Vehicular Communications 49 (2024) 100832

Contents lists available at ScienceDirect

Vehicular Communications
journal homepage: www.elsevier.com/locate/vehcom

Conditional privacy-preserving and efficient distributed IoV data sharing

scheme based on a hierarchical and zonal blockchain ✩
Ziyu Zhou a , Na Wang a,∗ , Jianwei Liu a,∗∗ , Wen Zhou a , Junsong Fu b , Lunzhi Deng c
a The School of Cyber Science and Technology, Beihang University, Beijing, 100191, China
b The School of Cyberspace Security, Beijing University of Posts and Telecommunications, Beijing, 100876, China
c School of Mathematical Sciences, Guizhou Normal University, Guiyang, 550001, China

A R T I C L E I N F O A B S T R A C T

Keywords: With the prevalence of intelligent driving, the vehicular data corresponding to driving safety and traffic
Internet of Vehicles (IoV) management efficiency is widely applied by the Internet of Vehicles (IoV) applications. Vehicular data is shared
Blockchain frequently in IoV, leading to privacy leakage of the message sender, yet most privacy-preserving measures bring
Conditional privacy-preserving authentication
difficulties for receivers to detect malicious messages. To trade-off between privacy and security, conditional
(CPPA)
Key derivation algorithm
privacy-preserving authentication (CPPA) solutions have been proposed. However, CPPA protocols deployed in
IoV rely on hardware devices or center servers to manage key generation and updates. This paper proposed
a blockchain-based CPPA mechanism for IoV data-sharing to mitigate these challenges. A hierarchical key
generation mechanism is presented to protect drivers’ privacy and authenticate messages which is suitable for
resource-limited IoV nodes. Management nodes can issue temporary pseudo-identity (PID) from their keys for
vehicles to interact in their area and trace the malicious behaviors, but know nothing about vehicles’ activities
outside their administration. A hierarchical and zonal blockchain is presented to realize distributed fine-grained
IoV management and enhance efficiency concerning traditional blockchain. Specifically, we propose a cross-
domain data-sharing mechanism, which can facilitate efficient communication and a mutual cross-domain chain
verification to guarantee the security of each domain blockchain in our IoV system. The security analysis and
performance evaluation demonstrate the security as well as computational and storage efficiency of our scheme.

1. Introduction in vehicle services and the expansion of vehicular network coverage, the
existing IoV framework is of privacy and security concerns in handling
The development of the smart automotive industry and information all data.
technology has led to widespread attention to the increasing traffic data A typical IoV system mainly consists of a Trusted Authority (TA),
[11]. Data collected by the vehicles’ on-board devices during driving, RSUs, and vehicles sharing real-time traffic information through wired/
combined with Global Positioning System information such as speed, wireless networks. Despite TA that is responsible for taking appropri-
location, weather, and road conditions, can be shared through the IoV ate actions based on traffic information obtained from other entities,
with other nodes, including other vehicles, roadside units (RSU), service public wireless communication in Vehicle-to-Vehicle (V2V) and Vehicle-
providers, and the traffic authority. This enables autonomous driving to to-Roadside (V2R) scenarios makes the transmitted data vulnerable to
enhance driving safety and convenience according to traffic conditions, attackers that impact traffic safety [6]. Malicious vehicles may also share
ultimately improving travel efficiency [20]. However, with the increase false information, misguiding others and affecting traffic security. To

✩
This work was supported in part by the National Key R&D Program of China (2021YFB2700200), National Natural Science Foundation of China (62102017,
62001055, 62372020, 61972017, 61932014, 61972018), Beijing Natural Science Foundation (L222050, M22038), and in part by the Fundamental Research Funds
for the Central Universities (YWF-23-L-1240).
* Principal corresponding author.
** Corresponding author.
E-mail addresses: zhouziyu@buaa.edu.cn (Z. Zhou), nawang@buaa.edu.cn (N. Wang), liujianwei@buaa.edu.cn (J. Liu), 19377014@buaa.edu.cn (W. Zhou),
fujs@bupt.edu.cn (J. Fu), denglunzhi@163.com (L. Deng).

https://doi.org/10.1016/j.vehcom.2024.100832
Received 3 March 2024; Received in revised form 9 July 2024; Accepted 20 July 2024
Available online 26 July 2024
2214-2096/© 2024 Elsevier Inc. All rights are reserved, including those for text and data mining, AI training, and similar technologies.
Z. Zhou, N. Wang, J. Liu et al. Vehicular Communications 49 (2024) 100832

prevent malicious vehicles from sharing false information, message au- 1. The CPPA supporting key generation mechanism: This paper in-
thentication needs to be taken into consideration. Yet the transmitted troduces a hierarchical key generation mechanism to achieve con-
data may contain sensitive information, such as car numbers, locations, ditional privacy-preserving for the IoV context. Vehicles can arbi-
and personal information about drivers, privacy-preserving measures trarily interact with different pseudo-identities in various domains,
are required to prevent privacy breaches. The complexity of the IoV ensuring anonymity and the privacy of sensitive information. Even
structure makes it challenging to strike a balance between effectively if an adversary gains complete control over a particular node, the
ensuring vehicle privacy and efficiently monitoring malicious vehicle data accessible to the adversary is limited, ensuring data security.
behavior. Thus conditional privacy-preserving authentication (CPPA) Meanwhile, malicious behaviors are traceable to ensure the mes-
is necessary to guarantee traffic security as well as preserve privacy. sage reliability and all behaviors of a certain adversary can be
Data encryption and anonymous identities are introduced to protect filtered avoiding further loss.
senders’ privacy and transmitted content, meanwhile, adversaries can be 2. Blockchain for efficient IoV distributed management: The hierarchi-
detected [16]. However, existing CPPA protocols [18,36,25] deployed cal and zonal blockchain designed in this paper relieves the depen-
in IoV impose certain requirements on the storage and computational dence on a central server and realizes the distributed hierarchical
identity authentication in the IoV system. The Vehicle temporarily
capabilities of vehicles that rely on onboard trusted devices. In pseudo-
registered in a particular domain, is managed by the corresponding
identity schemes, a center server is also required to manage key gener-
domain chain. This blockchain framework enhances the efficiency
ation and updates.
of pseudo-identity issues and data retrieval in various domains, as
The IoV systems using reputation evaluation trust management only
well as reduces the computational and storage overhead for an IoV
to enhance the credibility of IoV data [1,4], are struggling to meet the
node that participates in blockchain maintenance.
demands of multi-domain, hierarchy entities, and a large amount of re-
3. Cross-domain secure data sharing and verification mechanism: Ve-
dundant information in IoV data sharing. Moreover, the processing of
hicle nodes can obtain traffic information from other domains
a large amount of IoV data imposes high storage and computational re- through the proposed cross-domain data interaction mechanism.
quirements on a standalone central server, and the reliance on it puts This mechanism enables vehicles to quickly access data from other
the system has risk of a single point of failure (SPOF). To avoid the risk domains with the assistance of Roadside Units (RSUs) securely,
of a centralized system, multiple servers are introduced, combined with thereby improving data availability and reducing storage overhead.
RSUs, for distributed management of IoV data and vehicle credibility Moreover, a mutual cross-domain chain verification mechanism for
to resist threats from SPOF [27]. Nevertheless, the distributed system security is presented to increase the cost of blockchain attack, where
has the challenge of view unification among multiple servers. As some the adversary has to conquer all domain chains to overwrite the
servers may be subject to intrusion or collusion, the authenticity of IoV data in a certain chain.
data cannot be fully guaranteed and the investigation of traffic accidents
is not transparent. Blockchain consensus [21,30] enables decentralized 2. Related work
nodes that do not trust each other to reach a consensus on a public
ledger. It has been widely introduced to distributed networks [2,13] to 2.1. Conditional privacy-preserving authentication for the IoV system
ensure the integrity, tamper resistance, and traceability of ledger data
through cryptographic techniques. Integrating blockchain technology Despite the existing various IoV privacy-preserving solutions [35,22]
with IoV [32] allows participating nodes to share and store traffic in- can safeguard personal information in data interactions, these solutions
formation without dependence on a single server. However, unlike the face challenges in fully protecting privacy while tracing the behaviors of
Internet of Things with fixed nodes, mobile IoV has a dynamic topology malicious vehicles. The key to IoV privacy-preserving is to ensure that
where the vehicles should keep connecting with servers while moving vehicle messages are authentic and reliable without revealing driver pri-
arbitrarily. Directly introducing blockchain protocols into existing IoV vacy, that is authorities should be able to trace driver responsibility
systems may exert a node too much pressure to store a large amount through data and other nodes know nothing about the drivers’ pri-
of irrelevant blockchain data and incur additional computational over- vacy. Early privacy-preserving authentication schemes for vehicles [23]
head. always preload a large number of public/private key pairs and corre-
To address the above issues, it is necessary to design a decentralized sponding certificates into onboard devices. When vehicles share their
IoV framework and introduce a conditional privacy-preserving authenti- status, a random public/private key pair is chosen for signature veri-
fication, achieving anonymous authentication to hide the real identity
cation scheme, allowing the TA to effectively trace malicious behaviors
of vehicles, and authorities can trace vehicle data based on certificates.
without revealing sensitive information of other nodes, where multiple
However, vehicles needed to regularly update anonymous key sets, and
supervisors and regular nodes can be involved in assistant management.
there were significant storage and revocation costs for both vehicles and
To enhance the efficiency of IoV blockchain management and reduce the
relevant institutions [16].
data maintenance overhead of individual nodes, this paper proposes a
For the sake of reducing the cost of key sets update, Zhang et al.
hierarchical zonal IoV blockchain architecture. The upper-level architec-
[37] proposed a CPPA scheme based on the Chinese Remainder Theo-
ture consists of high-reputation representative nodes from each domain,
rem where the trusted authority regularly updated new group keys for
collectively maintaining a global blockchain managing the identity and
vehicles in VANET groups. However, this scheme requires the TA to
credibility of all IoV nodes, recording important traffic data, and stor- constantly update keys based on the situation of vehicles entering and
ing lower-level data digests. The lower-level zonal architecture includes leaving specific areas, leading to substantial communication overhead.
multiple domains, each maintained by lower-level nodes managing their Zhao et al. [39] presented an efficient privacy-preserving authentica-
local blockchains, which store real-time traffic data details in the respec- tion scheme for VANETs based on the Paillier cryptosystem, where the
tive domains and the temporary identity information of active nodes in update of PIDs and tracking of malicious vehicle identities require coor-
the current domain. A hierarchical key generation management mech- dination among multiple organizations. However, these schemes rely on
anism is proposed for the above architecture to achieve conditional tamper-proof devices, such that vehicles need to carry specific hardware
privacy-preserving. In the context of data sharing, nodes without cor- devices for certification computing and storage.
responding permissions are unable to access any private information To mitigate the reliance on onboard devices. Gu et al. [7] proposed
about the data sender. Authorized nodes have the capability to track a vehicle traceable privacy-preserving scheme based on fog computing,
and penalize malicious nodes. The main contributions are summarized combining fog computing and secret sharing technology to hide and
as follows: identify vehicle identities. However, the scheme requires collaboration

2
Z. Zhou, N. Wang, J. Liu et al. Vehicular Communications 49 (2024) 100832

among a certain number of fog servers to trace vehicles, leading to sig- Table 1
nificant communication and computation costs. Ullah et al. [28] used Notation Descriptions.
Hyperelliptic Curve Cryptography to build a heterogeneous signcryp-
Notations Descriptions
tion scheme providing CPPA for VANETs. It utilizes a key generation
center to generate keys, and roadside units know the real identity of 𝑇𝐴 Trusted authority
vehicles. Considering the multiple cloud servers in IoV, Cui et al. [3] 𝐷𝑀 Domain manager
designed a CPPA scheme to meet the diverse service requirements in 𝑅 Roadside units (RSUs nodes)
VANETs. But it needs a single trusted authority as a hub for vehicle regis- 𝑣 Vehicle nodes
tration and service scheduling, and the elliptic curve PID is generated by 𝑚 Parameter for key derivation
vehicles, placing computational demands on them. The temporary PID 𝐺𝐶 Global blockchain
generation in the aforementioned studies mostly relies on a center for 𝐿𝐶𝑖 Local blockchain of domain 𝑖
key generation, leading to significant operational and maintenance costs 𝐶𝑖 Blockchain of node 𝑖
for a single server which has a risk of a single point of failure. Trusted 𝐼𝐷𝑖 The unique identity of node 𝑖
authorities also have opaque operations, posing the risk of unfair ac-
𝑃 𝐼𝐷𝑖 The temporary pseudo-identity of node 𝑖
countability in case of incidents. Moreover, they lack a pseudo-identity
(𝑑, 𝑄) Key pair
update mechanism, each vehicle’s real identity corresponds to only one
𝐻(⋅) Hash computation
pseudo-identity, posing privacy leakage risks in subsequent interactions.
𝑆𝑖𝑔𝑛𝑜𝑑𝑒 Message signature of 𝑛𝑜𝑑𝑒
𝑠𝑙𝑗 Slot 𝑗
2.2. Blockchain for IoV privacy-preserving
𝑠𝑒𝑒𝑑 Random number seed of key
𝜆𝑖 Block issue parameter of domain 𝑖
To address the limitations of IoV systems that rely on a single institu-
𝜖 Malicious punishment parameter
tion to manage vehicles and centralized generate key pairs, an increasing
𝜖′ Inactive punishment parameter
number of studies are turning to distributed measures for vehicle man-
𝜁 Award parameter
agement [10]. Many blockchain-based schemes have been proposed to
ensure decentralized privacy-preserving in IoV systems to achieve public
censorship and immutability of transportation data [26,34]. Gupta et al.
[8] analyzed the security and privacy issues in connected autonomous intelligent and fair IoV charging service. Zhang et al. [38] introduce mul-
vehicles and proposed a blockchain-based secure and decentralized ar- tiple blockchains with the cross-chain mechanism into a multidomain
chitecture to mitigate them. Feng et al. [5] proposed a blockchain- IoV system for location-aware verifiable outsourcing data aggregation.
assisted privacy-preserving authentication system, which automatically Data providers of each data domain upload data to the corresponding
provides public key queries to vehicles through a smart contract, but re-
child blockchain. However, in the above work, the blockchains of each
lies on trusted authority to take charge of all key-related work. Zheng
domain are parallel which leaves management issues for data process-
et al. [40] designed an ID-based CPPA protocol using pseudonym tech-
ing.
nology, which has traceable anonymity but faces the challenge of ideal
Considering the different authorities for various nodes in the IoV
hardware requirements and cannot withstand leakage from certificate
system, there exist many works that utilize a double-layer blockchain
issuing agencies. Xie et al. [31] combined symmetric encryption with
architecture to improve the efficiency of blockchain-based IoV data
chameleon hash functions to implement blockchain-based anonymous
management. Kandah et al. [12] introduced a two-layer blockchain trust
cross-domain mutual authentication. Trusted agencies can obtain the
management model composed of platoon blockchains for each platoon
real identity of malicious vehicles through on-chain information com-
and a global blockchain. The platoon blockchains store localized trust
bined with chameleon hash, but the scheme fails to periodically update
values of vehicles, while the global blockchain stores the trust factors of
the PID, potentially leading to privacy leakage of the tracked vehicles.
all vehicles in the system. RSUs use trust-binding consensus to add data
As for PID update, Lu et al. [19] integrated blockchain with Merkle
from the platoon blockchain to the global blockchain. Lee et al. [14]
Patricia Tree to propose a new type of CPPA protocol with efficient
proposed a two layered blockchain-based reputation system in vehicu-
certificate revocation. Still, this protocol requires frequent interactions
lar networks, consisting of one-day message blockchains and a global
between vehicles and certificate-issuing agencies for anonymous certifi-
reputation blockchain, where the reputation of each vehicle is updated
cate generation. Lin et al. [16] proposed a CPPA based on the Ethereum
and permanently stored in the global vehicle reputation blockchain, and
blockchain using smart contracts, but its key generation and revoca-
the one-day message blockchains store local traffic information, with
tion depend on CA invoking smart contracts, leading to on-chain gas
RSUs and vehicles acting as blockchain nodes. Ruan et al. [24] proposed
expenses, and key revocation is initiated by the CA too. If a node needs to
a double-layer blockchain trust management system for vehicular net-
verify the validity of a message, it needs to retrieve all ID index informa-
works, including a vehicle blockchain and an RSU blockchain. Nodes can
tion on the blockchain, which is a costly process. Liu et al. [17] proposed
choose which chain to store messages based on their importance. The
a 5G IoV CPPA scheme based on the Elliptic Curve Diffie-Hellman prob-
vehicle consortium chain temporarily stores unimportant information
lem. It uses a hierarchical pseudo-identity mechanism to protect the
generated by vehicles and deletes it every hour, while the RSU private
vehicles’ real identities while enabling the recovery of the information of
chain stores vehicle trust values and important messages generated us-
malicious vehicles through corresponding pseudo-identities when nec-
ing logistic regression. However, the above studies lack consideration of
essary. However, the EC-based keys are challenging to apply in complex
vehicles’ activities and thus did not provide details on the data interac-
hierarchical IoV systems.
tion between different local chains. Moreover, vehicles can obtain the
information of others from anywhere, posing a risk of privacy leakage.
2.3. Blockchain framework for IoV system

As the large size of the IoV coverage and the highly dynamic net- 3. Problem definition
work topology because of vehicles’ mobility, many studies introduce
multiple blockchains to manage data in different areas with low latency. In this section, we formulate the system model and discuss the secu-
Li et al. [15] let each IoV area independently maintain a blockchain rity model. A summary of the notations used in this article is presented
reducing the internal communication delay of the vehicles to realize in Table 1.

3
Z. Zhou, N. Wang, J. Liu et al. Vehicular Communications 49 (2024) 100832

Fig. 1. IoV double layers blockchain framework.

3.1. System model ers to maintain the global blockchain, managing node registrations,
node reputation values, and significant traffic events. Along with
In the hierarchical IoV scenario, vehicle data is collected and pack- the RSUs and vehicle nodes with additional computational power,
aged by the roadside units in their respective domains. Different domain DMs maintain their domain blockchains, that manage nodes’ in-
managers individually control and manage the behavior of RSUs and formation and traffic events. Moreover, for malicious vehicles dis-
vehicle nodes in the corresponding IoV domains. Due to the frequent seminating false information, DMs can associate and retrieve all
joining and leaving of vehicle nodes in each domain and the data in- messages and footprints published by malicious vehicles, reporting
teraction between different domains, it is necessary to design an appro- them to the global blockchain network for punishment.
priate blockchain framework and data-sharing mechanisms to achieve 3. Road Side Unit: RSUs, serving as roadside infrastructure, are widely
efficiency and security requirements. This paper presents a double-layer distributed along roadways. While their computing and storage ca-
blockchain conditional privacy-preserving IoV framework, as illustrated pabilities are slightly weaker than those of DMs, they still possess
in Fig. 1. The framework consists of entities such as the Trusted Author- significantly greater computing and storage capacity than vehicle
ity (TA), Domain Managers (DMs), Road Side Units (RSUs), and vehicles. nodes. RSUs are crucial in facilitating inter-vehicle communication,
A DM along with the RSUs in its domain, collectively serve as nodes on providing real-time traffic information to vehicles, and offering
the local domain blockchain to share and supervise domain data. As temporary pseudo-identity (PID) registration services for vehicles
data on the local domain blockchain continues to grow, DMs periodi- entering their coverage area. Furthermore, for malicious vehicles
cally broadcast important data summaries and node reputation data to that register at RSUs and exhibit dishonest behavior within their
the global blockchain network. Under the supervision of the TA and the coverage area, RSUs can detect and associate those behaviors, and
collective participation of DMs and some RSUs with high reputations, then report them to DMs for further verification.
critical data within the IoV system is packaged and permanently stored 4. Vehicle: Vehicle nodes constitute the most numerous and essential
on the global blockchain. Only nodes with the corresponding permis- components in the IoV system. They possess limited computing and
sions can access the specific content of the data. A detailed description storage capabilities. Upon joining the IoV, vehicles register at the
of each entity is provided below: TA to obtain a unique identity identifier (ID), which only the TA can
access the specific vehicle owner’s identity information correspond-
1. Trusted Authority: TA is a trustworthy entity with sufficient com- ing to the ID. Each time a vehicle enters a new domain, it registers
puting and storage resources. It is responsible for managing the at the nearest RSU to obtain a temporary PID in the current area.
public keys and certificates of vehicles, DMs, and RSUs. TA directly This PID is used to participate in domain blockchain consensus and
generates keys for DMs and supervises the global blockchain, stor- share messages. Upon entering the next domain, the RSU in that
ing the keys, identities, and important information of all nodes. domain will issue a new PID for the vehicle and deregister the pre-
Additionally, TA can use its master key to trace all transaction in- vious PID from the previous domain.
formation corresponding to the issued subkeys and retrieve the real
identity of the target node from the blockchain. It is the only en- This paper adopts a double-layer blockchain framework for efficient IoV
tity capable of obtaining the complete real identities of all vehicles identity authentication and data management, which includes a global
from intercepted messages and penalizing dishonest nodes. blockchain for storing overall identity information and crucial events
2. Domain Manager: DMs serve as powerful cloud servers within each and local domain blockchains for storing traffic data within specific
domain, authorized by TA to provide registration, authentication, areas. The upper-layer nodes utilize the dynamic PBFT consensus al-
and revocation services for the RSUs under their management. The gorithm on the global blockchain to efficiently package important IoV
entire IoV system is composed of multiple domains, with each DM system data and simultaneously detect malicious nodes. The detection
offering direct or indirect services to the vehicle nodes in its re- of upper-layer consensus participation node crashes can be identified
sponsible area. In the double-layer blockchain architecture, DMs through the forwarded pre-prepare and preparation of data. Once a
act as full nodes in both the global blockchain and their domain Byzantine fault occurs in the upper-layer node, TA will directly penalize
blockchain. They collaborate with other upper-level nodes as min- it and reassess its reputation. Lower-layer nodes maintain their local do-

4
Z. Zhou, N. Wang, J. Liu et al. Vehicular Communications 49 (2024) 100832

main blockchain, using PIDs to protect privacy conditionally. Although blockchain consensus behavior. This could mask violations by vehicles
vehicles are aware of the credibility level and PIDs of nearby vehicles, or selfish mining to gain more block rewards and consensus control.
the overall activities of vehicles are not disclosed to any other nodes. Assuming IoV system nodes may experience two types of faults:
The double-layer blockchain is described as follows: crashes and Byzantine faults. In the event of a crash fault, a node will
cease participating in consensus and stop responding to received mes-
• Global main blockchain (GC): The upper-layer nodes, jointly main- sages. Byzantine attacks may involve RSUs maliciously controlling ve-
tained by TA, DMs, and some highly trusted RSUs, record trust hicle nodes within their coverage area for passive dishonest operations.
values, encrypted violation records, and significant traffic incidents In Byzantine faults, nodes may send incorrect messages, reject message
in the blocks. When a vehicle enters a new domain, it requests a transmission, or send messages out of order. For a Dynamic PBFT con-
temporary PID from the RSU in that area. The RSU, through DM, sensus with 3𝑓 + 1 upper-layer nodes, it can tolerate 𝑓 Byzantine fault
confirms the vehicle’s identity based on the main chain and sub- nodes. For a PoS consensus with 𝑛 domain nodes, it can tolerate 𝑛∕2
sequently issues a PID. When a vehicle is found to have malicious Byzantine nodes.
behavior, the RSU will report it to DM. DM verifies the report based
on the corresponding key and reports it to TA for final confirmation. 3.2.2. Secure requirements
The upper-layer nodes then package and record the information in This paper’s IoV data-sharing scheme needs to meet the following
the global chain block. security requirements:
• Local domain blockchain (DC): The local layer of our system is a
zonal blockchain covering several domains which consist of sev- (a) Message authentication: Entities authorized by TA, such as DMs,
eral local blockchains. Each domain maintains a local domain RSUs, and vehicles, can verify their legitimate entity identities
blockchain, collectively managed by the DM, RSUs, and some vehi- based on the corresponding chains. Messages sent by authenticated
cle nodes within that domain. The blocks in this blockchain record entities can be proven to be correct, with no modifications or forg-
traffic information within the domain and the driving records corre- eries.
sponding to each PID. RSUs provide temporary identity registration (b) Conditional privacy-preserving authentication: Only legitimate re-
services for vehicles, and the temporary registration information is cipients can access the content of messages sent by vehicles, which
stored in the local domain blockchain. The responsible RSU and may contain sensitive information. Except for authorized nodes, no
DM can then access the behavioral information of registered vehi- other entity can obtain the real identity information corresponding
cles. The domain blockchains between different domains can utilize to the data based on the messages sent or intercepted by vehicles.
cross-chain technology to share registration information, and traf- (c) Traceability and unlinkability: TA can trace all activities of mali-
fic data, and facilitate data interaction and service provision among cious nodes, while DMs and RSUs can trace all activities of nodes
vehicles across domains. using a specific temporary PID within their jurisdiction. Except for
TA, DMs, and RSUs can only link multiple messages within their
As shown in Fig. 1, when the vehicle 𝑣 transitions from domain 3 coverage area to the same entity. Other nodes cannot link multiple
to domain 2, it first needs to send a handover request {ℎ𝑎𝑛𝑑𝑜𝑣𝑒𝑟, 𝑃 𝐼𝐷, messages from the same entity in different zones.
𝑑𝑒𝑠𝑡𝑖𝑛𝑎𝑡𝑖𝑜𝑛, 𝑠𝑖𝑔𝑣 } to 𝑅𝑆𝑈{3} in domain 3. Here, 𝑃 𝐼𝐷 is the temporary (d) Blockchain security: Both the global main chain and domain sub-
key used by vehicle 𝑣 in domain 3, 𝑑𝑒𝑠𝑡𝑖𝑛𝑎𝑡𝑖𝑜𝑛 is the target area domain chains can not be taken over that aim to control information records
2 for vehicle 𝑣, and 𝑠𝑖𝑔 is the signature. Subsequently, 𝑅𝑆𝑈{3} will
and achieve double-spending or data tampering.
broadcast the vehicle’s handover message on the domain blockchain in
domain 3 and coordinate with 𝑅𝑆𝑈{2} in domain 2 to assign a new
4. Proposed scheme
temporary key and 𝑃 𝐼𝐷′ for the vehicle in domain 2. At this point,
𝑣 can use the new identity 𝑃 𝐼𝐷′ to participate in the IoV system in
This section begins by presenting a hierarchical key distribution and
domain 2.
temporary PID issuance scheme for entities in the IoV to achieve CPPA.
Following that, a double-layer blockchain consensus mechanism tai-
3.2. Secure model
lored for multi-domain IoV is introduced. Finally, a cross-chain data
interaction mechanism between domains is provided to enable data ex-
3.2.1. Secure assumption
change and service provision for vehicles across different areas.
Assuming TA, as the authenticator of node identities, is entirely
trustworthy, and only TA possesses knowledge of the true identities of
vehicles. TA, DM, and RSU, due to their fixed geographical locations, 4.1. Conditional privacy-preserving authentication
communicate through wired connections which are assumed secure.
RSU and DM, in tracking malicious vehicles, can use their keys to obtain 4.1.1. Hierarchical deterministic wallets
the driving trajectories and communication messages of vehicles within Currently, in many IoV systems, a large number of public/private
their coverage areas. Any entity in the model must strictly protect its key pairs and corresponding certificates need to be preloaded onto the
private keys. onboard devices of vehicles to achieve anonymous identity manage-
System attackers include external attackers and internal attackers. ment. This practice imposes certain demands on the storage space and
External attackers do not directly participate as entities in the IoV but computational capability of vehicles to manage these key pairs and cer-
may act as passive eavesdroppers, monitoring public communication tificates. To avoid that, [16] introduces the key derivation algorithm
channels, and attempting to obtain the real identities of vehicles, their used in the hierarchical deterministic wallets (HD Wallet). HD Wallets
driving trajectories, and encrypted messages. Internal attackers are en- alleviate much of the burden of wallet maintenance by generating a
tities within the IoV, such as vehicles, RSUs, and DMs. They may act pseudo-random sequence of child private keys from a master private
as passive eavesdroppers, monitoring public or secure communication key 𝑑̂, as defined in the Bitcoin Improvement Proposal 32 (BIP32) [9],
channels, attempting to obtain confidential information beyond what treat each child key as a new master private key. This allows the gener-
they are supposed to have initially. They may also collude with mali- ation of new child private key sequences infinitely. Corresponding child
cious vehicles or other corrupted nodes to gain profits, frame honest public keys can be generated by anyone who knows the master public
vehicles conflicting with their interests, or conceal the behavior of ma- key, and the entire hierarchical structure of private keys in the wallet
licious vehicles. For example, they may prevent honest traffic informa- can be recovered from the knowledge of 𝑑̂. HD Wallets possess the mas-
tion from being packaged into the blockchain by engaging in dishonest ter public key property, where users can create and publish a master

5
Z. Zhou, N. Wang, J. Liu et al. Vehicular Communications 49 (2024) 100832

Algorithm 1 Data tracing algorithm Data traceability.

𝑉
Input: 𝑃 𝐼𝐷{𝑖} : The temporary identity of malicious vehicle 𝑣 in domain 𝑖
𝐿𝐶𝑖 , 𝐿𝐶𝑗 : The local chain of domain 𝑖, 𝑗
𝐺𝐶 : The global chain 𝑀𝐾 : The master key
1: function 𝐷𝑎𝑡𝑎 − 𝑡𝑟𝑎𝑐𝑖𝑛𝑔
𝑉
2: 𝐷𝑀𝑖 receive the malicious behavior claim for 𝑃 𝐼𝐷{𝑖} from other nodes
𝑉
3: 𝐷𝑀𝑖 find the register information of 𝑃 𝐼𝐷{𝑖} in 𝐿𝐶𝑖 :
𝑉 𝑉
{𝑃 𝐼𝐷{𝑖} , 𝐸𝑛𝑐𝑅{𝑖} (𝐼𝐷𝑉 , 𝑠𝑒𝑒𝑑{𝑖} ), 𝑠𝑖𝑔𝑅{𝑖} } ← 𝐿𝐶𝑖
𝑉
4: 𝐷𝑀𝑖 check the message of 𝑃 𝐼𝐷{𝑖} and report it’s malicious behaviors to
TA
5: TA collect the domain record 𝑑𝑜𝑚𝑎𝑖𝑛𝐿𝑜𝑔 𝑉 of 𝐼𝐷𝑉 according to 𝐺𝐶
Fig. 2. Hierarchical keys. 6: for all domain 𝑗 in 𝑑𝑜𝑚𝑎𝑖𝑛𝐿𝑜𝑔 𝑉 do
7: TA obtain the 𝑘𝑒𝑦𝐷𝑀{𝑗} from 𝐺𝐶 using its 𝑀𝐾 : 𝑘𝑒𝑦𝐷𝑀{𝑗} ← 𝐺𝐶, 𝑀𝐾
8: TA obtain the 𝑘𝑒𝑦𝑅{𝑗} from 𝐿𝐶𝑗 using 𝑘𝑒𝑦𝐷𝑀{𝑗} : 𝑘𝑒𝑦𝑅{𝑗} ← 𝐿𝐶𝑗 , 𝑘𝑒𝑦𝐷𝑀{𝑗}
public key 𝑄̂ , from which anyone can generate a sequence of child pub-
9: TA obtain the PID registrations of 𝐼𝐷𝑉 with the 𝑘𝑒𝑦𝑅{𝑗} :
lic keys {𝑄1 , 𝑄2 , ⋯} corresponding to child private keys {𝑑1 , 𝑑2 , ⋯}. 𝑉
{𝑃𝐼𝐷{𝑗} 𝑉
, 𝐸𝑛𝑐𝑅{𝑗} (𝐼𝐷𝑉 , 𝑠𝑒𝑒𝑑{𝑗} ), 𝑠𝑖𝑔𝑅{𝑗} } ← 𝐿𝐶𝑗 , 𝑘𝑒𝑦𝑅{𝑗}
We expand the key derivation algorithm of HD wallet in our double-
10: TA obtains 𝑘𝑒𝑦𝑉{𝑗} and decodes 𝑎𝑐𝑡𝑖𝑣𝑖𝑡𝑦𝐿𝑜𝑔{𝑗} 𝑉
layer and zonal IoV blockchain structure, compared with [16], which 11: end for
only uses a single tier of hierarchical key with one dimension. In our 12: TA checks the data validation and decides the punishment according to
IoV system comprising 𝑡 domains, we randomly choose 𝑚 master pri- 𝑎𝑐𝑡𝑖𝑣𝑖𝑡𝑦𝐿𝑜𝑔 𝑉
vate keys {𝑑̂1 , 𝑑̂2 , … , 𝑑̂𝑚 } ∈ ℤ𝑝 , where 𝑚 > 𝑡. Considering a generic 13: TA update 𝑠𝑡𝑎𝑘𝑒𝑉 of vehicle 𝑣 in 𝐺𝐶
additive group 𝔾 of prime order 𝑝 with generator 𝑃 ∈ 𝔾. We gener- 14: end function
ate the corresponding master public keys {𝑄̂1 , 𝑄̂2 , … , 𝑄̂𝑚 } based on
the formula 𝑄̂ 𝑖 = 𝑑̂𝑖 𝑃 . Let 𝑠 be the public master seed, a hash function
behavior and data interactions of any node in the entire IoV system.
ℎ𝑎𝑠ℎ(𝑖, 𝑠) → (𝛼1𝑖 , … , 𝛼𝑚𝑖 ) is employed to produce an 𝑚-tuple of integers
Key derivation is performed by the parent node. Given the parent key
modulo 𝑝. The 𝑖-th child private key 𝑑𝑖 and public key 𝑄𝑖 are calculated
as follows: 𝑄̂ = {𝑄̂1 , 𝑄̂2 , ⋯ , 𝑄̂𝑚 } and 𝑑̂ = {𝑑̂1 , 𝑑̂2 , ⋯ , 𝑑̂𝑚 }, for each node 𝑖 that needs
to derive a key, the parent node uses an oracle to generate 𝑚 random
𝑚
∑ numbers 𝑠𝑒𝑒𝑑𝑖 = {𝛼1 , ⋯ , 𝛼𝑚 } for it. Then, it generates the child key
𝑑𝑖 = 𝛼𝑗𝑖 𝑑̂𝑗 ∑ ∑𝑚
𝑗=1
𝑑𝑖 = 𝑚 ̂
𝑗=1 𝛼𝑗 𝑑𝑗 and 𝑄𝑖 =
̂
𝑗=1 𝛼𝑗 𝑄𝑗 for node 𝑖. When a vehicle 𝑣 en-
𝑚
(1) ters a new domain, RSU generates a new key pair (𝑑𝑣 , 𝑄𝑣 ) based on its
∑
𝑄𝑖 = 𝛼𝑗𝑖 𝑄̂ 𝑗 RSU key. The corresponding 𝑄𝑣 and 𝑠𝑒𝑒𝑑𝑣 are transmitted to DM, then
𝑗=1 encrypted and packaged into the blockchain. DM, using 𝑄𝑣 and 𝑠𝑒𝑒𝑑𝑣
sent by RSU 𝑅, can derive the key for vehicle 𝑣 using 𝑅’s 𝑠𝑒𝑒𝑑𝑅 . This
Each child private key 𝑑𝑖 is a random linear combination of the mas-
means that DM can trace all the behaviors of vehicle 𝑣 without interact-
ter private keys. An adversary compromising one child private key can
ing with it, and TA can use the same method to trace the behavior of all
not recover any private keys. Possessing only one 𝑄̂ 𝑗 out of the 𝑚 keys
nodes in the entire IoV system.
is insufficient to generate any child keys. This ensures a level of privacy
and security in the IoV structure, as knowledge of the master public key
4.1.3. Data tracing
alone does not compromise other keys.
The hierarchical key derivation scheme presented in this paper can
support the IoV system in achieving conditional privacy-preserving data
4.1.2. Hierarchical IoV key derivation scheme
tracing. Specifically, apart from the RSU directly generating a tempo-
To achieve vehicle identity anonymity, enhance communication se-
rary PID for the vehicle, only the manager of the RSU’s corresponding
curity, and reduce the storage and computational burden on each node,
domain and the TA can trace the behavior of the vehicle node in the
a hierarchical key derivation mechanism based on HD Wallets is pro- 𝑉 has
RSU’s domain. Assuming a node reports that a vehicle 𝑣 with 𝑃 𝐼𝐷{𝑖}
posed. In this mechanism, a higher-level node with a master key can
generate multiple sub-keys for nodes under their supervision. TA, as the disseminated malicious information in domain 𝑖, the manager 𝐷𝑀{𝑖}
𝑉 on its local domain
will search for information corresponding to 𝑃 𝐼𝐷{𝑖}
highest trusted authority node, periodically generates a master key and,
based on reputation assessment, generates DM child keys distributed to chain 𝐿𝐶𝑖 . Using the signature, 𝐷𝑀{𝑖} can identify the responsible RSU
reliable DMs. Subsequently, a DM generates RSU grandchild keys based 𝑉 . Since the key of RSU is generated by 𝐷𝑀 ,
𝑅𝑖 for generating 𝑃 𝐼𝐷{𝑖} {𝑖}
on its updated DM key and distributes them to RSUs within its domain. 𝐷𝑀{𝑖} can unlock the encrypted 𝑃 𝐼𝐷 generation seed 𝑠𝑒𝑒𝑑{𝑖} 𝑉 by 𝑅
𝑖
An RSU uses the RSU key as the parent key for generating temporary and obtain all the behaviors of 𝑣 in domain 𝑖. If 𝐷𝑀𝑖 confirms mali-
keys used by vehicles entering its area, forming temporary PIDs for mes-
cious behavior by vehicle 𝑣 in domain 𝑖, 𝐷𝑀{𝑖} will report the malicious
sage authentication within that area.
behavior to TA. TA then retrieves all the domains where vehicle 𝑣 has
The key derivation scheme is illustrated in Fig. 2, where sub-
recently appeared on the global blockchain based on the vehicle 𝑣’s 𝐼𝐷.
keys are generated layer by layer from their parent keys. TA gener-
If it is discovered that 𝑣 has recently appeared in domain 𝑗 , TA uses a
ates DM keys 𝐾𝐸𝑌 𝐷𝑀 = {𝑘𝑒𝑦𝐷𝑀{1} , 𝑘𝑒𝑦𝐷𝑀{2} , ⋯} based on the mas- 𝑉 for 𝑣 in domain 𝑗 and requests 𝐷𝑀
similar method to obtain 𝑃 𝐼𝐷{𝑗} {𝑗}
ter key by (1) and sends them to the corresponding domain man- 𝑉 in domain 𝑗 to en-
agers through specific channels. Here, the key pair of 𝐷𝑀{𝑖} is de- to collect and report all the behaviors of 𝑃 𝐼𝐷{𝑗}
noted as 𝑘𝑒𝑦𝐷𝑀{𝑖} = (𝑑 𝐷𝑀{𝑖} , 𝑄𝐷𝑀{𝑖} ), where the subscript {𝑖} indi- sure the security impact of vehicle 𝑣 on the system. The details of data
cates that the node belongs to domain 𝑖. Similarly, 𝐷𝑀{𝑖} generates traceability are shown in Algorithm 1.
𝑅𝑆𝑈{𝑖}
1 𝑅𝑆𝑈 2
𝐾𝐸𝑌 𝑅{𝑖} = {𝑘𝑒𝑦 , 𝑘𝑒𝑦 {𝑖} , ⋯} based on 𝑘𝑒𝑦𝐷𝑀{𝑖} and distributes
4.2. The IoV double layer blockchain framework and consensus
them to RSUs in domain 𝑖. For each RSU 𝑅{𝑖}𝑗 in domain 𝑖, grandgrand-
𝑗 𝑗
𝑉 (1) 𝑉 (2)
child keys {𝑘𝑒𝑦 {𝑖} , 𝑘𝑒𝑦 {𝑖} , ⋯}
are generated for nodes registering Due to the wide coverage and hierarchical complexity of the ac-
in RSU’s area. In this way, RSU can access the behavior of vehicles tual IoV system, this paper adopts a zonal double-layer blockchain for
within its responsible area; DM can access all behaviors of vehicles the management of IoV data-sharing. The double-layer blockchain con-
and RSUs in its domain; and TA can use the master key to trace the sists of a global blockchain and domain blockchains, as illustrated in

6
Z. Zhou, N. Wang, J. Liu et al. Vehicular Communications 49 (2024) 100832

Fig. 1. The upper layer maintains a global blockchain, where participat-

ing nodes including TA, all DMs, and some RSUs selected by TA based
on their stake determined by factors such as credibility and activity. The
global blockchain stores the trust values of all participating nodes and
summaries of important messages generated by assessed nodes, facilitat-
ing future vehicles or regulators to request relevant information accord-
ing to their needs and interests. The lower layer is composed of multiple
domain blockchains. The maintainers of each domain blockchain are
the respective DM, all RSUs, and some vehicles with additional compu-
tational power confirmed by DM. Domain blockchain data is stored by
the domain DM and RSUs. When a vehicle detects an event, such as road
congestion or a traffic accident, it sends a message to RSU to report the
event. Upon receiving the message, the RSU decides whether to package Fig. 3. Vehicle register.
the message into the global blockchain or the domain blockchain based
on its importance. Generally, domain blockchains store less critical mes-
sages, such as vehicle speed, direction, and waiting time uploaded by
vehicle sensors. For crucial information, nodes can directly find it on
the global blockchain, and for data of interest to domain nodes, they
can quickly obtain data from nearby RSUs or full nodes from domain
blockchain. This design improves efficiency, allowing nodes to quickly
locate the desired data category for retrieval.
Each DM serves as a distributed storage server, storing all global
blockchain data. DMs have the right to view and trace specific data
generated by nodes in their managed domains, while other data require
further authorization from TA. When vehicles join the system, they need
to register through RSUs. RSUs can only trace specific data generated
by nodes they are responsible for registering, while other data in the do- Fig. 4. IoV data-sharing.
main blockchain requires further authorization from DM. Through the
above management approach, conditional privacy-preserving authenti- tity registration request to the nearest RSU. The RSU generates a
cation of vehicle data is achieved. The messages broadcasted in the IoV temporary identity 𝑃 𝐼𝐷 = 𝑑𝑣 , 𝑄𝑣 for the vehicle by the key deriva-
system which are signed by a valid PID are authenticated. Due to the tion scheme. Then it signs and broadcasts the PID register message
temporary PID of vehicles changing as they move to different domains, 𝑡𝑒𝑚𝑝 − 𝑟𝑒𝑔𝑖𝑠𝑡𝑒𝑟 = {𝑃 𝐼𝐷𝑣 , 𝐸𝑛𝑐𝑅𝑆𝑈 (𝑃 𝐼𝐷𝑣 , 𝑠𝑒𝑒𝑑𝑣 , 𝑐𝑒𝑟𝑡𝑣 ), 𝑆𝑖𝑔𝑅𝑆𝑈 } to
adversaries can only associate the activities of a vehicle using its PID for the domain blockchain network. The vehicle identity registration is
a certain period within a certain area. Even if an adversary completely illustrated in Fig. 3.
compromises an RSU node, the data they can access is limited. How- (c) Data sharing: A vehicle uses its 𝑃 𝐼𝐷 to interact with other nodes
ever, a DM can trace the behavior of a vehicle in the whole domain, and and signs the outgoing messages in the corresponding domain. The
the TA has the right the access all driving information while needed. message receiver (such as RSU or other vehicles) checks the signed
data based on the information on the domain blockchain for au-
4.2.1. The IoV identity management and data sharing thentication. If a vehicle 𝑣 detects a traffic accident or any other
This part provides details on the management and sharing of vehicle event while driving, 𝑣 can broadcast this event with its signa-
data in the proposed IoV data-sharing scheme. ture as message {𝑑𝑎𝑡𝑎 − 𝑠ℎ𝑎𝑟𝑖𝑛𝑔, 𝑚, 𝑃 𝐼𝐷𝑣 , 𝑠𝑖𝑔𝑣 }. The surrounding
nodes will verify 𝑚 based on the 𝑃 𝐼𝐷𝑣 information on the do-
(a) System initialization: This phase is jointly executed by the TA and main blockchain 𝐿𝐶 . The nearest RSU will help upload the traffic
DMs. TA first generates the master key and, using a random num- event in the form {𝐸𝑉 𝐸𝑁𝑇 , 𝑖𝑑𝑒𝑣𝑒𝑛𝑡 , 𝑚, 𝑃 𝐼𝐷𝑣 , 𝑠𝑖𝑔𝑅𝑆𝑈 }. After then,
ber generator, derives DM Keys from the master key and distributes it generates an IoV data-sharing reward transaction for the vehicle
them to each DM. The initialization information of DMs is then {𝐴𝑊 𝐴𝑅𝐷, 𝑖𝑑𝑎𝑤𝑎𝑟𝑑𝑡𝑥 , 𝑖𝑑𝑒𝑣𝑒𝑛𝑡 , 𝑃 𝐼𝐷𝑣 , 𝑠𝑖𝑔𝑅𝑆𝑈 } into 𝐿𝐶 , as illustrated
packaged into the first block of the global blockchain. DMs similarly in Fig. 4.
derive RSU keys for each RSU in their domain from the DM Keys (d) Cross-domain handover: When a vehicle from domain 1 wishes to
and package the RSU initialization information into the first block enter domain 2 but is uncertain about the traffic conditions in do-
of the corresponding domain blockchain. Simultaneously, RSU reg- main 2, it submits a traffic situation request to 𝑅𝑆𝑈{1} in domain
istration information is broadcasted to the global blockchain net- 1 and pays a certain fee. 𝑅𝑆𝑈{1} then requests data from domain 2
work, initiating the first DPBFT consensus in the global blockchain RSU 𝑅𝑆𝑈2 and sends it to the vehicle. If this vehicle with 𝑃 𝐼𝐷{1}
and packaging the information into the second block of the global decides to go to domain 2, it submits a handover request to 𝑅𝑆𝑈{1} .
blockchain. After initialization, the global blockchain stores DMs’ 𝑅𝑆𝑈{1} selects a suitable RSU 𝑅𝑆𝑈{2} in the next domain, com-
information encrypted with the TA master key and RSU key set pletes the identity transfer, and stores the transferred data to revoke
𝐾𝐸𝑌 𝑅 encrypted and signed by each DM. 𝑃 𝐼𝐷{1} on the domain blockchain 𝐿𝐶{1} . After entering the next
(b) Vehicle registration: For vehicles newly joining the IoV system, TA domain, the vehicle obtains a new temporary PID 𝑃 𝐼𝐷{2} from
generates a unique tag 𝐼𝐷 for each vehicle corresponding to its 𝑅𝑆𝑈{2} , and has the 𝑅𝑆𝑈{2} upload the information of the ve-
real identity. TA will also issue a certification whose information hicle’s entry to the domain blockchain 𝐿𝐶{2} . Subsequently, the
is encrypted and stored on the global blockchain to the vehicle in vehicle can use the 𝑃 𝐼𝐷{2} to operate in domain 2, and 𝑅𝑆𝑈{1} is
the form {𝑐𝑒𝑟𝑡𝐼𝐷 , 𝐸𝑛𝑐𝑇 𝐴 (𝐼𝐷), 𝑠𝑡𝑎𝑘𝑒𝑖𝑛𝑖𝑡 , 𝑆𝑖𝑔𝑇 𝐴 }, where 𝑐𝑒𝑟𝑡𝐼𝐷 rep- unable to track the activities of this vehicle.
resents the unique initial certificate for each vehicle, and 𝑠𝑡𝑎𝑘𝑒𝑖𝑛𝑖𝑡 (e) Node information update: Each DM summarizes and broadcasts the
is the initial stake value of the vehicle. In subsequent IoV data in- changes in node stake on its domain blockchain caused by data
teractions, vehicles use the 𝑐𝑒𝑟𝑡𝐼𝐷 to request a temporary 𝑃 𝐼𝐷 for sharing or malicious behavior to the global blockchain network ev-
interactions in each domain from RSUs. For a vehicle 𝑣 that has ery epoch. Additionally, DM sends information about the entry and
just entered a specific domain, the vehicle sends a temporary iden- exit of vehicles and the PIDs used during the current epoch to TA.

7
Z. Zhou, N. Wang, J. Liu et al. Vehicular Communications 49 (2024) 100832

Fig. 5. Topology of the proposed double-layer IoV blockchain system.

Each epoch, TA confirms and broadcasts the digest of stake and tra- to send data that needs to be packaged onto the global blockchain in the
jectory information of each node to the global blockchain, which next epoch into the global chain network. After completing the commit
is then packaged into a block in 𝐺𝐶 by the leader of the global phase, DM sends the global PBFT result and organized data (typically
blockchain in that epoch. For nodes exhibiting malicious behavior, stake update information and important traffic data in the domain it
TA imposes stake penalties. Let 𝑠𝑡𝑎𝑘𝑒𝑛,𝑘 be the stake value of node manages) to TA. TA updates the stake of each node based on the data
𝑛 in the 𝑘-th epoch, and 𝜖 be the penalty factor. The stake of this uploaded by DM and the registration information of nodes. This infor-
node in the next epoch will be updated as follows: mation is signed and included in the content of the next epoch’s block.
After several epochs, TA initiates a view reset with changes in partici-
𝑠𝑡𝑎𝑘𝑒𝑛,𝑘+1 = 𝑚𝑎𝑥(𝑠𝑡𝑎𝑘𝑒𝑛,𝑘 ⋅ (1 − 𝜖), 0) (2) pating nodes in the IoV system. It updates new participating nodes in the
global blockchain based on the past activities of nodes. During the pre-
For nodes that have crashed, such as 𝑅𝑆𝑈 nodes that have been
prepare phase, it designates a new primary node for the next epoch and
inactive for an extended period, if they have not engaged in mes-
attaches information about other participating nodes and the duration of
sage forwarding or key generation tasks for consecutive 𝑙 slots, their
the new epoch. The designated node confirms with other participating
stake will be updated as follows:
nodes through the prepare and commit phases. The DPBFT algorithm is
illustrated in Algorithm 2. TA designates 4𝑓 trusted upper-layer nodes
𝑠𝑡𝑎𝑘𝑒𝑛,𝑘+𝑙 = 𝑚𝑎𝑥(𝑠𝑡𝑎𝑘𝑒𝑛,𝑘 ⋅ (1 − 𝜖 ′ ), 0) (3)
each epoch to participate in PBFT consensus, ensuring the system’s se-
For nodes actively participating in consensus verification and data curity when the number of corrupt nodes is less than 𝑓 . Each round of
sharing, TA will reward them with stake. Their stake for the next consensus execution involves five stages: request, pre-prepare, prepare,
epoch will be: commit, and reply.

𝑠𝑡𝑎𝑘𝑒𝑛,𝑘+1 = 𝑚𝑖𝑛(𝑠𝑡𝑎𝑘𝑒𝑛,𝑘 ⋅ (1 + 𝜁), 1) (4) (a) Request stage: The request command is initiated by TA and directly
sent to the primary node for the current epoch. The request informa-
4.2.2. The upper layer blockchain consensus tion includes the participant node information for the epoch 𝐺(𝐼𝐷),
Our double-layer IoV system employs a double-layer blockchain con- the data digest 𝑥 that needs to be updated, and the epoch number
sensus for data management. In the global permissioned blockchain 𝑒𝑝𝑜𝑐ℎ − 𝑖𝑛𝑖𝑡 = {𝑟𝑒𝑞𝑢𝑒𝑠𝑡, 𝐺(𝐼𝐷), 𝑝𝑒𝑟𝑖𝑜𝑑, 𝑒𝑝𝑜𝑐ℎ, 𝐻(𝑥), 𝑠𝑖𝑔𝑇 𝐴 }. Once
consensus, fixed participants include all DMs and RSUs selected by the primary node verifies the correctness of the request command,
TA based on each stake from different geographical locations. Com- it proceeds to the next stage.
pared to the local blockchain, the global blockchain consensus has a (b) Pre-prepare stage: For the first epoch during a period, the primary
slower block generation speed, intended for preserving and synchro- node will send a pre-prepare message to the corresponding nodes
nizing nodes’ stakes, traffic events, vehicles’ register records, and PID based on 𝐺(𝐼𝐷). The pre-prepare message includes the updated
registration information from each domain. This paper designs an upper- stake set for each node as requested by TA, denoted as 𝑆𝑇 𝑠𝑒𝑡,
layer dynamic PBFT (DPBFT) consensus, where TA periodically updates and all the summaries of important traffic information received in
the list of RSUs participating in global layer consensus based on on- the current epoch, denoted as 𝑉 𝑇 𝑥𝑠. The primary node packages
chain stakes, that facilitates joint and distributed supervision. As shown these contents into a block and broadcasts it to the other upper-
in Fig. 5 for the global layer, the orange blocks in 𝐺𝐶 represent one layer nodes designated for this epoch. If other nodes verify the
round of DPBFT consensus, and each increase of a block in 𝐺𝐶 corre- pre-prepare message successfully, they proceed to the preparation
sponds to an epoch in the local layer’s domain blockchain. The 𝐺𝐶 block phase.
records important data appearing throughout the entire epoch in each (c) Prepare stage: During the prepare phase, each DM node not only
𝐿𝐶 . constructs the corresponding prepare messages but also sends
Requests in the global layer are triggered by TA. Based on network 𝑑𝑜𝑚𝑎𝑖𝑛𝑑𝑎𝑡𝑎 − 𝑖𝑛𝑖𝑡 to the RSUs within its jurisdiction to initiate the
information, primary nodes issue blocks in the commit phase in each domain data aggregation for the new epoch. Simultaneously, RSUs
epoch, and other nodes jointly confirm and reach global data consen- in the upper-layer nodes begin assisting in the data aggregation for
sus. Additionally, before entering the commit phase, each DM issues a their respective domains. After initiating the data aggregation for
𝑐𝑜𝑚𝑚𝑖𝑡𝑑𝑜𝑚𝑎𝑖𝑛 request within its domain, causing RSUs in the domain the next epoch, upper-layer nodes broadcast prepare messages to

8
Z. Zhou, N. Wang, J. Liu et al. Vehicular Communications 49 (2024) 100832

Algorithm 2 DPBFT algorithm DPBFT.

Input: 𝐶𝑟𝑒𝑑𝑖𝑡𝑅𝑆𝑈 : credit set of all RSUs
𝐺(𝐼𝐷): ID of nodes in global layer
𝑘: number of RSUs to be chosen
𝑛𝑢𝑚𝐷𝑃 𝐵𝐹 𝑇 : number of PBFT round per epoch
1: function 𝐷𝑃 𝐵𝐹 𝑇
2: while True do
3: for 𝑖 = 1 to 𝑛𝑢𝑚𝐷𝑃 𝐵𝐹 𝑇 do
4: PBFT within 𝐺(𝐼𝐷)
5: end for
6: Update 𝐶𝑟𝑒𝑑𝑖𝑡𝑅𝑆𝑈 according to performance
7: sort top 𝑘 RSUs in 𝐶𝑟𝑒𝑑𝑖𝑡𝑅𝑆𝑈
8: Update 𝐺(𝐼𝐷) with top 𝑘 RSUs
9: end while
10: end function
Fig. 6. Cross-chain proof.

other nodes. While participating in consensus confirmation, they

also signify that the data aggregation for the next epoch in their re- content of block 𝐵1 , the adversary would also need to manipulate 𝐵2
spective domains has commenced. Upon receiving 2𝑓 + 1 prepare in 𝐿𝐶2 , which references the state of 𝐵1 , and 𝐵4 in 𝐿𝐶3 , which ref-
messages, upper-layer nodes mutually confirm that the lower-layer erences the state of 𝐿𝐶2 . In other words, for a successful attack, the
nodes in various domains have begun preparing for the next epoch adversary must construct three new adversary chains, resulting in a cost
data, and the upper-layer nodes enter the commitment phase. far exceeding the attack on a single domain chain without mutual ver-
(d) Commit stage: The upper-layer node aggregates important domain ification. In scenarios like determining liability in traffic accidents or
data sent by lower-layer nodes during an epoch. After observing confirming malicious node behavior, tracing the travel sequence of in-
that the data from its own domain has been broadcast, the upper- dividual nodes is often necessary. However, due to block node selection
layer node sends a commit message to other upper-layer nodes. and network delay, achieving complete synchronization between do-
Upon receiving 2𝑓 + 1 commit messages, the upper-layer node com- main chains in different areas is challenging. Therefore, determining the
pletes the current epoch block confirmation and, at the same time, order of cross-domain events is crucial. Considering delays, malicious
confirms the completion of data collection for the next epoch in nodes may broadcast events with forged timestamps to RSUs due to de-
various domains of the IoV system. lays. Suppose a node forges a timestamp later than the actual time and
(e) Reply stage: After each upper-layer node verifies the validity of at successfully gets packaged into 𝐿𝐶1 , then forges an earlier timestamp
least 2𝑓 + 1 commit messages, the proposed block is returned to event in domain 2, which is packaged into 𝐿𝐶2 . Cross-chain references
TA. The global blockchain completes one round of block issue. can provide basic proof of time order for two domains, proving that the
event in 𝐵1 occurred before the event in 𝐵2 . In this way, an IoV system
with potentially unsynchronized clocks offers approximate evidence for
4.2.3. The local layer blockchain consensus the occurrence order of events.
To increase the decentralization of the system, we allow vehicles to
participate in the local blockchain consensus. Considering the frequency 4.3. Cross-domain data interaction in the local layer
of vehicle nodes’ entry or exit in a specific domain, it is challenging to
In real-world IoV scenarios, as vehicles often traverse multiple do-
use permissioned consensus that requires a predefined number of par-
mains during their journeys, there is a need to anticipate the traffic
ticipating nodes. Therefore, the Proof-of-Stake (PoS) consensus in each
conditions in the upcoming domains for preparation. In the context of
domain with determined specific parameters based on the distribution
the IoV system, when a vehicle from Domain 1 is about to enter Do-
of vehicles is utilized. Participating nodes will engage in the block gener-
main 2, it can proactively inquire about the traffic data in Domain 2
ation process in the domain blockchain based on their stake and domain
through RSU by invoking the content of 𝐿𝐶2 . The on-chain data inter-
parameters. When a vehicle 𝑣 enters domain 𝑖 sending a request for a
action and the specific process are illustrated in Fig. 7, involving the
new PID assigned by RSU, it simultaneously receives the current do-
following stages:
main’s block interval parameter 𝜆𝑖 from this RSU. The block generation
probability 𝑝𝑖𝑣 = 𝑠𝑡𝑎𝑘𝑒𝑣 ⋅ 𝜆𝑖 for the vehicle in this domain is determined
• Data request phase: Vehicle 𝑣 from Domain 1 broadcasts {𝑟𝑒𝑞𝑢𝑒𝑠𝑡,
by the vehicle’s stake and 𝜆𝑖 . 𝜆𝑖 is estimated and broadcasted in the
{2}, 𝑡𝑥, 𝑃 𝐼𝐷𝑣 , 𝑠𝑖𝑔𝑣 } as a data request message and spends data re-
blockchain network by the DM every epoch based on the current block
quest funds. This message is packaged as a transaction by consensus
generation status, as shown in Algorithm 3.
Furthermore, due to the wide coverage of the IoV system and the
Algorithm 3 Domain-based PoS algorithm domain-based PoS.
number of nodes being different in each domain, adversaries may launch
Input: 𝑁𝑖 : number of participants of domain 𝑖’s local chain
attacks in the domain with fewer nodes. These adversaries might target
𝑁𝑖𝑅𝑆𝑈 : number of RSUs of domain 𝑖’s local chain
a specific domain chain and take over its block generation to manipulate
𝑛𝑢𝑚𝑑 : slots interval for PoS target update
the historical data of that domain. Therefore, this paper proposes a mu- 𝛾 : block interval parameter (1 by default)
tual cross-domain chain verification mechanism to address such risk. 1: function 𝑑𝑜𝑚𝑎𝑖𝑛 − 𝑏𝑎𝑠𝑒𝑑𝑃 𝑜𝑆
In this mechanism, domain chains will write each other’s past states 2: 𝜆𝑖 = 1∕𝑁𝑖𝑅𝑆𝑈
as proofs of history (PoH) [33]. If an adversary undermines a domain 3: while True do
chain, other domain chains recording the historical state of the disrupted 4: for 𝑠𝑙𝑜𝑡 = 1 to 𝑛𝑢𝑚𝑑 do
chain will detect the attack. Therefore the adversary would need to un- 5: participants compete to issue blocks
dermine other chains simultaneously to succeed, significantly increasing 6: end for
the attack cost. The mutual chain historical verification mechanism is 7: DM summarizes the nodes’ online information according to blocks
illustrated in Fig. 6. In block 𝐵4 of 𝐿𝐶3 , it not only references the state 8: DM update 𝑁𝑖
𝛾
9: DM broadcast 𝜆𝑖 =
of a block from its own chain but also references the state of the most 𝑁𝑖

recent confirmed block in 𝐿𝐶2 of domain 2. Assuming an adversary 10: end while
11: end function
forges a chain in the sparsely populated domain 1 to manipulate the

9
Z. Zhou, N. Wang, J. Liu et al. Vehicular Communications 49 (2024) 100832

real identity of the message sender corresponding to a PID as they

cannot derive the child privacy key from the public keys.
(3) Traceability and unlinkability: As TA can derive the keys of all
nodes using its master key, it is able to trace all activities of nodes
with malicious behavior, which prevents the adversary from broad-
casting wrong information. A vehicle can apply different PIDs to
interact with different nodes using different private keys. Only the
node that happens to derive the exact two PIDs of one vehicle can
link two messages signed by these two PIDs respectively. Consid-
ering that a vehicle will keep moving to different areas and apply
different PIDs from various RSUs, others can hardly link messages
sent by it by arbitrary PIDs. Even a DM could only link the messages
sent by one entity in it own domain.
(4) Blockchain security: The global main chain maintained by TA and
Fig. 7. Cross-chain data interaction. DMs using our dynamic PBFT can resist at least one-third of the
malicious nodes. The domain chains adopt the mutual cross-domain
chain verification mechanism. An adversary who wants to take over
nodes of Domain 1 onto block 1 of 𝐿𝐶1 . After that, a message one domain chain needs to possess over half of the whole IoV system
{𝑟𝑒𝑞𝑢𝑒𝑠𝑡, {2}, 𝑖𝑑𝑡𝑥 , 𝑃 𝐼𝐷𝑣 , 𝑠𝑖𝑔𝑣 } is sent to RSU 𝑅𝑆𝑈{1} in Domain resources. The cost of this attack is high which would mitigate the
1 to request data, initiating the next phase. risk of the 51% attack.
• Cross-chain phase: Upon confirmation of the request message
in the local chain 𝐿𝐶1 , 𝑅𝑆𝑈{1} sends {𝑐𝑟𝑜𝑠𝑠 − 𝑟𝑒𝑞𝑢𝑒𝑠𝑡, {1}, 𝑡𝑥, 5. Performance analysis
𝑠𝑖𝑔𝑅𝑆𝑈{1} } as a cross-domain request message to the nearest avail-
able RSU 𝑅𝑆𝑈{2} in Domain 2, where 𝑡𝑥 records the requirement
In this section, we show the efficiency of our upper-layer dynamic
for data request.
PBFT consensus compared with the traditional one. And evaluate the
• Data reply phase: The cross-domain request message is acknowl-
authentication performance of our IoV conditional privacy-preserving
edged by the 𝑅𝑆𝑈{2} responsible for interfacing in Domain 2. After
authentication. The overhead of data storage and retrieval in the hier-
the data is broadcast and recorded as well as funds and interfac-
archical and zonal blockchain is shown at last.
ing nodes are confirmed in block 2 of 𝐿𝐶2 , 𝑅𝑆𝑈{2} replies with
{𝑐𝑟𝑜𝑠𝑠 − 𝑟𝑒𝑝𝑙𝑦, 𝑖𝑛𝑓 𝑜{2} , 𝑡𝑥, 𝑠𝑖𝑔𝑅𝑆𝑈{2} } to 𝑅𝑆𝑈{1} . Subsequently,
𝑅𝑆𝑈{1} sends the received data as a reply message {𝑟𝑒𝑝𝑙𝑦, 𝑖𝑛𝑓 𝑜{2} , 5.1. Evaluation of the dynamic PBFT algorithm
𝑖𝑑𝑡𝑥 , 𝑠𝑖𝑔𝑅𝑆𝑈{1} } to the vehicle 𝑣.
• Data reply confirmation phase: After completing data interaction, In the proposed dynamic PBFT algorithm, TA will select the nodes
𝑅𝑆𝑈{1} references the content of block 2 and broadcasts the award with the highest stake to participate in the upper-layer consensus each
transaction of 𝑅𝑆𝑈{2} . Assuming this information is packaged into epoch. These nodes are essentially the most active and honest partic-
block 3 on 𝐿𝐶1 . After stabilization of block 3, 𝑅𝑆𝑈{2} references ipants from the past. Assuming there are 120 candidate upper-layer
the content of block 3 and broadcasts its award transaction to block nodes, the probability of node 𝑖 experiencing a single point of failure
4 on 𝐿𝐶2 . (SPOF) is given by 𝑠𝑝𝑓𝑖 = 𝑠𝑡𝑎𝑘𝑒𝑖 ∗ 𝑝𝑠𝑝𝑓 , where 𝑠𝑡𝑎𝑘𝑒𝑖 represents the
• Data cross-chain confirmation phase: After stabilization of block participation stake of the node (default by 1 for all nodes), and the
4, 𝑅𝑆𝑈{2} obtains its award, and 𝑅𝑆𝑈{1} references the content of SPOF parameter is set as 𝑝𝑠𝑝𝑓 = 0.28. The offline penalty parameter for
blocks 4 and 3, broadcasting its award transaction to 𝐿𝐶1 . When participation in the upper-layer consensus is denoted as 𝜖 = 0.1. The
the message is packaged into block 5 and reaches stability, 𝑅𝑆𝑈{1} consensus reward parameter for completing a round of block genera-
obtains its award. tion is denoted as 𝜁 = 0.05. In each epoch, the TA selects the top 80%
highest stake nodes as the upper-layer participants. The comparison of
4.4. Security analysis consensus success between the proposed dynamic PBFT and traditional
PBFT is illustrated in Fig. 8. From the comparison in the figure, it can
We analyze that our IoV data-sharing scheme meets the security re- be observed that, under the assumption of equal probabilities of indi-
quirements mentioned above: vidual node failures, the proposed dynamic PBFT consensus, based on
reputation-based ranking, exhibits lower failure probabilities in each
(1) Message authentication and integrity: Once a node receives a mes- round. Consequently, nodes can efficiently achieve consensus on upper-
sage 𝑚 with a signature 𝑠𝑖𝑔𝑣 , it checks the legitimate identity of the layer data using this approach.
sender 𝑃 𝐼𝐷𝑖𝑣 based on the corresponding 𝐿𝐶𝑖 and verifies the sig- Assuming a total of 100 rounds of upper-layer blockchain consensus
nature to ensure message integrity. If the timestamp or the correct- execution, the number of successful rounds is depicted as the penalty
ness of 𝑃 𝐼𝐷𝑖𝑣 is unsatisfied, this node will not accept the message. parameter and reward parameter vary in Fig. 9 and Fig. 10. It can be
In this way, the proposed scheme provides message authentication observed that as the penalty parameter increases and the reward pa-
and integrity. rameter decreases, the success rate of the protocol rises. This is because
(2) Conditional privacy-preserving authentication: Vehicles employ nodes with higher reputations are less likely to experience failures, so an
different PIDs in different areas. Data encrypted by the secret key increase in the penalty parameter and a decrease in the reward param-
of a 𝑃 𝐼𝐷𝑖𝑣 could be only known by the RSU that issued this PID eter can lead to the selection of nodes with higher reputations, which
as well as the domain manager 𝐷𝑀𝑖 . Note that the TA owns the enhances the system’s robustness. However, there might be an issue of
master key and the derivation seed for each DM. Hence it can au- power concentration, where the power to generate blocks is controlled
thenticate all records on the chain using the keys derived by the by a small number of nodes with high reputations, which is not con-
PID database encrypted and uploaded by RSUs and DMs on local ducive to achieving decentralization. Therefore, it is crucial to choose
chains and the global blockchain respectively. Ensured by the hi- appropriate system parameters based on different application scenarios
erarchical key derivation scheme, other nodes can never know the and security requirements.

10
Z. Zhou, N. Wang, J. Liu et al. Vehicular Communications 49 (2024) 100832

Table 2
Efficiency and overhead of our vehicle authen-
tication.

Time cost (ms) 𝑚=1 𝑚=2 𝑚=3

Key derivation 0.9943 2.9923 4.0214

Signature 0.9994 4.0876 7.9832
Validation 2.9921 2.9916 3.0281

Fig. 8. The comparison of upper-layer consensus success probability.

Fig. 11. Efficiency for PID keys derivation.

that involves generating all certificates at once and preloading them into
vehicles would lead to substantial storage overhead for vehicle nodes
and increase the security risks associated with potential data breaches.
In contrast, the hierarchical key generation scheme proposed in this pa-
per avoids the need for preloading a large number of key/certificate
pairs onto vehicles. Instead, vehicles only need to request a new tem-
porary PID upon entering a new domain to facilitate interaction within
that specific area. The efficiency of the vehicle PID generation system
and communication overhead is presented in Table 2. We simulated 100
Fig. 9. The number of successful rounds with different penalty parameters. instances where RSUs generated PIDs to vehicles. The average duration
for PID key derivation, data signing, and signature verification during
node communication was presented, where 𝑚 represents the parame-
ter for hierarchical key generation. It shows that with the increase of
𝑚, the efficiency of the key derivation decreases but the security im-
proves, as the random linear combination of keys would be harder for
adversaries to find. When 𝑚 = 3, the efficiency of key generation and
signature verification is illustrated in Fig. 11.
According to the DSRC protocol standard [37], each vehicle period-
ically sends traffic-related information, such as location and accident
records, to nearby vehicles and RSUs every 100-300 milliseconds, to as-
sist RSUs in managing traffic on roads and aid vehicles in navigation.
As depicted in Fig. 12a, considering an IoV system consisting of four do-
mains where each domain covers an area of 196 square kilometers, we
simulated 49 evenly distributed RSUs, 40 randomly deployed vehicles,
and a DM at the center in each domain. A central authority supervi-
sor TA for the entire system, is in the middle of the whole IoV system.
Considering the vehicle node 𝑣 circled in red in Fig. 12a, Fig. 12b illus-
Fig. 10. The number of successful rounds with different reward parameters. trates the time comparison between traditional communication and the
cross-domain communication proposed in this paper. The yellow points
represent the time consumed for 𝑣 to communicate with other vehicles
5.2. Vehicle authentication and communication efficiency in the whole system directly, and the green points represent the time
consumed in our work. As our work to the direct communication ratio
Assuming vehicles change their PIDs approximately every 1 hour, shown by the blue line, our RSU-assisted cross-domain communication
with each vehicle averaging 2 hours of travel per day, a vehicle would mechanism becomes more effective as the distance between the vehicle
need around 730 anonymous identities in a year. Traditional research node and the selected node increases.

11
Z. Zhou, N. Wang, J. Liu et al. Vehicular Communications 49 (2024) 100832

Fig. 12. The communication efficiency.

5.3. The blockchain overhead and efficiency

The hierarchical and zonal blockchain mechanism of our scheme

includes both blockchain data and application data in communication
[29]. For the low latency requirement of IoV communication, it is nec-
essary to test the blockchain overhead effect on vehicle data sharing.
In addition, evaluating the time cost for a message sent by a vehicle
node to finally be packed into the IoV blockchain is of significance to
show blockchain efficiency. We simulate the blockchain processing of
the local layer with domain channel communication, as the maintain-
ers of the global layer are DMs and RSUs nodes with low latency as
well as high computational resources selected by TA. In the local layer,
the major maintainers are RSUs from different zones whose application
data mainly includes data-sharing messages and vehicle registration,
and the blockchain data includes block header and cross-domain val-
idation. Considering the IoV topology in Fig. 13a, we assume that the
block header size representing the blockchain data is 512 bits, periodical
cross-domain validation data is 256 bits, and the transaction size repre-
senting the application data is 256 bits. Each vehicle communicates with
the nearest RSU every second and the RSU transmits the received data to
RM. Given the communication latency, we assume a V2V communica-
tion of 0.1% ratio of the distance, a V2R communication of 0.05% ratio
of the distance, and 0.5% communication failure probability. Fig. 13b
shows the proportion of blockchain data in all communication data re-
ceived by the RSU that received the most messages and its corresponding Fig. 13. The blockchain overhead and efficiency.
domain RM. It can be seen that as time goes on, the proportion of their
blockchain data can be ignored which means the overhead of maintain-
ing the blockchain consensus is low. Moreover, we randomly selected

12
Z. Zhou, N. Wang, J. Liu et al. Vehicular Communications 49 (2024) 100832

about the sender. Malicious behaviors can be detected and traced by

nodes responsible for specific areas. To reduce dependence on cen-
tral servers and onboard devices, we present a hierarchical and zonal
blockchain for efficient distributed IoV management. Data transfer be-
tween different domains is facilitated by a cross-domain vehicle data
interaction mechanism. Additionally, a cross-domain blockchain mutual
verification mechanism is utilized to enhance the security of blockchain
consensus. Performance evaluation indicates that our design has low
computational and storage overhead with negligible blockchain over-
head, and achieves higher communication efficiency. Future work will
focus on developing lighter-weight consensus mechanisms and incen-
tive mechanisms for IoV blockchain maintainers, with evaluations in
real-world scenarios.

CRediT authorship contribution statement

Fig. 14. The storage consumption.

Ziyu Zhou: Writing – review & editing, Writing – original draft. Na
Wang: Writing – review & editing. Jianwei Liu: Writing – review &
editing. Wen Zhou: Writing – review & editing. Junsong Fu: Writing –
review & editing. Lunzhi Deng: Writing – review & editing.

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

Data will be made available on request.

References

[1] M.A. Azad, S. Bag, S. Parkinson, F. Hao, Trustvote: privacy-preserving node ranking
Fig. 15. The number of successful rounds with different parameters. in vehicular networks, IEEE Int. Things J. 6 (2019) 5878–5891, https://doi.org/10.
1109/JIOT.2018.2880839.
a vehicle circled in green as shown in Fig. 13a, assuming it sends a [2] J. Chen, J. Wu, H. Liang, S. Mumtaz, J. Li, K. Konstantin, A.K. Bashir, R. Nawaz, Col-
laborative trust blockchain based unbiased control transfer mechanism for industrial
message to its nearest RSU. The orange line of Fig. 13c shows the time automation, IEEE Trans. Ind. Appl. 56 (2020) 4478–4488, https://doi.org/10.1109/
cost for the message to be included in our blockchain, and the blue line TIA.2019.2959550.
shows the counterpart of the traditional blockchain. Fig. 13c illustrates [3] J. Cui, X. Zhang, H. Zhong, J. Zhang, L. Liu, Extensible conditional privacy protection
that our blockchain takes less time to synchronize the message than the authentication scheme for secure vehicular networks in a multi-cloud environment,
IEEE Trans. Inf. Forensics Secur. 15 (2020) 1654–1667, https://doi.org/10.1109/
traditional approach.
TIFS.2019.2946933.
[4] R.G. Engoulou, M. Bellaiche, T. Halabi, S. Pierre, A decentralized reputation manage-
5.4. Overhead of data storage and retrieval in the hierarchical and zonal ment system for securing the internet of vehicles, in: 2019 International Conference
blockchain on Computing, Networking and Communications (ICNC), 2019, pp. 900–904.
[5] Q. Feng, D. He, S. Zeadally, K. Liang, Bpas: blockchain-assisted privacy-preserving
The zonal blockchain divides blockchain data into domains, signifi- authentication system for vehicular ad hoc networks, IEEE Trans. Ind. Inform. 16
(2020) 4146–4155, https://doi.org/10.1109/TII.2019.2948053.
cantly reducing the amount of data that each domain node needs to store
[6] Y. Genc, N. Aytas, A. Akkoc, E. Afacan, E. Yazgan, Elcpas: a new efficient lightweight
over the long term. In each domain blockchain, data digest is stored in certificateless conditional privacy preserving authentication scheme for iov, Veh.
the form of a binary tree for retrieval, with a time complexity of 𝑂(𝑙𝑜𝑔𝑛). Commun. 39 (2023) 100549, https://doi.org/10.1016/j.vehcom.2022.100549.
Assuming that in a given slot, the amount of data generated by the IoV is [7] K. Gu, K. Wang, X. Li, W. Jia, Multi-fogs-based traceable privacy-preserving scheme
𝑁 , the storage overhead and retrieval complexity for a node in a partic- for vehicular identity in internet of vehicles, IEEE Trans. Intell. Transp. Syst. 23
(2022) 12544–12561, https://doi.org/10.1109/TITS.2021.3115171.
ular domain is illustrated in Fig. 14 and Fig. 15. Here, 𝑑 represents the
[8] R. Gupta, A. Kumari, S. Tanwar, A taxonomy of blockchain envisioned edge-as-a-
number of domains the data is partitioned into, and 𝑑 = 1 corresponds connected autonomous vehicles, Trans. Emerg. Telecommun. Technol. 32 (2021),
to a scenario of a traditional blockchain IoV system. As the number of https://doi.org/10.1002/ett.4009.
partitioned domains increases, the storage requirements for individual [9] G. Gutoski, D. Stebila, Hierarchical deterministic bitcoin wallets that tolerate key
nodes decrease significantly, and the efficiency of retrieving data from leakage, in: International Conference on Financial Cryptography and Data Security,
Springer, 2015, pp. 497–504.
the blockchain improves considerably.
[10] B. Hazarika, K. Singh, S. Biswas, S. Mumtaz, C.P. Li, Multi-agent drl-based task of-
floading in multiple ris-aided iov networks, IEEE Trans. Veh. Technol. 73 (2024)
6. Conclusion 1175–1190, https://doi.org/10.1109/TVT.2023.3302010.
[11] B. Ji, Z. Chen, S. Mumtaz, C. Han, C. Li, H. Wen, D. Wang, A vision of iov in 5g
This paper introduces a conditional privacy-preserving and efficient hetnets: architecture, key technologies, applications, challenges, and trends, IEEE
Netw. 36 (2022) 153–161, https://doi.org/10.1109/MNET.012.2000527.
distributed IoV data-sharing scheme based on blockchain technology.
[12] F. Kandah, B. Huber, A. Skjellum, A. Altarawneh, A blockchain-based trust manage-
We propose a hierarchical key generation mechanism for IoV nodes, en- ment approach for connected autonomous vehicles in smart cities, in: 2019 IEEE 9th
abling conditional privacy-preserving authentication. This allows mes- Annual Computing and Communication Workshop and Conference (CCWC), 2019,
sages to be authenticated without disclosing any private information pp. 0544–0549.

13
Z. Zhou, N. Wang, J. Liu et al. Vehicular Communications 49 (2024) 100832

[13] A. Kumari, M.M. Patel, A. Shukla, S. Tanwar, N. Kumar, J.J.P.C. Rodrigues, Armor: [27] S. Tangade, S.S. Manvi, P. Lorenz, Trust management scheme based on hybrid cryp-
a data analytics scheme to identify malicious behaviors on blockchain-based smart tography for secure communications in vanets, IEEE Trans. Veh. Technol. 69 (2020)
grid system, in: GLOBECOM 2020 - 2020 IEEE Global Communications Conference, 5232–5243, https://doi.org/10.1109/TVT.2020.2981127.
2020, pp. 1–6. [28] I. Ullah, M.A. Khan, N. Kumar, A.M. Abdullah, A.A. AlSanad, F. Noor, A conditional
[14] S. Lee, S.H. Seo, Design of a two layered blockchain-based reputation system in privacy preserving heterogeneous signcryption scheme for internet of vehicles, IEEE
vehicular networks, IEEE Trans. Veh. Technol. 71 (2022) 1209–1223, https://doi. Trans. Veh. Technol. 72 (2023) 3989–3998, https://doi.org/10.1109/TVT.2022.
org/10.1109/TVT.2021.3131388. 3220041.
[15] D. Li, R. Chen, Q. Wan, Z. Guan, S. Li, M. Xie, J. Su, J. Liu, Intelligent and fair iov [29] N. Wang, Z. Zhou, J. Liu, L. Deng, J. Fu, Secure and distributed iov data shar-
charging service based on blockchain with cross-area consensus, IEEE Trans. Intell. ing scheme based on a hybrid pos blockchain protocol, IEEE Trans. Veh. Technol.
Transp. Syst. (2023) 1–11, https://doi.org/10.1109/TITS.2023.3249180. 1–16doi (2024), https://doi.org/10.1109/TVT.2024.3378534.
[16] C. Lin, D. He, X. Huang, N. Kumar, K.K.R. Choo, BCPPA: a blockchain-based con- [30] G. Wood, et al., Ethereum: a secure decentralised generalised transaction
ditional privacy-preserving authentication protocol for vehicular ad hoc networks, ledger, Ethereum Proj. Yellow Pap. 151 (2014) 1–32, https://ethereum.github.io/
IEEE Trans. Intell. Transp. Syst. 22 (2021) 7408–7420, https://doi.org/10.1109/ yellowpaper/paper.pdf.
TITS.2020.3002096. [31] X. Xie, B. Wu, B. Hou, Bephap: a blockchain-based efficient privacy-preserving han-
[17] J. Liu, C. Peng, R. Sun, L. Liu, N. Zhang, S. Dustdar, V.C.M. Leung, Cpahp: condi- dover authentication protocol with key agreement for Internet of vehicles, J. Syst.
tional privacy-preserving authentication scheme with hierarchical pseudonym for Archit. 138 (2023) 102869, https://doi.org/10.1016/j.sysarc.2023.102869.
5g-enabled iov, IEEE Trans. Veh. Technol. 72 (2023) 8929–8940, https://doi.org/ [32] Z. Xu, W. Liang, K.C. Li, J. Xu, H. Jin, A blockchain-based roadside unit-assisted au-
10.1109/TVT.2023.3246466. thentication and key agreement protocol for internet of vehicles, J. Parallel Distrib.
[18] R. Lu, X. Lin, H. Zhu, P.H. Ho, X. Shen, Ecpp: efficient conditional privacy preser- Comput. 149 (2021) 29–39, https://doi.org/10.1016/j.jpdc.2020.11.003.
vation protocol for secure vehicular communications, in: IEEE INFOCOM 2008 - the [33] A. Yakovenko, Solana: a new architecture for a high performance blockchain v0.
27th Conference on Computer Communications, 2008, pp. 1229–1237. 8.13, Whitepaper, https://solana.com/solana-whitepaper.pdf, 2018.
[19] Z. Lu, Q. Wang, G. Qu, H. Zhang, Z. Liu, A blockchain-based privacy-preserving [34] Z. Yang, K. Yang, L. Lei, K. Zheng, V.C.M. Leung, Blockchain-based decentralized
authentication scheme for vanets, IEEE Trans. Very Large Scale Integr. (VLSI) Syst. trust management in vehicular networks, IEEE Int. Things J. 6 (2019) 1495–1505,
27 (2019) 2792–2801, https://doi.org/10.1109/TVLSI.2019.2929420. https://doi.org/10.1109/JIOT.2018.2836144.
[20] S.K. Mohanty, S. Tripathy, Siovchain: time-lock contract based privacy-preserving [35] Y. Yao, X. Chang, J. Mišić, V.B. Mišić, Lightweight and privacy-preserving id-as-a-
data sharing in siov, IEEE Trans. Intell. Transp. Syst. 23 (2022) 24071–24082, service provisioning in vehicular cloud computing, IEEE Trans. Veh. Technol. 69
https://doi.org/10.1109/TITS.2022.3192566. (2020) 2185–2194, https://doi.org/10.1109/TVT.2019.2960831.
[21] S. Nakamoto, A. Bitcoin, Bitcoin: a peer-to-peer electronic cash system, Decentralized [36] C. Zhang, X. Lin, R. Lu, P.H. Ho, Raise: an efficient rsu-aided message authentication
business review 4, 15, https://bitcoin.org/bitcoin.pdf, 2008. scheme in vehicular communication networks, in: 2008 IEEE International Confer-
[22] K. Rabieh, M.M.E.A. Mahmoud, M. Younis, Privacy-preserving route reporting ence on Communications, 2008, pp. 1451–1457.
schemes for traffic management systems, IEEE Trans. Veh. Technol. 66 (2017) [37] J. Zhang, J. Cui, H. Zhong, Z. Chen, L. Liu, Pa-crt: Chinese remainder theorem based
2703–2713, https://doi.org/10.1109/TVT.2016.2583466. conditional privacy-preserving authentication scheme in vehicular ad-hoc networks,
[23] M. Raya, J.P. Hubaux, Securing vehicular ad hoc networks, J. Comput. Secur. 15 IEEE Trans. Dependable Secure Comput. 18 (2021) 722–735, https://doi.org/10.
(2007) 39–68, https://doi.org/10.3233/JCS-2007-15103. 1109/TDSC.2019.2904274.
[24] W. Ruan, J. Liu, Y. Chen, S.M.N. Islam, M. Alam, A double-layer blockchain based [38] J. Zhang, Y. Wang, Z. Ma, X. Yang, Z. Ying, J. Ma, A location-aware verifiable
trust management model for secure internet of vehicles, Sensors 23 (2023), https:// outsourcing data aggregation in multiblockchains, IEEE Int. Things J. 10 (2023)
doi.org/10.3390/s23104699. 4783–4798, https://doi.org/10.1109/JIOT.2022.3221555.
[25] K.A. Shim, Cpas: an efficient conditional privacy-preserving authentication scheme [39] C. Zhao, N. Guo, T. Gao, X. Deng, J. Qi, Pepa: Paillier cryptosystem-based efficient
for vehicular sensor networks, IEEE Trans. Veh. Technol. 61 (2012) 1874–1883, privacy-preserving authentication scheme for vanets, J. Syst. Archit. 138 (2023)
https://doi.org/10.1109/TVT.2012.2186992. 102855, https://doi.org/10.1016/j.sysarc.2023.102855.
[26] R. Shrestha, R. Bajracharya, A.P. Shrestha, S.Y. Nam, A new type of blockchain for se- [40] D. Zheng, C. Jing, R. Guo, S. Gao, L. Wang, A traceable blockchain-based access
cure message exchange in VANET, Digit. Commun. Netw. 6 (2020) 177–186, https:// authentication system with privacy preservation in vanets, IEEE Access 7 (2019)
doi.org/10.1016/j.dcan.2019.04.003. 117716–117726, https://doi.org/10.1109/ACCESS.2019.2936575.

14