Quantum Secure Pairwise Key Agreement Scheme for Fog-Enabled Social Internet of Vehicles

Abstract

In Social Internet of Vehicles (SIoV) environments, fog computing plays a crucial role in supporting real-time services by reducing the latency inherent in cloud-based architectures. However, fog nodes are typically deployed in physically exposed roadside environments and can be operated by several system operators, making them vulnerable to physical compromise and unauthorized access. Despite these threats, many existing authentication schemes assume fog nodes to be fully trusted or honest-but-curious, allowing them to decrypt transmitted data using a session key shared among vehicles, fog nodes, and cloud servers. To overcome these limitations, this paper proposes a quantum-secure pairwise key agreement scheme that establishes distinct session keys for vehicle–fog, fog–cloud, and vehicle–cloud communications. This design effectively prevents the disclosure of sensitive information even in the event of fog node compromise. Furthermore, Physical Unclonable Functions (PUFs) are employed to mitigate physical capture attacks, while lattice-based cryptography based on the Module Learning with Errors (MLWE) problem is integrated to ensure resistance against quantum computing attacks. The security of the proposed protocol is rigorously validated through formal analysis using AVISPA, BAN logic, and the Real-or-Random (RoR) model, in addition to informal security analysis. Comparative performance evaluations against related schemes demonstrate that the proposed approach achieves a balance between efficiency and security, making it well suited for practical deployment in SIoV environments.

1. Introduction

Intelligent Transportation Systems (ITS) have gradually evolved into Cooperative Intelligent Transportation Systems (C-ITS) by enhancing connectivity among vehicles and diverse physical entities. This technological evolution has extended communication beyond conventional inter-vehicle interactions, giving rise to a novel paradigm known as the Social Internet of Vehicles (SIoV), which integrates concepts of social relationships and interactions into vehicular networks [1,2]. In SIoV environments, vehicles, drivers, and transportation infrastructure are seamlessly interconnected to support traffic safety and various convenience services [3,4]. The large volume of real-time data generated within SIoV systems necessitates integration with cloud-based services, which provide substantial computational power and storage capacity for global data analysis and long-term information management [5].

However, cloud servers inherently struggle to meet the stringent real-time requirements of SIoV applications due to network latency resulting from their physical distance from edge devices [5]. To address this challenge, fog computing has been introduced into SIoV environments as an intermediate layer between vehicles and the cloud, enabling low-latency service delivery closer to data sources [6,7]. By supporting data preprocessing and localized service provisioning, fog computing significantly enhances system responsiveness and overall processing efficiency [8,9].

Despite these advantages, fog nodes are typically deployed in physically exposed roadside environments and can be operated by several system operators, making SIoV systems vulnerable to physical compromise and unauthorized access [10,11]. In particular, the compromise of fog nodes can result in the exposure of sensitive information—such as vehicle location histories, identity credentials, and drivers’ private data—which may further facilitate severe security threats beyond simple data leakage.

Many existing authentication schemes for SIoV environments [11,12,13] assume fog nodes to be fully trusted or honest-but-curious. Under this assumption, fog nodes are able to decrypt transmitted data using a single session key shared among vehicles, fog nodes, and cloud servers. Such a trust model poses significant security risks, as a compromised fog node may gain unauthorized access to sensitive information beyond its intended communication scope.

To address these limitations, this paper proposes a pairwise key agreement scheme that generates distinct session keys for each communication link, namely vehicle–fog, fog–cloud, and vehicle–cloud. In the proposed scheme, independent session keys are established between each pair of entities within a single authentication session, ensuring that a fog node cannot access data beyond its authorized communication scope. As a result, even if a fog node is compromised, the exposure of sensitive information can be effectively prevented.

Furthermore, considering the characteristics of SIoV environments in which fog nodes and vehicular devices are often physically exposed, Physical Unclonable Functions (PUFs) are incorporated as a countermeasure against physical capture attacks. In addition, to address the long-term security threats posed by advances in quantum computing to conventional public-key cryptographic schemes, lattice-based cryptography based on the Module Learning with Errors (MLWE) problem is adopted to provide resistance against quantum attacks.

The security of the proposed protocol is rigorously analyzed using AVISPA, BAN logic, and the Real-or-Random (RoR) model, with comprehensive discussions covering various attack scenarios. Moreover, comparative evaluations with existing authentication schemes are conducted to assess the communication overhead, computational efficiency, and overall suitability of the proposed scheme for practical deployment in SIoV environments.

1.1. Contributions

The primary contributions of this paper are as follows:

• A pairwise three-party authentication and key agreement scheme is proposed for SIoV environments. The scheme establishes distinct session keys for each communication link within a single authentication session, thereby preventing fog nodes from accessing sensitive information beyond their authorized scope.
• A quantum-resistant authentication and key generation framework based on lattice-based cryptography, specifically the Module Learning with Errors (MLWE) problem, is developed. The proposed framework achieves strong security guarantees while maintaining computational efficiency suitable for resource-constrained vehicular devices.
• A comprehensive security and performance evaluation of the proposed scheme is conducted. Formal verification is performed using AVISPA, the Real-or-Random (RoR) model, and Burrows–Abadi–Needham (BAN) logic, complemented by informal security analysis and comparative performance assessments against existing schemes.

1.2. Paper Organization

The organization of this paper is as follows. Section 2 reviews existing authentication protocols for SIoV and fog computing environments and discusses their security and efficiency limitations. Section 3 introduces MLWE and PUF, which form the foundations of the scheme, and defines the adversary model and notations used throughout the paper. Section 4 presents the fog computing-based SIoV system model and specifies the roles and trust levels of each entity. Section 5 details the protocol procedures, including system initialization, registration, and the authentication and pairwise key agreement process. Section 6 analyzes the security of the protocol through formal verification using AVISPA, the RoR model, and BAN logic, along with informal analysis. Section 7 evaluates security features and computational costs through comparisons with existing protocols. Finally, Section 8 concludes the paper and outlines future research directions.

2. Related Works

The SIoV has been introduced as an extended paradigm that integrates social relationships and user-centric services into the conventional IoV, aiming to enhance information sharing efficiency and service intelligence in intelligent transportation environments. Early studies on SIoV primarily focused on conceptual definitions and architectural designs, while security considerations were treated as secondary issues.

In 2015, Alam et al. [1] presented a VANET-based physical architecture for SIoV and defined application scenarios that exploit social relationships among vehicles. Subsequently, Maglaras et al. [2] analyzed the key technological components of SIoV and pointed out that trust and privacy issues could become critical threats in such environments. However, these studies did not provide concrete authentication or key management mechanisms. Since 2017, SIoV research has expanded toward service quality and trust management. Ning et al. [3] proposed a cooperative quality-aware recommendation system to mitigate frequent disconnections among vehicles, while Iqbal et al. [4] emphasized the importance of trust management in SIoV and discussed various trust models, including blockchain-based approaches. In the same year, Butt et al. [14] systematically analyzed privacy management issues in SIoV and highlighted the need for advanced privacy-preserving techniques. Nevertheless, these studies mainly focused on logical trust models and did not sufficiently address authentication and key agreement issues in practical communication scenarios.

As SIoV environments began to incorporate advanced applications such as federated learning and vehicular advertising, security requirements became increasingly complex. Chen et al. [6] proposed a confidentiality-based key transmission protocol and a probabilistic-selection-based federated learning scheme for SIoV, while Zhao et al. [15] introduced a similar federated learning algorithm. Ibrar et al. [16] identified the dynamic evolution of vehicular social relationships as a major challenge in SIoV, and Zheng [17] proposed a digital-twin-based social relationship model for vehicular advertising. However, most of these studies rely on conventional cryptographic schemes and fail to fully address real-time security and computational efficiency in highly mobile environments.

To meet these increasingly stringent real-time and security requirements, fog computing has been introduced as a key infrastructure in SIoV, enabling distributed processing between vehicles and the cloud to reduce latency, while also introducing new security threats. After Bononi et al. [18] introduced the concept of fog computing, Yi et al. [19,20] systematically analyzed security and privacy threats in fog-based environments. In 2018, Imine et al. [21] applied blockchain-based authentication to fog computing, but dependence on cloud brokers and latency issues were identified as limitations. Huang et al. [22] and Saleem [23] proposed PUF- and ECC-based authentication schemes, respectively; however, limited attention was paid to scenarios involving untrusted fog nodes. Subsequently, numerous studies proposed fog-based authentication and key management schemes; however, many of them rely on single-session key sharing, complex key management procedures, or high computational costs [24,25,26]. Such approaches fail to adequately reflect the heterogeneous trust levels among vehicle–fog–cloud communications and may compromise end-to-end confidentiality when fog nodes are physically exposed.

In summary, although existing SIoV and fog-based security studies have gradually evolved, lightweight security frameworks that simultaneously satisfy high mobility, low latency, and resource constraints remain insufficient. Moreover, most existing schemes rely on classical public-key cryptography such as ECC and therefore fail to address fundamental vulnerabilities in post-quantum environments. To overcome these limitations, it is necessary to develop a new security framework that separately satisfies the security requirements of each communication segment while ensuring robustness in the post-quantum era.

3. Preliminaries

3.1. MLWE

Lattice-based cryptography was primarily established upon the Learning with Errors (LWE) problem introduced by Regev [27], which provides a security reduction from average-case instances to worst-case lattice problems such as the Shortest Vector Problem (SVP). While LWE offers robust security, its practical application is often hindered by the substantial computational overhead and storage requirements associated with large matrix operations. To address these efficiency concerns, Ring-LWE (RLWE) was proposed [28], utilizing polynomial rings to reduce key sizes and accelerate computations. However, the strict algebraic structure of RLWE potentially introduces vulnerabilities to specific structural attacks and limits parameter flexibility. As a generalized framework suitable for post-quantum authentication, MLWE strikes an optimal balance between the high security of LWE and the superior efficiency of RLWE by operating over modules of polynomial rings [29]. MLWE offers a scalable architecture where the security level can be adjusted by varying the module rank k. Notably, MLWE simplifies to RLWE when $k=1$ and reverts to standard LWE when the ring degree $n=1$, providing a versatile foundation for post-quantum cryptographic primitives.

3.1.1. The MLWE Problem

For a polynomial ring $R_q={\mathbb{Z}}_q\left[X\right]/(X^n+1)$, the MLWE problem is defined by the parameters $(n,q,k,\chi )$. Here, n denotes the degree of the polynomial ring, q is a prime modulus that defines the finite field over which the polynomial coefficients are represented, k denotes the dimension of the polynomial vector, and $\chi$ specifies the probability distribution from which the error terms are sampled. Let $A\in R_q^{k\times k}$ be a matrix sampled uniformly at random. Given a secret vector $s\in R_q^k$ and an error vector $e\in R_q^k$ both drawn from a noise distribution $\chi$, the MLWE sample is represented as $(A,b=A·s+e)$. The hardness of the MLWE problem lies in the computational infeasibility of distinguishing such samples from a uniformly random distribution over $R_q^{k\times k}\times R_q^k$.

3.1.2. CRYSTALS-Kyber Key Encapsulation Mechanism (KEM)

To construct the proposed protocol based on the security of the MLWE problem, this study employs the MLWE-based key encapsulation mechanism introduced in CRYSTALS-Kyber [30,31]. CRYSTALS-Kyber was ultimately selected as the standard KEM algorithm in the NIST post-quantum cryptography (PQC) standardization process, and its security and performance characteristics have been thoroughly analyzed.

A key encapsulation mechanism (KEM) enables two parties to establish a shared secret through an asymmetric cryptographic framework. In the CRYSTALS-Kyber design, indistinguishability under adaptive chosen-ciphertext attack (IND-CCA2) security is achieved by applying the Fujisaki-Okamoto (FO) transformation to an underlying public-key encryption scheme that satisfies indistinguishability under chosen-plaintext attack (IND-CPA).

The CRYSTALS-Kyber KEM operates through three main procedures: key generation, encapsulation, and decapsulation.

• Key Generation: The entity samples $s,e\leftarrow {\chi }^k$ and a random matrix $A\in R_q^{k\times k}$ to compute the public key $pk=(A,t=A·s+e)$. The corresponding secret key is $sk=s$.
• Encapsulation: To establish a shared secret with the owner of $pk$, the sender chooses a random message $m\in {\{0,1\}}^{\mathcal{l}}$ and samples internal noise vectors $r,e_1,e_2\leftarrow {\chi }^k$. The resulting ciphertext $ct=(u,v)$ is generated as follows:

  $$u=A^{\top }·r+e_1,v=t^{\top }·r+e_2+\mathrm{Encode}\left(m\right)$$
  The session key is derived as $SK=H\left(m\right)$.
• Decapsulation: Upon receiving $ct$, the recipient utilizes $sk=s$ to isolate the encoded message:

  $$m^{\prime }=\mathrm{Decode}(v-u^{\top }·s)$$
  The session key is then reconstructed as $SK=H\left(m^{\prime }\right)$.

3.1.3. Message Encoding and Decoding

To ensure error-resilient communication, the binary message m is mapped into the ring elements using specific encoding and decoding functions. This process facilitates the reliable recovery of the shared secret even in the presence of noise without requiring additional reconciliation data.

• Encode: Each bit $m_i$ of the binary message $m\in {\{0,1\}}^{\mathcal{l}}$ is mapped as follows:

  $$\mathrm{Encode}\left(m_i\right)=\left\{\begin{array}{cc}0\hfill & \mathrm{if}{m}_i=0\hfill \\ ⌊{\displaystyle \frac{q}{2}}⌋\hfill & \mathrm{if}{m}_i=1\hfill \end{array}\right.$$
• Decode: The decoding threshold $⌊{\displaystyle \frac{q}{4}}⌋$ is used to tolerate noise introduced during MLWE operations. For each polynomial coefficient $x\in {\mathbb{Z}}_q$ obtained during decryption, the following threshold function is applied to recover the corresponding binary value:

  $$\mathrm{Decode}\left(x\right)=\left\{\begin{array}{cc}1\hfill & \mathrm{if}x\ge ⌊{\displaystyle \frac{q}{4}}⌋\hfill \\ 0\hfill & \mathrm{otherwise}\hfill \end{array}\right.$$

3.2. Physical Unclonable Function

Recently, PUFs have been widely adopted as a key enabling technology to strengthen authentication and key management mechanisms in various lightweight security environments, including IoT, VANETs, drone networks, and wireless medical sensor networks.

A PUF is a hardware security primitive that leverages subtle and inherent physical variations occurring during the semiconductor manufacturing process. These microscopic variations make each PUF instance unique, rendering it practically impossible to physically clone a device or extract its internal secret values, even when devices are manufactured using the same design [32,33,34,35].

The core mechanism of a PUF is based on the concept of a Challenge–Response Pair (CRP). When a specific input, called a challenge ($CH$), is applied to the PUF circuit, a response ($RE$) reflecting the unique physical characteristics of that device is generated, which can be expressed as follows:

$$RE=PUF\left(CH\right)$$

A PUF provides the following key security properties:

• Unclonability: It is infeasible to manufacture another circuit that produces the same response $RE$ for a given challenge $CH$.
• One-way Evaluability: Computing the output $RE$ for a given input $CH$ is fast and efficient, whereas deriving the input $CH$ or inferring the internal structure of the device from the output $RE$ is computationally infeasible.
• Unpredictability: Since PUF responses cannot be predicted in advance by external entities, the device can be protected against intrusive physical attacks.

However, when PUF stability is limited, environmental conditions (e.g., temperature or voltage fluctuations) may affect response reproducibility. To address this issue, several classes of so-called ideal PUFs have been proposed to improve stability across wide operating ranges. For instance, certain designs exploit the randomness of soft gate-oxide breakdown locations or deliberately introduced permanent physical defects to yield more stable responses [36,37]. By adopting such ideal PUF designs, it is possible to reduce computational and storage overhead and lessen dependence on stability-enhancement mechanisms such as helper data or fuzzy extractors, while still maintaining practical deployability [38,39].

In this study, PUFs are introduced to both the vehicle $V_i$ and the fog node $F_j$ to integrate device-specific identification information into the authentication process. Consequently, even if an attacker physically captures a node and obtains data stored in its internal memory, the attacker cannot impersonate a legitimate entity without the hardware-dependent unique response generated by the PUF.

3.3. Adversary Model

To evaluate the security of the proposed protocol, this paper adopts a threat model based on the Dolev–Yao (DY) model [40]. Since the DY model assumes that an attacker has full control over public communication channels, it is suitable for analyzing various attack scenarios.

• An attacker can eavesdrop, modify, delete, and replay messages transmitted over wireless communication channels to bypass authentication or forge valid messages.
• An attacker can impersonate legitimate vehicles, fog nodes, or cloud servers, or illegally participate in the authentication process by generating forged messages.
• If a vehicle or a fog node is physically compromised, an attacker can extract data stored in the internal memory. However, it is assumed that it is impossible to clone or derive the response values of the PUF, which is a unique hardware characteristic.
• Fog nodes are considered untrusted entities. Their access to direct secret information between the vehicle and the cloud is restricted, and they may serve as potential channels for message leakage or manipulation during message verification and relay operations.
• An attacker may retransmit previously captured messages or attempt to guess secret parameters through repetitive computations. However, it is assumed that it is computationally infeasible for an attacker to successfully infer all secret information within polynomial time.

3.4. Notations

Table 1. Notations.

Notation	Description
$V_i$	The i-th vehicle
$F_j$	The j-th fog node
$CS$	Cloud server
$VI{D}_i$, $VP{W}_i$	Identity and password of vehicle $V_i$
$FI{D}_j$	Identity of fog node $F_j$
$TVI{D}_i$	Temporary pseudonym identifier of $V_i$
$P,s$	Public key and secret key of $CS$
$\mathcal{A}$	Public matrix $A\in R_q^{k\times k}$
$h(·)$	Hash function
$Encode(·)$	Encoding function
$Decode(·)$	Decoding function
$c_i=(u_i,v_i)$	Ciphertext
$k_i$	Shared secret derived through the KEM
$S{K}_{VCS},S{K}_{CSV}$	Session key between vehicle and cloud server
$S{K}_{VF},S{K}_{FV}$	Session key between vehicle and fog node
$S{K}_{FCS},S{K}_{CSF}$	Session key between fog node and cloud server
$T{S}_1,T{S}_2,T{S}_3,T{S}_4$	Timestamps
$PUF(·)$	Physical Unclonable Function
⊕	Bitwise XOR operation
$\left|\right|$	Concatenation operator

summarizes the notations and symbols used throughout the proposed protocol.

4. System Model

4.1. Communication Entities

The proposed fog computing-based SIoV environment consists of four distinct entities: the cloud server $CS$, fog node $F_j$, roadside unit (RSU), and vehicle $V_i$ equipped with an on-board unit (OBU). The system model of the proposed scheme is illustrated in Figure 1 and specific roles of each entity are defined as follows:

4.1.1. Cloud Server

The Cloud Server $CS$ acts as the central management authority of the entire system. During the system initialization phase, it generates and manages global system parameters and the master key s, and processes registration requests from vehicles and fog nodes. Technically, it functions as a data center with powerful computational capabilities and large-scale storage, performing long-term analysis of data transmitted from fog nodes.

From a security perspective, the $CS$ is assumed to be a semi-trusted entity, meaning it cannot be considered fully trustworthy. Specifically, there may exist a malicious insider with administrative privileges within the $CS$ who could secretly access registration messages or the internal database of vehicles and fog nodes. Furthermore, the server database may be exposed to external threats such as table leakage attacks, where the entire database is compromised.

To mitigate this imperfect trust assumption, the system is designed so that sensitive user information including the original password and hardware-specific response values is not directly transmitted to the $CS$ during the registration phase. Instead, these sensitive data are processed only within the user’s local device. In addition, when an actual session is established, the $CS$ does not unilaterally initiate communication; rather, it must prove its legitimacy through a step-by-step mutual authentication procedure with the vehicle and fog node before participating in the session key agreement.

4.1.2. Fog Node

The fog node is a distributed computing server positioned as an intermediate layer between vehicles and cloud servers, enabling real-time local services and data preprocessing closer to data sources. Fog computing serves as a key infrastructure for supporting real-time performance by reducing the network latency caused by the physical distance between vehicles and cloud servers. However, fog nodes are deployed in physically exposed roadside environments and can be operated by several system operators, which makes them potentially vulnerable to security threats. Considering these characteristics, fog nodes should be limited to processing only the information necessary for service execution, while sensitive data exchanged between vehicles and cloud servers should not be exposed even when it passes through fog nodes. Accordingly, in the proposed scheme, fog nodes are treated as untrusted entities, and different session keys are established for each communication link to ensure that fog nodes cannot cryptographically access, infer, or induce data beyond the scope of communication explicitly authorized to them.

4.1.3. Roadside Unit

The RSU is a wireless communication device installed along the roadside infrastructure that functions as a gateway supporting physical communication between vehicles and the upper layers. A key feature of the proposed architecture is that the RSU is defined as a simple relay and a fully transparent entity, which neither performs any cryptographic operations nor participates in authentication or key agreement processes. The RSU merely forwards messages between vehicles and fog nodes. By limiting the RSU’s role to physical relaying, the protocol minimizes the attack surface; even if an RSU is physically compromised, the integrity of the entire authentication system remains intact.

4.1.4. Vehicle

The vehicle $V_i$, equipped with an OBU, is both a producer of real-time sensor data and a consumer of system services. Despite having limited micro-controller-level resources, it executes MLWE-based quantum-resistant cryptographic algorithms to ensure high-speed security operations in high-mobility environments. To ensure privacy, vehicles utilize temporary identities $TVI{D}_i$ and negotiate independent session keys with both the fog node and the cloud server. As an untrusted entity, a vehicle must be authenticated as a legitimate user. Privacy protection through session keys and hardware-based security is mandatory to defend against potential physical theft and information leakage.

4.2. Communication Flow

The scheme proposed in this paper consists of three main phases: initialization, registration, and authentication and key agreement. During the key agreement phase, the Cloud server, Fog node, and Vehicle establish independent session keys for each pair of entities. This design restricts a fog node from accessing sensitive information transmitted by vehicles beyond its authorized scope. The overall workflow is illustrated in Figure 2, and the detailed descriptions for each phase are as follows:

• System Initialization: The cloud server generates the public parameters and MLWE-based master keys required for system operation.
• Fog Node Registration: The fog node transmits its identity information to the cloud server and receives the authentication parameters necessary for future secure communications.
• Vehicle Registration: The vehicle registers with the cloud server to obtain the security credentials required for network participation and mutual authentication.
• Authentication and Pairwise Key Agreement: This phase is performed when a vehicle enters the communication range of a fog node. Through a single message exchange session, three-party mutual authentication among the vehicle, fog node, and cloud server is completed. The core feature of this phase is the simultaneous generation of three independent session keys within a single authentication process.
• Derived Session Keys: Upon successful authentication, the following keys are shared between the entity pairs:
  • Fog–Cloud session key: A key for secure data transmission and control between the fog node and the cloud server.
  • Vehicle–Fog node session key: A key for secure communication between the vehicle and the adjacent fog node.
  • Vehicle–Cloud session key: A dedicated key that ensures end-to-end confidentiality between the vehicle and the cloud server, preventing data exposure to the intermediate fog node.

5. Proposed Scheme

5.1. Initialization Phase

In this phase, the Cloud Server $CS$ establishes the public parameters and cryptographic foundations for the MLWE-based environment. This process is depicted in Figure 3, and the detailed explanation is as follows. The $CS$ generates a public matrix $A\in R_q^{k\times k}$ and defines a cryptographic hash function $h:{\{0,1\}}^{\ast }\to {\{0,1\}}^{\lambda }$. Subsequently, the $CS$ samples a secret vector s and an error vector e from the discrete Gaussian distribution ${\chi }^k$ to compute the public key $P=A·s+e$. Finally, the $CS$ publishes the system parameters $\{A,h(·),P,{\chi }^k\}$, enabling all entities within the network to utilize these values for subsequent registration and authentication processes.

5.2. Registration Phase

5.2.1. Fog Node Registration Phase

Prior to the authentication and key agreement process, each fog node $F_j$ must undergo a registration phase with the $CS$. This process is depicted in Figure 4, and the detailed explanation is as follows:

S1: 

The fog node $F_j$ selects its identifier $FI{D}_j$ and sends it to the cloud server $CS$ through a secure channel to initiate the registration process.

S2: 

Upon receiving $FI{D}_j$, the $CS$ generates a challenge value $C{H}_j$ and random values $q_j,r_j$. The $CS$ then computes $Q_j=q_j\oplus h(r_j\parallel s)$, where s is the cloud server’s master secret key. The $CS$ stores $\{FI{D}_j,r_j,Q_j\}$ in its database and returns the registration response $\{C{H}_j,q_j\}$ to $F_j$ via the secure channel.

S3: 

After receiving the response, $F_j$ computes its physical response $R{E}_j=PUF\left(C{H}_j\right)$ using the received challenge $C{H}_j$ through its PUF. $F_j$ then computes $E{Q}_j=q_j\oplus h(FI{D}_j\parallel R{E}_j)$ and stores $\{FI{D}_j,C{H}_j,E{Q}_j\}$ in its local memory to complete the registration phase.

5.2.2. Vehicle Registration Phase

Prior to the authentication and key agreement process, each vehicle $V_i$ must undergo a registration phase with the $CS$. This process is depicted in Figure 5, and the detailed explanation is as follows:

S1: 

The vehicle $V_i$ selects its identifier $VI{D}_i$ and password $VP{W}_i$. It then sends $VI{D}_i$ to the cloud server $CS$ through a secure channel to initiate the registration process.

S2: 

Upon receiving the request, the $CS$ generates a challenge value $C{H}_i$ and random values $z_i,r_i$. The $CS$ computes $Z_i=z_i\oplus h(r_i\parallel s)$, where s is the cloud server’s master secret key. The $CS$ stores $\{VI{D}_i,Z_i,r_i\}$ in its secure database and returns the registration parameters $\{C{H}_i,z_i\}$ to $V_i$ via the secure channel.

S3: 

After receiving the response, $V_i$ computes its unique physical response $R{E}_i=PUF\left(C{H}_i\right)$ by applying the received challenge $C{H}_i$ to its PUF. $V_i$ then computes the authentication token $Aut{h}_i=h(VI{D}_i\parallel VP{W}_i\parallel R{E}_i)$ and the obscured secret value $E{Z}_i=z_i\oplus h(R{E}_i\parallel VI{D}_i\parallel VP{W}_i)$. Finally, $V_i$ stores $\{VI{D}_i,C{H}_i,E{Z}_i,Aut{h}_i\}$ in its local memory to complete the registration phase.

5.3. Login Phase

To initiate the authentication and key agreement process, $V_i$ must first undergo a login phase. The user enters their identity $VI{D}_i$ and password $VP{W}_i$ into the vehicle $V_i$. Upon input, $V_i$ retrieves the stored challenge $C{H}_i$ and computes the physical response $R{E}_i^{\ast }=PUF\left(C{H}_i\right)$ via its PUF. The vehicle then generates the verification token $Aut{h}_i^{\ast }=h(VI{D}_i\parallel VP{W}_i\parallel R{E}_i^{\ast })$ and compares it with the $Aut{h}_i$ stored during the registration phase. The login is granted only if $Aut{h}_i^{\ast }$ matches $Aut{h}_i$, allowing $V_i$ to proceed to the authentication and key agreement phase.

5.4. Mutual Authentication and Pairwise Key Agreement Phase

This phase establishes mutual authentication among the vehicle $V_i$, fog node $F_j$, and cloud server $CS$, while simultaneously generating independent session keys for each communication link. This process is depicted in Figure 6 following the login phase, and the detailed explanation of each step is as follows:

S1: 

$V_i$ begins the phase by generating a current timestamp $T{S}_1$ and a random number $n_1$. It then computes its secret value $z_i=E{Z}_i\oplus h(R{E}_i\parallel VI{D}_i\parallel VP{W}_i)$ and a temporary identity $TVI{D}_i=VI{D}_i\oplus h(n_1\parallel z_i\parallel T{S}_1)$. To ensure quantum resistance, $V_i$ samples $\{r_i,t_i^1,t_i^2\}\leftarrow {\chi }^k$ and a secret message $m_i\leftarrow {\{0,1\}}^k$ to generate an MLWE-based ciphertext $c_i=(u_i,v_i)$, where $u_i=A^T·r_i+t_i^1$ and $v_i=P^T·r_i+t_i^2+Encode\left(m_i\right)$. Subsequently, it derives $k_i=h\left(m_i\right)$ and the session key $S{K}_{VCS}=h(VI{D}_i\parallel z_i\parallel n_1\parallel k_i)$. Finally, $V_i$ computes verification tokens $V_{VCS}$ and $V_{VF}$, and a masked random value $N_1=n_1\oplus h(k_i\parallel z_i)$, then sends $\{TVI{D}_i,c_i,V_{VCS},V_{VF},N_1,T{S}_1\}$ to $F_j$.

S2: 

Upon receiving the message, $F_j$ verifies the freshness of $T{S}_1$. It then generates a new timestamp $T{S}_2$ and a random number $n_2$, and saves $V_{VF}$ and $T{S}_1$. $F_j$ computes its physical response $R{E}_j^{\ast }=PUF\left(C{H}_j\right)$ and reconstructs $q_j=E{Q}_j\oplus h(FI{D}_j\parallel R{E}_j^{\ast })$. Subsequently, it computes the verification token $V_{FCS}=h(FI{D}_j\parallel V_{VCS}\parallel q_j\parallel n_2\parallel T{S}_2)$ and the masked random value $N_2=n_2\oplus h(q_j\parallel T{S}_2)$. Finally, $F_j$ forwards $\{TVI{D}_i,FI{D}_j,c_i,V_{VCS},V_{FCS},N_1,N_2,T{S}_1,T{S}_2\}$ to the $CS$.

S3: 

The $CS$ verifies the freshness of $T{S}_2$ and proceeds to compute $z_i^{\ast }=Z_i\oplus h(r_i\parallel s)$. It decrypts the message $m_i^{\ast }=Decode(v_i-u_i^T·s)$ and computes $k_i^{\ast }=h\left(m_i^{\ast }\right)$. Using these, the $CS$ reconstructs $n_1^{\ast }=N_1\oplus h(k_i^{\ast }\parallel z_i^{\ast })$ and the vehicle’s identity $VI{D}_i^{\ast }=TVI{D}_i\oplus h(n_1^{\ast }\parallel z_i^{\ast }\parallel T{S}_1)$. It then derives the session key $S{K}_{CSV}=h(VI{D}_i^{\ast }\parallel z_i^{\ast }\parallel n_1^{\ast }\parallel k_i^{\ast })$ and the verification token $V_{VCS}^{\ast }=h(VI{D}_i^{\ast }\parallel S{K}_{CSV}\parallel T{S}_1)$, and verifies if $V_{VCS}\stackrel{?}{=}{V}_{VCS}^{\ast }$. Next, the $CS$ computes $q_j^{\ast }=Q_j\oplus h(r_j\parallel s)$ and $n_2^{\ast }=N_2\oplus h(q_j^{\ast }\parallel T{S}_2)$, then checks $V_{FCS}\stackrel{?}{=}{V}_{FCS}^{\ast }$ where $V_{FCS}^{\ast }=h(FI{D}_j\parallel V_{VCS}^{\ast }\parallel q_j^{\ast }\parallel n_2^{\ast }\parallel T{S}_2)$. After successful verification, the $CS$ generates $T{S}_3$ and random numbers $n_3,n_4$. It computes the session key $S{K}_{CSF}=h(FI{D}_j\parallel q_j^{\ast }\parallel n_2^{\ast }\parallel n_3\parallel T{S}_3)$ and the corresponding token $V_{CSF}=h(FI{D}_j\parallel S{K}_{CSF}\parallel T{S}_3)$. Finally, it computes $N_3=n_3\oplus h(n_2^{\ast }\parallel q_j^{\ast })$, $N{Z}_j=h(n_1\left|\right|z_i)\oplus h(n_3\parallel S{K}_{CSF})$, $V_{CSV}=h(VI{D}_i\parallel S{K}_{CSV}\parallel n_4\parallel T{S}_3)$, and $N_4=n_4\oplus h(k_i^{\ast }\parallel S{K}_{CSV})$, then returns the response message to $F_j$.

S4: 

$F_j$ verifies $T{S}_3$ and computes $n_3^{\ast }=N_3\oplus h(n_2\parallel q_j)$ to derive $S{K}_{FCS}=h(FI{D}_j\parallel q_j\parallel n_2\parallel n_3^{\ast }\parallel T{S}_3)$. It then verifies $V_{CSF}\stackrel{?}{=}{V}_{CSF}^{\ast }$, where $V_{CSF}^{\ast }=h(FI{D}_j\parallel S{K}_{FCS}\parallel T{S}_3)$. Following this, $F_j$ reconstructs $h{(n_1\parallel z_i)}^{\ast }=N{Z}_j\oplus h(n_3^{\ast }\parallel S{K}_{FCS})$ and verifies $V_{VF}\stackrel{?}{=}{V}_{VF}^{\ast }$ using $V_{VF}^{\ast }=h(TVI{D}_i\parallel FI{D}_j\parallel h{(n_1\parallel z_i)}^{\ast }\parallel T{S}_1)$. After validation, $F_j$ generates $T{S}_4$, computes the session key $S{K}_{FV}=h(TVI{D}_i\parallel FI{D}_j\parallel h{(n_1\parallel z_i)}^{\ast }\parallel T{S}_4)$ and the token $V_{FV}=h(TVI{D}_i\parallel S{K}_{FV}\parallel T{S}_4)$, and sends $\{TVI{D}_i,FI{D}_j,V_{CSV},N_4,V_{FV},T{S}_3,T{S}_4\}$ to $V_i$.

S5: 

$V_i$ verifies $T{S}_4$ and computes $S{K}_{VF}=h(TVI{D}_i\parallel FI{D}_j\parallel h(n_1\parallel z_i)\parallel T{S}_4)$ to check $V_{FV}\stackrel{?}{=}{V}_{FV}^{\ast }$, where $V_{FV}^{\ast }=h(TVI{D}_i\parallel S{K}_{VF}\parallel T{S}_4)$. Subsequently, it reconstructs $n_4^{\ast }=N_4\oplus h(k_i\parallel S{K}_{VCS})$ and verifies the cloud server by checking $V_{CSV}\stackrel{?}{=}{V}_{CSV}^{\ast }$ where $V_{CSV}^{\ast }=h(VI{D}_i\parallel S{K}_{VCS}\parallel n_4^{\ast }\parallel T{S}_3)$. Upon successful completion of all verifications, secure session keys are established between all parties.

6. Security Analysis

6.1. Formal Analysis Using AVISPA

To formally verify the security of the proposed scheme, this paper utilizes Automated Validation of Internet Security Protocols and Applications (AVISPA) [41], which has been widely adopted for the formal analysis of authentication and key agreement protocols. AVISPA has been proven to be an effective tool for verifying security properties in various existing studies [42,43]. By modeling the protocol execution processes and adversary interactions, it enables the analysis of security goal violations under representative attack scenarios, such as replay and man-in-the-middle attacks.

The tool operates based on code written in HLPSL (High-Level Protocol Specification Language) and supports four backend verification engines. These engines include the constraint-logic-based attack searcher (CL-AtSe), the on-the-fly model checker (OFMC), the SAT-based model checker (SATMC), and the tree automata-based protocol analyzer (TA4SP). In the process of evaluating security properties, the HLPSL code is first translated into an intermediate format through the HLPSL2IF translator, and subsequently, the backend models analyze this format to perform formal verification.

In this study, we selected the OFMC and CL-AtSe backend modules, which are the most commonly used engines, to simulate the security of the proposed scheme. Figure 7 presents the simulation result reports, confirming that both backend models received a “SAFE” status in their summary results. These formal verification results demonstrate that the proposed scheme is secure against major security threats, including replay and man-in-the-middle attacks.

6.2. Formal Analysis Using the RoR Model

We prove the semantic security of the proposed scheme using the RoR model [44], which has been widely adopted in prior works to analyze the security of authentication protocols [45,46]. In this model, the adversary $\mathcal{A}$ interacts with protocol instances to distinguish the session key $SK$ from a random value. Each participant instance is denoted by $p^t$, where $p\in \{V_i,F_j,CS\}$ represents the entity identity and t is the instance number.

In the RoR model, the adversary $\mathcal{A}$ is a probabilistic polynomial-time (PPT) algorithm that has complete control over the communication network. To simulate real-world threats, $\mathcal{A}$ can issue several oracle queries as follows.

• $\mathbf{Execute}(p_{V_i}^{t_1},p_{F_j}^{t_2},p_{CS})$: Simulates passive eavesdropping, where $\mathcal{A}$ collects all exchanged messages during the protocol run.
• $\mathbf{Corrupt}\left(p_{V_i}^{t_1}\right)$: Grants $\mathcal{A}$ access to the internal memory of the vehicle $V_i$, exposing stored parameters such as $\{VI{D}_i,C{H}_i,E{Z}_i,Aut{h}_i\}$.
• $\mathbf{Send}(p^t,M)$: Models active attacks by letting $\mathcal{A}$ send forged messages M to any participant instance and observe the output.
• $\mathbf{Test}\left({\mathrm{\Pi }}^{\ast }\right)$: Used once to challenge the security of the protocol. If $c=1$, the real session key $SK$ is returned; if $c=0$, a random string of the same length is returned. $\mathcal{A}$ must guess the value of c.

Let $Adv\left(\mathcal{A}\right)$ denote the advantage of $\mathcal{A}$ in distinguishing the session key from a random string. To evaluate this advantage, we analyze a sequence of games $G_i$ for $i\in \{0,1,2,3,4\}$, where $Pr\left[Suc{c}_{G_i}\right]$ represents the probability that $\mathcal{A}$ successfully guesses the bit c in each game $G_i$. The progression of these games is defined as follows:

• $G_0$: This is the initial game where $\mathcal{A}$ has no prior information, representing a real attack environment. By definition, the advantage of $\mathcal{A}$ is expressed as:

  $$Adv\left(\mathcal{A}\right)=|2Pr\left[Suc{c}_{G_0}\right]-1|.$$

  (1)
• $G_1$: $\mathcal{A}$ issues $Execute$ queries to eavesdrop on transcripts. Since all session keys ($S{K}_{VF},S{K}_{VCS},S{K}_{FCS}$) are derived from random nonces $n_1,n_2,n_3$ and the MLWE-based secret $k_i$, $\mathcal{A}$ cannot deduce the keys from passive observations. Thus,

  $$Pr\left[Suc{c}_{G_1}\right]=Pr\left[Suc{c}_{G_0}\right].$$

  (2)
• $G_2$: $\mathcal{A}$ is permitted to perform $Send$ and $Hash$ queries. The only feasible way for $\mathcal{A}$ to correctly guess c by forging tokens or compromising the session key is to find a hash collision in $h(·)$. According to the birthday bound:

  $$|Pr\left[Suc{c}_{G_2}\right]-Pr\left[Suc{c}_{G_1}\right]|\le {\displaystyle \frac{q_h^2}{2\left|Hash\right|}}.$$

  (3)
• $G_3$: $\mathcal{A}$ invokes the $Corrupt$ query to obtain parameters from $V_i$’s memory, such as $\{VI{D}_i,C{H}_i,E{Z}_i,Aut{h}_i\}$. However, due to the physical unclonability of the PUF, $\mathcal{A}$ cannot compute the exact physical response $R{E}_i=PUF\left(C{H}_i\right)$ even with the knowledge of $C{H}_i$. The advantage gained from PUF-related challenges is bounded as:

  $$|Pr\left[Suc{c}_{G_3}\right]-Pr\left[Suc{c}_{G_2}\right]|\le {\displaystyle \frac{q_p^2}{2\left|PUF\right|}}.$$

  (4)
• $G_4$: $\mathcal{A}$ may invoke the $Corrupt$ query to obtain the parameters stored in the vehicle’s memory. However, without knowledge of the user credentials such as $VI{D}_i,VP{W}_i$, $\mathcal{A}$ cannot recover the secret $z_i$, making it impossible to derive the session keys. Therefore:

  $$|Pr\left[Suc{c}_{G_4}\right]-Pr\left[Suc{c}_{G_3}\right]|\le {\displaystyle \frac{q_{send}}{|D_{VID}\left|\right|D_{VPW}|}}.$$

  (5)
• $G_5$: Finally, $\mathcal{A}$’s success depends on inverting the MLWE-based ciphertext $c_i$ to retrieve the secret $k_i$, which is computationally hard under the MLWE assumption:

  $$|Pr\left[Suc{c}_{G_5}\right]-Pr\left[Suc{c}_{G_4}\right]|\le Ad{v}_{\mathcal{A}}^{MLWE}.$$

  (6)

By applying the triangle inequality to the above equation:

$$\begin{array}{c}\hfill {\displaystyle \frac{1}{2}}Adv\left(\mathcal{A}\right)\\ \hfill & =|Pr\left[Suc{c}_{G_1}\right]-Pr\left[Suc{c}_{G_5}\right]|\hfill \\ \hfill & \le |Pr\left[Suc{c}_{G_1}\right]-Pr\left[Suc{c}_{G_2}\right]|+|Pr\left[Suc{c}_{G_2}\right]-Pr\left[Suc{c}_{G_3}\right]|\hfill \\ \hfill & +|Pr\left[Suc{c}_{G_3}\right]-Pr\left[Suc{c}_{G_4}\right]|+|Pr\left[Suc{c}_{G_4}\right]-Pr\left[Suc{c}_{G_5}\right]|\hfill \\ \hfill & \le {\displaystyle \frac{q_h^2}{2\left|Hash\right|}}+{\displaystyle \frac{q_p^2}{2\left|PUF\right|}}+{\displaystyle \frac{q_{send}}{|D_{VID}\left|\right|D_{VPW}|}}+Ad{v}_{\mathcal{A}}^{MLWE}.\hfill \end{array}$$

(7)

Hence, the adversary’s total advantage is bounded as:

$$Adv\left(A\right)\le {\displaystyle \frac{q_h^2}{2\left|Hash\right|}}+{\displaystyle \frac{q_p^2}{2\left|PUF\right|}}+{\displaystyle \frac{q_{send}}{|D_{VID}\left|\right|D_{VPW}|}}+Ad{v}_{\mathcal{A}}^{MLWE}.$$

(8)

Therefore, the proposed scheme is semantically secure under the RoR model, assuming the hardness of the MLWE problem and the physical unclonability of the PUF.

6.3. Formal Analysis Using the BAN Logic

We conduct a formal security analysis using BAN logic [47] to demonstrate that the vehicle $V_i$, fog node $F_j$, and cloud server $CS$ achieve mutual authentication and establish secure session keys.

Table 2. BAN logic notations.

Notation	Description
${\rho }_1,{\rho }_2$	Two principals
${\sigma }_1,{\sigma }_2$	Two statements
${\rho }_1|$≡${\sigma }_1$	${\rho }_1$  believes  ${\sigma }_1$
${\rho }_1|$∼${\sigma }_1$	${\rho }_1$ once said ${\sigma }_1$
${\rho }_1$⇒${\sigma }_1$	${\rho }_1$  controls  ${\sigma }_1$
${\rho }_1$⊲${\mu }_1$	${\rho }_1$  receives  ${\sigma }_1$
$\#{\sigma }_1$	${\sigma }_1$ is fresh
${\left\{{\sigma }_1\right\}}_K$	${\sigma }_1$ is encrypted with K
${\rho }_1\stackrel{K}{\leftrightarrow }$${\rho }_2$	${\rho }_1$ and ${\rho }_2$ have shared key K
$SK$	The session key

summarizes the key notations of BAN Logic employed in this study.

6.3.1. BAN Logic Rules

BAN logic rules used in this paper are as follows.

• Message meaning rule (MMR):

  $${\displaystyle \frac{{\rho }_1\mid \equiv {\rho }_1\stackrel{K}{\leftrightarrow }{\rho }_2,{\rho }_1⊲{\left\{{\sigma }_1\right\}}_K}{{\rho }_1\mid \equiv {\rho }_2\mid \sim {\sigma }_1}}$$
• Nonce verification rule (NVR):

  $${\displaystyle \frac{{\rho }_1\mid \equiv \#\left({\sigma }_1\right),{\rho }_1\mid \equiv {\rho }_2\mid \sim {\sigma }_1}{{\rho }_1\mid \equiv {\rho }_2\mid \equiv {\sigma }_1}}$$
• Jurisdiction rule (JR):

  $${\displaystyle \frac{{\rho }_1\mid \equiv {\rho }_2\mid ⟹{\sigma }_1,{\rho }_1\mid \equiv {\rho }_2\mid \equiv {\sigma }_1}{{\rho }_1\mid \equiv {\sigma }_1}}$$
• Belief rule (BR):

  $${\displaystyle \frac{{\rho }_1\mid \equiv ({\sigma }_1,{\sigma }_2)}{{\rho }_1\mid \equiv {\sigma }_1}}$$
• Freshness rule (FR):

  $${\displaystyle \frac{{\rho }_1\mid \equiv \#\left({\sigma }_1\right)}{{\rho }_1\mid \equiv \#({\sigma }_1,{\sigma }_2)}}$$

6.3.2. Goals

Goal 1: 

$V_i\mid \equiv V_i\stackrel{S{K}_{VF}}{\leftrightarrow }{F}_j$

Goal 2: 

$V_i\mid \equiv V_i\stackrel{S{K}_{VCS}}{\leftrightarrow }CS$

Goal 3: 

$V_i\mid \equiv F_j\mid \equiv V_i\stackrel{S{K}_{VF}}{\leftrightarrow }{F}_j$

Goal 4: 

$V_i\mid \equiv CS\mid \equiv V_i\stackrel{S{K}_{VCS}}{\leftrightarrow }CS$

Goal 5: 

$F_j\mid \equiv F_j\stackrel{S{K}_{FV}}{\leftrightarrow }{V}_i$

Goal 6: 

$F_j\mid \equiv F_j\stackrel{S{K}_{FCS}}{\leftrightarrow }CS$

Goal 7: 

$F_j\mid \equiv V_i\mid \equiv F_j\stackrel{S{K}_{FV}}{\leftrightarrow }{V}_i$

Goal 8: 

$F_j\mid \equiv CS\mid \equiv F_j\stackrel{S{K}_{FCS}}{\leftrightarrow }CS$

Goal 9: 

$CS\mid \equiv CS\stackrel{S{K}_{CSV}}{\leftrightarrow }{V}_i$

Goal 10: 

$CS\mid \equiv CS\stackrel{S{K}_{CSF}}{\leftrightarrow }{F}_j$

Goal 11: 

$CS\mid \equiv V_i\mid \equiv CS\stackrel{S{K}_{CSV}}{\leftrightarrow }{V}_i$

Goal 12: 

$CS\mid \equiv F_j\mid \equiv CS\stackrel{S{K}_{CSF}}{\leftrightarrow }{F}_j$

6.3.3. Idealized Forms

In BAN logic, complex cryptographic operations are abstracted into logical relationships in order to focus on the secure exchange of message origin and belief. In the proposed protocol, the vehicle $V_i$ generates an MLWE-based ciphertext $c_i$ to securely encapsulate a random message $m_i$, from which a shared secret $k_i=h\left(m_i\right)$ is derived. Since the underlying CRYSTALS-Kyber KEM guarantees IND-CCA2 security, only the legitimate CS possessing the master secret key s can correctly decapsulate $c_i$ and recover $k_i$.

From the perspective of formal verification, $k_i$ therefore functions as a securely established shared secret between $V_i$ and $CS$ (denoted as $V_i\stackrel{k_i}{\leftrightarrow }CS$ in the assumptions). Accordingly, in the idealized form, the algebraically complex MLWE ciphertext $c_i$ can be abstracted as a message protected by the shared secret $k_i$ (e.g., ${\left\{n_1\right\}}_{k_i}$). In contrast, parameters derived from $z_i$ are treated as values masked using the vehicle’s local secret rather than as encryption keys. For example, the XOR-masked parameter $N_1=n_1\oplus h(k_i\parallel z_i)$ is logically interpreted as a protected value associated with $k_i$ and $z_i$.

This abstraction enables BAN logic to rigorously evaluate the soundness of mutual authentication and key agreement without being entangled in the complexity of the underlying algebraic lattice structure.

Msg1: 

$V_i\to F_j:{\left\{VI{D}_i\right\}}_{z_i},{\left\{n_1\right\}}_{k_i},T{S}_1$

Msg2: 

$F_j\to CS:Ms{g}_1,{\left\{n_2\right\}}_{q_j},T{S}_2$

Msg3: 

$CS\to F_j:{\left\{n_3\right\}}_{n_2},{\left\{n_4\right\}}_{S{K}_{CSV}},T{S}_3$

Msg4: 

$F_j\to V_i:{\left\{n_4\right\}}_{S{K}_{CSV}},T{S}_3,T{S}_4$

6.3.4. Assumptions

$A_1$:

$V_i\mid \equiv \#(T{S}_3,T{S}_4)$

$A_2$:

$F_j\mid \equiv \#(T{S}_1,T{S}_3)$

$A_3$:

$CS\mid \equiv \#(T{S}_1,T{S}_2)$

$A_4$:

$V_i\mid \equiv V_i\stackrel{z_i,k_i}{\leftrightarrow }CS$

$A_5$:

$F_j\mid \equiv F_j\stackrel{q_j}{\leftrightarrow }CS$

$A_6$:

$CS\mid \equiv V_i\stackrel{z_i,k_i}{\leftrightarrow }CS$

$A_7$:

$CS\mid \equiv F_j\stackrel{q_j}{\leftrightarrow }CS$

$A_8$:

$V_i\mid \equiv F_j\Rightarrow \left(V_i\stackrel{{SK}_{VF}}{\leftrightarrow }{F}_j\right)$

$A_9$:

$V_i\mid \equiv CS\Rightarrow \left(V_i\stackrel{{SK}_{VCS}}{\leftrightarrow }CS\right)$

$A_{10}$:

$F_j\mid \equiv V_i\Rightarrow \left(F_j\stackrel{{SK}_{FV}}{\leftrightarrow }{V}_i\right)$

$A_{11}$:

$F_j\mid \equiv CS\Rightarrow \left(F_j\stackrel{{SK}_{FCS}}{\leftrightarrow }CS\right)$

$A_{12}$:

$CS\mid \equiv V_i\Rightarrow \left(CS\stackrel{{SK}_{CSV}}{\leftrightarrow }{V}_i\right)$

$A_{13}$:

$CS\mid \equiv F_j\Rightarrow \left(CS\stackrel{{SK}_{CSF}}{\leftrightarrow }{F}_j\right)$

6.3.5. BAN Logic Proof

Proof. 

The formal analysis is conducted through the detailed steps as follows.

Step 1: 

Based on $Ms{g}_1$, $F_j$ first receives the message from $V_i$.

$$S_1:F_j◁{\left\{VI{D}_i\right\}}_{z_i},{\left\{n_1\right\}}_{k_i},T{S}_1$$

Step 2: 

$F_j$ verifies $T{S}_1$ and forwards it to $CS$ via $Ms{g}_2$. Then $CS$ receives the relayed message. Applying the MMR with $A_6$ and $A_7$:

$$\begin{array}{c}{S}_2:CS\mid \equiv V_i\mid \sim (VI{D}_i,n_1,T{S}_1)\\ S_3:CS\mid \equiv F_j\mid \sim (n_2,T{S}_2)\end{array}$$

Step 3: 

Applying the FR with $A_3$ and the NVR to $S_2$ and $S_3$:

$$\begin{array}{c}{S}_4:CS\mid \equiv V_i\mid \equiv (VI{D}_i,n_1,T{S}_1)\\ S_5:CS\mid \equiv F_j\mid \equiv (n_2,T{S}_2)\end{array}$$

Step 4: 

Since $CS$ can now verify the parameters for $S{K}_{CSV}$ and $S{K}_{CSF}$:

$$\begin{array}{c}{S}_6:CS\mid \equiv V_i\mid \equiv CS\stackrel{{SK}_{CSV}}{\leftrightarrow }{V}_i \mathbf{(}\mathbf{Goal}\mathbf{11}\mathbf{)}\\ S_7:CS\mid \equiv F_j\mid \equiv CS\stackrel{S{K}_{CSF}}{\leftrightarrow }{F}_j \mathbf{(}\mathbf{Goal}\mathbf{12}\mathbf{)}\end{array}$$

Step 5: 

Applying the JR with $A_{12}$ and $A_{13}$ to $S_6$ and $S_7$:

$$\begin{array}{c}{S}_8:CS\mid \equiv CS\stackrel{S{K}_{CSV}}{\leftrightarrow }{V}_i \mathbf{(}\mathbf{Goal}\mathbf{9}\mathbf{)}\\ S_9:CS\mid \equiv CS\stackrel{S{K}_{CSF}}{\leftrightarrow }{F}_j \mathbf{(}\mathbf{Goal}\mathbf{10}\mathbf{)}\end{array}$$

Step 6: 

Based on $Ms{g}_3$, $F_j$ receives the session key information and verifies $T{S}_3$. Applying the MMR with $A_5$ and the NVR with $A_2$:

$$S_{10}:F_j\mid \equiv CS\mid \equiv (n_3,S{K}_{CSF},T{S}_3)$$

Step 7: 

$F_j$ accepts $CS$’s jurisdiction. Applying the JR with $A_{11}$:

$$\begin{array}{c}{S}_{11}:F_j\mid \equiv F_j\stackrel{S{K}_{FCS}}{\leftrightarrow }CS \mathbf{(}\mathbf{Goal}\mathbf{6}\mathbf{)}\\ S_{12}:F_j\mid \equiv CS\mid \equiv F_j\stackrel{S{K}_{FCS}}{\leftrightarrow }CS \mathbf{(}\mathbf{Goal}\mathbf{8}\mathbf{)}\end{array}$$

Step 8: 

$F_j$ computes $S{K}_{FV}$ using the verified $h\left(n_1\right|\left|z_i\right)$. Since it confirmed $V_i$’s fresh participation:

$$S_{13}:F_j\mid \equiv F_j\stackrel{S{K}_{FV}}{\leftrightarrow }{V}_i\mathbf{(}\mathbf{Goal}\mathbf{5}\mathbf{)}$$

$$S_{14}:F_j\mid \equiv V_i\mid \equiv F_j\stackrel{S{K}_{FV}}{\leftrightarrow }{V}_i\mathbf{(}\mathbf{Goal}\mathbf{7}\mathbf{)}$$

Step 9: 

Based on $Ms{g}_4$, $V_i$ receives the response and verifies $T{S}_4$. Applying the MMR with $A_4$ and the NVR with $A_1$:

$$S_{15}:V_i\mid \equiv CS\mid \equiv (n_4,S{K}_{CSV},T{S}_3)$$

Step 10: 

$V_i$ accepts $CS$’s authority. Applying the JR with $A_9$:

$$S_{16}:V_i\mid \equiv V_i\stackrel{S{K}_{VCS}}{\leftrightarrow }CS\mathbf{(}\mathbf{Goal}\mathbf{2}\mathbf{)}$$

$$S_{17}:V_i\mid \equiv CS\mid \equiv V_i\stackrel{S{K}_{VCS}}{\leftrightarrow }CS\mathbf{(}\mathbf{Goal}\mathbf{4}\mathbf{)}$$

Step 11: 

Finally, $V_i$ verifies $V_{FV}$ using the computed $S{K}_{VF}$:

$$S_{18}:V_i\mid \equiv V_i\stackrel{S{K}_{VF}}{\leftrightarrow }{F}_j\mathbf{(}\mathbf{Goal}\mathbf{1}\mathbf{)}$$

$$S_{19}:V_i\mid \equiv F_j\mid \equiv V_i\stackrel{S{K}_{VF}}{\leftrightarrow }{F}_j\mathbf{(}\mathbf{Goal}\mathbf{3}\mathbf{)}$$

□

6.4. Informal Analysis

6.4.1. Replay Attack

A malicious adversary $\mathcal{A}$ may capture transmitted messages and attempt to replay them. However, each transmitted message includes a timestamp $T{S}_n$, and a fresh random nonce $n_n$ is generated for every session to be used in verification messages and key generation. Therefore, even if $\mathcal{A}$ captures and replays a message, it will fail the verification process (e.g., due to the freshness check $|T{S}_{curr}-T{S}_n|<\delta$). Thus, the proposed scheme is resilient to replay attacks.

6.4.2. Man-in-the-Middle Attack

A malicious adversary $\mathcal{A}$ may attempt to intercept and manipulate messages exchanged between $V_i,F_j,$ and $CS$. However, all critical parameters are protected by MLWE-based ciphertexts $c_i$ and hash-based authentication tokens. To forge a valid message, $\mathcal{A}$ would need to know the shared secrets $z_i,q_j,$ or the master secret key s of the $CS$, which is computationally infeasible. Consequently, $\mathcal{A}$ cannot gain any advantage within the session, making the proposed scheme resilient to man-in-the-middle attacks.

6.4.3. Impersonation Attack

• Vehicle impersonation: To impersonate $V_i$, $\mathcal{A}$ must generate $V_{VCS}=h(VI{D}_i \Vert S{K}_{VCS } \Vert T{S}_1)$. This requires $S{K}_{VCS}$, which depends on $z_i$ and the MLWE secret $k_i$. Without the physical PUF device and $VP{W}_i$, it is impossible to calculate these values.
• Fog node impersonation: An adversary must construct $V_{FCS}=h(FI{D}_j \Vert V_{VCS} \Vert q_j \Vert n_2 \Vert T{S}_2)$. This is impossible without $q_j$, which is derived through the physical response $R{E}_j$ unique to $F_j$.
• Cloud Server impersonation: Impersonating the $CS$ requires the master secret key s to decrypt $c_i$ and calculate $S{K}_{CSV}$. Since $V_i$ performs a final verification of the $CS$’s legitimacy through $V_{CSV}$, $\mathcal{A}$ cannot forge a valid response.

6.4.4. Insider Attack

A legally registered malicious user $\mathcal{A}$ possesses their own $\{C{H}_{\mathcal{A}},E{Z}_{\mathcal{A}},Aut{h}_{\mathcal{A}}\}$, but cannot derive the secret keys ($s,z_i,q_j$) of other users or the server. Since MLWE-based KEM and PUF-based secrets are uniquely assigned to each hardware and identifier, $\mathcal{A}$ gains no advantage in compromising other users’ sessions even if they possess protocol parameters.

6.4.5. Privileged Insider Attack

Assuming $\mathcal{A}$ is an insider with administrative privileges at the $CS$, they may access registration messages $\{VI{D}_i,FI{D}_j\}$ and the database $\{VI{D}_i,Z_i,r_i\}$. However, sensitive credentials such as passwords ($VP{W}_i$) and unique hardware responses ($R{E}_i,R{E}_j$) are never transmitted to the server; they are processed locally within the user’s device. Since $C{H}_i$ and $z_i$ are hashed with local secrets ($VP{W}_i,R{E}_i$) before storage, the insider cannot derive the original password or hardware secrets without the $CS$ master key. Thus, the scheme is resilient to privileged insider attacks.

6.4.6. Vehicle Theft Attack

Even if a vehicle is stolen and the stored data $\{VI{D}_i,C{H}_i,E{Z}_i,Aut{h}_i\}$ is extracted, $\mathcal{A}$ cannot obtain $VP{W}_i$. The secret value $z_i$ is protected within $E{Z}_i$ by the hash of $R{E}_i$ and $VP{W}_i$. Without the correct password, the $Aut{h}_i$ verification cannot be passed, nor can $z_i$ be reconstructed, preventing the initiation of a session. Thus, the proposed scheme is resilient to vehicle theft attacks.

6.4.7. Table Leakage Attack

The system remains secure even if the $CS$ database or the local memory of $F_j$ is leaked. Stored values are secured through the hashes of the master secret key s or the PUF response $RE$. Without s or the physical hardware, the leaked table entries cannot be used to forge authentication tokens. Therefore, the proposed scheme is resilient to table leakage attacks.

6.4.8. Session Key Disclosure Attack

The final session keys ($S{K}_{VCS},S{K}_{FCS},S{K}_{VF}$) are generated through a combination of $VID,z_i,q_j,$ nonces, and the value $k_i$ derived from MLWE. Even an adversary $\mathcal{A}$ who captures all public messages cannot obtain $k_i$ without solving the MLWE problem (decrypting the lattice-based ciphertext) which requires s. Since $k_i$ is an essential component of the session key hash, the session key remains secure. Thus, the proposed scheme is resilient to session key disclosure attacks.

6.4.9. Key Compromise Impersonation Attack

Even if the long-term secret $z_i$ of $V_i$ is exposed, an adversary cannot impersonate the $CS$ to $V_i$. Generating $S{K}_{VCS}$ requires $k_i$, which is derived from the master secret key s of the $CS$. Consequently, $V_i$ will not accept a forged $V_{CSV}$ sent by $\mathcal{A}$. Therefore, the proposed scheme is resilient to KCI attacks.

6.4.10. Key Freshness

In this protocol, $V_i,F_j,$ and $CS$ each generate new independent nonces ($n_1,n_2,n_3,n_4$) for every session to participate in the session key ($S{K}_{VCS},S{K}_{FCS},S{K}_{VF}$) generation. Furthermore, through the MLWE-based KEM structure, a fresh random vector $r_i$ and error vector $t_i$ are sampled each time to derive the shared value $k_i$. Due to this dynamic combination of parameters, all generated session keys are statistically independent of previous keys, preventing vulnerabilities related to key reuse. Thus, the scheme guarantees strong key freshness.

6.4.11. Known Session Key Attack Resistance

Even if an adversary $\mathcal{A}$ obtains a session key $SK$ used in a specific session, they cannot derive the keys for previous or subsequent sessions. This is because each entity generates independent fresh nonces ($n_1,n_2,n_3,n_4$) in every session, and the MLWE-based random structure operates independently each time, ensuring key un-linkability.

6.4.12. Quantum Resistance

Traditional ECC or RSA-based authentication protocols are vulnerable to Shor’s algorithm, which can solve discrete logarithm and integer factorization problems in polynomial time on a quantum computer. However, this protocol is designed based on the MLWE problem, a standard in PQC. The ciphertext $c_i=(u_i,v_i)$ generated by $V_i$ is based on computationally hard lattice problems, which are currently evaluated as being unsolvable even by known quantum algorithms. Thus, the proposed protocol provides strong quantum resistance.

6.4.13. Anonymity

The proposed protocol ensures that the real identity $VI{D}_i$ of the vehicle is never exposed over public channels. During the authentication process, the vehicle $V_i$ utilizes a one-time pseudonym $TVI{D}_i$ instead of $VI{D}_i$, which is generated by masking the real identity with a hash function involving the secret value $z_i$ and a random nonce $n_1$. Only the $CS$, which possesses the legitimate master secret key s, can recover the real identity from $TVI{D}_i$. An adversary $\mathcal{A}$ cannot discern the user’s actual identity even if they intercept the transmitted messages. Thus, the proposed scheme fully guarantees user anonymity.

6.4.14. Untracability

Untraceability implies that an adversary cannot link multiple messages originating from different sessions to the same user. In the proposed protocol, since the random nonce $n_1$ and the timestamp $T{S}_1$ used to generate $TVI{D}_i$ are refreshed in every session, a different $TVI{D}_i$ is transmitted each time, even for the same vehicle. An adversary $\mathcal{A}$ cannot computationally derive any correlation between $TVI{D}_i$ from different sessions based solely on public parameters. Consequently, it is impossible to trace the vehicle’s movement trajectory or communication history, thereby satisfying the requirement for untraceability.

6.4.15. Mutual Authentication

The proposed protocol supports step-by-step mutual authentication between the three communicating parties.

• Authentication between Vehicle and CS: The $CS$ authenticates $V_i$ by comparing the received $V_{VCS}$ with its calculated $V_{VCS}^{\ast }$, while $V_i$ confirms the legitimacy of the $CS$ by verifying $V_{CSV}$ received from the $CS$.
• Authentication between Fog and CS: The $CS$ verifies $V_{FCS}$ from $F_j$, and $F_j$ authenticates the $CS$ through $V_{CSF}$ sent by the $CS$.
• Authentication between Vehicle and Fog: $F_j$ confirms the intent of $V_i$ through $V_{VF}$, and $V_i$ finally verifies $V_{FV}$ generated by $F_j$.

As a result, all entities verify each other’s legitimacy using shared secrets ($z_i,q_j,s$) and session keys, ensuring secure mutual authentication.

7. Performance Analysis

To evaluate the performance of the proposed scheme, we compare it with related studies [11,12,13,48] that employ similar system model environments.

Table 3. Comparison of system model.

	Number of Keys	Trust Model			Quantum Resistance
		Vehicle	Fog Node	Cloud Server
Geranfar et al. [12]	1	Untrust	Trust	Trust	X
Hegde et al. [11]	1	Untrust	Untrust	Trust	X
Chen et al. [13]	1	Untrust	Untrust	Semi-trust	X
Eftekhari et al. [48]	3	Untrust	Semi-trust	Trust	X
Proposed	3	Untrust	Untrust	Semi-trust	O

summarizes, for each study, the number of session keys generated per authentication session, the trust model in the system architecture, and whether resistance against quantum computing attacks is provided. Here, X indicates that the corresponding feature is not supported, whereas O indicates that the feature is securely provided.

7.1. Comparison of Security Features

In this section, we provide a comparative analysis of the security properties between the proposed protocol and existing key related studies [11,12,13,48], which are summarized in

Table 4. Comparison of security properties.

Security Property	Geranfar et al. [12]	Hegde et al. [11]	Chen et al. [13]	Eftekhari et al. [48]	Proposed
Replay Attack	✓	×	×	✓	✓
Man-in-the-Middle Attack	✓	✓	×	✓	✓
Vehicle Impersonation	×	×	×	✓	✓
Fog node Impersonation	×	×	×	✓	✓
Cloud server Impersonation	✓	×	×	✓	✓
Insider Attack	×	×	×	✓	✓
Privileged Insider Attack	×	×	✓	✓	✓
Vehicle Theft	×	×	✓	✓	✓
Table Leakage attack	×	×	×	✓	✓
Session Key Disclosure	✓	×	×	✓	✓
Guessing Attack	×	✓	×	×	✓
Anonymity	✓	✓	✓	✓	✓
Untracability	×	×	✓	✓	✓
Post-Quantum Security	×	×	×	×	✓
Mutual Authentication	×	×	×	✓	✓

✓: guarantees the security feature, ×: does not guarantee the security feature.

. The results indicate that the proposed protocol satisfies all security requirements, demonstrating resilience not only against common network attacks but also against physical attacks and threats in a quantum computing environment.

The proposed protocol provides differentiated security excellence by utilizing the PUF to effectively block impersonation attacks against all entities, including vehicles, fog nodes, and cloud servers, as well as data leakage attacks in vehicle theft scenarios. Furthermore, unlike existing studies based on ECC, our protocol introduces the lattice-based cryptographic scheme, MLWE, to maintain the confidentiality of session keys even in future attack scenarios involving quantum computers. Additionally, the protocol fully supports untraceability by using a dynamic temporary identity (TVID) that ensures anonymity and is updated every session, preventing adversaries from tracking a user’s movement trajectory.

7.2. Computation Costs Analysis

To evaluate the computational efficiency of the proposed protocol, the execution times of the cryptographic operations used in the protocol were measured. To better reflect realistic environments, a virtualization-based experimental setup was constructed using Oracle VM VirtualBox with two different hardware configurations. The configurations are defined as follows.

• Cloud Server/Fog Node: 4 GB memory, six processor cores, and a CPU Execution Cap set to 100%.
• Vehicle: 4 GB memory, four processor cores, and a CPU Execution Cap set to 40%.

In the Vehicle configuration, the number of processor cores was reduced from six to four and the CPU Execution Cap was limited to 40% compared with the Cloud Server/Fog Node configuration. By combining the reduced core allocation with the execution cap constraint, the Vehicle environment was modeled to provide approximately 27% of the effective processing capability of the Cloud Server/Fog Node environment.

This configuration reflects the practical characteristics of vehicular onboard units (OBUs), which typically rely on low-power ARM-based System-on-Chip (SoC) architectures. Compared with server-grade or infrastructure nodes, such platforms generally provide lower computational performance in terms of core count, clock frequency, and cache capacity [49,50,51]. In addition, prior IoV and vehicular network studies report that vehicular devices operate under strict size, weight, and power constraints, which results in significantly lower computational capability compared to cloud servers or infrastructure nodes [51,52,53].

To quantitatively capture the performance degradation in the Vehicle environment, the SHA-256 hash operation was benchmarked separately. The measured execution time increased from approximately 0.0004 ms in the Cloud Server/Fog Node configuration to approximately 0.0011 ms in the Vehicle configuration, corresponding to an approximately 2.7× slowdown. Since the primary cryptographic operations considered in this study exhibit CPU-bound characteristics, the empirically derived degradation factor was conservatively applied to estimate the execution times of the remaining primitives under the Vehicle configuration.

The implementation was performed using the MIRACL library and the Kyber KEM library. We adopt the parameter set corresponding to CRYSTALS-Kyber512, where $n=256$, $q=3329$, and $k=2$. In accordance with the conventions of existing literature, the execution times for XOR, concatenation operations, and PUF, which have negligibly low computational costs, were ignored [54,55]. Additionally, the fuzzy extractor operation was assumed to be equivalent to an ECC multiplication [56,57].

Table 5. Execution time of cryptographic primitives.

Operation	Symbol	Vehicle Execution Time (ms)	Cloud Server/Fog Node Execution Time (ms)
Hash	$T_h$	0.0011	0.0004
Fuzzy extractor	$T_f$	0.0956	0.0354
ECC multiplication	$T_{em}$	0.0956	0.0354
ECC addition	$T_{ea}$	0.0017	0.0006
Encapsulation	$T_{enc}$	0.0739	0.0274
Decapsulation	$T_{dec}$	0.0943	0.0349

summarizes the notations used for each cryptographic operation and their average execution times.

Although the benchmark experiments were conducted on a desktop environment, the actual execution performance may vary in practical deployments on resource-constrained vehicular OBUs or fog nodes. Nevertheless, these results provide a useful baseline for evaluating the computational overhead of the proposed protocol.

The comparative results summarized in

Table 6. Computation cost comparison.

Schemes	Vehicle (ms)	Fog Node (ms)	Cloud Server (ms)	Total Costs (ms)
Geranfar et al. [12]	$4T_h+4T_{em}\approx 0.3868$	$8T_h+9T_{em}\approx 0.3218$	$4T_h+6T_{em}\approx 0.2140$	$0.9226$
Hegde et al. [11]	$T_f+14T_h+3T_{em}\approx 0.3978$	$T_h+5T_{em}\approx 0.1774$	$6T_h+4T_{em}\approx 0.1440$	$0.7192$
Chen et al. [13]	$4T_h+2T_{em}\approx 0.1956$	$10T_h+T_{em}\approx 0.0394$	$8T_h\approx 0.0032$	$0.2381$
Eftekhari et al. [48]	$14T_h+3T_{em}+T_{ea}\approx 0.3039$	$14T_h+3T_{em}+T_{ea}\approx 0.1124$	$17T_h+3T_{em}+2T_{ea}\approx 0.1142$	$0.5306$
Proposed	$11T_h+T_{enc}\approx 0.0860$	$10T_h\approx 0.0040$	$14T_h+T_{dec}\approx 0.0405$	$0.1304$

and Figure 8 demonstrate that the proposed protocol achieves superior efficiency across all participating entities. The total computation cost of the proposed scheme is 0.1304 ms, representing a reduction of approximately 85.9% compared to the execution time of 0.9226 ms in Geranfar et al. [12], which exhibits the highest cost among the compared schemes. Even when compared with Chen et al. [13], previously the most efficient scheme with a total cost of 0.2381 ms, the proposed protocol achieves an improvement of approximately 45.2%.

In terms of the vehicle $V_i$, the proposed scheme requires $11T_h+T_{enc}=0.0860$ ms of computation time, which is lower than that of all the compared protocols. For the fog node $F_j$, the authentication process only incurs $10T_h=0.0040$ ms, indicating high suitability for real-time edge processing. The computational overhead at the cloud server $CS$ is $14T_h+T_{dec}=0.0405$ ms, which maintains the scalability of the overall system. By replacing computationally expensive ECC-based operations with efficient MLWE-based lattice cryptography and PUF mechanisms, the proposed protocol significantly reduces the computational burden while maintaining strong security guarantees, making it well suited for resource-constrained vehicular network environments.

7.3. Communication Cost Analysis

This subsection evaluates the communication overhead of the proposed protocol under practical vehicular network conditions. We assume a DSRC-based communication environment in which the PHY and MAC layers follow the IEEE 802.11p standard. In this standard, a 10 MHz channel supports transmission rates ranging from 3 Mbps to 27 Mbps [58].

According to the IEEE 802.11 specification, the maximum MAC frame body size is 2304 bytes. In the proposed scheme, identifiers and verification values require 32 bytes each, timestamps occupy 4 bytes, and the CRYSTALS-Kyber KEM ciphertext has a size of 768 bytes. Based on these parameters, the message sizes are calculated as follows: $\{TVI{D}_i,c_i,V_{VCS},V_{VF},N_1,T{S}_1\}$ is 900 bytes, $\{TVI{D}_i,FI{D}_j,c_i,V_{VCS},V_{FCS},N_1,N_2,T{S}_1,T{S}_2\}$ is 964 bytes, $\{TVI{D}_i,FI{D}_j,V_{CSF},N_3,N{Z}_j,V_{CSV},N_4,T{S}_3\}$ is 228 bytes, and $\{TVI{D}_i,FI{D}_j,V_{CSV},N_4,V_{FV},T{S}_3,T{S}_4\}$ is 168 bytes. The largest message is therefore 964 bytes, which is well below the MAC frame body limit. Consequently, MAC-layer fragmentation is not required, preventing additional overhead and retransmission delays.

In terms of transmission latency, the largest message (964 bytes) corresponds to 7712 bits. At a PHY data rate of 3 Mbps, the transmission time is approximately 2.57 ms, while it decreases to about 1.29 ms at 6 Mbps. Even when MAC headers and PHY preambles are considered, the overall transmission delay remains within a few milliseconds.

To approximate realistic traffic conditions, we consider a medium-density VANET scenario in which 50 vehicles broadcast authentication-related messages at a frequency of 10 Hz. Under this assumption, each vehicle generates approximately $964\times 10=9640$ bytes per second, corresponding to about 77.1 kbps. The aggregate channel load produced by 50 vehicles is therefore approximately 3.86 Mbps. This corresponds to about 64.3% channel occupancy at a 6 Mbps PHY rate and about 32.1% at a 12 Mbps PHY rate.

In practical deployments, IEEE 802.11p vehicular networks employ congestion control mechanisms such as SAE J2945.1 and ETSI DCC [59], which dynamically adjust transmission rates under high channel load conditions. In addition, the effective channel load perceived by an RSU or fog node may be lower than the theoretical aggregate traffic due to propagation effects and obstacles [60,61]. Therefore, channel utilization is unlikely to reach saturation in realistic environments. Overall, the communication overhead of the proposed scheme remains within the feasible bandwidth capacity of IEEE 802.11p-based DSRC systems in medium-density vehicular scenarios.

7.4. End-to-End Latency

To evaluate the practical applicability of the proposed authentication protocol, we analyze the end-to-end latency required for the entire authentication procedure. The proposed protocol performs mutual authentication among a vehicle $V_i$, a fog node $F_j$, and a cloud server $CS$, while simultaneously establishing session keys between the participating entities. The protocol operates through sequential message exchanges among the vehicle–fog, fog–cloud, cloud–fog, and fog–vehicle entities. Consequently, both the computational delay caused by cryptographic operations and the communication delay due to message transmission contribute to the overall authentication latency. The detailed authentication and key agreement procedure among the vehicle, fog node, and cloud server is described in Section 5.

The end-to-end latency can be estimated by considering both the computation time required for cryptographic operations at each node and the communication delay incurred during message transmission. The computation cost of cryptographic operations is analyzed in Section 7.2, while the communication delay was partially evaluated in Section 7.3. However, the previous analysis only considered the largest message size. Therefore, in this section, we calculate the transmission delay for all messages exchanged in the protocol and combine them with the computation cost in order to quantitatively estimate the overall end-to-end authentication latency.

According to the message exchange procedure described in Section 5, the authentication process consists of four communication stages: message transmission from the vehicle to the fog node, forwarding from the fog node to the cloud server, the response from the cloud server to the fog node, and finally the delivery of the response from the fog node back to the vehicle.

Accordingly, the total end-to-end latency $T_{E2E}$ can be approximated as

$$T_{E2E}\approx T_{V\to F}+T_{F\to CS}+T_{CS\to F}+T_{F\to V}+T_V^{proc}+T_F^{proc}+T_{CS}^{proc}.$$

Here, $T_{X\to Y}$ represents the communication delay for transmitting a message from node X to node Y, and $T^{proc}$ denotes the processing delay caused by cryptographic computations at each node.

Based on the message size analysis presented in this paper, the message sizes are 900 bytes for $V_i\to F_j$, 964 bytes for $F_j\to CS$, 228 bytes for $CS\to F_j$, and 168 bytes for $F_j\to V_i$. The transmission delay of each message can be calculated as

$$T_{X\to Y}={\displaystyle \frac{8\times \mathrm{bytes}}{R}},$$

where R denotes the data transmission rate [62].

Assuming an IEEE 802.11p data rate of 6 Mbps, the transmission delay of each communication stage is given as

$$T_{V\to F}={\displaystyle \frac{8\times 900}{6\times {10}^6}}\approx 1.20\mathrm{ms},T_{F\to CS}={\displaystyle \frac{8\times 964}{6\times {10}^6}}\approx 1.285\mathrm{ms},$$

$$T_{CS\to F}={\displaystyle \frac{8\times 228}{6\times {10}^6}}\approx 0.304\mathrm{ms},T_{F\to V}={\displaystyle \frac{8\times 168}{6\times {10}^6}}\approx 0.224\mathrm{ms}.$$

Furthermore, applying the computation costs presented in Table 6, the processing times of the vehicle, fog node, and cloud server are 0.031735 ms, 0.003960 ms, and 0.040478 ms, respectively. Therefore, under an IEEE 802.11p data rate of 6 Mbps, the overall end-to-end authentication latency is estimated as

$$T_{\mathrm{E}2\mathrm{E}}\approx 1.20+1.285+0.304+0.224+0.031735+0.003960+0.040478\approx 3.09\mathrm{ms}.$$

For a more conservative scenario, assuming the minimum IEEE 802.11p data rate of 3 Mbps, the total communication delay becomes $T_{\mathrm{comm}}\approx 6.027$ ms, which leads to

$$T_{\mathrm{E}2\mathrm{E}}\approx 6.027+0.076\approx 6.10\mathrm{ms}.$$

The proposed protocol provides a structural advantage by enabling the simultaneous establishment of three independent session keys (Vehicle–Fog, Fog–Cloud, and Vehicle–Cloud) within a single authentication session without requiring multiple handshake rounds. In SIoV environments, vehicles interact with nearby fog nodes for only a limited time due to high mobility, and authentication procedures must therefore be completed quickly to support real-time services. Since the proposed protocol completes the entire authentication process within a few milliseconds, the introduced delay is negligible compared with typical vehicular communication intervals, thereby satisfying the low-latency requirements of practical SIoV systems [6,7,8,9].

8. Conclusions

This paper examined the security challenges inherent in fog-enabled SIoV environments, particularly considering that fog nodes are typically deployed in physically exposed roadside locations. Existing authentication schemes often assume fog nodes to be fully trusted or honest-but-curious entities and rely on a single shared session key for all participating parties. Under such assumptions, a compromised fog node may decrypt all communications between vehicles and the cloud, resulting in unnecessary exposure of sensitive information.

To overcome these limitations, a post-quantum secure mutual authentication and pairwise key agreement scheme was proposed for fog computing–based SIoV environments. The proposed scheme establishes distinct session keys for vehicle–fog, fog–cloud, and vehicle–cloud communications within a single authentication session. This key separation mechanism prevents sensitive information disclosure even if a fog node is compromised. Consequently, fog nodes are restricted to processing only the data required for localized service execution, while direct vehicle–cloud communications remain confidential.

Furthermore, PUFs were applied to protect physical capture attacks, and lattice-based cryptography based on the MLWE was employed to ensure resistance against quantum computing threats. The security of the proposed scheme was rigorously validated through formal verification using AVISPA, BAN logic, and the RoR model, in addition to comprehensive informal security analysis. Comparative performance evaluations demonstrate that the proposed scheme achieves competitive computational and communication efficiency, confirming its suitability for deployment in latency-sensitive SIoV environments.