Internet of vehicles communication method based on alliance chain

Abstract

The invention discloses an Internet of Vehicles communication method based on an alliance chain, which mainly solves the problems of difficulty in cross-domain identity authentication and large computing resource consumption of the existing Internet of Vehicles, and the implementation scheme comprises the following steps: constructing an alliance block chain network which takes a plurality of management centers of a certificate as a plurality of center nodes and a plurality of Internet of Vehicles devices as a plurality of common nodes; each center node issues a public key certificate to the ordinary nodes managed by the center node, and the public key certificate is stored in the block chain after signature verification of the certificate is passed by other nodes in the network; when any two common nodes in the alliance chain network communicate, identity authentication requests are sent to each other, and identity authentication of both parties is carried out by inquiring the verification sequence of the public key certificate of the opposite party in the block chain; and after the authentication is passed, the two parties calculate the same session key, and the session key is used for symmetric encryption and then communication is carried out. The method has the advantages of being large in number of center nodes, simple in cross-domain identity authentication and small in computing resource consumption, and can be applied to secure communication when cross-domain authentication is carried out on the Internet of Vehicles nodes.

Description

Technical Field

[0001] The present invention belongs to the field of information security, and particularly relates to a vehicle networking communication method, which can be applied to secure communication during cross-domain authentication of vehicle networking nodes. Background Art

[0002] Intelligent Transportation System (ITS) is a transportation system applying modern technologies, which organically combines high-tech technologies such as computer technology, data communication technology, and artificial intelligence with relevant technologies of transportation systems such as transportation, service control, and vehicle manufacturing. As an important part of the intelligent transportation system, Vehicular Ad Hoc Network (VANET) involves a large amount of communication and data transmission. These data may involve personal privacy or safe driving. Once obtained or tampered with by an unauthorized third party, it will pose a threat to the safety of vehicle owners. Therefore, the security issue of VANET is of crucial importance.

[0003] The key management system is an important security infrastructure to ensure the security of VANET. Currently, the relatively mature ones are the certificate-based Public Key Infrastructure (PKI) and the identity-based key management system (IBC). Among them, IBC realizes by using the user's identity information as the public key. There is a Key Generation Center (KGC) in IBC, which can generate the public key by using the user's identity information such as name, mobile phone number, or email, and generate the corresponding private key for the user. While PKI is realized based on public key certificates, and the Certificate Authority (CA) completes operations such as certificate registration, update, revocation, etc., and maintains the Certificate Revocation List (CRL). They are both centralized key management systems. With the continuous expansion of the scale of VANET and the emergence of its distributed characteristics, this centralized key management system has become increasingly unsuitable for the VANET system. Almost all current VANET key management solutions are implemented based on PKI technology. Problems such as single point of failure of the PKI system, the need to maintain the certificate revocation list, and the need to verify the certificate chain for cross-domain authentication are very prominent. For end users, verifying the certificate chain also requires a large amount of computation, which imposes a heavy burden on the computation and storage of resource-constrained end users.

[0004] In recent years, with the rapid development of blockchain technology, people have also been exploring key management solutions for the vehicle networking based on blockchain technology. Blockchain technology is a distributed ledger technology that can link transaction data in the form of blocks to form an immutable and transparent ledger. When blockchain is applied to vehicle networking, the most concerned is the combination of blockchain and PKI technology to adapt to the distributed environment of vehicle networking and solve problems such as centralized trust in the PKI system, single-point failure, the need to maintain a certificate revocation list, and cross-domain authentication requiring verification of the certificate chain. The consensus mechanism is used to establish trust relationships among the CA nodes of each vehicle manufacturer, and the tamper-proof feature of blockchain is used to enhance the security strength of system key management. Since each CA node and the infrastructure in the vehicle networking system have a blockchain copy locally, even if the CA fails, it will not affect the normal operation of the entire system.

[0005] The patent document with the application number 201910854309.X discloses an "authentication method and device based on a blockchain network", aiming to solve problems such as being vulnerable to attacks, difficult to establish mutual trust, and high costs existing in the traditional certificate authority CA. It uses the characteristics of the blockchain network to achieve secure data interaction between different institutions. After the management institution receives a request from a user to upload data to the blockchain, it will first verify the identity information. After the identity is verified, it generates a public key certificate and signs it with the private key. This certificate is stored in the blockchain network after consensus, and the user's biometric features are used to uniquely identify the identity. When nodes in the network conduct data interaction, they will send the certificate of the other party to the blockchain network, and in the network, they confirm the identity by comparing the stored certificates and verifying the signature. After the verification passes, the data interaction continues. However, this solution cannot guarantee that the information sent by the blockchain network to the communication node is legal and valid. If a malicious attacker impersonates the blockchain network and sends false information to the communication node, the node cannot determine whether the information is secure and reliable, and there is a risk of being deceived by the attacker.

[0006] The patent document with the application number 201911386678.7 discloses a "digital certificate management method, device, and blockchain node". It receives a verification request for the first digital certificate from the client through the blockchain node, including verification data and certificate identification. If an electronic seal is involved, it also includes the electronic seal identification to be verified. Subsequently, corresponding verification information is obtained from each block of the blockchain, including certificate information and seal information. The validity of the certificate data is verified based on the certificate information, including confirming whether the certificate is valid, decrypting the digital signature and comparing the digest to determine the integrity of the data original text. At the same time, the validity of the electronic seal is judged according to the seal information, such as determining whether its current state is valid based on the seal status information. Finally, the verification result is fed back to the client terminal. However, this solution consumes a large amount of computing resources. When processing a large number of certificate verification requests, a large number of operations such as decrypting digital signatures and calculating digests are required, which places high requirements on the computing power and storage capacity of the node. Summary of the Invention

[0007] The object of the present invention is to propose a vehicle networking communication method based on a consortium blockchain aiming at the deficiencies of the above-mentioned existing technologies, so as to avoid nodes being deceived by attackers, reduce the consumption of certificate verification resources, and improve the efficiency of certificate verification.

[0008] To achieve the above object, the technical solution of the vehicle networking communication method based on a consortium blockchain of the present invention includes:

[0009] Construct a consortium blockchain network with a certificate management center as the central node and vehicle networking devices as ordinary nodes;

[0010] Each central node CA n issues a public key certificate for the ordinary node Com n,m it manages. After being consensus by other nodes in the network, the certificate is successfully chained and stored in the blockchain. Among them, CA n represents the nth central node, and Com n,m represents the mth ordinary node managed by the nth central node CA n ;

[0011] When any two ordinary nodes Com u,i and Com w,j in the consortium blockchain network communicate with each other, they send identity authentication requests to each other and conduct mutual authentication. Among them, Com u,i represents the ith ordinary node managed by the uth central node CA u , and Com w,j represents the jth ordinary node managed by the wth central node CA w ;

[0012] After the mutual identity authentication is passed, the two ordinary nodes Com u,i and Com w,j calculate the same session key K S , and use this session key K S to conduct communication after symmetric encryption.

[0013] Furthermore, the construction of the consortium blockchain network with a certificate management center as the central node and vehicle networking devices as ordinary nodes includes:

[0014] Take N certificate management centers as N central nodes of the consortium blockchain network: CA = {CA n |1 ≤ n ≤ N}, where N ≥ 2 represents the number of certificate management centers;

[0015] Take vehicle networking devices as ordinary nodes Com with the same number

[0016] Com = {Com n,m | 1 ≤ n ≤ N, 1 ≤ m ≤ M n}

[0017] Among them, M n ≥ 1 represents the number of ordinary nodes managed by CA n ;

[0018] It is assumed that the public key certificate of each ordinary node is issued by the affiliated central node, and the public key certificate of each central node is set in advance by each certificate management center. All central nodes and all ordinary nodes together form a consortium blockchain network;

[0019] The public key certificates of all ordinary nodes in the consortium blockchain network are stored in the blockchain. Each block Node a of the blockchain stores the public key certificates of q ordinary nodes in the vehicle networking. Among them, a represents the height of the blockchain, a ≥ 0, q ≥ 1;

[0020] Each ordinary node has the permission to send a public key certificate query request to the blockchain.

[0021] Furthermore, each central node CA n issues a public key certificate for the ordinary nodes Com n,m it manages, and it includes:

[0022] Each central node CA n generates a private key PriK n,m , a public key PubK n,m and a key validity period expiration time VP n,m for the ordinary nodes Com n,m it manages, and based on PriK n,m , PubK n,m , VP n,m these information, it generates a public key certificate Cer n,m for the ordinary nodes Com n,m . The public key certificate is provided with a revocation standard bit. The revocation flag bit being '0' indicates that the public key certificate is valid, and the revocation flag bit being '1' indicates that the public key certificate is invalid. And the central node CA n signs this certificate using its own private key PriK n ;

[0023] The central node CA n encapsulates the public key certificate Cer n,m into a transaction Tr n,m , and broadcasts this transaction Tr n,m in the consortium blockchain network, n,m completing the issuance of the public key certificate for the node Com.

[0024] Furthermore, when any two ordinary nodes Com in the consortium blockchain network u,i communicate with Com w,j they send identity authentication requests to each other and conduct mutual identity authentication, including:

[0025] The first ordinary node Com u,i sends an identity authentication request to the second ordinary node Com w,j and the second ordinary node Com w,j authenticates the identity of the first ordinary node Com u,i ;

[0026] The second ordinary node Com w,j sends an identity authentication request to the first ordinary node Com u,i and the first ordinary node Com u,i authenticates the identity of the second ordinary node Com w,j ;

[0027] Compared with the prior art inventions, the present invention has the following advantages:

[0028] First, the present invention improves the traditional vehicle networking key management scheme, introduces blockchain technology, constructs a consortium blockchain network with the certificate management center as the central node and vehicle networking devices as ordinary nodes, and stores the public key certificates of all ordinary nodes on the blockchain, solving the problem of difficult cross-domain authentication between ordinary nodes managed by different central nodes and improving the efficiency of identity authentication.

[0029] First, the present invention designs a lightweight blockchain public key certificate in combination with the characteristics of the blockchain, and adds a revocation flag bit to the certificate standard domain, that is, a value of '1' indicates that the certificate has been revoked, and a value of '0' indicates that the certificate has not been revoked, without the need to maintain an additional revocation list CRL, saving storage resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1 is the overall implementation flowchart of the present invention;

[0031] Figure 2 is the entity diagram of the consortium blockchain network in the present invention;

[0032] Figure 3 is the interaction diagram of identity authentication and key negotiation in the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0033] The following will further describe the present invention in detail with reference to the drawings and specific embodiments.

[0034] Referring to Figure 1 , the present invention includes the following steps:

[0035] Step 1: Construct a consortium blockchain network with the certificate management center as the central node and the vehicle networking devices as ordinary nodes.

[0036] As Figure 2 shown, in this example, a consortium blockchain network is composed of 5 certificate management centers as 5 central nodes and 30 vehicle networking devices as 30 ordinary nodes, where:

[0037] The 5 central nodes are represented as: CA = {CA n | 1 ≤ n ≤ 5};

[0038] The 30 ordinary nodes are represented as: Com = {Com n,m | 1 ≤ n ≤ 5, 1 ≤ m ≤ M n}, where CA n represents the nth central node, Com n,m represents the mth ordinary node managed by the nth central node CA n , and M n represents the number of ordinary nodes managed by the central node CA n , which is the sum of the numbers of all ordinary nodes managed by all central nodes in the consortium chain network; is the sum of the numbers of all ordinary nodes managed by all central nodes in the consortium chain network;

[0039] The public key certificate of each ordinary node is issued by the affiliated central node, the public key certificate of each central node is set in advance by each certificate management center, all central nodes and all ordinary nodes jointly form the consortium chain network, and the public key certificates of all ordinary nodes in the consortium chain network are stored in the blockchain;

[0040] In this example, taking each block of the blockchain storing 10 public key certificates as an example, that is, each block Block a of the blockchain stores the hash values of the public key certificates of 10 ordinary nodes in the vehicle networking. These hash values are recorded in the leaf nodes of the Merkle tree. Here, a represents the height of the blockchain, a ≥ 0. The Merkle tree is a binary tree, and the hash value of the parent node is calculated from the left and right child nodes. The hash value of the Merkle tree root node is recorded in the block;

[0041] In this example, taking the total length of the blockchain equal to 15 as an example, that is, the height of the latest block Block last of the blockchain is 15.

[0042] Step 2: Each central node CA n issues a public key certificate for the ordinary nodes Com n,m it manages.

[0043] Each central node CA n for the ordinary nodes Com n,mReview the identity-related materials of Com. After passing the review, it becomes a common node Com n,m Generate the private key PriK n,m , the public key PubK n,m and the expiration time VP of the key n,m , and based on PriK n,m , PubK n,m , VP n,m , timestamp and other information, generate the public key certificate Cer for the common node Com n,m The public key certificate has a revocation standard bit. The revocation flag bit being '0' indicates that the public key certificate is valid, and '1' indicates that the public key certificate is invalid. And the central node CA n,m uses its own private key PriK n to sign this certificate n

[0044] The central node CA n encapsulates the public key certificate Cer n,m into a transaction Tr n,m and broadcasts this transaction Tr in the consortium chain network n,m to complete the issuance of the public key certificate for the node Com n,m n,m .

[0045] It should be noted that: The public key certificate in this example adds a revocation flag bit. The value of this item being '1' indicates that the certificate has been revoked, and '0' indicates that the certificate has not been revoked. In addition, the start time of the validity period in the certificate and the start time of the validity period of the user's private key are deleted, and only the expiration time of the validity period is retained. Because the block header of the blockchain contains the timestamp of the block generation time, the timestamp of the block where the transaction encapsulated by the certificate is located can be regarded as the start time of the validity period of the certificate and the validity period of the user's private key.

[0046] Step 3, other nodes in the network conduct consensus on the public key certificate.

[0047] All central nodes in the consortium chain network use the public key PubK in the public key certificate Cer n,m of the central node CA n to which the common node Com belongs n to verify the signature part of the public key certificate Cer n encapsulated into the transaction Tr n,m ; n,m When the number of central nodes that pass the verification exceeds 2 / 3 of the total number of central nodes, consensus is reached, that is, all nodes in the network consider that the transaction record is a legal public key certificate, and store the public key certificate Cer

[0048] successfully in the blockchain. n,m ​

[0049] For the sake of convenience of description, the second ordinary node managed by the first central node CA1 is hereinafter taken as the first ordinary node Com 1,2 , and the fourth ordinary node managed by the third central node CA3 is taken as the second ordinary node Com 3,4 for description. It should be noted that the "first" and "second" mentioned herein are used to distinguish similar objects, rather than to describe a specific order or sequence.

[0050] Referring to Figure 3 , the implementation steps for the first ordinary node and the second ordinary node in the consortium blockchain network of this example to perform identity authentication and key negotiation are as follows:

[0051] Step 4, any node in the consortium blockchain network sends an identity authentication request to another arbitrary node.

[0052] The first ordinary node Com 1,2 generates a timestamp T 1,2 , and uses the private key PriK 1,2 to sign the public key certificate Cer 1,2 of the first ordinary node Com 1,2 , the timestamp T 1,2 and the encryption component P 1,2 supported by the first ordinary node Com 1,2 . Among them, the encryption component P 1,2 is the key negotiation algorithm, shared key generation algorithm and symmetric encryption algorithm supported by the first ordinary node Com 1,2 .

[0053] The first ordinary node Com 1,2 uses its own public key certificate Cer 1,2 , the timestamp T 1,2 , the encryption component P 1,2 and the signature Sig 1,2 to form an authentication request: Req 1,2 ={Cer 1,2 ||T 1,2 ||P 1,2 ||Sig 1,2}, and sends the authentication request Req 1,2 to the second ordinary node Com 3,4 .

[0054] Step 5, the second ordinary node Com 3,4 authenticates the first ordinary node Com 1,2 according to the authentication request Req 1,2 sent by the first ordinary node Com 1,2Authenticate the identity.

[0055] (5.1) The second ordinary node Com 3,4 Receives the authentication request Req 1,2 Sent by the first ordinary node Com 1,2 After that, calculate the current time T now_3,4 And the authentication request Req 1,2 The difference in timestamps in: ΔT 3,4 = T now_3,4 - T 1,2 And compare it with the set timestamp validity threshold T max For comparison:

[0056] If ΔT 3,4 ≤ T max , then it is considered that the authentication request Req 1,2 Sent by the first ordinary node Com 1,2 Meets the timeliness, and execute step (5.2);

[0057] If ΔT 3,4 > T max , then it is considered that the authentication request is invalid, and the second ordinary node Com 3,4 Authenticates the identity of the first ordinary node Com 1,2 Failed;

[0058] (5.2) The second ordinary node Com 3,4 Sends a query request for the public key certificate Cer 1,2 Of the first ordinary node Com 1,2 To the nearest blockchain node Node8, where Node8 represents the 8th ordinary node that makes up the blockchain;

[0059] (5.3) The nearest blockchain node Node8 to the second ordinary node Com 3,4 After receiving the query request, starts querying the public key certificate Cer 1,2 From the end of the blockchain:

[0060] If the public key certificate Cer 1,2 Is not found, then send a sequence of all 0s to the second ordinary node Com 3,4 Indicating that the public key certificate Cer 1,2 Was not found in the blockchain;

[0061] If the public key certificate Cer 1,2 Is found, for example, the public key certificate Cer 1,2 Is located in the 10th block Block 10 Of the blockchain, the verification sequence Seq 1,2 Of the public key certificate Cer 1,2Send to the second ordinary node Com 3,4 , execute step (5.4),

[0062] wherein, the verification sequence Seq 1,2 of the public key certificate Cer 1,2 includes: the public key PubK1 of the central node CA1 that issues the public key certificate Cer 1,2 , the hash values CerHash = {CerHash 1,2 |1≤i≤9} of the other 9 public key certificates stored in the block Block 10 where the public key certificate Cer i is located, and the hash value MerkleHash of the Merkle root node recorded in the block Block 1,2 where the public key certificate Cer 10 is located;

[0063] (5.4) After the second ordinary node Com 3,4 receives the verification sequence sent by the blockchain node Node8, use the public key PubK1 of the central node CA1 in the verification sequence to verify the signature part of the public key certificate Cer 1,2 :

[0064] The second ordinary node Com 3,4 uses the public key PubK1 to decrypt the signature part of the public key certificate Cer 1,2 to obtain a hash value Cerhash 1,2 ;

[0065] Then, splice the information such as the timestamp and public key recorded in the public key certificate Cer 1,2 to calculate a hash value Cerhash′ 1,2 , and compare it with the hash value hash obtained by decrypting the signature:

[0066] If Cerhash 1,2 = Cerhash′ 1,2 , the signature verification is successful;

[0067] If Cerhash 1,2 ≠ Cerhash′ 1,2 , the signature verification fails;

[0068] (5.5) The second ordinary node Com 3,4 judges the authentication of the first ordinary node Com 1,2 according to the signature verification situation:

[0069] If the signature verification is successful, execute step (5.6);

[0070] If the signature verification fails, the second ordinary node Com 3,4 fails to authenticate the identity of the first ordinary node Com 1,2 .

[0071] (5.6) The second ordinary node Com 3,4 uses the hash values of 9 public key certificates in the verification sequence Seq 1,2 and the hash value of the public key certificate Cer 1,2 of the first ordinary node Com 1,2 to calculate the hash value CalMerkleHash of the Merkle root node;

[0072] (5.7) Determine whether the calculated hash value CalMerkleHash of the Merkle root node is the same as the Merkle root node hash value MerkleHash of the verification sequence Seq 1,2 :

[0073] If they are the same, execute step (5.8);

[0074] If they are not the same, the second ordinary node Com 3,4 fails to authenticate the identity of the first ordinary node Com 1,2 .

[0075] (5.8) The second ordinary node Com 3,4 uses the public key PubK 1,2 in the public key certificate Cer 1,2 of the first ordinary node Com 1,2 to verify the signature Sig 1,2 in the authentication request Req 1,2 :

[0076] The second ordinary node Com 3,4 uses the public key PubK 1,2 to decrypt the signature Sig 1,2 to obtain a hash value hash 1,2 ;

[0077] Then, the public key certificate Cer 1,2 , timestamp T 1,2 and encryption component P 1,2 in the authentication request Req 1,2 are concatenated together to calculate a hash value hash' 1,2 , and it is compared with the decrypted hash value hash 1,2 :

[0078] If hash 1,2 = hash' 1,2 , the signature verification is successful;

[0079] If the hash 1,2 ≠ hash′ 1,2 , the signature verification fails;

[0080] (5.9) The second ordinary node Com 3,4 Judges the authentication of the first ordinary node Com 1,2 according to the signature verification result:

[0081] If the signature verification is successful, the second ordinary node Com 3,4 authenticates the first ordinary node Com 1,2 successfully. If the signature verification fails, the second ordinary node Com 3,4 authenticates the first ordinary node Com 1,2 unsuccessfully.

[0082] Step 6, the second ordinary node Com in the consortium blockchain network 3,4 sends an authentication request to the first ordinary node Com 1,2 .

[0083] (6.1) The second ordinary node Com 3,4 selects an encryption component P 1,2 supported by the first ordinary node Com 1,2 . The second ordinary node Com 3,4 generates a random number r 3,4 , a timestamp T 3,4 , and saves the random number r 3,4 as a temporary private key. According to the selected encryption component P 3,4 , a temporary public key k 1,2 = f(r 3,4 ) is generated, where the encryption component P 3,4 includes the key agreement algorithm, the shared key generation algorithm, and the symmetric encryption algorithm supported by the second ordinary node Com 1,2 , and f(r 3,4 ) is the key agreement algorithm in the selected encryption component P 3,4 ; 1,2

[0084] (6.2) The second ordinary node Com 3,4 uses its own private key PriK 3,4 to sign its own public key certificate Cer 3,4 , the timestamp T 3,4 , the temporary public key k 3,4 , and the selected encryption component P 3,4 : Sig 3,4 = En PriK3,4 (Cer​3,4 ||T 3,4 ||k 3,4 ||P 3,4 ) and use the public key PubK of the first ordinary node Com 1,2 to encrypt its own public key certificate Cer 1,2 , timestamp T 3,4 , temporary public key k 3,4 , encryption component P 3,4 and signature Sig 3,4 to obtain an authentication request 3,4 Then send the authentication request Req to the first ordinary node Com 3,4 . 1,2 .

[0085] Step 7, the first ordinary node Com 1,2 authenticates the identity of the second ordinary node Com according to the authentication request Req 3,4 . 3,4 .

[0086] (7.1) After the first ordinary node Com 1,2 receives the authentication request Req of the second ordinary node Com 3,4 , it uses its private key PriK 3,4 to decrypt and obtain the public key certificate Cer before encryption 1,2 , timestamp T 3,4 , temporary public key k 3,4 , encryption component P 3,4 and signature Sig 3,4 ; 3,4 ;

[0087] (7.2) The first ordinary node Com 1,2 calculates the difference between the current time T now_1,2 and the timestamp T 3,4 : ΔT 1,2 = T now_1,2 - T 3,4 , and compares this value with the set timestamp validity threshold T max :

[0088] If ΔT 1,2 ≤ T max , it is considered that the authentication request Req sent by the first ordinary node Com 1,2 meets the timeliness, and step (7.3) is executed; 3,4 ;

[0089] If ΔT 1,2 > T max , then the first ordinary node Com 1,2 authenticates the second ordinary node Com3,4 Identity authentication fails;

[0090] (7.3) The first ordinary node Com 1,2 Sends a query request for the public key certificate Cer of the second ordinary node Com 12 To the nearest blockchain node Node 3,4 Where Node 3,4 Represents the 12th ordinary node that makes up the blockchain; 12

[0091] (7.4) The blockchain node Node 1,2 Nearest to the first ordinary node Com 12 After receiving the query request, starts querying for the public key certificate Cer from the end of the blockchain 3,4 :

[0092] If the public key certificate Cer is not found 3,4 It sends a sequence of all 0s to the first ordinary node Com 1,2 Indicating that the public key certificate Cer was not found in the blockchain 3,4 ;

[0093] If the public key certificate Cer is found 3,4 For example, if the public key certificate Cer 3,4 Is located in the 13th block Block of the blockchain 13 It sends the verification sequence Seq of the public key certificate Cer 3,4 To the first ordinary node Com 3,4 And executes step (7.4); 1,2

[0094] The verification sequence Seq of the public key certificate Cer 3,4 Includes: the public key PubK3 of the central node CA3 that issued the public key certificate Cer 3,4 The hash values CerHash = {CerHash 3,4 |1 ≤ j ≤ 9} of the other 9 public key certificates stored in the block Block where the public key certificate Cer 3,4 Is located, and the hash value MerkleHash' of the Merkle root node of the block Block where the public key certificate Cer 13 Is located; j 3,4 The block Block where the public key certificate Cer 13 Is located;

[0095] (7.5) The first ordinary node Com 1,2 After receiving the verification sequence sent by the blockchain node Node 13 Uses the verification sequence Seq 3,4The public key PubK3 of the inner central node CA3 verifies the signature part of the public key certificate Cer 3,4 :

[0096] The first ordinary node Com 1,2 uses the public key PubK3 to decrypt the signature part of the public key certificate Cer 3,4 to obtain a hash value Cerhash 3,4 ;

[0097] Then, the information such as the timestamp and public key recorded in the public key certificate Cer 3,4 is concatenated together to calculate a hash value Cerhash' 3,4 , and it is compared with the hash value hash obtained by decrypting the signature:

[0098] If Cerhash 3,4 = Cerhash′ 3,4 , the signature verification is successful;

[0099] If Cerhash 3,4 ≠ Cerhash′ 3,4 , the signature verification fails;

[0100] (7.6) The first ordinary node Com 1,2 judges the authentication of the second ordinary node Com 3,4 according to the signature verification result of the public key certificate Cer 3,4 :

[0101] If the signature verification is successful, step (7.7) is executed;

[0102] If the signature verification fails, the first ordinary node Com 1,2 fails to authenticate the second ordinary node Com 3,4 ;

[0103] (7.7) The first ordinary node Com 1,2 uses the hash values of the 9 public key certificates in the verification sequence Seq 3,4 and the hash value of the public key certificate Cer 3,4 of the second ordinary node Com 3,4 to calculate the hash value CalMerkleHash' of the Merkle root node;

[0104] (7.8) The first ordinary node Com 1,2 judges whether the calculated hash value CalMerkleHash' is consistent with the hash value MerkleHash' of the Merkle root node in the verification sequence Seq 3,4 :

[0105] If they are consistent, execute step (7.8);

[0106] If they are inconsistent, the first ordinary node Com 1,2 authenticates the second ordinary node Com 3,4 and fails;

[0107] (7.9) The first ordinary node Com 1,2 uses the public key PubK in the public key certificate Cer 3,4 of the second ordinary node Com 3,4 to verify the signature Sig 3,4 in the authentication request Req 3,4 : 3,4 Verify as follows:

[0108] The first ordinary node Com 1,2 uses the public key PubK 3,4 to decrypt the signature Sig 3,4 in the authentication request Req 3,4 to obtain a hash value hash 3,4 ;

[0109] Then, the public key certificate Cer 3,4 , timestamp T 3,4 , temporary public key k 3,4 , and encryption component P 3,4 in the authentication request Req 3,4 are concatenated to calculate a hash value hash' 3,4 , and it is compared with the hash value hash obtained by decrypting the signature:

[0110] If hash 3,4 = hash' 3,4 , the signature verification is successful;

[0111] If hash 3,4 ≠ hash' 3,4 , the signature verification fails;

[0112] (7.10) The first ordinary node Com 1,2 judges the authentication of the second ordinary node Com 3,4 according to the signature verification result:

[0113] If the signature verification is successful, the first ordinary node Com 1,2 authenticates the second ordinary node Com 3,4 successfully. If the signature verification fails, the first ordinary node Com 1,2 authenticates the second ordinary node Com 3,4 and fails.

[0114] Step 8, the first ordinary node Com 1,2 Calculate the session key K according to the temporary public key k of the second ordinary node 3,4 . S

[0115] (8.1) The first ordinary node Com 1,2 Generate a random number r 1,2 , and save the random number r 1,2 as the temporary private key. Generate a temporary public key k 3,4 according to the encryption component P 3,4 in the authentication request Req 1,2 k = f(r 1,2 ), where f(r 1,2 ) is the key negotiation algorithm in the encryption component P 3,4 .

[0116] (8.2) The first ordinary node Com 1,2 Generate the session key K 3,4 according to the encryption component P 3,4 and the temporary public key k 3,4 of the second ordinary node in the authentication request Req 3,4 sent by the second ordinary node Com S K = f(r 1,2 , k 3,4 ), where f(r 1,2 , k 3,4 ) is the shared key generation algorithm in the encryption component P 3,4 .

[0117] (8.3) The first ordinary node Com 1,2 Generate a timestamp T 1',2' , and use the public key of the second ordinary node Com 3,4 to encrypt the session key K S , its own temporary public key k 1,2 and the timestamp T 1',2' . The first ordinary node Com 1,2 Sends the encrypted message M 1,2 to the second ordinary node Com 3,4 , where the encryption method of M 1,2 is the symmetric encryption algorithm in the encryption component P 3,4 .

[0118] Step 9, the second ordinary node Com 3,4 Calculate the session key K 1,2 according to the temporary public key k of the first ordinary node S .

[0119] ​(9.1) The second ordinary node Com 3,4 Receives the encrypted message M 1,2 sent by the first ordinary node Com 1,2 and then uses the private key PriK 3,4 to decrypt the message M 1,2 to obtain the session key K before encryption S , the temporary public key k of the first ordinary node 1,2 and the timestamp T 1',2' ;

[0120] (9.2) The second ordinary node Com 3,4 Calculates the difference between the current time T now_3',4' and the timestamp T 1',2' : ΔT 3',4' = T now_3',4' - T 1',2' and compares it with the set timestamp validity threshold T max :

[0121] If ΔT 3',4' ≤ T max , it is considered that the message M 1,2 meets the timeliness and executes step (9.3);

[0122] If ΔT 3',4' > T max , the second ordinary node Com 3,4 ends the communication with the first ordinary node Com 1,2 ;

[0123] (9.3) The second ordinary node Com 3,4 Generates a session key K' 3,4 = f(r 1,2 , k 1,2 ) according to the encryption component P S and the k in the message M 3,4 , where f(r 1,2 , k 3,4 ) is the shared key generation algorithm in the encryption component P 1,2 ; 3,4 ;

[0124] (9.4) The second ordinary node Com 3,4 Compares the calculated session key K' S with the session key K 1,2 in the message M 1,2 sent by the first ordinary node Com S :

[0125] If K' S = K S, then both parties have successfully completed the key negotiation, and step 10 is executed.

[0126] If K' S ≠K S , both parties have not calculated the same session key, and the communication ends.

[0127] Step 10, the second ordinary node Com 3,4 notifies the first ordinary node Com 1,2 to encrypt and decrypt the communication content using the session key K. S

[0128] (10.1) The second ordinary node Com 3,4 encrypts the string "Finished" using the session key K S and sends it to the first ordinary node Com , where 1,2 , the encryption method is the symmetric encryption algorithm in the encryption component P 3,4 ;

[0129] (10.2) After receiving the message sent by the second ordinary node Com 1,2 , the first ordinary node Com 3,4 uses the session key K S to decrypt, obtains the string "Finished", and both parties complete the key negotiation. Subsequently, the communication content between the first ordinary node Com 1,2 and the second ordinary node Com 3,4 will be encrypted and decrypted using the session key K S , where the encryption method is the symmetric encryption algorithm in the encryption component P 3,4 .

[0130] The key negotiation algorithm, shared key generation algorithm, and symmetric encryption algorithm in the encryption component P 3,4 are all existing algorithms in the field of cryptography, where:

[0131] The key negotiation algorithm refers to the algorithm in which a node generates a temporary private key r and generates a temporary public key k = f(r) based on the temporary private key.

[0132] The shared key generation algorithm refers to the algorithm in which two nodes respectively generate the same session key K self = f(r other , k S ) self , k other ) based on their own temporary private key r and the other party's temporary public key k.

[0133] The symmetric encryption algorithm refers to the algorithm in which a node uses the same key K when encrypting and decrypting a message.​S algorithm

[0134] The above description is only a specific example of the present invention and does not constitute any limitation to the present invention. Obviously, for professionals in this field, after understanding the content and principle of the present invention, various modifications and changes in form and details can be made without departing from the principle and structure of the present invention. However, these corrections and changes based on the idea of the present invention are still within the scope of protection of the claims of the present invention.

[0135] It should be noted that the step numbers in the specification and claims of the present invention are only for clearly describing the implementation embodiments of the present invention for easy understanding, and there is no limitation on their sequence order.

Claims

1. A vehicle networking communication method based on a consortium blockchain, characterized in that, Including: Constructing a consortium blockchain network with the certificate management center as the central node and vehicle networking devices as ordinary nodes; Each central node CA n issues public key certificates for the ordinary nodes Com n,m it manages. After being consensus by other nodes in the network, the certificate is successfully chained and stored in the blockchain. Here, CA n represents the nth central node, and Com n,m represents the mth ordinary node managed by the nth central node CA n ; Any two ordinary nodes Com in the consortium blockchain network u,i communicate with Com w,j When communicating, they send identity authentication requests to each other and conduct two-way authentication, where Com u,i represents the i-th ordinary node managed by the u-th central node CA u and Com w,j represents the j-th ordinary node managed by the w-th central node CA w ; After the mutual identity authentication is passed, two ordinary nodes Com u,i and Com w,j calculate the same session key K S , and use this session key K S to perform symmetric encryption and then communicate.

2. The method according to claim 1, characterized in that, The construction of the consortium blockchain network with the certificate management center as the central node and vehicle networking devices as ordinary nodes includes: Take N certificate management centers as the N central nodes of the consortium blockchain network: CA = {CA n | 1 ≤ n ≤ N}, where N ≥ 2 represents the number of certificate management centers; Take the same number of Internet of Vehicles devices as ordinary nodes with the same number: Com = {Com n,m | 1 ≤ n ≤ N, 1 ≤ m ≤ M n} Among them, M n ≥ 1 represents the number of ordinary nodes managed by CA n ; It is assumed that the public key certificate of each ordinary node is issued by its affiliated central node, and the public key certificate of each central node is set in advance by each certificate management center. All central nodes and all ordinary nodes jointly form a consortium chain network; The public key certificates of all ordinary nodes in the consortium blockchain network are stored in the blockchain, and each block Node of the blockchain a stores the public key certificates of q ordinary nodes in the vehicle networking, where a represents the height of the blockchain, a ≥ 0, q ≥ 1; Each ordinary node has the right to send a public key certificate query request to the blockchain.

3. The method according to claim 1, characterized in that Each of the central nodes CA n issues a public key certificate for the ordinary node Com it manages, including: n,m ​ Each central node CA n generates a private key PriK n,m , a public key PubK n,m , and a key validity period expiration time VP n,m for each ordinary node Com n,m it manages, and generates a public key certificate Cer n,m for the ordinary node Com n,m based on the information of PriK n,m , PubK n,m , and VP n,m . The public key certificate has a revocation standard bit. A revocation flag bit of '0' indicates that the public key certificate is valid, and a revocation flag bit of '1' indicates that the public key certificate is invalid. Moreover, the central node CA n signs the certificate with its own private key PriK n to obtain a signature Sig n,m = En PriKn (Cer n,m ); Central node CA n Encapsulate the public key certificate Cer n,m into a transaction Tr n,m , and broadcast the transaction Tr in the consortium blockchain network n,m , to complete the issuance of the public key certificate for node Com n,m .

4. The method according to any one of claims 1 to 3, characterized in that, Other nodes in the network perform consensus on the public key certificate, and it is the central node in the consortium blockchain network that verifies the transaction Tr n,m When the number of nodes that pass the verification exceeds 2 / 3 of the total number of central nodes, all nodes in the network consider that the public key certificate recorded in this transaction is legal, and the public key certificate Cer n,m is successfully stored in the blockchain.

5. The method according to claim 1, characterized in that, Any two ordinary nodes Com in the consortium blockchain network u,i and Com w,j When communicating with each other, send identity authentication requests to each other and conduct mutual identity authentication, including: The first ordinary node Com u,i Send an identity authentication request to the second ordinary node Com w,j The second ordinary node Com w,j Authenticate the identity of the first ordinary node Com u,i ; The second common node Com w,j Send an identity authentication request to the first common node Com u,i The first common node Com u,i Authenticate the identity of the second common node Com w,j and make a determination on its identity.

6. The method according to claim 5, wherein The first ordinary node Com u,i sends an identity authentication request to the second ordinary node Com w,j and the second ordinary node Com w,j authenticates the identity of the first ordinary node Com u,i The implementation includes the following: (6a) The first ordinary node Com u,i Generates a timestamp T u,i , and uses the private key PriK u,i to sign the public key certificate Cer u,i of the first ordinary node Com u,i , the timestamp T u,i and the encryption component P u,i supported by the first ordinary node Com u,i to obtain a signature Sig u,i = En PriKu,i (Cer u,i || T u,i || P u,i ), and sends the authentication request Req u,i = {Cer u,i || T u,i || P u,i || Sig u,i} to the second ordinary node Com w,j , where the encryption component P u,i is the key agreement algorithm, shared key generation algorithm, and symmetric encryption algorithm supported by the first ordinary node Com u,i ; (6b) The second ordinary node Com w,j After receiving the authentication request Req u,i sent by the first ordinary node Com u,i calculate the current time T now_w,j and the difference ΔT u,i from the timestamp in the authentication request Req w,j = T now_w,j - T u,i and determine whether ΔT w,j and the timestamp valid threshold satisfy ΔT w,j ≤ T max : If satisfied, it indicates the authentication request Req u,i If the timeliness is satisfied, then execute step (6c); Otherwise, the second ordinary node Com w,j fails to authenticate the identity of the first ordinary node Com u,i ; (6c) The second ordinary node Com w,j sends the public key certificate Cer a of the first ordinary node Com u,i to the nearest blockchain node Node u,i along with a query request; (6d) The blockchain node Node closest to the second ordinary node Com w,j After receiving the query request, start querying the public key certificate Cer from the end of the blockchain a , and after querying the public key certificate Cer u,i , send the verification sequence of the public key certificate Cer u,i to the second ordinary node Com u,i . If the public key certificate Cer w,j is not queried, then send a sequence of all 0s to the second ordinary node Com u,i , indicating that the public key certificate Cer w,j is not found in the blockchain u,i ; (6e) The second ordinary node Com w,j Determine the blockchain node Node a The first ordinary node Com sent u,i The public key certificate Cer u,i Whether the query result sequence of can verify the public key certificate Cer u,i : If the public key certificate Cer can be verified u,i , then step (6f) is executed If the public key certificate Cer cannot be verified u,i , then the authentication of the first ordinary node Com w,j by the second ordinary node Com u,i fails; (6f)Second ordinary node Com w,j Use the first ordinary node Com u,i Public key certificate Cer u,i The public key PubK in u,i For the first ordinary node Com u,i The authentication request Req sent u,i The signature Sig in u,i Verify and determine whether the decryption result is consistent with the authentication request Req u,i The Cer in u,i 、T u,i 、P u,i Are they consistent: If they are consistent, the second common node Com w,j successfully authenticates the identity of the first common node Com u,i ​ If they do not match, the second common node Com w,j fails the authentication of the first common node Com u,i and fails the authentication of the first common node Com 7. The method according to claim 5, wherein The second ordinary node Com w,j sends an identity authentication request to the first ordinary node Com u,i The first ordinary node Com u,i authenticates the identity of the second ordinary node Com w,j The implementation includes the following: (7a) The second common node Com w,j Select an encryption component P from the first common node Com u,i The supported encryption component P u,i Select one encryption component P w,j , the second common node Com w,j Generate a random number r w,j , a timestamp T w,j , and save the random number r w,j As a temporary private key, generate a temporary public key k according to the selected encryption component P w,j = f(r w,j ), where the encryption component P w,j Contains the key negotiation algorithm, shared key generation algorithm, and symmetric encryption algorithm supported by the second common node Com w,j , f(r w,j ) is the key negotiation algorithm in the selected encryption component P w,j , w,j In the key negotiation algorithm;​ (7b) The second ordinary node Com w,j Use the private key PriK w,j To the second ordinary node Com w,j Of the public key certificate Cer w,j , Timestamp T w,j , Temporary public key k w,j And the selected encryption component P w,j Perform signature Sig w,j = En PriKw,j (Cer w,j ||T w,j ||k w,j ||P w,j ), And use the public key PubK of the first ordinary node Com u,i To the second ordinary node Com u,i Of the public key certificate Cer w,j , Timestamp T w,j , Temporary public key k w,j , Encryption component P w,j , And signature Sig w,j And perform encryption to obtain the authentication request Req w,j = En w,j = En PubKu,i (Cer w,j ||T w,j ||k w,j ||P w,j ||Sig w,j ), Then send the authentication request Req w,j To the first ordinary node Com u,i ; (7c) The first ordinary node Com u,i receives the authentication request Req w,j from the second ordinary node Com w,j After that, use the private key PriK u,i to decrypt, and calculate the current time T now_u,i and the difference ΔT w,j from the timestamp in the authentication request Req u,i = T now_u,i - T w,j , and judge whether ΔT u,i and the timestamp valid threshold satisfy ΔT u,i ≤ T max : If satisfied, it indicates that the authentication request Req w,j meets the timeliness requirement and step (7d) is executed. Otherwise, the identity authentication of the first common node Com u,i fails for the second common node Com w,j ; (7d) The first ordinary node Com u,i sends the public key certificate Cer b of the second ordinary node Com w,j to the nearest blockchain node Node w,j along with a query request; (7e) The blockchain node Node closest to the first ordinary node Com u,i After receiving the query request, start querying the public key certificate Cer from the end of the blockchain b , and after querying the public key certificate Cer w,j , send the verification sequence of the public key certificate Cer w,j to the first ordinary node Com w,j . If the public key certificate Cer u,i is not queried w,j , then send a sequence of all 0s to the first ordinary node Com u,i , indicating that the public key certificate Cer w,j is not found in the blockchain; (7f) First ordinary node Com u,i Determine whether the query result sequence sent by blockchain node Node b can verify the public key certificate Cer w,j of the second ordinary node Com w,j : If the public key certificate Cer can be verified w,j , then step (7g) is executed If the public key certificate Cer cannot be verified w,j , then the first ordinary node Com u,i fails to authenticate the identity of the second ordinary node Com w,j ; (7g) The first common node Com u,i Use the second common node Com w,j Public key certificate Cer w,j The public key PubK in w,j For the authentication request Req w,j The signature Sig in w,j Verify and determine whether the decryption result is consistent with the authentication response Rep w,j The Cer in w,j 、T w,j 、k w,j And P w,j Are consistent: If they are consistent, the first common node Com u,i successfully authenticates the identity of the second common node Com w,j ​ If they are inconsistent, the authentication of the second ordinary node Com w,j fails.

8. The method according to claim 1, wherein The first common node Com u,i and the second common node Com w,j calculate the same session key K S , and its implementation includes the following: (8a) The first common node Com u,i Generates a random number r u,i , and saves the random number r u,i as a temporary private key. According to the authentication request Req w,j sent by the second common node Com w,j and the encryption component P w,j in it, generates a temporary public key k u,i = f(r u,i ), where f(r u,i ) is the key agreement algorithm in the encryption component P w,j ; (8b) The first common node Com u,i According to the encryption component P w,j and the second common node Com w,j The authentication request Req sent w,j The k in w,j , generate the session key K S = f(r u,i , k w,j ), where f(r u,i , k w,j ) is the shared key generation algorithm in the encryption component P w,j ; (8c) The first ordinary node Com u,i Generate a timestamp T u',i' , and use the public key of the second ordinary node Com w,j to encrypt the session key K S , the temporary public key k u,i of the first ordinary node Com u,i and the timestamp T u',i' to perform encryption M u,i = En PubKw,j (K S , k u,i , T u′,i′ ), and the first ordinary node Com u,i sends the encrypted message M u,i to the second ordinary node Com w,j . (8c) The second ordinary node Com w,j Receives the encrypted message M u,i Sent by the first ordinary node Com u,i After that, use the private key PriK w,j To decrypt and calculate the current time T now_w',j' And the difference ΔT u,i From the timestamp in the message M w',j' = T now_w',j' - T u',i' To determine whether ΔT w',j' And the timestamp valid threshold satisfy ΔT w',j' ≤ T max : If satisfied, it indicates that message M u,i meets the timeliness requirement, and step (8d) is executed. Otherwise, the second common node Com w,j ends the communication with the first common node Com u,i ; (8d) The second ordinary node Com w,j According to the encryption component P w,j and the first ordinary node Com u,i The message M sent u,i The k in u,i Generate the session key K S = f(r w,j , k u,i ), where f(r u,i , k w,j ) is the shared key generation algorithm in the encryption component P w,j ; (8e) The second common node Com w,j Compare the calculated session key K S with the session key K u,i in the message M u,i sent by the first common node Com S as follows: If they are consistent, the two parties have successfully completed key negotiation and execute step (8f). Otherwise, the two parties have not calculated the same session key and the communication ends. (8f) The second common node Com w,j Use the session key K S Encrypt the string "Finished", and send En KS (Finished) to the first common node Com u,i , the first common node Com u,i After receiving the message sent by the second common node Com w,j Use the session key K to decrypt, and the two parties complete the key negotiation. Among them, the encryption algorithm is the symmetric encryption algorithm in the encryption component P S w,j .​ 9. The method according to claim 1, wherein The use of the session key K S for symmetric encryption is to use the same session key K calculated by both parties S to encrypt and decrypt the communication content between the first ordinary node Com u,i and the second ordinary node Com w,j wherein the encryption is performed using the existing symmetric encryption algorithm in the encryption component P w,j for this purpose

Images