A vehicle networking cross-domain identity authentication method based on master-slave multi-chain architecture

Abstract

This invention proposes a cross-domain identity authentication method for the Internet of Vehicles (IoV) based on a master-slave multi-chain architecture, comprising six stages: system initialization, OBU registration, certificate storage, cross-domain identity authentication, certificate update, and certificate revocation. Considering that traditional IoV uses a single-chain blockchain structure, it cannot effectively isolate vehicle information across cities, posing risks of privacy leaks and low query efficiency. Therefore, this invention proposes a master-slave multi-chain architecture, where slave chains in each city build a secure cross-domain communication channel through the master chain, achieving secure isolation of cross-domain vehicle information. For data storage, a Merkle tree hash mechanism is used to process vehicle information to ensure data integrity and immutability. A prefix tree is used to compress the common parts in the hash path, constructing an MPT-based storage structure to improve the query efficiency of vehicle information. Furthermore, Active Directory (AD) is used to monitor malicious vehicle behavior in real time, thereby achieving secure and efficient cross-domain identity authentication.

Description

Technical Field

[0001] This invention belongs to the field of vehicle networking technology and proposes a cross-domain identity authentication method for vehicle networking based on a master-slave multi-chain architecture. Background Technology

[0002] With the advancement of information technology and the popularization of the intelligent vehicle concept, the Internet of Vehicles (IoV) has become a rapidly developing field in intelligent transportation systems. IoV achieves efficient and seamless data exchange by connecting vehicle onboard units (OBUs), roadside units (RSUs), trusted applications (TAs), and audit departments (ADs). However, when vehicles communicate across different cities, the single-chain structure used in traditional blockchains cannot effectively isolate vehicle information. This makes all data globally visible, potentially allowing malicious vehicles to forge false information to attack the identities of legitimate vehicles, leading to the leakage of legitimate vehicle identities and seriously threatening driving safety.

[0003] Therefore, using the layered structure of blockchain to build a master-slave multi-chain architecture can effectively solve the problem of efficient isolation of vehicle information between cities and ensure the security of cross-domain communication. However, considering the continuous increase in the number of vehicles between cities, the traditional single-chain structure of blockchain suffers from data bloat, requiring all nodes to maintain a complete copy of the blockchain, leading to a significant decrease in communication efficiency. Therefore, some scholars have combined blockchain with Merkle trees, using Merkle trees to store the hash values ​​of vehicle certificates and recording their root values ​​in the blockchain to improve the efficiency of data hashing. However, the Merkle tree structure itself still incurs significant computational and storage overhead, leaving room for optimization in scenarios with limited node resources.

[0004] To address the aforementioned problems, this invention proposes a cross-domain identity authentication method for the Internet of Vehicles (IoV) based on a master-slave multi-chain architecture. In IoV, the traditional blockchain is hierarchically divided to enable cross-domain communication between vehicles in different cities. Furthermore, the advantages of prefix trees are combined to optimize the traditional Merkle tree, constructing a Merkle Patricia Tree (MPT) to improve data query efficiency, thereby achieving secure and efficient cross-domain identity authentication. Summary of the Invention

[0005] The purpose of this invention is to provide a cross-domain identity authentication method for vehicle-to-everything (V2X) networks based on a master-slave multi-chain architecture, comprising the following steps:

[0006] 1. System Initialization Phase. In the master-slave multi-chain architecture, the slave chain (SC) consists of RSU nodes, and the main chain (MC) consists of TA nodes. These nodes store vehicle information within each city and vehicle identification identifiers between cities, ensuring effective isolation of vehicle information. Simultaneously, MPT is used to store data in the blockchain to improve data retrieval efficiency. AD, as a node with special permissions, monitors the vehicle status in real time to prevent malicious vehicles from forging false information and launching attacks, thereby ensuring system security. TA generates system parameters and generates public-private key pairs and identity certificates (Certificates) for legitimate vehicles. OBU The private key is stored locally, while the public key is public.

[0007] 2. OBU Registration Phase. When an OBU joins the vehicle-to-everything (V2X) system for the first time, it needs to register its identity. The OBU submits its registration information to the TA (Technical Controller) to initiate a registration request. The TA verifies the OBU's information. If verification fails, the registration process terminates; if verification succeeds, a public-private key pair and a CERT (Certificate) are generated for the OBU. OBU .

[0008] 3. Certificate Storage Phase. After successful OBU registration, the certificate is stored via RSU. OBU The data is stored in the InterPlanetary File System (IPFS) and the corresponding storage address (CID) is obtained. The RSU then stores the CID in the blockchain, facilitating cross-domain identity authentication between vehicles in different cities. In the blockchain, MPT key-value pairs are used to store data. Compared to traditional Merkle trees, MPT compresses the hash path of the Merkle tree by introducing the path compression feature of prefix trees, thereby achieving efficient key-value lookups. This structure effectively improves the efficiency of cross-domain vehicle communication while ensuring data security.

[0009] 4. Cross-domain authentication phase. Before the OBU can conduct cross-domain communication, it needs to verify the identity of the target vehicle. When the OBU in city A... A Received from OBU in city B B When sending information, OBU A via RSU A According to OBU B Check if the OBU is in the local cache for CID query. B If the query fails, retrieve the valid certificate from the subchain SC to which city A belongs. A Query OBU B If a valid certificate is still not found, then SC A Will OBU B The information is submitted to MC, and then transmitted to the slave chain SC to which city B belongs through the secure cross-chain channel provided by MC.B Request OBU B The certificate will ultimately be issued through SC. A Return to OBU A .

[0010] 5. Certificate Renewal Phase. When the OBU's Certificate... OBU When the certificate is nearing its expiration date, a certificate renewal request needs to be sent to the TA (Authorized Certificate Provider). Upon receiving the request, the TA verifies the OBU's identity and confirms its valid certificate renewal permissions. Once verification is successful, the TA generates a new certificate (Certificate) for the OBU. * Subsequently, the RSU transferred the OBU's Certification. * Upload to IPFS and obtain a new CID. * RSU signs the submitted information and sends it to SC. SC's smart contract verifies RSU's signature and then processes it based on the ID. OBU The corresponding key is searched for in the MPT to update the corresponding node. Finally, the system recalculates the root hash of the MPT and stores the new root hash in the blockchain.

[0011] 6. Certificate Revocation Phase. After AD detects a malicious vehicle forging or tampering with information, SC's smart contract searches for the corresponding node in MPT based on the malicious vehicle's identity, adds its status to the revocation list, and records the revocation time. Subsequently, the system recalculates the root hash of MPT and stores it in the blockchain. Finally, SC packages the revocation operation and waits for block confirmation; other nodes can then automatically obtain the updated certificate revocation status.

[0012] Beneficial effects of this invention:

[0013] 1. This invention employs a layered blockchain structure to achieve cross-domain identity authentication for vehicles across different cities. The SC (Site Controller) is responsible for storing vehicle information within its city, supporting real-time interaction among local vehicles. The MC (Machine Controller) is responsible for storing the global identity identifier of vehicles, ensuring effective isolation of vehicle information between different cities. Simultaneously, AD (Active Access Controller) provides real-time monitoring of malicious vehicles to prevent them from forging false information and launching identity attacks against legitimate vehicles.

[0014] 2. This invention combines the path compression characteristics of prefix trees to optimize traditional Merkle trees and construct an MPT structure. When vehicle information is added to the blockchain, the hash mechanism of the Merkle tree is used to process the vehicle information, thereby ensuring the integrity and immutability of the vehicle information. At the same time, the prefix tree is used to compress the common parts in the hash path to improve the data query efficiency. Attached Figure Description

[0015] Figure 1This is a flowchart illustrating the steps of cross-domain identity authentication for the Internet of Vehicles based on a master-slave multi-chain architecture, as described in this invention.

[0016] Figure 2 This is a flowchart of the cross-domain identity authentication process for the Internet of Vehicles based on a master-slave multi-chain architecture, as described in this invention.

[0017] Figure 3 This is a diagram of the cross-domain identity authentication architecture for the Internet of Vehicles based on a master-slave multi-chain architecture, as described in this invention.

[0018] Figure 4 This is a schematic diagram of an insertion operation in an embodiment of the present invention where the new node and the leaf node share a common prefix.

[0019] Figure 5 This is a schematic diagram of an insertion operation in an embodiment of the present invention where the new node and the extended node have a common prefix.

[0020] Figure 6 This is a comparison chart of the average latency of cross-domain identity authentication in embodiments of the present invention;

[0021] Figure 7 This is a comparison chart of certificate query path costs in an embodiment of the present invention. Detailed Implementation

[0022] This implementation provides a cross-domain identity authentication method for vehicle-to-everything (V2X) networks based on a master-slave multi-chain architecture, comprising six steps: system initialization, OBU registration, certificate storage, cross-domain identity authentication, certificate update, and certificate revocation. Figure 1 As shown, the specific flowchart is as follows: Figure 2 As shown below. These six steps will be explained in detail:

[0023] Step 1, System Initialization Phase:

[0024] Considering that traditional IoV architectures use a single-chain blockchain structure, they cannot effectively isolate vehicle information between cities, leading to privacy leaks. Furthermore, cross-domain communication between vehicles requires querying a large amount of information, significantly reducing query efficiency. Therefore, this invention optimizes the traditional Merkle tree to improve the query speed of vehicle information and achieves IoV cross-domain identity authentication in a master-slave multi-chain architecture. The IoV architecture diagram is shown below. Figure 3 As shown.

[0025] In the master-slave multi-chain architecture, SC consists of RSU nodes, and MC consists of TA nodes, storing vehicle information within each city and vehicle identification between cities respectively, ensuring effective isolation of vehicle information. Meanwhile, MPT is used in the blockchain to store data, improving data retrieval efficiency. AD, as a node with special permissions, monitors the vehicle status in real time, preventing malicious vehicles from forging false information to launch attacks, thereby ensuring system security. TA generates system parameters and generates public-private key pairs and Cert for legitimate vehicles. OBU The private key is stored locally, while the public key is public.

[0026] Step 2, OBU registration phase:

[0027] When an OBU joins the vehicle-to-everything (V2X) system for the first time, it needs to register its identity. The OBU submits its registration information to the TA (Technical Controller) to initiate a registration request. The TA verifies the OBU's information. If the verification fails, the registration is terminated. If the verification is successful, a public-private key pair and a CERT (Certificate) are generated for the OBU. OBU Step two, the OBU registration stage, includes:

[0028] 1. The OBU performs a hash operation on its MAC address to generate a corresponding unique identifier ID. OBU At the same time, a timestamp T is generated. reg Use TA's public key to PK TA Encrypt the registration information and send a registration request to the user.

[0029] 2. After receiving the OBU's registration request, the TA uses its private key SK. TA After decrypting the registration information, first verify |T cur -T reg |<=ΔT, then verify ID. OBU Check if the MAC address matches the corresponding OBU. If verification fails, registration is terminated; if verification succeeds, a number SK is randomly selected. OBU ∈Z q Used as the private key for the OBU, and the corresponding public key PK is calculated. OBU =SK OBU ·P, where ΔT is the maximum statutory time interval and P is the system parameter.

[0030] 3. The TA generates an identity certificate (Certificate) for the OBU. OBU , using its SK TA Sign and send SK through a secure channel OBU PK OBU Cert OBU Send to OBU.

[0031] 4. After receiving the information from the TA, the OBU verifies the TA's signature and confirms successful registration.

[0032] Step 3, Certificate Storage Stage:

[0033] After successful OBU registration, the Certification will be transferred via RSU. OBU The data is stored in IPFS, and the corresponding CID is retrieved. Subsequently, the RSU stores the CID in the blockchain, facilitating cross-domain identity authentication between vehicles in different cities. In the blockchain, MPT key-value pairs are used to store data. Compared to traditional Merkle trees, MPT compresses the hash path of the Merkle tree by introducing the path compression feature of prefix trees, thereby achieving efficient key-value lookups. This structure effectively improves the efficiency of cross-domain vehicle communication while ensuring data security.

[0034] RSU will Cert OBU The process of storing the CID in the blockchain is essentially the process of transferring the ID to the blockchain. OBU The CID is used as the key and the corresponding value is inserted into the MPT. The MPT includes empty nodes, branch nodes, leaf nodes, and extended nodes. The specific operations are as follows:

[0035] 1. First, find the new node (Node) New The node with the longest common path prefix is ​​denoted as Node. Cur .

[0036] 2. If Node Cur For branch nodes:

[0037] ①If Node New If the slot corresponding to the first character of the remaining path is empty, then the Node will be... New Insert it into the slot.

[0038] ②If Node New If the slot corresponding to the first character of the remaining path already has a hash value pointing to another node, then the process recursively moves to the next child node to continue matching.

[0039] ③If Node New If the path ends here, then Node will be... New Content in Node Cur Update in the 17th slot.

[0040] 3. If Node Cur Leaf nodes:

[0041] ①If Node New Remaining path and Node CurIf the remaining paths are completely identical, then update the Node directly. Cur Value.

[0042] ②If Node New Remaining path and Node Cur If the remaining path parts are identical, then after extracting the common prefix path, the Node will be... Cur Replace the new prefix path node as the extended node. Then create a branch node and insert it into the extended node. This branch node then branches into two paths: one pointing to the original Node. Cur The remaining path, one pointing to Node New Remaining path.

[0043] For example: There is already a Node Cur The key is "c54a8b". Now, the node with key "c54ae2" and value "d1a926" is... New Insert into MPT, as shown in the diagram. Figure 4 As shown, at this time, Node Cur Replace it with an extended node, then create a branch node and insert it into the extended node. Cur Remaining path and Node New The remaining paths each create a new leaf node, which is then stored in the corresponding slot of the branch node.

[0044] 4. If Node Cur For expanding nodes:

[0045] ①If Node New Remaining path and Node Cur If the remaining paths are completely identical, proceed to the next child node pointed to by the extended node and continue the insertion process.

[0046] ②If Node New Remaining path and Node Cur If the remaining path parts are identical, then after extracting the common prefix path, the Node will be... Cur Replace the new prefix path node as the new extended node. Then create a branch node and insert it into the extended node. For Node Cur For the remainder, create new extended nodes to compress the path and point to the atomic nodes; for Node New For the remaining part, create new leaf nodes. Point these two nodes to the corresponding slots of the branch nodes.

[0047] For example: There is already a Node Cur The prefix path is "c54a8", which points to a branch node. Now, the Node with key "c54be2" and value "d1a926" is...New Insert into MPT, as shown in the diagram. Figure 5 As shown, at this time, Node Cur Replace the new extended node "c54", then create a branch node and insert it into the new extended node. Subsequently, the "a" slot of the branch node points to the new extended node "8". New The remaining path creates new leaf nodes, which are stored in the corresponding slots of the branch nodes.

[0048] Step 4, Cross-Domain Identity Authentication Stage:

[0049] Before an OBU can conduct cross-domain communication, it needs to verify the identity of the target vehicle. When an OBU in city A... A Received from OBU in city B B When sending information, OBU A via RSU A According to OBU B Check if the OBU is in the local cache for CID query. B A valid certificate; if the query fails, then from the SC to which city A belongs. A Query OBU B If a valid certificate is still not found, then SC A Will OBU B The information is submitted to MC, and then transmitted to the SC to which city B belongs through the secure cross-chain channel provided by MC. B Request OBU B The certificate will ultimately be issued through SC. A Return to OBU A Step four, the cross-domain identity authentication stage, includes:

[0050] 1. OBU in City B B To the OBU in city A A Initiating cross-domain communication requests, including OBU B The city region D B Certificate CID, timestamp T, random number r, OBU A The city region D A and OBU B Signature of the above data;

[0051] 2. OBU A Upon receiving the request, via RSU A According to OBU B Check if the OBU is in the local cache for CID query. B A valid certificate; if the query fails, retrieve it from the SC of the domain. A Query OBU BIf a valid certificate is still not found, then SC A Send a request to MC;

[0052] 3. The MC receives the SC. A After the request, query the OBU. B If the CID query is successful, then the domain D it belongs to is mapped. B Return to SC A Otherwise, return a result indicating that the query failed.

[0053] 4. SC A Upon receiving the response from MC, if the query is successful, the query will be sent to SC via the secure cross-chain channel provided by MC. B Request OBU B Certificate;

[0054] 5. SC B Use its private key to OBU B The certificate and its SC B After signing the revocation status, it is returned to SC. A ;

[0055] 6. SC A After receiving the information, verify the SC. B The system checks the signature of the certificate to see if it has been revoked and if it is valid. If valid, it sets the appropriate time-to-live (TTL) for the certificate and stores it in the OBU. A RSU of the domain A In the process, the certificate is returned to the OBU. A Otherwise, return a verification failure result directly;

[0056] 7. OBU A Received SC A After receiving the information, use OBU B The public key is used to verify the signature, and the timestamp T and random number r are also verified to be valid. Once verification is successful, the OBU... A to OBU B Initiating a response, including OBU A Domain D A OBU A The CID, the new timestamp T2, the new random number r2, and the OBU A Signature of the above data;

[0057] 8. OBU B Received from OBU A After receiving the response, it is processed through the RSU of its domain. B Initiate a process that is completely symmetrical to steps 2-7 to obtain the vehicle's OBU. AThe certificate is verified. Once verified, cross-domain communication is established between the two parties.

[0058] Step 5, Certificate Renewal Phase:

[0059] When OBU's Cert OBU When the certificate is nearing its expiration date, a certificate renewal request needs to be sent to the TA (Authorized Certificate Provider). Upon receiving the request, the TA verifies the OBU's identity and confirms its valid certificate renewal permissions. Once verification is successful, the TA generates a new certificate (Certificate) for the OBU. * Subsequently, the RSU transferred the OBU's Certification. * Upload to IPFS and obtain a new CID. * RSU signs the submitted information and sends it to SC. SC's smart contract verifies RSU's signature and then processes it based on the ID. OBU The corresponding key is searched for in the MPT to find the appropriate node for updating. Finally, the system recalculates the root hash of the MPT and stores the new root hash in the blockchain. Step five, the certificate update stage, includes:

[0060] 1. The OBU sends a certificate update request to the TA, including the OBU's current certificate and the certificate's CID;

[0061] 2. After receiving the request from the OBU, the TA first verifies the OBU's identity, then verifies whether the OBU's certificate needs to be updated. If the verification passes, the TA generates a certificate for the OBU. * This includes the certificate's validity period and the TA's signature; if verification fails, the TA will reject the communication.

[0062] 3. After the OBU's certificate is successfully renewed, it sends a certificate renewal request to the RSU;

[0063] 4. After receiving the request from the OBU, the RSU verifies the OBU's identity. If the verification is successful, the RSU sends the OBU's Certification. * Upload to IPFS and obtain CID * Subsequently, RSU will assign the OBU ID. OBU CID * And the RSU signs the above data and sends it to the SC;

[0064] 5. After receiving the RSU information, the SC smart contract verifies the RSU signature. If the verification is successful, it uses the ID... OBU Find the corresponding node in the MPT and update its value to CID. * ;

[0065] 6. After the update is complete, backtrack up the search path, recalculate and update the root hash of MPT.

[0066] Step Six, Certificate Revocation Stage:

[0067] After AD detects a malicious vehicle forging or tampering with information, SC's smart contract searches for the corresponding node in MPT based on the malicious vehicle's identity, adds its status to the revocation list, and records the revocation time. Subsequently, the system recalculates the root hash of MPT and stores it in the blockchain. Finally, SC packages the revocation operation and waits for block confirmation; other nodes can then automatically obtain the updated certificate revocation status. Step six, the certificate revocation stage, includes:

[0068] 1. When AD detects a malicious vehicle, it submits the malicious vehicle's identification ID to SC.

[0069] 2. After receiving the information, SC verifies whether information about malicious vehicles exists in the blockchain. If so, it searches for the corresponding node in MPT based on the malicious vehicle's ID. During the node revocation process, the node to be revoked should be found... Del The node with the longest common path prefix is ​​denoted as Node. Cur The specific steps are as follows:

[0070] ①If Node Cur If it is a branch node, then delete the child node in the corresponding slot. After deletion, if Node Cur With only one child remaining, the branch node needs to be replaced with a leaf node or an extension node;

[0071] ②If Node Cur For leaf nodes, Node Del Path and Node Cur If the path is a complete match, then the entire Node will be... Cur Delete if Node Del The remaining path and Node Cur If the path does not match, then Node Del The item does not exist in the tree; deletion failed.

[0072] ③If Node Cur To expand a node, its path is Node Del The prefix, then for Node Cur Perform recursive deletion calls on the pointed-to node; if Node Cur Path is not a Node Del The prefix of Node Del The item does not exist in the tree; deletion failed.

[0073] 3. After the revocation is completed, add the ID of the malicious vehicle to the revocation list and record the revocation time. At the same time, trace back up the search path in MPT, recalculate and update the root hash of MPT.

[0074] 4. SC packages the revocation operation and waits for block confirmation. Once confirmed, other nodes can automatically obtain the updated certificate revocation status.

[0075] To address the aforementioned cross-domain identity authentication method for vehicle-to-everything (V2X) networks based on a master-slave multi-chain architecture, this invention utilizes OMNeT++ combined with Veins and SUMO to simulate the V2X environment. The specific simulation parameters are shown in Table 1.

[0076] Table 1. Simulation Parameters

[0077] parameter value Simulation area 1000 m × 1000 m Number of vehicles 50-500 vehicles Wireless transmission protocol 802.11p Simulation time 30s Communication bandwidth 6Mbps

[0078] To verify the advantages of the method of the present invention in terms of average authentication latency for cross-domain identity authentication, the method of the present invention simulated the average authentication latency when the number of vehicle nodes increased from 50 to 500. The results are as follows: Figure 6 As shown, compared with the traditional single-chain architecture, the master-slave multi-chain architecture for IoV cross-domain identity authentication has a lower average authentication latency. This is mainly because it achieves hierarchical management of vehicle information and efficient key-value queries, avoiding redundant queries and network congestion caused by the global visibility of all data in the traditional single-chain architecture. Therefore, this invention reduces the computational burden of cross-domain authentication, thereby lowering the average authentication latency.

[0079] To further improve certificate query efficiency, the performance of traditional Merkle trees and the MPT structure of this invention was compared under different numbers of certificates. The results are as follows: Figure 7 As shown, the traditional Merkle tree storage structure experiences a significant increase in the number of certificates during the query process, mainly because the query process requires the use of external indexes to locate data. In contrast, the MPT storage structure of this invention encodes the key as a search path, which can directly traverse from the root node to find data, thereby effectively reducing the computational overhead of the data.

Claims

1. A cross-domain identity authentication method for vehicle-to-everything (V2X) networks based on a master-slave multi-chain architecture, characterized in that... To effectively isolate vehicle information between different cities and ensure secure cross-regional vehicle communication, the method includes the following steps: (1) In the system initialization phase, in the master-slave multi-chain architecture, SC is composed of RSU nodes and MC is composed of TA nodes, which respectively store the information of vehicles within each city and the identity identifiers of vehicles between cities, ensuring effective isolation of vehicle information. At the same time, MPT is used to store data in the blockchain to improve the efficiency of data query. AD, as a node with special permissions, monitors the status of vehicles in real time to prevent malicious vehicles from forging false information to launch attacks, thereby ensuring the security of the system. TA generates system parameters and generates corresponding public and private key pairs and identity certificates Cert for legitimate vehicles. OBU The private key is stored locally, while the public key is public. (2) During the OBU registration phase, the OBU needs to register its identity when joining the vehicle networking system for the first time. The OBU submits its registration information to the TA to initiate a registration request. The TA verifies the OBU's information. If the verification fails, the registration is terminated. If the verification is successful, a public-private key pair and a Cert are generated for the OBU. OBU ; (3) During the certificate storage phase, after successful OBU registration, the certificate is stored via RSU. OBU The data is stored in IPFS and the corresponding storage address CID is obtained. Then, the RSU stores the CID in the blockchain to facilitate cross-domain identity authentication between vehicles in different cities. In the blockchain, MPT key-value pairs are used to store data. Compared with the traditional Merkle tree, MPT compresses the hash path of the Merkle tree by introducing the path compression feature of the prefix tree, thereby achieving efficient key-value lookup. This structure effectively improves the efficiency of cross-domain communication of vehicles while ensuring data security. (4) Cross-domain identity authentication stage: Before the OBU can conduct cross-domain communication, it needs to verify the identity of the target vehicle. When the OBU in city A... A Received from OBU in city B B When sending information, OBU A via RSU A According to OBU B Check if the OBU is in the local cache for CID query. B A valid certificate; if the query fails, then from the SC to which city A belongs. A Query OBU B If a valid certificate is still not found, then SC A Will OBU B The information is submitted to MC, and then transmitted to the SC to which city B belongs through the secure cross-chain channel provided by MC. B Request OBU B The certificate will ultimately be issued through SC. A Return to OBU A ; (5) During the certificate renewal phase, when the OBU's Cert... OBU When the certificate is nearing its expiration date, a certificate renewal request needs to be sent to the TA. Upon receiving the request, the TA verifies the identity of the OBU and confirms whether it has valid certificate renewal permissions. If the verification is successful, the TA generates a new certificate (Certificate) for the OBU. * Subsequently, the RSU transferred the OBU's Certification. * Upload to IPFS and obtain a new CID. * After RSU signs the submitted information, it sends it to SC. SC's smart contract verifies RSU's signature and then, based on the ID... OBU The corresponding key is searched for in the MPT to update the corresponding node. Finally, the system recalculates the root hash of the MPT and stores the new root hash in the blockchain. (6) During the certificate revocation phase, after AD detects that a malicious vehicle has forged or tampered with information, the SC smart contract searches for the corresponding node in MPT based on the identity of the malicious vehicle, adds its status to the revocation list, and records the revocation time. Subsequently, the system recalculates the root hash of MPT and stores it in the blockchain. Finally, SC packages the revocation operation and waits for the block to be confirmed. Other nodes can then automatically obtain the updated certificate revocation status.

2. The cross-domain identity authentication method for vehicle networking based on a master-slave multi-chain architecture according to claim 1, characterized in that, Step (1) System initialization phase: SCs in different cities build a secure cross-domain channel through MC to achieve secure isolation and trusted interaction of cross-domain vehicle information.

3. The cross-domain identity authentication method for vehicle networking based on a master-slave multi-chain architecture according to claim 1, characterized in that, In step (2) the OBU registration phase, the OBU generates a unique identifier ID based on its MAC address. OBU TA verifies the validity of the OBU registration time and ID. OBU Does it match the MAC address of the corresponding OBU? 4. The cross-domain identity authentication method for vehicle networking based on a master-slave multi-chain architecture according to claim 1, characterized in that, Step (3) Certificate storage stage: MPT includes empty nodes, branch nodes, leaf nodes, and extended nodes, and stores IDs through key-value pairs. OBU The mapping relationship between the certificate storage address (CID) and the hash path is optimized by utilizing the path compression feature of the prefix tree to improve the efficiency of data query.

5. The cross-domain identity authentication method for vehicle networking based on a master-slave multi-chain architecture according to claim 1, characterized in that, Step (4) Cross-domain identity authentication stage: When vehicles in different cities communicate across domains, the identity of the target vehicle needs to be verified.

6. The cross-domain identity authentication method for vehicle networking based on a master-slave multi-chain architecture according to claim 1, characterized in that, Step (5) Certificate Renewal Phase, OBU's Cert OBU When the certificate is nearing its expiration date, a certificate renewal request needs to be sent to the TA, who will then verify whether the OBU has the valid certificate renewal authority.

7. The cross-domain identity authentication method for vehicle networking based on a master-slave multi-chain architecture according to claim 1, characterized in that, In step (6) the certificate revocation stage, AD monitors the vehicle's status in real time and triggers the certificate revocation process when malicious vehicle behavior is detected.

Images