Internet of vehicles master-slave multi-chain architecture method based on block chain

Abstract

The invention provides an Internet of Vehicles master-slave multi-chain architecture method based on a block chain. The method comprises five stages of system initialization, vehicle registration, data preprocessing, slave chain consensus and global synchronization. The risk of single-point failure and privacy disclosure due to the fact that the traditional Internet of Vehicles depends on a third-party trust mechanism to carry out data transmission is considered. Therefore, according to the method, the distributed technology of the block chain is adopted, the PBFT consensus algorithm is optimized by fusing the reputation mechanism and the utility guidance strategy, and the corresponding smart contract is deployed on the node of the block chain, so that the data transmission efficiency is remarkably improved, and the data tampering and stealing behaviors of hackers can be effectively resisted. Meanwhile, distributed storage of a large amount of data is achieved in combination with the IPFS storage technology, and the storage pressure of the server is relieved. Besides, a hybrid encryption mechanism combining a symmetric key and an asymmetric key is adopted, so that vehicle coordination and interaction among different cities are guaranteed, and consistency, integrity and security of data transmission are ensured.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of Internet of Vehicles, and proposes a master-slave multi-chain architecture method of Internet of Vehicles based on block chain. BACKGROUND

[0002] Internet of Vehicles (IoV) is a prominent application of Internet of Things technology in the automotive industry, which supports high-speed mobile broadband wireless networks for driving safety, information services and other services. In IoV, equipped with On Board Units (OBU), Road Side Unit (RSU), Trusted Application (TA) and Audit Department (AD), etc., each entity cooperates with each other, which is an important part of intelligent transportation system. However, in the process of vehicle users participating in data sharing and information exchange, it usually depends on centralized third-party trust institutions, which is easy to be attacked by malicious tampering, resulting in invalid data due to the inability of the receiver to accurately verify, at the same time, once the third-party trust institution is attacked, it is easy to cause single point failure, which threatens the stability and security of the whole system.

[0003] Using block chain technology can well solve these problems. However, considering that vehicles in different cities interact with each other, the transmission of a large amount of information leads to low consensus efficiency, in addition, the resource overhead of identity certificate storage and management is large. Therefore, some scholars propose that using block chain and Inter Planetary File system (IPFS) can safely and effectively store vehicle data to reduce the pressure of the central server. However, in the existing IoV scene, there is still an imbalance between security and efficiency.

[0004] In view of the above problems, the application proposes a master-slave multi-chain architecture method of Internet of Vehicles based on block chain. In the traditional IoV architecture, the block chain is layered to construct a master-slave multi-chain block chain structure, and the corresponding smart contract is deployed on the node of the block chain, so as to build a safe and efficient IoV network architecture. SUMMARY

[0005] The application aims to provide a master-slave multi-chain architecture method of Internet of Vehicles based on block chain, comprising the following steps:

[0006] 1. System initialization phase. The blockchain-based IoV master-slave multi-chain architecture is built, the chain nodes of the chain are composed of RSU nodes, the chain nodes of the master chain are composed of TA nodes, and at the same time, the corresponding smart contract is deployed on the node of the blockchain to improve the data transmission rate of the vehicle. In order to overcome the problem of large storage capacity of each node in the blockchain, IPFS is used to store a large amount of data. The audit department (AD) as a node with special permissions, real-time monitoring of the smart contract, and compliance check of the IPFS stored data. The TA generates the corresponding unique identity ID and system parameters according to the MAC address of each entity, and each entity generates the corresponding public and private key pair according to the system parameters, the private key is saved locally, and the public key is public.

[0007] 2. Vehicle registration phase. The vehicle needs to register for the first time when entering the Internet of Vehicles system for the first time. The registration information is submitted to the TA through the RSU to initiate a registration request, the TA verifies the information of the vehicle, if the verification fails, the registration is terminated, and if the verification succeeds, an identity certificate is generated for the vehicle.

[0008] 3. Data preprocessing phase. The registered vehicle communicates with the vehicles in the same city, and needs to upload its identity certificate through the RSU to trigger the smart contract. In order to ensure the security of the identity certificate, the certificate is hashed during uploading. Since the storage resources of the RSU are limited, the RSU stores the certificate in the IPFS, thereby obtaining the corresponding storage address CID, and only stores the certificate hash and CID on the RSU.

[0009] 4. Slave chain consensus phase. When the vehicles in the same city communicate, it is necessary to ensure that the distributed ledger maintained by all RSU nodes in the city is consistent on the corresponding slave chain SC. In order to improve the transmission efficiency of data, the reputation mechanism and the utility guide strategy are combined, the grouping is used to reduce the number of consensus nodes, and the master node is selected by using the verifiable random function (VRF) to improve the traditional PBFT algorithm.

[0010] 5. Global synchronization phase. When vehicles in different cities communicate, the vehicle information needs to be uploaded to the master chain MC through the slave chain SC to trigger the smart contract. In order to enhance the security of the system, a hybrid encryption mechanism is adopted: first, the master node uses a randomly generated symmetric key to encrypt the data to be synchronized, and uses the public key of the MC to encrypt the symmetric key, and at the same time, the data is hashed to obtain the hash value; second, the smart contract on the SC performs chain-level signature on the hash value of the data; finally, all information is packaged and synchronized to the MC to ensure the consistency and integrity of data transmission.

[0011] The present application has the following advantages:

[0012] 1. The application adopts blockchain technology to build a master-slave multi-chain Internet of Vehicles architecture, realizing hierarchical management and isolation of data. The slave chain processes real-time authentication requests of vehicles within the city, and the master chain processes vehicle coordination and interaction between different cities, while combining smart contracts and IPFS distributed storage to effectively prevent single point failure and data tampering. The AD monitors and checks the compliance of smart contracts and IPFS stored data in real time, further enhancing the security and credibility of the system.

[0013] 2. The application optimizes the traditional PBFT consensus algorithm, combines reputation mechanism and utility guide strategy, uses grouping to reduce the number of consensus nodes, and uses VRF to randomly select master nodes, thereby effectively improving the efficiency of the PBFT algorithm. In addition, a hybrid encryption mechanism combining symmetric encryption and asymmetric encryption is adopted to comprehensively guarantee the consistency, integrity and security of data transmission between different cities. BRIEF DESCRIPTION OF DRAWINGS

[0014] Figure 1 A step diagram of the blockchain-based Internet of Vehicles master-slave multi-chain of the application;

[0015] Figure 2 A flowchart of the blockchain-based Internet of Vehicles master-slave multi-chain of the application;

[0016] Figure 3 A blockchain-based Internet of Vehicles master-slave multi-chain architecture diagram of the application. DETAILED DESCRIPTION

[0017] The embodiment provides a blockchain-based Internet of Vehicles master-slave multi-chain architecture method, which includes five steps of system initialization stage, vehicle registration stage, data preprocessing stage, slave chain consensus stage and global synchronization stage, as shown in Figure 1 , and the specific flowchart is shown in Figure 2 . The following will introduce the five steps in detail:

[0018] Step 1: System initialization stage:

[0019] Considering that the traditional IoV network architecture usually relies on centralized third-party authentication agencies for data transmission, there is a risk of single point failure and privacy leakage, and at the same time, vehicles between different cities lack effective isolation mechanism, making a single node more vulnerable to identity attacks, resulting in difficulty in realizing safe communication between vehicles in different cities. Therefore, the application adopts blockchain technology in the traditional IoV architecture to build a master-slave multi-chain IoV network architecture through hierarchical structure, and the network architecture diagram is shown in Figure 3 .

[0020] In the blockchain-based IoV master-slave multi-chain architecture, it is composed of two parts of master chain and slave chain. The chain nodes of the slave chain are composed of RSU nodes, mainly processing real-time authentication requests of vehicles within the city, while the master chain is composed of TA nodes on the basis of the slave chain, mainly processing data interaction between different slave chains. At the same time, the corresponding smart contract is deployed on the node of the blockchain to improve the data transmission rate of the vehicle. In order to overcome the problem of large storage capacity of each node in the blockchain, IPFS is used to store a large amount of data. AD as a node with special permissions, real-time monitoring of the smart contract, and compliance check of the IPFS stored data, effectively improve the security and credibility of the system, so as to realize the data transmission of vehicles between different cities. TA generates a unique identity ID and system parameters according to the MAC address of each entity, and each entity generates a corresponding public-private key pair according to the system parameters, and the private key is saved locally and the public key is public.

[0021] Step two, vehicle registration phase:

[0022] The vehicle needs to register for the first time when entering the Internet of Vehicles system for the first time. The registration information is submitted to TA through RSU to initiate a registration request. TA verifies the information of the vehicle. If the verification fails, the registration is terminated. If the verification is successful, an identity certificate is generated for the vehicle. The step two vehicle registration phase includes:

[0023] 1. The vehicle itself generates a public key PK Vi and a private key SK Vi , first signs the registration information using its SK Vi , including PK Vi , real identity OBU ID , MAC address, registration time OBU T , secondly uses the public key PK TA of TA for encryption, and initiates a registration request to TA after signing through a legal RSU;

[0024] 2. After receiving the registration request of the vehicle, TA verifies the signature of RSU;

[0025] 3. After decrypting the registration information using its private key SK TA , first verify the vehicle signature using the PK Vi of the vehicle, secondly check whether the registration time OBU T is reasonable, and verify whether the OBU ID is consistent with the MAC address of the corresponding vehicle. If the verification fails, the registration is terminated. If the verification is successful, an identity certificate Cert Vi is generated for the vehicle, and its SK TA is signed;

[0026] 4. TA uses the PK of the vehicle Vi To Cert Vi After encryption, it is issued to the vehicle;

[0027] 5. After the vehicle receives the certificate, it uses its SK Vi Decryption, extract Cert Vi From it, verify the signature of TA, confirm the success of registration, store SK Vi And Cert Vi .

[0028] Step three, data preprocessing stage:

[0029] The vehicle that has successfully registered needs to upload its identity certificate through the RSU to trigger the smart contract when communicating with vehicles in the same city. In order to ensure the security of the identity certificate, the certificate is hashed when uploading. Due to the limited storage resources of the RSU, the RSU stores the certificate in the IPFS to obtain the corresponding storage address CID, and only stores the certificate hash and CID on the RSU. The step three data preprocessing stage includes:

[0030] 1. The vehicle sends a request to upload data to the RSU;

[0031] 2. After receiving the request from the vehicle, the RSU generates a random number r and records its validity period, and sends it to the vehicle;

[0032] 3. After receiving the information from the RSU, the vehicle hashes its certificate Cert Vi To get the hash value, and use its private key SK Vi Sign the hash value and random number r, send the certificate Cert Vi , hash value, random number r and its signature to the RSU;

[0033] 4. After receiving the information, the RSU first checks the validity of the random number r, and then verifies the signature of the vehicle. After verification, store the vehicle certificate Cert Vi To IPFS to obtain the corresponding CID;

[0034] 5. The RSU calls the smart contract, generates a transaction with CID and certificate hash value as parameters, signs the transaction with its private key SK RSU , and returns the CID to the vehicle;

[0035] 6. The vehicle receives the CID and saves it by itself.

[0036] Step four, chain consensus stage:

[0037] When vehicles in the same city communicate, it is necessary to ensure that the distributed ledger maintained by all RSU nodes in the city is consistent on their corresponding SC. In order to improve the transmission efficiency of data, the reputation mechanism and utility guide strategy are combined, the number of consensus nodes is reduced by using grouping, and the master node is randomly selected by using VRF to improve the traditional PBFT algorithm. The fourth step from the chain consensus stage includes:

[0038] 1. Calculate the reputation value of each node in the SC according to the number of times it successfully participates in consensus;

[0039] 2. According to the reputation value, divide the nodes into consensus group and candidate group, and use VRF to randomly select the master node in the consensus group;

[0040] 3. RSU initiates a transaction request to the master node as a client;

[0041] 4. After the master node receives the request of RSU, it enters the pre-preparation stage, in which the master node packages the collected transactions into a candidate block, and sends it to all nodes in the chain through broadcast. The candidate block includes the storage address CID of the vehicle certificate, the certificate hash value and the signature of the master node;

[0042] 5. After the consensus node receives the candidate block, it verifies the signature of the master node using the public key of the master node. After verification, it enters the preparation stage, in which each consensus node broadcasts the preparation message, and receives and verifies the preparation messages broadcast by other consensus nodes.

[0043] 6. When the consensus node receives more than 2 / 3 of the valid preparation messages, it enters the submission stage, in which each consensus node broadcasts the submission information, and receives and verifies the submission messages broadcast by other consensus nodes.

[0044] 7. When the consensus node receives more than 2 / 3 of the valid submission messages, it considers that the candidate block has reached consensus and formally joins the SC. The master node broadcasts the confirmation result to all nodes. After the candidate node receives the consensus confirmation message, it updates its own ledger. The system will update the reputation value of each node according to its performance in this consensus.

[0045] Step five, global synchronization stage:

[0046] When vehicles in different cities communicate, vehicle information needs to be uploaded to the MC through the SC triggered smart contract. In order to enhance the security of the system, a hybrid encryption mechanism is adopted: first, the master node encrypts the data to be synchronized using a randomly generated symmetric key, and encrypts the symmetric key using the public key of the MC, and performs a hash operation on the data to obtain a hash value; second, the smart contract on the SC performs a chain-level signature on the hash value of the data; finally, all information is packaged and synchronized to the MC to ensure the consistency and integrity of data transmission. The step five global synchronization stage comprises:

[0047] 1. The master node obtains the data to be synchronized in the SC and the proof that the data has reached consensus within the slave chain, then generates a random symmetric key K, uses the key to symmetrically encrypt the data to obtain ciphertext, and then uses the public key PK MC of the MC to encrypt the symmetric key K to obtain ASK, and performs a hash operation on the original data to generate a hash value, and finally submits the hash value and the slave chain internal consensus proof to the smart contract on the SC for chain-level signature;

[0048] 2. After the smart contract receives the information, it first verifies the slave chain internal consensus proof to ensure that the data has reached consensus in the slave chain, and after verification, the contract uses the chain-level private key SK SC of the slave chain to sign the hash value of the data, and returns the generated signature to the master node;

[0049] 3. After the master node receives the signature, it packages the ciphertext, ASK, hash value of the data, signature of the slave chain and slave chain internal consensus proof into a complete data packet, and synchronizes the data packet to the smart contract of the MC;

[0050] 4. After the smart contract of the MC receives the data packet, it first uses its private key SK MC to decrypt ASK to obtain the symmetric key K, and then uses K to decrypt to obtain the original data, and calculates a new hash value to compare with the received hash value to ensure the integrity of the data, and finally uses the chain-level public key PK SC of the slave chain SC to verify the signature, and at the same time verifies the slave chain internal consensus proof, and after all the verifications are passed, the smart contract stores the data to the master chain, otherwise it refuses to receive the data.

[0051] At this point, the master-slave multi-chain architecture is completed.

Claims

1.A blockchain-based master-slave multi-chain architecture method for Internet of Vehicles, characterized in that The method for ensuring the safe communication of vehicles between different cities and ensuring the consistency and integrity of data transmission comprises the following steps: (1) System initialization stage, build a blockchain-based IoV master-slave multi-chain architecture, the chain nodes of the slave chain are composed of RSU nodes, the chain nodes of the master chain are composed of TA nodes, at the same time, deploy the corresponding smart contract on the node of the blockchain to improve the data transmission rate of the vehicle, in order to overcome the problem of large storage capacity of each node in the blockchain, IPFS is used to store a large amount of data, AD is used as a node with special permissions to monitor the smart contract in real time and check the compliance of the IPFS stored data, TA generates a corresponding unique identity ID and system parameters according to the MAC address of each entity, and each entity generates a corresponding public-private key pair according to the system parameters, the private key is saved locally and the public key is public; (2) Vehicle registration stage, the vehicle needs to register for the first time when entering the IoV system, submits the registration information to the TA through the RSU to initiate a registration request, the TA verifies the information of the vehicle, if the verification fails, the registration is terminated, if the verification succeeds, an identity certificate is generated for the vehicle; (3) Data preprocessing stage, the registered vehicle needs to upload its identity certificate through the RSU to trigger the smart contract when communicating with the vehicles in the same city, in order to ensure the security of the identity certificate, the certificate is subjected to a hash operation when uploading, due to the limited storage resources of the RSU, the RSU stores the certificate in the IPFS to obtain the corresponding storage address CID, only the certificate hash and CID are stored on the RSU; (4) Slave chain consensus stage, when the vehicles in the same city communicate, it is necessary to ensure that the distributed ledger maintained by all RSU nodes in the city is consistent on the corresponding slave chain SC, in order to improve the transmission efficiency of data, the reputation mechanism and the utility guide strategy are combined, the number of consensus nodes is reduced by grouping, and the master node is selected by using the verifiable random function VRF to improve the traditional PBFT algorithm; (5) Global synchronization stage, when the vehicles in different cities communicate, the vehicle information needs to be uploaded to the master chain MC through the slave chain SC to trigger the smart contract, in order to enhance the security of the system, a hybrid encryption mechanism is adopted: first, the master node uses a randomly generated symmetric key to encrypt the data to be synchronized, and uses the public key of the MC to encrypt the symmetric key, and then performs a hash operation on the data to obtain a hash value, second, the smart contract on the SC performs a chain-level signature on the hash value of the data, and finally, all information is packaged and synchronized to the MC to ensure the consistency and integrity of data transmission. 2.The blockchain-based master-slave multi-chain architecture method for Internet of Vehicles according to claim 1, characterized in that, In step (1), the TA generates a unique identity ID for each entity according to its MAC address, and each entity generates its own public-private key pair according to the system parameters generated by the TA. The AD monitors and checks the compliance of the smart contract and the data stored in the IPFS. 3.The blockchain-based V2X master-slave multi-chain architecture method of claim 1, wherein, Step (2) Vehicle registration phase, TA verifies the vehicle registration information including: verifying the validity of the registration time and verifying the real identity of the vehicle OBU ID Consistency with the MAC address. 4.The blockchain-based master-slave multi-chain architecture method for Internet of Vehicles according to claim 1, characterized in that, In step (3), the RSU stores the vehicle certificate in the IPFS to obtain the corresponding CID, and calls the smart contract to record the CID and the hash value. 5.The blockchain-based V2X master-slave multi-chain architecture method of claim 1, wherein, Step (4) from the chain consensus phase, the reputation value is calculated according to the number of times the node successfully participates in the consensus, and the node is divided into a consensus group and a candidate group based on the reputation value, and the master node is selected from the consensus group using VRF. 6.The blockchain-based V2X master-slave multi-chain architecture method of claim 1, wherein, Step (5) Global synchronization phase, a hybrid encryption mechanism combining symmetric encryption and asymmetric encryption is adopted to ensure the secure communication of vehicles between different cities.

Images