A key management system for heterogeneous cellular vehicle networks based on blockchain

Abstract

The present invention discloses a heterogeneous cellular vehicle network key management system based on blockchain, which includes an initialization module: TA divides vehicles into small groups, and each RSU manages the public keys of all vehicles within its coverage; a group key generation and issuance module: each RSU is responsible for generating a group key, and uses an asymmetric encryption mechanism to distribute the group key; a vehicle cross-domain module: the source RSU and the destination RSU are responsible for generating new transactions and recording public key changes; a key update module: the update of the RSU public key is completed by writing into the RSU public key blockchain, and the update of the vehicle public key is reported to the RSU to which it belongs through a symmetric encryption mechanism using the group key; a key revocation module: a node that detects malicious behavior generates a malicious behavior report, and when the number of reports reaches a threshold, it is written into the RSU public key blockchain / vehicle public key blockchain. The introduction of blockchain ledger technology avoids single point failures, reduces communication overhead, and provides traceability, non-repudiation and non-tamperability for key management.

Description

Technical Field

[0001] The present invention relates to the technical field of Internet of Vehicles security, and in particular to a heterogeneous cellular Internet of Vehicles key management system based on blockchain. Background Art

[0002] There are two mainstream access technologies for the Internet of Vehicles: DSRC technology based on IEEE 802.11p and C-V2X, a cellular communication technology that is continuously evolving based on long-term evolution technology. Since IEEE 802.11P is based on the non-coordinated scheduling mechanism of CSMA / CA, it is difficult to achieve reliable and efficient transmission performance in high-vehicle density scenarios; in addition, it has problems such as short coverage distance, high infrastructure cost, and difficulty in large-scale deployment. In contrast, thanks to the widely deployed infrastructure of cellular networks, C-V2X has great application prospects. By introducing side link communication and enhancing LTE-D2D technology, cellular networks use PC5 and Uu interfaces to jointly realize multi-scenario communications such as V2V, V2I, V2P, and V2N. In order to support higher-level vehicle applications, combined with the continuous evolution of cellular networks, 5G new air interface technology further enhances the performance of side link communication, complements LTE-V2X, and provides high-reliability and low-latency communication support for various types of vehicle-mounted applications. In addition, the X2 interface in the cellular communication architecture is a bridge for sending signaling and data between connecting base stations. The coexistence of Uu port, PC5 port and X2 interface forms a heterogeneous cellular Internet of Vehicles. Although the advantages of cellular communication technology in the application of Internet of Vehicles communication scenarios have become more and more obvious with the deepening of related research, there are still many technical gaps in its security level.

[0003] First, in addition to relying on the limited surrounding environment perceived by its own sensors, each vehicle's safe driving also requires the help of nearby vehicles to send BSM / CAM for collaborative perception. Therefore, it is very important to organize vehicles and manage vehicle keys so that they can support vehicle security communication. Secondly, in terms of traditional key management, most studies have adopted solutions based on public key infrastructure; this solution relies on centralized third-party CAs to issue and manage keys. This centralized management method is vulnerable to denial of service attacks, blocking attacks, and other attacks, which can cause single point failures. Moreover, this centralized management method requires real-time maintenance of a huge certificate revocation list when the number of vehicles increases dramatically, resulting in large computing delays and high communication overhead. In addition, different car manufacturers and Internet of Vehicles organizations use their own PKI systems, which will cause cross-domain authentication difficulties. Therefore, how to apply the existing cellular communication infrastructure and related interfaces, combined with the needs of Internet of Vehicles security communication, to design a trusted distributed key management method has become an urgent problem to be solved. Summary of the invention

[0004] The purpose of the present invention is to overcome the shortcomings and deficiencies of the prior art, and proposes a heterogeneous cellular vehicle network key management system based on blockchain, which fully utilizes the heterogeneous characteristics of cellular networks, introduces the openness, traceability, non-repudiation and non-tamperability of blockchain, and realizes distributed key management.

[0005] To achieve the above purpose, the technical solution provided by the present invention is: a heterogeneous cellular vehicle network key management system based on blockchain, the X2 interface, Uu interface and PC5 interface of the cellular network support different vehicle network communication modes, forming a heterogeneous cellular vehicle network, and its key management system includes the following modules:

[0006] Initialization module: Before the RSU and the vehicle start communicating, an offline TA, i.e. the trusted center, divides the vehicles into groups and generates and issues public and private key pairs for the RSU and the vehicle in a secure environment. The public keys of the RSU / vehicle are synchronized to all RSUs through forming blocks / transactions, "consensus" and "on-chaining". Each RSU manages the public keys of all vehicles within its coverage area.

[0007] Group key generation and issuance module: Each RSU generates a group key and issues the group key through an asymmetric encryption mechanism using the public key list of all vehicles in the domain stored locally;

[0008] Vehicle cross-domain module: For cross-domain vehicles, the source RSU and the destination RSU are responsible for generating new transactions, recording changes in public keys, and writing them into new blocks by the RSU that reaches the fastest consensus. Once the "chaining" is successful, the source RSU and the destination RSU groups regenerate and issue group keys respectively.

[0009] Key update module: The update of RSU public key is completed by writing into RSU public key blockchain. The update of vehicle public key is encrypted by group key based on symmetric encryption mechanism and reported to the RSU to which it belongs, and written into vehicle public key blockchain. Finally, source RSU and destination RSU group regenerate and issue group keys respectively.

[0010] Key revocation module: Nodes that detect malicious behavior generate reports related to the malicious behavior and place them in the report pool. When the number of reports reaches the threshold, the nodes form a transaction, "consensus" and "chain", and then the source RSU and the destination RSU regenerate and issue the group key respectively.

[0011] Furthermore, the initialization module includes the following submodules:

[0012] RSU initialization module: In a secure environment, an offline TA generates its own public-private key pair and publishes its public key to each RSU; the TA generates a public-private key pair for each group's RSU and issues the public-private key pair to the RSU for local secret storage; then, the TA forms an initial block signed with its own private key for each RSU's public key; the initial block will be sent to all RSU nodes through the X2 interface to verify the signature and "consensus"; the RSU that calculates the hash value that meets the conditions the fastest will send the initial block to other RSUs for verification; once the block's nonce passes the verification, it will be "uploaded to the chain", that is, all RSUs write to the locally maintained blockchain that stores the RSU public key, completing the synchronization of the RSU public key in the entire RSU network;

[0013] Vehicle initialization module: An offline TA divides all vehicles into different groups according to the geographical location of the RSU in a safe environment, generates a public-private key pair for each vehicle, and issues the public-private key pair to the vehicle for secret storage; then, the TA forms an initial transaction for the public key of each vehicle, and all vehicle public key initial transactions form an initial block, which is sent to the entire RSU network through the X2 interface for "consensus" and "chaining", that is, writing to the blockchain that stores the vehicle public key, and completing the synchronization of the vehicle public key status in the entire RSU network; during the synchronization process, the RSU in each group saves the public key of each vehicle under its jurisdiction, forms a vehicle public key list, and manages the vehicle public keys in this group.

[0014] Furthermore, the group key generation and issuance module specifically performs the following operations:

[0015] Each group of RSUs is responsible for generating group keys to support intra-group communication;

[0016] Each group of RSUs uses the public key of each vehicle stored locally to encrypt the generated group key one by one;

[0017] Each group of RSUs uses an asymmetric encryption mechanism to distribute the encrypted group key to each vehicle in the group one by one through the downlink corresponding to the Uu cellular interface;

[0018] Each vehicle decrypts the encrypted group key using its secretly kept private key;

[0019] All vehicles in the group use the group key to perform secure collaborative perception based on a symmetric encryption mechanism through the side link corresponding to the PC5 cellular interface.

[0020] Furthermore, the vehicle cross-domain module specifically performs the following operations:

[0021] The vehicle will periodically send heartbeat messages to the RSU via the uplink using the group key. The source RSU determines whether the vehicle has left the jurisdiction by detecting the vehicle's heartbeat message. If the source RSU does not receive a heartbeat message from a vehicle within an integer multiple of the heartbeat message period, it is considered that the vehicle has left the jurisdiction.

[0022] The source RSU generates an unverified vehicle cross-domain transaction and sends it to the destination RSU through the X2 interface. The transaction contains the public key of the cross-domain vehicle signed by the source RSU private key and encrypted by the destination RSU public key. The scenario considered here is the highway scenario: the RSU deployed on the two-way highway has the characteristic of knowing the public keys of its adjacent RSUs. Therefore, the source RSU can query the public key of the destination RSU from the locally stored RSU public key blockchain without the help of vehicle reporting to perform encryption operations, ensuring that only the destination RSU can decrypt the encrypted vehicle public key.

[0023] After receiving the transaction, the destination RSU will query the public key of the source RSU from all RSU public key blockchains maintained locally to verify the source RSU signature contained in the transaction, and use its own secretly kept private key to decrypt the public key of the cross-domain vehicle encrypted by the source RSU, and then change the transaction from an unverified state to a verified state;

[0024] The destination RSU sends the verified transaction to all other RSU nodes through the X2 interface, indicating that a vehicle has entered a new group across domains;

[0025] All RSUs regularly collect all received and verified transactions to form blocks and reach a “consensus” based on the Proof of Work consensus mechanism;

[0026] The RSU that reaches the fastest consensus will send the above block to all other RSUs for verification. Once the verification is successful, it will be "on-chained", that is, written into the blockchain to reach a consensus on cross-domain vehicle and key movement;

[0027] The source RSU deletes the public key of the departing vehicle from the locally managed vehicle public key list;

[0028] The destination RSU adds the public key information of the new vehicle to the local vehicle public key list;

[0029] The source RSU and the destination RSU groups generate and issue group keys respectively.

[0030] Furthermore, the key update module includes the following submodules:

[0031] RSU key update module: If an RSU updates its public-private key pair, it needs to form a block recording the updated public key and send the block to all RSUs through the X2 interface; all RSUs conduct "consensus" and "chain" according to the proof of work; after "chaining", the RSU will regenerate the group key and issue the group key to all vehicles in the group;

[0032] Vehicle key update module: If the vehicle updates its public-private key pair, it uses the old group key and symmetric encryption mechanism to report its public key to the RSU to which it belongs through the uplink of the Uu interface, and updates the vehicle public key list managed by the RSU; after the report is completed, the RSU of the group to which the vehicle belongs will regenerate the group key and issue it to all vehicles in the group.

[0033] Furthermore, the key revocation module specifically performs the following operations:

[0034] During the communication process of the Internet of Vehicles, the existence of some internal malicious nodes makes the Internet of Vehicles system subject to various attacks. Malicious behavior in the system can be judged by querying the records of the blockchain; if the records of the blockchain show that a certain RSU frequently updates its key, or a certain car repeatedly leaves and joins the area under the jurisdiction of the RSU in a short period of time, it can be determined that the behavior is malicious;

[0035] At this point, the detection party generates a report on the malicious behavior and places it in the report pool;

[0036] When the number of reports about a malicious behavior in the reporting pool exceeds the threshold: for malicious RSUs, a detection party RSU is randomly selected to generate a block of revoked keys, and sent to other RSUs for "consensus" and "chaining"; for malicious vehicles, a detection party vehicle is randomly selected in the group to which it belongs to generate a malicious behavior transaction, which is sent to all RSUs to form a block, "consensus" and "chaining", and finally the public key of the malicious vehicle is deleted from the vehicle public key list locally stored in the RSU to which the malicious vehicle belongs.

[0037] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0038] 1. In order to improve the efficiency of key management, the present invention has achieved a balance between vehicle-based distributed and CA-based centralized key management: vehicles are grouped according to different RSUs for key management. Vehicles within a group communicate with each other through a symmetric encryption mechanism using group keys, and groups are updated across domains through the RSU responsible for managing vehicle keys in each group. By grouping vehicles, cellular network resources are maximized, assisting vehicles in collaborative perception and secure communication.

[0039] 2. The present invention uses blockchain as a distributed ledger, combined with heterogeneous cellular networks, to provide a key management solution with the advantages of openness, traceability, and non-repudiation. Compared with the traditional centralized structure, blockchain technology reaches a consensus on cross-domain vehicle switching between each group of RSU nodes through distributed consensus. Secondly, by storing public keys on the blockchain instead of public key certificates, the computational and communication overhead of reaching consensus between RSUs is reduced. Finally, each block stores the hash value of the parent block in its block header to ensure that the content of the block cannot be easily tampered with without changing the content of all subsequent blocks. To tamper with the block content, the attacker must control more than half of the consensus RSU nodes-this is unrealistic in terms of the scale of the Internet of Vehicles. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 This is a schematic diagram of the system scenario.

[0041] Figure 2 This is a schematic diagram of the relationship between the various modules of this system.

[0042] Figure 3 The present invention is a flowchart of the key generation and issuance of an implementation group.

[0043] Figure 4 The present invention is a flowchart of cross-domain switching key management according to an embodiment. DETAILED DESCRIPTION

[0044] The present invention is further described in detail below in conjunction with embodiments and drawings, but the embodiments of the present invention are not limited thereto.

[0045] This example provides a blockchain-based heterogeneous cellular vehicle network key management system. Figure 1 As shown in Figure 2, the relationship between the modules in the system is as follows: Figure 2 As shown, it includes an initialization module, a group key generation and issuance module, a vehicle cross-domain module, a key update module and a key revocation module. Please see below for a detailed introduction to each functional module.

[0046] The initialization module includes the following submodules:

[0047] RSU initialization module: In a secure environment, an offline TA generates its own public-private key pair and publishes its public key to each RSU; the TA generates a public-private key pair for each group's RSU and issues the public-private key pair to the RSU for local secret storage; then, the TA forms an initial block signed with its own private key for each RSU's public key; the initial block will be sent to all RSU nodes through the X2 interface to verify the signature and "consensus"; the RSU that calculates the hash value that meets the conditions the fastest will send the initial block to other RSUs for verification; once the block's nonce passes the verification, it will be "uploaded to the chain", that is, all RSUs write to the locally maintained blockchain that stores the RSU public key, completing the synchronization of the RSU public key in the entire RSU network;

[0048] Vehicle initialization module: An offline TA divides all vehicles into different groups according to the geographical location of the RSU in a safe environment, generates a public-private key pair for each vehicle, and issues the public-private key pair to the vehicle for secret storage; then, the TA forms an initial transaction for the public key of each vehicle, and all vehicle public key initial transactions form an initial block, which is sent to the entire RSU network through the X2 interface for "consensus" and "chaining", that is, writing to the blockchain that stores the vehicle public key, and completing the synchronization of the vehicle public key status in the entire RSU network; during the synchronization process, the RSU in each group saves the public key of each vehicle under its jurisdiction, forms a vehicle public key list, and manages the vehicle public keys in this group.

[0049] The initialization of the initialization module is as follows:

[0050] like Figure 1 As shown in the figure, an offline TA divides the vehicles into groups according to the different coverage of RSUs. For each communication entity in each group, including vehicles and RSUs, the offline TA generates a public-private key pair for it in a secure environment and issues it to the local secret storage.

[0051] For each RSU, TA generates a public key for initialization to form an initial block signed by TA's private key, which is synchronized to all other RSU nodes in the network through the cellular network X2 interface, and intends to perform signature verification and "consensus" based on proof of work: the nonce of the block starts from the initial value, and after each self-increment, it is taken as the union with the hash value of the block, and the hash value of the union is calculated. During the calculation process, once a hash value less than a certain threshold is found, the "consensus" is called successful, as shown in the following formula:

[0052] H(c H ||nonce)<target

[0053] Among them, c His the hash value of this block, nonce is a random value that increases each time from the initial value, and target is the conditional threshold that the calculated hash value should meet. The RSU node that achieves the fastest "consensus", that is, the RSU node that calculates the hash value that meets the conditions the fastest, sends it to other RSU nodes in the network to verify the block nonce value. Once the verification is successful, it is "uploaded to the chain": the public key block containing the initialization generated by the RSU is written to the blockchain that stores all RSU public keys. A block storing RSU public keys contains the properties shown in Table 1 below:

[0054] Table 1

[0055]

[0056]

[0057] Note: This block has no block body and is only responsible for storing the RSU public key; therefore, each time a new RSU public key is generated, a new block will be generated accordingly. The digital signature of the "RSU new public key" is verified by the TA public key issued by TA to all RSUs. Before the "consensus" of the block is successful, the value of its "RSU public key of successful 'consensus'" is empty; the corresponding RSU public key is not written until the "consensus" is successful. The "status of the public key" is always "valid" until the public key is revoked. The "parent block" of the genesis block will be set to empty.

[0058] For each vehicle, TA forms an initial transaction for the public key it initializes, and the transaction body of the initial transaction contains the vehicle public key signed by TA's private key; all vehicle public key initial transactions are sent to all RSU nodes to verify the signature, and accumulate to form an initial block for "consensus", that is, calculating the hash value that meets the consensus difficulty. The RSU with the fastest "consensus" is sent to all other RSUs through the X2 interface for nonce value verification and "chaining", that is, writing to the blockchain that stores the vehicle public key. An initial transaction contains the following attributes shown in Table 2:

[0059] Table 2

[0060]

[0061] The digital signature of the transaction body content is verified through the TA public key issued by TA to all RSUs. In the process of sending the initial public key transactions of all vehicles to all RSU nodes to form blocks, the RSU in each group forms a vehicle public key list, saves the public key of each vehicle under its jurisdiction, and manages the public keys of the vehicles in the group.

[0062] Initialization needs to ensure that each RSU maintains a blockchain that stores all RSU public keys and a blockchain that stores all vehicle public keys.

[0063] The group key generation and issuance of the group key generation and issuance module is as follows:

[0064] The RSU is responsible for the generation of the group key, and uses the public key of each vehicle stored locally to encrypt the group key one by one, and sends it to each vehicle in the group through the Uu port downlink using an asymmetric encryption mechanism. Once the encrypted group key is distributed to all vehicles in the group, each vehicle will use the private key stored secretly to decrypt the encrypted group key; all vehicles in the group can send BSM / CAM and other messages through the side link for secure, collaborative perception based on the symmetric encryption mechanism. For details on the group key generation and issuance process, please refer to the embodiment. Figure 3 .

[0065] The vehicle cross-domain switching of the vehicle cross-domain module is as follows:

[0066] During the communication process, the vehicle will use the group key to periodically send a heartbeat message to the RSU of the group to which it belongs through the uplink corresponding to the Uu interface to report the status. The heartbeat message contains the attributes shown in Table 3 below:

[0067] Table 3

[0068]

[0069] When the source RSU does not receive the heartbeat information of a member vehicle within a certain time range, a vehicle cross-domain transaction is generated, and its transaction body contains the public key of the member vehicle; the public key is encrypted by the public key of the destination RSU, signed by the private key of the source RSU, and included in the transaction body and sent to all other RSUs through the X2 interface. Encryption and signing are performed according to the following formula:

[0070]

[0071] Where M e represents an encrypted message, Represents the encryption algorithm RSA, PK using the public key of the target RSU car Represents cross-domain vehicle public key information, represents the ECDSA algorithm that uses the private key of the source RSU for signing. Formula (1) encrypts the vehicle public key with the public key of the destination RSU, ensuring that only the private key secretly stored by the destination RSU can decrypt the encrypted information, providing confidentiality of key transmission. Here, the scenario considered by this method is the highway scenario: the RSU deployed on a two-way highway has the characteristic of knowing the public keys of its neighboring RSUs.

[0072] Therefore, the source RSU can query the public key of the destination RSU from the locally stored blockchain of all RSU public keys for encryption without the help of vehicle reporting. In formula (2), the source RSU uses its private key to digitally sign the encrypted content, and the destination RSU can obtain the public key of the source RSU from the chain that stores all RSU public keys and verify the validity of the signature, providing identity authentication function and ensuring the integrity and non-repudiation of the transmission key. After the destination RSU verifies the signature and decrypts to obtain the public key of the vehicle, it adds the corresponding transaction to the transaction pool, indicating that a vehicle has been switched across domains. All RSUs periodically clear transactions in the transaction pool and form blocks, and perform "consensus" and "chaining" according to the proof-of-work consensus mechanism. For details of the vehicle cross-domain switching process, please refer to the embodiment. Figure 4 From formula (2), we can know that the transaction should have the following properties as shown in Table 4:

[0073] Table 4

[0074]

[0075]

[0076] A block contains the following attributes as shown in Table 5:

[0077] Table 5

[0078]

[0079] After the block shown above is "on-chained", the source RSU cleans up the public key information of the vehicles under its jurisdiction and deletes the public key of the vehicle that has left from the list of vehicle public keys saved locally by the source RSU; the destination RSU adds the new vehicle public key to the list of vehicle public keys saved locally. Every change in the public key information will trigger the regeneration and issuance of the group key to ensure the forward / backward security of the group key.

[0080] The key update module includes the following submodules:

[0081] RSU key update module: If an RSU updates its public-private key pair, it needs to form a block recording the updated public key and send the block to all RSUs through the X2 interface; all RSUs conduct "consensus" and "chain" according to the proof of work; after "chaining", the RSU will regenerate the group key and issue the group key to all vehicles in the group;

[0082] Vehicle key update module: If the vehicle updates its public-private key pair, it uses the old group key and symmetric encryption mechanism to report its public key to the RSU to which it belongs through the uplink of the Uu interface, and updates the vehicle public key list managed by the RSU; after the report is completed, the RSU of the group to which the vehicle belongs will regenerate the group key and issue it to all vehicles in the group.

[0083] The key update status of the key update module is as follows:

[0084] Once the RSU key is updated, a block as shown in Table 1 is generated. The digital signature inside the block needs to be verified by finding the old RSU public key stored in the corresponding block through the "block hash value storing the public key before RSU initialization / update". After the verification, "consensus" and "chaining" are performed. Once the vehicle's key is updated, a vehicle key update transaction is generated. The transaction body contains the new vehicle public key encrypted using the old group key and symmetric encryption mechanism. The transaction is reported to the RSU to which it belongs through the uplink corresponding to the Uu interface; the RSU to which it belongs will use the group key to decrypt the encrypted vehicle public key, update the vehicle public key list managed by the RSU and send it to all RSU nodes for "consensus" and "chaining". A key update transaction contains the following attributes shown in Table 6:

[0085] Table 6

[0086]

[0087] Finally, the group to which the key update individual belongs regenerates and issues the group key.

[0088] The key revocation status of the key revocation module is as follows:

[0089] If the records of the blockchain show that a certain RSU frequently updates its key, or a certain vehicle repeatedly leaves and joins the area under the jurisdiction of a certain RSU in a short period of time, the behavior is determined to be malicious. After determining the malicious behavior, the detection party will generate a report on the malicious behavior and place it in the report pool. When the number of reports about a malicious behavior in the report pool exceeds a certain threshold: for a malicious RSU, a block will be generated to revoke the public key of the malicious RSU, that is, the status value of whether the public key is revoked in Table 1 is set to true. After the block reaches a consensus among all normal RSUs, it is "put on the chain". For malicious vehicles, a detection party vehicle is randomly selected in the group to which it belongs to generate a transaction of malicious behavior, which is sent to all RSUs to form a block, "consensus" and "put on the chain", and finally the public key of the malicious vehicle is deleted from the vehicle public key list stored locally in the RSU to which the malicious vehicle belongs. The transaction that generates malicious behavior contains the following attributes shown in Table 7:

[0090] Table 7

[0091]

[0092] Finally, the group to which the key update individual belongs regenerates and issues the group key.

[0093] The above embodiments are preferred implementation modes of the present invention, but the implementation modes of the present invention are not limited to the above embodiments. Any other changes, modifications, substitutions, combinations, and simplifications that do not deviate from the spirit and principles of the present invention should be equivalent replacement methods and are included in the protection scope of the present invention.

Claims

1. A heterogeneous cellular vehicle network key management system based on blockchain, characterized by: The X2 interface, Uu interface, and PC5 interface of the cellular network support different vehicle networking communication modes, forming a heterogeneous cellular vehicle networking. Its key management system includes the following modules: Initialization module: Before the RSU and the vehicle start communicating, an offline TA, i.e. the trusted center, divides the vehicles into groups and generates and issues public and private key pairs for the RSU and the vehicle in a secure environment. The public keys of the RSU / vehicle are synchronized to all RSUs through forming blocks / transactions, "consensus" and "on-chaining". Each RSU manages the public keys of all vehicles within its coverage area. Group key generation and issuance module: Each RSU generates a group key and issues the group key through an asymmetric encryption mechanism using the public key list of all vehicles in the domain stored locally; Vehicle cross-domain module: For cross-domain vehicles, the source RSU and the destination RSU are responsible for generating new transactions, recording changes in public keys, and writing them into new blocks by the RSU that reaches the fastest consensus. Once the "chaining" is successful, the source RSU and the destination RSU groups regenerate and issue group keys respectively. Key update module: The update of RSU public key is completed by writing into RSU public key blockchain. The update of vehicle public key is encrypted by group key based on symmetric encryption mechanism and reported to the RSU to which it belongs, and written into vehicle public key blockchain. Finally, source RSU and destination RSU group regenerate and issue group keys respectively. Key revocation module: Nodes that detect malicious behavior generate reports related to the malicious behavior and place them in the report pool. When the number of reports reaches the threshold, the nodes form a transaction, "consensus" and "upload to the chain", and then the source RSU and the destination RSU regenerate and issue the group key respectively; The initialization module includes the following submodules: RSU initialization module: In a secure environment, an offline TA generates its own public-private key pair and publishes its public key to each RSU; the TA generates a public-private key pair for each group's RSU and issues the public-private key pair to the RSU for local secret storage; then, the TA forms an initial block signed with its own private key for each RSU's public key; the initial block will be sent to all RSU nodes through the X2 interface to verify the signature and "consensus"; the RSU that calculates the hash value that meets the conditions the fastest will send the initial block to other RSUs for verification; once the block's nonce passes the verification, it will be "uploaded to the chain", that is, all RSUs write to the locally maintained blockchain that stores the RSU public key, completing the synchronization of the RSU public key in the entire RSU network; Vehicle initialization module: An offline TA divides all vehicles into different groups according to the geographical location of the RSU in a safe environment, generates a public-private key pair for each vehicle, and issues the public-private key pair to the vehicle for secret storage; then, the TA forms an initial transaction for the public key of each vehicle, and all vehicle public key initial transactions form an initial block, which is sent to the entire RSU network through the X2 interface for "consensus" and "on-chain", that is, written into the blockchain that stores the vehicle public key, and completes the synchronization of the vehicle public key status in the entire RSU network; during the synchronization process, the RSU in each group saves the public key of each vehicle under its jurisdiction, forms a vehicle public key list, and manages the vehicle public keys of this group; The group key generation and issuance module specifically performs the following operations: Each group of RSUs is responsible for generating group keys to support intra-group communication; Each group of RSUs uses the public key of each vehicle stored locally to encrypt the generated group key one by one; Each group of RSUs uses an asymmetric encryption mechanism to distribute the encrypted group key to each vehicle in the group one by one through the downlink corresponding to the Uu cellular interface; Each vehicle decrypts the encrypted group key using its secretly kept private key; All vehicles in the group use the group key to perform secure collaborative sensing based on a symmetric encryption mechanism through the side link corresponding to the PC5 cellular interface; The vehicle cross-domain module specifically performs the following operations: The vehicle will periodically send heartbeat messages to the RSU via the uplink using the group key. The source RSU determines whether the vehicle has left the jurisdiction by detecting the vehicle's heartbeat message. If the source RSU does not receive a heartbeat message from a vehicle within an integer multiple of the heartbeat message period, it is considered that the vehicle has left the jurisdiction. The source RSU generates an unverified vehicle cross-domain transaction and sends it to the destination RSU through the X2 interface. The transaction contains the public key of the cross-domain vehicle signed by the source RSU private key and encrypted by the destination RSU public key. The scenario considered here is the highway scenario: the RSU deployed on the two-way highway has the characteristic of knowing the public keys of its adjacent RSUs. Therefore, the source RSU can query the public key of the destination RSU from the locally stored RSU public key blockchain without the help of vehicle reporting to perform encryption operations, ensuring that only the destination RSU can decrypt the encrypted vehicle public key. After receiving the transaction, the destination RSU will query the public key of the source RSU from all RSU public key blockchains maintained locally to verify the source RSU signature contained in the transaction, and use its own secretly kept private key to decrypt the public key of the cross-domain vehicle encrypted by the source RSU, and then change the transaction from an unverified state to a verified state; The destination RSU sends the verified transaction to all other RSU nodes through the X2 interface, indicating that a vehicle has entered a new group across domains; All RSUs regularly collect all received and verified transactions to form blocks and reach a "consensus" according to the proof-of-work consensus mechanism; The RSU that reaches the fastest consensus will send the above block to all other RSUs for verification. Once the verification is successful, it will be "on-chained", that is, written into the blockchain to reach a consensus on cross-domain vehicle and key movement; The source RSU deletes the public key of the departing vehicle from the locally managed vehicle public key list; The destination RSU adds the public key information of the new vehicle to the local vehicle public key list; The source RSU and the destination RSU groups generate and issue group keys respectively; The key update module includes the following submodules: RSU key update module: If an RSU updates its public-private key pair, it needs to form a block recording the updated public key and send the block to all RSUs through the X2 interface; all RSUs reach a "consensus" and "upload the data to the chain" according to the proof of work; after "uploading the data to the chain", the RSU will regenerate the group key and issue the group key to all vehicles in the group; Vehicle key update module: If a vehicle updates its public-private key pair, it will use the old group key and symmetric encryption mechanism to report its public key to the RSU to which it belongs through the uplink of the Uu interface, and update the vehicle public key list managed by the RSU; after the report is completed, the RSU of the group to which the vehicle belongs will regenerate the group key and issue it to all vehicles in the group; The key revocation module specifically performs the following operations: During the communication process of the Internet of Vehicles, the existence of some internal malicious nodes makes the Internet of Vehicles system subject to various attacks. Malicious behavior in the system can be judged by querying the records of the blockchain; if the records of the blockchain show that a certain RSU frequently updates its key, or a certain car repeatedly leaves and joins the area under the jurisdiction of the RSU in a short period of time, it can be determined that the behavior is malicious; At this point, the detection party generates a report on the malicious behavior and places it in the report pool; When the number of reports about a malicious behavior in the report pool exceeds the threshold: for malicious RSUs, a detection party RSU is randomly selected to generate a block of revoked keys, and sent to other RSUs for "consensus" and "on-chain"; for malicious vehicles, a detection party vehicle is randomly selected in the group to which it belongs to generate a malicious behavior transaction, which is sent to all RSUs to form a block, "consensus" and "on-chain", and finally the public key of the malicious vehicle is deleted from the vehicle public key list stored locally in the RSU to which the malicious vehicle belongs; For each RSU, the public key generated by TA for initialization forms an initial block signed by TA's private key, which is synchronized to all other RSU nodes in the network through the cellular network X2 interface, and signature verification and "consensus" based on proof of work are intended to be performed: the nonce of the block starts from the initial value, and after each self-increment, the nonce is taken as the union with the hash value of the block, and the hash value of the union is calculated; during the calculation process, once a hash value less than the conditional threshold is found, the "consensus" is called successful, as shown in the following formula: H(c H ||nonce)<target Among them, c H is the hash value of this block, nonce is a random value that increases each time from the initial value, and target is the conditional threshold that the calculated hash value should meet; the RSU node that succeeds in "consensus" the fastest, that is, the RSU node that calculates the hash value that meets the conditions the fastest, sends it to other RSU nodes in the network to verify the block nonce value; once the verification is successful, it is "uploaded to the chain": the public key block containing the initialization of the RSU is written into the blockchain that stores all RSU public keys.

Images