An identity authentication and key agreement method based on lattice cryptography for vehicle networking cross-domain communication
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-05-09
- Publication Date
- 2026-08-11
Smart Images
Figure CN122554082A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of data security, and in particular to a lattice cryptography-based identity authentication and key negotiation method for cross-domain communication in the Internet of Vehicles. Background Technology
[0002] With the widespread adoption of 5G / 6G communication and Vehicle-to-Everything (VANET), terminal devices frequently cross different management domains (such as different operators, cloud service providers, or heterogeneous network areas) for dynamic access and collaboration, placing higher demands on security authentication mechanisms. Against this backdrop, Cross-domain Authenticated Key Agreement (Cross-domain AKA) has become a core component for ensuring end-to-end communication security. Traditional Cross-domain AKA schemes typically rely on Public Key Infrastructure (PKI) or Identity-Based Cryptography (IBC) to achieve inter-domain identity binding and key distribution through trusted third parties (such as CAs or KGCs).
[0003] However, PKI solutions require the exchange and verification of digital certificates in cross-domain interactions, resulting in high communication overhead and high verification latency, making it difficult to meet the needs of low-latency, high-concurrency scenarios (such as autonomous vehicles switching base stations); while IBC solutions simplify public key management, they completely entrust the generation of user private keys to the KGC, which poses a key custody risk, and in cross-domain scenarios, complex trust chains or joint key derivation mechanisms need to be established between multiple KGCs, significantly increasing system complexity.
[0004] To alleviate the aforementioned problems, Certificateless Public Key Cryptography (CL-PKC) has been introduced into cross-domain AKA design. By separating a portion of the private key from the user's secret value, it avoids both certificate management and complete key escrow. In recent years, several certificateless cross-domain AKA protocols based on elliptic curves or bilinear pairings have been proposed, improving efficiency and security to some extent. However, these schemes still heavily rely on classical number theory problems (such as discrete logarithms and bilinear Diffie-Hellman algorithms) and cannot withstand quantum computing attacks. Once practical quantum computers emerge, existing cross-domain authentication systems will face the risk of systemic collapse.
[0005] Meanwhile, in cross-domain communication, sending the signatures of the trusted institution responsible for guarantee and the user themselves leads to additional communication overhead, a disadvantage particularly pronounced in the context of lattice cryptography. To address this, researchers have attempted to introduce aggregatable signature technology to compress the authentication credentials of multiple users into a single signature, enabling batch verification. Current mainstream post-quantum signature schemes (such as Dilithium) do not support signature aggregation and rely on a centralized KGC, making them difficult to adapt to decentralized, asynchronous cross-domain environments.
[0006] Although lattice cryptography has been selected by NIST as a post-quantum cryptography standard (such as Kyber and Dilithium) due to its worst-case difficulty assumptions (such as the Module-SIS and Module-LWE problems), strong quantum security, and good computational efficiency, existing lattice-based schemes mostly focus on single functional modules (such as signing only or key encapsulation only), and have not yet effectively integrated the three capabilities of certificateless architecture, cross-domain key negotiation, and aggregated authentication. In particular, there is a lack of a unified AKA framework that can support certificateless, quantum-resistant, and aggregated verification across different administrative domains.
[0007] In summary, existing technologies have the following key shortcomings when facing the highly dynamic, large-scale, and multi-domain collaborative network environment of the future:
[0008] (1) Relying on non-quantum-resistant cryptographic primitives, security is unsustainable;
[0009] (2) The cross-domain authentication process has high certificate overhead or involves key escrow;
[0010] (3) Lack of support for batch authentication leads to excessive communication overhead;
[0011] (4) The lack of deep collaboration between signature aggregation and key negotiation leads to protocol redundancy.
[0012] Therefore, there is an urgent need to propose a novel cross-domain AKA scheme based on lattice cryptography that enables certificateless aggregated signatures and key negotiation. This scheme should achieve an integrated design of cross-domain identity authentication, session key negotiation, and identity aggregation verification while ensuring post-quantum security, thus providing an efficient, lightweight, and scalable solution for the next generation of secure communication infrastructure. Summary of the Invention
[0013] To address the aforementioned technical problems, this invention provides a modular lattice-based identity authentication and key negotiation method for cross-domain communication in the Internet of Vehicles (IoV). This invention aims to construct a quantum-secure authentication and key negotiation mechanism suitable for cross-domain scenarios, effectively solving the security collapse risk of traditional cross-domain AKA schemes under quantum computing threats and addressing the issues of existing post-quantum schemes focusing on single functions and lacking a complete AKA framework that supports certificateless, aggregateable, and cross-domain collaboration.
[0014] This invention provides a lattice-based cryptographic authentication and key negotiation method for cross-domain communication in vehicle-to-everything (V2X) networks, comprising the following steps:
[0015] S1: System initialization: The Key Generation Center (KGC) determines the public system parameters based on lattice cryptography and generates the system master key according to the security parameters;
[0016] S2: Partial Key Generation: The user and the trusted institution (TA) apply for registration with KGC. The user generates a second part of the encapsulation key for key encapsulation and sends its public key component to KGC. KGC generates a first part of the signature key for signing and a first part of the encapsulation key for key encapsulation for the user, generates a first part of the signature key for signing for TA, and returns it through a secure channel.
[0017] S3: Complete Key Generation: After receiving the partial key returned by KGC, the user and TA each generate a second part of the signing key for signing. The first part of the signing key and the second part of the signing key are combined to obtain the complete key for signing. The user also combines the first part of the encapsulation key and the second part of the encapsulation key to obtain the complete key for key encapsulation.
[0018] S4: Key Encapsulation: When a sending user needs to communicate across domains with a receiving user in another domain, the sending user generates a partial session key and uses the receiving user's key encapsulation public key to perform lattice cryptographic encryption on the partial session key to obtain ciphertext.
[0019] S5: Signature: The sending user and its domain's TA respectively sign the message containing the ciphertext and the receiver user's identity identifier based on lattice cryptography to obtain the user signature and TA signature;
[0020] S6: Aggregated Signature: The sending user aggregates the user signature and the TA signature to obtain an aggregated signature;
[0021] S7: Cross-domain transmission: The sending user sends the aggregated signature, the ciphertext, and the identity identifier to the receiving user;
[0022] S8: Aggregated signature verification: The receiving user performs a one-time verification of the aggregated signature based on lattice cryptography to confirm the legitimacy of the sending user and its domain TA;
[0023] S9: Decapsulation: If the signature verification is successful, the receiving user uses its own key to encapsulate the private key to decrypt the ciphertext and obtain a partial session key generated by the sending user.
[0024] S10: Bidirectional negotiation: The receiving user, as the sender, repeats steps S4 to S7 to send the corresponding aggregate signature and ciphertext to the original sender user; the original sender user executes steps S8 and S9 to obtain a partial session key generated by the receiving user; both parties perform an XOR operation on their respective partial session keys to obtain the complete session key, thus completing cross-domain authentication and key negotiation.
[0025] The beneficial effects of this invention are:
[0026] 1. Effective defense against quantum computing attacks: The core cryptographic components of this application (including certificateless signature and key negotiation) are all built on lattice cryptographic difficult problems. Their security can be reduced to the worst-case computational problem on the lattice, which can effectively resist classical and quantum computing attacks and provide long-term security for identity authentication and key establishment across administrative domains.
[0027] 2. Avoiding key escrow and certificate management issues: This application adopts a certificateless public key cryptography system, where user keys do not need to be bound to digital certificates, thus avoiding the certificate management complexity of PKI systems, significantly reducing the communication and storage burden in cross-domain interactions, and overcoming the full key escrow problem in identity-based cryptography systems, thereby improving the security robustness of the system in multi-domain environments.
[0028] 3. Lower communication overhead: The introduction of an aggregated signature mechanism based on lattice cryptography allows trusted institutions and users in the management domain to efficiently aggregate their authentication signatures. The verifier only needs to verify the identity and legitimacy of cross-domain communication users once, which greatly reduces computational overhead and network latency. It is particularly suitable for high-concurrency cross-domain access scenarios such as vehicle networking and industrial IoT.
[0029] 4. Modularity and scalability: By decoupling identity authentication and session key negotiation into two independent but ordered stages, the authentication result can serve as the trust basis for key negotiation. At the same time, the independent verifiability and replaceability of each module are preserved. This design not only facilitates security analysis and formal verification, but also supports flexible combination with other post-quantum key negotiation protocols in the future, improving the engineering adaptability and evolution capability of the solution. Attached Figure Description
[0030] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.
[0031] Figure 1 This is a schematic diagram illustrating the application scenarios and execution flow of the present invention. Detailed Implementation
[0032] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0033] It should be noted that the terminology used herein is for the purpose of describing particular implementations only and is not intended to limit the exemplary implementations of the present invention.
[0034] like Figure 1 As shown, this embodiment provides a lattice-based cryptographic authentication and key negotiation method for cross-domain communication in the Internet of Vehicles (IoV), including the following steps:
[0035] 1. System initialization: The Key Generation Center (KGC) determines the public system parameters based on lattice cryptography and generates the system master key according to the security parameters;
[0036] The publicly disclosed system parameters include the traditional lattice dimension, the traditional lattice modulus, the modular lattice rank, the polynomial ring dimension, the polynomial ring modulus, and a common matrix based on the polynomial ring. The system master key includes a traditional lattice basis generated based on the trapdoor algorithm and a modular lattice seed key generated based on a random bit string. KGC also determines multiple hash functions and symmetric encryption algorithms.
[0037] In one example, first, given a system security parameter, a prime number is chosen. Choose the traditional grid dimension Calculate the number of rows in a traditional integer cell. Then select two positive real numbers. and Then, the trapdoor algorithm is used to calculate... ,in For public key matrix, As the basis of the corresponding lattice, let For system private key .
[0038] KGC continues to select the rank of the module grid. Noise parameters and Polynomial ring dimension Polynomial ring modulus Determine a polynomial ring .
[0039] KGC defines the following five hash functions: , , , (in It is A matrix, where each column of the matrix comes from the set ), ( (Seed used for sampling).
[0040] KGC will determine another symmetric encryption algorithm to be used within the system. Define a common matrix Define another system private key ∈{ Finally, KGC released the system parameters. .
[0041] 2. After system initialization is complete, users and TAs need to register with KGC. When a TA registers, KGC only generates a partial key for it to use for signing. When a user registers, KGC generates both a partial key for signing and a partial key for key encapsulation.
[0042] The user generates a sampling seed by inputting their own identity and timestamp into the seed hash function, generates the secret vector and noise vector corresponding to the second part of the encapsulation key based on the central binomial distribution sampling algorithm, calculates the corresponding second part of the encapsulation public key, and sends it to KGC.
[0043] KGC generates the first part of the signature key based on the system master key and user identity identifier using a trapdoor sampling algorithm, and generates the first part of the encapsulation key based on the user identity identifier, the second part of the encapsulation public key and the module lattice seed key using a central binomial distribution sampling algorithm.
[0044] In one example, the user first performs the calculation locally. (This step is mainly to prevent different users from having the same public and private keys; the timestamp can be discarded after the seed is generated.) Then, the central binomial distribution sampling algorithm is used. Sampling secret value and noise Let the private key used for key encapsulation Then calculate the corresponding partial public key. Finally, Send them together to KGC to apply for registration.
[0045] After receiving the message, KGC first calculates the portion of the public key used for signing. Then use the matrix sampling algorithm Calculate the partial private key used for signing. Next, KGC generates a partial key for the user to use for key encapsulation: first, a seed is calculated. Similarly, the central binomial distribution sampling algorithm can be used. Sampling secret value and noise This allows some private keys to be used. Then calculate part of the public key. Finally, KGC directly sent two sets of partial public and private keys. It is sent to the user through a secure channel. If the applicant is a TA, KGC will only generate one for them. This refers to the partial key used for signing.
[0046] 3. The user and TA verify whether the first part of the signature key returned by KGC satisfies the linear verification equation based on the public key matrix. If the verification is successful, they sample the secret vector as the second part of the signature key and calculate the corresponding second part of the signature public key.
[0047] The user adds the public key component in the first part of the encapsulated key to the public key component in the second part of the encapsulated key to obtain the complete encapsulated public key, and adds the private key component in the first part of the encapsulated key to the private key component in the second part of the encapsulated key to obtain the complete encapsulated private key.
[0048] In one example, after receiving a partial key from KGC, the user or TA first generates a complete key for signing by following these steps: First, the user or TA verifies whether the received partial public and private keys are valid. If available, accept this partial key and obtain a secret vector through self-sampling using a central binomial distribution. , then calculate Directly ordered ,make Finally, set the full public key used for signing to Set the full private key to For TA, at this point, they have obtained the complete key. For users, it is also necessary to generate a complete key for key encapsulation, that is, directly setting the complete public key used for key encapsulation to be... Make the complete private key as Finally, the user receives the complete key. It contains the complete key used for signing. It also contains the complete key used for key encapsulation. .
[0049] 4. The sending user generates a random source, calculates the initial value of the shared key based on a hash algorithm, samples random vectors and noise using a central binomial distribution sampling algorithm, constructs ciphertext components by encapsulating the complete public key based on the public matrix in the public system parameters and the receiving user's key, and generates the partial session key through FO transformation.
[0050] In one example, when a user from domain A Need to communicate with users from domain B When conducting cross-domain communication, they need to authenticate each other and cooperate to complete key negotiation. First, randomly assign a portion of the key and encrypt and encapsulate it.
[0051] Specifically, Generate a 256-bit random value As a special random source, calculate the initial value of the shared key. Next, through Sampled random vector Random noise ,pass Sampled random noise and calculate and To improve the security of the symmetric key, another FO transformation is performed to obtain a partial shared key. Finally Sent to domain A Waiting for its signature, and preparing to sign it locally.
[0052] 5. The sending user and its domain's TA obtain the participant identity set and the message to be signed, respectively. They calculate the hash value for each participant based on the first hash function and sum them. They calculate the global challenge value based on the second hash function and the local challenge value based on the third hash function. They combine the complete signature private key, the lattice reduction algorithm, and Gaussian sampling to generate the user signature and TA signature containing the signature vector and the global challenge value.
[0053] In one example, receive The message will then be signed to serve as... In addition to the guarantees provided in this communication, It will also affect Sign up. and Each signature is generated independently according to the following steps.
[0054] by For example, it first obtains the identity information of all participants in this signature. Messages awaiting signature ,then Calculate a hash value for each of the two signers. Then calculate a sum , Next, calculate your own hash value. Calculate a global challenge value Further calculate a local challenge value .
[0055] Continue using standard subtraction (LLL algorithm) to find a vector. Make and Subsequently, Calculate signature and with The probability of outputting the signature is determined; if the output fails, the vector needs to be resampled. Then recalculate the signature, and finally output the signature. Similarly, It will output a signature .
[0056] 6. The sending user first verifies whether the global challenge value in the TA signature is consistent with the global challenge value calculated by itself, and verifies whether the TA signature is valid. After both verifications are passed, the user signature and the TA signature are vector-added together to obtain the aggregate signature.
[0057] In one example, The signature will be sent after signing is complete. ,and Two signatures will be aggregated to reduce communication overhead. First, examine Global challenge value in signature If it is equal to your own, then abandon the aggregation and check the signature again. Is it If so, abandon the aggregation; if both requirements are met, calculate the aggregation signature. and aggregate the signature and message Send to .
[0058] 7. The receiving user calculates and sums the hash values of each signing participant based on the first hash function, calculates the global challenge value based on the second hash function, calculates the local hash matrix of each participant based on the third hash function and the identity set of the signing participants, multiplies the public key of each participant's signature part with the corresponding local hash matrix and aggregates them to obtain the aggregated public key, and verifies whether the aggregated signature satisfies the linear equation based on the public key matrix and the preset norm boundary.
[0059] In one example receive Next, verify the correctness of the signature to confirm its validity. Their legal status.
[0060] Specifically, Calculate a hash value for each of the two signers using the method described above. Then calculate a sum Subsequently Calculate a global challenge value ,then, The aggregated public key, which is first... Calculate hash value , and then Calculate hash value Then, aggregate the corresponding public keys separately and calculate... and Finally, let the aggregated public key be... After that, finally Verify if there is And there are If both conditions are met, the signature is accepted and the verification is successful; otherwise, the signature is rejected and the verification fails.
[0061] 8. The receiving user encapsulates the complete private key with its own key and performs vector operations with the ciphertext. The random source is then obtained by decoding with a decoder based on the most significant bit (MSB). The random source is then re-encapsulated to obtain the verification ciphertext. The verification ciphertext is compared with the received ciphertext for consistency. If the comparison is successful, the partial session key is generated.
[0062] In one example, after the signature verification is successful, Begin decrypting the ciphertext of the key.
[0063] Specifically, the recipient receive Calculate first , then calculate The decoder is implemented based on the MSB (Most Significant Bit), and obtains... Then, follow the same steps as described above to encapsulate it. get and Comparison of received and If the two match, a partial session key can be generated following the steps described above. .
[0064] 9. Both parties perform a bitwise XOR operation on their respective partial session keys to obtain the complete session key, and use a symmetric encryption algorithm to encrypt the confirmation information with the complete session key and send it to the other party.
[0065] In one example, Verified Based on the identity, a portion of the session key was calculated. Then, continue with the key negotiation.
[0066] Specifically, Repeat steps 4-6 above to generate another partial session key. And encrypt it, so that The ciphertext is signed by itself, and then the ciphertext and the aggregated signature are sent to... .
[0067] Similarly, follow steps 7-8 to verify the signature and deseal the package, and calculate the results. Finally, the final session key is calculated. and using a symmetric encryption algorithm by Encrypt a confirmation message using the key and send it to... Key negotiation is complete.
[0068] While the specific embodiments of the present invention have been described above in conjunction with the accompanying drawings, this is not intended to limit the scope of protection of the present invention. Those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art without creative effort based on the technical solutions of the present invention are still within the scope of protection of the present invention.
Claims
1. A method for identity authentication and key negotiation based on lattice cryptography for cross-domain communication in vehicle-to-everything (V2X) networks, characterized in that, Includes the following steps: S1: System initialization: The Key Generation Center (KGC) determines the public system parameters based on lattice cryptography and generates the system master key according to the security parameters; S2: Partial Key Generation: Users and trusted organizations (TAs) apply for registration with KGC. Users generate a second part of the encapsulation key for key encapsulation and send its public key component to KGC. KGC generates a first part of the signing key for the user and a first part of the encapsulation key for key encapsulation, respectively, generates a first part of the signing key for the user to sign, and returns it through a secure channel; S3: Complete Key Generation: After receiving the partial key returned by KGC, the user and TA each generate a second part of the signing key for signing. The first part of the signing key and the second part of the signing key are combined to obtain the complete key for signing. The user also combines the first part of the encapsulation key with the second part of the encapsulation key to obtain the complete key used for key encapsulation. S4: Key Encapsulation: When a sending user needs to communicate across domains with a receiving user in another domain, the sending user generates a partial session key and uses the receiving user's key encapsulation public key to perform lattice cryptographic encryption on the partial session key to obtain ciphertext. S5: Signature: The sending user and its domain's TA respectively sign the message containing the ciphertext and the receiver user's identity identifier based on lattice cryptography to obtain the user signature and TA signature; S6: Aggregated Signature: The sending user aggregates the user signature and the TA signature to obtain an aggregated signature; S7: Cross-domain transmission: The sending user sends the aggregated signature, the ciphertext, and the identity identifier to the receiving user; S8: Aggregated signature verification: The receiving user performs a one-time verification of the aggregated signature based on lattice cryptography to confirm the legitimacy of the sending user and its domain TA; S9: Decapsulation: If the signature verification is successful, the receiving user uses its own key to encapsulate the private key to decrypt the ciphertext and obtain a partial session key generated by the sending user. S10: Bidirectional negotiation: The receiving user, acting as the sender, repeats steps S4 to S7 to send the corresponding aggregated signature and ciphertext to the original sender user; The original sender user executes steps S8 and S9 to obtain a partial session key generated by the receiver user; Both parties perform an XOR operation on their respective partial session keys to obtain the complete session key, thus completing cross-domain identity authentication and key negotiation.
2. The method according to claim 1, characterized in that: In step S1, the public system parameters include the traditional lattice dimension, the traditional lattice modulus, the modular lattice rank, the polynomial ring dimension, the polynomial ring modulus, and the common matrix based on the polynomial ring. The system master key includes the traditional lattice basis generated based on the trapdoor algorithm and the modular lattice seed key generated based on the random bit string. KGC also determines multiple hash functions and symmetric encryption algorithms.
3. The method according to claim 1, characterized in that: In step S2, the user generates a sampling seed by inputting their own identity identifier and timestamp into the seed hash function, generates the secret vector and noise vector corresponding to the second part of the encapsulation key based on the central binomial distribution sampling algorithm, calculates the corresponding second part of the encapsulation public key and sends it to KGC; KGC generates the first part of the signature key based on the system master key and user identity identifier using a trapdoor sampling algorithm, and generates the first part of the encapsulation key based on the user identity identifier, the second part of the encapsulation public key and the module lattice seed key using a central binomial distribution sampling algorithm.
4. The method according to claim 1, characterized in that: In step S3, the user and TA verify whether the first part of the signature key returned by KGC satisfies the linear verification equation based on the public key matrix. After the verification is successful, they sample the secret vector as the second part of the signature key and calculate the corresponding second part of the signature public key. The user adds the public key component in the first part of the encapsulated key to the public key component in the second part of the encapsulated key to obtain the complete encapsulated public key, and adds the private key component in the first part of the encapsulated key to the private key component in the second part of the encapsulated key to obtain the complete encapsulated private key.
5. The method according to claim 1, characterized in that: In step S4, the sending user generates a random source, calculates the initial value of the shared key based on a hash algorithm, samples random vectors and noise using a central binomial distribution sampling algorithm, constructs ciphertext components by encapsulating the complete public key based on the public matrix in the public system parameters and the key of the receiving user, and generates the partial session key through FO transformation.
6. The method according to claim 1, characterized in that: In step S5, the sending user and its domain's TA respectively obtain the participant identity set and the message to be signed, calculate the hash value based on the first hash function for each participant and sum them, calculate the global challenge value based on the second hash function, calculate the local challenge value based on the third hash function, and combine the complete signature private key, lattice reduction algorithm and Gaussian sampling to generate the user signature and TA signature containing the signature vector and the global challenge value.
7. The method according to claim 1, characterized in that: In step S6, the sending user first verifies whether the global challenge value in the TA signature is consistent with the global challenge value calculated by itself, and verifies whether the TA signature is valid. After both verifications are passed, the user signature and the TA signature are vector-added to obtain the aggregate signature.
8. The method according to claim 1, characterized in that: In step S8, the receiving user calculates and sums the hash values based on the first hash function for each signing participant, calculates the global challenge value based on the second hash function, calculates the local hash matrix of each participant based on the third hash function and the identity set of the signing participants, multiplies the public key of each participant's signature part with the corresponding local hash matrix and aggregates them to obtain the aggregated public key, and verifies whether the aggregated signature satisfies the linear equation based on the public key matrix and the preset norm boundary.
9. The method according to claim 1, characterized in that: In step S9, the receiving user encapsulates the complete private key with its own key and performs vector operations with the ciphertext. The random source is then decoded using a decoder based on the most significant bit (MSB), and the random source is re-encapsulated to obtain the verification ciphertext. The verification ciphertext is then compared with the received ciphertext for consistency. If the comparison is successful, the partial session key is generated.
10. The method according to claim 1, characterized in that: In step S10, the two parties perform a bitwise XOR operation on their respective partial session keys to obtain the complete session key, and use a symmetric encryption algorithm to encrypt the confirmation information with the complete session key and send it to each other.