A Privacy-Preserving V2I Fast Authentication Scheme in VANETs

Abstract

Due to the characteristics of high-speed movement of vehicles, authentication between vehicles and roadside units (RSUs) needs to be performed quickly. Vehicles can obtain the authentication information of the relevant RSUs from the certification authority (CA) in advance through route planning. Fast authentication can be performed when the vehicle enters the RSU range. However, in most of the current vehicle-to-infrastructure (V2I) fast authentication schemes, when the vehicle requests the authentication information of an RSU from the CA, the vehicle often needs to provide the CA with the travel path information, which leads to the CA easily obtaining the travel path of the vehicle. In addition, the CA encrypts the private keys of RSUs and sends them to vehicles as authentication keys, and the vehicles can obtain the private key information of RSUs directly after decryption. Once the private keys of RSUs are leaked, vehicular ad hoc networks (VANETs) can be attacked by malicious access. In order to protect the confidentiality of RSU private keys and the route privacy of vehicles, we propose a privacy-preserving V2I fast authentication scheme in VANETs. The scheme realizes the confidentiality of RSU private keys and the route privacy protection of vehicles by improving the oblivious transfer (OT) algorithm. Security analysis proves that our scheme has good privacy and attack resistance. Finally, performance evaluation shows that the proposed scheme performs better in terms of computational overhead and communication overhead compared to related schemes.

1. Introduction

With the rapid development of the Internet of Things (IoT), Big Data, Artificial Intelligence (AI), and other technologies, the intelligence and automation of vehicular networking systems have become a trend. VANETs are an important part of Intelligent Transportation Systems (ITSs) [1]. They can provide real-time road conditions, traffic information, safety warnings, and other services that are important for improving driving safety and reducing traffic accidents [2,3]. Therefore, information security and data exchange in VANETs become particularly important. In general, VANETs consist of the following three main entities: a certification authority (CA), roadside units (RSUs), and on-board units (OBUs) [4]. Their communication method is divided into two main parts, namely vehicle-to-infrastructure communication (V2I) and vehicle-to-vehicle communication (V2V) [5]. Both V2V and V2I communications follow the Dedicated Short-Range Communications (DSRC) protocol and use the IEEE 802.11p standard for wireless communication [6,7]. In V2I communication, information about road safety and traffic conditions is mainly provided to vehicles by RSUs to promote driving safety. In V2V communication, each vehicle utilizes a wireless transceiver to communicate in real time with other vehicles around it, exchanging information such as auxiliary information about the road, real-time traffic conditions, and emergency situations [8,9]. In order to secure communication in VANETs, mutual authentication between communicating entities is required before communication can be realized. Therefore, authentication protocols in VANETs are crucial.

In 2019, Ahmad et al. [10] introduced a scheme related to route planning in VANETs through which fast authentication for V2I is achieved. In the V2I fast authentication process, the vehicle usually plans the travel path in advance before traveling and calculates the RSUs that the path needs to pass through, then requests the authentication keys of the RSUs on the path from the CA; finally, the CA sends the authentication keys of these RSUs to the vehicle. When the vehicle enters the coverage area of the relevant RSU, it then utilizes the corresponding RSU authentication key to authenticate with the RSU. However, in many current V2I fast authentication schemes, when the vehicle requests authentication information from the CA for an RSU, the vehicle needs to provide the CA with the path information of the trip, which results in the CA easily obtaining the travel path of the vehicle. In fact, the vehicle’s sensitive information, such as the traveling path, departure time, and parking time, is private to other entities (including the CA). In addition, the CA encrypts the private key of the RSU as the authentication key and sends it to the vehicle, which is able to obtain the private key of that RSU directly after decryption. Since the CA does not further encrypt the private keys of these RSUs, once the private keys of these RSUs are maliciously leaked by vehicles, the RSUs may be subject to attacks such as malicious access and information tampering by attackers. This can cause serious consequences for the whole VANET. Therefore, how to ensure the confidentiality of RSU private keys and the route privacy of vehicles has become an urgent problem. To solve this problem, this paper proposes a privacy-preserving V2I fast authentication scheme in VANETs. The contributions of this scheme are described as follows:

• In the route-planning phase, the RSU authentication key sent by the CA to the vehicle is based on the RSU private key with the vehicle’s public identity key added. In this way, the confidentiality of the RSU private key is guaranteed, in addition to ensuring that this authentication key can only be used by the vehicle that applies for it.
• When the vehicle requests the authentication key of an RSU from the CA, the improved OT algorithm is utilized to encrypt the driving path information of the vehicle so that the CA cannot infer the driving path of the vehicle from the request information of the vehicle. In this way, the route privacy of the vehicle is protected.

The rest of this paper is organized as follows. Section 2 describes work related to privacy preservation in VANETs. Section 3 describes the preparatory work involved in this paper. Section 4 describes the models and design goals. Section 5 describes the privacy protection scheme proposed in this paper. A security analysis is presented in Section 6. Section 7 presents a comparison of performance overhead. In Section 8, we provide our conclusions and a discussion.

2. Related Works

In this section, privacy protection schemes in VANETs are introduced, and the advantages and disadvantages of these schemes are discussed.

In order to ensure the data privacy of each entity in VANETs, it is crucial to establish a system that can effectively protect the applications in VANETs. The protection of privacy information mainly relies on the communication authentication protocols in VANETs. Therefore, a secure and reliable authentication protocol needs to be constructed to ensure the confidentiality of private keys and route privacy in VANETs [11,12,13,14,15]. In terms of key management, to address the problems of complex and variable topologies that cause keys to be constantly updated every moment, as well as interference with regular V2I data exchanges, Tan et al. [16] proposed a secure authentication and key management scheme to solve the above problems. The scheme issues an independent session key for each legitimate vehicle, vehicle data are shared between neighboring vehicles, and all authenticated vehicles maintain group management records. As a result, the scheme has a large storage burden on the vehicle side. Ma et al. [17] proposed an efficient, decentralized, blockchain-based key management mechanism (DB-KMM) for in-vehicle self-organizing networks that automatically realizes the registration, updating, and revocation of users’ public keys. However, the connection, node deployment, and maintenance of the whole network require high operation costs. Xu et al. [18] proposed a BAGKD protocol to realize powerful and efficient group networking and ensure the security and efficiency of VANETs. The group key can be dynamically updated through the group key distribution mechanism, which effectively reduces the risk of group key breakage and leakage. Mansour et al. [19] introduced a new group key management protocol, ALMS, which solves the privacy problem of group members and the collusion problem among receivers. However, when a vehicle applies to join a group, the TA needs to broadcast the encrypted group key to all vehicles in the receiving group, which tends to lead to problems such as channel congestion. Li et al. [20] proposed an unlinkable authentication key protocol that prevents the problem of entity collusion in VANETs. The protocol relies heavily on the AAC stored in the blockchain and needs to focus on managing and controlling the data on the chain. As a result, the efficiency of authentication decreases. Li et al. [21] proposed an identity-based dynamic data integrity auditing scheme for CMTS. The scheme’s batch auditing approach can reduce the key management burden in VANETs and improve the auditing efficiency. Wei et al. [22] proposed a verified secure AKA scheme. The scheme is a tree-based key negotiation algorithm that focuses on assigning a public session key to vehicles and RSUs after they have been authenticated. This session key can protect V2V and V2I communications, along with the authentication algorithm and encryption algorithm for messages. Since frequent communication between the TAand RSUs is required, the scheme requires a large communication overhead. Yang et al. [23] proposed a two-way anonymous authentication and key negotiation scheme based on identity authentication. The scheme claims to fulfill the real-time communication requirements of VANETs with good security. However, due to the resource cost, the RSU nodes in VANET quickly reach their peak processing capacity under large-scale traffic due to the excessive number of messages that need to be authenticated and, thus, cannot quickly authenticate a large number of messages.

In terms of route privacy, the transmission of messages in open-access environments such as VANETs is faced with the most critical and challenging privacy issues [24]. To protect vehicle route privacy in VANETs, Sampigethaya et al. [25] proposed a location privacy scheme called CARAVAN. This scheme addresses the location privacy threat in VANETs based on broadcast tracking of vehicles. However, the scheme is still able to analyze the location privacy of vehicles by combining the analysis of map data and communication traffic. In order to further protect the user’s route privacy information, Zhu et al. [26] proposed bilinear pairing-based local authentication and roaming authentication for VANETs, which is able to provide secure communication and anonymous authentication between RSUs and vehicles. However, since the authentication process of this scheme includes both local and roaming authentication, the vehicle needs to spend a long time waiting for a response from the RSU during the authentication process between the vehicle and the RSU, resulting in inefficient communication. In order to efficiently and securely realize authentication in VANETs, Cui et al. [27] proposed a novel authentication scheme. The scheme uses a dual pseudonym approach to hide the true identity of the vehicle and a dynamic update technique to periodically update the information stored in the vehicle. By not using bilinear pairing, they claim that the scheme performs better in terms of computational overhead and communication overhead and is suitable for widespread application in VANETs. Wahid et al. [28] proposed a holistic safety-aware location-preserving scheme called Coupling Privacy with Safety (CPS). They claim that this scheme can ensure the provision of driver privacy and security. However, in this scheme, an RSU can use the information contained in the BSM to obtain the point in time when the vehicle enters its range and the driving time within its range. Therefore, the privacy information of the vehicle is not fully protected. Subsequently, Lv et al. [29] proposed a lightweight V2I fast authentication scheme that combines Moore’s curve and BGN homomorphic encryption to protect the vehicle’s travel path, making it impossible for CAs to learn about the vehicle’s travel path as well. Liang et al. [30], Yan et al. [31], and Su et al. [32] all utilized the idea of oblivious transfer to achieve route privacy protection for vehicles, which also makes it impossible for the CA to know a vehicle’s travel path. However, these schemes [29,30,31,32] are all subject to the problem that when the vehicle requests the RSU authentication key from the CA in the route-planning phase, the RSU authentication key returned by the CA to the vehicle is the private key of the RSU. These private keys are unique and can be used by all vehicles in the system to authenticate with the corresponding RSU. Therefore, once these RSU private keys are maliciously leaked or disseminated by vehicles, the RSUs, may be subject to malicious access and information tampering by attackers. This can have disastrous consequences for the entire VANET.

Inspired by the above problem, we propose a privacy-preserving V2I fast authentication scheme. The scheme ensures the confidentiality of RSUs’ private keys and the route privacy of vehicles through an improved oblivious transfer algorithm. In the route-planning phase, when a vehicle requests an RSU authentication key from the CA, the vehicle sends its planned route information to the CA, which is encrypted using the OT algorithm so that the CA cannot know which RSUs the vehicle passes through. In addition, the RSU authentication key returned by the CA to the vehicle is the vehicle’s public identity key added to the RSU private key. This ensures that the RSU’s authentication key can only be used by the requesting vehicle. Even if the authentication key of the RSU obtained by the vehicle is leaked, the security of the RSU private key can still be guaranteed. Therefore, while protecting the RSU private key, the route privacy of the vehicle is also protected.

3. Preliminaries

In this section, we focus on elliptic curve cryptography (ECC) and oblivious transfer (OT) as used in this paper.

3.1. Elliptic Curve Cryptography

Let $F_p$ be a finite field and p be a large prime order. E is an elliptic curve defined by $y^2=x^3+ax+bmodp$, where $a,b\in F_p$ is a constant and $4a^3+27b^2\ne 0$. Suppose that the infinitely far point is O; then, O and all the points on E form a cyclic additive group G with the order q, and its generator is P. The elliptic curve group (G) has the following properties.

• Point addition: Let $P,Q\in G$ be two points on E. If P and Q are not the same, there exists a point, $R=P+Q$, where R is the intersection of straight lines on E connecting P and Q. If P and Q are the same, then $R=P+P=2P$. If $P=-Q$, then $P+Q=O$.
• Scalar point multiplication: Scalar multiplication on E is the repeated addition of a point. Let $P\in G$, $n\in Z_q^{\ast }$; then, $n·P=\underset{n}{\underbrace{P+P+\cdots +P}}$.
• Elliptic curve discrete logarithm problem (ECDLP): Given two random points ($P,R\in G$), compute $R=x·P$, where $x\in Z_q^{\ast }$. It is difficult to compute x from R in probabilistic polynomial time.
• Elliptic curve computational Diffie–Hellman problem (ECCDHP): Given three random points ($P,Q,R\in G$), compute $Q=x·P,R=y·P$, where $x,y\in Z_q^{\ast }$. It is difficult to compute $xyP$ in probabilistic polynomial time.

3.2. Oblivious Transfer

Oblivious transfer (OT) is a basic cryptographic primitive that is widely used in areas such as secure multi-party computation. OT was first proposed by Michael O. Rabin [33] in 1981. In Rabin’s OT protocol, the sender, Alice, sends a message (m) to the receiver, Bob, and the receiver (Bob) accepts the message (m) with a $1/2$ probability. Therefore, at the end of the communication, Alice has no way of knowing which message Bob has accepted. Subsequently, after continuous improvement by researchers, it can be generalized to the k-out-of-n OT $\left(O{T}_n^k\right)$ scheme. In general, there are two entities in an $O{T}_n^k$, namely a sender containing n messages and a receiver who wants to receive k messages from the sender’s n messages. The receiver can select k messages from the n messages, denoted as $O{T}_n^k$. In other words, the receiver can only receive the k messages it has selected, and the sender has no way of knowing which specific messages the receiver has received [34]. $O{T}_n^k$ is defined as follows: Alice holds n messages, and Bob wants k of them. Bob encrypts the desired k messages and sends them to Alice, who encrypts all of them and returns them to Bob. In the end, Bob can only receive the messages he wants. In particular, Alice does not know the details of the information obtained by Bob, while Bob cannot be informed of the other information Alice has. The specific process is shown in Figure 1 below.

4. Models and Design Goals

In this section, the system model, attack model, and design goals of the proposed scheme are presented.

4.1. System Model

The system model in this scheme consists of three main entities, namely the certification authority (CA), the roadside unit (RSU), and the vehicle with an OBU installed. The responsibilities of each entity are described as shown in Figure 2 below:

• CA: The CA is the highest administrator within VANETs, with sufficient computing and storage capacity. The CA is mainly responsible for setting system parameters, vehicle registration, storage and distribution of RSU authentication keys, and assisting in vehicle identity authentication. Although the CA will strictly follow the predefined relevant protocols, it is also expected to infer private information such as the vehicle’s departure location, driving status, and trip destination from the vehicle’s request information.
• RSU: RSUs are roadside-installed infrastructure that are primarily responsible for collecting and processing data from vehicles to provide real-time information on traffic conditions and related services. In addition, they work with the CA to ensure the security of vehicle identities and communications. Through the deployment of RSUs, vehicles can effectively communicate and collaborate with road infrastructure and other vehicles.
• Vehicle: As mobile nodes in VANETs, vehicles with OBUs installed have communication and sensing capabilities. They communicate with RSUs, and other vehicles through their OBUs to obtain real-time traffic information and vehicle condition data. In addition, vehicles can share their own information with other vehicles, leading to collaborative operations between vehicles, thereby optimizing the ITS.

4.2. Attack Model

This section demonstrates some of the security threats that can be suffered in this scheme. The registration phase of the scheme occurs on a secure communication channel. Apart from that, the communication between the vehicle and other entities (RSUs, CA and other vehicles) in other phases takes place on an open and unsecured wireless communication channel, which provides breakthrough opportunities for attackers. The identities of RSUs are made public so that vehicles can plan their travel paths. The main elements involved in the attack model of this protocol are shown below.

• An attacker can easily access the public channel and intercept, replay, modify, and forge the messages transmitted on that channel.
• No attacker is able to modify, read, or delete any information stored in the vehicles and RSUs.
• It is assumed that CA and RSUs will honestly implement the designed protocols, but these entities still wish to infer the vehicle’s privacy from the obtained information, such as private information about the vehicle’s travel path and departure time.
• Suppose a vehicle wants to infer the private key of an RSU from the RSU authentication key obtained by the CA to generate an authentication key suitable for use by any vehicle.

4.3. Design Goals

In order to address the issues of confidentiality of RSU private keys and route privacy of vehicles in VANETs, this scheme should achieve the following security and privacy objectives:

• RSU private key confidentiality: RSUs’ private keys should be confidential to other entities (except the CA). Other entities are prevented from misusing an RSU’s private key for attacks such as malicious access to the RSU.
• Route privacy: Protecting vehicle route privacy is critical during the route-planning phase when the CA assists a vehicle in requesting an RSU’s authentication key. If the system fails to meet this requirement, then the CA can easily access the traveling path of any vehicle.
• Traceability: Once the presence of a malicious vehicle is detected as a threat to the security of a VANET, the CA obtains the real identity of the vehicle and revokes its identity information, preventing it from jeopardizing the security of the VANET.
• Unlinkability: An attacker cannot determine whether two or more received messages originate from the same sender. In other words, the attacker cannot trace the real identity of a vehicle by analyzing the messages sent by the vehicle.
• Resistance to common security attacks: Our scheme is resistant to several common security attacks, such as Sybil attacks, modification attacks, replay attacks, and repudiation attacks.

5. Proposed Scheme

This scheme consists of four phases, namely a system initialization phase, registration phase, route-planning phase, and V2I authentication phase. The notations used in our scheme are shown in

Table 1. List of notations.

Notations	Description
G	Cyclic addition group of elliptic curves
$q,P$	The order and generator of G
$s,P_{CA}$	System master private and public key of the $CA$
$c_i$	Private key of $V_i$
$C_i$	The public identity key of $V_i$
$RI{D}_i,PI{D}_i$	The real identity and pseudonym of $V_i$
$m_j$	Private key of $RS{U}_j$
$A{K}_t$	The authentication key of $RS{U}_t$
$\left|\right|,\oplus$	Concatenation and XOR operations
$H_{i,i=0,1,2,3}$	Secure hash functions
$T_{i,i=0,1,2,3}$	The timestamp
$E_s(.),D_s(.)$	Symmetric encryption and decryption
$E_a(.),D_a(.)$	Asymmetric encryption and decryption

. Meanwhile, in order to describe the work of each entity at each stage more intuitively, Figure 3 shows the workflow of each entity in VANETs.

5.1. System Initialization Phase

In this phase, the CA sets up all the necessary system parameters and releases them. To ensure smooth system initialization, the CA needs to perform the following specific steps:

Step 1: The CA selects a security parameter ($\lambda$) and a non-singular elliptic curve ($E(y^2=x^3+ax+b$, where $a,b\in F_p)$) according to the system requirements. Subsequently, an additive cyclic group (G, containing all points on elliptic curve E and one infinity point) of prime order q and generating element P is selected over finite domain ${\mathbb{F}}_p$.

Step 2: The CA selects a random number ($s\in Z_p^{\ast }$) as the system master private key, then computes the corresponding system public key ($P_{CA}=sP$).

Step 3: The CA selects several secure one-way hash functions ($H_0:{\{0,1\}}^{\ast }\to Z_p^{\ast },H_1:{\{0,1\}}^{\ast }\to G,H_2:G\to {\{0,1\}}^l,H_3:G\to Z_p^{\ast }$, where l denotes a fixed length bit string).

Step 4: Assume that all RSUs are labeled within the system as ${\left\{RS{U}_j\right\}}_{j=1,2,\dots ,n}$. The CA assigns a corresponding private key (${\{m_j\in Z_q^{\ast }\}}_{j=1,2,\dots ,n}$) to each RSU by secure means. The CA stores the relevant information of all RSUs ($\left\{\right(RS{U}_j\parallel m_j\parallel inf{o}_j{\left)\right\}}_{j=1,2,\dots ,n}$, where $inf{o}_j$ is the additional information of $RS{U}_j$). The private key ($m_j$) needs to be updated periodically. The RSU information is stored in the format shown in

Table 2. RSU information.

NO	Private Key	Information
${RSU}_1$	$m_1$	${info}_1$
${RSU}_2$	$m_2$	${info}_2$
…	…	…
${RSU}_j$	$m_j$	${info}_j$
…	…	…
${RSU}_n$	$m_n$	${info}_n$

below.

Step 5: The CA chooses the symmetric encryption algorithm ($E_s$), the symmetric decryption algorithm ($D_s$), the asymmetric encryption algorithm ($E_a$), and the asymmetric decryption algorithm ($D_a$). The algorithms are described as follows:

• Symmetric encryption: $c=E_s(sk,m)$, where c is the cipher text, $sk$ is the private key, and m is the plain text.
• Symmetric decryption: $m=D_s(sk,c)$.
• Asymmetric encryption: $c=E_a(PK,m)$, where c is the cipher text, $PK$ is the public key, and m is the plain text.
• Asymmetric decryption: $m=D_a(sk,c)$, where $sk$ is the private key.

Step 6: The CA secretly stores the system master private key (s) and publishes the system parameters ($parames=\{G,p,P,P_{CA},E_s,D_s,E_a,D_a,H_{i,i\in (0,1,2,3)}\}$) to all entities.

5.2. Registration Phase

Vehicles are required to register with the CA before entering the communication system. Only a successful registration will make a vehicle a legitimate user. The registration phase takes place over a secure communication channel, and the vehicle registration details are described below.

Step 1: Vehicles ($V_i$) with real identities ($RI{D}_i\in Z_q^{\ast }$) need to be registered by the CA. $V_i$ selects a random number ($a_i\in Z_p^{\ast }$) and calculates $A_i=a_{i}P$. Finally, $V_i$ sends $<RI{D}_i,A_i>$ to the CA over a secure channel.

Step 2: After receiving $<RI{D}_i,A_i>$ from $V_i$, the CA selects a random number ($b_i\in Z_p^{\ast }$) and calculates $B_i=b_{i}P$. The CA then generates a private key ($c_i=b_i+s·H_3(A_i\left|\right|B_i)modq$) and public identity key ($C_i=B_i\oplus H_0\left(RI{D}_i\right)·A_i$) for $V_i$ and calculates the pseudonym ($PI{D}_i=RI{D}_i\oplus H_0\left(s\right||c_i\left|\right|T_0)$, where $T_0$ is the valid time of the pseudonym). Finally, the CA sends $<c_i,PI{D}_i>$ to $V_i$ over a secure channel and stores the corresponding $<b_i,c_i,C_i,RI{D}_i,PI{D}_i,T_0>$ in the local database.

Step 3: $V_i$ stores $<c_i,PI{D}_i>$ after receiving $<c_i,PI{D}_i>$.

5.3. Route-Planning Phase

In this phase, the vehicle first plans its travel route to identify the RSUs that it will pass through. Then, the vehicle requests authentication information from the CA for these RSUs. In this way, the vehicle can quickly authenticate with the RSUs on the route while traveling. Finally, Figure 4 illustrates the interaction process of vehicle’s route planning.

Step 1: Before the trip starts, the vehicle ($V_i$) plans its path through the Dijkstra algorithm and obtains the RSUs it will pass through ($pat{h}_k={\{RS{U}_1,RS{U}_2,\dots ,RS{U}_t,\dots RS{U}_n\}}_{t\in \{1,2,\dots ,n\}}$). $V_i$ needs to obtain these k RSU private keys (${\{m_1,m_2,\dots ,m_t,\dots m_n\}}_{t\in \{1,2,\dots ,n\}}$) corresponding to the authentication key (${\{A{K}_1,A{K}_2,\dots ,A{K}_t,\dots ,A{K}_n\}}_{t\in \{1,2,\dots ,n\}}$).

Step 2: $V_i$ encrypts the k RSU numbers in sequence to calculate $P_t=H_1\left(t\right)$. Then, $V_i$ selects k random numbers ($r_p\in Z_q^{\ast }$) and computes $E_p=r_p{P}_t$, obtaining $ET=\{E_1,E_2,\dots ,E_k\}$, where $t\in \{1,2,\dots ,n\},p=1,2,\dots ,k$. $V_i$ is then utilized $P_{CA}$ to encrypt $ET$ to compute $\rho =E_a(P_{CA},ET)$.

Step 3: $V_i$ generates a timestamp $T_1$ and calculates $\eta =H_0\left(\rho \right||PI{D}_i\left|\right|T_1)$. Finally, $V_i$ sends $<PI{D}_i,\rho ,\eta ,T_1>$ to the CA.

Step 4: After receiving $<PI{D}_i,\rho ,\eta ,T_1>$, the CA first checks the validity of $T_1$, then queries the pseudonym of $V_i$ to check the legitimacy of the vehicle identity. The message is accepted if both checks pass; otherwise, the message is rejected. Next, the CA verifies $\eta =H_0\left(\rho \right||PI{D}_i\left|\right|T_1)$ and accepts $\rho$ if the content ($\eta$) has not been tampered with; otherwise, it rejects $\rho$.

Step 5: The CA decrypts $D_a=(s,\rho )$ to obtain $ET$ using its own private key (s) to $\rho$. The CA selects a random number ($x\in Z_p^{\ast }$) and calculates $F_a={\{f_p=x{E}_p\}}_{p=1,2,\dots ,k}$ for the elements within $ET$. Then, it queries the vehicle’s public identity key ($C_i$) based on the $PI{D}_i$ of $V_i$ and uses $C_i$ to encrypt the private keys of all $RS{U}_j$ to obtain the corresponding authentication key. The specific calculations are $P_j=H_1\left(j\right)$, $A{K}_j=H_2(m_j·C_i)$, and $G_a=\{g_j=A{K}_j\oplus H_2\left(x{P}_j\right)\}$, where $j=1,2,\dots ,n$. Finally, the computed information is encrypted ($F_b=E_s(c_i,F_a)$,$G_b=E_s(c_i,G_a)$).

Step 6: The CA generates a timestamp ($T_2$) and calculates $\delta =H_0(F_b\left|\right|T_2)$ and $\sigma =H_0(G_b\left|\right|T_2)$. Finally, it sends $<\delta ,\sigma ,F_b,G_b,T_2>$ to $V_i$.

Step 7: After receiving $<\delta ,\sigma ,F_b,G_b,T_2>$, $V_i$ checks the validity of $T_2$ first, then calculates $\delta =H_0(F_b\left|\right|T_2)$ and $\sigma =H_0(G_b\left|\right|T_2)$. If both are valid, it accepts $F_b,G_b$; otherwise, it rejects $F_b,G_b$.

Step 8: $V_i$ decrypts $F_b$ and $G_b$ by calculating $\left\{f_p\right\}=D_s(c_i,F_b)$ and $\left\{g_j\right\}=D_s(c_i,G_b)$ using private key $c_i$. $A{K}_t=g_t\oplus H_3\left(K_p\right)$ is then obtained by calculating $K_p=r_p^{-1}{f}_p$. The specific calculations of $K_p$ and $A{K}_t$ are shown in the following equations:

$$\begin{array}{cc}\hfill K_p& =r_p^{-1}{f}_p\hfill \\ & =r_p^{-1}x{E}_p\hfill \\ & =r_p^{-1}{r}_{p}x{P}_t\hfill \\ & =x{P}_t\hfill \end{array}$$

(1)

When $j=t$:

$$\begin{array}{c}{g}_t\oplus H_2\left(K_p\right)\hfill \\ =A{K}_t\oplus H_2\left(x{P}_t\right)\oplus H_2\left(K_p\right)\hfill \\ =A{K}_t\oplus H_2\left(x{P}_t\right)\oplus H_2\left(x{P}_t\right)\hfill \\ =A{K}_t\hfill \end{array}$$

(2)

5.4. V2I Authentication Phase

Since the vehicle has acquired the corresponding RSU authentication key on the path, when the vehicle ($V_i$) enters the communication range of $RS{U}_t$, it and $RS{U}_t$ quickly complete the mutual authentication work. The steps for quick authentication of $V_i$ and $RS{U}_t$ are as follows:

Step 1: When the vehicle $V_i$ enters the communication range of $RS{U}_t$, the vehicle selects a random number ($v{r}_i\in Z_q^{\ast }$) and a timestamp ($T_3$) and calculates $c{t}_i=E_s(A{K}_t,PI{D}_i\left|\right|v{r}_i\left|\right|T_3)$ and ${\phi }_i=H_0(PI{D}_i\left|\right|c{t}_i\left|\right|T_3)$. Finally, $V_i$ sends $<PI{D}_i,{\phi }_i,c{t}_i,T_3>$ to $RS{U}_t$.

Step 2: When $RS{U}_t$ receives $<PI{D}_i,{\phi }_i,c{t}_i,T_3>$, it first verifies the validity of the check message time ($T_3$). If it is valid, then the subsequent validation continues; otherwise, the communication is rejected. Then, it verifies the validity of $PI{D}_i$ to $CA$. If $PI{D}_i$ is legitimate, then the corresponding $C_i$ is returned to $RS{U}_t$; otherwise, the vehicle pseudonym is broadcast as illegal. Finally, the correctness of ${\phi }_i=H_0(PI{D}_i\left|\right|c{t}_i\left|\right|T_3)$ is calculated. If the checksum passes, then $c{t}_i$ is received; otherwise, $c{t}_i$ is rejected.

Step 3: $RS{U}_t$ obtains $A{K}_t$ by calculating $A{K}_t=H_2(m_t·C_i)$. Then, it uses $A{K}_t$ for decryption calculation ($PI{D}_i\left|\right|v{r}_i\left|\right|T_3=D_s(A{K}_t,c{t}_i)$) to obtain $v{r}_i$.

Step 4: $RS{U}_t$ calculates ${\gamma }_t=H_0(v{r}_i+1)$. Finally $RS{U}_t$, sends ${\gamma }_t$ to $V_i$.

Step 5: $V_i$ receives ${\gamma }_t$ and calculates ${\gamma }_i=H_0(v{r}_i+1)$. If ${\gamma }_i={\gamma }_t$, the authentication between $V_i$ and $RS{U}_t$ is successful; otherwise, the authentication fails.

6. Security Analysis

This section focuses on proving that our scheme is able to achieve the design goals presented in Section 4.3. The security of our scheme is compared with the schemes proposed in [29,30,31,32] in terms of confidentiality of RSU private keys, route privacy, traceability, unlinkability, and resistance to common security attacks. The analysis results show that our scheme provides more advantages. The comparison results are listed in

Table 3. Comparison results with respect to safety requirements.

						Common Security Attacks
Scheme	RSU Private Key Confidentiality	Route Privacy	Traceability	Unlinkability	Sybil	Modification	Replay	Repudiation
[29]	×	√	×	×	√	√	×	×
[30]	×	√	√	√	√	√	√	√
[31]	×	×	√	√	×	×	×	√
[32]	×	√	√	√	√	√	√	√
Our Scheme	√	√	√	√	√	√	√	√

, where × means that the scheme does not have the corresponding security requirements and √ means that the scheme has the corresponding security requirements.

• RSU private key confidentiality: In the route-planning phase, the CA combines the $RS{U}_t$ private key ($m_t$) and the $V_i$ public identity key ($C_i$) to generate the authentication key ($A{K}_t=H_2(m_t·C_i)$), which is only applicable to the vehicle, then sends it to the vehicle. If the vehicle wants to derive $m_t·C_i=H_2^{-1}\left(A{K}_t\right)$ from the known $A{K}_t$ and $C_i$, it needs to solve the unidirectionality problem of the one-way hash function first. However, the unidirectionality problem of the hash function is very difficult to overcome. Therefore, the confidentiality of $m_t$ can be guaranteed.
• Route privacy: In the route-planning phase, $V_i$ encrypts the information of the k RSU numbers that the planned path needs to pass through to calculate ${\{P_t=H_5\left(t\right)\}}_{t\in 1,2,\dots ,n}$ and ${\{E_p=r_p{P}_t\}}_{p=1,2,\dots ,k}$, then send $\left\{E_p\right\}$ to the CA. If the CA wants to derive $pat{h}_k={\left\{RS{U}_t\right\}}_{t\in \{1,2,\dots ,n\}}$, then it needs to obtain the correspondence between $E_p$ and $P_t$. If the CA wants to obtain the correspondence between $E_p$ and $P_t$, it needs to solve the ECDLP problem of ECC to obtain ${\{r_p\in Z_p^{\ast }\}}_{p=1,2,\dots ,k}$. However, the CA is well within the hard probabilistic polynomial time to solve the ECDLP problem of ECC to obtain ${\{r_p\in Z_p^{\ast }\}}_{p=1,2,\dots ,k}$. In addition, if the CA wishes to derive the travel path of $V_i$ by calculating $t=H_1^{-1}\left(P_t\right)$, it needs to solve the unidirectionality problem of the one-way hash function first. However, the unidirectionality problem of the one-way hash function is difficult to overcome. In summary, the CA cannot infer from $V_i$’s message which RSUs $V_i$ will pass through, and $V_i$’s route privacy is protected.
• Traceability: Although the real identity of a vehicle is hidden in a pseudonym, when an anonymous vehicle in the system sends a message that is disputed, the CA can calculate its real identity based on its pseudonym. Since $b_i$ and s are stored in the CA’s database, the CA can obtain the real identity of the vehicle by calculating $RI{D}_i=PI{D}_i\oplus H_0\left(s\right||c_i\left|\right|T_0)$. Therefore, traceability can be guaranteed.
• Unlinkability: In this scheme, each $PI{D}_i$ is created using a different random number ($b_i\in Z_p^{\ast }$), each pseudonym is updated periodically, and the pseudonyms contained within each message are indistinguishable. Therefore, an attacker cannot link any two or more messages to a particular vehicle.
• Resistance to common security attacks: The scheme proposed in this paper is able to resist several common security attacks, such as Sybil attacks, modification attacks, replay attacks, and repudiation attacks. The proof details are shown below.

  – 

  Sybil attacks: Since the pseudonym of the vehicle is generated by the CA through the vehicle’s real identity ($RI{D}_i$), the system private key (s), and vehicle private key ($c_i$), n attacker cannot obtain this information to generate a valid pseudonym. In addition, the attacker cannot know the rules for generating pseudonyms. Therefore, the attacker cannot utilize a pseudonym to realize a Sybil attack.

  – 

  Modification attacks: We resist modification attacks using secondary encryption of the message through a hash function. For example, $V_i$ sends a request message as $<PI{D}_i,\rho ,\eta ,T_1>$ when it applies for the authentication key of an RSU from the CA. When the CA receives the message, it calculates ${\eta }^{\prime }=H_0\left(\rho \right||PI{D}_i\left|\right|T_1)$, and if ${\eta }^{\prime }=\eta$, it proves that the message has not been modified. Thus, our scheme is resistant to modification attacks.

  – 

  Replay attacks: We include a timestamp ($T_i$) in both the message and the content of the communication to resist replay attacks. Each entity generates a timestamp ($T_i^{\prime }$) when it receives a message, and if $T_i^{\prime }-T_i<\Delta T$, the message is fresh. $\Delta T$ denotes a fixed value set by the system. Therefore, the receiver of a message can detect a replay attack by verifying the timestamp contained in the message.

  – 

  Repudiation attacks: When a vehicle wants to deny a message that has been sent, the CA can hold the vehicle responsible by calculating $RI{D}_i=PI{D}_i\oplus H_0\left(s\right||c_i\left|\right|T_i)$ to obtain the real identity of the corresponding vehicle based on the pseudonym information in the message. Therefore, our scheme is capable of low resistance to repudiation attacks.

7. Performance Evaluation

This section focuses on the comparative analysis of the performance overhead of our scheme with the schemes proposed in [29,30,31,32]. The comparative analysis considers computational overhead, communication overhead, and packet loss rate. This is to demonstrate the performance advantages of our proposed scheme. Our comparison experiments were conducted on a laptop computer. The laptop consists of a Quad-Core Intel Core i5 processor with a clock frequency of 1.4 GHz, 16 GB of operating memory, and a macOS Catalina operating system.

7.1. Computational Overhead Comparison

In order to count the computational overhead of each scheme, we experimented with the time overhead of some major cryptographic operations. Each cryptographic operation was run 1000 times, and the average value was taken as the final time overhead. The time overhead statistics of the relevant cryptographic operations are described in

Table 4. Execution time of primary operations.

Notation	Description	Execution Time (ms)
$T_H$	One-way hash function operation	0.016
$T_H^m$	Hash-to-map hash function operation	2.851
$T_{ecc}^a$	Point addition operation on ECC	0.024
$T_{ecc}^m$	Scalar multiplication operation on ECC	1.064
$T_{exp}$	Power operation	0.190
$T_{bp}$	Bilinear pairing operation	5.761
$T_{bgn}^a$	BGN homomorphic addition	0.283
$T_{bgn}^m$	BGN homomorphic multiplication	0.632
$T_s^e$	AES symmetric encryption	0.018
$T_s^d$	AES symmetric decryption	0.016
$T_a^e$	RSA asymmetric encryption	0.062
$T_a^d$	RSA asymmetric decryption	1.139
$T_e^e$	ElGamal asymmetric encryption	0.348
$T_e^d$	ElGamal asymmetric decryption	0.239

.

Since the registration phase is a one-time process, to be fair, only the computational overheads of the route-planning phase and the V2I authentication phase are compared. In the route-planning phase, the vehicle plans its traveling path in advance. Assuming that there are a total of n RSUs in the VANET, the vehicle’s planned path needs to pass through k RSUs. In our scheme, the computational overhead of the vehicle in the route-planning phase is $2k{T}_H^m+2k{T}_{ecc}^m+T_a^e+2T_s^d+3T_H=7.83k+0.142$, and the computational overhead required in the V2I authentication phase is $T_s^e+2T_H=0.05$. Therefore, the total computational overhead on the vehicle side is $7.83k+0.142+0.05=7.83k+0.192$. The CA side only participates in computation during the route-planning phase; therefore, the total computational overhead of the CA is $3n{T}_H^m+2n{T}_{ecc}^m+k{T}_{ecc}^m+2T_s^e+T_a^d+3T_H=10.681n+1.064k+1.223$. The RSU side only participates in computation during the V2I authentication phase, so the total computational overhead of an RSU is $T_H^m+T_{ecc}^m+T_s^e+2T_H=3.963$. Ultimately, the total computational overhead of our proposed scheme is $7.83k+0.192+10.681n+1.064k+1.233+3.963=10.681n+8.894k+5.388$. The total computational overhead of several other related protocols for each entity was similarly analyzed and calculated using the same method, and the results are displayed in

Table 5. Computational overhead for each scheme.

Scheme	Vehicle (ms)	RSU (ms)	CA (ms)	Total (ms)
[29]	$0.283(n+k)+1.315$	$0.048$	$0.283n^2+0.632n+1.233$	$0.283n^2+0.915n+0.283k+2.596$
[30]	$3.248k+0.144$	$0.048$	$0.058\ast n\ast k+1.064(n+k)+1.171$	$0.058\ast n\ast k+1.064n+4.312k+1.363$
[31]	$6.38k+4.269$	$1.13$	$0.19\ast n\ast k+0.348n$	$0.19\ast n\ast k+0.348n+6.38k+5.399$
[32]	$0.19k+7.325$	$0.048$	$0.19\ast n\ast k+0.032$	$0.19\ast n\ast k+0.19k+7.405$
Our Scheme	$7.83k+0.192$	$3.963$	$10.681n+1.064k+1.233$	$10.681n+8.894k+5.388$

.

Since the computation time of the route-planning phase is mainly related to the number of RSUs, the number of RSUs in the system needs to be determined by the coverage of the system. We determined the range of our scheme based on the communication coverage method proposed by Gang et al. [35]. Take the city of Houston in the U.S. as an example. The area of Houston is about 1659.4 square kilometers [36]. The maximum communication distance of an RSU is 1 km, and the communication coverage area of an RSU is about 3.14 square kilometers. Approximately 500 RSUs are required to cover the entire city of Houston. Therefore, we take 500 RSUs in the system as an example to analyze the computational overhead corresponding to different protocols. The results of the analysis are shown in Figure 5 below.

As can be seen in Figure 5, the computational overhead of the scheme proposed in [29] is high and appears to converge at a specific value. This is because the computational overhead of the scheme proposed in [29] is highly correlated with the number of RSUs in the system and less correlated with the number of RSUs for vehicle path planning. In the scheme proposed in [29], the vehicle marks the numbers of n RSUs in the system to determine the travel path and encrypts the marked n numbers and sends them to the CA. The CA performs n BGN homomorphic encryptions on the n RSU private keys in the system to return to the vehicle, and the vehicle obtains the required k RSU authentication key by decryption. Combined with the results in Table 5, it can be known that the computational overhead of the scheme proposed in [29] depends very much on the number of RSUs in the system (n), while the number of RSUs for vehicle path planning has less of an impact. Therefore, the computational overhead of the scheme proposed in [29] is high and appears to converge at a specific value.

The overall overhead of the scheme proposed in [30] is better than that of our proposed scheme when the number of RSUs in the path-planning phase is within 200. This is due to the fact that the CA of the scheme proposed in [30] returns an $n\ast k$ ciphertext matrix based on the number of RSUs in path planning (k), where n is the number of RSUs in the system. All the ciphertext elements inside the ciphertext matrix are encrypted by a one-way hash function and symmetric encryption algorithm. When n is determined, there is a strong correlation between the computational overhead of the ciphertext matrix and k. In our scheme, the CA returns a list of cipher texts of $n+k$ according to the number of RSUs in vehicle path planning k. When n is determined, the correlation between the computational overhead of the ciphertext list and k is smaller than that for the scheme proposed in [30]. The elements of the ciphertext list are encrypted by the a hash-to-map function and the symmetric encryption algorithm. From Table 4, it can be seen that the computational overhead of the hash-to-map function is higher than the computational overhead of the one-way hash function used in the scheme proposed in [30]. Therefore, when the number of RSUs in the system (n) is set to 500, with a smaller value of k, the computational overhead of the CA in the case reported in [30] is relatively smaller. In the scheme proposed in [31], the CA uses an exponentially correlated encryption algorithm for all RSU authentication keys. The overall computational overhead is highly correlated with both n and k. When n is determined, with a smaller k, the computational overhead is relatively reduced. The computational overhead of the scheme proposed in [32] follows the same principle as that of the scheme proposed in [31]. In short, our scheme uses a relatively time-consuming hash-to-map function to ensure the confidentiality of RSU private keys. However, our overall computational overhead is less correlated with the number of RSUs for path planning. Therefore, when the number of RSUs in the system is determined, with a smaller number of RSUs for path planning, the overall computational overhead of our scheme is relatively increased.

In summary, when the number of RSUs in vehicle path planning is small, our scheme’s computational overhead performs slightly worse than that of the schemes proposed in [30,31,32]. As the number of RSUs in vehicle path planning increases, the total computational overhead of the schemes proposed in [30,31,32] tends to increase linearly. The scheme proposed in [29] is in a relatively smooth state, but its total computational overhead is several times higher than that of the other schemes. Overall, the total computational overhead of our scheme is generally lower and grows most slowly. It also ensures the confidentiality of RSU private keys. Therefore, our scheme performs better than all compared schemes in terms of total computational overhead and security.

Since most of the computational overheads of the relevant schemes for path planning depend on the CA side, we analyzed the computational overhead relationship between different protocols from the perspective of the CA side. The results of the analysis are shown in Figure 6.

In Figure 6, it can be seen that the CA’s computational overheads in the scheme proposed in [29] and our scheme do not float much. From Table 5, we can learn that the computational overhead on the CA side of our scheme is $10.681n+1.064k+1.233$, n is the number of RSUs present in the system, and k is the number of RSUs in vehicle path planning. When there are 500 RSUs in the system, the number of RSUs in path planning is in the range of 100 to 500, corresponding to the computational overhead of the CA side in the range of $5448.133$ ms to $5873.733$ ms, which is a difference of $425.6$ ms. The performance of $425.6$ ms is not significant within the Y-axis range of 0 ms–80,000 ms in the statistical chart. Therefore, this is why Figure 6 appears to show the same value for all RSU numbers. The principle is similar in scheme [29]. The difference is that the scheme proposed in [29], uses BGN homomorphic encryption in encrypting the authentication keys of RSUs and encrypts the private keys of n RSUs n times. This leads to a large computational overhead required by the CA. The CA side of both the scheme proposed in [31] and the scheme proposed in [32] uses similar encryption operations and performs $n\ast k$ encryption operations on the authentication key of the RSU. Therefore, the CA’s computational overhead in the scheme proposed in [31] and the scheme proposed in [32] increases with the number of RSUs for path planning. Overall, the computational overhead on the CA side of the scheme proposed in [29] is much higher than that of other schemes, and the computational overhead on the CA side of the schemes proposed in [30,31,32] tends to increase. In our scheme, on the other hand, the computational overhead of the CA is the lowest and slowest-growing overall. Therefore, the CA’s computation overhead in our scheme performs better than that in all compared schemes.

7.2. Communication Overhead Comparison

In this section, we focus on analyzing the communication overhead in the route-planning phase and the V2I authentication phase. For security purposes, we constructed the bilinear pair cryptography algorithm and elliptic curve cryptography algorithm with a security level of 128 bits. First, a bilinear pair cryptography algorithm was constructed, and a group of order $\widehat{q}$ was set up ($G_T$, which denotes the additive group generating elements of $\widehat{P}$ on the hyper-singular elliptic curve ($\widehat{E}:y^2=x^3+xmod\widehat{p}$)). Secondly, we constructed an elliptic curve cryptography algorithm, where the q order group (G) denotes the additive group that generates the element as P on a non-singular elliptic curve ($E:y^2=x^3+ax+bmodp$). Then, the sizes of groups $G_T$ and G were $\left|G_T\right|=1024$ bits and $\left|G\right|=512$ bits, respectively. For fairness, it is assumed that the length of the identity in all schemes is $\left|I\right|=256$ bits, the length of the random number is $\left|Z_p^{\ast }\right|=256$ bits, the length of the hash value $SHA-256$ is $\left|H\right|=256$ bits, the length of the timestamp is $\left|T\right|=32$ bits, the length of the cipher text for AES encryption is $\left|AES\right|=256$ bits, the ciphertext length of RSA encryption is $\left|RSA\right|=1024$ bits, and the ciphertext length of ElGamal encryption is $\left|ELG\right|=1024$ bits.

In the route-planning phase, it is assumed that there are a total of n RSUs in the VANET and that the route planned by the vehicle needs to pass through k RSUs. In this paper’s scheme, the message sent by the vehicle to the CA is $<PI{D}_i,\rho ,\eta ,T_1>$, and the spent communication overhead is $256+1024+256+32=1568$ bits. The message sent by the CA to the vehicle is $<\delta ,\sigma ,F_b,G_b,T_2>$, and the spent communication overhead is $256+256+k\ast 256+n\ast 256+32=256\ast (n+k)+544$ bits. Therefore, the total communication overhead is $256\ast (n+k)+544bits+1568bits=256\ast (n+k)+2112$ bits. The total communication overheads of several other related protocols in the route-planning phase can be similarly analyzed. The specific results are displayed in

Table 6. Communication overhead in the route-planning phase.

Scheme	Vehicle (bits)	CA (bits)	Total (bits)
[29]	$1024+256+32=1312$	$1024\ast n+32+256+256=1024n+554$	$1024n+1866$
[30]	$256+1024+256+32=1568$	$256\ast n\ast k+256+32=256\ast n\ast k+288$	$256\ast n\ast k+1856$
[31]	$1024\ast k=1024k$	$1024\ast n=1024\ast n$	$1024n+1024k$
[32]	$1024+256+32=1312$	$256\ast n\ast k+256+32=256\ast n\ast k+288$	$256\ast n\ast k+1600$
Our Scheme	$256+1024+256+32=1568$	$256+256+256\ast k+256\ast n+32=256\ast (n+k)+544$	$256\ast (n+k)+2112$

.

In order to more intuitively observe the communication overhead of all protocols in the route-planning phase, according to the inference of 7.1, we also take the existence of 500 RSUs in the system as an example to analyze the relationship between the number of RSUs in path planning and the corresponding communication overhead of different protocols. The analysis results are shown in Figure 7.

From Figure 7, it can be seen that the total communication overhead of all the schemes increases linearly with the increase in the number of RSUs on the vehicle path. From Table 6, we can learn that in the route-planning phase, the communication overhead of the scheme proposed in [29] is $1024\ast n+1866$ (bits), where n is the number of RSUs in the system and k is the number of RSUs in vehicle path planning. The communication overhead of the scheme proposed in [30] is $256\ast n\ast k+1856$ (bits), that of scheme [31] is $1024\ast n+1024\ast k$ (bits), and that of scheme [32] is $256\ast n\ast k+1600$ (bits). It can be seen that the communication overhead of the scheme proposed in [29] is dependent on the number of RSUs present in the system but is not affected by the number of RSUs in path planning, whereas the communication overhead of the schemes proposed in [30,31,32] is not only affected by the number of RSUs in the system but also by the number of RSUs in path planning. The communication overhead of the schemes proposed in [30,32] is significantly higher than that in the other schemes due to the fact that the CA side of the schemes proposed in [30,32] returns the authentication key of the RSU to the vehicle in the form of an $n\ast k$ ciphertext matrix. Our scheme is also affected by the number of RSUs in the system and the number of RSUs in path planning. However, in our scheme, the CA utilizes AES symmetric encryption of the RSU’s authentication key. According to the definition of ciphertext size in this section, the ciphertext size after AES symmetric encryption is 256 bits, and the CA returns the authentication key of the RSU to the vehicle in the form of $n+k$, which greatly reduces the communication burden of the CA. Although the CA side of the scheme proposed in [31] also returns the authentication key of the RSU to the vehicle in the form of $n+k$, they use the ELG encryption algorithm with a ciphertext size of 1024 bits. Therefore, the communication overhead of scheme [31] is higher than that of our scheme. In summary, our scheme has a significant advantage in terms of communication overhead in the route-planning phase.

In the V2I authentication phase, the messages to be communicated by the scheme proposed in [29] are $\{E$_{$K_{RS{U}_i}$}, H(E_{$K_{RS{U}_i}$}), $SPI{D}_v,T_{s3}\}$, and $\left\{H\right(a+1\left)\right\}$, and the expended communication overhead is $256+256+256+32+256=1056$ bits. The messages to be communicated in scheme [30] are $\{AI{D}_j,c_j^i,{\varphi }_j,t_3\}$ and $\left\{{\phi }_i\right\}$, and the spent communication overhead is $256+256+256+32+256=1056$ bits. The messages to be communicated in the scheme proposed in [31] are $\{{\sigma }_i,E_{k_{RS{U}_i}}\left(a\right),PI{D}_i,P_V,T_i\}$ and $\{H_1(a+1),E_{k_{RS{U}_i}}\left(inf{o}_i\right)\}$, and the expended communication overhead is $256+256+256+512+32+256+256=1824$ bits. The messages that need to be communicated in scheme [32] are $\{E_{K_i},H\left(E_{K_i}\right),T_3\}$, $\{E_K,H\left(E_K\right),T_4\}$, and $\left\{H\right(r+1\left)\right\}$, and the spent communication overhead is $256+256+32+256+256+32+256=1344$ bits. The messages to be communicated in our scheme are $\{PI{D}_i,c{t}_i,{\phi }_i,T_3\}$ and $\left\{{\gamma }_i\right\}$, and the spent communication overhead is $256+256+256+32+256=1056$ bits. Finally Figure 8 shows a comparison of the communication overhead of the V2I authentication phase between the different schemes.

As can be seen in Figure 8, the communication overhead in the V2I authentication phase is the same for the schemes proposed in [29,30] and our scheme. This is due to the fact that the communication messages between the vehicle and the RSUs all use similar encryption methods, and the communication content is of the same size. For example, the schemes proposed in [29,30] and our scheme all utilize the RSUs’ authentication keys to symmetrically encrypt the authentication content, then utilize a hash function for secondary encryption to ensure the reliability of the message. According to the definition of ciphertext size in this section, the size of the ciphertext of the request authentication content sent by the vehicle to the RSU is 256 bits, the size of the secondary encryption of the requested authentication ciphertextis 256 bits, the size of the pseudonym is 256 bits, and the size of the timestamp is 32 bits. The size of the ciphertext authentication content returned by the RSU to the vehicle is 256 bits. The communication overheads of the scheme proposed in [29], the scheme proposed in [29], and our scheme are all $256+256+256+32+256=1056$ bits. Therefore, we have the same communication overhead in the V2I authentication phase. But scheme [31] adds a public key $PV$ with a length of 512 bits on the basis of the above to ensure the legitimacy of the message. At the same time, the RSU returns a message to the vehicle with 256 bits of additional RSU information. Therefore, the communication overhead of the scheme proposed in [31] is $256+256+256+256+512+32+256+256=1824$ bits. This shows that the evaluation performance of the scheme proposed in [31] lags behind the other schemes. In this regard, our scheme also maintains good performance in terms of communication overhead in the V2I authentication phase.

7.3. Packet Loss Rate Evaluation

In order to analyze the network availability of each scheme in the V2I authentication phase, we conducted simulation experiments on the data packet loss rate (PLR). Our simulation environment was configured according to the real test scheme for the data packet loss rate proposed by Fan et al. [37]. The simulation experiment environment consists of OMNET++ 5.6.2, SUMO 1.8.0, and Veins 5.2. The main parameters of the simulation environment are shown in

Table 7. Parameter configuration of the simulation.

Parameter	Value
Area	3000 m × 2500 m
MAC Layer	802.11 p
Data Rate	6 Mb/s
Broadcast Interval	1000 m
Number of Vehicles	20∼100
Vehicle Speed	3 m/s∼30 m/s
Simulation Time	300 s

below. The map and all roads in the simulation experiment use the default settings of SUMO.

Figure 9 shows the simulation process of our scheme. From Figure 9, we can visualize the interaction process between the vehicle and RSU for authentication in the V2I authentication phase. The nodes in the figure represent traveling vehicles, and rsu[0] represents the RSU. In addition, green nodes represent vehicle that have completed mutual authentication with the RSU, the white node represents a vehicle that has not yet completed mutual authentication with the RSU, and the red node represents that a vehicle in the process of mutual authentication with the RSU. The blue dotted line indicates that the vehicle and RSU are interacting with each other.

We define the formula for calculating the average packet loss rate according to the calculation of the average packet loss rate of the scheme proposed in [32]. The formula for calculating the packet loss rate is shown in Equation (3) below.

$$\begin{array}{c}\hfill PLR=\left(\frac{N_{sum}^l}{N_{sum}^r+N_{sum}^l}\right)\ast 100\%\end{array}$$

(3)

In Equation (3), $PLR$ denotes the packet loss rate, $N_{sum}^l$ denotes the total number of lost packets, and $N_{sum}^r$ denotes the total number of accepted packets. According to the formula for the packet loss rate, we obtain the experimental results as shown in Figure 10 below.

From Figure 10, we notice that the scheme proposed in [32] has the highest data packet loss rate. This is due to the fact a vehicle needs to send a security message with a length of 544 bits to the surrounding vehicles when it enters the range of the RSU. Then, the vehicle sends a request authentication message with a length of 544 bits to the RSU. The RSU confirms that the vehicle’s authentication message is correct, then returns 256 bit authentication content to the vehicle. Therefore, the scheme proposed in [32] requires frequent communication interactions, and the communication overhead of interaction is large, which leads to the phenomenon of a high packet loss rate in the scheme proposed in [32]. Compared with the scheme proposed in [32], the amount of communication data of the scheme proposed [31] is higher than that of the scheme proposed in [32]. However, the vehicles of this scheme do not need to send security messages to the surrounding vehicles, and the interaction frequency of information is lower than that of the scheme proposed in [32]. Therefore, the packet loss rate of the scheme proposed in [31] is lower than that of the scheme proposed in [32]. The communication data sizes of the scheme proposed in [29], the scheme proposed in [29], and our scheme are all 1056 bits. The authentication process of the scheme proposed in [30] is performed once for both vehicle and RSU encryption. Therefore, the overall response time is low, and the packet loss rate is small. The RSU side of our scheme needs to additionally calculate $A{K}_t=H_2(m_t·C_i)$ to obtain the authentication key, then perform decryption to obtain the vehicle’s authentication message using $A{K}_t$. Therefore, the overall delay and packet loss rate of our scheme is high compared to that of the scheme proposed in [30]. In the scheme proposed in [29], the vehicle not only needs to additionally compute the temporary pseudonym, but the RSU also needs to additionally compute the RSU beacon provided by the vehicle. Therefore, the delay and packet loss rate of the scheme proposed in [29] is higher than that of our scheme. To summarize, in the V2I authentication process, the scheme proposed in [29] has a higher delay and packet loss rate than the scheme proposed in [30] and our scheme.

8. Conclusions and Discussion

Currently, most of the V2I fast authentication protocols in VANETs suffer from RSU private key leakage and route privacy problems. To solve the above problems, we propose a privacy-preserving V2I fast authentication scheme in VANETs. The scheme achieves the protection of RSU private keys and route privacy through the use of an improved OT algorithm. The CA cannot obtain the vehicle’s travel path by analyzing the vehicle’s request information, and the vehicle’s route privacy is guaranteed. Meanwhile, even if the vehicle leaks the RSU authentication key, we can still guarantee the security of the RSU private key. In addition, security analysis proves that the scheme is able to guarantee the confidentiality of the RSU private key, the route privacy of the vehicle, the traceability of the vehicle, the unlinkability of the message, and resistance to common security attacks. Finally, the scheme outperforms other related schemes in terms of communication overhead and computational overhead.

Our current scheme treats the RSU as a fully trusted entity in the authentication process of V2I, and the RSU is able to retain information such as the current location and time of the vehicle when the vehicle and the RSU are authenticated. In addition, it has not been investigated how dynamic allocation of system resources can be achieved in the presence of large volumes of traffic. In future work, we will focus on how to perform secure authentication when the RSU is regarded as a not fully trusted entity. We will also investigate how artificial intelligence and machine learning can be utilized to dynamically adjust the allocation of system resources in the presence of varying vehicle traffic, in addition to designing more secure and efficient authentication protocols.