Mutual V2I Multifactor Authentication Using PUFs in an Unsecure Multi-Hop Wi-Fi Environment

Abstract

Secure authentication in vehicular ad hoc networks (VANETs) remains a fundamental challenge due to their dynamic topology, susceptibility to attacks, and scalability constraints in multi-hop communication. Existing approaches based on elliptic curve cryptography (ECC), blockchain, and fog computing have achieved partial success but suffer from latency, resource overhead, and limited adaptability, leaving a gap for lightweight and hardware-rooted trust models. To address this, we propose a multi-hop mutual authentication protocol leveraging Physical Unclonable Functions (PUFs), which provide tamper-evident, device-specific responses for cryptographic key generation. Our design introduces a structured sequence of phases, including pre-deployment, registration, login, authentication, key establishment, and session maintenance, with optional multi-hop extension through relay vehicles. Unlike prior schemes, our protocol integrates fuzzy extractors for error tolerance, employs both inductive and game-based proofs for security guarantees, and maps BAN-logic reasoning to specific attack resistances, ensuring robustness against replay, impersonation, and man-in-the-middle attacks. The protocol achieves mutual trust between vehicles and RSUs while preserving anonymity via temporary identifiers and achieving forward secrecy through non-reused CRPs. Conceptual comparison with state-of-the-art PUF-based and non-PUF schemes highlights the potential for reduced latency, lower communication overhead, and improved scalability via cloud-assisted CRP lifecycle management, while pointing to the need for future empirical validation through simulation and prototyping. This work not only provides a secure and efficient solution for VANET authentication but also advances the field by offering the first integrated taxonomy-driven evaluation of PUF-enabled V2X protocols in multi-hop Wi-Fi environments.

1. Introduction

Intelligent transportation systems (ITS) are a direct product of advances in information systems and the Internet of Things (IoT). Smart vehicles and vehicle area networks (VANs) are now a reality [1,2,3]. Vehicle-to-vehicle (V2V) communication allows nearby vehicles to exchange relevant data. Vehicles also communicate with infrastructure such as traffic lights and signs via vehicle-to-infrastructure (V2I) and vehicle-to-everything (V2X) communication modes. This naturally demands securing these interactions ensuring data privacy, and authenticating communicating entities [4,5].

Public key protocols such as elliptic curve cryptography (ECC) and Rivest–Shamir–Adleman (RSA) are very powerful, but they are mainly used for data hiding and digital signatures. The secret key is never shared. On the other hand, the physical unclonable functions (PUFs) used here are used for simple symmetric encryption and are mainly used for mutual authentication and secure key management [6].

Both V2V, V2I and V2X utilize conventional vehicle security and authentication protocols to facilitate this secure exchange in data [7,8,9,10]. These protocols face the following challenges:

1.

The dynamic nature of the network topology results from the mobility of the vehicles and the need for handover and continually authenticating vehicles that move into the coverage area.

2.

Network scalability, where the number of vehicles and the extent of the coverage area vary from limited inside a municipality to very large for a highway. Handover of security certificates becomes necessary in the microscale of a city block, for example.

3.

Heterogeneity due to use several types of network infrastructure and manufacturers of vehicles.

4.

Identifying priorities and handling the different types of network traffic.

5.

Detecting malicious vehicles or the onset of attacks on the infrastructure and the vehicles themselves.

6.

Secret keys are typically stored in non-volatile random access memory (NVRAM), which can be attacked to extract the secret keys and duplicate them.

7.

Secret keys cannot be static since this opens the doors to several types of attacks. Dynamic session keys are costly unless vehicles are equipped with physical unclonable functions (PUFs) [11].

PUFs have been used earlier for authentication, but the protocols used were simple since the PUF was used only to authenticate the device to the challenger. It was not clear how the challenger knows the expected response. Furthermore, the device typically sends back the expected response to be verified by the challenger. This is a one-time password scheme (OTP) where this challenge-response pair cannot be used again. In our proposed protocol here, the same challenge-response pair can be used as often as desired since the response is never revealed to the challenger.

This PUF technology offers a novel approach for authenticating vehicles by infrastructure and also allows for authenticating the infrastructure by the vehicles themselves (as will be shown in the proposed protocol). Using PUFs also facilitates secure and dynamic session key exchange and immunity to tampering. PUFs harness the inherent physical variations in hardware during the manufacturing process to endow devices with unique identities, which can be pivotal in generating and distributing secure secret keys among vehicles in a network [11]. It is imperative in V2X to be equipped with robust security mechanisms that include PUFs in their design as a hardware-based security mechanism.

This manuscript introduces a novel framework for vehicle authentication in VANs, specifically designed to address the aforementioned limitations by incorporating PUFs and ensuring anonymity in vehicle authentication.

1.1. Contributions

The contributions of this work are summarized as follows:

1.

Using PUFs installed on each vehicle helps achieve mutual authentication between the vehicle and roadside unit (RSU), drones, etc.

2.

Proposal of secure, anonymous and lightweight mutual authentication and key exchange protocols. The proposed protocol does not require clock synchronization, which is needed for timestamp-based mutual authentication protocols.

3.

Proposal of a secure key exchange protocol between several vehicles in the same RSU coverage area to accomplish secure multi-hop packet store-and-forward Wi-Fi network.

4.

Incorporation of freshness and presence properties in the proposed protocols to enhance security and prevent several impersonation attacks through context awareness and transaction history.

5.

Evaluation of the proposed protocols using informal security analysis.

6.

Evaluation of the proposed protocols using formal security analysis.

1.2. Organization of the Paper

The remainder of this paper is structured as follows: Section 2 reviews related work in the field of vehicle authentication protocols, highlighting the gaps our study aims to fill. Section 3 details the proposed mutual authentication and key exchange protocols and mechanisms for ensuring anonymity and security. Section 4 presents the security analysis using informal as well as formal techniques. Section 5 summarizes the main features of the proposed multifactor V2I authentication protocol. Section 6 discusses the advantages of the proposed security protocols. Section 7 discusses some protocol limitations and future research directions.

The notations used in the proposed schemes are alphabetically presented in

Table 1. Notations and parameters used in the proposed authentication protocol.

Notation	Definition/Description
$V_i$	Vehicle node i equipped with an On-Board Unit (OBU).
R	Roadside unit (RSU) serving as a local infrastructure node.
C	Cloud Authority/Trusted Third Party responsible for CRP management.
$I{D}_i$	Permanent identity of vehicle i assigned by the authority.
$P{W}_i$	Password or secret credential of vehicle i.
$k_i$	Long-term secret key of vehicle i (shared with C).
$Cer{t}_R$	Short-lived digital certificate issued by C to RSU R.
$PUF(·)$	Physical Unclonable Function producing unique responses from challenges.
$CRP$	Challenge–Response Pair $(c_j,r_j)$ derived from a PUF.
$c_j$	PUF challenge j.
$r_j$	Ideal PUF response corresponding to $c_j$.
$r_j^{\prime }$	Noisy response generated in practice under environmental factors.
$helper\_data$	Public data enabling error correction of noisy PUF responses.
$FE(·)$	Fuzzy Extractor algorithm for reconstructing reliable keys from noisy PUFs.
$TI{D}_i$	Temporary Identifier for $V_i$ used to preserve anonymity.
$nonc{e}_v,nonc{e}_r$	Random nonces generated by vehicle $V_i$ and RSU R, respectively, for freshness.
$n_i$	Authentication token computed by $V_i$: $n_i=H(I{D}_i\Vert k_i\Vert P{W}_i\Vert nonc{e}_v)$.
$E_{p{k}_X}(·)$	Asymmetric encryption under the public key of entity X.
$H(·)$	Cryptographic one-way hash function (e.g., SHA-256).
$K_{V_i,R}$	Session key established between vehicle $V_i$ and RSU R.
$LoginReq$	Encrypted login request message from $V_i$ to R.
$AuthCheck$	Authentication request message sent from R to C.
$Resp$	Response from $V_i$ during PUF-based challenge–response authentication.

.

2. Related Works

Vehicular Ad Hoc Networks (VANETs) represent one of the most challenging environments for secure authentication due to their high mobility, dynamic topology, and stringent latency requirements. Over the past decade, a wide range of solutions have been proposed, which can broadly be classified into four paradigms: (i) conventional cryptography-based schemes, (ii) blockchain-based frameworks, (iii) fog/edge-assisted models, and (iv) hardware-assisted protocols using Physical Unclonable Functions (PUFs). In this section, we critically analyze each paradigm in terms of its motivation, mechanisms, and shortcomings before synthesizing the research gap that motivates our contribution. Our review adopts a systematic mapping approach [12,13], ensuring that we not only catalog prior work but also identify structural limitations across categories.

2.1. Cryptography-Based Protocols

Traditional VANET authentication mechanisms have primarily relied on public-key cryptography. Elliptic Curve Cryptography (ECC) [14] has been widely used because of its reduced key size and efficiency compared to RSA. Identity-Based Cryptography (IBC) [15] was introduced to eliminate certificate overhead, while group signature schemes [16] were designed to ensure conditional anonymity of vehicles with traceability for accountability.

While these schemes represent significant progress, several issues persist. First, they assume secure storage of long-term private keyswithin On-Board Units (OBUs), but real vehicles remain vulnerable to physical tampering. Compromised OBUs enable large-scale impersonation attacks, invalidating cryptographic guarantees. Second, certificate revocation is a major bottleneck: large Certificate Revocation Lists (CRLs) [17] must be distributed frequently, leading to bandwidth overhead. This is particularly critical in multi-hop Wi-Fi environments, where latency accumulates at each hop, often exceeding the 100 ms threshold mandated for safety-critical messages. Furthermore, most studies evaluate these approaches under idealized conditions rather than at an urban scale, meaning the true scalability of cryptography-based VANET authentication remains questionable.

2.2. Blockchain-Based Frameworks

To overcome centralized trust anchors, blockchain has been proposed as an alternative for vehicular identity and message verification [18,19]. By leveraging a tamper-evident distributed ledger, blockchain promises transparency, accountability, and resilience against single points of failure. Several models rely on RSUs or fog nodes as consensus participants, theoretically ensuring decentralized validation of vehicles.

However, the practicality of blockchain for real-time VANET security is limited. Consensus algorithms such as Proof-of-Work (PoW) and Proof-of-Stake (PoS) impose computational and time overheads on the order of seconds, which is incompatible with the millisecond-scale requirements of vehicular safety applications. Even consortium or PBFT-based blockchains suffer from excessive message complexity when scaled to thousands of participants. Moreover, the obligation to store and synchronize a continuously growing ledger is unrealistic for OBUs with limited resources. Consequently, blockchain approaches, while attractive for post-incident forensics or liability attribution, are fundamentally misaligned with the ultra-low latency demands of V2X authentication.

2.3. Fog and Edge-Assisted Protocols

The fog/edge paradigm [20,21] seeks to reduce end-to-end latency by moving authentication closer to vehicles. Fog nodes deployed at RSUs perform lightweight authentication and manage session keys locally, thereby alleviating the reliance on distant cloud servers. Several studies demonstrate that this approach reduces average authentication delay and improves throughput for time-sensitive vehicular communication.

Despite these advantages, fog-based approaches face multiple unresolved issues. First, they typically rely on static symmetric or asymmetric keys, making them vulnerable once a fog node is compromised. Unlike cloud infrastructures, fog nodes are geographically distributed and more susceptible to physical capture by adversaries. Second, their security guarantees are bounded by the trustworthiness of fog infrastructure, which may vary by operator and jurisdiction. Third, most performance studies evaluate only small-scale topologies with simplified channel assumptions, overlooking the complex dynamics of multi-hop Wi-Fi relays and high-density urban mobility. Finally, fog solutions fail to leverage hardware-level unclonability, which is vital for ensuring that compromised software does not lead to unrestricted impersonation.

2.4. PUF-Based Authentication Protocols

Physical Unclonable Functions (PUFs) [22,23] represent a promising alternative to key-storage-based models. PUFs exploit intrinsic manufacturing randomness to generate unique challenge–response pairs (CRPs), eliminating the need for permanently stored cryptographic keys. This property makes them highly resistant to invasive attacks, as no secret exists until the PUF is challenged.

PUFs have been integrated into vehicular protocols to provide lightweight authentication with minimal computational load. However, current PUF-based VANET schemes exhibit significant limitations. Many only enable unidirectional authentication, verifying vehicles to RSUs but not vice versa, leaving vehicles exposed to rogue RSUs. Most assume direct communication between vehicles and RSUs, neglecting the reality of multi-hop Wi-Fi forwarding where relay vehicles are necessary. Additionally, the scalability problem of CRP management remains unresolved: large fleets require millions of CRPs to be generated, distributed, and refreshed, which is impractical without centralized orchestration. Finally, PUF outputs are inherently noisy; without mechanisms such as fuzzy extractors or helper data [24], error rates can render authentication unreliable under environmental variations such as temperature or voltage changes.

2.5. Comparative Analysis and Research Gap

Taken together, prior works highlight the difficulty of balancing performance, scalability, and security in VANET authentication. Cryptographic schemes provide strong theoretical security but suffer from latency and revocation bottlenecks. Blockchain approaches deliver tamper resistance but introduce prohibitive consensus delays. Fog-assisted methods reduce latency but inherit vulnerabilities from their infrastructure. PUF-based schemes offer unclonability and lightweight computation but are restricted to unidirectional, single-hop contexts with unresolved scalability challenges.

Research Gap: To date, no existing approach simultaneously achieves the following: (i) bi-directional trust between vehicles and infrastructure, (ii) seamless multi-hop Wi-Fi forwarding, (iii) freshness and presence guarantees resistant to replay and desynchronization attacks, and (iv) scalable CRP lifecycle management integrated with cloud resources. Addressing this multi-dimensional gap requires rethinking how hardware trust primitives are combined with scalable architectures.

Table 2. Comparative feature matrix of authentication approaches, showing the relative strengths and weaknesses across latency, scalability, trust, and unclonability.

Approach	Latency	Scalability	Bi-Directional Trust	Unclonability	CRP Lifecycle Managment
Cryptography-Based	High	Poor	Yes	No	Not Supported
Blockchain-Based	High	Poor	Yes	No	Not Feasible
Fog/Edge-Assisted	Low	Moderate	Parital	No	Not Addressed
PUF-Based	Low	Poor	Unidirectional	Yes	Not Scalable
Proposed Work	Low	High	Yes	Yes	Full Support

provides a comparison matrix for the different authentication approaches, showing the relative strengths and weaknesses across latency, scalability, trust, and unclonability.

In the context of VANET authentication, high latency refers to delays exceeding roughly 100 ms, which would not meet the stringent requirements of safety-critical V2X applications [25]. Conversely, low latency implies end-to-end delays on the order of a few tens of milliseconds (e.g., <50 ms), suitable for real-time communication. A moderate latency rating lies between these extremes (approximately 50–100 ms). Similarly, we qualify scalability in terms of the number of vehicles an RSU or domain can handle. High scalability denotes support for on the order of hundreds of nodes (around > 500 vehicles per RSU) without significant performance degradation [26]. A poor scalability rating implies the scheme can only manage on the order of mere tens of vehicles (e.g., <50 per RSU) before encountering bottlenecks. Ratings like “moderate scalability” fall in between (handling a few dozen up to a few hundred vehicles). These threshold values are grounded in ranges commonly reported in VANET studies; for example, safety message latencies around 100 ms are considered low-latency requirements  [25], and recent high-density V2X experiments scale to 500-node networks as a stress test for authentication protocols [26]. By basing our qualitative terms on such established figures, Table 2’s comparative analysis is made more concrete and transparent. This ensures that descriptors like “high” or “low” latency, “good” or “poor” scalability, etc., are interpreted consistently against typical benchmarks in the literature, rather than as subjective labels.

Figure 1 provides a taxonomy of the different authentication approaches in VANETs. Cryptographic, blockchain, fog/edge, and PUF paradigms are contrasted with the proposed framework.

2.6. Our Contribution

This work advances the state of the art by proposing the first integrated PUF-based authentication framework that achieves the following:

1.

Provides bi-directional authentication, securing both vehicles and RSUs against impersonation.

2.

Natively supports multi-hop Wi-Fi forwarding, addressing the realities of vehicular connectivity.

3.

Incorporates freshness and presence guarantees using nonces, temporary identifiers, and inductive proofs.

4.

Introduces cloud-assisted CRP management to ensure scalability for large fleets.

3. Proposed Multihop Wi-Fi Authentication Scheme

Before discussing the proposed protocol, we provide a brief account of how a PUF is used to establish mutual authentication and a reliable key exchange mechanism through a helper data algorithm. The steps to use the PUF to enable the server to authenticate the client and exchange the same key are as follows 10:

1.

The server obtains the challenge/response of a certain PUF from the device manufacturere (CRP).

2.

The server selects a challenge c and its associated response r.

3.

The server generates the helper data w, which is similar to forward error correction coding:

$$w=\mathrm{FEC}\left(r\right).$$

4.

The server generates a hash using r to obtain a one-time password and a secret key

$$[h,k]=\mathrm{H}(r,w).$$

5.

The server sends c and w to the client. Note that this does not reveal any secret information.

6.

The client uses its PUF to obtain a noisy response $r^{\prime }=\mathrm{PUF}\left(c\right)$.

7.

The client removes the noise from the response using received w,

$$r^{″}=\mathrm{FEC}(r^{\prime },w)$$

8.

The client uses the noise-free response to generate the secret key and has a pair

$$[h^{\prime },k^{\prime }]=\mathrm{H}(r^{″},w).$$

9.

The client sends $h^{″}$ to server to complete the authentication and key exchange.

10.

The server compares its h with the received $h^{″}$. If both match, then authentication and secret key exchange are deemed successful.

We discuss here our proposed secure and anonymous vehicle authentication protocols. The protocols use PUFs, context awareness and transaction history to achieve higher security levels.

Our mutual authentication schemes has the following phases:

1.

Pre-deployment phase;

2.

Registration phase;

3.

Vehicle login phase;

4.

Multi-hop mutual authentication phase;

5.

Multi-hop communication phase.

Figure 2 shows the system under consideration.

The main entities are certification authority (C), roadside units (RSU or R) and smart vehicles ($V_i$) containing Wi-Fi gateways and attached IoT sensor and actuator devices. Each vehicle is registered at the certification authority using the fabrication information supplied by the vehicle manufacturer. The vehicle gateway is responsible for establishing and monitoring communication between the vehicle and other vehicles or RSUs.

Wi-Fi communication is established by roadside units (RSU). The RSU is able to contact certification authorities to obtain information about vehicles in its coverage area. The figure shows at least one vehicle can directly connect to the RSU. However, most of the vehicles in the given geographical area are not in direct contact with the RSU.

To reach the RSU, these vehicles must depend on collaborative multi-hop communication as shown.

We state some basic assumptions for our analysis as follows:

1.

A coverage area is one that is served by an infrastructure device, e.g., an RSU, that can be considered a root-of-trust (RoT).

2.

Not all vehicles have direct access to the infrastructure and must rely on a cooperative multi-hop message store-and-forward strategy.

3.

Not all vehicles are trusted since some malicious vehicles might be present in the system

4.

All trusted vehicles must have a PUF, or an equivalent synthetic $\left\{\mathit{CRP}\right\}$ set, to facilitate creation of a unique ID, generation of a secret key exchange, and mutual authentication between vehicles and the RSU.

3.1. Pre-Deployment Phase

The two main players here are the roadside unit (RSU or R) and vehicles (V).

3.1.1. Roadside Unit (RSU or R)

The roadside units are considered a root-of-trust (RoT) and are responsible for establishing secure communication and mutual authentication with the certification authority (C). A symmetric secret key $k_{rc}$ is established between R and the certification authority C. Communication between R and C could be direct or via an RSU hierarchy to reduce and enhance the cost of communication.

3.1.2. Pre-Deployment for Vehicles (V)

The pre-deployment phase is conducted by the vehicle manufacturer, or more specifically the PUF fabricator, prior to selling the vehicle. A vehicle $V_i$ is given the following three unique parameters:

1.

Identity (${\mathit{ID}}_i$);

2.

Password (${\mathit{PWD}}_i$);

3.

Symmetric key $k_i$.

In addition, a vehicle could be supplied with a PUF that can generate its unique set of challenge/response pair set ($\left\{CRP\right\}$). If a PUF is not chosen, then the manufacturer assigns a unique secret key k to be used between the roadside unit and the vehicle.

The vehicle manufacturer supplies the vehicle parameters $({\mathit{ID}}_i,{\mathit{PWD}}_i,k_i,{\left\{CRP\right\}}_i$) to the certification authority C to be used for the login and authentication phases of vehicles. Listing 1 summarizes the steps needed to construct the PUF challenge response set $\left\{\mathit{CRP}\right\}$ to complete the vehicle pre-deployment phase.

Listing 1. Vehicle pre-deployment phase.
1	$\mathit{Fab}$	:	${\mathit{ID}}_i=\mathrm{Assign}\_\mathrm{ID}\left(V_i\right)$
2		:	${\left\{\mathit{PWD}\right\}}_i=\mathrm{Assign}\_\mathrm{PWD}\left(V_i\right)$
3		:	$k_i=\mathrm{Assign}\_\mathrm{key}\left(V_i\right)$
4		:	${\left\{\mathit{CRP}\right\}}_i=\varphi$	% Initialize $\left\{\mathit{CRP}\right\}$
5		:	FOR  $j=1:n$  DO
6		:	$r_j={\mathrm{PUF}}_j\left(c_j\right)$
7		:	${\left\{\mathit{CRP}\right\}}_i{=\mathrm{Concatenate}(\left\{\mathit{CRP}\right\}}_{i-1}\left|\right|c_j{r}_j)$	% Build CRP
8		:	END FOR
9	$\mathit{Fab}\to C$	:	$\mathit{PKI}\left({\mathit{ID}}_i\left|\right|{\mathit{PWD}}_i\left|\right|k_i\left|\right|{\left\{\mathit{CRP}\right\}}_i\right)$	Public key communication

The protocol in Listing 1 allows the device fabricator (Fab) to characterize the PUF after its fabrication to extract its challenge-response pair set $\left\{\mathit{CRP}\right\}$. Further, the device fabricator shares this set with a trusted certification authority (C) for sharing with other trusted entities.

3.2. Registration Phase

The main goal of the registration phase is to have the main players exchange public key infrastructure (PKI) credentials as follows:

1.

C will share its public key $K_c$ with the RSUs that register with it;

2.

$RSU$ will share its public key $K_r$ with C;

3.

$RSU$ will keep broadcasting a HELLO($K_r$) message over its coverage area so that incoming vehicles are aware of the RSU public key to use when they desire to login, as discussed in Section 3.3.

3.3. Vehicle Login Phase

Listing 2 shows the vehicle login to an RSU. Login starts by the vehicle contacting the RSU using the latter’s public key $k_r$. Using public key infrastructure (PKI) ensures the vehicle’s anonymity. The vehicle supplies its ID and a secret session parameter ${\varphi }_i$.

Listing 2. Vehicle login to a roadside unit phase.
1	$V_i$	:	$n_i=h({\mathit{ID}}_i\left|\right|{\mathit{PWD}}_i\left|\right|k_i)$	% Generate a secret parameter
2	$V_i\to R$	:	$\left({\mathrm{ID}}_i\left|\right|n_i\right)$	% Request registration
3	$R\to C$	:	$E_{k_c}\left({\mathit{ID}}_r\left|\right|{\mathrm{ID}}_i\right)$	% Request $V_i$ parameters
4	$C\to R$	:	$E_{k_r}\left({\left\{\mathit{CRP}\right\}}_i\right)$
5	R	:	$n_i^{\prime }=h({\mathit{ID}}_i\left|\right|{\mathit{PWD}}_i\left|\right|k_i)$
6	R	:	IF  $n_i=n_i^{\prime }$
7		:	Admit $V_i$	% $V_i$ joins R’s coverage area
8		:	END IF

• Step 1: The vehicle prepares a unique hash (${\varphi }_i$) for multifactor authentication, ensuring freshness and presence.
• Step 2: The vehicle sends an encrypted message to R using the RSU public key that it obtained from R’s Hello($k_r$) broadcast message.
• Step 3: The RSU encrypts a message to request vehicle $V_i$ credentials from C using C’s public key $k_c$.
• Step 4: C sends vehicle $V_i$ credentials to R using RSU public key $k_r$.
• Step 5: R independently calculates the hash (${\varphi }_i^{\prime }$).
• Steps 6–8: R checks the has values to complete the login phase.

3.4. Multi-Hop Mutual Authentication Phase

The mutual authentication phase is performed between an RSU (R) and a vehicle ($V_i$) when the vehicle is located within R’s coverage area and is already registered. The unique feature in the protocol proposed in this subsection is that both the server R and vehicle $V_i$ execute mutual authentication using the PUF present in the vehicle. This is the first time in the literature, as far as the authors are concerned, that a PUF is used not only to authenticate the device to the server but also to authenticate the server to the device.

3.5. Communication Phase

In the multi-hop communication phase, data routing between an RSU and a certain vehicle is accomplished through collaborative store-and-forward data exchange.

3.5.1. Direct Link Between Vehicle and RSU

We encounter two situations in this phase. The first situation is when the transmitting vehicle $V_0$ has a direct link with the RSU. At this stage and following the login and mutual authentication phases, the following information is shared:

1.

Shared secret session key $k_0$;

2.

Vehicle $V_0$ uses its temporary ID (${\mathit{TID}}_0$) to preserve its anonymity;

3.

A nonce $n_0$ is shared during the login phase to ensure freshness and presence.

The protocol in Listing 3 illustrates the case when $V_0$ needs to send a message to the RSU when a direct link is available.

Listing 3. Vehicle $V_0$ communicates with a roadside unit (RSU) when a direct link is available.
1	$V_0$	:	$n_0=\mathrm{Generate}\_\mathrm{Nonce}\left(\right)$
2		:	$h=H\left(\right[{\mathit{TID}}_0\left|\right|n_0\left]\right)$
3	$V_0\to R$	:	$m_0=E_{k_i}\left(\right[\mathit{Data}\left|\right|n_0\left|\right|h\left]\right)]$
4	R	:	$\left[\mathit{Data}\right||n_0\left|\right|h\left]\right)]=D_{k_i}\left(m_0\right)$
5		:	$h^{\prime }=H\left(\right[{\mathit{TID}}_0\left|\right|n_0\left]\right)$
6		:	$\mathrm{Authenticate}(h,h^{\prime })$

At the end of the protocol in Listing 3 transmitting vehicle $V_0$ succeeds in securely transmitting the message to RSU while maintaining its anonymity using temporary ID (${\mathit{TID}}_0$), privacy using encryption, and proof of presence and freshness using nonce $n_0$.

3.5.2. Indirect Link Between Vehicle and RSU

The second situation is when there is no direct link between the vehicle and the RSU. In that case, seeking the aid of authenticated other vehicles is needed to properly establish a link between the vehicle $V_0$ and RSU. Figure 3 illustrates this situation.

The figure shows vehicle $V_0$ is attempting to communicate with R but requires the services of n intermediate vehicles (${\mathit{TID}}_i$), where some of these vehicles might not have been authenticated and should not be trusted. A secret shared key K will be generated between R and $V_0$ and also involve the n other intermediate vehicles $V_i$ with $1\le i\le n$.

This situation is challenging since there is no authentication or shared secret key between the source vehicle $V_0$ and the intermediate vehicles. The protocol in Listing 4 illustrates the case when $V_0$ needs to establish communication with the RSU when a direct link is not available and a multi-hop packet store-and-forward is used. We assume the case of n intermediate vehicles $V_1$ to $V_n$.

Notice in the protocol in Listing 4, Line 1, that transmitting vehicle $V_0$ sends its location ${\mathit{GPS}}_0$ to help establish the best routing path to the destination RSU.

Listing 4. Vehicle communication with a roadside unit (RSU) when a direct link is not available and the vehicle requests to transmit to the RSU via n intermediate nodes.
1	$V_0$	:	$\mathrm{Req}\_\mathrm{XMT}({\mathit{TID}}_0,R,{\mathit{GPS}}_0)$	% $V_0\to R$
2	$V_1\to V_0$	:	$\mathrm{ACK}({\mathit{TID}}_1,{\mathit{TID}}_0)$	% $V_1$ near $V_0$
3	$V_0\to V_1$	:	$m_0=E_{k_0}({\mathit{TID}}_0\left|\right|N_0)$
4.a		:	FOR  $i=1:n-1$  DO
4.b	$V_i$	:	$\mathrm{Req}\_\mathrm{XMT}({\mathit{TID}}_i,R,{\mathit{GPS}}_i)$
4.c	$V_{i+1}$	:	$\mathrm{ACK}({\mathit{TID}}_{i+1},{\mathit{TID}}_i)$
4.b	$V_i\to V_{i+1}$	:	$m_i=\left[E_{k_i}({\mathit{TID}}_i\left|\right|N_i\left)\right||m_{i-1}\right]$
4.c		:	END FOR
5	$V_n\to R$	:	$\mathrm{Req}\_\mathrm{XMT}({\mathit{TID}}_n,R,{\mathit{GPS}}_n)$
7	R	:	$\mathrm{ACK}(R,{\mathit{TID}}_n)$
8	$V_n\to R$	:	$m_n=\left[E_{k_n}({\mathit{TID}}_n\left|\right|N_n\left)\right||m_{n-1}\right]$
9.a	R	:	$K=\mathrm{Generate}\_\mathrm{secret}\_\mathrm{key}(\cdots )$
1	R	:	$\mathrm{Req}\_\mathrm{XMT}(R,V_n)$
2	$V_n\to R$	:	$\mathrm{ACK}({\mathit{TID}}_n,R)$
9.b	$R\to V_n$	:	$m_n=E_{k_n}\left(K\right)$
9.c		:	FOR  $i=1:n$  DO
9.d	R	:	$m_i=E_{k_i}\left[K\left|\right|m_{i-1}\right]$	% augmented message
9.e		:	END FOR
10	$R\to V_n$	:	$m_n$
11.a		:	FOR  $i=n:-1:1$  DO
11.a	$V_i\to V_{i-1}$	:	$E_{k_i}\left(m_i\right)$
11.b	$V_{i-1}$	:	$m_{i-1}={\mathrm{DEC}}_{k_{i-1}}\left(m_i\right)$
11.a		:	END FOR

3.6. Overall Protocol: Putting It All Together

Algorithm 1 summarizes all the operations discussed in Listings 1 to 4. The algorithms shows all the phases necessary to achieve mutual authentication using PUFs. There are six essential phases in the algorithm starting with pre-deployment at the PUF manufacturer and exchange of secret PUF data with trusted certification authorities that communicate with associated infrastructure such as roadside units.

Figure 4 provides a flowchart for the steps performed in Algorithm 1. The main players involved in execution of the algorithm are the vehicles, and any multi-hop relay vehicles, roadside units infrastructure, certification authorities and the PUF manufacturer or fabricator. It should be mentioned here that vehicles only communicate among themselves or the roadside units. There is no direct communication between vehicles and certification authorities.

Algorithm 1: Multi-hop mutual authentication protocol using PUFs

Input: Vehicle $V_i$ with identity $I{D}_i$, password $P{W}_i$, secret $k_i$, and PUF-generated CRPs ${\left\{(c_j,r_j)\right\}}_i$; RSU R; cloud authority C.  Output: Secure session key $K_{V_i,R}$ established between $V_i$ and R, extendable to multi-hop forwarding.  Phase 1: Pre-deployment (manufacturing/initialization) ;     1. Fab house generates CRP set ${\left\{(c_j,r_j)\right\}}_i$ for $V_i$ via its PUF.     2. Fab house sends to cloud authority C vehicles’ $(I{D}_i,P{W}_i,k_i)$.     3. C stores ${\left\{(c_j,r_j)\right\}}_i$ in its CRP database, indexed by $I{D}_i$.  Phase 2: Registration ;     4. RSU R establishes a TLS/PKI-secured link with C.     5. R broadcasts a HELLO and its public key to nearby vehicles.   Phase 3: Login (vehicle → RSU) ;     6. $V_i$ generates $TI{D}_i$ and computes nonce $n_i$.     7. $V_i$ sends $(I{D}_i,n_i)$ to R     8. $V_i$ sends $LoginReq=E_{p{k}_R}(I{D}_i,TI{D}_i,{\varphi }_i,nonc{e}_v)$ to RSU R.     9. If R is unreachable, $LoginReq$ is forwarded by neighboring authenticated vehicles (multi-hop).     10. R contacts C with the vehicle identity ($I{D}_i$)     11. C sends to R the authentication dataset of vehicle $V_i$  Phase 4: Authentication and Key Establishment ;     12. R validates ${\varphi }_i$ and selects a fresh challenge $c_j$ from ${\{c_j,r_j\}}_i$.     13. R sends $(c_j,helper\_data)$ to $V_i$ over the secure channel.     14. $V_i$ generates a noisy response $r_j’=PUF\left(c_j\right)$.     15. Using $helper\_data$, $V_i$ corrects $r_j’$ to recover $r_j$.     16. $V_i$ computes $h=H(r_j\Vert nonc{e}_v\Vert TI{D}_i)$.     17. $V_i$ sends $Resp=h$ back to R.     18. R verifies h against the expected hash using $r_j$ from C.     19. If valid, mutual authentication is successful. Otherwise, abort.     20. Both parties derive a session key $K_{V_i,R}=H(r_j\Vert nonc{e}_v\Vert I{D}_i\Vert TI{D}_i)$.  Phase 5: Multi-hop Extension (if R unreachable) ;      21. $LoginReq$ is relayed via authenticated neighbors $V_{relay}$ until an RSU is reachable.     22. Each $V_{relay}$ signs the forwarded packet with its session key to prevent tampering.     23. R issues acknowledgments along the reverse multi-hop path, establishing $K_{V_i,R}$.  Phase 6: Session Maintenance ;     24. Both $V_i$ and R periodically refresh session keys using new CRPs.  Error Handling and Security Guarantees ;     25. Replay protection ensured via nonces and TIDs.     26. Forward secrecy is provided since CRPs are never reused.     27. Scalability achieved via cloud-managed CRP lifecycle.     28. Mutual trust guaranteed (vehicle ↔ RSU), extended to multi-hop.

4. Security Analysis

We develop in this section several security analysis techniques for the proposed VANET mutual authentication protocols.

Table 3. Mapping of formal proof techniques to validated security properties.

Proof Technique	Validated Security Property	Section
Inductive Proof	- Confidentiality of messages - Replay attack resistance - Freshness guarantees via nonces and TIDs - Preservation of secrecy under multi-hop relaying	Section 4.4
Game-based Model	- Indistinguishability of session keys from random values - Adversary advantage bounded by negligible $ϵ$ - Robustness against chosen-message and impersonation attacks	Section 4.5
BAN Logic	- Correctness of authentication beliefs - Mutual agreement on session key between $V_i$ and R - Resistance against impersonation	Section 4.6

provides a roadmap and summary of the protocols discussed here.

This section provides a comprehensive informal and formal verification of the security protocol using a variety of methods. For the informal verification, we discuss some attacks that target VANs and show how the proposed protocol guards against them. For the formal verification, we employed a variety of methods, including Inductive Proof and Game-Based Proof. Each of these approaches verifies the protocol’s ability to uphold key security properties such as confidentiality, mutual authentication, anonymity, replay protection, freshness, presence, and impersonation resistance. We structure this section to not only verify these properties but also to describe in detail the mechanism and reasoning behind each proof.

4.1. Threat Model

To model anticipated threats, we assume that the adversary initiates the attacks via the embedded edge device present in the vehicles or by intercepting the communication across the network and the cloud. The vehicle, and its edge devices, represent the weakest link. These devices have limited compute resources and do not typically receive prompt software updates. The Dolev–Yao model for the adversary is assumed [27]. In addition, we assume the adversary can do the following actions:

1.

Obtain the vehicle ID through eavesdropping or guessing the car model and ID sequence assignment.

2.

Gain physical access to the vehicle in the field and extract any secret information from the memory.

3.

Access the secret keys through reading the flash or solid-state drive (SSD).

4.

Perform any side-channel attacks on the vehicle’s edge devices.

5.

Corrupt the vehicle’s edge device contents to run malicious software.

4.2. Informal Verification

Informal verification was thoroughly discussed in a related publication [11]. We provide here a brief summary as it applies to the protocol of this paper, which is as follows:

1.

Tampering attack: Device tampering modifies the chip encapsulation layers. This modifies the PUF response and results in authentication failure.

2.

Replay attack: The algorithm in Listing 3 uses nonces that change for each session. Using nonces ensures actual device presence and freshness.

3.

Eavesdropping attack: Listings 3 and 4 of the proposed algorithms show that almost all messages are encrypted using dynamic secret keys. In addition, the algorithms in Listings 3 and 4 use encrypted messages using secret keys that change with every session.

4.

Impersonation attack: According to the mutual authentication algorithm in Listings 3 and 4, vehicle authentication requires the vehicle to give the correct PUF CRP responses. An impersonating device cannot simply create its own PUF since the CRP set of this counterfeit PUF would not be registered by the device manufacturer, and no RSU would accept the counterfeit vehicle.

5.

Man-in-the-midddle attack: Our communication is protected by at least four layers as follows:

(a)

Insisting that all vehicles are first authenticated via RSUs.

(b)

Using nonces.

(c)

Using dynamic secret keys where each communication session.

(d)

Extensive use of hashing.

A malicious vehicle will not be able to register with an RSU and will not be able to participate in any activity.

6.

Forward/backward secrecy: The secret keys for V2I and V2V modes rely on using nonces and change at the start of each session and after handover between femtocells. Thus, an attacker cannot learn past or future keys.

7.

Session key guessing attack: In our protocols there are two session keys: $k_i$ between an RSU and vehicle ${\mathrm{ID}}_i$ $k_{i,j}$ between vehicle ${\mathrm{ID}}_i$ and ${\mathrm{ID}}_j$. These keys can not be inferred since they are not stored in non-volatile random access memories (NVRAMs) and dynamically change through use of nonces.

8.

Cloning attack: As was explained in Section 2.4, using a PUF gives the device a unique ID, and a challenge generates a unique ID.

9.

Physical attack: Using PUFs eliminates the need to store secret keys in NVRAM. The PUF response is never revealed but is used to generate secret keys and hash values.

4.3. Formal Verification Using Inductive and Game-Based Proofs

In this subsection, we delve into the formal verification of the proposed security protocol, expanding upon the earlier informal analysis. Formal verification is crucial for establishing strong, mathematical assurances about the protocol’s ability to uphold critical security properties. In contrast to informal methods, which rely on practical demonstrations and hypothetical attacks, formal techniques offer rigorous, systematic proofs that ensure robustness against even the most sophisticated threats.

For this analysis, we employed two powerful formal methods: Inductive Proof and Game-Based Proof, each serving a distinct purpose in validating the security guarantees of the protocol. These approaches allow us to mathematically verify that the protocol maintains key security properties such as confidentiality, mutual authentication, anonymity, replay protection, freshness, and impersonation resistance. We structure this subsection to not only verify these properties but also to describe in detail the mechanism and reasoning behind each proof.

In the first part of the formal verification, we use Inductive Proof, systematically proving the correctness of each property through a base case and an inductive step. This method ensures that the protocol remains secure under all possible conditions. The second part involves a Game-Based Proof, where we model the adversary’s interaction with the protocol as a game. Here, we analyze the likelihood of an adversary successfully breaching the protocol’s defenses, demonstrating that the adversary’s advantage remains negligible across all properties.

4.4. Inductive Proof

An Inductive Proof method establishes the security properties by proving that each property holds in the base case and continues to hold at every subsequent step of the protocol. This part presents inductive proofs for confidentiality, mutual authentication, anonymity, replay protection, and impersonation resistance as follows:

1.

Confidentiality

• Base Case:

Before any communication, the adversary has no knowledge of the session key. Let ${\mathcal{K}}_A$ represent the adversary’s knowledge,

$${\mathcal{K}}_A=\varnothing (\mathrm{no}\mathrm{knowledge}\mathrm{of}{K}_{session}).$$

(1)

• Inductive Step:

Assume confidentiality holds at step n, i.e., $K_{session}\notin {\mathcal{K}}_A$. At step $n+1$, the RSU sends the encrypted session key $E_K\left(K_{session}\right)$ to the vehicle,

$$R\to V_i:E_K\left(K_{session}\right).$$

(2)

By the semantic security of encryption and the unclonability of the PUF, the adversary cannot learn $K_{session}$, so

$$K_{session}\notin {\mathcal{K}}_A\forall n\in \mathbb{N}.$$

(3)

• Conclusion:

By induction, confidentiality is preserved throughout the protocol.

2.

Mutual Authentication

• Base Case:

Initially, neither the vehicle nor the RSU has authenticated the other,

$$\mathrm{Authenticated}(V_i,R)=\mathrm{false},\mathrm{Authenticated}(R,V_i)=\mathrm{false}.$$

(4)

• Inductive Step:

Assume that mutual authentication holds at step n. At step $n+1$, the vehicle sends $H\left(PUF\left(c_V\right)\right)$ to the RSU. The RSU verifies the PUF response,

$$\mathrm{If}H\left(PUF\left(c_V\right)\right)=H\left(\mathrm{expected}PUF\left(c_V\right)\right),\mathrm{then}\mathrm{Authenticated}(R,V_i)=\mathrm{true}.$$

(5)

Similarly, the vehicle authenticates the RSU,

$$\mathrm{If}H\left(PUF\left(c_R\right)\right)=H\left(\mathrm{expected}PUF\left(c_R\right)\right),\mathrm{then}\mathrm{Authenticated}(V_i,R)=\mathrm{true}.$$

(6)

• Conclusion:

Mutual authentication is preserved by induction,

$$\mathrm{Authenticated}(V_i,R)=\mathrm{true}\forall n\in \mathbb{N}.$$

(7)

3.

Anonymity

• Base Case:

Initially, the adversary has no knowledge of the vehicle’s identity,

$${\mathcal{K}}_A=\varnothing (\mathrm{no}\mathrm{knowledge}\mathrm{of}\mathrm{the}\mathrm{vehicle}\text{’}\mathrm{s}\mathrm{identity}).$$

(8)

• Inductive Step:

Assume anonymity holds at step n, i.e., the adversary cannot link the temporary ID (TID) to the real identity. In the next step, the vehicle uses a new $TID$, unlinkable to the real identity, so

$$P\left(\mathrm{Adversary}\mathrm{links}TID\mathrm{to}\mathrm{real}\mathrm{identity}\right)=0\forall n\in \mathbb{N}.$$

(9)

4.

Replay Protection and Impersonation Resistance

• Replay Protection:

The use of fresh nonces $N_V$ and $N_R$ at each step ensures that replay attacks are impossible, i.e., the adversary cannot replay an old message successfully,

$$P\left(\mathrm{Replay}\mathrm{attack}\mathrm{succeeds}\right)=0\forall n\in \mathbb{N}.$$

(10)

• Impersonation Resistance:

PUF responses are unclonable, meaning the adversary cannot impersonate the vehicle or RSU,

$$P\left(\mathrm{Impersonation}\mathrm{attack}\mathrm{succeeds}\right)=0\forall n\in \mathbb{N}.$$

(11)

4.5. Game-Based Proof

In the College of Computer Science, in Game-Based Proofs, the adversary interacts with the protocol as part of a formal game. Unterweger et al. [28] used game-based privacy proofs for aggregation protocols in the smart grid. The two parties of the game were the challenger and the adversary. We formulate the problem such that the adversary’s advantage in winning the game (breaking the security property) is negligible.

1.

Confidentiality

• Game Definition:

The adversary wins if they can correctly guess the session key $K_{session}$ after intercepting the ciphertext $E_K\left(K_{session}\right)$.

• Adversary’s Advantage:

The adversary’s advantage $Ad{v}_A$ is the probability of guessing $K_{session}$ given the ciphertext

$$Ad{v}_A=P\left(A\mathrm{guesses}{K}_{session}\right).$$

(12)

By the semantic security of encryption and the unclonability of the PUF, this probability is negligible,

$$Ad{v}_A=\mathrm{negligible}.$$

(13)

2.

Mutual Authentication

• Game Definition:

The adversary wins if they can impersonate either the vehicle or RSU and fool the other party into authenticating them.

• Adversary’s Advantage:

The adversary’s advantage is the probability of generating a valid PUF response,

$$Ad{v}_A=P\left(A\mathrm{generates}\mathrm{valid}H\left(PUF\left(c_V\right)\right)\right).$$

(14)

Since PUF responses are unclonable, this probability is negligible,

$$Ad{v}_A=\mathrm{negligible}.$$

(15)

3.

Anonymity

• Game Definition:

The adversary wins if they can link the temporary ID (TID) to the vehicle’s real identity.

• Adversary’s Advantage:

The adversary’s advantage is the probability of linking the $TID$ to the real identity,

$$Ad{v}_A=P\left(A\mathrm{links}TID\mathrm{to}\mathrm{real}\mathrm{identity}\right).$$

(16)

Since the $TID$ is unlinkable without the trusted mapping, this probability is negligible,

$$Ad{v}_A=\mathrm{negligible}.$$

(17)

4.

Replay Protection and Impersonation Resistance

• Replay Protection:

The adversary’s advantage in performing a replay attack is negligible due to the use of fresh nonces,

$$Ad{v}_A=P\left(\mathrm{Replay}\mathrm{attack}\mathrm{succeeds}\right)=\mathrm{negligible}.$$

(18)

• Impersonation Resistance:

Since PUF responses are unclonable, the adversary cannot impersonate the vehicle or RSU,

$$Ad{v}_A=P\left(A\mathrm{generates}\mathrm{valid}\mathrm{PUF}\mathrm{response}\right)=\mathrm{negligible}.$$

(19)

Summary of Formal Verification

Table 4. Summary of resistance against attacks.

Attack Type	Description	Resistance Mechanism	Status
Tampering Attacks	Physical tampering with the device.	PUF sensitivity to hardware changes.	Resistant
Replay Attacks	Reusing old messages to gain access.	Use of nonces for freshness.	Resistant
Impersonation Attacks	Impersonating the vehicle or RSU.	PUF challenge-response pairs prevent impersonation.	Resistant
Eavesdropping Attacks	Intercepting messages to gather sensitive information.	Encryption based on PUF-generated keys.	Resistant
MITM Attacks	Intercepting and altering communication between vehicle and RSU.	Mutual authentication and encryption prevent unauthorized modifications.	Resistant
Forward/Backward Secrecy	Ensuring past or future sessions remain secure even if the session key is compromised.	A new session key is generated for each session.	Resistant
Session Key Guessing Attacks	Brute-force attempts to guess the session key.	The session key is derived from PUF and cryptographic hash, making guessing infeasible.	Resistant
Cloning Attacks	Attempting to clone the vehicle’s PUF to impersonate it.	PUF is unclonable and unique to each device.	Resistant
Physical Attacks	Direct physical attacks on the device to extract cryptographic keys or disable the PUF.	PUF is highly sensitive to physical tampering, rendering the device unusable.	Resistant

shows the summary of obtained resistance results of the proposed protocol against all the tested attacks.

Moreover, through the use of Inductive Proof and Game-Based Proof, we verified that the protocol satisfies the following security properties as follows:

• Confidentiality: The session key remains confidential.
• Mutual Authentication: Both the vehicle and RSU authenticate each other correctly.
• Anonymity: The vehicle’s real identity is protected through the use of temporary IDs.
• Replay Protection: Replay attacks are prevented by using fresh nonces.
• Impersonation Resistance: Adversaries cannot impersonate the vehicle or RSU.

This comprehensive analysis demonstrates that the protocol is secure against the most common attack vectors under standard cryptographic assumptions.

4.6. Formal Proof Using BAN Logic

Michael Burrows, Martin Abadi, and Roger Needham introduced BAN logic as a formal validation of authentication protocols [29]. Ahmad et al. [30] used BAN logic for mutual authentication and secure key exchange. Yang et al. [31] used BAN logic to validate authentication protocol for VANET traffic emergency message broadcasting.

We start here by providing a summary of the symbols used in BAN formal protocol verification formalism [29]. The notation of BAN rules are given in

Table 5. Basic notations of BAN logic.

Notation	Description
R and V	Principal actors
$R|\equiv m$	R trusts message m
R ᐊ m	R receives message m
$R|\Rightarrow m$	R has jurisdiction over m
$R|\sim m$	R once sent m
$(m_1,m_2)$	Messages $m_1$ or $m_2$ are one part of the message $(m_1,m_2)$
$<m{>}_k$	Message m is encrypted with key k
${\left(m\right)}_k$	Message m is hashed with key k
$R\stackrel{k}{⟷}V$	k is a secret variable between R and V
$R\stackrel{k}{\rightleftharpoons }V$	m is secret and known only to R and V and parties trusted by them
$\#\left(m\right)$	Message m is fresh

.

The following BAN rules verify that our multi-hop authentication protocol supports secure authentication and key exchange:

• Message meaning: If R believes that key k is shared with V and R receives m encrypted under k, then R believes that V once sent m.

  $${\displaystyle \frac{R|\equiv V\stackrel{k}{⟷}Vᐊ{\left(X\right)}_k}{R|\equiv V|\sim X}}.$$
• Nonce verification: If R believes m is fresh and R believes V once sent m, then R trusts m,

  $${\displaystyle \frac{R|\equiv \#(m),R|\equiv V|\sim m}{R|\equiv V|\equiv m}}.$$
• Jurisdiction: If R believes V has jurisdiction over m and R trusts V trusts m, then R trusts m,

  $${\displaystyle \frac{R|\equiv V|\Rightarrow m,R|\equiv V|\equiv m}{R|\equiv m}}.$$
• Freshness concatenation: If part of a message is fresh, then the entire message is fresh too. In other words, if R trusts that $m_1$ is fresh, then R trusts that $m_1$ and $m_2$ are fresh,

  $${\displaystyle \frac{R|\equiv \#(m_1)}{R|\equiv \#(m_1,m_2)}}.$$
• Trust rule: If R trusts $m_1$ and $m_2$, then R trusts m,

  $${\displaystyle \frac{R|\equiv (m_1,m_2)}{R|\equiv m_1}}.$$
• Session key:

  $${\displaystyle \frac{R|\equiv \#(m),R|\equiv V|\equiv m}{R|\equiv S\stackrel{k}{⟷}V}}.$$

Our proposed multi-hop authentication protocol should achieve the following goals:

• Goal 1:

  $$R|\equiv V|\equiv V\stackrel{k}{⟷}R.$$
• Goal 2:

  $$V|\equiv R|\equiv R\stackrel{k}{⟷}V.$$
• Goal 3:

  $$R|\equiv V\stackrel{k}{⟷}R.$$
• Goal 4:

  $$V|\equiv R\stackrel{k}{⟷}V.$$
• Goal 5:

  $$V_i|\equiv V_{i-1}|\equiv V_i\stackrel{k}{⟷}{V}_{i-1}.$$
• Goal 6:

  $$V_i|\equiv V_{i+1}|\equiv V_i\stackrel{k}{⟷}{V}_{i+1}.$$
• Goal 7:

  $$V_i|\equiv V_i\stackrel{k}{⟷}{V}_{i-1}.$$
• Goal 8:

  $$V_i|\equiv V_i\stackrel{k}{⟷}{V}_{i+1}.$$

Basic assumptions of the multi-hop authentication protocol are as follows:

• A1:

  $$R|\equiv \#(N).$$
• A2:

  $$V_0|\equiv \#\left(N\right).$$
• A3:

  $$V_{i+1}|\equiv V_i\Rightarrow m_i.$$
• A4:

  $$V_i|\equiv V_{i+1}\Rightarrow m_{i+1}.$$
• A5:

  $$R|\equiv V_n\Rightarrow m_n.$$
• A6:

  $$V_n|\equiv R\Rightarrow m_n.$$
• A7:

  $$V_1|\equiv V_0\stackrel{m_0}{⟷}{V}_1.$$
• A8:

  $$R|\equiv V_n\stackrel{m_n}{⟷}R.$$

Following are the messages transferred in the multi-hop authentication protocol:

• Message 1:

  $$V_0\to V_1:E_{k_0}({\mathit{TID}}_0\left|\right|N_0).$$
• Message 2:

  $$V_i\to V_{i+1}:\left[E_{k_i}({\mathit{TID}}_i\left|\right|N_i\left)\right||m_{i-1}\right].$$
• Message 3:

  $$V_n\to R:\left[E_{k_n}({\mathit{TID}}_n\left|\right|N_n\left)\right||m_{n-1}\right].$$
• Message 4:

  $$R\to V_n:E_{k_n}\left(K\right).$$
• Message 5:

  $$V_i\to V_{i-1}:E_{k_i}\left(m_i\right).$$

BAN analysis of our multi-hop authentication scheme returns the following:

• S1: According to Msg 1, we can write

  $$V_1ᐊE_{k_0}({\mathit{TID}}_0\left|\right|N_0).$$
• S2: Based on Assumption A3, S1 and message-meaning rule, we have

  $${\displaystyle \frac{V_1|\equiv V_0\stackrel{k_i}{⟷}{V}_1,V_1ᐊE_{k_0}({\mathit{TID}}_0\left|\right|N_0)}{V_1|\equiv V_0\sim E_{k_0}({\mathit{TID}}_0\left|\right|N_0)}}.$$
• S3: According to Msg 2, we can write

  $$V_{i+1}ᐊE_{k_i}({\mathit{TID}}_i\left|\right|N_i).$$
• S4: Based on Assumption A4, S3 and message-meaning rule, we have

  $${\displaystyle \frac{V_{i+1}|\equiv V_i\stackrel{k_i}{⟷}{V}_{i+1},V_iᐊE_{k_i}({\mathit{TID}}_i\left|\right|N_i)}{V_{i+1}|\equiv V_i\sim E_{k_i}({\mathit{TID}}_i\left|\right|N_i)}}.$$

The previous BAN logic analysis illustrates that the proposed V2V multi-hop protocol achieves multifactor authentication through an insecure Wi-Fi environment.

5. Discussion

The proposed work introduces a novel mutual V2I multifactor authentication protocol tailored for vehicular networks, offering several distinctive contributions that advance current security frameworks for VANETs. These contributions are as follows:

1.

Bi-directional Multi-hop Authentication: The protocol enables bi-directional authentication using PUF hardware tokens over unsecured multi-hop Wi-Fi links. This feature ensures that both the vehicle and the roadside unit (RSU) authenticate each other, even when communication occurs via intermediate relay vehicles. Previous V2I authentication schemes typically assumed direct, single-hop connectivity; our multi-hop extension fills this critical gap by enabling cooperative forwarding with maintained trust guarantees.

2.

Cloud-based CRP Lifecycle Management: A cloud authority is integrated to manage the Challenge–Response Pair (CRP) lifecycle. This entity issues fresh challenges, prevents reuse, and coordinates revocation or renewal, eliminating finite CRP storage constraints on vehicles. Cloud-assisted oversight ensures centralized monitoring and scalability, supporting large fleets without sacrificing security continuity.

3.

Formal Security Verification: We provide a formal security analysis based on established cryptographic verification tools. The model confirms resistance to replay, man-in-the-middle, impersonation, and PUF cloning attacks under realistic adversarial assumptions. Collectively, these contributions—multi-hop mutual authentication, cloud-assisted CRP management, and verified robustness—establish a new benchmark for lightweight, scalable V2I authentication frameworks.

4.

Comparative Advantages: Relative to prior studies, the proposed protocol offers the following clear performance and design improvements:

• Lightweight Operation: By relying on symmetric primitives and PUF responses rather than PKI-based digital signatures, the protocol minimizes computational and latency overhead. While RSA-based methods incur hundreds of milliseconds of delay, the PUF-based challenge–response mechanism achieves sub-50 ms authentication.
• Mutual Trust Establishment: Both the vehicle and the RSU verify each other’s legitimacy, preventing impersonation in multi-hop environments where intermediate relays may be untrusted.
• Multi-hop Robustness: Unlike earlier PUF-Guard and similar frameworks [11], the proposed system explicitly supports relay-based multi-hop trust propagation.
• Multifactor Integration: Beyond the PUF, vehicle-specific identifiers or biometric traits can be fused to reinforce authentication strength.
• Cloud Oversight: The centralized cloud authority enables efficient CRP lifecycle management and scalability beyond localized trust zones.

Overall, this scheme achieves low latency, high scalability, and mutual trust in complex, multi-hop vehicular topologies, addressing limitations observed in earlier PUF-based and PKI-based designs.

6. Conclusions

In conclusion, this paper establishes a robust, comprehensive framework that enhances the security of Vehicular Ad Hoc Networks (VANETs). The proposed PUF-based mutual authentication protocol supports diverse modes of vehicular communication, visible light, 5G/6G, and Wi-Fi multi-hop, while providing end-to-end protection against tampering, replay, eavesdropping, and impersonation.

Our framework leverages PUF technology as a hardware root of trust for secure key generation, exchange, and verification without relying on non-volatile key storage. The integration of one-time passwords and ephemeral keys preserves forward and backward secrecy, mitigating man-in-the-middle threats. These design features collectively fortify confidentiality, integrity, and trust within smart transportation infrastructures.

The implications of this work are substantial: by ensuring resilient, unclonable, and efficient authentication mechanisms, the framework lays the groundwork for the next generation of intelligent transportation systems. It establishes an adaptable foundation that unites hardware-level security with system-wide trust management across dynamic vehicular environments.

Nevertheless, certain assumptions and constraints remain. The proposed framework presumes the availability of stable, vendor-consistent PUF modules across vehicles and RSUs. Vehicles without PUF hardware can still participate through multifactor authentication, but at a reduced trust level, as their secret keys must be stored in NVRAM. The overall system security remains bounded by the weakest non-PUF node. Therefore, achieving full-scale deployment requires careful interoperability design across heterogeneous hardware ecosystems.

7. Future Work

Future research will focus on validating the framework’s empirical feasibility, addressing interoperability challenges, and extending its resilience against real-world conditions. These efforts are structured as follows.

1.

Implementation Roadmap. While the proposed protocol’s security has been formally proven, its practical performance must be demonstrated through simulation and prototyping. The planned implementation roadmap includes:

• Vehicle Nodes: Modeled as Mininet-WiFi stations representing vehicular OBUs with software-based PUF modules.
• RSUs: Simulated as Mininet access points using cloud-issued short-lived certificates.
• Cloud Authority: Operated as a Mininet controller responsible for CRP lifecycle management and challenge validation.
• PUF Simulation: Realized via software fuzzy extractors to emulate noise-resilient CRP generation [24].

2.

Simulation Environment. We will employ Mininet-WiFi [32] integrated with SUMO [33] to emulate dynamic vehicular mobility and multi-hop wireless propagation. This setup enables realistic performance assessment under variable traffic densities, hop distances, and network loads. Mininet-WiFi is a widely used network emulator that extends the well-known Mininet environment to support wireless stations and access points with full mobility and multi-hop capabilities [32,34]. This makes it particularly well-suited for emulating vehicular ad hoc networks (VANETs) in software. Crucially, Mininet-WiFi can realistically model multi-hop Wi-Fi topologies akin to our scenario—for example, vehicles forwarding packets over multiple wireless hops to reach an RSU—while running real network protocols and applications. The platform also integrates with the SUMO traffic mobility simulator, allowing us to import realistic vehicle movement traces and road network layouts [35].

This integration means we can recreate dynamic VANET scenarios (with vehicles joining, leaving, and moving between RSU coverage areas) and evaluate our authentication protocol under realistic mobility patterns. Another advantage is that Mininet-WiFi enables fine-grained measurement of network metrics. We will be able to measure latency (end-to-end and per-hop communication delay), authentication delay (time to complete our handshake), and system throughput under varying loads, all within a controlled, reproducible environment. It also scales to a significant number of virtual nodes, which will let us assess scalability (e.g., testing hundreds of simulated vehicles per RSU) before moving to real hardware. In summary, Mininet-WiFi offers an ideal balance of realism and flexibility—it has been employed in prior vehicular network research for prototyping V2X protocols. [32], and it provides the tools (mobility modeling, wireless channel emulation, etc.) needed to evaluate our multi-hop authentication scheme rigorously. We emphasize that this simulation-based evaluation is part of our future work plan, to be conducted in the next phase of the project, laying the groundwork for subsequent field testing. The implementation in Mininet-WiFi will not only validate the feasibility of our protocol in a complex network setting but also guide any optimizations before we proceed to hardware prototyping.

3.

Evaluation Metrics. Performance will be evaluated using the following:

• Authentication Latency: End-to-end handshake delay, per hop and aggregate.
• Key Generation Time: Average CRP evaluation and validation duration.
• Communication Overhead: Number of messages and data exchanged.
• Scalability: Performance degradation with increasing node count.
• Robustness: Authentication success under packet loss, noise, or adversarial interference.

Preliminary projections indicate an authentication latency below 10 ms per hop, satisfying the sub-100 ms safety requirement for real-time VANET applications.

4.

Hardware Prototyping. Subsequent stages will involve deploying a hardware-in-the-loop prototype using FPGA-based PUF modules integrated into vehicular OBUs and RSUs (e.g., Raspberry Pi or Jetson Nano boards). This will enable the evaluation of end-to-end handshake efficiency, interoperability with IEEE 802.11p/C-V2X standards, and resilience to environmental perturbations.

5.

Long-term Research Directions. The following open challenges remain to be addressed:

• Legacy Integration: Develop hybrid authentication modes for vehicles lacking PUF hardware.
• Standardization: Define cross-vendor CRP formats and lifecycle management protocols.
• Hardware Optimization: Explore cost-efficient, automotive-grade PUF designs resilient to modeling and side-channel attacks [36].
• Environmental Calibration: Investigate adaptive fuzzy extractors to stabilize CRPs under variable temperature and voltage conditions.
• Decentralized Trust: Incorporate distributed ledger technologies to reduce single-point dependence on cloud authorities.

In summary, the proposed framework represents a major step toward scalable, bidirectional, and hardware-rooted authentication for vehicular networks. Continued empirical validation and hardware deployment will ensure the practicality, reliability, and standardization necessary for real-world adoption in intelligent transportation systems.