Key determination method, application device and key determination system

Abstract

The present application belongs to the technical field of communications. Disclosed in the embodiments of the present application are a key determination method, an application device and a key determination system. In the embodiments of the present application, two application devices in a QKD network negotiate, by means of interaction of QKD information, which one will act as an active party for acquiring a quantum key, and then, on the basis of the acquired quantum key, determine a target CAK and a target CKN that are required for communication between the two parties using an MKA protocol. First, there is no need for technicians to preconfigure which device will act as an active party and which device will act as a passive party, thereby simplifying the configuration process; second, there is no need to preconfigure on each application device QKD information of a peer device; moreover, in the embodiments of the present application, two communication parties negotiate, by means of interaction of QKD information, which one will act as an active party for acquiring a quantum key, instead of a key server being directly assigned as an active party for acquiring a quantum key, thus achieving a wide application range.

Description

Key determination method, application device and key determination system

[0001] The present application claims priority from the Chinese Patent Application No. 202411377936.6 filed on September 29, 2024 and entitled "Key determination method, application device and key determination system", the content of which is incorporated herein by reference in its entirety. TECHNICAL FIELD

[0002] Embodiments of the present application relate to the field of communication technology, in particular to a key determination method, an application device and a key determination system. BACKGROUND

[0003] In a media range control security key agreement (MACSec Key Agreement, MKA) protocol, two communication devices communicating with each other first obtain the same secure connectivity association key (CAK) and secure connectivity association key name (CKN), and then perform key server election based on the CAK and CKN, the elected key server determines a secure association key (SAK), and distributes the determined SAK to the opposite end, so that the two parties can perform secure sending and secure receiving of link layer data based on the SAK.

[0004] In related technologies, the two parties communicating using the MKA protocol can be application devices in a quantum key distribution (QKD) network, and the same quantum key is obtained in advance through QKD technology, and then the quantum key is used as the CAK and the key identifier of the quantum key is used as the CKN in the subsequent key server election process to negotiate the SAK. Moreover, before obtaining the quantum key, a technician needs to pre-configure which one of the two parties is the active end for obtaining the quantum key and which one is the passive end for obtaining the quantum key. The active end can actively obtain the quantum key from the QKD network and send the key identifier of the obtained quantum key to the passive end, so that the passive end obtains the same quantum key from the QKD network based on the key identifier.

[0005] In the above process of determining the quantum key, the technician needs to pre-configure which one of the two parties is the active end for obtaining the quantum key, and the configuration process is complex. SUMMARY

[0006] The embodiment of the present application provides a key determination method, an application device and a key determination system, which can simplify the configuration process and have wide application range. The technical solution is as follows:

[0007] In the first aspect, a key determination method is provided, in which a first application device sends a first message to a second application device, the first message carries first quantum key distribution (QKD) information, the first QKD information is used to indicate configuration information of the first application device in a QKD network; the first application device receives a second message from the second application device, the second message carries second QKD information, the second QKD information is used to indicate configuration information of the second application device in the QKD network; in response to the first application device determining that the local end is an active end for obtaining a quantum key based on the first message and the second message, the first application device performs the following steps:

[0008] obtaining a quantum key from the QKD network, and determining a target connection key association (CAK) and a target connection key name (CKN) based on the quantum key, the target CAK and the target CKN being CAK and CKN required for the first application device and the second application device to communicate by using a media access control security key agreement (MKA) protocol; sending a third message to the second application device, the third message carrying quantum key announcement information, the quantum key announcement information being used to indicate key information of the quantum key which needs to be announced to the second application device; receiving a fourth message from the second application device, the fourth message carrying quantum key confirmation information, the quantum key confirmation information being used to indicate a result of the second application device obtaining a quantum key from the QKD network in response to the third message.

[0009] In the embodiment of the present application, two application devices in the QKD network negotiate who is the active end for obtaining a quantum key by interacting with QKD information, and then determine the target CAK and the target CKN required for the two parties to communicate by using the MKA protocol based on the obtained quantum key. On the one hand, it is not necessary to pre-configure who is the active end and who is the passive end by a technician, so that the configuration process can be simplified. On the other hand, the two communication parties interact with the QKD information of the local end in the embodiment of the present application, so it is not necessary to pre-configure the QKD information of the opposite end, such as the QKD identifier, on each application device, and the embodiment of the present application negotiates who is the active end for obtaining a quantum key by interacting with the QKD information, instead of directly taking the key server as the active end for obtaining a quantum key, so that the communication between the two parties based on the MKA protocol can be realized without the key server having the capability of actively obtaining a quantum key, and the application range is wide.

[0010] In a possible implementation manner of the method provided in the first aspect, the first QKD information includes a QKD identifier corresponding to the first application device and a quantum key acquisition priority of the first application device, and the second QKD information includes a QKD identifier corresponding to the second application device and a quantum key acquisition priority of the second application device.

[0011] Taking the first QKD information as an example, the first QKD information includes a QKD identifier corresponding to the first application device, and is used to ensure that the active end negotiated applies for a quantum key from the QKD network based on the QKD identifiers corresponding to the two parties. The first QKD information includes a quantum key acquisition priority of the first application device, and is used to ensure that the two parties can negotiate who is the active end for acquiring a quantum key.

[0012] In this scenario, taking the first application device as an example, the first application device determines who is the quantum active end according to the quantum key acquisition priority of the first application device and the quantum key acquisition priority of the second application device. For example, when the quantum key acquisition priority of the first application device is higher than the quantum key acquisition priority of the second application device, it is determined that the first application device is the active end for acquiring a quantum key. For another example, when the quantum key acquisition priority of the first application device is lower than the quantum key acquisition priority of the second application device, it is determined that the second application device is the active end for acquiring a quantum key. In this scenario, by default, any application device in the QKD network has the ability to actively acquire a quantum key from the QKD network.

[0013] In a possible implementation manner of the method provided in the first aspect, the first QKD information further includes a key acquisition mode of the first application device, and the second QKD information further includes a key acquisition mode of the second application device; the key acquisition mode includes an active acquisition mode and a passive reception mode, the active acquisition mode is used to indicate that the corresponding application device can actively acquire a quantum key from the QKD network, and the passive reception mode is used to indicate that the corresponding application device needs to acquire a quantum key from the QKD network based on the indication of another application device.

[0014] In some scenarios, if some application devices do not have the ability to actively acquire a quantum key from the QKD network, even if it is negotiated through the first packet and the second packet that the application device is the quantum active end, the application device cannot acquire a quantum key subsequently. Therefore, in the present application, the QKD information further includes a key acquisition mode of the application device in addition to the QKD identifier corresponding to the application device and the quantum key acquisition priority of the application device.

[0015] In a possible implementation manner of the method provided in the first aspect, the first QKD information includes a QKD identifier corresponding to the first application device and a key acquisition mode of the first application device, and the second QKD information includes a QKD identifier corresponding to the second application device and a key acquisition mode of the second application device; the key acquisition mode includes an active acquisition mode and a passive receiving mode, the active acquisition mode is used to indicate that the corresponding application device can actively acquire quantum keys from the QKD network, and the passive receiving mode is used to indicate that the corresponding application device needs to acquire quantum keys from the QKD network based on an indication of another application device.

[0016] If the key acquisition mode of the first application device and the key acquisition mode of the second application device are different, the two parties can negotiate who is the active end for acquiring quantum keys by comparing the key acquisition mode of the local end with the key acquisition mode of the opposite end. Therefore, in this scenario, the QKD information only needs to carry the QKD identifier corresponding to the application device and the key acquisition mode of the application device.

[0017] In a possible implementation manner of the method provided in the first aspect, the first QKD information further includes a quantum key acquisition priority of the first application device, and the second QKD information further includes a quantum key acquisition priority of the second application device.

[0018] Further, if the key acquisition mode of the first application device and the key acquisition mode of the second application device are the same, the first QKD information further needs to further include the quantum key acquisition priority of the first application device, and the second QKD information further needs to further include the quantum key acquisition priority of the second application device, so that the two parties negotiate who is the active end for acquiring quantum keys by comparing the quantum key acquisition priority of the local end with the quantum key acquisition priority of the opposite end.

[0019] In a possible implementation manner of the method provided in the first aspect, the first message and the second message both include a reference field, the reference field includes a first bit sequence and a second bit sequence, a bit value corresponding to the first bit sequence is used to indicate the key acquisition mode of the corresponding application device, and a bit value corresponding to the second bit sequence is used to indicate the quantum key acquisition priority of the corresponding application device.

[0020] In the scenario in which the QKD information includes the quantum key acquisition priority and the key acquisition mode of the application device, the quantum key acquisition priority and the key acquisition mode of the application device can be carried together by a specific field.

[0021] In a possible implementation manner of the method provided in the first aspect, the quantum key announcement information includes a key identifier of the quantum key, a key length of the quantum key, and a quantum key mixing mode, the quantum key mixing mode is used to indicate whether the quantum key and an existing CAK are mixed to obtain a target CAK.

[0022] In the embodiment of the present application, when the first application device is configured with the quantum key mixing mode, the first application device also carries the quantum key mixing mode in the quantum key announcement information to announce to the second application device, so that the second application device determines the target CAK according to the mode indicated by the quantum key mixing mode.

[0023] In a possible implementation manner of the method provided in the first aspect, the existing CAK is a CAK negotiated between the first application device and the second application device through an Extensible Authentication Protocol (EAP), or is a CAK configured at the first application device and the second application device.

[0024] When the first application device and the second application device use the MKA protocol in a host-oriented point-to-point mode, the two parties can negotiate a CAK through the EAP, and the negotiated CAK is used as the CAK for mixing the quantum key. When the first application device and the second application device use the MKA protocol in a device-oriented point-to-point mode, a CAK can be pre-configured at the two parties as the CAK for mixing the quantum key.

[0025] In a possible implementation manner of the method provided in the first aspect, in response to the quantum key mixing mode indicating that the quantum key and the existing CAK are mixed to obtain the target CAK, the quantum key announcement information further includes an existing CKN, and the existing CKN is an identifier of the existing CAK; and the quantum key confirmation information includes the existing CKN.

[0026] When the quantum key mixing mode configured at the first application device is used to indicate that the quantum key and the existing CAK are mixed to obtain the target CAK, the first application device also carries an identifier of the existing CAK, that is, an existing CKN, in the quantum key announcement information to announce to the second application device, so that the second application device also mixes the quantum key and the existing CAK to obtain the target CAK.

[0027] In a possible implementation manner of the method provided in the first aspect, the implementation process in which the first application device determines the target CAK based on the quantum key can include: in response to the quantum key mixing mode indicating that the quantum key and the existing CAK are not mixed to obtain the target CAK, determining the target CAK based on the quantum key; and in response to the quantum key mixing mode indicating that the quantum key and the existing CAK are mixed to obtain the target CAK, determining the target CAK based on the quantum key and the existing CAK.

[0028] In the present application, different ways can be used to determine the target CAK in different quantum key mixing modes.

[0029] In a possible implementation manner of the method provided in the first aspect, the implementation process of determining the target CAK based on the quantum key can be: determining the target CAK through the following formula: target CAK = KDF (quantum key, first label, QKD identifier 1 | QKD identifier 2, required length of the target CAK); wherein KDF is a key derivation function, the first label is QKD-CAK, QKD identifier 1 is the smaller one of the QKD identifier corresponding to the first application device and the QKD identifier corresponding to the second application device, and QKD identifier 2 is the larger one of the QKD identifier corresponding to the first application device and the QKD identifier corresponding to the second application device.

[0030] The target CAK can be derived from the quantum key through the formula, thereby avoiding directly using the quantum key as the target CAK.

[0031] In a possible implementation manner of the method provided in the first aspect, the implementation process of determining the target CAK based on the quantum key and the existing CAK can be: in response to the quantum key mixing mode indication, mixing the quantum key and the existing CAK through the KDF algorithm to obtain the target CAK, and determining the target CAK through the following formula: target CAK = KDF (quantum key, first label, existing CAK, required length of the target CAK), wherein KDF is a key derivation function, and the first label is QKD-CAK; in response to the quantum key mixing mode indication, mixing the quantum key and the existing CAK through the XOR algorithm to obtain the target CAK, and performing XOR calculation on the quantum key and the existing CAK to obtain the target CAK.

[0032] Considering that there can be multiple mixing modes for mixing the quantum key and the existing CAK to obtain the target CAK, the application further provides a determination manner of the target CAK in different mixing modes, thereby improving the application flexibility of the application.

[0033] In a possible implementation manner of the method provided in the first aspect, the implementation process of determining the target CKN based on the quantum key by the first application device can be: in response to the quantum key mixing mode indication not mixing the quantum key and the existing CAK to obtain the target CAK, determining the target CKN based on the quantum key; and in response to the case that the quantum key mixing mode indication mixes the quantum key and the existing CAK to obtain the target CAK, determining the target CKN based on the quantum key and the existing CKN.

[0034] In the application, different manners can be used to determine the target CKN in different quantum key mixing modes.

[0035] In a possible implementation manner of the method provided in the first aspect, the implementation process of determining the target CKN based on the quantum key can be: determining the target CKN by the following formula: target CKN = KDF (quantum key, second label, key identifier of the quantum key | QKD identifier 1 | QKD identifier 2, required length of the target CKN); wherein KDF is a key derivation function, the second label is QKD-CKN, QKD identifier 1 is the smaller one of the QKD identifier corresponding to the first application device and the QKD identifier corresponding to the second application device, and QKD identifier 2 is the larger one of the QKD identifier corresponding to the first application device and the QKD identifier corresponding to the second application device.

[0036] The target CKN can be derived according to the quantum key by the formula, and the identification of the quantum key is avoided to be directly used as the target CKN.

[0037] In a possible implementation manner of the method provided in the first aspect, the implementation process of determining the target CKN based on the quantum key and the existing CKN can be: determining the target CKN by the following formula: target CKN = KDF (quantum key, second label, key identifier of the quantum key | existing CKN, required length of the target CKN); wherein KDF is a key derivation function, and the second label is QKD-CKN.

[0038] The target CKN can be derived according to the key identifier of the quantum key and the existing CKN by the formula.

[0039] In a possible implementation manner of the method provided in the first aspect, the QKD network includes a first QKD device and a second QKD device, the first QKD device is a QKD device capable of providing a quantum key to a first application device, the second QKD device is a QKD device capable of providing a quantum key to a second application device, and the quantum key announcement information includes an address of the second QKD device.

[0040] In the present application, the quantum key announcement information can also include the address of the second QKD device, so that the second application device obtains the quantum key based on the address of the second QKD device. In this way, the second application device does not need to maintain the configuration information of the second QKD device, such as the address of the second QKD device, thereby expanding the application scenarios of the embodiments of the present application.

[0041] In a possible implementation manner of the method provided in the first aspect, the first message, the second message, the third message and the fourth message all carry a first session identifier, and the first application device and the second application device determine the target CAK and the target CKN through a session indicated by the first session identifier.

[0042] In the present application, the first application device and the second application device can also perform multiple key determination schemes provided by the embodiments of the present application in parallel to determine multiple target CAKs and multiple CKNs in parallel. In this scenario, in order to distinguish the key determination schemes executed in parallel, the first message, the second message, the third message and the fourth message can also carry a same session identifier, which is used to uniquely identify a session including the first message, the second message, the third message and the fourth message.

[0043] Based on the method provided in the first aspect, in a possible implementation, the quantum key obtained by the first application device from the QKD network includes multiple quantum keys, and the quantum key announcement information is used to indicate key information of the multiple quantum keys that need to be announced to the second application device; the quantum key obtained by the second application device from the QKD network includes at least one quantum key of the multiple quantum keys, and the quantum key confirmation information is used to indicate a result of the second application device obtaining the multiple quantum keys from the QKD network in response to the third message; the target CAK includes at least one target CAK corresponding to the at least one quantum key respectively, and the target CKN includes at least one target CKN corresponding to the at least one target CAK respectively.

[0044] In the present application, as the active end, the first application device can obtain multiple quantum keys when obtaining the quantum key from the QKD network, and then announce the key information corresponding to each quantum key of the multiple quantum keys to the second application device through one second message.

[0045] Based on the method provided in the first aspect, in a possible implementation, the first message, the second message, the third message and the fourth message are all EAPoL-Announcement messages on the local area network.

[0046] In the present application, the first message, the second message, the third message and the fourth message can be implemented by using the EAPoL-Announcement message defined by 802.1X.

[0047] Based on the method provided in the first aspect, in a possible implementation, the first message, the second message, the third message and the fourth message are all EAPoL-Key messages.

[0048] In the present application, the first message, the second message, the third message and the fourth message can be implemented by using the EAPoL-Key message defined by 802.1X.

[0049] In a possible implementation manner of the method provided in the first aspect, the first message and the second message are EAPoL-announce messages; the third message and the fourth message are first type EAPoL-MKA messages, and the first type EAPoL-MKA messages are used for electing a key server.

[0050] In the present application, after the first application device and the second application device complete the interaction of the QKD information through the EAPoL-announce messages, the first application device as the active end can directly initiate the key server election process after actively obtaining the quantum key, and can carry the obtained quantum key announcement information in the first type EAPoL-MKA message used for electing the key server, so as to shorten the total time length required for negotiating the SAK.

[0051] In a possible implementation manner of the method provided in the first aspect, the first message and the second message are first type EAPoL-MKA messages, and the first type EAPoL-MKA messages are used for electing a key server; in response to the first application device determining that the local end is the key server based on the first message and the second message, the third message is a second type EAPoL-MKA message, and the fourth message is a third type EAPoL-MKA message, the second type EAPoL-MKA message is used for distributing a security association key SAK, and the third type EAPoL-MKA message is used for announcing that the second application device has used the distributed SAK.

[0052] In a possible implementation manner of the method provided in the first aspect, the first message and the second message are first type EAPoL-MKA messages, and the first type EAPoL-MKA messages are used for electing a key server; in response to the first application device determining that the local end is not the key server based on the first message and the second message, the third message is a first type EAPoL-MKA message, and the fourth message is a second type EAPoL-MKA message, and the second type EAPoL-MKA message is used for distributing a security association key SAK.

[0053] In the present application, the first application device and the second application device synchronize and interact the QKD information through the first type EAPoL-MKA used for electing the key server, and simultaneously complete the negotiation operation of the key server and the active end. Since the elected key server and the active end can be the same application device or different application devices, the third message and the fourth message are implemented in the above two cases respectively.

[0054] In another aspect, a key determination method is provided, in which the second application device receives a first message from the first application device, the first message carrying first quantum key distribution (QKD) information, the first QKD information being used to indicate configuration information of the first application device in the QKD network; the second application device sends a second message to the first application device, the second message carrying second QKD information, the second QKD information being used to indicate configuration information of the second application device in the QKD network; in response to the second application device determining that the local end is not the active end for obtaining quantum keys based on the first message and the second message, the second application device performs the following steps:

[0055] receiving a third message from the first application device, the third message carrying quantum key announcement information, the quantum key announcement information being used to indicate key information of quantum keys that need to be announced to the second application device; obtaining quantum keys from the QKD network based on the third message, and determining a target security connection association key (CAK) and a target security connection association key name (CKN) based on the quantum keys, the target CAK and the target CKN being CAK and CKN required for the first application device and the second application device to communicate using a media access control security key agreement (MKA) protocol; sending a fourth message to the first application device, the fourth message carrying quantum key confirmation information, the quantum key confirmation information being used to indicate a result of the second application device obtaining quantum keys from the QKD network in response to the third message.

[0056] In a possible implementation manner of the method provided in the second aspect, the first QKD information includes a QKD identifier corresponding to the first application device and a quantum key obtaining priority of the first application device, and the second QKD information includes a QKD identifier corresponding to the second application device and a quantum key obtaining priority of the second application device.

[0057] Taking the first QKD information as an example, the first QKD information includes a QKD identifier corresponding to the first application device, which is used to ensure that the active end negotiated applies for quantum keys from the QKD network based on the QKD identifiers corresponding to the two parties. The first QKD information includes a quantum key obtaining priority of the first application device, which is used to ensure that the two parties can negotiate who is the active end for obtaining quantum keys.

[0058] In a possible implementation manner of the method provided in the second aspect, the first QKD information further includes a key obtaining mode of the first application device, and the second QKD information further includes a key obtaining mode of the second application device; the key obtaining mode includes an active obtaining mode and a passive receiving mode, the active obtaining mode being used to indicate that the corresponding application device can actively obtain quantum keys from the QKD network, and the passive receiving mode being used to indicate that the corresponding application device needs to obtain quantum keys from the QKD network based on the indication of another application device.

[0059] In a possible implementation manner of the method provided in the second aspect, the first QKD information comprises a QKD identifier corresponding to the first application device and a key acquisition mode of the first application device, and the second QKD information comprises a QKD identifier corresponding to the second application device and a key acquisition mode of the second application device; the key acquisition mode comprises an active acquisition mode and a passive receiving mode, the active acquisition mode is used to indicate that the corresponding application device can actively acquire a quantum key from the QKD network, and the passive receiving mode is used to indicate that the corresponding application device needs to acquire a quantum key from the QKD network based on an indication of another application device.

[0060] In a possible implementation manner of the method provided in the second aspect, the first QKD information further comprises a quantum key acquisition priority of the first application device, and the second QKD information further comprises a quantum key acquisition priority of the second application device.

[0061] In a possible implementation manner of the method provided in the second aspect, the first message and the second message each comprise a reference field, the reference field comprises a first bit sequence and a second bit sequence, a bit value corresponding to the first bit sequence is used to indicate the key acquisition mode of the corresponding application device, and a bit value corresponding to the second bit sequence is used to indicate the quantum key acquisition priority of the corresponding application device.

[0062] In a possible implementation manner of the method provided in the second aspect, the quantum key announcement information comprises a key identifier of the quantum key, a key length of the quantum key, and a quantum key mixing mode, the quantum key mixing mode is used to indicate whether the quantum key and an existing CAK are mixed to obtain a target CAK.

[0063] In a possible implementation manner of the method provided in the second aspect, the existing CAK is a CAK negotiated by the first application device and the second application device through an extensible authentication protocol (EAP), or is a CAK configured at the first application device and the second application device.

[0064] In a possible implementation manner of the method provided in the second aspect, in response to the quantum key mixing mode indicating that the quantum key and the existing CAK are mixed to obtain the target CAK, the quantum key announcement information further comprises an existing CKN, the existing CKN being an identifier of the existing CAK; and the quantum key confirmation information comprises the existing CKN.

[0065] In a possible implementation manner of the method provided in the second aspect, the implementation process of determining the target CAK based on the quantum key can include: in response to the quantum key mixing mode indicating that the quantum key and the existing CAK are not mixed to obtain the target CAK, determining the target CAK based on the quantum key; and in response to the quantum key mixing mode indicating that the quantum key and the existing CAK are mixed to obtain the target CAK, determining the target CAK based on the quantum key and the existing CAK.

[0066] In a possible implementation manner of the method provided in the second aspect, the implementation process of determining the target CAK based on the quantum key can include: determining the target CAK by using the following formula: target CAK = KDF(quantum key, first label, QKD identifier 1 | QKD identifier 2, required length of the target CAK); where KDF is a key derivation function, the first label is QKD-CAK, QKD identifier 1 is the smaller one of the QKD identifier corresponding to the first application device and the QKD identifier corresponding to the second application device, and QKD identifier 2 is the larger one of the QKD identifier corresponding to the first application device and the QKD identifier corresponding to the second application device.

[0067] In a possible implementation manner of the method provided in the second aspect, the implementation process of determining the target CAK based on the quantum key and the existing CAK can include: in response to the quantum key mixing mode indicating that the quantum key and the existing CAK are mixed to obtain the target CAK by using the KDF algorithm, determining the target CAK by using the following formula: target CAK = KDF(quantum key, first label, existing CAK, required length of the target CAK), where KDF is a key derivation function and the first label is QKD-CAK; and in response to the quantum key mixing mode indicating that the quantum key and the existing CAK are mixed to obtain the target CAK by using the XOR algorithm, performing XOR calculation on the quantum key and the existing CAK to obtain the target CAK.

[0068] In a possible implementation manner of the method provided in the second aspect, the implementation process of determining the target CAK based on the quantum key can include: in response to the quantum key mixing mode indicating that the quantum key and the existing CAK are not mixed to obtain the target CAK, determining the target CAK based on the quantum key; and in response to the quantum key mixing mode indicating that the quantum key and the existing CAK are mixed to obtain the target CAK, determining the target CAK based on the quantum key and the existing CAK.

[0069] In a possible implementation manner of the method provided in the second aspect, the implementation process of determining the target CKN based on the quantum key can be: determining the target CKN by the following formula: target CKN = KDF (quantum key, second label, key identifier of the quantum key | QKD identifier 1 | QKD identifier 2, required length of the target CKN); wherein KDF is a key derivation function, the second label is QKD-CKN, QKD identifier 1 is the smaller one of the QKD identifier corresponding to the first application device and the QKD identifier corresponding to the second application device, and QKD identifier 2 is the larger one of the QKD identifier corresponding to the first application device and the QKD identifier corresponding to the second application device.

[0070] In a possible implementation manner of the method provided in the second aspect, the implementation process of determining the target CKN based on the quantum key and the existing CKN can be: determining the target CKN by the following formula: target CKN = KDF (quantum key, second label, key identifier of the quantum key | existing CKN, required length of the target CKN); wherein KDF is a key derivation function, and the second label is QKD-CKN.

[0071] In a possible implementation manner of the method provided in the second aspect, the QKD network includes a first QKD device and a second QKD device, the first QKD device is a QKD device capable of providing a quantum key for the first application device, and the second QKD device is a QKD device capable of providing a quantum key for the second application device; and the quantum key announcement information includes an address of the second QKD device.

[0072] In a possible implementation manner of the method provided in the second aspect, the first message, the second message, the third message and the fourth message all carry a first session identifier, and the first application device and the second application device determine the target CAK and the target CKN through a session indicated by the first session identifier.

[0073] In a possible implementation manner of the method provided in the second aspect, the quantum key obtained by the first application device from the QKD network includes a plurality of quantum keys, and the quantum key announcement information is used to indicate key information of the plurality of quantum keys that need to be announced to the second application device; the quantum key obtained by the second application device from the QKD network includes at least one quantum key of the plurality of quantum keys, and the quantum key confirmation information is used to indicate a result of the second application device obtaining the plurality of quantum keys from the QKD network in response to the third message; the target CAK includes at least one target CAK corresponding to the at least one quantum key respectively, and the target CKN includes at least one target CKN corresponding to the at least one target CAK respectively.

[0074] In a possible implementation manner of the method provided in the second aspect, the first packet, the second packet, the third packet and the fourth packet are all EAPoL-announce packets.

[0075] In a possible implementation manner of the method provided in the second aspect, the first packet, the second packet, the third packet and the fourth packet are all EAPoL-announce packets.

[0076] In a possible implementation manner of the method provided in the second aspect, the first packet and the second packet are both EAPoL-announce packets; the third packet and the fourth packet are first-type EAPoL-MKA packets, and the first-type EAPoL-MKA packets are used for electing a key server.

[0077] In a possible implementation manner of the method provided in the second aspect, the first packet and the second packet are first-type EAPoL-MKA packets, and the first-type EAPoL-MKA packets are used for electing a key server; in response to the second application device determining, based on the first packet and the second packet, that the second application device is not the key server, the third packet is a second-type EAPoL-MKA packet, and the fourth packet is a third-type EAPoL-MKA packet, the second-type EAPoL-MKA packet is used for distributing a security association key (SAK), and the third-type EAPoL-MKA packet is used for announcing that the second application device has used the distributed SAK.

[0078] In a possible implementation manner of the method provided in the second aspect, the first packet and the second packet are first-type EAPoL-MKA packets, and the first-type EAPoL-MKA packets are used for electing a key server; in response to the second application device determining, based on the first packet and the second packet, that the second application device is the key server, the third packet is a first-type EAPoL-MKA packet, and the fourth packet is a second-type EAPoL-MKA packet, the second-type EAPoL-MKA packet is used for distributing a security association key (SAK).

[0079] The technical effects of each step in the method provided in the second aspect can refer to the method provided in the first aspect, and will not be described herein again.

[0080] In a third aspect, a first application device is provided, which has a function of implementing the key determination method in the first aspect. The first application device includes at least one module for implementing the key determination method provided in the first aspect.

[0081] In a fourth aspect, a second application device is provided, which has a function to implement the behavior of the key determination method in the second aspect. The second application device comprises at least one module for implementing the key determination method provided in the second aspect.

[0082] In a fifth aspect, an application device is provided, which comprises a processor and a memory in its structure, the memory is configured to store a program supporting the application device to execute the key determination method provided in the first aspect, and store data involved in implementing the key determination method provided in the first aspect. The processor is configured to execute the program stored in the memory.

[0083] In a sixth aspect, an application device is provided, which comprises a processor and a memory in its structure, the memory is configured to store a program supporting the application device to execute the key determination method provided in the second aspect, and store data involved in implementing the key determination method provided in the second aspect. The processor is configured to execute the program stored in the memory.

[0084] In a seventh aspect, a computer readable storage medium is provided, which stores instructions, when running on an application device, causes the application device to execute the key determination method in the first aspect.

[0085] In an eighth aspect, a computer readable storage medium is provided, which stores instructions, when running on an application device, causes the application device to execute the key determination method in the second aspect.

[0086] In a ninth aspect, a computer program product is provided, which comprises instructions, when running on an application device, causes the application device to execute the key determination method in the first aspect.

[0087] In a tenth aspect, a computer program product is provided, which comprises instructions, when running on an application device, causes the application device to execute the key determination method in the second aspect.

[0088] In an eleventh aspect, a key determination system is provided, which comprises a first application device and a second application device, to implement the key determination method in the first aspect or the key determination method in the second aspect by the first application device and the second application device.

[0089] The technical effects obtained by the corresponding technical means in the third aspect to the eleventh aspect are similar, and will not be repeated here. BRIEF DESCRIPTION OF DRAWINGS

[0090] Figure 1 is a flowchart of quantum key distribution;

[0091] Figure 2 is a diagram illustrating derivation of keys in various processes based on CAK in MKA protocol;

[0092] Figure 3 is a flowchart of a method for generating CAK and CKN for MKA protocol using QKD technology;

[0093] Figure 4 is another flowchart of a method for generating CAK and CKN for MKA protocol using QKD technology;

[0094] Figure 5 is a diagram illustrating an application scenario according to an embodiment of the present application;

[0095] Figure 6 is a diagram illustrating another application scenario according to an embodiment of the present application;

[0096] Figure 7 is a diagram illustrating another application scenario according to an embodiment of the present application;

[0097] Figure 8 is a flowchart of a key determination method 800 according to an embodiment of the present application;

[0098] Figure 9 is another diagram illustrating a key determination method according to an embodiment of the present application;

[0099] Figure 10 is a diagram illustrating a format of EAPoL-announcement packet according to an embodiment of the present application;

[0100] Figure 11 is another diagram illustrating a key determination method according to an embodiment of the present application;

[0101] Figure 12 is a diagram illustrating a format of EAPoL-key packet according to an embodiment of the present application;

[0102] Figure 13 is another diagram illustrating a key determination method according to an embodiment of the present application;

[0103] Figure 14 is another diagram illustrating a key determination method according to an embodiment of the present application;

[0104] Figure 15 is another diagram illustrating a key determination method according to an embodiment of the present application;

[0105] Figure 16 is a diagram illustrating a format of a first type of EAPoL-MKA packet according to an embodiment of the present application;

[0106] Figure 17 is another diagram illustrating a key determination method according to an embodiment of the present application;

[0107] Figure 18 is another diagram illustrating a key determination method according to an embodiment of the present application;

[0108] FIG. 19 is a flowchart of another key determination method 1900 provided by an embodiment of the present application;

[0109] FIG. 20 is a schematic diagram of a hardware structure of an application device 2000 provided by an embodiment of the present application;

[0110] FIG. 21 is a schematic diagram of a structure of an application device 2100 provided by an embodiment of the present application. DETAILED DESCRIPTION

[0111] To make the objects, technical solutions and advantages of embodiments of the present application clearer, the following further describes the embodiments of the present application with reference to the accompanying drawings.

[0112] To facilitate the understanding of the present application by the reader, the following first describes some technologies involved in the present application.

[0113] 1. QKD technology

[0114] With the development of quantum cryptography technology, QKD technology, as a typical application of quantum cryptography, has become a research hotspot of scholars. By building a QKD network, a quantum key pool (QKP) is constructed on each QKD device in the QKD network, so as to realize quantum key distribution. A QKD device is a physical device that follows the laws of quantum mechanics and processes information based on quantum computing principles. The QKD device stores and processes data using quantum bits. Quantum bits have more states than binary.

[0115] QKD technology is a secure key distribution technology that uses the Heisenberg uncertainty principle of quantum mechanics and the quantum state non-cloning theorem. In the process of quantum key distribution, a quantum key (QK) is generated by a QKD device and transmitted to another QKD device through a QKD network, so that the same quantum key is formed between the two QKD devices. In the process of quantum key distribution, the quantum key is transmitted in the form of a quantum state. Quantum key distribution has unconditional security, i.e., even if an eavesdropper is given unlimited computing resources, he cannot crack the quantum key using any decryption algorithm. The security basis of quantum key distribution is that the key source cannot be predicted and the channel eavesdropping can be detected. The key source cannot be predicted, which means that the QKD key source is a quantum true random number and thus cannot be predicted. Channel eavesdropping can be detected, which means that the quantum state sent into the channel satisfies the quantum non-cloning theorem, and the eavesdropping behavior in the channel will disturb the quantum state, so that the eavesdropping can be detected by the receiving party.

[0116] In recent years, the industry has tried to apply QKD technology to existing networks to provide secure key generation capabilities for communication parties that need keys. In the application framework of the QKD network, an application is deployed on the application device using quantum keys to obtain quantum keys from the QKD device. For example, FIG. 1 is a flowchart of quantum key distribution. As shown in FIG. 1, application device A and application device B are connected to the same QKD network, wherein application device A is connected to QKD device A in the QKD network, and application device B is connected to QKD device B in the QKD network. Application device A communicates with QKD device A through application A, and application device B communicates with QKD device B through application B. QKD device A and QKD device B are responsible for sending quantum keys to the application device. In the application scenario shown in FIG. 1, the quantum key distribution process includes the following steps.

[0117] Step 1.1: One of application device A and application device B is configured as an active end for obtaining quantum keys, and the other is configured as a passive end for obtaining quantum keys. For example, application device A is configured as the active end in FIG. 1. Both parties have QKD identities in the QKD network.

[0118] Step 1.2: The active end (i.e., application device A) applies for quantum keys from QKD device A in the QKD network, wherein the active end needs to provide the QKD identity of the active end in the QKD network and the QKD identity of the passive end in the QKD network to QKD device A when applying for quantum keys. This process can be implemented by calling the Get Key API on the active end through application device A.

[0119] Step 1.3: The active end notifies the passive end (i.e., application device B) of the key identifier (keyID) of the obtained quantum keys.

[0120] Step 1.4: Application device B applies for quantum keys from QKD device B in the QKD network, wherein the passive end needs to provide the key identifier of the quantum keys obtained by the active end to QKD device B when applying for quantum keys. This process can be implemented by calling the Get Key With KeyID API on the passive end through application device B.

[0121] Through steps 1.1 to 1.4, application device A and application device B have the same quantum keys.

[0122] 2, Extensible Authentication Protocol (EAP).

[0123] EAP is an authentication framework protocol running between the data link layer and the network layer, which can be used to implement access authentication of wireless network or point-to-point authentication of communication devices. EAP can be applied not only to wireless local area network, but also to wired local area network, but it is used more frequently in wireless local area network. EAP is not only a specific authentication mechanism, but also an authentication framework. EAP provides some common functions and allows both communication parties to negotiate the authentication mechanism desired to be used. These authentication mechanisms can be referred to as EAP authentication methods (or EAP methods). The mainstream EAP authentication methods currently include EAP-GPSK, EAP-TLS and EAP tunnel TLS (EAP-TTLS). In the EAP execution process, both communication parties negotiate to select an EAP authentication method through message interaction, and then complete authentication through the EAP authentication method.

[0124] 3. Extensible Authentication Protocol over LANs (EAPoL).

[0125] 802.1x protocol defines a message encapsulation format, which is called EAPoL message, and is mainly used to transmit EAP protocol messages between two communication devices to allow EAP protocol messages to be transmitted on a local area network (LAN).

[0126] 4. MKA protocol.

[0127] MKA protocol is a security protocol for protecting link layer data, and MKA protocol is a security protocol based on symmetric algorithm. In MKA protocol, it is assumed that both communication parties hold the same CAK and CKN, and CKN is used to identify CAK. Both communication parties can negotiate the SAK and other parameters used for encrypting and decrypting link layer data through the CAK and CKN, and then realize the secure transmission and secure reception of link layer data through these parameters, that is, provide security services for link layer data.

[0128] Among them, the process of both communication parties negotiating symmetric key and other parameters through MKA protocol can be implemented by the following steps. The following takes the first communication device and the second communication device as an example to illustrate.

[0129] Step 1: The first communication device and the second communication device perform key server election, which aims to elect a key server.

[0130] In step 1, each communication device sends a first type of EAPoL-MKA message for electing a key server to the opposite end, and the first type of EAPoL-MKA message sent by each communication device contains a basic parameter set of the local end, which mainly contains the MKA priority of the local end, the CKN of the local end, and an integrity check value (ICV) for checking the integrity of the message, etc.

[0131] For any communication device in the two communication parties, such as the first communication device, if the first communication device detects that the opposite end also holds the CAK with the same CKN identifier based on the first type of EAPoL-MKA message sent by the opposite end, then the ICK is derived from the CAK, the ICV of the first type of EAPoL-MKA message sent by the opposite end is calculated by using the ICK, and the calculated ICV is compared with the ICV in the first type of EAPoL-MKA message sent by the opposite end to check the integrity of the first type of EAPoL-MKA message sent by the opposite end. After the integrity check of the first type of EAPoL-MKA message sent by the opposite end is passed, it is determined whether the local end is a key server based on the MKA priority of the opposite end and the MKA priority of the local end. For example, in the case where the MKA priority of the opposite end is lower than the MKA priority of the local end, it is determined that the first communication device is a key server. Correspondingly, in the case where the MKA priority of the opposite end is higher than the MKA priority of the local end, it is determined that the first communication device is not a key server (non key server), in other words, the second communication device is a key server.

[0132] Step 2: The key server generates and distributes the SAK.

[0133] Suppose the first communication device is the elected key server, then after generating the SAK, the first communication device first issues and installs the SAK to the first receiving port of the local end, which is the receiving port used when interacting with the second communication device.

[0134] The first communication device further derives a key encrypting key (KEK) using the CAK, and then encrypts the SAK using the KEK, and distributes the encrypted SAK to the second communication device through the second type of EAPoL-MKA message. The second communication device derives the KEK based on the CAK using the same derivation method, decrypts the SAK based on the derived KEK, and issues and installs the SAK to the second sending port and the second receiving port of the local end, which are the transceiving ports used when the second communication device interacts with the first communication device.

[0135] The second communication device, after installing the SAK to the second sending port and the second receiving port, indicates that the SAK distributed by the key server has been used, and thus can return a third type of EAPoL-MKA message to the key server, the third type of EAPoL-MKA message being used to inform the key server that the distributed SAK has been used. After receiving the third type of EAPoL-MKA message, the key server installs the SAK to the first sending port of the second communication device, the first sending port being the sending port used when interacting with the second communication device. At this point, the sending ports and the receiving ports of the two communication devices have been installed with the same SAK, and the SAK is used to encrypt data in a message when sending the message to the other party, and the SAK is used to decrypt data in a message when receiving the message from the other party, so as to realize secure sending and secure receiving of the link layer data.

[0136] In addition, the key server can re-generate the SAK and re-install the SAK to the two communication devices according to the foregoing process when the amount of data encrypted and decrypted using the SAK reaches a certain amount, or when the time length of using the SAK reaches a certain time length, so as to improve the security of the SAK. Details are not described herein.

[0137] FIG. 2 is a schematic diagram of deriving the keys in each process based on the CAK in the MKA protocol. As shown in FIG. 2, the master key is the CAK, and the KEK and the ICK are directly derived from the CAK, the former being used to encrypt the SAK, and the latter being used to calculate the ICV. The key server generates the SAK in two ways, one of which is derived from the CAK, and the other of which is a random number generated by the key server as the SAK.

[0138] In addition, the MKA protocol has two modes of use, one of which is a host-to-host mode, and the other of which is a device-to-device mode.

[0139] In the host-to-host mode, one of the two communication devices is a host, and the other is a verifier. In this scenario, the host and the verifier need to perform an EAP protocol to complete the identity authentication of the host before performing the MKA protocol.

[0140] In the EAP protocol, the verifier requests the authentication server to authenticate the identity of the host. After the authentication server completes the identity authentication of the host, the authentication server derives a key, called MSK, according to the asymmetric exchange algorithm in the TLS 1.2, such as the DH algorithm, and returns the MSK to the host. At the same time, the authentication server transmits the MSK to the verifier through other protocols. The host and the verifier calculate the same CAK and CKN based on the MSK, and initiate the subsequent MKA protocol based on the same CAK and CKN, such as the subsequent key server election process.

[0141] However, the above-mentioned algorithm for generating MSK can be attacked by a quantum algorithm, so that the CAK and CKN obtained by this scheme do not have quantum resistance. And this scheme needs to deploy an authentication server to obtain CAK and CKN for MKA protocol through the authentication server. But in some scenarios, the communication parties do not need the authentication stage, which will limit the use of this method.

[0142] In the device-oriented point-to-point mode, the communication parties do not need to be authenticated by the authentication server. In this scenario, the CAK and CKN for the MKA protocol can be pre-configured on the communication parties by technicians. However, the manual configuration scheme cannot guarantee the entropy value of CAK and CKN, resulting in poor randomness of CAK and CKN, making it easy for attackers to guess CAK and CKN. And the manual configuration scheme is easy to cause CAK and CKN update not in time. In addition, the communication parties need to configure the same CAK and CKN at the same time, which is difficult to deploy.

[0143] Therefore, in recent years, methods for generating CAK and CKN for MKA protocol using QKD technology have been gradually proposed. Figures 3 and 4 are flowcharts of two methods for generating CAK and CKN for MKA protocol using QKD technology. Among them, figures 3 and 4 are explained by taking the QKD network application framework shown in figure 1 as an example.

[0144] In the flowchart shown in figure 3, the process of generating CAK and CKN for MKA protocol using QKD technology includes the following steps.

[0145] Step 3.1: The technicians pre-designate one party using MKA protocol communication as the active end for obtaining quantum key, and the other party as the passive end for obtaining quantum key. As shown in figure 3, the application device A is configured as the active end, and the application device B is configured as the passive end.

[0146] Step 3.2: The passive end informs the active end of the identification of the passive end in the QKD network, that is, the QKD identification.

[0147] Step 3.3: The active end requests quantum key from QKD device A, and provides the QKD identification of the active end and the QKD identification of the passive end when requesting quantum key.

[0148] Step 3.4: QKD device A returns quantum key and key identification of quantum key to the active end, that is, key+keyID.

[0149] Step 3.5: The active end initiates the MKA protocol, sends the first type of EAPoL-MKA message for key server election, and the message contains the basic parameter set of the local end. In the basic parameter set, the CKN field is filled with the keyID obtained in step 4. The basic parameter set also carries the QKD identifier of the active end. The ICV of the message is calculated by the ICK derived by the quantum key key obtained in step 3 as the CAK.

[0150] Step 3.6: The passive end obtains the keyID and the QKD identifier of the active end from the first type of EAPoL-MKA message sent by the active end, and applies for a quantum key based on the two parameters.

[0151] Step 3.7: The QKD device B returns the quantum key and the key identifier of the quantum key, i.e., key+keyID, to the passive end. The key+keyID in step 3.4 and step 3.7 are the same.

[0152] Step 3.8: The passive end derives the ICK by taking the quantum key as the CAK, and then checks whether the ICV in the first type of EAPoL-MKA message sent by the active end is correct. If it is correct, the passive end returns the first type of EAPoL-MKA message to the active end for key server election. Similarly, the CKN field in the basic parameter set in the first type of EAPoL-MKA message sent by the passive end is filled with the keyID, indicating that the passive end selects to use the quantum key as the CAK for key server negotiation.

[0153] Step 3.9 (not shown in FIG. 3): After the two messages in step 3.6 and step 3.8, the key server is elected between the active end and the passive end. It is assumed that the MKA priority of the active end on the left side is higher, so the active end is elected as the key server. Therefore, the active end generates the SAK, generates the KEK by taking the quantum key as the CAK, and encrypts the SAK using the KEK, and distributes the encrypted SAK to the passive end.

[0154] The subsequent steps have been described above, and will not be described here.

[0155] In the flow shown in FIG. 3, the active end and the passive end directly take the obtained quantum key as the CAK required by the MKA protocol. However, this technology needs to pre-configure the active end and the passive end between the two parties using the MKA protocol, and the configuration process is complex.

[0156] In the flow shown in FIG. 4, the process of generating the CAK and the CKN for the MKA protocol using the QKD technology includes the following steps.

[0157] Step 4.1: The same CAK and CKN are pre-configured in application device A and application device B by the technician, and the QKD identity of both parties is configured on each side, that is, the QKD identity of application device A and the QKD identity of application device B are configured on application device A, and the QKD identity of application device A and the QKD identity of application device B are configured on application device B.

[0158] Step 4.2: Based on the configured CAK and CKN, the two parties respectively send the first type of EAPoL-MKA message to the opposite end to perform key server election.

[0159] Step 4.3: The elected key server acts as the active end (Fig. 4 takes application device A as an example) and actively applies quantum key to QKD device A.

[0160] Step 4.4: QKD device A returns the quantum key and the key identity of the quantum key to the key server.

[0161] Step 4.5: The key server takes the key identity of the obtained quantum key as SAK, and sends the second type of EAPoL-MKA message for distributing SAK to the opposite end.

[0162] Step 4.6: After receiving the EAPoL-MKA message for distributing SAK, application device B applies quantum key to QKD device B based on the SAK carried in the EAPoL-MKA message.

[0163] Step 4.7: QKD device B returns the quantum key and the key identity of the quantum key to application device B.

[0164] Step 4.8: Application device B returns the third type of EAPoL-MKA message to the key server to announce that the distributed SAK has been used.

[0165] In the method shown in Fig. 4, the QKD identity of both parties must be configured on each communication side, and the configuration process is complex. In the scheme shown in Fig. 4, only the key server can act as the active end to obtain the quantum key, and if the key server does not have the ability to actively obtain the quantum key, the scheme shown in Fig. 4 cannot perform step 4.3 and the processes after step 4.3. Therefore, the application scenario of the scheme shown in Fig. 4 is limited.

[0166] Based on this, the embodiment of the application provides a key determination method, in which two application devices in a QKD network negotiate who is the active end for obtaining quantum keys by interacting QKD information, and then determine the target CAK and the target CKN required for communication between the two application devices using the MKA protocol based on the obtained quantum keys. On the one hand, it is not necessary to pre-configure who is the active end and who is the passive end by a technician, so that the configuration process can be simplified. On the other hand, the two communication parties interact the QKD information of the local end in the embodiment of the application, so it is not necessary to pre-configure the QKD information of the opposite end, such as the QKD identifier, on each application device, and the embodiment of the application is that the two communication parties negotiate who is the active end for obtaining quantum keys by interacting the QKD information, instead of directly taking the key server as the active end for obtaining quantum keys, so that the application range can be wide, and the two communication parties can avoid failing to realize the communication based on the MKA protocol due to the fact that the key server does not have the capability of actively obtaining quantum keys.

[0167] The application scheme is described in detail from the aspects of application scenarios, method processes, software devices, hardware devices, systems, and the like.

[0168] The application scenarios of the embodiment of the application are described by way of example.

[0169] For example, FIG. 5 is a schematic diagram of an application scenario provided by the embodiment of the application. As shown in FIG. 5, the application scenario includes a first application device and a second application device. The application scenario also includes one or more QKD networks. The first application device and the second application device are connected to the same QKD network. The QKD network includes a first QKD device and a second QKD device, wherein the first application device is connected to the first QKD device, and the second application device is connected to the second QKD device.

[0170] The first QKD device is configured to provide quantum keys to the first application device, and the second QKD device is configured to provide quantum keys to the second application device. In the same QKD network, one quantum key corresponds to one key identifier.

[0171] The first QKD device is configured to provide quantum keys to the first application device, and the second QKD device is configured to provide quantum keys to the second application device. In the same QKD network, one quantum key corresponds to one key identifier.

[0172] The first KME in the first QKD device is configured to manage a plurality of quantum keys, which can be generated by the first QKD device itself or transmitted to the first QKD device by other quantum devices, and the first QKD device uniformly manages the plurality of quantum keys. Similarly, the second KME in the second QKD device is configured to manage a plurality of quantum keys, which can be generated by the second QKD device itself or transmitted to the second QKD device by other quantum devices, and the second QKD device uniformly manages the plurality of quantum keys.

[0173] In addition, the first application device and the second application device in the embodiments of the present application are two end devices that communicate with each other through the MKA protocol.

[0174] The first application device and the second application device are an entity device or a virtual device for transmitting a signal, or receiving a signal, or transmitting and receiving a signal, and include but are not limited to a network device such as a router, a switch, or a base station, or a terminal device such as a host, a server, or a user terminal. Optionally, the first application device and the second application device communicate with each other through a wireless network, a wired network, a removable storage medium, or other special data communication technology. The wireless network includes but is not limited to the Internet, Bluetooth, a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a mobile network, a private network, or any combination of a virtual private network. The removable storage medium is, for example, a universal serial bus (USB) flash disk, a mobile hard disk, or other removable storage medium, which is not limited in the present application.

[0175] In the application scenario shown in FIG. 5, the first application device and the second application device interact with the QKD information of the local end through the first message and the second message in the embodiments of the present application, and both sides negotiate who is the active end for obtaining the quantum key according to the interactive QKD information, and obtain sufficient information required for requesting the quantum key from the QKD device through the interactive QKD information. The active end requests a new quantum key from the corresponding QKD device of the local end, and then notifies the passive end of the quantum key announcement information such as the key identifier of the quantum key through the third message in the embodiments of the present application. After receiving the quantum key announcement information sent by the active end, the passive end requests the quantum key corresponding to the key identifier from the corresponding QKD device of the local end. In this way, both sides obtain the same quantum key, and determine the target CAK and the target CKN required for communication using the MKA protocol according to the quantum key.

[0176] The first application device and the second application device can directly determine the target CAK required by the MKA protocol according to the quantum key, and determine the target CKN required by the MKA protocol according to the key identifier of the quantum key after obtaining the same quantum key through the method provided in the embodiments of the present application. For example, the quantum key is directly used as the target CAK required by the MKA protocol, and the key identifier of the quantum key is directly used as the target CKN required by the MKA protocol. For another example, the quantum key is directly used to derive the target CAK required by the MKA protocol through a key derivation algorithm, and the key identifier of the quantum key is directly used to derive the target CKN required by the MKA protocol through the key derivation algorithm.

[0177] Optionally, after obtaining the same quantum key through the method provided in the embodiments of the present application, the first application device and the second application device can further determine the target CAK required by the MKA protocol according to the quantum key and the existing CAK, and determine the target CKN required by the MKA protocol according to the key identifier of the quantum key and the existing CKN, wherein the existing CKN is the identifier of the existing CAK.

[0178] The existing CAK and the existing CKN are the CAK and the CKN negotiated by the first application device and the second application device through other ways. In this way, the first application device and the second application device can avoid directly using the quantum key as the target CAK, and thus avoid that the content of the communication between the first application device and the second application device through the MKA protocol is known by the QKD device in the QKD network, further improving the communication security between the first application device and the second application device.

[0179] Based on this, the quantum key announcement information announced by the active end to the passive end can further include a quantum key mixing mode, which is used to indicate whether to mix the quantum key and the existing CAK to obtain the target CAK. So that the first application device and the second application device can obtain the target CAK in the negotiated manner.

[0180] In the embodiments of the present application, the first application device and the second application device can use the MKA protocol to communicate through the host-oriented point-to-point mode, or use the MKA protocol to communicate through the device-oriented point-to-point mode. In different modes, the first application device and the second application device obtain the existing CAK and the existing CKN in different ways. This will be described below.

[0181] FIG. 6 is a schematic diagram of another application scenario provided by the embodiments of the present application. As shown in FIG. 6, in the host point-to-point mode, assuming that the first application device is a host (supplicant) and the second application device is an authenticator, the first application device and the second application device can complete the identity authentication of the host through the EAP protocol.

[0182] As shown in FIG. 6, in the EAP protocol, the host requests the identity authentication of the host to an authenticator server through the authenticator, which is implemented through an EAP-TLS message. After the identity authentication of the host is passed, the authenticator server notifies the host of the success of the identity authentication through the authenticator, which is implemented through an EAP-success message. Finally, the authenticator server issues MSK to the authenticator and the host respectively, and the authenticator and the host derive CAK and CKN respectively based on the MSK.

[0183] In this scenario, the first application device and the second application device can take the CAK negotiated through the EAP as the existing CAK for mixing the quantum key, and correspondingly take the CKN negotiated through the EAP as the existing CKN.

[0184] Continuing to refer to FIG. 6, after the first application device and the second application device complete the identity authentication of the host through the EAP protocol, the first application device and the second application device complete the interaction of the QKD information through the first message and the second message provided by the embodiments of the present application, to negotiate the active end for obtaining the quantum key, and then obtain the same quantum key, and finally determine the target CAK and the target CKN for the MKA protocol based on the same quantum key and the existing CAK respectively.

[0185] FIG. 7 is a schematic diagram of another application scenario provided by the embodiments of the present application. As shown in FIG. 7, in the device point-to-point mode, since the identity authentication is not required between the first application device and the second application device, the CAK (that is, the existing CAK) for mixing the quantum key and the existing CKN can be preconfigured in the first application device and the second application device. Subsequently, the first application device and the second application device complete the interaction of the QKD information through the first message and the second message provided by the embodiments of the present application, to negotiate the active end for obtaining the quantum key, and then obtain the same quantum key, and finally determine the target CAK and the target CKN for the MKA protocol based on the same quantum key and the existing CAK respectively.

[0186] It should be noted that FIG. 6 and FIG. 7 are two example scenarios of the first application device and the second application device using the MKA protocol. In the two scenarios shown in FIG. 6 and FIG. 7, the first application device and the second application device are directly connected, that is, the messages exchanged between the first application device and the second application device are directly sent to the opposite end without being forwarded through other intermediate devices. Alternatively, the first application device and the second application device can also communicate through other types of MKA protocol usage modes. For example, the first application device and the second application device can also communicate through the MACSec over WAN mode. In the MACSec over WAN mode, the first application device and the first application device can not be directly connected, but can communicate by forwarding messages through other intermediate devices.

[0187] The method flow of the embodiments of the present application is described below.

[0188] FIG. 8 is a flowchart of a key determination method 800 provided by an embodiment of the present application. As shown in FIG. 8, the method includes the following steps.

[0189] Step 801: The first application device sends a first message to the second application device, the first message carrying first QKD information, the first QKD information being used to indicate configuration information of the first application device in a QKD network.

[0190] Step 802: The first application device receives a second message from the second application device, the second message carrying second QKD information, the second QKD information being used to indicate configuration information of the second application device in the QKD network.

[0191] Through steps 801 and 802, for any communication party of the first application device and the second application device, the communication party can send the QKD information of the local end to the other communication party, so that both parties can obtain the QKD information of the opposite end, and then negotiate which party is the active end for obtaining the quantum key according to the QKD information of the local end and the QKD information of the opposite end.

[0192] In this way, for any communication party of the first application device and the second application device, only the QKD information of the local end needs to be configured on the communication party, without the need to configure the QKD information of the opposite end on the local end, thus simplifying the configuration operation.

[0193] It should be noted that there is no strict execution order between step 801 and step 802. For example, when the embodiment of the present application is applied, step 801 can be executed first, and then step 802 is executed, that is, the first application device sends the first message to the second application device first, and the second application device returns the second message to the first application device after receiving the first message. Alternatively, step 802 can be executed first, and then step 801 is executed, that is, the second application device sends the second message to the first application device first, and the first application device returns the first message to the second application device after receiving the second message.

[0194] The first QKD information and the second QKD information not only include necessary information that can negotiate who is the active end of the first application device and the second application device, but also include information required by the active end to apply for a quantum key. The implementation of the first QKD information and the second QKD information is described below.

[0195] The first QKD information includes the QKD identifier corresponding to the first application device and the quantum key acquisition priority of the first application device, and the second QKD information includes the QKD identifier corresponding to the second application device and the quantum key acquisition priority of the second application device.

[0196] The QKD identifier corresponding to the application device and the quantum key acquisition priority of the application device are described below taking the first application device as an example. The QKD identifier corresponding to the second application device and the quantum key acquisition priority of the second application device can be referred to the following content, and will not be described in detail.

[0197] The first QKD information includes the QKD identifier corresponding to the first application device, which is to ensure that the active end negotiated based on the QKD identifier corresponding to both parties to apply for a quantum key from the QKD network.

[0198] In the embodiment of the present application, the QKD identifier corresponding to the first application device can be understood as the identifier of the first application device in the QKD network, that is, the QKD identifier corresponding to the first application device is the QKD identifier of the first application device itself.

[0199] It should be noted that the first application device can include multiple ports, in the embodiments of the present application, the same QKD identifier can be configured for the multiple ports of the first application device, that is, a unique QKD identifier is configured for the first application device, in this scenario, the QKD identifier included in the first QKD information is the unique QKD identifier. Alternatively, different QKD identifiers can be configured for different ports of the first application device, in this scenario, assuming that the first application device currently needs to obtain quantum keys from the QKD network through one of the ports, the QKD identifier included in the first QKD information is the QKD identifier corresponding to the port. Alternatively, multiple QKD identifiers can be configured for one of the ports, in this scenario, assuming that the first application device currently needs to obtain quantum keys from the QKD network through the port, the QKD identifier included in the first QKD information can be any one of the multiple QKD identifiers corresponding to the port. The embodiments of the present application do not limit how to configure the QKD identifier of the first application device itself.

[0200] Alternatively, if the first application device is bound to the first QKD device in advance, and the second application device is bound to the second QKD device, the QKD identifier corresponding to the first application device can also be understood as the QKD identifier of the first QKD device bound to the first application device. In this scenario, the binding relationship between the first application device and the first QKD device is configured on the first application device in advance, so that the first device learns from the binding relationship that the quantum key needs to be applied through the first QKD device when applying for the quantum key.

[0201] In addition, the first QKD information includes the quantum key acquisition priority of the first application device, in order to ensure that both parties can negotiate who is the active end for acquiring quantum keys.

[0202] In this scenario, taking the first application device as an example, in some embodiments, the first application device determines who is the quantum active end according to the quantum key acquisition priority of the first application device and the quantum key acquisition priority of the second application device. For example, when the quantum key acquisition priority of the first application device is higher than the quantum key acquisition priority of the second application device, it is determined that the first application device is the active end for acquiring quantum keys. For another example, when the quantum key acquisition priority of the first application device is lower than the quantum key acquisition priority of the second application device, it is determined that the second application device is the active end for acquiring quantum keys.

[0203] In the above embodiments, any application device in the QKD network has the ability to actively obtain quantum keys from the QKD network by default.

[0204] Optionally, if some application devices do not have the ability to actively obtain quantum keys from the QKD network, even if the application device is negotiated as a quantum active end through the first message and the second message, the application device cannot obtain quantum keys subsequently. Based on this, in the first implementation manner, the first QKD information further includes the key acquisition mode of the first application device in addition to the QKD identifier corresponding to the first application device and the quantum key acquisition priority of the first application device, and the second QKD information further includes the key acquisition mode of the second application device in addition to the QKD identifier corresponding to the second application device and the quantum key acquisition priority of the second application device.

[0205] The key acquisition mode includes an active acquisition mode and a passive receiving mode. The active acquisition mode is used to indicate that the corresponding application device can actively obtain quantum keys from the QKD network. The passive receiving mode is used to indicate that the corresponding application device needs to obtain quantum keys from the QKD network based on the indication of another application device.

[0206] The key acquisition mode of any application device in the embodiments of the present application is pre-configured on the application device by the technician. For example, for any application device, the technician judges the key acquisition capability of the application device. If it is judged that the application device can actively obtain quantum keys from the QKD network, the key acquisition mode of the application device is configured as the active acquisition mode. Or, if it is judged that the application device cannot actively obtain quantum keys from the QKD network, the key acquisition mode of the application device is configured as the passive receiving mode. Or, even if it is judged that the application device can actively obtain quantum keys from the QKD network, but for some reason, the application device does not want to actively obtain quantum keys from the QKD network, the key acquisition mode of the application device is also configured as the passive receiving mode.

[0207] In this scenario, taking the first application device as an example, the first application device determines who is the active end for obtaining the quantum key according to the quantum key obtaining priority of the first application device, the quantum key obtaining mode of the first application device, the quantum key obtaining priority of the second application device, and the quantum key obtaining mode of the second application device. For example, in a scenario where the key obtaining mode of the first application device is the active obtaining mode and the key obtaining mode of the second application device is the passive receiving mode, it is determined that the first application device is the active end for obtaining the quantum key. For another example, in a scenario where the key obtaining mode of the first application device is the passive receiving mode and the key obtaining mode of the second application device is the active obtaining mode, it is determined that the second application device is the active end for obtaining the quantum key. For another example, in a scenario where the key obtaining mode of the first application device and the key obtaining mode of the second application device are both the active obtaining mode, when the quantum key obtaining priority of the first application device is higher than the quantum key obtaining priority of the second application device, it is determined that the first application device is the active end for obtaining the quantum key. For another example, in a scenario where the key obtaining mode of the first application device and the key obtaining mode of the second application device are both the active obtaining mode, when the quantum key obtaining priority of the first application device is lower than the quantum key obtaining priority of the second application device, it is determined that the second application device is the active end for obtaining the quantum key.

[0208] It should be noted that if the key obtaining mode of the first application device and the key obtaining mode of the second application device are both the passive receiving mode, it indicates that neither of the two communication parties has the ability to actively obtain the quantum key. In this scenario, any communication party among the first application device and the second application device can send an error fault message to the opposite end to prompt the opposite end that the active end for obtaining the quantum key cannot be negotiated at present.

[0209] In addition, in a scenario where the QKD information includes both the quantum key obtaining priority and the key obtaining mode of the application device, the quantum key obtaining priority and the key obtaining mode of the application device can be carried together by a specific field. Based on this, in some embodiments, the first message and the second message both include a reference field, the reference field includes a first bit sequence and a second bit sequence, the bit value corresponding to the first bit sequence is used to indicate the key obtaining mode of the corresponding application device, and the bit value corresponding to the second bit sequence is used to indicate the quantum key obtaining priority of the corresponding application device.

[0210] In this scenario, taking the first application device as an example, the first application device can first compare the first bit sequence in the first message and the first bit sequence in the second message. If the bit values corresponding to the two first bit sequences are different, the bit values corresponding to the two first bit sequences are directly determined to determine who is the active end of obtaining the quantum key. Correspondingly, if the bit values corresponding to the two first bit sequences are the same, the second bit sequence in the first message and the second bit sequence in the second message are further compared to determine who is the active end of obtaining the quantum key.

[0211] The correspondence between the bit value corresponding to the first bit sequence and the key acquisition mode can be flexibly configured in advance. For example, when the bit value corresponding to the first bit sequence is greater than or equal to a reference bit value, it is used to indicate that the key acquisition mode is a passive reception mode. Correspondingly, when the bit value corresponding to the first bit sequence is less than the reference bit value, it is used to indicate that the key acquisition mode is an active acquisition mode.

[0212] For example, the first bit sequence includes 2 bits, and the reference bit value is 10. When the bit value corresponding to the first bit sequence is greater than or equal to 10, it is used to indicate that the key acquisition mode is a passive reception mode. When the bit value corresponding to the first bit sequence is less than 10, it is used to indicate that the key acquisition mode is an active acquisition mode.

[0213] Alternatively, the correspondence between the bit value corresponding to the first bit sequence and the key acquisition mode can also be set to other correspondence, which will not be exemplified one by one here.

[0214] The correspondence between the bit value corresponding to the second bit sequence and the quantum key acquisition priority can also be flexibly configured in advance. For example, the smaller the bit value corresponding to the second bit sequence, the higher the quantum key acquisition priority of the corresponding application device.

[0215] In addition, in the reference field, the first bit sequence can be located before the second bit sequence. For example, the length of the reference field is M bits, and the first bit sequence is the first x bits of the reference field, and the second bit sequence is the last M-x bits of the reference field. For example, M=8, x=2, that is, the reference field is a field of 8 bits, the first 2 bits of the field are used as the first bit sequence to indicate the key acquisition mode of the application device, and the last 6 bits of the field are used as the second bit sequence to indicate the quantum key acquisition priority of the application device.

[0216] Optionally, in the reference field, the first bit sequence can be located after the second bit sequence. For example, the length of the reference field is M bits, and the second bit sequence is the first y bits of the reference field, and the first bit sequence is the last M-y bits of the reference field. For example, M=8 and y=6, that is, the reference field is a field of 8 bits, the first 6 bits of the field are used as the second bit sequence to indicate the quantum key acquisition priority of the application device, and the last 2 bits of the field are used as the first bit sequence to indicate the key acquisition mode of the application device.

[0217] In the embodiments of the present application, the position of the reference field is not limited. Details are not described herein.

[0218] The second implementation manner of the QKD information: the first QKD information includes the QKD identifier corresponding to the first application device and the key acquisition mode of the first application device, and the second QKD information includes the QKD identifier corresponding to the second application device and the key acquisition mode of the second application device; the key acquisition mode includes an active acquisition mode and a passive receiving mode, the active acquisition mode is used to indicate that the corresponding application device can actively acquire the quantum key from the QKD network, and the passive receiving mode is used to indicate that the corresponding application device needs to acquire the quantum key from the QKD network based on the indication of another application device.

[0219] In the second implementation manner, if the key acquisition mode of the first application device and the key acquisition mode of the second application device are different, the two parties can negotiate who is the active end for acquiring the quantum key by comparing the key acquisition mode of the local end with the key acquisition mode of the opposite end. Therefore, in this scenario, the QKD information only needs to carry the QKD identifier corresponding to the application device and the key acquisition mode of the application device.

[0220] Further, in the second implementation manner, if the key acquisition mode of the first application device and the key acquisition mode of the second application device are the same, the first QKD information further needs to further include the quantum key acquisition priority of the first application device, and the second QKD information further needs to further include the quantum key acquisition priority of the second application device, so that the two parties negotiate who is the active end for acquiring the quantum key by comparing the quantum key acquisition priority of the local end with the quantum key acquisition priority of the opposite end.

[0221] In the second implementation manner, how to negotiate who is the active end for acquiring the quantum key can refer to the related content in the first implementation manner, and details are not described herein.

[0222] In addition, if the first application device cannot negotiate who is the active end for obtaining the quantum key based on the first QKD information and the second QKD information, for example, the key obtaining mode of the first application device and the key obtaining mode of the second application device are both active obtaining modes, and the quantum key obtaining priority of the first application device and the quantum key obtaining priority of the second application device are also equal, in this case, the first application device can also compare the MAC address of the first application device and the MAC address of the second application device, and take the smaller one as the active end for obtaining the quantum key. Alternatively, the larger one of the MAC addresses can also be taken as the active end for obtaining the quantum key, and which way to be used can also be configured in advance at the first application device.

[0223] Step 803: In response to the first application device determining that the local end is the active end for obtaining the quantum key based on the first message and the second message, the first application device performs the following steps 8031-8033.

[0224] Step 8031: The first application device obtains the quantum key from the QKD network, and determines the target CAK and the target CKN based on the quantum key, the target CAK and the target CKN being the CAK and the CKN required for the first application device and the second application device to communicate using the MKA protocol.

[0225] In step 8031, the first application device sends a quantum key application request to the first QKD device, and the quantum key application request carries the QKD identifiers corresponding to the two application devices. After receiving the quantum key application request, the first QKD device determines a quantum key based on the two QKD identifiers, and returns the determined quantum key to the first application device. At the same time, the first QKD device also notifies the second QKD device of the determined quantum key, so that the second application device can subsequently obtain the quantum key from the second QKD device. It should be noted that the present application does not limit the mechanism by which the first QKD device notifies the second QKD device of the determined quantum key.

[0226] For example, in the case where the QKD identifier corresponding to the first application device is the QKD identifier of the first application device itself, and the QKD identifier corresponding to the second application device is the QKD identifier of the second application device itself, the first application device can select one of the plurality of QKD devices in the QKD network as the first QKD device, and send a quantum key application request to the first QKD device, and the quantum key application request carries the respective QKD identifiers of the two application devices. The first QKD device determines the quantum key to be distributed based on the respective QKD identifiers of the two application devices.

[0227] In this scenario, after determining the quantum key to be distributed, the first QKD device transmits the quantum key to the second QKD device, which is another QKD device in the QKD network. Subsequently, the second application device can determine that the second QKD device can provide the quantum key by analyzing the key identifier of the quantum key, and thus the second application device can determine which QKD device to obtain the quantum key from. The detailed implementation manner is not limited herein.

[0228] Optionally, in a scenario where the QKD identifier corresponding to the first application device is the QKD identifier of the first QKD device bound by the first application device, and the QKD identifier corresponding to the second application device is the QKD identifier of the second QKD device bound by the second application device, the first application device directly sends a quantum key application request to the first QKD device, where the quantum key application request carries the QKD identifier of the first QKD device and the QKD identifier of the second QKD device. The first QKD device determines the quantum key to be distributed based on the QKD identifiers of the two QKD devices.

[0229] In this scenario, since the first QKD device already knows the QKD identifier of the second QKD device, after determining the quantum key to be distributed, the first QKD device directly transmits the quantum key to the second QKD device. Subsequently, the second application device receives the key identifier of the quantum key, and since the second application device is currently bound to the second QKD device, the second application device can also directly determine which QKD device to obtain the quantum key from.

[0230] In addition, the first application device can send the quantum key application request by calling an interface, and the related content has been described in the foregoing embodiments.

[0231] After the first application device actively obtains the quantum key, the first application device determines the target CAK and the target CKN based on the quantum key. The following describes how the first application device determines the target CAK and the target CKN based on the quantum key.

[0232] In some embodiments, the first network device can directly use the quantum key as the target CAK and use the key identifier of the quantum key as the target CKN.

[0233] Optionally, in some other embodiments, a key mixing mode can also be configured in advance at the first network device. In this scenario, the first application device can determine the target CAK based on the quantum key in the following manner: in response to the quantum key mixing mode indicating that the target CAK is not obtained by mixing the quantum key and the existing CAK, determining the target CAK based on the quantum key; and in response to the quantum key mixing mode indicating that the target CAK is obtained by mixing the quantum key and the existing CAK, determining the target CAK based on the quantum key and the existing CAK.

[0234] That is, in the embodiments of the present application, different ways can be used to determine the target CAK in different quantum key mixing modes.

[0235] The following describes how to determine the target CAK in two scenarios.

[0236] Scenario 1: The quantum key mixing mode indicates that the target CAK is not obtained by mixing the quantum key and the existing CAK.

[0237] In scenario 1, the target CAK can be determined by the following formula (1): target CAK = KDF (quantum key, first label, QKD identifier 1 | QKD identifier 2, required length of target CAK) (1)

[0238] wherein KDF is a key derivation function, the first label is a string "QKD-CAK", QKD identifier 1 is the smaller one of the QKD identifier corresponding to the first application device and the QKD identifier corresponding to the second application device, and QKD identifier 2 is the larger one of the QKD identifier corresponding to the first application device and the QKD identifier corresponding to the second application device. QKD identifier 1 | QKD identifier 2 means that QKD identifier 1 and QKD identifier 2 are concatenated into a string.

[0239] It should be noted that the comparison between the QKD identifiers corresponding to the two application devices is binary comparison. For two QKD identifiers of different lengths, the shorter QKD identifier is padded with a leading 0 to the same length, and then the padded QKD identifiers are compared.

[0240] For example, when the QKD identifier corresponding to the application device is the QKD identifier of the application device itself, the above formula (1) can be converted to the following formula:

[0241] target CAK = KDF (quantum key, first label, appid 1 | appid 2, required length of target CAK)

[0242] Wherein, appid1 is the smaller one of the QKD identity of the first application device itself and the QKD identity of the second application device itself, and appid2 is the larger one of the QKD identity of the first application device itself and the QKD identity of the second application device itself.

[0243] The target CAK can be derived from the quantum key according to the above formula, and direct use of the quantum key as the target CAK is avoided.

[0244] It should be noted that the above formula is used to illustrate how to derive the target CAK from the quantum key. Alternatively, when deriving the target CAK through the KDF, the target CAK can also be derived through the KDF based only on the quantum key, or the target CAK can be derived through the KDF based on the quantum key and other parameters, which will not be illustrated one by one. In addition, the target CAK can also be derived through other derivation algorithms other than the KDF, which will also not be illustrated one by one.

[0245] In addition, the required length of the target CAK is a length pre-configured at the first application device, which can be understood as the required length of the target CAK by the first application device. For example, if the length of the target CAK is required to be 128 bits, the required length of the target CAK can be 16 (bytes). For example, if the length of the target CAK is required to be 256 bits, the required length of the target CAK can be 32 (bytes).

[0246] Scenario 2: The quantum key mixing mode indicates that the target CAK is obtained by mixing the quantum key and the existing CAK.

[0247] In scenario 2, considering that there are multiple mixing modes for obtaining the target CAK based on the quantum key and the existing CAK, the embodiments of the present application also provide a determination method of the target CAK in different mixing modes, thereby improving the application flexibility of the present application. The following will be illustrated by taking scenario 2.1 and scenario 2.2 as examples.

[0248] Scenario 2.1: The target CAK is obtained by mixing the quantum key and the existing CAK through the KDF algorithm in response to the quantum key mixing mode, and the target CAK is determined through the following formula (2): Target CAK = KDF (quantum key, first label, existing CAK, required length of target CAK) (2)

[0249] Wherein, KDF is a key derivation function, and the first label is a string "QKD-CAK".

[0250] Optionally, in the scenario 2.1, when the target CAK is derived through the KDF, the target CAK can also be derived through the KDF based on only the quantum key and the existing CAK, or based on the quantum key / existing CAK and other parameters, which are not exemplified one by one here. In addition, in the scenario 2.1, the target CAK can also be derived through other derivation algorithms other than the KDF, which are also not exemplified one by one here.

[0251] Scenario 2.2: In response to the quantum key mixing mode indication, the quantum key and the existing CAK are mixed through the XOR algorithm to obtain the target CAK, and the target CAK is determined through the following formula (3): target CAK = quantum key xor existing CAK (3)

[0252] XOR represents: XOR calculation is performed on the quantum key and the existing CAK.

[0253] Table 1 is a determination manner of the target CAK under different quantum key mixing modes (mixMode) provided by the embodiment of the application.

[0254] Table 1

[0255] Table 1 provides the values of three quantum key mixing modes, which are 0, 1 and 2. When the value of the quantum key mixing mode is 0, it is used to indicate that the quantum key and the existing CAK are not mixed to obtain the target CAK, in this scenario, the target CAK is derived through the formula shown in the scenario 1 above. When the value of the quantum key mixing mode is 1, it is used to indicate that the quantum key and the existing CAK are mixed to obtain the target CAK, and the target CAK is mixed through the KDF algorithm, in this scenario, the target CAK is derived through the formula shown in the scenario 2.1 above. When the value of the quantum key mixing mode is 2, it is used to indicate that the quantum key and the existing CAK are mixed to obtain the target CAK, and the target CAK is mixed through the XOR algorithm, in this scenario, the target CAK is determined through the manner shown in the scenario 2.2 above.

[0256] In addition, when determining the target CAK, the first application device also needs to determine the target CKN. The implementation manner of the first application device for determining the target CKN based on the quantum key can be: in response to the quantum key mixing mode indication that the quantum key and the existing CAK are not mixed to obtain the target CAK, determining the target CKN based on the quantum key; in response to the quantum key mixing mode indication that the quantum key and the existing CAK are mixed to obtain the target CAK, determining the target CKN based on the quantum key and the existing CNK.

[0257] That is, in the embodiments of the present application, different ways can be used to determine the target CKN in different quantum key mixing modes.

[0258] The following describes how to determine the target CKN in two scenarios.

[0259] Scenario 1: The quantum key mixing mode indicates that the target CAK is not obtained by mixing the quantum key and the existing CAK.

[0260] In scenario 1, the target CKN is determined by the following formula (4):

[0261] Target CKN = KDF (quantum key, second label, key identifier of the quantum key | QKD identifier 1 | QKD identifier 2, required length of the target CKN) (4)

[0262] Wherein, KDF is a key derivation function, the second label is a string "QKD-CKN", QKD identifier 1 is the smaller one of the QKD identifier corresponding to the first application device and the QKD identifier corresponding to the second application device, and QKD identifier 2 is the larger one of the QKD identifier corresponding to the first application device and the QKD identifier corresponding to the second application device.

[0263] For example, when the QKD identifier corresponding to the application device is the QKD identifier of the application device itself, the above formula (4) can be converted into the following formula:

[0264] Target CKN = KDF (quantum key, second label, key identifier of the quantum key | appid 1 | appid 2, required length of the target CKN)

[0265] Wherein, appid 1 is the smaller one of the QKD identifier of the first application device itself and the QKD identifier of the second application device itself, and appid 2 is the larger one of the QKD identifier of the first application device itself and the QKD identifier of the second application device itself.

[0266] The above formula can be used to derive the target CKN from the quantum key, avoiding directly using the identifier of the quantum key as the target CKN.

[0267] It should be noted that the above formula is used to illustrate how to derive the target CKN from the quantum key. Alternatively, when the target CKN is derived by KDF, the target CKN can be derived by KDF based on only the quantum key, or the target CKN can be derived by KDF based on the quantum key and other parameters, which will not be illustrated one by one. In addition, the embodiments of the present application can also derive the target CKN by using other derivation algorithms other than KDF, which will also not be illustrated one by one.

[0268] In addition, the required length of the target CKN is a length pre-configured at the first application device, which can be understood as the required length of the target CKN by the first application device. For example, the length of the target CKN is required to be 16 (bytes).

[0269] Scenario 2: The quantum key mixing mode indicates mixing the quantum key and the existing CAK to obtain the target CAK.

[0270] In scenario 2, the target CKN is determined by the following formula (5):

[0271] Target CKN = KDF (quantum key, second label, key identification of the quantum key | existing CKN, required length of the target CKN) (5)

[0272] Wherein, KDF is a key derivation function, and the second label is a string "QKD-CKN".

[0273] For example, in the aforementioned scenario 2.1 and scenario 2.2, the target CKN can be derived by formula (5).

[0274] It should be noted that the above formula is used to illustrate how to derive the target CKN from the quantum key and the existing CKN. Alternatively, when deriving the target CKN by KDF, the target CKN can be derived by KDF based on only the quantum key and the existing CKN, or based on the quantum key, the existing CKN and other parameters, which will not be illustrated one by one. In addition, the target CKN can also be derived by other derivation algorithms other than KDF in the embodiments of the present application, which will also not be illustrated one by one.

[0275] In other words, the above five formulas are used to illustrate how to determine the target CAK and the target CKN. Alternatively, in the embodiments of the present application, the target CAK and the target CKN can also be determined by other ways, which will not be illustrated one by one.

[0276] Step 8032: The first application device sends a third message to the second application device, and the third message carries quantum key announcement information, which is used to indicate the key information of the quantum key to be announced to the second application device.

[0277] In some embodiments, if the first application device and the second application device directly use the obtained quantum key as the target CAK, the quantum key announcement information can include only the key identification of the quantum key, or can include the key identification of the quantum key and the key length of the quantum key.

[0278] Optionally, in some other embodiments, the quantum key announcement information includes a key identifier of the quantum key, a key length of the quantum key, and a quantum key mixing mode. Alternatively, the quantum key announcement information includes the key identifier of the quantum key and the quantum key mixing mode. The quantum key mixing mode is used to indicate whether the quantum key and an existing CAK are mixed to obtain a target CAK.

[0279] In the embodiments of the present application, in the case that the quantum key mixing mode is configured at the first application device, the first application device also carries the quantum key mixing mode in the quantum key announcement information to announce to the second application device, so that the second application device also determines the target CAK in the manner indicated by the quantum key mixing mode.

[0280] In the application scenarios shown in FIG. 6 and FIG. 7, the existing CAK can be a CAK negotiated between the first application device and the second application device through EAP, or a CAK configured at the first application device and the second application device.

[0281] Further, in response to the quantum key mixing mode indicating that the quantum key and the existing CAK are mixed to obtain the target CAK, the quantum key announcement information further includes an existing CKN, which is an identifier of the existing CAK. That is, in the case that the quantum key mixing mode configured at the first application device is used to indicate that the quantum key and the existing CAK are mixed to obtain the target CAK, the first application device also carries the identifier of the existing CAK, i.e., the existing CKN, in the quantum key announcement information to announce to the second application device, so that the second application device also mixes the quantum key and the existing CAK to obtain the target CAK.

[0282] Correspondingly, in response to the quantum key mixing mode indicating that the quantum key and the existing CAK are not mixed to obtain the target CAK, the quantum key announcement information can not include the existing CKN.

[0283] In addition, the third message also carries an ICV. The ICV is calculated by an ICK on some information in the third message, such as the quantum key announcement information. The ICK can be derived based on the quantum key, can be derived based on the existing CAK, or can be derived based on the target CAK, which is not limited in the embodiments of the present application.

[0284] Optionally, referring to the application scenario shown in FIG. 5, the quantum key announcement information can further include an address of the second QKD device, so that the second application device obtains the quantum key based on the address of the second QKD device. In this way, the second application device does not need to maintain the configuration information of the second QKD device, such as the address of the second QKD device, which expands the application scenarios of the embodiments of the present application.

[0285] For example, the first application device can determine whether the address of the second QKD device needs to be carried in the third message based on the key acquisition mode of the second application device. For example, in the case where the key acquisition mode of the second network device is the passive receiving mode, the third message carries the address of the second QKD device. In the case where the key acquisition mode of the second network device is the active acquisition mode, the third message does not need to carry the address of the second QKD device.

[0286] Optionally, the quantum key announcement information can further include first state information, the first state information being used to indicate whether the active end successfully applies for the quantum key from the QKD network.

[0287] In step 8033, the first application device receives a fourth message from the second application device, the fourth message carrying quantum key confirmation information, the quantum key confirmation information being used to indicate the result of the second application device acquiring the quantum key from the QKD network in response to the third message.

[0288] When receiving the third message, the second application device parses the key identifier of the quantum key from the quantum key announcement information carried in the third message, and then acquires the quantum key from the second QKD device based on the key identifier, and returns the fourth message to the first application device after acquiring the quantum key.

[0289] For example, the quantum key confirmation information includes second state information, the second state information being used to indicate whether the passive end successfully acquires the quantum key from the QKD network.

[0290] Optionally, in the case where the quantum key announcement information includes the quantum key mixing mode and the existing CKN, the quantum key confirmation information can include the existing CKN, which is used to announce the first application device that the second application device has learned that the quantum key needs to be mixed with the existing CAK to obtain the target CAK required in the MKA protocol.

[0291] It should be noted that the process of determining the target CAK and the target CKN based on the quantum key in step 8031 can be implemented before step 8032 and step 8033, or can be implemented after step 8032 and step 8033, which is not limited in the embodiments of the present application.

[0292] In addition, in the embodiments of the present application, the first message, the second message, the third message and the fourth message can be any type of message, for example, a new format of message can be defined. Alternatively, the existing message in the EAPoL can be extended to implement the first message, the second message, the third message and the fourth message provided in the embodiments of the present application. The following will be described in different embodiments.

[0293] Embodiment 1: The first message, the second message, the third message and the fourth message are all EAPoL-Announcement messages.

[0294] FIG. 9 is a schematic diagram of another key determination process according to an embodiment of the present application. As shown in FIG. 9, the first message, the second message, the third message and the fourth message in the key determination method are implemented by using the EAPoL-Announcement messages defined by 802.1X.

[0295] Referring to FIG. 9, the key determination method includes the following steps. The steps are as follows.

[0296] Step 9.0 (not shown in FIG. 9): For each of the first application device and the second application device, the local end is configured with an identifier of the local end in the QKD network, i.e., a QKD identifier, and is configured with a quantum key acquisition priority and a key acquisition mode of the local end.

[0297] Step 9.1: The first application device sends a first EAPoL-Announcement message, i.e., the first message, to the second application device. The first EAPoL-Announcement message includes priority, appid, getKeyMode and the like. The priority field is used to carry the quantum key acquisition priority of the application device, the appid field is used to carry the QKD identifier of the application device, and the getKeyMode field is used to carry the key acquisition mode of the application device. That is, the first QKD information is implemented by using the priority, appid and getKeyMode fields in the first message.

[0298] Step 9.2: After receiving the first EAPoL-Announcement message, the second network device returns a second EAPoL-Announcement message, i.e., the second message, to the first application device. The second EAPoL-Announcement message also includes priority, appid, getKeyMode and the like. That is, the second QKD information is implemented by using the priority, appid and getKeyMode fields in the second message.

[0299] Through the first EAPoL-Announcement message and the second EAPoL-Announcement message, the two parties can elect an active end for acquiring quantum keys.

[0300] Step 9.3: The active end (for example, the first application device is taken as the active end in FIG. 9) initiates a quantum key application to the QKD device (i.e., the first QKD device) of the local end. When applying for a quantum key, the QKD identifier of the first application device and the QKD identifier of the second application device need to be provided to the first QKD device.

[0301] The first QKD device obtains the quantum key to be distributed to the first application device. Since the QKD identity of the second application device is known, the first QKD device can find the second QKD device according to the QKD identity of the second application device, and send the obtained quantum key and the key identity of the quantum key to the second QKD device.

[0302] Step 9.4: The first QKD device returns the quantum key and the key identity of the quantum key to the first application device. In FIG. 9, the quantum key is marked as key, and the key identity of the quantum key is marked as keyID.

[0303] Step 9.5: The first application device sends a third EAPoL-Announce message, i.e., a third message, to the second application device to inform the key obtaining situation. The third EAPoL-Announce message includes fields such as keyID, keylen, mixMode, and mixedCKN. The keyID is used to carry the key identity of the quantum key, the keylen is used to carry the key length of the quantum key, the mixMode is used to carry the quantum key mixing mode, and the mixedCKN is used to carry the existing CKN.

[0304] As shown in FIG. 9, the third EAPoL-Announce message further includes fields such as status, config, and ICV. The status in the third EAPoL-Announce message is used to carry first status information, which is used to indicate whether the first application device successfully applies for the quantum key. The config is used to carry the address of the second QKD device.

[0305] That is, the first status information, the address of the second QKD device, the key identity, the key length, the quantum key mixing mode, and the existing CKN in the quantum key announcement information are implemented by the fields of status, config, keyID, keylen, mixMode, and mixedCKN, respectively.

[0306] Step 9.6: The second application device receives the third EAPoL-Announce message and applies for the quantum key from the second QKD device. When applying, the second application device needs to provide the key identity of the quantum key to the second QKD device.

[0307] Step 9.7: The second QKD device returns the obtained quantum key and the key identity of the quantum key to the second application device.

[0308] The second application device compares the key length of the quantum key returned by the second QKD device with the length indicated by the keylen carried in the third EAPoL-Announce message. When the two lengths are consistent, the ICK is derived based on the quantum key, and the ICV of the third EAPoL-Announce message is verified based on the ICK.

[0309] Step 9.8: After the integrity check passes, the second application device returns a fourth EAPoL-Announcement packet to the first application device. The fourth EAPoL-Announcement packet carries fields such as status, mixedCKN and ICV. The status in the fourth EAPoL-Announcement packet is used to carry second status information, which is used to indicate whether the passive end has obtained the quantum key. The mixedCKN in the fourth EAPoL-Announcement packet is used to carry the existing CKN. That is, the second status information and the existing CKN in the quantum key confirmation information are implemented through the status and mixedCKN fields, respectively.

[0310] Step 9.9: The communication parties mix the quantum key and the existing CAK according to the mixMode and the mixedCKN to obtain a target CAK.

[0311] The first application device and the second application device send a packet for electing a key server based on the target CAK and the target CKN obtained in the previous nine steps, to negotiate the key server. In this way, the quantum key obtaining process of the passive end is not as shown in the processes of FIG. 3 and FIG. 4: it must occur after receiving the key election packet of the opposite end. Therefore, the embodiment shown in FIG. 9 completely decouples the process of obtaining the quantum key of the communication parties from the key server election process, to avoid the process of obtaining the quantum key affecting the subsequent key server process.

[0312] It should be noted that FIG. 9 is an example in which step 9.9 is executed after step 9.8. Alternatively, the active end can execute step 9.9 directly after step 9.4, and the passive end can execute step 9.9 directly after step 9.7, which is not limited in the embodiments of the present application.

[0313] FIG. 10 is a format diagram of an EAPoL-Announcement packet provided by an embodiment of the present application. As shown in FIG. 10, the EAPoL-Announcement packet includes fields such as Protocol Version, Packet Type, Packet Body Length and Packet Body. The Packet Body includes multiple type-length-value (TLV). The Packet Type takes the value of EAPoL-Announcement, which is used to indicate that the current packet is an EAPoL-Announcement packet.

[0314] Based on the message format shown in FIG. 10, the first EAPoL-Advertisement message and the second EAPoL-Advertisement message can each include a first extended TLV, T in the first extended TLV is a type of extension, L is used to indicate the total length of the first extended TLV, and V can further include a plurality of sub-TLVs, V in each sub-TLV is used to carry one of the black bold fields in the first message or the second message shown in FIG. 9. For example, V in the first extended TLV includes three sub-TLVs, V in the three sub-TLVs is respectively used to carry the priority, appid, and getKeyMode fields. Among them, T and L in each sub-TLV can be flexibly set according to requirements. Thus, the first EAPoL-Advertisement message and the second EAPoL-Advertisement message in steps 9.1 and 9.2 are realized.

[0315] Based on the message format shown in FIG. 10, the third EAPoL-Advertisement message can include a second extended TLV, T in the second extended TLV is a type of extension, L is used to indicate the total length of the second extended TLV, and V can further include a plurality of sub-TLVs, V in each sub-TLV is used to carry one of the black bold fields in the third message shown in FIG. 9. For example, V in the second extended TLV includes seven sub-TLVs, V in the seven sub-TLVs is respectively used to carry the status, config, keyID, keylen, mixMode, mixedCKN, and ICV fields. Among them, T and L in each sub-TLV can be flexibly set according to requirements. Thus, the third EAPoL-Advertisement message in step 9.5 is realized.

[0316] Based on the message format shown in FIG. 10, the fourth EAPoL-Advertisement message includes a third extended TLV, T in the third extended TLV is a type of extension, L is used to indicate the total length of the third extended TLV, and V can further include a plurality of sub-TLVs, V in each sub-TLV is used to carry one of the black bold fields in the third message shown in FIG. 9. For example, V in the third extended TLV includes three sub-TLVs, V in the three sub-TLVs is respectively used to carry the status, mixedCKN, and ICV fields. Among them, T and L in each sub-TLV can be flexibly set according to requirements. Thus, the fourth EAPoL-Advertisement message in step 9.8 is realized.

[0317] It should be noted that T in the first extended TLV, the second extended TLV, and the third extended TLV can be the same extension type or different extension types, and the embodiments of the present application do not limit this.

[0318] In addition, FIG. 10 is used to illustrate how to extend the EAPoL-Announce packet to obtain the first packet, the second packet, the third packet and the fourth packet required by the embodiment of the present application. Alternatively, the EAPoL-Announce packet can also be extended in other manners, as long as the extended EAPoL-Announce packet can carry the information required in the first packet, the second packet, the third packet and the fourth packet. The embodiment of the present application does not limit this.

[0319] Embodiment 2: The first packet, the second packet, the third packet and the fourth packet are all EAPoL-Key packets.

[0320] FIG. 11 is another key determination flowchart provided by the embodiment of the present application. As shown in FIG. 11, the first packet, the second packet, the third packet and the fourth packet in the key determination method are implemented by using the EAPoL-Key packet defined by 802. IX.

[0321] The implementation of steps 11.1 to 11.9 in FIG. 11 can refer to the implementation of steps 9.1 to 9.9 in Embodiment 1, and the difference is that the formats of the first packet, the second packet, the third packet and the fourth packet are different.

[0322] FIG. 12 is a format diagram of an EAPoL-Key packet provided by the embodiment of the present application. As shown in FIG. 12, the EAPoL-Key packet includes a protocol version number (Protocol Version), a packet type (Packet Type), a packet body length (Packet Body Length) and a packet body (Packet Body), etc. The packet body includes one or more descriptors, and each descriptor includes a descriptor type (Descriptor Type) and a descriptor body (Descriptor Body) corresponding to the descriptor type. The packet type takes the value of EAPoL-Key, which is used to indicate that the current packet is an EAPoL-Key packet.

[0323] Based on the message format shown in FIG. 12, the first EAPoL-key message and the second EAPoL-key message can each include a first extension descriptor, the first extension descriptor including a first extension descriptor type, and a descriptor body corresponding to the first extension descriptor type can further include a plurality of TLVs, V in each TLV being used to carry one of the black bold fields in the first message or the second message shown in FIG. 11. For example, the descriptor body corresponding to the first extension descriptor includes three TLVs, V in the three TLVs being used to carry the priority, the appid, and the getKeyMode fields respectively. Wherein, T and L in each TLV can be flexibly set according to requirements. Thus, the first EAPoL-key message and the second EAPoL-key message in steps 11.1 and 11.2 are implemented.

[0324] Based on the message format shown in FIG. 12, the third EAPoL-key message can include a second extension descriptor, the second extension descriptor including a second extension descriptor type, and a descriptor body corresponding to the second extension descriptor type can further include a plurality of TLVs, V in each TLV being used to carry one of the black bold fields in the third message shown in FIG. 11. For example, the descriptor body corresponding to the second extension descriptor includes seven TLVs, V in the seven TLVs being used to carry the status, the config, the keyID, the keylen, the mixMode, the mixedCKN, and the ICV fields respectively. Wherein, T and L in each TLV can be flexibly set according to requirements. Thus, the third EAPoL-key message in step 11.5 is implemented.

[0325] Based on the message format shown in FIG. 12, the fourth EAPoL-key message includes a third extension descriptor, the third extension descriptor including a third extension descriptor type, and a descriptor body corresponding to the third extension descriptor type can further include a plurality of TLVs, V in each TLV being used to carry one of the black bold fields in the fourth message shown in FIG. 11. For example, the descriptor body corresponding to the third extension descriptor includes three TLVs, V in the three TLVs being used to carry the status, the mixedCKN, and the ICV fields respectively. Wherein, T and L in each sub-TLV can be flexibly set according to requirements. Thus, the fourth EAPoL-key message in step 11.8 is implemented.

[0326] It should be noted that the first extension descriptor type, the second extension descriptor type, and the third extension descriptor type can be the same extension type or different extension types, and the embodiments of the present application do not limit this.

[0327] In addition, FIG. 12 is used to illustrate how to extend the EAPoL-Key packet to obtain the first packet, the second packet, the third packet and the fourth packet required by the embodiment of the application. Alternatively, the EAPoL-Key packet can also be extended in other manners, as long as the extended EAPoL-Key packet can carry the required information in the first packet, the second packet, the third packet and the fourth packet. The embodiment of the application does not limit this.

[0328] In the embodiment of the application, the first application device and the second application device determine the target CAK and the target CKN through the session indicated by the first session identifier.

[0329] In the embodiment of the application, the first application device and the second application device can also perform multiple key determination schemes shown in FIG. 8 in parallel to determine multiple target CAKs and multiple CKNs in parallel. In this scenario, in order to distinguish the key determination schemes executed in parallel, the first packet, the second packet, the third packet and the fourth packet can also carry the same session identifier, which is used to uniquely identify a session including the first packet, the second packet, the third packet and the fourth packet.

[0330] For example, if the first application device and the second application device have interacted with two batches of first packets, second packets, third packets and fourth packets in parallel, wherein the first packet, the second packet, the third packet and the fourth packet in the first batch of packets carry the first session identifier, and the first packet, the second packet, the third packet and the fourth packet in the second batch of packets carry the second session identifier, the target CAK determined by the first application device and the second application device through the session indicated by the first session identifier is different from the target CAK determined through the session indicated by the second session identifier. The target CKN determined by the first application device and the second application device through the session indicated by the first session identifier is different from the target CKN determined through the session indicated by the second session identifier.

[0331] It should be noted that since multiple QKD identifiers are allowed to be configured on the same application device, the QKD identifier used in the first packet in different sessions can be the same or different. The embodiment of the application does not limit this. In the scenario where the QKD identifier used in the first packet in two sessions is the same, and the QKD identifier used in the second packet in the two sessions is also the same, the quantum keys obtained by the active end are still different quantum keys. In this scenario, multiple quantum keys can be obtained in parallel for a pair of QKD identifiers through the embodiment 3.

[0332] FIG. 13 is another flowchart of a key determination method according to an embodiment of the present application. FIG. 13 is described by taking an example of the first message, the second message, the third message and the fourth message all being EAPoL-Announce messages. Alternatively, the embodiment 3 can also be applied to the message format shown in the embodiment 2, and the subsequent description is not expanded.

[0333] As shown in FIG. 13, steps 13.1-13.9 in the flowchart shown in FIG. 13 are basically the same as steps 9.1-9.9 in the flowchart shown in FIG. 9, and the difference is that the same session identifier (sessionID) is added in each EAPoL-Announce message.

[0334] Suppose that step 13.1 is performed in step 13.2, in step 13.1, the value of the session identifier is generated by the first application device on this side, and the session identifier is carried in the first EAPoL-Announce message to announce to the second application device.

[0335] In step 13.2, after receiving the first EAPoL-Announce message, the second application device carries the session identifier in the second EAPoL-Announce message and returns it to the first application device.

[0336] In step 13.5, the third EAPoL-Announce message is sent by the first application device, and the session identifier is carried in the third EAPoL-Announce message.

[0337] In step 13.5, the fourth EAPoL-Announce message is returned by the second application device to the first application device, and the session identifier is also carried in the fourth EAPoL-Announce message.

[0338] In addition, the session in the embodiment 3 can also be referred to as a link, and the session identifier can be referred to as a link identifier accordingly.

[0339] Embodiment 4: The quantum key obtained by the first application device from the QKD network includes multiple quantum keys, and accordingly, the quantum key announcement information carried in the third message is used to indicate the key information of the multiple quantum keys to be announced to the second application device. In this scenario, the quantum key obtained by the second application device from the QKD network includes at least one of the multiple quantum keys. Accordingly, the target CAK includes at least one target CAK corresponding to the at least one quantum key, and the target CKN includes at least one target CKN corresponding to the at least one quantum key.

[0340] In the embodiment 4, the first application device as the active end can obtain multiple quantum keys when obtaining the quantum key from the QKD network, and then announce the key information corresponding to each quantum key in the multiple quantum keys to the second application device through one second message.

[0341] Correspondingly, the second application device obtains the plurality of quantum keys from the QKD network based on the key information of each quantum key in the plurality of quantum keys, and the two parties respectively determine the target CAK and the target CAN based on the plurality of quantum keys. Alternatively, the second application device can only obtain part of the plurality of quantum keys, in which case the two parties respectively determine the target CAK and the target CAN based on the part of the plurality of quantum keys. Wherein, the part of the plurality of quantum keys can be understood as: one of the plurality of quantum keys, or at least two of the plurality of quantum keys.

[0342] FIG. 14 is another key determination flowchart provided by the embodiments of the present application. FIG. 14 is illustrated by taking the first message, the second message, the third message and the fourth message as EAPoL-Advertisement messages. Alternatively, the embodiments 4 can also be applied to the message format shown in the embodiments 2, which will not be expanded in the following.

[0343] As shown in FIG. 14, the steps 14.1 and 14.2 are respectively consistent with the steps 9.1 and 9.2 in FIG. 9, which will not be repeated.

[0344] In step 14.3, the first application device can call the key obtaining interface (Get Key API) to obtain a plurality of quantum keys at a time, or call the key obtaining interface to obtain the plurality of quantum keys one by one in multiple times, and the specific mode depends on the function of the key obtaining interface.

[0345] In step 14.4, the first QKD device returns the plurality of quantum keys to the first application device.

[0346] In step 14.5, the plurality of quantum keys corresponding key information is announced through the third message. As shown in FIG. 14, the third message includes a stutas field and a qkd-key-list field. The information carried by the stutas field in the third message is used to indicate whether the first application device successfully obtains the quantum key, that is, the stutas field is used to carry the first state information. The qkd-key-list field includes the config, KeyID, KeyLen, mixMode, mixedCKN and ICV fields corresponding to each quantum key in the plurality of quantum keys, so as to announce the key information of each quantum key through these fields.

[0347] In steps 14.6 and 14.7, the second application device batch obtains the plurality of quantum keys from the second QKD device, and obtains at least one quantum key in the plurality of quantum keys.

[0348] In step 14.8, the second application device delivers quantum key confirmation information to the first application device through a fourth message to inform the first application device of the result of obtaining the quantum key by the second application device. As shown in FIG. 14, the fourth message includes a stutas field and a qkd-key-confirm-list field. The stutas field in the fourth message carries information for indicating the result of obtaining the quantum key by the second application device, that is, the stutas field is used to carry second status information. The qkd-key-confirm-list field includes mixedCKN and ICV corresponding to each of the at least one quantum key, so as to inform the second application device of obtaining the at least one quantum key through the fields.

[0349] Both parties save the at least one target CAK successfully negotiated and the target CKN corresponding to each of the at least one target CAK. Then both parties can perform key server election, in which both parties can select a CAK from the at least one target CAK according to a certain rule for initiating a subsequent key server election process. The specific selection rule is not limited in the embodiments of the present application.

[0350] Embodiment 5: The first message and the second message are both EAPoL-Advertisement messages; the third message and the fourth message are first type EAPoL-MKA messages, and the first type EAPoL-MKA messages are used for electing a key server.

[0351] In embodiment 5, after the first application device and the second application device complete the interaction of the QKD information through the EAPoL-Advertisement messages, the first application device as the active end can directly initiate the key server election process after actively obtaining the quantum key, and can carry the quantum key information obtained in the first type EAPoL-MKA message used for electing the key server, so as to shorten the total time length required for negotiating the SAK.

[0352] FIG. 15 is a schematic diagram of another key determination process provided by the embodiments of the present application. As shown in FIG. 15, the key determination process includes several steps shown in FIG. 15.

[0353] As shown in FIG. 15, steps 15.1 to 15.4 are consistent with steps 9.1 to 9.4 shown in FIG. 9 respectively, and will not be described herein again.

[0354] In step 15.4, after the first application device successfully obtains the quantum key, the first application device directly initiates the key server election process.

[0355] In step 15.5, the first application device sends a third message, and the format of the third message is a first type EAPoL-MKA message, so as to initiate the key server election process through the first type EAPoL-MKA message.

[0356] The third message includes not only the basic parameter set and the ICV for electing the key server, but also an extended parameter set for carrying quantum key announcement information, including status, config, keyID, keyLen, mixMode, mixedCKN, and the like.

[0357] The basic parameter set carries a CKN for negotiating the key server between the two parties. The CKN in the basic parameter set can be an existing CKN or a target CKN determined based on the quantum key, and the embodiments of the present application do not limit this. In addition, the ICK used to determine the ICV can also be derived based on an existing CAK or derived based on a mixed target CAK, and the embodiments of the present application do not limit this either.

[0358] For example, if the mixMode indicates that the quantum key is not mixed with the existing CAK to obtain the target CAK, the CKN in the basic parameter set can be a target CKN of the target CAK determined by the quantum key, and the specific determination manner can refer to the embodiment shown in FIG. 8. Correspondingly, the ICV is calculated by the ICK derived from the target CAK. If the mixMode indicates that the quantum key is mixed with the existing CAK to obtain the target CAK, the CKN in the basic parameter set can be an existing CKN corresponding to the existing CAK, and correspondingly, the ICV can be calculated by the ICK derived from the existing CAK.

[0359] In step 15.6, the second application device parses the third message to obtain the key identifier of the quantum key, and then obtains the quantum key from the second QKD device based on the key identifier of the quantum key.

[0360] In step 15.7, the second QKD device returns the quantum key and the key identifier of the quantum key to the second application device.

[0361] The second application device derives the ICK in the manner in step 15.5 to verify the integrity of the third message.

[0362] In step 15.8, if the integrity verification of the third message is successful, the second application device returns a fourth message to the first application device. The fourth message is in the format of the first type of EAPoL-MKA message, so as to respond to the key server election process initiated by the first application device through the first type of EAPoL-MKA message. As shown in FIG. 15, the fourth message includes a basic parameter set and an extended parameter set. The basic parameter set is used for key server election. The extended parameter set is used to carry quantum key confirmation information, including status, mixedCKN, and the like.

[0363] The first application device checks the integrity of the fourth message upon receiving the fourth message, and elects a key server if the check passes, and then the elected key server leads the distribution process of the SAK based on the target CAK. The process is not repeated here.

[0364] FIG. 16 is a format of a first type of EAPoL-MKA message according to an embodiment of the present application. As shown in FIG. 16, the first type of EAPoL-MKA message includes fields such as a protocol version, a packet type, a packet body length, and a packet body. The packet body includes a basic parameter set, one or more parameter sets, and an ICV. The packet type takes a value of EAPoL-MKA, indicating that the current message is an EAPoL-MKA message.

[0365] Based on the message format shown in FIG. 16, the third message includes a first extension parameter set, and the first extension parameter set includes six TLVs. The V in each of the six TLVs includes fields such as status, config, keyID, keylen, mixMode, and mixedCKN. Thus, the third message shown in FIG. 15 is implemented.

[0366] Based on the message format shown in FIG. 16, the fourth message includes a second extension parameter set, and the second extension parameter set includes two TLVs. The V in each of the two TLVs includes fields such as status and mixedCKN. Thus, the fourth message shown in FIG. 15 is implemented.

[0367] Embodiment 6: The first application device and the second application device synchronize the QKD information through the first type of EAPoL-MKA for electing a key server, and at the same time, complete the negotiation operation of the key server and the active end. Since the elected key server and the active end can be the same application device or different application devices, the following describes the embodiment 6 in two cases.

[0368] Case 1: The elected key server and the active end are the same application device.

[0369] In case 1, it is assumed that the elected key server and the active end are both the first application device. In this scenario, the first message and the second message are the first type of EAPoL-MKA messages, which are used for electing the key server; the third message is the second type of EAPoL-MKA message, which is used for distributing the security association key SAK; and the fourth message is the third type of EAPoL-MKA message, which is used for announcing that the second application device has used the distributed SAK.

[0370] FIG. 17 is a schematic diagram of another key determination process provided by an embodiment of the present application.

[0371] As shown in FIG. 17, in step 17.1, the first application device sends a first message to the second application device, and the first message includes a basic parameter set, an extended parameter set, and an ICV. The basic parameter set includes parameters required for electing a key server, and the extended parameter set is used to carry first QKD information such as priority, appid, and getkeyMode.

[0372] In step 17.2, the second application device sends a second message to the first application device, and the second message includes a basic parameter set, an extended parameter set, and an ICV. The basic parameter set includes parameters required for electing a key server, and the extended parameter set is used to carry second QKD information such as priority, appid, and getkeyMode.

[0373] Through steps 17.1 and 17.2, when the first application device determines that the local end is both the active end and the key server, the first application device acquires quantum keys from the first QKD device based on steps 17.3 and 17.4.

[0374] In step 17.5, after acquiring the quantum keys, the first application device determines a target CAK based on the quantum keys, determines a SAK to be distributed, and then returns a third message in the form of the second type of EAPoL-MKA message to the second application device. The third message includes a basic parameter set, a distributed-sak parameter set, and an extended parameter set. The distributed-sak parameter set is used to carry the SAK to be distributed, and the carried SAK is an encrypted SAK. The extended parameter set is used to carry quantum key announcement information such as status, config, keyID, keylen, mixMode, and mixedCKN.

[0375] In steps 17.6 and 17.7, after receiving the third message, the second application device acquires quantum keys based on the quantum key announcement information.

[0376] In step 17.8, the second application device determines the target CAK based on the quantum key, and then obtains the decrypted SAK based on the target CAK, and checks the integrity of the third message based on the target CAK. After the integrity of the third message is checked, the fourth message in the format of the third type of EAPoL-MKA message is returned to the first application device. The fourth message includes a basic parameter set, a sak-use parameter set, and an extension parameter set. The sak-use parameter set is used to carry the information of the SAK that has been used, such as the key number of the SAK. The extension parameter set is used to carry quantum key confirmation information such as status and mixedCKN.

[0377] After the first application device receives the fourth message, the ICV is verified based on the target CAK. If the verification is passed, it indicates that the second application device has obtained the same target CAK, and has obtained the same SAK based on the target CAK.

[0378] Case 2: The elected key server and the active end are different application devices.

[0379] In case 2, it is assumed that the elected active end is the first application device, and the key server is the second application device. In this scenario, the first message and the second message are the first type of EAPoL-MKA message, which is used to elect the key server; the third message is the first type of EAPoL-MKA message, and the fourth message is the second type of EAPoL-MKA message, which is used to distribute the security association key SAK.

[0380] FIG. 18 is another key determination flow diagram provided by an embodiment of the present application.

[0381] As shown in FIG. 18, in step 18.1, the first application device sends a first message to the second application device. The first message includes a basic parameter set, an extension parameter set, and an ICV. The basic parameter set includes parameters required for electing a key server, and the extension parameter set is used to carry first QKD information such as priority, appid, and getKeyMode.

[0382] In step 18.2, the second application device sends a second message to the first application device. The second message includes a basic parameter set, an extension parameter set, and an ICV. The basic parameter set includes parameters required for electing a key server, and the extension parameter set is used to carry second QKD information such as priority, appid, and getKeyMode.

[0383] Through step 18.1 and step 18.2, the first application device determines that the local end is the active end but is not the key server, and obtains the quantum key from the first QKD device based on step 18.3 and step 18.4.

[0384] In step 18.5, after obtaining the quantum key, the first application device needs to first transmit quantum key announcement information such as status, config, keyID, keylen, mixMode, and mixedCKN to the second application device through a third message in the form of a first type of EAPoL-MKA message.

[0385] In step 18.6 and step 18.7, after receiving the quantum key announcement information, the second application device obtains the same quantum key based on the quantum key announcement information, and determines the target CAK based on the quantum key.

[0386] In step 18.8, since the second application device is currently the key server, after determining the target CAK, the second application device further determines the SAK to be distributed, and then returns a fourth message in the form of a second type of EAPoL-MKA message to the first application device, wherein the fourth message includes a basic parameter set, a distributed-sak parameter set for carrying the SAK to be distributed, and an extended parameter set, and the SAK carried in the distributed-sak parameter set is an encrypted SAK. The extended parameter set is used to carry quantum key confirmation information such as status and mixedCKN.

[0387] After receiving the fourth message, the first application device determines that the opposite end has obtained the quantum key based on the quantum key confirmation information, and then verifies the ICV in the fourth message through the ICK derived from the target CAK. After verification, it is indicated that the second application device also obtains the same target CAK. Finally, the decrypted SAK is obtained based on the target CAK, and the SAK is used.

[0388] In step 18.9, the first device returns a fifth message in the form of a third type of EAPoL-MKA message to the second application device. The fifth message includes a basic parameter set and a key-use parameter set.

[0389] It should be noted that the above embodiments 1 to 6 are only used to illustrate the implementation mode of the first message, the second message, the third message, and the fourth message, and do not constitute a limitation on the first message, the second message, the third message, and the fourth message provided by the embodiments of the application. The numbers of the six embodiments are only used to distinguish different embodiments.

[0390] To sum up, in the embodiment of the application, two application devices in the QKD network negotiate who is the active end for obtaining quantum keys by interacting QKD information, and then determine the target CAK and the target CKN required for communication between the two parties using the MKA protocol based on the obtained quantum keys. On the one hand, it is not necessary to pre-configure who is the active end and who is the passive end by technical personnel, so as to simplify the configuration process. On the other hand, the two parties of communication interact the QKD information of the local end in the embodiment of the application, so it is not necessary to pre-configure the QKD information of the opposite end, such as the QKD identifier, on each application device, and the embodiment of the application negotiates who is the active end for obtaining quantum keys by interacting the QKD information of the two parties of communication, instead of directly taking the key server as the active end for obtaining quantum keys, so as to avoid that the two parties of communication cannot realize the communication based on the MKA protocol due to the fact that the key server does not have the capability of actively obtaining quantum keys, and the application range is wide.

[0391] FIG. 19 is a flowchart of another key determination method 1900 provided by the embodiment of the application. As shown in FIG. 19, the method 1900 includes the following steps.

[0392] Step 1901: The second application device receives a first message from the first application device, the first message carrying first QKD information, the first QKD information being used to indicate the configuration information of the first application device in the QKD network.

[0393] Step 1902: The second application device sends a second message to the first application device, the second message carrying second QKD information, the second QKD information being used to indicate the configuration information of the second application device in the QKD network.

[0394] Step 1903: In response to the fact that the second application device determines that the local end is not the active end for obtaining quantum keys based on the first message and the second message, the second application device performs the following steps 19031-19033.

[0395] Step 19031: Receive a third message from the first application device, the third message carrying quantum key announcement information, the quantum key announcement information being used to indicate the key information of the quantum key which needs to be announced to the second application device.

[0396] Step 19032: Obtain the quantum key from the QKD network based on the third message, and determine the target CAK and the target CKN based on the quantum key, the target CAK and the target CKN being the CAK and the CKN required for communication between the first application device and the second application device using the MKA protocol.

[0397] Step 19033: sending a fourth message to the first application device, the fourth message carrying quantum key confirmation information, the quantum key confirmation information being used to indicate a result of the second application device obtaining a quantum key from the QKD network in response to the third message.

[0398] Wherein, each step in the embodiment shown in FIG. 19 has been described in the foregoing embodiments, and will not be repeated here.

[0399] The basic hardware structure of the application device is described below.

[0400] For example, FIG. 20 is a schematic diagram of a hardware structure of an application device 2000 provided by an embodiment of the present application. The first application device or the second application device in the foregoing embodiments can be implemented by the structure shown in FIG. 20.

[0401] As shown in FIG. 20, the application device 2000 includes a processor 2001 and a memory 2002, and the memory 2001 and the memory 2002 are connected through a bus 2003. FIG. 20 illustrates that the processor 2001 and the memory 2002 are independent of each other. Alternatively, the processor 2001 and the memory 2002 are integrated together.

[0402] Wherein, the memory 2002 is used to store a computer program, and the computer program includes an operating system and a program code. The memory 2002 is various types of storage media, such as a read-only memory (ROM), a random access memory (RAM), an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM), a flash memory, an optical memory, a register, an optical disc storage, a light disc storage, a magnetic disk or other magnetic storage devices.

[0403] Wherein, the processor 2001 is a general-purpose processor or a special-purpose processor. The processor 2001 can be a single-core processor or a multi-core processor. The processor 2001 includes at least one circuit to perform the actions of the application device in the above method 800 or method 1900 provided by an embodiment of the present application.

[0404] Optionally, the application device 2000 further includes a network interface 2004 connected with the processor 2001 and the memory 2002 through the bus 2003. The network interface 2004 can enable the application device 2000 to communicate with the QKD device or other application devices. The processor 2001 can interact with the QKD device through the network interface 2004 to register a service object, obtain a quantum key, and the like, and communicate with other application devices, and the like.

[0405] Optionally, the application device 2000 further includes an input / output (I / O) interface 2005 connected with the processor 2001 and the memory 2002 through the bus 2003. The processor 2001 can receive an input command or data, and the like, through the I / O interface 2005. The I / O interface 2005 is used for the application device 2000 to connect with input devices, such as a keyboard, a mouse, and the like. Optionally, in some possible scenarios, the network interface 2004 and the I / O interface 2005 are collectively referred to as a communication interface.

[0406] Optionally, the application device 2000 further includes a display 2006 connected with the processor 2001 and the memory 2002 through the bus 2003. The display 2006 can be used to display an intermediate result and / or a final result, and the like, generated by the processor 2001 executing the above method, for example, to display an alarm prompt. In a possible implementation manner, the display 2006 is a touch display screen, to provide a human-computer interaction interface.

[0407] The bus 2003 is any type of communication bus used for interconnecting internal devices of the application device 2000. For example, a system bus. The above devices inside the application device 2000 are interconnected through the bus 2003 in the embodiments of the application, and optionally, the above devices inside the application device 2000 are communicatively connected with each other in other connection manners other than the bus 2003, for example, the above devices inside the application device 2000 are interconnected through a logical interface inside the application device 2000.

[0408] The above devices can be respectively arranged on independent chips, or at least part or all of the above devices can be arranged on the same chip. Whether to arrange each device on a separate chip or to integrate the devices on one or more chips often depends on the needs of product design. The embodiments of the application do not limit the specific implementation forms of the above devices.

[0409] The application device 2000 shown in FIG. 20 is merely exemplary. In actual implementation, the application device 2000 includes other components, which are not listed here. The application device 2000 shown in FIG. 20 can implement the transmission of the quantum key by executing all or part of the steps of the method provided in the above-described embodiments.

[0410] The virtual device of the embodiments of the present application is described below.

[0411] FIG. 21 is a structural schematic diagram of an application device 2100 provided by the embodiments of the present application. The application device having the structure shown in FIG. 21 implements the functions of the first application device or the second application device in the schemes described in the above-described embodiments. As shown in FIG. 21, the application device 2100 includes a sending module 2101, a receiving module 2102, and a processing module 2103.

[0412] When the application device shown in FIG. 21 is the first application device in the foregoing embodiments, each module shown in FIG. 21 has the following functions.

[0413] The sending module 2101 is configured to send a first message to a second application device, the first message carrying first quantum key distribution (QKD) information, the first QKD information being used to indicate configuration information of the first application device in a QKD network. For a specific implementation, reference can be made to the embodiment of FIG. 8.

[0414] The receiving module 2102 is configured to receive a second message from the second application device, the second message carrying second QKD information, the second QKD information being used to indicate configuration information of the second application device in the QKD network. For a specific implementation, reference can be made to the embodiment of FIG. 8.

[0415] The processing module 2103 is configured to, in response to determining that a local end is an active end for obtaining a quantum key based on the first message and the second message, obtain the quantum key from the QKD network, and determine a target security connection association key (CAK) and a target security connection association key name (CKN) based on the quantum key, the target CAK and the target CKN being CAK and CKN required for the first application device and the second application device to communicate using a media access control security key agreement (MKA) protocol. For a specific implementation, reference can be made to the embodiment of FIG. 8.

[0416] The sending module 2101 is further configured to send a third message to the second application device, the third message carrying quantum key announcement information, the quantum key announcement information being used to indicate key information of a quantum key that needs to be announced to the second application device. For a specific implementation, reference can be made to the embodiment of FIG. 8.

[0417] The receiving module 2102 is further configured to receive a fourth message from the second application device, the fourth message carrying quantum key confirmation information, the quantum key confirmation information being used to indicate a result of the second application device obtaining a quantum key from the QKD network in response to the third message. The specific implementation can refer to the embodiment of FIG. 8.

[0418] In a possible implementation, the first QKD information includes a QKD identifier corresponding to the first application device and a quantum key obtaining priority of the first application device, and the second QKD information includes a QKD identifier corresponding to the second application device and a quantum key obtaining priority of the second application device.

[0419] In a possible implementation, the first QKD information further includes a key obtaining mode of the first application device, and the second QKD information further includes a key obtaining mode of the second application device; the key obtaining mode includes an active obtaining mode and a passive receiving mode, the active obtaining mode being used to indicate that the corresponding application device can actively obtain a quantum key from the QKD network, and the passive receiving mode being used to indicate that the corresponding application device needs to obtain a quantum key from the QKD network based on an indication of another application device.

[0420] In a possible implementation, the first QKD information includes a QKD identifier corresponding to the first application device and a key obtaining mode of the first application device, and the second QKD information includes a QKD identifier corresponding to the second application device and a key obtaining mode of the second application device; the key obtaining mode includes an active obtaining mode and a passive receiving mode, the active obtaining mode being used to indicate that the corresponding application device can actively obtain a quantum key from the QKD network, and the passive receiving mode being used to indicate that the corresponding application device needs to obtain a quantum key from the QKD network based on an indication of another application device.

[0421] In a possible implementation, the first QKD information further includes a quantum key obtaining priority of the first application device, and the second QKD information further includes a quantum key obtaining priority of the second application device.

[0422] In a possible implementation, the first message and the second message each include a reference field, the reference field including a first bit sequence and a second bit sequence, a bit value corresponding to the first bit sequence being used to indicate a key obtaining mode of the corresponding application device, and a bit value corresponding to the second bit sequence being used to indicate a quantum key obtaining priority of the corresponding application device.

[0423] In a possible implementation, the quantum key announcement information includes a key identifier of the quantum key, a key length of the quantum key, and a quantum key mixing mode, the quantum key mixing mode being used to indicate whether to mix the quantum key and an existing CAK to obtain a target CAK.

[0424] In a possible implementation, the existing CAK is a CAK negotiated between the first application device and the second application device through an extensible authentication protocol (EAP), or is a CAK configured at the first application device and the second application device.

[0425] In a possible implementation, in response to the quantum key mixing mode instruction indicating that the quantum key and the existing CAK are mixed to obtain the target CAK, the quantum key announcement information further includes an existing CKN, and the existing CKN is an identifier of the existing CAK; and the quantum key confirmation information includes the existing CKN.

[0426] In a possible implementation, the processing module 2103 is configured to: in response to the quantum key mixing mode instruction indicating that the quantum key and the existing CAK are not mixed to obtain the target CAK, determine the target CAK based on the quantum key; and in response to the quantum key mixing mode instruction indicating that the quantum key and the existing CAK are mixed to obtain the target CAK, determine the target CAK based on the quantum key and the existing CAK.

[0427] In a possible implementation, the processing module 2103 is configured to: determine the target CAK by using the following formula:

[0428] Target CAK = KDF (quantum key, first label, QKD identifier 1 | QKD identifier 2, required length of the target CAK).

[0429] wherein KDF is a key derivation function, the first label is QKD-CAK, QKD identifier 1 is a smaller one of a QKD identifier corresponding to the first application device and a QKD identifier corresponding to the second application device, and QKD identifier 2 is a larger one of the QKD identifier corresponding to the first application device and the QKD identifier corresponding to the second application device.

[0430] In a possible implementation, the processing module 2103 is configured to: in response to the quantum key mixing mode instruction indicating that the quantum key and the existing CAK are mixed to obtain the target CAK, determine the target CAK by using the following formula:

[0431] Target CAK = KDF (quantum key, first label, existing CAK, required length of the target CAK), wherein KDF is a key derivation function, and the first label is QKD-CAK.

[0432] In response to the quantum key mixing mode instruction indicating that the quantum key and the existing CAK are mixed to obtain the target CAK by using an exclusive or algorithm, the quantum key and the existing CAK are calculated by using the exclusive or algorithm to obtain the target CAK.

[0433] In a possible implementation, the processing module 2103 is configured to: in response to the quantum key mixing mode indicating that the quantum key and the existing CAK are not mixed to obtain the target CAK, determine the target CKN based on the quantum key; and in response to the quantum key mixing mode indicating that the quantum key and the existing CAK are mixed to obtain the target CAK, determine the target CKN based on the quantum key and the existing CKN.

[0434] In a possible implementation, the processing module 2103 is configured to: determine the target CKN by using the following formula:

[0435] Target CKN = KDF (quantum key, second label, key identifier of the quantum key | QKD identifier 1 | QKD identifier 2, required length of the target CKN).

[0436] wherein KDF is a key derivation function, the second label is QKD-CKN, QKD identifier 1 is the smaller one of the QKD identifier corresponding to the first application device and the QKD identifier corresponding to the second application device, and QKD identifier 2 is the larger one of the QKD identifier corresponding to the first application device and the QKD identifier corresponding to the second application device.

[0437] In a possible implementation, the processing module 2103 is configured to: determine the target CKN by using the following formula:

[0438] Target CKN = KDF (quantum key, second label, key identifier of the quantum key | existing CKN, required length of the target CKN).

[0439] wherein KDF is a key derivation function, and the second label is QKD-CKN.

[0440] In a possible implementation, the QKD network includes a first QKD device and a second QKD device, the first QKD device is a QKD device capable of providing a quantum key to the first application device, and the second QKD device is a QKD device capable of providing a quantum key to the second application device; and the quantum key announcement information includes an address of the second QKD device.

[0441] In a possible implementation, the first message, the second message, the third message, and the fourth message each carries a first session identifier, and the first application device and the second application device determine the target CAK and the target CKN through a session indicated by the first session identifier.

[0442] In a possible implementation, the quantum key obtained by the first application device from the QKD network comprises a plurality of quantum keys, the quantum key notification information is used to indicate key information of the plurality of quantum keys that need to be notified to the second application device; the quantum key obtained by the second application device from the QKD network comprises at least one quantum key of the plurality of quantum keys, and the quantum key confirmation information is used to indicate a result of the second application device obtaining the plurality of quantum keys from the QKD network in response to the third message; the target CAK comprises at least one target CAK corresponding to the at least one quantum key respectively, and the target CKN comprises at least one target CKN corresponding to the at least one target CAK respectively.

[0443] In a possible implementation, the first message, the second message, the third message and the fourth message are all EAPoL-announcement messages on a local area network.

[0444] In a possible implementation, the first message, the second message, the third message and the fourth message are all EAPoL-key messages.

[0445] In a possible implementation, the first message and the second message are both EAPoL-announcement messages; the third message and the fourth message are first type EAPoL-MKA messages, and the first type EAPoL-MKA messages are used to elect a key server.

[0446] In a possible implementation, the first message and the second message are first type EAPoL-MKA messages, and the first type EAPoL-MKA messages are used to elect a key server; in response to the first application device determining that the local end is the key server based on the first message and the second message, the third message is a second type EAPoL-MKA message, and the fourth message is a third type EAPoL-MKA message, the second type EAPoL-MKA message is used to distribute a security association key SAK, and the third type EAPoL-MKA message is used to notify the second application device that the distributed SAK has been used.

[0447] In a possible implementation, the first message and the second message are first type EAPoL-MKA messages, and the first type EAPoL-MKA messages are used to elect a key server; in response to the first application device determining that the local end is not the key server based on the first message and the second message, the third message is a first type EAPoL-MKA message, and the fourth message is a second type EAPoL-MKA message, the second type EAPoL-MKA message is used to distribute a security association key SAK.

[0448] In addition, when the application device shown in FIG. 21 is the second application device in the foregoing embodiments, each module shown in FIG. 21 has the following functions.

[0449] The receiving module 2102 is configured to receive a first message from the first application device, the first message carrying first quantum key distribution (QKD) information, the first QKD information being used to indicate configuration information of the first application device in the QKD network.

[0450] The sending module 2101 is configured to send a second message to the first application device, the second message carrying second QKD information, the second QKD information being used to indicate configuration information of the second application device in the QKD network.

[0451] The receiving module 2102 is further configured to receive a third message from the first application device in response to the processing module 2103 determining, based on the first message and the second message, that the local end is not an active end for obtaining quantum keys, the third message carrying quantum key announcement information, the quantum key announcement information being used to indicate key information of quantum keys that need to be announced to the second application device.

[0452] The processing module 2103 is further configured to obtain quantum keys from the QKD network based on the third message, and determine a target security connection association key (CAK) and a target security connection association key name (CKN) based on the quantum keys, the target CAK and the target CKN being CAK and CKN required for the first application device and the second application device to communicate using a media access control security key agreement (MKA) protocol.

[0453] The sending module 2101 is further configured to send a fourth message to the first application device, the fourth message carrying quantum key confirmation information, the quantum key confirmation information being used to indicate a result of the second application device obtaining quantum keys from the QKD network in response to the third message.

[0454] In a possible implementation, the first QKD information includes a QKD identifier corresponding to the first application device and a quantum key obtaining priority of the first application device, and the second QKD information includes a QKD identifier corresponding to the second application device and a quantum key obtaining priority of the second application device.

[0455] In a possible implementation, the first QKD information further includes a key obtaining mode of the first application device, and the second QKD information further includes a key obtaining mode of the second application device; the key obtaining mode includes an active obtaining mode and a passive receiving mode, the active obtaining mode being used to indicate that the corresponding application device can actively obtain quantum keys from the QKD network, and the passive receiving mode being used to indicate that the corresponding application device needs to obtain quantum keys from the QKD network based on an indication of another application device.

[0456] In a possible implementation, the first QKD information includes a QKD identifier corresponding to the first application device and a key acquisition mode of the first application device, and the second QKD information includes a QKD identifier corresponding to the second application device and a key acquisition mode of the second application device; the key acquisition mode includes an active acquisition mode and a passive reception mode, the active acquisition mode is used to indicate that the corresponding application device can actively acquire a quantum key from the QKD network, and the passive reception mode is used to indicate that the corresponding application device needs to acquire a quantum key from the QKD network based on an indication of another application device.

[0457] In a possible implementation, the first QKD information further includes a quantum key acquisition priority of the first application device, and the second QKD information further includes a quantum key acquisition priority of the second application device.

[0458] In a possible implementation, the first message and the second message each include a reference field, the reference field includes a first bit sequence and a second bit sequence, a bit value corresponding to the first bit sequence is used to indicate the key acquisition mode of the corresponding application device, and a bit value corresponding to the second bit sequence is used to indicate the quantum key acquisition priority of the corresponding application device.

[0459] In a possible implementation, the quantum key announcement information includes a key identifier of the quantum key, a key length of the quantum key, and a quantum key mixing mode, the quantum key mixing mode is used to indicate whether the quantum key and an existing CAK are mixed to obtain a target CAK.

[0460] In a possible implementation, the existing CAK is a CAK negotiated between the first application device and the second application device through an extensible authentication protocol (EAP), or is a CAK configured at the first application device and the second application device.

[0461] In a possible implementation, in response to the quantum key mixing mode indicating that the quantum key and the existing CAK are mixed to obtain the target CAK, the quantum key announcement information further includes an existing CKN, and the existing CKN is an identifier of the existing CAK; the quantum key confirmation information includes the existing CKN.

[0462] In a possible implementation, the processing module 2103 is configured to: in response to the quantum key mixing mode indicating that the quantum key and the existing CAK are not mixed to obtain the target CAK, determine the target CAK based on the quantum key; and in response to the quantum key mixing mode indicating that the quantum key and the existing CAK are mixed to obtain the target CAK, determine the target CAK based on the quantum key and the existing CAK.

[0463] In a possible implementation, the processing module 2103 is configured to: determine the target CAK by the following formula:

[0464] Target CAK = KDF (quantum key, first label, QKD identifier 1 | QKD identifier 2, required length of target CAK) ;

[0465] wherein KDF is a key derivation function, the first label is QKD-CAK, QKD identifier 1 is the smaller one of the QKD identifier corresponding to the first application device and the QKD identifier corresponding to the second application device, and QKD identifier 2 is the larger one of the QKD identifier corresponding to the first application device and the QKD identifier corresponding to the second application device.

[0466] In a possible implementation, the processing module 2103 is configured to: in response to the quantum key mixing mode indication, mix the quantum key and the existing CAK through a KDF algorithm to obtain the target CAK, and determine the target CAK through the following formula:

[0467] Target CAK = KDF (quantum key, first label, existing CAK, required length of target CAK), wherein KDF is a key derivation function, and the first label is QKD-CAK.

[0468] In response to the quantum key mixing mode indication, the quantum key and the existing CAK are mixed through an exclusive or algorithm to obtain the target CAK, and the quantum key and the existing CAK are calculated through exclusive or to obtain the target CAK.

[0469] In a possible implementation, the processing module 2103 is configured to: in response to the quantum key mixing mode indication not mixing the quantum key and the existing CAK to obtain the target CAK, determine the target CKN based on the quantum key; and in response to the quantum key mixing mode indication mixing the quantum key and the existing CAK to obtain the target CAK, determine the target CKN based on the quantum key and the existing CKN.

[0470] In a possible implementation, the processing module 2103 is configured to: determine the target CKN through the following formula:

[0471] Target CKN = KDF (quantum key, second label, key identifier of quantum key | QKD identifier 1 | QKD identifier 2, required length of target CKN) ;

[0472] wherein KDF is a key derivation function, the second label is QKD-CKN, QKD identifier 1 is the smaller one of the QKD identifier corresponding to the first application device and the QKD identifier corresponding to the second application device, and QKD identifier 2 is the larger one of the QKD identifier corresponding to the first application device and the QKD identifier corresponding to the second application device.

[0473] In a possible implementation, the processing module 2103 is configured to: determine the target CKN through the following formula:

[0474] Target CKN = KDF (quantum key, second label, key identification of the quantum key | existing CKN, required length of the target CKN) ;

[0475] wherein KDF is a key derivation function, and the second label is a QKD-CKN.

[0476] In a possible implementation, the QKD network includes a first QKD device and a second QKD device, the first QKD device is a QKD device capable of providing a quantum key to a first application device, and the second QKD device is a QKD device capable of providing a quantum key to a second application device; and the quantum key announcement information includes an address of the second QKD device.

[0477] In a possible implementation, the first message, the second message, the third message, and the fourth message each carries a first session identifier, and the first application device and the second application device determine the target CAK and the target CKN through a session indicated by the first session identifier.

[0478] In a possible implementation, the quantum key obtained by the first application device from the QKD network includes a plurality of quantum keys, and the quantum key announcement information is used to indicate key information of the plurality of quantum keys that need to be announced to the second application device; the quantum key obtained by the second application device from the QKD network includes at least one quantum key of the plurality of quantum keys, and the quantum key confirmation information is used to indicate a result of the second application device obtaining the plurality of quantum keys from the QKD network in response to the third message; the target CAK includes at least one target CAK corresponding to the at least one quantum key respectively, and the target CKN includes at least one target CKN corresponding to the at least one target CAK respectively.

[0479] In a possible implementation, the first message, the second message, the third message, and the fourth message are each an extended authentication protocol (EAPoL) -announcement message on a local area network.

[0480] In a possible implementation, the first message, the second message, the third message, and the fourth message are each an EAPoL-key message.

[0481] In a possible implementation, the first message and the second message are each an EAPoL-announcement message; the third message and the fourth message are a first type of EAPoL-MKA message, and the first type of EAPoL-MKA message is used to elect a key server.

[0482] In a possible implementation, the first message and the second message are first type EAPoL-MKA messages, the first type EAPoL-MKA messages are used for electing a key server; in response to the second application device determining, based on the first message and the second message, that the local end is not the key server, the third message is a second type EAPoL-MKA message, and the fourth message is a third type EAPoL-MKA message, the second type EAPoL-MKA message is used for distributing a security association key SAK, and the third type EAPoL-MKA message is used for announcing that the second application device has used the distributed SAK.

[0483] In a possible implementation, the first message and the second message are first type EAPoL-MKA messages, the first type EAPoL-MKA messages are used for electing a key server; in response to the first application device determining, based on the first message and the second message, that the local end is not the key server, the third message is a first type EAPoL-MKA message, and the fourth message is a second type EAPoL-MKA message, the second type EAPoL-MKA message is used for distributing a security association key SAK.

[0484] The embodiment of the present application further provides a computer readable storage medium, and instructions are stored on the computer readable storage medium, and when the instructions are executed by a processor of an application device, the steps performed by the first application device or the second application device in the method 800 or the method 1900 are implemented.

[0485] The embodiment of the present application further provides a computer program product, and the computer program product comprises a computer program, and when the computer program is executed by a processor of an application device, the steps performed by the first application device or the second application device in the method 800 or the method 1900 are implemented.

[0486] Those skilled in the art can understand that all or part of the steps of the above-mentioned embodiments can be completed by hardware, or can be instructed by a program to complete the related hardware, and the program can be stored in a computer readable storage medium, and the storage medium mentioned above can be a read-only memory, a magnetic disk or an optical disk.

[0487] In the embodiment of the present application, the terms "first", "second" and "third" are only for descriptive purposes, and cannot be understood as indicating or implying relative importance.

[0488] In the present application, the term "and / or" only describes the association relationship of the associated objects, and indicates that there can be three relationships, for example, A and / or B can represent the three cases of A alone, A and B together, and B alone. In addition, the character " / " in this paper generally represents an "or" relationship between the front and rear associated objects.

[0489] It should be noted that the information (including but not limited to user equipment information, user personal information, etc.), data (including but not limited to data for analysis, stored data, displayed data, etc.) and signals involved in the present application are authorized by the user or fully authorized by all parties, and the collection, use and processing of related data need to comply with relevant laws, regulations and standards of relevant countries and regions. For example, the quantum key information and registration information involved in the present application are obtained under full authorization.

[0490] The above only describes optional embodiments of the present application and is not intended to limit the present application. Any modification, equivalent replacement, improvement, etc. made within the concept and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A key determination method characterized by comprising: The method comprises: The first application device sends a first message to the second application device, the first message carrying first quantum key distribution (QKD) information, the first QKD information being used to indicate configuration information of the first application device in a QKD network; The first application device receives a second message from the second application device, the second message carrying second QKD information, the second QKD information being used to indicate configuration information of the second application device in the QKD network; In response to the first application device determining that the local end is an active end for obtaining a quantum key based on the first message and the second message, the first application device performs the following steps: Obtaining a quantum key from the QKD network and determining a target security connection association key (CAK) and a target security connection association key name (CKN) based on the quantum key, the target CAK and the target CKN being CAK and CKN required for the first application device and the second application device to communicate using a media access control security key agreement (MKA) protocol; Sending a third message to the second application device, the third message carrying quantum key announcement information, the quantum key announcement information being used to indicate key information of the quantum key that needs to be announced to the second application device; Receiving a fourth message from the second application device, the fourth message carrying quantum key confirmation information, the quantum key confirmation information being used to indicate a result of the second application device obtaining the quantum key from the QKD network in response to the third message.

2. The method of claim 1, wherein, The first QKD information comprises a QKD identifier corresponding to the first application device and a quantum key obtaining priority of the first application device, and the second QKD information comprises a QKD identifier corresponding to the second application device and a quantum key obtaining priority of the second application device.

3. The method of claim 2, wherein, The first QKD information further comprises a key obtaining mode of the first application device, and the second QKD information further comprises a key obtaining mode of the second application device. The key obtaining mode comprises an active obtaining mode and a passive receiving mode, the active obtaining mode being used to indicate that a corresponding application device can actively obtain a quantum key from the QKD network, and the passive receiving mode being used to indicate that a corresponding application device needs to obtain a quantum key from the QKD network based on an indication of another application device.

4. The method of claim 1, wherein, The first QKD information comprises a QKD identifier corresponding to the first application device and a key obtaining mode of the first application device, and the second QKD information comprises a QKD identifier corresponding to the second application device and a key obtaining mode of the second application device. The key obtaining mode comprises an active obtaining mode and a passive receiving mode, the active obtaining mode being used to indicate that a corresponding application device can actively obtain a quantum key from the QKD network, and the passive receiving mode being used to indicate that a corresponding application device needs to obtain a quantum key from the QKD network based on an indication of another application device.

5. The method of claim 4, wherein, The first QKD information further comprises a quantum key acquisition priority of the first application device, and the second QKD information further comprises a quantum key acquisition priority of the second application device.

6. The method of claim 3 or 5, wherein, The first message and the second message each comprise a reference field, the reference field comprising a first bit sequence and a second bit sequence, a bit value corresponding to the first bit sequence being used to indicate a key acquisition mode of a corresponding application device, and a bit value corresponding to the second bit sequence being used to indicate a quantum key acquisition priority of the corresponding application device.

7. The method of any one of claims 1-6, wherein, The quantum key announcement information comprises a key identifier of the quantum key, a key length of the quantum key, and a quantum key mixing mode, the quantum key mixing mode being used to indicate whether the quantum key and an existing CAK are mixed to obtain the target CAK.

8. The method of claim 7, wherein, The existing CAK is a CAK negotiated between the first application device and the second application device through an extensible authentication protocol (EAP), or is a CAK configured at the first application device and the second application device.

9. The method of claim 7 or 8, wherein, In response to the quantum key mixing mode indicating that the quantum key and the existing CAK are mixed to obtain the target CAK, the quantum key announcement information further comprises an existing CKN, the existing CKN being an identifier of the existing CAK; The quantum key confirmation information comprises the existing CKN.

10. The method of any one of claims 7-9, wherein, The first application device determines a target CAK based on the quantum key, comprising: In response to the quantum key mixing mode indicating that the quantum key and the existing CAK are not mixed to obtain the target CAK, the target CAK is determined based on the quantum key; In response to the quantum key mixing mode indicating that the quantum key and the existing CAK are mixed to obtain the target CAK, the target CAK is determined based on the quantum key and the existing CAK.

11. The method of claim 10, wherein, The target CAK is determined based on the quantum key, comprising: The target CAK is determined through the following formula: The target CAK = KDF (quantum key, first label, QKD identifier 1 | QKD identifier 2, required length of the target CAK); Wherein, the KDF is a key derivation function, the first label is QKD-CAK, the QKD identifier 1 is a smaller one of a QKD identifier corresponding to the first application device and a QKD identifier corresponding to the second application device, and the QKD identifier 2 is a larger one of the QKD identifier corresponding to the first application device and the QKD identifier corresponding to the second application device.

12. The method of claim 10, wherein, The target CAK is determined based on the quantum key and the existing CAK, comprising: In response to the quantum key mixing mode indicating that the quantum key and the existing CAK are mixed to obtain the target CAK through a KDF algorithm, the target CAK is determined through the following formula: The target CAK = KDF (quantum key, first label, existing CAK, required length of the target CAK), wherein the KDF is a key derivation function, and the first label is QKD-CAK; In response to the quantum key mixing mode indication, the quantum key and an existing CAK are mixed by an exclusive or algorithm to obtain the target CAK.

13. The method of any one of claims 7-12, wherein, The first application device determines a target CKN based on the quantum key, including: In response to the quantum key mixing mode indication, the quantum key and an existing CAK are not mixed to obtain the target CAK, the target CKN is determined based on the quantum key; In response to the quantum key mixing mode indication, the quantum key and an existing CAK are mixed to obtain the target CAK, the target CKN is determined based on the quantum key and the existing CKN.

14. The method of claim 13, wherein, The target CKN is determined based on the quantum key, including: The target CKN is determined by the following formula: The target CKN = KDF (quantum key, second label, key identification of the quantum key | QKD identification 1 | QKD identification 2, required length of the target CKN); The KDF is a key derivation function, the second label is QKD-CKN, the QKD identification 1 is the smaller one of the QKD identification corresponding to the first application device and the QKD identification corresponding to the second application device, and the QKD identification 2 is the larger one of the QKD identification corresponding to the first application device and the QKD identification corresponding to the second application device.

15. The method of claim 13, wherein, The target CKN is determined based on the quantum key and the existing CKN, including: The target CKN is determined by the following formula: The target CKN = KDF (quantum key, second label, key identification of the quantum key | existing CKN, required length of the target CKN); The KDF is a key derivation function, and the second label is QKD-CKN.

16. The method of any one of claims 1-15, wherein, The QKD network includes a first QKD device and a second QKD device, the first QKD device is a QKD device capable of providing the quantum key to the first application device, and the second QKD device is a QKD device capable of providing the quantum key to the second application device. The quantum key announcement information includes an address of the second QKD device.

17. The method of any one of claims 1-16, wherein, The first message, the second message, the third message and the fourth message all carry a first session identifier, and the first application device and the second application device determine the target CAK and the target CKN through a session indicated by the first session identifier.

18. The method of any one of claims 1-17, wherein, The quantum key obtained by the first application device from the QKD network includes a plurality of quantum keys, and the quantum key announcement information is used to indicate key information of the plurality of quantum keys to be announced to the second application device. The quantum key obtained by the second application device from the QKD network includes at least one of the plurality of quantum keys, and the quantum key confirmation information is used to indicate a result of the second application device obtaining the plurality of quantum keys from the QKD network in response to the third message; The target CAKs include at least one target CAK corresponding to each of the at least one quantum key, and the target CKNs include at least one target CKN corresponding to each of the at least one target CAK.

19. The method of any one of claims 1-18, wherein, The first message, the second message, the third message and the fourth message are all EAPoL-announcement messages on a local area network.

20. The method of any one of claims 1-18, wherein, The first message, the second message, the third message and the fourth message are all EAPoL-key messages.

21. The method of any one of claims 1-18, wherein, The first message and the second message are both EAPoL-announcement messages. The third message and the fourth message are first-type EAPoL-MKA messages, and the first-type EAPoL-MKA messages are used for electing a key server.

22. The method of any one of claims 1-18, wherein, The first message and the second message are first-type EAPoL-MKA messages, and the first-type EAPoL-MKA messages are used for electing a key server. In response to the first application device determining, based on the first message and the second message, that the first application device is a key server, the third message is a second-type EAPoL-MKA message, the fourth message is a third-type EAPoL-MKA message, the second-type EAPoL-MKA message is used for distributing a security association key (SAK), and the third-type EAPoL-MKA message is used for announcing that the second application device has used the distributed SAK.

23. The method of any one of claims 1-18, wherein, The first message and the second message are first-type EAPoL-MKA messages, and the first-type EAPoL-MKA messages are used for electing a key server. In response to the first application device determining, based on the first message and the second message, that the first application device is not a key server, the third message is the first-type EAPoL-MKA message, and the fourth message is a second-type EAPoL-MKA message, and the second-type EAPoL-MKA message is used for distributing a security association key (SAK).

24. A method of determining a key, the method comprising: The method comprises: The second application device receives a first message from a first application device, the first message carrying first quantum key distribution (QKD) information, and the first QKD information being used for indicating configuration information of the first application device in a QKD network. The second application device sends a second message to the first application device, the second message carrying second QKD information, and the second QKD information being used for indicating configuration information of the second application device in the QKD network. In response to the second application device determining, based on the first message and the second message, that the second application device is not an active end for obtaining a quantum key, the second application device performs the following steps: The second application device receives a third message from the first application device, the third message carrying quantum key announcement information, and the quantum key announcement information being used for indicating key information of a quantum key that needs to be announced to the second application device. The second application device receives a third message from the first application device, the third message carrying quantum key announcement information, and the quantum key announcement information being used for indicating key information of a quantum key that needs to be announced to the second application device. obtain the quantum key from the QKD network based on the third message, and determine a target security connection association key CAK and a target security connection association key name CKN based on the quantum key, the target CAK and the target CKN being CAK and CKN required for communication between the first application device and the second application device using a media access control security key agreement MKA protocol; send a fourth message to the first application device, the fourth message carrying quantum key confirmation information, the quantum key confirmation information being used to indicate a result of obtaining the quantum key from the QKD network by the second application device in response to the third message.

25. An application device, characterized by The application device includes a first application device, and the first application device includes a memory, a 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, the first application device performs the following operations: send a first message to a second application device, the first message carrying first quantum key distribution QKD information, the first QKD information being used to indicate configuration information of the first application device in a QKD network; receive a second message from the second application device, the second message carrying second QKD information, the second QKD information being used to indicate configuration information of the second application device in the QKD network; in response to the first application device determining that the local end is an active end for obtaining a quantum key based on the first message and the second message, perform the following steps: obtain the quantum key from the QKD network based on the third message, and determine a target security connection association key CAK and a target security connection association key name CKN based on the quantum key, the target CAK and the target CKN being CAK and CKN required for communication between the first application device and the second application device using a media access control security key agreement MKA protocol; send a third message to the second application device, the third message carrying quantum key announcement information, the quantum key announcement information being used to indicate key information of the quantum key that needs to be announced to the second application device; receive a fourth message from the second application device, the fourth message carrying quantum key confirmation information, the quantum key confirmation information being used to indicate a result of obtaining the quantum key from the QKD network by the second application device in response to the third message.

26. The application device of claim 25, wherein, The first QKD information includes a QKD identifier corresponding to the first application device and a quantum key obtaining priority of the first application device, and the second QKD information includes a QKD identifier corresponding to the second application device and a quantum key obtaining priority of the second application device.

27. The application device of claim 26, wherein, The first QKD information further includes a key obtaining mode of the first application device, and the second QKD information further includes a key obtaining mode of the second application device. The key acquisition mode comprises an active acquisition mode and a passive receiving mode, the active acquisition mode is used for indicating that the corresponding application device can actively acquire quantum keys from the QKD network, and the passive receiving mode is used for indicating that the corresponding application device needs to acquire quantum keys from the QKD network based on the indication of another application device.

28. The application device of claim 25, wherein, The first QKD information comprises a QKD identifier corresponding to the first application device and a key acquisition mode of the first application device, and the second QKD information comprises a QKD identifier corresponding to the second application device and a key acquisition mode of the second application device. The key acquisition mode comprises an active acquisition mode and a passive receiving mode, the active acquisition mode is used for indicating that the corresponding application device can actively acquire quantum keys from the QKD network, and the passive receiving mode is used for indicating that the corresponding application device needs to acquire quantum keys from the QKD network based on the indication of another application device.

29. The application device of claim 28, wherein, The first QKD information further comprises a quantum key acquisition priority of the first application device, and the second QKD information further comprises a quantum key acquisition priority of the second application device.

30. The application device of claim 27 or 29, wherein, The first message and the second message both comprise a reference field, the reference field comprises a first bit sequence and a second bit sequence, a bit value corresponding to the first bit sequence is used for indicating the key acquisition mode of the corresponding application device, and a bit value corresponding to the second bit sequence is used for indicating the quantum key acquisition priority of the corresponding application device.

31. The application device of any of claims 25-30, wherein, The quantum key announcement information comprises a key identifier of the quantum key, a key length of the quantum key, and a quantum key mixing mode, the quantum key mixing mode is used for indicating whether the quantum key and an existing CAK are mixed to obtain the target CAK.

32. The application device of claim 31, wherein, The existing CAK is a CAK negotiated between the first application device and the second application device through an extensible authentication protocol (EAP), or is a CAK configured at the first application device and the second application device.

33. The application device of claim 31 or 32, wherein, In response to the quantum key mixing mode indicating that the quantum key and the existing CAK are mixed to obtain the target CAK, the quantum key announcement information further comprises an existing CKN, and the existing CKN is an identifier of the existing CAK. The quantum key confirmation information comprises the existing CKN.

34. The application device of any of claims 31-33, wherein, After the program instructions are read by the at least one processor, the first application device further performs the following operations: In response to the quantum key mixing mode indicating that the quantum key and the existing CAK are not mixed to obtain the target CAK, the target CAK is determined based on the quantum key; In response to the quantum key mixing mode indicating that the quantum key and the existing CAK are mixed to obtain the target CAK, the target CAK is determined based on the quantum key and the existing CAK.

35. The application device of claim 34, wherein, After the program instructions are read by the at least one processor, the first application device further performs the following operations: The target CAK is determined by the following formula: The target CAK = KDF (quantum key, first label, QKD identifier 1 | QKD identifier 2, required length of the target CAK) ; Wherein, the KDF is a key derivation function, the first label is QKD-CAK, the QKD identifier 1 is the smaller one of the QKD identifier corresponding to the first application device and the QKD identifier corresponding to the second application device, and the QKD identifier 2 is the larger one of the QKD identifier corresponding to the first application device and the QKD identifier corresponding to the second application device.

36. The application device of claim 34, wherein, The program instructions are read by the at least one processor, so that the first application device further executes the following operations: In response to the quantum key mixing mode indication, the quantum key and the existing CAK are mixed to obtain the target CAK through the KDF algorithm, and the target CAK is determined by the following formula: The target CAK = KDF (quantum key, first label, existing CAK, required length of the target CAK), wherein the KDF is a key derivation function, and the first label is QKD-CAK; In response to the quantum key mixing mode indication, the quantum key and the existing CAK are mixed to obtain the target CAK through the XOR algorithm, and the quantum key and the existing CAK are XOR calculated to obtain the target CAK.

37. The application device of any of claims 31-36, wherein, The program instructions are read by the at least one processor, so that the first application device further executes the following operations: In response to the quantum key mixing mode indication, the quantum key and the existing CAK are not mixed to obtain the target CAK, and the target CKN is determined based on the quantum key; In response to the quantum key mixing mode indication, the quantum key and the existing CAK are mixed to obtain the target CAK, and the target CKN is determined based on the quantum key and the existing CKN.

38. The application device of claim 37, wherein, The program instructions are read by the at least one processor, so that the first application device further executes the following operations: The target CKN is determined by the following formula: The target CKN = KDF (quantum key, second label, key identifier of quantum key | QKD identifier 1 | QKD identifier 2, required length of the target CKN) ; Wherein, the KDF is a key derivation function, the second label is QKD-CKN, the QKD identifier 1 is the smaller one of the QKD identifier corresponding to the first application device and the QKD identifier corresponding to the second application device, and the QKD identifier 2 is the larger one of the QKD identifier corresponding to the first application device and the QKD identifier corresponding to the second application device.

39. The application device of claim 37, wherein, The program instructions are read by the at least one processor, so that the first application device further executes the following operations: The target CKN is determined by the following formula: The target CKN = KDF (quantum key, second label, key identifier of quantum key | existing CKN, required length of the target CKN) ; Wherein, the KDF is a key derivation function, and the second label is QKD-CKN.

40. The application device of any of claims 25-39, wherein, The QKD network comprises a first QKD device and a second QKD device, the first QKD device is a QKD device capable of providing the quantum key to the first application device, and the second QKD device is a QKD device capable of providing the quantum key to the second application device. The quantum key announcement information comprises an address of the second QKD device.

41. The application device of any of claims 25-40, wherein, The first message, the second message, the third message and the fourth message each carries a first session identifier, and the first application device and the second application device determine the target CAK and the target CKN through a session indicated by the first session identifier.

42. The application device of any of claims 25-40, wherein, The quantum key obtained by the first application device from the QKD network comprises a plurality of quantum keys, and the quantum key announcement information is used to indicate key information of the plurality of quantum keys that need to be announced to the second application device. The quantum key obtained by the second application device from the QKD network comprises at least one quantum key in the plurality of quantum keys, and the quantum key confirmation information is used to indicate a result of the second application device obtaining the plurality of quantum keys from the QKD network in response to the third message. The target CAK comprises at least one target CAK corresponding to the at least one quantum key respectively, and the target CKN comprises at least one target CKN corresponding to the at least one target CAK respectively.

43. The application device of any of claims 25-42, wherein, The first message, the second message, the third message and the fourth message are all EAPoL-announcement messages on a local area network.

44. The application device of any of claims 25-42, wherein, The first message, the second message, the third message and the fourth message are all EAPoL-key messages.

45. The application device of any of claims 25-42, wherein, The first message and the second message are both EAPoL-announcement messages. The third message and the fourth message are first-type EAPoL-MKA messages, and the first-type EAPoL-MKA messages are used for electing a key server.

46. The application device of any of claims 25-42, wherein, The first message and the second message are first-type EAPoL-MKA messages, and the first-type EAPoL-MKA messages are used for electing a key server. In response to the first application device determining that a local end is a key server based on the first message and the second message, the third message is a second-type EAPoL-MKA message, the fourth message is a third-type EAPoL-MKA message, the second-type EAPoL-MKA message is used for distributing a security association key SAK, and the third-type EAPoL-MKA message is used for announcing that the second application device has used the distributed SAK.

47. The application device of any of claims 25-42, wherein, The first message and the second message are first-type EAPoL-MKA messages, and the first-type EAPoL-MKA messages are used for electing a key server. In response to the first application device determining that the local end is not a key server based on the first message and the second message, the third message is the first type of EAPoL-MKA message, and the fourth message is a second type of EAPoL-MKA message, and the second type of EAPoL-MKA message is used to distribute a security association key (SAK).

48. An application device, comprising: The application device includes a second application device, and the second application device includes a memory, a network interface, and at least one processor. The memory is configured to store program instructions. The at least one processor, after reading the program instructions stored in the memory, causes the second application device to perform the following operations: receiving a first message from a first application device, the first message carrying first quantum key distribution (QKD) information, the first QKD information being used to indicate configuration information of the first application device in a QKD network; sending a second message to the first application device, the second message carrying second QKD information, the second QKD information being used to indicate configuration information of the second application device in the QKD network; in response to determining that the local end is not an active end for obtaining a quantum key based on the first message and the second message, performing the following steps: receiving a third message from the first application device, the third message carrying quantum key announcement information, the quantum key announcement information being used to indicate key information of a quantum key that needs to be announced to the second application device; obtaining the quantum key from the QKD network based on the third message, and determining a target security connection association key (CAK) and a target security connection association key name (CKN) based on the quantum key, the target CAK and the target CKN being CAK and CKN required for the first application device and the second application device to communicate using a media access control security key agreement (MKA) protocol; sending a fourth message to the first application device, the fourth message carrying quantum key confirmation information, the quantum key confirmation information being used to indicate a result of the second application device obtaining the quantum key from the QKD network in response to the third message.

49. A key determination system, comprising: comprise: a first application device and a first application device; the first application device is configured to send a first message to a second application device, the first message carrying first quantum key distribution (QKD) information, the first QKD information being used to indicate configuration information of the first application device in a QKD network; the second application device is configured to send a second message to the first application device, the second message carrying second QKD information, the second QKD information being used to indicate configuration information of the second application device in the QKD network; the first application device is further configured to, in response to determining that the local end is an active end for obtaining a quantum key based on the first message and the second message, perform the following steps: obtaining a quantum key from the QKD network, and determining a target security connection association key (CAK) and a target security connection association key name (CKN) based on the quantum key, the target CAK and the target CKN being required for the first application device and the second application device to communicate using a media access control security key agreement (MKA) protocol; sending a third message to the second application device, the third message carrying quantum key announcement information, the quantum key announcement information being used to indicate key information of the quantum key that needs to be announced to the second application device; receiving a fourth message from the second application device, the fourth message carrying quantum key confirmation information, the quantum key confirmation information being used to indicate a result of the second application device obtaining the quantum key from the QKD network in response to the third message.

Images