A heterogeneous authentication key exchange method based on key encapsulation and digital signature

Abstract

This invention discloses a heterogeneous authentication key exchange method based on key encapsulation and digital signatures, comprising two technical solutions. In the first solution, Alice, the communication initiator, holds a long-term public and private key generated by a key encapsulation mechanism, while Bob, the communication responder, holds a long-term public and private key generated by a digital signature scheme. In the second solution, Alice holds a long-term public and private key generated by the digital signature scheme, while Bob holds a long-term public and private key generated by the key encapsulation mechanism. The long-term public and private keys held by the two parties are generated using different cryptographic primitives. The two parties use a temporary key encapsulation mechanism for key exchange to achieve forward security. When deriving the final session key, not only the temporary shared key generated by the temporary key encapsulation mechanism but also the shared key k generated by the long-term key encapsulation mechanism is used. A / B In the second scheme, the long-term private key of the communication initiator and the state information are used together to generate a temporary public-private key, and the temporary private key is not stored in the state information.

Description

Technical Field

[0001] This invention belongs to the fields of cryptography and information security, and relates to a heterogeneous authentication key exchange method based on key encapsulation and digital signature. Background Technology

[0002] Authentication-based key exchange (AKE) protocols are the cornerstone of secure communication over untrusted networks. Their primary purpose is to establish a shared key between two or more parties, ensuring the confidentiality, integrity, and authenticity of subsequent communications. AKE protocols are crucial in encrypted systems such as HTTPS, VPNs, and messaging services like Signal and iMessage.

[0003] The core concepts of AKE include: (1) Identity authentication, which ensures the true identities of both communicating parties; authentication methods typically involve cryptographic credentials, such as passwords, digital certificates, or pre-shared keys, to prove the identity of one party; strong mutual authentication enhances trust and prevents the risk of impersonation; (2) Key exchange, which refers to the secure establishment of a shared key between the parties. Its goal is to create a session key known only to the communicating parties for subsequent encrypted communication.

[0004] The objectives of AKE include: (1) confidentiality, preventing unauthorized parties from learning about the shared secrets; (2) integrity, ensuring that the shared secrets are not tampered with during the exchange; and (3) authentication, verifying the identity of all relevant parties.

[0005] (1) The urgency and challenges of post-quantum transfer

[0006] With the rapid development of quantum computing technology, the security of the traditional AKE protocol faces severe challenges. Quantum algorithms can break classical cryptographic assumptions based on large integer factorization and discrete logarithm problems in polynomial time, making existing AKE protocols vulnerable in the context of quantum computing. To address this, the National Center for Cybersecurity Excellence (NCCoE) has emphasized the importance of migrating cryptographic systems to post-quantum cryptography (PQC) and has developed a framework to guide enterprises in adopting PQC solutions while maintaining system flexibility to adapt to future developments in quantum-resistant algorithms.

[0007] The flexibility of post-quantum migration refers to the ability of cryptographic systems to integrate new post-quantum algorithms without significantly altering existing infrastructure. This capability is crucial for ensuring a smooth transition from classical cryptographic systems to quantum-resistant systems, while minimizing operational disruptions and protecting data integrity.

[0008] However, in actual migration, the progress of different systems varies significantly. For example, some systems may have updated their long-term key pairs to quantum-resistant key encapsulation (KEM), while others may still be using long-term key pairs with classical signatures or have only updated their long-term key pairs with quantum-resistant signature algorithms. This asynchronous migration leads to differences in the functional types of digital certificates used by different institutions and entities, thus placing higher demands on the compatibility of authentication key exchange protocols.

[0009] In quantum-resistant migrations, updating software code is relatively easy, while updating certificates presents a greater challenge. Software code updates can be quickly accomplished through version iterations and deployment tools, but updating certificates involves significant infrastructure modifications, coordination with Certificate Authorities (CAs), and adaptation of end devices—a process that is large-scale, costly, and time-consuming. Furthermore, certificate updates must consider compatibility with existing systems to avoid business interruptions due to certificate replacement. Therefore, in actual migrations, software code updates often precede certificate updates, further exacerbating the problem of migration asynchrony.

[0010] (2) Limitations of the existing AKE protocol

[0011] Existing practical certified key exchange protocols typically require both communicating parties to hold long-term key pairs generated from the same cryptographic primitives. For example, authenticated DH key exchange requires both parties to hold long-term signature key pairs, while the HMQV protocol requires both parties to hold long-term DH key pairs. Furthermore, due to the efficiency and size limitations of post-quantum secure signature algorithms, international standardization organizations are promoting certified key exchange protocols based on key encapsulation mechanisms. These protocols require both parties to hold long-term encapsulated key pairs. These requirements conflict with heterogeneous scenarios caused by asynchronous migration (i.e., both communicating parties holding long-term key pairs with different functionalities). Existing practical certified key exchange protocols, where both communicating parties use the same cryptographic primitives to generate long-term keys, lack migration agility and are not well-suited to situations where PQC migration progresses inconsistently across systems.

[0012] (3) Attempts and shortcomings in theoretical research

[0013] In theoretical research, some attempts have been made to design AKE protocols that adapt to heterogeneous scenarios, but these have failed to meet real-world requirements. For example, Jager et al. (Tibor Jager, Eike Kiltz, Doreen Riepel, Sven...) In 2021, Tightly-Secure Authenticated Key Exchange (Revisited.EUROCRYPT(1)2021:117-146) proposed a scheme in which the initiator holds the long-term key for signing and the responder holds the long-term key for key encapsulation. The authentication key exchange is completed in one round of interaction, aiming to achieve compact reduction. However, the component properties required by this scheme are too strong, the performance is not suitable for practical scenarios, and it is difficult to instantiate using post-quantum-safe algorithms. It is only applicable to classical assumptions. In 2023, Boyd et al. (Colin Boyd, Bor de Kock, Lise Millerjord: Modular Design of KEM-Based Authenticated Key Exchange.ACISP 2023:553-579) proposed a modularly designed AKE protocol, in which two designs include schemes in which both parties hold the signature and KEM long-term key respectively, and the authentication key exchange is completed in 1.5 rounds of interaction. One design, simplified to a single-round interaction, can be covered by the scheme proposed by Jager et al. in 2021. However, this scheme cannot guarantee security when an adversary obtains the state information of the long-term key holder, resulting in low security. Another design, while achieving perfect forward security, is difficult to reduce to a single-round protocol with weak forward security and cannot guarantee security when state information is leaked. Caribé (Mark Diamantino Caribé: A Novel Post-quantum AuthenticatedKey Establishment Protocol. Master's Thesis. 2023) also proposed a scheme in 2023 where the initiator holds the long-term key for signing and the responder holds the key encapsulated in the long-term key, but it does not provide rigorous security proofs, only using the Verifpal formal analysis tool for analysis. Since Verifpal is a symbolic model tool, it can only perform falsification and cannot replace security proofs; furthermore, this scheme cannot guarantee security when state information is leaked. Furthermore, there is currently no theoretical research involving a single-round interaction scheme where the initiator holds the key encapsulated in the long-term key and the responder holds the long-term key for signing to complete the authentication key exchange.

[0014] Therefore, designing a practical authentication key exchange protocol that can adapt to different PQC cryptographic primitives is crucial. A flexible approach that allows communicating parties to use different PQC cryptographic primitives as long-term keys (e.g., one party uses a PQC key encapsulation algorithm, and the other uses a PQC signature algorithm) will facilitate secure and interoperable communication in diverse and evolving PQC migration environments. This heterogeneous practical AKE protocol not only solves the compatibility issues caused by migration asynchrony but also provides stronger guarantees for communication security in the post-quantum era. Summary of the Invention

[0015] To address the problems existing in the prior art, the purpose of this invention is to provide a heterogeneous authentication key exchange method based on key encapsulation and digital signature. In this invention, the communicating parties use different cryptographic primitives to exchange heterogeneous authentication keys, enabling them to still exchange authentication keys even when their progress in post-quantum migration is asynchronous. This ensures compatibility with different national standards and helps enterprises seamlessly transition to quantum-safe systems without being limited to a single, rigid method.

[0016] The technical solution of this invention is as follows:

[0017] A heterogeneous authentication key exchange method based on key encapsulation and digital signatures is proposed, with the underlying cryptographic primitive being an IND-CPA secure key encapsulation scheme, KEM. CPA = (KGen, Encap, Decap), an IND-CCA secure key encapsulation scheme KEM CCA = (KGen, Encap, Decap) and an EUF-CMA secure digital signature scheme Sig = (KGen, Sign, Verify), and a hash function H: in This is the session key space, where Alice and Bob, the two legitimate communicating parties, are aware in advance of each other's key encapsulation scheme, KEM. CPA KEM CCA The digital signature scheme Sig and the hash function H, the steps of which include:

[0018] 1) Alice uses KEM CCA .KGen generates a long-term public-private key pair (pk A ,sk A And had shared the public key pk with Bob before the authentication key exchange began. A Bob used Sig.KGen to generate a long-term public-private key pair (pk). B ,sk B And shared the public key pk with Alice before the authentication key exchange began. B ;

[0019] 2) Alice uses KEM CPA .KGen generates a temporary public-private key pair. Stored as state information, and a temporary public key is sent to Bob.

[0020] 3) After receiving the message, Bob uses the received temporary public key. conduct Obtain the ciphertext and the corresponding shared key And using Alice's long-term public key PK A Perform KEM CCA .Encap(pk A ) Obtain the ciphertext c B and shared key k B Then use your own long-term private key sk B For temporary public keys Both parties' long-term public key (pk) A ,pk B The two ciphertexts obtained through encapsulation and c B Sign For both parties' long-term public keys (pk) A ,pk B ), received temporary public key Cipher Cipher c B Shared key and shared key k B The final session key is obtained by hashing. Bob will Send to Alice;

[0021] 4) Alice received from Bob Then, retrieve the temporary public key from the state information. Concatenate known long-term public key for PK A Long-term public key PK with the other party B and received and c B Thus, the signed message is obtained. Alice uses Bob's long-term public key to PK. B Verify the signature σ

[0022] If verification fails, the session is terminated; if verification succeeds, Alice uses the temporary private key stored in the state.

[0023] For the received ciphertext conduct Decapsulate to obtain the shared key. Use your own long-term private key sk A For the received ciphertext c B Perform KEM CCA .Decap(sk A ,c B Decapsulation yields the shared key k. B ; for the long-term public key (pk) of both parties A ,pk B Temporary public key Received ciphertext and ciphertext c B Shared key and shared key k B The final session key is obtained by hashing.

[0024] A heterogeneous authentication key exchange method based on key encapsulation and digital signatures is proposed, with the underlying cryptographic primitive being an IND-CPA secure key encapsulation scheme, KEM. CPA = (KGen, Encap, Decap), an IND-CCA secure key encapsulation scheme KEM CCA = (KGen, Encap, Decap) and an EUF-CMA secure digital signature scheme Sig = (KGen, Sign, Verify), and two different hash functions H: in It is the session key space. It is KEM CPA The random number seed space used by KGen to generate the private key is known in advance by Alice and Bob, the two parties in legitimate communication, to the key encapsulation scheme KEM used by the other. CPA KEM CCA The digital signature scheme Sig and the hash function H, the steps of which include:

[0025] 1) Alice uses Sig.KGen to generate a long-term public-private key pair (pk). A ,sk A And had shared the public key pk with Bob before the authentication key exchange began. A Bob uses KEM CCA .KGen generates a long-term public-private key pair (pk B ,sk B And shared the public key pk with Alice before the authentication key exchange began. B ;

[0026] 2) Alice generates random numbers r through uniform random sampling, and for (r, sk) A Hash the result to get r′=G(r,sk) A ), r′ as KEM CPA .KGen uses a random number seed to generate temporary public and private keys. Use Bob's long-term public key to pk B Perform KEM CCA .Encap(pk B Obtain the shared key k A and ciphertext c A Then use your own long-term private key sk A For temporary public keys Both parties' long-term public key (pk) A ,pk B ), the ciphertext obtained by encapsulation A Sign

[0027] Alice will Send to Bob, with (r,k) A ,c A ) is stored as status information;

[0028] 3) Bob received the message sent by Alice. Then, use the temporary public key. Concatenate known long-term public key for PK A PK of one's own long-term public key B And the received ciphertext c A Thus, the signed message is obtained. Bob uses Alice's long-term public key to PK. A For signature σ and signature message Verification If verification fails, the session will terminate; if verification succeeds, Bob will use the received temporary public key. conduct Obtain the ciphertext and the corresponding shared key Use your own long-term private key sk B For the received ciphertext c A Perform KEM CCA .Decap(sk B ,c A Decapsulation yields the shared key k. A Then, the long-term public key (pk) of both parties is... A ,pk B ), received temporary public key Cipher Cipher c A Shared key and shared key k A The final session key is obtained by hashing. Bob will cipher Send to Alice;

[0029] 4) Alice receives the cipher from Bob. Then, using the random number r stored in the state, perform operations on (r, sk) A Hash the result to get r′=G(r,sk) A Using r′ as KEM CPA The .KGen random number seed is used to recover the temporary public and private keys.

[0030] Then use the temporary private key. For ciphertext conduct Decapsulate to obtain the shared key. For both parties' long-term public keys (pk) A ,pk B Temporary public key Received ciphertext The ciphertext c stored in the state A Shared key k A Shared key The final session key is obtained by hashing.

[0031] The advantages of this invention are as follows:

[0032] This invention constructs an authentication key exchange protocol using a heterogeneous approach, possessing post-quantum oracle model security. It is more flexible than existing solutions, adapting to the agility requirements of post-quantum cryptography migration. It exhibits significant advantages in application scenarios where the computing power of the communicating parties is unequal. For different actual application scenarios, the appropriate protocol scheme can be flexibly selected according to the needs, providing reliable security for communicating parties with different computing power, and has strong practical application value. Attached Figure Description

[0033] Figure 1 Flowchart of a design scheme for a heterogeneous authentication key exchange protocol.

[0034] Figure 2 Flowchart for Scheme 2 of the Heterogeneous Authentication Key Exchange Protocol Design.

[0035] Figure 3 This is a comparison chart of the communication volume between the two parties under NIST security level 1 for Scheme 1.

[0036] Figure 4 This is a comparison chart of the communication volume between the two parties under NIST security level 1 for Scheme 2.

[0037] Figure 5 This is a comparison chart of the local computation efficiency (logarithm of CPU cycles) of both parties under NIST security level 1 for Scheme 1.

[0038] Figure 6 This is a comparison chart of the local computation efficiency (logarithm of CPU cycles) of both parties under NIST security level 1 for Scheme 2. Detailed Implementation

[0039] The present invention will now be described in further detail with reference to the accompanying drawings. The examples given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0040] The heterogeneity of this invention refers to the fact that the long-term keys held by the communicating parties are generated from different cryptographic primitives. This invention includes two schemes with the same technical concept, such as... Figure 1 As shown, the technical method of Scheme 1 is as follows:

[0041] A heterogeneous authentication key exchange method is based on the underlying cryptographic primitive KEM, an IND-CPA secure key encapsulation scheme. CPA = (KGen, Encap, Decap), an IND-CCA secure key encapsulation scheme KEM CCA = (KGen, Encap, Decap) and an EUF-CMA secure digital signature scheme Sig = (KGen, Sign, Verify), and a hash function H: in This is a session key space applicable to both Alice and Bob, who are legitimate communicators. Both parties are aware in advance of the three schemes and H used. The method includes the following steps:

[0042] 1) Alice uses KEM CCA .KGen generates a long-term public-private key pair (pk A ,sk A And had shared the public key pk with Bob before the authentication key exchange began. A ;

[0043] 2) Bob uses Sig.KGen to generate a long-term public-private key pair (pk). B ,sk B And shared the public key pk with Alice before the authentication key exchange began. B ;

[0044] 3) Alice uses KEM CPA .KGen generates a temporary public-private key pair. Stored as state information, and a temporary public key is sent to Bob.

[0045] 4) After receiving the message, Bob uses the received temporary public key. conduct Obtain the ciphertext and the corresponding shared key Using Alice's long-term public key PK A Perform KEM CCA .Encap(pk A ) Obtain the ciphertext c B and shared key k B Then use your own long-term private key sk B For temporary public keys Both parties' long-term public key (pk) A ,pk B The two ciphertexts obtained through encapsulation and c B Sign For both parties' long-term public keys (pk) A ,pk B ), received temporary public key The above steps yielded c B , and k B The final session key is obtained by hashing. Bob will Send to Alice.

[0046] 5) Alice received from Bob Then, retrieve the temporary public key from the state information. Concatenate known long-term public key for PK A Long-term public key PK with the other party B and received and c B Thus, the signed message is obtained. Alice uses Bob's long-term public key to PK. B Verify the signature σ If verification fails, the session is terminated. If verification succeeds, Alice uses the temporary private key stored in the state. For received conduct Decapsulate to obtain the shared key. Use your own long-term private key sk A For the received ciphertext c B Perform KEM CCA .Decap(sk A ,cB Decapsulation yields the shared key k. B For the long-term public key (pk) of both parties A ,pk B Temporary public key Received ciphertext and c B The above steps yielded and k B The final session key is obtained by hashing. From this point on, both parties completed two-way authentication and established a session key.

[0047] In steps 1) and 2) of the above scheme 1, Alice, the initiator of the communication, holds the long-term public and private keys generated by the key encapsulation mechanism, and Bob, the responder of the communication, holds the long-term public and private keys generated by the digital signature scheme. The long-term public and private keys held by the two parties are generated by different cryptographic primitives.

[0048] In Scheme 1 above, the two communicating parties use a temporary key encapsulation mechanism to exchange keys to achieve forward security.

[0049] In the first scheme described above, Alice, the initiator of the communication, uses a key encapsulation mechanism for identity authentication.

[0050] In the above scheme one, Bob, the respondent, uses a digital signature scheme for identity authentication.

[0051] In steps 4) and 5) of the above scheme, when Bob and Alice derive the final session key, they not only use the temporary shared key generated by the temporary key encapsulation mechanism, but also... It also used Alice's long-term key encapsulation mechanism to generate a shared key k. B k B The benefits of participating in the derivation process include not only completing the authentication of Alice's identity (preventing the impersonator Alice from establishing the same session key with the real Bob), but also preventing related attacks caused by the leakage of Alice's state information.

[0052] like Figure 2 As shown, the technical method of Scheme 2 is as follows:

[0053] A heterogeneous authentication key exchange method is based on the underlying cryptographic primitive KEM, an IND-CPA secure key encapsulation scheme. CPA = (KGen, Encap, Decap), an IND-CCA secure key encapsulation scheme KEM CCA = (KGen, Encap, Decap) and an EUF-CMA secure digital signature scheme Sig = (KGen, Sign, Verify), and two different hash functions H: in It is the session key space. It is KEM CPA The random number seed space used by KGen to generate the private key is known in advance to both communicating parties to the three schemes and H used by the other party. This method is applicable to Alice and Bob, who are legitimate communicating parties. The method includes the following steps:

[0054] 1) Alice uses Sig.KGen to generate a long-term public-private key pair (pk). A ,sk A And had shared the public key pk with Bob before the authentication key exchange began. A ;

[0055] 2) Bob uses KEM CCA .KGen generates a long-term public-private key pair (pk B ,sk B And shared the public key pk with Alice before the authentication key exchange began. B ;

[0056] 3) Alice generates random numbers r through uniform random sampling, and for (r, sk) A Hash the result to get r′=G(r,sk) A ), r′ as KEM CPA .KGen uses a random number seed to generate temporary public and private keys. Use Bob's long-term public key to pk B Perform KEM CCA .Encap(pk B Obtain the shared key k A and ciphertext c A Use your own long-term private key sk A For temporary public keys Both parties' long-term public key (pk) A ,pk B ), the ciphertext obtained by encapsulation A Sign

[0057] Alice will Send to Bob, with (r,k) A ,c A It is stored as status information.

[0058] 4) Bob received the message sent by Alice. Then, use the temporary public key. Concatenate known long-term public key for PK A PK with your own long-term public key B , and the received cA Thus, the signed message is obtained. Bob uses Alice's long-term public key to PK. A For signature σ and signature message Verification If verification fails, the session will terminate. If verification succeeds, Bob will use the received temporary public key. conduct Obtain the ciphertext and the corresponding shared key Use your own long-term private key sk B For the received ciphertext c A Perform KEM CCA .Decap(sk B ,c A Decapsulation yields the shared key k. A For the long-term public key (pk) of both parties A ,pk B ), received temporary public key Cipher and c A The above steps yielded and k A The final session key is obtained by hashing. Bob will Send to Alice.

[0059] 5) Alice received from Bob Then, using the random number r stored in the state, perform operations on (r, sk) A Hash the result to get r′=G(r,sk) A ), r′ as KEM CPA The .KGen random number seed is used to recover the temporary public and private keys.

[0060] Then use the temporary private key. right conduct Decapsulate to obtain the shared key. For both parties' long-term public keys (pk) A ,pk B Temporary public key Received ciphertext c stored in the state A and k A The above steps yielded The final session key is obtained by hashing. From this point on, both parties completed two-way authentication and established a session key.

[0061] In steps 1) and 2) of the above scheme 2, Alice, the initiator of the communication, holds the long-term public and private keys generated by the digital signature scheme, and Bob, the responder of the communication, holds the long-term public and private keys generated by the key encapsulation mechanism. The long-term public and private keys held by the two parties are generated by different cryptographic primitives.

[0062] In Scheme 2 above, the two communicating parties use a temporary key encapsulation mechanism to exchange keys to achieve forward security.

[0063] In Scheme 2 above, Alice, the initiator of the communication, uses a digital signature scheme combined with a temporary key encapsulation mechanism for identity authentication; specifically, in step 3), Alice uses the signing private key sk A For containing temporary public keys Sign the messages, including those in step 5), only if you have the correct temporary private key. Only then can it be properly decapsulated. Obtain temporary shared key EUF-CMA secure digital signature guarantees no SK (security clearance). A An imposter cannot forge a legitimate signature; however, an imposter who replays a legitimate signature that has been eavesdropped on can pass signature verification, but because there is no correct signature... The correct session key still could not be negotiated.

[0064] In Scheme 2 above, Bob, the responder, uses a key encapsulation mechanism for authentication.

[0065] In steps 4) and 5) of Scheme 2 above, when Bob and Alice derive the final session key, they not only use the temporary shared key generated by the temporary key encapsulation mechanism, but also... It also used Bob's long-term key encapsulation mechanism to generate a shared key k. A k A The benefit of also participating in the derivation is to complete Bob's identity authentication, preventing the impersonator Bob from establishing the same session key with the real Alice.

[0066] Step 3) of Scheme 2 above, Alice's long-term private key sk A The temporary public and private keys are generated together with the state information (random number r). The temporary private key is not stored in the state information. In step 4), Alice uses the long-term private key and the state information to recover the temporary private key. The protocol remains secure even if Alice's state information and Bob's long-term private key are leaked at the same time.

[0067] Analysis and Evaluation:

[0068] Correctness analysis:

[0069] Based on the correctness of the key encapsulation and signature scheme used, honest communicating parties can negotiate a consistent session key by following the steps of Scheme 1 and Scheme 2.

[0070] Security Analysis:

[0071] Based on the IND-CPA secure key encapsulation scheme, the IND-CCA secure key encapsulation scheme, and the EUF-CMA secure digital signature scheme, the method of this invention satisfies... The IND-AA security model proposed by AKE et al. K, Kiltz E, Schge S, et al. Generic Authenticated Key Exchange in the Quantum Random Oracle Model [J]. Springer, Cham, 2020). This security model covers the requirements of classical security models (such as the BR model) and has weak forward security (wFS), which is resistant to common AKE attack types such as reflection attacks and key compromise impersonation (KCI). This method still has IND-AA security under the quantum oracle model.

[0072] Regarding existing theoretical research on heterogeneous scenario authentication key exchange, our second scheme surpasses that of Jager et al. (Tibor Jager, Eike Kiltz, Doreen Riepel, Sven). The scheme proposed by Tightly-Secure Authenticated Key Exchange (Revisited.EUROCRYPT(1)2021:117-146) is a practical scheme for achieving post-quantum security, and the initiator has one less long-term private key. In contrast, the work of Boyd et al. (Colin Boyd, Bor de Kock, Lise Millerjord: Modular Design of KEM-Based Authenticated Key Exchange.ACISP 2023:553-579) requires 1.5 rounds to achieve perfect forward security, but cannot simply reduce it by half a round to weak forward security. Our scheme can achieve weak forward security in one round, and enhance it to perfect forward security by adding half a round of key confirmation without changing the existing protocol process. Our scheme is more flexible in terms of the number of rounds and forward security requirements. In addition, our scheme can guarantee that it is still secure when the temporary state is leaked, while the work of Boyd et al. cannot. Compared to Caribé's work (Mark Diamantino Caribé: A Novel Post-quantum Authenticated KeyEstablishment Protocol. Master's Thesis. 2023), our work has rigorous security proofs, exhibits higher security, and guarantees security even when temporary states are leaked. Furthermore, our scheme proves security under the quantum random oracle machine model.

[0073] Efficiency Analysis:

[0074] Compared to other authentication key exchange schemes, our heterogeneous authentication key exchange scheme uses different long-term key primitives between the communicating parties. Depending on the selected key encapsulation and digital signature schemes, the computational and communication loads are unbalanced, which is advantageous in scenarios where one party has strong computational capabilities while the other party has limited capabilities. We selected the standardized algorithm key encapsulation scheme ML-KEM and the digital signature schemes ML-DSA, Falcon, and SPHINCS+ selected from the NIST post-quantum algorithm solicitation. We then used the liboqs codebase to test the communication load and local computational efficiency of both parties under NIST security level 1. The data are shown in Tables 1 and 2, respectively.

[0075] The local computation efficiency in the table consists of the CPU cycles consumed in generating the long-term key, the computation before Alice sends a message to Bob, and the computation of the session key after Alice receives a message from Bob. The local computation efficiency in the table consists of the CPU cycles consumed in generating the long-term key and the computation before Bob receives Alice's message and sends a message back to Alice. Alice's message length represents the number of bytes Alice sends to Bob, and Bob's message length represents the number of bytes Bob responds to Alice's message.

[0076] Table 1. Bilateral communication volume and local computing efficiency of Scheme 1 under NIST security level 1.

[0077]

[0078] Table 2 shows the bidirectional communication volume and local computing efficiency of Scheme 2 under NIST security level 1.

[0079]

[0080]

[0081] The bar charts of communication volume between the two parties under NIST security level 1 for Scheme 1 and Scheme 2 are as follows: Figure 3 and Figure 4 As shown in the diagram. The Alice message length represents the number of bytes Alice sends to Bob, and the Bob message length represents the number of bytes Bob sends to Alice.

[0082] Comparative analysis revealed that, under NIST security level 1, when the key encapsulation scheme is ML-KEM and the signature schemes are ML-DSA, Falcon, and SPHINCS+, the communication volume is unbalanced between the two parties. The communication party holding the signature key pair generates a larger data size, meaning that the responder in scheme one has a larger communication volume, while the opposite is true for scheme two. Specifically, when the signature scheme is Falcon, the communication data of the signature key pair holder is relatively smaller.

[0083] The bar chart showing the local computational efficiency (logarithm of CPU cycles) of Scheme 1 and Scheme 2 under NIST security level 1 is as follows: Figure 5 and Figure 6As shown in the diagram. In the diagram, Init_A represents Alice's computational efficiency in generating the long-term key, Init_B represents Bob's computational efficiency in generating the long-term key, Send_A represents Alice's local computational efficiency before sending the message to Bob, Receive_A represents Alice's efficiency in calculating the session key after receiving Bob's message, and Send_B represents Bob's local computational efficiency before sending the message to Alice. Because the data differences between different scheme combinations are too large, using logarithms better reflects the data comparison.

[0084] Through comparative analysis, under NIST security level 1, when the key encapsulation scheme is ML-KEM and the signature schemes are ML-DSA, Falcon, and SPHINCS+ respectively, the local computational cost of the initiator in Scheme 1 is less than that of the responder, while the opposite is true for Scheme 2.

[0085] In summary, this invention constructs an authentication key exchange protocol using a heterogeneous approach, possessing post-quantum oracle model security. It is more flexible than existing solutions, adapting to the agility requirements of post-quantum cryptography migration. It demonstrates significant advantages in application scenarios where the computing power of the communicating parties is unequal. For different actual application scenarios, the appropriate protocol scheme can be flexibly selected according to the requirements, providing reliable security for communicating parties with different computing power, and has strong practical application value.

[0086] Although specific embodiments of the invention have been disclosed for illustrative purposes to aid in understanding and implementing the invention, those skilled in the art will understand that various substitutions, variations, and modifications are possible without departing from the spirit and scope of the invention and the appended claims. Therefore, the invention should not be limited to the content disclosed in the preferred embodiments, and the scope of protection claimed by the invention is defined by the claims.

Claims

1. A heterogeneous authentication key exchange method based on key encapsulation and digital signature, the underlying cryptographic primitive being an IND-CPA secure key encapsulation scheme, KEM. CPA = (KGen, Encap, Decap), an IND-CCA secure key encapsulation scheme KEM CCA = (KGen, Encap, Decap) and an EUF-CMA secure digital signature scheme Sig = (KGen, Sign, Verify), and a hash function. in This is the session key space, where Alice and Bob, the two legitimate communicating parties, are aware in advance of each other's key encapsulation scheme, KEM. CPA KEM CCA The digital signature scheme Sig and the hash function H, the steps of which include: 1) Alice uses KEM CCA .KGen generates a long-term public-private key pair (pk). A ,sk A And had shared the public key pk with Bob before the authentication key exchange began. A Bob used Sig.KGen to generate a long-term public-private key pair (pk). B ,sk B And shared the public key pk with Alice before the authentication key exchange began. B ; 2) Alice uses KEM CPA .KGen generates a temporary public-private key pair. Stored as state information, and a temporary public key is sent to Bob. 3) After receiving the message, Bob uses the received temporary public key. conduct Obtain the ciphertext and the corresponding shared key And using Alice's long-term public key PK A Perform KEM CCA .Encap(pk A ) Obtain the ciphertext c B and shared key k B Then use your own long-term private key sk B For temporary public keys Both parties' long-term public key (pk) A ,pk B The two ciphertexts obtained through encapsulation and c B Sign For both parties' long-term public keys (pk) A ,pk B ), received temporary public key Cipher Cipher c B Shared key and shared key k B The final session key is obtained by hashing. Bob will Send to Alice; 4) Alice received from Bob Then, retrieve the temporary public key from the state information. Concatenate known long-term public key for PK A Long-term public key PK with the other party B and received and c B Thus, the signed message is obtained. Alice uses Bob's long-term public key to PK. B Verify the signature σ If verification fails, the session is terminated; if verification succeeds, Alice uses the temporary private key stored in the state. For the received ciphertext conduct Decapsulate to obtain the shared key. Use your own long-term private key sk A For the received ciphertext c B Perform KEM CCA .Decap(sk A ,c B Decapsulation yields the shared key k. B ; for both parties' long-term public keys (pk A ,pk B Temporary public key Received ciphertext and ciphertext c B Shared key and shared key k B The final session key is obtained by hashing.

2. A heterogeneous authentication key exchange method based on key encapsulation and digital signature, the underlying cryptographic primitive being an IND-CPA secure key encapsulation scheme, KEM. CPA = (KGen, Encap, Decap), an IND-CCA secure key encapsulation scheme KEM CCA = (KGen, Encap, Decap) and an EUF-CMA secure digital signature scheme Sig = (KGen, Sign, Verify), and two different hash functions. in It is the session key space. It is KEM CPA The random number seed space used by KGen to generate the private key is known in advance by Alice and Bob, the two parties in legitimate communication, to the key encapsulation scheme KEM used by the other. CPA KEM CCA The digital signature scheme Sig and the hash function H, the steps of which include: 1) Alice uses Sig.KGen to generate a long-term public-private key pair (pk). A ,sk A And had shared the public key pk with Bob before the authentication key exchange began. A Bob uses KEM CCA .KGen generates a long-term public-private key pair (pk). B ,sk B And shared the public key pk with Alice before the authentication key exchange began. B ; 2) Alice generates random numbers r through uniform random sampling, and for (r, sk) A Hash the data to obtain r′=G(r,sk) A ), r′ as KEM CPA .KGen uses a random number seed to generate temporary public and private keys. And using Bob's long-term public key PK B Perform KEM CCA .Encap(pk B Obtain the shared key k A and ciphertext c A Then use your own long-term private key sk A For temporary public keys Both parties' long-term public key (pk) A ,pk B ), the ciphertext obtained by encapsulation A Sign Alice will Send to Bob, with (r,k) A ,c A ) is stored as status information; 3) Bob received the message sent by Alice. Then, use the temporary public key. Concatenate known long-term public key for PK A PK of one's own long-term public key B And the received ciphertext c A Thus, the signed message is obtained. Bob uses Alice's long-term public key to PK. A For signature σ and signature message Verification If verification fails, the session will terminate; if verification succeeds, Bob will use the received temporary public key. conduct Obtain the ciphertext and the corresponding shared key Use your own long-term private key sk B For the received ciphertext c A Perform KEM CCA .Decap(sk B ,c A Decapsulation yields the shared key k. A Then, the long-term public key (pk) of both parties is... A ,pk B ), received temporary public key Cipher Cipher c A Shared key and shared key k A The final session key is obtained by hashing. Bob will cipher Send to Alice; 4) Alice receives the cipher from Bob. Then, using the random number r stored in the state, perform operations on (r, sk) A Hash the data to obtain r′=G(r,sk) A Using r′ as KEM CPA The .KGen random number seed is used to recover the temporary public and private keys. Then use the temporary private key. For ciphertext conduct Decapsulate to obtain the shared key. For both parties' long-term public keys (pk) A ,pk B Temporary public key Received ciphertext The ciphertext c stored in the state A Shared key k A Shared key The final session key is obtained by hashing.

Images