experimental security analysis of a modern automobile · experimental security analysis of a modern...
TRANSCRIPT
hyväksymispäivä arvosana
arvostelija
Experimental Security Analysis of a Modern Automobile
Matti Valovirta
Helsinki
HELSINGIN YLIOPISTOTietojenkäsittelytieteen laitos
HELSINGIN YLIOPISTO − HELSINGFORS UNIVERSITET – UNIVERSITY OF HELSINKI Tiedekunta − Fakultet –Faculty
Faculty of Science
Laitos − Institution − Department
Department of Computer ScienceTekijä − Författare − Author
Matti ValovirtaTyön nimi − Arbetets titel − Title
Experimental Security Analysis of a Modern AutomobileOppiaine − Läroämne − Subject
Computer ScienceTyön laji − Arbetets art − Level
Seminar Report Aika − Datum − Month and year
21.3.2011 Sivumäärä − Sidoantal − Number of pages
11p pagesTiivistelmä − Referat − Abstract
ACM Computing Classification System (CCS):K.6.5 [Security and Protection]
Avainsanat – Nyckelord − Keywords
Security. automobile, network, CAN-bus, ECUSäilytyspaikka − Förvaringställe − Where deposited
Muita tietoja − Övriga uppgifter − Additional information
ii
Sisältö
1 Introduction 1
2 Technical details 2
2.1 Buses.....................................................................................................................2
2.1.1 CAN (Controller Area Network)..................................................................2
2.1.2 OBD-II..........................................................................................................2
2.1.3 Wireless communication...............................................................................3
2.2 Electronic Control Units (ECUs)..........................................................................3
3 Security 4
3.1 CAN......................................................................................................................4
3.2 Techniques............................................................................................................4
3.2.1 Bus listening..................................................................................................5
3.2.2 Cracking challenge-response pairs................................................................5
3.2.3 Fuzzing..........................................................................................................5
3.2.4 Reverse engineering......................................................................................5
4 Results 5
4.1 Reflashing.............................................................................................................6
4.2 Unit security..........................................................................................................6
4.3 Interconnecting buses............................................................................................6
4.4 Effects to the car...................................................................................................7
5 Conclusions 8
Appendix A.
References 11
1
1 Introduction
Talking about security testing of a car in a security testing seminar might sound a bit
far-fetched but when you acknowledge that there are in fact a network or two inside a
car and up to 70 Electronic Control Units (ECUs) you start to realize that the same
vulnerabilities that plague other networks might apply. Purpose of this paper is to find
out how big of an issue software security is in cars and their networks.
Traditionally cars were built to operate mechanically but in recent years we've seen
dramatical increase in electronic devices and computers in cars and the typical
by-products of them, like software updates. Take a look for example Volvo's recent
advertisement in Helsingin Sanomat found in Picture 1. For those of you who don't
understand Finnish, it advertises that software updates are free in the new Volvo Service
2.0.
Picture 1. Volvo's ad campaign where they are advertising free software updates [2].
Also with the recent incidents with Toyota's acceleration pedal in the United States has
put the issue in the spotlight. Apparently Toyota hired an independent consultant to
verify their claims that the problems weren't coming from the electronics. This just
2
highlights how sensitive this issue is. Who wants to drive a car 120 km/h knowing that
there might be a software bug that let's say prevents you from braking at all?
2 Technical details
2.1 Buses
Usually all the devices are connected to each other through a CAN-bus. Reason for this
is money, it would be too expensive for every car manufacturer to have their own
proprietary network. Unfortunately a standardized network in most cars gives wider
surface for possible attacks.
There might be two separate networks, a high-speed, critical one and a low-speed
not-critical one. Typically devices that are real-time, like Anti-lock Braking System
(ABS) and other safety related and/or time-critical devices are connected to the
high-speed bus. Other devices such as a radio, infotainment display and such are
connected to the slow-speed one. Some devices might need to exist on both network, for
example Central Locking System (CLS) needs access to physical door lock switches,
wireless input from remote key and possibly remote telematics command to unlock the
doors. These are found on the low-speed network. In addition it also needs access to
crash detection system in order to unlock the doors after airbags have deployed to
facilitate exit. This system usually lies on the high-speed network. [1].
2.1.1 CAN (Controller Area Network)
Controller Area Network, CAN or CAN-bus is a bus built specifically for cars by
Robert Bosch GmbH in 1984. It has now become more or less the industry standard for
intra-car networks.
2.1.2 OBD-II
Currently in the United States and in European Union cars are required to have a
standardized access to car's network through a port called On-Board Diagnostics
(OBD-II), usually found under the dashboard. This port can be used to insert a
malicious device into the network or use it momentarily to alter some of the units in the
network to operate differently. This will be discussed later on.
3
2.1.3 Wireless communication
Other communication methods in a car might include a Bluetooth for connecting
portable music players to the radio and cellular link access to mobile phone network.
It has been implemented in some cars that there is a link between the car's internal
network and a service center through a cellular connection. Applications might be such
as that the service center displays a message on the car's display when a trip to the repair
shop is needed based on telematics from the car's devices or contacts the emergency
authorities if a crash is detected. [1].
2.2 Electronic Control Units (ECUs)
A few examples of ECUs found in a modern car:
• Engine Control Module (ECM)
• Electronic Brake Control Module (EBCM)
• Transmission Control Module (TCM)
• Body Control Module (BCM)
• Telematics Module
• Remote Control Door Lock Receiver (RCDLR)
• Heating, Ventilation, Air Conditioning (HVAC)
• Inflatable Restraint Sensing and Diagnostic Module (SDM)
• Instrument Panel Cluster/Driver Information Center (IPC/DIC)
• Radio
• Theft Deterrent Module (TDM)
These just examples of what kind of units are found inside a typical modern car. Some
of these devices are connected to either one of the low or high-speed buses, while some
are connected to both, like BCM and Telematics. The problem here is that if these units
are compromised it might be possible to convert the unit to act as a repeater, repeating
from one network to the other, thus interconnecting the two networks. One estimate
suggests that a typical car might contain over 100 MB of binary code over 50-70 ECUs.
[1].
4
3 Security
Given the nature of current automobile electronics architecture there a several
possibilities for a attacker to gain access to a car's internal networks. In the following
section we are going to give a overview on the possible techniques involved.
3.1 CAN
There are some inherent security flaws in CAN's design. In CAN, there are no addresses
and every node connected to the CAN-bus receives all messages sent to it. Messages are
processed by their identification fields. By design it is possible to add new nodes to the
network and make them process all messages sent to the network. Other possibility is a
denial-of-service attack which either floods the network with packets or using CAN's
priority-based arbitration sets the network to a “dominant” state, where all other nodes
will back off. In addition to these there are no authentication fields in CAN messages,
so that it could be identified from which node the message was sent.
One can build a higher level protocol on top of CAN which supports some mechanisms
to increase security. Apparently this was done on cars studied in the article. Solution
was to add a challenge-response sequence to protect the ECUs against certain actions
without being authenticated. The protocol they used defined that a given ECU could
participate in zero, one or two challenge-response pairs of the following types:
• Reflashing and memory protection. Protects against reflashing and reading out
sensitive parts of the memory.
• Tester capabilities. There might be a need to access and alter states while testing
the car's functionalities. This pair is to protect against unauthorized access.
In principle, challenge-response pair mechanism should protect ECUs from being
accessed unauthorized. But in reality there are few problems. First of all the CAN's
message is 16-bit wide, so it's feasible to scan all possible combinations in a decent
amount of time. More information can be found in section 3.2.2. [1].
3.2 Techniques
Here are listed the techniques described in the article that was used to gain knowledge
of the car's networks [1].
5
3.2.1 Bus listening
This mean that one simply records all messages on the bus. This can be easily achieved
since all messages are broadcasted and new devices can be added to the network so that
existing ones do not recognize their presence. Out of this recording one can derive what
messages correspond to what commands on the units.
3.2.2 Cracking challenge-response pairs
Since CAN messages are 16-bit wide it does not take that long to scan every possible
bit-combination in order to find the correct response for a challenge. It was stated in the
article that ECUs have to allow key entries every 10 seconds. It took seven and a half
days to scan every possible message of challenge-response pair. One can also speed this
up by powercycling the ECU which decreased the time to three and a half days. This
can be done in parallel to every device, in order to save time.
3.2.3 Fuzzing
Fuzzing means sending random messages to the network and observe their impact. With
this technique one can find what can messages correspond to what actions on the car.
One application of fuzzing might also be to disrupt the normal working state of the car
without any actual knowledge of the ECUs.
3.2.4 Reverse engineering
If one has access to the binary code of the unit, it is possible to reverse engineer it. This
means that by running the code in a debugger one gains knowledge what that particular
code is doing.
4 Results
Koscher et al [1] describes in their paper their findings of a “experimental security
analysis of a modern automobile”. They experimented with two automobiles from 2009
of the same make and model. They did not reveal the manufacturer but instead said that
they believe the problems lie within the architecture, not the particular implementation.
However the results were not verified with another cars. Neither the specifics of the
communication standards used were disclosed. Only that a CAN-bus was used.
6
Testing was done both individually to ECUs connected to a CAN-to-USB adapter and
an oscilloscope and the car hooked to a laptop through ODB-II and a CAN-to-USB
adapter. Experiments were done in three ways: bench, stationary car and on the road.
Bench means that the tested unit was extracted from the car and hooked to an
oscilloscope and a CAN analyzer. Stationary car means that the car was lifted to jack
stands to allow the tires to spin. On the road means that the car was literally tested on
the road, which in this case was a abandoned airport runway.
4.1 Reflashing
The standard used in the car tested by Koscher et al [1] states that ECUs should reject
reflashing requests if they seem unsafe, for example that the car is running. However,
testing showed that it was indeed possible to place ECM and TCM into reflashing mode
while the car was at speed on jack stands. Also the ECM could be set to reflashing mode
while on the road.
4.2 Unit security
It was found out that unit security was implemented less broadly than what the standard
specified. For example the telematics unit had hardcoded challenge and response that
was similar to all unit with the same model. Even worse, the challenge-response was
never used at all.
Memory in the units should also be protected against being read if it contains sensitive
information. However, the reflashing keys could be read from memory of the BCM
without any authentication. Also the whole memory of the telematics unit could be read
without any authentication.
4.3 Interconnecting buses
The standard implicitly describes the high-speed network as more reliable than the
low-speed network. It also states that the gateways between the two networks should
only be re-programmable from the high-speed network. This is likely implemented as a
safety measure, so that let's say a new radio could not gain access to the high-speed
network. On the tested car, there were two ECUs that were on both networks, the BCM
and the telematics unit. While the telematics unit is not technically a gateway, it
7
connects to both networks and against the standard it can be re-programmed only from
the low-speed network. This way a unit residing on the low-speed network could attack
the telematics unit and gain access to the high-speed network through it. It was verified
that it was possible to upload code to the telematics unit from low-speed network that in
turn sent packets on the high-speed network.
4.4 Effects to the car
Using the techniques described in section 3.2 Koscher et al [1] were able to obtain
knowledge about what are the commands used in intra-car networks. Complete list of
the effects they were able to achieve can be found in Appendix A. Below are listed a
few examples:
• Disable brakes and all auxiliary lights at speed without a possibility for a manual
override.
• Kill engine at speed without a possibility for a manual override so that it can not
be restarted.
• Lock all doors so that they can not be opened from inside.
• Prevent the driver from turning the car on or off.
What this short list demonstrates is that fundamental things regarding safety was
compromised in the experiment. If an attacker could gain access to the car's internal
network it could lead to very severe consequences.
Multi-component attacks
In addition to affecting individual units an attacker can exploit multiple components to
perform an composite attack. A few were described by Koscher et al [1]:
Speedometer. They manipulated the displayed speed to be arbitrary speed of the actual
speed with an offset.
Lights out. In this attack they demonstrated that it was possible to turn off all light,
including all interior lights, headlights, brake lights and instrument panel illumination.
This can be extremely dangerous in the situation where the victim is driving in a dark
environment or at night.
8
Self-Destruct. In this they displayed a 60-second countdown on the Driver Information
Center that would culminate in killing the engine and activating the door lock relay
(preventing the occupant from using the electronic door unlock button).
5 Conclusions
It seems that modern cars have not yet been designed with electronic security in mind.
Car manufacturers have chosen to use standardized buses instead of one-off designs.
This is a good thing for accessory business but good for possible hackers as well. The
amount of electronic units inside a car has increased dramatically over the years and it
seems that the trend is now to add wireless services to cars. This increases the surface
that possible hackers can use to gain access to intra-car networks.
The list of what can be achieved when the network is compromised seems quite
exhaustive. Koscher et. al. [1] achieved to stop the engine while the car was running,
lock the brakes so that they won't release their position even when powercycled and
battery removed and disable brakes completely while the car was running.
It was not assessed in the article how feasible these attacks would be in real life, but it
demonstrated that they are feasible in theory at least. With the likely increase in wireless
connections added to cars, it seems that this issue is something that will have to be
addressed sooner or later.
9
Appendix A.
Picture 2. Listing of CAN commands gathered. [1].
In these listings Manual Override indicates whether it is possible to override the effect
manually, such as pulling a knob pushing on the brakes, etc. At Speed means that the
effect was tested while the car was suspended on jack stands. Need to Unlock means
10
that in order to issue the command on the unit authentication was needed. Tested on
Runway means that the effect was tested while running the car on an abandoned airstrip.
11
References
[1] K. Koscher, A. Czeskis, F. Roesner, S. Patel, T. Kohno, S. Checkoway, D.
McCoy, B. Kantor, D. Anderson, H. Shacham, S. Savage. Experimental
Security Analysis of a Modern Automobile. IEEE Symposium on Security
and Privacy. 2010
[2] Volvo Service 2.0 wegpage. http://nitroservice.fi/volvoservice2/
[19.3.2011].