A Noval and Efficient Three-Party Identity Authentication and Key Negotiation Protocol Based on Elliptic Curve Cryptography in VANETs

Abstract

In the process of vehicles transitioning from conventional means of transportation to mobile computing platforms, ensuring secure communication and data exchange is of paramount importance. Consequently, identity authentication has emerged as a crucial security measure. Specifically, effective authentication is required prior to the communication between the On-Board Unit (OBU) and Roadside Unit (RSU). To address vehicle identity authentication challenges in the Internet of Vehicles (VANETs), this paper proposes a three-party identity authentication and key agreement protocol based on elliptic curve public key cryptography. Considering issues such as vehicle impersonation attacks, RSU impersonation attacks, and vehicle privacy breaches in existing schemes within wireless mobile environments, this protocol introduces a trusted registry center that successfully enables mutual authentication between OBU and RSU. The proposed protocol not only enhances the VANETs system’s ability to withstand security threats but also improves the credibility and efficiency of the authentication process.

1. Introduction

The rapid advancement of computing technologies and the widespread implementation of communication mechanisms have facilitated the development of connected vehicles, which are revolutionizing the automotive field at a fast pace. Simultaneously, global urbanization and increasing traffic flow pose challenges to transportation systems, including congestion, accidents, pollution, and energy wastage [1,2,3,4]. To address these issues effectively, VANETs technology integrates a network system by establishing connections among vehicles, individuals, and sensing devices to enable bidirectional data transmission. Its functionalities [5] encompass information sharing, vehicle safety management, condition monitoring, driving behavior analysis, real-time traffic management as well as intelligent road network planning. Despite its potential for significant enhancements in vehicle safety standards along with improved driving comfort and energy efficiency levels; however, VANETs’s widespread adoption necessitates addressing concerns related to communication security and vehicle privacy [6,7,8,9].

In the VANETs, identity authentication serves as a pivotal measure to ensure system security. By implementing effective authentication mechanisms, unauthorized vehicles can be prevented from accessing the network, thereby effectively mitigating information leakage and potential malicious activities. This endeavor not only aids in establishing a trusted vehicle communication environment but also assumes a crucial role in transportation coordination and intelligent scenarios. Simultaneously, it guarantees that vehicle communication and cooperation are founded on reliable identities, thus enhancing the overall security and reliability of the entire VANETs system.

1.1. Related Works

In the realm of VANETs, the pertinent technologies for implementing an identity authentication scheme can be categorized into three distinct groups: identity authentication schemes based on Public Key Infrastructure (PKI) [10,11]; batch identity authentication schemes [12,13,14,15,16,17,18]; blockchain-based authentication schemes [19,20,21,22]; and identity authentication scheme in multiserver architecture [23].

Currently, the prevailing authentication scheme in the field of Internet of Vehicles is based on Public Key Infrastructure (PKI). Xiong et al. [10] proposed a lightweight authentication protocol utilizing hash functions and exclusive OR operations, which is suitable for VANETs communication model. However, this scheme relies on a trusted third party (TA) during the authentication process, limiting its service coverage when TA is offline. Shohei et al.’s Meta-PKI [11], on the other hand, establishes trust relationships between certificate authorities outside the blockchain to construct an authentication path uniformly while leveraging blockchain technology to expedite certificate configuration and ensure path validity. However, this method solely utilizes edge connection state for building certification paths and suffers from limitations due to cross-certification and policy reasons, resulting in potential invalidity of some public key certificates. Furthermore, this scheme presents challenges such as high processing load for PKI clients and complexity in managing constraints and policies associated with them. Although PKI has made significant progress in enhancing verification efficiency, it also reinforces reliance on trust centers and increases system management complexity.

In order to provide a scheme for identity batch authentication, Tzeug et al. [12] proposed an identity-based anonymous batch authentication scheme with strong privacy protection that utilizes a tamper-proof device to store the system master key. By allowing vehicles to generate dynamic pseudonym identities before communicating with the RSU, it becomes difficult for attackers to determine whether different messages are sent by the same vehicle, effectively reducing the risk of vehicle tracking and solving complex replacement issues. Zhang et al. [13] proposed an identity-based batch authentication scheme for VANETs that does not require certificates on vehicles and provides a method for authenticating multiple messages simultaneously, significantly improving message verification efficiency; however, this scheme has limitations in resisting replay attacks and impersonation attacks. Lu et al. [14] proposed a V2I (vehicle-to-infrastructure) communication batch authentication scheme that is vulnerable to tampering attacks [24]. Chim et al. [15] improved upon Zhang et al.’s [13] work by providing anonymity for VANET users while having lower computational overhead; however, it still has limitations in effectively resisting impersonation attacks. Additionally, Azees et al.’s efficient anonymous authentication scheme prevents malicious vehicles from entering VANETs [16]. Zhou et al.’s [17] security-enhanced solution introduced in 2022 can resist signature forgery attacks in VANETs while further ensuring vehicle identity privacy; furthermore, Zhang et al.’s trust currency called TCoin was introduced as an anonymous reporting mechanism in VANETs [18]. Although these schemes have improved authentication efficiency, they still need further optimization to improve antiattack capabilities.

To establish a more secure and privacy-preserving authentication mechanism for the VANETs, several blockchain-based authentication schemes have been proposed. The BUA authentication protocol, introduced by Liu et al. [19], enables vehicles to generate multiple pseudonyms; however, this scheme lacks an effective revocation mechanism against malicious vehicles as the pseudonyms are verified based on specific blocks. Feng et al. [20] designed a blockchain-assisted privacy-preserving authentication system that utilizes smart contracts to record and revoke vehicle pseudonyms and public keys. Nevertheless, each authentication process requires querying the blockchain manager, resulting in significant verification overhead. Zheng et al. [21] proposed an innovative multi-TA network authentication protocol along with a multiserver network authentication protocol to distribute authentication tasks, reducing workload for individual entities and enhancing user authentication efficiency. Additionally, Chai et al.’s [22] blockchain-based authentication framework transmits physical vehicle data to cyberspace through RSUs while establishing blockchains in third-party systems instead of executing consensus processes on physical nodes—aiming to create a lightweight blockchain that safeguards vehicle privacy and security while minimizing creation and maintenance costs. Although these schemes offer more effective options for identity verification in VANETs, they still face challenges related to insufficient revocation mechanisms and high verification overhead, thus, necessitating finding a balance between security and efficiency.

In the identity authentication system designed for multiserver architecture, the registry is responsible for user and server registration as well as generating master keys. Within the unified registration and authentication model, users only need to register once at the central registration center, enabling them to log in to all servers managed by the center and access corresponding network resources and services. When implementing identity authentication mode schemes under a multiserver architecture, there are primarily two types: two-party authentication mode and three-party authentication mode [25]. As a fundamental component of more complex high-level protocols, designing a secure and efficient identity authentication and key agreement protocol suitable for multiserver architecture is currently an active research area. The protocol must fulfill security requirements against impersonation attacks, password guessing attacks, known key attacks, replay attacks, etc., ensuring user privacy and forward security of the scheme [26,27]. In 2021, Chen et al.’s [23] scheme effectively resolved forgery issues along with adaptive chosen message attacks; nevertheless, its drawback lies in a high total cost of signature verification, which may impact network performance in dense scenarios. Overall, the research direction of multiserver authentication systems continues to be positive. However, researchers face quite complex challenges in balancing security and system efficiency and improving the ability to resist various attacks.

In the network environment, mutually authenticated entities are usually distributed in different physical locations, and there is a relationship between each other. In order to solve this problem, the second “what to have” and the third “what to know” technical means are widely used. Through the scheme proposed in this paper, the close connection between OBU, RSU and RC is established successfully, and the communication cost of the client is reduced through RC.

1.2. Motivation

To ensure reliable and secure communication services for the VANETs, while maintaining identity reliability and effectively protecting vehicle user privacy, numerous security protocols have been proposed by researchers. However, these protocols suffer from several limitations. For instance, the PKI-based identity authentication scheme proposed by Xiong et al. [10] proposed a lightweight authentication protocol that was suitable for the VANET communication model and effectively improved authentication efficiency; however, this scheme relied excessively on third parties. In the batch identity authentication scheme introduced by Zhang et al. [13], a method for simultaneous authentication of multiple messages without storing certificates on vehicles is proposed; however, it overlooks potential threats such as replay attacks and impersonation attacks. Furthermore, Feng et al.’s blockchain-based identity authentication scheme [20] utilizes smart contracts to record and revoke pseudonyms and public keys but significantly increases system overhead. Existing remote authentication schemes applicable to multiserver wireless mobile environments also face challenges in resisting vehicle impersonation attacks, RSU impersonation attacks, and vehicle privacy leakage issues. This paper introduces a trusted third party into the authentication process to achieve mutual authentication between vehicles and RSUs while ensuring high computational efficiency for vehicles—thus further enhancing security during VANETs communication.

1.3. Contributions

The main contributions of this paper are as follows:

Introduction of trusted third parties: The paper introduces a trusted third party (registration center RC) to actively participate in the specific authentication process, thereby achieving mutual authentication between OBU and RSU. This approach effectively mitigates security risks without introducing additional storage complexity to the intelligent terminal.

Eliminate duplicate registration: The identity authentication and key agreement protocol proposed in this paper within a multiserver architecture achieves the elimination of repetitive registration for vehicle users with each RSU, enabling unified management, authentication, and authorization of vehicles.

Efficient certification: The authentication protocol proposed in this paper demonstrates robust security across various attack scenarios while exhibiting efficient computational performance and occupying relatively minimal system memory space.

2. System Model and Preliminary

2.1. System Model

The present paper proposes an elliptic curve cryptography-based multiserver authentication and key agreement protocol for the VANET. The network model comprises three primary entities: RC, OBU, and RSU. Wired communication serves as the mode of communication between RSU and RC.

The OBU serves as the fundamental component of VANETs technology, being installed within vehicles to facilitate intervehicle and infrastructure communication, vehicle data collection and transmission, as well as real-time traffic information reception. These functionalities are achieved through integrated communication modules such as Bluetooth, Wi-Fi, GSM, LTE, 5G, among others.

The RSU, also known as the roadside unit, plays a pivotal role in VANETs technology and is typically deployed alongside roadways or at traffic intersections. It serves as a crucial link between vehicles and the transportation infrastructure, facilitating data exchange with on-board devices through wireless communication technologies such as Wi-Fi, LTE, 5G, etc.

The RC refers to the Registration Center, which serves as a fully trusted third party capable of withstanding various security attacks. Its primary role within this system involves generating essential parameters, such as a suitably large prime number for a well-constructed elliptic curve and constructing the system’s master key to establish the public key. Additionally, RC acts as an intermediary facilitating communication between RSU and OBU.

The registry enables verification and authorization of vehicles and infrastructure, ensuring the validity and trustworthiness of both parties’ identities. This mechanism differs from mutual authentication between OBU and RSU as it relies on a neutral entity for verification, reducing communication complexity and alleviating system configuration and maintenance burdens. Moreover, the third-party registry offers enhanced flexibility by allowing vehicles to access multiple applications and services using the same authentication credentials, simplifying operational processes while improving convenience and efficiency of communication. Additionally, this solution leverages advanced security features provided by registries, such as multifactor authentication, to enhance communication security while mitigating potential risks. The network model diagram is depicted in Figure 1.

However, in terms of security certification, the presence of an RC may introduce a single point of failure in the system, making it susceptible to potential large-scale monitoring. If an RC were to fail, it would impact the associated authentication process, rendering the entire system vulnerable. To counter this challenge, the implementation of multinode backup and load-balancing strategies is proposed. This ensures a seamless transition to a standby RC, thereby minimizing the risk associated with a single point of failure. Simultaneously, decentralizing the authentication process serves as an effective measure to mitigate potential threats posed by mass surveillance to the overall system.

2.2. Preliminary

2.2.1. Elliptic Curve Public Key Cryptosystem

Elliptic Curve Cryptography (ECC) is an algorithm for public key encryption which leverages the mathematical principle of elliptic curves. In comparison to traditional cryptographic algorithms such as RSA, ECC offers enhanced performance at an equivalent security level and requires smaller key sizes. Consequently, it finds wider applicability in resource-constrained environments such as mobile devices and IoT devices.

The fundamental principle of ECC lies in leveraging the addition and multiplication operations on points residing on an elliptic curve to facilitate the generation of public and private keys, data encryption and decryption, as well as digital signature and other cryptographic operations. Its security is rooted in the discrete logarithm problem associated with elliptic curves, which involves finding a point $P$ on the curve such that $k\times P=Q$, where $k$ represents the private key while $Q$ denotes the public key. Given this problem’s computational infeasibility under elliptic curve settings, deriving the private key from its corresponding public key ensures ECC’s robust security.

The elliptic curve group $E_p(a,b)$ is defined by the nonsingular equation $E$ over a prime finite field $F_p$ as shown in Formula (1), where $p$ represents a prime number.

$$y^2=x^3+ax+b\left(mod p\right), a,b\in F_p, ∆=4a^3+27b^{2}mod p\ne 0$$

(1)

Lemma 1

(Elliptic Curve Discrete Logarithm Problem (ECDLP)). Given a fixed point $G\in E_p\left(a,b\right)$ and $P=KG\in E_p\left(a,b\right)$, the computation of $k\in Z_q^{*}$ for the discrete logarithm problem exhibits both ease and difficulty.

Lemma 2

(Elliptic Curve Diffie–Helman Problem (ECDHP)). The security of the ECDHP key exchange system relies on the computational intractability of solving the Elliptic Curve Discrete Logarithm Problem (ECDLP). Given $G,xG,yG\in E_p\left(a,b\right)$, computing $xyG\in E_p\left(a,b\right)$ is considered to be a highly challenging task.

2.2.2. Authentication Mode in Multiserver Architecture

The utilization of third-party authentication mitigates the risks associated with identity theft and fraud by incorporating advanced security features, such as multifactor authentication. Moreover, it ensures adherence to stringent security standards and supervision, alleviates the burden of user authentication, enhances user-friendliness, and effectively reduces computational complexity.

The multiserver architecture described in this paper refers to the sharing of information sent by vehicles among multiple RSUs, eliminating the need for repetitive vehicle registration with each RSU. This approach enables unified management, authentication, and authorization of vehicle information. The authentication system based on the multiserver architecture primarily consists of two modes: two-party authentication and three-party authentication. In three-party authentication, an independent third-party agency is involved to verify the identity of individuals or entities. The chosen intermediary possesses the expertise and resources necessary for assuming responsibility for authentication while ensuring the validity of trusted identities for both parties involved. Compared to mutual authentication, third-party authentication simplifies the system complexity by eliminating the requirement for configuring encryption infrastructure like digital certificates. It streamlines the identity verification process and reduces costs and technical difficulties associated with it. Additionally, third-party authentication offers greater flexibility as users can utilize their credentials across multiple applications and services, thereby enhancing user convenience and experience. The third-party authentication mode is illustrated in Figure 2.

2.3. Security Requirements

The existing authentication and key agreement schemes applicable in the V2I environment fail to withstand vehicle impersonation attacks, RSU impersonation attacks, and vehicle privacy leakage in the Internet of Vehicles. To address these issues, this paper proposes the integration of a trusted registry into the authentication process, enabling mutual authentication between vehicles and roadside units. Consequently, an identity authentication and key agreement protocol for VANETs should satisfy the following security requirements:

• Ensuring message authentication and integrity. When receiving a message, both the vehicle and the RSU must authenticate the identity of the sender and verify whether the received message is indeed from the original sender;
• Session key agreement. The vehicle and RSU can establish a secure session key, which is then utilized to encrypt subsequent sessions in order to ensure the confidentiality of the sessions;
• Privacy protection. In light of the growing emphasis on privacy protection, VANETs must incorporate robust measures to safeguard sensitive vehicle information, including identity, session records, and driving location. The protocol should ensure that no privacy information can be extracted by potential attackers;
• Can effectively withstand various types of security attacks. The security of VANETs is susceptible to a range of attacks, including impersonation and replay attacks. Therefore, it is imperative for the authentication scheme to possess robust resistance against diverse security threats in order to ensure its reliability and effectiveness.

3. Our Proposed Scheme

The present paper proposes an elliptic curve cryptography-based multiserver authentication and key agreement protocol for the VANETs. This protocol adopts a third-party authentication mode to address the issues of high system overhead and vulnerability against impersonation attacks found in existing protocols without introducing additional storage and computational complexity to the vehicle terminal. In this protocol, both the vehicle and roadside unit possess distinct keys, thereby increasing the registration process for RSU. The protocol comprises five phases: roadside unit registration phase, vehicle registration phase, vehicle login phase, authentication and key agreement phase, and password upgrade phase. Figure 3 illustrates the system process framework of this scheme.

3.1. System Initialization Phase

The registry RC initially generates a large prime number $p$ and constructs an elliptic curve with desirable properties, carefully selecting a generator $P$ of order $p$. Subsequently, the registry RC proceeds to choose a low entropy random number $sr\in Z_p$ as the system’s master key, generating the parameter $Q=sr\times P\left(mod p\right)$, and publicly disclosing the public parameter $\{Q,P\}$. The identifiers utilized are presented in

Table 1. Common identifiers.

Identification	Instructions
$OB{U}_i$	A vehicle unit
$RS{U}_i$	Some roadside unit
$RC$	Registry
${ID}_i$	User identity
$SI{D}_j$	Server identification
${PW}_i$	User password
$x$	The master key of the system
$SK$	Session key
$E_k\left(M\right)$	The message M is encrypted with key K
$D_k\left(C\right)$	Indicates that key K decrypts ciphertext C
$\Vert$	String concatenation symbol
⊕	Xor operation

.

3.2. Roadside Unit Registration Phase

The roadside unit $RS{U}_i$ is required to register at the registration center RC to provide network resources to vehicle users through the registration center RC. The proposed multiserver identity authentication and key agreement protocol, based on three-party authentication, offers flexibility and scalability. It allows any RSU to register at any time, eliminating the need for an application process during the initialization phase of the authentication system. Initially, $RS{U}_i$ selects its own identity $SI{D}_j$ and formulates a plaintext registration request that is transmitted through the authentication channel to the registration center RC. Upon receiving this request, registry RC performs further calculations $s_j=H(SI{D}_j\Vert sr)$, which are then securely transmitted back to $RS{U}_i$ via a security channel. Upon receipt of $s_j$, $RS{U}_i$ stores it successfully completing the registration process. Finally, $RS{U}_i$ announces its identity $SI{D}_j$ to vehicle users, as depicted in Figure 4 and Algorithm 1.

Algorithm 1 ${RSU}_i$ registration

Input: ${SID}_{\mathrm{j}}$;

Output: $s_j$;

1: $s_j=H(SI{D}_j\Vert sr)$;

2: return ${\mathrm{RSU}}_{\mathrm{j}}\leftarrow \left(s_{\mathrm{j}}\right);$

3.3. Vehicle Registration Phase

The vehicle users can register at any time to acquire the corresponding access rights. Initially, the first vehicle user selects $OB{U}_i$ identity $I{D}_i$ and $P{W}_i$ passwords, followed by generating a random number $t\in Z_p$ for calculating the hash value of the implicit vehicle user password $RP{W}_i=H(P{W}_i\Vert t)$. Subsequently, $OB{U}_i$ sends the registration request and $\{I{D}_i$,$RP{W}_i\}$ to the registration center RC in plaintext form through channel authentication. Upon receiving the vehicle user requests, the registry generates random numbers $R_i\in Z_p$ and calculates ${RID}_i$ = $H({ID}_i\Vert R_i)$, $K_i=H({RID}_i\Vert sr)$, $A_i=K_i\oplus H({ID}_i\Vert {RPW}_i)$, $B_i=H\left(K_i\right)$. Following this, the registration center RC transmits authentication information $\left\{A_i,B_i,P,Q,H\left(·\right),E_k\right\}$ to the vehicle terminal. The detailed process of RC authentication for registry is illustrated in Figure 5 and Algorithm 2.

Algorithm 2 ${OBU}_i$ registration

Input: ${\mathrm{ID}}_{\mathrm{j}}$, ${\mathrm{PW}}_i$,${SID}_j$;

Output: $A_i,B_i,P,Q,H\left(·\right),E_k,t$;

1: $t\in Z_N^{*}$; //generate a random number

2: $RP{W}_i=H(P{W}_i\Vert t)$;

3: if (${\mathrm{ID}}_{\mathrm{j}}\in {\mathrm{Z}}_{\mathrm{N}}^{*})$ then

4:  $R_i\in {\mathrm{Z}}_{\mathrm{N}}^{*}$;

5:  ${RID}_i$ = $H\left({ID}_i\right|\left|R_i\right);$

6:  $K_i=H\left({RID}_i\right|\left|sr\right);$

7:  $A_i=K_i\oplus H\left({ID}_i\right|\left|{RPW}_i\right);$

8:  $B_i=H\left(K_i\right);$

9: else return null;

4: return $OB{U}_i\leftarrow (A_i,B_i,P,Q,H\left(·\right),E_k,t);$

Finally, the $OB{U}_i$ of the vehicle user appends a randomly selected number $t$ to the received information $\{A_i,B_i,P,Q,H\left(·\right),E_k,t\}$, marking the end of the registration process for the vehicle user.

3.4. Vehicle Login Phase

When the $OB{U}_i$ of the vehicle user executes the local verification module, it first needs to input its $I{D}_i$ and corresponding password $P{W}_i$. Subsequently, $OB{U}_i$ computes $K_i=A_i\oplus H(I{D}_i\Vert H(P{W}_i\Vert t\left)\right)$, $B_i^{\mathrm{*}}=H\left(K_i\right)$, and transmits $\left\{B_i^{\mathrm{*}}\right\}$ to RC for validation against the stored check information $B_i^{\mathrm{*}}=B_i$. In case of an invalid equation, RC returns an “error” prompting $OB{U}_i$ to re-enter incorrect identity and password details. If successful, RC responds with a “pass”. Consequently, $OB{U}_i$ generates a random number $\mathsf{\alpha }\in Z_p$ and calculates $X=\mathsf{\alpha }\times P$, $X^{\prime }=\mathsf{\alpha }\times Q,CI{D}_i=E_{H\left(X^{\prime }\right)}(RI{D}_i,H(K_i\Vert SI{D}_j\left)\right)$. Finally, $OB{U}_i$ sends the login request message $\left\{CI{D}_i,X\right\}$ through a public network channel to interface ${RSU}_i$ where the vehicle user intends to log in.

3.5. Authentication and Key Agreement Phase

After receiving $OB{U}_i$’s login request, $RS{U}_i$ initiates a response and completes the identity authentication of $OB{U}_i$ with the assistance of RC registry. The session key for encrypting data transmission between the vehicle user and $RS{U}_i$ is generated. The registry cannot recover the negotiated session key. $RS{U}_i$ randomly selects $\mathsf{\beta }\in Z_p$, calculates $Y=\mathsf{\beta }\times P$, $M_j=H(X\Vert Y\Vert s_j\Vert SI{D}_j)$, $V_j=E_{sj}\left(M_j,CI{D}_i,X,Y\right)$, and then sends $\left\{SI{D}_j,V_j\right\}$ to the RC registry. Upon receiving the message from RSU, RC computes $s_j=H({SID}_j\Vert sr)$ and decrypts $V_j$ using $s_j$ to obtain ${\{M}_j,{CID}_i,X,Y\}$. Next, RC computes $M_j^{\prime }=H(X\Vert Y\Vert s_j|{|SID}_j)$ and compares it with $M_j$. If they match, it confirms that ${RSU}_i$ is a legitimate roadside unit and proceeds to the next step; otherwise, RC rejects further operations and returns an error. Subsequently, RC continues by computing $H(sr\times X)$ to extract $CI{D}_i$ as a parameter in $\{RI{D}_i,H(K_i\Vert SI{D}_j\left)\right\}$. Then it calculates $K_i=H\left(RI{D}_i\right|\left|sr\right),H(K_i\Vert SI{D}_j)$, and verifies whether $H(K_i\Vert SI{D}_j)$ exists in the decamping parameters. If verification fails, the registry terminates the session with “Vehicle Verification Failed”. Otherwise, the registry successfully completes identity verification of both roadside unit $RS{U}_i$ and vehicle unit $RS{U}_i$, and proceeds to subsequent steps. RC computing $Y^{\prime }=sr\times Y$, ${SK}_{ij}=H({RID}_i\Vert {SID}_j\Vert X^{\prime }\Vert Y)$, $C_i=E_{K_i}\left({SK}_{ij},X,Y\right)$ and $D_j=E_{s_j}(Y^{\prime },C_i,{SK}_{ij})$. Upon completion of the calculation, RC transmits $\left\{D_j\right\}$ to ${RSU}_i$. After receiving the information $\left\{D_j\right\}$, RSU employs its own key $s_j$ to decrypt $D_j$ and obtain parameters $\{Y^{\prime },C_i,{SK}_{ij}\}$. It then verifies $Y^{\prime }?=\beta \times Q$. If they match, ${RSU}_i$ considers ${OBU}_i$ as trusted and sends the unsealed parameter $\left\{C_i\right\}$ to ${OBU}_i$. Subsequently, ${OBU}_i$ decrypts $C_i$ using its own key $K_i$ to acquire parameters ${\{SK}_{ij},X,Y\}$. Next, ${OBU}_i$ verifies $H({RID}_i\Vert {SID}_j\Vert X^{\prime }|\left|Y\right)?={SK}_{ij}$. If it holds true, ${OBU}_i$ deems ${RSU}_i$ as trusted and computes $F_i=H({SID}_j\Vert {SK}_{ij}\Vert X\Vert Y)$, which is sent as the authentication message for the session key to ${RSU}_i$. Otherwise, the response message from i is deemed invalid by ${OBU}_i$, and thus ends the session with a return of “Response message is not valid”. Finally, based on existing data, ${RSU}_i$ computes $F_i^{\mathrm{*}}=H({SID}_j\Vert {SK}_{ij}\Vert X\Vert Y)$ and verifies $F_i^{\mathrm{*}}?=F_i$. if they are equal, ${RSU}_i$ and ${OBU}_i$ negotiate the session key $SK=\alpha \times \beta \times P$. The specific process of authentication and key negotiation can be seen in Figure 6 and Algorithm 3.

Algorithm 3 ${RSU}_i$ authenticates ${OBU}_i$

Input: ${\mathrm{ID}}_i$, $P{W}_i$,$A_i,B_i,P,Q,H\left(·\right),E_k,t,CI{D}_i,X$;

Output: $SK$;

1: $\mathsf{\beta }\in Z_p$; //generate a random number

2: $Y=\mathsf{\beta }\times P;$

3: $M_j=H(X\Vert Y\Vert s_j\Vert {SID}_j);$

4: $V_j=E_{sj}\left(M_j,CI{D}_i,X,Y\right)$;

5: $s_j=H\left({SID}_j\right|\left|sr\right)$;

6: $M_j^{\prime }=H(X\Vert Y\Vert s_j|{|SID}_j)$;

7: if ($M_j^{\prime }==M_j$) then

8:  $K_i^{\prime }=H\left(RI{D}_i\right|\left|sr\right);$

9:  if (${H(K}_i^{\prime })==H(K_i\Vert SI{D}_j)$ then

10:    $Y^{\prime }=sr\times Y$;

11:   ${SK}_{ij}=H({RID}_i\Vert {SID}_j\Vert X^{\prime }\Vert Y)$;

12:  ${ C}_i=E_{K_i}\left({SK}_{ij},X,Y\right)$;

13:  $D_j=E_{s_j}(Y^{\prime },C_i,{SK}_{ij})$;

14:    if ($Y^{\prime }==Y)$ then

15:     ${SK}_{ij}^{\prime }=H({RID}_i\Vert {SID}_j\Vert X^{\prime }|\left|Y\right);$

16:     if (${SK}_{ij}^{’}=={ SK}_{ij})$ then

17:      $F_i=H({SID}_j\Vert {SK}_{ij}\Vert X|\left|Y\right);$

18:      $F_i^{\mathrm{*}}=H({SID}_j\Vert {SK}_{ij}\Vert X|\left|Y\right);$

19:      if ($F_i==$ $F_i^{\mathrm{*}})$ then

20:       return $SK=\alpha \times \beta \times P;$

21:      else return null;

22:     else return null;

23:    else return null;

24:   else return null;

25: else return null;

3.6. Password Upgrade Phase

The registration center will implement a password security mechanism for the vehicle, requiring timely password updates within a specified period to mitigate security risks associated with password loss. Vehicle users can independently update their passwords on $OB{U}_i$ without the need to communicate with RSU or RC. To initiate the password upgrade module, the vehicle user enters their ID $I{D}_i$ and original password ${PW}_i$ into $OB{U}_i$ as prompted by the intelligent terminal. OBU calculates $K_i=A_i\oplus H({ID}_i\Vert H({PW}_i\left|\left|r\right)\right)$ and verifies $B_i?=H\left(K_i\right)$. In case of inconsistency, an incorrect ID or password is indicated, prompting re-entry. If three consecutive incorrect attempts are made, OBU activates the security interrupt mechanism and restricts further attempts to upgrade the password within a designated security period. Conversely, if consistency is confirmed, the vehicle user is prompted to enter a new password twice consecutively; this new password must differ from the original one. In case of inconsistency between entered passwords, OBU prompts re-entry twice; otherwise, OBU calculates $A_i^{new}=K_i\oplus H({ID}_i\Vert H({PW}_i^{new}\left|\left|r\right)\right)$, replacing $A_i$ with $A_i=A_i^{new}$, thereby completing the password upgrade operation. The password upgrade process is shown in Figure 7.

4. Security Analysis

4.1. Formal Security Analysis

The stochastic oracular model, proposed by Bellare and Rogaway [28] in 1993, offers a method for designing protocols that are highly effective. It can be considered the ideal state of the hash function, known as the random oracle model, which possesses three fundamental properties.

• Consistency: If the input value is the same, the output must be the same;
• Computability: The output will be calculated in polynomial time;
• Uniform distribution: The output value space range is evenly distributed. The biggest advantage of this model is that it applies provable security methodology to practical applications.

The steps to verify the security of a scheme using a random oracle model are:

• The security of the scheme is formally defined, assuming that an adversary can successfully steal the key with a nonnegligible probability in a probability polynomial of time;
• An adversarial algorithm C is established to provide a simulation environment for the adversarial algorithm C. The adversarial algorithm C uses a unique attack method to ask the protocol, and the protocol answers all the questions asked by the opponent;
• Try to solve mathematical puzzles with information obtained from your opponent. If the mathematical problem can be solved successfully, it proves that the protocol does not pass the random oracle model verification. If the mathematical problem is not solved successfully, it is proved that the protocol is successfully verified by the random oracle model.

We will choose the random oracle model as the simulation environment and the CK adversarial model as the adversarial algorithm to analyze the security of the whole scheme.

Theorem: Let $A$ be an adversary against a probabilistic polynomial protocol. Adversary A can compromise the semantic security of the protocol through Send queries, Execute queries, and Hash queries. The probability of opponent $A$’s success is shown in Formula (2), where $N$ represents a set of integers, $l$ denotes the size of the hash function space, $q_h$ indicates the number of hash queries executed by adversary $A$, and $q_s$ represents the number of Send queries executed by adversary $A$.

$$ad{v}^{AKA}\left(A\right)\le \frac{q_s^2}{N}+\frac{q_h^2+q_s+2q_h}{2^l}+2q_{h}max\left\{ad{v}_{CMBDLP}^{AKA}\left(A\right)\right\}$$

(2)

Proof. 

Define a sequence of events, denoted as ${\mathrm{G}}_0$ through ${\mathrm{G}}_5$, where the event ${\mathrm{G}}_0$ represents a genuine attack with opponent A having no advantage. In event ${\mathrm{G}}_1$, opponent A is granted the ability to passively attack and launches passive attacks on both sides. Building upon event ${\mathrm{G}}_1$, event ${\mathrm{G}}_2$ grants opponent A the capability to send queries and initiates active attacks on both sides. Event ${\mathrm{G}}_3$ enables adversary A to send a Hash query based on event ${\mathrm{G}}_2$, which is then utilized by adversary A to make guesses about the values of ${\mathrm{W}}_3$ and ${\mathrm{W}}_4$. Extending from event ${\mathrm{G}}_3$, event ${\mathrm{G}}_4$ empowers adversary A with ESReveal queries and Corrupt queries. Finally, in event ${\mathrm{G}}_5$, derived from event ${\mathrm{G}}_4$, adversary A gains the ability to send a Test query. Subsequently, adversary A is presented with a mathematical problem related to the CMBDLP hypothesis and the CMBDHP hypothesis. The progression of these events is illustrated in Figure 8. □

Theorem (differential theorem): R1, R2, R3 denote events in a certain probability distribution. If the equation $\mathrm{R}1\wedge \neg \mathrm{R}2\iff \mathrm{R}3\wedge \neg \mathrm{R}2$ exists. Then $|\mathrm{Pr}\left[\mathrm{R}1\right]- \mathrm{Pr}\left[\mathrm{R}3\right]|\le \mathrm{Pr}\left[\mathrm{R}2\right]$

The following is a detailed description of the ${\mathrm{G}}_0$ to ${\mathrm{G}}_5$ events:

Event ${\mathrm{G}}_0$: This event is A simulation of a real attack by adversary A in a random language model. According to the above definition, Formula (3) is derived:

$$\mathrm{P}\mathrm{r}\left[Suc{c}_1\right]=\mathrm{P}\mathrm{r}\left[Suc{c}_0\right]$$

(3)

Event ${\mathrm{G}}_1$: In this event, opponent A initiates a passive attack by using the Execute $({OBU}_i,{RSU}_i$) function to query the interaction information {${CID}_i,\mathrm{X},{\mathrm{SID}}_j,V_j,D_j,C_j,F_j$} from RC. However, opponent A is unable to obtain the parameter $s_j$ that RC sends to ${RSU}_i$ during the registration phase. Consequently, adversary A cannot derive the session key solely based on this information, Formula (4) is derived:

$$ad{v}^{AKA}\left(A\right)=\left|2Pr\left[Suc{c}_0\right]-1\right|$$

(4)

Event ${\mathrm{G}}_2$: First event ${\mathrm{G}}_2$ simulates event ${\mathrm{G}}_1$ and adversary A has the ability to Send an active attack using the SEND query. When peer A sends different Send queries, peer A receives different interaction messages. There are several cases:

For a Send$({RSU}_i$,$\{{CID}_i,\mathrm{X}\}$) query: when ${RSU}_i$ received ${\{CID}_i,\mathrm{X}\}$, ${RSU}_i$ will select a random number beta and calculate the $\mathrm{Y}$, ${\mathrm{M}}_{\mathrm{j}}$, ${\mathrm{V}}_{\mathrm{j}}$. Finally, $\{Y$, ${\mathrm{M}}_{\mathrm{j}}$, ${\mathrm{V}}_{\mathrm{j}}$} to opponent A.

For a Send$(\mathrm{RC},{\{SID}_j,V_j\left\}\right)$ query: RC calculates $s_j=\mathrm{H}({SID}_j\Vert \mathrm{sr})$, using $s_j$ unlock $\{M_j,{CID}_i,\mathrm{X},\mathrm{Y}\}$, and calculate the $M^{\prime }=H(X\Vert Y\Vert sj|\left|{SID}_j\right)$, and then judge $M^{\prime }?=M_j$. Next, calculate $\mathrm{H}(\mathrm{s}\mathrm{r}\times \mathrm{X})$, The parameter $\{RID,H\left(K_i|\left|{SID}_j\right)\right\}$ is obtained by unlocking ${CID}_i$, and calculate the $\mathrm{H}({\mathrm{R}\mathrm{I}\mathrm{D}}_i\Vert \mathrm{s}\mathrm{r}),{\mathrm{M}}^{″}=\mathrm{H}({\mathrm{K}}_i\Vert {\mathrm{S}\mathrm{I}\mathrm{D}}_j)$, and then judge $M^{″}?=M^{\prime }$. If is equal to the calculated by $Y^{\prime }=\mathrm{s}\mathrm{r}\times Y,{SK}_{ij}=\mathrm{H}({RID}_i\Vert {SID}_j\Vert X^{\prime }\Vert \mathrm{Y}),{\mathrm{C}}_i={\mathrm{E}}_{K_i}\left({SK}_{ij},X,Y\right),{\mathsf{D}}_j={\mathrm{E}}_{s_i}(Y^{\prime },C_i,{SK}_{ij})$. Finally, RC sends $\{{\mathsf{D}}_j$} to opponent A.

For a Send$({RSU}_i$,$\left\{{\mathrm{D}}_i\right\})$ query: ${RSU}_i$ decrypts ${\mathrm{D}}_i$ with $s_j$ to obtain parameters $\{{SK}_{ij},C_i,Y^{\prime }\}$, and judge $Y\mathrm{’}?=Q\times \beta$. If so, unseal $C_i$. Finally, ${RSU}_i$ sends $\left\{C_i\right\}$ to opponent A.

For a Send$({OBU}_i$,$\left\{{\mathrm{C}}_i\right\})$ query: ${OBU}_i$ with $K_i$ decryption ${\mathrm{C}}_i$ get parameters $\{{SK}_{ij},X,Y\}$, calculate ${\mathrm{S}\mathrm{K}}_{ij}^{\prime }=\mathrm{H}({RID}_i\Vert {SID}_j\Vert X^{\prime }\Vert \mathrm{Y})$, then judge ${\mathrm{S}\mathrm{K}}_{ij}^{\prime }?={SK}_{ij}$. If this is true, then $F_i=H({SID}_j\Vert {SK}_{ij}\Vert X\Vert Y)$ is calculated. Finally, ${OBU}_i$ sends $\left\{F_i\right\}$ to opponent A.

For a Send$({RSU}_i$,$\left\{F_i\right\})$ query: ${RSU}_i$ computing ${\mathrm{F}}_i^{\mathrm{*}}=\mathrm{H}({SID}_j\Vert {SK}_{ij}\Vert \mathrm{X}\Vert \mathrm{Y})$, the final inspection ${\mathrm{F}}_i^{\mathrm{*}}?=F_i$.

In this scheme, the random numbers $\alpha$ and $\beta$ come from the set of positive integers ${\mathrm{Z}}^{*}$. According to the birthday paradox theorem, the probability of a collision between two random numbers after sending a ${\mathrm{q}}_{\mathrm{s}}$ query is ${\mathrm{q}}_{\mathrm{s}}^2/2\mathrm{N}$. If a hash query collision occurs, the event ends immediately, and the probability of a hash collision occurring is ${\mathrm{q}}_{\mathrm{h}}^2/2^{\mathrm{l}+1}$, Formula (5) is derived: (the length of each hash value is $l$)

$$\mid Pr\left[Suc{c}_2-Suc{c}_1\right]\mid \le q_s^2/2N+q_h^2/2^{l+1}$$

(5)

Event ${\mathrm{G}}_3$: If opponent A cannot correctly guess the values of $\mathrm{X}$ and $\mathrm{Y}$ without using the hash oracle query scenario. Then, the event ${\mathrm{G}}_3$ is the same as the previous event, and Formula (6) is derived:

$$\mid Pr\left[Suc{c}_3-Suc{c}_2\right]\mid \le q_s/2^{l+1}$$

(6)

Event ${\mathrm{G}}_4$: This event contains concerns about session key security. In addition to inheriting the ability of event ${\mathrm{G}}_3$, adversary A in event ${\mathrm{G}}_4$ can also obtain $\{{SID}_j,{ID}_i,s_j,K_i,\alpha ,\beta \}$ and other information through ESReveal query and Corrupt query.

Case 1: Send ESReveal$\left({OBU}_i\right)$ and ESReveal$\left({RSU}_i\right)$ queries: When opponent A sends ESReveal$\left({OBU}_i\right)$ and ESReveal$\left({RSU}_i\right)$ queries, opponent A will get the information $\left\{\alpha \right\}$ in ${OBU}_i$ and $\left\{\beta \right\}$ in ${RSU}_i$. But this information is different in every conversation.

Case 2: Send ESReveal$\left({OBU}_i\right)$ and Corrupt$\left({RSU}_i\right)$ query: When opponent A sends ESReveal$\left({OBU}_i\right)$ and Corrupt$\left({RSU}_i\right)$ queries, opponent A will get $\left\{\alpha \right\}$ in $\left({OBU}_i\right)$ and $\{s_j,{SID}_j\}$ in $\left({RSU}_i\right)$.

Case 3: Send Corrupt$\left({OBU}_i\right)$ and ESReveal$\left({RSU}_i\right)$ query: When opponent A sends Corrupt$\left({OBU}_i\right)$ and ESReveal$\left({RSU}_i\right)$ queries. Opponent A will have access to the information $\{K_i,{ID}_i\}$ in ${OBU}_i$ and $\left\{\beta \right\}$ in ${RSU}_i$.

Case 4: Sending Corrupt$\left({OBU}_i\right)$ and Corrupt$\left({RSU}_i\right)$ queries: When adversary A sends Corrupt$\left({OBU}_i\right)$ and Corrupt$\left({RSU}_i\right)$ queries, adversary A will get the information $\{K_i,{ID}_i\}$ in ${OBU}_i$ and $\{s_j,{SID}_j\}$ in ${RSU}_i$.

But since the session key is associated with $X^{\prime },\mathrm{Y}$. When opponent A does not get $\mathrm{H}({RID}_i\Vert {SID}_j\Vert X^{\prime }\Vert \mathrm{Y})$ or solve CMBDLP and CMBDHP assumptions, opponents will not be able to get A session key. That is, event ${\mathrm{G}}_4$ is the same as event ${\mathrm{G}}_3$ as long as the assumptions of CMBDLP and CMBDHP hold. Then we get:

$$\left|Pr\left[Suc{c}_4-Suc{c}_3\right]\right|\le q_{h}max\left\{ad{\nu }_{CMBDLP}^{AKA}\left(A\right),ad{\nu }_{CMBDHP}^{AKA}\left(A\right)\right\}$$

Event ${\mathrm{G}}_5$: Event ${\mathrm{G}}_5$ simulates event ${\mathrm{G}}_4$. The opponent A issues a Test query, if your opponent A $\mathrm{H}({RID}_i\Vert {SID}_j\Vert X^{\prime }\Vert \mathrm{Y})$ query. Then, the Test query for event ${\mathrm{G}}_5$ terminates. Since the adversary A can obtain ${SK}_{ij}$ by hash query. The probability that ${SK}_{ij}$ is obtained by hash query is $q_h/2^l$. Then, Formula (7) is derived:

$$|Pr\left[Suc{c}_5-Suc{c}_4\right]|\le \frac{q_h}{2^l}$$

(7)

The adversary A issues a Test query and makes a guess about the value of b. Then, we get the probability that adversary A guessed correctly, Formula (8) is derived:

$$Pr\left[Suc{c}_5\right]=1/2$$

(8)

Combining the above formula, Formula (9) is derived:

$$ad{v}^{AKA}(A)\le \frac{q_s^2}{N}+\frac{q_h^2+q_s+2q_h}{2^l}+2q_{h}max\left\{ad{v}_{CMBDLP}^{AKA}\left(A\right),ad{v}_{CMBDHP}^{AKA}\left(A\right)\right\}$$

(9)

Then the formula follows: there exists a number $\mathsf{\epsilon }, \mathsf{\epsilon }>0$, such that the inequality ${\mathrm{adv}}^{\mathrm{AKA}}\left(\mathrm{A}\right)<\mathsf{\epsilon }$ holds. That is, in the CK model, the protocol scheme is considered secure.

4.2. Informal Security Analysis

OBU impersonation attack: OBU impersonation attack means that an attacker masquerades as a legitimate vehicle user to obtain information services illegally. First of all, the attacker can forge a login request $\{CI{D}_i,X\}$, including $CI{D}_i=E_{H\left(X^{\prime }\right)}(RI{D}_i,H(K_i\parallel SI{D}_j\left)\right)=E_{H(\alpha \times Q)}(RI{D}_i,H(K_i\parallel SI{D}_j\left)\right)$ and be RSU and RC validation through. Among them, $RI{D}_i$ and $K_i$ are the key information, but from the above introduction of this protocol, we know that they are secure, and the corresponding key $K_i$ is also secure. Therefore, vehicle impersonation attack is not possible in the proposed protocol.

RSU impersonation attack and RC impersonation attack: In order to launch an RSU impersonation attack, the attacker must forge a valid authentication reply information $\left\{C_i\right\}$ and successfully pass the verification process of vehicle ${OBU}_i$. The keys used by each vehicle and RSU are unique and independently generated by the registration center, with no correlation between them. Without obtaining the key of the target RSU or the key of the vehicle communicating with it, the attacker will be unable to recover or calculate $\left\{C_i\right\}$ in $D_j$, thus making it impossible to forge a legitimate reply $\left\{C_i\right\}$ that can be authenticated by vehicle ${OBU}_i$. Consequently, our proposed protocol effectively mitigates against RSU impersonation attacks. Furthermore, an RC impersonation attack can only be launched if the attacker gains access to the system master key sr. However, this master key is exclusively stored and accessible by the registry center itself. The security of this master key directly determines overall security within our multiserver authentication system framework. It is assumed in this paper that proper measures are taken by the registry center to safeguard this system master key at all times; hence rendering any effective RC masquerading attacks unfeasible.

User privacy protection function: This scheme proposes the random generation of ${RID}_i$ to replace the actual vehicle information identification in the login request information. The dynamic parameter is encrypted using the key $H\left(\alpha \times Q\right)$. Only a trusted third-party registry RC can compute $X\mathrm{’}=sc\times X$ using the system master key. By utilizing parameters obtained from this calculation, $CI{D}_i=E_{H\left(X^{\prime }\right)}(RI{D}_i,H(K_i\Vert SI{D}_j\left)\right)=E_{H\left(\alpha \times Q\right)}({RID}_i,H(K_i\Vert {SID}_j\left)\right)$ recovery ${RID}_i$ can be unlocked. However, there are only two ways for an attacker to recover the vehicle user key: illegal theft of the system master key or solving an NP problem. It is evident that successful retrieval by attackers is not possible; hence, ensuring anonymity in this proposed protocol. Furthermore, none of the fixed parameters are present in the vehicle login request information $\{{CID}_i,X\}$, as they are all randomized by parameter α. Therefore, tracing fixed parameters within login information cannot reveal any vehicle-related details. Consequently, this proposed scheme ensures nontraceability.

Offline password guessing attack: In this study, it is assumed that the attacker has obtained $\left\{A_i,B_i,r\right\}$ of the vehicle through unauthorized means, where $B_i=H\left(A_i\oplus H(I{D}_i\parallel H(P{W}_i\parallel r\left)\right)\right)$. To recover the password in $B_i$, the attacker must acquire both the vehicle’s ID and password. However, during registration services provided by the registration center (RC), vehicles are required to adhere to specific rules for selecting their identity and password. This inevitably enhances the difficulty for attackers attempting to crack these two crucial parameters. Consequently, our proposed scheme effectively withstands offline password-guessing attacks launched by potential adversaries.

Replay attack: A replay attack occurs when an attacker records or repeats information during network communication with the intention of deceiving the system. In our proposed scheme, we have integrated random numbers and timestamps into the interactive information exchanged between the on-board unit ${OBU}_i$, roadside unit ${RSU}_i$, and registration center (RC). This integration enables any recipient to determine whether a particular piece of information has been replayed or not, thereby effectively filtering out any illicitly replayed data.

Forward security: Forward security means that the leakage of a long-used master key does not lead to the leakage of past session keys. In the proposed scheme, the session key $SK=\alpha \times \beta \times P$ negotiated by the on-board unit ${OBU}_i$ and the roadside unit ${RSU}_i$ integrates the random numbers $\{\alpha ,\beta \}$ generated by them respectively. These two random numbers are generated independently by the on-board unit ${OBU}_i$ and the roadside unit ${RSU}_i$, which cannot be obtained by anyone else. The attacker can only calculate SK by $X=\alpha \times \mathrm{P},Y=\beta \times P$. In other words, the session key security of the proposed scheme can be reduced to the computational DH problem, so it satisfies forward security.

Interoperability: The protocol meticulously adheres to and integrates VANET standards, such as IEEE 802.11p [29] and SAE J2735 [30], ensuring coherence with industry benchmarks across vital elements like communication protocols, message formats, and data fields. This adherence to standards aims to facilitate the seamless integration of protocols into the existing VANET ecosystem, mitigate compatibility issues among diverse protocols, and enhance the overall system’s stability and maintainability. Simultaneously, to accommodate the resource constraints of the VANET environment, we opted for ECC with a focus on a concise key length. The rationale behind this choice lies in the ability of a short key length to alleviate computational burdens during communication, rendering the protocol more suitable for the resource-limited vehicle communication milieu in VANET while also maintaining compatibility with traditional encryption algorithms.

5. Performance Analysis

The proposed scheme will be compared with the schemes of Shohei et al. [11], Zhang et al. [13], Liu et al. [19], Guo et al. [25], Kumari et al. [26], Jangirala et al. [27], and Chen et al. [23] in this section to analyze and compare their security functions. Furthermore, a comparison will be made between our scheme and the schemes of Zhou et al. [17], Liu et al. [19], and Chen et al. [23] in terms of encryption operations, computation delay, and communication cost.

5.1. Safety Function Analysis

According to the comparison in

Table 2. Comparison of security functions.

	OBU and RSU Feinting	User Privacy Protection	Resist Known Session Key Attacks	Resist Password Guessing Attacks	Replay Attack	Forward Safety
[11]	√	√	×	×	√	√
[13]	√	×	√	√	×	√
[19]	√	√	×	×	√	√
[25]	√	√	√	×	×	√
[26]	×	×	√	√	√	√
[27]	×	×	√	√	√	√
[23]	√	×	√	√	×	√
Ours	√	√	√	√	√	√

, it is evident that the protocols proposed by Zhang et al. [13] and Liu et al. [19] lack effective resistance against known session key attacks and password-guessing attacks. Guo et al.’s scheme [25] fails to withstand offline password guessing attacks and replay attacks. On the other hand, Kumari et al.’s protocol [26] and Jangirala et al.’s protocol [27] are susceptible to impersonation attacks from OBU and RSU, while also failing to ensure vehicle privacy. In recent years, although the new protocols proposed by Shohei et al. [11] and Chen et al. [23] have enhanced identity authentication efficiency, they still possess certain flaws, such as susceptibility, to replay attacks and absence of vehicle privacy protection. Distinguished from other solutions, our proposed protocol comprehensively fulfills all security requirements listed in the table while providing a more comprehensive and efficient solution for addressing limitations present in existing approaches.

5.2. Computational Cost

The encryption operations employed in the four compared schemes include hash operation, scalar multiplication operation, point addition operation, symmetric key encryption operation, and symmetric key decryption operation. Their corresponding symbols are Has, Mul, Add, Enc and Dec. To facilitate a more intuitive comparison of performance data between the schemes, we conducted simulations using OpenSSL library [31], GMP library [32], and PBC Library [33] on two Ubuntu 16.04 devices. The end device hardware utilized was a RASPBERRY PI 3B+ with 1 GB LPDDR2 SDRAM and a BCM2837B0 system chip operating at a frequency of 1.4 GHz. The AG hardware consisted of a computer with 4 GB RAM and an INTEL(R) CELERON (R) J1900 CPU. The execution time of the basic operation is shown in

Table 3. Execution time of basic operations (ms).

	Definition	BCM2837B0	Intel J1900
$T_{\mathit{Has}}$	Execution time of the SHA 256 algorithm (160 bit)	0.0729 ms	0.0023 ms
$T_{\mathit{Mul}}$	Curve25519 Execution time of point multiplication	23.4405 ms	2.2260 ms
$T_{\mathit{Add}}$	Curve25519 Execution time of point addition	0.1652 ms	0.0288 ms
$T_{\mathit{Enc}}$	Execution time for AES 128 encryption (ECB mode and 128 bit)	0.0500 ms	0.0130 ms
$T_{\mathit{Dec}}$	Execution time of AES 128 decryption (ECB mode and 128 bit)	0.0810 ms	0.0170 ms
$T_{Xor}$	Curve25519 Execution time of the XOR operation	0.1650 ms	0.0490 ms
$T_{EXP}$	Curve25519 Indicates the execution time of the exponential operation	3.3280 ms	0.0390 ms

.

To evaluate the performance of the schemes in terms of encryption operations, we conducted a comprehensive analysis of the utilization of different encryption techniques in each scheme, as presented in

Table 4. Comparison of the number of different encryption operations.

	Our		Zhou et al. [17]		Liu et al. [19]		Chen et al. [23]
	User	Server	User	Server	User	Server	User	Server
Has	5	8	2	2	0	2	1	4
Mul	2	5	3	5	4	3	5	4
Add	0	0	2	3	1	0	1	1
Enc	0	3	0	0	0	0	0	0
Dec	1	3	0	0	0	0	0	0
Xor	1	0	0	0	0	0	0	0
EXP	0	0	0	0	6	4	1	2
Total	58.8955 ms		82.0601 ms		120.7338 ms		129.7886 ms

. In terms of encryption operations, it is observed that the remaining three schemes exhibit higher usage rates, potentially leading to increased computational latency.

Based on the data in Table 3 and Table 4, we computed the duration of cryptographic operations for the compared schemes. Among them, Zhou et al. [17] performed 17 cryptographic operations, taking 82.0601 ms. Lin et al. [19] conducted 20 cryptographic operations and required 120.7338 ms. Chen et al. [23] executed 19 cryptographic operations, which consumed 129.7886 ms of time. The proposed scheme involved a total of 28 cryptographic operations with a corresponding time expenditure of 58.8955 ms.

Through simulation, we obtained the results as shown in Figure 9, which shows the comparison of different schemes of average computing latency between the client side and the server side under the same attack ratio. The vertical axis represents the average computation delay, while the horizontal axis represents the four different schemes, with the blue and orange columns representing the client and server sides, respectively. According to the data in Table 4, the scheme proposed in this paper mainly completes the encryption operation on the server side. It can be clearly seen from Figure 9 that compared with other schemes, the scheme proposed in this paper has relatively short computation latency on both the client and server side.

The security properties of the proposed scheme have been analyzed in Section 4, and it has been proven that the scheme can withstand certain attacks. Attacks that can be defended through security analysis are considered as known attacks, while all other potential attacks are classified unknown attacks due to their unpredictable nature. It is assumed that an unknown attack may disrupt the authentication process of these four schemes, whereas known attacks cannot. Under known attacks, each scheme exhibits a fixed computation delay; however, under unknown attacks, the computation delay may vary. To assess the impact of this uncertainty on performance, we conducted simulations using C++ to evaluate how the authentication schemes perform under unknown attacks. During these simulations, we measured the computation delay for each scheme as we varied the ratio between unknown and known attacks. The parameter used to measure performance is defined as the average successful computation delay according to Equation (10).

$${\mathrm{d}\mathrm{e}\mathrm{l}\mathrm{a}\mathrm{y}}_{\mathrm{A}\mathrm{V}\mathrm{G}}=\frac{{\mathrm{d}\mathrm{e}\mathrm{l}\mathrm{a}\mathrm{y}}_{\mathrm{u}\mathrm{n}\mathrm{k}\mathrm{n}\mathrm{o}\mathrm{w}\mathrm{n}}\ast {\mathrm{t}\mathrm{i}\mathrm{m}\mathrm{e}\mathrm{s}}_{\mathrm{u}\mathrm{n}\mathrm{k}\mathrm{n}\mathrm{o}\mathrm{w}\mathrm{n}}+{\mathrm{d}\mathrm{e}\mathrm{l}\mathrm{a}\mathrm{y}}_{\mathrm{k}\mathrm{n}\mathrm{o}\mathrm{w}\mathrm{n}}\ast {\mathrm{t}\mathrm{i}\mathrm{m}\mathrm{e}\mathrm{s}}_{\mathrm{k}\mathrm{n}\mathrm{o}\mathrm{w}\mathrm{n}}}{{\mathrm{t}\mathrm{i}\mathrm{m}\mathrm{e}\mathrm{s}}_{\mathrm{k}\mathrm{n}\mathrm{o}\mathrm{w}\mathrm{n}}}$$

(10)

where ${\mathrm{t}\mathrm{i}\mathrm{m}\mathrm{e}\mathrm{s}}_{\mathrm{u}\mathrm{n}\mathrm{k}\mathrm{n}\mathrm{o}\mathrm{w}\mathrm{n}}={\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{o}}_{\mathrm{u}\mathrm{n}\mathrm{k}\mathrm{n}\mathrm{o}\mathrm{w}\mathrm{n}}\ast {\mathrm{t}\mathrm{i}\mathrm{m}\mathrm{e}\mathrm{s}}_{\mathrm{A}\mathrm{L}\mathrm{L}-\mathrm{A}\mathrm{T}\mathrm{T}\mathrm{A}\mathrm{C}\mathrm{K}}$.

The correlation between the average computation delay of each scheme and the percentage of unidentified attacks is depicted in Figure 10, with the Y-axis representing the average computation delay and the X-axis indicating the proportion of unknown attacks relative to the total number of attacks. Each scheme is represented by a distinctive color curve. As outlined in Table 4, our computations primarily occur on the server side, and as indicated in Table 3, the server side’s computational time significantly outperforms that of the user side. Figure 10 illustrates that, with the escalating percentage of unknown attacks, the average computation delay for each scheme gradually increases. Notably, our proposed scheme consistently exhibits the lowest computation latency even when facing a higher proportion of unknown attacks, underscoring its robust security. Hence, our scheme stands out with considerable advantages in this context.

5.3. Memory Overhead

The authentication process relies heavily on the relationship between memory and performance, as it involves handling a substantial amount of information and keys. The efficient utilization of memory directly impacts the overall performance of the authentication system. Sufficient memory enhances concurrency, enabling simultaneous authentication for multiple users and thereby improving system performance. Conversely, inadequate memory can lead to delays in authentication requests, reduced system responsiveness, or even denial-of-service situations. We will evaluate each scheme’s size to assess its pros and cons in terms of performance. If a scheme requires less memory, it consumes fewer system resources for identity authentication and offers certain advantages in terms of performance.

The memory consumption of different operands varies across systems. In this paper, it was assumed that the memory footprint for timestamp $S_T$ random number $S_R$, and identifier $S_I$ was 32 bits; the memory footprint for data obtained through point multiplication $S_M$ was 320 bits; the memory footprint for hash value $S_H$ and packet $S_S$ was 160 bits; and the memory footprint for symmetric key encryption $S_E$ was 128 bits.

Table 5. Memory usage operand analysis.

Scheme	User	Server	Total
Our	$2S_E+S_M+S_H$	$S_I+{3S}_E$	${5S}_E$$+S_M+S_H+S_I$
Zhou et al. [17]	${8S}_S+S_T+S_H$	$2S_M$	${8S}_S+S_T+S_H+$$2S_M$
Liu et al. [19]	${3S}_E+S_M+{2S}_I$	$S_E+S_R+{3S}_M+2S_I$	${4S}_E+S_R+{4S}_M+4S_I$
Chen et al. [23]	$7S_S+S_T$	$2S_M$	$7S_S+S_T+$$2S_M$

presents an analysis of the proportion of memory usage in four schemes on both the user side and the server side. Figure 11 illustrates a comparison of the total occupied memory by these four schemes.

The proposed scheme exhibits the minimum total memory occupancy value, as evidenced by Table 5 and Figure 11. Moreover, it demonstrates superior performance in terms of memory occupation on the user side with limited system resources. A smaller memory footprint on the user side ensures smooth operation even with fewer system resources available. In conclusion, our proposed scheme offers significant advantages in terms of memory utilization.

To verify the performance of the scheme in terms of packet loss rate, we set up a simulation scenario using the Vein simulation platform. Reasonable deployment of Rsus, such as key intersections, high-traffic areas, and emergency lanes, is the key to ensuring efficient coverage. The OBU is placed inside the vehicle, paying attention to the antenna position and causing minimal interference to the vehicle. In terms of communication protocols, IEEE 802.11p [29] and SAE J2735 [30] protocols are used to support a variety of communication technologies. The simulation scenario Settings are shown in

Table 6. Simulation Scenario.

Parameter	Setting
Simulation Scenario Range	12 km
RSU Communication Radius	800 m
Vehicle Speed	40–120 km/h
Vehicle Communication Radius	250 m
Vehicle Broadband	200 kbit/s

: (1) On a two-way four-lane road with a total length of 12 km, an RSU with a communication radius of 800 m is placed every 3 km. (2) Allow different numbers of vehicles to pass through, introducing changes in traffic density. (3) The vehicle speed is controlled within the range of 40~120 km/h to simulate the real traffic conditions. (4) The vehicle communication radius is set to 250 m to establish a local communication network. (5) The broadband of the vehicle is fixed at 200 kbit/s, representing the typical data transmission rate of vehicle communication. The packet loss rate is defined as the ratio of the total number of lost signed packets transmitted by a vehicle to the total number of signed packets.

As depicted in Figure 12, the packet loss rate exhibits an upward trend with the increase of traffic volume in a given scenario. This phenomenon is mainly attributed to the elevated vehicle density, which leads to vehicles moving out of communication range before message processing by RSUs is completed. Under high traffic conditions, vehicles may enter and leave the communication range of RSUs more rapidly, resulting in a shorter time window for message processing and a higher likelihood of packet loss.

Traditional authentication and key management can become cumbersome and computationally intensive as traffic increases. In our proposed scheme, RC serves as a centralized entity that simplifies the communication process between vehicles and RSUs. By reporting to RC to obtain authentication information and keys, vehicles do not need to communicate directly with multiple RSUs frequently, thereby reducing communication complexity. Meanwhile, RC handles complex computational tasks such as key management and authentication more efficiently using specialized algorithms and resources. The advantages offered by RC alleviate the computational burden on both vehicles and RSUs during authentication and key exchange processes while reducing packet loss probability significantly.

Observations from Figure 12 indicate that when there are few vehicles present, our proposed scheme’s packet loss rate is almost identical to other schemes; however, its superiority becomes more pronounced when there are many vehicles present. Our scheme demonstrates strong adaptability when dealing with high traffic flow while providing reliability and stability for communications within vehicular networking environments—further proving its practical applicability.

6. Open Challenges and Future Research Directions

The protocol introduced in this paper presents a significant advancement in the realm of autonomous driving and intelligent transportation. The incorporation of a trusted RC effectively addresses security challenges prevalent in existing protocols, ensuring highly reliable bidirectional authentication between vehicles and RSUs. This not only strengthens the resilience of vehicle communications but also enhances the security posture for autonomous vehicles. Under a multiserver architecture, the protocol achieves substantial progress in identity authentication and key negotiation, eliminating the burdensome and repetitive registration of vehicle users at each RSU. This optimization improves system efficiency, fosters seamless integration of vehicle management, and delivers a more efficient solution for intelligent transportation systems.

Nevertheless, in the current landscape, the security of multiserver authentication and key protocols based on elliptic curve cryptography faces considerable challenges due to the emergence of quantum computing. The vulnerabilities of traditional encryption algorithms become more apparent in a quantum computing environment, particularly the susceptibility of elliptic curve cryptography to factorization and other attacks. This raises critical questions about the overall protocol security, necessitating urgent exploration of future research directions to counter the new challenges posed by quantum computing.

To address this challenge, future research directions should concentrate on implementing cryptographic algorithms resistant to quantum computing attacks, such as hash function-based message authentication code (HMAC) [34] and lattice-based encryption algorithms (NTRUEncrypt) [35]. These cryptographic algorithms demonstrate heightened resistance in the current quantum computing environment and can effectively counter potential quantum computing attacks. Additionally, future research should delve into advanced strategies for key management, incorporating regular key updates to ensure the adaptability of system security to the continuous evolution of cryptographic techniques. Research in this direction will offer profound insights and crucial solutions for addressing the security challenges associated with elliptic curve cryptography in the era of quantum computing.

7. Conclusions

In this paper, we propose a three-party identity authentication and key agreement protocol based on elliptic curve public key cryptography to address the challenges of identity authentication and key agreement between OBU and RSU in VANETs. To mitigate vehicle impersonation attacks, RSU impersonation attacks, and vehicle privacy leakage in multiserver remote authentication within a wireless mobile environment, we introduce a trusted third-party registration center that facilitates identity verification for OBU and RSU. During the login and mutual authentication process, the registration center assumes most of the identity verification tasks without imposing additional storage or computational complexity on the vehicle terminal. This ensures efficient storage utilization and computing efficiency even for vehicles with limited computing power while enabling successful mutual authentication between OBU and RSU. By adopting this scheme, we effectively address security risks present in existing approaches without increasing the storage complexity of the vehicle terminal. Future research will focus on vehicle efficient authentication through RSU, exploring this direction in order to enhance system stability, reduce costs, reduce dependence on third parties, and thus improve the sustainability of the overall solution.