Linköpings universitet SE–581 83 Linköping
Linköping University | Department of Computer and Information Science
Master’s thesis, 30 ECTS | Computer Science
2018 | LIU-IDA/LITH-EX-A--2018/010--SE
Decentralized firmware
attes-tation for in-vehicle networks
–Mohammad Khodari
Supervisor : Mikael Asplund Examiner : Andrei Gurtov
Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admin-istrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circum-stances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the con-sent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.
c
Abstract
Today’s vehicles are controlled by several so called electronic control units (ECUs). ECUs can be seen as small computers that work together in order to perform a common task. They control everything from critical tasks such as engine control to less critical function-ality such as window control. The most prominent trend that can be observed today is the development of self-driving functionality. Due to inherent complexity of self-driving functionality, ECUs are becoming more dependent on each other. A fundamental problem in today’s vehicles is that there does not exist any efficient way of achieving trust in the vehicle’s internal-network. How can ECUs be assured that the output of other ECUs can be trusted? If an ECU produces the wrong output when the vehicle is in autonomous mode it can lead to the vehicle performing unsafe actions and risking the lives of the passengers and driver.
In this thesis we evaluate different already established firmware attestation solutions for achieving trust in a decentralized network. Furthermore, three new firmware attestation solutions specially tailored for the automotive domain are proposed. We demonstrate that all the found existing solutions have a fundamental flaw, they all have a single point of failure. Meaning that if you eliminate the correct node, the entire attestation process stops functioning. Thus, a new more robust solution specially tailored for the automotive domain needed to be developed. Three different consistency verification mechanisms were designed. One parallel solution, one serial solution and one merkle-tree solution. Two of the three proposed solutions, the parallel solution and serial solution, were imple-mented and assessed. Two tests were conducted, a detection performance test and a timing performance test.
By assessing the detection performance test and timing performance test of the serial and parallel solutions, it was concluded that the parallel solution showed a significant improve-ment in both stability and performance over the serial solution.
Contents
Abstract iii
Contents iv
List of Figures vi
List of Tables viii
1 Introduction 1 1.1 Motivation . . . 1 1.2 Aim . . . 2 1.3 Research questions . . . 2 1.4 Approach . . . 3 1.5 Delimitations . . . 3 2 Theory 4 2.1 Cryptography . . . 4
2.2 Decentralized cryptographic solutions . . . 8
2.3 Vehicle architecture . . . 9
2.4 Automotive communication protocols . . . 9
2.5 Automotive supply chain . . . 13
2.6 Distributed control architecture in Scania’s trucks . . . 14
2.7 Firmware Over-The-Air (FOTA) . . . 15
2.8 Known in-vehicle network vulnerabilities and proposed solutions . . . 16
2.9 ECU security classes . . . 19
2.10 Metrics . . . 20
3 Literature study 22 3.1 Search strategy . . . 22
3.2 Study selection . . . 23
3.3 Study quality assessment . . . 23
3.4 Related Work . . . 23
4 Consistency verification mechanism 29 4.1 Overview . . . 29
4.2 ECU security level . . . 29
4.3 Design . . . 30
4.4 Proposed solutions . . . 36
5 Security analysis and comparison 45 5.1 Spoofing identity . . . 45
5.2 Tampering with data . . . 46
5.4 Information disclosure . . . 47 5.5 Denial of service . . . 47 5.6 Elevation of privilege . . . 47 5.7 Summary . . . 48 6 Evaluation 49 6.1 Metrics . . . 49 6.2 Test setup . . . 51 6.3 Detection performance . . . 54 6.4 Timing performance . . . 55 7 Discussion 60 7.1 Results . . . 60 7.2 Method . . . 60 8 Conclusion 63 Bibliography 65 A Serial and parallel implementations in detail 68 A.1 Serial solution . . . 68
A.2 Parallel solution . . . 69
List of Figures
2.1 Symmetric key cryptography . . . 5
2.2 Message authentication code (MAC) . . . 6
2.3 Asymmetric key cryptography . . . 6
2.4 Digital signature . . . 7
2.5 Merkle Tree . . . 8
2.6 ecuReset diagnostic service request . . . 11
2.7 ecuReset diagnostic service positive response . . . 12
2.8 ecuReset diagnostic service negative response . . . 12
2.9 readDataByIdentifier diagnostic request and response . . . 13
2.10 Automotive supply chain . . . 13
2.11 CAN bus architecture in Scania trucks . . . 14
2.12 Firmware Over-The-Air (FOTA) . . . 15
2.13 Security classes . . . 20
3.1 New attestation protocol . . . 24
3.2 Remote attestation protocol . . . 26
3.3 Example of an advances metering infrastructure (AMI) network . . . 27
4.1 Generating hash-value from flash-memory . . . 30
4.2 ECU state verification . . . 31
4.3 ECU state signing . . . 32
4.4 Replay attack usage to bypass attestation process . . . 34
4.5 Architecture of the database . . . 37
4.6 ECU firmware update . . . 39
4.7 Serial solution’s attestation requests . . . 39
4.8 Parallel solution’s attestation request . . . 40
4.9 Dependency modeling of function x . . . 41
4.10 Artificial association tree with a maximum of two children for each node . . . 42
4.11 Dependency tree, sending attestation requests . . . 43
4.12 Tree consistency verification . . . 44
6.1 ECU to laptop USB interface for flashing firmware . . . 52
6.2 Test environment setup . . . 53
6.3 Key stored inside the database . . . 54
6.4 Result of the correctness test . . . 55
6.5 Result of the scalability test . . . 56
6.6 Result of the predictability test . . . 57
6.7 Processing of responses in serial solution . . . 58
6.8 Processing of responses in parallel solution . . . 58
A.1 Attestation request using readDataByIdentifier . . . 68
A.3 Attestation request using readDataByIdentifier . . . 69 A.4 Attestation response using readDataByIdentifier . . . 69 B.1 Result of the hashing test . . . 71
List of Tables
4.1 Comparison between the three expected state storage methods . . . 33 5.1 STRIDE results . . . 48
1
Introduction
1.1
Motivation
In the vehicle industry there has been some major advancements due to integration of in-creasingly advanced technologies. Vehicles are controlled by a large number of so called Electronic Control Units (ECUs). ECUs are specialized computers that perform everything from critical tasks such as engine control to less critical functionality such as window control. Many people see vehicles as “computers on wheels” [18] due to how dependent they are on ECUs.
A very prominent trend that can be observed today in relation to vehicles is the emergence of self-driving capabilities [7]. Companies such as Tesla have implemented rudimentary self-driving capabilities into their new cars. These self-driving capabilities enable the car to follow the current lane by analyzing data received from the car’s various sensors. It is tremendously important that such capabilities work as intended. The safety of passengers as well as the safety of other people on the road are at risk. A malfunction of critical components or manipulation of software or hardware in ECUs can cost people their lives. Therefore, it is very important that all ECUs in a vehicle are secure and that the software inside them cannot be tampered with, without being noticed.
An example of what the consequences of having insufficient security can be is the recent hack on the Tesla model X performed by Chinese researchers [32]. Even though Tesla introduced firmware code signing to prevent such malicious activity, the Chinese researchers managed to hack the vehicle remotely. By exploiting security holes in the car’s different ECUs, the Chinese researchers managed to open its doors, blink the lights, control the in-car display, surprisingly, also engage the breaks whilst the car was in motion. These kinds of security holes can be life threatening. Therefore, it is very important that OEMs (Original Equipment Manufacturers) or software developers responsible for the firmware of ECUs update the firmware on their vehicles when needed.
ECUs in vehicles used to only have ROM (read only memory). This meant that the firmware placed on the ECUs was not re-writable and therefore could not be updated. The ECUs in today’s vehicles have flash memory. Flash memory allows authorized entities to update or
1.2. Aim
flash a new version of the firmware. This enables the repair of bugs and security holes in the software itself. By updating the vehicle’s firmware and taking into account new exploits and vulnerabilities, the vehicle’s firmware can stay up-to-date.[23, 29] An ability to update the firmware can also have a negative effect. It will increase the attack surface present for various malicious actors. For example, a malicious actor can try to flash new malicious firmware on the vehicle or they can try to prevent a new update (which patches some vulnerability) from being flashed. Furthermore, most newer vehicles today have some sort of network connection for receiving firmware updates and other functionalities such as remotely locking and unlocking the vehicle’s doors. This introduces the potential of an unauthorized user taking control of the vehicle’s various functions remotely by for example taking advantage of known security holes.
Additionally, the ECUs in a vehicle are dependent on each other and they communicate with each other in order to perform a specific task. ECUs need to be able to trust each other, they must trust that the data that other ECUs supply them with are correct and have not been tampered with.
A common way of injecting trust into a network and into the nodes themselves is to utilize a so called Trusted platform module (TPM). TPM provides hardware-based security that can securely store sensitive information such as passwords and cryptographic keys. Furthermore, a TPM provides the means of measuring the integrity of software running on a node, by measuring the state of the boot loader, kernel and application. The state of the node provided by the TPM is represented by a hash-value which can be used to determine if a node in a network is in the correct/expected state. The TPM is an essential component for providing trust in a decentralized network.
1.2
Aim
The aim of this thesis project is to evaluate several different cryptographically secure dis-tributed solutions in order to determine if controllers in a vehicle are in a consistent state. This means that each ECU connected to the vehicle communication bus can attest that all other ECUs in the network are in a consistent/expected state by initiating the proposed solution.
Furthermore, the aim is to propose consistency verification solutions based on already es-tablished research, and to evaluate some of these solutions in terms of detection and timing performance in an emulated setting.
This assignment was carried out at Scania in Södertälje, Sweden which is a heavy truck and bus manufacturer.
1.3
Research questions
The following questions are going to be answered in the thesis:
1. What types of hardware and software requirements will the proposed consistency ver-ification mechanisms necessitate?
2. What is the detection performance of the implemented consistency verification mecha-nisms?
3. What is the timing performance of the implemented consistency verification mecha-nisms?
1.4. Approach
1.4
Approach
The approach used for solving the consistency verification problem is presented in the list below:
1. A literature study will be performed in order to find already established research on consistency verification and decentralization.
2. Based on the results from the literature study, three new consistency verification mecha-nisms are going to be proposed. Furthermore, the protocol design of the three proposed solutions are going to be presented showing how the ECUs will communicate with each other for attestation.
3. A subset of the proposed protocol designs will then be implemented on real ECUs for testing.
4. Two different tests are going to be performed on the implementations. One detection performance test and one timing performance test. The detection performance measures the success rate of detecting malicious/tampered nodes. Whereas the timing performance test measures the predictability and scalability of the two implemented solutions based on response-times.
1.5
Delimitations
There are a couple of assumptions made to emphasize the requirements needed for successful implementation of the three proposed solutions. These assumption are:
1. The attacker is able to change the firmware of ECUs at will.
2. Each ECU has trusted hardware and software extension installed for secure storage and integrity verification.
3. The three proposed solutions are only going to detect unauthorized manipulation of firmware and will not consider what actions to take after detection.
4. Only the content of the flash memory (non-volatile memory) will be attested. Verifica-tion of informaVerifica-tion/code stored in volatile memory will not be included in the proposed solutions.
2
Theory
This chapter introduces important concepts needed in order to fully understand the content of this thesis. The theory chapter is divided into ten sections: Cryptography, Decentralized cryptographic solutions, Vehicle architecture, Automotive communication protocols, Automotive supply chain, Distributed control architecture in Scania’s trucks, Firmware Over-The-Air (FOTA), Known-in vehicle network vulnerabilities and proposed solutions, ECU security classes and Metrics. The theory chapter presents different cryptographic solutions that can be used for securing messages transmitted between nodes. Furthermore, the basics of in-vehicle communication between ECUs are described. Moreover, in order to understand the shortcomings of vehicular security, common internal communication vulnerabilities in today’s vehicles are presented.
2.1
Cryptography
Cryptography is the study of secure communication and the practice of providing informa-tion security. The Greek word cryptography stands for "hidden writing". Cryptography can be seen as the study and practice of hiding messages from a third party also knowns as an adversary [16]. There are four main security goals or services that cryptographic techniques aim to provide. These security goals are:
1. Confidentiality: Is a means of keeping content of information secret from all unautho-rized entities. Thus only allowing authounautho-rized entities to read or access the protected information.
2. Data Integrity: Data integrity assures that the protected data cannot be altered by an unauthorized entity. Data integrity also encompasses the ability to detect unauthorized data alteration.
3. Authentication: Authentication can be seen as a method for communicating nodes to identify each other and also to assure that the received message’s content is correct/au-thentic. The idea is to authenticate the origin and the contents of messages received over a channel.
4. Non-repudiation: Prevents both communicating parties from denying their previous actions and commitments. For example a node should not be able to successfully deny
2.1. Cryptography
a previously authorized purchase. In such cases were there is a dispute between two parties, a trusted third party is needed to resolve such issues.
There exists three main categories of cryptography: Symmetric key cryptography, Public key cryptography and Unkeyed cryptography.
2.1.1
Symmetric key cryptography
In symmetric key cryptography two or multiple parties protect the messages sent between them using a so called symmetric key algorithm. The symmetric key algorithm is what transforms plain-text to and from cipher-text.
Alice
Encrypt DecryptBob
Key Key
Message
(Plaintext) Ciphertext Message(Plaintext)
Figure 2.1: Symmetric key cryptography
The algorithm takes two arguments: a message (plain-text or cipher-text) and a key, see figure 2.1. For plain-text encryption the algorithm takes the plain-text message and the key in order to produce the cipher-text message. Whereas, for cipher-text decryption the algorithm takes the cipher-text (encrypted message) and the key to produce the original message which was previously encrypted by the transmitting party.
The same message and key combination will always produce the same output. The key used for encryption and decryption is symmetric. Meaning that the key is the exact same for encryption as well as decryption. In order for two parties to communicate with each other using symmetric key cryptography, a symmetric key must be pre-distributed between them and stored securely. The security in symmetric key cryptography is dependent the confidentiality of the key. If a third party gets hold of the key, that party will also be able encrypt and decrypt messages, thus being able to read the messages sent between the two original parties. [16] Symmetric key cryptography can be seen as a safe. The safe has two identical keys for locking and unlocking the safe. The keys are given to two different entities that want to communicate with each other. When one of them wants to send a message to the other, that entity writes the message on a piece of paper, puts the message in the safe and then locks it. Then the second entity is notified that a message has arrived. The receiving entity goes to the safe, unlocks the safe and then the message is retrieved. Thus, the receiving party can now read the message. A third-party will not be able to open the safe and read the sent messages without having the secret key.
Message authentication code (MAC)
Message authentication code leverages from the fact that a combination between message and secret key in symmetric key encryption produces a "unique" cipher-text. This also means that if a different message and key combination is used a totally different cipher-text will be produced. Therefore, symmetric key encryption algorithms can also be used to ensure message integrity and data origin. This done by utilizing a so called MAC algorithm which takes a
2.1. Cryptography
message and a secret symmetric key and produces a MAC value. This MAC value is then used to assure that the message is authentic. [16]
Alice
AlgorithmMACBob
Key Message Ciphertext MAC Message MAC Algorithm Key Equal ?
Figure 2.2: Message authentication code (MAC)
Say, Alice wants to send a message to Bob, but they also want ensure that the sent message is authentic and that the message originated from Alice. So they decide to use a MAC for message authentication and they pre-distribute the symmetric key between them, see figure 2.2. This means that only Alice or Bob can produce a genuine MAC value. Alice takes the message she wants to send to Bob with the pre-distributed symmetric key and inserts them into the MAC algorithm. The MAC algorithm then produces the corresponding MAC value. Alice then takes the MAC value and the message (plain-text) and sends both of them to Bob. In turn, when Bob receives the message, consisting of the message (plain-text) and MAC-value, he takes the plain-text message with the pre-distributed key, inserts them into the MAC algorithm. He then takes the locally produced MAC-value by the MAC algorithm and compares it to the received MAC-value from Alice. If they are equal, then he is assured that the message originated from Alice and is authentic.
2.1.2
Public key cryptography
Public key cryptography separates the key used for encryption and decryption of messages. The idea is that each node in a network has a key-pair, one public key and one private key. The private key is kept secret and securely stored on the node while the public key is distributed to other nodes that want to communicate with it.
Alice
Encrypt DecryptBob
Bob's private Key Bob's Public Key
Message
(Plaintext) Ciphertext
Message (Plaintext) Figure 2.3: Asymmetric key cryptography
If Alice wants to communicate with Bob, see figure 2.3. Then Alice takes her message and encrypts it with Bob’s public key. Only the entity or person with the private key can decrypt a message encrypted with the corresponding public key. Hence, only Bob can read/decrypt encrypted messages sent to him that are encrypted with the corresponding public key. In some cases messages can also be encrypted by the private key. When a message is encrypted with the private key, all entities with the corresponding public key can read the message. [16]
2.1. Cryptography
Digital signatures
Digital signatures is based on public key cryptography. Digital signatures are used to assure message integrity and data origin. Digital signatures are used in the following manner. Alice wants to send an authenticated message to Bob. They decide to use digital signature, so Alice generate an asymmetric key pair. She keeps the secret private-key to herself and distributes the public key to Bob.
Alice
SignBob
Alice's Private Key
Message Ciphertext
Signature Message
Verify
Alice's Public Key Equal
? Message
Figure 2.4: Digital signature
Alice takes the message she wants to send to Bob, signs/encrypts it with her private-key using public key cryptography and sends the plain-text message and the signature to Bob, see figure 2.4. Bob then verifies the received signature by decrypting it with Alice’s public key. The output of the decrypted signature will be the plain-text message. Bob then compares the received plain-text to the decrypted plain-text. If they are equal, then he knows that the message is authentic and the message originated from Alice. [10]
There is one important aspects that must be highlighted. The public-key that Alice distributes to Bob must be distributed in a way that ensures Bob that it is actually Alice’s public-key.
2.1.3
Unkeyed Cryptography
Unkeyed cryptography encompasses cryptographic algorithms that does not utilize keys. An example of such algorithms are Cryptographic Hash-functions.
Cryptographic Hash-functions
A cryptographic hash-function is a function which takes an input of arbitrary length and maps it to a fix-sized output. A cryptographic hash-function has three distinct properties. [2] . Pre-image resistance: Given the hash-value Y it is hard to find an input (pre-image) X so
that h(X) =Y.
. Second pre-image resistance:Given hash-input X it hard to find a different input Y, which when inserted into the hash function produces the same hash-value, h(X) h(Y).
. Collision resistance:It is hard to find two different inputs X and Y, which when inserted into the hash function produces the same hash-value, h(X) h(Y).
2.2. Decentralized cryptographic solutions
2.2
Decentralized cryptographic solutions
In order to provide integrity and confidentiality assurance for decentralized networks, dif-ferent cryptographic solutions are needed.
In this section two different decentralized cryptographic solutions are presented: Double Ratchet and Merkle Tree.
2.2.1
Double Ratchet
Double ratchet is a key derivation protocol that produces two symmetric-key pairs for each communicating party, one for receiving messages and one for sending messages. The produced symmetric-key pairs are used for encryption/decryption or authentication of transmitted messages. For each sent and received message, new sending and receiving symmetric-keys are generated.[24]
What makes this algorithm special is its appealing characteristics:
. Forward security: Earlier generated keys cannot be calculated from newer keys. In
other words, if an attacker derives a key used for encryption or signing, only that mes-sage is compromised, earlier keys still seem random to the attacker even though the attacker knows the current key.
. Backward secrecy: Newer keys cannot be calculated from earlier keys. In other words,
if an attacker derives an previously used key, that key cannot be used to derive later keys.
. Replay-attack resistance: Because new symmetric key pairs are generated
continu-ously, a replay-attack will not be possible since the key used by the replayed message is not used anymore.
2.2.2
Merkle Tree
The Merkle tree was invented by Ralph Merkle in 1979 [17]. A Merkle Tree is a binary hash tree which enables efficient integrity verification of large data sets.
h0=HASH(d0) h1=HASH(d1) h2=HASH(d2) h3=HASH(d3)
h6=HASH(h4||h5)
Leaves
Root
h4=HASH(h0||h1) h5=HASH(h2||h3)
2.3. Vehicle architecture
The top most element in the Merkle Tree is called the Merkle root and the bottom most elements are called Merkle leaves, see figure 2.5. Leaves are computed hashes of data chunks/blocks decomposed from a larger data set. Higher level nodes in the tree are hashes of concatenated pair child nodes. Therefore, the hash-value that the Merkle root consists of is indirectly dependent on the state of all data blocks. If one of the data blocks has changed, the Merkle root will be completely different.[12] This is a very important concept especially in peer-to-peer networks. If for example a file has been split into smaller data chunks and scattered on different untrusted nodes on the network. A mechanism for integrity verifica-tion is needed when retrieving the file since the data chunks retrieved are from untrusted sources. By requiring the Merkle root from a trusted source, it can be determined if the data chunks received by untrusted nodes are genuine or not using a Merkle tree. If the Merkle root received from the trusted source is equal to the locally calculated Merkle tree root, then the downloaded data chunks are genuine.
2.3
Vehicle architecture
A very important part of a vehicle’s architecture is its ECUs.
2.3.1
Electronic Control Unit (ECU)
ECUs are specialized computers which control a vehicle’s various functions such as electronic engine control and active suspension. An ECU can be seen as a black box that given an input, usually signals from sensor or other ECUs, produces a corresponding output.[23, 18]
2.4
Automotive communication protocols
In order for a vehicle to communicate with its surroundings and with its internal components, a set of communication protocols must be put in place. These protocols specify the format of the messages and the medium in which they are sent on. Different protocols have different characteristics. Some protocols may be more suited for short distance communications while other are more suited for long distance communication. In general, communication protocols in the automotive industry can be categorized into three different domains. These domains are long distance wireless, short distance wireless and wired communication [28].
2.4.1
Long distance wireless communication
Long distance communication protocols are as the name implies communication protocol used for long range communication. Such communication protocols can for example be protocols used for communication with a cloud service or a back-end system. This domain encom-passes vehicle to vehicle (V2V) and vehicle to infrastructure (V2I) communication.
Cell phone 3G, 4G, 5G communication
Cell phone 3G, 4G and 5G are wireless mobile telecommunication technologies. In vehicles these technologies are mostly used as a means of accessing the cloud or more specifically the OEM’s back-end [21]. The cloud can be seen as an access point or a domain where users and OEMs can share information. The cloud can for example be used to share traffic information between vehicles. Furthermore, it can also be used to monitor a vehicle’s various variables, such as current location or sensor values. The cloud forms new revenue streams for vehicle manufacturers in the form of cloud services. An example of a cloud service can for example be to enable monitoring of a vehicle through cell phones.
2.4. Automotive communication protocols
A problem that currently exists in vehicles is that a vehicle’s different micro-controllers (ECUs) have strict real-time constraints making it difficult or challenging to implement com-putationally demanding tasks on its different ECUs without violating the real-time con-straints [11]. Today vehicle ECUs are dependent on each other, they communicate with each other to perform a common task. If the timing between ECUs is off, the consequences can be devastating. Thus, it is of great interest to offload computationally heavy tasks to an external device or to increase the computational power of ECUs. This is especially important due to the implementation of autonomous (very computationally heavy) functionality. A solution that is researched today that can potentially solve such problems is cloud computing. By uploading computationally heavy tasks to the cloud and letting remote servers solve those tasks. The cloud or more precisely a server will then respond with the solution once its done solving it. The problem with this solution is that there will be a delay between uploading the task to the cloud and then getting the response. Depending on what the task is the delay can be too long, thus the strict timing constraint will be violated. [1]
2.4.2
Short distance wireless communication
Short distance communication encompasses all wireless short distance, local communication such as Bluetooth or RFID.
2.4.3
Wired
The wired domain consists of all communication done through physical contact. There are two main automotive wired communication protocols used today: the Unified Diagnostic Services (UDS) protocol and the control area network (CAN) protocol.
Control Area Network (CAN)
CAN is the most commonly used communication protocol in vehicles. This protocol lies on the physical and data link layers on the OSI model. It allows message broadcasting between micro-controllers. CAN was originally designed by Bosch to decrease the complexity of wiring harnesses in vehicles and to enable real-time applications. CAN can be seen as the bus which connects ECUs in vehicles together, enabling cross ECU communication. Further-more, CAN also allows sharing of sensors between ECUs. [15, 6]
CAN is a broadcast protocol, meaning that everything sent over the can bus is publicly accessible by all CAN connected devices. Therefore, in order for nodes to only react on a specific message, local message filtering is required. [15, 20, 6]
Moreover, some error-detection measures exist. A so called CRC checksum is included in CAN messages. The checksum is used to ensure the integrity of transmitted messages. Unified Diagnostic Services (UDS)
The unified diagnostic services is a protocol used for diagnostics of ECUs, it also allows the diagnostic tester (client) to control diagnostic functions in ECUs (servers). A diagnostic session to one or multiple ECUs allows for the exchange of diagnostic data, such as error codes and system status. UDS is a request and response type of protocol, were the client sends a request to the server. The server will then respond with the appropriate information. The UDS protocol can also be used to flash new firmware on ECUs.
In a diagnostic session each ECU has an address which can be used to send diagnostic queries to a single ECU and thereby ignored by other ECUs except the intended. Moreover,
2.4. Automotive communication protocols
diagnostic queries can also be broadcast to all connected ECUs.
A diagnostic request message in a UDS session consists of two main parts, a request service iden-tifier (request SID) and additional parameters needed by the request such as sub-functions. The request SID indicates what type of diagnostic service the client is asking for such as the ECUReset service which resets ECUs in that particular session.
Request SID =
ecuReset
(0x11) (1 byte)
Sub-function =
[ResetType]
(1 byte)
ResetType hardReset 0x01 softReset 0x03 . . .Figure 2.6: ecuReset diagnostic service request
Figure 2.6 shows a visual representation of how the ecuReset diagnostic request looks like. The first byte in the request is the request SID which is set to 0x11 hexadecimal. This value indicates that the service requested is the ecuReset service. The following byte represents the ecuReset sub-function. The ecuReset sub-function depicts what type of ecuReset is requested. The ecuReset type can be one of several options. For example, if the sub-function paramater is set to 0x01 then the ecuReset type is a hardReset and if the value is 0x03 then the ecuReset type is a softReset. The difference between a hard and a soft reset is that a hardReset restarts the whole ECU by simulating a disconnection from its power-supply, while a softReset only restarts the application running on the ECU.
For each request received by the server, either a positive response is sent back to the client indicating that the requested diagnostic service was successfully performed or a negative response indicating that the requested diagnostic service failed or could not be completed in time.
2.4. Automotive communication protocols Response SID = ecuReset (0x11 + 0x40 = 0x51) (1 byte) Sub-function = [ResetType] (1 byte) ResetType hardReset 0x01 softReset 0x03 . . . powerDownTime (1 byte)
Figure 2.7: ecuReset diagnostic service positive response
A positive response consists of two main parts, response SID and additional parameters needed by the response, see figure 2.7. The response SID that the request SID corresponds to can always be identified by adding hexadecimal 0x40 to request SID. For instance, a positive response for a ecuReset service request consist of three parts. These three parts are response SID, resetType and powerDowntime. The response SID is set to 0x51 (0x11 + 0x40) indicating a positive response for the ecuReset service request (0x11). The resetType argument indicates what type of ecuReset the response corresponds to. The last argument powerDowntime indi-cates to the client the minimum time it takes for the server to restart.
Response SID = negative Response (0x7F)(1 byte) Request SID = ecuReset (0x11) NRC incorrectMessageLengthOrInvalidFormat 0x13 conditionsNotCorrect 0x22 . . . Negative response code (NRC) (1 byte)
Figure 2.8: ecuReset diagnostic service negative response
A negative response consists of three parts, Negative response SID (NRC), request SID and negative response code, see figure 2.8. The negative response SID has a fixed value of 0x7F, the request SID indicates which diagnostic request failed and the negative response code (NRC) indicates what type of failure it was, see figure 2.8.
2.5. Automotive supply chain
ReadDataByIdentifier
The readDataByIdentifier diagnostic service allows the client to request specific data from the server using a so called dataIdentifier.
Request SID = ReadDataByIdentifier (0x22) (1 byte) DID = [DataIdentifier] Response SID = ReadDataByIdentifier (0x62) (1 byte)
DID = [DataIdentifier]
Payload
Request
Response
Figure 2.9: readDataByIdentifier diagnostic request and response
The readDataByIdentifier diagnostic service has two arguments, see figure 2.9. The first argu-ment is the request SID indicating that the diagnostic request in question is a readDataByIden-tifier diagnostic request. This is signaled by a 0x22 hexadecimal request SID. Followed by the request SID is the data identifier (DID). The DID tells the server what type of data the client wants. Depending on the value of the DID, corresponding data to that specific value will be sent back to the client. If the server can carry out that request a positive response will be sent back indicated by a response SID with value 0x62 hexadecimal. Followed by the positive response is the DID that was requested and lastly the payload containing the data that the client asked for.
2.5
Automotive supply chain
There exists six main stakeholders in the vehicle manufacturing process [5]. These six stake-holders are Raw Material Supplier, Tier 2 Supplier, Tier 1 Supplier, Vehicle Manufacturer (OEM), Dealer and Consumer.
Vehicle Manufacturer (OEM) Tier 1 Supplier Tier 2
Supplier Dealer Consumer
Automotive Supply Chain
Raw Material Supplier
Figure 2.10: Automotive supply chain
A visual representation of the automotive supply chain is depicted in figure 2.10. The pre-sented supplier chain model is centered around the OEM which in this case is the vehicle manufacturer.
2.6. Distributed control architecture in Scania’s trucks
1. Raw Material Supplier: The raw material provider, is the supplier that provides raw material such as metal or plastic to tier 2 suppliers.
2. Tier 2 Supplier: Tier 2 suppliers supply necessary component to the tier 1 companies. 3. Tier 1 Supplier: Tier 1 suppliers are the suppliers that are in direct contact with the
OEM. They provide products usually different components such as ECUs directly to the OEM.
4. Vehicle Manufacturer (OEM): The original equipment manufacturer in this case is the vehicle manufacturer. The company or organization that assembles or produces vehi-cles from the components provided by the tier 1 supplier. The vehicle manufacturer then provides vehicle dealers with fully assembled and tested vehicles.
5. Dealer: The vehicle dealer then sell vehicles provided by the OEM to consumers. 6. Consumer: The consumer is the vehicle buyer that buys the vehicle from the vehicle
dealer. The vehicle buyer can be a company/organization or a single person.
2.6
Distributed control architecture in Scania’s trucks
The CAN bus in Scania trucks is divided into three sub-networks.COO Coordinator system Red bus EMS Engine management system BMS Brake management system SMS Suspension management system RTC Road Traffic Communicator ACC Automatic Climate Control CTS
Clock and Timer System
Diagnostic Bus
Cloud
Y
ellow bus
Green bus
Figure 2.11: CAN bus architecture in Scania trucks
These three sub-networks are called green bus, yellow bus and red bus, see figure 2.11. Further-more, new truck models also include an orange bus. The three sub-networks are indirectly connected together through an ECU gateway known as the coordinator ECU. The coordinator ECU forwards messages between the sub-networks based on the messages CAN identi-fier. Only CAN messages with specific CAN identifier are allowed to be forwarded from one sub-network to another. Messages that do not need forwarding are blocked by the coordinator. Each sub-network contains specific types of ECUs. The red bus contains critical ECUs related to the vehicles propulsion, usually powertrain related ECUs. The yellow bus contains less critical safety and comfort related ECUs, such as the infotainment system and the instrument cluster. The green bus contains non-critical body domain related systems, such as internal lights and mirror control.
The internal CAN network also consists of other types of gateways such as the RTC ECU. The RTC ECU provides communications between the yellow bus and Scania’s back-end services
2.7. Firmware Over-The-Air (FOTA)
over cellular data. The RTC ECU is for example used in FOTA in order to push new firmware to ECUs. The RTC ECU can be seen as the ECU that is connected to the cloud.
2.7
Firmware Over-The-Air (FOTA)
In the early days ECUs used to have ROM read only memory which permanently stored the firmware or applications on the micro-controller. A problem with using ROM that vehicle manufacturers then discovered was that many software and hardware bugs are discovered after shipping the product. Thus making it very difficult to resolve those bugs without com-pletely replacing the ECU or by replacing the ROM component. Furthermore, the inability to update the software on ECUs increases the overall complexity by requiring the vehicle manufacturer to produce or provide a larger number of ECUs for different combinations of software enabled functionality. [23]
Today, re-writable flash memory is used instead of ROM. This gives OEMs the opportunity to update the software of ECUs without the need to replace the ECU itself or the ROM memory [29]. There are two main ways to update the software on ECUs. ECUs can be updated through physical contact by connecting to the CAN bus through the OBD socket inside the vehicle or by updating ECUs remotely through something called firmware over-the-air (FOTA). Previously vehicles could only be updated though physical contact in a repair-shop. This puts a lot of pressure on repair-shops and also complicates the update process making it inconvenient.
FOTA simplifies the process by enabling remote firmware updates. It enables convenient security patching in software keeping ECUs up-to-date. Furthermore, such technology also opens up new previously unattainable possibilities. Which is systematically enabling newly developed functionality through over-the-air updates after the product has been shipped.
Vehicle Manufacturer (OEM)
Cloud
1. Pushes update to the cloud
2. Determine if there exists new updates3. Download new firmware updates
Vehicle Figure 2.12: Firmware Over-The-Air (FOTA)
Firmware over-the-air functions in the following manner, see figure 2.12. The OEM pushes new firmware updates to the cloud only accessible by eligible vehicles. Upon start, vehicles
2.8. Known in-vehicle network vulnerabilities and proposed solutions
determine if there is a new firmware update on the cloud. If there is a new update the vehicle will start to download the update file with corresponding update instructions. The update is then flashed/installed on the corresponding ECU. [21]
There exists a major security concern when it comes to FOTA. FOTA might enable unau-thorized actors updating the vehicle’s different ECUs with firmware that could very well contain malicious functionality or functionality that disrupts the vehicle’s expected behavior. The most common reason for unauthorized firmware updates is to activate certain vehicle futures, such as stronger engine without paying the activation fee [23]. Thus vehicle manu-facturers like Tesla actually cryptographically sign their updates making it more difficult for malicious actors to flash or install malicious software.
2.8
Known in-vehicle network vulnerabilities and proposed solutions
As mentioned in the Automotive communication protocols section 2.4 many different commu-nication bus systems are used in vehicles. Currently, the number of commucommu-nication bus systems used in vehicles is constantly increasing. This increase in complexity and functional-ity will undoubtedly also increase the attack surface, opening a very large door for potential misuse of the system. What makes the situation even worse is the use of insecure commu-nication protocols such as CAN which is the most commonly used commucommu-nication protocol in vehicles. The only type of "security" the CAN protocol provides is the CRC checksum parameter in CAN messages as an integrity check. Furthermore, the node sending data over CAN does not know who is supposed to receive the transmitted message. Moreover, the receiving node does not know where the message came from, the CAN controller only knows that the message is needed by its micro-controller based on the message identifier. This means that a malicious actor can easily interface/connect to the CAN bus and forge a message pretending for example to be sending genuine sensor data, but in reality is sending false sensor values designed to crash the vehicle while in autonomous mode. An important aspect to note is that anyone can produce the CRC checksum based on the message sent. Therefore, the CRC checksum does not pose any problem for an attacker. [4]An explanation to why the situation today is so dire is presented in the article Embedded IT Security in Automotive Application – An Emerging Area [23]. The article explains that in the early days there was no real reason for malicious manipulation of applications and security usually wasn’t OEM’s first priority. Therefore, communication protocols and components that are still used today are lacking security wise.
In the article "Security threats to automotive CAN networks—Practical examples and selected short-term countermeasures" [9] it is explained that there actually exist measures today to at least detect malicious activity by for example using intrusion detection systems (IDS). But the problem is that such tools or techniques are not well established in the automotive domain. Thus, several self-diagnostic mechanisms are used instead. These self-diagnostic mechanisms are not designed for preventing or detecting malicious or unauthorized activity, instead these mechanisms are used to isolate component failure in order to help service technicians to find potential problems. Component failures are reported by reserving a portion of the memory in ECUs for so called diagnostic trouble codes (DTC). Each reported DTC refers to a specific problem, thus the problem can be isolated. Furthermore, some modern ECUs also store en-vironmental information during failure such as engine temperature. Moreover, there exist security measures in vehicles today such as digital signatures.
2.8. Known in-vehicle network vulnerabilities and proposed solutions
2.8.1
Known exploited vulnerabilities
Most vulnerabilities that can be found today in in-vehicle networks are mostly related to vulnerabilities in the CAN bus since practically no security is provided. There are vulnera-bilities that can be found in other protocols and components such as in the engine immobilizer due to the use of short cryptographic keys. But those vulnerabilities are not widely reported. There exists a plethora of exploits today showcasing how vulnerable communication proto-cols used in vehicles actually are. In the article "Security threats to automotive CAN net-works—Practical examples and selected short-term countermeasures" [9] four different at-tacks were analyzed and simulated using CANoe. Some of the atat-tacks need to transmit CAN messages on a specific CAN subnetwork in order to work, whilst other attacks are possible by simply connecting the OBD socket and start sending CAN messages that way.
Electric window system attack
This attack was performed by injecting malicious code into an arbitrary ECU in the simulated comfort CAN subnetwork. The goal with the attack was to open the door window when the vehicle speed had exceeded 200 km/h. In other words what the malicious code did was first to listen for the speed or velocity of the vehicle and once it exceeds 200 km/h, the ECU starts replaying the CAN message to open the window. Despite the fact that the real ECU responsible for sending window open/close CAN messages still sends messages indicating that no button is pressed in a certain frequency, the attack was still successful. [9]
Another version of the same type of attack was also performed. But this time it was a real attack on a real window lifter not a simulation. The goal with this attack was to prevent the passengers or driver from opening the window. By first identifying how window open and close CAN messages looked like, they were able to once a window open message was observed on the CAN bus, directly send an opposite command which is to close the window. This will in turn prevent anyone from opening the window by denying the window open service. [9]
Warning lights attack
The goal with the warning lights attack is to disable the warning lights which are activated when unauthorized opening of doors is detected. When unauthorized access is detected by the door contact sensor, the door control module conveys this to the comfort ECU which then triggers an alarm for a few minutes by sending warning light set (turn on) and unset (turn off) CAN messages.
The attack can successfully be achieved by any controller that has access to the comfort CAN subnetwork. Either by connecting a malicious device or by injecting malicious code into an ECU in the comfort CAN subnetwork. The attack functioned in the following way, when a warning light set (turn on) CAN message was observed, immediately a warning light unset (turn off) message was broadcast over CAN. Despite the fact that warning lights set (turn on) CAN messages are still broadcast in a certain frequency, the attack was still successful. This attack will completely disable the warning lights for the most part, but because they had a timing issue sometimes a weak glow appeared. [9]
Airbag system attack
The aim of the airbag system attack is to be able to remove the airbag without triggering the airbag failure dashboard indicator. This attack can be done by any controller in the powertrain CAN subnetwork. They performed this attack by connecting a PC system to the
2.8. Known in-vehicle network vulnerabilities and proposed solutions
powertrain network through the CAN bus interface. The PC then emulated the expected behavior of the airbag control system, thus no airbag failure could be detected. [9]
The method they used for emulating the airbag control system was to record the response of the airbag control system to diagnostic queries during a genuine diagnostic session. After removing the airbag control system, they emulated its expected behavior by replaying the recorded responses of the real airbag control system. [9]
ECU gateway attack
The ECU gateway attack exploits vulnerabilities in the gateway ECU in order to allow CAN messages sent from an external diagnostic interface to be forwarded to internal subnetworks. This was done by listening to a regular diagnostic session. What they discovered was that when a diagnostic session is initialized between the tester and the device that is going to be tested, a message identifier negotiation is performed between them. The chosen message identifier will then be unlocked in the gateway allowing messages with that message identifier to be forwarded from their respective CAN subnetworks only during the extent of the diag-nostic session. The problem is that there is no check if the chosen message identifier is within the range of allowed ids for such a session. This does potentially mean that an already used message identifier can be unlocked in the gateway in order to forward that message in and out from internal to external subnetworks. [9]
By performing this attack they were able to forward internal arbitrary messages to external buses that should otherwise not be possible.
Control override
The control override is a denial-of-service type of attack. The aim of this attack is to disrupt the expected behavior off the network. This is done by blocking low priority CAN packets from being transmitted over CAN. This can be achieved in two different ways, by continuously sending high-priority message thus preventing lower priority messages from accessing the CAN bus, or by continuously sending unauthorized error-frames thus violating the bit-stuff rule which will in turn cause all nodes on the CAN bus to reject the frame received at the time of receiving the error-frame. Such type of attack has proven to be very effective leading to undefined behavior by the vehicle’s various ECUs. The control override attack can potentially also disable various equipment in a vehicle. [4] [25]
Using this attack a couple of tester were able to block the communication to the engine control module thus preventing the vehicle to start and also to reduce the vehicle’s velocity from 40 mph to 0 mph while the vehicle was moving. [13]
2.8.2
Proposed solutions
There are four main ways of securing automotive components and networks. These counter-measures are: network segmentation, cryptography and intrusion detection or intrusion prevention system (IDS, IPS). [25]
Network segmentation
The aim of network segmentation is to isolate different ECU domains from each other. For ex-ample most vehicle manufacturers today separate safety-critical ECU from non-critical ECUs by locating ECU of respective domain in different CAN subnetworks. Different subnetworks are the connected via a so called gateway. The gateway functions as a filtering device,
contain-2.9. ECU security classes
ing a white-list of CAN message identifiers that can pass through. There is also the option to use firewalls which are more sophisticated than gateways.
Cryptography
Cryptography can be used as a means of encrypting or sign frames sent via different medi-ums. A problem that vehicle manufacturers face today is that a CAN frame payload only consists of maximum 8 bytes, thus using message authentication codes (MAC) to ensure in-tegrity and data origin is impractical. But there exists some instances where cryptographic signing is used, mainly when uploading and downloading firmware over-the-air updates. This is to ensure that the firmware originated from the OEM.
Intrusion detection or intrusion prevention systems (IDSs, IPSs)
The are current research examining if IDS and IPS can be used in todays in-vehicle networks. An IDS is a system that monitors and analyzes the traffic or events occurring in a device or network in order to detect possible malicious intrusions or violations of expected behavior. Intrusion prevention systems takes it a step further than intrusion detection systems. It doesn’t only detect intrusions but also tries to prevent them from successfully going through. [26]
A significant problem that can be seen when it comes to network intrusion detection systems is that CAN messages do not contain enough information about the sender and reciever in order for an network IDS to detect intrusions properly. Thus a more reliable way of detection is to use an anomaly-based IDS. The idea behind anomaly-based IDSs is to record the normal behavior base-line of a device or network and compare it to the current behavior. If the current behavior deviates to much from the expected base-line, then there is a possibility that there exists an intruder in the device or network. [11]
2.9
ECU security classes
Dividing ECU domains into different security classes is not as simple as one might think. There is a lot of different variables that depict what security level or class a specific ECU domain can have. In general there are two major variables that restrict the security aggres-siveness of ECU domains. These two variables are, the ECU’s security objectives and the security capabilities of the ECU. In other words, when assessing what security level a ECU domain should have, it is necessary to think about what level of protection that domain needs and what security restrictions exist, such as limited processing power and storage space. In the article Vehicle ECU classification based on safety-security characteristics [14] a study was performed to showcase which of the ECU domains needed the strongest protection based on their security and safety requirements. The conclusion was that ECUs in the powertrain and body domain needed the strongest and most aggressive protection out of all the five ECU domains. This is because a malfunction or unintended behavior of ECUs in the body or powertrain domain can directly affect and put the driver and passengers at risk by for example disabling the braking system or engaging the airbag randomly.
In order to provide certain security levels and requirements, security classes need to be de-fined. In the article Aspects of Secure Vehicle Software Flashing [29], four security classes are defined related to ECU firmware flashing.
2.10. Metrics
Figure 2.13: Security classes [29]
The classes presented in the article are called class A, B, C and D. A visual representation of the security classes is presented in figure 2.13.
1. D: Class D provides the minimum security requirement in order to assure that the firmware is fully received by the ECU without any errors. The meaning by this re-quirement is that there must be a check for data transfer errors in the receiving end. The main method presented for error detection is CRC-calculation.
2. C: Class C adds the concept of integrity and authenticity. Integrity in the form off as-suring that the firmware transfered to the ECU has not been manipulated with and authenticity in the form off assuring that the source off the received firmware is a cor-rect/authentic source. Another requirement that this class provides is the detection of correctly and incorrectly flashed firmware on the ECU. The main methods for fulfilling these requirements are MAC-Calculation and Hash-values authentication.
3. B: The additional requirement that class B provides is Copy Protection. This requirement assures that the firmware transfered can only be flashed to the intended recipient/ECU. 4. A: In class A an extra requirement is added to requirements of class B. This requirement is confidentiality. Confidentiality in the form of only allowing the intended recipient to access/read the sent flashware. The main method presented to assure confidentiality is encryption.
2.10
Metrics
2.10. Metrics
2.10.1
F1-score
The F1-score is a metric that measures the accuracy of the system under test. An F1-score of 1 indicates perfect accuracy while an F1-score of 0 indicates the worst possible accuracy. The F1-score is calculated by the following formula, were P is precision and R is recall:
F1= 2 P R
P+R (2.1)
[3] Recall
The recall is the number of true positives divided by the sum of all true positives and false negatives.
R= TP
TP+FN (2.2)
[3] Precision
The precision is the number of true positives divided by the sum of all true positive and false positives.
P= TP
TP+FP (2.3)
[3]
2.10.2
Sample standard deviation
Sample standard deviation is a metric that measure the degree of deviation of a provided data set from the mean value. The lower the standard deviation is the closer the data points are to the mean. The higher the standard deviation is the farther the data points are to the mean. The sample standard deviation is calculated with the following formula. [30]
s= d°n
i=1(xi x)2
n 1 (2.4)
• s: Sample standard deviation • xi: An entry in the data set
• x: Mean of all entries in the data set, that is sum of all entries divided by the number of entries in the data set
3
Literature study
The literature study chapter is divided into four sections: Search strategy, Study selection, Study quality assessment and Related work. The purpose of this chapter is not only to demonstrate how the literature study was conducted, but also to present already established research related to consistency verification.
The systematic literature review presented in the article Guidelines for performing Systematic Literature Reviews in Software Engineering was used as the main method for the literature study. A systematic literature review is divided into three steps, search strategy, study selection and study quality assessment.
3.1
Search strategy
The first step in the literature review was to define the search strategy. The aim of this step was to find as many studies as possible that are related to the research questions. This was done by breaking down the research questions into a list of relevant search terms. The search term list was further expanded by adding the synonyms and abbreviations of the search terms. Furthermore, combination of two or more search terms were also used such as automotive attestation or vehicle communication. Moreover, terms from the created attack model were also used such as replay attack or data tap in order to find existing solutions that protect against the attacks presented in the attack model.
The search terms that could be extracted from the research questions are presented in list below .
1. What types of hardware and software requirements will the proposed consistency verification mechanisms necessitate?: ECU, Hardware, software, restrictions, verifica-tion, attestaverifica-tion, vehicle, automotive, communication
2. What is the detection performance of the implemented consistency verification mech-anisms?: F1-score, metrics, success rate, performance
3. What is the timing performance of the implemented consistency verification mecha-nisms?: Response-time, real-time constraints, efficiency
3.2. Study selection
4. Other relevant terms: CAN bus, TPM, key-distribution, security, safety, embedded, public key infrastructure
Only two search engines were used for the literature study, the LIU library and Google scholar.
3.2
Study selection
Relevant articles, journals and books were chosen by first reading the abstract, introduction or summary 2-4 times. After reading the abstract a decision was made based on if the study seemed to be relevant for answering the research questions. Thereafter, the date of publica-tion was also looked at. If the date of publicapublica-tion was earlier than the year 2000 and there exists newer studies with the same content or topic, then that article, journal or book was discarded. But if the date of publication was earlier than the year 2000 and there was no other publication that touched the same topic, then that publication was allowed to be used. The next step was to read the entire content of each publication. If after reading the whole publication no relevant information was presented then that publication was discarded.
3.3
Study quality assessment
The quality of the studies found were also assessed based on validity and applicability of the study. If the results presented in the study were invalid or untrustworthy the study was discarded. Moreover, if the study was not applicable for the automotive domain or the results were not reproducible the study was also discarded.
3.4
Related Work
The current research on a decentralized consistency verification mechanisms in the auto-motive domain is very limited, thus only one genuinely relevant article could be found, Oguma et al.[22]. Since only one article was found in the automotive consistency verification domain, other consistency verification mechanisms from other domains were also included and analyzed. One fundamental flaw that all the found consistency verification solution had, was that they had a single point of failure. Meaning that if you eliminate the correct node, the entire attestation process stops functioning. This fundamental flaw called for a new, more robust solution to be developed which is specially tailored for the automotive domain. Other relevant literature was also found related to cryptography in order to provide integrity, data origin assurance and also to prevent replay attacks. The most interesting cryptographic solution found that fulfills the requirements above is called double ratchet. For more informa-tion about double ratchet, see secinforma-tion 2.2.1.
Four of the already established consistency verification mechanism are presented in the next section.
3.4.1
New Attestation-Based Security Architecture for In-vehicle
Communication
The article New Attestation-Based Security Architecture for In-vehicle Communication[22] presents an attestation process that is specially crafted for the automotive domain. The attestation process presented in this article consists of two main components, several ordinary ECUs and a master ECU. The master ECU is the ECU that actually attests the state of the whole vehicle. The master ECU contains a database storing all the expected-state hash-values of all connected ordinary ECUs. Each ECU contains a TPM for software measurements. The
3.4. Related Work
TPM hashes the corresponding ECU’s flash-memory in its entirety as a form of measurement which represent the current-state of the ECU. Every ECU has a unique identifier that is pro-vided inside attestation messages in order to identify the location of the cryptographic key used for message verification and decryption.
Master ECU
ECU
1. Broadcast r1
2. {ECU_id, H(flash-memory), r
1,r} MAC
3. Enc {r
2, r, H(flash-memory
Master)}
Figure 3.1: New attestation protocol
1. The attestation protocol is engaged by the master ECU by broadcasting a nonce known as r1, see figure 3.1. Moreover, the master ECU also generates another nonce r2 and keeps it a secret. The first nonce r1 is used for replay attack protection. The second nonce r2 is used to signal to other ECU that it has successfully been attested by the master ECU.
2. When a connected ECU receives the broadcast r1 nonce, its TPM starts hashing the entire flash-memory. The ECU being attested responds with a message consisting of its ECU id, current-state hash-value provided by the TPM, r1 nonce and a new nonce called r. The entire response is cryptographically authenticated using a message au-thentication code (MAC). The r nonce serves as a challenge for the master ECU, such that the next response from master ECU must contain the r nonce.
The master ECU after receiving the message containing the current-state hash-value, verifies the MAC by using the cryptographic key corresponding to the ECU id con-tained in the received message. The master ECU thereafter compares the current-state hash-value to the expected-state hash-value stored in its database. If they are equal then the ECU in question is in a consistent state. If they are not equal then the ECU in question is in a inconsistent state.
3. The master ECU then responds with a symmetrically encrypted message containing the nonce r2, nonce r1 and the current-state hash-value of the master ECU’s flash-memory. When the attested ECU receives the message, it first decrypt the message in order to reveal its contents. First the attested ECU verifies that the r nonce inside the message is the nonce previously transmitted. Then the ECU verifies that the master ECU’s current-state hash-value is correct by comparing it to a locally stored expected-current-state hash-value. The r2 nonce is thereafter securely stored inside its memory in order to be later used inside every encrypted message in order to signal to other ECU that it has been attested by the master ECU.
