Key default security information exchange method, system and device based on physical layer network coding and block chain in internet of vehicles and medium

Abstract

The application discloses a key default security information exchange method, system, device and medium based on physical layer network coding and block chain in Internet of Vehicles, and the method comprises the following steps: constructing a block chain network; registering an on-board unit (OBU); initiating a data exchange request; authenticating the OBU; and exchanging data. The system, device and medium are used for realizing the key default security information exchange method based on physical layer network coding and block chain in Internet of Vehicles. The block chain technology is applied to identity authentication of Internet of Vehicles, and the data exchange between OBUs is carried out by using physical layer network coding, so that the security and confidentiality are high, and the eavesdropping attack and privacy leakage can be prevented at the same time.

Description

Technical Field

[0001] This invention relates to the field of wireless communication security technology in the Internet of Vehicles (IoV), specifically to a method, system, device, and medium for exchanging secure key default information based on physical layer network coding and blockchain in the IoV. Background Technology

[0002] Security issues related to connected vehicles (IOV) can be categorized into four types: network-level issues, authentication issues, data confidentiality issues, and privacy protection issues. While researchers have conducted extensive research and achieved relevant results on security issues, research on group data exchange within connected vehicles is scarce. Current technologies for group data exchange include blockchain and physical layer security.

[0003] Vehicle-to-everything (V2X) communication is a crucial component of future Intelligent Transportation Systems (ITS). Based on communication between vehicles (V2V) and between vehicles and infrastructure (V2I), V2X can provide convenient services such as lane-change assistance, accident warnings, real-time traffic updates, and parking lot information. Furthermore, multimedia entertainment and commercial services, such as advertising, can also be provided via V2X. Therefore, research on vehicle networks and intelligent transportation systems is becoming increasingly extensive.

[0004] Vehicle-to-everything (V2X) networks, with vehicular ad hoc networks (VANETs) as their core architecture, are characterized by self-formation, self-configuration, and self-management. However, such an architecture lacks a trusted authentication center, and key sharing remains a challenge. Recent security issues in V2X networks can be categorized into four types: network-level issues, authentication issues, data confidentiality issues, and privacy protection issues. Reviewing existing protocols, encryption-based strategies remain the primary method for addressing security problems; however, encryption strategies are difficult to apply securely to data exchange within V2X networks. Among existing group data exchange technologies, blockchain technology and physical layer security technologies are widely used.

[0005] Using blockchain technology for IOV security has been a hot topic in the past two or three years. However, its effectiveness in terms of timeliness is still relatively weak, especially in data exchange applications. Meanwhile, another idea is to use blockchain for authentication. Blockchain-based authentication has been applied to Internet of Things (IoT) networks. In 2018, MTHammi et al. proposed an original decentralized system that uses blockchain for authentication (MTHammi, B. Hammi, P. Bellott, A. Serhrouchni, Bubbles of trust: A decentralized blockchain-based authentication system for iot, Computers & Security 78 (2018) 126–142.). Furthermore, C. Lin et al. also considered applying blockchain to Industry 4.0 in 2018 (C. Lin, D. He, X. Huang, KRChoo, AV Vasilakos, Bsein: A blockchain-based secure mutual authentication with fine-grained access control system 580 for industry 4.0, J. Network and Computer Applications 116 (2018) 42–52.). A patent application entitled "A Blockchain Distributed Data Sharing Method Based on Vehicle Networking," with publication number CN113141600A, provides a blockchain distributed data sharing method based on vehicle networking. This method utilizes the timeliness, effect, and frequency of interaction between vehicle i and node j to obtain the reputation value of node j, increasing the efficiency of screening consensus nodes. Simultaneously, vehicle data sharing records are stored as block data and added to the blockchain to achieve effective verification of data sharing, effectively solving the problem that the consensus efficiency of blockchain nodes in existing technologies cannot meet requirements. Therefore, applying blockchain-based identity verification to the Internet of Vehicles is an inevitable consideration. However, since this patent application only considers blockchain-based data recording and storage, it cannot prevent eavesdropping attacks and privacy leaks during the data exchange process, resulting in poor security and low confidentiality.

[0006] In 2017, L. Zhou et al. proposed a novel secure information exchange scheme for MIMO vehicular ad hoc networks (VANET) using a physical layer approach (L. Zhou, Q. Liu, Y. Wang, H. Li, Secure group information exchange scheme for vehicular ad hoc networks, Personal and Ubiquitous Computing 21(5)(2017)903–910.). In this scheme, a group of on-board units (OBUs) exchange information with the assistance of a roadside unit (RSU). A key signal processing technique, Direction Rotation Alignment, is used to align the information to be exchanged between adjacent OBUs to the same direction, forming a summation signal at the RSU or an external eavesdropper. With this summation signal, the RSU or the eavesdropper cannot recover personal information from the OBUs. Information-theoretic security can be achieved by adjusting the transmission rate of each OBU. The confidentiality and efficiency of the proposed scheme are analyzed. Finally, numerical results are used to validate the theoretical analysis. However, the proposal also does not put forward an IOV data pair protocol based on physical layer security.

[0007] Therefore, existing technologies can only prevent one of eavesdropping attacks and privacy leaks, and cannot prevent eavesdropping attacks and privacy leaks at the same time while ensuring identity authentication and secure data exchange. Summary of the Invention

[0008] In order to overcome the shortcomings of the prior art, the present invention aims to provide a method, system, device and medium for key default security information exchange based on physical layer network coding and blockchain in the Internet of Vehicles. By applying blockchain technology to identity authentication in the Internet of Vehicles and using physical layer network coding for data exchange between on-board units (OBUs), it has the characteristics of high security and confidentiality, and can simultaneously prevent eavesdropping attacks and privacy leaks.

[0009] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0010] A method for exchanging secure key default information based on physical layer network coding and blockchain in the Internet of Vehicles includes the following steps:

[0011] Step 1: Construct a blockchain-based V2I network, which includes on-board units (OBU), roadside units (RSU), and a blockchain network based on a consortium blockchain model.

[0012] Step 2, Register On-Board Unit (OBU): The vehicle sends a registration request to the Roadside Unit (RSU) via the On-Board Unit (OBU) and uploads the registration information to the blockchain network of Step 1;

[0013] Step 3, Initiate a data exchange request: The on-board unit (OBU) registered in Step 2 initiates a data exchange request to the roadside unit (RSU);

[0014] Step 4, Authenticate On-Board Unit (OBU): The Roadside Unit (RSU) authenticates the On-Board Unit (OBU) that initiated the data exchange request in Step 3, and sends a communication permission to the successfully authenticated On-Board Unit (OBU).

[0015] Step 5, Data exchange based on physical layer security: Data exchange between on-board units (OBUs) after successful authentication in Step 4 is completed using physical layer network coding.

[0016] The specific process for registering the On-Board Unit (OBU) in step 2 is as follows:

[0017] Step 2.1, the On-Board Unit (OBU) generates the vehicle's unique identifier V. ID A session key SK and a public key PK used only for authentication;

[0018] Step 2.2, using the vehicle's unique identifier V obtained in Step 2.1 ID The public key is compared with the data source, and the header address of the On-Board Unit (OBU) is generated using a hash function and Base58Check encoding. The header address of the OBU is:

[0019] Address=Base58Check[Hash2||V ID )]

[0020] In the formula, Address represents the block header address of the On-Board Unit (OBU); Hash2 consists of two hash functions included in the proposed protocol, namely Hash1: and Hash2:{0,1} * →{0,1} λ Where λ is a system security parameter; Base58Check is a binary text encoding method used to encode Bitcoin addresses; V ID A unique identifier for a vehicle; || indicates a connection.

[0021] Step 2.3, use the vehicle ID V obtained in Step 2.1. ID The key SK, public key PK, and the block header address of the on-board unit (OBU) obtained in step 2.2 are uploaded to the blockchain network of step 1 through the roadside unit (RSU).

[0022] The specific process of step 2.3 is as follows:

[0023] Step 2.3.1: Send the block header address of the On-Board Unit (OBU) obtained in Step 2.2 to the consortium node of the V2I network blockchain constructed in Step 1. The block header address of the OBU and the address of the consortium node are then compared. C A transaction is generated together, and a timestamp is obtained. The consortium nodes sign the transaction and the timestamp, resulting in the following signature:

[0024] Sig[Hash1(Address C ||Address i ||timestamp)],

[0025] In the formula, Address i This represents the block header address of the On-Board Unit (OBU); Hash1 consists of two hash functions included in the proposed protocol, namely Hash1: and Hash2:{0,1} * →{0,1} λ , where λ is the system's safety parameter; Address C The address of the consortium node is represented by `timestamp`; `||` represents the connection.

[0026] Step 2.3.2, the alliance node will send the address. C The On-Board Unit (OBU) header address (Address), timestamp (timestamp), and signature (Sig[Hash1(Address)) are also included. C ||Address i Extract the [||timestamp)] to the transaction pool;

[0027] Step 2.3.3: The alliance nodes periodically elect a block creator. The block creator packages the data extracted into the transaction pool in step 2.3.2 into a block and broadcasts it to other alliance nodes to reach a consensus and form a new block.

[0028] Step 2.3.4: Other alliance nodes verify the validity of the new block obtained in step 2.3.3, and add the verified new block to the end of the blockchain.

[0029] The specific process for authenticating the On-Board Unit (OBU) in step 4 is as follows:

[0030] Step 4.1, the On-Board Unit (OBU) sends an authentication request and V to the Roadside Unit (RSU). ID ;

[0031] Step 4.2, the roadside unit (RSU) returns a random number N to the on-board unit (OBU).

[0032] Step 4.3: The on-board unit (OBU) signs the random number N using the key SK to obtain the signature Sig. SK ;

[0033] Step 4.4, the on-board unit (OBU) signs the random number N with Sig. SK Send the public key PK to the roadside unit (RSU);

[0034] Step 4.5, the roadside unit RSU will V ID The hash calculation of the public key PK is: Hash2(PK||V) ID The roadside unit (RSU) then calculates the address of the on-board unit (OBU), specifically:

[0035] Address=Base58Check[Hash2(PK||V ID )];

[0036] Step 4.6, the Roadside Unit (RSU) searches for and verifies V on the blockchain. ID Whether it has already been registered in the blockchain and whether the signature has been verified using a PK, specifically:

[0037] Step 4.7: If the verification is successful, the Roadside Unit (RSU) grants the On-Board Unit (OBU) a communication license. If both OBUs are authenticated, a communication pair is formed. If the verification fails, the OBUs are not granted a communication license.

[0038] The specific process of data exchange in step 5 is as follows:

[0039] Step 5.1, assuming the vehicle-mounted unit O A and vehicle-mounted unit O B For the two valid On-Board Units (OBUs) that have passed the certification in step 4, the On-Board Units (OBUs) A and vehicle-mounted unit O B Form a two-way communication pair;

[0040] Step 5.2, vehicle-mounted unit O A and vehicle-mounted unit O B The data d to be exchanged are treated separately. A and d B Perform physical layer network coding to obtain the encoded data c A and c B The specific formula is as follows:

[0041] ci =ε(d i )

[0042] In the formula, c i This represents the encoded data, ε(·) represents the physical layer network coding, and d i This represents the data to be exchanged, where i∈{A,B} represents the on-board unit O. A and vehicle-mounted unit O B ;

[0043] Step 5.3, On-board unit O A and vehicle-mounted unit O B The data c after physical layer network encoding in step 5.2 are processed respectively. A and c B Beamforming is performed to obtain the transmitted signal X. A and X B The specific formula is as follows:

[0044] X i =B i ×c i

[0045] In the formula, X i c represents the transmitted signal after beamforming. i B represents the data encoded at the physical layer. i O i The beamforming vector, i∈{A,B} represents the on-board unit O. A and vehicle-mounted unit O B ;

[0046] Step 5.4, vehicle-mounted unit O A and vehicle-mounted unit O B The transmitted signal X obtained in step 5.3 is respectively... A and X B Send to the Roadside Unit (RSU) via the uplink;

[0047] Step 5.5, the roadside unit (RSU) receives the transmitted signal X from step 5.4 on the uplink. A and X B Superimposed signal Y R Specifically:

[0048] Y R =H A,R X A +H B,R X B +Z R ,

[0049] In the formula, Y R The transmitted signal X received by the roadside unit (RSU) A and XB The superimposed signals, the uplink phase channel in the vehicle unit O A The relationship between the roadside unit R and the roadside unit is represented by H. A,R In the vehicle-mounted unit O B The relationship between the roadside unit R and the roadside unit is represented by H. B,R Assuming the vehicle-mounted unit O A Vehicle-mounted unit O B The number of antennas for the roadside unit R and the roadside unit R are n respectively. A n B and n R H A,R The size is n A ×n R H B,R The size is n B ×n R Z R It is the noise vector at the roadside unit RSU, and it passes through Z. R ~CN(0,I nR Modeling;

[0050] Step 5.6, the roadside unit (RSU) applies the superimposed signal Y obtained in step 5.5. R Perform a parallel-to-serial conversion to obtain the element Y after parallel-to-serial conversion. R (i), and for Y R Decode each element of (i) to obtain data c. A and c B The and code The specific formula is as follows:

[0051]

[0052] In the formula, Representing data c A and c B The sum code; D represents XOR-based channel decoding XOR-CD; Y R (i) indicates the use of Y R The elements obtained after performing a parallel-to-serial conversion;

[0053] Step 5.7, the roadside unit (RSU) applies the sum code obtained in step 5.6. Beamforming is performed to obtain the transmitted signal X. R The specific formula is as follows:

[0054]

[0055] In the formula, X R Representation and code The transmitted signal after beamforming, B R Represents the beamforming vector of the roadside unit (RSU);

[0056] Step 5.8, the roadside unit (RSU) transmits the transmitted signal X obtained in step 5.7 via the downlink. R Broadcast to vehicle unit O A and vehicle-mounted unit O B Vehicle-mounted unit O A and vehicle-mounted unit O B Received signal Y i Y i Specifically:

[0057] Y i =H R,i ·X R +Z j

[0058] In the formula, Y i This indicates the signal received by the on-board unit (OBU) from the downlink, H R,i This represents the downlink phase channel matrix, the roadside unit (RSU), and the on-board unit (O). A The space between them is represented by H. R,A Roadside Unit (RSU) and Vehicle-Mounted Unit (O) B The space between them is represented by H. R,B Z j This represents the noise vector at the on-board unit (OBU), and is expressed through Z... j ~CN(0,I ni Modeling, where i,j∈{A,B} represents the vehicle-mounted unit O. A and vehicle-mounted unit O B ;

[0059] Step 5.9, On-board unit O A and vehicle-mounted unit O B The received signal Y i Perform parallel-to-serial conversion and decoding to obtain the sum code.

[0060] Step 5.10, vehicle-mounted unit O A Received code Then, the data d is recovered using the XOR operation. B Onboard Unit O B Received code Then, the data d is recovered using the XOR operation. A .

[0061] A key default security information exchange system based on physical layer network coding and blockchain in the Internet of Vehicles includes:

[0062] V2I Network Construction Unit: Constructs a V2I network, which includes an On-Board Unit (OBU), a Roadside Unit (RSU), and a blockchain network based on a consortium blockchain model.

[0063] Registering the On-Board Unit (OBU) module: The vehicle sends a registration request to the Roadside Unit (RSU) through the On-Board Unit (OBU) and uploads the registration information to the blockchain network of the V2I network building unit;

[0064] Initiate data exchange request module: The registered on-board unit (OBU) initiates a data exchange request to the roadside unit (RSU);

[0065] Authentication of On-Board Unit (OBU) Module: The Roadside Unit (RSU) authenticates the On-Board Unit (OBU) that initiates a data exchange request and sends a communication permission to the successfully authenticated On-Board Unit (OBU).

[0066] Data exchange module: Uses physical layer network coding to complete data exchange between on-board units (OBUs) after successful authentication.

[0067] In the Internet of Vehicles (IoV), key default security information exchange devices based on physical layer network coding and blockchain include:

[0068] Memory: Used to store the computer program that implements the key default security information exchange method based on physical layer network coding and blockchain in the Internet of Vehicles;

[0069] Processor: Used to implement the key default security information exchange method based on physical layer network coding and blockchain in the Internet of Vehicles when executing the computer program.

[0070] A computer-readable storage medium:

[0071] The computer-readable storage medium stores a computer program that, when executed by a processor, enables the implementation of the key default security information exchange method based on physical layer network coding and blockchain in the Internet of Vehicles.

[0072] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0073] 1. This invention applies blockchain consortium blockchain technology to the registration and authentication of on-board unit (OBU) information. Compared with existing technologies, consortium blockchain has a highly efficient consensus algorithm, making it more suitable for time-sensitive IoV (Internet of Vehicles) systems.

[0074] 2. This invention utilizes physical layer network coding for data exchange between on-board units (OBUs). Pre-coding and physical layer network coding are performed at each OBU to form a summed codeword at the roadside unit (RSU), thus achieving privacy protection at the RSU. Compared with existing technologies, this invention achieves privacy protection through coding, exhibiting higher privacy characteristics.

[0075] 3. This invention sets artificial noise at the eavesdropper's location on the uplink and downlink of data exchange, and forms a total codeword at the roadside unit (RSU) through coding design. Compared with the prior art, this invention achieves the purpose of preventing eavesdropping by setting artificial noise, and has the characteristics of high privacy.

[0076] In summary, this invention applies blockchain technology to identity authentication in the Internet of Vehicles and utilizes physical layer network coding for data exchange between on-board units (OBUs). Compared with existing technologies, it features high security and confidentiality, and can simultaneously prevent eavesdropping attacks and privacy leaks. Attached Figure Description

[0077] Figure 1 This is a flowchart of the method of the present invention.

[0078] Figure 2 This is a network architecture diagram of the present invention.

[0079] Figure 3 This is a schematic diagram of the blockchain block structure of the present invention.

[0080] Figure 4 This is a flowchart of the On-Board Unit (OBU) certification process for this invention.

[0081] Figure 5 To obtain the signature Sig in step 4.3 of this invention SK The algorithm flowchart.

[0082] Figure 6 To verify the signature in step 4.6 of this invention The algorithm flowchart.

[0083] Figure 7 This is a simulation result diagram of the confidentiality capability of the present invention.

[0084] Figure 8 The simulation results show the bit error rate of this invention. Detailed Implementation

[0085] The technical solution of the present invention will be described in detail below with reference to the accompanying drawings and simulations.

[0086] See Figure 1 and Figure 2 Vehicle-to-everything (V2X) networks typically consist of three different types of nodes: Application Unit (AU), On-Board Unit (OBU), and Roadside Unit (RSU).

[0087] Application Units (AUs) are typically used in vehicles to provide a variety of functional applications for drivers and passengers.

[0088] The On-Board Unit (OBU) provides communication functionality for each vehicle. The communication information consists of basic driving information, including vehicle location, driving direction, speed, traffic conditions, hazard warnings, and other relevant traffic status information. The basic communication protocols for the OBU include IEEE 802.11p and IEEE 1069.3. Both the Application Unit (AU) and the OBU are located within the vehicle. The AU operates at the upper layer, while the OBU operates at the lower layer. This invention focuses on proposing a secure transmission protocol at the physical layer (the lowest layer), therefore it does not separately distinguish between the OBU, AU, or user.

[0089] Roadside Units (RSUs) are communication infrastructure located along roadsides or intersections. RSUs are typically access points, Wi-Fi hotspots, or base stations. RSUs can communicate with On-Board Units (OBUs) via wireless communication links and with Trust Authorities (TAs) or Application Servers (ASs) via wired links. In this invention, due to the consideration of decentralized networks, the proposed protocol does not include a Trust Authority (TA). Furthermore, the proposed protocol incorporates blockchain-based authentication, allowing each RSU to connect to one or more ledgers.

[0090] On-board units (OBUs) and roadside units (RSUs) involve two types of communication models: vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I). For V2V, vehicles communicate directly with each other via wireless communication links. For V2I, vehicles first communicate with the roadside units (RSUs), and the RSUs then communicate with other vehicles.

[0091] Assume a vehicle pairs with an assistant of a roadside unit (RSU) in a vehicle-to-infrastructure (V2I) network to exchange data. The system model is as follows: Figure 2 As shown in the diagram, the model comprises three parts: the physical part includes the onboard unit (OBU) and the roadside unit (RSU), and the virtual part includes the blockchain account.

[0092] In this model, On-Board Unit 1 (OBU 1) and On-Board Unit 2 (OBU 2) securely exchange data with the assistance of a Roadside Unit (RSU). Since the data exchange involves only one RSU, we simply refer to it as the Roadside Unit RSU without assigning a number. The two OBUs only have wireless communication links with the Roadside Unit RSU in the vehicle-to-infrastructure (V2I) network, and they cannot communicate with each other.

[0093] The proposed protocol comprises two steps: 1) blockchain-based authentication; and 2) physical layer (PHY) secure data exchange. In the first step, the two onboard units (OBUs) authenticate each other using blockchain technology. (The last part, "V," appears to be an unrelated fragment and is omitted from the translation.)ID The vehicle ID is considered a blockchain transaction. On-Board Units (OBUs), Roadside Units (RSUs), and blockchain accounts constitute a blockchain network. Two authenticated OBUs form a data exchange pair. In the second step, these two OBUs securely exchange data through the physical layer. One round of data exchange requires two time slots. In the first time slot, the two OBUs send their data to the RSU; this is called the uplink phase or MAC (Multiple Access) phase. In the second time slot, the RSU broadcasts summation data to the two OBUs; this is called the downlink phase or BC phase.

[0094] Specifically:

[0095] Step 1, build a blockchain-based V2I network, such as Figure 2 As shown, the V2I network includes an on-board unit (OBU), a roadside unit (RSU), and a blockchain network based on a consortium blockchain model.

[0096] Step 2, Register On-Board Unit (OBU): The vehicle sends a registration request to the Roadside Unit (RSU) via the On-Board Unit (OBU) and uploads the registration information to the blockchain network of Step 1;

[0097] Step 3, Initiate a data exchange request: The on-board unit (OBU) registered in Step 2 initiates a data exchange request to the roadside unit (RSU);

[0098] Step 4, Authenticate On-Board Unit (OBU): The Roadside Unit (RSU) authenticates the On-Board Unit (OBU) that initiated the data exchange request in Step 3, and sends a communication permission to the successfully authenticated On-Board Unit (OBU).

[0099] Step 5, Data exchange based on physical layer security: Data exchange between on-board units (OBUs) after successful authentication in Step 4 is completed using physical layer network coding.

[0100] See Figure 3 The specific process of registering the on-board unit (OBU) in step 2 is as follows:

[0101] Step 2.1, the On-Board Unit (OBU) generates the vehicle's unique identifier V. ID A session key SK and a public key PK used solely for authentication, wherein the key is randomly selected. SK serves as the key, and kG serves as the associated public key PK.

[0102] Step 2.2, using the vehicle's unique identifier V obtained in Step 2.1 IDThe public key is compared with the data source, and the header address of the On-Board Unit (OBU) is generated using a hash function and Base58Check encoding. The header address of the OBU is:

[0103] Address=Base58Check[Hash2||V ID )]

[0104] In the formula, Address represents the block header address of the On-Board Unit (OBU); Hash2 consists of two hash functions included in the proposed protocol, namely Hash1: and Hash2:{0,1} * →{0,1} λ λ is a system security parameter; Base58Check is a binary text encoding method used to encode Bitcoin addresses; V ID A unique identifier for a vehicle; || indicates a connection.

[0105] Step 2.3, use the vehicle ID V obtained in Step 2.1. ID The key SK, public key PK, and the block header address of the on-board unit (OBU) obtained in step 2.2 are uploaded to the blockchain network of step 1 via the roadside unit (RSU). The specific process is as follows:

[0106] Step 2.3.1: Send the block header address of the On-Board Unit (OBU) obtained in Step 2.2 to the consortium node of the V2I network blockchain constructed in Step 1. The block header address of the OBU and the address of the consortium node are then compared. C A transaction is generated together, and a timestamp is obtained. The consortium nodes sign the transaction and the timestamp, resulting in the following signature:

[0107] Sig[Hash1(Address C ||Address i ||timestamp)],

[0108] In the formula, Address i This represents the block header address of the On-Board Unit (OBU); Hash1 consists of two hash functions included in the proposed protocol, namely Hash1: and Hash2:{0,1} * →{0,1} λ Where λ is the system's safety parameter; Address C The address of the consortium node is represented by `timestamp`; `||` represents the connection.

[0109] Step 2.3.2, the alliance node will send the address. C The On-Board Unit (OBU) header address (Address), timestamp (timestamp), and signature (Sig[Hash1(Address)) are also included. C ||Address i Extract the [||timestamp)] to the transaction pool;

[0110] Step 2.3.3: The consortium nodes periodically elect a block creator. The block creator packages the data extracted from the transaction pool in Step 2.3.2 into a block, and then broadcasts it to other consortium nodes to reach consensus. The block creator sorts the transactions according to their timestamps and calculates the Merkle root of the selected transactions.

[0111] In step 2.3.4, the block creator broadcasts the new block to the other consortium nodes using the PBFT protocol. During the preparation phase, each remaining consortium node verifies the validity of the new block and broadcasts it to the other consortium nodes in the same way. Once the other consortium nodes receive 2f identical blocks, they will broadcast confirmation messages to the other consortium nodes during the preparation phase. If a node receives 2f+1 confirmation messages, that node will append the new block to the end of the blockchain.

[0112] Blockchains are generally categorized into three types: public blockchains, consortium blockchains, and private blockchains. This invention chooses a consortium blockchain as the basic model. Unlike public and private blockchains, transaction verification in a consortium blockchain is performed by a pre-selected set of nodes within the system. In other words, these nodes collectively maintain the ledger, rather than some nodes across the entire network or a single central node. Unlike public blockchains, consortium blockchains use other efficient consensus algorithms instead of expensive Proof-of-Work (PoW), such as Practical Byzantine Fault Tolerance (PBFT) and RAFT. Consortium blockchains can reach consensus faster than public blockchains, making them more suitable for time-sensitive vehicle-to-everything (IoV) systems.

[0113] In the automotive manufacturer protocol proposed in this invention, cloud servers or government-authorized service nodes act as consortium nodes. Each on-board unit (OBU) can apply for registration and authentication with any consortium node. Once a transaction is formed in a consortium node, it will upload this cross-section, and the selected lead node will package this cross-section and fill in the block.

[0114] Figure 3 The image shows the block body, which includes the block header and the block body. The address is derived from the vehicle's ID V. IDi And the public key PK encoded with the Base58Check hash function iGeneration. The key proves ownership of the relative address. The block body consists of a Merkle tree. The integrity of the data in the block body is verified through the Merkle root. The special data structure of the Merkle tree greatly improves the operating efficiency of the blockchain, allowing the block header to store only the Merkle root, without needing to encapsulate the data in the block body.

[0115] See Figure 4 , Figure 5 and Figure 6 The specific process of authenticating the On-Board Unit (OBU) in step 4 is as follows:

[0116] Step 4.1: The On-Board Unit (OBU) sends an authentication request to the Roadside Unit (RSU);

[0117] Step 4.2, the roadside unit (RSU) sends a random number N to the on-board unit (OBU).

[0118] Step 4.3: The on-board unit (OBU) signs the random number N using the key SK to obtain the signature Sig. SK The signature Sig of the random number N at the on-board unit (OBU) is described above. SK like Figure 5 As shown;

[0119] Step 4.4, the on-board unit (OBU) signs the random number N with Sig. SK PK with public key — i.e., {Sig SK ,PK} is sent to the roadside unit RSU;

[0120] Step 4.5, the roadside unit RSU will V ID The hash calculation of the public key PK is: Hash2(PK||V) ID The roadside unit (RSU) then calculates the address of the on-board unit (OBU), specifically:

[0121] Address=Base58Check[Hash2(PK||V ID )];

[0122] Step 4.6, the Roadside Unit (RSU) searches for and verifies V on the blockchain. ID Whether it has already been registered in the blockchain and whether the signature has been verified using a PK, specifically: Signature Sig SK Verification at the roadside unit (RSU) is as follows: Figure 6 As shown;

[0123] Step 4.7: If the verification is successful, the Roadside Unit (RSU) grants the On-Board Unit (OBU) a communication license. If both OBUs are authenticated, a communication pair is formed. If the verification fails, the OBUs are not granted a communication license.

[0124] See Figure 2 After blockchain-based authentication, two legitimate On-Board Units (OBUs) form a communication pair for data exchange, referred to as an On-Board Unit (OBU). A and vehicle-mounted unit O B These two on-board units (OBUs) securely exchange information with the assistance of a roadside unit (RSU), denoted as R. This transmission model is called a bidirectional OBU pair. This invention considers MIMO transmission in the protocol, assuming that the on-board unit OBU... A Vehicle-mounted unit O B The number of antennas for the roadside unit R and the roadside unit R are n respectively. A n B and n R .

[0125] The two time slots are for the on-board unit O. A and vehicle-mounted unit O B The cost of a single round of data exchange. In the first time slot, the onboard unit O... A and vehicle-mounted unit O B Simultaneously, data is sent to the roadside unit R; this is called the uplink phase. The uplink phase channel is in the vehicle-mounted unit O. A The relationship between the roadside unit R and the roadside unit is represented by H. A,R In the vehicle-mounted unit O B The relationship between the roadside unit R and the roadside unit is represented by H. B,R H A,R The size is n A ×n R H B,R The size is n B ×n R .

[0126] Data exchange is divided into the following two stages:

[0127] Multiple access phase: In the first time slot, the onboard unit O A and vehicle-mounted unit O BTheir data is transmitted to the Roadside Unit (RSU). Before transmission, physical layer network coding and beamforming are performed on each On-Board Unit (OBU). For physical layer network coding, XOR-based channel decoding (XOR-CD) is the most efficient method. Although XOR-based channel decoding (XOR-CD) may suffer from capacity gaps between Gaussian upper bounds, the computational complexity advantage makes it well-suited for vehicular inter-vehicle (IoV) communication. Nested trellis coding can be considered for even better channel capacity.

[0128] Decoding and forwarding of Roadside Unit (RSU): Receiving transmitted signal X A and transmitted signal X B Afterwards, the Roadside Unit (RSU) first performs physical layer network coding and then forwards the summed coded data in the next time slot.

[0129] The specific process of data exchange is as follows:

[0130] Step 5.1, assuming the vehicle-mounted unit O A and vehicle-mounted unit O B For the two valid On-Board Units (OBUs) that have passed the certification in step 4, the On-Board Units (OBUs) A and vehicle-mounted unit O B Form a two-way communication pair;

[0131] Step 5.2, vehicle-mounted unit O A and vehicle-mounted unit O B The data d to be exchanged are treated separately. A and d B For physical layer network coding, XOR-based channel decoding (XOR-CD) is the most efficient method. Although XOR-based channel decoding (XOR-CD) may suffer from capacity limitations due to Gaussian upper bounds, its computational advantage makes it very suitable for vehicular networks (IoV). The encoded data c is obtained. A and c B The specific formula is as follows:

[0132] c i =ε(d i )

[0133] In the formula, c i This represents the encoded data, ε(·) represents the physical layer network coding, and d i This represents the data to be exchanged, where i∈{A,B} represents the on-board unit O. A and vehicle-mounted unit O B ;

[0134] Step 5.3, On-board unit O A and vehicle-mounted unit OB The data c after physical layer network encoding in step 5.2 are processed respectively. A and c B Beamforming is performed to obtain the transmitted signal X. A and X B The specific formula is as follows:

[0135] X i =B i ×c i

[0136] In the formula, X i c represents the transmitted signal after beamforming. i B represents the data encoded at the physical layer. i O i The beamforming vector, i∈{A,B} represents the on-board unit O. A and vehicle-mounted unit O B ;

[0137] Step 5.4, vehicle-mounted unit O A and vehicle-mounted unit O B The transmitted signal X obtained in step 5.3 is respectively... A and X B Send to the Roadside Unit (RSU) via the uplink;

[0138] Step 5.5, the roadside unit (RSU) receives the transmitted signal X from step 5.4 on the uplink. A and X B Superimposed signal Y R Specifically:

[0139] Y R =H A,R X A +H B,R X B +Z R ,

[0140] In the formula, Y R The transmitted signal X received by the roadside unit (RSU) A and X B The superimposed signals, the uplink phase channel in the vehicle unit O A The relationship between the roadside unit (RSU) and the roadside unit is represented as H. A,R In the vehicle-mounted unit O B The relationship between the roadside unit (RSU) and the roadside unit is represented as H. B,R Assuming the vehicle-mounted unit O A Vehicle-mounted unit O B The number of antennas for the roadside unit (RSU) and the roadside unit (RSU) are n respectively. A n B and n R HA,R The size is n A ×n R H B,R The size is n B ×n R Z R It is the noise vector at the roadside unit RSU, and it passes through Z. R ~CN(0,I nR Modeling;

[0141] Step 5.6, the roadside unit (RSU) applies the superimposed signal Y obtained in step 5.5. R Perform a parallel-to-serial conversion to obtain the element Y after parallel-to-serial conversion. R (i), and for Y R Decode each element of (i) to obtain data c. A and c B The and code The specific formula is as follows:

[0142]

[0143] In the formula, Representing data c A and c B The sum code; D represents XOR-based channel decoding (XOR-CD); Y R (i) indicates the use of Y R The elements obtained after performing a parallel-to-serial conversion;

[0144] Step 5.7, the roadside unit RSU compares the selenium obtained in step 5.6. Beamforming is performed to obtain the transmitted signal X. R The specific formula is as follows:

[0145]

[0146] In the formula, X R Representation and code The transmitted signal after beamforming, B R Represents the beamforming vector of the roadside unit (RSU);

[0147] Step 5.8, the roadside unit (RSU) transmits the transmitted signal X obtained in step 5.7 via the downlink. R Broadcast to vehicle unit O A and vehicle-mounted unit O B Vehicle-mounted unit O A and vehicle-mounted unit O B Received signal Y i Y i Specifically:

[0148] Y i=H R,i ·X R +Z j

[0149] In the formula, Y i This indicates the signal received by the on-board unit (OBU) from the downlink, H R,i This represents the downlink phase channel matrix, the roadside unit (RSU), and the on-board unit (O). A The space between them is represented by H. R,A Roadside Unit (RSU) and Vehicle-Mounted Unit (O) B The space between them is represented by H. R,B Z j This represents the noise vector at the on-board unit (OBU), and is expressed through Z... j ~CN(0,I ni Modeling, where i,j∈{A,B} represents the vehicle-mounted unit O. A and vehicle-mounted unit O B ;

[0150] Step 5.9, On-board unit O A and vehicle-mounted unit O B The received signal Y i Perform parallel-to-serial conversion and decoding to obtain the sum code.

[0151] Step 5.10, vehicle-mounted unit O A Received code Then, the data d is recovered using the XOR operation. B Onboard Unit O B Received code Then, the data d is recovered using the XOR operation. A Thus, one round of data exchange is complete.

[0152] This invention addresses the security of the protocol from two perspectives. Firstly, the proposed protocol is resistant to eavesdropping; secondly, it protects privacy.

[0153] For resistance to eavesdropping, the main attacks come from external eavesdroppers. This means that the proposed protocol must ensure that the exchanged data cannot be recovered by external eavesdroppers.

[0154] The external eavesdropper was named Eve for analysis. Eve can also eavesdrop on both uplink and downlink channels.

[0155] For uplink channel eavesdropping, Eve's received signal is:

[0156] Y EU =H A,E X A +H B,E XB +Z E

[0157] Among them, H A,E and H B,E It is the vehicle-mounted unit O A Vehicle-mounted unit O B The eavesdropping channel matrix between EVE and EVE.

[0158] For the downlink channel eavesdropping channel, Eve's received signal is:

[0159] Y ED =R R,E X R +Z E

[0160] Where H R,E This is the eavesdropping channel between the roadside unit RSU and Eve. (And Y) EU and Y E，D Together, Eve tries to restore d A and d B .

[0161] For privacy protection, the protocol proposed in this invention must enable two on-board units (OBUs) to exchange data without leaking the data to the roadside units (RSUs).

[0162] A key default security information exchange system based on physical layer network coding and blockchain in the Internet of Vehicles includes:

[0163] V2I Network Construction Unit: Constructs a V2I network, which includes an On-Board Unit (OBU), a Roadside Unit (RSU), and a blockchain network based on a consortium blockchain model.

[0164] Registering the On-Board Unit (OBU) module: The vehicle sends a registration request to the Roadside Unit (RSU) through the On-Board Unit (OBU) and uploads the registration information to the blockchain network of the V2I network building unit;

[0165] Initiate data exchange request module: The registered on-board unit (OBU) initiates a data exchange request to the roadside unit (RSU);

[0166] Authentication of On-Board Unit (OBU) Module: The Roadside Unit (RSU) authenticates the On-Board Unit (OBU) that initiates a data exchange request and sends a communication permission to the successfully authenticated On-Board Unit (OBU).

[0167] Data exchange module: Uses physical layer network coding to complete data exchange between on-board units (OBUs) after successful authentication.

[0168] In the Internet of Vehicles (IoV), key default security information exchange devices based on physical layer network coding and blockchain include:

[0169] Memory: Used to store the computer program that implements the key default security information exchange method based on physical layer network coding and blockchain in the Internet of Vehicles;

[0170] Processor: Used to implement the key default security information exchange method based on physical layer network coding and blockchain in the Internet of Vehicles when executing the computer program.

[0171] A computer-readable storage medium:

[0172] The computer-readable storage medium stores a computer program that, when executed by a processor, enables the implementation of the key default security information exchange method based on physical layer network coding and blockchain in the Internet of Vehicles.

[0173] The application effects of this invention will be described in detail below with reference to simulation.

[0174] This invention evaluates transmission performance analysis by presenting simulation results in a view of confidentiality capabilities and bit error rate (BER) curves.

[0175] In this simulation, the number of antennas for all nodes is set to 2, and more than 10,000 iterations are simulated by generating a new channel matrix for each iteration.

[0176] like Figure 7 As shown in the figure, the horizontal axis represents the signal-to-noise ratio, and the vertical axis represents the security capacity. Channel Capacity represents the security capacity without considering security, Security Capacity Considering Privacy Preserving represents the security capacity considering privacy protection, and Security Capacity Considering Wiretap Resisting represents the security capacity considering eavesdropping prevention. The simulation results show that the security capacity is reduced when considering privacy protection and eavesdropping prevention, which means that the transmission resources have been compromised by security considerations.

[0177] like Figure 8As shown in the figure, the horizontal axis represents the signal-to-noise ratio (SNR), and the vertical axis represents the bit error rate (BER). BER at OBU A represents the BER at OBU node A, BER at OBU B represents the BER at OBU node B, BER at RSU represents the BER at RSU node, and BER at Eve represents the BER at the eavesdropping node. The simulation results show that the BER curves of OBU A and OBU B decrease with increasing SNR, indicating successful transmission at these two nodes. However, regardless of SNR variations, the BER curves of RSU and Eve remain at high levels, especially Eve's BER, which is almost equal to 1 / 2. This means that Eve obtains almost no information about the transmitted data.

[0178] Simulation results demonstrate that the proposed protocol, from the perspectives of confidentiality capacity and bit error rate (BER), achieves both transmission efficiency and information security. Compared to existing IOV security protocols for vehicle-to-everything (V2X) communication, this protocol is the first secure data exchange protocol that does not require a shared key during the entire process from authentication to data exchange.

[0179] In summary, this invention applies blockchain technology to identity authentication in the Internet of Vehicles and utilizes physical layer network coding for data exchange between on-board units (OBUs). It features high confidentiality, low error rate, and can simultaneously prevent eavesdropping attacks and privacy leaks.

Claims

1. A method for secure key default information exchange based on physical layer network coding and blockchain in the Internet of Vehicles, characterized in that, Includes the following steps: Step 1: Construct a blockchain-based V2I network, which includes on-board units (OBU), roadside units (RSU), and a blockchain network based on a consortium blockchain model. Step 2, Register On-Board Unit (OBU): The vehicle sends a registration request to the Roadside Unit (RSU) via the On-Board Unit (OBU) and uploads the registration information to the blockchain network of Step 1; Step 3, Initiate a data exchange request: The on-board unit (OBU) registered in Step 2 initiates a data exchange request to the roadside unit (RSU); Step 4, Authenticate On-Board Unit (OBU): The Roadside Unit (RSU) authenticates the On-Board Unit (OBU) that initiated the data exchange request in Step 3, and sends a communication permission to the successfully authenticated On-Board Unit (OBU). Step 5, Data exchange based on physical layer security: Data exchange between on-board units (OBUs) after successful authentication in Step 4 is completed using physical layer network coding; The specific process for registering the On-Board Unit (OBU) in step 2 is as follows: Step 2.1: The On-Board Unit (OBU) generates a unique identifier for the vehicle. Session keys used only for authentication and public key ; Step 2.2, using the unique vehicle identifier obtained in Step 2.1 and public key The header address of the on-board unit (OBU) is generated using a hash function and Base58Check encoding. The block header address of the on-board unit (OBU) for: In the formula, This indicates the block header address of the On-Board Unit (OBU). These are the two hash functions included in the proposed protocol, namely... and ,in, These are the system's safety parameters; It is a binary text encoding method used to encode Bitcoin addresses; A unique identifier for a vehicle; || indicates a connection. Step 2.3, use the vehicle ID obtained in Step 2.

1. Key and public key and the block header address of the on-board unit (OBU) obtained in step 2.2 Uploaded to the blockchain network in step 1 via the roadside unit (RSU).

2. The method for key default security information exchange based on physical layer network coding and blockchain in the Internet of Vehicles according to claim 1, characterized in that, The specific process of step 2.3 is as follows: Step 2.3.1: Obtain the block header address of the On-Board Unit (OBU) obtained in Step 2.

2. The block header address of the On-Board Unit (OBU) is sent to the consortium nodes of the blockchain network of the V2I network built in step 1. Address of the alliance node Generate a transaction together and obtain a timestamp. Alliance nodes for transactions and timestamps The signature obtained is: , In the formula, This indicates the block header address of the On-Board Unit (OBU). These are the two hash functions included in the proposed protocol, namely... and ,in These are the system's safety parameters; Indicates the address of the alliance node; || represents a timestamp; || represents a link; Step 2.3.2, the alliance node will send the address Header address of the on-board unit (OBU) timestamp timestamp and its signature Extract to the transaction pool; Step 2.3.3: The alliance nodes periodically elect a block creator. The block creator packages the data extracted into the transaction pool in step 2.3.2 into a block and broadcasts it to other alliance nodes to reach a consensus and form a new block. Step 2.3.4: Other alliance nodes verify the validity of the new block obtained in step 2.3.3, and add the verified new block to the end of the blockchain.

3. The method for key default security information exchange based on physical layer network coding and blockchain in the Internet of Vehicles according to claim 1, characterized in that, The specific process for authenticating the On-Board Unit (OBU) in step 4 is as follows: Step 4.1, the On-Board Unit (OBU) sends an authentication request to the Roadside Unit (RSU) and ; Step 4.2: The roadside unit (RSU) returns a random number to the on-board unit (OBU). , N ∈ ; Step 4.3, On-Board Unit (OBU) uses a key For random numbers N Sign the document and obtain a signature. ; Step 4.4, the on-board unit (OBU) generates a random number. N signature and public key Send to the roadside unit (RSU); Step 4.5, the roadside unit (RSU) will and public key The hash is calculated as follows: ; The roadside unit (RSU) then calculates the address of the on-board unit (OBU). Specifically: ； Step 4.6, the Roadside Unit (RSU) searches and verifies on the blockchain. Has it already been registered in the blockchain and used? To verify the signature, specifically: ; Step 4.7: If the verification is successful, the Roadside Unit (RSU) grants the On-Board Unit (OBU) a communication license. If both OBUs are authenticated, a communication pair is formed. If the verification fails, the OBU communication license will not be granted.

4. The method for key default security information exchange based on physical layer network coding and blockchain in the Internet of Vehicles according to claim 1, characterized in that, The specific process of data exchange in step 5 is as follows: Step 5.1, assuming the vehicle-mounted unit and vehicle-mounted unit For the two valid On-Board Units (OBUs) that have passed the certification in step 4, the On-Board Units and vehicle-mounted unit Form a two-way communication pair; Step 5.2, On-board unit and vehicle-mounted unit Treat the exchanged data separately and Perform physical layer network coding to obtain the encoded data. and The specific formula is as follows: In the formula, This represents the encoded data. (·) indicates physical layer network coding. This represents the data to be exchanged, where i∈{A,B} represents the vehicle unit. and vehicle-mounted unit ; Step 5.3, On-board unit and vehicle-mounted unit The data encoded by the physical layer network in step 5.2 are processed separately. and Beamforming is performed to obtain the transmitted signal. and The specific formula is as follows: In the formula, This represents the transmitted signal after beamforming. This represents the data encoded at the physical layer. express The beamforming vector, i∈{A,B} represents the on-board unit. and vehicle-mounted unit ; Step 5.4, Onboard Unit and vehicle-mounted unit The transmitted signals obtained in step 5.3 are respectively and Send to the Roadside Unit (RSU) via the uplink; Step 5.5: The roadside unit (RSU) receives the transmitted signal from step 5.4 on the uplink. and superimposed signals Specifically: , In the formula, The transmitted signal received by the roadside unit (RSU) and The superimposed signals, the uplink phase channel in the vehicle unit The relationship between the roadside unit R and the roadside unit is represented as In the vehicle unit The relationship between the roadside unit R and the roadside unit is represented as Assuming the vehicle-mounted unit Vehicle-mounted unit The number of antennas for the roadside unit R are respectively , and ; The size is × , The size is × ; It is the noise vector at the roadside unit RSU, and through Modeling; Step 5.6, the roadside unit (RSU) superimposes the signal obtained in step 5.

5. Perform a parallel-to-serial conversion to obtain the elements after parallel-to-serial conversion. (i), and for Decode each element of (i) to obtain the data. and The and code The specific formula is as follows: In the formula, Representing data and The sum code; D indicates XOR-based channel decoding XOR-CD; (i) indicates the use of The elements obtained after performing a parallel-to-serial conversion; Step 5.7, the roadside unit (RSU) applies the sum code obtained in step 5.

6. Beamforming is performed to obtain the transmitted signal. The specific formula is as follows: = · In the formula, Representation and code The transmitted signal after beamforming Represents the beamforming vector of the roadside unit (RSU); Step 5.8, the roadside unit (RSU) transmits the signal obtained in step 5.7 via the downlink. Broadcast to vehicle unit and vehicle-mounted unit vehicle-mounted unit and vehicle-mounted unit Received signal , Specifically: = · + In the formula, This indicates the signal received by the on-board unit (OBU) from the downlink. This represents the downlink phase channel matrix, roadside unit (RSU), and vehicle-mounted unit (V2V). The interval is represented as Roadside Unit (RSU) and Vehicle-Mounted Unit The interval is represented as , Represents the noise vector at the on-board unit (OBU), and through Modeling, where i,j∈{A,B} represents the vehicle-mounted unit. and vehicle-mounted unit ; Step 5.9, Onboard Unit and vehicle-mounted unit The received signals respectively Perform parallel-to-serial conversion and decoding to obtain the sum code. ; Step 5.10, Onboard Unit Received code Then, the data is recovered using the XOR operation. ; vehicle-mounted unit Received code Then, the data is recovered using the XOR operation. .

5. A key default security information exchange system based on physical layer network coding and blockchain in the Internet of Vehicles, characterized in that, To implement the method of claim 1, the method comprises: V2I Network Construction Unit: Constructs a V2I network, which includes an On-Board Unit (OBU), a Roadside Unit (RSU), and a blockchain network based on a consortium blockchain model. Registering the On-Board Unit (OBU) module: The vehicle sends a registration request to the Roadside Unit (RSU) through the On-Board Unit (OBU) and uploads the registration information to the blockchain network of the V2I network building unit; Initiate data exchange request module: The registered on-board unit (OBU) initiates a data exchange request to the roadside unit (RSU); Authentication of On-Board Unit (OBU) Module: The Roadside Unit (RSU) authenticates the On-Board Unit (OBU) that initiates a data exchange request and sends a communication permission to the successfully authenticated On-Board Unit (OBU). Data exchange module: Uses physical layer network coding to complete data exchange between on-board units (OBUs) after successful authentication.

6. A key default security information exchange device based on physical layer network coding and blockchain in the Internet of Vehicles, characterized in that, include: Memory: for storing a computer program that implements the key default security information exchange method based on physical layer network coding and blockchain in the Internet of Vehicles according to any one of claims 1-4; Processor: Used to implement the key default security information exchange method based on physical layer network coding and blockchain in the Internet of Vehicles according to any one of claims 1-4 when executing the computer program.

7. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program that, when executed by a processor, enables the implementation of the key default security information exchange method based on physical layer network coding and blockchain in the Internet of Vehicles as described in any one of claims 1-4.

Images