Security Control Mechanism for Safety Critical Functions Operating on an Automotive Controller Area Network

A Thesis

Presented in Partial Fulﬁllment of the Requirements for the Degree Master of Science in the Graduate School of The Ohio State University

Matt Appel,

Graduate Program in Electrical and Computer Engineering

The Ohio State University

2020

Master’s Examination Committee:

Prof. Girogio Rizzoni, Advisor Prof. Ness Shroﬀ Prof. Qadeer Ahmed c Copyright by

Matt Appel

2020 Abstract

Safety-critical systems in automotive design are facing new challenges associated with advancements in autonomous functionality and connectivity. One of those challenges is security in these systems. There are a multitude of diﬀerent problems with all of these additional connectivity and sensing units. The focus of this thesis is on the internal communication of Network Control Systems(NCS) of a vehicle. The

Controller Area Network (CAN) is the primary network used in safety-critical vehicle operation and is lacking inherent security. This thesis presents a security control mechanism for CAN that uses vehicle models to detect and mitigate malicious messages on CAN. The security control mechanism is an Intrusion Detection System

(IDS) that uses an unknown input observer implementation to address stealth, replay, and covert attacks. The goal of this method is to address performance challenges in the authentication of an entire CAN bus. It uses vehicle dynamic behavior to authenticate messages rather than using encryption methods to require CAN message authentication when the vehicle is not under attack reducing the burden caused by implementing and continually using secure communication protocols on top of CAN.

A case study on a throttle control request of an engine by an Autonomous Vehicle

Control Unit (AVCU) test and demonstrate the security control mechanisms.

ii Dedicated to my family: mother Teresa Appel, father Andrew Appel, and brother

Jason Appel for providing their support, their motivation, and their time to help me

achieve my goals.

iii Acknowledgments

I would like to thank all of my colleagues at The Center for Automotive Research for there great support and all of the opportunities that they have provided. I want to also thank Dr. Qadeer Ahmed and Pradeep Oruganti for all the support over the past couple years. The creation and development CyberSecuirty@CAR Lab has been a challenging and rewarding task and I am thankful o have been apart of that team. I would also like to thank my parents and family for there continued support in getting me to this point. No matter what they have always been there for me and supported my dreams and goals. I will forever be grateful to everyone who has helped me throughout this process, without the proper opportunities, support and guidance none of this would have been possible.

iv Vita

February 17, 1995 ...... Born - Mayﬁeld Heights, USA

2018 ...... B.S. Electrical and Computer Engineer The Ohio State University 2018-present ...... Graduate Research Associate, The Ohio State University: Center for Automotive Research

Publications

Appel, Matthew Andrew, and Qadeer Ahmed. Intelligent Vehicle Monitoring for Safety and Security. No. 2019-01-0129. SAE Technical Paper, 2019.

Oruganti, Pradeep Sharma, Matt Appel, and Qadeer Ahmed. ”Hardware-in-loop based Automotive Embedded Systems Cybersecurity Evaluation Testbed.” In Pro- ceedings of the ACM Workshop on Automotive Cybersecurity, pp. 41-44. 2019.

Fields of Study

Major Field: Electrical and Computer Engineering

v Table of Contents

Page

Abstract ...... ii

Dedication ...... iii

Acknowledgments ...... iv

Vita...... v

List of Tables ...... ix

List of Figures ...... x

1. Introduction ...... 1

2. Background ...... 5

2.1 Introduction to Transportation Security ...... 5 2.1.1 Cyber Security Domain ...... 5 2.1.2 Threat Models ...... 7 2.1.3 Layered Security ...... 9 2.1.4 Security Assurance ...... 10 2.2 Automotive Security Review ...... 12 2.2.1 First Formal Projects out of the EU ...... 14 2.2.2 Penetration Testing ...... 15 2.2.3 Automotive Security Standards ...... 17 2.2.4 Security Recommendations ...... 19 2.2.5 Automotive Security Layers ...... 20 2.3 Security Layer Targeted in this Thesis ...... 22

vi 3. Intra-Vehicle Networks and Controller Area Network ...... 23

3.1 Vehicle Electrical and Electronic Architecture ...... 23 3.2 Controller Area Network ...... 26 3.2.1 CAN Security Challenges ...... 28 3.3 Related work in CAN Security ...... 32 3.3.1 CAN secure communication protocols ...... 33 3.3.2 Intrusion Detection Systems ...... 33 3.3.3 Cyber Physical System Security, Model-Based Methods . . . 38 3.4 Thesis Contribution and Gap Analysis ...... 38

4. Observer based CAN Intrusion Detection and Mitigation Mechanism . . 40

4.1 CPS Attack Monitor Preliminaries ...... 40 4.1.1 CPS Attack Monitor ...... 41 4.1.2 Observability under Adversarial Attack ...... 45 4.1.3 Unknown Input Observer ...... 46 4.2 Attack Model ...... 48 4.2.1 CAN Attack Scenario Being Addressed ...... 48 4.2.2 Attacks on Observer-Based Security Mechanisms ...... 49 4.3 UIO based IDS algorithm for CAN ...... 51 4.3.1 NCS Graphical Analysis for CAN Tasks, Messages, and Re- sources ...... 51 4.3.2 Formulation of a Secure CAN Message ...... 54 4.3.3 Connecting CPS System Model to CAN Network Graph . . 56 4.3.4 UIO based Dynamic Monitor for Attacks on CAN Sensor Messages ...... 58 4.3.5 Security Mechanism for Trust of Message under Sensor Attack 60 4.3.6 Security Mechanism for Control Input Under Attack . . . . 62 4.3.7 Limitations ...... 62

5. Autonomous Vehicle Engine Throttle Control Case Study ...... 64

5.1 NCS Graph Analysis for Engine Throttle Control ...... 64 5.2 Engine ...... 66 5.2.1 Continuous Time Engine Model ...... 70 5.2.2 Bilinear Approximation Discretization State Space Model . 72 5.2.3 Zero Order Hold State Space Model ...... 73 5.2.4 ZOH Engine Model Structure Graph and Attack Set . . . . 74 5.3 UIO Construction for AV Engine Control Security Mechanism . . . 76 5.4 IDS and Mitigation Security Mechanism ...... 77

vii 5.4.1 Pressure Sensor Attack Detector and Security Mechanism Design ...... 78 5.4.2 Throttle Actuator Attack Detector and Security Mechanism Design ...... 79

6. Implementation, Simulation and Results ...... 80

6.1 Model in the Loop Testing ...... 80 6.1.1 UIO test in the Crank Angle Domain ...... 80 6.1.2 Time Domain and CAN simulation ...... 85 6.2 HIL Test Bench Design ...... 89 6.2.1 Real-time Machine Setup ...... 90 6.2.2 Results on Preliminary HIL setup ...... 91

7. Conclusion and Future Work ...... 94

Appendices 96

A. Engine Model ...... 96

Bibliography ...... 98

viii List of Tables

Table Page

2.1 ASIL table used to determine what the safety level is for an E/E component [29] ...... 18

3.1 Table showing the list of challenges associated with the security of CAN [40] ...... 32

3.2 The diﬀerent types of In-Vehicle anomaly detectors, referred to by sensor types, with the approach in this thesis potentially classiﬁed as both a plausibility, S-7, and/or consistency, S-8, type. [48, Table I] . . 36

3.3 The type of anomaly sensor needed can be determined by the design scenario. In our case, a speciﬁcation approach is not enough; there are multiple messages for which the payload data is available. How- ever, there could be multiple busses and diﬀerent network types. This approach could be both checking plausibility of the payload data and also checking for consistency on either side of a gateway [48, Table II] 37

4.1 Basic NCS graph notation for tasks, resources, and messages . . . . . 52

4.2 Notation for trusted and CAN message sets in NCS ...... 56

ix List of Figures

Figure Page

2.1 Layers and components of the cyber domain [68] ...... 6

2.2 Model types based on diﬀerent attributes [69] ...... 9

2.3 Pyramid that shows the general attack surfaces for ITS technology . . 10

2.4 Mobility landscape including various V2X communication surfaces that present security risks to vehicles [11] ...... 13

2.5 Depiction showing the large number of common attack vectors on a vehicle [20] ...... 14

2.6 Security mechanisms for a vehicle as a function of the attack progression over time and the type of component being targeted [70] . . . . . 20

3.1 A common E/E architecture that would be found on a vehicle today [32] 24

3.2 Communication connections in future AV controllers [32] ...... 25

3.3 Potential vehicle E/E architecture in future cars showing the high level of attack vectors involved in intra-vehicle communication [32] . . . . . 26

3.4 The relationship between CAN and OSI model showing it is only a layer 1/2 protocol which contributes to inherent struggles with security [58] 27

3.5 CAN Packet Description: (a) is a standard packet, (b) is an extended frame packet [28] ...... 28

3.6 Simpliﬁed view of the CAN packet showing the relationship between ArbID, data payload, and messages ...... 29

x 4.1 Diﬀerent attack types: (a) is a stealth attack, (b) is a replay attack, (c) is a covert attack [55] ...... 50

4.2 An example resource graph ...... 53

4.3 An example process graph ...... 53

4.4 Example mapping of the process graph in Fig. 4.3 to the resource graph in Fig. 4.2 ...... 54

5.1 Network setup for the computational units relevant to this case study 65

5.2 Resource graph for AV throttle request ...... 66

5.3 Process graph for throttle control task ...... 67

5.4 Mapping of process graph to resource graph focused on targeting the messages used for the observer and vulnerable CAN messages . . . . 68

5.5 Engine Model I/O ...... 69

5.6 Structural digraph for the zero order hold engine model showing a link

size of 1 for a vulnerable state x1, pressure, and its associated output reading y1 ...... 75

5.7 Attack detector system-level view where the two highlighted systems secure the pressure reading and throttle control messages ...... 77

6.1 Simulation results with no attack: MAP and engine speed actual output and estimation from the UIO ...... 81

6.2 Simulation resulting engine speed residual when not under attack . . 82

6.3 Simulation results when pressure message is under attack: (a) Attacked pressure signal, (b) Engine speed estimation with attacked pressure signal 82

6.4 Residual of attack simulation in Fig. 6.3 showing that the residual is sensitive to an attack on the MAP, pressure, message ...... 83

xi 6.5 Results of an attack on throttle control signal α: (a) The attacked signal, (b) The resulting residual when the throttle is under attack . . 84

6.6 Resulting engine speed from the attack on α ...... 84

6.7 The estimate of the attacked throttle signal showing the UIO can be used to estimate the attack properly...... 85

6.8 Initial engine speed estimation and residual when the system is not under attack: (a) Engine speed and engine speed estimate, (b) Residual output ...... 86

6.9 Torque load profiles for two scenarios: (a) profile simulating a smooth driving scenario (b) profile simulating large deviations potential resulting from gear changes, ...... 87

6.10 Resulting residual and engine speed without abrupt changes in torque load, using torque load proﬁle Fig. 6.9(a): (a) engine speed and engine speed estimate, (b) engine speed residual ...... 88

6.11 Results from pressure attack on CAN pressure message: (a) adjusted pressure value(b) resulting residual taken from engine speed estimate and measurement showing the mechanism is response to pressure attacks 88

6.12 Current HIL setup showing the relationship between components on the real-time machine and the CAN network ...... 89

6.13 Base HIL run engine speed estimate, open-loop no attack ...... 91

6.14 Pressure attack of an increase of 300 Pa on HIL setup ...... 92

6.15 Attack on throttle HIL setup ...... 93

xii Chapter 1: Introduction

The automotive ﬁeld has been evolving rapidly over time. Vehicles are no longer independent entities but are part of a broader technological ecosystem. Cars are part of an environment referred to as Mobility. Mobility is an umbrella term en- compassing all aspects of transportation; this can include rideshare services, public transportation, etc. There are other terms such as Mobility-as-a-Service (MaaS) that are referring to this shift away from personally owned vehicles to transportation as- sisted by/with technology as a service. Where Mobility is this high-level concept, the term Intelligent Transportation Systems(ITS) is more focused on the technology of the mobility space. The advancements and production of this new technology is a signiﬁ- cant reason for interest in automotive security over the past decade. Modern vehicles are starting to contain more and more technology, such as head units or In-Vehicle

Infotainment (IVI) units that have wireless access points such as Bluetooth, WiFi, 4G

LTE, etc. Along with connectivity, there are new features such as Adaptive Cruise

Control (ACC) and Automated Lane Centering (ACL) that are Autonomous Driver

Assist Systems (ADAS). Eventually, there will be fully Connected and Autonomous

Vehicles (CAV) in production that are going to be part of the mobility space and are going to be an ITS with signiﬁcant, life-threatening, security implications.

1 The reason is a result of vehicles today, and in the future, having this remote access and autonomous features. There have also been tremendous advancements in

Vehicle-to-Everything (V2X) connectivity. Transportation and Mobility, as a whole, is moving towards connectivity. A person can connect to their vehicle, an easy example being remote start technology. New technology allows vehicles to communicate to infrastructure, Vehicle-to-Infrastructure (V2I), and other vehicles, Vehicle-to-Vehicle

(V2V). Then there is mobility service or MaaS, which has its associated security challenges but is going to require a great eﬀort in adding communication capabilities to vehicles. These examples are just hitting the surface of what connectivity oﬀers vehicles, and the space is growing rapidly. The take away is that vehicles are and will continue to be connected. As for autonomous functionalities, they bring new sensor suites to vehicles, including cameras and radars, LIDAR, etc. All of these new autonomous functions and sensors bring a plethora of security risks. They also are going to be used to operate a vehicle, which is how the safety concern presents itself. There is already a great deal of research and debate on how to handle safety concerns of these systems along with how to address security in relation to safety.

This thesis aims to present an approach to vehicular security that addressing some of the signiﬁcant challenges of providing security for safety-critical vehicular operation.

As can be seen, the scope of security challenges that are arising in the automotive space is too large to cover in one solution. That is why the exploration of this thesis is focused on the security of safety-critical systems. Distributed network of control, Network Control System (NCS), used in intra-vehicle operation, is inherently not secure. Speciﬁcally, the powertrain control systems that operate safety-critical functionality operating over a Controller Area Network (CAN). The NCS is how the

2 vehicle communicated internally. It allows diﬀerent computers in the vehicle to pass data to each other. CAN is the common protocol used to pass this data as it was designed to meet vehicles rough operating conditions. However, the protocol does not include built-in security measures due to threats of attack being very limited and required physical access. The result is signiﬁcant challenges in creating a security solution that can operate in a limited bandwidth environment that has necessary safety-critical performance requirements.

This thesis is an exploration into the use of control theory model-based methods for security, resulting in a new security control mechanism. It was found that solutions in applying control theory methods for CAN are not heavily studied or used for securing autonomous functions. Other security mechanisms do exist and have been studied heavily, such as cryptography authentication methods. However, it has been shown that trying to authenticate every message on a CAN network can be challenging to implement due to performance cost. Using encryption and message authentication are preemptive measures. Another mechanism is Intrusion Detection Systems (IDS).

Authentication and encryption are preemptive methods. The model-based approach presented in this work is an IDS that then mitigate the attack by using authentication.

The ﬁnal contribution is a CAN Intrusion Detection System (IDS) and mitigation based on control-theory methods using a new analysis method that connects CAN communication to the dynamical system that is vulnerable to attack. It reduces the number of messages that require authentication at all times and uses authentication to elevate security only when necessary provided that authentication has a signiﬁcant impact on CAN performance, given its low bandwidth characteristics.

3 The organization of the Thesis is presented: Chapter 2 is used to provide a general background on security topics. The goal is to provide terminology and fundamental concepts, then narrow the scope to Automotive security, and give a review of some of the signiﬁcant events and the state of automotive security. Chapter 3 then shifts focus into a review of the Electrical and Electronic (E/E) structure of a vehicle.

This chapter is going to present the E/E architecture used in this work. Chapter 3 also introduces and reviews CAN and CAN security, including challenges, proposed solutions, how to classify solutions, and a review of IDS. Chapter 3 provides the primary motivation of this CAN security mechanism concerning challenges with a fully authenticated CAN network. Chapter 4 is the main contribution. This chapter contains a review of preliminary topics is CPS security. The analysis focuses on attack monitors, attack models, and graph theoretical concepts. Then the IDS system is presented with a mitigation security mechanism that using authentication to elevate the security of CAN when under attack. Chapter 5 is a case study on designing a security mechanism for AV control of velocity using the throttle. The testbed and results are presented in Chapter 6, followed by the conclusion and future work in

Chpater 7

4 Chapter 2: Background

2.1 Introduction to Transportation Security

When addressing security challenges in this space trying to ﬁnd a proper security solution, addressing the entire space at once is not practical, as the problem scales and becomes to complex. Instead, this work is focused on automotive security but still understands that a holistic understanding of security is necessary. It is thus essential to have a high-level understanding of what the cyber domain is along with one of the primary key concepts that allows one to break down such a large problem in smaller manageable problems, layered security.

2.1.1 Cyber Security Domain

In this thesis, the cyber domain contains three main layers, and up to five components, as shown in figure 2.1 per the US ARMY TRADOC pamphlet [68]. This structure provides a holistic, layered approach that considers all actors in the cyber domain. The concept of layered security is that different security mechanisms can be in place to secure different subsystems within the entire system. The idea is that the resulting system is secure as each subsystem is secure. Within this cyber domain, there can be many complexities. In a perfect world, each layer within the domain

5 Figure 2.1: Layers and components of the cyber domain [68]

would interact seamlessly with each other layer. In reality, the interactions can be- come quite complex. However, by using a layered approach, efforts can be primarily focused on one layer at a time: Physical, Logical, or Social. A more tangible example is the different rules and regulations that apply to different geographic bodies. The right-to-repair legislation in the United States differs from that of the EU [67] provides rights to the owner of vehicles in the US that provide a user different legally attainable information that might not be available in the EU. Having that information easily accessible is a potential resource to a malicious actor trying to gain more knowledge of a potential target. The main takeaway is that it is important to make assumptions on a system design based on the attributes of the cyber domain.

6 It is essential to be aware of these diﬀerent layers. A holistic security solution would focus on providing solutions at each of these layers. However, given the cyber domain is a high-level concept does not give any information on actual threats.

2.1.2 Threat Models

A quick clariﬁcation on terminology: Given a system, the system has a list of attack surfaces. Each surface provides diﬀerent attack vectors, which contain vulnerabilities. These vulnerabilities are used to exploit the system. Where a vulnerability refers to knowing how to compromise a system, and an exploit is taking action using a known vulnerability. In this work, an attack on a system is referring to performing an exploit.

An example of an attack surface would be wireless communication. Within the wireless communication attack surface, there are many attack vectors, such as wiﬁ,

Bluetooth, and more. An attack would be on the vulnerability of one of these attack vectors. Related work in [41] seeks to formally deﬁne and weigh these vectors and create an attack surface metric. There is a much larger ﬁeld of study on trying to quantify the security of a system. It is mentioned but not explored further.

A threat model seeks to classify an attack based on its impact on a system. An intention can have other consequences, such as safety, that should be taken into consideration even though it may not be the primary objective of an attack. Thus, this thesis considers the eﬀect of an attack rather than intent.

There are diﬀerent recommendations and approaches to threat modeling. Each of these threat models contain attributes. The attributes are the key areas of focus when analyzing the system. A threat model example being CIA, which includes the

7 attributes: Conﬁdentiality, Integrity, and Availability. In [17], it is referred to as

DDD (Deception, Disruption, and Disclosure) with the added element of a physical damage category given the focus on CPS systems. Based on the CIA model, a more comprehensive model is the STRIDE model, from Microsoft, which encompasses the same attributes as the CIA with the addition of Authentication and Authorization.

STRIDE is a very well studied model for which a more detailed survey is referenced

[62]. However, this work does not believe these models cover the scope needed for

Automotive security design. An example is that an attack on integrity may also have implications on safety, but a model based on CIA types would not address this.

The model presented do not consider safety or other attributes present in physical systems. For example, vehicles interact with humans both virtually and physically.

As a result, a security breach has safety implications for passengers and those in the surrounding environment. A referenced review of security and dependability models that expand beyond focused security concerns provided in [69]. The model attributes, or types, can be found in figure 2.2. In [69], the author provides multiple case studies of evaluations of different dependability and security models on different systems.

The attributes chosen for the threat model are focused on an automotive security mechanism. For systems using a model only focused on safety, SF in Figure 2.2, there are well-known methods such as FMEA [65], and HAZOP [18] that can identify failure sates in a system. Along with these methods, there is also the ISO 26262 standard

[29] for vehicular functional safety. All of these methods have worked for automotive design but are not directly applicable to automotive security design. Section 2.2.1 introduces related work on some of the ﬁrst attempts at formally modeling automotive security for automotive security assurance.

8 Figure 2.2: Model types based on diﬀerent attributes [69]

This work does not aim to analyze or quantify insecure states or modes. The threat models identify and clearly deﬁne the attributes of focus in the design of the automotive CAN security mechanism that is the primary contribution of this paper.

The attributes of focus throughout the remainder of this paper are survivability, performance, and integrity.

2.1.3 Layered Security

In general, to secure a system, three layers: software, hardware, or communication need to be secure. Figure 2.3 represents the high-level security design of these attack surfaces. The tip of the pyramid is a visual way to sate that to secure Intelligent

Transportation Systems (ITS), one has to secure software, hardware, and communication. A secure system is only as secure as its weakest link [61]. Here the concept of

9 Figure 2.3: Pyramid that shows the general attack surfaces for ITS technology

a layered security approach is quite obvious. The limitation is that having even one weak solution can make the entire system insecure. An obvious example is encryption, or the encoding of a message. Complex encryption algorithms can be impossible to decrypt, or decode, within a reasonable time. The assumption is that there is a private key not known by an attacker. If there is not a proper security mechanism in place to keep the key private, then it does not matter how good the encryption is.

2.1.4 Security Assurance

Given section 2.1.1 and 2.1.2 brief background on general security, a valid question is how to assure that these known vulnerabilities are not able to be exploited, i.e., how can a system be validated as secure. Security assurance is the task of providing as much mitigation of risk as possible. IT standards, such as the Common

Criteria(CC), have created EAL ratings and Protection Proﬁles (PP) that address this concern [30]. Protection Proﬁles require security mechanisms to be in place.

10 Unfortunately, the rating criteria are not perfect and are not directly available to be used in the automotive industry, as there are no verified protection profiles for automotive systems. National Information Insurance Project (NIAP), evaluates devices and has a list of protection profiles, none are automotive specific [49]. There is related work conducted on the application of CC to general information systems security [42].

Specialized labs can undertake validation of meeting a PP, Common Criteria Testing

Laboratories (CCTL). Formal standard methods such as CC require speciﬁc security mechanisms. However, not all of these PP veriﬁed systems are secure. Penetration testing is a method of identifying security issues in a system or a security mechanism.

Penetration testing is when a reverse engineer attempts to ﬁnd vulnerabilities in a system. The goal is to identify vulnerabilities and provide a patch.

Some common frameworks used in the IT industry are MITRE and Metasploit, which list known vulnerabilities that can be used by a reverse engineer to pentest a system. These methods go beyond a PP. A PP says that a security mechanism needs to be in place, but that mechanism or the system as a whole could have a vulnerability, bug. Frameworks such as MITRE and Metasploit provide a robust database of attacks on common attack vectors. However, those frameworks do not take into account attack vectors unique to vehicles, i.e., CAN. So even given the great foundation of work in security laid out in the IT industry, mobility still has unique challenges in the unique network components in its cyber domain. These frameworks are just scraping the surface of penetration testing as it is an entirely separate profession. There are many techniques, tools, and experiences needed to conduct a proper pentest. A survey of penetration testing is out of scope, but reports and results of pen testing projects are released continuously, an example being the

11 NIST reporting website [1]. When exploring gaps in security, a review of pen testing eﬀorts is always a good place to start.

Along with these validation methods, there are attempts to formalize security assurance through analysis and metrics. The threat models presented in section 2.1.2 can be used to create probabilistic models to quantify the ability of a system to meet the needs of a chosen model, again refer to [69]. From these methods other metrics can be used to quantify safety, section 2.2.3 provides current standards used for this safety evaluation in the automotive ﬁeld. This thesis does not focus on security assurance, but it is important enough to warrant a review. To this point, the reader has a high-level knowledge of security concepts. This next section guides the rationale and motivation behind the focus on Intra-Vehicle NCS, speciﬁcally targeting CAN.

2.2 Automotive Security Review

Automotive security is a subset of Mobility security. Figure 2.4 [11] is a visu- alization of the components that make up the mobility space now and in the near future. It is not fully exhaustive. Mobility aﬀects every person in some aspect, even those who do not operate or own any form of vehicle. The scope of mobility security extensive and, as a result, complex and challenging. Some components within the mobility space have already had an extensive amount of security research conducted on them. However, mobility does present new components and new challenges. An example of a unique aspect of vehicle security within the mobility space is Vehicle-To-

Everything (V2X). A review of V2X can be found here [9], with a debate currently occurring on what protocol is best. No matter the protocol chosen, V2X can be viewed as a security attack vector unique to vehicles and mobility. Many aspects of

12 Figure 2.4: Mobility landscape including various V2X communication surfaces that present security risks to vehicles [11]

a vehicle communication are not unique, i.e., Bluetooth, but potentially is unique in application. For example, the Controller Area Network is in other Networked Control

Systems outside vehicles. The application of CAN for automotive control is unique to vehicular systems. A more technical review of CAN, focused on CAN security, is conducted in Chapter 3. The physical systems that CAN communication controls make it unique. There are many diﬀerent protocols, and attack vectors in vehicles beyond the examples presented, Fig. 2.5 from [20] provides some other external attack vectors. In general, vehicle attack vectors reside in two categories: external or internal.

External refers to the connectivity of the vehicle, threats from remote attack vectors. Internal, are attack vectors that operate within a vehicle; they require physical

13 Figure 2.5: Depiction showing the large number of common attack vectors on a vehicle [20]

access or a compromised external attack vector. There have been multiple eﬀorts in automotive security to address vehicular security, both externally and internally.

These eﬀorts include government-funded projects, Penetration testing to understand vehicular vulnerabilities, formal standard guidelines, and recommendations from the professional security community. These are presented as a literature review of early work in the European Union, released penetration testing reports, current automotive security standards, and recommendations from government agencies and industry.

2.2.1 First Formal Projects out of the EU

An example of one of the ﬁrst formal automotive research initiatives was the Evita project, as part of the European union 7th Framework program, FP7. The primary

14 object of the EVITA project was to “design, verify, and prototype and architecture for automotive on-board networks” [51]. The project addressed and provided solutions for automotive security. They particularly list: Security Requirements, Secure on-board architecture design, Implementation, Prototype-based demonstration, and

Dissemination and external Interfaces, as the high-level topics of the project. Pub- lications from this project addressed every level of automotive security. Of these works, there are a few major topics: Modelling of security used for veriﬁcation of safety and security properties [56]. Hardware Security Modules (HSM) to accelerate the computation [72], Secure communication, both internal and external. [63, 3].

Sevecom is an example of another FP7 funded project aimed at secure automotive communication. These initial exploratory projects give a foundation for understanding the challenges in automotive security. FP7 ended in 2013. Many companies arose from these projects, including Escrypt. More recent projects have emerged under the new EU project Horizon 2020, an example being the safertec-project, showing a continued interest in automotive security. These project eﬀorts are focused on solutions, whereas penetration testing eﬀorts have resulted in the release of reports demonstrating automotive security exploits.

2.2.2 Penetration Testing

Eﬀorts in the penetration testing, RED team, or hacking, give a tangible understanding of the implications of compromised vehicle security. The most notable and public example was the infamous 2015 Jeep Grand Cherokee hack [24]. A Jeep was taken over remotely via a cell network. The attack was not malicious but a call to

15 arms for automotive security. Unlike publication or research where the safety implications of attacks are clear technically, it is not always tangible. This attack didn’t need to be technically clear to deliver a message on the importance of security. A security vulnerability can compromise the safety of the driver, the passengers, and those in the surrounding environment. Charlie Miller and Chris Valasek, the two behind the attack, have contributed other works [43, 44] in which they educate the public on car vulnerabilities as well as the more technical side of automotive penetration testing tools and techniques. One of the most prominent penetration testing books is the

Car Hacker’s Handbook [64] released in 2016. This book provides a lot of the skills and tools necessary to start exploring vulnerabilities. The list of vulnerabilities will continue to grow. At the physical layer of the CAN bus, speciﬁc pen-testing tools are also being developed, such as the bitbane CAN’T out of Grimm [25].

Reports such as [14] also give insight into vehicle vulnerabilities. Other reports have emerged on an analysis of vehicular security [34, 14] as well as attacks such as the

Keen Labs attack on an Autopilot system [50]. There have been other Telsa attacks

[59]. Observation is that many of these attacks and reports came after the conclusion of the FP7 EU projects mentioned above. These concerns are not limited to the automotive passenger space. The heavy-duty industry also has been dealing with security concerns [13]. Heavy-duty has arguably a more challenging security problem with the requirement of ﬂeet data tracking and a standardized network stack for CAN,

SAE J1939 [60].

Exploits of CAN are not new, with this workshop paper exemplifying this [73], which was released back in 2004. The concerns for CAN bus have mostly been non-essential, given the physical nature of the attacks. After the conclusion of this

16 section, it should be evident that external attack vectors are vulnerable, and CAN is no longer just a physical access security concern. External attack vectors are not being analyzed any further in this paper. Later a more thorough review of CAN provides an understanding of these exploits, along with related works that propose diﬀerent methods to secure the bus.

All of these reports and surveys on security highlight that there is a gap in automotive security. Vehicle security can compromise safety, and the controllers communicate over an insecure network, CAN. There are security standards published to formally address how to conduct security design in light of these vulnerabilities.

2.2.3 Automotive Security Standards

To date, many standards for automotive safety exist. ISO 26262 [29] is the current standard used in the functional safety of automotive systems. This standard has many challenges regarding autonomy [33] and does not cover security. New standards such as SOTIF, ISO/PAS 21448 [31], are attempts to address autonomy concerns, particularly focused on safety, but again do not address security concerns regarding safety. ISO 26262 even deﬁnes safety level requirements based on an analysis of the system, Automotive Safety Integrity Level (ASIL). ASIL ratings range from A to D with a separate speciﬁcation Quality Management (QM), which denotes to requirement per ISO 26262. To determine the ASIL requirement table 2.1 is used.

Where the S rating is the severity class, E is the probability of exposure, and C is the controllability class. This method gives the safety requirements of Automotive

E/E systems. As stated, this standard does not hold for safety in more autonomous vehicles. As a result, SOTIF was created. Rather than use table 2.1, the criteria for

17 Table 2.1: ASIL table used to determine what the safety level is for an E/E component [29]

safety is the intended functionality. The reason is that a system could be operational safe according to ISO 26262 standards, but its operational output could be unintended and potentially catastrophic. Koopman and Wagner review the safety challenges in autonomous vehicles[33]. Where new safety challenges are arriving in CAVs, the solution now has to consider security, as a malicious attacker can cause unintended behavior that could potentially result in an unsafe action.

In automotive security, there is no current equivalent to these standards. New standards, such as SAE J3061 [60], have been released to ﬁll in the security gap.

J3061 is viewed as a security recommendation and does not provide the level of detail needed in the industry. To date, there are no speciﬁc methods to provide security assurance of a vehicle. Still, ISO/SAE 21434, currently listed as a preview, is to be released in 2020 and be the successor to SAE J3061. This release would aim to require a Threat Assessment and Risk Analysis (TARA), which is the security equivalent to

18 HARA in functional safety [29]. It will not provide countermeasures or techniques for security. Since ISO/SAE 21434 is not oﬃcially released at the time of this writing this thesis, it is not clear the impact it will have on automotive security.

The takeaway is that automotive security design right now is left to the designer.

What security mechanisms need to be in place is an open question. However, some recommendations are coming out of the professional security community.

2.2.4 Security Recommendations

As mentioned in the background, there is currently no set standard on what system is to be implemented in vehicles to provide security. Or a general security architecture. However, many released reviews and recommendations can give a picture of what vehicle security needs to include. Semiconductor companies have released such recommendations, such as the NXP white paper release on a multi-layered security architecture [70]. There also have been government releases, such as this report from the GAO [22]. Fig. 2.4 comes from a McAfee white paper on automotive security and provides a well-written review of automotive security from a high-level and also provides its recommendation for best practices in automotive security[11].

Government Agencies such as the National Motor Freight Traﬃc Association

(NMFTA) have also released heavy-duty vehicle speciﬁc surveys on challenges and recommendations for combating these challenges [4]. Another Heavy-Duty vehicle cybersecurity review and recommendation from Michigan and published under NHTSA

[65]. As mentioned previously, the FP7 projects have concluded. Europe still is invested in automotive security. An example is the European Union Agency for Cy- bersecurity ENISA. ENISA is involved with all aspects of security but has speciﬁc

19 Figure 2.6: Security mechanisms for a vehicle as a function of the attack progression over time and the type of component being targeted [70]

ﬁndings and publications targeted at the industry; an example is there report on smart car security [21]. The new Horizon project has also started up. Another agency, the

National Highway Transportation Safety Administration (NHTSA), has released its recommendations to the public [2].

None of these recommendations are standards but can be a great place to start when trying to understand vehicular security. An example is the NXP recommendation on layered automotive security. The next section is going to investigate further layered from an automotive perspective and highlight the layer of focus in this work.

2.2.5 Automotive Security Layers

Fig. 2.6[70] is one way of looking at breaking down vehicle security. It states that vehicle security mechanisms can be designed based on four categories: Secure

20 Interfaces, Secure Intra-Vehicle Network, Secure Gateway, and Secure Processing. For which each can have security targeting the three general security layers previously mentioned: hardware, software, and communication layers.

Security interfaces refer to any external communication, components such as V2X, wifi, would all fall into this category. Secure processing refers to the computation units themselves, microcontroller, ECUs, sensors, etc. The gateway separates external interfaces with internal communication and facilitate communication between different internal communication networks. The Internal communication layer is how different components within the vehicle communicate. In particular, the Controller Area

Network (CAN) is the network used for communication to control units. The next chapter is a review of a vehicle’s E/E architecture and further explain these components. The CAN network, CAN security, and current challenges in securing the CAN network, are presented as well.

For each layer, there is a time axis. The time axis represents the evolution of an attack. Prevention is preemptive measures that can take place to stop attacks from occurring. Detection is used to detect attacks when they happen. Reduce, is simply to mitigate the amount of damage an attack does after its started, note it does not have to be detected. In particular, at the secure communication layer, they list IDS as a method of detection but do not have a place holder to reduce impact. Secure interfaces also have a gap, according to this work, in automotive-speciﬁc solutions for detection and reduction. This NXP review is just one of the many related works cited and providing recommendations. It was chosen as it represents a trend and a gap in automotive security detection mechanism without a means to counter the detection on safety-critical networks within a vehicle.

21 2.3 Security Layer Targeted in this Thesis

This thesis is targeting the secure Intra-Vehicle Network communication layer, which is a part of the communication layer of the pyramid in Figure 2.3. The mechanism provided does not consider security in either the hardware or software layer.

It follows many recommendations and standards and views security as an integral part of system design rather than add on the wrapper. This thesis is targeting the serviceability, integrity, and performance of safety-critical automotive systems. One way to compromise these attributes is by attacks that manifest in the vehicle NCS.

To further clarify the problem statement and gap, a review of the intra-vehicle E/E architecture is required. After this review, the motivation and contribution of this thesis is clear.

22 Chapter 3: Intra-Vehicle Networks and Controller Area Network

The intra-vehicle communication layer of a vehicle is essential for vehicle operation and provides a high risk to safety when compromised. The Controller Area Network

(CAN) is shown in this chapter to have the greatest threat to safety and faces many challenges in providing a proper security solution. A review of Electrical and Elec- tronic vehicle architecture, followed by an analysis of CAN bus and CAN security, is presented to motivate a security solution for CAN. CAN bus security mechanisms are introduced, explicitly targeting Intrusion Detection Systems (IDS). This review provides the necessary information to understand the motivation behind the design of an observer-based IDS and Mitigation security mechanism for CAN.

3.1 Vehicle Electrical and Electronic Architecture

The structure of the Electrical and Electronic (E/E) architecture has evolved with the addition of new technologies. A review of the trends in E/E architecture is given by [32]. This review also presents the impact of connectivity and autonomy on the E/E architecture. The E/E architecture provides the overall attack surface on intra-vehicles communication networks. Within the communication, there are several attack vectors, diﬀerent communication networks, controllers, sensors, and

23 graphics/ch3/Current Vehicle Archetecture.PNG

Figure 3.1: A common E/E architecture that would be found on a vehicle today [32]

more. Figure 3.1 from [32] is a potential architecture that could be found on a car today. An important note is that these architectures are not standard and vary by

OEM. The vehicle architecture contains multiple domains. The gateway passes data from one domain to another. A ﬁrewall can be implemented in the gateway to limit communication between domains. As demonstrated in the penetration attacks listed in section 2.2.2, the Infotainment unit is a primary attack vector for remote attacks.

Implementing a ﬁrewall in the gateway is a good step towards securing that attack vector. However, as demonstrated at a Black Hat conference [50], it does not ensure an attacker can not access other domains.

In future vehicles, autonomous control is going to require a large, dedicated computational unit, which is named AV control unit (AVCU) in this thesis. A potential communication E/E architecture for an AVCU is presented in ﬁgure 3.2 [32]. The

AVCU has multiple networks that it uses for data acquisition, in addition to communication to lower-level controllers over CAN. The AV unit has access to a plethora of data, including Radar, Lidar, Cameras, Ultrasonic, GPS/IMU, and more. In this architecture, the platform is connected to the central gateway via Ethernet. In the case that the AVCU needs direct access to lower-level control, a message can be sent through the gateway to the appropriate domain.

24 Figure 3.2: Communication connections in future AV controllers [32]

a domain such as ﬁgure 3.3 is assumed to implement the AVCU into the overall vehicle E/E structure. In this domain approach, the central gateway can consist of either CAN/Ethernet connections. Each sub-domain has a Master controller that re- lays data from is sub-domain to the central gateway. The Human Machine Interface

(HMI) domain would have access to a large number of physical attack vectors like

USB, WiFi, IVI, and more. The Diagnostic ports provide physical access through

OBD2, which has limited access to CAN networks depending on the gateway implementation. The most obvious remote attack vector is the Connectivity and Control

Unit (CCU). If the attacker can gain access to the powertrain domain through any one of these attack vectors, then the safety of the system can be compromised. The security of connected devices and sensing suite is out of scope for this work. There are related works in this ﬁeld [23, 43, 52].

25 Figure 3.3: Potential vehicle E/E architecture in future cars showing the high level of attack vectors involved in intra-vehicle communication [32]

The review of the E/E architecture has shown that the control requests from an

AVCU can be compromised on the powertrain domain CAN network. There are two main objectives targeted in this thesis: Detecting when an attacker has gained access to a safety-critical CAN network and provide a security mechanism in the case of such an event. A review of CAN is necessary.

3.2 Controller Area Network

The CAN network has been around since the 1980s. It is a popular choice as the go-to automotive controller network due to the known traits: high-Speed serial interface, low-cost, short data packets, fast reaction times, multi-master, and peer- to-peer, error detection and correction. This source provides an in-depth technical review of the protocol [28]. The technical details of the physical layer are not reviewed.

26 There is similar work on attacks and the development of a pen-testing tool at the electrical level of the protocol [25].

For this thesis, a taxonomy of the network packet structure is necessary. The CAN network utilized layer 1/2 of the OSI model. Fig. 3.4 [58] shows this relationship. It

Figure 3.4: The relationship between CAN and OSI model showing it is only a layer 1/2 protocol which contributes to inherent struggles with security [58]

also shows that there are two main components needed to use CAN: a CAN controller and transceiver. Within the data link layer has a deﬁned packet structure. There are two types of packets that can be used, standard and extended show in Fig. 3.5 [28].

There are many details of this packet that are not required for this thesis. Also, this thesis does not focus on modelling the network but there is related work in doing so

[26].

There are two components of a CAN packet that are of concern: Arbitration ID

(Identiﬁer in Fig. 3.6), and data. The data payload of the packet is where the data

27 (a)

(b)

Figure 3.5: CAN Packet Description: (a) is a standard packet, (b) is an extended frame packet [28]

is stored as messages and is dynamic between 0 and 8 bytes. The CAN packet from

Fig. 3.5 can be reduced to Fig. 3.6. The use of the Arbitration ID (ArbID) in the

CAN protocol is for the arbitration process, which handles collision [28]. In design, it categorizes messages. An ArbID has associated messages in the data payload section of its packet. The designer knows where the packet should be coming from based on the design, not on information from the packet. In practice, a ﬁle with extension .dbc is used to store information on the connection between ArbIds and their associated

CAN messages. CAN packets that contain safety-critical messages in the data payload portion of the packet are susceptible to spooﬁng, replication, manipulation, and more attacks, securing the network comes with some diﬃcult challenges.

3.2.1 CAN Security Challenges

Though CAN has many advantages for use in automotive systems, it also has inherent security challenges. The three largest being [74]:

• Lack of message authentication

28 Figure 3.6: Simpliﬁed view of the CAN packet showing the relationship between ArbID, data payload, and messages

• Unsegmented network

• Unencrypted messages

Section 3.1 on E/E architectures shows a trend in providing segmentation in automotive control network design. However, it is diﬃcult to implement authentication and encryption for all CAN communication. Authentication at this level is concerned with message authentication. A Message Authentication Code (MAC) is an example of how to provide authentication. There is no one set algorithm used to construct a

MAC, though a common example cipher is AES. The National Institute for Standards and Technology (NIST) has published work on other recommended cryptographic algorithms [6]. However, a cryptographic algorithm is not always used. Sometimes simpler, more insecure, methods are used. There are many MAC algorithms, look

29 under patent CPC class H04L9/3242. There are other methods to provide authentication, but the goal is to ensure that a packet is coming from an authoritative source. In contrast, Message encryption provides conﬁdentiality and privacy to data in a message packet.

Encryption can render a message meaningless without knowledge of the key or algorithm used to encrypt the data. Again, it is common to use a NIST certiﬁed cryptographic algorithm but not required. Both encryption and authentication require a secure communication protocol to be implemented appropriately. This protocol manages keys, along with ensuring that the communication is secure. Packets may need to add additional information in the data section in combination with nounces, or numbers only sent one, depending on the protocol. The goal is to manage all parties involved in the communication while also addressing potential vulnerabilities such as replay, eavesdropping, man-in-the-middle, etc. The take away is that secure communication protocols have a cost in overhead and bandwidth. Encryption and authentication are preemptive security mechanisms that come at some cost, i.e., time to run cryptographic algorithms, packet overhead, key management complications, etc.

The short packets and limited bandwidth make these solutions very diﬃcult to implement [36]. Given that CAN has such limited bandwidth, it is common for all packets to have fully used message payloads, especially if a message authentication code (MAC) is required. Giving up some bits of the data section may not be an option in a max size 8-byte packet. A newer revision of CAN, CAN-FD, extended the max packet size and allowed for a faster bus rate which makes these security mechanisms more practical. As the bus rate can achieve 8Mbits/s over the max

30 1Mbit/s on regular CAN, and the data packet size can reach 64 bytes rather than 8 bytes. In CAN-FD, the arbitration process is still limited to 1Mbits/s. The security mechanism here works for either protocol and the general structure in Fig. 3.5 since both protocols still use an ArbID and Data payload. More details of CAN-FD can be found here [63].

This thesis assumes that some level of authentication is available to the user regardless of use. An example is the Automotive Open System Architecture (AU-

TOSAR) Secure Onboard Communication (SECOC) [5], which follows NIST [19] recommendation. If following the simplest implementation of the SECOC deﬁned

Interaction Layer Protocol Data Unit (I-PDU), security proﬁle 2 or 3 can be used to provide an authentication code and freshness value, which consumes 32 bits of the data payload portion of a CAN packet when used. Refer to the standard for speciﬁcs.

As mentioned using authentication has drawbacks in performance, a quantization of this impact is researched in related works [76, 75, 77] that demonstrate the performance cost that secure communication has on a system. The overhead and delay of using a secure communication standard that provides authentication can lead to undesired performance lost. The security mechanism design in Chapter 4 is aimed at addressing this challenge.

In addition to the struggle with CAN encryption methods, other important considerations that need to be made regarding technical challenges within CAN security given in table 3.1 [40]. Security solutions need to take into account all of these challenges. This thesis is primarily focused on the performance impact of CAN authentication and providing a mechanism that can use knowledge of system dynamics to reduce required authentication messages on the CAN bus. There is also an

31 Table 3.1: Table showing the list of challenges associated with the security of CAN [40]

exploration conducted into what messages require authentication. Authentication, encryption, and network segmentation are preemptive measures to secure can. There are other related works in detecting and mitigation of attacks.

3.3 Related work in CAN Security

Given the known limitations of CAN in regards to security, there is a large amount of related work to provide a viable solution. There have been attempts at solving the challenges with methods such as encryption and authentication. An introduction to Intrusion Detection Systems (IDS) is given along with related works in CAN IDS mechanisms.

32 3.3.1 CAN secure communication protocols

Section 3.2.1 presented the diﬃculty of an implementable encryption, and authentication solution for CAN. It also mentioned the need for a secure communication protocol to use these security mechanisms properly. There have been several attempts at creating CAN speciﬁc protocols to provide authentication and encryption mechanisms.

In literature, a few related works are provided in the following works [7, 47, 35, 12,

57]. Those are just a sample of which there are many more. One example, LASAN, attempts to provide its solution concerning the challenges with secure communication in CAN [47], by addressing key management and the life-cycle of the protocol. There are many contributions, but vehicles still do not heavily use these protocols. It seems natural to assume that implementation challenges are critical to consider in future approaches.

To move away from literature, a Ford CAN MAC algorithm that filed under patent number US20180131522A1 is an automotive-specific example of a non-literature approach and a move towards finding an implementable solution. However, the challenges mentioned earlier imply that secure communication protocols and authentication alone may not be viable as a complete solution. It appears that there is progress, but authentication and encryption of CAN may not ever be plausible. Another approach to address these challenges is using an Intrusion Detection System.

3.3.2 Intrusion Detection Systems

Rather than prevent an attack from happening, an Intrusion Detection System detects an attacker. An Intrusion Detection and Prevention System is an IDS that

33 can also prevent the attack from taking eﬀect. An Intrusion Detection and Mitiga-

tion System is an IDS that can also mitigate attacks, which is the security control

mechanism designed in this work. An IDS can present as Host-based (HIDS) or

Network-based (NIDS) [74]. A host-based IDS detects attacks based only on data

coming in and out of the host; it is unaware of the entire network. NIDS is aware

of all network traﬃc but not aware of the internal working of a host, in contrast to

HIDS. The Controller Area Network has a bus topology. A single host can monitor all

network traﬃc on a bus. An IDS can be located on a host but still retain knowledge

of the CAN network on which it resides. An IDS in [10] uses this property of CAN

to detect and drop malicious packets. However, this method only uses lookup tables

to determine if a packet has entered the bus with an ArbID that only the observing

unit is allowed to use. It can not counter messages that have been spoofed by a

compromised unit that is authorized to send a speciﬁc ArbId. It also does not work

for attacks on an ArbID where multiple units are allowed to use that ArbID. The

most signiﬁcant disadvantage is that it gives power to units to drop messages.

There are many more IDS examples in literature for CAN. A 2019 release in the

EURASIP journal for communications and Networking provided a survey on known

IDS methods in literature [40]. There are three types of IDS in this review:

• Signature-based

• Anomaly-based

• Speciﬁcation-based

Where the signature-based method utilizes information on a set of known attacks to detect if a current attack is occurring. The disadvantage of these methods is

34 the requirement to have a database of known attacks. The struggle is referenced in

another review of IDS [27]. Also, that database would need to be exhaustive and

updated just as is done with malware software, and the feasibility of this in practice

may be diﬃcult to achieve.

Speciﬁcation approaches are based on given requirements implemented in the net-

work. Any deviation from the requirements would detect an attack. The disadvantage

is that this is a static implementation that may change over time just as with the

signature-based approach, any change in speciﬁcation of an ECU behavior would

render the IDS useless.

The last category of anomaly-based approaches provide a means of understanding

if a system is under attack if acting abnormally. The anomaly-based approach is

similar to the speciﬁcation approach but does not require a set of known requirements

that is static and provided to the system. There are many subcategories listed by

[40]:

• Machine-learning

• Frequency-based

• Statistical

• Hybrid (learning)

All of these methods seek to ﬁnd behavior outside of normal operation. Learning methods impede on the computational limitation of ECU nodes. Future with more powerful controllers may alleviate this concern. However, an even bigger challenge is the training of learning algorithms, given that the behavior of the network may

35 Table 3.2: The diﬀerent types of In-Vehicle anomaly detectors, referred to by sensor types, with the approach in this thesis potentially classiﬁed as both a plausibility, S-7, and/or consistency, S-8, type. [48, Table I]

be dynamic. Table 3.1 references this as a major challenge in CAN security design.

On top of this, as with any machine learning-based approach, the ability to provide solid veriﬁcation or assurance is quite diﬃcult. The challenge of verifying learning methods in regards to safety has been mention previously in section 2.2.3. Given the focus of this work if on the security of critical safety systems, these concerns apply here as well.

In general, for anomaly detection system for In-Vehicle Networks can be classiﬁed based on a structural approach presented in [48]. In particular, they lay out what is referred to as sensor types S-1 - S-8, as shown in Table 3.2. The usefulness of each of these sensors can be determined based on its application criteria given in Table 3.3.

The method presented in this work is a bit unique, provided that there is a central gateway point of attack linking multiple networks. That is why the mechanism is a plausibility check, but given the architecture has one central gateway linking multiple networks, it is providing a consistency check as well.

Given the review of vehicular anomaly detection types and available mechanisms, model-based anomaly methods do not appear in these surveys and reviews. Where

36 Table 3.3: The type of anomaly sensor needed can be determined by the design scenario. In our case, a speciﬁcation approach is not enough; there are multiple messages for which the payload data is available. However, there could be multiple busses and diﬀerent network types. This approach could be both checking plausibility of the payload data and also checking for consistency on either side of a gateway [48, Table II]

the application of observer-based methods for a CAN IDS is not apparent after un- dergoing a literature review, one IDS system that built upon CAN is [8]. One primary assumption is also that all controllers are on the same bus and see the same control messages. Also, the observer design does not address sparse observably, i.e., the system can be unobservable if a sensor reading is under attack, which leads to questions about the ability to detect replay attacks. These limitations may not be apparent at this point but are clariﬁed in a later section on observability under adversarial attack in Chapter 4.

Observer methods have seen a great deal of research in the Cyber-Physical Systems

(CPS) security domain and creating security resilience control. This thesis targets

37 this particular gap in the use of model-based methods for use in CAN bus security and the creation of Intrusion Detection Systems using an observer-based approach.

3.3.3 Cyber Physical System Security, Model-Based Meth- ods

The bulk of foundational work on cyber-physical system attack detection and identiﬁcation can be referenced in Pasqualetti et all. [55]. A few works that create observer-based monitors using this foundation can be examined further in [45, 46].

These works, however, are not called intrusion detection systems; they are referred to as attack monitors. The monitor has to meet certain criteria to detect attacks.

Chapter 4, section 4.1, provides the core foundation of CPS control-theoretic methods.

These methods are general for cyber-physical systems, and not for CAN automotive systems. The foundational theory is focused on attack monitors that can be used as a detection mechanism, and does not provide any actionable countermeasure. Therefore additional work is conducted in connecting the CPS approach to the CAN network, as well as providing a security control mechanism so the detection system can provide some actionable defense.

3.4 Thesis Contribution and Gap Analysis

Chapter 2 clarified the security layer of focus is the intra-vehicle communication layer. This chapter has provided all the necessary background needed to understand the problem statement. CAN is an attack vector that directly affect safety-critical automotive systems. Instead, then use a general solution, CAN is a specific application in which the proposed security mechanism can target its unique challenges.

Those challenges being it only consists of 2 layers, with no inherent security and

38 limited bandwidth, and the E/E architecture that it resides on has limited computational units. Leading to preemptive security solutions such as authentication and encryption being challenging to implement due to the performance cost.

There are diﬀerent IDS methods, but for anomaly detection using payload data

(S-7), the main contributions in CAN solutions are using learning methods. Given this analysis is on the security of safety-critical systems, learning methods may not be an appropriate solution given the current state of challenges in AV safety. Learning methods are promising and show great value but isn’t respect to a holistic security approach. They present a major challenge in security assurance. The security mechanism presented combines the CAN network with control-theoretic methods to use authentication to elevate security when sensors or actuators are under attack. To provide a method that reduces the amount of authentication used.

39 Chapter 4: Observer based CAN Intrusion Detection and Mitigation Mechanism

The intrusion detection and mitigation algorithm design presented in this chapter provides a method to secure safety-critical control tasks. These tasks are operating on a resource that requires communication using CAN messages. A Task, message, and resource are all presented and formally deﬁned in this chapter. The chapter structure:

First introduced is the required preliminary theory. Second, is a method for graphical analysis of NCS and CAN. Finally, the main contribution is an observer-based intrusion detection algorithm designed in conjunction with a security mechanism algorithm. Security level is deﬁned in relation to message trust. The attributes of concern in this approach are: survivability, performance, and integrity of the system.

4.1 CPS Attack Monitor Preliminaries

The base theory for control-theoretic approaches to security can be referenced in

[53, 54, 55]. These methods are for general linear time-invariant state-space systems.

A few assumptions before presetting the required theory on CPS security.

Assumption 1 The security mechanism in this method considers the system it is monitoring to be free of faults.

40 Some related works that consider the distinction of attack from faults, it is in itself

another topic of focus. The last major assumption 2

Assumption 2 The data used is to be free of noise. Noise ﬁltering has already been

conducted, given the data used in this method is coming from the CAN network.

It is common for available data on CAN to have already gone through a noise ﬁlter.

Fault diagnostic methods are in place at a lower control level, that would be hardwired

and not susceptible to these attacks. There are two main pieces of foundational work:

1. A deﬁnition of a general dynamic monitor pair (Φ, γk) for detection and identi-

ﬁability of attacks.

2. A formal deﬁnition of observability under adversarial attack.

4.1.1 CPS Attack Monitor

An attack monitor is used to determine if the states or outputs of a system are under attack. A note on notation: subscript k is the sample. Consider the following discrete-time system:

a Exk+1 = Φxk + Γuk (4.1) a yk = Hxk + Duk

n p n×n n×n n×m p×n p×m Where xk ∈ R , yk ∈ R , E ∈ R ,Φ ∈ R ,Γ ∈ R , H ∈ R , D ∈ R . x a m uk Here, uk ∈ R = y is the attack input on states and outputs respectively. uk The attack monitor presented by Pasqualetti et all. [55] assumes the input is unknown and that attacks occur on states and outputs, that attack set is given as

K ⊆ {1, ..., n + p} [55]. Provided the attack set the attack signature are the matrices

ΓK,DK. In this thesis it is assumed that it is an explicit system such that E = I

41 to satisfy [54, A1,A2]. Also, inputs are considered smooth to satisfy [54, A3]. The

general deﬁnition of a monitor is given as:

Deﬁnition 4.1.1 (Attack Monitor [53]) A monitor is a pair (Φ, γk), where Φ:

Λ 7→ Ψ is an algorithm, and γ : R 7→ Rn+p is a signal. In particular, Λ is the

algorithm input to be 0 for this monitor, Ψ = {ψ1, ψ2}, with ψ1 ⊆ {true, false}, ψ2 ⊆

{1, ..., n + p} is the algorithm output.

There are three types of monitors: static, dynamic, and active. A static monitor

which has no information on the system only knowledge of sensor readings. A dynamic

monitor, which contains information about the system states and is the monitor type

used in this thesis. The ﬁnal monitor is an active monitor, which is a dynamic monitor

with the ability to send unique inputs. These referenced works provide examples of

active monitors and their use against attacks that can avoid detection by dynamics

monitors [45, 46]. The most signiﬁcant disadvantage to these monitors is that the

active control signal can degrade performance [45].

The dynamic monitor utilizes information from a system model without the per-

formance cost of an active monitor. The dynamic monitor deﬁnition is from [53,

Deﬁnition 2], presented as a function in discrete time, it evolves over samples where

t = kτd such that τd is the sample rate:

Deﬁnition 4.1.2 (Dynamic Monitor [53]) A dynamic monitor is a monitor with

γk = 0 ∀k ∈ N≥0, and Λ = {E, Φ, H, yk∀k ∈ N}.

The monitor is a general deﬁnition of an algorithm but not every system is detectable.

K An attack on (4.1) is considered undetectable if y(x0, uk , k) = y(x0, 0, k), where K ⊆ {1, ..., n + p} is the set of vulnerable states and outputs.

42 It should be apparent that there is a correlation between invariant zeros of (4.1) and detectability and identiﬁability. Two remarks on detection and identiﬁcation.

Following [55, Theorem 1 ] undetectable attacks exist if there a invariant zero exists.

This remark provides the condition for an undetectable attack to exist.

Remark 4.1.1 (Undetectable Attack Condition [53]) There exists an attack set

K, with |K| = w, undetectable by a dynamic monitor if and only if w ≥ ||(sE−Φ)x||0+

||Hx||0.

If there is an invariant zero, then there exists an undetectable attack, this does not mean all attacks are undetectable. For the monitor to provide identiﬁability the following remark must be met per [55, Theorem 2], the interpretation of this theorem is as a remark:

Remark 4.1.2 (Unidentiﬁable Attack Condition [53]) There exists an attack set K, with |K| = w ∈ N, unidentiﬁable by a dynamic monitor if and only if there exist an attack set A, with |A| ≤ 2w, which is undetectable by a dynamic monitor.

If there are no invariant zeros, then the system is completely identifiable. Both detectable and identifiability conditions can be difficult to interpret obvious meaning.

The following reference provides the proofs for these theorems [53]. Directly applying these remarks to a system is not trivial. A structural graph approach determines the presence of undetectable attacks.

There are two types of graphs used, directed and undirected graph. The following are the deﬁnition of a directed, digraph, used in this thesis:

Definition 4.1.3 (undirected graph) G = (N ,A) is defined to be a finite non- empty set N of nodes and a collection of A unordered pairs of nodes from N . Each

43 unordered pair in A is called an arc. G(A) is the set of all unordered arcs, and G(N ) is the set of all nodes in G.

Deﬁnition 4.1.4 (digraph, or directed graph) G = (N,A) is deﬁned to be a

ﬁnite non-empty set N of nodes and a collection A of ordered pairs of nodes from

N. Each ordered pair in A is called a directed arc and contains a head and a tail respectively. G(A) is the set of all ordered arcs, and G(N) is the set of all nodes in

The notation is unique between an undirected graph and a digraph to clearly identify what type of graph is being used. The deﬁnition of a path and a link are provided as it is required in a later analysis.

Deﬁnition 4.1.5 (path [55]) A path is deﬁned as: P = ({n1, ..., nk+1}, {e1, ...ek}) such that ni 6= nj for all i 6= j and ei = {ni, ni+1}.

Deﬁnition 4.1.6 (link size [55]) A set of mutually disjoint paths between two sets of vertices, S1 and S2, is called a linking of size l from S1 to S2.

The following deﬁnitions follow [53, Section V-A] A structure matrix is given as

[M] in which each entry is a 0 or indeterminate parameter. The structured system is given as:

[E]xk+1 = [Φ]xk + [Γ]uk (4.2) yk = [H]xk + [D]uk

For a given structured system a digraph G(V,ES) can be created from the tuple

([E], [Φ], [Γ], [H], [D]). Where V = U ∪ X ∪ Y; U = {u1, ...um},X = {x1, ...xn},Y =

[Φ] [Γ] [E] [H] [D] [Φ] {y1, ...yp}. The edge set ES is given as ES ∪ ES ∪ ES ∪ ES ∪ ES where: ES =

44 [Γ] [E] [H] {(xi, xj) : [Φ]ij 6= 0},ES = {(xi, xj) : [Γ]ij 6= 0},ES = {(xi, xj):[E]ij 6= 0},ES =

[D] {(xi, xj):[H]ij 6= 0},ES = {(xi, xj):[D]ij 6= 0}. The following remark extends from [53, Theorem 5.3]:

Remark 4.1.3 (Structurally Undetectable Attack [53]) There exists a structural undetectable attack if and only if there is no linking of size |U| from U to Y.

This remark can be used to determine if a system can detect and identify attacks in attack set K. The maximum number of attacked states at once is equal to max linking size of |U| from U to Y. An example: if the linking size is 2 then attacks on 1 or 2 states/outputs at a time in K can be identiﬁed but an attack on 3 states/outputs is not. This is following the case that initial condiitons are unkown. This method can be used to determine if a dynamic monitor is able to detect or identify attacks but does not make any comments on oberservalitiy of a system during an attack.

4.1.2 Observability under Adversarial Attack

The main theorem used for the observablility under adversarial attack is presented in [16]. Given the following system:

xk+1 = Φxk + Γuk (4.3) i i i i yk = Hkxk + Dkuk + ak : i ∈ {1, ..., N} Here i is the index of the measured outputs, looking at each output separately. Where

n pi m r xk ∈ R , yi ∈ R , uk ∈ R , ai ∈ R . N is deﬁned as the number out measurable outputs, |yk| = N. M is deﬁned as the number of attacked outputs, M ≤ N. System

(4.3) is observable if the following theorem holds per [16, Theorem 1]:

Theorem 4.1.1 (Observablilty under Adversarial Attack [16]) System (4.3) is observable if N > 2M and for every set J ⊂ {1, .., N} with card(J ) ≥ N − 2M, the

45 pair (Φ,HJ ) is observable, where HJ is a matrix obtained by stacking all the output matrices Hj : j ∈ J .

The result means that if a system meets these conditions for a subset of attacked outputs, it retains observability even under attack, provided that the attacked sensors are removed. The ﬁnal piece of necessary background information is the unknown input observer.

4.1.3 Unknown Input Observer

The goal of an Unknown Input Observer (UIO) is to provide a state estimation in the presence of an unknown input in the system, a disturbance [15]. The previous section on dynamics monitors provides an analysis of the system, but does not contain any mechanism for detection. A UIO implements the dynamic monitor.

The observer design comes from [15]. The UIO is designed for the system given by (4.1), where E = I. The system also has to be modiﬁed to account for unknown input disturbances, consider the altered system:

xk+1 = Φxk + Γuk + Edk (4.4) yk = Hxk + Duk + Eydk

n r Where E ∈ R × r is the unknown input dynamics matrix, dk ∈ R is the unknown

n×n n×m p×n p×m p×r disturbance input vector, Φ ∈ R ,Γ ∈ R , H ∈ R , D ∈ R , Ey ∈ R .

m The input vector has a diﬀerent meaning then (4.1), uk ∈ R is the input vector not an attack input. This is important as the input in (4.4) is a characteristic of the system, not a model of the attack, how attacks are modeled in relation to the UIO is provided later. For the observer design it is assumed that no input eﬀects the output

46 such that:

xk+1 = Φxk + Γuk + Edk (4.5) yk = Hxk

Methods from [15] can be used to transform (4.4) to (4.5). A new outputy ¯k = yk−Huk can be used to remove the known input eﬀect on the output. A transform matrix Ty can be used such that TyEy = 0 to remove the unknown input eﬀect on the output.

The following equation is the deﬁnition of the UIO:

a zk+1 = Fuiozk + TuioΓuk + Kuioyk (4.6) xˆk = zk + Huioyk

The resulting estimation is decoupled from any eﬀect on the system caused by the unknown input disturbance dk. This can be proven by deriving the error dynamics for the observer, where ek = xk − xˆk:

ek+1 = [(Φ − HuioHΦ − K1H) − F ]ek + [(I − HuioH) − Tuio]uk (4.7) + (FHuio − K2)yk + (I − HuioH)Edk

As long as the following algebraic conditions hold then the observer (4.6) is an unknown input observer. The reference provides the complete design procedure [15].

(I − HuioH)E = 0

T = I − HuioH (4.8) F = Φ − HuioHΦ − K1H

K2 = FHuio

Where K = K + 1 + K2. 2 conditions need to hold per [15]:

1. rank(HE) = rank(E)

+ 2. (A1,H) is a detectable pair, where A1 = Φ − E(CE) HΦ

47 The notation (CE)+ refers to the left pseudo inverse. Also, detectable pair used here is not the same as the previous use of detectable [15]. An observable pair is also a detectable pair per [15].

4.2 Attack Model

Many diﬀerent attacks can occur. In general, the attacks focused on in this thesis are on the actuators and sensors of a system. The security strategy changes based on the attack execution. The security mechanism can not cover all possible attacks on

CAN. The security mechanism overlaps a communication protocol and CPS security concepts. Two subsections model the attack from the perspective of the NCS and the system dynamics.

4.2.1 CAN Attack Scenario Being Addressed

A trivial attack on CAN results in both attack packets and ligament packets available on the network. Many other IDS methods can detect these types of attacks.

In particular, the detector design for this type of trivial attack can use an S-1 - S-6 mechanism with no need to analyze payload. Here an assumption is made on the attack:

Assumption 3 The attack is a man-in-the-middle attack that alters the data payload of a message. From the assumed architecture presented in Section 3.1, this could occur from a compromised gateway or if an attacker has physical access to the vehicle. The attack is also smooth as required by [53, A3].

An attack such as this could replace packets as they pass through the gateway. The attack may also be able to shut down communication or remove packets. However,

48 again this falls into the category of a Denial of Service (DOS) attack, and other simpler

IDS systems can detect this behavior on the network without needing information from the payload of a packet.

4.2.2 Attacks on Observer-Based Security Mechanisms

From the system perspective, it doesn’t matter where or how the attack occurs on the network. If the attack is on as system given by (4.1) then it can be modeled as one of the following from ”Stealth, Replay, Covert, and Injection Attacks” in [55]:

1. Stealth

2. Replay

3. Covert

4. Dynamic false data injection attack

Any one of these methods can be used to attack a CPS system. An observer-based approach has to take into account the requirements needed to detect, and recover, from these attacks. Considered in this thesis are spoof, replay, and covert attacks.

Not addressed are Dynamic false data injection attacks. The following ﬁgure from,

[55], shows the three attack types from a systems view: Stealth attacks are modifying outputs with no knowledge of the system, replay uses previous knowledge of the expected output for a system to modify the outputs, and covert are replay attacks with feedback.

The biggest challenge for replay, covert, and dynamic fault data injection attacks is that an attacker can take advantage of the system dynamics equations. There are speciﬁc conditions that observer-based methods do not work against replay attacks

49 (a)

(b)

(c)

Figure 4.1: Diﬀerent attack types: (a) is a stealth attack, (b) is a replay attack, (c) is a covert attack [55]

[45]. If a system has some inherent instability in its dynamics equations, the following source demonstrates how to create a dynamic false data injection attack [46], which can not be detected by an observer-based method. Previously mentioned was that active monitors could combat this but come at a performance cost. Observer methods

50 are also susceptible to replay attacks. A UIO decoupling method addressed this concern, which addresses the concern over using an active control signal modiﬁcation.

4.3 UIO based IDS algorithm for CAN

The method requires an analysis of the NCS system. The analysis provides meaning between the presented UIO approach. As such, the algorithm contribution contains two parts:

1. Secure Control Algorithm for Authentication of Insecure Outputs Coming from

CAN

2. Unknown Input Observer for Attack Estimation

This approach uses an unknown input observer, or a bank of unknown input observers when necessary, to validate the measurements coming from CAN. A UIO observer provides a mechanism that provided a countermeasure to replay attacks without the need for an active monitor.

4.3.1 NCS Graphical Analysis for CAN Tasks, Messages, and Resources

There are related works in using graph theory as a method of formalizing an approach to IDS in Automotive E/E security design, related work for this approach is available from [71]. That approach is used in the design of a frequency and timing- based IDS method and is not directly applicable to an observer-based method.

The basic notation from [71] is utilized as a foundation and presented here in conjunction with some basic graph theory notation and deﬁnitions as required. In addition to using this as a tool to analyze CAN, trusted, and untrusted messages are

51 T Set of all tasks in NCS under investigation. M Set of all messages used between tasks. PT ∪ M R Set of resources in NCS, could be control unit or a communication network i.e. ECU and CANbus are 2 examples. GR(R,ER) Resource Graph used to define resources in networked control system. GP (P,EP ) Process graph that defines tasks and message passing between tasks. EM (P,R) Mapping of process in P to resources R formally defined as: f : P 7→ R.

Table 4.1: Basic NCS graph notation for tasks, resources, and messages

deﬁned using the resulting NCS graph. Providing an organized method to identify data in the NCS system that is trusted and what data is vulnerable to attack.

The notation about to be presented extends from [71, Section II-C]. A digraph

GP = (P,Ep) is presented to deﬁne message m ∈ M between tasks t ∈ T , where

P = T ∪M is the union set. Data dependency is presented as edges, e ∈ Ep. A second undirected graph GR = (R,Er) of resources r ∈ R, and a connection between two resources is an edge l ∈ Er. A resource is a control unit or a message-passing network.

A connection means that a data pipe exsists between two units. GP is mapped to GR using the mapping Em(P,R) deﬁned as a mapping function f : P 7→ R. Table 4.2 lists out these basic notations. An example is presented in ﬁgure 4.2. A 5 node graph GR, such that GR(R) = {F,B,C,D,E} are the resources or nodes of the graph.

The directed arcs of GR(ER) = {(A, B) , (A, C) , (B,D) , (C,D) , (D,E)}. An example for a process graph GP is given in ﬁgure 4.3. Where P = {t1, t2, t3, t4, m1, m2} and

ER = {(m1, t1), (t2, m1), (m2, t4),

52 Figure 4.2: An example resource graph

Figure 4.3: An example process graph

53 Figure 4.4: Example mapping of the process graph in Fig. 4.3 to the resource graph in Fig. 4.2

(t3, m2), (m1, t3)}. These two graphs can be mapped using EM (P,R). The result is

ﬁgure 4.4.

4.3.2 Formulation of a Secure CAN Message

The graph construction in the previous section does not include any information regarding the security of a CAN message. The term trust and the meaning of trust- worthiness have diﬀerent connotations depending on the application. The following assumption:

Assumption 4 Messages coming from a non-CAN resource are trusted.

54 This assumption reduced the complexity of the problem as the layer of focus is on

CAN, and the problem expands to far if considering the security of other layers.

Therefore, security mechanisms are in place or required for other systems.

CAN messages can be assumed trustworthy if proper security mechanisms are in place, such as authentication. Within the CAN network, the trust of a message can be achieved through a Message Authentication Code (MAC), as mentioned in section 3.2.1. The following assumption follows:

Assumption 5 CAN messages are untrusted unless authenticated using an appropriate MAC and associated secure communication protocol.

Here the assumption is made because if nothing is trusted, then the ability to create a proper security mechanism becomes extremely diﬃcult and potentially unfeasible.

Anomaly detection requires some amount of trusted information is required. This requirement also requires one to be present in the system. Given the requirement for Over the Air updates, this is reasonable to assume. The performance cost is in the use of the system, not the presence. The goal is to reduce the use and have an authentication mechanism present that does not impede that objective; rather, the use of it is more important.

As mentioned in section 3.2.1 the utilization of cryptography results in decreased performance. The set of all messages on a CAN network is a subset of M. The subset is deﬁned as MCAN ⊆ M. A new set of trusted messages is deﬁned as Mt ⊆ M.

MCAN is the set of messages paired with a CAN resource after applying EM . Mt is up to the designer. A best case scenario is that the ﬁnal security design does not require any message on CAN to be continuously authenticated, i.e MCAN ∩ Mt = ∅ unless a message m ∈ MCAN is under attack. However, there may be some CAN

55 Mt Set of all trusted messages. MCAN Set of all CAN messages.

Table 4.2: Notation for trusted and CAN message sets in NCS

messages that may require authentication at all times, also some message will require authentication when under attack, this can be realized by the intersection Mt ∩MCAN .

These cases and the rationale are apparent at the conclusion of the chapter.

4.3.3 Connecting CPS System Model to CAN Network Graph

Following Assumption 5 an authenticated messaged belongs to the set Mt. The connection between a CAN message and the system attack set, K, is deﬁned as:

Deﬁnition 4.3.1 If a system output yi i ∈ {1, ..., p} has an associated message

m ∈ MCAN , such that there exists a sample when m∈ / Mt, its index, n + i where n is the number of states, is part of the attack set K of the the dynamic monitor, and there can exist a sample k such that ψ2 ∩ {i + n} = {i + n} could occur.

For this deﬁnition, every CAN message has the potential to be manipulated by an adversarial attacker. Authentication provides trust. A trusted CAN message:

Deﬁnition 4.3.2 If a system output yi i ∈ {1, ..., p} has an associated message

m ∈ MCAN , its index, n + i where n is the number of states, is part of the attack set

K of the dynamic monitor. If m ∈ Mt the output of the monitor is ψ2 ∩ {i + n} = ∅.

In the case that the system contains a fault, a false positive can occur. A false pos-

itive can also occur if the authentication mechanism is compromised. The following

deﬁnition provides the method to remove a CAN message from the attack set K:

56 Deﬁnition 4.3.3 A message m ∈ MCAN authenticated throughout vehicle operation

can never be attacked and thus does not belong to attack set K.

This deﬁnition implies that unless a measurement, i.e., sensor, requires authentication

at all times, it is always part of the attack set K. Here the cost of performance would be deemed necessary to retain the ability to design the security mechanism. The presented case study utilizes this deﬁnition.

The dynamic monitor attack set includes attacks on states and outputs. The attack set K¯ contains vulnerable outputs.

Deﬁnition 4.3.4 Deﬁne a CAN sensor attack set K¯ ⊆ K. Let N be the cardinality ¯ ¯ of yk, and M be the cardinality of K Where |K| = M : M ≤ N..

The set provides a connection to attack observability. Now, M = |¯

K—andN¿2MandtheobservabilityrequirementofT heorem4.1.1holdsthenobservabilityunderattackholds.However, ifM≥

N 2 , then the dynamic monitor is required as messages under attack require authenti- caiton to retain attack observablity. Attack observablity allows for the estimation of

attcks on the input.

A new attack set is given as K˜ for inputs that come from CAN messages.

Deﬁnition 4.3.5 An input attack set K˜, where |K|¯ = r, is the set of inputs on (4.1)

that originate from a CAN message.

The attack set of inputs is not a subset of K. The distinction is important as this

method needs to know what input is under attack, not the state, as a single input

may attack multiple states. The UIO back-calculated the attack input if attack

observability holds.

57 4.3.4 UIO based Dynamic Monitor for Attacks on CAN Sen- sor Messages

A UIO was used to decouple the attack. The reason a UIO is rather than a

Luerenburger observer is to counter replay attacks. Provided it has removed the

eﬀect of an attack on the input, any attack on the input would not be part of the

estimation. Consider the system:

xk+1 = Φxk + Γuk + ΓK˜ ak (4.9) yk = Hxk

With a residual deﬁned as:

rk = yk − yˆk (4.10)

s The attack is an unknown input into the system ak ∈ R . ak is the attack, modeled as a deviation from the input uk. A residual generator shows how much the estimate diﬀers from the measurements. The attack does not aﬀect the estimation. Therefore the residual detects attacks on sensors regardless of attacks on inputs. This result detects if a CAN message in the attack set K¯ is under attack but does not identify which message is under attack.

One approach to identify which sensor is under attack is to use a bank of observers, removing sensors from the model as needed to remove their inﬂuence on the observer.

Then use a residual general on each of the modiﬁed systems to detect which set of senors is under attack. The source [15] shows a design case for identifying faulty sensors, with the assumption that only one sensor is faulty. From a security perspective, the assumption of one entity under attack at a time from K¯ does not hold.

From reference [55], the number of sensors that can be identiﬁed is dependent on

58 Remark 4.1.3, or the structure graph linking size, l. Given this analysis is on CAN, it presents a unique take on identiﬁcation.

A CAN packet contains multiple messages or a set of messages. Authenticating a packet with a speciﬁc ArbID authenticates all messages in that packet. This was addressed by presenting a deﬁnition of a payload:

Deﬁnition 4.3.6 A payload is given a set indices of the outputs, yi : i ∈ {1, ..., p}, of the system (4.9) where the output has an associated message m ∈ MCAN that is also part of the attack set K¯, refer to Def.(4.3.1,4.3.2).

There are multiple payloads on CAN and a speciﬁc payload, indexed using the notation j ∈ {1, 2, 3, ...}. A system can be modiﬁed such that it is not sensitive to payload j where the resulting UIO is not sensitive to CAN messages contained in the removed payload:

xk+1 = Φxk + Γuk + ΓK˜ ak (4.11) Pj yk = HPj xk;

(p−|Pj |)xn Where HP j ∈ R and j ∈ N≥0 is the packet index. HPj matrix is modiﬁed such that all outputs messages in the payload are removed, and as such the appropriate rows are deleted from H. Following notation in [15], hi : i ∈ {1, ..., p} is the ith row

of H and Pj ⊆ {1, ..., p}. Therefore, HPj is the removal of all rows hi of i ∈ Pj.

Pj Pj rk = yk − yˆk (4.12)

Now a bank of UIOs can be constructed based on to identify attacks on sets of messages. A design consideration is on the direct interpretation of a packet. There may be a case where |P|| > l.

59 If the identiﬁcation of all messages in P| is not possible, the designer has to modify the CAN packet or the messages in Pj. Pj is a concept and does not have to be directly associated with the CAN structure. The importance here is that untrusted measurement messages may exist in multiple packets, and it may not be possible to detect if all of the messages are under attack at once, depending on if a UIO exists.

4.3.5 Security Mechanism for Trust of Message under Sensor Attack

The previous UIO derivation is used to design a dynamic monitor given in Def- inition 4.1.2. Its purpose is to require authentication on attacked sensor readings.

The following equation uses the residual generator for the UIO given in (4.9). This

Algorithm 1 Dynamic Monitor Output Using a Residual Generator

1: procedure Sensor Attack Detection(yk, yˆk) 2: rk ← |yk − yˆk| 3: i ← 0 4: while i < length(rk)& ψ1 = false do i 5: if rk > Tr then .Tr = threshold 6: ψ1 ← T rue 7: else 8: ψ1 ← F alse 9: end if 10: i ← i + 1 11: end while 12: return ψ1 13: end procedure

algorithm sets the detection of the dynamic monitor,ψ1 but not ψ2. In order to do

this a similar algorithm is run, but for all the diﬀerent packets and combintaions

within a packet. From [55] it is known that the total number of UIOs to achieve

60 n+p complete attack identiﬁablility is equal to |K| . Tr accounts for inaccuracies in the

Algorithm 2 Dynamic Monitor Attack Identiﬁcation and Authentication Request of a Payload of Messages 1: procedure Sensor Security Control Mechanism 2: while true do 3: function Sensor Attack Detection(yk, yˆk) . Algorithm 1 4: end function 5: detect ← ψ1 6: i ← 0 7: ψ2 ← ∅ 8: while i < length(rk)& detect = true do Pj Pj 9: if rk > Tr then .Tr = threshold 10: ψ2 ← ψ2 ∪ Pj 11: end if 12: i ← i + 1 13: end while 14: function Request Authentication(ψ2) 15: end function 16: return ψ2 17: end while 18: end procedure

estimation. Under attack rk ≥ Tr. This algorithm adjusts ψ2 by adding every attack set to its set depending on if the associated UIO has a residual over some designed

Pj threshold Tr . Notice that there is no signal to remove authentication, as this could lead to unintended consequences of providing a security mechanism to an attacker.

How to handle the secure communication protocol of this signal is for future work and left to the designer. A potential issue being an attack can cause the residual to hover around the threshold.

61 4.3.6 Security Mechanism for Control Input Under Attack

Observability under adversarial attack holds provided that the security mecha-

nism from the previous section is in place to authenticate sensor messages as needed.

Determining if there is an attack occurring is then straight forward. The estimate

provided by (4.13) can be used to back calculate ak using (4.13).

Γ+(x − Φx − Γu ) = a (4.13) K˜ k+1 k k k

The estimate is derived from the system (4.9). Where Γ+ is the pseudo left inverse K˜ of the attack signature matrix.

4.3.7 Limitations

There are a few limitations. One is on the full rank observability of the UIO. In some cases, the error dynamics can not be controlled entirely in the UIO design; an observable canonical decomposition can be performed in these cases to create a UIO per [15]. The means performance of the UIO is not entirely up to the designer. The noting of UIO design limitations is a result of encountering this issue. Just because a

UIO exists, it does not mean that it can meet the performance requirements in this case. Also, with any model-based method, the model ﬁdelity plays a signiﬁcant role in the accuracy of the result. The other major note is on inaccuracies that present themselves in implementation. A threshold accounts for the inaccuracy of the modeled system as well as any other potential inaccuracies. As a result, any attack within the threshold will result in a false-negative. This is an important design consideration.

The threshold represents how much inﬂuence an attacker can have on the system before detected. It also is largely inﬂuenced by how much noise or other inaccuracies

62 exist. In fault diagnostics, this is a heavily studied topic, and potential solutions may be applicable but are not considered further in this work.

63 Chapter 5: Autonomous Vehicle Engine Throttle Control Case Study

Consider a safety-critical AV task. First, the process and resource graphs are constructed, following Chapter 4 Section4.3.1, focused on a throttle control task.

Next, the design of an observer-based attack detection system. The attack scenario considered follows the assumptions in the design methodically from Chapter 4.

5.1 NCS Graph Analysis for Engine Throttle Control

The throttle task and its interaction with the engine is analyzed. The engine here is used by an autonomous system and thus presents a unique system-level design. The system consists of an Autonomous Vehicle Control Unit (AVCU), Engine Control Unit

(ECU), and Engine. These are the actors of interest in this study and are presented in ﬁgure 5.1. The ECU conducts the low-level engine control, in which the AVCU requests a throttle body position. The Transmission Control Unit (TCU) is in charge of low-level transmission control. The AVCU unit does not control the transmission.

Both the TCU and ECU have sensors connected to their associated plants. As for the AVCU, it has a Global Positioning System (GPS) and Inertial Measurement Unit

(IMU).

64 Figure 5.1: Network setup for the computational units relevant to this case study

Figure 5.2 is the resource graph, GR, for the system presented in Fig. 5.1. The

process graph provides more information beyond the high-level controllers. There

are two sensors connected to the ECU: engine speed and Manifold Absolute Pressure

(MAP). This case study assumes there is a Sensor Fusion node connected to the AVCU

to provides ﬁltered actual vehicle velocity, va, rather than raw GPS and IMU data.

The graph also contains 2 CAN resources, passing information between a gateway.

The set of nodes that participate in CAN communication are {ECU, T CU, ACU}.

The process graph is given in ﬁgure 5.3.

The process graph GP consists of 4 tasks. One task is creating a throttle request.

The other is engine speed control, another handles the gear selection, and ﬁnally, a task represents the gateway passing messages between CAN networks. The tasks and messages from GP can be mapped to GR using the mapping EM . Figure 5.4 provides

the major takeaway from the mapping, given that a ﬁgure of the entire mapping would

be cluttered and not provide any meaning. Any message mapped to a CAN resource

is a CAN message. The torque load and spark advance, ϑ messages, are constantly

65 Figure 5.2: Resource graph for AV throttle request

authenticated. The meaning of the messages and the rationale for requiring constant authenticating on a couple of the messages becomes clear after presenting the engine model.

The Gateway node is the node under attack in this scenario. Therefore, the attacker can run a man-in-the-middle attack on the throttle control task as it will have to move from CAN1 to CAN2. The process and resource graph provide all the necessary information on tasks, messages, resources, and data flow. The throttle request is the vulnerable message of primary concern. As such, the meaning behind the messages presented needs to be clarified. How the throttle angle influences the vehicle needs to be understood to create a security mechanism.

5.2 Engine

There can be diﬀerent ways that an AVCU adjusts vehicle speed. Not provided are the detailed operation of an engine. However, some basic understanding is required.

66 Figure 5.3: Process graph for throttle control task

An engine has a throttle body, the throttle body angle, in degrees, is adjusted to increase or decrease the engine speed by adjusting airﬂow. In practice, the AVCU may send a normalized pedal position from 0-1 rather than directly sending the desired throttle body angle. Another control strategy would use the pedal potion to create the actuation command, throttle body angle. A combination of a pedal map and a torque map can provide the throttle body request angle from the pedal position angle.

This analysis looks at the case that the throttle body is requested. It is assumed that regardless of the control strategy, the throttle body request is known without using

67 Figure 5.4: Mapping of process graph to resource graph focused on targeting the messages used for the observer and vulnerable CAN messages

68 Figure 5.5: Engine Model I/O

a CAN message. Since the task under investigation is an actuation command that

propagates through the engine, naturally, an engine model is required for the observer

design. The engine model comes from related work [?, ?, ?]. Figure 5.5 shows the input-output relationship of the engine model used in this thesis. The inputs are throttle body angle, α in deg, spark timing advance, ϑ, in deg bTDC, Tload in Nm.

Torque load accounts for external forces resisting the engine. Spark timing advance causes instant changes in engine speed, and it adjusts when the spark plug ignition spark is triggered. The outputs are engine speed, ω in rad/s, p is the Manifold Intake

Pressure (MAP) in Pa, and Tind is the indicated Torque provided by the engine at the crank before the removal of torque loss to friction and Tload. AVCU does not control

ϑ, and does not know Tload.

Assumption 6 The ECU has the ability to estimate Tload and controls vartheta.

This security mechanism requires the ECU to retain this assumption. Provided these are low-level controls, estimating them is not going to be easily achievable by the

AVCU, requiring authentication on these messages at all times solves this challenge.

69 The choice of the state-space model had a signiﬁcant eﬀect on the ability to design

this security mechanism. A few derivations of the model highlight these struggles.

Section 5.2.3 provides the State-Space model used in the security mechanism design.

5.2.1 Continuous Time Engine Model

The non-linear time-domain equations for the engine model have been calibrated,

veriﬁed and are given in equation 5.1, and can be referenced in other works[37, 78,

39, 38] :

2 p˙ = Kp1Kthr(a2α + a1α + a0) − Kp2pω + Kp3ω 1 ω˙ = (T − T − (K ω2 + K ω + K )) (5.1) J ind load fr1 fr2 fr3 2 Tind = KT (b1p(t − td) − b0)(c2ϑ + c1ϑ + c0)

The constants for the model can be found in Appendix A. There is a practical chal-

4π lenge with using this model because td = Zω is a state dependent time delay, where Z is the number of cylinders in the engine. To reduce the complexity of this problem

the state dependent variable delay becomes a constant delay by converting the model

into the crank-angle domain. The crank-angle domain means the equations are a

function of the crank shaft angle θ rather then time t. Equation 5.2 provides the conversion method. d d dθ = dt dθ dt dθ = ω (5.2) dt d 1 d = dθ ω dt

70 Using (5.1), (5.1) was divided by the engine speed ω resulting in the crank-angle

domain model (5.3):

K K p˙(θ) = p1 thr (a α2 + a α + a ) − K p(θ) + K ω(θ) 2 1 0 p2 p3 1 T (θ) T (θ) K ω˙ (θ) = ind − load − K ω(θ) + K + fr3 (5.3) J ω(θ) ω(θ) fr1 fr2 ω(θ) 2 Tind(θ) = KT (b1p(θ − θd) − b0) · (c2ϑ + c1ϑ + c0)

4·π Now, θd = Z where Tind is a function of constant time delayed state,p(θ − θd, rather then a state dependent variable time p(t − td).

Linearization is required to ﬁnd the LTI state-space model, needed to design the security mechanism. The drawback of linearization is that the model only holds near

load the operating point. Essentially there is a cost in model ﬁdelity. Given α0, ϑ0,T0 the equilibrium point for an operating point are found by solving the set of non-linear

equations (5.4).

Kp1Kthr 2 0 = a2 · α0 + a1α0 + a0 − Kp2p0 + Kp3 ω0 ind load 2 (5.4) 0 = T0 − T0 − Kfr1ω0 + Kfr2ω0 + Kf r3

2 0 = T0 − KT (b1P0 − b0)(c2ϑ + c1ϑ + c0)

ind load The linearization is conducted around the operating points, ω0, p0,T0 , α0, ϑ0,T0 . The linearized equations are given in (5.5). Where δ is the deviation from the lin-

earized operating points.

K2 K1 δp˙ = −K3δp − 2 δω + δα ω0 ω0 Kf 1 1 (5.5) δω˙ = − 2 δω + δTind − δTload Jω0 Jω0 Jω0

δTind = Kpδp(θ − θd) + Kϑϑ

71 The constants and linearization derivation for equation 5.5 can be found in Appendix

A. There are two democratization methods presented, a billinear numerical approximation and a zero order hold. Originally, the bilinear method was going to be used but was found to present some noteworthy challenges.

5.2.2 Bilinear Approximation Discretization State Space Model

Equation 5.6 is the resulting state-space matrix for (5.5) after applying a billinear numerical approximation discretization. Equation 5.8 is the state equations, including the total torque equation Ttot. The discretization has a sampling rate of τd. The

π sample rate is in radians of the crake shaft. Therefore a sampling rate of 3 is sampling every 60 degrees of rotation.     R11 R12 0 0 Q12Kp Q11 Q12Kϑ −Q12 R21 R22 0 0 Q22Kp Q21 Q22Kϑ −Q22     Φ = S11 S12 0 0 U12Kp  Γ = U11 U12Kϑ −U12       0 0 1 0 0   0 0 0  (5.6) 0 0 0 1 0 0 0 0 S S 0 0 U K U U K −U H = 21 22 22 p D = 21 22 ϑ 22 S11 S12 0 0 U12Kp U11 U12Kϑ −U12

 α  ω Where u = ϑ , and y = and the state equations are given in (5.7) and k   k p Tload (5.8).

x (k + 1) x (k) α(k) 1 = R 1 + Q x2(k + 1) x2(k) Ttot (5.7) p(k) x (k) α(k) = S 1 + U ω(k) x2(k) Ttot

72 CT 1 CT 3 CT 4 x1[k] = −√ p[k] − √ ω[k] + √ α[k] τd τd τd CT 5 CT 7 x2[k] = −√ ω[k] + √ Ttot[k] τd τd

x3[k] = p[k − 1] (5.8)

x4[k] = p[k − 2]

x5[k] = p[k − 3]

Ttot = Kpx5[k] − Tload[k] The model in (5.6) shows why the network analysis incorporated engine speed and pressure messages on CAN, these are the outputs of the system and are needed in for the observer.

However, a UIO does not exist for this model. It is not possible to ﬁnd a transform matrix, Ty, to modify the system to meet (4.9). The error dynamics equation does not hold, and the UIO does not exist. Another method for discretization is applying a zero-order hold (ZOH).

5.2.3 Zero Order Hold State Space Model

Equation(5.3) was discretized using a zero order hold, following the deﬁnition of a zero order hold given in (5.9).

z − 1 G(s) G(z) = Z (5.9) z s

The state space matrices are given in (5.10).

 −τdK2  τ K 1 − τdK3 0 0 0  d 1 0 0  ω0 ω0 τdKf Kpτd τdKtheta τd  0 1 − 2 0 0   0 −   Jω Jω0  Jω0 Jω0  0    Φ =  1 0 0 0 0  Γ =  0 0 0       0 0 1 0 0   0 0 0  (5.10) 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 H = D = 0 1 0 0 0 0 0 0

73 Here D= 0, and there is no eﬀect of alpha on the measurements, which solved the

0 previous issue with the bilinear model. The input vector is uk = [α ϑ Tload] , the

0 output is yk = [p ω] .

Assumption 7 There exists an authenticated CAN packet that contains Torque load

and spark advance values from the ECU node.

As the ECU has or can estimate these values, the assumption is realistic. Making

this assumption does require a cooperative design. Both are provided in the list of

available diagnostics messages from J1979. J1979 is a diagnostic protocol that runs

on CAN and is required for environment regulation [66], also known as OBD-II.

5.2.4 ZOH Engine Model Structure Graph and Attack Set

The dynamic monitor deﬁnes the attack set as attacks on states an outputs. An

attack index set, {1, 2, 3, 4, 5, 6, 7}, is used to index states and outputs from the state

0 0 vector xk = [pk, ωk, pk−1, pk−2, pk−3] and output vector yk = [pk k] respectively. The

full attack set is given as K = {1, 6}. However, the output attack set is K¯ = {6}.

This is achieved by using the UIO to decouple the eﬀect of the inputs that cause the state attacks. This is why the attack signature is created using K¯. Given that K¯ is the attack set an analysis can be made on detectability.

Figure 5.6 is the structure graph for ( 5.10). The inputs and outputs are the index of the input and output vectors uk, yk respectively. Here is where the biggest contribution of the UIO is apparent. The linking size from the vulnerable input, u1, to the vulnerable output, y1, is l = 1 but the cardinality of |K| = 2 which means that there is an undetectable attack per Deﬁnition 4.1.3. By decoupling the input and using the attack set, |K|¯ , the attack set cardinality |K|¯ = 1 which does not

74 Figure 5.6: Structural digraph for the zero order hold engine model showing a link size of 1 for a vulnerable state x1, pressure, and its associated output reading y1

75 contain undetectable attacks. Also, replay attacks are countered as the attacker can

not inﬂuence the states and output at the same time.

5.3 UIO Construction for AV Engine Control Security Mech- anism

The zero-order hold state-space matrices from ( 5.10) are used to construct a UIO

0 that decouples attacks on α. The input vector, uk = [α ϑ Tload] , can be interpreted

as the index set {1, 2, 3}. Using the index, the input attack set is now K˜ = {1}.

Therefore, the disturbance matrix ΓK˜ is the attack signature and is the 1st column vector of Γ from (5.10).  τdK1  ω0  0    Γ ˜ =  0  (5.11) K    0  0 Modeling the attack, this was changes the interpretation of the attack. The attack is a deviation from the desired input. Therefore, if an attack is equal to the throttle request is not detected. The resulting UIO design matrices are:

0 0 0 0 0 1 0 0 1 0 0 0 0 0     T = 0 0 1 0 0 Huio = 0 0     0 0 0 1 0 0 0 0 0 0 0 1 0 0 (5.12)  −0.0061 0 0 0 0   0 −0.0000  0.7887 0.0261 0 0 0.0004  0 0.9728      F =  0.0031 0 0 0 0  K = 1.0000 −0.0000      −0.2857 −0.0068 1 0 0   0 0.0068  −46.3019 0.1827 0 1 0 0 −0.1827

76 Figure 5.7: Attack detector system-level view where the two highlighted systems secure the pressure reading and throttle control messages

5.4 IDS and Mitigation Security Mechanism

The remainder of this chapter is the design of the attack detection mechanism.

The entire design requires two parts, to detect and secure the p message, then to

estimate and secure attacks on α. The implementations are quite straightforward, as they follow algorithms 1 and 2. Reviewed are just the yellow highlighted sections, the rest is assumed knowledge but shown in the ﬁgure for clariﬁcation. How the system implements the sensor fusion and vehicle speed to engine speed conversion is out of this scope, given there are many methods, and the best approach requires a

77 separate eﬀort. Also, remember the spark and torque load inputs to the engine are assumed authenticated and trusted and do not need to be considered further in this implementation.

5.4.1 Pressure Sensor Attack Detector and Security Mecha- nism Design

The detection of the pressure sensor comes from implementing Algorithm 1 using the engine model UIO (5.12) to provide the estimate. The observer uses, pvalid and

ωGP S, as well as the driver model throttle control request message α, which are all trusted messages. The residual is the diﬀerence between the measurements from

CAN and estimated measurements from the UIO. The UIO has decoupled attacks on inputs, and therefore the residual is only responsive to attacks on pressure. Here the threshold is, Tr = 0. So if the residual is non-zero, the attack is detected.

The next chapter tests this case in both an ideal and more realistic implementation. For the more practical implementation, the threshold had to be increased, and was dependent on the application. If the residual becomes larger than the threshold, the dynamic monitor sets a detection, ψ1 = true. Provided there is only one item ¯ under attack in the attack set K this implies that ψ2 = {6} and authentication on pressure is requested.

Future work needs to explore further how to manage the authentication request, i.e., is the dynamic monitor triggered exactly when the threshold id broken or is there some time above the threshold before triggering. Also, how to reset the mechanism.

78 5.4.2 Throttle Actuator Attack Detector and Security Mech- anism Design

The previous section introduced a detector and security mechanism for pressure,

which ensures pressure is valid. Proved that there are only two sensors, both have

to be trusted to estimate the attack, per Deﬁnition 4.1.1. This method does not

account for the delay in starting and using authentication nor delay introduced from

CAN. Therefore it is should be noted that in the implementation actuator attack

estimate is unknown when the pressure attack residual, the previous section is above

the threshold.

The detector uses the UIO (5.12) for state estimation. The detector then reports if

there is an attack on α using (4.13) if the absolute value of the estimate, |aˆk|, is greater than a chosen threshold. During testing, the threshold needed to be increased in a more realistic environment that presented inaccuracies, such as network delay. Similar to the pressure detection, future work needs to address implementation concerns.

79 Chapter 6: Implementation, Simulation and Results

The ﬁnal step is to test the security mechanism designed for the AVCU throttle control request. Presented ﬁrst is the results from an idealistic case run in the crank angle design. The purpose is to numerically demonstrate the usefulness of using a

UIO to decouple attacks. Then a time domain simulation with a virtual CAN is run.

Finally, a Hardware in the Loop (HIL) setup tested the security mechanism with a real CAN network. Unfortunately, due to extenuating circumstances, the HIL setup was not able to be completed due to restricted lab access.

6.1 Model in the Loop Testing

Matlab and SIMULINK provide the tools for simulation and algorithm design.

First, the constructed UIO was designed and tested in the crank angle domain. Next developed was A Model in the Loop (MIL) design, including a getaway and virtual

CAN. Not considered in MIL testing are authentication and secure communication protocols. As mentioned previously, both of these topics are out of scope.

6.1.1 UIO test in the Crank Angle Domain

A baseline simulation provides behavior when not under attack. The operating points are: ω0 = 82.9, p0 = 26424,Tind0 = 21.3765, α0 = 9.81, ϑ0 = −25,Tload0 = 10.

80 During the simulation, a torque load disturbance of 10Nm is added at 600 degrees and then removed at 900 degrees. In this section a linearized model is used and the results are the delta form these operating points. Figure 6.1 is as expected. The

Figure 6.1: Simulation results with no attack: MAP and engine speed actual output and estimation from the UIO

observer perfectly matches the model. The exact match is expected as the model is the same being used by the observer without any other inaccuracies to consider, currently. The residual in Fig. 6.2 is zero as expected.

81 Figure 6.2: Simulation resulting engine speed residual when not under attack

Figure 6.3 is a simple pressure attack that adds 1000Pa to the pressure measurement at 800 degrees into the simulation. The diﬀerence in the plotted result of

Fig. 6.3(a) shows the attack. The resulting residual is eﬀected by this attack as shown

(a) (b)

Figure 6.3: Simulation results when pressure message is under attack: (a) Attacked pressure signal, (b) Engine speed estimation with attacked pressure signal

82 in Fig. 6.3 (b). The residual is non-zero show in Fig. 6.4 for the attack on pressure.

An attack on pressure has no eﬀect on engine speed. To eﬀect the engine speed an

Figure 6.4: Residual of attack simulation in Fig. 6.3 showing that the residual is sensitive to an attack on the MAP, pressure, message

attack was conducted on the throttle body input, α.

The decoupling was testing by initiating an attack on α at 1000 degrees into the simulation, shown in Fig. 6.15 along with the residual. The resulting residual on was zero as shown in Fig 6.15(b). Showing that attacking the input has no eﬀect on the residual used to detect sensor attacks. The resulting engine speed and estimate is shown in Fig. 6.6. These plots show that the monitor is producing the expected behavior. The UIO can detect sensor attacks without the inﬂuence of input attacks.

The engine speed in Fig. 6.6 is clearly modiﬁed from Fig 6.1. In the design of the security mechanism, if the residual goes outside the threshold, the pressure message

83 (a) (b)

Figure 6.5: Results of an attack on throttle control signal α: (a) The attacked signal, (b) The resulting residual when the throttle is under attack

Figure 6.6: Resulting engine speed from the attack on α

84 is going to require authentication. However, in practice, a simple binary solution may not be practical.

The next test was an input attack. The assumption is that the pressure message is not under attack or authenticated. Figure 6.7 provides the estimation of the attack.

When the attack estimate is non-zero, α is under attack, given this is a perfect

Figure 6.7: The estimate of the attacked throttle signal showing the UIO can be used to estimate the attack properly.

simulation. This test did not include inaccuracies that may arise in a more realistic setting.

6.1.2 Time Domain and CAN simulation

The purpose of the MIL design in the time domain is to compile down the algorithm to run in a HIL setup. The simulation needs to include a gateway, CAN, and a method for running the security mechanism in the crank angle domain.

MATLAB virtual network toolbox simulates the CAN network. The engine model is operating in the time domain. The engine model used was the linear time-domain

85 (a) (b)

Figure 6.8: Initial engine speed estimation and residual when the system is not under attack: (a) Engine speed and engine speed estimate, (b) Residual output

model. The UIO requires to be operating in the crank angle domain. To operate the observer in the crank angle domain, the engine speed, ω, was integrated over time to

π provide the crank angle θ. Then the security mechanism is triggered every 3 radians. SIMULINK was the tool used for the simulation design, and algorithm design.

The first run is to demonstrate normal behavior, Fig. 6.8 shows the result. Throttle input is controlled by a simple PID that tries to retain a constant engine speed constant at 800 RPM. The spark is held constant at -25 bTDC. The torque load profile first tested follows the signal profile in Fig. 6.9(a). The torque load profile replicated potential gear shifts when a large spike would occur. The first noticeable difference is there are inaccuracies in the simulation, as seen from the noisy residual.

The current rationale is that these issues are steaming from the integration used to provide the crank angle sampling time.

86 If a scenario, such as Adaptive Cruise Control (ACC) on the highway and a gear change, doesn’t occur, this issue does not preset itself. It is left to future work to improve on this approach. Generally, there are other methods in residual generation techniques and discretization methods that could potentially help but are out of scope for this work. Figure 6.9(b) shows the new torque load proﬁle used for the remainder of testing. The resulting engine speed and residual are provided in Fig. 6.10. The

(a) (b)

Figure 6.9: Torque load profiles for two scenarios: (a) profile simulating a smooth driving scenario (b) profile simulating large deviations potential resulting from gear changes,

residual contains a less noisy signal and the large discontinuity spikes are gone. There is still some time at start up that is required for the observer to stabilize.

Next, an attack conducted on the CAN pressure message in the gateway showed the ability of the UIO to detect an attack on pressure. The attacker intercepts the

CAN pressure message in the gateway and adds 300 Pa. Figure 6.11 shows the attack along with the residual.

87 (a) (b)

Figure 6.10: Resulting residual and engine speed without abrupt changes in torque load, using torque load proﬁle Fig. 6.9(a): (a) engine speed and engine speed estimate, (b) engine speed residual

(a) (b)

Figure 6.11: Results from pressure attack on CAN pressure message: (a) adjusted pressure value(b) resulting residual taken from engine speed estimate and measurement showing the mechanism is response to pressure attacks

88 Figure 6.12: Current HIL setup showing the relationship between components on the real-time machine and the CAN network

6.2 HIL Test Bench Design

The MIL setup provided numerical conﬁrmation that the simulation worked. How- ever, the simulation does not consider many inaccuracies that arise during implementation. The objective of the HIL implementation was to use equipment to perform authentication and provide a realistic CAN network with heavy network traﬃc. Lim- itations, however, resulted in the system set up in Fig. 6.12. Both of these operations

89 are not modeled and have impacts of the performance of this security mechanism, and testing could provide numerical data from the eﬀects. Provided the lab equipment could not be accessed; the HIL simulation provided operates on a real-time machine with a real CAN network. There is no authentication mechanism available, and the

CAN traﬃc is just the essential message. COVID-19 restrictions on facility access limited the testbench functionality.

6.2.1 Real-time Machine Setup

A SpeedGoat real-time machine with a Xilinx Virtex-7 FPGA reduced development time. The device comes with software used to compile and upload a SIMULINK model. Therefore an algorithm can be designed in SIMULINK and then implemented to run real-time. It also auto-generates the VHDL as well as synthesizes the FPGA bitstream. The bitstream sets up the logic gates and lookup tables in the FPGA. In practice, the goal would be to operate the FPGA in parallel to the CPU functions.

The rationale for this approach is that the security mechanism does not require a large amount of CPU time, as the AVCU would already be using a large amount of computational power to operate.

Provided there is no access to a full testbench or lab equipment, the HIL setup is not able to perform the synthesis as the license that is required is located within the inaccessible facilities. The simulation contains three main components: engine, ECU, and AVCU. The resource, task, and message setup follows from the previous chapter network analysis.

90 (a) (b)

Figure 6.13: Base HIL run engine speed estimate, open-loop no attack

6.2.2 Results on Preliminary HIL setup

The test run methodology follows the previous sections; however, there is no PID engine speed control. The simulation used a throttle input of 9.81 degrees. The ﬁrst run contained no attacks. The torque load proﬁle is unchanged from Fig. 6.9(b) but only runs for 10 seconds instead of 30, provided it runs real-time this shortens the time between runs. The initial run shows that the engine speed estimate is working on the HIL setup. Also, Fig. 6.13(b) is the residual with a threshold decided based on the initial result. The threshold equals 0.1. The next test is to run a pressure attack to see if the residual becomes larger then threshold during an attack on the

CAN pressure measurement message.

In the gateway, the ”attacker” modiﬁes the pressure message by adding 300 PA.

Figure 6.14 provides the resulting attack and residual. Here a major consideration on triggering the attack detection is demonstrated. If the threshold is 0.1, then the

91 (a) (b)

Figure 6.14: Pressure attack of an increase of 300 Pa on HIL setup

detection mechanism would trigger; however, it would also drop back to an allowable value during the attack. The designer has to choose how to use the threshold. A strict implementation would require authentication once the residual exceeds the threshold, but this could result in a large number of false positives. An initial analysis shows that time outside of the threshold when not under attack is very small compared to an attack. A time outside threshold modiﬁcation might help but requires further work and testing.

Also, in the HIL case, the simulations are not going to be deterministic. The no attack case and attack case are the same simulation up to the 5-second mark. In the attack simulation, the residual drops below the threshold chosen in the nonattack case.

More data is needed to create a proper threshold. Also, the simulation should contain as many inaccuracies, or be as realistic as possible. Once the facilities reopened, the full testbench can be implemented and used to collect data on a more realistic scenario.

92 (a) (b)

Figure 6.15: Attack on throttle HIL setup

For now, launching a considerable eﬀort does not make sense. Any result would need reassessing once a proper testbench is available.

The next test is an attack on the throttle. The attack and estimate, along with an initial threshold choice, is shown in Fig. 6.15. Both cases follow with the expected results from the MIL section, but initial choices of threshold present some challenges.

Future work is going to require to build on this testbench and analyze performance and fully implement the security mechanism authentication system, i.e., determine a threshold strategy as well as how to manage authentication. More runs need to be conducted on a more realistic testbed to perform these tasks. Unfortunately, due to unforeseen diﬃcult circumstances following COVID-19, the proper facilities are closed at the time of preparing this thesis.

93 Chapter 7: Conclusion and Future Work

The goal of this thesis was to address automotive security from a safety perspective. As such, a background and motivation review introduced general security concepts and brieﬂy highlighted the state of automotive security. Automotive security is a relatively new domain of focus that has come on as a result of connectivity and autonomous features. Over the past decade, there has been a considerable increase in many recommendations, penetration testing reports, and automotive-speciﬁc security control mechanisms.

When it comes to safety-critical automotive applications, the intra-vehicle network security presents safety concerns if compromised. As a result, the thesis targeted security control mechanisms that target the intra-vehicle network, speciﬁcally the

CAN network. CAN has traditionally been a problematic network to secure due to its inherent lack of security. Many preemptive methods have attempted to use encryption, authentication, and secure communication protocols to increase security.

Other then preemptive methods, intrusion detection systems can detect attacks, and many CAN speciﬁc mechanisms exist. There are many types of IDS, but anomaly detection is the most elevated and uses information within network packets to detect intruders. There was a clear gap in using model-based methods for a CAN anomaly- based IDS. Model-based methods are useful as they provide a clear mathematical

94 understating of the performing of the security mechanism in contrast to learning methods.

There is also a lack of addressing some of the significant challenges of implementation on CAN, one of the most substantial difficulties being the performance impact of authentication. An unknown input observer is used to implement a dynamic monitor that detects attacks on CAN messages containing measurements and requires authentication when these messages are under attack. The UIO can achieve this by decoupling attacked inputs from the observation. The result is a security control mechanism that is model-based and can be used to authenticate CAN messages without burdening the network itself. The mechanism was then testing in a case study presented using a scenario involving an engine throttle control request made by an autonomous vehicle control unit. The results confirmed that the core foundation of the mechanism is in place and can detect stealth, covert, and replay attacks. Future work needs to focus on implementation, including how to make the system more robust, including cases where faults and noise are present. Future work also includes the design of the threshold for the residual, including filtering out noise in the residual measurement.

95 Appendix A: Engine Model

These are the constants used for the engine:

γ = 1.35 pamb = 101325P a Tamb = 302K

3 3 R = 288J/(kgK) VIM = 0.0058m Vd = 0.0024m (A.1)

J = 0.0789kgm3 Z = 4

Where γ is the Speciﬁc Heath Ratio, pamb is the ambient pressure, Tamb, is the ambient temperature, R is the gas constant, VIM is the manifold volume, Vd is the displacement volume, J is the moment of inertia of the crankshaft, and Z is the number of cylinders.

The following constants are used for the nonlinear crank angle domain model:

s γ+1 pamb √ 2 γ−1 Kthr = √ · γ · RTamb γ + 1 5 10 Vd RTamb KT = Kp1 = 4π VIM siVd yiVd (A.2) Kp2 = Kp3 = 4πVIM 4πVIM 302 30 K = d K = d fr1 π 2 fr2 π 1 4π K = d θ = fr3 0 d Z

Where d2 = 7.4198e − 7, d1 = −4.989e − 4, d0 = 11.3 are calibration terms and

si = 0.812, yi = 0.0633 are volumetric eﬃciency terms. The linear crank angle domain

96 model uses the following coeﬃcients:

2 K1 = Kp1Kthr(2a2α0 + a1) K2 = Kp1Kthr(a2α0 + a1α0 + a0) K3 = Kp2

2 Kp = KT b1(c2ϑ0 + c1ϑ0 + c0) Kϑ = KT (b1p0 − b0)(2c2ϑ0 + c1) (A.3)

2 Kf = 2Kfr1ω0 + Kfr2ω0

Where a2 = 1.69e − 7, a1 = −1.136e − 6, a0 = 6.89e − 6 are throttle calibration terms, b1 = 1.2323e − 4, b0 = 2.1256 are more calibration terms, and c2 = −0.0017, c1 =

−0.0277, c0 = 1.36 are the last set of calibration terms. p0, α0, ϑ0, ω0,Tload0,Tind0 are the operating points in which the linearization was conducted around. For the bilinear model the following constants where used: τdK3 τdK2 CT 1 = 1 + CT 3 = 2 2 2ω0 τdKf τdK3 CT 5 = 1 + 2 CT 2 = − 1 2Jω0 2 (A.4) τdK1 τdKf CT 4 = CT 6 = − 1 2ω0 2Jω0 τd CT 7 = 2Jω0

Where τd is the sampling rate in rad. The constants are used to construct the following matrices used in the bilinear discretized linear model:

" −C −C # " C # √ T 1 √ T 3 √T 4 0 τd τd τd M = −C N = C √ T 5 √T 7 0 τ 0 τ d d (A.5) " C C # " −C # √T 2 √T 3 √ T 4 0 τd τd τd O = C P = −C 0 √T 6 0 √ T 7 τd τd

97 Bibliography

[1] National vulnerability database: https://nvd.nist.gov/vuln/search.

[2] National Highway Traﬃc Safety Administration et al. Cybersecurity best practices for modern vehicles. Technical report, 2016.

[3] Ludovic Apvrille, Rachid El Khayari, Olaf Henniger, Yves Roudier, Hendrik Schweppe, Herv´eSeudi´e,Benjamin Weyl, and Marko Wolf. Secure automotive on-board electronics network architecture. In FISITA 2010 world automotive congress, Budapest, Hungary, volume 8, 2010.

[4] National Motor Freight Traﬃc Association. A survey of heavy vehicle cyber security. NMFTA Report, pages 1–73, 2015.

[5] AUTOSAR. Speciﬁcation of secure onboard communication, 2017.

[6] Elaine Barker and Allen Roginsky. Transitioning the use of cryptographic algorithms and key lengths. Technical report, National Institute of Standards and Technology, 2018.

[7] Giampaolo Bella, Pietro Biondi, Gianpiero Costantino, and Ilaria Matteucci. Toucan: A protocol to secure controller area network. In Proceedings of the ACM Workshop on Automotive Cybersecurity, pages 3–8, 2019.

[8] Zoleikha Abdollahi Biron, Pierluigi Pisu, and Baisravan HomChaudhuri. Ob- server design based cyber security for cyber physical systems. In Proceedings of the 10th Annual Cyber and Information Security Research Conference, pages 1–6, 2015.

[9] Mate Boban, Apostolos Kousaridas, Konstantinos Manolakis, Joseph Eichinger, and Wen Xu. Use cases, requirements, and design considerations for 5g v2x. arXiv preprint arXiv:1712.01754, 2017.

[10] Aymen Boudguiga, Witold Klaudel, Antoine Boulanger, and Pascal Chiron. A simple intrusion detection method for controller area network. In 2016 IEEE International Conference on Communications (ICC), pages 1–7. IEEE, 2016.

98 [11] David Brown, Geoﬀrey Cooper, Ian Gilvarry, Anand Rajan, Alan Tatourian, Ramnath Venugopalan, David Wheeler, and Meiyuan Zhao. Automotive security best practices. White Paper, pages 1–17, 2015.

[12] Alessandro Bruni, Michal Sojka, Flemming Nielson, and Hanne Riis Nielson. Formal security analysis of the macan protocol. In International Conference on Integrated Formal Methods, pages 241–255. Springer, 2014.

[13] Yelizaveta Burakova, Bill Hass, Leif Millar, and Andr´eWeimerskirch. Truck hacking: An experimental analysis of the {SAE} j1939 standard. In 10th {USENIX} Workshop on Oﬀensive Technologies ({WOOT} 16), 2016.

[14] Stephen Checkoway, Damon McCoy, Brian Kantor, Danny Anderson, Hovav Shacham, Stefan Savage, Karl Koscher, Alexei Czeskis, Franziska Roesner, Ta- dayoshi Kohno, et al. Comprehensive experimental analyses of automotive attack surfaces. In USENIX Security Symposium, volume 4, pages 447–462. San Fran- cisco, 2011.

[15] Jie Chen and Ron J Patton. Robust model-based fault diagnosis for dynamic systems, volume 3. Springer Science & Business Media, 2012.

[16] Michelle S Chong, Masashi Wakaiki, and Joao P Hespanha. Observability of linear systems under adversarial attacks. In 2015 American Control Conference (ACC), pages 2439–2444. IEEE, 2015.

[17] Seyed Mehran Dibaji, Mohammad Pirani, David Bezalel Flamholz, Anuradha M Annaswamy, Karl Henrik Johansson, and Aranya Chakrabortty. A systems and control perspective of cps security. Annual Reviews in Control, 2019.

[18] Jordi Dunj´o,Vasilis Fthenakis, Juan A V´ılchez, and Josep Arnaldos. Hazard and operability (hazop) analysis. a literature review. Journal of hazardous materials, 173(1-3):19–32, 2010.

[19] Morris Dworkin. Recommendation for block cipher modes of operation: the cmac mode for authentication. Technical report, National Institute of Standards and Technology, 2016.

[20] Mahmoud Hashem Eiza and Qiang Ni. Driving with sharks: Rethinking connected vehicles with vehicle cybersecurity. IEEE Vehicular Technology Magazine, 12(2):45–51, 2017.

[21] ENISA. Enisa good practices for security of smart cars. Technical report, ENISA, 2019, November.[Online]. Available: https://www.enisa.europa.eu/publications/smart-cars, 2019.

99 [22] U GAO. Vehicle cybersecurity. Technical report, GAO-16-350, 2016, March.[Online]. Available: https://www. gao. gov/assets . . . .

[23] Mario Gerla, Eun-Kyu Lee, Giovanni Pau, and Uichin Lee. Internet of vehicles: From intelligent grid to autonomous cars and vehicular clouds. In 2014 IEEE world forum on internet of things (WF-IoT), pages 241–246. IEEE, 2014.

[24] Andy Greenberg. The jeep hackers are back to prove car hacking can get much worse. Wired, Aug 2016.

[25] CO GRIMM. Cant. url= https://github. com/bitbane/CANT.

[26] Bharatkumar Hegde. Modeling of Vehicle Controller Area Network for Control Systems Simulation. PhD thesis, The Ohio State University, 2014.

[27] Tobias Hoppe, Stefan Kiltz, and Jana Dittmann. Applying intrusion detection to automotive it-early insights and remaining challenges. Journal of Information Assurance and Security (JIAS), 4(6):226–235, 2009.

[28] Steve Corrigan HPL. Introduction to the controller area network (can). Appl. Rep. SLOA101, pages 1–17, 2002.

[29] Road vehicles — Functional safety. Standard, International Organization for Standardization, Geneva, CH, December 2009.

[30] Information technology — Security techniques — Evaluation criteria for IT security. Standard, International Organization for Standardization, Geneva, CH, December 2009.

[31] Road vehicles — Safety of the intended functionality. Standard, International Organization for Standardization, Geneva, CH, January 2019.

[32] Shugang Jiang. Vehicle e/e architecture and its adaptation to new technical trends. Technical report, SAE Technical Paper, 2019.

[33] Philip Koopman and Michael Wagner. Autonomous vehicle safety: An interdis- ciplinary challenge. IEEE Intelligent Transportation Systems Magazine, 9(1):90– 96, 2017.

[34] Karl Koscher, Alexei Czeskis, Franziska Roesner, Shwetak Patel, Tadayoshi Kohno, Stephen Checkoway, Damon McCoy, Brian Kantor, Danny Anderson, Hovav Shacham, et al. Experimental security analysis of a modern automobile. In 2010 IEEE Symposium on Security and Privacy, pages 447–462. IEEE, 2010.

100 [35] Ryo Kurachi, Yutaka Matsubara, Hiroaki Takada, Naoki Adachi, Yukihiro Miyashita, and Satoshi Horihata. Cacan-centralized authentication system in can (controller area network). In 14th Int. Conf. on Embedded Security in Cars (ESCAR 2014), 2014.

[36] Chung-Wei Lin and Alberto Sangiovanni-Vincentelli. Cyber-security for the controller area network (can) communication protocol. In 2012 International Con- ference on Cyber Security, pages 1–7. IEEE, 2012.

[37] Yuxing Liu, Yue-Yun Wang, and Marcello Canova. Distributed model predictive control of an electrically boosted diesel engine air path system. In 2018 Annual American Control Conference (ACC), pages 2461–2466. IEEE, 2018.

[38] Yuxing Liu, Junqiang Zhou, Lisa Fiorentini, Marcello Canova, and Yue-Yun Wang. Model predictive control of a two-stage turbocharged diesel engine air- path system for rapid catalyst warm-up. In 2015 European Control Conference (ECC), pages 123–128. IEEE, 2015.

[39] Yuxing Liu, Junqiang Zhou, Lisa Fiorentini, Marcello Canova, and Yue-Yun Wang. Control of a two-stage turbocharged diesel engine air path system for mode transition via feedback linearization. In 2016 American Control Conference (ACC), pages 5105–5111. IEEE, 2016.

[40] Siti-Farhana Lokman, Abu Talib Othman, and Muhammad-Husaini Abu-Bakar. Intrusion detection system for automotive controller area network (can) bus system: a review. EURASIP Journal on Wireless Communications and Networking, 2019(1):184, 2019.

[41] Pratyusa K Manadhata and Jeannette M Wing. An attack surface metric. IEEE Transactions on Software Engineering, 37(3):371–386, 2010.

[42] Daniel Mellado, Eduardo Fern´andez-Medina,and Mario Piattini. A common criteria based security requirements engineering process for the development of secure information systems. Computer standards & interfaces, 29(2):244–253, 2007.

[43] Charlie Miller and Chris Valasek. A survey of remote automotive attack surfaces. black hat USA, 2014:94, 2014.

[44] Charlie Miller and Chris Valasek. Car hacking: for poories. Technical report, Tech. rep., IOActive Report, 2015.

[45] Yilin Mo and Bruno Sinopoli. Secure control against replay attacks. In 2009 47th Annual Allerton Conference on Communication, Control, and Computing (Allerton), pages 911–918. IEEE, 2009.

101 [46] Yilin Mo and Bruno Sinopoli. False data injection attacks in control systems. In Preprints of the 1st workshop on Secure Control Systems, pages 1–6, 2010.

[47] Philipp Mundhenk, Andrew Paverd, Artur Mrowca, Sebastian Steinhorst, Martin Lukasiewycz, Suhaib A Fahmy, and Samarjit Chakraborty. Security in automotive networks: Lightweight authentication and authorization. ACM Transactions on Design Automation of Electronic Systems (TODAES), 22(2):1–27, 2017.

[48] Michael M¨uter,Andr´eGroll, and Felix C Freiling. A structured approach to anomaly detection for in-vehicle networks. In 2010 Sixth International Confer- ence on Information Assurance and Security, pages 92–98. IEEE, 2010.

[49] Niap/ccevs. Niap home page: https://www.niap-ccevs.org/.

[50] Sen Nie, Ling Liu, and Yuefeng Du. Free-fall: Hacking tesla from wireless to can bus. Brieﬁng, Black Hat USA, pages 1–16, 2017.

[51] EVITA Home page: https://www.evita project.org/index.html.

[52] Simon Parkinson, Paul Ward, Kyle Wilson, and Jonathan Miller. Cyber threats facing autonomous and connected vehicles: Future challenges. IEEE transactions on intelligent transportation systems, 18(11):2898–2915, 2017.

[53] Fabio Pasqualetti, Florian Dörfler, and Francesco Bullo. Attack detection and identification in cyber-physical systems–part i: Models and fundamental limitations. arXiv preprint arXiv:1202.6144, 2012.

[54] Fabio Pasqualetti, Florian Dörfler, and Francesco Bullo. Attack detection and identification in cyber-physical systems. IEEE transactions on automatic control, 58(11):2715–2729, 2013.

[55] Fabio Pasqualetti, Florian Dorﬂer, and Francesco Bullo. Control-theoretic methods for cyberphysical security: Geometric principles for optimal cross-layer re- silient control systems. IEEE Control Systems Magazine, 35(1):110–127, 2015.

[56] Gabriel Pedroza, Ludovic Apvrille, and Daniel Knorreck. Avatar: A sysml environment for the formal veriﬁcation of safety and security properties. In 2011 11th Annual International Conference on New Technologies of Distributed Systems, pages 1–10. IEEE, 2011.

[57] Olaf Pfeiﬀer. Implementing scalable can security with cancrypt. Embedded Sys- tems Academy, 2017.

[58] Pat Richards. A can physical layer discussion. Microchip Technology Inc, 2002.

102 [59] Marc Rogers and Kevin Mahaﬀey. How to hack a tesla model s. DEF CON, 23:37–116, 2015.

[60] Serial Control and Communications Heavy Duty Vehicle Network. Standard, SAE International, August 2018.

[61] Andy Jackson Sayler. Securing secrets and managing trust in modern computing applications. 2016.

[62] Riccardo Scandariato, Kim Wuyts, and Wouter Joosen. A descriptive study of microsoft’s threat modeling technique. Requirements Engineering, 20(2):163–180, 2015.

[63] Hendrik Schweppe, Yves Roudier, Benjamin Weyl, Ludovic Apvrille, and Dirk Scheuermann. Car2x communication: securing the last meter-a cost-eﬀective approach for ensuring trust in car2x applications using in-vehicle symmetric cryptography. In 2011 IEEE Vehicular Technology Conference (VTC Fall), pages 1–5. IEEE, 2011.

[64] Craig Smith. The car hacker’s handbook: a guide for the penetration tester. no starch press, 2016.

[65] Diomidis H Stamatis. Failure mode and eﬀect analysis: FMEA from theory to execution. Quality Press, 2003.

[66] SAE Standard. Sae j1979: E/e diagnostic test modes. Vehicle EE Systems Diagnostics Standards Committee. SAE International, 2002.

[67] Sahra Svensson, Jessika Luth Richter, El´eonore Maitre-Ekern, Taina Pihla- jarinne, Aline Maigret, and Carl Dalhammar. The emerging ‘right to repair’legislation in the eu and the us. Proceedings from Going Green–Care In- novation, Vienna, 2018.

[68] US Army Training and Doctrine Command. The united states army’s cyberspace operations concept capability plan 2016–2028. US Army Training and Doctrine Command Pamphlet, pages 525–7, 2010.

[69] Kishor S Trivedi, Dong Seong Kim, Arpan Roy, and Deep Medhi. Dependability and security models. In 2009 7th International Workshop on Design of Reliable Communication Networks, pages 11–20. IEEE, 2009.

[70] Timo van Roermund and Andy Birnie. A multi-layer vehicle security framework. Whitepaper, May, pages 11–25, 2016.

103 [71] Peter Waszecki, Philipp Mundhenk, Sebastian Steinhorst, Martin Lukasiewycz, Ramesh Karri, and Samarjit Chakraborty. Automotive electrical and electronic architecture security via distributed in-vehicle traﬃc monitoring. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, 36(11):1790–1803, 2017.

[72] Marko Wolf and Timo Gendrullis. Design, implementation, and evaluation of a vehicular hardware security module. In International Conference on Information Security and Cryptology, pages 302–318. Springer, 2011.

[73] Marko Wolf, Andr´eWeimerskirch, and Christof Paar. Security in automotive bus systems. In Workshop on Embedded Security in Cars. Bochum, 2004.

[74] C. Young, J. Zambreno, H. Olufowobi, and G. Bloom. Survey of automotive controller area network intrusion detection systems. IEEE Design Test, 36(6):48– 55, Dec 2019.

[75] Wente Zeng and Mo-Yuen Chow. Optimal tradeoﬀ between performance and security in networked control systems based on coevolutionary algorithms. IEEE Transactions on Industrial Electronics, 59(7):3016–3025, 2011.

[76] Wente Zeng and Mo-Yuen Chow. A trade-oﬀ model for performance and security in secured networked control systems. In 2011 IEEE International Symposium on Industrial Electronics, pages 1997–2002. IEEE, 2011.

[77] Heng Zhang, Yuanchao Shu, Peng Cheng, and Jiming Chen. Privacy and performance trade-oﬀ in cyber-physical systems. IEEE Network, 30(2):62–66, 2016.

[78] Junqiang Zhou, Lisa Fiorentini, Marcello Canova, and Yue-Yun Wang. Coordi- nated performance optimization of a variable geometry compressor with model predictive control for a turbocharged diesel engine. IEEE Transactions on Con- trol Systems Technology, 24(3):804–816, 2015.

104