A tls handshake method fusing post-quantum cryptography (pqc) and quantum key

Abstract

The application discloses a TLS handshake method fusing post-quantum cryptography (PQC) and quantum key, relates to the technical field of quantum communication and network security, and is characterized in that a client and a server respectively acquire three types of shared quantum keys, i.e., a pre-shared quantum key, a handshake traffic quantum key and a service traffic quantum key, from a quantum key distribution device, the pre-shared quantum key is updated before each handshake, the client sends a hello message carrying a PQC temporary public key and a pre-shared quantum key identifier, the server checks a binding value and completes shared key exchange by using a PQC key encapsulation algorithm, both sides obtain a new handshake traffic key by performing exclusive OR operation on a derived handshake traffic key and the handshake traffic quantum key, complete authentication, obtain a new service traffic key by performing exclusive OR operation on a derived service traffic key and the service traffic quantum key, and use the new service traffic key for service data encryption. The application has the anti-quantum computing attack capability by injecting quantum keys in three layers of pre-shared keys, handshake traffic and service traffic and combining PQC key exchange.

Description

Technical Field

[0001] This invention relates to the fields of quantum communication and network security technology, and in particular to a TLS handshake method that integrates post-quantum cryptography (PQC) and quantum key distribution. Background Technology

[0002] When the existing TLS 1.3 protocol uses the PSK+(EC)DH mode, a symmetric PSK needs to be pre-configured out-of-band as an authentication credential, while forward confidentiality is achieved using (EC)DHE ephemeral key exchange. During the handshake, both parties exchange (EC)DHE public keys to calculate an ephemeral shared key. The client calculates a Binder value based on the PSK for the server to verify its identity. Finally, the ephemeral shared key and the PSK are mixed using HKDF to derive the master key, which in turn generates the encryption key for business data.

[0003] However, the above scheme has the following shortcomings: First, PSK is pre-configured offline and remains unchanged for a long time, which increases the risk of leakage and the difficulty of key management. Once leaked, it will lead to identity impersonation and decryption of historical sessions. Second, the security of (EC)DHE relies on the elliptic curve discrete logarithm problem. With the development of quantum computing technology, sufficiently powerful quantum computers can solve this problem in polynomial time. Attackers can record the current encrypted data first, and decrypt all historical communication data after the computing power matures, so that this mode loses its forward secrecy capability when facing quantum computing attacks. Summary of the Invention

[0004] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is: to provide a TLS handshake method that integrates post-quantum cryptography (PQC) and quantum key distribution, comprising the following steps: S1: The client and server respectively obtain a shared quantum key from the quantum key distribution device. The shared quantum key includes a pre-shared quantum key, a handshake traffic quantum key, and a service traffic quantum key. The pre-shared quantum key is obtained and updated before each handshake. S2: The client sends a client greeting message to the server carrying a key identifier of the PQC temporary public key and the pre-shared quantum key. The server verifies the binding value based on the pre-shared quantum key and completes the shared key exchange based on the PQC temporary public key using the PQC key encapsulation algorithm. S3: The client and the server respectively derive handshake traffic keys, XOR the derived handshake traffic keys with the handshake traffic quantum keys to obtain new handshake traffic keys, and complete the handshake authentication by writing keys based on the derived handshake traffic keys. S4: The client and the server respectively derive service traffic keys, XOR the derived service traffic keys with the service traffic quantum keys to obtain new service traffic keys, and use the derived service traffic key for encrypted transmission of service data.

[0005] Furthermore, the steps for the client and server to obtain a shared quantum key from the quantum key distribution device include: one quantum key distribution device reads a quantum key of a specified length from its quantum key pool according to the read pointer and moves the read pointer forward, and sends the read pointer, length, and hash value of the quantum key to the other end; the other quantum key distribution device reads a quantum key of the same length from its quantum key pool according to the read pointer and moves the read pointer forward, calculates the hash value and compares it with the received hash value, and if the comparison is consistent, the acquisition is confirmed to be successful.

[0006] Furthermore, the length L of the pre-shared quantum key is not less than 32 bytes. Before each handshake, the client reads a quantum key of length L from the quantum key pool of its side quantum key distribution device as the pre-shared quantum key, and sends the read pointer, length L and hash value of the pre-shared quantum key in the quantum key pool to the server. The server obtains the same-length quantum key according to the read pointer and returns a success message after comparing the hash value.

[0007] Furthermore, the PQC key encapsulation algorithm is an ML-KEM type algorithm, which uses the Kyber algorithm; the identity authentication during the quantum key acquisition process uses the Dilithium algorithm, and the quantum key transmission encryption uses the Kyber algorithm.

[0008] Furthermore, the steps for the client and the server to derive the handshake traffic key include: exchanging a shared key and an early key using the PQC key encapsulation algorithm, obtaining the handshake root key through an extraction step, deriving the client handshake traffic key and the server handshake traffic key using the HKDF-Expand-Label function, XORing them with the handshake traffic quantum key to obtain the new handshake traffic key, and then deriving the handshake traffic write key and the handshake traffic write key initial vector using the HKDF-Expand-Label function.

[0009] Further, the steps for completing the handshake authentication include: the server derives a completion key based on the server handshake traffic key in the new handshake traffic key, calculates a server completion message using a first handshake record hash, and sends it; the first handshake record hash consists of a client greeting message, a server greeting message, and an encrypted extension message; the client derives a completion key based on the client handshake traffic key in the new handshake traffic key, calculates a client completion message using a second handshake record hash, and sends it; the second handshake record hash is formed by appending the server completion message to the first handshake record hash; both parties compare and verify the server completion message and the client completion message.

[0010] Furthermore, when the service traffic key is updated, the client and the server respectively reacquire the service traffic quantum key, XOR the newly derived service traffic key with the service traffic quantum key to obtain the updated service traffic key, and derive the service traffic write key and the service traffic write key initial vector based on it.

[0011] Compared with the prior art, the present invention has the following beneficial technical effects: First, quantum keys are injected into the three layers of pre-shared key, handshake traffic, and service traffic, and XORed with the keys derived from HKDF. This ensures that the keys at each layer are protected by both PQC computational security and quantum key physical security. A single breach will not lead to session key leakage. Moreover, this two-layer XOR injection structure is a synergistic effect that cannot be achieved by a single PQC technology or a single quantum key technology.

[0012] Secondly, the pre-shared quantum key is updated by retrieving it from the quantum key distribution device before each handshake, replacing the static PSK that is offline and unchanging in the existing TLS 1.3, thus avoiding the risks of leakage and identity impersonation caused by the long-term unchanging PSK.

[0013] Furthermore, the key exchange uses the PQC key encapsulation algorithm instead of the (EC)DHE algorithm, which relies on the elliptic curve discrete logarithm problem. This resists quantum computing attacks from the perspective of computational complexity and eliminates the threat of attackers storing encrypted data first and then decrypting it.

[0014] Finally, this solution does not change the original TLS 1.3 handshake process and message structure, and is compatible with existing TLS 1.3 application scenarios, including but not limited to web browsing, email transmission, remote login, instant messaging communication, etc., while maintaining protocol compatibility and gaining the ability to resist quantum computing attacks. Attached Figure Description

[0015] Figure 1 A schematic diagram of the architecture and overall process of a TLS handshake system integrating PQC and quantum key distribution provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the message interaction timing of the TLS handshake process provided in an embodiment of the present invention; Figure 3 A schematic diagram illustrating the process of handshake traffic key derivation and XOR fusion with quantum key according to an embodiment of the present invention; Figure 4 This is a schematic diagram illustrating the process of deriving service traffic keys and XORing them with quantum keys, as provided in an embodiment of the present invention. Detailed Implementation

[0016] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0017] Terminology Explanation: (1) PQC: Post-quantum cryptography, refers to cryptographic algorithms that can resist quantum computing attacks. In this embodiment, the key encapsulation adopts the ML-KEM type algorithm, specifically the Kyber algorithm, and the identity authentication adopts the Dilithium algorithm. (2) QKD: Quantum Key Distribution. QKD_A and QKD_B are quantum key distribution devices deployed on the client side and server side respectively. They generate a shared and consistent quantum key through quantum link negotiation and store it in their respective quantum key pools. (3) PSK: Pre-shared key. This scheme replaces the static PSK pre-built offline in the existing TLS1.3 with a pre-shared quantum key QPSK distributed by a quantum key distribution device. (4) Three types of shared quantum keys: pre-shared quantum key, used for identity authentication and original materials for key derivation at each stage; handshake flow quantum key, used for XOR with handshake flow key; business flow quantum key, used for XOR with business flow key; (5) Read pointer: The offset in the quantum key pool that marks the current readable position. It moves forward by the corresponding number of bits after reading a specified length of key. (6) Truncate the client greeting message: refers to the part of the client greeting message that precedes the binding value of the pre_shared_key extension, i.e., the client greeting message prefix on which the binding value is based; (7) XOR fusion: XOR the key derived from HKDF with the quantum key of the same length bit by bit to obtain a new key that has the properties of both; (8) HKDF-Extract and HKDF-Expand-Label: Key derivation functions defined in TLS 1.3, HMAC is a hash-based message authentication code, and Transcript-Hash is the hash value of the handshake message record.

[0018] Example 1 The TLS handshake method integrating PQC and quantum key distribution, as described in this embodiment, includes the following steps: S1: Quantum key distribution and acquisition of three types of shared quantum keys.

[0019] QKD_A and QKD_B each contain a QKD module and a quantum key pool. The QKD modules in QKD_A and QKD_B distribute quantum keys via a QKD link, generating a shared quantum key. After both ends generate a certain amount of shared quantum key (e.g., 1KB), the hash values ​​of the generated quantum keys are verified to ensure consistency. If they match, the quantum keys are stored in their respective quantum key pools. The client and server securely obtain quantum keys from the key pools of QKD_A and QKD_B, respectively, for use in pre-shared keys, handshake traffic key generation, and business traffic key generation. Security protection during the quantum key acquisition process employs the Dilithium algorithm from the PQC algorithm for authentication and the Kyber algorithm from the PQC algorithm for protecting the encryption key during transmission.

[0020] The process of obtaining the pre-shared quantum key (QPSK) for each handshake update is as follows: Before each handshake, the client first obtains a shared quantum key of length L (L is greater than or equal to 32 bytes) from the key pool of QKD_A as the pre-shared key QPSK_A. The read pointer of the quantum key in the key pool is QPSK_RP. At this time, the read pointer of QKD_A in the key pool is shifted forward by L positions. The client sends the read pointer QPSK_RP, the key length L, and the hash value of the key QPSK_A to the server. The server obtains a shared quantum key of length L, QPSK_B, from the key pool of QKD_B according to the read pointer QPSK_RP. At this time, the read pointer of QKD_B in the key pool is shifted forward by L positions. The server calculates the hash value of QPSK_B and compares it with the hash value of QPSK_A sent by the client. If the comparison is consistent, the server returns a message indicating that the QPSK key has been successfully obtained to the client. The acquisition mechanism for the handshake traffic quantum key and the service traffic quantum key is the same, except that the length of the acquired key is the same as that of the handshake traffic key and the service traffic key, respectively.

[0021] S2: Client greeting message sending, binding value verification, and PQC key exchange.

[0022] like Figure 2The diagram illustrates the message interaction timing of the TLS handshake process according to an embodiment of the present invention. It details the sequence of messages along the timeline during the handshake. QKD_A and QKD_B exchange quantum keys. QKD_A sends a quantum key, i.e., a pre-shared key, to the client; simultaneously, QKD_B sends a quantum key, also a pre-shared key, to the server. Next, the client sends a client key exchange message to the server. Afterwards, QKD_A and the client, and QKD_B and the server, respectively, exchange quantum keys again. Immediately following, QKD_A sends a quantum key to the client, i.e., the client handshake traffic key and the server handshake traffic key; QKD_B also sends the same quantum key to the server.

[0023] Afterwards, the server sends a server key exchange message and a server completion message to the client for authentication. The client then sends a client completion message to the server for authentication. Once authentication is complete, QKD_A and the client, and QKD_B and the server, respectively, perform another quantum key acquisition operation. QKD_A then sends the quantum key to the client, which is the initial client-side business traffic key and the initial server-side business traffic key. QKD_B sends the same quantum key to the server. During this stage, bidirectional encrypted transmission of business data begins between the client and the server, followed by bidirectional business traffic key update operations.

[0024] After the key update, QKD_A and the client, and QKD_B and the server, perform a final quantum key acquisition operation. Then, QKD_A sends the updated quantum key to the client, which contains both the updated client and server service traffic keys. QKD_B sends the same quantum key to the server. Finally, the client and server perform another round of bidirectional encrypted transmission of service data, completing the entire communication process.

[0025] Specifically, the client sends the first handshake message to the server, which includes ClientHello and its extensions. The extensions include: supported_version (TLS 1.3); key_share (PQC temporary public key PK_PQC); psk_key_exchange_modes (PQC key exchange algorithm identifier, PQC can use the Kyber algorithm); pri_extension (private extension parameters); and pre_shared_key (QPSK key identifier, i.e., read pointer QPSK_RP and binder checksum).

[0026] The binding value (binder) is calculated as follows: EarlySecret=HKDF-Extract(Zero,QPSK_A) binder_key=HKDF-Expand-Label(EarlySecret,extbinder|resbinder,empty,Hash.length) binder verification value = HMAC(binder_key, truncated ClientHello) Zero is a string of all zero bytes with a length equal to the length of the hash output (corresponding to 0 in the RFC8446 key scheduling diagram), and Hash.length is the length of the output bytes of the hash function used.

[0027] After receiving the handshake message from the client, the server verifies the binding value: Based on the QPSK key identifier (read pointer QPSK_RP), it selects the acquired quantum key QPSK_B, calculates the binding value using QPSK_B according to the above formulas, and compares it with the binding value sent by the client. If the comparison matches, the verification is successful, indicating that the client's identity has been successfully authenticated. Subsequently, the server uses the client's PQC temporary public key PK_PQC to perform key encapsulation operations, generating a shared key SharedSecret and shared key ciphertext SharedSecret_s. The key encapsulation method is as follows: (SharedSecret_s,SharedSecret)=PQC_Enc(PK_PQC) PQC_Enc is the Kyber key encapsulation algorithm.

[0028] S3: Handshake flow key derivation, XOR fusion with quantum key, and handshake authentication.

[0029] The server calculates the handshake root key and handshake traffic key. Figure 3 This is a schematic diagram illustrating the handshake flow key derivation and XOR fusion with quantum keys according to an embodiment of the present invention. At the very top of the flow is the pre-shared key box, which points downwards to the early key box. Simultaneously, the shared key box on the left and the early key box both point to the handshake root key box.

[0030] The handshake root key box branches downwards into two main branches, left and right.

[0031] In the left branch, the handshake root key derives the client handshake traffic key box downwards. This client handshake traffic key box, along with the quantum key client handshake traffic key box to its left, points downwards to the XORed client handshake traffic key box. Subsequently, the XORed client handshake traffic key box branches downwards again, pointing to the underlying client handshake traffic write key box and the client handshake traffic write key initialization vector box, respectively.

[0032] In the right-hand branch, the structure is symmetrical to the left. The root handshake key derives downwards into the server-side handshake traffic key box. The quantum key and server-side handshake traffic key to the right of the server-side handshake traffic key box together point downwards to the XORed server-side handshake traffic key box. Finally, the XORed server-side handshake traffic key box branches downwards, pointing respectively to the server-side handshake traffic write key box and the server-side handshake traffic write key initialization vector box. The process is as follows: HandshakeSecret=HKDF-Extract(EarlySecret,SharedSecret) Transcript-Hash=H(ClientHello,ServerHello) client_hs_secret=HKDF-Expand-Label(HandshakeSecret,chstraffic,Transcript-Hash,Hash.length) server_hs_secret=HKDF-Expand-Label(HandshakeSecret,shstraffic,Transcript-Hash,Hash.length) The server retrieves a shared quantum key of the same length as `client_hs_secret` from the key pool of QKD_B. QKD_B returns the quantum key `Q_client_hs_secret_B` and its read pointer `Q_client_hs_RP`, shifting the read pointer forward by the same number of bits as `Q_client_hs_secret_B`. The server sends the read pointer `Q_client_hs_RP`, the length of the key `Q_client_hs_secret_B`, and its hash value to the client. The client then retrieves the shared quantum key `Q_client_hs_secret_A` from the key pool of QKD_A, shifting the read pointer synchronously and calculating its hash value. If the hash value matches the one sent by the server, a success message is returned. Similarly, the server retrieves the quantum key `Q_server_hs_secret_B` corresponding to `server_hs_secret`, and the client retrieves `Q_server_hs_secret_A`. The handshake traffic key is XORed with the retrieved quantum key, and the resulting XORed key is used as the new handshake traffic key. new_client_hs_secret=client_hs_secret⊕Q_client_hs_secret_B new_server_hs_secret=server_hs_secret⊕Q_server_hs_secret_B Calculate the handshake flow write key and initialization vector: server_hs_write_key=HKDF-Expand-Label(new_server_hs_secret,key,empty,L_Key) server_hs_write_iv=HKDF-Expand-Label(new_server_hs_secret,iv,empty,L_IV) client_hs_write_key=HKDF-Expand-Label(new_client_hs_secret,key,empty,L_Key) client_hs_write_iv=HKDF-Expand-Label(new_client_hs_secret,iv,empty,L_IV) The server constructs the `server_Finished` message: The completion key is derived from the new server handshake traffic key, and the Transcript-Hash is calculated using the hashes of `ClientHello`, `ServerHello`, and `EncryptedExtensions`. server_finished_key=HKDF-Expand-Label(new_server_hs_secret,finished,empty,Hash.length) server_Finished=HMAC(server_finished_key,Transcript-Hash) The server sends a message to the client, including ServerHello and its extensions, as well as EncryptedExtensions and server_Finished encrypted using server_hs_write_key. The extensions include supported_version (TLS 1.3), key_share (SharedSecret_s), and pre_shared_key (the key identifier of the verified QPSK).

[0033] After receiving the message from the server, the client retrieves the shared secret ciphertext SharedSecret_s from key_share, and uses the PQC temporary private key SK_PQC to decrypt it to obtain the shared secret. SharedSecret=PQC_Dec(SharedSecret_s,SK_PQC) Where PQC_Dec is the Kyber decapsulation algorithm, and SK_PQC is the client's temporary PQC private key. The client calculates HandshakeSecret, client_hs_secret, and server_hs_secret using the same formula as described above, and XORs the handshake traffic key with Q_client_hs_secret_A and Q_server_hs_secret_A respectively to obtain new_client_hs_secret, new_server_hs_secret, and the handshake traffic write key, which are identical to those on the server. The client independently calculates server_Finished, decrypts the server_Finished sent by the server using server_hs_write_key, and compares it with the server_Finished. If the comparison matches, the authentication with the server is successful.

[0034] The client then constructs the `client_Finished` message: the completion key is derived from the new client handshake traffic key, and its Transcript-Hash is constructed by appending `server_Finished` to `ClientHello`, `ServerHello`, and `EncryptedExtensions`, consistent with RFC8446, ensuring that `client_Finished` overrides `server_Finished`. client_finished_key=HKDF-Expand-Label(new_client_hs_secret,finished,empty,Hash.length) client_Finished=HMAC(client_finished_key,Transcript-Hash) The client encrypts `client_Finished` using `client_hs_write_key` and sends it to the server. The server calculates `client_Finished` using the same formula, decrypts the received `client_Finished` using `client_hs_write_key`, and compares it with the encrypted `client_Finished`. If they match, authentication is successful, and the handshake is complete.

[0035] S4: Business traffic key derivation, XOR fusion with quantum key and key writing.

[0036] The client and server respectively derive business traffic keys and write keys for encrypted transmission of subsequent business data. Figure 4 This is a flowchart illustrating the process of deriving service traffic keys and XORing them with quantum keys, as provided in an embodiment of the present invention. The flowchart demonstrates the hierarchical derivation relationship of the key system. At the top is the pre-shared key node, which points downwards to earlier key nodes.

[0037] The early key node, together with the shared key node on the left, continues downward to the handshake root key node, which in turn points downward to the core business data encryption root key node.

[0038] The business data encryption root key node branches into two main branches, left and right, at the bottom.

[0039] In the left branch, a client-side initial service traffic key node is derived from the business data encryption root key. This client-side initial service traffic key node and the quantum key client-side initial service traffic key are XORed together and input into the XORed client-side initial service traffic key node. Subsequently, the XORed client-side initial service traffic key node branches downwards again, deriving the underlying client-side initial service traffic write key node and the client-side initial service traffic write key initial vector node.

[0040] The right-side branch structure is symmetrical to the left-side structure. The root key for encrypting business data derives the initial server-side business traffic key node. This initial server-side business traffic key node and the initial quantum key server-side business traffic key node are both input downwards and XORed with each other to form the next initial server-side business traffic key node. Finally, the XORed initial server-side business traffic key node branches downwards, deriving the initial server-side business traffic write key node and the initial initial vector node for the initial server-side business traffic write key. The key derivation process is as follows: MasterSecret=HKDF-Extract(HandshakeSecret,Zero) Transcript-Hash=H(ClientHello,ServerHello,EncryptedExtensions,server_Finished) client_app_0=HKDF-Expand-Label(MasterSecret,captraffic,Transcript-Hash,Hash.length) server_app_0=HKDF-Expand-Label(MasterSecret,saptraffic,Transcript-Hash,Hash.length) The server and client obtain the service traffic quantum keys Q_client_app_0_B, Q_server_app_0_B, Q_client_app_0_A, and Q_server_app_0_A, respectively, of the same length as client_app_0 and server_app_0, from QKD_B and QKD_A, respectively, according to the read pointer mechanism described in S1, and verify their consistency through hash comparison. The initial service traffic key is then XORed with the quantum key to obtain the new service traffic key. new_client_app_0=client_app_0⊕Q_client_app_0_A / B new_server_app_0=server_app_0⊕Q_server_app_0_A / B Calculate the write key and initialization vector for the business traffic between the client and server, which will be used for the encryption and decryption of subsequent business messages: client_write_key=HKDF-Expand-Label(new_client_app_0,key,empty,L_Key) client_write_iv=HKDF-Expand-Label(new_client_app_0,iv,empty,L_IV) server_write_key=HKDF-Expand-Label(new_server_app_0,key,empty,L_Key) server_write_iv=HKDF-Expand-Label(new_server_app_0,iv,empty,L_IV) L_Key is the byte length of the write key as defined by the cipher suite, and L_IV is the byte length of the initialization vector as defined by the cipher suite.

[0041] S5: Business traffic key update.

[0042] When a client or server initiates a KeyUpdate message, the business traffic key is updated, and the write keys and initialization vectors for both the client and server are recalculated. Assuming the number of updates is N, the updated business traffic key is calculated as follows: client_app_N=HKDF-Expand-Label(new_client_app_N-1,trafficupd,empty,Hash.length) server_app_N=HKDF-Expand-Label(new_server_app_N-1,trafficupd,empty,Hash.length) The client and server obtain new business traffic quantum keys from the key pools of QKD_A and QKD_B, respectively, using the same method as the read pointer mechanism in S1. The obtained quantum keys are Q_client_app_N_A, Q_server_app_N_A, Q_client_app_N_B, and Q_server_app_N_B, respectively. The business traffic keys are then XORed with the quantum keys to obtain the updated business traffic key for the Nth time. new_client_app_N=client_app_N⊕Q_client_app_N_A / B new_server_app_N=server_app_N⊕Q_server_app_N_A / B The updated client and server write keys and initialization vectors are then calculated for use in the encryption and decryption of subsequent business messages: client_write_key=HKDF-Expand-Label(new_client_app_N,key,empty,L_Key) client_write_iv=HKDF-Expand-Label(new_client_app_N,iv,empty,L_IV) server_write_key=HKDF-Expand-Label(new_server_app_N,key,empty,L_Key) server_write_iv=HKDF-Expand-Label(new_server_app_N,iv,empty,L_IV) It should be noted that the business traffic key update in this scheme uses new_client_app_N-1 and new_server_app_N-1 obtained after the previous XOR fusion as the input for the next round of HKDF derivation. This ensures that the business traffic key obtained in each update is protected by both the PQC derivation chain and the quantum key, thereby enhancing security while maintaining the original protocol context link.

[0043] The security protocol proposed in this solution has the same handshake process as the TLS 1.3 protocol and is applicable to TLS 1.3 application scenarios, including but not limited to web browsing, email transmission, remote login, instant messaging communication, etc. It is used to ensure the confidentiality and integrity of data transmission between the client and the server in the above scenarios, and has the characteristics of resistance to quantum computing attacks compared with the existing TLS 1.3 protocol.

[0044] Example 2 This embodiment proposes a TLS handshake system that integrates post-quantum cryptography (PQC) and quantum key distribution (QKD), and its overall architecture is as follows: Figure 1 As shown, the system includes a client, a server, a first quantum key distribution device QKD_A, and a second quantum key distribution device QKD_B. QKD_A is connected to the client, and QKD_B is connected to the server. QKD_A and QKD_B negotiate and generate a shared quantum key through a quantum link and store them in their respective quantum key pools. Both the client and server are configured with a key acquisition module, a key derivation module, a PQC encapsulation module, and an XOR fusion module. These modules work collaboratively according to steps S1 to S5 as described in Embodiment 1 to jointly complete the TLS handshake that fuses the PQC and quantum key.

[0045] First, QKD_A and QKD_B perform the quantum key acquisition operations to the left and right sides respectively. QKD_A sends the quantum key to the client, while QKD_B sends the quantum key to the server. Then, the client sends a client key exchange message to the server, the server sends a server key exchange message and a server completion message to the client for authentication, and the client sends a client completion message to the server for authentication.

[0046] After authentication, the client and server begin bidirectional encrypted transmission of business data, followed by bidirectional business traffic key update operations.

[0047] After the update is complete, to prepare for a new round of encrypted transmission, QKD_A and QKD_B again perform the operation of obtaining the quantum key. QKD_A sends the quantum key to the client, and QKD_B sends the quantum key to the server. Finally, the client and server once again perform bidirectional encrypted transmission of business data, completing the interaction process described in the flowchart.

[0048] Specifically, the key acquisition module retrieves three types of shared quantum keys from the quantum key pool of the local quantum key distribution device according to the read pointer, and sends the read pointer, length, and hash value to the peer. The consistency of the keys is confirmed through hash comparison. The PQC encapsulation module performs Kyber key encapsulation and decapsulation to complete the exchange of shared keys and executes the Dilithium algorithm for authentication during the quantum key acquisition process. Based on this, the key derivation module derives the handshake traffic key, handshake traffic write key, service traffic key, and service traffic write key from the shared key obtained through the PQC key encapsulation algorithm using HKDF. Subsequently, the XOR fusion module performs a bitwise XOR operation between the derived handshake traffic key and service traffic key and the corresponding level's handshake traffic quantum key and service traffic quantum key to obtain new handshake traffic keys and new service traffic keys.

[0049] In the complete handshake and data transmission process, the stages are performed sequentially: The client initiates a request (ClientHello): The client sends a greeting message, which includes the supported protocol version (supported_version), the key sharing parameters for key exchange (key_share), the PSK key exchange mode (psk_key_exchange_modes), and related pre-shared key extension information (pri_extension and pre_shared_key, referring to the specific PSK extension data).

[0050] Server response (ServerHello): After receiving the request, the server replies with the selected version, its own key sharing parameters, and confirms the use of the pre-shared key (pre_shared_key); then, the server immediately sends the encrypted extension information ({EncryptedExtensions}) and a closing message ({Finished}) confirming the handshake is complete.

[0051] Client completes handshake (Finished): The client sends its own encrypted {Finished} message, indicating that the key exchange and handshake phase has successfully ended.

[0052] Application Data Transmission: Both parties begin transmitting encrypted application data ([Application Data]) using the agreed-upon session key.

[0053] Key Update: During transmission, to ensure forward security, one party initiates a Key Update command to generate a new encryption key.

[0054] Subsequent data transmission: After the key is updated, both parties continue to transmit encrypted application data ([ApplicationData]) under the protection of the new key.

[0055] As can be seen, the system establishes a shared quantum key through quantum key distribution, and realizes shared key exchange and identity authentication through PQC key encapsulation (Kyber / Dilithium). Then, it derives various session keys through HKDF, and finally fuses the quantum key and the derived key bit by bit through XOR fusion, thereby realizing encrypted data transmission and key update in each stage of the TLS handshake, taking into account both quantum security and forward security.

[0056] In a preferred embodiment, a computer-readable storage medium is also provided, on which a computer program is stored. When executed by a processor, the computer program implements the TLS handshake method integrating PQC and quantum key distribution as described in Embodiment 1. This embodiment also provides an electronic device, including a processor and a memory, on which a computer program is stored. When the processor executes the computer program, it implements the TLS handshake method integrating PQC and quantum key distribution as described in Embodiment 1.

[0057] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A TLS handshake method integrating post-quantum cryptography (PQC) and quantum key distribution, characterized in that, Includes the following steps: S1: The client and server respectively obtain a shared quantum key from the quantum key distribution device. The shared quantum key includes a pre-shared quantum key, a handshake traffic quantum key, and a service traffic quantum key. The pre-shared quantum key is obtained and updated before each handshake. S2: The client sends a client greeting message to the server carrying a key identifier of the PQC temporary public key and the pre-shared quantum key. The server verifies the binding value based on the pre-shared quantum key and completes the shared key exchange based on the PQC temporary public key using the PQC key encapsulation algorithm. S3: The client and the server respectively derive handshake traffic keys, XOR the derived handshake traffic keys with the handshake traffic quantum keys to obtain new handshake traffic keys, and complete the handshake authentication by writing keys based on the derived handshake traffic keys. S4: The client and the server respectively derive a service traffic key, XOR the derived service traffic key with the service traffic quantum key to obtain a new service traffic key, and derive a service traffic key based on it for use in encrypted transmission of service data.

2. The TLS handshake method for integrating quantum cryptography (PQC) and quantum key distribution according to claim 1, characterized in that, The steps for the client and server to obtain a shared quantum key from a quantum key distribution device include: one quantum key distribution device reads a quantum key of a specified length from its quantum key pool according to the read pointer and moves the read pointer forward, and sends the read pointer, length, and hash value of the quantum key to the other end; the other quantum key distribution device reads a quantum key of the same length from its quantum key pool according to the read pointer and moves the read pointer forward, calculates the hash value and compares it with the received hash value, and if the comparison is consistent, the acquisition is confirmed to be successful.

3. The TLS handshake method for integrating quantum cryptography (PQC) and quantum key distribution according to claim 2, characterized in that, The length L of the pre-shared quantum key is not less than 32 bytes. Before each handshake, the client reads a quantum key of length L from the quantum key pool of its side quantum key distribution device as the pre-shared quantum key, and sends the read pointer, length L and hash value of the pre-shared quantum key in the quantum key pool to the server. The server obtains the same-length quantum key according to the read pointer and returns a success message after comparing the hash value.

4. The TLS handshake method for integrating quantum cryptography (PQC) and quantum key distribution according to claim 1, characterized in that, The PQC key encapsulation algorithm is an ML-KEM type algorithm, which uses the Kyber algorithm; the identity authentication in the quantum key acquisition process uses the Dilithium algorithm, and the quantum key transmission encryption uses the Kyber algorithm.

5. The TLS handshake method for integrating quantum cryptography (PQC) and quantum key distribution according to claim 1, characterized in that, The steps for the client and the server to derive the handshake traffic key include: exchanging a shared key and an early key using the PQC key encapsulation algorithm, obtaining the handshake root key through an extraction step, deriving the client handshake traffic key and the server handshake traffic key using the HKDF-Expand-Label function, XORing them with the handshake traffic quantum key to obtain the new handshake traffic key, and then deriving the handshake traffic write key and the handshake traffic write key initial vector using the HKDF-Expand-Label function.

6. The TLS handshake method for integrating quantum cryptography PQC and quantum key distribution according to claim 5, characterized in that, The steps for completing the handshake authentication include: the server derives a completion key based on the server handshake traffic key in the new handshake traffic key, calculates a server completion message using a first handshake record hash, and sends it; the first handshake record hash consists of a client greeting message, a server greeting message, and an encrypted extension message; the client derives a completion key based on the client handshake traffic key in the new handshake traffic key, calculates a client completion message using a second handshake record hash, and sends it; the second handshake record hash is formed by appending the server completion message to the first handshake record hash; both parties compare and verify the server completion message and the client completion message.

7. The TLS handshake method for integrating quantum cryptography (PQC) and quantum key distribution according to claim 1, characterized in that, When the service traffic key is updated, the client and the server respectively reacquire the service traffic quantum key, XOR the newly derived service traffic key with the service traffic quantum key to obtain the updated service traffic key, and derive the service traffic write key and the service traffic write key initial vector based on it.

Images