An ECC-Based Anonymous and Fast Handover Authentication Protocol for Internet of Vehicles

Abstract

As an important part of the Internet of Things, the Internet of Vehicles (IoV) has achieved efficient interconnection and collaboration between vehicles and road infrastructure, and between vehicles through advanced information and communication technologies. However, the high-speed movement of vehicles has generated a large number of cross-domain behaviors, which has greatly increased the number of authentications. Existing authentication protocols face challenges such as high cost, high computational overhead, and easy eavesdropping, interception, or tampering. To this end, this paper proposes an ECC-based IoV secure and efficient handover authentication protocol. The protocol adopts a “non-full key escrow” mechanism. The private key of the vehicle is jointly generated by the Trusted Authority (TA) and the vehicle. The TA only holds part of the private key. Even if the TA is malicious, the security of the vehicle’s private key can be ensured. At the same time, the proposed protocol uses the time tree technology in trusted computing to share part of the vehicle’s private data, which not only ensures the security of authentication, but also improves the efficiency of authentication, and solves the high-latency problem caused by the use of blockchain in previous protocols. When the vehicle moves across domains, there is no need to re-register and authenticate, which reduces the authentication overhead. Compared with existing protocols, this protocol is lightweight in both computational and communication overheads, effectively solving the problem of excessive cost.

1. Introduction

As the concept of smart cities is accelerating, the Internet of Things (IoT) technology has evolved from a single-scenario application to a core driving force for promoting urban digital transformation. It is widely used in smart healthcare, intelligent transportation systems (ITSs) and other fields [1]. As an important component of intelligent transportation systems (ITSs), the Internet of Vehicles (IoV) leverages advanced information and communication technologies to enable efficient interconnection and collaboration between vehicles and road infrastructure, and between vehicles themselves, bringing revolutionary changes to ITSs through its rapid development [2]. Due to the openness of the IoV communication architecture, the system faces security threats such as identity impersonation attacks and privacy data leakage [3]. For example, the information interaction between entities faces multi-dimensional security threats such as eavesdropping, interception and tampering by the enemy. Therefore, the identity authentication mechanism has become the core mechanism to ensure the security of the IoV system. It verifies the legitimate identity of the vehicle/infrastructure through cryptographic technology, prevents spoofing attacks by malicious edge nodes [4], and ensures secure and reliable real-time communication between entities in the system.

Figure 1 depicts the process of a vehicle communicating with infrastructure while driving in an IoV scenario. However, with the high-speed movement and frequent cross-domain behavior of vehicles, the number of authentication requests has increased dramatically. This not only places higher demands on the carrying capacity of the communication network, but also poses severe challenges to the performance and efficiency of the authentication protocol. How to achieve fast and secure cross-domain authentication in an IoV environment has become one of the key issues that need to be urgently addressed in the IoV field. In recent years, the academic community has made breakthrough progress in multiple dimensions in the field of vehicle network identity authentication protocols, but still faces many security and efficiency challenges. First, research on authentication protocols based on cryptographic technology, such as protocols based on public key infrastructure (PKI), can provide high security, but they rely on certificates to verify public keys. Errors in certificate authorities can undermine the entire PKI trust chain, which brings challenges to certificate management and increases the complexity and cost of large networks. In addition, in identity-based protocols, although some limitations of PKI-based authentication schemes that require the generation and storage of a large number of certificates have been solved, the user’s private key is usually generated by a trusted third party. When the third party is attacked or abused, it will bring privacy and security risks and face the challenge of public key revocation. There are also some certificateless protocols that use complex bilinear pairing or blockchain, which leads to communication delays, excessive resource consumption, and low system efficiency, and they are vulnerable to man-in-the-middle attacks or user key attacks. It can be seen that designing a vehicle authentication protocol that protects vehicle privacy and security while reducing the system’s computational overhead and communication overhead is still a work with extremely high research value.

To address these challenges, this paper proposes a secure and efficient handover authentication protocol. The main contents are as follows:

• A secure and efficient handover authentication protocol for the Internet of Vehicles is proposed, which can achieve mutual authentication and key negotiation between vehicles and Roadside Units (RSUs), and provide secure and reliable real-time communication. The proposed protocol is lightweight, with few message exchanges between entities, which effectively reduces communication and computational overhead and the risk of privacy leakage.
• The proposed protocol uses the time tree technology in trusted computing [5] to share some private data of vehicles, ensuring the security of vehicle authentication while improving the efficiency of authentication. When a vehicle moves across domains, it does not need to re-register and authenticate, reducing the cost of the vehicle in the authentication process.
• The proposed protocol implements “non-full key escrow”. The private key of the vehicle is generated by the TA and the vehicle separately. The TA only knows part of the vehicle’s private key. Even if the TA is malicious, the security of the vehicle’s private key can be guaranteed.
• Performance analysis shows that compared with existing protocols, the proposed protocol greatly reduces the communication overhead in the authentication process and the computational overhead when switching the authentication process.

The rest of the paper is structured as follows. Section 2 reviews existing authentication protocols. Section 3 introduces the preliminaries, including the system architecture, threat assumptions, and security requirements. Section 4 details the proposed protocol. Section 5 and Section 6 present the security and performance evaluations, respectively. Finally, Section 7 concludes the paper.

2. Related Works

In recent years, scholars have conducted in-depth research on identity authentication protocols to address the problems of rapid vehicle movement and frequent cross-domain communication in the Internet of Vehicles environment, and have proposed a variety of authentication schemes from different perspectives. Due to the limited computing and storage capabilities of devices in the Internet of Vehicles, the designed protocol cannot use overly complex algorithms. In order to address the problem of excessive authentication overhead in the Internet of Vehicles, scholars have proposed many feasible lightweight identity authentication schemes. Next, we will summarize the existing authentication protocol work for protecting the security of the Internet of Vehicles system to achieve vehicle V2I communication from the perspectives of Internet of Vehicles identity authentication schemes based on cryptography, challenge–response, and blockchain. Table 1 compares the advantages and limitations of existing protocols.

2.1. Cryptography-Based Identity Authentication Protocol

Zhang et al. [6] proposed a conditional privacy-preserving authentication scheme (PA-CRT) based on the Chinese Remainder Theorem (CRT) to secure communications in vehicular ad hoc networks (VANETs). By using CRT to assist TAs in the dynamic generation and distribution of group keys, the scheme enhances both the security and efficiency of the system. Subsequently, Xiong et al. [7] developed a CRT-based authentication protocol that supports dynamic group membership. The protocol addresses key issues such as message authentication, anonymity, and conditional privacy, while also ensuring forward and backward security, thereby responding effectively to the limitations of previous approaches. In 2021, Wang et al. [8] introduced a lightweight authentication protocol designed to improve the efficiency of emergency vehicle clearance in the IoV. After completing initial authentication with an RSU, an emergency vehicle can subsequently authenticate with other RSUs more quickly, thereby reducing computational overhead during transit. Subsequently, Wang and Liu [9] proposed a secure and efficient message authentication protocol (SEMA), which combines the advantages of pseudonym-based and group-based schemes to support efficient bidirectional authentication between vehicles and RSUs in VANETs. Despite their advantages, these protocols are still exposed to certain security risks, including desynchronization attacks, attacks by privileged insiders, and the compromise of RSUs. To ensure secure wireless communication between unmanned aerial vehicles (UAVs) and ground stations, He et al. [10] developed a lightweight key agreement protocol capable of maintaining security even in the event of temporary session information leakage, while keeping computational costs low. To address the performance overhead during protocol execution, Li et al. [11] proposed an authentication and key agreement scheme based on ECC. Their approach employs a dynamic credential synchronization framework, using dynamic authentication credentials in place of temporary public keys or static sender credentials to provide both efficiency and anonymity.

2.2. Challenge–Response-Based Authentication Protocol

Challenge–response protects data transmission between the client and server, thereby establishing a secure session key. Cao et al. [12] proposed a capability-based, privacy-preserving switching authentication mechanism for 5G heterogeneous networks (HetNets), building on Duan’s scheme [13] by incorporating user capability information with software-defined networking (SDN) technology. The scheme enables efficient authentication and key agreement between user equipment (UE) and base stations. However, it relies on fixed UE credentials and lacks a mechanism for credential updates, posing potential security risks. To strengthen resistance against physical capture attacks, Zhang et al. [14] designed a lightweight two-stage authentication and key agreement protocol for drones, integrating an embedded physical unclonable function (PUF) to ensure secure communication. Ren et al. [15] also introduced a PUF-based access authentication scheme involving a dual authentication process between drones and ground terminals. Their approach supports mutual authentication, key agreement, and privacy protection, while eliminating the need for key storage and offering robustness against physical attacks. To address the issue of drones being vulnerable to capture during operation, Choi et al. [16] proposed a secure and lightweight authentication and key agreement scheme based on hash functions and XOR operations. The scheme leverages the unique properties of PUFs to defend against various security threats, especially physical capture attacks. Aiming to overcome the limitations of many authentication schemes that do not adequately resist physical emulation and smart card loss attacks, Mo et al. [17] presented a two-factor authentication protocol. This protocol employs PUF technology to prevent physical emulation and sensor node capture, while also improving the efficiency and security of session key management. While the challenge–response handover authentication protocol offers strong robustness, its high computational and storage demands make it impractical for resource-limited IoV environments.

2.3. Blockchain-Based Identity Authentication Protocol

Blockchain offers unique advantages and is widely applied across various fields. It enables cross-domain authentication and key management without relying on a central Trusted Authority, simplifying the authentication process. As a result, numerous blockchain-based identity authentication protocols have been proposed to ensure secure and reliable access.

Table 1. Advantages and limitations of existing protocols.

Protocol	Advantages	Limitations
Zhang et al. [6]	Low computation and communication overheads.	Vulnerable to impersonation attacks.
Xiong et al. [7]	Guaranteeing forward and backward secrecy.	Vulnerable to desynchronization attacks and privileged insider attacks.
Wang et al. [8]	Low computation and communication overheads.	Vulnerable to desynchronization attacks and RSU capture attacks.
Wang and Liu [9]	Low computation and communication overheads.	Vulnerable to privileged insider attacks and RSU capture attacks.
He et al. [10]	Low computation and communication overheads.	Not handover authentication.
Li et al. [11]	Low computation and communication overheads.	Not handover authentication.
Cao et al. [12]	Low computation and communication overheads.	Presence of key escrow problem.
Zhang et al. [14]	Resist physical capture attacks.	Complexity and high deployment overhead.
Ren et al. [15]	Not requiring key storage.	Complexity and high computation overhead.
Choi et al. [16]	Resist physical capture attacks.	Not handover authentication.
Mo et al. [17]	Resist physical emulation attacks and sensor node capture attacks.	Complexity and high computation overhead.
Yazdinejad et al. [18]	Cross-domain authentication.	Complexity and high computation overhead.
Zhang et al. [19]	Hide users’ sensitive information on the blockchain.	Complexity and high deployment overhead.
Shen et al. [20]	Hide users’ sensitive information on the blockchain.	Not handover authentication.
Son et al. [21]	Low computation and communication overheads.	Vulnerable to RSU capture attacks.
Yu et al. [22]	Low computation and communication overheads.	Vulnerable to vehicle capture attacks.
Gu et al. [23]	Low deployment overheads.	Complexity and high deployment overhead.
Kanjanapruthipong et al. [24]	Resist SPoF attacks.	Complexity and high deployment overhead.
Wang et al. [25]	Resist vehicle impersonation attacks and tracking attacks.	Complexity and high deployment overhead.

Table 1. Advantages and limitations of existing protocols.

Protocol	Advantages	Limitations
Zhang et al. [6]	Low computation and communication overheads.	Vulnerable to impersonation attacks.
Xiong et al. [7]	Guaranteeing forward and backward secrecy.	Vulnerable to desynchronization attacks and privileged insider attacks.
Wang et al. [8]	Low computation and communication overheads.	Vulnerable to desynchronization attacks and RSU capture attacks.
Wang and Liu [9]	Low computation and communication overheads.	Vulnerable to privileged insider attacks and RSU capture attacks.
He et al. [10]	Low computation and communication overheads.	Not handover authentication.
Li et al. [11]	Low computation and communication overheads.	Not handover authentication.
Cao et al. [12]	Low computation and communication overheads.	Presence of key escrow problem.
Zhang et al. [14]	Resist physical capture attacks.	Complexity and high deployment overhead.
Ren et al. [15]	Not requiring key storage.	Complexity and high computation overhead.
Choi et al. [16]	Resist physical capture attacks.	Not handover authentication.
Mo et al. [17]	Resist physical emulation attacks and sensor node capture attacks.	Complexity and high computation overhead.
Yazdinejad et al. [18]	Cross-domain authentication.	Complexity and high computation overhead.
Zhang et al. [19]	Hide users’ sensitive information on the blockchain.	Complexity and high deployment overhead.
Shen et al. [20]	Hide users’ sensitive information on the blockchain.	Not handover authentication.
Son et al. [21]	Low computation and communication overheads.	Vulnerable to RSU capture attacks.
Yu et al. [22]	Low computation and communication overheads.	Vulnerable to vehicle capture attacks.
Gu et al. [23]	Low deployment overheads.	Complexity and high deployment overhead.
Kanjanapruthipong et al. [24]	Resist SPoF attacks.	Complexity and high deployment overhead.
Wang et al. [25]	Resist vehicle impersonation attacks and tracking attacks.	Complexity and high deployment overhead.

Yazdinejad et al. [18] proposed an authentication scheme combining blockchain and SDN to tackle repeated authentication issues during frequent handovers in 5G heterogeneous cells, enabling fast and privacy-aware switching within 1 millisecond. However, this scheme causes high communication overhead between the SDN controller and blockchain center and focuses only on data privacy, overlooking identity and location privacy. To address identity privacy concerns from [17], Zhang et al. [19] developed RUSH, a robust universal seamless handover authentication protocol for 5G heterogeneous networks. RUSH offers features like perfect forward secrecy and strong traceability to enhance handover security and reliability. It protects user anonymity by storing a chameleon hash of the user’s identity on the blockchain instead of the actual identity. Shen et al. [20] introduced BASA, a blockchain-assisted authentication mechanism for cross-domain industrial IoT, which uses identity-based signatures and anonymous identity management to protect device privacy. The parties also negotiate session keys to secure future communications. Son et al. [21] proposed a lightweight blockchain-based handover authentication protocol for VANETs to improve network efficiency during handovers. However, vehicles and RSUs in this scheme still undergo time-consuming authentication processes and it does not effectively protect against RSU capture attacks. In a similar vein, Yu et al. [22] developed a handover authentication protocol using blockchain smart contracts that streamlines mutual authentication and key negotiation between 5G vehicles and base stations, lowering authentication costs. Despite these improvements, the protocol lacks guarantees of mutual authentication and untraceability, making it vulnerable to physical vehicle capture attacks. To solve the problem of industrial IoT devices being vulnerable to attacks, Gu et al. [23] proposed an improved protocol based on the string space attack model theory to meet the identity authentication requirements and gave corresponding attack examples. Kanjanapruthipong et al. [24] proposed a decentralized distributed identity authentication processing mechanism based on the blockchain verification paradigm. This scheme can resist various potential attacks and has great potential in identity management. Wang et al. [25] proposed a mechanism that combines Schnorr signature-based authentication and dynamic refresh of temporary identities, which can effectively prevent vehicle impersonation attacks, tracking attacks, etc.

3. Preliminaries

In this section, we present the ECC scheme, system architecture, corresponding threat models and security requirements. To enhance comprehensibility,

Table 2. Notations.

Notation	Description
$I{D}_{V_i}$	The identity of $V_i$
$I{D}_{RS{U}_j}$	The identity of $RS{U}_j$
$PI{D}_i$	Temporary pseudonym of $V_i$
$s,P_{pub}$	Master secret key and public key of $TA$
$d_{V_i},P_{V_i}$	Secret key and public key of $V_j$
$d_{RS{U}_j},P_{RS{U}_j}$	Secret key and public key of $RS{U}_j$
$\mathbb{G}$	A cyclic additive group of an order q
P	A generator of $\mathbb{G}$
$p,q$	Prime numbers of $Z_p^{\ast }$
$T_i$	Timestamp $i\in [1,4]$
$h(·)$	A one-way hash algorithm: ${\{0,1\}}^{\ast }\to {\{0,1\}}^l$
l	The output length of $h(·)$
$\left|\right|$	Concatenation operation
$I{D}_{V_i}$	Bitwise XOR operation

provides a comprehensive overview of symbols employed in our framework.

3.1. Elliptic Curve Cryptosystem

The Elliptic Curve Cryptosystem (ECC) is a public key cryptosystem. Let p and q be two large prime numbers. An elliptic curve $E_p(a,b)$ is defined over the finite field $F_p$ by the equation $y^2=x^3+ax+b$, where $4a^3+27b^2\ne 0,(a,b)\in F_p$. Let $\mathbb{G}$ denote an additive cyclic group of order q, and P be a generator of $\mathbb{G}$.

Elliptic curve discrete logarithm problem (ECDLP): Given two points, $P\in \mathbb{G}$ and $k·P\in \mathbb{G}$, the advantages of calculating $k\in Z_p^{\ast }$ in probabilistic polynominal time are negligible.

Elliptic curve computing Diffle–Hellman problem (ECCDHP): For a given $P_1=a·G$, $P_2=b·G$, it is extremely difficult to calculate $k=ab·G$.

Elliptic curve determination Diffie–Hellman problem (ECDDH): For a given four points $P,A=a·P,B=b·P,C=c·P(a,b,c\in Z_q^{\ast })$ on $\mathbb{G}$, it is difficult to determine $C=ab·P$.

The latter two problems are considered mathematically insurmountable.

3.2. System Architecture

As shown in Figure 2, our system model contains the following three types, and our protocol assumes that the adversaries cannot extract any information from the trusted computation tree and the timer will not expire.

• TA: Adversaries possess the capability to eavesdrop on, modify, intercept, and replay all messages transmitted over a public communication channel. However, secure transmission mechanisms are designed to prevent adversaries from intercepting such information.
• RSU: Attackers may exploit intercepted sensitive parameters like vehicle control data, cryptographic keys and public information to initiate spoofing attacks or inject malicious messages.
• V: The attacker may exploit session keys or the session state within a specific session to compromise confidential credentials. However, if the current session key has been compromised in a particular session, the attacker remains incapable of deducing both past and future session keys.

3.3. Threat Model

In vehicular network systems, the wireless channel serves as a public medium, rendering Vehicle-to-Infrastructure (V2I) communications susceptible to numerous security threats, including eavesdropping and privacy infringement. Attackers may attempt to eavesdrop on, intercept, analyze, or modify messages transmitted over the channel. The threat model is a formalization of an adversary, under which the adversary’s capabilities and intentions can be programmatically characterized. The attacker’s objective is to gain unauthorized access to the system and subsequently attempt to derive profit from it. By integrating the widely adopted Canetti–Krawczyk adversary model [26] and the Dolev–Yao adversary model [27], we define the attacker’s capabilities as follows:

• Adversaries possess the capability to eavesdrop on, modify, intercept, and replay all messages transmitted over a public communication channel. However, secure transmission mechanisms are designed to prevent adversaries from intercepting such information.
• Attackers may exploit intercepted sensitive parameters like vehicle control data, cryptographic keys and public information to initiate spoofing attacks or inject malicious messages.
• The attacker may exploit session keys or the session state within a specific session to compromise confidential credentials. However, if the current session key has been compromised in a particular session, the attacker remains incapable of deducing both past and future session keys.
• Adversaries cannot extract any information from the trusted computation tree.

3.4. Security Requirements

• Mutual Authentication: During the mutual authentication process, both parties mutually authenticate each other’s legitimacy and verify their authorization to conduct secure encrypted communications.
• Anonymity: During handover authentication procedures, ensuring the confidentiality of vehicle privacy information assumes paramount importance. Vehicle privacy data must not be transmitted in plaintext format, with access restricted exclusively to authorized entities possessing legitimate entitlements to such sensitive information.
• Unlinkability: During the handover authentication process, even if an attacker intercepts certain messages, it remains fundamentally infeasible to ascertain whether these messages originate from the same user terminal.
• Perfect Forward Secrecy: To protect the confidentiality of messages exchanged during prior sessions, the protocol must ensure the provision of perfect forward secrecy. This guarantees that even if an adversary obtains the long-term private keys of the participants, the session keys established in previous communications remain secure against compromise.
• Defend Against Various Common Attacks: To enhance the security of the authentication process, the proposed protocol should be capable of resisting common attacks such as vehicle impersonation attacks, RSU impersonation attacks, replay attacks, man-in-the-middle (MITM) attacks and other known attacks.
• Penalty and Exposure: Malicious vehicles compromising system security must be subject to sanctions by the Trusted Authority (TA) through cryptographic revocation mechanisms.

4. Proposed Protocol

4.1. Initialization Phase

In this phase, the $TA$ selects a generator P of an additive cyclic group G of order q, along with a cryptographic hash function $h(·)$. The system then computes and generates the master secret key $s\in Z_p^{\ast }$ and $P_{Pub}=s·P$, and subsequently publishes the system parameters $Param=\{p,q,P,P_{Pub},h(·)\}$.

4.2. Registration Phase

4.2.1. Vehicle Registration

The vehicle registration process is shown in Table 3. In this phase, the $TA$ delivers registration services to the vehicle $V_i$ through a secure communication channel, ultimately enabling $V_i$ to acquire the private key $d_{V_i}$ and public key $P_{V_i}$.

• $V_i$ selects a secret parameter $y_v\in {\mathbb{Z}}_p^{\ast }$ as a component of its private key, computes $Y_v=y_v·P$, and transmits a registration request message $\{I{D}_{V_i},Y_v\}$ through the secure communication channel to the $TA$.
• Upon receiving the registration request from $V_i$, the $TA$ randomly selects $u\in {\mathbb{Z}}_p^{\ast }$, computes $X_v=u·P$, generates a component $x_v=u+s·h(I{D}_{V_i}\left|\right|X_v\left|\right|Y_v)$ of its partial private key, and transmits the response message $\{x_v,X_v\}$ through the secure communication channel.
• Upon receiving the response message from the $TA$, $V_i$ first sets $C=h\left(I{D}_{V_i}\right|\left|X_v\right|\left|Y_v\right)$, and verifies whether equation $x_v·P=X_v+P_{Pub}·C$ holds true. If the verification succeeds, $V_i$ proceeds to compute and generate the $d_{V_i}=x_v+y_v$ and $P_{V_i}=\{X_v,Y_v\}$. Finally, $V_i$ stores $\{d_{V_i},P_{V_i},C\}$ in its memory and publishes $P_{V_i}=\{X_v,Y_v\}$. If the verification fails, $V_i$ retransmits the registration request $\{I{D}_{V_i},Y_v\}$ through the secure communication channel.

Table 3. Vehicle registration stage.

${\mathit{V}}_{\mathit{i}}$	$\mathit{TA}$
Randomly choose $y_v$
Compute $Y_v=y_v·P$
send $\{I{D}_{V_i},Y_v\}$
	Randomly choose u
	Compute $X_v=u·P$
	$x_v=u+s·h(I{D}_{V_i}\left|\right|X_v\left|\right|Y_v)$
	send $\{x_v,X_v\}$
Compute $C=h\left(I{D}_{V_i}\right|\left|X_v\right|\left|Y_v\right)$
Verify $x_v·P\stackrel{?}{=}{X}_v+P_{Pub}·C$
Compute $d_{V_i}=x_v+y_v,P_{V_i}=\{X_v,Y_v\}$
store $\{d_{V_i},P_{V_i},C\}$

Table 3. Vehicle registration stage.

${\mathit{V}}_{\mathit{i}}$	$\mathit{TA}$
Randomly choose $y_v$
Compute $Y_v=y_v·P$
send $\{I{D}_{V_i},Y_v\}$
	Randomly choose u
	Compute $X_v=u·P$
	$x_v=u+s·h(I{D}_{V_i}\left|\right|X_v\left|\right|Y_v)$
	send $\{x_v,X_v\}$
Compute $C=h\left(I{D}_{V_i}\right|\left|X_v\right|\left|Y_v\right)$
Verify $x_v·P\stackrel{?}{=}{X}_v+P_{Pub}·C$
Compute $d_{V_i}=x_v+y_v,P_{V_i}=\{X_v,Y_v\}$
store $\{d_{V_i},P_{V_i},C\}$

4.2.2. $RSU$ Registration

The registration process of RSU is shown in Table 4. In a similar manner, during this phase, the $TA$ provides the registration services to $RS{U}_j$ through the security channel, ultimately enabling $RS{U}_j$ to generate its private key $d_{RS{U}_j}$ and public key $P_{RS{U}_j}$.

• $RS{U}_j$ randomly selects a secret parameter $y_r\in {\mathbb{Z}}_p^{\ast }$, computes $Y_r=y_r·P$, and transmits the registration message $\{I{D}_{RS{U}_j},Y_r\}$ to the $TA$ through the security channel.
• Upon receiving the registration information from $RS{U}_j$, the $TA$ selects a random number $v\in {\mathbb{Z}}_p^{\ast }$, computes $X_r=v·P$, generates a partial private key $x_r=v+s·h(I{D}_{RS{U}_i}\left|\right|X_r\left|\right|Y_r)$ for $RS{U}_j$, and sends the response message $\{x_r,X_r\}$.
• Upon receiving the information, $RS{U}_j$ first verifies whether $x_r·P=X_r+P_{Pub}·h(I{D}_{RS{U}_j}\left|\right|X_r\left|\right|Y_r)$ holds true. If satisfied, $RS{U}_j$ generates the private key $d_{RS{U}_j}=x_r+y_r$ and public key $P_{RS{U}_j}=\{X_r,Y_r\}$. Subsequently, $RS{U}_j$ stores $\{{\mathrm{d}}_{{\mathrm{RSU}}_{\mathrm{j}}},{\mathrm{P}}_{{\mathrm{RSU}}_{\mathrm{j}}}\}$ in memory and publishes its public key ${\mathrm{P}}_{{\mathrm{RSU}}_{\mathrm{j}}}=\{{\mathrm{X}}_{\mathrm{r}},{\mathrm{Y}}_{\mathrm{r}}\}$.

Table 4. RSU registration stage.

${\mathit{RSU}}_{\mathit{j}}$	$\mathit{TA}$
Randomly choose $y_r$
Compute $Y_r=y_r·P$
send $\{I{D}_{RS{U}_j},Y_r\}$
	Randomly choose v
	Compute $X_r=v·P$
	$x_r=v+s·h(I{D}_{RS{U}_j}\left|\right|X_r\left|\right|Y_r)$
	send $\{x_r,X_r\}$
Verify $x_r·P\stackrel{?}{=}{X}_r+P_{Pub}·h(I{D}_{RS{U}_j}\left|\right|X_r\left|\right|Y_r)$
Compute $d_{RS{U}_j}=x_r+y_r,P_{RS{U}_j}=\{X_r,Y_r\}$
store $\{d_{RS{U}_j},P_{RS{U}_j}\}$

Table 4. RSU registration stage.

${\mathit{RSU}}_{\mathit{j}}$	$\mathit{TA}$
Randomly choose $y_r$
Compute $Y_r=y_r·P$
send $\{I{D}_{RS{U}_j},Y_r\}$
	Randomly choose v
	Compute $X_r=v·P$
	$x_r=v+s·h(I{D}_{RS{U}_j}\left|\right|X_r\left|\right|Y_r)$
	send $\{x_r,X_r\}$
Verify $x_r·P\stackrel{?}{=}{X}_r+P_{Pub}·h(I{D}_{RS{U}_j}\left|\right|X_r\left|\right|Y_r)$
Compute $d_{RS{U}_j}=x_r+y_r,P_{RS{U}_j}=\{X_r,Y_r\}$
store $\{d_{RS{U}_j},P_{RS{U}_j}\}$

4.3. The Initial Authentication Between Vehicles and $RSUs$ and the Generation of Cryptographic Keys

The initial authentication between the vehicles and the RSUs and the generation process of the cryptographic keys are shown in Table 5. During this phase, $V_i$ and $RS{U}_j$ perform initial authentication to establish a session key $S{K}_{ij}$, laying the foundation for subsequent re-authentication. After completing initial authentication, a vehicle-specific secret parameter $\{PI{D}_i,I{D}_{V_i},C,TTL\}$ is shared with a legitimate $RSU$ through time tree technology. When the vehicle enters the jurisdiction of another $RSU$, handover authentication is conducted between the vehicle and the new $RSU$, thereby reducing authentication overhead and enhancing efficiency.

• $V_i$ randomly selects a partial private key $r_1\in {\mathbb{Z}}_p^{\ast }$, computes $R_1=r_1·P$, and uses the local $RS{U}_j$’s $I{D}_{RS{U}_j}$ along with $P_{RS{U}_j}=\{X_r,Y_r\}$ to derive $D_r=X_r+Y_r+P_{Pub}·h\left(I{D}_{RS{U}_j}\left|\right|X_r\left|\right|Y_r\right)$, pseudonymous identifier $PI{D}_i=I{D}_{V_i}\oplus h(r_1·D_r)$ and verification parameter $V_v=r_1+d_{V_i}·h(R_1\left|\right|PI{D}_i\left|\right|T_1)$. Subsequently, $V_i$ obtains the current timestamp $T_1$ and transmits the message $\{PI{D}_i,R_1,V_v,T_1\}$ to the $RS{U}_j$.
• Upon receiving the message, the $RS{U}_j$ first verifies the freshness of $T_1$ through a condition check $|T_1-T_c|<\Delta T$. If this condition is violated (indicating $T_1$ staleness), the $RS{U}_j$ terminates the current session. Otherwise, the $RS{U}_j$ retrieves the $V_i$’s true identity $I{D}_{V_i}^{\ast }=PI{D}_i\oplus h(R_1·d_{RS{U}_j})$, sets $C=h\left(I{D}_{V_i}^{\ast }\right|\left|X_v\right|\left|Y_v\right)$, computes the $V_i$’s $D_v=X_v+Y_v+P_{Pub}·C$, and validates the message’s legitimacy and integrity via the verification equation $V_v·P=R_1+D_v·h(R_1\left|\right|PI{D}_i\left|\right|T_1)$. If the equation holds, the $RS{U}_j$ proceeds with the following steps: The $RS{U}_j$ generates a random number $r_2\in {\mathbb{Z}}_p^{\ast }$, computes $R_2=r_2·P$ and $R_{ij}=R_1·r_2$, establishes the session key $S{K}_{ij}=h(R_{ij}\left|\right|C)$, updates the pseudonymous identifier $PI{D}_i^{+}=h(d_{RS{U}_j}\left|\right|I{D}_{V_i}^{\ast }\left|\right|C\left|\right|T_4)$ to prevent tracking, and encrypts it as $H_1=PI{D}_i^{+}\oplus h(r_2·D_v)$. Subsequently, the $RS{U}_j$ generates $V_r=r_2+d_{RS{U}_j}·h(R_2\left|\right|H_1\left|\right|T_2)$ and transmits $\{I{D}_{RS{U}_j},R_2,H_1,V_r,T_2\}$ to the $V_i$. Finally, the $RSU$ stores $\{PI{D}_i,I{D}_{V_i},C,TTL\}$ in its memory. After updating, the default ${\mathrm{PID}}_{\mathrm{i}}={\mathrm{PID}}_{\mathrm{i}}^{+}$ is set. Here, $TTL$ is a configured threshold representing the maximum number of messages allowed to pass through the $RS{U}_j$ before being discarded. If $\mathrm{TTL}\le 0$, the $V_i$ must re-register.
• Upon receiving a message from the $RS{U}_j$, $V_i$ first verifies the $T_2$’s freshness, then validates the equation $V_r·P=R_2+D_r·h(R_2\left|\right|H_1\left|\right|T_2)$. If the equation holds, $V_i$ computes $R_{ij}=r_1·R_2$, recovers the pseudonymous identifier $PI{D}_i^{+}=H_1\oplus h(R_2·d_{V_i})$, and generates the session key $S{K}_{ij}=h(R_{ij}\left|\right|C)$; otherwise, the $V_i$ resends the authentication request. Finally, $V_i$ replaces parameter $PI{D}_i$ with $PI{D}_i^{+}$ and stores the updated value in its memory.

Table 5. The initial authentication between vehicles and $RSUs$ and the generation of cryptographic keys.

${\mathit{V}}_{\mathit{i}}$	${\mathit{RSU}}_{\mathit{j}}$
Randomly choose $r_1$
Compute $R_1=r_1·P$
$D_r=X_r+Y_r+P_{Pub}·h\left(I{D}_{RS{U}_j}\left|\right|X_r\left|\right|Y_r\right)$
$PI{D}_i=I{D}_{V_i}\oplus h(r_1·D_r)$
$V_v=r_1+d_{V_i}·h(R_1\left|\right|PI{D}_i\left|\right|T_1)$
send $\{PI{D}_i,R_1,V_v,T_1\}$
(via open channel)
	Check $|T_1-T_c|<\Delta T$
	Compute $I{D}_{V_i}^{\ast }=PI{D}_i\oplus h(R_1·d_{RS{U}_j})$
	$C=h\left(I{D}_{V_i}^{\ast }\right|\left|X_v\right|\left|Y_v\right)$
	$D_v=X_v+Y_v+P_{Pub}·C$
	Verify $V_v·P\stackrel{?}{=}{R}_1+D_v·h(R_1\left|\right|PI{D}_i\left|\right|T_1)$
	Randomly choose $r_2$
	Compute $R_2=r_2·P,R_{ij}=R_1·r_2$
	$S{K}_{ij}=h(R_{ij}\left|\right|C)$
	$PI{D}_i^{+}=h(d_{RS{U}_j}\left|\right|I{D}_{V_i}^{\ast }\left|\right|C\left|\right|T_4)$
	$H_1=PI{D}_i^{+}\oplus h(r_2·D_v)$
	$V_r=r_2+d_{RS{U}_j}·h(R_2\left|\right|H_1\left|\right|T_2)$
	send $\{I{D}_{RS{U}_j},R_2,H_1,V_r,T_2\}$
	save $\{PI{D}_i,I{D}_{V_i},C,TTL\}$
	(via open channel)
Check $|T_2-T_c|<\Delta T$
Verify $V_r·P\stackrel{?}{=}{R}_2+D_r·h(R_2\left|\right|H_1\left|\right|T_2)$
Compute $R_{ij}=r_1·R_2$
$PI{D}_i^{+}=H_1\oplus h(R_2·d_{V_i})$
$S{K}_{ij}=h(R_{ij}\left|\right|C)$
save $\left\{PI{D}_i^{+}\right\}$

Table 5. The initial authentication between vehicles and $RSUs$ and the generation of cryptographic keys.

${\mathit{V}}_{\mathit{i}}$	${\mathit{RSU}}_{\mathit{j}}$
Randomly choose $r_1$
Compute $R_1=r_1·P$
$D_r=X_r+Y_r+P_{Pub}·h\left(I{D}_{RS{U}_j}\left|\right|X_r\left|\right|Y_r\right)$
$PI{D}_i=I{D}_{V_i}\oplus h(r_1·D_r)$
$V_v=r_1+d_{V_i}·h(R_1\left|\right|PI{D}_i\left|\right|T_1)$
send $\{PI{D}_i,R_1,V_v,T_1\}$
(via open channel)
	Check $|T_1-T_c|<\Delta T$
	Compute $I{D}_{V_i}^{\ast }=PI{D}_i\oplus h(R_1·d_{RS{U}_j})$
	$C=h\left(I{D}_{V_i}^{\ast }\right|\left|X_v\right|\left|Y_v\right)$
	$D_v=X_v+Y_v+P_{Pub}·C$
	Verify $V_v·P\stackrel{?}{=}{R}_1+D_v·h(R_1\left|\right|PI{D}_i\left|\right|T_1)$
	Randomly choose $r_2$
	Compute $R_2=r_2·P,R_{ij}=R_1·r_2$
	$S{K}_{ij}=h(R_{ij}\left|\right|C)$
	$PI{D}_i^{+}=h(d_{RS{U}_j}\left|\right|I{D}_{V_i}^{\ast }\left|\right|C\left|\right|T_4)$
	$H_1=PI{D}_i^{+}\oplus h(r_2·D_v)$
	$V_r=r_2+d_{RS{U}_j}·h(R_2\left|\right|H_1\left|\right|T_2)$
	send $\{I{D}_{RS{U}_j},R_2,H_1,V_r,T_2\}$
	save $\{PI{D}_i,I{D}_{V_i},C,TTL\}$
	(via open channel)
Check $|T_2-T_c|<\Delta T$
Verify $V_r·P\stackrel{?}{=}{R}_2+D_r·h(R_2\left|\right|H_1\left|\right|T_2)$
Compute $R_{ij}=r_1·R_2$
$PI{D}_i^{+}=H_1\oplus h(R_2·d_{V_i})$
$S{K}_{ij}=h(R_{ij}\left|\right|C)$
save $\left\{PI{D}_i^{+}\right\}$

4.4. The Handover Authentication Between Vehicles and $RSUs$ and the Generation of Cryptographic Keys

The handover authentication and key generation process between the vehicles and the RSUs is shown in Table 6. In this phase, $V_i$ and $RS{U}_j$ undergo initial authentication while $S{K}_{ij}$ is generated through handover authentication, with the entire process conducted over open communication channels.

• In this step, $V_i$ randomly selects $r_i\in {\mathbb{Z}}_p^{\ast }$ as a component of its private key, computes $R_i=r_i·P$ and $V_i=PI{D}_i\oplus h(T_3\left|\right|R_i\left|\right|C)$, and transmits the message $\{PI{D}_i,V_i,R_i,T_3\}$ to $RS{U}_j$.
• Upon receiving the message, the $RS{U}_j$ first assesses $T_3$’s freshness by checking $|T_3-T_c|<\Delta T$. If this condition is violated, indicating $T_3$ is stale, the $RS{U}_j$ terminates the current session. Otherwise, it reconstructs $\{C,I{D}_i\}$ based on $PI{D}_i$ from shared information and verifies vehicle validity by checking whether $TTL>0$. Then the $RS{U}_j$ authenticates the message origin through the equation $V_i=PI{D}_i\oplus h(T_3\left|\right|R_i\left|\right|C)$ to ensure it originates from a legitimately authenticated vehicle. Upon successful validation, the $RS{U}_j$ proceeds as follows: generates random numbers $r_j\in {\mathbb{Z}}_p^{\ast }$, computes $R=r_j·R_i$ and $R_j=r_j·P$, updates the pseudonymous $PI{D}_i^{+}=h(d_{RS{U}_j}\left|\right|I{D}_{V_i}\left|\right|C\left|\right|T_4)$ with obfuscation to $H_2=PI{D}_i^{+}\oplus h\left(C\right||T_4)$, generates $V_j=h(H_2\left|\right|I{D}_{V_i}\left|\right|C\left|\right|R_j)$ and session key $S{K}_{ij}=h\left(R\right|\left|C\right)$, and finally updates the information $\{PI{D}_i^{+},TTL-1\}$ in trusted computing tree and transmits $\{I{D}_{RS{U}_j},V_j,H_2,R_j,T_4\}$ to $V_i$.
• Upon receiving the message from $RS{U}_j$, $V_i$ performs a $T_4$ freshness check firstly and verifies the equation $V_j=h(H_2\left|\right|I{D}_{V_i}\left|\right|C\left|\right|R_j)$. If the equation holds true, $V_i$ proceeds to compute $R=r_i·R_j$, generate the session key $S{K}_{ij}=h\left(R\right|\left|C\right)$, and subsequently update its pseudonymous $PI{D}_i^{+}=H_2\oplus h\left(C\right||T_4)$.

Table 6. The handover authentication between vehicles and $RSUs$ and the generation of cryptographic keys.

${\mathit{V}}_{\mathit{i}}$	${\mathit{RSU}}_{\mathit{j}}$
Randomly choose $r_i$
Compute $R_i=r_i·P$
$V_i=PI{D}_i\oplus h(T_3\left|\right|R_i\left|\right|C)$
send $\{PI{D}_i,V_i,R_i,T_3\}$
	Check $|T_3-T_c|<\Delta T$
	Retrieve $\{C,I{D}_i\}$
	Verify $TTL\stackrel{?}{>}0$
	Check $V_i\stackrel{?}{=}PI{D}_i\oplus h(T_3\left|\right|R_i\left|\right|C)$
	Randomly choose $r_j$
	Compute $R=r_j·R_i,R_j=r_j·P$
	$PI{D}_i^{+}=h(d_{RS{U}_j}\left|\right|I{D}_{V_i}\left|\right|C\left|\right|T_4)$
	$H_2=PI{D}_i^{+}\oplus h\left(C\right||T_4)$
	$V_j=h(H_2\left|\right|I{D}_{V_i}\left|\right|C\left|\right|R_j)$
	Generate $S{K}_{ij}=h\left(R\right|\left|C\right)$
	Update $\{PI{D}_i^{+},TTL-1\}$
	send $\{I{D}_{RS{U}_j},V_2,H_2,R_j,T_4\}$
Check $|T_4-T_c|<\Delta T$
Verify $V_j\stackrel{?}{=}h(H_2\left|\right|I{D}_{V_i}\left|\right|C\left|\right|R_j)$
Compute $R=r_i·R_j$
Generate $S{K}_{ij}=h\left(R\right|\left|C\right)$
Update $PI{D}_i^{+}=H_2\oplus h\left(C\right||T_4)$

Table 6. The handover authentication between vehicles and $RSUs$ and the generation of cryptographic keys.

${\mathit{V}}_{\mathit{i}}$	${\mathit{RSU}}_{\mathit{j}}$
Randomly choose $r_i$
Compute $R_i=r_i·P$
$V_i=PI{D}_i\oplus h(T_3\left|\right|R_i\left|\right|C)$
send $\{PI{D}_i,V_i,R_i,T_3\}$
	Check $|T_3-T_c|<\Delta T$
	Retrieve $\{C,I{D}_i\}$
	Verify $TTL\stackrel{?}{>}0$
	Check $V_i\stackrel{?}{=}PI{D}_i\oplus h(T_3\left|\right|R_i\left|\right|C)$
	Randomly choose $r_j$
	Compute $R=r_j·R_i,R_j=r_j·P$
	$PI{D}_i^{+}=h(d_{RS{U}_j}\left|\right|I{D}_{V_i}\left|\right|C\left|\right|T_4)$
	$H_2=PI{D}_i^{+}\oplus h\left(C\right||T_4)$
	$V_j=h(H_2\left|\right|I{D}_{V_i}\left|\right|C\left|\right|R_j)$
	Generate $S{K}_{ij}=h\left(R\right|\left|C\right)$
	Update $\{PI{D}_i^{+},TTL-1\}$
	send $\{I{D}_{RS{U}_j},V_2,H_2,R_j,T_4\}$
Check $|T_4-T_c|<\Delta T$
Verify $V_j\stackrel{?}{=}h(H_2\left|\right|I{D}_{V_i}\left|\right|C\left|\right|R_j)$
Compute $R=r_i·R_j$
Generate $S{K}_{ij}=h\left(R\right|\left|C\right)$
Update $PI{D}_i^{+}=H_2\oplus h\left(C\right||T_4)$

4.5. The Revocation of Malicious Vehicles in Vehicular Networks

The malicious vehicle’s true identity $I{D}_{V_i}$ is identified through $PI{D}_i$, followed by removal of its credentials from the trusted computing environment and registration in $L_b$. Subsequently, all $RSUs$ shall deny services to vehicles marked as malicious in $L_b$.

5. Security Analysis

In this section, we show that our protocol satisfies the security requirements mentioned in Section 3.

• Untraceability: In the process of authentication, the protocol proposed in this paper changes the parameters of each authentication randomly and contains dynamic timestamps. The adversary cannot effectively link related vehicles based on some random numbers. Therefore, this protocol is untraceable.
• Anonymity of vehicle identity: When a vehicle attempts to communicate with an RSU or other vehicles, it will use a temporary pseudonym $PI{D}_i=I{D}_{V_i}\oplus h(r_1·D_r)$ instead of its real identity to transmit on a public channel. Without the master private key of the TA or RSU, the attacker cannot obtain the real identity of the vehicle. Only the TA or RSU can reveal the real information of the vehicle. The vehicle can update $PI{D}_i$ autonomously every time it communicates (rather than being generated by a trusted third party like other protocols).
• Perfect forward secrecy: Even if an adversary intercepts messages such as $R_1$ and $R_2$, deriving the session key (SK) remains infeasible. This is because SK is computed using a secret random value generated by the client. Recovering the SK from the intercepted data would require solving the elliptic curve discrete logarithm problem (ECDLP), which is widely regarded as computationally intractable. As a result, the protocol achieves perfect forward secrecy, ensuring that past session keys remain secure even if long-term private keys are compromised.
• Resistance to DDoS attacks: The system architecture employs multiple registration servers, which improves fault tolerance and enhances overall availability. Due to the protocol’s low transmission and processing overhead, the system remains responsive even when subjected to a high volume of incoming requests. This design allows it to effectively absorb and mitigate the impact of distributed denial-of-service (DDoS) attacks, ensuring continued service for legitimate users.
• Resistance to replay attacks: The protocol prevents adversaries from reusing previously intercepted messages to gain unauthorized access. Each message carries a timestamp T, allowing the server to verify its timeliness. Messages with outdated or invalid timestamps are recognized as replays and are subsequently rejected, thereby mitigating the risk of replay attacks.
• Resistance to man-in-the-middle attacks: As mentioned above, this protocol can prevent $V_i$’s identity $I{D}_i$, random number $r_i$, and secret parameter C from being recovered by malicious opponents. And this protocol is based on the mutual authentication feature and can resist man-in-the-middle attacks.
• Resistance to imitation attacks: Malicious attackers cannot obtain both the TA’s master private key and the partial private key generated by the vehicle at the same time, so the attacker cannot successfully imitate a legitimate vehicle to generate a signature, and therefore cannot successfully launch a vehicle simulation attack. Malicious attackers will try to launch RSU imitation attacks to obtain vehicle-related privacy information. However, the attacker cannot generate a legitimate sum, so they cannot successfully simulate a legitimate RSU.
• Resistance to single point failure attack: A malicious attacker can launch a single point failure attack on $RS{U}_j$. However, the registered vehicle information is directly written into the trusted computing tree instead of $RS{U}_j$’s memory, so the adversary cannot obtain the registered vehicle information. The exit of a certain $RS{U}_j$ will not change $d_{RS{U}_j}$ and $P_{RS{U}_j}$, so other $RSUs$ do not need to regenerate $(d_{RS{U}_j},P_{RS{U}_j})$. The multi-registration server structure will not cause the vehicle to fail to register due to a single $RS{U}_j$, because other servers can also register for $V_i$.

The protocol in this chapter takes security and functional characteristics into consideration.

Table 7. Security feature comparison.

Security Attributes	[28]	[29]	[30]	Our Protocol
$P_1$	✓	✓	✓	✓
$P_2$	✓	✓	✓	✓
$P_3$	✓	✓	✗	✓
$P_4$	✓	✓	✓	✓
$P_5$	✓	✓	✓	✓
$P_6$	✓	✗	✓	✓
$P_7$	✓	✓	✓	✓
$P_8$	✗	✗	✗	✓

$P_1$: “Untraceability”; $P_2$: “Anonymity of vehicle identity”; $P_3$: “Perfect forward secrecy”; $P_4$: “Resistance to DDoS attacks”; $P_5$: “Resistance to replay attacks”; $P_6$: “Resistance to man-in-the-middle attacks”; $P_7$: “Resistance to imitation attacks”; $P_8$: “Resistance to single point failure attack”.

gives the security and functional characteristics of the protocol and compares them with existing related protocols [28,29,30]. The proposed protocol can guarantee all security characteristics. Existing related protocols [28,29,30] do not consider or cannot guarantee all security characteristics. The proposed protocol can resist more attacks that may occur in the wireless channel and provide better security than existing protocols.

6. Performance Analysis

In this section, the proposed protocol will be compared with existing handover authentication schemes [28,29,30] in terms of computational cost and communication cost.

6.1. Computational Cost

All protocols were achieved on a four-core 3.2 GHz machine with 8 GB memory, and the results were averaged over 300 randomized simulation runs [31]. The execution time of each basic operation is shown in

Table 8. Execution time of basic operations.

Symbol	Operation	Execution Time (ms)
$T_h$	One-way hash function	0.32
$T_m$	Elliptic curve scalar multiplication	17.10
$T_{ex}$	Exponentiation operation	19.20
$T_{bp}$	Bilinear pairing operation	42.11
$T_{mm}$	Modular multiplication operation	0.88
$T_{mi}$	Modular inverse operation	2.64

[29].

The protocol of Wang et al. [28] requires four one-way hash operations, four bilinear pairing operations, six exponentiation operations, three modular multiplication operations and two modular inverse operations in the initial authentication phase. Therefore, the computational cost of this scheme in the initial authentication phase is about $4T_h+4T_{bp}+6T_{ex}+3T_{mm}+2T_{mi}\approx 292.84$ ms. In the handover authentication phase, it requires two one-way hash operations, two bilinear pairing operations, six exponentiation operations and five modular multiplication operations. Therefore, the computational cost of this scheme in the handover authentication phase is about $2T_h+2T_{bp}+6T_{ex}+5T_{mm}\approx 204.46$ ms.

The protocol of Dwivedi et al. [29] requires twelve one-way hash operations and six elliptic curve scalar multiplications in the initial authentication phase. Therefore, the computational cost of this scheme in the initial authentication phase is about $12T_h+6T_m\approx 106.44$ ms. In the handover authentication phase, it requires twenty-one one-way hash operations and twelve elliptic curve scalar multiplications. Therefore, the computational cost of this scheme in the handover authentication phase is about $21T_h+12T_m\approx 211.92$ ms.

The protocol of Maria et al. [30] requires four one-way hash operations, two elliptic curve scalar multiplications, two bilinear pairing operations and six exponentiation operations in the initial authentication phase. Therefore, the computational cost of this scheme in the initial authentication phase is about $4T_h+2T_m+2T_{bp}+6T_{ex}\approx 234.90$ ms. In the handover authentication phase, it requires three one-way hash operations, two elliptic curve scalar multiplications, two bilinear pairing operations and seven exponentiation operations. Therefore, the computational cost of this scheme in the handover authentication phase is about $3T_h+2T_m+2T_{bp}+7T_{ex}\approx 253.78$ ms.

In the protocol proposed in this paper, in the initial authentication stage, thirteen one-way hash operations and sixteen elliptic curve scalar multiplication operations are required, so the computational cost of the scheme in the initial authentication stage is about $13T_h+16T_m\approx 277.76$ ms; in the handover authentication stage, only nine one-way hash operations and four elliptic curve scalar multiplication operations are required, so the computational overhead of the scheme proposed in this paper in the handover authentication stage is approximately $9T_h+4T_m\approx 71.28$ ms.

Table 9. Comparison of computational costs of protocols.

Protocols	Initial Authentication Phase (ms)		Handover Authentication Phase (ms)
[28]	$4T_h+4T_{bp}+6T_{ex}+3T_{mm}+2T_{mi}$	292.84	$2T_h+2T_{bp}+6T_{ex}+5T_{mm}$	204.46
[29]	$12T_h+6T_m$	211.92	$21T_h+12T_m$	211.92
[30]	$4T_h+2T_m+2T_{bp}+6T_{ex}$	253.78	$3T_h+2T_m+2T_{bp}+7T_{ex}$	253.78
Ours	$13T_h+16T_m$	277.76	$9T_h+4T_m$	71.28

and Figure 3 shows that the proposed scheme has extremely superior performance in terms of computational overhead in the handover authentication phase. Compared with the protocols of Wang et al. [28], Dwivedid et al. [29], and Maria et al. [30], the proposed scheme has a lower computational overhead in the handover authentication phase.

6.2. Communication Cost

In this section, we analyze the communication overhead of our proposed scheme by combining the schemes of Wang et al. [28], Dwivedi et al. [29], and Maria et al. [30]. For the sake of comparison, this section assumes that $\left|G\right|,\left|ID\right|,\left|h\right|,\left|Ts\right|$ are the length of the elliptic curve point, the length of the vehicle or server identity, the output length of the hash function, and the length of the timestamp, respectively. In the implementation, it is assumed that the elliptic curve point is 320 bits, the output length of the hash function is 256 bits, the length of the vehicle or server identity (including the real identity and the disguised identity) is 160 bits, and the length of the timestamp is 32 bits.

In the protocol of Dwivedi et al. [29], in the initial authentication phase, two messages $\{M_0,M_2,M_3,M_4,Y,T_1\}$ and $\{Z_2,M_4,VER{I}_{S{K}_{i}j},T_2\}$ are transmitted between $ve{h}_j^k$ and $rs{u}_i^k$, requiring $\left|ID\right|+\left|G\right|+3\left|h\right|+\left|Ts\right|=1280$ bits and $\left|G\right|+2\left|h\right|+\left|Ts\right|=864$ bits, respectively, so the total communication cost of sending these two messages is 2144 bits; in the handover authentication phase, four messages $\{M_{00},M_{22},M_{33},M_{44},B,T_3\}$, $\{R_2,F,T_5\}$, $\{H,R_4,VER{I}_{S{K}_m^{rsu}},T_6\}$ and $\{Z_{22},M_{44},VER{I}_{S{K}_{mj}},T_4\}$ are exchanged among $ve{h}_j^k$,$rs{u}_m^n$ and $ve{h}_i^k$, requiring $\left|ID\right|+\left|G\right|+3\left|h\right|+\left|Ts\right|=1280$ bits, $\left|G\right|+\left|h\right|+\left|Ts\right|=608$ bits, $\left|G\right|+2\left|h\right|+\left|Ts\right|=864$ bits and $\left|G\right|+2\left|h\right|+\left|Ts\right|=864$ bits, respectively, so the total communication cost of sending these four messages is 3616 bits. In summary, the total communication cost of this scheme is 5760 bits.

In the protocol proposed by Maria et al. [30], the initial authentication phase requires 512 bits in total, comprising $\left|ID\right|+\left|G\right|+\left|Ts\right|$, while the handover authentication phase requires 1280 bits ($4\left|G\right|$). This results in an overall communication overhead of 1792 bits. However, the protocol does not support multi-domain authentication for vehicles, limiting its applicability in large-scale vehicular networks. Additionally, the messages $H{K}_1$ and $H{K}_2$ are transmitted over public channels without integrity verification at the receiving RSU, leaving the protocol unable to guarantee the confidentiality of public messages or the integrity of the handover process. Building on this, Wang et al. [28] later introduced a protocol that incurs 1056 bits of overhead during initial authentication and 3072 bits during handover authentication, amounting to a total of 4128 bits. Despite the increased communication cost, this scheme does not offer mutual authentication and fails to address the risk of privileged insider attacks.

In the protocol proposed in this paper, in the initial authentication phase, two messages $\{PI{D}_i,R_1,V_v,T_1\}$ and $\{I{D}_{RS{U}_j},R_2,H_1,V_r,T_2\}$ are transmitted, requiring $\left|ID\right|+2\left|G\right|+\left|Ts\right|=832$ bits and $2\left|ID\right|+2\left|G\right|+\left|Ts\right|=992$ bits, respectively, so the total communication cost of sending these two messages is 1824 bits; in the handover authentication phase, two messages $\{PI{D}_i,V_i,R_i,T_3\}$ and $\{I{D}_{RS{U}_j},V_j,H_2,R_j,T_4\}$ are exchanged, requiring $2\left|ID\right|+\left|G\right|+\left|Ts\right|=672$ bits and $2\left|ID\right|+\left|G\right|+\left|h\right|+\left|Ts\right|=928$ bits, so the total communication cost of sending these messages is 1600 bits. In summary, the total communication overhead of our scheme is 2528 bits. Figure 4 compares the communication overhead of each protocol.

7. Conclusions

We propose a lightweight handover authentication protocol based on ECC, which aims to solve the security and efficiency problems of cross-domain vehicle authentication in the Internet of Vehicles. The protocol uses cryptography and time tree technology to achieve fast two-way authentication and key negotiation between vehicles and infrastructure, ensuring the security and real-time nature of communication. The core innovation of the protocol lies in the “non-full key escrow” mechanism; that is, the private key of the vehicle is jointly generated by the TA and the vehicle, and the TA only holds part of the private key, thereby effectively preventing malicious TA from fully controlling the vehicle private key and significantly improving security. In addition, the protocol reduces the communication and computing overhead by reducing the number of message exchanges between entities, and uses the time tree technology to share some private data, further improving the authentication efficiency. Vehicles do not need to register and authenticate repeatedly when moving across domains, reducing resource consumption in the authentication process. Experimental results show that compared with existing protocols, this protocol has significant advantages in computing and communication overhead, providing a reliable solution for efficient and secure authentication in the Internet of Vehicles.

In future research, we will focus on the security and efficiency of fast switching authentication in vehicles in practice (including dynamic environmental factors, unforeseen attacks that may occur in actual deployment, etc.), and verify and improve our protocol.