A data protection method integrating quantum keys into TLS

Abstract

This invention discloses a data protection method that integrates quantum keys into TLS, relating to the field of quantum secure communication technology. This method uses quantum keys in combination with pre-shared keys for identity authentication and continuously updates the pre-shared key database. This method addresses the vulnerability of existing public key authentication systems to quantum computing attacks and the reduced security caused by the reuse of pre-shared keys. Furthermore, this method uses a preset key generation algorithm to use quantum keys as key material to generate session keys for communication, avoiding the use of insecure traditional key exchange algorithms and enhancing data transmission security.

Description

Technical Field

[0001] The present invention belongs to the technical field of quantum secure communication, and in particular relates to a data protection method integrating quantum keys in TLS. Background Art

[0002] The traditional Transport Layer Security (TLS) protocol establishes a handshake between the client and server, using asymmetric cryptographic algorithms such as public key certificates for identity authentication and Elliptic Curve Diffie–Hellman (ECDH) key exchange to generate session keys. With the development of quantum computing technology, quantum computers combined with quantum algorithms can easily crack the asymmetric cryptographic algorithms used in traditional TLS protocols, threatening the security of TLS.

[0003] Quantum Key Distribution (QKD) technology, based on the principles of quantum mechanics, enables communicating parties to share a secure, random key stream. The keys generated by the QKD process are theoretically unconditionally secure. Therefore, how to enhance the security of the TLS protocol using quantum keys remains an unresolved issue.

[0004] Existing technical solutions primarily focus on using quantum keys to replace insecure key exchange algorithms and how to generate session keys. They fail to consider the insecurity of public key certificates and pay relatively little attention to enhancing identity authentication. Furthermore, the relatively new TLS v1.3 version has not been enhanced to incorporate the QKD protocol. Compared to older versions, the latest TLS v1.3 boasts lower handshake latency, higher forward security, and more secure and efficient encryption algorithms. However, identity authentication and key exchange also utilize insecure asymmetric cryptographic algorithms. Simply replacing traditional key exchange with quantum keys is susceptible to key exhaustion attacks by unauthorized users. Therefore, to maintain the original protocol architecture and improve security, it is necessary to design a TLS protocol that integrates quantum keys for identity authentication and key exchange without compromising the existing TLS v1.3 protocol. Summary of the Invention

[0005] To address the above technical issues, the present invention provides a data protection method that integrates quantum keys into TLS. Using quantum keys in combination with pre-shared keys for identity authentication and continuously updating the pre-shared key database solves the existing problems of public key identity authentication systems being vulnerable to quantum computing attacks and the reduced security caused by the reuse of pre-shared keys. Furthermore, this method uses a preset key generation algorithm to use quantum keys as key material to generate session keys for communication, avoiding the use of insecure traditional key exchange algorithms and enhancing data transmission security.

[0006] To achieve the above object, the present invention adopts the following technical solutions:

[0007] A data protection method integrating quantum keys in TLS, comprising:

[0008] S110: After the TCP handshake, the client and the server perform a TLS handshake process. The client initiates a quantum key acquisition request to the first quantum key management device, and the first quantum key management device returns a first quantum key and a corresponding first quantum key identifier to the client.

[0009] S120: The client sends a Client Hello message and performs a handshake using a pre-shared key. The Client Hello message includes a list of supported encryption suites, a first quantum key identifier, an exchange mode extension, and a pre-shared key extension.

[0010] S130: The server receives the Client Hello message, uses the corresponding pre-shared key to complete the identity authentication of the client, and uses the obtained first quantum key identifier to initiate a quantum key retrieval request to the second quantum key management device. The second quantum key management device returns the first quantum key corresponding to the retrieval request to the server;

[0011] S140: The server sends a Server Hello message, which includes the selected encryption suite and pre-shared key identifier. The server uses the pre-shared key and the first quantum key to derive a key according to a predefined key generation algorithm, and sends a Finished message, indicating that the handshake phase of the server is complete.

[0012] S150: The client determines a pre-shared key according to the pre-shared key identifier selected by the server, jointly uses the pre-shared key and the first quantum key to derive a key according to a predefined key generation algorithm, and sends a Finished message, indicating that the handshake phase of the client is over;

[0013] S160: After the handshake phase is completed, the server verifies the Finished message sent by the client, obtains the second quantum key from the second quantum key management device to update the local pre-shared key database, and sends a NewSessionTicket message to the client. The client synchronously updates the local pre-shared key database.

[0014] The beneficial effects of the present invention are:

[0015] The present invention uses quantum keys in combination with pre-shared keys for identity authentication and continuously updates the pre-shared key database, solving the problem in existing methods that public key identity authentication is vulnerable to quantum computing attacks and the problem of reduced security caused by the reuse of pre-shared keys; at the same time, the method uses quantum keys as key materials to generate session keys used in the communication process through a preset key generation algorithm, avoiding the use of insecure traditional key exchange algorithms and enhancing the security of data transmission; finally, the method maintains compatibility with traditional TLS protocols and only requires minor modifications for rapid deployment and promotion. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 This is a flow chart of a data protection method for integrating quantum keys into TLS according to the present invention;

[0017] Figure 2 A schematic diagram of the TLS protocol communication architecture and handshake flow chart integrating quantum keys according to the present invention;

[0018] Figure 3 Schematic diagram of updating the pre-shared key database according to the present invention. DETAILED DESCRIPTION

[0019] In order to make the objectives, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with specific embodiments and with reference to the accompanying drawings.

[0020] like Figure 1 As shown, this is a flow chart of a data protection method for integrating quantum keys in TLS according to the present invention, including operations S110 to S160.

[0021] In operation S110, after the TCP handshake, the client and the server perform a TLS handshake process, wherein the client initiates a quantum key acquisition request to the first quantum key management device, and the first quantum key management device returns a first quantum key and a corresponding first quantum key identifier to the client;

[0022] According to an embodiment of the present invention, the first quantum key management device is directly connected to the client and stores the quantum key generated by the quantum key distribution device in a local key pool of the first quantum key management device;

[0023] The second quantum key management device is directly connected to the server and stores the quantum key generated by the quantum key distribution device in a local key pool of the second quantum key management device;

[0024] The first quantum key management device and the second quantum key management device assign quantum key identifiers to the stored quantum keys according to a predefined format, manage the stored quantum keys, and supply the stored quantum keys to the client or server.

[0025] In operation S120, the client sends a Client Hello message to perform a handshake using a pre-shared key. The Client Hello message includes a list of supported encryption suites, a first quantum key identifier, an exchange mode extension, and a pre-shared key extension.

[0026] The encryption suite list supported by the client is stored in the "cipher_suites" extension, including the authenticated encryption algorithm and hash encryption suite with associated data supported by the client; the first quantum key identifier is stored in the "key_share" extension; the exchange mode extension is the "psk_key_exchange_modes" extension, indicating that the exchange mode is "psk_qke_ke", indicating that the pre-shared key and quantum key are used for key exchange at the same time; the pre-shared key extension is the "pre_shared_key" extension, which is used to negotiate the pre-shared key identifier, including a list of pre-shared key identifiers, and a binding value calculated for each pre-shared key using a hash-based message authentication code on the current message copy, which corresponds one-to-one to each identifier in the pre-shared key identifier list and is in the same order, and is used to bind the pre-shared key to the current handshake;

[0027] The pre-shared key is configured in advance by the client and server. Both parties can select a fixed-length quantum key as the pre-shared key to enhance key strength. When configuring the pre-shared key, a unified pre-shared key identifier is also configured, and the expiration time of the pre-shared key is indicated. The default expiration time is one week. When the client and server perform a TLS handshake, they cannot use a pre-shared key whose current handshake time is greater than the indicated expiration time.

[0028] When a pre-shared key is established, a hash algorithm must be set to calculate the binding value of the pre-shared key. The default hash algorithm is SHA-256.

[0029] Among them, both parties configure a certain number of pre-shared keys and corresponding pre-shared key identifiers in advance to form a local pre-shared key database, which includes a pre-shared key list and a corresponding pre-shared key identifier list. Only the corresponding pre-shared key identifier list needs to be provided in the pre-shared key extension item.

[0030] In operation S130, the server receives the Client Hello message, uses the pre-shared key to complete the identity authentication of the client, and uses the obtained first quantum key identifier to initiate a quantum key retrieval request to the second quantum key management device. The second quantum key management device returns the first quantum key corresponding to the retrieval request to the server.

[0031] The server selects a pre-shared key identifier supported by the local pre-shared key database from the pre-shared key identifier list in the Client Hello message, and uses the corresponding pre-shared key and a hash-based message authentication code to calculate a binding value for the current message copy. If the binding value is consistent with the binding value provided by the client, it verifies that both parties hold the same pre-shared key, completing the identity authentication of the client. Otherwise, the client's identity cannot be verified, and the server sends an "Invalid PSK" alert and terminates the TLS connection. Only after successfully authenticating the legitimate identity of the client can the server retrieve the quantum key from the second quantum key management device, preventing illegal users from continuously requesting the server to retrieve the quantum key, which could cause the server's key resources to be exhausted.

[0032] In operation S140, the server sends a Server Hello message, which includes the selected encryption suite and the identifier of the selected pre-shared key. The server uses the pre-shared key and the first quantum key to derive a key according to a predefined key generation algorithm, and sends a Finished message, indicating that the handshake phase of the server is complete.

[0033] The server selects a cipher suite from the cipher_suites list in the Client Hello message and sends a "pre_shared_key" extension containing the identifier of the server's selected pre-shared key.

[0034] Among them, the predefined key generation algorithm is the HMAC-based Key Derivation Function (HKDF) based on the hash operation message authentication code; the above-mentioned server uses the above-mentioned pre-shared key and the above-mentioned first quantum key as key material, and uses HKDF to calculate the handshake key and the session key. After that, the messages in the handshake phase are protected by the handshake key, and the messages in the session communication phase are protected by the session key. The handshake key is used to perform HMAC signature on all the above-mentioned handshake information to generate a Finished message.

[0035] In operation S150, the client determines a pre-shared key according to the pre-shared key identifier selected by the server, jointly uses the pre-shared key and the first quantum key to perform key derivation according to a predefined key generation algorithm, and sends a Finished message to indicate that the handshake phase of the client is completed;

[0036] The client verifies whether the identifier of the pre-shared key selected by the server is within its supported range. If not, the handshake process is aborted. The client uses the pre-shared key and the first quantum key as key material, calculates the handshake key and session key using HKDF, and uses the handshake key to verify the correctness of the content of the server's Finished message. If incorrect, indicating that the keys negotiated by the client and server are inconsistent, the client issues a "decryption failed" alert and terminates the TLS connection. If verification succeeds, the client uses the handshake key to perform an HMAC signature on all the handshake information, generating a Finished message.

[0037] In operation S160, after the handshake is completed, the server verifies the Finished message sent by the client, obtains the second quantum key from the second quantum key management device to update the local pre-shared key database, and sends a NewSessionTicket message to the client, and the client synchronously updates the local pre-shared key database.

[0038] After the handshake phase is completed, the server verifies the Finished message, triggers the pre-shared key update operation, and initiates a quantum key acquisition request to the second quantum key management device. The second quantum key management device returns the second quantum key and the corresponding second quantum key identifier to the server. The server stores the second quantum key and the second quantum key identifier in the local pre-shared key database and sets the expiration time of the second quantum key. The default expiration time is one day. The server puts the second quantum key identifier and the corresponding expiration time into the NewSessionTicket message and sends it to the client.

[0039] The client uses the obtained second quantum key identifier to initiate a quantum key retrieval request to the first quantum key management device. The first quantum key management device returns the corresponding second quantum key to the client. The client stores the second quantum key, the second quantum key identifier, and the expiration time of the second quantum key in a local pre-shared key database.

[0040] like Figure 2 Figure 2 shows a schematic diagram of the TLS protocol communication architecture and handshake flow chart for integrating quantum keys according to the present invention. A first quantum key manager is connected to QKD device A, and a second quantum key manager is connected to QKD device B. The QKD devices use the quantum key distribution protocol. The quantum key manager stores the quantum keys generated by the QKD devices in a key pool. The client is directly connected to the first quantum key manager, and the server is directly connected to the second quantum key manager. The client and server communicate over a public channel.

[0041] The client and server first establish a TCP connection, complete a three-way handshake, and then begin the TLS handshake process. The client uses quantum keys to enhance the security of the handshake process. It first initiates a quantum key acquisition request to the first quantum key management device, which returns the first quantum key QKEY_1 and the corresponding first quantum key identifier QKEYID_1 to the client. The default quantum key length is 64 bytes, and the key identifier is 32 bytes.

[0042] Afterwards, the client sends a Client Hello message. In the exchange mode extension, i.e., the "psk_key_exchange_modes" extension, it indicates that the exchange mode is "psk_qke_ke", indicating that both pre-shared keys and quantum keys are used for key exchange and pre-shared keys are used for handshake. This mode is a new mode added by the present invention. The standard protocol only contains "psk_ke" and "psk_dhe_ke", indicating that only PSK keys or PSK and (EC)DHE are used for handshake. The client stores the list of supported encryption suites in the "cipher_suites" extension, including the authenticated encryption algorithms and hash encryption suites with associated data supported by the client, such as "TLS_AES_256_GCM_SHA384". At the same time, the client stores the first quantum key identifier QKEYID_1 in the "key_share" extension.

[0043] The client includes the pre-shared key extension (pre_shared_key) in the PSKid_LIST list of local, unexpired pre-shared keys, along with a binding value calculated using a hash-based message authentication code (SHA256-HMAC) on the current message copy. Each binding value corresponds to each identifier in the PSKid_LIST and is in the same order as the pre-shared key.

[0044] The above-mentioned pre-shared key is configured in advance by the client and server. Both parties select a 32-byte quantum key as the pre-shared key in advance and use the corresponding quantum key identifier as the pre-shared key identifier; both parties configure N pre-shared keys (N>1) and corresponding pre-shared key identifiers to form a local pre-shared key database.

[0045] The server selects a pre-shared key identifier supported by the local pre-shared key database from the pre-shared key identifier list PSKid_LIST in the Client Hello message, such as PSKid_1, and uses the corresponding pre-shared key PSK_1 and a message authentication code based on a hash operation, using SHA256-HMAC by default, to calculate a binding value for the current message copy. If the binding value is consistent with the binding value provided by the client, it verifies that both parties hold the same pre-shared key, completing the identity authentication of the client. The server then retrieves the quantum key from the second quantum key management device, including the quantum key identifier QKEYID_1 to be retrieved. The second quantum key management device then returns the corresponding first quantum key QKEY_1 to the server.

[0046] The server then sends a Server Hello message containing the selected cipher suite, such as "TLS_AES_256_GCM_SHA384," and the identifier of the selected pre-shared key, QKEYID_1. The server uses the pre-shared key, PSK_1, and the first quantum key, QKEY_1, as key material, and employs the key derivation function, HKDF, based on a hash-based message authentication code, to calculate the handshake key and session key. Subsequently, messages in the handshake phase are protected by the handshake key, and messages in the session communication phase are protected by the session key. The handshake key is used to perform an HMAC signature on all of the above handshake information, generating a Finished message.

[0047] The client then verifies whether the identifier of the pre-shared key selected by the server is within its supported range. If not, the handshake process is terminated. The client determines the pre-shared key PSK_1 based on the pre-shared key identifier PSKid_1 selected by the server, uses the pre-shared key PSK_1 and the first quantum key QKEY_1 as key material, and uses the key derivation function HKDF based on the hash operation message authentication code to calculate the handshake key and session key. The handshake key is used to perform an HMAC signature on all the above handshake information, generating a Finished message, indicating that the client's handshake phase has ended and the TLS session communication has officially begun.

[0048] like Figure 3 As shown in the figure, it is a schematic diagram of updating the pre-shared key database in an embodiment of the present invention. After the Finished message is sent, in the complete handshake process, after the Server receives the Finished message from the Client and completes the verification, it immediately triggers the pre-shared key update operation and initiates a quantum key acquisition request to the second quantum key management device. The second quantum key management device returns the second quantum key QKEY_2 and the corresponding second quantum key identifier QKEYID_2 to the above-mentioned server. The server sets the expiration time Life_time of QKEYID_2 to 24 hours. The server adds the above-mentioned second quantum key QKEY_2 and the second quantum key identifier QKEYID_2 to the local pre-shared key database B. The server puts the above-mentioned second quantum key identifier QKEYID_2 and the corresponding expiration time Life_time into the NewSessionTicket message and sends it to the client.

[0049] The client uses the obtained second quantum key identifier QKEYID_2 to initiate a quantum key retrieval request to the first quantum key management device. The first quantum key management device returns the corresponding second quantum key QKEY_2 to the client. The client adds the second quantum key, the second quantum key identifier and the corresponding expiration time Life_time to the local pre-shared key database A.

[0050] This invention discloses a data protection method that integrates quantum keys into TLS. This method uses quantum keys in combination with pre-shared keys for identity authentication and continuously updates the pre-shared key database. This addresses the vulnerability of public key authentication to quantum computing attacks and the reduced security caused by the reuse of pre-shared keys in existing methods. Furthermore, the method uses quantum keys as key material to generate session keys for communication through a preset key generation algorithm, avoiding the use of insecure traditional key exchange algorithms and enhancing the security of data transmission. Finally, this method maintains compatibility with traditional TLS protocols and requires only minor modifications for rapid deployment and promotion.

[0051] The specific embodiments described above further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above are only specific embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A data protection method integrating quantum keys in TLS, characterized in that: include: S110: After the TCP handshake, the client and the server perform a TLS handshake process. The client initiates a quantum key acquisition request to the first quantum key management device, and the first quantum key management device returns a first quantum key and a corresponding first quantum key identifier to the client. S120: The client sends a Client Hello message and uses a pre-shared key for handshake. The Client Hello message includes a list of supported encryption suites, a first quantum key identifier, an exchange mode extension, and a pre-shared key extension. The list of supported encryption suites includes the authenticated encryption algorithm and hash encryption algorithm suite supported by the client. The exchange mode extension indicates that the key exchange mode is "psk_qke_ke", indicating that both the pre-shared key and the quantum key are used for key exchange. The pre-shared key extension provides a list of pre-shared key identifiers and a binding value calculated for each pre-shared key for the current message copy. S130: The server receives the Client Hello message, uses the corresponding pre-shared key to complete the identity authentication of the client, and uses the obtained first quantum key identifier to initiate a quantum key retrieval request to the second quantum key management device. The second quantum key management device returns the first quantum key corresponding to the retrieval request to the server; S140: The server sends a Server Hello message, which includes the selected encryption suite and pre-shared key identifier. The server uses the pre-shared key and the first quantum key to derive a key according to a predefined key generation algorithm, and sends a Finished message, indicating that the handshake phase of the server is complete. S150: The client determines a pre-shared key according to the pre-shared key identifier selected by the server, jointly uses the pre-shared key and the first quantum key to derive a key according to a predefined key generation algorithm, and sends a Finished message, indicating that the handshake phase of the client is over; S160: After the handshake phase is completed, the server verifies the Finished message sent by the client, obtains the second quantum key from the second quantum key management device to update the local pre-shared key database, and sends a NewSessionTicket message to the client. The client synchronously updates the local pre-shared key database.

2. A data protection method for integrating quantum keys in TLS according to claim 1, characterized in that: The first quantum key management device is directly connected to the client and stores the quantum key generated by the quantum key distribution device in the local key pool of the first quantum key management device; the second quantum key management device is directly connected to the server and stores the quantum key generated by the quantum key distribution device in the local key pool of the second quantum key management device; The first quantum key management device and the second quantum key management device assign a quantum key identifier to the stored quantum key according to a predefined format, manage the stored quantum key, and supply the stored quantum key to the client or server.

3. A data protection method for integrating quantum keys in TLS according to claim 1, characterized in that: In S120, the pre-shared key is configured in advance by the client and the server. Both parties select a fixed-length quantum key as the pre-shared key in advance. When configuring the pre-shared key, a unified pre-shared key identifier is configured and the expiration time of the pre-shared key is indicated. When the client and the server perform a TLS handshake, they cannot use a pre-shared key whose current handshake time is greater than the indicated expiration time.

4. A data protection method for integrating quantum keys in TLS according to claim 1, characterized in that: In S130, the server selects a pre-shared key identifier supported by the server's local pre-shared key database from the pre-shared key identifier list in the Client Hello message, calculates a binding value for the current message copy using the corresponding pre-shared key, and if the binding value is consistent with the binding value provided by the client, verifies that both parties hold the same pre-shared key, thereby completing the identity authentication of the client. Otherwise, the client identity cannot be verified, and the server sends a PSK invalid alert and terminates the TLS connection; After successfully authenticating the legal identity of the client, the server sends a quantum key retrieval request to the second quantum key management device, and the second quantum key management device returns the first quantum key corresponding to the retrieval request to the server.

5. A data protection method for integrating quantum keys in TLS according to claim 1, characterized in that: In S140, the server selects a supported encryption suite from the list of supported encryption suites in the Client Hello message, and uses the pre-shared key and the first quantum key as key materials, and uses a predefined key generation algorithm to calculate a handshake key and a session key. The handshake key is used to protect messages in the handshake phase, and the session key is used to protect messages in the session communication phase. The handshake key is used to sign all handshake information to generate a Finished message.

6. A data protection method for integrating quantum keys in TLS according to claim 1, characterized in that: In S150, the client uses the pre-shared key and the first quantum key as key materials, uses a predefined key generation algorithm to calculate a handshake key and a session key, and then uses the handshake key to calculate a verification value to verify whether the content of the Finished message sent by the server is correct. If the verification result is incorrect, the client sends a verification failure alert and terminates the TLS connection.

7. A data protection method for integrating quantum keys in TLS according to claim 1, characterized in that: In S160, after the handshake phase is completed, the server verifies the Finished message sent by the client. If the verification result is correct, a pre-shared key update operation is triggered, and a quantum key acquisition request is initiated to the second quantum key management device. The second quantum key management device returns the second quantum key and the corresponding second quantum key identifier to the server. The server stores the second quantum key and the second quantum key identifier in the server's local pre-shared key database and adds the expiration time of the second quantum key. The server puts the second quantum key identifier and the corresponding expiration time into a NewSessionTicket message and sends it to the client. The client uses the obtained second quantum key identifier to initiate a quantum key retrieval request to the first quantum key management device. The first quantum key management device returns the corresponding second quantum key to the client. The client stores the second quantum key, the second quantum key identifier, and the expiration time of the second quantum key in the client's local pre-shared key database. If the verification result is incorrect, the server sends a verification failure alert and terminates the TLS connection.

Images