Secure Data Transfer Based on a Multi-Level Blockchain for Internet of Vehicles

Because of the decentralized trait of the blockchain and the Internet of vehicles, both are very suitable for the architecture of the other. This study proposes a multi-level blockchain framework to secure information security on the Internet of vehicles. The main motivation of this study is to propose a new transaction block and ensure the identity of traders and the non-repudiation of transactions through the elliptic curve digital signature algorithm ECDSA. The designed multi-level blockchain architecture distributes the operations within the intra_cluster blockchain and the inter_cluster blockchain to improve the efficiency of the entire block. On the cloud computing platform, we exploit the threshold key management protocol, and the system can recover the system key as long as the threshold partial key is collected. This avoids the occurrence of PKI single-point failure. Thus, the proposed architecture ensures the security of OBU-RSU-BS-VM. The proposed multi-level blockchain framework consists of a block, intra-cluster blockchain and inter-cluster blockchain. The roadside unit RSU is responsible for the communication of vehicles in the vicinity, similar to a cluster head on the Internet of vehicles. This study exploits RSU to manage the block, and the base station is responsible for managing the intra-cluster blockchain named intra_clusterBC, and the cloud server at the back end is responsible for the entire system blockchain named inter_clusterBC. Finally, RSU, base stations and cloud servers cooperatively construct the multi-level blockchain framework and improve the security and the efficiency of the operation of the blockchain. Overall, in order to protect the security of the transaction data of the blockchain, we propose a new transaction block structure and adopt the elliptic curve cryptographic signature ECDSA to ensure that the Merkle tree root value is not changed and also make sure the transaction identity and non-repudiation of transaction data. Finally, this study considers information security in a cloud environment, and therefore we propose a secret-sharing and secure-map-reducing architecture based on the identity confirmation scheme. The proposed scheme with decentralization is very suitable for distributed connected vehicles and can also improve the execution efficiency of the blockchain.


Introduction
In recent years, the Internet of vehicles has become increasingly mature with the rise of electric vehicles and unmanned self-driving vehicles. In addition, the construction of 5G base stations by various telecom companies has become more popular year by year, which has gradually made the cloudification of the Internet of vehicles (IoV) more feasible, and the Internet of vehicles will be a hot topic, and hundreds of companies must compete in the near future.
The cloud Internet of vehicles can reach vehicles and neighboring equipment to exchange messages with both parties and deliver a large amount of sensing messages to the back-end cloud service platform for big data analysis and computing, generating valuable information. The composition of the Internet of vehicles includes vehicles-tovehicles communication (vehicles-to-vehicles, V2V), vehicles-to-pedestrian (vehicles-topedestrian, V2P), vehicles-to-roadside device (vehicles-to-roadside, V2R), vehicles-to-group tion 4. Finally, conclusions and subsequent work are explained in Section 5.

Related Work
The blockchain is a peer-to-peer distributed database. In contrast to traditional databases, the data are reposited in a primary location, while the blockchain spreads these data across many secondary locations, which are referred to as nodes. In addition, the blockchain has several characteristics: 1. Decentralization 2. Anonymous 3. Prevent tampering 4. Data consistency 5. Information transparency [3,4]. A blockchain is made up of many combined blocks, and then those blocks are tensed together into a blockchain. Additionally, every block consists of two kinds of information, namely the block header and the block body. Figure 1a demonstrates the structure of the complete block; the types of data below are block headers [5,6].
(1) Pervious block hash: The prev_hash value is the hash calculated from the block header of the preceding block. We consider the Merkle tree to be an arborescent structure. Every non-leaf node has a hash value. This study exploits this tree architecture to obtain the hash value of the data, and the timestamp indicates when the block was generated and makes sure that every block is sequentially linked. Moreover, the root of the Merkle tree is the aforementioned root node. The child nodes below it are all the transaction events that occur. The block body is the same as all the information about the transaction. Additionally, the transaction is the message of the generated block body, including the creation time, data and the size of the record, received transaction number, the hash value of the transaction of the Merkle tree node, the digital signature of the transaction, the transaction identification address, and the transaction record's index number, which is conducive to querying the address of the transaction. Each transaction is linked to a hash value to form a node in the Merkle  (1) Pervious block hash: The prev_hash value is the hash calculated from the block header of the preceding block. We consider the Merkle tree to be an arborescent structure. Every non-leaf node has a hash value. This study exploits this tree architecture to obtain the hash value of the data, and the timestamp indicates when the block was generated and makes sure that every block is sequentially linked. Moreover, the root of the Merkle tree is the aforementioned root node. The child nodes below it are all the transaction events that occur. The block body is the same as all the information about the transaction. Additionally, the transaction is the message of the generated block body, including the creation time, data and the size of the record, received transaction number, the hash value of the transaction of the Merkle tree node, the digital signature of the transaction, the transaction identification address, and the transaction record's index number, which is conducive to querying the address of the transaction. Each transaction is linked to a hash value to form a node in the Merkle tree to make sure that the transaction cannot be copied or tampered with. In addition, the blockchain has the following characteristics. (1) Genesis block: It is located in the first block, and the value of the field prev_hash in this block is null. Once a blockchain is generated, it starts by creating a genesis block. Other blocks make use of the previous block called the prev_hash field within the header to store the hash value of the preceding block header and obtain an entire blockchain.
(2) The blockchain is not able to be altered: As a result of changing the transaction records, the value of the Merkle tree root in the block header will be altered, causing the prev_hash field values of each block header, which are concatenated by the entire blockchain, to change synchronously because the integrity of the blockchain is broken. As a result, the prev_hash field values of the previous block that led to the next block must be adjusted in the same way; therefore, if someone wants to modify the transaction history of the block, they must modify all of the following blocks, which is almost impossible to perform.
Looking around in recent years, the majority of the proposed methods have focused on the security of the IoVs but have lacked the integration of back-end cloud service platforms. Many of the proposed methods concentrate on how to deal with secure transmission in terms of the IoVs. After surveying a variety of research papers and discussions, this study summarizes the information security mechanism of the IoVs proposed at this stage in several directions: (1) The blockchain in business transactions and management model; (2) interchain and intrachain architectures; (3) the integration of the blockchain in various network layers; (4) a privacy-preserving authentication blockchain for vehicle ad hoc networks; (5) the consortium blockchain; (6) the batch authentication protocol of the blockchain-based IoT; (7) an anonymous authentication mechanism in the blockchain; (8) a lightweight authentication based on the blockchain. The detailed descriptions are as follows: (1) In 2019, Jiang et al. [7] divided the application of the blockchain in business transactions and management models into five categories, namely vehicle management blockchain, vehicle manufacturing blockchain, user privacy blockchain, vehicle insurance purchase blockchain and the common data blockchain. Shrestha et al. [8] proposed that a regional blockchain can achieve an attack success rate of 51% by controlling several control parameters, such as the number of vehicles, malicious vehicles, messaging and time and puzzle calculations under the premise of ensuring stability. (2) In 2019, Ma et al. [9] proposed a privacy-secure and decentralized vehicle network architecture. In the architecture, RSUs play the role of the main blockchain storage node. In addition, the cloud computing node is in charge of storing and backing up the data of the blockchain. Moreover, this architecture consists of two distinct sub-blockchains, called inter-blockchain and intra-blockchain. Interchain is in charge of communicating information between RSUs, vehicles and infrastructure. The intrachain supports sensors that allow drivers to communicate with passengers in the car. (3) In 2020, Dai et al. and Lu et al. [10,11], based on a ledger structure, set up a private blockchain to store transactions on a secure communication network with crowdsourcing tasks. Overcoming the traditional crowdsourcing single-point error problem, Liu et al. [12] incorporated blockchain mechanisms at the data layer, network layer, application layer, AI layer and business layer. Among them, the network layer contains the peer-to-peer network sublayer and the collaborative network module of the blockchain. Moreover, the AI layer consists of the consensus sublayer of the blockchain, the analysis services and vehicle-oriented computing, including the block consensus protocol executed at this layer. (4) Lu et al. [13] offered a blockchain-based VANETs (vehicular ad hoc networks) privacy protection authentication protocol in 2019 called the BPPA protocol. The authors developed a privacy-preserving authentication blockchain for VANETs. The proposed BPPA scheme uses a blockchain to remain immutable and store all credentials and transactions to achieve transparency and verifiability of TAs. In addition, this research provides a mechanism capable of distributed authentication but does not need a revocation list. To achieve indirect privacy, the study authorizes vehicles to deploy credentials that are encrypted and retained in the blockchain. If there is an inconsistency, it can be disclosed through a link. (5) In 2022, Cui et al. [14] designed an effective data-sharing method between vehicles named the consortium blockchain. In traditional vehicle systems, data sharing takes place between the vehicle and roadside equipment. However, the authors used a distributed technology consortium to enable the sharing of traceable information between anonymous vehicles. Furthermore, the combination of 5G and blockchain makes it possible to share data with no RSUs. (6) In 2021, Bagga and other scholars [15] proposed a batch authentication protocol for blockchain-based IoT. There are two types of authentication: (1) vehicle-to-vehicle authentication. In a cluster, this mode allows the authentication of a vehicle with adjacent vehicles. (2) Batch authentication enables the same group of vehicles to authenticate via their RSUs. Ultimately, cluster vehicles and RSUs can collaborate to establish a group key. (7) In 2021, Maria et al. [16] proposed an anonymous authentication mechanism, which can be applied to the security of the vehicular ad hoc networks during the switching process between the vehicles and the roadside device RSU that consumes fewer computing resources at reduced costs. (8) In 2022. Zheng et al. [17] offered a lightweight blockchain-based authentication and an IoT key agreement to improve the effectiveness of the authentication using a multi-TA model. The authors used the blockchain to save the vehicle's authentication information and cross-region authentication to protect the user's private information. At the same time, the proposed method adopts lightweight computing to shorten the certification time of the vehicles and complete the whole certification procedure.
In summary, most research has focused on connected car networks [18,19], wherein the vehicles' collected data are finally delivered to the back-end cloud service platform for big data analysis and processing so as to acquire valuable information. Consequently, the aforementioned research lacks a discussion of the security transmission mechanisms of IoVs combined with back-end cloud computing information. In view of this, we designed an information security mechanism based on blockchain combined with front-end vehicle terminal equipment and a back-end cloud service platform.

The Transaction Block and the ECDSA Digital Signature for IoVs
Due to the huge number of vehicles in the IoVs and the rapidly changing topology, we proposed a customized cloud IoV transaction block and a digital signature for the onboard transaction block through the ECDSA scheme, which can ensure the integrity and non-repudiation of transaction data, thus protecting the transmission security of vehicle transaction information. The proposed transaction block's internal structure contains the following information, as shown in Figure 1b In addition, this study considers the integrity and non-repudiation of the transaction data; we exploit the ECDSA to achieve the aforementioned functions. ECDSA signature procedures When the vehicles need to transmit data, the transaction block must be digitally signed by the ECDSA to assure the integrity and non-repudiation of the transaction data [20,21]. Here, we introduce the elliptic curve cryptosystem into the OBU and RSU, and the detailed signature process is described below, as shown in Figure 2. The architecture based on a multi-level security management The IoVs integrates the topology logic of onboard, roadside devices and cloud-side servers. Since the Internet of vehicles changes rapidly, here we consider the information security efficiency of the IoVs. Different from the traditional blockchain framework, the designed multi-level blockchain architecture is divided into three layers as an edge computing architecture. Each layer is in charge of its own tasks and performs the operation of the blockchain. Thus, the proposed architecture can handle the latency issues of a traditional block. In this system, each level of security is similar to a layered delegation of authority, and each level performs its own responsibilities. The designed multi-layered security architecture of the Internet of vehicles blockchain mechanism is shown in Figure 3. This architecture is an intra-blockchain based on the M-Tree dynamic management of each base station to deal with the security issues of all levels of the IoVs [21]. Since the vehicle is located at the bottom of the multi-level security architecture of the Internet of vehicles blockchain system, we lay out the vehicle to the leaf node. Additionally, RSUs manage the transaction block transmitted from the vehicle's OBU. In this study, RSUs are placed on the third level of the security level, the base station (local credential authorization) is placed at the second layer, and the cloud server VMmaster (global credential authorization) corresponds to the upper layer of the security level, which is the top layer and is responsible for cooperating with different base stations to construct an inter-blockchain.
This study takes into account the fact that the OBU devices equipped in vehicles gen-Every vehicle is recorded to apply for the digital signature of OBU .

Registration phase
Initial Phase ( 1 ). First, the registered OBU takes an elliptic curve EGF(p) (l, q) and owns an order d = | E GF(p) l, q)| + 1 and a generator R. Moreover, d indicates the number of points at this curve containing the distant point to infinity.
( 2 ). Afterwards, this vehicle OBU selects a private key S and a point R = (XR, YR) which S is between 1 and d−1 and d is the R order. In the meantime, OBU computes the public key P K = S × R = S × (XR, YR) through the R generator. In this case, this system stands for the public key P K as (l, q, p, d, R, PK).

Signature phase
( 3 ) .The OBU randomly selects an integer number e that is equally between 1 and d−1. After that, it calculates a point P = (XP, YP) = e × R = e × (XR, YR).
( 4 ). Next, OBU uses the transmitted transaction block TD from the point P and a coordinate value ( X, Y) as inputs and calculates f = Hash ( TD) using SHA256. (5). H= X P mod d.
(1 0). If H = XM, the recipient agrees to this signature, or otherwise refuses the incoming signature. Initially phase: Phase 1. First, the registered OBU takes an elliptic curve E GF(p) (l, q) and owns an order d = |E GF(p) l, q)| + 1 and a generator R. Moreover, d indicates the number of points on this curve containing the distant point to infinity. Phase 2. Afterward, this vehicle OBU selects a private key S and a point R = (X R , Y R ); S is between 1 and d − 1, and d is the R order. In the meantime, the OBU computes the public key P K = S × R = S × (X R , Y R ) through the R generator. In this case, this system stands for the public key P K , as (l, q, p, d, R, P K ).
Signature phase: Phase 3. The OBU randomly selects an integer number e that is equally between 1 and d − 1. After that, it calculates a P point = (X P , Y P ) = e × R = e × (X R , Y R ). Phase 4. Next, the OBU uses the delivered transaction block TD coming from the point P and a coordinate value (X, Y) as inputs and calculates f = Hash (TD) using SHA256.
Afterward, the recipient checks if H is equivalent to X M . Phase 10. If H = X M , the recipient agrees to this signature or otherwise refuses the incoming signature.
Secure phase If the vehicles want to deliver data to the cloud service platform, first, the vehicles need to execute the ECDSA digital signature procedure on the transaction block to obtain the digital signature result.
The architecture based on a multi-level security management The IoVs integrates the topology logic of onboard, roadside devices and cloud-side servers. Since the Internet of vehicles changes rapidly, here we consider the information security efficiency of the IoVs. Different from the traditional blockchain framework, the designed multi-level blockchain architecture is divided into three layers as an edge computing architecture. Each layer is in charge of its own tasks and performs the operation of the blockchain. Thus, the proposed architecture can handle the latency issues of a traditional block. In this system, each level of security is similar to a layered delegation of authority, and each level performs its own responsibilities. The designed multi-layered security architecture of the Internet of vehicles blockchain mechanism is shown in Figure 3. This architecture is an intra-blockchain based on the M-Tree dynamic management of each base station to deal with the security issues of all levels of the IoVs [21]. Since the vehicle is located at the bottom of the multi-level security architecture of the Internet of vehicles blockchain system, we lay out the vehicle to the leaf node. Additionally, RSUs manage the transaction block transmitted from the vehicle's OBU. In this study, RSUs are placed on the third level of the security level, the base station (local credential authorization) is placed at the second layer, and the cloud server VMmaster (global credential authorization) corresponds to the upper layer of the security level, which is the top layer and is responsible for cooperating with different base stations to construct an inter-blockchain. The proposed architecture can efficiently enhance the performance of the overall blockchain and reduce the synchronization time of the blockchain. Additionally, we adopt the ECDH key exchange protocol to compute the common conference key between the routers and encrypt/decrypt the transmitted data to ensure the security of the information  This study takes into account the fact that the OBU devices equipped in vehicles generally do not have strong computing capabilities. Before deployment, we verify and register the BSs and RSUs; therefore, if nonregistered BSs and RSUs want to join the operation, this system will turn them down. In this study, RSUs are responsible for the communication transmission of the transaction blocks with surrounding vehicles, and the base stations BSs with more powerful computing functions are responsible for cooperating with different RSUs to construct an intra-blockchain, while the back-end cloud PKI is in charge of combining the intra-blockchains into a complete inter-blockchain for this IoVs system.
The proposed architecture can efficiently enhance the performance of the overall blockchain and reduce the synchronization time of the blockchain. Additionally, we adopt the ECDH key exchange protocol to compute the common conference key between the routers and encrypt/decrypt the transmitted data to ensure the security of the information transmission among the base station, routers and the PKI VM master .
To this end, a multi-level blockchain management protocol is proposed, and the elliptic curve signature cryptosystem is embedded into the vehicles' OBU and roadside devices' RSUs [21]. When the transaction message is transmitted by the vehicles, we adopt the transaction block and sign the transaction block through ECDSA to ensure the non-repudiation of the transaction and ensure the integrity of the transaction data.
Herein, this study assumes that when the moving vehicles pass through the path C 1 ←→ C 2 ←→ C 3 ←→ C 4 and transmit the transaction, the blocks are T D1~TD4 , as shown in the red line of Figure 4. This study employs blockchain algorithms to protect the delivered transaction block. The detailed procedure is described below, and the usage notation in this system is represented in Table 1. Step 4. Repeat step 2 until the system obtains the Markle tree root node, as shown by the black dotted line in Figure 5.

Notations Description Ci
The vehicle C is numbered i. TDx Transaction block data TDx transmitted by the vehicle Cx.

SigCx(TDx)
The vehicles Cx performs an ECDSA digital signature on the transmitted transaction block data TDx. Rx The router R is numbered x.
Perform a SHA256 hash operation on the ECDSA digital signature of the delivered transaction block SigCx(TDx), * representing the value obtained after a new hash operation. VMi The virtual machine VM is numbered i.

IDVMx
The identity ID of the virtual machine VMx. EKK The data are encrypted using the key K. || Data concatenation operations.

MNLix
The vehicle node number x at the ith level of the Merkle tree.

BSx
The base station is numbered x.

MNx
The leaf node of the Merkle tree is numbered x RSUxy The road site equipment is located at level x, and the number is y.  Figure 4. The routing path of the transaction block. Table 1. The usage of notation in this system.

Notations Description
Transaction block data T Dx transmitted by the vehicle C x .
The vehicles C x performs an ECDSA digital signature on the transmitted transaction block data T Dx .

R x
The router R is numbered x.
Perform a SHA256 hash operation on the ECDSA digital signature of the delivered transaction block Sig Cx (T Dx ), * representing the value obtained after a new hash operation. VM i The virtual machine VM is numbered i.

ID VMx
The identity ID of the virtual machine VM x . EK K The data are encrypted using the key K. || Data concatenation operations.

MNLi x
The vehicle node number x at the ith level of the Merkle tree.

BS x
The base station is numbered x.

MN x
The leaf node of the Merkle tree is numbered x RSU xy The road site equipment is located at level x, and the number is y. Block xy The block is located at level x, and the number is y.

VM master
The master VM in map/reduce operation of the cloud. intra_clusterBC x The intra cluster blockchain is numbered x.

SK Rx_Ry
The session key between devices R x and R y .
The signature of [ ] through VM master .

S
The system key S. P The corresponding public key P.

S i
The shared secret Si. P i The corresponding public key Pi.
Phase 1: First, the RSU is responsible for calculating the internal cluster blockchain named intra_clusterBC. Step , as shown in Figure 5. For example, Phase 2: The base station BS connects the blockchains named intra_clusterBC, which are formed by the RSU, and there is a corresponding RSU responsible for the connected vehicles. Since each RSU is in charge of the management of the block within the cluster, this study assigns RSU ix , respectively, where i represents the level, and x represents the number of the RSU and also the intra_clusterBC x .
Additionally, multiple vehicles in each RSU ix transmit their signed transaction block, the block name is Block ix , and the block is managed by RSU ix. Afterward, BS i , where i represents the number of the base station, connects the intra_clusterBC i formed by the RSU ix , as shown in Figures 6 and 7.  Sensors 2023, 23, x FOR PEER REVIEW 10 of 20 Phase 2: The base station BS connects the blockchains named intra_clusterBC, which are formed by the RSU, and there is a corresponding RSU responsible for the connected vehicles. Since each RSU is in charge of the management of the block within the cluster, this study assigns RSUix, respectively, where i represents the level, and x represents the number of the RSU and also the intra_clusterBCx. Additionally, multiple vehicles in each RSUix transmit their signed transaction block, the block name is Blockix, and the block is managed by RSUix. Afterward, BSi, where i represents the number of the base station, connects the intra_clusterBCi formed by the RSUix, as shown in Figures 6 and 7. Phase 3: The cloud service platform PKI VMmaster combines each intra_clusterBCi coming from BSi to form inter_clusterBC, as shown in Figure 6. Finally, the cloud service platform PKI VMmaster must integrate and manage the intracluster blockchain sent back by all the base stations. Since the cloud service platform VMmaster is located in the top layer of the whole system, the intra_clusterBCi is managed by BSi must be concatenated to form the intercluster blockchain named inter_clusterBC of the whole system, as shown in Figure 6.

Information Security Transmission Method Between IoVs And Routers
When the intra_clusterBCx is complete, the base station BSx is responsible for transmitting the intra_clusterBCx to the cloud service platform VMmaster, and the transmission process must pass through the router to protect the intra_clusterBCx information. This study adopts the elliptic curve cryptographic exchange protocol, ECDH, to protect the transmitted data. Here, we assume that the base station BSx and router are secure and certified before deployment. The delivered data are routed through the BS1→R1→R 2→R3→R4→ PKI VMmaster path, as shown by the red line in Figure 4.
Initially, the vehicle digitally signs the transaction block using ECDSA and then performs a hash operation through the RSU to obtain the hash value of the Merkle tree root and the complete block. When each RSU performs similar operations and individually transmits its blocks to the BS, the BS can concatenate the received blocks into an intra_clus-terBC. The router then transfers the intra_clusterBC to the destination, VMmaster. In this study, ECDH key agreement is used on the routing side, and the two parties use the ECDH conference key to cipher and decipher the transmitted data [21]. The ECDH mechanism is similar to the traditional Diffie-Hellman key exchange protocol, where both sides set up a conference key over an unsecured channel [22]. Since asymmetric cryptosystems have a key length of at least 1024 bits, they offer an elevated grade of security. However, ECDH

Block11
Block12  Phase 3: The cloud service platform PKI VM master combines each intra_clusterBC i coming from BS i to form inter_clusterBC, as shown in Figure 6.
Finally, the cloud service platform PKI VM master must integrate and manage the intracluster blockchain sent back by all the base stations. Since the cloud service platform VM master is located in the top layer of the whole system, the intra_clusterBC i is managed by BS i must be concatenated to form the intercluster blockchain named inter_clusterBC of the whole system, as shown in Figure 6.

Information Security Transmission Method between IoVs and Routers
When the intra_clusterBC x is complete, the base station BS x is responsible for transmitting the intra_clusterBC x to the cloud service platform VM master , and the transmission process must pass through the router to protect the intra_clusterBC x information. This study adopts the elliptic curve cryptographic exchange protocol, ECDH, to protect the transmitted data. Here, we assume that the base station BS x and router are secure and certified before deployment. The delivered data are routed through the BS 1 →R 1 →R 2 →R 3 →R 4 →PKI VM master path, as shown by the red line in Figure 4.
Initially, the vehicle digitally signs the transaction block using ECDSA and then performs a hash operation through the RSU to obtain the hash value of the Merkle tree root and the complete block. When each RSU performs similar operations and individually transmits its blocks to the BS, the BS can concatenate the received blocks into an intra_clusterBC. The router then transfers the intra_clusterBC to the destination, VM master . In this study, ECDH key agreement is used on the routing side, and the two parties use the ECDH conference key to cipher and decipher the transmitted data [21]. The ECDH mechanism is similar to the traditional Diffie-Hellman key exchange protocol, where both sides set up a conference key over an unsecured channel [22]. Since asymmetric cryptosystems have a key length of at least 1024 bits, they offer an elevated grade of security. However, ECDH utilizes the key protocol of Diffie-Hellman to implement elliptic curve cryptosystems that require merely a 160-bit key strength and use less computing power to achieve similar security intensity [23,24]. Therefore, it is highly adapted to the Internet of vehicles that are short of computer capabilities. Similarly, in this study, the information security transmission between the router and the cloud service platform can also be protected by ECDH.
Cloud information security transmission mechanism When BS 1 receives the intra_clusterBC 1 , BS 1 and R 1 cooperate to figure out the common conference key SK BS1_R1 using the ECDH key exchange protocol, and then BS 1 and R 1 adopt SK BS1_R1 to encrypt and protect the timestamp, sequence number, routing path, and intra_clusterBC 1 . Then, the encrypted result is delivered to the R 1 router.
When the router R 1 receives the message, it decrypts the accepted encrypted message through the common conference key of SK BS1_R1 and adds its identity ID to the passing path. Then, depending on the routing table, R 1 and the following router R 2 use the ECDH protocol to jointly calculate the conference key of SK R1_R2 , and then R 1 encrypts the entire message and transmits the encryption result to the R 2 router.
In the same way, when the router R 2 receives the message, it decrypts the accepted encrypted message through the common conference key of SK R1_R2 and adds its own ID to the passing path. Then, depending on the routing table, R 2 and the following router R 3 use the ECDH protocol to jointly calculate the conference key of SK R2_R3 , and then R 1 encrypts the entire message and transmits the encryption result to the R 2 router. Therefore, it repeats until the message is delivered to the PKI VM master .
When VM master receives the encrypted message, it immediately uses the SK R4_VMmaster to decrypt the encrypted message to obtain intra_clusterBC 1 , and so on to obtain the cluster blockchain from BS 2~B S N , where there are intra_clusterBC 1~i ntra_clusterBC N , and then they are concatenated together to become a complete inter_clusterBC.
Under special circumstances, such as vehicle emergencies wherein the vehicle needs to transmit data immediately, only RSU 1 is responsible for clustering the internal vehicles to transmit the transaction information in a single block. In order to facilitate the explanation of the block transmitted by this single RSU 1 for explanation, we assume that RSU 1 contains vehicles C 1~C4 . To guarantee security during data transmission, first, BS 1 and R 1 calculate the conference key of SK BS1_R1 between each other via the ECDH key exchange agreement, and subsequently, BS 1 encrypts and protects the routing path, sequence number, timestamp stamp and the Merkle tree root HMAC value in the block, concatenating the original data, and then transmitting the encrypted result to the R 1 router.
When R 1 receives the message, the two parties can decrypt the accepted encrypted message because they have a common conference key of SK BS1_R1 . Then, its own ID is appended to the passing path, and referring to the routing table, R 1 and the following router R 2 , the two parties cooperate via the ECDH key exchange agreement to calculate the conference key of SK R1_R2 , and then R 1 encrypts the entire message[(R 1 , , transmitting the encryption result to the R 2 router. When R 2 obtains the data transmitted by R 1 , both parties decrypt the encrypted data through SK R1_R2 , the common conference key, and then R 2 adds its ID to the passing path. Then, depending on the routing table, R 2 and the following router, R 3 , work together to calculate the conference key of SK R2_R3 using the ECDH key exchange protocol, and then R 2 use SK R2_R3 to encrypt the entire message [(R 2 , R 1 , BS 1 )|SN|TS |[H(H(H(Sig C1 (T D1 ))|H(Sig C2 (T D2 )))|H(H(Sig C3 (T D3 ))|H(Sig C4 (T D4 ))))||(Sig C1 (T D1 )|Sig C2 (T D2 )|Sig C3 (T D3 )|Sig C4 (T D4 ))]], transmitting the encrypted result to the R 3 router.
Similarly, when R 3 obtains the data transmitted by R 2 , both parties calculate the common conference key of SK R2_R3 , decrypt the received encrypted data, and append its own ID to the passing path. Afterward, based on the routing table, R 3 and the following router, R 4 , calculate the common conference key of SK R3_R4 via the ECDH key exchange agreement, and then R 3 uses the SK R3_R4 to cipher the entire message [(R 3 , ], subsequently delivering the enciphered result to the router R 4.
The above steps are repeated, and R 4 and R 5 obtain the transmitted encrypted message; then, SK R3_R4 and SK R4_R5 decrypt the encrypted message through the common conference key and append their own ID to the routing path. Subsequently, R 5 finds the destination of VM master according to the routing path table, and then the two parties use ECDH to jointly calculate the conference key SK R5_VMmaster , and then R 5 uses the SK R5_VMmaster to encrypt the entire message [(R 5 , and send the encrypted result to VM master . Upon receiving the data, PKI VM master deciphers the enciphered data through the SK R5_Vmmaster , confirms the service type required by the TS (type of service) field inside each onboard transaction block, and then transmits the data to the correlative cloud service server to perform the emergency service required by the vehicle. Since the PKI VM master is the master VM of the cloud service platform [21], the VM master subsequently continues to perform mapping/reduction tasks.

The Secure Data Transmission Agreement for Map/Reduce
When the transaction block of the vehicle is transmitted to the cloud platform to perform mapping/reduction operations, it may be attacked by malicious VMs. Therefore, this study considers the certainty and security of the identity of VMs that have joined operations to avoid identity spoofing. When the reduction operation reads the data from the mapper, it must also confirm the integrity of the data and confirm the identity of the mapper so as to avoid malicious modifications of the data and read the data transmitted by the malicious VMs. In summary, this study proposes that the group signature and threshold key protection mechanism perform secure mapping and reduction operations, mainly using the secret sharing method proposed by Shamir and Blakley [25]. This mechanism contains two essential parameters. There is the threshold value, n, and the number of shared keys, m, which are generally expressed as (m, n), and this method has a secret fault tolerance mechanism. First, the system distributes the selected master key into m different sharing keys, and each computer participating in the cloud computing obtains a shared key, and when the number of shared keys obtained is greater than or equal to the n value, the master key can be recovered. However, when the number of shared keys obtained is less than n, the master key cannot be recovered.
In the proposed model, the PKI VM master computer first calculates the system key, S, and its corresponding public key, P, and then divides the system key into m shared secret keys (S 1 , S 2 , . . . , S m ). PKI VM master is responsible for assigning each shared secret key to the m mapper VM i computers.
When the system is destroyed, the newly appointed PKI VM master only needs to collect n shared secret keys to restore the original system key of S. After passing through the threshold to share the secret operation, each mapper VM i in the cloud has the shared key, S i , and its corresponding public key, P i .
In addition, we use {M i , TD sigi } to represent the individual signature of each mapper, VM i , and when the PKI VM master receives each TD sigi and verifies the signatures of m VM i , the signature, M i and TD sigi (i = 1, 2, 3, . . . , m), are combined to form a group signature {M, TD Sig }, which must satisfy TD Sig = TD Sig1 + TD Sig2 + TD Sig3 +...+ TD Sigm mod p, where p is a prime. By using this step, we can confirm that the data are calculated by the correct computer VM i and that the restructured data are correct.
Map operation (1) Initially, when the PKI VM master receives the request from the user, it then decides which mapper VM i can participate in the operation in the future and then transmits the task to VM i . With the purpose of confirming the validity of the PKI VM master identity of the request, the PKI VM master is required to sign the request information sent to the mapper VM i , the identity of the PKI VM master as ID VMmaster and the data to be transmitted as TD Sigi , so the mapper VM i subsequently sends a request to verify the identity of the PKI VM master . Here, we represent the complete data TD = , and divide TD into several segments, according to mapping/reduction operations.
[Request| ID VMmaster , TD Sigi ] VMmaster_sig Once the mapper VM i receives the signature message, it uses the VM master 's public key to verify whether the identity of the requestor VM master is correct and then signs the response message to reply, the mapper VM i 's own identity ID VMi-mapper , and the transmitted message {M i , TD Sigi }. (3) Once the reducer, VM x , accepts an appointed job from the VM master , for the purpose of ensuring that the sender is accurate, the PKI VM master must sign the requested information, the VM master identity ID VMmaster and the delivered data Inf req , and the reducer of VM x will then be able to verify the identity of the VM master .
[Request| [ID VMmaster , Inf req ] ] VMmaster_sig After receiving the delivered data, VM x has to confirm whether the VM master identity named ID VMmaster is correct through the VM master public key and subsequently signs the response reply, the reducer's identity ID VMx-reducer and the response data Inf rep .
[Reply|ID VMx-reducer , Inf rep ] VMx-reducer_Sig (4) Successively, the reducer, VM x , receives the data segments {M i , TD Sigi }~{M n , TD Sigm }, the timestamp, and the sequence number signed by the mappers VM i 's secret-sharing key S i from mappers VM i (i = 1~m). After the reducer, VM x , obtains the public key corresponding to S i , the encrypted data are encrypted, and the signatures {M i , TD Sigi } (i = 1, 2, 3,..., m) of each VM i are merged to become the group signature, {M, TD Sig }, where TD Sig = TD Sig1 + TD Sig2 + TD Sig3 + . . . + TD Sigm mod p. The reducer, VM x , then uses the PKI VM master 's public key to confirm the {M, TD Sig } group signature and then merges the data segments into an integral message. Eventually, the VM x reducer delivers this integral information to the vehicle that sent the request to complete the map/reduce operation with a confirmed identity and secure data transmission.
The proposed mechanism is fast, effective and also fault-tolerant. When the master is damaged, only n mapper's shared secret keys need to be collected to reassemble the system secret key, S. Additionally, the mapper and the reducer protect each other through each other's secret shared keys to secure the transmitted data from being changed during data transmission. The time stamp and the sequence number protect against repeated reply transmissions. Moreover, by verifying the identity of the mapper/reducer and assigning work through the master, malicious computers can also be prevented from impersonating mappers or reducers to perform DoS, denial of service.

The Analysis of Security Additionally, Performance
This section presents an analysis of the security and performance of the proposed scheme. While the data are being transferred, we have to esnure the integrity of the transaction block and discover the modified block. Additionally, we also need to ensure the participant of joining secure map/reduce operations to avoid impersonal attacks. Additionally, this section provides the efficiency analysis of performing a group signature to compare it with the Kerberos scheme. The detailed descriptions are as follows: (1) Merkle tree verification The advantage of Merkle trees is that if a block is collapsed or altered, the root value of the Merkle tree can be gained by recomputing along the path of the destroyed node to the root node of the Merkle tree. In addition, we can also determine the location of the damaged child nodes of the Merkle tree according to the following steps, as shown by the blue line in Figure 5.
Step 2. Similar hash jobs are performed repeatedly, and if MNL1 1 is the same and the node MNL1 2 is different, this study will examine the child nodes, MN 3 and MN 4 , of the node MNL1 2 .
Step 3. Similar hash jobs are repeated, and if MN 3 is equal but MN 4 is not, this study will examine MN 4 and finally realize the accurate collapsed node.
In the process of this comparison manipulation, this mechanism merly consumes the time complexity of comparison O(log 2 M), and M is the number of transaction blocks. In addition, O(M) of creating this Merkle tree is the amount of hash operations computed.
(2) Group signature verification Initially, the PKI VM master announces a public key, Z, to the participating group members to confirm the message {M i , TD Sigi } of the signature. Additionally, this formula for the verification is as follows: If the above verification formula (1) can be derived, it means that the group signature of the message {M i , TD Sigi } is correct because the VM i signature value {M i , TD Sigi } can be satisfied.
The correct verification equation for the signature of the verification group can be derived from the above equation.
(3) Efficiency evaluation In this study, we adopt MediaTek MT7697 CPU with ARM ®® Cortex ®® -M4 with a floating-point computing unit and 1T1R 802.11 b/g/n Wi-Fi as OBUs and RSUs. In addition, this study embeds the blockchain protocol and the ECDSA cryptosystem in OBUs and RSUs to simulate the proposed multi-level blockchain management protocol. Moreover, in order to prove system efficiency and facilitate the evaluation of the time of reconstructing the system key, S, this study exploits a (m, n) threshold scheme and gradually increases the threshold value from 1 to n on the m mapper VMs to rebuild the S system key and evaluate the consuming time. Figure 8a indicates that in the beginning, the system increases stably and needs more time to recover the system key, S, with the increasing threshold values. However, when the system reaches the threshold value, the time consumed becomes smooth, as shown in Figure 8a. Additionally, when we compare our group signature scheme with no security and the Kerberos scheme, Figure 8b depicts that our proposed scheme costs more time than a no-security scheme when we increase the number of the mappers m under the fixed threshold value n. However, it is still better than the Kerberos scheme because the need for Kerberos is an authentication server and a ticket-granting server, thus consuming extra operations in cloud operations.
In addition, the limitations of the proposed method depend on the threshold value of reconstructing the system key. With the increase in the number of vehicles, Figure 8b shows that our proposed threshold signature does not change significantly compared to Kerberos's time consumption growth. This is mainly because the system key can be reconstructed as long as we collect the partial key that reaches the threshold value, unlike Kerberos, which must obtain partial keys from all of the participants in order to reconstruct the system key. Therefore, after reaching the threshold value, our system only needs a fixed time to reconstruct the system key, and thus the communication overhead is not huge. Figure 8b shows a few changes in consuming time after collecting n partial keys to reconstruct the system key under a fixed threshold value of n. our proposed scheme costs more time than a no-security scheme when we increase the number of the mappers m under the fixed threshold value n. However, it is still better than the Kerberos scheme because the need for Kerberos is an authentication server and a ticket-granting server, thus consuming extra operations in cloud operations.
In addition, the limitations of the proposed method depend on the threshold value of reconstructing the system key. With the increase in the number of vehicles, Figure 8b shows that our proposed threshold signature does not change significantly compared to Kerberos's time consumption growth. This is mainly because the system key can be reconstructed as long as we collect the partial key that reaches the threshold value, unlike Kerberos, which must obtain partial keys from all of the participants in order to reconstruct the system key. Therefore, after reaching the threshold value, our system only needs a fixed time to reconstruct the system key, and thus the communication overhead is not huge. Figure 8b shows a few changes in consuming time after collecting n partial keys to reconstruct the system key under a fixed threshold value of n. (4) The threshold cryptosystem with fault tolerance Since this study adopts the threshold-sharing key mechanism, it has a fault-tolerant mechanism and can avoid a single point of error. When the system key of S is damaged or VMmaster collapses. Mapper VMs collect the secret-sharing key, Si, of the surviving mappers to recover the system key, S, through Lagrange interpolation polynomial to figure out S, and then the system key can be regained and avoid the system collapsing. Even if the system faces malicious attacks, only n mappers VMs exit to sign the transmitted data instead of m members, and then the system can verify whether the transmitted data are correct.

(5) Blockchain integrity
Since the prev_hash field of the next block indicates the hash value of the previous block header, the system can use this as a certificate of overall blockchain integrity [26,27]. When an intruder modifies the historical transaction in the previous block number, N − 1, even if only any node value in the Merkle tree is modified, the Merkle root value of the block header will be affected by the linkage, and the prev_hash value of the subsequent block number N will also be invalidated, unless the intruder also changes the prev_hash  4 5 6 7 8 9 10 11 12 13 14 15 16 17 18  (4) The threshold cryptosystem with fault tolerance Since this study adopts the threshold-sharing key mechanism, it has a fault-tolerant mechanism and can avoid a single point of error. When the system key of S is damaged or VM master collapses. Mapper VMs collect the secret-sharing key, S i , of the surviving mappers to recover the system key, S, through Lagrange interpolation polynomial to figure out S, and then the system key can be regained and avoid the system collapsing. Even if the system faces malicious attacks, only n mappers VMs exit to sign the transmitted data instead of m members, and then the system can verify whether the transmitted data are correct.

(5) Blockchain integrity
Since the prev_hash field of the next block indicates the hash value of the previous block header, the system can use this as a certificate of overall blockchain integrity [26,27]. When an intruder modifies the historical transaction in the previous block number, N − 1, even if only any node value in the Merkle tree is modified, the Merkle root value of the block header will be affected by the linkage, and the prev_hash value of the subsequent block number N will also be invalidated, unless the intruder also changes the prev_hash value of each block header in the blockchain, but there are technical difficulties due to the decentralized nature of the blockchain. This study compares our proposed scheme with the related research on scalability, communication cost and a single-point failure. The proposed multi-level blockchain is composed of three levels, which are responsible for blockchain operation. Therefore, when the number of vehicles is increased, the problem of excessive single-point calculation and single-point failure can be avoided. At the same time, it can reduce much of the communication costs between vehicles and make the system more scalable. By contrast, other approaches mostly use the traditional blockchain architecture. They have problems related to expansion difficulty, huge communication costs and the single-point failure of authentication, as described in Table 2.

Conclusions
Since the IoVs operates in a communication environment open to all, personal information is shared within the wireless network. Consequently, the issue of information security in terms of the IoVs will therefore be important [29,30]. The main contribution of this study is to propose a new transaction block and ECDSA digital signature that are able to ensure the non-repudiation of the transaction and assure the integrity of the transaction data. In addition, the designed multi-level blockchain architecture distributes the operations within intra_clusterBC and inter_clusterBC to improve the efficiency of the entire block. Moreover, in order to secure the security of OBU-RSU-BS-VM, this research adopts ECDH key exchange agreement to protect the transmitted information. Eventually, we consider the collected data from vehicles that will be delivered to the back-end cloud service platform to perform the big data computing and analysis and generate value-added information [31,32]. This research has to ensure the VMs identity of joining the map/reduce operations, and therefore we exploit the secret-sharing mechanism to propose the group signature and threshold key protection mechanism to accomplish the secure map and reduce operations. The threshold scheme can recover the system key as long as the threshold partial key is collected. This avoids the occurrence of PKI single-point failure. Overall, the proposed architecture is capable of securing data transmission among IoV devices and cloud service platforms. In this way, this study can ensure the security of the information and obtain a secure IoV.