A blockchain-based lightweight authentication and key agreement scheme for internet of vehicles

Abstract

The Internet of Vehicles is deployed in an open environment, and protecting its security and data privacy is the challenge. Carrying out the Internet of Vehicles secure authentication before interaction of information is an important part of ensuring the security foundation. Therefore, this article designs a safe and reliable Internet of Vehicles authentication and key agreement schemeassisted by blockchain. This article uses a multi-TA network model to improve the efficiency of authentication. Because of the rapid movement of vehicles, it will continue to appear cross-RSU and TA certification. Considering the disadvantages of most centralised authentication protocols using a single TA, this paper uses the multi-TA model to improve the efficiency of authentication. By usingblockchain technology to store the authentication information of vehicles, the cross-domain authentication of vehicles and the protection of user privacy information can be well realised. At the same time, in order to reduce the time of vehicle authentication, this scheme uses a lightweight calculation operation to complete the whole process of authentication. Through security analysis and results of Proverif simulation, the security of the solution is well proved, our scheme can resist various common attacks. Compared with some existing Internet of Vehicles security authentication protocols, the proposed scheme has a lower cost of computation, communication, and storage.

Keywords:

• Blockchain
• internet of vehicle
• mutual authentication
• security

1. Introduction

With the development of data processing (Liu et al., 2019) and communication technology, vehicles begin to be intelligent (Zhao et al., 2021). The vehicle integrates sensor computing, network communication, and other technologies, which enables it to interact with different units. It is the intelligent development of vehicles that led to the emergence of the Internet of Vehicles. It is not only an important part of the intelligent transportation system (Zheng et al., 2021), but also an important innovation in the Internet of Things technology (Xiao & Zhu, 2017). In the Internet of Vehicles, vehicles can realise V2X communication through their own communication components. X can be any entity, which includes communication between vehicle and vehicle(V2V), communication between vehicle and infrastructure (V2I), communication between vehicle and RSU (vehicle and roadside unit), etc (Machardy et al., 2018). The structure of the traditional internet of vehicles is shown in Figure 1. Internet of vehicles can provide users with a lot of basic services, such as vehicles can get traffic information, allowing users to make traffic decisions, vehicles can collect road information through sensors, GPS, and other equipment and share it with other vehicles in real time (Zhang et al., 2021). More and more smart cars are joining, which has led to a massive increase in traffic data to the Internet of Vehicles, and because of its open environment, the security problems of the Internet of Vehicles are getting worse (Jiang et al., 2019). It is not only necessary to safely and reliably protect the data privacy of vehicle users, but also prevent attacks from malicious users, such as data tampering, data replay, denial of service, man-in-the-middle attacks, and other malicious behaviours (Aman et al., 2020). These malicious behaviours will make users unable to use the Internet of Vehicles service normally, and cause serious traffic accidents due to the use of wrong traffic information data. The first step to improve the reliability and security of the Internet of Vehicles is to verify the security of users. It can ensure that legitimate vehicles enter the Internet of Vehicles and refuse the participation of illegal users. This is also the focus of experts' research on the Internet of Vehicles in recent years.

Figure 1. The structure of the traditional internet of vehicles.

Authentication of identity and data processing efficiency are important factors to realise the real-time response of the Internet of Vehicles (Huang et al., 2021). Reducing the time delay can provide users with fast traffic decisions and ensure good service quality (Qiu et al., 2018). During the fast driving process of the vehicle, it will pass through different areas and conduct multiple authentications, which will also increase the computational and communication costs of vehicles, thereby affecting the service quality of the Internet of Vehicles. The German Federal Highway Research Institute (BASt) reports that the risk of traffic accidents caused by the traffic decision made by the owner under the condition of reaction delay is eight times higher than that in the normal situation, and the risk of fatal traffic accidents is four times higher (Huang et al., 2010). Therefore, it is necessary to ensure that the Internet of Vehicles has a low-latency authentication scheme, which can enable users to quickly obtain traffic information services and make correct decisions in time (Jiang et al., 2016; Vasudev & Das, 2018). In the current Internet of Vehicles authentication, the PKI method is still the most adopted. Because of the fast-moving characteristics of vehicles, TA must complete the trust relationship and key agreement with the vehicle in a short time. As the number of vehicles increases, many vehicles carry out authentication at the same time, which will cause heavy tasks on central node and privacy leakage of user (Wu et al., 2021). TA requires multiple information interactions with vehicles, which leads to increased delays in authentication and communication and makes it more unsuitable for fast-moving vehicles to access the Internet of Vehicles (Xiong et al., 2012). Therefore, the efficiency in the traditional PKI scheme is easily affected by the computational performance of TA. In our smart city, the independent development of regions has become more and more mature. Each region should have its own TA for vehicle management. Therefore, the Internet of Vehicles can no longer use a single TA for authentication and should use a multi-TA model. Given the ability of vehicles to move quickly and the limits of RSU communication range, vehicles will certainly encounter many RSUs or enter different areas during driving, and the number of authentication will increase (Yao et al., 2019). Therefore, shortening the time of authentication and communication is the main goal of authentication scheme for Internet of vehicle, and it also needs to meet the security characteristics such as authenticity, integrity, and anonymity. In order to ensure these security features, the blockchain (Li et al., 2021) can well meet these needs. As a distributed ledger, blockchain has the characteristics of tamper-proofing, integrity, and decentralisation (Liang et al., 2020). It is suitable for distributed application scenarios and provides great help to solve the problem of cross-domain authentication of vehicles. Blockchain has become a reliable technology to solve the security problem of vehicles. It solves the problem of message leakage caused by centralisation, and also makes attackers unable to tamper with vehicle-related data. Based on the above scenarios, this article proposes a blockchain-based lightweight authentication and key agreement scheme for Internet of vehicles. The main contributions of this article are summarised as follows:

• This article uses a multi-TA network authentication model to establish a trust relationship with the vehicle. All TAs serve as nodes of the blockchain to maintain vehicle-related information to achieve cross-domain authentication.

• To reduce the security risks caused by information leakage through distributed storage, We store the vehicle's auxiliary authentication information and the vehicle's real identity information separately. The former is stored in the alliance chain, and the latter is stored in the private chain of TA and RSU nodes in each region.

• Each entity performs mutual authentication and reaches a key agreement to enhance security.

• In order to realise the lightweight authentication, we only use XOR, connection, hash, and other related operations in the whole scheme, which reduces the calculation and storage cost of vehicle identity authentication and ensures the security characteristics required by the system.

• Through security analysis and using the ProVerif tool, we prove the security of the authentication and key exchange mechanism designed in this scheme.

2. Related work

The design of the Internet of Vehicles is mainly to provide driving services for vehicle users, de Cock Buning and de Bruin (2017) information security and privacy issues are very important. The first step to solve the problem of security and privacy in VANETs is authentication, which has attracted more and more scholars' attention and research. Raya and Hubaux (2007) proposed an authentication scheme based on public-key infrastructure (PKI), which can complete identity authentication and ensure message integrity, but the process of authentication is complicated, the communication volume of RSU is huge, and the vehicle needs to store a large number of certificates. Vasudev et al. (2020) proposed Internet of Vehicle identity authentication protocol, which uses physical unclonable functions to implement anonymous identity authentication, but it has not been proven that it can prevent man-in-the-middle attacks. Yahiatene and Rachedi (2018) use anonymous identity for authentication, which can well protect the user's private information and protect against identity relocation attacks, but this scheme has a long delay and requires a lot of storage space. Lei (2016) proposed an efficient and anonymous authentication scheme, which uses the roadside unit RSU for batch authentication, but the authentication of RSUs is very frequent and the workload of RSUs is considerable. Wang et al. (2021) designed a novel authentication protocol for emergency vehicles. Although the subsequent process of authentication is simplified and the interaction of identity information is reduced, its overall authentication delay is still high. At the same time, the workload of RSU is relatively large, which has a great impact on efficiency. Fromknecht et al. (2014) proposed a blockchain-based decentralised PKI authentication system to provide key querying and identity binding service, but it may leak user's privacy because the user's identity and public key are stored in the blockchain directly. Vasudev et al. (2020) proposed a lightweight authentication scheme that simplifies the authentication process to respond to vehicles in real time. In terms of safety performance, malicious vehicles cannot be effectively traced. Basudan et al. (2017) also designed a privacy protection protocol in order to improve the security of the Internet of Vehicles. Wang et al. (2018) proposed a scheme based on Paillier encryption. However, these authentication schemes are too centralised and require multiple communication, which leads to increased consumption of computing and communication. Obviously, the traditional centralised authentication method can no longer meet the growing demand for cross-domain communication. As a distributed ledger, blockchain has become a good solution for the Internet of Vehicles authentication scheme. It can not only provide anonymity, authenticity, and integrity for information but also play an important role in the cross-domain authentication of vehicles (Liang et al., 2021). Wang et al. (2019) developed an effective blockchain-based decentralised authentication mechanism for the Internet of Vehicles, which solved the centralisation problem caused by the traditional centralised authentication, but did not protect the private information of the vehicle and did not conduct a comprehensive security analysis. Vehicles are vulnerable to security attacks such as identity relocation. Wang et al. (2020) proposed a scheme that uses blockchain assistance to calculate the credibility of vehicles and implement cross-domain authentication. Although the consumption of calculation and communication of vehicles in the subsequent authentication is reduced, the calculation overhead in the initial authentication stage is still relatively big. Lei et al. (2017) used the blockchain to construct an identity authentication and key agreement protocol and designed a new network topology to simplify the management of distributed keys in the Internet of Vehicles, but it did not implement a key update. Xu et al. (2021) also proposed a blockchain-assisted authentication protocol for Internet of Vehicle. With the help of blockchain, only some lightweight calculational methods are used to complete the authentication, which greatly reduces the calculation of the authentication process. But it still has the problem of data centring, and the efficiency of authentication is easily affected by the data centre. Yao et al. (2019) proposed a lightweight anonymous authentication for distributed vehicle fog services assisted by blockchain, but the computational cost and time consumption will continue to increase as the number of vehicles increases. Eddine et al. (2021) proposed a blockchain authentication scheme based on fog computing, which has an efficient authentication efficiency but cannot adapt to large-scale authentication of vehicles, and there is still a high delay when the number of vehicles is large. Kang et al. (2018) used mobile edge computing and blockchain to realise data sharing and information security in the Internet of Vehicles. The authentication scheme designed does not support the mutual authentication, and the security is lower than that of the mutual authentication scheme. Therefore, in view of the security features and real-time requirements of the Internet of Vehicles, we designed a lightweight blockchain-based identity authentication and key agreement scheme for the Internet of Vehicles.

3. Background and system structure

3.1. Elliptic curve cryptography

Elliptic Curve Encryption Algorithm (ECC) is an asymmetric encryption algorithm based on the mathematical theory of elliptic curve (Xiao et al., 2021). In general, the elliptic curve can be represented by the following equation, where A, B are coefficients. (1) $y^2=x^3+Ax+B$(1) Choose two non-negative integers A and B that are less than P meet the following constraints: (2) $4A^3+27B^2\ne 0$(2)

Definition 3.1

Elliptic curve discrete logarithm problem (ECDLP): Given a prime number p and an elliptic curve E, for (3) $Q=X\cdot P$(3) that find a positive integer X less than p, given P, Q. The advantage of an adversary to calculate during polynomial time is as given: $Ad{v}_A^{ECDLP}\left(t\right)=\mathrm{P}\mathrm{r}\mathrm{b}\left[A\right(Q,P)=X]$, $Ad{v}_A^{ECDLP}\left(t\right)<ϵ$, is the ECDLP assumption concluded, where $ϵ>0$, is very small (Chaudhry et al., 2017).

3.2. One-way hash function

One-way hash function (Liu et al., 2021) can calculate quickly a fixed-length hash value based on information of any length, and the hash value is different for different messages, It has a one-way nature, which means that the hash value cannot be used to inversely calculate the message.

Definition 3.2

Hash function has the feature of resisting collision that predefined security anti-collision hash function Hf(). The opponent wants to find a label $(m_1,m_2)$ in order to get $\left(Hf\right(m_1)=Hf(m_2\left)\right)$ which is marked as $Ad{v}_A^{HASH}\left(t\right)=\mathrm{P}\mathrm{r}\mathrm{b}\left[\right(m_1,m_2)\leftarrow A:(m_1\ne m_2),(Hf\left(m_1\right)=Hf\left(m_2\right)\left)\right]$, where A is permitted to choose $(m_1,m_2)$ arbitrarily in polynomial time t, the collision resistance deduce that $Ad{v}_A^{HASH}\left(t\right)<ϵ$ (Chaudhry et al., 2017)

3.3. Blockchain

Blockchain is a distributed peer-to-peer network (Liang et al., 2019). It is also a specific data structure that combines data blocks in chronological order in a chain, and is cryptographically guaranteed to be non-tamperable, non-forgeable, and shared general ledger. There are three types of blockchains: public chains, private chains, and alliance chains. Faced with different types of application scenarios, different types of blockchains can be selected. The security requirements of the Internet of Vehicles coincide with the technical characteristics of the blockchain (Yang et al., 2019). In order to solve the problem that leakage of privacy information, and tampering caused by the traditional centralised authentication system, and to solve the problem of rapid cross-domain authentication, blockchain can be used technically to store the relevant authentication information of the vehicle. If an attacker wants to modify the data on the blockchain, it must not only modify the hash value of the current blockchain but also modify the hash value of all blocks on the chain. The cost is extremely high. In our proposed security scheme, we use blockchain to store vehicle auxiliary information for cross-domain authentication. The structure of the blockchain in this article is shown in Figure 2. In order to protect the privacy of users, the registered nodes TA in each region form an alliance blockchain and are responsible for initiating a consensus on the auxiliary authentication message $<OB{U}_{info},M_2>$ obtained after vehicle registration. Because the private chain has a built-in access control layer in the protocol, it can manage access rights and ensure the privacy and security of data. In order not to expose the real identity of the user to the alliance chain with more participating nodes, We form a private chain of registered nodes (TA) in each region and all RSUs in the region, which is responsible for storing and updating the mapping relationship between anonymity and the real identity of registered vehicles in the region. In the blockchain structure, each block contains the previous block's hash value, timestamp, markle tree, block transaction, etc. As far as the consensus algorithm is concerned, PoW (Javaid et al., 2020) needs to consume a lot of computing resources and cannot meet real-time performance. PoS (Ayaz et al., 2020) and DpoS (Liang et al., 2020) are also not suitable for the application scenarios of the Internet of Vehicles, so the alliance chain and Private chains all use the PBFT consensus algorithm, which has a low consensus response and meets the real-time requirements of the Internet of Vehicles.

3.4. System structure

The Internet of Vehicle System is composed of the following parts: authoritative department (AD), vehicle, trust agency (TA), roadside unit (RSU), vehicle server (VS). In smart city management, a city has only one AD, the city consists of several regions. Each region will have its own TA, RSU, and VS. When the vehicle enters the region managed by a TA, it will pass through multiple RSU communication ranges in the region. After the vehicle is authenticated by RSU, the key to communicate with VS can be obtained. VS provides corresponding services for the vehicle through the key. The Internet of Vehicle model framework of this article is shown in Figure 3.

• AD (authoritative department): It manages the TA of the entire CITY system and initialises and publishes system security parameters

• TA (trust agency): Each region is managed by a TA, TA is responsible for vehicle registration tasks. TAs in this region and TAs in other regions act as alliance chain nodes that store vehicle authentication information $〈OB{U}_{info},M_2〉$, In addition, TA in each region and RSU belonging to the region together form a private chain, which maintains the real identity and anonymous identity $〈I{D}_{OBU}-HID〉$ of registered vehicles in the region.

• RSU (roadside unit): It is responsible for mutual authentication with vehicles entering the communication range, and assists VS to complete key agreements with the vehicle. RSU, as a private chain node, maintains $〈I{D}_{OBU}-HID〉$ together with TA in the region. It can also access the alliance chain.

• VS (vehicle server): As an information platform for providing services for vehicles, it is deployed around each RSU. With the help of RSU, complete the key agreement with the vehicle, and finally provide service for the vehicle through the key. The services VS can provide are road traffic information, route planning, entertainment applications, etc.

3.5. Adversary threat model

The threat models used in this article are as follows:

1. All TAs are semi-trusted nodes, they may produce malicious behaviour, but their malicious behaviour will not affect other TA nodes.

2. The adversary has the ability to intercept all data transmitted through non-secure channels, he can inject new data, and replace or replay previously sent data.

3. The adversary can simulate the communication between entities. For example, the adversary can simulate a trusted node and perform authentication.

4. The adversary can perform password guessing through offline attacks of password guessing.

5. The shared key between RSU and TA is stored in the tamper-proof device. Even if the adversary compromises the RSU or TA, it still cannot obtain the session key.

6. The adversary can capture the vehicle's session information to retrieve the parameters.

Figure 2. Blockchain structure.

Figure 3. Internet of Vehicle System model framework.

4. Proposed scheme

In this section, we will describe in detail the proposed scheme, which consists of five stages: (1) system initialisation stage, (2) registration stage, (3) consensus stage, (4) mutual authentication and key agreement stage. (5) Vehicle real identity retrospective and anonymous identity change Its workflow is shown in Figure 4. We will explain each stage in the following sections. Table 1 shows the label descriptions used in the certification process.

4.1. Description of our scheme

4.1.1. System initialisation phase

When the system is being established, AD loads the parameters into TA and RSU through offline mode.

Figure 4. Project workflow.

Table 1. Label description.

Symbol	Description
$I{D}_{OBU}$	Identity of the vehicle with the OBU device
$P{W}_i$	Password of vehicle with the OBU device
HID	Anonymous identity of vehicle with the OBU device
$OB{U}_{info}$	Vehicle authentication parameters stored in blockchain
$S{K}_{TA}$	Secret Key shared between TAs
$K_s$	Secret Key shared between VS and TA
Key	Secret Key shared between vehicle and VS
$\Vert$	Concatenation Operation
$h(\cdot )$	One-way cryptographic hash

• AD chooses a large prime number P and a finite field $Z_P^{\ast }$.

• AD generates a session key $S{K}_{TA}$ shared by each regional TA.

• AD chooses a secure one-way encryption hash function $h(\cdot )$.

• Each TA will get the parameters $\mathrm{\partial }=\{Z_P^{\ast },P,S{K}_{TA},h\}$ shared by AD when it is arranged.

4.1.2. Registration stage

Each vehicle needs to register with the local TA before obtaining the relevant services provided by the Internet of Vehicles. TA will check the identity information of the registered vehicle, assign it a public–private key pair, and store the relevant information of the vehicle in the blockchain. The specific steps are shown in Figure 5.

Figure 5. Steps in the registration phase.

• The user submits the real message of his related vehicle and unique identity $I{D}_{OBU}$, vehicle password $P{W}_i$. It generate a timestamp T, and creating anonymous identity $HID=h\left\{I{D}_{OBU}||T\right\},H_{pw}=h\left(P{W}_i\right)$. User sends $\{I{D}_{OBU},HID,H_{pw}\}$ to TA through a secure channel (offline transmission).

• TA checks the vehicle information and $I{D}_{OBU}-HID$, and then TA selects a random number $S{K}_{OBU}\in Z_P^{\ast }$, as vehicle's private key, and computes the public key that $Pu{b}_{OBU}=S{K}_{OBU}\ast P$. TA assigned $\{Pu{b}_{OBU},S{K}_{OBU}\}$ to vehicle. In addition, $TK=\{Pu{b}_{OBU},S{K}_{OBU}\}$. The TA choose a random number R, then calculates $L=h\left(I{D}_{OBU}||S{K}_{OBU}\right)\oplus h\left(I{D}_{OBU}||S{K}_{TA}\right),OB{U}_{info}=H_{PW}\oplus L,M_1=h\left(I{D}_{OBU}||S{K}_{TA}\right),M_2=h\left(S{K}_{TA}||R\right)$.TA broadcasts $HID-〈OB{U}_{info},M_2〉$ to the alliance chain, broadcasts the mapping $〈I{D}_{OBU}-HID〉$ of the vehicle to the local private chain and stores TK locally. TA sends smart card $\{M_1,M_2\}$ and TK to the vehicle.

The vehicle user saves $I{D}_{OBU},P{W}_i$, HID, T, TK, Smart Card $\{M_1,M_2\}$ for future communication.

4.1.3. Consensus stage

In our scheme, there are alliance chains and private chains. TAs of all regions form an alliance chain, and TAs and RSUs of each region form a private chain. In order to reduce the consumption of consensus time, they choose to use the PBFT algorithm to form a public ledger. To solve problems caused by centralised management, we use the tamper-proof modification of the blockchain to write the relevant auxiliary authentication information $〈OB{U}_{info}$, $M_2〉$ of the vehicle into the alliance chain composed of TA. Because of the openness and transparency of the blockchain, if all TAs can obtain the relevant identity information of the vehicle, it is easy to cause the leakage of the vehicle information. Therefore, We introduce a private chain to store identity information $〈I{D}_{OBU}-HID〉$ for vehicles registered in the area. If there is a TA seeking the true identity of a malicious vehicle on the consortium chain, each TA can quickly search on its own private chain to see whether there is the real identity of the anonymous vehicle. In the consensus process, we take the alliance chain as an example, and the consensus process is shown in Figure 6.

Figure 6. Consensus process.

1. We assume that there are n registered nodes $\{T{A}_1,T{A}_2,T{A}_3\cdots \cdots T{A}_n\}$, in a certain city, and they are all responsible for creating blocks as consensus nodes of the blockchain. In each round of consensus, one node is selected as the speaker. The remaining nodes serve as slave nodes to respond or vote and the speaker cannot vote. In order to save consensus time, each speaker is responsible for k rounds of consensus. The rule for the election of speakers is $X=(heighmodn)+1$ Where heigh is the height of the current block.

2. After the vehicle has passed the TA registration, the TA will publish the vehicle's auxiliary information $〈OB{U}_{info},M_2〉$ to the alliance chain, so as to facilitate the subsequent cross-RSU or TA certification of the vehicle. At the same time, the TA announces the relationship $〈I{D}_{OBU}-HID〉$ to the private chain of its own group for consensus. After a certain fixed time interval, ▵t, the vehicle auxiliary authentication information $〈OB{U}_{info},M_2〉$ set within the interval is constructed into a block, and the speaker will send $〈Prequest.heigh,T{A}_X,SIGT{A}_X\left(Block\right),Block〉$ to other TAs, $P_{request}$ represents the speaker's vote request.

3. After the TA node receives the speaker's voting request, it will check the block content and make a voting response and broadcast that $〈Presponse,heigh,T{A}_K,SIGT{A}_K\left(Block\right),Block〉$.

4. Each TA node will reach a consensus only if it receives voting responses from N-F nodes, otherwise, it will enter the next round of consensus. Among them, F stands for $(N-1)/3$, which means that at most F nodes are tolerated during the consensus process, such as offline caused by network failure.

4.1.4. Mutual authentication and key agreement stage

After registered vehicles want to obtain services from VS, they must first perform mutual authentication with RSU and a key agreement with VS. The specific process is as follows.

• The vehicle generates a timestamp $T_0$ and calculate $L_{OBU}$, $Aut{h}_{OBU}$, these parameters are used for authentication. $X_0=h\left(P{W}_i\right)\oplus h\left(M_2\right),L_{OBU}=h\left(I{D}_{OBU}||S{K}_{OBU}\right)\oplus M_1$, $Aut{h}_{OBU}=h\left\{L_{OBU}||X_0||T_0||HID\right\}$, Vehicle sends $\{T_0,X_0,Aut{h}_{OBU},HID\}$ to RSU, as shown in Algorithm 1.

• RSU verifies the timestamp and matches the $<OB{U}_{info},M_2>$ according to HID from the blockchain. First, RSU obtains the password information of the vehicle and calculates $H_{PW}^{\ast }=X_0\oplus h\left(M_2\right)$. RSU calculates vehicle identity information $L=OB{U}_{info}\oplus H_{PW}^{\ast }$, computes $Aut{h}_{OBU}^{\ast }=h\left\{L||X_0||T_0||HID\right\}$. RSU verifies whether $Aut{h}_{OBU}^{\ast }$ and $Aut{h}_{OBU}$ are equal and completes the validation, otherwise disconnecting the connection. Next, RSU computes $X_1=L\oplus h\left(K_S\right)$. and generating a timestamp $T_1$, Computes ${Auth}_{RSU}=h\left\{X_1||L||T_1||K_S\right\}$, Finally, RSU sends $\{{Auth}_{RSU},X_1,T_1\}$ to VS. The specific steps are shown in Algorithm 2.

  

• VS first verifies the timestamp $T_1$ sent by RSU, Computes $L^{\ast }=X_1\oplus h\left(K_S\right)$, $Aut{h}_{RSU}^{\ast }=h\left\{X_1||L^{\ast }||T_1||K_S\right\}$. Check if ${Auth}_{RSU}^{\ast }$ is equal to ${Auth}_{RSU}$, if it is equal, the authentication of the RSU is completed. Otherwise, disconnect the connection. VS generates a timestamp $T_2$ and random number $R_s$. VS calculates the $key=h\left(L^{\ast }||R_s\right),X_2=R_s\oplus L^{\ast }$, $Aut{h}_{VS}=h\left(X_2||T_2||R_s\right)$. Finally, VS sends $\{{Auth}_{VS},X_2,T_2\}$ to RSU. The specific steps are shown in Algorithm 2.

  

  

• RSU verifies the timestamp $T_2$, and calculates $R_s^{\ast }=X_2\oplus L,Aut{h}_{VS}^{\ast }=h\left(X_2||T_2||R_s^{\ast }\right)$. RSU checks if $Aut{h}_{VS}^{\ast }$ is equal to ${Auth}_{VS},$ if they are equal, its integrity is valid and authentication is successful. RSU generates a timestamp $T_3$ and computes $Aut{h}_{rsu}=h\left(X_2||R_s^{\ast }||T_3||L\right)$. Finally RSU sends $\{Aut{h}_{rsu},X_2,T_3\}$ to vehicle.

  

• Vehicle checks timestamp $T_3$, computes $R_s^{\ast }=L_{OBU}\oplus X_2,Aut{h}_{rsu}^{\ast }=h\left\{X_2||R_s^{\ast }||T_3||L_{OBU}\right\},$ If $Aut{h}_{rsu}^{\ast }$ equals $Aut{h}_{rsu}$, the validation completes. Finally, vehicle calculates the $key=h\left(L_{OBU}||R_s^{\ast }\right)$ . The specific steps are shown in Algorithm 3.

4.1.5. Vehicle real identity retrospective and anonymous identity change

The private chain composed of TAs and RSUs in each region maintains a public ledger with the label $〈I{D}_{OBU}-HID〉$ of the real and anonymous identity of the vehicle user. When a node on the alliance chain looks for the real identity of the malicious vehicle, a request broadcasting Request-HID is sent, each TA node will start a smart contract to forward the message to the private chain maintained by itself, and look for the identity information of the anonymous vehicle on the private chain. If it exists, TA broadcasts the real identity information $〈I{D}_{OBU}-HID〉$ to the alliance chain. On the private chain and the alliance chain, the Speaker on the respective chains will set the status of the vehicle's different information $〈I{D}_{OBU}-HID〉$ to be invalid and add them to the public ledger maintained by the blockchain. If the authenticated vehicle wants to change HID, the vehicle sends a change request $〈HI{D}_{new},I{D}_{OBU}-HID〉$ to the new TA. New TA stores the $〈I{D}_{OBU}-HI{D}_{new}〉$ on its private chain and tells other TAs that HID identity information has changed.

5. Security analysis

This part shows the security analysis of our proposed solution. First, we analyse the security characteristics of the solution and compare the security performance with other solutions, and then use Random Oracle Model and Proverif software to provide formal verification security certification for the solution.

5.1. Security feature analysis

1. Simulated attack: The enemy can pretend to be a participant in the entire conversation, such as vehicles, RSU, and VS.

   • Resist simulation attacks of vehicle: If the adversary wants to simulate a legal vehicle for authentication, it needs to calculate authentication message that $X_0,L_{OBU},Aut{h}_{OBU}$. The adversary needs to guess the real identity of the legal vehicle $I{D}_{OBU}$, the vehicle password $P{W}_i$ and also need to obtain the Smart Card of the vehicle $\{M_1,M_2\}$. If the authentication information is calculated and sent to the RSU without knowing these identity information parameters, the authentication will fail at the RSU and RSU will consider the authentication request as invalid and connect the terminal. Therefore, this solution is a good defense against simulation attacks of vehicles.

   • Resist simulation attacks of RSU: The adversary can intercept the information transmitted on the non-secure channel between the RSU and the vehicle/VS server, and pretend to be the RSU to communicate with them. When the adversary sends a message to the VS, it needs to guess the session key $K_s$ between the RSU and the VS, which will cause the verification to fail due to the wrong value of $K_s$. That will cause the verification to fail due to the wrong value of $Aut{h}_{RSU}$ when the VS server performs verification. Similarly, when the opponent sends a message to the vehicle, it needs to guess a random number $R_s$ generated by the VS server and L. These guessed values will cause the verification at the vehicle to fail.

   • Resist simulation attacks of VS: When the adversary simulates the VS to send a message to the RSU, it needs to guess the shared key $K_s$ between the RSU and the VS and the L sent by the RSU to the VS, so that the VS cannot calculate the correct $X_2,Aut{h}_{VS}$ and the verification at the RSU also leads to failure.

2. Smart card theft attack: When the Smart Card $\{M_1,M_2\}$ of the vehicle is obtained by the opponent, the adversary can use it to calculate the authentication information, but the adversary cannot know $S{K}_{OBU}$ and the password $P{W}_i$, and still cannot calculate the correct $X_0$ and $Aut{h}_{OBU}$. The first step of RSU verification is to get the correct password of the vehicle and calculate the correct L with $OB{U}_{info}$ for the next step of verification.

3. Key security: When a vehicle wants to negotiate a session key with the VS, both the RSU and VS verify the vehicle's information $L_{OBU}$ to ensure that it is valid. Vehicle at the same time will also check L and $R_s$ sent by RSU, and finally, $R_s$ and L will be used for the session Key, the session $Key=h\left(L||R_S\right)$. This ensures the security of the session key.

4. Replay attack: The proposed protocol uses timestamp $T_0,T_1,T_2,T_3$ to resist replay attacks. When the session entity receives the message, it first verifies the validity of the timestamp. In addition, it can ensure that the received timestamp is not tampered with, because the timestamp is also protected by h() function as part of the authentication parameter. Because the opponent cannot get some relevant parameters such as $X_1,X_2$, and L to calculate the correct messages such as $Aut{h}_{OBU},Aut{h}_{RSU}.$ So the validity of the timestamp can be guaranteed to resist replay attacks.

5. Man-in-the-middle attack: In order to avoid man-in-the-middle attack, each part of the session will verify each other. For example, RSU will authenticate the vehicle through $P{W}_i$ and $L_{OBU}$. VS and RSU are also authenticated by the session key $K_s$, and the vehicle authenticates the L from the RSU to ensure there is no man-in-the-middle attack.

6. Non-interactivity: The vehicle only needs to send the authentication request message once. Even in the service transport phase, the vehicles only need to submit the service access request, and they are non-interactive throughout the process.

7. Traceability and non-repudiation: The goal of the private chain of TA and RSU is to store the identity information $〈I{D}_{OBU}-HID〉$ to achieve traceability. When malicious behaviour is discovered and broadcast in the alliance chain, each TA will search for the vehicle's true identity $I{D}_{OBU}$ on its own private chain according to HID. After finding the public key, TA will revoke its public key, broadcast the result on the alliance chain, and add its real identity and auxiliary authentication message $〈OB{U}_{\mathrm{i}\mathrm{n}\mathrm{f}\mathrm{o}},M_2〉$ to the blacklist maintained by the alliance chain. When the true identity of the vehicle is revealed, its malicious behaviour cannot be denied, so the proposed scheme is traceable and uncertain. Finally we compare our security performance with other schemes, as shown in Table 2.

Table 2. Safety analysis and comparison.

–	Xiong et al. (2012)	Vasudev et al. (2020)	Xu et al. (2021)	Yao et al. (2019)	Eddine et al. (2021)	Proposed scheme
Vehicle anonymity	$\sqrt{}$	$\sqrt{}$	$\sqrt{}$	$\sqrt{}$	$\sqrt{}$	$\sqrt{}$
impersonation attack	$\sqrt{}$	$\sqrt{}$	$\sqrt{}$	$\sqrt{}$	$\sqrt{}$	$\sqrt{}$
Replay attack	$\sqrt{}$	$\sqrt{}$	$\sqrt{}$	×	$\sqrt{}$	$\sqrt{}$
Traceability and non-repudiation	$\sqrt{}$	$\times$	$\sqrt{}$	$\sqrt{}$	$\sqrt{}$	$\sqrt{}$
Data storage decentralisation	$\sqrt{}$	$\sqrt{}$	$\times$	$\sqrt{}$	$\times$	$\sqrt{}$
Session key security	$\times$	$\sqrt{}$	$\sqrt{}$	$\times$	$\sqrt{}$	$\sqrt{}$
Mutual Authentication	$\sqrt{}$	$\sqrt{}$	$\sqrt{}$	$\times$	$\sqrt{}$	$\sqrt{}$
Based on blockchain technology	$\times$	$\times$	$\sqrt{}$	$\sqrt{}$	$\sqrt{}$	$\sqrt{}$

5.2. Formal security verification using Random Oracle Model (ROM)

The following theorems are used to formally prove the security of our scheme against an adversary (Mishra et al., 2014), we define the following Oracle:

• Reveal: This oracle will unconditionally return the input m from the associated hash value $h=Hf\left(m\right)$

• Extract: This oracle will return the scalar X out of a specified point Q = XP and P

Theorem 5.1

Based on the assumption that the secure one-way hash function $\left(\right)$ acts like a random oracle and the hardness hypothesis of the ECDLP, the proposed authentication scheme is secure against an adversary A for resolution: It prevents an adversary from getting the identity of the vehicle $I{D}_{OBU},$ the vehicle key $S{K}_{OBU}$ and the TA key $S{K}_{TA}$.

Proof.

If Adversary A wants to get the identity of the vehicle $I{D}_{OBU}$, private key $S{K}_{OBU}$ and the TA key $S{K}_{TA}$, Reveal and Extract are needed to perform some operation $EXPR{1}_A^{ECDLP,HASH}\left(t\right)$ to counter the security of the proposed certification scheme. A has a success rate of $Succ{1}_A^{ECDLP,HASH}=|\mathrm{Prb}\left[EXPR{1}_A^{ECDLP,HASH}\right(t)=1]-1|$. The advantage of A is defined as $Adv{1}_A^{ECDLP,HASH}(t_e,q_{re},q_{ex})=\underset{A}{max}(\mathrm{Succ}{1}_A^{\mathrm{E}\mathrm{C}\mathrm{D}\mathrm{L}\mathrm{P},\mathrm{H}\mathrm{A}\mathrm{S}\mathrm{H}})$ [27], in which is allowed to make the maximum number of Reveal $\left({\mathrm{q}}_{\mathrm{r}\mathrm{e}}\right)$ and Extract $\left(q_{ex}\right)$ queries. In EXPR1, A calculates the information it needs by eavesdropping on the message sent by OBU to TA and using Reveal and Rxtract. Based on the above behaviour of A, if A can reverse the security one-way hash function Hf() and solve ECDLP, So A can Compute $I{D}_{OBU},S{K}_{OBU},S{K}_{TA}$. However, according to Definitions 3.1 and 3.2, this is not feasible in the calculation. As a result $Adv{1}_A^{ECDLP,HASH}(t_e,q_{re},q_{ex})<ϵ$. Therefore, the proposed authentication scheme is secure against an adversary A to derive the $I{D}_{OBU},S{K}_{OBU},S{K}_{TA}$.

Theorem 5.2

Based on the assumption that the secure one-way hash function $\left(\right)$ acts like a random oracle and the hardness hypothesis of the ECDLP, the proposed authentication scheme is secure against an adversary A for resolution: It prevents an adversary from getting the Shared key $K_s$ of the RSU and VS, Authentication message $Aut{h}_{OBU},Aut{h}_{RSU},Aut{h}_{VS}$ and Session Key.

Proof.

Adversary A wants to get the Shared key $K_s$ of the RSU and VS,$Aut{h}_{OBU},Aut{h}_{RSU}andAut{h}_{VS}$. In order to calculate these, A must use Reveal and Extract in $EXPR{2}_A^{ECDLP,HASH}\left(t\right)$ to against the security of the proposed scheme. Its success rate is $Succ{2}_A^{ECDLP,HASH}=|\mathrm{Prb}[\mathrm{EXPR}{1}_A^{ECDLP,HASH}(t)=1]-1|$ , the experimental EXPR2 algorithm is shown in Figure 7. The advantage of A is defined as $Adv{2}_A^{ECDLP,HASH}(t_e,q_{re},q_{ex})=\underset{A}{max}(\mathrm{Succ}{2}_A^{ECDLP,HASH})$,in which is allowed to make the maximum number of Reveal ($q_{re}$) and Extract ($q_{ex}$) queries. Based on EXPR2, If A can reverse the secure one-way hash function Hf() and solve the ECDLP, then A can calculate the shared key $K_S$ of the RSU and VS, $Aut{h}_{OBU},Aut{h}_{RSU},Aut{h}_{VS}$ and Session Key. However, according to Definitions 3.1 and 3.2, this is not feasible in the calculation. As a result $Adv{1}_A^{ECDLP,HASH}(t_e,q_{re},q_{ex})<ϵ$. Therefore, the proposed authentication scheme is secure against an adversary A to derive the $K_S,Aut{h}_{OBU},Aut{h}_{RSU},Aut{h}_{VS}$.

Figure 7. Proverif experiment code.

5.3. Proverif security verification

ProVerif is a formal automatic verification cryptographic protocol tool based on the Dolev–Yao model developed by Bruno Blanchet. It is implemented in Prolog language. It is able to describe a variety of cryptographic primifiers, including: shared key cryptography, public key cryptography (encryption and digital signature), Hash functions, the Deffie–Hellman key exchange protocol, specify rewrite rules and equations for the input language as applied PI calculus or Horn words. In order to verify the scheme proposed in this paper, we coded and tested the protocol with HLPSL. Figures 7 and 8 are the verification result of the Proverif. Proverif software verifies the experimental results of our scheme. It can be concluded that our scheme can guarantee the security of parameters such as vehicle password $P{W}_i$, $L_{OBU}$, $K_s$, and negotiated Key between vehicle and VS server, which cannot be captured by the opponent. All the authentication processes defined are also performed sequentially.

6. Performance analysis

In this part, we analyse the performance of the proposed scheme. We will analyse the consumption of computation, communication and storage from the three aspects. We also compare our scheme with some existing schemes. We implemented the entire authentication scheme on a single desktop device running Windows 7 Professional 64-bit version having an Intel Core i7-3537U processor with a 2.00 GHz clock and 3.7 GB memory. we evaluate the performance of our scheme with C++ under Visual Studio 2019 using the Crypto++ library.

Figure 8. Proverif experiment results.

6.1. Computaional cost

In this article, we make $T_c$ represents cost of a multiplication, $T_h$ representative for a hash operation cost, $T_{xor}$ represents the cost of XOR operation, $T_{sym}$ represents the cost of a symmetric encryption, $T_{pm}$ represent the cost of a symmetric decryption, $T_{pe}$ represents the cost of a public key encryption, $T_{pd}$ represents the cost of a public key decrypt, $T_{sig}$ is the cost of a private key signature and $T_{ver}$ is the cost of a signature verification. Assuming that the cost is the time required to perform the calculation, then a single operation needs this time, according to (Vasudev et al., 2020) we can know, $T_{sig}=2.165\mathrm{m}\mathrm{s},{\mathrm{T}}_{\mathrm{v}\mathrm{e}\mathrm{r}}\approx 4.33\mathrm{m}\mathrm{s},{\mathrm{T}}_{\mathrm{h}}\approx 0.002\mathrm{m}\mathrm{s}$, ${\mathrm{T}}_{\mathrm{x}\mathrm{o}\mathrm{r}}\approx 0.00047\mathrm{m}\mathrm{s},{\mathrm{T}}_{\mathrm{c}}\approx 0.0268\mathrm{m}\mathrm{s},{\mathrm{T}}_{\mathrm{c}\mathrm{m}}/{\mathrm{T}}_{\mathrm{p}\mathrm{m}}\approx 0.01\mathrm{m}\mathrm{s},{\mathrm{T}}_{\mathrm{p}\mathrm{e}}\approx 4.4063\mathrm{m}\mathrm{s},{\mathrm{T}}_{\mathrm{p}\mathrm{d}}\approx 7.7613\mathrm{m}\mathrm{s}$. In the mutual authentication phase of our scheme, OBU used 6h(.), RSU used 6h(.), VS used 4h(.). Because the time required for concatenation and XOR calculations was short, these operations could no longer be considered. Since the initialisation phase and the registration phase can take place earlier than the authentication phase, we also do not consider their overhead. So the total computational time cost in the whole process is:16 $T_h$. In short, our scheme is suitable for practical applications because of its low computational overhead. We can see the differences in the calculated costs of the various scenarios in Table 3. From Figure 9(a), we can see that our scheme has lower computational consumption than existing schemes and is more suitable for real-time requirements of Internet of vehicle. Although our scheme is similar to that of xu and Vasuade, our security is better than theirs.

Figure 9. (a) Comparison of computation costs. (b) Comparison of communication costs.

Table 3. Comparison of safety performance.

Scheme	OBU/vehicle	RSU	TA	VS/SM	Tocal cost	Time cost (ms)
Basudan et al. (2017)	$3T_c+T_{sig}+7T_h$	–	$3T_c+T_{ver}+4T_h$	–	$6T_c+T_{sig}+T_{ver}+11T_h$	6.6778
Vasudev et al. (2020)	$6T_h$	–	$7T_h$	$4T_h$	$17T_h$	0.034
Xu et al. (2021)	$6T_h$	$8T_h$	$6T_h$	–	$20T_h$	0.04
Yao et al. (2019)	$4T_h+\left(k+3\right)T_c$	–	–	$4T_h+5T_c$	$8T_h+\left(8+k\right)T_c$	0.034 + 0.0268k
Eddine et al. (2021)	$3T_c+3T_h+T_{pe}$	–	–	$3T_c+2T_h+2T_{pe}$	$5T_h+6T_c+3T_{pe}+T_{pd}$	21.151
Proposed scheme	$6T_h$	$6T_h$	–	$4T_h$	$16T_h$	0.032

6.2. Communication cost

The hash used by the proposed scheme is the SHA-256 algorithm, with 256 bits, timestamp is 64 bits, $I{D}_{OBU}$ and HID is 64 bits, public/private key pair is 256 bits, symmetric encryption or decrypt is 256 bits, Throughout the mutual authentication process, we sent $\{X_0,Aut{h}_{OBU},T_0,HID\},\{X_1,Auth,T_1\},\{X_2,Aut{h}_{VS},T_2\},$ $\{X_2,Aut{h}_{rsu},T_3\}$. The total number of bits is 2357. The communication cost of our agreement is shown in Table 4. It can be seen from Figure 9(b) that our scheme has obvious advantages in communication consumption, which is lower than that of the existing scheme.

Table 4. Communication costs in different stage.

Communication between nodes	Communication cost
Step 1: OBU-to-RSU	640 bits
Step 2: RSU-to-VS	572 bits
Step 3: VS-to-RSU	572 bits
Step 4: RSU-to-OBU	572 bits

6.3. Storage cost

In this part, we will calculate the storage consumption of each vehicle node in the scheme. To determine the overall consumption of each related scheme, we still adopt the following assumptions: the size of identity and random number is 64 bits, the output size of One-way hash function is 256 bits, and Elliptic points are 40 bytes.

During the registration phase of this scheme, vehicle nodes require 896 bits of storage space, because it needs to store their own public–private key $Pu{b}_{OBU}$( 320 bits), $S{K}_{OBU}$( 64 bits) and smart card $\{M_1,M_2\}$ ( 512 bits). In the vehicle authentication and key agreement phase, the vehicle node needs to store the session key( 256 bits) negotiated with the VS node. In comparison with other related solutions, this scheme is relatively small in terms of storage consumption, and vehicle nodes do not need to consume too much storage space. We can see the comparison results from Figure 10.

Figure 10. Comparison of storage costs.

7. Conclusions and future directions

In this paper, we use the multi-TA model of the Internet of Vehicles and use blockchain to propose a mutual authentication and key agreement scheme, which can be used for the communication between the vehicle and VS to provide better and more timely service for the vehicle. We use these lightweight operations Xor, hash to implement mutual authentication between entities, this allows our scheme to have lower consumption, but also easier to meet the real-time requirements of the Internet of Vehicles. The blockchain composed of TA nodes can not only facilitate the cross-TA authentication of vehicles but also improve the authentication efficiency. In order to ensure the security of vehicle identity information, that is distributed stored in the private chain composed of TA and RSU nodes in each region. It reduces the threat of information leakage brought by centralised storage and the openness of the blockchain itself. Through security analysis and simulation results of Proverif, we show that our authentication scheme is secure, and the consumption of time and communication cost of our protocol is very low. In short, our scheme can meet the real-time requirements of the Internet of Vehicles, and enable fast-moving vehicles to obtain Internet of Vehicles services, which has more practical industrial significance. In the future, we will start from two perspectives of analysing network attacks of Internet of Vehicles and authentication consumption, solving the problem of massive consumption of computation and communication after vehicle passing the first authentication.

Disclosure statement

No potential conflict of interest was reported by the author(s).