An internet of vehicles identity authentication method based on lattice cryptography and block chain

Abstract

The application discloses a kind of based on lattice cryptosystem and double-layer blockchain's vehicle networking security authentication and abnormal protection method this method fuses lattice cryptosystem (MLWE / RLWE), double-layer alliance chain and decentralized identifier DID technology, successively through system initialization, DID registration and lattice key generation, cross-domain authentication and RLWE key negotiation, reputation feedback and abnormal monitoring, five stages of malicious node revocation, build "identity authentication-key negotiation-reputation control-node revocation" full closed loop security system.Adopt MLWE to realize anti-quantum long-term identity authentication, RLWE completes efficient temporary session key negotiation;Double-layer blockchain realizes backbone layer global storage and user layer localization management, reduces consensus delay, improves real-time performance;Combined with DID decentralized identity and blockchain reputation mechanism, realize vehicle cross-domain fast authentication, abnormal accurate identification and malicious node global network isolation.The application has the characteristics of anti-quantum attack, decentralization, high real-time performance, engineering can be landed, etc., suitable for vehicle-to-everything (V2X) scene, can meet the identity of vehicle high dynamic communication, data security and global protection demand.

Description

Technical Field

[0001] This invention belongs to the fields of vehicle networking and blockchain, and specifically to the field of vehicle networking security technology. It relates to an identity authentication method that integrates lattice cryptography, a two-layer blockchain, and a decentralized identifier, suitable for V2X scenarios, and possesses the technical characteristics of resistance to quantum attacks and decentralization. Background Technology

[0002] As a core component of Intelligent Transportation Systems (ITS), the Internet of Vehicles (IoV) enables core functions such as road condition information sharing, cooperative driving, and collision warning through vehicle-to-vehicle (V2V) and vehicle-to-roadside unit (RSU) V2X communication. However, its open wireless communication, highly dynamic network topology, and decentralized node distribution make it vulnerable to serious security threats such as identity forgery, message tampering, and replay attacks.

[0003] Existing vehicle-to-everything (V2X) security authentication solutions have many technical flaws:

[0004] Firstly, mainstream solutions are based on Elliptic Curve Cryptography (ECC) to build encryption and authentication systems. This algorithm is based on the discrete logarithm problem of elliptic curves, which is easily cracked in a quantum computing environment and poses a quantum security risk.

[0005] Secondly, traditional solutions rely on centralized public key infrastructure (PKI), and certificate authorities (CAs) are prone to becoming single points of failure. Furthermore, certificate distribution and verification are inefficient and cannot meet the highly dynamic requirements of vehicle-to-everything (V2X) networks.

[0006] Third, the application of blockchain technology in the Internet of Vehicles mostly adopts a single-layer architecture, and the consensus process involving all nodes in the network results in excessively high consensus latency, making it difficult to meet the real-time requirements of the Internet of Vehicles.

[0007] Fourth, although decentralized identifiers (DIDs) can achieve decentralized identity management, their integration with cryptographic algorithms and blockchain is insufficient, and the efficiency of key negotiation and reputation synchronization during cross-domain authentication is low.

[0008] In summary, existing vehicle-to-everything (V2X) security solutions suffer from weak resistance to quantum attacks, centralized authentication architecture, low efficiency in cross-domain interactions, and high latency in blockchain consensus. There is a need for an integrated security solution that combines post-quantum lattice cryptography, distributed DID identity management, and layered blockchain to balance security and efficiency under the limited resources of V2X and achieve end-to-end, highly reliable security protection. Summary of the Invention

[0009] In view of this, the purpose of this invention is to provide a vehicle network identity authentication method based on lattice cryptography and blockchain.

[0010] The purpose of this invention is to address the aforementioned technical deficiencies of existing vehicle network security authentication schemes and provide a vehicle network security authentication and anomaly protection method based on lattice cryptography and a two-layer blockchain. It integrates three core technologies: lattice cryptography (MLWE / RLWE), a two-layer blockchain, and DID decentralized identity management. The invention explicitly designs cross-domain authentication and RLWE key exchange protocols, DID registration on-chain protocols, reputation feedback update protocols, and malicious node revocation consensus protocols. MLWE enables quantum-resistant long-term identity authentication, RLWE enables efficient temporary session key negotiation, the two-layer blockchain enables a distributed architecture of "global storage + local management," and DID enables vehicle autonomy identity control. Furthermore, by combining the blockchain's reputation management and node revocation mechanisms, a fully closed-loop vehicle network security protection system is constructed, consisting of "DID registration - lattice cryptography authentication - RLWE key negotiation - reputation monitoring - malicious node revocation." All processes clearly define specific execution steps, protocol interaction content, data formats, and judgment rules, allowing those skilled in the art to directly implement the system, thus balancing quantum-resistant security, decentralization, cross-domain efficiency, and engineering feasibility.

[0011] To achieve the above objectives, the present invention adopts the following technical solution:

[0012] A vehicle-to-everything (V2X) security authentication and anomaly protection method based on lattice cryptography and a two-layer blockchain is characterized by comprising five core stages: system initialization, DID registration and lattice cryptography key generation, cross-domain security authentication and RLWE key exchange protocol execution, reputation feedback and anomaly monitoring, and malicious node revocation consensus protocol execution. The entire system consists of five core entities: a Trusted Authority (TA), a backbone blockchain, a user-layer blockchain, Roadside Units (RSUs), and On-Board Units (OBUs).

[0013] 1. Trusted Authority (TA): This is the system's sole root trust node, deployed on high-performance servers, and solely responsible for RSU root trust registration, system-wide parameter configuration, token issuance, and algorithm standard publication.

[0014] 2. Backbone Blockchain: Composed of all authorized RSUs, this consortium blockchain is deployed on the Hyperledger Fabric platform and employs the Practical Byzantine Fault Tolerance (PBFT) consensus algorithm. It has N consensus nodes and a fault tolerance factor f = (N-1) / 3. It is responsible for storing vehicle DIDs, public keys, a list of valid users (VALIDList), and a list of malicious nodes that have been withdrawn (REVList).

[0015] 3. User-layer blockchain: Divided into multiple independent partitions according to the wireless communication coverage of RSUs. Each partition consists of one RSU within its jurisdiction and connected vehicles forming a consortium blockchain. It is also deployed based on Hyperledger Fabric and adopts PBFT consensus. It is responsible for storing the credit score list (RSList) of vehicles within its jurisdiction, realizing localized identity authentication, credit update and anomaly monitoring.

[0016] 4. Roadside Unit (RSU): As a blockchain consensus node and vehicle-to-everything (V2X) communication hub, it is responsible for vehicle registration verification, cryptographic signature verification, RLWE key encapsulation, reputation score updates, malicious node revocation proposal initiation, and blockchain consensus.

[0017] 5. On-board Unit (OBU): Deployed in the vehicle, responsible for generating DID and cipher key pairs, securely storing private key and DID information, initiating cross-domain authentication requests, decapsulating RLWE keys, and signing and broadcasting traffic information.

[0018] In this method, the lattice cryptography algorithm adopts a hybrid MLWE / RLWE architecture, where MLWE is used for long-term vehicle identity authentication and digital signature; RLWE is used for temporary session key encapsulation and negotiation; the blockchain adopts a two-layer consortium blockchain architecture to achieve "global control at the backbone layer + localized processing at the user layer"; DID is implemented based on the Microsoft ION architecture, where the vehicle, as the identity owner, autonomously generates and manages its DID, breaking away from the dependence on a centralized CA and achieving decentralized identity management.

[0019] The five core stages are explained below:

[0020] S1: System Initialization Phase

[0021] A trusted authority (TA) completes the unified configuration of global system parameters, compilation of algorithm modules, and initial deployment of the blockchain network, providing standardized basic parameters, algorithm interfaces, and network environment for all subsequent processes. This stage is executed only once, and the specific steps are as follows:

[0022] 1. Configuration of core parameters for lattice cryptography

[0023] (1) Define the polynomial ring: the core polynomial ring R q = Z q [X] / (X n + 1), where (n=256), Z q It is an integer ring modulo q;

[0024] (2) Define the prime modulus:

[0025] -MLWE Identity Authentication Module: q sign =8380417

[0026] - RLWE key negotiation modulus: q kem =3329;

[0027] (3) Noise distribution setting: The noise terms of both MLWE and RLWE adopt a discrete Gaussian distribution D. σ,0 The standard deviation σ = 3.2;

[0028] (4) Define the dimensions of the MLWE matrix / vector: The MLWE public matrix A∈Rq sign k×l , where (k=4), (l=4); private vector (s1∈Rq) sign l×l ), (s2 ∈ Rq sign k×l The vector coefficients all follow a discrete Gaussian distribution D. σ,0 ;

[0029] (5) Set the signature security limit: The response coefficient security limit of MLWE digital signature is β=8, that is, the absolute value of all coefficients of the signature response z must be less than β, otherwise it is judged as signature leakage.

[0030] 2. Algorithm Module and Hash Function Configuration

[0031] (1) Compile algorithm modules: TA compiles MLWE key generation (KeyGen), signature generation (Sign), and signature verification (Verify) algorithm modules, as well as RLWE temporary key generation, key encapsulation (Encapsulate), and key decapsulation (Decapsulate) algorithm modules;

[0032] (2) Define a secure hash function:

[0033] H0: SHA-256 hash function, used for hashing vehicle identification and traffic information;

[0034] H1: SHA-256 hash function, used for hash calculations of DID documents and blockchain transactions;

[0035] H sig The SHA-256 hash function is used to calculate the challenge value for MLWE signatures. All hash functions satisfy the properties of collision resistance, anti-preimage attack, and anti-second preimage attack.

[0036] 3. Blockchain list definition:

[0037] VALIDList: A core list of the backbone layer, with data formatted as ({DID, PK...). {MLWE} , Tok, REV, TimeStamp} ), where REV is the cancellation flag (0 = valid, 1 = cancelled);

[0038] REVList: Core list of the backbone layer, data format is ({DID, PK) {MLWE} , Tok, RevTime,RevRSU} ), where RevTime is the revocation time and RevRSU is the RSU identifier that initiated the revocation;

[0039] RSList: A core list for the user layer, with data formatted as ({DID, PK)). {MLWE} , RS, UpdateTime} ), where RS is the reputation score (range [0,1)) and UpdateTime is the latest update time.

[0040] 4. DID System

[0041] (1) DID generation rules: The DID format based on the ION architecture is (did:ion:EiDxxxxxxx), which is generated autonomously by the vehicle OBU through SHA-256 hash and Base64 encoding to ensure global uniqueness;

[0042] (2) DID document format: The DID document is in JSON-LD format, and the core fields are...

[0043] {

[0044] "@context": "https: / / w3id.org / did / v1", / / Context definition

[0045] "id": "did:ion:EiC9BzU2X7...", / / : DID unique identifier

[0046] "publicKey": [ / / List of public keys (core authentication field)]

[0047] {

[0048] "id": "did:ion:EiC92X7...#mlwe-pub", / / Public key ID

[0049] "type": "MLWEPublicKey", / / Public key type

[0050] "publicKeyHex": "a1b2c3d4e5f6..." / / Public key plaintext

[0051] }

[0052] ],

[0053] "credential": { Token (identity credential) issued by TA}

[0054] "Tok_Hash": "f8a7b6c5d4e3...", / / Hash of the vehicle's UID)

[0055] "Tok_Sig": "9f8e7d6c5b4a..." / / TA token signature

[0056] },

[0057] "created": "2024-05-20T14:30:00Z" / / Document creation timestamp

[0058] }

[0059] 5. Blockchain network initialization

[0060] (1) Genesis Block Deployment: TA generates a genesis block for the backbone blockchain and all user layer blockchains. The genesis block contains system parameters, consensus node list, algorithm interface address, and DID resolution server address.

[0061] (2) List initialization: In the backbone layer generative block, VALIDList and REVList are initialized as empty lists, and RSList is initialized as an empty list in all user layer generative blocks;

[0062] (3) RSU Root Trust Registration: All RSUs submit their physical identifiers (MAC / IP) to the TA. The TA generates a root public key / private key pair for each RSU and writes the RSU public key into the backbone generative block to complete the root trust registration of the RSU.

[0063] 6. Parameter and Module Release

[0064] The TA sets up a standardized parameter publishing server to publish all the above system parameters across the network. All RSUs and OBUs download and pre-install them through a secure channel, completing system initialization.

[0065] S2: DID Registration and Gradient Cryptography Key Generation Phase

[0066] This phase executes the DID registration and on-chain protocol. Vehicles complete the autonomous generation of their decentralized DID identity, the secure generation of MLWE long-term key pairs, and the on-chaining of the DID document and lattice cryptographic public key. The RSU completes the review, verification, and blockchain consensus of the registration request. This process is executed only once per vehicle and is a prerequisite for vehicle access to the Internet of Vehicles. The specific steps are as follows:

[0067] 1. Vehicle Token Application and Acquisition

[0068] (1) The vehicle OBU generates a unique physical identity identifier (UIDi) (generated by concatenating the vehicle VIN code and MAC address and then hashing it using H0, 256 bits) and obtains the current timestamp t. token ;

[0069] (2) The OBU submits a request data packet to the TA: ({ ReqType: "TokApply", UID: UIDi, TimeStamp: t token} ;

[0070] (3) TA Validation: ① Timestamp Freshness (t) current - t token ≤ 3s, to prevent replay); ② Uniqueness of UIDi (query the local database of TA, no duplicates);

[0071] (4) TA generates tokens: Toki = (TokHash: H0(UIDi), TokSig: Sig) SKTA (H0(UIDi))), TA uses its own root private key to sign;

[0072] (5) The TA returns a response packet to the OBU: { ResType: "TokSuccess", Tok: Toki, TimeStamp: t current .

[0073] 2. DID and DID document self-generation

[0074] (1) The OBU executes the DID generation algorithm to generate a unique DID identifier DIDi, in the format did:ion:EiDxxxxxxx;

[0075] (2) The OBU generates a DID document Doci, in which the publicKey field is written with the hexadecimal encoding of the subsequently generated MLWE public key, the credential field is written with Toki, and the created field is written with the current timestamp;

[0076] (3) The OBU performs H1 hashing on the DID document (Doci) to obtain H(Doci), and stores DIDi, Doci, and H(Doci) locally.

[0077] 3. MLWE Long-Term Key Pair Generation (KeyGen Algorithm)

[0078] The OBU calls the pre-installed MLWE KeyGen algorithm module, and the specific steps are as follows:

[0079] (1) Generate a 256-bit random seed ρ;

[0080] (2) Generate the MLWE public matrix A∈Rq from the seed ρ sign 4×4 ;

[0081] (3) Sample private vectors s1∈Rq according to discrete Gaussian distribution D{σ,0}. sign 4×1 , s2∈Rq sign 4×1 ;

[0082] (4) Perform polynomial ring matrix / vector multiplication: t = A·s1 + s2;

[0083] (5) Determine the MLWE long-term key pair:

[0084] Public key PK {MLWE} = (A, t), and write its hexadecimal encoding into the publicKey field of the DID document;

[0085] Private key (SK) {MLWE} = (s1, s2);

[0086] (6) After the OBU updates the DID document, H(Doc) is recalculated. i )

[0087] 4. Submitting a vehicle registration request

[0088] The OBU submits a DID registration request data packet to the RSU in its current jurisdiction. The data format is as follows:

[0089] {

[0090] ReqType: "DIDReg",

[0091] DID: DIDi,

[0092] Doc: Doci,

[0093] HDoc: H(Doci),

[0094] TimeStamp: t u{reg} ,

[0095] Sig: Sig SK{MLWE} (H(Doci)|| t u{reg} )

[0096] }

[0097] Where Sig is the signature of the MLWE private key pair H(Doci) and the timestamp.

[0098] 5. RSU registration request review and verification

[0099] After receiving a registration request, RSU will perform a four-step verification process. If any verification fails, the registration will be rejected. The specific steps are as follows:

[0100] (1) Timestamp verification: t current - t u{reg} ≤ 1s, otherwise it is judged as a replay attack and the request is discarded;

[0101] (2) DID uniqueness verification: Call the DID parsing server API interface to query whether (DIDi) already exists. If it exists, it is determined to be a duplicate registration and the request is discarded.

[0102] (3) Hash consistency verification: Perform H1 hash on Doci in the request to obtain (H'(Doci)), and determine whether (H'(Doci)) is consistent with (H(Doci)) in the request. If they are inconsistent, discard the request.

[0103] (4) MLWE signature verification: using the (PK) in the request {MLWE} Verify the signature (Sig). If the verification is successful, proceed to the on-chain process; otherwise, discard the request.

[0104] 6. Blockchain On-Chain and Consensus (Core of DID Registration On-Chain Protocol)

[0105] After RSU (Rj) verification is successful, two blockchain consensus transactions are initiated to complete the on-chaining of the DID document backbone layer and the on-chaining of vehicle information at the user layer, respectively. The specific steps are as follows:

[0106] (1) Backbone layer blockchain transactions:

[0107] RSU generates backbone layer transaction data:

[0108] {TxType: "DIDReg",

[0109] DID: DIDi,

[0110] Doc: Doci,

[0111] PKMLWE: PK {MLWE} ,

[0112] Tok: Toki,

[0113] REV: 0,

[0114] TimeStamp: t current ,

[0115] Sig RSU Sig SK{Rj} (DIDi||PK {MLWE} )}

[0116] Broadcast transaction data to all consensus nodes of the backbone blockchain;

[0117] All nodes execute PBFT consensus: proposal → pre-preparation → preparation → submission. If more than (2f+1) nodes confirm, consensus is reached.

[0118] Once consensus is reached, the transaction data is written to a new block in the backbone layer, and the VALIDList is updated, adding the record ({DIDi, PK...). {MLWE} , Toki, 0, t current} );

[0119] (2) User-level blockchain transactions:

[0120] RSU generates user-level transaction data: {

[0121] TxType: "RSInit",

[0122] DID: DIDi,

[0123] PKMLWE: PK {MLWE} ,

[0124] RS: 0.5,

[0125] UpdateTime: t current ,

[0126] SigRSU: Sig SK{Rj} (DIDi||RS)

[0127] };

[0128] - Broadcast the transaction data to all consensus nodes of the blockchain at the user level;

[0129] - All nodes execute PBFT consensus, and consensus is reached when more than (2f+1) nodes confirm.

[0130] - Once consensus is reached, the transaction data is written to a new block at the user level, and RSList is updated, adding the record {DIDi,PK}. {MLWE} , 0.5, t current};

[0131] (3) RSU local cache: (DIDi) and (PK) {MLWE} ), RS=0.5 is cached in the local database for subsequent localized authentication.

[0132] 7. Registration Complete Response

[0133] RSU returns a registration success response packet to OBU:

[0134] {

[0135] ResType: "DID_Reg_Success",

[0136] DID: DIDi,

[0137] RegRSU: Rj,

[0138] TimeStamp: t current ,

[0139] Sig_RSU: Sig SK{Rj} (DIDi)

[0140] After the OBU receives the device, it completes the entire registration process and officially connects to the vehicle network.

[0141] S3: Cross-Domain Security Authentication and RLWE Key Exchange Protocol Execution Phase

[0142] This stage is the core of the invention, clearly designing and implementing a cross-domain authentication and RLWE key exchange protocol. When a vehicle moves from its original RSU jurisdiction to a new RSU jurisdiction, this protocol completes the entire process of "MLWE identity authentication + RLWE temporary key negotiation + encrypted communication establishment," executing once for each cross-domain transaction. The protocol adopts a four-way interaction mode of "vehicle request - RSU verification - RSU encapsulation - vehicle decapsulation," with the specific steps as follows:

[0143] Preconditions of the Agreement

[0144] 1. Vehicle V has completed DID registration and MLWE key generation.

[0145] 2. The new RSU (R{new}) can obtain the vehicle's MLWE public key through the backbone blockchain;

[0146] Protocol interaction process (four interactions, core steps)

[0147] Interaction 1: Vehicle → RSU, cross-domain access request (including RLWE public key signed by MLWE)

[0148] After vehicle V enters the communication coverage area of ​​RSU (R{new}), the OBU automatically initiates a cross-domain access request. The specific steps are as follows:

[0149] 1. RLWE Temporary Key Generation: The steps for OBU to generate a one-time temporary key pair are as follows:

[0150] (1) Sample private polynomials s ∈ Rq kem ;

[0151] (2) Obtain the common polynomial a ∈ Rq from the common polynomial pool. kem ;

[0152] (3) Sampling noise polynomial e ∈ Rq kem ;

[0153] (4) Perform polynomial ring multiplication: b = a·s + e;

[0154] (5) Determine the RLWE temporary key pair:

[0155] Public key PK {RLWE} =b, private key sk {RLWE} =s,

[0156] 2. Construct the core request message: M = { Nonce: N_V, TimeStamp: t_V, PK {RLWE} : PK {RLWE}}, where Nonce is a random number.

[0157] 3. MLWE Signature Generation (Sign Algorithm): The OBU signs message M, and the specific steps are as follows:

[0158] (1) Randomly generate a mask vector y ∈ Rq sign 4×1 ;

[0159] (2) Calculate the commitment value: ( w1 = HighBits(A·y) ), where HighBits is the high-bit extraction operation, which extracts the high 3 bits of each coefficient of the polynomial and hides the low-bit details;

[0160] (3) Calculate the challenge value: c = H sig (M||w1)

[0161] (4) Calculate the signature response: z = y + c·s1 (s1 is (SK) {MLWE} V Private vectors in )

[0162] (5) Reject sampling: Iterate through all coefficients of z. If there is any coefficient whose absolute value is ≥ β = 8, or if there is information leakage in the low bit of w1, discard the current y and return to step (1) to regenerate until the condition is met.

[0163] (6) Determine the signature result: σ V = (z, c);

[0164] 4. Sending a request data packet: The OBU sends a cross-domain access request data packet to R{new}, with the data format being {

[0165] ReqType: "Cross_Domain_Req",

[0166] DID: DIDV,

[0167] M: M,

[0168] σ V : (z, c),

[0169] PK {MLWE} : PK {MLWE} V};

[0170] Interaction 2: RSU → Local / Backbone Layer, Vehicle Public Key Query

[0171] After receiving the request, RSU (R{new}) first obtains the vehicle's MLWE public key, employing a query strategy that prioritizes local caching and uses the backbone layer as a fallback. The specific steps are as follows:

[0172] 1. Parse the request data packet and extract the DID. V PK {MLWE} V ;

[0173] 2. Query the local cache database; if the DID exists... V Corresponding PK {MLWE}V If so, obtain directly and proceed to interaction 3;

[0174] 3. If the local cache is not found, call the backbone blockchain VALIDList query interface and input the DID. V Get the corresponding PK {MLWE} V ;

[0175] 4. If the core layer also fails to find the vehicle, it is determined that the vehicle has not completed registration, and a rejection response is returned: ( {ResType: "Cross_Domain_Fail", Reason: "DID_Not_Reg"} ), and the protocol is terminated.

[0176] Interaction 3: RSU → Vehicle, encrypted response (including RLWE-encapsulated session key + RSU signature)

[0177] RSU ( R{new} ) Get PK {MLWE} V Next, MLWE identity authentication is performed first. After successful authentication, RLWE key encapsulation is performed, and an encrypted response is sent to the vehicle. The specific steps are as follows:

[0178] 1. MLWE identity authentication, the steps are as follows:

[0179] (1) Response coefficient verification: Iterate through the coefficients of the signature response z and determine whether the absolute value of all coefficients is <β. If not, the authentication fails and a rejection response is returned.

[0180] (2) Hash value consistency verification:

[0181] - Using vehicle PK {MLWE} V =(A,t) and signature σ V =(z,c), calculate ( w1' = HighBits(A·z - c·t) );

[0182] - Calculate the challenge value c' = H sig (M||w1');

[0183] - Determine if c' is completely identical to c in the signature. If they are identical, authentication is successful; otherwise, authentication fails and a rejection response is returned: ( { ResType: "Cross_Domain_Fail", Reason: "MLWE_Verify_Fail"} ), and the protocol is terminated.

[0184] 2. RLWE Key Encapsulation: After successful authentication, the RSU generates a symmetric session key and encapsulates it into ciphertext. The steps are as follows:

[0185] (1) Generate symmetric session key: K {shared} ;

[0186] (2) Utilize the vehicle's RLWE temporary public key (PK) {RLWE} =b), generating ciphertext C {KEM} =(u, v), where:

[0187] - u ∈ Rq kem , is a polynomial containing session key information;

[0188] - (v∈Rq) kem ), which is the verification polynomial for the inclusion of noise;

[0189] 3. RSU Signature Generation: RSU uses its own private key SK {Rnew} For ciphertext C {KEM} Perform SM2 signing to obtain σ {rsu} ,

[0190] 4. Sending encrypted response data packet: The RSU sends an encrypted response data packet to the vehicle (V). The data format is as follows:

[0191] {

[0192] ResType: "Cross_Domain_Enc",

[0193] C {KEM} : (u, v),

[0194] σ {rsu} : σ {rsu} ,

[0195] PK {RSU} : PK {Rnew} ,

[0196] TimeStamp: t {R}

[0197] }

[0198] Interaction 4: Vehicle → RSU, handshake confirmation

[0199] After receiving the encrypted response, vehicle V performs RSU signature verification and RLWE key decapsulation, recovers the session key, and sends an encrypted handshake confirmation message to the RSU to complete the protocol execution. The specific steps are as follows:

[0200] 1. RSU signature verification: OBU exploit (PK) {Rnew} ) Verify signature σ {rsu} The SM2 signature verification algorithm is used. If the verification is successful, the process continues; otherwise, the ciphertext is discarded and the protocol terminates.

[0201] 2. RLWE Key Decapsulation: OBU utilizes sk {RLWE} =s decrypts encrypted text C {KEM} , restore K {shared} The steps are as follows:

[0202] (1) Extract ciphertext C {KEM} =(u, v);

[0203] (2) Perform polynomial ring multiplication: (v' = s·u);

[0204] (3) Noise stripping: Extracting the session key (K) from v - v' {shared} );

[0205] 3. Encrypted handshake confirmation: OBU utilizes (K {shared} The session confirmation message (Msg = "HandShake_Success") is encrypted using the AES-256-CTR algorithm, resulting in the ciphertext (C). {Msg} );

[0206] 4. Sending a handshake confirmation packet: The OBU sends a handshake confirmation packet to (R{new}): ({ ReqType:"HandShake_Req", C {Msg} : C {Msg} TimeStamp: t V'} );

[0207] 5. RSU decryption verification: RSU utilizes (K {shared} Decrypt (C) {Msg} After receiving (Msg), and determining that the handshake was successful, a confirmation response is returned to the vehicle: ({ ResType: "HandShake_Success"}).

[0208] S4: Reputation Feedback and Anomaly Monitoring Phase

[0209] This phase executes the reputation feedback update protocol. Based on the "local management + global synchronization" characteristics of a two-layer blockchain, it achieves dynamic updates of vehicle reputation scores and accurate identification of abnormal nodes. Through two-way reputation feedback between vehicles and between vehicles and RSUs, it collects evaluations of the authenticity of road condition messages, providing quantitative evidence for the subsequent removal of malicious nodes. This phase is a continuously executed process, triggered every time a vehicle broadcasts a message. The specific steps are as follows:

[0210] 1. Traffic message broadcasts with MLWE signature

[0211] (1) The OBU of the vehicle Ui collects road condition information (location, speed, road conditions, accidents, etc.) through on-board sensors, generates plaintext messages (msgi), and adds millisecond-level timestamps (t_b) to the messages;

[0212] (2) OBU utilization (SK) {MLWE} i Perform an MLWE signature on (msg_i||t_b) to obtain σ. i ;

[0213] (3) The OBU broadcasts message data packets to surrounding vehicles and local RSUs (Rj) via V2X communication. The data format is as follows:

[0214] {

[0215] MsgType: "Road_Info",

[0216] DID: DIDi,

[0217] PK {MLWE} : PK {MLWE} i ,

[0218] msg: msgi,

[0219] TimeStamp: t_b,

[0220] σ i : σ i

[0221] }

[0222] 2. Triple preliminary verification of the message recipient

[0223] Message recipient (surrounding vehicles (U) k ) or RSU ( R j Upon receiving a message, a triple preliminary verification is first performed. If any verification fails, the message is rejected and an exception is triggered. The steps are as follows:

[0224] (1) Timestamp freshness verification: (t) current - t_b ≤ 500ms) to prevent replay attacks;

[0225] (2) MLWE signature verification: using PK {MLWE} i Verify σ i To ensure the message has not been tampered with;

[0226] (3) Reputation score threshold verification: Query the RSList of the blockchain of the user layer, obtain the current reputation score rsi of Ui, and determine if rsi ≥ ψ (ψ=0.3, the system presets the reputation threshold of normal users). If rsi < ψ, it is determined to be an abnormal node message and is rejected.

[0227] 3. Reputation Feedback Coefficient Generation

[0228] After the recipient verifies the authenticity of the message (msgi) based on the actual road conditions, a reputation feedback coefficient (fc) is generated. {ik} ∈ {0,1}), the rule is:

[0229] - (fc {ik} =0): The message is true and valid, with no false information;

[0230] - (fc {ik} =1): The message is fake or tampered with (such as a fake accident, fake speed, etc.).

[0231] 4. Submitting Reputation Feedback Messages

[0232] The receiver encapsulates the feedback coefficients into a reputation feedback message data packet and sends it to the jurisdictional RSU (R j Submit, data format is:

[0233] {

[0234] ReqType: "RS_Feedback",

[0235] SrcDID: DIDi,

[0236] DstDID: DIDk,

[0237] H_Msg: H0(msg_i||t_b),

[0238] fc: fc {ik} ,

[0239] TimeStamp: t_f,

[0240] σ k Sig SK{MLWE} k}(SrcDID|| fc {ik} ||t_f)

[0241] }

[0242] H_Msg is the hash value of the traffic message, σ k Sign the recipient's MLWE to prevent feedback information from being tampered with.

[0243] 5. Effective feedback screening and global feedback result calculation for RSU

[0244] RSU (R j After collecting all feedback messages for the same message (MSGI), first perform valid feedback filtering, then calculate the global feedback result. The steps are as follows:

[0245] (1) Valid feedback filtering: Remove the following invalid feedback: ① Timestamp expired t current -t_f > 2s; ② Signature verification failed; ③ Feedback party's reputation score rs k <ψ=0.3; The number of valid feedback items n is obtained after filtering;

[0246] (2) Calculation of global feedback results: Count the number n1 of valid feedbacks with fc=1, calculate the proportion r = n1 / n, and determine the global feedback result fc according to the following rules:

[0247] fc = 1, r > 0.5 (Most feedback is false information)

[0248] fc = 0, r < 0.5 (Most feedback is genuine)

[0249] If (r=0.5), it is considered invalid feedback and the reputation score is not updated.

[0250] 6. Vehicle credit score is updated dynamically.

[0251] Based on the global feedback result fc, RSU calls the reputation update formula to update vehicle U. i Reputation score rs i Dynamic updates are performed, all calculations are rounded to four decimal places, and the range of values ​​is strictly limited. The steps are as follows:

[0252] (1) Retrieve U from the user-level RSList i Historical reputation score rs i{past} );

[0253] (2) Substitute into the reputation update formula:

[0254] rs i = ρ1·rs i{past} + ρ2·(-p) fc

[0255] Where: ρ1=0.6 (historical reputation weight), ρ2=0.4 (current behavior weight), ρ1+ρ2=1); p=0.2 (penalty coefficient);

[0256] (3) Value boundary restrictions: If the calculation result rs iIf ≥1, then take rs. i =0.9999; if rs i If <0, then take rs. i =0.0000;

[0257] 7. Credit score blockchain on-chaining and synchronization

[0258] After RSU completes the reputation score update, it initiates a user-level blockchain consensus transaction to achieve localized reputation score updates and cross-domain global synchronization. The steps are as follows:

[0259] (1) Generate user-level transaction data:

[0260] { TxType: "RS_Update",

[0261] DID: DIDi,

[0262] Old_RS: (rs i{past} ,

[0263] New_RS: rs i ,

[0264] UpdateTime: t current ,

[0265] Sig_RSU: Sig SK{Rj} (DID i ||New_RS)} ;

[0266] (2) Broadcast to all consensus nodes of the user-level blockchain;

[0267] (3) After consensus is reached, update U in the user layer RSList. i For the record, change the RS field to rs i UpdateTime changed to t current ;

[0268] (4) Cross-domain synchronization: If vehicle U i In the event of a cross-domain incident, the new jurisdiction RSU can obtain the U from the original jurisdiction's user layer blockchain through the cross-domain reputation query interface of the backbone blockchain. i The latest rs i To achieve cross-domain credit sharing.

[0269] 8. Dual identification and marking of abnormal nodes

[0270] RSU (R j Real-time monitoring of the user-level RSList, achieving dual identification and marking of abnormal nodes through active detection and passive reporting. The steps are as follows:

[0271] (1) Active detection: The RSU traverses the RSList in 1-second cycles. If a vehicle is detected, the RSU will detect it. i If <ψ, it is immediately marked as an abnormal node, and the abnormal time and current reputation score are recorded;

[0272] (2) Passive reporting: If the feedback message submitted by the recipient mentions vehicle rs i If <ψ, then RSU directly marks it as an anomalous node without waiting for the active detection cycle;

[0273] (3) Secondary verification: For marked abnormal nodes, RSU verifies whether they have continuous malicious behavior (such as sending false messages more than 3 times in a row) through multi-source traffic message verification and cross-domain reputation synchronization. If the verification is successful, the malicious node revocation process will be initiated.

[0274] S5: Malicious nodes revoke the consensus protocol execution phase

[0275] Preconditions of the Agreement

[0276] 1. Vehicle U i The node was marked as an anomalous node by RSU and confirmed by secondary verification to have sustained malicious behavior (sending false messages / identity forgery / replay attack more than 3 times in a row).

[0277] 2. Initiating the withdrawal of the RSU (R j This is the user-layer blockchain consensus node in the current jurisdiction of the vehicle, and also a backbone-layer blockchain consensus node;

[0278] Execution process

[0279] Step 1: User-level blockchain consensus, deletion of localized information

[0280] The RSU (R) of the jurisdiction where the malicious node is located j Initiate a user-level deletion consensus transaction to permanently remove the information of malicious nodes from the user-level blockchain. The specific steps are as follows:

[0281] 1. Generate a deletion proposal: RSU (R j Generate a user-level deletion proposal data packet with the following format:

[0282] {

[0283] PropType: "RS_Del",

[0284] DID: DIDi,

[0285] MalType: Malicious behavior type,

[0286] MalEvidence: Hash of evidence of malicious behavior

[0287] ProposerRSU: R j ,

[0288] TimeStamp: t {del} ,

[0289] Sig_RSU: Sig SK{Rj} (DID i ||MalType)

[0290] }

[0291] The hash of malicious behavior evidence is H1 (all malicious behavior evidence), and the evidence includes fake messages, feedback records, verification results, etc.

[0292] 2. Proposal Broadcasting and Consensus: RSU (R j The deletion proposal will be broadcast to all consensus nodes of the blockchain at the user's level.

[0293] 3. PBFT Consensus Voting: All nodes verify the proposal and execute the PBFT consensus.

[0294] 4. Deletion of localized information: After consensus is reached, perform the following operations:

[0295] (1) Write the deletion proposal into a new block at the user level;

[0296] (2) Permanently remove the malicious node U from the user-level RSList. i The record;

[0297] (3) RSU (R) j Delete U from local cache i All information is collected, and all vehicles within the jurisdiction are notified to mark the node as malicious.

[0298] Step 2: Backbone Blockchain Consensus, Global Identity Revocation and Public Key Expiration

[0299] RSU (R j After completing the user-level deletion, immediately initiate a backbone-level reversal consensus transaction to achieve the network-wide identity revocation of malicious nodes and the permanent invalidation of MLWE public keys. The specific steps are as follows:

[0300] 1. Generate a withdrawal proposal: RSU (R j Generate a backbone layer withdrawal proposal data package. The data format is as follows:

[0301] {

[0302] PropType: "Global_Rev",

[0303] DID: DID i ,

[0304] PK_{MLWE}: PK {MLWE} i ,

[0305] Tok: Tok i ,

[0306] MalType: Malicious behavior type,

[0307] MalEvidence: Hash of evidence of malicious behavior

[0308] ProposerRSU: R j ,

[0309] TimeStamp: t {rev} ,

[0310] Sig_RSU: Sig SK{Rj} (DID i ||PK {MLWE} i )

[0311] }

[0312] 2. Proposal Broadcasting and Consensus: RSU will broadcast the revocation of the proposal to all consensus nodes in the backbone blockchain;

[0313] 3. PBFT consensus voting: All RSU nodes verify the proposal and execute the PBFT consensus.

[0314] 4. Global Identity Revocation: After consensus is reached, the following core operations are executed to achieve triple isolation:

[0315] (1) Blockchain layer isolation:

[0316] Permanently remove U from the backbone layer VALIDList i The record;

[0317] Add U to the backbone layer REVList i Revocation record: {DID i PK {MLWE} i , Toki, RevTime:t {rev} RevRSU: R j};

[0318] The backbone blockchain will synchronize the updated REVList to all RSUs and vehicles across the entire network, with a synchronization time of ≤1 second;

[0319] (2) Cryptographic layer isolation:

[0320] Mark (U) i MLWE public key (PK) {MLWE} i This key is permanently invalid. When a signature / authentication request for this public key is received, verification will be rejected directly. The node's RLWE key negotiation request will also be rejected by the entire network, and no session key can be generated.

[0321] (3) Network layer isolation:

[0322] All RSUs received U i Any V2X communication request is rejected directly without any interaction.

[0323] All vehicles received U i When broadcasting messages, they are all discarded without any verification or feedback.

[0324] 5. Revocation Result Notification to the Entire Network: The backbone blockchain sends a revocation result notification to all RSUs and vehicles across the network: { ResType: "Global_Rev_Success", DID: DIDi, RevTime: t {rev} All nodes update their local REVList cache.

[0325] The advantages and beneficial effects of this invention are as follows:

[0326] 1. Technological Integration and Innovation: Deeply integrate three major technologies—MLWE / RLWE lattice cryptography, two-layer blockchain, and DID decentralized identity management—to achieve post-quantum-secure vehicle network security authentication and solve the security threats brought about by quantum computing;

[0327] 2. Innovative Protocol Design: The protocol clearly designs the DID registration on-chain protocol, cross-domain authentication and RLWE key exchange protocol, reputation feedback update protocol, and malicious node revocation consensus protocol. All protocols have clearly defined interaction processes, data formats, and execution steps, and have full engineering feasibility.

[0328] 3. Innovative Architectural Design: Adopting a "two-layer blockchain + TA root trust" architecture, it achieves "global storage + localized management," solving the consensus latency problem of a single blockchain;

[0329] 4. Closed-loop process innovation: A closed-loop security protection system has been built, covering the entire lifecycle of vehicle access, communication, and behavior monitoring in the Internet of Vehicles, from DID registration, grid-based password authentication, and RLWE key negotiation to reputation monitoring and malicious node revocation. Attached Figure Description

[0330] To make the objectives, technical solutions, and advantages of the present invention clearer, the preferred embodiments of the present invention will be described in detail below with reference to the accompanying drawings, wherein:

[0331] Figure 1 A schematic diagram of the vehicle-to-everything (V2X) identity authentication process based on lattice cryptography and blockchain; Detailed Implementation

[0332] Step 1: System Initialization

[0333] TA configures global parameters uniformly:

[0334] 1. Set the lattice cipher polynomial ring parameters: n=256, MLWE modulus q s ᵢ gn =8380417, RLWE modulus q kem =3329, signature security limit β=8;

[0335] 2. Define three types of hash functions: H0 (identity / message hash), H1 (DID / transaction hash), and H... s ᵢ𝑔 (signature challenge hash), all using SHA-256;

[0336] 3. Establish a two-layer blockchain: the backbone chain consists of authorized RSUs, and the user chain is divided according to RSU coverage, both adopting PBFT consensus;

[0337] 4. Initialize the valid list VALIDList, the undo list REVList, and the reputation list RSList;

[0338] Step 2: Vehicle DID Registration and MLWE Key Generation

[0339] 1. The vehicle requests a token from the TA, which verifies the vehicle's unique identifier (UID), issues a token (Tok), and returns it.

[0340] 2. The vehicle's OBU autonomously generates a DID and a DID document, and performs MLWE key generation within the trusted hardware TEE:

[0341] - Generate a public matrix A and sample private vectors s1 and s2;

[0342] - Calculate t = A·s1 + s2 to obtain the public key PK = (A, t) and the private key SK = (s1, s2);

[0343] - Store the private key in the TEE and write the public key into the DID document;

[0344] 3. The vehicle sends a registration request to the local RSU, along with the DID, documentation, and MLWE signature;

[0345] 4. RSU verifies the signature, timestamp, and token validity. Once verified, the DID and public key are uploaded to the backbone chain, and the vehicle reputation value of 0.5 is initialized to the user chain.

[0346] 5. Registration complete, vehicle officially registered with the network.

[0347] Step 3: Cross-domain authentication and RLWE key exchange

[0348] When a vehicle enters the new RSU coverage area, the following shall apply:

[0349] 1. The vehicle generates a one-time RLWE temporary key pair and constructs a request message M (timestamp, random number, temporary public key);

[0350] 2. The vehicle signs M using the MLWE private key, performs rejection sampling to ensure coefficient security, and generates a signature σ=(z,c);

[0351] 3. The vehicle sends {DID, M, σ} to the new RSU;

[0352] 4. The RSU retrieves the vehicle's public key via the DID and performs a two-step verification:

[0353] - Response coefficient verification: The absolute value of the coefficients of all z is less than β=8;

[0354] - Hash consistency verification: c=H s ᵢ𝑔(M||HighBits(Az−ct));

[0355] 5. After successful verification, RSU generates session key K. shared Use the vehicle's temporary public key to perform RLWE encapsulation, generate ciphertext C, and sign it;

[0356] 6. Verify the vehicle's RSU signature, and decapsulate it using the RLWE temporary private key to obtain K. shared ;

[0357] 7. Both sides use K. shared Perform AES-256 encrypted communication, and destroy the temporary key when the session ends.

[0358] Step 4: Reputation Feedback and Anomaly Monitoring

[0359] 1. Vehicle broadcasts traffic updates, accompanied by an MLWE signature and timestamp;

[0360] 2. The receiver verifies whether the signature, timestamp, and sender reputation value are ≥ threshold ψ=0.3;

[0361] 3. The recipient responds with 0 (true) or 1 (false) based on the message's authenticity and then forwards it to the relevant RSU.

[0362] 4. RSU collects valid feedback and determines the overall result based on the majority principle;

[0363] 5. Update vehicle credit according to the formula:

[0364] - Authenticity: Bonus points for reputation; Falsehood: Deduction points for reputation;

[0365] 6. Upload the updated reputation information to the user's blockchain and synchronize it in real time;

[0366] 7. RSU performs regular inspections; nodes with a reputation score < 0.3 are marked as abnormal.

[0367] Step 5: Revocation of Malicious Nodes

[0368] 1. The RSU secondary confirmation abnormal node exhibits malicious behavior such as forged messages and identity impersonation;

[0369] 2. RSU initiates a deletion proposal to the user chain. After the PBFT consensus is passed, the vehicle is removed from the reputation list.

[0370] 3. RSU initiates a global revocation proposal to the backbone chain. After consensus is reached:

[0371] - Move the vehicle DID and public key into the REVList;

[0372] - Mark its MLWE public key as permanently invalid;

[0373] 4. The entire network is simultaneously removed from the list, and all RSUs and vehicles refuse to communicate with this node;

[0374] 5. Malicious nodes are permanently isolated, creating a secure closed loop.

Claims

1. A method for vehicle network security authentication and anomaly protection based on lattice cryptography and a two-layer blockchain, characterized in that, The method includes a system initialization phase, a DID registration and lattice cryptographic key generation phase, a cross-domain security authentication and RLWE key exchange phase, a reputation feedback and anomaly monitoring phase, and a malicious node revocation consensus phase. The entire system consists of five core entities: a trusted authority (TA), a backbone blockchain, a user-layer blockchain, a roadside unit (RSU), and an on-board unit (OBU).

2. The method according to claim 1, characterized in that, The system initialization phase is performed by a trusted authority (TA), and the specific steps are as follows: (1) Configure the core parameters of lattice cryptography, and define the polynomial ring, prime modulus, noise distribution, MLWE matrix / vector dimension and signature security limits; (2) Configure the algorithm module and hash function, compile the MLWE and RLWE algorithm modules, and define the SHA-256 series hash functions; (3) Define the blockchain list, including VALIDList, REVList, and RSList; (4) Establish a DID system and set DID generation rules and DID document format; (5) Initialize the blockchain network, deploy the genesis block, initialize the list and complete the RSU root trust registration; (6) Publish system global parameters.

3. The method according to claim 1, characterized in that, The specific steps for DID registration and lattice cryptography key generation are as follows: (1) The vehicle OBU generates a unique physical identity identifier and applies for and obtains an identity token from the TA; (2) The vehicle autonomously generates DID and DID documents; (3) The vehicle calls the MLWE algorithm to generate a long-term key pair and writes the public key into the DID document; (4) The vehicle submits a DID registration request to the local RSU and attaches an MLWE signature; (5) The RSU verifies the registration request for timestamp, DID uniqueness, hash consistency and MLWE signature; (6) After verification, RSU initiates a two-layer blockchain consensus to complete the on-chaining of DID and public key and the initialization of vehicle reputation; (7) The RSU returns a registration success response to the vehicle.

4. The method according to claim 1, characterized in that, The cross-domain security authentication and RLWE key exchange phase adopts a four-interaction mode, with the following specific steps: (1) The vehicle generates an RLWE temporary key pair, constructs a request message and completes the MLWE signature, and sends a cross-domain access request to the new RSU; (2) After receiving the request, the new RSU queries the vehicle's MLWE public key according to the local cache priority and backbone layer fallback strategy; (3) The RSU completes MLWE identity authentication, performs RLWE key encapsulation and ciphertext signing, and returns a ciphertext response to the vehicle; (4) Verify the RSU signature of the vehicle, perform RLWE key decapsulation to recover the session key, and send an encrypted handshake to confirm the completion of the protocol.

5. The method according to claim 1, characterized in that, The specific steps of the reputation feedback and anomaly monitoring phase are as follows: (1) Vehicle broadcasts traffic information with MLWE signature and timestamp; (2) The message recipient performs a three-fold preliminary verification based on timestamp, MLWE signature, and reputation score; (3) The recipient verifies the authenticity of the message, generates a reputation feedback coefficient, and submits it to the local RSU; (4) Valid feedback is screened by RSU, and the global feedback result is calculated according to the majority principle; (5) The RSU dynamically updates the vehicle credit score based on the credit update formula; (6) The updated reputation score is uploaded to the user-level blockchain and supports cross-domain synchronization; (7) RSU identifies and marks abnormal nodes through both active detection and passive reporting.

6. The method according to claim 1, characterized in that, The reputation update formula is ； Where ρ1 is the historical reputation weight, ρ2 is the current behavior weight, p is the penalty coefficient, and fc is the global feedback result.

7. The method according to claim 1, characterized in that, The malicious node revocation consensus phase consists of two steps: local deletion at the user level and global revocation at the backbone level. Step 1: The local RSU initiates a user-level blockchain consensus to delete malicious node localized information and reputation records; Step 2: RSU initiates consensus on the backbone blockchain, moves the malicious node's DID and public key into the revocation list, marks the MLWE public key as permanently invalid, achieves triple isolation of the blockchain layer, cryptographic layer, and network layer, and synchronizes the revocation results across the entire network.

8. The method according to claim 1, characterized in that, The lattice cryptography algorithm adopts a hybrid MLWE / RLWE architecture, with MLWE used for long-term vehicle identity authentication and digital signatures, and RLWE used for temporary session key encapsulation and negotiation; the blockchain adopts a two-layer consortium blockchain architecture, with the backbone layer responsible for global storage and the user layer responsible for local identity authentication and reputation management.

Images