Security Authentication Scheme for Vehicle-to-Everything Computing Task Offloading Environments

Abstract

Computational task offloading is a key technology in the field of vehicle-to-everything (V2X) communication, where security issues represent a core challenge throughout the offloading process. We must ensure the legitimacy of both the offloading entity (requesting vehicle) and the offloader (edge server or assisting vehicle), as well as the confidentiality and integrity of task data during transmission and processing. To this end, we propose a security authentication scheme for the V2X computational task offloading environment. We conducted rigorous formal and informal analyses of the scheme, supplemented by verification using the formal security verification tool AVISPA. This demonstrates that the proposed scheme possesses fundamental security properties in the V2X environment, capable of resisting various threats and attacks. Furthermore, compared to other related authentication schemes, our proposed solution exhibits favorable performance in terms of computational and communication overhead. Finally, we conducted network simulations using NS-3 to evaluate the scheme’s performance at the network layer. Overall, the proposed scheme provides reliable and scalable security guarantees tailored to the requirements of computing task offloading in V2X environments.

1. Introduction

Vehicle-to-everything (V2X) computing task offloading is an indispensable enabling technology for intelligent transportation systems, serving as the bridge connecting vehicle intelligence with smart traffic networks. In vehicle-to-everything (V2X) scenarios, computational tasks requiring offloading can be categorized into three types: computation-intensive, latency-sensitive, and hybrid. Computation-intensive tasks include map modeling and updating, environmental perception and fusion, and path planning. While these tasks do not demand high latency, they require substantial computational power ranging from hundreds of GOPS to several TOPS. Therefore, they should be offloaded to edge servers or cloud centers with richer computational resources for execution. Latency-sensitive tasks encompass collision warnings, collaborative perception sharing, and real-time vehicle platooning. While their computational demands are not exceptionally high, they impose extremely stringent latency requirements, typically demanding end-to-end latency between 10 milliseconds and 100 milliseconds, or even less than 10 milliseconds. Hybrid tasks encompass real-time decision-making and driver assistance (such as lane changes or ramp merging based on edge-server-enhanced visual perception). These tasks fall between the preceding two categories in terms of both computational power and latency requirements.

To address the challenges posed by traditional cloud computing—which cannot meet the stringent requirements of V2X for low latency, high channel bandwidth, and robust privacy and security—edge computing has emerged as a solution [1]. Edge computing addresses cloud computing’s limitations by relocating computational power and storage resources closer to the network edge—near the data source [1,2]. This enables rapid processing and timely responses to computational tasks while alleviating single-point pressure on cloud centers, establishing a complementary and collaborative relationship with the cloud [3]. Offloading V2X computing tasks onto edge computing infrastructure is a critical operation. By transferring vehicle-generated computational tasks to edge servers, it leverages their processing power and storage resources to handle task data and receive results [3,4]. This approach overcomes terminal computing limitations while meeting low-latency application demands. However, offloading significantly expands the attack surface. First, attackers can impersonate legitimate edge servers. Requesting vehicles may unload computational tasks—containing sensitive identity information, location data, sensor readings, or even control commands—onto these disguised servers. This enables attackers to steal private data or return erroneous results, potentially causing requesting vehicles to make fatal misjudgments. Second, attackers may impersonate legitimate requesting vehicles to consume edge server computational resources. As the number of spoofed requesting vehicle nodes increases, server resources can be rapidly depleted, denying service to legitimate requesting vehicles. Furthermore, the task offloading process always occurs over open channels, exposing transmitted messages to eavesdropping, interception, forgery, and tampering by attackers—potentially causing severe consequences [5]. Therefore, authentication between relevant entities is an absolutely essential first line of defense before implementing computational task offloading. To this end, we need to design an authentication key exchange scheme to ensure the legitimacy of entities participating in computational task offloading and the confidentiality of the offloading process.

In this paper, the computational task offloading scenarios we investigate include offloading between the requesting vehicle and an edge server (V2I), as well as offloading between the requesting vehicle and an auxiliary vehicle (V2V). The auxiliary vehicle can leverage its idle resources to serve the requesting vehicle, thereby extending the coverage range of the edge to some extent. In the V2I computational offloading scenario, roadside units (RSUs) serve as information aggregation and distribution hubs, responsible for relaying messages between vehicles within their jurisdiction and the edge server.

The primary objective of this paper is to design an authentication scheme for the vehicle-to-everything (V2X) computing task offloading environment. This scheme ensures the security of communication entities involved in task offloading and the offloading process itself, while minimizing computational overhead to guarantee high efficiency. Our proposed secure authentication scheme features the following characteristics:

• Includes four-party authentication involving the requesting vehicles, roadside units (RSUs), edge servers (ESs), and the cloud management center (CMC—all entities accessing the vehicle-to-everything network must first register here), as well as three-party authentication between the requesting vehicles, auxiliary vehicles, and the cloud management center.
• This solution employs lightweight cryptographic techniques and operations such as elliptic curve cryptography, hash functions, physically unclonable function (PUF), and XOR. This approach provides security protection while minimizing computational and communication overhead associated with task offloading.
• The proposed scheme underwent formal analysis using BAN logic and the ROR model and was validated through the AVISPA tool. It has been demonstrated to possess reliable security properties and can withstand potential attacks on vehicle-to-everything (V2X) networks.
• We compared our proposed scheme with existing schemes in the field of vehicle-to-everything (V2X) communication. Our scheme demonstrates favorable performance in terms of authentication overhead.

2. Related Work

The security framework in the vehicle-to-everything (V2X) environment is built upon two core issues: identity authentication and behavioral trustworthiness. Identity authentication serves as the foundation for ensuring the legitimacy of communicating entities, while behavioral trustworthiness is evaluated through trust management models, aiming to determine the reliability of authenticated entities’ actions. To defend against unpredictable, potentially malicious attacks in the heterogeneous V2X environment and enhance the “trusted decision-making” capabilities at the application layer, numerous scholars have proposed relevant solutions.

Regarding identity authentication, Li et al. [5] designed an authentication protocol for V2X with lightweight characteristics. The protocol employs low-overhead operations like HASH and XOR operations, reducing computational overhead and enhancing authentication efficiency. However, it does not support forward secrecy and fails to account for the impact of real-world physical layer attacks on On-Board Units (OBUs). Gupta et al. [6] proposed a hierarchical authentication mechanism based on identity-based cryptography or short signature algorithms, integrating network slicing technology to provide differentiated bandwidth for various service data. By processing authentication requests at MEC nodes, it reduces backhaul time but may introduce single-point-of-failure risks. Han et al. [7] proposed an anonymous authentication scheme based on fog computing. However, the protocol employs computationally complex bilinear pairing, which is unsuitable for resource-constrained V2X environments and low-latency requirements. Yang et al. [8] introduced an Edge-Assisted Distributed Authentication (EADA) architecture, which also offloads authentication capabilities to RSUs and base stations while tailoring vehicle authentication based on vehicle status. Cui et al. [9] proposed a scalable in-vehicle network authentication scheme for multi-cloud environments, employing a Cloud Broker (CB) managed by the TA to connect all cloud services, thereby shielding vehicle users from the complexity of selecting cloud services. Bagga et al. [10] designed a robust authentication and key establishment scheme for intelligent transportation systems (ITSs) that allows new vehicles to dynamically join RSUs after initial deployment, while reducing the management burden on the TA. Vinoth et al. [11] designed a secure key negotiation scheme for the Industrial Internet of Things (IoT) between a single user and multiple sensor devices. Adopting the key sharing concept and leveraging the Chinese Remainder Theorem (CRT) from number theory, the scheme constructs group keys for multiple sensor devices while being highly suitable for resource-constrained environments. Zhou et al. [12] identified computational inconsistencies in the security proofs of Ali’s [13] CLCPPA protocol for V2I communications. They improved upon Ali et al.’s work and demonstrated that the enhanced CLCPPA effectively defends against signature forgery attacks. Cao et al. [14] proposed a lattice-based group signature authentication protocol, implementing forward secrecy using a Bonsai-tree signature scheme. Prateek et al. introduced a privacy-preserving authentication scheme based on quantum key distribution protocols for V2I communications. Son et al. [15] proposed a blockchain-based VANET handover authentication protocol where vehicles perform only lightweight computations during zone transitions, demonstrating the protocol’s feasibility through formal tools and simulation experiments. Yang et al. [16] proposed an ECC-based anonymous authentication scheme with a two-stage process: initial authentication followed by subsequent authentication phases. Subsequent authentication relies on the initial authentication, but this places significant authentication pressure on RSUs, especially when authenticating numerous vehicles, potentially causing performance bottlenecks. Wei et al. [17] addressed the single point of failure issue in root-TA models by adopting a multi-TA architecture. They implemented an identity authentication list within sub-TAs and employed the Cuckoo Filter to optimize retrieval processes. Novelly, they utilized Lagrange’s Interpolation Theorem during mutual authentication to establish session keys. Similarly, the multi-TA model is referenced in [18]. Awais et al. [19] propose a lightweight key exchange scheme using PUFs for n vehicles in VANETs, resisting physical attack risks. It employs hash encryption and XOR operations to reduce computational overhead and communication costs. This scheme is proven secure under the ROR model and satisfies relevant security properties. Mulambia et al. [20] introduced a blockchain-based VANET architecture comprising three layers: the message propagation layer, the management layer, and the blockchain layer. Roadside units (RSUs) function as authentication managers, verifying vehicle information. Management-layer RSUs broadcast their known authentication data to other RSUs at the same layer. All RSUs submit hashed records to the blockchain, thereby reducing the propagation of malicious information by rogue nodes. However, this approach incurs increasing latency as the number of transactions within blocks grows, necessitating a trade-off with security. Yu et al. [21] proposed RLBA-UAV, a blockchain-based authentication and key establishment scheme addressing privacy and security challenges in sensor and IoT data transmission for UAVs. Leveraging UAVs’ PUF capabilities, the scheme demonstrated proven security properties via ROR and AVISPA models while exhibiting efficiency compared to existing approaches. These studies lay a solid foundation for our exploration in the IOV domain and hold significant importance. Othman et al. [22] proposed a secure authentication protocol based on Physical Unclonable Functions (PUFs). Vehicles and road side units (RSUs) can use embedded PUFs to construct polynomial shared keys. The use of PUFs prevents attackers from impersonating legitimate entities. Additionally, the authors propose a revocation mechanism “SGKD”, supporting both temporary and permanent revocation, reducing the time complexity from O(${\mathrm{l}\mathrm{o}\mathrm{g}}^{\mathrm{N}}$) to O(1). For vehicle-to-vehicle communication, the protocol distinguishes between unicast fast authentication and broadcast secure message transmission scenarios. It also demonstrates strong resistance against desynchronization attacks. Wu et al. [23] proposed a lightweight vehicle social network security authentication protocol based on fog nodes. Unfortunately, Li et al. [24] discovered that their authentication protocol contained threats, failing to resist insider attacks and smart card theft attacks, and lacked perfect forward secrecy. Li et al. improved Wu’s scheme in [24] and proved the effectiveness of their enhanced scheme.

Regarding behavioral trustworthiness, Liu et al. [25] proposed a Trust Cascade-based emergency message dissemination (TCEMD) model in [25], which comprehensively considers the synergistic effects of multiple factors. This model efficiently integrates entity-oriented trust values into data-oriented trust assessment and consolidates the analysis of messages reporting different states of emergency events. It addresses the shortcomings of existing models and demonstrates its superiority through a series of simulations and analyses. In 2021, Liu et al. [26] proposed an innovative Privacy-Preserving Trust Management (PPTM) scheme for emergency message dissemination in Space–Air–Ground Integrated Networks. The paper thoroughly demonstrates the correctness, precise management, and robust practicality advantages of the PPTM scheme. Through simulation analysis, it proves that the scheme achieves precise trust management and strong conditional privacy protection while maintaining low communication overhead. Recently, Liu et al. proposed a novel Privacy-Preserving Reputation Updating (PPRU) scheme in [27] to address the pressure load issue on the TA side in cloud-assisted vehicle-to-everything (V2X) networks. This scheme leverages ECC and the Paillier algorithm, delegating reputation feedback collection and preprocessing to the cloud service provider (CSP). This significantly reduces the computational burden on the TA while supporting weighted average calculations of encrypted ratings, enabling more robust reputation management. Simulation analysis demonstrates that the scheme achieves strong privacy protection against potential attacks with acceptable computational and communication overhead.

In this paper, we aim to propose an authentication scheme tailored to the vehicle-to-everything (V2X) computing task offloading environment, laying a foundational trust base for subsequent behavioral trustworthiness issues within such environments. We have summarized some of the proposed schemes in

Table 1. A comparative summary of existing authentication schemes.

Scheme	Year	Concept	Advantages	Drawbacks
Cui et al. [9]	2019	* Elliptic curve cryptography * Hash function * Elliptic curve Diffie–Hellman	Ensures anonymity Achieves traceability Perfect forward secrecy	- Multi-collaboration may add complexity - Communication delays may increase
Li et al. [5]	2020	* Hash function	Low computation overhead Support for unlinkability and anonymity	- Unrealized forward security - Idealized OBUs without considering realistic physical layer attacks
Han et al. [7]	2020	* Bilinear pairing operation * Hash function	Meet vehicle anonymity and traceability Information integrity and non-forgeability are achieved	- High computational cost
Othman et al. [22]	2021	* Elliptic curve cryptograph * Hash function and Hash-based Message Authentication Code (HAMC) * Pseudo-random function	Immune to MITM attacks Resiliency against desynchronization attacks Protection against physical attacks	- Execution of bivariate polynomials may be slow on resource-constrained OBUs
Li et al. [24]	2022	* Hash function	Satisfying forward security Resist insider attacks	- Linkability of temporary identities - Defense that does not take physical attacks into account
Wei et al. [17]	2021	* Elliptic curve cryptograph * Lagrange interpolation theorem	Multi-TA model Enhance resilience against DoS attacks Satisfying unlinkability	- Deployment cost and management complexity of sub-TA can be high
Salem et al. [28]	2023	* Elliptic curve Diffie–Hellman key exchange (ECDH) * Hash function	Supports anonymity, mutual authentication, and traceability	- No timestamp introduced - Possible offline dictionary attack
Liang et al. [29]	2023	* Elliptic curve cryptograph * Hash function * Physically unclonable function	Resistance to cloning and physical attacks Resistance to known session key attacks	- PUFs are seen as idealized, while the reality of PUFs is susceptible to environmental influences
Awais et al. [30]	2024	* Hash function * Symmetric encryption and decryption * Physically unclonable function	Resisting RSU forgery attacks Vehicle traceability Resistance to physical attacks	- Missing key confirmation step - Long-term homogeneity of the “CRP”

.

3. Preliminaries

3.1. Elliptic Curve Cryptography

We select a non-singular elliptic curve E, whose form is $y^2=x^3+ax+b(modq)$. It is defined over the finite field $F_q$, where $q$ denotes a large prime number, $a,b\in F_q=\{0,1,2,\dots ,q-1\}$ and satisfies $4a^3+27b^2\ne 0$. The points on the curve together with the point at infinity $O$ form an Abelian group. Given a base point $P$, we have $P+O=P$. Elliptic curve cryptography relies on two major computational challenges. The first is ECDLP: given a base point $P$ and a point $Q=d\times P$ on an elliptic curve, where $d\in Z_p^{*}$, $p$ is the order of the cyclic subgroup generated by the point $P$, that is, the smallest positive integer p such that $p\times P=O$. It is computationally difficult to find $d$. The second is ECDHP: given a base point $P$, a point $A$, and a point $B$, $A=d_A\times P,B=d_B\times P$, where $d_A$, $d_B\in Z_p^{*}$, it is computationally difficult to find the common key $C=d_A\times d_B\times P$.

3.2. Physically Unclonable Function (PUF)

PUF is a security technology based on hardware physical characteristics that generates a unique and non-replicable “fingerprint” for each chip or physical device [31]. PUF primarily leverages minute manufacturing variations inherent in hardware production to ensure each device produces a unique PUF response. The unpredictability of the manufacturing process also renders it non-cloneable [32]. PUF is currently widely discussed in the field of protecting IoT privacy and security. For telematics computing task offloading, embedding PUF within the integrated circuit of a vehicle’s On-Board Unit (OBU) device can resist physical attacks. Its security capability is based on dynamic challenge–response interactions, generating distinct responses to different challenges. Compared to traditional chips, PUFs consume minimal hardware resources, with negligible area overhead and dynamic power consumption [32]. This makes them exceptionally well-suited for the V2X environment, effectively addressing the resource constraints and power sensitivity challenges inherent in V2X devices. We adopted the “SRAM PUF” in our proposed scheme because of its high maturity. It can utilize a Fuzzy Extractor to address bit flipping issues caused by temperature and voltage variations, ensuring stable output. Moreover, its extremely fast response speed makes it well-suited for the real-time requirements of communication authentication.

3.3. Hash Function

Hash functions are fundamental tools in cryptography. They accept input messages of arbitrary length and produce a fixed-length “fingerprint” output, always generating the same output for identical inputs. Hash functions exhibit strong resistance to preimage attacks and collision attacks [33]. Their unique “avalanche effect” and computational efficiency also make them widely used cryptographic techniques in cryptography (such as digital signatures, blockchain, and HMAC).

3.4. Adversary Threat Model

We consider employing two classical threat models—the DY model proposed by Dolev and Yao [34] and the CK model proposed by Canetti and Krawczyk [35]—to define the capabilities of adversary $\mathcal{A}$ in our proposed scheme. The CK model treats messages transmitted between protocol entities as abstract symbols, focusing on the security of protocol logic while assuming the attacker has complete control over the network. The CK model extends the attacker’s capabilities beyond the DY model by allowing selective sabotage of specific sessions and access to session-specific temporary keys. This makes the attack scenario more realistic, encompassing practical risks such as network attacks, key compromises, and insider threats. Therefore, we define the capabilities possessed by adversary $\mathcal{A}$ in our paper as follows:

• $\mathcal{A}$ can eavesdrop on, delete, tamper with, replay, or forge messages transmitted over the public channel.
• $\mathcal{A}$ can steal a vehicle’s OBU and extract stored information through physical attacks.
• $\mathcal{A}$ can impersonate legitimate users.
• $\mathcal{A}$ can guess temporary secret values through enumeration attacks.
• $\mathcal{A}$ can exploit key leaks and session vulnerabilities to launch attacks.

3.5. V2X Computing Task Offloading System Model

The vehicle-to-everything (V2X) computing task offloading system model we established is shown in Figure 1. The entities involved in offloading include vehicles, roadside units (RSUs), edge servers (ESs), and the cloud management center (CMC).

• For each vehicle entity, the On-Board Unit (OBU) serves as its core device, providing the hardware foundation for the vehicle to communicate with the external environment while possessing a certain degree of data processing and decision-making capability.
• Roadside units (RSUs) function as relay nodes and collaborative nodes within the vehicle-to-everything (V2X) computing task offloading system. They collect offloading requests issued by vehicles within the managed area and transmit status information of connected edge servers and other auxiliary vehicles in the region to the requesting vehicle. Additionally, they distribute computing task data processed by edge servers and related instructions to the managed area for centralized coordination.
• Edge servers (ESs) possess greater storage capacity and computational power than vehicles and RSUs. They handle computational tasks offloaded by vehicles, addressing the constraints of limited vehicle resources while enabling rapid response.
• The cloud management center (CMC) serves as the cloud service provider and management authority for the entire vehicle-to-everything (V2X) computing task offloading system. All entities must register here before entering the system to obtain their unique, legitimate credentials.

4. Proposed Scheme

4.1. Initialization Phase

Step 1: CMC selects a large prime number $q$ and defines an elliptic curve $E$ over the finite field $Fq$: $y^2=x^3+ax+b mod q(where 4a^3+27b^2\ne 0)$. Then, a point $P$ is chosen as the base point.

Step 2: CMC randomly selects a number $S\in Z_p^{\mathrm{*}}$ as the system private key and calculates the system public key ${PK}_{sys}=S\times P$.

Step 3: CMC selects a set of secure hash functions: $H_1:{\left\{0,1\right\}}^{\mathrm{*}}\to {\left\{0,1\right\}}^{length}$, $H_2:{\{0,1\}}^{*}\to Z_p^{*}$, $H_3:E(Fq)\to {\left\{0,1\right\}}^{\mathrm{*}}$, $H_4:(E\left(Fq\right),{\left\{0,1\right\}}^{\mathrm{*}})\to {\left\{0,1\right\}}^{length}$.

Finally, CMC publishes the parameters $\{a,b,q,P,H(),{PK}_{sys}\}$ to the entire system.

4.2. Entity Registration Phase

The symbols used in the scheme are described in

Table 2. Symbols in the scheme.

Symbols	Description
${ID}_V^i,{ID}_{RSU}^j,{ID}_{ES}^k,{ID}_{CMC}$	Real identity of vehicles, RSUs, ESs, and CMC
${PK}_{sys},S$	The system’s public key and private key
$(Cha,Res)$	Challenges and responses to PUF
${fp}_U$	The fingerprint information
${ID}_U,{PWD}_U$	User ID and password
$S_V^i,S_R^j,S_E^k$	Partial private keys of vehicles, RSUs, and ESs
${TID}_V^i,{TID}_R^j,{TID}_E^k$	Temporary identity of vehicles, RSUs, and ESs
${PK}_V^i,{PK}_R^j,{PK}_E^k$	Partial public keys of vehicles, RSUs, and ESs
$Request,ACK$	Request and response information
$Gen()/Rep()$	Cryptographic functions
${ts}_i$	Timestamp
$⨁$	XOR operation
$\parallel$	Concatenation

.

4.2.1. Vehicle Registration Phase (VRP)

VRP-1: The vehicle issues a registration request, and the CMC generates a set of PUF challenges $\{{Cha}_1,{Cha}_2,{Cha}_3\dots \}$ and transmits them to the requesting vehicle via a secure channel.

VRP-2: Upon receiving the challenge set, the vehicle uses the PUF to compute the response set $PUF\left({Cha}_h\right)={Res}_h(h=1,2,3\dots )$ and stores this challenge–response pair. The user selects and inputs their name ${ID}_U$ and password ${PWD}_U$, then enters their fingerprint information ${fp}_U$ into the vehicle. The vehicle computes $Gen({fp}_U)=(\sigma ,\tau )$, then selects a challenge–response pair $\left\{{Cha}_i,{Res}_i\right\}$ and further calculates ${PID}_U^i=H_1({ID}_U\Vert \sigma \Vert {Res}_i)$ and ${PPW}_U^i=H_1({PWD}_U\Vert {Res}_i)$. Finally, it transmits ${VRM}_1=\{{ID}_V^i,{PID}_U^i,{PPW}_U^i,{Cha}_i,{Res}_i\}$ to the CMC.

VRP-3: Upon receiving ${VRM}_1$, CMC computes $X_i=H_1({ID}_V^i\Vert {PID}_U^i\Vert S\Vert {Res}_i), A_i=X_i\oplus H_1({PID}_U^i\Vert {PPW}_U^i\Vert {ID}_V^i), B_i=H_1(X_i\Vert {PID}_U^i\Vert {PPW}_U^i)$. It then selects a random number ${nonce}_V^i$ and calculates $S_V^i=\left(S\times H_2\left({ID}_V^i\Vert {PID}_U^i{\Vert nonce}_V^i\right)\right)mod q, {TID}_V^i=({ID}_V^i\Vert {PID}_U^i)\oplus H_1(S\Vert {ID}_{CMC})$. Finally, it transmits ${VRM}_2=\{A_i,B_i,S_V^i,{TID}_V^i\}$ to the vehicle via the secure channel and stores the vehicle’s challenge response for {${Cha}_i,{Res}_i$}.

VRP-4: Upon receiving ${VRM}_2$, the vehicle calculates $C_i=S_V^i\oplus H_2({PID}_U^i\Vert {PPW}_U^i\Vert {Res}_i)$ and stores $\{A_i,B_i,C_i,{TID}_V^i\}$.

4.2.2. RSU Registration Phase (RRP)

RRP-1: RSU sends ${RRM}_1=\left\{{ID}_{RSU}^j\right\}$ to CMC via the secure channel.

RRP-2: Upon receiving ${RRM}_1$, CMC computes $Y_j=H_1({ID}_{RSU}^j\Vert S)$, then selects a random number ${nonce}_R^j$, and further calculates $S_R^j=(S·H_2({ID}_{RSU}^j\Vert {nonce}_R^j))mod q$ and ${TID}_R^j={ID}_{RSU}^j\oplus H_1(S\left.‖{ID}_{CMC}\right),{PK}_{RSU}^j=S_R^j\times P$. Finally, it transmits ${RRM}_2=\{Y_j,S_R^j,{TID}_R^j\}$ to the RSU via a secure channel and publishes ${PK}_{RSU}^j$ to the system.

RRP-3: After receiving the message ${RRM}_2$, the RSU computes $D_j=Y_j\oplus {ID}_{RSU}^j$ and $E_j=S_R^j\oplus H_2(Y_j\Vert {TID}_R^j)$ and stores $\{D_j,E_j,{TID}_R^j\}$.

4.2.3. ES Registration Phase (ERP)

RRP-1: ES sends ${ERM}_1=\left\{{ID}_{ES}^k\right\}$ to CMC via the secure channel.

RRP-2: Upon receiving ${RRM}_1$, CMC computes $Z_k=H_1({ID}_{ES}^k\Vert S)$, then selects a random number ${nonce}_E^k$, and further calculates $S_E^k=(S·H_2({ID}_{ES}^k\Vert {nonce}_E^k))mod q$ and ${TID}_E^k={ID}_{ES}^k\oplus H_1(S\left.‖{ID}_{CMC}\right), {PK}_{ES}^k=S_E^k\times P$. Finally, it transmits ${RRM}_2=\{Z_k,S_E^k,{TID}_E^k\}$ to the RSU via a secure channel and publishes ${PK}_{ES}^k$ to the system.

RRP-3: After receiving the message ${RRM}_2$, the RSU computes $F_k=Z_k\oplus {ID}_{ES}^k$ and $G_k=S_E^k\oplus H_2(Z_k\Vert {TID}_E^k)$ and stores $\{F_k,G_k,{TID}_E^k\}$.

4.3. Vehicle Login Phase (VLP)

When a vehicle enters the coverage area of its assigned RSU, it must log in to the RSU.

VLP-1: The user inputs their ${{ID}_U}^{*}$ and password ${{PWD}_U}^{*}$ and registers their fingerprint information ${{fp}_U}^{*}$. The vehicle sequentially calculates $Rep({{fp}_U}^{*},\tau )={\sigma }^{*},{{PID}_U^i}^{*}=H_1({{ID}_U}^{*}\Vert {\sigma }^{*}\Vert {Res}_i),{{PPW}_U^i}^{*}=H_1({{PWD}_U}^{*}\left.‖{Res}_i\right),{X_i}^{*}=A_i\oplus H_1\left({{PID}_U^i}^{*}‖{{PPW}_U^i}^{*}‖{ID}_V^i\right),{B_i}^{*}=H_1({X_i}^{*}\Vert {{PID}_U^i}^{*}\Vert {{PPW}_U^i}^{*})$, verifies whether ${B_i}^{*}$ equals $B_i$; if equal, login successful; otherwise, immediately abort the login.

VLP-2: When a vehicle needs to offload computational tasks, it generates a request message $Request$and selects a random number $\alpha$, where $\alpha \in Z_p^{*}$, then computes $M_1^i=\alpha \times P,M_2^i=\alpha \times {PK}_{RSU}^j,D_1=(Request\left.‖{TID}_V^i\right)\oplus H_3\left(M_2^i\right);$next, it generates a timestamp $T_1$, continues calculating $Q=\alpha +H_2(H_3\left(M_2^i\right)\left.‖T_1\right),D_2=H_1(Request\left.‖T_1\right),$ and finally sends ${VLP}_1=$ {$M_1^i,M_2^i,D_1,Q,D_2$} to the regional RSU.

VLP-3: Upon receiving ${VLP}_1$, the RSU first verifies the timestamp’s freshness, then calculates $M_2^i=S_R^j\times M_1^i,({Request}^{\mathrm{*}}\left.‖{TID}_V^i\right)=D_1\oplus H_3\left(M_2^i\right),D_3=H_2(H_3\left(M_2^i\right)\left.‖T_1\right),{D_2}^{\mathrm{*}}=H_1({Request}^{\mathrm{*}}\left.‖T_1\right)$, verifies whether $Q\times P$ equals $(M_1^i+D_3\times {PK}_V^i)$ and ${D_2}^{\mathrm{*}}$ equals $D_2$; if they are equal, then RSU generates a response message $Ack$ and a timestamp $T_2$, then calculates $D_4=(Ack\left.‖T_2\right)\oplus H_3\left(M_2^i\right),D_5=H_4(Ack\left.‖M_2^i\right)$; finally, it sends ${VLP}_2=\{D_4,D_5,T_2\}$ to the vehicle, otherwise, it immediately terminates this session.

VLP-3: After receiving ${VLP}_2$, the vehicle calculates $({Ack}^{*}\left.‖T_2\right)=D_4\oplus H_3\left(M_2^i\right),{D_5}^{*}=H_4({Ack}^{*}\left.‖M_2^i\right)$ and verifies whether ${D_5}^{*}$ equals $D_5$. If they are equal, the request succeeds, otherwise, the request fails.

4.4. Mutual Authentication and Session Key Establishment Phase

After completing the registration and login phases, the vehicle performs entity authentication based on the unloading policy.

4.4.1. Offloading Scenario 1

When a vehicle needs to offload computational tasks to an edge server, the following authentication procedures are performed.

OS1-1: The vehicle first calculates ${Auth}_V^i=H_1({TID}_V^i\Vert {ID}_V^i\Vert {Res}_i\Vert X_i)$, then generates a timestamp ${ts}_1$, and continues to compute $U_1=({TID}_E^k\Vert {ts}_1)\oplus H_3\left(M_2^i\right),{Int}_1=H_1({{Auth}_V^i\Vert U}_1‖{TID}_V^i‖{TID}_E^k\left.‖{ts}_1\right),$ and finally sends ${Msg}_1^{V2I}=\{{Auth}_V^i,U_1,{TID}_V^i,{Int}_1,{ts}_1\}$ to the regional RSU.

OS1-2: Upon receiving ${Msg}_1^{V2I}$, the RSU first checks the timestamp’s freshness, then calculates $({{TID}_E^k}^{\mathrm{*}}\left.‖{{ts}_1}^{\mathrm{*}}\right)=U_1\oplus H_3\left(M_2^i\right),{{Int}_1}^{\mathrm{*}}=H_1({Auth}_V^i{\Vert U}_1‖{TID}_V^i‖{{TID}_E^k}^{\mathrm{*}}\left.‖{{ts}_1}^{\mathrm{*}}\right)$. It verifies whether ${{Int}_1}^{\mathrm{*}}$ equals ${Int}_1$. If verification fails, the session is immediately terminated. Otherwise, it generates a random number $\beta ,\beta \in Z_p^{\mathrm{*}}$ and continues calculating $M_3^j=\beta \times P,M_4^j=\beta \times {PK}_{ES}^k$. Then it generates a timestamp ${ts}_2$ and calculates $U_2=({TID}_V^i\left.‖{ts}_2\right)\oplus H_3\left(M_4^j\right),{Auth}_R^j=H_1\left({TID}_R^j‖{ID}_{RSU}^j‖Y_j\right),{Int}_2=H_1({M_3^j\Vert U}_2\Vert {Auth}_R^j\Vert {Auth}_V^i\Vert {TID}_R^j\Vert {TID}_V^i\Vert {ts}_2)$, and finally sends ${Msg}_2^{V2I}=\{M_3^j,U_2,{Auth}_V^i,{Auth}_R^j,{TID}_R^j,{ts}_2\}$ to the ES.

OS1-3: Upon receiving ${Msg}_2^{V2I}$, ES first verifies the timestamp’s freshness, then calculates $M_4^j=S_E^k{ \times M}_3^j,({{TID}_V^i}^{\mathrm{*}}\left.‖{{ts}_2}^{\mathrm{*}}\right)=U_2\oplus H_3\left(M_4^j\right),{{Int}_2}^{\mathrm{*}}=H_1({M_3^j\Vert U}_2\Vert {Auth}_R^j\Vert {Auth}_V^i\Vert {TID}_R^j\Vert {{TID}_V^i}^{\mathrm{*}}\Vert {{ts}_2}^{\mathrm{*}})$, verifies whether ${{Int}_2}^{\mathrm{*}}$ equals ${Int}_2$, and if they do not equal, immediately terminate the session. Otherwise, continue calculating ${Auth}_E^k=H_1=\left({ID}_{ES}^k‖{TID}_E^k‖Z_k\right)$, generate a timestamp ${ts}_3$, calculate $E_1={Enc}_{\left(Z_k\right)}\left\{{{TID}_V^i}^{\mathrm{*}},{Auth}_V^i,{TID}_R^j,{Auth}_R^j,{Auth}_E^k,{ts}_3\right\},{Int}_3=H_1(E_1\Vert {TID}_E^k\Vert {Auth}_E^k{\Vert ts}_3)$, and finally send ${Msg}_3^{V2I}=\{E_1,{TID}_E^k,{Int}_3,{ts}_3\}$ to the CMC.

OS1-4: Upon receiving message ${Msg}_3^{V2I}$, CMC first verifies the timestamp’s freshness, then calculates ${ID}_{ES}^k={TID}_E^k\oplus H_1(S\left.‖{ID}_{CMC}\right),Z_k=H_1({ID}_{ES}^k\left.‖S\right)$ and decrypts $\left\{{{TID}_V^i}^{**},{{Auth}_V^i}^{*},{{TID}_R^j}^{*},{{Auth}_R^j}^{*},{{Auth}_E^k}^{*},{{ts}_3}^{*}\right\}={Dec}_{\left(Z_k\right)}(E_1)$. Then compute ${{Int}_3}^{*}=H_1(E_1\Vert {TID}_E^k\Vert {{Auth}_E^k}^{*}\Vert {{ts}_3}^{*})$, verify whether ${{Int}_3}^{*}$ equals ${Int}_3$, if not equal, immediately terminate the session. Otherwise, continue computing ${Auth}_E^k=H_1({TID}_E^k{\Vert ID}_{ES}^k\left.‖Z_k\right),{ID}_{RSU}^j={{TID}_R^j}^{*}\oplus H_1(S\left.‖{ID}_{CMC}\right),{(ID}_V^i\Vert {PID}_U^i)={{TID}_V^i}^{**}\oplus H_1(S\left.‖{ID}_{CMC}\right),X_i=H_1({ID}_V^i‖{PID}_U^i‖S\left.‖{Res}_i\right),Y_j=H_1({ID}_{RSU}^j\left.‖S\right),{Auth}_V^i=H_1({{TID}_V^i}^{*}‖{ID}_V^i‖{Res}_i\left.‖X_i\right),{Auth}_R^j=H_1\left({{TID}_R^j}^{*}‖{ID}_{RSU}^j‖Y_j\right)$, verify whether ${Auth}_E^k,{Auth}_R^j,{Auth}_V^i$ are equal to ${{Auth}_E^k}^{*},{{Auth}_R^j}^{*},{{Auth}_V^i}^{*}$. If verification fails, immediately terminate the session. If verification succeeds, CMC generates a random number $\gamma ,\gamma \in Z_p^{*}$, selects a new set of “CRP”, and updates the temporary IDs for ES, RSU, and Vehicle: ${{TID}_E^k}^{new}=$ ${TID}_E^k\oplus H_1(\gamma {\Vert Z}_k),{{TID}_R^j}^{new}=$ ${{TID}_R^j}^{*}\oplus H_1(\gamma \Vert Y_j),{{TID}_V^i}^{new}=$ ${{TID}_V^i}^{**}\oplus H_1\left(\gamma ‖{{Res}_i}^{\prime }‖X_i\right)$, then continues calculating $U_3=Z_k\oplus {{TID}_R^j}^{new},U_4=({{TID}_E^k}^{new}\Vert {{TID}_V^i}^{new})\oplus ({ID}_{RSU}^j\left.‖Y_j\right),U_5=({{TID}_R^j}^{new}\left.‖{{Cha}_i}^{\prime }\right)\oplus {(X}_i\left.‖{Res}_i\right)$. Next, generate a timestamp ${ts}_4$, calculate $U_6=\gamma \oplus H_1\left({ID}_{ES}^k\Vert {ts}_4\right),E_2={Enc}_{\left(Z_k\oplus {ID}_{ES}^k\right)}\left\{U_3,U_4,U_5,{U_6,ts}_4\right\},{Int}_4=H_1(E_2\Vert {{TID}_E^k}^{new}\Vert {{TID}_R^j}^{new}\Vert {ts}_4)$, and finally send ${Msg}_4^{V2I}=\{E_2,{Int}_4,{ts}_4\}$ to the ES.

OS1-5: Upon receiving message ${Msg}_4^{V2I}$, ES first verifies the timestamp’s freshness, then decrypts $\left\{{U_3}^{\mathrm{*}},{U_4}^{\mathrm{*}},{U_5}^{\mathrm{*}},{U_6}^{\mathrm{*}},{{ts}_4}^{\mathrm{*}}\right\}={Dec}_{\left(Z_k\oplus {ID}_{ES}^k\right)}(E_2)$, computes $\gamma ={U_6}^{\mathrm{*}}\oplus H_1\left({ID}_{ES}^k\Vert {{ts}_4}^{\mathrm{*}}\right),{{TID}_E^k}^{new}=$ ${TID}_E^k\oplus H_1\left(\gamma {\Vert Z}_k\right),{{TID}_R^j}^{new}=Z_k\oplus {U_3}^{\mathrm{*}},{{Int}_4}^{\mathrm{*}}=H_1(E_2\Vert {{TID}_E^k}^{new}\Vert {{TID}_R^j}^{new}\Vert {{ts}_4}^{\mathrm{*}})$, and verifies whether ${{Int}_4}^{\mathrm{*}}$ equals ${Int}_4$. If verification fails, immediately terminate the session. Otherwise, continue calculating ${SK}_{E-R}^{k-j}=H_4\left({{TID}_E^k}^{ new}\Vert {{TID}_R^j}^{ new}\Vert M_4^j\right)$, and generate a timestamp ${ts}_5$, calculate $U_7=H_3\left(M_4^j\Vert {ts}_5\right)\oplus \gamma ,{Int}_5=H_1({U_4}^{\mathrm{*}}\Vert {U_5}^{\mathrm{*}}\Vert U_7\Vert {SK}_{E-R}^{k-j}{\Vert \gamma \Vert ts}_5)$, and finally send ${Msg}_5^{V2I}=\{{U_4}^{\mathrm{*}},{U_5}^{\mathrm{*}},U_7,{Int}_5,{ts}_5\}$ to the RSU.

OS1-6: Upon receiving message ${Msg}_5^{V2I}$, RSU first verifies the timestamp’s freshness, then calculates $\gamma =U_7\oplus H_3\left(M_4^j\Vert {ts}_5\right),{{TID}_R^j}^{new}={{TID}_R^j}^{\mathrm{*}}\oplus H_1(\gamma \Vert Y_j),({{TID}_E^k}^{new}\Vert {{TID}_V^i}^{new})={U_4}^{\mathrm{*}}\oplus ({ID}_{RSU}^j\Vert Y_j),{SK}_{R-E}^{j-k}=H_4\left({{TID}_E^k}^{ new}\Vert {{TID}_R^j}^{ new}\Vert M_4^j\right)$, ${{Int}_5}^{\mathrm{*}}=H_1({U_4}^{\mathrm{*}}\Vert {U_5}^{\mathrm{*}}\Vert U_7{\Vert SK}_{R-E}^{j-k}\Vert {\gamma \Vert ts}_5)$, and verifies whether ${{Int}_5}^{\mathrm{*}}$ equals ${Int}_5$. If verification fails, immediately terminate the session. Otherwise, generates a timestamp ${ts}_6$, calculate $C_1=H_1({SK}_{R-E}^{j-k}\Vert {ts}_6)$; next, send ${Msg}_6^{V2I}=\{C_1,{ts}_6\}$ to ES.

OS1-7: Upon receiving the message ${Msg}_6^{V2I}$, ES first verifies the timestamp’s freshness, then calculates ${C_1}^{*}=H_1({SK}_{R-E}^{j-k}\Vert {ts}_6)$, verifies whether ${C_1}^{*}$ equals $C_1$, and if the verification succeeds, it indicates that the session key between the ES and the RSU has been correctly established. Otherwise, the session is immediately terminated.

OS1-8: After sending the ${Msg}_6$, the RSU calculates ${SK}_{R-V}^{j-i}=H_4({{TID}_R^j}^{new}\Vert {{TID}_V^i}^{new}\Vert M_2^i)$, then generates a timestamp ${ts}_7$, continues to calculate $U_8=\gamma \oplus H_4(M_2^i\left.‖{ts}_7\right),{Int}_6=H_1({U_5}^{\mathrm{*}}\Vert U_8\Vert \mathsf{\gamma }{\Vert SK}_{R-V}^{j-i}\Vert {ts}_7)$, and finally sends ${Msg}_7^{V2I}=\{{U_5}^{\mathrm{*}},U_8,{Int}_6,{ts}_7\}$ to the vehicle.

OS1-9: Upon receiving the message ${Msg}_7^{V2I}$, the vehicle first verifies the timestamp’s freshness, then calculates $\gamma =U_8\oplus H_4(M_2^i\left.‖{ts}_7\right)$, $({{TID}_R^j}^{new}\left.‖{{Cha}_i}^{\mathrm{\prime }}\right)={U_5}^{\mathrm{*}}\oplus {(X}_i\left.‖{Res}_i\right),PUF\left({{Cha}_i}^{\mathrm{\prime }}\right)={{Res}_i}^{\mathrm{\prime }},{{TID}_V^i}^{new}={TID}_V^i\oplus H_1\left(\gamma ‖{{Res}_i}^{\mathrm{\prime }}‖X_i\right)$, ${SK}_{V-R}^{i-j}=H_4\left({{TID}_R^j}^{ new}\Vert {{TID}_V^i}^{ new}\Vert M_2^i\right)$, and ${{Int}_6}^{\mathrm{*}}=H_1({U_5}^{\mathrm{*}}\Vert U_8\Vert {SK}_{V-R}^{i-j}\Vert \mathsf{\gamma }\Vert {ts}_7)$, and verifies whether ${{Int}_6}^{\mathrm{*}}$ equals ${Int}_6$. If verification fails, immediately terminate the session. Otherwise, it generates a timestamp ${ts}_8$ and calculates $C_2=H_1({SK}_{V-R}^{i-j}\Vert {ts}_8)$; finally, the vehicle send ${Msg}_8^{V2I}=\left\{C_2,{ts}_8\right\}$ to the RSU.

OS1-10: Upon receiving the message ${Msg}_8^{V2I}$, RSU first verifies the timestamp’s freshness, then calculates ${C_2}^{*}=H_1({SK}_{R-V}^{k-i}\Vert {ts}_6)$, verifies whether ${C_2}^{*}$ equals $C_2$, and if the verification succeeds, it indicates that the session key between the RSU and the vehicle has been correctly established. Otherwise, the session is immediately terminated.

Figure 2 illustrates a specific process of offloading scenario 1.

4.4.2. Offloading Scenario 2

When a vehicle needs to offload computational tasks to an auxiliary vehicle, the following authentication process will be executed. Figure 3 illustrates a specific process of offloading scenario 2.

OS2-1: The vehicle requesting offloading first generates a random number $n_V^i$, then calculates $V_1=n_V^i\oplus X_i,{Auth}_V^i=H_1(n_V^i\Vert {ID}_V^i\Vert {PID}_U^i\Vert X_i)$; next, it generates a timestamp ${ts}_1$, continues calculating $W_1=H_1(V_1\Vert {Auth}_V^i\Vert {TID}_V^i\Vert {ts}_1)$; finally, it sends ${Msg}_1^{V2V}=\{V_1,{Auth}_V^i,{TID}_V^i,W_1,{ts}_1\}$, to the auxiliary vehicle.

OS2-2: Upon receiving message ${Msg}_1^{V2V}$, the auxiliary vehicle first verifies the timestamp’s freshness and calculates ${W_1}^{*}=H_1(V_1\Vert {Auth}_V^i\Vert {TID}_V^i\Vert {ts}_1)$, and verifies whether ${W_1}^{*}$ equals $W_1$. If verification fails, it immediately terminates the session. Otherwise, he generates a random number $n_V^m$ and continues calculating $V_2=n_V^m\oplus X_m,{Auth}_V^m=H_1(n_V^m\Vert {ID}_V^m\Vert {PID}_U^m\Vert X_m)$, then generates a timestamp ${ts}_2$, continues calculating $W_2=H_1\left(V_1\right.‖{Auth}_V^i‖{TID}_V^i‖V_2‖{Auth}_V^m‖{TID}_V^m\left.‖{ts}_2\right),$ and sends ${Msg}_2^{V2V}=\{{W_2,V}_1,{Auth}_V^i,{TID}_V^i,V_2,{Auth}_V^m,{TID}_V^m,{ts}_2\}$ to the CMC.

OS2-3: Upon receiving message ${Msg}_2^{V2V}$, CMC first verifies the timestamp’s freshness and computes ${W_2}^{\mathrm{*}}=H_1(V_1\Vert {Auth}_V^i\Vert {TID}_V^i\Vert V_2\Vert {Auth}_V^m\Vert {TID}_V^m\Vert {ts}_2)$, then validates whether ${W_2}^{\mathrm{*}}$ equals $W_2$. If they do not equal, the session is immediately terminated. Otherwise, it proceeds to calculate $({ID}_V^i\Vert {PID}_U^i)={TID}_V^i\oplus H_1(S\left.‖{ID}_{CMC}\right),X_i=H_1({ID}_V^i\Vert {PID}_U^i\Vert S\left.‖{Res}_i\right),{{n_V^i=V_1\oplus X_i,Auth}_V^i}^{\mathrm{*}}=H_1({ID}_V^i\Vert {PID}_U^i\Vert n_V^i\Vert X_i)$; CMC verifies whether ${{Auth}_V^i}^{\mathrm{*}}$ equals ${Auth}_V^i$. If they are equal, it indicates that CMC has successfully verified the requesting vehicle. Otherwise, the verification fails. CMC continues to calculate $({ID}_V^m\Vert {PID}_U^m)={TID}_V^m\oplus H_1(S\left.‖{ID}_{CMC}\right),X_m=H_1({ID}_V^m‖{PID}_U^m‖S\left.‖{Res}_m\right),{{n_V^m=V_2\oplus X_m,Auth}_V^m}^{\mathrm{*}}=H_1({ID}_V^m\Vert {PID}_U^m\Vert n_V^m\Vert X_m)$, then verifies whether ${{Auth}_V^m}^{\mathrm{*}}$ equals ${Auth}_V^m$. Similarly, if they are equal, it indicates that CMC has successfully verified the auxiliary vehicle. Subsequently, CMC generates a random number $n_C$, selects a new set of “CRP” and updates the temporary IDs for the requesting vehicle and the auxiliary vehicle: ${{N_1=\left[\left(n_C\times n_V^m\right)mod p\right]\times P,N_2=[\left(n_C\times n_V^i\right)mod p]\times P,TID}_V^i}^{new}={TID}_V^i\oplus H_4(N_1\left.‖{{Res}_i}^{\mathrm{\prime }}\right),{{TID}_V^m}^{new}={TID}_V^m\oplus H_4(N_2\left.‖{{Res}_m}^{\mathrm{\prime }}\right)$, then, it calculates $V_3={{TID}_V^i}^{new}\oplus H_1{(X}_m\Vert {{Res}_m}^{\mathrm{\prime }}),V_4=({{Cha}_m}^{\mathrm{\prime }}\Vert N_2)\oplus H_1({ID}_V^m\left.‖n_V^m\right),V_5={{TID}_V^m}^{new}\oplus {H_1(X}_i\Vert {{Res}_i}^{\mathrm{\prime }}),V_6=({{Cha}_i}^{\mathrm{\prime }}\Vert N_1)\oplus H_1({ID}_V^i\Vert n_V^i)$; next, it generates a timestamp ${ts}_3$ and an encrypted message $S_1={Enc}_{(n_V^m)}{\{V}_3,V_4,V_5,V_6,{ts}_3\}$, calculates $W_3=H_1(S_1‖{ts}_3‖{{TID}_V^m}^{new}\Vert {{TID}_V^i}^{new}),$ and finally sends ${Msg}_3^{V2V}=\{S_1,W_3,{ts}_3\}$ to the auxiliary vehicle.

OS2-4: Upon receiving message ${Msg}_3^{V2V}$, the auxiliary vehicle first verifies the timestamp’s freshness, then decrypts $\left\{{V_3}^{\mathrm{*}},{V_4}^{\mathrm{*}},{V_5}^{\mathrm{*}},{V_6}^{\mathrm{*}},{{ts}_3}^{\mathrm{*}}\right\}={Dec}_{\left(n_V^m\right)}(S_1)$, calculates $({{Cha}_m}^{\mathrm{\prime }}\left.‖N_2\right)={{V_4}^{\mathrm{*}}\oplus H}_1({ID}_V^m\left.‖n_V^m\right),{{TID}_V^m}^{new}={TID}_V^m\oplus H_1(N_2\left.‖{{Res}_m}^{\mathrm{\prime }}\right),{{TID}_V^i}^{new}={V_3}^{\mathrm{*}}\oplus H_1{(X}_m\left.‖{{Res}_m}^{\mathrm{\prime }}\right),{W_3}^{\mathrm{*}}=H_1(S_1‖{{ts}_3}^{\mathrm{*}}‖{{TID}_V^m}^{new}\left.‖{{TID}_V^i}^{ new}\right)$, and validates whether ${W_3}^{\mathrm{*}}$ equals $W_3$. If they do not equal, the session is immediately terminated. Otherwise, it proceeds to calculate $N_t=n_V^m\times N_2$, after that, it establishes the session key ${SK}_{V-V}^{m-i}=H_4({{TID}_V^m}^{\mathrm{*}}\Vert {{TID}_V^i}^{\mathrm{*}}\Vert N_t)$. Then, it generates a timestamp ${ts}_4$, continues to calculate $W_4=H_1({V_5}^{\mathrm{*}}\Vert {V_6}^{\mathrm{*}}\Vert {ts}_4)$, and finally sends ${Msg}_4^{V2V}=\{{V_5}^{\mathrm{*}},{V_6}^{\mathrm{*}},W_4,{ts}_4\}$ to the requesting vehicle.

OS2-5: Upon receiving the message ${Msg}_4^{V2V}$, the requesting vehicle first verifies the timestamp’s freshness, then computes ${W_4}^{*}=H_1({V_5}^{*}\Vert {V_6}^{*}\Vert {ts}_4)$, verifying whether ${W_4}^{*}$ equals $W_4$. If unequal, the session is immediately terminated, otherwise, it continues computing $({{Cha}_i}^{\prime }\left.‖N_1\right)={{V_6}^{*}\oplus H}_1({ID}_V^i\left.‖n_V^i\right),{{TID}_V^i}^{new}={TID}_V^i\oplus H_1(N_1\left.‖{{Res}_i}^{\prime }\right),{{TID}_V^m}^{new}={V_5}^{*}\oplus H_1{(X}_i\left.‖{{Res}_i}^{\prime }\right),N_t=n_V^i\times N_1$. Similarly, it establishes the session key ${SK}_{V-V}^{i-m}=H_1({{TID}_V^m}^{new}\Vert {{TID}_V^i}^{new}\Vert N_t)$. Next, it generates a timestamp ${ts}_5$ and continues calculating $W_5=H_1({SK}_{V-V}^{i-m}\Vert {ts}_5)$, and finally, it sends ${Msg}_5^{V2V}=\{W_5,{ts}_5\}$ to the auxiliary vehicle.

OS2-6: Upon receiving the message ${Msg}_5^{V2V}$, the auxiliary vehicle first verifies the timestamp’s freshness, then calculates ${W_5}^{*}=H_1({SK}_{V-V}^{m-i}\Vert {ts}_5)$, verifies whether ${W_5}^{*}$ equals $W_5$, and if the verification succeeds, it indicates that the session key between the requesting vehicle and the auxiliary vehicle has been correctly established. Otherwise, the session is immediately terminated.

5. Formal Analysis and Informal Analysis

In this section, we perform both formal and informal security analyses on the proposed scheme to evaluate its security.

5.1. Formal Analysis Using BAN Logic

BAN logic is a formal logical tool for analyzing and verifying protocol security [36]. It transforms protocol security into provable problems through belief reasoning [37]. The primary concepts and rules of BAN logic are shown in

Table 3. Key concepts of BAN logic.

Concepts	Description
$A|\equiv M$	A believes M.
$A|~M$	A once said M.
$A⊲M$	A met M.
$\#(M)$	M is fresh.
$A|\Rightarrow M$	A has jurisdiction over M.
${〈X〉}_Y,(X,Y)$	The combination of X and Y.
${\left\{M\right\}}_K$	The message M encrypted with key K.
$A\stackrel{K}{\leftrightarrow }B$	K is the shared key between A and B.

and

Table 4. Rules for inference in BAN logic.

Inference Rules	Form of Expression
(R1) Message-Meaning Rule	${\displaystyle \frac{A|\equiv A\stackrel{K}{\leftrightarrow }B,A⊲{\left\{M\right\}}_K}{A|\equiv B|~M}}$
(R2) Nonce-Verification Rule	${\displaystyle \frac{A|\equiv \#(M),A|\equiv B|~M}{A|\equiv B|\equiv M}}$
(R3) Jurisdiction Rule	${\displaystyle \frac{A|\equiv B|\Rightarrow M,A|\equiv B|\equiv M}{A|\equiv M}}$
(R4) Freshness Rule	${\displaystyle \frac{A|\equiv \#(X)}{A|\equiv \#(X,Y)}}$
(R5) Belief Rule	${\displaystyle \frac{A|\equiv X,A|\equiv Y}{A|\equiv (X,Y)}}$

.

Based on the concepts and rules of the BAN logic outlined above, the security and correctness of the solution are verified through the following specific reasoning process (we take OS1 as an example.):

1.

The goals we need to prove:

Goal 1: $V_i|\equiv (V_i\stackrel{S{K}_{ij}}{\leftrightarrow }RS{U}_j)$ Goal 2: $RS{U}_j|\equiv (V_i\stackrel{S{K}_{ij}}{\leftrightarrow }RS{U}_i)$

Goal 3: $V_i|\equiv RS{U}_j|\equiv (V_i\stackrel{S{K}_{ij}}{\leftrightarrow }RS{U}_j)$ Goal 4: $RS{U}_j|\equiv V_i|\equiv (V_i\stackrel{S{K}_{ij}}{\leftrightarrow }RS{U}_j)$

Goal 5: $RS{U}_j|\equiv (RS{U}_j\stackrel{S{K}_{jk}}{\leftrightarrow }E{S}_k)$ Goal 6: $E{S}_k|\equiv (RS{U}_j\stackrel{S{K}_{jk}}{\leftrightarrow }E{S}_k)$

Goal 7: $RS{U}_j|\equiv E{S}_k|\equiv (RS{U}_j\stackrel{S{K}_{jk}}{\leftrightarrow }E{S}_k)$

Goal 8: $E{S}_k|\equiv RS{U}_j|\equiv (RS{U}_j\stackrel{S{K}_{jk}}{\leftrightarrow }E{S}_k)$

2.

Initial assumptions:

A1: $V_i|\equiv (V_i\stackrel{M_2^i,X_i,Re{s}_i}{\leftrightarrow }RS{U}_j)$ A2: $RS{U}_j|\equiv (V_i\stackrel{M_2^i,X_i,Re{s}_i}{\leftrightarrow }RS{U}_j)$

A3: $RS{U}_j|\equiv \text{\#}(t{s}_2)$ A4: $E{S}_k|\equiv (RS{U}_j\stackrel{M_4^j,Y_j}{\leftrightarrow }E{S}_k)$

A5: $RS{U}_j|\equiv (RS{U}_j\stackrel{M_4^j,Y_j}{\leftrightarrow }E{S}_k)$ A6: $V_i|\equiv RS{U}_j\Rightarrow (V_i\stackrel{S{K}_{ij}}{\leftrightarrow }RS{U}_j)$

A7: $RS{U}_j|\equiv V_i\Rightarrow (V_i\stackrel{S{K}_{ij}}{\leftrightarrow }RS{U}_j)$ A8: $E{S}_k|\equiv \#(t{s}_1)$

A9: $E{S}_k|\equiv (E{S}_k\stackrel{Z_k,I{D}_{ES}^k}{\leftrightarrow }RS{U}_j)$ A10: $V_i|\equiv \#(t{s}_3)$

A11: $RSU|\equiv \#(t{s}_5)$ A13: $E{S}_k|\equiv \#(t{s}_4)$

A14: $RS{U}_j|\equiv E{S}_k\Rightarrow (RS{U}_j\stackrel{S{K}_{jk}}{\leftrightarrow }E{S}_k)$

A15: $E{S}_k|\equiv RS{U}_j\Rightarrow (RS{U}_j\stackrel{S{K}_{jk}}{\leftrightarrow }E{S}_k)$

3.

Idealized scheme:

The idealized form of the BAN logic for the proposed scheme is as follows:

$$\begin{array}{l}{M}_1=({\{TI{D}_R^{j new},\gamma \}}_{(Z_k,I{D}_{ES}^k)},t{s}_1,{\left\{TI{D}_E^{k new}\right\}}_{(Z_k)})\\ M_2=({\left\{\gamma \right\}}_{(M_4^j)},{\{TI{D}_E^{k new},TI{D}_V^{i new}\}}_{(Y_j)},{\left\{TI{D}_R^{j new}\right\}}_{(\gamma ,Y_j)},t{s}_6)\\ M_3=({\left\{\gamma \right\}}_{(M_2^i)},{\left\{TI{D}_R^{j new}\right\}}_{(X_i,Re{s}_i)},{\left\{TI{D}_V^{i new}\right\}}_{(X_i)},t{s}_6)\\ M_4=({\left\{S{K}_{jk}\right\}}_{(M_4^j)},t{s}_7)\\ M_5=(S{K}_{ij},t{s}_8)\end{array}$$

4.

Process of logical reasoning:

P1: From $M_1$, we obtain

$$E{S}_k⊲({\{TI{D}_R^{j new},\gamma \}}_{(Z_k,I{D}_{ES}^k)},t{s}_1,{\left\{TI{D}_E^{k new}\right\}}_{(Z_k)})$$

P2: From P1, A9, and by applying the R1, we deduce

$$E{S}_k|\equiv CMC|\sim (TI{D}_R^{j new},TI{D}_E^{k new},\gamma )$$

P3: From P2, A8, and by applying the R4, we deduce

$$E{S}_k|\equiv \#(TI{D}_R^{j new},TI{D}_E^{k new},\gamma )$$

P4: From $M_2$, we obtain

$$RS{U}_j⊲({\left\{\gamma \right\}}_{(M_4^j)},{\{TI{D}_E^{knew},TI{D}_V^{i new}\}}_{(Y_j)},{\left\{TI{D}_R^{j new}\right\}}_{(\gamma ,Y_j)},t{s}_2)$$

P5: From P4, A5, and by applying the R1, we deduce

$$RS{U}_j|\equiv E{S}_k|\sim (TI{D}_E^{k new},TI{D}_V^{i new},\gamma ,TI{D}_R^{j new})$$

P6: From P5, A3, and by applying the R4, we deduce

$$RS{U}_j|\equiv \#(TI{D}_E^{k new},TI{D}_V^{i new},\gamma ,TI{D}_R^{j new})$$

P7: From P5, P6, and by applying the R2, we deduce

$$RS{U}_j|\equiv E{S}_k|\equiv (TI{D}_E^{k new},TI{D}_R^{j new})$$

P8: From Msg6, we obtain

$$V_i⊲({\left\{\gamma \right\}}_{(M_2^i)},{\left\{TI{D}_R^{j new}\right\}}_{(X_i,Re{s}_i)},{\left\{TI{D}_V^{i new}\right\}}_{(X_i)},t{s}_3)$$

P9: From P8, A1, and by applying the R1, we deduce

$$V_i|\equiv RS{U}_j|\sim (\gamma ,TI{D}_R^{j new},TI{D}_V^{i new})$$

P10: From P9, A10, and by applying the R4, we deduce

$$V_i\#(\gamma ,TI{D}_R^{j new},TI{D}_V^{i new})$$

P11: From Msg, we obtain

$$E{S}_k⊲({\left\{S{K}_{jk}\right\}}_{(M_4^j)},t{s}_4)$$

P12: From P11, A4, and by applying the R1, we deduce

$$E{S}_k|\equiv RS{U}_j|\sim (S{K}_{jk})$$

P13: From P12, A12, and by applying the R4, we deduce

$$E{S}_k|\equiv \#(S{K}_{jk})$$

P14: From Msg, we obtain

$$RS{U}_j⊲(S{K}_{ij},t{s}_5)$$

P15: From P14, A5, and by applying the R1, we deduce

$$RS{U}_j|\equiv E{S}_k|\sim (S{K}_{ij})$$

P16: From P15, A13, and by applying the R4, we deduce

$$RS{U}_j|\equiv \#(S{K}_{ij})$$

P17: From P9, P10, A1 and by applying the R2, we deduce

$$V_i|\equiv RS{U}_j|\equiv (V_i\stackrel{S{K}_{ij}}{\leftrightarrow }RS{U}_j)(\mathrm{Goal}3)$$

P18: From P17, A6 and by applying the R3, we deduce

$$V_i|\equiv (V_i\stackrel{S{K}_{ij}}{\leftrightarrow }RS{U}_j)(\mathrm{Goal}1)$$

P19: From P12, P13, A9 and by applying the R2, we deduce

$$E{S}_k|\equiv RS{U}_j|\equiv (RS{U}_j\stackrel{S{K}_{jk}}{\leftrightarrow }E{S}_k)(\mathrm{Goal}8)$$

P20: From P19, A15 and by applying the R3, we deduce

$$E{S}_k|\equiv (RS{U}_j\stackrel{S{K}_{jk}}{\leftrightarrow }E{S}_k)(\mathrm{Goal}6)$$

P21: From P7 and A5, we deduce

$$RS{U}_j|\equiv E{S}_k|\equiv (RS{U}_j\stackrel{S{K}_{jk}}{\leftrightarrow }E{S}_k)(\mathrm{Goal}7)$$

P22: From P2, A14, and by applying the R3, we deduce

$$RS{U}_j|\equiv (RS{U}_j\stackrel{S{K}_{jk}}{\leftrightarrow }E{S}_k)(\mathrm{Goal}5)$$

P23: From P15, P16, and by applying the R2, we deduce

$$RS{U}_j|\equiv V_i|\equiv (V_i\stackrel{S{K}_{ij}}{\leftrightarrow }RS{U}_j)(\mathrm{Goal}4)$$

P24: From P23, A, and by applying the R2, we deduce

$$RS{U}_j|\equiv (V_i\stackrel{S{K}_{ij}}{\leftrightarrow }RS{U}_j)(\mathrm{Goal}2)$$

The above reasoning achieves all security goals, showing that the proposed scheme passes the BAN logical verification analysis.

5.2. Formal Analysis Using ROR Oracle Model

In this section, we employ the Real-Or-Random (ROR) model [38] to evaluate the semantic security of the proposed scheme. The participating entity types include a vehicle (V), a roadside unit (RSU), an edge server (ES), and a cloud management center (CMC). Their respective instances are denoted as ${\Pi }_V^i,{\Pi }_{RSU}^j,{\Pi }_{ES}^k,{\Pi }_{CMC}^l$.

In the model, the capabilities of adversary $\mathcal{A}$ are defined through a set of queries. The specific queries are detailed in

Table 5. Queries executable by adversary $\mathcal{A}$.

Queries	Description
Execute (${\Pi }_V^i,{\Pi }_{RSU}^j,{\Pi }_{ES}^k,{\Pi }_{CMC}^l$)	This query simulates adversary $\mathcal{A}$’s passive eavesdropping capability. When $\mathcal{A}$ invokes this query, challenger C will return messages transmitted among (${\mathsf{\Pi }}_{\mathrm{V}}^{\mathrm{i}},{\mathsf{\Pi }}_{\mathrm{R}\mathrm{S}\mathrm{U}}^{\mathrm{j}},{\mathsf{\Pi }}_{\mathrm{E}\mathrm{S}}^{\mathrm{k}},{\mathsf{\Pi }}_{\mathrm{C}\mathrm{M}\mathrm{C}}^{\mathrm{l}}$) over the public channel.
Send(${\Pi }_{\Delta }^o,Msg$)	After $\mathcal{A}$ sends a request message Msg to ${\mathsf{\Pi }}_{\mathsf{\Delta }}^{\mathsf{o}}$, C will return the corresponding response message to $\mathcal{A}$.
Corrupt(${\Pi }_V^i$)	By executing this query, $\mathcal{A}$ can obtain the secret parameters stored in the vehicle’s OBU.
Reveal(${\Pi }_{\Delta }^o$)	When $\mathcal{A}$ initiates a Reveal query against ${\mathsf{\Pi }}_{\mathsf{\Delta }}^{\mathsf{o}}$, C checks ${\mathsf{\Pi }}_{\mathsf{\Delta }}^{\mathsf{o}}$‘s state; if its state is accepted, C returns the session key (SK) established between ${\mathsf{\Pi }}_{\mathsf{\Delta }}^{\mathsf{o}}$ and its partner, otherwise, C returns null.
Test(${\Pi }_{\Delta }^o$)	This query may only be invoked once by $\mathcal{A}$, and ${\mathsf{\Pi }}_{\mathsf{\Delta }}^{\mathsf{o}}$ must satisfy the freshness requirement. When $\mathcal{A}$ invokes this query, C randomly selects a bit b∈{0, 1}. If b = 1, C returns the actual session key established with its partner; if b = 0, C returns to $\mathcal{A}$ a random string of equal length to the session key.

.

• Partnership: If two instances are partners, they must satisfy the following conditions:

(1)

They are in the same session.

(2)

They can send and receive corresponding messages to and from each other.

(3)

Other instances besides them will not accept the session keys established between them.

• Freshness: If ${\Pi }_{\Delta }^o$ is deemed fresh, it must satisfy the following conditions:

(1)

${\Pi }_{\Delta }^o$ is in the accepted state. It indicates that ${\Pi }_{\Delta }^o$ has successfully completed the session.

(2)

A has never called Send query for ${\Pi }_{\Delta }^o$.

(3)

${\Pi }_{\Delta }^o$ and its partners have not been queried by $\mathcal{A}$ using Reveal().

• Session Key Semantic Security: The advantage of adversary $\mathcal{A}$ is a precise definition quantifying the probability of $\mathcal{A}$’s attack succeeding beyond random guessing. If adversary $\mathcal{A}$ performs a Test() query on a fresh instance and successfully returns the correct guess b’ = b, this indicates $\mathcal{A}$’s success. Advantage $\mathcal{A}$ is defined as $Ad{v}_{\mathcal{A}}=2|P[b^{\prime }=b]-1/2|$. If $Ad{v}_{\mathcal{A}}$ is negligible for any polynomial-time adversary $\mathcal{A}$, then our proposed scheme is secure.

Theorem 1.

Suppose there exists an adversary$\mathcal{A}$ running in polynomial time whose goal is to undermine the semantic security of session keys in the proposed scheme.$\mathcal{A}$’s winning advantage in the ROR security game is defined as

$$\begin{array}{ll}Ad{v}_{\mathcal{A}}& \le {\displaystyle \frac{{\displaystyle {\sum }_{i=1}^4{q}_{H_i}^2}}{2^{(l_1+1)}}}+{\displaystyle \frac{q_{puf}^2}{2^{(l_2+1)}}}+{\displaystyle \frac{3{(q_S^{OS\delta }+q_E^{OS\delta })}^2}{2p}}+{\displaystyle \frac{{(q_S^{OS\delta }+q_E^{OS\delta })}^3}{6p^2}}+{\displaystyle \frac{q_S^2}{2^{l_1}}}\\ & +Max\{C_Z\times q_S^s,{\displaystyle \frac{q_S}{2^u}}\}+Ad{v}_{\mathcal{A}}^{ECDHP}\end{array}$$

We prove this theorem through the following game.

Proof of Theorem 1.

Game 0: Game 0 is the initial game, simulating the protocol’s execution in a real-world environment. $\mathcal{A}$ can initiate all oracle queries (Send(), Execute(), Reveal(), Corrupt()) to C, who will return the corresponding responses. Game 0 defines $\mathcal{A}$’s attack capabilities within the actual protocol. The adversary’s advantage is defined as

$$Ad{v}_{\mathcal{A}}=|2\times Ad{v}_{\mathcal{A},Game0}-1|$$

(1)

Game 1: In Game 1, a hash oracle query $H_i$ is defined. C maintains a list, List($H_i$), of Hash oracle queries. If $\mathcal{A}$ invokes a hash oracle query on message m, C queries List($H_i$). If the list contains a matching $〈m,H_i(m)〉$ entry, C directly returns it to $\mathcal{A}$. If no matching entry is found, C selects a uniform random output value $H_i(m)$, returns this randomly generated hash value to $\mathcal{A}$, and adds < m, $H_i(m)$ > to List($H_i$). Game 1 is identical to Game 0, so we have

$$|Ad{v}_{\mathcal{A},Game1}-Ad{v}_{\mathcal{A},Game0}|=0$$

(2)

Game 2: Simulates all oracle queries from Game 1 and, building upon Game 1, defines three types of collisions using the birthday paradox [39]:

(1)

Probability of hash function collisions:

$$P_H={\displaystyle \frac{{\displaystyle {\sum }_{i=1}^4{q}_{H_i}^2}}{2^{(l_1+1)}}}$$

(2)

Probability of PUF collision:

$$P_{puf}={\displaystyle \frac{q_{puf}^2}{2^{(l_2+1)}}}$$

The probability of a collision between random numbers in OS1 and OS2 is

$$P_{nonce}={\displaystyle \frac{3{(q_S^{OS\delta }+q_E^{OS\delta })}^2}{2p}}+{\displaystyle \frac{{(q_S^{OS\delta }+q_E^{OS\delta })}^3}{6p^2}}(\delta =1,2)$$

Therefore,

$$\begin{array}{ll}|Ad{v}_{\mathcal{A},Game2}-Ad{v}_{\mathcal{A},Game1}|& \le {\displaystyle \frac{{\displaystyle {\sum }_{i=1}^4{q}_{H_i}^2}}{2^{(l_1+1)}}}+{\displaystyle \frac{q_{puf}^2}{2^{(l_2+1)}}}+{\displaystyle \frac{3{(q_S^{OS\delta }+q_E^{OS\delta })}^2}{2p}}\\ & +{\displaystyle \frac{{(q_S^{OS\delta }+q_E^{OS\delta })}^3}{6p^2}}(\delta =1,2)\end{array}$$

(3)

Game 3: Simulates all queries from Game 2, but in this game, adversary $\mathcal{A}$ directly obtains certain authentication-related values without invoking the hash oracle query. Therefore, in this game, we can conclude that

$$|Ad{v}_{\mathcal{A},Game3}-Ad{v}_{\mathcal{A},Game2}|\le {\displaystyle \frac{q_S^2}{2^{l_1}}}$$

(4)

Game 4: Simulates all queries from Game 3. In this game, we specifically consider the scenario where $\mathcal{A}$ invokes the Corrupt() query to query C, and C returns the corresponding response to $\mathcal{A}$. $\mathcal{A}$ can extract $\{A_i,B_i,C_i,{TID}_V^i\}$ from the OBU. $\mathcal{A}$ attempts to compute $X_i$, but lacks the correct ${PID}_U^i$ and ${PPW}_U^i$, making $X_i$ calculation infeasible. Furthermore, $\mathcal{A}$ cannot construct a valid ${TID}_V^i$. Applying Zipf’s Law [40], we conclude that $C_Z,q_S^s$ are two core parameters in Zipf’s Law:

$$|Ad{v}_{\mathcal{A},Game4}-Ad{v}_{\mathcal{A},Game3}|\le Max\{C_Z\times q_S^s,{\displaystyle \frac{q_S}{2^u}}\}$$

(5)

Game 5: In this game, we consider the problem that $\mathcal{A}$ must solve to construct the correct session key. For the session key SK to be established, $\mathcal{A}$ must solve the ECDH problem. Therefore, we conclude that

$$|Ad{v}_{\mathcal{A},Game5}-Ad{v}_{\mathcal{A},Game4}|\le Ad{v}_{\mathcal{A}}^{ECDHP}$$

(6)

In this game, $\mathcal{A}$ can only make random guesses. If $\mathcal{A}$ initiates any other queries, the game terminates. Therefore, $\mathcal{A}$ holds no advantage in this game, and we conclude that

$$Ad{v}_{\mathcal{A},Game5}={\displaystyle \frac{1}{2}}$$

(7)

By combining (1), (2) and (7), we can obtain

$$\begin{array}{ll}{\displaystyle \frac{1}{2}}Ad{v}_{\mathcal{A}}& =|Ad{v}_{\mathcal{A},Game0}-{\displaystyle \frac{1}{2}}|=|Ad{v}_{\mathcal{A},Game1}-{\displaystyle \frac{1}{2}}|\\ & =|Ad{v}_{\mathcal{A},Game0}-Ad{v}_{\mathcal{A},Game5}|\end{array}$$

(8)

Then, through (3)–(6) and (8), we obtain

$$\begin{array}{ll}{\displaystyle \frac{1}{2}}Ad{v}_{\mathcal{A}}& =|Ad{v}_{\mathcal{A},Game1}-Ad{v}_{\mathcal{A},Game4}|\\ & \le |Ad{v}_{\mathcal{A},Game1}-Ad{v}_{\mathcal{A},Game2}|\\ & +|Ad{v}_{\mathcal{A},Game2}-Ad{v}_{\mathcal{A},Game3}|\\ & +|Ad{v}_{\mathcal{A},Game3}-Ad{v}_{\mathcal{A},Game4}|\\ & +|Ad{v}_{\mathcal{A},Game4}-Ad{v}_{\mathcal{A},Game5}|\\ & \le {\displaystyle \frac{{\displaystyle {\sum }_{i=1}^4{q}_{H_i}^2}}{2^{(l_1+1)}}}+{\displaystyle \frac{q_{puf}^2}{2^{(l_2+1)}}}+{\displaystyle \frac{3{(q_S^{OS\delta }+q_E^{OS\delta })}^2}{2p}}+{\displaystyle \frac{{(q_S^{OS\delta }+q_E^{OS\delta })}^3}{6p^2}}\\ & +{\displaystyle \frac{q_S^2}{2^{l_1}}}+Max\{C_Z\times q_S^s,{\displaystyle \frac{q_S}{2^u}}\}+Ad{v}_{\mathcal{A}}^{ECDHP}\end{array}$$

Thus, we obtain Theorem, which proves the security of our scheme under the ROR model. □

5.3. Formal Analysis Using AVISPA

We employed the formal verification tool AVISPA to conduct security analysis on our designed protocol, which can demonstrate whether our protocol possesses fundamental security properties and the ability to defend against critical attacks. AVISPA [41] stands for “Automated Verification of Internet Security Protocols and Applications.” It provides an advanced protocol specification language called “HLPSL [42].” We employ HLPSL to describe our security protocols and use the “HLPSL2IF” translator to convert the HLPSL specification into an “Intermediate Format (IF)” specification. IF is a lower-level language specification than HLPSL, enabling it to be directly read by the backend modules of AVISPA tools. AVISPA tools comprise four backend modules [41]: The “On-the-Fly Model-Checker” (OFMC), which efficiently verifies protocol security in bounded sessions through dynamic symbolic (Dolev–Yao) model checking; The CL-based Model-Checker (CL-AtSe) converts the security specifications of a protocol into a set of logical constraints, such as message freshness and consistency. By solving these logical constraints, it identifies various potential attacks against the protocol, including replay attacks and key leakage; the SAT-based Model-Checker (SATMC) transforms protocol security verification problems into satisfiability problems (SATs), then employs SAT solvers to automatically detect security vulnerabilities within protocols; Tree Automata-based Protocol Analyzer (TA4SP) models and analyzes protocols using tree automata theory, primarily verifying protocol security under unbounded sessions or complex message structures.

AVISPA permits malicious adversaries to participate throughout the entire protocol interaction process during protocol analysis. These adversaries are granted the ability to intercept, tamper with, replay, and forge messages. Potential attacks they may execute include Man-in-the-Middle (MITM) attacks, type obfuscation attacks, and impersonation attacks targeting legitimate users. The simulation results of our protocol under this tool are shown in Figure 4 below. These results demonstrate that our protocol can withstand multiple malicious attacks.

5.4. Informal Security Analysis

In this section, we demonstrate the security features of the proposed scheme.

(1)

Vehicle OBU Physical Capture Attack: Suppose adversary $\mathcal{A}$ reads the information $\{A_i,B_i,C_i,{TID}_V^i\}$ stored within the OBU through a physical attack. However, the secret credentials are protected, preventing $\mathcal{A}$ from obtaining the registered user’s name and password, thus unable to compute the secret credentials. More importantly, we employ a PUF for defense in the information construction. The PUF generates a unique and irreplicable identifier based on the unavoidable microscopic variations inherent in the vehicle’s hardware manufacturing process. Although environmental disturbances may cause errors in the generated identifier, error correction is achievable through measures like BCH error-correcting codes and Fuzzy Extractors. Should adversary $\mathcal{A}$ attempt to disassemble the OBU to clone the PUF, the PUF will cease to produce valid outputs, rendering it inoperable. Consequently, adversary $\mathcal{A}$ cannot reconstruct the PUF.

(2)

Replay Attack: We apply the timestamp property to all communication messages involved in the mutual authentication and key establishment phases (${ts}_1,{ts}_2,{ts}_3,{ts}_4\dots$). If $\mathcal{A}$ intercepts a message sent by the sender and replays it to the receiver, this replayed message will also be rejected by the receiver due to failing to satisfy the timestamp’s freshness requirement. Therefore, our scheme is resistant to replay attacks.

(3)

Impersonation Attack: If adversary $\mathcal{A}$ attempts to intercept messages transmitted over the public channel and impersonate a legitimate vehicle, they must first forge the information {M1, M2, Q} and attempt verification with the regional RSU. Since adversary $\mathcal{A}$ has not been legitimately registered with the CMC, this will result in verification failure by the regional RSU.

(4)

MITM Attack: Suppose $\mathcal{A}$ eavesdrops on and intercepts messages in the channel and attempts to reconstruct a valid message ${(Msg}_1,{Msg}_2,{Msg}_3\dots )$. However, since $\mathcal{A}$ lacks knowledge of the secret credentials between entities (such as $X_i,Y_j,Z_k,$ etc.), and all messages are secured through hash operations and XOR operations, it is extremely difficult for $\mathcal{A}$ to accomplish this. Therefore, our scheme is resistant to such attacks.

(5)

Anonymity: All entities within the system are represented by temporary identifiers (${TID}_V^i,{TID}_R^j,{TID}_E^k$) instead of their actual names. These TIDs are dynamically updated during each authentication process (${{TID}_V^i}^{ new},{{TID}_R^j}^{ new},{{TID}_E^k}^{ new}$), ensuring that adversary $\mathcal{A}$ remains unaware of the entities’ true identities. Consequently, the anonymity of the entities is guaranteed.

(6)

Traceability: When an entity exhibits abnormal behavior and engages in malicious actions, CMC can extract the true identity of the anomalous entity using the system private key and track it. Therefore, our scheme satisfies this characteristic.

(7)

Data Integrity Protection: In the proposed scheme, message integrity verification is performed for every message transmitted over the public channel, effectively preventing malicious attackers from tampering with messages. The receiver reconstructs ${Int}_n,n=\mathrm{1,2},3\dots$ from all received messages. If ${{Int}_n}^{*}\ne {Int}_n(n=\mathrm{1,2},3\dots )$, the message is immediately discarded, and the session with the sender is terminated.

(8)

Perfect Forward Secrecy: The proposed scheme establishes a temporary session key for each communication authentication, with distinct session keys generated for different session instances. Suppose an adversary $\mathcal{A}$ obtains messages $M_1=\alpha \times P$ and $M_3=\beta \times P$. To derive the random numbers α and β, it must solve an ECDL problem. Since it lacks the entity’s private key, calculating $M_2$ and $M_4$ remains infeasible. Furthermore, even if the system key is compromised, the adversary cannot compute SK because it lacks knowledge of $X_i,Y_j,Z_k$and the vehicle’s challenge–response pairs. Thus, our scheme guarantees forward secrecy.

6. Performance Analysis

In this section, we analyze the performance of the proposed scheme in terms of communication overhead and computational overhead, comparing it with existing schemes. Since all compared schemes involve authentication among three entities, our analysis of the proposed scheme OS1 includes the requesting vehicle, ES, and CMC; while for scheme OS2, the entities analyzed are the requesting vehicle, the auxiliary vehicle, and CMC. The primary focus here is on evaluating the protocol’s performance during mutual authentication and key establishment phases.

6.1. Computation Overhead

The computational overhead is primarily determined by the time required to execute cryptographic operations during the authentication process. In

Table 6. Cryptographic operation execution time.

Operation	Description	Execute Time (ms)
$T_H$	The execution time of a one-way hash function.	0.002
$T_{EPA}$	The execution time of this elliptic curve addition operation.	0.004
$T_{EPM}$	The execution time of this elliptic scalar multiplication operation.	0.682
$T_{BP}$	The execution time of the bilinear pairing.	2.904
$T_E/T_D$	The execution time of this symmetric encryption and decryption.	0.008

, we list the relevant cryptographic operations and the respective time required for their execution.

In OS1, the requesting vehicle performed a total of eight hash encryption operations, taking 0.016 ms to execute. The edge server (ES) performed a total of eleven hash encryption operations, one elliptic curve point multiplication operation, and two symmetric encryption/decryption operations, taking 0.72 ms to execute. The cloud management center (CMC) performed a total of thirteen hash encryption operations and two symmetric encryption/decryption operations, taking 0.042 ms. In OS2, the requesting vehicle (i) performed a total of eight hash encryption operations and one elliptic curve point multiplication operation, with an execution time of 0.698 ms. The auxiliary vehicle (m) performed a total of nine hash encryption operations, one elliptic curve point multiplication operation and one symmetric encryption/decryption operation, with an execution time of 0.708 ms. The cloud management center (CMC) performed a total of thirteen hash encryption operations, two elliptic curve point multiplication operations, and one symmetric encryption/decryption operation, taking 1.398 ms to complete. Similarly, the computational overhead of other schemes is calculated using the same method. Since XOR is an atomic operation, we do not consider the time spent executing XOR here.

A detailed comparison of computational overhead between the proposed scheme and other existing relevant schemes is presented in

Table 7. Comparative analysis of scheme computational overhead.

Scheme	Vehicles/Users	ES/Fog Node	CMC/Cloud Server
J. Oh et al. [43]	$12T_H+5T_{EPM}+4T_{BP}\approx 15.05\mathrm{m}\mathrm{s}$	$1T_H+3T_{EPM}+3T_{BP}\approx 10.76\mathrm{m}\mathrm{s}$	$10T_H+1T_{EPM}\approx 0.702\mathrm{m}\mathrm{s}$
Tomar et al. [44]	$8T_H+2T_{EPM}\approx 1.38\mathrm{m}\mathrm{s}$	$5T_H+2T_{EPM}\approx 1.374\mathrm{m}\mathrm{s}$	$9T_H+10/3T_{EPM}\approx 2.291\mathrm{m}\mathrm{s}$
Eftekhari et al. [45]	$11T_H+3T_{EPM}+1T_{EPA}\approx 2.072\mathrm{m}\mathrm{s}$	$12T_H+3T_{EPM}+1T_{EPA}\approx 2.074\mathrm{m}\mathrm{s}$	$15T_H+3T_{EPM}+2T_{EPA}\approx 2.084\mathrm{m}\mathrm{s}$
Chen et al. [46]	$9T_H+4T_{EPM}+1T_E/T_D\approx 2.754\mathrm{m}\mathrm{s}$	$8T_H+7T_{EPM}+3T_{EPA}+1T_E/T_D\approx 4.81\mathrm{m}\mathrm{s}$	$9T_H+8T_{EPM}+2T_{EPA}+1T_E/T_D\approx 5.49\mathrm{m}\mathrm{s}$
Awais et al. [30]	$7T_H+4T_{EPM}\approx 2.742\mathrm{m}\mathrm{s}$	$4T_H+5T_{EPM}\approx 3.418\mathrm{m}\mathrm{s}$	$9T_H+6T_{EPM}\approx 4.11\mathrm{m}\mathrm{s}$
OS1	${8T}_H\approx 0.016\mathrm{m}\mathrm{s}$	11$T_H+1T_{EPM}+2T_E/T_D\approx 0.72\mathrm{m}\mathrm{s}$	$13T_H+2T_E/T_D\approx 0.042\mathrm{m}\mathrm{s}$
OS2	$8T_H+1T_{EPM}\approx 0.698\mathrm{m}\mathrm{s}$	$9T_H+1T_{EPM}+1T_E/T_D\approx 0.708\mathrm{m}\mathrm{s}$	13$T_H+2T_{EPM}+1T_E/T_D\approx 1.398\mathrm{m}\mathrm{s}$

and Figure 5. We can observe that the proposed scheme exhibits superior lightweight characteristics, aligning with the requirements of the vehicle-to-everything (V2X) computing task offloading environment.

6.2. Communication Overhead

Communication overhead primarily quantifies the number of message bits transmitted during a complete authentication process. We primarily investigate the communication overhead incurred during the authentication and key establishment phases. In the proposed scheme, we define the identity ID and PUF challenge response as 80 bits, the timestamp as 32 bits, and the elliptic curve point as 257 bits due to its compressibility, and message ${int}_i$ and $W_i$ are 128 bits. Additionally, the scheme employs a 256-bit hash function (SHA-256) and 256-bit random numbers.

In OS1, the messages that need to be exchanged between the requesting vehicle, ES, and CMC include ${Msg}_1^{V2I}=\{{Auth}_V^i,U_1,{TID}_V^i,{Int}_1,{ts}_1\}$, ${Msg}_3^{V2I}=\{E_1,{TID}_E^k,{Int}_3,{ts}_3\}$, ${Msg}_4^{V2I}=\{E_2,{Int}_4,{ts}_4\}$, and ${Msg}_7^{V2I}=\{{U_5}^{*},U_8,{Int}_6,{ts}_7\}$. The sizes corresponding to the messages are (256 + 288 + 256+ 128 + 32 = 960 bits), (800 + 256 + 128 + 32 = 1216 bits), (1392 + 128 + 32 = 1552 bits), and (336 + 256 + 128 +32 = 752 bits), respectively; therefore, the total communication overhead is 4480 bits. Similarly, in OS2, the messages that need to be exchanged between the requesting vehicle, the auxiliary vehicle, and the CMC include ${Msg}_1^{V2V}=\{V_1,{Auth}_V^i,{TID}_V^i,W_1,{ts}_1\}$, ${Msg}_2^{V2V}=\{{W_2,V}_1,{Auth}_V^i,{TID}_V^i,V_2,{Auth}_V^m,{TID}_V^m,{ts}_2\}$, ${Msg}_3^{V2V}=\{S_1,{Int}_3,{ts}_3\}$, and ${Msg}_4^{V2V}=\{{V_5}^{*},{V_6}^{*},W_4,{ts}_4\}$. The sizes corresponding to the messages are (256 + 256+ 256+ 128 + 32 = 928 bits), (128 + 256 + 256 + 256 + 256 + 256 + 256 + 32 = 1696 bits), (1216 + 128 + 32 = 1376 bits), and (256 + 336 + 128 +32 = 752 bits), respectively; as a result, the communication overhead in OS2 is 4752 bits. For the other schemes we compare, we employ the same computational approach. A comparative analysis of communication overhead is presented in

Table 8. Communication overhead of participating entities.

Scheme	Vehicles/Users	ES/Fog Node	CMC/Cloud Server
J. Oh et al. [43]	2629 bits	546 bits	1316 bits
Tomar et al. [44]	1312 bits	3392 bits	1312 bits
Eftekhari et al. [45]	1137 bits	3012 bits	1281 bits
Chen et al. [46]	288 bits	2148 bits	2084 bits
Awais et al. [30]	769 bits	2822 bits	1283 bits
OS1	960 bits	1968 bits	1376 bits
OS2	928 bits	2448 bits	1552 bits

and Figure 6.

6.3. Comparison of Security Features

This section compares the security features of the proposed solution with those of the existing scheme.

Table 9. Security features analysis.

Security Attributes	J. Oh et al. [43]	Tomar et al. [44]	Eftekhari et al. [45]	Chen et al. [46]	Awais et al. [30]	OS1/OS2
SA-1	YES	YES	YES	NO	YES	YES
SA-2	NO	NO	NO	NO	NO	YES
SA-3	YES	YES	YES	NO	NO	YES
SA-4	YES	YES	YES	YES	YES	YES
SA-5	YES	YES	YES	YES	YES	YES
SA-6	YES	NO	YES	YES	YES	YES
SA-7	YES	YES	YES	YES	YES	YES
SA-8	NO	NO	NO	YES	NO	YES
SA-9	YES	YES	YES	YES	YES	YES

summarizes the security characteristics of the schemes.

Note: SA-1: “Entity Anonymity”; SA-2: “Capture Physical Attack”; SA-3: “Reply Attack”; SA-4: “Mutual Authentication”; SA-5: “MITM Attack”; SA-6: “Entity Impersonation Attack”; SA-7: “Traceability”; SA-8: “Integrity Verify”; SA-9: “Privileged Insider Attack”. (“YES” indicates possession; “NO” indicates non-possession.)

7. Simulation Using NS-3

NS-3 [47] is a discrete-event-driven, open-source network simulator that offers outstanding functionality and flexibility. With its extensive model library and modular design, NS-3 provides powerful extensibility. In this section, we employ NS-3 to conduct simulation studies on the proposed scheme, evaluating its performance at the network layer.

7.1. Simulation Environment

The relevant network parameters used in the simulation process are shown in

Table 10. Simulation parameters.

Parameters	Value
Platform	Ubuntu 20.04
Simulation tool	NS-3 (3.33)
Routing protocol	OLSR
Network area	2 km
Number of vehicles	(20, 40, 60)
Number of ESs	5 (Scenario 1), 7 (Scenario 2), 9 (Scenario 3)
Number of CMC	1 (Scenario 1, Scenario 2, Scenario 3)
Mobility of vehicles	(0–54 km/h)
Protocol standard	IEEE 802.11 [48]
Simulation time	800 s

below. The entities involved in the simulation include vehicles, ES, and CMC, with OS1 serving as an example. In the proposed scheme, the communication overhead for messages {${Msg}_1^{V2I}$,${Msg}_3^{V2I}$,${Msg}_4^{V2I}$,${Msg}_7^{V2I}$,${Msg}_8^{V2I}$} is {120 bytes, 152 bytes, 194 bytes, 94 bytes, 36bytes}, respectively. In scenarios 1, 2, and 3, we compared the performance resulting from varying numbers of vehicles and ESs. We evaluate the proposed scheme using three performance metrics: End-to-End Delay (EED), throughput, and Packet Delivery Rate (PDR).

7.2. End–End Delay (EED)

EED measures the average time taken for a data packet to travel from its source point (sender) to its destination point (receiver). Its calculation method is defined as $EED={\displaystyle \frac{\sum _{i=1}^{N_p}{T}_{{se}_i}-T_{{re}_i}}{N_p}}$. Here, $N_p$ denotes the total number of packets, $T_{{se}_i}$ represents the transmission time of packet $i$, and $T_{{re}_i}$ denotes the reception time of packet $i$. Figure 7 shows the performance of EED under three scenarios.

7.3. Throughput

Throughput is defined as the amount of effective data transmitted within a network per unit of time. It serves as another core metric for measuring network performance, fundamentally differing from EED. The calculation method for throughput is defined as $Throughput={\displaystyle \frac{\sum _{p=1}^{N_{re}}{Size}_p}{T_t}}$. Here, $N_{re}$ denotes the number of received data packets, ${Size}_p$ represents the size of the received data packets, and $T_t$ indicates the total duration of the statistical period. The throughput performance under the three scenarios is shown in Figure 8.

7.4. Packet Delivery Rate (PDR)

PDR is another core metric for measuring network stability and reliability, distinct from EED and throughput. Its mathematical representation for calculation is $PDR={\displaystyle \frac{N_{re}^{suc}}{N_{se}}}$. It is defined as the ratio of the number of packets successfully received by the destination (receiver) to the number of packets transmitted by the source (sender) within a specific time period. Figure 9 shows PDR performance under three scenarios.

8. Conclusions

To address security challenges in the offloading environment for vehicle-to-everything (V2X) computing tasks, we propose an authentication scheme among relevant entities involved in the offloading process. Rigorous analysis and evaluation demonstrate that this scheme satisfies the security properties required for V2X task offloading, effectively resisting common threats and attacks while safeguarding the legitimacy and privacy of the offloading process. However, significant work remains to establish a comprehensive, multi-layered security framework for vehicle-to-everything (V2X) computing task offloading.

The proposed scheme may face non-linear scalability issues under exponentially increasing vehicle traffic, potentially overloading the CMC. Therefore, future research will explore developing a dynamic mechanism based on this scheme that supports reauthentication and rapid authentication, making it more adaptable to high-speed, mobile network topologies. Second, even legitimate communication entities may exhibit malicious behavior during prolonged network interactions. Therefore, future research will focus on deeply integrating the foundational authentication proposed in this paper with higher-level behavioral trust management (e.g., PPRU and TCDEM). We aim to design a trust evaluation framework tailored for offloading computing tasks, thereby enhancing the security framework for V2X computing task offloading.

Additionally, in our research on V2X computing task offloading strategies, we will consider incorporating the computational and communication overhead generated by authentication into the strategy. We will establish a dynamic trust mechanism to achieve joint optimization of security and efficiency, thereby enhancing the reliability of V2X computing task offloading.