PMAKA-IoV: A Physical Unclonable Function (PUF)-Based Multi-Factor Authentication and Key Agreement Protocol for Internet of Vehicles

Abstract

With the explosion of vehicle-to-infrastructure (V2I) communications in the internet of vehicles (IoV), it is still very important to ensure secure authentication and efficient key agreement because of the vulnerabilities in the existing protocols such as physical capture attacks, privacy leakage, and low computational efficiency. This paper proposes a physical unclonable function (PUF)-based multi-factor authentication and key agreement protocol tailored for V2I environments, named as PMAKA-IoV. The protocol integrates hardware-based PUFs with biometric features, utilizing fuzzy extractors to mitigate biometric template risks, while employing dynamic pseudonyms and lightweight cryptographic operations to enhance anonymity and reduce overhead. Security analysis demonstrates its resilience against physical capture attacks, replay attacks, man-in-the-middle attacks, and desynchronization attacks, and it is verified by formal verification using the strand space model and the automated Scyther tool. Performance analysis demonstrates that, compared to other related schemes, the PMAKA-IoV protocol maintains lower communication and storage overhead.

1. Introduction

The rapid development of the internet of vehicles (IoV) has brought revolutionary changes to intelligent transportation systems (ITSs). Within modern IoV architectures, vehicles are equipped with integrated sensor arrays, edge computing modules, and dedicated communication interfaces such as on-board units (OBUs), enabling dynamic information exchange through standardized communication paradigms including vehicle-to-infrastructure (V2I) and vehicle-to-vehicle (V2V) communication [1]. Specifically, V2I communication facilitates bidirectional real-time interactions between OBUs and roadside units (RSUs), allowing vehicles to obtain real-time traffic information, such as road congestion and accident locations. This capability enables intelligent route planning to bypass congested areas, optimize travel efficiency, and enhance coordinated driving through inter-vehicle data sharing, thereby significantly reducing collision risks and improving road safety.

However, the surge of IoV deployments has inadvertently expanded the attack surface of vehicle networks. The inherent broadcast characteristics of dedicated short-range communications (DSRCs) and cellular-V2X (C-V2X) protocols expose some key vulnerabilities, which can be used by attackers to launch various malicious activities [2], including eavesdropping, tampering, spoofing, and replay attacks. Furthermore, sophisticated adversaries may extract sensitive information stored in OBUs, compromising vehicle owners’ privacy through trajectory reconstruction, or impersonate legitimate entities by forging digital identities. These threats elevate security and privacy concerns in V2I communications to a critical priority, necessitating robust authentication mechanisms to ensure communication integrity and system reliability. Traditional V2I authentication protocols face three key challenges: (1) vulnerability to physical capture attacks, where the stored information of a physically captured device can be obtained by performing power analysis attacks on it; (2) inadequate privacy preservation, where fixed identifiers or pseudonyms enable long-term tracking of user behavior; and (3) inefficiency due to computationally intensive cryptographic operations, hindering real-time response.

In the past few years, many researchers have proposed various V2I authentication protocols. Specifically, physical unclonable function (PUF) can resist physical capture attack because it is the unique identifier of a semiconductor device. Moreover, multi-factor authentication is an authentication mechanism that can enhance security. Therefore, although several authentication and key agreement schemes based on the PUF or multi-factor are proposed for the IoV, which can address certain vulnerabilities, they often exhibit deficiencies in robustness. These gaps highlight the necessity of a holistic approach that balances security, privacy, and efficiency.

In this paper, we present a novel PUF-based multi-factor authentication and key agreement protocol designed for V2I environments, called PMAKA-IoV. Different from previous solutions, our major contributions can be summarized as follows.

• Multi-factor authentication integration: by combining PUF’s hardware characteristics with user’s biometrics, the scheme employs a fuzzy extractor to handle the noise of biometric data, thus eliminating the risk of storing the raw biometric templates in plaintext. This approach enhances the reliability of identity authentication and resistance to spoofing.
• Dynamic privacy protection mechanism: a dynamic pseudonym system is introduced to ensure vehicle identity anonymity and session key untraceability while achieving perfect forward secrecy in the protocol.
• Lightweight design: hash functions and “exclusive or” (XOR) operations replace traditional public key cryptography, significantly reducing computational complexity. Simultaneously, dynamic random number updating and timestamp validation mechanisms can defend against replay attacks and ensure forward security.

In order to verify the security of the protocol, formal proofs using the strand space model show that PMAKA-IoV satisfies critical security properties, including resisting man-in-the-middle attacks, replay attacks, physical capture attacks, and desynchronization attacks. Further, the automated verification via the Scyther tool confirms its bidirectional authentication capability and session key confidentiality. The performance analysis results demonstrate that PMAKA-IoV outperforms the existing schemes in overall performance, especially in computational overhead, thereby meeting real-time requirements for IoV applications. Subsequent sections will elaborate on the protocol design, security analysis, and performance evaluation.

2. Related Works

Research from recent years shows that the emerging authentication technologies provide an innovative direction for IoV security. For example, federated learning-based authentication schemes [3,4] can protect data privacy and improve the accuracy and robustness, but they have the drawbacks of high communication overhead, high requirements for the network, and vulnerability to abnormal model attacks. In addition, edge artificial intelligence-based dynamic security schemes [5] can achieve real-time response and reduce data transmission, but they face challenges such as limited computing resources of edge devices and difficulties in model updating. In 2020, Ma et al. [6] proposed a decentralized key management mechanism for the IoV, which realized the registration, update, and revocation of vehicle public keys based on smart contracts. However, there are performance bottlenecks and high storage costs. Wang et al. [7] proposed a V2I authentication scheme using blockchain to achieve trustworthy and scalable computing, as well as blockchain-based cross-domain authentication schemes [8,9]. These schemes have their own advantages in the field of IoV security authentication, but there are also some problems.

The lightweight nature of PUFs enables them to operate efficiently on resource-constrained IoV devices without imposing excessive computational or storage burdens [10]. For example, in small-scale devices such as vehicle electronic control units, PUFs can achieve security functionalities without significantly increasing hardware costs or power consumption. The unclonability of PUFs stems from the inherent physical variations introduced during chip manufacturing, which generate unique responses that are random and unpredictable, making it difficult for attackers to replicate or forge PUF outputs. The uniqueness of PUFs ensures that the response of each device is different, providing a unique identity identifier that enhances the accuracy and reliability of authentication.

In recent years, an increasing number of scholars have attempted to integrate PUFs into devices and design PUF-based authentication and key agreement protocols. Chatterjee et al. [11] proposed an authentication and key exchange protocol combining identity-based encryption with PUF, which avoids the explicit storage of secret challenge–response pairs (CRPs). However, this scheme fails to achieve user anonymity and relies solely on random number checks to resist replay attacks, leaving certain security vulnerabilities. Aman et al. [12] introduced a PUF-based authentication protocol, establishing a three-tier authentication framework involving RSUs, RSU gateways, and a trusted center. When a vehicle enters a gateway area covered by multiple RSUs, it only needs to initiate a single authentication request to the gateway. By using the unique responses generated by the PUF, the gateway can complete cross-domain authentication and authorization for multiple RSUs synchronously. This protocol fully exploits the properties of PUFs, reducing the risk of key storage while enhancing encryption efficiency through hardware-level random number generation mechanisms. It provides a novel approach and methodology for secure authentication in the IoV. Umar et al. [13] proposed a lightweight PUF-based authentication protocol. This protocol requires only basic operations such as XOR, concatenation, and hashing on resource-constrained devices such as vehicles and RSUs, significantly reducing computational costs and making it suitable for IoV devices with limited resources. However, its anonymity mechanism only relies on temporary identifiers, and it lacks robust dynamic updating abilities. This means that the attacker may crack or trace the temporary identifier within a certain time, thus endangering the privacy protection of users. Xie et al. [14] presented an anonymous authentication scheme based on PUFs and elliptic curve cryptography (ECC). ECC offers high security with relatively low computational complexity, and its integration with the PUF enables anonymous authentication in the IoV. Nevertheless, this scheme has some security flaws. Since it involves only partially trusted RSUs and vehicles during the authentication process, the attacker can spoof malicious RSUs to deceive vehicles into completing the verification process, thereby undermining the reliability of authentication.

Fuzzy extractor is a cryptographic technique that aims to derive fixed-length, reproducible, and secure binary strings from noisy data sources such as biometrics. Due to variations in acquisition environments, sensor devices, and individual physiological states, biometric data inherently contain noise and inconsistencies. Fuzzy extractors address this challenge by reliably extracting stable and secure information from these variable data, thereby meeting the requirements of security-sensitive applications such as authentication systems. Jiang et al. [15] addressed the security shortcomings of identity authentication in the IoV by proposing a three-factor authentication scheme that integrates PUFs, biometrics, and dynamic passwords. By leveraging the hardware characteristics of the PUF, the uniqueness of biometrics, and the randomness of dynamic passwords, the scheme improves the accuracy of feature detection and authentication. Since it is extremely challenging for adversaries to simultaneously forge PUF responses, biometric features, and dynamic passwords, the IoV system can effectively defend against impersonation attacks. This scheme compensates for the lack of anonymity in Chatterjee et al.’s [11] approach. Saleem et al. [16] proposed a lightweight authentication and key agreement scheme for vehicular networks that combines hash functions, XOR operations, and the PUF. This scheme employs the PUF and fuzzy extractors to protect OBUs against physical tampering and cloning attacks. Although the protocol reduces the computational cost and communication overhead, it is still vulnerable to security problems such as desynchronization attacks. Although PUF-based authentication schemes have made progress in the field of IoV security, there is still a lot of room for improvement in terms of both security and performance.

Multi-factor authentication is an authentication mechanism that enhances identity security by combining multiple independent authentication elements. Jiang et al. [17] proposed a cloud-centric three-factor authentication and key agreement protocol (CT-AKA) integrating passwords, biometrics, and smart cards to ensure secure access to both the cloud and autonomous vehicles. Tahir et al. [18] proposed a multi-factor authentication scheme that integrates identity, password, and biometric information. The scheme enhances the robustness of the system by employing simple cryptographic operations to reduce computational overhead and leveraging the vehicle’s geographical coordinates to verify its actual location. However, it still faces security problems such as physical capture attacks. Awais et al. [19] put forward a lightweight privacy-preserving authentication protocol for the vehicular ad hoc network (VANET) using the PUF technique, which provides efficient and secure communication via public channels, but it does not provide PUF challenge–response pair protection. He et al. [20] proposed a verifiable commitment-based mutual authentication and key agreement protocol, called mutual authentication and key agreement protocol based on verifiable commitment (VC-MAKA). However, it is not applicable to high-traffic IoV scenarios. Some important related works are summarized in

Table 1. Summary of the related authentication and key agreement schemes for the IoV.

Scheme	Year	Cryptographic Techniques	Advantages	Limitations
Chatterjee et al. [11]	2018	Uses PUF and hash functions	Avoids explicit storage of secret CRPs	Lacks user anonymity and relies on random number check for replay resistance
Aman et al. [12]	2020	Uses PUF and hash functions	Reduces the risk of key storage via PUF and provides hardware-level random number generation to improve encryption efficiency	Does not provide PUF challenge–response pair protection
Jiang et al. [17]	2020	Uses ECC	Provides three-factor authentication	The computational complexity is relatively high
Umar et al. [13]	2021	Uses XOR, hash functions, and PUF	Uses lightweight operations, thus suitable for resource-constrained devices	Temporary identifiers lack dynamic updates, risking privacy breaches
Jiang et al. [15]	2021	Uses PUF and hash functions	Provides three-factor authentication and resists impersonation attacks	Involves some entities that cannot be fully trusted
Xie et al. [14]	2023	Uses PUF and ECC	Combines PUF with ECC for anonymous authentication and provides high security with low computational complexity	Relies on partially trusted RSUs and vehicles and is vulnerable to spoofing attacks by malicious RSUs
Saleem et al. [16]	2023	Uses PUF, hash functions, XOR, and fuzzy extractor	Provides lightweight operations and protects OBUs from physical tampering and cloning attacks using PUF and fuzzy extractors	Vulnerable to desynchronization attacks
Tahir et al. [18]	2023	Uses XOR and hash functions	Provides multi-factor authentication and verifies vehicle location for system robustness	Vulnerable to physical capture attacks
Awais et al. [19]	2023	Uses PUF, hash functions, and ECC	Provides high security and is free from the influence of known attacks	Does not provide PUF challenge–response pair protection
He et al. [20]	2024	Uses PUF, hash functions, and symmetric encryption/decryption	Provides mutual authentication, secure session key establishment, rapid session key updates, and conditional anonymity	Not applicable to high-traffic IoV scenarios

.

3. System Model

3.1. Network Model

As shown in Figure 1, the network model of the PMAKA-IoV protocol comprises three main entities: vehicle, RSU, and trust authority (TA). Their roles are defined as follows.

Vehicle: As a protocol participant, it completes registration, login, and mutual authentication with RSUs, along with dynamic key agreement. Each vehicle is equipped with an OBU that stores identity information, biometric features, and challenge–response pairs generated by the PUF.

RSU: It is deployed in the traffic infrastructure nodes, and it forwards authentication requests and collaborates in key generation. It stores its own identity, PUF challenge–response pairs, and other security parameters. In addition, it synchronizes security parameters with the TA to ensure consistency and participates in key agreement.

TA: As the core security entity of the system, it is responsible for registering vehicles and RSUs, generating master keys and session keys. It maintains a database to store pseudonyms, hash responses, and other security parameters and coordinates the authentication process.

In Figure 1, each RSU and each vehicle need to undergo RSU registration and vehicle registration before deployment. Then, after the user logins, each vehicle conducts V2I authentication and key agreement with its connected RSU and the TA.

3.2. Threat Model

The network model in this study employs a public wireless communication channel to exchange information between entities. This open environment exposes the system to various security threats. Specifically, malicious attackers (MAs) can exploit the open nature of wireless channels to disrupt normal communications. To comprehensively evaluate the security of the SLAKA-IoD protocol, we adopt two classical threat models for analysis.

Firstly, according to the Dolev–Yao (DY) threat model [21], the MA is assumed to have capabilities as follows:

• Intercepting communications between nodes;
• Tampering with transmitted messages;
• Forging or deleting messages.

Furthermore, we apply the more rigorous Canetti–Krawczyk (CK) threat model [22], which additionally considers the following abilities of the MA:

• Obtaining secret information and session states through session hijacking attacks;
• Conducting ephemeral secret leakage (ESL) attacks;
• Performing physical capture attacks on vehicle nodes.

4. Proposed PMAKA-IoV Protocol

The execution of our proposed PMAKA-IoV protocol is divided into four phases: initialization phase, registration phase, login phase, and authentication phase.

Table 2. The notations used in this protocol.

Notation	Description
Vi	$i^{th}$ vehicle
RSUj	$j^{th}$ RSU
IDvi, PWvi	Identity and password of the user of Vi, respectively
BIOvi	Biometric data of the user of Vi
Cvi, Rvi	PUF challenge–response pair of Vi
IDj, IDt	Identities of RSUj and the TA, respectively
PIDvi	Pseudonym of Vi
Cj, Rj	PUF challenge–response pair of RSUj
ri, rj, rt	Random numbers
T1, T2, T3, T4	Timestamps
$∆T$	Maximum transmission time delay
F·G()	Biometric fuzzy generator function
F·R()	Biometric fuzzy reproducer function
mk	Master key generated by the TA
SKij	Session key between Vi and RSUj
$\left|\right|$,$\oplus$	Concatenation and bitwise XOR operator, respectively
PUF(), h()	PUF function and hash function, respectively
(φvi, φvi*)	Parameters generated by fuzzy extractors

lists the notations used in the protocol. In addition, in order to prevent side channel attacks, dynamic power consumption adjustment, and electromagnetic radiation shielding, randomization and noise injection techniques, as well as physical isolation and real-time monitoring and response, can be further adopted to protect the operation of the protocol. Further, during the implementation and operation of the PMAKA-IoV protocol, compliant commercial cryptographic algorithms should be used, unpredictable random numbers should be generated based on a high-entropy random number generator, and the keys should be updated regularly.

4.1. Initialization Phase

The TA selects a one-way cryptographic hash function h:{0,1}* to register all vehicles and generates a master key mk.

4.2. Registration Phase

4.2.1. Vehicle Registration

The vehicle registration process is illustrated in Figure 2 and proceeds as follows:

1.

The vehicle V_i generates its identity ID_vi and sends it to the TA.

2.

Upon receiving ID_vi, the TA queries its database to verify whether ID_vi already exists. If not, the TA generates a challenge C_vi, computes the pseudonym PID_vi = h(ID_vi$\left|\right|$C_vi), and sends {PID_vi, C_vi, ID_t} to V_i, where ID_t is the identity of the TA.

3.

After receiving the message, V_i computes the response R_vi = PUF(C_vi) and HR_vi = h(C_vi$\left|\right|$R_vi). The user of V_i then inputs its password PW_vi and biometric data BIO_vi. Subsequently, V_i calculates F·G(BIO_vi) = (φ_vi, φ_vi*) and A = h(ID_vi$\left|\right|$PW_vi$\left|\right|$φ_vi). Finally, V_i stores [φ_vi*, A, PID_vi, ID_t, C_vi] in the OBU and sends {HR_vi} to the TA.

4.

The TA securely stores [ID_vi, PID_vi, ID_t, HR_vi] in its database.

Figure 2. Vehicle registration.

Figure 2. Vehicle registration.

4.2.2. RSU Registration

The registration process for the RSU is illustrated in Figure 3 and proceeds as follows:

1.

RSU_j sends its identity ID_j to the TA, where RSU_j is the $j^{th}$ RSU.

2.

The TA generates a challenge C_j and sends it to RSU_j.

3.

Upon receiving the message, RSU_j computes the response R_j = PUF(C_j) and HR_{j =} h(C_j$\left|\right|$R_j). It then stores [ID_j, C_j] locally and sends HR_j to the TA.

4.

The TA securely stores [ID_j, HR_j] in its database.

Figure 3. RSU registration.

Figure 3. RSU registration.

4.3. Login Phase

1.

The user of V_i inputs ID_vi, PW_vi, and BIO_vi.

2.

By using the fuzzy extractor, V_i calculates φ_vi = F·R(BIO_vi,φ_vi*) and computes A′ = h(ID_vi$\left|\right|$PW_vi$\left|\right|$φ_vi). V_i then verifies whether the computed A′ matches the stored security parameter A. If they are equal, the login succeeds.

4.4. V2I Authentication and Key Agreement Phase

The authentication process between vehicle V_i and RSU_j, as shown in Figure 4, proceeds as follows:

1.

V_i computes R_vi = PUF(C_vi) and HR_vi = h(C_vi$\left|\right|$R_vi), generates a random number r_i and a timestamp T₁, and then calculates A₁ = ID_vi$\oplus$HR_vi$\oplus$ID_t$\oplus$r_i and M₁ = h(ID_j$\left|\right|$PID_vi$\left|\right|$HR_vi$\left|\right|$r_i$\left|\right|$A₁$\left|\right|$T₁). Finally, V_i sends {PID_vi,M₁,A₁,T₁} to RSU_j.

2.

Upon receiving the message, RSU_j generates a timestamp T₂. If |T₂-T₁|<∆T, the message is discarded, i.e., verifying the freshness of T₁. Otherwise, RSU_j generates a random number r_j; computes R_j = PUF(C_j), HR_j = h(C_j$\left|\right|$R_j), A₂ = ID_j$\oplus$HR_j$\oplus$r_j, and M₂ = h(M₁$\left|\right|$ID_t$\left|\right|$HR_j$\left|\right|$r_j$\left|\right|$A₂$\left|\right|$T₂); and then sends {PID_vi,ID_j,,M₂,A₁,A₂,T₁,T₂} to the TA.

3.

The TA verifies the freshness of T₂. By using PID_vi, it retrieves HR_vi and ID_vi, computes r_i = ID_vi$\oplus$HR_vi$\oplus$ID_t$\oplus$A₁, validates M₁ = h(ID_j$\left|\right|$PID_vi$\left|\right|$HR_vi$\left|\right|$r_i$\left|\right|$A₁$\left|\right|$T₁), and retrieves HR_j based on ID_j. Next, it computes r_j = ID_j$\oplus$HR_j$\oplus$A₂ and M₂′ = h(M₁$\left|\right|$ID_t$\left|\right|$HR_j$\left|\right|$r_j$\left|\right|$A₂$\left|\right|$T₂) and then verifies whether M₂′ = M₂. If this is valid, the TA generates a new random number r_t^new, a timestamp T₃, and a master key mk. It computes PID_vi^new = h(ID_vi$\left|\right|$C_vi$\left|\right|$r_t), X = mk$\oplus$HR_vi$\oplus$r_t, Y = mk$\oplus$HR_j$\oplus$r_t, A₃ = r_j$\oplus$(r_i$\left|\right|$r_t), M₃ = h(ID_j$\left|\right|$mk$\left|\right|$r_j$\left|\right|$r_t$\left|\right|$HR_j$\left|\right|$T₃), and M₄ = h(ID_vi$\left|\right|$mk$\left|\right|$r_i$\left|\right|$r_t$\left|\right|$HR_vi$\left|\right|$T₃)). The TA stores PID_vi^new and sends {A₃, M₃, M₄, X, Y, T₃} to RSU_j.

4.

RSU_j generates timestamp T₄; verifies the freshness of T₃; computes (r_i$\left|\right|$r_t) = r_j$\oplus$A₃, mk = Y$\oplus$HR_j$\oplus$r_t, and M₃′ = h(ID_j$\left|\right|$mk$\left|\right|$r_j$\left|\right|$r_t$\left|\right|$HR_j$\left|\right|$T₃); and then checks whether M₃′ = M₃. If this is valid, RSU_j calculates the session key SK_ij = h(ID_j$\left|\right|$PID_vi$\left|\right|$r_i$\left|\right|$r_j$\left|\right|$ r_t$\left|\right|$mk), computes A₄ = r_i$\oplus$(r_j$\left|\right|$r_t) and M₅ = h(ID_j$\left|\right|$M₄$\left|\right|$PID_vi$\left|\right|$SK_ij$\left|\right|$T₄), and then sends {A₄,X,M₄,M₅,T₃,T₄} to V_i.

5.

V_i verifies the freshness of T₄; computes (r_j$\left|\right|$r_t) = r_i$\oplus$A₄, mk = X$\oplus$HR_vi$\oplus$r_t, and M₄′ = h(ID_vi$\left|\right|$mk$\left|\right|$r_i$\left|\right|$r_t$\left|\right|$HR_vi$\left|\right|$T₃); and then checks whether M₄′ = M₄. If this is valid, V_i computes M₅′ = h(ID_j$\left|\right|$M₄$\left|\right|$PID_vi$\left|\right|$SK_ij$\left|\right|$T₄) and verifies whether M₅′ = M₅. If this is valid, V_i updates PID_vi^new in the OBU.

Figure 4. V2I authentication and key agreement.

Figure 4. V2I authentication and key agreement.

5. Security Analysis

This section provides a detailed security analysis of PMAKA-IoV. Firstly, an informal analysis of PMAKA-IoV is conducted. Subsequently, a formal verification of PMAKA-IoV is performed using the strand space model. Furthermore, the simulations with the Scyther tool are carried out to further validate PMAKA-IoV’s security. Finally, we compare the security features of PMAKA-IoV and other relevant schemes.

5.1. Informal Analysis

In this section, we conduct an informal analysis of the PMAKA-IoV protocol. It resists various threats including replay attacks, man-in-the-middle attacks, desynchronization attacks, and physical capture attacks, covering common attack scenarios in the IoV environment. Additionally, it satisfies many security features, such as perfect forward secrecy, mutual authentication, and anonymity.

1.

Physical Capture Attack

In the above protocol, HR_vi and HR_j, rather than R_vi and R_j, are securely transmitted to the TA and stored in it. Therefore, it is difficult for an attacker to obtain R_vi and R_j. Even if the attacker can acquire HR_vi and HR_j based on the CK threat model, it will be unable to reverse-engineer R_vi and R_j from them, as they are generated via hash functions. Additionally, C_vi is stored in V_vi rather than in the TA, and similarly, C_j is stored in RSU_j rather than in the TA. Thus, to obtain the PUF challenge–response pair of V_vi, the attacker will need to physically capture V_vi to acquire C_vi based on the CK threat model. Likewise, to obtain the PUF challenge–response pair of RSU_j, the attacker will need to physically capture RSU_j to acquire C_j based on the CK threat model.

2.

Replay Attack

Upon receiving a message, the recipient checks the validity of the timestamp in the message, and messages that fail the check will be discarded. Furthermore, the messages {M₁, M₂, M₃, M₄, M₅} are all bound to timestamps. If an attacker attempts to modify the timestamp for a replay attack, the authentication will fail.

3.

Man-in-the-Middle Attack

If an attacker attempts to carry out a man-in-the-middle attack on the protocol, it must intercept and tamper with the protocol’s messages. As described above, {PID_vi, M₁, A₁, T₁}, {PID_vi, ID_j, M₂, A₁, A₂, T₁, T₂}, {A₃, M₃, M₄, X, Y, T₃}, and {A₄, X, M₄, M₅, T₃, T₄} are protected by HR_vi or HR_j, which are unknown to the attacker. Thus, although the attacker may intercept these messages, it cannot tamper with them, thereby preventing man-in-the-middle attacks.

4.

Session Key Disclosure Attack

The session key SK_ij between V_vi and RSU_j is computed as SK_ij = h(ID_j$\left|\right|$PID_vi$\left|\right|$r_i$\left|\right|$r_j$\left|\right|$r_t$\left|\right|$mk). An attacker cannot compute SK_ij because it lacks access to the random numbers r_i, r_j, and r_t generated by V_vi, RSU_j, and the TA, respectively, as well as the master key mk.

5.

Desynchronization Attack

V_vi stores the old value {PID_vi} before receiving the fourth message and updates PID_vi = PID_vi^new after receiving the second message of the phase. Moreover, the TA stores both the old value {PID_vi} and the new value {PID_vi^new}. Therefore, no matter whether the attacker tampers with the third or fourth message to execute a desynchronization attack, there will always be a set of pseudo-identities and key material values shared between V_vi and the TA for this phase.

6.

Mutual Authentication

During the phase of authentication and key agreement between V_vi and RSU_j, the TA verifies the legitimacy of V_vi via HR_j and validates RSU_j by checking whether M₂ = h(M₁$\left|\right|$ID_t$\left|\right|$HR_j$\left|\right|$r_j$\left|\right|$A₂$\left|\right|$T₂) holds. This is because only the TA and V_vi know HR_vi, and only the TA and RSU_j know HR_j. Similarly, RSU_j and V_vi verify the authenticity of the messages from the TA by checking whether M₃ = h(ID_j$\left|\right|$mk$\left|\right|$r_j$\left|\right|$r_t$\left|\right|$HR_j$\left|\right|$T₃) and M₄ = h(ID_vi$\left|\right|$mk$\left|\right|$r_i$\left|\right|$r_t$\left|\right|$HR_vi$\left|\right|$T₃) hold, respectively.

7.

Anonymity and Untraceability

During the phase of authentication and key agreement between V_vi and RSU_j, the pseudo-identity PID_vi is used instead of the real identity ID_vi. Hence, an adversary cannot obtain ID_vi, ensuring the vehicle’s anonymity. Furthermore, PID_vi is updated during this phase, preventing the adversary from using PID_vi to trace V_vi. Thus, our proposed protocol guarantees untraceability.

8.

Perfect Forward Secrecy

The session key SK_ij is dynamically generated using the temporary random numbers r_i, r_j, and r_t and the master key mk. Therefore, even if long-term keys are compromised, past sessions remain secure.

9.

Denial-of-Service (DoS) Attack

The PMAKA-IoV protocol uses hash functions and XOR operations at its core, avoiding complex cryptography such as elliptic curve math. This makes the processing speed of each request very fast, and even if many requests are processed at the same time, the response ability of the system can be maintained. Each message includes a timestamp. If the receiver finds that the time difference exceeds the limit ∆T, it will drop the request immediately to save resources. Each session also creates unique random numbers associated with the hash values M₁ = h(ID_j$\left|\right|$PID_vi$\left|\right|$HR_vi$\left|\right|$r_i$\left|\right|$A₁$\left|\right|$T₁), which prevents attackers from reusing old numbers to drown the system. This can prevent resources from being overloaded.

10.

Impersonation Attack

The PMAKA-IoV protocol prevents impersonation attacks through multi-factor authentication and dynamic identity mechanisms. Vehicles must simultaneously provide a PUF hardware response R_vi = PUF(C_vi), biometric features (processed into stable keys φ_vi via fuzzy extractors, and dynamic pseudonym PID_vi. The physical unclonability of the PUF and the uniqueness of biometrics make it impossible to forge all three factors at the same time. Furthermore, the pseudonym PID_vi is dynamically updated with PID_vi^new = h(ID_vi$\left|\right|$C_vi$\left|\right|$r_t) after each session, which ensures that the intercepted pseudonyms cannot be reused in subsequent sessions, thereby eliminating long-term impersonation risks.

11.

ESL Attacks

The PMAKA-IoV protocol effectively mitigates ESL attacks through multi-parameter binding and session isolation mechanisms. The session key SK_ij = h(ID_j$\left|\right|$PID_vi$\left|\right|$r_i$\left|\right|$r_j$\left|\right|$r_t$\left|\right|$mk) is derived from a combination of ephemeral random numbers r_i, r_j, and r_t and the master key mk. Leakage of a single ephemeral parameter cannot compromise the whole key due to the interdependency of multiple parameters. Additionally, the protocol employs perfect forward secrecy, ensuring that ephemeral random numbers are valid only for a single session and destroyed afterward. Even if r_i, r_j, and r_t from a session are leaked based on the CK threat model, historical and future sessions remain secure due to the use of independently generated random numbers. Furthermore, the master key mk is only used to derive encrypted parameters and is not directly linked to ephemeral values, thus preventing attackers from using leaked ephemeral secrets to reverse-engineer long-term keys. The dynamic pseudonym update mechanism ensures that even if a pseudonym from a session is leaked based on the CK threat model, it cannot be tracked or reused across sessions, thus completely limiting the influence scope of ESL attacks.

5.2. Formal Analysis

The strand space model [23,24,25], a rigorously validated formal framework for analyzing security protocols, is adopted in this work to assess the security of our proposed PMAKA-IoV protocol. The detailed analysis proceeds as follows.

Definition 1.

An infiltrated strand space, Σ,P, is a space for the V2I authentication and key agreement phase of PMAKA-IoV if it is the union of the following four types of strands: Initiator Strand s$\in$Init[ID_vi, ID_j, ID_t, r_i, r_j, r_t, mk, PID_vi, T₁, T₃, T₄]: The trace is < + m₁, −m₄ >, associated with the entity V_vi. Responder Strand s$\in$Resp[ID_vi, ID_j, ID_t, r_i, r_j, r_t, mk, PID_vi, T₁, T₂, T₃, T₄]: The trace is <−m₁, + m₂, −m₃, + m₄>, associated with the entity RSU_j. Server Strand s$\in$Serv[ID_vi, ID_j, ID_t, r_i, r_j, r_t, mk, PID_vi, T₁, T₂, T₃]: The trace is <−m₂, + m₃ >, associated with the entity TA. Penetrator Strand s$\in$P.

Theorem 1.

Suppose that (a) Σ is a space for the V2I authentication and key agreement phase of PMAKA-IoV, and C is a bundle in Σ containing an initiator strand s with trace s$\in$ Init[ID_vi, ID_j, ID_t, r_i, r_j, r_t, mk, PID_vi, T₁, T₃, T₄]; (b) HR_vi, HR_j$\notin$ K_P; and (c) r_i, r_j, and r_t are uniquely originated in Σ, and r_i$\ne$ r_j$\ne$ r_t. Then, C contains a responder t$\in$ Resp[ID_vi, ID_j, ID_t, r_i, r_j, r_t, mk, PID_vi, T₁, T₂′, T₃, T₄] and a server strand r$\in$ Serv[ID_vi, ID_j, ID_t, r_i, r_j, r_t, mk, PID_vi, T₁, T₂′, T₃].

Proof of Theorem 1.

By assumptions (b) and (c), M₅$\subset$ term(<s, 2>) uniquely originates from a responder strand t$\in$ Resp[ID_vi, ID_j, ID_t′, r_i, r_j, r_t, mk,PID_vi,T₁′,T₂′,T₃,T₄]. Similarly, M₁ $\subset$ term(<t, 1>) uniquely originates from an initiator strand s′$\in$ Init[ID_vi, ID_j″, ID_t′, r_i, r_j, r_t″, mk″,PID_vi, T₁′, T₃″, T₄″]. From assumption (c), s′ = s, implying ID_t′ = ID_t and T₁′ = T₁. Additionally, M₃ $\subset$ term(<t, 3>) uniquely originates from a server strand r$\in$ Serv[ID_vi‴, ID_j, ID_t‴, r_i‴, r_j, r_t, mk, PID_vi‴, T₁‴, T₂‴, T₃], and M₂ $\subset$ term(<r, 1>) originates from a responder strand t′$\in$Resp[ID_vi‴, ID_j, ID_t‴, r_i‴, r_j, r_t⁗, mk‴, PID_vi‴, T₁‴, T₂‴, T₃⁗, T₄⁗]. By assumption (c), t′ = t, so ID_vi‴ = ID_vi, ID_t‴ = ID_t, r_i ‴ = r_i, PID_vi‴ = PID_vi, T₁‴ = T₁, and T₂‴ = T₂′. □

By Theorem 1, V_vi authenticates RSU_j and the TA. Both the responder strand t and the server strand r include T₂′, as this field is only transmitted between RSU_j and the TA and is unknown to the initiator strand s.

Theorem 2.

Suppose that (a) Σ is a space for the V2I authentication and key agreement phase of PMAKA-IoV, and C is a bundle in Σ containing a responder strand s with traces s$\in$ Resp[ID_vi, ID_j, ID_t, r_i, r_j, rt, mk, PID_vi, T₁, T₂, T₃, T₄]; (b) HR_vi, HR_j$\notin$ K_P; (c) r_i, r_j, and r_t are uniquely originated in Σ, and r_i$\ne$ r_j$\ne$ r_t. Then, C contains an initiator strand t$\in$ Init[ID_vi, ID_j, ID_t, r_i, r_j, r_t, mk, PID_vi, T₁, T₃, T₄] and a server strand r$\in$ Serv[ID_vi, ID_j, ID_t, r_i, r_j, r_t, mk, PID_vi, T₁, T₂, T₃].

Proof of Theorem 2.

By assumptions (b) and (c), M₃⊂ term (<s, 3>) uniquely originates from a server strand r$\in$ Serv[ID_vi′, ID_j, ID_t′, r_i′, r_j, r_t, mk,PID_vi′,T₁′,T₂′,T₃]. Similarly, M₂$\subset$ term (<r, 1>) originates from a responder strand s′$\in$ Resp[ID_vi′, ID_j, ID_t′, r_i′, r_j, r_t″, mk″, PID_vi′, T₁′, T₂′, T₃″, T₄″]. From assumption (c), s′ = s, implying ID_vi′ = ID_vi, ID_t′ = ID_t, r_i′ = r_i, PID_vi′ = PID_vi, T₁′ = T1, and T₂′ = T₂. Moreover, M₁ ⊂ term(<s, 1>) uniquely originates from an initiator strand t$\in$ Init[ID_vi, ID_j, ID_t, r_i, r_j‴, r_t‴, mk‴,PID_vi,T₁,T₃‴,T₄‴], and M₅$\subset$ term(<t, 2>) originates from a responder strand s″$\in$ Resp[ID_vi, ID_j, ID_t⁗, r_i, r_j‴, r_t‴, mk‴, PID_vi, T₁⁗, T₂⁗, T₃‴, T₄‴]. By assumption (c), s″ = s, so r_j‴ = r_j, r_t‴ = r_t, mk‴ = mk, T₃‴ = T₃, and T₄‴ = T₄. □

By Theorem 2, RSU_j successfully authenticates V_vi and the TA.

5.3. Security Verification Based on Scyther

Scyther [26,27], introduced and utilized by Cremers, is a powerful formal verification tool that serves as a cornerstone for analyzing security protocols. It specializes in verifying potential threats, such as forgery and tampering. In this study, we leverage Scyther’s capabilities to simulate the V2I authentication and key agreement phase of the PMAKA-IoV protocol by using the security protocol description language (SPDL). The Scyther tool employs symbolic model checking to exhaustively analyze protocol execution paths under the Dolev–Yao adversary model [21] (where the attackers control the network and can intercept, modify, or replay messages). This section provides a detailed exposition of the experimental results.

As shown in Figure 5, the formal verification using the Scyther tool demonstrates that the PMAKA-IoV protocol meets the design requirements for core security properties, including confidentiality, authenticity, and freshness. Furthermore, the protocol can resist various attacks, such as replay, man-in-the-middle, and desynchronization attacks. The verification results further support the security claims made in the informal analysis, confirming the protocol’s reliability and robustness in practical vehicular network environments. The main findings are as follows:

1.

No Successful Attack Traces: Scyther exhaustively explored all possible interleavings of protocol runs and failed to find any violations of the specified security properties. For example, the attempts to forge M₃ = h(ID_j$\left|\right|$mk$\left|\right|$r_j$\left|\right|$r_t$\left|\right|$HR_j$\left|\right|$T₃) without knowledge of HR_j or mk were detected as invalid.

2.

Mutual Authentication Guarantees: The tool verified that V_vi and R_j mutually authenticate each other through TA-mediated validation of M₁, M₂, M₄, and M₅. Any tampering with these messages will destroy the integrity of the hash-chain, thus triggering the termination of the protocol.

3.

Session Key Confidentiality: Scyther confirmed that SK_ij remains secret even if the long-term key mk is compromised, as SK_ij relies on ephemeral values erased after each session.

4.

Desynchronization Resilience: The dual pseudonym storage of this protocol ensures continuity, even though messages are lost or tampered. Scyther validated that the TA retains both versions until successful key confirmation, preventing denial-of-service via forced state mismatches.

Figure 5. The Scyther-based verification results of the PMAKA-IoV protocol.

Figure 5. The Scyther-based verification results of the PMAKA-IoV protocol.

5.4. Security Comparison

Table 3. Comparison of the security features of the V2I authentication and key agreement phase.

Feature	Li et al. [28]	Yadav et al. [29]	Saleem et al. [16]	PMAKA-IoV
Anonymity	✔	✔	✔	✔
Mutual Authentication	✔	✔	✔	✔
Resistance to Man-in-the-Middle Attack	✗	✔	✔	✔
Resistance to Replay Attack	✗	✗	✗	✔
Unlinkability	✗	✗	✔	✔
Resistance to Password Guessing Attack	✔	✔	✔	✔
Resistance to Desynchronization Attack	✗	✗	✗	✔
Resistance to Impersonation Attack	✔	✔	✔	✔
Resistance to DoS Attack	✗	✗	✗	✔
Resistance to Physical Capture Attack	✗	✗	✔	✔
Perfect Forward Secrecy	✗	✔	✔	✔

demonstrates that the PMAKA-IoV scheme exhibits superior security characteristics compared to similar authentication schemes, proving more resilient against various types of security attacks. The comparison includes the existing representative authentication and key agreement schemes.

In Table 3, all the messages of the PMAKA-IoV protocol are protected by HR_vi or HR_j, which are unknown to the attacker, and they are bound to fresh timestamps, so the PMAKA-IoV protocol can resist man-in-the-middle attack, reply attack, and DoS attack, while the scheme in [28] cannot resist man-in-the-middle attack, and the schemes in [16,28,29] cannot resist replay attack or DoS attack. Our proposed PMAKA-IoV protocol and the scheme in [16] are based on the PUF, so they can resist physical capture attack, while the schemes in [28,29] cannot resist this attack because they do not use PUFs. In the PMAKA-IoV protocol, the TA stores both the old value PID_vi and the new value PID_vi^new to resist desynchronization attack, while the schemes in [16,28,29] do not provide this mechanism. Moreover, PID_vi^new is generated in a secret way in the PMAKA-IoV protocol, so the attacker cannot link PID_vi to PID_vi^new, while the schemes in [28,29] do not provide unlinkability.

6. Performance Analysis

This section evaluates the practical efficiency of the PMAKA-IoV protocol through rigorous analysis of the communication cost, storage cost, computation cost, and energy cost.

6.1. Communication Cost

In order to evaluate the communication cost and storage cost, we consider that the sizes of the timestamp, identity, random number, hash value, AES value, PUF challenge, and PUF response are 64 bits, 80 bits, 160 bits, 256 bits, 128 bits, 32 bits, and 320 bits, respectively.

During the authentication and key agreement phase, for our scheme, the message {PID_vi,M₁,A₁,T₁} requires 256 + 256 + 256 + 64 = 832 bits, the message {PID_vi,ID_j,M₂,A₁,A₂,T₁,T₂} requires 256 + 256 + 256 + 256 + 80 + 64 + 64 = 1232 bits, the message {A₃,M₃,M₄,X,Y,T₃} requires 256 + 256 + 256 + 256 + 64 + 160 = 1248 bits, and the message {A₄,X,M₄,M₅,T₃,T₄} requires 256 + 256 + 256 + 64 + 64 + 160 = 1056 bits, totaling 4368 bits. Similarly, for the scheme in [28], it requires 256 + 256 + 256 + 256 + 256 + 256 + 256 + 256 + 256 + 256 + 256 + 256 + 256 + 256 + 256 + 256 + 256 + 256 + 256 + 256 + 160 + 160 + 64 + 64 + 64 + 64 = 5696 bits. For the scheme in [29], it requires 320 + 320 + 320 + 320 + 320 + 320 + 320 + 320 + 320 + 320 + 64 + 64 + 64 + 64 + 160 = 3616 bits. For the scheme in [16], it requires 256 + 256 + 256 + 256 + 256 + 256 + 160 + 160 + 160 + 160 + 160 + 160 + 160 + 160 + 128 + 128 = 3072 bits.

Table 4. Comparison of the communication cost of the V2I authentication and key agreement phase.

Scheme	Communication Cost
PMAKA-IoV	4368 bits
Li et al. [28]	5696 bits
Yadav et al. [29]	3616 bits
Saleem et al. [16]	3072 bits

compares the communication cost between our scheme and other schemes.

As can be seen from Table 4 and Figure 6, the scheme in [28], which is based on hash and XOR operations, involves a higher communication cost than our scheme. However, our scheme has a higher communication cost than the schemes in [16,29]. This represents a trade-off between communication efficiency and the additional security features provided by our lightweight yet secure authentication protocol.

For PMAKA-IoV, if the number of vehicles in an IoV network is n, the theoretical communication cost during the V2I authentication and key agreement phase can reach (4368 × n!)/((n − 2)! × 2) bits. As shown in Figure 7, the communication cost comparison among different schemes under varying numbers of vehicles can be observed. In the actual scenarios, this phase is performed on-demand, thereby avoiding a sudden increase in communication cost. Consequently, the PMAKA-IoV protocol is still suitable in terms of communication cost.

6.2. Storage Cost

In the vehicle and RSU registration phase of our scheme, the PUF challenge–response pairs, biometric fuzzy parameters, and dynamic pseudo-identity information are stored. The TA stores 80 + 80 + 80 + 256 + 256 + 256 = 1008 bits, each vehicle stores 80 + 256 + 256 + 160 + 32 = 784 bits, and each RSU stores 80 + 32 = 112 bits, totaling 1904 bits of storage cost. The calculation of the storage cost does not consider the newly generated messages during the execution of the protocol, which will be deleted later because they are usually located in memory.

Similarly, for the scheme in [28], the TA stores 80 + 160 + 160 = 400 bits, each vehicle stores 256 + 256 + 256 + 80 = 848 bits, and each RSU stores 80 + 160 = 240 bits, totaling 1488 bits of storage cost. For the scheme in [29], the TA stores 256 + 256 + 256 = 768 bits, each vehicle stores 256 + 256 + 256 + 320 + 80 = 1168 bits, and each RSU stores 256 bits, totaling 2192 bits of storage cost. For the scheme in [16], the TA stores 256 + 256 + 256 = 768 bits, each vehicle stores 128 + 256 + 256 + 256 + 160 = 1056 bits, and each RSU stores 256 + 80 = 336 bits, totaling 2160 bits of storage cost.

Table 5. Comparison of the storage cost of the V2I authentication and key agreement phase.

Scheme	Vehicle	TA	RSU	Total Cost
PMAKA-IoV	784 bits	1008 bits	112 bits	1904 bits
Li et al. [28]	848 bits	400 bits	240 bits	1488 bits
Yadav et al. [29]	1168 bits	768 bits	256 bits	2192 bits
Saleem et al. [16]	1056 bits	768 bits	336 bits	2160 bits

compares the storage cost between the PMAKA-IoV protocol and the other schemes.

As can be seen from Table 5 and Figure 8, the scheme in [28] stores pseudo-identities, hash values, and random numbers in both the TA and the OBU, resulting in a lower storage cost than our scheme due to the fewer stored security parameters. However, this scheme stores vehicle registration parameters in plaintext within the OBU, which may lead to security problems. If a smart card is stolen, the attackers can obtain these parameters and impersonate vehicles. Moreover, compared with the other schemes in [16,29], our scheme still has advantages in storage cost.

For the PMAKA-IoV protocol, when the number of vehicles in a V2I network is n, the storage cost amounts to (784n + 1008 + 112) bits. In Figure 9, a comparative analysis of the storage cost across different schemes under varying vehicle numbers is presented. Because the storage cost of vehicles is relatively low, with the increase in the number of vehicles, the advantages of the PMAKA-IoV protocol become increasingly obvious.

6.3. Computation Cost

The computation cost during the V2I authentication and key agreement phase of our scheme comprises the sum of the computation cost from three entities. According to the execution time per operation [16,28,29,30,31], some symbols for the execution time are defined as shown in

Table 6. Execution time cost of each operation.

Operation	Notation	Execution Time Per Operation
One-way hash function	Th()	0.0020 ms
AES encryption	TAE	0.0100 ms
AES decryption	TAD	0.0100 ms
PUF operation	TPUF	0.00013 ms
Elliptic curve multiplication	TECC	2.6100 ms
Multiplication operation	TMUL	0.2680 ms

.

As demonstrated in

Table 7. Comparison of the computation cost of the V2I authentication and key agreement phase.

Scheme	Computation Cost	Total Cost
PMAKA-IoV	16Th() + 2TPUF	0.0323 ms
Li et al. [28]	23Th()	0.0460 ms
Yadav et al. [29]	16Th() + 14TECC	36.570 ms
Saleem et al. [16]	16Th() + 3TMUL + 2TPUF + 2TAE + 2TAD	0.8750 ms

and Figure 10, which compare the computation cost between the PMAKA-IoV protocol and the other schemes, the scheme in [29] involves multiple ECC point multiplication operations, resulting in a higher computational complexity. Our scheme reduces computational overhead by employing more efficient cryptographic operations.

In Figure 11, the computation cost comparison of different schemes under varying numbers of vehicles is presented. For the PMAKA-IoV protocol, theoretically, when the number of vehicles in an IoV network is n, the computation cost during the V2I authentication and key agreement phase is (0.0323 × n!)/((n − 2)! × 2) ms. The results demonstrate that the PMAKA-IoV protocol can meet the real-time requirements for V2I communications in terms of computation cost.

6.4. Energy Cost

During the communication between vehicles and other entities, performing any computation consumes energy, and a high energy cost may negatively affect the performance of the authentication scheme. As described in [31], the formula for calculating the energy cost is as follows: energy cost $=$ total computation cost × maximum processing power.

Generally, the maximum processing power in wireless transmission is 10.88 W [32]. Hence, for our scheme, the energy cost is 0.35 mJ (i.e., 0.0323 × 10.88 ≈ 0.35 mJ). Similarly, the energy costs of the schemes in [16], [29], and [28] are 9.52 mJ (i.e., 0.8750 × 10.88 ≈ 9.52 mJ), 397.88 mJ (i.e., 36.570 × 10.88 ≈ 397.88 mJ), and 0.50 mJ (i.e., 0.460 × 10.88 ≈ 0.50 mJ), respectively. As demonstrated in Figure 12, our scheme maintains a low energy cost. In addition, the energy cost comparison of different schemes under varying numbers of vehicles is similar to Figure 11.

7. Conclusions

We propose a PUF-based multi-factor authentication and key agreement protocol for the internet of vehicles, named PMAKA-IoV. From the aspect of security analysis, we first conducted an informal security analysis to illustrate its defense ability against various potential threats. Then, we performed a rigorous logical proof of the protocol’s security using the strand space model as a formal verification tool, further confirming its theoretical reliability. Finally, we comprehensively tested the protocol’s security using the Scyther automated verification tool, verifying its effectiveness against various known attacks.

Compared with the existing V2I security protocols of the same type, the PMAKA-IoV protocol demonstrates significant advantages in security. By introducing the PUF’s unique characteristics, the key unpredictability and physical anti-cloning ability are realized, effectively enhancing the overall security of the protocol. The PMAKA-IoV protocol also fully considers the efficiency and practicality of the authentication process, avoiding unnecessary computational overhead and communication delays.

In terms of performance, we conducted an in-depth analysis and evaluation. While satisfying more security properties, the PMAKA-IoV protocol maintains a low overhead and demonstrates outstanding performance in computing speed.