Key management and data re-encryption schemes for secure in-vehicle network

Abstract

With the development of intelligent vehicles, in-vehicle security and privacy receive considerable attention from researchers and drivers. The data stored in a vehicle control unit (VCU) may contain privacy-sensitive content, which may be exposed to unauthorized devices or attackers due to the structural problems of the in-vehicle network. To overcome this problem, data can be encrypted with the target module’s key before being transmitted to the in-vehicle network. However, this may lead to another efficiency problem.

In this study, we propose a model that adopts the proxy re-encryption (PRE) scheme to the in-vehicle network. This is called privacy-enhancing in-vehicle network key management (PINK). In the proposed model, the data stored in the VCU is encrypted with a master key. In addition, when the stored data is requested by a node, it is transformed into a ciphertext that can only be decrypted with the node’s key using the PRE scheme. Moreover, for the case in which a special group of nodes request the data several times, simultaneously, a group-based key management scheme i provided. Further it is demonstrated using simulations that the proposed PINK scheme can be efficiently applied to the in-vehicle network.

Keywords

In-vehicle network proxy re-encryption privacy key management

1 Introduction

In the near future, the in-vehicle network is expected to be one of the key technologies for intelligent vehicles. Using the in-vehicle networks, many electronic control units (ECUs), driver-aiding devices, and vehicular accessories can internally exchange various data via serial buses [1]. In addition, this data is processed by applications such as advanced driver assistant system and many other sophisticated applications [2]. This type of data can include private information as well as a vehicle is considered to be closely related to person’s personal life. However, the structural problems of the in-vehicle network can cause such data to be leaked when portable or communication devices, which are connected to an outer network are used.

The in-vehicle network consists of a vehicle control unit (VCU), several nodes, and buses. The VCU is a powerful on-board computer, which receives commands from the remote operator and relays them to the vehicle. The VCU has a processor as well as memory and storages; thus, it can store the data created by the nodes and that transmitted from the outside via the communication modules. Nodes constitute an in-vehicle network that includes ECUs, modules, and portable devices that are plugged in the on-board device (OBD) ports. Furthermore, the devices that communicate using wireless channels such as Bluetooth and Zigbee are capable of participating in the in-vehicle network.

For the original model of the VCU, all the data stored in it is not encrypted. Thus, when the requested data is broadcasted to the nodes via the bus, it can get delivered to a portable device plugged in the OBD port. In addition, if the wireless communication devices participate, the raw data can be exposed to the wireless channel, and an adversary may eavesdrop on the transmitted data. Furthermore, if the VCU is compromised, the stored data can be exposed, and the privacy-sensitive data can be abused by attackers.

To solve these problems, the following solutions can be considered:

A key shared only between the VCU and all the valid nodes is prepared. Further, the data is encrypted with the shared key before it is stored in the VCU. When a node requests for this data, it is broadcasted and decrypted at the destination.

Each node and the VCU have their own keys, and the data is encrypted with the VCU’s key before it is stored in the VCU. When a node requests for this data, it decrypted and encrypted with the node’s key by the VCU. Consequently, the required data is broadcasted and decrypted at the destination.

For the first solution, when a node is withdrawn or attached, the shared key should be updated for the forward and backward secrecies [3]. In addition, the key should be changed due to other reasons, such as the key being compromised. When the key is changed, the encrypted data in the VCU should be decrypted and re-encrypted with the new key, which forms a tremendous computational overhead.

The efficiency problem may get resolved using the second solution. However, in this case, it takes too long to decrypt the stored file, encrypt it with another key, and decrypt it again at the final node. If the data in the VCU is required for an urgent purpose, these procedures may cause computational overhead and time delay, thereby causing more severe problems.

In this study, these possible problems are resolved using a proxy re-encryption (PRE) scheme to store data in the VCU and to deliver it to each node when requested. In the PRE scheme for the in-vehicle network model used in this study, the entire data is encrypted with a master key, which is kept solely by the VCU. In addition, when the stored data is used by a node, it is first re-encrypted by a proxy and is transformed to another ciphertext that can be decrypted with the node’s key. Note that there are no decryption and encryption procedures in the re-encryption process performed by the proxy; thus, it time required for re-encryption in this case is less as compared that in the second solution.

If the PRE scheme is adopted to the in-vehicle network, the data is not only stored in the VCU but also delivered to each node, safely and efficiently. However, with the use of PRE, a new efficiency-related problem can occur. For example, if the data is required by several nodes simultaneously, many versions of the encrypted data should be created, which may cause higher computational cost and more time delay. To solve this problem, a group-based key management scheme is proposed in this study.

In this study, this structure of the in-vehicle network is called privacy-enhancing in-vehicle network key management (PINK). The remainder of this study is organized as follows. The related works are discussed in Section 2, and the in-vehicle network and the PRE scheme are introduced in Section 3. Further, the main algorithm of the PINK scheme is proposed in Section 4, and this proposed scheme is analyzed with simulation results in Section 5. Finally, this study is summarized in Section 6.

This study focuses on designing concrete processes for the PINK scheme and demonstrating using simulations that they can be adopted to the in-vehicle network. The work is the extended version of a short conference paper [4].

2 Related works

Most research works on this topic focus on the lack of the security while addressing the security and privacy issues of the in-vehicle network, and propose various security solutions [2 , 6]. However, one of the most important aspect of a secure network is key management, which has been rarely addressed by any study. In this section, the related works are listed and their limitations are summarized.

Basically, for the in-vehicle network, the messages are broadcasted and not encrypted. Thus, the ECUs and devices connected to the network can access the transmitted data [2, 7]. Using this property, various researchers highlighted these vulnerabilities and tried providing security solutions against attacks. However, most of the security solutions focused on authentication [8, 9] or availability [5]. Moreover, privacy issues in the data transmitted through the in-vehicle network are rarely addressed.

Enck et al. demonstrated the possibility of privacy infringement by observing data transmission via the controller area network (CAN) bus [10]. Further, Rouf et al. highlighted that tire pressure information can be eavesdropped in the tire pressure monitoring system (TPMS) using experiments [11]. Moreover, Checkoway et al. proved that attack on the in-vehicle network can be conducted not only locally but also remotely [12]. To solve the problems, Schweppe et al. provided schemes for guaranteeing the security and privacy of data in the in-vehicle network by proposing a new message broadcast policy [13]. However, these schemes cannot accomplish the privacy problem because the data delivered via the CAN bus are plaintexts.

Groll et al. [14] proposed a key management scheme for the in-vehicle networks. For security and efficiency, they suggested a method that divides the components for the in-vehicle network into trusted and untrustworthy groups, and employs a symmetric key shared by only the trusted group for encrypting and decrypting the privacy-sensitive data. However, they did not consider the key update issue during the joining and removal of devices. This is a critical issue because removable vehicular accessories that have been connected to the in-vehicle network may expose the shared symmetric key.

This study addresses the confidentiality of the data stored in the VCU, which has the main storage for the shared data of the devices in the in-vehicle network. For an efficient management, the PRE scheme is adopted for encrypting the shared data, and a new key management scheme is provided.

3 Preliminaries

3.1 In-vehicle network

In this section, the structure of the in-vehicle network is described briefly. For better understanding, an example of CAN is provided, which is the most popular type of in-vehicle network. Further, the security and privacy issues in the CAN are highlighted.

3.1.1 Structure of in-vehicle network

As shown in Fig. 1, the in-vehicle network is composed of a gateway, more than 70 ECUs, various devices, and buses [7]. ECUs are embedded devices that monitor a vehicle’s state with various sensors and allow the powertrains to take actions with actuators. The ECUs are composed of specific modules, such as engine control, transmission control, and oil supply control. For the inputs, not only is the data measured by each sensor but the signals from other devices are also used to determine the actions.

Fig.1

Example of Controller Area Network (CAN).

As shown in Fig. 1, there are two types of buses: high-speed and low-speed CAN buses. The devices on the high-speed bus, whose speed is about 500 kb/s [2], are time-critical modules, such as engine control module and brake control module; while the devices on the low-speed bus are less time-critical. When a signal is sent from a module, it is broadcasted to not only other modules on the same bus, but also the ones on the other bus via the gateway.

Figure 2 shows a data frame for CAN 2.0B. The CAN was developed in the early 1980s; thus, it has been updated and modified by many researchers. Nowadays, the CAN 2.0A and 2.0B protocols are adopted to the vehicles, in which the data frame in the CAN 2.0B protocol is an extended version of the one in the CAN 2.0A protocol (i.e., in the data frame of CAN 2.0A, there is no extended identifier field in the arbitration field of 18 bits size).

Fig.2

CAN 2.0B Frame.

3.1.2 Security and privacy issues

As discussed in the previous section, the CAN data frame is broadcasted to all the modules via buses. Therefore, every module in the in-vehicle network can receive the CAN data via the bus. Thus, if a portable device is plugged in the OBD port, or if a malicious device is connected to the in-vehicle network, they can read the broadcasted data.

As shown in Fig. 2, there is no field related to confidentiality or authentication, which may allow various security and privacy attacks. The data is not encrypted; thus, all the nodes in the in-vehicle network can sniff the broadcasted frames. If such frames contain privacy-sensitive data, and a malicious device is plugged in the OBD port, the privacy of the driver may be infringed. Koscher et al. demonstrated that adversaries can discover many functions of selected ECUs [5].

3.2 Proxy re-encryption

PRE is a scheme that enables a proxy to transform a ciphertext that can be decrypted by one user into another ciphertext that can be decrypted by another user without decryption [15]. A plaintext is not revealed in the process of PRE; thus, the confidentiality of the ciphertext is preserved. It is observed that the PRE scheme is based on public key cryptography. The basic concept of the PRE scheme is shown in Fig. 3.

Fig.3

Proxy Re-Encryption.

Let pk_A and sk_A be Alice’s encryption and decryption keys and let pk_B and sk_B be the ones for Bob. Note that sk_A and sk_B are kept only by Alice and Bob, respectively. Moreover, for a message M, let {M} _{pk
_X} be an encrypted version of M that can be decrypted with sk_X, where X ∈ {A, B}.

Conventionally, to allow Bob to decrypt {M} _{pk
_A}, Alice first decrypts with sk_A and encrypts with pk_B, or may employ a third party, which is called proxy. In terms of the latter case, Alice first splits sk_A between Bob and the proxy, {M} _{pk
_A} is partially decrypted by the proxy and is finally decrypted by Bob [16 –18]. However, this approach requires Bob to have an additional secret key for every delegation that he accepts [19]. To accomplish this, the PRE scheme is proposed.

The concept of the PRE scheme is as follows. First, there are four parties: a delegator (Alice), a delegatee (Bob), a key distributor, and a proxy. The aim of the key distributor is generating and distributing keys which include various participants’ keys (pk_X and sk_X) and the re-encryption key (rk). As shown in Fig. 3, let us consider the case that Alice delegates the access authority of the message M to Bob. The aim of the proxy is to re-encrypt {M} _{pk
_A} to {M} _{pk
_B} using only rk without decryption.

The PRE scheme was first proposed by Blaze, Bleumer, and Strauss [20], the PRE scheme has received considerable attention, and many researchers have proposed more developed PRE schemes. Generally, the PRE scheme can be categorized into two types: unidirectional PRE and bidirectional PRE. The bidirectional PRE scheme allows the users to re-encrypt the ciphertext many times, while the unidirectional PRE allows that only once. The first one proposed is bidirectional PRE. However, the bidirectional PRE scheme has a few shortcomings: the delegation in the scheme is transitive and the delegator’s secret key can be completely recovered if the proxy and the delegate collude. Due to these problems, secure storages employ the unidirectional PRE schemes [21]. In the proposed scheme, we also use the unidirectional PRE because the re-encrypted data can no longer be re-encrypted again.

The unidirectional PRE scheme has been developed by many researchers since the time it was first proposed. In [21 –24], the authors addressed a chosen-plaintext attack for the unidirectional PRE scheme, and proposed solutions for preventing such type of attack. Furthermore, in [19] and [25], the authors pointed out the possibility of the chosen ciphertext attack on the unidirectional PRE scheme, and developed new PRE schemes, which are based on public key and identity, respectively. In addition, Chow et al. proposed a new efficient unidirectional PRE scheme secure against the chosen ciphertext attack [26].

Generally, a unidirectional PRE scheme is composed of seven functions: Setup, KeyGen, Rekey-Gen, Enc₁, Enc₂, Re-Enc and Dec. The aim of each function is as follows:

Setup: This process is in operation when the system is initialized or reset. In this process, the parameters, which will be used in the unidirectional PRE scheme, are determined. These parameters include not only values such as prime numbers and some constants, but also hash functions.

KeyGen: This process is in operation when a new user joins. In this process, the user’s private and public keys are generated. Furthermore, this KeyGen process includes sending the user generated keys, shared values, and shared hash functions.

Enc₁, Enc₂: In the unidirectional PRE scheme, there are two types of encryptions: first-level encryption and second-level encryption [21]. Literally, Enc₁ is a process for the first-level encryption, and Enc₂ is a process for the second-level encryption. For both encryptions, the input parameters are plaintext and user’s public key. However, with the Re-Enc process, a ciphertext from the second-level encryption is transformed to another ciphertext, which is the same as a result of the first-level encryption for the same plaintext.

Dec: This process is for decrypting the ciphertext. As mentioned above, there are two types of the encryptions, hence there are also two types of decryptions: first-level decryption (Dec₁) and second-level decryption (Dec₂). Dec₁ is used for decrypting a ciphertext that is encrypted with Enc₁, and Dec₂ is used for Enc₂. For both decryptions, a user employs one’s private key.

RekeyGen: This process is performed by a delegator and generates a re-encryption key. Assume that Alice is a delegator and Bob is a delegatee. To generate the re-encryption key, Alice uses her private key and Bob’s public key [19]. After generating the re-encryption key, it is sent to the proxy.

Re-Enc: The aim of this process is re-encrypting the ciphertext. Let us consider the case mentioned in RekeyGen. Alice sends the ciphertext and the re-encryption key to the proxy. It is noted that the ciphertext is a result of the second-level encryption of a plaintext. Further, the proxy transforms the ciphertext with the re-encryption key to another ciphertext, which can be decrypted with Bob’s private key and first-level decryption.

4 PINK: Privacy-enhancing in-vehicle network key management

In this section, the PINK scheme is proposed. First, the system architecture is proposed, and then the concrete file encryption and decryption schemes based on the PRE are proposed. Finally, a group-based key management scheme for efficient data delivery is proposed.

4.1 System architecture

Figure 4 shows the basic architecture of the proposed scheme. The scheme is composed of a VCU with a shared storage, a proxy, a key distributor, a gateway, and various nodes including ECUs. All the components are connected to the buses. The shared storage stores all the data collected by the nodes or various information generated by the vehicle. Among the data in the storage, the privacy-sensitive ones are encrypted with a master encryption key, pk_M, which is kept only by the VCU and the key generator. Note that the encrypted data in the VCU can be decrypted with the master decryption key sk_M.

Fig.4

Basic Architecture of PINK.

Each node has its own encryption key and decryption key. For a node n, let pk_n and sk_n be its encryption and decryption keys, respectively. Further, a proxy collects all the encryption keys that include pk_M, which will be used for generating the re-encryption key. Note that ${X}_{{pk}_{y}}$ is an encrypted version of a plaintext $X$ , which can be decrypted with sk_y. Let us consider a case that a node n wants to receive data $D$ in the VCU. ${D}_{{pk}_{M}}$ is stored in the VCU. When the VCU accepts, the key generator creates a re-encryption key rk, which is made from pk_M and pk_n.

When ${D}_{{pk}_{M}}$ arrives in the proxy, the proxy re-encrypts it to ${D}_{{pk}_{n}}$ using rk. Note that $D$ is not revealed in the re-encryption procedure. Further, the re-encrypted data ${D}_{{pk}_{n}}$ is broadcasted via the bus, and reaches the node n. Finally, the node decrypts with its decryption key sk_n. The other nodes cannot decrypt due to the absence of sk_n. We address the detailed procedures in Subsection 4.2.

In addition to the unicast way, this study proposes a multicast data transmission. Let us assume that nodes n₁, n₂, ⋯, n_t shares a group encryption key pk_g and a group decryption key sk_g. Further, when these t nodes requests data $D$ in the VCU, the proxy first generates a re-encryption key with pk_M and pk_g. Further, the VCU puts ${D}_{{pk}_{M}}$ into the proxy, the proxy re-encrypts it to ${D}_{{pk}_{g}}$ with the re-encryption key, and the proxy broadcasts ${D}_{{pk}_{g}}$ through the bus. Finally, when the t nodes receive ${D}_{{pk}_{g}}$ , they decrypt it with sk_g. We address this type of the scheme in Subsection 4.3.

4.2 Concrete scheme

Now, we describe the detailed procedures for the proposed scheme, which is composed of five procedures: system initialization, participant registration, withdrawal, data storing, and data loading. To implement our scheme, we employ a unidirectional PRE scheme proposed by Chow el al., which is secure against well-known possible attacks including the chosen ciphertext attack [26].

4.2.1 System initialization

When the system is initialized or reset, the values and functions that are used for the PRE scheme are determined. The description is as follows:

The key generator first chooses two large primes p and q that satisfy q ∣ (p - 1), and selects a generator $g \in G$ , where $G$ is a subgroup of $ℤ_{q}^{*}$ .

The key generator determines four hash functions $H_{1} : {0, 1}^{ℓ_{0}} \times {0, 1}^{ℓ_{1}} \to ℤ_{q}^{*}$ , $H_{2} : G \to {0, 1}^{ℓ_{0} + ℓ_{1}}$ , $H_{3} : {0, 1}^{*} \to ℤ_{q}^{*}$ , and $H_{4} : G \to ℤ_{q}^{*}$ , where ℓ₀ and ℓ₁ are pre-determined parameters. Let param be $(q, G, g, H_{1}, H_{2}, H_{3}, H_{4}, ℓ_{0},$ ℓ₁).

The key generator broadcasts param via the bus.

The VCU chooses a secret key ${sk}_{M} = (x_{M, 1} \in ℤ_{q}^{*}, x_{M, 2} \in ℤ_{q}^{*})$ , and calculates pk_M = (g^{x
_M,1}, g^{x
_M,2}). Every node determines its secret key and derives the public key in the similar way.

The VCU transmits its secret key sk_M to the proxy securely. In addition, each node sends its public key to the proxy. Note that these keys are used for generating the re-encryption key.

After the system initialization process, all the components have the shared parameters, the shared functions, and their own public and secret keys.

4.2.2 Joining and revocation of participant

When an additional node is plugged to the in-vehicle network, the device receives the shared parameters and determines its secret and public keys. Moreover, when the device is removed forever, the system should let the device not participate the in-vehicle network. The descriptions of these processes are as follows:

Joining

When a node (let the node be n) is plugged, the vehicle checks its validity.

If there is no problem, the key generator transmits param to the new node.

Using the parameters, the node chooses its secret key ${sk}_{n} = (x_{n, 1} \in ℤ_{q}^{*}, x_{n, 2} \in ℤ_{q}^{*})$ and computes its public key pk_n = (g^{x
_n,1}, g^{x
_n,2}).

The node sends its public key to the proxy via the bus.

Revocation

All the participants except the removed node deletes the removed node’s public key.

The key distributor removes the re-encryption key related to the removed device.

When being plugged, if a device joins an exist group, then in the above joining process, a step for receiving the group public and private keys is added. Further, in the revocation process, if the removed device was in a group, then the group key is updated and shared by the remaining participants. We will address the group key management in Subsection 4.3.

4.2.3 Storing data

In this scheme, when a node such as ECU, sensor, and communication device creates data and stores to the shared storage in the VCU, the data need security, and then they are encrypted with the master public key pk_M. For this, the node encrypts the data with a master public key pk_M = (pk_M,1, pk_M,2). The detailed process for encrypting message $M$ is as follows:

The node chooses $u \in ℤ_{q}^{*}$ and computes $D = {({pk}_{M, 1}^{H_{4} ({pk}_{M, 2})} \cdot {pk}_{M, 2})}^{u}$ .

The node picks ω ∈ {0, 1} ^ℓ₁ and computes $r = H_{1} (M, ω)$ .

The node computes $E = {({pk}_{M, 1}^{H_{4} ({pk}_{M, 2})} \cdot {pk}_{M, 2})}^{r}$ and $F = H_{2} (g^{r}) \oplus (M ∥ ω)$ .

The node computes s = u + r · H₃ (D, E, F) mod q, and outputs the ciphertext $C = (D, E, F, s)$ .

The node sends $C$ to the VCU via the bus.

4.2.4 Decryption by the VCU

The VCU may use the data stored in itself. In the VCU, the ciphertext is in the form $C = (D, E, F, s)$ , and it can be decrypted using Dec₂, master public key pk_M = (pk_M,1, pk_M,2), and master secret key sk_M = (x_M,1, x_M,2). The detailed procedure is as follows:

The VCU checks if $({pk}_{M, 1}^{H_{4} ({pk}_{M, 2})}) = D \cdot E^{H_{3} (D, E, F)}$ . If the equation is not established, return ⊥.

If the above equation is established, the VCU computes $(M ∥ ω) \leftarrow F \oplus H_{2} (E^{\frac{1}{x_{M, 1} H_{4} ({pk}_{M, 2}) + x_{M, 2}}}) .$

The VCU checks if the equation $E = {({pk}_{M, 1}^{H_{4} ({pk}_{M, 2})} \cdot {pk}_{M, 2})}^{H_{1} (M, ω)}$ holds true. If so, $M$ is the decrypted plaintext, or, return ⊥.

4.2.5 Loading data

Now, let us consider the case of loading data from the shared storage. If the data is not encrypted, the participants may use it as is. However, if encrypted, the following procedures are in operation.

When a node n requests to receive data $M$ stored in the VCU and the VCU accepts, it first delivers the encrypted version of $M$ , (D, E, F, s), to the proxy.

The key distributor picks h ∈ {0, 1} ^ℓ₀ and π ∈ {0, 1} ^ℓ₁, then computes v ← H₁ (h, π).

The key distributor computes $V \leftarrow {pk}_{n, 2}^{v}$ and W ← H₂ (g^v) ⊕ (h ∥ π).

The key distributor determines the re-encryption key ${rk}_{M \to n} = ({rk}_{M \to n}^{< 1 >}, V, W)$ , where ${rk}_{M \to n}^{< 1 >} = \frac{h}{x_{M, 1} H_{4} ({pk}_{M, 2}) + x_{M, 2}}$ , and delivers it to the proxy via unicast communication.

The proxy checks if ${({pk}_{M, 1}^{H_{4} ({pk}_{M, 2})} \cdot {pk}_{M, 2})}^{s} = D \cdot E^{H_{3} (D, E, F)}$ holds. If not, return ⊥.

If the equation is true, the proxy computes $E^{'} = E^{{rk}_{M \to n}^{< 1 >}}$ , and transmits (E′, F, V, W) to the node n via the bus.

When (E′, F, V, W) arrives in node n, it computes (h ∥ π) ← W ⊕ H₂ (V^1/sk_n,2) and $(ℳ ∥ ω) \leftarrow F \oplus H_{2} (E^{' 1 / h})$ .

Node n checks if $V = {pk}_{n, 2}^{H_{1} (h, π)}$ and $E^{'} = g^{H_{1} (M, ω) \cdot h}$ hold. If so, $M$ becomes the decrypted plaintext.

These are eight steps with complex calculations, thus, the procedure for loading data can be a time-consuming task. If the stored data is loaded in real time, the verification steps can be skipped.

4.3 Group-based key management

There may exist a group of nodes that requests the VCU to send the same data simultaneously. If the group requires the same data multiple times, the loading data procedure discussed in Subsection 4.2 may prove inefficient. To overcome this problem, this study proposes a group-based key management scheme.

Let $G$ be a group of specific nodes, and sk_G and pk_G be the group’s secret and public keys, respectively. When all the members of $G$ request the same data $M$ , the proxy re-encrypts the encrypted data in the VCU into another ciphertext that can be decrypted with sk_G and pk_G. After the re-encrypted data is delivered to the group of nodes via the bus, the nodes decrypt the ciphertext with the group key. The nodes not a part of this group cannot open the delivered data because they do not have the group key.

A new node can join the in-vehicle network. Moreover, there may exist a node in the in-vehicle network that will be revoked. For these cases, the group key should be changed because of the forward and backward secrecies [3]. To update the group key, the key distributor first generates the new group secret and public keys and encrypts them with each node’s public key. Note that this encryption process is repeated for each remaining member of the group.

With this process, the operation cost for data transmission must be reduced if a special group of the nodes requests the same data simultaneously multiple times. In addition, only the nodes in the new group can receive the updated group key; thus, only the group members can receive the data even when group membership changes.

5 Simulations

In this section, we demonstrate that the proposed PINK scheme can be efficiently applied to the in-vehicle network using the simulation. We measured the time for loading data, which was introduced in 4.2.5. In this scheme, time for loading data is the major concern, because the node should be able to use the data in the VCU as fast as possible.

In terms of the simulation environment, we employ SHA-512 hash function for determining four functions H₁, H₂, H₃, and H₄, and determine p as a prime number with 1024 bits. In addition, the simulation is the results of experiment on Ubuntu, 2.4 GHz Intel Core i5, and 8 GB DDR4 RAM environment.

Figure 5 indicates the simulation result for the measuring time for data decryption. We first set the data sizes from 8 bytes to 16 bytes because the size of can message is between 8 and 16 bytes according to Fig. 2. As Fig. 5 (a), the time for data decryption is under 3 ms, this is sufficiently short time for applying the in-vehicle network. In addition, we conduct the simulation for decrypting data whose size is between 1 KB and 1 MB. Although it takes more than 1 second when the data size is over 20 KB, this PINK scheme can be used because almost data for the in-vehicle network are small.

Fig.5

Time for Data Decryption.

6 Conclusion

In existing in-vehicle networks, data is stored and transmitted without being encrypted. Moreover, during data transmission, it is broadcasted to the bus and exposed to all the participants of the in-vehicle network. Therefore, using a portable device, which is plugged to the vehicle, or a communication module, the privacy-sensitive data can be leaked.

In this study, we proposed the application of the PINK scheme to the in-vehicle network. The privacy-sensitive data is encrypted by the master key using the PINK scheme before being stored in the VCU. Thus, only the VCU can see the encrypted data in the storage. In addition, with the PRE scheme, the data transmitted through the bus can be decrypted only at the target node. Moreover, with a group key, the VCU can securely multicast the encrypted data to a group of participants. Thus, the data can be transmitted securely and efficiently.

Footnotes

Acknowledgments

This research was partly supported by the National Research Foundation of Korea (NRF) grant funded by the Korea government (MSIP) (No. 2017R1C1B5018116), and the Sookmyung Women’s University Research Grants (1-1603-2018).

References

Kimm

and Ham

H.S.

, Integrated fault tolerant system for automotive bus networks, in Computer Engineering and Applications (ICCEA), 2010, Second International Conference on, vol. 1, 2010, pp. 486–490.

Zeng

, Khalid

M.A.S.

and Chowdhury

, In-vehicle networks outlook: Achievements and challenges, IEEE Communications Surveys Tutorials, 18 (2016), 1552–1571. thirdquarter.

Park

Y.H.

, Je

D.H.

, Park

M.H.

and Seo

S.W.

, Efficient rekeying framework for secure multicast with diverse-subscriptionperiod mobile users, IEEE Transactions on Mobile Computing, 13 (2014), 783–796.

Park

Y.-H.

, Data encryption and key management for secure in-vehicle networks based on proxy re-encryption, in International Conference on Green and Human Interface Technology, (ICGHIT 2018), Chiang Mai, Thailand, 2018, pp. 192–195.

Koscher

, Czeskis

, Roesner

, Patel

, Kohno

, Checkoway

, McCoy

, Kantor

, Anderson

, Shacham

and Savage

, Experimental security analysis of a modern automobile, in 2010 IEEE Symposium on Security and Privacy,, (2010), pp. 447–462.

Kleberger

, Olovsson

and Jonsson

, Security aspects of the in-vehicle network in the connected car, in 2011 IEEE Intelligent Vehicles Symposium (IV), (2011), pp. 528–533.

Liu

, Zhang

, Sun

and Shi

, In-vehicle network attacks and countermeasures: Challenges and future directions, IEEE Network, 31(5) (2017), 50–58.

Woo

, Jo

H.J.

and Lee

D.H.

, A practical wireless attack on the connected car and security protocol for in-vehicle can, IEEE Transactions on Intelligent Transportation Systems, 16 (2015), 993–1006.

Hoppe

, Kiltz

and Dittmann

, Security threats to auto- motive can networks — practical examples and selected short-term countermeasures, in Proceedings of the 27th International Conference on Computer Safety, Reliability, and Security, SAFECOMP ’08, Berlin, Heidelberg, Springer-Verlag, 2008, pp. 235–248.

10.

Enck

, Gilbert

, Chun

B.-G.

, Cox

L.P.

, Jung

, Mc-Daniel

and Sheth

A.N.

, Taintdroid: An information- flow tracking system for realtime privacy monitoring on smartphones, in Proceedings of the 9th USENIX Conference on Operating Systems Design and Implementation, OSDI’10, Berkeley, CA, USA, 2010, pp. 393–407, USENIX Association.

11.

Rouf

, Miller

, Mustafa

, Taylor

, Oh

, Xu

, Gruteser

, Trappe

and Seskar

, Security and pri- vacy vulnerabilities of in-car wireless networks: A tire pressure monitoring system case study, in Proceedings of the 19th USENIX Conference on Security, USENIX Secu- rity’10, Berkeley, CA, USA, 2010, pp. 21–21, USENIX Association.

12.

Checkoway

, McCoy

, Kantor

, Anderson

, Shacham

, Savage

, Koscher

, Czeskis

, Roesner

and Kohno

, Comprehensive experimental analyses of auto motive attack surfaces, in Proceedings of the 20th USENIX Conference on Security, SEC’11, Berkeley, CA,USA, 2011, pp. 6–6, USENIX Association.

13.

Schweppe

and Roudier

, Security and privacy for invehicle networks, in 2012 IEEE 1st International Workshop on Vehicular Communications, Sensing, and Computing (VCSC), (2012), pp. 12–17.

14.

Groll

and Ruland

, Secure and authentic communication on existing in-vehicle networks, in 2009 IEEE Intelligent Vehicles Symposium, (2009), pp. 1093–1097.

15.

Blaze

, Bleumer

and Strauss

, Divertible protocols and atomic proxy cryptography, in AdvancesinCryptology—EUROCRYPT’98 ( Nyberg

, ed.), Berlin, Heidelberg, 1998, pp. 127–144, Springer Berlin Heidelberg.

16.

Mambo

and Olamoto

, Olamoto, Proxy cryptosystem: Delegation of the power to decrypt cipher-texts, vol. 80, 011997.

17.

Ivan

and Dodis

, Proxy cryptography revisited, in Proceedings of the Network and Distributed System Security Symposium (NDSS), 2003.

18.

Zhou

, Marsh

M.A.

, Schneider

F.B.

and Redz

, Distributed blinding for distributed elgamal re-encryption, in 25th IEEE International Conference on Distributed Computing Systems (ICDCS’05)2005. pp. 824–824.

19.

Canetti

and Hohenberger

, Chosen-ciphertext secure proxy re-encryption, in Proceedings of the 14th ACM Conference on Computer and Communications Security, CCS ’07, New York, NY, USA, ACM, 2007, pp. 185–194.

20.

Blaze

, Bleumer

and Strauss

, Divertible protocols and atomic proxy cryptography, In EUROCRYPT, Springer-Verlag, 1998, pp. 127–144.

21.

Ateniese

, Fu

, Green

and Hohenberger

, Improved proxy re-encryption schemes with applications to secure distributed storage, ACM Trans Inf Syst Secur, 9 (2006), 1–30.

22.

Hohenberger

, Rothblum

G.N.

, Shelat

and Vaikuntanathan

, Securely obfuscating re-encryption, in Heidelberg, Proceedings of the 4th Conference on Theory of Cryptography, TCC’07Berlin, Heidelberg, Springer-Verlag, 2007. pp. 233–252

Berlin

Springer-Verlag.

23.

Libert

and Vergnaud

, Tracing malicious proxies in proxy re-encryption, in Pairing-BasedCryptography–Pairing2008 ( Galbraith

S.D.

and Paterson

K.G.

, eds.), Berlin, Heidelberg, Springer Berlin Heidelberg, 2008, pp. 332–353.

24.

Ateniese

, Benson

and Hohenberger

, Key-private proxy re-encryption, in Proceedings of the The Cryptog-raphers’ Track at the RSA Conference 2009 on Topics in Cryptology, CTRSA ’09, Berlin, Heidelberg, Springer-Verlag, 2009, pp. 279–294.

25.

Green

and Ateniese

, Identity-based proxy re-encryption, in Proceedings of the 5th International Conference on Applied Cryptography and Network Security, ACNS ’07, Berlin, Heidelberg, Springer-Verlag, 2007, pp. 288–306.

26.

Chow

S.S.M.

, Weng

, Yang

and Deng

R.H.

, Efficient unidirectional proxy re-encryption, in Proceedings of the Third International Conference on Cryptology in Africa, AFRICACRYPT’10, Berlin, Heidelberg, Springer-Verlag, 2010, pp. 316–332.