A lightweight and secure online/offline cross-domain authentication scheme for VANET systems in Industrial IoT

In heterogeneous wireless networks, the industrial Internet of Things (IIoT) is an essential contributor to increasing productivity and effectiveness. However, in various domains, such as industrial wireless scenarios, small cell domains, and vehicular ad hoc networks, an efficient and stable authentication algorithm is required (VANET). Specifically, IoT vehicles deal with vast amounts of data transmitted between VANET entities in different domains in such a large-scale environment. Also, crossing from one territory to another may have the connectivity services down for a while, leading to service interruption because it is pervasive in remote areas and places with multipath obstructions. Hence, it is vulnerable to specific attacks (e.g., replay attacks, modification attacks, man-in-the-middle attacks, and insider attacks), making the system inefficient. Also, high processing data increases the computation and communication cost, leading to an increased workload in the system. Thus, to solve the above issues, we propose an online/offline lightweight authentication scheme for the VANET cross-domain system in IIoT to improve the security and efficiency of the VANET. The proposed scheme utilizes an efficient AES-RSA algorithm to achieve integrity and confidentiality of the message. The offline joining is added to avoid remote network intrusions and the risk of network service interruptions. The proposed work includes two different significant goals to achieve first, then secure message on which the data is transmitted and efficiency in a cryptographic manner. The Burrows Abdi Needham (BAN logic) logic is used to prove that this scheme is mutually authenticated. The system’s security has been tested using the well-known AVISPA tool to evaluate and verify its security formally. The results show that the proposed scheme outperforms the ID-CPPA, AAAS, and HCDA schemes by 53%, 55%, and 47% respectively in terms of computation cost, and 65%, 83%, and 40% respectively in terms of communication cost.


INTRODUCTION
The Industrial Internet of Things (IIoT), also known as the industrial Internet, put forward the IoT advances in development (Shaikh, Zeadally & Exposito, 2015;Khalid et al., 2020a). IIoT integrates a wide range of existing industrial automation systems with the latest electronics, computing, machine learning, and communication technologies. IIoT claims that in gathering and communicating data, intelligent machines are more capable than humans (Khalid et al., 2021a). This data makes business intelligence activities simpler for the manufacturing and business communities (Sey, 2018). An extensive network of vehicles and roadside units communicating with each other to share information is the ad hoc vehicle network, an IIoT application (Latif et al., 2018;Al-Heety et al., 2020). VANET is a particular case of wireless multihop network, which has the constraint of fast topology changes due to the high node mobility. With the increasing number of vehicles equipped with computing technologies and wireless communication devices, inter-vehicle communication is becoming a promising field of research, standardization, and development. VANETs enable a wide range of applications, such as prevention of collisions, safety, blind crossing, dynamic route scheduling, real-time traffic condition monitoring, etc. Another important application for VANETs is providing Internet connectivity to vehicular nodes (Badis & Rachedi, 2015). These are networks for naturally created needs from connected vehicles-VANETs aim to provide comfort for travelers and improve road safety and congestion. VANETs, information about vehicle-to-vehicle (V2V), and vehicle-to-infrastructure (V2I) communication between the highway and urban scenarios are shared wirelessly. The growing number of vehicles on the road causes many major traffic problems every day, including traffic delays and pileups of cars (Kaiwartya et al., 2016;Khalid et al., 2017). The industrial IoT is an emerging implementation of IoT technologies in several contexts, such as automation, intelligence controls, smart cities, smart transportation, and smart grids (Rehman et al., 2021). It would be hard to incorporate industrial IoT solutions without the construction of an infrastructural network. It is important to understand unique IoT concepts when applying these methods to wireless IoT networks. One of the significant features of IoT networks is the collaboration between heterogeneous IoT devices. The Internet of Things (IoT) application areas have significantly increased as digital electronics and wireless networking evolve rapidly (Goudarzi et al., 2019). A broad range of technologies is currently funded, including industrial automation, smart transport, medical and e-health services (Javed et al., 2020). Low-weight, efficient communication between sensing devices and interoperability between various communication mechanisms is the IoT's critical issue (Khalid et al., 2020b). The industrial IoT data created from billions of device-person interactions will be massive and complex and will suffer from many security and privacy issues, particularly concerning device authentication. Computer security researchers have developed many authentication protocols, implemented in the industrial IoT context, to overcome these security concerns (Ferrag et al., 2017). Vehicle ad-hoc networks (VANETs), an essential part of an intelligent transport system, will use less wired communications technologies to provide continuing and reliable network communications services (Manvi & Tangade, 2017). As illustrated in Fig. 1, VANETs are made of three essential entities: trust authority (TA), roadside units (RSU), and on-board vehicles (OBUs) (Sheikh & Liang, 2019).
OBU: Each vehicle must be linked to the TA with the private key and the public device's necessary parameters. Secret information, such as private keys, is inserted into each vehicle's tamper-proof device to allow only authorized parties to access the tamperproof device. Individual safe values, such as true vehicle identity and a secret vehicle key, are pre-loaded by the device. The vehicles' computation mechanism is also included in this system, and the hidden values are never revealed. OBUs routinely disseminate such data while traveling on roads, such as distance, current time, direction, speed, traffic conditions, and traffic events useful for other vehicles and RSUs. The 5.9 GHz Dedicated Short-Range Communication (DSRC) IEEE 802.11p is the communication protocol for neighboring OBUs. TA: TA has registered OBUs and RSUs. It initializes them with the public system's data or private keys. TA has a general computing and storage capacity and is the only party who can reveal the signers' identity. The solution to TA is impossible, and both parties to the scheme fully trust it. RSU: RSU is a stationary component system with DSRC wireless access point, stable memory storage, and computational capabilities. The time between requesting and receiving RSU responses is crucial for successfully disseminating data by VANETs, given the restricted transmission range of RSUs and vehicles' movement. RSUs are known as fully trusted parties in the scheme.
However, VANET architecture dealing with a hundred vehicle devices for accessing and management, this large amount of data and information seems to be a large-scale environment. However, these systems are limited resource devices in computation, storage, and energy. Traditionally, most authentication schemes rely on Roadside units (RSUs) that mainly hold the data's computing and processing. According to the large-scale architecture, the devices will deal with a large amount of data transmitted and processed. In a short time interval, several vehicles can continuously cross-practical areas of several RSUs. Also, at any time beyond prediction, the random vehicle can enter or leave the VANET network. The vehicles are also dynamically moved through different domains. This movement comes out with a critical problem across domain access. Because of the significant number of participating vehicles, the individual RSUs would have enormous time consumption and computation costs, which are crucial for limiting the comprehensive implementation of VANETs. Each vehicle and the RSU passed should be authenticated in time for each vehicle before exchanging vehicle data. Thus, this issue causes a significant delay and high computation costs, and it also increases the number of the interacted messages through a public network. Therefore, the VANET system will take a lengthy verification process before granting access (Picone et al., 2015). Likewise, transmitted data between the RSUs, OBUs, and the trusted party are sensitive. The adversaries are mainly targeting this information to delete, manipulate, eavesdrop on this data. Current authentication schemes are vulnerable to specific attacks (e.g., replay attacks, modification attacks, man-in-the-middle attacks, and insider attacks), and these attacks make the VANET system week (Deepa et al., 2021). For example, a MiTM attack occurs in the middle of V2V communication to check closely and alter the messages. The attacker can access and control the entire V2V communication, but the communication entities think they can communicate directly in private. Also, this way, each vehicle's temporary identity changes over time, and a malicious attacker can hardly trace a specific vehicle. This is because after altering the certificate, an attacker would not link the new certificate with the old certificate, which means that the attacker has lost the target. However, this method still has some problems, such as high revocation costs. For example, when a vehicle is revoked, the number of pseudonymous certificates that need to be added to the Certificate Revocation List (CRL) could be too large. The size of CRL increases rapidly when the size of the network increases. These attacks could enable adversaries to enter the VANET system user's registered ID, password and broadcasting a false message, or repeat/delay the transmission fraudulently (Khalid et al., 2021b). Also, preserving data confidentiality, privacy, and integrity in the trusted information context, where the information is shared between many parties, is becoming one of the most challenging issues for such a community. Therefore, a lightweight cross-domain authentication scheme for the VANET system is critically needed to satisfy the VANET's security requirements.
Motivated by the above discussion on VANET secure transmission, we proposed an online/offline lightweight authentication scheme for VANET in industrial IoT. The offline joining and handover phase was added to avoid service interruption if the connectivity is down, allowing vehicles to send authentication requests. At the same time, they are temporarily disconnected from the Internet (Deepa et al., 2020). In offline authentication, TA is not involved in the joining procedure since the information is preloaded prior. The combination comprises the Advanced Encryption Algorithm (AES) and the Database Encryption RSA algorithm for the integrity, authentication, and distribution of the key. The algorithms have less encryption and decryption time in processing such extensive data. This mechanism also provides dual protection by taking advantage of the algorithms used, so the data transmission in the network will be more secure. The main advantage of this combination is that the AES-RSA encryption algorithm utilized the features of already existing algorithms which are very secure and difficult to break since it requires two different keys and algorithms. The strength of the security is improved by combining symmetric and asymmetric encryption methods where retrieval of the key is very difficult. The scheme ensures resistance against specific attacks, e.g., such as reply, modification, impersonation, and man-in-the-middle attacks. Also, it provides message integrity, authentication, and identity privacy preserving against change.
The study lists the findings as follows: in "VANETs security requirements,'' we identify the security requirements of the VANET system; in "Related Work,'' we review the previous studies and categorize their limitations; in "Preliminaries,'' we give a brief introduction on RSA, and AES-RSA algorithms; in "proposed Scheme'' presents the main finding of the study; in "Security analysis'' verify the security aspects using BAN logic, and AVISPA tool; in "performance evaluation'' we evaluate the performance of the proposed scheme; in "Conclusion'' the study is finalized, and a brief conclusion is given.

VANETS SECURITY REQUIREMENTS
Vehicles in VANETs may detect nearby traffic details or an event to notify neighboring vehicles or the central traffic center. The authentication of messages can reduce these threats because of users' wrong behaviors, such as false information transmissions, re-transmission of previous messages, and changes in the messages sent. Since users' data should be kept secret, including driver names, speeds, positions, and relationships with other users, authentication should be performed anonymously (Khan et al., 2021). There is a contradiction between anonymity and dedication. As a result of anonymous authentication, unauthorized users should not utilize the network against external attackers (Hemalatha, 2021). If approved users do something wrong, anonymous authentication will not track them. For TA to determine the sender's real identity, anonymous authentication should therefore be performed. We thus need the preservation of authentication protocols on conditional privacy. The security criteria for the VANETs are as follows: 1. Message integrity and authentication: VANETs must be sure to create and send the received message through an approved OBU and that nobody modifies the received message. Moreover, the authentication scheme should be immune to impersonation, and no signature vehicle could be impersonated (Kumar & Singh, 2021).

2.
Identity privacy-preserving: The security of identity information underlines that by monitoring communications in VANETs, an intruder cannot identify either the initiators of the message or the party, including its originators. As vehicle names and locations are private and privacy disclosure is immoral, this is a critical property for VANETs.

RELATED WORKS
In recent years, security authentication and privacy protection have been a significant research orientation in VANETs. Several anonymous authentication schemes were suggested for VANETs. Azees, Vijayakumar & Deboarh (2017) proposed in 2017 an effective anonymous authentication scheme (EAAP) for VANETs. No storage of anonymous vehicle certificates and RSUs based on bilinear pairing is required by the trusted authority (TA) in the EAAP. In the case of a dispute, the trust authority will revoke and expose its real identity to a misbehaving vehicle's privacy. The revoked identity is then put on the TA's retained identity revocation list (IRL). Furthermore, without incentives, the enthusiasm problem still suffers when sending messages. Verma et al.
(2021) presents a short digital signature scheme without pairing in a certificate-based setting with aggregation in an IIoT environment. In the SCBS scheme, each signer/user generates his/her (public and secret) keys and gets a certificate on (ID, public access) pair from CA. Certificates are sent via a public channel. During the execution of the signing phase, the signer requires his/her updated certificate along with a secret key. Similarly, Moni & Manivannan (2021) proposed a distributed and scalable privacy-preserving authentication and message dissemination scheme. Traditionally Certificates and CRLs were used for authenticating entities. However, as the number of entities grows, using CRLs for authentication incurs significant computation and communication overhead. In this scheme, a vehicle only needs to store the public key of the TA and the latest MHT root generation timestamp to authenticate RSUs. Similarly, MMPT is used by RSUs to authenticate vehicles, thus reducing the complexity involved in authenticating vehicles. Xie et al. (2017) subsequently introduced a new, efficient authentication process, using identity to relatively protect VANET applicants' privacy. The ECC is used to solve the problem of the bilinear pairing because of its complex operations. The proposed system is an improved CPA solution based on (He et al., 2015) that is more effective than the former and fulfills VANET security requirements. The proposed scheme offers a simple message verification and batch message verification, where several messages can simultaneously be verified, and authentication costs are significantly reduced. However, a TA can track this vehicle when a vehicle broadcasts false information without preventing it from transmitting these messages. Furthermore, the identity of each vehicle can be easily discovered by an insider attacker since this attacker has private and public key pairs and has high computational and communication costs.
In Vijayakumar et al. (2018), a signature-based anonymity technique was suggested for vehicular ad hoc networks using bilinear pairing. However, this method eventually introduces enormous computational complexity and overhead, which are unfeasible for the RFID Tag resource restriction. A conditional monitoring mechanism is developed through which the TA tracks the wrong vehicles or RSUs in the IoT environment that misuse the VANET. The TA will, therefore, revoke the privacy of misbehaved vehicles for additional damage. Efficient authentication of the anonymous batch message (ABM) also suggested testing the authenticity of an RSU while sending a batch of messages via RSU to vehicles. However, because of the high overhead of communication, the high computational cost of the Certificate Revocation List (CRL) testing method makes it difficult to validate a large number of VANET messages over a specific period (Lu, Qu & Liu, 2018). Similarly, Pournaghi et al. (2018), proposed the NECPPA scheme, incorporating schemes based on RSU and TPD. The key concept for this system is that the master and public parameter is stored on the RSU TPD. This is because the connection between TA and RSU is secure and fast for communication. The RSU, therefore, generates the sub-master key inside the coverage area to be sent to all vehicles (Zmezm et al., 2015). The execution time during message generation and verification, however, is high (Al-Shareeda et al., 2020). Li et al. (2018) a conditional anonymous authentication of the VSNs' privacy was proposed, while the authors suggested the VSNs' design goals. Their scheme is robust and adopts pseudo-identity generation and private key extraction to maintain anonymity. To keep the privacy of its identity, every OBU should restore several pseudo-identities in this scheme. This scheme promotes the security and privacy needed for services rendered by VANET. However, the machine's private key is pre-loaded into the car's tamper-proof computer, which attackers can eliminate (e.g., through side-channel attacks). Hence, when the attackers have physical access to the tamper-proof device, their solution is not secure.
Likewise, an available certificates conditional privacy-preserving authentication scheme for vehicular ad-hoc networks was proposed by Ming & Shen (2018). Certificateless cryptography and elliptical curve cryptography form the basis of the proposed scheme (ECC). As an adversary would not connect a vehicle to its transmitted message, the system encourages conditional privacy and ensures unlinkability. In this work, however, the Benarous et al. (2020); anonymous tickets and challenge-based authentication are the foundation of their scheme. The scheme's effectiveness against the most popular security parameters is tested using several methods and techniques that have proven its efficiency and robustness, such as the BAN logic, SPAN, and AVISPA instruments. Recently, Alfadhli et al. (2020b) proposed a novel and successful CPPA-VANET solution based on lightweight pseudo-identity to overcome the crucial driving area and key escrow problems and provide better efficiency in terms of computation cost and overhead communications. Regrettably, the device also has a high computational cost in the authentication process and is prone to replay attacks. Similarly, Cheng & Liu (2020) an improved ECC authentication scheme based on RSU was proposed, in which RSU distributes vehicle pseudonyms when the vehicle pseudonyms are invalid. However, the password is estimated to have a low entropy secret value and vulnerable to password guessing attacks due to the built-in issues related to the password.
In Thumbur et al. (2020), to avoid the complicated public fundamental infrastructure certificate management problem and the Identity-based key escrow problem, a new VANET certificateless aggregate signature-based authentication scheme was proposed. All signatures/messages received from the surrounding vehicles are aggregated into a single signature by the RSU. AS/RSU can ensure that the related messages are signed by only the registered vehicles. The lack of an effective signature authentication process, however, increases the overhead of computing. Jiang, Ge & Shen (2020) and Jiang, Hua & Wahab (2020) also proposed a Self-checking Authentication Scheme with Higher Efficiency and Security for VANET, called SAES; the proposed scheme adopts pseudonym-based self-checking authentication. Unfortunately, the system also suffers from primary session attacks, modification attacks, and high processing costs due to the bilinear pairing. Similarly, for VANETs that protect privacy, a lightweight multi-factor authentication and security solution was introduced (Alfadhli et al., 2020a). It operates as authentication variables, a mixture of physically unclonable (PUF) functions and one-time dynamic pseudo-identities. The proposed scheme removes the need for a TPD to store sensitive long-term data (such as a fingerprint, password), enhancing the system's effectiveness and security. Nevertheless, by analyzing the content of such captured messages in VANETs, an intruder can acquire the original identity and track its traveling routes. From the above analysis, we found out that most of the existing schemes suffer from high computation and communication costs because the architecture of VANET contains a considerable quantity of vehicles. Likewise, transmitted data between the RSUs, OBUs, and the trusted party are sensitive. The adversaries are primarily targeting this information to delete, manipulate, eavesdrop on this data. Some attacks (e.g., replay attacks, modification attacks, man-in-the-middle attacks, and insider attacks) are vulnerable to current authentication systems, and these attacks make the VANET system week. Such attacks will probably allow adversaries to access the registered ID of the VANET device user and password and broadcast a false message or fraudulently repeat/ delay the transmission. Though some research attention has been paid to date, the critical issue of cross-domain authentication has not been appropriately addressed in the VANET market. As a matter of fact, under the static trust model, most of the existing VANET authentication mechanisms tend to build up the verification process, where only the initial RSU opportunity is discussed. The CDA ability, in other words, was not considered at all. Both successive RSUs must request sensitive information from the cloud server for the remaining systems where the CDA issue has already been solved, causing unnecessary contact burdens and high latency. The comparison of the existing studies is shown in Table 1.

PRELIMINARIES
In this section, the mathematical concept of RSA and the AES-RSA algorithm steps proposed are discussed. First, the basic definition and properties of the RSA algorithm are highlighted to explain RSA encryption and decryption. The combined AES-RSA algorithm is also described to understand the workflow on the sender and receivers' sides. Figure 2 shows the workflow diagram of the AES-RSA algorithm.

RSA cryptosystem
Here, the basic description of the RSA cryptosystem and its properties are discussed. Two appropriate primes p, q and n = p Ã q are selected by Server TA as well as (n) = (p − 1) Ã (q − 1). TA is now choosing an integer e such that gcd(e, (n)) = 1. Further, TA computes de − 1 mod(n). Finally, the public key for TA is (e, n), and d is the private key. The algorithm's description is given as: Encryption: OBUs take the message m and the public key e from TA in RSA encryption and encrypt the message as c = m e and send the output c to TA. Decryption: TA takes cipher c and its private key d on the RSA decryption server and decrypts cipher c as m = c d and gets the message.

AES-RSA encryption/decryption
The AES-RSA algorithms' steps on both sides, sender, and receiver are shown in this section. The steps are shown as follows: Encryption: 1. User data, i.e., identity and information, are given input to the AES and SHA-2 algorithms.
2. SHA-2 is hashing algorithm used to generate the hash value of the given plaintext.
3. The RSA is used to encrypt the hash value using the public key and produce the digital signature.
4. The plaintext is also encrypted with an AES using the AES's public key.
5. Then, the RSA public key is used to encrypt the text encrypted with an AES.
6. The digital signature is now padded with an AES encrypted text and sent through the cross-domain Internet to the receiver side. Decryption: 1. The receiver now receives the message it decrypts the digital signature using the sender's public key to retrieve the encrypted text and the hash value.
2. The retrieved encrypted text is decrypted using it is the public key to obtain the plaintext.
3. Then, the hashed value is decrypted into a message digest using the RSA's private key.
4. The decrypted text from the AES is passed to SHA-2, and the hash value is generated for the input plaintext.
5. The generated hash value is then compared to the one generated from the RSA and SHA-2 to check the message's validity.
6. If both are matched, then the integrity of the message is achieved.

PROPOSED SCHEME
The lightweight authentication scheme for the VANET cross-domain system in industrial IoT is proposed in this section. The system includes entities such as the Trusted Authority (TA), the Domain Trusted Authority (DTA), road-side units (RSUs), and vehicles (Vi). The proposed scheme comprises eight phases: the setup phase, the vehicle registration phase, the domain TA registration phase, the RSU registration phase, the online joining phase, the online crossover phase, the offline joining phase, and the offline crossover  Table 2. The phases of the scheme proposed are described in detail below.

Setup phase
To initialize the system, the trusted authority TA selects two large primes p, q and computes n = p, q. The trusted authority TA keeps p, q as secret parameters and publishes n as a public parameter. Then, the trusted authority TA chooses a prime e (where 1 < e < (p − 1)(q − 1)) and computes d such that ed1 mod (p − 1)(q − 1). The trusted authority TA also chooses a one-way hash function h(): 0, 1 Ã → Z Ã q . The trusted authority TA publishes e as public and keeps d as secret. Also, the TA choose an encryption/ decryption pair Enc{.}, Dec{.} related to AES-RSA algorithm. The exchanged messages are encrypted using AES public key for secure transmission. The RSA public key is also used to encrypt the generated signature to provide integrity, confidentiality, and authenticity.

Vehicle registration phase
In this phase, the vehicle must be registered at the trusted authority TA to authenticate to the distributed domains. The vehicle initializes the session by sending the identity and other security parameters to the TA via a secure channel. The transmitted message is protected where the information is double encrypted using the AES-RSA algorithm. When the TA receives the message, it checks the existence of the information in the database; if the vehicle is registered, the server will send a notification; otherwise, the vehicle performs the following steps as shown in Fig. 4.
1. Firstly, the Vehicle V i randomly picks a secret key s 2 Z Ã q ; secret value R i , and computes A i = a.p. Then, it computes T i = H(VID i ∥ s), and encrypt the hash value with RSA's public key Enc TA pk rsa fT i g. The vehicle parameters and it is identity are concatenated and encrypted with AES's public key CT V!TA ¼ Enc TA pk aes fA i ; R i ; Enc TA e rsa fT i gg: The vehicle sends the CT V ! TA to the TA.
2. The trusted authority TA receives the message CT V ! TA from the vehicle, it will decrypt the CT V ! TA using it is public-key Dec TA pk aes fA i ; R i ; Enc TA pk rsa fT i gg to obtain the encrypted identity and the parameters , A i ; R i ; Enc TA e rsa fT i g . . 3. Then, it uses the RSA private key Dec TA d rsa fT i g to obtain the vehicle identity VID i . TA will select a few random values r j v 2 Z Ã q to calculate vehicles pseudonyms where t e xp is the expiration of r j v ; 1 < j < n; n is the total number of each vehicle obtaining pseudonym. Later, TA calculates the session key with the vehicle K TA→v = d.A i and encrypts , r

Domain TA registration phase
This phase enables the domain trusted authority DTA to register itself into the trusted authority TA. The DTA sends a registration request containing the hashed value of the domain along with a freshly generated random number. Figure 5 shows the steps of the current phase. Then, TA checks whether the identity already exists in the database or not; if yes, send a notification; otherwise, apply the following steps: 1. Firstly, DTA selects a random number r dta 2 2 Z Ã q as a secret key and compute A dta i ¼ r dta 2 :p; andHID dta ¼ H 1 ðID dta kr dta 2 Þ. Then encrypt the hashed identity with RSA's public key Enc PK TA fHID dta ; r dta 2 ; A dta i ; R i g; to get the ciphertext CT DTA!TA ¼ Enc PK TA HID dta ; r dta 2 ; A dta i ; R i ; where R i is the secret value. The AES's public key is then utilized to encrypt the ciphertext CT DTA ! TA to get CT aes DTAbTA ¼ Enc TA pk aes fCT DTA!TA g. DTA sends CT aes DTA!TA to TA. 2. When TA receives CT aes DTA!TA , it will first decrypt Dec TA pk aes fCT DTA!TA g, and then decrypt the ciphertext Dec TA d rsa HID dta ; r dta 2 ; A dta i ; R i using it is the private key to obtain , HID dta ; r dta 2 ; A dta i ; R i . ; it also calculates it is a private key SK dta = d.PK dta , where PK dta ¼ H 1 ðID dta kt dta exp Þ is the public key of DTA, and t v exp is the expiration of SK dta . TA calculates the shared session key with DTA K TAbDTA

RSU registration phase
All RSUs submit their registration information to DTA within their domain area. Before the RSU registration phase, the DTA select a group private/public key that only valid in this area based on RSA key generation sk 0 dta ¼ r dta 2 , and pk 0 dta ¼ r dta 2 :p. Then DTA uses the private key sk 0 dta to generate signature Sign dta ¼ Sign sk dta fHID dta ; t dta exp ; pk 0 dta g. DTA also calculates X dta ¼ r dta 2 :pk 1. The RSUs generates a random number r rsu 2 Z Ã q as a secret key and computes A r i su ¼ r r su:p, and RID rsu = H 1 (ID rsu ∥ r rsu ). RSU encrypt the parameter RSA's public key CT RSU→DTA = Enc_PK DTA {RID rsu , r rsu }, A rsu i ; R i , where R i is the secret value. Then, generate ciphertext using AES's public key CT aes RSU!DTA ¼ Enc DTA pk aes fCT RSU!DTA g, and sends CT aes RSU!DTA to DTA. 2. Upon receiving CT aes RSU!DTA , DTA decrypts is using Dec DTA pk aes fCT RSU!DTA g, and also decrypts Dec DTA d rsa fRID rsu ; r rsu ; A rsu i ; R i g to get , RID rsu ; r rsu ; A rsu i ; R i . : DTA generates a RSU's private key SK rsu ¼ r dta 2 :PK rsu ; where PK rsu = H 1 (RID rsu .r rsu ). Then, it calculates the session key with DTA K DTA!RSU ¼ r dta 2 :r rsu :p; and CT DTA!RSU : Enc K DTA!RSU fSK rsu ; t rsu exp ; R i þ 1g; where t rsu exp is the expiration of SK rsu . The ciphertext is further encrypted with AES's public key CT aes DTA!RSU ¼ Enc RSU pk aes fCT DTA!RSU g, and sends CT aes DTA!RSU to RSU. 3. After receiving the RSU decrypts Dec RSU pk aes fCT DTA!RSU g, to obtain CT DTA ! RSU and compute session key with DTA K DTA!RSU ¼ r dta 2 :PK dta and decrypts Dec K DTA!RSU fSK rsu ; t rsu exp ; R i þ 1g, to get , SK rsu ; t rsu exp ; R i þ 1 . if valid, stores SK rsu ; t rsu exp . Otherwise, RSU rejects it.
In this phase, the vehicle will send a joining request to the DTA through the RSU. The information is broadcasted to each vehicle within the domain to enable the vehicle to get authenticated. The joining steps are shown in Fig. 7 and described as follow: 1. The RSU1 broadcasts ID rsu1 ; t dta exp ; t rsu exp ; T 1 ; R i ; ID dta ; PK dta ; Sign rsu1 Þ and Sign dta regularly, where Sign rsu1 Þ ¼ Sign sk rsu1 ÞfID rsu1 Þ; ID dta ; t rsu exp ; T 1 ; R i g; and calculates X rsu1 ¼ r rsu 2 :pk rsu1 Þ 0 ; I rsu1 ¼ X rsu1 þ H 2 ðM rsu1 Þ 0 ; X rsu1 Þ; and M r su 0 ¼ ID rsu1 kID dta kt rsu1 exp k T 1 kR i . Then, it encrypts it using AES public key CT RSU!V ¼ Enc V aes RSU!V fSign rsu1 kM 0 rsu g, and sends CT RSU → V to the vehicle. 2. Upon receiving, Vehicle decrypt CT RSU ! V using the public key Dec V aes RSU!V fSign rsu1 ÞkM 0 rsu g to get the signature. Then, it computes pk dta ¼ H 1 ðHID dta kt dta exp and verifies Sign rsu1 ), if invalid, end the session; otherwise, the vehicle continues to verify the freshness of the timestamp T 1 and validity of the Sign rsu1 ), if validation successful, DTA and RSU1 are considered legal entities. Vehicle choose a random number r v 2 2 Z Ã q and compute session key with RSU1 K ðV!RSU 1 Þ ¼ r v 2 :X rsu1 Þ and the session key with DTA K V!DTA ¼ r v 2 :X dta respectively. The vehicle finally choose pseudonyms kT 2 kR i and encrypts the secret value Enc_Kv! RSU1 ∥ R i , and Enc_K v ! DTA ∥ R i . Then AES public utilized to encrypt the message CT v!rsu 1 3. When the RSU1 receives the message, it decrypts the Dec V aes v!rsu 1 =DTA fSign v k FID v kT 2 kM 0 rsu g and verifies Sign v , T 2 , and t v exp accordingly. If the verification goes well, RSU1 generates a shared session key K RSU 1 !v ¼ r v 2 :X v to decrypt Enc_Kv!RSU 1 and check the validity of R i . Finally computes CT v ! DTA = Enc_CTv!RSU 1 {R i } and sends CT rsu 1  4. Upon receiving the message, DTA computes the session key K DTA!v ¼ r dta 2 :X v and decrypts Dec V aes v!rsu 1 ft v exp kFID v kCT v!DTA g and also decrypt CT ( v!DTA) to get R i . If valid, DTA generates a group of identities MID i v and the group private key sk 0 MID i v ¼ r dta 2 ; sk i for the vehicle. The DTA encrypt the message using the session key is expiration of MID i v . The DTA sends CT DTA ! v to RSU1, and RSU1 forwards the CT DTA→v , and CT RSU ! V to vehicle.

Online crossover phase
When the vehicle crosses from one domain to another, it needs to send a joining request to the RSU2 located in different geographical domains. After the RSU2 broadcasted the information to each vehicle, it will send an authentication message to RSU2, where this phase is called the crossover phase. Figure 8 shows the steps of this phase and described as follows: 1. The RSU2 broadcasts ID rsu 2 ; t rsu 2 exp ; T 3 ; R i ; Sign rsu 2 and Sign dta regularly, where Sign rsu 2 ¼ Sign sk rsu 2 fID rsu 2 ; t rsu 2 exp ; T 3 ; R i g, and calculates X rsu 2 ¼ r rsu 2 2 :pk 0 rsu 2 ; I rsu 2 ¼ X rsu 2 þ H 2 ðM 0 rsu 2 ; X rsu 2 ; and M 0 rsu 2 ¼ ID rsu 2 kt rsu 2 exp kT 3 kR i : Then, it encrypts it using AES public key CT RSU!V ¼ Enc V aes RSU!V fSign rsu 2 kM 0 rsu 2 g; and sends CT RSU → V to the vehicle.
2. The vehicle gets the message and decrypts it using AES's public key Dec V aes RSU!V fSign rsu 2 kM 0 rsu 2 g to obtain a signature, then it verifies the T 3 whether is fresh or not, if not, end the session. Otherwise, the vehicle generates a shared session key with RSU2 K V!RSU 2 ¼ r v 2 :X rsu 2 ; G Sign SK MID i v fMID i v ; T 4 ; t MID i v exp ; R i g; X rsu 2 ¼ r rsu 2 2 :pk 0 rsu 2 ; I rsu 2 ¼ X rsu 2 þ H 2 ðM 0 rsu 2 ; X rsu 2 Þ; and M 0 rsu 2 ¼ ID rsu 2 kID dta kt rsu 2 exp kT 4 kR i : Then, it encrypts it using AES public key CT V!RSU 2 ¼ Enc V aes V!RSU 2 fSign v kM 0 rsu 2 g, and sends CT V/RSU 2 to the RSU2.
3. The RSU2 first decrypts Dec V aes V!rsu 2 fSign v kM 0 rsu 2 g; and verifies the timestamp T 4 , and signature Sign v by computing the public of the vehicle pk MID i Finally, RSU2 generates a shared session key with the vehicle K RSU 2 !v ¼ r rsu 2 2 :X v , and compute CTRSU 2 →v = Enc_kRSU 2 →v {R i }, then encrypt the ciphertext using AES public key Enc V aes rsu 2 !v fCT rsu 2 !vÞ , and send it to the vehicle. 4. The vehicle uses the AES public key to decrypt the message Dec V aes rsu 2 !v fCT rsu 2 !v g, to obtain CTrsu 2 !v to decrypt it using a shared session key K v!rsu 2 ¼ r rsu 2 2 :X rsu 2 ; if the secret value R i is valid, then a trust relationship is created; otherwise, authentication fails.

Offline crossover phase
As the secret credentials have been preloaded priorly into the RSUs, the movement from RSU1 to RSU2 does occur dynamically. Therefore, when the vehicle leaves RSU1, crossover authentication is required to execute. The following steps are described as follows: 1. The RSU2 preloads the parameters r j v ; SK j rsu 2 ; t exp ; R i ; TID v ; ID rsu 2 ; t dta exp ; t rsu exp ; T 1 ; Sign rsu 2 , where the Sign rsu 2 : Sign SK rsu 2 fID rsu 2 ; t rsu 2 exp ; T 2 ; R i ; TID v ; r rsu 2 g, where t rsu 2 exp is the expiration of SK rsu 2 , and r rsu 2 2 Z Ã q is a random number. The RSU2 encrypts the offline signature using AES public key CTrsu 2 !v: {Sign rsu 2 } and sends CT rsu 2 →v to vehicle.
2. Upon receiving CT rsu 2 !v, vehicle decrypts it using the public key to get the offline signature Sign rsu 2 , then decrypt the signature using the private key of the vehicle to obtain , ID rsu 2 ; t rsu 2 exp ; T 2 ; R i ; TID v ; r rsu 2 .: The vehicle verifies the timestamps T 2 , if not fresh, authentication failed; otherwise, the vehicle generates a shared session key K ð v ! rsu 2 Þ ¼ r v 2 :X rsu 2 and select a unique private key to sign ID rsu 2 ; t rsu 2 exp ; T 2 ; R i ; TID v ; r rsu 2 . ; Sign rsu 2 : Sign SK rsu 2 fID rsu 2 ; t rsu 2 exp ; T 2 ; R i ; TID v ; r rsu 2 >; g; and then it encrypts the signature using AES public key CTv!rsu 2 : {Sign rsu 2 } and sends CTv!rsu 2 to RSU.
3. After receiving CTv !rsu 2 from the vehicle, RSU2 decrypts it using AES public key to obtain the signature Sign rsu 2 , then use the RSU2 private key to get the parameters t rsu 2 exp ; T 2 ; R i ; TID v ; r rsu 2 . RSU2 verifies the t rsu 2 exp ; R i ; and T 2 ; if verification is not equal, end session. Otherwise, generate a shared session key with the vehicle K rsu 2 !v ¼ r v 2 :X rsu 2 , and compute CT_K rsu2 !v {R i } and sends CT_K rsu2→ v to vehicle.
4. The vehicle receives the message using CT_K rsu2 !v {R i }, if the secret value is not matched, terminate the session. Otherwise, an offline authentication is established between the vehicle and RSU2.

SECURITY ANALYSIS
We provide a complete overview of the proposed scheme's security in this section to illustrate how the proposed scheme has provided robust security. The study was carried out using Burrows, Abadi, and Needham's logic in our scheme to demonstrate mutual authentication between the vehicle and other participating entities (BAN). Finally, in this section, a theoretical security examination, called informal analysis, has been discussed.

Informal analysis
The proposed scheme's security has been discussed in this sub-section in an informal review to show that the scheme provides strong security protection for associated security properties and attacks. We justify the defence of the device and attacks in the following terms of security properties. Table 3 shows the comparison of the security features of the proposed scheme against other schemes.

Message Integrity and authentication:
In the proposed scheme, a hash function h(·): 0,1 Ã →Z Ã q is utilized to the message signature that makes the faking of the message is impossible. To generate the signature, the message is further attached with secret key of the RSA algorithm to the hashed value of the message, e.g., Sign dta ¼ Sign sk dta fHID dta ; t dta exp ; pk 0 dta g by the sender. Upon receiving, the receiver can decode the message and check its validity by comparing it with the latest computed message and the RSUs. DTA can effectively ensure the message's integrity. Therefore, message integrity and authentication are supported by the proposed scheme.

Message unforgeability:
The proposed scheme is achieved by Sign dta , and h(·). The trusted authority generates the signature with a private key d, and this key is held secretly by the TA. The attacker is, therefore, cannot compute the session key that shared between entities and TA; the session K TA→v = d.A i is based on the secret key of the TA, and the attacker cannot forge the message. Also, the exchanged messages are further encrypted using the AES public key for secure communication; thus, the attacker cannot obtain the secret value R i of the entity. Therefore, only the specified RSUs, can obtain R i , and the proposed scheme can protect the message from being forged and generate the related hash function.
3. Identity privacy-preserving: The pseudonyms and RID rsu = H 1 (ID rsu ∥ r rsu ) are hashed along with identity and the random number; hence, the adversaries cannot obtain the vehicle's real identity and RSUs. Furthermore, it used to calculate several parameters T i ¼ HðVID i ksÞ; PK dta ¼ H 1 ðID dta kt dta exp Þ, and M 0 dta ¼ HID dta kt dta exp kpk 0 dta kr dta 2 the attacker cannot obtain the real identity because the identity is secured using a one-way hash function. Also, in each communication session, the pseudonyms used are different, so no opponent can obtain the identity and trace the vehicle from the message it sends. Therefore, identity and location privacy is achieved by the proposed scheme.

Non-repudiation:
In the proposed scheme, the messages CT RSU!V ; Enc K v!DTA fR i g, and CT DTA→v contains different values, e.g., fSign v kFID v kT 2 kM 0 rsu g, where M 0 rsu ¼ ID rsu 1 kID dta kt rsu 1 exp kT 1 kR i ; it has the secret value R i that know to RSUs, and DTA, the vehicle cannot deny the message it has received because of the secret value. The freshness of the timestamps also plays a vital role in checking the validity of the message. Therefore, the proposed scheme achieved the non-repudiation property. 5. Unlinkability: The message ID rsu 1 ; t dta exp ; t rsu exp ; T 1 ; R i ; ID dta ; PK dta ; Sign rsu 1 in each broadcasting operation, the RSUs are transmitted, which is different. Also, the secret SK r su is valid only for one session communication. Furthermore, the identity of the vehicle is further secured with a one-way hash function. Therefore, the adversary cannot expect that messages belong to the same vehicle. Thus, the proposed scheme provides desired unlinkability. 6. Forward secrecy: In the proposed scheme, the broadcasted parameters ID rsu 1 ; t dta exp ; t rsu exp ; T 1 ; R i ; ID dta , PK dta , Sign rsu1 indicates the legitimacy of the entity's identities. All these broadcasted parameters do not contain information about other credentials of the vehicles. Also, the session keys are used only for a single session to communicate, and although that the message is encrypted with these short-lived keys, the keys are further encrypted with AES public key. Consequently, attackers cannot obtain any information about other credentials. Therefore, the proposed scheme provides perfect forward secrecy. 7. Cross-domain Property: According to the proposed scheme's specification, two vehicles belong to different domains and are separately registered with domain trusted authorities. Every domain trusted authority has separate RSUs with vehicles and can connect mutually through the domain trusted authority.
8. Offline Authentication: In the proposed scheme, TA preloads the credentials r j v ; SK j v ; t exp ; R i ; TID v in RSUs priorly in their domain. Then, RSU1 preloads ID rsu 1 ; t dta exp ; t rsu exp ; T 1 ; R i ; ID dta ; PK dta ; Sign rsu 1 into the vehicles in prior deployment. This helps the vehicle to authenticate to the domain in offline mode while the connectivity is temporarily unavailable. Therefore, the proposed scheme provides an offline authentication. 9. 9. Impersonation Attacks: If the adversary impersonate one of the registered vehicles or RSUs, it should construct a message ID rsu 1 ; t dta exp ; t rsu exp ; T 1 ; R i ; ID dta ; PK dta ; Sign rsu 1 to meet the verification process. However, it will be difficult for the adversary to pass the verification because the signature is generated using the public key of the entity, and the parameters M 0 rsu ¼ ID rsu 1 kID dta kt rsu 1 exp kT 1 kR i are concatenated with signature and encrypted using the public key CT RSUkV ¼ Enc V aes RSU!V fSign rsu 1 kM 0 rsu g: The message also contains a secret Ri value that the recipient verifies to verify the message's validity. Therefore, no impersonation attack on the current technique can be launched by the adversary.
10. Modification attack: Assume the adversary get the encryption key during the transmission and modify the message Enc V aes RSU!V fSign rsu 1 kM 0 rsu ; he/she will not be able to obtain the signature values ID rsu 1 ; ID dta ; t rsu exp ; T 1 ; R i because it is encrypted using the secret key of the vehicle or RSUs. Also, the adversary will not pass the verification process because the message cannot be decrypted. However, the receiver who has the private key and the secret value stored in the initial registration phase is used to check the message's validity. Therefore, the proposed scheme withstands the modification attack.
11. Reply attack: In the proposed scheme, a timestamp is used in every message, e.g., M 0 rsu ¼ ID rsu 1 kID dta kt rsu 1 exp kT 1 kR i has the timestamp of the current session, and respectively after receiving, the freshness of the timestamp will be validated by comparing it with the current timestamp T 1 ≠ DT of the system. Furthermore, the shared session key between entities has an expiration time, e.g., t rsu 1 exp ; and t dta exp : Therefore, the proposed scheme resistance to reply attacks.
12. Man-in-the-middle attack: The transmitted messages may be intercepted, and the adversary could do a particular modification. In the proposed scheme, the secret vehicle key s 2 Z Ã q ; is generated randomly; also, the T i = H(VID i ∥ s), is computed based on the random number. The secret value Ri is generated randomly, sent alongside the message, and encrypted using the vehicle private key to create the signature. So, the message is transmitted in encrypted form, and it will be difficult for the adversary to get this information. Besides, if the attacker intercepts the message, the receiving message will be delayed, and it will not pass the validation process due to the timestamp usage T 1 T. The proposed scheme, therefore, withstands the man-in-themiddle attack.
13. Brute-force attack: In our scheme, various generated random, e.g., s 2 Z Ã q ; r dta 2 2 Z Ã q ; and r rsu 2 Z Ã q are used to secure the identities and sent securely to the vehicle or RSUs by encrypting them using AES public key and RSA key. If the adversary wants to break the authentication message, he/she needs to know the secret vehicle parameters or identity VID i . But, in the proposed scheme, the identity is secured using a one-way hash function and concatenated with random number T i = H(VID i ∥ s). Then, this hash value is encrypted using RSA Enc TA pk rsa fT i g, to find the value, the adversary will try all the numbers (brute-force) till find the value which transmission will be delayed and results in authentication fails due to the timestamp. So, the chance of the adversary to get/brute-force the correct value is infinitesimal. Therefore, the proposed scheme has resistance to a brute-force attack.

Burrows, abadi, and needham (BAN) logic
We use Burrows, Abadi, and Needham BAN logic in this subsection, which is used to prove the correctness of authentication methods, beginning with the solution's formalization, followed by postulates to achieve the objectives emphasized. Nonetheless, with the commonly used BAN logic technique, we show the mutual authentication validity between the vehicle and RSU. In the BAN logic analysis, Table 4 displays the related notations. We start by explaining the notes used to do the demonstration, followed by BAN logic postulates, followed by the formal idealization of the scheme's messages; we also list the assumptions of the solution and highlight the goals.
Security Goals: This process shows the session key authentication goals between vehicles and RSU that authenticated mutually. Thus, there five goals primarily used in the proposed scheme and established as follows:  Goal 4: DTA| ≡ (RID rsu ).
Goal 6: RSU| ≡ (k dta→rsu ). Messages: In this process, we idealize the scheme phase to represent the exchanged messages between the main entities of the scheme; the message representation is shown as follows: The messages of scheme can be idealized as follows:  SMI 4. DTA→RSU: (K DTAßRSU ) ( PK rsu ).
The initialization situation of the proposed scheme depends on some assumptions to prove the scheme; the assumptions are as follow: B is fresh with the key K P $ K Q P and Q use the shared key K to communicate

SK
The current session key The message-meaning rule The freshness-conjuncatenation rule The nonce verification The jurisdiction rule Proof: The stated security goals (Goal 1, Goal 2, Goal 3, Goal 4, Goal 5, Goals 6, Goal 7, and Goal 8) will be demonstrated in this process and achieved in this respect.
THE SIMULATION OF OUR SCHEME USING AVISPA AVISPA refers to Internet Security Protocols and Applications Automated Validation. It is a web-based push-button tool used to simulate the authentication protocols' security and formally validate them. To code the protocol, AVISPA uses the High-Level Protocol Specification Language (HLPSL). It is made up of four back-ends called HLPSL2IF and a tool for translators. The translator method is used to convert a scheme written in HLPSL to Intermediate Format (IF). This IF is a general language understood by all back-ends and used to evaluate and analyze multiple properties defined in the scheme by different back-ends. Four back-ends are available: Constraint-Logic-based At-tack Searcher (CL-AtSe), On-the-fly Model-Checker (OFMC), Automatic Approximate Tree Automata for Security Scheme Analysis (TA4SP), and SAT-based Model-Checker (SATMC). The architecture of AVISPA is illustrated in Fig. 9 (Vigano, 2006;Chevalier, 2004). It is crucial to specify designed protocols in the HLPSL language in AVISPA (Chevalier, 2004) HLPSL is based on roles: each participant role determines the primary roles, and the scenarios of fundamental roles describe composition roles. Each function is independent of the others and, by requirements, obtains some initial information and then communicates with the other roles across channels. The intruder is often modelled in HLPSL using the Dolev-Yao model (Dolev & Yao, 1983) (as in the threat model used in this paper) with the possibility of assuming a proper function for the intruder in the running of a protocol. The positioning system decides the number of meetings, the number of principals and the roles. By using one of the four back-ends, the output format (OF) of AVISPA is created. If a protocol analysis (by detecting an attack or not) has been successful, the performance determines precisely what the outcome is and under what conditions it has been obtained. Comprehensive formats for the OF can be found in Chevalier, 2004.

Scheme specification in HLPSL
There are three roles played by the Vi vehicle, RSU road-side unit, and DTA domain trusted authority in the proposed scheme. The other role is the role of the session, environment, and goal. As shown in Figs. 11 and 12, all the specified roles are coded in HLPSL. First, in Figs. 11 and 12, the role played by the vehicle is shown. The agent vehicle Vi receives the start signal =n RCV (start) = |> and the states changes from 0 to 1. Then, it transmits the registration message (VIDi.Ri′. CT vT A′. Ti′_SKvirsu) to the roadside unite via a secure channel =n SND () command. The =n secret(VIDi, Ai,Ki,s1,Vi) declares that the information (VIDi, Ai, Ki) is kept secret permanently to the agent Vi, and the label (s1) is the protocol (id) used to identify the goal. The declaration =n secret   K,Q,T,Ni,Cig,CIDi: text,TS1,TS2,TS3,TS4,IDrsu,Ri,Rn,Xi,Rt: text,NIDi,Ai,Bi,SKrsudta,Fi,SKvidta,SKi : text,Gi,Mi,SKrsuvi,SKmidi,CT_DTA_vi : text,H : hash_func,Gen,Rep : hash_func const vehicle_rsu_ts1,rsu_domainTA_ts2,domainTA_rsu_ts3,vehicle_rsu_ri,rsu_vehicle_ts4,domainTA_vehicle_rn,domainTA_rsu_rn,rsu_domainTA_ri,s1,s2,s3,s4,s5,s6 : protocol_id   IDdta.Ri'.Rn')).Rn'.TS4'), and the declarations =n request(RSU, Vi, rsu_vehicle_ts4, TS4′), and =n request(DTA, Vi, domainTA_vehicle_rn, Ri′) indicates the vehicle acceptance of the timestamp that generated by the RSU, and the (Ri) that sent by the DTA. The role specification of the role played by the RSU is shown in Fig. 10B  The declaration secret (IDrsu, IDdta, Ki, s1, Vi) indicates that the values are kept secret to the Vi using the label (s1). The secret (VIDi, s2, Vi, RSU) declaration shows that VIDi is shared between the Vi and the RSU. The statement secret (SKrsudta, s3, RSU, DTA) states that SKrsudta is shared between RSU and DTA. At the same time, secret (SKvirsu, s4, Vi, RSU) indicates SKvirsu is known to the Vi and RSU. In the authentication phase, the RSU sends the message (Mi'.TS4') via a secure channel using SND ( ). However, the witness (RSU, Vi, rsu_vehicle_ts4, TS4′) declaration specifies that the RSU has freshly generated TS4 for the vehicle. The declaration request (Vi, RSU, vehicle_rsu_ri, Ri) indicates that the vehicle accepts Ri's value. The specification of domain trusted authority role (domainTA) is shown in Fig. 11. The DTA receives the message ({H (NIDi′. IDdta.Ri′. TS2′). NIDi′. IDdta.xor (Ri′, H (SKrsudta. NIDi′. IDdta.)).TS2′} SKrsudta) from the RSU. However, the declaration secret (SKrsudta, s3, RSU, DTA) indicates that the value SKrsudta is shared between the RSU and DTA using the label (s3: protocol_id). In the command secret (SKvirsu, s4, Vi, RSU), we declare that the SKvirsu shared between the vehicle and RSU generated freshly by the DTA. The value IDdta as stated in declaration secret (IDdta, s6, Vi, RSU, DTA) is known to the vehicle, RSU, and DTA. Later, the domain trusted authority sends the message (Gi′. CT D TA v i′.TS3′) using secure channel SND (). Nevertheless, the declarations witness (DTA, RSU, domainTA_rsu_ts3, TS3′, and witnessðDTA; RSU; domainTA rsu; Rn 0 Þ states that the DTA has freshly generated TS3', and Rn' for the RSU. We presented the roles for the session, goal, and environment in the HLPSL code in Fig. 12. All primary roles, including roles for the (Vi, RSU, and DTA), are incorporated with concrete arguments in the session segments. The environment section contains the global constant and composition of one or more sessions, and knowledge of the intruder is also provided. We define six secrecy objectives in our scheme simulation, and five authentications are tested.
The secrecy_of s1: It represents that the (VIDi, Ai, Ki) is kept secret only (Vi).
The secrecy_of s4: The (SKvirsu) is secretly shared between the Vi and RSU.
The secrecy_of s6: It states that the identity (IDdta) is known to all entities (Vi, RSU, DTA). The authentication_on vehicle_rsu_ts1, vehicle_rsu_ri: It represents that the values (TS1′), and (Ri′) are generated randomly and known to the (Vi) and (RSU). The authentication_on rsu_domainTA_ts2, rsu_domainTA_ri: It indicates that the values (TS3′), and (Rn′) are generated by the DTA and sent to the RSU securely, and the values are fresh. The authentication_on domainTA_rsu_ts3, domainTA_rsu_rn: The values TS3′ and Rn ′ are generated freshly for the RSU by the DTA and authenticates the RSU to DTA.
The authentication_on rsu_vehicle_ts4, rsu_dta_ts2: It represents that the timestamp TS2′ is generated freshly by the RSU for the vehicle. The authentication_on domainTA_vehicle_rn: indicates that the value Rn′ generated freshly by the DTA for the vehicle.

Simulation results
For an execution test and a limited number of model checking sessions, we chose the back end OFMC (Basin, Mödersheim & Vigano, 2005). This back-end tests whether legitimate agents can execute the specified protocol by conducting a passive intruder search for replay attack checks. After that, the intruder is given the information of some regular sessions between the legitimate agents by this back-end. This back end also checks whether the attacker can carry out any man-in-the-middle attack for the Dolev-Yao model search. With the OFMC back-end, under the AVISPA web tool, we simulated our schema for formal security verification. Figures 13A and 13B in Fig. 13 show the simulation results for our scheme's formal security verification using OFMC. The first written part, called the Summary, indicates in these statistics whether the protocol is stable, risky, or whether the analysis is inconclusive. The written Overview segment safeguards our scheme. The information section explains what state the device is considered secure, what conditions were used to detect an attack, or why the analysis was inconclusive. It is recognized that our architecture is deemed to be protected, and our system does not detect an attack. Consequently, the result of this figure suggests that our system is safe from passive and active attacks, including man-in-the-middle replay attacks and attacks. Knowledge of daily sessions between the authentic agents is given to the intruder. Figures 13A and 13B in Fig. 13 show the OFMC and CL-AtSe back-end simulation results and demonstrate that the scheme is secure and stable against attacks.

PERFORMANCE EVALUATION
In this section, we evaluate the performance of the proposed system in terms of cost of computation and communication with other VANET authentication schemes, e.g., ID-CPPA (Ali & Li, 2020); AAAS (Jiang, Ge & Shen, 2020), and HCDA (Tan, Xuan & Chung, 2020). The performance of the schemes against those schemes is shown in Table 6. The performance metrics evaluation is described as following:

Computation cost
Here, we analyze the computation cost of the proposed scheme against other authentication schemes for the VANET system, e.g., ID-CPPA (Ali & Li, 2020); AAAS (Jiang, Ge & Shen, 2020), and HCDA (Tan, Xuan & Chung, 2020) are summarized in Table 6. In this study, the cryptographic operations involved are counted. To represent the comparison, Table 5 shows the notations, definition, and calculation of their estimated execution time by using the PBC library stated by Al-Shareeda et al. (2020) for different cryptographic operations. It is noted that the XOR operation and concatenated operation k are ignored because their execution time is negligible. The proposed scheme's simulation was carried out on Intel Core™i7-5700HQ, CPU 2.70 GHz platform using Java Pairing-Based Cryptography Library (JPBC) library. In the proposed scheme, we applied five cryptographic operations hash function, symmetrical encryption, symmetrical decryption, asymmetric signature, and asymmetric signature verification that related to AES and RSA algorithm, which are respectively donated as T h , T se , T sd , T as , and T av . two-time hash function 2T h , and two-times exponentiation operation 2T pe , and the computation cost in RSU is nearly ≈ 18.0184 ms. In the TA side, there were two times hash function operation used 2T h and it costs 0.002 ms. Therefore, the total computation cost of Tan's scheme (Tan, Xuan & Chung, 2020) is approximately ≈ 28.596 ms. In the proposed scheme, the vehicle needs to execute three times hash function 3T h , one times asymmetric encryption 1T as , one times symmetric encryption 1T se , one times symmetric decryption 1T sd , and one times asymmetric signature verification 1T av related to RSA, and AES. The execution time of these operation is approximately 0.003, 3.8500, 0.0046, 0.0046, and 0.1925 respectively. Therefore, the computation cost in the vehicle side is 3T h + 1T as + 1T se + 1T sd + 1T av ≈ 4.0547 ms. In the RSU side, there are five operations needed to be executed e.g., one-time hash function 1T h , one-time asymmetric encryption 1T as , two times symmetric encryption 2T se , two times symmetric decryption 2T s d, and one-time asymmetric signature verification 1T av . Their execution time is independently 0.001, 3.8500, 0.0092, 0.0092, and 0.5775 ms. Therefore, the computation cost in RSU side is 1T h + 1T as + 2T se + 2T sd + 1T av ≈ 4.0619 ms. Likewise, the DTA needs to execute two cryptographic operations, one-time symmetric encryption 1T se , and one time symmetric decryption 1T sd , The execution time of these operations is 0.0046 ms, and 0.0046 ms. Thus, the computation cost in the DTA side is 1T se + 1T sd ≈ 0.0092 ms. Therefore, the total computation cost of the proposed scheme is approximately 8.1258 ms. Comparing to other schemes and as shown Table 6, the proposed scheme has less computation cost due to the use of lightweight cryptographic operations which makes the scheme suitable for Industrial IoT environment.

Communication cost
The communication cost refers to the size of the interacted messages between the system entities. Our proposed scheme has four interacted messages exchanged in the whole joining phase amongst the vehicle, road-side units, and domain trusted authority. 32 bits represent the size of the identity, general hash function 160 bits, secret value 160 bits, time expiration of the value, and the timestamp with the size of 32 bits, respectively. In AAAS scheme (Jiang, Ge & Shen, 2020), the message a ¼ V v ; W v ; V v ; W v 2 G 1 ; N 8 2 Z Ã q with pseudo-identity f i v , expiration Exp f i v , timestamp TS 4 , and challenge value N 8 is signed by the vehicle and transmitted to the RSU. As we mentioned above, the size of the identity is represented as 32 bits, expiration and time stamp is represented as 32 bits, and the challenge value is represented as 1,024 bits. The communication can be calculated as 160 + 32 + 32 + 16 + 1024 × 2. Therefore, the total communication cost of In Jiang scheme (Jiang, Ge & Shen, 2020), is 2,432 bits. In ID-CPPA Scheme Ali & Li (2020), the vehicle needs to transmit the message α i = (A i , B i ) ∈ G 1 along together with the pseudo-identity PIDi = (PID i , 1, PID i , 2), where PID i ,1 ∈ G 1 , and PID i ; 1; 2 2 Z Ã q : However, in their scheme, they take the signature's size in the message and the corresponding identity only into account. Thus, the communication cost of Ali's Scheme (Ali & Li, 2020) can be calculated as 128 ÷ 3 + 20 + 4 = 408 bytes, where, (128 bytes = 1,024 bits), (20 bytes = 160 bits), and (4 bytes = 32 bits), therefore, the total communication cost of their