Method and system for integrating quantum key one-time pad in tls record layer

Abstract

The application discloses a method and system for fusing quantum key one-time pad in a TLS record layer, and relates to the technical field of quantum security communication, which comprises the following steps: a client and a server perform a standard TLS handshake protocol, complete bidirectional identity authentication, negotiate encryption suite parameters, generate a unique session identifier, generate a classical key through a classical key exchange algorithm, and declare a quantum key enhancement mode in a handshake message extension field; after the handshake is completed, the client and the server are connected to a locally deployed quantum key manager through a secure channel respectively, submit the unique session identifier for session binding, obtain corresponding quantum key stream identifiers, exchange information of the quantum key stream identifiers of both parties, and perform one-time pad encryption transmission; the method effectively prevents sensitive data leakage and tampering risks without changing the structure of the TLS protocol stack, and improves the information transmission security strength.

Description

Technical Field

[0001] This invention relates to the field of quantum secure communication technology, and in particular to a method and system for integrating quantum key distribution in the TLS record layer. Background Technology

[0002] Traditional TLS protocols use asymmetric cryptography algorithms for authentication and key exchange. Clients and servers use Elliptic Curve Diffie-Hellman key exchange (ECDH) to generate session keys and rely on algorithms like RSA / ECC for forward security. However, with breakthroughs in quantum computing, Shor's algorithm (quantum factorization algorithm) can break existing asymmetric cryptosystems in polynomial time, posing a quantum computing threat to the core key exchange mechanism of TLS protocols. Quantum Key Distribution (QKD) technology, based on the quantum no-cloning theorem and the uncertainty principle, can provide information-theoretically secure keystreams for both communicating parties.

[0003] Existing related technical solutions, such as patents CN118540163B "Method for Enhancing Quantum Security of Chinese National Cryptographic SSL VPN Protocol" and CN116865966B "Encryption Method, Device, and Storage Medium for Generating Working Keys Based on Quantum Keys," mainly focus on using QKD to replace the traditional key negotiation process and deriving more secure session keys based on quantum keys. However, these methods do not fully utilize the unconditional security advantage of quantum keys' "one-time pad" encryption, especially in data protection at the TLS protocol record layer. Furthermore, patent CN116743372A "Method and System for Implementing Quantum-Secure Protocol Based on SSL Protocol" proposes directly using quantum keys for MAC authentication and encryption of record layer data, but it still does not achieve a strictly true one-time pad encryption mode.

[0004] In summary, current technologies have not yet achieved seamless integration of quantum keys with TLS layered encryption architecture, making it difficult to effectively transfer the advantages of quantum security to the application layer, and there are technical problems that urgently need to be solved. Summary of the Invention

[0005] Based on the technical problems existing in the background technology, this invention proposes a method and system for integrating quantum key one-time pad in the TLS record layer. Without changing the TLS protocol stack structure, it effectively prevents the risk of sensitive data leakage and tampering, and improves the security of information transmission.

[0006] The present invention proposes a method for fusing quantum key distribution in the TLS record layer using one-time pad technology, comprising:

[0007] The client and server execute the standard TLS handshake protocol, complete two-way authentication and negotiate cipher suite parameters, generate a unique session identifier, generate a classic key through the classic key exchange algorithm, and declare the quantum key enhancement mode in the handshake message extension field;

[0008] After the handshake is completed, the client and server connect to the locally deployed quantum key manager through a secure channel, submit the unique session identifier for session binding, obtain the corresponding quantum key stream identifier, and exchange information of the quantum key stream identifiers of both parties to perform a one-pad encrypted transmission.

[0009] Furthermore, during the data execution phase after the handshake is completed, when the client or the server, acting as the encryptor, performs a one-pad encrypted transmission, the following steps are executed:

[0010] A fixed-length quantum key is obtained from the local quantum key manager based on the unique session identifier. The classical key is used to derive an enhanced classical key through a pseudo-random function. An independent message authentication key is then derived using the quantum key, the enhanced classical key, and a hash function.

[0011] At the TLS record layer, the application layer plaintext is divided into multiple data segments. The message authentication key is used to calculate message authentication code one for each data segment and associated information. Each data segment is combined with the corresponding message authentication code one to obtain a plaintext data group.

[0012] Obtain an encrypted quantum key stream of equal length to each of the data groups based on the sender's quantum key stream identifier;

[0013] The plaintext data group is XORed using the encrypted quantum key stream to generate a ciphertext record block;

[0014] A TLS header is added to the ciphertext record block to encapsulate it into a ciphertext data packet. The TLS header includes information on type, protocol version, and data segment length.

[0015] Further, the step of obtaining an encrypted quantum key stream of equal length to each data group based on the sender's quantum key stream identifier specifically involves:

[0016] The sender sends a quantum key request to the local quantum key manager through a quantum key stream identifier to obtain an encrypted quantum key stream cache. The key request information includes: the quantum key stream identifier and the requested quantum key length.

[0017] Furthermore, in the step of calculating the message authentication code for each data segment and associated information using the message authentication key pair, the associated information includes: sequence number, type, protocol version, and data segment length.

[0018] Furthermore, during the data execution phase after the handshake is completed, when the client or the server, as the receiver, performs a one-key encrypted transmission, the following steps are executed:

[0019] After the TCP layer completes the reassembly and sorting of the ciphertext data packets, the record layer protocol processes the data and extracts the TLS record header.

[0020] A fixed-length quantum key two is obtained from the local quantum key manager based on the quantum key stream identifier of the sender. The classical key is used to derive an enhanced classical key through a pseudo-random function. An independent message authentication key two is then derived using quantum key two, the enhanced classical key, and a hash function.

[0021] Obtain the decryption quantum key stream of the same length as the ciphertext record block based on the sender's quantum key stream identifier;

[0022] The ciphertext record block is XORed and decrypted using the decryption quantum key stream to obtain the plaintext data group;

[0023] Use message authentication key two to verify the integrity and sequence continuity of message authentication code one in the plaintext data group.

[0024] Furthermore, the step of using message authentication key two to verify the integrity and sequence continuity of message authentication code one in the plaintext data group specifically involves:

[0025] The receiver uses message authentication key two to recalculate message authentication code two for multiple data segments of the plaintext and associated information;

[0026] The message authentication code 2 is compared with the message authentication code 1 in the plaintext data group obtained by decryption using the decryption quantum key stream. If they match, the application layer plaintext is obtained. If they do not match, the quantum key stream sequence synchronization fails or the data is tampered with, and the client and server terminate the TLS connection.

[0027] Furthermore, the client and server are each locally deployed with a directly connected quantum key manager to store the quantum keys generated by the quantum key distribution device. The quantum key manager uses the quantum key stream identifier as an index to associate and store the corresponding quantum key stream cache.

[0028] Furthermore, the client declares the quantum key enhancement mode as quantum one-time pad in the handshake message extension field. If the server does not support quantum one-time pad, or if the quantum key manager connected to the server cannot provide a usable quantum key cache, both parties fall back to the standard TLS encryption mode.

[0029] Furthermore, the client and server respectively connect to the locally deployed quantum key manager through a secure channel, submit the unique session identifier for session binding, and obtain the corresponding quantum key stream identifier, specifically:

[0030] The client and server use the unique session identifier to register a session with their respective connected quantum key managers;

[0031] The quantum key manager initializes the quantum key stream cache using the unique session identifier and generates a quantum key stream identifier;

[0032] The local quantum key manager is indexed using the quantum key stream identifier to obtain the corresponding quantum key stream.

[0033] A computer system includes a memory, a processor, and a computer program stored in the memory, the processor executing the computer program to implement the method as described above.

[0034] The advantages of the method and system for integrating quantum key distribution (QKD) one-time pad encryption into the TLS record layer provided by this invention are as follows: While fully preserving the original handshake negotiation mechanism of the TLS protocol, it introduces the key stream generated by QKD technology into the transport layer security system. By designing a layered key derivation architecture, a dual security mechanism of quantum key-driven one-time pad encryption and quantum key-enhanced integrity protection is implemented at the record layer. This scheme effectively prevents the risk of sensitive data leakage and tampering without changing the TLS protocol stack structure, thereby improving the security strength of information transmission. Attached Figure Description

[0035] Figure 1 This is a schematic diagram of the process of the present invention;

[0036] Figure 2 This document outlines the communication architecture and handshake flowchart for the quantum key distribution one-time pad protocol.

[0037] Figure 3 A schematic diagram illustrating the process of implementing quantum key one-time pad encryption for TLS record layer. Detailed Implementation

[0038] The technical solution of the present invention will now be described in detail through specific embodiments. Many specific details are set forth in the following description to provide a thorough understanding of the invention. However, the present invention can be implemented in many other ways different from those described herein, and those skilled in the art can make similar modifications without departing from the spirit of the invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0039] like Figures 1 to 3As shown, the method for fusing quantum key distribution in the TLS record layer proposed in this invention includes:

[0040] Step 1: The client and server execute the standard TLS handshake protocol to complete two-way authentication and negotiate cipher suite parameters, generate a unique session identifier, generate a classic key through the classic key exchange algorithm, and declare the quantum key enhancement mode in the handshake message extension field;

[0041] Step 2: After the handshake is completed, the client and server connect to the locally deployed quantum key manager through a secure channel, submit the unique session identifier for session binding, obtain the corresponding quantum key stream identifier, and exchange information of the quantum key stream identifiers of both parties to perform a one-pad encrypted transmission.

[0042] This embodiment, while fully preserving the original handshake negotiation mechanism of the TLS protocol, introduces the key stream generated by quantum key distribution (QKD) technology into the transport layer security system. By designing a layered key derivation architecture, a dual security mechanism is implemented at the record layer, combining quantum key-driven one-time pad encryption with quantum key-enhanced integrity protection. This scheme effectively prevents the risk of sensitive data leakage and tampering without changing the TLS protocol stack structure, thereby improving the security strength of information transmission.

[0043] In one embodiment, the client and server are each locally deployed with a directly connected key manager (KM) to store the quantum keys generated by the quantum key distribution device. The key manager uses the quantum key stream identifier as an index to associate and store the corresponding quantum key stream cache; and regularly updates and manages the quantum keys to assist the client and server in securely obtaining and responding to the quantum key stream.

[0044] The client and server register their sessions with their respective quantum key managers using a unique session identifier (SessionID). The quantum key manager initializes its quantum key stream cache using the unique session identifier and generates a quantum key stream identifier (QKSID). This QKSID is used to index the local quantum key manager to retrieve the relevant quantum key stream. The QKSID is a 128-bit UUID string, randomly generated by each local quantum key manager and exchanged for confirmation upon completion of the TLS handshake. The client and server each use the QKSID obtained from the other as their own decryption quantum key stream identifier.

[0045] The quantum key manager maintains the consistency of the bidirectional encryption and decryption quantum key stream cache through a periodic update synchronization mechanism. When the session ends, the KM automatically destroys the relevant key stream cache to ensure security.

[0046] It should be noted that the client declares the quantum key enhancement mode as quantum one-time pad in the extended field of the handshake message. If the server does not support quantum one-time pad, or if the quantum key manager connected to the server cannot provide a usable quantum key cache, both parties will fall back to the standard TLS encryption mode.

[0047] In one embodiment, during the data execution phase after the handshake is completed, when the client or the server, acting as the encryptor, performs a one-key encrypted transmission, the following steps are executed:

[0048] (a1) Obtain a fixed-length (e.g., 32 bytes) quantum key one from the local quantum key manager based on the unique session identifier. The classical key is used to derive an enhanced classical key through a pseudo-random function. The quantum key one, the enhanced classical key, and the hash function are used to derive an independent message authentication key one, QMAC1=HMAC(MAC_write_key, QKEY1, SHA-256), where HMAC is a hash-based message authentication code, MAC_write_key is the enhanced classical key, QKEY1 is the quantum key one, and SHA-256 is the hash function.

[0049] (a2) At the TLS record layer, the application layer plaintext is divided into multiple data segments P={P1,P2,…,Pi,…}, where Pi is the i-th data segment and the maximum length of the data segment is 16K bytes. The message authentication key is used to calculate the message authentication code MAC for each data segment and associated information. Each data segment is combined with the corresponding message authentication code to obtain the plaintext data group (Pi|MAC).

[0050] (a3) Obtain an encrypted quantum key stream QK={QK1,QK2,…, QKi, …} of the same length as each of the plaintext data groups, based on the quantum key stream identifier of the sender; QKi is the i-th encrypted quantum key stream.

[0051] It should be noted that the encrypted quantum key stream corresponds to the plaintext data group, that is, each plaintext data group corresponds to one encrypted quantum key stream. Since each plaintext data group includes a data segment, the encrypted quantum key stream and the plaintext data segment are in one-to-one correspondence, that is, the i-th encrypted quantum key stream QKi corresponds to the i-th data segment Pi.

[0052] In this process, the sender sends its own quantum key stream identifier to the local quantum key manager.

[0053] (a4) Perform XOR encryption on the plaintext data block (Pi|MAC) using the encrypted quantum key stream QKi to generate a ciphertext record block;

[0054] The associated information for plaintext data segments includes the sequence number, type, protocol version, and data segment length.

[0055] (a5) Add a TLS record header to the ciphertext record block to encapsulate it into a ciphertext data packet. The TLS record header includes type, protocol version and data segment length information.

[0056] According to steps (a1) to (a5), the advantage of this encryption process lies in its construction of dual quantum security guarantees for integrity and confidentiality within the standard TLS record layer framework. First, by deriving a hybrid message authentication key through the fusion of classical and quantum keys, robust protection against both classical and quantum computing attacks is provided for data integrity, avoiding the risk of a single key source. Crucially, by dynamically acquiring an equal-length quantum key stream for each data segment and performing a one-key XOR encryption, perfect information-theoretical security is achieved, fundamentally eliminating the risk of data breaches. Finally, the method of encapsulating the ciphertext in a standard TLS record header ensures seamless compatibility with existing TLS protocol stacks and network infrastructure, combining the highest level of security with practicality.

[0057] In one embodiment, when the client or the server performs a one-key encrypted transmission as the receiver, the following steps are executed:

[0058] (b1) After the TCP layer completes the packet reordering, the record layer protocol processes the data and extracts the TLS record header;

[0059] The encrypted data packets first pass through the TCP layer, which is responsible for ensuring the order and integrity of the data packets, forming a complete data stream that is then passed to the TLS record layer. The TLS record layer then decrypts the received encrypted data.

[0060] (b2) Obtain a fixed-length quantum key two from the local quantum key manager according to the quantum key stream identifier of the sender. The classical key is used to derive an enhanced classical key through a pseudo-random function. The quantum key two, the enhanced classical key, and the hash function are used to derive an independent message authentication key two, QMAC2=HMAC(MAC_write_key,QKEY2,SHA-256), where HMAC is a hash-based message authentication code, MAC_write_key is the enhanced classical key, QKEY2 is the quantum key two, and SHA-256 is the hash function.

[0061] (b3) Obtain a decryption quantum key stream of the same length as the ciphertext record block based on the sender's quantum key stream identifier;

[0062] (b4) Perform XOR decryption on the ciphertext record block using the decryption quantum key stream to obtain the plaintext data group (Pi|MAC);

[0063] (b5) Use message authentication key two to verify the integrity and sequence continuity of message authentication code one in the plaintext data group.

[0064] According to (b1) to (b5), the advantage of this receiver processing flow lies in providing a reliable and secure closed loop for data reception through a symmetric "decryption-verification" procedure. First, by employing the same key derivation method and keystream acquisition mechanism as the sender, precise synchronization of the encryption and decryption keys is ensured. The final integrity and sequence continuity verification step not only uses an authentication key that integrates quantum and classical keys to verify the authenticity of the data, but also effectively identifies any potential keystream synchronization failures. Furthermore, through a mandatory security policy that immediately terminates the connection, the reliability and security of the entire communication reception process are fundamentally guaranteed.

[0065] For step (b5), the specific steps are as follows:

[0066] (c1) The receiver uses message authentication key 2 QMAC2 to recalculate message authentication code 2 for multiple data segments and associated information of plaintext P;

[0067] (c2) Compare the message authentication code 2 with the message authentication code 1 in the plaintext data group obtained by decryption using the decryption quantum key stream. If they match, the application layer plaintext is obtained. If they do not match, the quantum key stream sequence synchronization fails or the data is tampered with, and the client and server terminate the TLS connection.

[0068] The following specific embodiments, in conjunction with the appendix, demonstrate this process. Figure 2 and 3 The method of integrating quantum key one-time pad into the TLS record layer protocol proposed in this embodiment will be described in detail.

[0069] like Figure 2 As shown, quantum key manager A is connected to QKD device A, and quantum key manager B is connected to QKD device B. The QKD devices distribute quantum keys to each other using a quantum key distribution protocol such as BB84. Each quantum key manager stores the quantum keys generated by its respective QKD device in its local key pool. The client is directly connected to quantum key manager A, and the server is directly connected to quantum key manager B. The client and server communicate via a common channel, and quantum key managers A and B also synchronize keys via a common channel. Quantum key managers A and B periodically update and manage the quantum keys, and assist the client and server in securely obtaining and responding to quantum key streams through a local secure channel.

[0070] The client and server first establish a TCP connection, complete a three-way handshake, and then begin the TLS handshake process. The client and server execute the standard TLS handshake protocol, complete mutual authentication, negotiate cipher suite parameters, generate a unique session identifier (SessionID), generate a classical key using a classical key exchange algorithm, and declare the quantum key enhancement mode in the handshake message extension field.

[0071] The client sends a Client Hello message, which includes a random number and a list of cipher suites supported by the client. In the "cipher_suites" extension of the supported cipher suite list, the quantum key enhancement mode is declared as "TLS_QKD_WITH_OTP_SHA256", which means that the quantum key stream distributed by quantum key distribution is used for one-time pad and SHA256HMAC is used as the message authentication algorithm.

[0072] If the server does not support one-time pad encryption using quantum key distribution's quantum key stream, or if the quantum key manager B has insufficient available quantum key cache, the server selects a classic cipher suite mode, such as "TLS_DH_DSS_WITH_AES_128_CBC_SHA256", and subsequently uses the classic key in conjunction with AES128CBC mode for encryption to ensure backward compatibility of the protocol. If the server supports one-time pad encryption using quantum key distribution's quantum key stream, this is confirmed in the ServerHello message.

[0073] The server sends a Server Hello message, which includes a random number, a server-generated unique session identifier (SessionID) to identify the current session, supported cipher suites, and the server certificate, key exchange parameters, and client certificate request.

[0074] The client sends its client certificate, key exchange parameters, and certificate verification result; then both parties exchange Finished messages. This completes certificate-based authentication and generates a unique session identifier (SessionID). A classic key, `master_secret`, is generated using the Diffie-Hellman key exchange algorithm. From this, enhanced classic keys required for encryption and message authentication codes, such as `client_write_key`, `server_write_key`, `client_write_MAC_key`, and `server_write_MAC_key`, are derived. Both parties agree to use a quantum key stream distributed via quantum key distribution for one-time pad encryption and SHA256HMAC as the message authentication algorithm. The Diffie-Hellman key exchange algorithm is an asymmetric encryption protocol for securely negotiating and sharing keys over an insecure channel, and SHA256HMAC is an encrypted signature method combining the SHA-256 hash algorithm and HMAC (Hyperkey Message Authentication Code).

[0075] After the TLS handshake is completed, the client and server connect to the locally deployed quantum key manager through a secure channel. The client and server register their sessions with their respective quantum key managers using a unique session identifier (SessionID). The quantum key manager initializes a quantum key stream cache using the SessionID and generates a 128-bit UUID character as the quantum key stream identifier (QKSID). Each SessionID is bound to a QKSID, which is used by the quantum key manager to distinguish requests from different TLS sessions. The client and server use this QKSID to index the local quantum key manager to obtain the relevant quantum key stream.

[0076] The quantum key manager maintains its own key database, using the quantum key stream identifier (QKSID) as an index to associate and store the corresponding quantum key stream cache. The quantum key stream identifier (QKSID) actively generated by the quantum key manager serves as the quantum key stream identifier for the encryption direction. For example, if quantum key manager A actively generates QKSID1, when the quantum key manager creates an encryption direction key stream, it will notify the decryption direction quantum key manager to create a quantum key stream with the same decryption direction identifier (QKSID1). The quantum key managers of both the client and server maintain the consistency of the bidirectional encryption and decryption quantum key stream cache through a periodic update synchronization mechanism. When the session ends, KM automatically destroys the relevant key stream cache to ensure security.

[0077] The client obtains its corresponding quantum key stream identifier QKSID1 from quantum key manager A, and the server obtains its corresponding quantum key stream identifier QKSID2 from quantum key manager B. They then exchange their QKSID information. In subsequent communications, the client uses its own QKSID1 as the encryption quantum key stream identifier and the server's QKSID2 as the decryption quantum key stream identifier; similarly, the server uses its own QKSID2 for encryption and the client's QKSID1 for decryption. The two parties then begin a one-pad secure communication using quantum keys.

[0078] Taking the client as an example, as the encryptor (i.e., the sender), the client divides the transmitted plaintext data into multiple data segments through the record layer protocol, calculates the message authentication code MAC1 for each data segment using the message authentication key QMAC1, and obtains an encrypted quantum key stream of the same length (Len) as the data segment plus MAC1 from the local quantum key manager through the quantum key stream identifier QKSID1. The client then uses the obtained encrypted quantum key stream to encrypt the data segment and MAC1 in a one-time pad mode to generate a ciphertext record block. Finally, the client adds a TLS record header to the ciphertext record block and encapsulates it into a ciphertext data packet.

[0079] Taking the server as an example, after the decryptor (i.e., the receiver) receives the ciphertext data packet, the TCP protocol is responsible for sorting the data packet and handling packet loss retransmission. When the data packet arrives and is arranged in the correct order, it is processed by the record layer protocol. The decryption quantum key stream of the corresponding length Len is obtained through the same quantum key stream identifier QKSID1. The message authentication code MAC2 is recalculated on the plaintext data segment and its associated information using the message authentication key QMAC2. Then, the recalculated MAC2 is compared with the decrypted MAC1. If the two are the same, the application layer plaintext is obtained; if they are different, it is considered that the quantum key stream sequence synchronization has failed or the data has been tampered with, and both parties terminate the TLS connection.

[0080] Figure 3 This is a schematic diagram illustrating the data encryption process of the TLS record layer implementing quantum key one-time pad encryption in this embodiment. Figure 3As shown, when the encrypting party transmits data, it first initiates a quantum key acquisition request to the quantum key manager. Using QKSID1 as the index for the relevant quantum key stream cache, it first acquires the 32-byte quantum key QKEY. This QKEY is then combined with the classical key and the enhanced classical key MAC_write_key derived from the PRF (pseudo-random function) to perform HMAC (Hash-based message authentication code), generating the quantum key-enhanced message authentication key, as shown in the formula: QMAC1 = HMAC(MAC_write_key, QKEY1, SHA-256). QKEY1 is the quantum key, and its length depends on the hash algorithm used. For example, SHA256 requires a 32-byte quantum key input, so the length of the quantum key is 32 bytes.

[0081] Then, the TLS record layer processes the plaintext from the application layer, dividing the plaintext data into multiple data segments Pi, each with a maximum length of no more than 16k. The message authentication key QMAC1 is used to calculate the message authentication code MAC1_i for each data segment Pi, calculated as follows: MAC1_i = MAC(QMAC, seq + type + version + length + fragment). Here, MAC is the MAC algorithm specified during the TLS cipher suite negotiation phase, such as SHA256HMAC; "+" indicates a data connection; Seq represents the sequence number; type represents the data type; version represents the TLS protocol version; length represents the data segment length; and fragment is the plaintext data segment itself.

[0082] After calculating the MAC1 value, it is then encrypted using an encryption algorithm. The encryptor obtains the encrypted quantum key stream QKi of length L in sequence using the quantum key stream identifier QKSID based on the length L of the data segment Pi + MAC1_i. Then, it performs a one-key XOR encryption on the data combination (Pi|MAC1_i) to generate the ciphertext record block C_i. The mode of calculating MAC1 first and then encrypting is adopted.

[0083] Finally, the encryptor adds a TLS record header to the ciphertext record block C_i to encapsulate it into a ciphertext data packet. The TLS record header includes information such as type, protocol version, and data segment length. The ciphertext data packet is then encapsulated into a TLS record message and transmitted by the underlying TCP protocol.

[0084] Since the encryptor obtains the quantum key in a certain order and length each time, after reliable data transmission via the TCP protocol, the TLS record messages arrive at the decryptor in the correct order. The decryptor requests the quantum key of the same length in the same order as the encryptor, which can ensure the consistency of the key streams between the encryption and decryption parties and reduce the overhead of quantum key synchronization.

[0085] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A method for integrating quantum key distribution in the TLS record layer, characterized in that, include: The client and server execute the standard TLS handshake protocol, complete two-way authentication and negotiate cipher suite parameters, generate a unique session identifier, generate a classic key through the classic key exchange algorithm, and declare the quantum key enhancement mode in the handshake message extension field; After the handshake is completed, the client and server connect to the locally deployed quantum key manager through a secure channel, submit the unique session identifier for session binding, obtain the corresponding quantum key stream identifier, and exchange information of the quantum key stream identifiers of both parties to perform a one-pad encrypted transmission. When the client or the server performs a one-key encrypted transmission as the encryptor, the following steps are executed: A fixed-length quantum key is obtained from the local quantum key manager based on the unique session identifier. The classical key is used to derive an enhanced classical key through a pseudo-random function. An independent message authentication key is then derived using the quantum key, the enhanced classical key, and a hash function. At the TLS record layer, the application layer plaintext is divided into multiple data segments. The message authentication key is used to calculate message authentication code one for each data segment and associated information. Each data segment is combined with the corresponding message authentication code one to obtain a plaintext data group. Obtain an encrypted quantum key stream of equal length to each of the data groups based on the sender's quantum key stream identifier; The plaintext data group is XORed using the encrypted quantum key stream to generate a ciphertext record block; A TLS header is added to the ciphertext record block to encapsulate it into a ciphertext data packet. The TLS header includes information on type, protocol version, and data segment length.

2. The method according to claim 1, characterized in that, The step of obtaining an encrypted quantum key stream of equal length to each data group based on the sender's quantum key stream identifier specifically involves: The sender sends a quantum key request to the local quantum key manager through a quantum key stream identifier to obtain an encrypted quantum key stream cache. The key request information includes: the quantum key stream identifier and the requested quantum key length.

3. The method according to claim 1, characterized in that, In the process of calculating a message authentication code for each data segment and associated information using the message authentication key pair, the associated information includes: sequence number, type, protocol version, and data segment length.

4. The method according to claim 1, characterized in that, During the data execution phase after the handshake is completed, when the client or the server, as the receiver, performs a one-key encrypted transmission, the following steps are executed: After the TCP layer completes the reassembly and sorting of the ciphertext data packets, the record layer protocol processes the data and extracts the TLS record header. A fixed-length quantum key two is obtained from the local quantum key manager based on the quantum key stream identifier of the sender. The classical key is used to derive an enhanced classical key through a pseudo-random function. An independent message authentication key two is then derived using quantum key two, the enhanced classical key, and a hash function. Obtain the decryption quantum key stream of the same length as the ciphertext record block based on the sender's quantum key stream identifier; The ciphertext record block is XORed and decrypted using the decryption quantum key stream to obtain the plaintext data group; Use message authentication key two to verify the integrity and sequence continuity of message authentication code one in the plaintext data group.

5. The method according to claim 4, characterized in that, The step of using message authentication key two to verify the integrity and sequence continuity of message authentication code one in the plaintext data group specifically involves: The receiver uses message authentication key two to recalculate message authentication code two for multiple data segments of the plaintext and associated information; The message authentication code 2 is compared with the message authentication code 1 in the plaintext data group obtained by decryption using the decryption quantum key stream. If they match, the application layer plaintext is obtained. If they do not match, the quantum key stream sequence synchronization fails or the data is tampered with, and the client and server terminate the TLS connection.

6. The method according to claim 1, characterized in that, The client and server are each locally deployed with a directly connected quantum key manager to store the quantum keys generated by the quantum key distribution device. The quantum key manager uses the quantum key stream identifier as an index to associate and store the corresponding quantum key stream cache.

7. The method according to claim 1, characterized in that, The client declares quantum key enhancement mode as quantum one-time pad in the extended field of the handshake message. If the server does not support quantum one-time pad, or if the quantum key manager connected to the server cannot provide a usable quantum key cache, both parties fall back to the standard TLS encryption mode.

8. The method according to claim 1, characterized in that, The client and server connect to the locally deployed quantum key manager through a secure channel, submit the unique session identifier for session binding, and obtain the corresponding quantum key stream identifier, specifically: The client and server use the unique session identifier to register a session with their respective connected quantum key managers; The quantum key manager initializes the quantum key stream cache using the unique session identifier and generates a quantum key stream identifier; The local quantum key manager is indexed using the quantum key stream identifier to obtain the corresponding quantum key stream.

9. A computer system comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the method as described in any one of claims 1-8.

Images