# An Atomic Cross-Chain Swap-Based Management System in Vehicular Ad Hoc Networks

Authors: Chenkai Tan; Shaoyi Bei; Zhengjun Jing; Neal Xiong
Journal: Wireless Communications and Mobile Computing
 (2021)

---

## Abstract

The blockchain-based management system has been regarded as a novel way to improve the efficiency and safety of Vehicular Ad Hoc Networks (VANETs). A blockchain-based scheme’s performance depends on blockchain nodes’ computing power composed from the road-side unit (RSU). However, the throughput of blockchain-based application in VANETs is limited by the network bandwidth. A single blockchain cannot record large-scale VANETs’ data. In this paper, we design an atomic cross-chain swap-based management system (ACSMS) to boost the scalability of blockchain-based application in VANETs. The blockchain-based public-key encryption with keyword search is further introduced to protect user privacy. The analysis shows that ACSMS achieves cross-chain swap without loss of CAV security privacy. The simulation results show that our method can realize multiple blockchain-based applications in VANETs.


---

## Body

## 1. Introduction

Nowadays, connected autonomous vehicles (CAVs) equip with the on-board unit (OBU) that enables vehicle ad hoc networks (VANETs [1]) to be formed. By C-V2X and DSRC communication, VANETs could improve traffic efficiency [2] and road safety [3]. With the VANET development [4], CAVs not only need safely and efficiently communicate to other CAVs [5–7] but also need to decide the trustworthiness of other CAVs’ messages. There are many attacks and challenges [8–11] in VANETs, which may be solved by blockchain technology. For example, blockchain-based VANET schemes have been designed to provide security key transfers [12] and decentralized trust management [13].Blockchain is a novel tamper-resistance and decentralization ledger-based storage method, which is useful in VANETs. However, the throughput of blockchain is limited by the blockchain consensus algorithms and network bandwidth. For example, the throughput on Ethereum [14] is 10-30 TPS. Simultaneously, the number of CAVs around the world will reach 2 billion in the next 10-20 years [15]. Therefore, Shrestha et al. [16] proposed that administrator divide multiple blockchains according to geographical location to enhance application scalability.There are three categories of existing blockchain-based VANET schemes: the blockchain-based PEKS [17], the blockchain-based dynamic key management system [12] (BKM), and the blockchain-based trust management system [13] (BTM). First, the blockchain-based PEKS integrates blockchain technology and PEKS. The blockchain technology supports the data tamper resistance, and PEKS supports verifiable searching simultaneously. Second, BKM could prevent an unregistered user from accessing VANETs illegally. However, BKM uses pseudo-ID to achieve conditional privacy. Without revealing CAVs’ identities, the user will lack the motivation to deliver information. Therefore, BTM was proposed to build trust in the communications of CAVs and incentive users to forward announcements.Toward enhancing the flexibility of the blockchain-based scheme in VANETs, we integrate multiple blockchain-based applications into the single blockchain. Then, we use the atomic cross-chain protocol to connect blockchain. The main contributions of this article are summarized as follows:(i)
In VANETs, network size can be geographically unbounded and very scalable, but nodes in VANETs have geographical relevancy. We partition country maps into regions, and each region maintains an independent blockchain, which will reduce blockchain scalability issues. We develop ACSMS to connect multiple blockchain systems while maintaining the property of trust and integrity built by individual blockchains. Therefore, the ACSMS can enhance interoperability between chains(ii)
We also introduce the blockchain-based PEKS [18] as the data-sharing scheme. In blockchain-based PEKS, CAVs use the public key to encrypt the data and the corresponding keywords. The ciphertext signature is provided in the blockchain, and the ciphertexts are stored in the TA server. Thus, the blockchain-based PEKS support verifies of ciphertexts(iii)
Furthermore, we attempt to integrate the blockchain-based PEKS, BKM, and BTM into ACSMS, such that CAVs could use multiple blockchain-based applications with a single blockchain account. Compared with other reference schemes, ACSMS achieves more functionalityThe remainder of this paper is organized as follows. The related works are briefly introduced in Section2. In Section 3, we give the model overview and details of ACSMS. Then, the security analysis of our scheme is presented in Section 4. In Section 5, we make a performance evaluation of ACSMS. In Section 6, we give the conclusions of the paper.


## 2. Related Work

### 2.1. Blockchain-Based PEKS

Since Boneth et al. [19] first posed PEKS, numerous schemes about PEKS have been put forward. There are four polynomial-time algorithms of PEKS: KeyGen, Trapdoor, PEKS, and Test. If the user sends a trapdoor to the server, the server can locate all ciphertexts containing keywords through PEKS. Significantly, blockchain-based PEKS for VANETs [17] allows users to detect any unauthorized manipulation. The blockchain-based PEKS schemes [17, 18, 20] avoid the centralized malicious attacks [21]. The oblivious protocol between users and blockchain servers can thwart off-line KGA (keyword guessing attacks).


### 2.2. BKM

Lei et al. [12] proposed a novel key management scheme based on blockchain to transfer key within the decentralized VANETs securely. Similarly, Ma et al. [22] developed an efficient BKM scheme that supports key updates and revocation. Furthermore, a lightweight mutual authentication protocol for BKM is proposed in [22]. Shrestha et al. [16] also employed blockchain technology to disseminate information in VANETs. Unlike Lei et al. and Ma et al., Shrestha et al. divided the map into blockchain regions according to the density of CAVs. However, Shrestha et al. did not use cross-chain technology to connect the different regions.As shown in Figure1, the basic structure of the blockchain [23] consists of a series of various blocks that has a block header and a block body. The block header is used to identify a particular block, and a block header consists of blockchain version, the previous block’s hash (PreHash), MerkleRoot, Timestamp (TS), nonce, and difficulty target. The block body is used to record transactions, and a block body consists of transactions and a Merkle hash tree formed by the hash value of transactions. Each block has a difficulty target related to the previous block; a chain structure is formed. If a miner first finds the nonce and broadcast correct block into the network, this block’s validity will be acknowledged by other blockchain nodes.Figure 1
The basic blockchain structure.


### 2.3. BTM

The decentralized BTM schemes are introduced to determine the trustworthiness of CAVs. Yang et al. [13] proposed a BTM to query neighbours’ trust values and then verify the received messages. Similarly, Lu et al. [24] investigated an anonymous BTM to break the linkability between real identities and the public keys. Furthermore, Lu et al. used the TA and RSU to provide BTM. Zhao et al. [25] employed blockchain technology to associate resource allocation with the trust value of CAVs. In addition, Zhao et al. introduced a novel BTM based on PBFT&PoS consensus algorithm to support cross-chain swap. But PBFT&PoS-based BTM cannot support PoW-based scheme.


## 2.1. Blockchain-Based PEKS

Since Boneth et al. [19] first posed PEKS, numerous schemes about PEKS have been put forward. There are four polynomial-time algorithms of PEKS: KeyGen, Trapdoor, PEKS, and Test. If the user sends a trapdoor to the server, the server can locate all ciphertexts containing keywords through PEKS. Significantly, blockchain-based PEKS for VANETs [17] allows users to detect any unauthorized manipulation. The blockchain-based PEKS schemes [17, 18, 20] avoid the centralized malicious attacks [21]. The oblivious protocol between users and blockchain servers can thwart off-line KGA (keyword guessing attacks).


## 2.2. BKM

Lei et al. [12] proposed a novel key management scheme based on blockchain to transfer key within the decentralized VANETs securely. Similarly, Ma et al. [22] developed an efficient BKM scheme that supports key updates and revocation. Furthermore, a lightweight mutual authentication protocol for BKM is proposed in [22]. Shrestha et al. [16] also employed blockchain technology to disseminate information in VANETs. Unlike Lei et al. and Ma et al., Shrestha et al. divided the map into blockchain regions according to the density of CAVs. However, Shrestha et al. did not use cross-chain technology to connect the different regions.As shown in Figure1, the basic structure of the blockchain [23] consists of a series of various blocks that has a block header and a block body. The block header is used to identify a particular block, and a block header consists of blockchain version, the previous block’s hash (PreHash), MerkleRoot, Timestamp (TS), nonce, and difficulty target. The block body is used to record transactions, and a block body consists of transactions and a Merkle hash tree formed by the hash value of transactions. Each block has a difficulty target related to the previous block; a chain structure is formed. If a miner first finds the nonce and broadcast correct block into the network, this block’s validity will be acknowledged by other blockchain nodes.Figure 1
The basic blockchain structure.


## 2.3. BTM

The decentralized BTM schemes are introduced to determine the trustworthiness of CAVs. Yang et al. [13] proposed a BTM to query neighbours’ trust values and then verify the received messages. Similarly, Lu et al. [24] investigated an anonymous BTM to break the linkability between real identities and the public keys. Furthermore, Lu et al. used the TA and RSU to provide BTM. Zhao et al. [25] employed blockchain technology to associate resource allocation with the trust value of CAVs. In addition, Zhao et al. introduced a novel BTM based on PBFT&PoS consensus algorithm to support cross-chain swap. But PBFT&PoS-based BTM cannot support PoW-based scheme.


## 3. An Atomic Cross-Chain Swap-Based Management System

### 3.1. System Model

As illustrated in Figure2, three types of entities in VANETs are CAVs, RSU, and TA.Figure 2
System model of ACSMS.The connected autonomous vehicles (CAVs): each CAV, as a sender S, is equipped with a hardware security module (HSM) and an OBU. The feature of CAVs includes dynamic mobility, wireless communication [26], and predictable trajectory [27] [22, 28]The roadside unit (RSU): the RSUs provide V2I provide V2I services by communicating with CAVs. RSU as blockchain nodes {KS1, KS2, ..., KSn} creates new blocks to maintain the blockchain in the regionThe trust authority (TA): as a storage server C, the main task of TA includes the identity review of CAV users, deployment of smart contracts, and the issuance of transaction data. The TA also sends the pseudo-IDs to the CAVs. After the initial registration, TA provides every CAVs with a unique blockchain account to realize ACSMSWith different transfer protocols, CAVs can reach V2X through OBU. The concept design of the OBU [29] is illustrated in Figure 3. The OBU provides with long-range wide-area network (LoRaWAN), narrow-band internet of things (NB-IoT), and global positioning system (GPS). By LoRaWAN and NB-IoT, CAVs communicate with the TA (V2C), RSU (V2I), and other CAVs (V2V).Figure 3
The structure of ACSMS.In the ACSMS, there are four primary functions: blockchain-based PEKS, BKM, BTM, and atomic-cross chain-swap. We will, respectively, present the four functions.(a)
The blockchain-based public-key encryption with keyword search (PEKS). CAVs outsource ciphertext and cypher-text signature to the TA. Then, the TA broadcasts the signature and the serial number of ciphertext into the blockchain. Finally, by TEST algorithm and the signature, the searcher can obtain correct ciphertext from the TA(b)
The blockchain-based key management (BKM). The TA registers CAVs and sends pseudo-ID to CAVs. By blockchain-based PEKS, CAVs’ details (such as licence plate and driver’s licence) are encrypted to protect privacy. By pseudo-ID, CAVs enable explicit mutual authentication with RSU through a handover authentication protocol [30]. Furthermore, blockchain technology provides decentralized authentication for this protocol(c)
The blockchain-based trust management (BTM). After the BKM, CAV, and RSU establish a shared symmetric key for the subsequent communication session. Then, RSU gets CAV’s trust value from the blockchain. To share trust value with pseudo-ID, RSU generates an authentication code of CAVs’ trust value. Other CAVs can then gain the credibility of CAVs’ trust value without knowing the CAVs’ real identity(d)
The atomic-cross chain-swap. We use an atomic-cross chain-swap algorithm [31, 32] that provides cross-chain interoperability among blockchain-based systems. Only serial number of ciphertext and CAVs’ trust value are swapped across different blockchains


### 3.2. The Blockchain-Based PEKS

Based on the project of PEKS from bilinear pairings [17, 20, 33], we design a blockchain-based PEKS scheme for ACSMS. In the blockchain-based PEKS, the CAV (S) has a blockchain account bs1 and send message (M) to the TA (C). Furthermore, the public key and private key of bs1 are PKbs,SKbs. It should be emphasized that the PEKS construction in this work is very basic and can be extended to more complex PEKS through integrating with other technology. For example, by introducing cloud storage services [18], the CAV is able to outsource the data to the cloud storage services.


#### 3.2.1. Setup Stage

With a security parameterλ, the system parameters {q, e^, G1, G2, H1, H2, H3, H4, μ,} are generated. Here, (G1,+) and (G2,·) are two cyclic groups of prime order q. e^: G1×G1⟶G2 be an admissible bilinear map, which satisfies bilinear, nondegenerate, and computable [34].H is a cryptographic hash function, H1:0,1∗⟶ℤq∗, ℤq∗=ρ∣1≤ρ≤q. H2:G2⟶0,1logq. H3:0,1∗⟶0,1h, where h is the output length of H3. H4:0,1∗⟶G1. μ = e^P,P.


#### 3.2.2. Blockchain Stage

(i)
KeyGen. The CAV (S) picks a random secret key Sks=x∈ℤq∗, and corresponding public key is Pks=X=xP∈G1. With same parameters, the TA (C) generates the key as Pkc=Y=yP∈G1,Skc=y∈ℤq∗.(ii)
Trapdoor. Take as input Sks and keyword w, the CAV computes the Trapdoor [33] Tw=H1w+x−1P. Then, the CAV encrypts M through a standard public-key encryption E(·) [35].(iii)
PEKS. Take as input Pks, Pkc, and w, the CAV randomly selects r1,r2∈ℤq∗. The CAV computes A=r1H1wP+r1X, B=r2P, V=H2e^r1P+r2A,Y, and output PEKSw,PKs=A,B,V [33].With the encryptedM and keywords w1,w2,⋯,wn, a list of ciphertext is got by CAV, which is Cts=EM∥PEKSw1,PKs∥⋯∥PEKSwn,PKs, where ∥ indicates message concatenation operation. Then, the CAV computes the signature of Cts as [34] Sig=P/H3Cts+x. Finally, the CAV sends ciphertext Cts and Sig to the TA.To fast searchSig, the TA generates serial number Sni from bs1 record Sni−1, and Sni=Sni−1+1. The TA broadcasts a transaction Sig,Sni into blockchain nodes (RSU) to check data integrity and authenticate user, which the receive account is bs1. Then, RSU KSt will broadcast Sig,Sni into the blockchain network, when a blockchain node KSt(RSU) finds a correct nonce.
(iv)
TEST. Take as input Pks, y, A,B,V, and Tw, test H2e^yA,Tw+B=?V, where =? operation returns true if two values are equal and false if they are not equal. With keywords w1,w2,⋯,wn and TEST, the TA obtains ciphertexts of each keyword. Then, check e^H3CtsP+X,Sig=?e^P,P through blockchain. The Sig proves that the ciphertexts belong to the blockchain account bs1, when =? operation returns trueBy sending trapdoors and blockchain signature to the TA, the searcher can obtain ciphertexts as follows. The CAV (S) send Pks,Tw,Sigsearcher,ts,PKbs to the searcher, which Sigsearcher=P/H3PksTwts+SKbs. With Pks, y, A,B,V, and Tw, the TA can find ciphertexts from Pks,Tw,Sigsearcher,ts,PKbs. If e^H3CtsP+X,Sig=e^P,P, the ciphertexts belong to the blockchain account bs. If e^H3PksTwtsP+X,Sigsearcher=e^P,P, the legal searcher is consented with the CAV (S).The correctness of the scheme is proofed as follows:(1)H2e^yA,Tw+B=H2e^yA,H1w+x−1P+r2P=H2e^yr1PH1w+x,PH1w+x−1+r2=H2e^r1Y,P1+r2H1w+x=H2e^Y,r1P+r2r1PH1w+r1X=H2e^Y,r1P+r2A=H2e^r1P+r2A,Y=V,e^H3CtsP+X,Sig=e^PH3Cts+x,1H3Cts+xP=e^P,PH3Cts+x1/H3Cts+x=e^P,P.


### 3.3. Blockchain-Based Key Management in VANETs

The design goals of the BKM are security and efficiency user authentication. The VANET performs the BKM inside the blockchain region that can decentralized record user public key [12, 22]. However, BKM [12, 22] is hard to realize key revocation and hard to support cross-chain verify. In this paper, we take the PKI-based scheme [30] to realize key agreement, public update, and revocation. The ACSMS setups stage corresponding to the BKM system setup. The ACSMS blockchain stage includes the BKM user registration, CAV authentication, and the TA management CAVs’ pseudo-ID. In contrast to [30], the blockchain is used to authentication users’ pseudo-ID.


#### 3.3.1. System Setup Phase

In our system, all nodes keep loose time synchronization. The system setup phase is as follows: First, the RSU has to install a blockchain-based application. Second, based on the density of CAVs in a country, maps are partitioned into different regions. Third, TA sends a unique blockchain account to every RSU. RSU then creates new blocks to maintain the blockchain in the region. Finally, administrators apply ACSMS to these blockchains.


#### 3.3.2. Registration Phase

To ensure legitimacy within VANET, TA must register new CAVs [22, 36] through relevant CAV information Sinfo. Sinfo is formed by phone number, licence plate, driver’s ID, etc. Different from the blockchain-based PEKS, the TA will sign the Sinfo. Take as input Sinfo, TA private key y, TA computes the signature of Sinfo, SigSinfo=P/H3Sinfo+y. By the blockchain-based PEKS, CAVs get ciphertext (Ctinfo) of Sinfo. Then, the CAV (S) sends the ciphertext Ctinfo to the TA (C), and the TA generates serial number Sni.The blockchain transaction of (SigSinfo,Sni) is processed as follows. The TA encapsulates (SigSinfo,Sni) into JSON format. Next, TA sends the transaction to the RSU, and the RSU executes the mining process; the transaction (SigSinfo,Sni) is added to the block. If a miner KSt finds a nonce, KSt broadcasts the block into the network. The RSU gets the transaction (SigSinfo,Sni) through update the blockchain.After the TA registers CAVs, the TA chooses a set of unlinkable pseudo-IDsPID=Pid1,Pid2,⋯ for each CAVs. For each Pidj∈PID, TA computes the private key sH4Pidj, s is a random number ∈ℤq∗. Then, TA sends all tuples (Pidj,sH4Pidj) back to the CAV (S) using a secure transmission protocol. By changing its pseudo-ID, CAV achieves conditional location privacy and identity privacy in the VANETs.


#### 3.3.3. Authentication Phase

The authentication based on bilinear pairing [30] could ensure the security of ACSMS. We use an handover authentication protocol to ensure efficiency seamless handover over multiple access points [30].As Figure4 shows, when an RSU (KSt) is within the CAV direct communication range, the protocol run of BKM is as follows:
(1)
The CAV picks an unused pseudo-IDPidi,sH4Pidi(2)
With messageMi=PidiIDKStts and sH4Pidi, the CAV computes the signature σi=H1Mi·sH4Pidi [30], where IDKSt is RSU’ (KSt) identity, ts is a timestamp, and ∥ indicates the message concatenation operation(3)
The CAV computes the signature ofSigSinfo,Sni as Sigb=P/H3Sni∥Pidi∥IDKSt∥ts+SKbs, where SKbs is the private key of bs1(4)
The CAV sends the access request messageMi,σi,PKbs,Sni,Sigb,ts to RSU (KSt) through unicast, where PKbs is the public key of bs1(5)
The CAV computes the shared symmetric key with RSU (KSt) as KS−KSt=e^sH4Pidi,H4IDKSt [30]Figure 4
The protocol run of BKM.Upon receipt ofMi,σi,PKbs,Sni,Sigb, the RSU KSt proceeds as follows:
(1)
RSU first checksts to prevent replay attack. Then, RSU checks signature σi as e^σi,P=e^H1Mi·sH4Pidi,P=?e^H1Mi·H4Pidi,Pkc [30]. Then, RSU needs to retrieve the corresponding bs1,Sni from the blockchain to ensure user legitimacy within pseudo-ID. Finally, RSU checks e^H3Sni∥Pidi∥IDKSt∥tsP+PKbs,Sigb=?e^P,P. If both formula is correct, the CAV (S) is a legal vehicle, which was signed by the TA(2)
RSU further computes the shared symmetric keyKKSt−S: KKSt−S=e^H4Pidi,sH4IDKSt=e^sH4Pidi,H4IDKSt=KS−KSt [30](3)
Then,KSt generates an authentication code Aut=H1KKSt−SPidiIDKSt [30] and sends Pidi,IDKSt,Aut to the CAV (S)Upon receipt ofPidi,IDKSt,Aut, the CAV computes the verification code Ver=H1KKSt−SPidiIDKSt=?Aut [30]. If Ver matches Aut, KSt is a legitimate RSU. The shared key between the CAV and RSU is KKSt−S.By this protocol, CAV realizes authentication with RSU. The blockchain technology provides decentralized key authentication for the protocol. Between RSU and CAVs, a shared symmetric keyKKSt−S is also established for the subsequent communication session.If the administrator wants to findSinfo of Mi,σi,PKs1,Sni,Sigb, the TA first obtains Tw and Pks from the CAV. The TA takes as input Pks, y, and Tw and tests if H2e^yA,Tw+B=V. With keywords w1,w2,⋯,wn and TEST, the TA obtains ciphertext Ctinfo of each keyword. Then, the TA sends ciphertext Ctinfo to the CAV and CAV decryption Ctinfo as Sinfo′. After this, the CAV sends Sinfo′ to the TA. Then, TA checks if e^H3Sinfo′P+Y,SigSinfo=e^P,P, where SigSinfo is obtained from the account bs1. If so, the correct Sinfo belongs to account bs1.


### 3.4. Blockchain-Based Trust Management in VANETs

The BKM uses pseudo-ID to provide conditional privacy. However, VANET is difficult to forward reliable message with an anonymous environment. Besides, the user with pseudo-ID will lack the motivation to forward announcements [37]. The BTM [13, 24, 25] was proposed to resolve these issues, which can recognize and eliminate of misbehaving vehicles. The process of the BTM is as follows. First, the CAV validates the legitimacy of received messages from neighboring CAVs. Second, based on the validated result, the rating of messages is generated by CAVs. Third, with the ratings uploaded from CAVs, the RSU gets the offsets of involved CAVs. Finally, the RSU adds the offset into the blockchain, where the offset is reflected by the CAV’s blockchain account balance.To calculate trust value, Zhao et al. [25] classify CAVs into three roles: privilege vehicles (S1), enterprise vehicles (S2), and individual vehicles (S3). Each role has different initial credibility. To share trust value with pseudo-ID, KSt generates an authentication code of CAV’s trust value OCP as SigOCP=P/H3PidiOCPts1+SKKSt. SKKSt is the private key of the RSU (KSt). Upon receipt of Message,Pidi,ts1,SigOCP,OCP, other CAV checks e^H3PidiOCPts1P+PKKSt,SigOCP=?e^P,P, where PKKSt is RSU’s (KSt) public key.A CAV receiveM kinds of road-relevant events from different CAVs in a certain time. There are J CAVs in the reference set. The CAVs separate received messages into M groups as g1,g2,⋯,gM. gi is one road-relevant event, which contains messages Wi1,Wi2,⋯,WiJ that send by CAVs in the reference set J. According to [25], the tuple of one specific message (Wkj [25]) is defined as
(2)Wkj=dkj,timekj,OCP,P∈S1,S2,S3.The CAV receiver obtains the road-relevant eventk from the neighboring CAV j. dkj is the distance between the location of the event k and CAV j; timekj is the message received time of CAV j; OCP is the trust value of CAV j. According to [25], the credibility of specific messages (ckj) is calculated as:
(3)ckj=ηeαdkj+1−ηmkj+OCp.η is the balance coefficient between distance and time; α is a parameter to control the communication boundary; mkj is used to prevent replay attack. Next, ti is the trust value of one road-relevant event gi, which contains c1i,c2i,⋯,cJi. ti is calculated as (3) using Bayesian Inference [38].
(4)ti=Pe∣gi=Pe·∏k=1JPcik∣ePe·∏k=1jPcik∣e+Pe¯·∏k=1JPcik∣e¯.Pe is the prior probability of event e; e¯ is the complementary event of e. By comparing with threshold (Thr), the CAV j judges the event gi. Then, CAV j generates ratings rateij(i.e., +1 or -1) and sends to RSU. By weighted aggregation (4), RSU gets the offset of the trust value ∈0,1. According to [13], the sensitivity of ratings offseti is controlled by F·.
(5)offseti=Fm·m+Fn·nm+n,wherem is the positive(+1) rating and n is the negative(-1) rating;Comparedoffseti with a threshold (Thr1), if offseti>=Thr1, the offset of one CAV j is offsetij=rateij. Otherwise, the offset of one CAV j is offsetij=−rateij. After the event gi, the new trust value of CAV j is OCp=OCp+offsetij. Finally, if a miner finds offset blocks that meet difficulty target, RSUs can share the new trust value of CAV j.


### 3.5. Atomic Swap-Based Cross-Chain Scheme

For now, the researcher proposed four categories cross-chain technologies [39], which include atomic cross-chain swap, multicentre witness, side chain (Ethereum 2.0), and distributed private key control. Atomic cross-chain swap [31, 32, 40, 41] is a standard method to connect multiple blockchains. Without trusted third parties, the atomic swap can realize fair cross-chain exchange.The ACSMS can exchange the CAV’s data for the blockchain-based PEKS, the BKM, and the BTM. Take as input last signature (Sig,Sni, data), old blockchain account (PKbs1, SKbs1), and new blockchain account (PKbs2, SKbs2). S computes the cross-chain transaction AssetR=SigSni+1tsOCp,Sni+1,ts,PKbs1⟶PKbs2,OCp,swap. The signature SigSni+1tsOCp=P/H3Sni+1tsOCp+SKbs1. After the ACSMS process, if searcher wants to find past information, then searcher uses index Si and PKbs1 to find past signature (Sig), which can check data integrity and authenticate the user. The cross-chain model is illustrated in Figure 5.Figure 5
Atomic swap-based cross-chain scheme.The atomic swaps problem in VANETs is as follows. Assume a CAV has an account (PKbs1, PRbs1) and holds an asset Z=AssetS,OCp in blockchain A. If CAV accesses blockchain B domain, the CAV creates a new blockchain account (PKbs2, PRbs2) in blockchain B. By the smart contract [32], the CAV can deal with other CAV or RSU or TA to realized cross-chain swap. Compared with other CAVs and RSU, it is more securely and efficient that CAVs deal with the TA as escrow agent [31, 32, 41]. The escrow agent to occur for the ACSMS is as follows.Algorithm 1
Atomic swap for ACSMS {depositA, depositB: bool; hash1, hash2 : int256;//the deposit function allows user transfer of the asset to the smart contract.uint startA, startB; //protocol starting timeinitialize {deposited A : = False; deposited B := False; hash1=hash2=0; }depositA{if sender = accountA and asset=Z:Then depositA : = True and hash = h1 and startA = time()}//h1 is hash-lock; startA + timeset is time-lock.depositB{if sender = TA and asset=Z:Then depositB : = True and hash = h2 and startB = time()}Finalise{if depositA and depositB and now < startA + timeset :Then {depositA : = False; depositB:= Falsesend(accountB,Z), send(TA,Z)}}cancelA{if (depositA and sha-256(x2) = h2) or now> startA + timesetthen {depositA : = False; Send(accountA,Z)}}cancelB{if (depositB and sha-256(x1) = h1) or now> startB + timesetthen {depositB : = False; Send(TA,Z)}}}


## 3.1. System Model

As illustrated in Figure2, three types of entities in VANETs are CAVs, RSU, and TA.Figure 2
System model of ACSMS.The connected autonomous vehicles (CAVs): each CAV, as a sender S, is equipped with a hardware security module (HSM) and an OBU. The feature of CAVs includes dynamic mobility, wireless communication [26], and predictable trajectory [27] [22, 28]The roadside unit (RSU): the RSUs provide V2I provide V2I services by communicating with CAVs. RSU as blockchain nodes {KS1, KS2, ..., KSn} creates new blocks to maintain the blockchain in the regionThe trust authority (TA): as a storage server C, the main task of TA includes the identity review of CAV users, deployment of smart contracts, and the issuance of transaction data. The TA also sends the pseudo-IDs to the CAVs. After the initial registration, TA provides every CAVs with a unique blockchain account to realize ACSMSWith different transfer protocols, CAVs can reach V2X through OBU. The concept design of the OBU [29] is illustrated in Figure 3. The OBU provides with long-range wide-area network (LoRaWAN), narrow-band internet of things (NB-IoT), and global positioning system (GPS). By LoRaWAN and NB-IoT, CAVs communicate with the TA (V2C), RSU (V2I), and other CAVs (V2V).Figure 3
The structure of ACSMS.In the ACSMS, there are four primary functions: blockchain-based PEKS, BKM, BTM, and atomic-cross chain-swap. We will, respectively, present the four functions.(a)
The blockchain-based public-key encryption with keyword search (PEKS). CAVs outsource ciphertext and cypher-text signature to the TA. Then, the TA broadcasts the signature and the serial number of ciphertext into the blockchain. Finally, by TEST algorithm and the signature, the searcher can obtain correct ciphertext from the TA(b)
The blockchain-based key management (BKM). The TA registers CAVs and sends pseudo-ID to CAVs. By blockchain-based PEKS, CAVs’ details (such as licence plate and driver’s licence) are encrypted to protect privacy. By pseudo-ID, CAVs enable explicit mutual authentication with RSU through a handover authentication protocol [30]. Furthermore, blockchain technology provides decentralized authentication for this protocol(c)
The blockchain-based trust management (BTM). After the BKM, CAV, and RSU establish a shared symmetric key for the subsequent communication session. Then, RSU gets CAV’s trust value from the blockchain. To share trust value with pseudo-ID, RSU generates an authentication code of CAVs’ trust value. Other CAVs can then gain the credibility of CAVs’ trust value without knowing the CAVs’ real identity(d)
The atomic-cross chain-swap. We use an atomic-cross chain-swap algorithm [31, 32] that provides cross-chain interoperability among blockchain-based systems. Only serial number of ciphertext and CAVs’ trust value are swapped across different blockchains


## 3.2. The Blockchain-Based PEKS

Based on the project of PEKS from bilinear pairings [17, 20, 33], we design a blockchain-based PEKS scheme for ACSMS. In the blockchain-based PEKS, the CAV (S) has a blockchain account bs1 and send message (M) to the TA (C). Furthermore, the public key and private key of bs1 are PKbs,SKbs. It should be emphasized that the PEKS construction in this work is very basic and can be extended to more complex PEKS through integrating with other technology. For example, by introducing cloud storage services [18], the CAV is able to outsource the data to the cloud storage services.


### 3.2.1. Setup Stage

With a security parameterλ, the system parameters {q, e^, G1, G2, H1, H2, H3, H4, μ,} are generated. Here, (G1,+) and (G2,·) are two cyclic groups of prime order q. e^: G1×G1⟶G2 be an admissible bilinear map, which satisfies bilinear, nondegenerate, and computable [34].H is a cryptographic hash function, H1:0,1∗⟶ℤq∗, ℤq∗=ρ∣1≤ρ≤q. H2:G2⟶0,1logq. H3:0,1∗⟶0,1h, where h is the output length of H3. H4:0,1∗⟶G1. μ = e^P,P.


### 3.2.2. Blockchain Stage

(i)
KeyGen. The CAV (S) picks a random secret key Sks=x∈ℤq∗, and corresponding public key is Pks=X=xP∈G1. With same parameters, the TA (C) generates the key as Pkc=Y=yP∈G1,Skc=y∈ℤq∗.(ii)
Trapdoor. Take as input Sks and keyword w, the CAV computes the Trapdoor [33] Tw=H1w+x−1P. Then, the CAV encrypts M through a standard public-key encryption E(·) [35].(iii)
PEKS. Take as input Pks, Pkc, and w, the CAV randomly selects r1,r2∈ℤq∗. The CAV computes A=r1H1wP+r1X, B=r2P, V=H2e^r1P+r2A,Y, and output PEKSw,PKs=A,B,V [33].With the encryptedM and keywords w1,w2,⋯,wn, a list of ciphertext is got by CAV, which is Cts=EM∥PEKSw1,PKs∥⋯∥PEKSwn,PKs, where ∥ indicates message concatenation operation. Then, the CAV computes the signature of Cts as [34] Sig=P/H3Cts+x. Finally, the CAV sends ciphertext Cts and Sig to the TA.To fast searchSig, the TA generates serial number Sni from bs1 record Sni−1, and Sni=Sni−1+1. The TA broadcasts a transaction Sig,Sni into blockchain nodes (RSU) to check data integrity and authenticate user, which the receive account is bs1. Then, RSU KSt will broadcast Sig,Sni into the blockchain network, when a blockchain node KSt(RSU) finds a correct nonce.
(iv)
TEST. Take as input Pks, y, A,B,V, and Tw, test H2e^yA,Tw+B=?V, where =? operation returns true if two values are equal and false if they are not equal. With keywords w1,w2,⋯,wn and TEST, the TA obtains ciphertexts of each keyword. Then, check e^H3CtsP+X,Sig=?e^P,P through blockchain. The Sig proves that the ciphertexts belong to the blockchain account bs1, when =? operation returns trueBy sending trapdoors and blockchain signature to the TA, the searcher can obtain ciphertexts as follows. The CAV (S) send Pks,Tw,Sigsearcher,ts,PKbs to the searcher, which Sigsearcher=P/H3PksTwts+SKbs. With Pks, y, A,B,V, and Tw, the TA can find ciphertexts from Pks,Tw,Sigsearcher,ts,PKbs. If e^H3CtsP+X,Sig=e^P,P, the ciphertexts belong to the blockchain account bs. If e^H3PksTwtsP+X,Sigsearcher=e^P,P, the legal searcher is consented with the CAV (S).The correctness of the scheme is proofed as follows:(1)H2e^yA,Tw+B=H2e^yA,H1w+x−1P+r2P=H2e^yr1PH1w+x,PH1w+x−1+r2=H2e^r1Y,P1+r2H1w+x=H2e^Y,r1P+r2r1PH1w+r1X=H2e^Y,r1P+r2A=H2e^r1P+r2A,Y=V,e^H3CtsP+X,Sig=e^PH3Cts+x,1H3Cts+xP=e^P,PH3Cts+x1/H3Cts+x=e^P,P.


## 3.2.1. Setup Stage

With a security parameterλ, the system parameters {q, e^, G1, G2, H1, H2, H3, H4, μ,} are generated. Here, (G1,+) and (G2,·) are two cyclic groups of prime order q. e^: G1×G1⟶G2 be an admissible bilinear map, which satisfies bilinear, nondegenerate, and computable [34].H is a cryptographic hash function, H1:0,1∗⟶ℤq∗, ℤq∗=ρ∣1≤ρ≤q. H2:G2⟶0,1logq. H3:0,1∗⟶0,1h, where h is the output length of H3. H4:0,1∗⟶G1. μ = e^P,P.


## 3.2.2. Blockchain Stage

(i)
KeyGen. The CAV (S) picks a random secret key Sks=x∈ℤq∗, and corresponding public key is Pks=X=xP∈G1. With same parameters, the TA (C) generates the key as Pkc=Y=yP∈G1,Skc=y∈ℤq∗.(ii)
Trapdoor. Take as input Sks and keyword w, the CAV computes the Trapdoor [33] Tw=H1w+x−1P. Then, the CAV encrypts M through a standard public-key encryption E(·) [35].(iii)
PEKS. Take as input Pks, Pkc, and w, the CAV randomly selects r1,r2∈ℤq∗. The CAV computes A=r1H1wP+r1X, B=r2P, V=H2e^r1P+r2A,Y, and output PEKSw,PKs=A,B,V [33].With the encryptedM and keywords w1,w2,⋯,wn, a list of ciphertext is got by CAV, which is Cts=EM∥PEKSw1,PKs∥⋯∥PEKSwn,PKs, where ∥ indicates message concatenation operation. Then, the CAV computes the signature of Cts as [34] Sig=P/H3Cts+x. Finally, the CAV sends ciphertext Cts and Sig to the TA.To fast searchSig, the TA generates serial number Sni from bs1 record Sni−1, and Sni=Sni−1+1. The TA broadcasts a transaction Sig,Sni into blockchain nodes (RSU) to check data integrity and authenticate user, which the receive account is bs1. Then, RSU KSt will broadcast Sig,Sni into the blockchain network, when a blockchain node KSt(RSU) finds a correct nonce.
(iv)
TEST. Take as input Pks, y, A,B,V, and Tw, test H2e^yA,Tw+B=?V, where =? operation returns true if two values are equal and false if they are not equal. With keywords w1,w2,⋯,wn and TEST, the TA obtains ciphertexts of each keyword. Then, check e^H3CtsP+X,Sig=?e^P,P through blockchain. The Sig proves that the ciphertexts belong to the blockchain account bs1, when =? operation returns trueBy sending trapdoors and blockchain signature to the TA, the searcher can obtain ciphertexts as follows. The CAV (S) send Pks,Tw,Sigsearcher,ts,PKbs to the searcher, which Sigsearcher=P/H3PksTwts+SKbs. With Pks, y, A,B,V, and Tw, the TA can find ciphertexts from Pks,Tw,Sigsearcher,ts,PKbs. If e^H3CtsP+X,Sig=e^P,P, the ciphertexts belong to the blockchain account bs. If e^H3PksTwtsP+X,Sigsearcher=e^P,P, the legal searcher is consented with the CAV (S).The correctness of the scheme is proofed as follows:(1)H2e^yA,Tw+B=H2e^yA,H1w+x−1P+r2P=H2e^yr1PH1w+x,PH1w+x−1+r2=H2e^r1Y,P1+r2H1w+x=H2e^Y,r1P+r2r1PH1w+r1X=H2e^Y,r1P+r2A=H2e^r1P+r2A,Y=V,e^H3CtsP+X,Sig=e^PH3Cts+x,1H3Cts+xP=e^P,PH3Cts+x1/H3Cts+x=e^P,P.


## 3.3. Blockchain-Based Key Management in VANETs

The design goals of the BKM are security and efficiency user authentication. The VANET performs the BKM inside the blockchain region that can decentralized record user public key [12, 22]. However, BKM [12, 22] is hard to realize key revocation and hard to support cross-chain verify. In this paper, we take the PKI-based scheme [30] to realize key agreement, public update, and revocation. The ACSMS setups stage corresponding to the BKM system setup. The ACSMS blockchain stage includes the BKM user registration, CAV authentication, and the TA management CAVs’ pseudo-ID. In contrast to [30], the blockchain is used to authentication users’ pseudo-ID.


### 3.3.1. System Setup Phase

In our system, all nodes keep loose time synchronization. The system setup phase is as follows: First, the RSU has to install a blockchain-based application. Second, based on the density of CAVs in a country, maps are partitioned into different regions. Third, TA sends a unique blockchain account to every RSU. RSU then creates new blocks to maintain the blockchain in the region. Finally, administrators apply ACSMS to these blockchains.


### 3.3.2. Registration Phase

To ensure legitimacy within VANET, TA must register new CAVs [22, 36] through relevant CAV information Sinfo. Sinfo is formed by phone number, licence plate, driver’s ID, etc. Different from the blockchain-based PEKS, the TA will sign the Sinfo. Take as input Sinfo, TA private key y, TA computes the signature of Sinfo, SigSinfo=P/H3Sinfo+y. By the blockchain-based PEKS, CAVs get ciphertext (Ctinfo) of Sinfo. Then, the CAV (S) sends the ciphertext Ctinfo to the TA (C), and the TA generates serial number Sni.The blockchain transaction of (SigSinfo,Sni) is processed as follows. The TA encapsulates (SigSinfo,Sni) into JSON format. Next, TA sends the transaction to the RSU, and the RSU executes the mining process; the transaction (SigSinfo,Sni) is added to the block. If a miner KSt finds a nonce, KSt broadcasts the block into the network. The RSU gets the transaction (SigSinfo,Sni) through update the blockchain.After the TA registers CAVs, the TA chooses a set of unlinkable pseudo-IDsPID=Pid1,Pid2,⋯ for each CAVs. For each Pidj∈PID, TA computes the private key sH4Pidj, s is a random number ∈ℤq∗. Then, TA sends all tuples (Pidj,sH4Pidj) back to the CAV (S) using a secure transmission protocol. By changing its pseudo-ID, CAV achieves conditional location privacy and identity privacy in the VANETs.


### 3.3.3. Authentication Phase

The authentication based on bilinear pairing [30] could ensure the security of ACSMS. We use an handover authentication protocol to ensure efficiency seamless handover over multiple access points [30].As Figure4 shows, when an RSU (KSt) is within the CAV direct communication range, the protocol run of BKM is as follows:
(1)
The CAV picks an unused pseudo-IDPidi,sH4Pidi(2)
With messageMi=PidiIDKStts and sH4Pidi, the CAV computes the signature σi=H1Mi·sH4Pidi [30], where IDKSt is RSU’ (KSt) identity, ts is a timestamp, and ∥ indicates the message concatenation operation(3)
The CAV computes the signature ofSigSinfo,Sni as Sigb=P/H3Sni∥Pidi∥IDKSt∥ts+SKbs, where SKbs is the private key of bs1(4)
The CAV sends the access request messageMi,σi,PKbs,Sni,Sigb,ts to RSU (KSt) through unicast, where PKbs is the public key of bs1(5)
The CAV computes the shared symmetric key with RSU (KSt) as KS−KSt=e^sH4Pidi,H4IDKSt [30]Figure 4
The protocol run of BKM.Upon receipt ofMi,σi,PKbs,Sni,Sigb, the RSU KSt proceeds as follows:
(1)
RSU first checksts to prevent replay attack. Then, RSU checks signature σi as e^σi,P=e^H1Mi·sH4Pidi,P=?e^H1Mi·H4Pidi,Pkc [30]. Then, RSU needs to retrieve the corresponding bs1,Sni from the blockchain to ensure user legitimacy within pseudo-ID. Finally, RSU checks e^H3Sni∥Pidi∥IDKSt∥tsP+PKbs,Sigb=?e^P,P. If both formula is correct, the CAV (S) is a legal vehicle, which was signed by the TA(2)
RSU further computes the shared symmetric keyKKSt−S: KKSt−S=e^H4Pidi,sH4IDKSt=e^sH4Pidi,H4IDKSt=KS−KSt [30](3)
Then,KSt generates an authentication code Aut=H1KKSt−SPidiIDKSt [30] and sends Pidi,IDKSt,Aut to the CAV (S)Upon receipt ofPidi,IDKSt,Aut, the CAV computes the verification code Ver=H1KKSt−SPidiIDKSt=?Aut [30]. If Ver matches Aut, KSt is a legitimate RSU. The shared key between the CAV and RSU is KKSt−S.By this protocol, CAV realizes authentication with RSU. The blockchain technology provides decentralized key authentication for the protocol. Between RSU and CAVs, a shared symmetric keyKKSt−S is also established for the subsequent communication session.If the administrator wants to findSinfo of Mi,σi,PKs1,Sni,Sigb, the TA first obtains Tw and Pks from the CAV. The TA takes as input Pks, y, and Tw and tests if H2e^yA,Tw+B=V. With keywords w1,w2,⋯,wn and TEST, the TA obtains ciphertext Ctinfo of each keyword. Then, the TA sends ciphertext Ctinfo to the CAV and CAV decryption Ctinfo as Sinfo′. After this, the CAV sends Sinfo′ to the TA. Then, TA checks if e^H3Sinfo′P+Y,SigSinfo=e^P,P, where SigSinfo is obtained from the account bs1. If so, the correct Sinfo belongs to account bs1.


## 3.3.1. System Setup Phase

In our system, all nodes keep loose time synchronization. The system setup phase is as follows: First, the RSU has to install a blockchain-based application. Second, based on the density of CAVs in a country, maps are partitioned into different regions. Third, TA sends a unique blockchain account to every RSU. RSU then creates new blocks to maintain the blockchain in the region. Finally, administrators apply ACSMS to these blockchains.


## 3.3.2. Registration Phase

To ensure legitimacy within VANET, TA must register new CAVs [22, 36] through relevant CAV information Sinfo. Sinfo is formed by phone number, licence plate, driver’s ID, etc. Different from the blockchain-based PEKS, the TA will sign the Sinfo. Take as input Sinfo, TA private key y, TA computes the signature of Sinfo, SigSinfo=P/H3Sinfo+y. By the blockchain-based PEKS, CAVs get ciphertext (Ctinfo) of Sinfo. Then, the CAV (S) sends the ciphertext Ctinfo to the TA (C), and the TA generates serial number Sni.The blockchain transaction of (SigSinfo,Sni) is processed as follows. The TA encapsulates (SigSinfo,Sni) into JSON format. Next, TA sends the transaction to the RSU, and the RSU executes the mining process; the transaction (SigSinfo,Sni) is added to the block. If a miner KSt finds a nonce, KSt broadcasts the block into the network. The RSU gets the transaction (SigSinfo,Sni) through update the blockchain.After the TA registers CAVs, the TA chooses a set of unlinkable pseudo-IDsPID=Pid1,Pid2,⋯ for each CAVs. For each Pidj∈PID, TA computes the private key sH4Pidj, s is a random number ∈ℤq∗. Then, TA sends all tuples (Pidj,sH4Pidj) back to the CAV (S) using a secure transmission protocol. By changing its pseudo-ID, CAV achieves conditional location privacy and identity privacy in the VANETs.


## 3.3.3. Authentication Phase

The authentication based on bilinear pairing [30] could ensure the security of ACSMS. We use an handover authentication protocol to ensure efficiency seamless handover over multiple access points [30].As Figure4 shows, when an RSU (KSt) is within the CAV direct communication range, the protocol run of BKM is as follows:
(1)
The CAV picks an unused pseudo-IDPidi,sH4Pidi(2)
With messageMi=PidiIDKStts and sH4Pidi, the CAV computes the signature σi=H1Mi·sH4Pidi [30], where IDKSt is RSU’ (KSt) identity, ts is a timestamp, and ∥ indicates the message concatenation operation(3)
The CAV computes the signature ofSigSinfo,Sni as Sigb=P/H3Sni∥Pidi∥IDKSt∥ts+SKbs, where SKbs is the private key of bs1(4)
The CAV sends the access request messageMi,σi,PKbs,Sni,Sigb,ts to RSU (KSt) through unicast, where PKbs is the public key of bs1(5)
The CAV computes the shared symmetric key with RSU (KSt) as KS−KSt=e^sH4Pidi,H4IDKSt [30]Figure 4
The protocol run of BKM.Upon receipt ofMi,σi,PKbs,Sni,Sigb, the RSU KSt proceeds as follows:
(1)
RSU first checksts to prevent replay attack. Then, RSU checks signature σi as e^σi,P=e^H1Mi·sH4Pidi,P=?e^H1Mi·H4Pidi,Pkc [30]. Then, RSU needs to retrieve the corresponding bs1,Sni from the blockchain to ensure user legitimacy within pseudo-ID. Finally, RSU checks e^H3Sni∥Pidi∥IDKSt∥tsP+PKbs,Sigb=?e^P,P. If both formula is correct, the CAV (S) is a legal vehicle, which was signed by the TA(2)
RSU further computes the shared symmetric keyKKSt−S: KKSt−S=e^H4Pidi,sH4IDKSt=e^sH4Pidi,H4IDKSt=KS−KSt [30](3)
Then,KSt generates an authentication code Aut=H1KKSt−SPidiIDKSt [30] and sends Pidi,IDKSt,Aut to the CAV (S)Upon receipt ofPidi,IDKSt,Aut, the CAV computes the verification code Ver=H1KKSt−SPidiIDKSt=?Aut [30]. If Ver matches Aut, KSt is a legitimate RSU. The shared key between the CAV and RSU is KKSt−S.By this protocol, CAV realizes authentication with RSU. The blockchain technology provides decentralized key authentication for the protocol. Between RSU and CAVs, a shared symmetric keyKKSt−S is also established for the subsequent communication session.If the administrator wants to findSinfo of Mi,σi,PKs1,Sni,Sigb, the TA first obtains Tw and Pks from the CAV. The TA takes as input Pks, y, and Tw and tests if H2e^yA,Tw+B=V. With keywords w1,w2,⋯,wn and TEST, the TA obtains ciphertext Ctinfo of each keyword. Then, the TA sends ciphertext Ctinfo to the CAV and CAV decryption Ctinfo as Sinfo′. After this, the CAV sends Sinfo′ to the TA. Then, TA checks if e^H3Sinfo′P+Y,SigSinfo=e^P,P, where SigSinfo is obtained from the account bs1. If so, the correct Sinfo belongs to account bs1.


## 3.4. Blockchain-Based Trust Management in VANETs

The BKM uses pseudo-ID to provide conditional privacy. However, VANET is difficult to forward reliable message with an anonymous environment. Besides, the user with pseudo-ID will lack the motivation to forward announcements [37]. The BTM [13, 24, 25] was proposed to resolve these issues, which can recognize and eliminate of misbehaving vehicles. The process of the BTM is as follows. First, the CAV validates the legitimacy of received messages from neighboring CAVs. Second, based on the validated result, the rating of messages is generated by CAVs. Third, with the ratings uploaded from CAVs, the RSU gets the offsets of involved CAVs. Finally, the RSU adds the offset into the blockchain, where the offset is reflected by the CAV’s blockchain account balance.To calculate trust value, Zhao et al. [25] classify CAVs into three roles: privilege vehicles (S1), enterprise vehicles (S2), and individual vehicles (S3). Each role has different initial credibility. To share trust value with pseudo-ID, KSt generates an authentication code of CAV’s trust value OCP as SigOCP=P/H3PidiOCPts1+SKKSt. SKKSt is the private key of the RSU (KSt). Upon receipt of Message,Pidi,ts1,SigOCP,OCP, other CAV checks e^H3PidiOCPts1P+PKKSt,SigOCP=?e^P,P, where PKKSt is RSU’s (KSt) public key.A CAV receiveM kinds of road-relevant events from different CAVs in a certain time. There are J CAVs in the reference set. The CAVs separate received messages into M groups as g1,g2,⋯,gM. gi is one road-relevant event, which contains messages Wi1,Wi2,⋯,WiJ that send by CAVs in the reference set J. According to [25], the tuple of one specific message (Wkj [25]) is defined as
(2)Wkj=dkj,timekj,OCP,P∈S1,S2,S3.The CAV receiver obtains the road-relevant eventk from the neighboring CAV j. dkj is the distance between the location of the event k and CAV j; timekj is the message received time of CAV j; OCP is the trust value of CAV j. According to [25], the credibility of specific messages (ckj) is calculated as:
(3)ckj=ηeαdkj+1−ηmkj+OCp.η is the balance coefficient between distance and time; α is a parameter to control the communication boundary; mkj is used to prevent replay attack. Next, ti is the trust value of one road-relevant event gi, which contains c1i,c2i,⋯,cJi. ti is calculated as (3) using Bayesian Inference [38].
(4)ti=Pe∣gi=Pe·∏k=1JPcik∣ePe·∏k=1jPcik∣e+Pe¯·∏k=1JPcik∣e¯.Pe is the prior probability of event e; e¯ is the complementary event of e. By comparing with threshold (Thr), the CAV j judges the event gi. Then, CAV j generates ratings rateij(i.e., +1 or -1) and sends to RSU. By weighted aggregation (4), RSU gets the offset of the trust value ∈0,1. According to [13], the sensitivity of ratings offseti is controlled by F·.
(5)offseti=Fm·m+Fn·nm+n,wherem is the positive(+1) rating and n is the negative(-1) rating;Comparedoffseti with a threshold (Thr1), if offseti>=Thr1, the offset of one CAV j is offsetij=rateij. Otherwise, the offset of one CAV j is offsetij=−rateij. After the event gi, the new trust value of CAV j is OCp=OCp+offsetij. Finally, if a miner finds offset blocks that meet difficulty target, RSUs can share the new trust value of CAV j.


## 3.5. Atomic Swap-Based Cross-Chain Scheme

For now, the researcher proposed four categories cross-chain technologies [39], which include atomic cross-chain swap, multicentre witness, side chain (Ethereum 2.0), and distributed private key control. Atomic cross-chain swap [31, 32, 40, 41] is a standard method to connect multiple blockchains. Without trusted third parties, the atomic swap can realize fair cross-chain exchange.The ACSMS can exchange the CAV’s data for the blockchain-based PEKS, the BKM, and the BTM. Take as input last signature (Sig,Sni, data), old blockchain account (PKbs1, SKbs1), and new blockchain account (PKbs2, SKbs2). S computes the cross-chain transaction AssetR=SigSni+1tsOCp,Sni+1,ts,PKbs1⟶PKbs2,OCp,swap. The signature SigSni+1tsOCp=P/H3Sni+1tsOCp+SKbs1. After the ACSMS process, if searcher wants to find past information, then searcher uses index Si and PKbs1 to find past signature (Sig), which can check data integrity and authenticate the user. The cross-chain model is illustrated in Figure 5.Figure 5
Atomic swap-based cross-chain scheme.The atomic swaps problem in VANETs is as follows. Assume a CAV has an account (PKbs1, PRbs1) and holds an asset Z=AssetS,OCp in blockchain A. If CAV accesses blockchain B domain, the CAV creates a new blockchain account (PKbs2, PRbs2) in blockchain B. By the smart contract [32], the CAV can deal with other CAV or RSU or TA to realized cross-chain swap. Compared with other CAVs and RSU, it is more securely and efficient that CAVs deal with the TA as escrow agent [31, 32, 41]. The escrow agent to occur for the ACSMS is as follows.Algorithm 1
Atomic swap for ACSMS {depositA, depositB: bool; hash1, hash2 : int256;//the deposit function allows user transfer of the asset to the smart contract.uint startA, startB; //protocol starting timeinitialize {deposited A : = False; deposited B := False; hash1=hash2=0; }depositA{if sender = accountA and asset=Z:Then depositA : = True and hash = h1 and startA = time()}//h1 is hash-lock; startA + timeset is time-lock.depositB{if sender = TA and asset=Z:Then depositB : = True and hash = h2 and startB = time()}Finalise{if depositA and depositB and now < startA + timeset :Then {depositA : = False; depositB:= Falsesend(accountB,Z), send(TA,Z)}}cancelA{if (depositA and sha-256(x2) = h2) or now> startA + timesetthen {depositA : = False; Send(accountA,Z)}}cancelB{if (depositB and sha-256(x1) = h1) or now> startB + timesetthen {depositB : = False; Send(TA,Z)}}}


## 4. Security Analysis

### 4.1. Security of Blockchain-Based PEKS

The security of blockchain-based PEKS consists of three aspects: CAVs’ data security preservation [42], conditional identity privacy, and storage correctness guarantee.
(i)
CAVs’ data security preservation. In the ACSMS, with a standard public key encryption E·, message M with keywords, the TA gets ciphertext Cts. Cts is encrypted with SKs,PKs,PKc, any adversary is infeasible to compute SKs due to the hardness assumption of bilinear Diffie-Hellman problem [43]. Without SKs, the TA can not decryption Cts(ii)
Conditional identity privacy. Many ciphertexts are stored in the server. It is difficult for any adversary to find specific ciphertext without trapdoor Tw. However, the ciphertexts have identity privacy during storage; any searcher can use trapdoor Tw to find the ciphertext. The searcher has no right to download ciphertext without the signature of blockchain account bs1. Therefore, blockchain-based PEKS can resist the keyword guessing attacks (KGA).(iii)
Storage correctness guarantee. The signature of the ciphertext provides storage correctness guarantee, which is obtained from the blockchain


### 4.2. Security of BKM

A distributed BKM is built through a key management protocol [30] and blockchain technology. ACSMS can achieve subscription validation, server authentication, CAV untraceability, and anonymity. Furthermore, the ACSMS can achieve distributed and tamper-proofing through blockchain technology. In addition, the BKM can against typical attacks towards the VANETs as follows: internal attack, public key tampering, and DoS Attack.
(i)
Internal attack. The adversary eavesdrops on the communication data between the CAVs and RSU [22]. However, without private key sH4Pidi or sH4IDKSt, adversary cannot get shared symmetric key KS−KSt between the CAVs and RSU(ii)
Public key tampering. If adversary creates fake pseudo-ID Pidi without a legal blockchain account, the RSU can verify that e^H3Sni∥Pidi∥IDKSt∥tsP+PKbs,Sigb≠e^P,P. In the ACSMS, legal blockchain account is registered by the TA; adversary cannot counterfeit the registration transaction into the blockchain(iii)
DoS Attack. The ACSMS can resist DoS Attack by timestamp ts and hardware security module. If adversary sends a lot of intercepted messages to VANETs, timestamp ensures the freshness of the messages


### 4.3. Security of BTM

The security of BTM consists of three aspects: conditional identity privacy, prevention of replay attack, and prevention of message spoofing attack.(i)
Conditional identity privacy. CAVs broadcast message Message,Pidi,ts1,SigOCP,OCP without blockchain account information; the Pidi is unlinkable pseudo-IDs. Thus, other vehicles are difficult to analyze the user information with the BTM. But, the RSU can find the blockchain account bs1 through the BKM, and the TA can find relevant CAV information Sinfo by the blockchain-based PEKS(ii)
Prevention of replay attack. By timekj and mkj, if the messages are send by the same CAVs at different times, the credibility of specific messages ckj will set to zero. Therefore, equations (2) and (3) will reject the same information with a different timestamp(iii)
Prevention of message spoofing attack. Adversary may broadcast fake messages to neighbors. In the ACSMS, we take the Bayesian Inference-based rating generation scheme. Therefore, the receiver will analyze messages from different reference CAVs about the same event


### 4.4. Security of Atomic Swap

The ACSMS achieves hash locking and smart contract to create conditional payment. The atomicity of atomic swap is guaranteed by the cross-chain protocol. At the same time, the security of the atomic cross-chain swap is ensured by blockchain-based PEKS, BKM, and BTM. The security of atomic swap consists of three aspects: CAVs’ data security preservation, conditional identity privacy, and storage correctness guarantee. The atomic swap also against typical attacks towards the VANETs is as follows: internal attack, public key tampering, and DoS Attack. The ACSMS achieves security and anonymity by the blockchain-based PEKS, BKM, and BTM. Furthermore, in ACSMS, only the TA and RSU can create new transaction that can resist targeted attacks [44].


### 4.5. Comparison of Related Works

There are many blockchain-based application systems that have been developed in VANETs [12, 13, 16, 17, 22, 24]. These researches can protect CAV privacy and ensure security certificate. As shown in Table 1, compared with these schemes, ACSMS integrates the function of the above methods into the ACSMS. Besides, the ACSMS can provide cross-chain process, which boost interoperability between multiple blockchain. Furthermore, compared with [25], the ACSMS can support cross-chain stage security in VANETs.Table 1
Comparison of related works.
Feature[12][16][22][13][25][24][18, 20][17]ACSMSPEKS××××××√√√BKM√√√××√××√BTM×××√√√××√PoW√√√√×√√×√Smart contract××√×√×××√No TA√√×√×××√×Key agreement√√√×√×××√Cross-chain××××√×××√Table1 shows the comparison of related work. A safe and reliable decentralized data storage system was built in [17, 18, 20]. The scheme [12, 16, 22, 24] applied blockchain technology into VANETs; the management of CAVs’ key is more efficient and secure. Furthermore, by BTM [13, 24, 25], the CAV could forward reliable announcements without relevant CAVs’ information, and the users with pseudo-ID are encouraged to forward announcements. The ACSMS scheme uses PEKS and blockchain technology to integrate above the functions to support multiple blockchain-based applications with a single blockchain account. In addition, we use atomic swap smart contract to achieve cross-chain interoperability among blockchain-based systems.


## 4.1. Security of Blockchain-Based PEKS

The security of blockchain-based PEKS consists of three aspects: CAVs’ data security preservation [42], conditional identity privacy, and storage correctness guarantee.
(i)
CAVs’ data security preservation. In the ACSMS, with a standard public key encryption E·, message M with keywords, the TA gets ciphertext Cts. Cts is encrypted with SKs,PKs,PKc, any adversary is infeasible to compute SKs due to the hardness assumption of bilinear Diffie-Hellman problem [43]. Without SKs, the TA can not decryption Cts(ii)
Conditional identity privacy. Many ciphertexts are stored in the server. It is difficult for any adversary to find specific ciphertext without trapdoor Tw. However, the ciphertexts have identity privacy during storage; any searcher can use trapdoor Tw to find the ciphertext. The searcher has no right to download ciphertext without the signature of blockchain account bs1. Therefore, blockchain-based PEKS can resist the keyword guessing attacks (KGA).(iii)
Storage correctness guarantee. The signature of the ciphertext provides storage correctness guarantee, which is obtained from the blockchain


## 4.2. Security of BKM

A distributed BKM is built through a key management protocol [30] and blockchain technology. ACSMS can achieve subscription validation, server authentication, CAV untraceability, and anonymity. Furthermore, the ACSMS can achieve distributed and tamper-proofing through blockchain technology. In addition, the BKM can against typical attacks towards the VANETs as follows: internal attack, public key tampering, and DoS Attack.
(i)
Internal attack. The adversary eavesdrops on the communication data between the CAVs and RSU [22]. However, without private key sH4Pidi or sH4IDKSt, adversary cannot get shared symmetric key KS−KSt between the CAVs and RSU(ii)
Public key tampering. If adversary creates fake pseudo-ID Pidi without a legal blockchain account, the RSU can verify that e^H3Sni∥Pidi∥IDKSt∥tsP+PKbs,Sigb≠e^P,P. In the ACSMS, legal blockchain account is registered by the TA; adversary cannot counterfeit the registration transaction into the blockchain(iii)
DoS Attack. The ACSMS can resist DoS Attack by timestamp ts and hardware security module. If adversary sends a lot of intercepted messages to VANETs, timestamp ensures the freshness of the messages


## 4.3. Security of BTM

The security of BTM consists of three aspects: conditional identity privacy, prevention of replay attack, and prevention of message spoofing attack.(i)
Conditional identity privacy. CAVs broadcast message Message,Pidi,ts1,SigOCP,OCP without blockchain account information; the Pidi is unlinkable pseudo-IDs. Thus, other vehicles are difficult to analyze the user information with the BTM. But, the RSU can find the blockchain account bs1 through the BKM, and the TA can find relevant CAV information Sinfo by the blockchain-based PEKS(ii)
Prevention of replay attack. By timekj and mkj, if the messages are send by the same CAVs at different times, the credibility of specific messages ckj will set to zero. Therefore, equations (2) and (3) will reject the same information with a different timestamp(iii)
Prevention of message spoofing attack. Adversary may broadcast fake messages to neighbors. In the ACSMS, we take the Bayesian Inference-based rating generation scheme. Therefore, the receiver will analyze messages from different reference CAVs about the same event


## 4.4. Security of Atomic Swap

The ACSMS achieves hash locking and smart contract to create conditional payment. The atomicity of atomic swap is guaranteed by the cross-chain protocol. At the same time, the security of the atomic cross-chain swap is ensured by blockchain-based PEKS, BKM, and BTM. The security of atomic swap consists of three aspects: CAVs’ data security preservation, conditional identity privacy, and storage correctness guarantee. The atomic swap also against typical attacks towards the VANETs is as follows: internal attack, public key tampering, and DoS Attack. The ACSMS achieves security and anonymity by the blockchain-based PEKS, BKM, and BTM. Furthermore, in ACSMS, only the TA and RSU can create new transaction that can resist targeted attacks [44].


## 4.5. Comparison of Related Works

There are many blockchain-based application systems that have been developed in VANETs [12, 13, 16, 17, 22, 24]. These researches can protect CAV privacy and ensure security certificate. As shown in Table 1, compared with these schemes, ACSMS integrates the function of the above methods into the ACSMS. Besides, the ACSMS can provide cross-chain process, which boost interoperability between multiple blockchain. Furthermore, compared with [25], the ACSMS can support cross-chain stage security in VANETs.Table 1
Comparison of related works.
Feature[12][16][22][13][25][24][18, 20][17]ACSMSPEKS××××××√√√BKM√√√××√××√BTM×××√√√××√PoW√√√√×√√×√Smart contract××√×√×××√No TA√√×√×××√×Key agreement√√√×√×××√Cross-chain××××√×××√Table1 shows the comparison of related work. A safe and reliable decentralized data storage system was built in [17, 18, 20]. The scheme [12, 16, 22, 24] applied blockchain technology into VANETs; the management of CAVs’ key is more efficient and secure. Furthermore, by BTM [13, 24, 25], the CAV could forward reliable announcements without relevant CAVs’ information, and the users with pseudo-ID are encouraged to forward announcements. The ACSMS scheme uses PEKS and blockchain technology to integrate above the functions to support multiple blockchain-based applications with a single blockchain account. In addition, we use atomic swap smart contract to achieve cross-chain interoperability among blockchain-based systems.


## 5. Performance Evaluation

The performance evaluation of ACSMS was carried out using simulations. Our results are generated using pypbc (the encryption algorithm) and truffle (blockchain for ACSMS). ACSMS is simulated by our laptop with 2.6Ghz Core i7 CPU and 16G RAM and display card Radeon Pro 555X 4 GB. We also simulated the ACSMS in the elastic compute service with Ubuntu 18.02, 4v 3.1GHz/3.5Ghz CPU and 16G RAM.The simulation of the trust management system in VANET [45] shows that the rate of malicious vehicles. A variable percentage is generated to simulate a different percentage of malicious vehicles like in [45]. The performance of trust management is evaluated through the trust value of CAVs OCP. However, our BTM scheme only affects the initial OCP, and the RSU uploads trust value after receiving multiple pieces of evidence. Therefore, blockchain will not change the efficiency of trust management [32, 45, 46].


### 5.1. Blockchain-Based PEKS

To evaluate blockchain-based PEKS and other related woks, we use a cryptographic function called Type-A [17]. We set ∣ℤq∗∣=160 bits and ∣G1∣=∣G2∣=1024 bits by setting parameters qbits=1024 and rbits=160, where ∣x∣ is the length of x. We take ZSS (Zhang-Safavi-Naini-Susilo) short signature scheme from Bilinear Pairing [34]. Besides, pypbc requires the hash of the signature scheme and key in the same group. So, we use 160 bits Sig=P/H1Cts+x instead of Sig=P/H3Cts+x.Figure6 shows the computation cost comparisons for the FTDS [17] and the BSPP [20]. The computation costs of encrypting ciphertext and decrypt ciphertext are constant, which not show in the picture. Each scheme uses 100 keywords to encrypt 100 files. The FTDS [17] is slower than the ACSMS and the BSPP in KeyGen and PEKS, because the FTDS uses key-aggregate encryption, which is a decentralized PEKS scheme. In BSPP [20], the user’s medical data is encrypted and stored in the server of the hospital. The corresponding index of user data is stored in the blockchain. It can be seen that the calculation delay of BSPP is close to the ACSMS, because the calculation of KeyGen, Trapdoor, PEKS, and Test all depends on the PEKS algorithm.Figure 6
Computation cost comparison for algorithms.The blockchain storage time of the three schemes is similar. Because all three plans store indexes or proofs, the small amount of data will not affect the blockchain’s storage speed. The block generation rate will limit blockchain-based on workload consensus. By adjusting the difficulty target, administrators can change the block generation rate of the blockchain. However, too fast block generation rate will lead to the blockchain bifurcating. Therefore, the block generation rate of the typical blockchain is maintained at a certain level. Consequently, we can consider that the three schemes have the same computing delay on the blockchain storage.


### 5.2. BKM

Then, we study the processing time cost for the BKM. Our BKM scheme based on PairHand [30], the user cryptographic operation of [30] is 1ECSM+1Pairing. Based on PairHand, we use blockchain to realize distributed key authentication. Therefore, the user cryptographic operation of the BKM in ACSMS is 1ECSM+2Pairing+1hash. In the PairHand, the RSU will transmit messages to TA after authentication, which can find the real identity of CAVs. However, if CAV transmission legal pseudo-IDs to the adversary, the RSU cannot distinguish the adversary and the normal CAVs in the authentication. Although our scheme costs more processing time than the PairHand, our schemes can provide decentralized key authentication than [30]. To evaluate the performance of our scheme, we compare the conventional handover schemes [12, 30].We can obtain that the exponential increase of blockchain key transfer time in decentralized BKM [12] as shows in Figure 7. In [12], the keys of new joining members are delivered by the blockchain. Our BKM only uses the blockchain record Sinfo to authenticate users, which increases linearly. Although, in the experiment, our key transmission time authenticated by this scheme is relatively large. But, RSU only needs to find the user’s signature in the blockchain. There is no need to store data into the blockchain. In this way, our scheme can better support other blockchain-based applications.Figure 7
Processing time comparison different schemes.


### 5.3. Atomic Cross-Chain Swap

To evaluate the effect of ACSMS, we realize the atomic swap protocol in python. Two PoW-based blockchains are built in python. Administrators can set the difficulty target of each blockchain to adjust blockchain throughput. The total number of CAVs is 1000, andZ=AssetR,OCp is calculated by CAVs. Furthermore, there are average packet latency and blockchain transaction time in the blockchain-based VANET application [22]. As Figure 8 shows, the delay of atomic cross-chain swap changes with the number of CAVs per unit time.Figure 8
Average delay over different number of CAVs.


### 5.4. Engineering Applications

On Ethereum [14], the user can write a smart contract to realize a distributed program. In order to evaluate our proposed ACSMS, we have built a web application of ACSMS, as illustrated in Figure 9.Figure 9
The application of ACSMS.The application of ACSMS was built as follows:(1)
We installed truffle, Ganache, and node.js v9.10.0. Next, we configured babel (a JavaScript compiler), bootstrap (HTML, CSS, and JS library), identicon (a visual representation of a hash value), chai (a BDD/TDD assertion library), mocha (a feature-rich JavaScript test framework), and web3 (web3.js interact with Ethereum node using HTTP, IPC, or WebSocket). Then, we use those to create a package.json file for the project using npm install to install these libraries(2)
We developed a smart contract in atom text editor and write test cases for use with TDD (test-driven development, chai, and mocha). Then, metamask was used to access ethrum enabled distributed applications(3)
As shown in Figure9, the application of ACSMS saves Sig,Sni into the blockchain network, which blockchain-based PEKS was realized(4)
With metamask and web3 command web3.eth.getAccounts(·), user blockchain account was got for BKM. RSU can retrieve the corresponding bs1,Sni from the blockchain to ensure user legitimacy within pseudo-ID(5)
With metamask and web3 command web3.eth.getBalance (Account), the user account balance was got for BTM. To share trust value with pseudo-ID, RSU generates an authentication code of CAV’s trust valueOCP, where OCP is reflected by the CAV’s blockchain in account balance. Furthermore, after BTM, RSU could send the balance to the user account through the button


## 5.1. Blockchain-Based PEKS

To evaluate blockchain-based PEKS and other related woks, we use a cryptographic function called Type-A [17]. We set ∣ℤq∗∣=160 bits and ∣G1∣=∣G2∣=1024 bits by setting parameters qbits=1024 and rbits=160, where ∣x∣ is the length of x. We take ZSS (Zhang-Safavi-Naini-Susilo) short signature scheme from Bilinear Pairing [34]. Besides, pypbc requires the hash of the signature scheme and key in the same group. So, we use 160 bits Sig=P/H1Cts+x instead of Sig=P/H3Cts+x.Figure6 shows the computation cost comparisons for the FTDS [17] and the BSPP [20]. The computation costs of encrypting ciphertext and decrypt ciphertext are constant, which not show in the picture. Each scheme uses 100 keywords to encrypt 100 files. The FTDS [17] is slower than the ACSMS and the BSPP in KeyGen and PEKS, because the FTDS uses key-aggregate encryption, which is a decentralized PEKS scheme. In BSPP [20], the user’s medical data is encrypted and stored in the server of the hospital. The corresponding index of user data is stored in the blockchain. It can be seen that the calculation delay of BSPP is close to the ACSMS, because the calculation of KeyGen, Trapdoor, PEKS, and Test all depends on the PEKS algorithm.Figure 6
Computation cost comparison for algorithms.The blockchain storage time of the three schemes is similar. Because all three plans store indexes or proofs, the small amount of data will not affect the blockchain’s storage speed. The block generation rate will limit blockchain-based on workload consensus. By adjusting the difficulty target, administrators can change the block generation rate of the blockchain. However, too fast block generation rate will lead to the blockchain bifurcating. Therefore, the block generation rate of the typical blockchain is maintained at a certain level. Consequently, we can consider that the three schemes have the same computing delay on the blockchain storage.


## 5.2. BKM

Then, we study the processing time cost for the BKM. Our BKM scheme based on PairHand [30], the user cryptographic operation of [30] is 1ECSM+1Pairing. Based on PairHand, we use blockchain to realize distributed key authentication. Therefore, the user cryptographic operation of the BKM in ACSMS is 1ECSM+2Pairing+1hash. In the PairHand, the RSU will transmit messages to TA after authentication, which can find the real identity of CAVs. However, if CAV transmission legal pseudo-IDs to the adversary, the RSU cannot distinguish the adversary and the normal CAVs in the authentication. Although our scheme costs more processing time than the PairHand, our schemes can provide decentralized key authentication than [30]. To evaluate the performance of our scheme, we compare the conventional handover schemes [12, 30].We can obtain that the exponential increase of blockchain key transfer time in decentralized BKM [12] as shows in Figure 7. In [12], the keys of new joining members are delivered by the blockchain. Our BKM only uses the blockchain record Sinfo to authenticate users, which increases linearly. Although, in the experiment, our key transmission time authenticated by this scheme is relatively large. But, RSU only needs to find the user’s signature in the blockchain. There is no need to store data into the blockchain. In this way, our scheme can better support other blockchain-based applications.Figure 7
Processing time comparison different schemes.


## 5.3. Atomic Cross-Chain Swap

To evaluate the effect of ACSMS, we realize the atomic swap protocol in python. Two PoW-based blockchains are built in python. Administrators can set the difficulty target of each blockchain to adjust blockchain throughput. The total number of CAVs is 1000, andZ=AssetR,OCp is calculated by CAVs. Furthermore, there are average packet latency and blockchain transaction time in the blockchain-based VANET application [22]. As Figure 8 shows, the delay of atomic cross-chain swap changes with the number of CAVs per unit time.Figure 8
Average delay over different number of CAVs.


## 5.4. Engineering Applications

On Ethereum [14], the user can write a smart contract to realize a distributed program. In order to evaluate our proposed ACSMS, we have built a web application of ACSMS, as illustrated in Figure 9.Figure 9
The application of ACSMS.The application of ACSMS was built as follows:(1)
We installed truffle, Ganache, and node.js v9.10.0. Next, we configured babel (a JavaScript compiler), bootstrap (HTML, CSS, and JS library), identicon (a visual representation of a hash value), chai (a BDD/TDD assertion library), mocha (a feature-rich JavaScript test framework), and web3 (web3.js interact with Ethereum node using HTTP, IPC, or WebSocket). Then, we use those to create a package.json file for the project using npm install to install these libraries(2)
We developed a smart contract in atom text editor and write test cases for use with TDD (test-driven development, chai, and mocha). Then, metamask was used to access ethrum enabled distributed applications(3)
As shown in Figure9, the application of ACSMS saves Sig,Sni into the blockchain network, which blockchain-based PEKS was realized(4)
With metamask and web3 command web3.eth.getAccounts(·), user blockchain account was got for BKM. RSU can retrieve the corresponding bs1,Sni from the blockchain to ensure user legitimacy within pseudo-ID(5)
With metamask and web3 command web3.eth.getBalance (Account), the user account balance was got for BTM. To share trust value with pseudo-ID, RSU generates an authentication code of CAV’s trust valueOCP, where OCP is reflected by the CAV’s blockchain in account balance. Furthermore, after BTM, RSU could send the balance to the user account through the button


## 6. Conclusion

In this paper, we proposed the ACSMS to boost the scalability of blockchain-based applications in VANETs. Besides, the ACSMS integrates the blockchain-based schemes into a single blockchain through the bilinear pairing. First, we designed a blockchain-based PKES to check data integrity and authenticate the user. Second, we designed blockchain-based key management. The BKM uses data of blockchain-based PKES to provide decentralized key authentication. Third, based on the BKM, CAVs get proof of trust value from the RSU. Therefore, the CAVs can share reasonable trust value in blockchain-based trust management. Finally, the atomic swap-based cross-chain scheme can exchange user trust value and data index across the chain. The searcher quickly finds the data of blockchain-based PKES in the different blockchain. However, the simulation results demonstrate that the performance of ACSMS is no improvement than the previous scheme. Nevertheless, security analysis shows that our schemes can achieve the security requirements of VANETs.In the future, we will take PEKS for cloud storage services. The sender in ACSMS can outsource the data to the cloud storage services. On the other, we may use PoS-based blockchain instead of PoW-based blockchain as long as security is ensured.



---

*Source: 6679654-2021-01-29.xml*