Data protection method fusing quantum key in TLS

Abstract

The invention discloses a data protection method for fusing a quantum key in a TLS, and relates to the technical field of quantum secret communication. According to the method, a quantum key is combined with a pre-shared key to perform identity authentication, and a pre-shared key database is continuously updated, so that the problem that a public key identity authentication system is easily attacked by quantum computing and the problem that the security is reduced due to repeated use of the pre-shared key in the existing method are solved; meanwhile, according to the method, a session key used in the communication process is generated by taking the quantum key as a key material through a preset key generation algorithm, so that the use of an unsafe traditional key exchange algorithm is avoided, and the security of data transmission is enhanced.

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 the server, and uses 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, thus threatening the security of TLS protocols.

[0003] Quantum Key Distribution (QKD) technology is based on the principles of quantum mechanics, which enables both parties in communication 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 through quantum keys is an unsolved problem.

[0004] In the existing technical solutions, the main focus is on how to use quantum keys to replace insecure key exchange algorithms and how to generate session keys. The insecurity of public key certificates is not considered, and there is less attention paid to identity authentication enhancement. In addition, the newer TLS v1.3 version has not been enhanced by integrating the QKD protocol. Compared with the old version, the latest TLS v1.3 version has the advantages of lower handshake latency, higher forward security, and the use of more secure and efficient encryption algorithms. However, identity authentication and key exchange also use insecure asymmetric cryptographic algorithms. If quantum keys are simply used instead of traditional key exchanges, they are prone to key exhaustion attacks by illegal users. Therefore, in order to maintain the architecture of the original protocol and improve security, it is necessary to design a TLS protocol that integrates quantum keys for identity authentication and key exchange without affecting the existing TLS v1.3 protocol. Summary of the invention

[0005] In order to solve the above technical problems, the present invention provides a data protection method that integrates quantum keys in TLS. Using quantum keys in combination with pre-shared keys for identity authentication and continuously updating the pre-shared key database solves the problem that the public key identity authentication system in the existing method 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 the quantum key as the key material to generate the session key used in the communication process through a preset key generation algorithm, avoiding the use of unsafe traditional key exchange algorithms and enhancing the security of data transmission.

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

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

[0008] 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;

[0009] S120: The client sends a Client Hello message and uses a pre-shared key to perform a 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.

[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, and 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 a selected encryption suite and a 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 over.

[0012] S150: The client determines the 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, 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 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.

[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, which solves the problem that public key identity authentication is vulnerable to quantum computing attacks in existing methods and the problem of reduced security caused by repeated use 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 to be quickly deployed and promoted. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 This is a flow chart of a data protection method for integrating quantum keys in 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 FIG. 4 is a schematic diagram of updating a 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, it is a flow chart of a data protection method 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, 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 the 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 in 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 and uses a pre-shared key to perform a handshake, wherein 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 authentication 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 for 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 above-mentioned pre-shared key is configured in advance by the client and the server. Both parties can select a fixed-length quantum key as the pre-shared key in advance to improve the key strength. When configuring the pre-shared key, a unified pre-shared key identifier is configured at the same time, and the expiration time of the pre-shared key is indicated. The default expiration time is one week. 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;

[0028] When the pre-shared key is established, the 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, and 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 the message authentication code based on the hash operation to calculate the binding value for the current message copy; if it is consistent with the binding value provided by the client, it verifies that both parties hold the same pre-shared key and completes the identity authentication of the client; otherwise, the client identity cannot be verified, and the server sends an "Invalid PSK" alarm to terminate the TLS connection. The server can only retrieve the quantum key from the second quantum key management device after successfully authenticating the legal identity of the client, which can prevent illegal users from constantly causing the server to retrieve the quantum key and cause the server key resources to be exhausted.

[0032] In operation S140, the server sends a Server Hello message, which includes the selected encryption suite and an identifier of the selected pre-shared key. 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, indicating that the handshake phase of the server is over.

[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 pre-shared key selected by the server.

[0034] Among them, the predefined key generation algorithm is a key derivation function (HMAC-based Key Derivation Function, HKDF) based on a 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 materials, 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, indicating that the handshake phase of the client is over;

[0036] The client verifies whether the identifier of the pre-shared key selected by the server is within the range supported by the client. If not, the handshake process is terminated. The client uses the pre-shared key and the first quantum key as key materials, uses HKDF to calculate the handshake key and the session key, and uses the handshake key to verify whether the content of the server's Finished message is correct. If it is not correct, it indicates that the keys negotiated by the client and the server are inconsistent. The client sends a "decryption failure" alarm and terminates the TLS connection. If the verification is successful, the client uses the handshake key to perform HMAC signatures on all the handshake information and generate 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, initiates a quantum key acquisition request to the second quantum key management device, and 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 initiates a quantum key retrieval request to the first quantum key management device using the obtained second quantum key identifier, and 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 As shown in the figure, the communication architecture of the TLS protocol integrating quantum key according to the present invention and the handshake flow chart are shown. The first quantum key manager is connected to the QKD device A, the second quantum key manager is connected to the QKD device B, and the QKD devices use the quantum key distribution protocol. The quantum key manager stores the quantum key generated by the QKD device into the 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 the server communicate through a public channel.

[0041] The client and the server first establish a TCP connection, complete a three-way handshake, and then start 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, and the first quantum key management device 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, and in the exchange mode extension item, i.e., the "psk_key_exchange_modes" extension item, indicates that the exchange mode is "psk_qke_ke", indicating that both the pre-shared key and the quantum key are used for key exchange and the pre-shared key is used for handshake. This mode is a newly added mode of the present invention. The standard protocol only contains "psk_ke" and "psk_dhe_ke", indicating that only the PSK key is used or the PSK and (EC)DHE are used for handshake. The client stores the list of supported encryption suites in the "cipher_suites" extension item, including the authentication encryption algorithm and hash encryption suite 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 item;

[0043] The client includes the pre-shared key identifier list PSKid_LIST of the local unexpired pre-shared key in the pre-shared key extension, i.e., the "pre_shared_key" extension, and the binding value calculated for the current message copy using a message authentication code based on a hash operation for each pre-shared key. The default algorithm used is SHA256-HMAC. Each identifier in the pre-shared key identifier list corresponds one-to-one and is in the same order.

[0044] The above-mentioned pre-shared key is configured in advance by the client and the 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 the message authentication code based on the hash operation, using SHA256-HMAC by default, to calculate the binding value for the current message copy; if it is consistent with the binding value provided by the above client, it verifies that both parties hold the same pre-shared key, completing the identity authentication of the above client; then the server retrieves the quantum key from the second quantum key management device, including the quantum key identifier QKEYID_1 to be retrieved. Then the second quantum key management device returns the corresponding first quantum key QKEY_1 to the server;

[0046] After that, the server sends a Server Hello message, which contains the selected encryption 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 materials, and uses the key derivation function HKDF based on the hash operation message authentication code 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 handshake information to generate a Finished message.

[0047] Afterwards, the client verifies whether the identifier of the pre-shared key selected by the server is within the range supported by itself. 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, and jointly uses the pre-shared key PSK_1 and the first quantum key QKEY_1 as key materials, and uses the key derivation function HKDF based on the hash operation message authentication code to calculate the handshake key and the session key. Use the handshake key to perform HMAC signature on all the above handshake information and generate a Finished message, indicating that the handshake phase of the client is over and the TLS session communication officially begins.

[0048] like Figure 3 As shown, it is a schematic diagram of updating the pre-shared key database of 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, after verification, the pre-shared key update operation is immediately 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 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 and the second quantum key identifier as well as the corresponding expiration time Life_time to the local pre-shared key database A.

[0050] The present invention discloses a data protection method that integrates quantum keys in TLS. The method uses quantum keys in combination with pre-shared keys for identity authentication and continuously updates the pre-shared key database, solving the problem that public key identity authentication is vulnerable to quantum computing attacks in existing methods and the problem of reduced security caused by repeated use 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 unsafe 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.

[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 description is only a specific embodiment of the present invention and is 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, 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; S120: The client sends a Client Hello message and uses a pre-shared key to perform a 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. 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, and 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 a selected encryption suite and a 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 over. S150: The client determines the 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, 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, and 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 in 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 supportable encryption suite list includes the authentication encryption algorithm and hash encryption algorithm suite supported by the client; the exchange mode extension item indicates that the key 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 item provides a list of pre-shared key identifiers, and a binding value calculated by each pre-shared key for the current message copy; Among them, 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, and uses the corresponding pre-shared key 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, 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 supportable 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 alarm 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, the 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 the 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 and the second quantum key identifier, as well as 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