A cross-domain authentication method for integrated space-ground vehicle networking based on alliance blockchain

Abstract

The present invention relates to the field of information network security, and in particular to a cross-domain authentication method for a space-ground integrated vehicle network based on a consortium blockchain, comprising: a vehicle, a satellite and a roadside unit respectively registering to obtain a private key and calculating a public key; if the vehicle is connected to the space-ground integrated vehicle network for the first time, when the vehicle enters the communication range of the roadside unit, it is authenticated through consensus verification or batch authentication, and if it passes, network services are provided for the vehicle nodes; if the batch authentication of the vehicle message fails, the malicious node is traced back; the present invention uses a conditional anonymous ring signature to sign the message, and realizes the security and integrity of information transmission by hiding the real identity in the ring members.

Description

Technical Field

[0001] The present invention relates to the field of information network security, and more particularly to a cross-domain authentication method for a space-ground integrated vehicle networking based on a consortium blockchain. Background Art

[0002] With the development of the automotive industry, the number of motor vehicles in use has been growing rapidly. How to use some technological means to coordinate among various means of transportation to reduce traffic accidents and alleviate traffic congestion has become an unavoidable issue at present. Therefore, in order to coordinate the orderly passage of vehicles, in combination with the rapidly developing network in the current environment, a vehicular ad hoc network (VANET) has emerged, that is, the vehicle networking realizes the intelligent information interaction between vehicles and everything (Vehicle-to–everything, V2X) by carrying sensors and other devices. A typical VANET network communication model usually consists of two layers, namely the roadside unit RSU at the bottom layer and the vehicle, and the trusted center TA at the upper layer. Among them, the vehicles at the lower layer communicate with the RSU or between vehicles through dedicated short-range communication technology DSRC or V2X technology C-V2X based on cellular communication, which can improve the traffic flow efficiency.

[0003] However, there are still security risks in the operation of vehicles with these two mainstream wireless communication methods. For example, Tencent Keen Lab directly obtained the permission of the in-vehicle electrical network (CAN bus) that controls the driving system of Tesla in a remote and physically contactless manner; Baidu successfully achieved remote control of the vehicle by cracking into the WIFI and mobile communication networks of the in-vehicle T-BOX. Therefore, realizing the communication security between the lower-layer vehicles and the RUS or between vehicles in an open VANET network has become a hot topic in the research on vehicle networking security.

[0004] Since realizing the communication security of VANET must meet basic requirements such as authenticity, authorization, availability, data confidentiality, and data integrity to resist various attacks. Therefore, in order to meet the communication security requirements of the vehicular ad hoc network, the current mainstream solution is to adopt the mechanism of a mutual trust authentication protocol. The mutual trust authentication protocol mechanism is to obtain a digital certificate from the certificate center when the vehicle accesses the network, generate a signature for the data using a digital signature algorithm before sending the data, and use the methods of certificate differentiation and revocation for identity authentication. However, due to the rapid and dynamic network topology change of the vehicle networking and the huge number of VANET messages, in order to ensure data security, authentication needs to be performed frequently during the communication process, resulting in low communication efficiency, data congestion, and further blocking the vehicle flow. Summary of the Invention

[0005] In view of the problems existing in the above prior art, in order to reduce the number of cross-domain authentication interactions, reduce the cross-domain authentication delay and computing overhead, and ensure the security of the vehicle authentication process at the same time, the present invention proposes a cross-domain authentication method for the space-ground integrated vehicle network based on the consortium blockchain, which specifically includes:

[0006] S1. The vehicle, satellite, and roadside unit respectively send information carrying their inherent identities to the trusted center for registration. The trusted registration center distributes information for generating private keys to the registered devices. The vehicle, satellite, and roadside unit generate private key sk i and calculate public key pk i ;

[0007] S2. After completing the registration, when the vehicle is accessing the space-ground integrated vehicle network for the first time, when the vehicle enters the communication range of the roadside unit, the vehicle executes the signature algorithm to generate a signature message, and sends the signature message to the roadside unit for initial authentication. If the authentication is passed, the roadside unit will initiate a consensus to record the pseudonym on the block and provide network services for the vehicle;

[0008] S3. If consensus verification is to be performed, the roadside unit sends a request to the satellite node. The satellite, as the primary node, collects the information sets in each stage of the consensus to complete the consensus process. If the consensus fails, a satellite is reselected through the view conversion protocol, and it returns to step S2 to determine whether cross-domain authentication is to be performed;

[0009] S4. If the consensus verification is successful, the satellite broadcasts the newly generated area to other roadside units and the current roadside unit provides network services for the vehicle;

[0010] S5. When the vehicle is not accessing the space-ground integrated vehicle network for the first time, when the vehicle enters the communication range of other roadside units, the vehicle and the roadside unit need to perform cross-domain authentication. When the timestamp carried by the vehicle is within the critical value and the pseudonym used by the vehicle is stored on the blockchain, the roadside unit determines whether the batch authentication of the legal vehicle road information in other domains passes. If it passes, network services are provided for the vehicle node;

[0011] S6. When the timestamp is not within the critical value, or the pseudonym is not stored on the blockchain, or the batch authentication of the vehicle message fails, the malicious node is traced back.

[0012] Further, if the current vehicle is within the coverage of an unauthenticated roadside unit, cross-domain authentication needs to be performed. When performing cross-domain authentication, the on-vehicle unit selects a pseudonym T and signs it using the ring signature algorithm, selects a ring member R to provide identity endorsement for the pseudonym T, and sends the signature message to the roadside unit for authentication, which specifically includes the following steps:

[0013] The trusted registration center sets the system security factor η and generates a sufficiently large safe prime number q;

[0014] Select an elliptic curve additive cyclic group G 1 and a multiplicative cyclic group G 2 , both cyclic groups having the same order q;

[0015] Set a bilinear mapping, The generator of G1 is P, H 0 :{0,1} * →G 1 and H 1 :{0,1} * →Z q are two secure hash functions, H 0 :{0,1} * →G 1 represents mapping an arbitrary length sequence composed of 0 and 1 to G 1 This mapping process is the first hash function H 0 (), H 1 :{0,1} * →Z q represents mapping an arbitrary length sequence composed of 0 and 1 to the finite field Z q This mapping process is the second hash function H 1 ().

[0016] Furthermore, if the current vehicle is within the coverage of an unauthenticated roadside unit, cross-domain authentication is required. When performing cross-domain authentication, the on-vehicle unit selects a pseudonym T and signs it using the ring signature algorithm, selects a ring member R to provide an identity endorsement for the pseudonym T, and sends the signed message to the roadside unit for authentication, which specifically includes the following steps:

[0017] The on-vehicle device randomly selects an integer t, t←Z * g and calculates the pseudonym T based on t and the generator P; afterwards, the vehicle selects the ring member R = pk 1 ||pk 2 …||pk n ;

[0018] Take a random number r 0 ←{0,1} S , calculate ω 0 , ω 1 , then ω 0 , ω 1 and the private key sk of this vehicle k are used to calculate the identity information ρ through a linear mapping;

[0019] Use to prove contains the private key of the corresponding vehicle without exposing the corresponding identity information, and sends the full signature σ = (ρ, r 0 , π 1 ) and (R, T) as a request for anonymous authentication to the roadside unit for verification;

[0020] After receiving the authentication request, the roadside unit parses out π 1 , extracts the parameters required for the calculation process, and verifies according to the public key of the vehicle and whether it holds;

[0021] If the equation holds, the roadside unit packages the verification information to generate a transaction and sends it to the satellite node, records the pseudonym of the vehicle on the blockchain, and initiates a consensus process; if it does not hold, it refuses to provide services to the vehicle;

[0022] Among them, Z * g represents a finite field; pk 1 ,..., pk n represents the public key; S represents the length of the random number r 0 ; M represents the intermediate parameter obtained by bilinear calculation of the generator and the random number; N represents the intermediate parameter obtained by bilinear calculation of the value obtained by passing the pseudonym and the ring members through two secure hash functions; U i represents the result of summing the public key of member i and the public keys of other members in the ring; h i represents the hash value of a fixed length calculated according to the secure hash function for the i-th member in the ring and the current member's pseudonym; e represents the intermediate parameter obtained by summing the private key and the random number; is a bilinear mapping function.

[0023] Furthermore, the process of conducting consensus includes:

[0024] After receiving the request, the satellite node assigns a sequence number z to the message m, attaches a timestamp st, and then broadcasts it to other roadside unit nodes in the roadside unit node set E within its coverage area. At this time, the roadside unit acts as a consensus node;

[0025] The format of the pre-prepare message is <<Pre-Prepare, v, z, (R, T), σ, st>sp, m>, where v represents the view number when the message is sent, σ is the full signature, sp represents the signature of the satellite node, st represents the timestamp, and z represents the message serial number;

[0026] If node i in set E receives a pre-prepare message from a satellite node, the node will enter the preparation phase and reply with a Prep-prepare message to the primary node; the format of the replied Prep-prepare message is <Prepare,v,z,R,T),σ,i> si , where si is the signature of node i;

[0027] When the satellite node receives 2f Prep-prepare messages from nodes, it will broadcast a Prep-Collect message to other consensus nodes. The format of the Prep-Collect message is <Prepare-Collect,Θ 1 ,v,st> sp , where Θ 1 is the set of 2f messages received by the primary node;

[0028] After receiving the Prep-Collect message, node i verifies the signature of the message and checks the number. It verifies whether there are 2f different prepare messages in set Θ 1 . If the node signatures and view numbers obtained from the verification in the Prepare message are correct, it means that the message digest and sequence number are the same as the pre-prepare message received by the current node, and the node number in the message is in the current consensus node set E. Then this Prepare message passes the verification;

[0029] In the commit phase, each node needs to send a Commit message to the primary node p in the format of <Commit,v,z,d,i> si , where d is the digest of message m;

[0030] When the primary node p receives 2f + 1 messages with the same digest d, view number v, and sequence number z from different consensus nodes including itself, the primary node will broadcast a Commit-Collect message to all consensus nodes, expressed as <Commit-Collect,Θ 2 ,v,st> sp , where Θ 2 represents the set of 2f + 1 Commit messages;

[0031] After receiving the Commit-Collect message, consensus node i verifies whether there are 2f + 1 correct Commit messages sent by different consensus nodes. After successful confirmation, it adds the block to the local blockchain to complete the consistency process; otherwise, the satellite node p broadcasts a prepare timeout message to other consensus nodes. The message format is <Prepare-Timeout,v,st> sp , and the consensus fails.

[0032] Furthermore, the batch authentication of vehicle messages includes:

[0033] When the pseudonym T of vehicle k k is recorded in a block of the blockchain and the block is still within the valid time, vehicle k can use the Merkle tree path path=(hash 2 , hash 34 , hash 5678 ) stored in the blockchain to prove the validity of the pseudonym;

[0034] The roadside unit receives multiple different message signature tuples from different vehicles, expressed as:

[0035] (PID 1 , M 1 , PK 1 , σ 1 , t 1 ), (PID 2 , M 2 , PK 2 , σ 2 , t 2 ),..., (PID n , M n , PK n , σ n , t n ). It checks the timestamps, including the timestamp T i of the pseudonym PID i and the timestamp t i of the message signature tuple, and after the pseudonym PID i stored on the consortium blockchain, the RSU uses params, M i , PID i , PK i , and σ i to calculate h i = H 0 (PID i , A i , P pub ) and j i = H 1 (M i , PID i , A i , PK i , P pub , t i ) and determines whether holds. If it holds, the verifier accepts the signature σ i on the message M i , otherwise it rejects, completing the batch authentication;

[0036] Among them, Ai Denotes an intermediate parameter obtained by multiplying a random number in the finite field Z * g by a generator; P pub Denotes the public key obtained in the initialization phase; R i Denotes one of the R's generated during initialization, where R contains n members.

[0037] Furthermore, the process of tracing malicious nodes is as follows:

[0038] When a vehicle misbehaves, the trusted center sends a disclosure request to each member of the ring signature and sends the signature σ = (ρ, r 0 , π 1 ), (R, T) to each member of the ring; after receiving the information, the ring members respectively execute the signature admission algorithm and the signature denial algorithm to disclose the true identity of the signer. Except for the real signer, non-signers can execute the signature denial algorithm to prove that the ring signature was not generated by this node.

[0039] After executing the ring signature admission algorithm, (π 2 = (M', N', e), ρ') is sent as response information to the satellite.

[0040] Furthermore, the signature denial algorithm includes: The vehicle uses its own private key, and ω 0 calculated by the hash function, ω 1 has been linearly mapped to calculate ρ', and (π 2 , ρ') generated by the signature admission algorithm is sent to the trusted center. After receiving these evidences, it is judged and whether they hold. When both equations hold, if ρ = ρ', it indicates the real signer.

[0041] Compared with the prior art, the present invention improves the communication security and efficiency of the vehicular ad hoc network, specifically including the following points:

[0042] 1) The present invention adopts a data storage method based on the consortium blockchain. Each regional RSU forms a consortium blockchain network, and two-way authentication is performed between the RSU and the vehicle; relying on the characteristics of the consortium regional chain that does not rely on a trusted third party and is traceable, each RSU node in the VANET can effectively trace the information of malicious nodes and timely stop the malicious spread of false messages, which can effectively ensure system security;

[0043] 2) Use conditional anonymous ring signature to sign messages, and realize the security and integrity of information transmission by hiding the real identity among the ring members;

[0044] 3) An optimized PBFT consensus mechanism is adopted to improve the efficiency of block verification and chain - up in the consortium blockchain; the aerial nodes are designated as the primary nodes, and the roadside units in the traditional ground network are the secondary nodes. In the next period T, after receiving a certain amount of transactions, the primary node will first verify the transactions, then package these transactions into a block b, and send it to all consensus nodes, and guide other consensus nodes to execute the consensus process to generate a new block and quickly broadcast it to the RSUs within the coverage area. By reducing the communication overhead of O(n2) to O(n), the efficiency of block consensus verification and the speed of block propagation are improved, so as to achieve the purpose of ensuring communication efficiency;

[0045] 4) In the process of conditional anonymous ring signature authentication, a batch authentication method is adopted. Through the batch signature verification function, multiple signatures of multiple traffic - related messages generated by different vehicles are verified simultaneously, thus improving the authentication efficiency. Brief Description of the Drawings

[0046] Figure 1 It is a schematic flow chart of a cross - domain authentication method for a space - ground integrated vehicle - to - everything network based on a consortium blockchain of the present invention;

[0047] Figure 2 It is a schematic flow chart of generating a block from the initiation of consensus to the end of consensus verification of the present invention;

[0048] Figure 3 It is a structure diagram of the consortium chain data storage adopted by the present invention. Detailed Embodiment

[0049] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0050] The present invention proposes a cross - domain authentication method for a space - ground integrated vehicle - to - everything network based on a consortium blockchain, which specifically includes:

[0051] S1. Vehicles, satellites, and roadside units respectively send information carrying their inherent identities to the trusted center for registration. The trusted registration center will distribute information for generating private keys to the registration devices. Vehicles, satellites, and roadside units generate private keys sk i , and calculate public keys pk i ;

[0052] S2. After completion of registration, when the vehicle is accessing the space-ground integrated vehicle network for the first time, when the vehicle enters the communication range of the roadside unit, the vehicle executes a signature algorithm to generate a signature message, and sends the signature message to the roadside unit for initial authentication. If the authentication is passed, the roadside unit will initiate a consensus to record the pseudonym on the blockchain and provide network services for the vehicle;

[0053] S3. If consensus verification is to be performed, the roadside unit sends a request to the satellite node. The satellite, as the primary node, collects the information sets in each stage of the consensus to complete the consensus process. If the consensus fails, a satellite is reselected through the view conversion protocol, and it returns to step S2 to determine whether cross-domain authentication is to be performed;

[0054] S4. If the consensus verification is successful, the satellite broadcasts the newly generated area to other roadside units and the current roadside unit provides network services for the vehicle;

[0055] S5. When the vehicle is not accessing the space-ground integrated vehicle network for the first time, when the vehicle enters the communication range of other roadside units, the vehicle and the roadside unit need to perform cross-domain authentication. When the timestamp carried by the vehicle is within the critical value and the pseudonym used by the vehicle is stored on the blockchain, the roadside unit determines whether the batch authentication of the legal vehicle road information in other domains passes. If it passes, network services are provided for the vehicle node;

[0056] S6. When the timestamp is not within the critical value, or the pseudonym is not stored on the blockchain, or the batch authentication of the vehicle message fails, the malicious node is traced.

[0057] In this embodiment, the authentication process is divided into 5 stages, specifically including:

[0058] Registration stage. Before the vehicle node first enters the space-ground integrated vehicle network, the vehicle and the RSU complete registration at the TA to generate the initial system parameters; such as Figure 1 the initialization of the system parameters in;

[0059] Authentication stage. The OBU selects a pseudonym T and signs using the ring signature algorithm, selects a ring member R to provide an identity endorsement for the pseudonym, and then sends the signature message to the RSU; specifically, as Figure 1 in, it is judged whether the terminal device is registered. The registration behavior is the process of obtaining a pseudonym and an identity endorsement. When the terminal device is in the registration process, that is, the OBU selects a pseudonym T and signs using the ring signature algorithm, and selects a ring member R to provide an identity endorsement for the pseudonym;

[0060] In the consensus verification stage, the RSU uses an improved PBFT consensus algorithm to verify the data block and then upload it to the blockchain. At this time, the OBU is a legal vehicle within the RSU. If the vehicle node moves from the coverage area of the current RSU to the coverage area of the next RSU, it needs to be re-authenticated when communicating with a pseudonym within the coverage area of the next RSU. Specifically, as Figure 1 , after the vehicle sends a road message to the RUS, the RUS needs to determine whether the current vehicle node needs to be authenticated, that is, if the vehicle node has been authenticated in the current RUS, it does not need to be authenticated, and if it has not been authenticated in this RUS, it needs to be authenticated; if the current vehicle does not need to perform cross-domain authentication, consensus verification is performed. If the consensus is successful, the regional chain broadcasts and provides network services for the vehicle node. If the consensus fails, a satellite node is reselected through the view conversion protocol, and it continues to determine whether to perform cross-domain authentication; the process from initiating consensus to the end of consensus verification to generate a block is as Figure 2 shown, specifically including the following steps:

[0061] 101. Update the node status and block information according to the result of the previous round of consensus;

[0062] 102. The satellite node selects consensus nodes according to the node status to form a consensus set;

[0063] 103. The satellite, as the primary node, packages and broadcasts the unconfirmed block to the consensus nodes;

[0064] 104. Execute the three-phase consensus. If the consensus is successful, all nodes synchronize the new block information;

[0065] 105. If the consensus fails, execute the view conversion protocol to convert the primary node, and after converting the primary node, return to step 103;

[0066] Those skilled in the art can choose any consensus algorithm in the prior art according to actual needs for the above consensus process, and the present invention does not limit the specific consensus algorithm.

[0067] In the cross-domain authentication stage, the identity authentication for vehicles when crossing regions is divided into two parts. On the one hand, the roadside unit needs to verify the identity information of the vehicle node. In this part, the RSU determines the validity of the pseudonym by verifying the Merkle tree path path stored in the blockchain for the pseudonym used by the OBU. On the other hand, the authenticity of the cross-region message must also be verified by the RSU. In this part, the RSU batch-authenticates the signature messages of legal vehicles to determine the validity of the OBU cross-domain message and further confirm the authenticity of the OBU identity. Specifically, as Figure 1, if cross - domain authentication is required, first check whether the timestamp is within the critical value and whether the pseudonym is stored on the blockchain. If so, perform batch authentication of vehicle messages. After the vehicle batch authentication passes, provide network services to the vehicle node; otherwise, it is considered that there is a malicious node in the network and trace the malicious node. In the tracking completion stage, if there is user misbehavior or a dispute event, start the tracking completion stage, and the members of the joint ring will expose the true identity of the user by each node executing the denial algorithm and the recognition algorithm in the ring signature algorithm, and end the process.

[0068] In this embodiment, the above - mentioned stages are described in detail respectively. In the registration stage, before the vehicle node first enters the space - ground integrated vehicle network, the vehicle, RSU, and satellite complete registration at a trusted registration center. The trusted registration center only manages the registration and regular update or distribution of vehicle identities and does not participate in the subsequent authentication process. After registration, the necessary system initial parameters, security parameters, and large prime numbers are generated, and a cyclic group, a hash function, and a bilinear mapping are selected. Specifically, it includes:

[0069] 1) The trusted registration center sets the system security factor η and generates a sufficiently large safe prime number q;

[0070] 2) Select an elliptic curve additive cyclic group G 1 and a multiplicative cyclic group G 2 , and both cyclic groups have the same order q;

[0071] 3) Set a bilinear mapping, The generator of G1 is P, H 0 :{0,1} * →G 1 and H 1 :{0,1} * →Z q are two secure hash functions, where Z q is a finite field.

[0072] After registration, the OBU selects a pseudonym T and signs it using the ring signature algorithm, selects ring members R to provide identity endorsement for the pseudonym to ensure the validity of the pseudonym, and then sends the signed message to the RSU. This process specifically includes:

[0073] 1) User k randomly selects an integer t←Z * g and calculates T = t·P as the pseudonym, where P is the generator; then, selects ring members R = pk 1 ||pk 2 …||pk n and pk k ∈R.

[0074] 2) Take a random sequence r 0←{0, 1} S , {0, 1} S denotes r 0 is a sequence consisting of 0 and 1 with length S, and then calculate:

[0075] ω 0 = H 0 (0, r 0 , T, R)

[0076] ω 1 = H 1 (1, r 0 , T, R)

[0077]

[0078] H 0 :{0, 1} * →G 1 , H 1 :{0, 1} * →Z q , in cryptography, H 0 denotes mapping a message of any length to an element in G1. In this embodiment, H 0 () means mapping after concatenating each element in the parentheses. H 1 denotes mapping a message of any length to an integer in a Z q . Similarly, in this embodiment, H 1 () means mapping after concatenating each element in the parentheses.

[0079] 3) Take a random number r, a random number r 1 ←Z q , and calculate and where the random number r needs to be a sufficiently large prime number. In this embodiment, randomly select a prime number greater than 10000;

[0080] 4) Take U i ←G 1 , where i ∈ {1, 2,..., n}, i ≠ k, and calculate h i = H 1 (T, M, N, S, ρ, U i );

[0081] 5) Calculate:

[0082] U k = r 1 ·pk k - ∑ i≠k (U i + h i·pk i -h i ·pk k )

[0083] h i =H 1 (T, M, N, S, ρ, U i )

[0084]

[0085] 6) Use to prove contains the corresponding pk k ∈R private key without exposing pk k corresponding identity information; the full signature σ = (ρ, r 0 , π 1 ) and (R, T) are sent to the satellite node as a request for anonymous authentication to initiate the consensus verification process.

[0086] Forwarded by the RSU to the consensus initiating node (satellite) to apply for storing the record in the blockchain, and then the satellite node broadcasts the request to other RSU nodes for consensus verification. After the consensus is reached, the identity endorsement provided by the ring members for the OBU pseudonym is stored on the chain. At this time, the OBU is a legal vehicle within the RSU and can use the various services of the RSU normally with the pseudonym. After that, as the vehicle node moves, it will move from the coverage area of the current RSU to the coverage area of the next RSU. When using the pseudonym for communication within the coverage area of the next RSU, re-authentication is required, specifically including:

[0087] 1) Preparation stage

[0088] In the pre-preparation stage, the primary node assigns a sequence number z to the message m and attaches a timestamp st, and then broadcasts it to other consensus nodes in the valid node set E. The format of the pre-prepare message is <<Pre-Prepare, v, z, (R, T), σ, st>sp, m>, that is, the satellite node signs the current message format (the message format in this stage is pre-prepare, that is, the pre-preparation stage), the view number v when the message is sent, the sequence number z of the message m by the primary node, the combination (R, T) of the ring members and the pseudonym, the full signature σ, the timestamp st using the signature sp of the satellite node, and together with the message m as the sending information.

[0089] 2) Preparation stage

[0090] If node i in set E (i.e., the roadside unit with serial number i) receives the pre-prepare message from the primary node, node i will enter the preparation phase and reply with a Prep-prepare message to the primary node. The format of the Prepare message is <Prepare, v, z, R, T), σ, i> si , where si is the signature of node i.

[0091] When the primary node receives 2f messages, it will broadcast the Prep-Collect message to other consensus nodes. The format of the Prep-Collect message is <Prepare-Collect, Θ 1 , v, st> sp , where Θ 1 is the set of 2f messages received by the primary node, and st is the timestamp;

[0092] After receiving the Prep-Collect message, node i verifies the signature of the message and checks the view number, and then verifies whether there are 2f different prepare messages in the set Θ 1 . If the node signatures and view numbers obtained from the verification in the prepare messages are correct, it means that the message digest and sequence number are the same as those of the pre-prepare message received by the current node, and the node number in the message is in the current consensus node set E, then this Prepare message passes the verification.

[0093] 3) Commit phase

[0094] If 2f Prepare messages pass the verification, the node enters the commit phase.

[0095] The process of the commit phase is similar to that of the preparation phase. In the commit phase, each node needs to send a Commit message to the primary node p in the format of <Commit, v, z, d, i> si , where z is the message serial number, that is, a serial number assigned by the primary node to message m; d is the digest of message m;

[0096] When the primary node p receives 2f + 1 messages with the same digest d, view number v, and serial number z from different consensus nodes (including itself), the primary node will broadcast a Commit-Collect message to all consensus nodes. The format of this message is <Commit-Collect, Θ 2 , v, st> sp , where Θ 2 represents the set of 2f + 1 messages with the same digest;

[0097] After consensus node i receives the Commit-Collect message, it verifies whether there are 2f + 1 correct Commit messages sent by different consensus nodes; when successfully confirmed, that is, there are 2f + 1 correct Commit messages sent by different consensus nodes, the block is added to the local blockchain to complete the consistency process.

[0098] In the original Practical Byzantine Fault Tolerance (PBFT) consensus mechanism, the Prepare and Commit phases are two full-node broadcasts across the entire network, and the communication complexity is O(n 2 ); while the SVBFT consensus process mentioned in this paper simplifies the two full-network full-node broadcasts, and the consensus nodes only send messages to the primary node, thus reducing the communication complexity to O(n); however, it is difficult to avoid network latency or malicious behavior of the primary node in an asynchronous network, which may cause the above process to not execute correctly. Then the satellite node p broadcasts a "preparation timeout" message to other consensus nodes, and the format of the "preparation timeout" message is <Prepare-Timeout, v, st> sp , where Prepare-Timeout represents the message format of the "preparation timeout" message.

[0099] The identity authentication for vehicles when crossing regions is divided into two parts. On the one hand, the roadside unit needs to verify the identity information of the vehicle node. This part is to determine whether the pseudonym T of the OBU sending the message is recorded in the block of the blockchain and whether the block is still within the valid time by the RSU. The OBU can use the Merkle tree path path stored in the blockchain with the pseudonym to prove the validity of the pseudonym; on the other hand, the authenticity of the cross-region message must also be verified by the RSU. This part determines the validity of the OBU cross-region message by the RSU batch authenticating the signature messages of legitimate vehicles, and further confirms the authenticity of the OBU identity. Specifically, it includes:

[0100] 1) When the pseudonym T of vehicle k k is recorded in the block of the blockchain and the block is still within the valid time. Then vehicle k can use the Merkle tree path path = (hash 2 , hash 34 , hash 5678 ) stored in the blockchain with the pseudonym to prove the validity of the pseudonym, where hash x represents the hash value of the xth block message, hash xy represents the value obtained by performing a hash operation after concatenating the values of hash x and hash y , and hash xyzr represents the value obtained by performing a hash operation after concatenating the values of hash xy and hash zrThe value obtained after concatenating the values and performing a hash operation. Different subscripts represent different paths or branches. For example, Figure 3 as shown, TX n represents the nth block information, which consists of the full signature information, ring member information, and public key information corresponding to the block. After concatenating these information of the nth block information and performing a hash operation, the corresponding hash value is obtained, that is, hash n , hash 2 is the leaf node (height 1) existing in the Merkle root, hash 34 is the hash value stored in the node at height 2 in the Merkle tree, hash 5678 is the hash value stored in the node at height 3 in the Merkle tree. Vehicle k signs the message m with t k and sends to the message recipient. height represents the height of the Merkle tree;

[0101] When the RSU receives the message, it first verifies the validity of the block generation time and obtains the Merkle root MerRoot regarding the pseudonym integrity in the block;

[0102] Then, it determines whether T k is recorded on the chain, that is, determines whether the left and right sides of the following formula are equal:

[0103] MerRoot = Hash(hash(hash(hash(T k ), hash 2 ), hash 34 ), hash 5678 ));

[0104] Among them, hash() represents the path and the data block pointed to by the path, and Hash() points to the root node, indicating which hash block it is located in;

[0105] If they are equal, it proves that the pseudonym passes the verification, otherwise the pseudonym does not exist;

[0106] Finally, the message recipient verifies whether is equal. represents the signature of the message plaintext m by the signature algorithm, represents the signature of the message m by the signature verification function.

[0107] 2) Once the RSU receives multiple different message signature tuples, if it receives n different message signature tuples, that is, receives messages from n different vehicles, the received messages are expressed as:

[0108] {(PID 1 , M 1 , PK1 , σ 1 , t 1 ), (PID 2 , M 2 , PK 2 , σ 2 , t 2 ),..., (PID n , M n , PK n , σ n , t n )};

[0109] Among them, for messages from n different vehicles (V 1 , V 2 ,..., V n ), for the i-th vehicle V i , check its timestamp, including the timestamp T i of the pseudonym PID i from the i-th vehicle, the timestamp t i of the message signature tuple, and the pseudonym PID i stored on the consortium blockchain. After that, the RSU uses the road traffic message M i generated by the i-th vehicle, the pseudonym PID i of the i-th vehicle, and the private key PK i of the i-th vehicle to verify the full signature σ i of the i-th vehicle, calculate the parameter h i = H 1 (PID i , A i , P pub ) and j i = H 2 (M i , PID i , A i , PK i , P pub , t i ). A i represents an intermediate parameter obtained by multiplying a random number and a generator in the finite field Z * g , and P pub represents the public key obtained in the initialization phase.

[0110] Check whether it holds. If this equation holds, the verifier accepts the signature σ i on the message M i , otherwise rejects.

[0111] The verification process is expressed as:

[0112]

[0113] Among them, γ i ,j i is a random number over a finite field, and θ i =(S + h i γ i ) mod q.

[0114] If a user misbehaves or a dispute event occurs, the tracing phase is initiated. The trusted center, in conjunction with the members of the ring, exposes the true identity of the user by each node executing the disavowal algorithm and the confirmation algorithm in the ring signature algorithm, specifically including:

[0115] When the vehicle misbehaves, the trusted center sends a disclosure request to each member of the ring signature and sends the signature σ=(ρ, r 0 , π 1 ) to be disclosed, (R, T) to each member.

[0116] The true signer executes the CONFIRM algorithm to prove that the ring signature was generated by him.

[0117] 1) Take d'←Z q , calculate h' k =H 1 (M, N, ρ') and e' = d' - h' k ·sk k ;

[0118] 2) Send (π 2 =(M', N', e), ρ') as the response information to the trusted center.

[0119] In addition to the admission of the true signer, non-signers can execute the DISAVOW algorithm to prove that the ring signature was not generated by them. After the non-signers complete the algorithm, the identity of the true signer will be exposed.

[0120] a. Calculate and generate evidence π 3

[0121] b. Send the evidence (π 3 , ρ') to the trusted center. After receiving these evidences, the trusted center calculates h' k =H 1 (M 1 , N', ρ'), and then checks the following equation:

[0122]

[0123]

[0124] If and only if the above two formulas hold, if ρ' = ρ, the signer is the genuine signer; otherwise, the signer is a non-signer.

[0125] Although the embodiments of the present invention have been shown and described, those of ordinary skill in the art can understand that various changes, modifications, substitutions, and variations can be made to these embodiments without departing from the principles and spirit of the present invention. The scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A cross-domain authentication method for a space-ground integrated vehicle network based on a consortium blockchain, characterized in that: The specific steps include: S1, vehicles, satellites and roadside units send information carrying inherent identities to the trusted center for registration. The trusted registration center will distribute information to generate private keys to the registered devices. Vehicles, satellites and roadside units generate private keys sk based on the given information. i , and calculate the public key pk i ; S2. After completing the registration, if the vehicle is connected to the integrated space-ground vehicle network for the first time, when the vehicle enters the communication range of the roadside unit, the vehicle executes the signature algorithm, generates a signature message, and sends the signature message to the roadside unit for initial authentication. If the authentication is successful, the roadside unit will initiate a consensus to record the pseudonym on the block and provide network services for the vehicle; S3. If consensus verification is performed, the roadside unit sends a request to the satellite node. The satellite, as the master node, collects information sets in each consensus stage to complete the consensus process. If the consensus fails, the satellite is reselected through the view conversion protocol. S4. If the consensus verification succeeds, the satellite broadcasts the newly generated area to other roadside units and the current roadside unit provides network services to the vehicle; S5. If it is not the first time for the vehicle to access the integrated vehicle-to-ground vehicle network, when the vehicle enters the communication range of other roadside units, the vehicle and the roadside unit must perform cross-domain authentication. When performing cross-domain authentication, the vehicle-mounted unit selects a pseudonym T and signs it using the ring signature algorithm, selects a ring member R to provide identity endorsement for the pseudonym T, and sends the signed message to the roadside unit for authentication. When the timestamp carried by the vehicle is within the critical value and the pseudonym used by the vehicle is stored on the blockchain, the roadside unit determines whether the batch authentication of the road information of legal vehicles in other domains is passed. If passed, it provides network services for the vehicle node; S6. When the timestamp is not within the critical value or the pseudonym is not stored on the blockchain, or the batch authentication of the vehicle message fails, the malicious node is traced back.

2. According to the cross-domain authentication method of the space-ground integrated vehicle network based on the alliance blockchain of claim 1, it is characterized in that: The registration process includes the following steps: The trusted registration center sets the system security factor η and generates a sufficiently large security prime number q; Choose an additive cyclic group G1 and a multiplicative cyclic group G2 of an elliptic curve, both of which have the same order q; Set up a bilinear map, The generator of G1 is P, H0:{0,1} * →G1 and H1: {0,1} * →Z q are two secure hash functions, H0:{0,1} * →G1 means mapping a sequence of any length consisting of 0 and 1 to G1. The mapping process is the first hash function H0(), H1:{0,1} * →Z q Represents mapping a sequence of any length consisting of 0s and 1s to a finite field Z q The mapping process is the second hash function H1().

3. According to the cross-domain authentication method of the space-ground integrated vehicle network based on the alliance blockchain in claim 1, it is characterized in that: Cross-domain authentication specifically includes the following steps: The vehicle-mounted device randomly selects an integer t, t←Z * g and calculates the pseudonym T based on t and the generator P; then, the vehicle selects the ring member R = pk1||pk2···||pk n ; Take a random number r0←{0,1} S , calculate ω0, ω1 according to the two secure hash functions, and then add ω0, ω1 and the private key sk of the vehicle k The identity information ρ is obtained by linear mapping calculation; use prove The private key of the corresponding vehicle is included without exposing the corresponding identity information, and the full signature σ = (ρ, r0, π1) and (R, T) are sent to the roadside unit for verification as a request for anonymous authentication; After receiving the authentication request, the roadside unit parses π1, extracts the parameters required for the calculation process, and verifies it based on the vehicle's public key. and whether it is established; If the equation holds, the roadside unit packages the verification information to generate a transaction and sends it to the satellite node, records the vehicle's pseudonym on the blockchain, and initiates a consensus process; if not, the vehicle is refused service. Among them, Z * g represents a finite field; pk1,...,pk n represents the public key; S represents the length of the random number r0; M represents the intermediate parameter obtained by bilinear calculation of the generator and the random number; N represents the intermediate parameter obtained by bilinear calculation of the value obtained by two secure hash functions for the pseudonym and the ring member; U i represents the result of summing the public key of member i and the public keys of other members in the ring; h i It represents the fixed-length hash value of the pseudonym of the i-th member in the ring and the current member calculated according to the secure hash function; e represents the intermediate parameter obtained by summing the private key and the random number; is a bilinear mapping function.

4. According to the cross-domain authentication method of the space-ground integrated vehicle network based on the alliance blockchain in claim 1, it is characterized in that: The consensus process includes: After receiving the request, the satellite node assigns a sequence number z to the message m and attaches a timestamp st, and then broadcasts it to other roadside units in the roadside unit node set E within the coverage area. At this time, the roadside unit acts as a consensus node; The format of the pre-prepare message is <<Pre-Prepare,v,z,(R,T),σ,st>sp,m>, where v is the view number when the message is sent, σ is the full signature, sp is the signature of the satellite node, st is the timestamp, and z is the message serial number; If node i in set E receives a pre-prepare message from a satellite node, the node will enter the preparation phase and reply with a Prep-prepare message to the master node; the format of the reply Prep-prepare message is <Prepare,v,z,R,T),σ,i> si , si is the signature of node i; When a satellite node receives the Prep-prepare message from 2f nodes, it will broadcast the Prep-Collect message to other consensus nodes. The format of the Prep-Collect message is <Prepare-Collect,Θ1,v,st> sp , where Θ1 is the set of 2f messages received by the master node; After receiving the Prep-Collect message, node i verifies the signature of the message and checks the number to verify whether there are 2f different prepare messages in the set Θ1. If the node signature and view number verified in the Prepare message are correct, the Prepare message passes the verification; In the commit phase, each node needs to submit a request to the master node p with <Commit,v,z,d,i> si The Commit message is sent in the format of , where d is the digest of message m; when the master node p receives 2f+1 messages with the same digest d, view number v and sequence number z from different consensus nodes including itself, the master node will broadcast the Commit-Collect message to all consensus nodes, expressed as <Commit-Collect,Θ2,v,st> sp , where Θ2 represents the set of 2f+1 Commit messages; After receiving the Commit-Collect message, consensus node i verifies whether there are 2f+1 correct Commit messages sent by different consensus nodes. After successful confirmation, it adds the block to the local blockchain to complete the consistency process; otherwise, satellite node p broadcasts a prepare timeout message to other consensus nodes. The message format is <Prepare-Timeout,v,st> sp , consensus failed.

5. According to the cross-domain authentication method of the space-ground integrated vehicle network based on the alliance blockchain of claim 1, it is characterized in that: Batch authentication of vehicle messages includes: When the pseudonym T of vehicle k k When the block is recorded in the blockchain and the block is still within the validity period, vehicle k can use the pseudonym to store the Merkle tree path path = (hash2, hash 34 ,hash 5678 ) to prove the validity of the pseudonym; The roadside unit receives multiple different message signature tuples from different vehicles, represented as: (PID1, M1, PK1, σ1, t1), (PID2, M2, PK2, σ2, t2), ..., (PID n ,M n ,PK n ,σ n ,t n ), check timestamps, including pseudonymous PID i Timestamp T i and the timestamp t of the message signature tuple i , and the pseudonymous PID stored on the consortium chain i Afterwards, the roadside unit RSU uses params,M i ,PID i ,PK i , and σ i , calculate h i =H0(PID i ,A i ,P pub ) and j i =H1(M i ,PID i ,A i ,PK i ,P pub ,t i ) and judge Is it true? If so, the verifier accepts the message M i The signature σ i , otherwise it is rejected and batch authentication is completed; Among them, A i Represented by the finite field Z * g The intermediate parameter is calculated by multiplying the random number in and the generator; pub Represents the public key obtained in the initialization phase; R i Represents one of the R generated during initialization, where R contains n members.

6. According to the cross-domain authentication method of the space-ground integrated vehicle network based on the alliance blockchain in claim 1, it is characterized in that: The process of tracing back malicious nodes is as follows: When a vehicle commits a crime, the trusted center sends a disclosure request to each member of the ring signature, and sends the signature to be disclosed σ=(ρ,r0,π1),(R,T) to each member in the ring; after receiving the information, the ring members respectively execute the signature recognition algorithm and the signature denial algorithm to reveal the true identity of the signer. In addition to the real signer, non-signers can execute the signature denial algorithm to prove that the ring signature is not generated by the node; After executing the ring signature recognition algorithm, (π2=(M',N',e),ρ') is sent to the satellite as the response information.

7. According to claim 6, a cross-domain authentication method for a space-ground integrated vehicle network based on a consortium blockchain is characterized in that: Signature repudiation algorithms include: The vehicle uses its own private key, the hash function to calculate ω0, ω1, and the linear mapping to calculate ρ', and sends the (π2, ρ') generated by the signature recognition algorithm to the trusted center. After receiving these evidences, it determines and Is it true? When both equations are true, if ρ=ρ', it means that the signer is the real signer.

Images