Key generation method, device and system

Abstract

The invention provides a key generation method, device and system, and relates to the technical field of networks. A first application device determines a negotiation key by performing key negotiation with a second application device. The first application device generates a target key based on the seed key and the key-derived function parameter value using the key-derived function. And the first application device encrypts key context information by using the negotiation key to obtain a key context information ciphertext, the key context information comprising a key derived function parameter value. And the first application device sends a key generation request message to the second application device, wherein the key generation request message comprises the key context information ciphertext. The key generation request message is used for requesting the second application equipment to generate a target key. The two communication parties can automatically generate the same target key. The key context information used for generating the target key is transmitted after being symmetrically encrypted by adopting the negotiation key, so that anti-quantum security in the target key generation process can be realized.

Description

Technical Field

[0001] This application relates to the field of network technology, and in particular to a key generation method, device and system. Background Technology

[0002] With the development of quantum computers, quantum attacks pose a significant threat to currently widely used cryptographic systems. Quantum attacks are attack algorithms running on quantum computers capable of breaking widely used public-key cryptography algorithms such as RSA (rivest-shamir-adleman) and elliptic curve cryptography (ECC). Quantum computers are expected to be achievable within the next few decades. If an eavesdropper saves data encrypted using current encryption algorithms and transmitted over a network, and then uses a quantum attack to break the encryption algorithm of the saved data after quantum computers are implemented, they can obtain the decrypted plaintext data. This poses a huge threat to confidential information that needs to be stored long-term. Therefore, designing cryptographic technologies resistant to quantum attacks has become an urgent matter.

[0003] Since symmetric cryptography is relatively unaffected by quantum attacks—generally, extending the key length can resist them—communication security can be ensured by configuring symmetric keys for both communication endpoints. Currently, there are two main methods for configuring symmetric keys for communication endpoints. One method involves manually configuring the same key for both endpoints. This method is labor-intensive and lacks flexibility in key updates. The other method involves a quantum key distribution (QKD) network providing the same quantum key to both endpoints. In this method, both endpoints need to communicate with the QKD network to obtain the quantum key. Due to factors such as the communication security between the endpoints and the QKD network, and the performance limitations of the QKD network, the security and reliability of the quantum key obtained by the endpoints are difficult to guarantee. Summary of the Invention

[0004] This application provides a key generation method, device, and system.

[0005] Firstly, a key generation method is provided. The method includes: a first application device negotiating a key with a second application device to determine a negotiated key, wherein the first and second application devices hold the same negotiated key; the first application device using a key derivation function to generate a target key based on a seed key and key derivation function parameter values, the key derivation function parameter values ​​including a random salt value; the first application device encrypting key context information using the negotiated key to obtain ciphertext of the key context information, the key context information including the key derivation function parameter values; and the first application device sending a key generation request message to the second application device, the key generation request message including the ciphertext of the key context information. This key generation request message is used to request the second application device to generate the target key.

[0006] Optionally, the target key is used for secure data transmission or secure authentication of the application protocol.

[0007] In this application, the communicating parties first determine that they hold the same negotiation key through key negotiation. They then use this negotiation key to encrypt the key context information before transmission, enabling both parties to generate the same target key using the same key context information. On one hand, this achieves automatic generation of the same target key by both parties. On the other hand, since the key context information used by both parties to generate the target key is transmitted after symmetric encryption using the negotiation key, only the parties holding the negotiation key can decrypt and obtain the key context information. Provided the negotiation key is not leaked or cracked, symmetric encryption can be combined with the key context information transmission process to resist quantum attacks, thereby achieving quantum-resistant security in the target key generation process.

[0008] Optionally, the first application device determines a negotiated key by engaging in key negotiation with the second application device. This includes: the first application device sending a key negotiation request message to the second application device, the key negotiation request message indicating the public key algorithms supported by the first application device; the first application device receiving a key negotiation response message corresponding to the key negotiation request message from the second application device, the key negotiation response message indicating the public key algorithms supported by both the second and first application devices; and if the public key algorithms supported by both the second and first application devices are not empty, the first application device, based on the public key algorithms supported by both the second and first application devices, engages in key negotiation with the second application device using a key negotiation algorithm to generate a negotiated key.

[0009] Optionally, the public-key algorithms supported by both the first and second application devices include post-quantum cryptography algorithms. Since post-quantum cryptography algorithms inherently possess a certain degree of resistance to quantum attacks, the negotiation keys generated based on them also possess a certain degree of resistance to quantum attacks, thus achieving quantum-resistant security in the negotiation key generation process.

[0010] Optionally, the public key algorithms supported by both the second application device and the first application device include a first public key algorithm and a second public key algorithm. One implementation of the first application device generating a negotiated key by negotiating with the second application device using a key negotiation algorithm based on the public key algorithms supported by both the first and second application devices includes: the first application device negotiating with the second application device using a first key negotiation algorithm based on the first public key algorithm to generate a first key; the first application device negotiating with the second application device using a second key negotiation algorithm based on the second public key algorithm to generate a second key; and the first application device generating a negotiated key based on the first and second keys.

[0011] In this application, when both the first application device and the second application device support multiple public key algorithms, the final negotiation key is generated by mixing multiple keys obtained through key negotiation based on multiple public key algorithms. In this way, as long as one of the keys used to generate the negotiation key is not cracked, the negotiation key cannot be cracked, thereby improving the security of the negotiation key.

[0012] Optionally, the first application device stores one or more configuration keys. The first application device uses the first configuration key to encrypt the negotiation request information to obtain ciphertext of the negotiation request information. The negotiation request information includes a first public key algorithm list, which carries the algorithm identifiers of the public key algorithms supported by the first application device. The first configuration key is any one of the one or more configuration keys. The key negotiation request message includes the ciphertext of the negotiation request information and the key identifier of the first configuration key.

[0013] In this application, the first application device uses a configuration key to encrypt the negotiation request information using a symmetric encryption algorithm, which can resist quantum attacks during the transmission of the negotiation request information, thereby achieving quantum-resistant security in the negotiation key generation process.

[0014] Optionally, the negotiation request information may also include the algorithm identifier of the key negotiation algorithm used by the first application device and the second application device to conduct key negotiation.

[0015] Optionally, the key negotiation algorithm includes, but is not limited to, the key-encapsulation mechanism (KEM) algorithm and / or the elliptic curve Diffie-Hellman (ECDH) key exchange algorithm.

[0016] Optionally, the key negotiation response message includes ciphertext of negotiation response information. After the first application device receives the key negotiation response message from the second application device, the first application device uses the first configuration key to decrypt the ciphertext of negotiation response information to obtain a second public key algorithm list. The second public key algorithm list is used to carry the algorithm identifiers of public key algorithms supported by both the second application device and the first application device.

[0017] In this application, the second application device uses a configuration key to encrypt the negotiation response information using a symmetric encryption algorithm, which can resist quantum attacks during the transmission of the negotiation response information, thereby achieving quantum-resistant security in the negotiation key generation process.

[0018] Optionally, the first application device stores one or more configuration keys. If the public key algorithm supported by both the second and first application devices is empty, the first application device uses the second configuration key as the negotiation key, and the second configuration key is any one of the one or more configuration keys. The key generation request message also includes a key identifier for the second configuration key.

[0019] The second configuration key has a length greater than a length threshold. Since the configuration key is pre-stored on both the first and second application devices and typically does not leave the devices, it is not at risk of being compromised by information leakage during the negotiation process or by quantum attacks. When using the configuration key as the negotiation key, as long as the storage security of the configuration key on both the first and second application devices is ensured—that is, the configuration key on both devices is not leaked—the security of the negotiation key can be achieved. Furthermore, using a configuration key with a length greater than the length threshold as the negotiation key makes it resistant to quantum attacks.

[0020] Optionally, after the first application device generates a negotiated key by negotiating with the second application device using a key negotiation algorithm based on a public key algorithm supported by both the first and second application devices, and the negotiated key meets the key update conditions, the first application device renegotiates with the second application device using the same public key algorithm to obtain an updated negotiated key. The key update conditions include: the generation time of the negotiated key reaches the aging time, and / or, the number of times the negotiated key has been used reaches a threshold.

[0021] In this application, by periodically updating the negotiation key held by the first application device and the second application device or updating it according to the number of times it is used, the security of key generation can be improved, and the security of all subsequently generated keys can be avoided if the negotiation key is leaked once.

[0022] Optionally, the first application device may announce the seed key to the second application device.

[0023] Optionally, the key context information may also include a key identifier assigned by the first application device to the target key.

[0024] One possible implementation involves a first application device using a key derivation function to generate a target key based on a seed key and the parameter values ​​of the key derivation function. This includes: in response to receiving a key acquisition instruction from a first application, the first application device uses the key derivation function to generate the target key based on the seed key and the parameter values ​​of the key derivation function. The key acquisition instruction includes the device identifier of the second application device. Correspondingly, after the first application device sends a key generation request message to the second application device, the first application device receives a key generation response message corresponding to the key generation request message from the second application device. The key generation response message indicates that the second application device has generated the target key. The first application device then allocates the target key and its key identifier to the first application.

[0025] In this application, the first application device can generate the target key under the trigger condition of the application requesting a key.

[0026] Another possible implementation involves the first application device sending a key generation request message to the second application device. The first application device then receives a key generation response message corresponding to the key generation request message from the second application device. This response message indicates that the second application device has generated the target key. The first application device then sets the target key to an available status and stores the target key and its key identifier.

[0027] In this application, the first application device can pre-generate a target key and store it locally, and then allocate the locally stored target key to the application that requests the key.

[0028] Furthermore, if a key acquisition instruction is received from the first application, the first application device allocates a stored target key and a key identifier of the target key to the first application. The key acquisition instruction includes the device identifier of the second application device.

[0029] Optionally, after the first application device allocates the stored target key and its key identifier to the first application, the first application device sends a key status synchronization request message to the second application device. The key status synchronization request message includes the key identifier of the target key and indicates that the first application device has allocated the target key. The first application device receives a key status synchronization response message corresponding to the key status synchronization request message from the second application device. The key status synchronization response message indicates that the second application device has set the target key's status to allocated. The first application device then sets the target key's status to allocated.

[0030] In this implementation, since the first application device pre-generates the target key and stores it locally, the first application device can distinguish and identify whether the target key has been allocated by synchronizing the status of the target key with the second application device, thereby avoiding the target key being allocated repeatedly.

[0031] In the first possible implementation, the key acquisition instruction also includes a key aging time. After the first application device allocates the target key and the key identifier of the target key to the first application, the first application device sends the first key allocation information to the second application device. The first key allocation information includes the key identifier of the target key and the key aging time. The key aging time is used by the second application device to age the target key after a timeout.

[0032] In a second possible implementation, the key acquisition instruction further includes a key request identifier and a key aging time. The implementation of the first application device allocating a target key and its key identifier to the first application includes: the first application device allocating a key list to the first application, the key list comprising multiple key groups, each key group including a key and its key identifier, and the target key and its key identifier being one of the multiple key groups. The first application device sends second key allocation information to the second application device, the second key allocation information including a key request identifier, key identifiers in the key list, and a key aging time. The key aging time is used by the second application device to age the key list after a certain period, and the key request identifier is used by the second application device to allocate the key list to the second application, the second application being the application configured with the key request identifier on the second application device.

[0033] Optionally, in the first or second possible implementation described above, the application protocol running by the first application includes, but is not limited to, Internet Protocol Security (IPSec) or Transport Layer Security (TLS) protocols.

[0034] In a third possible implementation, the key acquisition instruction also includes the protocol identifier of the application protocol running by the first application. After the first application device allocates the target key and the key identifier of the target key to the first application, the first application device sends third key allocation information to the second application device. The third key allocation information includes the key identifier and the protocol identifier of the target key. The protocol identifier is used by the second application device to allocate the target key to the third application, and the third application is an application on the second application device that subscribes to the key corresponding to the protocol identifier.

[0035] Optionally, in the third possible implementation described above, the application protocol running by the first application includes, but is not limited to, Border Gateway Protocol (BGP), Label Distribution Protocol (LDP), or Path Computation Element Protocol (PCEP).

[0036] Based on the above three possible implementation methods, it can be seen that this application provides corresponding key allocation methods for the differences in key application of different application protocols, supports a wide range of application protocols, has little impact on application protocols, and has high feasibility.

[0037] Optionally, the first application device includes a key management module, and the above method is executed by the key management module.

[0038] Optionally, the key management module receives a key acquisition instruction from the first application, the key acquisition instruction including the device identifier of the second application device; the key management module acquires one or more keys that are the same as those held by the key management module and the second application device according to the key acquisition instruction; the key management module allocates one or more keys to the first application.

[0039] This application enables unified management and allocation of keys by configuring a key management module in the application device. In this way, the keys required by various application protocols can be obtained from the key management module, which simplifies the key management of various application protocols.

[0040] Optionally, the sources of the keys held by the key management module include, but are not limited to, one or more of the following: keys generated by the key management module; keys imported into the key management module; keys obtained by the key management module from the key service platform; and keys obtained by the key management module by mixing the generated keys with the keys obtained from the key service platform.

[0041] In this application, the key management module in the application device supports multiple working modes, with different key sources in each mode. The key management module in the application device can switch to different working modes to cope with different application scenarios.

[0042] Optionally, the first application is an application on a first application device, or the first application is an application on a third application device, which is different from the first application device.

[0043] In this application, in addition to automatically configuring symmetric keys for its own applications, the application device can also configure symmetric keys for applications on other application devices.

[0044] Optionally, both the first application device and the second application device are network devices.

[0045] Secondly, a key generation method is provided. The method includes: a second application device negotiating a key with a first application device to determine a negotiated key, wherein the second application device and the first application device hold the same negotiated key; the second application device receiving a key generation request message from the first application device, the key generation request message including ciphertext of key context information; the second application device decrypting the ciphertext of key context information using the negotiated key to obtain key context information, the key context information including key derivation function parameter values, the key derivation function parameter values ​​including a random salt value; and the second application device using a key derivation function to generate a target key based on a seed key and the key derivation function parameter values.

[0046] In this application, the communicating parties first determine that they hold the same negotiation key through key negotiation. They then use this negotiation key to encrypt the key context information before transmission, enabling both parties to generate the same target key using the same key context information. On one hand, this achieves automatic generation of the same target key by both parties. On the other hand, since the key context information used by both parties to generate the target key is transmitted after symmetric encryption using the negotiation key, only the parties holding the negotiation key can decrypt and obtain the key context information. Provided the negotiation key is not leaked or cracked, symmetric encryption can be combined with the key context information transmission process to resist quantum attacks, thereby achieving quantum-resistant security in the target key generation process.

[0047] Optionally, the second application device determines a negotiated key by engaging in key negotiation with the first application device in one implementation method, including: the second application device receiving a key negotiation request message from the first application device, the key negotiation request message indicating the public key algorithms supported by the first application device; the second application device sending a key negotiation response message corresponding to the key negotiation request message to the first application device, the key negotiation response message indicating the public key algorithms supported by both the second and first application devices; if the public key algorithms supported by both the second and first application devices are not empty, the second application device responds to the first application device by performing key negotiation through a key negotiation algorithm based on the public key algorithms supported by both the second and first application devices to generate a negotiated key.

[0048] Optionally, the public key algorithms supported by both the second application device and the first application device include a first public key algorithm and a second public key algorithm. One implementation of the second application device generating a negotiation key by performing key negotiation via a key negotiation algorithm in response to the first application device, based on the public key algorithms supported by both the second and first application devices, includes: the second application device performing key negotiation via a first key negotiation algorithm in response to the first application device, to generate a first key; the second application device performing key negotiation via a second key negotiation algorithm in response to the first application device, to generate a second key; and the second application device generating a negotiation key based on the first and second keys.

[0049] In this application, when both the first application device and the second application device support multiple public key algorithms, the final negotiation key is generated by mixing multiple keys obtained through key negotiation based on multiple public key algorithms. In this way, as long as one of the keys used to generate the negotiation key is not cracked, the negotiation key cannot be cracked, thereby improving the security of the negotiation key.

[0050] Optionally, the second application device stores one or more configuration keys. The key negotiation request message includes encrypted negotiation request information and a first key identifier. After receiving the key negotiation request message from the first application device, the second application device obtains the first configuration key from the one or more configuration keys based on the first key identifier. The second application device uses the first configuration key to decrypt the encrypted negotiation request information to obtain the negotiation request information, which includes a first public key algorithm list. The first public key algorithm list carries the algorithm identifiers of the public key algorithms supported by the first application device.

[0051] In this application, the first application device uses a configuration key to encrypt the negotiation request information using a symmetric encryption algorithm, which can resist quantum attacks during the transmission of the negotiation request information, thereby achieving quantum-resistant security in the negotiation key generation process.

[0052] Optionally, the second application device encrypts the negotiation response information using the first configuration key to obtain ciphertext of the negotiation response information. The negotiation response information includes a second public key algorithm list, which carries the algorithm identifiers of public key algorithms supported by both the second and first application devices. The key negotiation response message includes the ciphertext of the negotiation response information.

[0053] In this application, the second application device uses a configuration key to encrypt the negotiation response information using a symmetric encryption algorithm, which can resist quantum attacks during the transmission of the negotiation response information, thereby achieving quantum-resistant security in the negotiation key generation process.

[0054] Optionally, the second application device stores one or more configuration keys, and the key generation request message further includes a second key identifier. The second application device obtains the second configuration key from the one or more configuration keys based on the second key identifier. The second application device uses the second configuration key as a negotiation key.

[0055] Since the configuration key is pre-stored on both the first and second application devices and typically does not leave the devices, it is not at risk of being compromised due to information leakage during the negotiation process or quantum attacks. When using the configuration key as the negotiation key, as long as the storage security of the configuration key on both devices is guaranteed—that is, the configuration key on both devices is not leaked—the security of the negotiation key can be achieved. Furthermore, using a configuration key with a length exceeding a certain threshold as the negotiation key makes it resistant to quantum attacks.

[0056] Optionally, the second application device obtains the seed key announced by the first application device.

[0057] Optionally, the key context information also includes a key identifier assigned to the target key by the first application device. After the second application device generates the target key based on the seed key and the parameter values ​​of the key derivation function using the key derivation function, the second application device stores the target key and the key identifier of the target key.

[0058] Optionally, after the second application device generates the target key based on the seed key and the parameter values ​​of the key derivation function using the key derivation function, the second application device sends a key generation response message corresponding to the key generation request message to the first application device. The key generation response message indicates that the second application device has generated the target key. The second application device then sets the status of the target key to available.

[0059] Optionally, the second application device receives a key status synchronization request message from the first application device. The key status synchronization request message includes a key identifier for the target key and indicates that the first application device has allocated the target key. The second application device sets the status of the target key to "allocated." The second application device then sends a key status synchronization response message corresponding to the key status synchronization request message to the first application device. The key status synchronization response message indicates that the second application device has set the status of the target key to "allocated."

[0060] In one possible implementation, the second application device receives first key allocation information from the first application device. This first key allocation information includes a key identifier for the target key and a key aging time. The key aging time is used by the second application device to age the target key. If a key acquisition request, including the key identifier of the target key, is received from the first application on the second application device within the key aging time, the second application device allocates the target key to the first application.

[0061] In a second possible implementation, the second application device receives second key allocation information from the first application device. This second key allocation information includes a key request identifier, a key identifier list, and a key aging time. The key aging time is used by the second application device to time out the keys indicated in the key identifier list. If, before the key aging time expires, it is determined that a second application on the second application device is configured with a key request identifier, the second application device allocates the key indicated in the key identifier list to the second application.

[0062] In a third possible implementation, the second application device receives third key allocation information from the first application device. This third key allocation information includes the key identifier and protocol identifier of the target key. The second application device then allocates the target key to a third application, which is an application on the second application device that subscribes to the key corresponding to the protocol identifier.

[0063] Thirdly, an application device is provided. For ease of distinction, this application device is referred to herein as a first application device. The first application device includes multiple functional modules, which interact to implement the methods described in the first aspect and its various embodiments. The multiple functional modules can be implemented based on software, hardware, or a combination of software and hardware, and can be arbitrarily combined or divided based on specific implementations.

[0064] For example, the first application device includes, but is not limited to, a key negotiation module, a key generation module, an encryption / decryption module, and a transceiver module. Optionally, the first application device further includes a key distribution module and a key state management module.

[0065] The system includes the following modules: a key negotiation module for determining a negotiation key by negotiating with a second application device, wherein both the first and second application devices hold the same negotiation key; a key generation module for generating a target key using a key derivation function based on a seed key and key derivation function parameter values, wherein the key derivation function parameter values ​​include a random salt value; an encryption / decryption module for encrypting key context information using the negotiation key to obtain ciphertext of the key context information, wherein the key context information includes the key derivation function parameter values; and a transceiver module for sending a key generation request message to the second application device, wherein the key generation request message includes the ciphertext of the key context information and is used to request the second application device to generate the target key.

[0066] Optionally, the transceiver module is configured to send a key negotiation request message to the second application device, the key negotiation request message indicating the public key algorithms supported by the first application device, and to receive a key negotiation response message corresponding to the key negotiation request message from the second application device, the key negotiation response message indicating the public key algorithms supported by both the second application device and the first application device. The key negotiation module is configured to, if the public key algorithms supported by both the second application device and the first application device are not empty, perform key negotiation with the second application device using a key negotiation algorithm based on the public key algorithms supported by both the second application device and the first application device to generate the negotiation key.

[0067] Optionally, the public key algorithms supported by both the second application device and the first application device include a first public key algorithm and a second public key algorithm. The key negotiation module is configured to: negotiate a key with the second application device using a first key negotiation algorithm based on the first public key algorithm to generate a first key; negotiate a key with the second application device using a second key negotiation algorithm based on the second public key algorithm to generate a second key; and generate the negotiation key based on the first key and the second key.

[0068] Optionally, the first application device stores one or more configuration keys. The encryption / decryption module is further configured to encrypt the negotiation request information using the first configuration key to obtain ciphertext of the negotiation request information. The negotiation request information includes a first public key algorithm list, which carries algorithm identifiers of public key algorithms supported by the first application device. The first configuration key is any one of the one or more configuration keys. The key negotiation request message includes the ciphertext of the negotiation request information and the key identifier of the first configuration key.

[0069] Optionally, the negotiation request information may also include the algorithm identifier of the key negotiation algorithm used by the first application device and the second application device to negotiate the key.

[0070] Optionally, the key negotiation algorithm includes the KEM algorithm and / or the ECDH key exchange algorithm.

[0071] Optionally, the key negotiation response message includes ciphertext of negotiation response information. The encryption / decryption module is further configured to, after the first application device receives the key negotiation response message from the second application device, use the first configuration key to decrypt the ciphertext of negotiation response information to obtain a second public key algorithm list. The second public key algorithm list is used to carry algorithm identifiers of public key algorithms supported by both the second application device and the first application device.

[0072] Optionally, the first application device stores one or more configuration keys. A key negotiation module is configured to use a second configuration key as the negotiation key if the public key algorithm supported by both the second and first application devices is empty. The second configuration key is any one of the one or more configuration keys. The key generation request message further includes a key identifier for the second configuration key.

[0073] Optionally, the key negotiation module is further configured to, after the first application device performs key negotiation with the second application device based on a public key algorithm supported by both the first and second application devices to generate the negotiation key, when the negotiation key meets the key update conditions, re-negotiate the key with the second application device based on a public key algorithm supported by both the first and second application devices through the key negotiation algorithm to obtain an updated negotiation key, wherein the key update conditions include: the generation time of the negotiation key reaches the aging time, and / or, the number of times the negotiation key is used reaches a threshold.

[0074] Optionally, the transceiver module is further configured to notify the second application device of the seed key.

[0075] Optionally, the key context information may also include a key identifier assigned by the first application device to the target key.

[0076] Optionally, the key generation module is configured to, in response to receiving a key acquisition instruction from the first application, generate the target key using the key derivation function based on the seed key and the parameter values ​​of the key derivation function, wherein the key acquisition instruction includes the device identifier of the second application device. The transceiver module is further configured to, after the first application device sends a key generation request message to the second application device, receive a key generation response message corresponding to the key generation request message from the second application device, wherein the key generation response message indicates that the second application device has generated the target key. The key allocation module is configured to allocate the target key and the key identifier of the target key to the first application.

[0077] Optionally, the transceiver module is further configured to receive a key generation response message corresponding to the key generation request message from the second application device after the first application device sends a key generation request message to the second application device, wherein the key generation response message indicates that the second application device has generated the target key. The key status management module is configured to set the status of the target key to available and store the target key and its key identifier.

[0078] Optionally, the key allocation module is configured to, upon receiving a key acquisition instruction from a first application, allocate the stored target key and the key identifier of the target key to the first application, wherein the key acquisition instruction includes the device identifier of the second application device.

[0079] Optionally, the transceiver module is further configured to, after the first application device allocates the stored target key and the key identifier of the target key to the first application, send a key status synchronization request message to the second application device, the key status synchronization request message including the key identifier of the target key, the key status synchronization request message indicating that the first application device has allocated the target key, and receive a key status synchronization response message corresponding to the key status synchronization request message from the second application device, the key status synchronization response message indicating that the second application device has set the status of the target key to allocated. The key status management module is configured to set the status of the target key to allocated.

[0080] Optionally, the key acquisition instruction further includes a key aging time. The transceiver module is further configured to send first key allocation information to the second application device after the first application device allocates the target key and the key identifier of the target key to the first application device. The first key allocation information includes the key identifier of the target key and the key aging time, and the key aging time is used by the second application device to age the target key after a timeout.

[0081] Optionally, the key acquisition instruction further includes a key request identifier and a key aging time. The key allocation module is used to allocate a key list to the first application. The key list includes multiple key groups, each key group including a key and a key identifier for that key. The target key and its key identifier are one of the multiple key groups. The transceiver module is further used to send second key allocation information to the second application device. The second key allocation information includes the key request identifier, key identifiers in the key list, and the key aging time. The key aging time is used by the second application device to age the key list after a certain period. The key request identifier is used by the second application device to allocate the key list to the second application. The second application is an application configured with the key request identifier on the second application device.

[0082] Optionally, the application protocol running the first application may include the IPSec protocol or the TLS protocol.

[0083] Optionally, the key acquisition instruction further includes a protocol identifier of the application protocol running by the first application. The transceiver module is further configured to send third key allocation information to the second application device after the first application device allocates the target key and the key identifier of the target key to the first application. The third key allocation information includes the key identifier of the target key and the protocol identifier. The protocol identifier is used by the second application device to allocate the target key to the third application. The third application is an application on the second application device that subscribes to the key corresponding to the protocol identifier.

[0084] Optionally, the application protocol running the first application may include BGP, LDP, or PCEP.

[0085] Optionally, the first application device includes a key management module, which integrates the functions of the key negotiation module, the key generation module, the encryption / decryption module, and the transceiver module. Optionally, the key management module also integrates the functions of the key distribution module and the key status management module.

[0086] Optionally, the key management module receives a key acquisition instruction from a first application, the key acquisition instruction including the device identifier of the second application device; the key management module acquires one or more keys that are the same as those held by the key management module and the second application device according to the key acquisition instruction; the key management module allocates the one or more keys to the first application.

[0087] Optionally, the source of the key held by the key management module includes one or more of the following: a key generated by the key management module; a key imported by the key management module; a key obtained by the key management module from the key service platform; or a key obtained by the key management module by mixing the generated key and the key obtained from the key service platform.

[0088] Optionally, the first application is an application on the first application device, or the first application is an application on a third application device, which is different from the first application device.

[0089] Optionally, both the first application device and the second application device are network devices.

[0090] Fourthly, an application device is provided. For ease of distinction, this application device is referred to herein as a second application device. The second application device includes multiple functional modules that interact to implement the methods described in the second aspect and its various embodiments. The multiple functional modules can be implemented based on software, hardware, or a combination of software and hardware, and can be arbitrarily combined or divided based on specific implementations.

[0091] For example, the second application device includes, but is not limited to, a key negotiation module, a transceiver module, an encryption / decryption module, and a key generation module. Optionally, the second application device also includes a key state management module and a key distribution module.

[0092] The system includes a key negotiation module for determining a negotiation key by negotiating with a first application device, wherein the second application device and the first application device hold the same negotiation key. A transceiver module for receiving a key generation request message from the first application device, the message including ciphertext of key context information. An encryption / decryption module for decrypting the ciphertext using the negotiation key to obtain key context information, the latter including key derivation function parameter values, which include a random salt value. A key generation module for generating a target key based on a seed key and the key derivation function parameter values ​​using a key derivation function.

[0093] Optionally, the transceiver module is configured to receive a key negotiation request message from the first application device, the key negotiation request message indicating the public key algorithms supported by the first application device, and to send a key negotiation response message corresponding to the key negotiation request message to the first application device, the key negotiation response message indicating the public key algorithms supported by both the second application device and the first application device. The key negotiation module is configured to, if the public key algorithms supported by both the second application device and the first application device are not empty, respond to the first application device by performing key negotiation through a key negotiation algorithm to generate the negotiation key, based on the public key algorithms supported by both the second application device and the first application device.

[0094] Optionally, the public key algorithms supported by both the second application device and the first application device include a first public key algorithm and a second public key algorithm. The key negotiation module is configured to: respond to the first application device by performing key negotiation through the first key negotiation algorithm based on the first public key algorithm to generate a first key; respond to the first application device by performing key negotiation through the second key negotiation algorithm based on the second public key algorithm to generate a second key; and generate the negotiation key based on the first key and the second key.

[0095] Optionally, the second application device stores one or more configuration keys. The key negotiation request message includes ciphertext of negotiation request information and a first key identifier. The encryption / decryption module is further configured to, after the second application device receives the key negotiation request message from the first application device, obtain a first configuration key from the one or more configuration keys according to the first key identifier, and use the first configuration key to decrypt the ciphertext of negotiation request information to obtain negotiation request information. The negotiation request information includes a first public key algorithm list, which is used to carry the algorithm identifiers of the public key algorithms supported by the first application device.

[0096] Optionally, the encryption / decryption module is further configured to encrypt the negotiation response information using the first configuration key to obtain ciphertext of the negotiation response information. The negotiation response information includes a second public key algorithm list, which carries algorithm identifiers of public key algorithms supported by both the second application device and the first application device. The ciphertext of the negotiation response information is included in the key negotiation response message.

[0097] Optionally, the second application device stores one or more configuration keys, and the key generation request message further includes a second key identifier. The key negotiation module is used to obtain a second configuration key from the one or more configuration keys according to the second key identifier, and use the second configuration key as the negotiation key.

[0098] Optionally, the transceiver module is further configured to obtain the seed key announced by the first application device.

[0099] Optionally, the key context information further includes a key identifier assigned by the first application device to the target key. The key state management module is used to store the target key and the key identifier of the target key after the second application device generates the target key based on the seed key and the parameter values ​​of the key derivation function using a key derivation function.

[0100] Optionally, the transceiver module is further configured to, after the second application device generates a target key based on a seed key and the parameter values ​​of the key derivation function using a key derivation function, send a key generation response message corresponding to the key generation request message to the first application device, wherein the key generation response message indicates that the second application device has generated the target key. The key status management module is configured to set the status of the target key to available.

[0101] Optionally, the transceiver module is further configured to receive a key status synchronization request message from the first application device, the key status synchronization request message including a key identifier of the target key, and the key status synchronization request message indicating that the first application device has allocated the target key. The key status management module is configured to set the status of the target key to allocated. The transceiver module is further configured to send a key status synchronization response message corresponding to the key status synchronization request message to the first application device, the key status synchronization response message indicating that the second application device has set the status of the target key to allocated.

[0102] Optionally, the transceiver module is further configured to receive first key allocation information from the first application device, the first key allocation information including a key identifier of the target key and a key aging time, the key aging time being used by the second application device to age the target key. The key allocation module is configured to allocate the target key to the first application if it receives a key acquisition request from a first application on the second application device within the key aging time, the key acquisition request including the key identifier of the target key.

[0103] Optionally, the transceiver module is further configured to receive second key allocation information from the first application device. The second key allocation information includes a key request identifier, a key identifier list, and a key aging time. The key aging time is used by the second application device to age out the keys indicated by the key identifier list. The key allocation module is configured to allocate the keys indicated by the key identifier list to the second application if, before the key aging time expires, it determines that a second application on the second application device is configured with the key request identifier.

[0104] Optionally, the transceiver module is further configured to receive third key allocation information from the first application device, the third key allocation information including a key identifier and a protocol identifier for the target key. The key allocation module is configured to allocate the target key to a third application, the third application being an application on the second application device that subscribes to the key corresponding to the protocol identifier.

[0105] Fifthly, a first application device is provided, comprising: a memory, a network interface, and at least one processor. The memory stores program instructions, and the at least one processor reads the program instructions stored in the memory, causing the first application device to execute the methods described in the first aspect and its various embodiments.

[0106] Specifically, after the at least one processor reads the program instructions stored in the memory, it causes the first application device to perform the following operations: determine a negotiation key by negotiating with the second application device, wherein the first application device and the second application device hold the same negotiation key; generate a target key based on a seed key and key derivation function parameter values, wherein the key derivation function parameter values ​​include a random salt value; encrypt key context information using the negotiation key to obtain ciphertext of the key context information, wherein the key context information includes the key derivation function parameter values; and send a key generation request message to the second application device, wherein the key generation request message includes the ciphertext of the key context information and is used to request the second application device to generate the target key.

[0107] Optionally, after the at least one processor reads the program instructions stored in the memory, it causes the first application device to perform the following operations: send a key negotiation request message to the second application device, the key negotiation request message indicating the public key algorithms supported by the first application device; receive a key negotiation response message corresponding to the key negotiation request message from the second application device, the key negotiation response message indicating the public key algorithms supported by both the second application device and the first application device; if the public key algorithms supported by both the second application device and the first application device are not empty, perform key negotiation with the second application device based on the public key algorithms supported by both the second application device and the first application device through a key negotiation algorithm to generate the negotiation key.

[0108] Optionally, the public key algorithms supported by both the second application device and the first application device include a first public key algorithm and a second public key algorithm. After the at least one processor reads the program instructions stored in the memory, it causes the first application device to perform the following operations: based on the first public key algorithm, it performs key negotiation with the second application device through a first key negotiation algorithm to generate a first key; based on the second public key algorithm, it performs key negotiation with the second application device through a second key negotiation algorithm to generate a second key; and generates the negotiation key according to the first key and the second key.

[0109] Optionally, the first application device stores one or more configuration keys. After the at least one processor reads the program instructions stored in the memory, it causes the first application device to perform the following operations: encrypting the negotiation request information using the first configuration key to obtain ciphertext of the negotiation request information. The negotiation request information includes a first public key algorithm list, which carries the algorithm identifiers of public key algorithms supported by the first application device. The first configuration key is any one of the one or more configuration keys. The key negotiation request message includes the ciphertext of the negotiation request information and the key identifier of the first configuration key.

[0110] Optionally, the negotiation request information may also include the algorithm identifier of the key negotiation algorithm used by the first application device and the second application device to negotiate the key.

[0111] Optionally, the key negotiation algorithm includes the KEM algorithm and / or the ECDH key exchange algorithm.

[0112] Optionally, the key negotiation response message includes ciphertext of negotiation response information. After the at least one processor reads the program instructions stored in the memory, it causes the first application device to perform the following operations: after the first application device receives the key negotiation response message from the second application device, it decrypts the ciphertext of negotiation response information using the first configuration key to obtain a second public key algorithm list. The second public key algorithm list is used to carry the algorithm identifiers of public key algorithms supported by both the second application device and the first application device.

[0113] Optionally, the first application device stores one or more configuration keys. After the at least one processor reads the program instructions stored in the memory, it causes the first application device to perform the following operations: if the public key algorithm supported by both the second application device and the first application device is empty, the second configuration key is used as the negotiation key, and the second configuration key is any one of the one or more configuration keys. The key generation request message further includes a key identifier for the second configuration key.

[0114] Optionally, after the at least one processor reads the program instructions stored in the memory, it causes the first application device to perform the following operations: after the first application device performs key negotiation with the second application device using a key negotiation algorithm based on a public key algorithm supported by both the first and second application devices to generate the negotiation key, when the negotiation key meets the key update conditions, it re-negotiates the key with the second application device using the key negotiation algorithm based on a public key algorithm supported by both the first and second application devices to obtain an updated negotiation key, wherein the key update conditions include: the generation time of the negotiation key reaches the aging time, and / or, the number of times the negotiation key is used reaches a threshold.

[0115] Optionally, after the at least one processor reads the program instructions stored in the memory, it causes the first application device to perform the following operation: notify the second application device of the seed key.

[0116] Optionally, the key context information may also include a key identifier assigned by the first application device to the target key.

[0117] Optionally, after the at least one processor reads the program instructions stored in the memory, it causes the first application device to perform the following operations: in response to receiving a key acquisition instruction from the first application, it uses the key derivation function to generate the target key based on the seed key and the parameter values ​​of the key derivation function, wherein the key acquisition instruction includes the device identifier of the second application device; after the first application device sends a key generation request message to the second application device, it receives a key generation response message corresponding to the key generation request message from the second application device, wherein the key generation response message indicates that the second application device has generated the target key; and it allocates the target key and the key identifier of the target key to the first application.

[0118] Optionally, after the at least one processor reads the program instructions stored in the memory, it causes the first application device to perform the following operations: after the first application device sends a key generation request message to the second application device, it receives a key generation response message corresponding to the key generation request message from the second application device, wherein the key generation response message indicates that the second application device has generated the target key; sets the status of the target key to available, and stores the target key and the key identifier of the target key.

[0119] Optionally, after the at least one processor reads the program instructions stored in the memory, it causes the first application device to perform the following operations: if it receives a key acquisition instruction from the first application, it allocates the stored target key and the key identifier of the target key to the first application, wherein the key acquisition instruction includes the device identifier of the second application device.

[0120] Optionally, after the at least one processor reads the program instructions stored in the memory, it causes the first application device to perform the following operations: after the first application device allocates the stored target key and the key identifier of the target key to the first application, it sends a key status synchronization request message to the second application device, the key status synchronization request message including the key identifier of the target key, the key status synchronization request message indicating that the first application device has allocated the target key; and receives a key status synchronization response message corresponding to the key status synchronization request message from the second application device, the key status synchronization response message indicating that the second application device has set the status of the target key to allocated; and sets the status of the target key to allocated.

[0121] Optionally, the key acquisition instruction further includes a key aging time. After the at least one processor reads the program instructions stored in the memory, it causes the first application device to perform the following operations: after the first application device allocates the target key and the key identifier of the target key to the first application, it sends first key allocation information to the second application device. The first key allocation information includes the key identifier of the target key and the key aging time, and the key aging time is used by the second application device to age the target key after a timeout.

[0122] Optionally, the key acquisition instruction further includes a key request identifier and a key aging time. After the at least one processor reads the program instructions stored in the memory, it causes the first application device to perform the following operations: allocate a key list to the first application, the key list including multiple key groups, each key group including a key and a key identifier of the key, the target key and the key identifier of the target key being one of the multiple key groups; send second key allocation information to the second application device, the second key allocation information including the key request identifier, key identifiers in the key list and the key aging time, the key aging time being used by the second application device to age the key list, the key request identifier being used by the second application device to allocate the key list to the second application, the second application being an application configured with the key request identifier on the second application device.

[0123] Optionally, the application protocol running the first application may include the IPSec protocol or the TLS protocol.

[0124] Optionally, the key acquisition instruction further includes a protocol identifier of the application protocol running by the first application. After the at least one processor reads the program instructions stored in the memory, it causes the first application device to perform the following operations: after the first application device allocates the target key and the key identifier of the target key to the first application, it sends third key allocation information to the second application device. The third key allocation information includes the key identifier of the target key and the protocol identifier. The protocol identifier is used by the second application device to allocate the target key to a third application. The third application is an application on the second application device that subscribes to the key corresponding to the protocol identifier.

[0125] Optionally, the application protocol running the first application may include BGP, LDP, or PCEP.

[0126] Optionally, the first application device includes a key management module, and after the at least one processor reads the program instructions stored in the memory, it causes the key management module to perform the above operations.

[0127] Optionally, the key management module receives a key acquisition instruction from a first application, the key acquisition instruction including the device identifier of the second application device; the key management module acquires one or more keys that are the same as those held by the key management module and the second application device according to the key acquisition instruction; the key management module allocates the one or more keys to the first application.

[0128] Optionally, the source of the key held by the key management module includes one or more of the following: a key generated by the key management module; a key imported by the key management module; a key obtained by the key management module from the key service platform; or a key obtained by the key management module by mixing the generated key and the key obtained from the key service platform.

[0129] Optionally, the first application is an application on the first application device, or the first application is an application on a third application device, which is different from the first application device.

[0130] Optionally, both the first application device and the second application device are network devices.

[0131] In a sixth aspect, a second application device is provided, comprising: a memory, a network interface, and at least one processor. The memory stores program instructions, and the at least one processor, after reading the program instructions stored in the memory, causes the second application device to execute the methods described in the second aspect and its embodiments.

[0132] Specifically, after the at least one processor reads the program instructions stored in the memory, it causes the second application device to perform the following operations: determine a negotiation key by negotiating with the first application device, wherein the second application device and the first application device hold the same negotiation key; receive a key generation request message from the first application device, the key generation request message including ciphertext of key context information; decrypt the ciphertext of key context information using the negotiation key to obtain key context information, the key context information including key derivation function parameter values, the key derivation function parameter values ​​including random salt values; and generate a target key based on a seed key and the key derivation function parameter values ​​using a key derivation function.

[0133] Optionally, after the at least one processor reads the program instructions stored in the memory, it causes the second application device to perform the following operations: receive a key negotiation request message from the first application device, the key negotiation request message indicating the public key algorithms supported by the first application device; and send a key negotiation response message corresponding to the key negotiation request message to the first application device, the key negotiation response message indicating the public key algorithms supported by both the second application device and the first application device; if the public key algorithms supported by both the second application device and the first application device are not empty, respond to the first application device to perform key negotiation through the key negotiation algorithm to generate the negotiation key based on the public key algorithms supported by both the second application device and the first application device.

[0134] Optionally, the public key algorithms supported by both the second application device and the first application device include a first public key algorithm and a second public key algorithm. After the at least one processor reads the program instructions stored in the memory, it causes the second application device to perform the following operations: based on the first public key algorithm, responding to the first application device by performing key negotiation through a first key negotiation algorithm to generate a first key; based on the second public key algorithm, responding to the first application device by performing key negotiation through a second key negotiation algorithm to generate a second key; and generating the negotiation key according to the first key and the second key.

[0135] Optionally, the second application device stores one or more configuration keys. The key negotiation request message includes ciphertext of negotiation request information and a first key identifier. After the at least one processor reads the program instructions stored in the memory, it causes the second application device to perform the following operations: after the second application device receives the key negotiation request message from the first application device, it obtains a first configuration key from the one or more configuration keys according to the first key identifier, and uses the first configuration key to decrypt the ciphertext of the negotiation request information to obtain negotiation request information. The negotiation request information includes a first public key algorithm list, which is used to carry the algorithm identifiers of the public key algorithms supported by the first application device.

[0136] Optionally, after the at least one processor reads the program instructions stored in the memory, it causes the second application device to perform the following operations: encrypting the negotiation response information using the first configuration key to obtain ciphertext of the negotiation response information, wherein the negotiation response information includes a second public key algorithm list, which carries algorithm identifiers of public key algorithms supported by both the second application device and the first application device. The ciphertext of the negotiation response information is included in the key negotiation response message.

[0137] Optionally, the second application device stores one or more configuration keys, and the key generation request message further includes a second key identifier. After the at least one processor reads the program instructions stored in the memory, it causes the second application device to perform the following operations: obtain a second configuration key from the one or more configuration keys according to the second key identifier; and use the second configuration key as the negotiation key.

[0138] Optionally, after the at least one processor reads the program instructions stored in the memory, it causes the second application device to perform the following operation: obtain the seed key announced by the first application device.

[0139] Optionally, the key context information further includes a key identifier assigned by the first application device to the target key. After the at least one processor reads the program instructions stored in the memory, it causes the second application device to perform the following operations: after the second application device generates the target key based on the seed key and the parameter values ​​of the key derivation function using the key derivation function, it stores the target key and the key identifier of the target key.

[0140] Optionally, after the at least one processor reads the program instructions stored in the memory, it causes the second application device to perform the following operations: after the second application device generates a target key based on the seed key and the parameter values ​​of the key derivation function using a key derivation function, it sends a key generation response message corresponding to the key generation request message to the first application device, wherein the key generation response message indicates that the second application device has generated the target key; and sets the status of the target key to available.

[0141] Optionally, after the at least one processor reads the program instructions stored in the memory, it causes the second application device to perform the following operations: receive a key status synchronization request message from the first application device, the key status synchronization request message including a key identifier of the target key, the key status synchronization request message indicating that the first application device has allocated the target key; set the status of the target key to allocated; and send a key status synchronization response message corresponding to the key status synchronization request message to the first application device, the key status synchronization response message indicating that the second application device has set the status of the target key to allocated.

[0142] Optionally, after the at least one processor reads the program instructions stored in the memory, it causes the second application device to perform the following operations: receiving first key allocation information from the first application device, the first key allocation information including the key identifier of the target key and the key aging time, the key aging time being used by the second application device to age the target key; if a key acquisition request is received from a first application on the second application device within the key aging time, the key acquisition request including the key identifier of the target key, the target key is allocated to the first application.

[0143] Optionally, after the at least one processor reads the program instructions stored in the memory, it causes the second application device to perform the following operations: receiving second key allocation information from the first application device, the second key allocation information including a key request identifier, a key identifier list, and a key aging time, the key aging time being used by the second application device to time out the keys indicated by the key identifier list. After the at least one processor reads the program instructions stored in the memory, it causes the second application device to perform the following operations: if it is determined that a second application on the second application device is configured with the key request identifier before the key aging time expires, it allocates the key indicated by the key identifier list to the second application.

[0144] Optionally, after the at least one processor reads the program instructions stored in the memory, it causes the second application device to perform the following operations: receive third key allocation information from the first application device, the third key allocation information including a key identifier and a protocol identifier for a target key; allocate the target key to a third application, the third application being an application on the second application device that subscribes to the key corresponding to the protocol identifier.

[0145] In a seventh aspect, a key generation system is provided, comprising: a first application device and a second application device, wherein the first application device is configured to execute the methods described in the first aspect and its embodiments, and the second application device is configured to execute the methods described in the second aspect and its embodiments.

[0146] Eighthly, a computer-readable storage medium is provided, wherein instructions are stored thereon, which, when executed by a processor of an application device, implement the methods of the first aspect and its embodiments described above, or implement the methods of the second aspect and its embodiments described above.

[0147] Ninthly, a computer program product is provided, comprising a computer program that, when executed by a processor of an application device, implements the methods described in the first aspect and its embodiments, or implements the methods described in the second aspect and its embodiments.

[0148] In a tenth aspect, a chip is provided, the chip including programmable logic circuitry and / or program instructions, which, when the chip is running, implement the methods described in the first aspect and its embodiments or the methods described in the second aspect and its embodiments. Attached Figure Description

[0149] Figure 1 This is a schematic diagram of an application device obtaining a quantum key from a QKD network;

[0150] Figure 2 This is a schematic diagram of an application scenario provided by an embodiment of this application;

[0151] Figure 3 This is a schematic diagram illustrating the implementation flow of a key generation method provided in an embodiment of this application;

[0152] Figure 4 This is a schematic diagram of a key application process provided in an embodiment of this application;

[0153] Figure 5 This is a schematic diagram of another key application process provided in an embodiment of this application;

[0154] Figure 6 This is a schematic diagram of another key application process provided in an embodiment of this application;

[0155] Figure 7 This is a schematic diagram illustrating how an application obtains a key, as provided in an embodiment of this application.

[0156] Figure 8 This is a schematic diagram illustrating another application for obtaining a key, provided in an embodiment of this application.

[0157] Figure 9 This is a schematic diagram of the structure of an application device provided in an embodiment of this application;

[0158] Figure 10 This is a schematic diagram of the structure of another application device provided in an embodiment of this application;

[0159] Figure 11 This is a schematic diagram of the hardware structure of an application device provided in an embodiment of this application;

[0160] Figure 12 This is a schematic diagram of the hardware structure of another application device provided in an embodiment of this application. Detailed Implementation

[0161] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0162] To facilitate readers' understanding of this application, some terms will be explained below.

[0163] 1. Classical computer: A physical device that uses binary (0 or 1) to store and process data. Optionally, the application device involved in this application belongs to the category of classical computers.

[0164] 2. Quantum Computer: A quantum computer is a physical device that processes information according to the laws of quantum mechanics and the principles of quantum computing. Quantum computers use qubits to store and process data. Qubits have more states than binary digits. Quantum computers possess the capabilities of classical computers. Quantum computers can solve certain problems that are difficult for classical computers to solve more efficiently. The quantum device involved in this application belongs to the category of quantum computers.

[0165] 3. Classical Network: This refers to a communication network composed of classical computers, such as a digital transmission network consisting of network devices and transmission equipment, which transmits classical digital signals (0 / 1). Network devices include, but are not limited to, routers, switches, firewalls, wireless controllers, wireless access points, personal computers, or servers. Transmission equipment includes, but is not limited to, microwave systems, synchronous digital hierarchy (SDH) equipment, or wavelength division multiplexing (WDM) equipment. In this application, the devices in a classical network (including but not limited to network devices) are collectively referred to as application devices.

[0166] 4. Quantum Networks: These are novel secure communication networks that utilize quantum entanglement and quantum teleportation to bring true security to the network, representing a qualitative leap in computing and science. Communication between nodes via quantum networks can be understood as the sharing of quantum keys between nodes using quantum key distribution technology, and communication based on these quantum keys. Quantum computers can also communicate with each other via quantum networks.

[0167] 5. Quantum attack: refers to attack algorithms that run on quantum computers, such as Shor's algorithm and Grover's algorithm, which can efficiently crack certain passwords.

[0168] 6. Quantum Key Distribution (QKD): This is a secure key distribution technology that utilizes the Heisenberg uncertainty principle and the no-cloning theorem of quantum states in quantum mechanics. In QKD, a quantum device generates a quantum key and transmits it to another quantum device through a quantum network, thus creating a shared quantum key between the two devices. During QKD, the quantum key is transmitted in the form of a quantum state. In a quantum network, QKD is unconditionally secure; even with unlimited computing resources, an eavesdropper cannot crack the quantum key using any decryption algorithm. The security of QKD is based on the unpredictability of the key source and the detectability of channel eavesdropping. The unpredictability of the key source means that the QKD key source is a quantum truly random number, and therefore cannot be predicted. The detectability of channel eavesdropping means that the quantum state sent into the channel satisfies the no-cloning theorem; eavesdropping in the channel will disturb the quantum state, making it detectable by the receiver.

[0169] 7. Quantum key (QK): A symmetric key generated by two communicating parties based on the QKD protocol.

[0170] 8. Public-key algorithms: Also known as asymmetric cryptography algorithms, these are algorithms where the sender and receiver use different keys for encryption and decryption. In asymmetric cryptography, there is a key pair: a private key and a public key. The private key is kept secret by the key pair owner and cannot be published. The public key is published by the key pair holder. Data encrypted with the public key can only be decrypted using the corresponding private key. Data signed with the private key can only be verified using the corresponding public key. Commonly used public-key algorithms include public-key cryptography (PKC) algorithms and post-quantum cryptography (PQC) algorithms. Common public-key cryptography algorithms include RSA and ECC algorithms.

[0171] 9. Post-quantum cryptography: A public-key cryptosystem that includes key generation, encryption, and decryption algorithms. The algorithms included in post-quantum cryptography are collectively called post-quantum cryptographic algorithms. Post-quantum cryptographic algorithms are asymmetric cryptographic algorithms that can run on classical computers. Post-quantum cryptographic algorithms are quantum resistant, meaning they are resistant to quantum attacks and cannot be broken by quantum computers. This quantum resistance does not rely on quantum mechanics but is based on mathematical problems that are currently unbreakable by quantum computers. Post-quantum cryptographic algorithms include subcategories such as those based on lattices, encoding, homology, or multiple variables.

[0172] 10. Symmetric Encryption Algorithms: These are algorithms where the sender and receiver use the same key for encryption and decryption. Commonly used symmetric encryption algorithms include the Advanced Encryption Standard (AES), the SM4 block cipher, and the Data Encryption Standard (DES).

[0173] Because quantum attacks pose a significant threat to traditional asymmetric cryptography techniques (such as public-key cryptography algorithms like RSA and ECC), while symmetric cryptography is less affected by quantum attacks, the security of communication can be guaranteed by configuring symmetric keys for both communication endpoints. Currently, there are two main methods for configuring symmetric keys for communication endpoints.

[0174] One approach involves manually configuring the same key on both communication endpoints. This method is labor-intensive and lacks flexibility in key updates. For example, with the rapid development of network technology, networks are becoming increasingly larger, and the types of application protocols are also increasing. Currently, many application protocols require symmetric keys to be configured on the application device to ensure communication security, such as BGP, LDP, PCEP, Resource Reservation Protocol (RSVP), and Multicast Source Discovery Protocol (MSDP). When there are multiple types of application protocols running on an application device, and / or multiple neighbors for each type of application protocol on multiple application devices, it is necessary to manually configure symmetric keys for each neighbor of each type of application protocol on multiple application devices, and these keys need to be updated periodically. This results in a large workload for key configuration, low key security, and complex key management.

[0175] Another method involves a QKD network providing the same quantum key to both communicating ends. For example, Figure 1 This is a schematic diagram illustrating how an application device obtains a quantum key from a QKD network. For example... Figure 1As shown, the QKD network includes quantum device 1 and quantum device 2, which communicate with each other via the quantum network. The classical network includes application device 1 and application device 2, which communicate with each other via the classical network. Application device 1 communicates with quantum device 1 via the classical network. Application device 2 communicates with quantum device 2 via the classical network. The process of application device 1 and application device 2 obtaining the same quantum key from the QKD network is as follows: Application device 1 requests a quantum key from quantum device 1. Quantum device 1 assigns a quantum key and its key identifier to application device 1. Quantum device 1 synchronizes the assigned quantum key and its key identifier with quantum device 2. Application device 1 synchronizes the key identifier of the quantum key assigned to it by quantum device 1 with application device 2. Application device 2 requests a quantum key from quantum device 2 based on the key identifier provided by application device 1. Quantum device 2 provides the quantum key indicated by the key identifier, i.e., the quantum key assigned to application device 1 by quantum device 1, to application device 2. Thus, application device 1 and application device 2 obtain the same quantum key.

[0176] Providing the same quantum key to both communication endpoints via a QKD network has the following drawbacks. First, since application devices rely on an additional QKD network to obtain keys, this network must be established and maintained, resulting in high operational costs. Second, when a large number of application devices obtain keys from the same QKD network, the key supply performance of the QKD network can easily become a bottleneck, making it difficult to guarantee the reliability of key acquisition for application devices. Third, since application devices communicate with the QKD network through a classical network, a secure channel resistant to quantum attacks needs to be established between the application devices and the QKD network to ensure the security of the key transmission process; establishing and ensuring the security of this channel incurs additional overhead. Fourth, both ends of the application device need to obtain keys across networks; network reliability and latency can affect the real-time nature of key acquisition by the application devices, potentially impacting the normal operation of application protocols on the application devices.

[0177] Based on this, this application provides a technical solution that automatically generates symmetric keys resistant to quantum attacks by deploying symmetric key negotiation and generation capabilities on the application device, without relying on a third-party key service system (such as a QKD network) or manual configuration. The specific technical solution provided by this application is as follows: First, a first application device negotiates a key with a second application device to determine a negotiation key. Both the first and second application devices hold the same negotiation key; that is, the negotiation key is the same symmetric key held by both devices. The first application device uses a key derivation function to generate a target key based on a seed key and key derivation function parameter values, including a random salt value. The random salt value refers to a salt with randomness. Then, the first application device uses the negotiation key to encrypt the key context information to obtain ciphertext of the key context information, which includes the key derivation function parameter values. The first application device sends a key generation request message to the second application device, which includes the ciphertext of the key context information. The key generation request message is used to request the second application device to generate a target key. Accordingly, after receiving the key generation request message from the first application device, the second application device decrypts the ciphertext of the key context information using the negotiated key to obtain the key context information. Then, it uses a key derivation function to generate the target key based on the seed key and the key derivation function parameter values ​​in the key context information. Thus, the first and second application devices generate the same target key. In this application, the communicating parties first determine that they hold the same negotiated key through key negotiation, and then use the negotiated key to encrypt the key context information before transmission, enabling both parties to generate the same target key using the same key context information. On the one hand, this achieves automatic generation of the same target key by both communicating parties. On the other hand, since the key context information used by both parties to generate the target key is transmitted after symmetric encryption using the negotiated key, only the communicating parties holding the negotiated key can decrypt and obtain the key context information. Provided the negotiated key is not leaked or cracked, symmetric encryption can be combined with the key context information transmission process to resist quantum attacks, thereby achieving quantum-resistant security in the target key generation process.

[0178] The following section provides a detailed introduction to this technical solution from multiple perspectives, including application scenarios, methodology, functional modules, system, hardware devices, and software devices.

[0179] The following are examples illustrating the application scenarios of embodiments of this application.

[0180] The application scenarios provided in this application involve multiple application devices. Optionally, the application devices include, but are not limited to, network devices such as routers, switches, or firewalls. Alternatively, the application devices may be terminal devices such as computers, mobile phones, or Internet of Things (IoT) terminals. Or, the application devices may be other devices with communication needs, such as servers or cloud platforms.

[0181] For example, Figure 2 This is a schematic diagram illustrating an application scenario provided in an embodiment of this application. For example... Figure 2 As shown, this application scenario includes application device A and application device B. Optionally, application device A and application device B communicate via a classic network. For example, application device A and application device B communicate based on Transmission Control Protocol / Internet Protocol (TCP / IP).

[0182] Optionally, both application device A and application device B are equipped with a key management module. For example, see [link to example]. Figure 2 Application device A is equipped with a key management module A, and application device B is equipped with a key management module B. The key management modules have key management capabilities, including but not limited to symmetric key negotiation and symmetric key generation capabilities. The key management modules on the application devices are configured to implement the key generation method provided in this application embodiment. For example, the key management modules on the application devices implement the key generation method provided in this application embodiment by running a security protocol. Optionally, the key management modules on the application devices may be called security symmetric key management (SSKM) modules, and the security protocol run by the key management modules may be called security symmetric key protocol (SSKP). This application embodiment does not limit the naming of the key management modules on the application devices or the security protocols they run.

[0183] Optionally, application device A and application device B support one or more of the same application protocols. Applications (APPs) on application device A and application device B perform data transmission or authentication by running the same application protocol. Currently, communication networks can adopt the Open Systems Interconnection (OSI) reference model or the TCP / IP reference model. The OSI reference model is a seven-layer model, dividing the communication network from low to high into the physical layer, data link layer, network layer, transport layer, session layer, presentation layer, and application layer. The TCP / IP reference model is a five-layer model, dividing the communication network from low to high into the physical layer, data link layer, network layer, transport layer, and application layer. The data link layer is also known as the Medium Access Control (MAC) layer. In this application embodiment, the application protocol refers to a protocol for any layer of the communication network, including but not limited to TLS for the transport layer, IPsec for the network layer, and BGP, LDP, or PCEP for the application layer. By configuring symmetric keys for one or more application protocols on application device A and application device B, secure data transmission or secure authentication at the corresponding layer of the communication network can be achieved between application device A and application device B. This application embodiment achieves unified management and distribution of keys by configuring a key management module in the application device. This allows keys required by multiple application protocols to be obtained from the key management module, simplifying key management for each application protocol.

[0184] Optionally, the key management module in the application device can configure symmetric keys for applications on that application device. See, for example... Figure 2 In application device A, key management module A and key management module B in application device B negotiate and generate a symmetric key. Then, key management module A provides this symmetric key to application A in application device A, and key management module B provides this symmetric key to application B in application device B. Furthermore, application A in application device A and application B in application device B can perform secure data transmission or secure authentication based on this symmetric key. Secure data transmission based on the symmetric key means that the sender uses the symmetric key to encrypt the plaintext data to be transmitted to obtain ciphertext, sends the ciphertext to the receiver, and the receiver uses the same symmetric key to decrypt the ciphertext to obtain the plaintext data. Secure authentication based on the symmetric key means that the sender uses the symmetric key to encrypt authentication information to obtain ciphertext authentication information, sends the ciphertext authentication information to the receiver, and the receiver uses the same symmetric key to decrypt the ciphertext authentication information to obtain authentication information, and authenticates the sender (e.g., verifying the sender's legitimacy) based on this authentication information.

[0185] The method flow of the embodiments of this application is illustrated below.

[0186] For example, Figure 3 This is a schematic diagram illustrating the implementation flow of a key generation method 300 provided in an embodiment of this application. For example... Figure 3 As shown, the method 300 includes, but is not limited to, steps 301 to 306. Optionally, the first application device in the method 300 is... Figure 2 In the first application device A, the actions performed by the first application device are, for example, executed by the key management module A within application device A. The second application device in method 300 is... Figure 2 The actions performed by the second application device B are, for example, executed by the key management module B in the application device B.

[0187] Step 301: The first application device determines the negotiated key by negotiating a key with the second application device.

[0188] The first application device and the second application device hold the same negotiation key; that is, the negotiation key is a symmetric key determined by the first and second application devices through key negotiation. After establishing a session connection, the first application device and the second application device perform key negotiation to determine the negotiation key. Optionally, the first application device and the second application device use TCP or TLS as the transport layer protocol to establish the session connection.

[0189] Optionally, the key negotiation process in step 301 may be initiated by the first application device or by the second application device. The following embodiments of this application illustrate this by assuming the key negotiation process in step 301 is initiated by the first application device, for example, the first application device is a client and the second application device is a server. In one possible implementation, step 301 includes steps 3011 to 3013.

[0190] In step 3011, the first application device sends a key negotiation request message to the second application device. The key negotiation request message is used to indicate the public key algorithm supported by the first application device.

[0191] Optionally, the key negotiation request message includes a list of public key algorithms. For ease of description, in this embodiment, the list of public key algorithms in the key negotiation request message is referred to as the first public key algorithm list. The first application device selects supported public key algorithms and carries the algorithm identifiers of the supported public key algorithms in the first public key algorithm list. If the first application device does not support any public key algorithms, the first public key algorithm list is empty. The algorithm identifier may include, for example, the algorithm name, algorithm version, etc., and should be able to uniquely identify the corresponding algorithm.

[0192] Optionally, the first application device and the second application device are pre-configured with their respective supported public key algorithms. The public key algorithms supported by the first application device and the second application device may be the same or different. Optionally, the public key algorithms include, but are not limited to, PKC algorithms and / or PQC algorithms. PKC algorithms include, for example, RSA algorithms and ECC algorithms. PQC algorithms include, for example, lattice-based algorithms, encoding-based algorithms, homologous algorithms, or multivariate-based algorithms.

[0193] After receiving the key negotiation request message from the first application device, the second application device determines the public key algorithm supported by both the second and first application devices based on the public key algorithms supported by the second and first application devices. Then, it continues to execute the following step 3012.

[0194] In step 3012, the second application device sends a key negotiation response message corresponding to the key negotiation request message to the first application device. The key negotiation response message is used to indicate the public key algorithm supported by both the second application device and the first application device.

[0195] Optionally, the key negotiation response message includes a list of public key algorithms. For ease of description, in this embodiment, the list of public key algorithms in the key negotiation response message is referred to as the second public key algorithm list. The second application device selects a public key algorithm that is supported by both the second application device and the first application device, and carries the algorithm identifier of the public key algorithm supported by both the second application device and the first application device in the second public key algorithm list. If neither the second application device nor the first application device supports a public key algorithm, the second public key algorithm list is empty.

[0196] Optionally, the first application device and the second application device are pre-configured with one or more identical keys and symmetric encryption algorithms. The identical keys pre-configured in the first and second application devices refer to the same symmetric keys held by both devices. In this embodiment, the pre-configured key in the application device is called a configuration key, which can also be called a pre-shared key (PSK). Optionally, the length of the configuration key is greater than a length threshold, which can be set according to quantum resistance requirements. By making the length of the configuration key greater than the length threshold, the configuration key acquires quantum resistance capabilities. The longer the configuration key, the stronger its quantum resistance capabilities.

[0197] In one possible implementation, the first application device and the second application device each store one or more configuration keys. The first application device encrypts the negotiation request information using the first configuration key to obtain ciphertext of the negotiation request information. This negotiation request information includes a first public key algorithm list. The first public key algorithm list carries the algorithm identifiers of the public key algorithms supported by the first application device. The first configuration key is any one of the one or more configuration keys stored in the first application device. In this implementation, the key negotiation request message includes the ciphertext of the negotiation request information and the key identifier of the first configuration key. Accordingly, after receiving the key negotiation request message from the first application device, the second application device retrieves the first configuration key from the one or more configuration keys stored in the second application device based on the key identifier carried in the key negotiation request message, and then uses the first configuration key to decrypt the ciphertext of the negotiation request information carried in the key negotiation request message to obtain the negotiation request information, thereby determining the public key algorithms supported by the first application device.

[0198] Optionally, the second application device encrypts the negotiation response information using the first configuration key to obtain ciphertext of the negotiation response information. This negotiation response information includes a second public key algorithm list. The second public key algorithm list carries algorithm identifiers of public key algorithms supported by both the second and first application devices. In this implementation, the key negotiation response message includes ciphertext of the negotiation response information. Accordingly, after receiving the key negotiation response message from the second application device, the first application device decrypts the ciphertext of the negotiation response information carried in the key negotiation response message using the first configuration key to obtain the second public key algorithm list, thereby determining the public key algorithms supported by both the second and first application devices. This embodiment uses the example of the second application device encrypting the negotiation response information using the first configuration key (i.e., the configuration key used by the first application device to encrypt the negotiation request information). Of course, the second application device can also use a different configuration key than the first configuration key to encrypt the negotiation response information. In this case, the key negotiation response message also includes the key identifier of the configuration key used by the second application device to encrypt the negotiation response information, so that the first application device can obtain the corresponding configuration key to decrypt the ciphertext of the negotiation response information.

[0199] In this embodiment of the application, the first application device and the second application device use a configuration key to encrypt and decrypt the above-mentioned negotiation request information and / or negotiation response information using a symmetric encryption algorithm. That is, the first application device and the second application device use a configuration key to perform symmetric encryption transmission of the interactive information in the key negotiation process, which can resist quantum attacks in the information transmission process, thereby achieving quantum-resistant security in the negotiation key generation process.

[0200] Optionally, the aforementioned negotiation request information may also include the algorithm identifier of the key negotiation algorithm used by the first application device and the second application device for key negotiation. Optionally, the key negotiation algorithm includes, but is not limited to, the KEM algorithm and / or the ECDH key exchange algorithm.

[0201] After receiving the key negotiation response message from the second application device, the first application device continues to execute the following step 3013.

[0202] In step 3013, if the public key algorithm supported by both the second application device and the first application device is not empty, the first application device performs key negotiation with the second application device based on the public key algorithm supported by both the second application device and the first application device through a key negotiation algorithm to generate a negotiation key.

[0203] Both the second application device and the first application device support public key algorithms that are not empty, meaning there is an overlap between the public key algorithms supported by the second application device and the first application device. Accordingly, if both the second and first application devices support public key algorithms that are not empty, the second application device, based on the public key algorithms supported by both devices, responds to the first application device by performing key negotiation through a key negotiation algorithm to generate a negotiated key.

[0204] It is worth noting that when the first and second application devices generate a negotiation key through key negotiation based on a public-key algorithm supported by both, in order to improve the quantum attack resistance of the negotiation key generated by the first and second application devices, i.e., to reduce the possibility of the negotiation key being cracked by a quantum attack, the first and second application devices should at least meet one of the following configuration conditions: The first and second application devices pre-store the same configuration key and both support symmetric encryption, wherein the length of the configuration key is greater than a length threshold; the public-key algorithms supported by both the first and second application devices include the PQC algorithm. When the first and second application devices pre-store the same configuration key and both support symmetric encryption, the first and second application devices use the configuration key to perform symmetric encryption transmission of the interactive information during the key negotiation process, achieving quantum security in the negotiation key generation process. When the public-key algorithms supported by both the first and second application devices include the PQC algorithm, since the PQC algorithm itself has a certain degree of quantum attack resistance, the negotiation key generated based on the PQC algorithm also has a certain degree of quantum attack resistance, i.e., it can also achieve quantum security in the negotiation key generation process. Of course, if both the first and second application devices meet both configuration conditions, the resulting negotiated key will be more resistant to quantum attacks compared to if only one condition is met. In practical applications, the application devices can be configured according to the required security level.

[0205] Optionally, the public key algorithm supported by both the first application device and the second application device includes the first public key algorithm. The implementation process of key negotiation between the first application device and the second application device using the KEM algorithm as the key negotiation algorithm includes the following steps A1 to A3.

[0206] In step A1, the first application device generates a public-private key pair based on the first public-key algorithm, and encrypts the public key in the public-private key pair using a symmetric key kq before sending it to the second application device.

[0207] The symmetric key is the same key held by the first application device and the second application device. For example, in the initial stage of key negotiation, the same configuration key stored in the first application device and the second application device is used as the symmetric key.

[0208] In step A2, the second application device uses the symmetric key kq to decrypt and obtain the public key, generates a key key locally, and uses the public key to encrypt the key key to obtain key'. Then, it uses the symmetric key kq to encrypt key' and sends it to the first application device.

[0209] Further, the second application device generates a new symmetric key based on the key key and the symmetric key kq. Optionally, the second application device mixes the key key and the symmetric key kq to obtain a new symmetric key. For example, the second application device uses a key derivation function (KDF) to generate a new symmetric key based on the key key and the symmetric key kq.

[0210] In step A3, the first application device first uses the symmetric key kq to decrypt and obtain key', and then uses the private key in the generated public-private key pair to decrypt key' to obtain the key key.

[0211] Further, the first application device generates a new symmetric key based on the key key and the symmetric key kq. Optionally, the first application device mixes the key key and the symmetric key kq to obtain a new symmetric key. For example, the first application device uses the same key derivation function as the second application device to generate a new symmetric key based on the key key and the symmetric key kq.

[0212] Optionally, the public key algorithm supported by both the first application device and the second application device includes the first public key algorithm. The implementation process of key negotiation between the first application device and the second application device using the ECDH algorithm as the key negotiation algorithm includes the following steps B1 to B3.

[0213] In step B1, the first application device generates a first public-private key pair based on the first public-key algorithm. The first public-private key pair includes a first public key and a first private key. The first public key is encrypted using a symmetric key kq and then sent to the second application device.

[0214] The symmetric key is the same key held by the first application device and the second application device. For example, in the initial stage of key negotiation, the same configuration key stored in the first application device and the second application device is used as the symmetric key.

[0215] Optionally, the private key in the public-private key pair generated by the first application device is a random number, and the public key is calculated based on the private key and the base point. Before step B1 is executed, the first application device and the second application device need to agree in advance on the elliptic curve parameters to be used, including but not limited to the elliptic curve equation, modulus, and base point. The base point is a fixed point on the elliptic curve.

[0216] In step B2, the second application device uses the symmetric key kq to decrypt and obtain the first public key held by the first application device. Based on the first public key algorithm, it generates a second public-private key pair, which includes the second public key and the second private key. The second public key is then encrypted using the symmetric key kq and sent to the first application device. The second application device calculates the shared key based on the second private key and the first public key.

[0217] Further, the second application device generates a new symmetric key based on the shared key and the symmetric key kq. Optionally, the second application device mixes the shared key and the symmetric key kq to obtain a new symmetric key. For example, the second application device uses a key derivation function to generate a new symmetric key based on the shared key and the symmetric key kq.

[0218] In step B3, the first application device uses the symmetric key kq to decrypt and obtain the second public key held by the second application device, and calculates the shared key based on the first private key and the second public key.

[0219] Further, the first application device generates a new symmetric key based on the shared key and the symmetric key kq. Optionally, the first application device mixes the shared key and the symmetric key kq to obtain a new symmetric key. For example, the first application device uses the same key derivation function as the second application device to generate a new symmetric key based on the shared key and the symmetric key kq.

[0220] Optionally, if both the second application device and the first application device support multiple public key algorithms, the first and second application devices sequentially perform key negotiation using key negotiation algorithms based on these multiple public key algorithms, and generate a final negotiation key based on the multiple keys negotiated using these multiple public key algorithms. For example, if both the second and first application devices support a first public key algorithm and a second public key algorithm, the implementation process of step 3013 above includes steps 3013A to 3013C.

[0221] In step 3013A, the first application device negotiates a key with the second application device based on the first public key algorithm and through the first key negotiation algorithm to generate the first key.

[0222] Accordingly, the second application device, based on the first public key algorithm, responds to the first application device by performing key negotiation through the first key negotiation algorithm to generate the first key.

[0223] Optionally, the first key negotiation algorithm is the KEM algorithm, and the key negotiation process between the first application device and the second application device based on the first public key algorithm can refer to steps A1 to A3 above. In this key negotiation process, for example, the same configuration key stored in the first application device and the second application device is used as the symmetric key kq, the first key generated by the first application device is the key key in step A3 above, and the first key generated by the second application device is the key key in step A2 above.

[0224] Alternatively, the first key negotiation algorithm may be the ECDH algorithm, and the key negotiation process between the first application device and the second application device based on the first public key algorithm can refer to steps B1 to B3 above. In this key negotiation process, for example, the same configuration key stored in the first and second application devices may be used as the symmetric key kq. The first key generated by the first application device is the shared key in step B3 above, and the first key generated by the second application device is the shared key in step B2 above.

[0225] In step 3013B, the first application device negotiates a key with the second application device based on the second public key algorithm and through the second key negotiation algorithm to generate a second key.

[0226] Accordingly, the second application device, based on the second public key algorithm, responds to the first application device by performing key negotiation using the second key negotiation algorithm to generate a second key. The second key negotiation algorithm may be the same as or different from the first key negotiation algorithm.

[0227] Optionally, the second key negotiation algorithm is the KEM algorithm. The key negotiation process between the first application device and the second application device based on the second public key algorithm can refer to steps A1 to A3 above. In this key negotiation process, for example, a new symmetric key generated based on the first key generated in step 3013A above and the same configuration key stored on the first and second application devices is used as the symmetric key kq. The second key generated by the first application device is the key in step A3 above, and the second key generated by the second application device is the key in step A2 above.

[0228] Alternatively, the first key negotiation algorithm is the ECDH algorithm, and the key negotiation process between the first application device and the second application device based on the second public key algorithm can refer to steps B1 to B3 above. In this key negotiation process, for example, a new symmetric key generated based on the first key generated in step 3013A above and the same configuration key stored on the first and second application devices is used as the symmetric key kq. The second key generated by the first application device is the shared key in step B3 above, and the second key generated by the second application device is the shared key in step B2 above.

[0229] In step 3013C, the first application device generates a negotiation key based on the first key and the second key.

[0230] Accordingly, the second application device generates a negotiation key based on the first key and the second key.

[0231] Optionally, in one implementation of step 3013C, the first application device generates a new symmetric key based on the first key and the symmetric key used to encrypt information transmitted during the generation of the first key. This new symmetric key is then used to encrypt information transmitted during the generation of the second key. The first application device then generates a negotiation key based on the second key and the new symmetric key. In other words, the key generated in the previous key negotiation can be used to encrypt information transmitted during the subsequent key negotiation, and the newly generated key is mixed with the previous key to update the symmetric key. This process is iterated until all public key algorithms have been negotiated, and the latest symmetric key is used as the negotiation key.

[0232] For example, if both the first and second application devices support n public-key algorithms, then the first and second application devices will perform n key negotiations, where n is an integer greater than 1. The first and second application devices store the same configuration key ke. During the first key negotiation between the first application device and the second application device, let the symmetric key used to encrypt the transmitted information be kq = ke, and record the key generated in the first key negotiation as key1; during the second key negotiation between the first application device and the second application device, let the symmetric key used to encrypt the transmitted information be kq = KDF(kq,key1), and record the key generated in the second key negotiation as key2; during the third key negotiation between the first application device and the second application device, let the symmetric key used to encrypt the transmitted information be kq = KDF(kq,key2), and record the key generated in the third key negotiation as key3; and so on. During the nth key negotiation between the first application device and the second application device, let the symmetric key used to encrypt the transmitted information be kq = KDF(kq,keyn-1), and record the key generated in the nth key negotiation as keyn; finally, KDF(kq,keyn) is used as the negotiation key. Here, let kq = KDF(kq,keym), which means updating kq with a new key generated by the key derivation function based on the original kq and keym, where m is a positive integer.

[0233] This application does not limit the implementation method of the first application device and the second application device generating the negotiation key based on the first key and the second key. For example, the first application device and the second application device concatenate the first key and the second key respectively to obtain the same negotiation key. Alternatively, the first application device and the second application device respectively extract the same segment of the first key and the same segment of the second key, and then concatenate the two extracted key segments to obtain the same negotiation key.

[0234] In this embodiment, when both the first and second application devices support multiple public key algorithms, the final negotiation key is generated by mixing multiple keys obtained through key negotiation based on these algorithms. This ensures that the negotiation key cannot be cracked as long as one of the keys used to generate it remains unbroken, thus improving its security. Furthermore, when both the first and second application devices support at least one PKC algorithm and at least one PQC algorithm, the security level of the negotiation key is even higher.

[0235] Optionally, the first application device and the second application device automatically update the negotiated key they hold. When the negotiated key meets the key update conditions, the first application device, based on a public key algorithm supported by both the first and second application devices, re-negotiates the key with the second application device using a key negotiation algorithm to obtain the updated negotiated key. The key update conditions include: the generation time of the negotiated key reaches the aging time, and / or, the number of times the negotiated key has been used reaches a threshold.

[0236] Optionally, if the first application device and the second application device use the KEM algorithm as the key negotiation algorithm, the first application device and the second application device may re-negotiate the key. This can be achieved by the second application device locally generating a new key in step A2 above, and then generating a new negotiation key based on this new key. Alternatively, the first application device and the second application device can generate a new negotiation key based on the new key and the old negotiation key; that is, the old negotiation key can be used as the basis for generating the new negotiation key.

[0237] Alternatively, if the first and second application devices use the ECDH algorithm as the key negotiation algorithm, they can renegotiate the key. This could involve the first and / or second application devices generating a new public-private key pair based on the same public-key algorithm, then generating a new shared key based on the new public-private key pair, and further generating a new negotiation key based on this new shared key. Optionally, the first and second application devices can generate a new negotiation key based on the new shared key and the old negotiation key; that is, the old negotiation key can be used as the basis for generating the new negotiation key.

[0238] In this embodiment of the application, by periodically updating the negotiation key held by the first application device and the second application device or updating it according to the number of times it is used, the security of key generation can be improved, and the security of all subsequently generated keys can be avoided if the negotiation key is leaked once.

[0239] Optionally, after receiving the key negotiation response message from the second application device, if both the first and second application devices support no public key algorithms (i.e., the public key algorithms supported by the second and first application devices do not overlap), the first application device uses the second configuration key as the negotiation key. The second configuration key is any one of one or more configuration keys stored in the first application device. Correspondingly, the second application device also uses the second configuration key as the negotiation key. The length of the second configuration key is greater than a length threshold. Since the configuration keys are pre-stored on both the first and second application devices and typically do not leave the devices, there is no risk of the configuration keys being compromised due to information leakage or quantum attacks during the negotiation process. When using the configuration key as the negotiation key, as long as the storage security of the configuration keys on both the first and second application devices is ensured—that is, the configuration keys on both devices are not leaked—the security of the negotiation key can be achieved. Furthermore, using a configuration key with a length greater than the length threshold as the negotiation key makes the configuration key resistant to quantum attacks.

[0240] Alternatively, considering the quantum security issues in the subsequent target key generation process, if both the second and first application devices support an empty public key algorithm, then the first and second application devices will end the key negotiation process, for example, by disconnecting the session connection, which means that the key generation fails.

[0241] Optionally, after the first application device and the second application device determine the negotiated key through key negotiation, the first application device and / or the second application device further initiate a key generation process. It is worth noting that the initiator of the key generation process and the initiator of the key negotiation process can be the same or different. For example, the key negotiation process is initiated by the first application device, and the key generation process is initiated by the second application device. Alternatively, both the key negotiation process and the key generation process are initiated by the first application device. The following embodiments of this application illustrate the key generation process initiated by the first application device, as shown in steps 302 to 306.

[0242] Step 302: The first application device uses a key derivation function to generate a target key based on the seed key and the key derivation function parameter values, which include a random salt value.

[0243] Here, a random salt value refers to a salt value that possesses randomness. For example, the first application device uses a generated random number as a random salt value for key derivation. The randomness of the salt value is to ensure that the entropy value of the derived key does not decrease. Optionally, the key derivation function parameter values ​​may also include the number of iterations.

[0244] Optionally, the key derivation function used by the first application device includes, but is not limited to, a hash function or a password-based key derivation function (PBKDF2). The key derivation function is used to derive one or more keys from a secret value using a pseudo-random function. The secret value is the original key, and the derived key is the derivation key. For example, the use of the key derivation function is represented as: DK = KDF(Key, Salt, Iterations). Where DK is the derivation key, KDF is the key derivation function, Key is the original key, Salt is the salt value, and Iterations refers to the number of iterations. In conjunction with step 302, the derivation key DK is the target key, the original key Key is the seed key, and the salt value Salt is a random salt value.

[0245] Step 303: The first application device uses the negotiated key to encrypt the key context information to obtain the key context information ciphertext, which includes the key derivation function parameter values.

[0246] The key context information refers to information related to the key, including key generation information. Key generation information refers to information related to the key generation process, including the parameter values ​​of the key derivation function used by the first application device to generate the target key. Optionally, the key generation information may also include the function identifier (e.g., function name) of the key derivation function used by the first application device to generate the target key.

[0247] Optionally, the key context information may also include key attribute information and / or key application information. Key attribute information refers to information related to the key itself, such as one or more of the following: the key identifier assigned to the target key by the first application device, the key length of the target key, or the aging time of the target key. Key application information refers to information related to the object on which the key is applied, such as the protocol identifier of the application protocol that requests and applies the target key. Optionally, the protocol identifier of the application protocol includes the protocol type of the application protocol and / or the port number corresponding to the application protocol.

[0248] Step 304: The first application device sends a key generation request message to the second application device. The key generation request message includes the key context information ciphertext.

[0249] The key generation request message is used to request the second application device to generate the target key.

[0250] Optionally, if in step 301 above, the public key algorithm supported by both the second application device and the first application device is empty, and the first application device uses the second configuration key as the negotiation key, then the key generation request message also includes the key identifier of the second configuration key. Accordingly, after receiving the key generation request message from the first application device, the second application device retrieves the second configuration key from one or more configuration keys stored in the second application device based on the key identifier carried in the key generation request message, and uses the second configuration key as the negotiation key.

[0251] After receiving the key generation request message from the first application device, the second application device continues to execute the following steps 305 to 306.

[0252] Step 305: The second application device uses the negotiated key to decrypt the key context information ciphertext to obtain the key context information.

[0253] Optionally, after the first application device and the second application device determine the negotiation key through key negotiation, the first application device and the second application device can announce their respective seed keys. Typically, the application device that initiates the key generation process announces its seed key to the other. Optionally, in this embodiment, the first application device announces the seed key to the second application device. The first application device can announce the seed key to the second application device before generating the target key. Alternatively, the first application device can also carry the seed key in the key context information and announce the seed key to the second application device through a key generation request message. After obtaining the seed key announced by the first application device, the second application device executes step 306. Of course, in this embodiment, the seed key used by the first application device and the second application device can also be a seed key from the second application device, that is, a key seed announced by the second application device to the first application device; this embodiment does not limit this.

[0254] Step 306: The second application device uses a key derivation function to generate a target key based on the seed key and the parameter values ​​of the key derivation function.

[0255] In step 306, the second application device uses the same key derivation function as the first application device to generate the target key based on the same seed key and the same key derivation function parameter values. The implementation of step 306 can be referenced to the implementation of step 302 described above, and will not be repeated here.

[0256] Optionally, if the key context information includes a key identifier assigned to the target key by the first application device, the second application device stores the target key and the key identifier of the target key after generating the target key for subsequent use.

[0257] In this embodiment, the first application device and the second application device first determine that they hold the same negotiation key through key negotiation. They then use this negotiation key to encrypt the key context information before transmission, enabling the first and second application devices to generate the same target key using the same key context information. On one hand, this achieves automatic generation of the same target key by the first and second application devices. On the other hand, since the key context information used by the first and second application devices to generate the target key is transmitted after symmetric encryption using the negotiation key, only the first and second application devices holding the negotiation key can decrypt it. Provided the negotiation key is not leaked or cracked, symmetric encryption can be combined with the key context information transmission process to resist quantum attacks, thereby achieving quantum-resistant security in the target key generation process. When the first and second application devices generate the negotiation key through key negotiation based on a public-key algorithm supported by both parties, this embodiment configures the first and second application devices to pre-store the same configuration key and both support symmetric encryption. This allows the first and second application devices to use the configuration key to symmetrically encrypt the interactive information during the key negotiation process, achieving quantum-resistant security in the negotiation key generation process. And / or, by configuring public key algorithms, including PQC, supported by both the first and second application devices, the negotiation key generated based on the PQC algorithm possesses a certain degree of resistance to quantum attacks, thus achieving quantum security in the negotiation key generation process. This ensures the negotiation key is quantum-resistant, reducing the possibility of it being cracked by quantum attacks. When the first and second application devices use the same stored configuration key as the negotiation key, since the configuration key is pre-stored on both devices, it is not at risk of being cracked due to information leakage or quantum attacks during the negotiation process. When using the configuration key as the negotiation key, as long as the storage security of the configuration key on both devices is ensured—that is, the configuration key on both devices is not leaked—the security of the negotiation key can be achieved. Furthermore, using a configuration key with a length greater than a certain threshold as the negotiation key further enhances its resistance to quantum attacks.

[0258] Optionally, after generating the target key, the second application device sends a key generation response message corresponding to the key generation request message to the first application device. This key generation response message indicates that the second application device has generated the target key. The second application device then sets the status of the target key to available.

[0259] Optionally, the application device that initiates the key generation process is responsible for key allocation and / or key state synchronization. In this embodiment, after the first application device and the second application device generate the target key, the first application device that initiates the key generation process is responsible for the allocation of the target key and / or the synchronization of the target key state.

[0260] In the first implementation, the first application device generates the target key upon being triggered by a key request from an application. In this implementation, step 302 is implemented as follows: in response to receiving a key acquisition instruction from application A1, the first application device uses a key derivation function to generate the target key based on the seed key and the parameter values ​​of the key derivation function. The key acquisition instruction includes the device identifier of the second application device, indicating the acquisition of a symmetric key with the second application device. Correspondingly, after receiving a key generation response message from the second application device, i.e., after determining that the second application device has generated the target key, the first application device allocates the target key and its key identifier to application A1. Optionally, the device identifier may be, for example, the device's IP address.

[0261] In the first implementation, since the first application device needs to allocate the target key to the application A1 that applied for the key in real time after generating the target key, that is, the target key is in the state of being allocated, there is no need to synchronize the state of the target key with the second application device.

[0262] In the second implementation, the first application device pre-generates a target key and stores it locally, then allocates the locally stored target key to the application requesting the key. In this implementation, upon receiving a key generation response message from the second application device—that is, after determining that the second application device has generated the target key—the first application device sets the target key's status to available and stores the target key and its key identifier. Optionally, after generating the target key, the first application device sets the target key's status to a negotiation state before receiving the key generation response message from the second application device. Furthermore, in this implementation, the target key generated by the first application device can be configured with an aging time.

[0263] Optionally, if a key retrieval instruction is received from application A1, the first application device allocates a stored target key and a key identifier for the target key to application A1. The key retrieval instruction includes a device identifier for the second application device and indicates the retrieval of a symmetric key between the first and second application devices.

[0264] Optionally, in the second implementation, after the first application device allocates the stored target key and its key identifier to application A1, it sends a key status synchronization request message to the second application device. This message includes the key identifier of the target key and indicates that the first application device has allocated the target key. Upon receiving the key status synchronization request message from the first application device, the second application device sets the target key's status to allocated. The second application device then sends a key status synchronization response message corresponding to the key status synchronization request message to the first application device, indicating that it has set the target key's status to allocated. Upon receiving the key status synchronization response message from the second application device, the first application device sets the target key's status to allocated. In this implementation, since the first application device pre-generates and stores the target key locally, by synchronizing the target key's status with the second application device, it can distinguish and identify whether the target key has been allocated, thereby preventing the target key from being allocated repeatedly. Optionally, after the first application device allocates the target key to application A1, it sets the status of the target key to "allocation in progress" before receiving a key status synchronization response message from the second application device.

[0265] Optionally, the first application device encrypts the key identifier of the target key using the negotiated key and includes it in the key state synchronization request message. Correspondingly, the second application device decrypts the information in the key state synchronization request message using the negotiated key to obtain the key identifier of the target key.

[0266] Optionally, the key acquisition instruction includes, in addition to the device identifier of the second application device, the device identifier of the application device where application A1 resides and / or the protocol identifier of the application protocol running application A1. When the key acquisition instruction includes the device identifier of the application device where application A1 resides and the device identifier of the second application device, the key acquisition instruction instructs the acquisition of the symmetric key between the application device where application A1 resides and the second application device. When the key acquisition instruction includes the protocol identifier of the application protocol running application A1 and the device identifier of the second application device, the key acquisition instruction instructs the acquisition of the symmetric key between application A1 and the second application device, as well as the specific application protocol to which the symmetric key is applied. When the key acquisition instruction includes the protocol identifier of the application protocol running application A1, the device identifier of the application device where application A1 resides, and the device identifier of the second application device, the key acquisition instruction instructs the acquisition of the symmetric key between the application device where application A1 resides and the second application device, as well as the specific application protocol to which the symmetric key is applied.

[0267] Optionally, after the first application device allocates the target key to application A1, it binds the target key with the information in the key acquisition instruction from application A1 to identify the allocation result of the target key. Alternatively, the key status synchronization request sent by the first application device to the second application device may also include the information in the key acquisition instruction; similarly, the second application device binds the target key with the information in the key acquisition instruction to identify the allocation result of the target key.

[0268] Optionally, in the first or second embodiment described above, application A1 is an application on the first application device. Alternatively, application A1 is an application on a third application device, which is different from the first application device. That is, in this embodiment, in addition to automatically configuring symmetric keys for its own applications, the application device can also configure symmetric keys for applications on other application devices.

[0269] Optionally, embodiments of this application can provide corresponding key allocation methods for different application scenarios where applications request keys. The following description uses three application scenarios for application key requests as examples.

[0270] In the first application scenario, the application actively requests to obtain a key. In this scenario, the key acquisition instruction from application A1 includes the device identifier of the second application device and a key aging time. The key aging time specifies the aging period for the key allocated to application A1. Combining the first or second implementation method described above, after the first application device allocates the target key and its key identifier to application A1, the first application device sends first key allocation information to the second application device. This first key allocation information includes the key identifier of the target key and a key aging time. This key aging time is used by the second application device to age the target key. Accordingly, after receiving the first key allocation information from the first application device, if the second application device receives a key acquisition request from application B1 on the second application device within the key aging time, and this request includes the key identifier of the target key, the second application device allocates the target key to application B1.

[0271] It is worth noting that in the first application scenario, since application B1 on the second application device actively requests to obtain the target key, the second application device can determine that the target key has been allocated after allocating the target key to application B1 based on the key acquisition request from application B1. Therefore, when the second implementation method described above is applied to the first application scenario, the first application device does not need to send a key status synchronization request message to the second application device.

[0272] For example, in conjunction with references Figure 2 The application scenarios shown Figure 4 This is a schematic diagram of a key application process provided in an embodiment of this application. For example... Figure 4 As shown, in step S11, application A provides the device identifier of application device B and the key aging time to the key management module A to request a key. In step S12, key management module A synchronizes the key identifier and key aging time of the target key with key management module B. In step S13, key management module A allocates the target key and its key identifier to application device A. In step S14, application A synchronizes the key identifier of the target key with application B. In step S15, application B provides the key identifier of the target key to key management module B to request a target key. In step S16, key management module B allocates the target key to application B. Thus, application A and application B obtain the same target key. Furthermore, key management modules A and B age the target key based on the key aging timeout. It is worth noting that... Figure 4 The order of steps in the illustrated key request process is for illustrative purposes only. For example, there is no need to specify the execution order of S11 and S12; that is, S12 can be executed after S11, or S12 can be executed before S11, or S11 and S12 can be executed simultaneously. In the latter two cases, the key aging time of the target key can be set by the key management module A.

[0273] In the second application scenario, the application requests a batch of keys for pre-fetching. In this scenario, the key acquisition instruction from application A1 includes a device identifier of the second application device, a key request identifier, and a key aging time. The key aging time specifies the aging time for the keys allocated to application A1. Optionally, the key acquisition instruction also includes a key request quantity. The key request identifier, key aging time, and key request quantity can be configured in application A1. In conjunction with the first or second implementation method described above, one implementation of the first application device allocating a target key and its key identifier to application A1 includes: the first application device allocating a key list to application A1, the key list including multiple key groups. The number of key groups in the key list is, for example, the number of key requests indicated by the key acquisition instruction. Each key group includes a key and its key identifier. The target key and its key identifier are one of the multiple key groups. Further, the first application device sends second key allocation information to the second application device. This second key allocation information includes a key request identifier, key identifiers in the key list, and a key aging time. The key aging time is used by the second application device to age out the key list, and the key request identifier is used by the second application device to allocate the key list to application B2. Application B2 is an application on the second application device configured with the key request identifier. Accordingly, after receiving the second key allocation information from the first application device, if the second application device determines that application B2 on the second application device is configured with the key request identifier carried in the second key allocation information before the key aging time expires, the second application device allocates the key indicated by the key identifier list carried in the second key allocation information to application B2.

[0274] For example, in conjunction with references Figure 2 The application scenarios shown Figure 5 This is a schematic diagram of another key application process provided in an embodiment of this application. For example... Figure 5As shown, in step S21, application A provides the key management module A with the device identifier of application device B, key request identifier, number of key requests, and key aging time to request multiple keys. In step S22, key management module A synchronizes the key request identifier, key identifiers in the key list, and key aging time with key management module B. In step S23, key management module A allocates a key list to application device A, which includes multiple keys and their respective key identifiers. In step S24, application B provides the configured key request identifier to key management module B. In step S25, key management module B allocates the key list corresponding to the key request identifier to application B. At this point, application A and application B obtain the same key list. In step S26, application A selects key M from the local key list, synchronizes the key identifier of key M with application B, and application B obtains key M from the local key list based on the key identifier of key M. At this point, application A and application B obtain the same key M. Additionally, key management modules A and B age the key list based on the key aging time. It is worth noting that... Figure 5 The order of steps in the illustrated key application process is for illustrative purposes only. For example, S24 can be executed before S25, without being restricted to the execution order of S24 and S21 to S23.

[0275] Optionally, the first and second application scenarios described above are applicable to application protocols capable of negotiating and synchronizing key identifiers. For example, in the first and second application scenarios, the application protocol running application A1 includes, but is not limited to, IPSec or TLS protocols. Further, after application A1 and application B1 obtain the symmetric key, they perform encrypted data transmission based on that symmetric key.

[0276] The third application scenario involves application subscription keys. In this scenario, the key acquisition instruction from application A1 includes the device identifier of the second application device and the protocol identifier of the application protocol running application A1. Combining the first or second implementation method described above, after the first application device allocates the target key and its key identifier to application A1, the first application device sends third key allocation information to the second application device. This third key allocation information includes the key identifier and protocol identifier of the target key. The protocol identifier is used by the second application device to allocate the target key to application B3. Application B3 is an application on the second application device that subscribes to the key corresponding to this protocol identifier. Accordingly, after receiving the third key allocation information from the first application device, the second application device allocates the target key to application B3.

[0277] Optionally, the protocol identifier of the application protocol includes the protocol type of the application protocol and / or the port number corresponding to the application protocol. Optionally, the key retrieval instruction from application A1 includes, in addition to the protocol identifier of the application protocol running by application A1, the source IP address and / or destination IP address of the session connection on which application A1 runs the application protocol. The information carried in the key retrieval instruction can be collectively referred to as session information, which typically includes one or more of the five-tuple information.

[0278] In the third application scenario, application B3 initiates the key subscription first. The subscription conditions include a protocol identifier, used to specify the key corresponding to that protocol identifier. The subscription conditions provided by application B3 are typically a subset of the information in the key acquisition instruction from application A1. Optionally, the subscription conditions provided by application B3 are the same as the information in the key acquisition instruction from application A1. Taking application A1 as an application on the first application device, and application A1 running the application protocol BGP as an example, the key acquisition instruction includes a five-tuple of information, where the source IP address is the IP address of the first application device, the destination IP address is the IP address of the second application device, the transport layer protocol is TCP, and the source and destination port numbers are 179 (BGP port number). The subscription conditions provided by application B3 include the BGP port number.

[0279] For example, in conjunction with references Figure 2 The application scenarios shown Figure 6 This is a schematic diagram of another key application process provided in an embodiment of this application. For example... Figure 6 As shown, in step S31, application B sends subscription conditions to key management module B, which include a protocol identifier. In step S32, application A provides session information to key management module A, including the device identifier and protocol identifier of application device B, to request a key. In step S33, key management module A synchronizes the key identifier and protocol identifier of the target key with key management module B. In step S34, key management module B pushes the target key, its key identifier, and protocol identifier to application B according to the subscription conditions. In step S35, key management module A allocates the target key and its key identifier to application device A. At this point, application A and application B obtain the same target key. In step S36, application A sends an authentication request to application B, which includes a protocol identifier. Application B uses the protocol identifier in the authentication request to find the corresponding target key and further completes authentication based on the target key. It is worth noting that... Figure 6The order of steps in the illustrated key application process is for illustrative purposes only. For example, there is no need to limit the execution order of S34 and S35. That is, S35 can be executed after S34, or S35 can be executed before S34, or S34 and S35 can be executed simultaneously.

[0280] Optionally, the third application scenario described above applies to application protocols that do not have the capability to negotiate and synchronize key identifiers. For example, in this third application scenario, the application protocol running on application A1 includes, but is not limited to, BGP, LDP, or PCEP. Further, after application A1 and application B1 obtain the symmetric key, they perform business protocol authentication based on that symmetric key.

[0281] Optionally, the key management module in the application device provides corresponding interfaces for different key acquisition methods. For example, for the first application scenario mentioned above, the key management module interacts with the application through interface 1; for the second application scenario, it interacts with the application through interface 2; and for the third application scenario, it interacts with the application through interface 3, thus meeting the different key application requirements. Here, the interfaces provided by the key management module typically refer to logical interfaces.

[0282] This application provides corresponding key allocation methods to address the differences in key application across different application protocols. It supports a wide range of application protocols with minimal impact and high feasibility. For example, for the IPsec protocol, the key negotiation process can be replaced with the process in this application embodiment where both application devices negotiate to generate a target key, which is then injected into the session as the session key.

[0283] Optionally, the application device provided in this application embodiment includes a key management module. This key management module performs key management functions of the application device, including but not limited to key negotiation, key generation, and key distribution. For example, in conjunction with the first or second embodiment described above, the first application device receives a key acquisition instruction from application A1. Specifically, the key management module receives a key acquisition instruction from the first application, and this key acquisition instruction includes the device identifier of the second application device. Then, based on the key acquisition instruction, the key management module acquires one or more keys that are the same as those held by the key management module and the second application device (the key management module in the second application device), and then distributes these one or more keys to the first application.

[0284] Optionally, the source of the key held by the key management module includes one or more of the following: a key generated by the key management module; a key imported into the key management module; a key obtained by the key management module from the key service platform; or a key obtained by the key management module by mixing the generated key with the key obtained from the key service platform.

[0285] Optionally, the key management module in the application device supports multiple working modes, with different key sources in each mode. The key management module can switch between different working modes to suit various application scenarios. The following explanation uses the following five working modes supported by the key management module in the application device as an example.

[0286] In the first operating mode, the key held by the key management module is generated by the key management module itself. The method by which the key management module generates keys can be referenced from the method described in the above embodiment where the application device generates keys. This first operating mode can be used as the default mode for the key management module.

[0287] The second working mode, also known as the import mode, involves importing keys held by the key management module. This can be done through methods such as importing keys from key files or offline key filling. Optionally, when allocating keys, the key management module synchronizes the key status with other communication parties holding the same keys.

[0288] The third working mode, also known as the pass-through mode, involves the key management module receiving keys from a key service platform (such as a QKD network). The application obtains the keys from the key service platform through the key management module. For example, Figure 7 This is a schematic diagram illustrating an application obtaining a key according to an embodiment of this application. Figure 7As shown, in step S41, application A requests a key from key management module A, and key management module A requests a key from quantum device A, i.e., key management module A transparently transmits the key acquisition request from application A to quantum device A. In step S42, quantum device A allocates a key and its key identifier to key management module A, and key management module A allocates a key and its key identifier to application A, i.e., key management module A transparently transmits the key from quantum device A and its key identifier to application A. In step S43, quantum device A synchronizes the allocated key and its key identifier to quantum device B. In step S44, application A synchronizes the key identifier of the key allocated to application A by quantum device A to application B. In step S45, application B requests a key from key management module B based on the key identifier provided by application A, and key management module B requests a key from quantum device B based on the key identifier, i.e., key management module A transparently transmits the key acquisition request (including the key identifier) ​​from application A to quantum device A. S46, quantum device B provides the key indicated by the key identifier (i.e., the key assigned to application A by quantum device 1) to key management module B. Key management module B then provides the key indicated by the key identifier to application B; in other words, key management module B transparently transmits the key from quantum device B to application B. At this point, application A and application B obtain the same key. This working mode is suitable for applications where a third party has key service capabilities, and no negotiation channel needs to be established between the key management modules in the application devices. It is worth noting that... Figure 7 The order of steps in the application key acquisition process shown is for illustrative purposes only. For example, there is no need to limit the execution order of S42 and S43. That is, S43 can be executed after S42, or S43 can be executed before S42, or S42 and S43 can be executed simultaneously.

[0289] The fourth operating mode, also known as the proxy mode, involves the key management module obtaining keys from a key service platform (such as the QKD network). The key management module pre-obtains a batch of keys from the key service platform and stores them locally. When an application requests a key, the key management platform selects a key from its local key pool and assigns it to the application. For example, Figure 8 This is a schematic diagram illustrating another application method for obtaining a key, as provided in an embodiment of this application. Figure 8As shown, in step S51, the key management module A sends a key acquisition request to quantum device A to request a key. In step S52, quantum device A provides the key and its key identifier to the key management module A. In step S53, quantum device A synchronizes the allocated key and its key identifier to quantum device B. In step S54, key management module A synchronizes the key identifier of the key provided by quantum device A to key management module B. In step S55, key management module B requests a key from quantum device B based on the key identifier provided by key management module A. In step S56, quantum device B provides the key indicated by the key identifier to key management module B, i.e., the key provided by quantum device 1 to key management module A. At this point, key management module A and key management module B have obtained the same key. In step S57, application A requests a key from key management module A, and key management module A allocates a key and its key identifier to application A. In step S58, application A synchronizes the key identifier of the key allocated to application A by key management module A to application B. In step S59, application B requests a key from key management module B based on the key identifier provided by application A. S510, the key management module B provides application B with the key indicated by the key identifier. At this point, application A and application B have obtained the same key. This operating mode is suitable for scenarios where applications have high requirements for the latency and reliability of key acquisition. It is worth noting that... Figure 8 The order of steps in the application key acquisition process shown is for illustrative purposes only. For example, there is no need to limit the execution order of S52 and S53. That is, S53 can be executed after S52, or S53 can be executed before S52, or S52 and S53 can be executed simultaneously.

[0290] The fifth working mode, also known as the hybrid mode, involves the key management module holding a key obtained by mixing a key generated by the module itself with a key from a key service platform (such as a QKD network). The key management module pre-obtains keys from the key service platform and generates its own keys, then stores the resulting key locally. When an application requests a key, the key management platform selects a key from its local key pool and assigns it to the application. This mode is suitable for scenarios with high key security requirements.

[0291] In this embodiment, the key management module in the application device supports diverse key sources to suit various application scenarios.

[0292] The order of steps in the methods provided in this application can be adjusted appropriately, and steps can be added or removed as needed. Any variations that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the protection scope of this application. For example, to reduce interaction between application devices, some steps can be combined depending on the specific application scenario. For instance, in conjunction with the first embodiment described above, the first key allocation information sent by the first application device to the second application device can be carried in the key generation request message.

[0293] The following describes an example of a virtual device in an embodiment of this application.

[0294] For example, Figure 9 This is a schematic diagram of the structure of an application device provided in an embodiment of this application. For ease of distinction, this application device is referred to here as the first application device 900. The first application device 900 is used to implement the functions of the first application device in the scheme described in the above embodiment. Optionally, the first application device 900 is... Figure 2 , Figures 4 to 8 Any of the application devices A shown. For example... Figure 9 As shown, the first application device 900 includes, but is not limited to, a key negotiation module 901, a key generation module 902, an encryption / decryption module 903, and a transceiver module 904. Optionally, the first application device 900 further includes a key distribution module 905 and a key status management module 906.

[0295] The system includes the following modules: a key negotiation module 901, used to determine a negotiation key by negotiating with a second application device; both the first and second application devices hold the same negotiation key. A key generation module 902, used to generate a target key based on a seed key and key derivation function parameter values, including a random salt value, using a key derivation function. An encryption / decryption module 903, used to encrypt key context information using the negotiation key to obtain ciphertext of the key context information, including the key derivation function parameter values. A transceiver module 904, used to send a key generation request message to the second application device, the key generation request message including the ciphertext of the key context information, requesting the second application device to generate the target key.

[0296] Optionally, the transceiver module 904 is configured to send a key negotiation request message to the second application device, the key negotiation request message indicating the public key algorithms supported by the first application device, and to receive a key negotiation response message corresponding to the key negotiation request message from the second application device, the key negotiation response message indicating the public key algorithms supported by both the second and first application devices. The key negotiation module 901 is configured to, if the public key algorithms supported by both the second and first application devices are not empty, perform key negotiation with the second application device using a key negotiation algorithm based on the public key algorithms supported by both the second and first application devices to generate a negotiated key.

[0297] Optionally, the public key algorithms supported by both the second application device and the first application device include a first public key algorithm and a second public key algorithm. The key negotiation module 901 is used to: negotiate a key with the second application device based on the first public key algorithm and through a first key negotiation algorithm to generate a first key; negotiate a key with the second application device based on the second public key algorithm and through a second key negotiation algorithm to generate a second key; and generate a negotiation key based on the first key and the second key.

[0298] Optionally, the first application device stores one or more configuration keys. The encryption / decryption module 903 is further configured to encrypt the negotiation request information using the first configuration key to obtain ciphertext of the negotiation request information. The negotiation request information includes a first public key algorithm list, which carries the algorithm identifiers of the public key algorithms supported by the first application device. The first configuration key is any one of the one or more configuration keys. The key negotiation request message includes the ciphertext of the negotiation request information and the key identifier of the first configuration key.

[0299] Optionally, the negotiation request information may also include the algorithm identifier of the key negotiation algorithm used by the first application device and the second application device to conduct key negotiation.

[0300] Optionally, the key negotiation algorithm includes the KEM algorithm and / or the ECDH key exchange algorithm.

[0301] Optionally, the key negotiation response message includes ciphertext of negotiation response information. The encryption / decryption module 903 is further configured to, after the first application device receives the key negotiation response message from the second application device, use the first configuration key to decrypt the ciphertext of negotiation response information to obtain a second public key algorithm list. The second public key algorithm list is used to carry the algorithm identifiers of public key algorithms supported by both the second application device and the first application device.

[0302] Optionally, the first application device stores one or more configuration keys. The key negotiation module 901 is used to use the second configuration key as the negotiation key if the public key algorithm supported by both the second and first application devices is empty. The second configuration key is any one of the one or more configuration keys. The key generation request message also includes a key identifier for the second configuration key.

[0303] Optionally, the key negotiation module 901 is further configured to, after the first application device performs key negotiation with the second application device based on a public key algorithm supported by both the first and second application devices to generate a negotiation key, when the negotiation key meets the key update conditions, re-negotiate the key with the second application device based on a public key algorithm supported by both the first and second application devices to obtain an updated negotiation key. The key update conditions include: the generation time of the negotiation key reaches the aging time, and / or, the number of times the negotiation key is used reaches a threshold.

[0304] Optionally, the transceiver module 904 is also used to announce the seed key to the second application device.

[0305] Optionally, the key context information may also include a key identifier assigned by the first application device to the target key.

[0306] Optionally, the key generation module 902 is configured to, in response to receiving a key acquisition instruction from the first application, generate a target key using a key derivation function based on a seed key and the parameter values ​​of the key derivation function. The key acquisition instruction includes the device identifier of the second application device. The transceiver module 904 is further configured to, after the first application device sends a key generation request message to the second application device, receive a key generation response message corresponding to the key generation request message from the second application device. The key generation response message indicates that the second application device has generated the target key. The key distribution module 905 is configured to distribute the target key and its key identifier to the first application.

[0307] Optionally, the transceiver module 904 is further configured to receive a key generation response message corresponding to the key generation request message from the second application device after the first application device sends a key generation request message to the second application device, wherein the key generation response message indicates that the second application device has generated the target key. The key status management module 906 is configured to set the status of the target key to available and store the target key and its key identifier.

[0308] Optionally, the key distribution module 905 is configured to distribute a stored target key and a key identifier of the target key to the first application if a key acquisition instruction is received from the first application, wherein the key acquisition instruction includes a device identifier of the second application device.

[0309] Optionally, the transceiver module 904 is further configured to, after the first application device allocates the stored target key and the key identifier of the target key to the first application, send a key status synchronization request message to the second application device, the key status synchronization request message including the key identifier of the target key, indicating that the first application device has allocated the target key; and receive a key status synchronization response message corresponding to the key status synchronization request message from the second application device, the key status synchronization response message indicating that the second application device has set the status of the target key to allocated. The key status management module 906 is configured to set the status of the target key to allocated.

[0310] Optionally, the key acquisition instruction also includes a key aging time. The transceiver module 904 is further configured to send first key allocation information to the second application device after the first application device allocates the target key and the key identifier of the target key to the first application device. The first key allocation information includes the key identifier of the target key and the key aging time. The key aging time is used by the second application device to age the target key after a timeout.

[0311] Optionally, the key acquisition instruction also includes a key request identifier and a key aging time. The key allocation module 905 is used to allocate a key list to the first application. The key list includes multiple key groups, each key group including a key and its key identifier. The target key and its key identifier are one of the multiple key groups. The transceiver module 904 is further used to send second key allocation information to the second application device. The second key allocation information includes a key request identifier, key identifiers in the key list, and a key aging time. The key aging time is used by the second application device to age the key list after a certain period. The key request identifier is used by the second application device to allocate the key list to the second application. The second application is the application configured with the key request identifier on the second application device.

[0312] Optionally, the application protocol running the first application may include the IPSec protocol or the TLS protocol.

[0313] Optionally, the key acquisition instruction also includes the protocol identifier of the application protocol running by the first application. The transceiver module 904 is further configured to send third key allocation information to the second application device after the first application device allocates the target key and the key identifier of the target key to the first application device. The third key allocation information includes the key identifier of the target key and the protocol identifier. The protocol identifier is used by the second application device to allocate the target key to the third application device, and the third application device is an application on the second application device that subscribes to the key corresponding to the protocol identifier.

[0314] Optionally, the application protocol running the first application may include BGP, LDP, or PCEP.

[0315] Optionally, the first application device includes a key management module, which integrates the functions of a key negotiation module 901, a key generation module 902, an encryption / decryption module 903, and a transceiver module 904. Optionally, the key management module also integrates the functions of a key distribution module 905 and a key status management module 906.

[0316] Optionally, the key management module receives a key acquisition instruction from the first application, the key acquisition instruction including the device identifier of the second application device; the key management module acquires one or more keys that are the same as those held by the key management module and the second application device according to the key acquisition instruction; the key management module allocates one or more keys to the first application.

[0317] Optionally, the source of the key held by the key management module includes one or more of the following: a key generated by the key management module; a key imported into the key management module; a key obtained by the key management module from the key service platform; or a key obtained by the key management module by mixing the generated key with the key obtained from the key service platform.

[0318] Optionally, the first application is an application on a first application device, or the first application is an application on a third application device, which is different from the first application device.

[0319] Optionally, both the first application device and the second application device are network devices.

[0320] For example, Figure 10 This is a schematic diagram of another application device provided in an embodiment of this application. For ease of distinction, this application device is referred to here as the second application device 1000. The second application device 1000 is used to implement the functions of the second application device in the scheme described in the above embodiment. Optionally, the second application device 1000 is... Figure 2 , Figures 4 to 8 Any of the application devices B shown. For example... Figure 10 As shown, the second application device 1000 includes, but is not limited to, a key negotiation module 1001, a transceiver module 1002, an encryption / decryption module 1003, and a key generation module 1004. Optionally, the second application device 1000 further includes a key status management module 1005 and a key distribution module 1006.

[0321] The system includes a key negotiation module 1001, used to determine a negotiation key by negotiating with a first application device. The second application device holds the same negotiation key as the first application device. A transceiver module 1002 is used to receive a key generation request message from the first application device, the message including ciphertext of key context information. An encryption / decryption module 1003 is used to decrypt the ciphertext of the key context information using the negotiation key to obtain the key context information, which includes key derivation function parameter values, including a random salt value. A key generation module 1004 is used to generate a target key based on a seed key and the key derivation function parameter values ​​using a key derivation function.

[0322] Optionally, the transceiver module 1002 is configured to receive a key negotiation request message from a first application device, the key negotiation request message indicating the public key algorithms supported by the first application device, and to send a key negotiation response message corresponding to the key negotiation request message to the first application device, the key negotiation response message indicating the public key algorithms supported by both the second application device and the first application device. The key negotiation module 1001 is configured to, if the public key algorithms supported by both the second application device and the first application device are not empty, respond to the first application device by performing key negotiation through a key negotiation algorithm to generate a negotiation key, based on the public key algorithms supported by both the second application device and the first application device.

[0323] Optionally, the public key algorithms supported by both the second application device and the first application device include a first public key algorithm and a second public key algorithm. The key negotiation module 1001 is used to: respond to the first application device by performing key negotiation through the first key negotiation algorithm based on the first public key algorithm to generate a first key; respond to the first application device by performing key negotiation through the second key negotiation algorithm based on the second public key algorithm to generate a second key; and generate a negotiation key based on the first key and the second key.

[0324] Optionally, the second application device stores one or more configuration keys. The key negotiation request message includes ciphertext of negotiation request information and a first key identifier. The encryption / decryption module 1003 is further configured to, after the second application device receives the key negotiation request message from the first application device, obtain the first configuration key from one or more configuration keys according to the first key identifier, and use the first configuration key to decrypt the ciphertext of negotiation request information to obtain negotiation request information. The negotiation request information includes a first public key algorithm list, which is used to carry the algorithm identifiers of the public key algorithms supported by the first application device.

[0325] Optionally, the encryption / decryption module 1003 is further configured to encrypt the negotiation response information using the first configuration key to obtain ciphertext of the negotiation response information. The negotiation response information includes a second public key algorithm list, which carries algorithm identifiers of public key algorithms supported by both the second application device and the first application device. The key negotiation response message includes the ciphertext of the negotiation response information.

[0326] Optionally, the second application device stores one or more configuration keys, and the key generation request message also includes a second key identifier. The key negotiation module 1001 is used to obtain a second configuration key from one or more configuration keys based on the second key identifier and use the second configuration key as the negotiation key.

[0327] Optionally, the transceiver module 1002 is also used to obtain the seed key announced by the first application device.

[0328] Optionally, the key context information also includes a key identifier assigned to the target key by the first application device. The key state management module 1005 is used to store the target key and the key identifier of the target key after the second application device generates the target key based on the seed key and the parameter values ​​of the key derivation function using the key derivation function.

[0329] Optionally, the transceiver module 1002 is further configured to, after the second application device generates a target key based on the seed key and the parameter values ​​of the key derivation function using a key derivation function, send a key generation response message corresponding to the key generation request message to the first application device. The key generation response message indicates that the second application device has generated the target key. The key status management module 1005 is configured to set the status of the target key to available.

[0330] Optionally, the transceiver module 1002 is further configured to receive a key status synchronization request message from the first application device. The key status synchronization request message includes a key identifier for the target key and indicates that the first application device has allocated the target key. The key status management module 1005 is configured to set the status of the target key to "allocated". The transceiver module 1002 is further configured to send a key status synchronization response message corresponding to the key status synchronization request message to the first application device. The key status synchronization response message indicates that the second application device has set the status of the target key to "allocated".

[0331] Optionally, the transceiver module 1002 is further configured to receive first key allocation information from the first application device, the first key allocation information including a key identifier of the target key and a key aging time, the key aging time being used by the second application device to age the target key. The key allocation module 1006 is configured to allocate the target key to the first application if a key acquisition request including a key identifier of the target key is received from the first application on the second application device within the key aging time.

[0332] Optionally, the transceiver module 1002 is further configured to receive second key allocation information from the first application device. The second key allocation information includes a key request identifier, a key identifier list, and a key aging time. The key aging time is used by the second application device to age out the keys indicated by the key identifier list. The key allocation module 1006 is configured to allocate the key indicated by the key identifier list to the second application if it is determined that the second application on the second application device is configured with a key request identifier before the key aging time expires.

[0333] Optionally, the transceiver module 1002 is further configured to receive third key allocation information from the first application device, the third key allocation information including a key identifier and a protocol identifier for the target key. The key allocation module 1006 is configured to allocate the target key to a third application, the third application being an application on the second application device that subscribes to the key corresponding to the protocol identifier.

[0334] Appendix Figure 9 and attached Figure 10 The described device embodiments are merely illustrative. For example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. The functional modules in the various embodiments of this application may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module. Appendix Figure 9 and attached Figure 10 The above modules can be implemented in either hardware or software functional units.

[0335] The following provides examples illustrating the basic hardware structures involved in the embodiments of this application.

[0336] Optionally, the application device provided in this application embodiment is a network device. For example, Figure 11 This is a schematic diagram of the hardware structure of an application device provided in an embodiment of this application. For example... Figure 11 As shown, the application device 1100 includes a processor 1101, a forwarding chip 1102, and at least one network interface 1103. Optionally, combined with Figure 2 Let's take a look. Figure 11 Application device 1100 is Figure 2 The application device A or application device B shown.

[0337] Optionally, the processor 1101 includes a central processing unit (CPU) and / or a dedicated hardware chip. The CPU refers to a general-purpose CPU with high scalability and flexibility. A CPU can be, for example, a single-core processor or a multi-core processor. The dedicated hardware chip is a high-performance processing hardware module. The dedicated hardware chip includes at least one of an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a network processor (NP).

[0338] The forwarding chip 1102 is used to forward requests and data. For example, the forwarding chip 1102 is used by the application device 1100 to send and receive messages.

[0339] At least one network interface 1103 includes, for example, Figure 11 Network interface 1103 is a network interface 1, network interface 2, network interface 3... network interface n. Network interface 1103 uses any transceiver-like device for communicating with other devices or communication networks. Optionally, network interface 1103 includes at least one of a wired network interface or a wireless network interface. The wired network interface is, for example, an Ethernet interface. The Ethernet interface is, for example, an optical interface, an electrical interface, or a combination thereof. The wireless network interface is, for example, a wireless protected local area networks (WLAN) interface, a cellular network interface, or a combination thereof.

[0340] At least one network interface 1103 is connected to the forwarding chip 1102, and the forwarding chip 1102 is connected to the processor 1101 via an internal connection 1104. The internal connection 1104 includes a path for transmitting data between the network interface 1103, the forwarding chip 1102, and the processor 1101. Optionally, the internal connection 1104 is a single board or a bus. For example, the internal connection 1104 is Ethernet, Fibre Channel, PCI-E (Peripheral Component Interconnect Express, PCI Express, a high-speed serial computer bus), RapidIO (a high-performance, low-pin-count, packet-switched interconnect architecture), InfiniBand, or XAUI bus (an interface extender that connects the Ethernet Media Access Control (MAC) layer to the physical layer).

[0341] Optionally, the application device 1100 also includes a content addressable memory (CAM) 1105. The CAM 1105 may be, for example, a ternary content addressable memory (TCAM). Optionally, the CAM 1105 exists independently and is connected to the forwarding chip 1102 via the aforementioned internal connection 1104. Alternatively, the CAM 1105 and the forwarding chip 1102 are integrated, meaning the CAM 1105 serves as the internal memory of the forwarding chip 1102.

[0342] Optionally, the application device 1100 also includes a memory 1106. The memory 1106 may be, for example, a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions; a random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions; an electrically erasable programmable read-only memory (EEPROM); a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed discs, laser discs, optical discs, digital universal discs, Blu-ray discs, etc.); a magnetic disk storage medium; or any other medium capable of carrying or storing desired program code 1108 in the form of instructions or data structures and accessible by a computer, but not limited thereto. The memory 1106 may exist independently and be connected to the processor 1101 via an internal connection 1104. Alternatively, the memory 1106 and the processor 1101 may be integrated together.

[0343] The memory 1106 stores an operating system 1107 and program code 1108. Optionally, the processor 1101 reads the operating system 1107 from the memory 1106 and runs the operating system 1107. The processor 1101 also reads the program code 1108 from the memory 1106 and runs the program code 1108 on the operating system 1107 to implement the actions performed by any of the application devices in the methods provided in the embodiments of this application.

[0344] Optionally, the aforementioned devices are disposed on separate chips, or at least partially or entirely on the same chip. Whether the devices are disposed independently on different chips or integrated on one or more chips often depends on the needs of the product design. This application does not limit the specific implementation of the aforementioned devices.

[0345] Optionally, the application device provided in this application embodiment is a terminal device or a server, etc. For example, Figure 12 This is a schematic diagram of the hardware structure of another application device provided in an embodiment of this application. For example... Figure 12 As shown, the application device 1200 includes a processor 1201 and a memory 1202, which are connected via a bus 1203. Figure 12 The processor 1201 and memory 1202 are described independently. Optionally, the processor 1201 and memory 1202 are integrated together. Optionally, they are combined... Figure 2 Let's take a look. Figure 12 The application device 1200 is Figure 2 The application device A or application device B shown.

[0346] The memory 1202 is used to store computer programs, including operating systems and program code. The memory 1202 can be various types of storage media, such as ROM, RAM, EEPROM, CD-ROM, flash memory, optical storage, registers, optical disc storage, disk storage, or other magnetic storage devices.

[0347] The processor 1201 is a general-purpose processor or a special-purpose processor. The processor 1201 may be a single-core processor or a multi-core processor. The processor 1201 includes at least one circuit to perform the actions executed by any of the application devices in the methods provided in the embodiments of this application.

[0348] Optionally, the application device 1200 also includes a network interface 1204, which is connected to the processor 1201 and the memory 1202 via a bus 1203. The network interface 1204 enables the application device 1200 to communicate with other devices.

[0349] Optionally, the application device 1200 also includes an input / output (I / O) interface 1205, which is connected to the processor 1201 and the memory 1202 via a bus 1203. The processor 1201 can receive input commands or data through the I / O interface 1205. The I / O interface 1205 is used for the application device 1200 to connect input devices, such as a keyboard and mouse. Optionally, in some possible scenarios, the network interface 1204 and the I / O interface 1205 are collectively referred to as a communication interface.

[0350] Optionally, the application device 1200 also includes a display 1206, which is connected to the processor 1201 and the memory 1202 via a bus 1203. The display 1206 can be used to display intermediate and / or final results generated by the processor 1201 executing the above methods. In one possible implementation, the display 1206 is a touch screen to provide a human-machine interface.

[0351] Wherein, bus 1203 can be any type of communication bus used to interconnect internal devices of application device 1200. For example, a system bus. This embodiment of the application uses the interconnection of the aforementioned devices inside application device 1200 via bus 1203 as an example. Optionally, the aforementioned devices inside application device 1200 can communicate with each other using connection methods other than bus 1203, such as interconnecting the aforementioned devices inside application device 1200 through internal logic interfaces of application device 1200.

[0352] The aforementioned devices can be disposed on separate chips, or at least partially or entirely on the same chip. Whether to dispose of the devices independently on different chips or integrate them on one or more chips often depends on the needs of the product design. This application does not limit the specific implementation of the aforementioned devices.

[0353] Figure 12 The application device 1200 shown is merely an example. In the implementation process, the application device 1200 includes other components, which will not be listed one by one in this document.

[0354] This application also provides a key generation system, including: a first application device and a second application device. The first application device is, for example, a... Figure 2 , Figures 4 to 8 Any of the application devices A shown has Figure 11 or Figure 12 The hardware structure is used to execute the steps performed by the first application device in the above method embodiments. The second application device is, for example, a... Figure 2 , Figures 4 to 8 Any of the application devices B shown has Figure 11 or Figure 12 The hardware structure is used to execute the steps performed by the second application device in the above method embodiments.

[0355] This application also provides a computer-readable storage medium storing instructions that, when executed by a processor, implement the steps performed by the first or second application device in the above method embodiments.

[0356] This application also provides a computer program product, including a computer program, which, when executed by a processor, implements the steps performed by the first application device or the second application device in the above method embodiments.

[0357] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0358] The terms "first" and "second," etc., used in the specification and claims of this application are used to distinguish different objects, not to describe a specific order of objects, and should not be construed as indicating or implying relative importance.

[0359] In the description of the embodiments in this application, unless otherwise stated, "at least one" means one or more. "More than one" means two or more.

[0360] A references B, which means that A is the same as B or A is a simple variation of B.

[0361] In this application, the term "and / or" is merely a description of the relationship between related objects, indicating that there are three possible relationships. For example, A and / or B means: A exists alone, A and B exist simultaneously, or B exists alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0362] Optionally, in the above embodiments, all or part of the implementation is carried out by software, hardware, firmware, or any combination thereof. Optionally, when implemented using software, it is implemented in the form of a computer program product, which is implemented in whole or in part. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. Optionally, the computer is a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Optionally, the computer instructions are stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. Optionally, the computer-readable storage medium is any available medium that can be accessed by a computer or a data storage device such as a server or data center that integrates one or more available media. Alternatively, the available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video disks (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0363] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A key generation method, characterized in that, The method includes: The first application device determines a negotiation key by engaging in key negotiation with the second application device, and the first application device and the second application device hold the same negotiation key. The first application device uses a key derivation function to generate a target key based on a seed key and key derivation function parameter values, wherein the key derivation function parameter values ​​include random salt values; The first application device uses the negotiated key to encrypt the key context information to obtain ciphertext of the key context information, wherein the key context information includes the key derivation function parameter value; The first application device sends a key generation request message to the second application device. The key generation request message includes the key context information ciphertext and is used to request the second application device to generate the target key.

2. The method according to claim 1, characterized in that, The first application device determines a negotiated key by engaging in key negotiation with the second application device, including: The first application device sends a key negotiation request message to the second application device, the key negotiation request message being used to indicate the public key algorithms supported by the first application device; The first application device receives a key negotiation response message corresponding to the key negotiation request message from the second application device. The key negotiation response message is used to indicate the public key algorithm supported by both the second application device and the first application device. If the public key algorithm supported by both the second application device and the first application device is not empty, the first application device performs key negotiation with the second application device based on the public key algorithm supported by both the second application device and the first application device through a key negotiation algorithm to generate the negotiation key.

3. The method according to claim 2, characterized in that, Both the second application device and the first application device support public key algorithms, including a first public key algorithm and a second public key algorithm. The first application device, based on the public key algorithms supported by both the second and first application devices, performs key negotiation with the second application device using a key negotiation algorithm to generate the negotiated key, including: The first application device, based on the first public key algorithm, negotiates a key with the second application device through a first key negotiation algorithm to generate a first key; The first application device, based on the second public key algorithm, performs key negotiation with the second application device through the second key negotiation algorithm to generate the second key; The first application device generates the negotiation key based on the first key and the second key.

4. The method according to claim 2 or 3, characterized in that, The first application device stores one or more configuration keys, and the method further includes: The first application device uses a first configuration key to encrypt the negotiation request information to obtain ciphertext of the negotiation request information. The negotiation request information includes a first public key algorithm list, which is used to carry the algorithm identifier of the public key algorithm supported by the first application device. The first configuration key is any one of the one or more configuration keys. The key negotiation request message includes the encrypted negotiation request information and the key identifier of the first configuration key.

5. The method according to claim 4, characterized in that, The key negotiation response message includes encrypted negotiation response information. After the first application device receives the key negotiation response message from the second application device, the method further includes: The first application device uses the first configuration key to decrypt the ciphertext of the negotiation response information to obtain a second public key algorithm list. The second public key algorithm list is used to carry the algorithm identifiers of public key algorithms supported by both the second application device and the first application device.

6. The method according to claim 2, characterized in that, The first application device stores one or more configuration keys, and the method further includes: If both the second application device and the first application device support no public key algorithms, the first application device will use the second configuration key as the negotiation key, where the second configuration key is any one of the one or more configuration keys. The key generation request message also includes the key identifier of the second configuration key.

7. The method according to any one of claims 2 to 5, characterized in that, After the first application device performs key negotiation with the second application device based on a public key algorithm supported by both the first and second application devices, and generates the negotiation key, the method further includes: When the negotiated key meets the key update conditions, the first application device re-negotiates the key with the second application device based on the public key algorithm supported by both the first and second application devices, through the key negotiation algorithm, to obtain the updated negotiated key. The key update conditions include: the generation time of the negotiated key reaches the aging time, and / or the number of times the negotiated key is used reaches the number threshold.

8. The method according to any one of claims 1 to 7, characterized in that, The method further includes: The first application device announces the seed key to the second application device.

9. The method according to any one of claims 1 to 8, characterized in that, The key context information also includes the key identifier assigned by the first application device to the target key.

10. The method according to any one of claims 1 to 9, characterized in that, The first application device uses a key derivation function to generate a target key based on a seed key and key derivation function parameter values, including: In response to receiving a key acquisition instruction from a first application, the first application device uses the key derivation function to generate the target key based on the seed key and the parameter values ​​of the key derivation function, and the key acquisition instruction includes the device identifier of the second application device; After the first application device sends a key generation request message to the second application device, the method further includes: The first application device receives a key generation response message corresponding to the key generation request message from the second application device, and the key generation response message indicates that the second application device has generated the target key; The first application device assigns the target key and the key identifier of the target key to the first application.

11. The method according to any one of claims 1 to 9, characterized in that, After the first application device sends a key generation request message to the second application device, the method further includes: The first application device receives a key generation response message corresponding to the key generation request message from the second application device, and the key generation response message indicates that the second application device has generated the target key; The first application device sets the status of the target key to available and stores the target key and its key identifier.

12. The method according to claim 11, characterized in that, The method further includes: If a key acquisition instruction is received from the first application, the first application device allocates the stored target key and the key identifier of the target key to the first application, and the key acquisition instruction includes the device identifier of the second application device.

13. The method according to claim 12, characterized in that, After the first application device allocates the stored target key and the key identifier of the target key to the first application, the method further includes: The first application device sends a key status synchronization request message to the second application device. The key status synchronization request message includes the key identifier of the target key and indicates that the first application device has allocated the target key. The first application device receives a key state synchronization response message corresponding to the key state synchronization request message from the second application device. The key state synchronization response message indicates that the second application device has set the state of the target key to be allocated. The first application device sets the status of the target key to "assigned".

14. The method according to claim 10 or 12, characterized in that, The key acquisition instruction further includes a key aging time. After the first application device allocates the target key and the key identifier of the target key to the first application, the method further includes: The first application device sends first key allocation information to the second application device. The first key allocation information includes the key identifier of the target key and the key aging time. The key aging time is used by the second application device to age the target key after a timeout.

15. The method according to claim 10 or 12, characterized in that, The key acquisition instruction also includes a key request identifier and a key aging time. The first application device allocates the target key and the key identifier of the target key to the first application, including: The first application device allocates a key list to the first application. The key list includes multiple key groups, each key group including a key and a key identifier of the key. The target key and the key identifier of the target key are one of the multiple key groups. The method further includes: The first application device sends second key allocation information to the second application device. The second key allocation information includes the key request identifier, the key identifier in the key list, and the key aging time. The key aging time is used by the second application device to age the key list after a timeout. The key request identifier is used by the second application device to allocate the key list to a second application. The second application is an application configured with the key request identifier on the second application device.

16. The method according to claim 10 or 12, characterized in that, The key acquisition instruction further includes a protocol identifier of the application protocol running the first application. After the first application device allocates the target key and the key identifier of the target key to the first application, the method further includes: The first application device sends third key allocation information to the second application device. The third key allocation information includes the key identifier of the target key and the protocol identifier. The protocol identifier is used by the second application device to allocate the target key to a third application. The third application is an application on the second application device that subscribes to the key corresponding to the protocol identifier.

17. The method according to any one of claims 1 to 16, characterized in that, The first application device includes a key management module, and the method is executed by the key management module.

18. The method according to claim 17, characterized in that, The key management module receives a key acquisition instruction from the first application, the key acquisition instruction including the device identifier of the second application device; The key management module obtains one or more keys that are the same as those held by the key management module and the second application device according to the key acquisition instruction; The key management module assigns one or more keys to the first application.

19. The method according to claim 18, characterized in that, The keys held by the key management module come from one or more of the following sources: The key generated by the key management module; The key imported into the key management module; The key management module obtains the key from the key service platform; The key management module obtains a key by mixing the generated key with the key obtained from the key service platform.

20. The method according to any one of claims 10, 12 to 16, 18 to 19, characterized in that, The first application is an application on the first application device, or the first application is an application on a third application device, which is different from the first application device.

21. A key generation method, characterized in that, The method includes: The second application device determines a negotiation key by engaging in key negotiation with the first application device, and the second application device and the first application device hold the same negotiation key. The second application device receives a key generation request message from the first application device, the key generation request message including key context information ciphertext; The second application device uses the negotiated key to decrypt the key context information ciphertext to obtain the key context information, which includes key derivation function parameter values ​​and random salt values. The second application device uses a key derivation function to generate a target key based on the seed key and the parameter values ​​of the key derivation function.

22. The method according to claim 21, characterized in that, The second application device determines the negotiated key by engaging in key negotiation with the first application device, including: The second application device receives a key negotiation request message from the first application device, the key negotiation request message being used to indicate the public key algorithms supported by the first application device; The second application device sends a key negotiation response message corresponding to the key negotiation request message to the first application device. The key negotiation response message is used to indicate the public key algorithm supported by both the second application device and the first application device. If the public key algorithm supported by both the second application device and the first application device is not empty, the second application device responds to the first application device by performing key negotiation through a key negotiation algorithm based on the public key algorithm supported by both the second application device and the first application device, so as to generate the negotiation key.

23. The method according to claim 22, characterized in that, Both the second application device and the first application device support public key algorithms, including a first public key algorithm and a second public key algorithm. Based on the public key algorithms supported by both the second and first application devices, the second application device responds to the first application device by performing key negotiation through a key negotiation algorithm to generate the negotiation key, including: The second application device, based on the first public key algorithm, responds to the first application device by performing key negotiation through the first key negotiation algorithm to generate the first key; The second application device, based on the second public key algorithm, responds to the first application device by performing key negotiation through the second key negotiation algorithm to generate a second key; The second application device generates the negotiation key based on the first key and the second key.

24. The method according to claim 22 or 23, characterized in that, The second application device stores one or more configuration keys. The key negotiation request message includes ciphertext of negotiation request information and a first key identifier. After the second application device receives the key negotiation request message from the first application device, the method further includes: The second application device obtains the first configuration key from the one or more configuration keys based on the first key identifier; The second application device uses the first configuration key to decrypt the ciphertext of the negotiation request information to obtain the negotiation request information, which includes a first public key algorithm list. The first public key algorithm list is used to carry the algorithm identifiers of the public key algorithms supported by the first application device.

25. The method according to claim 24, characterized in that, The method further includes: The second application device uses the first configuration key to encrypt the negotiation response information to obtain the ciphertext of the negotiation response information. The negotiation response information includes a second public key algorithm list, which is used to carry the algorithm identifiers of public key algorithms supported by both the second application device and the first application device. The key negotiation response message includes the ciphertext of the negotiation response information.

26. The method according to claim 22, characterized in that, The second application device stores one or more configuration keys, the key generation request message further includes a second key identifier, and the method further includes: The second application device obtains the second configuration key from the one or more configuration keys based on the second key identifier; The second application device uses the second configuration key as the negotiation key.

27. The method according to any one of claims 21 to 26, characterized in that, The method further includes: The second application device obtains the seed key announced by the first application device.

28. The method according to any one of claims 21 to 27, characterized in that, The key context information also includes a key identifier assigned by the first application device to the target key. After the second application device generates the target key based on the seed key and the parameter values ​​of the key derivation function using a key derivation function, the method further includes: The second application device stores the target key and the key identifier of the target key.

29. The method according to claim 28, characterized in that, After the second application device generates the target key based on the seed key and the parameter values ​​of the key derivation function using the key derivation function, the method further includes: The second application device sends a key generation response message corresponding to the key generation request message to the first application device, and the key generation response message indicates that the second application device has generated the target key; The second application device sets the status of the target key to available.

30. The method according to claim 29, characterized in that, The method further includes: The second application device receives a key status synchronization request message from the first application device. The key status synchronization request message includes a key identifier of the target key and indicates that the first application device has allocated the target key. The second application device sets the status of the target key to "allocated"; The second application device sends a key status synchronization response message corresponding to the key status synchronization request message to the first application device. The key status synchronization response message indicates that the second application device has set the status of the target key to be allocated.

31. The method according to any one of claims 28 to 30, characterized in that, The method further includes: The second application device receives first key allocation information from the first application device. The first key allocation information includes the key identifier and key aging time of the target key. The key aging time is used by the second application device to age the target key after a timeout. If a key acquisition request is received from a first application on the second application device within the key aging time, and the key acquisition request includes the key identifier of the target key, the second application device allocates the target key to the first application.

32. The method according to any one of claims 28 to 30, characterized in that, The method further includes: The second application device receives second key allocation information from the first application device. The second key allocation information includes a key request identifier, a key identifier list, and a key aging time. The key aging time is used by the second application device to age out the keys indicated by the key identifier list. If, before the key aging time expires, it is determined that a second application on the second application device is configured with the key request identifier, the second application device allocates the key indicated by the key identifier list to the second application.

33. The method according to any one of claims 28 to 30, characterized in that, The method further includes: The second application device receives third key allocation information from the first application device, the third key allocation information including the key identifier and protocol identifier of the target key; The second application device allocates the target key to a third application, which is an application on the second application device that subscribes to the key corresponding to the protocol identifier.

34. An application device, characterized in that, include: Memory, network interface, and at least one processor, The memory is used to store program instructions. After the at least one processor reads the program instructions stored in the memory, it causes the application device to execute the method as described in any one of claims 1 to 33.

35. A key generation system, characterized in that, include: A first application device and a second application device, wherein the first application device is configured to perform the method as described in any one of claims 1 to 20, and the second application device is configured to perform the method as described in any one of claims 21 to 33.

36. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed by a processor, implement the method as described in any one of claims 1 to 33.

Images