Threat Analysis on Vehicle Computer Systems

(1)

Institutionen för datavetenskap

Department of Computer and Information Science

Final thesis

Threat Analysis on Vehicle Computer Systems

by

Christian Vestlund

LIU-IDA/LITH-EX-A--10/002--SE

2010-01-26

Linköpings universitet

SE-581 83 Linköping, Sweden

Linköpings universitet

581 83 Linköping

(2)

(3)

Linköping University

Department of Computer and Information Science

Final Thesis

Threat Analysis on Vehicle Computer Systems

by

Christian Vestlund

LIU-IDA/LITH-EX-A--10/002--SE

2010-01-26

Supervisor: Nahid Shahmehri

Linköping University

Department of Computer and Information Science

Examiner: Nahid Shahmehri

Linköping University

(4)

(5)

Abstract

Vehicles have been around in our society for over a century,

un-til recently they have been standalone systems. With increased

amounts of initiatives to inter-network vehicles to avoid

acci-dents and reduce environmental impact the view of a vehicle as

a standalone system needs to be reconsidered. Networking and

cooperation between vehicles requires that all systems and the

information therein are trustworthy. Faulty or malicious vehicle

systems are thus not limited to only affecting a single vehicle

but also the entire network. The detection of anomalous

behav-ior in a vehicle computer system is therefore of importance. To

improve the vehicle systems we strive to achieve security

aware-ness within the vehicle computer system. As a first step we will

identify threats toward the vehicle computer system and what

has been done to address them.

We perform a threat analysis consisting of fault trees and

misuse cases to identify the threats. The fault trees provide a

way to connect the threats found with vehicle stakeholders’ goals.

The connection between stakeholder goals and threat highlights

the need for threat mitigation.

Several research initiatives are discussed to find out what has

been done to address the identified threats and to find the state

of the research for security in vehicle computer system.

Lastly, an error model for the Controller Area Network (CAN)

is proposed to model the consequences of threats applied to the

CAN bus.

(6)

(7)

Authors’ Affiliations

Christian Vestlund

Department of Computer and Information Science Link¨oping University

SE-58183 Link¨oping, Sweden E-mail: chrve@ida.liu.se

Acknowledgement

I would like to thank my supervisor Professor Nahid Shahmehri

for giving me the opportunity to work on this project and for

the guidance during the work with this thesis. I would also like

to thank the rest of my colleagues at ADIT for the pleasant

work environment (especially all the cakes). My gratitude also

to Johannes Hassmund for our small discussions which always

gave some ideas. And lastly I would like to thank my father Leif

who read through my work and came with helpful comments.

(8)

(9)

List of Figures

1.1 The RMF and our adaption of the RMF. . . 3

2.1 Vehicle computer system. . . 11

4.1 In-vehicle network architecture. . . 24

4.2 ITS model as described by the CVIS project. . . 25

4.3 Fault tree event symbols. . . 32

4.4 Transfer symbols and logical gates in fault trees. . . 32

4.5 Fault tree example. . . 33

4.6 Fault tree illustrating the modified application subtree. . . 35

B.1 CAN architecture according to OSI reference model. . . 96

B.2 CAN standard format frame. . . 97

B.3 Two node arbitration process. . . 97

B.4 CAN error frame. . . 98

B.5 CAN abstract model components. . . 100

All figures are drawn by the author unless otherwise specified in the figure caption.

(14)

(15)

List of Tables

2.1 Information security concepts. . . 8

3.1 Adversaries found by EVITA and the eSecurity WG. . . 14

3.2 The table is an extract from the original table of adversaries found by Wolf (2009). . . 15

3.3 Volvo Cars company values. . . 15

3.4 Volvo Cars company manufacturer goals. . . 16

3.5 Owner goals with owning a car. . . 18

3.6 Threats toward manufacturer goals. . . 19

3.7 Threats toward owner goals. . . 20

4.1 Safety applications in Volvo XC60 . . . 26

4.2 Sub top-events for the stakeholder threat ”Higher amount of accidents”. . . 31

4.3 Event classification . . . 34

4.4 Misuse case template with field descriptions. . . 36

4.5 Misuse case description of brake functionality . . . 37

4.6 Misuse case description of CWAB safety system. . . 39

4.7 Misuse case description of OBD flashing. . . 40

4.8 Misuse case describing illegitimate acquisition and dispersion of automotive software. . . 42

4.9 Misuse case description of reducing fuel efficiency on a micro level. . . 44

4.10 Misuse case description of reducing fuel efficiency on a macro level. . . 45

4.11 Misuse case description of unintentionally losing ownership of a vehicle. . . 46

5.1 In-vehicle threat classes . . . 50

5.2 ITS threat classes . . . 53

A.1 Abbreviations used for transfer gates in the fault trees. . . 81

B.1 CAN node mode depending on TEC and REC counters. . . . 99

B.2 Initialization values for a CAN node. . . 101

(16)

(17)

Nomenclature

CAN Controller Area Network

CRC Cyclic Redundancy Check

CSMA Carrier Sense Medium Access

DoS Denial-of-Service

ECU Electronic Control Unit

FMEA Failure Mode and Effect Analysis

FTA Fault Tree Analysis

ITS Intelligent Transportation System

LIN Local Interconnect Network

MAC Medium Access Control

NoW Network on Wheels, research project

OBD On-Board Diagnostics

REC Receive Error Counter

RMF Risk Management Framework

RSU Roadside Unit

TEC Transmit Error Counter

V2I Vehicle-to-Infrastructure

V2V Vehicle-to-Vehicle

V2X Vehicle-to-X

VANET Vehicular Ad-hoc Network

(18)

(19)

Chapter 1 Introduction

The focus of this thesis is to perform a threat analysis to determine the threats toward commercially available and envisioned vehicle computer sys-tems. We will also look into the research community to see what has been done to address the threats that we identify in this thesis. Section 1.1 gives an overview of the evolution of vehicles during the last century. Section 1.2 describes the motivation for our work. Section 1.3 defines the research problems. Section 1.4 describes the methodology used for the threat analy-sis in this theanaly-sis. Section 1.5 states the delimitations for this work. Lastly Section 1.6 outlines the rest of the thesis.

1.1 History

Vehicles started out as purely mechanical systems for over a century ago. The view of the vehicle as a mechanical system has been a subject for change during the last century with the introduction of the Electronic Control Unit (ECU) in vehicles in the 1970s [1]. The introduction of the ECU came out of the need for more complex engine control when the awareness of fuel consumption and emissions increased [2, 3].

Since then most of the functionality within a vehicle has been over-taken by ECUs, electrical seats, window lifts, etc. The increasing amount of ECUs led to a need to allow efficient communication between them. Be-fore 1991 most inter-ECU communication were done using point-to-point wiring. That changed with the introduction of the Controller Area Network (CAN), which allowed for a minimization of the wiring needed for ECU communication [4].

Nowadays there can be as much as 70 ECUs in a single vehicle [5, 6]. The amount of code needed to handle all functionality is estimated to be circa one gigabyte year 2012 [6].

Now when the vehicle itself had been internally networked, the next big technological breakthrough has been (or is going to be) the external networking of the vehicle. There is a vast amount of ended and present research projects that aim to utilize the possibilities of vehicle external networking, a few examples of projects are:

(20)

• Cooperative Vehicle-Infrastructure Systems (CVIS) • Cooperative Systems for Road Safety (SAFESPOT)

• Preparation for driving implementation and evaluation of C2X com-munication technology (PRE-DRIVE C2X)

• Co-operative Systems for Intelligent Road Safety (COOPERS) • Secure Vehicular Communication (SeVeCom)

• Network on Wheels (NoW), ended 2008

• Preventative and Active Safety (PReVENT), ended 2008 • E-safety vehicle intrusion protected applications (EVITA)

Several applications have been suggested in combination with the exter-nal networking of vehicles, most in the area of cooperative safety and road efficiency [7, 8].

1.2 Motivation

Both the in-vehicle and the vehicle-to-X1 (V2X) communication possibil-ities opens up for a higher propagation of faults and a far greater attack surface2 _{in a vehicle. This has been noted by some of the above mentioned} research projects that have focused extensively on securing V2X communica-tion [9, 10]. An example of such a project is the EVITA project that started in July 2008. EVITA has the objective to create a on-board network archi-tecture (i.e. in-vechicle) where security relevant components are protected against tampering and sensitive data are protected against compromise [11].

But how do we know when a network or a component has been com-promised and malicious activity is taking place? The EVITA project is bringing intrusion protection into the vehicle system (as described by the full project name; ”E-safety vehicle intrusion protected applications”) to protect the vehicle system from being compromised.

What we think is lacking is the security awareness3 within the vehicle computer system. If the system is compromised although the intrusion prevention is present we need to be able to identify faulty behavior.

This is where the FORTIS project [12] comes into play. The second work package addresses security failures at run-time by developing mechanisms to detect and handle them, which leads to an increased security awareness at run-time.

1_{Communication between vehicle and other arbitrary entity capable to communicate}

with the vehicle.

2_{An attack is a malicious action. An attack surface describes the number of points in}

a system where an attack can occur.

3_{Security awareness is an ambiguous term. Its exact meaning in this context will be}

(21)

3

1.3 Definition of problem

The motivation in Section 1.2 raises the obvious question of how to achieve security awareness in vehicle computer systems. This thesis begins the process of achieving security awareness in vehicle computer systems by an-swering the following questions:

Problem statement 1: What are the threats toward commercially avail-able and envisioned vehicle computer systems?

Problem statement 2: What has been done to address the identified threats toward commercially available and envisioned vehicle com-puter systems?

1.4 Methodology

In order to answer the first of our two questions we will perform a threat analysis.

We want to achieve a connection between stakeholder goals and threats toward the target system. We found the Risk Management Framework (RMF) [13], which allows for such a connection. The RMF is divided into five steps where we are interested in the first two; 1) Understanding the business context, and 2) Identify and link business and technical risks. How-ever, due to a lack of information we needed to modify the RMF for threats rather than risks (see Section 1.5). The figures 1.1a and 1.1b illustrates the differences between the RMF and our methodology, the threat mitigation activity is not included in this thesis.

Business Context Understand the Business Context Identify and link the Business and Technical Risks Synthesize & Ranks the Risks Define the Risk Mitigation Strategy Artifact Analysis Carry out Fixes and Validate

(a) Risk Management Framework methodology.

Business Context Stakeholder

Threats Technical Threats Threat Mitigation

(b) Adaption of the RMF for our threat analysis.

(22)

We therefore first analyzed the business context to identify stakeholder goals and threats toward those goals.

In order to identify the threats toward our target system we used two methodologies in combination. A fault tree analysis (FTA) that used the threats toward the stakeholder goals as root nodes for the fault trees. Vul-nerabilities/failure events in the target system was deduced from the root nodes in the fault trees. The resulting vulnerabilities and failure events can be exploited by an adversary. The exploitation is illustrated using misuse cases to model threats toward the target system.

The information used in the analysis has been gathered from various research projects e.g. CVIS, SeVeCom and EVITA [7, 10, 11] (for target system and applications) and from Volvo Cars company (for manufacturer business goals and applications).

1.5 Delimitations

The focus of this thesis has been on the in-vehicle computer system, it is therefore not guaranteed that all threats for the Intelligent Transportation Systems (ITSs) have been identified. The ITS is the system that allows for communication between vehicles and between vehicles and infrastructure.

The lack of insight into automotive companies, due to company secrecy, led to a lack of detailed system knowledge and a lack of knowledge about economic values. This lack led to the modification of the RMF from a risk analysis into a threat analysis. A risk is in this work defined as likelihood of occurrence times impact of a specific event. To perform a risk analysis we would therefore need detailed system knowledge to estimate the likelihood of occurrence and economic values for handling failures to be able to estimate the impact of a specific event. Without those two components we cannot perform a risk analysis. However, a threat analysis is possible to perform with a general system knowledge and will result in events which we need to be aware of.

1.6 Disposition

The thesis is outlined as follows:

Chapter 1 presents the introduction, problem statements and the method-ology used for this thesis.

Chapter 2 provides background and basic concepts which is necessary for the understanding of the thesis.

Chapter 3 initiates the threat analysis by identifying stakeholder goals and threats toward the stakeholder goals.

Chapter 4 continues the threat analysis by using the threats toward stake-holder goals as a basis for identifying threats toward the target system.

(23)

5

Chapter 6 provides a discussion of threat modeling processes used in au-tomotive security research. A discussion of the research addressing the identified threats is also provided.

(24)

(25)

Chapter 2 Background - Basic

concepts

The aim of this chapter is to provide necessary basic concepts and definitions for the continued reading of this thesis. The chapter will include a brief introduction to information security, in-vehicle network components and intelligent transport systems (ITS).

2.1 Information Security

When talking about IT security, especially in systems which deploys IT safety measures, it is important to highlight the differences between the two concepts. We will adopt the view of the two concepts as in Wolf (2009) where IT security means protection against malicious manipulations whereas IT safety protects against random failures in the system [14].

2.1.1 Security Properties

There are three key aspects of information security which are the corner stones of most other security concepts:

• Confidentiality • Integrity • Availability

These three concepts will be described shortly. There are however a few more concepts which needs to be defined so the ambiguity of interpretation is mitigated.

• Authentication • Authorization • Privacy

• Nonrepudiation

The seven mentioned concepts are described in Table 2.1, the descrip-tions are made from common definidescrip-tions of the concepts [15, 16, 17].

(26)

Table 2.1: Information security concepts.

Concept Description

Confidentiality Confidentiality is defined as the concealment of in-formation or resources. It can also be formulated as the act of keeping unauthorized users from learning (possibly) sensitive information.

Integrity Integrity is defined as the trustworthiness of data or resources. Another definition used for integrity is that the data state is the same as in the data source and has not been exposed to accidental or malicious alteration or destruction.

Availability Availability is referred to as the ability to use in-formation or resources as desired.

Authentication Authentication is to establish the validity of a claimed identity. It can also involve a concept of freshness of the message which would mitigate the threat of replaying old messages.

Authorization Authorization is the process of establishing some-one’s right to perform a certain action.

Privacy Privacy is a special case of confidentiality and refers to the concealment of personal information. An example of privacy data in the context of vehicle systems can be GPS data which can reveal travel patterns.

Nonrepudiation Nonrepudiation means that a party cannot repu-diate an event since there is unforgeable evidence from the event. Digital signatures provides evi-dence which cannot be repudiated and also can be verified by a third party. Most often we will apply nonrepudiation in the case of origin of a message. Digital signatures will be described later in this Chapter.

2.1.2 Threat

The semantic meaning of the word ”threat” is often overlooked and the word has been defined in many ways in todays literature [13, 15, 16]. We will in this section make it clear what we mean when we say attack or threat.

A threat is in this thesis constituted by a) a threat agent (e.g. attacker) who utilizes b) a method with which to reach c) an objective [18].

The attacker will always be thought of as a human which utilizes different means to carry out an attack e.g. viruses, jamming equipment and rogue hardware. The objective stems from the attacker carrying out the attack

(27)

9

and can be for example financial gain, intellectual gain or being destructive. In Chapter 3 we will look closer into the business/personal goals and their corresponding attacker objectives. It shall be noted that an attacker in this thesis is defined as a person with a malicious intent and not a non-malicious person causing a failure by accident (creatively described by Bishop (2003) as a fat-finger error).

2.1.3 Vulnerability

A vulnerability is a weakness in a system that can be exploited [16, 19]. The exploitation is the instantiation of a threat which through a threat method exploits a vulnerability.

2.1.4 Threat Analysis

When conducting a threat analysis we are interested in identifying threats related to our target system. That is, for our target system we want to identify an attackers objective and how the attacker can carry out that objective. This can be done in several different ways as described in Chapter 4.

2.2 In-Vehicle Computer System

Most people do not think much about the amount of processors that exists in a single vehicle system, and even less about how the processors interact with each other and other in-vehicle units. This section will give an overview of the different components and their role in the vehicle computer network. We will also briefly mention the domains of the in-vehicle network [5].

2.2.1 Electronic Control Unit

An electronic control unit (ECU) is a microprocessor that hosts one or more application components. An ECU can be connected to a CAN or LIN bus which allows it to communicate with other ECUs, sensors and actuators.

2.2.2 Controller Area Network

The CAN is a multimaster broadcast bus solution which allows ECUs to communicate with each other [20]. The CAN is explained in greater detail in Appendix B where a CAN error model is presented.

2.2.3 Local Interconnect Network

The local interconnect network (LIN) is a vehicle bus standard that has a low bandwidth and is therefore mostly used to connect sensors and actuators to ECUs [21].

(28)

2.2.4 Actuators

An actuator is a mechanical device which may take input from an ECU and perform actions depending on the received inputs. An actuator is connected to an ECU via a LIN bus [22].

2.2.5 Sensors

A sensor is a device that measures a physical quantity (e.g. distance, fuel levels), converts the measured value into a signal and transmits the signal to an ECU. A sensor is connected to an ECU via a LIN bus [22].

2.2.6 Power Train Domain

The power train domain mainly handles engine control. With engine control we mean handling of requests from the driver (e.g. speeding up and braking) and to optimize parameters it was given when manufactured (e.g. fuel consumption) [5].

2.2.7 Chassi Domain

In the chassi domain we find systems which controls the interaction between the vehicle and the road (e.g. wheels and suspension). In this domain we also find several safety systems e.g. Anti-lock Braking System (ABS) and Electronic Stability Programme (ESP), which must be reliable [5].

2.2.8 Body Domain

The body domain includes the functionality which is not connected to its progression. Here we find functionality to control windows, blinkers, seats, mirrors and so on. We also find the door functionality in this domain i.e. locking and unlocking functions [5].

2.2.9 Telematic, HMI and Entertainment Domain

The three concepts of telematics, HMI (Human-Machine Interface) and en-tertainment all fit well together in one domain. The telematics part is responsible for the communication with external entities such as road in-frastructure and other vehicles. HMI systems are in a sense an extension of the telematics communication to involve the driver in some functionality. Such functionality can be web surfing and voice calls which are made using the telematics communication channels. Entertainment is more or less just an application of the two previously mentioned concepts of telematics and HMI although entertainment can be more dedicated systems such as DVD players and LCD screens in the backseat [5].

2.3 Intelligent Transportation System

ITSs are probably one of the most researched automotive areas today. Two important goals of these systems is to create applications which can help to

(29)

11

reduce the environmental impact and the number of fatal accidents on the road [23].

2.3.1 In-Vehicle Computer System

The in-vehicle computer system consists of a unit which is responsible for the external communication (this unit has a different name depending on which project one is looking at); we will call this unit the ”communica-tion unit”. The communica”communica-tion unit is responsible for all communica”communica-tion with infrastructure and other vehicles. In addition to the communication unit there is a gateway which separates the communication unit from the in-vehicle network. The vehicle system can also include application units which are responsible for ITS applications [7, 11, 24]. Figure 2.1 illustrates the total vehicle system. The vehicle system will be described in detail in Chapter 4.

Powertrain Controller Chassis & Safety Body Electronic Head Unit (Telematics) Communication Unit Diagnostic interface USB Bluetooth UMTS DSRC GPS/ Galileo ECUs Actuators & Sensors

Figure 2.1: Vehicle system with communication unit and in-vehicle network.

2.3.2 Roadside Units

A roadside unit (RSU) consists of at least one or two gateways which allows a vehicle to communicate with a larger infrastructure e.g. other RSUs, the Internet and other provided services. In addition to the gateway(s) a roadside system can consist of application units which are connected to installations such as other RSUs, road tolls, traffic lights etc [7, 24].

2.3.3 Central System

A central system is responsible for cooperative applications and other pro-vided vehicular services. As described in the CVIS project there can be several ”centres” within a central system, e.g. service centres, application management centres and content centres [25].

(30)

(31)

Chapter 3 Threat Identification on

Stakeholder Goals

The first hurdle when conducting a threat analysis on a system is to decide where to start. We are, besides identifying threats, interested in being able to show a commercial company how the threats we identify can affect them. Such a framework, the Risk Management Framework (RMF), was proposed by McGraw (2006) [13]. The first step in the RMF is to understand the business context. When the business context is understood (i.e. the business goals for a stakeholder is found) the second step is to identify business risks and technical risks4 _{and link them together. However, the RMF was} designed for risk analysis which needs information about likelihood and impact of an event. Those two event properties are however hard to estimate without detailed knowledge about systems and economical values connected to an event. Therefore we will instead of risks focus on threats toward stakeholder goals. We modified the RMF to accommodate for a threat analysis instead of a risk analysis.

The aim of this chapter is to identify threats toward stakeholder goals which will be used to guide the threat analysis on the vehicle computer system.

3.1 Stakeholders

We will focus on the manufacturer and the owner of a vehicle system as stakeholders. There are several other stakeholders which can be included (e.g. dealers and authorities) [26]. The choice of stakeholders is mainly because we believe that those two stakeholders are the main stakeholders of a vehicle system.

3.2 Adversaries

As well as stakeholders there are entities which aim to misuse the vehicle computer system to reach different objectives. Adversaries and their

objec-4_{A risk is here defined as likelihood of occurrence times impact for an event.}

(32)

tives have been researched by others in the research community, we will in this section look into their findings and list the adversaries together with their possible objectives.

The EVITA project and the eSecurity working group both list possible adversaries with some objectives without going in to details about the risk they pose [27, 26]. See Table 3.1 for a list of adversaries found by the two projects.

Table 3.1: Adversaries found by EVITA and the eSecurity WG.

Adversary Objective

Dishonest drivers Gaining traffic advantages, avoid financial obliga-tions.

Malicious hackers Gaining reputation, thrill, curiosity.

Criminals, terrorists

Financial gain, tracking vehicles/persons, harm-ing people.

Dishonest organizations

Industrial espionage, sabotage

”Rogue states” Achieve economic harm to other societies

Wolf (2009) provides a more detailed list of possible adversaries and classifies them depending on several resources. See Table 3.2 for a list of adversaries found by Wolf (2009). He divided the adversaries into four different classes; three internal I1, I2 and I3 and one external E0. The internal classes are partitioned depending on the attack power the adversary possesses. The internal adversaries are all considered to be legitimate user of the attacked system [14].

In Table 3.1 and Table 3.2 we have seen that there exist incentives for dif-ferent entities to perform malicious acts towards vehicle computer systems. We will in the rest of this thesis focus on the threats from a stakeholder’s point of view, how the stakeholder can be affected and in what ways.

3.3 Stakeholder Goals

In this section we aim to identify the goals of our chosen stakeholders, the manufacturer and the owner. The goals will be used to identify threats toward them to guide further threat analysis. Stakeholder goals are fairly abstract and describes what the stakeholder wants the system to achieve. This is closely related to the term non-functional requirements that de-scribes how functionality in a system shall operate [28]. For example, in a vehicle there are several mechanisms implemented to increase the per-cepted safety of the vehicle (e.g. ABS brakes and airbags). In the example safety is a non-functional requirement and the mechanisms implemented to

(33)

15

Table 3.2: The table is an extract from the original table of adversaries found by Wolf (2009).

Attacker I1 Attacker I2 Attacker I3 Attacker E0

Example attackers Driver, owner Garage personnel Organized crime, rival, academia Thief, exter-nal hacker Technical Resources Generally low Medium to high Virtually unlimited Varying, usually low to medium Knowledge Resources Generally low Medium to high

Very high Varying, can be high

Financial Resources

Low Medium Very high Generally low

increase the safety are described by functional requirements. Functional requirements describes what a system must do i.e. reaction to input [29].

3.3.1 Manufacturer

For the rest of the stakeholder threat analysis we will use Volvo Cars as example manufacturer and identify their business goals related to vehicle systems. Volvo Cars states their goal as:

To sell cars with good profitability in the premium segment [30]

To achieve their goal, Volvo Cars use their most important values as a guideline. See Table 3.3 for a list of values and their descriptions.

Table 3.3: Values for Volvo Cars, based on Volvo Cars Corporation’s annual report [30].

Company values Description

Safety Volvo Cars has a tradition of making safe cars with innovative safety solutions. They have their own safety centre where they test vehicle systems, sim-ulate and reconstruct accidents. They also have safety requirements from the Swedish authorities which they always pass. An example of forefront safety is that Volvo has integrated an alco lock to minimize the number of drink driving accidents.

(34)

Quality For Volvo Cars quality equals satisfied customers. Quality includes the whole experience with a Volvo car, the car itself, ownership of the car, the service of the car. The average life expectancy of a Volvo car is 18.6 years.

Design Volvo Cars’ design philosophy states that ”Good design is not just about the good looks. It is equally important that the product is user friendly and log-ical. The product can never be beautiful unless it is functional.”

Environment Volvo Cars is working on minimizing the use of fossil fuels in their cars, as well as making the cars less hazardous for those who suffers from allergies and asthma. The company considers the environ-mental aspects of their cars through the whole life cycle of the car, the manufacturing of a car, the company suppliers and the recycling of a car.

Excitement Travelling in a Volvo car should not be a boring ex-perience, therefore Volvo Cars have tried to max-imize the comfort of driving a Volvo car. For the passengers comfort there is a high end sound tem as well as the possibility of a infotainment sys-tem for movies, televisions and video games.

Using this information about Volvo Cars’ goal and their most important values we can identify Volvo Cars’ business goals.

Table 3.4: Manufacturer goals for Volvo Cars company. Information gath-ered from Volvo Car Corporation’s annual report [30].

Rank High-Low

Manufacturer goal

Description

High Excel at safety Volvo Cars’ most important value is safety, this value is the one which is used most in marketing their cars. Volvo Cars have a vision that no one will be seriously injured or killed in a new Volvo car by 2020. In the current company report Volvo Cars states that its cars in 70 % of performed safety sur-veys got the highest mark.

(35)

17

Moderate Deliver cars with a useful design

Volvo Cars is marketing its cars by stat-ing that a design shall be functional. The company wants its customers to experience control and a good driving feel when driving a Volvo car.

Moderate Fulfill participa-tion in environ-mental initiatives

Volvo Cars supports national and in-ternational initiatives to promote re-search for more environmental friendly cars. Volvo Cars’ vision for environ-ment is ”Drive towards zero”, which means that the company aims to de-velop cars free from hazardous emis-sions that has a negative effect on the environment.

Moderate Deliver cars which stands up to the expectations on quality from the company and the customers

Quality is one of the business goals of highest importance to the external stakeholders of the company, e.g. cus-tomers of Volvo Cars. The importance of quality to both the external stake-holders and the internal stakestake-holders combined with the company value to deliver cars with ”premium quality” makes quality an important business goal to fulfill.

3.3.2 Owner

The owner of the vehicle has other goals with the vehicle than the manu-facturer. The goals of the owner are somewhat related to the goals of the manufacturer since the owner trusts the manufacturer to deliver what the owner expects from the specification of a car.

Table 3.5 states some personal goals that an owner might have regarding a vehicle system. The goals are assumed from the authors point of view and are not necessarily the same for every individual owner of a vehicle.

(36)

Table 3.5: Owner goals with owning a car.

Rank High-Low

Owner goal Description

High Functionality When owning a car one of the main goals is that the owner shall have the possibility to use his car when he wants to use it without having to worry about it not functioning as specified by the manufacturer.

High Ownership A car owner wants to be sure that he is the only one that can get in to the car when he has control of the car keys.

High Safety A car owner wants his car to be safe to drive. The safety aspect includes that the systems are functioning prop-erly and does not fail in unexpected ways.

Moderate Functional integrity

No one shall be able to modify the func-tionality of the car without the consent of the owner.

Moderate Sustainability If a car owner takes care of his car as recommended by a manufacturer he wants it to keep its functionality and performance without significant degra-dation for a long time.

Moderate Functional design As an owner you want the car to be easy to drive, you do not want the has-sle with controls for the AC, the radio etc. which makes the driving less safe.

Low Comfort An owner wants his new car to be com-fortable to drive.

Low Data availability An owner might store data in his vehi-cle if possible. In that case he wants the data to only be available to autho-rized persons and not available to any-one that does not have legitimate access to the vehicle and the data.

(37)

19

3.4 Threats to Stakeholder Goals

Our stakeholder threat analysis is focused on information security in vehicle computer systems. We will therefore limit the stakeholder threats to those that are related to the vehicle computer system.

The stakeholder threats are described using a threat objective from an attacker’s perspective and a threat consequence for the related threat ob-jective.

3.4.1 Manufacturer

Firstly we need to identify business threats that directly affect the manufac-turer goals. The threats toward the manufacmanufac-turer goals are then connected to specific technical threats. The relation between manufacturer threats and technical threats are described in Chapter 4.

Table 3.6: Threats toward manufacturer goals.

Threat objective Threat consequence

Higher amounts of accidents.

A higher amount of accidents involving a Volvo car will affect the premium offered by the insurance companies as well as Volvo’s reputation of being a manufacturer of safe cars.

Lower functionality Tampering with the functionality may lead to re-duced functionality and higher amount of acci-dents. The consequences of tampering might occur for both an attacker with the stated threat objec-tive and for an owner with the the objecobjec-tive of increasing the functionality.

Lower performance Tampering with the engine settings may lead to reduced fuel efficiency. Engine tampering can also be conducted by the owner with the objective of increasing the engines performances, the conse-quences can however be the same.

Dispersion of inter-nal software

Dispersion of internal software may lead to other manufacturers taking advantage of the knowledge and offer better internal software. Dispersion can also lead to liability issues with other software providers. Other more specific problems with dis-persion of software is that an attacker may be able to affect the systems behavior in specific ways if the attacker understands how the system works inter-nally.

(38)

3.4.2 Owner

As with the manufacturer threats, the owner threats directly affect the owner’s goals on the vehicle system.

Table 3.7: Threats toward owner goals.

Threat objective Threat consequence

Lower functionality An adversary wants to degrade the functionality of certain systems to either cause discomfort for the owner or to cause harm. The owner might want to change some functionality in a way he sees as better, thus he can modify the software intention-ally to do as he want. Such changes can have side effects which might not be visible to the owner. The lower functionality may lead to lower safety depending on which modifications that have been made.

Lower sustainability

An adversary modifies engine settings to cause the car to use more fuel or wear out components quicker than with the manufacturer settings. The owner or another entity might introduce software modifications which for example might aim to in-crease performance but also puts a higher load on the system. A higher load might in turn lead to a lower sustainability and/or higher maintenance cost.

Overtaking ownership

If the authentication software for the opening of the car fails the integrity and the ownership of the vehicle is in danger.

Dispersion of personal data

If the software fails to keep unauthorized entities from entering the system it may lead to the dis-persion of personal data such as GPS data, info-tainment data etc. thus endangering the person in other ways. Dispersion of personal data may also endanger the ownership of the vehicle if the remote unlocking application makes use of e.g. passwords or secret keys.

(39)

21

3.5 Summary

The goals and threats that have been identified are not to be seen as gen-eral goals and threats for the entire automotive industry. They have been identified to guide the technical threat analysis and to show that it is pos-sible to relate technical threats to the stakeholders’ goals. The stakeholder threats that we have identified will be used in the first part of the following technical threat analysis.

(40)

(41)

Chapter 4 Threat Analysis on

Vehicle Computer System

This chapter contains the threat analysis for the vehicle computer system. We are firstly going to define our target system for the threat analysis so we know what to apply our analysis methodology on. Secondly we will apply our threat analysis method on the target system. The analysis method used is a combination of two methodologies, FTA and misuse cases. The stakeholder threats identified in the previous chapter will be used as top events in the FTA in this chapter. The use of stakeholder threats as top events directly connects a threat with a stakeholder threat which in turn is directly connected to a stakeholder goal. This connection gives a clear view of how a stakeholder goal can be affected by a threat towards a vehicle computer system.

What we want to achieve with the threat analysis is a set of threats toward the vehicle computer system which then can be summarized into classes of threats.

The resulting fault trees from this chapter are available in Appendix A.

4.1 Target System for Threat Analysis

Before we start with our threat analysis on vehicle computer systems we need to know what system we are analyzing. The target system for the threat analysis is divided into two parts; one consisting of the in-vehicle computer system and the other consisting of the ITS. The difference between them is that the in-vehicle computer system is restricted to a single vehicle while the ITS goal is to interconnect vehicles and infrastructure. We will see that the two parts are not completely separated since there are ITS applications for e.g. cooperative safety that make use of in-vehicle data to work properly.

4.1.1 In-Vehicle Computer System

Due to the lack of knowledge about specific architecture, specific technolo-gies and topolotechnolo-gies used in vehicle computer systems we will adopt a

(42)

alized view of in-vehicle network architecture. The EASIS [31] and EVITA projects both addresses security issues in in-vehicle systems, both projects provides a generalized in-vehicle network architecture. We will use the pro-vided network architectures from EASIS and EVITA to model an in-vehicle network architecture for the threat analysis in this thesis.

The EASIS project makes use of a network architecture that consists of four domains; Body, Powertrain, Chassis and Telematics. The four do-mains in EASIS are connected by one or two FlexRay buses [32], although FlexRay is not extensively used today [33]. The EVITA project has built its generalized network architecture from the EASIS architecture. There is however a small but very crucial addition to the EASIS architecture made by EVITA; the Communication Unit [27].

The Communication Unit enables the vehicle computer system to com-municate with surrounding entities. In this model the communication may be for example a) Vehicle-to-Vehicle (V2V) b) Vehicle-to-Infrastructure (V2I) c) Vehicle-to-Internet d) Vehicle-to-Handheld devices. This extension of the EASIS architecture brings up a lot more security issues related to commu-nication, this is well described by Papadimitratos et al. (2008a) and in publications made by the NoW project [9].

See Figure 4.1 for an illustration of the generalized network architecture based on the EASIS and EVITA projects.

Powertrain Controller Chassis & Safety Body Electronic Head Unit (Telematics) Communication Unit Diagnostic interface USB Bluetooth UMTS DSRC GPS/ Galileo ECUs Actuators & Sensors

Figure 4.1: Simplified general network architecture created from the EASIS and EVITA projects.

The communication unit in Figure 4.1 is not commercially available today and is the addition to the vehicle computer system which will make it possible to deploy ITSs.

(43)

25

4.1.2 Intelligent Transportation System

Current research projects within the European 7th _{Framework Program} aims at developing systems which makes use of V2V and V2I communication (enabled by having a communication unit in the vehicle) [7, 24]. The ITS applications being researched can be divided into three groups; 1) Safety 2) Mobility and 3) Commercial/OEM use [24]. The applications extend the ”reach” of a single vehicle computer system to contain other vehicles and infrastructure units which interacts with the vehicle computer system. Figure 4.2 illustrates the communicating entities related to the ITS model. Figure 4.2 also illustrates the four communication domains which are described by the PRE-DRIVE project; 1) ITS Ad Hoc Domain 2) ITS Roadside Infrastructure Domain 3) Internet Domain, and 4) Service Domain [24]. Internet RSU RSU Service Centre Authorities Home Agent Control Centre 1 2 3 4

Figure 4.2: ITS model as described by the CVIS project [7].

4.1.3 Applications

The applications in the target system have been taken from the specification of Volvo XC60 [34]. We will mainly focus on the safety systems in the vehicle and model the applications behaviors from the semantic descriptions in the specification. Table 4.1 lists the applications considered in the analysis.

(44)

Table 4.1: Safety applications in Volvo XC60

Application Description

City Safety City Safety is a system designed for urban driving safety. The system senses if a vehi-cle 6-8 meters in front of you is moving slower than your vehicle and prepares the brakes for a faster reaction. If the driver does not brake the system will automatically brake to avoid a collision.

Adaptive Cruise Control (ACC)

ACC is a system created to help drivers keep-ing the distance while drivkeep-ing at higher speeds than 30 km/h. The system takes the desired speed and minimum time to the vehicle in front and adapts the actual speed to the vehicle in front.

Collision Warning with Automatic Braking (CWAB)

CWAB is a system designed for freeway driv-ing. The system monitors the road 0-150 me-ters in front of the vehicle and warns the driver if there is a risk for collision. If it is not pos-sible to avoid the collision the CWAB system will activate the brakes to mitigate the colli-sion.

Driver Alert Control (DAC)

DAC is a system that makes use of a digital camera that reads the road markings and com-pares the drivers driving behavior with the ac-tual behavior of the road. If the driver starts to depart from his ordinary driving behavior the system will warn the driver.

Lane Departure Warning (LDW)

LDW also uses a digital camera to keep track of the road markings but in this case to help the driver to avoid collisions out of temporary distractions. If the car starts to move out of its lane without any use of the direction indicators the system will warn the driver.

Dynamic Stability with Traction Control (DSTC)

DSTC uses sensor values to compare the di-rection and the inclination of the car to the steering wheel movements made by the driver. DSTC then uses the information to calculate if there is a risk of a skid or a rollover and then uses the brakes to try to avoid such situations. Continued on next page. . .

(45)

27

Intelligent Driver Information System (IDIS)

IDIS is a system that constantly monitors the traffic situation. When it detects a critical traffic situation it blocks all signals that may distract the driver during the critical situation. Such signals may be for example an embedded telephone.

Roll Stability Control (RSC)

In the case of evasive actions the RSC system calculates the risk of a rollover and uses the brakes to improve the balance of the car. Blind Spot

Information System (BLIS)

BLIS is a system that helps the driver to keep track of vehicles that he cannot see using the driving mirrors. The system warns the driver with an indicator lamp when it senses a vehicle in the blind spot.

Ready Alert Brakes (RAB)

RAB is a system that predicts hard braking and prepares the brakes for a quicker reaction. Electronic Brake

Distribution (EDB)

EDB is a system that distributes the brake force distribution between the wheels to obtain an optimum result depending on the driving conditions.

Cooperative Safety Systems5

Cooperative systems are envisioned to improve road safety and optimize the road traffic (thus decreasing vehicle emissions). The systems rely on I2V, V2I and V2V communication to disseminate information which will be used to assess traffic situations and make decisions about driving route or road safety [26].

4.2 Analysis Methods

This section will list some known analysis methods and evaluate their use-fulness in the context of vehicle computer systems. A short introduction to each method is provided together with advantages and disadvantages for performing a threat analysis using the method on the vehicle computer system.

5_{The cooperative systems are not a part of the Volvo XC60 systems but are considered}

as important for e.g. future safety applications and are as such included in this target system.

(46)

4.2.1 Attack Trees

Attack Trees is a threat modeling method6_{, and it got advantages over most} of the other of the discussed methods. Attack trees is used to model how an attacker can reach his goal, i.e. the attack goal (which in this analysis is a business threat). The goal is used as root node and the necessary measures are deducted from there [35]. The use of attack trees opens up for an approach using the business threats as attack goals and from there deduct how the attacker can realize the threats against stakeholder goals. A disadvantage however, is that the trees easily becomes very large for complex systems. The method is used in the EVITA project to decompose an attack goal into asset attacks for which the probability of success can be estimated [27].

4.2.2 What-if/Checklist

A What-if/Checklist is a combined analysis of the ”What if” and ”Checklist” methods. The ”What if” method is performed by postulating a situation and asking ”what if ...” questions. By using such questions the ”What if” method is highly dependent on the investigators’ imagination, experience and understanding of the system.

The checklist analysis method makes use of a checklist where items are listed and consequences, present safeguards and necessary actions are doc-umented for each listed item. The checklist analysis method requires a checklist to be present, either by reusing one already available or by con-structing a new checklist customized to the target system. In order to be able to create a checklist, an extensive understanding of the target system is required [36].

The What if/Checklist method is not especially suited for the analysis of a complex target system as in this thesis since there is no access to existing checklists (if they exist at all). Our knowledge about the target system is lacking sufficient detail for a What if/Checklist analysis to produce good results.

4.2.3 Event Tree Analysis

Event tree analysis takes an initiating event which is defined as a signifi-cant deviation from a normal situation. Such an event can have unwanted consequences, which are identified using induction from the initiating event [37]. To identify the set of initiating events there is a need to perform for example Preliminary Hazard Analysis on the target system [36], which in turn requires a good knowledge about the low levels of the system to be able to identify initiating events. The knowledge on the appropriate level of resolution is in this thesis too limited for event tree analysis to generate useful results.

6_{Threat modeling is what Bruce Schneier who invented Attack trees calls the method.}

Threat modeling is, according to Schneier (2000), in its basic form what we call threat analysis in this thesis [35].

(47)

29

4.2.4 Failure Mode and Effects Analysis

Failure Mode and Effects Analysis (FMEA) is an inductive risk analysis method in which the system being analyzed is divided into components. Each component is then analyzed to find failure modes and the effects of the failure modes [38]. The advantage with FMEA is that a relatively complex system can be divided into smaller components which are easier to evaluate. FMEA is used in the aviation industry and is considered an important tool [39]. FMEA is also used in the automotive industry for verification purposes [40]. A drawback with FMEA that relates to this thesis is that FMEA is a bottom-up approach where failure modes are identified/postulated and the effects of those failures are identified. To identify/postulate failure modes an extensive and detailed understanding of the system is required. The target system for this thesis is a more abstract picture of the real system than what would probably be optimal for a FMEA.

4.2.5 Misuse Cases

A misuse case can be seen as a security awareness extension of a use case7_. Misuse cases highlights possible unwanted behavior in a system and are used to elicit security requirements for a system [41]. As with use cases the involved actors, their interaction with the system and the systems behavior are illustrated in a way easy to understand. Misuse cases can be used as starting point for a method to break down the identified unwanted behavior or it can be used to complete vulnerabilities into threats.

4.2.6 Fault Tree Analysis

Fault Tree Analysis (FTA) is a deductive method which uses a ”top event” and then deduces the causes to that event. FTA allows for the use of stakeholder threats as top events and then deduces the causes to those events. FTA has the advantage of being able to identify multiple-event failures, i.e. where several causes must occur in order for a top event to happen [38]. The difference between attack trees and fault trees is that attack trees describe the attacker’s possible methods of attack while the FTA describes the system’s vulnerabilities and failure events. Fault trees has the same drawback as attack trees in that the generated trees may grow very large for complex target systems. Like FMEA, FTA is used in both the aviation and automotive industry for various purposes [39, 40].

4.2.7 Zurich Hazard Analysis

Zurich Hazard Analysis (ZHA) makes use of either a ”Tickler list” or ”Path-ways” to guide the hazard identification. The ”Tickler list” is non-structured and requires a team of system experts to produce a good result. The ”path-way” method is appropriate where there are clear and distinctive flows through the system [42]. In complex information systems there may be a lot of flows and subflows to consider, which makes the ZHA insufficient. A problem by using ZHA for the threat analysis in this thesis is the lack of

(48)

knowledge regarding the topologies deployed in the vehicle computer sys-tem. This lack makes it impossible to accurately evaluate information flows in the system.

4.2.8 Conclusion

Out of the analysis methods discussed above there are three methods which are occurring in the context of automotive systems; a) Attack trees, b) FTA, and c) FMEA [11, 39]. These three methods are structured methods that are able to simplify the analysis of complex systems, which is necessary when analyzing in-vehicle networks and electronics systems.

FMEA has a drawback that a good understanding of the system and its components is necessary to decompose it into smaller subsystems and then identify the failure modes. It is not possible to detect multiple causes that together causes a failure using FMEA.

Attack trees have the drawback that only vulnerabilities that are part of an attack will be detected during the analysis. This means that if one attack is missed during the analysis all vulnerabilities/failures that cause missed attack is potentially left out of the requirements or design developed from the analysis.

Our analysis shows that FTA has an advantage over FMEA in that it is easy to connect a stakeholder threats identified in Chapter 3 with a technical threat. FTA explicitly illustrates how a vulnerability in the vehicle computer system can affect the stakeholders’ goals. Attack trees have the same advantage in its coupling to the stakeholder, except that it is only those vulnerabilities associated with an attack that are identified using attack trees. The coverage of vulnerabilities/failures makes the FTA favorable to attack trees in terms of completeness of the analysis.

A FTA will result in trees consisting of vulnerabilities/failures that can lead to a top event (i.e. stakeholder threat). However, we want the analysis to end up with a set of threats toward the target system. Therefore we will use misuse cases to model threats that exploits vulnerabilities/failures found in the FTA.

The fault trees will describe vulnerabilities that are connected to com-ponents in the system that in turn are involved in the execution of an application. The misuse cases will semantically describe the execution of the application and implicitly the interaction between the components dur-ing runtime of the application. Thus the threats are identified for each step of the execution of the application. The connection between the FTA and the misuse cases is thus the components that are involved in the execution of an application.

The combination of FTA and misuse cases will have a good coverage of system vulnerabilities/failures and illustrate the threats made possible by the vulnerabilities/failures.

(49)

31

4.3 Fault Tree Analysis: Vehicle Computer

System

The aim for the FTA is to find the single or multiple failures which can lead to an instantiation of a stakeholder threat. The starting point is therefore the stakeholder threats. Potential causes (i.e. vulnerabilities/failures) for the instantiation of a stakeholder threat are deduced from the stakeholder threat. For example, the stakeholder threat ”Higher amount of accidents” in Table 3.6 could for example indicate that a safety system deployed to reduce the risk of an accident has failed. Thus we can use the failure of each active safety system as a sub-top event [43] for the FTA with the top event ”Higher amount of accidents”. Table 4.2 lists the vehicle computer systems in which a failure can lead to the top event.

Table 4.2: Sub top-events for the stakeholder threat ”Higher amount of accidents”.

Stakeholder threat (Top event)

Sub top-events (failure in . . . )

Higher amount of accidents

• Blind Spot Information System (BLIS)

• Dynamic Stability and Traction Control system (DSTC)

• Intelligent Driver Information System (IDIS) • City Safety

• Driver Alert Control (DAC)

• Collision Warning with Auto Brake (CWAB) • Lane Departure Warning (LDW)

• Adaptive Cruise Control (ACC) • Roll Stability Control (RSC) • Ready Alert Brakes (RAB)

• Electronic Brakeforce Distribution (EBD) • Cooperative Safety Systems

4.3.1 Basics of Fault Tree Analysis

A fault tree is a model that contains combinations of fault events or vul-nerabilities, parallel as well as sequential, that lead to an undesired top event. The combination of fault events is depicted by using logical gates to connect events and transfer symbols to simplify the representation. Figure 4.3 illustrates the different event types and the symbols representing them. The definition of fault tree symbols have been taken from The Fault Tree Handbook [43].

(50)

!"#$%&'()*+ ,*-)()./0)-&_'()*+ 1*+)23)-$"+)&_'()*+ 4/*-$+$/*$*5&_'()*+ '6+)2*".&'()*+

Figure 4.3: Fault tree event symbols [43].

Basic Event describes an initiating fault that does not need to be devel-oped any further.

Undeveloped Event describes an event that is not developed any further since it either is not necessary due to the consequences or because the system knowledge is not good enough for a better resolution.

Intermediate Event is a fault event that occurs because of the occurrence of one or more of the antecedents.

Conditioning Event is an event that describes conditions that applies to a gate.

Basic Event Undeveloped _Event Intermediate _Event Conditioning _Event External Event

Transfer in Transfer out

(a) Transfer symbols.

Basic Event Undeveloped _Event Intermediate _Event Conditioning _Event External Event

Transfer in Transfer out

OR AND Inhibit

(b) Logical gates.

Figure 4.4: Transfer symbols and logical gates in fault trees [43].

Figure 4.4b illustrates the gates used to connect the events illustrated in Figure 4.3. Figure 4.4a illustrate transfer gates. Transfer gates are used to reuse sub trees in the fault trees. A transfer in gate denotes the point where a subtree (denoted by a transfer out gate) should be attached.

Transfer in is an indication that the tree is further developed where there is a corresponding transfer out symbol.

Transfer out is an indication that the part of the tree connected to the ”transfer out” symbol must be attached where there are corresponding ”transfer in” symbols.

OR is a gate that indicates that the output of the gate occurs if one or more of the input events occurs.

AND is a gate that indicates that the output of the gate occurs if all of the input events occurs.

(51)

33

Inhibit is a gate that indicates that the output of the gate occurs if the single input event occurs at the same time as the conditional event connected to the inhibit gate is fulfilled.

Figure 4.5 illustrates an example of a fault tree where the different gates and events are used.

The robber needed cash Cash was visible through the window

A robber broke it _{stone through it}A kid threw a A tree fell through _the window

Broken window Top event There was gravel outside The kid was angry There was a storm The tree blew down He did not get ice cream The house owner made him angry

Figure 4.5: Example of a fault tree using all gates and events present in this thesis.

4.3.2 Results of Fault Tree Analysis

From the resulting fault trees in Appendix A we can see that the lack of knowledge about details in the system resulted in a lot of leaves being undeveloped events. We can also see which intermediary events that are reoccurring most:

• Modified application, • Faulty sensor values, and • Communication failure

We will focus on these three sub trees during the rest of the result section. For each sub tree we have classified their sub events into one of three classes; a) Intentional, b) Unintentional, or c) Intentional or Unintentional. The events identified and their classifications are found in Table 4.3. The simple classification shows if an event is purely malicious or if there is a

(52)

possibility that an event was triggered by a transient fault. The classification can, combined with the threat consequences, rank the threats and provide information to the threat mitigation process8. The threat consequences are however hard to assess. In Appendix B we propose a model to estimate threat consequences for CAN communication threats.

Table 4.3: Event classification

Event Classification

Hardware rewiring Intentional

Hardware failure Intentional or Unintentional Modification of software using

debugging link

Intentional

Unauthorized software update/ modification

Intentional

Corrupt memory Intentional or Unintentional Modified bootloader Intentional or Unintentional Modification of data in transit Intentional or Unintentional Faulty applications Intentional or Unintentional

Rogue ECU Intentional

Viruses/malware Intentional

An illustration of the subtree for the ”modified application” event in-cluding the Intentional/Unintentional classification can be seen in Figure 4.6. The ”modified application” sub tree shows that the event of ”modified application” has seven identified causes. Each of those causes have their own causes except for ”Viruses/malware” which is a basic event.

All fault trees created for the target system with the stakeholder threats as root nodes can be found in Appendix A.

To illustrate how these vulnerabilities/failures can be exploited and used as part of a threat a set of misuse cases will be provided in Section 4.4.

(53)

35 M od ifi ed ap pl ic at io n M A U na ut ho riz ed so ftw ar e up da te / m od ifi ca tio n M od ifi ed bo ot lo ad er M od ifi ca tio n us in g de bu gg in g lin k C or ru pt m em or y W ea k au th en tic at io n m ec ha ni sm s U na ut ho riz ed up da te / m od ifi ca tio n vi a ca bl e O ve r-th e-ai r up da te p os si bl e U na ut ho riz ed up da te / m od ifi ca tio n vi a w ire le ss li nk W ea k au th en tic at io n m ec ha ni sm s W ea k in te gr ity ch ec ks U se o f ac qu ire d di ag no st ic s to ol W ea k au th en tic at io n m ec ha ni sm s E C U a cc es s co nt ro l f ai lu re E C U s ig na tu re ch ec k fa ilu re H ar dw ar e re w iri ng C or ru pt m em or y W ea k in te gr ity ch ec ks B og us au th en tic at io n ke ys in je ct ed B og us au th en tic at io n ke ys in je ct ed B og us au th en tic at io n ke ys in je ct ed In te n ti o n al / U n in te n ti o n al In te n ti o n al In te n ti o n al / U n in te n ti o n al In te n ti o n al In te n ti o n al W ire le ss co m m un ic at io n V iru se s/ m al w ar e In te n ti o n al M B A pp lic at io n m od ife d at ap pl ic at io n se rv er In te rn et co nn ec tio n W ea k se cu rit y m ea su re s In te n ti o n al E C U s ig na tu re ch ec k fa ilu re

Threat Analysis on Vehicle Computer Systems

Institutionen för datavetenskap

Department of Computer and Information Science

Final thesis

Threat Analysis on Vehicle Computer Systems

by

Christian Vestlund

LIU-IDA/LITH-EX-A--10/002--SE

2010-01-26

Linköpings universitet

SE-581 83 Linköping, Sweden

Linköpings universitet

581 83 Linköping

Final Thesis

Threat Analysis on Vehicle Computer Systems

by

Christian Vestlund

LIU-IDA/LITH-EX-A--10/002--SE

2010-01-26

Supervisor: Nahid Shahmehri

Linköping University

Department of Computer and Information Science

Examiner: Nahid Shahmehri

Linköping University

Vehicles have been around in our society for over a century,

un-til recently they have been standalone systems. With increased

amounts of initiatives to inter-network vehicles to avoid

acci-dents and reduce environmental impact the view of a vehicle as

a standalone system needs to be reconsidered. Networking and

cooperation between vehicles requires that all systems and the

information therein are trustworthy. Faulty or malicious vehicle

systems are thus not limited to only affecting a single vehicle

but also the entire network. The detection of anomalous

behav-ior in a vehicle computer system is therefore of importance. To

improve the vehicle systems we strive to achieve security

aware-ness within the vehicle computer system. As a first step we will

identify threats toward the vehicle computer system and what

has been done to address them.

We perform a threat analysis consisting of fault trees and

misuse cases to identify the threats. The fault trees provide a

way to connect the threats found with vehicle stakeholders’ goals.

The connection between stakeholder goals and threat highlights

the need for threat mitigation.

Several research initiatives are discussed to find out what has

been done to address the identified threats and to find the state

of the research for security in vehicle computer system.

Lastly, an error model for the Controller Area Network (CAN)

is proposed to model the consequences of threats applied to the

CAN bus.

I would like to thank my supervisor Professor Nahid Shahmehri

for giving me the opportunity to work on this project and for

the guidance during the work with this thesis. I would also like

to thank the rest of my colleagues at ADIT for the pleasant

work environment (especially all the cakes). My gratitude also

to Johannes Hassmund for our small discussions which always

gave some ideas. And lastly I would like to thank my father Leif

who read through my work and came with helpful comments.

Contents

List of Figures

List of Tables

Nomenclature

Chapter 1

Introduction

1.1

History

1.2

Motivation

1.3

Definition of problem

1.4

Methodology

1.5

Delimitations

1.6

Disposition

Chapter 2

Background - Basic

concepts

2.1

Information Security