An Improved Blockchain-Based Lightweight Vehicle-to-Infrastructure Handover Authentication Protocol for Vehicular Ad Hoc Networks

Abstract

We conduct a cryptanalysis of the Vehicle-to-Infrastructure (V2I) handover authentication protocol newly developed by Son et al., which incorporates blockchain technology for authentication purposes. Although this approach is notably efficient, our analysis reveals that the protocol is vulnerable to vehicle impersonation attacks, traceability attacks, and trusted authority (TA) circumvention attacks. To address these security vulnerabilities, we propose an enhanced protocol integrating Schnorr signature-based authentication, dynamically refreshed temporary identities, and TA-anchored credential mechanisms. We validate its security through heuristic analysis and formal verification using ProVerif. Furthermore, a comprehensive comparison with various related schemes confirms that the new protocol achieves a higher level of security while simultaneously maintaining satisfactory efficiency in both the computational and communication aspects.

1. Introduction

With the rapid progression of vehicle technologies, satellite communications [1], and Cyber–Physical Systems (CPSs), vehicles are increasingly becoming intelligent [2,3]. Among these advancements, Intelligent Transportation Systems (ITSs) have become a significant area of focus [4,5], garnering substantial interest from industry and academia alike. Vehicular Ad Hoc Networks (VANETs) are a critical component of future ITS development [6]. In VANETs, vehicles within ITS collect environmental data using On-Board Units (OBUs) and transmit this information to other vehicles and roadside infrastructure. Developments in edge computing, artificial intelligence, and advanced in-vehicle communication technologies further drive the growth of VANETs. The primary aim of VANETs is to establish an extensive, integrated network that allows intelligent vehicles to efficiently share data and resources. This integration enables a variety of vehicle applications, including safety, efficiency, and third-party entertainment services. Due to the high-speed dynamic properties of vehicles, the above information interaction process must ensure a stable and continuous connection between the vehicle and the Internet.

However, the inherently open nature of wireless communication channels in VANETs makes them susceptible to significant security threats, such as replay attacks, identity impersonation, and man-in-the-middle attacks [7]. In addition, as the vehicle travels, it will cross the communication range of several roadside infrastructures. Therefore, handover authentication mechanisms are also required to achieve stable and secure communication. This mechanism must ensure communication confidentiality and integrity while facilitating mutual authentication and key establishment, resisting typical protocol attacks, and maintaining high performance.

Blockchain technology has been introduced for VANET authentication due to its tamper-resistant and decentralized features [8,9]. The primary goal of employing blockchain for handover authentication is to enable Roadside Units (RSUs) to store historical access data for vehicle authentication. This storage allows RSUs to swiftly verify vehicle identities based on past access data, greatly streamlining the re-authentication process. This methodology offers numerous advantages, including reducing dependency on remote servers for vehicles that have been previously authenticated, lowering the number of authentication rounds, and decreasing computational and communication burdens. Moreover, it enhances the security of both RSUs and intelligent vehicles.

1.1. Related Work

Qu et al. [10] conducted a study utilizing Public Key Infrastructure (PKI) to manage security services in VANETs, focusing on entities with wireless access and communication mechanisms. Cui et al. [11] noted that PKI-based systems are advantageous for secure information exchange in VANETs, facilitating entity authentication and message integrity verification. Yang et al. [12] proposed a signature-based protocol for rapid handover authentication in VANETs, acknowledging the incompatibility of long authentication latencies with the high mobility of vehicles in VANET environments. This protocol reduces latency in identity verification by removing the need for multiple-party interactions. Ref. [13] discussed a novel authentication protocol for fog-enabled VANETs based on the multiple-trusted-authority model, which reduces the chance of service unavailability and single-point-of-failure.

Xu et al. [14] introduced an LTE-A anonymous handover authentication scheme for vehicular networks, acknowledging the necessity of concealing vehicle identities from message recipients due to mobility across different Roadside Units (RSUs). Anonymous handover ensures the confidentiality of vehicle identities, thwarting potential location tracking by attackers. Liu et al. [15] highlighted the inability of many handover authentication protocols to address serious threats such as unauthorized access and impersonation attacks. To counter these challenges, they suggested a decentralized and anonymous authentication scheme that supports seamless handover by incorporating blockchain technology.

Wang et al. [16] observed that vehicles entering new infrastructure coverage areas in VANETs face complex re-authentication processes. They recommended a scalable computation scheme aided by blockchain technology, facilitating vehicle handover authentication via secure ownership transfer mechanisms. Maria et al. [17] merged bilinear pairing technology with blockchain to expedite handover authentication between RSUs, significantly minimizing computational overhead. Su et al. [18] proposed a hybrid blockchain-based privacy-preserving authentication scheme, while a pre-authentication mechanism was used to accelerate the cross-domain authentication of vehicles.

1.2. This Work

In 2022, Son et al. [19] introduced a blockchain-based handover authentication protocol for VANETs, aiming to enhance system efficiency and security. Their protocol was validated for security using the well-established BAN Logic.

They claimed that the proposed protocol had resistance to various attacks and could ensure security properties such as perfect forward secrecy and anonymity. However, our analysis reveals vulnerabilities in their design. Despite the innovative design leveraging blockchain’s tamper-proof nature for computational and communication efficiency, our in-depth analysis of the protocol revealed several flaws, which make the protocol impractical for actual deployment. Therefore, we first demonstrate successful attacks against their protocol, then propose a security-enhanced handover authentication protocol to fix these issues. In the initial authentication stage, we implemented a strategy involving hiding fake identities. This method aims to protect the true identity of users from being disclosed. By updating the temporary identity, we ensure the anonymity of the identity throughout the entire switching authentication process. This design effectively prevents issues related to traceability and also prevents synchronization attacks. We adopted the well-known Schnorr signature mechanism, which can effectively resist various attacks, including vehicle impersonation attacks and TA bypass attacks. Finally, a thorough analysis of the security and operational performance of the improved protocol is presented.

The remainder of the paper is structured as follows. Section 2 introduces the system model and adversary model of the protocol. Section 3 reviews the protocol by Son et al. Our cryptanalysis of their protocol is detailed in Section 4. The enhanced protocol is presented in Section 5. Section 6 presents a security analysis of the improved protocol. Additionally, Section 8 presents a comprehensive analysis of the performance of the protocol. Finally, our conclusions are presented in Section 9.

2. Preliminaries

This section introduces elliptic curve cryptography and the Schnorr signature scheme, which we will use as building blocks for our new protocol. Here, we also outline the system models on which such authentication protocols are based and the adversary models used to explore their security.

2.1. Elliptic Curve Cryptography

ECC is a public-key cryptosystem based on the algebraic structure of elliptic curves over finite fields. Let $F_p$ denote a finite field of large prime order p. An elliptic curve E over $F_p$ is defined by the Weierstrass equation $y^2=x^3+ax+b\mathrm{mod}p$, where $x,y,a,b\in F_p$.

Definition 1

(Elliptic Curve Discrete Logarithm Problem). Given a base point $P\in E\left(F_p\right)$ and another point $Q=x·P$, it is computationally infeasible to determine the unique integer x.

Definition 2

(Elliptic Curve Computational Diffie–Hellman Problem). Given points $Q_1=a·P$ and $Q_2=b·P$, it is computationally infeasible to compute the point $Q=abP$ in probabilistic polynomial time without the knowledge of either a or b.

2.2. Schnorr Signature

The Schnorr signature [20] is a digital signature scheme based on the discrete logarithm problems proposed by Schnorr in 1991. It has the characteristics of simplicity, efficiency, and security, and is widely used in many security protocols. The core of this algorithm is to generate a pair of signatures using the user’s private key and public key, which can prove that the sender of the message has the corresponding private key without exposing the private key itself. The algorithm consists of three main steps: the setup phase, signature generation, and verification.

• Setup: Assume group $\mathbb{G}$ is a cyclic group of order n. The signer chooses a private signing key x from the set ${\mathbb{Z}}_n$. The public verification key is $y=g^x$.
• Signature generation: The signer selects a random number k, calculates the temporary public key $R=g^{k}modp$, and then computes the hash values, $e=Hash\left(R\right|\left|m\right)$ and $s=k-xe$, to generate the signature pair $(s,e)$, where g is a generator of the group $\mathbb{G}$, and k is an element of the set ${\mathbb{Z}}_n$.
• Signature verification: The verifier confirms the validity of the signature by calculating the hash value $e=Hash\left(R\right|\left|m\right)$ and verifying whether $g^s{g}^{y}modp$ is equal to R.

2.3. System Model

Figure 1 illustrates the blockchain-based handover authentication architecture within VANETs. This architecture includes four key components: the TA, RSUs, vehicles, and, finally, blockchain. Each component has a specific, well-defined role:

1.

TA: The TA disseminates vital public system parameters. During the registration phase, it selects identities and private keys for the RSUs and issues smart cards to vehicles.

2.

RSUs: RSUs are crucial for vehicle authentication before establishing communication links. They have the computational capacity for authenticating in-zone vehicles and act as ledger guardians and transaction nodes on the blockchain. In handover scenarios, RSUs verify vehicle authenticity using blockchain data.

3.

Vehicles: Vehicles, equipped with computationally limited OBUs, register with the TA and authenticate with RSUs to facilitate real-time traffic and entertainment data transmission.

4.

Blockchain: RSUs function as active nodes in the blockchain. After successful vehicle-to-RSU authentication, RSUs upload key elements—temporary identity, randomized data, and vehicle hash—to the blockchain, enabling quick vehicle identity authentication using the stored information.

2.4. Adversary Model

To evaluate the security of the protocol, it is crucial to define the capabilities of potential attackers. The widely recognized Dolev–Yao threat model [21] is widely used for assessing the security of authentication protocols. In this model, the adversary, denoted as $\mathcal{A}$, has the following capabilities:

• $\mathcal{A}$ has complete control over the public communication channel, which includes the ability to eavesdrop and to modify and delete messages exchanged between entities.
• $\mathcal{A}$ is capable of conducting side-channel attacks to extract stored values from physical devices [22,23,24].
• $\mathcal{A}$ has unrestricted access to the parameters of all entities, including their identities and public keys, as well as to unauthorized users.

3. Review of the Scheme of Son et al. [19]

This section reviews the protocol proposed by Son et al. [19], which involves three entities, i.e., vehicles, RSUs, and a TA, as key components. The protocol consists of five phases: system setup, vehicle registration, initial V2I authentication, blockchain-based handover authentication, and vehicle revocation. For clarity,

Table 1. Notation Guide.

Notations	Description
$V_i$	i-th vehicle
$I{D}_i$	Identity of $V_i$
$P{W}_i$	Password of $V_i$
$RS{U}_j$	j-th RSU
$RS{U}_k$	k-th RSU
$I{D}_j$	Identity of $RS{U}_j$
$I{D}_k$	Identity of $RS{U}_k$
$E_p(a,b)$	An elliptic curve
$S{C}_i$	Smart card
P	Generator of $\mathbb{G}$
$RI{D}_i$	Pseudo-identity of $V_i$
$TI{D}_i$	Temporary identity of $V_i$
$Y,y$	Public key and private key of TA
k	Shared key of TA and RSUs
$Si{g}_j(·)$	Signature of $RS{U}_j$
$S{K}_{ij}$	Session key of $V_i$ and $RS{U}_j$
$s_j$	Private key of $RS{U}_j$
$P_j$	Public key of $RS{U}_j$
$n_j,n_k$	Random nonces
$T_a$	Timestamp
$h(·)$	One-way hash function
⊕	Exclusive OR operation
∥	Concatenation operation

summarizes the notations used in the protocol.

3.1. System Setup

The system setup phase includes the following steps:

Step 1:

The TA initializes an elliptic curve $E_p(a,b)$, with P as its generator in $\mathbb{G}$. A secret master key $s_{TA}$, a one-way hash function $h(·)$, and a fuzzy verifier l ($2^4\le l\le 2^8$) are chosen by the TA. Secret and shared keys are deployed to each RSU.

Step 2:

The TA generates a distinct identifier $I{D}_j$ for $RS{U}_j$, computed as $s_j=h(I{D}_j\left|\right|s_{TA})$ and $k=h\left(I{D}_{TA}\right|\left|s_{TA}\right)$. The triplet $(I{D}_j,s_j,k)$ is then shared with $RS{U}_j$.

Step 3:

Upon receiving this information, $RS{U}_j$ calculates a public key $P_j=s_{j}P$ and securely stores the values $(k,s_j)$. This exchange occurs via a secure communication channel.

3.2. Vehicle Registration

Before authentication with an RSU, vehicle $V_i$ must register with the TA, which is carried out over a secure channel. The registration process involves the following steps:

Step 1:

$V_i$ generates a unique identity $I{D}_i$ and password $P{W}_i$, along with a random $x_i$. It calculates $HP{W}_i=(I{D}_i\left|\right|P{W}_i)$ and $RP{W}_i=HP{W}_i\oplus h\left(x_i\right)$, forwarding $(I{D}_i,RP{W}_i)$ to the TA.

Step 2:

The TA checks $I{D}_i$’s registration status and whether $RI{D}_i$ is revoked. If not, the TA randomly chooses $r_i$, computes $RI{D}_i=h(I{D}_i\left|\right|RP{W}_i\left|\right|r_i)$, and securely stores $(I{D}_i,RP{W}_i,r_i)$. The TA updates $S{C}_i$ with $(r_i,l)$, which is transmitted to $V_i$, while $h\left(RI{D}_i\right|\left|k\right)$ is uploaded to the blockchain.

Step 3:

After receiving $S{C}_i$, $V_i$ performs computations: $RI{D}_i$, $A_i=r_i\oplus HP{W}_i$, $B_i=x_i\oplus h\left(r_i\right)$, and $C_i=h\left(h\right(RI{D}_i\left|\right|x_i)$ mod l). These values update $S{C}_i$ as $(A_i,B_i,C_i)$ for future use.

3.3. Initial V2I Authentication

Following registration, $V_i$ begins authentication with $RS{U}_j$. The initial V2I authentication process is as follows:

Step 1:

$V_i$ enters $I{D}_i$ and $P{W}_i$ into $S{C}_i$, triggering several computations. $S{C}_i$ calculates $HP{W}_i=h(I{D}_i\left|\right|P{W}_i)$, $r_i=A_i\oplus HP{W}_i$, $x_i=B_i\oplus h\left(r_i\right)$, $RP{W}_i=HP{W}_i\oplus h\left(x_i\right)$, and $RI{D}_i=h(I{D}_i\left|\right|RP{W}_i\left|\right|r_i)$. Then, it verifies whether $C_i\stackrel{?}{=}h\left(h\right(RI{D}_i\left|\right|x_i)$ mod l).

Step 2:

$V_i$ selects a random $b_i$ and computes $P_{ij}=(r_i·b_i)·P_j$, $P_i=(r_i·b_i)·P$, $M_1=RI{D}_i\oplus h(I{D}_j\left|\right|P_{ij}\left|\right|T_1)$, and $M_2=h(RI{D}_i\left|\right|P_{ij}\left|\right|T_1)$. It sends the computed values $(M_1,M_2,P_i,T_1)$ to $RS{U}_j$.

Step 3:

$RS{U}_j$ checks the timestamp $T_1$, calculates $P_{ij}=s_j·P_i$, and derives $RI{D}_i=M_1\oplus h(I{D}_j\left|\right|P_{ij}\left|\right|T_1)$. It confirms the presence of $h\left(RI{D}_i\right|\left|k\right)$ in the blockchain and verifies $M_2\stackrel{?}{=}h(RI{D}_i\left|\right|P_{ij}\left|\right|T_1)$, authenticating $V_i$.

Step 4:

$RS{U}_j$ generates random values $b_j$ and $n_j$ and a timestamp $T_2$. The RSU calculates $Q_{ij}=b_j·P_i$, $Q_j=b_j·P$, $TI{D}_i=RI{D}_i\oplus h(n_j\left|\right|I{D}_j\left|\right|k)$, $M_3=TI{D}_i\oplus h(Q_{ij}\left|\right|RI{D}_i)$, $S{K}_{ij}=h(Q_{ij}\left|\right|TI{D}_i\left|\right|RI{D}_i)$, and $M_4=h(S{K}_{ij}\left|\right|T_2)$. These values $(M_3,M_4,Q_j,T_2)$ are sent to $V_i$.

Step 5:

Upon receipt, $V_i$ calculates $Q_{ij}=(r_i·b_i)·Q_j$, determines $TI{D}_i$ as $M_3\oplus h(Q_{ij}\left|\right|RI{D}_i)$, and derives $S{K}_{ij}$ as $h\left(Q_{ij}\right|\left|TI{D}_i\right|\left|RI{D}_i\right)$. The RSU checks if $M_4$ equals $h\left(S{K}_{ij}\right|\left|T_2\right)$. If so, $RS{U}_j$ uploads $(TI{D}_i,n_j,I{D}_j,Si{g}_j\left(h\right(TI{D}_i\left|\right|RI{D}_i\left|\right|n_j\left)\right))$ to the blockchain.

3.4. Blockchain-Enabled Handover Authentication

When $V_i$ transitions to $RS{U}_k$ from $RS{U}_j$, a mutual authentication process between $V_i$ and $RS{U}_k$ occurs. The authentication phase consists of the following steps:

Step 1:

$V_i$ generates a random value $c_i$, calculates $M_5=h(RI{D}_i\left|\right|TI{D}_i\left|\right|I{D}_k\left|\right|T_3) \oplus c_i$, and computes $M_6=h(c_i\left|\right|RI{D}_i\left|\right|TI{D}_i)$. It then transmits these values $(TI{D}_i,M_5,M_6,T_3)$ to $RS{U}_k$.

Step 2:

Upon receipt, $RS{U}_k$ retrieves the corresponding transaction $(TI{D}_i,n_j,I{D}_j,$$Si{g}_j\left(h\right(TI{D}_i\left|\right|RI{D}_i\left|\right|n_j\left)\right))$ from the blockchain. The RSU verifies the signature, computes $RI{D}_i^{\ast }=TI{D}_i$$\oplus h\left(n_i\right|\left|I{D}_j\right|\left|k\right)$, and checks if $h(TI{D}_i\left|\right|RI{D}_i^{\ast }\left|\right|n_j)\stackrel{?}{=}h(TI{D}_i\left|\right|RI{D}_i\left|\right|n_j)$.

Step 3:

If the values are consistent, $RS{U}_k$ calculates $c_i=h(RI{D}_i\left|\right|TI{D}_i\left|\right|I{D}_k\left|\right|T_3) \oplus M_5$ and checks if $M_6\stackrel{?}{=}h(c_i\left|\right|RI{D}_i\left|\right|TI{D}_i)$. Upon successful verification, $RS{U}_k$ generates random $c_k$ and $n_k$, then computes $TI{D}_{new}=RI{D}_i\oplus h(n_k\left|\right|I{D}_k\left|\right|k)$, $M_7=TI{D}_{new}\oplus h(c_i\left|\right|RI{D}_i)$, $M_8=c_k\oplus h(c_i\left|\right|TI{D}_{new}\left|\right|RI{D}_i)$, $S{K}_{ik}=$$h\left(c_k\right|\left|c_i\right|\left|TI{D}_{new}\right|\left|RI{D}_i\right)$, and $M_9=h(S{K}_{ik}\left|\right|T_4)$. These values $(M_7,M_8,M_9,T_4)$ are then sent to $V_i$.

Step 4:

$V_i$ upon receiving this information, calculates $TI{D}_{new}=M_7\oplus h(c_i\left|\right|RI{D}_i)$, $c_k=M_8\oplus h(c_i\left|\right|TI{D}_{new}\left|\right|RI{D}_i)$, and $S{K}_{ik}=h(c_k\left|\right|c_i\left|\right|TI{D}_{new}\left|\right|RI{D}_i)$. It verifies $M_9\stackrel{?}{=}h(S{K}_{ik}\left|\right|T_4)$. The successful completion of these steps confirms mutual authentication between $V_i$ and $RS{U}_k$. Additionally, $RS{U}_k$ appends $(TI{D}_{new},n_k,I{D}_k,Si{g}_k\left(h\right(TI{D}_{new}\left|\right|RI{D}_i\left|\right|n_k\left)\right))$ to the blockchain.

3.5. Vehicle Revocation

During communication, RSUs can detect deviations in $V_i$’s behavior. In response, RSUs have the authority to revoke $V_i$ by invalidating $h\left(RI{D}_i\right|\left|k\right)$ via blockchain transactions. This action nullifies $h\left(RI{D}_i\right|\left|k\right)$, preventing $V_i$ from communicating with other RSUs. This deterrence mechanism is strengthened by the shared blockchain transactions among RSUs, enabling the identification of unauthorized activities by $V_i$. Furthermore, if $V_i$ attempts re-registration with the TA, it must submit $I{D}_i$. The TA can infer $RI{D}_i$ from $I{D}_i$ and stored values, thereby rejecting $V_i$’s registration request.

4. Cryptanalysis of Son et al.’s [19] Protocol

Son et al. claim that their protocol fulfills the essential security properties required for a handover authentication scheme [19]. Nevertheless, our analysis exposes several crucial vulnerabilities in their protocol, such as susceptibility to vehicle impersonation, traceability, and susceptibility to TA circumvention attacks.These attacks can result in privacy violations and data tampering, and in severe cases, they may compromise system security, leading to crashes and system outages. To break through these vulnerabilities, the attacker $\mathcal{A}$ initially needs to obtain secret data, $s_j$ and k, stored in $RS{U}_j$, typically through power analysis attacks (like side channel attacks). As noted in [10], the remote placement of RSUs makes them vulnerable to physical attacks, allowing $\mathcal{A}$ to capture and manipulate RSUs, extract cryptographic details, and even relocate tampered RSUs to facilitate further attacks.

4.1. Traceability Attacks

Ensuring vehicle untraceability in VANETs is crucial for protecting privacy. This means preventing attackers from tracing a specific vehicle’s route [25]. Specifically, an attacker should not be able to determine which RSUs a vehicle has passed.

It is generally assumed that RSU administrators/managers will not engage in “active” attacks. However, they may act as “honest-but-curious” adversaries $\mathcal{A}$ and initiate “passive” attacks. To acquire a vehicle’s RID, we now present two methods through which $\mathcal{A}$ can acquire a vehicle’s pseudo-identity RID:

Case1: With the secret key $s_j$ of $RS{U}_j$ and intercepted data $(M_1,M_2,P_i,T_1)$ from a public channel, $\mathcal{A}$ calculates $P_{ij}=s_j·P_i$ and the pseudo-identity $RI{D}_i=M_1\oplus h(I{D}_j\left|\right|P_{ij}\left|\right|T_1)$.

Case2: Using the secret key k from a compromised RSU, $\mathcal{A}$ accesses blockchain transaction data to extract $(TI{D}_i,n_j,I{D}_j,Si{g}_j\left(h\right(TI{D}_i\left|\right|RI{D}_i\left|\right|n_j\left)\right))$. Then, $\mathcal{A}$ computes $RI{D}_i=TI{D}_i\oplus h(n_j\left|\right|I{D}_j\left|\right|k)$, thus acquiring any vehicle’s pseudo-identity RID authenticated by an RSU.

This enables $\mathcal{A}$ to associate specific $TID$s with a given pseudo-identity RID. Since each vehicle has a unique pseudo-identity, $\mathcal{A}$ can then identify all RSUs (through their $ID$s) that a particular vehicle has encountered. Consequently, $\mathcal{A}$ effectively compromises the trace privacy of vehicles.

4.2. Vehicle Impersonation Attacks

Vehicle impersonation attacks involve attackers disguising themselves as legitimate vehicles registered with the TA. These attacks pose serious risks, such as obtaining paid services under false pretenses or engaging in malicious activities to avoid detection and punishment, thereby compromising the security of VANETs [26].

Our scrutiny of Son et al.’s initial V2I authentication stage indicated the following major flaw: if an attacker acquires a vehicle’s pseudo-identity RID, they can convincingly impersonate that vehicle and pass the authentication checks of all RSUs. Worryingly, this could even apply to unregistered vehicles, highlighting the severity of this security breach. The vehicle impersonation attack proceeds as follows:

Step 1:

$\mathcal{A}$ selects a random number $b_i^{\ast }$ and a timestamp $T_1^{\ast }$.

Step 2:

Upon choosing the random number and timestamp, $\mathcal{A}$ computes the following values from the acquired pseudo-identity $RI{D}_i$ as the vehicle enters the legitimate $RS{U}_t$:

$$\begin{array}{cc}\hfill P_{it}^{\ast }& =b_i^{\ast }·P_t\hfill \end{array}$$

(1)

$$\begin{array}{cc}\hfill P_i^{\ast }& =b_i^{\ast }·P\hfill \end{array}$$

(2)

$$\begin{array}{cc}\hfill M_1^{\ast }& =RI{D}_i\oplus h(I{D}_t\left|\right|P_{it}^{\ast }\left|\right|T_1^{\ast })\hfill \end{array}$$

(3)

$$\begin{array}{cc}\hfill M_2^{\ast }& =h\left(RI{D}_i\right|\left|P_{it}^{\ast }\right|\left|T_1^{\ast }\right)\hfill \end{array}$$

(4)

Step 3:

$\mathcal{A}$ then creates a valid authentication request message $(M_1^{\ast },M_2^{\ast },P_i^{\ast },T_1^{\ast })$.

Step 4:

$RS{U}_t$ authenticates the message $(M_1^{\ast },M_2^{\ast },P_i^{\ast },T_1^{\ast })$, calculates $S{K}_{it}^{\ast }=TI{D}_i^{\ast }\oplus h(n_j\left|\right|I{D}_t\left|\right|k)$, and forwards the message $(M_3^{\ast },M_4^{\ast },Q_t^{\ast },T_2^{\ast })$ to $\mathcal{A}$.

Step 5:

$\mathcal{A}$ receives the message and computes $Q_{it}^{\ast }=b_i^{\ast }·Q_t^{\ast }$, $TI{D}_i^{\ast }=M_3^{\ast }\oplus h(Q_{it}^{\ast }\left|\right|RI{D}_i)$, and $S{K}_{it}^{\ast }=h(Q_{it}^{\ast }\left|\right|TI{D}_i^{\ast }\left|\right|RI{D}_i)$.

Step 6:

Consequently, both $\mathcal{A}$ and $RS{U}_t$ generate the session key $S{K}_{it}^{\ast }$ and maintain it.

Through this attack, $\mathcal{A}$ can convincingly impersonate a legitimate vehicle and gain access to $RS{U}_t$.

4.3. TA Circumvention Attacks

In a secure VANET system, vehicles must register with the TA before accessing services. However, the following attack scenario demonstrates a vulnerability. An RSU administrator can impersonate a TA and complete the vehicle registration process independently. This breach is possible because the legitimate TA uses a shared secret key k with the RSU to verify the vehicle registration information uploaded to the blockchain. An RSU with knowledge of k can bypass the TA, create registration data, and upload it to the blockchain. The attack process unfolds as follows:

Step 1:

The vehicle selects $I{D}_i,P{W}_i$ and $x_i$, computes $HP{W}_i=h(I{D}_i\left|\right|P{W}_i)$ and $RP{W}_i=HP{W}_i\oplus h\left(x_i\right)$, and sends $(I{D}_i,RP{W}_i)$ to the RSU, not the TA.

Step 2:

Upon receiving $(I{D}_i,RP{W}_i)$, the RSU generates $r_i$ and computes $RI{D}_i=h(I{D}_i\left|\right|RP{W}_i\left|\right|r_i)$.

Step 3:

The RSU then uploads $h\left(RI{D}_i\right|\left|k\right)$ to the blockchain.

This process effectively completes the registration of the vehicle by the RSU, allowing the vehicle to authenticate interactions with all RSUs using their registered $RI{D}_i$. Consequently, $\mathcal{A}$ can launch attacks upon bypassing the TA.

5. Our Improved Protocol

In response to the security issues identified in Son et al.’s protocol, we propose specific enhancements and introduce our improved protocol. Firstly, to mitigate vehicle impersonation attacks, our protocol employs the Schnorr signature. Secondly, we address traceability attacks by reducing the size of parameters uploaded to the blockchain, opting for hashing over signatures. Lastly, to prevent circumvention attacks, we incorporate unique parameters from the TA. The effectiveness of these measures will be demonstrated in the subsequent section. Additionally, our design aims for the protocol to be lightweight.

It is important to note that our new protocol builds upon Son et al.’s framework. Therefore, the general process of both protocols remains similar. To provide a clear explanation and ensure completeness, we will reiterate the identical parts in our description.

5.1. System Setup

The TA establishes an elliptic curve $E_p(a,b)$, utilizing P as the generator within the group $\mathbb{G}$. Besides selecting a secret key y and its corresponding public key Y, the TA employs a one-way hash function $h(·)$ and a fuzzy verifier l, adhering to the condition $2^4\le l\le 2^8$. The shared parameters k, private key $s_j$, and identity $I{D}_j$ are securely stored in the RSU following the same system initialization steps as Son’s scheme, where $s_j=h(I{D}_j\left|\right|y)$, and $k=h\left(I{D}_{TA}\right|\left|y\right)$.

5.2. Vehicle Registration

Prior to initiating authentication with an RSU, vehicle $V_i$ must register with the TA. The initial V2I authentication phase is depicted in Figure 2.

Step 1:

$V_i$ generates a unique identity $I{D}_i$ and password $P{W}_i$, and selects a random number $x_i$. It then computes $HP{W}_i=(I{D}_i\left|\right|P{W}_i)$ and $RP{W}_i=HP{W}_i\oplus h\left(x_i\right)$. $V_i$ transmits the values $(I{D}_i,RP{W}_i)$ to the TA.

Step 2:

The TA verifies whether $I{D}_i$ is already registered and if the corresponding $RI{D}_i$ is on the revocation list. If not, TA selects $r_i$ randomly and computes $R_i=r_i·P$, $RI{D}_i=h(I{D}_i\left|\right|RP{W}_i\left|\right|R_i)$, $\alpha =h\left(RI{D}_i\right|\left|R\right)$, and $\beta =r_i+\alpha \ast y$. TA securely stores $(I{D}_i,RP{W}_i,r_i)$ and stores $(R_i,\beta ,l)$ in $S{C}_i$, which is then forwarded to $V_i$.

Step 3:

$V_i$, upon receiving $S{C}_i$, performs the following computations: $RI{D}_i=$$h\left(I{D}_i\right|\left|RP{W}_i\right|\left|R_i\right)$, $A_i=R_i\oplus HP{W}_i$, $B_i=x_i\oplus h\left(R_i\right)$, $C_i=\beta \oplus h(x_i\left|\right|R_i)$, and $D_i=h\left(h\right(RI{D}_i\left|\right|x_i\left)\mathrm{mod}l\right)$. The values $(R_i,\beta )$ in $S{C}_i$ are then replaced with $(A_i,B_i,C_i,D_i)$, concluding this phase.

5.3. Initial V2I Authentication

Following the registration phase, the authentication process between $V_i$ and $RS{U}_j$ is outlined in Figure 3. The process includes the following steps:

Step 1:

$V_i$ inputs $I{D}_i$ and $P{W}_i$ into $S{C}_i$. $S{C}_i$ calculates various values, including $HP{W}_i=h(I{D}_i\left|\right|P{W}_i)$, $R_i=A_i\oplus HP{W}_i$, $x_i=B_i\oplus h\left(R_i\right)$, $RP{W}_i=HP{W}_i\oplus h\left(x_i\right)$, $\beta =C_i\oplus h(x_i\left|\right|R_i)$, and $RI{D}_i=h(I{D}_i\left|\right|RP{W}_i\left|\right|r_i)$. $S{C}_i$ then verifies $D_i\stackrel{?}{=}h\left(h\right(RI{D}_i\left|\right|x_i)$ mod l).

Step 2:

If verification is successful, $V_i$ selects a random number $b_i$ and calculates $P_{ij}=b_i·P_j$, $P_i=b_i·P$, $M_1=RI{D}_i\oplus h(I{D}_j\left|\right|P_{ij}\left|\right|T_1)$, $M_2=\beta \oplus h(RI{D}_i\left|\right|T_1\left|\right|P_{ij})$, $M_3=R_i\oplus h(RI{D}_i\left|\right|P_{ij})$, and $M_4=h(RI{D}_i\left|\right|\beta \left|\right|R_i\left|\right|P_{ij}\left|\right|T_1)$. $V_i$ sends $(M_1,M_2,M_3,M_4,$$P_i,T_1)$ to $RS{U}_j$.

Step 3:

On receipt, $RS{U}_j$ verifies the timestamp $T_1$ and computes $RI{D}_i=M_1\oplus h(RI{D}_i\left|\right|P_{ij}\left|\right|T_1)$, $\beta =M_2\oplus h(RI{D}_i\left|\right|T_1\left|\right|P_{ij})$, and $R_i=M_3\oplus h(RI{D}_i\left|\right|P_{ij})$. The RSU retrieves $\left(h\right(RI{D}_i\left|\right|R_i),\beta )$ and calculates $R=\beta ·P-h(RI{D}_i\left|\right|R_i)·Y$, where Y is the public key of the TA. It verifies $h(RI{D}_i\left|\right|R)\stackrel{?}{=}h(RI{D}_i\left|\right|R_i)$, indicating successful vehicle authentication. The integrity of $M_4$ is also verified by checking if $M_4\stackrel{?}{=}h(RI{D}_i\left|\right|\beta \left|\right|R_i\left|\right|P_{ij}\left|\right|T_1)$.

Step 4:

Subsequently, $RS{U}_j$ generates random numbers $b_j$ and $n_j$ and a timestamp $T_2$. It calculates $Q_{ij}=b_j·P_i$, $Q_j=b_j·P$, $TI{D}_i=RI{D}_i\oplus h(n_j\left|\right|k)$, $M_5=TI{D}_i\oplus h(Q_{ij}\left|\right|RI{D}_i)$, $S{K}_{ij}=h(Q_{ij}\left|\right|TI{D}_i\left|\right|RI{D}_i)$, and $M_6=h(S{K}_{ij}\left|\right|T_2)$. $RS{U}_j$ transmits $(M_5,M_6,Q_j,T_2)$ to $V_i$.

Step 5:

Upon receiving the message, $V_i$ calculates $Q_{ij}=b_i·Q_j$, $TI{D}_i=M_5\oplus h(Q_{ij}\left|\right|RI{D}_i)$, $S{K}_{ij}=h(Q_{ij}\left|\right|TI{D}_i\left|\right|RI{D}_i)$, and verifies $M_6\stackrel{?}{=}h(S{K}_{ij}\left|\right|T_2)$. Following successful mutual authentication, $RS{U}_j$ uploads $(TI{D}_i,n_j,h(TI{D}_i\left|\right|RI{D}_i\left|\right|k\left)\right)$ to the blockchain.

5.4. Blockchain-Based Handover Authentication

When vehicle $V_i$ successfully authenticates with $RS{U}_j$ and enters the coverage area of $RS{U}_k$, it is essential to initiate a new round of mutual authentication between $V_i$ and $RS{U}_k$. The blockchain-based handover authentication procedure is illustrated in Figure 4 and proceeds as follows:

Step 1:

$V_i$ generates a random value $c_i$ and computes $M_7=h(RI{D}_i\left|\right|TI{D}_i\left|\right|I{D}_k\left|\right|T_3) \oplus c_i$, along with $M_8=h(c_i\left|\right|RI{D}_i\left|\right|TI{D}_i)$. $V_i$ then transmits $(TI{D}_i,M_7,M_8,T_3)$ to $RS{U}_k$.

Step 2:

On receiving this message, $RS{U}_k$ retrieves the transaction $(TI{D}_i,n_j,h(TI{D}_i$$\left|\right|RI{D}_i\left|\right|k\left)\right)$ from the blockchain. It then calculates $RI{D}_i=TI{D}_i\oplus h(n_i\left|\right|k)$ and verifies whether $h(TI{D}_i\left|\right|RI{D}_i\left|\right|k)\stackrel{?}{=}h(TI{D}_i\left|\right|RI{D}_i\left|\right|k)$.

Step 3:

If the verification is successful, $RS{U}_k$ computes $c_i=h(RI{D}_i\left|\right|TI{D}_i\left|\right|I{D}_k\left|\right|T_3) \oplus M_7$ and checks if $M_8\stackrel{?}{=}h(c_i\left|\right|RI{D}_i\left|\right|TI{D}_i)$. Upon confirmation, $RS{U}_k$ generates random values $c_k$ and $n_k$, and calculates $TI{D}_k=RI{D}_i\oplus h(n_k\left|\right|k)$, $M_9=TI{D}_k\oplus h(c_i\left|\right|RI{D}_i)$, $M_{10}=c_k\oplus h(c_i\left|\right|TI{D}_k\left|\right|RI{D}_i)$, $S{K}_{ik}=h(c_k\left|\right|c_i\left|\right|TI{D}_k\left|\right|RI{D}_i)$, and $M_{11}=h(S{K}_{ik}\left|\right|T_4)$. $RS{U}_k$ then transmits $(M_9,M_{10},M_{11},T_4)$ to $V_i$.

Step 4:

Upon receipt, $V_i$ calculates $TI{D}_k=M_9\oplus h(c_i\left|\right|RI{D}_i)$, $c_k=M_{10}\oplus h(c_i\left|\right|TI{D}_k\left|\right|$$RI{D}_i)$, and $S{K}_{ik}=h(c_k\left|\right|c_i\left|\right|TI{D}_k\left|\right|RI{D}_i)$. $V_i$ then verifies if $M_{11}\stackrel{?}{=}h(S{K}_{ik}\left|\right|T_4)$. The successful completion of these steps confirms mutual authentication between $V_i$ and $RS{U}_k$, after which $RS{U}_k$ uploads $(TI{D}_k,n_k,h(TI{D}_k\left|\right|RI{D}_i\left|\right|n_k\left)\right)$ to the blockchain.

5.5. Vehicle Revocation

During communication, if $V_i$ exhibits any inappropriate behavior, it can be detected by RSUs. In response, an RSU can upload a transaction to the blockchain that invalidates the corresponding entry $h\left(RI{D}_i\right|\left|k\right)$. This action effectively nullifies the validity of $h\left(RI{D}_i\right|\left|k\right)$, preventing $V_i$ from engaging in further communication with other RSUs. As RSUs collectively access blockchain records, they can quickly identify and flag any unauthorized activities of $V_i$. Moreover, if $V_i$ attempts to re-register with the TA, it is required to provide $I{D}_i$ during the registration phase. The TA, utilizing $I{D}_i$ along with securely stored data, can derive $RI{D}_i$, enabling it to conclusively reject any registration requests from $V_i$.

6. Security Analysis of the Improved Protocol

In this section, we first present our design goals related to security features and then offer both heuristic and formal security analyses to demonstrate that our proposed scheme successfully achieves all these design goals.

Security Goals

Our design goals include identity privacy, confidentiality, message integrity, and resistance to common attacks, which are detailed as follows:

• Identity privacy: The proposed protocol should enable vehicle users to authenticate without revealing their identity and ensure that their activities and actions cannot be traced.
• Confidentiality: The proposed protocol needs to ensure that all data and information on public transmission channels remain private and prevent unauthorized access and leakage.
• Message integrity: The proposed protocol needs to ensure that the data transmitted during the authentication process have not been tampered with.
• Resistance to common attacks: The proposed protocol is designed to effectively counter a range of potential security threats, including but not limited to replay attacks and impersonation attacks.

7. Heuristic Security Analysis

The heuristic security analysis of our proposed scheme is outlined as follows:

7.1. Anonymity and Untraceability

In the authentication phase, the vehicle’s real identity $I{D}_i$ is concealed, utilizing the pseudonym $RI{D}_i$. This approach ensures that adversaries cannot determine the actual identity of the vehicle, thereby maintaining anonymity. Moreover, the information uploaded to the blockchain by RSUs, $(TI{D}_i,n_j,h(RI{D}_i\left|\right|TI{D}_i\left|\right|k\left)\right)$, only serves to verify the vehicle’s RID without revealing the RSU details. The dynamic temporary identity $TID$ updates via blockchain, and refreshed $TID$ values using RSU-specific nonces $n_k$ break long-term pseudonym linkage. With $TI{D}_i$ being refreshed during each handover authentication, it becomes impossible for adversaries to track the vehicle’s movement across RSUs, ensuring untraceability.

7.2. Mutual Authentication

The improved protocol establishes robust mutual authentication through a bidirectional verification framework. Throughout the authentication phase, both $RS{U}_j$ and $RS{U}_k$ can deduce the vehicle’s pseudonymous RID from the transmitted vehicle data. In the initial authentication, the vehicle sends $R_i$ and $\beta$, enabling the RSUs to verify the legitimacy of its pseudonymous RID using the TA’s public key, Y. The RSU cryptographically validates vehicle registration credentials using the TA’s public key through elliptic curve operations, while the vehicle authenticates the RSU by verifying timestamped session key hashes. This step ensures the authentication of $V_i$ by the RSUs. Also, in both the initial and handover authentication phases, the vehicle receives $M_6$ and $M_{11}$, respectively. By verifying the source of these messages as being from $RS{U}_j$ and $RS{U}_k$, in handover scenarios, infrastructure nodes authenticate vehicles through blockchain-stored identity records, while vehicles confirm RSU legitimacy via temporary identity decryption and session key verification. The protocol achieves mutual authentication.

7.3. Offline Password Guessing Resistance

In the event that an adversary obtains $S{C}_i$, they might try an offline dictionary attack with a list of ${10}^6$ identity–password pairs. However, even if they use $I{D}_i$ and $P{W}_i$ to access $S{C}_i$, verifying the correctness of $(I{D}_i,P{W}_i)$ becomes impossible due to the fuzzy verifier l. The likelihood of accurately guessing $(I{D}_i,P{W}_i)$ is about ${\displaystyle \frac{l}{{10}^{12}}}\cong {\displaystyle \frac{1}{2^{32}}}$, which is extremely low and can be considered negligible.

7.4. Impersonation Attack Resistance

In our scheme, only authorized vehicles can input $I{D}_i$ and $P{W}_i$ to generate $\beta$ and create $(M_1,M_2,M_3,M_4,P_i,T_1)$. By integrating Schnorr signatures with Trusted Authority (TA) key binding, we introduce the parameter $\beta =r_i+h(RI{D}_i\left|\right|R)\ast y$ by integrating Schnorr signatures with TA key binding, where the TA’s private key y cryptographically binds the vehicle registration to authentication processes. This ensures that only TA-registered vehicles can generate valid messages, as forging $\beta$ would require solving the Elliptic Curve Discrete Logarithm Problem (ECDLP), a mathematically intractable task under standardized security assumptions, which RSUs then validate using the TA’s public key. This validation indicates successful registration with the TA, effectively preventing impersonation attacks.

7.5. TA Circumvention Attack Resistance

Our scheme requires vehicles to register with the TA to acquire $\beta$, uniquely generated by the TA as $\beta =r_i+h(RI{D}_i\left|\right|R_i)·y$. Without the TA’s private key, adversaries cannot mimic the registration process, safeguarding against TA circumvention attacks. This process creates an unforgeable trust chain, ensuring all vehicles must undergo legitimate TA registration. Malicious RSUs cannot autonomously provision unauthorized entities. These coordinated measures establish a multi-layered defense architecture that balances security robustness with operational efficiency.

7.6. Replay Attack Resistance

Our approach incorporates timestamps and random numbers to defend against replay attacks. During authentication, the freshness of the timestamp is checked first. The random values $b_i$ and $c_k$ are utilized in establishing the session key, providing a solid defense against replay attacks.

7.7. Perfect Forward Security

Even with access to keys like $s_j$ and k, adversaries cannot calculate the session key $S{K}_{ij}$ due to the inclusion of $Q_{ij}$ in the initial authentication phase. Since the necessary random numbers $b_i$ and $b_j$ for the computation of $Q_{ij}$ are beyond the reach of adversaries, determining $S{K}_{ij}$ is infeasible. This unavailability also extends to the $TI{D}_i$ required for subsequent handover authentication, ensuring our scheme’s provision of perfect forward security.

7.8. Formal Security Analysis Using ProVerif

ProVerif [27] is an automated tool used to analyze and verify the security of cryptographic protocols. It can check properties such as confidentiality, authentication, and resistance to various attacks by formalizing protocols and using logical reasoning. It supports a wide range of protocols, including those based on symmetric and asymmetric encryption. In this section, we utilize ProVerif to evaluate the security of our proposed scheme.

The initial part of the analysis involves the declaration of elements related to our scheme. This includes channels for message transmission, constants, variables, functions, and events, as depicted in Figure 5. Here, we define a public communication channel, ch1, for vehicle–RSU node interactions. Additionally, we establish constants, variables, a hash function $h(·)$, various connection functions, and XOR and ECC operations. The attacker model and associated events are illustrated primarily in Figure 6.

In the next part of the analysis, the focus shifts to the role of vehicles in the authentication process, shown in Figure 7. This process involves vehicles accessing SC-stored data, transmitting an authentication message to the RSU, and formulating a session key based on the information provided by the RSU. The RSU’s role is detailed in Figure 8, which includes decrypting messages using its private key, verifying vehicle identities using the TA’s public key, generating temporary identities and session keys, and securely transmitting these to the vehicle.

Figure 9 presents the results obtained from ProVerif’s analysis of our scheme. The findings confirm that adversaries are unable to obtain the critical parameters necessary for session key computation, thereby establishing the security robustness of our proposed scheme.

8. Performance Comparison

This section presents a detailed performance evaluation of our proposed scheme, focusing on computation, communication, and security aspects. Our performance analysis is based on a comparison between the new protocol and some of the most relevant existing protocols., specifically those detailed in [14,19,28,29].

8.1. Computation Cost

Table 2. Comparison of computation cost.

Scheme	${\mathit{V}}_{\mathit{i}}$	${\mathit{RSU}}_{\mathit{k}}$	Total Performed Operation
[14]	$2T_m+9T_h+1T_{se}$	$4T_m+3T_h+4T_{se}$	$6T_m+12T_h+5T_{se}\approx 20.508$ ms
[19]	$6T_h$	$4T_m+10T_h$	$4T_m+16T_h\approx 12.12$ ms
[28]	$2T_m+4T_h$	$4T_m+4T_h$	$6T_m+8T_h\approx 17.284$ ms
[29]	$6T_h+2T_m$	$5T_h+1T_m$	$11T_h+3T_m\approx 9.034$ ms
Proposed	$6T_h$	$10T_h$	$16T_h\approx 0.896$ ms

offers a comparative analysis of computational costs, contrasting our proposed scheme with those referenced. The evaluations were conducted using a personal computer equipped with an Intel(R) Core(TM) i5-1035G1 CPU @ 1.00 GHz, 1.19 GHz, 16.0 GB RAM, and a Windows 10 64-bit operating system. We denote the computation times for cryptographic one-way hash functions, elliptic curve point operations, and symmetric encryption/decryption functions as $T_h$, $T_m$, and $T_{se}$, respectively, with respective durations of 0.056 ms, 2.806 ms, and 0.062 ms.

Notably, the initial authentication in our scheme is a one-time occurrence, followed by successive handover authentications. Thus, our analysis primarily focuses on the handover authentication overhead for comparison. In our scheme, the computation cost for vehicles is quantified as 6$T_h$, and for the RSU nodes, it is 10$T_h$. The total computation cost for our scheme, therefore, is approximately $6T_h+10T_h\approx 0.896$ ms. In contrast, the total computation costs for the schemes in [14,19] are approximately 20.508 ms and 12.12 ms, respectively. Moreover, the schemes described in [28,29] entail computation times of approximately 17.284 ms and 9.034 ms, respectively. These findings, graphically represented in Figure 10, highlight the lower computational overhead of our proposed scheme compared to the aforementioned alternatives.

8.2. Communication Cost

Table 3. Comparison of communication costs.

Scheme	BC/NBC	Number of Transmitting Messages	Total Communication Overhead (in Bits)
[14]	NBC	11	7264
[19]	BC	4	3618
[28]	BC	4	4416
[29]	BC	2	1472
Proposed	BC	4	3840

BC indicates the utilization of a blockchain-based security solution, while NBC denotes the adoption of a non-blockchain-based security approach.

provides a comparative analysis of communication costs, contrasting our proposed scheme with referenced alternatives. This assessment specifically evaluates the communication costs incurred during the authentication phase of our scheme. For this analysis, we assume the following sizes: the timestamps, identities, and random numbers are set to 32 bits, 160 bits, and 160 bits, respectively; the encryption/decryption processes utilize 256 bits; and the hash function output is set at 256 bits. The size of the elliptic curve point, represented as $P=(Px,Py)$, is established at 320 bits. In our scheme, the communication overhead required in the first authentication is 2240 bits. The communication overhead required in the handover authentication process is 1600 bits. Hence, the total communication of our scheme is 3840 bits.

For comparison, the communication costs of the schemes presented in [14,19,28] and [29] are 7264 bits, 3618 bits, 4416 bits, and 1440 bits, respectively. Figure 11 visually demonstrates that the communication overhead of the proposed protocol is much smaller than [14,28]. This juxtaposition highlights that our proposed scheme achieves competitive communication costs in relation to the other referenced schemes. Our protocol balances security and efficiency through optimized cryptographic design. Introducing 159 bits of additional computation addresses four high-risk vulnerabilities while ensuring robust anonymity and forward secrecy.

8.3. Security Features

Table 4. Comparison of security features.

Security Features	[14]	[19]	[28]	[29]	Ours
A1	✓	×	✓	×	✓
A2	✓	✓	✓	✓	✓
A3	✓	✓	✓	×	✓
A4	✓	×	✓	×	✓
A5	−	×	−	−	✓
A6	✓	✓	✓	✓	✓
A7	✓	✓	✓	✓	✓

−: Feature not considered or lacks security solution in state of the art. ✓: Protocol supports feature or is secure against applicable attacks. ×: Protocol does not support functionality or feature.

presents a detailed comparison of security features between our proposed protocol and other existing protocols. This evaluation covers essential attributes such as A1: “Anonymity and Non-traceability Preservation”; A2: “Mutual Authentication”; A3: “Offline Password Guessing Attack Resistance”; A4: “Impersonation Attack Resistance”; A5: “TA circumvention Attack Preservation”; A6: “Replay Attack Resistance”; and A7: “Perfect Forward Secrecy”. As discussed in Section 7, our protocol successfully maintains these security features. In contrast, we analyze the security of the related protocols. The schemes [14,28] achieve the security goal, but their solution consumes a huge amount of computing and communication overhead. We analyzed Son et al. [19]’s protocol and found it to have some security flaws, such as traceability, impersonation attacks, and TA bypass attacks. The requirements of anonymity and traceability are not met by the scheme [29], and it is vulnerable to off-line password guessing attacks and impersonation attacks. Compared with these protocols, our solution is more suitable for VANETs.

9. Conclusions

We identified security vulnerabilities in the blockchain-based handover authentication protocol proposed by Son et al., specifically the vulnerabilities related to vehicle impersonation, traceability, and TA circumvention attacks. Subsequently, we proposed an enhanced blockchain-based protocol. Our protocol effectively mitigates the identified vulnerabilities while maintaining desirable security properties. Through a comprehensive security analysis and a detailed comparison with related protocols, we demonstrated the relative superiority of our protocol in terms of computational efficiency. Although communication efficiency remains an area for potential improvement, we also envision extending this work to address emerging quantum threats. Future iterations could incorporate post-quantum cryptographic primitives such as lattice-based signatures or hash-based commitments to enhance resistance against quantum computing attacks.