Internet of Things 22 (2023) 100728

Contents lists available at ScienceDirect

Internet of Things
journal homepage: www.elsevier.com/locate/iot

Research article

An in-situ authentication with privacy preservation scheme for

accident response in Internet of Vehicles
Xiaofan Liu a,b , Weihui Qiu a , Wei Ren a,b ,∗, Caixu Xu b ,∗∗, Kim-Kwang Raymond Choo c
a School of Computer Science, China University of Geosciences, Wuhan, 430074, China
b Guangxi Key Laboratory of Machine Vision and Intelligent Control, Wuzhou University, 543002, China
c
Department of Information Systems and Cyber Security, University of Texas at San Antonio, San Antonio, TX 78249-0631, USA

ARTICLE INFO ABSTRACT

Keywords: Real-time monitoring and handling of traffic in large urban cities, remains challenging due to
Blockchain a broad range of technical and non-technical factors. For example, while real-time incident
Ring signature reporting with supporting data (e.g., images or video feeds) can inform decision-making
Smart contract
and facilitate traffic control, there are operational challenges (e.g., bandwidth and security).
Internet of Vehicles
Hence, we propose an identity authentication and privacy preservation scheme based on both
Privacy preservation
blockchain and ring signature. Specifically, in our approach, blockchain is leveraged to maintain
anonymity yet guaranteeing traceability. We also design a new ring signature scheme based on
the SM2 algorithm and analyze its security. To demonstrate utility, we evaluate our proposed
approach using Ethereum smart contracts, and the findings demonstrate that our approach is
efficient, supports privacy preservation, and is resilient to a range of common attacks.

1. Introduction

As cities become ‘smarter’ and more interconnected with other entities and systems (e.g., autonomous vehicles and other Internet
of Things (IoT)), ensuring both security and privacy (with conflicting priorities and expectations) will be increasingly challenging.
For example, an autonomous vehicle supported by other IoT systems and onboard devices (collectively referred to as Internet of
Vehicles (IoV)) is generally capable of capturing and recording data about the surroundings and sharing such information with other
entities and systems in real-time. Not surprisingly, understanding and mitigating the various security risks have been the subject of
ongoing research [1,2]. For example, in the context of a smart intelligent system comprising a traffic control center (TCC), some
roadside units (RSUs), and smart vehicles (with Internet-connected onboard units), communications can take place over wired or
wireless connections, as well as Bluetooth, mmWave, and dedicated short range communication (DSRC). In such a setting, smart
vehicles can share and upload various data such as road traffic situation to the TCC. However, in the event of an accident (e.g.,
while driving under the influence of drugs or alcohol), the party involved may choose to omit certain information or inject fake
data to avoid penalty or prosecution. This reinforces the importance of ensuring the authenticity and integrity of data sent to the
TCC, while also ensuring the privacy of vehicles.
In this paper, we propose an authentication and privacy preservation scheme that consists of two building blocks, blockchain
and ring signature. To minimize the risk of misuse (e.g., revenge taking or retaliation), we use blockchain. Ring signature is used
to protect vehicle privacy since any member of the ring is allowed to sign on behalf of all members of the ring. A summary of our
approach in this paper is as follows:

∗ Corresponding author at: School of Computer Science, China University of Geosciences, Wuhan, 430074, China.
∗∗ Corresponding author.
E-mail addresses: weirencs@cug.edu.cn (W. Ren), mvic.cxxu@gmail.com (C. Xu), raymond.choo@fulbrightmail.org (K.-K.R. Choo).

https://doi.org/10.1016/j.iot.2023.100728
Received 10 October 2022; Received in revised form 14 February 2023; Accepted 14 February 2023
Available online 3 March 2023
2542-6605/© 2023 Elsevier B.V. All rights reserved.
X. Liu et al. Internet of Things 22 (2023) 100728

• We provide a method for identity identification and privacy protection based on ring signatures and the blockchain that can
automatically handle traffic accidents and effectively maintain privacy.
• We create a ring signature system based on the SM21 digital signature, which is then used to conceal the identity of the vehicle
in IoV. We also formally evaluate the proposed signature scheme’s security.
• We demonstrate how to leverage a smart contract on the Ethereum blockchain to facilitate identity authentication. We also
show how employing RSU nodes as the blockchain’s nodes and the intermediary layer between a vehicle and a server enhances
those operations while reducing server overhead.

The rest of the paper is organized as follows. In the next section, we will briefly review the related approaches. Section 3
introduces the system and adversary models. Section 4 describes our proposed approach, followed by the associated security analysis.
We then explain our evaluation setup and discuss the findings in Section 5. Section 6 concludes our work.

2. Extant literature

Vehicle networks, such as vehicular ad hoc networks (VANETs), vehicular wireless networks (VWN), the Internet of Vehicles
(IoV), and smart driving vehicles (SDV), have been intensively studied. IoV-related research is mostly introduced in this section.
The IoV can be seen as the evolution of VANET, which originated from the Mobile Ad-hoc Network (MANET), which is a flexible
and complex network system consisting of numerous vehicles and small networks. IoV is able to integrate cutting-edge technologies
like federated learning, cloud computing, edge computing, and big data since it has a more powerful computational capacity and
reduced latency. Lu et al. [3] proposed a new federated learning-based architecture, which reduces the transmission load, solves the
provider’s privacy issue and improves the reliability and efficiency of data sharing. Feng et al. [4] investigated a distributed vehicle
edge computing solution, called Autonomous Vehicle Edge (AVE) to share the available resources of adjacent vehicles through V2V
communication.
The relationship between the blockchain and the IoV has substantially improved in recent years, and the blockchain is frequently
utilized as a platform for trusted databases or data exchanges. Xu et al. [5] designed a protocol based on blockchain used to
authenticate and key agreement, which reduces the amount of computations and improves the efficiency of verifying. Additionally,
blockchain can be utilized to manage numerous Trusted Authorities (TAs) that store car data, making it simple for vehicles to
successfully complete cross-TA authentication. Gong et al. [6] introduced a method based on blockchain to complete data transaction
on IoV. Besides, they also proposed a blockchain-based data transaction framework to improve the efficiency of data transactions.
Zhang et al. [7] constructed a blockchain-based secure data sharing system which uses the blockchain to store announcement
messages. In order to encourage more vehicles to participate in, they ruled that honest and active vehicles will be rewarded by
cryptocurrency.
In terms of identity authentication combined with blockchain, Wang et al. [8] designed an effective distributed authentication
scheme on IoV based on the consensus algorithm of blockchain. Sharma and Chakraborty [9] constructed a new blockchain-
based architecture for seamless access control for vehicle authentication and privacy preservation, which also supports an optional
traceability feature.
There are many studies combined smart contract and IoV. In order to reduce the number of traffic accidents and improve the
efficiency of urban traffic, Chen et al. [10] designed a platoon-driving model for autonomous vehicles in a free-flow traffic state,
the model use smart contract to enable the payment based on blockchain. Singh et al. [11] proposed that the blockchain can be
sliced to decentralize the load on the main chain to each small piece, while also increasing the processing speed of blockchain.

3. Problem formulation

In this section, we introduce the system model and adversary model of our scheme.

3.1. System model

Traffic accidents cannot be prevented, even in a smart city, because the flow of traffic is unpredictable and dynamic. Let us
say the accident occurs, and we label it as Fig. 1. We propose a blockchain-and-ring-signature-based authentication and privacy
preservation strategy to effectively manage the collision and safeguard the privacy of all involved cars. To finish the automated
processing of traffic incidents, we apply this technique to a hypothetical accident. In this case, the blockchain (smart contract), the
TCC, the RSU, and the vehicle play the first four roles in the plan.
Blockchain is envisioned in our scheme as a database. Here, we establish a private chain using Ethereum since it has benefits
including faster transaction speeds, reduced transaction costs, greater resistance to assaults by malevolent nodes, and better privacy
preservation due to its anonymity. We create smart contracts for each function in order to accomplish the numerous functions among
all the sections. After smart contracts have been developed, they will be made available for use in this blockchain network.
All vehicles and RSUs participating in the scheme must be registered at TCC, a trusted traffic control center. The TCC is in charge
of handling car accidents.

1 SM2 is an elliptic curve public key cryptography algorithm released by the State Encryption administration of China https://www.oscca.gov.cn/sca/xxgk/

2010-12/17/content_1002386.shtml

2
X. Liu et al. Internet of Things 22 (2023) 100728

Fig. 1. A typical accident scenario and communication diagram.

Fig. 2. System architecture diagram.

RSU is an IoV node that is deployed along the side of the road and is in charge of managing communications between vehicles
and the network. Additionally, each RSU serves as a node on our private chain, which is in charge of maintaining the blockchain
and packaging blocks. A wired network connecting RSU and TCC ensures the transfer speed.
In our proposed scheme, vehicles represent a sort of mobile node. Each vehicle includes a smart camera and many sensors, enough
processing capacity to gather and process data from the host, and it communicates wirelessly with the RSU over short distances.
Nearby automobiles are split into two groups during traffic accidents: accident vehicles and witness vehicles. While witness vehicles
transmit their reporting message to the closest RSU, accident cars upload the relevant accident parameters to that RSU. RSU organizes
and sends the data from both types of cars to TCC. All of these cars use ring signatures to conceal their genuine identities so that
no other character can determine them, protecting the privacy of witness and accident vehicles.
Fig. 2 depicts the scheme’s system architecture, which is broken up into three levels from bottom to top. Support for data,
including blockchain and relational databases, is the bottom layer. The blockchain maintains transaction information, whereas the
database stores information about vehicles and accidents. The tools, such as smart contracts and cryptography, are what make up
the middle layer. Smart contracts are utilized for automated processing, and encryption safeguards privacy. The application, which
makes up the top layer, describes the features of the system, such as authentication, accident adjudication, incentives, data archiving,
and privacy protection.

3.2. Adversary model

A complete protocol can not only accomplish the established goals but also be able to resist common attacks. The following
statements are common attacks against the system model:

1. Insurance Fraud. Suppose malicious users  and  collude with each other and lie together about a car accident (either 
crashes  or  crashes ) to defraud insurers.

3
X. Liu et al. Internet of Things 22 (2023) 100728

2. Perjury. Suppose a car accident happened between user 𝑖 and user 𝑗 (user 𝑖 and user 𝑗 are all authenticated system users), a
malicious witness  submit a fake accident analysis or other non-significant message to interfere the final accident treatment.
3. Tracing Attack. Tracing attack is that the privacy of the witness vehicles and the accident cars is leaked. Or, mailicious users
can impersonate identity of other users to submit the fake message.
4. RSU Attack. Suppose a RSU held by an adversary . The attacked RSU either does not communicate with cars or TCC when
the accident happens nearby (which is called ‘‘Offline’’) or transit the meaningless information repeatedly.

However, the scheme we proposed can resist all the attacks on the above perfectly, and the detailed security analysis will be given
in Section 4.5.

4. Proposed scheme

This section focuses on the paper, where we propose the authentication and privacy preservation scheme. The basic setting,
including the hash algorithm and digital signature algorithm, will be introduced first. The second will cover the ring signature
algorithm we developed based on the SM2 digital signature. The third will show the blockchain and the smart contract design in
our scheme. The final subsection will cover protocol design and security analysis.

4.1. Basic setting

4.1.1. SM2
Members’ keys include public key and secret key. We use the national standard key scheme for China. The SM2 technique is
typically used for key exchange and digital signature and is based on the elliptic curve cryptography (ECC) mechanism. The SM2
secret key has a size of 32 bytes while the public key has a size of 64 bytes. The output signature result actually takes up 70 to 72
bytes.

4.1.2. SM3
The SM3 hash algorithm is used to produce random integers, as well as to generate and verify message authentication codes. It
is also utilized in the SM2 standard and can satisfy the security needs of different encryption applications. The algorithm generates
a 256-bit hash value by populating and successively compressing input bit messages with lengths smaller than 2 to the power of 64.

4.2. SM2 based ring signature

In our scheme, we add witness vehicles to handle with accidents and use ring signature to protect the privacy of witness vehicles.
According to the multiple parameters (city area, number of vehicles, road rate, accident area, etc.), we divide all vehicles into various
groups in advance while each group has the equal amounts of vehicles, and every member of the group enjoy equal. Every registered
vehicle in the same group will obtain a public key set ℒ , and can use ℒ and its own secret key to generate ring signature.
A standard ring signature algorithm should be unforgeable and untraceable. To suit for our proposed system, we design a new
ring signature based on SM2. Our ring signature algorithm contains the following three phases: initialization, signature, verification.

4.2.1. Initialization
Initialization includes the generation and distribution of keys, which are divided into public and secret keys.
The SM2 initialization algorithm input secret param 𝜆, generate 𝑝𝑎𝑟𝑎𝑚𝑠 = {𝑝, 𝐹𝑝 , 𝐸(𝐹𝑝 ), G, 𝐺, 𝑞, 𝐻}, output public and secret keys.
Where 𝑝 is a large prime number, 𝐹𝑝 is a finite field; 𝐸(𝐹𝑝 ) is an elliptic curve defined on 𝐹𝑞 , and G is an additive cyclic group
formed by points on 𝐸(𝐹𝑝 ), 𝑞 is an order; 𝐺 is the base point of G; 𝐻 ∶ {0, 1}∗ → 𝑍𝑞∗ is a secure hash function. KGC randomly
generate 𝑠𝑘 ∈ 𝑍𝑞∗ and save it as secret key, compute public key 𝑝𝑘 = 𝑠𝑘 ⋅ 𝐺.
The SM2 key of each vehicle is distributed by the key generation server (KGC) server through a secure channel, and then the
vehicle uploads the public key and information to the TCC, and the TCC returns the public key set of the group it belongs to after
the registration. The result of initialization includes the secret key sk and the public key set ℒ ={𝑝𝑘1 , 𝑝𝑘2 , . . . , 𝑝𝑘𝑁 }.

4.2.2. Signature
The signer is the 𝑖-th(1 ⩽ 𝑖 ⩽ n) member, uses the secret key 𝑠𝑘𝑖 and ℒ = {𝑝𝑘1 , 𝑝𝑘1 , . . . 𝑝𝑘𝑛 } to generate ring signature 𝜎 for the
message ℳ through algorithm 1.

4
X. Liu et al. Internet of Things 22 (2023) 100728

Algorithm 1 SM2-based Ring Signature.

Input: 𝑠𝑘𝑖 , ℒ = {𝑝𝑘1 , 𝑝𝑘1 , ..., 𝑝𝑘𝑛 }, ℳ
Output: Ring Signature 𝜎ℒ (ℳ) = (𝑐1 , 𝑠1 , 𝑠2 , ..., 𝑠𝑛 )
1: Generate random numbers 𝑟𝑖 ∈ 𝑍𝑞∗ , compute 𝑐𝑖+1 = 𝐻(ℒ , ℳ, 𝑟𝑖 ⋅ 𝐺)
2: for 𝑗 = 𝑖 + 1, ..., 𝑛, 1, ..., 𝑖 − 1 do
3: Random generate 𝑠𝑗 ∈ 𝑍𝑞∗ , compute 𝑍𝑗 = 𝑠𝑗 ⋅ 𝑝𝑘𝑗 + 𝑐𝑗 ⋅ 𝐺, 𝑐𝑗+1 = 𝐻(ℒ , ℳ, 𝑍𝑗 ), mark 𝑐1 = 𝑐𝑛+1
4: Compute 𝑠𝑖 = 𝑠𝑘−1
𝑖 ⋅ (𝑟𝑖 − 𝑐𝑖 ) mod 𝑞
return Ring Signature (𝑐1 , 𝑠1 , 𝑠2 , ..., 𝑠𝑛 ) on 𝜎ℒ about ℳ.

Algorithm 2 Ring Signature Verify.

Input: Ring Signature {𝑐1 , 𝑠1 , 𝑠2 , ..., 𝑠𝑛 }, ℳ ′ , ℒ
Output: 𝑇 𝑟𝑢𝑒 OR 𝐹 𝑎𝑙𝑠𝑒
1: if 𝑐1 or 𝑠𝑗 ∉ 𝑍𝑞∗ then
2: return False
3: for 1 ⩽ 𝑗 ⩽ 𝑛 do
4: compute 𝑍𝑗′ = 𝑠𝑗 ⋅ 𝑝𝑘𝑗 + 𝑐𝑗′ ⋅ 𝐺, 𝑐𝑗+1
′ = 𝐻(ℒ , ℳ, 𝑍𝑗 )
5: if 𝑐𝑗′ = 𝑐𝑛+1
′ then
6: return True
7: else
8: return False

4.2.3. Verification
Input public key set ℒ , message ℳ and signature 𝜎, verify the signature through algorithm 2, return True if the signature is
correct, or False.
Correctness Analysis. From the algorithm 1, the signer computes the ring signature 𝜎 = (𝑐1 , 𝑠1 , 𝑠2 , … , 𝑠𝑛 ). After obtaining the
signature 𝜎, the message ℳ and the public key set ℒ , the verifier starts the verification by using the algorithm 2.
Since 𝑠𝑗 ∈ 𝑍𝑞∗ (𝑗 ≠ 𝑖) and 𝐻 ∶ {0, 1}∗ → 𝑍𝑞∗ , 𝑠𝑗 ∈ 𝑍𝑞∗ and the hash value 𝑐1 ∈ 𝑍𝑞∗ . With the value range promised, the verifier can
compute 𝑍𝑗′ = 𝑠𝑗 ⋅ 𝑝𝑘𝑗 + 𝑐𝑗′ ⋅ 𝐺 and 𝑐𝑗+1
′ = 𝐻(ℒ , ℳ, 𝑍𝑗′ ) where 𝑗 is from 1 to 𝑛. According to the signing algorithm, when 𝑗 ≠ 𝑖, it is
obvious that 𝑐𝑗+1 = 𝐻(ℒ , ℳ, 𝑍𝑗 ). When 𝑗 = 𝑖, since 𝑠𝑖 = 𝑠𝑘𝑖 −1 ⋅ (𝑟𝑖 − 𝑐𝑖 ) mod 𝑞, it can be obtained that
′ ′

𝑍𝑖′ = 𝑠𝑖 ⋅ 𝑝𝑘𝑖 + 𝑐𝑖′ 𝐺 = 𝑠𝑖 ⋅ 𝑠𝑘𝑖 𝐺 + 𝑐𝑖′ 𝐺

(1)
= 𝑠𝑘𝑖 −1 ⋅ (𝑟𝑖 − 𝑐𝑖′ ) ⋅ 𝑠𝑘𝑖 𝐺 + 𝑐𝑖′ 𝐺 = 𝑟𝑖 𝐺 = 𝑍𝑖 .
Then, the verifier computes that
′
𝑐𝑖+1 = 𝐻(ℒ , ℳ, 𝑍𝑖′ ) = 𝐻(ℒ , ℳ, 𝑟𝑖 𝐺). (2)

Therefore, it is clear that 𝑐1 = 𝑐𝑛+1 and the signature 𝜎 is verified validity.

4.3. Smart contract design

Blockchain can reach IoV destinations of trust and security because of its high trustworthiness and anonymity as a distributed
ledger technology. Distributed data stored in RSUs can also retain consistency since distributed consensus procedures are used. The
blockchain system can continue to function even if certain nodes are compromised. The aforementioned characteristics ensure that
the blockchain can successfully address the IoV’s trust management issue.
In general, blockchain can be divided into three types: public chain, alliance chain, and private chain. All three types of chains
rely on consensus techniques (for example, PoW for the public blockchain [12] and PoS for the public blockchain [13]). However,
the degree of decentralization might be interpreted as the key distinction between these chains. Here, we chose private chains as
system participants after taking into account the actual computational power of RSUs and cars.
The idea of a smart contract is not new; Nick Szabo developed it in 1995 and formalized its description in 1997 [14]. Since
the creation of Bitcoin, people have come to understand that the blockchain can offer a reliable environment for smart contract
execution. The first smart contract was implemented by Ethereum, which also published the Ethereum white paper [15]. The greatest
difference between Ethereum and Bitcoin is that Ethereum provides a more potent scripting language (Turing complete, for example,
𝑆𝑜𝑙𝑖𝑑𝑖𝑡𝑦). A smart contract processes the received content according to predetermined rules and displays the program’s outcomes.
As mentioned above, we add smart contract technology to our scheme. The four functions are shown as below.

1. Registration. Save the vehicle or RSU public keys to the blockchain so that the other party can use them to confirm your
identity. Storage success is represented by 𝑇 𝑟𝑢𝑒.

5
X. Liu et al. Internet of Things 22 (2023) 100728

Algorithm 3 Functions of Smart Contract.

Input: Function name, parameters
Output: 𝑇 𝑟𝑢𝑒 OR 𝐹 𝑎𝑙𝑠𝑒
1: %TCC and RSUs can successfully execute this function.
function register(string pk) returns (bool)
Send this public key as the information of the transaction.
%Only vehicles can successfully execute this function.
function accident(bool airbag, bool gyro, bool location, int accleration, uint speed) returns (bool)
If the airbag, gyro, or position is abnormal, return 𝑇 𝑟𝑢𝑒 directly, then if the current speed is 0 and the maximum acceleration
⩽ 𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑, return 𝑇 𝑟𝑢𝑒, otherwise return 𝐹 𝑎𝑙𝑠𝑒.
%Vehicles and RSUs can successfully execute this function.
function authentication(string pk) returns (bool)
If find this public key return 𝑇 𝑟𝑢𝑒, otherwise return 𝐹 𝑎𝑙𝑠𝑒.
%Only TCC can successfully execute this function.
function reward(address wallet) returns (bool)
Send a token increase transaction to this address’s wallet.

Table 1
Notations.
Symbol Accuracy
𝑉𝐼𝐷 The unique symbol of vehicle
𝐺𝐼𝐷 The unique symbol of vehicle group
𝑝𝑘𝑉 The public key of vehicle
𝑠𝑘𝑉 The secret key of vehicle
𝑝𝑘𝑅 The public key of RSU
𝑠𝑘𝑅 The secret key of RSU
𝑅𝐼𝐷 The unique symbol of RSU
𝐴𝐼𝐷 The unique symbol of an accident
𝐻 Hash function

2. Accident. Determine the existence of a traffic accident using parameters such as gyro, airbag, speed, etc. According to these
criteria, the technique determines whether an accident has occurred; the value 𝑇 𝑟𝑢𝑒 denotes an accident.
3. Authentication. Verify that the blockchain contains the same public key settings. The authentication will succeed and return
𝑇 𝑟𝑢𝑒 if they are real; otherwise, it will fail and return 𝐹 𝑎𝑙𝑠𝑒.
4. Reward. Rewards are sent out in accordance with the wallet address specifications, which creates a transaction to send
tokens. Reward success is represented by 𝑇 𝑟𝑢𝑒.

4.4. Protocol design

The protocol includes functions such as key management, authentication, ring signature, etc. It consists of four parts: blockchain
(smart contract), TCC, RSUs, and vehicles. It can be divided into 3 phases: Initialization, Accident and Additional. The notations
used in the protocol are shown in Table 1.

4.4.1. Initialization phase

The issuing of keys, which is the first phase of initialization and is generated by the KGC server and done so via a secure
connection, is represented in Fig. 3. When the program is initially installed, the vehicle will apply to the server, whereas the
RSU will apply during deployment. The obtained key is safely kept. One must upload their driver’s license, vehicle license, ID
card number, debit card number, 𝑝𝑘𝑉 , and 𝑉𝐼𝐷 to TCC through a secure channel in order to participate in the project. Following
receipt, TCC uploads the public key as a parameter to the car registration contract in accordance with the contract address and,
following successful registration, delivers the transaction hash. The public key will be connected to the transaction hash as an
identification during the authentication step. Transaction hash is the singular identifier of a transaction, through which the specifics
of the transaction (public key) may be found. The vehicles will then be grouped by TCC, which will also build a vehicle table with
data about the drivers and the vehicles. Finally, all of the automobiles in this group are returned together with their group number
and public key sets. The car will receive and store data while it is on the road. RSU broadcast of 𝑝𝑘𝑅 .

4.4.2. Accident phase

The most crucial stage of the protocol is the accident phase. This phase includes two-way authentication, accident handling, and
privacy protection via ring signature and encryption, as shown in Fig. 4. The program will begin this phase by gathering vehicle
status data when the vehicle’s sensor data is aberrant. There are 13 steps that make up the phase.

6
X. Liu et al. Internet of Things 22 (2023) 100728

Fig. 3. Initialization phase diagram of the protocol.

Fig. 4. Accident and additional phases diagram of the protocol.

Step 1: According to the contract address, by receiving the collected sensor value as parameters, the contract judges whether it
is a traffic accident.
Step 2: The contract returns the judgment result, true or false. True means that an accident has occurred, and the execution
continues. Otherwise, stop.

7
X. Liu et al. Internet of Things 22 (2023) 100728

Step 3: According to the contract address, the vehicle will send the recently received 𝑝𝑘𝑅 to the certification contract to verify
the RSU identity.
Step 4: The contract returns the judgment result, including true or false. True means the RSU identity is correct, execution
continues. Otherwise, replace another RSU.
Step 5: The vehicle generates 𝑉 𝑒ℎ𝑖𝑐𝑙𝑒 𝑆𝑖𝑔𝑛𝑎𝑡𝑢𝑟𝑒 with the timestamp and accident time, then sends it to RSU.
Step 6: RSU extracts 𝑝𝑘𝑉 and also goes to the authentication contract to verify the vehicle’s identity, two-way authentication is
complete.
Step 7: The contract returns the judgment result, true or false. True means the identity of this vehicle is correct, execution
continues. Otherwise, stop.
Step 8: RSU generates accident unique identification 𝐴𝐼𝐷 according to time and 𝑅𝐼𝐷 , 𝑅𝑆𝑈 𝑆𝑖𝑔𝑛𝑎𝑡𝑢𝑟𝑒 with the timestamp
and 𝐴𝐼𝐷 , then sends them to the vehicle. After 𝐴𝐼𝐷 is generated, RSU has to broadcast to the adjacent RSUs which guarantees
non-appearance of repeated processing.
Step 8’: At the same time of step 8, the accident time and 𝐴𝐼𝐷 are broadcast, vehicles within a certain range will receive, these
vehicles are witness vehicles, they will collect the image information of the accident time for analysis and give their conclusions.
Step 9: Vehicle generates 𝐴𝑐𝑐𝑖𝑑𝑒𝑛𝑡 𝑆𝑖𝑔𝑛𝑎𝑡𝑢𝑟𝑒 with sensor information and the image information of the keyframe and sends it
to RSU.
Step 9’: At the same time, the witness vehicles perform ring signatures on the analyzed accident conclusion and send them to
RSU.
Step 10: After waiting for a certain period or collecting more than 2/3 of the witness vehicles’ data, the RSU packages them
into a signature set and uploads them to TCC.
Step 11: TCC first verifies the signature set and then uses our improved clustering analysis method to get the conclusion according
to sensor information and the conclusion of witness vehicles. Finally, the judge result will be returned to RSU.
Step 12: RSU uses 𝑝𝑘𝑉 of the accident vehicles to encrypt the result and reply to the corresponding vehicle.
Step 13: RSU generates 𝑅𝑒𝑠𝑢𝑙𝑡 𝑆𝑖𝑔𝑛𝑎𝑡𝑢𝑟𝑒 with the result and computes 𝐻(𝑟𝑒𝑠𝑢𝑙𝑡), then packs them into the data area of the block,
and maintains the blockchain through POW competition mining.

4.4.3. Addition phase

The additional phase is the final phase of the protocol, which occurs after incident processing is complete and can be delayed.
Step 14: The extra duty of TCC is to reward the cars that take part in this handling process, as seen in Fig. 4. Since awards
are the only thing that would encourage additional drivers to join the project, we created a particular type of currency for the
blockchain system. TCC completes the payouts, or splits the tokens, in accordance with the wallet address that is associated to the
ring signature. In our version, the token’s exchange rate is steady, and the owner of the vehicle can periodically exchange actual
money in the system using the wallet address on file.

4.5. Security analysis

4.5.1. Security of ring signature

To protect witness’s privacy and achieve transmission between witness and RSU, our scheme designs a ring signature scheme
based on SM2. We will provide the security analysis of our proposed ring signature in this part, including unforgeability and
anonymity.

Unforgeability.

Theorem 1. Our signature scheme is unforgeable if no one can solve the hard assumptions of discrete logarithm problem.

Proof. Suppose the discrete logarithm problem is hard and an adversary  can forge a valid signature of our proposed ring signature
in polynomial time. Thus, a polynomial-time simulator  can be constructed to solve the discrete logarithm problem by using . 
randomly selects 𝑛 different ring members (𝑈1∗ , 𝑈2∗ , … , 𝑈𝑛∗ ) and computes all their public keys 𝑝𝑘∗𝑖 = 𝑠𝑘∗𝑖 𝐺 (𝑖 ∈ [1, 𝑛]) with randomly
selecting 𝑠𝑘∗𝑖 ∈ 𝑍𝑞∗ 𝑖 ∈ [1, 𝑛]. The public key set is written as ℒ ∗ = {𝑝𝑘∗1 , 𝑝𝑘∗2 , … , 𝑝𝑘∗𝑛 }.  sends ℒ ∗ and the system parameters to
the adversary  if ℒ ∗ is the real public key set. For the known message ℳ and its signature 𝜎 = (ℒ , ℳ, 𝑐1 , 𝑠1 , 𝑠2 , … , 𝑠𝑛 ),  produce
another valid signature 𝜎 ′ = (ℒ ∗ , ℳ, 𝑐1∗ , 𝑠∗1 , 𝑠∗2 , … , 𝑠∗𝑛 ). Since both 𝜎 and 𝜎 ∗ are verified validity, according to the verification, for
𝑘 ∈ [1, 𝑛], there exists at least 𝑍𝑘 = 𝑍𝑘∗ from the two signatures though 𝑐𝑘 ≠ 𝑐𝑘∗ and 𝑠𝑘 ≠ 𝑠∗𝑘 . Because of 𝑍𝑘 = 𝑠𝑘 ⋅ 𝑝𝑘𝑘 + 𝑐𝑘 ⋅ 𝐺, it can
be obtained that

𝑠𝑘 ⋅ 𝑝𝑘𝑘 + 𝑐𝑘 ⋅ 𝐺 = 𝑠∗𝑘 ⋅ 𝑝𝑘𝑘 + 𝑐𝑘∗ ⋅ 𝐺. (3)

The equation can be simplified as

𝑐𝑘∗ − 𝑐𝑘
𝑝𝑘𝑘 = 𝐺. (4)
𝑠𝑘 − 𝑠∗𝑘
𝑐𝑘∗ − 𝑐𝑘
Thus, we can obtain the real secret key 𝑠𝑘𝑘 = which means the adversary  solve the discrete logarithm problem. However,
𝑠𝑘 − 𝑠∗𝑘
the discrete logarithm problem is too hard to be solved. Thus, our signature scheme is unforgeable.

8
X. Liu et al. Internet of Things 22 (2023) 100728

Anonymity.

Theorem 2. Our signature scheme is anonymous if everyone’s signature is indistinguishable.

Proof. Suppose an adversary  wants to distinguish everyone’s signature. Similar as the above process, the simulator  send the
system parameters to .  selects the signing message ℳ ∗ and the public set ℒ ∗ = {𝑝𝑘∗1 , 𝑝𝑘∗2 , … , 𝑝𝑘∗𝑛 }, and sends them to the
simulator.  randomly selects 𝑁𝑤 (𝑤 ∈ [1, 𝑛]), one of the ring members, to compute signature. According to signing procedure, 𝑁𝑤
needs to compute 𝑛 − 1 parameter pairs (𝑐𝑗 , 𝑠𝑗 ) (𝑗 ∈ [1, 𝑛] and 𝑗 ≠ 𝑤). Thus, 𝑁𝑤 needs to randomly select 𝑟 first, compute other 𝑛 − 1
(𝑐𝑗 , 𝑠𝑗 ) by 𝑍𝑗 = 𝑠𝑗 ⋅ 𝑝𝑘𝑗 + 𝑐𝑗 ⋅ 𝐺, 𝑐𝑗+1 = 𝐻(ℒ , ℳ, 𝑍𝑗 ), and then find the appropriate 𝑐𝑤 to complete the whole ring signature. It is clear
that

𝑠𝑤 = (𝑠𝑘𝑤 )−1 ⋅ (𝑟 − 𝑐𝑤 ) mod 𝑞. (5)

1 1 1
The probability of processing 𝑛 − 1 different (𝑐𝑗 , 𝑠𝑗 ) pairs is 𝜃 = 𝑞−1
⋅ 𝑞−2
⋅⋯⋅ 𝑞−𝑛+1
. Additionally, the probability of 𝑐𝑤 ≠ 𝑐𝑗 (𝑗 ∈
1 1 1 1 1
[1, 𝑛] and 𝑗 ≠ 𝑤) is 𝑞−𝑛 . Therefore, the probability of 𝑁𝑤 generating the valid signature is 𝛿 = 𝑞−1 ⋅ 𝑞−2 ⋅ ⋯ ⋅ 𝑞−𝑛+1 ⋅ 𝑞−𝑛 . Besides,
the probability of every ring member generating the valid signature is also 𝛿 which means it is hard to distinguish everyone’s ring
signature in statistical terms. In addition, the probability of distinguishing ring members is no more than 𝛿. In total, our signature
scheme is anonymous.

4.5.2. Analysis of the adversary model

Insurance fraud. Suppose malicious users  and  collude with each other and lie together about a car accident (either  crashes
 or  crashes ) to defraud insurers. For insurance fraud, our scheme takes ‘‘the witness mechanism’’ by RSU and witness vehicle
participation. Only submitting signatures from accident cars to TCC is not accepted at once. TCC will deal with the accident only
when signatures from both accident cars and witness vehicles are received. TCC will set a time interval 𝑇𝑝 for receiving all signatures
from RSU. If no witness submits signatures for accident message during the interval, the signatures from accident cars will not be
trusted and TCC will ask the accident cars to submit the accident videos from car cameras. If the accident cars do not submit videos
or the videos show that they tell lies, these two car will be banned from our scheme and their behaviors will be broadcast in the
blockchain.

Perjury. Suppose a car accident happened between user 𝑖 and user 𝑗 (user 𝑖 and user 𝑗 are all authenticated system users), a malicious
witness  submit a fake accident analysis or other non-significant message to interfere the final accident treatment. TCC receive
all signatures from RSU, including the accident cars’, honest witness vehicles’ and witness ’s, and conduct summary evaluation.
There exists two situations: If only  give the different accident message, TCC will record his behavior and check the number of
abnormal records he has. Generally, TCC will set a domain value 𝐴𝑛 for abnormal records to manage all users. If the number of
’s abnormal records is over 𝐴𝑛, he will be banned from the system. Besides , some other users give the different message for not
seeing the accident clearly or for other reasons. Then, TCC will require every users to submit their videos during the accident time.
According to the videos, TCC will deal with this accident correctly and record cars who give the false message. However, honest
user can reduce this unexpected abnormal record by providing correct witness message ten times in a row. In addition, if only 
submit the witness signature this time and his submitting message cannot get the consensus of these accident cars, TCC will also
require all these cars to submit the videos.

Tracing attack. Suppose the identities and privacy of witness vehicles or accident cars are leaked. For witness vehicles, they will
not give evidence for fear of reprisals of the crashing car; for the accident cars, other users can use their identity information to
fraud insurance. According to the above viewpoints, it is important to protect the privacy of both witness vehicles and accident
cars. Because of the anonymity of ring signature, based on the above consideration, we use design a protect-privacy system using
ring signature. Besides, our designed signature can avoid malicious users impersonating identity of other users to submit the fake
message. Although ring signature can protect the signer’s privacy, the signature has ability of authentication. The signer cannot use
others’ secret keys to generate signatures, and his signature can only be verified validity by his own public key. In other words,
the malicious cannot impersonate others’ identity to generate the valid signature since he cannot obtain other’s secret keys in our
system. In our scheme, TCC is an independent trusted third party, and only TCC knows all cars information. Besides, every car in
our system will not expose its identity to others which means witness submits the accident message only including the accident cars’
make and color, the accident place and time, and other information that does not expose the accident cars’ privacy. In addition,
according to the security analysis of our designed ring signature, the malicious users cannot forge a valid signature. Thus, malicious
users cannot impersonate other users and our scheme can resist tracing attack.

RSU attack. Suppose a RSU held by an adversary . The attacked RSU either does not communicate with cars or TCC when
the accident happens nearby (which is called ‘‘Offline’’) or transit the meaningless information repeatedly. TCC can get accident
information from other RSU. Though ’s RSU could be the nearest to the scene of the accident, the accident will also be received
by other RSU (The distance between these RSUs and the accident site is second only to ). Because of time difference of transiting
message, the nearest RSU will send all these message to TCC more quickly. However, message from other RSUs will also be accepted.
It is noticed that for one accident, TCC only accepted message from a certain number of RSUs. Thus,  is be attacked but TCC can
deal with the accident receiving message from other RSUs.

9
X. Liu et al. Internet of Things 22 (2023) 100728

4.6. Engineering application

Our proposed approach can resolve the problem in real-world situations, such as engineering applications. We will go into
more detail about how our proposed system works about the process applied in the real world in this subsection. Suppose there
is a vehicle driving down the road and colliding with another vehicle. The program on the vehicle at this moment automatically
collects the sensor parameters and driving video content for 10 s before and after. Then the vehicle packs all the abnormal sensor
information and sends it to the smart contract for judgment. Besides, the vehicle also encrypts the video and send it to the file
server. Receiving the package sent from vehicle, the smart contract will evaluate it by using algorithm 3, and return the outcome
based on the gyro, acceleration sensor, and vehicle condition inputs. Following two-way certification between the vehicle and the
RSU, the RSU generates 𝐴𝐼𝐷 and broadcasts it to all nearby vehicles. Based on the image information, the witness vehicle forms
a conclusion, uses algorithm 1 to sign it, and then uploads it to the RSU and blockchain. After the number of signatures for the
same conclusion exceeds a specific value, we call it the threshold value, RSU gathers all these signatures and transmits them with
the conclusion to TCC. TCC employs algorithm 2 to validate ring signatures, and then analyzes it with a clustering algorithm. The
incident processing function uses a simple modified clustering algorithm that first divides the message into two classes in order to
prevent the opposite conclusion for malicious or unusual vehicles, i.e. by setting the specified K-value to ‘‘2’’. This is followed by an
analysis using a modified clustering K-means algorithm. If the final difference between the two clustering centers is too large and
the ratio of elements in the class with more elements to those in the class with fewer elements exceeds a certain threshold, then the
one with significantly more elements is selected, and if the numbers are similar then it is judged to be an anomaly and needs to be
left to a manual decision. After obtaining the real conclusion, TCC sends the result back to RSU. Then RSU broadcasts this result to
make all cars receive it. Finally, all participating vehicles will obtain incentives for support-giving automobiles offered from TCC.
We can see that the program completes all of these stages automatically in this application case. Identity verification and accident
handling may be done in a matter of seconds thanks to the fact that the car is already registered in the blockchain when the smart
software is loaded, as long as the public key information is given. The allocation of responsibility for the accident is completed
quickly by the accident owner, reducing the workload of the traffic police. In addition to speeding up processing and streamlining
incident handling, it also gets rid of private transactions.

5. Experiment results and analysis

In this section, the system implementation, experiment, and the analysis of experimental results will be introduced in detail.

5.1. System implementation

5.1.1. Smart contract

The most popular smart contract language at the moment is 𝑆𝑜𝑙𝑖𝑑𝑖𝑡𝑦, which, like JavaScript, is also Ethereum’s official
development language recommendation. 𝑅𝑒𝑚𝑖𝑥, a browser-based IDE that enables compiling, running, debugging, and publishing,
is the greatest tool for writing 𝑆𝑜𝑙𝑖𝑑𝑖𝑡𝑦.
The blockchain must be used to deploy smart contracts. Ethereum offers various test chains to developers. We make use of the
PoA-based 𝑅𝑖𝑛𝑘𝑒𝑏𝑦 test network, which is a popular choice among developers. Posting wallet addresses on social media will earn
you free 𝐸𝑇 𝐻. We employ the Google Chrome extension 𝑀𝑒𝑡𝑎𝑀𝑎𝑠𝑘 for management in order to use the 𝑅𝑖𝑛𝑘𝑒𝑏𝑦 blockchain more
efficiently. This extension allows for the graphical display and operation of account information, transaction information, required
Gas, and other information.
As described in Section 4.3, the four functions of a smart contract are register, accident, authentication, and reward. These
functions were coded, debugged, and compiled through 𝑅𝑒𝑚𝑖𝑥 in order to launch the contract on 𝑅𝑖𝑛𝑘𝑒𝑏𝑦. Considering the register
function as an illustration, a transaction is generated and the transaction hash is returned with each call. The remaining three
functions use the registered public key in the same way by looking for the transaction hash in the blockchain browser. Since our
proposed system makes use of the Ethereum private chain, the value of the gas fees is not taken into account.

5.1.2. Other platform

Other parts besides smart contract are covered in this section. First, introduce the simulation platform configuration, vehicle
platform is an Intel (R) Core (TM) i5-5200U CPU @2.70 GHz and 8 GB RAM, RSU platform is an Intel (R) Core (TM) i5-6700 CPU
@3.40 GHz and 8 GB RAM, TCC platform is cloud server with dual-core CPU and 4 GB RAM. The operating system is Ubuntu
20.04. The source code was written in Java language with IntelliJ IDEA. Each part is described below, the vehicle is responsible for
initiating the accident request, due to the lack of sensors, the data is stored in the system in advance (two copies of normal data and
abnormal data). The RSU is responsible for the transfer of data, and the vehicle can access it through the internet after deployment.
TCC is responsible for the accident process, the accident vehicle uploads sensor information, and each witness vehicle analyzes
the image information to obtain a preliminary conclusion, performs ring signature and uploads it to RSU, and TCC summarizes
multi-party information to obtain a final conclusion. The accident processing function uses a simple improved clustering algorithm.
In order to prevent the opposite conclusion of malicious vehicles, messages are divided into two categories. If the difference between
clustering centers is too large, more elements will be selected, and if the number is similar, a new center value will be taken.

10
X. Liu et al. Internet of Things 22 (2023) 100728

Table 2
Scheme compare. (see [5–7,9,16–19]).
Scheme Cross-domin Decentralization Anonymity Privacy preservation
Xu et al. [5]
Zhang et al. [7]
Gong et al. [6]
Chen et al. [16]
Sharma et al. [9]
Lin et al. [17]
Lin et al. [18]
Liu et al. [19]
Our scheme

5.2. Result and analysis

There is rarely such a comprehensive consideration of the privacy aspect of this research topic. In this part, we first make a
careful comparison in the security aspect between our proposed scheme and then design experiments to measure the latency of our
proposed system and verify the validity of our proposed ring signature. The experiments demonstrate that the system’s time delay
is tolerable, and the proposed ring signature is efficient.

5.2.1. Comparison analysis

When comparing with other solutions, in addition to anonymity, cross-domain authentication and decentralization, it is of utmost
importance to focus on whether the solution has privacy protection features. The use of signatures or encryption ensures that
information is not compromised, and if it is, it does not compromise user privacy. Cross-domain authentication ensures that vehicles
can be authenticated regardless of their geographical location. Decentralization ensures that data is stored securely. The privacy
protection focuses on the non-disclosure of sensitive information such as vehicle owner’s identity and vehicle data. Our system uses
ring signatures to hide the true identity of the witness vehicle to prevent malicious retaliation, while encrypting the transmission of
sensitive information to ensure its security. We compare our proposed scheme with others’ works in the aspects mentioned above.
Sharma et al.’s work [9], which focuses on vehicle authentication for seamless access control, takes into account privacy
protection but does not anonymize the user, making it possible for an adversary to gain access to the vehicle’s identity through
tracking, etc. Zhang et al.’s work [7] focuses on the secure sharing of vehicle data and incentivizes active participation by issuing
rewards in the form of cryptocurrency, but it only uses the blockchain to store propagation messages and not vehicle information.
Gong et al. [6] use a combination of ring signatures and proxy signatures to protect the identity privacy of traders and data sender
address information and use blockchain to address the strain on centralized systems, but the scheme cannot achieve cross-domain
authentication. Chen et al. [16] design a zero-knowledge proof-based RSA protocol to achieve vehicle-to-roadside unit and vehicle-
to-vehicle authentication through a zero-knowledge proof-based RSA digital signature scheme, but the scheme is time-consuming
and cannot achieve privacy protection. This scheme is suitable for accident disputes and vehicle insurance claims, but it is time-
consuming and does not enable privacy protection. Lin et al.’s scheme [17] aims to facilitate secure authentication of vehicles and
achieves effective certificate management based on blockchain technology, taking into account privacy protection, but lacks the
protection of communication messages. We record all these schemes and their performance in the Table 2.

5.2.2. System time delay

The first experiment is the system time delay, which verifies the feasibility of the solution by measuring the time it takes to run the
entire system. The timing starts when a vehicle accident occurs and ends when the accident is completed. In order to eliminate the
influence of unexpected factors, several experiments were conducted at different time periods and the results of these experiments
were averaged. The final result obtained was 5.13 s. This time is acceptable for processing a vehicle accident and completing a
claim.
In order to monitor the true latency of the system and to exclude the effect of network instability on the latency of the solution,
we conducted local experiments for all steps except network time. We conducted several experiments and averaged the results to
obtain a final result of 3.49 s, which represents 68% of the total time previously measured. Therefore, we can conclude that network
conditions have a large impact on the latency of the system and that good network conditions will help the system to complete the
incident processing faster. The above findings are very inspiring for our future work, and we will further explore the use of more
advanced communication methods to reduce time delays, such as 5G and other technologies, which will have a significant impact
on the IoT and Telematics sectors.

5.2.3. Ring signature

One of the primary contributions of this work is the method mentioned in Section 4.2, therefore experiments are done to
determine how much computing power the program uses. The time required for computation will depend on the resources used in
creating the ring signature. Assume that there are 𝑛 members in the ring, which is the computational amount shown in Table 3.
To test the performance of the ring signature algorithm even further, we implemented the ring signature generation signature
algorithm1 and the verification signature algorithm2 using Java, recorded the test results and analyzed the relationship between

11
X. Liu et al. Internet of Things 22 (2023) 100728

Table 3
Computational amount of ring signature.
Phase Dot product on G Point addition on G 𝐻 operate Inverse operate on 𝑍𝑞
Signature 2𝑛 − 1 𝑛−1 𝑛 1
Verification 2𝑛 𝑛 𝑛 0

Fig. 5. Relationship between members and SM2 ring signature size.

Fig. 6. Comparison of signature time cost.

the length of our proposed ring signature and the number of members. The number of members tested ranged from 10 to 100, in
intervals of 10. The signature length is expressed as the number of bits in the physical memory of the computer for the signature
result object. The experimental results are shown in Fig. 5, where we can conclude that there is a linear relationship between the
length of the signature and the number of members of the ring signature, presented as a straight line.
Our proposed ring signature scheme is improved from the work of Fan et al. [20] by reducing the number of operations in
its steps. We measured the time consumption of signature generation and verification for the two schemes separately, and the test
results are shown in Fig. 6. We can obtain the following conclusions: (1) The time for signature and verification shows an increasing
trend with the number of members in the ring, basically in a straight line. (2) Our improved ring signature algorithm reduces the
time by a certain amount compared to the original algorithm, with the time reduction ranging from 7 to 14 ms and the percentage
reduction ranging from 7% to 11%.

6. Conclusion

In this work, we focus on the efficient and undisputed handling of the traffic accident in the smart city. According to the
traditional traffic accident occasion, we provide a general system model on IoV and summarize the hidden privacy problems and

12
X. Liu et al. Internet of Things 22 (2023) 100728

existing adversary conditions of this proposed model. To defend against these adversary methods and protect the privacy of all
vehicles, by using the blockchain and ring signature, we propose an authentication and privacy preservation scheme for handling
accidents on IoV and present its detailed descriptions. So far, to better enhance the stability and efficiency of our scheme, we design a
new ring signature based on SM2. To verify and demonstrate our system’s utility and efficiency, we assess the effect of our approach
by using Ethereum smart contracts. The experimental results emerge that the time cost of the scheme is only 5.13 s while the time
without network delay is 3.49 s, which can be suitable for the actual scenario demands. Objectively speaking, there are still some
shortcomings in our article, such as the security of messages relying on the TCC server not being compromised and the lack of
support for very high concurrency and high throughput. In the future, we will use new technologies to design solutions to enhance
the protection of the TCC. In addition, we will simplify and redesign the data structure of blocks, use techniques such as sidechaining
to increase the throughput of the blockchain, or use more efficient consensus mechanisms to rationalize the computational power
of nodes. Finally, we will promote and use our solution in the industry.

Declaration of competing interest

The authors declare that they have no known competing financial interests or personal relationships that could have appeared
to influence the work reported in this paper.

Data availability

No data was used for the research described in the article.

Acknowledgments

The research was financially supported by a grant from Guangxi Key Laboratory of Machine Vision and Intelligent Control,
China (No. 2022B11), the Provincial Key Research and Development Program of Hubei, China (No. 2020BAB105), the Knowledge
Innovation Program of Wuhan - Basic Research, China (No. 2022010801010197), National Natural Science Foundation of China
(61961036, 62162054), Natural Science Foundation of Guangxi, China (2020JJA170007), Special Project of Guangxi Science
and Technology Base and Talent, China (Guike AD20297148), Guangxi Innovation Driven Development Project, China (Guike
AA18118036), and Basic Ability Improvement Project for Young and Middle-aged Teachers in Guangxi, China (2021KY0673). The
work of K.-K. R. Choo was supported only by the Cloud Technology Endowed Professorship.

References

[1] H. Talat, T. Nomani, M. Mohsin, S. Sattar, A survey on location privacy techniques deployed in vehicular networks, in: 2019 16th International Bhurban
Conference on Applied Sciences and Technology, IBCAST, IEEE, 2019, pp. 604–613.
[2] M. Aloqaily, S. Otoum, I. Al Ridhawi, Y. Jararweh, An intrusion detection system for connected vehicles in smart cities, Ad Hoc Netw. 90 (2019) 101842.
[3] Y. Lu, X. Huang, K. Zhang, S. Maharjan, Y. Zhang, Blockchain empowered asynchronous federated learning for secure data sharing in internet of vehicles,
IEEE Trans. Veh. Technol. 69 (4) (2020) 4298–4311.
[4] J. Feng, Z. Liu, C. Wu, Y. Ji, Mobile edge computing for the internet of vehicles: Offloading framework and job scheduling, IEEE Veh. Technol. Mag. 14
(1) (2018) 28–36.
[5] Z. Xu, W. Liang, K.-C. Li, J. Xu, H. Jin, A blockchain-based roadside unit-assisted authentication and key agreement protocol for internet of vehicles, J.
Parallel Distrib. Comput. 149 (2021) 29–39.
[6] J. Gong, Y. Mei, F. Xiang, H. Hong, Y. Sun, Z. Sun, A data privacy protection scheme for internet of things based on blockchain, Trans. Emerg. Telecommun.
Technol. 32 (5) (2021) e4010.
[7] L. Zhang, M. Luo, J. Li, M.H. Au, K.-K.R. Choo, T. Chen, S. Tian, Blockchain based secure data sharing system for Internet of vehicles: A position paper,
Veh. Commun. 16 (2019) 85–93.
[8] X. Wang, P. Zeng, N. Patterson, F. Jiang, R. Doss, An improved authentication scheme for internet of vehicles based on blockchain technology, IEEE Access
7 (2019) 45061–45072.
[9] R. Sharma, S. Chakraborty, BlockAPP: using blockchain for authentication and privacy preservation in IoV, in: 2018 IEEE Globecom Workshops (GC
Wkshps), IEEE, 2018, pp. 1–6.
[10] C. Chen, T. Xiao, T. Qiu, N. Lv, Q. Pei, Smart-contract-based economical platooning in blockchain-enabled urban internet of vehicles, IEEE Trans. Ind.
Inform. 16 (6) (2019) 4122–4133.
[11] P.K. Singh, R. Singh, S.K. Nandi, K.Z. Ghafoor, D.B. Rawat, S. Nandi, Blockchain-based adaptive trust management in internet of vehicles using smart
contract, IEEE Trans. Intell. Transp. Syst. (2020).
[12] S. Nakamoto, Bitcoin: A peer-to-peer electronic cash system, Decentralized Bus. Rev. (2008) 21260.
[13] D. Larimer, Transactions as proof-of-stake, 2013, Nov-2013.
[14] N. Szabo, Formalizing and securing relationships on public networks, First Monday (1997).
[15] G. Wood, et al., Ethereum: A secure decentralised generalised transaction ledger, Ethereum Proj. Yellow Pap. 151 (2014) (2014) 1–32.
[16] Y.R. Chen, J.R. Sha, Z.H. Zhou, IOV privacy protection system based on double-layered chains, Wirel. Commun. Mob. Comput. 2019 (2019).
[17] C. Lin, D. He, X. Huang, N. Kumar, K.-K.R. Choo, BCPPA: a blockchain-based conditional privacy-preserving authentication protocol for vehicular ad hoc
networks, IEEE Trans. Intell. Transp. Syst. (2020).
[18] C.-C. Lin, C.-C. Chang, Y.-Z. Zheng, A ring signature based anonymity authentication scheme for group medical consultation, Symmetry 12 (12) (2020)
2009.
[19] J. Liu, Y. Yu, J. Jia, S. Wang, P. Fan, H. Wang, H. Zhang, Lattice-based double-authentication-preventing ring signature for security and privacy in vehicular
ad-hoc networks, Tsinghua Sci. Technol. 24 (5) (2019) 575–584.
[20] F. Qing, H. De-Biao, L. Min, H. Xin-Yi, L. Da-Wei, Ring signature schemes based on SM2 digital signature algorithm, J. Cryptol. Res. 8 (4) (2021) 710–723.

13