Technical White Paper

Advanced Driver
Assistant System
Threats, Requirements, Security Solutions

EXECUTIVE SUMMARY
This paper discusses security vulnerabilities and potential solutions for Advanced
Driver Assistance Systems (ADAS). We introduce ADAS system architecture and
present use cases. We further provide detailed threat analysis of two leading
ADAS use cases: (1) lane departure warning and (2) adaptive cruise control. Based
on threat analysis results we identify security problem areas and state security
requirements for each. We devote the last part of this paper to ADAS security
solutions that can meet identified objectives.

This study makes several key contributions to addressing ADAS security problems
Establish critical needs to addressing security problems via detailed
threat analysis
Define main security problem areas for ADAS
Identify challenges and requirements for securing ADAS control functions
Establish the mission of securing E2E ADAS data path
Define trust foundation for secure ADAS platforms
Make recommendations for ADAS security solution menu

1. Introduction
Demand for Advanced Driver Assistance Systems (ADAS) is caused by desire to
build safer vehicles and roads in order to reduce the number of road fatalities
and by legislation in the leading countries. ADAS is made of the following physical
sensors: radar, LIDAR, ultrasonic, photonic mixer device (PMD), cameras, and night-
vision devicesthat allow a vehicle to monitor near and far fields in every direction
and of evolving and improving sensor fusion algorithms that ensure vehicle, driver,
passengers, and pedestrians safety based on factors such as traffic, weather,
dangerous conditions, etc. Modern ADAS systems act in real time via warnings
to the driver or by actuation of the control systems directly and are precursors
to the autonomous vehicles of the future.
Lead Author: Meiyuan Zhao
Research Scientist
Security & Privacy Research, Intel Labs
[email protected]
Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

Table of Contents There are several challenges to design, implement, deploy,

and operate ADAS. The system is expected to gather accurate
Executive Summary..................................................................................1
input, be fast in processing data, accurately predict context,
1. Introduction...............................................................................1
and react in real time. And it is required to be robust, reliable,
2. ADAS System Background.....................................................2 and have low error rates. There has been significant amount
2.1. ADAS Example Usage Cases................................................3 of effort and research in the industry to solve all these chal-
2.2. ADAS Conceptual Architecture..........................................3 lenges and to develop the technology that will make ADAS
3. ADAS Security Problem Areas..............................................5 and autonomous driving a reality.
4. ADAS Control Function Threat Analysis.............................7 In addition to functional requirements, ADAS must be
4.1. Adversarial Model.....................................................................7 secured from adversaries with malicious intent whose
4.2. Use Cases for Threat Analysis............................................7 goal is to compromise the system and cause catastrophic
accidents with loss of life and damage to property.
4.3. Summary of Threat Analysis Results...............................8
5. ADAS System Security Requirements.................................9 It has been shown both in academia and automotive
5.1. Control System Security Requirements..........................9 industry that control system can be compromised via
malicious attacks launched through various means, for
5.2. Lifecycle Management Security Requirements....... 10
example via DVD player, the ODB-II port,1,2 or even wirelessly
5.2.1. Start Secure.................................................................. 10 via tire pressure sensors,3 as a result displaying to the driver
5.2.2. Run Secure.................................................................... 10 wrong warnings3 or even causing fatality by remotely dis-
5.2.3. Stay Secure................................................................... 10 abling braking system on a vehicle while it is moving.1,2
6. Secure End-to-End ADAS Data Path................................ 10 In addition to protecting the system from criminal actors,
6.1. SummarySolution Areas................................................ 11 there is a bigger threat looming from nation-state
sponsored cyber terrorism.
6.2. Secure ADAS Computing Platforms.............................. 11
6.3. Intel ADAS Platform Security Foundation................. 12 In this whitepaper we argue that ADAS security should be
6.4. Secure Sensing....................................................................... 13 considered as a fundamental non-functional requirement
together with reliability, robustness, performance, and low
6.5. Secure Actuation.................................................................... 14
error rates. We analyze vulnerabilities in a conceptual ADAS
6.6. Secure ADAS Main Data Processing.............................. 14 architecture via representative use cases. Based on the
6.7. Secure Connected Ensembles......................................... 15 vulnerability analysis results we state security requirements
7. Conclusion............................................................................... 16 and make suggestions on countermeasures against malicious
References................................................................................... 16 attacks. We show that ignoring ADAS security compromises
other design goals.
Appendix A. Threat Case Study #1:
Lane Departure Warning (LDW)............................................. 17
A.1. Lane Departure Warning Usage Case........................... 17
2. ADAS System Background
A.2. Adversarial Model................................................................. 17 ADAS system provides assistance to the driver and improves
A.3. Threat Analysis....................................................................... 17 driving experience. Its primary function is to ensure safety
of the vehicle, the driver, and the pedestrians or bikers. ADAS
A.3.1. Assets and Interfaces............................................... 17
could be used to save fuel costs by enabling platooning in
A.3.2. Data Structure Asset Properties........................ 18 which vehicles follow each other within close distance; it
A.3.3. Threat Analysis........................................................... 19 could warn when a vehicle swerves across the lane or it
A.3.4. Data Privacy Discussion......................................... 22 could apply emergency brake to avoid collision, etc. To
Appendix B. Case Study #2: function reliably, ADAS must be able to recognize objects,
Adaptive Cruise Control (ACC)................................................ 24 signs, road surface, and moving objects on the road and to
B.1. Adaptive Cruise Control Usage Case............................. 24 make decisions whether to warn or act on behalf of a driver.
B.2. Adversarial Model................................................................. 26
B.3. Threat Analysis....................................................................... 26
B.3.1. Assets and Interfaces............................................... 26
B.3.2. Data Structure Asset Properties......................... 26
B.3.3. Threat Analysis........................................................... 28

2
 Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

2.1. ADAS Example Usage Cases 2.2. ADAS Conceptual Architecture

ADAS system is considered as the advancement from driver To support ADAS functions the architecture must include
assistant system (DAS). DAS is a system that informs and modules for sensing, processing, intelligence generation,
warns, provides feedback on actions, increases comfort, and decision making. Figure 2 is a generic view of what the
and reduces workload by actively stabilizing or maneuvering ADAS system might look like. The overall system compro-
the vehicle. ADAS system is considered as a subset of DASs, mises sensors of various types; a CPU-GPU combination to
with increased use of complex processing algorithms to perform the sensor data processing, object identification,
detect and evaluate the vehicle environment based on and early sensor fusion; a Central Brain CPU for performing
data collected via a variety of sensor inputs. Figure 1 sensor fusion from different sensor blocks, object tracking,
demonstrates the spectrum of DAS capabilities available vehicle control activities to interact with the actuation, and
in production today; the capabilities considered as ADAS a diagnostics block.
are highlighted with stars. The ADAS usage cases that re-
quire full power of real-time processing and intelligence are
highlighted with full stars, whereas half-colored star marked
usage cases are relatively more rudimentary ADAS cases.

Cruise control
Electronic self-locking differential
Automatic cruise control
Electronic break power distributor
Anitblocking system Speed limit information

Traction control Intelligent speed adaption

DRIVING
STABILITY
Electronic stability program
Right of way regulation information
Power steering Steering support LONGITUDINAL
Active steering CONTROL Traffic sign/light violation warning
Tire pressure control
Vertical dynamic control Brake assist Brake preparation
Dry brake
Automatic emergency brake
Adaptive curve light Automatic hold
Automatic brake control
Automatic headlight range adaption Start automatic
Hill climb automatic
Beam light assist
LIGHT
Night vision AND SIGHT DAS Driver state monitoring
Adaptive light system Passenger seat observer
COCKPIT
Automatic warning light Navigation system
Fuel consumption optimisation
Rain sensor system

Rear view camera Turn assist

Blind spot detection
Lane change assist
Surround view
Lane departure warning
Park distance control PARKING LATERAL
CONTROL Lane keep support
Automatic parking assist
Lane change support
Alighting assit

Figure 1. Spectrum of DAS and ADAS Functions

3
Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

SMART

SENSOR COMMUNICATION

COMMUNICATION PORTAL
SENSOR

COMMUNICATION PORTAL
CLOCK POWER SMART
ACTUATOR
SMART
PROTOCOL
SENSOR

SENSOR CENTRAL
PROCESSOR PROCESSOR

RAM ASILD SMART

SMART WDT ACTUATOR
SENSOR

ROM RAM ROM

Figure 2. Conceptual Hardware Block Diagram for ADAS System

This system is considered as a close-loop control system, where the vehicle control actuation actions are computed based
on received data from sensors. And the outcome of the ADAS actuation actions is fed back in the loop as sensor input. All the
computing units in ADAS of the vehicular system are generally referred to as electronic control units (ECUs). The sensing and
actuation ECUs are relatively resource constrained units, compared with the central processor of ADAS.

One of the key advancements in ADAS design is the concept of sensor fusion. This is the process by which the internal pro-
cessing takes input from the multiplicity of external sensors and creates a map of possible impediments around the vehicle. The
map then facilitates the computation that creates a series of possible actions and reactions through situational analysis. Figure 3
shows an example ADAS-enabled vehicle with a collection of sensors to enable sensor fusion and actions.

NIGHT VISION VIDEO REVERSE

CAMERA CAMERA CAMERA

LONG-RANGE MID-RANGE ULTRASOUND MID-RANGE

RADAR RADAR FRONT RADAR BACK

Figure 3. Example ADAS Sensors

4
 Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

Sensor fusion and situational analysis can be done case 3. ADAS Security Problem Areas
by case for different ADAS functions and occurs at mul-
Before looking into details of security threats, let us
tiple levels. It is beneficial to have early fusion (determining
first examine, at high level, what are the major areas of
conditions as early as possible) and a centralized processing
concerns for ADAS system in dealing with hostile running
brain (improving quality of detection and reducing CPU
environment and malicious actions by adversaries. In gen-
power consumption). Figure 4 demonstrates an approach
eral, any malicious actions that could cause ADAS system
where sensor fusion occurs in both the sensor processor
to behave outside its specification are referred to as threats
and the central brain. With this design, the system provides
to ADAS. And the interfaces that allow such threats to occur
a horizontal architecture that can support multiple ADAS
are referred to as attack surfaces. Now the key questions are:
applications in parallel. Such architecture is an advancement
what is the specified behavior of an ADAS system, and how
from vertical systems that only support individual ADAS ap-
do attackers cause the system to misbehave? The answers
plications case by case. We base our security analysis on this
to these questions lead to the discovery of three major ADAS
conceptual architecture.
security problem areas.

LANE FORWARD BLIND SPOT ACTIVE ADAS

DEPARTURE COLLISION DETECTION CRUISE APPLICATION
WARNING WARNING WARNING CONTROL N

SITUATIONAL ANALYSIS

SENSOR FUSION

CLASSIFICATION CLASSIFICATION

TRACKING TRACKING TRACKING

OBJECT DETECTION OBJECT DETECTION OBJECT DETECTION

FEATURE EXTRACTION FEATURE EXTRACTION FEATURE EXTRACTION

PRE-PROCESSING PRE-PROCESSING PRE-PROCESSING

SENSOR INPUT 1 SENSOR INPUT 2 SENSOR INPUT N

Figure 4. Example Sensor Fusion in ADAS

5
Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

Control System Security Secure Lifecycle Management

As we discussed before, ADAS can be thought of as a Deploying and maintaining intended modules in the ADAS
close-loop control system. While in operation it must is as important as any other protection mechanism for ensuring
satisfy functional safety, efficiency, performance, and ADAS system behavior according to the specifications. This
reliability requirements. We refer to this whole system process is typically referred to as lifecycle management.
behavior as ADAS control system and processing and Changes to the ADAS system could be triggered by:
make securing it our priority.
System upgrade/algorithm updates
Threats to the control function come from any actions the Software patch
attacker could take, given their capabilities, to cause the
system to act outside of its specifications. Any changes of Installation of new components for additional functions
the system properties that contribute to the violation of Hardware recovery and replacement
its safety goals may happen due to deliberate attacks. The System recovery due to compromise
security requirements to support safety goals should mainly
Root of trust update due to authority updates in
concern establishing and maintaining functional integrity
the administrative domain
and other requirements. With further threat analysis and risk
assessment, one could derive detailed security requirements, Cryptographic algorithm and key updates due
which will be discussed in Section 5.1. to cryptosystem migration or other reasons

ADAS Data Protection ADAS is especially vulnerable to malicious actions

In addition to attacking core functions of ADAS, the attacker during updates because some interfaces which are
could be motivated to attack the system to achieve other not normally available become open to external data or
unexpected consequences by the original design. For example, external operations. Furthermore, ADAS system consists
the attacker could eavesdrop on ADAS data processing and/ of multiple modules. Any changes to any one of the modules
or internal communication to gain access to ADAS data. Leak- will require the system to re-establish trust relationships
age of data to an external party other than for local control between these modules so that they can reliably exchange
system consumption may also be an unexpected behavior of data and commands.
the system, therefore a second area of security problem for
Lifecycle management security is not a new problem for
ADAS may come from ADAS data protection. Security system
ADAS system. Any computing system needs to deal with
must ensure Confidentiality, Integrity, and Availability (CIA)
changes to ensure that the system can start securerun
of data collection.
securestay secure. The same problem in ADAS system
The practice of recording data for accountability may be is facing extra challenges:
implemented by a blackbox system. Should the blackbox
Secure update on control system immature in auto
be implemented, the storage security would be an issue. Simi-
industry and ecosystem
larly, integrity protected storage system would be required
Manual update at a garage or repair shop by trained
if the storage is used for collecting and storing other vehicle
professionals is a common practice. Update process
related information, such as object classifiers or maps. The
usually requires proprietary tools and labor intensive
specific threats are similar as seen in a typical storage system
work. Although there is a new trend of attempting to
in the traditional computing world. Hence, in this whitepaper,
enable remote update via standardized processes to
we do not dedicate our focus on understanding threats in
relief the labor cost the procedure is still not mature
such systems, as well as the derived requirements on ADAS
enough to be pervasive. This is especially true for the
data protection. Nonetheless, there exist many studies in
updates that require intense verification on control
the literature that we could leverage. In this article, we derive
system integrity.
security requirements based on existing threat studies and
certain solutions can be leveraged to address security issues
for data protection and access control.

6
 Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

Small scale ECUs to meet security primitive Can read/write/jam/forge the radio channel
requirements for secure update Can add/remove functionality
Updating relatively large scale computing platforms is Can boot/operate removed parts in alternate
straightforward since there are available system update environments
and recovery technologies and services suitable for such
Expected attacker capability: University Challenge
platforms. ADAS, however, may have smaller scale micro-
controllers for sensors and actuators. Such small scale Will invest up to 6 months engineering effort and $50K
platforms may not have sufficient cryptographic or security part/equipment/computation to develop tools to attack
primitive support. Hence, the challenge is to achieve the many vehicles
same security objectives with lightweight system update Compared with the typical computing system, the difference
security technology. in ADAS system is mostly on the physical aspect, besides the
Long lifetime vs. limited cryptographic strength cyber actions and capabilities. For instance, the ADAS function
Control systems like the vehicles typically have long life- used for controlling operation of the vehicle physically offers
times. Cryptographic solutions in the current computing opportunities to attackers to launch their actions that may lead
world, however, have relatively shorter lifetimes. Hence, to consequences on control systems, on actuators, and on
during the ADAS system lifecycle, there may appear the other ECUs that have mechanical impact to the vehicle. On the
need to update the ADAS system with stronger and new other hand, the attacker could also potentially launch attack
cryptosystem. This problem in the traditional computing via physical actions and eventually cause cyber or physical
system is not critical given that most of the devices must consequences. In our analysis, we attempt to cover both
be operational only for a few years. Careful design and cyber and physical aspects of possible attacking actions.
analysis is required for updating the cryptographic system,
because it effectively serves as the basis of trust for every 4.2. Use Cases for Threat Analysis
security function. Compromising the root of trust will Two applications are used in the study:
surrender control to attackers. Lane Departure Warning (LDW)

4. ADAS Control Function Threat Analysis Adaptive Cruise Control (ACC)

For conducting threat analysis, we need information on LDW use case is for vehicle lateral control, where warning
1) target usage case; 2) architecture for the use case; is presented to driver if the ADAS system detects that the
3) expected adversarial model. The analysis methodology vehicle is departing from the current lane. The main function-
is a commonly used approach where we decompose the ality by the sensors and data fusion is to recognize the lane
system to assets and examine every interface exposed by lines and predict the vehicles driving direction based on the
each asset to understand all possible behaviors with all detected trajectory.
possible interface parameters and values.
ACC use case is for vehicle longitudinal control. It manages
4.1. Adversarial Model the vehicle speed adaptively based on the detection of
Lets first define expected adversarial model in our analysis. distance with leading vehicle, the current speed, the
We use a typical adversarial model, the same for analyzing road condition, and prediction of leading vehicles speed
threats to Intels system product and technology. ADAS sys- change. In this application, the ADAS system continuously
tems share many properties as a typical computing system. generates actuation command to control throttle ECU
Hence, the adversarial model for the computing system is or brake ECU accordingly.
mostly applicable to ADAS system. We assume that ADAS These two applications use similar ADAS architecture, with
system should worry about the attackers who can launch some differences on required input sensing data and output
simple hardware attacks with the capability of university data format and purpose. Their output difference is clear:
challenge. This means: warning only or take direct actuation. Potential failure in
Expected attacker capability: Simple hardware attacker computing and generating corresponding output in these
two cases may have dramatically different consequences.
Has reverse engineered all firmware, software
Can modify and replace all firmware, software These two use cases can represent several ADAS functions
Can replace/substitute any ADAS components that improve driving experience and support safety. Our
future work will extend the threat analysis on other use
Can remotely install privileged and unprivileged
malware onto any micro-processor that communicates cases that facilitate parking or improving lighting and sight,
through external interfaces as illustrated in Figure 1.

7
Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

4.3. Summary of Threat Analysis Results Given the diverse types of data being generated and
Detailed threat analysis is documented in Appendix A and processed in the ADAS, not only forged data or incorrect
Appendix B. Here, we provide a summary of threat analysis data content has impact to the system, but also whether
results and insight on high risks. the data is in time for consumption, or available at all are
intrinsically important issues for ADAS control system.
Study summary: entire data path from initial sensing to Missing data or delayed data may cause the system fail to
final actuation is vulnerable. generate appropriate intelligence, or respond to situations
in real time. Furthermore, the sensing fusion algorithms rely
Lets examine where the vulnerable assets and exposed in- on potentially multiple streams of data. Some algorithms
terfaces are. Main attack surfaces, shown in Figure 5, include have requirement that streams of input data are received
exposed interfaces and are broken by vulnerable assets and processed in correlated sequence. Hence, attack
(internal or external). Attackers have a range of options, they actions that can successfully change the correlation to
can, for example, generate false data on a sensing platform, further manipulate the behavior of sensing fusion.
modify data on the internal communication channel, gener- In terms of undesirable consequences, as summarized
ate undesirable ADAS output data on the fusion brain plat- in Figure 5, the compromised ADAS system could cause
form, change output data on the internal communication to false positive or false negative warnings or actuation actions.
the actuation ECUs, manipulate firmware and software on the In false positive case, the ADAS system could generate warn-
output platform to make the system fail. ing or take unnecessary actions on vehicle control system to
Our analysis reveals that there is a set of data properties respond to falsely computed need to warn or take action
especially vulnerable to manipulation. Beyond the basic at- situation, whereas the actual driving condition may be still
tack on data values, as summarized in Figure 5, vulnerabilities normal. On the other hand, the false negative outcome
exist if syntax, semantics, timing, availability, and correlation could cause the system fail to respond to potential danger
are manipulated. Data syntax refers to some of the properties happening on the road. Furthermore, the control decision
associated with the content, for example, output from LDW could still be relevant, but only relevant to the past condition,
could be played via audio device where volume of the output a little too late current. All these undesirable outcomes could
warning is defined as data syntax. Change of audio volume to potentially lead to unsafe driving consequences, cause a
undesirable level is a realistic threat to LDW function. collision, or even loss of human life. These consequences

SENSING SMART SENSOR

INPUT PLATFORM OUTPUT
HDMI
SENSING SMART SENSOR ADAS FUSION
INPUT PLATFORM BRAIN PLATFORM
ACTUATION
SENSING SMART SENSOR CONTROLLER
INPUT PLATFORM

DATA

MAIN ATTACK SURFACES MANIPULATION ON DATA MAJOR CONSEQUENCES

External Input Syntax False Positive

Interface Semantics False Negative
Processing Timing Delayed Actuation
Internal Processing Availability Failure in Enabling Control
Processing Correlation Failure in Disabling Control
Communication User Mistrust
User Discomfort
External Output
Interface
Processing

Figure 5. Summary of Threat Analysis Results

8
 Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

are very specific to the vehicle control system and defeat These requirements are fundamental for a secure ADAS
its primary design goal: improving driving safety. control system. They shall be used guidelines when design-
ing and implementing the ADAS system. In the complete
Other consequences may include failure in enabling or
ADAS data path, assets that satisfy these requirements
disabling ADAS control. In addition, frequent failures in
include all types of data, sensing modules, actuation mod-
reporting accurate driving conditions can cause users mis-
ules, any processing modules, and internal communication.
trust of the ADAS system and turn off the system all together.
Further decomposition is needed when it comes to the need
ADAS system can also be compromised to defeat the goal to design solution to protect a specific module or a specific
of improving driving experience. For instance, in the case set of modules in the ADAS system.
of ACC, to maintain a proper speed, the vehicle may be ma-
On sensing modules, initial calibration and on-going operation
nipulated to speed up or slow down suddenly, or repeatedly
are the focus. Sensing data is required to be available in real
take these actions. Such outcome is apparently not desirable
time, accurately reflect the sensing condition, and reliable to
to the driver and to passengers.
tolerate most of unexpected conditions.

5. ADAS System Security Requirements On actuation modules, similarly, the focus is on initial calibra-
tion and on-going operation. In particular, it is required that
Given the threat analysis results and insights in highly
incoming actuation commands are processed in real time
vulnerable parts of the system, we examine security and
and accurate manner. The actual actuator should execute
system requirements that will provide guidance in designing
the commands accurately, fast, and reliably under various
security solution for ADAS.
conditions. The actuation function should be available and
5.1. Control System Security Requirements continuously in correct operation status.
Security requirements for ADAS control system are primarily On internal processing modules, software and hardware
derived from threat analysis results. We take LDW and ACC protection should be in place to ensure that the supporting
as case studies, and focus most efforts on understanding data is 1) available; 2) not delayed or rushed; 3) content is
how attackers could launch the attacks that could cause the authentic and integrity protected; 4) syntax is correct; and
system to act outside its control system specification. That is, 5) correct correlation in multiple sensing streams is main-
the system that achieves the control system objectives. tained. To accomplish these objectives, the major software
Therefore, the overall security objective on ADAS control and hardware components for any internal processing
system is to: module should:

Provide boot time system integrity protection against

Defend the ADAS control function against malicious
malicious software modification
attacks, so that the ADAS control function can achieve the
expected specified behaviors: delivers warning or takes Provide run time execution protection against
necessary actuation actions in real time that accurately malicious modification
reflect the current driving condition and according to Ensure processing latency protection against malicious
reasonably accurate prediction of potential danger. system jamming or denial of service

To support this objective, the secure ADAS control system On internal communication, to protect data properties, the
should satisfy the following major requirements. protocols should ensure integrity, authenticity, availability,
freshness, and timeliness of any data internally communicated.
R1. Availability The system and functions should ensure These requirements can be used to further derive specific re-
that data and processing capability are available to satisfy quirements on functions for internal communication, including
the needs by ADAS fusion and intelligent actions. managing communication keys, handshakes, communication
R2. Real Time Delivering of warnings/actions should buffering, and actual data distribution.
be in real time to be useful.
R3. Accuracy Warnings and actions correctly
and accurately reflect the current driving condition
and accurate enough prediction of potential
incidents on road.
R4: Reliability System is able to predict potential
dangerous conditions with high probability and low
error rate; Ensuring such capability when system is
under attack.

9
Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

5.2. Lifecycle Management Security Requirements Detect runtime attacks: It is required that system should
Like other secured systems, the functions and the archi- at least detect attacks when they happen in the system.
tecture that support ADAS functions should start secure, To do this, the system is required to generate information
run secure, and stay secure. Security from cradle to grave of system status that differentiates between normal
is a critical requirement to maintain ADAS lifecycle integ- conditions vs. under attack conditions.
rity. ADAS system consists of multiple components and the Prevent runtime attacks: A stronger requirement for
internal communication. This makes security of lifecycle system to run secure, is to invoke mechanisms that
management more challenging compared with a traditional prevent the system from being attacked at runtime.
computing system or any other systems that only deal with a Solutions that satisfy this requirement may be built-in
single main processing module. In this section, we pay close design in the system architecture, or additional security
attention on security management of ADAS ensemble and mechanisms/protocols that protect the operation
modules that specific for ADAS or automotive. Readers can and data.
refer to literature for secure lifecycle management require-
ments for stand-alone computing modules. 5.2.3. Stay Secure
Changes occur in ADAS system with respect to individual
5.2.1. Start Secure
components and managing the ADAS trusted ensemble.
Primary goal at this stage is to establish secure provisioning
Whether it is about updating/patching hardware and soft-
of ADAS components, and the trust relationships between
ware on individual components, or on updating trust rela-
components. Below are some key requirements:
tionship among group members, the following are the high
Establish Root of Trust (RoT): A trusted owner of the entire level requirements to be satisfied in order to maintain the
system to be established and held accountable of ADAS trusted ADAS ensemble.
system configuration and management. This common RoT
Integrity protected
is the foundation for ADAS components to establish secure
relationships and communication keys as required by Authenticated source to provide update
ADAS operation. Update with authorized modules only
Deploy trustworthy HW and SW trust modules: It is Freshness in update process
required that the initially provisioned system hardware Proper trust foundation re-establishment on
and software modules are trustworthy and are the updated components
authentic version by the authority. The system is also
required establish the authority as the trusted party, Group-based authenticity and integrity protected
and provide mechanisms to allow third party to gain
proof that the system is running trustworthy modules. 6. Secure End-to-End ADAS Data Path
Establishing integrity policies among components: This section offers some thoughts on how to design and
There should exist policies and mechanisms that allow develop solutions to support ADAS security requirements.
each individual component to establish and prove its trust
Given our analysis of threats and security requirements,
status to other components, as well as for the components
the overall goal for securing ADAS function has emerged:
to establish and prove their trusted status as a whole
ensuring protection of data collection, processing, and
architecture and group.
control system execution for ADAS use cases. We are in the
5.2.2. Run Secure mission of securing the end-to-end ADAS data path: from
Once the ADAS system starts to run, the following are some collection to final consumption. Security solutions should
high level requirements. be designed to secure ADAS path with four major areas of
concerns: 1) secure Real-time Sensing and Input, 2) internal
Invoke trusted system only: Upon system boot, only the data processing, fusion, and decision making, 3) trustworthy
provisioned trusted hardware and software can be booted. and reliable output, and 4) trusted internal data dissemina-
Any forged components should be detected and prevent tion. Furthermore, lifecycle management issues will be
from loading into the system. addressed together with control system security in our
Validated input only: Mechanisms should be invoked here solution discussion.
to validate the input. In particular, there are interfaces
Note 1: The discussion on securing diagnosis and auditing
exposed externally to acquire input from physical world.
functions that require separate architecture from main ADAS
Mechanisms that are used to protect input at these inter-
system and are considered out of scope for this document.
faces are still in their infancy.

10
 Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

SECURE ADAS ENSEMBLE

ADAS Group Key Management Secure in-Vehicle Comms Protocol

SECURED SMART SECURED ADAS SECURED ACUTATION

SENSOR PLATFORMS FUSION BRAIN PLATFORM PLATFORMS

Sensing ECU Integrity Protection System Integrity Protection Acutation ECU Integrity Protection

ADAS Data ADAS Data ADAS Data ADAS Group ADAS Data Actuation
Sensing Comms
Comms Fusion Mgmt Comms

Trusted Platform Foundation Trusted Platform Foundation Trusted Platform Foundation

Figure 6. Summary of ADAS Security Solution Areas

Note 2: We dont necessarily limit ourselves in a specific Furthermore, the trust relationships between these platforms
solution space. As general discussion, all solution and how they establish secure communication to support
spaceshardware, software, firmware, system, security requirements on data flows are also critical. In this
networking, and servicesare under consideration. area, there are key management issues among platforms,
and issues of securing data paths and channels. To facilitate
6.1. SummarySolution Areas trusted ensemble management, there should be a module
To secure the end-to-end ADAS data path, the main solution to manage the ADAS group. Here, we hypothetically put this
areas should concentrate on following five areas: functionality on the central fusion platform, given its unique
1. Common trust basis for computing platform position that allows it communicate with every other compo-
2. Securing sensing nent in the ADAS system. This function could also be enabled
by a specially designed module as a completely separate
3. Securing actuation component in the system.
4. Securing internal processing In the rest of this section, we discuss each solution area in
5. S
 ecuring ADAS ensemble (trust management more detail. Again, we mainly focus on how each component
and communication) in the system can leverage security technology to satisfy
security requirements for ADAS control system and lifecycle
Their relationships can be described at high level, management. In some of the areas, the existing security tech-
as illustrated in Figure 6. nology needs to be re-engineered or re-designed to meet
To handle input, or output, or internal processing, any com- ADAS requirements.
puting platform should have a set of basic security features 6.2. Secure ADAS Computing Platforms
that establish basic trust on these computing platforms.
Computing platforms in ADAS include sensing platform, the
Beyond this basis, each computing platform may be required
ADAS main processing platform, and the platforms for actua-
to enable additional security solutions that meet specific
tion. All these platforms should establish a set of primitives
security and functional requirements for input, output, or
as trust foundation for supporting ADAS security operations.
internal processing respectively.
Figure 7 demonstrates these primitives at the conceptual
As illustrated in Figure 6, for sensing ECUs, the primary tasks level. Note that the actual instantiation of these primitives
for security solution are protected sensing and trustworthy is case by case depending on the target platform or micro
communication to distribute sensing information to con- controller. Also, this is a demonstrative security profile. We
suming components in the ADAS system. For actuators, the do not require that every ADAS component to support all
ADAS specific security protection is trustworthy actuation, of these primitives. This is especially the case for resource
and communication for receiving actuation commands and limited micro controllers. Nonetheless, for the completeness
other management messages. For main ADAS main fusion of discussion, it is important that the trust foundation covers
platform, the center of the solution stack is on trusted data major areas of issues for protecting basic functions that an
fusion processing. ADAS component relies on.

11
Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

COMMON SECURITY FOUNDATION

Protect Data Communications
To ensure strong protection on internal communication for
Attestation Service Secure Network Stack ADAS data, one could enable technology to protect channels
directly. This may include I/O protection on platform and
Authenticated Recovery Trusted FW Update
system, as well as the secured network stack support. Fur-
PCIe*/DDR/PCI Protected/ thermore, the security protocol should be in place to ensure
I/O Protection Virtualization Isolated Memory that data transportation satisfies the requirements: authen-
CPU Crypto
ticity, integrity, freshness, completeness, and timeliness. The
Secure Storage Secure IDs
(AES/SHA, etc.) communication driver should be operated in the protected
execution environment with support of HW root of trust and
TPM HW Root of Secure/Verified Boot
Trust secure identities for necessary cryptographic operations
and validations. Also, the networking buffer operated by the
driver should be in a protected memory region to prevent it
Figure 7. A Menu for Security Ingredients for ADAS from being malicious tampered.
Computing Platform
6.3. Intel ADAS Platform Security Foundation
In summary, a platform is responsible for four major security Intel is uniquely positioned to provide full hardware, firm-
goals in order to support ADAS functional security. ware, and software support to ADAS trusted foundation.
Intel continues to enhance systems so they run more
Goal #1: Establish and Maintain Platform Integrity
securely. A key component of this approach is providing more
Goal #2: Support Secured Update robust, vulnerability-resistant platforms. Security features
are embedded in the hardware of Intel processors, some
Goal #3: Protect ADAS Processing and Operations
of which will be deployed and leveraged in future ADAS
Goal #4: Protect Data Communication systems. The following is some sample technology that
combines the hardware strength from Intel platforms and
Establish and Maintain Platform Integrity comprehensive software security solutions from McAfee,
Platform integrity is the basis of trust for the platform. In this offering great potential to enable strong ADAS E2E solutions.
category, the platform should enable primitives to form a
trusted computing base: trusted platform module (TPM) or Intel Boot Guard for secure boot
equivalent component, HW root of trust, secure IDs, secured Intel architectures provide temper-resistant hardware
storage, protected crypto engine. Based on these primitives, modules, such as authenticated code module (ACM)-based
other basic security functions can be established, including secure boot that verifies a known and trusted BIOS is booting
secure/verified boot, attestation of system and firmware. the platform. It is the foundation of trustworthy system boot
and execution.
Support Secured Update
The platform should have capability to continuously watch Intel Platform Protection Technology with BIOS Guard
itself for integrity protection. In the case of corruption, on BIOS Guard supports hardware-assisted authentication
either BIOS, firmware, OS, or on software, the authenticated and protect against BIOS recovery attacks, along with other
recovery technology should be invoked to ensure the system platform protection technology, ensuring fundamental
can regain its integrity with the authenticated image. Further- platform protection.
more, the trusted FW/SW update technology is part of trust Intel Platform Protection Technology with Platform
foundation to ensure system can be securely patched. Trust as basis for ADAS key management
Protect ADAS Processing and Operations Platform Trust provides integrated solution for secure
Protection on ADAS function operations on the platform is credential storage and key management. This feature may be
needed to achieve security requirements R1R4. The execu- utilized for enabling secure ADAS ensemble key management
tion integrity is the first priority. Furthermore, internal data and serving as the basis for trusted ADAS communication.
structure and buffered data should be protected from mali- Intel Trusted Execution Technology (Intel TXT)
cious tempering. For this purpose, the security foundation enhancing platform security
can provide primitives for boot time and run time execution To protect against attacks toward hypervisor and BIOS,
protection. Example primitives could include secure/verified firmware, and other pre-launch software components,
boot, secure storage, protection memory for execution isola- Intel Trusted Execution Technology (Intel TXT) provides
tion, and virtualization. hardware-based technology to establish a root of trust
through measurements when the hardware and pre-launch
software components are in a known good state.

12
 Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

Hardware-Assisted Intel Data Protection Technology 6.4. Secure Sensing

With Intel AES New Instructions (Intel AES-NI), Intel Sensors are at the starting line of the ADAS data path. The
Secure Key instruction, and Intels Digital Random Number sensing input has critical impact on overall correct operation
Generator (DRNG), users gain combined value of solid of ADAS functions. Leveraging the common trust founda-
cryptographic foundation support from Intel platforms. tion, one can ensure that the smart sensing platform satisfies
Intel Virtualization Technology (Intel VT) securing the requirements and enables a trusted computing base for
ADAS workloads ADAS sensing function, and secured sensing data communi-
On shared virtualized hardware, a set of ADAS workloads cation. For the platform that supports smart sensing, there
can co-locate while maintaining full isolation from each other, are few issues that require special attention and treatment.
freely migrate across infrastructures, and scale as needed. Lightweight Security Mitigation
Intel Virtualization Technology (Intel VT) provides hardware The variety of sensing platforms demands that the security
assist to virtualization software, eliminating performance solutions should be customized to be suitable for the tar-
overheads, and improving security. get platform resource constraints and cost limit. For some
Intel Software Guard Extensions (Intel SGX) of the lightweight sensors, the full protection package as
for targeted ADAS execution protection described in Section 6.2 is not feasible. Tradeoffs between
With a new set of CPU instructions, Intel Software Guard cost and just enough security are needed.
Extensions (Intel SGX) could provide ADAS application capa- For small scale micro controllers, the trusted computing
bility to set aside private region of code and data, allowing base may be as small as a protected memory region for
application to protect sensitive data from unauthorized sensing execution. To minimize the complexity, the system
access or modification by rogue software, or enabling the could be required to support only a static version of the
platform to measure ADAS applications trusted code and sensing algorithm firmware. No other software or firm-
produce a signed attestation. ware can be inserted to the system without authorization.
Such concept can be realized by an embedded controller
TrustLite: Lightweight Trusted Execution Protection
whitelisting solution. Furthermore, the cryptographic
Technology4 for small ECUs in ADAS
support of small scale embedded controller may be
The technology developed in Intel Labs to enable
simplified as well. The goal, is to support just enough
protection on execution on very resource-constrained
for customized protection on the sensing platform.
SoCs or platforms. Potential protection on every small
ECUs (sensing, processing, or control) become possible Trusted Graphics Processing
with TrustLite,4 enabling Secure Loader, Secure Exceptions/ Some of the sensing platforms used in ADAS require
IPC, and Lightweight Isolation Execution. powerful graphics processing. For instance, the front-view
and side-view cameras operate to capture frame streams
McAfee Deep Defender and DeepSAFE defending at high frequency in real time and generate initial graph-
malware attacks ics models, and output to main ADAS processing platform.
Anti-malware solutions work with the Intel hardware To meet the performance requirement, the platform may
features to run beyond the operating system to detect integrate a GPU to facilitate demanding graphics process-
covert stealth attacks. ing. In such architectures, the additional care of security
McAfee Embedded Control to protect fixed-function is needed on GPU processing and data paths to ensure
ADAS modules authenticated data flows between GPU and CPU, as well
Fixed-function modules, including ADAS fusion brain plat- as the trusted execution environment support on GPU.
form are protected against any unauthorized change on the Sensing Integrity Protection
application with McAfee Embedded Control technology. Smart sensing platforms interact with physical environment
Intel is thriving to develop platform protection foundation directly. Trusted ADAS operations rely on authentic, com-
across various form factors, making E2E ADAS system pro- plete, and fresh source of information, which is the main task
tection possible. The rest of this section discuss specific of sensors in ADAS. The challenging objective is to provide
additional treatments for secure sensing, actuation, data sensing integrity technology that can ensure the generated
fusion, and ensemble management. models by the sensing platform accurately and correctly re-
flect current physical condition in real time. This is, currently,
a technology gap to be filled with further innovation.

13
Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

6.5. Secure Actuation Maintain Functional Simplicity

The secure actuation platform is on the final consuming phase As powerful as it should be for processing high volume
of ADAS data path. Similar to sensing platform, actuation of data in real time and generate accurate models from
ECUs could leverage the common trust foundation for target multiple data streams, the main ADAS computing plat-
security requirements. For the platform that supports reliable form in fact supports relatively less complex functionality:
actuation, there are few issues that require special attention generate control commands to manage vehicle operation,
and treatment. Some of the issues are similar ones that the given current driving condition. Unlike a typical computing
smart sensing platform faces. platform in IT world (e.g., desktop, laptop, or smartphone),
the ADAS computing platform only supports a few algo-
Lightweight Security Mitigation rithms and a few ADAS use cases.
Actuation platforms are typically small scale and support
singular functionality. For these smaller scale controllers, With this observation, it is important for the ADAS main
the full protection package as described in Section 6.2 computing platform to maintain its simplicity. The security
is not feasible. Tradeoffs between cost and just enough technology that ensures only a few authorized applica-
security are needed. Again, the minimized trusted comput- tions, such as whitelisting, can be invoked. And unauthor-
ing base, as required for small sensors, is also required for ized installation or modification of the ADAS application
small scale actuation platforms. Hence, lightweight cryp- software should be detected and denied.
tographic engine and embedded controller whitelisting Protecting Real time Operating System and Software
solution are of special consideration to support lightweight Huge work loads of ADAS main platform and the real-time
security mitigation on actuation. reaction requirement could drive the system architecture
Actuation Integrity Protection to be supported by a real-time operation system. This
Actuator ECUs manipulate control mechanics of the vehicle means, the security ingredients that are traditionally tied
directly. Taking authentic input command and making sure to a specific operating system should be re-engineered
the execution is faithful and timely are critical to the overall or re-designed to be suitable for the real-time operating
ADAS system security and reliability. Any failure of actua- system and software. Example of such technology may
tor ECUs could have catastrophic and fatal consequences. include boot time/run time integrity protection, attestation,
While most actuator ECUs are implemented to satisfy anti-malware solutions, and trusted recovery technology.
highest safety requirements, we need to enable security Multi-interface Protection and Isolation
protection on these ECUs so that possibility of triggering The main ADAS computing platform is situated in the
failures cannot increase when the ECU becomes the target unique position in the vehicular control system that it has
of malicious attack. various interfaces that essentially connect to every parts
Here, the challenge of ensuring integrity protected actua- of the ADAS system, from user interface, physical sensing,
tion has not been fully met, which remains a technology and to passing commands to ECUs. The more interfaces
gap to be filled with further innovation. it has, the higher probability that the system may be at-
tacked. Therefore, protecting each interface, as well as
6.6. Secure ADAS Main Data Processing isolating these interfaces are critical to the system to have
any hope of maintaining its integrity. On the main ADAS
As the main brain of ADAS system, the ADAS main pro-
computing platform, an integrated isolation solution,
cessing platform demands full security protection. It is the
such as Trusted Execution Environment + Protected Data
best practice to enable strongest security protection on this
Path should be carefully designed and implemented.
platform given its critical function of data fusion. The good
Additional challenge in this task is that the resulting solu-
news is that the target platform is relatively more powerful
tion has to also meet the minimized latency requirement
than sensors and actuators. Therefore, a full set of security
as mandated by the real-time system.
primitives can be made available on the main platform for
integration to ADAS internal data processing protection.
There are three particular considerations on main platform
worth further discussion.

14
 Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

6.7. Secure Connected Ensembles For security design, different layers of network stack have
The security system for intra-vehicle data communication their own security issues and suitable solutions. In ADAS
for ADAS function consists of three components: system, there exists diversity of communication channels:
Integrity assurance of communicating modules Ethernet, CAN, FlexRay, and other proprietary channels.
Different type has its own security issues. And existing
Key management that establishes trust between modules
solutions are different in terms of the technology maturity.
Secure communication protocol For instance, for Ethernet links, existing TCP/IP stack and
their security countermeasures could be suitable to secure
Integrity Verification communication. On the other hand, the CAN protocol is
The integrity of platforms serves as the basis for establishing currently still vulnerable to malicious attacks and the solu-
trusted channels between them. Here the local attestation tion is still under development in the standards groups and
or integrity verification solution is required to establish that by industrial consortia. Here, the main issue with enabling
the modules maintain their integrity of the system. The integ- secure communication in ADAS system is primarily on ensur-
rity demonstration to modules serves as the basis of trust for ing interoperability, so that modules from different vendors
further establishing protected channels. could be easily integrated to construct secure intra-system
Furthermore, if there is a need that a group of modules to communication in an ADAS system.
establish trusted communication, the basis of trust among The communication protocols may not be always pairwise
them could be established via a group-based attestation between modules. Depending on the ADAS use case, there
solution. There are some technology in the literature, could could also be group-based communication. For instance,
be used as the basis for constructing group-based attesta- in the case of multiple sensors serving together for ACC
tion. Yet, to our best knowledge, this is an open challenge function in ADAS, there may be needs to ensure multiple
for securing ADAS group. front-view cameras work together to ensure reliable
Secure Communication Protocols modeling of front view road condition. There may be group-
For data distribution, we need to enable trusted data paths based communication flow among these cameras, the corre-
across platforms in the ADAS architecture. As identified sponding sensing platform(s), and the main ADAS processing
in threat analysis, the primarily concerned data channels platform. That means security protocols should be designed
are mostly bi-directional from the main ADAS processing and deployed among these modules that satisfy specific
platform to all other platforms including: smart sensing requirements by such group communication workloads.
platforms, platform for user input, ECUs for status report Hence, individual modules in ADAS system should provision
and actuation control. The primary issues for protecting data and invoke these additional components that support data
flows are the data properties that directly impact functional flow protection, whether its pairwise based or group base,
goals of the entire ADAS control system: availability, real- or any form of relationship.
time, reliability, and accuracy. Key Management
Supporting secure communication among ADAS modules To support secure communication protocol, the secure com-
is a non-trivial problem. As demonstrated in threat analysis, munication sessions should be established. The goal of key
given the expected adversarial model, communication management is to establish session keys or the keys used to
channels can be fully under control by adversaries. To protect the communicate channel between parties. In ADAS
protect data flows on these channels, security protocols are system in general, the communication is required to support
required. Security primitives such as HW root of trust, secure data availability, freshness, integrity, and authenticity. Hence,
identities, and secured cryptographic engines are required the keys used to achieve these goals should be established
to support cryptographic operations and validation by the properly before the modules could engage with the secure
secure communication protocol. In addition, the complexity communication protocol for exchange data. The property of
of supporting secured communication comes from two these keys depends on the choice of target security protocol.
issues: diverse channel types and diverse data flows.

15
Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

The basis of establishing keys is from the trust relationship between the modules. The trust relationships should be repre-
sented by the security credentials that can authenticate the modules. In addition, the binding of the modules current status
with its authentication credentials could be required to establish the trust. To achieve this goal, the system needs to utilize the
integrity verification function. Such verification may be required to be mutual: mutual authentication and mutual attestation.
Furthermore, the group-based authenticated communication requires group-based trust relationship, hence requires member
authentication in group and group-based attestation.

Technology foundation in this area exists. The suitable solutions for ADAS should be designed to meet the architectural
requirements and specific communication security requirements.

7. Conclusion
This paper details the security issues that directly impact the ADAS system functional safety goals. Key security issues are
identified via threat analysis case studies. Security requirements are derived from every parts of the ADAS architecture. Key
security objectives are defined to support ADAS control system integrity, data protection, and lifecycle management. Various
pieces of the security architecture and solutions are identified that can be put together to protect the vehicles operation with
ADAS system. There are many architecture specific details to be worked out. More learning comes from actually doing
experiments. Further work is along with a few specific directions:

1. F
 urther exercise and experiment for a specific ADAS architecture; engineering work to enable ADAS security solutions,
advancing the secure ADAS system to be reality.

2. Proof-of-concept and experiments:

a. Integration of primary security technology with a target ADAS use case.
b. Validate effectiveness of solutions for control functional safety.
c. Evaluate performance overhead and impact on functional correctness.
3. R
 &D efforts to tackle challenges and technology gap in ADAS security, both from functional and performance perspectives.

4. S
 ecurity impacts on functional safety for automotive: detailed analysis, and community consensus building in the context
of automotive standardization.

References
1 Checkoway et al, Comprehensive Experimental Analyses of Automotive Attack Surface, USENIX Security, Aug. 2011

2 Koscher et al, Experimental Analysis of a Modern Automobile, S&P 2010

3 Rouf et al, Security and Privacy Vulnerabilities of In-Car Wireless Networks, USENIX Security, Aug. 2011

4 Koeberl et al, TrustLite: a security architecture for tiny embedded devices, In Proceedings of the Nineth European
Conference on Computer Systems (EuroSys 14)

16
 Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

Appendix A. Threat Case Study #1: Lane Departure Warning (LDW)

A.1. Lane Departure Warning Usage Case Expected attacker capability: Simple HW attacker
The lane departure warning (LDW) use case refers to a spe- Has reverse engineered all firmware, SW
cific function by the ADAS system that enables the vehicle Can modify and replace all firmware, SW
to sense and calculate model to determine if the vehicle is
Can replace/substitute any ADAS components
moving in the lane properly. The calculation is ongoing and
the system generates warning to driver if the LDW module Can remotely install privileged and unprivileged
malware onto any micro-processor that
determines that the vehicle is currently outside the intended
communicates through external interfaces
lane, or is about to cross the lane line, departing the current
lane. Figure 8 demonstrates a conceptual system architecture Can read/write/jam/forge the radio channel
that enables LDW function. Can add/remove functionality
Can boot/operate removed parts in
In particular, the input taken from sensors include frames
alternate environments
captured from front cameras in real-time, and speed and
steering position of the vehicle as captured internally Expected attacker capability: University Challenge
through CAN bus. The incoming frames are consumed by a
Will invest up to 6 months engineering effort and $50K
sensor pre-processor, which uses the frames to recognize
part/equipment/computation to develop tools to attack
objects, such as lane lines, and generates graphical model of
many vehicles
driving condition with respect to LDW. The graphics model(s)
are then transmitted to the main processor that fuses sens- A.3. Threat Analysis
ing information from both the graphics models and current A.3.1. Assets and Interfaces
conditions of the vehicle, and generates LDW output as the To analyze all threats, the ADAS system is decomposed
outcome of calculation. The output can be in the form of to assets. Threats on each asset are the threats to the
video/audio to the corresponding output interfaces. entire system. Assets can be a piece of software, hardware,
or data structure. We treat assets as atomic modules in the
A.2. Adversarial Model
system. The threats on assets are launched through inter-
The expected adversary to LDW usage case are the
faces, each assets exposed, including input interfaces
attackers who can launch simple HW attacks with the
and output interfaces.
capability of university challenge. This means:
Figure 8 summarizes the relationships between assets. Table
I enumerates all assets and the corresponding interfaces.

AVB/ Video
PRE-PROCESSOR

FRONT Ethernet Out

Clock Code DRIVER
CAMERA
SENSOR

Frames DISPLAY
Main CPU Data
FRONT AUDIO
CAMERA SYSTEM
Frames/ COMPUTING PLATFORM Audio
75 Mbps Out
CAN Network

Speed, Stearing
Position

Figure 8. Lane Departure Warning System Block Diagram

17
Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

ASSET ASSET INPUT INPUT FROM OUTPUT OUTPUT TO

ID NAME INTERFACE ID INTERFACE ASSET INTERFACE ID INTERFACES ASSET
Lens to AVB/Ethernet
A1 Camera C1.1 External O1.1 A2
front view interface
Sensor pre-
A2 C2.1 Ethernet port A1 O2.1 Internal bus A3
processor
C3.1 Internal bus A2 O3.1 Video port A4
A3 Main processor
C3.2 CAN port A6 O3.2 Audio port A5
Audio
A4 Audio system C4.1 A3 O4.1 Speaker External
input port
Driver graphics HDMI
A5 C5.1 A3 O5.1 Display External
output input port
ECU status ECU specific
A6 C6.1 Internal O6.1 CAN bus A3
reporter ports
Ethernet Ethernet
A7 Frames C7.1 A1 O7.1 A2
channel channel
Graphics
A8 C8.1 Internal bus A2 O8.1 Internal bus A3
models
Audio
A9 Audio warning C9.1 A3 O9.1 Audio channel A4
channel
Graphical HDMI
A10 C10.1 A3 O10.1 HDMI channel A5
warning channel
CAN
A11 Velocity info C11.1 A6 O11.1 CAN channel A3
channel
Steering CAN
A12 C12.1 A6 O12.1 CAN channel A3
wheel info channel

Table 1. Assets in LDW Architecture

In this definition, each asset has one or more input interfaces A.3.2. Data Structure Asset Properties
and one or more output interfaces. For the assets that expose For A7 A12 data structures, we further define all properties
some or all interfaces externally, the interfaces are specially of concern.
labelled. Otherwise, all input interface should specify the
A7: Frames
assets that the input is taken from, and all output interfaces
should specify the assets that the output is delivered to. Content parseable as video frame from camera
Resolution in proper range
Furthermore, assets A1 A6 are major modules in the LDW
system architecture that work together to enable the LDW Contrast
function. Assets A7 A12 are specifically defined for the data Brightness
structure that moves between major functional assets. We
Generated frequency
define the assets in such way to make sure the properties of
the data structures are captured. And unexpected changes to Availability
these data structures that alter the properties are considered
attacking actions.

18
 Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

A8: Graphics model data A.3.3. Threat Analysis

Data structure syntax To analyze the threats posed by the expected adversaries, we
Data structure semantics start from the expected behavior of the system. In general,
any attack actions that cause the system to act outside its
Availability
specification, are categorized threats to the system.
Generated frequency
The system specification of LDW, from threat analysis
A9: Audio warning perspective, is the following:
Data syntax The LDW system should produce accurate warning in time,
Data semantics (content delivers the intended meaning) based on current driving condition.
Availability Therefore, the attackers goal of causing the system to
Timeliness act outside its specification can be illustrated in the
Volume following figure.

As illustrated in Figure 9, the main goal of attacker is Cause

A10: Graphics warning
incorrect warning w.r.t. current condition. It can be further
Data syntax
broken to three cases:
Data semantics (content delivers the intended meaning)
False warning: the system produces warning to user, when
Availability the vehicle is NOT departing the lane. Or the system pro-
Timeliness duces warning to driver with unexpected properties, which
are considered as false as well.
A11: Speed status information
Removed warning: the system fails to produce/deliver
Data structure syntax
warning to user, when the vehicle IS departing the lane.
Data structure semantics
Delayed warning: the system produces/delivers warning
Availability not useful at present time, but may reflect past condition.
Timeliness This threat can be considered as the combination of
Frequency Removed Warning and then False Warning.

The consequences of attacking LDW may include

A12: Steering wheel information
the following:
Data structure syntax
Data structure semantics False warning:
Incorrect warning cause driver panic and potential colli-
Availability
sion that cause lost of life and damages of properties
Generated frequency
In-accurate warnings (maybe too many of them) cause
decrease users trust on LDW system, and the user
could eventually ignore the LDW system totally

19
Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

LDW: INCORRECT WARNING W.R.T. CURRENT CONDITION

FALSE WARNING REMOVED WARNING DELAYED WARNING

AVB/ Video
FRONT Ethernet PRE-PROCESSOR Out
Clock Code DRIVER
CAMERA
SENSOR

Frames DISPLAY
Main CPU Data
FRONT AUDIO
CAMERA SYSTEM
Frames/ COMPUTING PLATFORM Audio
75 Mbps Out
CAN Network

Figure 9. Threat Analysis on LDW Architecture

Removed warning: Summary

Lack of warning to reflect current condition is Manipulation of input data properties have direct impact
equivalent to the vehicle WITHOUT LDW system. of LDW function correctness
If driver relies on LDW system to react to condition, Accurately represent current condition (incoming
the drivers reaction to dangerous condition could frames and vehicle status)
be delayed Both content and properties are important
Potential collision and/or other fatal consequences Internal processes are vulnerable because of
Delayed warning: Malware threats on sensor pre-processor and main
LDW algorithm for fusion
Consequences are the combination from False Warning
and Removed Warning Internal communication on Ethernet channel, CAN bus,
internal bus, as well as output channels
False Warning Threat Analysis
Table 2 summarizes threat analysis results for False
Warning Threat. The threats are categorized into threats
on input data, internal process, and output data. The
goal is to identify all external/internal interfaces of LDW
system assets that attacker can manipulate to conduct
actions and cause the system to produce False Warnings.

20
 Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

MAJOR SUB TARGET TARGET

THREATS THREATS ASSETS INT ACTIONS
Camera take input A1 C1.1 Fake env. condition for camera lens
Camera process input A1 N/A Insert forged frames directly in camera
processing and memory
Infect camera firmware to produce forged
frames that indicate lane departure
Camera delivers frames A1, A7 C1.1, O1.1, O7.1 Frames are modified with property change: e.g.,
blurry frames to confuse modeling software.
Insert forged frameworks to indicate lane
Input Data departure
Remove frames that indicate normal condition
Vehicle operation status A6, A11, A12 C6.1, C11.1, Block delivery of speed and steering wheel
report C12.1, O11.1, information
O12.1 Rush/delay delivery of status information
Forge speed information: pretend moving fast to
confuse modeling algorithm
Forge steering wheel information: report turning
when vehicle moves straight, or report straight
when vehicle is turning
Process frames to A2 C2.1 Insert malicious code that processes frames and
generate models generate models (malware)
Modify internal memory with forged information
Insert frames indicating lane departure
Output models to further A2 O2.1, C8.1, O8.1 Insert malicious code that process
LDW alg. A8 output models
Modify internal buffer that stores models
Modify generated models
Delete models
Insert forged models
Internal bus channel manipulation
Same actions as on output buffer
LDW alg. to fuse sensing A3 C3.1, C3.2 Insert malicious code that fuses sensing data
data, and generates and generates warning (malware)
Internal Process warning Modify internal memory with forged information
Insert models that directly indicate lane
departure
Deliver output warning to A3 O3.1, C10.1 Insert malicious code that process output
output devices A10 O10.1 warnings
Modify internal buffer that stores output
warnings
Modify generated warnings with undesirable
properties, e.g., turn up warning volume
Re-order buffered warnings
Insert forged warnings in buffer
HDMI channel manipulation
Similar actions as on output buffer
Audio channel manipulation
Similar actions as on output buffer
Output device process A4 C4.1, C5.1 Manipulate input buffer to store forged and
received data A5 incorrect warning data or modify the stored
warning data
Malware in warning data processing code to
Output Data introduce forged final signal for warning output
Output device delivers A4 O4.1, O5.1 Malfunction of A4 to deliver unnecessary loud
warning A5 warning
Output HW delivers forged warning directly
from attacker
Table 2. Threat AnalysisFalse Warning Case of LWD

21
Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

Removed Warning Threat Analysis

Table 3 summarizes threat analysis results for Removed Warning Threat. The threats are categorized into threats on
input data, internal process, and output data. The goal is to identify all external/internal interfaces of LDW system
assets that attacker can manipulate to conduct actions and cause the system to not produce warning when it should given
the current condition.

MAJOR SUB TARGET TARGET

THREATS THREATS ASSETS INT ACTIONS
Camera take input A1 C1.1 Fake env. condition for camera lens
E.g., putting up a video to feed in camera lens
Camera process input A1 N/A Insert forged frames directly in camera
processing and memory
Infect camera firmware to produce forged
frames that indicate normal driving condition
Delete incoming frames
Delay incoming frames
Reorder incoming frames
Replay normal frames
Camera delivers frames A1, A7 C1.1, O1.1, O7.1 Frames are modified with property change: e.g.,
Input Data blurry frames to confuse modeling software.
Insert forged frames to indicate normal
condition
Remove frames that indicate lane departure
condition
Vehicle operation status A6, A11, A12 C6.1, C11.1, Block delivery of speed and steering wheel
report C12.1, O11.1, information
O12.1 Rush/delay delivery of status information
Forge speed information: pretend moving fast to
confuse modeling algorithm
Forge steering wheel information: report turning
when vehicle moves straight, or report straight
when vehicle is turning

Table 3. Removed Warning Case of LWD (continued to next page)

Notes: Attacker actions for removed warnings are very similar A.3.4. Data Privacy Discussion
to the actions for False Warning case. All these actions So far, we focus our analysis mostly on examine vulnerabilities
focus on interfaces that could: that cause the ADAS to fail its LDW functionality. Given that
the system is expected to constantly collect and process input
Manipulate input or input processing
data from video cameras and internal CAN bus, there might be
Manipulate output or output delivery a concern of privacy of such data. For instance, such data can
Manipulate internal processing and internal be used to track location of the vehicle, and reveal behavior
data communication history of the driver(s).

As discussed above, the Delayed Warning attack can be In our analysis, we believe, there is no privacy concern if the
achieved with combination of actions for removed warning data is collected only for the purpose of supporting LDW
and false warning. Therefore, threat analysis for this third function. The rationale is the following:
case can be considered as union of actions as illustrated in The input data, internal data, and output data are all
table 1 and 2. for temporary consumption. The data is not stored
for long term.
Front view condition is publically available for any one of
interest. Instead of attack LDW system directly, attacker
could simply install his own camera to capture the same
or similar views.

22
 Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

MAJOR SUB TARGET TARGET

THREATS THREATS ASSETS INT ACTIONS
Process frames to A2 C2.1 Insert malicious code that processes frames
generate models and generate models (malware)
Modify internal memory with forged information
Insert frames indicating normal conditions
Output models to further A2 O2.1, C8.1, O8.1 Insert malicious code that process
LDW alg. A8 output models
Modify internal buffer that stores models
Modify generated models
Delete models
Insert forged models
Internal bus channel manipulation
Same actions as on output buffer
LDW alg. to fuse sensing A3 C3.1, C3.2 Insert malicious code that fuses sensing data
data, and generates and generates warning (malware)
Internal Process warning Modify internal memory with forged information
Insert models that directly indicate lane
departure
Deliver output warning to A3 O3.1, C10.1 Insert malicious code that process
output devices A10 O10.1 output warnings
Modify internal buffer that stores
output warnings
Modify generated warnings with undesirable
properties, e.g., turn down warning volume
to zero
Delete warnings directly
HDMI channel manipulation
Similar actions as on output buffer
Audio channel manipulation
Similar actions as on output buffer
Output device process A4 C4.1, C5.1 Manipulate input buffer to remove the
received data A5 warning data
Malware in warning data processing code
Output Data to delete output
Output device delivers A4 O4.1, O5.1 Malfunction of A4 to deliver muted warning
warning A5 Output HW of A5 shut down by attacker

Table 3. Removed Warning Case of LWD

Given this reasoning, we think data privacy should not be Besides data privacy, there may be a need to keeping the
considered as a threat for LDW system. details of internal LDW algorithm secret, for vendors IP
protection purpose. If there is such need, and the algorithm
However, if in the vehicle ADAS, there is a function module
is designed and implemented in such a way that internal data
that collects sensing and vehicle status information and
models as input for LDW fusion can potentially reveal algo-
stores it in a non-volatile storage for other usages, such as
rithm details, there should be mechanisms to keep internal
telematics, auditing, etc., then there is the privacy concern
data private, even if such data is only for temporary con-
that leakage of such information can be used to reveal users
sumption. Alternatively, the vendor could choose to design
private driving activities.
or re-design the LDW algorithm, so that internal model data
structure wont provide information that helps to recover
algorithm details.

23
Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

Appendix B. Case Study #2: Adaptive Cruise Control (ACC)

B.1. Adaptive Cruise Control Usage Case ACC function, by nature has higher severity in the conse-
The adaptive cruise control (ACC) use case refers to another quences of failure, because it involves direct vehicle control,
specific function by the ADAS system that enables the vehicle as opposed to only the warning through UI to driver. The
to autonomously manage its moving speed, based on the controllability is outside the consideration of this analysis.
following four sources of information: Therefore, our focus should be on exposure to failures.
Attack actions to ACC function could potentially increase
Current vehicle condition
system exposure to failure significantly. Well visit this issue
Driving condition and relative speed of leading vehicle in risk analysis.
Road conditions Figure 10 illustrates a conceptual system architecture that
Drivers preference enables ACC function.

ACC is the advanced version of current cruise control function. The similar ADAS architecture is used to support ACC func-
Currently, the cruise control accepts a speed set value from tion. For ACC, the system takes different input data set, runs
driver and manages the vehicle control system to maintain the the ACC modeling algorithm, and output to take actions that
target speed. It may takes additional sensing information for manage vehicle speed. Heres the summary:
speed management from road, e.g., up/down hill and turning. Input:
However, traditional cruise control does not allow the vehicle Speed, acceleration status (gas, brake) from CAN bus
to adjust vehicle speed dynamically according to the relative
Graphics: front cameras, lidar, radar
distance to the leading vehicle.
Road condition: surface condition, uphill/downhill, curves,
Primary intelligence in ACC is the capability of recognize weather conditions (from local sensors as well as through
leading vehicle(s), estimate relative distance, and even network communication)
predict the leading vehicles next moving model.
ACC Algorithm:
Compared with LDW, ACC function provides additional
Leading vehicle(s) object detection
opportunity to analyze a more complete example of ADAS
function that involves input, internal process, and real-time Distance estimation
control command and actuation. Based on ISO 26262 require- Leading vehicle driving condition assessment
ments, LDW is generally considered as ASIL B function and and prediction
ACC is generally considered as ASIL C/D function. In other
Hazard detection: sudden brakes, pedestrians,
words, ACC has more stringent safety requirements. For the
traffic sign/light, speed limit, road construction, etc.
same ADAS system architecture, implementing ACC means
need to reduce exposure to failure, reduce severity of system Speed management prediction
failures, and increase controllability when failure happens.

AVB/
FRONT Ethernet WATCHDOG
CAMERA
SENSOR PRE-PROCESSOR

Frames/ Audio/ ACC

FRONT 75 Mbps Video CONDITION
Clock Code
CAMERA UPDATE
Models
Main CPU Data CAN
bus SPEED
COMPUTING PLATFORM MANAGEMENT
ACTIONS
CAN bus External network
LIDAR
VELOCITY, DESIRED ROAD CONDITION,
DIRECTION, INPUT WEATHER INFO,
ACCELERATION FROM POLICY REPORT,
RADAR STATUS USER TRAFFIC INFO

Figure 10. Adaptive Cruise Control System Example Architecture

24
 Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

LEADING CAR
Smart Sensing Platform(s) MOVEMENT
Camera Input OBJECT
OBJECT
OBJECT OBJECT MOVEMENT PEDESTRIAN
Lidar Input DISTANCE
DETECTION RECOGNITION MODEL AND MOVEMENT
ESTIMATION
Radar Input PREDICTION
LANE
LINES
User Input
TRAFFIC
Road DESIRABLE SIGNS
Condition ROAD SPEED/SPACE
ROAD
Input SURFACE MODELING
MODEL
MODELING Low Level Controller

ADAS Brain Platform THROTTLE

CONTROLLER
Vehicle
Operation SPEED
Condition MANAGEMENT SWITCHING LOGIC
Input ACTUATION

BRAKE
CONTROLLER

Figure 11. Functional Flow Diagram for ACC

Output: The models of recognized objects could then be passed

Control signals to control speed and adjustment to ADAS brain platform. Here, there are multiple ADAS
Information output through HMI use cases supported, besides ACC. More powerful fusion
process on ADAS brain takes input from smart sensing
Figure 11 gives an example flow diagram with respective to platform, users input, road condition input, and vehicle
more detailed processing in ACC function. Focusing on the operation status from CAN bus, and conduct processes to:
fusion algorithms for ACC, there may be a nature separation
Predict object movement
of processing among the main platform as ADAS brain, and
the sensing data pre-processor. Model road surface and condition
Calculate desirable speed for vehicle and/or desirable
As shown in Figure 11, the smart sensing platform could be
distance to be maintained from the leading vehicle
responsible for taking input from sensors, and construct-
ing models for object recognition, and extra properties and Eventually generate speed management command
conditions of the detected objects. In this process, there may
be multiple sensing platforms, each handling a set of sen- The speed management commands are then passed to low
sors that provide a specific type of sensing information. In level controllers. Here corresponding throttle controller or
ACC case, sensing processing for video frames from camera, brake controller processes the input command and take
for lidar input, and radar input could be separated. There is, actions to adjust vehicle speed via throttle or brake.
however, a process used to fuse all three types of sensing Threat analysis, all these ACC fusion and control processes
data to accomplish accurate object detection, recognition, are under consideration.
and distance estimation.

25
Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

B.2. Adversarial Model A14: Audio warning

The expected adversaries to ACC usage case are the same Data syntax
as the model used for LDW threat analysis. Data semantics (content delivers the intended meaning)
Here these are the attackers who can launch simple Availability
HW attacks with the capability of university challenge. Timeliness
This means:
Volume
Expected attacker capability: Simple HW attacker
Has reverse engineered all firmware, SW A15: Graphics warning
Can modify and replace all firmware, SW Data syntax
Can replace/substitute any ADAS components Data semantics (content delivers the intended meaning)
Can remotely install privileged and unprivileged mal- Availability
ware onto any micro-processor that communicates
through external interfaces Timeliness
Can read/write/jam/forge the radio channel A16: Speed status information
Can add/remove functionality Data structure syntax
Can boot/operate removed parts in Data structure semantics
alternate environments
Availability
Expected attacker capability: University Challenge
Timeliness
Will invest up to 6 months engineering effort and $50K
Frequency
part/equipment/computation to develop tools to attack
many vehicles A17: Lidar input
Content parseable as Lidar sensing data
B.3. Threat Analysis
B.3.1. Assets and Interfaces Resolution in proper range
Following the same analysis philosophy, we define ADAS Generated frequency
assets for ACC function. The architecture is slightly more
Availability
complex than the LDW architecture, due to diverse types
of input and additional actuation control command output. A18: Radar input
Table 4 numerates assets and interfaces for ACC architecture. Content parseable as Radar sensing data

B.3.2. Data Structure Asset Properties Resolution in proper range

For A12 A21 data structure assets, we further define all Generated frequency
properties of concern. Availability
A12: Frames
A19: Speed change command
Content parseable as video frame from camera
Content parseable as speed change command
Resolution in proper range
Desirable speed value within valid range
Contrast
Desirable speed value reflects current driving condition
Brightness
Desirable acceleration/deceleration time window is
Generated frequency a valid range and reflects current driving condition
Availability Availability

A13: Graphics model data Timeliness

Data structure syntax
Data structure semantics
Availability
Generated frequency

26
 Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

Assets in Adaptive Cruise Control (ACC) System Architecture

ASSET ASSET INPUT INPUT FROM OUTPUT OUTPUT TO
ID NAME INTERFACE INTERFACE ASSET INTERFACE INTERFACES ASSET
ID ID
A1 Camera C1.1 Lens to front view External O1.1 AVB/Ethernet interface A2
A2 Lidar sensor C2.1 Lidar sensing port External O2.1 Internal communication link A4
A3 Radar sensor C3.1 Radar sensing port External O3.1 Internal communication link A4
C4.1 Ethernet port A1
Sensor pre-
A4 C4.2 Lidar link port A2 O2.1 Internal bus A5
processor
C4.3 Radar link port A3
C5.1 Internal bus A4 O5.1 Video port A6
C5.2 CAN port A9 O5.2 Audio port A7
A5 Main processor
C5.3 Internal bus A10 O5.3 CAN bus A7
C5.4 Network driver A11
A6 Audio system C6.1 Audio input port A5 O4.1 Speaker External
A7 Driver graphics C7.1 HDMI input port A5 O5.1 Display External
output
Internal channel (could be
Throttle/brake
CAN bus) to send command to
A8 Low level controller C8.1 command input A5 O8.1, O8.2 Internal
Throttle Controller or Brake
port
Controller
Vehicle status
A9 C9.1 ECU specific Internal O9.1 CAN bus A5
reporter
On board road Sensor specific CAN bus or other internal
A10 C10.1 External O10.1 A5
condition sensors sensing input port channel
Weather condition
A11 C11.1 Internet driver External O11.1 Internal channel A5
reporter
A12 Video Frames C12.1 Ethernet channel A1 O12.1 Ethernet channel A4
A13 Graphics models C13.1 Internal bus A4 O13.1 Internal bus A5
A14 Audio warning C14.1 Audio channel A5 O14.1 Audio channel A6
A15 Graphical warning C15.1 HDMI channel A5 O15.1 HDMI channel A7
A16 Velocity info C16.1 CAN channel A9 O16.1 CAN channel A5
A17 Lidar input C17.1 Lidar sensing port External O17.1 Internal link A4
A18 Radar input C18.1 Radar sensing port External O18.1 Internal link A4
A19 Speed change C19.1 CAN bus A5 O19.1 CAN bus A8
Road condition
A20 C20.1 CAN bus A10 O20.1 Internal channel A5
sensing data
Weather information
Network driver/
A21 (rain or not, and how C21.1 A11 O21.1 Internal channel A5
port
hard)

Table 4. Assets in ACC Architecture

A20: Road condition sensing data A21: Weather information

Content parseable as road condition sensing data Content parseable as weather information
Availability Generated and provided by an authorized source
Data frequency Content authenticated from the authorized source
Timeliness
Availability

27
Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

B.3.3. Threat Analysis For the system design, the first two criteria are considered
To analyze the threats posed by the expected adversaries, as primary, given the ACC function has direct safety goals.
again, we examine the expected behavior of the system. Therefore, the attackers goal of causing the system to act
In general, any attack actions that cause the system to act outside its specification is primarily on: causing the failure
outside its specification, are categorized as the threats to manage proper speed to the point that the attack can
to the system. compromise the system design goal according to the
success criteria.
The system specification of ACC, from threat analysis
perspective, is the following: We are going to focus primarily on the safety critical
consequences. The rest of this section presents in more
Manage vehicle speed adaptive to real-time
details on the threat analysis that cause ACC safety
driving conditions
critical consequences.
This means that the success of ACC function can be
Collision Under ACC Threat Analysis
measured by the following criteria:
Similar to LDW, the threat analysis is conducted on assets in
Achieve cruise control function with reasonable conditions the system, for threats from input data, internal process,
Minimize danger of collision via real-time and output data. The goal is to identify all external/internal
speed management interfaces of ACC system assets that attacker can manipulate
to conduction actions and cause the system to cause colli-
Minimize traffic congestion factors
sion. A similar table, as LWD threat analysis, can be created
Maximize user comfort for capturing all threats.

These attacking consequences are illustrated Figure 12.

COMPROMISE ACC FUNCTIONALITY

CAUSE FAILURE TO CAUSE CAUSE

COLLISION ENABLE ACC TRAFFIC CONDITION DISCOMFORT
WHEN UNDER UNDER REASONABLE GIVEN REASONABLE GIVEN REASONABLE
ACC CONDITIONS CONDITIONS CONDITIONS

FAILED INPUT FAILED MODELING FAILED OUTPUT

Missing Failed to Indentify Object Missing Output Command

Improper Data Properties Incorrect Modeling of Generate Incorrect
Objects Acceleration Command
Delayed
Failure in Estimate Correct Generate Incorrect
Replayed Distance Brake Command
Incorrect Correlation Failure in Predict Failure to Enable
Incorrect Timestamps Movement Acutation Actions
Failure in Assess Failure in Delivering
Road Condition Video/Audio Output
to Driver
Failure in Enabling
Driver Control
Deliver False Warnings
to Driver

Figure 12. High Level Threats in ACC System

28
 Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

COLLISION UNDER ACC

FALSE ACTION ON THROTTLE MISSING ACTION BY BRAKE CONTROLLER

THROTTLE MODIFIED/ INCORRECT FAILURE IN DELAYED DELAYED DELETED BRAKE

FAILURE MISSING COMMAND GENERATE COMMAND COMMAND COMMAND FAILURE
COMMAND GENERATED COMMAND GENERATION TO TO
TO ON ON ON BRAKE BRAKE
THROTTLE CONTROLLER CONTROLLER CONTROLLER

IMPROPER SPACE/ DELAYED SPACE/

SPACE/ SPEED SPACE/ SPEED
SPEED INFO SPEED INFO
MODELING MIS- MODELING DELAYED
COMMUNICATED RESULTS COMMUNICATED

COMPROMISED INCORRECT INCORRECT IMPROPER MIS- DELAYED/

ALGORITHM LEADING LEADING ROAD COMMUNICATED DELETED
SW CAR CAR CONDITION MODELING MODELING
SPEED DISTANCE MODELS OUTPUT OUTPUT
PREDICTION ESTIMATION

COMPROMISED MIS- INCORRECT COMPROMISED CORRUPTED INCORRECT MISSING/

ALGORITHM COMMUNICATED OBJECT ALGORITHM COMMS. ROAD DELETED
SW MODELS RECOGNITION/ SW ROAD CONDITION ROAD
FROM SMART DISTANCE CONDITION INPUT CONDITION
SENSING EST. INPUT INPUT
ALG.
(DELAY, FORGERY,
DELETE,
MISCORRELATED)
COMPROMISED CORRUPTED INCORRECT MISSING/
ALGORITHM COMMS. FRONT DELETED
SW FRONT OBJECT FRONT
OBJECT SENSING OBJECT
SENSING INPUT SENSING
INPUT INPUT

COMPROMISED SENSING RISKS ON HW MECHANICAL

SW FAILURE INTERNAL COMMS FAILURE

Figure 13. Detailed Threat Analysis on Collision under ACC case

29
Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

Here, we use Figure 13 to summarize our findings. In L1.2: Missing action by brake controller, caused by
addition to the enumeration by a detailed threat analysis Brake mechanical failure
table, an organized tree of threats is created describe Mechanical problem is out of scope for ACC threat analysis
relationship of each threat to how it eventually achieve
Modified or missing command to brake (on A19)
the attack goals.
False information causes brake to fail to brake in time.
In Figure 13, the individual threats are the leaves in the tree. Properties on A19 that could lead to the consequence
They are color-coded by four categories: compromised SW, could be either command been delayed or deleted.
sensing failure, risks on internal communications, and HW Further, if there is a time window specified to take brak-
mechanical failure. The figure illustrates the process how an ing action, a malicious change to prolong the time window
attack could take action on an entry point, manipulating the information will cause the failure of braking properly.
system from that leaf upwards to parent nodes, which repre- L2.2: Failure in generating braking command by A8
senting the consequences caused by this action. Eventually, all This internal needs further analysis. Incorrect command
these internal unexpected changes in the system lead to the could be caused by either the input failures, or internal
final result of compromising ACC function and cause collision. processing failures.
Heres how the consequences are defined. L2.3: Delayed in generating braking command by A8
This internal needs further analysis. Incorrect command
L0: Collision under ACC System, caused by
could be caused by either the input failures, or internal
L1.1: False action on Throttle, or
processing failures.
The primary concern is that the vehicle doesnt slow
down in time that causes collision with leading vehicle. L2.1, L2.2, L2.3: Internal: Incorrect command generated by
Reduction of speed within a time window is the primary A8, caused by
concern. Failures in generating, or processing, or executing Miscommunication of target speed information input to
the appropriate command are the primary causes to A8 (input interface)
this consequence.
Missing speed change, or time window for
L1.2: Missing action by brake system action restriction
When braking is required to avoid collision, missing the Increase of target speed to an undesirable level
braking action becomes fatal. This could be caused by
Delayed speed change command
failures in generating, processing, or executing braking
commands by the system. L3.1: Incorrect space/speed modeling results from A5
This is an internal condition that needs further
L1.1: False action non Throttle, caused by
analysis. The desirable outcome by the attacker is
Throttle mechanical failure
to manipulate A5 or the input interface of A5 so that
Mechanical problem is out of scope for ACC threat analysis
the output speed change command is manipulated
Modified or missing command to throttle (on A19) to achieve the properties as describe in the above:
False information causes throttle to fail to reduce the increase of target speed to an undesirable level or
speed given required time window. Modification on A19, missing speed reduction when it needs to.
or the internal channel could include:
L3.2: Delayed space/speed modeling results from A5
Incorrect speed target (not enough reduction, or even
increase speed) Similarly, this is an internal condition that needs further
Longer time window specified to reduce speed analysis. A5 or input interfaces are manipulated in such
a way that the output of speed reduction command is
Missing speed reduction command
delayed.
Delayed speed reduction command

L2.1: Incorrect command generated by A8

This internal needs further analysis. Incorrect command
could be caused by either the input failures, or internal
processing failures.

30
 Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

L3.1: Internal: Incorrect space/speed modeling results L4.1.3: Improper road condition models
from A5, caused by Compromised ADAS brain fusion algorithm SW on A5
Compromised ADAS brain fusion algorithm SW Incorrect road condition sensing input
This can be achieved by malware infection. Once
E.g., incorrect sensing that misses downhill condition
the fusion algorithm SW is taken by the attacker, its
behavior is completely controlled by the attacker. Lack of weather info to indicate slippery road on
Therefore, the output of space or speed modeling a rainy day
is by attackers choice completely. This could be achieve by compromising sensors di-
rectly, or by compromising external weather source
Manipulation on O5.3, for output properties
Properties: speed value, space value, Missing road condition information
availability, timeliness E.g., missing downhill information
L4.1: Internal: incorrect modeling of current Corrupted communication to C5.3 and C5.4
condition, including
Similar properties of sensing data or weather
L4.1.1: Incorrect leading car speed prediction information are changed
L4.1.2: Incorrect leading car distance estimation
Input failures on C5.2
L4.1.3: Improper road condition models
CAN bus problem to provide correct information
Combination of above
on the vehicle speed status
L3.2: Internal: Delayed space/speed modeling results
L5.1: Internal: Incorrect object recognition or distance
from A5, caused by
estimation from A4
Compromised ADAS brain fusion algorithm SW
See L3.1 for further details
Manipulation on O5.3, for output properties
Property: delay output

L4.2: Internal: incorrect modeling of current condition,

that leads to delayed completion
L4.1.1, L4.1.2, L4.1.3 could lead to delayed output as well

L4.1.1: Internal: Incorrect leading car speed prediction

L4.1.2: Incorrect leading car distance estimation
Compromised ADAS brain fusion algorithm SW on A5
Input failures on C5.1
Models delayed, forged, deleted, or miscorrelated
Input failures on C5.2
CAN bus problem to provide correct information on the
vehicle speed status
L5.1: Internal: Incorrect object recognition or distance
estimation from A4

31
Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

L5.1: Internal: Incorrect object recognition or distance Discussion on Other Three Threats
estimation from A4 As described above, besides collision caused under ACC
Compromised SW: smart sensing platform (A4) with function, there are three other types of threats:
infected software
Failure to enable ACC under reasonable conditions
Output of speed modeling can be of attackers choice
Cause Traffic condition given reasonable conditions
Compromised communication
Input channels are compromised (C4.1, C4.2, and C4.3). Cause discomfort given reasonable conditions
Properties could directly affect the outcome of object
These three threats are real to users, although not necessarily
recognition, and object distance estimation, could include:
directly related to driving safety. Here we briefly discuss these
Availability of frames, or lidar, or radar signals that
threats, especially some of the detailed actions by attacker
illustrates current condition
that are not covered in collision threat analysis.
Content of input information
Failure to Enable ACC
Maliciously modified, or inserted with forged Hypothetically, the user input the desirable speed through
information
the existing input interface to trigger ACC function. The ACC
Frequency of input information system then could take the input, launch the software mod-
Correlation of these three sensing data streams that ule, and wake up sensors. The system could be attacked via
directly impact the outcome of the modeling threats on
Compromised sensing Users input
A1: front camera compromised to produce Sensor calibration error
compromised sensing content ACC function testing
Availability, legitimacy of content, in time ACC function testing output
Faked environment on the lens that feed in
as sensing input Under a typical driving environment, such as
Compromised camera FW/SW that produces reasonable leading vehicle distance,
undesirable output
past speed dynamics is reasonable,
HW compromise on A1, mechanical errors
the road is not too slippery, and
Failed calibration
A2: Lidar sensor compromised to produce visibility is good enough for sensing,
compromised sensing content
Availability, legitimacy of content, in time
Faked environment on the input interface to be fed in
Compromised sensor FW/SW that produces
undesirable output
HW compromised on A2, mechanical errors
Failed calibration
A3: Radar sensor compromised to produce
compromised sensing content
Availability, legitimacy of content, in time
Faked environment on the input interface to be fed in
Compromised sensor FW/SW that produces
undesirable output
HW compromised on A3, mechanical errors
Failed calibration

32
 Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

The ACC can be successfully enabled, after the ACC system Failed to launch ACC could also be achieved by failing the sen-
runs a round or multiple rounds of quick test. Hence, the sor calibration. During the process of system launching, the
threats posed by attacker that can fail the launch of ACC necessary sensors need calibration before they can be used to
involve actions to cause the system to produce output that capture sensing data for ACC function. Failure in enabling sen-
indicates failure of one or more of the above 4 conditions. sors properly via calibration can directly fail ACC function and
system. The attacking surface could be on the direct attacks
Overall, the threats can be summarized in Figure 14.
in sensor mechanics, or the module that handles calibration,
Attack actions on Internal ACC testing procedure can be very or the internal communication channels that pass information
similar to the actions taken to achieve collision. Similar threat between modules for the purpose of calibration, or the output
analysis for collision is applicable here. The difference lies in channels to confirm success of calibration.
that the same vulnerabilities are utilized and information is
Finally, output confirmation could be disrupted by the
manipulated differently to convince the system that it is too
attackers that could effectively disable the launch of
dangerous, or unreasonable to launch ACC now, even though
the ACC system.
the current driving condition is normal. Hence, the goals are
opposite to some of the attacking goals in the collision case.

Failed to launch ACC could also be achieved by failure in ac-

cepting users input, or errors in user input. Attacker could
take action on users input interface to delete, delay, replay,
modify, or insert fake command from user. The attack surface
could be on the direct external interface, or the module that
process the input command, or the internal communication
channel to delivers the command to ACC system.

FAILURE IN LAUNCHING ACC

FAILED INPUT FAILED FAILED INTERNAL FAILED OUTPUT

FROM SENSING ACC TESTING TO CONFIRM
USER UI CALIBRATION PROCEDURE SUCCESS LAUNCH

FAILED TO FAILED TO FAILED TO CONFIRM FAILED TO

CALCULATE IDENTIFY REASONABLE CONFIRM THAT
REASONABLE REASONABLE ROAD CONDITION ACC SYSTEM
DISTANCE HISTORICAL (REPORT TOO HAS GOOD
TO LEADING SPEED DYNAMICS SLIPPERY, VISIBILITY
VEHICLE (PATTERNS) OR TOO WINDY) ON ROAD

Figure 14. Threat AnalysisFailure to Enable ACC case

33
Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

34
 Advanced Driver Assistant System:
Threats, Requirements, and Security Solutions

35
 INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHER-
WISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTELS TERMS AND CONDITIONS OF SALE
FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE
AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR
INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT.
Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics
of any features or instructions marked reserved or undefined. Intel reserves these for future definition and shall have no responsibility whatsoever for
conflicts or incompatibilities arising from future changes to them. The information here is subject to change without notice. Do not finalize a design with this
information.
Copyright 2015 Intel Corporation. All rights reserved. Intel and the Intel logo are trademarks of Intel Corporation in the U.S. and/or other
countries. *Other names and brands may be claimed as the property of others. 0115/MW/HBD/PDF 331817-001US