EDA for Secure and Dependable Cybercars: Challenges

and Opportunities

Farinaz Koushanfar Ahmad-Reza Sadeghi† , Hervé Seudie†,‡

Electrical& Computer Engineering †
Fraunhofer SIT, Germany
Rice University †
Intel-TU Darmstadt Security Institute, Germany
Houston, TX ‡
Robert Bosch GmbH, Germany
farinaz@rice.edu {ahmad.sadeghi,herve.seudie}@trust.cased.de

ABSTRACT bedded system. The ECU networks not only command the
Modern vehicles integrate a multitude of embedded hard hard realtime control of automobile mechanical parts and
realtime control functionalities, and a host of advanced in- support infotainment functions [14], but also they provide a
formation and entertainment (infotainment) features. The gateway between modern cars and their surroundings (e.g.,
true paradigm shift for future vehicles (cybercars) is not traffic lights), devices (e.g., smartphones), vehicles, and ac-
only a result of this increasing plurality of subsystems and cessible networks. The terms car-to-car and car-to-X (infras-
functions, but is also driven by the unprecedented levels of tructure or device) are used to refer to cybercars’ commu-
intra- and inter-car connections and communications as well nication scenarios. The emergence of Intelligent Transport
as networking with external entities. System (ITS) is expected to further reduce the number of
Several new cybercar security and safety challenges si- road accidents and improve the road traffic conditions. Fur-
multaneously arise. On one hand, many challenges arise thermore, connecting cars to the cloud or smartphones offers
due to increasing system complexity as well as new func- a new set of applications and business models. In this con-
tionalities that should jointly work on the existing legacy text, Infotainment and safety related subsystems may need
protocols and technologies; such systems are likely unable to interact to provide various information to the driver.
to warrant a fully secure and dependable system without Figure 1 shows the view of ITS depicted by the stan-
afterthoughts. On the other hand, challenges arise due to dardization body ETSI (European Telecommunication Stan-
the escalating number of interconnections among the real- dards Institute). While the introduction of new communica-
time control functions, infotainment components, and the tion technologies offers an unprecedented number of new op-
accessible surrounding external devices, vehicles, networks, portunities, it increases the complexity of the car system and
and cloud services. The arrival of cybercars calls for novel demands new analysis of security and privacy requirements.
abstractions, models, protocols, design methodologies, test- A few preliminary attacks that could seriously impact the
ing and evaluation tools to automate the integration and car’s safety and reliability have already been demonstrated
analysis of the safety and security requirements. in simulations or experiments including [26, 37, 27, 28, 43,
31, 12]. For example, a study by Barisani et al. shows that
2 malicious cars out of 400 vehicles affected 20% of the traf-
Categories and Subject Descriptors fic [9], where this estimation did not even consider system
C.3 [Real-time and embedded systems]; D.4.6 failures due to design errors or poor implementation and
[Software]: OPERATING SYSTEMS—Security and Pro- testing schemes. A comprehensive summary of related work
tection which includes the description of the demonstrated attacks,
is provided in Appendix A.
General Terms The cyber-physical attributes of modern automotive sys-
Security, Reliability tems directly link security vulnerabilities to the cybercar’s
Keywords physical safety and reliability features. Therefore, the scope
of the potential vulnerabilities is much more vast than what
Perspective Article, Automotive Security, CPS Security has been demonstrated, and is far beyond attacking an in-
dividual car [42, 29]. Thinking of vehicle safety without
1. INTRODUCTION considering security, as it was done in the past, is no longer
Modern vehicles include several Electronic Control Units a viable option. In this respect, security vulnerabilities of
(ECUs) that form an in-vehicle distributed networked em- cars are markedly different from typical security issues in
conventional computer and network systems.
A few rather recent projects and initiatives have started
investigating the safety and security of modern vehicular
Permission to make digital or hard copies of all or part of this work for electronics, including [51, 52, 20]. The work thus far has
personal or classroom use is granted without fee provided that copies are mostly centered on identifying protection primitives to be in-
not made or distributed for profit or commercial advantage and that copies cluded in the emerging standards, characterizing the attack
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
models and security threats, as well as devising technical
permission and/or a fee. and specific protection guidelines to further secure cyber-
DAC 2012, June 3-7, 2012, San Francisco, California, USA. cars. Independent of the cybercar security initiatives, the
Copyright 2012 ACM 978-1-4503-1199-1/12/06 ...$10.00.

220
 2. PRELIMINARIES
Before we delve into more detailed discussions of cybercars
security and the pertinent challenges and opportunities, we
briefly outline a typical cybercar system architecture and
some key evolving standards.
Cybercar system architecture. The term cybercar refers
to a generation of vehicles that are fully connected to their
surrounding objects, environments, and networks. A cyber-
car is part of an ecosystem where it could either play the
role of a content or a service provider in addition to express-
ing content and determining applications. Thus, a cybercar
can be described as a sophisticated mobile device. As it is
connected to external entities, the cybercar has the possibil-
ity to rely on outside computing resources, externally avail-
able data, and services. For instance, a cybercar without
the proper sensors could still run driving assistance applica-
tions with the help of a smartphone and a cloud connection.
Figure 1: Intelligent Transport Systems. Source: A cybercar may also provide services to connected entities.
www.etsi.org Cybercars are composed of following domains: (i) the in-car
system with the network and the car components, (ii) com-
munication interfaces to external communication partners,
(iii) communications partners represent by external devices,
cars, infrastructure or cloud. Figure 2 represents an example
EDA and embedded systems communities have been work- of a cybercar system architecture.
ing for years on problems pertaining to modeling, analysis,
Emerging automotive standards. With some exceptions
simulation, and automation of complex vehicular networked
[4, 2], automotive standards are only regionally accepted,
embedded systems. Such methods are required not only to
which might be due to the role of the legislation and the in-
ensure design time predictability and composability, but also
fluence of regional automotive industry. However, the AU-
for architecture selection and design-space exploration [48].
TOSTAR experience has shown that the global participation
The complexity of the modern cybercar’s networked em-
of automotive manufacturers and suppliers coming from dif-
bedded systems, its various interfaces to external entities,
ferent countries in the specification process, is a key to the
together with the scope of emerging attacks, supersedes
global acceptance of standards [4].
present knowledge and capabilities pertaining to both lines
With the emergence of cybercars and the requirement
of efforts in vehicular security and in embedded system com-
of global acceptance, the automotive industry has created
munities. The evolving nature of the system complexity and
different consortiums to support the specification of stan-
attack possibilities suggests that a continuous flow of re-
dards for ITS. Examples are the GENIVI alliance, the Car
search and development is needed before cybercar systems
Connectivity Consortium and the Car2Car Consortium [7,
can be efficiently designed, and safely/securely operated.
13, 55], where the first two are driving the specification
The situation with cybercars today is similar to the evolu-
of an in-vehicle infotainment platform with different con-
tion of personal computing and networked communication in
nectivity technologies. The Car2Car Consortium coordi-
the past several decades: One can make an analogy between
nates different investigation results on communication and
connecting individual cars to external objects/networks and
system architectures for car-to-car and car-to-infrastructure
linking personal computers to the Internet. Since the In-
communication. The resulting specifications are provided
ternet was not originally designed with an explicit set of
to standardization bodies. The Sevecom and the EVITA
security objectives, connected computers still suffer from a
projects are examples of unclassified funded projects [20,
range of attacks that could be largely avoided by correct-
51] that have significantly influenced standardization bod-
by-construction methodologies. Due to safety criticality and
ies like the ETSI and the Communication Access for Land
the vital role of vehicular and transportation systems in per-
Mobiles (CALM) [6, 5].
sonal, business, government, and economic affairs, leaving
Typical goals of the automotive industry are guaranteeing
security as an afterthought is disadvantageous. However,
interoperability, reliability, dependability and quality. Secu-
since legacy protocols and hardware take a long time to
rity has not been a major concern. Hence, standards for the
change, for present and pending cybercar generations, se-
car components and networks have been specified with very
curity afterthoughts maybe the only practicable choice.
limited security requirements. The integration of IT in cars
This perspective article calls for development of novel
and recent attacks on cars has led to a change of this view
holistic but systematic EDA methodologies and tools that
[12]. As a result, the security has been integrated both in cy-
simultaneously ensure a robust and secure cybercar design
bercar related standardization activities and in established
flow. The important architecture-evaluation, design, and
specifications such as AUTOSAR, with the introduction of
evaluation process phases need to be automatically aug-
cryptographic interfaces [4]. There is still a need to analyze
mented with security primitives and flows as defined by ris-
the overall impact of new technologies emerging on the au-
ing standards and protection measures. The challenges for
tomotive process, development, and tool chain, and the role
realizing such a holistic and systematic automated cybercar
of security.
security approach are abundant, but so are the research and
development opportunities.

221
 ∙ Automotive components have resource constraints, e.g.,
limited memory, processing, or number of sensors.
∙ Automotive networks are insecure and have limited
throughput with strict latency requirements.
∙ Automotive components must be cost effective. Security
must be integrated without a high cost overhead.
∙ The lifecycle of the automotive industry is up to 20 years.
Solutions should be capable to hold for a long time.
∙ Safety critical applications have realtime constraints.
Security should not disable the safety function.
∙ Interference exists between safety and entertainment
applications on the infotainment platforms.

In-vehicle security. It seems that there is still no concrete

plan to change the specification of the most used automotive
bus protocol, the Controller Area Network (CAN) protocol.
In fact, CAN is deployed in billions of cars, industry ma-
chines and aircrafts. A specification change would impact
the complete development and supply chain within the au-
tomotive industry. With CAN being the most used protocol
for safety critical applications, it has been the most attrac-
Figure 2: Cybercar System Architecture. tive protocol for attackers [27, 26, 37, 31, 12]. The challenge
is to embed security in the CAN protocol and ensure that
the safety applications are not affected by the changes.
3. CYBERCAR SECURITY CHALLENGES While the CAN specification cannot be changed, using the
fields of the CAN frames is a plausible alternative to embed
3.1 Threats authentication and data integrity. Today’s constraints on
The automobile industry has traditionally focused on pro- car applications (e.g., fault tolerance times of about 100ms,
viding safety and reliability, under the assumption that a message sizes of approximately 2-4 bytes, and asymmetry
vehicle is an isolated system which is not accessible to adver- in the available performance in the different modules) re-
saries [35], leading to the design of insecure car components quires the use of efficient cryptography algorithms to fulfill
and bus systems. Several successful attack scenarios have authentication and integrity goals. Thus, researchers have
invalidated traditional models for cybercar security [26, 37, proposed to use a truncated Message Authentication Code
43, 11, 19, 31, 12, 56]. The vulnerabilities are exasperated (MAC) added in the payload of the CAN frames [50, 37].
by poor implementation of protocols and firmware [30, 39]. This approach can be improved if one considers the error de-
The growing connectivity of modern cybercars escalates the tection attributes of MACs. In the CAN specifications, two
range of potential exploits [42, 29, 18]. The existing weak- bytes are reserved for the Cyclic Redundancy Check (CRC)
nesses in the automotive domain can be classified as follows: which the MAC uses. The potential of the combination of
MAC and error correcting codes could be investigated as a
∙ Threats caused by physical access, e.g., by connecting measure to provide safety and security.
to the in-car network through the on-board diagnostic
interface, or the in-vehicle network cables. Car-to-X (a.k.a., Car2X) Security and Privacy. The
∙ Vulnerabilities due to access via infotainment, which in- success of Car2X applications depends on their penetration
troduce the possibility to manipulate cars using multimedia in the car market. Current cars will have to be upgraded for
interfaces, e.g., by disabling safety functions. car-2o-X communications. Car2X systems will have to be
∙ Exposures due to the remote access, which describe the compatible in terms of messages formats, communications
possibility to manipulate cars using wireless interfaces. technologies, and security, among other requirements. More-
over, applications will have to react in realtime for safety
Exploiting such vulnerabilities may even enable the com- critical tasks. An example of a Car2X application is an
plete remote control of a car by an attacker, who might pos- active brake, where a car brakes based on a warning mes-
sess the expertise to gain access to the in-vehicle network sage received from an external communication. This task
using the on-board diagnostic interfaces or the multimedia requires an instant brake manoeuver with a maximum de-
interfaces (e.g., USB connection, Bluetooth connection or lay of 250ms [21]. In 250ms the car will have to perform
media players). Such an adversary could remotely disable plausibility checks on the message content, and verify the
brakes or manipulate sensor values using typical attacks such authentication and integrity of the message. The challenges
as eavesdropping, dropping, modification, spoofing, injec- can be summarized in the following key words: Upgrade-
tion, or message replay on the bus system [43, 12]. ability of car systems, compatibility, realtime performance,
trustworthiness, and privacy.
The fact that cybercars may need to deal with huge num-
3.2 Challenges ber of signature verifications per second enforces the use of
The security and dependability challenges of cybercars hardware accelerators to cope with the high computation
are closely related to the general engineering challenges of requirements for authentication and integrity verifications
cars and the current state of car networks. These challenges (e.g., of up to 4000 per second [49]). EVITA has made a
include,

222
proposal for such a hardware accelerator enhanced with se- 4.1 Model-based automotive security
curity features [57]. However, this module still has to be Vehicular system integration has been traditionally done
integrated in available architectures [51, 41, 6, 5] to provide based on black-box integrated subsystems along with orig-
a security architecture covering the security requirements of inal equipment manufacturer’s high-level specifications and
Car2X applications [22]. With the high density of Car2X overall performance metrics. The design flow has to be en-
communications, the common approach is to use public key hanced to better model the secure cybercar system structure
infrastructure to manage the high number of required keys. and interactions, possibly through refined diagrams consist-
An example of a public key infrastructure is proposed in ing of block entities linked by interconnects and flows, which
[10]. One important and still open issue is the owner’s pri- specify a topology and variables for communication among
vacy protection. The project Sevecom proposed the use of the blocks. A block may represent a logical or physical com-
short term credentials (e.g., certificates), that are period- ponent, e.g., a hardware or software part, often either rep-
ically changed by the car users [51]. Nevertheless, other resenting an abstraction of the full component description
layers in the communication stack may still send sensitive or a characterization of the component interface [44, 16, 15].
private information such as vehicle position. Like any other proper abstraction, neither description nor
Secure integration at the infotainment platform. Re- interface should contain more information than necessary to
cent attacks have demonstrated that the integration sur- realize or connect the components. Let us more carefully in-
faces at the infotainment platform (head unit) like the me- vestigate the design requirements and security demands for
dia players or Bluetooth are insecure [12]. The head unit components and interfaces.
typically runs three types of applications: applications with Component-models and abstractions. In order to meet
no access rights to the in-vehicle domains, applications with the stringent time-to-market constraints, the reuse-based
read access such as diagnostic tasks, and applications with paradigms are a standard practice in design and implemen-
read/write access such as firmware updates. Read access al- tation of complex automotive network embedded systems.
lows collecting privacy-sensitive data, such as location data, Stand-alone component models are typically available and if
fuel consumption, and the vehicle identification number not, they are attainable at the proper level of abstraction by
(VIN), which can result in creation of driver profiles. The the original IP owners or manufacturers. However, one has
reuse of such profiles could be interesting for businesses, e.g., to pay a special attention to component models, especially
insurance companies. Write access allows the control of the those for the reusable ready blocks, since their functionality
car which could potentially cause fatalities. The head unit may not be static; their behavior has to be considered in the
may run applications with different access rights in parallel, context of complex dynamic interactions with other system
which could lead to confused deputy attacks [25]. Present components and environmental/user variables.
efforts to isolate the different types of applications are done Abstraction of the electronic components has tradition-
in the GENIVI consortium but currently seem to rely on ally been an integral part of EDA methods and tools. How-
desktop standard approaches of virtualization [7] and do not ever, the Cyber-Physical nature of cybercar networked em-
address the unique issues of transportation systems, which bedded systems requires adding a totally new dimension to
is related to the safety of system users. the component modeling and abstraction. Essentially, there
is a need to model and abstract the non-electronic compo-
nents which include the mechanical parts and user inputs. In
4. EDA CHALLENGES AND OPPORTUNI- the development of such models and abstractions, challenges
arise due to the inherent continuous and analog nature of
TIES the underlying components, which are far from discrete and
Unless security is integrated within the automotive elec- (often) binary form of well-known digital or logical abstrac-
tronics and communication design flows, cybercars will be tions. Attacks based on exploiting the component vulner-
vulnerable to several nefarious attacks. The scope of the po- abilities that infiltrate the electronic components, the me-
tential exploits is likely much more sophisticated than what chanical parts, or the user inputs can be envisioned. Finding
has been demonstrated thus far in simulations or in limited the proper level of component abstraction that also captures
practical experiments. The design, realization, and valida- such potential exposures is a major challenge.
tion of complex networked embedded systems for automo-
Interface-based design for security. Designers com-
tive applications is already a standing challenge, even before
monly make assumptions about the environment where the
the security demands are considered [48]. Security require-
component will be employed, or the pairwise interactions be-
ments have to be carefully recognized and implemented at
tween the components. Such descriptions can also be a part
each complex step of modeling, simulation, end-to-end de-
of the interface specifications. Abstracting the component
sign, and implementation of the cybercar systems.
security requirements brings upon yet another dimension to
Due to the rising complexity and scale of automotive func-
the already sophisticated environmental models and inter-
tionalities, networks, interactions, and the supply chain,
actions among the underlying parts developed by disparate
stand alone or adhoc protective solutions have a very lim-
entities. Such secure interface-based models should support
ited effectiveness. Novel EDA methodologies and tools are
compositional refinement as well as different degrees of com-
required for scalable automated security modeling, integra-
ponent abstractions. A model-based approach may profile
tion, verification, checking, and analysis of the cybercar
secure control and dataflow task requirements in a graphical
complex systems.
language amenable to graph-theoretic analysis.
In the remainder of this section, we outline some of the
According to the recent analyses of automotive security
EDA challenges that have to be overcome in order to realize
attacks in [12], virtually all exploits outlined in their prac-
secure cybercars and highlight the great research opportu-
tical experiments, emerged at the interface between codes
nities in this field.

223
written by distinct organizations. A significant advantage Time-triggered communications could allow for better iso-
of developing sound and proper component and secure in- lation between security sensitive tasks and non-critical ap-
terface abstractions is that they can be together used as a plications; they are also better suited for distributed control
precursor to formal verification and correct-by-construction applications. However, time-triggered protocols are still far
designs. Components and interfaces which expose protocol from providing a comprehensive security measure. For ex-
information about component interactions or secure protocol ample, a denial of service attack targeted at fixed time slots
information can be naturally expressed in an automation- could result in significant loss of bandwidth and even in the
based language. A great introduction to such interface au- worst-case, failure in meeting realtime constraints. Thus,
tomata and interface languages are outlined in [16, 15]. They along with isolation, attack models as well as proactive and
have shown that several aspects of interface models, includ- reactive measures to secure against attacks, must be inte-
ing compatibility and refinement checking for interface in- grated within the system timing analysis framework.
teractions can be viewed in a game-theoretic framework. Note that isolation for security may be done by the soft-
ware control layer interface standards for both priority-based
and time-based scheduling policies. For example the AU-
4.2 Temporal models and constraints TOSTAR software standard description allows isolation of
Automotive control systems including the ECUs have tra- timing error for one IP from the other IPs interacting with
ditionally been designed for real-time operations. For exam- it. Since such additions may lead to timing violations, a
ple, the CAN protocol implements a deterministic algorithm layer in the standard is aimed at addressing performance
and assigns priorities to messages. Assuming a fault-free and delay violations. In a complex control software interac-
operation and predictable task times, the worst-case timing tions could generate timing dependencies because of schedul-
behavior of such a system can be estimated. However, it has ing conflicts, synchronization issues, or buffering. If correct
been shown that especially in presence of small changes in timing models and abstractions are available, it is possible
the temporal parameters, there are points of discontinuity to set up a simulation tool which can model the behavior of
in the system where the increased number of preemptions tasks and their interactions in a complex environments. An
adds the execution of one or more tasks to the execution interface-based design methodology could also be used for
time [48]. This situation is exacerbated for larger and more addressing the security challenges.
sophisticated interactions which in turn limit the usefulness
of such predictive models. 4.3 End-to-end secure & reliable integration
Priority-based scheduling and security. Practical imple- An end-to-end design of secure cybercars requires a com-
mentations of security often require a nontrivial overhead bination of security requirements along with functional mod-
on the plaintext processing and tasks such as ciphertext els and abstractions of the architecture and hardware plat-
decryption. The complexity would be even worse if keys forms. Novel system-level security abstractions and analysis
must be established with external entities, such as on-the-fly not only guide partitioning and separation of concerns at the
Car2X communications which require public key protocols. design time, but also accommodate an efficient exploration
Priority-based scheduling such as the one implemented by of the complex design space in early design phases. Such
CAN, has very high worst-case latency and discrepancy be- abstractions could lead to a significant increase in efficiency
tween the best- and worst- case system timing behavior in of performance, reliability, delay, and implementation cost
the presence of faults or jitters. In particular, a drawback of of the security solutions. We advocate the use of platform-
priority-based resource scheduling is sensitivity to high pri- based designs along with our suggested security flow models
ority computation or communication flows that can easily and simulation tools for addressing the sophisticated end-
take control of the interface or the ECU in order to steal to-end system security requirements.
time from lower priority tasks. An intelligent attacker could Platform-based design for secure architecture selec-
use this sensitivity to attack the system timing and to vio- tion. Platform-based design [47, 46] is based upon explicitly
late the system’s timing constraints through fault injection characterized layers of abstraction and a design interface be-
in high priority applications. tween the behavioral specifications and abstractions of possi-
Additional control layers might be able to avoid the tim- ble implementation platforms. Therefore, this methodology
ing faults and could improve the security, but significantly decouples application-layer software from variations in the
add to the system overhead. Added control layers may very underlying hardware. By decoupling these two components,
well lead to violations of end-to-end real-time constraints the same applications are permitted to run across several
for priority-based schedules, which should be included in vehicle platforms without modifications. Once security is
the system-level models discussed in Section 4.3. abstracted at the proper level, e.g., using the flow model
Isolation of safety-critical and security sensitive tasks described in Section 4.1, one would be able to use platform-
by time-based scheduling. Time-based schedulers such as based design principals and tools for system optimization.
those supported by the FlexRay enforce assignment of the Essentially, the platform interface and the security require-
communication bus at predefined time slots and are not al- ments should be independent and isolated from lower-level
ways sensitive to system load requests [40]. For example, in architecture details, while simultaneously allowing design-
FlexRay a cycle is divided into up to four segments: static, space exploration with a good predictions of the properties
dynamic, symbol, and nit. The static part is strictly re- for the system realization.
served for transmission of time-critical messages which have The design-space-exploration finds the secure system’s op-
a fixed length time slot for each node. The dynamic interval timal mapping into a platform candidate instance. There is
is reserved for non-critical messages with more robust tim- a need to develop new methods and tools that can provide
ing requirements. The arbitration among the less critical a measure of the appropriateness of a particular architec-
messages is based on priorities similar to CAN. ture solution for optimizing performance metrics while also

224
satisfying various performance constraints. secure sessions, are available in a standard format. To ensure
Iterative synthesis for security. To find a good opti- robustness of interfaces against potential adversaries, imple-
mization solution in the large space of possibilities, often mentation of such protocols within the system’s realtime
an iterative approach is taken by the EDA community [17]. constraint is necessary; this may lead to requiring hardware
Such an iterative approach is suitable for the complex map- acceleration. Once security community spends the time and
ping between the space of security parameters/flows and the effort to develop security protocols, new SRC tools must be
hardware platform. After a set of end-to-end design/security developed accordingly to ensure a correct implementation.
metrics and constraints are specified, a set of initial candi- Continuous attack analysis and countermeasure de-
date configurations for the platform architecture are then velopment. The attacks targeted at cybercars will likely
determined. The candidates are then analyzed and com- not be static and will evolve over time, as it is the case with
pared for fitting to the design goals and security objectives. other computer and network attacks. As researchers and
If the results are not up to expectations, alternative sets of practitioners devise new security primitives, rules, and pro-
platform architectures are iteratively evaluated. tocols, adversaries could simultaneously find new holes in the
Automated robust secure software design. Iterative system or its implementation. As the protection protocols
synthesis and analysis results typically guide the selection and security methods become more advanced, the attacks
of the next set of candidate architectures to evaluate. The will become more sophisticated. There is a need to continu-
analysis include evaluation of delay properties, timing sensi- ously and dynamically monitor for potential vulnerabilities
tivity, faults, security, and cost. In the cybercar distributed and attacks. Once instances of attacks are observed, the cor-
ECU environment, software architecture and mapping can responding countermeasures should be implemented within
become rather complex. There is an intermediate layer be- the system. Software patches and anti-virus software should
tween the specified function and the underlying architecture be continually updated to limit the spread of any exploits.
which is often implemented in software for flexibility reasons. Online tests for detection of possible exploits should also be
Such tools can be automated to select the best combination implemented and enforced in the cybercar systems.
of timing, security, and performance constraints. Counterfeit detection. Since counterfeits provide physi-
Counterfeit parts prevention. A possible set of attacks cal access to the system, malicious fake devices could po-
can be launched by the counterfeit automotive parts that tentially launch efficient attacks. They may be Trojans that
are prevalent in the market. The car owners’ incentive in spy information to the outside world or disrupt the system’s
buying the fake parts is mostly driven by economics. Coun- functionality on a trigger event. Even when the counter-
terfeit car electronics not only often have various reliability feit parts are not intentionally malicious, they introduce a
problems, they could also allow for several nefarious attacks high risk to the system reliability [33]. This is because the
such as Trojan embedding [1, 53]. While legal measures counterfeit components are often lower quality grades, or
could potentially suppress the rising problem of fake auto- recycled old ICs. Therefore, the system designers must au-
motive components, they have not been effective in practice. tomatically embed means for testing and detecting the dis-
This is largely because of the long and hard-to-track supply crepancy and unreliability of the system components, and
chain of fake components, the improved appearance of the for monitoring/detecting the Trojan components.
cloned components, lack of sufficient reliability and security Development of cybercar security benchmarks. Like
tests for the fake parts, and the black market nature of the other areas of EDA and testing, it is necessary to create
fake parts suppliers [3, 33]. benchmarks and platforms in order to evaluate and compare
Development of methods for unclonable and secure iden- the competing methodologies. A flurry of research activities
tification of devices are very relevant for addressing these are being directed towards addressing the known and poten-
challenges [24, 36, 8, 45, 32]. Devising possible measures to tial vulnerabilities of cybercar systems. There is a need to
disable a system when a fake component is identified, are of understand the effectiveness and limitations of each method.
great interest. For cases where the exact functional descrip- This will not be only used as an evaluation tool, but also
tion of an electronic part is unknown or a part cannot be would help in standardization of the best methodologies and
found because of its obsoleteness, one may need to reverse tools. Effective security benchmark development requires
engineer the functionality. Thus, research and developments outlining the taxonomy and details of the attacks, as well
in functional reverse-engineering, and in formal functional as research and experiments which realistic but challenging
verification are important for preventing counterfeits. hard-to-address attack instances.

4.4 Security validation and testing 5. CONCLUSION

System security models and exact characterization of at- Tight integration of networked computation and physical
tacks are both necessary steps for proactively or reactively components in safety-critical modern automotive environ-
protecting against pertinent vulnerabilities. ments and applications (cybercars) makes them exception-
Rule checking for secure implementation correctness. ally vulnerable to security attacks, as confirmed by a number
There is a need for methods that define and express Security of recent studies. The evolving nature of the complexity of
Rule Checks (SRC) based on a set of protection primitives cybercar systems and the severity of possible attacks suggest
and security protocols at the proper abstraction layer, e.g., integration of security within the embedded system design
at the control and data flow vulnerable interface levels [12]. flow. This perspective article highlights the importance of
The SRC can be used to enforce unimplemented constraints developing novel holistic and systematic EDA methodolo-
of the existing protocols which may not be always in effect, gies and tools that simultaneously ensure a robust and se-
as suggested in [31]. Many widely-used strong protection cure cybercar design flow. We discussed the challenges and
protocols, including those for access control, encryption, or opportunities in realizing our proposed vision.

225
APPENDIX tions for addressing some of the known vulnerabilities.
With the exception of the wireless access experiment in
A. RELATED LITERATURE [43], most of the attacks described thus far assume the ad-
Modern vehicular technology is typically comprised of sev- versary has physical access to the car’s internal network.
eral intercommunicating electronic and software components More recent work in [12] provided a systematic synthesis of
that enable ever-increasing flexibility, efficiency, safety, and possible attack vectors at three modalities: indirect physical
a myriad of new and exciting functionalities [14]. While au- access, short-range wireless access, and long-range wireless
tomotive systems, standards, functions, and components are access. For each modality, the authors reported the prac-
almost always devised to satisfy strict safety and reliability ticality of exploitable vulnerabilities, allowing unauthorized
constraints, requirements for security and protection of the control without the need for physical access. They further
pertinent components and functions have not yet been im- demonstrated a number of post-compromise control chan-
plemented. Therefore, concerns over the potential risks and nels that could act like a remotely controllable Trojan. Ca-
vulnerabilities of this complex networked environment were pabilities of theft and surveillance were also shown. A set
expressed at a high level [59, 39, 58, 34, 35, 54]. Such worries of high-level recommendations for raising the security bar
have been exacerbated by the emergence of newer car-to-X were subsequently suggested. We believe that these efforts
technologies [42, 29]. are a precursor to future research and developments as we
The EVITA project took the first fundamental step to- are still far from fully secure and protected cybercars.
wards addressing the rising concerns about the security of
modern cars. The project identified a list of automotive use B. REFERENCES
cases with a security impact that could be potentially mis- [1] Defense science board (DSB) study on high
used [21]. It also developed a security and trust model for performance microchip supply.
modern vehicles along with attack scenarios [22]. To address http://www.acq.osd.mil/dsb/reports/2005-02-
identified vulnerabilities, a set of high level requirements hpms report final.pdf.
along with concrete technical recommendations have been [2] ASAM: Association for standardisation of automation
proposed [23]. Architecture solutions that could address the and measuring systems. http://www.asam.net.
identified vulnerabilities were subsequently suggested and
[3] Defense industrial base assessment: Counterfeit
prototyped in hardware.
electronics. Technical report, U.S. Department Of
A majority of the reported attacks have been targeted
Commerce, Bureau Of Industry And Security, Office
at the Control Area Network (CAN) protocol. Attacks on
Of Technology Evaluation, 2010.
simulation models of CAN were suggested in [26, 38]; the
first implementation on a real car was demonstrated in [27], [4] AUTOSAR automotive open software architecture
where the researchers performed several practical tests on specification. http://www.autosar.org, 2012.
the CAN network and demonstrated their vulnerabilities. [5] CALM communications access for land mobiles.
The demonstrated attacks included controlling the windows, http://calm.its-standards.eu/, 2012.
lights, and airbag systems. Later, they discussed CAN pri- [6] ETSI TC ITS standards european
vacy violation issues [28]. telecommunications standards institute.
The authors in [43] performed an analysis of the Wire- http://www.etsi.org, 2012.
less Tire Pressure System (TPMS) in a modern automobile. [7] G. Alliance. Genivi. http://www.genivi.org/, 2009.
They outlined methods to manipulate drivers by spoofing [8] F. Armknecht, R. Maes, A.-R. Sadeghi, F.-X.
the faulty tire pressure measurements. The tire pressure val- Standaert, and C. Wachsmann. A formalization of the
ues are typically sent from the tire pressure wireless sensor to security features of physical functions. In IEEE
the ECU managing the TPMS data. The authors were able Symposium on Security and Privacy, pages 397–412,
to send wrong values to stop the functionality of the ECU 2011.
managing the TPSM data. Note that our focus in this work [9] A. Barisani and D. Bianco. Unusual car navigation
is on the intrusions at the network level that are orthogonal tricks. In CanSecWest, April 2007.
to the practical demonstration of attacks on single-device [10] N. Bissmeyer, H. Stuebing, E. Schoch, S. Götz, J. P.
vehicle access control mechanisms such as those targeting Stotz, and B. Lonc. A generic Public Key
the keyless entry system [19] and vehicle immobilizers [11]. Infrastructure for securing Car-to-X Communication.
A more comprehensive practical security analysis of the In 18th ITS World Congress, Orlando, USA, Oct.
CAN vulnerabilities was later demonstrated in [31], where 2011.
cars’ components were tested in isolation in a lab, in con- [11] S. C. Bono, M. Green, A. Stubblefield, A. Juels, A. D.
trolled settings, and in live road tests. Their attacks con- Rubin, and M. Szydlo. Security analysis of a
firm that an attacker infiltrating any ECU in the CAN net- cryptographically-enabled RFID device. In USENIX
work could circumvent a large array of of automotive func- Security Symposium, pages 1–16, 2005.
tions while ignoring the driver inputs. The attacks included [12] S. Checkoway, D. McCoy, B. Kantor, D. Anderson,
safety critical tasks such as break disabling, engine halting, H. Shacham, S. Savage, K. Koscher, A. Czeskis,
and light control. Other less critical but vulnerable mod- F. Roesner, and T. Kohno. Comprehensive
ules were heating and cooling, infotainment, and instrument experimental analyses of automotive attack surfaces.
panels. Their findings show the extent of potential damages In USENIX Security Symposium, 2011.
from the existing security holes, ease of attacks, weakness
[13] C. C. Consortium. Mirror link.
of contemporary vehicular access control, and the ability to
http://www.terminalmode.org/, 2010.
delete the traces of infiltration by the attackers. Lastly, they
[14] J. Cook, I. Kolmanovsky, D. McNamara, E. Nelson,
explore considerations and future possible high-level direc-
and K. Prasad. Control, computing and

226
 communications: Technologies for the twenty-first [29] F. Kargl, P. Papadimitratos, L. Buttyan, M. Muter,
century model T. Proceedings of the IEEE, 95(2):334 E. Schoch, B. Wiedersheim, T.-V. Thong,
–355, 2007. G. Calandriello, A. Held, A. Kung, and J.-P. Hubaux.
[15] L. de Alfaro and T. Henzinger. Interface theories for Secure vehicular communication systems:
component-based design. In T. Henzinger and implementation, performance, and research challenges.
C. Kirsch, editors, Embedded Software, volume 2211 of IEEE Communications Magazine, 46(11):110–118,
Lecture Notes in Computer Science, pages 148–165. 2008.
Springer Berlin / Heidelberg, 2001. [30] P. Kleberger, T. Olovsson, and E. Jonsson. Security
[16] L. de Alfaro and T. Henzinger. Interface-based design. aspects of the in-vehicle network in the connected car.
In M. Broy, J. Grünbauer, D. Harel, and T. Hoare, In IEEE Intelligent Vehicles Symposium (IV), pages
editors, Engineering Theories of Software Intensive 528 –533, 2011.
Systems, volume 195 of NATO Science Series, pages [31] K. Koscher, A. Czeskis, F. Roesner, S. Patel,
83–104. Springer Netherlands, 2005. T. Kohno, S. Checkoway, D. McCoy, B. Kantor,
[17] G. De Micheli. Synthesis and Optimization of Digital D. Anderson, H. Shacham, and S. Savage.
Circuits. McGraw-Hill Higher Education, 1st edition, Experimental security analysis of a modern
1994. automobile. In IEEE Symposium on Security and
[18] F. Dressler, F. Kargl, J. Ott, O. Tonguz, and Privacy (S& P), pages 447–462, 2010.
L. Wischhof. Research challenges in intervehicular [32] F. Koushanfar. Provably secure active ic metering
communication: lessons of the 2010 dagstuhl seminar. techniques for piracy avoidance and digital rights
Communications Magazine, IEEE, 49(5):158 –164, management. IEEE Transactions on Information
2011. Forensics and Security, 7(1):51–63, 2012.
[19] T. Eisenbarth, T. Kasper, A. Moradi, C. Paar, [33] F. Koushanfar, S. Fazzari, C. McCants, W. Bryson,
M. Salmasizadeh, and M. T. M. Shalmani. On the M. Sale, P. Song, and M. Potkonjak. Can EDA
power of power analysis in the real world: A complete combat the rise of electronic counterfeiting? In Design
break of the keeloqcode hopping scheme. In CRYPTO, Automation Conference (DAC), 2012.
pages 203–220, 2008. [34] A. Lang, J. Dittmann, S. Kiltz, and T. Hoppe. Future
[20] EVITA Consortium. The EVITA project: E-safety perspectives: The car and its IP-address - a potential
vehicle intrusion protected applications, 2011. safety and security risk assessment. In International
http://www.evita-project.org. Conference Computer Safety, Reliability, and Security
[21] The EVITA project Deliverable 2.1, (SAFECOMP), pages 40–53, 2007.
http://evita-project.org/deliverables.html. [35] U. E. Larson and D. K. Nilsson. Securing vehicles
Specification and evaluation of e-security relevant use against cyber attacks. In Cyber Security and
cases, 2009. Information Intelligence Research Workshop
[22] The EVITA project Deliverable 2.3, (CSIIRW), pages 30:1–30:3, 2008.
http://evita-project.org/deliverables.html. Security [36] M. Majzoobi, F. Koushanfar, and M. Potkonjak.
requirements for automotive on-board networks based Lightweight secure PUFs. In International Conference
on dark-side scenarios, 2009. on Computer-Aided Design (ICCAD), pages 670–673,
[23] The EVITA project Deliverable 3.1, 2008.
http://evita-project.org/deliverables.html. Security [37] D. K. Nilsson, U. Larson, and E. Jonsson. Efficient
and trust model, 2009. in-vehicle delayed data authentication based on
[24] B. Gassend, D. Clarke, M. van Dijk, and S. Devadas. compound message authentication codes. In VTC
Silicon physical random functions. In ACM Computer Fall’08, pages 1–5, 2008.
and Communications Security Conference (CCS), [38] D. K. Nilsson and U. E. Larson. Simulated attacks on
pages 148–160, 2002. CAN buses: vehicle virus. In IASTED International
[25] N. Hardy. The confused deputy (or why capabilities Conference on Communication Systems and Networks
might have been invented). Operating Systems Review, (AsiaCSN), pages 66–72, 2008.
22(4):36–38, 1988. [39] C. Paar, A. Weimerskirch, and M. Wolf. Security in
[26] T. Hoppe and J. Dittman. Sniffing/replay attacks on automotive bus systems. In Embedded Security in Cars
CAN buses: A simulated attack on the electric Workshop, 2004.
window lift classified using an adapted CERT [40] T. Pop, P. Pop, P. Eles, Z. Peng, and A. Andrei.
taxonomy. In Workshop on Embedded Systems Timing analysis of the FlexRay communication
Security (WESS), 2007. protocol. In Euromicro Conference on Real-Time
[27] T. Hoppe, S. Kiltz, and J. Dittmann. Security threats Systems, pages 203–216, 2006.
to automotive CAN networks - practical examples and [41] PRESERVE Consortium. Preparing secure
selected short-term countermeasures. In Computer vehicle-to-x communication systems, 2011.
Safety, Reliability, and Security (SAFECOMP), pages http://www.preserve-project.eu.
235–248, 2008. [42] M. Raya, P. Papadimitratos, and J.-P. Hubaux.
[28] T. Hoppe, S. Kiltz, and J. Dittmann. Automotive Securing vehicular communications. IEEE Wireless
IT-security as a challenge: Basic attacks from the Communications,, 13(5):8–15, 2006.
black box perspective on the example of privacy [43] I. Rouf, R. Miller, H. Mustafa, T. Taylor, S. Oh,
threats. In Computer Safety, Reliability, and Security W. Xu, M. Gruteser, W. Trappe, and I. Seskar.
(SAFECOMP), pages 145–158, 2009. Security and privacy vulnerabilities of in-car wireless

227
 networks: a tire pressure monitoring system case
study. In USENIX Security Symposium, 2010.
[44] J. Rowson and A. Sangiovanni-Vincentelli.
Interface-based design. In Design Automation
Conference (DAC), pages 178–183, 1997.
[45] U. Ruhrmair, S. Devadas, and F. Koushanfar. Security
based on Physical Unclonability and Disorder, Book
Chapter in ‘Introduction to Hardware Security and
Trust’. Springer, 2011.
[46] A. L. Sangiovanni-Vincentelli. Defining platform-based
design. EE Times, Feb 2007.
[47] A. L. Sangiovanni-Vincentelli. Quo Vadis, SLD?
reasoning about the trends and challenges of system
level design. Proceedings of the IEEE, 95(3):467 –506,
2007.
[48] A. L. Sangiovanni-Vincentelli and M. Di Natale.
Embedded system design for automotive applications.
IEEE Computer, 40(10):42–51, 2007.
[49] E. Schoch and F. Kargl. On the efficiency of secure
beaconing in vanets. In Proceedings of the third ACM
conference on Wireless network security (WiSec),
pages 111–116, 2010.
[50] H. Schweppe, M. Idrees, Y. Roudier, B. Weyl,
R. El Khayari, O. Henniger, D. Scheuermann,
G. Pedroza, L. Apvrille, H. Seudié, H. Platzdasch, and
M. Sall. Secure on-board protocols specification.
Technical Report Deliverable D3.3, EVITA Project,
2010.
[51] SEVECOM Consortium. Secure vehicular
communication, 2008. http://www.sevecom.org.
[52] SIMTD Consortium. Sichere intelligente mobilität
testfeld deutschland, 2011.
[53] M. Tehranipoor and F. Koushanfar. A survey of
hardware trojan taxonomy and detection. IEEE
Design & Test of Computers, 27(1):10–25, 2010.
[54] P. R. Thorn and C. A. MacCarley. A spy under the
hood: Controlling risk and automotive EDR. In Risk
Management, 2008.
[55] C. to Car Communication Consortium. Car to Car
Communication Consortium.
http://www.car-to-car.org/, 2006.
[56] VDAT. Der deutsche tuningmarkt. http:
//www.vdat.org/tuningmarkt_deutschland.php/,
2010.
[57] B. Weyl, M. Wolf, F. Zweers, T. Gendrullis, M. Idrees,
Y. Roudier, H. Schweppe, H. Platzdasch,
R. El Khayari, O. Henniger, D. Scheuermann,
A. Fuchs, L. Apvrille, G. Pedroza, H. Seudié,
J. Shokrollahi, and A. Keil. Secure on-board
architecture specification. Technical Report
Deliverable D3.2, EVITA Project, 2010.
[58] M. Wolf, A. Weimerskirch, and T. J. Wollinger. State
of the art: Embedding security in vehicles. EURASIP
Journal of Embedded Systems, 2007.
[59] Y. Zhao. Telematics: safe and fun driving. IEEE
Intelligent Systems, 17(1):10–14, jan/feb 2002.

228