Blockchain-Based Method for Pre-Authentication and Handover Authentication of IoV Vehicles

Abstract

The Internet of Vehicles (IoV) is an important supporting technology for intelligent transportation systems that connects traffic participants, such as vehicles, pedestrians, and roads, through wireless networks and enables information exchange to enhance traffic safety and improve traffic efficiency. The IoV is a unique network that involves many network security risks, which must be controlled through authentication, encryption, and other protective measures. To solve problems, such as high computing overhead and low handover authentication efficiency of the existing vehicle access authentication of the IoV, a compact consensus pre-authentication and handover authentication method was designed based on blockchain features such as decentralization and security. The proposed method is based on ensuring authentication security and reduces the consensus time, saves computing resources, and effectively solves the problems of high computing cost and high communication cost arising from frequent vehicle authentication handovers. A performance and security analysis demonstrates that our approach can reduce the computational overhead by up to 88.14% for a vehicle and by more than 60% for a roadside unit (RSU). The overall communication overhead of the solution is reduced by up to 71.31%. The data illustrate that the proposed method can safely and significantly improve the efficiency of vehicle handover authentication.

1. Introduction

The Internet of Vehicles (IoV) has become a platform for collaborative connections between pairs of vehicles, vehicles and roads, and vehicles and pedestrians [1]. The IoV provides vehicles with traditional information services, such as navigation and entertainment, while offering related traffic safety services, such as collision warning and congestion control. The open communication environment of the IoV is susceptible to various attacks because of the lack of authentication in filtering malicious data. Malicious attackers or illegal users may take advantage of the openness of wireless communication to launch various attacks, e.g., identity impersonation, replay, and Sybil attacks, that impair the safe operation of vehicles. Therefore, to ensure the running safety of vehicles, a vehicle must send an access application containing identity information to a roadside unit (RSU) while applying for access to the IoV, where the RSU confirms the vehicle identity with a third-party certification authority before granting the vehicle network access. Therefore, it is important to explore the authentication mechanism of the IoV for user privacy protection and IoV security. Authentication plays a vital role in ensuring IoV security to prevent vehicles from illegally accessing the system [2]. IoV identity authentication can confirm the legitimacy of the identity of a vehicle applying for network access. The original authentication solution confirms the identity of all vehicles requesting access through a trusted third party and excludes illegally accessed vehicles. This solution requires even historically accessed vehicles to undergo a complete authentication operation, which is an inessential process that increases both the number of authentication steps and channel pressure.

There are currently two main types of handover authentication mechanisms for the IoV: those without and with pre-authentication. The solution without pre-authentication generally reduces the authentication overhead of all vehicles by optimizing the algorithm and authentication framework, whereas the solution with pre-authentication reduces the number of authentication steps for historically accessed vehicles by allowing RSUs to prestore vehicle information. Some researchers have introduced blockchain technology to redesign the authentication framework, thereby omitting communication between local devices and remote servers during vehicle authentication, improving the efficiency of vehicle authentication, and protecting the privacy of vehicles. However, the use of an optimization algorithm and framework cannot solve the problem of repeated authentication of some vehicles. The prestored data must be updated by a third-party organization, and the prestorage itself introduces additional security issues and authentication overhead. While the introduction of a blockchain reduces the negative impact of pre-authentication to some extent, the consensus and storage overhead brought by the blockchain must be addressed.

With the development of privacy protection, the blockchain has also been used in IoV security authentication because of characteristics such as non-tampering and decentralization. The main objective of using a blockchain to achieve handover authentication is that the RSU can prestore historically accessed information for vehicle authentication, and pre-authentication can be used to match the vehicle access data with data stored by the RSU for the vehicle before handover authentication of the vehicle, which is thereby significantly simplified. Such schemes have the advantage of eliminating the dependence of historically authenticated vehicles on remote servers, reducing the number of authentication steps and the computational and communication overhead, and improving the security of RSUs and historically authenticated vehicles. However, the high cost of storing data in the blockchain and the low efficiency of the existing consensus mechanism creates difficulties in using a blockchain for handover authentication with a pre-authentication phase, such as high consensus computation and data storage overhead and low authentication efficiency.

In this study, a blockchain-based method for pre-authentication and handover authentication of IoV vehicles is proposed to address the problems of high authentication and consensus overhead in the current vehicle authentication scenario using a blockchain. The proposed approach can reduce the computation and communication overhead of handover authentication and improve consensus efficiency by improving the consensus mechanism and introducing the pre-authentication mechanism before handover authentication. The contributions of this study are given below.

(1)

A blockchain-based handover authentication method is designed. The decentralized and non-tampering features of the blockchain ensure data security while reducing the authentication overhead.

(2)

An improved practical Byzantine fault tolerance (PBFT) consensus based on information matching is designed. Using information matching instead of cryptography to complete the consensus process reduces the computational overhead while improving the efficiency of consensus.

(3)

A pre-authentication method is introduced before handover authentication. The RSU stores information for historically accessed vehicles and reduces the computation and communication overhead of vehicles and the RSU during handover authentication by pre-authenticating the vehicles.

This paper is structured as follows. The results of related studies are presented in Section 2 to describe the state of development of the field. We summarize existing schemes and compare them with the proposed scheme to identify the ways in which our solution improves on these schemes. In Section 3, our proposed solution is presented. A consensus mechanism is introduced and used to implement the vehicle authentication solution. Experimental results and a numerical analysis of the solution are presented in Section 4. The superiority of the proposed scheme over existing solutions is demonstrated using specific experimental data. The proposed scheme is summarized in Section 5.

2. Related Works

A large number of approaches have been proposed to balance security and cost in IoV authentication. These approaches can be categorized into optimization of algorithms and frameworks for authentication and the inclusion of pre-authentication processes. Blockchain technology has been widely used to implement these approaches.

The optimization of authentication algorithms and frameworks can improve the authentication efficiency for access of all vehicles, but does not solve the problem of repeat vehicle authentication. The pre-authentication approach reduces the number of authentication steps for matching vehicles by setting reasonable conditions, but the additional pre-authentication steps increase security issues and the authentication overhead. Blockchain technology removes the reliance of vehicle authentication on remote trusted third-party servers, improves security, and considerably reduces communication and computational overhead for the authentication process. However, the data storage and execution of smart contracts in the blockchain also introduce significant computational overhead.

In an IoV system, vehicles communicate with RSUs or other vehicles through wireless networks. As described in [3], if the receiver cannot distinguish unauthorized frames between valid frames and pseudo-frames, the malicious node can disguise its identity and send the pseudo-frame to other nodes to control the vehicle. In [4], Hoppe and Dittman implemented frame sniffing and replay attacks on vehicles in a simulated vehicle network environment. In [5], the author successfully controlled a large number of modules in the target vehicle by injecting pseudo-frames. In [6], Woo et al. commanded a malicious application installed on a smartphone to implement a wireless attack in a real car environment, and successfully controlled the vehicle.

Because of the mobility of vehicles and the limited coverage of RSUs, vehicles may be connected to different RSUs at different times. To gain uninterrupted access to the networks and services provided by RSUs, the vehicles must undergo handover authentication between new and old RSUs [7]. The existing handover authentication method has poor security in the handover information interaction between the old and new RSUs, which allows the spread of false information [8]. Therefore, an efficient and safe handover authentication method is needed to address the need for frequent handovers and reduce the computing and communication overheads of vehicle authentication to achieve safe and efficient communication of vehicles in the IoV system.

When a vehicle moves from the coverage area of the current RSU to that of another RSU, the communication link of the vehicle must be changed from the current RSU to the other RSU to ensure network connection. This process is called “handover.” Although the Institute of Electrical and Electronic Engineers (IEEE) 802.11x standard supports authentication between high-speed vehicles, RSUs, and service providers, the delay of such an authentication method is too long for IoV applications [9]. Multiple handover authentication of vehicles may bring about high computing and communication overheads, which places a strain on vehicles with limited resource capacity.

In the anonymous handover authentication mode, the central server is a remote static authentication authority. All vehicles must communicate with the central server during the authentication, which may lead to heavy queuing and authentication delays. In [10], a fast handover authentication scheme based on a public key protocol was designed. After the RSU performs handover authentication on the vehicle, it only communicates the result and vehicle pseudonym information to the authentication, authorization, and accounting (AAA) server to efficiently update the vehicle pseudonym identity authentication. However, this scheme involves long communication delay between the RSU and the AAA server. Reference [11] proposed a lightweight identity authentication protocol (LIAP) suite to enable fast handover authentication with privacy protection. For the vehicle handover authentication, LIAP establishes a shared session key with the vehicle upon vehicle login to the authentication server and uses the dynamic session secret process method to improve the computing efficiency of authentication and hide the private information of the vehicle user. Reference [12] analyzed the LIAP protocol and found that it lacked privacy protection features and was thus vulnerable to impersonation attacks. It proposed a fast handover authentication protocol to protect vehicle privacy. To enhance the security of the LIAP protocol, the protocol associated the vehicle pseudonym with a random number and then encrypted the vehicle pseudonym and random number through a quadratic residue operation, thereby generating a dynamic identity that can withstand location tracking attacks; however, the scheme did not provide formal authentication.

Reference [13] proposed a pre-authentication method for fast handover authentication of vehicles. In this scheme, each RSU stores the identity of the vehicle registered on the central server. When the vehicle enters the coverage area of the new RSU, it triggers the identity matching authentication immediately to reduce the authentication delay in handover. Although the scheme offers a low authentication delay, since the authentication information of vehicles is updated only once a year, the information is susceptible to tracking and forging by malicious users.

Reference [14] proposed a distributed group key batch authentication protocol to reduce the vehicle authentication delay. To avoid group signing certificates being maintained by the central authority, the protocol allows each RSU to maintain an instant group within its communication range and manage the group signing certificates. Once a vehicle enters an RSU-managed instant group, the vehicle anonymously broadcasts its identity and is authenticated by members of the group or adjacent groups. Although the protocol reduces the vehicle authentication delay, a large number of packets are transmitted during the handover authentication. Reference [15] proposed a scalable, robust authentication protocol-based pre-authentication scheme. When a vehicle is handed over, the previous RSU first sends the certificate of successful authentication to the next RSU, then the RSU that receives the certificate authenticates the sent certificate and broadcasts the handover message to the vehicle. Finally, the vehicle that receives the message decrypts the message using the symmetric key to complete the handover authentication. This pre-authentication scheme helps reduce the computing overhead of the vehicle; however, the symmetric encryption method used is generally not suitable for IoV communication, since the vehicle must encrypt and decrypt the information of another vehicle through the RSU, thus increasing the hop count of vehicle communication.

Reference [16] proposed a group management and group handover authentication scheme of public key infrastructure (PKI) to reduce signaling overhead and authentication delay during vehicle handover authentication. However, limited by the RSU capabilities, the communication costs of handover authentication will increase as vehicle density increases. Reference [17] proposed an authentication framework that accelerates vehicle handover authentication using a type of trust value. In this framework, the cloud server evaluates each vehicle’s credit score based on its characteristics, and the RSU uses the vehicle’s credit score to authenticate the vehicle and establish session keys. When the communication range of the RSU to which the vehicle belongs changes, the former RSU sends the handover certificate to the next RSU and the vehicle. The RSU that receives the certificate sends a token to the vehicle prepared for handover, and then the vehicle and the RSU receiving the certificate calculate the corresponding session key simultaneously and establish communication for vehicle handover authentication.

For purposes of vehicle privacy protection and secure information transfer, [18] proposed a blockchain-based IoV framework system, where a secure access authentication scheme is designed between the vehicle and the RSU to reduce the dependence on the authentication authority. This provides accountability auditing against malicious vehicles and guarantees the protection of vehicle privacy; however, this scheme relies on cloud storage and consensus-generated authentication results, which involves high communication overhead and consensus delay. Reference [19] proposed a trusted scale-computing authentication scheme based on blockchain assistance to reduce the computational cost of vehicle handover authentication. With this scheme, the RSU must only determine whether the trust value of the vehicle recorded in the blockchain is consistent with that sent by its handover vehicle, thereby determining whether to directly access the handover vehicle. Reference [20] used smart blockchain contracts for vehicle handover authentication to eliminate the redundancy frequently seen in traditional handover authentication. This scheme records vehicle information through blockchain and uses smart contract to check the validity of handover vehicles for handover authentication, thereby reducing the steps and overhead of handover authentication; however, the scheme does not consider the time consumption of consensus during performance of the smart contract. Reference [21] takes advantage of the immutability and consistency of blockchain data to propose an anonymous authentication scheme based on blockchain to achieve fast handover authentication of vehicles. This scheme only requires an RSU to check the block number and determine whether the corresponding credential is correct, thereby determining whether to access the handover vehicle; however, this scheme does not consider the time consumption of consensus in blockchain, and there is a large communication overhead.

Thus, a large number of approaches have been proposed to balance security and cost, and the introduction of blockchain has solved one aspect of the failure problem and reduced the number of authentication steps. However, problems remain in this research area: the consensus overhead of a blockchain is not negligible and many blockchain-based approaches increase overhead while guaranteeing security. Our approach minimizes the cost of authentication while ensuring security.

3. Pre-Authentication and Handover Authentication Methods for Vehicles

When a vehicle is moving, it is connected to different RSUs along its route, so it must be handed over between RSUs. To guarantee the IoV communication quality during rapid vehicle motion, vehicles need an efficient handover authentication method to minimize communication interruption caused by the handover. In this study, a blockchain-based vehicle pre-authentication and handover authentication method is designed by virtue of the decentralized and security characteristics of blockchain: RSUs are based on the blockchain technology to achieve synchronization between vehicle authentication consensus and authentication information, thereby realizing fast authentication and efficient vehicle handovers.

3.1. Basic Architecture

When a vehicle is moving, it is supported by different RSUs at different time nodes. In addition, based on the intensive deployment of RSUs, vehicles are handed over frequently between RSUs. To solve problems such as high computing overhead and prolonged communication resulting from frequent access authentication with RSUs during vehicle motion, a blockchain-based vehicle pre-authentication and handover authentication method is proposed by virtue of the decentralization and data-tampering resistance of the blockchain. The overall architecture is shown in Figure 1.

The IoV system packages the vehicle’s identity, pre-authentication, historical handover, and other information into blocks and maintains them in the blockchain. The network nodes jointly maintain this vehicle information. RSUs deployed on roadsides have certain computing and storage capabilities; thus, they are suitable for complex cryptographic operations and data storage. The individual RSUs are interconnected via an internal network. Therefore, the blockchain nodes are deployed in RSUs, which participate in consensus and store complete block data. The computing and storage resources of vehicles are relatively limited: they carry only identity information, basic algorithms, keys, and other basic information for authentication with the system. Therefore, vehicles do not participate in the maintenance and operation of the blockchain system.

The history information of vehicle handover is collected and subjected to consensus by the RSUs that the vehicle passes. With reference to the collected information, RSUs work with the blockchain consensus mechanism to verify the vehicle’s identity and maintain the information concerning the authentication result through the distributed storage of blockchain based on the tamper protection of data to ensure the immutability, consistency, security, and nonrepudiation of the authentication results. Since vehicles do not participate in the consensus, there is no additional computing or communication overhead for vehicles.

Handover certification occurs when a vehicle leaves the previous RSU coverage area and enters that of the new RSU. To minimize the computing and communication overheads of re-authentication during vehicle handover, the vehicle is pre-authenticated. By means of blockchain consensus, the pre-authentication ensures the correctness, consistency, and immutability of the pre-authentication results. An overview of the vehicle pre-authentication and handover authentication processes is given in Figure 2.

3.2. Vehicle Access Authentication Process

When a vehicle is initially connected to the system, the system contains no authentication history record of the vehicle, nor can it pre-authenticate the vehicle. Therefore, the vehicle must undergo normal access authentication with an RSU to establish a mutual-trust relationship and access the system. The access authentication process is described as follows.

(1)

When vehicle A applies for access to an RSU, it listens to the current RSU broadcast of its own identity information ID_RSU and sends the ID_RSU of the RSU, location information L_RSU, and its own identity identification (virtual IoT device A (VID_A)) to the authentication center of the system for authentication of the RSU identity; the relevant information is encrypted with the public key pubsys of the authentication center.

req = Enc_pubsys (ID_RSU, L_RSU, VID_A, ts, Hash (ID_RSU, L_RSU, VID_A, ts))

(1)

Upon receipt of the message, the authentication center of the system uses its own private key to decrypt the message, thereby obtaining the vehicle identification and the RSU information to be verified. Secondly, the system checks timestamp ts to prevent replay attacks;

ΔT ≥ time_now − ts? T

(2)

If the above inequality is true, the message is valid. ΔT represents the maximum time interval defined in advance, and time_now denotes the time when the system receives the message. The message hash is calculated to check if the message has been tampered with. If the vehicle identification is already in the registered device library, it means that the vehicle is legally registered and the RSU validity is verified. Since RSUs register their own information into the system during the system initialization, coupled with the fact that RSUs are relatively fixed, the system can verify the validity of the RSUs. If the RSU is valid, the system replies with the reply message with authentication result “true.” Otherwise, it replies with “false”.

Upon receipt of the message of RSU validity, the vehicle generates an initial authentication message, where Num_block represents the block number of the vehicle identity information and “Time” denotes the timestamp; additionally, the message is signed with the private key pria of vehicle A.

verify = (Num_block, VID_A, Time, Sign_pria (Num_block, VID_A, Time))

(3)

Vehicle A uses the RSU’s public key to encrypt the verify message and sends the encrypted message to the RSU for access authentication.

After decrypting the message using its own private key, the RSU first verifies its signature to determine whether the authentication message is complete. Then, the RSU queries whether Num_block exists in the blockchain network, and if it does, the RSU looks at the details of the block and determines whether the vehicle is legal with reference to the identity information in the block.

If all the above steps are correct, the RSU will formally allocate the relevant resources and negotiate the session key with legal vehicle A to establish a secure channel. Otherwise, the RSU will disconnect from the vehicle. Additionally, the RSU temporarily stores the authentication information of vehicle A to verify the validity of the vehicle identity handover during pre-authentication. The authentication information includes the location, time, and speed of vehicle A’s access for current authentication.

3.3. Consensus Mechanism between RSUs

The existence of the consensus mechanism enables secure and reliable pre-authentication results among semi-trusted RSUs, and makes all RSUs agree on the pre-authentication results. Due to the open wireless network environment of telematics, there are problems such as tampering information, single point of failure, and downtime in the consensus RSU set, which makes some nodes in the RSU set unable to submit authentication messages, and thus they cannot reach a consensus authentication result. Therefore, all RSUs form a Byzantine fault-tolerant system that can be used to perform consensus pre-authentication of vehicle identities using a practical Byzantine fault-tolerant algorithm (PBFT).

However, PBFT uses a three-stage approach for communication consensus, and its consensus efficiency decreases with the increase of the number of consensus nodes, which is not conducive to the efficient complete consensus pre-authentication in the IoV scenario. In this paper, we improve PBFT according to the characteristics of a handover authentication scenario and design a compact consensus pre-authentication mechanism. The consensus no longer adopts complex cryptography for identity authentication. Instead, the historical RSU passed by the vehicle is mathematically calculated to determine whether the geographic location or trajectory information of the vehicle is reasonable, so as to determine whether the vehicle moves from the historical RSU to the pre-authentication location and provide identity endorsement for its legitimate handover vehicles.

Handover certification occurs when a vehicle leaves the previous RSU coverage area and enters that of the new RSU. To minimize the computing and communication overheads of re-authentication during vehicle handover, the vehicle is pre-authenticated in this study. Blockchain consensus is used to pre-authenticate the handover vehicle identity to ensure the correctness, consistency, and immutability of the pre-authentication results. Its basic flow design is shown in Figure 3.

(1)

When vehicle A finds that the signal intensity of the surrounding RSUs gradually increases while the signal of the currently connected source RSU is decreasing, the vehicle sends a pre-authentication request message to the source RSU. In this message, VID_A represents the vehicle identification; V_A represents the current speed of the vehicle, which is used to make a judgment on the authenticity of the vehicle at consensus; HL_A is a collection of historical RSU information that vehicle A passes through in a predefined time interval, including the location of the historical RSU, the identification of the historical RSU, and the information of vehicle A’s successful authentication at the historical RSU (such information is also available for other RSUs’ pre-authentication consensus on vehicle identity); T₁ represents the timestamp; and S₁ represents the digital signature for the pre_auth message from vehicle A with its private key.

pre_auth = (VID_A, V_A, HL_A, T₁, S₁)

(4)

(2)

When the source RSU receives the pre-authentication message pre_auth, it checks the timestamp to prevent replay attacks and then verifies the integrity of the message; finally, it pre-authenticates consensus on the handover vehicle. During the pre-authentication consensus, the source RSU first selects a node among consensus nodes as the master node of consensus, and its selection equation can be defined as:

N = (b + c) % n

(5)

where b represents the number of blocks in the current blockchain, c represents the number of nodes participating in the consensus when the number of blocks is b, n denotes the number of nodes participating in the present consensus, % is the remainder of the operation, and N is the serial number of the chosen master node. The source RSU then sends a consensus request to master node N, as follows:

con_request = (request, VID_A, V_A, HL_A, T₁, L_S, S₂)

(6)

con_request = (request, PID_A, V_A, HL_A, T₁, L_S, S₂) This consensus request includes an additional request header based on pre-authentication request pre_auth to indicate the phase of the consensus. The con_request message also contains additional information, including the location information L_S of the source RSU and the signature S₂ of the source RSU of the con_request message.

(3)

Upon receipt of the message, the master node verifies the correctness of signature S₂ and then determines whether the nodes in HL_A exist in the neighbor table of the master node. If the nodes in HL_A exist in the neighbor table, the pre_prepare message will be constructed and broadcast to the nearby consensus RSUs along the road; the header of the pre_prepare message is changed to pre_prepare, and the original signature is replaced with master node signature S₃. The format is as follows:

pre_prepare = (pre_prepare, VID_A, V_A, HL_A, T₁, L_S, S₃)

(7)

(4)

Upon receipt of the pre_prepare message, the other historical RSUs verify that the signature is correct and then verify the vehicle’s identity. If the authentication is passed, the con_commit message will be broadcast; otherwise, the prepare message will be constructed and broadcast to the consensus RSUs near the road.

To authenticate the vehicle, the RSU confirms whether the vehicle VID_A corresponding to the historical RSU in HL_A exists in its own authentication history information and then determines whether other RSU information in HL_A is true, so as to determine the authenticity of the vehicle A and RSU. The historical RSUs are allowed to determine whether the vehicle really traveled from the historical RSU to the requested pre-authentication location based on the relationship of vehicle speed, travel time, and the distance between the vehicle and the RSU, thereby determining the validity of the vehicle identity.

The vehicle speed obeys the standard Gaussian distribution [22]:

$$V_A\sim N(0,{\sigma }_A^{2}t)$$

(8)

where ${\sigma }_A^2$ is the variance:

$${\sigma }_A^2=[({(V_A-V_A^{T_0})}^2)/(T_1-T_0)]$$

(9)

where T₀ is the time that vehicle A is successfully authenticated at this RSU, and $V_A^{T_0}$ represents the speed of vehicle A at time $T_0$. Then, the distance ∆D_A that vehicle A traveled relative to the historical RSU during the time period T₀ to T₁ is:

$$\Delta D_A=(V_A{V}_A^{T_0}+\Delta V_A^{\Delta T})\Delta T$$

(10)

where ?T denotes the time period from T₀ to T₁, and $\Delta D_A$ represents the rate of vehicle change in period ∆T. According to the linear combination principle of Gaussian distribution, it is known that:

$$\Delta D_A\sim N(0,{\delta }_A{}^2\Delta T^3)$$

(11)

$\Delta D_A{}^{\Delta T}\sim N(0,{\delta }_A{}^2\Delta T^3)$ This helps determine whether vehicle A has actually traveled from the historical RSU to the source RSU. If vehicle A actually travels from the historical RSU to the source RSU and the vehicle is authenticated successfully at the historical RSU, the historical RSU will broadcast the con_commit message containing authentication result T; otherwise, only the prepare message will be broadcast. Only the header of the received pre_prepare message is changed to prepare; the remainder remains unchanged. The header of the con_commit message is commit, Re_i represents the authentication result of the $i$ RSU for vehicle A, and S₄ denotes signature of the broadcast RSU on the con_commit message. The format is as follows:

con_commit = (commit, VID_A, V_A, HL_A, T₁, Re_i, S₃, S₄)

(12)

(5)

Other RSUs that have not authenticated vehicle A will verify that the signature of the master node in the received prepare and con_commit messages is the same as that in the received pre_prepare message to prevent the master node $N$ selected by the source RSU from being malicious. If there are 2F messages with the same signature, where F is the number of down or malicious RSUs during the consensus process, the RSU will broadcast the con_commit message containing the authentication result whose Re_i is null and request the source RSU to replace the master node to prevent malicious nodes from affecting the pre-authentication result.

(6)

After receiving 2F + 1 con_commit messages, the master node performs consensus view statistics on the Re_i of its own vehicle authentication results with those of other RSUs to confirm the validity of the vehicle identity.

As shown in

Table 1. Node view statistics.

Consensus Node	Self-Authentication Result Rei	Commit View	Consensus View
Historical RSU1	T	[null, T, T, null]	[T, T, T, null]
Historical RSU2	T	[T, null, T, null]	[T, T, T, null]
Historical RSU3	T	[T, T, null, null]	[T, T, T, null]
Historical RSU4	null	[T, T, T, null]	[T, T, T, null]

, assuming that vehicle A only passes through three historical RUSs, i.e., RSU1, RSU2, and RSU3, these historical RUSs determine the authorized information of the vehicle after receiving the prepare message, and they set Re_i to T. Since the vehicle did not pass through historical RSU4, the Re_i result of the historical RSU4 is null. When historical RSU1 is the master node, among the received con_commit messages, only the pre-authentication result of historical RSU4 for vehicle A is null; hence, the updated view of RSU1 indicates at least $2F+1$ Re_i results that are true. Therefore, historical RSU1 will consider the identity of the handover vehicle to be valid and construct a con_reply for the source RSU. The message header of con_reply is reply, Re_i is changed to the consensus view result of the master node, and S₅ denotes the signature of the RSU for the con_reply message. The format is as follows:

con_reply = (reply, VID_A, V_A, HL_A, T₁, Re_i, S₅)

(13)

(7)

The source RSU receives a con_reply message indicating that a pre-authentication consensus has been reached, and it will generate a block of pre-authentication results and add it to the blockchain. The pre-authentication result block includes the identification and result information of the pre-authenticated vehicle, the consensus node set information, and the consensus view, as shown in Figure 4.

To reduce the computing overhead of re-authentication for vehicle A during the handover, the source RSU communicates the number of the pre-authentication result block to vehicle A and encrypts the message with vehicle A’s public key. Meanwhile, the source RSU sends the authentication information to the possible target RSU so that the target RSU can prepare relevant connection resources in advance.

3.4. Vehicle Handover Authentication Process

When a vehicle is about to leave the currently connected RSU and intends to access another RSU, the handover authentication is initiated. During the handover authentication, the RSU does not perform complex cryptographic verification for vehicle authentication, but performs simple information matching.

First, handover vehicle A sends the source RSU the VID_targetRsu message that verifies the authenticity of the target RSU. Upon receiving the message, the source RSU verifies the authenticity of the target RSU through the neighbor table and sends the result to the handover vehicle. Then, the handover vehicle sends the target RSU a handover authentication message (Num_block, ts, VID_A) containing the pre-authentication result block number Num_block, the timestamp ts, and the vehicle identification, and encrypts it using the public key of the target RSU. The target RSU receiving the message decrypts it with its private key and then judges the validity of the timestamp ts to prevent replay attacks: if the timestamp is valid, the block generation timestamp, the pre-authenticated vehicle identification VID_A, and the pre-authentication result are obtained on the blockchain through Num_block. Then, the target RSU determines whether the vehicle identification of the handover authentication message is consistent with the pre-authenticated vehicle identification in the block. If consistent, it is necessary to determine whether the time difference between the block generation time and the current time suits the timeliness of the pre-authentication result. If so, the pre-authentication result is considered valid. Finally, the RSU decides whether to access the handover vehicle based on the pre-authentication result of the block and completes the handover authentication of the vehicle. The handover authentication process is shown in Figure 5.

4. Analysis and Authentication

4.1. Security Analysis

The method proposed in this study stores the pre-authentication results and vehicle identity information in the blockchain to ensure that these items can be queried by means of traceability. Since the pre-authentication information contains the signature encrypted by the private key of the vehicle, the vehicle cannot deny the pre-authentication behavior during communication. Because the result of pre-authentication is derived from the consensus of the RSU nodes, and the block generated by the consensus contains the information of the consensus nodes and their consensus view, while the block is immutable, the RSU cannot deny the pre-authentication result.

The pre-authentication result is obtained after the consensus nodes in the blockchain reach a consensus on the handover vehicle identity. Attackers who attempt to generate a block with forged identity information for handover authentication must break the consensus mechanism of the blockchain. Since each block is associated with the hash value of the previous block, those who want to change a block must change all the blocks behind the target block. Since this is considered impossible, it is impossible for an attacker to perform vehicle handover by forging the pre-authentication result.

In the pre-authentication phase, the RSU that receives the pre-authentication request determines whether the interval between the current time and the pre-authentication request time exceeds the predefined time limit to avoid replay attacks. During the handover authentication, the RSU checks not only the timestamp of the handover authentication message but also whether the interval between the generation time of the pre-authentication result block and the current handover authentication time is outside the predefined pre-authentication time limit. Therefore, malicious vehicles will not be authenticated if they resend messages that have lost their timeliness.

The RSUs participating in the consensus determine whether the real geographic location or trajectory information of the vehicle is reasonable through mathematical calculation (thereby determining whether the vehicle has really moved from the historical RSU to the pre-authentication location) and provide identification endorsement for the legal handover vehicle. Malicious vehicles have no real geographical location and trajectory information, so they cannot pass the pre-authentication consensus phase before authentication; therefore, they cannot occupy channel resources and affect the normal handover of legitimate vehicles.

4.2. Performance Analysis and Verification

The computational overhead refers to the time consumed to complete the authentication. To facilitate comparative analysis with other schemes, it is assumed in this method that the execution time for a bilinear mapping is $T_{bp}$, $T_h$ is the execution time for a hash function, $T_{\exp }$ is the execution time for a modulo-power operation, $T_{mul}$ is the execution time for a point multiplication operation, and $T_{add}$ is the execution time for a point addition operation.

In the calculation related to elliptic curves, $T_{enc}$ is the execution time of encryption, $T_{dec}$ is the execution time of decryption, $T_{sign}$ is the signature time, and $T_{ver}$ is the verification time.

Table 2. Comparison of computational overhead.

Method	Computational Overhead for Vehicles	Computational Overhead for RSU
Kim, J. 2012 [15]	$3T_{\exp }+2T_h$	$2T_{bp}+2T_{\exp }+T_h$
BBAAS [21]	$T_{bp}+T_h$	$2T_{bp}+T_{mul}+T_h$
ECPP [23]	$4T_{mul}+T_{bp}+2T_{add}+T_{\exp }$	$3T_{bp}+T_{mul}+T_h+T_{\exp }$
Zheng, D. 2019 [24]	$2T_{mul}+2T_h+2T_{add}+T_{\exp }$	$2T_{bp}+3T_{add}+5T_h$
Proposed	$T_{sign}$	$(2n+1)T_{ver}+(n+2)T_{sign}$

compares the computational overhead of the vehicle and RSU during the authentication process in each solution. For the authentication of a single package, the computational overhead of the vehicle in [23] is 7.25 ms; in [15] is 1.598 ms; in reference [24] is 1.266 ms; in [21] is 5.344 ms; the computational overhead of the vehicle in our scheme is 0.86 ms. Thus, the computational overhead of the resource-constrained vehicle in our solution is lower than blockchain-based literature [21] by 83.91%, 32.07% than the literature [24] solution, and up to 88.14% lower than other non-blockchain-based authentication solutions. The relationship between the computational overhead of the vehicle and the number of messages during the pre-authentication process is shown in Figure 6.

We compared the computational overhead of the target RSU in the handover authentication phase. For the target RSU, the computation overheads of the five schemes show a linear growth trend with the increasing number of handover messages. References [23,24] do not use pre-authentication for handover authentication, so the computational overhead of the target RSU is 16.88 ms and 10.814 ms, respectively. Only [15,21] and this paper use pre-authentication for fast handover authentication. In reference [15], one symmetric encryption and two elliptic curve point multiplication operations are required for handover authentication, so the computational overhead of the target RSU in reference [15] is 0.652 ms. In [21], the computational overhead of the target RSU is 5.67 ms. In this paper, the target RSU only needs to perform one elliptic curve decryption for handover authentication of the vehicle, and its computational over-head is 0.364 ms. Therefore, the scheme in this paper can reduce the computational load of the target RSU, improve the ability of the target RSU to handle vehicle handover, and can be better applied to the IoV handover authentication scenario. Comparison of the computational overhead of the target RSU in the handover authentication phase is shown in Figure 7.

In the process of single vehicle pre-authentication, the computational overhead of RSU in reference [23] is 16.88 ms, the computational overhead of RSU in reference [15] is 11.744 ms, the computational overhead of RSU in reference [24] is 10.814 ms, the computational overhead of RSU in reference [21] is 11.01 ms. In our solution, RSU uses consensus to pre-authenticate the vehicle, and its computational overhead depends on the consensus process. In the case of four consensus nodes, the total computation overhead of our solution is 17.67 ms, which is slightly higher than the other four solutions. Although this scheme increases the total computation overhead of RSUs in the pre-authentication process, the average computation overhead of a single RSU is 4.4175 ms, which is still lower than the other four authentication schemes. In addition, the pre-authentication operation is completed before the vehicle handover, which does not affect the efficiency of vehicle switching. The relationship between the computation overhead of RSU and the number of messages during pre-authentication is shown in Figure 8.

The communication overhead refers to the size of the message sent by the vehicle during the handover authentication phase and is expressed in bytes. The communication overheads of the five solutions are shown in

Table 3. Comparison of communication overheads.

Method	Overhead of a Single Handover Authentication Message/Byte
Kim, J. 2012 [15]	474
BBAAS [21]	256
ECPP [23]	289
Zheng, D. 2019 [24]	680
Proposed	136

.

Among the five solutions, our solution reduces the communication overhead by 46.88% compared to the blockchain-based reference [21], and its communication overhead is reduced by 71.31% compared to [15]. Therefore, the pre-authentication solution in this paper is able to reduce the communication overhead of the vehicle during the switching authentication process.

The communication overhead of handover authentication is linearly related to the number of authentication messages. It can also be concluded that our pre-authentication solution in this paper has a lower communication overhead than other similar solutions. The communication overhead comparison is shown in Figure 9.

The commonly used practical Byzantine fault tolerance (PBFT) consensus algorithm principally involves three phases, i.e., pre-preparation, preparation, and commit. Assume that the number of nodes participating in the consensus is n. During the pre-preparation, the master node broadcasts pre-prepare messages to other nodes, and the communication count is n − 1. Each node must broadcast the prepare and commit messages to other nodes again during the preparation and the commit phases; therefore, the number of communications in both phases is n* (n − 1), so the total number of communications C_PBFT of the PBFT is:

C_PBFT = 2n² − n − 1.

(14)

In the present consensus algorithm, the historical RSUs of the vehicle have stored the authentication information of the vehicle as they can provide the endorsement for the pre-authenticated vehicle identity in the consensus process, which helps reduce the consensus communication. Assuming that each RSU can provide endorsement for the pre-authenticated vehicle identity, the consensus algorithm can reduce the three phases to two phases; that is, only the pre-prepare and con_commit phases are included. The total communication count C is:

C = n² − 1.

(15)

The communication count of the PBFT algorithm is compared with that of the consensus algorithm, and the count ratio R is the following:

R = (2n² − n − 1)/n² − 1

(16)

In summary, with the increase in consensus nodes, the communication efficiency of this consensus process is half that of PBFT. Hence, the proposed consensus algorithm can remarkably reduce the communication overhead of the consensus process.

Computer software was used to simulate and implement a small blockchain experiment system, where the authentication mechanisms based on the consensus algorithm proposed in this study and the PBFT algorithm were simulated and compared in terms of consensus time. The results are shown in Figure 10. According to the experimental results, the efficiency of the proposed consensus algorithm is better than that of the PBFT algorithm. Additionally, with an increase in consensus nodes, the gap of authentication efficiency between the proposed consensus algorithm and the traditional PBFT algorithm progressively widens.

5. Conclusions and Prospects

Aiming at the problem of high computing and communication overheads arising from frequent handover authentication of vehicles, this study designed a vehicle pre-authentication and handover authentication method based on blockchain, in which each vehicle completed the authentication operation before handover authentication, and the consensus algorithm was optimized. To ensure authentication security, the pre-authentication and handover authentication reduced consensus time, saved computing resources, and remarkably improved the operation efficiency of the IoV system. Nevertheless, the overall computing overhead in the pre-certification phase was positively correlated with the number of nodes participating in the consensus. Future study will further optimize and improve the pre-authentication consensus process to reduce the computing overhead in the pre-authentication phase.