1.1 Key contributions and innovations

This study addresses core challenges in IoV identity authentication and key agreement by proposing an innovative blockchain-based solution. Compared to existing research, its primary contributions and innovations are as follows:

1. 1) Innovative multi-TA collaborative authentication architecture

Overcoming the limitations of traditional single-trusted-authority models, this research proposes a blockchain-based multi-trusted-authority collaborative authentication framework. By enabling trusted data sharing among authorities via smart contracts, it resolves cross-domain authentication challenges while significantly enhancing system scalability.

1. 2) Multi-layer security protection mechanism

Building upon conventional hash and XOR operations, it incorporates elliptic curve point multiplication and designs a dynamic blockchain pointer encryption mechanism, constructing a more robust security system resistant to various known attacks.

1. 3) Optimized network resource allocation strategy

Redefines the functional boundaries of roadside units, limiting them to data relay nodes while delegating core authentication computation tasks to trusted authorities. This architectural innovation reduces network load while minimizing potential security exposure.

1. 4) Efficient Vehicle-to-Vehicle key agreement protocol

Proposes a direct vehicle-to-vehicle key agreement mechanism based on blockchain-stored shared parameters. This significantly enhances authentication efficiency while maintaining high security, making it particularly suitable for high-density IoV environments.

1. 5) Comprehensive Security and Performance Validation

The solution undergoes multidimensional verification through formal BAN logic analysis, informal security arguments, and ProVerif simulation. By optimizing parameter storage and simplifying computational workflows, security is substantially enhanced without compromising computational or communication efficiency. Experimental results demonstrate acceptable overall performance compared to existing mainstream solutions.

1.2 Paper organization

The remainder of this paper is organized as follows: Section 2 introduces the fundamental concepts required for understanding the proposed scheme, including blockchain, ECC, and BAN logic. Section 3 systematically analyzes the limitations of existing authentication protocols and blockchain-based solutions, while identifying research gaps. Section 4 formally defines the system model, threat model, security objectives, and security measures. Section 5 elaborates on the blockchain-based multi-TA collaborative authentication mechanism, comprising three phases: system initialization, entity registration, mutual authentication and key agreement. Section 6 rigorously evaluates the security of the proposed scheme through BAN logic verification, informal security analysis, and formal validation using the ProVerif tool. Section 7 presents a comprehensive performance comparison with five state-of-the-art protocols in terms of computational and communication overhead. Finally, Section 8 summarizes the key contributions and discusses potential future research directions in IoV security.

2.1 Blockchain

The fundamental principles of blockchain comprise distributed storage, consensus mechanisms, and cryptographic algorithms. Distributed storage involves replicating and storing data across the network, while consensus mechanisms ensure data consistency among network nodes. Cryptographic algorithms are employed to safeguard the confidentiality and integrity of data. These basic principles collectively form the foundational architecture of blockchain, enabling decentralization while ensuring the security and reliability of data.

2.2 ECC

ECC is a public-key cryptographic system based on the mathematical structure of elliptic curves. Users can establish a secure elliptic curve by appropriately choosing parameters. The encryption and signature processes involve mathematical operations on points on the elliptic curve, including point addition, doubling, and other operations. Compared to traditional asymmetric encryption algorithms like RSA, ECC offers higher security with smaller key lengths, making it more suitable for resource-limited environments. The following subsections present the mathematical foundations and algorithms underlying ECC.

1. 1) Elliptic Curve Equation

Parameters:

p: Large prime defining finite field F_p

a,b: Curve coefficients (4a³+27b2  ≡ 0(mod p))

G.

: Basepoint (generator) of prime order n

1. 2) Elliptic Curve Diffie-Hellman (ECDH)

Key Generation:

Alice: Private key d_A[1, n−1], Public key Q_A=d_AG

Bob: Private key d_B[1,n−1], Public key Q_A=d_BG

Shared Secret Calculation:

Security: Relies on ECDH assumption (hard to compute d_Ad_BG given Q_A, Q_B)

1. 3) Elliptic Curve Digital Signature Algorithm (ECDSA)

Signature Generation (for message m):

Compute hash h = H(m), interpreted as integer in Z_n, Select random k[1, n − 1], Compute (x,y)=kG, Output signature (r, s): r = x mod n, s = k⁻¹(h + d_Ar) mod n.

Signature Verification:

Verify r, s∈[1,n − 1], Compute h = H(m)h, Calculate: u₁ ≡ hs⁻¹(mod n), u₂ ≡ rs⁻¹(mod n), (x,y)=u₁G+u₂Q_A.

Accept if r ≡ x (mod n).

2.3 BAN logic

BAN logic, proposed by Burrows, Abadi, and Needham in 1989, is a formal approach for analyzing and verifying cryptographic protocols. It translates protocol messages into logical formulas and applies inference rules to derive the beliefs and knowledge of the participating entities. By enabling structured analysis, BAN logic aids in identifying and addressing vulnerabilities to bolster the overall robustness of cryptographic systems.

3.1 Authentication schemes for in-vehicle self-organizing networks

1. 1) Conditional Privacy-Preserving Authentication with Efficient Revocation Mechanisms

This category includes schemes that achieve conditional privacy while optimizing communication and computational efficiency via novel revocation mechanisms. Zhong et al.[2] proposed a conditional privacy-preserving authentication scheme based on registration lists, which reduces communication overhead by substituting traditional revocation lists and mitigates malicious vehicle behavior. Alazzawi et al.[3] proposed a novel pseudo-identity-based solution for achieving conditional anonymity in Vehicular Ad Hoc Networks (VANETs), which discards bilinear pairings and certificate revocation lists, thus significantly improving the efficiency of signing and authentication. However, Al-Shareeda et al.[4] identified that the scheme of Alazzawi et al. suffers from vulnerabilities in privacy preservation and unlinkability, fails to provide password modification functionality, and is susceptible to side-channel attacks. To address these issues, Al-Shareeda et al. redesigned a conditional privacy-preserving authentication scheme based on elliptic curve cryptography, effectively resolving the aforementioned problems.

Overall, existing conditional privacy-preserving schemes still have room for improvement in achieving efficient revocation and privacy trade-offs, particularly lacking lightweight solutions that simultaneously satisfy low communication overhead, strong privacy protection, and resistance to physical side-channel attacks.

1. 2) Certificateless and lightweight authentication architectures

These schemes eliminate traditional certificate management through certificateless or identity-based cryptographic constructs while maintaining low computational overhead. Cui et al.[5] proposed an extensible authentication mechanism for multi-cloud environments, leveraging ECC and simplifying service selection complexity through cloud brokers to meet diversified service demands. Liu et al.[6] proposed an authentication scheme integrating anonymous identity generation, trust authority verification, and a reputation evaluation mechanism to dynamically assess vehicle credibility based on historical interaction behavior. Ma et al.[7] proposed a scheme that does not rely on bilinear pairings, supporting mutual authentication and generates secure session keys for secret communication while preserving privacy. Wu et al.[8] introduced a certificateless aggregated signatures scheme for IoV to address the problem of frequent key updates by vehicles. Tangade et al.[9] proposed an identity-based scheme utilizing keyed-Hash Message Authentication Code (HMAC) that employs reward points to calculate vehicle trust values. However, it does not support batch verification of messages and signatures. Su et al.[10] proposed a scheme for Vehicle-to-Grid (V2G) networks employing non-supersingular elliptic curves.

Although certificateless and lightweight architectures eliminate complex certificate management, most solutions still face the following challenges: difficulty in efficiently supporting batch verification across large-scale vehicular networks, communication overhead caused by frequent key updates, and ensuring equivalent security levels without introducing bilinear pairing operations.

1. 3) Multi-factor and physically enhanced authentication schemes

This category encompasses methods that incorporate Physical Unclonable Functions (PUF), biometrics, or multi-factor protocols to enhance security and resilience against physical attacks. Li et al.[11] proposed a scheme based on anonymous identity, introducing a new authentication architecture and hiding the computation of the user’s identity through a one-way hash function to enhance privacy and security. Alfadhli et al.[12] proposed a scheme combining PUFs and one-time dynamic pseudo-identities as factors for authentication to improve overall security and efficiency. Xu et al.[13] proposed a scheme that delineates distinct roles within system operations. During the initialization phase, the System Administrator (SA) performs security registration in a specified environment. Subsequently, the TA takes responsibility for disseminating authentication parameters to the RSUs. Umar et al.[14] proposed a PUF-based scheme for secure and efficient data transfer over public channels, though its anonymity relies on trusted third parties for pseudonym updates. Jiang et al.[15] proposed a PUF-based scheme integrating PUFs, passwords, and biometrics to achieve multifactor authentication, thus increasing the difficulty of forgery by adversaries.

While incorporating physical factors such as PUFs or biometrics enhances security, it also introduces new challenges, including the instability of PUF responses, privacy concerns for biometric templates, and increased user experience complexity and deployment costs associated with multi-factor protocols.

1. 4) Advanced cryptographic protocols and group-oriented authentication

These approaches employ advanced cryptographic techniques such as chaotic maps, puncturable signatures, and group authentication to achieve scalability, forward secrecy, and efficient batch verification. Wei et al.[16] proposed a bidirectional anonymous traceable group authentication scheme for IoV. Their scheme manages multiple RSUs through fast dynamic grouping and uses the unidirectional trapdoor nature and semigroup property of Chebyshev chaotic mapping to authenticate the access of vehicles entering the RSU groups. Hou et al.[17] introduced a lightweight PUF into the authentication scheme and integrated the in-vehicle unit with a 5G Subscriber Identity Module (SIM) card to address identity forgery issues. Sripathi et al.[18] proposed a scheme for nonlinear pairings that supports batch verification by using a certificate-less signature mechanism to avoid certificate management and key escrow issues. Xie et al.[19] employed PUFs to resist RSU capture attacks while enhancing security through a three-factor secrecy strategy. Hou et al.[20] proposed an efficient two-factor authentication protocol by integrating blockchain with Trusted Execution Environment (TEE) technology, which not only guarantees anonymity but also reduces computational overhead. Jiang et al.[21] developed a two-level security framework based on blockchain and ensemble learning, achieving lightweight authentication via PUF while utilizing Whale Optimization Algorithm (WOA) and Extreme Gradient Boosting (XGBoost) for malicious attack detection. Xiong et al.[22] introduced a mutual authentication protocol supporting fine-grained forward/backward security through the combination of puncturable signatures and parallel key-insulated proxy re-signature schemes. Bhatt et al.[23] proposed a blockchain-based conditional privacy-preserving authentication scheme for temporary platoon communications, reducing RSU reliance and infrastructure costs while incorporating an accident prevention mechanism. Ibrahim et al.[24] proposed the PPA6-IoV protocol featuring a six-step authentication process to preserve vehicle privacy while effectively reducing both communication and computational costs. Zhang et al.[25] proposed a system based on a trusted connection architecture, which introduced a platform authentication mechanism and effectively improved communication security in IoV environments.

Group authentication and advanced cryptographic protocols—such as chaotic mapping and puncturable signatures—demonstrate advantages in scalability and forward secrecy. However, their computational complexity is typically high, and most schemes fail to achieve efficient group dynamic management within highly dynamic vehicular ad hoc networks.

1. 5) Decentralized IoV authentication

Recent research emphasizes the shift toward decentralized authentication in the IoV to address scalability, security, and privacy challenges. The edge enhancement protocol proposed by Lo et al.[26] reduces cloud dependencies and improves system resilience by leveraging a consortium blockchain. The BAKARI (Blockchain-Powered AKA Scheme with a Reputation-Centric) proposed by Mukathe et al.[27] is a blockchain-based key agreement scheme with reputation incentives. Haider et al.[28] proposed the Blockchain Enabled Secure Authentication Protocol for IoVs (BESA-IOV), which utilizes ECC and blockchain for a lightweight authentication mechanism to achieve the goal of reducing latency and cost. Borges et al.[29] proposed using decentralized reputation management to verify identity, and this approach has the advantage of ensuring identity security even in disconnected environments. Wang et al.[30] introduced BCADS, a blockchain-assisted cross-domain authentication scheme with decentralized identity for VANETs under strict oversight, enabling autonomous identifier management and reducing computational and communication costs by 36.6% and 87.1%. Liu et al.[31] proposed a Cybertwin-enabled distributed authentication scheme that employs lightweight cryptography and digital twins for real-time behavior tracking and dynamic trust distribution, reducing authentication latency in high-density vehicular environments.

Emerging decentralized solutions leverage technologies such as blockchain to mitigate single points of failure and trust issues. However, they still face widespread performance bottlenecks, including high transaction latency and substantial consensus overhead, and lack effective mechanisms to balance computational and communication loads between resource-constrained in-vehicle units and powerful backend systems.

3.2 Blockchain-related research in the field of IoV

1. 1) Authentication and Key Management Schemes

This category focuses on leveraging blockchain’s decentralization, immutability, and traceability to construct novel authentication frameworks and key management systems. Dorri et al.[32] presented an innovative lightweight and scalable blockchain system designed to meet the high demands of the IoV. However, their approach relies on centralized key management lists that are susceptible to compromise, leading to large-scale key compromise incidents. To address these challenges, Wang et al.[33] proposed a scheme for IoV that fully integrates blockchain technology, including consensus-mechanism-driven smart contracts and cryptographic accumulator-based Public Key Infrastructure (PKI) mechanisms. Zhang et al.[34] proposed a blockchain-based asymmetric group key agreement protocol for IoV, aiming to protect user privacy through anonymous authentication techniques. Qureshi et al.[35] proposed an efficient, secure, and anonymous blockchain-based conditional privacy protection and authentication mechanism. They implemented a blockchain using Hyperledger Fabric to enable vehicle nodes to share data anonymously and maintain anonymity, traceability, and unlinkability during data communication. Ma et al.[36] proposed an innovative decentralized key management scheme in the field of VANETs, with the main goal of achieving automatic registration, updating, and revocation of users’ public keys to ensure communication security. However, this scheme may introduce high computational complexity for resource-constrained devices in VANETs. Lin et al.[37] employed blockchain technology to solve key update and certificate management challenges in public key cryptographic authentication systems. They combined blockchain technology with key derivation algorithms to proactively manage certificates for secure authentication. Li et al.[38] proposed a blockchain-assisted revocable cross-domain authentication scheme for VANETs, supporting different authentication methods across domains and enabling malicious vehicle revocation via group public key updates while avoiding blockchain-induced latency. Akhter et al.[39] designed a blockchain-based switching authentication scheme to reduce the redundant computational overhead incurred by vehicles when switching RSUs. Singh et al.[40] proposed a lightweight group-based authentication protocol for 5G-enabled IoV networks, achieving mutual authentication, forward/backward secrecy, and session unlinkability. AVISPA and BAN logic validation confirm attack resistance, with signaling overhead reduced by 47.3% and bandwidth consumption by 32.3%.

Existing blockchain-based authentication and key management solutions effectively enhance traceability and tamper resistance. However, their performance is often constrained by the inherent throughput and latency limitations of blockchain technology. Moreover, designing truly lightweight on-chain operations suitable for vehicle-embedded environments remains an open challenge.

1. 2) Certificateless and lightweight cryptographic schemes

These schemes eliminate traditional certificate management through lightweight cryptographic constructs and efficient algorithms. Ali et al.[41] proposed an innovative certificateless public key signature solution utilizing bilinear pairing techniques aimed at enhancing the privacy security of vehicle-to-infrastructure communications. However, this solution utilizes bilinear pairing for batch signature aggregation and verification, which leads to the challenge of high computational complexity. Meng et al.[42] proposed a lightweight anonymous mutual authentication and key agreement scheme, enabling efficient cross-regional node authentication and session key establishment. Tan et al.[43] introduced a VANET system model incorporating edge computing infrastructure, which provides sufficient computational and storage resources for individual vehicles. Vishwakarma et al.[44] proposed a lightweight blockchain security scheme supporting Software-Defined Networking (SDN) for secure storage and communication, enabling vehicles to generate their own key pairs and obtain temporary credentials during registration.

Despite adopting certificateless and lightweight designs, many solutions struggle to balance robust privacy protection (such as identity unlinkability) with efficient cross-domain authentication while achieving fully decentralized trust.

1. 3) Privacy-preserving and conditional anonymity schemes

This category comprises identity protection, conditional traceability, and communication privacy without sacrificing security. Bhushan et al.[45] proposed a vehicular blockchain network model introducing a consensus authentication model to smart city infrastructure, handling security and traffic control via specialized miner nodes but heavily relying on sensor data and underutilizing smart contracts and PKI technologies. Feng et al.[46] proposed an Efficient Privacy-Preserving Authentication Model (EPAM) using asynchronous accumulators to extend blockchain applications for efficient membership verification and pseudonym management, though its three-level model may add computational overhead. Xu et al.[47] proposed a blockchain and token-based scheme reducing costs through time-sensitive tokens but is vulnerable to Man-In-The-Middle (MITM) attacks. Son et al.[48] proposed a blockchain-based Vehicle-to-Infrastructure (V2I) authentication scheme comprising five phases. The initial authentication phase uses ECC for security authentication, and authentication data is stored on the blockchain. If the RSU discovers vehicle misbehavior, it can execute vehicle revocation through the blockchain. Lu et al.[49] proposed a lattice-based dual blockchain anonymous authentication scheme featuring forward security and revocability for VANETs. The dual-chain architecture decouples identity from mobility to enhance anonymity. Bonsai tree structures ensure forward security, and malicious vehicles can be anonymously revoked. This work addresses quantum computing threats while maintaining balanced security and efficiency.

Existing privacy-preserving solutions strike a good balance between conditional anonymity and traceability, but they often rely on complex cryptographic accumulators or multi-layer architectures. This can impose significant storage and computational burdens in practical deployments and lack sufficient support for rapid revocation of dynamic vehicle members.

1. 4) Hybrid and multi-technology integrated schemes

These approaches combine blockchain with other technologies such as edge computing, software-defined networking (SDN), and advanced consensus mechanisms to achieve scalable and efficient authentication. Mei et al.[50] proposed a scheme that combines blockchain, IoV, and edge computing to support efficient computation and storage functions. Xu et al.[51] proposed a scheme for IoV that utilizes blockchain and RSU-assisted technologies, aiming to address the complex authentication problems faced by vehicles in the transportation domain. Shi et al.[52] proposed a blockchain-enabled domain name service and mutual authentication protocol based on the Blockchain-enabled Authentication and Communications Network (BeACONS) framework, significantly reducing reliance on centralized infrastructure for inter-vehicle communications. Surapaneni et al.[53] developed a handover authentication scheme combining blockchain with the InterPlanetary File System (IPFS), utilizing a Proof-of-Reputation (PoR) consensus mechanism to substantially improve vehicle re-authentication efficiency. Lin et al.[54] enhanced their protocol by employing blockchain to implement distributed trusted third-party services, effectively preventing single points of failure. The BAKARI scheme proposed by Mukathe et al.[27] achieves secure key agreement through Schnorr signatures and elliptic curve cryptography while employing blockchain smart contracts for vehicle reputation management. Ma et al.[55] introduced an optimized Practical Byzantine Fault Tolerance (PBFT) consensus-based distributed authentication scheme, where smart-contract-automated authentication processes enable the reuse of authentication results.

Integrating blockchain with technologies such as edge computing and SDN represents a cutting-edge research direction. However, current research still faces significant gaps in designing collaborative security architectures across technology stacks, establishing unified trust propagation mechanisms, and ensuring scalability for massive vehicle fleets.

1. 5) Blockchain-based trust mechanisms

Recent research indicates that trust mechanisms empowered by blockchain have become the core technical direction for enhancing the security and trustworthy interaction of the Internet of Vehicles (IoV). Srivastava et al.[56] proposed an Additive Increase and Multiple Decrease (AIMD) trust model based on a permissioned blockchain, which reduces latency while improving the packet delivery rate. Wei et al.[57] proposed a game-theory-driven dynamic Proof of Work (PoW) consensus that adjusts mining difficulty based on RSU trust values; this protocol achieves Nash equilibrium and higher efficiency. Yadav et al.[58] developed a Delegated Proof of Stake (DPoS) consensus that ensures trustworthiness by employing entropy and binomial distribution for miner selection, enabling information traceability and anonymous information sharing. Wang et al.[59] proposed a drone-assisted trust management scheme that combines certificateless authentication and Quality of Service (QoS) evaluation; this scheme resists both internal and external attacks.

Trust mechanisms based on game theory or novel consensus protocols enhance system security. However, these mechanisms typically require complex global information exchange or assume relatively stable network environments. Their effectiveness and efficiency in highly dynamic, partially connected IoV scenarios still require further validation and optimization.

The comparison of related research methods is shown in Table 1.

Download:

• PNG
  larger image
• TIFF
  original image

Table 1. Comparison of Related Authentication Schemes.

https://doi.org/10.1371/journal.pone.0347787.t001

Analysis of Table I reveals that existing solutions primarily exhibit three limitations. First, there is an imbalance between security and efficiency, often resulting in high computational overhead for enhanced security or compromised privacy protection for higher efficiency. Second, centralization dependency and scalability issues persist, with trust models or key management presenting single points of failure. Third, deployment complexity and weak dynamic adaptability remain problematic, as many solutions rely on specific hardware or complex cryptography while offering limited support for cross-domain and highly mobile scenarios. Correspondingly, this proposal introduces three core design solutions. First, it employs lightweight cryptographic modules and batch-verifiable anonymous authentication protocols. By integrating security mechanisms such as ECC point multiplication while optimizing efficiency, it achieves a balance between security and performance. Second, it constructs a multi-TA decentralized trust architecture based on blockchain. Through smart contracts, it enables automated trust propagation and key management, eliminating central bottlenecks and enhancing scalability. Finally, it simplifies RSUs to pure relay nodes and designs a cross-domain direct authentication mechanism. This reduces deployment dependencies and leverages the blockchain’s global state to enable rapid, secure mutual recognition among vehicles in dynamic environments. Through this systematic design, the proposed solution comprehensively addresses existing challenges, delivering a more practical and scalable authentication framework for the IoV.

4.1 System model

This section presents the proposed system model, which comprises five key components: On-Board Unit (OBU), Roadside Unit (RSU), Trusted Authority (TA), blockchain, and Data Center (DC). Fig 1 illustrates the system model of the proposed scheme.

Download:

• PNG
  larger image
• TIFF
  original image

Fig 1. System models.

This figure shows that the system model comprises five key components: OBU, RSU, TA, blockchain, and DC.

https://doi.org/10.1371/journal.pone.0347787.g001

OBU: Each vehicle is equipped with an OBU that provides computational and storage capabilities, along with support for cryptographic operations. The primary functions of the OBU include registering with third-party TAs and sending and receiving real-time traffic information via wireless communication with nearby RSUs.

RSU: Installed in road infrastructure, RSUs have limited communication ranges and moderate computational resources. They serve as the first contact point between vehicles and TAs, acting as information bridges. RSUs must register with TAs and facilitate message exchange with vehicles and TAs within their coverage area. Notably, RSUs do not authenticate vehicles or participate in blockchain transactions. It is important to emphasize that complete end-to-end identity authentication and key agreement must always be performed directly between the OBU and the TA. The essential communication exchanges between the OBU and the TA cannot be omitted. Consequently, offloading the authentication function from RSUs does not introduce additional network round-trip delays.

TA: The TA functions as a fully trusted third-party entity with substantial computing and robust storage resources. Both vehicles and RSUs must register with the TA. During vehicle registration, the TA generates and stores shared key parameters on the blockchain for subsequent authentication. When authenticating a vehicle, the TA retrieves the relevant parameters stored on the blockchain. It is worth noting that there are usually multiple TAs in a city or region, and the high-speed, long-distance mobility of vehicles necessitates cross-TA authentication.

Blockchain: Within the proposed network model, the collection of TAs constitutes a private blockchain-based multiserver network, with TAs actively assuming the role of miners. However, it is essential to note that any TA joining the network must be authorized by the system administrator through a meticulous process. Each block of the blockchain contains a pointer to the previous block, through which the corresponding block data can be queried. TAs upload information about registered vehicles to the blockchain, acting as nodes responsible for maintaining the ledger and uploading signed transactions. Regarding the consensus mechanism, to meet the high-speed, low-latency requirements of the IoV, a fast random node selection mechanism based on verifiable random functions (VRF) is adopted (drawing inspiration from Algorand) to participate in block generation. This mechanism efficiently and fairly selects consensus nodes in each round, avoiding the high energy consumption and long delays associated with PoW while eliminating the multi-round communication overhead of Practical Byzantine Fault Tolerance (PBFT). Consequently, it ensures security while enabling rapid and stable block generation.

DC: The DC stores all IoV-related information, including vehicle registration data and encrypted communication records. Importantly, all TAs share a common DC and communicate with it through wired channels. Given that DCs and TAs possess abundant resources, the secure channels established between them ensure message integrity and confidentiality.

In summary, the proposed system model incorporates multiple entities—OBU, RSU, TA, blockchain, and DC—to enable secure communication and authentication in intelligent vehicular networks. The synergy among these entities ensures vehicle security and data integrity.

4.2 Threat model

When constructing a secure communication system for the IoV, it is essential to clearly define the capabilities, targets, and methods of potential attackers. This threat model aims to comprehensively analyze the potential security threats, laying a foundation for the subsequent security objectives and measures proposed.

1. 1) Capabilities of potential attackers

Computational Capability: Attackers may possess substantial computational resources, enabling them to perform complex cryptographic analyses, such as breaking keys or forging signatures.

Information Gathering Capability: Attackers may obtain sensitive information by eavesdropping on network communications or infiltrating system nodes, including vehicle identity information and communication keys.

Temporal Flexibility: Attackers can initiate attacks at any time without temporal constraints.

Network Control Capability (Extended from the Dolev-Yao Model): Attackers are assumed to possess complete control over the communication channel, enabling them to intercept, eavesdrop, inject, tamper with, or replay any message transmitted within the network. However, they cannot directly decrypt cryptographically sound encrypted messages without the corresponding keys.

1. 2) Attack targets

Vehicle Identity Information: Attackers may attempt to obtain or tamper with vehicle identity information to conduct impersonation attacks.

Communication Keys: Attackers may attempt to compromise or steal communication keys to eavesdrop on or tamper with communication content.

System Integrity: Attackers may attempt to disrupt the normal operation of the system, for instance, through denial-of-service (DoS) attacks aimed at paralyzing the network.

1. 3) Attack methods

Vehicle Impersonation Attack: Attackers may forge vehicle identities, masquerading as legitimate vehicles to communicate, thereby gaining illegal benefits or compromising system security.

Man-in-the-Middle Attack: Attackers may intercept communications between vehicles and RSUs or TAs, and tamper with or forge communication content to commit fraud or disrupt system operations.

Replay Attack: Attackers may intercept and store legitimate messages, then retransmit them at a later time to deceive the system or vehicles.

Key-Breaking Attack: Attackers may utilize powerful computational resources to attempt to break communication keys to obtain sensitive information or conduct unauthorized communications.

1. 4) Threat model integration and foundational principles

This model systematically integrates core concepts from classical threat modeling frameworks when describing attacker capabilities and methods, ensuring a comprehensive and rigorous analysis:

Dolev-Yao Model: We adopt the Dolev-Yao model’s core assumption regarding attacker network capabilities—namely, attackers fully control communication channels and can perform eavesdropping, interception, injection, and replay operations. This forms the foundation for analyzing network-layer attacks, such as man-in-the-middle and replay attacks, within this model.

STRIDE Model: The attack types addressed by this model span multiple critical dimensions of the STRIDE threat classification:

Spoofing: Corresponds to vehicle impersonation attacks, where adversaries forge identities to masquerade as legitimate entities.

Tampering: In scenarios such as man-in-the-middle attacks, adversaries may illegally modify transmitted data content.

Repudiation: Leveraging blockchain immutability and smart contract execution logs, this proposed solution aims to provide verifiable audit trails for all critical operations to counter such threats.

Information Disclosure: Key cracking attacks and eavesdropping directly threaten information confidentiality.

Denial of Service: Attackers may incapacitate RSUs or TAs through resource exhaustion or similar methods, threatening system availability.

Elevation of Privilege: This solution employs multi-level authentication and strict separation of duties to prevent adversaries from exploiting vulnerabilities to gain unauthorized access beyond their permitted scope.

4.3 Security objectives and measures

The proposed scheme addresses the following security requirements through corresponding measures:

1. 1) Registration security: During the registration process, the vehicle must transmit sensitive identity information, which is accomplished over a secure channel to ensure the security of the registration.
2. 2) Confidentiality of TA key: The TA’s master key is neither transmitted over the network nor stored in RSUs at any time to ensure confidentiality.
3. 3) Security of the blockchain pointer: This solution employs a blockchain pointer P as the key index credential for accessing specific on-chain data, such as vehicle identities or transaction records. Unlike the content-addressable approach based on hashes or block heights in conventional blockchains, P undergoes cryptographic processing to provide more direct access control tailored for specific application scenarios. To enhance the pointer’s security, the solution incorporates not only conventional XOR and hash operations but also elliptic curve point multiplication during its computation, thereby strengthening its resistance to cryptographic attacks.
4. 4) Identity anonymity: Identity IDs cannot be directly involved in communication or cryptographic operations to preserve identity anonymity.
5. 5) Communication security between RSU and TA: RSUs do not perform computations—they only act as data relays—thereby mitigating critical data transmission risks between RSUs and TAs.
6. 6) Bidirectional authentication and key agreement: The scheme achieves mutual authentication between the OBU and TA while simultaneously negotiating session keys. Vehicle-to-vehicle communication is enabled via key agreement protocols.
7. 7) Session key strength: To ensure that session keys are not easily cracked, their complexity must be increased.
8. 8) Message integrity: Message integrity is ensured by verifying that the computed hash matches the received hash, confirming the sender’s legitimacy. Hash operations are employed to achieve this property.
9. 9) Forward security: Forward security is ensured by deriving each session key independently using fresh random parameters, such that compromising a current session key does not reveal any previously established session keys.
10. 10) Resistance to common attacks: The solution is designed to resist common attacks, including vehicle impersonation, MITM attacks, and replay attacks.

These security measures collectively ensure that the system remains robust against a diverse range of threats.

5.1 Initialization phase

The initialization phase is as follows:

1. Step I1: TA generates K and r_TA.
2. Step I2: TA initializes List = 0. For every OBU request: List←List+1.

5.2 Registration phase

The registration phase includes OBU registration and RSU registration.

1. 1) Vehicle registration phase

The process of registering an OBU within any TA involves several steps, which are outlined as follows. During this process, the OBU and TA communicate via a secure channel.

Step R1:OBU registers with TA through a secure channel. The owner inputs ID_i, PW_i and BIO_i via the OBU, generates a random number r_i and calculates R_i = r_i·G. Using biometric fuzzy extraction, it generates α_i, β_i by biometric fuzzy extraction, calculates HID_i = h(ID_i‖α_i), HPW_i = h(PW_i‖α_i), O₁ = h(ID_i‖PW_i‖α_i)⊕r_i, and O₂ = h(ID_i‖PW_i‖α_i‖r_i). After completing the above steps, {HID_i,HPW_i,R_i} are sent to TA via a secure channel.

Step R2: TA receives the message and calculates R_TA = r_TA·G, R_TA-i = r_TA·R_i, K_TA = h(K‖r_TA), OK_TA = K_TA⊕h(HID_i‖HPW_i), and THID_i = h(HID_i‖K_TA). TA sends {OK_TA,THID_i,R_TA} to the OBU via the secure channel.

Step R3: OBU receives the message, calculates K_TA = OK_TA⊕h(HID_i‖HPW_i), and S₁ = r_i⊕K_TA, then sends S₁ to TA via the secure channel.

Step R4:TA receives the message, generates blockchain pointer P, calculates r_i = S₁⊕K_TA, OP = P⊕h(K_TA‖R_TA-i), OT = r_i⊕h(THID_i‖K_TA), and uploads {HID_i,OT,S₁} to the blockchain block corresponding to the pointer P. TA sends {OP} to the OBU via the secure channel.

Step R5:OBU receives the message and saves {OK_TA,THID_i,O₁,O₂,OP,r_i}. The OBU registration is completed.

Fig 2 illustrates the OBU registration phase.

Download:

• PNG
  larger image
• TIFF
  original image

Fig 2. Registration phase between OBU and TA.

This figure shows the interaction process when the OBU completes registration with the TA.

https://doi.org/10.1371/journal.pone.0347787.g002

1. 2) RSU registration phase

Here are the steps for an RSU to register with TA. During this process, the RSU and TA communicate via a secure channel.

Step R1: RSU generates identity information RID_j and a random number r_j, then calculates HRID_j = h(RID_j‖r_j) for subsequent authentication. RSU sends {HRID_j} to TA via the secure channel.

Step R2: TA receives the message, calculates TRID_j = h(HRID_i‖K_TA), and saves TRID_j.

Fig 3 illustrates the RSU registration phase.

Download:

• PNG
  larger image
• TIFF
  original image

Fig 3. Registration phase between RSU and TA.

This figure shows the interaction process when the RSU completes registration with the TA.

https://doi.org/10.1371/journal.pone.0347787.g003

5.3 Authentication and key agreement phase

The authentication phase is divided into two sub-phases: OBU and TA authentication and OBU and OBU authentication. During the subsequent authentication process, all three parties communicate via a public channel.

1. 1) OBU and TA authentication

The authentication and key agreement phase for OBU and TA is as follows.

Step A1: The owner inputs ID_i, PW_i, BIO_i via OBU, calculates α_i^* = Rep(BIO_i,β_i), r_i^* = O₁⊕h(ID_i‖PW_i‖α_i^*), O₂^* = h(ID_i‖PW_i‖α_i^*‖r_i^*), and checks if O₂^* equals O₂, If yes, proceed; otherwise, stop. Next, OBU calculates HID_i = h(ID_i‖α_i), HPW_i = h(PW_i‖α_i), K_TA = OK_TA⊕h(HID_i‖HPW_i), OT = r_i⊕h(THID_i‖K_TA), generates T₁, and calculates M₁ = h(THID_i‖OT‖r_i‖K_TA‖T₁). It sends {M₁, OP, R_i, T₁} to RSU.

Step A2: RSU receives the message, appends its identity HRID_j, and sends {M₁, OP,R_i,T₁,HRID_j} to TA.

Step A3: TA receives the message and verifies time parameter T₁. It then verifies the RSU identity by calculating if TRID_j^*= h(HRID_i^*‖K_TA) equals TRID_j. If RSU identity is valid, TA calculates R_TA-i = r_TA·R_i, P = OP⊕h(K_TA‖R_TA-i), and checks if blockchain pointer P exists. If so, it reads the blockchain data corresponding to {HID_i,OT,S₁}. Using the read data, it calculates r_i^* = S₁^*⊕K_TA, THID_i = h(HID_i^*‖K_TA), OT^* = r_i^*⊕h(THID_i^*‖K_TA), M₁^* = h(THID_i^*‖OT^*‖r_i^*‖K_TA‖T₁), checks if M₁^* equals M₁, and if so, performs List = List+1 to prevent replay attack. TA generates r_s, r_T and T₂, calculates r_i^’ = h(r_i‖r_s), OT^’ = r_i^’⊕h(THID_i‖K_TA), R_TA-i’ = r_TA·r_i^’·G, and derives the session key SK_T = h(THID_i‖r_i‖r_T‖K_TA‖R_TA-i’). It generates a new blockchain pointer P^’, calculates OP^’ = P^’⊕h(K_TA‖R_TA-i’), and puts {HID_i,OT^’,SK} to the new block. Next, it calculates M₂ = r_s⊕h(HID_i‖K_TA‖TRID_j), M₃ = r_T⊕h(THID_i‖K_TA‖r_s), M₄ = h(THID_i‖TRID_j‖r_i^’‖r_T‖T₂), M₅ = h(THID_i‖K_TA‖TRID_j‖SK). Finally, {M₂,M₃,M₄, M₅, R_TA, T₂} are sent to RSU.

Step A4: RSU receives the message from TA, appends its identity, and sends {M₂,M₃,M₄, M₅, R_TA,HRID_j,T₂} to TA.

Step A5: OBU receives the message and verifies time parameter T₂. Then it calculates TRID_j^* = h(HRID_i^*‖K_TA), r_s^* = M₂⊕h(HID_i‖K_TA‖TRID_j^*), r_T^* = M₃⊕h(THID_i‖K_TA‖r_s^*), r_i^’* = h(r_i‖r_s^*), M₄^* = h(THID_i‖TRID_j‖r_i^’*‖r_T^*‖T₂), and verifies if M₄^* equals M₄. If verified, it calculates R_i-TA^* = r_i^’*·R_TA, derives session key SK_O^* = h(THID_i‖r_i‖r_T^*‖K_TA‖R_i-TA^*), calculates M₅^* = h(THID_i‖K_TA‖TRID_j^*‖SK^*), and verifies if M₅^* equals M_5. If this also passes, it calculates O₁^’ = h(ID_i‖PW_i‖α_i)⊕r_i^’, O₂^’ = h(ID_i‖PW_i‖α_i‖r_i^’), and updates OBU’s storage data to {OK_TA,THID_i,O₁^’,O₂^’,OP^’,r_i^’}.

Fig 4 illustrates the authentication and key agreement phase for OBU and TA.

Download:

• PNG
  larger image
• TIFF
  original image

Fig 4. Authentication phase between OBU and TA.

This figure shows the process of the OBU completing authentication and key agreement with the TA.

https://doi.org/10.1371/journal.pone.0347787.g004

1. 2) OBU and OBU authentication

The authentication and key agreement phase for OBU and OBU is as follows.

Step A1: OBU_A and OBU_B broadcast their respective identity information {HID_A,OP_A,R_A} and {HID_B,OP_B,R_B}. The communicating parties receive each other’s information and send authentication requests to RSU in the region, respectively.

Step A2: RSU forwards authentication requests {OP_A,R_A,OP_B,R_B} from OBU_A and OBU_B to TA.

Step A3: TA receives the message and calculates R_TA-A = r_TA·R_A, R_TA-B = r_TA·R_B, P_A = OP_A⊕h(K_TA‖R_TA-A), P_B = OP_B⊕h(K_TA‖R_TA-B). It then checks whether blockchain pointer P_A, and P_B exist in the blockchain. If they do, it reads blockchain data {HID_A,OT_A,SK_A} associated with P_A and {HID_B,OT_B,SK_B} associated with P_B, calculates SK_AB = h(SK_A‖SK_B), derives the session keys PK_BA = SK_AB⊕h(K_TA‖SK_B) and PK_AB = SK_AB⊕h(K_TA‖SK_A) between OBU_A and OBU_B, and sends {HID_A, PK_BA} and {HID_B, PK_AB} to RSU.

Step A4: RSU sends {HID_A, PK_BA} to OBU_B and {HID_B, PK_AB} to OBU_A.

Step A5: OBU_B calculates session key SK_AB = PK_BA⊕h(K_TA‖SK_B), OBU_A calculates session key SK_AB = PK_AB⊕h(K_TA‖SK_A). OBU_A and OBU_B then communicate using the session key.

Fig 5 illustrates the authentication and key agreement phase for OBU and OBU.

Download:

• PNG
  larger image
• TIFF
  original image

Fig 5. Authentication phase between OBU and OBU.

This figure shows the process of authentication and key agreement between two OBUs.

https://doi.org/10.1371/journal.pone.0347787.g005

5.4 Scalability analysis and optimization strategy

This scheme focuses on two core bottlenecks in large-scale deployment scenarios, especially in heterogeneous vehicle networks. First, differentiated authentication requirements across multiple vehicle types may lead to an imbalance in TA computational load. With the increasing diversity of vehicles—such as fuel-powered vehicles, new energy vehicles, and autonomous vehicles—authentication dimensions vary significantly. During peak hours, TA computing resources may become overloaded, potentially degrading authentication efficiency. Second, variations in RSU hardware specifications across different regions can cause coordination failures. In heterogeneous networks, discrepancies in RSU processing capabilities may result in mismatched message forwarding rates, with low-capability RSUs becoming data transmission bottlenecks that compromise real-time authentication performance.

To address these challenges, two key optimization strategies are proposed. To tackle the first bottleneck, a dynamic computing power scheduling mechanism is constructed, which sets authentication priorities based on vehicle types and authentication requirements, and diverts non-core authentication tasks to edge nodes. Additionally, a flexible resource pool is configured for the TA, enabling automatic scaling during peak periods to accommodate surges in computational demand. Regarding the second bottleneck, a hierarchical collaborative system for RSUs is established, dividing them into high-computing-power core nodes and ordinary relay nodes based on hardware capabilities. Core nodes are responsible for aggregating and forwarding cross-domain authentication data, whereas ordinary nodes serve only as low-load local relays. By synchronizing RSU load status through blockchain, the system dynamically adjusts data transmission paths to avoid single-point overload and ensure the scalability of the system under large-scale deployment.

6.1 Formal security analysis

Next, the scheme’s security was verified using BAN logic, whose notations, descriptions, and inference rules are defined as shown in Tables 3 and 4.

Download:

• PNG
  larger image
• TIFF
  original image

Table 3. BAN Logic Notations and Descriptions.

https://doi.org/10.1371/journal.pone.0347787.t003

Download:

• PNG
  larger image
• TIFF
  original image

Table 4. Inference Rules of BAN Logic.

https://doi.org/10.1371/journal.pone.0347787.t004

1. 1) Goals:

1. 2) Idealized forms:

1. 3) Assumptions:

1. 4) Main proofs

Step 1: From I1 and I2, we can deduce that TA has received message M₁.

Step 2: Applying the message-meaning rule (R1) to S1 and assumption A1 yields:

This confirms that TA believes M₁ originated from OBU_i.

Step 3: By applying the freshness rule (R4) to assumption A3, we obtain:

Thus, TA believes that M₁ is fresh.

Step 4: Applying the nonce-verification rule (R2) to S2 and S3 gives:

This indicates that TA believes OBU_i also believes M₁.

Step 5: From S4 and assumption A5, the jurisdiction rule (R3) allows us to infer:

Thus, TA believes that M₁ is true.

Step 6: Applying the conjunction rule (R5) to S5 and assumption A5 yields:

where r_i is a component of M₁. This confirms that TA believes that OBU_i also believes r_i.

Step 7: With S6, assumption A3, and the session key , applying rule R6 gives:

This achieves goal G1, i.e., TA believes that SK is a secure shared key between itself and OBU_i.

Step 8: From S7, assumption A3, and assumption A7, applying rules R2 and R4 yields:

This achieves goal G2, i.e., TA believes that OBU_i also believes SK is a secure shared key between them.

Step 9: From I3 and I4, we can deduce that OBU_i has received message M₄.

Step 10: Applying the message-meaning rule (R1) to S9 and assumption A2 yields:

This confirms that OBU_i believes M₄ originated from TA.

Step 11: By applying the freshness rule (R4) to assumption A4, we obtain:

Thus, OBU_i believes that M₄ is fresh.

Step 12: Applying the nonce-verification rule (R2) to S10 and S11 gives:

This indicates that OBU_i believes that TA also believes M₄.

Step 13: From S12 and assumption A6, the jurisdiction rule (R3) allows us to infer:

Thus, OBU_i believes that M₄ is true.

Step 14: Applying the conjunction rule (R5) to S13 and assumption A6 yields:

where r_T is a component of M₄. This confirms that OBU_i believes that TA also believes r_T.

Step 15: With S14, assumption A4, and the session key , applying rule R6 gives:

This achieves goal G3, i.e., OBU_i believes that SK is a secure shared key between itself and TA.

Step 16: From S15, assumption A4, and assumption A8, applying rules R2 and R4 yields:

This achieves goal G4, i.e., OBU_i believes that TA also believes SK is a secure shared key between them.

6.2 Informal security analysis

Informal security analysis evaluates the scheme’s security properties and its resistance to diverse attacks. Each security property and attack type is briefly defined, followed by a demonstration of how the proposed scheme effectively resists the identified threats.

1. 1) Vehicle anonymity

All vehicle identity information is secured via one-way hashing: the scheme concatenates vehicle ID with a random number, then hashes the result to generate HID_i = h(ID_i‖α_i), ensuring that adversaries cannot derive real identities from the hash value.

1. 2) Vehicle impersonation attack

Even if an adversary captures vehicle information and obtains ID/PW, they must input the owner’s biometric BIO to verify α_i and compute r_i^* = O₁⊕h(ID_i‖PW_i‖α_i^*) and O₂^* = h(ID_i‖PW_i‖α_i^*‖r_i^*) for login. The adversary does not possess the biometrics of the vehicle owner, so he cannot log in the system. Furthermore, each login requires a fresh random number r_i, that cannot be obtained by the adversary. Therefore, even if the adversary captures the vehicle’s information, he/she cannot execute an impersonation attack.

1. 3) Message integrity

The TA verifies M₁ = h(THID_i‖OT‖r_i‖K_TA‖T₁) upon receiving OBU messages, so if the data are tampered with or deleted, the M₁ verification will fail, and the scheme will terminate the verification and subsequent processes. Similarly, the OBU verifies the one-way hash functions M₄ = h(THID_i‖TRID_j‖r_i^’‖r_T‖T₂) and M₅ = h(THID_i‖K_TA‖TRID_j‖SK) after receiving the message from the TA, if the data are tampered with or deleted, the verification will fail, thereby ensuring information integrity.

1. 4) Forward safety

Suppose an adversary compromises the vehicle’s current session key SK_O = h(THID_i‖r_i‖r_T‖K_TA‖R_i-TA) through a key attack. Since the key is derived from a hash of parameters (THID_i, r_i, r_T, K_TA and R_i-TA), the adversary cannot retrieve these parameters from the hash value alone. Suppose the adversary captures all past data transmitted over the channel to obtain parameters (e.g., R_i, R_TA), parameters such as THID_i, r_i, r_T, K_TA are never transmitted over the channel, and the random number r_i is updated every round. In addition, the attacker cannot calculate r_i and r_TA using R_i = r_i·G and R_TA = r_TA·G because this calculation involves the Elliptic Curve Discrete Logarithm Problem (ECDLP) mathematical difficulties. Therefore, an adversary cannot calculate the previous key from the current key.

1. 5) Replay attack

This scheme contains timestamps T₁ and T₂. During the scheme, when the OBU, RSU, and TA receive a message, they must verify the timestamp. Because the timestamp is generated based on the current time, it is unmodifiable, and the adversary cannot forge it. If the adversary carries out a replay attack, the OBU, RSU, and TA can quickly identify the adversary by recognizing the validity of the timestamp, thereby resisting the replay attack.

1. 6) MITM attack

According to the challenge/response mechanism, both OBU-RSU and RSU-TA communications require mutual identity verification. As established in the analysis of vehicle impersonation attacks, an adversary cannot successfully masquerade as a legitimate entity. Moreover, as demonstrated in the message integrity analysis, an adversary cannot tamper with transmitted messages without detection. Suppose the adversary intercepts the messages {M₁, OP,R_i,T₁} and {M₂,M₃,M₄, M₅, R_TA, T₂} over public channels. The messages M₁, M₂, M₃, and M₄ are hash functions, and R_i and R_TA are results of elliptic curve scalar multiplications. According to the unidirectional property of hash functions and the mathematical hardness of the ECDLP, the adversary cannot obtain any useful parameters from them. Thus, the adversary cannot disguise themselves as intermediaries during MITM attack. Furthermore, timestamps and random numbers are inherently time-sensitive and cannot be forged via MITM attack, making it impossible for an attacker to pose as an intermediary and initiate an assault.

1. 7) Sybil attack

The proposed scheme mainly includes two measures to resist Sybil attack: binding the vehicle identity with a unique biometric credential, and leveraging the immutability of blockchain. During the registration phase, each OBU needs to complete registration with the TA through exclusive biometric information, which is processed through hashing and stored on the blockchain. During the authentication process, the TA will verify the hash value corresponding to the biometric features against the blockchain records. Due to the tamper-proof nature of blockchain, attackers cannot forge valid biometric credentials. Furthermore, real-time synchronization is achieved through blockchain during multi-TA verification. Even if attackers register false identities in a single TA domain, cross-TA verification can quickly detect anomalies and effectively resist Sybil attacks.

1. 8) DoS attack

This solution employs RSU function optimization and lightweight cryptographic computations to resist DoS attacks. On one hand, RSUs are restricted to functioning solely as message relays, which effectively prevents attackers from exhausting RSU resources through forged authentication requests. On the other hand, the ECC key of this protocol adopts a 160-bit short key length, which not only ensures security but also reduces computation time. Even under high request volumes, the TA can efficiently process legitimate requests and effectively resist DoS attacks targeting system overload.

1. 9) Rogue RSU attack

The dual-layer verification mechanism of this scheme can effectively resist Rogue RSU attack. Legitimate RSUs need to be registered with the TA in advance, and the TA will issue the OK_TA parameter containing the RSU’s identity and public key. Before receiving a message, the OBU and TA will first verify the validity of the operation result corresponding to OK_TA. Any rogue RSU that fails this verification is immediately rejected. In addition, the TA will send the blockchain pointer parameter OP to legitimate users during registration. Communication between the OBU and TA also requires verification of OP, and rogue RSUs will be directly rejected. Finally, the TA distributes the RSU certificate revocation list to the network through blockchain to ensure that rejected RSUs can be promptly excluded, effectively resisting Rogue RSU attacks.

1. 10) Bidirectional authentication and key agreement

The scheme achieves bidirectional authentication between OBU and TA via M₁ = h(THID_i‖OT‖r_i‖K_TA‖T₁), M₄ = h(THID_i‖TRID_j‖r_i^’‖r_T‖T₂), M₅ = h(THID_i‖K_TA‖TRID_j‖SK) and simultaneously derives the session key SK_T = h(THID_i‖r_i‖r_T‖K_TA‖R_TA-i’)= h(THID_i‖r_i‖r_T‖K_TA‖R_i-TA)= SK_O.

1. 11) Backward secrecy

The session key SK = h(THID_i‖r_i‖r_T‖K_TA‖R_i-TA) in this scheme is jointly generated by the K_TA and the round-specific temporary random numbers r_i and r_T. These random numbers are immediately discarded after each session and are never transmitted in plaintext, preventing attackers from obtaining historical r_i/r_T values. Consequently, the TA’s master key K_TA alone cannot be used to derive any past SK. This ensures strict backward secrecy, protecting all past communication sessions.

1. 12) Session key security

In this scheme, each session key SK = h(THID_i‖r_i‖r_T‖K_TA‖R_i-TA)is generated using a unique and independent temporary random number ri and rT for each round. The strong one-way property of the hash function ensures that the random numbers used to generate the key cannot be derived from the old SK. More importantly, the random numbers used in different authentication rounds are mathematically and temporally independent. Thus, leakage of random numbers from one session provides no advantage to an adversary in guessing or deriving random numbers for any other session. Therefore, the scheme guarantees session key security.

1. 13) Insider and malicious TA attacks

This solution employs blockchain multi-TA coordination and cryptographic mechanisms to counter insider threats. When a single TA node attempts unauthorized authentication due to key theft or malicious intent, it must provide the OBU’s random number ri for verification by peer TAs. The blockchain’s smart contracts ensure transparent and verifiable trust states. Any abnormal TA behavior is recorded on-chain and excluded through consensus, thereby suppressing internal attacks.

1. 14) Smart-card-lost/device capture attack

The critical login parameter αi in this solution is protected by the vehicle owner’s biometric data (BIO_i). The value O₁ stored within the device is either a hash or ciphertext. Without BIO_i, α_i cannot be recovered nor can valid random numbers r_i be generated. Furthermore, the r_i required for session key generation is dynamically produced each time and is not stored on the device, ensuring physical tampering is ineffective. Therefore, even if the device is lost, an attacker cannot authenticate using the lost device.

Table 5 presents the security characteristics of the proposed scheme alongside a comparative security analysis against various attacks using related schemes from the past two years. In the table, √ denotes protection, and × denotes no protection.

Download:

• PNG
  larger image
• TIFF
  original image

Table 5. Comparative Analysis of Security Features and Attack Resilience.

https://doi.org/10.1371/journal.pone.0347787.t005

6.3 Simulation-based verification using proverif

This section employs the formal verification tool ProVerif to conduct a rigorous security analysis of the proposed authentication and key agreement protocol, thereby validating the security of the scheme. ProVerif, based on the Applied Pi calculus, is an automated verification tool designed to assess confidentiality, authenticity, and integrity in cryptographic protocols. It can analyze a protocol’s resistance to both passive and active attacks.

1. 1) Methodology description

First, model the protocol participants (OBU, RSU, and TA) and their interaction process, including: 1) Defining multiple private channels (sch1, sch2) and public channels (ch1, ch2) for transmitting confidential and public information, respectively; 2) Defining cryptographic operations, including hash functions (h), exclusive-OR operations (xor), point multiplication (mult), symmetric encryption (syme), and biometric-related functions (Gen, Rep); 3) Defining multiple private-type key parameters, such as vehicle identity IDi, temporary key ri, and TA master key K, to prevent theft by attackers.

Second, characterize the authentication process by inserting event markers at critical protocol steps: event beginTA(id) and event endTA(id) mark the start and end of TA authentication; event beginOBUi(id) and event endOBUi(id) mark the start and end of vehicle OBUi authentication.

Finally, verify the protocol’s security properties through the following queries: 1) Using query attacker(SKO) and query attacker(SKT) to conduct confidentiality queries, verifying whether the session keys SKO and SKT have been compromised by attackers; 2) Employing inj-event formal queries to assess bidirectional authentication properties, and conducting authentication queries to verify whether communication between TA and OBUi is susceptible to identity spoofing or replay attacks.

1. 2) Analysis process

The entire system analysis process is divided into three parallel processes:!processOBUi |!processRSU |!processTA, representing the behaviors of the vehicle OBU, RSU, and TA respectively. These include: 1) OBUi uses biometric information Bio to generate auxiliary data (alpha_i, beta_i), calculates the hidden identity HIDi and hidden password HPWi, and sends registration-related data to TA; 2) The TA uses the master key K and random number rTA to generate key material, returning data such as OKTA, temporary identity THIDi, and public key parameters RTAA to OBUi to complete OBUi registration; 3) OBUi and TA complete mutual authentication through multiple interactions, ultimately negotiating session keys SKO and SKT. RSU acts as a relay node, forwarding authentication messages between OBUi and TA without participating in key derivation or security parameter processing.

During verification, ProVerif automatically simulates the Dolev-Yao attacker model. Under this model, the attacker fully controls the public channel, capable of eavesdropping, intercepting, tampering with, and injecting messages, while possessing cryptographic computation capabilities. ProVerif detects whether the attacker can violate the defined security properties by exploring attack paths in the state space and deriving rules.

1. 3) Analysis results

The automated verification results from ProVerif are shown in Fig 6. Based on the verification results, the protocol’s security is analyzed as follows.

Download:

• PNG
  larger image
• TIFF
  original image

Fig 6. Outputs of the proVerif verification.

This figure shows the automated verification results generated by ProVerif.

https://doi.org/10.1371/journal.pone.0347787.g006

Session key confidentiality is strictly guaranteed. Verification results (1) and (2) show that both “not attacker(SKO[])” and “not attacker(SKT[])” yield true. This indicates that even under the Dolev-Yao threat model, where the attacker fully controls the public channel and employs eavesdropping, replay, or tampering attacks—the attacker cannot obtain the session keys SKO and SKT negotiated between the vehicle and the TA. These results validate the security of the protocol’s key exchange process, thereby ensuring the confidentiality of subsequent communications.

Furthermore, the bidirectional authentication mechanism is effectively implemented. Verification results (3) and (4) demonstrate that “inj-event(endTA(id)) ==> inj-event(beginTA(id))” and “inj-event(endOBUi(id)) ==> inj-event(beginOBUi(id))” both yield true. This confirms the protocol’s capability to achieve secure mutual authentication. Specifically, only after the TA has indeed initiated an authentication session with a specific vehicle OBUi (beginTA(id)) can that session successfully conclude (endTA(id)); similarly, only after the vehicle OBUi has correctly initiated the authentication process (beginOBUi(id)) can it successfully complete authentication with the TA (endOBUi(id)). This causal relationship between injection events (inj-event) proves the protocol’s resistance to MITM attack and identity spoofing attack, ensuring the authenticity of both communicating parties.

7.1 Computational cost

The computational cost is defined as the total simulation time required to fully execute the proposed scheme, including operations such as authentication, verification, and key agreement. This study focuses on elliptic curve operations, modular exponentiation, symmetric cryptography, and hashing. XOR and concatenation costs are negligible compared to others. In this section, the execution time data for various cryptographic primitives are examined, employing the well-regarded Multi-precision Integer and Rational Arithmetic Cryptographic Library (MIRACL) as the benchmark, in accordance with established literature [62]. The considered hardware configuration has the setting: “Raspberry PI 3 B+ Rev 1.3, Ubuntu 20.04 LTS, 64-bit OS, 1.4 GHz Quad-core processor, cores 4, 1 GB RAM”. The measured computation times for the relevant cryptographic operations are presented in Table 6.

Download:

• PNG
  larger image
• TIFF
  original image

Table 6. Computation Time Measurements for Cryptographic Operations.

https://doi.org/10.1371/journal.pone.0347787.t006

Assuming that the computational costs of OBU_i, RSU, and TA are ECA_OBUi, ECA_RSU, and ECA_TA, respectively, the specific computational expressions are as follows:

(1)

(2)

(3)

The total computation costs ECA_total of the scheme are as follows:

(4)

To substantiate the efficacy of the proposed scheme and validate its performance, its computational costs were compared with those of related schemes from the past two years. Fig 7 illustrates this comparison. The proposed scheme achieves the lowest computational cost among all compared solutions. It employs an ECDH-based key agreement mechanism, where the majority of the computational overhead is attributed to point multiplication operations. Although point multiplication is relatively time-intensive, it offers higher key density and enables the use of shorter key lengths while maintaining an equivalent security level. Consequently, despite incorporating this operation, the overall computational cost of the proposed scheme does not increase significantly, thereby effectively enhancing the operational efficiency of the IoV system.

Download:

• PNG
  larger image
• TIFF
  original image

Fig 7. Comparison of computation costs of various schemes.

The figure illustrates the comparison of the computation costs of various schemes.

https://doi.org/10.1371/journal.pone.0347787.g007

7.2 Communication cost

Communication cost refers to the bits required to transmit variables and parameters. This study evaluates costs based on data lengths, including hash values, timestamps, and elliptic curve points (public keys). For consistency with other compared schemes, the proposed scheme adopts the data length settings defined in reference [30]. The specific values are detailed in Table 7.

Download:

• PNG
  larger image
• TIFF
  original image

Table 7. Communication Data Length Analysis for the Proposed Scheme.

https://doi.org/10.1371/journal.pone.0347787.t007

Assuming that the length of the data sent by OBU_i, RSU, and TA is ECO_OBUi, ECO_RSU, and ECO_TA, respectively, the specific calculation expression is as follows:

(5)

(6)

(7)

The total transmit data length ECO_total is as follows:

(8)

To assess the effectiveness of the proposed scheme, a comprehensive comparison of its communication costs with those of the aforementioned schemes was conducted. Fig 8 presents a quantitative comparison of communication costs across different schemes. As illustrated, the communication overhead of the proposed scheme falls within the mid-to-high range among all compared solutions. This result is primarily attributed to the transmission of multiple public keys and hash values during the authentication process, which enhances security and attack resistance by incorporating redundant security information. Although this leads to a slight increase in communication overhead, the overall cost remains within a reasonable and controllable range acceptable for practical IoV deployments. Thus, the proposed scheme achieves a balanced trade-off between security and communication efficiency.

Download:

• PNG
  larger image
• TIFF
  original image

Fig 8. Comparison of communication costs of various schemes.

The figure illustrates the specific quantification of the communication costs of various schemes.

https://doi.org/10.1371/journal.pone.0347787.g008