Blockchain-based identity authentication and data security communication method for internet of vehicles

Abstract

The application discloses a blockchain-based vehicle networking identity authentication and data security communication method, relates to the technical field of vehicle networking communication security, and realizes decoupled parallel processing of communication and authentication through a non-interactive zero-knowledge credit proof mechanism; a decentralized trust graph is constructed through an encrypted behavior token chain to realize point-to-point non-repudiation behavior mutual evaluation; through a key token double-staking mechanism combining a session key component and a behavior token chain hash, the cryptographic binding of communication behavior and credit status is established, and the application can solve the technical contradiction that real-time performance and security of vehicle networking communication are difficult to balance, and significantly improves the overall security protection capability and operation efficiency of the vehicle networking system.

Description

Technical Field

[0001] This invention relates to the field of vehicle network communication security technology, and more specifically, to a blockchain-based vehicle network identity authentication and data security communication method. Background Technology

[0002] Vehicle-to-everything (V2X) communication, as a core infrastructure of intelligent transportation systems, enables key applications such as active safety, cooperative driving, and traffic efficiency optimization through real-time information interaction between vehicles (V2V), vehicles and infrastructure (V2I), and vehicles and pedestrians (V2P). However, the openness, distributed nature, and stringent requirements for real-time communication of V2X expose it to multiple security threats, including identity forgery, data tampering, fake news attacks, and denial-of-service attacks.

[0003] Existing vehicle-to-everything (V2X) security authentication solutions mainly fall into two categories: centralized certificate systems based on PKI and distributed identity solutions based on blockchain. PKI-based solutions rely on trusted third-party Certificate Authorities (CAs) to issue digital certificates for vehicles, posing a single point of failure risk, and certificate revocation has an irreversible lag window of several hours to several days. While blockchain-based distributed solutions solve the single point of failure problem, they still follow a sequential model of "completing the full authentication process first, then authorizing data communication."

[0004] This serial authentication mode has two fundamental flaws: First, the authentication process itself becomes the main bottleneck for communication latency. Even with optimization of the blockchain consensus algorithm, it is impossible to break through the hard constraint that "valid data cannot be exchanged before authentication is completed," and it cannot meet the millisecond-level real-time requirements in emergency scenarios of vehicle networking. Second, all node behavior evaluations are retrospective. When a node's credit score drops or it is marked as malicious, the node may already hold a valid certificate and session key, and can still launch attacks before the revocation takes effect, causing irreparable damage. Summary of the Invention

[0005] This invention aims to solve the aforementioned technical problems by providing a blockchain-based method for vehicle-to-everything (V2X) identity authentication and secure data communication. It achieves decoupling and parallel processing of communication and authentication through non-interactive zero-knowledge credit proofs, enabling the receiver to complete trusted verification locally upon receiving a message. A decentralized trust transfer system between vehicle nodes is constructed using an encrypted behavior token chain. Furthermore, a dual-staking mechanism of session keys and credit token chains elevates communication security from post-event revocation to instant cryptographic disarmament. When a node is found to have acted maliciously, its credit proof key is directly revoked, and the node loses its cryptographic ability to prove its trustworthiness.

[0006] The above objectives can be achieved through the following technical solutions.

[0007] On the one hand, this invention provides a blockchain-based method for vehicle network identity authentication and secure data communication, comprising the following steps:

[0008] Register distributed identity identifiers for vehicle network nodes on the blockchain and bind credit proof key pairs, which are used to generate non-interactive zero-knowledge credit proofs;

[0009] When the first node sends a communication data packet, it generates a zero-knowledge proof and attaches it to the communication data packet. The zero-knowledge proof is used to prove to the receiver that the first node's current credit score is not lower than a preset threshold and does not disclose the credit score.

[0010] The second node receives the communication data packet, verifies the validity of the zero-knowledge proof using the first node's public key of credit proof, and confirms the first node as a trusted node and processes the communication data packet after successful verification.

[0011] The first node and the second node issue encrypted behavior tokens to each other based on communication behavior, forming their own behavior token chains. Positive evaluation tokens are linked together by hash pointers to form a trust chain, and negative evaluation tokens contain irrefutable evidence of violations.

[0012] When the first node and the second node establish an encrypted communication session, they negotiate and generate a shared session key, and then each generates a key token and exchanges them encrypted. The key token is generated as follows: the negotiated shared session key is divided into a first part and a second part; the first part is XORed with the hash value of its current behavior token chain; and the result is encrypted using the public key of the peer node. The shared session key is negotiated and generated using the elliptic curve Diffie-Hellman key exchange algorithm, and has a length of 256 bits, with the first 128 bits being the first part and the last 128 bits being the second part. During communication, the second part is used as a symmetric encryption key, and the first part does not directly participate in data encryption.

[0013] When communication ends normally, both parties disclose their key tokens to complete the token chain update; when a pre-set malicious behavior is detected on the other end of the communication, the injured party terminates the communication, refuses to disclose its own key token, and submits an anomaly report containing evidence of malicious behavior to the blockchain smart contract.

[0014] After the smart contract verifies the anomaly report, it changes the status of the malicious node's credit proof key to revocation, thereby depriving the malicious node of its ability to generate valid zero-knowledge credit proofs.

[0015] As a further improvement of the present invention, the generation and verification of the non-interactive zero-knowledge credit proof is based on a credit proof circuit pre-deployed on the blockchain. The public input of the circuit includes the preset threshold and the credit proof public key of the first node, and the secret input includes the current credit score and the credit proof private key of the first node.

[0016] As a further improvement of the present invention, the communication data packet includes the following fields in sequence: the sender's distributed identity identifier, the zero-knowledge credit proof, a timestamp, encrypted data content, and the hash value of the sender's current action token chain.

[0017] As a further improvement of the present invention, the encrypted behavior token includes an evaluation type field, a previous token hash field, and a signature field; the previous token hash field of the positive evaluation token points to the hash value of the previous token in the sender's token chain, and the signature field is the digital signature of each field of the token by the receiver; the negative evaluation token also includes a description of the violation and an evidence hash.

[0018] As a further improvement of the present invention, after receiving the positive evaluation token and verifying the validity of the signature, the sender appends the positive evaluation token to the end of its own behavior token chain, forming a chain structure with hash pointers connected end to end; when communicating with the third node subsequently, the sender may selectively disclose part or all of the token chain, and the third node establishes trust in the sender by verifying the signature validity of each token in the chain.

[0019] As a further improvement of the present invention, the smart contract changes the credit proof key status of the malicious node to revocation, specifically including: marking the credit proof public key of the malicious node as revoked on the blockchain and broadcasting it to the entire network through a consensus mechanism; the trusted execution environment of the malicious node queries the corresponding public key status on the chain before each generation of zero-knowledge proof, and refuses to execute the proof generation operation when the status is revoked.

[0020] As a further improvement of the present invention, the trusted execution environment is an ARM TrustZone environment, which is used to seal and store the private key of the credit proof and perform zero-knowledge proof generation operations.

[0021] As a further improvement of the present invention, when the smart contract verifies the anomaly report, it also verifies the consistency between the description of the violation and the evidence hash in the negative evaluation token.

[0022] On the other hand, the present invention provides a blockchain-based vehicle network identity authentication and data security communication system, comprising:

[0023] The identity and key registration module is used to register the distributed identity identifiers of vehicle network nodes on the blockchain and bind credit proof key pairs;

[0024] The zero-knowledge proof processing module is used to enable the sending node to generate a communication data packet with a non-interactive zero-knowledge credit proof, and to enable the receiving node to verify the zero-knowledge credit proof to confirm the trust status of the sending party.

[0025] The Behavior Token Chain Management Module is used to enable communication peers to issue encrypted behavior tokens to each other based on communication behavior, and to form a behavior token chain by concatenating hash pointers.

[0026] The dual-staking communication module is used to negotiate the session key when establishing an encrypted communication session, generate and exchange the key token obtained by preset calculation of the session key components and the behavior token chain hash, and use another part of the session key for data encryption.

[0027] The anomaly handling and key revocation module is used to receive malicious behavior anomaly reports, and after verification by the smart contract, change the status of the malicious node's credit proof key to revocation, so that it loses its ability to generate valid zero-knowledge credit proofs.

[0028] In a third aspect, the present invention provides a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the steps of any of the methods described above.

[0029] Compared with the prior art, the advantages of this invention are:

[0030] (1) This invention utilizes a non-interactive zero-knowledge credit proof mechanism, enabling the receiver to immediately process communication data by verifying only a constant-sized proof. This avoids the rigid serial constraint of authentication before communication, achieving complete parallelism between the authentication process and data transmission. Simulation tests show that in a high-density vehicle network scenario with 200 nodes, the average authentication latency of traditional blockchain authentication schemes based on PBFT consensus is 1520 ms, while this method reduces the authentication latency to 0.5 ms, and the communication establishment latency is reduced by approximately three orders of magnitude. Simultaneously, the characteristics of zero-knowledge proofs ensure the privacy of node credit status, disclosing only the necessary information regarding whether the credit meets the requirements to the verifier, without revealing any specific credit value. This effectively protects node privacy while ensuring real-time communication.

[0031] (2) This invention constructs a truly decentralized trust system through a token chain of encrypted behavior, completely delegating the power of credit assessment from centralized institutions to each pair of communication participants, and realizing peer-to-peer non-repudiation mutual evaluation based on direct interactive behavior. Positive evaluation tokens are chained together with hash pointers to form a verifiable trust chain, which can be used to quickly establish trust across nodes; negative evaluation tokens contain tamper-proof cryptographic evidence, ensuring that malicious behavior will inevitably leave a traceable record. Simulation tests show that in a network environment containing 30% malicious nodes, the malicious behavior detection rate of this method reaches 98.7%, which is 16.4 percentage points higher than the detection rate of 82.3% of the traditional roadside unit-based centralized monitoring scheme, and trust determination can be completed without relying on any third-party credit scoring agency.

[0032] (3) This invention establishes a strong cryptographic binding between communication behavior and node credit status through a dual staking mechanism of session keys and credit tokens. Once malicious behavior is detected, the victim can block the credit update path of the malicious node by refusing the public key token, and the smart contract can revoke the credit proof capability of the malicious node from a cryptographic perspective. Simulation tests show that, under the conditions of 10 consensus nodes in the consortium blockchain and a block confirmation time of 3 seconds, the average response time of this method from the detection of malicious behavior to the isolation of the malicious node across the network is 3.2 seconds; while the traditional solution based on the certificate revocation list usually takes 30 minutes to several hours from the revocation of the certificate to the distribution of the information to the entire network. This method compresses the security response delay from minutes to seconds, completely eliminates the lag window of the traditional certificate revocation mechanism, realizes the immediate and proactive isolation of malicious nodes, and fundamentally improves the security and reliability of vehicle network communication. Attached Figure Description

[0033] Figure 1 This is a flowchart illustrating the overall method of the present invention;

[0034] Figure 2 This is a diagram of the communication data packet structure of the present invention;

[0035] Figure 3 This is a schematic diagram of the behavior token chain and key token exchange of the present invention;

[0036] Figure 4 This is a system module architecture diagram of the present invention. Detailed Implementation

[0037] The technical solution of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0038] The system of this invention consists of three core layers:

[0039] Terminal node layer: includes all on-board units (OBU) and roadside units (RSU). Each node is equipped with a Trusted Execution Environment (TEE), which uses ARMTrustZone technology to implement an isolated secure execution environment for sealed storage of private keys and execution of sensitive cryptographic operations.

[0040] Blockchain Network Layer: Employing a permissioned consortium blockchain architecture, authoritative institutions such as traffic management departments, automakers, and roadside unit operators serve as consensus nodes to jointly maintain the blockchain ledger. The blockchain uses the PBFT consensus algorithm, with a block generation time of 1 second and a transaction confirmation time of 3 seconds, meeting the real-time requirements of vehicle-to-everything (V2X) communication.

[0041] Smart Contract Layer: The core contracts deployed on the blockchain include: Identity Registration Contract, Credit Proof Management Contract, and Arbitration Contract. The Identity Registration Contract is responsible for the registration and management of distributed identities of nodes; the Credit Proof Management Contract is responsible for the storage and status updates of credit proof public keys; and the Arbitration Contract is responsible for receiving reports of malicious behavior, verifying evidence, and enforcing penalties.

[0042] Example 1:

[0043] like Figure 1 As shown in the figure, this embodiment provides a blockchain-based method for vehicle network identity authentication and secure data communication. The specific steps are as follows:

[0044] 1.1 Node Registration and Key Binding:

[0045] Register distributed identity identifiers for vehicle network nodes on the blockchain and bind credit proof key pairs. The credit proof key pairs are used to generate non-interactive zero-knowledge credit proofs.

[0046] System global parameter initialization: First, define the system global cryptographic parameters:

[0047] The elliptic curve secp256k1 is chosen as the basis curve for asymmetric encryption and digital signatures. Its base point is G, its order is n, and it satisfies nG=O (the point at infinity).

[0048] Define a hash function H(·) using the SHA-256 algorithm, which can convert input data of any length into a fixed-length output of 256 bits.

[0049] Define a symmetric encryption algorithm E s (·,·), using the AES-128-GCM algorithm, provides both data confidentiality and integrity protection.

[0050] Define an asymmetric encryption algorithm E a(·,·), using the ECIES algorithm, is used to encrypt the transmission key token.

[0051] The preset minimum trust threshold for the entire network is t=60, and the initial credit score of a newly registered node is s. o =100.

[0052] Node key generation: Each vehicular network node generates three independent key pairs within its Trusted Execution Environment (TEE):

[0053] The first group is the identity key pair (sk i d,pk i d), where the identity public key pk i d=sk i d·G, sk i d is a random integer between 1 and n-1.

[0054] The second group is the credit verification key pair (sk cp ,pk cp ), which is specifically generated by the Groth16 zero-knowledge proof system.

[0055] The third group is the token signing key pair (sk token ,pk token ), where the token signing public key pk token =sk token ·G,sk token It is a random integer between 1 and n-1.

[0056] Distributed Identity Generation: A node's Distributed Identity (DID) is generated using the following formula: DID = H(pk i d||timestamp) where timestamp is the current Unix timestamp, and || represents byte concatenation. This identifier is completely decoupled from the vehicle's real physical identity, effectively protecting the node's identity privacy.

[0057] On-chain registration: A node submits a registration transaction to the identity registration contract on the blockchain. The transaction includes the generated distributed identity identifier, identity public key, credit proof public key, token signing public key, hash value H(VIN) of the vehicle's VIN code, and the digital signature of the car manufacturer for all the above information. After verifying the validity of the car manufacturer's signature, the identity registration contract permanently stores the above information on the blockchain, assigns an initial credit score of 100 points to the node, and initializes an empty behavior token chain.

[0058] Sealed private key storage: The node's trusted execution environment (TEE) stores the identity private key, credit verification private key, and token signing private key in a sealed manner. The sealed private keys cannot be exported, copied, or tampered with; only authorized processes running within the TEE can use these private keys to perform cryptographic operations.

[0059] 1.2 Zero-Knowledge Credit Proof Generation

[0060] When the first node sends a communication data packet, it generates a zero-knowledge proof and attaches it to the communication data packet. The zero-knowledge proof is used to prove to the receiver that the first node's current credit score is not lower than a preset threshold and does not disclose the credit score. The generation and verification of the non-interactive zero-knowledge credit proof are based on a credit proof circuit pre-deployed on the blockchain. The public input of the circuit includes the preset threshold and the first node's credit proof public key, and the secret input includes the first node's current credit score and credit proof private key. The generation and verification of the proof are both completed in constant time.

[0061] Credit proof circuit deployment: A credit proof circuit C based on the Groth16 algorithm is pre-deployed on the blockchain. The mathematical definition of this circuit is: C(pk cp ,t,sk cp ,s,r)=1 if and only if s>t where:

[0062] Public input: pk cp (Public key for proof of trust), t (preset trust threshold for the entire network).

[0063] Secret input: sk cp (Private key for credit proof), s (node's current credit score), r (256-bit random number).

[0064] Output: A boolean value indicating whether the credit score is greater than the threshold.

[0065] The circuit generates the corresponding proof key pk prove and verification key vk verify The verification key vk verify It is publicly stored on the blockchain and can be downloaded and obtained by all nodes.

[0066] Zero-knowledge proof generation: When node A needs to send communication data to node B, the following operation is performed within the trusted execution environment to generate a zero-knowledge proof: π = Groth16.Prove(pk prove ,sk cp a ,s a ,t,r a ) where s a Let r be the current credit score of node A. aA 256-bit random number was generated for the trusted execution environment. The generated proof π is 192 bytes in size and takes approximately 0.3 milliseconds to generate, which is constant time complexity and is independent of the node's credit score and the amount of communication data.

[0067] This proof has three properties:

[0068] Completeness: If node A’s current credit score is indeed greater than the trust threshold, then an honest verifier will accept the proof.

[0069] Reliability: If node A’s current credit score is less than or equal to the trust threshold, then no malicious prover can generate an acceptable proof.

[0070] Zero knowledge content: The verifier can only know that node A's credit score is greater than the trust threshold, and cannot obtain any other information about the specific value of the credit score.

[0071] 1.3 Zero-knowledge proof verification and data packet processing

[0072] like Figure 2 As shown, the second node receives the communication data packet, verifies the validity of the zero-knowledge proof using the first node's public key of the credit proof, and confirms the first node as a trusted node after successful verification and processes the communication data packet; the communication data packet contains the following fields in sequence: the sender's distributed identity identifier, the zero-knowledge credit proof, the timestamp, the encrypted data content, and the hash value of the sender's current action token chain.

[0073] Communication data packet structure: The communication data packet generated by node A contains the following five fields in sequence:

[0074] The first field is the Distributed Identity (DID) of the sending node A. a .

[0075] The second field is the zero-knowledge credit proof π generated by node A.

[0076] The third field is the current timestamp, used to prevent replay attacks.

[0077] The fourth field is the data content E encrypted using the second part of the session key, K2. s (K2,data).

[0078] The fifth field is the hash value H(Token_Chain) of the token chain for node A's current behavior. a ).

[0079] Zero-knowledge proof verification: After receiving the data packet, node B first obtains node A's public key pk for credit proof from the blockchain based on the sender's distributed identity identifier in the data packet.cp a Then, using the public key, the network-wide preset trust threshold, and the received zero-knowledge proof as input, the Groth16 verification algorithm is called for verification: result = Groth16.Verify(vk verify ,pk cp a The verification process (π,t) takes about 0.5 milliseconds, which is also a constant time complexity.

[0080] Data packet processing: If the zero-knowledge proof verification result is true, Node B immediately uses the second part of the previously negotiated session key K2 to decrypt the data content and perform the corresponding business processing; if the verification result is false, Node B directly discards the data packet without performing any subsequent processing.

[0081] While decrypting and processing data, Node B performs two auxiliary verification operations in parallel: first, it verifies whether the timestamp in the data packet is within a valid time window (5 seconds before or after the current time); second, it verifies whether the hash value of the behavior token chain in the data packet matches the latest record stored on the blockchain. This achieves fully parallel processing of communication and authentication, avoiding the rigid constraint of serial communication where authentication precedes communication.

[0082] 1.4 Encrypted Behavior Tokens and Trust Chain Construction

[0083] The first and second nodes mutually issue encrypted behavior tokens based on communication behavior, forming their respective behavior token chains. Positive evaluation tokens are linked together by hash pointers to form a trust chain, while negative evaluation tokens contain irrefutable evidence of violations. The encrypted behavior tokens include an evaluation type field, a previous token hash field, and a signature field. The previous token hash field of the positive evaluation token points to the hash value of the previous token in the sender's token chain, and the signature field is the recipient's digital signature of each field of the token. The negative evaluation token also includes a description of the violation and an evidence hash. After receiving a positive evaluation token and verifying the signature's validity, the sender appends the positive evaluation token to the end of its own behavior token chain, forming a chain structure linked end-to-end by hash pointers. When communicating with the third node subsequently, the sender can selectively disclose part or all of the token chain, and the third node establishes trust in the sender by verifying the signature validity of each token in the chain.

[0084] The general structure of a cryptographic behavior token: A cryptographic behavior token contains five fields, in order: evaluation type, previous token hash, timestamp, content, and signature. The formula for generating the signature field is as follows:

[0085] Signature = Sign(sk token β,Type||Prev_Hash||Timestamp||Content)

[0086] Among them, sk token β , is the token signing private key of the receiving node B, and Sign(·,·) is the elliptic curve digital signature algorithm.

[0087] Positive Evaluation Token and Trust Chain Construction: After a successful communication, node B generates a positive evaluation token based on node A's behavior during the communication. The evaluation type field of the positive evaluation token is marked as positive, the content field is empty, and the previous token hash field is filled with the hash value H(Token_Chain) of the last token in node A's behavior token chain. a [-1]), the signature field is the digital signature of the first four fields by node B using its own token signing private key.

[0088] After receiving the positive evaluation token, node A first uses node B's token to sign the public key pk. token β Verify the validity of the signature in the token. If verification is successful, append the token to the end of its own behavior token chain to form a new behavior token chain: Token_Chain. a =Token_Chain a ||Token_eval β This creates a trust chain linked together by hash pointers, where each token carries a signature of a different communication peer.

[0089] Negative Evaluation Token: If Node A engages in malicious behavior during communication, Node B generates a negative evaluation token. The evaluation type field of the negative evaluation token is marked as negative, and the content field contains a detailed description of the violation and the hash value H (Packet) of the communication data packet. Other fields are generated in the same way as the positive evaluation token. The negative evaluation token is non-repudiable because it contains the recipient's digital signature and hash evidence of the communication data packet. Node B submits the generated negative evaluation token directly to the arbitration smart contract on the blockchain. After verifying the signature's validity, the smart contract associates and stores it with Node A's distributed identity identifier.

[0090] Use of the Trust Chain: When node A subsequently establishes communication with node C, it can selectively disclose part or all of its behavioral token chain content. Node C can quickly establish trust in node A by verifying the signature validity of each token in the chain in turn, without relying on any centralized credit scoring agency.

[0091] 1.5 Key Token Generation and Double Staking

[0092] like Figure 3 As shown, when the first node and the second node establish an encrypted communication session, they negotiate to generate a shared session key and then exchange encrypted key tokens. The key token is generated by a preset operation on at least a part of the session key and the hash value of its own behavior token chain. The key token is generated as follows: the negotiated shared session key is divided into a first part and a second part. The first part is XORed with the hash value of its current behavior token chain, and the result is encrypted using the public key of the peer node. The shared session key is negotiated and generated using the elliptic curve Diffie-Hellman key exchange algorithm. It is 256 bits long, with the first 128 bits being the first part and the last 128 bits being the second part. During communication, the second part is used as the symmetric encryption key, and the first part does not directly participate in data encryption.

[0093] Session Key Negotiation: Node A and Node B negotiate a shared session key using the Elliptic Curve Diffie-Hellman (ECDH) key exchange algorithm. The specific process is as follows: Node A generates a temporary private key 'a', calculates a temporary public key A = a·G, and sends it to Node B; Node B generates a temporary private key 'b', calculates a temporary public key B = b·G, and sends it to Node A; Node A calculates the shared key K = a·B; Node B calculates the shared key K = b·A. Finally, both parties obtain a 256-bit shared session key K.

[0094] Session key splitting: The two parties will divide the 256-bit shared session key obtained through negotiation into two equal parts: K1=K[0:128] (the first part of the session key, used to generate the key token) K2=K[128:256] (the second part of the session key, used for data encryption). During the entire communication process, the two parties only use the second part K2 of the session key to encrypt data, and the first part K1 does not directly participate in data encryption transmission.

[0095] Key token generation: Both parties generate their own key tokens, and the mathematical formula is as follows:

[0096] Key_Token a =E a (pk i d β ,K1⊕H(Token_Chain a Key_Token β =E a (pk i d a ,K1⊕H(Token_Chain β ))

[0097] in:

[0098] E a(pk,m) indicates that message m is encrypted using public key pk using ECIES asymmetric encryption, ⊕ indicates bitwise XOR operation, and H(Token_Chain) indicates the SHA-256 hash value of the token chain for the current action.

[0099] Both parties send their generated key tokens to each other, achieving dual staking of the session key and the credit token chain: if either party engages in malicious behavior during communication, the other party will refuse to disclose its key token, thus preventing the malicious party from completing the subsequent credit update process.

[0100] 1.6 Normal Communication End and Credit Update

[0101] When communication ends normally, both parties publicly share their key tokens to complete the token chain update.

[0102] After the communication is successfully completed, both parties shall perform the following operations to complete the credit update:

[0103] Both parties publicly disclose the plaintext of their respective key tokens: Node A uses its own identity private key sk i d a Decrypt the key token sent by node B. β M β =K1⊕H(Token_Chain β Node B uses its own identity private key sk i d β Decrypt the key token sent by node A a M a =K1⊕H(Token_Chain a ).

[0104] Both parties perform consistency verification: Node A calculates K1'=M β ⊕H(Token_Chain β ), verify whether K1' is equal to the first part K1 of the session key negotiated by both parties; Node B calculates K1'=M a ⊕H(Token_Chain a ), and perform the same verification operation.

[0105] After all verifications are successful, both parties submit a credit update transaction to the credit proof management contract on the blockchain, recording evidence of this successful interaction on the chain, and each party's credit score increases by 1 point. Simultaneously, both parties add the positive evaluation token generated from this interaction to their own behavior token chain.

[0106] 1.7 Malicious Behavior Handling and Key Revocation

[0107] When a pre-set malicious action is detected on the communicating peer, the victim terminates communication, refuses to disclose its own key token, and submits an anomaly report containing evidence of the malicious action to the blockchain smart contract. After verifying the anomaly report, the smart contract changes the status of the malicious node's credit proof key to revocation, causing the malicious node to lose its ability to generate valid zero-knowledge credit proofs. The smart contract changes the status of the malicious node's credit proof key to revocation by: marking the malicious node's credit proof public key as revoked on the blockchain and broadcasting it to the entire network through the consensus mechanism; the malicious node's trusted execution environment queries the corresponding public key status on the chain before each zero-knowledge proof generation, and refuses to execute the proof generation operation when the status is revoked.

[0108] Malicious Behavior Detection and Response: If node B detects that node A has sent a false message during communication, it shall immediately perform the following operations: First, immediately terminate all communication with node A; second, refuse to disclose its own key token plaintext; third, generate an anomaly report, the report content of which includes node A's distributed identity identifier, the hash value of the data packet in this communication, the content of the false message and verification evidence, and the hash commitment H(Key_Token) of the undisclosed key token. β ), node B's digital signature, and the generated negative evaluation token.

[0109] Smart Contract Verification and Penalty: Node B submits the generated anomaly report to the arbitration smart contract on the blockchain. The smart contract executes three verification operations in sequence: verifying the validity of Node B's signature; verifying the validity of Node B's signature in the negative evaluation token; and verifying that the hash value of the communication data packet matches the transaction record stored on the blockchain.

[0110] After all verifications are successful, the smart contract executes the following penalty operations: First, based on the severity of the malicious behavior, deduct 50 points from Node A's credit score; Second, generate a key revocation transaction, and PK Node A's credit proof public key on the blockchain. cp a The status changes from "valid" to "revoked"; third, the revocation transaction is broadcast to the entire network through the blockchain consensus mechanism.

[0111] Malicious nodes are immediately isolated: Before each call to generate a zero-knowledge proof, node A's trusted execution environment first queries the status of its own public key for credit proof on the blockchain. If the public key is detected as "revoked," the trusted execution environment immediately refuses to perform the proof generation operation and permanently deletes the sealed-stored private key sk for credit proof. cp a .

[0112] Subsequently, node A is no longer able to generate valid zero-knowledge proofs, and all data packets it sends will be discarded by the receiver due to the failure of zero-knowledge proof verification, thus completely isolating it from the vehicle-to-everything (V2X) communication system. This mechanism achieves instant isolation of malicious nodes at the cryptographic level, completely eliminating the lag window present in traditional certificate revocation mechanisms.

[0113] Example 2:

[0114] like Figure 4 As shown, the system in this embodiment consists of two parts: terminal software deployed on the vehicle network node and smart contracts deployed on the blockchain. The functions and working principles of each module are as follows:

[0115] Identity and Key Registration Module: Deployed in the trusted execution environment of each vehicle network node, it is responsible for generating three sets of key pairs for the node (identity key pair, credit proof key pair, and token signing key pair), according to the formula DID=H(pk i The module generates a distributed identity identifier (d||timestamp) and submits the registration transaction to the identity registration contract on the blockchain. This module is also responsible for the sealed storage and secure access of the private key, ensuring that the private key is not leaked to any unauthorized process.

[0116] Zero-knowledge proof processing module: Deployed in each vehicle-to-everything (V2X) node, it consists of two sub-modules: a generation unit and a verification unit. The generation unit runs in a trusted execution environment and is responsible for processing the zero-knowledge proof according to the formula π=Groth16.Prove(pk prove ,sk cp The function generates a non-interactive zero-knowledge credit certificate (s,t,r) and appends the generated certificate to the communication data packet. The verification unit is responsible for verifying the certificate according to the formula: result=Groth16.Verify(vk verify ,pk cp The function verifies the validity of the zero-knowledge proof (π,t), and immediately notifies the encrypted communication unit to process the data upon successful verification.

[0117] Behavior token chain management module: Deployed in each vehicle network node, responsible for implementing the token chain according to the formula Signature=Sign(sk token This module (Type||Prev_Hash||Timestamp||Content) generates and verifies encrypted behavior tokens and maintains a local behavior token chain. It is also responsible for selectively disclosing part or all of the behavior token chain content according to the request of other nodes when establishing communication, helping them quickly establish trust in this node.

[0118] Dual-staking communication module: Deployed in each vehicle-to-everything (V2X) node, responsible for negotiating and sharing the session key with the communication peer using the elliptic curve Diffie-Hellman algorithm, according to the formula Key_Token=E. a (pk i The module (d, K1⊕H(Token_Chain)) generates and exchanges key tokens, and encrypts and decrypts communication data using the second part K2 of the session key. This module is also responsible for publicly revealing its key token and completing the credit update process when communication ends normally.

[0119] The anomaly handling and key revocation module is divided into a terminal component and a smart contract component. The terminal component is deployed in each vehicle-to-everything (V2X) node, responsible for real-time detection of malicious behavior from the communicating peer, generating anomaly reports, and submitting them to the blockchain. The smart contract component is deployed on the blockchain, responsible for verifying the validity of the anomaly reports, executing credit deduction and credit proof public key revocation operations, and broadcasting the revocation information to the entire network through the blockchain's consensus mechanism.

[0120] Example 3:

[0121] This embodiment provides a computer-readable storage medium storing a computer program that, when executed by the processor of an on-board unit (OBU) or a roadside unit (RSU), can implement all the steps of the blockchain-based vehicle network identity authentication and data security communication method described in Embodiment 1 above.

[0122] Computer-readable storage media can be any medium capable of storing computer programs, such as read-only memory (ROM), random access memory (RAM), hard disk, optical disk, flash memory, etc. Once the computer program stored on this medium is loaded into a processor and executed, it can perform all functions, including node registration, zero-knowledge proof generation and verification, behavioral token chain management, double-staking communication, malicious behavior handling, and key revocation.

[0123] Example 4:

[0124] To verify the technical effectiveness of this invention, a performance comparison test was conducted between the proposed method and a traditional solution in a simulation environment. The test environment configuration was as follows: a total of 200 vehicle network nodes, including 190 vehicle nodes and 10 roadside unit nodes; 10 consensus nodes using the PBFT consensus algorithm in the consortium blockchain; a 5km × 5km urban road grid in the simulation area; and real traffic flow data generated using SUMO for the vehicle movement model. A blockchain authentication scheme based on PBFT consensus was selected as the representative of the traditional solution for comparison.

[0125] Test 1: Comparison of Authentication Latency

[0126] The test scenario involves vehicle nodes randomly initiating communication requests within a simulated area, recording the end-to-end latency from the initiation of the authentication request to the receiver confirming the sender's trustworthiness and beginning data processing. Traditional solutions require a complete PBFT three-stage consensus process, with block generation taking 1 second and transaction confirmation approximately 3 seconds. In high-concurrency scenarios, due to consensus queue queuing, the average authentication latency is 1520ms. This invention employs non-interactive zero-knowledge proof of trust, allowing the receiver to complete verification locally the instant the communication data packet is received, with a verification time of approximately 0.5ms, eliminating the need to wait for any consensus process or remote query. After 1000 communication request tests, the average authentication latency of this method is 0.5ms, with a maximum latency not exceeding 1.2ms, representing a reduction of approximately three orders of magnitude compared to traditional solutions. In high-concurrency scenarios, the latency of traditional solutions increases significantly with the number of concurrent requests, while the latency of this method is unaffected by the number of concurrent requests because the verification process is a local constant-time operation.

[0127] Test 2: Comparison of Malicious Behavior Detection Rates

[0128] Of 200 nodes, 60 were randomly labeled as malicious (30%). Malicious behaviors included sending false security alerts and tampering with relay data packets. Traditional solutions rely on centralized monitoring by roadside units and reporting to a centralized server for behavior evaluation. This invention's solution uses direct interaction between communication partners for point-to-point evaluation and generates encrypted behavior tokens. After 5000 communication interaction tests, the traditional solution achieved a malicious behavior detection rate of 82.3%, with missed detections mainly occurring in areas without roadside unit coverage or in scenarios of selective attacks by malicious nodes. This invention's solution achieved a malicious behavior detection rate of 98.7%, with missed detections mainly concentrated in single, short-duration communication scenarios where behavioral characteristics were insufficient to trigger negative evaluations. This invention effectively eliminates the coverage blind spots of centralized monitoring by decentralizing credit evaluation to communication participants.

[0129] Test 3: Comparison of Malicious Node Isolation Response Time

[0130] The test measured the end-to-end response time from the submission of an anomaly report by the victim to the complete isolation of the malicious node after malicious behavior was detected. In this invention, the victim submits an anomaly report to the arbitration smart contract. After the contract is verified, a key revocation transaction is generated and uploaded to the blockchain. After confirmation by PBFT consensus, it takes effect across the entire network. In a consortium blockchain environment with 10 consensus nodes, the block confirmation time is approximately 3 seconds, and the average time from report submission to the malicious node's public key being marked as revoked is 3.2 seconds. The trusted execution environment of the malicious node detects the revocation status and refuses to execute when generating the zero-knowledge proof again, and the isolation takes effect immediately. Traditional schemes based on certificate revocation lists require certificate revocation information to be issued by the certificate authority and distributed to each node, with a distribution cycle typically ranging from 30 minutes to several hours. In tests with the same network scale, the average revocation distribution delay of traditional schemes is approximately 1800 seconds. This invention reduces the security response delay from minutes to seconds, achieving proactive and immediate isolation of malicious nodes.

[0131] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and not restrictive.

[0132] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style of the specification is merely for clarity. Those skilled in the art should regard the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other implementation methods that can be understood by those skilled in the art.

Claims

1. A blockchain-based method for vehicle-to-everything (V2X) identity authentication and secure data communication, characterized in that: Includes the following steps: Register distributed identity identifiers for vehicle network nodes on the blockchain and bind credit proof key pairs, which are used to generate non-interactive zero-knowledge credit proofs; When the first node sends a communication data packet, it generates a zero-knowledge proof and attaches it to the communication data packet. The zero-knowledge proof is used to prove to the receiver that the first node's current credit score is not lower than a preset threshold and does not disclose the credit score. The second node receives the communication data packet, verifies the validity of the zero-knowledge proof using the first node's public key of credit proof, and confirms the first node as a trusted node and processes the communication data packet after successful verification. The first node and the second node issue encrypted behavior tokens to each other based on communication behavior, forming their own behavior token chains. Positive evaluation tokens are linked together by hash pointers to form a trust chain, and negative evaluation tokens contain irrefutable evidence of violations. When the first node and the second node establish an encrypted communication session, they negotiate and generate a shared session key, and then each generates a key token and exchanges them encrypted. The key token is generated as follows: the negotiated shared session key is divided into a first part and a second part; the first part is XORed with the hash value of its current behavior token chain; and the result is encrypted using the public key of the peer node. The shared session key is negotiated and generated using the elliptic curve Diffie-Hellman key exchange algorithm, and has a length of 256 bits, with the first 128 bits being the first part and the last 128 bits being the second part. During communication, the second part is used as a symmetric encryption key, and the first part does not directly participate in data encryption. When communication ends normally, both parties disclose their key tokens to complete the token chain update; when a pre-set malicious behavior is detected on the other end of the communication, the injured party terminates the communication, refuses to disclose its own key token, and submits an anomaly report containing evidence of malicious behavior to the blockchain smart contract. After the smart contract verifies the anomaly report, it changes the status of the malicious node's credit proof key to revocation, thereby depriving the malicious node of its ability to generate valid zero-knowledge credit proofs.

2. The blockchain-based vehicle network identity authentication and data security communication method according to claim 1, characterized in that: The generation and verification of the non-interactive zero-knowledge credit proof is based on a credit proof circuit pre-deployed on the blockchain. The public input of the circuit includes the preset threshold and the credit proof public key of the first node, and the secret input includes the current credit score and the credit proof private key of the first node.

3. The blockchain-based vehicle network identity authentication and data security communication method according to claim 1, characterized in that: The communication data packet contains the following fields in sequence: the sender's distributed identity identifier, the zero-knowledge credit proof, a timestamp, encrypted data content, and the hash value of the sender's current action token chain.

4. The blockchain-based vehicle network identity authentication and data security communication method according to claim 1, characterized in that: The encrypted behavior token includes an evaluation type field, a previous token hash field, and a signature field; the previous token hash field of a positive evaluation token points to the hash value of the previous token in the sender's token chain, and the signature field is the digital signature of each field of the token by the recipient; the negative evaluation token also includes a description of the violation and an evidence hash.

5. The blockchain-based vehicle network identity authentication and data security communication method according to claim 4, characterized in that: After receiving the positive evaluation token and verifying the validity of the signature, the sender appends the positive evaluation token to the end of its own behavior token chain, forming a chain structure with hash pointers connected end to end. When communicating with the third node later, the sender may selectively disclose part or all of the token chain. The third node establishes trust in the sender by verifying the signature validity of each token in the chain.

6. The blockchain-based vehicle network identity authentication and data security communication method according to claim 1, characterized in that: The smart contract changes the status of the malicious node's credit proof key to revocation, specifically by: marking the malicious node's credit proof public key as revoked on the blockchain and broadcasting it to the entire network through a consensus mechanism; the malicious node's trusted execution environment queries the corresponding public key status on the chain before each zero-knowledge proof generation, and refuses to execute the proof generation operation when the status is revoked.

7. The blockchain-based vehicle network identity authentication and data security communication method according to claim 6, characterized in that: The trusted execution environment is the ARM TrustZone environment, which is used to seal and store the private key of the credit proof and perform zero-knowledge proof generation operations.

8. The blockchain-based vehicle network identity authentication and data security communication method according to claim 7, characterized in that: When verifying the anomaly report in the smart contract, the consistency between the description of the violation and the evidence hash in the negative evaluation token is also verified.

9. A blockchain-based vehicle network identity authentication and data security communication system, characterized in that, include: The identity and key registration module is used to register the distributed identity identifiers of vehicle network nodes on the blockchain and bind credit proof key pairs; The zero-knowledge proof processing module is used to enable the sending node to generate a communication data packet with a non-interactive zero-knowledge credit proof, and to enable the receiving node to verify the zero-knowledge credit proof to confirm the trust status of the sending party. The Behavior Token Chain Management Module is used to enable communication peers to issue encrypted behavior tokens to each other based on communication behavior, and to form a behavior token chain by concatenating hash pointers. The dual-staking communication module is used to negotiate the session key when establishing an encrypted communication session, generate and exchange the key token obtained by preset calculation of the session key components and the behavior token chain hash, and use another part of the session key for data encryption. The anomaly handling and key revocation module is used to receive malicious behavior anomaly reports, and after verification by the smart contract, change the status of the malicious node's credit proof key to revocation, so that it loses its ability to generate valid zero-knowledge credit proofs.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the program implements the steps of the method described in any one of claims 1-8.

Images