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

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.


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][6][7] but also need to decide the trustworthiness of other CAVs' messages. There are many attacks and challenges [8][9][10][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 blockchainbased 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 blockchainbased 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 functionality The remainder of this paper is organized as follows. The related works are briefly introduced in Section 2. 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.

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).

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  As shown in Figure 1, 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.
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  3. An Atomic Cross-Chain Swap-Based Management System 3.1. System Model. As illustrated in Figure 2, three types of entities in VANETs are CAVs, RSU, and TA. 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 {KS 1 , KS 2 , ..., KS n } creates new blocks to maintain the blockchain in the region The 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 ACSMS With 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).

Wireless Communications and Mobile Computing
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.     [17,20,33], we design a blockchain-based PEKS scheme for ACSMS. In the blockchain-based PEKS, the CAV (S) has a blockchain account b s 1 and send message (M) to the TA (C). Furthermore, the public key and private key of b s 1 are ðPK b s , SK b s Þ.
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.
H is a cryptographic hash function,

Blockchain Stage
(i) KeyGen. The CAV (S) picks a random secret key S k s = x ∈ ℤ * q , and corresponding public key is Pk s = X = xP ∈ G 1 . With same parameters, the TA (C) generates the key as ðPk c = Y = yP ∈ G 1 , Sk c = y ∈ ℤ * q Þ.

Wireless Communications and Mobile Computing
xÞ −1 P. Then, the CAV encrypts M through a standard public-key encryption E(·) [35].
With the encrypted M and keywords fw 1 , w 2 , ⋯, w n g, a list of ciphertext is got by CAV, which is Ct s = EðMÞ∥ PEKSðw 1 , PK s Þ∥⋯∥PEKSðw n , PK s Þ, where ∥ indicates message concatenation operation. Then, the CAV computes the signature of Ct s as [34] Sig = P/ðH 3 ðCt s Þ + xÞ. Finally, the CAV sends ciphertext Ct s and Sig to the TA.
To fast search Sig, the TA generates serial number Sn i from b s 1 record Sn i−1 , and Sn i = Sn i−1 + 1. The TA broadcasts a transaction ðSig, Sn i Þ into blockchain nodes (RSU) to check data integrity and authenticate user, which the receive account is b s 1 . Then, RSU KS t will broadcast ðSig, Sn i Þ into the blockchain network, when a blockchain node KS t (RSU) finds a correct nonce.
(iv) TEST. Take as input Pk s , y, ðA, B, VÞ, and T w , test H 2 ðêðyA, T w + BÞÞ = ? V, where = ? operation returns true if two values are equal and false if they are not equal. With keywords fw 1 , w 2 , ⋯, w n g and TEST, the TA obtains ciphertexts of each keyword. Then, checkêðH 3 ðCt s ÞP + X, SigÞ = ?ê ðP, PÞ through blockchain. The Sig proves that the ciphertexts belong to the blockchain account b s 1 , when = ? operation returns true By sending trapdoors and blockchain signature to the TA, the searcher can obtain ciphertexts as follows. The CAV (S) send ðPk s , T w , Sig searcher , ts, PK b s Þ to the searcher, which Sig searcher = P/ðH 3 ðPk s kT w ktsÞ + SK b s Þ. With Pk s , y, ðA, B, VÞ, and T w , the TA can find ciphertexts from ðPk s , T w , Sig searcher , ts, PK b s Þ. IfêðH 3 ðCt s ÞP + X, SigÞ =êðP, PÞ, the ciphertexts belong to the blockchain account b s . IfêðH 3 ðPk s kT w ktsÞP + X, Sig searcher Þ =êðP, PÞ, the legal searcher is consented with the CAV (S).
The correctness of the scheme is proofed as follows: 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.

Registration Phase.
To ensure legitimacy within VANET, TA must register new CAVs [22,36] through relevant CAV information S info . S info is formed by phone number, licence plate, driver's ID, etc. Different from the blockchain-based PEKS, the TA will sign the S info . Take as input S info , TA private key y, TA computes the signature of S info , Sig S info = P/ðH 3 ðS info Þ + yÞ. By the blockchain-based PEKS, CAVs get ciphertext (Ct info ) of S info . Then, the CAV (S) sends the ciphertext Ct info to the TA (C), and the TA generates serial number Sn i . The blockchain transaction of (Sig S info ,Sn i ) is processed as follows. The TA encapsulates (Sig S info ,Sn i ) into JSON format. Next, TA sends the transaction to the RSU, and the RSU executes the mining process; the transaction (Sig S info ,Sn i ) is added to the block. If a miner KS t finds a nonce, KS t broadcasts the block into the network. The RSU gets the transaction (Sig S info ,Sn i ) through update the blockchain.
After the TA registers CAVs, the TA chooses a set of unlinkable pseudo-IDs PID = fPid 1 , Pid 2 , ⋯g for each CAVs. For each Pid j ∈ PID, TA computes the private key s H 4 ðPid j Þ, s is a random number ∈ℤ * q . Then, TA sends all tuples (Pid j ,sH 4 ðPid j Þ) 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.

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 Figure 4 shows, when an RSU (KS t ) is within the CAV direct communication range, the protocol run of BKM is as follows: (1) The CAV picks an unused pseudo-ID ðPid i , sH 4 ðPid i ÞÞ Upon receipt of fM i , σ i , PK b s , Sn i , Sig b g, the RSU KS t proceeds as follows: (1) RSU first checks ts to prevent replay attack. Then, RSU checks signature σ i asêðσ i , PÞ =êðH 1 ðM i Þ · sH 4 ðPid i Þ, PÞ = ?ê ðH 1 ðM i Þ · H 4 ðPid i Þ, Pk c Þ [30]. Then, RSU needs to retrieve the corresponding fb s 1 , Sn i g from the blockchain to ensure user legitimacy within pseudo-ID. Finally, RSU checksêðH 3 ðSn i ∥Pid i ∥I D KS t ∥tsÞP + PK b s , Sig b Þ = ?ê ð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 key [30] (3) Then, KS t generates an authentication code Aut = H 1 ðK KS t −S kPid i kID KS t Þ [30] and sends fPid i , ID KS t , Autg to the CAV (S) Upon receipt of fPid i , ID KS t , Autg, the CAV computes the verification code Ver = H 1 ðK KS t −S kPid i kID KS t Þ = ? Aut [30]. If Ver matches Aut, KS t is a legitimate RSU. The shared key between the CAV and RSU is K KS t −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 key K KS t −S is also established for the subsequent communication session.
If the administrator wants to find S info of fM i , σ i , PK s 1 , Sn i , Sig b g, the TA first obtains T w and Pk s from the CAV. The TA takes as input Pk s , y, and T w and tests if H 2 ðêðyA, T w + BÞÞ = V. With keywords fw 1 , w 2 , ⋯, w n g and TEST, the TA obtains ciphertext Ct info of each keyword. Then, the TA sends ciphertext Ct info to the CAV and CAV decryption Ct info as S info ′ . After this, the CAV sends S info ′ to the TA. Then, TA checks ifêðH 3 ðS info ′ ÞP + Y, Sig S info Þ =êðP, PÞ, where Sig S info is obtained from the account b s 1 . If so, the correct S info belongs to account b s 1 .

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 (S 1 ), enterprise vehicles . Each role has different initial credibility. To share trust value with pseudo-ID, KS t generates an authentication code of CAV's trust value OC P as Sig OC P = P/ðH 3 ðPid i kOC P kts 1 Þ + SK KS t Þ. SK KS t is the private key of the RSU (KS t ). Upon receipt of fMessage, Pi d i , ts 1 , Sig OC P , OC P g, other CAV checksêðH 3 ðPid i kOC P kt s 1 ÞP + PK KS t , Sig OC P Þ = ?ê ðP, PÞ, where PK KS t is RSU's (KS t ) public key. A CAV receive M 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 fg 1 , g 2 , ⋯, g M g. g i is one road-relevant event, which contains messages fW 1 i , W 2 i , ⋯, W J i g that send by CAVs in the reference set J. According to [25], the tuple of one specific message (W j k [25]) is defined as The CAV receiver obtains the road-relevant event k from the neighboring CAV j. d j k is the distance between the location of the event k and CAV j; time j k is the message received time of CAV j; OC P is the trust value of CAV j. According to [25], the credibility of specific messages (c j k ) is calculated as: η is the balance coefficient between distance and time; α is a parameter to control the communication boundary; m j k is used to prevent replay attack. Next, t i is the trust value of one road-relevant event g i , which contains fc i 1 , c i 2 , ⋯, c i J g. t i is calculated as (3) using Bayesian Inference [38].
PðeÞ 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 g i . Then, CAV j generates ratings rate j i (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 offset i is controlled by Fð·Þ.
where m is the positive(+1) rating and n is the negative(-1) rating; Compared offset i with a threshold (Thr 1 ), if offset i > = Thr 1 , the offset of one CAV j is offset

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 crosschain 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, Sn i , data), old blockchain account (PK b s 1 , SK b s 1 ), and new blockchain account (PK b s 2 , SK b s 2 ). S computes the cross-chain transaction Asset R = fSigðSn i+1 kts kOC p Þ, Sn i+1 , ts, PK b s 1 ⟶ PK b s 2 , OC p , swapg. The signature SigðSn i+1 ktskOC p Þ = P/ðH 3 ðSn i+1 ktskOC p Þ + SK b s 1 Þ. After the ACSMS process, if searcher wants to find past information, then searcher uses index Si and PK b s 1 to find past signature (Sig), which can check data integrity and authenticate the user. The cross-chain model is illustrated in Figure 5.
The atomic swaps problem in VANETs is as follows. Assume a CAV has an account (PK b s 1 , PR b s 1 ) and holds an asset Z = ðAsset S , OC p Þ in blockchain A. If CAV accesses blockchain B domain, the CAV creates a new blockchain account (PK b s 2 , PR b s 2 ) 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.

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 Ct s . Ct s is encrypted with ðSK s , PK s , PK c Þ, any adversary is infeasible to compute SK s due to the hardness assumption of bilinear Diffie-Hellman problem [43]. Without SK s , the TA can not decryption Ct s (ii) Conditional identity privacy. Many ciphertexts are stored in the server. It is difficult for any adversary to find specific ciphertext without trapdoor T w . However, the ciphertexts have identity privacy during storage; any searcher can use trapdoor T w to find the ciphertext. The searcher has no right to download ciphertext without the signature of blockchain account b s 1 . Therefore, blockchain-based PEKS can resist the keyword guessing attacks (KGA).  (i) Conditional identity privacy. CAVs broadcast message fMessage, Pid i , ts 1 , Sig OC P , OC P g without blockchain account information; the Pid i 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 b s 1 through the BKM, and the TA can find relevant CAV information S info by the blockchain-based PEKS (ii) Prevention of replay attack. By time j k and m j k , if the messages are send by the same CAVs at different times, the credibility of specific messages c j k 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 crosschain 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].

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 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.

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 OC P . However, our BTM scheme only affects the initial OC P , 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].

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 |G 1 | = | G 2 | = 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/ðH 1 ðCt s Þ + xÞ instead of Sig = P/ðH 3 ðCt s Þ + xÞ. Figure 6 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.
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. 9 Wireless Communications and Mobile Computing 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 S info 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.

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, and Z = ðAsset R , OC p Þ is calculated by CAVs. Furthermore, there are average packet latency and blockchain   11 Wireless Communications and Mobile Computing transaction time in the blockchain-based VANET application [22]. As Figure 8 shows, the delay of atomic crosschain swap changes with the number of CAVs per unit time. [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.

Engineering Applications. On Ethereum
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 Web-Socket). 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 Figure 9, the application of ACSMS saves ðSig, Sn i Þ 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 fb s 1 , Sn i g from the blockchain to ensure user legitimacy within pseudo-ID (5) With metamask and web3 command web3.eth.get-Balance (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 value OC P , where OC P 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

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 blockchainbased 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.

Data Availability
The data are available at https://github.com/tanchenkai/ Paper.