CD-AKA-IoV: A Provably Secure Cross-Domain Authentication and Key Agreement Protocol for Internet of Vehicle

1  Introduction

With the Internet of Things (IoT) technology and artificial intelligence continuing to evolve and gain popularity, the field of Internet of Vehicles (IoV) [1,2] has gained significant prominence. IoV enables real-time monitoring and early warning of traffic information through data interaction and information sharing between vehicles and infrastructure, reducing the occurrence of traffic accidents. In the IoV environments, on-board units (OBU) installed in vehicles play a crucial role in exchanging messages with roadside units (RSU) deployed on both sides of the road. RSU can transmit the collected messages to passing vehicles to provide real-time traffic information. This information exchange enables vehicles to promptly identify the traffic situations and take necessary measures.

The open nature of the IoV makes messages transmitted over public channels highly susceptible to becoming targets for attackers, posing risks of interception, tampering, and eavesdropping [3–5]. Moreover, attackers can maliciously impersonate legitimate vehicles. This vulnerability jeopardizes communication between vehicles and the RSU, and even potentially compromises users’ privacy [6–8]. As a result, ensuring the communication security of vehicles and RSUs in the IoV environments becomes imperative. To address this concern, researchers have proposed various authentication and key agreement (AKA) protocols [9–11] to enhance the security of communications between vehicles and RSUs.

However, when vehicles move from one domain to another, cross-domain authentication will be a great challenge. Fig. 1 shows the frequently employed cross-domain architecture of the IoV. This architecture comprises three entities: vehicle, RSU, and cloud server (CS). The CS is in charge of registering both vehicles and RSUs, and helps them in the domain to achieve authentication. In recent years, researchers have conducted in-depth research in the IoV, dedicating significant efforts to addre ssing the challenges of cross-domain authentication. Xu et al. [12] devised an authentication protocol aimed at enhancing secure communication among diverse vehicle networks operating within various domains. Yang et al. [13] proposed a multi-domain vehicle authentication architecture based on blockchain technology, which effectively enables cross-domain information sharing among multiple management domains by establishing a distributed trust mechanism. Yu et al. [14] designed an innovative handover authentication protocol that utilizes blockchain to record vehicle information and verify vehicle legitimacy. To address the vulnerability of vehicles to physical attacks, Jiang et al. and Babu et al. [15,16] deployed physically unclonable functions (PUF) [17] in vehicles. Yan et al. [18] devised a certificateless group handover authentication protocol within a 5G vehicular network environment. Chen et al. [19] presented a key transfer authentication protocol that employs confidential computing environments. Their protocol includes a key transmission phase that facilitates the secure exchange of keys between different RSUs within the same fog node (FN) and different RSUs in distinct FNs.

Figure 1: Cross-domain architecture in the IoV

Currently, there is a scarcity of AKA protocols in IoV to ensure secure cross-domain authentication. To enable secure communication when vehicles cross domains, we propose a cross-domain authentication protocol for vehicles in this paper. Building upon the architecture depicted in Fig. 1, we design intra-domain authentication and cross-domain authentication for vehicles. In our design, when a vehicle within a specific domain intends to move to another domain, the cross-domain request needs to be transmitted to the RSU in the destination domain to ensure cross-domain authentication. With the assistance of the CS, the RSU in the intra-domain can transmit the related cross-domain information about the vehicle to the RSU in the cross-domain. Upon receiving the message, the RSU (cross-domain) searches its database and determines the communication status with the vehicle. If it is the first communication between the vehicle and the RSU (cross-domain), the RSU will request the information of the vehicle from the CS. Otherwise, the vehicle will communicate directly with the RSU (cross-domain). Finally, they can authenticate each other and establish a session key for further encrypting transmitted messages using symmetric encryption. Furthermore, we conducted a systematic analysis and validation of the security of our protocol in the Real-or-Random (ROR) model and Scyther, a security validation tool. The results show that our protocol is secure and resistant to several known attacks. Through a comprehensive comparative analysis of security and performance with other protocols, the results indicate that our protocol has both higher security and performance. The main contributions of this paper are summarized as follows:

1.   We propose a provably secure cross-domain authentication protocol for vehicles in IoV environments, which supports secure communication for both intra-domain and cross-domain.

2.   We design a handover mechanism that allows the RSU (cross-domain) to determine whether to authenticate vehicles directly or request assistance from the CS.

3.   We adopt a two-phase authentication to reduce computation costs by avoiding repeated CS involvement in cross-domain authentication.

The remainder of this paper is structured as follows: Section 2 elaborates on the attacker model and protocol design goals, Section 3 presents our proposed protocol, Section 4 provides the security analysis of the protocol, Section 5 compares the performance of the protocols, and Section 6 provides a summary.

2  System Model, Attacker Model and Design Goals

In this section, we provide a comprehensive description of the system model and the attacker’s capabilities. Moreover, we outline the essential security requirements that must be fulfilled by a cross-domain authentication protocol.

2.1 System Model

The proposed protocol consists of three entities: the vehicle Vi, the roadside unit RSUj, and the cloud server CS. Fig. 2 illustrates the overall architecture of the system model.

Figure 2: System model

1.   Vi: As a semi-trusted device, Vi is equipped with OBU and Intel software guard extensions (SGX) [20–22]. SGX offers a trusted execution environment, preventing attackers from accessing or altering data stored within SGX.

2.   RSUj: As a semi-trusted device, RSUj is similarly equipped with Intel SGX. The RSUj is responsible for collecting real-time traffic information and periodically uploading it to the CS. RSUj is typically deployed on the sides of the road and provides interactions with Vi.

3.   CS: CS is the primary computing and storage resource provider. CS serves as the registration center and responds to the registration for Vi and RSUj. Here, we consider it a trusted entity.

The cross-domain authentication of the vehicle from Domain 1 to Domain 2 is depicted in Fig. 2, and the comprehensive description of each step is provided below.

1.   Initialization Phase: In this phase, CS pre-allocates unique identities and private keys for each Vi and RSUj. Then, Vi and RSUj finish the registration to CS.

2.   Intra-domain Authentication Phase: In this phase, when Vi needs to communicate with RSU1 in Domain 1, they will complete mutual authentication and negotiate a session key (SK1) with the help of CS.

3.   Cross-domain Notification and Data Request Phase: Upon receiving this request, RSU1 generates a Vi’s cross-domain message called M and sends it to CS. Upon receiving M, CS combines M with some private values to generate Vi’s cross-domain message called M′. Subsequently, CS assists in sending M′ to RSU2. Upon receiving M′, RSU2 will utilize it for subsequent authentication of Vi.

4.   Cross-domain Authentication Phase: When Vi moves to Domain 2 and wants to communicate with RSU2, they can authenticate each other and establish SK2 using M′ without the participation of CS.

2.2 Attacker Model

In this paper, the capabilities of the attacker (𝒜) are defined based on the widely recognized Dolev-Yao (DY) [23] model and the Canetti-Krawczyk (CK) [24] model. Specifically, the attacker 𝒜 possesses the following capabilities:

(1)   The attacker 𝒜 can intercept, tamper with, and replay information transmitted over public channels.

(2)   The attacker 𝒜 can extract the data stored in the OBU of the vehicle Vi, but cannot access the data within its SGX.

(3)   The attacker 𝒜 can obtain data stored in the RSUj’s database, but cannot access the data within its SGX.

(4)   The attacker 𝒜 is capable of capturing random numbers generated by any entity.

(5)   The attacker 𝒜 cannot acquire the long-term key of CS.

(6)   The attacker 𝒜 is allowed to obtain any one of (2), (3), or (4) individually, but cannot obtain all of them simultaneously.

2.3 Design Goals

Based on the attacker model described above, our protocol is designed to meet the following security requirements:

(1)   Perfect Forward Secrecy (PFS): Even if an attacker 𝒜 eventually compromises the long-term secret key of an entity, they should not be able to derive any previously established session keys.

(2)   Resistance to Impersonation Attacks: The protocol must prevent an attacker 𝒜 from successfully impersonating a legitimate entity (Vi or RSUj).

(3)   Resistance to Man-in-the-Middle (MITM) Attacks: The protocol should ensure that an attacker 𝒜 who positions themselves between two communicating parties cannot intercept, alter, or forge messages without being detected.

(4)   Resistance to Capture Attacks: Even if 𝒜 compromises and gains access to the internal storage of a legitimate entity (Vi or RSUj), they should be unable to deduce the session key.

(5)   Mutual Authentication: This requirement necessitates mutual authentication between entities. In this process, the entities involved in the communications must present corresponding authentication credentials to ensure the legitimacy and trustworthiness.

(6)   Anonymity: Entities maintain anonymity throughout the AKA process, ensuring that their true identity and other sensitive information remain undisclosed.

(7)   Untraceability: It is impossible to trace or identify the identity or activities of Vi during the AKA process.

3  The Proposed Protocol

This section elaborates on the various phases of the proposed protocol. For ease of understanding, Table 1 lists the symbols used in this paper along with their specific meanings.

3.1 Initialization Phase

Before the registration phase, CS uses a random number generator to generate its master key K and selects a one-way anti-collision hash function denoted h(⋅). Note that K is kept secure by CS. When Vi and RSUj are produced by the factory, Vi will be assigned a private key xi and a long identity IDi, where xi is stored in Vi’s SGX. Similarly, RSUj is assigned a long identity IDRSUj, which is stored in RSUj’s SGX.

3.1.1 Vi Registration Phase

The specific steps for this phase are elaborated in the following.

(1)   Vi first selects a random number ri and calculates PIDi=h(IDi∥ri). Subsequently, Vi transmits {IDi,PIDi} to CS through a secure channel.

(2)   After CS receives {IDi,PIDi}, it selects rcsi and calculates TIDi=h(IDi∥rcsi∥K), Bi1=h(PIDi∥TIDi∥K). Finally, CS stores {TIDi,PIDi} in the database and transmits {TIDi,Bi1} to Vi.

(3)   After Vi receives {TIDi,Bi1}, it calculates Bi2=ri⊕h(IDi∥xi), Bi3=Bi1⊕h(ri∥xi), Bi4=h(IDi∥Bi1∥ri), and Bi5=IDi⊕h(TIDi∥xi). Then, Vi stores {Bi2,Bi3,Bi4,Bi5,TIDi} into OBU.

3.1.2 RSUj Registration Phase

The specific steps for this phase are detailed below.

(1)   RSUj transmits the identity {IDRSUj} to CS via a secure channel.

(2)   After CS receives {IDRSUj}, it selects rcsj and calculates PIDRSUj=h(IDRSUj∥rcsj∥K), KRSUj−CS=h(IDRSUj∥PIDRSUj∥K), CRSUj=IDRSUj⊕h(PIDRSUj∥K). Finally, CS stores {PIDRSUj,CRSUj} in the database and transmits {PIDRSUj,KRSUj−CS} to RSUj.

(3)   After receiving the message, RSUj stores {PIDRSUj,KRSUj−CS} in the database.

3.2 Intra-Domain Authentication Phase

In this phase, Vi and RSU1 achieve authentication and establish the session key SK1 with the help of CS. The specific process is shown in Fig. 3, and the detailed steps are as follows:

Figure 3: Intra-domain authentication phase

(1)   Vi calculates IDi=Bi5⊕h(TIDi∥xi), ri=Bi2⊕h(IDi∥xi), Bi1=Bi3⊕h(IDi∥ri), and checks Bi4=?h(IDi∥Bi1∥ri). If true, Vi login is successful. Then, it selects random number Ri and timestamp T1, and calculates Ri′=Ri⊕h(PIDi∥Bi1), VE1=h(TIDi∥Ri∥T1). Finally, Vi transmits M11={PIDi,Ri′,VE1,T1} to RSU1 via a public channel.

(2)   After receiving M11, RSU1 checks T1. If the time is not exceeded, RSU1 selects random number Rj, timestamp T2 and calculates Rj′=Rj⊕h(IDRSU1∥PIDRSU1), VE2=h(PIDRSU1∥Rj∥KRSU1−CS∥T2). Finally, RSU1 sends M12={PIDi,Ri′,VE1,PIDRSU1,Rj′,VE2,T1,T2} to CS.

(3)   After receiving M12, CS checks T2. If the time is not exceeded, CS finds TIDi in the validation table according to PIDi, and then calculates Bi1=h(PIDi∥TIDi∥K), Ri=Ri′⊕h(PIDi∥Bi1), and checks VE1=?h(TIDi∥Ri∥T1). After successfully verifying Vi, CS finds CRSU1 in the verification table according to PIDRSU1, and then calculates IDRSU1=CRSU1⊕h(PIDRSU1∥K), Rj=Rj′⊕h(IDRSU1∥PIDRSU1), KRSU1−CS=h(IDRSU1∥PIDRSU1∥K), and checks VE2=?h(PIDRSU1∥Rj∥KRSU1−CS∥T2). After successfully verifying RSU1, CS selects T3, calculates Gi=(IDRSU1∥Rj)⊕h(TIDi∥Ri), Gj=(TIDi∥Ri)⊕h(KRSU1−CS∥Rj), VE3=h(KRSU1−CS∥IDRSU1∥T3), and sends M13={Gi,Gj,VE3,T3} to RSU1.

(4)   After receiving M13, RSU1 checks T3 and VE3=?h(KRSU1−CS∥IDRSU1∥T3). After successfully verifying CS, RSU1 can calculate a session key SK1=h(TIDi∥IDRSU1∥Ri∥Rj), where (TIDi∥Ri)=Gj⊕h(KRSU1−CS∥Rj). Then, RSU1 selects T4, calculates VE4=h(TIDi∥IDRSU1∥SK1∥T4), and sends M14={Gi,VE4,T4} to Vi.

(5)   After receiving M14, Vi checks T4. If the time is not exceeded, Vi calculates SK1=h(TIDi∥IDRSU1∥Ri∥Rj), where (PIDRSU1∥Rj)=Gi⊕h(TIDi∥Ri). Finally, Vi verifies VE4=?h(TIDi∥PIDRSU1∥SK1∥T4). If verification is true, Vi sets SK1 as a session key, which is used to encrypt transmitted messages communicating with RSU1.

3.3 Cross-Domain Notification and Data Request Phase

In this phase, vehicle Vi wants to move from the jurisdiction domain RSU1 to that of RSU2. The specific process is shown in Fig. 4, and the detailed steps are as follows:

Figure 4: Notification and data transmission phase

(1)   RSU1 generates a notification Notj and calculates P1=EIDRSU1(PIDRSU2∥PIDi), P2=h(KRSU1−CS∥IDRSU1∥Notj∥T5), where T5 is the current timestamp. Finally, RSU1 sends M21={Notj,PIDRSU1,P1,P2,T5} to CS.

(2)   After receiving M21, CS first checks T5. If the time limit is not exceeded, CS gets CRSU1 according to PIDRSU1 and checks P2=?h(KRSU1−CS∥IDRSU1∥Notj∥T5), where IDRSU1=CRSU1⊕h(PIDRSU1∥K). After successfully verifying RSU1, CS selects T6 and calculates P3=h(KRSU2−CS∥IDRSU2∥Notj∥T6), where KRSU2−CS=h(IDRSU2∥PIDRSU2∥K), IDRSU2=CRSU2⊕h(PIDRSU2∥K), CRSU2 is according to PIDRSU2, and PIDRSU2∥PIDi=DIDRSU1(P1). Finally, CS sends M22={Notj,PIDi,P3,T6} to RSU2.

(3)   After receiving M22, RSU2 first checks T6 and P3=?h(KRSU2−CS∥IDRSU2∥Notj∥T6). If the verifications are valid, RSU2 uses PIDi to retrieve Hi from the database to determine whether Vi has communicated with itself before. If not, RSU2 generates a data request Reqj and rj′=rj⊕h(PIDRSU2∥IDRSU2), P4=h(KRSU2−CS∥IDRSU2∥Reqj∥rj∥T7), where rj is a random number and T7 is the current timestamp. Finally, RSU2 sends M23={Reqj,rj′,P4,T7} to CS.

(4)   After receiving M23, CS first checks T7. If the time limit is not exceeded, CS calculates rj=rj′⊕h(PIDRSU2∥IDRSU2), and checks P4=?h(KRSU2−CS∥IDRSU2∥Reqj∥rj∥T7). After successfully verifying RSU2, CS gets {TIDi} according to {PIDi} and calculates Bi1=h(PIDi∥TIDi∥K), Hi=Eh(IDRSU2∥KRSU2−CS)(TIDi∥Bi1). Finally, CS calculates P5=h(TIDi∥PIDRSU2∥T8) and sends M24={Hi,P5,T8} to RSU2, where T8 is the current timestamp.

(5)   After receiving M24, RSU2 first checks T8 and P5=?h(TIDi∥PIDRSU2∥T8), where TIDi∥Bi1=Dh(IDRSU2∥KRSU2−CS)(Hi). After successfully verifying CS, RSU2 computes Zj=h(IDRSU2∥PIDRSU2)⊕(TIDi∥Bi1) and stores {PIDi,Zj} in its database.

3.4 Cross-Domain Authentication Phase

When Vi moves to Domain 2, mutual authentication and session key computation are required with RSU2.

The specific process is shown in Fig. 5, and the detailed description is as follows:

Figure 5: Cross-domain authentication phase

(1)   Vi selects a random number αi and timestamp T9, calculates αi′=αi⊕h(TIDi∥Bi1), N1=h(PIDi∥αi∥T9). Finally, Vi sends M31={PIDi,αi′,N1,T9} to RSU2.

(2)   After receiving M31, RSU2 first checks T9. If the time limit is not exceeded, RSU2 gets {Zj} from its database according to PIDi and checks N1=?h(TIDi∥αi∥T9), where TIDi∥Bi1=Zj⊕h(IDRSU2∥PIDRSU2), αi=αi′⊕h(PIDi∥Bi1). After successfully verifying Vi, RSU2 selects a random number βj, timestamp T10, calculates Li=(ID2∥βj)⊕h(PIDi∥αi), session key SK2=h(TIDi∥ID2∥αi∥βj), N2=h(TIDi∥βj∥SK2∥T10). Finally, RSU2 sends M32={Li,T1,T10} to Vi.

(3)   After receiving M32, Vi first checks T10. If the time limit is not exceeded, Vi calculates IDRSU2∥βj=Li⊕h(TIDi∥αi), SK2=h(TIDi∥ID2∥αi∥βj), and checks N2=?h(TIDi∥βj∥SK2∥T10). If verification is true, Vi sets SK2 as a session key, which is used to encrypt transmitted messages communicating with RSU2.

4  Security Analysis

4.1 Formal Security Analysis

In this section, we focus on verifying the session key security under the ROR model, a well-established analytical framework referred to [17,25,26], for proving that an authentication protocol achieves the semantic security of the session key. The protocol involves three primary participants: ΠVix (the x-th instance of Vi), ΠRSUjy (the y-th instance of RSUj), and ΠCSz (the z-th instance of CS). The adversary 𝒜 is permitted to perform both passive and active attacks through the execution of a set of standard ROR queries.

(1)   Execute(ℰ): When 𝒜 executes this query, it can intercept messages transmitted between entities ℰ={ΠVix,ΠRSUjy,ΠCSz}.

(2)   Send(ℰ,Mi): This query means that 𝒜 sends a message Mi to ℰ and then receives a reply.

(3)   Hash(string): By entering a string, 𝒜 can obtain its corresponding hash value.

(4)   Corrupt(ΠVix,ΠRSUjy): When this query is executed, 𝒜 can extract the values stored in the vehicle’s OBU or RSU’s database.

(5)   Reveal(ℰ): When this query is executed, 𝒜 can receive session key SK1 or SK2.

(6)   Test(ℰ): The game starts with 𝒜 to guess the flipping coin 𝒞. If 𝒞=1, ℰ returns session keys SK1 and SK2. Otherwise, ℰ returns a random string.

Based on the ROR model, the security of our protocol can be proved by the following theorem.

Theorem 1: Based on the ROR model, the advantage of probabilistic polynomial-time ξ, adversary 𝒜 in breaking our protocol 𝒫 is bounded by: Adv𝒜𝒫(ξ)≤qh2|Hash|+2Adv𝒜Ω(k)+2qs|D|. Here, qs and qh denote the hash and send queries respectively, Adv𝒜Ω(k) denotes the advantage of 𝒜 in cracking symmetric encryption algorithm Ω, |D| and |Hash| indicate the space of dictionary and hash function.

Proof: We define four rounds of games, denoted as GM0-GM3, to simulate 𝒜 in breaking our protocol. Here, the event in which 𝒜 wins in GMi is denoted by Succ𝒜GMi(ξ). In Table 2, we demonstrate that 𝒜 simulates detailed queries.

GM0: It simulates a real attack on the scheme, 𝒜 does not execute any query. Therefore, we can get

Adv𝒜𝒫(ξ)=|2Pr[Succ𝒜GM0(ξ)]−1|.(1)

GM1: During this game, 𝒜 endeavors to perform session key disclosure attacks. 𝒜 executes Execute(ℰ) query to obtain messages M11={PIDi,Ri′,VE1,T1}, M12={PIDi,Ri′,VE1,PIDRSU1,Rj′,VE2,T1,T2}, M13={Gi,Gj,VE3,T3}, M14={Gi,VE4,T4}, M21={Notj,PIDRSU1,P1,P2,T5}, M22={Notj,PIDi, P3,T6}, M23={Reqj,rj′,P4,T7} M31={PIDi,αi′,N1,T9}, and M32={Li,N2,T10}. Then, 𝒜 executes Test(ΠVix,ΠRSUjy) to check whether its output is the real session key. According to our protocol, SK1=h(TIDi∥IDRSU1∥Ri∥Rj) and SK2=h(TIDi∥IDRSU2∥αi∥βj), which has confidential information such as TIDi, IDRSU1, IDRSU2 and random values Ri,Rj,αi,βj. These secret values cannot be obtained from the messages, so the probability of 𝒜 guessing 𝒞 has not increased. Therefore, we can get the same result as GM0.

Pr[Succ𝒜GM1(ξ)]=Pr[Succ𝒜GM0(ξ)].(2)

GM2: In this game, the adversary 𝒜 is additionally granted access to the Send(ℰ) and Hash(ℰ) oracles, thereby enabling active attacks such as message tampering. 𝒜 can run multiple hash queries to check for collisions, it also tries to fool participants into accepting forged messages. However, the authentication values {VE1,VE2,VE3,VE4,P1,P2,P3,P4,P5,N1,N2} are composed of secret credentials and random numbers, and are securely protected by a one-way hash function. At this time, 𝒜 attempts to decrypt the ciphertext Hi=Eh(IDRSU2∥KRSU2−CS)(TIDi∥Bi1), which is generated using a secure symmetric encryption algorithm. Since 𝒜 does not possess the secret values IDRSU2 and KRSU2−CS, the encryption key h(IDRSU2∥KRSU2−CS) cannot be computed. Consequently, the plaintext components TIDi,Bi1 remain inaccessible, and it is computationally infeasible for 𝒜 to infer the session keys SK1 or SK2. Therefore, according to the birthday paradox and the security of the symmetric encryption algorithm, we can get

|Pr[Succ𝒜GM2(ξ)]−Pr[Succ𝒜GM1(ξ)]|≤qh22|Hash|+Adv𝒜Ω(k).(3)

GM3: In this game, 𝒜 attempts to perform OBU capture attacks and RSU capture attacks. 𝒜 issues the Corrupt(ΠVix) query and obtains the stored data from the OBU, which includes {Bi2,Bi3,Bi4,Bi5,TIDi}, where the values are defined as follows Bi2=ri⊕h(IDi∥xi),Bi3=Bi1⊕h(ri∥xi),Bi4=h(IDi∥Bi1∥ri),Bi5=IDi⊕h(TIDi∥xi), and xi is a long-term private key securely stored within the Vi’s SGX. In addition, 𝒜 can also eavesdrop on all messages {Gi,VE4,T4} and {Li,N2,T10} transmitted on the communication channel. If 𝒜 wants to calculate SK1=h(TIDi∥IDRSU1∥Ri∥Rj) or SK2=h(TIDi∥IDRSU2∥αi∥βj), it must first recover Bi1. However, 𝒜 must use ri and xi to get Bi1. Similarly, if 𝒜 issues the Corrupt(ΠRSUjy) query and obtains the stored data form the RSU, which include {PIDRSUj,KRSUj−CS}. However, in order to compute SK1 or SK2, 𝒜 must also know IDRSUj, which is securely stored within the RSU’s SGX and is not revealed to the adversary. Therefore, 𝒜 may attempt to guess xi or IDRSUj from a finite key dictionary of size |D|. As a result, the advantage gained in this game compared to GM2 is bounded by

|Pr[Succ𝒜GM3(ξ)]−Pr[Succ𝒜GM2(ξ)]|≤qs|D|.(4)

Finally, 𝒜 attempts to distinguish the real session key from a random value by issuing the Test(ΠVix,ΠRSUjy) query. Since all sensitive information required to compute the session key is secure or computationally infeasible, 𝒜 has no advantage over random guessing. Therefore, the adversary’s success probability in this game is exactly

Pr[Succ𝒜GM3(ξ)]=12.(5)

Given the results from Eqs. (1) through (5), we obtain an upper bound of the advantage

Adv𝒜𝒫(ξ)2=|Pr[Succ𝒜GM0(ξ)]−12|=|Pr[Succ𝒜GM0(ξ)]−Pr[Succ𝒜GM3(ξ)]|=|Pr[Succ𝒜GM1(ξ)]−Pr[Succ𝒜GM3(ξ)]|≤∑i=12|Pr[Succ𝒜GMi+1(ξ)]−Pr[Succ𝒜GMi(ξ)]|≤qh22|Hash|+Adv𝒜Ω(k)+qs|D|.(6)

Therefore, the overall advantage of adversary 𝒜 in breaking protocol 𝒫 is bounded by

Adv𝒜𝒫(ξ)≤qh2|Hash|+2Adv𝒜Ω(k)+2qs|D|,(7)

where Adv𝒜Ω(k) is negligible in the security parameter k under a secure symmetric encryption algorithm Ω.

□

4.2 Security Verification Using Scyther

In this section, we adopt Scyther to model and analyze the security of the proposed protocol, including intra-domain and cross-domain authentications. Scyther is a security validation tool based on the D-Y model and performs symbolic execution to automatically detect potential attack paths within defined bounds. Here, we define a range of security claims, including the secrecy of session keys and authentication credentials, identity agreement, and aliveness of participating entities.

In Fig. 6a, it shows the results of the intra-domain authentication in which the entities include vehicle V, intra-domain roadside unit RSU1, and cloud server CS. In Fig. 6b, it shows the results of the cross-domain authentication in which the entities include vehicle V and cross-domain roadside unit RSU2. The two results show that all the claims are satisfied and no attacks are detected. Meanwhile, all entities achieve mutual authentication and key establishment. This evidence shows that the proposed protocol is capable of resisting common threats, such as man-in-the-middle, replay, and impersonation attacks, in both intra-domain and cross-domain authentications.

Figure 6: Simulation results of Scyther

4.3 Anonymity and Untraceability

In our protocol, the real identity of Vi, IDi, is ingeniously encapsulated in a pseudo-identity PIDi=h(IDi||ri). Similarly, the real identity of RUSj, IDRSUj, is ingeniously encapsulated in a pseudo-identity PIDRSUj=h(IDRSUj||rcsi||K). Therefore, 𝒜 is not able to identify and track them even if PIDi and PIDRSUj are obtained by 𝒜.

5  Security and Performance Comparisons

In this section, we conducted a comparative analysis of security and performance between the proposed protocol and authentication protocols in IoV [4,10–13,19].

5.1 Security and Functionality Comparisons

The security and functionality comparison is summarized in Table 3. Note that ✗ indicates that the protocol cannot resist a particular type of attack or does not support the specified feature, while ✓ indicates that the protocol provides protection or support accordingly. It can be observed that Li et al.’s protocol [4] is vulnerable to RSU impersonation attacks and does not provide anonymity and untraceability. Lee et al.’s protocol [10] cannot withstand offline password guessing attacks and lacks mutual authentication. Eftekhar et al.’s protocol [11] violates PFS. On the other hand, Xu et al.’s, Yang et al.’s, Chen et al.’s protocols [12,13,19], and our protocol are resistant to common attacks and both achieve cross-domain authentication. In particular, we design a handover mechanism to reduce computation costs by avoiding the repeated involvement of the cloud server in cross-domain authentication.

5.2 The Comparison of Computational Costs

We are mainly concerned with comparing the computational costs that different protocols used in the authentication phase. Specifically, we conduct experiments to simulate the computational time required by each entity in the protocols in which the XiaoMi 8 smartphone is used to simulate Vi, the Lenovo laptop is used to simulate RSU(FN), and the Lenovo desktop computer is used to simulate CS(TA). The configurations of these devices are detailed in Table 4. Throughout the experiments, each device was executed 80 times, and the average running time was considered the final execution time. Finally, the execution times of each device are presented in Table 5.

Table 6 illustrates the comparison of computational cost results. Yang et al.’s protocol [13] has the highest computational cost across all protocols, due to the use of point scalar multiplication operations in ECC within blockchain-based pseudonym handling and verification processes. Similarly, Eftekhari et al.’s protocol [11] also demonstrates high costs, especially for Vi and RSUj, due to its use of three times point scalar multiplication operations. In contrast, Xu et al.’s protocol [12] also involves multiple operations in ECC. Its total cost remains lower than that of Eftekhari et al.’s and Yang et al.’s protocol. For the other protocols [4,10,19], the computational costs are relatively low, primarily based on hash functions and lightweight cryptographic operations. Among them, Chen et al.’s protocol [19] uses symmetric encryption/decryption operation in RSU, resulting in a higher cost than Li et al.’s protocol [4].

In the cross-domain authentication phase of our protocol, it achieves the lowest computational cost in Vi and RSUj with only hash operations. For CS(TA), our protocol requires only a small number of hash operations, resulting in the lowest central computational cost among all protocols. Overall, these results confirm that our protocol achieves lower computational costs, particularly in cross-domain authentication.

5.3 The Comparison of Communicational Costs

We defined the following length of parameters used to evaluate communication costs: identity |ID|, ciphertext of symmetric encryption |E|, random number |R|, timestamp |T|, hash function |H|, and point |P| as 160, 256, 160, 32, 256, and 320 bits, respectively.

As our protocol consists of two authentication phases, we divided the communication cost into two cases. In case 1 (Inter-domain authentication + notification and data transmission), the transmitted messages comprise {M11,M12,M13,M14,M21,M22,M23,M24}. The total communication cost is 8|H|+14|R|+8|R|+2|E|=5056 bits. In case 2 (cross-domain authentication), the transmitted messages comprise {M31,M32}. The total communication cost is 3|R|+2|H|+|T|=1024 bits. Using the same methodology, the communication costs of these protocols [4,10–13,19] are calculated as 4000, 2208, 4992, 3616, 5728, and 5216 bits, respectively.

Table 7 illustrates the comparative results. It can be observed that Yang et al.’s protocol [13] incurs the highest communication cost due to its blockchain-based pseudonym exchange among all protocols. In our protocol, Case 1 involves 8 rounds of communications. However, this case occurs only once for the same Vi and RSU. All subsequent cross-domain authentication is executed in Case 2, which achieves only 1024 bits of communicational cost within 2 rounds. It is noteworthy that Case 2 (cross-domain authentication) significantly reduces communication overhead, outperforming all compared protocols.

It is noteworthy that Case 2 significantly reduces communication overhead, outperforming all compared protocols under similar conditions. Through the joint analysis of computational and communicational costs, we claim that our proposed protocol achieves higher performance while maintaining higher security, particularly in cross-domain authentication.

6  Conclusion

In this paper, we have proposed a provably secure cross-domain AKA protocol tailored for the Internet of Vehicles (IoV). This protocol empowers the RSU to evaluate the communication status between itself and the vehicle, thereby enabling rapid cross-domain authentication for the vehicle. Additionally, we conducted a formal security analysis of the proposed protocol using the ROR model and Scyther. Finally, we performed a comparative analysis of the proposed protocol against existing protocols in terms of security and performance, with results demonstrating that our protocol excels in both security and performance.

Acknowledgement: Not applicable.

Funding Statement: This work was supported by the Startup Foundation for Introducing Talent of Nanjing University of Information Science and Technology and Natural Science Foundation of Shandong Province, China (Grant no. ZR202111230202).

Author Contributions: The authors confirm contribution to the paper as follows: Conceptualization, Tsu-Yang Wu and Haozhi Wu; methodology, Tsu-Yang Wu and Haozhi Wu; validation, Maoxin Tang; formal analysis, Haozhi Wu and Maoxin Tang; investigation, Saru Kumari and Chien-Ming Chen; data curation, Saru Kumari and Chien-Ming Chen; writing—original draft preparation, Tsu-Yang Wu, Haozhi Wu, Maoxin Tang, Saru Kumari and Chien-Ming Chen; writing—review and editing, Tsu-Yang Wu, Maoxin Tang, Saru Kumari and Chien-Ming Chen. All authors reviewed the results and approved the final version of the manuscript.

Availability of Data and Materials: The data are contained within the article.

Ethics Approval: Not applicable.

Conflicts of Interest: The authors declare no conflicts of interest to report regarding the present study.

References

1. Dey KC, Rayamajhi A, Chowdhury M, Bhavsar P, Martin J. Vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communication in a heterogeneous wireless network-Performance evaluation. Transport Res Part C: Emerg Technol. 2016;68(6):168–84. doi:10.1016/j.trc.2016.03.008. [Google Scholar] [CrossRef]

2. Yu S, Lee J, Park K, Das AK, Park Y. IoV-SMAP: secure and efficient message authentication protocol for IoV in smart city environment. IEEE Access. 2020;8:167875–86. doi:10.1109/access.2020.3022778. [Google Scholar] [CrossRef]

3. Mejri MN, Ben-Othman J, Hamdi M. Survey on VANET security challenges and possible cryptographic solutions. Vehic Communicat. 2014;1(2):53–66. doi:10.1016/j.vehcom.2014.05.001. [Google Scholar] [CrossRef]

4. Li X, Liu T, Obaidat MS, Wu F, Vijayakumar P, Kumar N. A lightweight privacy-preserving authentication protocol for VANETs. IEEE Systems J. 2020;14(3):3547–57. doi:10.1109/jsyst.2020.2991168. [Google Scholar] [CrossRef]

5. Gupta D, Rathi R. RDVFF-reliable data dissemination in vehicular ad hoc networks based on validation of far to farthest zone. J Internet Technol. 2024;25(1):87–104. [Google Scholar]

6. Sutrala AK, Bagga P, Das AK, Kumar N, Rodrigues JJ, Lorenz P. On the design of conditional privacy preserving batch verification-based authentication scheme for internet of vehicles deployment. IEEE Transacti Vehic Technol. 2020;69(5):5535–48. doi:10.1109/tvt.2020.2981934. [Google Scholar] [CrossRef]

7. Lv S, Liu Y. PLVA: privacy-preserving and lightweight V2I authentication protocol. IEEE Transact Intell Transport Syst. 2021;23(7):6633–9. doi:10.1109/tits.2021.3059638. [Google Scholar] [CrossRef]

8. Wang H, Zhang F, Shen Z, Liu P, Liu K. Blockchain-based IVPPA scheme for pseudonym privacy protection in internet of vehicles. J Network Intell. 2024;9(2):1260–77. [Google Scholar]

9. Liu Y, Wang Y, Chang G. Efficient privacy-preserving dual authentication and key agreement scheme for secure V2V communications in an IoV paradigm. IEEE Transact Intell Transport Syst. 2017;18(10):2740–9. doi:10.1109/tits.2017.2657649. [Google Scholar] [CrossRef]

10. Lee J, Kim G, Das AK, Park Y. Secure and efficient honey list-based authentication protocol for vehicular ad hoc networks. IEEE Transact Netw Sci Eng. 2021;8(3):2412–25. doi:10.1109/tnse.2021.3093435. [Google Scholar] [CrossRef]

11. Eftekhari SA, Nikooghadam M, Rafighi M. Security-enhanced three-party pairwise secret key agreement protocol for fog-based vehicular ad-hoc communications. Veh Commun. 2021;28(1):100306. doi:10.1016/j.vehcom.2020.100306. [Google Scholar] [CrossRef]

12. Xu C, Huang X, Ma M, Bao H. A privacy-preserving and cross-domain group authentication scheme for vehicular in LTE-A networks. J Communicat. 2017;12(11):604–10. doi:10.12720/jcm.12.11.604-610. [Google Scholar] [CrossRef]

13. Yang Y, Wei L, Wu J, Long C, Li B. A blockchain-based multidomain authentication scheme for conditional privacy preserving in vehicular ad-hoc network. IEEE Int Things J. 2021;9(11):8078–90. doi:10.1109/jiot.2021.3107443. [Google Scholar] [CrossRef]

14. Yu F, Ma M, Li X. A blockchain-assisted seamless handover authentication for V2I communication in 5G wireless networks. In: ICC 2021-IEEE International Conference on Communications. Montreal, QC, Canada: IEEE; 2021. p. 1–6. [Google Scholar]

15. Jiang Q, Zhang X, Zhang N, Tian Y, Ma X, Ma J. Three-factor authentication protocol using physical unclonable function for IoV. Comput Communicat. 2021;173(5):45–55. doi:10.1016/j.comcom.2021.03.022. [Google Scholar] [CrossRef]

16. Babu PR, Reddy AG, Palaniswamy B, Das AK. EV-PUF: lightweight security protocol for dynamic charging system of electric vehicles using physical unclonable functions. IEEE Transact Netw Sci Eng. 2022;9(5):3791–807. doi:10.1109/tnse.2022.3186949. [Google Scholar] [CrossRef]

17. Wu TY, Wu H, Kumari S, Chen CM. An enhanced three-factor based authentication and key agreement protocol using PUF in IoMT. Peer Peer Netw Appl. 2025;18(2):83. doi:10.1007/s12083-024-01839-z. [Google Scholar] [CrossRef]

18. Yan X, Ma M, Su R. A certificateless efficient and secure group handover authentication protocol in 5G enabled vehicular networks. In: ICC 2022-IEEE International Conference on Communications. Seoul, Republic of Korea: IEEE; 2022. p. 1678–84. doi:10.1109/ICC42927.2021.9500334. [Google Scholar] [CrossRef]

19. Chen CM, Li Z, Kumari S, Srivastava G, Lakshmanna K, Gadekallu TR. A provably secure key transfer protocol for the fog-enabled Social Internet of Vehicles based on a confidential computing environment. Veh Commun. 2023;39(1):100567. doi:10.1016/j.vehcom.2022.100567. [Google Scholar] [CrossRef]

20. Costan V, Devadas S. Intel SGX Explained, Cryptology ePrint Archive, Report 2016/086. 2016. [Google Scholar]

21. Liu X, Guo Z, Ma J, Song Y. A secure authentication scheme for wireless sensor networks based on DAC and Intel SGX. IEEE Int Things J. 2021;9(5):3533–47. doi:10.1109/jiot.2021.3097996. [Google Scholar] [CrossRef]

22. Will NC, Maziero CA. Intel software guard extensions applications: a survey. ACM Comput Surv. 2023;55(14s):322. doi:10.1145/3593021. [Google Scholar] [CrossRef]

23. Dolev D, Yao A. On the security of public key protocols. IEEE Transact Inform Theory. 1983;29(2):198–208. doi:10.1109/tit.1983.1056650. [Google Scholar] [CrossRef]

24. Canetti R, Krawczyk H. Analysis of key-exchange protocols and their use for building secure channels. In: International Conference on the Theory and Applications of Cryptographic Techniques. Berlin/Heidelberg, Germany: Springer; 2001. p. 453–74. doi:10.1007/3-540-44987-6_28. [Google Scholar] [CrossRef]

25. Gao Y, Zhou T, Zheng W, Yang H, Zhang T. High-availability authentication and key agreement for internet of things-based devices in Industry 5.0. IEEE Transact Indust Inform. 2024;20(12):13571–9. doi:10.1109/tii.2024.3414443. [Google Scholar] [CrossRef]

26. Alrashdi I, Tanveer M, Aldossari SA, Alshammeri M, Armghan A. BSCP-SG: blockchain-enabled secure communication protocols for IoT-driven smart grid systems. Int Things. 2025;32(2):101626. doi:10.1016/j.iot.2025.101626. [Google Scholar] [CrossRef]