# Designing an Efficient and Secure Message Exchange Protocol for Internet of Vehicles

Authors: Shehzad Ashraf Chaudhry
Journal: Security and Communication Networks
 (2021)

---

## Abstract

In the advancements in computation and communication technologies and increasing number of vehicles, the concept of Internet of Vehicles (IoV) has emerged as an integral part of daily life, and it can be used to acquire vehicle related information including road congestion, road description, vehicle location, and speed. Such information is very vital and can benefit in a variety of ways, including route selection. However, without proper security measures, the information transmission among entities of IoV can be exposed and used for wicked intentions. Recently, many authentication schemes were proposed, but most of those authentication schemes are prone to insecurities or suffer from heavy communication and computation costs. Therefore, a secure message authentication protocol is proposed in this study for information exchange among entities of IoV (SMEP-IoV). Based on secure symmetric lightweight hash functions and encryption operations, the proposed SMEP-IoV meets IoV security and performance requirements. For formal security analysis of the proposed SMEP-IoV, BAN logic is used. The performance comparisons show that the SMEP-IoV is lightweight and completes the authentication process in just0.198ms.


---

## Body

## 1. Introduction

The Internet of Vehicles (IoV) is a self-organized network of vehicles on the road and the road side units (RSUs). The IoV provides intervehicles (V2V) and vehicles to RSUs (V2R) communication infrastructure [1], which can benefit in many ways including the information relating to road congestion/traffic issues, parking information, alternative routes, and warnings of potential accidents. Using the information, the drivers can quickly make decisions relating to vehicles and/or road/s. It can further help the unmanned vehicles regarding the accuracy and safety through the use of more sophisticated information and artificial intelligence techniques. The information exchanged or the communication among entities of IoV is always through public wireless channel, which makes it prone to several attacks. An attacker can easily listen and extract the meaningful information from the exchanged messages. Such information can be very crucial for the accuracy and safety of the vehicles in an IoV. The attacker can replay an old message or can inject a message with total fake information, and it can cause some severe consequences on the vehicles and the riders including the accidents. Moreover, the listened information can be used by an attacker to trace/track a vehicle/rider, and such information can be used for criminal/terrorism purposes. The information can also be faked for marketing purposes to gain attraction of the riders, while they are attracted to a specific route through false information of traffic as well as to compete for the parking lots [2].Therefore, the security and privacy of the entire IoV including the communicating entities have more importance than all other factors. The goal can be achieved through authentication of the entities including vehicles before initiation of the communication among the entities of IoV. In this study, we proposed a lightweight symmetric key-based authentication scheme to secure message exchange among the entities of the IoV. We organize rest of the study as follows: Table1 provides the notation guide. In Subsection 1.1, the system model is described. The motivations and contributions of the study are explained in Subsection 1.2, while the Subsection 1.3 discusses the adopted adversarial model. The Section 2 summarizes the existing related literature; whereas, our proposed secure message exchange protocol for IoV (SMEP-IoV) scheme is explained in Section 3. Using BAN logic, the Section 4 formally proves the security of the SMEP-IoV. In Section 5, a discussion on functional security and attack resilience of the proposed SMEP-IoV is given. Security and performance comparisons of the proposed SMEP-IoV with related schemes are given in Section 6. The study is concluded finally in Section 7.Table 1
Notations guide.
SymbolsRepresentationsVS,ViVehicle server, vehicleRSUjRoad side unitIDvi,IDrjID’s ofVi and RSUjKVSMaster secret key ofVSKrjShared key amongRSUj and Vitx,rsTimestamp and random number of entityxPIDviPseudoidentity ofViHa,‖Hash ofa and concatenation


### 1.1. System Model

Figure1 shows a typical IoV scenario. It consists of vehicles, each having installed a processing unit called on-board unit, which is responsible for communication and processing of exchanged data among the vehicle and other entities of an IoV. Along with vehicles, there are road side units (RSUs), which are the infrastructure deployed on the road. Typically, communication is performed among vehicles and nearby RSU. Moreover, intervehicle communication is also an important component of the IoV. The whole network is administered by a trusted authority called vehicle server (VS). All the vehicles and related entities (RSUs) join the IoV by registering with VS. After getting registered with VS, the two entities can communicate with each other, for which both have to authenticate each other, and the authentication ensures that both communicating entities are legitimate.Figure 1
Typical IoV scenario.


### 1.2. Motivation and Contributions

Recently, many authentication schemes are proposed to secure message exchange among the entities of an IoV. However, many authentication schemes for IoV lack the required security features and resistance to known attacks. In this connection, Yu et al. proved some of the weaknesses of the scheme of Vasudev et al. Yu et al. further claimed to propose a secure authentication scheme with all required security features. The arguments in preceding section of this study refute their claim and the proof relating to several insecurities of Yu et al.’s scheme calls for an authentication scheme with all required security features.The contributions of this study are many folds:(i)
Initially, we unveiled that the insecurities of the IoV authentication scheme proposed by Yu et al. We then proposed a robust authentication scheme using symmetric key-based encryption and hash functions.(ii)
The security of the proposed scheme is proved using formal RoR.(iii)
The comparative study with respect to efficiency and security among proposed and several existing studies is also provided in this study.


### 1.3. Attack Model

We have taken into consideration the eCK adversary model [3], with strong adversary as compared with DY [4] and CK [5] models. The eCK is an extension of the CK model with a more strong adversary having capabilities to launch a key compromise impersonation attack in addition to controlling the communication channel, launching the power analysis to extract secrets stored in the smart card and access to all public parameters [6,7].


## 1.1. System Model

Figure1 shows a typical IoV scenario. It consists of vehicles, each having installed a processing unit called on-board unit, which is responsible for communication and processing of exchanged data among the vehicle and other entities of an IoV. Along with vehicles, there are road side units (RSUs), which are the infrastructure deployed on the road. Typically, communication is performed among vehicles and nearby RSU. Moreover, intervehicle communication is also an important component of the IoV. The whole network is administered by a trusted authority called vehicle server (VS). All the vehicles and related entities (RSUs) join the IoV by registering with VS. After getting registered with VS, the two entities can communicate with each other, for which both have to authenticate each other, and the authentication ensures that both communicating entities are legitimate.Figure 1
Typical IoV scenario.


## 1.2. Motivation and Contributions

Recently, many authentication schemes are proposed to secure message exchange among the entities of an IoV. However, many authentication schemes for IoV lack the required security features and resistance to known attacks. In this connection, Yu et al. proved some of the weaknesses of the scheme of Vasudev et al. Yu et al. further claimed to propose a secure authentication scheme with all required security features. The arguments in preceding section of this study refute their claim and the proof relating to several insecurities of Yu et al.’s scheme calls for an authentication scheme with all required security features.The contributions of this study are many folds:(i)
Initially, we unveiled that the insecurities of the IoV authentication scheme proposed by Yu et al. We then proposed a robust authentication scheme using symmetric key-based encryption and hash functions.(ii)
The security of the proposed scheme is proved using formal RoR.(iii)
The comparative study with respect to efficiency and security among proposed and several existing studies is also provided in this study.


## 1.3. Attack Model

We have taken into consideration the eCK adversary model [3], with strong adversary as compared with DY [4] and CK [5] models. The eCK is an extension of the CK model with a more strong adversary having capabilities to launch a key compromise impersonation attack in addition to controlling the communication channel, launching the power analysis to extract secrets stored in the smart card and access to all public parameters [6,7].


## 2. Related Literature

In their survey, Contreras-Castillo et al. [8] pointed out some security requirements and suggested to address authentication, integrity, confidentiality, and related security requirement before the IoV gain popularity. Some future directions were also discussed in [8]. In addition to the mentioned security requirements in [8], Mokhtar and Azab [9] stressed vehicle privacy, untraceability, access control, and resistance against tempering/forgery and jamming attacks.In recent times, some authentication schemes were proposed [10–13]. Two different schemes were proposed by Lin et al. [14] and Yin et al. [15] using hashchains. Both schemes provided efficient and rapid authentication but lacked vehicle/user anonymity. The absence of anonymity could lead towards the leakage of sensitive vehicle/user information, IoV. In 2015, the scheme of Li et al. [16] was proved to have weaknesses against disclosure of session key attack by Dua et al. [17]. Afterwards in 2016, Wang et al. also proposed a smartcard-based two-factor authentication scheme for IoV [18], which was proved as having weaknesses against many attacks including vehicle/user forgery and smart card stolen attacks, and the scheme was also lacking anonymity by Amin et al. [19]. A pairing-based scheme was also proposed by Liu et al. [20]. However, due to usage of expensive pairing operations, a considerable delay can happen, which is unsuitable for fast moving vehicles. Another lightweight scheme was proposed by Ying et al. [21]. However, Chen et al. [2] found critical weaknesses in the scheme of Ying et al. Due to usage of modular exponentiation, the scheme of Chen et al. entails inefficiencies against storage, communication cost, and computation time. Quite recently, in 2020, Vasudev et al. [22] presented another efficient authentication scheme. In 2020, Yu et al. [23] pointed out that the scheme of Vasudev et al. lacks mutual authentication and has weaknesses against some attacks including session key disclosure and vehicle/user forgery attacks. Yu et al. also proposed an improved scheme. However, the scheme of Yu et al. is prone to many attacks including disclosure of master secret key KVS of the vehicle server. Due to leakage of KVS, the scheme of Yu et al. cannot be deployed in any environment because if an attacker is able to get KVS, it can generate secret parameters for any of the existing device to impersonate on behalf of that device; moreover, the attacker can register and deploy fake vehicles in the system. Any registered device can compute KVS using the Qi stored in the smartcard and its own password and identity related parameters, i.e., RPWi and RIDi. For this, a vehicle/user Vi computes enters password (PWAi), identity (IDAi), and computes RIDi=hIDAi‖PWAi, RNi=Ei⊕hPWAi‖RIDi and RPWi=hPWAi‖RNi. The Vi now computes KVS=Qi⊕hRIDi‖RPWi. Here, KVS is the master secret key of the vehicle server. Now, using KVS, any dishonest vehicle of the system can launch any attack on any devices. For example,(i)
The dishonest vehicle with extractedKVS can disclose any session key shared among two vehicles. Let Vx initiates a login request by sending Mi1,Mi2,MAE,T1. By just listening to the request, the dishonest vehicle using Mi1, Mi2, and T1 can compute R1=Mi1⊕hKVS‖T1 and Mrequest1=Mi2⊕hR1‖KVS, on the fly. Similarly, when the responding vehicle Vy sends reply message M3,MEA,T2, the dishonest vehicle using M3 and T2 can compute Mrequest2‖R2 and the session key SK=hR1‖R2‖KVS by just executing instep two hash functions on the public parameters.(ii)
Likewise, the dishonest device can launch man in middle, impersonation, and all related attacks usingKVS. For example, when Vx sends request message Mi1,Mi2,MAE,T1 to Vy, the dishonest vehicle can extract R1 and then can generate another valid response message M3,MAE,T2 by using KSV and current timestamp. Ultimately, the possession of KSV enables a dishonest vehicle to generate a valid request and a response message, and it can act like a man in middle.


## 3. Proposed SMEP-IoV

The proposed secure message exchange protocol for IoV (SMEP-IoV) consists of four phases. Table1 provides the notation guide to understand the technical details of the proposed SMEP-IoV, briefed in following subsections:


### 3.1. SMEP-IoV : Initialization

The vehicle server (VS) selects its secret keyKvs, a one way hash function H:0,1∗⟶0,1l and a symmetric encryption/decryption function X=EkY.


### 3.2. SMEP-IoV : RSU Registration

During this phase, VS registers all road side units by assigning a unique identityIDrj and a shared secret key Krj=hIDrj‖KVS. The VS stores IDrj in its database.


### 3.3. SMEP-IoV : Vehicle Registration

During this phase, VS registers all vehicles by assigning a unique identityIDvi. Moreover, VS computes Avi=hKVS‖IDvi, PIDvi=EKVSIDvi‖ri0, and Bvi=hPIDvi‖KVS. The VS stores IDvi, PIDvi, Avi, and Bvi in the memory of the vehicle Vi. Furthermore, the VS stores IDvi in its own memory. Please note, except IDvi, the VS does not store any other parameter relating to a vehicle say Vi. Specifically, PIDvi, Avi, and Bvi are not stored in the memory of VS.


### 3.4. SMEP-IoV : Message Authentication

For message authentication, the vehicleVi initiates the following steps with RSUj and vehicle server VS, the in-sequence steps as shown in Figure 2:Figure 2
Proposed SMEP-IoV.


#### 3.4.1. PMA 1

(1)Vi⟶RSUj:Mvi=PIDvi,Mi1,Mi2,ti,where Vi initiates the message authentication process by generating fresh timestamp ti and a random number ri. Vi further computes Mi1=hAvi‖IDvi‖ti‖ri and Mi2=ri⊕Bvi. Vi finalizes these steps by sending Mvi=PIDvi,Mi1,Mi2,ti to RSUj.


#### 3.4.2. PMA 2

(2)RSUj⟶VS:Mrj1=IDrj,Mvi,Mj1,tjOn receivingMvi=PIDvi,Mi1,Mi2,ti, the RSUj checks the freshness of ti by comparing it with current timestamp; if the delay is not within a predefined tolerable range ΔT, the RSUj terminates the process; otherwise, RSUj generates new timestamp tj and a random number rj. Moreover, RSUj computes Mj1=EKrjrj,tj and sends Mrj1=IDrj,Mvi,Mj1,tj to VS.


#### 3.4.3. PMA 3

(3)VS⟶RSUj:Mvs=RSK,VSK,RSV,tvsAfter receivingMrj1=IDrj,Mvi,Mj1,tj, the VS checks the freshness of tj by comparing it with current timestamp; if the delay is not within a predefined tolerable range ΔT, the VS terminates the process; otherwise, VS computes Krj=hIDrj‖KVS and decrypts Mj1 using Krj to obtain the pair rj′,tj′. The VS also verifies the sameness of received tj with decrypted tj′, and in case both are same, the VS using its secret key Kvs decrypts PIDvi and obtains IDvi,r0. Now, the VS computes Avi=hKvs‖IDvi and Bvi=hPIDvi‖Kvs and gets ri=Bvi⊕Mi2. After that, the VS checks Mi1=?hAvi‖IDvi‖ti‖ri, and if verification is successful, the VS generates timestamp tvs and a random number rvs. The VS computes session key SK=hri‖rj‖rvs‖Avi‖Krj, PIDvin=EKvsIDvi‖rvs, Bvin=hPIDvin‖Kvs, and RSK=EKrjSK. In addition, the VS computes VSK=EAviSK‖PIDvin‖Bvin and RSV=hSK‖tvs. Now, the VS sends Mvs=RSK,VSK,RSV,tvs to RSUj.


#### 3.4.4. PMA 4

(4)RSUj⟶Vi:Mrj2=VSK,VSV,tjn.After receivingMvs=RSK,VSK,RSV,tvs, the RSUj checks the freshness of tvs by comparing it with current timestamp; if the delay is not within a predefined tolerable range ΔT, the RSUj terminates the process; otherwise, RSUj computes session key SK=DKrjRSK. Now, RSUj checks the session key verifier RSV=?hSK‖tvs, and if RSV is verified successfully, the RSUj accepts the session key. Now, RSUj generates new timestamp tjn and session key verifier VSV=hSK‖tjn for Vi. After that, the RSUj sends Mrj2=VSK,VSV,tjn to Vi.


#### 3.4.5. PMA 5

After receivingMrj2=VSK,VSV,tjn, the Vi checks the freshness of tjn by comparing it with current timestamp; if the delay is not within a predefined tolerable range ΔT, the Vi terminates the process; otherwise, Vi decrypts VSK using Avi and obtains SK‖PIDvin‖Bvin. Now, Vi checks the session key verifier VSV=?hSK‖tjn, and if VSV is verified successfully, the Vi accepts the session key and updates PIDvi=PIDvin and Bvi=Bvin.


## 3.1. SMEP-IoV : Initialization

The vehicle server (VS) selects its secret keyKvs, a one way hash function H:0,1∗⟶0,1l and a symmetric encryption/decryption function X=EkY.


## 3.2. SMEP-IoV : RSU Registration

During this phase, VS registers all road side units by assigning a unique identityIDrj and a shared secret key Krj=hIDrj‖KVS. The VS stores IDrj in its database.


## 3.3. SMEP-IoV : Vehicle Registration

During this phase, VS registers all vehicles by assigning a unique identityIDvi. Moreover, VS computes Avi=hKVS‖IDvi, PIDvi=EKVSIDvi‖ri0, and Bvi=hPIDvi‖KVS. The VS stores IDvi, PIDvi, Avi, and Bvi in the memory of the vehicle Vi. Furthermore, the VS stores IDvi in its own memory. Please note, except IDvi, the VS does not store any other parameter relating to a vehicle say Vi. Specifically, PIDvi, Avi, and Bvi are not stored in the memory of VS.


## 3.4. SMEP-IoV : Message Authentication

For message authentication, the vehicleVi initiates the following steps with RSUj and vehicle server VS, the in-sequence steps as shown in Figure 2:Figure 2
Proposed SMEP-IoV.


### 3.4.1. PMA 1

(1)Vi⟶RSUj:Mvi=PIDvi,Mi1,Mi2,ti,where Vi initiates the message authentication process by generating fresh timestamp ti and a random number ri. Vi further computes Mi1=hAvi‖IDvi‖ti‖ri and Mi2=ri⊕Bvi. Vi finalizes these steps by sending Mvi=PIDvi,Mi1,Mi2,ti to RSUj.


### 3.4.2. PMA 2

(2)RSUj⟶VS:Mrj1=IDrj,Mvi,Mj1,tjOn receivingMvi=PIDvi,Mi1,Mi2,ti, the RSUj checks the freshness of ti by comparing it with current timestamp; if the delay is not within a predefined tolerable range ΔT, the RSUj terminates the process; otherwise, RSUj generates new timestamp tj and a random number rj. Moreover, RSUj computes Mj1=EKrjrj,tj and sends Mrj1=IDrj,Mvi,Mj1,tj to VS.


### 3.4.3. PMA 3

(3)VS⟶RSUj:Mvs=RSK,VSK,RSV,tvsAfter receivingMrj1=IDrj,Mvi,Mj1,tj, the VS checks the freshness of tj by comparing it with current timestamp; if the delay is not within a predefined tolerable range ΔT, the VS terminates the process; otherwise, VS computes Krj=hIDrj‖KVS and decrypts Mj1 using Krj to obtain the pair rj′,tj′. The VS also verifies the sameness of received tj with decrypted tj′, and in case both are same, the VS using its secret key Kvs decrypts PIDvi and obtains IDvi,r0. Now, the VS computes Avi=hKvs‖IDvi and Bvi=hPIDvi‖Kvs and gets ri=Bvi⊕Mi2. After that, the VS checks Mi1=?hAvi‖IDvi‖ti‖ri, and if verification is successful, the VS generates timestamp tvs and a random number rvs. The VS computes session key SK=hri‖rj‖rvs‖Avi‖Krj, PIDvin=EKvsIDvi‖rvs, Bvin=hPIDvin‖Kvs, and RSK=EKrjSK. In addition, the VS computes VSK=EAviSK‖PIDvin‖Bvin and RSV=hSK‖tvs. Now, the VS sends Mvs=RSK,VSK,RSV,tvs to RSUj.


### 3.4.4. PMA 4

(4)RSUj⟶Vi:Mrj2=VSK,VSV,tjn.After receivingMvs=RSK,VSK,RSV,tvs, the RSUj checks the freshness of tvs by comparing it with current timestamp; if the delay is not within a predefined tolerable range ΔT, the RSUj terminates the process; otherwise, RSUj computes session key SK=DKrjRSK. Now, RSUj checks the session key verifier RSV=?hSK‖tvs, and if RSV is verified successfully, the RSUj accepts the session key. Now, RSUj generates new timestamp tjn and session key verifier VSV=hSK‖tjn for Vi. After that, the RSUj sends Mrj2=VSK,VSV,tjn to Vi.


### 3.4.5. PMA 5

After receivingMrj2=VSK,VSV,tjn, the Vi checks the freshness of tjn by comparing it with current timestamp; if the delay is not within a predefined tolerable range ΔT, the Vi terminates the process; otherwise, Vi decrypts VSK using Avi and obtains SK‖PIDvin‖Bvin. Now, Vi checks the session key verifier VSV=?hSK‖tjn, and if VSV is verified successfully, the Vi accepts the session key and updates PIDvi=PIDvin and Bvi=Bvin.


## 3.4.1. PMA 1

(1)Vi⟶RSUj:Mvi=PIDvi,Mi1,Mi2,ti,where Vi initiates the message authentication process by generating fresh timestamp ti and a random number ri. Vi further computes Mi1=hAvi‖IDvi‖ti‖ri and Mi2=ri⊕Bvi. Vi finalizes these steps by sending Mvi=PIDvi,Mi1,Mi2,ti to RSUj.


## 3.4.2. PMA 2

(2)RSUj⟶VS:Mrj1=IDrj,Mvi,Mj1,tjOn receivingMvi=PIDvi,Mi1,Mi2,ti, the RSUj checks the freshness of ti by comparing it with current timestamp; if the delay is not within a predefined tolerable range ΔT, the RSUj terminates the process; otherwise, RSUj generates new timestamp tj and a random number rj. Moreover, RSUj computes Mj1=EKrjrj,tj and sends Mrj1=IDrj,Mvi,Mj1,tj to VS.


## 3.4.3. PMA 3

(3)VS⟶RSUj:Mvs=RSK,VSK,RSV,tvsAfter receivingMrj1=IDrj,Mvi,Mj1,tj, the VS checks the freshness of tj by comparing it with current timestamp; if the delay is not within a predefined tolerable range ΔT, the VS terminates the process; otherwise, VS computes Krj=hIDrj‖KVS and decrypts Mj1 using Krj to obtain the pair rj′,tj′. The VS also verifies the sameness of received tj with decrypted tj′, and in case both are same, the VS using its secret key Kvs decrypts PIDvi and obtains IDvi,r0. Now, the VS computes Avi=hKvs‖IDvi and Bvi=hPIDvi‖Kvs and gets ri=Bvi⊕Mi2. After that, the VS checks Mi1=?hAvi‖IDvi‖ti‖ri, and if verification is successful, the VS generates timestamp tvs and a random number rvs. The VS computes session key SK=hri‖rj‖rvs‖Avi‖Krj, PIDvin=EKvsIDvi‖rvs, Bvin=hPIDvin‖Kvs, and RSK=EKrjSK. In addition, the VS computes VSK=EAviSK‖PIDvin‖Bvin and RSV=hSK‖tvs. Now, the VS sends Mvs=RSK,VSK,RSV,tvs to RSUj.


## 3.4.4. PMA 4

(4)RSUj⟶Vi:Mrj2=VSK,VSV,tjn.After receivingMvs=RSK,VSK,RSV,tvs, the RSUj checks the freshness of tvs by comparing it with current timestamp; if the delay is not within a predefined tolerable range ΔT, the RSUj terminates the process; otherwise, RSUj computes session key SK=DKrjRSK. Now, RSUj checks the session key verifier RSV=?hSK‖tvs, and if RSV is verified successfully, the RSUj accepts the session key. Now, RSUj generates new timestamp tjn and session key verifier VSV=hSK‖tjn for Vi. After that, the RSUj sends Mrj2=VSK,VSV,tjn to Vi.


## 3.4.5. PMA 5

After receivingMrj2=VSK,VSV,tjn, the Vi checks the freshness of tjn by comparing it with current timestamp; if the delay is not within a predefined tolerable range ΔT, the Vi terminates the process; otherwise, Vi decrypts VSK using Avi and obtains SK‖PIDvin‖Bvin. Now, Vi checks the session key verifier VSV=?hSK‖tjn, and if VSV is verified successfully, the Vi accepts the session key and updates PIDvi=PIDvin and Bvi=Bvin.


## 4. Formal Security Analysis through BAN

The Burrows–Abadi–Needham (BAN) logic analysis is performed to test the protocol from various security aspects with a focus on mutual key agreement, key sharing, and protection from exposure to session key. We used the following symbolic tokens to perform this analysis.(i)
L|≡w¯:L believes w¯(ii)
L⊲w¯:L sees w¯(iii)
L|∼w¯:L once said w¯, some time ago(iv)
L|⇒w¯:L has got the entire jurisdiction over w¯(v)
(#barw): the message w¯ is fresh(vi)
(L)w¯: L is used in formulae with w¯(vii)
w¯,w¯′k:w¯ or w¯′ is symmetrically encrypted with key K(viii)
w¯,w¯′k:w¯ or w¯′ is hashed with key K(ix)
L,w¯k:K is used in formula with w¯ and L(x)
LK↔L′:L communicates with the key KThe following BAN logic rules are used to verify the security features:Rule 1.
Message meaning.(5)L|≡LK↔L′,L⊲<w¯>w¯L|≡L|∼w¯.Rule 2.
Nonce verification.(6)L|≡#w¯,L|≡L′|∼w¯L|≡L′|≡w¯.Rule 3.
Jurisdiction.(7)L|≡L′⇒w¯,L|≡L′|≡w¯L|≡w¯.Rule 4.
Freshness conjunction.(8)L|≡#w¯L|≡#w¯,w¯′.Rule 5.
Belief rule.(9)L|≡w¯,L|≡w¯′L|≡w¯,w¯′.Rule 6.
Session key.(10)L|≡#w¯,L|≡L′≡w¯L|≡LK↔L′.
Corresponding with the above rules and assumptions, we accomplish the following goals in the BAN logic analysis. The symbols used here, i.e.,g,RSUj,Vi,Vs, represent the goal, road side unit, vehicle, and vehicle server.(i)
G1:RSUj|≡RSUj↔SKVs(ii)
G2:RSUi|≡Vs|≡RSUi↔SKVs(iii)
G3:Vi|≡RSUj↔SKVi(iv)
G4:Vi|≡RSUj|≡RSUj↔SKVi(v)
G5:Vs|≡Vi↔SKVs(vi)
G6:Vs|≡Vi↔SKVi
Initially, the communication contents must be adapted into idealized form as shown in the following:(i)
M1:Vi⟶RSUj:PIDvi,Mi1,Mi2,ti:PIDvi,IDvi,ti,riBvi,ti(ii)
M2:RSUj⟶Vs:IDrj,PIDvi,IDvi,ti,riAvi,riBvi,ti,Mj1,tj:IDrj,PIDvi,IDvi,ti,riAvi,riBvi,ti,rj,tjKrj,tj(iii)
M3:Vs⟶RSUj:RSK,VSK,RSV,tvs:SKKrj,SK,PIDvin,BvinAvi,tvsSK,tvs(iv)
M4:RSUs⟶Vi:VSK,VSV,Tjn:SK,PIDvinAvi,tjnSK,tjn
Furthermore, we take the following assumptions to support the security proof.(i)
B1:Vi|≡#ti(ii)
B2:RSUj|≡#tj,tjn(iii)
B3:Vs|≡#tvs(iv)
B4:Vi|≡ViAvi↔Vs(v)
B5:Vi|≡Vi↔SK‖tjnRSUj(vi)
B6:RSUJ|≡RSUj↔SK‖tjnVi(vii)
B7:RSUj|≡RSUj↔KrjRSUj(viii)
B8:Vs|≡VsAvi↔Vi(ix)
B9:Vs|≡Vs↔KrjRSUj(x)
B10:Vi|≡RSUj|≡Vi↔SKRSUj(xi)
B11:RSUj|≡Vi|≡Vi↔SKRSUj(xii)
B12:Vs|≡Vi|≡Vi↔SKVs(xiii)
B13:RSUj|≡Vs|≡Vs↔SKRSUj(xiv)
B14:Vs|≡RSUj|≡Vi↔SKRSUi(xv)
B15:Vi|≡Vs|≡Vi↔SKRSUj
Next, employing the above assumptions, we further analyze the idealized forms.
Taking the idealized version of M1 and M2:(i)
M1:Vi⟶RSUj:PIDvi,Mi1,Mi2,ti:PIDvi,IDvi,ti,riBvi,ti(ii)
M2:RSUj⟶Vs:IDrj,PIDvi,IDvi,ti,riAvi,riBvi,ti,(iii)
Mj1,tj:IDrj,PIDvi,IDvi,ti,riAvi,riBvi,ti,rj,tjKrj,tj
By applying seeing rule, we get(i)
X1:RSUj⊲PIDvi,Mi1,Mi2,ti:PIDvi,IDvi,ti,riBvi,ti(ii)
X2:Vs⊲IDrj,PIDvi,IDvi,ti,riAvi,riBvi,ti,Mj1,tj:IDrj,PIDvi,IDvi,ti,riAvi,riBvi,ti,rj,tjKrj,tj
According toD1,D2,P8,B9, and R1, we get(i)
X3:Vs|≡Vi∼PIDvi,IDvi,ti,riBvi,ti(ii)
X4:Vs|≡RSUj∼IDrj,PIDvi,IDvi,ti,riAvi,riBvi,ti,rj,tjKrj,tj
Referring toX3,B1,R2, and R4, we get(i)
X5:Vs|≡Vi≡PIDvi,IDvi,ti,riBvi,ti(ii)
X6:Vs|≡RSUj≡IDrj,PIDvi,IDvi,ti,riAvi,riBvi,ti,rj,tjKrj,tj
Referring toX5,B12, and R3,(i)
X7:Vs|≡PIDvi,IDvi,ti,riBvi,ti
In accordance withX6,B14, and R3, we have(i)
X8:Vs|≡IDrj,PIDvi,IDvi,ti,riAvi,riBvi,ti,rj,tjKrj,tj
Referring toX5,X7, and R6, we have(i)
X9:Vs|≡Vi↔SKVs (goal 5)
UsingX5,X7,B8, and R2, we get(i)
X10:Vs|≡Vi|≡Vi↔SKVs (goal 6)
Taking the idealized version ofM3,(i)
M3:Vs⟶RSUj:RSK,VSK,RSV,tvs:SKKrj,SK,PIDvin,BvinAvi,tvsSK,tvs
On the application of seeing rule forM3, we get(i)
X11:Vs|≡Vi∼RSK,VSK,RSV,tvs:SKKrj,SK,PIDvin,BvinAvi,tvsSK,tvs
UsingX11,B7, and R1, we have(i)
X12:RSUj|≡Vs∼SKKrj,SK,PIDvin,BvinAvi,tvsSK,tvs(ii)
RSUj|≡RSUj↔SKVs (goal 1)
According toX12,B3,B13,R2, and R4, we have(i)
X13:RSUj|≡Vs|≡SKKrj,SK,PIDvin,\\BvinAvi,tvsSK,tvs(ii)
RSUi|≡Vs|≡RSUi↔SKVs (goal 2)
Next, consideringM4 idealized form,(i)
M4:RSUs⟶Vi:VSK,VSV,Tjn:SK,PIDvinAvi,tjnSK,tjn
On the application of seeing rule forM4, we have(i)
X14:Vi⊲Vi:VSK,VSV,Tjn:SK,PIDvinAvi,tjnSK,tjn
WhileX14,B4, B5, and R1 imply(i)
X15:Vi|≡RSUj∼SK,PIDvinAvi,tjnSK,tjn
Referring toX15,B2,B3,R2, and R4, we have(i)
X16:Vi|≡RSUj|≡SK,PIDvinAvi,tjnSK,tjn
FromX16,B4,B10,B15, and rule 3, we get(i)
X17:Vi|≡SK,PIDvinAvi,tjnSK,tjn
Referring toX17, we apply R6 as(i)
X18:Vi|≡RSUj↔SKVi (goal 3)
According toX18,B2, we apply the R6 as(i)
X19:Vi|≡RSUj|≡RSUj↔SKVi (goal 3)
The discussed cases for proving the protocol in BAN logic make obvious that the contributed scheme entirely supports mutual authentication and protects the established session key among the three participating members.


## 5. Informal Security Analysis

An informal security discussion on the security features of the proposed scheme is provided in following subsection:


### 5.1. Mutual Authentication

The SMEP-IoV ensures mutual authenticity for all participating entities of the system. In particular, theRSUj authenticates both entities, VS and Vi, by means of equality check comparing RSV against the computed hSK‖tvs parameter. Since, RSUj is aware of the fact, the generated session key SK can only be constructed by a legitimate VS entity having access to master secret key Kvs. Using Kvs, VS can access ri, rj, Avi, and Krj factors to compute a valid SK. Likewise, Vi authenticates RSUj on the basis of VSV equality check, after comparing it with the computed hSK‖tjn. Similarly, Vs authenticates Vi by computing hAvi‖IDvi‖ti‖ri against Mi1. Realizing the fact that Avi is only held with a valid Vi entity, it can validate the vehicle Vi. If these equality checks fail, the mutual authentication cannot be assured in the protocol.


### 5.2. Stolen Verifier Attack

In the proposed scheme, the vehicle server VS stores only public identities (IDvi:i=1,2…n) of all the registered vehicles in its memory. VS does not store any other vehicle-related secret parameter in its own memory, and the verifier is with the vehicle. Therefore, the possibility of stolen verifier attack on proposed SMEP-IoV is negligible.


### 5.3. Vehicle Anonymity

The SMEP-IoV employs a pseudoidentityPIDvi for each vehicle, which is renewed and replaced after the termination of each session. In this manner, the vehicle or user remains anonymous during the execution of the protocol. Moreover, there is no desynchronization possible in case an adversary holds or blocks the message on its way.


### 5.4. VS Impersonation Attack

No adversary A can impersonate as Vs in the SMEP-IoV scheme. This is because, if an adversary attempts the same towardsVi, the latter may discern the possibility of attack by comparing VSV against the computed factor hSK‖tjn. Similarly, if A attempts to impersonate as VS against RSUj, the RSUj may successfully thwart this attack on the basis of comparison of RSV and calculated hSK‖tvs. Hence, the SMEP-IoV is immune to VS impersonation attack.


### 5.5. RSU Impersonation Attack

The SMEP-IoV is immune toRSU impersonation attack. Both entities Vi and VS may easily prevent any attempt of impersonation as RSU on the part of adversary. This is due to the fact that VS shares a secret with RSUj. The use of fresh timestamps along with the shared secrets helps the VS entity in authenticating a legitimate RSU. Similarly, Vi authenticates RSUj on account of the derived session key SK from the VSK message as submitted by a valid VS, which is further used in the later comparison of VSV. In this manner, both of the entities validate a legal RSUj on account of provided logical comparison of equality checks.


### 5.6. Man-in-the-Middle Attack (MiDM)

To launch a successful MiDM attack on SMEP-IoV, the adversary needs access to either theVi registration parameters such as Avi and Bvi or access to secret key Krj or the master secret key Kvs. On the other hand, as we see earlier, it is less likely for an adversary to initiate an impersonation attack on the protocol.


### 5.7. Session Key Security

As we see earlier, no adversary could engage in the mutual authentication process until it gains access to secure credentials of the system either held by the registration authority or registered entities. Since, the SMEP-IoV provides mutual authentication to all participants, the established session key is only known to the legitimate members involved in the protocol execution.


### 5.8. Denial of Service

Our scheme is resistant to denial of service attacks, since it engages fresh timestamps for the generation ofMvi and Mrj1. Due to these timestamps, the receiving entity may check the freshness of the incoming message and discard the message immediately if the latency is beyond a certain preset threshold.


### 5.9. Replay Attack

In case an adversary attempts to initiate a replay attack towards any entityVi, RSUj, or VS, the SMEP-IoV may foil this attempt immediately after checking the freshness of timestamps ti, tj/tjn, and tvs, respectively. Hence our scheme is immune to this threat.


## 5.1. Mutual Authentication

The SMEP-IoV ensures mutual authenticity for all participating entities of the system. In particular, theRSUj authenticates both entities, VS and Vi, by means of equality check comparing RSV against the computed hSK‖tvs parameter. Since, RSUj is aware of the fact, the generated session key SK can only be constructed by a legitimate VS entity having access to master secret key Kvs. Using Kvs, VS can access ri, rj, Avi, and Krj factors to compute a valid SK. Likewise, Vi authenticates RSUj on the basis of VSV equality check, after comparing it with the computed hSK‖tjn. Similarly, Vs authenticates Vi by computing hAvi‖IDvi‖ti‖ri against Mi1. Realizing the fact that Avi is only held with a valid Vi entity, it can validate the vehicle Vi. If these equality checks fail, the mutual authentication cannot be assured in the protocol.


## 5.2. Stolen Verifier Attack

In the proposed scheme, the vehicle server VS stores only public identities (IDvi:i=1,2…n) of all the registered vehicles in its memory. VS does not store any other vehicle-related secret parameter in its own memory, and the verifier is with the vehicle. Therefore, the possibility of stolen verifier attack on proposed SMEP-IoV is negligible.


## 5.3. Vehicle Anonymity

The SMEP-IoV employs a pseudoidentityPIDvi for each vehicle, which is renewed and replaced after the termination of each session. In this manner, the vehicle or user remains anonymous during the execution of the protocol. Moreover, there is no desynchronization possible in case an adversary holds or blocks the message on its way.


## 5.4. VS Impersonation Attack

No adversary A can impersonate as Vs in the SMEP-IoV scheme. This is because, if an adversary attempts the same towardsVi, the latter may discern the possibility of attack by comparing VSV against the computed factor hSK‖tjn. Similarly, if A attempts to impersonate as VS against RSUj, the RSUj may successfully thwart this attack on the basis of comparison of RSV and calculated hSK‖tvs. Hence, the SMEP-IoV is immune to VS impersonation attack.


## 5.5. RSU Impersonation Attack

The SMEP-IoV is immune toRSU impersonation attack. Both entities Vi and VS may easily prevent any attempt of impersonation as RSU on the part of adversary. This is due to the fact that VS shares a secret with RSUj. The use of fresh timestamps along with the shared secrets helps the VS entity in authenticating a legitimate RSU. Similarly, Vi authenticates RSUj on account of the derived session key SK from the VSK message as submitted by a valid VS, which is further used in the later comparison of VSV. In this manner, both of the entities validate a legal RSUj on account of provided logical comparison of equality checks.


## 5.6. Man-in-the-Middle Attack (MiDM)

To launch a successful MiDM attack on SMEP-IoV, the adversary needs access to either theVi registration parameters such as Avi and Bvi or access to secret key Krj or the master secret key Kvs. On the other hand, as we see earlier, it is less likely for an adversary to initiate an impersonation attack on the protocol.


## 5.7. Session Key Security

As we see earlier, no adversary could engage in the mutual authentication process until it gains access to secure credentials of the system either held by the registration authority or registered entities. Since, the SMEP-IoV provides mutual authentication to all participants, the established session key is only known to the legitimate members involved in the protocol execution.


## 5.8. Denial of Service

Our scheme is resistant to denial of service attacks, since it engages fresh timestamps for the generation ofMvi and Mrj1. Due to these timestamps, the receiving entity may check the freshness of the incoming message and discard the message immediately if the latency is beyond a certain preset threshold.


## 5.9. Replay Attack

In case an adversary attempts to initiate a replay attack towards any entityVi, RSUj, or VS, the SMEP-IoV may foil this attempt immediately after checking the freshness of timestamps ti, tj/tjn, and tvs, respectively. Hence our scheme is immune to this threat.


## 6. Performance and Security Comparisons

The performance and security comparisons of the proposed scheme with related existing scheme [22–24] are explained in the following subsections.


### 6.1. Performance Comparisons

For measuring the computation time and cost, Pi3 B+ is used with Cortex A53 (ARMv8) 64 bit SoC and with processing speed 1.4 GHz along with 1 GB LPDDR2 SDRAM RAM. The simulation results of basic operations executed over Pi3 are given in Table2. For completion of authentication and a key agreement (AKA) among a vehicle Vi and RSU RSUj through the intermediate agent VS-Vehicle Server, Vi executes 2Chs and 3Ced operations. Likewise, RSUj performs 2Chs+2Ced operations while VS accomplishes 7Chs and 7Ced operations. Hence, total computational operations performed to complete a cycle of AKA are 11Chs+12Ced. Using the experiment with computational times represented in Table 2, the performance comparisons are briefed in Table 3. The proposed scheme completes single AKA cycle in ≈0.198ms. In contrast to the proposed scheme, the scheme of Yu et al. [23] completes single AKA cycle in ≈0.132ms, the scheme of Vasudev et al. [22] and Mohit et al. [24] complete the one cycle of AKA in ≈0.082ms and ≈0.108ms, respectively.Table 2
Operational Cost of the primitives.
OperationNotationTime (ms)Enc-decryptionCed≈0.011Hash functionChs≈0.006Table 3
Performance comparisons.
↓ protocolsCa.RTCbProposed11Chs+12Ced≈0.1982848Yu et al. [23]22Chs≈0.132864Vasudev et al. [22]10Chs+2Ced≈0.082800Mohit et al. [24]18Chs≈0.1081760Note:Ca, computation cost; RT, running time in ms; Cb, communication cost in bits.For communication cost comparisons, subsequent consideration is taken as per the sizes of different parameters. Timestamps and identity are taken as 32 and 64 bits, respectively; whereas, the sizes of the outputs of the symmetric key and asymmetric key operations are taken as 128 and 1024 bits. The value of hash output is fixed at 160 bits. Moreover, the size of random numbers is also assumed as 160 bit of length. The communication cost of SMEP-IoV and related schemes of Yu et al. [23], Vasudev et al. [22], and Mohit et al. [24] is computed as the bits exchanged among the IoV entities. The Vi sends Mvi=PIDvi,Mi1,Mi2,ti to RSUj, where the size of Mvi is 128+160+160+32=480. Subsequently, the RSUj sends Mrj1=IDrj,Mvi,Mj1,tj, where the size of Mrj is 64+480+128+32=704. The VS replies RSUj with Mvs=RSK,VSK,RSV,tvs, where the size of Mvs is 256+512+160+32=960. The final message Mrj2=VSK,VSV,tjn was sent from RSUj to Vi, where the size of Mrj2 is 512+160+32=704. Therefore, total communication cost is 2848 bits. The communication cost of Yu et al.’s scheme is 864, while the communication costs of Vasudev et al. and Mohit et al. are 800 and 1760, respectively.


### 6.2. Security Features

The security comparisons of the SMEP-IoV and related existing schemes [22–24] are provided in this subsection. Table 4 solicits the summary of the security comparisons. Due to disclosure of master secret key KVS, the Yu et al.’ scheme [23] is vulnerable to many attacks including impersonation of vehicle, RSU, and vehicle server, along with session key disclosure and vehicle/user anonymity violations attack. The scheme of Vasudev et al. [22] lacks mutual authentication and has insecurities against vehicle, RSU, and vehicle server impersonation attacks. Moreover, Vasudev et al.’s scheme is insecure against man-in-the-middle attack. The scheme of Mohit et al. [24] is also weak against man in middle attack. In contrast, proposed SMEP-IoV provides all security features and is robust against the known attacks.Table 4
Security features.
SchemesOur[23][22][24]Mutual authentication✓✗✗✓Stolen verifier✓✓✓✓Vehicle anonymity✓✗✓✓VS impersonation✓✗✗✓RSU impersonation✓✗✗✓Vehicle impersonation✓✗✗✓Man in middle attack✓✗✗✗Session key security✓✗✗✓Denial of service✓✓✓✓Replay attack✓✓✓✓Note: ✓, provides or resists; ✗,does not provide or does not resist.


## 6.1. Performance Comparisons

For measuring the computation time and cost, Pi3 B+ is used with Cortex A53 (ARMv8) 64 bit SoC and with processing speed 1.4 GHz along with 1 GB LPDDR2 SDRAM RAM. The simulation results of basic operations executed over Pi3 are given in Table2. For completion of authentication and a key agreement (AKA) among a vehicle Vi and RSU RSUj through the intermediate agent VS-Vehicle Server, Vi executes 2Chs and 3Ced operations. Likewise, RSUj performs 2Chs+2Ced operations while VS accomplishes 7Chs and 7Ced operations. Hence, total computational operations performed to complete a cycle of AKA are 11Chs+12Ced. Using the experiment with computational times represented in Table 2, the performance comparisons are briefed in Table 3. The proposed scheme completes single AKA cycle in ≈0.198ms. In contrast to the proposed scheme, the scheme of Yu et al. [23] completes single AKA cycle in ≈0.132ms, the scheme of Vasudev et al. [22] and Mohit et al. [24] complete the one cycle of AKA in ≈0.082ms and ≈0.108ms, respectively.Table 2
Operational Cost of the primitives.
OperationNotationTime (ms)Enc-decryptionCed≈0.011Hash functionChs≈0.006Table 3
Performance comparisons.
↓ protocolsCa.RTCbProposed11Chs+12Ced≈0.1982848Yu et al. [23]22Chs≈0.132864Vasudev et al. [22]10Chs+2Ced≈0.082800Mohit et al. [24]18Chs≈0.1081760Note:Ca, computation cost; RT, running time in ms; Cb, communication cost in bits.For communication cost comparisons, subsequent consideration is taken as per the sizes of different parameters. Timestamps and identity are taken as 32 and 64 bits, respectively; whereas, the sizes of the outputs of the symmetric key and asymmetric key operations are taken as 128 and 1024 bits. The value of hash output is fixed at 160 bits. Moreover, the size of random numbers is also assumed as 160 bit of length. The communication cost of SMEP-IoV and related schemes of Yu et al. [23], Vasudev et al. [22], and Mohit et al. [24] is computed as the bits exchanged among the IoV entities. The Vi sends Mvi=PIDvi,Mi1,Mi2,ti to RSUj, where the size of Mvi is 128+160+160+32=480. Subsequently, the RSUj sends Mrj1=IDrj,Mvi,Mj1,tj, where the size of Mrj is 64+480+128+32=704. The VS replies RSUj with Mvs=RSK,VSK,RSV,tvs, where the size of Mvs is 256+512+160+32=960. The final message Mrj2=VSK,VSV,tjn was sent from RSUj to Vi, where the size of Mrj2 is 512+160+32=704. Therefore, total communication cost is 2848 bits. The communication cost of Yu et al.’s scheme is 864, while the communication costs of Vasudev et al. and Mohit et al. are 800 and 1760, respectively.


## 6.2. Security Features

The security comparisons of the SMEP-IoV and related existing schemes [22–24] are provided in this subsection. Table 4 solicits the summary of the security comparisons. Due to disclosure of master secret key KVS, the Yu et al.’ scheme [23] is vulnerable to many attacks including impersonation of vehicle, RSU, and vehicle server, along with session key disclosure and vehicle/user anonymity violations attack. The scheme of Vasudev et al. [22] lacks mutual authentication and has insecurities against vehicle, RSU, and vehicle server impersonation attacks. Moreover, Vasudev et al.’s scheme is insecure against man-in-the-middle attack. The scheme of Mohit et al. [24] is also weak against man in middle attack. In contrast, proposed SMEP-IoV provides all security features and is robust against the known attacks.Table 4
Security features.
SchemesOur[23][22][24]Mutual authentication✓✗✗✓Stolen verifier✓✓✓✓Vehicle anonymity✓✗✓✓VS impersonation✓✗✗✓RSU impersonation✓✗✗✓Vehicle impersonation✓✗✗✓Man in middle attack✓✗✗✗Session key security✓✗✗✓Denial of service✓✓✓✓Replay attack✓✓✓✓Note: ✓, provides or resists; ✗,does not provide or does not resist.


## 7. Conclusion

Initially, this study reviewed some of the recent authentication schemes for securing IoVs. Then, we developed a symmetric key-based authentication scheme, through which a vehicle can share a secret key with corresponding RSU through the mediation of the vehicle server. The proposed secure message exchange protocol for IoV (SMEP-IoV) uses only lightweight symmetric encryption and hash functions. The comparisons of the SMEP-IoV show that proposed scheme compromises slight performance overhead and provides adequate security, which other competing schemes do not provide. Hence, due to performance and security provisions, SMEP-IoV best suits the security requirements of the fast moving vehicles in the IoV scenario.



---

*Source: 5554318-2021-05-19.xml*