# Secure Message Transmission for V2V Based on Mutual Authentication for VANETs

Authors: Jabar Mahmood; Zongtao Duan; Heng Xue; Yun Yang; Michael Abebe Berwo; Sajjad Ahmad Khan; Abd al Kader Ahmed Yassin
Journal: Wireless Communications and Mobile Computing
 (2021)

---

## Abstract

The advancements in Vehicular Ad Hoc Networks (VANETs) require more intelligent security protocols that ultimately provide unbreakable security to vehicles and other components of VANETs. VANETs face various types of security pitfalls due to the openness characteristics of the VANET communication infrastructure. Researchers have recently proposed different mutual authentication schemes that address security and privacy issues in vehicle-to-vehicle (V2V) communication. However, some V2V security schemes suffer from inadequate design and are hard to implement practically. In addition, some schemes face vehicle traceability and lack anonymity. Hence, this paper’s primary goal is to enhance privacy preservation through mutual authentication and to achieve better security and performance. Therefore, this article first describes the vulnerabilities of a very recent authentication scheme presented by Vasudev et al. Our analysis proves that the design of Vasudev et al.’s scheme is incorrect, and resultantly, the scheme does not provide mutual authentication between a vehicle and vehicle server when multiple vehicles are registered with the vehicle sever. Furthermore, this paper proposes a secure message transmission scheme for V2V in VANETs. The proposed scheme fulfills the security and performance requirements of VANETs. The security analysis of the proposed scheme using formal BAN and informal discussion on security features confirm that the proposed scheme fulfills the security requirements, and the performance comparisons show that the proposed scheme copes with the lightweightness requirements of VANETs.


---

## Body

## 1. Introduction

Recently, the use of transportation has increased in every aspect of our lives. Vehicles are used not only for traveling but also in various smart city applications (such as traffic lights, cameras, and street lights) [1]. Urban transportation faces various challenges such as traffic issues, parking challenges, poor connectivity, inefficient road safety, and traffic jamming [2]. Intelligent Transportation System (ITS) [3, 4] provides solutions to previously mentioned challenges in urban transportation [5].Vehicular Ad Hoc Networks (VANETs) [6–9] play a vital role in the urban transportation system; they help to improve road safety and traffic management. VANETs communicate with various elements such as vehicles, Roadside Units (RSUs) [10–12], Onboard Wireless Units (OBUs), internet/network, and vehicle servers/vehicle authentication servers. Based on these elements, communication is divided into two categories, V2V and Vehicle to RSUs (V2R/V2I). V2V communicate through the Dedicated Short-Range Communication (DSRC) protocol [13], which is included in IEEE 802.11p [14, 15]. Figure 1 shows the VANET architecture.Figure 1
Structure of VANETs.The OBU is fixed inside the vehicle and integrated with a Global Positioning System (GPS), ITS-G5 IEEE 802.11p protocol, and various sensors [13]. The OBU function stores information such as vehicle location, speed, and traffic flow on the road during driving and permits disseminating the information to RSUs or other vehicles on the road. The RSUs are fixed on the road edges; RSUs collect all information from the vehicles/OBUs, save it, forward it to vehicles, and connect other RSUs for the network’s security. That information is passed through a reliable communication channel from RSUs to OBUs and RSUs to RSUs. A vehicle server or vehicle authentication server ensures that all vehicles are trusted in-network and checks the vehicle ID and password when entering the network. If the vehicle fails to prove identity, an alert message is sent in the network through RSUs about a fake vehicle. Figure 2 provides complete details about V2V communication in VANETs. Usually, vehicles communicate with other vehicles, share information/data about the vehicle’s current position, and share the keys. These data are confidential and sent through a secure communication channel with trusted vehicles part of the network. If confidential information is available, the adversary can use it in a way that is dangerous to vehicles and humans. In such a case, the adversary/attacker quickly gets a transmitted message and uses its advantages, such as altering the message and changing it according to its benefits or delaying the transmitted message making it unavailable to the original vehicle or devices within a specific time limit [16].Figure 2
Typical structure of V2V communication.


### 1.1. Motivation and Contributions

We observed that VANETs face various threats during communication, such as internal and external threats, as discussed previously. Every attacker hits the data packets, aiming to disturb the network and use its benefits. Due to these situations, we need a suitable protocol that provides strong user authentication and secures the data packet from attackers in V2V. This paper is aimed at analyzing the recent scheme, “A Lightweight Mutual Authentication Protocol V2V Communication on Internet of Vehicles,” proposed by Vasudev et al. to present vital design faults. Specifically, LAMP-V2VCIoV cannot work when more than one registered vehicles are in the system. The working of LAMP-V2VCIoV can only be apprehended when there is only one vehicle registered. Moreover, this paper introduces a mutual authentication protocol for V2V communication in the VANETs (MAP-V2VCV). MAP-V2VCV is designed vigilantly to prevent any such incorrectness and provide an enhanced and secure message exchange.The structure of the paper is organized as follows. The system model of the proposed scheme is presented in Section2. The related works that have been done in recent years are presented in Section 3. In Section 4, we review Vasudev et al.’s authentication scheme. Section 5 points out the weakness of existing security scheme vulnerabilities. We propose a new and improved scheme in Section 6, while Section 7 describes the security analysis of the new scheme. Section 8 presents the security and performance analysis. At last, in Section 9, we provide the conclusion of the paper.


## 1.1. Motivation and Contributions

We observed that VANETs face various threats during communication, such as internal and external threats, as discussed previously. Every attacker hits the data packets, aiming to disturb the network and use its benefits. Due to these situations, we need a suitable protocol that provides strong user authentication and secures the data packet from attackers in V2V. This paper is aimed at analyzing the recent scheme, “A Lightweight Mutual Authentication Protocol V2V Communication on Internet of Vehicles,” proposed by Vasudev et al. to present vital design faults. Specifically, LAMP-V2VCIoV cannot work when more than one registered vehicles are in the system. The working of LAMP-V2VCIoV can only be apprehended when there is only one vehicle registered. Moreover, this paper introduces a mutual authentication protocol for V2V communication in the VANETs (MAP-V2VCV). MAP-V2VCV is designed vigilantly to prevent any such incorrectness and provide an enhanced and secure message exchange.The structure of the paper is organized as follows. The system model of the proposed scheme is presented in Section2. The related works that have been done in recent years are presented in Section 3. In Section 4, we review Vasudev et al.’s authentication scheme. Section 5 points out the weakness of existing security scheme vulnerabilities. We propose a new and improved scheme in Section 6, while Section 7 describes the security analysis of the new scheme. Section 8 presents the security and performance analysis. At last, in Section 9, we provide the conclusion of the paper.


## 2. System Models

This section presents the network and attack models and describes the working of both models on the contributed scheme.


### 2.1. Network Model

The network model is based on five entities, the vehicle/OBU, the RSU, registration authority (RA), trusted authority (TA), and vehicle server (VS); as shown in Figure 3, we describe each entity in detail.Figure 3
Network model of VANETs.The vehicle/OBU: an OBU installed inside each vehicle that receives messages from other vehicles/RSU/sensor verifies these messages and transmits them to other vehicles through the DSRC protocol. The secret information related to the message is kept secret in a tamper-proof device (TPD) inside the OBU. Every OBU in VANETs has a clock synchronized with the RSU communication range, also equipped with GPS and GUI interface that provide services such as the vehicle’s location, the interaction of drivers to each other, and traffic information. Its computational power and storage capacity are more petite than RSU.The RSU: the RSU is fixed on roadsides that acts as an intermediate entity between vehicles, RA, TA, and VS. The RSU is responsible for sharing traffic congestion, speed limits, and any threat information on the road. The RSU receives messages from the vehicle or RSUs, authenticates these messages, and then broadcasts these messages to other entities such as VS, via the secure communication channel.Registration authority: in VANETs, RA is a trusted point to perform the registration procedure of every vehicle; this process is mandatory for each vehicle before moving to the communication phase. Generally, at the time of manufacture, the manufacturing company does this process; during the registration phase, vehicle users select required credentials, generate a key, and send some other information to RA for the registration. In the end, RAinstalls the OBU with the necessary parameters into the vehicle.Trusted authority: TA is responsible for an authentication process that makes sure that the vehicle is trusted or authenticated and already registered with RA. TA first registers RSU and after that the vehicle and then generates anonymous identities to secure the privacy of the vehicle. TA also has the authority to identify the misbehaved vehicle’s original identity and block it in the VANET network and inform other vehicles about that vehicle.Vehicle server: the VS stores real-time information if any vehicle is requested to VS for the information that VS provides. When the vehicle wants that information, it first needs to register itself with theTA. If TA ensures the given vehicle is trusted, then credentials are sent toVS; after receiving this information from the trusted authority, theVSverifies that information again, and to ensure such information fromTA,VSsend some messages toTA; the purpose of this process is only for authenticity. AfterTAandVS, communication starts.


### 2.2. Attack Model

We choose the well-known Dolev-Yao threat model [17] for the security analysis of the proposed model. The Dolev-Yao threat model assumes and ensures a public channel for communication between vehicle to vehicle. A variety of proposals have been employed [18–21]; important points regarding the adopted attack model are given as follows:
(1)
The attacker (E) properly controls the public channel. E is considered competent enough to listen, modify, delete, or jam any transmitted message between entities such as Vi, TA, and VS(2)
E can extract and analyze the parameter stored in a stolen smart card or capture the card’s memory(3)
The vehicle and other entity are not trusted, which means any communicating authority or entity can try to impersonate on behalf of the other(4)
All parameters such as identities and the public keys of all the entities, includingTA, are easily accessible to other systems and unauthorized users(5)
Private key (PK) of the participating entities, including TA, are secure and safe; no E is powerful enough to reveal the PK of any system entity


## 2.1. Network Model

The network model is based on five entities, the vehicle/OBU, the RSU, registration authority (RA), trusted authority (TA), and vehicle server (VS); as shown in Figure 3, we describe each entity in detail.Figure 3
Network model of VANETs.The vehicle/OBU: an OBU installed inside each vehicle that receives messages from other vehicles/RSU/sensor verifies these messages and transmits them to other vehicles through the DSRC protocol. The secret information related to the message is kept secret in a tamper-proof device (TPD) inside the OBU. Every OBU in VANETs has a clock synchronized with the RSU communication range, also equipped with GPS and GUI interface that provide services such as the vehicle’s location, the interaction of drivers to each other, and traffic information. Its computational power and storage capacity are more petite than RSU.The RSU: the RSU is fixed on roadsides that acts as an intermediate entity between vehicles, RA, TA, and VS. The RSU is responsible for sharing traffic congestion, speed limits, and any threat information on the road. The RSU receives messages from the vehicle or RSUs, authenticates these messages, and then broadcasts these messages to other entities such as VS, via the secure communication channel.Registration authority: in VANETs, RA is a trusted point to perform the registration procedure of every vehicle; this process is mandatory for each vehicle before moving to the communication phase. Generally, at the time of manufacture, the manufacturing company does this process; during the registration phase, vehicle users select required credentials, generate a key, and send some other information to RA for the registration. In the end, RAinstalls the OBU with the necessary parameters into the vehicle.Trusted authority: TA is responsible for an authentication process that makes sure that the vehicle is trusted or authenticated and already registered with RA. TA first registers RSU and after that the vehicle and then generates anonymous identities to secure the privacy of the vehicle. TA also has the authority to identify the misbehaved vehicle’s original identity and block it in the VANET network and inform other vehicles about that vehicle.Vehicle server: the VS stores real-time information if any vehicle is requested to VS for the information that VS provides. When the vehicle wants that information, it first needs to register itself with theTA. If TA ensures the given vehicle is trusted, then credentials are sent toVS; after receiving this information from the trusted authority, theVSverifies that information again, and to ensure such information fromTA,VSsend some messages toTA; the purpose of this process is only for authenticity. AfterTAandVS, communication starts.


## 2.2. Attack Model

We choose the well-known Dolev-Yao threat model [17] for the security analysis of the proposed model. The Dolev-Yao threat model assumes and ensures a public channel for communication between vehicle to vehicle. A variety of proposals have been employed [18–21]; important points regarding the adopted attack model are given as follows:
(1)
The attacker (E) properly controls the public channel. E is considered competent enough to listen, modify, delete, or jam any transmitted message between entities such as Vi, TA, and VS(2)
E can extract and analyze the parameter stored in a stolen smart card or capture the card’s memory(3)
The vehicle and other entity are not trusted, which means any communicating authority or entity can try to impersonate on behalf of the other(4)
All parameters such as identities and the public keys of all the entities, includingTA, are easily accessible to other systems and unauthorized users(5)
Private key (PK) of the participating entities, including TA, are secure and safe; no E is powerful enough to reveal the PK of any system entity


## 3. Related Work

The nature of VANETs is dynamic due to the Wireless Medium (WM) because of data transmission through WM to V2V, RSUs2V. Therefore, the chances of an attack are possible in the network every time. When attackers attack in the network during data transmission, stop, or delays, the original message can be tampered or discarded during this period [22]. A tampered or wrong message in VANETs becomes the reason for accidents or jamming of traffic. Xu et al. [22] proposed a security scheme to reduce the computation and storage cost and provide authentication to dense environments where vehicles receive multiple messages simultaneously, as well as to resist against the various attacks such as impersonation, modification, and replay attacks; however, the security analysis is not provided against remaining internal and external assaults [22].VANET message transmissions from V2V or V2RSUs have many security threats. Vijayakumar et al. [23] proposed a dual authentication (DA) scheme that provides a high level of security to the vehicle inside the network and does not allow the entrance of any unauthorized vehicle in VANETS. It also provides a dual key management (DKM) security scheme for the user when joining or leaving which must be updated in the group. Nevertheless, the privacy of the vehicle’s location is not provided in this scheme.VANETs face various challenges due to dynamic topological conditions owing to speedily moving vehicles. Transmission of messages is in a limited area in VANETs, but security threats exist. Check of the authenticity of the message origin to the receiver in this environment is a big challenge. Chuang and Lee proposed a V2V communication security scheme called trust-extended authentication mechanism (TEAM) [24]. During analysis, Kumari et al. [25] find that TEAM is vulnerable to inside attacks, privacy breaches, impersonation attacks, and other challenges. Kumari et al. [25] proposed an enhanced trust extended authentication (ETEA) scheme for VANETs. ETEA proves that the analysis is better than TEAM and protects it from inside attacks. Also, computation load was reduced as compared to TEAM. Nevertheless, computational and storage cost is not discussed.Various security protocols have been proposed for road safety applications in vehicle-to-everything (V2X) communication. These security protocols did not meet the lightweight (LW) preliminary requirements and fast processing integral parts of V2X; Hakeem et al. [26] proposed an LW authentication protocol for the privacy and protection of V2X. The protocol integrates with two hardware devices, biometrics devices and temper proof devices installed inside the vehicle. The proposed protocol is responsible for providing driver identity and private key security management. Decentralized certificateless authority generates a pseudoidentity of the driver, private key, secure privacy, and authentication V2V communication. They have also proposed an authentication signature protocol using the notation hash function. In [26], the scheme satisfies the security requirements and also reduces the message communication cost and computation time. Protection is provided against DoS, man-in-the-middle, modification, and replay assaults. However, storage cost was missing.Chaudhry [27] states that the Internet of Vehicles (IoV) has become an integral part of our lives due to technological enhancement. Information is relevant to vehicles, including the position of the vehicle, information on the road, and the vehicle speed. This information is vital for selecting routes; without security, disseminating information between IoV entities is impossible. Many researchers proposed authentication schemes, but most security schemes did not perform as per claimed or communication cost or computation cost is very high. The authors in [27] proposed a secure message authentication protocol (SMEP-IoV); this protocol uses the symmetric lightweight hash function and encryption operation and provides a lightweight authentication process in 0.198 ms. SMEP-IoV resists various attacks such as stolen verifier, denial of service, replay, RSU impersonation, mutual authentication, and session key security. However, storage cost of the proposed is missing in their paper.Recently, data transmission and protection of the user from various security attacks, the user authentication protocol plays an integral role in ensuring security. Wang et al. [28] discovered two authentication security schemes that are not fully claimed and fail to provide secure communication, such as password guessing, session key disclosure, impersonation assaults, and user anonymity. In [28] eliminated the security threats from the existing scheme. The proposed improved authentication scheme based on the elliptic curve cryptosystem, performing analysis, proves that security scheme in [28] was better than existing schemes in terms of security, computation cost, and communication cost. However, storage cost was missing; also DoS and Sybil assaults were missing in the formal analysis.In VANET, secure communication among neighbors, authentication, and trust establishment is an essential requirement of VANET. Many researchers proposed cryptography schemes that are claimed to overcome the inside assaults. However, they do not perform as per expectations. To reduce the inside attacks, researcher proposed a trust management scheme. Tangade and Manvi [29] proposed a neighbor trust management scheme (NTMS) for secure communication in VANET. NTMS employs an ID-based signature and HMAC [30]. NTMS provides various types of security during communication detection of malicious vehicles, the integrity of the message, and the level of trust among communication vehicles. However, formal security analysis was not provided, and also, computation cost and communication cost were missing.Currently, the advancement of technologies has become a digital world, sharing information is not an issue. Hence, information must be secured; otherwise, the attacker may attack the information and use it for their own benefits and purposes. VANETs have become a more popular industry because vehicles share information among other vehicles speedily on the road. Limbasiya and Das [16] proposed a secure message exchange protocol using a public private key encryption and decryption approach in the computation of messages. In [16], the algorithm fulfills all security requirements on confidentiality, authenticity, and availability. This protocol also sends the current position of the vehicle to other vehicles within the network area. However, neither is formal security analysis provided nor are computation and communication costs discussed.Vehicular sensor networks (VSNs) play a vital role in ITS and provide good driving experience, due to characteristics of VANETs facing different security threats. Researchers have proposed various authentication security schemes inappropriate to VSN applications due to high communication costs and high computation. Zhou et al. [30] improved the Chuang and Lee security scheme and eliminated the weakness of TEAM [24]. In [30], analysis was performed through the random oracle model and proved that this scheme was better than TEAM. Wu et al. [31] prove that Zhou et al. fail to provide identity guessing, impersonation assaults, and user anonymity and do not discuss DoS and Sybil attacks. Also, storage cost was missing.For the last two decades, the mobile auto industry has been booming due to ITS, particularly the development of VANETs. It provides safety to the driver and passenger and a good experience. In VANETs, the mobility of vehicles is fast; due to this reason, privacy and security were a significant threat. Researchers have proposed an identity-based security scheme to overcome this issue but failed to provide the claimed solution. Wu et al. [31] improved Zhou et al.’s [30] scheme that failed to prove identity guessing and impersonation attack using elliptic curve encryption technology. Wu et al. [31] have proposed a new security scheme, V2V secure communication. However, computation cost and storage cost are missing. Table 1 provides the bird’s eye view of the previous related works such as cryptography techniques, and their advantages and disadvantages/weaknesses are listed.Table 1
Summary of previous authentication schemes.
PaperCryptography techniqueAdvantageDisadvantageXu et al. [22]One-way hash function h(.) XOR (MD5)Achieve lightweight certification; reduce storage and computation cost; less storage space; resist against impersonation, modification, and replay assaultsDoes not resist reaming internal and external assaults such as DoS and man-in-the-middle, respectivelyVijayakumar et al. [23]Hash codeFinger printProvide security to the vehicle and preventing unauthorized users, DKM for the user; unauthorized user does not enter the network; resist against replay, masquerading, Sybil, and message alteration assaultsDoes not protect the vehicle location privacyKumari et al. [25]One-way hash functionXOR operationFast authentication process; low computational load; protect against impersonation, stolen verifier, modification, replay, and insider assaultsComputation cost and storage costs are missingHakeem et al. [26]Hash chain key generationElliptic curveEnhances security level to protect anonymous identities;20%~85% communication overhead is compared to previous protocols; reduces the message communication cost and computation time; protects DoS, man-in-the-middle, modification, and replay assaultsStorage cost is missingChaudhry [27]Symmetric lightweight hash functions and encryptionProvides sufficient security; provide SEMP-IoV best security requirement of the fast mobility vehicle IoV scenario; protects stolen verifier, denial of services, replay, RSU impersonation, mutual authentication, and session key security; authentication process takes 0.198 msStorage cost is missingWang et al. [28]Elliptic curve cryptosystemProtects session key exposure, forward scary assaults; low computation costStorage cost is missing; DoS and Sybil assaults were missing in formal analysisTangade and Manvi [29]ID-based signaturesHMAC techniquesDetection of malicious nodes; the integrity of the message is maintained; the proposed protocol fulfills the security requirements such as confidentiality, authenticity, and availabilityDoes not provide formal security analysis and lacks explanation of computation and communication costsLimbasiya and Das [16]One-way hash functionsBitwise XOR operationLow-cost cryptographic functionsProtects various assaults such as modification assault, man-in-the-middle assault, impersonation assault, concatenation, replay assault, stolen OBU, and password guessing assaultFormal security analysis is missing; computation cost and communication costs are missingZhou et al. [30]Elliptic curve discrete logarithm problemResists internal assaults; low computation cost; secures the identity of driver and location privacy, and only authentication users get itStorage cost is missing; does not discuss DoS and Sybil attacksWu et al. [31]Hash functionsXOR operationElliptic curve encryptionImproves weaknesses of Zhou et al.’s security scheme such as guessing assaults and impersonation assaultsComputation and storages cost are missing


## 4. Summary of Vasudev et al.’s Authentication Scheme

This section provides a brief review of the scheme of Vasudev et al. [2]. The scheme is divided into four phases, and four entities are involved in these phases. First of all, we explain the entities and then the phases. The first entity vehicle Vi acts as a vehicle/user or node that wants to communicate with other vehicles or RSUs. Secondly, the registration authority RA is responsible for registering all vehicles; without RA registration, the vehicle cannot participate in VANET communication. The third entity is the trusted authority (TA), responsible for authentication between vehicle to vehicle and vehicle to a server. The fourth entity is the vehicle server (VS) that stores information about the network, such as vehicle position, weather condition, and congestion control. These four entities performed activity in four phases such as (1) registration, (2) login, (3) authentication, and (4) communication phases. For better understanding, the notations are given in Table 2.Table 2
Notation guide.
Notation symbolsDetail of notationsVS,DiVehicle server, vehicle/hostVIDiIdentification number of theith vehiclePWiThe password ofith vehicleRA,TARegistration authority, trusted authorityCIDThe identification number ofTASIDkThe identification number ofkthVSYiRandom number (RN) generate vehicleKsSecret key shared betweenVS and TANuiNonce produced byVIDiNskNonce produced bySIDkNsNonce produced byVSYtaRandom number produced byRATu,Tc,TsTimestamp ofVi,TA,VSEVIDiPseudo identity of vehicleEksEncryption usingKsDksDecryption usingKsh.One-way cryptography hash function⊕XOR operation‖Concatenation operation


### 4.1. Vehicle Registration

The vehicle driver/host(Di) selects a vehicle ID and password IDi,PWi with random nonce Yi. The Vi computes a cloaked ID and password such as DVIDi=hVIDiYi, DPWi=hhPWiYi and sends to the registration authority through a secure channel. A secure channel means that the channel must ensure the integrity and confidentiality of information transferred via the channel. A secure channel is created using various cryptography security protocols such as SSH or TLS, or data or information is shared with the trusted user.After receiving the data from a vehicle,RA calculates two parameters a1 and b1, which are unique for every vehicle or user. The value of a1 is calculated such as a1=hDVIDiKs, Ks is a private key that is shared by TA, and b1=a1⊕hDVIDiDPWi. The registration authority stores a1 and b1 parameters in SC and forwards to TA immediately. After receiving SC, it is sent to the driver/user via a secure channel.After receiving theSC, Diagain computes the parameter Ci such as Ci=VIDi⊕PWi⊕Yi. Then, Di stores the Ci and SC parameters for future communication.


### 4.2. Vasudev et al.’s Login, Authentication, and Communication

When a vehicle/user is registered successfully atRA, it must be logged in and authenticate itself with a trusted authority if Di gets some information from the vehicle server. The purpose of authentication is to ensure Di validity and protect impersonation assault from third-party vehicles or devices. The authentication process is also mandatory to verify that VS is not impersonated and that the vehicle gets accurate information. For normal execution of this phase, Figure 4 explains the process of login, authentication, and communication. The processes are described as follows.Figure 4
Vasudev et al.’s scheme.


#### 4.2.1. Step VA1:Vi⟶TA:MSG1,X1,Tu,SID

Two parameters are required for login. The first one is the vehicle’s identification number, and the second one is the password. It is not possible to login without these parameters. The vehicle computes the value ofb1, which is received from RA to cross-verify VIDi and PWi. The vehicles (Vi) produce a nonce Nu and current timestamp Tu. Next, the vehicle computes three parameters such as MSG1, Z1, and X1 for the communication with TA, MSG1=ha1TuDPWiNu, Z1=hb1DPWi, and X1=Nu⊕Z1, which are used for authentication of Di. After that, the (MSG1,X1,Tu,SID) are sent to TA through an insecure channel.


#### 4.2.2. Step VA2:TA⟶VS:MSG2,X2,Tc,DCID

WhenTA receives a message from the vehicle, the (MSG1,X1,Tu,SID) calculates the Z1 and X1 such as Z1∗=hb1DPWi and Nu∗=X1⊕Z1. Also, it computes MSG1=?ha1TuDPWiNu∗ to verify the same message which is received through an insecure channel from the vehicle. After calculation, the received information also ensures the integrity of the received message. The TA calculates DCID such as DCID=hDVIDiCIDSID. After that, it computes MSG2 and X2 as MSG2=hDCIDKsTcNu and X2=Nu⊕hKs, respectively. Tc represents the timestamp that generated TAat the time when the message was computed. Finally, the (MSG2,X2,Tc,DCID) is sent to the vehicle sever.


#### 4.2.3. Step VA3:VS⟶TA:MSG3,X3,Ts

After receiving the information fromTA, (MSG2,X2,Tc,DCID) calculates the information to verify whether it is correct or not, such asNu∗=X2⊕hKs,MSG2=?hDCIDKsTcNu∗. The VS produces random nonce Ns and timestamp Ts. The VS also generates secret key Sk, Sk=hDCIDNsNu, that is shared with the vehicle for future communication. The VS also computes X3=hNuNsTsKs and MSG3=Ns⊕Nu; these parameters are (MSG3,X3,Ts) sent back to TA.


#### 4.2.4. Step VA4:TA⟶Vi:X4,W

At this phase, the trusted authority calculates theMSG3 and X3 as Ns∗=MSG3⊕Nu, X3=?hNuNs∗TsKs. After verification of information, TA computes W=Ns⊕DPWi, X4=hNuNsDPWi and sends (X4,w) to the vehicle/user. The vehicle computes W and X4 such as Ns∗=W⊕DWPi, X4=?hNuNs∗DPWi; after that, the secret key Sk=hDCIDNsNu is calculated.


#### 4.2.5. Step VA5: Communication

The secret keySk is used for V2V communication in the future. The vehicle server stores the vehicle/host identity and key after this communication. If vehicle A wants to communicate with other vehicles or devices, the message is encrypted with the help of a key and sent. After receiving a message from vehicle A, vehicle B sends it to VS to check the identity of vehicle A. The VS checks the legitimacy of vehicle B and vehicle A. If VS ensures that both are authorized vehicles, then the keys are sent to vehicle A and vehicle B through a secure channel. Then, vehicle B decrypts the request using this key that is received from VS.


## 4.1. Vehicle Registration

The vehicle driver/host(Di) selects a vehicle ID and password IDi,PWi with random nonce Yi. The Vi computes a cloaked ID and password such as DVIDi=hVIDiYi, DPWi=hhPWiYi and sends to the registration authority through a secure channel. A secure channel means that the channel must ensure the integrity and confidentiality of information transferred via the channel. A secure channel is created using various cryptography security protocols such as SSH or TLS, or data or information is shared with the trusted user.After receiving the data from a vehicle,RA calculates two parameters a1 and b1, which are unique for every vehicle or user. The value of a1 is calculated such as a1=hDVIDiKs, Ks is a private key that is shared by TA, and b1=a1⊕hDVIDiDPWi. The registration authority stores a1 and b1 parameters in SC and forwards to TA immediately. After receiving SC, it is sent to the driver/user via a secure channel.After receiving theSC, Diagain computes the parameter Ci such as Ci=VIDi⊕PWi⊕Yi. Then, Di stores the Ci and SC parameters for future communication.


## 4.2. Vasudev et al.’s Login, Authentication, and Communication

When a vehicle/user is registered successfully atRA, it must be logged in and authenticate itself with a trusted authority if Di gets some information from the vehicle server. The purpose of authentication is to ensure Di validity and protect impersonation assault from third-party vehicles or devices. The authentication process is also mandatory to verify that VS is not impersonated and that the vehicle gets accurate information. For normal execution of this phase, Figure 4 explains the process of login, authentication, and communication. The processes are described as follows.Figure 4
Vasudev et al.’s scheme.


### 4.2.1. Step VA1:Vi⟶TA:MSG1,X1,Tu,SID

Two parameters are required for login. The first one is the vehicle’s identification number, and the second one is the password. It is not possible to login without these parameters. The vehicle computes the value ofb1, which is received from RA to cross-verify VIDi and PWi. The vehicles (Vi) produce a nonce Nu and current timestamp Tu. Next, the vehicle computes three parameters such as MSG1, Z1, and X1 for the communication with TA, MSG1=ha1TuDPWiNu, Z1=hb1DPWi, and X1=Nu⊕Z1, which are used for authentication of Di. After that, the (MSG1,X1,Tu,SID) are sent to TA through an insecure channel.


### 4.2.2. Step VA2:TA⟶VS:MSG2,X2,Tc,DCID

WhenTA receives a message from the vehicle, the (MSG1,X1,Tu,SID) calculates the Z1 and X1 such as Z1∗=hb1DPWi and Nu∗=X1⊕Z1. Also, it computes MSG1=?ha1TuDPWiNu∗ to verify the same message which is received through an insecure channel from the vehicle. After calculation, the received information also ensures the integrity of the received message. The TA calculates DCID such as DCID=hDVIDiCIDSID. After that, it computes MSG2 and X2 as MSG2=hDCIDKsTcNu and X2=Nu⊕hKs, respectively. Tc represents the timestamp that generated TAat the time when the message was computed. Finally, the (MSG2,X2,Tc,DCID) is sent to the vehicle sever.


### 4.2.3. Step VA3:VS⟶TA:MSG3,X3,Ts

After receiving the information fromTA, (MSG2,X2,Tc,DCID) calculates the information to verify whether it is correct or not, such asNu∗=X2⊕hKs,MSG2=?hDCIDKsTcNu∗. The VS produces random nonce Ns and timestamp Ts. The VS also generates secret key Sk, Sk=hDCIDNsNu, that is shared with the vehicle for future communication. The VS also computes X3=hNuNsTsKs and MSG3=Ns⊕Nu; these parameters are (MSG3,X3,Ts) sent back to TA.


### 4.2.4. Step VA4:TA⟶Vi:X4,W

At this phase, the trusted authority calculates theMSG3 and X3 as Ns∗=MSG3⊕Nu, X3=?hNuNs∗TsKs. After verification of information, TA computes W=Ns⊕DPWi, X4=hNuNsDPWi and sends (X4,w) to the vehicle/user. The vehicle computes W and X4 such as Ns∗=W⊕DWPi, X4=?hNuNs∗DPWi; after that, the secret key Sk=hDCIDNsNu is calculated.


### 4.2.5. Step VA5: Communication

The secret keySk is used for V2V communication in the future. The vehicle server stores the vehicle/host identity and key after this communication. If vehicle A wants to communicate with other vehicles or devices, the message is encrypted with the help of a key and sent. After receiving a message from vehicle A, vehicle B sends it to VS to check the identity of vehicle A. The VS checks the legitimacy of vehicle B and vehicle A. If VS ensures that both are authorized vehicles, then the keys are sent to vehicle A and vehicle B through a secure channel. Then, vehicle B decrypts the request using this key that is received from VS.


## 4.2.1. Step VA1:Vi⟶TA:MSG1,X1,Tu,SID

Two parameters are required for login. The first one is the vehicle’s identification number, and the second one is the password. It is not possible to login without these parameters. The vehicle computes the value ofb1, which is received from RA to cross-verify VIDi and PWi. The vehicles (Vi) produce a nonce Nu and current timestamp Tu. Next, the vehicle computes three parameters such as MSG1, Z1, and X1 for the communication with TA, MSG1=ha1TuDPWiNu, Z1=hb1DPWi, and X1=Nu⊕Z1, which are used for authentication of Di. After that, the (MSG1,X1,Tu,SID) are sent to TA through an insecure channel.


## 4.2.2. Step VA2:TA⟶VS:MSG2,X2,Tc,DCID

WhenTA receives a message from the vehicle, the (MSG1,X1,Tu,SID) calculates the Z1 and X1 such as Z1∗=hb1DPWi and Nu∗=X1⊕Z1. Also, it computes MSG1=?ha1TuDPWiNu∗ to verify the same message which is received through an insecure channel from the vehicle. After calculation, the received information also ensures the integrity of the received message. The TA calculates DCID such as DCID=hDVIDiCIDSID. After that, it computes MSG2 and X2 as MSG2=hDCIDKsTcNu and X2=Nu⊕hKs, respectively. Tc represents the timestamp that generated TAat the time when the message was computed. Finally, the (MSG2,X2,Tc,DCID) is sent to the vehicle sever.


## 4.2.3. Step VA3:VS⟶TA:MSG3,X3,Ts

After receiving the information fromTA, (MSG2,X2,Tc,DCID) calculates the information to verify whether it is correct or not, such asNu∗=X2⊕hKs,MSG2=?hDCIDKsTcNu∗. The VS produces random nonce Ns and timestamp Ts. The VS also generates secret key Sk, Sk=hDCIDNsNu, that is shared with the vehicle for future communication. The VS also computes X3=hNuNsTsKs and MSG3=Ns⊕Nu; these parameters are (MSG3,X3,Ts) sent back to TA.


## 4.2.4. Step VA4:TA⟶Vi:X4,W

At this phase, the trusted authority calculates theMSG3 and X3 as Ns∗=MSG3⊕Nu, X3=?hNuNs∗TsKs. After verification of information, TA computes W=Ns⊕DPWi, X4=hNuNsDPWi and sends (X4,w) to the vehicle/user. The vehicle computes W and X4 such as Ns∗=W⊕DWPi, X4=?hNuNs∗DPWi; after that, the secret key Sk=hDCIDNsNu is calculated.


## 4.2.5. Step VA5: Communication

The secret keySk is used for V2V communication in the future. The vehicle server stores the vehicle/host identity and key after this communication. If vehicle A wants to communicate with other vehicles or devices, the message is encrypted with the help of a key and sent. After receiving a message from vehicle A, vehicle B sends it to VS to check the identity of vehicle A. The VS checks the legitimacy of vehicle B and vehicle A. If VS ensures that both are authorized vehicles, then the keys are sent to vehicle A and vehicle B through a secure channel. Then, vehicle B decrypts the request using this key that is received from VS.


## 5. Weaknesses of Vasudev et al.’s Scheme

This section highlights the weaknesses of Vasudev et al.’s scheme. The following subsections present the security scheme proposed in [2]. The scheme has some flaws and does not provide anonymity. The authenticated vehicle sends a request to TA for login approval through an insecure channel and also sends parameters {MSG1,X1,Tu,SID}. The TA does not recognize the specific identity of the vehicle where further communication is not possible between vehicles, TA and VS. To better understand Vasudev et al.’s scheme on that basis, the details of the scheme’s incorrectness are mentioned below.
(1)
Vi calculates following parameters after completing the login phase:(1)MSG1=ha1TuDPWiNu,Z1=hb1DPWi,X1=Nu⊕Z1.Vi send {MSG1,X1,Tu,SID}
(2)
After verifying the correctness ofTu, TA calculates the following:(2)Z1∗=hb1DPWi,(3)Nu∗=X1⊕Z1∗,(4)MSG1=?ha1TuDPWiNu∗.(3)
TA calculates Z1 through Equation (2), where TA requires hb1DPWi. TA receives the Tu and maintains the database that contains the records in the form of tuple{a1,b1}. Therefore, to extract hb1DPWi, TA needs to know the DVIDi. Nevertheless, TA does not know about the identity of the vehicle. Moreover, to calculate Nu∗ through Equation (3), it needs the value of Z1∗; that is not possible because several vehicles send requests to TA at the same time where every vehicle has its own parameter values such as a1,b1,Zi. Therefore, it is not possible for TA to identify the vehicle identity because TA does not know about Zi. Similarly, in order to compute the originality of the message, Equation (4) needs the value of Z1∗. So, TA does not calculate any parameters, and the authentication process may be suspended, irrespectively(4)
Similarly, the reply message fromTA sends {X4,W} to the requesting vehicleVi, without recognizing Vias the information of the requesting vehicle is unknown for TA. Moreover, the message {MSG2,X2,Tc,DCID} from TA to VS has not carried information about Vi; rather, TA itself is not able to recognize the identity of specific vehicles. Hence, TA does not send any message to Vi. Thus, this scheme is incorrect.


## 6. Proposed Scheme

In the following subsections, the main phases of the proposed scheme are explained:


### 6.1. Vehicle Registration

The driver of the vehicle/host(Di) selects a vehicle ID and password VIDi,PWi with random nonce Yi. The Vi computes DPWi=hPWiYi and sends VIDi,DPWi to the registration authority through a secure channel. After receiving data from the vehicle, RA generates Yta∈Zp∗ and calculates the following parameters: a1, b1, and EVIDi, which are unique for every vehicle or user, where a1=hVIDiKs, b1=a1⊕hVIDiDPWi, and EVIDi=EKsVIDiYta. The registration authority stores a1, b1, and EVIDi in SC and immediately forwards to TA. After receiving SC, the information is sent to the driver/user via a secure channel.When the SC information is received,Di computes the parameter Ci as Ci=VIDi⊕PWi⊕Yi. Then, Di stores Ci and SC parameters for future communication.


### 6.2. Proposed Login, Authentication, and Communication

When vehicles successfully register to the registration authority, they must be logged in and prove their authentication with aTA if the vehicle wants to obtain data from VS. The whole process is aimed at ensuring Di validity and protecting against impersonation assaults from an intruder or third-party vehicle/device.The authentication processes can also be done by the vehicle server to verify the impersonation ofVS and send accurate information to the vehicle. Figure 5 describes the whole process of login, authentication, and communication. The explanation is given as follows.Figure 5
Proposed scheme.


#### 6.2.1. Step PA1:Vi⟶TA:EVIDi,MSG1,X1,Tu,SID

Two parameters are required for the login process, i.e., the vehicle’s identification number and the password. Login is not possible without these two parameters. After login, the vehicle computes the value ofb1 which is received from RA to cross-verify VIDi and PWi. The vehicle (Vi) produces a nonce Nu and current timestamp Tu. Then, the vehicle computes the other two parameters MSG1 and X1 for the communication with TA, MSG1=ha1TuDPWiNu and X1=Nu⊕VIDi, respectively, which are used for authentication of Di. After that, (EVIDi,MSG1,X1,Tu,SID) sends the information to the TAthrough an insecure channel.


#### 6.2.2. Step PA2:TA⟶VS:MSG2,X2,Tc

WhenTA receives a message from vehicle (EVIDi,MSG1,X1,Tu,SID) to calculate the EVIDi, MSG1, and X1 such as VIDiri=DKsEVIDi, MSG1=?ha1TuDPWiNu also computes Nu=X1⊕VIDi to confirm the same message received on the channel from the vehicle. The above calculation ensures the integrity of the received message. The TA calculates MSG2 and X2 as MSG2=hKsTcNuSID and X2=Eh(KsNuTcTuVIDi, respectively. Tc represents the timestamp that is generated from TA at the time when the message was computed. Finally, (MSG2,X2,Tc) is sent to the vehicle sever.


#### 6.2.3. Step PA3:VS⟶TA:MSG3,X3,Ts

After receiving the information fromTA in which (MSG2,X2,Tc), VS calculates the information to verify whether it is correct or not, such as NuTcTuVIDi=DhKsX2 and MSG2=?hKsTcNuSID. The VS produces random nonce Ns and timestamp Ts. The VS also generates a secret key Sk, Sk=hNsNuTuTs, that is shared with the vehicle for future communication. The VS also computes X3=hNuNsKsTs and MSG3=EhKsNsTs; these parameters (MSG3,X3,Ts) are sent back to TA.


#### 6.2.4. Step PA4:TA⟶Vi:X4,W,FVIDi

The trusted authority calculatedMSG3 and X3 such as NsTs=DhKsMSG3 and X3=?hNuNsKsTs. After verification of information, TA computes W=ENuNsTs, EVIDinew=EKsVIDiTs, FVIDi=EVIDinew⊕hNuTs, Sk=hNuNsTuTs, and X4=hNuNsTsEVIDinew to the vehicle/user.The vehicle again computesW, X4, and FVIDi such as NsTs=DNuW, EVIDinew=FVIDi⊕hNu‖Ts, and X4=?hNuNsTsEVIDinew; after that, the EVIDi is replaced with EVIDinew and the secret key Sk=hNsNuTuTs is calculated.


#### 6.2.5. Step PA5: Communication

The secret keySk is used for V2V communication in the future. The vehicle server stores the vehicle/host identity and key after this communication. If vehicle A wants to communicate with other vehicles or devices, the message is encrypted with the help of a key and sent. After receiving a message from vehicle A, vehicle B sends it to VS to check the identity of vehicle A. The VS checks the legitimacy of vehicle B and vehicle A. If VS ensures that both are authorized vehicles, then a key is sent to vehicle A and vehicle B through a secure channel. Then, the vehicle B decrypts the request using this key which is received from VS.


## 6.1. Vehicle Registration

The driver of the vehicle/host(Di) selects a vehicle ID and password VIDi,PWi with random nonce Yi. The Vi computes DPWi=hPWiYi and sends VIDi,DPWi to the registration authority through a secure channel. After receiving data from the vehicle, RA generates Yta∈Zp∗ and calculates the following parameters: a1, b1, and EVIDi, which are unique for every vehicle or user, where a1=hVIDiKs, b1=a1⊕hVIDiDPWi, and EVIDi=EKsVIDiYta. The registration authority stores a1, b1, and EVIDi in SC and immediately forwards to TA. After receiving SC, the information is sent to the driver/user via a secure channel.When the SC information is received,Di computes the parameter Ci as Ci=VIDi⊕PWi⊕Yi. Then, Di stores Ci and SC parameters for future communication.


## 6.2. Proposed Login, Authentication, and Communication

When vehicles successfully register to the registration authority, they must be logged in and prove their authentication with aTA if the vehicle wants to obtain data from VS. The whole process is aimed at ensuring Di validity and protecting against impersonation assaults from an intruder or third-party vehicle/device.The authentication processes can also be done by the vehicle server to verify the impersonation ofVS and send accurate information to the vehicle. Figure 5 describes the whole process of login, authentication, and communication. The explanation is given as follows.Figure 5
Proposed scheme.


### 6.2.1. Step PA1:Vi⟶TA:EVIDi,MSG1,X1,Tu,SID

Two parameters are required for the login process, i.e., the vehicle’s identification number and the password. Login is not possible without these two parameters. After login, the vehicle computes the value ofb1 which is received from RA to cross-verify VIDi and PWi. The vehicle (Vi) produces a nonce Nu and current timestamp Tu. Then, the vehicle computes the other two parameters MSG1 and X1 for the communication with TA, MSG1=ha1TuDPWiNu and X1=Nu⊕VIDi, respectively, which are used for authentication of Di. After that, (EVIDi,MSG1,X1,Tu,SID) sends the information to the TAthrough an insecure channel.


### 6.2.2. Step PA2:TA⟶VS:MSG2,X2,Tc

WhenTA receives a message from vehicle (EVIDi,MSG1,X1,Tu,SID) to calculate the EVIDi, MSG1, and X1 such as VIDiri=DKsEVIDi, MSG1=?ha1TuDPWiNu also computes Nu=X1⊕VIDi to confirm the same message received on the channel from the vehicle. The above calculation ensures the integrity of the received message. The TA calculates MSG2 and X2 as MSG2=hKsTcNuSID and X2=Eh(KsNuTcTuVIDi, respectively. Tc represents the timestamp that is generated from TA at the time when the message was computed. Finally, (MSG2,X2,Tc) is sent to the vehicle sever.


### 6.2.3. Step PA3:VS⟶TA:MSG3,X3,Ts

After receiving the information fromTA in which (MSG2,X2,Tc), VS calculates the information to verify whether it is correct or not, such as NuTcTuVIDi=DhKsX2 and MSG2=?hKsTcNuSID. The VS produces random nonce Ns and timestamp Ts. The VS also generates a secret key Sk, Sk=hNsNuTuTs, that is shared with the vehicle for future communication. The VS also computes X3=hNuNsKsTs and MSG3=EhKsNsTs; these parameters (MSG3,X3,Ts) are sent back to TA.


### 6.2.4. Step PA4:TA⟶Vi:X4,W,FVIDi

The trusted authority calculatedMSG3 and X3 such as NsTs=DhKsMSG3 and X3=?hNuNsKsTs. After verification of information, TA computes W=ENuNsTs, EVIDinew=EKsVIDiTs, FVIDi=EVIDinew⊕hNuTs, Sk=hNuNsTuTs, and X4=hNuNsTsEVIDinew to the vehicle/user.The vehicle again computesW, X4, and FVIDi such as NsTs=DNuW, EVIDinew=FVIDi⊕hNu‖Ts, and X4=?hNuNsTsEVIDinew; after that, the EVIDi is replaced with EVIDinew and the secret key Sk=hNsNuTuTs is calculated.


### 6.2.5. Step PA5: Communication

The secret keySk is used for V2V communication in the future. The vehicle server stores the vehicle/host identity and key after this communication. If vehicle A wants to communicate with other vehicles or devices, the message is encrypted with the help of a key and sent. After receiving a message from vehicle A, vehicle B sends it to VS to check the identity of vehicle A. The VS checks the legitimacy of vehicle B and vehicle A. If VS ensures that both are authorized vehicles, then a key is sent to vehicle A and vehicle B through a secure channel. Then, the vehicle B decrypts the request using this key which is received from VS.


## 6.2.1. Step PA1:Vi⟶TA:EVIDi,MSG1,X1,Tu,SID

Two parameters are required for the login process, i.e., the vehicle’s identification number and the password. Login is not possible without these two parameters. After login, the vehicle computes the value ofb1 which is received from RA to cross-verify VIDi and PWi. The vehicle (Vi) produces a nonce Nu and current timestamp Tu. Then, the vehicle computes the other two parameters MSG1 and X1 for the communication with TA, MSG1=ha1TuDPWiNu and X1=Nu⊕VIDi, respectively, which are used for authentication of Di. After that, (EVIDi,MSG1,X1,Tu,SID) sends the information to the TAthrough an insecure channel.


## 6.2.2. Step PA2:TA⟶VS:MSG2,X2,Tc

WhenTA receives a message from vehicle (EVIDi,MSG1,X1,Tu,SID) to calculate the EVIDi, MSG1, and X1 such as VIDiri=DKsEVIDi, MSG1=?ha1TuDPWiNu also computes Nu=X1⊕VIDi to confirm the same message received on the channel from the vehicle. The above calculation ensures the integrity of the received message. The TA calculates MSG2 and X2 as MSG2=hKsTcNuSID and X2=Eh(KsNuTcTuVIDi, respectively. Tc represents the timestamp that is generated from TA at the time when the message was computed. Finally, (MSG2,X2,Tc) is sent to the vehicle sever.


## 6.2.3. Step PA3:VS⟶TA:MSG3,X3,Ts

After receiving the information fromTA in which (MSG2,X2,Tc), VS calculates the information to verify whether it is correct or not, such as NuTcTuVIDi=DhKsX2 and MSG2=?hKsTcNuSID. The VS produces random nonce Ns and timestamp Ts. The VS also generates a secret key Sk, Sk=hNsNuTuTs, that is shared with the vehicle for future communication. The VS also computes X3=hNuNsKsTs and MSG3=EhKsNsTs; these parameters (MSG3,X3,Ts) are sent back to TA.


## 6.2.4. Step PA4:TA⟶Vi:X4,W,FVIDi

The trusted authority calculatedMSG3 and X3 such as NsTs=DhKsMSG3 and X3=?hNuNsKsTs. After verification of information, TA computes W=ENuNsTs, EVIDinew=EKsVIDiTs, FVIDi=EVIDinew⊕hNuTs, Sk=hNuNsTuTs, and X4=hNuNsTsEVIDinew to the vehicle/user.The vehicle again computesW, X4, and FVIDi such as NsTs=DNuW, EVIDinew=FVIDi⊕hNu‖Ts, and X4=?hNuNsTsEVIDinew; after that, the EVIDi is replaced with EVIDinew and the secret key Sk=hNsNuTuTs is calculated.


## 6.2.5. Step PA5: Communication

The secret keySk is used for V2V communication in the future. The vehicle server stores the vehicle/host identity and key after this communication. If vehicle A wants to communicate with other vehicles or devices, the message is encrypted with the help of a key and sent. After receiving a message from vehicle A, vehicle B sends it to VS to check the identity of vehicle A. The VS checks the legitimacy of vehicle B and vehicle A. If VS ensures that both are authorized vehicles, then a key is sent to vehicle A and vehicle B through a secure channel. Then, the vehicle B decrypts the request using this key which is received from VS.


## 7. Security Analysis

This section performs formal security analysis through the BAN-logic method and discusses how the proposed scheme protects it from various security attacks.


### 7.1. Formal Security Analysis through BAN-Logic

In this subsection, the detailed security analysis is provided of the proposed scheme using BAN-logic [35]. Firstly, some basic notations are presented that are used to analyze the proposed scheme. Here, the L and M are used as participators, and X is used as a formula.
(i)
(#X): X is fresh(ii)
L∣≡X:L believes the trustworthiness of X(iii)
L∣~X:L once said X(iv)
L⊲X:L sees X(v)
L∣X:L has jurisdiction over X(vi)
L↔KM: between L and M, K is shared key(vii)
X,Yk:X and Y are encrypted with the help of K(viii)
XY:X combined with YThe following BAN-logic rules are used to verify the security features:(i)
Rule 1: message meaning ruleIfL sees a statement X encrypted with key K and L believes K is a shared secret key between L and M, then L believes M once said X.
(5)L∣≡↔KM,L⊲XKL≡M~X.(ii)
Rule 2: nonce verification ruleIfL believes that the statement X is updated and L also believes that M once said X, then L believes M is the statement of X.
(6)L∣≡#X,L∣≡M∣~XL∣≡M∣≡X.(iii)
Rule 3: jurisdiction ruleIfL believes M has jurisdiction over the statement X and L believes M is the statement X, then L believes the statement of X.
(7)L≡M⇒X,L≡M∣≡XL∣≡X.(iv)
Rule 4: freshness ruleIfL believes that the part of the statement X is updated, then L believes that the statement X,Y is updated.
(8)L∣≡#XL∣≡#X,Y.(v)
Rule 5: belief ruleIfL believes that M believes in the statement of X,Y, then L believes that M believes in the part of statement X.
(9)L∣≡M∣≡X,YL∣≡M∣≡X.The main goals of the proposed security scheme are proven under the BAN-logic analytic procedure:(i)
G1:Vi∣≡Vi↔SKTA(ii)
G2:Vi∣≡TA∣≡Vi↔SKTA(iii)
G3:TA∣≡Vi↔SKTA(iv)
G4:TA∣≡Vi∣≡Vi↔SKTA(v)
G5:VS∣≡VS↔SKTA(vi)
G6:VS≡TA≡VS↔SKTA(vii)
G7:TA∣≡VS↔SKTA(viii)
G8:TA≡VS≡VS↔SKTAIn the proposed scheme, when a message is sent over an unsafe communication channel, the details of the message are mentioned below:(i)
M1:Vi⟶TA:EVIDi,MSG1X1,Tu,SID:Nu,EVIDiVIDi(ii)
M2:TA⟶VS:MSG2,X2,Tc:hKs‖Tc‖Nu‖SID,NuKs(iii)
M3:VS⟶TA:MSG3,X3,Ts:Nsks(iv)
M4:TA⟶Vi:X4,W,FVIDi:Nu,NsVIDiFurthermore, the following assumptions are given as proof of the proposed security scheme:(i)
A1:TA∣≡#Nu(ii)
A2:TA∣≡#Ns(iii)
A3:VS∣≡#hKs‖Tc‖Nu‖SID(iv)
A4:Vi∣≡#Nu(v)
A5:Vi∣≡TAVi↔SkTA(vi)
A6:TA∣≡ViVi↔SkTA(vii)
A7:VS∣≡TAVS↔SkTA(viii)
A8:TA∣≡VS∣VS↔SkTA(ix)
A9:Vi∣≡Vi↔VIDiTA(x)
A10:TA∣≡Vi↔VIDiTA(xi)
A11:VS∣≡VS↔SkTA(xii)
A12:TA∣≡VS↔SkTA(xiii)
A13:VS∣≡TA∣~hKs‖Tc‖Nu‖SID,Nu


#### 7.1.1. BAN-Logic Proof

The BAN-logic is conducted to analyze the proposed scheme:Step 1.
S1 can be acquired from M1.
(10)S1:TA⊲Nu,EVIDiVIDi.Step 2.
S2 can be persuaded by applying rule 1, using S1 and A10.
(11)S2:TA≡Vi~Nu,EVIDi.Step 3.
S3 can be persuaded by applying rule 4, using S2 and A1.
(12)S3:TA∣≡#Nu,EVIDi.Step 4.
S4 can be persuaded by applying rule 2, using S2 and S3.
(13)S4:TA≡Vi≡Nu,EVIDi.Step 5.
S5 can be persuaded by S4 and applying rule 5
(14)S5:TA≡Vi≡Nu.Step 6.
S6 obtained from M2.
(15)S6:VS⊲hKsTcNuSIDKS.Step 7.
S7 can be persuaded by applying rule 1, using S6 and A13.
(16)S7:VS≡TA~hKsTcNuSID.Step 8.
S8 can be persuaded by applying rule 5, using S7 and A3.
(17)S8:VS∣≡#hKsTcNuSID,Nu.Step 9.
S9 can be persuaded by applying rule 2, using S7 and S8.
(18)S9:VS≡TA≡hKsTcNuSID,Nu.Step 10.
S10 obtained from M3.
(19)S10:TA⊲NUSk.Step 11.
S11 can be persuaded by applying rule 1, using A5 and S8.
(20)S11:TA≡VS~Ns.Step 12.
S12 can be persuaded by applying rule 2, using S9 and S10.
(21)S12:TA≡VS≡Ns.Step 13.
S13 can be persuaded by S9 and S12, VS. TA can be calculated by session key Sk=hNsNuTuTs.
(22)S13:TA≡VS≡VS↔SkTA⟶G8,S14:VS≡TA≡VS↔SkTA⟶G6.Step 14.
S15 and S16 can be persuaded by applying rule 3, using S13 and A8 and S14 and A7.
(23)S15:TA∣≡VS↔SkTA⟶G7,S16:VS∣≡VS↔SkTA⟶G5.Step 15.
S17 obtained from M4.
(24)S17:Vi⊲Ns,NUVIDi.Step 16.
S18 can be persuaded by applying rule 1, using A9 and S17.
(25)S18:Vi≡TA~Nu,Ns.Step 17.
S19 can be persuaded by applying rule 5, using S18 and A4.
(26)S19:Vi∣≡#Nu,Ns.Step 18.
S20 can be persuaded by applying rule 2, using S16 and S17.
(27)S20:Vi≡TA≡Nu,Ns.Step 19.
S21 and S22 can be persuaded by S5, S18, and Vi. TA can be calculated by session key Sk=hNsNuTuTs.
(28)S21:Vi≡TA≡Vi↔SkTA⟶G2,S22:TA≡Vi≡Vi↔SkTA⟶G4.Step 20.
S23 and S24 can be persuaded by applying rule 3, using S21, A5, S22, and A6.
(29)S23:Vi∣≡Vi↔SkTA⟶G1,S24:TA∣≡Vi↔SkTA⟶G3.


### 7.2. Security Discussion

This subsection explains how the proposed security scheme can resist against various security attacks; details are given as follows.


#### 7.2.1. Correctness

The proposed scheme completes the authentication process correctly betweenVi and VS with the help of TA. The proposed scheme is designed and provides intuition to the common mistakes. It also provides supports for correctness issues in the future work. In the vehicle registration phase of the proposed scheme, a random and dynamic identity EVIDi is generated by the RA and is stored in the memory of vehicle SC. This identity is used in the process of the login and authentication request on both SC in possession of the vehicle and TA. Furthermore, every vehicle has a different random number and unique identity. Thus, TA easily identifies the vehicle identity at the time of authentication when the vehicle requests TA for login. Therefore, the proposed scheme eliminates the correctness issues.


#### 7.2.2. Impersonation Attack

Here, the defense of the proposed security scheme against the vehicle such asTA, and the VS impersonation assault are described.
(1)
Vehicle impersonation attack: if E tries to launch the impersonation assault on the behalf of the vehicle, it needs to construct an original login request message M1′ such as M1′=MSG1′,EVIDi′,Tu′,X1′,SID′, where MSG1′=ha1‖Tu‖DPWi‖Nu, X1′=Nu⊕VIDi, EVIDi′=EKsVIDi‖Yta with updated nonce Nu′ and timestamp Tu′. However, it is seen at the start that it is very difficult to recover Tu, VIDi, and DWPi for constructing M′=MSG1′,EVIDi′,Tu′,X1′,SID′. Thus, the proposed protocol provides security against the vehicle impersonation assault.(2)
TAimpersonation attack: similarly, an E tries to instigate a forgery toward VS on the behalf of TA. For this purpose, E needs to construct the M2′ such as M2′=MSG2,X2 with updated nonce Nu′ and timestamp Tc′ and also requires some confidential parameters such as Tc, Nu, Tu, and Ks secret keys. It is a computationally hard problem to compute these parameters from previously intercepted message MSG2 and X2. Thus, the proposed protocol also provides security against TA impersonation assault.(3)
VSimpersonation attack: in the case of VS impersonation assault, when E launches an assault on VS toward TA, it also needs to design the message M3′ with an updated nonce Nu′ and new timestamp Tc′, where M3′=MSG3′,X3′,Ts′, MSG3′=EhNs‖Ts, and X3′=hNu′‖Ns′‖Ks′‖Ts′. However, the attacker may not be able to construct the valid message parameters in M3′, until granted the valid secret key Ks. Thus, E cannot impersonate the VS, and the proposed scheme provides security to VS impersonation assault.


#### 7.2.3. Stolen SC Attack

Suppose ifE steals the smart card and obtains all confidential credentials {a1,b1,EVIDi} using a power analysis attack (PWA) [33]. E tries to compute MSG1, X1, and EVIDi. However, E requires the knowledge of DPWi=hPWiYi, whereas the E does not hold a hash function, which is not convertible. Thus, E cannot recover the password, and the stolen smart card cannot be accessible.


#### 7.2.4. Session Key Security

The trusted authority and vehicle server both verify the value of nonceNs, Tu, Ts, and Nu that are used to compute the secret key value Sk=hNsNuTuTs. This process ensures the originality of the session key. Thus, session key security is ensured.


#### 7.2.5. Anonymity and Untraceability

In the phase of mutual authentication, the proposed security scheme utilizes random nonceNu, ri, and Tu, as well as timestamp Tu, Tc, and Ts in communication messages MSG1–MSG3. In the communication scenario, E may not differentiate among the messages of the different sessions, which publicly render the proposed scheme untraceable. At the same time, the E may not identify the vehicle identity, since the messages employ pseudoidentities, i.e., EVIDi, EVIDinew, and FVIDi and again replace EVIDinew into EVIDi in the messages instead of original identities, that are enclosed under the rigidity of a one-way hash function-bearing collision resistance characteristic. Thus, the proposed scheme maintains the untraceability and anonymity characteristics.


#### 7.2.6. Man-in-the-Middle Attack

IfE want to launch the man-in-the-middle assault, it is required to build the message M′ i.e., M1′=MSG1,EVIDi,Tu,X1,SID where MSG1=ha1‖Tu‖DPWi‖Nu, X1=Nu⊕VIDi, and EVIDi=EKsVIDi‖Yta. However, to meet the goal, the attacker needs to build those message parameters with updated nonce Nu and timestamp Tu, which are not possible until E has access to Ks, EVIDi, and DPWi. Likewise, E is not able to rebuild other messages such as MSG1–MSG3 in the protocol with updated nonce and timestamp without having access to important parameters in possession with those participating entities. Therefore, the proposed scheme provides security against the man-in-the-middle assault.


#### 7.2.7. Off-Line Password Guessing Attack

It is proven that the proposed scheme is infeasible forE to get the identity of Di, even after extracting the parameters. Suppose if E has access to a smart card, which contains {EVIDi,a1,b1,h.,Yi}, the parameters can be obtained by using the PWA [33]. However, assaults cannot compute the Ks and, ultimately, PWi from DWPi. The E has only one way to acquire the PWi from MSG1 without breaching the noninvertible characteristics of the cryptography hash function.


#### 7.2.8. Replay Attack

In the proposed security scheme, various entities such asVi, TA, and VS exchange the messages from MSG1 to MSG3 and utilize the timestamp Tu, Tc, and Ts to encounter the possible replay assault. At the same time, mutual authentication is required for communication. The messages need to be replied to in a short period of timestamp T to abolish the possibility of E manipulating the messages and initiating replay assault. Without updating the parameters MSG1, X1, EVIDi, MSG2, X2, MSG3, X3, W, X4, and FVIDi, the updated timestamp cannot be utilized. At the same time, the parameters need to be updated with the new timestamp, whereas the E requires access to VIDi identity and password, and other shared parameters between Vi, TA, and VS. Thus, the replay assault does not happen in the proposed scheme.


#### 7.2.9. Denial of Service (DoS) Attack

The proposed scheme provides security against DoS assault as theSC in the start authenticate Vi such as EVIDi=HVIDiYta. This condition will only be legal if Vi enters the correct identity VIDi and password DPWi; after the insertion of the valid identity and password, the parameters are computed in SCVIDiYta=EksEVIDi. The authentication of Vi is done locally at the vehicle’s side. After that, a request is sent to TA for authentication. The same process is followed in the password and update phases to protect the incorrect modification of these parameters. Thus, the scheme prevents DoS assault.


## 7.1. Formal Security Analysis through BAN-Logic

In this subsection, the detailed security analysis is provided of the proposed scheme using BAN-logic [35]. Firstly, some basic notations are presented that are used to analyze the proposed scheme. Here, the L and M are used as participators, and X is used as a formula.
(i)
(#X): X is fresh(ii)
L∣≡X:L believes the trustworthiness of X(iii)
L∣~X:L once said X(iv)
L⊲X:L sees X(v)
L∣X:L has jurisdiction over X(vi)
L↔KM: between L and M, K is shared key(vii)
X,Yk:X and Y are encrypted with the help of K(viii)
XY:X combined with YThe following BAN-logic rules are used to verify the security features:(i)
Rule 1: message meaning ruleIfL sees a statement X encrypted with key K and L believes K is a shared secret key between L and M, then L believes M once said X.
(5)L∣≡↔KM,L⊲XKL≡M~X.(ii)
Rule 2: nonce verification ruleIfL believes that the statement X is updated and L also believes that M once said X, then L believes M is the statement of X.
(6)L∣≡#X,L∣≡M∣~XL∣≡M∣≡X.(iii)
Rule 3: jurisdiction ruleIfL believes M has jurisdiction over the statement X and L believes M is the statement X, then L believes the statement of X.
(7)L≡M⇒X,L≡M∣≡XL∣≡X.(iv)
Rule 4: freshness ruleIfL believes that the part of the statement X is updated, then L believes that the statement X,Y is updated.
(8)L∣≡#XL∣≡#X,Y.(v)
Rule 5: belief ruleIfL believes that M believes in the statement of X,Y, then L believes that M believes in the part of statement X.
(9)L∣≡M∣≡X,YL∣≡M∣≡X.The main goals of the proposed security scheme are proven under the BAN-logic analytic procedure:(i)
G1:Vi∣≡Vi↔SKTA(ii)
G2:Vi∣≡TA∣≡Vi↔SKTA(iii)
G3:TA∣≡Vi↔SKTA(iv)
G4:TA∣≡Vi∣≡Vi↔SKTA(v)
G5:VS∣≡VS↔SKTA(vi)
G6:VS≡TA≡VS↔SKTA(vii)
G7:TA∣≡VS↔SKTA(viii)
G8:TA≡VS≡VS↔SKTAIn the proposed scheme, when a message is sent over an unsafe communication channel, the details of the message are mentioned below:(i)
M1:Vi⟶TA:EVIDi,MSG1X1,Tu,SID:Nu,EVIDiVIDi(ii)
M2:TA⟶VS:MSG2,X2,Tc:hKs‖Tc‖Nu‖SID,NuKs(iii)
M3:VS⟶TA:MSG3,X3,Ts:Nsks(iv)
M4:TA⟶Vi:X4,W,FVIDi:Nu,NsVIDiFurthermore, the following assumptions are given as proof of the proposed security scheme:(i)
A1:TA∣≡#Nu(ii)
A2:TA∣≡#Ns(iii)
A3:VS∣≡#hKs‖Tc‖Nu‖SID(iv)
A4:Vi∣≡#Nu(v)
A5:Vi∣≡TAVi↔SkTA(vi)
A6:TA∣≡ViVi↔SkTA(vii)
A7:VS∣≡TAVS↔SkTA(viii)
A8:TA∣≡VS∣VS↔SkTA(ix)
A9:Vi∣≡Vi↔VIDiTA(x)
A10:TA∣≡Vi↔VIDiTA(xi)
A11:VS∣≡VS↔SkTA(xii)
A12:TA∣≡VS↔SkTA(xiii)
A13:VS∣≡TA∣~hKs‖Tc‖Nu‖SID,Nu


### 7.1.1. BAN-Logic Proof

The BAN-logic is conducted to analyze the proposed scheme:Step 1.
S1 can be acquired from M1.
(10)S1:TA⊲Nu,EVIDiVIDi.Step 2.
S2 can be persuaded by applying rule 1, using S1 and A10.
(11)S2:TA≡Vi~Nu,EVIDi.Step 3.
S3 can be persuaded by applying rule 4, using S2 and A1.
(12)S3:TA∣≡#Nu,EVIDi.Step 4.
S4 can be persuaded by applying rule 2, using S2 and S3.
(13)S4:TA≡Vi≡Nu,EVIDi.Step 5.
S5 can be persuaded by S4 and applying rule 5
(14)S5:TA≡Vi≡Nu.Step 6.
S6 obtained from M2.
(15)S6:VS⊲hKsTcNuSIDKS.Step 7.
S7 can be persuaded by applying rule 1, using S6 and A13.
(16)S7:VS≡TA~hKsTcNuSID.Step 8.
S8 can be persuaded by applying rule 5, using S7 and A3.
(17)S8:VS∣≡#hKsTcNuSID,Nu.Step 9.
S9 can be persuaded by applying rule 2, using S7 and S8.
(18)S9:VS≡TA≡hKsTcNuSID,Nu.Step 10.
S10 obtained from M3.
(19)S10:TA⊲NUSk.Step 11.
S11 can be persuaded by applying rule 1, using A5 and S8.
(20)S11:TA≡VS~Ns.Step 12.
S12 can be persuaded by applying rule 2, using S9 and S10.
(21)S12:TA≡VS≡Ns.Step 13.
S13 can be persuaded by S9 and S12, VS. TA can be calculated by session key Sk=hNsNuTuTs.
(22)S13:TA≡VS≡VS↔SkTA⟶G8,S14:VS≡TA≡VS↔SkTA⟶G6.Step 14.
S15 and S16 can be persuaded by applying rule 3, using S13 and A8 and S14 and A7.
(23)S15:TA∣≡VS↔SkTA⟶G7,S16:VS∣≡VS↔SkTA⟶G5.Step 15.
S17 obtained from M4.
(24)S17:Vi⊲Ns,NUVIDi.Step 16.
S18 can be persuaded by applying rule 1, using A9 and S17.
(25)S18:Vi≡TA~Nu,Ns.Step 17.
S19 can be persuaded by applying rule 5, using S18 and A4.
(26)S19:Vi∣≡#Nu,Ns.Step 18.
S20 can be persuaded by applying rule 2, using S16 and S17.
(27)S20:Vi≡TA≡Nu,Ns.Step 19.
S21 and S22 can be persuaded by S5, S18, and Vi. TA can be calculated by session key Sk=hNsNuTuTs.
(28)S21:Vi≡TA≡Vi↔SkTA⟶G2,S22:TA≡Vi≡Vi↔SkTA⟶G4.Step 20.
S23 and S24 can be persuaded by applying rule 3, using S21, A5, S22, and A6.
(29)S23:Vi∣≡Vi↔SkTA⟶G1,S24:TA∣≡Vi↔SkTA⟶G3.


## 7.1.1. BAN-Logic Proof

The BAN-logic is conducted to analyze the proposed scheme:Step 1.
S1 can be acquired from M1.
(10)S1:TA⊲Nu,EVIDiVIDi.Step 2.
S2 can be persuaded by applying rule 1, using S1 and A10.
(11)S2:TA≡Vi~Nu,EVIDi.Step 3.
S3 can be persuaded by applying rule 4, using S2 and A1.
(12)S3:TA∣≡#Nu,EVIDi.Step 4.
S4 can be persuaded by applying rule 2, using S2 and S3.
(13)S4:TA≡Vi≡Nu,EVIDi.Step 5.
S5 can be persuaded by S4 and applying rule 5
(14)S5:TA≡Vi≡Nu.Step 6.
S6 obtained from M2.
(15)S6:VS⊲hKsTcNuSIDKS.Step 7.
S7 can be persuaded by applying rule 1, using S6 and A13.
(16)S7:VS≡TA~hKsTcNuSID.Step 8.
S8 can be persuaded by applying rule 5, using S7 and A3.
(17)S8:VS∣≡#hKsTcNuSID,Nu.Step 9.
S9 can be persuaded by applying rule 2, using S7 and S8.
(18)S9:VS≡TA≡hKsTcNuSID,Nu.Step 10.
S10 obtained from M3.
(19)S10:TA⊲NUSk.Step 11.
S11 can be persuaded by applying rule 1, using A5 and S8.
(20)S11:TA≡VS~Ns.Step 12.
S12 can be persuaded by applying rule 2, using S9 and S10.
(21)S12:TA≡VS≡Ns.Step 13.
S13 can be persuaded by S9 and S12, VS. TA can be calculated by session key Sk=hNsNuTuTs.
(22)S13:TA≡VS≡VS↔SkTA⟶G8,S14:VS≡TA≡VS↔SkTA⟶G6.Step 14.
S15 and S16 can be persuaded by applying rule 3, using S13 and A8 and S14 and A7.
(23)S15:TA∣≡VS↔SkTA⟶G7,S16:VS∣≡VS↔SkTA⟶G5.Step 15.
S17 obtained from M4.
(24)S17:Vi⊲Ns,NUVIDi.Step 16.
S18 can be persuaded by applying rule 1, using A9 and S17.
(25)S18:Vi≡TA~Nu,Ns.Step 17.
S19 can be persuaded by applying rule 5, using S18 and A4.
(26)S19:Vi∣≡#Nu,Ns.Step 18.
S20 can be persuaded by applying rule 2, using S16 and S17.
(27)S20:Vi≡TA≡Nu,Ns.Step 19.
S21 and S22 can be persuaded by S5, S18, and Vi. TA can be calculated by session key Sk=hNsNuTuTs.
(28)S21:Vi≡TA≡Vi↔SkTA⟶G2,S22:TA≡Vi≡Vi↔SkTA⟶G4.Step 20.
S23 and S24 can be persuaded by applying rule 3, using S21, A5, S22, and A6.
(29)S23:Vi∣≡Vi↔SkTA⟶G1,S24:TA∣≡Vi↔SkTA⟶G3.


## 7.2. Security Discussion

This subsection explains how the proposed security scheme can resist against various security attacks; details are given as follows.


### 7.2.1. Correctness

The proposed scheme completes the authentication process correctly betweenVi and VS with the help of TA. The proposed scheme is designed and provides intuition to the common mistakes. It also provides supports for correctness issues in the future work. In the vehicle registration phase of the proposed scheme, a random and dynamic identity EVIDi is generated by the RA and is stored in the memory of vehicle SC. This identity is used in the process of the login and authentication request on both SC in possession of the vehicle and TA. Furthermore, every vehicle has a different random number and unique identity. Thus, TA easily identifies the vehicle identity at the time of authentication when the vehicle requests TA for login. Therefore, the proposed scheme eliminates the correctness issues.


### 7.2.2. Impersonation Attack

Here, the defense of the proposed security scheme against the vehicle such asTA, and the VS impersonation assault are described.
(1)
Vehicle impersonation attack: if E tries to launch the impersonation assault on the behalf of the vehicle, it needs to construct an original login request message M1′ such as M1′=MSG1′,EVIDi′,Tu′,X1′,SID′, where MSG1′=ha1‖Tu‖DPWi‖Nu, X1′=Nu⊕VIDi, EVIDi′=EKsVIDi‖Yta with updated nonce Nu′ and timestamp Tu′. However, it is seen at the start that it is very difficult to recover Tu, VIDi, and DWPi for constructing M′=MSG1′,EVIDi′,Tu′,X1′,SID′. Thus, the proposed protocol provides security against the vehicle impersonation assault.(2)
TAimpersonation attack: similarly, an E tries to instigate a forgery toward VS on the behalf of TA. For this purpose, E needs to construct the M2′ such as M2′=MSG2,X2 with updated nonce Nu′ and timestamp Tc′ and also requires some confidential parameters such as Tc, Nu, Tu, and Ks secret keys. It is a computationally hard problem to compute these parameters from previously intercepted message MSG2 and X2. Thus, the proposed protocol also provides security against TA impersonation assault.(3)
VSimpersonation attack: in the case of VS impersonation assault, when E launches an assault on VS toward TA, it also needs to design the message M3′ with an updated nonce Nu′ and new timestamp Tc′, where M3′=MSG3′,X3′,Ts′, MSG3′=EhNs‖Ts, and X3′=hNu′‖Ns′‖Ks′‖Ts′. However, the attacker may not be able to construct the valid message parameters in M3′, until granted the valid secret key Ks. Thus, E cannot impersonate the VS, and the proposed scheme provides security to VS impersonation assault.


### 7.2.3. Stolen SC Attack

Suppose ifE steals the smart card and obtains all confidential credentials {a1,b1,EVIDi} using a power analysis attack (PWA) [33]. E tries to compute MSG1, X1, and EVIDi. However, E requires the knowledge of DPWi=hPWiYi, whereas the E does not hold a hash function, which is not convertible. Thus, E cannot recover the password, and the stolen smart card cannot be accessible.


### 7.2.4. Session Key Security

The trusted authority and vehicle server both verify the value of nonceNs, Tu, Ts, and Nu that are used to compute the secret key value Sk=hNsNuTuTs. This process ensures the originality of the session key. Thus, session key security is ensured.


### 7.2.5. Anonymity and Untraceability

In the phase of mutual authentication, the proposed security scheme utilizes random nonceNu, ri, and Tu, as well as timestamp Tu, Tc, and Ts in communication messages MSG1–MSG3. In the communication scenario, E may not differentiate among the messages of the different sessions, which publicly render the proposed scheme untraceable. At the same time, the E may not identify the vehicle identity, since the messages employ pseudoidentities, i.e., EVIDi, EVIDinew, and FVIDi and again replace EVIDinew into EVIDi in the messages instead of original identities, that are enclosed under the rigidity of a one-way hash function-bearing collision resistance characteristic. Thus, the proposed scheme maintains the untraceability and anonymity characteristics.


### 7.2.6. Man-in-the-Middle Attack

IfE want to launch the man-in-the-middle assault, it is required to build the message M′ i.e., M1′=MSG1,EVIDi,Tu,X1,SID where MSG1=ha1‖Tu‖DPWi‖Nu, X1=Nu⊕VIDi, and EVIDi=EKsVIDi‖Yta. However, to meet the goal, the attacker needs to build those message parameters with updated nonce Nu and timestamp Tu, which are not possible until E has access to Ks, EVIDi, and DPWi. Likewise, E is not able to rebuild other messages such as MSG1–MSG3 in the protocol with updated nonce and timestamp without having access to important parameters in possession with those participating entities. Therefore, the proposed scheme provides security against the man-in-the-middle assault.


### 7.2.7. Off-Line Password Guessing Attack

It is proven that the proposed scheme is infeasible forE to get the identity of Di, even after extracting the parameters. Suppose if E has access to a smart card, which contains {EVIDi,a1,b1,h.,Yi}, the parameters can be obtained by using the PWA [33]. However, assaults cannot compute the Ks and, ultimately, PWi from DWPi. The E has only one way to acquire the PWi from MSG1 without breaching the noninvertible characteristics of the cryptography hash function.


### 7.2.8. Replay Attack

In the proposed security scheme, various entities such asVi, TA, and VS exchange the messages from MSG1 to MSG3 and utilize the timestamp Tu, Tc, and Ts to encounter the possible replay assault. At the same time, mutual authentication is required for communication. The messages need to be replied to in a short period of timestamp T to abolish the possibility of E manipulating the messages and initiating replay assault. Without updating the parameters MSG1, X1, EVIDi, MSG2, X2, MSG3, X3, W, X4, and FVIDi, the updated timestamp cannot be utilized. At the same time, the parameters need to be updated with the new timestamp, whereas the E requires access to VIDi identity and password, and other shared parameters between Vi, TA, and VS. Thus, the replay assault does not happen in the proposed scheme.


### 7.2.9. Denial of Service (DoS) Attack

The proposed scheme provides security against DoS assault as theSC in the start authenticate Vi such as EVIDi=HVIDiYta. This condition will only be legal if Vi enters the correct identity VIDi and password DPWi; after the insertion of the valid identity and password, the parameters are computed in SCVIDiYta=EksEVIDi. The authentication of Vi is done locally at the vehicle’s side. After that, a request is sent to TA for authentication. The same process is followed in the password and update phases to protect the incorrect modification of these parameters. Thus, the scheme prevents DoS assault.


## 7.2.1. Correctness

The proposed scheme completes the authentication process correctly betweenVi and VS with the help of TA. The proposed scheme is designed and provides intuition to the common mistakes. It also provides supports for correctness issues in the future work. In the vehicle registration phase of the proposed scheme, a random and dynamic identity EVIDi is generated by the RA and is stored in the memory of vehicle SC. This identity is used in the process of the login and authentication request on both SC in possession of the vehicle and TA. Furthermore, every vehicle has a different random number and unique identity. Thus, TA easily identifies the vehicle identity at the time of authentication when the vehicle requests TA for login. Therefore, the proposed scheme eliminates the correctness issues.


## 7.2.2. Impersonation Attack

Here, the defense of the proposed security scheme against the vehicle such asTA, and the VS impersonation assault are described.
(1)
Vehicle impersonation attack: if E tries to launch the impersonation assault on the behalf of the vehicle, it needs to construct an original login request message M1′ such as M1′=MSG1′,EVIDi′,Tu′,X1′,SID′, where MSG1′=ha1‖Tu‖DPWi‖Nu, X1′=Nu⊕VIDi, EVIDi′=EKsVIDi‖Yta with updated nonce Nu′ and timestamp Tu′. However, it is seen at the start that it is very difficult to recover Tu, VIDi, and DWPi for constructing M′=MSG1′,EVIDi′,Tu′,X1′,SID′. Thus, the proposed protocol provides security against the vehicle impersonation assault.(2)
TAimpersonation attack: similarly, an E tries to instigate a forgery toward VS on the behalf of TA. For this purpose, E needs to construct the M2′ such as M2′=MSG2,X2 with updated nonce Nu′ and timestamp Tc′ and also requires some confidential parameters such as Tc, Nu, Tu, and Ks secret keys. It is a computationally hard problem to compute these parameters from previously intercepted message MSG2 and X2. Thus, the proposed protocol also provides security against TA impersonation assault.(3)
VSimpersonation attack: in the case of VS impersonation assault, when E launches an assault on VS toward TA, it also needs to design the message M3′ with an updated nonce Nu′ and new timestamp Tc′, where M3′=MSG3′,X3′,Ts′, MSG3′=EhNs‖Ts, and X3′=hNu′‖Ns′‖Ks′‖Ts′. However, the attacker may not be able to construct the valid message parameters in M3′, until granted the valid secret key Ks. Thus, E cannot impersonate the VS, and the proposed scheme provides security to VS impersonation assault.


## 7.2.3. Stolen SC Attack

Suppose ifE steals the smart card and obtains all confidential credentials {a1,b1,EVIDi} using a power analysis attack (PWA) [33]. E tries to compute MSG1, X1, and EVIDi. However, E requires the knowledge of DPWi=hPWiYi, whereas the E does not hold a hash function, which is not convertible. Thus, E cannot recover the password, and the stolen smart card cannot be accessible.


## 7.2.4. Session Key Security

The trusted authority and vehicle server both verify the value of nonceNs, Tu, Ts, and Nu that are used to compute the secret key value Sk=hNsNuTuTs. This process ensures the originality of the session key. Thus, session key security is ensured.


## 7.2.5. Anonymity and Untraceability

In the phase of mutual authentication, the proposed security scheme utilizes random nonceNu, ri, and Tu, as well as timestamp Tu, Tc, and Ts in communication messages MSG1–MSG3. In the communication scenario, E may not differentiate among the messages of the different sessions, which publicly render the proposed scheme untraceable. At the same time, the E may not identify the vehicle identity, since the messages employ pseudoidentities, i.e., EVIDi, EVIDinew, and FVIDi and again replace EVIDinew into EVIDi in the messages instead of original identities, that are enclosed under the rigidity of a one-way hash function-bearing collision resistance characteristic. Thus, the proposed scheme maintains the untraceability and anonymity characteristics.


## 7.2.6. Man-in-the-Middle Attack

IfE want to launch the man-in-the-middle assault, it is required to build the message M′ i.e., M1′=MSG1,EVIDi,Tu,X1,SID where MSG1=ha1‖Tu‖DPWi‖Nu, X1=Nu⊕VIDi, and EVIDi=EKsVIDi‖Yta. However, to meet the goal, the attacker needs to build those message parameters with updated nonce Nu and timestamp Tu, which are not possible until E has access to Ks, EVIDi, and DPWi. Likewise, E is not able to rebuild other messages such as MSG1–MSG3 in the protocol with updated nonce and timestamp without having access to important parameters in possession with those participating entities. Therefore, the proposed scheme provides security against the man-in-the-middle assault.


## 7.2.7. Off-Line Password Guessing Attack

It is proven that the proposed scheme is infeasible forE to get the identity of Di, even after extracting the parameters. Suppose if E has access to a smart card, which contains {EVIDi,a1,b1,h.,Yi}, the parameters can be obtained by using the PWA [33]. However, assaults cannot compute the Ks and, ultimately, PWi from DWPi. The E has only one way to acquire the PWi from MSG1 without breaching the noninvertible characteristics of the cryptography hash function.


## 7.2.8. Replay Attack

In the proposed security scheme, various entities such asVi, TA, and VS exchange the messages from MSG1 to MSG3 and utilize the timestamp Tu, Tc, and Ts to encounter the possible replay assault. At the same time, mutual authentication is required for communication. The messages need to be replied to in a short period of timestamp T to abolish the possibility of E manipulating the messages and initiating replay assault. Without updating the parameters MSG1, X1, EVIDi, MSG2, X2, MSG3, X3, W, X4, and FVIDi, the updated timestamp cannot be utilized. At the same time, the parameters need to be updated with the new timestamp, whereas the E requires access to VIDi identity and password, and other shared parameters between Vi, TA, and VS. Thus, the replay assault does not happen in the proposed scheme.


## 7.2.9. Denial of Service (DoS) Attack

The proposed scheme provides security against DoS assault as theSC in the start authenticate Vi such as EVIDi=HVIDiYta. This condition will only be legal if Vi enters the correct identity VIDi and password DPWi; after the insertion of the valid identity and password, the parameters are computed in SCVIDiYta=EksEVIDi. The authentication of Vi is done locally at the vehicle’s side. After that, a request is sent to TA for authentication. The same process is followed in the password and update phases to protect the incorrect modification of these parameters. Thus, the scheme prevents DoS assault.


## 8. Security and Performance Analysis

Under this section, the security features, computation cost, and communication cost of the proposed scheme with relation to other schemes are described [2, 25, 30, 34].


### 8.1. Security Features

Table3 provides a detailed overview of security comparisons of our proposed scheme in relation to other schemes [2, 25, 30, 34]. In Table 3, the proposed scheme acquires the required attributes associated with pragmatic security under the DY model described in Section 2.2. At the same time, Vasudev et al.’s scheme [2] is incorrect and cannot fulfill the authentication as evinced in Section 5. In Vasudev et al.’s scheme [2], TA cannot identify the vehicle identity if more than one vehicle communicates to TA. This scheme also only works when one registered vehicle is in the system. Vasudev et al.’s scheme [2] is insecure against the man-in-the-middle attack. Additionally, the scheme of Mohit et al. [34] also failed to provide security against man-in-the-middle and DoS attacks. Kumari et al.’s scheme [25] is also insecure against the man-in-the-middle, offline password guessing, and DoS attacks. Zhou et al.’s scheme [30] failed to provide security against the impersonation attack such as (Vi,TA,VS) and is also insecure against the man-in-the-middle, offline password guessing, replay, and DoS attacks.Table 3
Security analysis.
SchemesOurs[2][34][25][30]Correctness✓✗✓✓✓Vehicle impersonation attack✓✓✓✓✗Trusted authority impersonation attack✓✓✓✓✗Vehicle server impersonation attack✓✓✓✓✗Stolen SC attack✓✓✓✓✓Anonymity attack✓✓✓✓✓Untraceability attack✓✓✓✓✓Man-in-the-middle attack✓✗✗✗✗Off-line password guessing attack✓✓✓✗✗Replay attack✓✓✓✓✗Mutual authentication✓✓✓✓✓DoS attack✓✓✗✗✗Note: ✓: provides or resists; ✗: does not provide or does not resist.


### 8.2. Computation Cost

We adopted the running times computed in [35] over a Pi-3:B+64-bit-Cortes A5-3:ARM-v8, SoC:1.4 GHz processor, and 1 GB LPDDR2-SDRAM. We denote Tbe, Th, and T⊕ as the symbols representing symmetric block encryption, hash, and exclusive or operations, respectively. Implying the experiment conducted in [35], the Tbe furnishes in 0.013 ms, the running time of Th is 0.006, while T⊕ takes negligible time to complete its execution, and therefore, T⊕ is being ignored in the comparisons. We used AES-128-bit block for encryption, and each identity and random numbers are of 64-bit size. Therefore, an encryption block can convert two parameters (identity/random number) into cipher text. The proposed scheme executes 14Th+14Tbe operations with a running time of 0.266 ms. Table 4 shows the computation cost comparisons of the proposed and related schemes [2, 25, 30, 34]. The proposed scheme has a slight extra computation cost as compared with the other schemes [2, 25, 30, 34].Table 4
Performance comparisons.
SchemeComputation costRT (ms)MEBESCOurs14Th+14Tbe0.26641824512Vasudev et al. [2]16Th0.09641696384Mohit et al. [34]19Th0.11441760864Kumari et al. [25]12Th0.07231056608Zhou et al. [30]16Th0.09631604544Note: RT: running time; ME: no. of message exchanges; BE: bit exchange: SC: storage cost in bits.


### 8.3. Communication Cost

To calculate the fair and pragmatic communication cost comparisons of the proposed scheme with related other schemes, we adopted 160-bit SHA-1, timestamps, random numbers, and identities which are considered to be 64 bits of length. We simulated the AES block cipher with 128-bit output. Thus, in the proposed scheme, communication cost is computed following the previously mentioned parameter values. The authentication cycle of the proposed scheme finishes through the exchange of four messages. In message 1,EVIDi,MSG1,X1,Tu,SID=128+160+160+64+64=576 bits are sent from Vi to TA. In message 2, MSG2,X2,Tc=160+160+64=384 bits sent from TA to VS.In message 3,MSG3,X3,Ts=160+160+64=384 bits are directed from VS to TA, and the transmission of message 4 {X4,W,FVIDi} requires transmission of 160+160+160=480 bits from TA to Vi. Thus, total communication cost of the authentication phase of the proposed scheme is 576+384+384+480=1824 bits. Referring to Table 4, the communication cost of the proposed scheme is higher than other schemes [2, 25, 30, 34]; however, other scheme do not provide one or more security features.


### 8.4. Storage Cost

To calculate the storage cost of the proposed scheme, we took into account the parameters stored in the memory of the vehicle. The three parameters stored are the hash output, random numbers, and block-based symmetric encryption. Due to usage of SHA-1, the hash output value is 160 bits, the size of the random nonce is 64 bits, and the size of AES-128 encryption is 128 bits. Thus, the storage cost of the proposed scheme isa1+b1+EVIDi+Ci=160+160+128+64=512 bits. Table 4 shows the storage cost of the proposed scheme and other schemes [2, 25, 30, 34]. The storage cost of the proposed scheme is lower than the schemes in [25, 30, 34]; however, the storage cost of the proposed scheme is a bit higher than the scheme in [2], and we proved that Vasudev et al.’s scheme design is incorrect and cannot work in practical environments.


## 8.1. Security Features

Table3 provides a detailed overview of security comparisons of our proposed scheme in relation to other schemes [2, 25, 30, 34]. In Table 3, the proposed scheme acquires the required attributes associated with pragmatic security under the DY model described in Section 2.2. At the same time, Vasudev et al.’s scheme [2] is incorrect and cannot fulfill the authentication as evinced in Section 5. In Vasudev et al.’s scheme [2], TA cannot identify the vehicle identity if more than one vehicle communicates to TA. This scheme also only works when one registered vehicle is in the system. Vasudev et al.’s scheme [2] is insecure against the man-in-the-middle attack. Additionally, the scheme of Mohit et al. [34] also failed to provide security against man-in-the-middle and DoS attacks. Kumari et al.’s scheme [25] is also insecure against the man-in-the-middle, offline password guessing, and DoS attacks. Zhou et al.’s scheme [30] failed to provide security against the impersonation attack such as (Vi,TA,VS) and is also insecure against the man-in-the-middle, offline password guessing, replay, and DoS attacks.Table 3
Security analysis.
SchemesOurs[2][34][25][30]Correctness✓✗✓✓✓Vehicle impersonation attack✓✓✓✓✗Trusted authority impersonation attack✓✓✓✓✗Vehicle server impersonation attack✓✓✓✓✗Stolen SC attack✓✓✓✓✓Anonymity attack✓✓✓✓✓Untraceability attack✓✓✓✓✓Man-in-the-middle attack✓✗✗✗✗Off-line password guessing attack✓✓✓✗✗Replay attack✓✓✓✓✗Mutual authentication✓✓✓✓✓DoS attack✓✓✗✗✗Note: ✓: provides or resists; ✗: does not provide or does not resist.


## 8.2. Computation Cost

We adopted the running times computed in [35] over a Pi-3:B+64-bit-Cortes A5-3:ARM-v8, SoC:1.4 GHz processor, and 1 GB LPDDR2-SDRAM. We denote Tbe, Th, and T⊕ as the symbols representing symmetric block encryption, hash, and exclusive or operations, respectively. Implying the experiment conducted in [35], the Tbe furnishes in 0.013 ms, the running time of Th is 0.006, while T⊕ takes negligible time to complete its execution, and therefore, T⊕ is being ignored in the comparisons. We used AES-128-bit block for encryption, and each identity and random numbers are of 64-bit size. Therefore, an encryption block can convert two parameters (identity/random number) into cipher text. The proposed scheme executes 14Th+14Tbe operations with a running time of 0.266 ms. Table 4 shows the computation cost comparisons of the proposed and related schemes [2, 25, 30, 34]. The proposed scheme has a slight extra computation cost as compared with the other schemes [2, 25, 30, 34].Table 4
Performance comparisons.
SchemeComputation costRT (ms)MEBESCOurs14Th+14Tbe0.26641824512Vasudev et al. [2]16Th0.09641696384Mohit et al. [34]19Th0.11441760864Kumari et al. [25]12Th0.07231056608Zhou et al. [30]16Th0.09631604544Note: RT: running time; ME: no. of message exchanges; BE: bit exchange: SC: storage cost in bits.


## 8.3. Communication Cost

To calculate the fair and pragmatic communication cost comparisons of the proposed scheme with related other schemes, we adopted 160-bit SHA-1, timestamps, random numbers, and identities which are considered to be 64 bits of length. We simulated the AES block cipher with 128-bit output. Thus, in the proposed scheme, communication cost is computed following the previously mentioned parameter values. The authentication cycle of the proposed scheme finishes through the exchange of four messages. In message 1,EVIDi,MSG1,X1,Tu,SID=128+160+160+64+64=576 bits are sent from Vi to TA. In message 2, MSG2,X2,Tc=160+160+64=384 bits sent from TA to VS.In message 3,MSG3,X3,Ts=160+160+64=384 bits are directed from VS to TA, and the transmission of message 4 {X4,W,FVIDi} requires transmission of 160+160+160=480 bits from TA to Vi. Thus, total communication cost of the authentication phase of the proposed scheme is 576+384+384+480=1824 bits. Referring to Table 4, the communication cost of the proposed scheme is higher than other schemes [2, 25, 30, 34]; however, other scheme do not provide one or more security features.


## 8.4. Storage Cost

To calculate the storage cost of the proposed scheme, we took into account the parameters stored in the memory of the vehicle. The three parameters stored are the hash output, random numbers, and block-based symmetric encryption. Due to usage of SHA-1, the hash output value is 160 bits, the size of the random nonce is 64 bits, and the size of AES-128 encryption is 128 bits. Thus, the storage cost of the proposed scheme isa1+b1+EVIDi+Ci=160+160+128+64=512 bits. Table 4 shows the storage cost of the proposed scheme and other schemes [2, 25, 30, 34]. The storage cost of the proposed scheme is lower than the schemes in [25, 30, 34]; however, the storage cost of the proposed scheme is a bit higher than the scheme in [2], and we proved that Vasudev et al.’s scheme design is incorrect and cannot work in practical environments.


## 9. Conclusion

Primarily, this study reviewed some of the recent V2V authentication schemes. The paper is aimed at openly discussing the faulty design of the V2V mutual authentication scheme of Vasudev et al. We proved that the design of the scheme of Vasudev et al. is incorrect, and it cannot work practically. Moreover, we introduced an improvement over the scheme of Vasudev et al. The robustness of the proposed scheme is formally proven through BAN-logic. The proposed security scheme provides mutual authentication between a vehicle and the vehicle server through intermediation of a trusted authority. We also provided security discussion and proved that the proposed scheme provides resistance against various security assaults and provides essential security features. The execution time of a cycle of authentication of the proposed scheme is slightly over the execution time of Vasudev et al.’s scheme. The comparisons with some of the related and recently proposed schemes also show that the proposed scheme provides known security features and resistance to known attacks, while the compared schemes lack one or more security features.



---

*Source: 3400558-2021-11-23.xml*