Securing Vehicle Electronic Control Unit (ECU) Communications and Stored Data

Home , Control unit, Electronic control unit

Md Swawibe Ul Alam

A thesis submitted to the School of Computing in conformity with the requirements for the degree of Master of Science

Queen’s University Kingston, Ontario, Canada September 2018

Nowadays, the automobile industry is integrating many new features into vehicles. To provide these features, various electronic systems are being added. These systems are coordinated by different ECUs (Electronic Control Unit). Vehicle ECUs are internally connected through multiple communication buses. Any ECU connected to the bus can read or send data to other ECUs. As a result, if an adversary can compromise one of the ECUs, then the adversary will be able to access and exploit data of other important ECUs. The absence of confidentiality is the main reason for that. Furthermore, the absence of data integrity and authenticity make the communications more vulnerable. In the past, it has been shown that an adversary can take control of the vehicle exploiting the inadequacy of CIA (Confidentiality, Integrity, and Authenticity). Moreover, an adversary can modify the stored data of an important ECU, if it is compromised. To solve these problems, we propose the use of symmetric key cryptography and elliptic curve-based Public Key Encryption (PKE) for ensuring confidentiality and the use of digital signature for ensuring integrity and authenticity. In addition, we propose the adoption of an identity-based access control in Mother ECUs (MECU, also known as a domain controller) to control the communication permissions. We also introduce Blockchain in vehicles to protect the stored data of ECUs. Finally, we integrate a watcher to monitor the stored data and report if it is

i modiﬁed. We implement the proposed technique in two platforms, namely Docker and the ARM architecture-based Raspberry Pi Board. Our experiments show that the proposed technique can improve security in ECU communications. The watcher reports when an ECU data is modiﬁed which helps limit the damage when an ECU is compromised.

ii Acknowledgements

I am grateful to my supervisor Professor Mohammad Zulkernine for his continu- ous support, guidance, patience, and motivation over the last two years at Queen’s University. Without his help, this thesis would not have been possible. I would also like to dedicate this thesis to my parents and sister for their encour- agement, unconditional love, inspiration, motivation, and wisdom through my entire life. Finally, I would like to thank Dr. Cliﬀord Liem for his guidance to my research during my internship and Dr. Shahrear Iqbal for his motivation during my experiments. I would also like to thank my colleagues at Queen’s Reliable Software Technol- ogy Group (QRST) especially to Karim Lounis who have been more than supportive during this eﬀort.

iii Contents

Abstracti

Acknowledgements iii

Contents iv

List of Figures vii

List of Tables ix

Chapter 1: Introduction1 1.1 Motivation...... 1 1.2 Problem Overview ...... 3 1.3 Overview of the Proposed Approach...... 5 1.4 Contributions...... 7 1.5 Organization of the Thesis...... 8

Chapter 2: Background and Related Work9 2.1 Electronic Control Unit (ECU) ...... 9 2.1.1 Mother ECU (MECU)...... 10 2.2 In-Vehicle E/E-Architecture...... 10 2.2.1 Current In-Vehicle E/E-Architecture ...... 10 2.2.2 Domain-Based In-Vehicle E/E-Architecture ...... 12 2.3 Cryptography...... 13 2.3.1 Symmetric Key Cryptography...... 13 2.3.2 Public Key Encryption (PKE)...... 14 2.3.3 Digital Signature...... 15 2.4 Identity-Based Access Control...... 15 2.5 Blockchain...... 16 2.5.1 The Use of Blockchain in Bitcoin ...... 16 2.6 Related Work...... 18 2.6.1 In-Vehicle Communication Security...... 18

iv 2.6.2 Use of Blockchain in Vehicles ...... 20 2.7 Summary ...... 23

Chapter 3: ECU Communications and Data Security 25 3.1 Proposed Approach Overview...... 25 3.2 Securing Vehicle ECU Communications...... 27 3.2.1 Structure of Lists...... 27 3.2.2 Secure Communications between ECUs...... 29 3.2.2.1 Data Transaction Structure between ECUs ...... 31 3.2.3 Secure Communications from an ECU to an MECU ...... 32 3.3 Securing the Stored Data...... 35 3.3.1 Storing Data in the Blockchain ...... 35 3.3.1.1 Data Transaction Structure from an MECU to the Leader...... 38 3.3.1.2 The Structure of Blocks...... 39 3.3.2 Data Monitoring by the Watcher ...... 40 3.3.3 Data Protection Without the Resource Consuming Algorithm 41 3.4 Major Challenges...... 42 3.4.1 Transferring Data...... 43 3.4.2 Choosing the Symmetric Key Cryptography...... 44 3.4.3 The Use of Public Key Encryption ...... 45 3.4.4 Choosing the Digital Signature ...... 45 3.4.5 Using Blockchain in Vehicles...... 46 3.4.5.1 Resource Consuming Consensus Algorithm ...... 46 3.4.5.2 Latency of Transactions...... 47 3.4.5.3 Transaction Throughput of the Blockchain ...... 48 3.4.5.4 Resource Scarcity...... 48 3.5 Summary ...... 49

Chapter 4: Implementation and Evaluation 50 4.1 Initialization of ECUs and MECUs ...... 50 4.1.1 ECU Credential Initialization ...... 51 4.1.2 MECU Credential Initialization...... 51 4.1.3 Watcher Credential Initialization ...... 52 4.2 Implementation on the Docker...... 52 4.2.1 Why Docker?...... 53 4.2.2 Experimental Setup...... 53 4.3 Implementation on the Raspberry Pi Board ...... 55 4.3.1 Why Raspberry Pi Board?...... 55 4.3.2 Experimental Setup...... 55

v 4.4 Security Experiments...... 57 4.4.1 Data Conﬁdentiality ...... 57 4.4.2 Data Integrity and Authenticity...... 58 4.4.3 Identity-Based Access Control...... 59 4.4.4 Security of the Stored Data ...... 61 4.5 Attack Protection Analysis...... 62 4.5.1 Protection from Data Stealing...... 63 4.5.2 Protection from Data Falsiﬁcation...... 63 4.5.3 Protection from Control Override...... 63 4.5.4 Protection from Vehicle Degradation ...... 64 4.5.5 Protection from Remote Access Threats ...... 64 4.6 Performance Evaluation ...... 65 4.6.1 End to End Delay on Docker ...... 66 4.6.2 End to End Delay on RPBs...... 66 4.6.3 Discussion of the End to End Delay...... 68 4.7 Summary ...... 69

Chapter 5: Conclusion and Future Work 70 5.1 Conclusion...... 70 5.2 Limitations ...... 71 5.3 Future Work...... 72

Bibliography 73

vi List of Figures

1.1 Overview of the proposed approach...... 7

2.1 In-vehicle E/E-architecture of BMW 7 series...... 11 2.2 Domain-based in-vehicle E/E-architecture...... 13 2.3 Basic structure of a Bitcoin block...... 17

3.1 The domain-based in-vehicle architecture after integrating the proposed approach...... 26 3.2 The process of securing communications between ECUs...... 29 3.3 The process of securing communications from an ECU to an MECU. 33 3.4 Data transaction structure from an ECU to an MECU...... 35 3.5 The process of storing data in the Blockchain...... 36 3.6 Data transaction structure from an MECU to the leader...... 38 3.7 The Structure of Blocks...... 40

4.1 Docker container setup...... 54 4.2 The experimental setup of RPBs...... 56 4.3 Unencrypted data transmit from ECU2 to ECU1...... 57 4.4 Encrypted data transmit from ECU2 to ECU1...... 58 4.5 ECU1 rejects ECU2’s data as the signature is not veriﬁed...... 59

vii 4.6 MECU1 rejects ECU3’s ‘Communication Request’...... 60 4.7 Watcher alert when a single block is compromised...... 61 4.8 Watcher alert when multiple blocks are compromised...... 62 4.9 Average end to end delay of data transfer on Docker...... 67 4.10 Average end to end delay of data transfer on RPBs...... 68

viii List of Tables

3.1 Request List...... 27 3.2 Permission List...... 28 3.3 State List...... 28 3.4 Data Transaction Structure between ECUs...... 31

4.1 Host Machine Speciﬁcation...... 54

ix 1

Chapter 1

Introduction

1.1 Motivation

Modern vehicles are not just a combination of engine, chassis, body, and wheels. They are equipped with many sensors and electronic devices to assist drivers. By 2020, around 35 percent of total manufacturing costs for vehicles will be for electronics [63]. The vehicle industry is expanding exponentially and more features are being added to vehicles for safe driving. Most of these features are integrated as an electronic system or subsystem. To coordinate these electronic systems, vehicle manufacturers introduced Electronic Control Units (ECU). An ECU takes inputs from sensors and computes data for its required task. Besides, one ECU can take inputs from another ECU to perform its tasks. This large number of ECUs’ communications create the in-vehicle network. Though the in-vehicle network was considered as an isolated network, for the past few years, this concept has changed. Today’s vehicles not only transport people but also provide entertainment and other services. For example, the telematics system (a sub-system of the communication system) is connected to the outside world through the Wireless Wide Area 1.1. MOTIVATION 2

Network (LTE, UMTS, EDGE, GPRS, etc.) or Wireless Local Area Network (Wi- Fi). Vehicles are using the telematics system to show maps, get the weather news, update software, make an emergency call, etc. In addition, the infotainment system enables electronic devices (e.g., mobile, tablet, smartwatch, and laptop) to connect to the vehicles, through the Wi-Fi or Bluetooth. Besides, some of these electronic devices can be paired with the vehicles, so that the devices can be operated from the vehicles. For instance, if a smartphone is paired with a vehicle, then the user of the vehicle can make a phone call from the vehicle’s display. All of these features did not appear without a price. The previously isolated in- vehicle network is now open to the outside world. It increases vehicle attack surfaces. In the last few years, various kinds of attacks have been demonstrated in vehicles. Some of those are described below: In the Jeep Hack, Miller and Valasek [33] found a vulnerability of the Uconnect platform [78]. This vulnerability gave them the entry point to compromise the vehicle. They rewrote the ﬁrmware and sent commands to the vehicle network. They were able to stop the vehicle from several miles away. After this demonstration, 1.4 million FCA (Fiat Chrysler Automobiles) US vehicles were recalled. The SmartGate system allows car owners to connect a smartphone to the car. Then the owner can check various information of the car. For example, the speed of the car, fuel status, average fuel consumption, and the next oil change date. Re- searchers showed that an adversary can easily connect to the car Wi-Fi and read all these information. Moreover, the adversary can lock out the car owner from the SmartGate system [46]. The ‘NissanConnect EV’ is a mobile application to check battery status, estimated 1.2. PROBLEM OVERVIEW 3

driving range, and the climate control system of the Nissan Leaf electric vehicle. A security researcher found a vulnerability of that mobile application and took control of the vehicle heater. Then the researcher was able to keep it on all the time to drain the vehicle battery. As a result, to protect the vehicles, Nissan disabled all the functions of its “NissanConnect EV” app [11]. In 2016, The Keen Security Lab at Tencent demonstrated the Tesla model S hack [26]. They deceived the Tesla driver to access a malicious website through a wiﬁ hotspot and then installed their own software to gain access to the Tesla’s features. They were able to control the braking system of the Tesla from twelve miles away. In the Netherlands, a group of thieves exploited the GPS system of the Tesla to track the vehicle and stole more than nine Teslas within a week [1]. All these exploitations directly or indirectly depend on vehicle ECU communications and data. Therefore, the ECU communications and data protection deserve special attention.

1.2 Problem Overview

Inside vehicles, any data is transported through communication buses. Many types of communication buses are used in current vehicles. For example, Controller Area Net- work (CAN), Local Interconnect Network (LIN), Media Oriented System Transport (MOST), Ethernet, and FlexRay have been widely used in vehicles. Among these communication buses, the mostly used CAN bus was released in 1986 [13]. Vehicle engineers at that time did not think much about conﬁdentiality, integrity, and authenticity of the data as vehicles were used only as a transportation medium. Therefore, any ECU or anyone who was connected to the communication bus could read or send 1.2. PROBLEM OVERVIEW 4

data to other ECUs. Even today’s vehicles follow the same concept. Vehicles may connect to different Internet-based services which increase the security risks. For example, GM’s OnStar, Toyota’s Safety Connect, and BMW’s BMW Assist provide access to vehicles from anywhere [17]. Besides, there are third party vehicle platforms that deliver entertainment, navigation, and communication features. The platform of the Uconnect [78] is now available into Chrysler, Dodge, Jeep, Ram, and FIAT. The owners of these vehicles can use a smartphone to start the engine and lock or unlock the vehicles. However, as we have discussed earlier, in the Jeep Hack, Miller and Valasek [33] exploited a vulnerability of the Uconnect and stopped the vehicle from several miles away. An absence of confidentiality (communication bus data are not encrypted), integrity (receiver ECU does not check whether the data is modified), and authenticity (receiver ECU does not check whether the data is from an authentic ECU) are primary reasons for this kind of attack. Another reason behind these attacks is the absence of an access control mechanism among ECUs. Currently, every ECU can communicate with other ECUs in the same bus. If one of the ECUs is compromised, then the compromised ECU can monitor other uncompromised ECUs. Therefore, it increases security risks. Furthermore, ECU data can be very important to insurance companies or law enforcement organizations for post-accident analysis. To analyze a post-accident scenario, an Event Data Recorder (EDR) is used. It records all important events in tamper-proof storage. These events can be a sudden speed increase, sudden brake, airbag deployment, etc. After an accident, insurance companies and law enforcement organizations use the EDR data to reconstruct the accident scene. However, the EDR data does not provide an extensive history and the data is overwritten due to limited 1.3. OVERVIEW OF THE PROPOSED APPROACH 5

storage [15]. As a result, data stored in ECUs can be used to analyze the post-accident scenario. For example, steering control ECU data, airbag control ECU data, braking system ECU data, and transmission control system ECU data can be used with the EDR. Besides, the collected data from ECUs can be helpful to investigate a driver’s driving behavior, driving pattern, driving speed, etc. [24]. These kinds of analytics are necessary for insurance companies to decide the insurance premium for the driver. To perform a correct analysis, the ECU data should be protected.

1.3 Overview of the Proposed Approach

Secure ECU communications can be achieved if the transferred data are confidential and the receiver ECU checks integrity and authenticity. The confidentiality of data ensures that only authorized ECUs will read the data. The integrity mechanism vali- dates whether the data is accurate and consistent. Finally, the authenticity property verifies whether the received data is from a reliable source. To secure vehicle communications, we propose to use symmetric key cryptography, elliptic curve-based PKE, and digital signature. The symmetric key cryptography provides confidentiality of the data. However, the key of the symmetric key cryptography needs to be shared secretly. Therefore, we use the PKE to exchange the key. The digital signature ensures integrity and authenticity of the data [10,38]. The elliptic curve-based PKE and digital signature provide faster computations, use less storage, and employ a shorter key [38]. Ensuring the security of the communications is not adequate to protect ECUs from a compromised ECU. An identity-based access control mechanism can help protect uncompromised ECUs from a compromised ECU. If the access control mechanism is 1.3. OVERVIEW OF THE PROPOSED APPROACH 6

integrated, then an ECU can communicate only with the permitted ECUs. There- fore, the compromised ECU cannot interact with ECUs which are not permitted. As a result, we propose the adoption of an identity-based access control mechanism to regulate ECU communications. If one of the ECUs needs to communicate with another ECU, then the first ECU makes a request to its MECU for a communication permission. The MECU checks the ‘Permission List’ and accepts or rejects the request. Finally, we propose the concept of Blockchain to protect the data stored in ECUs. Blockchain has been used in industries for its distributed structure, immutability, security, and privacy [2]. However, it can also be used for securing data [87]. In the proposed approach, MECUs hold the Blockchain. Besides, we propose to integrate a watcher in the in-vehicle network to monitor the stored data and generate an alert, if someone tries to modify it. Figure 1.1 shows an overview of the proposed approach. In the figure, the requester ECU sends communication permission request to the MECU for connecting to the requestee ECU. The MECU checks permission in the ‘Permission List’ and sends accept/reject notification to both ECUs. If the request is accepted, then the requestee ECU sends encrypted data to the requester, which assures confidentiality of the data. The requester ECU verifies the digital signature of the requestee ECU. The digital signature ensures the integrity of the data and authenticity of the requestee ECU. After a predefined time, every MECU collects data from its ECUs and sends the data to a leader MECU. A leader is elected among MECUs using a round-robin algorithm [82]. The leader creates a block with the data, verifies the block, and sends the block to other MECUs for their verification. After the verification, the block is 1.4. CONTRIBUTIONS 7

appended to the Blockchain. Furthermore, the watcher monitors the Blockchain and reports when any ECU data is inconsistent.

Leader MECU 6 6 Requester 1 7 5 ECU 6 3 7 7 4 MECU Watcher MECU 2 3 Requestee ECU 7

MECU

1. Requesting communication permission 5. Verifying integrity and authenticity 2. Checking permission 6. Generating block of the Blockchain 3. Notifying permission accept/reject 7. Monitoring ECU data 4. Sending encrypted data (confidentiality) o Blockchain

Figure 1.1: Overview of the proposed approach.

1.4 Contributions

In brief, the main contributions of this thesis are as follows:

• We propose a systematic way to use the symmetric key cryptography and elliptic curve-based PKE among ECUs to transfer data conﬁdentially.

• We propose a method to use the elliptic curve-based digital signature among ECUs to ensure data integrity and authenticity.

• We integrate an identity-based access control in MECUs to control ECU communications. 1.5. ORGANIZATION OF THE THESIS 8

• We implement a concept of Blockchain in MECUs to protect the stored data.

• We integrate a watcher in the in-vehicle network to monitor and report changes in the Blockchain.

1.5 Organization of the Thesis

The remainder of this thesis is organized as follows:

• In Chapter2, we discuss the background information regarding this work and introduce in-vehicle electrical/electronic-architecture. Then we summarize the related work on in-vehicle communication security and the usage of Blockchain in vehicles.

• Chapter3 begins by describing the proposed approach. Then, we present the major challenges of this work.

• In Chapter4, we present the implementation details. This is followed by the security experiments and some attacks that can be prevented after applying the proposed approach. Finally, we describe the performance evaluation of our experiments.

• Chapter5 concludes the thesis. Then, we discuss the limitations of this work and provide some potential future work. 9

Chapter 2

Background and Related Work

In this chapter, we discuss the background for the understanding of this work and the related work. At ﬁrst, we present a basic overview of electronic control units and in-vehicle electrical/electronic-architecture (E/E-architecture). Then, we explain the underlying principles of cryptographic algorithms used in this work. We also explore the principle of Blockchain. Finally, we provide an overview of the related work.

2.1 Electronic Control Unit (ECU)

An ECU is an embedded computer in vehicles to control mechanical or electronic systems or subsystems. It is an electronic component, which takes an input from its sensors or other ECUs and uses actuators to control functionalities of the vehicle. For example, the Anti-Lock Brake System (ABS) can take inputs from the Powertrain Control Module (PCM) to check whether the traction control is working. Modern vehicles contain many ECUs. Some important ECUs are Anti-Lock Brake System Module, Parking Aid Module, Powertrain Control Module, Audio Control Module, Front Display Module, Engine Control Module, Transmission Module, Skid Control Module, Airbag Control ECU, and Seat Belt Control ECU [79]. Most of these ECUs 2.2. IN-VEHICLE E/E-ARCHITECTURE 10

have some common parts, such as Microcontroller, SRAM (Static Random Access Memory), EEPROM (Electrically Erasable Programmable Read Only Memory), input for supply voltage, and a communication link to communicate with other ECUs or actuators.

2.1.1 Mother ECU (MECU)

An MECU is a special kind of ECU which has more resources (computation power, storage, RAM, etc.) than traditional ECUs. In the literature, it is also described as a domain controller or master ECU. It provides the communications among ECUs and interfaces to the gateway [48]. It can control its assigned bus system. For example, to save energy, it can allow partial bus operation or can deactivate an ECU. MECUs are more reliable than ECUs. As a result, applications which must be available during a vehicle operation are integrated into MECUs. It is also responsible to control the activities of its subordinate ECUs [65]. Besides all these features, in this work, MECUs hold the Blockchain and identity-based access control list.

2.2 In-Vehicle E/E-Architecture

In this section, we present current in-vehicle E/E-architecture and the domain based in-vehicle E/E-architecture.

2.2.1 Current In-Vehicle E/E-Architecture

Current high-end vehicles’ E/E-architecture is made up of around 70 ECUs with many buses. This large number of ECUs are installed into diﬀerent buses depending on application areas. Some of these buses are CAN, CAN-FD, LIN, MOST, FlexRay, 602.2. IN-VEHICLE E/E-ARCHITECTURE Electronic automotive systems 11

Diagnose

Gateway

K-CAN MOST K-CAN SI-BUS PT-CAN System Periphery (Byteflight)

Figure 2.1: 3.3: In-vehicle Network E/E-architecture infrastructure of of BMW BMW 7 series 7 series. [55].

Ethernet and all these buses are connected through a central gateway. The central gateway is a common gateway, which converts data from one bus format to another for different classes of subsystems. Only CAN and LIN networks are used, althoughbus format. the differences Moreover, the among gateway CAN directly networks handles are, inter-ECU for example, communications. their different As speedsa result, (100 the Kbps gateway and must 500 deal Kbps). with a For large chassis communication and powertrain load because systems, data among “CAN Antrieb” is used, and “CAN Komfort” is used for body and comfort systems. all the ECUs pass through the gateway. [48]. For multimedia/infotainment, “CAN Infotainment” is used. Figure 2.1 shows the in-vehicle E/E-architecture of BMW 7 series [55]. This 3.5.4architecture Subsystem contains diﬀerent integration types of data buses (e.g., K-CAN System, MOST, K- CAN Periphery, SI-BUS, PT-CAN) and multiple ECUs are installed in each data bus. The XC90 contains around 40 ECUs, the BMW 7 series has around 65, and theThe VW buses Passat are connectedhas around through 45. Also, the central other gateway. car models are known to have up to 70 ECUs. Integrating subsystems on the distributed automotive architecture is becoming more and more complicated. To overcome this, as one example in the case of the XC90, Volvo is using the Volcano concept 8 [11, 31, 171, 172]. The Volcano system provides tools for packaging data (signals) into network frames, both for CAN and LIN networks (more recent versions of Volcano also supports MOST and FlexRay [51] networks). This simpliﬁes the design, development and maintenance of the automotive system. Using the Volcano tools it is also possible to perform a timing analysis of the system, needed at

8The Volcano concept is developed by Volcano Communications Technologies AB, which in turn was Acquired by Mentor Graphics in May 2005. 2.2. IN-VEHICLE E/E-ARCHITECTURE 12

2.2.2 Domain-Based In-Vehicle E/E-Architecture

Today’s ECUs generate a great amount of data. For example, the data amount in infotainment related ECUs (audio/video, navigation, telephone, etc.) are increasing day by day. If the central gateway needs to handle this large amount of data, then it might become a hindrance to the in-vehicle communications. To reduce the load and the complexity of the central gateway, the domain-based E/E-architecture is proposed [3]. In this architecture, ECUs are grouped according to their functionalities (called domain) and placed in the same communication bus. Some examples of domains are powertrain, infotainment, chassis, and body [51]. Each domain is controlled by one domain controller that controls the activities of its ECUs and can deactivate ECUs to conserve energy when necessary [30]. In the domain-based E/E-architecture, all ECUs are clustered by their functionalities. Therefore, most of the data transfer among ECUs occurs within a domain. It reduces the data load in the central gateway. After considering the benefits of the domain-based E/E-architecture, we have decided to use this architecture in this work. We have modified the architecture for the proposed approach. The details are described in Section 3.1. Figure 2.2 shows the domain-based in-vehicle E/E-architecture [48]. In this architecture, different ECUs are grouped by their functionalities and each of the groups is controlled by a domain controller. All domain controllers are connected through the central gateway. 2.3. CRYPTOGRAPHY 13

Gateway

Domain Domain Domain Controller Controller Controller

ECU ECU ECU ECU ECU ECU

Figure 2.2: Domain-based in-vehicle E/E-architecture.

2.3 Cryptography 1

We use a few cryptographic algorithms in this work. In this section, we explain the underlying principles of those algorithms.

2.3.1 Symmetric Key Cryptography

Symmetric Key Cryptography is used to send data securely. It provides data encryption and decryption methods. In symmetric key cryptography, the same key is used for the encryption and decryption of the data. Both sender and receiver have the same key. The steps of symmetric key cryptography are as follows: Initially, one of the parties (sender/receiver) generates a symmetric key. Then the key is sent to the other party securely. The sender encrypts the data using the symmetric key and 2.3. CRYPTOGRAPHY 14

sends it to the receiver. The receiver can decrypt the data with the same symmetric key. Symmetric key cryptography provides conﬁdentiality, as only the legitimate receiver with the legitimate key can decrypt the data (as long as the key remains secret to both of them). Some symmetric key algorithms are AES [71], TWINE [73], Simon [4], Speck [4], PRESENT [12], Salsa20 [8], and Chacha20 [7]. However, we adopt Chacha20 for a few reasons and those are described in Section 3.4.2.

2.3.2 Public Key Encryption (PKE)

The PKE is also used to send data confidentially. However, the PKE uses asymmetric cryptography, which means different keys are used for the encryption and decryption. In asymmetric cryptography, a pair of keys is used where each are mathematically linked. One of these keys is the private key and the other one is the public key. The private key is securely stored in the receiver system and the public key is sent to all sender systems. The steps of the PKE are as follows: The receiver generates the key pair. A trusted Certificate Authority (CA) verifies the public key of the receiver and sends it to the sender. The sender uses the public key of the receiver to encrypt the data and sends it to the receiver. The receiver decrypts the data with the private key. As the data is encrypted by the receiver’s public key, only the receiver’s private key can decrypt it. Hence, the PKE provides the confidentiality, as only the legitimate receiver can read the data. Some PKE algorithms are RSA [67], ElGamal [27], and ECIES [47]. We apply ECIES in this work and the reasons for applying ECIES are explained in Section 3.4.3. 2.4. IDENTITY-BASED ACCESS CONTROL 15

2.3.3 Digital Signature

The digital signature ensures that the received data is not altered, and the sender of the data is authentic [38]. It provides the data integrity and authenticity. The steps of the digital signature are as follows: The sender of the data makes a hash of the data with a known hashing algorithm and encrypts the hash with a private key. This is called the signature. Then the sender sends the data and the signature to the receiver. The receiver has the public key of the sender. The receiver decrypts the signature with the sender’s public key and creates a hash of the sent data. If the decrypted hash and the newly created hash of the data are equal, then the integrity and authenticity of the data are veriﬁed. Throughout this thesis, the word verify denotes the checking of integrity and authenticity of the data or transactions. Some digital signatures are RSA [67], ECDSA [39], and Ed25519 [9]. However, we use Ed25519 and the reasons for using the Ed25519 are detailed in Section 3.4.4.

2.4 Identity-Based Access Control

The identity-based access control mechanism gives the permission to access resources or services based on a requester’s identity [86]. All identities are stored in a secure data structure. In this work, we call it a ‘Permission List’. A requester can get access to resources or services when a permission is granted in the ‘Permission List’. In the ‘Permission List’, requester’s id and permissions are added by the administrator. The communication protocol follows the ‘Permission List’ to control the communications among users. For example, we can conﬁgure the ‘Permission List’ in a way so that user A is permitted to communicate with user B but not with user C. Therefore, if user A wants to communicate with user C, then the communication request will be 2.5. BLOCKCHAIN 16

rejected as user A is not permitted to communicate with user C.

2.5 Blockchain

Blockchain is a special kind of Distributed Ledger. Distributed Ledger Technology gives us an opportunity to keep our data in distributed locations, where validation and updating of data are done by a consensus-based protocol and integrity is checked through a cryptographic signature [5]. To make it transparent, every node keeps the same copy of the data. A leader or a master node replicates the data to all followers or slave nodes. In Blockchain, every block contains multiple chronological transactions and the reference to the earlier block. Here, the reference is a hash of the earlier block. Blockchain uses a consensus algorithm for the validation of data. Once the data is written in Blockchain, it becomes immutable. In Blockchain, every block is chained to its previous block. Hence, changing one block requires changing all the suc- ceeding blocks. Blockchain technology is used in the cryptocurrency (Bitcoin [52]), in a distributed and scalable database (BigchainDB [49]), in executing a contract (Ethereum [84]), and in various other ﬁelds. More and more sectors are adopting Blockchain for its distributed structure, immutability, security, and privacy [2, 50]. We use Blockchain in MECUs and the use of the Blockchain in this work are explained in Section 3.4.5.

2.5.1 The Use of Blockchain in Bitcoin

Bitcoin is one of the most widely used applications of Blockchain. In this section, we brieﬂy describe the concept of Blockchain of Bitcoin. 2.5. BLOCKCHAIN 17

Genesis block block block Most recent block Block Number …1010 …1011 …1011 Proof of Work 4d6f2d826c… 39aa881c71… 4a8c2a075b… Hash of Previous Block 725b46c115… 96773e9264… 1b16d15ffa… Hash of Current Block 96773e9264… 7aed15b687… 397d713c82… Transactions Transactions Transactions Transactions

Figure 2.3: Basic structure of a Bitcoin block.

In Bitcoin, every block contains multiple chronologically sorted transactions, a reference to the previous block, and the proof of the block. Figure 2.3 shows the basic structure of Bitcoin block. In the block, the proof is a result of a computationally hard mathematical puzzle. This puzzle is hard to solve but easy to verify. It is called the proof of work (PoW) [52]. To generate a block, all transactions are sent to all miners. Every miner gathers recent transactions. Then, the miners try to solve the PoW. Whoever solves the PoW ﬁrst, it broadcasts the result to the network. Later, other miners verify the validity of the result. If most of the miners agree on the validity of the result, then the block is appended to the Blockchain and all miners update their Blockchain. This process where multiple miners come to a mutual decision is called the consensus algorithm. The consensus algorithm is very resource consuming [85]. The security of Bitcoin network depends on the consensus protocol which is based on the PoW. As the Bitcoin network is public, anyone can join the network. Moreover, the identity of the user is anonymous. Therefore, an adversary can join the network anonymously and may try to alter transactions. If an adversary tries to change any of the transactions, then the adversary needs to regenerate all the successor blocks and redo all computations those were done by the successor blocks. Redoing all the previous computations takes a long time and needs a large amount of computational 2.6. RELATED WORK 18

power. As a result, it is not feasible to tamper the stored data. Hence, the PoW is making the data immutable.

2.6 Related Work

In this section, the overview of the related work is presented into two parts. The ﬁrst part is on in-vehicle communication security (ECU communication security) and the second part is on protecting ECU data by using Blockchain.

2.6.1 In-Vehicle Communication Security

There are many works related to in-vehicle communication security. However, we focus on the related work which use either the concept of cryptography or MECU (domain controller/master ECU). Chavez et al. [16] propose to integrate three (confidentiality, integrity, and access control) out of five security services of the OSI model in vehicle communications. The authors suggest to apply the RC4 stream cipher for confidentiality and the hash algorithm for data integrity. They also propose to implement the access control mechanism at a higher layer (e.g., application layer). Nilsson et al. [53] propose to use a Message Authentication Code (MAC) to provide authentication and integrity in the communications. In their method, 64 bit MAC is calculated from four successive CAN messages. Then the MAC is divided into four blocks and sent in the next four subsequent CAN messages. Oguma et al. [59] propose an attestation-based in-vehicle communication security. In their work, they propose to have a master ECU in vehicles. The master ECU contains hash values, which are used to verify the ECUs. Each time the vehicle 2.6. RELATED WORK 19

starts, the master ECU verifies other ECUs using the hash values. They also apply the Key Predistribution System (PKS) instead of the PKI. They assume that every ECU will have a Trusted Platform Module (TPM). The TPM is a tamper-free security chip. It might increase the cost of the vehicles if vehicle manufacturers need to install TPM in every ECU. Groll and Ruland [34] propose to make a trusted group among ECUs. The central gateway can work as a key distribution center (KDC). The KDC generates symmetric keys and sends it to every group. The symmetric key is used to communicate with the group ECUs. Every ECU has one Access Control List (ACL). The members of the group are defined in the ACL. Their approach is similar to our work in the following ways: 1) We also group ECUs depending on functionalities. 2) We use symmetric keys among group members for data exchange. However, this work is different from their work in the following ways: 1) Instead of using a single KDC for the key distribution, we use multiple MECUs. An MECU distributes symmetric keys among its dependent ECUs. 2) Though we use ACLs (‘Permission List’) in this work, it is used for the access control mechanism. Moreover, in our work, only MECUs can contain the ACL, while in their work, every ECU has the ACL for making a group. Wolf et al. [83] propose three practices to achieve in-vehicle communication security. 1) Authentication mechanism by the gateway: the gateway verifies every controller (MECU) by a public key certificate issued by the manufacturer. The gateway manages encryption keys for the encryption in sub-networks. 2) Encrypted communications: ECU communications are encrypted using a combination of asymmetric and symmetric encryption. They use the symmetric encryption for data broadcasting and asymmetric encryption for a secure key distribution. 3) Firewall in the Gateway: 2.6. RELATED WORK 20

The firewall works on controllers’ certificates. When a controller tries to send data through the gateway, the gateway checks the validity of the controller’s certificate. If the certificate is valid, then the data of the controller are allowed to pass. Their approach is similar to our work in the following ways: 1) The central gateway verifies every MECU using the public key certificate. 2) ECU communications are encrypted using a combination of asymmetric and symmetric encryption. However, the proposed approach is different from their work in the following ways: 1) In their work, a single central gateway manages encryption keys for the encryption in sub-networks. The gateway deals with large communication loads and it can be a single point of failure. In this work, multiple MECUs manage encryption keys and handle inter- domain communications. Moreover, multiple MECUs protect from a single point of failure. 2) They propose to use a firewall in the gateway. The function of their firewall is to check the validity of the controllers. However, in the proposed approach, we integrate an identity-based access control mechanism in MECUs which manages communication permissions. 3) In their work, the same encryption key is used in the whole sub-network. In this work, every ECU pair uses a different symmetric key for the data encryption. As a result, the compromise of a single ECU will not affect other ECUs’ confidentiality.

2.6.2 Use of Blockchain in Vehicles

Blockchain is being used in various industries for its tamper-proof ability, trans- parency, and availability. It is also used in the vehicle industry. In this section, we describe some related work which uses Blockchain in vehicles. Benjamin et al. [44] propose Blockchain-based vehicular ad hoc network (VANET). 2.6. RELATED WORK 21

In their work, they propose to use Ethereum’s smart contract for traﬃc regulation, vehicle tax, and vehicle insurance. Kim et al. [41] propose Blockchain-based mobile charger billing system for electric cars. They also propose a lightweight Blockchain scheme to reduce the size of the Blockchain data. In their work, they use Blockchain to transfer data from vehicles to infrastructure (V2I). Singh and Kim [70] propose a reward-based intelligent vehicle to vehicle communications using Blockchain. Their main idea is to share the data among intelligent vehicles by implementing Blockchain-based trust environment. Initially, they transmit vehicles data in the cloud. These data can be used for various purposes. For example, if someone wants to buy an old car, then the buyer can check the car’s accident history, condition, criminal history, etc. They use Blockchain for the vehicle to vehicle (V2V) communications. Dorri et al. [24] propose Blockchain-based architecture among smart vehicles, smart homes, and smart devices. Their idea is to use Blockchain to protect data. They propose an architecture where smart vehicles and smart devices are connected to a smart home. Every smart home is connected to the cloud, service provider or another smart home. The data transfer between smart vehicles, smart home, and other entities use Blockchain. They also propose a new Blockchain consensus algorithm for lightweight devices [23]. They show some use cases of their architecture. For example, they show how the Blockchain-based architecture can help in the remote software update, car-sharing services, and an electric vehicle’s charging services. They use Blockchain in the V2I and V2V communications. 2.6. RELATED WORK 22

In 2018, Cebe et al. [15] propose Blockchain-based framework to manage vehicle- related data. Their concept is to collect vehicle data from all parties, such as drivers, maintenance centers, car manufacturers, and law enforcement agencies. All these parties upload the data to the cloud. When the data will be needed, these data will be disclosed to the authorized parties for investigation. Every party is regarded as a single data source of the Blockchain. When all parties upload their data, the data are sent to the leader. The leader can be any party among maintenance centers, car manufacturers, or an insurance company. Then the leader creates a block, verifies it, and appends to the Blockchain. On the contrary, in our proposed approach, Blockchain is kept by MECUs. Every MECU is one of the data sources of the Blockchain. Any of the MECUs can be a leader. The leader MECU creates a block, verifies it, and appends it to the Blockchain. In their work, they use Blockchain to provide the integrity and privacy of the data among different parties (drivers, maintenance centers, car manufacturers, law enforcement agencies, etc.), while we use Blockchain to protect ECU data inside vehicles. Liem et al. [45] propose a runtime self-protection and integrity verification of ECUs using a permissioned distributed ledger with other tools. To protect the code of an ECU, they suggest the use of run-time self-protection, white box cryptography (hiding keys at runtime), program transformation (anti-reversing), diversity of the program, and OS-level secure environment. They propose to use distributed ledger for providing the integrity of the data. They use the distributed ledger in every ECU. Besides, they propose the use of a watcher. The watcher ECU monitors the distributed ledger. If any of the ECU data is compromised, then the watcher generates an alert. They use etcd [20] to simulate the distributed ledger. etcd is a distributed key-value store that 2.7. SUMMARY 23

replicates data in multiple machines for reliability. In their experiments, they install the etcd and other tools in Wandboards and in R-Car M2/M3 boards. They also simulate some attacks to show the scenarios of integrity compromise. Their approach is similar to this work in the following ways: 1) Blockchain (distributed ledger) is used to provide the integrity of the data. 2) A watcher monitors the integrity of the data. 3) The ARM architecture-based board is employed as an ECU. On the contrary, the proposed approach is diﬀerent from their work in the following ways: 1) We are not using Blockchain in each ECU, as the Blockchain is resource consuming. Instead, we use Blockchain in MECUs. 2) In both works, a watcher monitors the integrity of the data, however, in the proposed approach, the watcher only monitors few MECUs instead of monitoring hundreds of ECUs. 3) In our work, we implement an identity-based access control mechanism, which is not present in their work.

2.7 Summary

In this chapter, some important background information is explained before proceed- ing to the proposed approach. We briefly discuss current in-vehicle E/E-architecture and domain-based in-vehicle E/E-architecture. Today’s ECUs are generating a high amount of data, therefore, the current in-vehicle E/E-architecture is being replaced by the domain-based in-vehicle E/E-architecture. Besides, we shortly explain the underlying principles of cryptographic algorithms used in this work. We also explore the principle of Blockchain to use it as a secure data storage. Finally, we compare and contrast our work with the related work. We find very few works, where both the CIA and an access control mechanism are provided. We also find that in most cases, Blockchain is used to transfer data securely in V2V or V2I communications, 2.7. SUMMARY 24

while we use Blockchain to protect ECU data. 25

Chapter 3

ECU Communications and Data Security

In this chapter, at ﬁrst, we describe the overview of the proposed approach. Then, we explain the process of securing ECU communications and the stored data. Finally, we explain the main challenges of this work.

3.1 Proposed Approach Overview

In this work, we use the domain-based in-vehicle architecture. In the domain-based architecture, ECUs are grouped by their functionalities and placed in the same communication bus (called a domain). Every domain is controlled by a controller, which is called an MECU (domain controller). In this architecture, every ECU collects data from its sensors, processes the data, takes a decision, and works on that decision or sends the processed data to other ECUs. MECUs are connected through the gateway. An MECU can send data to other MECUs through the gateway. Figure 3.1 shows the domain-based in-vehicle architecture after integrating the proposed approach. In our approach, we propose to transmit encrypted and digitally signed data. As a result, every ECU sends encrypted data with a signature. This signed encrypted communication ensures conﬁdentiality, integrity, and authenticity. 3.1. PROPOSED APPROACH OVERVIEW 26

Gateway WATCHER Watches MECUs’ Watcher data consistency

MECU . Provides access control . Fetches data from ECUs MECU MECU . Holds the Blockchain ECU MECU . Collects data from sensors ECU ECU ECU ECU ECU ECU . Encrypts and signs the data before sending ECU ECU ECU ECU ECU to the MECU ECU or ECUs ECU ECU ECU ECU ECU ECU

ECU ECU ECU ECU ECU ECU

Figure 3.1: The domain-based in-vehicle architecture after integrating the proposed approach. It also shows an ECU, MECU, and the watcher tasks.

2 Besides, we propose to integrate an access control mechanism in MECUs. When one of the ECUs wants to communicate with another ECU, the ﬁrst ECU needs a permission from its MECU. Furthermore, the MECUs fetch data (ECU data) from its ECUs. The ECU data are stored in MECUs in Blockchain. Every MECU keeps the same copy of the Blockchain. However, the data of the Blockchain is encrypted. As a result, if one of the MECUs is compromised, then the compromised MECU cannot read other MECUs’ ECU data. Finally, to monitor the MECUs’ data consistency, we integrate a watcher in the in-vehicle network. The watcher is directly connected to the MECUs. Therefore, the watcher can monitor the data consistency of MECUs. In the proposed approach, all communications are transmitted through an Ethernet bus. 3.2. SECURING VEHICLE ECU COMMUNICATIONS 27

3.2 Securing Vehicle ECU Communications

In this section, we discuss the process of securing communications between ECUs and from an ECU to an MECU. In addition, the structure of the data transaction is illustrated after each process.

3.2.1 Structure of Lists

In the process of securing communications, we use a number of lists namely ‘Request List’, ‘Permission List’, and ‘State List’. In the following, we describe those and the reasons for their usage. Request List. Each ECU contains a ‘Request List’. When an ECU receives another ECU’s information from an MECU, the ECU stores all information in the ‘Request List’. Table 3.1 shows ECU ‘Request List’. This list stores requester/requestee ECU UID, public veriﬁcation key, and the common shared key between requester and requestee.

Table 3.1: Request List.

Public Veriﬁcation Common Shared ECU UID Key (256 bit) Key (256 bit) 10001000 b556eb8798. . . 9a5c75b18. . . 10001110 c7f8546c57. . . d7c3c06a68. . . 10001101 7aa6949f72. . . 576320c7c0......

Permission List. MECUs contain an ECU ‘Permission List’. This list imple- ments the identity-based access control of ECUs. Every time an ECU wants permission to communicate with another ECU, an MECU checks the ‘Permission List’. If 3.2. SECURING VEHICLE ECU COMMUNICATIONS 28

the requester ECU is permitted (Y) to communicate, then the MECU grants access, otherwise it is rejected (N). Table 3.2 shows ECU ‘Permission List’. There are four attributes in this list. These attributes are requester ECU UID, requestee ECU’s MECU UID, requestee ECU UID, and communication permission.

Table 3.2: Permission List.

Requester Requestee ECU’s Requestee Communication ECU UID MECU UID ECU UID Permission 10001000 1001 10001011 Y 10001001 1010 10001011 N ......

State List. MECUs hold an ECU ‘State List’. This list stores ECUs’ states. The states of ECUs are Ready, Active, and Disabled. When an ECU is installed in the communication bus it is in the Ready state. When an MECU veriﬁes the ECU, the state becomes Active. If an ECU is not working, then the state is Disabled. Table 3.3 shows ECU ‘State List’.

Table 3.3: State List.

ECU State ECU UID (Disabled/Ready/Active) 10001000 Active 10001110 Disabled 10001101 Ready ...... 3.2. SECURINGSecure Communications VEHICLE ECU COMMUNICATIONS and Data Transfer 29 between ECUs

MECU1

ECU1 ECU2

1 ECU1 sends communication request to MECU1 2 Checks Permission List & generates common shared key

3 MECU1 sends notification 4 Decrypts common shared with details of ECU1 and key & stores ECU1’s details in 5 MECU1 sends request accepted encrypted common shared the Request List 6 Decrypts common notification with details of ECU2 key shared key & stores and encrypted common shared ECU2’s details in the key Request List 7 ECU1 sends data request to ECU2 8 Checks ECU1’s entry in the Request list

9 ECU2 Sends encrypted data with the common 10 Decrypts the data shared key using the symmetric key encryption

Figure 3.2: The process of securing communications between ECUs.

3.2.2 Secure Communications between ECUs

If an ECU is in ‘Active’ state, then it can request data from other ECUs. However, before making the data request, the requester ECU needs to get permission from an MECU. For example, ECU1 is a requester and ECU2 is a requestee. Both of them are connected under MECU1. Figure 3.2 shows the process of securing communications between ECU1 and ECU2. All communications are transmitted with a digital signature. However, signing and veriﬁcation of the digital signature are not depicted in the ﬁgure. Now, if ECU1 wants data from ECU2, then the following steps are executed:

1. ECU1 sends a ‘Communication Request’ to MECU1 with its digital signature.

2. MECU1 veriﬁes the signature of ECU1 and checks ‘Permission List’. If ECU1 is permitted to communicate with ECU2, then MECU1 generates a common shared key for both ECU1 and ECU2. This common shared key is valid for 3.2. SECURING VEHICLE ECU COMMUNICATIONS 30

the next N number of transactions (or next T seconds). After N number of transactions, ECU1 needs to generate another ‘Communication Request’ to MECU1 for a new key.

3. MECU1 sends a notification to ECU2 with its digital signature. The notification contains the public verification key of ECU1 (to verify the digital signature of ECU1), UID of ECU1, and encrypted common shared key. Only the common shared key is encrypted using the public encryption key of ECU2.

4. After getting the notification from MECU1, ECU2 verifies the signature of MECU1. If the signature is verified, then ECU2 decrypts the common shared key and stores the public verification key, UID, and common shared key in the ‘Request List’.

5. MECU1 also sends a ‘Communication Request Accepted’ notification to ECU1 with its digital signature. The notification contains the public verification key of ECU2 (to verify the digital signature of ECU2), UID of ECU2, and encrypted common shared key.

6. After getting the ‘Communication Request Accepted’ notification, ECU1 verifies the signature of MECU1. If the signature is verified, then ECU1 decrypts the common shared key. Then ECU1 stores the public verification key, UID, and the common shared key of ECU2 in the ‘Request List’.

7. ECU1 sends the data request to ECU2 with its digital signature.

8. ECU2 veriﬁes the signature of ECU1. If the signature is veriﬁed, then ECU2 checks the entry of ECU1 in its ‘Request List’. Then ECU2 encrypts the data 3.2. SECURING VEHICLE ECU COMMUNICATIONS 31

with the shared key using the symmetric key encryption.

9. The encrypted data is sent to ECU1 with ECU2’s digital signature. The format of the data transaction between ECUs is described in Section 3.2.2.1.

10. After receiving the data, ECU1 veriﬁes the digital signature of ECU2. If the signature is veriﬁed, ECU1 decrypts the data with the common shared key. Only ECU1 can decrypt the data, as the common shared key is shared only between ECU1 and ECU2.

3.2.2.1 Data Transaction Structure between ECUs

When an ECU sends the data request to another ECU, the requestee ECU checks the ‘Request List’. If there is an entry for the requester ECU, then the requestee ECU sends data. Table 3.4 shows the data transaction structure between ECUs. The transaction contains following fields: Transaction Number, Requester ECU UID, Requestee ECU UID, Sensor ID, Encrypted Data, and Requestee Signature. Every requestee ECU may be connected with multiple sensors. Therefore, the requester ECU might request for a specific sensor’s data. The Sensor ID field contains a sensor’s identification number. The next field contains the encrypted data and the last field is the Requestee Signature.

Table 3.4: Data Transaction Structure between ECUs.

Requester Requestee Requestee Tx. No Sensor ID Encrypted Data ECU UID ECU UID Signature 1000. . . 10001000 10001011 1100. . . dc84bc1329. . . fc55115dd5. . . 3.2. SECURING VEHICLE ECU COMMUNICATIONS 32

3.2.3 Secure Communications from an ECU to an MECU

An ECU has a very small amount of storage. As a result, ECUs need to transfer data to its MECU. However, it might not be feasible to store all ECUs’ data. It depends on vehicle engineers whether one of the ECUs data should be stored or not. In this work, we assume that all ECUs’ data are stored in MECUs. To process ECU data, every MECU requests to all its ECUs to send data after a predefined time. This time depends on the block generation time. For example, if a block is generated after every T seconds, an MECU requests to all its ECUs to send data within this time. Figure 3.3 shows the process of securing communications from an ECU to an MECU. All communications are transmitted with a digital signature. However, the signing and the verification of the digital signature are not depicted in the figure. The following steps are executed when an MECU requests for data to one of its ECUs:

1. An MECU sends a ‘Send Data’ request to an ECU with its digital signature.

2. The ECU veriﬁes the signature. If the ECU is not busy and it has new data to send, then the ECU sends a transfer acknowledgment.

3. The MECU sends the last successful data transaction number from its Blockchain with a digital signature.

4. The ECU verifies the digital signature of the MECU. After the verification, the ECU creates a data transaction. This transaction contains the data which are generated after the last successful data transaction. The data is encrypted with the symmetric key encryption. The shared symmetric key is generated from the MECU’s public key and the ECU’s private key [56]. Among all fields, only the data field is encrypted to reduce space and time. Secure Communications and Data

3.2.Transfer SECURING VEHICLE from ECU an COMMUNICATIONS ECU to an MECU 33

ECU MECU

1 MECU sends a `Send Data’ request

2 ECU sends transfer acknowledgement

4 Creates a 3 MECU sends the last successful data transaction transaction number from the with Encrypted Blockchain data 5 ECU sends the encrypted data 6 Processes transaction the data transaction 7 MECU sends a `Data Received’ acknowledgment 8 ECU releases its storage

Figure 3.3: The process of securing communications from an ECU to an MECU.

5. The ECU sends the data transaction to the MECU with the encrypted data and digital signature. The format of the data transaction structure from an ECU to an MECU is described in the next Section.

6. After receiving the data, the MECU veriﬁes the digital signature of the ECU. If the signature is veriﬁed, the MECU processes the data transaction.

7. The MECU sends a ‘Data Received’ acknowledgment to the ECU with its digital signature.

8. The ECU veriﬁes the acknowledgment of the MECU. After the veriﬁcation, the ECU releases its storage for the future use. 3.2. SECURING VEHICLE ECU COMMUNICATIONS 34

Data Transaction Structure from an ECU to an MECU

An ECU sends data to its MECU to store it. However, an ECU may have multiple sensors. Every sensor may generate hundreds of data in a second. If we use a single transaction to transfer a single data, then this process will consume significant bandwidth. Moreover, all transactions are digitally signed. As a result, if an ECU has s number of sensors and each of the sensors generates n number of data, then the MECU needs to verify s*n number of transactions from a single ECU. To solve this problem, an ECU sends a single ECU transaction instead of s*n number of transactions to its MECU. Each ECU transaction contains s*n number of requester ECU UID, sensor ID, encrypted data, and data generation time. Further- more, multiple ECUs can request for data to a single ECU. Therefore, a requestee ECU needs to store UIDs of all requester ECUs (Requester ECU UID). The encrypted data field holds the encrypted data. The data generation time contains the generation time of the data. Figure 3.4 shows data transactions structure from an ECU to an MECU. This transaction contains the following fields: Transaction Number, MECU UID, Reques- tee ECU UID, Requester ECU UID, Sensor ID, Encrypted Data, Data Generation Time, Last Data Generation Time, and ECU Signature. Every transaction contains the last data generation time which holds the largest time of all data generation time of a transaction. The last data generation time of a newer transaction is larger than the earlier transaction’s last data generation time. 3.3. SECURING THE STORED DATA 35

Requestee Requester Encrypted Data Generation Last Data ECU Tx. No MECU UID Sensor ID ECU UID ECU UID Data Time Generation Time Signature 10001110 1011 ab8f21ebdd… 1529938741.12 10001111 1101 65f8037786… 1529938783.34 1001… 1001 10001000 1529938802.31 98e9699d…

10001110 1011 30c78520e4… 1529938802.31

Figure 3.4: Data transaction structure (ECU transaction) from an ECU to an MECU.

3.3 Securing the Stored Data

In this section, we discuss the process of storing data in the Blockchain and watcher data monitoring in detail. In the process of storing data in the Blockchain, an MECU sends data to the leader and the leader creates a block. Therefore, we explain the data transaction structure from an MECU to the leader and the structure of blocks after the process of storing data in the Blockchain.

3.3.1 Storing Data in the Blockchain

The generation of Blockchain can be resource consuming. Therefore, instead of using Blockchain in ECUs, we use it in MECUs. MECUs are more capable than ECUs. Every MECU manages multiple ECUs. As we have discussed earlier, an MECU sends the ‘Send Data’ request to its ECUs to send data. Each ECU collects data from its sensors, generates an ECU data transaction (ECU transaction), and sends it to the MECU. The MECU receives all ECU transactions and veriﬁes (checks integrity and authenticity) those. If an ECU transaction cannot be veriﬁed, then the MECU makes the ‘Send Data’ request again to that ECU. When all transactions are collected, the MECU gathers the transactions and signs it. Figure 3.5 shows the process of storing data in the Blockchain. There are multiple 3.3. SECURING THE STORED DATA 36

Start Text YES M*N ECU NO transactions veriﬁed?

Select leader among M MECUs MECU sends signed MECU sends signed 'Block Accepted' 'Block Rejected' notiﬁcation to the leader notiﬁcation to the leader

Leader sends signed `Send Data' request to other M-1 MECUs Leader veriﬁes (M-1) `Block Accepted/Rejected' notiﬁcations

The MECUs verify leader's sign and send the signed MECU transaction to the leader NO Percentage of 'Block YES Accepted' > Block Acceptance Rate?

Leader verifies M-1 MECU transactions The Block is Rejected The Block is accepted and appended in Blockchain Leader verifies every MECU's ECU transactions (N), which in total (M-1)*N ECU Leader sends all `Block Accepted/Rejected' transactions notifications to M-1 MECUs with its sign

Leader creates a block with all verified Every MECU verifies the leader's sign and M-1 ECU transactions signs of the `Block Accepted/Rejected' notifications

Leader sends the signed block to MECUs for veriﬁcation NO Percentage of 'Block YES Accepted' > Block Acceptance Rate? MECUs verify leader's sign and M*N ECU The Block is accepted and transactions The Block is Rejected appended in Blockchain

End

Figure 3.5: The process of storing data in the Blockchain. 3.3. SECURING THE STORED DATA 37

MECUs in a vehicle. One of the MECUs is chosen as a leader by the round-robin algorithm [82]. Every time a new leader is selected to create a new block. The leader makes a ‘Send Data’ request to all MECUs. Each MECU sends their signed MECU transaction to the leader. The leader verifies the MECU transactions. If the number of total MECUs is M (including the leader), then the leader needs to verify (M-1) MECU transactions. After the verification of the MECU transactions, the leader verifies every ECU transactions. For example, if an MECU has N number of ECUs, then the leader needs to verify (M-1)*N number of ECU transactions. After the verification of the ECU transactions, the leader makes a block with the verified ECU transactions. The block contains the following items: Block number, (M*N) number of ECU transactions, Hash of the current block, Hash of the previous block, Leader ID, and Leader Signature. Then the leader sends this block to the MECUs for verification. When an MECU receives a new block, it verifies the signature of the leader. If the leader’s signature is verified, then the MECU verifies the ECU transactions (M*N number of transactions). If the transactions are verified, then the MECU sends the ‘Block Accepted’ notification to the Leader. Otherwise, the MECU sends the ‘Block Rejected’ notification. The leader receives either ‘Block Accepted’ or ‘Block Rejected’ notification from the MECUs. If the percentage of ‘Block Accepted’ notification is higher than the predefined block acceptance rate, then the leader accepts the block and appends it to the Blockchain. The block acceptance rate can be decided by vehicle manufacturers as their requirements. Next, the leader sends the received ‘Block Accepted/Rejected’ notifications to other MECUs. Every MECU verifies all ‘Block Accepted/Rejected’ 3.3. SECURING THE STORED DATA 38

notifications. If the percentage of ‘Block Accepted’ notifications is higher than the predefined block acceptance rate, then the MECUs append the last verified block to the Blockchain. Otherwise, the MECUs discard the last verified block. As a result, all the MECUs hold the exact copy of the Blockchain.

MECU UID ECUs Data MECU Signature

1001 7aa6949f72…

10001110 1011 30c78520e4… 1529938802.31

Figure 3.6: Data transaction structure (MECU transaction) from an MECU to the leader.

3.3.1.1 Data Transaction Structure from an MECU to the Leader

An MECU sends data transaction to the leader when the leader requests for the data (MECU transaction). Figure 3.6 shows data transaction structure from an MECU to the leader. This transaction contains the following fields: MECU UID, ECUs Data, and MECU Signature. The MECU UID field contains the UID of the MECU. The ECUs Data field holds every ECUs transactions of that MECU. To form the ECUs Data field, the MECU collects transactions from its ECUs. After collecting all the transactions, the MECU sorts the transactions by the transaction number in ascending order. Then these transactions are listed as an ECUs Data. The last field 3.3. SECURING THE STORED DATA 39

is the MECU signature. The MECU sends its signature so that, the leader can verify. In the figure, the ‘ECUs Data’ field contains multiple ECU transactions. One of the ECU transactions is shown in the figure.

3.3.1.2 The Structure of Blocks

A block is a segment of Blockchain. All block structures are the same. The first block of Blockchain is called the genesis block. Every other blocks follow the genesis block. Figure 3.7 shows the structure of blocks of our Blockchain. Each block contains Block Number, Leader ID, Hash of the Previous Block, Hash of the Current Block, Transactions, and Leader Signature. A first attribute is a Block Number. Every time a new block’s block number increases by one. Therefore, a new block’s number is higher than the number of the most recent block of the Blockchain. The next attribute is the Leader ID. Each block is created by the leader. The leader ID holds the UID of that leader. Each block contains the hash of the previous block. However, the genesis block does not have any preceding block. Therefore, for the genesis block, this field can be predefined. The Transactions field holds the transactions from MECUs. As we have discussed earlier, an MECU sends its ECUs’ transactions to the leader. The leader sorts all transactions by the MECU UID and appends the transactions in the block. In the figure, one of the transactions is shown. The next field is the hash of the current block. This field is calculated from the block number, leader ID, hash of the previous block, and transactions. To generate a hash, we use SHA256, which is used in the bitcoin [81]. This hash is used to provide integrity of the data. The last field is the leader signature. When a block is created, the leader generates a signature with all previously presented fields. Finally, the signature is appended in the block. 3.3. SECURING THE STORED DATA 40

This signature provides authenticity and integrity of the block.

Genesis block block block Most recent block Block Number …1010 …1011 …1011 Leader ID 1100 1101 1001 Hash of Previous Block f5f5a7915a… 00729b325f… 810f879c91… Hash of Current Block 00729b325f… e16f7290a9… aa2d57cf2f… Transactions Transactions Transactions Transactions

Leader Signature baf2211044… bb39dd55cc… 481dc9d423…

Requestee Requester Encrypted Data Generation Last Data ECU Tx. No MECU UID Sensor ID ECU UID ECU UID Data Time Generation Time Signature 10001110 1011 36269df89e… 1529938741.12 10001111 1101 52df6a002b… 1529938783.34 1001… 1001 10001000 1529938802.31 98e9699d…

10001110 1011 a65689a061… 1529938802.31

Figure 3.7: The Structure of Blocks.

3.3.2 Data Monitoring by the Watcher

When an adversary compromises one of the MECUs and tries to alter the Blockchain data, it is detected by the watcher as described below. The watcher is connected to every MECUs. It can directly read the Blockchain from the MECUs, though it does not have a write permission on MECUs. The watcher reads the same block from the MECUs and compares the hash values of the same blocks. If all the MECUs’ hash values are the same, then the Blockchain is not compromised. If the same block is compromised in multiple MECUs, then the watcher assumes the hash value from the maximum number of MECUs is authentic. Any value diﬀerent than this value is considered as altered. This decision-making rule is called the majority rule. Therefore, the watcher can make an appropriate 3.3. SECURING THE STORED DATA 41

decision as long as half of the MECUs are not compromised. The watcher checks the Blockchain after every T seconds. The value of T can be adjusted by vehicle manufacturers depending on the communication bus speed and the processing power of MECUs. Performance Improvement of the Watcher: The watcher monitors blocks of the Blockchain for data consistency. However, the number of blocks in the Blockchain can be more than thousands. Therefore, it might be resource draining to check all the blocks. We assume that the Blockchain data will be synchronized to the cloud regularly. However, there might be a scenario when vehicles cannot be synchronized. In this case, the number of blocks can be large enough to cause the monitoring process slow. For this reason, a reasonable default value Z should be assigned by the vehicle manufacturers. The value of Z can be the last N blocks or the last T seconds. The watcher will always monitor the last N number of blocks or the blocks of the last T seconds. The value of Z can be assigned in a way so that the watcher can monitor all the blocks in most of the time.

3.3.3 Data Protection Without the Resource Consuming Algorithm

In Blockchain, a consensus algorithm is used to choose a leader. A leader creates a block and appends the block in the Blockchain. However, the consensus algorithm might be resource consuming. Some examples of the resource consuming consensus algorithms are presented in Section 3.4.5.1. In the proposed solution, we choose the leader among MECUs using a round-robin algorithm [82], which does not need additional resources. Now, if one of the MECUs is compromised, then the data protection is achieved in the following ways: 3.4. MAJOR CHALLENGES 42

Protection from a Compromised Source MECU: Every MECU gathers their ECUs’ data, makes a transaction, and sends it to the leader. However, a compromised MECU can try to modify its ECU data. For example, when an ECU sends its transaction to its MECU, the MECU can modify the ECU data and send it to the leader to append in the Blockchain. Nevertheless, the leader verifies the ECU transactions. Therefore, if the compromised MECU modifies one of its ECUs’ data, then that data is going to be rejected by the leader. As the signing key of the data is only known to the source ECU, the compromised MECU cannot make an authentic signature after the modification of the data. As a result, the data is not going to be appended to the Blockchain. Protection from a Compromised Leader: Every MECU sends transactions to the leader. The leader gathers all MECU transactions and makes a block. Then the leader sends the block to every MECU for verification. Hence, a compromised leader can try to modify any ECU data before sending it to other MECUs. However, if the leader modifies any ECU data, then that transaction (transaction carries data) will not be verified by other MECUs, as each transaction is signed by the source ECU and the signing key is only known to the source ECU. Therefore, the compromised leader will not be able to modify ECU data.

3.4 Major Challenges

In this section, we explain the challenges in transferring data, using the PKE, deter- mining the digital signature, choosing the symmetric key cryptography, and employing Blockchain in vehicles. 3.4. MAJOR CHALLENGES 43

3.4.1 Transferring Data

If we examine some widely used communication bus message formats, then we will observe that most of those are not capable to provide CIA. For example, Controller Area Network (CAN), Local Interconnect Network (LIN), Media Oriented System Transport (MOST), and FlexRay are widely used in vehicles. CAN, LIN, and MOST messages do not provide any authenticity or confidentiality. Hence, a single compromised ECU can compromise the bus it belongs to [83]. Similarly, in FlexRay messages, authentication and encryption are not provided. Thus, the FlexRay messages can be spoofed [54]. Our Decision. Integrating CIA into the current communication buses will re- quire more bandwidth. Moreover, the number of ECUs are increasing in the communication buses. Therefore, the bandwidth consumption is increasing significantly. To solve this problem, the vehicle industry has started to use Unshielded Twisted Pair (UTP) Ethernet. The UTP Ethernet is a single pair wire which is flexible, lightweight, cheap, and easy to manufacture [77]. A single pair allows the manufacturer to make space and save weight in vehicles. The BMW is already using the Ethernet in its X5 model to connect cameras and the surround view system. The Ethernet is also used in the Volkswagen Passat for its parallel parking system [18]. The Jaguar Land Rover is utilizing the Ethernet as its communication backbone [3]. The NXP is manufacturing Automotive Ethernet Switch and Automotive Ethernet PHY Transceiver [57]. The speed of the automotive Ethernet switch is 1000 Mbps which is more than ten times faster than any traditional automotive communication system. After considering all these examples, we have decided to use the Ethernet to integrate CIA in this work. 3.4. MAJOR CHALLENGES 44

3.4.2 Choosing the Symmetric Key Cryptography

We use symmetric key cryptography to send data conﬁdentially. Symmetric key cryptography is faster than the PKE. However, we need to select a symmetric key algorithm which is less memory consuming, less power consuming, and faster in ECUs. Our Decision. The eSTREAM project ran from 2004 to 2008 to promote the design of an eﬃcient and compact stream cipher, which would be suitable for devices with restricted resources, such as limited storage and power consumption. Salsa20 was one of the accepted ciphers in the eSTREAM. In 2008, Bernstein [6] showed that Salsa20 would not be slower than most widely used AES. Furthermore, Chacha20 [7] is an enhancement of the Salsa20. In 2017, Santis et al. [21] showed that Chacha20 is the most promising cipher for resource-constrained devices, such as IoT devices. They also compared Chacha20 and AES in the ARM processor (in vehicles, the ARM processor is most widely used). In their comparison, they showed that if a device has a dedicated hardware for AES, then the AES is faster than Chacha20. However, without the dedicated hardware, Chacha20 is better than AES. Google is using Chacha20 instead of AES in their chrome browser of an android phone, as Chacha20 is around three times faster than AES in mobile devices [80]. Chacha20 has been used in SSH, Android OS, Chromium/Chrome browser for TLS, Firefox browser for TLS, Opera browser for TLS, Google web crawler, etc. [36]. After considering all these literature, we have concluded to use Chacha20 cipher in this work. 3.4. MAJOR CHALLENGES 45

3.4.3 The Use of Public Key Encryption

One of the specialties of PKE is that the sender and receiver do not need to use a common encryption key. Unlike symmetric key cryptography, PKE uses diﬀerent keys for encryption and decryption. Therefore, it is not required to send a common key to both parties (sender/receiver) before the encryption and decryption. However, we cannot use PKE for data transmission of ECUs. The PKE is slower and resources consuming [69]. As a result, it is not feasible for handling every data transmission of ECUs. Our Decision. In this work, we use PKE only for transferring the key. Moreover, we have adopted the Elliptic Curve Integrated Encryption Scheme (ECIES) instead of the widely used RSA. The ECIES is an encryption and decryption scheme based on the Elliptic Curve Cryptography (ECC) and it is faster than the RSA in encryption and decryption time [35,68,76].

3.4.4 Choosing the Digital Signature

A digital signature provides confidentiality and integrity of the data. There are many digital signature algorithms to use. Most widely used digital signature algorithms are RSA, DSA, and ECDSA. RSA is faster than the ECDSA in signature verification. However, the ECDSA is faster than RSA in signing [40]. For the proposed approach, we need a digital signature algorithm, which is faster in signing and verification. Our Decision. The Ed25519 is almost two times faster than RSA, DSA, and ECDSA in signing and verification [9]. The Ed25519 has the following benefits over other digital signature algorithms:

• The Ed25519 provides faster single veriﬁcation. 3.4. MAJOR CHALLENGES 46

• It provides faster batch veriﬁcation and we need a faster batch veriﬁcation in the proposed approach.

• It also provides more robust security. The security strength of Ed25519 is equivalent to 3000-bit RSA keys.

• The size of the signature is very small in the Ed25519. It is just 64 bytes, which is smaller than RSA.

After examining all these beneﬁts, we have determined to use the Ed25519 in this work. The Ed25519 has been used by Tor, Sia, OpenBSD, Hyperledger Iroha, Putty, OpenSSH, etc. [37].

3.4.5 Using Blockchain in Vehicles

Among the many use cases of Blockchain, securing data is one of them [87]. In vehicles, we need to protect ECU data. However, we cannot directly use Blockchain in vehicles as some of the properties of Blockchain cannot be allowed in vehicles. We describe those in the following subsections.

3.4.5.1 Resource Consuming Consensus Algorithm

Consensus algorithms are resource exhausting [28,29,58]. Currently, there are various consensus algorithms to use in Blockchain. Some of those are Proof of Work (PoW) [52], Proof of Stake (PoS) [84], and Proof of Elapsed Time (PoET) [14]. Bitcoin is using the PoW and Ethereum is based on the PoS. The PoW needs high computational resources and the PoS needs asset for solving cryptographic puzzle [24]. Though the PoET does not need high computational resources, it needs to be implemented in 3.4. MAJOR CHALLENGES 47

Intel’s Software Guard Extensions (SGX). The SGX is a set of processor commands that allow the execution of code inside a Trusted Execution Environment [31]. If we want to adopt the PoET in vehicles, then vehicles need to install Intel’s hardware, which might not be achievable for every vehicle. As a result, we cannot choose these consensus algorithms in vehicles. Our Decision. As ECUs are a resource-constrained device, we cannot directly use these algorithms in vehicles. Therefore, we have decided to use a simple round- robin algorithm to elect an MECU as a leader. How the data is protected without any resource consuming consensus algorithm is discussed in the Section 3.3.3.

3.4.5.2 Latency of Transactions

In Blockchain, a transaction is confirmed when a block containing that transaction is verified and added to the Blockchain. The total time of generating, verifying, and appending a block to Blockchain is called a block time. In Bitcoin, the block time is around ten minutes, while in Ethereum around fifteen seconds. However, in vehicles, we need a fast response from one ECU to another ECU. Therefore, we need faster transactions among ECUs. Moreover, we need a flexible block time, so that vehicle manufacturers can change the block time depending on vehicle architecture. Our Decision. In this work, the inter-ECU communications do not involve Blockchain. ECUs send data to its MECU (ECU transaction). MECUs process the ECU transactions and send to the leader. Therefore, inter-MECU communications are used instead of the inter-ECU communications to create a block. Thus, high latency of transactions does not affect inter-ECU communications. Furthermore, the block time of the proposed approach is flexible. It can be adjusted based on our 3.4. MAJOR CHALLENGES 48

needs.

3.4.5.3 Transaction Throughput of the Blockchain

The throughput of Blockchain is the number of confirmed transactions per second. As the number of confirmed transactions depends on a block, therefore, the throughput of Blockchain depends on the block time. If the number of transactions in any block is N and the block time is M minutes, then the throughput is (N/M*60) transactions per second (tps). For Bitcoin, the throughput is around 7 tps and for Ethereum it is around 20 tps, while for Visa it is around 56000 tps [43]. In vehicles, the requirement of the throughput can be remarkably high when multiple ECUs try to get the data from a single ECU. As a result, this low throughput might not be acceptable in vehicles. Our Decision. As we have discussed earlier, we adopt Blockchain only in MECUs, which solves the low throughput issue too. Since we are not using Blockchain in inter-ECU communications, ECU transactions are not affected by this work. There- fore, the throughput can be adjusted on our requirements. In this work, the throughput depends on the communication bus speed and the processing power of ECUs.

3.4.5.4 Resource Scarcity

An ECU is a very small device. The resources (computational power, memory, storage capacity, etc.) of ECUs are limited. Furthermore, to run Blockchain, it needs high computational power and memory. To store Blockchain data, enough storage space is needed. All these requirements of Blockchain might not be feasible in ECUs. 3.5. SUMMARY 49

Our Decision. Similar to the previous decision, we have resolved this chal- lenge by implementing Blockchain only in MECUs. We have shown that if we use the Blockchain solely in MECUs, it is still possible to protect ECU data. Besides, MECUs are equipped with more resources than normal ECUs. For example, Neousys technology [75] is marketing embedded in-vehicle devices, which can be used as an MECU. These in-vehicle devices are conﬁgured with 8 GB - 32 GB RAM, 1.6 GHz - 2.7 GHz processor, supports hot-swappable HDD, and Gigabyte Ethernet.

3.5 Summary

Current vehicle ECU communications are vulnerable. We can increase the security by adopting conﬁdentiality, integrity, and authenticity. The proposed approach describes the systematic use of cryptographic algorithms in vehicle ECU communications. We also determine the cryptographic algorithms that are suitable for ECUs. Furthermore, for the protection of ECU data, we propose to use Blockchain. How- ever, Blockchain uses resource consuming consensus algorithm to generate a block, which is not suitable for vehicles. Therefore, we modify the process of storing data (block generation) in the Blockchain to use in MECUs. We also modify the domain- based in-vehicle architecture by integrating a watcher, which monitors ECU data in the Blockchain. 50

Chapter 4

Implementation and Evaluation

In this chapter, we describe the implementation details of the proposed approach. In our implementation, we use two platforms, namely Docker and the ARM architecture- based Raspberry Pi Board (RPB). Docker is a tool that provides virtualization and RPB is a real hardware. However, the implementation and debugging process on Docker is faster and simpler than RPB. Therefore, at ﬁrst, we conduct our experiments on Docker, then we do the same experiments on RPB. Furthermore, we perform our security experiments to check whether the proposed approach works. After that, we make an attack protection analysis based on our security experiments. Finally, we conduct the performance evaluation.

4.1 Initialization of ECUs and MECUs

To implement the proposed approach, we need to initialize ECUs, MECUs, and the watcher that we describe below. 4.1. INITIALIZATION OF ECUS AND MECUS 51

4.1.1 ECU Credential Initialization

In the vehicle manufacturing process, every ECU needs to be assigned a Unique Identifier (UID), two elliptic curve-based asymmetric key pairs, and public keys of its MECU. The UID is unique in a vehicle. It can be eight (8) bit in length as the total number of ECUs in vehicles is lower than 256. However, the length of the UID is not fixed. It can be changed by the vehicle manufacturer. Then two elliptic curve-based asymmetric key pairs are generated. One key pair is used for public key encryption and another pair is for a digital signature. Besides these keys, every ECU holds its MECU’s public encryption key and a public verification key. Finally, the ECUs hold ECU ‘Request List’.

4.1.2 MECU Credential Initialization

During the vehicle manufacturing process, every MECU is assigned a UID, the digital signature key pair, all MECUs’ public verification keys, and all ECUs’ public keys. Similar to ECU UID, MECU UID is unique in a vehicle. The total number of domains in vehicles is 5 to 10. Therefore, the UID can be four (4) bit in length. However, this length can be changed by the vehicle manufacturer. Unlike ECUs, the vehicle manufacturer generates one elliptic curve-based asymmetric key pair for MECUs. This key pair is for a digital signature. The data of the ECUs are encrypted by source ECUs. Hence, the MECUs do not need the public key encryption pair. Every MECU holds public verification key of all MECUs. As a result, an MECU can verify every other MECUs’ signature. Besides these keys, the MECUs contain public encryption keys of its subordinate ECUs and public verification keys of all ECUs. When a leader MECU sends a block to verify, other MECUs verify every ECU’s signature to ensure 4.2. IMPLEMENTATION ON THE DOCKER 52

that the data are not modiﬁed by a compromised MECU or the leader. The details of the block veriﬁcation are discussed in Section 3.3.1. Finally, the MECUs hold ECU ‘Permission List’ and ‘State List’.

4.1.3 Watcher Credential Initialization

In the vehicle manufacturing process, the watcher is assigned with a UID and secure read permission capability. The secure read capability gives the ability to read the Blockchain of MECUs. The watcher reads every MECU’s Blockchain and compares all hash values. The frequency of the reading is ﬂexible. It can be adjusted depending on the Blockchain size, communication bus speed, and the processing power of the watcher. The watcher also has the capability to generate an alert and inform the authorized parties. In this work, we assume that the watcher cannot be compromised.

4.2 Implementation on the Docker

Docker is a tool that provides virtualization of applications and its dependencies. These applications can be any software or operating system. For example, in an Ubuntu machine, we can virtualize Debian, Alpine or Fedora operating system and execute their software. The whole package of software that includes code, libraries, settings, system ﬁles, etc. is called a container. Unlike the virtual machine, a Docker container is an abstraction in the application layer and multiple containers share the same kernel. Therefore, the container is lightweight and faster than the virtual machine [22]. 4.2. IMPLEMENTATION ON THE DOCKER 53

4.2.1 Why Docker?

We use Docker containers in the experiments as an ECU, MECU, and the watcher. The containers provide virtualization of the real environment. Therefore, we write source code for the containers, execute the code, and use the same code on the RPBs. We build the Docker containers with the same environment as the RPBs. We could directly write code on the RPBs. However, it would take a longer time, since the debugging process of multiple Docker containers is much faster than multiple RPBs.

4.2.2 Experimental Setup

In the experiments, the Docker containers are configured to use 100% of the host machine’s CPU. Therefore, the performance of the Docker containers depends on the host machine’s specification. Table 4.1 shows the host machine specification and the Docker version. The host machine’s operating system is Ubuntu. We install Docker on Ubuntu and create ten (10) Linux-based Docker containers. We create four Docker bridge networks. The Docker bridge network (Docker network) allows communications among containers in the same network. However, the containers of one network cannot communicate to another network containers until they are permitted explicitly. Figure 4.1 shows the Docker container setup of the ECUs, MECUs, and the watcher. We assign MECU1, ECU1, and ECU2 in the first network; MECU2, ECU3, and ECU4 in the second network; MECU3, ECU5, and ECU6 in the third network, and finally the watcher in the fourth network. Next, we generate elliptic curve-based keys and lists (permission, state, and request list) of ECUs and MECUs. The MECUs and watcher are permitted to communicate with each other. Even though the MECUs can communicate with their own ECUs, 4.2. IMPLEMENTATION ON THE DOCKER 54

Table 4.1: Host Machine Speciﬁcation

Processor Model Intel Core i5-6200U Clock Frequency 2.3 GHz Number of Cores 2 Number of Logical Processor 4 L1 cache 128 KB L2 cache 512 KB L3 cache 3.0 MB RAM 8 GB Hard Disk Size 1000 GB Operating System Ubuntu 16.04.3 Docker Version 17.05.0-ce Docker API Version 1.29 with other MECUs, and the watcher, they cannot interact with another MECU’s ECU. In Docker, the inter-container reading or writing speed can be conﬁgured [32]. Therefore, we conﬁgure the inter-container speed to 1000 Mbps to simulate the speed of the gigabyte Ethernet.

WATCHER Watches MECUs’ WATCHER data consistency MECU . Provides access control ECU . Fetches data from ECUs . Encrypts and signs MECU1 MECU2 MECU3 . Holds the Blockchain data before sending . Leader Generates a block to the MECU or ECUs

ECU1 ECU2 ECU3 ECU4 ECU5 ECU6

Figure 4.1: Docker container setup.

8 4.3. IMPLEMENTATION ON THE RASPBERRY PI BOARD 55

4.3 Implementation on the Raspberry Pi Board

Raspberry Pi Board (RPB) is a single board computer which has a processor and RAM for computing, microSD card for installing operating system, USB ports to connect external peripherals (keyboard, mouse, flash drive, etc.), Ethernet port to connect with a wired network, HDMI port to connect with a display, etc. Besides, it is possible to install different types of operating systems on RPB. Currently, RPB supports the following operating systems: Raspbian, Ubuntu, Windows, OSMC, RISC OS, etc [60]. Similar to a computer, we can execute different programs or processes on the RPB and check the output on the display.

4.3.1 Why Raspberry Pi Board?

We conduct the experiments using RPBs. The latest automotive computing devices are mostly based on the ARM architecture. For example, Renesas is marketing computing and infotainment systems for vehicles. Some of those are R-car H1, R-car H2, R-car H3, R-car M2, R-car M3 [66]. All these products are ARM architecture-based. Their CPU, clock speed, RAM, and memory is almost similar to RPB. Moreover, Liem et al. [45] used Wandboard as an ECU in their experiments. The speciﬁcations of the Wandboard is almost identical to RPB. Therefore, we use the Raspberry Pi 3B plus [61] as an ECU, MECU, and the watcher in the experiments.

4.3.2 Experimental Setup

We use six RPBs in the experiments. We assign two RPBs as an ECU (ECU1 and ECU2), three RPBs as an MECU (MECU1, MECU2, and MECU3), and one RPB as the watcher. Every RPB runs Raspbian operating system, which is a Linux-based 4.3. IMPLEMENTATION ON THE RASPBERRY PI BOARD 56

WATCHER Watches MECUs’ WATCHER data consistency

ECU Encrypts and signs data before MECU1 MECU2 MECU3 sending to the MECU or ECUs MECU ECU1 ECU2 . Provides access control . Fetches data from ECUs . Holds the Blockchain . Leader Generates a block (a) (b)

Figure 4.2: (a) The experimental setup of RPBs and (b) The experimental testbed.

(Linux kernel 4.14.42). All these RPBs are connected through an Ethernet connection.

Figure 4.2(a) shows the experimental setup of RPBs. In13 the experiments, ECU1 is the data requester and ECU2 is the requestee. Both ECUs are connected in the same domain under MECU1. ECU1 and ECU2 contain the public encryption and verification keys of MECU1. MECU1 contains the other two MECUs’ public verification keys, ECU1 and ECU2’s public keys (encryption and verification), ‘Permission List’, and ‘State List’. Similarly, each of MECU2 and MECU3 holds other MECU’s public verification keys, ECU1 and ECU2’s public verification keys, ‘Permission List’, and ‘State List’. MECUs can communicate with each other. The watcher uses scp [19] command to read Blockchain from the MECUs. ECU2 contains randomly generated sensor’s data (raw data) of different sizes. Figure 4.2(b) shows the experimental testbed. In the figure, two RPBs on the left are ECUs (ECU1 and ECU2), three RPBs in the center are MECUs (MECU1, MECU2, and MECU3), and the rightmost RPB is the watcher. 4.4. SECURITY EXPERIMENTS 57

4.4 Security Experiments

In this section, we present security experiments with respect to CIA, identity-based access control, and the Blockchain. To check the impact of the proposed approach, we perform the experiments with and without CIA, ‘Permission List’, and Blockchain.

4.4.1 Data Conﬁdentiality

In this experiment, ECU1 makes the ‘Communication Request’ to MECU1 for communicating with ECU2. After getting the approval from MECU1, ECU1 makes the data request to ECU2. ECU2 sends the sensor data to ECU1. At this point, we use tcpdump [74] to examine the sent data. We find that without confidentiality, we can read ECU2’s sent data from the communication bus. However, after ensuring CIA, the data field becomes meaningless since it is encrypted. It ensures confidentiality of the data. Figure 4.3 shows the unencrypted data before applying CIA. ECU2 sends ‘HELLO’ in the data field. This data is unencrypted. Therefore, other ECUs can read this data.

Figure 4.3: Unencrypted data transmit from ECU2 to ECU1. 4.4. SECURITY EXPERIMENTS 58

Figure 4.4 shows the encrypted data ﬁeld after applying CIA. In this experiment, ECU2 sends the same ‘HELLO’ data to the ECU1. However, this time it is encrypted with Chacha20 cipher. Therefore, other ECUs cannot read the data.

Figure 4.4: Encrypted data transmit from ECU2 to ECU1.

4.4.2 Data Integrity and Authenticity

A digital signature ensures integrity and authenticity. Therefore, we check ECU data with and without a digital signature. Similar to the data confidentiality experiments, ECU2 sends sensor data to ECU1. We assume ECU2 is supposed to send ‘3.3V’ as a sensor data. However, accidentally ECU2 sends ‘4.3V’ in the data field. Without the CIA, ECU1 accepts ‘4.3V’ as valid data. While CIA is implemented, ECU2 creates a signature (generates a hash of data then encrypts it with a private key) assuming that the data is ‘3.3V’. Then ECU2 sends ‘4.3V’ instead of ‘3.3V’. Furthermore, when ECU1 verifies the signature, it finds the mismatch between the received data 4.4. SECURITY EXPERIMENTS 59

and signature. As a result, ECU1 declines the data. It conﬁrms the integrity and authenticity of the data. Figure 4.5 shows the rejection of ECU2’s (requestee) data by ECU1 (requester). ECU1 shows an error stating that the requestee’s signature is not matched (forged or corrupted).

Figure 4.5: ECU1 rejects ECU2’s data as the signature is not veriﬁed.

4.4.3 Identity-Based Access Control

Identity-based access control mechanism is implemented in MECUs. When ECU1 makes the ‘Communication Request’ to MECU1 for communicating with ECU2, MECU1 checks the identity of ECU1 by verifying the signature of ECU1. Then MECU1 checks ECU1’s entry in the ‘Permission List’. To ensure identity-based access control, we add another ECU (ECU3) under MECU1. Now, there are three ECUs (ECU1, ECU2, and ECU3) in the same domain. In the experiments, we ﬁnd that without the ‘Permission List’, every ECU can directly send or receive data from another ECU as none of these ECUs (ECU1, ECU2, and ECU3) need permissions 4.4. SECURITY EXPERIMENTS 60

from MECU1. On the contrary, this situation is diﬀerent when the ‘Permission List’ is integrated. We change the ‘Permission List’ in a way so that ECU3 can communicate particularly with ECU1 but not with ECU2. When ECU3 sends the request to communicate with ECU1, MECU1 accepts its request and gives the permission. Be- sides, when ECU3 sends the request to communicate with ECU2, MECU1 rejects the request. Furthermore, when ECU3 sends the data request to ECU2 without the permission, ECU2 refuses the request. Since ECU3 is not registered in ECU2’s ‘Request List’, the request is rejected. Figure 4.6 shows the rejection of ECU3’s ‘Communication Request’ to MECU1 for ECU1. MECU1 sends an error message to ECU3 stating that it does not have the permission to connect with ECU1.

Figure 4.6: MECU1 rejects ECU3’s ‘Communication Request’. 4.4. SECURITY EXPERIMENTS 61

4.4.4 Security of the Stored Data

To check the security of the Blockchain data, we assume that MECU3 is compromised. We also assume that the objective of the adversary is to alter the vehicle’s stored data. The adversary wants to modify the speedometer value of the stored data. We consider that the adversary knows the sensor ID of the speedometer. The adversary also identifies the block number that contains the value of the speedometer. In our case, it is block number 0. At first, MECU3 modifies the block number 0 and recalculates the hash value in its Blockchain. However, the watcher finds the mismatch among hash values. It gives an alert stating that the block number 0 is modified. Figure 4.7 shows the watcher alert when a single block is compromised. The watcher shows the timestamp and the block number that is compromised. We config- ure the watcher to monitor the Blockchain and generate an alert message after every second.

Figure 4.7: Watcher alert when a single block is compromised. 4.5. ATTACK PROTECTION ANALYSIS 62

We also modify multiple blocks at the same time to check the ability of the watcher. We notice that the watcher detects all modiﬁcations and generates an alert. Figure 4.8 shows the watcher alert when multiple blocks are compromised. This time the watcher shows all block numbers that are compromised.

Figure 4.8: Watcher alert when multiple blocks are compromised.

4.5 Attack Protection Analysis

In this section, we analyze some attacks that can be prevented by employing the proposed approach. 4.5. ATTACK PROTECTION ANALYSIS 63

4.5.1 Protection from Data Stealing

In vehicles, if an adversary can compromise one of the ECUs, then the adversary can record another ECU data. Later this data can be exploited for other attacks. For example, by analyzing the data packet, an adversary can discover how to control the radio, the instrument panel cluster, and body control module [42]. However, we encrypt all data. Therefore, the adversary cannot read the data. As a result, the proposed solution is protecting from data stealing and new attacks.

4.5.2 Protection from Data Falsiﬁcation

If the adversary remotely compromises one of the ECUs and sends misleading data to other ECUs, then the driver of the vehicle can be confused. For example, an adversary can manipulate the speedometer to display slower than the actual speed. In such cases, the driver can drive more than the speed limit and cause an accident. However, if every ECU checks the integrity and authenticity, then this kind of attack can be prevented. In the proposed approach, we provide integrity and authenticity. Therefore, this problem can be eliminated.

4.5.3 Protection from Control Override

If the adversary remotely compromises one of the ECUs and sends the shutdown command to the engine control unit, then the vehicle will stop. This can be a disaster. The reason for this disaster is that the compromised ECU can pretend to be a high priority ECU, though the adversary compromises the low priority ECU. As the engine control unit does not check the authenticity of the message, therefore, it thinks the shutdown message is from the high priority ECU and it stops the engine. 4.5. ATTACK PROTECTION ANALYSIS 64

However, we provide the authenticity of every message and the identity-based access control mechanism. Even though one of the ECUs is compromised, the compromised ECU cannot send messages to other ECUs without the permission. As a result, the proposed solution can defend from this type of attack.

4.5.4 Protection from Vehicle Degradation

An adversary can connect to the OBD-2 port, send unauthentic messages and do following things: boost RPM, disable all cylinders suddenly, disable the engine such a way so that it knocks excessively when started [42]. All these things can degrade vehicles. However, we provide authenticity mechanism among ECUs. If an adversary tries to connect with OBD-2 port and sends unauthentic messages, then ECUs will not respond. Therefore, the proposed approach is guarding against vehicle degradation.

4.5.5 Protection from Remote Access Threats

Vehicle manufacturers provide mobile apps to view the information of vehicles. Most of these mobile apps use web API from the service provider and the provider connects to the vehicle using 3G/4G connection [25]. Miller and Valasek [33] exploited a vulnerability of the Uconnect platform, which was connected using the 3G connection. Then they stopped the Jeep from several miles away by sending a shutdown command. As the engine control unit did not check the authenticity of the message, hence, it believed that the shutdown message was from the legitimate ECU. However, the proposed solution provides the authenticity and access control to prevent such attacks. 4.6. PERFORMANCE EVALUATION 65

4.6 Performance Evaluation

To evaluate the performance, we measure the end to end delay of the data transfer between ECUs. From recent literature, we find that the maximum end to end delay between ECUs for control data in vehicles is 10 ms [64]. Subsequently, the requirement for real-time audio and video data is different. For example, when the video data from camera systems or interactive audio applications such as VoIP are transmitted, the maximum end to end delay is 45 ms [64, 72]. Furthermore, for the multimedia data, this delay is 100 ms [62]. The multimedia data is an audio or video data that is transmitted for the entertainment system of vehicles. After comparing all end to end delay requirements, we can conclude that the maximum lowest requirement is 10 ms. However, the maximum data size in CAN frame is 8 bytes, CAN-FD is 64 bytes, MOST is 384 bytes (3072 bits), and Ethernet is 1500 bytes. If the vehicle uses the Ethernet and the data size is 1500 bytes, then the total time of the encryption, signing, verification, decryption, and transfer time need to be within 10 ms. In the experiments, we use various sizes of data. Initially, we send 1 byte of data. Then every time we double the size of the data (2 bytes, 4 bytes, 8 bytes, . . . ) and record the average end to end delay. We double the size of the data until the end to end delay exceed 10 ms. In both platforms, ECU1 is data requester and ECU2 is requestee. Both ECUs are connected in the same domain under MECU1. ECU1 is permitted to send a data request to ECU2. Therefore, ECU2 sends a randomly generated sensor’s data (raw data) to ECU1. 4.6. PERFORMANCE EVALUATION 66

4.6.1 End to End Delay on Docker

In Docker experiments, ECU1 is added in MECU1’s ‘Permission List’ to communicate with ECU2. After receiving the notification from MECU1, ECU2 adds ECU1 in its ’Request List’. Next, ECU1 sends the data request to ECU2. At this point, we start our timer. After that, ECU1 receives the data, verifies the signature, and decrypts the data. At that time, we stop the timer. ECU2 sends various sizes of data, which started from 1 byte. For each size of data, ECU1 records the average end to end delay for ten thousand (10,000) transfers. From Docker experiments, we note that more than 256 kilobytes of data can be transmitted within 10 ms. This data size (256 kilobytes) is much bigger than the current maximum data size (1500 bytes). Figure 4.9 shows the average end to end delay of data transfer on Docker. From the figure, we can observe when the size of the data is from 1 byte to 1 kilobyte, then the average end to end delay does not change significantly. However, when the data size is 2 kilobytes or larger, the end to end delay increases significantly. Furthermore, when the data size is 256 kilobytes, the average end to end delay is 6.204 ms. The next data size is 512 kilobytes, which takes 11.18 ms. Therefore, we cannot transmit 512 kilobytes or more data within 10 ms. However, we cannot evaluate our results with respect to the vehicle’s requirements because of the lack of enough data.

4.6.2 End to End Delay on RPBs

Similar to Docker experiments, ECU1 is permitted to send a data request to ECU2 on RPB experiments. We start our timer when ECU1 sends the data request to ECU2 with its signature. ECU2 veriﬁes the signature, encrypts data, and sends to the ECU1 with its signature. ECU1 veriﬁes the signature and decrypts the data. At 4.6. PERFORMANCE EVALUATION 67

512K 11.18 256K 6.204 128K 3.674 64K 3.272 32K 3.085 16K 2.756 8K 2.592 4K 2.28 2K 2.023 1K 1.612 512 1.497 256 1.406 Data Size (in byte) (in Size Data 128 1.345 64 1.271 32 1.243 16 1.217 8 1.192 4 1.188 2 1.182 1 1.181 0 2 4 6 8 10 12 End to end delay (in miliseconds) Figure 4.9: Average end to end delay of data transfer on Docker. this time, we stop the timer and take the differences of start and stop time. This is our end to end delay. At first, ECU2 sends 1 byte data. We collect the end to end delay for ten thousand (10,000) transfers. Then we continuously double the size of the data and obtain the end to end delay for ten thousand data transfers. We observe that it is feasible to transmit more than 16 kilobytes of data within 10 ms. Figure 4.10 shows the average end to end delay of data transfer on RPBs. From the figure, we can see when the size of the data is from 1 byte to 512 bytes, then the average end to end delay does not change significantly. However, when the data size is 1 kilobyte or larger, the end to end delay increases significantly. Furthermore, when the data size is 16 kilobytes, the average end to end delay is 8.64592 ms. The next data size is 32 kilobytes, which takes 10.10342 ms. Therefore, it is not feasible to transmit 32 kilobytes or more data within 10 ms. However, we cannot evaluate 4.6. PERFORMANCE EVALUATION 68

32K 10.10342 16K 8.64592 8K 7.68132 4K 7.20432 2K 6.93932 1K 6.6947 512 6.4943 256 6.48842 128 6.48533

64 6.4745 Data Size (in byte) (in Size Data 32 6.45423 16 6.40368 8 6.3423 4 6.3092 2 6.28362 1 6.28198

0 2 4 6 8 10 12 End to end delay (in miliseconds) Figure 4.10: Average end to end delay of data transfer on RPBs. our results with respect to the vehicle’s requirements because of the lack of enough data.

4.6.3 Discussion of the End to End Delay

When we measure the end to end delay between ECUs data transfer, we record the data transfer time from one ECU to another ECU. We neglect the time, which is needed for obtaining the permission from MECUs. The reason for this is that when an ECU’s ‘Communication Request’ is granted, the ECU can communicate with the permitted ECU for the next T seconds. At that time, the ECU does not need to send the ‘Communication Request’. To compromise the time which is needed for the ‘Communication Request’, an ECU resends the ‘Communication Request’ before the expiration of the previous ‘Communication Request’. In Docker experiments, we can transmit around 256 kilobytes of data while on the 4.7. SUMMARY 69

RPB experiments 16 kilobytes. The reason for this diﬀerence is the processor speed. The Docker containers are conﬁgured to use 100% of the host machine’s processor and the host machine’s processor speed is 2.3 GHz. Furthermore, RPB’s processor speed is 1.4 GHz, which is lower than the host machine. As a result, RPBs transmit fewer data than the Docker containers within the same time. Therefore, if we increase current ECUs’ processor speed, then ECUs will be able to transmit more data within vehicles’ time requirements.

4.7 Summary

We implement our experiments to exhibit conﬁdentiality, integrity, authenticity, and identity-based access control. Our experiments also generate the Blockchain, where each of the blocks contains ECU data. We also present the capability of the watcher, which monitors the ECU data of the Blockchain. The monitoring of the ECU data ensures the security of the data. Besides, we perform experiments to demonstrate the time needed by the ECUs to communicate after using signing, encryption, veriﬁcation, decryption, and access control mechanism. 70

Chapter 5

Conclusion and Future Work

In this chapter, we summarize our research work, discuss the limitations of the proposed approach, and potential future work.

5.1 Conclusion

Secure in-vehicle communications minimize the plausibility of infiltrating a non- compromised ECU from a compromised ECU. In addition, the protected ECU data can be used to analyze post-accident scenarios, driving behaviors, vehicle conditions, etc. In this thesis, we show that secure in-vehicle communications can be accom- plished by adopting cryptography and digital signature. The combination of these ensures confidentiality, integrity, and authenticity. The confidentiality can be achieved by using ECIES [47] and Chacha20 [7]. The integrity and authenticity can be estab- lished by employing Ed25519 [9]. After applying these algorithms, we show that it is feasible to transmit reasonable amount of data within 10 ms. We also show the implementation of an identity-based access control mechanism in MECUs. The access control of MECUs controls ECU communications and prevents various attacks. Finally, we show the use of Blockchain in MECUs to protect the stored data. To use 5.2. LIMITATIONS 71

Blockchain in MECUs, we modify the process of storing data (block generation) of the Blockchain. The integrated watcher can monitor the ECU data and generate an alert, if the ECU data is inconsistent.

5.2 Limitations

Few limitations of this work are described below:

• Every data is encrypted and signed with a digital signature. As a result, the size of the data has increased and it needs more bandwidth.

• The data structure of the Blockchain stores few additional attributes like the previous hash, current hash, block number, leader ID, and leader signature. To store these attributes, it needs more storage.

• If an MECU fails to work or an adversary compromises the access control of an MECU, then only the communications of that domain can be impeded.

• If an adversary can compromise more than 50 percent of MECUs, then the watcher gives an incorrect alert. Though, the data of the Blockchain is still protected, as every data is encrypted and every transaction is signed by the source ECU.

• The proposed approach can prevent attacks which occur in the absence of conﬁ- dentiality, integrity, and authenticity. However, a receiver ECU or MECU does not check the timestamp of a transaction. Therefore, an adversary may perform a replay attack. 5.3. FUTURE WORK 72

• We are protecting stored data of ECUs, which means that once the ECU data are collected by MECUs then it cannot be altered. Though, if one of the ECUs is compromised and sends corrupted data, then the proposed method cannot detect it. In that case, the corrupted data will be appended in the Blockchain.

5.3 Future Work

As part of the future work, we plan to integrate an Intrusion Detection System (IDS) in MECUs. If a compromised ECU sends corrupted data, then the IDS will generate an alert. In that case, the leader will not append that ECU data in a block. As a result, the corrupted data will not be appended in the Blockchain. We also plan to implement the watcher in the cloud, which will monitor uploaded ECU data in the cloud and send an alert if the ECU data is compromised. BIBLIOGRAPHY 73

Bibliography

[1] Robert Abel. Thieves ﬁnd a new way to steal Teslas and may have stolen as many as nine Teslas within a week. https://www.scmagazine.com/thieves-circumvent- tesla-gps-to-steal-at-least-nine-cars-in-a-week/article/676151/, 2017. [Online]

[accessed 10-June-2018]. [Cited on page(s):3 ]

[2] Michael Abramaowicz. Cryptocurrency-based law. Ariz. L. Rev., 58:359, 2016.

[Cited on page(s):6 and 16 ]

[3] Syreeta Bath and Sachin Shinde. Ethernet journey at Jaguar Land Rover. https://vector.com/portal/medien/cmc/events/commercial events/ Automotive Ethernet Symposium vAES17/pdf/vAES17 02 Ethernet-Journey-

JLR Bath Shinde.pdf, 2017. [Online] [accessed 10-June-2018]. [Cited on page(s):

12 and 43]

[4] Ray Beaulieu, Stefan Treatman-Clark, Douglas Shors, Bryan Weeks, Jason Smith, and Louis Wingers. The simon and speck lightweight block ciphers. In

52nd Design Automation Conference (DAC), pages 1–6. IEEE, 2015. [Cited on

page(s): 14]

[5] Evangelos Benos, Rod Garratt, and Pedro Gurrola-Perez. The economics of

distributed ledger technology for securities settlement. 2017. [Cited on page(s): 16] BIBLIOGRAPHY 74

[6] Daniel Julius Bernstein. Salsa20 speed. Technical report, 2005. [Cited on page(s):

44]

[7] Daniel Julius Bernstein. Chacha, a variant of salsa20. In Workshop Record of

SASC, volume 8, pages 3–5, 2008. [Cited on page(s): 14, 44, and 70]

[8] Daniel Julius Bernstein. The salsa20 family of stream ciphers. In New stream

cipher designs, pages 84–97. Springer, 2008. [Cited on page(s): 14]

[9] Daniel Julius Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, and Bo-Yin Yang. High-speed high-security signatures. Journal of Cryptographic Engineer-

ing, 2(2):77–89, 2012. [Cited on page(s): 15, 45, and 70]

[10] Amit S Bhala, Vivek P Kshirsagar, Meghana B Nagori, and Mandar K Desh- mukh. Performance comparison of elliptical curve and rsa digital signature on arm7. In International Conference on Information and Network Technology

(IPCSIT), volume 4, pages 58–62, 2011. [Cited on page(s):5 ]

[11] Nicole Bogart. Nissan has disabled NissanConnect EV app after claims in-car system could be hacked. https://globalnews.ca/news/2540277/nissan-leaf-app- disabled-after-claims-in-car-system-could-be-hacked/, 2016. [Online] [accessed

10-June-2018]. [Cited on page(s):3 ]

[12] Andrey Bogdanov, Lars R Knudsen, Gregor Leander, Christof Paar, Axel Poschmann, Matthew JB Robshaw, Yannick Seurin, and Charlotte Vikkelsoe. Present: An ultra-lightweight block cipher. In International Workshop on Cryp-

tographic Hardware and Embedded Systems, pages 450–466. Springer, 2007. [Cited

on page(s): 14] BIBLIOGRAPHY 75

[13] Robert Bosch. Can speciﬁcation version 2.0. Rober Bousch GmbH, Postfach,

300240:72, 1991. [Cited on page(s):3 ]

[14] Amy Castor. A (short) guide to Blockchain consensus protocols. https://www. coindesk.com/short-guide-blockchain-consensus-protocols/, 2017. [Online] [ac-

cessed 10-June-2018]. [Cited on page(s): 46]

[15] Mumin Cebe, Enes Erdin, Kemal Akkaya, Hidayet Aksu, and Selcuk Uluagac. Block4forensic: An integrated lightweight blockchain framework for forensics

applications of connected vehicles. arXiv preprint arXiv:1802.00561, 2018. [Cited

on page(s):5 and 22 ]

[16] Miguel Leon Chavez, Carlos Hernandez Rosete, and Francisco Rodriguez Hen- riquez. Achieving conﬁdentiality security service for can. In 15th International Conference on Electronics, Communications and Computers, pages 166–170.

IEEE, 2005. [Cited on page(s): 18]

[17] 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. San Francisco, 2011. [Cited on page(s):

[18] Amy Clements. Next generation vehicle Ethernet emerges as communications platform for next generation of vehicles. https://blog.zuken.com/ethernet-for-

vehicles/, 2017. [Online] [accessed 10-June-2018]. [Cited on page(s): 43] BIBLIOGRAPHY 76

[19] Linux Command. Syntax for Secure Copy (scp). http://www.hypexr.org/linux

scp help.php, 2018. [Online] [accessed 10-June-2018]. [Cited on page(s): 56]

[20] CoreOS. ETCD - a distributed reliable key-value store. https://github.com/

coreos/etcd, 2017. [Online] [accessed 10-June-2018]. [Cited on page(s): 22]

[21] Fabrizio De Santis, Andreas Schauer, and Georg Sigl. Chacha20-poly1305 au- thenticated encryption for high-speed embedded iot applications. In Design, Automation & Test in Europe Conference & Exhibition (DATE), pages 692–697.

IEEE, 2017. [Cited on page(s): 44]

[22] Docker Documentation. What is a Docker container. https://www.docker.com/

what-container, 2017. [Online] [accessed 10-June-2018]. [Cited on page(s): 52]

[23] Ali Dorri, Salil S Kanhere, Raja Jurdak, and Praveen Gauravaram. Blockchain for iot security and privacy: The case study of a smart home. In International Conference on Pervasive Computing and Communications Workshops (PerCom

Workshops), pages 618–623. IEEE, 2017. [Cited on page(s): 21]

[24] Ali Dorri, Marco Steger, Salil S Kanhere, and Raja Jurdak. Blockchain: A distributed solution to automotive security and privacy. arXiv preprint

arXiv:1704.00073, 2017. [Cited on page(s):5, 21, and 46 ]

[25] Mahmoud Hashem Eiza and Qiang Ni. Driving with sharks: Rethinking connected vehicles with vehicle cybersecurity. IEEE Vehicular Technology Magazine,

12(2):45–51, 2017. [Cited on page(s): 64] BIBLIOGRAPHY 77

[26] Electrek. Keen lab hackers managed to take control of tesla vehicles again. https://electrek.co/2017/07/28/tesla-hack-keen-lab/, 2016. [Online] [accessed

10-June-2018]. [Cited on page(s):3 ]

[27] Taher ElGamal. A public key cryptosystem and a signature scheme based on discrete logarithms. IEEE transactions on information theory, 31(4):469–472,

1985. [Cited on page(s): 14]

[28] Entefy. Bitcoin mining consumes more power than 82 percent of countries. https://www.entefy.com/blog/post/552/bitcoin-mining-consumes-more-

power-than-82-of-countries, 2018. [Online] [accessed 10-June-2018]. [Cited on

page(s): 46]

[29] Peter Fairley. The ridiculous amount of energy it takes to run Bitcoin. https://spectrum.ieee.org/energy/policy/the-ridiculous-amount-of-

energy-it-takes-to-run-bitcoin, 2017. [Online] [accessed 10-June-2018]. [Cited

on page(s): 46]

[30] Martin Fuchs, Patrick Scheer, and Andreas Grzemba. Selektiver teilnetzbetrieb im fahrzeug: Eine realisierung f¨urden can-bus und adaption auf andere bussys-

teme. GMM-Fachbericht-AmE Automotive Meets Electronics, 2010. [Cited on

page(s): 12]

[31] Motius GmbH. Proof of elapsed time, Intel’s SGX and the Internet of things. https://www.motius.de/en/2018/02/02/proof-of-elapsed-time-intels-

sgx-and-the-internet-of-things/, 2018. [Online] [accessed 10-June-2018]. [Cited

on page(s): 47] BIBLIOGRAPHY 78

[32] Marek Goldmann. Resource management in Docker. https://goldmann.pl/blog/ 2014/09/11/resource-management-in-docker/, 2014. [Online] [accessed 10-June-

2018]. [Cited on page(s): 54]

[33] Andy Greenberg. Hackers remotely kill a jeep on the highway. https:// www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/, 2015. [Online]

[accessed 10-June-2018]. [Cited on page(s):2,4, and 64 ]

[34] Andre Groll and Christoph Ruland. Secure and authentic communication on existing in-vehicle networks. In Intelligent vehicles symposium, pages 1093–1097.

IEEE, 2009. [Cited on page(s): 19]

[35] Nils Gura, Arun Patel, Arvinderpal Wander, Hans Eberle, and Sheueling Chang Shantz. Comparing elliptic curve cryptography and rsa on 8-bit cpus. In In- ternational workshop on cryptographic hardware and embedded systems, pages

119–132. Springer, 2004. [Cited on page(s): 45]

[36] IANIX. Chacha usage and deployment. https://ianix.com/pub/chacha-

deployment.html, 2018. [Online] [accessed 10-June-2018]. [Cited on page(s): 44]

[37] IANIX. Things that use Ed25519. https://ianix.com/pub/ed25519-deployment.

html, 2018. [Online] [accessed 10-June-2018]. [Cited on page(s): 46]

[38] Ali Al Imem. Comparison and evaluation of digital signature schemes employed

in ndn network. arXiv preprint arXiv:1508.00184, 2015. [Cited on page(s):5 and 15 ]

[39] Don Johnson, Alfred Menezes, and Scott Vanstone. The elliptic curve digital signature algorithm (ecdsa). International journal of information security,

1(1):36–63, 2001. [Cited on page(s): 15] BIBLIOGRAPHY 79

[40] Gary C Kessler. An overview of cryptography: Cryptographic. HLAN, ver,

1:1999–2014, 2014. [Cited on page(s): 45]

[41] Nam Ho Kim, Sun Moo Kang, and Choong Seon Hong. Mobile charger billing system using lightweight blockchain. In 19th Asia-Paciﬁc Network Operations

and Management Symposium (APNOMS), pages 374–377. IEEE, 2017. [Cited on

page(s): 21]

[42] Karl Koscher, Alexei Czeskis, Franziska Roesner, Hovav Patel, et al. Experimen- tal security analysis of a modern automobile. In IEEE Symposium on Security

and Privacy (SP), pages 447–462. IEEE, 2010. [Cited on page(s): 63 and 64]

[43] Kai Kr¨amerand Sam Hartnett. When it comes to throughput, transactions per second is the wrong blockchain metric. https://energyweb.org/2018/05/10/ when-it-comes-to-throughput-transactions-per-second-is-the-wrong-blockchain-

metric/, 2018. [Online] [accessed 10-June-2018]. [Cited on page(s): 48]

[44] Benjamin Leiding, Parisa Memarmoshreﬁ, and Dieter Hogrefe. Self-managed and blockchain-based vehicular ad-hoc networks. In 2016 ACM International Joint Conference on Pervasive and Ubiquitous Computing, pages 137–140. ACM, 2016.

[Cited on page(s): 20]

[45] Cliﬀord Liem, Eslam Abdallah, Chidinma Okoye, John O’Connor, Md Swaw- ibe Ul Alam, and Stacy Janes. Runtime self-protection in a trusted blockchain-

inspired ledger. ESCAR EUROPE, 2017. [Cited on page(s): 22 and 55]

[46] Rainer Link. High visibility can mean high risk, is your car broadcasting too much information? https://blog.trendmicro.com/trendlabs-security-intelligence/is- BIBLIOGRAPHY 80

your-car-broadcasting-too-much-information/, 2015. [Online] [accessed 10-June-

2018]. [Cited on page(s):2 ]

[47] V´ıctorGayoso Mart´ınez,Luis Hern´andezEncinas, and Carmen S´anchez Avila.´ A survey of the elliptic curve integrated encryption scheme. ratio, 80(1024):160–

223, 2010. [Cited on page(s): 14 and 70]

[48] Kirsten Matheus and Thomas K¨onigseder. Automotive ethernet. Cambridge

University Press, 2017. [Cited on page(s): 10, 11, and 12]

[49] Trent McConaghy, Rodolphe Marques, Andreas M¨uller,Dimitri De Jonghe, Troy McConaghy, Greg McMullen, Ryan Henderson, Sylvain Bellemare, and Alberto Granzotto. Bigchaindb: a scalable blockchain database. white paper,

BigChainDB, 2016. [Cited on page(s): 16]

[50] Andrew Medal. These 6 industries are using Blockchain to gain a competitive advantage. https://www.entrepreneur.com/article/311164, 2018. [Online] [ac-

cessed 10-June-2018]. [Cited on page(s): 16]

[51] Hans-Ulrich Michel, Dirk Kaule, and Martin Salfer. Vision einer intelligenten

vernetzung. Elektronik automotive, 2012. [Cited on page(s): 12]

[52] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. 2008. [Cited

on page(s): 16, 17, and 46]

[53] Dennis K Nilsson, Ulf E Larson, and Erland Jonsson. Eﬃcient in-vehicle delayed data authentication based on compound message authentication codes. In IEEE

68th Vehicular Technology Conference, pages 1–5. IEEE, 2008. [Cited on page(s):

18] BIBLIOGRAPHY 81

[54] Dennis K Nilsson, Ulf E Larson, Francesco Picasso, and Erland Jonsson. A ﬁrst simulation of attacks in the automotive network communications protocol ﬂexray. In International Workshop on Computational Intelligence in Security for

Information Systems (CISIS), pages 84–91. Springer, 2009. [Cited on page(s): 43]

[55] Thomas Nolte. Share-driven scheduling of embedded networks. PhD thesis, In-

stitutionen f¨orDatavetenskap och Elektronik, 2006. [Cited on page(s): 11]

[56] Nominet. How elliptic curve cryptography encryption works. https://www. nominet.uk/researchblog/how-elliptic-curve-cryptography-encryption-works/,

2018. [Online] [accessed 10-June-2018]. [Cited on page(s): 32]

[57] NXP. In-vehicle network Ethernet. https://www.nxp.com/products/analog/ interfaces/in-vehicle-network/ethernet:MC 1436432488692, 2018. [Online] [ac-

cessed 10-June-2018]. [Cited on page(s): 43]

[58] Karl J O’Dwyer and David Malone. Bitcoin mining and its energy footprint.

2014. [Cited on page(s): 46]

[59] Hisashi Oguma, Akira Yoshioka, Makoto Nishikawa, Rie Shigetomi, Akira Ot- suka, and Hideki Imai. New attestation based security architecture for in-vehicle communication. In Global Telecommunications Conference, pages 1–6. IEEE,

2008. [Cited on page(s): 18]

[60] Raspberry Pi Organization. Operating systems of Raspberry Pi. https://www.

raspberrypi.org/downloads/, 2018. [Online] [accessed 10-June-2018]. [Cited on

page(s): 55] BIBLIOGRAPHY 82

[61] Raspberry Pi Organization. Raspberry Pi 3 model B plus. https://www. raspberrypi.org/products/raspberry-pi-3-model-b-plus/, 2018. [Online] [ac-

cessed 10-June-2018]. [Cited on page(s): 55]

[62] Lothar Pantel and Lars C Wolf. On the impact of delay on real-time multiplayer games. In 12th international workshop on Network and operating systems support

for digital audio and video, pages 23–29. ACM, 2002. [Cited on page(s): 65]

[63] The Statistics Portal. Automotive electronics cost as a percentage of total car cost worldwide from 1950 to 2030. https://www.statista.com/statistics/277931/ automotive-electronics-cost-as-a-share-of-total-car-cost-worldwide/, 2017. [On-

line] [accessed 10-June-2018]. [Cited on page(s):1 ]

[64] Mehrnoush Rahmani, Rainer Steﬀen, Ktawut Tappayuthpijarn, Eckehard Stein- bach, and Giuseppe Giordano. Performance analysis of diﬀerent network topolo- gies for in-vehicle audio and video communication. In 4th International Telecom- munication Networking Workshop on QoS in Multiservice IP Networks, pages

179–184. IEEE, 2008. [Cited on page(s): 65]

[65] Dominik Reinhardt and Markus Kucera. Domain controlled architecture-a new approach for large scale software integrated automotive systems. PECCS, 13:221–

226, 2013. [Cited on page(s): 10]

[66] Renesas. Renesas oﬀers a lineup of R-Car systems-on-chip for automotive appli-

cations. [Online] [accessed 10-June-2018]. [Cited on page(s): 55] BIBLIOGRAPHY 83

[67] Ronald L Rivest, Adi Shamir, and Leonard Adleman. A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM,

21(2):120–126, 1978. [Cited on page(s): 14 and 15]

[68] Maryam Savari, Mohammad Montazerolzohour, and Yeoh Eng Thiam. Com- parison of ecc and rsa algorithm in multipurpose smart card application. In International Conference on Cyber Security, Cyber Warfare and Digital Foren-

sic (CyberSec), pages 49–53. IEEE, 2012. [Cited on page(s): 45]

[69] Gurpreet Singh. A study of encryption algorithms (rsa, des, 3des and aes) for information security. International Journal of Computer Applications, 67(19),

2013. [Cited on page(s): 45]

[70] Madhusudan Singh and Shiho Kim. Intelligent vehicle-trust point: Reward based intelligent vehicle communication using blockchain. arXiv preprint

arXiv:1707.07442, 2017. [Cited on page(s): 21]

[71] NIST-FIPS Standard. Announcing the advanced encryption standard (aes).

Federal Information Processing Standards Publication, 197:1–51, 2001. [Cited

on page(s): 14]

[72] Rainer Steﬀen, Richard Bogenberger, Mehrnoush Rahmani, Joachim Hillebrand, Wolfgang Hintermaier, and Andreas Winckler. Design and realization of an ip- based in-car network architecture. In The First Annual International Symposium

on Vehicular Computing Systems, 2008. [Cited on page(s): 65] BIBLIOGRAPHY 84

[73] Tomoyasu Suzaki, Kazuhiko Minematsu, Sumio Morioka, and Eita Kobayashi. Twine: A lightweight, versatile block cipher. In ECRYPT Workshop on

Lightweight Cryptography, 2011. [Cited on page(s): 14]

[74] Tcpdump. TCPDUMP. https://www.tcpdump.org/tcpdump man.html, 2018.

[Online] [accessed 10-June-2018]. [Cited on page(s): 57]

[75] Neousys Technology. In-vehicle computing products. https://www.neousys- tech.com/en/product/application/in-vehicle-computing/, 2018. [Online] [ac-

cessed 10-June-2018]. [Cited on page(s): 49]

[76] Jonas Toreskaas. Ecc vs. rsa. 2015. [Cited on page(s): 45]

[77] Shane Tuohy. Hybrid simulation of ethernet based intra-vehicle networks. PhD

thesis, 2016. [Cited on page(s): 43]

[78] Uconnect. Uconnect Access. https://www.driveuconnect.com/, 2018. [Online]

[accessed 10-June-2018]. [Cited on page(s):2 and4 ]

[79] Chris Valasek and Charlie Miller. Adventures in automotive networks and control units. https://www.ioactive.com/pdfs/IOActive Adventures in Automotive Networks and Control Units.pdf, 2014. [Online] [accessed 10-June-

2018]. [Cited on page(s):9 ]

[80] Imperial Violet. TLS Symmetric Crypto. https://www.imperialviolet.org/2014/

02/27/tlssymmetriccrypto.html, 2014. [Online] [accessed 10-June-2018]. [Cited

on page(s): 44] BIBLIOGRAPHY 85

[81] Bitcoin Wiki. SHA-256 is used in the creation of bitcoin addresses to improve security and privacy. https://en.bitcoin.it/wiki/SHA-256, 2016. [Online] [accessed

10-June-2018]. [Cited on page(s): 39]

[82] Wikipedia. Round-robin scheduling. https://en.wikipedia.org/wiki/Round-

robin scheduling, 2018. [Online] [accessed 10-June-2018]. [Cited on page(s):6,

37, and 41]

[83] Marko Wolf, Andr´eWeimerskirch, and Christof Paar. Secure in-vehicle commu-

nication. In Embedded Security in Cars, pages 95–109. Springer, 2006. [Cited on

page(s): 19 and 43]

[84] Gavin Wood. Ethereum: A secure decentralised generalised transaction ledger.

Ethereum Project Yellow Paper, 151, 2014. [Cited on page(s): 16 and 46]

[85] Xtrabytes. Proof-of-Work is draining the grid. https://blog.xtrabytes.global/

technology/proof-of-work/, 2018. [Online] [accessed 10-June-2018]. [Cited on

page(s): 17]

[86] Eric Yuan and Jin Tong. Attributed based access control (abac) for web services.

In International Conference on Web Services. IEEE, 2005. [Cited on page(s): 15]

[87] Guy Zyskind and Oz Nathan. Decentralizing privacy: Using blockchain to protect personal data. In Security and Privacy Workshops (SPW), pages 180–184.

IEEE, 2015. [Cited on page(s):6 and 46 ]