A State-Assisted Authentication and Key Agreement Scheme for Lightweight Multi-RSU Access in VANETs

Abstract

In highly dynamic vehicular ad hoc networks (VANETs), vehicles frequently move across the coverage areas of multiple roadside units (RSUs), making secure and efficient continuous vehicle-to-infrastructure access essential. However, repeated full authentication and key agreement for each new RSU access impose considerable computational and communication overhead. This paper proposes a state-assisted privacy-preserving mutual authentication and key agreement scheme for lightweight multi-RSU access in VANETs. The proposed scheme consists of initial and subsequent authentication phases. In the initial phase, elliptic curve cryptography (ECC) is used to achieve anonymous mutual authentication and session key establishment between vehicles and RSUs. In the subsequent authentication phase, a vehicle leverages follow-up authentication state securely forwarded by the previous RSU to complete fast authentication with a neighboring RSU using only hash and XOR operations. In addition, physically unclonable functions (PUFs) are deployed on both vehicles and RSUs to protect critical secrets. Security analysis shows that the proposed scheme achieves mutual authentication, anonymity preservation, and resistance to common attacks. Performance evaluation shows that it reduces the computational cost of subsequent authentication by more than 90% while maintaining low communication overhead.

1. Introduction

Vehicular ad hoc networks (VANETs) are a key component of Intelligent Transportation Systems (ITSs), enabling real-time communications among vehicles, roadside units (RSUs), and traffic service infrastructure. Through vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communications, VANETs support a wide range of applications, including traffic safety, road condition dissemination, driving assistance, and intelligent transportation services [1,2]. Since these communications are conducted over open wireless channels and often involve sensitive information such as vehicle identities, locations, and cryptographic credentials, secure and efficient authentication is essential for practical VANET deployment [3]. In such open V2I environments, replay, impersonation, Man-in-the-Middle (MitM), and denial-of-service (DoS) attacks may threaten session freshness, entity authenticity, message integrity, and RSU-side processing availability. These threats motivate VANET authentication mechanisms that provide mutual authentication, privacy preservation, lightweight verification, and robustness against invalid or stale authentication states.

In a typical VANET architecture, trusted authorities (TAs), RSUs, and on-board units (OBUs) jointly support infrastructure-assisted vehicular communications. Among them, RSUs play a central role in providing access and authentication services for moving vehicles. However, in highly dynamic traffic environments, vehicles may traverse the coverage areas of multiple RSUs within a short period. In such scenarios, many existing schemes still treat each new RSU access as an independent authentication event, requiring vehicles to repeatedly perform full authentication and key agreement [4,5]. This design introduces considerable computational and communication overhead, especially for resource-constrained OBUs, and limits the efficiency of continuous V2I access in dense and high-mobility environments.

Therefore, a practical VANET authentication scheme should support secure and efficient continuous access across multiple RSUs, rather than handling each new access as a fully independent authentication event [6,7]. In particular, a vehicle should be able to complete secure follow-up authentication with a new RSU during handover without repeatedly executing full authentication and key agreement, while still preserving anonymity, session security, and resistance to common attacks [8,9,10]. However, achieving this goal remains challenging because authentication-related states must be securely inherited across neighboring RSUs without exposing vehicle identity, weakening session-key freshness, or introducing excessive coordination overhead. This indicates the need for a state-assisted continuous authentication mechanism that can securely reuse RSU-assisted authentication states while maintaining anonymity, mutual authentication, and fresh session-key establishment. Moreover, because OBUs and RSUs may be exposed to physical capture and device-level attacks, relying solely on software-protected secrets may introduce additional security risks in practical deployments [11,12,13].

To address these challenges, this paper proposes a state-assisted privacy-preserving mutual authentication and key agreement scheme for lightweight multi-RSU access in VANET environments. The proposed scheme adopts a two-stage authentication design consisting of an initial trust-establishment phase and a lightweight subsequent authentication phase. In the initial phase, elliptic curve cryptography (ECC) is used to achieve anonymous mutual authentication and session key establishment between vehicles and RSUs. In the subsequent authentication phase, a vehicle authenticates with a neighboring RSU by using RSU-specific and session-bound follow-up authentication states securely forwarded by the previous RSU, thereby avoiding repeated full authentication during frequent RSU transitions. In addition, physically unclonable functions (PUFs) are used to provide device-bound protection for locally stored secrets on vehicles and RSUs. Therefore, the lightweight advantage of the proposed scheme mainly lies in the subsequent authentication phase, while PUFs serve as hardware-level protection mechanisms for device-side secrets. Compared with existing ECC-based and PUF-assisted VANET authentication schemes, the proposed scheme focuses on state-assisted continuous authentication across neighboring RSUs. Rather than treating each RSU access as an independent authentication event, the proposed scheme decouples authentication into initial trust establishment and follow-up state-assisted authentication. The subsequent authentication phase reuses RSU-specific and session-bound authentication states forwarded through secure inter-RSU channels, thereby reducing repeated public-key operations during frequent RSU transitions. In this design, PUFs are used to provide device-bound protection for local secrets, while the core authentication efficiency is achieved by the RSU-assisted state inheritance mechanism. The main contributions of this paper are summarized as follows:

• We propose a state-assisted authentication framework for lightweight multi-RSU access in VANET environments. The framework decouples authentication into initial trust establishment and subsequent authentication, enabling secure continuous V2I access without requiring full authentication at every RSU.
• We design an efficient RSU-assisted subsequent authentication mechanism. By using RSU-specific and session-bound authentication states forwarded through secure inter-RSU channels, a vehicle can complete follow-up authentication with a neighboring RSU using only lightweight hash and XOR operations while supporting anonymity, mutual authentication, and fresh session key establishment.
• We introduce PUF-based device-bound secret protection for both vehicles and RSUs. PUFs are used for local secret protection and stable secret recovery through fuzzy extraction, thereby improving the protection of device-side secrets.
• We provide security analysis and performance evaluation for the proposed scheme. The results show that the proposed scheme achieves the required security properties and reduces the computational cost of the subsequent authentication phase by more than 90% while maintaining low communication overhead.

Related Work

Existing VANET authentication studies have mainly focused on privacy preservation, lightweight protocol design, continuous access, and device-level security enhancement [14]. In recent years, several schemes have improved authentication efficiency while preserving user privacy. For example, Lv and Liu [15] proposed a privacy-preserving and lightweight V2I authentication protocol, Su et al. [16] designed an efficient privacy-preserving authentication scheme with reduced TA dependency, and Kumar and Om [4], Shahparian et al. [5], and Shi et al. [17] further extended privacy-preserving authentication to multi-authority, blockchain-enabled, and lattice-based settings. However, these studies still mainly treat each new RSU access as an independent authentication event, requiring repeated full authentication and key agreement. To improve authentication efficiency in highly dynamic vehicular environments, some studies have further explored continuous or fast follow-up authentication. Palaniswamy et al. [7] investigated continuous authentication to reduce repeated authentication overhead during vehicle movement. Gan et al. [8] proposed a privacy-preserving fast V2I authentication scheme, and Liu et al. [9] designed an efficient Merkle-tree-based authentication method. These studies highlight the importance of reducing repeated authentication overhead in mobile vehicular environments. Nevertheless, continuous access across multiple RSUs remains challenging, especially when low follow-up overhead, anonymity preservation, mutual authentication, and fresh session-key establishment must be achieved simultaneously. In particular, although some schemes distinguish between initial and subsequent authentication, they usually do not explicitly employ RSU-specific forwarded states to inherit the authentication context across neighboring RSUs while maintaining fresh session-key establishment. Recent VANET authentication studies have increasingly emphasized deployment-oriented security requirements, including conditional privacy, traceability, revocation support, and resistance to device-level attacks. For example, Zhao et al. [18] proposed a blockchain-based traceability authentication scheme to support anonymous authentication and malicious-vehicle tracing, while Xiong et al. [19] investigated blockchain-based conditional privacy-preserving authentication for enhancing trust management and privacy protection in VANETs. These studies indicate that practical VANET authentication schemes should consider not only cryptographic overhead, but also privacy-preserving identity management, traceability, and revocation-related handling. Another line of research has introduced hardware-assisted protection mechanisms to enhance resistance against device-level attacks. Umar et al. [20] proposed a PUF-based anonymous inter-vehicular authentication protocol, and Yuan et al. [13] further designed a PUF-based multi-factor authentication and key agreement protocol for Internet of Vehicles scenarios. Although these studies demonstrate the value of hardware-assisted secret protection, they mainly focus on device-level protection or specific authentication settings. They do not fully integrate PUF-based secret protection with state-assisted continuous multi-RSU follow-up authentication. Therefore, PUFs in our scheme are used as device-bound protection mechanisms for locally stored secrets, while the main authentication-efficiency improvement is achieved through RSU-assisted state inheritance across neighboring RSUs.

Table 1. Comparison of representative VANET authentication schemes with respect to continuous multi-RSU access.

Scheme	Identity Privacy	Traceability	Multi-RSU Follow-Up	Session-Key Establishment	Hardware-Assisted Protection
Lv and Liu [15]	✓	✕	✕	✓	✕
Kumar and Om [4]	✓	✓	✕	✓	✕
Shahparian et al. [5]	✓	✓	✕	✓	✕
Palaniswamy et al. [7]	✓	✓	✓	✓	✕
Umar et al. [20]	✓	✕	✕	✓	✓
Yuan et al. [13]	✓	✕	✕	✓	✓
Our scheme	✓	✓	✓	✓	✓

Note: ✓ indicates that the feature is supported, whereas ✕ indicates that the feature is not supported.

summarizes representative schemes from the above categories. As shown, existing studies have made notable progress in identity privacy, continuous authentication, and hardware-assisted protection. However, few representative schemes simultaneously support multi-RSU follow-up authentication, traceability, session-key establishment, and hardware-assisted protection within a unified design. This gap motivates the scheme proposed in this paper.

2. System Model

2.1. System Framework

The proposed authentication protocol is designed for a VANET environment consisting of three entities: TA, RSUs, and vehicles, as illustrated in Figure 1. In this architecture, vehicles communicate with RSUs over open wireless channels, while the TA and RSUs are connected through protected backend channels. Adjacent RSUs can also exchange authenticated information through secure links to support follow-up authentication during vehicle movement across multiple RSU coverage areas.

The TA is responsible for system initialization and credential management. It generates the global system parameters, registers vehicles and RSUs, and issues the corresponding authentication-related credentials. In addition, the TA maintains the mapping between real identities and anonymous identities, so that malicious vehicles can be traced and revoked when necessary.

RSUs are deployed along roads to provide infrastructure-side access and authentication services for moving vehicles. Each RSU is capable of verifying authentication messages from vehicles and establishing secure session keys with legitimate users. To support continuous access in high-mobility environments, after a successful initial authentication, the current RSU can securely forward the follow-up authentication state to neighboring RSUs within the expected handover scope. As a result, a vehicle can complete efficient subsequent authentication at any neighboring RSU encountered during handover, without repeating the full initial authentication procedure.

Each vehicle is equipped with an OBU, which stores system parameters and authentication-related secrets. The OBU enables the vehicle to communicate with surrounding RSUs through wireless channels and supports secure message exchange during both initial and follow-up authentication. Since OBUs are resource-constrained and may be exposed to physical attacks, the proposed scheme employs lightweight hash/XOR operations mainly in the subsequent authentication phase, while PUF-assisted protection is used to enhance device-level secret protection.

2.2. Cryptographic and Hardware Assumptions

The proposed scheme is built over an additive cyclic group $\mathbb{G}$ of prime order q generated by the base point P over an elliptic curve. For a scalar $x\in {\mathbb{Z}}_q^{*}$, the corresponding elliptic-curve point is denoted by $xP$. The security of the scheme relies on the hardness of the elliptic curve discrete logarithm problem (ECDLP) and the elliptic curve computational Diffie–Hellman problem (ECCDH) [21].

To strengthen device-level security, physically unclonable functions (PUFs) are deployed on both vehicles and RSUs. A PUF exploits inherent hardware variations to produce device-specific and hard-to-reproduce responses [22,23]. Since raw PUF responses may contain noise, a fuzzy extractor is employed to derive stable cryptographic material [24]. Let $F.Gp(·)$ and $F.Rp(·)$ denote the generation and reproduction functions, respectively. Given a response R, the generation function outputs helper data $HD$ and a key k, i.e., $(k,HD)\leftarrow F.Gp\left(R\right),$ while the reproduction function reconstructs the same key from a noisy response $R^{\prime }$ and the helper data $HD$, i.e., $k\leftarrow F.Rp(R^{\prime },HD).$ In the proposed scheme, the PUF–fuzzy-extractor mechanism is used to protect authentication-related secrets and to support reliable secret recovery during authentication. In this scheme, the PUF is used as a device-bound local secret reconstruction primitive rather than as a public online challenge-response oracle. Thus, the required PUF functionality is closer to a weak-PUF setting, where each vehicle or RSU uses one or a small number of enrolled local challenges to reproduce a device-specific secret through the fuzzy extractor. Accordingly, the protocol does not require a large public challenge-response space or expose massive challenge-response pairs during online authentication.

2.3. Adversary Threat Model

The security of the proposed scheme is analyzed under the Dolev–Yao adversarial model [25], extended with device-level attack assumptions relevant to VANET environments. Under this model, the adversary is assumed to have full control over public wireless communication channels but cannot break standard cryptographic primitives.

Specifically, the adversary is assumed to have the following capabilities:

• The adversary can eavesdrop on, intercept, modify, replay, and delete messages transmitted over public channels.
• The adversary can obtain public system parameters and publicly available identity-related information of protocol participants.
• The adversary may attempt impersonation, replay, man-in-the-middle, and message tampering attacks by actively manipulating protocol messages.
• The adversary may physically capture an OBU or an RSU and launch side-channel or device-level attacks to extract software-stored information. For the PUF primitive, cloning the underlying PUF instance or accurately reproducing its challenge-response behavior is assumed to be infeasible within feasible resources. The helper data generated by the fuzzy extractor is also assumed not to reveal the reconstructed PUF-derived secret by itself. Under this assumption, capturing an RSU does not enable the adversary to clone its PUF-bound secret or reproduce valid PUF-derived values on another device.

Under these assumptions, the proposed scheme is designed to achieve mutual authentication, privacy preservation, session security, and resistance against both communication-based and device-level attacks.

3. The Proposed Scheme

This section presents the proposed authentication scheme for V2I communication in VANET environments. The scheme involves three entities, namely the TA, RSUs, and vehicles equipped with OBUs. Based on the system model and security assumptions introduced in the previous section, the TA is responsible for system initialization and credential management, while adjacent RSUs can securely exchange follow-up authentication states to support continuous access.

Figure 2 illustrates the high-level architecture of the proposed scheme. When a vehicle $V_i$ first enters the coverage of $RS{U}_j$, it performs an ECC-based initial authentication with $RS{U}_j$ over the public V2I channel. After successful initial authentication, $RS{U}_j$ forwards the follow-up authentication state to candidate neighboring RSUs through secure RSU-side channels, with $RS{U}_k$ shown in Figure 2 as an example target RSU. When $V_i$ later moves into the coverage of $RS{U}_k$, the forwarded state enables $RS{U}_k$ to verify the inherited authentication context and complete subsequent authentication with $V_i$ using lightweight hash-based operations, without repeating the full ECC-based authentication procedure. In this process, PUFs and fuzzy extractors are used locally by vehicles and RSUs to protect device-side secrets and support reliable secret recovery. Therefore, the proposed scheme follows a two-stage authentication logic. The initial authentication stage establishes the trust basis and session security through ECC-based mutual authentication, whereas the subsequent authentication stage reuses securely forwarded RSU-side state to support fast continuous access during RSU transitions. This design reduces repeated public-key operations on the vehicle-facing V2I link while preserving privacy, mutual authentication, and session-key establishment. The procedural flow of the proposed scheme is presented in Figure 3, covering initial authentication, inter-RSU state forwarding, follow-up authentication, session-key establishment, and fallback handling.

The main notations used in the following protocol description are summarized in

Table 2. Main notations used in the proposed scheme.

Notation	Description
$V_i$	The i-th vehicle
$R_j,R_{j+1}$	The current RSU and the subsequent RSU
$RI{D}_j,RI{D}_{j+1}$	Identities of $R_j$ and $R_{j+1}$
$VI{D}_i$	Real identity of vehicle $V_i$
$PI{D}_i$	Anonymous pseudonym of $V_i$
P	Generator of the elliptic curve group $\mathbb{G}$
q	Large prime order of $\mathbb{G}$
$x_T,X_T$	TA private/public key pair
$x_i,X_i$	Vehicle private/public key pair
$x_j,X_j$	RSU private/public key pair
$A_i,A_j$	Credentials issued by the TA to $V_i$ and $R_j$
$P_i,P_j$	PUF challenges for $V_i$ and $R_j$
$H{D}_i,H{D}_j$	Helper data generated by the fuzzy extractor
$Aut{h}_1$–$Aut{h}_5$	Authentication tokens generated in different phases
$S{K}_{ij},S{K}_{i,j+1}$	Session keys established with $R_j$ and $R_{j+1}$
$\mathsf{\Delta }T,\mathsf{\Delta }{T}_{\mathrm{store}}$	Timestamp threshold and state retention threshold
$h(·)$	One-way hash function
⊕	Bitwise XOR operation

.

3.1. System Initialization and Registration

The trusted authority (TA) initializes the system by selecting an additive cyclic group $\mathbb{G}$ of prime order q over an elliptic curve, together with a generator P. The TA further chooses a master secret key $x_T\in {\mathbb{Z}}_q^{*}$ and computes the corresponding public key $X_T=x_{T}P$. In addition, the TA specifies a secure hash function $h:{\{0,1\}}^{*}\to {\mathbb{Z}}_q^{*}$. The public system parameters are then published as $\{\mathbb{G},q,P,X_T,h\}$.

Before participating in authentication, each RSU must complete registration with the TA. Let $R_j$ denote the j-th RSU. $R_j$ selects its real identity $RI{D}_j$ and a private key $x_j\in {\mathbb{Z}}_q^{*}$, and computes the corresponding public key $X_j=x_{j}P$. Then, $R_j$ sends $(RI{D}_j,X_j)$ to the TA through a secure channel.

Upon receiving the registration request, the TA verifies the legitimacy and uniqueness of $RI{D}_j$. If the identity is valid, the TA selects a random value $t_j\in {\mathbb{Z}}_q^{*}$ and computes $T_j=t_{j}P$ and $A_j=h(X_j \Vert RI{D}_j \Vert T_j)x_T+t_j (\mathrm{mod} q)$. The TA also generates a PUF challenge $P_j$ for the RSU and sends $(T_j,A_j,P_j)$ to $R_j$ through a secure channel.

After receiving the registration response, $R_j$ verifies the correctness of the credential by checking $A_{j}P\stackrel{?}{=}h(X_j \Vert RI{D}_j \Vert T_j)X_T+T_j.$ If the equation holds, $R_j$ evaluates its embedded PUF on challenge $P_j$ to obtain $F_j=\mathrm{PUF}\left(P_j\right)$. Then, $R_j$ applies the fuzzy extractor generation function to derive a stable secret and helper data, i.e., $(k_j,H{D}_j)\leftarrow F.Gp\left(F_j\right)$. To protect its private key, $R_j$ computes $B_j=k_j\oplus x_j$. Finally, $R_j$ stores $(H{D}_j,P_j,RI{D}_j,A_j,T_j,B_j)$ for subsequent authentication.

Before accessing the VANET infrastructure, each vehicle must register with the TA. Let $V_i$ denote the i-th vehicle. $V_i$ selects its real identity $VI{D}_i$ and a private key $x_i\in {\mathbb{Z}}_q^{*}$ and computes the corresponding public key $X_i=x_{i}P$. Then, $V_i$ sends $(VI{D}_i,X_i)$ to the TA through a secure channel.

After verifying the legitimacy and uniqueness of $VI{D}_i$, the TA selects a random value $t_i\in {\mathbb{Z}}_q^{*}$ and computes $T_i=t_{i}P$ and $A_i=h\left(t_i{X}_i\right)x_T+t_i (\mathrm{mod} q)$. The TA also generates a PUF challenge $P_i$ for the OBU of $V_i$. To support conditional traceability and revocation, the TA further selects a random value $c_i\in {\mathbb{Z}}_q^{*}$, computes the tracing anchor $C_i=c_{i}P$, stores $(VI{D}_i,C_i)$ in the revocation database, and sends $(T_i,A_i,P_i,C_i)$ to $V_i$ through a secure channel.

Upon receiving the registration response, $V_i$ verifies the issued credential by checking $A_{i}P\stackrel{?}{=}h\left(x_i{T}_i\right)X_T+T_i.$ If the equation holds, the vehicle computes $Z_i=h\left(x_i{T}_i\right)$. Next, the OBU evaluates its PUF on challenge $P_i$ to obtain $F_i=\mathrm{PUF}\left(P_i\right)$, and derives a stable secret using the fuzzy extractor, i.e., $(k_i,H{D}_i)\leftarrow F.Gp\left(F_i\right)$. Then, $V_i$ computes $b_i=k_i\oplus Z_i$ to protect its secret material. Then, $V_i$ randomly selects an anonymous pseudonym $PI{D}_i$ for subsequent authentication, computes the tracing-related value $T{R}_i=h(PI{D}_i \Vert C_i)$, and derives $G_i=h\left(PI{D}_i\right)T_i$ for the initial authentication procedure. Finally, $V_i$ stores $(A_i,H{D}_i,P_i,b_i,C_i,PI{D}_i,T{R}_i,G_i)$ for the authentication process.

3.2. Initial Authentication and Key Agreement

The purpose of this phase is to establish the first authenticated V2I session between $V_i$ and $R_j$. In this phase, $V_i$ verifies the credential of $R_j$, reconstructs its PUF-protected secret, and sends an anonymous authentication request. Then, $R_j$ verifies the vehicle credential, authenticates $V_i$, establishes $S{K}_{ij}$, and generates the state values that will be used for later follow-up authentication. When a vehicle $V_i$ enters the coverage area of an RSU $R_j$ for the first time, the two parties perform initial authentication and establish a session key. The detailed procedure is shown in Figure 4. Unless otherwise stated, all values involved in XOR operations are encoded as fixed-length bit strings before applying ⊕.

After receiving the broadcast information of $R_j$, namely $(RI{D}_j,X_j,A_j,T_j)$, the vehicle first verifies the legitimacy of the RSU credential by checking $A_{j}P\stackrel{?}{=}h(X_j \Vert RI{D}_j \Vert T_j)X_T+T_j$. If the equation holds, $V_i$ evaluates its embedded PUF on challenge $P_i$ to obtain $F_i^{\prime }=\mathrm{PUF}\left(P_i\right)$ and reconstructs the stable secret via the fuzzy extractor, i.e., $k_i\leftarrow F.Rp(F_i^{\prime },H{D}_i)$. Then, the vehicle recovers $Z_i$ from the stored masked value $b_i$, selects a random ephemeral value $d_i\in {\mathbb{Z}}_q^{*}$, and computes the temporary public component $D_i=d_{i}P$. Based on the RSU public key, it derives $E_0=h\left(d_i{X}_j\right)$, $E_1=E_0\oplus Z_i$, and $E_2=h(E_0 \Vert X_j)\oplus PI{D}_i$. To bind the ephemeral secret to the vehicle credential, $V_i$ further computes $F_1=d_i+A_{i}h\left(PI{D}_i\right) (\mathrm{mod} q)$. Then, it generates a timestamp $T_1$ and computes $Aut{h}_1=h(PI{D}_i \Vert T{R}_i \Vert T_1 \Vert RI{D}_j \Vert E_0)$. Finally, $V_i$ sends $(T_1,Aut{h}_1,D_i,G_i,E_1,E_2,F_1,T{R}_i)$ to $R_j$ through the public channel.

Upon receiving the message from $V_i$, $R_j$ first checks whether the timestamp is fresh. If $T_1$ is valid, $R_j$ evaluates its embedded PUF on challenge $P_j$ to obtain $F_j^{\prime }=\mathrm{PUF}\left(P_j\right)$ and reconstructs the stable secret via the fuzzy extractor, i.e., $k_j\leftarrow F.Rp(F_j^{\prime },H{D}_j)$. Then, the RSU recovers its private key $x_j$ from the stored masked value $B_j$. Using its recovered private key, $R_j$ computes $E_0^{\prime }=h\left(x_j{D}_i\right)$, recovers $Z_i^{\prime }=E_1\oplus E_0^{\prime }$, and derives the vehicle pseudonym as $PI{D}_i^{\prime }=h(E_0^{\prime } \Vert X_j)\oplus E_2$. Then, it computes $F_2=Z_i^{\prime }h\left(PI{D}_i^{\prime }\right) (\mathrm{mod} q)$ and verifies the vehicle credential by checking $F_{1}P\stackrel{?}{=}{F}_2{X}_T+G_i+D_i$. If the equation holds, $R_j$ further verifies the received authentication token by checking $Aut{h}_1\stackrel{?}{=}h(PI{D}_i^{\prime } \Vert T{R}_i \Vert T_1 \Vert RI{D}_j \Vert E_0^{\prime })$. After successful verification, $R_j$ selects two fresh random values $a_1,a_2\in {\mathbb{Z}}_q^{*}$, and computes $A_1=a_{1}P$, $A_2=a_1{D}_i$, and $S_1=h(RI{D}_j \Vert A_2 \Vert E_0^{\prime })$. Then, it derives $V_1=h(S_1\oplus a_2)$ and $V_2=V_1\oplus S_1$. After generating a fresh timestamp $T_3$, the RSU computes $Aut{h}_2=h(A_2 \Vert V_2 \Vert E_0^{\prime } \Vert T_3)$ and establishes the session key as $S{K}_{ij}=h(A_2 \Vert V_1 \Vert RI{D}_j)$. In addition, for subsequent authentication, $R_j$ computes $A_3=h(a_2 \Vert RI{D}_j)\oplus S_1$, $X_1=h(T_1 \Vert V_1)$, $X_2=h(T_3 \Vert V_1)$, and $Aut{h}_3=h(A_3 \Vert X_1 \Vert X_2)$, and retains these values as the forwarding state. Finally, $R_j$ sends $(A_1,V_2,T_3,Aut{h}_2)$ to $V_i$ through the public channel.

After receiving $(A_1,V_2,T_3,Aut{h}_2)$, the vehicle checks the freshness of timestamp $T_3$. If valid, it computes $A_2^{\prime }=d_i{A}_1$ and verifies $Aut{h}_2\stackrel{?}{=}h(A_2^{\prime } \Vert V_2 \Vert E_0 \Vert T_3)$. If the equation holds, the vehicle computes $S_1^{\prime }=h(RI{D}_j \Vert A_2^{\prime } \Vert E_0)$, recovers $V_1^{\prime }=V_2\oplus S_1^{\prime }$, and establishes the session key as $S{K}_{ij}=h(A_2^{\prime } \Vert V_1^{\prime } \Vert RI{D}_j)$. For subsequent authentication, it further computes $X_1^{\prime }=h(T_1 \Vert V_1^{\prime })$ and $X_2^{\prime }=h(T_3 \Vert V_1^{\prime })$, selects a fresh random value $d_2$, derives a masking key $m{k}_i^{\left(1\right)}=h(k_i \Vert d_2)$, and masks $S_1^{\prime }$ as $S_2=m{k}_i^{\left(1\right)}\oplus S_1^{\prime }$. Finally, $V_i$ stores $(X_1^{\prime },X_2^{\prime },S_2,V_2,d_2,S{K}_{ij})$ for the subsequent authentication phase.

3.3. Subsequent Authentication

This phase consists of two closely related parts: inter-RSU state preparation and vehicle-to-RSU follow-up authentication. After the initial authentication, $R_j$ forwards the short-lived state $(a_2,Aut{h}_3,RI{D}_j,X_1,X_2)$ to adjacent RSUs, and each receiving RSU stores a PUF-protected local form of this state for later lookup. When $V_i$ enters $R_{j+1}$, it uses its locally stored follow-up state to prove that it has completed the previous initial authentication, while $R_{j+1}$ uses the forwarded state to verify the inherited authentication context and establish a fresh session key without invoking ECC operations. When a vehicle leaves the coverage area of the current RSU and enters that of a neighboring RSU, it performs subsequent authentication instead of repeating the initial authentication process. To support fast follow-up authentication at any adjacent RSU, after completing the authentication with $V_i$, the current RSU $R_j$ securely sends $(a_2,Aut{h}_3,RI{D}_j,X_1,X_2)$ to all adjacent RSUs. When the vehicle later enters one of these neighboring RSUs, denoted by $R_{j+1}$, the RSU evaluates its embedded PUF on challenge $P_{j+1}$ and reconstructs its stable secret via the fuzzy extractor, i.e., $F_{j+1}^{\prime }=\mathrm{PUF}\left(P_{j+1}\right)$ and $k_{j+1}\leftarrow F.Rp(F_{j+1}^{\prime },H{D}_{j+1})$. To avoid directly reusing the same PUF-recovered secret in multiple XOR masking operations, $R_{j+1}$ derives a context-dependent masking value $m{k}_{j+1}=h(k_{j+1} \Vert X_1 \Vert X_2 \Vert RI{D}_j)$ and computes $a_3=m{k}_{j+1}\oplus a_2$ for protected local storage. Then, $R_{j+1}$ stores $(X_1,X_2,a_3,Aut{h}_3,RI{D}_j)$ in its local mapping table by using $X_1$ as the lookup index. The stored state is deleted once its retention period exceeds the predefined threshold $\mathsf{\Delta }{T}_{\mathrm{store}}$. The forwarding of authentication state between adjacent RSUs is illustrated in Figure 5.

The subsequent authentication procedure is shown in Figure 6. When $V_i$ enters the coverage area of $R_{j+1}$, it first evaluates its embedded PUF on challenge $P_i$ to obtain $F_i^{″}=\mathrm{PUF}\left(P_i\right)$ and reconstructs the stable secret via the fuzzy extractor, i.e., $k_i\leftarrow F.Rp(F_i^{″},H{D}_i)$. Then, the vehicle derives a masking key $m{k}_i^{\left(1\right)}=h(k_i \Vert d_2)$ and recovers $S_1^{\prime }$ from the stored masked value $S_2$ by computing $S_1^{\prime }=m{k}_i^{\left(1\right)}\oplus S_2$. After that, it generates a fresh timestamp $T_5$, computes $E_3=S_1^{\prime }\oplus X_2^{\prime }$, and derives $E_4=h(S_1^{\prime } \Vert E_3 \Vert T_5 \Vert PI{D}_i^{new} \Vert T{R}_i^{new})$. Finally, $V_i$ sends $(T{R}_i^{new},X_1^{\prime },E_3,T_5,E_4)$ to $R_{j+1}$ through the public channel.

After receiving the message, $R_{j+1}$ first checks the freshness of timestamp $T_5$. If the timestamp is valid, it retrieves the stored tuple $(X_2,a_3,Aut{h}_3,RI{D}_j)$ by using $X_1^{\prime }$ as the lookup index. Then, $R_{j+1}$ evaluates its embedded PUF on challenge $P_{j+1}$ to obtain $F_{j+1}^{″}=\mathrm{PUF}\left(P_{j+1}\right)$ and reconstructs the stable secret via the fuzzy extractor, i.e., $k_{j+1}\leftarrow F.Rp(F_{j+1}^{″},H{D}_{j+1})$. It further derives $m{k}_{j+1}^{\prime }=h(k_{j+1} \Vert X_1^{\prime } \Vert X_2 \Vert RI{D}_j)$ and recovers $a_2^{\prime }=m{k}_{j+1}^{\prime }\oplus a_3$. Then, $R_{j+1}$ computes $S_1^{″}=E_3\oplus X_2$ and verifies whether $E_4\stackrel{?}{=}h(S_1^{″} \Vert E_3 \Vert T_5 \Vert PI{D}_i^{new} \Vert T{R}_i^{new})$. If the equation holds, the RSU derives $A_3^{\prime }=h(a_2^{\prime } \Vert RI{D}_j)\oplus S_1^{″}$ and verifies whether $Aut{h}_3\stackrel{?}{=}h(A_3^{\prime } \Vert X_1^{\prime } \Vert X_2)$. If the verification succeeds, $R_{j+1}$ confirms the legitimacy of $V_i$ and proceeds to generate the response for the next round of lightweight authentication. Specifically, $R_{j+1}$ computes $V_1^{″}=h(S_1^{″}\oplus a_2^{\prime })$ and derives $S_3=h(RI{D}_{j+1} \Vert V_1^{″} \Vert X_{j+1})$. Then, it selects a fresh random value $a_4\in {\mathbb{Z}}_q^{*}$, computes $V_3=h(S_3\oplus a_4)$ and $V_4=V_3\oplus S_3$, and generates a fresh timestamp $T_7$. The RSU further computes $Aut{h}_4=h(V_1^{″} \Vert V_4 \Vert RI{D}_j \Vert RI{D}_{j+1} \Vert T_7)$, together with the forwarding state for the next subsequent RSU, namely $A_4=h(a_4 \Vert RI{D}_{j+1})\oplus S_3$, $X_3=h(T_5 \Vert V_3)$, $X_4=h(T_7 \Vert V_3)$, and $Aut{h}_5=h(A_4 \Vert X_3 \Vert X_4)$. Finally, $R_{j+1}$ sends $(Aut{h}_4,V_4,T_7)$ to $V_i$ through the public channel.

After receiving the response, $V_i$ checks the freshness of timestamp $T_7$. If valid, it computes $V_1^{\prime }=V_2\oplus S_1^{\prime }$ and verifies whether $Aut{h}_4\stackrel{?}{=}h(V_1^{\prime } \Vert V_4 \Vert RI{D}_j \Vert RI{D}_{j+1} \Vert T_7)$. If the equation holds, the vehicle computes $S_3^{\prime }=h(RI{D}_{j+1} \Vert V_1^{\prime } \Vert X_{j+1})$, recovers $V_3^{\prime }=V_4\oplus S_3^{\prime }$, and establishes the new session key as $S{K}_{i,j+1}=h(S_3^{\prime } \Vert V_3^{\prime } \Vert RI{D}_{j+1})$. For the next subsequent authentication, it further computes $X_3^{\prime }=h(T_5 \Vert V_3^{\prime })$, $X_4^{\prime }=h(T_7 \Vert V_3^{\prime })$, selects a fresh random value $d_3$, derives a new masking key $m{k}_i^{\left(2\right)}=h(k_i \Vert d_3)$, and masks $S_3^{\prime }$ as $S_4=m{k}_i^{\left(2\right)}\oplus S_3^{\prime }$. Finally, it stores $(X_3^{\prime },X_4^{\prime },S_4,V_4,d_3,S{K}_{i,j+1})$ for the next handover.

By iteratively applying the above procedure, the vehicle can complete subsequent authentication with later RSUs without invoking ECC operations. Therefore, the subsequent authentication phase only requires lightweight hash and XOR computations, which makes the proposed scheme suitable for high-density and high-mobility VANET environments.

3.4. Vehicle Pseudonym Update, Traceability, and Revocation

The purpose of this part is to decouple external anonymity from authority-side accountability. The vehicle updates its pseudonym to reduce linkability to external observers, while the TA can still recover the real identity of a misbehaving vehicle through the tracing anchor $C_i$ when a valid tracing value is reported by an RSU. To enhance privacy protection, a vehicle periodically updates its pseudonym. Specifically, $V_i$ randomly selects a new pseudonym $PI{D}_i^{new}$ and computes the corresponding tracing-related value as $T{R}_i^{new}=h(PI{D}_i^{new} \Vert C_i)$, where $C_i$ is the tracing anchor issued by the TA during registration. Since $PI{D}_i^{new}$ is randomly generated and $C_i$ is not disclosed to external entities, different pseudonyms of the same vehicle cannot be directly linked by ordinary observers.

When malicious behavior is detected, the corresponding RSU reports $(PI{D}_i^{new},T{R}_i^{new})$ to the TA through the secure backend channel. The TA then searches its revocation database, which stores tuples $(VI{D}_i,C_i)$ for all registered vehicles, and computes $T{R}_i^{*}=h(PI{D}_i^{new} \Vert C_i)$ for each candidate entry. If a match $T{R}_i^{*}=T{R}_i^{new}$ is found, the TA identifies the real identity $VI{D}_i$ of the malicious vehicle. After identification, the TA adds the corresponding identity to the revocation list and distributes the updated revocation information to RSUs. A revoked vehicle is rejected in subsequent initial authentication attempts, and any forwarding state associated with it is invalidated during subsequent authentication.

4. Security Analysis

4.1. Formal Security Proof

We provide a formal security analysis of the proposed authentication protocol under the Real-Or-Random (ROR) model. Let $\mathcal{A}$ be a probabilistic polynomial-time adversary aiming to compromise the semantic security of the session key established between a vehicle $V_i$ and an RSU $R_j$. The proof is conducted under the Dolev–Yao threat model introduced previously, together with the following assumptions: the TA is fully trusted, the secure backend channels among the TA and RSUs are not compromised, the hash function is modeled as a random oracle, and the underlying PUF primitive cannot be cloned or perfectly emulated by a polynomial-time adversary. The security of the protocol further relies on the hardness of the elliptic curve discrete logarithm problem (ECDLP).

The adversary $\mathcal{A}$ is allowed to issue the following queries.

Execute$(V_i,R_j)$: This query models passive eavesdropping and returns all messages exchanged during an honest protocol execution.

Send$(\mathsf{\Pi },m)$: This query models an active attack, where $\mathcal{A}$ sends a forged or modified message m to an oracle instance $\mathsf{\Pi }$. If the message is valid, the corresponding protocol response is returned.

Corrupt$\left(V_i\right)$/Corrupt$\left(R_j\right)$: This query models the compromise of ordinary stored information in the vehicle or RSU. It returns the contents of local storage but does not allow $\mathcal{A}$ to clone or perfectly emulate the underlying PUF primitive. Therefore, a corrupted RSU in this model cannot reconstruct PUF-protected RSU-side secrets or generate valid forwarded authentication states without the corresponding PUF-derived value.

Reveal$(V_i,R_j)$: This query returns the session key held by an accepted session between $V_i$ and $R_j$.

Test$(V_i,R_j)$: This query can be issued only once to a fresh accepted session. It returns either the real session key or a random value of the same length according to a hidden bit b.

A session is said to be fresh if neither the session itself nor its partner session has been queried by Reveal and if the adversary has not obtained sufficient secret information through Corrupt queries to trivially reconstruct the session key. Confirmed. We have checked the italics throughout the manuscript. The italics in terms such as “Corrupt” are retained because they denote oracle/query names in the security model. The italic formatting is used consistently and is necessary for technical clarity.

Theorem 1.

Under the ECDLP assumption, the collision resistance of the hash function, and the unclonability of the PUF primitive, the advantage of any probabilistic polynomial-time adversary $\mathcal{A}$ in distinguishing the established session key of the initial authentication phase from a random value is negligible. More precisely, the adversary’s advantage is bounded by

$$Ad{v}_{\mathcal{A}}^{\mathrm{init}}\le {\displaystyle \frac{q_h^2}{2^{l_h}}}+{\displaystyle \frac{{(q_s+q_e)}^2}{n}}+q_{c}Ad{v}_{\mathcal{A}}^{\mathrm{PUF}}+2Ad{v}_{\mathcal{A}}^{\mathrm{ECDLP}},$$

(1)

where $q_h$, $q_s$, $q_e$, and $q_c$ denote the numbers of hash, active message-transmission, passive eavesdropping, and corruption queries, respectively, $l_h$ is the bit-length of the hash output, and n is the order of the elliptic curve group.

Proof. 

To prove the theorem, we define a sequence of games, from $Gam{e}_0$ to $Gam{e}_4$, to analyze the advantage of $\mathcal{A}$ in the test-session experiment. Let $Wi{n}_i$ denote the event that $\mathcal{A}$ correctly guesses the hidden bit b in $Gam{e}_i$. Then, the adversary’s advantage in the real attack game is

$$Ad{v}_{\mathcal{A}}^{\mathrm{init}}=\left|2\mathrm{Pr}\left[Wi{n}_0\right]-1\right|.$$

(2)

${\mathit{Game}}_{\mathbf{0}}$. This is the real attack game in the ROR model, corresponding to an actual execution of the initial authentication and key agreement protocol.

${\mathit{Game}}_{\mathbf{1}}$. In this game, $\mathcal{A}$ is restricted to passive eavesdropping through Execute queries. From the transmitted messages, $\mathcal{A}$ can obtain $(T_1,Aut{h}_1,D_i,G_i,E_1,E_2,F_1,T{R}_i)$ and $(A_1,V_2,T_3,Aut{h}_2)$ but cannot derive the hidden values $d_i$, $a_1$, $a_2$, and $Z_i$ or the pseudonym-dependent internal state required for session key derivation. Therefore, passive observation alone does not increase the adversary’s advantage, and we have

$$\mathrm{Pr}\left[Wi{n}_1\right]=\mathrm{Pr}\left[Wi{n}_0\right].$$

(3)

${\mathit{Game}}_{\mathbf{2}}$. This game captures hash collisions and transcript collisions. Since the hash function is modeled as a random oracle, the probability of hash collisions is bounded by the birthday bound. In addition, the protocol transcripts contain fresh random values uniformly chosen from ${\mathbb{Z}}_n^{*}$, where n is the order of the elliptic curve group. Hence, the probability that $\mathcal{A}$ succeeds by producing a valid colliding hash value or transcript is bounded by

$$\left|\mathrm{Pr}\left[Wi{n}_2\right]-\mathrm{Pr}\left[Wi{n}_1\right]\right|\le {\displaystyle \frac{q_h^2}{2^{l_h+1}}}+{\displaystyle \frac{{(q_s+q_e)}^2}{2n}}.$$

(4)

${\mathit{Game}}_{\mathbf{3}}$. In this game, $\mathcal{A}$ is additionally allowed to issue Corrupt queries against vehicles and RSUs. Although such queries reveal ordinary stored information, the critical secrets protected by the PUF mechanism, such as the recovered value $Z_i$ and the RSU private key $x_j$, cannot be obtained unless the underlying PUF primitive is compromised. Therefore, the advantage gained in this game is bounded by the success probability of breaking the PUF primitive, namely,

$$\left|\mathrm{Pr}\left[Wi{n}_3\right]-\mathrm{Pr}\left[Wi{n}_2\right]\right|\le q_{c}Ad{v}_{\mathcal{A}}^{\mathrm{PUF}}.$$

(5)

${\mathit{Game}}_{\mathbf{4}}$. In this game, we consider the adversary’s attempt to distinguish the session key from a random value. In the proposed protocol, the initial session key is derived from the hidden shared value $A_2=a_1{D}_i=d_i{A}_1$ and the internal state $V_1=h(S_1\oplus a_2)$, where the adversary does not know the vehicle’s ephemeral secret $d_i$ or the RSU randomness $(a_1,a_2)$. After excluding the possibility of PUF compromise in $Gam{e}_3$, recovering the remaining ECC-dependent secret from the public transcript is at least as hard as solving the ECDLP on the elliptic curve group. Thus,

$$\left|\mathrm{Pr}\left[Wi{n}_4\right]-\mathrm{Pr}\left[Wi{n}_3\right]\right|\le 2Ad{v}_{\mathcal{A}}^{\mathrm{ECDLP}}.$$

(6)

In the final game, the session key is replaced by an independent random value. Hence,

$$\mathrm{Pr}\left[Wi{n}_4\right]={\displaystyle \frac{1}{2}}.$$

(7)

Combining (3)–(7), we obtain

$$Ad{v}_{\mathcal{A}}^{\mathrm{init}}=\left|2\mathrm{Pr}\left[Wi{n}_0\right]-1\right|\le {\displaystyle \frac{q_h^2}{2^{l_h}}}+{\displaystyle \frac{{(q_s+q_e)}^2}{n}}+q_{c}Ad{v}_{\mathcal{A}}^{\mathrm{PUF}}+2Ad{v}_{\mathcal{A}}^{\mathrm{ECDLP}}.$$

(8)

Therefore, the adversary’s advantage is negligible, and the initial authentication phase is secure. □

Theorem 2.

Under the collision resistance of the hash function and the unclonability of the PUF primitive, the advantage of any probabilistic polynomial-time adversary $\mathcal{A}$ in forging a valid subsequent authentication transcript or distinguishing the established session key of the subsequent authentication phase from a random value is negligible. More precisely, the adversary’s advantage is bounded by

$$Ad{v}_{\mathcal{A}}^{\mathrm{sub}}\le {\displaystyle \frac{q_h^2}{2^{l_h}}}+{\displaystyle \frac{{(q_s+q_e)}^2}{n}}+2q_{c}Ad{v}_{\mathcal{A}}^{\mathrm{PUF}},$$

(9)

where $q_h$, $q_s$, $q_e$, and $q_c$ denote the numbers of hash, active message-transmission, passive eavesdropping, and corruption queries, respectively, $l_h$ is the bit-length of the hash output, and n is the order of the elliptic curve group.

Proof. 

To prove the theorem, we define a sequence of games, from $Gam{e}_0$ to $Gam{e}_4$, to analyze the advantage of $\mathcal{A}$ in the test-session experiment for the subsequent authentication phase. Let $Wi{n}_i$ denote the event that $\mathcal{A}$ correctly guesses the hidden bit b in $Gam{e}_i$. Then, the adversary’s advantage in the real attack game is

$$Ad{v}_{\mathcal{A}}^{\mathrm{sub}}=\left|2\mathrm{Pr}\left[Wi{n}_0\right]-1\right|.$$

(10)

${\mathit{Game}}_{\mathbf{0}}$. This is the real attack game in the ROR model, corresponding to an actual execution of the subsequent authentication protocol.

${\mathit{Game}}_{\mathbf{1}}$. In this game, $\mathcal{A}$ is restricted to passive eavesdropping through Execute queries. From the transmitted messages, $\mathcal{A}$ can obtain $(PI{D}_i^{new},T{R}_i^{new},X_1^{\prime },E_3,T_5,E_4)$ and $(Aut{h}_4,V_4,T_7)$ but cannot derive the hidden values $S_1^{\prime }$, $a_2^{\prime }$, and $a_4$ or the protected forwarding state required for generating a valid subsequent session key. Therefore, passive observation alone does not increase the adversary’s advantage, and we have

$$\mathrm{Pr}\left[Wi{n}_6\right]=\mathrm{Pr}\left[Wi{n}_5\right].$$

(11)

${\mathit{Game}}_{\mathbf{2}}$. This game captures hash collisions and transcript collisions. Since the hash function is modeled as a random oracle, the probability of hash collisions is bounded by the birthday bound. In addition, the protocol transcripts contain fresh random values uniformly chosen from ${\mathbb{Z}}_n^{*}$, where n is the order of the elliptic curve group. Hence, the probability that $\mathcal{A}$ succeeds by producing a valid colliding hash value or transcript is bounded by

$$\left|Wi{n}_7]-\mathrm{Pr}\left[Wi{n}_6\right]\right|\le {\displaystyle \frac{q_h^2}{2^{l_h+1}}}+{\displaystyle \frac{{(q_s+q_e)}^2}{2n}}.$$

(12)

${\mathit{Game}}_{\mathbf{3}}$. In this game, $\mathcal{A}$ is additionally allowed to issue Corrupt queries against vehicles and RSUs. Although such queries reveal ordinary stored information, the critical values required in subsequent authentication remain protected by the PUF mechanism. In particular, recovering the valid vehicle-side state from $S_2$ requires the secret $k_i$, while recovering the RSU-side masked value $a_2^{\prime }$ from $a_3$ requires the secret $k_{j+1}$. Therefore, the advantage gained in this game is bounded by the probability of compromising the underlying PUF primitive on either side, namely,

$$\left|\mathrm{Pr}\left[Wi{n}_8\right]-\mathrm{Pr}\left[Wi{n}_7\right]\right|\le 2q_{c}Ad{v}_{\mathcal{A}}^{\mathrm{PUF}}.$$

(13)

${\mathit{Game}}_{\mathbf{4}}$. In this game, we consider the adversary’s attempt to forge a valid subsequent authentication transcript or distinguish the session key from a random value. To succeed, $\mathcal{A}$ must construct a valid tuple $(X_1^{\prime },E_3,T_5,E_4)$ and pass the verification of $Aut{h}_3$ or equivalently recover the hidden forwarding state generated in the previous successful authentication. Without the legitimate values $S_1^{\prime }$ and $a_2^{\prime }$, which are both protected through the PUF-based masking mechanism, the adversary cannot generate a valid subsequent authentication transcript except with negligible probability. Therefore, once the events considered in the previous games are excluded, the session key is computationally indistinguishable from a random value, Therefore, we have

$$\mathrm{Pr}\left[Wi{n}_9\right]={\displaystyle \frac{1}{2}}.$$

(14)

Combining (11)–(14), we obtain

$$Ad{v}_{\mathcal{A}}^{\mathrm{sub}}=\left|2\mathrm{Pr}\left[Wi{n}_5\right]-1\right|\le {\displaystyle \frac{q_h^2}{2^{l_h}}}+{\displaystyle \frac{{(q_s+q_e)}^2}{n}}+2q_{c}Ad{v}_{\mathcal{A}}^{\mathrm{PUF}}.$$

(15)

Therefore, the adversary’s advantage is negligible, and the subsequent authentication phase is secure. □

4.2. Informal Security Analysis

1. Mutual Authentication. The proposed protocol achieves mutual authentication in both the initial and subsequent authentication phases. In the initial authentication, the vehicle first verifies the legitimacy of the RSU credential through $A_{j}P\stackrel{?}{=}h(X_j \Vert RI{D}_j \Vert T_j)X_T+T_j$, while the RSU verifies the vehicle request through the consistency check $F_{1}P\stackrel{?}{=}{F}_2{X}_T+G_i+D_i$ and the authentication tag $Aut{h}_1$. The vehicle then authenticates the RSU by verifying $Aut{h}_2$. In the subsequent authentication phase, the neighboring RSU validates the follow-up request through $E_4$ and $Aut{h}_3$, while the vehicle authenticates the RSU response through $Aut{h}_4$. Therefore, both communicating parties can confirm each other’s legitimacy before establishing a session key.

2. Conditional Unlinkability. The proposed protocol provides conditional unlinkability by using dynamically updated pseudonyms. In each authentication session, the vehicle adopts a fresh pseudonym $PI{D}_i$ and computes the corresponding tracing-related value $T{R}_i=h(PI{D}_i \Vert C_i)$, where $C_i$ is known only to the TA and the legitimate vehicle. Since both the pseudonym and the transmitted authentication parameters are session-dependent, an external adversary observing public communications cannot correlate different sessions to the same vehicle without access to $C_i$. Since $C_i$ serves as a long-term tracing anchor to support conditional traceability and revocation, the disclosure of $C_i$, for example, caused by TA compromise, may enable cross-session linkage. Accordingly, the unlinkability achieved by the proposed protocol is conditional on the confidentiality of $C_i$ and should be interpreted as conditional unlinkability against external adversaries, rather than unconditional unlinkability.

3. Resistance to Vehicle Capture and Impersonation Attacks. The proposed protocol resists both vehicle capture and vehicle impersonation attacks by protecting critical vehicle-side secrets with the PUF mechanism. On the vehicle side, the OBU reconstructs the internal secret only through the PUF and fuzzy extractor, i.e., $F_i^{\prime }=\mathrm{PUF}\left(P_i\right)$ and $k_i\leftarrow F.Rp(F_i^{\prime },H{D}_i)$. The protected value $Z_i$ is recovered as $Z_i=k_i\oplus b_i$, while the subsequent authentication state is protected by $S_2=m{k}_i^{\left(1\right)}\oplus S_1^{\prime }$ and $S_4=m{k}_i^{\left(2\right)}\oplus S_3^{\prime }$. In the initial authentication, the RSU verifies the relation $F_{1}P\stackrel{?}{=}{F}_2{X}_T+G_i+D_i$, where $F_1=d_i+A_{i}h\left(PI{D}_i\right)$ and $A_i$ is generated using the TA’s secret key. Therefore, an adversary cannot impersonate a legitimate vehicle without either reconstructing the protected vehicle-side secret or forging the certified credential component issued by the TA.

4. Resistance to Replay Attacks. The protocol resists replay attacks by incorporating timestamps and integrity checks in every authentication stage. In the initial authentication, the freshness of $T_1$ and $T_3$ is verified before processing the corresponding messages, and message integrity is protected by $Aut{h}_1$ and $Aut{h}_2$. In the subsequent authentication, the freshness of $T_5$ and $T_7$ is checked, while the integrity of the request and response is ensured by $E_4$ and $Aut{h}_4$. Therefore, replayed messages are rejected once their timestamps are invalid or their authentication tags do not match the current session context.

5. Resistance to RSU Capture and Impersonation Attacks. The RSU private key is protected by the PUF-based mechanism as $B_j=k_j\oplus x_j$, where $k_j$ can only be reconstructed from a valid PUF response through the fuzzy extractor. Therefore, even if an attacker captures an RSU and obtains its ordinary stored data, it still cannot recover the private key $x_j$ without reproducing the underlying PUF behavior. In the initial authentication phase, the vehicle first verifies the RSU-issued credential before starting authentication and later checks the response message through $Aut{h}_2$, so a forged or compromised RSU cannot successfully impersonate a legitimate infrastructure node. This protection also extends to the subsequent authentication phase. Although the forwarding state $\{a_2,Aut{h}_3,RI{D}_j,X_1,X_2\}$ is delivered to neighboring RSUs, a subsequent RSU must still rely on its own locally recovered secret, obtained through its embedded PUF and fuzzy extractor, to correctly derive the parameters required for follow-up authentication. Hence, merely intercepting or replaying the forwarded state is insufficient for an adversary to masquerade as a valid subsequent RSU. As a result, the proposed protocol resists both RSU capture attacks and RSU impersonation attacks in the initial and subsequent authentication phases. Without reconstructing the required PUF-protected secret, a captured prior RSU cannot generate a valid forwarded authentication state. If the forwarded state is forged, modified, or inconsistent, it cannot be correctly matched and used for subsequent authentication; thus, the receiving RSU will not accept it as a valid inherited state. Therefore, the proposed protocol provides RSU capture and impersonation resistance under the adopted PUF-based device-capture model.

6. Resistance to Man-in-the-Middle Attacks. The proposed scheme effectively resists man-in-the-middle attacks because both initial and subsequent authentications include mutual verification and integrity protection. In the initial authentication, the request is protected by $Aut{h}_1$ and the RSU response is protected by $Aut{h}_2$. In the subsequent authentication, the request integrity is checked by verifying $E_4$, and the RSU response is authenticated by $Aut{h}_4$. Since these tags are computed from fresh timestamps, hidden session-dependent values, and protected secrets, an intermediate attacker cannot modify or substitute messages without detection. Thus, the protocol prevents message tampering and session hijacking.

7. Anonymity, Conditional Traceability, and Revocation. The protocol preserves anonymity because the real identity $VI{D}_i$ is never transmitted over the public channel. Instead, each session uses the current pseudonym $PI{D}_i$ and the tracing-related value $T{R}_i=h(PI{D}_i \Vert C_i)$, where $C_i$ is hidden from ordinary entities. Thus, public messages do not reveal the relationship between the pseudonym and the real identity. When malicious behavior is detected, the RSU reports $(PI{D}_i,T{R}_i)$ to the TA, which searches the revocation database containing $(VI{D}_i,C_i)$ and identifies the corresponding real identity by matching $h(PI{D}_i \Vert C_i)$. After identification, the TA updates the revocation list and distributes revocation information to RSUs.

8. Session Key Security and Conditional Forward Secrecy. In the subsequent authentication phase, the new session key is established as $S{K}_{i,j+1}=h(S_3^{\prime } \Vert V_3^{\prime } \Vert RI{D}_{j+1})$, where $S_3^{\prime }=h(RI{D}_{j+1} \Vert V_1^{\prime } \Vert X_{j+1})$ and $V_3^{\prime }=V_4\oplus S_3^{\prime }$. These values depend on the valid state inherited from the previous successful authentication, including the forwarding values $(a_2,Aut{h}_3,RI{D}_j,X_1,X_2)$, the locally protected value $a_3=m{k}_{j+1}\oplus a_2$ stored by the neighboring RSU, the recovered values $S_1^{\prime }$ and $a_2^{\prime }$, and the fresh randomness $a_4$ generated by the neighboring RSU. Since $(a_2,Aut{h}_3,RI{D}_j,X_1,X_2)$ are delivered through secure backend channels, while $a_3$ and $S_2$ are protected by PUF-based local secret recovery mechanisms, an adversary observing only the public transcript cannot reconstruct past subsequent authentication credentials or derive the corresponding session keys. Therefore, the proposed protocol provides conditional forward secrecy under the adopted device-capture model. In the subsequent authentication phase, the exposure of the public transcript or the forwarded authentication state alone is insufficient to derive the session key, because the key derivation also depends on the vehicle-side reconstructed state, the RSU-side locally protected value, and the fresh randomness generated by the subsequent RSU. However, if the forwarded authentication state and the corresponding device-side protected secrets or local authentication states are simultaneously exposed, the security of subsequent session keys may be affected. Therefore, the forward-secrecy claim of the proposed protocol should be understood as conditional forward secrecy rather than unconditional full forward secrecy.

9. Fault Tolerance. Because practical PUF outputs may exhibit slight noise, the protocol employs a fuzzy extractor to ensure stable secret reconstruction. Therefore, minor variations in the raw PUF response do not cause authentication failure, which improves the robustness of the protocol in practical deployment.

10. Practical Security Discussion. Although the above analysis shows that the proposed protocol resists common attacks such as replay, impersonation, and man-in-the-middle attacks, practical VANET deployments may also face DoS attacks, desynchronization attacks, and PUF-related implementation threats.

For DoS attacks, an adversary may send forged initial authentication requests to $R_j$ or forged follow-up authentication requests to $R_{j+1}$. To reduce unnecessary processing, the RSU first checks timestamp freshness before performing further verification. In the initial phase, $R_j$ verifies $T_1$, the authentication value $Aut{h}_1$, and the credential consistency relation involving $F_1$, $F_2$, $D_i$, and $G_i$. In the subsequent authentication phase, $R_{j+1}$ first checks $T_5$ and uses $X_1^{\prime }$ as the state index to retrieve the stored tuple $(X_2,a_3,Aut{h}_3,RI{D}_j)$. If no valid state is found, or if the state has expired according to $\mathsf{\Delta }{T}_{\mathrm{store}}$, the request is rejected directly. Only after this lightweight lookup does $R_{j+1}$ continue to verify the hash-based values $E_4$ and $Aut{h}_3$. Therefore, forged or stale requests can be filtered by timestamp checking, state lookup, state expiration, and hash-based integrity verification. In addition, the retention threshold $\mathsf{\Delta }{T}_{\mathrm{store}}$ limits the lifetime of stored follow-up states, which helps reduce the risk of RSU-side storage exhaustion caused by stale or accumulated states. Nevertheless, large-scale flooding attacks cannot be completely eliminated by the authentication protocol alone and should be further handled by rate limiting, abnormal request filtering, storage quota control, and RSU-side cache management.

Desynchronization attacks may occur if the authentication state forwarded from $R_j$ to $R_{j+1}$ is delayed, lost, replayed, modified, or inconsistent with the vehicle-side state. In the proposed protocol, the vehicle stores the follow-up state $(X_1^{\prime },X_2^{\prime },S_2,V_2,d_2,S{K}_{ij})$, while $R_{j+1}$ stores the forwarded state $(X_1,X_2,a_3,Aut{h}_3,RI{D}_j)$. During subsequent authentication, the vehicle reconstructs its local state using the PUF-derived secret $k_i$, while $R_{j+1}$ reconstructs the RSU-side state using $k_{j+1}$; for example, $S_2=h(k_i \Vert d_2)\oplus S_1^{\prime }$ and $a_3=h(k_{j+1} \Vert X_1 \Vert X_2 \Vert RI{D}_j)\oplus a_2$ bind the stored states to device-local secrets. If the vehicle-side state and the RSU-side forwarded state are inconsistent, or if the forwarded state is forged or modified during state propagation, the target RSU cannot correctly match or use the inherited state for subsequent authentication. Thus, the target RSU will not accept the invalid inherited state as a valid follow-up authentication context. If the required forwarded state is unavailable, expired, or cannot be correctly matched, the vehicle can fall back to the initial authentication phase, improving robustness under state loss, handover failure, invalid state forwarding, or delayed inter-RSU synchronization.

PUF modeling attacks and PUF reliability issues are also practical concerns. In the proposed protocol, the PUF is used for local secret reconstruction rather than as a public online challenge-response oracle. During registration, each vehicle and RSU derives a device-bound secret and helper data through the fuzzy extractor, e.g., $(k_i,H{D}_i)\leftarrow F.Gp\left(\mathrm{PUF}\left(P_i\right)\right)$ and $(k_j,H{D}_j)\leftarrow F.Gp\left(\mathrm{PUF}\left(P_j\right)\right)$. During authentication, the PUF is evaluated only locally to reproduce the device-bound secret, e.g., $k_i\leftarrow F.Rp(\mathrm{PUF}\left(P_i\right),H{D}_i)$ and $k_j\leftarrow F.Rp(\mathrm{PUF}\left(P_j\right),H{D}_j)$. Therefore, online authentication transcripts do not expose public challenge-response pairs in bulk, which reduces the exposure surface for PUF modeling attacks. This design does not require the PUF to be exposed as an externally accessible oracle with a large public CRP space; instead, it uses enrolled local challenges for device-bound key reconstruction. The reconstructed PUF-derived secrets are further used to protect local values such as $b_i$, $B_j$, $S_2$, and $a_3$, thereby binding critical authentication states to device-local PUF recovery. At the same time, practical PUF responses may be affected by noise, aging, and environmental variations. The fuzzy extractor is used to tolerate noisy responses and reproduce stable secrets from helper data. The helper data is not treated as a secret key, but it should not leak sufficient information to reconstruct the PUF-derived secret without the corresponding device response. However, the security of this protection still depends on the reliability, uniqueness, uniformity, and modeling resistance of the implemented PUF, as well as the leakage resilience of the helper data. Therefore, practical instantiation should adopt well-evaluated PUF designs, limit CRP exposure, and combine fuzzy extraction with secure storage and implementation-level protection.

11. STRIDE-Based Qualitative Risk Analysis. To further summarize the protocol-level risk coverage,

Table 3. STRIDE-based qualitative risk analysis of the proposed scheme.

Category	Potential Threat	Mitigation	Residual Risk
Spoofing	Vehicle or RSU impersonation.	Mutual authentication, credential verification, hash-based authenticators, and PUF-protected secrets.	Relies on credential and PUF protection.
Tampering	Modification of V2I messages or forwarded states.	Session-dependent authenticators and inherited-state verification reject modified or inconsistent states.	Disruption may trigger fallback.
Repudiation	Misbehavior denial under anonymous identities.	TA-side tracing information supports conditional traceability and revocation.	Relies on tracing-anchor protection.
Information disclosure	Exposure of identity, session state, or local secrets.	Dynamic pseudonyms, hash-protected values, session keys, and PUF/fuzzy-extractor-based secret recovery.	Conditional on tracing-anchor and local-state protection.
Denial of Service	Excessive requests or stale state queries.	Timestamps, lightweight lookup, state expiration, and early rejection of invalid requests.	Requires deployment-level rate limiting.
Elevation of privilege	Unauthorized follow-up access or state reuse.	Follow-up authentication requires valid inherited states, protected secrets, and fresh session-dependent values.	Depends on PUF protection and state expiration.

provides a STRIDE-based qualitative risk analysis of the proposed scheme. STRIDE is suitable for categorizing protocol-level threats in authentication systems, including spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. The analysis maps representative VANET threats to the corresponding defense mechanisms of the proposed scheme and clarifies the remaining deployment-dependent risks.

4.3. Comparative Security Analysis

To further evaluate the security characteristics of the proposed protocol, this subsection compares it with four representative VANET authentication schemes that are also used in the subsequent performance analysis, namely, Yang et al. [26], Dwivedi et al. [27], Xie et al. [28], and Kong and Tian [29]. The comparison results are summarized in

Table 4. Comparison of security features between the proposed protocol and related schemes.

Scheme	Conditional Unlinkability	Replay Resistance	Capture Resistance	Traceability/ Revocation	Conditional Forward Secrecy	Subsequent Authentication	PUF-Based Protection	Fault Tolerance
Yang et al. [26]	✓	✕	✕	✕	✕	✓	✕	✕
Dwivedi et al. [27]	✓	✕	✓	✕	✓	✓	✕	✕
Xie et al. [28]	✓	✓	✓	✓	✓	✕	✓	✕
Kong and Tian [29]	✓	✓	✕	✓	✓	✓	✕	✕
Ours	✓	✓	✓	✓	✓	✓	✓	✓

Note: ✓ indicates that the feature is supported, whereas ✕ indicates that the feature is not supported.

, where both conventional security properties and protocol-specific protection mechanisms are taken into account.

As shown in Table 4, the selected schemes emphasize different design objectives. Yang et al. [26] distinguishes between initial authentication and subsequent authentication, thereby reducing the overhead of repeated full authentication in high-mobility environments. Dwivedi et al. [27] focuses on blockchain-assisted handover authentication and secure session-key agreement across vehicular domains. Xie et al. [28] provides a relatively comprehensive design that integrates anonymous authentication, malicious-vehicle tracing, and PUF-based protection. Kong and Tian [29] emphasizes anonymous and efficient handover authentication with temporary identity update and revocation support. In comparison, the proposed protocol simultaneously supports conditional unlinkability, replay resistance, capture resistance, traceability-related handling, conditional forward secrecy, subsequent authentication, PUF-based protection, and fault tolerance. Compared with the selected related schemes, the proposed protocol achieves a more complete integration of state-assisted multi-RSU access, lightweight subsequent authentication, privacy preservation, and hardware-assisted security protection.

5. Performance Analysis

5.1. Computation Overhead Analysis

To evaluate the computational efficiency of the proposed protocol, this subsection compares its authentication cost with those of representative related schemes, including Yang et al. [26], Dwivedi et al. [27], Xie et al. [28], and Kong and Tian [29]. The comparison focuses on the online cryptographic operations required during the initial authentication phase and the subsequent or handover authentication phase. The computational overhead is evaluated based on the execution time of dominant cryptographic operations. Since all compared schemes mainly rely on ECC operations and hash functions during authentication, these operations are used as the dominant cost factors in the computational comparison. The execution times of ECC scalar multiplication and ECC point addition were measured using the MIRACL cryptographic library on a personal computer equipped with Windows 10, an Intel i5-7400 CPU running at 3.0 GHz, and 8 GB RAM. Each ECC operation was repeated 500 times, and the average execution time was adopted as the benchmark value. Let $T_{sme}$, $T_{ae}$, and $T_h$ denote the execution time of one elliptic curve scalar multiplication, one elliptic curve point addition, and one hash operation, respectively. Accordingly, we set $T_{sme}=2.331$ ms and $T_{ae}=0.012$ ms. Since the subsequent authentication phase of the proposed protocol is hash-dominant, $T_h$ is assigned a conservative non-negligible value of 0.1 ms rather than being ignored, so as to avoid underestimating the cumulative cost of hash operations. Lightweight operations such as XOR, concatenation, and modular addition are ignored due to their negligible cost compared with elliptic-curve operations.

The latency functions used for the computational-overhead comparison are derived by summing the dominant online cryptographic operations performed by the entities involved in the corresponding authentication phase, according to the computational-cost analyses and protocol procedures reported in the original papers [26,27,28,29]. Specifically, the initial-authentication cost represents the total dominant operations required to complete one full authentication and key-agreement execution, including both vehicle-side and RSU-side computations. For schemes that explicitly define a subsequent or handover authentication phase, the operations of that phase are counted as the subsequent-authentication cost. For schemes without a dedicated lightweight subsequent-authentication procedure comparable to the proposed follow-up authentication phase, the full-authentication cost reported in the original performance analysis is used as the subsequent-authentication cost when evaluating repeated RSU access. This unified operation-counting method ensures that all schemes are compared under the same benchmark setting. For Yang et al. [26], the operation counts are taken from Table 4 in Ref. [26], where the vehicle-side and RSU-side computation costs are separately reported for both initial and subsequent authentication. Therefore, we sum the vehicle-side and RSU-side costs and ignore lightweight XOR and concatenation operations, obtaining $10T_{sme}+2T_{ae}+10T_h$ for initial authentication and $4T_{sme}+12T_h$ for subsequent authentication. For Dwivedi et al. [27], the operation counts are taken from Section VI-B and Table IV in Ref. [27]. The intra-vehicular-domain authentication cost is used as the initial-authentication cost, while the inter-vehicular-domain handover authentication cost is used as the subsequent-authentication cost, corresponding to $6T_{sme}+12T_h$ and $12T_{sme}+21T_h$, respectively. For Xie et al. [28], the V2I authentication computation cost is taken from Table III in Ref. [28], which reports the single-authentication computational overhead. Since that scheme does not define a separate lightweight subsequent-authentication phase comparable to the proposed follow-up authentication phase, the same V2I authentication cost, $10T_{sme}+9T_h$, is used for both initial and subsequent authentication in the repeated-RSU-access comparison. For Kong and Tian [29], the initial and handover costs are directly obtained from Section 6.1 and Table 9 in Ref. [29], corresponding to $16T_{sme}+13T_h$ and $4T_{sme}+9T_h$.

Table 5. Comparison of computational overhead.

Scheme	Initial Authentication	Subsequent Authentication
Yang et al. [26]	$10T_{sme}+2T_{ae}+10T_h$$(24.334 \mathrm{ms})$	$4T_{sme}+12T_h$$(10.524 \mathrm{ms})$
Dwivedi et al. [27]	$12T_h+6T_{sme}$$(15.186 \mathrm{ms})$	$21T_h+12T_{sme}$$(30.072 \mathrm{ms})$
Xie et al. [28]	$9T_h+10T_{sme}$$(24.210 \mathrm{ms})$	$9T_h+10T_{sme}$$(24.210 \mathrm{ms})$
Kong and Tian [29]	$13T_h+16T_{sme}$$(38.596 \mathrm{ms})$	$9T_h+4T_{sme}$$(10.224 \mathrm{ms})$
Ours	$9T_{sme}+3T_{ae}+17T_h$$(22.715 \mathrm{ms})$	$19T_h$$(1.900 \mathrm{ms})$

presents the comparison of computational overhead. As shown in the table, the proposed protocol incurs an initial authentication cost of $9T_{sme}+3T_{ae}+17T_h$, corresponding to 22.715 ms under the adopted benchmark. This initial cost is not the lowest among the compared schemes because the initial phase performs full ECC-based authentication and session-key establishment, while also interacting with PUF-protected local secrets to establish a secure trust basis. Nevertheless, it remains comparable to representative ECC-based schemes and within an acceptable range for the first access phase. The main computational advantage of the proposed protocol appears in the subsequent authentication phase. Yang et al., Dwivedi et al., and Kong and Tian also distinguish between initial authentication and subsequent or handover authentication. However, their subsequent phases still rely on ECC-based operations for mutual authentication and key agreement, whereas the proposed protocol uses RSU-forwarded inherited states to complete these functions through lightweight hash-based operations. This design avoids repeated ECC-based mutual authentication during frequent multi-RSU access and thus significantly reduces subsequent-phase computational overhead. After the initial authentication is completed, the proposed scheme eliminates expensive elliptic-curve operations from the subsequent authentication process and only requires $19T_h$, corresponding to 1.900 ms. Compared with the representative schemes listed in Table 5, this yields the lowest computational overhead in the subsequent phase and thus significantly reduces repeated public-key computation during frequent RSU transitions.

To further illustrate the advantage of the proposed protocol in highly dynamic vehicular environments, Figure 7 compares the cumulative computation overhead as the number of traversed RSUs increases. For protocols with an explicit subsequent or handover authentication phase, the cumulative overhead is calculated as one initial authentication plus $(n-1)$ subsequent authentications. For schemes without a dedicated lightweight subsequent authentication phase, the full-authentication cost is repeatedly accumulated. As shown in Figure 7, the cumulative computation overhead of the proposed protocol grows much more slowly than those of the compared schemes as the number of traversed RSUs increases. Although its initial authentication cost is not always the lowest, the lightweight subsequent authentication makes its advantage increasingly evident in frequent handover scenarios. This result mainly stems from the two-phase design of the proposed protocol. The initial authentication phase completes full identity verification and fresh session establishment, whereas the subsequent authentication phase reuses securely inherited authentication state and only performs lightweight hash-based verification. As a result, repeated public-key computation during frequent RSU transitions is significantly reduced, making the proposed protocol more suitable for highly dynamic vehicular environments. Since the computation comparison focuses on vehicle-facing online cryptographic computation, the infrastructure-side state forwarding and synchronization overhead introduced by the proposed scheme is further discussed in Section 5.3.

5.2. Communication Overhead Analysis

To evaluate the communication efficiency of the proposed protocol, this subsection compares the total size of the messages exchanged during the online authentication process with those of the selected related schemes, including Yang et al. [26], Dwivedi et al. [27], Xie et al. [28], and Kong and Tian [29]. Similarly to the computation overhead analysis, only the online authentication phase is considered, while the one-time registration phase is excluded.

In the communication analysis, elliptic-curve operations are instantiated over the secp256r1 curve, and SHA-256 is adopted as the hash function. Accordingly, let $\left|G\right|$, $\left|h\right|$, $\left|ID\right|$, and $|T_s|$ denote the bit-lengths of an elliptic-curve point, a hash output, an identity-related short tag, and a timestamp, respectively. In this paper, we set $\left|G\right|=256$ bits, $\left|h\right|=256$ bits, $\left|ID\right|=32$ bits, and $|T_s|=32$ bits.

For protocols that explicitly define a handover-authentication phase, that phase is aligned with the subsequent authentication phase for comparison. For schemes that do not separately report a follow-up authentication procedure, the same full-authentication communication cost is used for both columns.

For the proposed protocol, the initial communication overhead is calculated as $\left(\right|T_s|+4|h|+2|G|+|ID\left|\right)+\left(\right|G|+2|h|+|T_s\left|\right),$ which corresponds to 2400 bits. The subsequent communication overhead is calculated as $\left(\right|ID|+3|h|+|T_s\left|\right)+\left(2\right|h|+|T_s\left|\right),$ which corresponds to 1376 bits.

Figure 8 presents the communication-overhead comparison. As shown in the figure, the proposed protocol does not achieve the minimum communication overhead in the initial authentication phase, since the first access still needs to convey sufficient information for full identity verification, freshness validation, and session-key establishment. However, its subsequent authentication overhead is significantly reduced and is lower than those of Yang et al., Dwivedi et al., and Xie et al. This indicates that the proposed protocol is more effective in reducing repeated message transmission during frequent RSU transitions.

This reduction mainly comes from the fact that the subsequent authentication phase no longer retransmits complete strong-authentication materials, but instead reuses inherited authentication state and only exchanges compact verification parameters required for freshness and legitimacy checking. Therefore, the proposed protocol is more suitable for highly dynamic vehicular environments, where vehicles frequently traverse adjacent RSU coverage areas.

5.3. RSU-Side Coordination Overhead Analysis

In the proposed protocol, the reduction in repeated computation and communication in the subsequent authentication phase is supported by inter-RSU state forwarding. After completing the initial authentication with $V_i$, the serving RSU $R_j$ forwards the authentication state $\{a_2,Aut{h}_3,RI{D}_j,X_1,X_2\}$ through a secure RSU-side channel, so that a subsequent RSU can validate the inherited authentication context without re-executing a full initial authentication procedure. Under the adopted message-length setting, where $\left|h\right|=256$ bits and $\left|ID\right|=32$ bits, the forwarding overhead of one authentication state is calculated as $|a_2|+|Aut{h}_3|+|RI{D}_j|+|X_1|+|X_2|=4|h|+|ID|=4\times 256+32=1056 \mathrm{bits}.$

The 1056-bit value represents the forwarding payload of one authentication state for one vehicle authentication context, rather than the total RSU-side forwarding or storage overhead in a practical deployment. Since the same forwarded state can be shared within the neighboring RSU scope, it does not need to be regenerated as different per-RSU state contents. However, the total RSU-side overhead is not constant in practical deployments. For multiple vehicles, if $N_v$ vehicles maintain follow-up authentication states within a retention window, the aggregate authentication-state payload can be estimated as $1056\times N_v$ bits within that window. A larger number of neighboring RSUs may also increase cache space, state indexing, synchronization management, and state-copy maintenance burden, although it does not change the size of each forwarded authentication state. This estimation only reflects the authentication-state payload and does not include implementation-dependent synchronization delay, lookup latency, retransmission cost, or cache-management overhead. Therefore, the proposed protocol provides bounded per-context forwarding overhead, rather than a constant total RSU-side overhead. It reduces repeated vehicle-facing computation and wireless V2I communication by introducing a small infrastructure-side state forwarding and maintenance burden, including state lookup, synchronization, and short-term state retention. This forwarding process is performed after the vehicle completes the initial authentication with the serving RSU and therefore does not consume vehicle-side computational resources or introduce additional vehicle-facing authentication messages during the current authentication exchange. Moreover, the use of the forwarded state is constrained by the PUF-assisted RSU-side secret recovery mechanism, since a subsequent RSU must still rely on its locally recovered PUF-derived secret to derive the parameters required for follow-up authentication. Thus, merely obtaining the forwarded state is insufficient for an adversary to complete follow-up authentication without the corresponding RSU-side protected secret.

If $p_f$ denotes the probability of state-inheritance failure caused by delayed synchronization, missing state, failed lookup, non-sequential mobility, handover failure, or state expiration, the expected cost of a follow-up access can be expressed as $(1-p_f)C_{\mathrm{follow}}+p_f{C}_{\mathrm{initial}}.$ Thus, the efficiency gain mainly holds under successful state inheritance. When no valid inherited state is available, the vehicle falls back to the initial authentication phase. Mobility uncertainty, synchronization failures, state lookup, cache maintenance, and revocation propagation therefore introduce deployment-dependent RSU-side management overhead.

5.4. Storage Overhead Analysis

In this subsection, we evaluate the vehicle-side storage overhead incurred by authentication. Specifically, both long-term authentication credentials and temporary state that must be retained by the vehicle to complete the current or next authentication procedure are taken into account. In the proposed protocol, the vehicle only needs to preserve six authentication-related state values to maintain continuity across RSU transitions. After the initial authentication, the retained state is $(X_1^{\prime },X_2^{\prime },S_2,V_2,d_2,S{K}_{ij})$, and after a successful follow-up authentication, it is updated to $(X_3^{\prime },X_4^{\prime },S_4,V_4,d_3,S{K}_{i,j+1})$. Following the parameter setting used in the communication overhead analysis, where an elliptic-curve point and a hash output are both represented with 256 bits, and identity-related short tags and timestamps are represented with 32 bits, the resulting vehicle-side storage overhead of the proposed protocol is 1536 bits, corresponding to six retained authentication-related state values.

As shown in

Table 6. Vehicle-side storage overhead comparison.

Scheme	Vehicle-Side Storage Overhead
Yang et al. [26]	1056 bits
Dwivedi et al. [27]	1312 bits
Xie et al. [28]	800 bits
Kong and Tian [29]	800 bits
Ours	1536 bits

, the vehicle-side storage overheads of the selected schemes are evaluated under the same parameter setting used in the communication overhead analysis. Xie et al. mainly retain vehicle-side authentication credentials together with a small amount of state information, resulting in relatively low storage overhead. Yang et al. require not only preloaded credentials but also identity- and session-related information to support subsequent authentication, leading to a moderately higher cost. Dwivedi et al. further retain both long-term vehicle-side authentication information and temporary state during authentication, which increases the storage requirement. Kong and Tian also rely on locally retained identity-related and handover-related authentication context, although the resulting vehicle-side storage remains relatively compact under the same parameter setting. Compared with the selected schemes, the proposed protocol introduces a moderate increase in vehicle-side storage overhead. This is mainly because it explicitly preserves inherited authentication state to support efficient follow-up authentication across frequent RSU transitions. Nevertheless, the retained state remains compact in absolute size and directly enables a substantial reduction in repeated computation and communication during handover. Therefore, the proposed protocol achieves a reasonable tradeoff between vehicle-side storage overhead and authentication efficiency in highly dynamic vehicular environments.

6. Conclusions

This paper proposes a state-assisted authentication protocol for lightweight multi-RSU access in vehicular ad hoc networks. By separating authentication into an initial phase and a subsequent phase, the proposed design enables secure access while significantly reducing repeated authentication overhead during frequent RSU transitions. The protocol integrates PUF-based device-side secret protection, secure inter-RSU state forwarding, and hash-based subsequent authentication to support mutual authentication, session-key establishment, and authentication continuity in highly dynamic vehicular environments.

Performance evaluation shows that, although the proposed protocol does not always achieve the minimum cost in the initial authentication phase, it significantly reduces the computation and communication overhead in subsequent authentication compared with representative schemes. Accordingly, the lightweight feature of the proposed protocol mainly refers to the subsequent authentication phase and repeated multi-RSU access, rather than to a single initial authentication execution. In addition, the inter-RSU forwarding payload remains fixed for each vehicle authentication context, while the vehicle-side storage remains compact. These results indicate that the proposed design is particularly suitable for scenarios in which vehicles frequently move across adjacent RSU coverage areas and require efficient continuous access.

Overall, the proposed protocol provides an efficient and secure authentication solution for continuous V2I access in high-mobility multi-RSU VANET environments. By reducing repeated full authentication during frequent RSU transitions, the proposed design helps maintain lightweight and secure vehicle-to-infrastructure communication while preserving mutual authentication, privacy protection, traceability, and session-key establishment. This makes the scheme suitable for dynamic vehicular networks where vehicles require continuous and efficient access across adjacent RSUs. For future large-scale V2X environments, continuous authentication mechanisms can be further extended to scenarios involving multiple RSUs, cross-domain infrastructures, and diverse service providers. Future work can also explore adaptive multi-RSU authentication frameworks that dynamically adjust security strength according to vehicle mobility, infrastructure load, and application requirements, so as to better balance lightweight authentication, privacy preservation, conditional accountability, and scalability.