Conference PaperPDF Available

A Car Hacking Experiment: When Connectivity Meets Vulnerability


Abstract and Figures

Interconnected vehicles are a growing commodity providing remote access to on-board sys- tems for monitoring and controlling the state of the ve- hicle. Such features are built to facilitate and strengthen the owner’s knowledge about its car but at the same time they impact its safety and security. Vehicles are not ready to be fully connected as various attacks are currently possible against their control systems. In this paper, we analyse possible attack scenarios on a recently released all-electric car and investigate their impact on real life driving scenarios. We leverage our findings to change the behaviour of safety critical com- ponents of the vehicle in order to achieve autonomous driving using an Open Vehicle Monitoring System. Furthermore, to demonstrate the potential of our setup, we developed a novel mobile application able to control such vehicle systems remotely through the Internet. We challenge the current state-of-the-art technology in today’s vehicles and provide a vulnerability analysis on modern embedded systems.
Content may be subject to copyright.
A Car Hacking Experiment:
When Connectivity meets Vulnerability
Sasan Jafarnejad, Lara Codeca, Walter Bronzi, Raphael Frank, Thomas Engel
Interdisciplinary Centre for Security, Reliability and Trust
University of Luxembourg, 2721, Luxembourg,{lara.codeca,walter.bronzi,raphael.frank,thomas.engel}
Abstract —Interconnected vehicles are a growing
commodity providing remote access to on-board sys-
tems for monitoring and controlling the state of the ve-
hicle. Such features are built to facilitate and strengthen
the owner’s knowledge about its car but at the same
time they impact its safety and security. Vehicles are
not ready to be fully connected as various attacks
are currently possible against their control systems. In
this paper, we analyse possible attack scenarios on a
recently released all-electric car and investigate their
impact on real life driving scenarios. We leverage our
findings to change the behaviour of safety critical com-
ponents of the vehicle in order to achieve autonomous
driving using an Open Vehicle Monitoring System.
Furthermore, to demonstrate the potential of our setup,
we developed a novel mobile application able to control
such vehicle systems remotely through the Internet.
We challenge the current state-of-the-art technology in
today’s vehicles and provide a vulnerability analysis on
modern embedded systems.
KeywordsInterconnected Vehicles, Car Hacking,
Autonomous Driving, Embedded Systems, Mobile Com-
puting, Security
I. Introduction
Many objects that we use everyday at home and outside
are becoming increasingly connected and remotely control-
lable. Today’s high-speed, high-coverage mobile networks
enable us to access these objects to influence and automate
their behaviour that once required local and manual input.
Motor vehicles are the latest addition to the Internet of
Things (IoT) network of objects and thus an important
topic to tackle in order to evaluate the impact and trade-
offs that this technology has to offer.
When connectivity meets modern vehicles, we can im-
mediately picture a scenario where we control a car with
a smartphone. Moreover, as we present in this paper,
autonomous vehicles and self-driving cars represent the
next logical step and are now a reality. With the increasing
complexity in the electronics of the vehicles, the number
of Electronic Control Units (ECUs) and their importance
in monitoring the different subsystems of a car has grown
steadily over the last decade. In addition, modern vehicles
are able to communicate with other devices using wireless
interfaces potentially exposing the internal network of the
car to vulnerabilities. It is our belief that the current
state-of-the-art internal communication systems used in
modern cars, are not ready to handle threats from external
In this paper, we present a platform based on open
source hardware and software that is able to gain access to
the internal network of a car. We show that the inadequacy
of the existing security mechanisms in the internal network
architectures is a major concern now that many vehi-
cles are equipped with wireless communication capacities.
Given the structure of the internal network, our remote
access was able to compromise safety critical systems of
the vehicle.
For all our experiments we make use of the Open
Vehicle Monitoring System (OVMS)
, which is an open
source tool that brings remote access to a number of
electric cars in order to retrieve various information such
as the battery state, location, and other readings. OVMS
supports different vehicles, and amongst them, the Renault
Twizy, the car that we used for all our experiments.
II. Related Work
Many studies have been carried out for discovering vul-
nerabilities and proposing solutions to increase the security
of embedded car systems. In [1], the authors provide an
overview of all the different approaches used to investigate
these security issues and list the solution that have been
proposed to increase their safety.
Given the complexity of the automotive electronic ar-
chitecture, works such as [2] and [3] provide a taxonomy
of the different attacks such as systematic manipulation
and intrusion. In [4], the authors suggest that the internal
automotive computer network was not protected from a
local attacker able to physically access the car. Here, they
present an attack that leverages individual weaknesses in
the different subsystems, such as an attack that embeds
malicious code in an Electronic Control Unit (ECU) and
that erases any evidence of its presence after a crash. We
further extend this idea by exploring the feasibility of
reproducing such attacks at distance by remotely taking
over a vehicle’s internal control systems. Papers such as [5]
and [6] present an overview of the different vulnerabilities,
the possible attacks and provide an outlook on security
challenges of interconnected vehicles. A notable work that
explores possible attacks on vehicle subsystems with a very
practical approach is [7] in which authors discuss in detail
how to manipulate and control a number of safety critical
subsystems of a Ford Escape and a Toyota Prius. One year
later same authors in [8] provide an insightful survey of
OVMS website:
978-1-4673-9526-7/15/$31.00 ©2015 IEEE
remote attacks by evaluating possible penetration scenar-
ios for 20 different vehicles. In [9], the authors provide an
overview of the advances in autonomous vehicle technology
from the latest US and European research projects and
point out the vulnerabilities of current embedded systems.
In recent years, many solutions have been proposed to
overcome those vulnerabilities. CANAuth [10] and Libra-
can [11] are two broadcast authentication protocols for the
CAN bus based on basic building blocks from cryptogra-
phy (encryptions, signatures, etc.).
In this work we describe a novel mechanism based on
open source hardware and software, that is able to provide
remote access to the internal network of the car, and given
its structure, we demonstrate how to compromise safety-
critical systems such as the engine controller.
III. Background
Before presenting our experimental setup and problem
statement, we first provide some background information
about the concepts that are used in this work.
A. Electronic Control Unit
An Electronic Control Unit (ECU) designates an em-
bedded system that controls one or more subsystems of a
vehicle. One type of ECU is the Engine Contro l Module
(ECM), which specifies the runtime parameters of the
engine (combustion, hybrid or electric). ECMs introduced
in the eighties to allow for a fine control of the amount
of fuel injected in the motor at each cycle. Modern ECUs
are, among other things, able to control air intake, fuel
injection, torque and collect various sensor information.
They can have many functions, from the door control unit
to human computer interfaces and cruise control systems.
It is of vital importance that such systems run unperturbed
according to factory specifications. A malicious tampering
to such components could seriously compromise the car’s
behaviour on the road and lead to a potential accident.
B. Controller Area N etwork
In the past, car components, also called nodes, were
wired independently to each system they needed to com-
municate with, resulting in enormous lengths of electric
cable used. This led to an increase of the cost and weight
of the car and made maintenance more difficult. To address
this issue Robert Bosch GmbH developed the Controller
Area Network (CAN). The CAN is a multi-master serial
bus, which allows micro-controllers in a vehicle (generally
ECUs) to exchange short messages at a maximum rate of
1 megabits per second. On the CAN bus all the devices are
usually connected through a twisted pair of wires and each
message is broadcasted to every device on the bus. There
is no notion of identification for the source and destination
of messages. Each message has an ID, which identifies
the purpose of the message and its priority. Priorities are
resolved based on an arbitration method. There are four
different message types on the CAN bus: Data Frame,
Remote Frame, Error Frame and Overload Frame.The
first two types are respectively used to broadcast a data
payload between nodes and to request the transmission
Figure 1: CANopen device structure
of data from a particular node. The error frame is sent
by a node that has detected an error in a message to
ask the sender to retransmit that message. The overload
frame is sent by a busy node to request an extra delay
between messages. As there is no central coordination
defined by the CAN standard, nodes can be added or
removed without impacting the network.
C. CANopen
The CAN standard (ISO11989) defines the OSI layers
1 and 2, but in practice these are already being handled
solely by the hardware (CAN controller), which is of
great help for engineers. However a flexible and highly
configurable embedded network based on CAN, is not
possible without employing higher layer protocols, and
is one of the existing solutions. CANopen
specifies a set of device and application profiles. The
device profiles specify the interface of a logical device and
the application profiles a set of virtual device interfaces.
CANopen devices may implement one or several virtual
devices. Devices implementing the same set of profiles are
partly or completely exchangeable. This allows a flexible
integration of CANopen devices and enables interoperabil-
ity and interchangeability between multiple devices.
Every CANopen device is described by an Object Dic-
tionary (OD). An OD describes a group of objects, each
of them addressed by a 16-bit index. To access individual
elements of data in each object an 8-bit subindex is used.
The OD encloses all the parameters describing the device
and its behaviour on the network. Each subindex points
to an object that is defined by Object Name, Name, Type,
Attribute, M/O. The Attribute defines object access rights
and the M/O specifies whether it is mandatory or optional.
CANopen defines several communication objects to
achieve different goals such as network management, tim-
ing, synchronization and handling emergency states. But
the most vital communication objects are Service Data
Object (SDO) and Process Data Object (PDO). An SDO
gives a node read and/or write access to objects on another
device’s OD knowing its index and subindex. In this case,
the first node is the client and the target device is the
server. PDO is used to transfer real-time data. In SDO a
node requests to read or write an object but in PDO data
is being broadcast at certain intervals or is triggered by
Figure 2: Experimental Setup
an event. The simplified structure of a CANopen device is
depicted in Figure 1.
IV. Experimental Setup
For all our experiments we used a factory standard
Renault Twizy 80. The Twizy is a compact electric quadri-
cycle for two passengers, including the driver. The motor
controller ECU that is mounted in the Twizy is produced
by the company Sevcon
, which manufactures motor con-
trollers and system components for electric vehicles. The
actual model installed in the Twizy is a Sevcon Gen4
The Twizy is equipped with an additional backseat
computer that provides direct access to the OVMS in order
to make changes to the firmware. Although it is an atypical
vehicle, the Twizy can be seen as a simplified version of a
modern car as it shares a similar system architecture. For
our study the most important requirement is the presence
of a standard CAN bus for the communication between
the different components.
Access to the internal CAN bus is provided via the
On-board Diagnostics (OBD) port. Given the increasing
number of ECUs in cars over the past few decades,
manufacturers started to add self-diagnostic capabilities
to their vehicles in order to help technicians retrieving
the status of the subsystems and determine faults. The
OBD, or more commonly OBD-II (EOBD in Europe)
is a standardized interface and it is mandatory by law
in both United States and Europe since 1996 and 2001,
respectively. In order to interact with the CAN bus and
the attached systems, a variety of tools can be purchased
without any requirements. For our experiments we choose
the OVMS. This tool is open source and open hardware
and is equipped with GPRS/GSM module, a GPS and a
serial port that allows to configure the device.
This tool was originally developed by and for owners
of the Tesla Roadster, a high-end electric vehicle. It allows
the user to monitor the status of the car battery, the
last known GPS location, and to control some of the
Sevcon website:
car’s features such as the lock status of the doors or the
heating system through their smartphones. Compared to
a USB or Bluetooth adapter, the OVMS allows to extend
the range of interaction with the CAN bus by using the
cellular network. Moreover, due to open source nature of
the OVMS, the source code is openly accessible online
[12]. We used it both as a way to acquire knowledge on
how the internal systems of the Twizy works, and as an
experimentation platform.
Given the presence of a serial port on the OVMS
module, we used the backseat computer as a Wi-Fi proxy
to speed up our experiments and avoid relying on the
GSM signal reception. The connection between the two
was made with a USB to RS-232 adapter. In this setup,
the module needs to boot into debug mode during, which
the output messages are sent through the serial port
instead of the cellular network. This allowed us to connect
to the backseat computer via Wi-Fi and send messages
directly to the OVMS through the serial port. Instead of
operating with a serial terminal application we developed a
program in C called OVMS Controller that was installed
on the backseat computer. This enabled us to automate
the communication with the module, and to perform tasks
that would otherwise be time consuming and redundant.
In addition to the serial port, one can interact with the
OVMS via text messages or through the Internet using the
available mobile applications (iOS and Android). When
using the mobile applications, the module connects to
a public server that acts as an Internet proxy to relay
commands between OVMS and the client. A default server
is hosted by the Tesla Motors Club
for convenience.
Messages going through the Internet use a Base64 encoding
scheme and are encrypted using RC4 stream cipher [13].
To reduce latency and to have a higher degree of flexibility,
we deployed our own server locally.
During the project, we developed a number of new
features for the OVMS. In order to use these features
remotely, we developed a new web interface and a custom
version of the OVMS Android application. Using these two
interfaces, the module can easily be accessed using smart-
phones and standard computers through the browser.
V. Exploiting Vulnerabilities
As introduced in the previous section, the main ECU
of the Twizy is the Sevcon Gen4 controller. We will now
describe its architecture and how we succeeded in accessing
the main configuration parameters. The Sevcon Gen4 uses
CANopen as higher layer protocol and specifies different
level of access rights that prevent manipulating some
objects without the correct level of authentication.
Setting up the parameters of a Sevcon Gen4 (see
the Sevcon Gen4 manual [14]) is done by reading and
writing the values associated to the objects. The tools
commonly used for this purpose are either a proprietary
software on a computer, or a professional hand-held device.
Nevertheless, with a good understanding of the CANopen
protocol, the process can be done manually by forging
Tesla Motors Club:
Table I: Access Levels
Access Level Usage
2 Service Engineer
4 OEM Engineering
5 Sevcon Engineering
the data frames. There are 5 levels of accessibility, and
different login credentials for each level. The access levels
are listed in the Table I. In the initial state, the user is
not authenticated, and can only access a very limited set
of objects. The higher the access level, the more objects
can be manipulated (i.e. the configuration changed). The
authentication can be done by sending a data frame whose
payload contains the ID of the authentication object and
the passcode. As a result, anyone with the right passcode
could have access to the whole OD of a Sevcon Gen4.
A. Brute-Force Attack
To be able to freely reconfigure the Sevcon Gen4 one
needs to gain access to the right passcode preferably for a
high access level (e.g. 4 or 5). Like for every other protected
system when it comes to finding a passcode, brute forcing
is the simplest way of approaching the problem. However,
while being easy to perform, it is only practical when
applied to short passcodes. Knowing that the passcode for
the Sevcon Gen4 is only 2 bytes long, this was the preferred
approach. After implementing the required routines on the
OVMS to try all 65536 combinations on the ECU, we
executed the program. It took our brute forcing routine
approximately 11 hours to find the passcodes for all the
access levels. Although this was reasonably fast, a delay
was introduced due to the the link between the OVMS
and our brute forcing routine that has been executed on
the backseat computer. Moreover we checked for all access
levels in one run, in other words we tested the passcode
space 5 times.
After studying the technical documents of the Sevcon
Gen4 and having obtained the passcodes for all the access
levels, we defined a number of experiments. We only
had access to one master OD that was not specifically
for the Sevcon Gen4 but was a general format for all
Sevcon products. The Master OD is a reference object
containing information about all the dictionaries and their
constraints. We read the configuration of the controller to
determine what were the parameters in use for the Twizy.
We then tried to modify those parameters one by one to
observe what changes they induced in the behaviour of the
There are many parameters to take into account in
order to fine tune the motor and change the behaviour of
the system. Here, we present two parameters that allowed
us to make the car move autonomously.
Throttle Control: By default, the Sevcon Gen4 converts
the voltage from the throttle pedal position into a scaled
numerical value that controls the power output of the
Figure 3: Throttle conversion function
Table II: Gear State
Forward Reverse Action
0 0 Neutral (No Torque)
0 1 Negative Torque
1 0 Positive Torque
1 1 Unauthorized
electric motor. By having access to all parameters of the
controller, we can modify the conversion function to alter
the default behavior of the vehicle. As shown in Figure
3, we modified the parameters of the function in order
to interpret any input voltage as the numerical value of
our choice. In this example no matter what input voltage
(horizontal axis), the output value for the throttle (vertical
axis) is about 70 percent. The default conversion line
is drawn in blue and the modified line is in red. This
modification effectively simulates a push on the throttle
pedal and removes the user’s control over the acceleration
of the vehicle.
Gear State: We identified two Boolean switches that
together describe the gear state of the vehicle. One cor-
responds to the forward direction and the other to the
reverse direction. By default, those values are set by
physical switches next to the steering wheel. Table II shows
the internal logical functions of the Sevcon Gen4 and how
they determine the driving mode of the vehicle (e.g. torque
positive, negative or neutral).
By programmatically setting those values, we were
able to automatically change the gear state and as a
consequence the driving direction of the vehicle.
Brake: The previously described technique could also
be used as the brake. Only by applying negative torque
to the motor, the vehicle will slow down. We used this in
our experiments to stop the vehicle while it remained at
low speed, under 30 km/h. This was not tested at higher
speeds because the amount of negative torque would not
be sufficient to stop the car. Another concern is that this
method, also called Plug braking, generates a lot of heat
and endangers the operation of the engine [15].
C. Remote Control
To be able to demonstrate what is practically feasible
using this module we decided to implement the aforemen-
tioned exploits directly in the OVMS module.
Figure 4: Android Application
We implemented several keyboard short-cuts on the
OVMS client to have an easier control over the dynamics of
the vehicle. By exploiting the vulnerabilities discovered in
the experimentation phase, the module is able to remotely
and autonomously drive the vehicle forward and in reverse.
Forward and reverse throttle values sent by the client are
expressed as percentages of the maximum throttle value
acceptable by the Sevcon Gen4. To avoid latency and
reliability issues, we implemented the routines directly on
the OVMS. The client applications (Android and Web
application) are solely used to send basic commands.
Android and Web Application: Two client applications
have been implemented to demonstrate our scenario: An
Android mobile application and a web application. We
modified the already existing mobile application provided
by OVMS to include the remote control features that we
developed. We also modified the OVMS firmware in order
to accept the custom commands of the client applications.
The Android application interface is shown in Figure
4. The vertical arrows represent the forward and reverse
throttle, similar to the ones used by game controllers.
The application also allows to disable the throttle pedal,
limit the maximum speed or enable a demo mode that
repetitively moves the car slowly forward and backward.
VI. Discussions
In this section we will present potential attack sce-
narios, suggest solutions and discuss future applications.
First, it is important to note that the Sevcon Gen4 is
only accessible while the cars is turned on (i.e. ignition
turned on). Therefore an attack is only possible while
the car is operated. Given that the Twizy does not have
door locks nor windows and that the OBD-II port is
freely accessible inside the glove box, it is easy for an
attacker to install a system such as the OVMS without
the owner noticing. The Sevcon Gen4 centralizes many
safety critical functions of the vehicle, some of which are
not implemented in the case of the Twizy. For example,
the master OD indicates the presence of objects managing
brake lights and steering servomotors. However the Twizy
does not have assisted steering, therefore these features
cannot be exploited. If this was the case, as shown in [7],
complete control over the steering wheel would be possible
and the attacker would be able to make dangerous turns at
high speeds and potentially collide with other vehicles or
with road infrastructures. Furthermore, we observed that
the passcode is the same for every Sevcon Gen4 controller.
As a result, once connected to the CAN bus, there are
no security measures to prevent an attacker from taking
control over the subsystems of the vehicle. The security of
the onboard system only relies on the assumption that an
attacker does not have the passcode to access the engine
Possible Attack Scenarios: In order to demonstrate
the potential of our system, several attack scenarios are
described to show some use case examples of the module.
We identified the following attack scenarios:
Forcing the car to go forward or backward.
Limiting the speed (e.g. Very low speed on the
Setting unsafe motor and voltage parameters
which, could lead to possible damage to the engine
of the vehicle.
Randomly changing motor direction.
Interacting with the dashboard to display false
data, tricking the driver into making dangerous
Changing or inverting the conversion function of
the throttle input.
The proposed attack scenarios can either be activated
remotely by an attacker or triggered automatically by the
module upon any arbitrary events such as speed or the
location information retrieved from the integrated GPS
module (e.g. while being in a predefined area or when the
speed is over a certain value).
A. Possible Solutions
There have been many attempts in solving security
issues in automotive environments and more specifically
on the CAN bus.
One important category of solutions propose use of
cryptography for authentication. For instance solutions
proposed in [10], [11], [16] are in fact very effective.
However, not all the processors used in the ECUs are
powerful enough to incorporate them. To solve this issue
Hardware Security Modules (HSMs) were proposed. The
main idea of HSM is to dedicate part of ECU’s hardware
only for encryption purposes[17]. Although HSM handled
the security overhead, they demand a new and more
sophisticated ECU design, which leads to much higher
costs. Cryptographic solutions are the best candidates as
a long term solution but this transition will not happen
in near future. Therefore it is important to find adequate
solutions that are conveniently integrate into the current
What is worth mentioning about Twizy and Gen4, is
the lack of a mechanism that prevents brute-force attacks.
For example, in [7] it has been shown that the Toyota Prius
already uses a challenge-response authentication protocol
and when an attacker tries to brute-force the system it
fails after 10 attempts.
Another category of solutions are based on detecting
anomalies in the network, just like the Intrusion Detection
Systems (IDSs) for computer networks. For example in [18]
authors use time and frequency and in [19] the entropy
of messages are used as feature to monitor and detect
anomalies. To our knowledge only anomaly based solutions
can effectively detect and possibly react upon attacks on
the CAN bus without requiring any additional change to
the network structure.
We believe that a temporary solution to achieve a
reliable security in vehicles lies in implementing more
sophisticated IDS that not only detects anomalies and
signature based attacks, but also actively inspect current
state of the vehicle and ECUs. For example in the Twizy,
an observation of write access to the configuration ODs of
Gen4 should flag a suspicious event. If this occurs while the
vehicle is moving, the IDS could react upon it and trigger
an alarm informing the driver of the incident.
B. Other Applications
Based on what we showed in Section V, one can foresee
that these security flaws in the Sevcon Gen4 controller can
lead to the development of new applications. Using the
OVMS bundled with our improvements the Twizy can be
transformed into an autonomous vehicle at a reasonable
cost. More equipments such as additional sensors (e.g.
Lidar) and actuators (e.g. for braking and steering) are
needed to build a fully functional autonomous vehicle. In
this preliminary work we proved that the power train,
which is the most critical system in a vehicle, can be con-
trolled electronically bringing us one step forward towards
automated driving.
VII. Conclusion and Future Work
In this paper, we presented an experimental platform
able to remotely access and interact with internal systems
of a vehicle. This platform is composed of a Renault
Twizy 80, an Open Vehicle Monitoring System (OVMS)
and an Android mobile application used as communication
interface. The goal of this work was to remotely control
the safety critical systems of the vehicle. Using the OVMS
we accessed and reconfigured the Sevcon Gen4 controller
in order to manipulate the behaviour of the vehicle. We
showed that with off the shelf hardware it is possible
to control vital engine parameters, which allowed us to
interact with the operation mode of the vehicle (e.g. slow
down or stop the vehicle, reversing the gear while moving).
By doing this, we noticed a lack of protection mechanisms,
which allowed us to exploit and modify many parameters
of the vehicle at runtime (e.g. gear, throttle, speed limita-
tion, etc.). For demonstration purposes, we implemented
a web interface and an Android mobile application able
to interact remotely with the vehicle. We demonstrated
the effects of remotely changing the vehicle’s behaviour in
a real life situation and pointed out the dangers behind
such attacks.
Our future work will consist in adding additional equip-
ment to the vehicle, including sensors and actuators for the
braking and steering. Ultimately, our goal is to produce
a low cost fully connected and fully automated electric
[1] I. Studnia, V. Nicomette, E. Alata, Y. Deswarte, M. Kaˆaniche,
and Y. Laarouchi, “Survey on security threats and protection
mechanisms in embedded automotive networks,” in Dependable
Systems and Networks Workshop (DSN-W), 2013 43rd Annual
IEEE/IFIP Conference on. IEEE, 2013, pp. 1–12.
[2] M. Wolf, A. Weimerskirch, and T. Wollinger, “State of the
art: Embedding security in vehicles,” EURASIP Journal on
Embedded Systems, vol. 2007, no. 1, p. 074706, 2007.
[3] P. Kleberger, T. Olovsson, and E. Jonsson, “Security aspects
of the in-vehicle network in the connected car,” in Intelligent
Vehicles Symposium (IV), 2011 IEEE. IEEE, 2011, pp. 528–
[4] K. Koscher, A. Czeskis, F. Roesner, S. Patel, T. Kohno,
S. Checkoway, D. McCoy, B. Kantor, D. Anderson, H. Shacham
et al., “Experimental security analysis of a modern automo-
bile,” in Security and Privacy (SP), 2010 IEEE Symposium
on. IEEE, 2010, pp. 447–462.
[5] S. Checkoway, D. McCoy, B. Kantor, D. Anderson, H. Shacham,
S. Savage, K. Koscher, A. Czeskis, F. Roesner, T. Kohno et al.,
“Comprehensive experimental analyses of automotive attack
surfaces. in USENIX Security Symposium, 2011.
[6] R. Moalla, H. Labiod, B. Lonc, and N. Simoni, “Risk analysis
study of its communication architecture,” in Network of the
Future (NOF), 2012 Third International Conference on the.
IEEE, 2012, pp. 1–5.
[7] C. Miller and C. Valasek, “Adventures in automotive networks
and control units,” in DEF CON 21 Hacking Conference. Las
Vegas, NV: DEF CON, 2013.
[8] ——, “A survey of remote automotive attack surfaces,” Black
Hat USA, 2014.
[9] J. Iba˜nez-Guzman, C. Laugier, J. D. Yoder, and S. Thrun, “Au-
tonomous driving: Context and state-of-the-art,” in Handbook
of Intelligent Vehicles. Springer, 2012, pp. 1271–1310.
[10] A. Van Herrewege, D. Singelee, and I. Verbauwhede,
“CANAuth-a simple, backward compatible broadcast authen-
tication protocol for CAN bus,” in ECRYPT Workshop on
Lightweight Cryptography 2011, 2011.
[11] B. Groza, S. Murvay, A. Van Herrewege, and I. Verbauwhede,
“Libra-can: a lightweight broadcast authentication protocol for
controller area networks,” in Cryptology and Network Security.
Springer, 2012, pp. 185–200.
[12] Open vehicles monitoring system. [Online]. Available: https:
[13] OVMS Protocol Guide, 2013, v2.5.1.
[14] Sevcon Gen4 Applications Reference Manual, 2009, rev
3.0. [Online]. Available:
Product Manual V3.0.pdf
[15] C. Richard, What is Plug/Dynamic Braking for series motors?,
ALLTRAX, jan 2007, technical Note 008.
[16] O. Hartkopp, C. Reuber, and R. Schilling, “Macan-message
authenticated can,” in 10th Int. Conf. on Embedded Security
in Cars (ESCAR 2012), 2012.
[17] M. Wolf and T. Gendrullis, “Design, implementation, and
evaluation of a vehicular hardware security module,” in Infor-
mation Security and Cryptology-ICISC 2011. Springer, 2012,
pp. 302–318.
[18] M. M¨uter and N. Asa j, “Entropy-based anomaly detection for
in-vehicle networks,” in Intelligent Vehicles Symposium (IV),
2011 IEEE. IEEE, 2011, pp. 1110–1115.
[19] I. Broster and A. Burns, “An analysable bus-guardian for event-
triggered communication,” in Real-Time Systems Symposium,
2003. RTSS 2003. 24th IEEE. IEEE, 2003, pp. 410–419.
... The most obvious way to steal data from a vehicle is to hack into its computer system, either by surreptitious physical connection or using its links to other vehicles and to the traffic guidance system (Jafarnejad et al., 2015). If the system contains sensitive information, such as geopositioned travel logs, then this information can be used for instance for blackmailing or for arranging an "accident" at a place to which the owner returns regularly. ...
... Software manipulation can be performed for various criminal purposes, for instance to make the vehicle inoperable, to make it crash, or to direct the vehicle to a destination undesired by the passengers, for instance with the intent of frightening or kidnapping travellers (Crane et al., 2017, pp. 239-251;Jafarnejad et al., 2015;Joh, 2019, p. 313). Such manipulations can be connected with terrorism or organized crime. ...
Full-text available
The introduction of self-driving vehicles gives rise to a large number of ethical issues that go beyond the common, extremely narrow, focus on improbable dilemma-like scenarios. This article provides a broad overview of realistic ethical issues related to self-driving vehicles. Some of the major topics covered are as follows: Strong opinions for and against driverless cars may give rise to severe social and political conflicts. A low tolerance for accidents caused by driverless vehicles may delay the introduction of driverless systems that would substantially reduce the risks. Trade-offs will arise between safety and other requirement on the road traffic system. Over-reliance on the swift collision-avoiding reactions of self-driving vehicles can induce people to take dangerous actions, such as stepping out in front of a car, relying on its fast braking. Children travelling alone can violate safety instructions such as the use of seatbelts. Digital information about routes and destinations can be used to convey commercial and political messages to car users. If fast passage can be bought, then socio-economic segregation of road traffic may result. Terrorists and other criminals can hack into a vehicle and make it crash. They can also use self-driving vehicles for instance to carry bombs to their designed places of detonation or to wreak havoc on a country’s road system.
... Since the vast majority of control systems are implemented via computers or embedded systems, these systems have become vulnerable targets for attackers. Notable examples of attacks on cyber-physical control systems include Stuxnet in 2009 [16], a cyberattack attack on an RQ-170 military UAV in 2011 [17], multiple attacks conducted on consumer automobiles [18][19][20], and the hacking of multiple UAVs by the Russian military during an insurgent attack on a Syrian base [21]. Two conclusions can be drawn from this trend: first, the increase in number of cyberphysical systems will be accompanied by a rise in faults and failures of such systems. ...
... isRRobust == false and (r > 0) do16: while isRSRobust == false and (s > 0) ROBUSTHOLDS(A(D), S 1 , S 2 , r, s)19: ...
The capabilities of and demand for complex autonomous multi-agent systems, including networks of unmanned aerial vehicles and mobile robots, are rapidly increasing in both research and industry settings. As the size and complexity of these systems increase, dealing with faults and failures becomes a crucial element that must be accounted for when performing control design. In addition, the last decade has witnessed an ever-accelerating proliferation of adversarial attacks on cyber-physical systems across the globe. In response to these challenges, recent years have seen an increased focus on resilience of multi-agent systems to faults and adversarial attacks. Broadly speaking, resilience refers to the ability of a system to accomplish control or performance objectives despite the presence of faults or attacks. Ensuring the resilience of cyber-physical systems is an interdisciplinary endeavor that can be tackled using a variety of methodologies. This dissertation approaches the resilience of such systems from a control-theoretic viewpoint and presents several novel advancements in resilient control methodologies. First, advancements in resilient consensus techniques are presented that allow normally-behaving agents to achieve state agreement in the presence of adversarial misinformation. Second, graph theoretic tools for constructing and analyzing the resilience of multi-agent networks are derived. Third, a method for resilient broadcasting vector-valued information from a set of leaders to a set of followers in the presence of adversarial misinformation is presented, and these results are applied to the problem of propagating entire knowledge of time-varying Bezier-curve-based trajectories from leaders to followers. Finally, novel results are presented for guaranteeing safety preservation of heterogeneous control-affine multi-agent systems with sampled-data dynamics in the presence of adversarial agents.
... In particular, signals related to the wheels speed are often twinned, meaning that they are carried by the same frame, while those representing the vehicle speed are not. Phase 3 post-processes the results of the translation to exploit this peculiarity and, therefore, increase the overall accuracy (line [14][15][16][17][18][19][20][21]. Vice versa, in the scope of the format decoding, each signal with a strong correlation to the vehicle speed can be used to decode the others. ...
Controller Area Network (CAN) is the most frequently used in-vehicle communication system in the automotive industry today. The communication inside the CAN bus is typically encoded using proprietary formats in order to prevent easy access to the information exchanged on the bus. However, it is still possible to decode this information through reverse engineering, performed either manually or via automated tools. Existing automated CAN bus reverse engineering methods are still time-consuming and require some manual effort, i.e., to inject diagnostic messages in order to trigger specific responses. In this paper, we propose CANMatch a fully automated CAN bus reverse engineering framework that does not require any manual effort and significantly decreases the execution time by exploiting the reuse of CAN frames across different vehicle models. We evaluate the proposed solution on a dataset of CAN logs, or traces, related to 479 vehicles from 29 different automotive manufacturers, demonstrating its improved performance with respect to the state of the art.
... In-vehicle networks connect these systems together inside vehicles and allow exchanging data between these devices and systems. In this part of the paper, we will review four widely used in-vehicle communication networks and their characteristics [47]. ...
With recent developments in communication technologies, vehicular networks have become a reality with various applications. However, the cybersecurity aspect of vehicular networks is still an open issue that needs to be addressed with novel defence mechanisms against attacks. This paper first presents the state-of-the-art communication technologies in vehicular networks (either inter-vehicle networking or in-vehicle networking) along with their applications. Then we explore novel technologies including machine learning and blockchain as cybersecurity defence mechanisms in vehicular networks. Based on the extensive survey, we highlight some insights for future research to secure vehicular networks.
... The developments in incorporating computer systems and computerization of mechanical and manual functions have improved the features of vehicles. More and more new cars are incorporating driver assisting features like adaptive cruise-control, lane departure warning systems and self-parking systems among other features [1,2]. These features have reduced human dependency for the vehicles and given rise to vehicles that are partly autonomous in nature. ...
Full-text available
Autonomous vehicles have been invented to increase the safety of transportation users. These vehicles can sense their environment and make decisions without any external aid to produce an optimal route to reach a destination. Even though the idea sounds futuristic and if implemented successfully, many current issues related to transportation will be solved, care needs to be taken before implementing the solution. This paper will look at the pros and cons of implementation of autonomous vehicles. The vehicles depend highly on the sensors present on the vehicles and any tampering or manipulation of the data generated and transmitted by these can have disastrous consequences, as human lives are at stake here. Various attacks against the different type of sensors on-board an autonomous vehicle are covered.
... It was standardised in ISO 11898 series and it works as a serial bus, indicating that any node on the network (e.g. an ECU) can use the network bus to send data via a multi-master mechanism using 2 wires [15]. This reduces the cost of wiring compared to a point to point wiring mechanism and reduces the negative effects of external noise through its CAN-High and CAN-Low (signal differential) transmission [14] [16]. It works on the physical and data link layers, although it does not use Media Access Control addresses (MAC) and MAC tables to send and receive (route) frames. ...
Full-text available
As connectivity between and within vehicles increases, so does concern about safety and security. Various automotive serial protocols are used inside vehicles such as Controller Area Network (CAN), Local Interconnect Network (LIN), and FlexRay. CAN Bus is the most used in-vehicle network protocol to support exchange of vehicle parameters between Electronic Control Units (ECUs). This protocol lacks security mechanisms by design and is therefore vulnerable to various attacks. Furthermore, connectivity of vehicles has made the CAN Bus vulnerable not only from within the vehicle but also from outside. With the rise of connected cars, more entry points and interfaces have been introduced on board vehicles, thereby also leading to a wider potential attack surface. Existing security mechanisms focus on the use of encryption, authentication, and vehicle Intrusion Detection Systems (IDS), which operate under various constraints such as low bandwidth, small frame size (e.g., in the CAN protocol), limited availability of computational resources, and real-time sensitivity. We survey and classify current cryptographic and IDS approaches and compare these approaches based on criteria such as real-time constraints, types of hardware used, changes in CAN Bus behaviour, types of attack mitigation, and software/ hardware used to validate these approaches. We conclude with mitigation strategies limitations and research challenges for the future.
... Cybersecurity is another potential concern related to AV operation because hacking and vehicle misuse can result in catastrophic crashes (Lee, 2017;Taeihagh and Lim, 2018;Cui et al., 2019). A car hacking experiment conducted by (Jafarnejad et al., 2015) demonstrated that electric vehicles could be easily controlled remotely by mobile applications that forced the vehicles to go forward or backward, limited their speed, etc. In addition, the ethical dilemma associated with AV reactions during unavoidable situations introduces another challenge in AV operation (Goodall, 2014;Awad et al., 2018) that requires further attention. ...
Vehicle automation safety must be evaluated not only for market success but also for more informed decision-making about Automated Vehicles' (AVs) deployment and supporting policies and regulations to govern AVs' unintended consequences. This study is designed to identify the AV safety quantification studies, evaluate the quantification approaches used in the literature, and uncover the gaps and challenges in AV safety evaluation. We employed a scoping review methodology to identify the approaches used in the literature to quantify AV safety. After screening and reviewing the literature, six approaches were identified: target crash population, traffic simulation, driving simulator, road test data analysis, system failure risk assessment, and safety effectiveness estimation. We ran two evaluations on the identified approaches. First, we investigated each approach in terms of its input (required data, assumptions, etc.), output (safety evaluation metrics), and application (to estimate AVs' safety implications at the vehicle, transportation system, and society levels). Second, we qualitatively compared them in terms of three criteria: availability of input data, suitability for evaluating different automation levels, and reliability of estimations. This review identifies four challenges in AV safety evaluation: (a) shortcomings in AV safety evaluation approaches, (b) uncertainties in AV implementations and their impacts on AV safety, (c) potential riskier behavior of AV passengers as well as other road users, and (d) emerging safety issues related to AV implementations. This review is expected to help researchers and rulemakers to choose the most appropriate quantification method based on their goals and study limitations. Future research is required to address the identified challenges in AV safety evaluation.
In the last decade, the automotive industry incorporated multiple electronic components into vehicles introducing various capabilities for adversaries to generate diverse types of attacks. In comparison to older types of vehicles, where the biggest concern was physical security, modern vehicles might be targeted remotely. As a result, multiple attack vectors aiming to disrupt different vehicle components emerged. Research and practice lack a comprehensive attack taxonomy for the automotive domain. In this regard, we conduct a systematic literature study, wherein 48 different attacks were identified and classified according to the proposed taxonomy of attack mechanisms. The taxonomy can be utilized by penetration testers in the automotive domain as well as to develop more sophisticated attacks by chaining multiple attack vectors together. In addition, we classify the identified attack vectors based on the following five dimensions: (1) AUTOSAR layers, (2) attack domains, (3) information security principles, (4) attack surfaces, and (5) attacker profile. The results indicate that the most applied attack vectors identified in literature are GPS spoofing, message injection, node impersonation, sybil, and wormhole attack, which are mostly applied to application and services layers of the AUTOSAR architecture.
Full-text available
Vehicles are evolving into autonomous mobile-connected platforms. The rationale resides on the political and economic will towards a sustainable environment as well as advances in information and communication technologies that are rapidly being introduced into modern passenger vehicles. From a user perspective, safety and convenience are always a major concern. Further, new vehicles should enable people to drive that presently can not as well as to facilitate the continued mobility of the aging population. Advances are led by endeavors from vehicle manufacturers, the military and academia and development of sensors applicable to ground vehicles. Initially, the motivators are detailed on the reasons that vehicles are being built with intelligent capabilities. An outline of the navigation problem is presented to provide an understanding of the functions needed for a vehicle to navigate autonomously. In order to provide an overall perspective on how technology is converging towards vehicles with autonomous capabilities, advances have been classified into driver centric, network centric and vehicle centric. Vehicle manufacturers are introducing at a rapid pace Advanced Driving Assistance Systems; these are considered as Driver Centric with all functions facilitating driver awareness. This has resulted on the introduction of perception sensors utilizable in traffic situations and technologies that are advancing from simple (targeted to inform drivers) towards the control of the vehicle. The introduction of wireless links onboard vehicles should enable the sharing of information and thus enlarge the situational awareness of drivers as the perceived area is enlarged. Network Centric vehicles provide the means to perceive areas that vehicle onboard sensors alone can not observe and thus grant functions that allow for the deployment of vehicles with autonomous capabilities. Finally, vehicle centric functions are examined; these apply directly to the deployment of autonomous vehicles. Efforts in this realm are not new and thus fundamental work in this area is included. Sensors capable to detect objects in the road network are identified as dictating the pace of developments. The availability of intelligent sensors, advanced digital maps, and wireless communications technologies together with the availability of electric vehicles should allow for deployment on public streets without any environment modification. Likely, there will first be self-driving cars followed by environment modifications to facilitate their deployment.
Conference Paper
Full-text available
Embedded electronic components, so-called ECU (Electronic Controls Units), are nowadays a prominent part of a car's architecture. These ECUs, monitoring and controlling the different subsystems of a car, are interconnected through several gateways and compose the global internal network of the car. Moreover, modern cars are now able to communicate with other devices through wired or wireless interfaces such as USB, Bluetooth, WiFi or even 3G. Such interfaces may expose the internal network to the outside world and can be seen as entry points for cyber attacks. In this paper, we present a survey on security threats and protection mechanisms in embedded automotive networks. After introducing the different protocols being used in the embedded networks of current vehicles, we then analyze the potential threats targeting these networks and describe how the attackers' opportunities can be enhanced by the new communication abilities of modern cars. Finally, we present the security solutions currently being devised to address these problems.
Conference Paper
Full-text available
Modern automobiles are no longer mere mechanical devices; they are pervasively monitored and controlled by dozens of digital computers coordinated via internal vehicular networks. While this transformation has driven major advancements in efficiency and safety, it has also introduced a range of new potential risks. In this paper we experimentally evaluate these issues on a modern automobile and demonstrate the fragility of the underlying system structure. We demonstrate that an attacker who is able to infiltrate virtually any Electronic Control Unit (ECU) can leverage this ability to completely circumvent a broad array of safety-critical systems. Over a range of experiments, both in the lab and in road tests, we demonstrate the ability to adversarially control a wide range of automotive functions and completely ignore driver inputdash including disabling the brakes, selectively braking individual wheels on demand, stopping the engine, and so on. We find that it is possible to bypass rudimentary network security protections within the car, such as maliciously bridging between our car's two internal subnets. We also present composite attacks that leverage individual weaknesses, including an attack that embeds malicious code in a car's telematics unit and that will completely erase any evidence of its presence after a crash. Looking forward, we discuss the complex challenges in addressing these vulnerabilities while considering the existing automotive ecosystem.
Conference Paper
Security in vehicular networks established itself as a highly active research area in the last few years. However, there are only a few results so far on assuring security for communication buses inside vehicles. Here we advocate the use of a protocol based entirely on simple symmetric primitives that takes advantage of two interesting procedures which we call key splitting and MAC mixing. Rather than achieving authentication independently for each node, we split authentication keys between groups of multiple nodes. This leads to a more efficient progressive authentication that is effective especially in the case when compromised nodes form only a minority and we believe such an assumption to be realistic in automotive networks. To gain more security we also account an interesting construction in which message authentication codes are amalgamated using systems of linear equations. We study several protocol variants which are extremely flexible allowing different trade-offs on bus load, computational cost and security level. Experimental results are presented on state-of-the-art Infineon TriCore controllers which are contrasted with low end controllers with Freescale S12X cores, all these devices are wide spread in the automotive industry. Finally, we discuss a completely backward compatible solution based on CAN+, a recent improvement of CAN.
Conference Paper
Intelligent Transportation Systems (ITS) are cooperative systems based on vehicular communications. They involve different actors like manufacturers, transportations authorities and users and enable diverse ITS applications to enhance safety in transportation systems. One of the ultimate design goals of ITS is to have a robust system that resists to various security attacks. Thus, security remains a major challenge before the deployment of such systems. In this paper, we present the ITS framework and communication architecture in Europe. Then, we identify inherent threats in this architecture. Finally, and using ETSI threat analysis methodology, we propose a risk analysis of ITS.
Conference Paper
Todays in-vehicle IT architectures are dominated by a large network of interactive, software driven digital microprocessors called electronic control units (ECU). However, ECUs relying on information received from open communication channels created by other ECUs or even other vehicles that are not under its control leaves the doors wide open for manipulations or misuse. Thus, especially safety-relevant ECUs need effective, automotive-capable security measures that protect the ECU and its communications efficiently and dependably. Based on a requirements engineering approach that incorporates all security-relevant automotive use cases and all distinctive automotive needs and constraints, we present an vehicular hardware security module (HSM) that enables a holistic protection of in-vehicle ECUs and their communications. We describe the hardware design, give technical details on the prototypical implementation, and provide a first evaluation on the performance and security while comparing our approach with HSMs already existing.
Due to an increased connectivity and seamless integration of information technology into modern vehicles, a trend of research in the automotive domain is the development of holistic IT security concepts. Within the scope of this development, vehicular attack detection is one concept which gains an increased attention, because of its reactive nature that allows to respond to threats during runtime. In this paper we explore the applicability of entropy-based attack detection for in-vehicle networks. We illustrate the crucial aspects for an adaptation of such an approach to the automotive domain. Moreover, we show first exemplary results by applying the approach to measurements derived from a standard vehicle's CAN-Body network.
Conference Paper
In this paper, we briefly survey the research with respect to the security of the connected car, and in particular its in-vehicle network. The aim is to highlight the current state of the research; which are the problems found, and what solutions have been suggested. We have structured our investigation by categorizing the research into the following five categories: problems in the in-vehicle network, architectural security features, intrusion detection systems, honeypots, and threats and attacks. We conclude that even though quite some effort has already been expended in the area, most of it has been directed towards problem definition and not so much towards security solutions. We also highlight a few areas that we believe are of immediate concern.