SecuringVehicleElectronicControlUnitECUCommunicationsandStoredData PDF

See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/327828954
Securing Vehicle Electronic Control Unit (ECU) Communications and Stored

Data
Thesis · September 2018
CITATION READS
1 4,771
1 author:
Md Swawibe Ul Alam
Queen's University
7 PUBLICATIONS 2 CITATIONS
SEE PROFILE
All content following this page was uploaded by Md Swawibe Ul Alam on 23 September 2018.
The user has requested enhancement of the downloaded file.

Securing Vehicle Electronic Control Unit
(ECU) Communications and Stored Data
by
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
Copyright
c Md Swawibe Ul Alam, 2018
Abstract
Nowadays, the automobile industry is integrating many new features into vehicles.
To provide these features, various electronic systems are being added. These sys-
tems 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 commu-
nications 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
modified.
We implement the proposed technique in two platforms, namely Docker and the
ARM architecture-based Raspberry Pi Board. Our experiments show that the pro-
posed technique can improve security in ECU communications. The watcher reports
when an ECU data is modified which helps limit the damage when an ECU is com-
promised.
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. Clifford Liem for his guidance to my research
during my internship and Dr. Shahrear Iqbal for his motivation during my experi-
ments. 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 effort.
iii
Contents
Abstract i
Acknowledgements iii
Contents iv
List of Figures vii
List of Tables ix
Chapter 1: Introduction 1
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 Work 9

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 Confidentiality . . . . . . . . . . . . . . . . . . . . . . . 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 Falsification . . . . . . . . . . . . . . . . 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 pro-

posed 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 verified. . . . . . . 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 Specification . . . . . . . . . . . . . . . . . . . . . . . . 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 communi-
cation 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 firmware 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 wifi
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 communi-
cations 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 confidentiality, integrity, and authen-
ticity 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 secu-
rity 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 ve-
hicle 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 sce-
nario, 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 commu-
nications, 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 en-
sures 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 communica-
tion 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 7
1
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 confidentially.
• 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 com-

munications.
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 Chapter 2, 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.
• Chapter 3 begins by describing the proposed approach. Then, we present the

major challenges of this work.
• In Chapter 4, 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.
• Chapter 5 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 first, 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), in-
put 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 different buses depending
on application areas. Some of these buses are CAN, CAN-FD, LIN, MOST, FlexRay,
60 2.2. IN-VEHICLE E/E-ARCHITECTUREElectronic automotive systems
11
Diagnose
Gateway
K-CAN MOST K-CAN SI-BUS PT-CAN

System Periphery (Byteflight)
Figure 2.1: In-vehicle E/E-architecture of BMW 7 series [55].

Figure 3.3: Network infrastructure of BMW 7 series.
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,
bus format.
although Moreover, the
the differences gateway
among CAN directly handlesare,
networks inter-ECU communications.
for example, As
their different
speeds (100
a result, theKbps andmust
gateway 500deal
Kbps).
with aFor chassis
large and powertrain
communication systems,
load because “CAN
data among
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
architecture contains different types of data buses (e.g., K-CAN System, MOST, K-
3.5.4 Subsystem integration
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
VWbuses are connected
Passat has aroundthrough the central
45. Also, 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 simplifies 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
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 function-
alities. 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 archi-
tecture, 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 en-
cryption 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 symmet-
ric key. Symmetric key cryptography provides confidentiality, 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 verified. 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 configure 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 fields. 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 ex-
plained 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
briefly 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 first, 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 first
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
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 secu-
rity. 1) Authentication mechanism by the gateway: the gateway verifies every con-
troller (MECU) by a public key certificate issued by the manufacturer. The gateway
manages encryption keys for the encryption in sub-networks. 2) Encrypted commu-
nications: 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:
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 pro-
posed 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 fire-
wall 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).
In their work, they propose to use Ethereum’s smart contract for traffic 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 commu-
nications using Blockchain. Their main idea is to share the data among intelligent
vehicles by implementing Blockchain-based trust environment. Initially, they trans-
mit 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 algo-
rithm 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 re-
mote software update, car-sharing services, and an electric vehicle’s charging services.
They use Blockchain in the V2I and V2V communications.
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 man-
ufacturers, 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 cen-
ters, 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 different 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 first, 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 com-
munication 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 confidentiality, 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 MECU  Holds the Blockchain
ECU
 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 first 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/reques-
tee ECU UID, public verification key, and the common shared key between requester
and requestee.
Table 3.1: Request List.
Public Verification 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 permis-
sion to communicate with another ECU, an MECU checks the ‘Permission List’. If
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 verifies 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
... ...
... ...
Secure Communications and Data Transfer
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
5 MECU1 sends request accepted key & stores ECU1’s details in
encrypted common shared
6 Decrypts common notification with details of ECU2 key
the Request List
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 communica-
tions between ECU1 and ECU2. All communications are transmitted with a digital
signature. However, signing and verification of the digital signature are not depicted
in the figure. 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 verifies 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
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 verifies the signature of ECU1. If the signature is verified, then ECU2
checks the entry of ECU1 in its ‘Request List’. Then ECU2 encrypts the data
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 verifies the digital signature of ECU2. If the
signature is verified, 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.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 verifies 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 from
SECURING VEHICLE an
ECU ECU to an MECU33
COMMUNICATIONS
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 verifies the digital signature of the ECU.
If the signature is verified, the MECU processes the data transaction.
7. The MECU sends a ‘Data Received’ acknowledgment to the ECU with its digital
signature.
8. The ECU verifies the acknowledgment of the MECU. After the verification, the
ECU releases its storage for the future use.
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 band-
width. 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 verifies (checks integrity and
authenticity) those. If an ECU transaction cannot be verified, 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
Start
Text
YES M*N ECU NO
transactions
verified?
Select leader among

M MECUs
MECU sends signed MECU sends signed
'Block Accepted' 'Block Rejected'
notification to the leader notification to the leader
Leader sends signed

`Send Data' request
to other M-1 MECUs
Leader verifies (M-1) `Block
Accepted/Rejected' notifications
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 verification NO Percentage of 'Block YES
Accepted' > Block
Acceptance Rate?
MECUs verify
leader's sign and
M*N ECU
transactions The Block is accepted and
The Block is Rejected
appended in Blockchain
End
Figure 3.5: The process of storing data in the Blockchain.

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’
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 ab8f21ebdd… 1529938741.12
10001111 1101 65f8037786… 1529938783.34
1001… 1001 10001000 1529938802.31 98e9699d…
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
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.
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…

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 different than this value is considered as altered. This decision-making
rule is called the majority rule. Therefore, the watcher can make an appropriate
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 com-
promised 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.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 compro-
mised 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 commu-
nication 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.2 Choosing the Symmetric Key Cryptography
We use symmetric key cryptography to send data confidentially. 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 efficient 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.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 different
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 verification.

• It provides faster batch verification and we need a faster batch verification 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 benefits, 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
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
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 through-
put 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 configured 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 confidentiality, 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 first, we conduct our experi-
ments 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 modified by a compromised MECU or the leader. The details of
the block verification 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 flexible. 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 files, 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.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,
Table 4.1: Host Machine Specification
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 configured [32].
Therefore, we configure 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 sup-
ports 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 com-
puting 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 specifications
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 verifi-
cation 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 gener-
ated 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 Confidentiality
In this experiment, ECU1 makes the ‘Communication Request’ to MECU1 for com-
municating 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.

Figure 4.4 shows the encrypted data field 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
and signature. As a result, ECU1 declines the data. It confirms 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 verified.
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 ac-
cess 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 find
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
from MECU1. On the contrary, this situation is different when the ‘Permission List’
is integrated. We change the ‘Permission List’ in a way so that ECU3 can communi-
cate 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 per-
mission, 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.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 modifications 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.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 Falsification
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 dis-
aster. 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.
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.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 verifies the signature, encrypts data, and sends to
the ECU1 with its signature. ECU1 verifies the signature and decrypts the data. At
512K 11.18
256K 6.204
128K 3.674
64K 3.272
32K 3.085
16K 2.756
8K 2.592
Data Size (in byte)
4K 2.28
2K 2.023
1K 1.612
512 1.497
256 1.406
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
32K 10.10342
16K 8.64592
8K 7.68132
4K 7.20432
2K 6.93932
Data Size (in byte)
1K 6.6947
512 6.4943
256 6.48842
128 6.48533
64 6.4745
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 difference is the processor speed.
The Docker containers are configured 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 confidentiality, 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, verification,
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 pro-
posed 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 ac-
cess 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 confi-
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 find 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 specification 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 confidentiality 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):
4]
[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.
[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 con-
nected 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
[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 coun-
tries. 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 für den 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.
[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 digi-
tal 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-Pacific 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 Krämer and 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 Memarmoshrefi, 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] Clifford 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-

[47] Vı́ctor Gayoso Martı́nez, Luis Hernández Encinas, and Carmen Sánchez Ávila.
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 Königseder. Automotive ethernet. Cambridge

University Press, 2017. [Cited on page(s): 10, 11, and 12]
[49] Trent McConaghy, Rodolphe Marques, Andreas Müller, 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-
[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. Efficient 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
first simulation of attacks in the automotive network communications protocol
flexray. 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 för Datavetenskap 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-
[58] Karl J O’Dwyer and David Malone. Bitcoin mining and its energy footprint.
[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,
[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-
[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 Steffen, Ktawut Tappayuthpijarn, Eckehard Stein-

bach, and Giuseppe Giordano. Performance analysis of different 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 offers 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),
[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 Steffen, 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-
[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 and 4]
[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-
[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 se-
curity and privacy. https://en.bitcoin.it/wiki/SHA-256, 2016. [Online] [accessed
[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, André Weimerskirch, 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 pro-
tect personal data. In Security and Privacy Workshops (SPW), pages 180–184.
IEEE, 2015. [Cited on page(s): 6 and 46]
View publication stats

SecuringVehicleElectronicControlUnitECUCommunicationsandStoredData PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

SecuringVehicleElectronicControlUnitECUCommunicationsandStoredData PDF

Transféré par

Droits d'auteur :

Formats disponibles

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

Securing Vehicle Electronic Control Unit (ECU) Communications and Stored

Thesis · September 2018

The user has requested enhancement of the downloaded file.

A thesis submitted to the

I am grateful to my supervisor Professor Mohammad Zulkernine for his continu-

List of Figures vii

Chapter 2: Background and Related Work 9

Chapter 3: ECU Communications and Data Security 25

Chapter 4: Implementation and Evaluation 50

Chapter 5: Conclusion and Future Work 70

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

2.1 In-vehicle E/E-architecture of BMW 7 series. . . . . . . . . . . . . . . 11

3.1 The domain-based in-vehicle architecture after integrating the pro-

4.1 Docker container setup. . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.1 Request List. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1 Host Machine Specification . . . . . . . . . . . . . . . . . . . . . . . . 54

1.2 Problem Overview

1.3 Overview of the Proposed Approach

1. Requesting communication permission 5. Verifying integrity and authenticity

Figure 1.1: Overview of the proposed approach.

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

• We propose a method to use the elliptic curve-based digital signature among

• We integrate an identity-based access control in MECUs to control ECU com-

• 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

1.5 Organization of the Thesis

The remainder of this thesis is organized as follows:

• In Chapter 2, we discuss the background information regarding this work and

• Chapter 3 begins by describing the proposed approach. Then, we present the

• In Chapter 4, we present the implementation details. This is followed by the

Background and Related Work

2.1 Electronic Control Unit (ECU)

An ECU is an embedded computer in vehicles to control mechanical or electronic

2.1.1 Mother ECU (MECU)

2.2 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

K-CAN MOST K-CAN SI-BUS PT-CAN

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

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

ECU ECU ECU ECU ECU ECU

ECU ECU ECU ECU ECU ECU

ECU ECU ECU ECU ECU ECU

ECU ECU ECU ECU ECU ECU

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

2.3.1 Symmetric Key Cryptography

2.3.2 Public Key Encryption (PKE)

2.3.3 Digital Signature

2.4 Identity-Based Access Control

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

Blockchain is a special kind of Distributed Ledger. Distributed Ledger Technology

2.5.1 The Use of Blockchain in Bitcoin

Genesis block block block Most recent block

Figure 2.3: Basic structure of a Bitcoin block.

In Bitcoin, every block contains multiple chronologically sorted transactions, a

2.6 Related Work

2.6.1 In-Vehicle Communication Security

There are many works related to in-vehicle communication security. However, we

2.6.2 Use of Blockchain in Vehicles

In 2018, Cebe et al. [15] propose Blockchain-based framework to manage vehicle-

In this chapter, some important background information is explained before proceed-

while we use Blockchain to protect ECU data.