Research on In-Vehicle Key Management System under Upcoming Vehicle Network Architecture

: The intelligentization and connectedness of vehicles make vehicle cybersecurity an important research topic. In-vehicle key management is a critical function in vehicle cybersecurity countermeasures. After describing previous research on vehicle key management and the development trend of vehicle network architecture, a key management scheme for in-vehicle multi-layer electronic control units (ECUs) is proposed. The scheme is based on authenticated key exchange protocol 2 (AKEP2) and on-the-air (OTA) technology. Then, the key storage and trusted key usage based on secure hardware are analyzed and studied. Moreover, the AES Counter with CBC-MAC (AES-CCM) algorithm, which uses fewer keys, is introduced to in-vehicle secure communication. The simulation analysis for the proposed OTA-based key update protocol veriﬁes the protocol’s security. The validity of the hardware-based trusted key usage environment and the feasibility of the AES-CCM algorithm for the CAN FD bus are proven with corresponding experiments.


Introduction
Electrification, intelligentization, and connectedness are developing trends of modern vehicles. Intelligentization can lead to changes in the vehicle's electrical/electronic architecture, such as the concepts of a central gateway and domain controller. Electrification and connectedness, especially connectedness, will result in more attacks in the surfaces of vehicles, thus increasing the risk of the vehicle being attacked. The object of these attacks is either the operation and control functions of the vehicle [1,2], representing the most damaging attack, or information about privacy and intellectual property in the vehicle [3,4]. Cryptography is an essential method to ensure cybersecurity, and the key is the essence of cryptography [5]. Key management is extremely important for a vehicle [6]. For the complex and developing vehicle electrical system, which consists of tens of electronic control units (ECUs), studies on in-vehicle key management systems (KMS) are necessary.
The KMS has many functions, such as key generation, key distribution, key update, key storage, and key destruction. In this paper, we mainly study the functions of storage, usage, update, and destruction of vehicle keys. To the best of our knowledge, there is no complete and comprehensive research on in-vehicle KMS. The previous research mainly focused on key generation and key distribution for the in-vehicle CAN or CAN FD bus. × , × × × Woo et al. [13] , × × This paper × × , The structure of this paper is as follows: Section 2 shows the trend of vehicle network architecture. Section 3 describes the extended AKEP2-based key update scheme and the proposed on-the-air (OTA)-based key update and destruction scheme for multi-layer ECUs. Key storage and a trusted key usage environment based on hardware are discussed in Section 4. The AES counter with CBC-MAC (AES-CCM) algorithm is introduced for secure communication in multi-layer ECUs to lower the number of stored keys in Section 5. Related experiments are shown and analyzed in Section 6. In Section 7, conclusions and future work are explained.
The research methodology in this paper is based on the existing research and our best knowledge of the vehicle KMS, where some worthy issues were found such as the remote key update, key storage, and key usage. The proposed solutions and experiments are also presented. The main work in this paper is summarized as follows: 1. The frame counter is a practical method to prevent replay attacks in in-vehicle networks [7]. The key distribution method based on AKEP2 has low overhead and good real-time performance in vehicle environments [13]. Based on the research of the above two groups and OTA technology, a key management scheme involving in-vehicle multi-layer ECUs is proposed and its security properties are analyzed and verified. 2. Key storage and a trusted key usage environment are studied. The related experiment proves the availability of tampering detection based on a trusted platform module (TPM). 3. An alternative algorithm, i.e., an authenticated encryption algorithm called AES-CCM, is studied for CAN FD bus communication. This algorithm can reduce the number of keys from two to one while ensuring security. Measurement results of the execution time and bus load rate guarantee the algorithm's feasibility.

The Trend of Vehicle Network Architecture
For current vehicles in the market, their network architecture is a distributed network. Their main communication pattern is a CAN bus, and other patterns include LIN, MOST, and FlexRay. All of these vehicles have a low-performance gateway. The main function of the gateway is communication protocol transactions, for example, transforming FlexRay format data to CAN data, or transforming CAN data to LIN data. The general communication network architecture is shown in Figure 1.  the domain, then we use AKEP2 to derive keys and update keys for the in-domain network in the same way as Woo et al. in 2016; furthermore, for the encryption communication secure frames which include counter and truncated, a MAC value can be used as proposed by Lin and Sangiovanni-Vincentelli in 2012.

Extended AKEP2-Based Key Update Scheme and Proposed OTA-Based Key Update and Destruction Scheme for Multi-Layer ECUs
In this paper, the typical in-vehicle ECUs are classified as follows: gateway ECU (GECU), domain ECU (DECU), and function ECU (FECU). The related notations and nouns used in the ECUs are described in Table 2. A function ECU is an ECU that connects an actuator or a sensor. In this classification, the telematics unit is integrated in the GECU. We extend the application span of the AKEP2-based self-management scheme proposed by Woo et al. from DECU to FECU and additionally propose an OTA-based key update and destruction mechanism to realize all functions of the KMS, namely, key generation, key distribution, key storage, key update, and key destruction. When designing a specific solution, the two principles below are followed.
(1) For each vehicle, the vehicle manufacturer should manage as few keys as possible. Through this principle, the total number of keys which are managed by the manufacturers is reduced.
(2) For different vehicles of the same product series, their keys should be different. Through this principle, security incidents in which a key leak for one vehicle leads to a large number of key leaks for several are avoided.

Extended AKEP2-Based Key Update for Multi-Layer ECUs
Woo et al. proposed a security architecture to realize key generation, key distribution, and key update based on long-term keys, the AKEP2 algorithm, and a KDC in 2016 [13]. Its application span can be extended, and, in this paper, it is named the in-vehicle key self-management scheme. Keys stored in the ECUs of each layer are shown and explained in Table 3.
In the in-vehicle key self-management scheme, the session key is derived by the KDF, which requires the input of a nonce and long-term key. The session key is distributed and updated by the AKEP2 algorithm and a KDC. For GECU, the long-term key can be stored by the TPM storage mechanism. For DECU or FECU, the long-term key is stored in a hardware security module (HSM). For long-term key update and revocation, we can use an OTA-based management scheme. Table 3. Keys and functions included in the ECUs of each layer.

ECU Layer
Keys Included and Explanation GECU 1. Long-term key. One GECU long-term key and some DECU long-term keys are included. Every vehicle has a unique GECU long-term key; 2. Vehicle manufacturer public key. One vehicle manufacturer public key is included; 3. Session key. One session key to DECUs; 4. KDF; 5. Vehicle's own certificate; 6. CRL, the list consists of invalid certificates of vehicles, suppliers, and telematic service providers (TSP).

DECU
1. Long-term key. One GECU long-term key, one DECU long-term key, and some FECU long-term keys are included. Every DECU has a unique DECU long-term key; 2. DECU supplier public key. One supplier public key is included. Different DECUs have different DECU supplier public keys; 3. Session key. One session key for GECU and DECUs, and one session key for FECUs are included; 4. KDF.

FECU
1. Long-term key. One DECU long-term key and one FECU long-term key are included; 2. Session key. One session key for DECU and FECUs; 3. FECU supplier public key. One supplier public key is included; 4. KDF.

Proposed OTA-Based Key Update, Key Destruction, and Certificate Revacation
The key management system mainly implements two functions via OTA technology. One is long-term key update or destruction. The other is the certificate revocation, which is implemented by updating the CRL. Figure 4 shows the related entities and the message stream. In the in-vehicle key self-management scheme, the session key is derived by the KDF, which requires the input of a nonce and long-term key. The session key is distributed and updated by the AKEP2 algorithm and a KDC. For GECU, the long-term key can be stored by the TPM storage mechanism. For DECU or FECU, the long-term key is stored in a hardware security module (HSM). For long-term key update and revocation, we can use an OTA-based management scheme.

Proposed OTA-Based Key Update, Key Destruction, and Certificate Revacation
The key management system mainly implements two functions via OTA technology. One is long-term key update or destruction. The other is the certificate revocation, which is implemented by updating the CRL. Figure 4 shows the related entities and the message stream. A procedure to update an FECU long-term key for the n-th time based on OTA technology is proposed and described below. Figure 5 is the simulation stream of the proposed long-term key update. Role-M, role-G, role-D, and role-F stand for manufacture, GECU, DECU, and destination FECU, respectively. Steps 1-6 show the nonce transmission, while steps 7-12 show the update process of the FECU's n-th long-term key. Notations and nouns used in Figure 5 are explained in Table 4. A procedure to update an FECU long-term key for the n-th time based on OTA technology is proposed and described below. Figure 5 is the simulation stream of the proposed long-term key update. Role-M, role-G, role-D, and role-F stand for manufacture, GECU, DECU, and destination FECU, respectively. Steps 1-6 show the nonce transmission, while steps 7-12 show the update process of the FECU's n-th long-term key. Notations and nouns used in Figure 5 are explained in Table 4.

Notation or Noun Description
Manu, k_manu Manufacturer (Manu) and its public key Sup, k_sup Supplier (Sup) and its public key kij the (n − 1)-th shared long-term symmetric key between entity i and entity j by default. In this paper, m, g, d, and f represent manufacture, GECU, DECU, and FECU, respectively. {p}_k Encrypt plaintext p by key k, which is either a symmetric or an asymmetric key. n n-th update.

Notation or Noun Description
Manu, k_manu Manufacturer (Manu) and its public key Sup, k_sup Supplier (Sup) and its public key kij the (n − 1)-th shared long-term symmetric key between entity i and entity j by default. In this paper, m, g, d, and f represent manufacture, GECU, DECU, and FECU, respectively. {p}_k Encrypt plaintext p by key k, which is either a symmetric or an asymmetric key. n n-th update.
Notation "." connects different contents. nonce-1 New nonce fhash() Hash function inv(k_i) k_i represents entity i's public key; inv(k_i) means i's private key. nonce_ok, ok_F Response message from FECU ok_D Response message from DECU Table 5 explains the procedure of the FECU long-term key update for the n-th time. The security analysis and simulation experiment of the procedure are presented in Section 6.1. The in-vehicle key can be destroyed by an OTA-based mechanism when a vehicle needs scrapping. The procedure is the same as key update, except for the contents transmitted between the vehicle manufacturer and the vehicle.
Certificate revocation can be achieved by updating the CRL. In the OTA-based key management scheme, when the vehicle is scrapped, a vehicle certificate can be revoked by updating the CRL in the manufacturer's server. Similarly, if the vehicle manufacturer, supplier, or TSP claims that its certificate is invalid, its certificate can be revoked by updating the CRL in a vehicle gateway.

Application of Hardware-Based Key Storage and Trusted Key Usage in Proposed KMS
In an embedded system such as vehicle ECUs, key storage mainly relies on hardware isolation or encryption by a key encryption key (KEK). Usually, a hardware security module (HSM) is used to store a session key and provide an isolated environment for secure operations [14]. Except for key storage based on a KEK, TPM utilizes a trust anchor and integrity measurement function to construct a trusted key usage environment on a host microcontroller. Table 6 shows the differences between them. HSM is a simpler and low-cost method compared to TPM. The security of HSM depends on the hardware security. The secure access mechanism and dedicated memory mapping of HSM and other security strategies protect the data in the HSM. TPM is not integrated in a microcontroller, but is connected to the host microcontroller via an Inter-Integrated Circuit (I 2 C) bus or other kinds of buses.
KEK is securely stored in the TPM. The ciphertext of the key is stored in a specific area in the host microcontroller because the read-only memory (ROM) of the TPM is limited. However, the area where the key ciphertext is stored is not as secure as the inside of the TPM. In order to prevent tampering with the key ciphertext or unauthorizedly reading the decryption result using KEK, it is necessary to construct a trusted key usage environment on the host microcontroller. The trusted environment can be built by measuring the integrity of the host's bootloader file and the operation system (OS) file using TPM. Figure 6 shows the integrity measurement function of TPM. HSM is a simpler and low-cost method compared to TPM. The security of HSM depends on the hardware security. The secure access mechanism and dedicated memory mapping of HSM and other security strategies protect the data in the HSM. TPM is not integrated in a microcontroller, but is connected to the host microcontroller via an Inter-Integrated Circuit (I 2 C) bus or other kinds of buses.
KEK is securely stored in the TPM. The ciphertext of the key is stored in a specific area in the host microcontroller because the read-only memory (ROM) of the TPM is limited. However, the area where the key ciphertext is stored is not as secure as the inside of the TPM. In order to prevent tampering with the key ciphertext or unauthorizedly reading the decryption result using KEK, it is necessary to construct a trusted key usage environment on the host microcontroller. The trusted environment can be built by measuring the integrity of the host's bootloader file and the operation system (OS) file using TPM. Figure 6 shows the integrity measurement function of TPM.

Application of AES-CCM Algorithm in Proposed Multi-Layer ECU Communication
As mentioned above, Woo et al. used an encryption key and authentication key to calculate ciphertext and MAC separately. Under the premise of ensuring the secrecy of keys, the same key can be used for both the authentication and encryption operations. This is the concept of the authentication encryption algorithm [17]. It has the advantage of reducing the number of keys used, which makes sense in embedded systems with limited storage space. In the TLS1.3 specification, authenticated encryption with associated data (AEAD) algorithms are adopted as the only stream encryption algorithms. As one of the AEAD algorithms in TLS1.3, AES-CCM has a short operation

Application of AES-CCM Algorithm in Proposed Multi-Layer ECU Communication
As mentioned above, Woo et al. used an encryption key and authentication key to calculate ciphertext and MAC separately. Under the premise of ensuring the secrecy of keys, the same key can be used for both the authentication and encryption operations. This is the concept of the authentication encryption algorithm [17]. It has the advantage of reducing the number of keys used, which makes sense in embedded systems with limited storage space. In the TLS1.3 specification, authenticated encryption with associated data (AEAD) algorithms are adopted as the only stream encryption algorithms. As one of the AEAD algorithms in TLS1.3, AES-CCM has a short operation time and is considered secure [18]. Furthermore, AES-CCM has a good reuse of the AES code and this also means a lower cost of future AES-CCM hardware modules. Figure 7 shows the steps for calculating the ciphertext and MAC values proposed by Woo et al. and the steps of the AES-CCM that we studied. Table 7 shows the meaning of the notations in the steps in Figure 7. The parameters and functions in Figure 7b are from or derived from the National Institute of Standards and Technology (NIST) Special Publication 800-38C [19].
The steps in Figure 7a,b show two independent algorithms for realizing confidentiality and authentication between two ECUs. With respect to the AES-CCM algorithm we studied, when j is equal to 2, steps 5* and 6* are executed in the sender ECU. After the receiver ECU receives C * ||T * , steps 7*, 6*, and 8* are executed successively. In the case that j is equal to 2, the security requirements are data confidentiality and entity authentication [13]. The difference between our study in Figure 7b and the former study in Figure 7a is that we use one key as opposed to two keys to calculate the ciphers and authentication value, which may mean less storage and easier management. time and is considered secure [18]. Furthermore, AES-CCM has a good reuse of the AES code and this also means a lower cost of future AES-CCM hardware modules. Figure 7 shows the steps for calculating the ciphertext and MAC values proposed by Woo et al. and the steps of the AES-CCM that we studied. Table 7 shows the meaning of the notations in the steps in Figure 7. The parameters and functions in Figure 7b are from or derived from the National Institute of Standards and Technology (NIST) Special Publication 800-38C [19].  Table 7. Notation used in steps in Figure 7.

Notation Description
ij ECU ECU using identity "i" and belonging to the subnetwork with ASL grade "j" [13]. M Message; it is plaintext used in Woo et al.'s work [13]. EKk Encryption key of k-th session [13]. AKk Authentication key of k-th session [13]. T* P's corresponding tag. We define that T* is equal to 0 (T MSB (S )) τ ⊕ [19]. T*' P's corresponding tag calculated by receiver ECU.

Analysis Based on Provable Security Theory
The principle of the provable security theory is to attribute the security of the cryptosystem to the security of the basic modules.
Confidentiality. Confidentiality is ensured because kmf_n is encrypted by kmf_(n − 1). As kmf_(n − 1) is stored and used in the secure hardware module of manufactures and the FECU, in our scheme, we assume it is secure.
Source authentication and integrity. The two properties are ensured because the ciphertext of kmf_n is signed successively by the supplier and vehicle manufacturer. Moreover, the public keys or certificates used for verifying signatures are secured by the HSM, TPM, and CRL of entities.
Prevention for replay attacks. In our scheme, nonce and identifier n are used to prevent replay attacks.

Simulation Analysis According to Dolev-Yao Model
Dolev-Yao model analysis uses a formula to analyze the security property of a certain protocol, especially one which that contains public key encryption. The Dolev-Yao model has two basic assumptions: the cryptography is secure, and the intruder has full control over the network. SPAN is a software that supports the security analysis of a protocol according to the Delov-Yao model [22]. Figure 8 shows a part of the code for the OTA-based protocol in HLPSL under the SPAN software [23]. After the definitions of each entity and the sessions, the environment and security goals are defined successively, as presented in Figure 8. The goal is the secrecy of Na and x, authentication between manufacture and the FECU, and authentication between manufacture and the DECU. Under the SPAN software, the simulation for authentication can analyze not only the identification of two entities, but also the prevention ability for replay attacks.  The ATSE tool integrated in SPAN was used to analyze the proposed protocol [24]. The simulation analysis result is shown in Figure 9. The proposed OTA-based protocol is safe, and the goal shown in Figure 8 was realized as specified.

Tamper Detection Experiment Based on TPM
In this paper, Raspberry Pi 3 was used to simulate a vehicle gateway which has a Linux OS and connects the Infineon TPM SLB9645 expansion board via an I2C bus. The TPM was programmed to perform the integrity check of a critical file after the Linux OS boots. The original file and the tampered file were tested separately, and the result is shown in Figure 10. The results show that the OS can effectively perform file integrity detection based on the TPM. Based on the same principle and the trust chain extension, a trusted environment for key usage can be built by performing integrity verification on codes of bootloader files and OS files. The results show that the OS can effectively perform file integrity detection based on the TPM. Based on the same principle and the trust chain extension, a trusted environment for key usage can be built by performing integrity verification on codes of bootloader files and OS files.

Security Analysis and Experiment for AES-CCM Algorithm on CAN FD Bus
The security of the AES-CCM algorithm was analyzed [18]. Although there are still some criticisms of the algorithm, it was adopted as the recommended standard of NIST [19]. Thus, we considered it to be secure in this paper.
The execution time of the AES-CCM algorithm in an AURIX TC297 microcontroller, the execution time of secure communication, and the bus load rate were measured. In the experiment, the compiler was a TriCore Eclipse IDE v4.3r3, and more devices are shown in Figure 11.
(c) The results show that the OS can effectively perform file integrity detection based on the TPM. Based on the same principle and the trust chain extension, a trusted environment for key usage can be built by performing integrity verification on codes of bootloader files and OS files.

Security Analysis and Experiment for AES-CCM Algorithm on CAN FD Bus
The security of the AES-CCM algorithm was analyzed [18]. Although there are still some criticisms of the algorithm, it was adopted as the recommended standard of NIST [19]. Thus, we considered it to be secure in this paper.
The execution time of the AES-CCM algorithm in an AURIX TC297 microcontroller, the execution time of secure communication, and the bus load rate were measured. In the experiment, the compiler was a TriCore Eclipse IDE v4.3r3, and more devices are shown in Figure 11. The set-up of the experiment is shown in Table 8. For a more accurate result, we did the measurement 10,000 times to get an average execution time of the algorithm and secure Figure 11. Experiment devices.
The set-up of the experiment is shown in Table 8. For a more accurate result, we did the measurement 10,000 times to get an average execution time of the algorithm and secure communication. The length of the AES-CCM output was chosen for two reasons. Firstly, 8 bytes was chosen because it can be compatible with a CAN frame which is already defined by manufacturers. Another reason is that the CAN FD frame supports some values of the length in the ISO specification. That is to say, the Data Length Code (DLC) values 8, 10, 12, 13, 14, and 15 stand for 8 bytes, 16 bytes, 24 bytes, 32 bytes, 48 bytes, and 64 bytes, respectively. The results are shown in Figure 12a.  ( The result is 97.6% of a measurement time of 430 μs. The difference rate of 2.4% is mainly because the stuffing bits in the transmitted CAN FD frame are not included in Equation (2). After the comparison of theoretical values and experimental values, the experimental results are reasonable.
The result shows that, as the plaintext increases from 4 bytes to 56 bytes, the encryption time is from 66 μs to 129 μs. The decryption costs almost the same time, while the secure communication time is from 203 μs to 430 μs. The execution time of the AES-CCM algorithm is acceptable for invehicle embedded systems. Moreover, the time can be further reduced by an AES-CCM hardware module, which is a more efficient method to realize the algorithm. From the ratio of the secure communication time to the ordinary communication time, the time consumption of the secure communication can be compared. The ratio r varies between 2.26 and 2.82 according to Equation (3) and values in Figure 12a.  With Equation (1) and the encryption and decryption time in Figure 12a, the secure communication time can be calculated. Taking 56 bytes and 8 bytes as examples, according to the CAN FD specification, if stuffing bits are not included, there are about 27 bits translated at the arbitration baud rate and 543 bits translated at the data baud rate. It is easy to get the following: τ sec _com = 129µs + (27 × 2 + 543 × 0.2)µs + 128µs = 419.6µs. ( The result is 97.6% of a measurement time of 430 µs. The difference rate of 2.4% is mainly because the stuffing bits in the transmitted CAN FD frame are not included in Equation (2). After the comparison of theoretical values and experimental values, the experimental results are reasonable.
The result shows that, as the plaintext increases from 4 bytes to 56 bytes, the encryption time is from 66 µs to 129 µs. The decryption costs almost the same time, while the secure communication time is from 203 µs to 430 µs. The execution time of the AES-CCM algorithm is acceptable for in-vehicle embedded systems. Moreover, the time can be further reduced by an AES-CCM hardware module, which is a more efficient method to realize the algorithm. From the ratio of the secure communication time to the ordinary communication time, the time consumption of the secure communication can be compared. The ratio r varies between 2.26 and 2.82 according to Equation (3) and values in Figure 12a.
When the frequency was set to 100 messages per second, the largest bus load rate was no more than 1.2%. The values are acceptable considering that the total bus load rate usually reaches 50%. Moreover, the increment values of ROM and random access memory (RAM) based on codes from tls.mbed.org are 27,686 bytes and 8688 bytes, which occupy only 0.33% of the total ROM and 0.31% of the total RAM.

Conclusions
This paper summarizes previous research on in-vehicle KMS and studies an OTA-based key update protocol, key storage, and trusted key usage environment, along with application of the AES-CCM algorithm in in-vehicle communication.
Considering the developing and layered in-vehicle network architecture, a key update scheme based on AKEP2 and OTA technology was proposed for the first time. SPAN software is an efficient tool to find potential attacks on cryptographic protocols. Simulation analysis in SPAN verified the security properties of the proposed OTA-based protocol. The properties verified were key confidentiality, authentication, and resistance to replay attacks. Key storage and a trusted key usage environment based on the secure hardware were discussed. Experiments on a microcontroller with TPM SLB9645 showed that the OS can recognize the behavior of tampering with a certain file by verifying the integrity of critical files or configurations, thus constructing a trusted key usage environment. AES-CCM can decrease the number of used keys. The experiment between two AURIX TC297 microcontrollers showed that the time consumption and bus load consumption of the CAN FD frame with AES-CCM are acceptable for the in-vehicle environment.
Our research can provide a reference for in-vehicle secure communication protocols and lifecycle key management for vehicle manufacturers. Future research will include lightweight secure protocols and a performance evaluation of in-vehicle Ethernet communication, as well as the implementation and optimization of trusted environment and key management based on TPM.

Conflicts of Interest:
The authors declare no conflict of interest.