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

Abstract

The application discloses a cross-domain vehicle identity authentication method based on master-slave multi-chains, considers single-chain storage limitation, designs and realizes master-slave chain structure, and assists in realizing cross-domain authentication of vehicles; cross-domain storage and shared vehicle data are realized by means of the master-slave chain; in the authentication process, pseudonym generation parameters and verification parameters are introduced, so that the vehicle authentication between the Internet of Vehicles domains can resist various risk attacks, and the ACGA algorithm is used to propose a reputation value calculation mode for chain nodes, and the reputation value of the chain nodes is quantified according to the consensus delay and consensus result of the chain nodes, so that the blockchain authentication consensus efficiency and the throughput of cross-domain access are improved.

Description

Technical Field

[0001] This invention relates to the field of vehicle networking, and specifically to a cross-domain vehicle identity authentication method based on master-slave multi-chain. Background Technology

[0002] Cross-domain vehicle communication is an important application scenario in the Internet of Vehicles (IoV). It can be understood as communication between vehicles belonging to different vehicle domains, registered, authorized, and managed by different Certificate Authorities (CAs). Cross-domain vehicle communication takes various forms, such as inter-domain vehicle communication, vehicle-to-infrastructure communication, and vehicle-to-cloud platform communication. These communication interactions can help vehicles obtain real-time road condition information, reduce traffic congestion, improve road safety, and enhance the driver experience.

[0003] Vehicles communicating across domains have virtually no communication history with each other, making it impossible for them to determine the trustworthiness of vehicles from other domains. Some research has proposed identity authentication schemes with anonymity, achieving authentication while ensuring the vehicle's own anonymity to prevent identity leakage. This can be achieved by generating a legitimate alias through the pseudonym mechanism of the vehicle-to-everything (V2X) system, which is then used to communicate with surrounding entities. However, most of these schemes overlook the security vulnerabilities introduced by anonymity. Malicious vehicles can easily exploit this anonymity to launch identity spoofing attacks, making it impossible for the system to locate their true identity. Furthermore, existing authentication schemes often suffer from low efficiency in cross-domain authentication. Therefore, designing a cross-domain identity authentication scheme that can provide anonymous authentication while resisting such identity spoofing attacks is crucial. Summary of the Invention

[0004] To address the aforementioned shortcomings in existing technologies, this invention provides a cross-domain vehicle identity authentication method based on master-slave multi-chain.

[0005] To achieve the above-mentioned objectives, the technical solution adopted by this invention is as follows:

[0006] A cross-domain vehicle identity authentication method based on master-slave multi-chain includes the following steps:

[0007] S1. Construct a cross-domain authentication model based on master-slave multi-chain, including master chain layer, slave chain layer and vehicle domain layer;

[0008] S2. Based on the constructed cross-domain authentication model, use the consensus authentication algorithm to find the optimal consensus decision set;

[0009] S3. Based on the optimal formula found, each chain node performs corresponding state switching and uses a cross-domain vehicle identity authentication algorithm to achieve authentication consensus.

[0010] Furthermore, the main chain layer is a trusted sharing platform. When vehicles in the vehicle domain layer need to perform cross-domain communication, cross-domain authentication and resolution are performed through the main chain.

[0011] The slave chain layer is a transit station between the main chain layer and the vehicle domain layer, and the vehicle domain layer and the slave chain layer are bound to each other. Each vehicle domain in the vehicle domain layer interacts with the main chain layer through the slave chain in the slave chain layer.

[0012] The vehicle domain layer includes vehicles and communication devices. There are multiple different vehicle domains in this layer. Vehicles need to register or be verified on a server in a certain domain before they can access the network of that domain for information communication.

[0013] Furthermore, the specific interaction methods between each vehicle domain and the main chain layer through the slave chain in the slave chain layer are as follows:

[0014] S11, Vehicle V i A and V j B Registered in domain D respectively A and Domain D B Each person's identity certificate and other information are stored in D. A SC from chain A and D B SC from chain B In the chain, each storage account address is Addr. vi and Addr vj When V i A Received from V j B The communication message, then V i A Proceed to step S12;

[0015] S12, V i A Connect to the SC of this domain through a trusted entity in the domain. A via V j B Account address Addr vj Check if the vehicle's certificate information exists. If it does, the information can be directly returned to the trusted entity for authentication; otherwise, proceed to step S13.

[0016] S13, Current Domain D A and its continuation chain SC A V does not exist in j B When the certificate information is provided, then SC A Submit a request to the main chain MC, including the target vehicle's registration domain D. B and account address Addrvj In the main chain MC, according to {D B Addr vj}, towards D B SC B Inquire about account Addr vj If the account exists and is valid, proceed to step S14.

[0017] S14, the main chain MC will come from SC B Data response to SC A , by V i A The trusted entity in the vehicle domain is based on v j B The certificate information is verified, and if the verification is successful, the two parties can proceed to the next step of communication.

[0018] Furthermore, the optimal consensus decision set in S2 is selected based on the proportion of nodes participating in the consensus process, the reputation value of chain nodes, and the load of chain nodes. The solution is obtained by maximizing the efficiency P of the authentication process as the objective function. The specific solution process is as follows:

[0019]

[0020] stra N ∈[ra min ,ra max ],ld∈[ld min ,ld max ]

[0021] Where {f1,f2,f3} represent weighting factors, and ra min ,ra max To constrain the proportion of participation, ld min ,ld max Constraints on node load; Let ld be the i-th node participating in the consensus, and N be the total number of nodes; i The load of the i-th node participating in consensus; ra N For participation ratio, rv i Let be the reputation value of the i-th node and

[0022]

[0023] In the formula, T represents the ideal consensus time for a node to verify the vehicle's identity, k represents the k-th consensus, and num represents the total number of consensus attempts. Let be the actual consensus time for the k-th verification of the vehicle identity at the i-th node. This represents the actual result of the node's consensus at the k-th time. Let represent the result of the node's consensus at the kth time, where score1 represents the reputation value reduced due to consensus delay, and score2 represents the reputation value reduced for each consensus failure.

[0024] Furthermore, step S3 specifically includes the following steps:

[0025] S31. The system is configured to have different vehicle domains {D} A D B D j}, V i A and V j B Represents belonging to domain D A and D B For vehicles numbered i and j, initialize the elliptic curve and the key pair of the trusted device;

[0026] S32. Assign a unique identification code to each vehicle based on its type and network access time, and issue this code to the Certificate Authority (CA) in the corresponding vehicle domain. j Verify the identity of each vehicle;

[0027] S33. Before each communication, the vehicle requests a pseudonym belonging to the vehicle. When the roadside unit (RSU) receives the pseudonym request, it performs vehicle legitimacy verification and pseudonym generation parameter distribution.

[0028] S34, Vehicle V i A Initiating with vehicle V i B During communication, first process message M i Perform signature encryption, vehicle V i A Use temporary identity TID i and the corresponding private key vsk i To calculate the signature σ i The calculation method is as follows

[0029]

[0030] Where, β i For intermediate parameters, The timestamp is used to ensure the validity of the message. and For the private key vsk i The component, M i For vehicle V i A With vehicle V i B message of communication;

[0031] S35, Vehicle V iA Will contain signature σ i The message is sent to the roadside unit, which performs message verification and uses common parameters to perform batch verification of the signed messages sent by each vehicle.

[0032] Furthermore, the S32 process for authenticating each vehicle specifically includes the following steps:

[0033] S321, Order Certificate Authority (CA) j The key pair is {C pkj c skj}, CA j The vehicle's submitted identity information will be verified. If the vehicle information is valid, then the vehicle will be approved (V). i A Generate a registration key pair {V pki x i}, represented as:

[0034] x i =H2(RID) i ·λ+C pkj )

[0035] V pki =x i ·P

[0036] Among them, RID i P is the unique code for the vehicle, P is the generator of the elliptic curve, and λ is the random number required by the system company.

[0037] S322, Certificate Authority (CA) j Use the private key for vehicle V i A Generate encryption parameter pa i The vehicle stores this parameter locally;

[0038] S323, Certificate Authority (CA) j For vehicle V i A Generate identity certificate Cert i ={D i C pkj V pki S i}, S i For certificate status, the identity certificate is recorded in the vehicle domain D using the ACGA algorithm. i SC from chain i Above, from chain SC i With V pki and D i Calculate V for raw materials i A storage address Addrvi Ultimately, Addr vi Return to V i A The system queries the vehicle's identity certificate from the chain via the storage address.

[0039] Furthermore, the specific method for performing vehicle legitimacy verification and pseudonym generation parameter distribution in S33 is as follows:

[0040] S331, Roadside Unit (RSU) Request from pseudonym Obtain vehicle V from i A The vehicle domain is specified, and a query is made to the chain to retrieve the vehicle's identity certificate (Certificate). i ={D i C pkj V pki S i If the identity certificate does not exist, a cross-domain query for the vehicle's identity certificate (Certificate) is requested from the main chain. i ={D i C pkj V pki S i};

[0041] S332, Verify identity certificate Cert i ={D i C pkj V pki S i Certificate Status S i Is it a valid state? If valid, then proceed using the formula.

[0042]

[0043] The system verifies the validity of the vehicle's request. If the request is invalid, it is rejected. If the request is valid, the roadside unit calculates the pseudonym generation parameter pb using the vehicle's public key based on the pre-stored preload factor. i The calculation method is as follows:

[0044] pb i =H2(u i ·V pki )·h i .

[0045] Furthermore, step S35 specifically includes the following steps:

[0046] S351, Roadside Unit (RSU) checks the validity period T of the data packet. i sign If the data packet has expired, the RSU discards the message; otherwise, the RSU further checks the validity period T of the vehicle pseudonym.temp If the identity is invalid, the data packet is discarded; otherwise, the validity of the vehicle alias is verified using the formula:

[0047]

[0048] Verify its validity. If the formula is true, proceed to step S352, where, For pseudonyms, P is the generator of the elliptic curve, {V pki x i} for vehicle V i A The registration key pair, ts i To verify the parameters, this is used to prove that the vehicle's pseudonym was generated under authorization from the KGC and RSU; the H1(·) function represents... The set of all remainders modulo q that are coprime to q is denoted as Zq. * ;u i It is a random number and u i ∈Zq * W i Generate the i-th element in the random vector during the process of KGC generating pseudonyms for authorized vehicles;

[0049] S352, Roadside Unit (RSU) searches its local database for vehicle domain D. i Certificate Authority (CA) i public key C pkj If no record is found locally, the RSU queries the vehicle V from the blockchain of its domain. i A Cert Identity Certificate i ={D i C pkj V pki S i} and based on certificate status S i Verify the validity of the vehicle credential. If invalid, terminate the verification and discard the data. If valid, proceed with vehicle identity verification. The specific verification method is as follows:

[0050]

[0051] Where, σ i For signing, RID i For each vehicle, P is a unique identifier, P is a generator of the elliptic curve, and C is a unique identifier. pkj Key information, V pki For vehicle V i A Registration key information, α i ,β i As an intermediate parameter, the H2(·) function represents For vehicle V i A Temporary identity TID i Components of;

[0052] S353, The verifier uses the timestamp T used to ensure the validity of the message. i sign Verify the validity of messages from each vehicle. If a message has expired, discard it. If it is valid, verify the formula.

[0053]

[0054] If the signature is not valid, the roadside unit verifies the validity of each signature by traversing the process to complete the batch verification of the message. In the formula, ω... i Let the vector ω = {ω1, ω2, ..., ω} be defined. n The elements in}, ω n ∈[1,2 x And x is an integer.

[0055] The present invention has the following beneficial effects:

[0056] (1) High scalability. Based on blockchain technology and considering the storage limitations of a single chain, this invention designs and implements a master-slave chain structure to assist in cross-domain authentication of vehicles. The master-slave multi-chain structure has high scalability, which is beneficial to the expansion of the entire vehicle network.

[0057] (2) High security. The CAMS algorithm proposed in this invention uses a master-slave chain to achieve cross-domain storage and sharing of vehicle data. It introduces pseudonym generation parameters and verification parameters in the authentication process, which can protect against various risk attacks while ensuring vehicle authentication between vehicle network domains.

[0058] (3) High consensus efficiency. The ACGA algorithm proposed in this invention proposes a reputation value calculation method for chain nodes, which quantifies the reputation value of chain nodes based on the consensus latency and consensus results, thereby improving the consensus efficiency of blockchain authentication and the throughput of cross-domain access. Attached Figure Description

[0059] Figure 1 This is a schematic diagram of the cross-domain vehicle identity authentication method based on master-slave multi-chain according to the present invention.

[0060] Figure 2 This is a schematic diagram of a master-slave multi-chain authentication model according to an embodiment of the present invention.

[0061] Figure 3 This is a schematic diagram illustrating the interaction between the vehicle domain and the master-slave chain in an embodiment of the present invention.

[0062] Figure 4 This is a schematic diagram of the ACGA algorithm flow according to an embodiment of the present invention.

[0063] Figure 5 This is a sequence diagram of vehicle registration according to an embodiment of the present invention.

[0064] Figure 6 This is a timing diagram for the generation of pseudonyms in an embodiment of the present invention.

[0065] Figure 7 This is a timing diagram for message signature verification in an embodiment of the present invention. Detailed Implementation

[0066] The specific embodiments of the present invention are described below to enable those skilled in the art to understand the present invention. However, it should be understood that the present invention is not limited to the scope of the specific embodiments. For those skilled in the art, various changes are obvious as long as they are within the spirit and scope of the present invention as defined and determined by the appended claims. All inventions utilizing the concept of the present invention are protected.

[0067] A cross-domain vehicle identity authentication method based on master-slave multi-chain, such as Figure 1 As shown, it includes the following steps:

[0068] S1. Construct a cross-domain authentication model based on master-slave multi-chain, including master chain layer, slave chain layer and vehicle domain layer;

[0069] In this embodiment, the master-slave multi-chain authentication model is a cross-domain authentication model based on master-slave multi-chain, mainly to solve the problems of forgery attacks and authentication efficiency in cross-domain authentication. This model can be divided into a three-layer structure: the master chain layer, the slave chain layer, and the vehicle domain layer.

[0070] The main chain layer, as a trusted sharing platform, serves as a bridge for communication between various vehicle-to-everything (V2X) domains. When vehicles in the V2X need to communicate across domains, they must use the main chain for cross-domain authentication and resolution. The main chain supports data interaction between slave chains of different vehicle domains.

[0071] The slave chain layer can be viewed as a relay station between the main chain layer and the vehicle network domain. Vehicle domains are bound to slave chains, and each vehicle domain interacts with the main chain through its slave chain. Slave chain layer nodes exist in three states: communication state, consensus state, and candidate state. The state change of a chain node is based on its reputation value. Nodes in the communication state are the most trusted nodes and are responsible for communicating with the main chain; nodes in the consensus state actually participate in authentication consensus and block construction; nodes in the candidate state do not participate in the authentication consensus process but store the consensus results and are mainly responsible for data transmission. All newly added nodes are initialized to the candidate state.

[0072] When general data is transferred across blockchain nodes, it can be considered a data transaction. In the context of connected vehicles, this manifests as the storage and retrieval of vehicle data. A transaction is initiated by a node on the slave chain, and after verification by a majority of nodes on the slave chain, a block is created and connected to the slave chain. The slave chain broadcasts this information to the main chain, and after verification by a majority of nodes on the main chain, a new block is generated on the main chain.

[0073] The vehicle domain layer contains vehicles and various communication devices. There are multiple different vehicle domains in this layer. A vehicle domain is a collection of all vehicles registered with the same authentication server. Vehicles need to complete registration or verification on a server in a certain domain before they can access the network of that domain for information communication.

[0074] like Figure 2 As shown, the roles of various entities involved in the vehicle-to-everything (V2X) domain are as follows:

[0075] 1) Trust Provider (TA): The TA is the administrator in the Internet of Vehicles, the maintainer of the master-slave multi-chain, responsible for the management of devices within the domain, the deployment of blockchain nodes, and the tracking of the true identity of vehicles.

[0076] 2) Key Generation Center (KGC): The Key Generation Center (KGC) is unique within the system. It is responsible for managing the key pairs for vehicles and various entities. In this model, the KGC participates in the pseudonym generation process and, together with the RSU, participates in the vehicle pseudonym authorization process to defend against vehicle-initiated forgery attacks.

[0077] 3) Roadside Unit (RSU): The RSU is one of the trusted entities in the cross-domain authentication process. As one of the bridges for communication between the vehicle and the slave chain, it is responsible for processing and distributing the pseudonym generation parameters of the KGC, and verifying vehicle pseudonyms and vehicle identity signatures.

[0078] 4) Certificate Authority (CA): Provides vehicle registration services and maintains vehicle identity certificates. During the registration process, the CA issues a long-term key pair and associated identity certificate to vehicles within its domain, enabling communication with the blockchain and storage and retrieval of vehicle identity certificates.

[0079] 5) Intelligent Terminal (IT): IT mainly includes intelligent terminals such as vehicles and transportation equipment that have communication and data processing capabilities. They support real-time interaction, can store a small amount of data and perform simple calculations, and can collect real-time traffic conditions and broadcast them to other terminals in the vehicle network after signing.

[0080] Before engaging in cross-domain communication, vehicles need to authenticate the identity of the other vehicle. In this model, cross-domain authentication is accomplished using a master-slave blockchain. The interaction process between the vehicle domain and the master-slave blockchain is as follows: Figure 3 As shown, the specific process is as follows:

[0081] S11, Vehicle V i A and V j B Registered in domain D respectively A and Domain D B Each person's identity certificate and other information are stored in D. A SC from chain A and D B SC from chain B In the chain, each storage account address is Addr. vi and Addr vj When V i A Received from V j B The communication message, then V i A Proceed to step S12;

[0082] S12, V i A Connect to the SC of this domain through a trusted entity in the domain. A via V j B Account address Addr vj Check if the vehicle's certificate information exists. If it does, the information can be directly returned to the trusted entity for authentication; otherwise, proceed to step S13.

[0083] S13, Current Domain D A and its continuation chain SC A V does not exist in j B When the certificate information is provided, then SC A Submit a request to the main chain MC, including the registration domain D of the target vehicle. B and account address Addr vj In the main chain MC, according to {D B Addr vj}, towards D B SC B Inquire about account Addr vj If the account exists and is valid, proceed to step S14.

[0084] S14, the main chain MC will come from SC B Data response to SC A , by V i A The trusted entity in the vehicle domain is based on V j B The certificate information is verified, and if the verification is successful, the two parties can proceed to the next step of communication.

[0085] S2. Based on the constructed cross-domain authentication model, use the consensus authentication algorithm to find the optimal consensus decision set;

[0086] In cross-domain authentication, the vehicle-to-everything (V2X) domain layer of the authentication model needs to interact with the secondary chain layer. Vehicle domain data is frequently read and written between the secondary and main chain layers, leading to authentication latency issues. Each authentication transaction in the blockchain (such as the storage of vehicle certificate data) must undergo consensus verification before being written into a new block, which may cause delays in the authentication process. To achieve efficient consensus-based reading and writing of vehicle data in the blockchain, it is urgent to propose an authentication consensus algorithm suitable for cross-domain V2X authentication.

[0087] Current identity authentication research rarely addresses authentication efficiency issues in blockchain-based solutions, often suffering from throughput bottlenecks and high consensus failure rates, leading to inefficient authentication processes. The key to solving these problems lies in a suitable data authentication consensus algorithm. For example, in the PBFT-based authentication process, vehicle data requires three broadcasts: one to the main chain node and two to all chain nodes across the network, ensuring all chain nodes execute vehicle data operations in the same order. Assuming the number of participating chain nodes is N, the total number of messages sent by this algorithm can be represented as 2N. 2 -N. It can be seen that the number of messages in the consensus process increases quadratically with increasing N, and the algorithm's time complexity is O(n^2). 2 In cross-domain vehicle networking scenarios, the system has a wide coverage, a large number of master-slave multi-chain architecture nodes, and frequent consensus processes. Its algorithm time complexity is O(n^2). 2 As can be seen, using traditional authentication consensus algorithms will have a significant negative impact on cross-domain authentication efficiency, leading to problems such as high authentication latency and poor interaction between vehicle domains and master-slave chains.

[0088] Therefore, for the master-slave multi-chain architecture in the Internet of Vehicles (IoV), a genetic authentication consensus algorithm (ACGA) is designed, using consensus efficiency as the fitness function to find the optimal set of participating consensus nodes. In a single authentication consensus process, the more trusted chain nodes participating, the more accurate the authentication consensus result and the higher the efficiency; conversely, the credibility of the authentication result is questionable, and consensus failure will lead to time-consuming processes such as view switching, master node re-election, and re-consensus. Therefore, the credibility of a node is quantified by calculating a reputation value for each node, and chain nodes with high reputation values ​​are selected to participate in the authentication consensus process. The participating chain nodes should consider their own load capacity; if too many computational tasks are given to nodes with high reputation values, it may lead to the node being unable to handle the load or even failing. Meanwhile, for algorithms like PBFT with a time complexity of O(n...)... 2The algorithm should consider the proportion of nodes participating in the authentication consensus, reducing consensus latency while ensuring consensus efficiency. Therefore, there are multiple objective function constraints in calculating the optimal consensus efficiency, which are difficult to solve using ordinary calculation methods. It is advisable to consider finding an approximate value of the optimal solution of the objective function within the constraints.

[0089] Genetic algorithms are a biomimetic computational technique that simulates basic operations such as selection, crossover, and mutation in natural evolution, and can be used to solve multi-constraint problems. In the ACGA algorithm of this invention, the objective function is defined as consensus efficiency, and the solution to the function can be viewed as a set of certified consensus chain nodes. Assuming the blockchain contains m nodes, a set of function solutions can be represented as {x1, x2, x3, ..., x...} m}. x m An element in a set of solutions is mapped to a Node in the chain. m In the genetic algorithm, element x m A gene is a set of m elements, and a chromosome is a set of solutions. This invention encodes chromosomes in binary form, where gene x... m It can be encoded as 0 or 1, representing a Node. m Whether to participate in the consensus process. The ACGA algorithm can advance the entire algorithm's iterative process through mutation and crossover. Mutation refers to the modification of certain genes x. m Making random changes to diversify the population and avoid getting trapped in local optima too early, such as flipping x. m Binary bits allow for the diversification of chromosomes and algorithmic solution sets. Crossover refers to the random exchange of certain genes between two chromosomes to generate new individuals. Crossover can distribute the superior genes of each chromosome... m By combining them, they can produce better offspring, thus driving the emergence of better solutions in the algorithm.

[0090] The ACGA algorithm, through processes such as crossover and mutation, can obtain an approximate value that satisfies the optimal solution of the objective function. The process is as follows: Figure 4 As shown.

[0091] The optimal consensus decision set is selected based on the proportion of nodes participating in the consensus process, the reputation value of chain nodes, and the load of chain nodes. The solution aims to maximize efficiency, with the efficiency P of the authentication process as the objective function. Assume that the reputation value calculation period for chain node a is T. period In a T period Let num be the total number of times node a participates in consensus, where the result of the chain node for the k-th consensus is represented as... The actual result of the k-th consensus is expressed as: when and When the results are consistent, otherwise T represents the ideal consensus time for a node to verify the vehicle's identity. This represents the actual consensus time for chain node a to verify the vehicle's identity for the kth time. `score1` and `score2` represent the reputation value reduced by consensus latency and the reputation value reduced by each consensus failure, respectively. Therefore, a's reputation value `rv` is... a The formula can be represented as follows:

[0092]

[0093] As can be seen from the above formula, when the actual consensus time is less than T, it will have a positive effect on the reputation value of the chain node; otherwise, its reputation value will decrease.

[0094] In each consensus authentication process, we aim to maximize the overall trust value of all participating nodes to improve the success rate and reliability of the consensus result. To minimize the algorithm's time complexity, the number of participating chain nodes should be kept as small as possible within a certain range. The number of participating nodes, n, can be obtained by multiplying the participation ratio ra by the total number of nodes m. If the proportion of participating nodes is too large, it will affect consensus efficiency; if the proportion is too small, the consensus result is prone to errors. Therefore, the proportion ra of participating nodes needs to be considered when selecting the consensus decision set. The consensus process should also consider the load capacity ld of the chain nodes themselves. Nodes with weak load capacity, even if they have high reputation values, should be avoided from participating in the consensus process as much as possible.

[0095] Assume there are m chain nodes in the blockchain. This represents whether chain node i participates in the authentication consensus process. It is a binary number, where 0 represents not participating and 1 represents participating. It consists of m nodes. A set of binary data represents a set of authentication consensus decisions numbered j, which is then processed through... A consensus decision matrix B can be established to represent the set of consensus nodes in each group.

[0096]

[0097] Each row in the consensus decision matrix B represents a consensus decision set. The number of nodes n and the participation ratio ra in the consensus decision set can be expressed as:

[0098] As mentioned above, the optimal consensus decision set needs to be selected by comprehensively considering the proportion of nodes participating in the consensus process, the reputation value of chain nodes, and the load of chain nodes. We will use a genetic algorithm to optimize the set of participating consensus nodes and update the list of actual participating consensus nodes in the cross-domain authentication process based on the optimization results. Taking the efficiency P of the authentication consensus process as the objective function, the process of maximizing efficiency can be expressed as:

[0099]

[0100] stra N ∈[ra min ,ra max ],ld∈[ld min ,ld max ]

[0101] Where {f1,f2,f3} represent weighting factors, and ra min ,ra max To constrain the proportion of participation, ld min ,ld max Constraints on node load; Let ld be the i-th node participating in the consensus, and N be the total number of nodes; i The load of the i-th node participating in consensus; ra N For participation ratio, rv i To calculate the reputation value of the i-th node, the ACGA algorithm is designed to solve the above equation (). The algorithm's multivariate parameter set can be represented as {mg, SC, SP, cr, mr}, representing the number of iterations, chromosome size, population size, crossover rate, and mutation rate, respectively. The algorithm population consists of a certain number of individuals, representing a set of candidate nodes participating in the consensus, and representing one of the candidate solutions among all nodes participating in the consensus. The total number of individuals in the population represents the population size S. p Initial stage S p Randomly generated by the population. A set of nodes participating in consensus can be represented as a binary string. In this system, each 0 or 1 indicates whether a chain node participates in consensus. The chromosome of an individual can be represented as a binary string of m binary numbers, and the state of a chain node can represent a gene. The goal is to find the solution set X = {x1, x2, x3, ..., x...} that maximizes efficiency. m After this, an optimal set of nodes for consensus is obtained. Based on this set X, each chain node can perform corresponding state transitions to achieve authentication consensus.

[0102] S3. Based on the optimal formula found, each chain node performs corresponding state switching and uses a cross-domain vehicle identity authentication algorithm to achieve authentication consensus.

[0103] This embodiment specifically includes the following steps:

[0104] S31. The system is configured to have different vehicle domains {D} A D B D j}, V i A and V j B Represents belonging to domain D A and D B For vehicles numbered i and j, initialize the elliptic curve and the key pair of the trusted device;

[0105] Assume that there are different vehicle domains {D} in the system. A D B D j},,V i A and V j B Represents belonging to domain D A and D B Vehicles numbered i and j. TA and KGC exist throughout the entire vehicle network, and CA exists in each vehicle domain. j The key pairs owned by KGC itself can be represented as {P} pk p sk}, for CA j Generate key pair {C pkj c skj The key pair generated by RSU with ID n can be represented as {R}. pkn r n}. TA chose an additive group G0 of order q, derived from the elliptic curve E p The points on (a, b) and the point at infinity form a group, where a, b ∈ F. p Let p and q be two prime numbers. Let P be the generator of the elliptic curve, and F be the finite field. p Elliptic curve E on p (a,b) can be represented as:

[0106]

[0107] The algorithm first selects two random numbers {s1, s2} ∈ Z by KGC. q * As the system's private key SK, the corresponding two public keys PK can be calculated and represented as P. pub1 =s1·and P pub2 =s²·P. The set of common parameters can be represented as CP = {G0,q,P,P}. pub1 ,P pub2 ,Rpkn It will be announced in the vehicle networking section.

[0108] S32. Assign a unique identification code to each vehicle based on its type and network access time, and issue this code to the Certificate Authority (CA) in the corresponding vehicle domain. j Verify the identity of each vehicle;

[0109] like Figure 5 As shown, in order to uniquely identify vehicles in the system, a unique identification code RID is assigned to each vehicle based on information such as vehicle type and network access time. i ∈G0. In the vehicle domain D j In the middle, vehicle V i Send to administrator CA j Submit RID i Identity information such as vehicle registration certificate, D j CA in j Will be applied to vehicle V i To verify your identity, perform the following steps:

[0110] S321, CA j The key pair is {C pkj c skj}, CA j The vehicle's submitted identity information will be verified. If the vehicle information is valid, then the vehicle will be certified (V). i A Generate a registration key pair {V pki x i Let λ∈Z q * Then the key pair can be represented by the formula:

[0111] x i =H2(RID) i ·λ+C pkj )

[0112] V pki =x i ·P

[0113] Among them, RID i P is the unique code for the vehicle, P is the generator of the elliptic curve, and λ is the random number required by the system company.

[0114] S322, Certificate Authority (CA) j Use the private key for vehicle V i A Generate encryption parameter pa i The vehicle stores this parameter locally. i The following formula can be used to prove vehicle V i It is through CA jThe vehicle is certified and assists in generating signatures in subsequent communications.

[0115] pa i =H2(RID) i )·c skj

[0116] pa i ·P=H2(RID i )·C skj

[0117] S323, Certificate Authority (CA) j For vehicle V i A Generate identity certificate Cert i ={D i C pkj V pki S i}, S i For certificate status, the identity certificate is recorded in the vehicle domain D using the ACGA algorithm. i SC from chain i Above, from chain SC i With V pki and D i Calculate V for raw materials i A storage address Addr vi Ultimately, Addr vi Return to V i A The system queries the vehicle's identity certificate from the chain via the storage address.

[0118] S33. Before each communication, the vehicle requests a pseudonym. When the Roadside Unit (RSU) receives the pseudonym request, it performs vehicle legitimacy verification and pseudonym generation parameter distribution, such as... Figure 6 As shown.

[0119] To prevent the leakage of the private key p during the process of generating aliases for authorized vehicles, the Key Generation Center (KGC) uses this method. sk Generate a preloaded factor h containing a private key based on ECC. n First, generate a random vector W = {w1, w2, ..., w...}. n}, where w n ∈Z q * Let the preload factor h of KGC be n =w n ·p sk h n ∈G0; W n =w n ·P pk Wn If ∈G0, then we obtain the set H = {h1, h2, ..., h}. n}, a certain number of h n Preloaded onto each RSU for subsequent generation of authorized vehicle pseudonyms. As per the ECDLP problem, the RSU cannot parse the private key p from the preloaded factor. sk This method can prevent RSUs from being hijacked and causing p sk Leakage, preventing attackers from using p sk It generates its own pseudonym, rendering identity authentication ineffective.

[0120] To protect the anonymity of the vehicle's identity, in vehicle V i A Before each communication, you need to apply for your own pseudonym. i A Submit a pseudonym request to the nearest RSU The request includes the domain identifier D. id Real Identity RID i The hash value and the current timestamp T req In addition, parameters Used to verify the legitimacy of vehicle requests. When the Roadside Unit (RSU) receives a pseudonym request, it performs vehicle legitimacy verification and distributes pseudonym generation parameters, as shown in the following steps:

[0121] S331, Roadside Unit (RSU) Request from pseudonym Obtain vehicle V from i A The vehicle domain is specified, and a query is made to the chain to retrieve the vehicle's identity certificate (Certificate). i ={D i C pkj V pki S i If the identity certificate does not exist, a cross-domain query for the vehicle's identity certificate (Certificate) is requested from the main chain. i ={D i C pkj V pki S i}

[0122] S332, Verify identity certificate Cert i ={D i C pkj V pki S i Certificate Status S i Is it a valid state? If valid, then proceed using the formula.

[0123]

[0124] The system verifies the legitimacy of the vehicle request. If the request is invalid, it is rejected. If the request is valid, the roadside unit calculates the pseudonym generation parameter pb using the vehicle's public key based on the pre-stored preload factor. i .

[0125] RSU uses the pre-loaded factor stored locally to calculate the pseudonym generation parameter pb using the vehicle's unique public key. i , can be represented as:

[0126] pb i =H2(u i ·V pki )·h i .

[0127] RSU will pb i Send to the vehicle and record the pseudonym authorization. i ={Addr vi V pki ,u i Upload it to the corresponding slave chain for subsequent message verification.

[0128] random number u i ∈Zq * h here o The private key of KGC cannot be forged by RSU, which is used to prevent RSU from being compromised and causing the preload factor h of KGC to be lost. o It has been leaked. Only this pb is obtained in this algorithm. i Only vehicles that meet certain criteria can generate their own pseudonyms.

[0129] Next, the vehicle can calculate the complete pseudonym and the corresponding key, V i A Temporary identity TID i Depend on and It consists of two parts. The vehicle passes through TID i Generate the corresponding private key vsk i The private key is used to sign the message. Private key vsk i Depend on and It consists of two parts. We can represent the temporary identity and vehicle private key as follows:

[0130]

[0131]

[0132] Vehicles pass through random numbers r∈Z q * To generate Furthermore, each communication generates a new 'r' to change the TID. i In order to ensure TID i The uniqueness of the pseudonym and key. Let T be the timestamp for the generation of the pseudonym and key. temp .make Vehicle TID generation i and VSK i The calculation process is as follows:

[0133]

[0134]

[0135] ts i =x i +H1(TID i )·pb i

[0136]

[0137]

[0138] Where the verification parameter ts i The pseudonym used to prove that the vehicle was generated with authorization from KGC and RSU can assist in verification during the message verification phase, preventing attackers from launching attacks on the vehicle network by forging pseudonyms. The calculation process of the above formula is encapsulated as a transaction to ensure the verification parameter ts. i The atomicity of computation and computation of pseudonyms and key pairs.

[0139] S34, Vehicle V i A Initiating with vehicle V i B During communication, first process message M i Perform signature encryption, vehicle V i A Use temporary identity TID i and the corresponding private key vsk i To calculate the signature σ i Calculation method:

[0140]

[0141] Where, β i β is an intermediate parameter. i =h3(T i sign ||M i ||TID i ), T i sign The timestamp is used to ensure the validity of the message. and For the private key vsk i The amount.

[0142] Vehicle V i A Set message Package = {M i Addr vi TID i H i , σ i T i sign , ts i The data packet is sent to the target vehicle, which then forwards it to the RSU for verification. In some emergency situations, it is necessary to trace the V... i A RID's true identity i Then, their true identity can be obtained through TA. The calculation process is as follows:

[0143]

[0144] S35, Vehicle V i A Will contain signature σ i The message is sent to the roadside unit, which performs message verification and uses common parameters to perform batch verification of the signed messages sent by each vehicle.

[0145] In the scenario where a vehicle sends a message to the RSU, vehicle V i A Packet Package = {M i Addr vi TID i H i , σ i T i sign , ts i}Sent to RSU, where T i sign The RSU verification process, representing the validity period of the message, is as follows:

[0146] S351, Roadside Unit (RSU) checks the validity period T of the data packet. i sihn If the data packet has expired, the RSU discards the message; otherwise, the RSU further checks the validity period T of the vehicle pseudonym. temp If the identity is invalid, the data packet is discarded; otherwise, the validity of the vehicle alias is verified using the formula:

[0147]

[0148] Verify its validity. If the formula is true, proceed to step S352, where, For pseudonyms, P is the generator of the elliptic curve, {V pki x i} for vehicle V i A The registration key pair.

[0149] Roadside Unit (RSU) searches its local database for vehicle domain D i Certificate Authority (CA) i public key C pkj If no record is found locally, the RSU queries the vehicle V from the blockchain of its domain. i A Cert Identity Certificate i ={D i C pkj V pki S i} and based on certificate status S i Verify the validity of the vehicle credential. If invalid, terminate the verification and discard the data. If valid, proceed with vehicle identity verification. The specific verification method is as follows:

[0150]

[0151] Where, σ i For signing, RID i For each vehicle, P is a unique identifier, P is a generator of the elliptic curve, and C is a unique identifier. pkj Key information, V pki For vehicle V i A Registration key information, α i ,β i This is an intermediate parameter.

[0152] S353, RSU according to S i Verify the validity of the vehicle credential. If invalid, terminate the verification and discard the data packet; if valid, the RSU will process the vehicle credential. i A Identity verification is performed using the following formula:

[0153]

[0154] Whether it is true or not, if not, vehicle V i A If the verification fails, the data packet is discarded, where σ i For signing, RID i For each vehicle, P is a unique identifier, P is a generator of the elliptic curve, and C is a unique identifier. pkjKey information, V pki For vehicle V i A Registration key information, α i ,β i This is an intermediate parameter.

[0155] The above formula can be derived as follows.

[0156]

[0157] To reduce system computation, multiple messages are quickly batch-verified. Assume the verifier receives n messages from various vehicles. The verifier uses the public parameter CP = {G0, q, P, P} pub1 ,P pub2 ,R pkn} to verify these messages. If the equation is not true, RSU i Each signature is verified individually to determine its validity. Therefore, this batch verification significantly reduces verification latency, especially when verifying a large number of signatures. From the batch verification equation above, it's clear that the time required for a vehicle to verify a large number of signatures sent by surrounding vehicles can be significantly reduced, which obviously lowers the message loss rate due to the potential bottleneck of vehicle signature verification.

[0158] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0159] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0160] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0161] Specific embodiments have been used to illustrate the principles and implementation methods of this invention. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this invention. Therefore, the content of this specification should not be construed as a limitation of this invention.

[0162] Those skilled in the art will recognize that the embodiments described herein are intended to help the reader understand the principles of the invention, and should be understood that the scope of protection of the invention is not limited to such specific statements and embodiments. Those skilled in the art can make various other specific modifications and combinations based on the technical teachings disclosed in this invention without departing from the spirit of the invention, and these modifications and combinations are still within the scope of protection of this invention.

Claims

1. A cross-domain vehicle identity authentication method based on master-slave multi-chain, characterized in that, Includes the following steps: S1. Construct a cross-domain authentication model based on master-slave multi-chain, including master chain layer, slave chain layer and vehicle domain layer; S2. Based on the constructed cross-domain authentication model, the optimal consensus decision set is found using a consensus authentication algorithm. Specifically, the optimal consensus decision set is selected based on the proportion of nodes participating in the consensus process, the reputation value of chain nodes, and the load of chain nodes. The solution is to maximize the efficiency P of the authentication process as the objective function. The specific solution process is as follows: in,{ } represents the weighting factor. To constrain the proportion of participation, Constraints on node load; Let N be the i-th node participating in the consensus, and N be the total number of nodes. For the first to participate in the consensus The load of each node; Let be the reputation value of the i-th node and In the formula, The ideal consensus time for a node to verify the vehicle's identity is given by k, where k is the k-th consensus iteration and num is the total number of consensus iterations. For the first The actual consensus time for the k-th verification of vehicle identity by each node. This represents the actual result of the k-th consensus. For the chain node pair k The result of this consensus The reputation value reduced due to consensus delay. The reputation value lost for each consensus failure; The participation ratio is the proportion of nodes that participate in the consensus process when selecting a consensus decision set. Solving the objective function, the algorithm's multivariate parameter set is represented as { mg , SC , SP , cr , mr } represents the number of iterations, chromosome size, population size, crossover rate, and mutation rate, respectively; the algorithm population consists of multiple individuals, each representing a set of candidate nodes participating in the consensus, representing one of the candidate solutions among all nodes participating in the consensus scheme; the total number of individuals in the population represents the population size. Initial stage Randomly generated from the population, a set of nodes participating in consensus is represented as a binary string. In this context, each 0 or 1 represents whether a chain node participates in consensus. The chromosome of this individual can be represented as... Given a binary string consisting of binary numbers, where the state of each node in the chain represents a gene, find the solution set that maximizes efficiency. X ={ x 1, x 2, x 3,…, x m After that, an optimal set of nodes participating in the consensus was obtained, and based on this set... X Each chain node can switch its state accordingly to achieve authentication and consensus. S3. Based on the found optimal consensus decision set, each chain node switches between the communication state, consensus state, and alternative state accordingly, and uses a cross-domain vehicle identity authentication algorithm for authentication consensus. The specific method is as follows: S31. Different vehicle domains exist in the system. , Belongs to domain D j The Chinese number is i The vehicle initializes the elliptic curve and the key pair of the trusted device; S32. Assign a unique identification code to each vehicle based on its type and network access time, which is then issued by the Certificate Authority in the corresponding vehicle domain. CA j The authentication process is performed on each vehicle within the vehicle domain, specifically as follows: S321, Certificate Authorization Center CA j The key pair is { C pkj , c skj }, CA j The system will verify the identity information submitted by the vehicle. If the vehicle information is valid, a registration key pair will be generated for the vehicle. V pki , x i }, represented as: in, A unique code for the vehicle. Let be the generator of the elliptic curve. A random number generated using the system's public and private keys; This is the vehicle's registered public key. x i Its corresponding private key; For vehicle domain D j Certificate Authorization Center CA j The public key; S322, Certificate Authority CA j Use the private key to generate encrypted parameters for the vehicle. pa i The vehicle stores this parameter locally; S323, Certificate Authority CA j Generate an identity certificate for the vehicle Cert i ={ D j C pkj , V pki , S i }, S i For certificate status, the authentication consensus result of the optimal consensus decision set of identity certificates is recorded in the vehicle domain. D j from chain SC j Up, from the chain SC j by V pki and D j Calculate the storage address of the vehicle for the raw materials. Ultimately Returning to the vehicle, query the vehicle's identity certificate from the blockchain using the storage address; S33. Before each communication, the vehicle requests a pseudonym. When the Roadside Unit (RSU) receives the pseudonym request, it performs vehicle legitimacy verification and pseudonym generation parameter distribution, specifically as follows: S331, Roadside Unit (RSU) Request from pseudonym The system retrieves the vehicle domain to which the vehicle belongs and requests the vehicle's identity certificate from the chain. Cert i ={ D j C pkj , V pki , S i If the identity certificate does not exist, a cross-domain query for the vehicle's identity certificate will be requested from the main chain. Cert i ={ D j C pkj , V pki , S i }; S332, Verify Identity Certificate Cert i ={ D j C pkj , V pki , S i Certificate Status S i Is it a valid state? If valid, then proceed using the formula. in, For the generators of the elliptic curve, For pseudonym requests, verify the validity of the vehicle request. If invalid, reject the pseudonym request; if valid, the roadside unit uses a pre-stored preload factor. Preload factor It contains the vehicle's private key, used to authorize the generation of vehicle aliases. The alias generation parameters are calculated using the vehicle's own public key. The calculation method is as follows: In the formula, are random numbers and , Generate parameters for the pseudonyms; S34, When a vehicle initiates communication, it first checks the message. M i The signature is encrypted, and the initiating vehicle uses a temporary identity. and corresponding private key To calculate signature The calculation method is as follows in, For intermediate parameters, , The timestamp is used to ensure the validity of the message. and For private key The amount, M i Messages for communication between vehicles; S35, the vehicle will include a signature. The message is sent to the roadside unit, which performs message verification and uses common parameters to perform batch verification of the signed messages sent by each vehicle. The specific steps include the following: S351, Roadside Unit (RSU) checks the validity period of data packets. If the data packet has expired, the RSU discards the message; otherwise, the RSU further checks the validity period of the vehicle pseudonym. T temp If the identity is invalid, the data packet is discarded; otherwise, the validity of the vehicle alias is verified using the formula: Verify its validity. If the formula is true, proceed to step S352, where, Requesting a pseudonym Let { be the generator of the elliptic curve, { V pki , x i } is the vehicle's registration key pair. To verify the parameters, used to prove that the vehicle's pseudonym was obtained through... KGC and RSU Authorization generation; H 1( ) function representation The set of all remainders modulo q that are coprime to q is denoted as . ; are random numbers and ; for KGC During the process of generating pseudonyms for authorized vehicles, the i-th element in the random vector is generated; S352, the Roadside Unit (RSU) searches its local database for vehicle domains. D j Certificate Authorization Center CA j public key C pkj If there is no record in the local machine, RSU Retrieve the vehicle's identity certificate from the blockchain of its domain. Cert i ={ D j C pkj , V pki , S i } and based on certificate status S i Verify the validity of the vehicle credential. If invalid, terminate the verification and discard the data. If valid, proceed with vehicle identity verification. The specific verification method is as follows: in, For signature, A unique code for the vehicle. Let be the generator of the elliptic curve. Key information, This is the vehicle's registered public key. For intermediate parameters, For the public key of the key generation center KGC, H 2( ) function representation , Temporary identity for the vehicle Components of; S353, The verifier uses a timestamp to ensure the message's validity. Verify the validity of messages from each vehicle. If a message has expired, discard it. If it is valid, verify the formula. If the signature is invalid, the roadside unit verifies each signature by traversing the process to complete batch message verification. In the formula, To define a vector The elements in and It is an integer.

2. The cross-domain vehicle identity authentication method based on master-slave multi-chain as described in claim 1, characterized in that, The main chain layer is a trusted sharing platform. When vehicles in the vehicle domain layer need to perform cross-domain communication, cross-domain authentication and resolution are performed through the main chain. The slave chain layer is a transit station between the main chain layer and the vehicle domain layer, and the vehicle domain layer and the slave chain layer are bound to each other. Each vehicle domain in the vehicle domain layer interacts with the main chain layer through the slave chain in the slave chain layer. The vehicle domain layer includes vehicles and communication devices. There are multiple different vehicle domains in this layer. Vehicles need to register or be verified on a server in a certain domain before they can access the network of that domain for information communication.

3. The cross-domain vehicle identity authentication method based on master-slave multi-chain as described in claim 2, characterized in that, The specific interaction methods between each vehicle domain and the main chain layer through the slave chain in the slave chain layer are as follows: S11, Vehicles and Registered in the domain D A Heyu D B Each individual's identity certificate information is stored in the vehicle domain. D A from chain SC A and vehicle domain D B from chain SC B In the chain, each storage account address is... and ,when Received from The communication message, Proceed to step S12; S12, Connect to this domain through trusted entities in the current domain. SC A ,pass account address Check if the vehicle's certificate information exists. If it does, the information can be directly returned to the trusted entity for authentication; otherwise, proceed to step S13. S13, Current Domain D A and its chain SC A It does not exist in When the certificate information is available, then SC A To the main chain MC Submit a request containing the registration domain of the target vehicle. D B and account address In the main chain MC According to ,Towards D B of SC B Inquire about account If the account exists and is valid, proceed to step S14. S14, Main Chain will come from SC B Data response to SC A ,Depend on Trusted entities in the vehicle domain The certificate information is verified, and if the verification is successful, the two parties can proceed to the next step of communication.

Images