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].