Certificateless post-quantum tls handshake method based on kem and ibe

Abstract

The application discloses a certificateless post-quantum TLS handshake method based on KEM and IBE. The application integrates the functions of key agreement and identity authentication in a single computing operation by adopting the mode of encrypting a temporary KEM public key by an IBE public key, simplifies the protocol interaction structure, and realizes the certificateless bidirectional implicit authentication and the forward secure key agreement. In the bidirectional identity authentication scene, the client can send application data only by one round trip delay, and the connection establishment efficiency is effectively improved. The method can resist the attack of a quantum computer, and solves the technical defects of the traditional and existing post-quantum TLS protocols in the aspects of quantum security resistance, communication overhead and handshake delay.

Description

A Certificateless Post-Quantum TLS Handshake Method Based on KEM and IBE Technical Field

[0001] This invention belongs to the field of encrypted communication technology, specifically relating to a certificateless post-quantum TLS handshake method based on KEM and IBE. Background Technology

[0002] Transport Layer Security (TLS) is an encrypted communication protocol used to establish encrypted communication tunnels over digital networks. It consists of two layers: a handshake protocol and a record protocol. The handshake protocol is the core component, providing confidentiality, authentication, and data integrity protection for network data. TLS is the most widely deployed and applied cryptographic protocol on the internet, with over 60% of internet data transmitted via the secure HTTPS protocol based on TLS. TLS provides security for digital communication on open networks. Its basic structure involves using public-key cryptography to authenticate entities and establish a shared key, which is then used as a private key for symmetric encryption to encrypt application data.

[0003] The latest protocol version is TLS 1.3, released by the Internet Engineering Task Force (IETF) in 2018. It employs asymmetric cryptographic algorithms based on RSA or ECC for key exchange and server certificate authentication. However, these asymmetric cryptographic algorithms rely on the difficulty of discrete logarithm and large integer factorization, which can theoretically be efficiently broken by quantum algorithms proposed by Shor. Once large-scale quantum computers are built, existing systems will be unable to withstand quantum computing attacks, posing a risk of data leakage and serious threats to network security.

[0004] The existing TLS protocol has the following technical shortcomings:

[0005] 1. Asymmetric cryptographic algorithms have weak resistance to quantum mechanics.

[0006] The current TLS 1.3 protocol uses the Diffie-Hellman key exchange protocol and elliptic curve digital signature algorithm for key negotiation and authentication. The security of these algorithms relies on the difficulty of factoring discrete logarithms and large integers, problems that are vulnerable to Shor's quantum algorithm. With the development of quantum computers, TLS protocols based on traditional cryptographic algorithms will struggle to guarantee the long-term security of network communications. Therefore, it is urgent to implement quantum-resistant modifications to the TLS protocol to ensure reliable security in future quantum computing environments.

[0007] 2. The post-quantum signature algorithm has a significant overhead.

[0008] Post-quantum signature algorithms typically involve large public keys and signature lengths. Using authentication mechanisms based on digital signatures and certificates would incur significant storage and communication overhead. As the scale of cryptographic components increases, the amount of data transmitted during the handshake process rises accordingly, directly impacting network communication efficiency and deployment costs. Therefore, this invention replaces the post-quantum signature algorithm with a lattice-based IBE scheme. Both parties can directly derive the public key based on their identity information, eliminating the traditional certificate transmission and verification steps, and significantly reducing computational, storage, and communication overhead as well as overall latency.

[0009] 3. Latency bottleneck exists in two-way authentication scenarios.

[0010] In two-way authentication scenarios, the current TLS protocol requires the client to complete two full round trips (2-RTT) before transmitting application data, thus introducing significant communication latency. This limitation is particularly prominent in applications with high real-time requirements, becoming a key bottleneck affecting user experience and system response speed. Therefore, this invention combines the advantages of KEM and IBE, completing key negotiation and authentication simultaneously in a single interaction, greatly simplifying the protocol structure and communication process.

[0011] Existing solutions include:

[0012] Peter Schwabe et al. proposed the post-quantum KEMTLS protocol in their paper "Post-Quantum TLS Without Handshake Signatures". This protocol uses the long-term KEM algorithm, which is secure against indistinguishability under chosen-ciphertext attacks (IND-CCA), to replace signatures for server authentication, effectively reducing storage and communication overhead compared to TLS 1.3. However, the server still needs to send a certificate containing the long-term KEM public key in the KEMTLS protocol, which still introduces some communication overhead. Furthermore, in two-way authentication scenarios, the client must also provide its own certificate, causing the client to complete two round trips (2-RTT) before sending application data, thus introducing additional latency.

[0013] Douglas Stebila et al. proposed a post-quantum KEMTLS protocol, KEMTLS-PDK, in their paper "More efficient post-quantum KEMTLS with pre-distributed public keys." This protocol allows clients to obtain the server's long-term KEM public key in advance, thus eliminating the need for the server to send a certificate during the handshake process and improving efficiency. However, the pre-distributed key mechanism severely limits the practical deployment scope of this protocol. Furthermore, in two-way authentication, this protocol presents a trade-off between security and efficiency. If the client sends application data after 1-RTT, it loses forward security; to ensure forward security, a temporary secret needs to be introduced into the encryption key of the client certificate, meaning the client can only send application data after 2-RTT, which actually increases communication latency.

[0014] Wang Xiaofeng et al., in their paper "TLS Handshake Protocol Based on Identity Cryptography," proposed a TLS handshake protocol and deployment method based on elliptic curve bilinear mapping. This method utilizes identity-based cryptography, employing the IBAKA (Identity-Based Authenticated Key Agreement) protocol to complete key negotiation and authentication, thus eliminating the need to send and verify certificates during the handshake process, saving network traffic and memory. However, the security of IBAKA in this protocol is based on the discrete logarithm problem and is not resistant to quantum attacks. Furthermore, the client can only begin sending application data after 2-RTT, resulting in high handshake latency.

[0015] Therefore, this invention proposes a certificateless post-quantum TLS handshake method based on Key Encapsulation Mechanism (KEM) and Identity-Based Encryption (IBE). This method combines the advantages of KEM and IBE, simultaneously completing key negotiation and authentication in a single interaction, significantly simplifying the protocol structure and communication process. In a two-way authentication scenario, the client only needs one round-trip time (1-RTT) to transmit application data, effectively reducing connection establishment latency and eliminating the communication overhead associated with traditional certificate transmission. Furthermore, by designing the cryptographic components to be quantum-resistant, this method can resist the security threats posed by quantum computing. Summary of the Invention

[0016] The purpose of this invention is to propose a certificateless post-quantum TLS handshake method based on KEM and IBE. By combining the efficient key negotiation capability of KEM with the certificateless authentication advantage of IBE, and by replacing the basic cryptographic components with quantum-resistant alternatives, this method achieves simultaneous bidirectional authentication and key negotiation with forward security within a round-trip time, while also resisting attacks from quantum computers. This addresses the technical shortcomings of traditional and existing post-quantum TLS protocols in terms of quantum security, communication overhead, and handshake latency.

[0017] The present invention specifically includes the following steps:

[0018] Step 1: The Private Key Generator (PKG) selects and initializes the quantum-resistant identity base encryption scheme IBE, generating the system's master public key and master private key. The master public key is made public, while the master private key is kept strictly confidential by the PKG.

[0019] The communication participants register their unique identity with the key generation server. After verifying the identity of the communication participants, the key generation server uses the system master private key and the user identity to run the IBE private key extraction algorithm to generate a personal private key bound to the identity, and distributes the generated private key to the corresponding communication participants through a secure channel.

[0020] Step 2, the communication process is as follows:

[0021] Step 1: Client initiates connection: The client encrypts the temporary public key generated using the quantum-resistant key encapsulation mechanism (KEM) with the server's identity identifier and master public key, generating the client challenge ciphertext. The client then sends its identity identifier, the generated client random number, and the client challenge ciphertext to the server.

[0022] Step 2: The server processes the request and responds: It decrypts the client's challenge ciphertext using its private key, calls the KEM encapsulation algorithm to generate the server-encapsulated ciphertext and shared secret; it encrypts the encapsulated ciphertext using the client's identity and master public key to obtain the server's challenge ciphertext; and it derives the client's temporary key and the server's temporary key based on the server's shared secret, the client's random number, and the server's random number. The server's temporary key is used to encrypt the KEM-generated server temporary public key to obtain the protected server temporary public key. The server then sends its own identity, the generated server random number, the server challenge ciphertext, and the protected server temporary public key to the client.

[0023] Step 3: The client completes authentication and sends the final message: After receiving the response, the client uses its private key to decrypt the server's challenge ciphertext, and uses the client's temporary private key generated by KEM to decapsulate the server's encapsulated ciphertext, restoring the server's shared secret. It then derives the client's temporary key and the server's temporary key in the same way as in Step 2, and uses the server's temporary key to decrypt the protected server's temporary public key, obtaining the server's temporary public key. The client then calls the KEM encapsulation algorithm to generate the client's encapsulated ciphertext and the shared secret using the server's temporary public key. Based on the server's shared secret, the client's shared secret, the client's random number, and the server's random number, the final encryption key and authentication key for both parties are derived. Finally, a symmetric encryption algorithm is called to encrypt the client's encapsulated ciphertext using the client's temporary key, obtaining the protected client-encapsulated ciphertext. The client's authentication key is used to calculate the message authentication code, overwriting all previous handshake messages.

[0024] The client sends the protected client-encapsulated ciphertext and message authentication code to the server. Simultaneously, the client immediately begins encrypting and sending encrypted application data to the server using its client encryption key.

[0025] Step 4: Server completes handshake: After receiving the message from the client, the server uses the client's temporary key to decrypt the protected client-encapsulated ciphertext and restores the client's shared secret; it derives the same encryption key and authentication key as the client, uses the client's authentication key to verify the message authentication code, and uses the server's authentication key to calculate an equivalent message authentication code and send it to the client; at the same time, the server begins to use the server's encryption key to send encrypted application data to the client.

[0026] Finally, after the client verifies the message authentication code calculated from the client's authentication key, the two-way explicit authentication is completed.

[0027] Using the above method, when a client needs to send an encrypted message to the server, it directly uses the server's identity identifier as the public key for encryption, and the server uses its corresponding private key for decryption, and vice versa.

[0028] Furthermore, both the KEM algorithm and the IBE algorithm employ post-quantum cryptography algorithms that are resistant to quantum computing attacks.

[0029] Furthermore, the key generation server (PKG) broadcasts or publishes the system's master public key through public channels. This process does not require a secure channel, and any potential communication party can freely obtain it.

[0030] Furthermore, the client-side challenge ciphertext generation process in step 1 is as follows:

[0031] The client calls the key generation algorithm of the quantum-resistant key encapsulation mechanism KEM to generate a temporary public / private key pair; then, it calls the encryption algorithm of the quantum-resistant identity basis encryption scheme IBE to encrypt the client's temporary public key using the server's identity identifier and master public key, generating the client's challenge ciphertext.

[0032] Furthermore, the server challenge ciphertext generation process in step 2 is as follows:

[0033] The server invokes the decryption algorithm of the quantum-resistant identity basis encryption scheme IBE, using its private key to decrypt the client's challenge ciphertext sent by the client, and obtains the client's temporary public key. After successful decryption, the server invokes the key generation algorithm of the quantum-resistant key encapsulation mechanism KEM, using the decrypted client's temporary public key to generate the server's shared secret and encapsulated ciphertext. Then, the server invokes the encryption algorithm of IBE, using the client's identity identifier and master public key to encrypt the server's encapsulated ciphertext, generating the server's challenge ciphertext.

[0034] Furthermore, the process for generating the protected temporary public key for the server in step 2 is as follows:

[0035] The server calls the decryption algorithm of the quantum-resistant identity basis encryption scheme IBE, uses the server's private key to decrypt the client challenge ciphertext sent by the client, and obtains the client's temporary public key; after successful decryption, the server calls the key generation algorithm of the quantum-resistant key encapsulation mechanism KEM, and uses the decrypted client's temporary public key to generate the server's shared secret and encapsulated ciphertext.

[0036] Then, the server calls IBE's encryption algorithm, uses the client's identity and master public key to encapsulate the ciphertext and generate the server challenge ciphertext;

[0037] Then, the server calls the key generation algorithm of the quantum-resistant key encapsulation mechanism KEM to generate a temporary public / private key pair for the server; at the same time, it calls the key derivation function, inputting the server's shared secret, the client's random number, and the server's random number, to derive the client's temporary key and the server's temporary key;

[0038] Finally, the server invokes a symmetric encryption algorithm, using its temporary key to encrypt the temporary public key, thus obtaining the protected temporary public key.

[0039] Furthermore, the protected client-side ciphertext generation process in step 3 is as follows:

[0040] Use the client's private key to decrypt the server's challenge ciphertext and obtain the server's encapsulated ciphertext;

[0041] Then, the client calls the decapsulation algorithm of the quantum-resistant key encapsulation mechanism KEM, uses the client's temporary private key to decapsulate the server's encapsulated ciphertext, and restores the server's shared secret;

[0042] Then, the client calls the key derivation function, inputting the server's shared secret, the client's random number, and the server's random number, to derive the client's temporary key and the server's temporary key;

[0043] Then, the client calls the symmetric encryption algorithm, uses the server's temporary key to decrypt the protected server temporary public key, and obtains the server's temporary public key;

[0044] Then, the client calls the key generation algorithm of the quantum-resistant key encapsulation mechanism KEM, and uses the decrypted temporary public key of the server to generate the client-encapsulated ciphertext and shared secret;

[0045] Then, the client calls the key derivation function again, inputting the server's shared secret, the client's shared secret, the client's random number, and the server's random number, to derive the encryption key used for encrypting data between the two parties, as well as the authentication key used for explicit authentication between the two parties;

[0046] Finally, the client invokes a symmetric encryption algorithm, using its temporary key to encrypt the client-encapsulated ciphertext, thus obtaining the protected client-encapsulated ciphertext.

[0047] Furthermore, step 4 specifically involves:

[0048] The symmetric encryption algorithm is invoked, and the protected client-encapsulated ciphertext is decrypted using the client's temporary key to obtain the client-encapsulated ciphertext.

[0049] Then, the server calls the decapsulation algorithm of the quantum-resistant key encapsulation mechanism KEM to restore the shared secret of the client;

[0050] Then, the server calls the key derivation function, taking the server's shared secret, the client's shared secret, the client's random number, and the server's random number as input, to derive the encryption key used for encrypting data between the two parties, and the authentication key used for explicit authentication between the two parties;

[0051] Then, the server uses the client authentication key to verify the message authentication code; if the verification is successful, it confirms that the client's identity is genuine and the handshake message has not been tampered with; at the same time, it uses the server authentication key to calculate a peer message authentication code and sends it to the client; simultaneously, the server begins to use the server encryption key to send encrypted application data to the client.

[0052] Finally, after the client verifies the message authentication code calculated from the client's authentication key, the two-way explicit authentication is completed.

[0053] In the above method, the client combines two shared secrets—one from the server and one from the client—and introduces random numbers from both sides to jointly derive the final session key through a key derivation function. This design ensures forward security of the protocol; even if an attacker successfully cracks the long-term key or temporary private key used in a future exchange, they cannot recover the complete session key. After deriving the final session key, the client can begin sending encrypted application data, enabling secure communication within 1-RTT in a two-way authentication scenario. Simultaneously, the client sends its processed client-encapsulated ciphertext and a verification code to the server. The server recovers the client-encapsulated ciphertext from the client's final message and derives a session key identical to the client's. The server verifies the verification code sent by the client, confirming the integrity of the handshake process and the client's authenticity, completing explicit authentication. Subsequently, the server sends its own verification code to the client, achieving final two-way confirmation, and the secure channel is fully established.

[0054] Preferably, the symmetric encryption algorithm used is the same AES-256-GCM algorithm as the TLS protocol.

[0055] This invention provides a highly efficient, secure, and quantum-resistant network communication solution by combining KEM with IBE and introducing quantum-resistant cryptography. During each handshake, by encrypting a temporary KEM public key with an IBE public key, both communicating parties (client and server) can directly derive each other's public key from the other's identity identifier, eliminating the need for certificate lookup, sending, and verification. This significantly reduces the computational, storage, and communication overhead and overall latency of the TLS protocol. Simultaneously, integrating key negotiation and authentication into each computational operation simplifies the protocol interaction structure, achieving certificate-free, two-way implicit authentication and forward-secure key negotiation. In the two-way authentication scenario, the client only needs one round-trip time to send application data, effectively improving connection establishment efficiency.

[0056] Compared to existing technologies, this invention has the following significant advantages: 1. Quantum-resistant security: It fundamentally solves the quantum computing threat faced by traditional cryptographic algorithms. 2. Extremely high communication efficiency: The client can transmit application data after the first round trip, greatly reducing connection establishment latency and making it suitable for applications with high real-time requirements. 3. Significantly reduced overhead: It completely eliminates the overhead of transmitting, verifying, and storing digital certificates, simplifying the public key management infrastructure. 4. Complete security attributes: Two-way implicit authentication is completed synchronously in one interaction, and forward security is achieved through two temporary key exchanges. Attached Figure Description

[0057] Figure 1 is a flowchart of the certificateless construction process of the identity-based key infrastructure in the embodiment;

[0058] Figure 2 is a flowchart of the authentication key exchange process for a single round trip in the embodiment. Detailed Implementation

[0059] The specific embodiments of the present invention will be further described below with reference to the accompanying drawings.

[0060] A certificateless post-quantum TLS handshake method based on KEM and IBE includes the following steps:

[0061] Step 1: As shown in Figure 1, the certificateless construction of the identity-based key infrastructure:

[0062] Before the protocol is deployed, the management authority of the protocol domain selects a quantum-resistant identity-based encryption scheme (such as a lattice-based IBE scheme), and then deploys a trusted key generation server (Private Key Generator, PKG).

[0063] The Private Key Generator (PKG) selects and initializes the quantum-resistant identity base encryption scheme IBE, generating the system's master public key mpk and master private key msk. The master public key is made public, while the master private key is kept strictly confidential by the PKG. The PKG broadcasts or publishes the system's master public key mpk through public channels (such as official websites or directory services). This process does not require a secure channel, and any potential communication party (such as clients and servers) can freely obtain it.

[0064] Subsequently, the communication participants (client and server) register their unique identity with the PKG. After verifying the identities of the client and server, the PKG uses the system master private key and user identity held by the client to run the IBE private key extraction algorithm to generate a personal decryption key (private key) bound to the identity. The generated private key is then distributed to the corresponding client and server through a secure channel.

[0065] The process of generating a client private key (client registration) is as follows:

[0066] The client submits its unique identifier ID_Client to PKG.

[0067] After PKG verifies the client's identity, it uses the system master private key msk and the identity identifier ID_Client to run the IBE private key extraction algorithm to generate the client private key SK_Client, and then distributes the generated private key SK_Client to the corresponding client through a secure channel.

[0068] Similarly, the server private key generation (server registration) process is as follows:

[0069] The server submits its unique identifier ID_Server to PKG.

[0070] After PKG verifies the server's identity, it uses the system master private key msk and the identity identifier ID_Server to run the IBE private key extraction algorithm, generate a server-specific private key SK_Server, and distribute the generated private key SK_Server to the corresponding server through a secure channel.

[0071] After completing the above operations, the system enters the ready state. At this time, the client holds the master public key mpk, its own identity ID_Client, and its own private key SK_Client, while the server holds the master public key mpk, its own identity ID_Server, and its own private key SK_Server.

[0072] Step 2, as shown in Figure 2, involves a single round trip authentication key exchange (communication process) as follows:

[0073] Step 1: The client initiates a connection (Client Hello):

[0074] First, the client initiates a connection, generates a client random number N_c, and calls the key generation algorithm of the quantum-resistant key encapsulation mechanism KEM to generate a client temporary public / private key pair (pk_c, sk_c);

[0075] Then, the client calls the encryption algorithm of the quantum-resistant identity basis encryption scheme IBE, and uses the server ID_Server and the master public key mpk to encrypt the client's temporary public key pk_c, generating the client challenge ciphertext C_1;

[0076] Finally, the client sends its client identity ID_Client, client random number N_c, and generated client challenge ciphertext C_1 to the server.

[0077] Step 2: The server processes the request and responds (Server Hello):

[0078] After receiving the request, the server initiates a connection and generates a server-side random number N_s.

[0079] Then, the server invokes the decryption algorithm of the quantum-resistant identity basis encryption scheme IBE, using the server private key SK_Server generated in step one to decrypt the client challenge ciphertext C_1 sent by the client, obtaining the client's temporary public key pk_c (successful decryption means the server has proven its legitimate identity, completing implicit authentication of the server). After successful decryption, the server invokes the key generation algorithm of the quantum-resistant key encapsulation mechanism KEM, using the decrypted client temporary public key pk_c to generate the server's shared secret ss_1 and the encapsulated ciphertext ct_1.

[0080] Then, the server calls the encryption algorithm of the quantum-resistant identity base encryption scheme IBE, uses the client's identity identifier ID_Client and the master public key mpk to encrypt the server's encapsulated ciphertext ct_1, and generates the server challenge ciphertext C_2.

[0081] Then, the server calls the key generation algorithm of the quantum-resistant key encapsulation mechanism KEM to generate a temporary public / private key pair (pk_s, sk_s); at the same time, it calls the key derivation function, inputting the server's shared secret ss_1, the client's random number N_c, and the server's random number N_s, to derive the client's temporary encryption key K_c and the server's temporary encryption key K_s.

[0082] Then, the server calls a symmetric encryption algorithm (such as AES-256-GCM) to encrypt the server's temporary public key pk_s using the server's temporary encryption key K_s, thus obtaining the protected server's temporary public key c_s.

[0083] Finally, the server sends its own identity ID_Server, server random number N_s, server challenge ciphertext C_2, and protected server temporary public key c_s to the client.

[0084] Step 3: The client completes authentication and sends the final message (Client Finished):

[0085] After receiving the response, the client uses the client private key SK_Client generated in step one to decrypt the server challenge ciphertext C_2 to obtain the server encapsulated ciphertext, and successfully decrypts it (that is, the implicit authentication of the client is completed).

[0086] Then, the client calls the decapsulation algorithm of the quantum-resistant key encapsulation mechanism KEM, uses the client's temporary private key sk_c to decapsulate the server's encapsulated ciphertext ct_1, and restores the server's shared secret ss_1;

[0087] Then, the client calls the key derivation function, taking into input the server's shared secret ss_1, the client's random number N_c, and the server's random number N_s, to derive the client's temporary encryption key K_c and the server's temporary encryption key K_s.

[0088] Then, the client calls the symmetric encryption algorithm and uses the server's temporary encryption key K_s to decrypt the protected server temporary public key c_s, obtaining the server's temporary public key pk_s;

[0089] Then, the client calls the key generation algorithm of the quantum-resistant key encapsulation mechanism KEM, and uses the decrypted server temporary public key pk_s to generate the client-encapsulated ciphertext ct_2 and the shared secret ss_2.

[0090] Then, the client calls the key derivation function again, taking into account the server's shared secret ss_1, the client's shared secret ss_2, the client's random number N_c, and the server's random number N_s, to derive the encryption keys AppK_S and AppK_C (S for server use and C for client use) used for encrypting data between the two parties, as well as the authentication keys AuthK_C and AuthK_S (S for server use and C for client use) used for explicit authentication between the two parties.

[0091] Then, the client invokes a symmetric encryption algorithm, using its temporary encryption key K_c to encrypt the client-encapsulated ciphertext ct_2, obtaining the protected client-encapsulated ciphertext c_c. (This operation protects ct_2 from eavesdropping during transmission, preventing man-in-the-middle attacks from obtaining ct_2 and performing offline analysis or replay attacks.)

[0092] Then, using the key AuthK_C used for explicit client authentication, a message authentication code MAC_C is calculated, overriding all previous handshake messages.

[0093] Finally, the client sends the protected client-encapsulated ciphertext c_c and message authentication code MAC_C to the server. Simultaneously, the client immediately begins encrypting and sending encrypted application data to the server using the client encryption key AppK_C.

[0094] Step 4: Server completes handshake (Server Finished):

[0095] After receiving the message sent by the client, the server calls the symmetric encryption algorithm and uses the client's temporary encryption key K_c to decrypt the protected client-encapsulated ciphertext c_c, obtaining the client-encapsulated ciphertext ct_2.

[0096] Then, the server calls the decapsulation algorithm of the quantum-resistant key encapsulation mechanism KEM to restore the client's shared secret ss_2;

[0097] Then, the server calls the key derivation function, taking into input the server's shared secret ss_1, the client's shared secret ss_2, the client's random number N_c, and the server's random number N_s, to derive the encryption keys AppK_S and AppK_C (S for server use and C for client use) used for encrypting data between the two parties, as well as the keys AuthK_C and AuthK_S (S for server use and C for client use) used for explicit authentication between the two parties.

[0098] Then, the server uses the client's authentication key AuthK_C to verify the message authentication code MAC_C. If the verification is successful, the client's identity is confirmed as genuine and the handshake message has not been tampered with. Simultaneously, the server uses its authentication key AuthK_S to calculate a peer-to-peer message authentication code MAC_S and sends it to the client (after the client verifies MAC_S, two-way explicit authentication is complete).

[0099] Finally, the server begins encrypting and sending encrypted application data to the client using the server encryption key AppK_S.

[0100] In the above steps: implicit authentication is performed on the server by decrypting the client's challenge ciphertext C_1, and implicit authentication is performed on the client by decrypting the server's challenge ciphertext C_2, thus achieving two-way implicit authentication; after completing two rounds of key exchange, the final key is derived by combining the server's shared secret ss_1 and the client's shared secret ss_2, achieving forward security and allowing application data to be sent after 1-RTT (one round-trip time); the explicit authentication process begins with MAC_C, and two-way explicit authentication is completed by verifying MAC_S, enhancing non-repudiation.

[0101] The KEM and IBE algorithms used in this embodiment are both implemented using post-quantum cryptographic algorithms resistant to quantum computing attacks, such as lattice-based algorithms. Given that symmetric encryption algorithms have relatively strong security against quantum computing, this embodiment does not require any changes at this stage and directly adopts the same AES-256-GCM algorithm as the existing TLS protocol.

[0102] Using the above method, when a client needs to send an encrypted message to the server, it directly uses the server's identity identifier ID_Server as the public key for encryption, and the server uses its corresponding private key SK_Server for decryption, and vice versa. This process completely eliminates the complex steps of applying for, issuing, transmitting, verifying, and revoking digital certificates in traditional PKI.

Claims

1. A certificateless post-quantum TLS handshake method based on KEM and IBE, characterized in that: Specifically, the steps are as follows: Step 1: The key generation server PKG selects and initializes the quantum-resistant identity base encryption scheme IBE, and generates a master public key and a master private key. The master public key is made public, while the master private key is kept strictly confidential by the PKG. The communication participants register their unique identity with the key generation server. After verifying the identity of the communication participants, the key generation server uses the master private key and the user identity to run the IBE private key extraction algorithm to generate a personal private key bound to the identity, and distributes the generated private key to the corresponding communication participants through a secure channel. Step 2, the communication process is as follows: Step 1, the client initiates a connection: it calls the IBE encryption algorithm, uses the server identity and master public key to encrypt the client's temporary public key generated using the quantum-resistant key encapsulation mechanism KEM, and generates the client challenge ciphertext. The client sends its client identity, generated client random number, and client challenge ciphertext to the server. Step 2: The server processes the request and responds: it decrypts the client challenge ciphertext using its private key, calls the KEM encapsulation algorithm to generate server encapsulation ciphertext and a shared secret, calls the IBE encryption algorithm, and encrypts the encapsulation ciphertext using the client identity and master public key to obtain the server challenge ciphertext. Based on the server shared secret, the client random number, and the server random number, it derives the client temporary key and the server temporary key, and uses the server temporary key to encrypt the KEM-generated server temporary public key to obtain the protected server temporary public key. The server sends its own identity identifier, a generated server random number, a server challenge ciphertext, and a protected server temporary public key to the client; Step 3: The client completes authentication and sends the final message: After receiving the response, the client uses its private key to decrypt the server challenge ciphertext, uses the client temporary private key generated by KEM to decapsulate the server encapsulation ciphertext, and restores the server shared secret; it derives the client temporary key and server temporary key in the same way as in Step 2, and uses the server temporary key to decrypt the protected server temporary public key; The KEM encapsulation algorithm is invoked to generate the client-encapsulated ciphertext and shared secret using the server's temporary public key. Based on the server's shared secret, the client's shared secret, the client's random number, and the server's random number, the final encryption key and authentication key for both parties are derived. The client-encapsulated ciphertext is encrypted using the client's temporary key to obtain the protected client-encapsulated ciphertext. The client uses its authentication key to calculate the message authentication code, overwriting all previous handshake messages. The client sends the protected client-encapsulated ciphertext and the message authentication code to the server. Simultaneously, the client immediately begins encrypting and sending encrypted application data to the server using its client encryption key. Step 4: The server completes the handshake. After receiving the message from the client, the server uses the client's temporary key to decrypt the protected client-encapsulated ciphertext and restores the client's shared secret. It derives the same encryption key and authentication key as the client. The server uses the client authentication key to verify the message authentication code and simultaneously uses its server authentication key to calculate an equivalent message authentication code, which it then sends to the client. At the same time, the server begins to use the server encryption key to send encrypted application data to the client; finally, after the client verifies the message authentication code calculated by the client authentication key, the two-way explicit authentication is completed.

2. The certificateless post-quantum TLS handshake method based on KEM and IBE as described in claim 1, characterized in that: Both the KEM algorithm and the IBE algorithm mentioned above employ post-quantum cryptography algorithms that are resistant to quantum computing attacks.

3. The certificateless post-quantum TLS handshake method based on KEM and IBE as described in claim 1, characterized in that: The key generation server (PKG) broadcasts or publishes the system's master public key through public channels. This process does not require a secure channel, and any potential communication party can freely obtain it.

4. The certificateless post-quantum TLS handshake method based on KEM and IBE as described in claim 1, characterized in that: The client challenge ciphertext generation process in step 1 is as follows: The client calls the key generation algorithm of the quantum-resistant key encapsulation mechanism KEM to generate a client temporary public / private key pair; then, it calls the encryption algorithm of the quantum-resistant identity base encryption scheme IBE to encrypt the client temporary public key using the server's identity identifier and master public key to generate the client challenge ciphertext.

5. The certificateless post-quantum TLS handshake method based on KEM and IBE as described in claim 1, characterized in that: The server challenge ciphertext generation process in step 2 is as follows: The server calls the decryption algorithm of the quantum-resistant identity basis encryption scheme IBE, uses the server's private key to decrypt the client challenge ciphertext sent by the client, and obtains the client's temporary public key; After successful decryption, the server calls the key generation algorithm of the quantum-resistant key encapsulation mechanism KEM, and uses the decrypted client temporary public key to generate the server's shared secret and encapsulated ciphertext. Then, the server calls the encryption algorithm of IBE, and uses the client's identity and master public key to encrypt the server's encapsulated ciphertext, generating the server's challenge ciphertext.

6. The certificateless post-quantum TLS handshake method based on KEM and IBE as described in claim 1, characterized in that: The protected server temporary public key generation process in step 2 is as follows: The server calls the decryption algorithm of the quantum-resistant identity basis encryption scheme IBE, uses the server's private key to decrypt the client challenge ciphertext sent by the client, and obtains the client's temporary public key; after successful decryption, the server calls the key generation algorithm of the quantum-resistant key encapsulation mechanism KEM, uses the decrypted client temporary public key to generate the server shared secret and encapsulated ciphertext; then, the server calls the encryption algorithm of IBE, uses the client's identity identifier and master public key to encrypt the server encapsulated ciphertext, and generates the server challenge ciphertext; Then, the server calls the key generation algorithm of the quantum-resistant key encapsulation mechanism (KEM) to generate a temporary public / private key pair; at the same time, it calls the key derivation function, inputting the server's shared secret, the client's random number, and the server's random number, to derive the client's temporary key and the server's temporary key; finally, the server calls a symmetric encryption algorithm to encrypt the server's temporary public key using the server's temporary key, obtaining the protected server's temporary public key.

7. The certificateless post-quantum TLS handshake method based on KEM and IBE as described in claim 1, characterized in that: The protected client-side encapsulated ciphertext generation process in step 3 is as follows: The client uses its private key to decrypt the server challenge ciphertext to obtain the server-side encapsulated ciphertext; then, the client calls the decapsulation algorithm of the quantum-resistant key encapsulation mechanism (KEM) to decapsulate the server-side encapsulated ciphertext using its temporary private key, restoring the server's shared secret; then, the client calls the key derivation function, inputting the server's shared secret, a client random number, and a server random number, to derive the client's temporary key and the server's temporary key; finally, the client calls a symmetric encryption algorithm to decrypt the protected server temporary public key using the server's temporary key, obtaining the server's temporary public key. Then, the client calls the key generation algorithm of the quantum-resistant key encapsulation mechanism KEM, and uses the decrypted temporary public key of the server to generate the client-encapsulated ciphertext and shared secret; then, the client calls the key derivation function again, inputting the server shared secret, the client shared secret, the client random number and the server random number, to derive the encryption key used for data encryption between the two parties, and the authentication key used for explicit authentication between the two parties; Finally, the client invokes a symmetric encryption algorithm, using its temporary key to encrypt the client-encapsulated ciphertext, thus obtaining the protected client-encapsulated ciphertext.

8. The certificateless post-quantum TLS handshake method based on KEM and IBE as described in claim 1, characterized in that: Step 4 specifically involves: calling a symmetric encryption algorithm to decrypt the protected client-encapsulated ciphertext using the client's temporary key, obtaining the client-encapsulated ciphertext; then, the server calls the decapsulation algorithm of the quantum-resistant key encapsulation mechanism (KEM) to recover the client's shared secret; then, the server calls the key derivation function, taking into input the server's shared secret, the client's shared secret, the client's random number, and the server's random number, to derive the encryption key used for data encryption between the two parties, and the authentication key used for explicit authentication between the two parties; Then, the server uses the client authentication key to verify the message authentication code; If the verification is successful, it confirms that the client's identity is genuine and the handshake message has not been tampered with; at the same time, a peer-to-peer message authentication code is calculated using the server's authentication key and sent to the client; At the same time, the server begins to use the server encryption key to send encrypted application data to the client; finally, after the client verifies the message authentication code calculated by the client authentication key, the two-way explicit authentication is completed.

9. The certificateless post-quantum TLS handshake method based on KEM and IBE as described in any one of claims 6 to 8, characterized in that: The symmetric encryption algorithm described uses the AES-256-GCM algorithm.

Images