Secure Key Agreement and Authentication Protocol for Message Confirmation in Vehicular Cloud Computing

Abstract

With the development of vehicular ad-hoc networks (VANETs) and Internet of vehicles (IoVs), a large amount of useful information is generated for vehicle drivers and traffic management systems. The amount of vehicle and traffic information is as large as the number of vehicles and it is enormous when compared to vehicle calculation and storage performance. To resolve this problem, VANET uses a combined cloud computing technology, called vehicular cloud computing (VCC), which controls vehicle-related data, and helps vehicle drivers directly or indirectly. However, VANETs remain vulnerable to attacks such as tracking, masquerade and man-in-the-middle attacks because VANETs communicate via open networks. To overcome these issues, many researchers have proposed secure authentication protocols for message confirmation with vehicular cloud computing. However, many researchers have pointed out that some proposed protocols use ideal tamper-proof devices (TPDs). They demonstrated that realistic TPDs cannot prevent adversaries attack. Limbasiya et al. presented a message confirmation scheme for vehicular cloud computing using a realistic TPD in order to prevent these problems. However, their proposed scheme still has security weaknesses over a TPD and does not guarantee mutual authentication. This paper proposes a secure key agreement and authentication protocol to address the security weaknesses inherent in the protocol of Limbasiya et al. The suggested protocol withstands malicious attacks and ensures secure mutual authentication for privacy-preserving. We prove that the proposed protocol can provide session key security using Real-Or-Random (ROR) model. We also employed Automated Validation of Internet Security Protocols and Applications (AVISPA) simulation tool to show that the proposed protocol is able to defeat replay and man-in-the-middle attacks. Furthermore, we established that the proposed protocol can resist other malicious attacks by conducting the informal security analysis. We proved that our proposed protocol is lightweight and suitable for VCC environments.

1. Introduction

Embedded devices, such as sensors and on-board units (OBUs) of Internet of vehicles (IoVs), collect a variety of information including traffic conditions and road conditions. The driver and traffic management system can share and use various services by sharing this information with other IoVs. Therefore, the role of embedded devices in IoV has been increasing with the increase in the size of a vehicle system, and traffic information has been increasing in complexity. However, enhancing the computing power and extending the storage space of the embedded devices is not technically possible or financially viable. Vehicular cloud computing (VCC) has been suggested to address these limitations of embedded devices. VCC is a system that controls vehicle-related data. IoVs send traffic information to the vehicular cloud. Subsequently, other vehicles can obtain information from the vehicular cloud when required.

However, this information is transmitted through open and unsecured channels; therefore, malicious attackers can threaten the VCC environment. When malicious attackers steal and manipulate traffic information, the lives of pedestrians, and drivers are endangered. Therefore, VCC should provide a key agreement with secure authentication that protects the information by providing message confirmations. Therefore, many studies have been suggested for VCC to provide a secure authentication. Recently, proposed schemes are used for ideal tamper-proof devices (TPDs). The TPD is safe from malicious attacks and it is impossible to tamper with it, according to the proposed schemes. However, the ideal TPD has a strong assumption that an attacker cannot obtain or tamper with values in the TPD according to [1,2,3,4]. They pointed out that attackers can obtain stored values in the realistic TPD through power analysis attacks and side-channel attacks.

In 2019, Limbasiya et al. [4] presented a message confirmation scheme based batch verification, and a VCC environment to address OBU computation limitations. They proposed secure authentication to address an issue, where realistic TPD cannot prevent side channel and power analysis attacks. And also, they proposed a session key agreement for secure transmitting information. However, we figure out that the proposed protocol of Limbasyia et al. is vulnerable to side channel attacks of TPD and cannot defeat various attacks, including session key disclosure and impersonation attacks. Their protocol is also unable to provide secure mutual authentication and privacy-preserving.

This paper suggests a secure key agreement and authentication protocol for message confirmation in the VCC environment in order to overcome their security flaws. We design the protocol to use only the hash function and XOR operation, and assume that realistic OBUs can be deployed realistic environments. We also assume that an attacker can perform side channel attacks on TPDs to obtain secret values stored in TPDs. Consequently, our proposed protocol does not strongly rely on TPDs; instead, it uses only OBUs. Furthermore, we propose a key agreement protocol for secure data transmission. We analyze the security aspects of our proposed protocol using Real-Or-Random (ROR) model and the Automated Validation of Internet Security Protocols and Applications (AVISPA) software for the formal analysis. This paper also compares the computation cost and security features with [4] and previous similar protocols. Finally, this paper demonstrates that the proposed protocol is able to be deployed in a real VANET.

The rest of this paper is as follows: Section 2 reviews related works and presents the network model, threat model and notations used in this paper. At Section 3, we review the Limbasiya et al.’s protocol. We cryptanalyze its security flaws in Section 4. At Section 5 and Section 6, we propose a secure key agreement and authentication protocol for VCC environment in VANET and perform informal and formal security analysis. We use ROR model, AVISPA simulation, and informal analysis for verification. Subsequently, we compare the security properties and computational cost with related previous researches in Section 7. Finally, in Section 8, we present our conclusions with the results of the proposed protocol.

2. Related Works

This section reviews the literature regarding the authentication protocol for vehicle communication and examines the limitations of ideal TPDs. We also introduce the network model, threat model, and notations used in this paper.

2.1. Literature Reviews

This section briefly reviews secure authentication protocols and key agreement protocols that are involved in two aspects, i.e., general authentication protocols for vehicular communication or VANETs, and authentication protocol using a practical TPD that points out the limitations of the ideal TPD.

2.1.1. Authentication Protocol for Vehicle Communication

Authentication is considered a basic security service that allows subjects to mutually authenticate with other subjects [5,6,7,8,9]. In 2007, Lin et al. [10] suggested an authentication protocol while using a group signature based on bilinear pairing. In their protocol, the verifier can verify multiple signatures simultaneously, which improves authentication efficiency. However, Zhang et al. [11] pointed out a significant flaw in Lin et al.’s protocol, that validation required at least two pairing operations that could not be extended. In addition, their protocol uses many exponential operations that require complex computing. Therefore, they suggested an authentication protocol based on bilinear pairing and used addition operation, which is simpler than exponential operation. In 2013, Lee and Lai [12] found that Zhang et al.’s proposed scheme also has security weaknesses. They demonstrated that Zhang et al.’s protocol cannot achieve the signature non-repudiation and is insecure against replay attack. Moreover, Zhang et al.’s scheme cannot provide security to masquerade and tracking attacks. However, Jianhong et al. [13] proved that Lee and Lai’s protocol is insecure to the impersonation and tracing attacks and violates the non-repudiation. Further, Bayat et al. [14] also found an impersonation attack in Lee and Lai’s protocol. After that, Bayat et al. [14] proposed a secure authentication scheme for VANETS with batch verification to overcome [12]’s security weaknesses. Unfortunately, He et al. [15] pointed out that [14]’s protocol cannot defeat against modification, replay, and impersonation attacks. Then, He et al. [15] designed a novel secure protocol using Elliptic Curve Cryptographic (ECC) for vehicle communication. Zhong et al. [16] analyzed the protocol in [15] and concluded that using complex cryptographic functions can result in enormous operational costs and, consequently, the system faces network disruption problems. Therefore, they proposed a system to distribute pseudonymized signatures to verify user identities. In 2014, Chuang et al. [17] proposed a trust-extended authentication scheme in VANETs. Under their protocol, vehicles are divided into three types and they only used hash and exclusive-or functions to create lightweight communication. However, Zhou et al. [18] found out that Chuang et al.’s protocol cannot guarantee privacy-preserving and is vulnerable to impersonation and insider attacks. They also argued that the assumption of TPD is strong. Therefore, Zhou et al. proposed a more secure authentication protocol to improve Chuang et al.’s protocol. They use an ECC to protect entities’ real identities and protect against internal attacks. In 2019, Wu et al. [19] pointed out that Zhou et al.’s proposed protocol cannot prevent identity guessing and impersonation attacks and also cannot guarantee user’s anonymity. In 2017, Zhang et al. [1] proposed a personal information protection system based on distributed aggregation to conditionally block user’s anonymity. However, this method takes more time to verify the signature, so the recipient must spend more time immediately verifying the correctness of the message. In 2019, Limbasiya et al. [4] proposed a secure message confirmation in vehicular cloud environment. They are pointed out that Zhong et al’s protocol [16] has a security flaws using side channel attack over the OBU and TPD. Therefore, they suggested a more secure protocol for overcoming computational limitations of OBU and TPD through cloud computing. However, we revealed that their proposed protocol does not defeat several malicious attacks, such as session key disclosure attack and masquerade attack and so on. Additionally, their protocol does not provide privacy preserving and mutual authentication and has a correctness problem.

2.1.2. Ideal Tpd Limitation

In 2017, Zhang et al. [1] proposed a privacy-preserving authentication protocol for VANET communication with a realistic TPD in OBUs. They showed that the general TPD used in many previous studies was not realistic. The ideal TPD has a strong assumption that an attacker cannot obtain or tamper with values stored in the OBU. However, Zhang et al. [1] demonstrated that attackers can perform side channel attack on TPDs in realistic situations to eventually control the entire VANET. In 2017, Zhang et al. [2] proposed a Chinese remainder theorem based authentication protocol for VANETs. They pointed out the heavy reliance on the ideal TPD. If a single TPD is obtained by a malicious user, reliance on the ideal TPD created a single point of failure and fail to preserve privacy of entire network. Therefore, they use biometrics of the drivers to help prevent attack over TPDs.

In 2018, Liu et al. [3] proposed an authentication scheme for VANETs to balance the reliance on the TPD. They demonstrated that strong reliance of the TPD provokes that attacker can compromise the whole system, because of key leakage, and they designed a protocol, such that, even if the TPD is compromised, the whole system will not be in danger.

2.2. Network Model

In the general architecture of vehicular networks, the communication of vehicles among the other vehicles or with the road side units (RSUs) is based on dedicated short-range communication [20], where the vehicle-to-Infrastructure (V2I) communication is the external network among the vehicles and RSUs.

Our proposed network model is based on Limbasiya et al.’s network model, but it addresses the problems regarding flaws in communication and authentication. Under their protocol, the process of transmitting the session key between RSUs and vehicles is unclear. Therefore, we propose a network model, in which vehicles and RSUs register at a trusted authority. The key agreement consists of all entities, including the vehicle, RSU, and trusted authority. Figure 1 illustrates our proposed network model and gives a detailed description of the entities.

Figure 1. Proposed network model.

• Vehicle: vehicles have embedded devices, sensors and wireless communication device, such as velocity or location measurement equipment, Bluetooth, Wi-Fi, and OBU. In particular, the OBU collects information generated by sensors or devices. However, the OBU has relatively restricted memory. Therefore, the OBU sends the collected information to RSUs; subsequently, RSUs transmit the data to the vehicular cloud.
• RSU: RSUs are intermediary devices to transmit data between vehicles and the vehicular cloud. RSUs register with the trusted authority to generate a session key with vehicles. RSUs have more memory and computing performance than OBUs. Therefore, RSUs can obtain data from many vehicles. However, RSUs cannot store data from multiple vehicles. Therefore, RSUs send specific data to the vehicular cloud.
• Trusted authority: a trusted authority is the top-level entity that an attacker can never attack. RSUs and vehicles should register with the trusted authority to generate the session key, and then, the trusted authority, RSUs, and vehicles perform mutual authentication.
• Vehicular cloud: a vehicular cloud is a storage server used to save a huge amount of data of different kinds within a VANET system. Each vehicle needs to collect and share the data with other vehicles. Therefore, the OBU collects data and communicates with other OBUs. However, OBUs have low computational performance and small storage space. Thus, vehicles send the data securely to RSUs and RSUs forward it to the vehicular cloud.

2.3. Threat Model

We cryptanalyze protocol security using the popular Dolev-Yao(DY) model [21]. By using this threat model, malicious attackers can capture, modify, add, or delete messages sent over insecure channels. And we also consider the following assumptions:

• A malicious adversary can steal or obtain a legitimate user’s device, and perform side-channel attacks [22] to obtain key information stored in the device.
• A malicious adversary is able to masquerade as a legitimate user and trick authority entities for accessing resources.
• An adversary may obtain an authority entity’s secret key. Subsequently, the adversary can compute a previous session key to trick user or authority entities.

We also follow the claims of [1,2,3]. Therefore, we assume that attackers can perform side channel attack or power analysis attack over TPDs or OBUs. Subsequently, attackers can obtain values stored in TPDs. Adversaries can perform a variety of attacks including impersonation, spoofing, identity guessing attacks using values obtained from compromised TPDs.

2.4. Notations

The used notations in this paper are given in Table 1.

Table 1. Notations.

Notations	Meanings
$OBU$	On board unit
$TPD$	Tamper-proof device
P	Elliptic curve generator
$P_{pr{i}_i}$	A server private key
$s_i,a_i,b_i,r_i,r_j,a_j$	Selected random numbers
$RI{D}_i,I{D}_i$	Registered vehicle identity
$I{D}_{RS{U}_j}$	Road-side unit identity
$P{W}_{TP{D}_i},P{W}_i$	Registered vehicle password
$v_i$	Vehicle i in the network
$RSU$	Road-side unit
$TA$	Trusted authority
$h(·)$	Hash function
$\left|\right|$	Connection symbol
⊕	XOR operator

3. Review of Limbasiya et al.’s Protocol

We review Limbasiya et al.’s message confirmation scheme for VCC environment, which includes formation, key generation and message signature, and message confirmation phases.

3.1. Formation Phase

If a new vehicle requests registration with trusted authority $TA$, $TA$ computes and sends $OB{U}_i$ and $TP{D}_i$, which store the necessary values to the vehicle. Before registration, each vehicle computes parameters using unique identity $RI{D}_i$, password $PW{D}_{TP{D}_i}$, and random number $s_i$. The detailed equations are shown in Figure 2 and steps are as follows.

Figure 2. Formation phase of Limbasiya et al.’s protocol.

Step 1:

Vehicle $v_i$ chooses unique identity $RI{D}_i$, password $PW{D}_{TP{D}_i}$ and generates a random number $s_i$. $v_i$ computes $X_i=(PW{D}_{TP{D}_i}\left|\right|s_i)\oplus RI{D}_i$, and then sends $RI{D}_i$, $X_i$ to $TA$ through a secure channel.

Step 2:

After receiving $RI{D}_i$ and $X_i$, $TA$ calculates $P_{pr{i}_i}=s_i\oplus P\oplus RI{D}_i$ and saves $\left\{P\right\}$ in $OB{U}_i$ and $\{X_i,P_{pr{i}_i}\}$ in $TP{D}_i$. Subsequently, $TA$ sends $OB{U}_i$ and $TP{D}_i$ to $v_i$ via a secure channel.

3.2. Key Generation Phase

The vehicle $v_i$ begins a key agreement process in $TP{D}_i$ for message signature. $v_i$ generates a session key $S{K}_{RI{D}_i}$ and transmits it to a concerned $RSU$. The detailed equations are illustrated in Figure 3 and the steps are as following.

Figure 3. Key generation phase of Limbasiya et al.’s protocol.

Step 1:

$v_i$ inserts $RI{D}_i$ and $PW{D}_{TP{D}_i}$ into $TP{D}_i$.

Step 2:

then $TP{D}_i$ computes $s_i=P\oplus RI{D}_i\oplus P_{pr{i}_i}$ and $X_i^{\prime }=(PW{D}_{TP{D}_i}\left|\right|s_i)\oplus RI{D}_i$. Then $TP{D}_i$ compares $X_i^{\prime }$ with $X_i$ stored in itself.

Step 3:

if they are same, $TP{D}_i$ selects random number $r_i$ and computes $I{D}_1=r_i·P$, $I{D}_2=RI{D}_i\oplus h(r_i·P_{pr{i}_i})$ and $I{D}_{i+2}=h(I{D}_1\left|\right|I{D}_2)$. Then $TP{D}_i$ generates the session key $S{K}_{RI{D}_i}=s_i\oplus h(I{D}_{i+2}\left|\right|T_1)\oplus I{D}_{RS{U}_j}$ and transmits the session key to a concerned $RSU$.

3.3. Message Signature and Confirmation Phase of Limbasiya et al.’s Protocol

$TP{D}_i$ signs the information with the session key and forwards to the connected $RS{U}_j$. Figure 4 shows the detailed equations with process steps, as follows.

Figure 4. Message signature phase of Limbasiya et al.’s protocol.

Step 1:

for signing the message, $TP{D}_i$ computes ${\sigma }_i=S{K}_{RI{D}_i}\oplus h(M_i\left|\right|T_1)$ and $M_i^{\prime }=S{K}_{RI{D}_i}\oplus M_i\oplus T_1\oplus RI{D}_i\oplus I{D}_{RS{U}_j}$. Subsequently, $TP{D}_i$ sends message $\{I{D}_{i+2},RI{D}_i,{\sigma }_i,M_i^{\prime },T_1\}$ to the concerned $RS{U}_j$.

Step 2:

after receiving the message, $RS{U}_j$ computes $M_i=S{K}_{RI{D}_i}\oplus M_i^{\prime }\oplus T_1\oplus RI{D}_i\oplus I{D}_{RS{U}_j}$ and ${\sigma }_i^{\prime }=S{K}_{RI{D}_i}\oplus h(M_i\left|\right|T_1)$.

Step 3:

then, $RS{U}_j$ compares the ${\sigma }_i$ with ${\sigma }_i^{\prime }$. If they are equal, $RS{U}_j$ uses $M_i$ for future computations. Additionally, Generally for batch verification, $RS{U}_j$ inspects the exaction by a following equation:

$$(\sum _{i=1}^n{v}_i·{\sigma }_i)=\sum _{i=1}^n{v}_i·S{K}_{RI{D}_i}\oplus \sum _{i=1}^n{v}_i·h(M_i\left|\right|T_1)$$

4. Cryptanalysis of Limbasiya et al.’s Protocol

Limasyia et al. demonstrated that their protocol provides privacy-preserving and mutual authentication and so on. However, in this section, we cryptanalyze Limbasiya et al.’s scheme for the VCC environment. Additionally, we figure out their protocol has several security flaws.

4.1. Correctness Problem

In the formation phase, a vehicle $v_i$ sends only $\{RI{D}_i,X_i\}$. Thus, $TA$ cannot know information $s_i$. However, in Limbasiya et al.’s protocol, $TA$ computes $P_{pr{i}_i}$ using $s_i$. Therefore, Limbasiya et al.’s protocol has a correctness problem and it may derive the incorrect formation of $v_i$.

4.2. Session Key Disclosure Attack

A malicious attacker $\mathcal{A}$ can perform the side channel attack on TPD [1,2,3] and OBU. Accordingly, $\mathcal{A}$ can obtain values stored in OBU and TPD, and also obtain transmitted messages through insecure channels. Thus, $\mathcal{A}$ can compute the session key using the obtained values.

Step 1:

$\mathcal{A}$ can obtain P in $OB{U}_i$ and $X_i,P_{pr{i}_i}$ in $TP{D}_i$ using side channel attack. And $\mathcal{A}$ also can obtain the value $RI{D}_i$ through transmitted message. Subsequently, $\mathcal{A}$ can compute $s_i=P\oplus RI{D}_i\oplus P_{pr{i}_i}$.

Step 2:

$\mathcal{A}$ can obtain $I{D}_{i+2}$ and $T_1$ from transmitted messages and $\mathcal{A}$ obtains the value $I{D}_{RS{U}_j}$, which is public value. Therefore, $\mathcal{A}$ can compute $S{K}_{RI{D}_i}=s_i\oplus h(I{D}_{i+2}\left|\right|T_1)\oplus I{D}_{RS{U}_j}$.

Step 3:

finally, $\mathcal{A}$ obtains the previous session key $S{K}_{RI{D}_i}$ and can trick other OBUs or RSUs.

4.3. Impersonation Attack

$\mathcal{A}$ can impersonate vehicles to compute message confirmation request messages. Section 4.2 shows that $\mathcal{A}$ can compute the session key. Therefore, $\mathcal{A}$ can compute confirmation request messages while using the computed session key and transmitted messages. The detailed steps are as follows.

Step 1:

$\mathcal{A}$ can obtain $M_i^{\prime }$ through the transmitted message and compute previous session key as above session key disclosure attack Section. Subsequently, $\mathcal{A}$ can compute $M_i=S{K}_{RI{D}_i}\oplus M_i^{\prime }\oplus T_1\oplus RI{D}_i\oplus I{D}_{RS{U}_j}$.

Step 2:

$\mathcal{A}$ can also compute ${\sigma }_i=S{K}_{RI{D}_i}\oplus h(M_i\left|\right|T_1)$.

Step 3:

finally, $\mathcal{A}$ can generate the confirmation request message $\{I{D}_{i+2},RI{D}_i,{\sigma }_i,M_i^{\prime },T_1\}$ to impersonate the vehicle.

4.4. Privacy Preserving Problem

In Limbasiya et al.’s scheme, the legitimate identity of the vehicle $RI{D}_i$ is transmitted through public channels. This may cause the tracing attack and cannot preserve the user’s privacy. As above sections, the attacker can masquerade legitimate vehicles and make a session key to access sensitive information. Therefore, the protocol of Limbasiya et al. is not able to provide privacy-preserving.

4.5. Mutual Authentication

In above section, we prove that $\mathcal{A}$ can generate the session key $SK$ successfully, and impersonate the legitimate vehicle. Therefore, the protocol of Limbasiya et al. cannot achieve key agreement and mutual authentication.

5. Secure Key Agreement and Authentication Protocol for VCC

This section provides the proposed protocol to resolve the security flaws in Limbasiya et al.’s protocol. We use only an OBU instead of a TPD. Limbasiya et al.’s protocol cannot provide secure key agreement, because the TPD sends the session key without encryption. Therefore, we register vehicles and RSUs at the $TA$ to generate secure key agreement. Thereafter, the vehicle transmits the information encrypted with the session key to the RSU. RSUs validate the message and send it to the vehicular cloud. We also consider performance and storage of OBU because of its relatively low computational power and small storage. Thus, we design the protocol using only exclusive-or and one-way hash function, which have low computational cost.

5.1. Registration Phase

For message confirmation with VCC and communicating with other vehicles or RSUs, the vehicle must register with the TA. Additionally, RSUs also register through TA to make secure session key with the vehicle. The detailed steps are as following and shown in Figure 5.

Figure 5. Registration phase of our proposed protocol.

Step 1:

vehicle $v_i$ chooses identity $I{D}_i$, password $P{W}_i$ and random number $b_i$. And vehicle computes $P{E}_i=h(P{W}_i\left|\right|b_i)$ and $B{E}_i=b_i\oplus h(I{D}_i\left|\right|P{W}_i)$. $v_i$ sends the message $\{I{D}_i,P{W}_i,P{E}_i,B{E}_i\}$ to $TA$.

Step 2:

$TA$ has master key x and secret key y. After receiving the registration request message from $v_i$, $TA$ generates random numbers $a_i$ and $s_i$ for the vehicle. Subsequently, $TA$ calculates $A{E}_i=h(I{D}_i\left|\right|P{E}_i)\oplus a_i$, $HI{D}_i=h(I{D}_i\left|\right|P{W}_i\left|\right|a_i)$, $HP{W}_i=h(HI{D}_i\left|\right|P{W}_i)$, $M{V}_i=h(HI{D}_i\left|\right|h\left(x\right|\left|y\right))$, $A_i=HP{W}_i\oplus s_i$, $V_i=M{V}_i\oplus s_i$ and $V{S}_i=h(HI{D}_i\left|\right|M{V}_i\left|\right|s_i)$. Afterwards, $TA$ saves $A_i,V{I}_i,A{E}_i,B{E}_i$ and $V{S}_i$ in the $OB{U}_i$, and then sends $OB{U}_i$ to the vehicle through a closed channel.

Step 3:

road side unit $RS{U}_j$ chooses $I{D}_{RS{U}_j}$ and random nonce $a_j$ and sends these values to $TA$ via a closed channel.

Step 4:

when $TA$ receives values from $RS{U}_j$, $TA$ calculates $R{A}_j=h(I{D}_{RS{U}_j}\left|\right|a_j)$ and $R{B}_j=h(R{A}_j\left|\right|h\left(x\right|\left|y\right))$. Subsequently, $TA$ sends the message $\{R{A}_j,R{B}_j\}$ to $RS{U}_j$ via a secure channel.

5.2. Key Agreement and Authentication Phase

The vehicle and RSU must have key agreement through generating the session key for secure communication among the RSU and other OBUs. Vehicle and RSU are authenticated by TA. If the TA checks that vehicle and RSUs are legitimate entities, vehicle and RSU generate a session key. The detailed steps are given below. See Figure 6.

Figure 6. Key agreement and authentication phase of our proposed protocol.

Step 1:

vehicle $v_i$ inputs $I{D}_i$ and $P{W}_i$. Subsequently, $v_i$ extracts $b_i=B{E}_i\oplus h(I{D}_i\left|\right|P{W}_i)$ with stored values $B{E}_i$ in the $OB{U}_i$. $v_i$ calculates $PE=h\left(P{W}_i\right|\left|b_i\right)$, $a_i=A{E}_i\oplus h(I{D}_i\left|\right|P{E}_i)$, $HI{D}_i=h(I{D}_i\left|\right|P{W}_i\left|\right|a_i)$, $HP{W}_i=h(HI{D}_i\left|\right|P{W}_i)$, $s_i=HP{W}_i\oplus A_i$, and $M{V}_i=V{I}_i\oplus s_i$ and $V{S}_i^{\prime }=h(HI{D}_i\left|\right|M{V}_i\left|\right|s_i)$. Then, $v_i$ checks whether $V{S}_i^{\prime }\stackrel{?}{=}V{S}_i$. If valid, $v_i$ selects a random number $r_i$ and computes $Aut{h}_1=h(r_i\left|\right|M{V}_i)$ and $M_1=M{V}_i\oplus r_i$. Finally, $v_i$ sends the message $\{Aut{h}_1,M_1,HI{D}_i\}$ to the concerned $RS{U}_j$ via an insecure channel.

Step 2:

$RS{U}_j$ selects $r_j$, and computes $B_i=R{B}_j\oplus r_j$ and $Aut{h}_2=h(I{D}_{RS{U}_j}\left|\right|R{B}_j\left|\right|r_j)$. Then, $RS{U}_j$ sends the values $\{Aut{h}_1,M_1,HI{D}_i,B_i,R{A}_j,Auh{t}_2\}$ to the $TA$ via an insecure channel.

Step 3:

when $TA$ receives the message from $RS{U}_j$, $TA$ computes $M{V}_i^{\prime }=h(HI{D}_i\left|\right|h\left(x\right|\left|y\right))$, $r_i=M_1\oplus M{V}_i$ and $Aut{h}_i^{\prime }=h(r_i\left|\right|M{V}_i)$. Then, $TA$ compares $Aut{h}_1^{\prime }$ and $Aut{h}_1$. If they are equal, $TA$ extracts the values $R{B}_j=h(R{A}_j\left|\right|h\left(x\right|\left|y\right))$ and $r_j=R{B}_j\oplus B_i$. $TA$ computes $Aut{h}_2^{\prime }=h(I{D}_{RS{U}_j}\left|\right|R{B}_j\left|\right|r_j)$ and compares it with $Aut{h}_2$. If they are same, $TA$ generates a new secret key $y_{new}$. $TA$ computes $R{B}_{jnew}=h(R{A}_j\left|\right|h\left(x\right||y_{new})$, $C_i=R{B}_j\oplus r_i$, $D_i=M{V}_i\oplus r_j$, $E_i=R{B}_{jnew}\oplus r_j$, $Aut{h}_3=h(R{B}_j\left|\right|r_i)$ and $Aut{h}_4=h(M{V}_i\left|\right|r_j)$. Finally, $TA$ sends the message $\{C_i,D_i,E_i,Aut{h}_3,Aut{h}_4\}$ to $RS{U}_j$ through an open channel.

Step 4:

after receiving the values from $TA$, $RS{U}_j$ extracts $r_i=R{B}_j\oplus C_i$, $R{B}_{jnew}=r_j\oplus E_i$ and computes $Aut{h}_3^{\prime }=h(R{B}_j\left|\right|R{B}_{jnew}\left|\right|r_i)$. Then $RS{U}_j$ checks whether $Aut{h}_3^{\prime }$ and $Aut{h}_3$ are equal or not. If they are equal, $RS{U}_j$ updates $R{B}_j$ to $R{B}_{jnew}$ and generates the session key $SK=h\left(r_i\right|\left|r_j\right)$. $RS{U}_j$ sends the message $\{D_i,Aut{h}_4\}$ to $v_i$ via a public channel.

Step 5:

$v_i$ extracts the value $r_j=M{V}_i\oplus D_i$, computes $Aut{h}_4^{\prime }=h(M{V}_i\left|\right|r_j)$ and checks whether $Aut{h}_4^{\prime }$ and $Aut{h}_4$ are same or not. If they are equal, $v_i$ computes the session key $SK=h\left(r_i\right|\left|r_j\right)$. Finally, $v_i$ and concerned $RS{U}_j$ have the same session key.

5.3. Message Signature and Message Confirmation Phase

If the $v_i$ wants to send information to the concerned RSU, $v_i$ must sign the message using the session key and sends it to the $RS{U}_j$. Additionally, $RS{U}_j$ checks whether the message is legitimate or not. If the message is legitimate, $RS{U}_j$ validates the message and sends it to a cloud server. The detailed steps are as following and are shown in Figure 7.

Figure 7. Message signature and confirmation phase of our proposed protocol.

Step 1:

for signing the information $M_i$, $v_i$ computes ${\sigma }_i=SK\oplus h(M_i\left|\right|T_1)$ and $M_i^{\prime }=SK\oplus M_i\oplus T_1\oplus I{D}_{RS{U}_j}$ and sends the message $\{{\sigma }_i,M_i^{\prime },T_1\}$ to the concerned $RS{U}_j$.

Step 2:

after receiving the message, $RS{U}_j$ extracts information $M_i=SK\oplus M_i^{\prime }\oplus T_1\oplus I{D}_{RS{U}_j}$, computes ${\sigma }_i^{\prime }=SK\oplus h(M_i\left|\right|T_1)$ and checks whether ${\sigma }_i$ and ${\sigma }_i^{\prime }$ are equal or not. If they are the same, $RS{U}_j$ uses the information $M_i$ for the future computations. Additionally, generally for batch verification, $RS{U}_j$ inspects the exaction by a following equation:

$$(\sum _{i=1}^n{v}_i·{\sigma }_i)=\sum _{i=1}^n{v}_i·SK\oplus \sum _{i=1}^n{v}_i·h(M_i\left|\right|T_1)$$

6. Security Analysis

We simulate with the AVISPA simulation tool [23,24] in order to demonstrate that the proposed protocol is able to prevent against replay and man-in-the-middle attacks. We also prove the session key security using the ROR model [25] and conduct the informal security analysis. Therefore, our proposed protocol can provide security against various attacks including impersonation, side channel attack over TPD, trace attack, and so on.

6.1. ROR Model

In this section, we use the universally-accepted real-or-random (ROR) model [25] in order to prove the security of the session key in our proposed protocol.We provide the similar proof as adopted in [26,27].

Short Discussion about ROR Model

In the ROR model [25], the malicious attacker $\mathcal{A}$ is modeled using the DY model, which interacts with the instance of the participants in the protocol. In our proposed protocol, $v_i$, $RS{U}_j$ and $TA$ are considered as participants. Additionally, $P_{v_i}^{t^1}$, $P_{RS{U}_j}^{t^2}$, and $P_{TA}^{t^3}$, which are called $oracles$ denoting the instances $t^1$, $t^2$, and $t^3$ of $v_i$, $RS{U}_j$, and $TA$, respectively. Table 2 shows various queries that simulate attacks, such as eavesdropping, modifying, and deleting or inserting the transmitted messages among the entities. $h(·)$ and Collision-resistant one-way hash function $Hash$ are modeled as a random oracle and they can be used by all participants including $\mathcal{A}$.

Table 2. Various queries and their meanings.

Query	Meaning
$Execute(P_{v_i}^{t^1}$, $P_{RS{U}_j}^{t^2}$, $P_{TA}^{t^3})$	This query means that the model of the eavesdropping attack between the entities $v_i$, $RS{U}_j$ and $TA$ via an insecure channels.
$CorruptOBU(P_{v_i}^{t^1})$	Under this corrupt on-board-unit (OBU) query, $\mathcal{A}$ can fetch all sensitive credentials stored in the OBU of $v_i$. This is modeled as an active attack.
$Send\left(P^t\right)$	Under this query, $\mathcal{A}$ can transmits a message to $P^t$, and in response, it also receives a message from $P^t$. This is also modeled as an active attack.
$Reveal\left(P^t\right)$	The query means that $\mathcal{A}$ reveals session key $SK$ created by $P^t$ and its partner to $\mathcal{A}$ in the current session.
$Test\left(P^t\right)$	Before the game begins, under this query, an unbiased coin c is flipped. Depending on the output, the following decisions are made. $\mathcal{A}$ executes this query and if the session key $SK$ among $v_i$ and $RS{U}_j$ is fresh, $P^t$ returns $SK$ if $c=1$ or a random nonce if $c=0$; otherwise, it returns a null value(⊥).

Wang et al. [28] showed that the password chosen by the user follows the Zipf’s law, which is quite different from the uniform distribution. They also found that the size of password dictionary is quite limited in the sense that users do not generally use the entire space of the passwords; instead, they use a small space of the allowed characters space. We apply the Zipf’s law in order to prove the session key security of our proposed protocol.

Theorem 1.

If $Ad{v}_P$ is the advantage function of an attacker $\mathcal{A}$ in breaking the session key $SK$ security of the proposed protocol P, respectively, $q_h$, $q_{send}$, and $\left|Hash\right|$ are the number of $Hash$ queries, $Send$ queries, and the range space of the hash function, respectively. Subsequently,

$$Ad{v}_P\le \frac{q_h^2}{\left|Hash\right|}+2max\{C^{\prime }·q_{send}^{s^{\prime }}\}$$

where $C^{\prime }$ and $s^{\prime }$ are the Zipf’s parameters [28].

Proof. 

We define four games, called game $G{M}_i$, $i\in [0,1,2,3]$. The probability associated with $G{M}_i$ in which $\mathcal{A}$ can guess the random bit c and wins the game and denoted by $Suc{c}_i$. Moreover, $Pr[.]$ denotes the probability. We discuss the details for these four defined games below.

• Game$G{M}_0$: in this game, $\mathcal{A}$ chooses a random bit c. Additionally, this game involves a practical attack executed by $\mathcal{A}$ against the protocol in the ROR model. Because $G{M}_0$ and protocol are identical, we get,

  $$Ad{v}_P=|2·Pr\left[Suc{c}_0\right]-1|.$$

  (1)
• Game$G{M}_1$: under this game, $\mathcal{A}$ performs the eavesdropping attack to all transmitted messages during key generation and message confirmation process of the proposed protocol using the $Execute$ query. At the end of the this game, $\mathcal{A}$ makes $Reveal$ and $Test$ queries. The output of the $Reveal$ and $Test$ queries decide if $\mathcal{A}$ obtains the derived session key $SK$ between $v_i$ and $RS{U}_j$ or a random number. In our proposed protocol, $v_i$ and $RS{U}_j$ computes the session key as $SK=h\left(r_i\right|\left|r_j\right)$. To derive $SK$, $\mathcal{A}$ needs the short-term (temporal) secrets ($r_i$ and $r_j$), which are unknown to $\mathcal{A}$. However, the transmitted messages are not helpful to increase winning probability. As both the game $G{M}_0$ and $G{M}_1$ are indistinguishable, we can get

  $$Pr\left[Suc{c}_1\right]=Pr\left[Suc{c}_0\right].$$

  (2)
• Game$G{M}_2$: this game is modeled as an active attack which includes the simulation of $Hash$ and $Send$ queries. In proposed protocol, all of the messages are protected by the collision-resistant one-way hash function except $M_1,B_j,C_i$ and $D_i$. However, random numbers are used in values $M_1,B_j,C_i$ and $D_i$. Furthermore, deriving $r_i$ from the intercepted $Aut{h}_1$, $C_i$, and $M_1$, and also $r_j$ from intercepted $B_i$, $Aut{h}_2$, $D_i$, and $Aut{h}_4$ are computationally infeasible task because of collision-resistant property of the hash function. Therefore, no collision occurs when $\mathcal{A}$ executes $Hash$ query. Using the birthday paradox results, we can have,

  $$|Pr\left[Suc{c}_2\right]-Pr\left[Suc{c}_1\right]|\le \frac{q_h^2}{2\left|Hash\right|}.$$

  (3)
• Game$G{M}_3$: this is the final game that executes the $CorruptOBU$ query by $\mathcal{A}$. $\mathcal{A}$ can extract all the information $\{A_i,V_i,A{E}_i,B{E}_i,V{S}_i\}$ from the OBU of $v_i$. Note that $HP{W}_i=h(HI{D}_i\left|\right|P{W}_i)$, $A{E}_i=h(I{D}_i\left|\right|P{E}_i)\oplus a_i$, $P{E}_i=h(P{W}_i\left|\right|b_i)$, $B{E}_i=b_i\oplus h(I{D}_i\left|\right|P{W}_i)$, and $V{S}_i=h(HI{D}_i\left|\right|M{V}_i\left|\right|s_i)$. To derive the secrets $s_i$, $a_i$, and $b_i$ from $A_i$, $V{I}_i$, $B{E}_i$, and $A{E}_i$, $\mathcal{A}$ needs unknown $I{D}_i$ and $P{W}_i$. Without having secret credentials $b_i$, $I{D}_i$, and $P{W}_i$ of $v_i$, it is a computationally difficult problem for $\mathcal{A}$ to guess password $P{W}_i$ of $v_i$ correctly using the $Send$ queries. Because $G{M}_2$ and $G{M}_3$ are identical when password guessing attack is absent. Therefore, using the Zipf’s law on passwords, we obtain

  $$|Pr\left[Suc{c}_3\right]-Pr\left[Suc{c}_2\right]|\le C^{\prime }·q_{send}^{s^{\prime }}.$$

  (4)

All of the games are executed; therefore, $\mathcal{A}$ needs to guess the correct bit c. Therefore, we have

$$Pr\left[Suc{c}_3\right]=\frac{1}{2}.$$

(5)

Equations (1) and (2) give the following result:

$$\begin{array}{cc}\hfill \frac{1}{2}Ad{v}_P& =|Pr\left[Suc{c}_0\right]-\frac{1}{2}|\hfill \\ \hfill & =|Pr\left[Suc{c}_1\right]-\frac{1}{2}|.\hfill \end{array}$$

(6)

Again, Equations (5) and (6) give the following result:

$$\begin{array}{c}\hfill \frac{1}{2}Ad{v}_P=|Pr\left[Suc{c}_1\right]-Pr\left[Suc{c}_3\right]|.\end{array}$$

(7)

We obtain the following equation using the triangular inequality and Equations (3) and (4):

$$\begin{array}{cc}\hfill \frac{1}{2}Ad{v}_P& =|Pr\left[Suc{c}_1\right]-Pr\left[Suc{c}_3\right]|\hfill \\ \hfill & \le |Pr\left[Suc{c}_1\right]-Pr\left[Suc{c}_2\right]|+|Pr\left[Suc{c}_2\right]-Pr\left[Suc{c}_3\right]|\hfill \\ \hfill & \le \frac{q_h^2}{2\left|Hash\right|}+max\{C^{\prime }·q_{send}^{s^{\prime }}\}.\hfill \end{array}$$

(8)

At last, we obtain the required result by multiplying both sides of Equation (8) by a factor of 2:

$$Ad{v}_P\le \frac{q_h^2}{\left|Hash\right|}+2max\{C^{\prime }·q_{send}^{s^{\prime }}\}.$$

Therefore, the Theorem 1 is proved. □

6.2. Formal Security Analysis through AVISPA

We perform a formal security analysis of the proposed protocol using the AVISPA validation tool in order to demonstrate that the protocol can resist replay and man-in-the-middle attacks. The AVISPA adopts the High-Level Protocol Specification Language (HLPSL) code. We briefly discuss AVISPA and present HLPSL codes of our protocol. After that, we present the simulation results of the AVISPA to show that our protocol can protect against man-in-the-middle and replay attacks. Numerous studies verified with the AVISPA tool have been presented [29,30,31].

6.2.1. Proposed Protocol’s HLPSL Code

The AVISPA uses the four back-ends, such as On-the-fly Model-Checker (OFMC) [32], CL-based Attack Searcher (CL-AtSe) [33], SAT-based Model-Checker (SATMC), and Tree Automate-based Protocol Analyser (TA4SP) in order to verify security of a protocol. The code is translated into intermediate format (IF), and IF uses four back-ends to convert to output format (OF). Especially, OFMC and CL-AtSe are commonly used for verification.

The proposed protocol has three basic $roles$ which denote entities: $VI$ denotes a vehicle, $RSU$ denotes a roadside unit and $TA$ denotes a trusted authority. Roles of $session$ and $environments$ are illustrated in Figure 8. In $session$ and $environments$, we set up the intruder knowledge, five authentication goals and four secrecy goals. We briefly discuss HLPSL code for role $VI$ shown in Figure 9.

Figure 8. Code of session and environments.

Figure 9. Code of vehicle.

At transition 1, $VI$ begins registration phase at 0 state value with start message, and $VI$ updates the state to 1. $VI$ sends message $\{I{D}_i,P{W}_i,P{E}_i,B{E}_i\}$ to $TA$ through closed channels and declares the function $secret(\{IDi,PWi,B{i}^{\prime }\},sp1,\left\{VI\right\})$, which means that $sp1$ denotes values $\{IDi,PWi,B{i}^{\prime }\}$ which are only known to $VI$. At transition 2, $VI$ receives the $OB{U}_i$ from $TA$ and updates the state to 2. At the state 2, $VA$ generates a random number $r_i$, sends the message $\{Aut{h}_1,M_1,HI{D}_i\}$ to the $RS{U}_j$ through an open channel, and declares function $witness(VI,TA,vi\_ta\_ri,R{i}^{\prime })$, which means that $vi\_ta\_ri$ denotes a weakness authentication factor is used by $VI$ to authenticate $TA$. At transition 3, $VI$ receives the message from $RSU$. After that $VI$ generates the session key $SK$, performs message confirmation and declares $witness(VI,RSU,vi\_rsu\_sig,S{K}^{\prime })$ and $request(VI,TA,ta\_vi\_auth4,R{j}^{\prime })$. The function $request(VI,TA,ta\_vi\_auth4,R{j}^{\prime })$ means that $ta\_vi\_auth4$ represents a strong authentication factor. The codes of $RSU$ and $TA$ are similar to the code of $VI$.

6.2.2. Results of Verification

The verification results using models OFMC and CL-AtSe are shown in Figure 10. Two simulations are able to check whether the protocol withstands man-in-the-middle and replay attacks. The CL-AtSe verification shows that three states are analyzed and translated to 0.11 s. The results of OFMC shows that it visits 1040 nodes with a search time of 9.57 s and 9 plies depth. The summary part of CL-AtSe and OFMC indicates SAFE, so we can say that the proposed protocol resists replay and man-in-the-middle attacks.

Figure 10. Result of Automated Validation of Internet Security Protocols and Applications (AVISPA) simulation using On-the-fly Model-Checker (OFMC) and CL-based Attack Searcher (CL-AtSe) models.

6.3. Informal Analysis

In this section, we analyze informal security verification in order to prove that the proposed protocol can resist numerous attacks, such as OBU stolen, impersonation, session key disclosure, off-line guessing attacks, and so on. Moreover, we show that the proposed protocol can achieve privacy-preserving and mutual authentication.

6.3.1. Vehicle Impersonation Attack

If an adversary $\mathcal{A}$ attempts to impersonate a vehicle $v_i$, $\mathcal{A}$ should generate message $\{Aut{h}_1,M_1,HI{D}_i\}$ and $\{{\sigma }_i,M_i^{\prime },T_1\}$. However, $\mathcal{A}$ cannot extract $a_i$, $r_i$ and $M{V}_i$ even if $\mathcal{A}$ extracts the value stored in the OBU. Because $a_i$, $r_i$ and $M{V}_i$ are masked with random numbers $b_i$, $s_i$, and session key $SK$. Therefore, the proposed protocol resists impersonation attacks, because $\mathcal{A}$ cannot generate the correct messages.

6.3.2. Side Channel Attack over OBU

We assume that $\mathcal{A}$ can extract values from the OBU based on our assumed threat model. Therefore, $\mathcal{A}$ can perform side channel attack over OBU and extract $\{A_i,V{I}_i,A{E}_i,B{E}_i,V{S}_i\}$. However, $\mathcal{A}$ cannot obtain any useful information without identity, password, and secret random numbers, because all of the values stored in OBU are masked with one-way hash function or XOR operation on $a_i$, $b_i$, and $s_i$. Thus, $\mathcal{A}$ does not have any advantage of side channel attack over OBU.

6.3.3. Off-Line Guessing Attack

$\mathcal{A}$ cannot guess the identity or password, because $b_i=B{E}_i\oplus h(I{D}_i\left|\right|P{W}_i)$, $a_i=A{E}_i\oplus h(I{D}_i\left|\right|P{E}_i)$ and $P{E}_i=h(P{W}_i\left|\right|b_i)$ are masked with random numbers and the secret values $I{D}_i$ and $P{W}_i$. $\mathcal{A}$ must also check whether $V{S}_i$ and calculate $V{S}_i^{\prime }$ by $\mathcal{A}$ to see whether the identity and password are guessed correctly. For this, $\mathcal{A}$ can perform a side channel attack over OBU to obtain the stored values $\{A_i,V{I}_i,A{E}_i,B{E}_i,V{S}_i\}$. However, to calculate $V{S}_i^{\prime }$, $\mathcal{A}$ needs to know the secret random number $s_i$ and secret parameter $M{V}_i$. This allows for being computationally expensive to guess identity or password. Therefore, we show that the proposed protocol can prevent off-line guessing attacks.

6.3.4. Man-in-the Middle Attack and Replay Attack

The adversary $\mathcal{A}$ can obtain the transmitted messages over an open channel and stored parameters in the OBU according to the threat model. However, we show that $\mathcal{A}$ cannot generate valid vehicle’s messages as mentioned above. Furthermore, $\mathcal{A}$ also cannot generate the $RS{U}_j$’s message, because $\mathcal{A}$ does not know secret random numbers $r_i$, $r_j$ and secret parameter $R{B}_j$. Thus, $\mathcal{A}$ cannot impersonate $v_i$ or $RS{U}_j$ by replaying intercepted messages as all messages are dynamic with random numbers $r_i$ and $r_j$. Therefore, the proposed protocol prevents man-in-the-middle and replay attacks.

6.3.5. Session Key Disclosure Attack

Even if $\mathcal{A}$ has obtained values, as mentioned above, $\mathcal{A}$ cannot generate the session key $SK$. The $SK$ comprises the hash function with secret random numbers $r_i$ and $r_j$. However, $\mathcal{A}$ cannot extract random numbers, because they are masked with secret parameters $M{V}_i$ and $R{B}_j$. Moreover, $M{V}_i$ and $R{B}_j$ are also masked with random numbers. Therefore, $\mathcal{A}$ does not know about the session key $SK$.

6.3.6. Trace Attack and Privacy-Preserving

The vehicle $v_i$ does not send its real identity $I{D}_i$ over an open channel. The vehicle generates the pseudonym identity $HI{D}_i=h(I{D}_i\left|\right|P{W}_i\left|\right|a_i)$. And also $RS{U}_j$ uses the $R{A}_j$ instead of real identity $I{D}_{RS{U}_j}$. Moreover, as above mentioned Sections, $\mathcal{A}$ cannot impersonate legitimate vehicles and also cannot generate a validated session key. Therefore, the proposed protocol provides the privacy-preserving. $v_i$ and $RS{U}_j$ communicate the information using the session key without pseudonym identities. Thus, we can say that the proposed protocol can prevent trace attack.

6.3.7. Mutual Authentication

After receiving message the $\{Aut{h}_1,M_1,HI{D}_i,B_i,R{A}_j,Aut{h}_2\}$ from $v_i$ and $RS{U}_j$, $TA$ checks whether $Aut{h}_1^{\prime }\stackrel{?}{=}Aut{h}_1$. If it is equal, $TA$ also checks $Aut{h}_2^{\prime }\stackrel{?}{=}Aut{h}_2$. Subsequently, $TA$ sends $\{C_i,D_i,Aut{h}_3,Aut{h}_4\}$ to the $v_i$ and $RS{U}_j$ for authenticating. $RS{U}_j$ checks $Aut{h}_3^{\prime }\stackrel{?}{=}Aut{h}_3$ and $v_i$ checks also $Aut{h}_4^{\prime }\stackrel{?}{=}Aut{h}_4$. If they are valid, $v_i$, $RS{U}_j$, and $TA$ successfully authenticate each other. Previous sections have shown that $\mathcal{A}$ cannot generate valid messages. Furthermore, all of the transmitted messages are refreshed for every session with secret random numbers. Therefore, our proposed protocol successfully ensures secure mutual authentication and achieves session key agreement.

7. Performance Analysis

In this section, we compare our proposed protocol with other related protocols for VANETs. We consider computation, communication costs, and security features.

7.1. Computation Cost

We show the comparison outcomes in Table 3. Our proposed protocol is lightweight as compared to other related protocols. Therefore, we can demonstrate that the proposed protocol is suitable for vehicular cloud environment in VANETs.

Table 3. Computation cost of key generation and message confirmation phase.

Protocols	Computational Complexity	Total Cost
Jianhong et al. [13]	$T_{bpsm}+3T_{bp}+T_{MPH}$	18.748 ms
Zhong et al. [16]	5$T_{sem}$+3$T_h$+$Tea$	0.0711 ms
Limbasiya et al. [4]	4$T_h$+2$T_{sem}$	0.0280 ms
Ours	22$T_h$	0.0022 ms

XOR operation is negligible as compared to other operations.

For comparing the computational cost, we define following notations. $T_{bp}$, $T_{bpsm}$, $T_{MPH}$, $T_h$, $T_{sem}$ and $T_{ea}$, which denotes the execution time of bilinear mapping, multiplication related to bilinear pairing, map-To-point hash, one-way hash, small scale multiplication related to elliptic curve cryptography (ECC), and addition related to ECC. We focus on time overhead in the process of authentication message generation and message verification. For rough estimation, we consider the existing results reported by [34]. The execution time of each operation is as following.

• $T_{bp}$: Time for bilinear pairing operation (≈4.2110 ms)
• $T_{bpsm}$: Time for small scale multiplication related to bilinear pairing (≈1.7090 ms)
• $T_{MPH}$: Time for map-To-point hash operation (≈4.406 ms)
• $T_h$: Time for one-way hash operation (≈0.0001 ms)
• $T_{sem}$: Time for small scale multiplication related to ECC (≈0.0138 ms)
• $T_{ea}$: Time for point addition related to ECC (≈0.0018 ms)

7.2. Communication Cost and Storage Cost

We compare communication cost overheads among related protocols and proposed protocol during the message confirmation phase in Table 4. We assume that the identity, password, and normal variable needs eight bytes, the time-stamp needs four bytes, an ECC encryption/decryption needs 32 bytes, a bilinear pairing needs 128 bytes, and one-way hash function needs 32 bytes [4]. As the results of the comparison, the proposed protocol is the most efficient when compared with other related protocols. The storage overhead is calculated based on the total number of bytes required to store required parameters in OBU or TPD and RSU. The proposed protocol has 224 bytes storage cost, where OBU has 160 bytes and RSu has 64 bytes. Although the total memory of our protocol is slightly higher than that of other protocols, our protocol ensures security.

Table 4. Communication cost and storage cost.

Protocols	Communication Cost	Storage Cost	Total Memory
Jianhong et al. [13]	132 bytes	528 bytes	660 bytes
Zhong et al. [16]	100 bytes	136 bytes	236 bytes
Limbasiya et al. [4]	124 bytes	32 bytes	156 bytes
Ours	100 bytes	224 bytes	324 bytes

7.3. Energy Consumption

Researchers need to consider the size and speed of the message being sent to the recipient. This is because data transmission occurs under Dedicated Short-Range Communication (DSRC) and, in the case of vehicle networks defined in IEEE 802.11p, it belongs to the physical protocol layer. This IEEE standard operates at 10 MHz channel bandwidth, 5.8 GHz frequency, 25 dBm transmit power, and 6 Mbps data rate [35]. The energy consumption for the verification scheme can be calculated as $E_{et}$ (for the execution time of key generation and message confirmation) $E_{co}$ (for the communication cost for message confirmation) and it is measured in millijoule (mJ). For the execution time, $E_{et}=T_c\ast C$, where $T_c$ = Total computation cost, C = cpu maximum power, which is 10.88 W for wireless communication networks [36]. $E_{et}=(D_m\ast C)/\left(D_r\right)$, where $D_m$ = the size of message, $D_r$ = the data rate for vehicular communications (6000 Kbps). By referring to Table 5, we can say that the proposed protocol consumes the least energy.

Table 5. Energy consumption.

Protocols	Execution Energy Consumption	Communication Energy Consumption
Jianhong et al. [13]	203.978 mJ	0.239 mJ
Zhong et al. [16]	0.774 mJ	0.181 mJ
Limbasiya et al. [4]	0.305 mJ	0.225 mJ
Ours	0.024 mJ	0.181 mJ

7.4. Propagation Delay

The propagation delay ($d_p=T_2-T_1$) is determined by computing the difference between the timestamps of a message received ($T_2$) and transmitted ($T_1$). But $d_p$ expects some time interval, which can be stated as in $d_{p\left(V2V\right)}=\frac{L\ast h}{f}$ and $d_{p\left(V2I\right)}=\frac{L}{f_{RSU}}$ for L length messages (i.e., communication cost) at f transmitted data rate along with h hops through which a message is traveled [37]. Thus, the propagation delay of our protocol is the lowest, because the communication cost of the proposed protocol is the lowest.

7.5. Security Properties

In Table 6, we present the results of protocols related to security comparisons and our proposed protocol based on batch verification. The suggested protocol prevents more attacks than other related previous studies, and also provide privacy-preserving and mutual authentication. Therefore, our proposed protocol is significantly safer than the considered related protocols. The system consumes some energy during implementation, depending on the real time and communication overhead of the system.

Table 6. Security Properties.

Security Properties	Jianhong et al. [13]	Zhong et al. [16]	Limbasiya et al. [4]	Ours
Impersonation attack	x	x	x	o
Side channel attack over OBU or TPD	-	x	x	o
Trace attack	o	o	o	o
Replay attack	x	o	o	o
Man-in-the-middle attack	x	x	o	o
Privacy-preserving	o	o	o	o
Mutual authentication	x	x	x	o

x: Insecure. o: Secure. -: Does not concern.

8. Conclusions

Vehicle systems have developed significantly and they have recently helped people to drive more comfortably and safely. However, unsolved security problems and large quantities of traffic information have limited the use of vehicle systems. The VCC with message confirmation is the one of solutions to decline burdens of OBU’s storage. And VCC helps to use the vast amount of vehicle information easily. In addition, to protect the vehicle information, key agreement and authentication process is also necessary to address malicious attacks, including communication security problems. Additionally, previous studies and the protocol of Limbasiya et al. are not safe for stored values in ideal or realistic TPDs. In this paper, we first showed that protocol of Limbasiya et al. is not secure against session key disclosure and impersonation attacks because of information leaked from a TPD. Their protocol also does not provide privacy of the users and mutual authentication property. Subsequently, we proposed a secure key agreement and authentication protocol for message confirmation in VCC. The proposed protocol withstands various attacks and provides privacy of users and mutual authentication. We conducted formal security analysis and simulation to prove the security of the proposed protocol. Moreover, we compared computation, communication costs and the security properties with other related protocols. Thus, our proposed protocol is lightweight and suitable for VCC environments. As part of the future, we will put effort into developing a better protocol by applying the developed protocol to the real environment.