Master Thesis Computational Sciences in Engineering
Safe and Secure Trust Management in V2X Communication Using Secret Unknown Cipher
Submitted by: Raghad Abdulwahed Matr. Nr: 4246385 March 2018
First Examiner: Prof. W. Adi
[email protected] Second Examiner: Prof. A. Jukan
[email protected] Technische Universität Braunschweig | IDA Hans-Sommer-Str. 66 | 38106 Braunschweig | Germany
Confirmation Hereby I declare, that I have written the present master's thesis independently and I have used no other than the specified sources.
Braunschweig, in March 2018 Raghad Abdulwahed
2
Acknowledgment I would like to express my gratitude and thanks to Mohammad Hamad for imparting his knowledge and expertise in this study. My thanks also go to Ayoub Mars and Saleh Mulhem. Above all, I would like to thank my husband, Zain, who has been a constant source of support and encouragement during all the challenges and also for my little son, Ayham, who gives me the love. I consider myself the luckiest in the world to have such a lovely and caring family, standing beside me with their love and unconditional support.
3
4
Abstract In the environment of self-driving vehicles, enabling a vehicle to communicate with surrounding infrastructure (V2I) and other vehicles (V2V) increases transportation efficiency and vehicle safety. Using only the vehicle sensors to perceive the environment is however not sufficient. To enable V2V and V2I, many concerns have to be under consideration, principally, safety, security, reliability, etc. Safety and security are the main concern of this thesis. An efficient authentication mechanism between vehicles and surrounding infrastructures is a requirement for ensuring safe and secure V2X communication. Such efficient authentication mechanism should satisfy certain properties like 1) in-field management (at running time), 2) lightweight protocols, 3) scalable management. In this thesis, a perusal of the state-of-the-art of proposed solutions is presented where the insufficiency in the state of the art will be uncovered. Since the lack of proper authentication mechanism gives rise to most of the security issues in V2X communication, this work aims to propose an authentication mechanism that combines two solutions in hand, namely the Secure Hardware Module (HSM) and the Secret Unknown Cipher (SUC). SUC will be used as an ID of the vehicle. Such an ID is a clone-resistance and non-replicable ID, which eliminate security attacks e.g. replication attack or Sybil attack. The needed protocols for V2X communication, which take the features of the SUC, are defined in this work. Since authenticity is a cornerstone of any trust management system, our proposed authentication mechanism could be considered as a step toward establishing an efficient trust management module in the vehicle domain.
5
Kurzfassung Im Umfeld von selbstfahrenden Fahrzeugen erhöht die Kommunikation eines Fahrzeugs mit der umgebenden Infrastruktur (V2I) und mit anderen Fahrzeugen (V2V) die Transporteffizienz und die Fahrzeugsicherheit. Es reicht jedoch nicht aus, nur die Fahrzeugsensoren zur Wahrnehmung der Umgebung zu verwenden. Um V2V und V2I zu ermöglichen, müssen viele Belange berücksichtigt werden, vor allem Safety, Security, Zuverlässigkeit, usw. Safety und Security sind das Hauptanliegen dieser Masterarbeit. Ein effizientes Trust-Management zwischen Fahrzeugen und umliegenden Infrastrukturen ist Voraussetzung für eine sichere V2X-Kommunikation. Ein solches effizientes Trust-Management sollte bestimmte Eigenschaften erfüllen, wie 1) In-FieldManagement (zur Laufzeit), 2) schlanke Protokolle, 3) skalierbare Verwaltung und 4) sichere Verbindung zwischen Knoten. In dieser Arbeit werden Lösungen, die dem aktuellem Stand der Technik entsprechen, diskutiert und es werden auf Unzulänglichkeiten und Verbesserungsmöglichkeiten hingewiesen. Da das Fehlen eines geeigneten Authentifizierungsmechanismus zu den meisten Sicherheitsproblemen in der V2X-Kommunikation führt, zielt diese Arbeit darauf ab, einen Authentifizierungsmechanismus vorzuschlagen, der zwei Lösungen kombiniert, nämlich das Secure Hardware Module (HSM) und die Secret Unknown Cipher (SUC). SUC wird als ID des Fahrzeugs verwendet. Eine solche ID ist eine KlonResistenz und nicht replizierbare ID, die Sicherheitsangriffe wie z.B. Replikationsangriffe oder Sybil-Angriffe eliminiert. In dieser Arbeit werden die notwendigen Protokolle für die V2X-Kommunikation definiert, die die Eigenschaften der SUC übernehmen. Da Authentizität ein Eckpfeiler eines jeden Trust-Management-Systems ist, könnte der vorgeschlagene Authentifizierungsmechanismus als ein Schritt zur Etablierung eines effizienten Trust-Management-Moduls in der Fahrzeugdomäne betrachtet werden.
6
Contents 1
|
INTRODUCTION ------------------------------------------------------------------------------------------------------------ 9
1.1.
VEHICLE-TO-VEHICLE AND VEHICLE-TO-INFRASTRUCTURE COMMUNICATION (V2X) -- 10
1.2.
SECURITY PRIMITIVE ------------------------------------------------------------------------------ 12
1.3.
SAFETY AND SECURITY IN V2X ------------------------------------------------------------------ 13
1.4.
SOLUTION FOR SECURITY AND SAFETY ISSUES IN V2X: ------------------------------------ 15
1.4.1. Software Solutions: --------------------------------------------------------------------------- 15 1.4.2. Hardware Solutions: -------------------------------------------------------------------------- 17
2
3
1.5.
RESEARCH OBJECTIVES AND CONTRIBUTION ------------------------------------------------ 18
1.6.
OUTLINE --------------------------------------------------------------------------------------------- 18
|
HARDWARE SECURITY MODULE (HSM) ----------------------------------------------------------------- 19
2.1.
SECURITY AND FUNCTIONALITY REQUIREMENTS OF HSM: --------------------------------- 19
2.2.
HSM ARCHITECTURE ----------------------------------------------------------------------------- 20
2.3.
HSM KEYS MECHANISM: ------------------------------------------------------------------------- 21
2.4.
HSM IMPLEMENTATION: -------------------------------------------------------------------------- 23
2.5.
COMPARISON BETWEEN THREE HSM MODULES: -------------------------------------------- 24
2.6.
COMPARISON BETWEEN HSM AND OTHER HARDWARE SECURITY MODULES: ----------- 26
| 3.1.
PHYSICAL UNCLONABLE UNITS (PUF & SUC) ------------------------------------------------------ 29 PHYSICAL UNCLONABLE FUNCTION (PUF) ---------------------------------------------------- 29
3.1.1. PUF applications: ------------------------------------------------------------------------------ 32 3.1.2. PUFs in vehicular system: ------------------------------------------------------------------- 39 3.2.
SECRET UNKNOWN CIPHER (SUC) ------------------------------------------------------------- 39
3.2.1. SUC as Stream Cipher: ---------------------------------------------------------------------- 41 3.2.2. Using SUC in clone-resistant Vehicular RKE: ------------------------------------------ 43 3.2.3. Generic Identification Protocol by deploying SUC: ------------------------------------ 43 4 | ENHANCING THE SECURITY IN V2X COMMUNICATION USING SECRET UNKNOWN CIPHER----------------------------------------------------------------------------------------------------------------- 45 4.1.
SUC IN USE ----------------------------------------------------------------------------------------- 45
4.1.1. System Module -------------------------------------------------------------------------------- 45 4.1.2. Sequence diagram ---------------------------------------------------------------------------- 47 4.2.
PROBLEM OF UPDATING CRS LIST AND THE USE OF DYNAMIC UPDATING OF LIST---- 49
4.3.
PROTOCOLS AND IMPLEMENTATION ------------------------------------------------------------ 49
4.3.1. Enrollment Protocol for a single Node ---------------------------------------------------- 49 4.3.2. Authentication Protocol for a single Node------------------------------------------------ 49 4.3.3. Authentication Protocol between two Nodes by one Mediator (One-wayAuthentication) ------------------------------------------------------------------------------------------- 51
7
4.3.4. Authentication Protocol between two Nodes by one Mediator (MutualAuthentication) ------------------------------------------------------------------------------------------- 52 5
|
DISCUSSION AND FUTURE WORK--------------------------------------------------------------------------- 53
6
|
CONCLUSION -------------------------------------------------------------------------------------------------------------- 55
LIST OF FIGURES -------------------------------------------------------------------------------------------------------------------- 57 LIST OF TABLES --------------------------------------------------------------------------------------------------------------------- 59 ACRONYMS------------------------------------------------------------------------------------------------------------------------------ 61 BIBLIOGRAPHY ----------------------------------------------------------------------------------------------------------------------- 63
8
1
|
INTRODUCTION
The rapid development of techniques for design and analysis of Cyber-Physical Systems (CPS) as well as the fascinating growth of the applications of Artificial Intelligence (AI) facilitates bringing the smart and self-driving cars from science fiction movies to our laboratories. To bring self-driving cars (known also as autonomous driving) to our streets, many concerns have to be under consideration, principally, safety and security. Such smart cars are required to interact and communicate with the surrounding environment, practically, two kinds of communications will take place: Vehicle to Vehicle (V2V) and Vehicle to Infrastructure (V2I) communications. Both together are known as V2X communication. Security issues in V2X communication are the main interest of this thesis. Preventing unauthorized parties from hijacking an embedded computer or sending false data is the main goal of proper authentication mechanisms. Since the lack of such proper authentication mechanism gives rise to most of the security issues in V2X communication [1], this work aims to propose an authentication mechanism that combines two solutions in hand, namely the Secure Hardware Module and the Secret Unknown Cipher (SUC). An SUC will be used as an ID of the vehicle. Such an ID is a clone-resistance and non-replicable ID, which eliminate security attacks e.g. replication attack [2] or Sybil attack [3]. The needed protocols for V2X communication, which take the features of the SUC, are defined in this work. To motivate this work let us consider the following scenario in V2V communication: A self-driving car A is moving on a street, another self-driving car B broadcasting a message claiming that it is an ambulance and asking car A to slow down and to takeover the rightmost lane. How to verify the claim of B to let A respond properly according to a predefined trust policy, is a problem to be solved in this thesis. The proposed solution depends on defining a secure authentication mechanism which deploys the technology of clone-resistance 1 of PUFs as will be shown later in this thesis. Another motivation is eliminating Sybil attacks [3]. These two motivations will be recalled in Chapter 5. In this chapter, the primitives of security are presented as well as the principles of the V2X communication. The issues of safety and security in V2X are sated in this chapter, and then briefly the state of the art of available solutions are listed down where they will be detailed in Chapter 2 and 3. Later, the objectives and the contribution of this work are clarified.
1
At least it is defined to be clone-resistance.
9
1.1. Vehicle-to-Vehicle and Vehicle-to-Infrastructure Communication (V2X) In automotive, especially when semi-autonomous or full-autonomous driving is considered, vehicles need to communicate with other vehicles (V2V) and with surrounding infrastructure (V2I) such as streetlights, building, streets, or even cyclists or pedestrians as shown in Figure 1.
Figure 1 : V2X Communication System Vehicle communication system is conceptually simple, where it is an Electronic Control Unit (ECU) [3] that is embedded in vehicles and configured to exchange messages with other vehicles or infrastructure terminals. The V2V message exchange is used generally to communicate the state of a vehicle with other vehicles. On the other hand, the V2I message exchange is required to access remote services, to receive safety information of a roadway, etc. [4]. Recently, vehicle manufacturing has been changed significantly, with increasing of embedded systems and embedded software applications which integrated into vehicles. A modern vehicle is equipped up to 100 embedded ECUs. These ECUs in a vehicle are connected via different types of communication buses (e.g. CAN, MOST, FlexRay, LIN, etc.) as shown in Figure 2.
Figure 2: Automotive On-Board Network Architecture [14] 10
With the advent of wireless network interfaces, the automotive on-board networks have more opportunity for tampering. The on-board electronics will be threatened attacks both inside and outside the vehicle. The main components that might be the most target of the attackers in a vehicular system are the on-board electronics (e.g. ECUs, sensors, actuator, etc.), the software that is running on ECUs, and the communication links. The increasing of connectivity in a vehicle improves the functionality, capability and the utility of the vehicle. On the other hand, however, this may cause more cyber-security threats and the vehicles will be more vulnerable to attacks from adversaries [5]. In vehicle system as shown in Figure 3, the concept of communicating with road conditions also has become the most developing concept recently, not only to improve the traffic safety or to increase the number of the vehicles in a safe area but also to reduce the traffic congestion. Understanding this work requires that the reader is familiar with basic concepts related to security, thus, in the following, some security primitives are presented in order to state the issues related to safety and security in V2X.
Figure 3 : V2X System Overview
11
1.2. Security Primitive CIA stands for Confidentiality, Integrity and Availability. These principles should be satisfied in any kind of security system. It considered as a known-well model for security policy. Figure 4 shows the CIA model.
CIA Security Model Integrity
Figure 4 : CIA Security Model
Confidentiality: In the communication, the confidentiality means, the ability to prevent unauthorized parties to access the transmitted data. it is implemented using a security mechanism such as passwords, usernames, encryption, etc. Encrypting the data is a method which ensures the confidentiality. Encrypting method allows just the right parties to read the information using a shared key between the sender and the receiver as shown in Figure 5. Shared Secret Key is known only by Sender and Receiver.
Message
encrypt
Message
decrypt
Sender
Message
Receiver
Figure 5 : Confidentiality
Integrity: It means, protecting the information from being modified by unauthorized parties. Digital signature and hash functions are mechanisms that could be used to ensure the integrity of the data. A Message Authentication Code (MAC) is a piece of information that appended with the massage to ensure its integrity. The code is generated mathematically by combining a key with a hash of data as shown in Figure 6. 12
Message
send
Compare if equal
receive
Hash Message
Message
Calculate Hash
Receiver
Sender
Figure 6 : Integrity
Availability: The final component of the CIA triad is the availability of the data. It means, ensuring that the authorized parties are able to access the information when needed. Denying access to the information has become a very common attack. The availability is implemented using a hardware maintenance, software patching and network optimization. Threats of the availability may be nature natural disasters, human errors, hardware failures, etc. The three principles are important, but sometimes one of them or the combination of them is more needed depending in the use-case. i.e. a financial information of the bank is needed to be protected, so the integrity of the information should be provided.
1.3. Safety and Security in V2X Safety and Security requirements are essential aspects for establishing a new technology in automotive and avionics domains, therefore, safety and security requirements are challenging V2X communication. V2X safety applications require a frequent exchange of information by means of Cooperative Awareness Messages (CAMs) or Basic Safety Messages (BSMs), which are generated, encoded and sent to all vehicles and then the corresponding actions have to be executed on receiving vehicles. So, message processing and data visualization are a key technology that influences the performance and the usability of the V2X communication system. Due to the popularity of the V2X system, it becomes the major target of the attackers, making them vulnerable to security threats, and thus affecting the safety of passengers, vehicles and roads. The research in V2X address the safety, security and the performance limitation threats to connected vehicles [6]. These three concepts are related each other as shown in Figure 7. Safety
Performance
Security
Figure 7 : Safety, Security and Performance in a system 13
The embedded chip inside the car is may prone to different security attacks. In the following are some examples: -
On-Board. The privacy of personal data such as a Personal Identification Number (PIN) of a vehicle should be secure.
-
Active physical attack. The variation in the chip’s voltage or temperature.
-
Side channel attack. Most of the side channel attack depend on the statistical analysis of the data that is obtained from the physical measurements i.e. a power consumption, timing or electromagnetic noise.
-
Counterfeit components. The automotive spare parts are attractive for counterfeits. The serial number is not enough to protect the manufacture. So, the authentication is needed to ensure that only the authenticated parts are used in a vehicle.
-
Boot security. The integrity and authenticity of executing software should be ensured. The boot mechanism has to authenticate the application before executing.
The multiple kind of attackers in V2X system has own motivation, some of them are mentioned in the following [5]: -
Falsification: the attackers may change an actual vehicle information (could be the owner of the vehicle).
-
Illegal profit: the attackers may make profit by stealing the vehicle or counterfeiting for money.
-
Insane fun and vandalism: it may motivate the attacker to make damage or vandalism to ex-company. The electronic hobbyist attacker may customize for fun.
-
Research and test purpose: the attackers may have motivations to discover the security information in a system by gaining knowledge and expertise.
-
Accidental: it may cause without any intention. It could be performed during the upgrade of the system.
So, the main major target for V2X systems is the safety and the security. The source of the message has to be trusted (trust anchor), the secure storage of the secret key and the content of the message needs to be protected from the outside interference. Which means, a secure trustworthy communication between vehicles. To provide such trusted environment, V2X system has to include a security infrastructure to authenticate the messages, a communication network providing system security between vehicles and infrastructures in the road (entities), and also an accurate analysis of security requirements is required to devise security measures that are effective and cost-effective [7]. Such trusted environment requires the use of digital signatures to provide the integrity of the message content, and also the use of certificates to authenticate the sender.
14
1.4. Solution for Security and Safety Issues in V2X: As mentioned, V2X requires a security infrastructure to guarantee an effective safeguarding of a mutual exchange authentication. Software and hardware solutions to deal with the safety and security issues in V2X communication have been invented or on-shelf solutions have been adopted to cope with the safety and security requirements. So, the different security challenges and countermeasures that mentioned above, should be taken into account by focusing on both hardware and software (algorithm level) solutions. The following are some of the solutions that are already existed to ensure the safety and the security of V2X communication. 1.4.1. Software Solutions: Software solutions include secure protocols, kernel isolation or software layers. ESCRYPT project [8] has developed software toolkits and infrastructure to secure V2X communication. ESCRYPT offers the implementation of Security Credential Management System (SCMS) and secures V2X communication by means of two ways; digital signatures which protect the massage against manipulation, and certificates which determine the trustworthy of the sender. Moreover, it provides a solution to implement secure V2X protocols in automotive embedded systems. The MILS project, which is standing for Multiple Independent Levels of Security Operating System, is issued by the EURO-MILS Consortium [9]. It aims to develop a solution for virtualization of heterogeneous resources. Mils ensures a high security based on the concepts of separation and controlled information flow. MILS based on a Separation Kernel (SK) which is a special kind of operating system. The idea of MILS to make the security-criteria part of the system.
Figure 8: MILS architecture template [10]
15
The MILS project is a system that handles information from different components with different levels of safety and security [9]. The internal MILS architecture is not visible from around the MILS system, or it is like a black box, thus it can be used to build a system that has different safety and security requirements for different components. The MILS architecture consists of three main components which are MILS core, MILS platform and partition as shown in Figure 8. The MILS core provides the primary security functionality, by proving separated partitions with controlled information flow between them. The MILS platform provides the secondary security functionality, which consists of the MILS core and optional Software (SW)/ Hardware (HW) components, that are security services which are used depending on the use-case needs. And finally, the partition component which is a unit of the separation created with MILS core [10]. It is a container which hosts the data of a resource which is enforced by MILS core. As a solution for safety and security issued, there is also Internet Protocol Security (IPsec). It is widely used to solve these issues by providing the integrity and the confidentiality of the communications of the network. IPsec runs in the third layer, and it is transparent to the application layer, thus the applications do not have to know about IPsec mechanism to be able to use it. It is based on two encapsulation protocols. The First on is Authentication Header (AH), and the second one is Encapsulation Security Payload (ESP). As disadvantages of the IPsec, it affects on the performance of the communications, because of additional processing requirements [1]. It can be work in two modes; host to host transport mode and in a network tunneling mode. As shown in Figure 9, many cryptographic algorithms used in IPsec to provide the integrity and authenticity.
Figure 9: IPsec Implementation as layer between the IP and the network interface [1]
16
1.4.2. Hardware Solutions: Vehicular environment indicates new security requirements which make classical security solutions, that typically targeting server environment, not applicable efficiently to the vehicular environment. With the potential extends of the internal and physical attackers, the software solutions have to be protected against manipulations, by means of such as Trusted Platform Modules (TPM) or Hardware Security Module (HSM) which is considered as one of the effective countermeasures [11].
Figure 10: Toward a distributed in-vehicle security system [56] Figure 10 shows the importance of the security system within the vehicle and V2X communications. TPM is a hardware chip, which is integrated within the system. If the system doesn’t include the TPM in manufacturing, it can’t be added to the system later. It provides encryption capabilities for the system and becomes the “root of trust” to the boot process. It keeps the HW drivers locked until the authentication process is done. HSM is a hardware device that can be plugged to the system or connecting to a network using Transmission Control Protocol/Internet Protocol (TCP/IP) [12], which enables managing, generating and securely storing encryption keys. In comparison, both TPM and HSM provide secure encryption capability using Rivest– Shamir–Adleman (RSA) [13] keys. On the other hand, TPM is not flexible to add it to the system if it is not added during manufacturing, while HSM is easily added to a system or a network. And thus, HSM has studied more extensively in this thesis. HSM is the harvest of the EU project “Evita”, which is a trust in-vehicle environment. HSM is designed based on a trusted platform and secure communication. Depending on the security requirements of the application, cryptography is also used in this project to enable the authenticity, integrity and the confidentiality. The communication protocols, which are used in the vehicle, are customized to hold a security payload [6]. HSM will be visited in more details in Chapter 2.
17
1.5. Research Objectives and Contribution This thesis addresses security issues related to the V2X communication in order to propose an authentication mechanism. This mechanism guarantees a cloneresistance and non-replicable ID of the vehicles by deploying physically unclonable entities, namely the Secret Unknown Cipher (SUC). Software and hardware solutions to deal with the safety and security issues in V2X communication are available as has been shown in the last section. In this thesis, the insufficiency in the state of the art of available solutions are uncovered, where this insufficiency leaves the security of parties (vehicle or infrastructure) vulnerable which in turn threats the safety of users (human beings). To overcome these limitations and to make the V2X communication more protected, the thesis brings attention to the physically unclonable entities (PUF & SUC) where their properties are presented. This thesis shows how to invest the physically unclonable entities to enhance the Hardware Security Model (HSM) to define an efficient authentication mechanism. Practically speaking, the major contribution in this thesis is: 1. A detailed study of HSM, which is a standard HW security module for V2X. Its limitations are addressed. 2. A study of the physically unclonable entities (PUF, SUC). The goal is to bring attention to their advantages and their applicability in V2X communication. This work presents the difference between PUF and SUC, where SUC is considered as an alternative of PUF. 3. Enhancing the HSM by investing the SUC. 4. The needed authentication protocols for V2X communication are defined, those protocols take the features of the SUC.
1.6. Outline The rest of this thesis is organized as follow: In Chapter2, concise yet complete summary of the Hardware Secure Model where its limitations are addressed. Chapter3 brings the attention to the physically unclonable entities and their possible role in enhancing the security in vehicular systems. The main contribution of this thesis is presented concretely in Chapter4. Horizons for future work are discussed in Chapter5. Finally, the thesis is concluded in Chapter6.
18
2
|
HARDWARE SECURITY MODULE (HSM)
V2X communication system is used mainly for an intelligent traffic management and for decreasing the traffic accidents. However, malicious attacks on embedded systems and networks between vehicles and infrastructure may have a severe impact. Thus, on-board networks and critical in-vehicle data must be secured and protected from any untrusted parties [14]. The HSM was especially designed for protecting e-safety applications such as emergency break based on communications between vehicles (V2V) or emergency call based on communications between vehicles and (traffic) infrastructures (V2I) [9]. that is used to perform cryptographic operations and to protect the cryptographic keys from adversaries and unauthorized parties. Crypto key passes through a lot of phases in its life which are: generation, secure storage, secure distribution, backup, and destruction. These crypto keys are guarded by HSM at every phase of their life cycle. The usage of HSMs can provide enhanced cryptographic throughput of the system, thus, some security and functionality requirements are properly taken into account [11]. In this chapter, the security and functionality requirements of V2X system are explained. Then it is shown the architecture, key mechanisms and the implementation of it. At the end of this chapter, a comparison between HSM and other hardware security modules is presented.
2.1. Security and Functionality Requirements of HSM: A set of security and functionality requirements have been inferred by Evita HSM project [11] to provide the security level that required for V2X communications [14] : -
Integrity and authenticity of safety-related data: the critical data should be authenticated in term of origin, content and time. And any tampering should be detectable. Integrity and authenticity of ECU/firmware installation and configuration: any addition or replacement of ECU, SW, security credential, etc. in a vehicle should be trusted and authenticated in term of origin. Secure execution environment: ECU attacks should not affect the whole system. Vehicular access control: a mechanism to control the access of data which is stored within a vehicle should be exist. Trusted on-board platform: an alternative platform should be prevented from running in an untrusted configuration. Secure in-vehicle data storage: the applications should be able to ensure the integrity and the confidentiality of stored data. Confidentiality of certain on-board and external communication: the confidentiality of SW, firmware, updates and security credential must be ensured. Also, some of sent/received of traffic messages should be certified. Privacy: it should be provided on critical data stored within the vehicle or on messages that are sent from a vehicle to outside. Interference of security functionality: the security operations should not affect the availability of the system recourses; buses, Central Processing Unit (CPU), Random Access Memory (RAM), etc. 19
Those requirements are considered in the design and the implementation of HSM architecture [11].
2.2. HSM Architecture The architecture of HSM consists of sub-modules [11], namely volatile [15] and nonvolatile memory [16] (secure storage), a set of hardware secure building blocks (cryptography HW), secure internal processor CPU and the interface to the application core as shown in Figure 11. The architecture is based on an on-chip internal connection between a standard ECU application core and the HSM. The interface of the internal connection or external connection peripherals is managed by application core.
Figure 11 : Vehicular Security Hardware Module Architecture [56] In the following, each sub-module is explained in more details: -
Secure memory. It consists of RAM and Non-Volatile Memory (NVM). RAM acts as key buffer and NVM (flash memory) contains the security data (i.e. crypto keys, certificates, etc.). Such secure storage is used to prevent unauthorized parties from manipulation or detection of critical data.
-
Cryptography HW module. It contains of a set of hardware building blocks. It is an optional block that may be included in HSM or not depending on the security requirements of the system. Following are the cryptography modules which are deployed in HSM: a. Asymmetric Crypto Engine. A digital signature is enabled in HSM to be created and verified using different hashing functions. An Elliptic-curve cryptography ECC-256 [17] signature function is provided in full and medium modules of HSM (HSM modules they will be discussed later). b. Symmetric Crypto Engine. Symmetric encryption/decryption using cipher is enabled. At least an Advanced Encryption Standard AES-128 [18] block cipher is provided in all HSM prototype modules. Generation and verification of Message Authentication Code (MAC) [19] are also 20
enabled by symmetric crypto. It is faster and less complexity from asymmetric crypto using one secret key for both encryption and decryption. c. Cryptographic hash function. Hash fingerprints and hash-based message authentication codes (HMACs) is enabled to be created and verified using hashing algorithms and a secret key. ISO 10118 WHIRLPOOL [20] is provided in full and medium HSM prototype modules. The main characteristic of a good hash function is that its computationally is difficult to reconstruct the input by knowing the stored hash value. d. Pseudo Random Number Generator (PRNG). A pseudo random number is created using a PRNG algorithms [21]. An internal physical true random number generator (TRNG) seeds the algorithm or an external TRNG is used also during the manufacturing process of the chip. Other cases that come later require a proper seed update protocol. All prototype modules of HSM provide an evaluated PRNG according to E.4 [22]. e. Internal clock. It is used as hardware-protected time reference which is synchronized with UTC time. f. Monotonic counter. It is used as a simple secure clock. It provides at least 16 to 64-bit monotonically counters together with proper access control. It is similar to Trusted Computing Group (TCG) [23] monotonic counters [24]. -
Secure CPU. It is a 32-bit internal microprocessor that handles all logics and non-time critical cryptographic functionality.
-
Secure HW interface. It enforces a well-defined access to the hardware security functionality for the application software. It provides with help of the secure CPU a message pre/post-processing, message/session control and message/session management [25].
2.3. HSM Keys Mechanism: The main motivation of HSM is to keep the crypto keys secured, thus different kind of keys and management mechanism are supported in HSM. Here are the central HSM keys [11]: Manufacturer Verification Key (MVK). It is from manufacturer module which used to verify the authenticity of HSMs. Device Identity Key (IDK). It is unique for each HSM module which enables the authentication and the verification. It is signed by MVK. OEM Verification Key (OVK). It is from Original Equipment manufactory (OEM) which enables more trust management domain and controlled by MVK. It is unique for each OEM and fixed during HSM lifetime. Clock Synchronization Keys (CSKs). They are from a trusted time reference and are used for verification. They are also controlled by MVK. 21
Storage Root Key (SRK). It is used for swapping securely internally keys to external storages. Stakeholder Keys (SxKs). They are created externally. They are for symmetric or asymmetric and for each individual usage; authentication, content protection or secure feature activation. They are also signed by MVK to increase the externally trusted level. There is a special characteristic in HSM related to key management (e.g. the authentication process and the migration of internal security key). The key is generated internally by using internal RNG. HSM supports a key use-flags sign for each individual process (i.e. signing/MAC verification, encryption/decryption of the data, time stamping, secure boot, and storage, clock synchronization, creations/transportation of the key) [11]. As shown in the Table 1 below:
Table 1: Internal key structure [11] where sign is for signature creation, verify is for signature verification etc. Use-flags sign can restrict key transport. Thus, use-flags sign can be set to determine for case of key transport which are no other location (internal), between HSMs (migration), between HSMs and trusted (OEM) and to any other locations (external). The usage of key is set by creator. It can be as “use-flags” for authorization or “trnsp_flags” for transport authorization. Additionally, some flags can’t be set freely. Use_flags can be set “internal” to be swapped out to offline storage or imported again to the same HSM. It can be also set “migratable” to be moved between HSMs. Here some use cases of HSM are shown, which are used in applications that require high level of security [26]: -
Storage of CA Keys: The most critical in a Public Key Infrastructure (PKI) [27] is the management of Certified Authority (CA) Keys thus, the CA keys are stored on HSM to be protected from unauthorized parties.
-
Secure key based on TRNG on-board: TRNG generates real-time random numbers which are used to generates the cryptographic keys. The security is mainly depended on these numbers and their predictability.
-
On-board secure key management: The usage of keys is in HW, thus, HSM is used as a secure and tamper resident device. The keys can’t be imported or exported from HSM in readable form.
-
Secure Communications: The communication with HSM must be highly secure, while HSM stores the most critical security data (keys). All provider of HSM support PCKS #11 standard. PCKS #11 is one of the most standards that 22
specifies detailed requirements for standard public-key cryptographic functions. It defines a platform-independent Application Program Interface (API [28] to cryptographic tokens such as HSM. API has the implementation of the most used of symmetric/asymmetric algorithms (i.e. AES, RSA, DES/Triple DES, etc.), encryption/decryption and hashing algorithms. -
Zeroization the Keys: HSM should erase all sensitive secure data (keys) if it detects physical tampering, anomalous electrical activity or anomalous temperature.
Figure 12: Architectural overview of HSM implementation [11]
2.4. HSM Implementation: The implementation of HSM is on a Xilinx Virtex-5 FPGA [29] . More details for FieldProgrammable Gate Arrays FPGA that is used, and other technical details are described in [11]. Figure 12 shows an overview of the HSM implementation. The mapping of the secure processor to the embedded one on the FPGA is by using a standard Linux kernel as operating system. This operating system hosts the implementation of firmware, cryptographic library and Linux kernel drivers to access the hardware. The configurable logic of the FPGA is used to implement the hardware cores of HSM, which is connected to the embedded processor via Processor Local Bus (PLB) [30]. As shown, it can be divided into: firmware, software and hardware implementation [11]. -
HSM Firmware: it is the top level that handles all communication requests (from the application and secure cores).
-
Software: It is divided into: o HSM Library: it includes all security functionality of HSM, that are used as a reference for verification and performance analysis. o Cryptographic Library: it includes all cryptographic primitives of the Security Building Blocks (SBBs) that are implemented in HW (i.e. AES-128, ECC-256, etc.).
23
o Configuration, Control and Status (CCS) module: for making the communication interface independent from the physical communication medium such CSS is used. Also, it provides the access from the application processor to the secure processor. It includes a shared RAM to buffer the commands. o Transmission Control Protocol/Internet Protocol (TCP/IP) : it is a socket-based communication between HSM and physical communication mediums. o Abstract Syntax Notation ASN.1 [31] : the connection between HSM and application processor uses a serial bus, thus all data has to be serialized between them. The data is serialized before transmitting and de-serialized after receiving by a separate layer using ASN.1 representation. -
Hardware: the implementation of all cryptographic primitives is done in hardware. More details are described in [11]. There are also three modules of HSM which is differ from each other in the cryptographic blocks depending on the security and functionality requirements of the applications.
2.5. Comparison between Three HSM Modules: There are mandatory and optional components in HSM module, depending on the usecase and the security requirements. Thus, there are three HSM modules; full, medium and light to provide cost-effective hardware. Error! Reference source not found. presents the components of three HSM variants [14], and more details are described in [14].
Table 2: Full, Medium and Light HSM Modules [14]
24
-
Full HSM module focuses on protecting the vehicle as a node in V2X communications. It provides securing V2X communications and securing connecting the external vehicle interfaces. This module provides the maximum level of security, performance and functionality comparing with the another HSM variants.
Figure 13 shows the HW implementation of the full HSM module.
Figure 13: Full HSM Hardware implementation [25] -
Medium HSM module focuses on securing in-vehicle communications (on-board communications). Figure 14 shows the HW implementation of the full HSM module.
Figure 14: Medium HSM Hardware implementation [25] -
Light HSM module focuses on securing the interactions between ECUs, sensors and actuators. Figure 15 shows the HW implementation of the full HSM module.
Figure 15: Light HSM Hardware implementation [25]
25
Figure 16 shows the implementation of three different classed of HSM in V2X communication and in-vehicle system. The use of each class depending on the cost constraint, security protection requirements and the different functionality requirements of the application.
Figure 16: EVITA hardware deployment architecture [57]
2.6. Comparison between HSM and other hardware security modules: Figure 17 shows the comparison between HSM and other hardware security module.
Figure 17: comparison between HSM and other hardware security modules [11].
26
The comparison between three version of HSM full, medium and light with Secure Hardware Extension (SHE) [32], Trusted Platform Module (TPM) [32], and Typical Cryptographic Smartcard (SmC). TPM and SmC are not applicable in automotive system, because, they lock in cost efficiency, performance, physical robustness and security functionality [11]. Besides of the secure level provided by HSM which enhances the security in V2X communications, containing a NVM in the architecture of HSM makes it vulnerable to side channel attack [33]. Such an attack make the vehicle’s ID (manufacturer verification key MVK, see section 2.3), which is saved as a key in HSM, to be clonable that increase the possibility of the replication attack [2].Therefore, the architecture of HSM has to be enhanced by more secure solution than NVM. Physically Unclonable Functions (PUFs), for instance, is considered nowadays as a practical alternative of NVM. In the next chapter, the PUF are presented and the possibility of using PUF in V2X communication are discussed.
27
28
3
|
PHYSICAL UNCLONABLE UNITS (PUF & SUC)
In consequence of increasing the information technology, it becomes more difficult to protect the data especially the critical data that should be kept secret from untrusted parties [34]. There are also different ways to attack the communication channel to get the critical data (i.e. secret keys), thus the security domain has been increased recently especially for identification. One approach handles that problem is so-called Physically Unclonable Function (PUF). PUF is a physical entity which is embodied in a physical structure. It is useful for a system that requires a high security level and usually implemented in integrated circuits. PUF is established now as secure storage of secret keys in FieldProgrammable Gate Arrays (FPGAs) [35]. Secret Unknown Cipher (SUC) is a digital PUF, and it will be described in more details in the following.
3.1. Physical Unclonable Function (PUF) Secure authentication of electrical devices becomes more difficult to achieve, due to the emerging physical attacks on systems. PUFs are a promising solution for the secure authentication problem [36]. These functions are used to generate “finger-print data” of physical devices. These devices or chips can be identified, authenticated, by means of PUFs. Also, PUFs can be used as a key generator. Last years, PUF becomes widely popular, although the PUFs circuits exhibit high bit-error rates. Thus, the recent researches focus on how to reduce the bit-error rates of PUFs [34] and the major topics concerning the PUF is the Error-Correction Code (EEC) [37]. Our research focuses on the usage of PUFs in vehicular system for identification, authentication and key generation. PUFs use the production variability to generate an output considered as finger-print of device [34] as shown in Figure 18.
Figure 18: Finger-print of device using PUFs [34] The output of a PUF (response) is influenced by the input (challenge) signal. Each single word of PUF has theoretical the following meaning [34]: Physical: If a physical entity is used physically, it becomes an adverb to unclonable. That means, the function is clonable in general but not in a physical way. Unclonable: that means a data cannot be replicated. Theoretically, PUFs are clonable.
29
Function: mathematically, it means that an input value is associated with one output value. But it is happened that may PUF produces many outputs to one input due to the noisy. Thus, more accurate definition to the PUF is the following: A PUF is a physical entity which produces an output value at least in dependence of physical structures which are hard to clone [34]. A set of security requirements should be considered in an unclonable unit [38]: o Evaluable: the ability to get the response R for any challenge C. o Uniqueness: each unit should give a different response R for the same challenge C. o Unpredictability: the response R should be difficult for adversary to predict. o One-way: It is hard to compute the challenge C for a given response R. o Tamper-evident: the unit should change its challenge/response behavior if any physical attack detected. As an advantage of PUF, we can use the PUF to enhance the security of the device. Because of two main reasons. The first one, the probability of reading the output of PUF is very low because PUF is very hard to attack by reverse engineering method. Seconds, by means of PUF, the critical data (e.g. cryptographic keys) are generated inside the chip. Thus, PUF provides a high level of security and decreases the cost of NVM (where the critical data are stored). Moreover, it eliminates the need of a secure transmit environment which is required if the critical data are generated outside the chip to transfer it to the chip. On the other hand, PUF has a bit-error problem [34] as mentioned above. These errors appear randomly and deterministically. The errors are generated by the mismatch between the parameters of the components (e.g. temperature coefficients, ageing effects, etc.). If we use the PUF as a key generator, no errors are allowed for the output. Thus, error correction data should be used and stored inside or outside of the chip, see Figure 19.
Figure 19: Helper data stored a: in the chip b: out the chip [34]
30
For the authentication usage of the PUF, error problem may be no big issue, if the distance between IDs is large enough as shown in Figure 20, the device can be identified correctly.
Figure 20: a: Small number of PUF cells; b: Large number of PUF cells [34] Different approaches have been used to configure PUFs, like Static Random Access Memory SRAM PUF [39], optical PUF [40], arbiter PUF [41], inverter-based PUF [42], digital PUF [43], etc. More details about PUF approaches are described in [34]. PUF is established nowadays as secure storage for secret keys in FPGA. Figures below show the FPGA with encrypted configuration system and PUF [34]. As shown in Figure 23, the encrypted software is stored outside the FPGA and during the enrollment phase (startup phase) it is loaded into the FPGA. In Figure 22, the key is loaded into FPGA and stored in an internal NVM. In FPGA the data can be decrypted and used to configure the structure of FPGA. So, the NVM is still needed in FPGA and the plain key is still stored somewhere inside the NVM. With the comparison with the Figure 21 which shows the usage of PUF and how no NVM is needed. The usage of PUF (i.e. SRAM cells or dictated PUF module) can increase the security in this approach. The encrypted configuration data and the error-correction data are stored in the memory chip. During the enrollment phase, which is shown in Figure 21a, and done in the secure environment, the key is sent to the FPGA, the output of PUF is used to mask the key, the system is prepared to decrypt the configuration data and the errorcorrection code generate the helper data (HD). Figure 21b shows the upload of the encrypted configuration data into the external NVM. Figure 21c presents the FPGA configuration process. The key is regenerated by using the PUF and the helper data. Then, the key is used to decrypt the configuration data that is read-in from the cryptographic engine. So, the FPGA can be configured.
31
Figure 23: Configuration of an FPGA [34]
Figure 22: FPGA with encrypted configuration system [34]
Figure 21: FPGA with PUF code protection [34]: (a) Enrollment phase: generating the helper data; (b) Storing the encrypted configuration data; (c) FPGA configuration
3.1.1. PUF applications: 3.1.1.1.
Identification:
The basic idea behind PUFs is making a finger-print for chip or device as an identifier. It depends on the mismatching between PUFs components to generate unique numbers to use it as identifier of device. The first patent was in 1999 by Lofstrom and his company ICID [34] . The idea was to generate the unique number depending on the random parameter variation of the PUF cells. For a good identification, an ID should be measured many times and in different environmental conditions to get reliable data. There are also approaches that use only characteristic PUF cells (more details about this could be found in chap.8 in [34]). Figure 24 presents the comparison of identification procedure between biometric and PUF. The similar points between them are the noisy measurements, both are hard to clone, and both are used for identification and authentication. 32
When PUF is used for identification, it replaces the externally storage of the key and eliminate the need of the internal NVM. Thus, PUF reduces the cost of the device remarkably and it provides the ID from the intrinsic properties of the chip. The identification system should be error tolerant and the EEC could be omitted depending on the tolerance of the system. The Hamming Distance (HD) is used for error correction. To increase the probability of the correct ID, the number of bits of the output should be increased as shown in Figure 20.
Figure 24: Comparison of Biometric and PUF identification [34]: (a) Enrollment fingerprint; (b) Identification fingerprint; (c) Enrollment PUF; (d) Identification PUF 3.1.1.2.
Key Generation:
It is another important application of the PUF. There are also several patents on key generation that utilize process variations to generate a secret key. These patents depend on using the output of the PUF as a key that will never leave the system and will not be visible to the outside [34]. This key is used for cryptographic purpose [44]. The generated key has to be the same for the same PUF, thus, EEC and the helper data is required as shown in Figure 25.
Figure 25: Basic concept of key generation and encryption using PUFs [34] 33
3.1.1.3.
Authentication:
PUF-based device authentication is also one of the important PUF applications. An authentication procedure for identify the binary ID codes was proposed by Lofstrom and issued in 2004 [34]. An authentication procedure is based on Challenge-Response Pairs (CRPs). A Hand-Shake Authentication Protocol (HSAP) [45] is used in like this technology.
Figure 26: Authentication procedure using challenge–response pairs [34] The sender device in the left of Figure 26 sends some questions (challenges) to the receiver device that should be authenticated. The receiver returns the answers of these questions (responses) to the sender. The sender compares the received answer with the corresponded one that is saved in a database. If they match, then the receiver will be authenticated. The response is generated by SW or HW. So, authentication procedure could be classified as shown in Figure 27.
Figure 27: Classification of authentication with PUF [34] The software-based generation uses symmetric/asymmetric algorithm. For symmetric algorithm, the CRP is stored is the database of the device or it could be dynamic updated. For each authentication process, a CRP is required and should not be reused. In the following, the CRPS list will be presented at first, then the authentication procedure is presented. Also, the advantages and disadvantages of each approach will be discussed. 34
List of CRPs in a database:
Figure 28: Device in CRP approach [34] Figure 28 shows the authentication procedure which includes three phases: o Enrollment phase: it is the first phase within the authentication procedure. Within, the ID of the chip is generated, and may also the helper data for ECC be generated and loaded into the database. o CRPs generation phase: a number of CRPs is generated and stored in the database. The number of CRPs depends on the number of authentication process of the chip or device. o Authentication phase: the final phase is to verify the authenticity of the chip by a claimed ID. It will be described in detail in Figure 29. Authentication with hardware-based CRPs generation: It is based on the PUF cells. The output depends on the input of the PUF. The PUF is like a hash function, so it should have the same important properties which are [34]: o Determinism: the same output for the same input. o Uniformity: each output should be generated in the same probability. o Predictability: the output value should not be predictable, even the output/input combination is known.
35
Figure 29: Authentication with hardware-based CRPs generation [34] The concept of the authentication procedure is shown in Figure 29. The ID of the chip is the output (response) of the PUF using 0-vector as input (challenge). o First, the chip sends the ID to the server which compares it with the ID stored in the database considering the hamming distance. o After that, the server sends a challenge vector to the chip. o The chip generates the corresponding response by PUF and sends it back to the server. o The server compares the received response with the corresponding one in the database to authenticate to chip if they match considering a certain tolerance. As advantages of this approach, no NVM is required and also no ECC is required. On the other hand, the CRPs are stored on the server and should be regenerated in a secure environment. Authentication with software-based CRPs generation:
Figure 30: Authentication with software-based CRPs generation [34] As shown in Figure 30, the cryptographic algorithm is needed in this approach of authentication. The cryptographic algorithms that are used are public-key and symmetric-key algorithm [46]. The response is the output of the cryptographic algorithm by using the challenge as input. The helper data for ECC is required to generate an error-free cryptographic key (as an output of the PUF) which is required for the cryptographic algorithm.
36
Public-key cryptographic:
Figure 31: Block diagram of a chip with public key-based CRP generation [34] As shown in Figure 31, o
In the enrolment phase: ▪ ▪ ▪
an ID of the chip is generated and stored on the server. HD is generated and stored in the server’s database for later usage. The private and public key is generated as an output of the PUF. The public key is sent to the server and stored in the database. Whereas, the private key is kept in the chip.
o In the authentication phase: ▪ ▪ ▪ ▪ ▪
The chip sends the ID to the server The server sends the HD and a random number as a challenge to the chip. The response is generated by encrypting the received challenge by using the private key. On the server, the response is decrypted using the public key. The chip is authenticated if both challenges match.
The advantages are no need to generate and to store the CRPs in the server during the enrollment phase. Symmetric-key Algorithm: In this approach, the secret of the PUFs (keys) leaves the chip and such that is not recommended, since the most important intrinsic proprieties of the PUF is to keep the critical data inside the chip and to increase the security level of the system. As shown in Figure 28, a list of CRPs is required which is also requires a secure updating environment. Thus, in the following will be presented a dynamic updating of the CRPs which is considered as a solution for the CRPs list problem.
37
Dynamic CRPs Updating:
Figure 32: Dynamic CRPs updating [34] How to update the list of CRPs, which was mentioned above, is still an open question and the target for researchers. The dynamic updating can be a solution for this problem. The most advantage is that just one CRP is stored. The new CRP is generated during the authentication phase, so there is no limitation of the number of the authentications. So, two phases are needed, the enrollment and authentication phases [34]. o
In the enrollment phase: ▪
The ID of the chip and the helper data are generated.
▪
One pair of challenge-response is generated and stored in the server database.
▪
The Response Bn should be stored in both server and chip to use it for the encryption/decryption.
o In the authentication phase: as shown in Figure 32 ▪
The server receives the ID from the chip. Then it sends the HD, challenges An which is stored in the database and An+1 which is generated by TRG to the chip.
▪
The chip generates the corresponding responses Bn, Bn+1 by PUF using the internal key. Then, both responses are merged and encrypted using Bn as an encryption key and are sent to the server.
▪
The server decrypts the received responses using also B n as a decryption key and compares the received Bn with the one that is stored to ensure the authentication of the chip.
▪
As a final and essential step in the dynamic approach, the new challenge/response An+1/Bn+1 are stored as the challenge/response An/Bn to be used in next authentication process. 38
3.1.2. PUFs in vehicular system: The clone-resistant physically unit is required to act as secure-anchor in many applications. These applications include vehicular, commercial, medical, smartphone system, IOT, etc. [38]. The facing challenge in the vehicular system is proving a highly secure and safe communication system with low-cost [38]. PUF structures, especially for existing microcontroller low-cost applications showed serious drawbacks because of their cost, aging instability, their sensitivity to the environment conditions (temperature, etc.) [38]. Thus, the using of analog PUFs is limited in real-world applications [38]. Regarding the analog PUF limitations, a digital PUF is presented. Such a PUF is known as Secret Unclonable Cipher (SUC). More details about SUC will be presented in the following.
3.2. Secret Unknown Cipher (SUC) SUC is a concept of physically unclonable units, which was developed in 2008 at IDA, TU Braunschweig [36]. The work in [36] was the first publication about the SUC concept and it is a pure digital PUF concept. The idea is to create a digital DNA-like identity by creating a random unknown cipher [47]. This technique is proposed to create a digital PUF embedded in ECU. The ECU (FPGA) should be a selfreconfigurable non-volatile hardware. In contrast of the analog PUF, digital PUFs operate consistently during the whole lifetime of the unit [47]. The challenge is to create an unpredictable or hard to predict a digital PUF. Thus, a theory of cryptographic schemes is used [36]. The focus on a light weight block ciphers is presented also in [36] to generate a digital PUF as small as possible. Figure 33 shows the principle of SUC. The internal TRG generates a random secret which is unknown to anyone and this is the importance of SUC concept.
Figure 33: The Principle of SUC [38]
39
Figure 34: Embedded SUC in EUC [47] A practical scenario for creating SUC within ECU is shown in Figure 34. A smart program or process called GENIE is injected into System on Chip (SoC) [48] for a short time by Trusted Authority (TA). It runs for just one time and selects a number of an unpredictable random cipher by consuming random bits from TRNG [49]. After a GENIE finishes, it is deleted. After that, a random selection of ciphers from a huge number of possibilities is done [47]. The created digital cipher may act as a digital PUF, which avoids the inconsistency of the analog PUF [50]. In Figure 35, a primitive protocol for using SUC is shown. TA sends the X to the chip which creates the Y using embedded SUC in it and sends it back to the TA. Where: 𝑋 = 𝑆𝑈𝐶(𝑌) .To verify the authentication of the chip, TA compares the Y which was received it from the chip with the corresponding one in its database.
Figure 35: Primitive Challenge-Response Identification Protocol of SUC [38]
40
This proposed physical unclonable unit tries to achieve a uniqueness and a high security robustness against clone attacks [38], which makes this unit attractive for many applications like the Internet of Things (IoT) networks, vehicular system, IP protection, etc. This uniqueness that is provided by SUC is called e-DNA (electronic DNA), and to provide such e-DNA, we need to implement such units in non-volatile self-reconfiguring technology. Thus, this SUC should be in a form of permanent to serve as a clone resistant physical identity unit. So, e-DNA identity should be not removed, changed, copied, modelled and simulated [51]. One of the proposed SUC is Random Stream Cipher-based SUC (RSC-SUC) [38]. Another publication, [51], shows the use of SUC in Remote Keyless Entry RKE systems as a clone resistant physical unit. There are also other publications [49], [50] show the use of SUC for identification. 3.2.1. SUC as Stream Cipher: SUC contains a chain of unknown ciphers as described above. These ciphers could be a t-functions. The following concept of the SUC depends on the T-functions. It uses some of single cycle T-functions and S-boxes. As a simple definition of Tfunction, it is a mapping which the i-th bit of the output depends on the bits 0,1, …. i of the inputs [38]. The T-function has a cycle length of 2n for n-bit integer arithmetic in Z2n, which makes them suitable as building blocks in stream ciphers [38]. It can be used as a key Stream Generator (KSG). Figure 36 shows the structure of T-function as KSG. This T-function is used in the proposed RSA-SUC to create a class of stream ciphers, each one of these classes constitutes a RSA-SUC.
Figure 36: General structure of T-function-based key stream generator [38] KSG, as shown in Figure 36, uses a secret random initial state to create its secret key sequence. But the attacker can reveal the state by a Chosen Plaintext Attack (CPA), so the use of T-function as KSG is not secure enough. The proposed solution of the weakness of using the T-function in [38] is by using m/4 random S-Boxes as 4-to-4 bits mapping for m-bits of the T-function state, so the attacker needs to find the mapping of each S-box before attacking the KSG.
41
Figure 37: Combining T-function with S-Boxes [38] Figure 37 shows the proposed solution of KSG by combining S-boxes with T-functions. The m-bits of the T-function will feed the m/4 4-bits S-boxes. The S-boxes are approved that they are optimal against the linear, algebraic and differential attacks [38]. The attackers should first get the S-boxes to reveal the m-bits coming from the Tfunction but deducting the S-boxes by just analyzing the output cannot happen while the attacker has no access to the S-boxes inputs. The proposed RSA-SUC is in non-volatile SoC FPGAs as shown in the Figure 38.
Figure 38: Concept for personalizing individual RSC-SUCs in the enrolled units [38] In [38], the proposed RSA-SUC is described in more details and also the used FPGA is described and its properties. The hardware complexity of the proposed SUC is presented also.
42
3.2.2. Using SUC in clone-resistant Vehicular RKE: The security of the Remote Keyless Entry (RKE) systems is still a curial issue in the vehicular system [51]. In [51], a proposed fabrication of SUC is presented to be used as a security anchor for RKE system. A mutual authentication protocol to manage the RKE system is also presented. This protocol is based on a digital hardware unclonable module known as SUC that is designed in low-cost to fit the vehicular industrial environment [51].
Figure 39: Proposed RKE system setup [51] Figure 39 shows the proposed two-ways RKE system deploying SUC as a clone resistant physical unit. This RFK system relies on a two-way data transmission from the vehicle key (the remote control which is embedded in the vehicle key) to the vehicle. The vehicle and the RKE should integrate the SUC units which are SUCV and SUCRKE respectively. More details are described in [51]. 3.2.3. Generic Identification Protocol by deploying SUC: In [50], a generic mutual identification protocol is presented.
Figure 40: Generic Two-Way Symmetric Mutual Identification Protocol [50] 43
As shown in Figure 40, a mutual identification between two units A and B, by means of a TA which acts as a one-time mediator, is presented. The protocol is described step by step in [50]. This protocol requires deleting and updating the input\output pairs that are used. As a conclusion of SUC, it is presented as an alternative for the analog PUF which has a limitation as mentioned above. SUC could serve as a low-cost clone-resistant digital entity in the whole life of the system without any aging or instability problem [51].
44
4
|
Enhancing the Security in V2X Communication Using Secret Unknown Cipher
After studying the HSM, PUF and SUC and addressing the pros and cons of using each one of them in V2X communication, we come now to the next part of the contribution in this thesis where an efficient authentication mechanism is proposed by investing the SUC as an ID of vehicles to enhance the security of V2X communication. Then, the needed protocols for V2X communication are defined, which take the features of the SUC. In this chapter, it is shown firstly a system module and sequence diagram of using SUC. Then, the problem of updating the list of input/output pairs is addressed. A dynamic update is proposed as practical solution. Finally, authentication protocols are defined for the best possible investment of the advantages provided by SUC.
4.1. SUC in Use 4.1.1. System Module
Libraries
SW HW
CPU
F3
TRNG
Memory HW. F1
Functional HW-Core
CM : Crypto Module
SoC
Soft. Unknown Function
Fn
F2
Figure 41: System module by deploying SUC 45
The system module that is shown in the Figure 41, gives an overview of using SUC in SoC. It consists of SoC, cryptographic module, interface and the application. The cryptographic module is needed for the cryptographic operations like encryption/decryption and hashing. It could include the cryptographic algorithm such as symmetric/asymmetric algorithms (i.e. AES, RSA, DES/Triple DES, etc.) and hashing algorithms. SUC consists of two parts; HW and SW. The HW of the SUC is embedded in the SoC (in the chip or ECU) made of the reconfigurable resources. The following process is done when the HW of the SUC is configured: -
The set of unknown functions is saved in the memory.
-
The process which is called a GENIE will be scheduled on the CPU from the instruction memory.
-
TRNG will generate a random value which is used by GENIE to select randomly a set of functions from that saved in the memory.
-
After the randomly selection by GENIE, SUC will be configured as a chain of unknown functions.
-
The GENIE will be deleted.
-
The configured SUC will be connected with CPU by a bus.
An interface is needed to make a connection between the application and the hardware of the chip. The software part of the SUC, which contains the libraries of the SUC, is included in the interface. It will be used by the application which will use the SUC as following: -
The SUC libraries will be included in the header files of the application. Thus, the application will be able to use the SUC functionality.
-
When the application will be compiled, the respective task will be aware that it has to access the SUC.
-
And finally, the task will access the SUC and be able to use its functionality.
In the scenario that will be presented. It is assumed that two chips or nodes A and B exist in additional to the server. Each node has the same module that is presented in Figure 41. The sequence diagram for this assumption will be presented next.
46
4.1.2.
Sequence diagram
The sequence diagram in Figure 43 shows the scenario of the connection and oneway authentication between two nodes A, B and the server, which is considered as a trusted authority TA, is presented in Error! Reference source not found.. Each node has an Identification Number ID. Both nodes A and B have a Main Module MM, a Crypto Module CM and the SUC. MM is the main task of the operating system, which responds for capsulation, abstraction and controlling all tasks between the system module. CM contains the crypto algorithms which is needed for the cryptographic operations. The trusted authority has a MM and CM and also it has in its database an ID (identification number) and X/Y (Input/Output pair) for each node or entity. Assuming that X is the input of the SUC and Y is the output.
ID
ID
ID
B
Trusted By: TA
A
,XA , YA
B
,XB , YB
TA Server ID
A
Trusted By: TA
. .
ID
i
,Xi ,Yi
B - B send IDB to the chip A
A IDB, I want to connect with you
- The server sends the XA and the encrypted XB/YB of B with the key CA to the chip A
- B calculates XB by using YB as input of the SUC - then sends it to the A
IDB, IDA YA, EnXA (XB, YB) YB
XB
- A sends IDB to the server to get needed info about chip B - also sends IDA to the server to ensure that is A - A calculates XA by using YA as input of the SUC - Then decrypts XB, YB by using the same XA - A sends the YB to B and waits for XB. - A gets the X’B=XB from B - then compares the X’B with XB that received from the server
if X’B == XB then B is authenticated
Figure 42: Primitive Authentication protocol for two nodes by a mediator TA
47
Sequence Diagram of System Module Node B
Server TA
Node A
MM
CM
SUC
MM
CM
SUC
MM
CM
get IDB IDB IDB, IDA
gets the corresponding XB/YB , XA/YA XB/YB, XA
EnXA (XB, YB), YA
EnXA (XB, YB)
,
YA XA
YB
calculate XA = SUC-1(YA)
XA
YB
DecXA (XB, YB) Get XB, YB
YB XB calculate XB = SUC-1(YB) X’B = XB
Compares XB that received from the server with X’B the received from B If XB == X’B then B is authenticated
Figure 43: Sequence diagram of the system module for two nodes
48
4.2. Problem of Updating CRs List and The Use of Dynamic Updating of List For the list of the Challenge Response Pairs CRPs as mentioned in chapter 3 is, how to update the list in a secure way still the most target for the research. The dynamic updating can be one of the solutions for this problem in PUF technology. The most advantage of this solution is that only one CRP is stored. The new CRPs is generated during the authentication phase, so no limitation of the number of the authentications. According to the dynamic solution that is presented in chapter 3, the following protocols for the enrollment and the authentication phase are defined depending on the dynamic generation of the X/Y pairs between one node and the trusted authority by deploying the SUC that is mentioned in the last chapter as an alternative for PUF. And then this protocol is extended to get a suitable one for making a one-way/mutual authentication protocol between two nodes by considering a server as a mediator between them.
4.3. Protocols and Implementation 4.3.1. Enrollment Protocol for a single Node Figure 44 shows the enrollment phase of the chip A with the TA. -
The ID is generated inside the chip by using a zero vector as an input of the SUC, the output of the SUC is considered as an ID of the chip; 𝐼𝐷 = 𝑆𝑈𝐶(𝑧𝑒𝑟𝑜 − 𝑣𝑒𝑐𝑡𝑜𝑟) . Then the chip sends the generated ID to the server to store it in the database. Then, the server generates the XA by TRNG and sends it to the chip. The chip generates the corresponding YA by using the SUC, where = 𝑆𝑈𝐶 −1 (𝑋) . Then the chip A sends YZ back to the server to store it. The chip doesn’t store the XA/YA Pairs.
ID ,X , Y A A A ID ,X , Y B
B
TA Server
B
A
. .
ID ,X , Y i i i The server stores the received IDA in the database The server sends the corresponding stored XA of the IDA to the chip (which is generated by TRNG)
IDA
Trusted By: TA
The chip connects with server A generates the IDA which is the output of SUC generated by 0-vector, and sends it to the server
IDA XA Y
The chip generates the corresponding YA of the received XA using SUC. The chip sends the YA to the server
The server stores the received YA in the database
Figure 44: Enrollment Protocol 4.3.2. Authentication Protocol for a single Node for a single Node
49
In Figure 45 is shown the authentication phase protocol for the chip A to be authenticated by a server (trusted authority). The steps are explained in the Figure 45. The important and the final step which is not existed in the protocols that depend on the list of CRPs (in case of using PUF) or the list of X/Y (in case of using SUC) is, to update XN/YN in the authentication process N with the new pairs XN+1/YN+1 that is needed for the next authentication process N+1. The messages that are needed for updating are presented in a green color in the protocol.
TA Server
ID
A
ID
B
,XNA , YNA ,XNB , YNB
. .
ID
i
A
,XNi , YNi
IDA - The server creates Y(N+1)A by using TRG - then sends YAN , Y(N+1)A to the chip - The server decrypts the received message using the same key Dec XNA (XNA ⊕ X(N+1)A) and get XNA = X’NA , X(N+1)A
YNA, Y(N+1)A EnXNA (XNA ⊕ X(N+1)A)
IDA Trusted By: TA
- The chip sends the ID to the server - The chip generates the two corresponding XNA , X(N+1)A using SUC - XAN , X(N+1)A are merged - then are encrypted using XNA as a key - The chip sent the encrypted message to the server
- The server compares X’NA that is received with XNA which is stored in the database, (Verify X’NA == XNA ) if they are equal then: A is authenticated by Server - As a final step, the server must update the XNA, YNA values by storing X(N+1)A as XNA and Y(N+1)A as YNA for next authentication process.
Figure 45: Authentication Protocol for a single Node
50
4.3.3. Authentication Protocol between two Nodes by one Mediator (One-wayAuthentication) The following protocol shows the authentication process between two nodes by a mediator server as a trusted authority. The node B needs to be authenticated by A (one-way protocol). The authentication process is done as presented in the Figure 46. The steps are described in the figure. As shown in the final step, B sends XB as a clear text. Here it is no problem even the attacker can get the XB and YB values, thus the YB is generated randomly and no relation between the step N and the next one N+1. So, it is difficult or impossible for the attacker to know the mechanism of generating X, Y. As the protocol above, the final step is to update the X/Y pair. ID
A
ID
B
IDB
.
Trusted By: TA
.
ID
i
,XNA , YNA
TA Server
,XNB , YNB
IDA Trusted By: TA
,XNi , YNi
B
A
- B sends the IDB to the chip A
IDB , I want to connect with you
IDB, IDA - The server generates Y(N+1)A by using TRG , - then sends YNA , Y(N+1)A - and the encrypted XNB / YNB by using XA as a key to the chip A.
YNA , Y(N+1)A , EnXNA (XNB , YNB )
YNB
- B calculates XNB by using YNB as an input of the SUC - then sends it to the A
XNB
- A calculates XNA by using YNA as input of the SUC - Then decrypts XNB, YNB by using XNA - A sends the YNB to the B, and waits the XNB from it. - A gets the XNB from B - then compares the X’NB=XNB with XNB that received from the server if X’NB == XNB then B is authenticated
IDB, need Y(N+1)B to update Y(N+1)B
EnXNB (XNB ⊕ X(N+1)B)
- A sends the IDB to the server to get needed info about the chip B, and also sends IDB to the server to ensure that is A
EnXNA (XNA ⊕ X(N+1)A)
As final step, the server must update the X/Y pair of A and B (XNA/YNA , XNB/YNB) values by storing (X(N+1)A/Y(N+1)A , X(N+1)B/Y(N+1)B) for the next authentication process.
Figure 46: Authentication Protocol between two Nodes by one Mediator (One-way-Authentication) 51
4.3.4. Authentication Protocol between two Nodes by one Mediator (MutualAuthentication) This protocol, which is shown in Figure 47, is similar to the last one. In this protocol, A should be authenticated by B also, to make a mutual authentication between A and B.
ID
A
ID
B
,XNA , YNA ,XNB , YNB
TA Server
. .
IDB
ID
i
Trusted By: TA
IDA
,XNi , YNi
Trusted By: TA
B
A IDB , I want to make mutual connection with you
- B sends the IDB to the chip A to make a secure link with it
- The server generates Y(N+1)A IDB , IDA by using TRG , then sends the YNA , Y(N+1)A and the encrypted XNB / YNB to the chip A by using XNA as a key. YNA , Y(N+1)A , EnXNA (XNB , YNB ) IDB , I want to connect with A
YNB, Y(N+1)B , EnXNB (XNA, YNA ) - B calculates XNB by using YNB as an input of the SUC - then decrypts XNA by using XNB as a key. - and compares X’NA=XNA with XNA that received it from the server if X’NA == XNA then A is authenticated
- A calculates XNA by using YNA as input of the SUC - Then decrypts XNB, YNB by using XNA
- The server generates Y(N+1)B by using TRG , then sends YNB , Y(N+1)B and the encrypted XNA /YNA to the chip B by using XNB as a key.
EnXNB (XNA), YNB
EnXNA (XNB), YNA - B sends the YNA , and the encrypted XNB to the chip A to make sure that just A can decrypt it by using XNA
- A sends the IDB to the server to get the needed info about the chip B, and also sends IDB to the server to ensure that is A
Mutual authentication
- A sends the YNB , and the encrypted XNA to the chip B to make sure that just B can decrypt it by using XNB
- A decrypts the XNB , by using XNA as a key - then compares the X’NB=XNB with XNB that received from the server if X’NB == XNB then B is authenticated
EnXNA (XNA ⊕ X(N+1)A)
EnXNB (XNB ⊕ X(N+1)B)
As final step, the server must update the X/Y pair of A and B (XNA/YNA , XNB/YNB) values by storing (X(N+1)A/Y(N+1)A , X(N+1)B/Y(N+1)B) for the next authentication process.
Figure 47: Authentication Protocol between two Nodes by one Mediator (Mutual-Authentication) 52
5
|
DISCUSSION AND FUTURE WORK
HSM is used in practice nowadays in vehicles [11] regarding its advantages, see Chapter 2. The architecture of HSM contains NVM, see Figure 11. NVM is used to store the secret keys that are used for different purposes like encryption/decryption. From the perspective of V2X communication, the most critical key is the ID of the vehicle which is saved in the HSM. NVM, however, is a prone to side channel attacks [52]. One particularly strong class of side-channel attacks is the Differential Power Analysis (DPA) [53], which allows successful key recovery from observing the power consumption during the en/decryption of several different data inputs. Such an attack simplifies cloning the vehicle’s ID which makes the V2X communication prone to security attacks e.g. replication attack [2] or Sybil attack [3]. Classical solutions to protect the content of NVMs depend on encrypt the memory using sophisticated and complex encryption algorithms [52], which are w.r.t. cost, computation and area are expensive. An alternative practical solution may be the PUFs. PUF is a security primitive, which has proprieties of a low-power, high speed and a small area [43]. PUF also has a high security propriety and is considered as a clone-resistant against the physical and side-channel attacks [43]. The SUC, which is a digital PUF, has more advantages than the analog PUFs in the context of cost, aging and stability, see the discussion in Chapter 3. Thus, using an SUC as an ID, which has been shown in Chapter3, of the vehicle will eliminate the risk of being clonable and replicable by attackers. Furthermore, this thesis not only proposes to replace the current approach of defining an ID of a vehicle (a key saved in NVM) by an SUC representing the ID, but also this thesis proposes to replace all secret keys in the HSM by SUCs to further enhance the security in V2X communication as long as the cost of NVM design and protection methods is less efficient than the design and implementation of SUC [47]. To show the significance of our proposal in V2X communication, let us recall the V2V communication scenario that is mentioned in chapter 1. The scenario was: A selfdriving car A is moving on a street, another self-driving car B broadcasting a message claiming that it is an ambulance and asking car A to slow down and to takeover the rightmost lane. The proposed secure authentication mechanism helps A to verify that B is really an ambulance. That because, the identification of B is not replicable (the ID is a SUC which is clone-resistance) and A can ask the trusted authority to verify the ID of B. Note that, when the claim of B is verified it does not mean that B is trusted by A, however, A responds according to a predefined trust policy. For instance, A will respond to a request to slowdown or to takeover the rightmost lane, but it will not respond to a request to follow B. Another example is Sybil Attack [3] where a car cannot pretend many IDs because the ID of each car is not replicable by definition. See Figure 48.
53
Figure 48: Sybil Attack This work is the cornerstone in investing the technology of physically uncolnable entities to enhance the security in V2X communication. The implementation and evaluation of the proposed solution, however, require more research and experiments to be done with a physical access to HSM models. The implementation and evaluation are, therefore, left for future work. Since authenticity is an essential pillar of any trust management system [54], this thesis could be invested to establish an efficient trust management module in the vehicle domain in future work.
54
6
|
CONCLUSION
Designing autonomous cars is the current tendency in the automotive industry which conducts more research related to this topic in different domains. Ensuring safety and security is essential requirement to design autonomous car, therefore, safety and security issues related to autonomous cars are attractive topics for scientist and research centers. However, since most of the security issues in the V2X communications are related to the lack of proper authentication mechanism to prevent unauthorized parties from hijacking an embedded computer or sending false data, this thesis addressed issues related to security in V2X communication where it showed how to combine two solutions in hand, namely the Secure Hardware Module and the Secret Unknown Cipher, to enhance the security in V2X communication. The contribution of this thesis covers the following details: 1. A detailed study of HSM, which is a standard HW security module for V2X. Its limitations are addressed. 2. A study of the physically unclonable entities (PUF, SUC). The goal is to bring attention to their advantages and their applicability in V2X communication. This work presents the difference between PUF and SUC, where SUC is considered as an alternative of PUF. 3. Enhancing the HSM by investing the SUC. 4. The needed authentication protocols for V2X communication are defined, those protocols take the features of the SUC. This work paves the way to do more research to invest the technology of physically unclonable entities in vehicular systems to establish safe and secure trust management which helps to solve some challenging issues like defining an agreement policy to make joint decisions in V2X communication environment to operate effectively.
55
56
List of Figures Figure 1 : V2X Communication System _________________________________________________________ 10 Figure 2: Automotive On-Board Network Architecture [14] _________________________________________ 10 Figure 3 : V2X System Overview ______________________________________________________________ 11 Figure 4 : CIA Security Model ________________________________________________________________ 12 Figure 5 : Confidentiality ____________________________________________________________________ 12 Figure 6 : Integrity ________________________________________________________________________ 13 Figure 7 : Safety, Security and Performance in a system ___________________________________________ 13 Figure 8: MILS architecture template [10] ______________________________________________________ 15 Figure 9: IPsec Implementation as layer between the IP and the network interface [1] ___________________ 16 Figure 10: Toward a distributed in-vehicle security system [56] _____________________________________ 17 Figure 11 : Vehicular Security Hardware Module Architecture [56] ___________________________________ 20 Figure 12: Architectural overview of HSM implementation [11] _____________________________________ 23 Figure 13: Full HSM Hardware implementation [25] ______________________________________________ 25 Figure 14: Medium HSM Hardware implementation [25] __________________________________________ 25 Figure 15: Light HSM Hardware implementation [25] _____________________________________________ 25 Figure 16: EVITA hardware deployment architecture [57] __________________________________________ 26 Figure 17: comparison between HSM and other hardware security modules [11]. _______________________ 26 Figure 18: Finger-print of device using PUFs [34] _________________________________________________ 29 Figure 19: Helper data stored a: in the chip b: out the chip [34] ____________________________________ 30 Figure 20: a: Small number of PUF cells; b: Large number of PUF cells [34] ____________________________ 31 Figure 21: FPGA with PUF code protection [34]: (a) Enrollment phase: generating the helper data; ________ 32 Figure 22: FPGA with encrypted configuration system [34] _________________________________________ 32 Figure 23: Configuration of an FPGA [34] _______________________________________________________ 32 Figure 24: Comparison of Biometric and PUF identification [34]: (a) Enrollment fingerprint; (b) Identification fingerprint; (c) Enrollment PUF; (d) Identification PUF ____________________________________________ 33 Figure 25: Basic concept of key generation and encryption using PUFs [34] ____________________________ 33 Figure 26: Authentication procedure using challenge–response pairs [34] _____________________________ 34 Figure 27: Classification of authentication with PUF [34] __________________________________________ 34 Figure 28: Device in CRP approach [34] ________________________________________________________ 35 Figure 29: Authentication with hardware-based CRPs generation [34] ________________________________ 36 Figure 30: Authentication with software-based CRPs generation [34] ________________________________ 36 Figure 31: Block diagram of a chip with public key-based CRP generation [34] _________________________ 37 Figure 32: Dynamic CRPs updating [34] ________________________________________________________ 38 Figure 33: The Principle of SUC [38] ___________________________________________________________ 39 Figure 34: Embedded SUC in EUC [47] _________________________________________________________ 40 Figure 35: Primitive Challenge-Response Identification Protocol of SUC [38] ___________________________ 40
57
Figure 36: General structure of T-function-based key stream generator [38] ___________________________ 41 Figure 37: Combining T-function with S-Boxes [38] _______________________________________________ 42 Figure 38: Concept for personalizing individual RSC-SUCs in the enrolled units [38] ______________________ 42 Figure 39: Proposed RKE system setup [51] _____________________________________________________ 43 Figure 40: Generic Two-Way Symmetric Mutual Identification Protocol [50] ___________________________ 43 Figure 41: System module by deploying SUC ____________________________________________________ 45 Figure 42: Primitive Authentication protocol for two nodes by a mediator TA __________________________ 47 Figure 43: Sequence diagram of the system module for two nodes __________________________________ 48 Figure 44: Enrollment Protocol for a single Node_________________________________________________ 49 Figure 45: Authentication Protocol for a single Node _____________________________________________ 50 Figure 46: Authentication Protocol between two Nodes by one Mediator (One-way-Authentication)________ 51 Figure 47: Authentication Protocol between two Nodes by one Mediator (Mutual-Authentication) _________ 52 Figure 48: Sybil Attack _____________________________________________________________________ 54
58
List of Tables Table 1: Internal key structure [11] ---------------------------------------------------------------------------------------------------- 22 Table 2: Full, Medium and Light HSM Modules [14] ------------------------------------------------------------------------------- 24
59
60
Acronyms AI
Artificial Intelligence
AES
Advanced Encryption Standard
API
Application Program Interface
CRP
Challenge-Response Pair
CPU
Central Processing Unit
CIA
Confidentiality, Integrity and Availability
CA
Certified Authority
CPS
Cyber-Physical System
ECU
Electronic Control Unit
ECC
Elliptic-curve cryptography
EEC
Error-Correction Code
FPGA
Field-Programmable Gate Array
HSAP
Hand-Shake Authentication Protocol
HW
Hardware
HSM
Hardware Security Module
IoT
Internet of Things
KSG
Key Stream Generator
MAC
Message Authentication Code
NVM
Non-Volatile Memory
PPIN
Personal Identification Number
PUF
Physically Unclonable Functions
PLB
Processor Local Bus
PKI
Public Key Infrastructure
PRNG
Pseudo Random Number Generator
RAM
Random Access Memory 61
RSC
Random Stream Cipher
RKE
Remote Keyless Entry
RSA
Rivest–Shamir–Adleman
SUC
Secret Unknown Cipher
SHE
Secure Hardware Extension
SCMS
Security Credential Management System
SW
Software
SRAM
Static Random-Access Memory
TCP/IP
Transmission Control Protocol/Internet Protocol
TRNG
True Random Number Generator
TA
Trusted Authority
TCG
Trusted Computing Group
TPM
Trusted Platform Modules
V2X
Vehicle to Vehicle / Infrastructure
V2V
Vehicle to Vehicle
V2I
Vehicle to Infrastructure
62
Bibliography [1] V. P. Mohammad Hamad, "Implementation and Performance Evaluation of Embedded IPsec in Microkernel OS," Hammamet, Tunisia, Sept. 2015.
[2] W. T. Z. a. J. Z. a. R. H. D. a. F. Bao, "Detecting node replication attacks in wireless sensor networks: A survey," Journal of Network and Computer Applications, pp. 1022 1034, 2012.
[3] J. R. Douceur, "The Sybil Attack," [Online]. Available: https://www.microsoft.com/enus/research/wp-content/uploads/2002/01/IPTPS2002.pdf.
[4] A. Eskandarian, Handbook of Intelligent Vehicles, Center for Intelligent Systems Research The George Washington University USA: Springer London Dordrecht Heidelberg New York, 2012.
[5] M. N. V. P. M Hamad, "Towards Comprehensive Threat Modeling for Vehicles," 2016/11.
[6] Y. R. Hendrik Schweppe, "Security issues in vehicular systems: threats, emerging solutions and standards," 2010.
[7] L. A. A. F. Olaf Henniger, Security requirements for automotive on-board networks, Lille, France: Intelligent Transport Systems Telecommunications,(ITST),2009 9th International Conference, Oct. 2009.
[8] [Online]. Available: https://www.escrypt.com. [9] V. S. Igor Furgel and T.-S. I. G. (TSYS), "Secure European Virtualisation for Trustworthy Applications in Critical Domains," 2016.
[10] S. T. B. L. (. /. D. F. f. k. I. J. M. B. D. S. (. G. B. L. B. T. (. K. M. M. P. Holger Blasum (SYSGO AG), "MILS Architecture," 2014.
[11] T. G. Marko Wolf, "Design, Implementation, and Evaluation of a Vehicular Hardware Security Module," 2012.
[12] E. O. R. T. Vogt, "Transmission Control Protocol/Internet Protocol Overview," in Advanced Internet Protocols, Services, and Applications , March 2012 .
[13] N. P. Smart, "The “Naive” RSA algorithm," in Cryptography Made Simple, November 2016.
[14] L. 2. K. R. 2. O. 3. Y. 3. H. 4. H. 5. B. 6. M. Apvrille, "SECURE AUTOMOTIVE ONBOARD ELECTRONICS NETWORK ARCHITECTURE," Budapest, HUNGARY, May 2010.
[15] B. Dipert, "Fundamentals of volatile memory technologies," September 2011. [16] D. Richter, "Fundamentals of Non-Volatile Memories," in Flash Memories, September 2014.
[17] O. O. M. O. Kovalskiy, "ELLIPTIC CURVE CRYPTOGRAPHY," July 2014. [18] E. I. Rifqi Azhar Nugraha, "Advanced Encryption Standard (AES)," January 2017. [19] J. P. Christof Paar, "Message Authentication Codes (MACs)," August 2016 . [20] V. R. Paulo S. L. M. Barreto, "The Whirlpool hashing function," January 2003. 63
[21] B. A. S. Schachinger, "Pseudo-random Number Generators," in Basic Concepts in Computational Physics, March 2016.
[22] W. Schnidler, "AIS 20 - Functionality classes and evaluation methodology for deterministic random generators," 1999.
[23] B. Berger, "Trusted computing group history," Information Security Technical Report, December 2005.
[24] K. M. C. John Thornley, "Trusted Computing Group (TCG) monotonic counters," Parallel and Distributed Processing Symposium, 2000. IPDPS 2000. Proceedings. 14th International, February 2000.
[25] A. R. H. S. R. B. M. W. T. J. W. Dr.-Ing. Olaf Henniger, "Securing Vehicular On-Board IT Systems: The EVITA Project," 2009.
[26] I. Damgård, arhus, Denmark, 1986. [Online]. Available: https://www.cryptomathic.com. [27] T. Spies, "Public Key Infrastructure," in Cyber Security and IT Infrastructure Protection , December 2014 .
[28] S. Patni, "API Platform and Data Handler," in Pro RESTful APIs, March 2017. [29] xilinx, "xilinx," 21 August 2015. [Online]. Available: https://www.xilinx.com/support/documentation/data_sheets/ds100.pdf.
[30] B. D. R. Hofmann, "Next generation CoreConnect/spl trade/ processor local bus architecture," in ASIC/SOC Conference, 2002. 15th Annual IEEE International, Rochester, NY, USA, USA, 2002.
[31] G. P. Rédei, "ASN.1 (Abstract Syntax Notation)," in Encyclopedia of Genetics, Genomics, Proteomics and Informatics, January 2008.
[32] W. K. G. K. R. L. I. M. P. Kenneth Ezirim, "Trusted Platform Module – A Survey," November 2012 .
[33] N. J. Z. Resh, "Timing and Side Channel Attacks," May 2015. [34] M. H. Christoph Boehm, Physical Unclonable Functions in Theory and Practice, London: Springer New York Heidelberg Dordrecht, 2013.
[35] A. B. Hamedi-Hagh, Field-Programmable Gate Arrays (FPGAs), February 2016. [36] C. K. W. A. M. Fyrbiak, "Construction of Software-Based Digital Physical Clone Resistant Functions," Emerging Security Technologies (EST), 2013 Fourth International Conference , Cambridge, UK, Sept. 2013.
[37] A. C.-F. Liu, "Error-Correction Code (EEC)," January 2018. [38] D.-I. A. M. Prof. Wael Adi, "Physical and Mechatronic Security, Technologies and Future Trends for Vehicular Environment," 2017.
[39] B. W. F. K. Holcomb DE, "Initial SRAM state as a fingerprint and source of true random numbers for RFID tags.," Proceedings of the conference on RFID security, 2007.
[40] R. R. T. J. G. N. Pappu R, "Physical one-way functions," 2002. [41] L. D. G. B. S. G. v. D. M. D. S. Lee J, "A technique to build a secret key in integrated circuits for identification and authentication applications.," Symposium on VLSI circuits, 2004. Digest of technical papers, 2004.
64
[42] S. S. I. G. Puntin D, "Cmos unclonable system for secure authentication based on device variability," 34th European on solid-state circuits conference ESSCIRC, 2008.
[43] T. Xu, "Digital Physical Unclonable Functions: Architecture and Applications," UCLA Electronic Theses and Dissertations, 2014.
[44] C. B. H. B. M. Hofer, "Identifikation, Authentifizierung und Schlu€sselgenerierung mittels Physical Uncloneable Functions," Informationstagung Mikroelektronik, 2010.
[45] W. Simpson, "PPP Challenge Handshake Authentication Protocol (CHAP)," in Network Working Group, August 1996.
[46] N. P. M. H. Jiang, "Public Key Cryptography," May 2016. [47] W. A. S. M. E. H. Ayoub Mars, "Random Stream Cipher as a PUF-like Identity in FPGA Environment," in Seventh International Conference on Emerging Security Technologies (EST), 2017.
[48] V. Taraate, "System on Chip (SOC) Design," in Digital Logic Design Using Verilog , May 2016.
[49] S. Mulhem, W. Adi, A. Mars and V. Prevelakis, "Chaining trusted links by deploying secured physical identities," in 2017 Seventh International Conference on Emerging Security Technologies (EST), 2017.
[50] W. Adi, A. Mars and S. Mulhem, "Generic identification protocols by deploying Secret Unknown Ciphers (SUCs)," in IEEE International Conference on Consumer Electronics - (ICCE-TW), Taiwan, 2017.
[51] A. M. W. A. S. M. Emad Hamadaqa, "Clone-Resistant Vehicular RKE by Deploying SUC," Seventh International Conference on Emerging Security Technologies (EST), 2017.
[52] M. W. a. S. M. Thomas Unterluggauer, "Securing Memory Encryption and Authentication Against Side-Channel Attacks Using Unprotected Primitives".
[53] J. J. a. B. J. P. C. Kocher, "Differential Power Analysis," in Advances in Cryptology CRYPTO, 1999.
[54] M. a. F. J. a. I. J. a. K. A. D. e. J. a. J. C. D. Blaze, "The Role of Trust Management in Distributed Systems Security," in Secure Internet Programming: Security Issues for Mobile and Distributed Objects, Berlin Heidelberg, Springer Berlin Heidelberg, 1999, pp. 185--210.
[55] B. B. P. A. Miguel Villarreal-Vasquez, Adaptable Safety and Security in V2X Systems, Internet of Things (ICIOT), 2017 IEEE International Congress: IEEE, June 2017.
[56] Renesas, "Security in Automotive Applications," 2012. [57] D.-I. O. Henniger, "Secure automotive on-board networks, Basis for secure vehicle-to-X communication," Fraunhofer SIT / Darmstadt, 2 December 2010.
[58] M. Kaiser, "Electronic control unit (ECU)," in Gasoline Engine Management, July 2015 .
65
