Online-to-offline quantum key distribution method and system
Through the quantum key distribution method and system that is online and offline, the quantum key pool is used to realize the offline distribution of quantum keys, which solves the problems of limited coverage and poor real-time performance of the quantum key distribution network in the prior art, and improves the service support capabilities and the stability and concurrency of key distribution.
Patent Information
- Application Number
- CN202311399564.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2023-10-25
- Publication Date
- 2025-05-06
AI Technical Summary
The existing quantum key distribution network has high deployment cost, limited coverage, poor real-time performance, difficult to implement concurrently and poor stability, and cannot effectively support the needs of some services.
A quantum key distribution method and system that is turned off-line online, and centrally controls the first security execution module and the second security execution module through a fusion security management platform. The first security execution module is connected to the quantum key distribution network to pre-store quantum keys, and the second security execution module is not connected to the network, and obtains and distributes the quantum keys offline from the quantum key pool.
It reduces the requirements for the coverage of the quantum key distribution network, supports more service types, improves the real-time, concurrency and stability of quantum key distribution, and reduces the waiting time of the client.
Smart Images

Figure CN119945662A_ABST
Abstract
Description
Technical Field
[0001] The embodiments of the present application relate to the field of quantum technology, and in particular to a method and system for online-to-offline quantum key distribution. Background Art
[0002] Quantum Key Distribution (QKD) technology is a technology that allows both parties to jointly generate a set of random numbers by transmitting quantum states. It is one of the most practical and engineered quantum communication technologies. A common implementation of QKD technology is the online distribution mode, that is, the quantum key generated by the QKD network is directly provided to the client after the client accesses the QKD network.
[0003] However, the deployment cost of the QKD network is high, and the coverage of the QKD network is limited, which makes some services unsupported. At the same time, the QKD network's ability to provide quantum keys in real time is limited and unstable, making the distribution of quantum keys difficult to implement concurrently and having poor stability. Summary of the invention
[0004] The embodiments of the present application provide a method and system for online-to-offline quantum key distribution, which at least helps to reduce the requirements for QKD network coverage, support more business types, and improve the real-time, concurrency and stability of quantum key distribution.
[0005] According to some embodiments of the present application, on the one hand, an embodiment of the present application provides an online-to-offline quantum key distribution method, which is applicable to a converged security management platform, wherein the converged security management platform centrally manages and controls a first security execution module and a second security execution module, wherein the first security execution module is connected to a quantum key distribution network, and the second security execution module is not connected to the quantum key distribution network, including: receiving a quantum key request, wherein the quantum key request is a client quantum key request forwarded by the second security execution module; forwarding the quantum key request to the first security execution module, and obtaining a target quantum key from a quantum key pool built into the first security execution module, wherein the quantum key pool pre-stores a number of quantum keys obtained from a quantum key distribution network; forwarding the target quantum key to the second security execution module, wherein the second security execution module sends the target quantum key to the client for use.
[0006] According to some embodiments of the present application, on the other hand, the embodiments of the present application also provide a quantum key distribution method from online to offline, which is applicable to a second security execution module, wherein the second security execution module and the first security execution module are centrally managed and controlled by a fusion security management platform, the first security execution module is connected to a quantum key distribution network, and the second security execution module is not connected to the quantum key distribution network, including: receiving a quantum key request, wherein the quantum key request is initiated by a client connected to the second security execution module; forwarding the quantum key request to the fusion security management platform, and obtaining a target quantum key from a quantum key pool built into the first security execution module through the fusion security management platform, wherein the quantum key pool pre-stores a number of quantum keys obtained from the quantum key distribution network; and forwarding the target quantum key to the client.
[0007] According to some embodiments of the present application, on the other hand, the embodiments of the present application further provide a converged security management platform, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the online-to-offline quantum key distribution method as described in any one of the above items.
[0008] According to some embodiments of the present application, on the other hand, the embodiments of the present application further provide a secure execution module, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the online-to-offline quantum key distribution method as described above.
[0009] According to some embodiments of the present application, on the other hand, the embodiments of the present application further provide an online-to-offline quantum key distribution system, comprising: a first security execution module, wherein the first security execution module is connected to a quantum key distribution network; a second security execution module, wherein the second security execution module is not connected to the quantum key distribution network, and the second security execution module is the security execution module as described above; and the integrated security management platform as described above, wherein the integrated security management platform centrally controls the first security execution module and the second security execution module.
[0010] The technical solution provided by the embodiment of the present application has at least the following advantages: Since the first security execution module is connected to the quantum key distribution network, the first security execution module can obtain the quantum key online from the quantum key distribution network and pre-store it in the built-in quantum key pool. In this way, after the client initiates a quantum key request, the quantum key request can be sent to the first security execution module via the second security execution module and the fusion security management platform connected to the client, so that the first security execution module can obtain the target quantum key requested by the quantum key request pre-stored in the built-in quantum key pool, and return it to the client in an offline manner through the fusion security management platform and the corresponding second security execution module. In the case where the client does not need to access the quantum key distribution network, the quantum key distributed to the client from online to offline is realized, which no longer depends on the client accessing the quantum key distribution network, so that the quantum key distribution network does not need to cover the area where the client is located, and can support services within the coverage range of the quantum key distribution network. At the same time, since the target quantum key distributed is obtained from the quantum key distribution network online and then stored in the quantum key pool offline, the quantum key generation efficiency of the quantum key distribution network can be improved, and quantum keys can be distributed to more clients at the same time, that is, it can support services with large key volume requirements and high real-time performance, and can also reduce the waiting time of clients. This is conducive to reducing the requirements for the coverage of the quantum key distribution network, supporting more business types, and improving the real-time performance, concurrency and stability of quantum key distribution. BRIEF DESCRIPTION OF THE DRAWINGS
[0011] One or more embodiments are exemplarily described by pictures in the corresponding drawings, and these exemplified descriptions do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, and unless otherwise stated, the figures in the drawings do not constitute proportional limitations.
[0012] Figure 1 It is a structural diagram of a quantum key distribution system and a quantum key distribution network provided in one embodiment of the present application;
[0013] Figure 2 is a flow chart of a quantum key distribution method provided in one embodiment of the present application;
[0014] Figure 3 is another flow chart of the quantum key distribution method provided in one embodiment of the present application;
[0015] Figure 4 is another flow chart of the quantum key distribution method provided in one embodiment of the present application;
[0016] Figure 5This is a structural diagram of a first secure execution module designed for a quantum key distribution method provided in an embodiment of the present application;
[0017] Figure 6 It is another structural schematic diagram of the first secure execution module designed for the quantum key distribution method provided in one embodiment of the present application;
[0018] Figure 7 is another flow chart of the quantum key distribution method provided in one embodiment of the present application;
[0019] Figure 8 is another flow chart of the quantum key distribution method provided in one embodiment of the present application;
[0020] Fig. 9 is another flow chart of the quantum key distribution method provided in one embodiment of the present application;
[0021] Fig.10 is another flow chart of the quantum key distribution method provided in one embodiment of the present application;
[0022] Fig.11 This is a schematic diagram of an application scenario of the quantum key distribution method provided in one embodiment of the present application;
[0023] Fig.12 This is another application scenario schematic diagram of the quantum key distribution method provided in one embodiment of the present application;
[0024] Fig.13 The quantum key distribution method provided in one embodiment of the present application is Fig.11 The interactive flow chart in the application scenario shown;
[0025] Fig.14 The quantum key distribution method provided in one embodiment of the present application is Fig.12 The interactive flow chart in the application scenario shown;
[0026] Fig.15 It is a structural diagram of a converged security management platform provided in one embodiment of the present application;
[0027] Fig.16 It is a structural diagram of a security execution module provided in one embodiment of the present application. DETAILED DESCRIPTION
[0028] To make the purpose, technical scheme and advantages of the embodiments of the present application clearer, the embodiments of the present application will be described in detail below in conjunction with the accompanying drawings. However, it will be appreciated by those skilled in the art that in the present application, many technical details are proposed in order to enable the reader to better understand the present application. However, even without these technical details and various changes and modifications based on the following embodiments, the technical scheme claimed in the present application can also be implemented. The division of the following embodiments is for the convenience of description, and the specific implementation of the present application should not be construed as any limitation, and the various embodiments can be combined and referenced with each other under the premise of no contradiction.
[0029] At least one embodiment of the present application provides an online-to-offline quantum key distribution system, which is used to distribute quantum keys to clients. The client can be any electronic device with communication and data processing capabilities, such as a computer, a server, etc., on which corresponding functions can be deployed, such as a cloud desktop function, a quantum virtual machine function, a distributed storage function, a file encryption function, etc. The structure of the online-to-offline quantum key distribution system provided in the embodiment of the present application is as follows: Figure 1 As shown, including:
[0030] Harmonized Security Control Module (HSCM) 100. HSCM is the central management platform of SEM (including the first security execution module 200 and the second security execution module 300), and has the capabilities of user, business management, equipment, network management, interconnection and policy control; HSCM is connected to SEM to centrally manage and control SEM, and multiple HSCMs form a HSCM network. SEM is a cryptographic computing device for data encryption and decryption, and has the capabilities of key generation / storage, policy storage, digital signature / verification, identity authentication, data encryption / decryption, quantum random numbers, and quantum key services. The external application interface supports JAVA and C language API. The fused security management platform 100 of the present invention centrally controls the first security execution module 200 and the second security execution module 300.
[0031] The first security execution module (SEM) 200 is connected to the quantum key distribution network 400. The quantum key distribution network 400 (also called QKD network) is based on the principles of quantum physics and can provide information-theoretic secure confidential communication services (such as key distribution capabilities) for thousands of users, building a secure and controllable network environment.
[0032] The second security execution module (SEM) 300 is not connected to the quantum key distribution network 400.
[0033] In this way, the client can access the online-to-offline quantum key distribution system provided in this embodiment by establishing a connection with the second security execution module 300, so as to obtain the required quantum key, that is, the target quantum key, from the online-to-offline quantum key distribution system. Among them, since the first security execution module 200 is connected to the quantum key distribution network 400, and the second security execution module is not connected to the quantum key distribution network 400, the first security execution module 200 can obtain the quantum key online from the quantum key distribution network 400, and the client can obtain the quantum key offline from the first security execution module 200 through the second security execution module 300 and the integrated security management platform 100, so as to realize the online-to-offline quantum key distribution, and no longer need the quantum key distribution network, and also do not need the quantum key distribution network to cover the area where the client is located, and can support the business within the coverage range of the quantum key distribution network. At the same time, since the client obtains the quantum key obtained by the first security execution module 200 from the quantum key distribution network 400, it is no longer limited by the quantum key generation efficiency of the quantum key distribution network 400, and supports the distribution of quantum keys to more clients at the same time, that is, it can support services with large key volume requirements and high real-time performance, and can also reduce the waiting time of the client. This is conducive to reducing the requirements for the coverage of the quantum key distribution network, supporting more business types, and improving the real-time performance, concurrency and stability of quantum key distribution.
[0034] It should be noted that Figure 1 The online-to-offline quantum key distribution system shown is only an example, and the embodiment of the present application does not limit the number of first security execution modules and second security execution modules included in the online-to-offline quantum key distribution system. It should also be noted that each module involved in this embodiment is a logical module. In practical applications, a logical unit can be a physical unit, or a part of a physical unit, or it can be implemented as a combination of multiple physical units. In addition, in order to highlight the innovative part of the present application, units that are not closely related to solving the technical problems proposed by the present application are not introduced in this embodiment, but this does not mean that there are no other units in this embodiment.
[0035] At least one embodiment of the present application also provides a method for online-to-offline quantum key distribution, which is applicable to a fusion security management platform 100. The fusion security management platform 100 centrally controls the first security execution module 200 and the second security execution module 300, the first security execution module 200 is connected to the quantum key distribution network 400, and the second security execution module 300 is not connected to the quantum key distribution network 400. For the convenience of description, the fusion security management platform 100 is described as a fusion security management platform, the first security execution module 200 is described as a first security execution module, the second security execution module 300 is described as a second security execution module, and the quantum key distribution network 400 is described as a quantum key distribution network. The flowchart of the method for online-to-offline quantum key distribution provided in the embodiment of the present application is as follows: Figure 2 As shown, including:
[0036] Step 201: receiving a quantum key request, wherein the quantum key request is a client quantum key request forwarded via a second secure execution module.
[0037] Step 202: forward the quantum key request to the first security execution module, and obtain the target quantum key from the quantum key pool built into the first security execution module, wherein the quantum key pool pre-stores a number of quantum keys obtained from the quantum key distribution network.
[0038] Step 203: forward the target quantum key to the second secure execution module, wherein the second secure execution module sends the target quantum key to the client for use.
[0039] In this way, since the first security execution module is connected to the quantum key distribution network, the first security execution module can obtain the quantum key online from the quantum key distribution network and pre-store it in the built-in quantum key pool. In this way, after the client initiates a quantum key request, the quantum key request can be sent to the first security execution module through the second security execution module and the fusion security management platform connected to the client, so that the first security execution module can obtain the target quantum key requested by the quantum key request from the pre-stored acquisition in the built-in quantum key pool, and return it to the client in an offline manner through the fusion security management platform and the corresponding second security execution module. In the case where the client does not need to access the quantum key distribution network, the quantum key distributed to the client from online to offline is realized, which no longer depends on the client accessing the quantum key distribution network, so the quantum key distribution network does not need to cover the area where the client is located, and can support services within the coverage range of the quantum key distribution network. At the same time, since the target quantum key distributed is obtained from the quantum key distribution network online and then stored in the quantum key pool offline, the quantum key generation efficiency of the quantum key distribution network can be improved, and quantum keys can be distributed to more clients at the same time, that is, it can support services with large key volume requirements and high real-time performance, and can also reduce the waiting time of clients. This is conducive to reducing the requirements for the coverage of the quantum key distribution network, supporting more business types, and improving the real-time performance, concurrency and stability of quantum key distribution.
[0040] In order to facilitate those skilled in the art to better understand the above embodiments, they will be described below.
[0041] In step 201, a quantum key request is received, wherein the quantum key request is a client quantum key request forwarded by the second security execution module. That is, the quantum key request of the present invention is initiated by the client and forwarded by the second security execution module before reaching the fusion security management platform, wherein the transmission of the quantum key request between the client and the second security execution module is established through the virtual network of the second security execution module, and the second security execution module is controlled by the fusion security management platform, that is, the virtual network is established under the control of the fusion security management platform. Specifically, Figure 3 As shown, the online-to-offline quantum key distribution method further includes, before step 201:
[0042] Step 204, construct a virtual network of the second security execution module, wherein the virtual network includes a virtual key management terminal and an offline secret service, the second security execution module is connected to the virtual key management terminal through the offline secret service, the virtual key management terminal is used to simulate the key management terminal, and the offline secret service is used to simulate the key management device. For example, the constructed virtual key management terminal can provide a dynamic library so, and provide the same interface and communication protocol when the client interacts with the quantum key distribution network, so that the interaction mode between the client and the second security execution module is exactly the same as the interaction mode between the client and the quantum key distribution network. For example, the constructed offline secret service can provide a service for encrypting quantum keys. Specifically, the target quantum key received by the second security execution module from the fusion security management platform is first encrypted by the encryption service provided by the offline secret service, and then the offline secret service transmits the encrypted target quantum key to the virtual key management terminal through the WebSocket protocol, and sends the encrypted target quantum key to the client through the virtual key management terminal.
[0043] In addition, the constructed offline secret service can also provide mutual calling services of development languages, so that it can flexibly support various development languages, such as C language, Java, etc., while ensuring the compatibility between the virtual key management terminal and other parts of the second security execution module.
[0044] Step 205, control the second security execution module to send the configuration information of the virtual key management terminal and the offline secret service to the client, wherein the client initiates a connection to the second security execution module according to the configuration information. Here, the configuration information of the virtual key management terminal and the offline secret service includes auth_key information and private_key information. Among them, the auth_key information is used to authenticate the virtual key management terminal, and the private_key information is used to symmetrically decrypt the quantum key encrypted by the offline secret service. In this way, after receiving the auth_key information and the private_key information, the client can set the auth_key information and the private_key information to the configuration file, and initiate a quantum key request to the second security execution module by loading the header file qkssdk.h, the library file libqkssdk.so and the prefabricated quantum SDK program. Among them, the content format of the auth_key information and the private_key information placed in the configuration file is as follows:
[0045] <! --AuthCode node: The key used by the key application device for identity authentication. In the simulator, all devices use the same AuthCode. (Changes take effect immediately) -->
[0046] <AuthCodeval="66c7f0f462eeedd9d1f2d46bdc10e4e24167c4875cf2f7a2297da02b8f4ba8e0" / >
[0047] <! --PreKey node: The preset key used when encrypting the key output. It can be set to 64 bytes or 32 bytes. (Changed to take effect immediately) -->
[0048] <PreKey val="66c7f0f462eeedd9d1f2d46bdc10e4e24167c4875cf2f7a2297da02b8f4ba8e0" / > .
[0049] It can be seen that, given that the quantum key distribution network includes a key management terminal (KMT) and a key management device (KMS), the key management terminal is connected to the first security execution module via the key management device, so that the first security execution module is connected to the quantum key distribution network. The key management terminal, as a key generation control client, is controlled by the key management server; controls the quantum key distribution terminal under its jurisdiction to perform quantum key distribution; controls the optical quantum switch under its jurisdiction to switch the optical path; outputs the quantum key to the application layer device; receives the quantum key input from the quantum layer, and implements the local security storage of the quantum key; collaborates with the quantum key management service system to complete the key relay process; provides a network management interface to implement the network management server's security monitoring of the device. The key management device includes QKM-C600 and QKM-S600. QKM-S600 can also interact with QKM-C600 as a management domain subnet to complete key management related functions, share data with other service terminals, and accept the management of the network management system, further expanding the network control range and enhancing the robustness of the entire network. QKM-C600 provides key routing calculation for the quantum key relay process across management domains, supports the collaborative management of application sessions, can ensure the collaborative operation of multiple subnets; and can collaborate with other C600s to control a larger scale network. As the control core of the system, QKM-S600 mainly completes functions such as device authentication, device management (including network access and network disconnection), quantum key generation, key routing calculation, key application management, network management, and dual-machine hot standby. The present invention constructs a virtual key management terminal (Virtual KeyManagement Terminal, quantum key terminal, Virtual-KM) for simulating a key management terminal and an offline secret service for simulating a key management device, so that the service provided by the second security execution module to the client can be similar to the service provided by the quantum key distribution network, avoiding the user's perception of the difference between obtaining a quantum key from an online-to-offline quantum key distribution system through the second security execution module and obtaining a quantum key through a quantum key distribution network, which is conducive to improving the user experience.
[0050] On the basis of building a virtual network including virtual key management terminal and offline key service, Figure 4 As shown, step 201 may also include:
[0051] Step 2011: receiving a session application request, wherein the session application request is a client session application request forwarded by the second security execution module.
[0052] Step 2021, control the virtual key management terminal to take over the session application request and receive the client quantum key request when the session is established.
[0053] In step 2011, the session application request is a POST request for requesting to establish a session, and the request carries information related to session establishment. Specifically, step 2011 can be implemented in the following manner: a POST request initiated by a client and forwarded by the second security execution module is received through a URL, the URL points to the QKS_ManageSession_Apply interface, and the request body includes a request type code, a session ID, and a session receiving device ID. For example, the content of a session application request is as follows:
[0054] POST / api / v1 / module / service / customer / manageSession? HTTP / 1.0
[0055] HOST:127.0.0.1;8091
[0056] User-Agent: QG1 Http 0.1
[0057] Cache-Control: no-cache
[0058] Content-Type: application / json
[0059] Postman-Token: 8d4d5783-4460-c219-8644-e2e7dad68500
[0060] Authorization:Basics cm9hbTJmcmVl0mx5bmttYXhfdGVzda==
[0061] Accept: * / *
[0062] Content-Length: 69
[0063] {"identifier": 100000000, "keyLen": 1024, "sessionIDD": 143165579373120713}
[0064] Among them, the request method is "POST / api / v1 / module / service / customer / manageSession?HTTP / 1.0", the host address (IP and port number) is "127.0.0.1;8091", the browser name is "QG1 Http 0.1", the Cache Control type is "no-cache", the resource file type is "application / json", the authentication information is "8d4d5783-4460-c219-8644-e2e7dad68500" and "Basicscm9hbTJmcmVl0mx5bmttYXhfdGVzda==", the transmission file type is "* / *", the request length and request body are "62", and the request body includes the request type code "1", the session ID "143165579373120713" and the session receiving device ID "44444444".
[0065] In step 221, the client quantum key request is a POST request for requesting a quantum key, which carries a keyLen parameter, a key reading identifier, and a session ID. Specifically, receiving the client quantum key request can be implemented as follows: receiving a POST request initiated by the client forwarded by the second secure execution module through a URL, wherein the URL points to the QKS_ApplyKey interface, and the request body includes the keyLen parameter, the key reading identifier, and the session ID. For example, the content of a client quantum key request is as follows:
[0066] POST / api / v1 / module / service / customer / applykey? HTTP / 1.0
[0067] HOST:127.0.0.1;8091
[0068] User-Agent: QG1 Http 0.1
[0069] Cache-Control: no-cache
[0070] Content-Type: application / json
[0071] Postman-Token: 8d4d5783-4460-c219-8644-e2e7dad68500
[0072] Authorization:Basics cm9hbTJmcmVl0mx5bmttYXhfdGVzda==
[0073] Accept: * / *
[0074] Content-Length: 69
[0075] {"identifier": 100000000, "keyLen": 1024, "sessionIDD": 143165579373120713}
[0076] Among them, the request method is "POST / api / v1 / module / service / customer / applykey?HTTP / 1.0", the host address (IP and port number) is "127.0.0.1;8091", the browser name is "QG1 Http 0.1", the CacheControl type is "no-cache", the resource file type is "application / json", the authentication information is "8d4d5783-4460-c219-8644-e2e7dad68500" and "Basics cm9hbTJmcmVl0mx5bmttYXhfdGVzda==", the transmission file type is "* / *", the request length and request body are "69", and the request body includes the key reading identifier "100000000", the keyLen parameter is "1024" and the session ID "143165579373120713".
[0077] In step 202, the quantum key request is forwarded to the first security execution module, and the target quantum key is obtained from the quantum key pool built into the first security execution module, wherein the quantum key pool pre-stores a number of quantum keys obtained from the quantum key distribution network. There are many ways to build the quantum key pool: Figure 5 As shown, the quantum key pool can be located in the password card in the first security execution module, and the password card can be divided into multiple containers for partitioning, so that one or more partitions can be used as the quantum key pool, such as using a total area of 32M as the quantum key pool. Figure 6 As shown, the quantum key pool can also be mounted on the first security execution module, for example, the storage space provided by the network attached storage (NAS) is used as the quantum key pool. On the basis of the built-in quantum key pool, the first security execution module can fill the built-in quantum key pool with quantum keys under the control of the fusion security management platform. Specifically, under the control of the fusion security management platform, the first security execution module accesses the quantum key distribution network, and after obtaining the quantum key from the quantum key distribution network, fills the obtained quantum key into the quantum key pool.
[0078] Furthermore, considering that several quantum keys pre-stored in the quantum key pool will be issued and consumed through the quantum key request initiated by the client. Therefore, the number of quantum keys in the quantum key pool can also be monitored, so that after the number of quantum keys in the quantum key pool reaches a preset threshold condition, the quantum keys are pre-stored in the quantum key pool again until the number of quantum keys in the quantum key pool reaches a predetermined number, or the quantum key pool is filled with quantum keys, etc. The preset threshold condition can be that the number of quantum keys in the quantum key pool is less than a preset number, or the speed at which the number of quantum keys in the quantum key pool decreases reaches a preset speed, etc. Monitoring the number of quantum keys pre-stored in the quantum key pool can be implemented by the fusion security management platform, or by the first security execution module.
[0079] In this way, compared with the existing online quantum key distribution mode, quantum key requests can be responded to through several quantum keys pre-stored in the quantum key pool, and no longer need to be obtained online in real time. Therefore, it will not be limited by the performance of quantum key distribution network equipment, such as the key generation rate of quantum key distribution network equipment, and no longer need to rely on the quantum key distribution network, avoiding the occurrence of key retrieval or insufficient key quantity, and avoiding the interference of limited coverage of the quantum key distribution network. It is conducive to reducing the requirements for the coverage of the quantum key distribution network, supporting more business types, and improving the real-time, concurrency and stability of quantum key distribution.
[0080] In step 203, the target quantum key is forwarded to the second security execution module, wherein the second security execution module sends the target quantum key to the client for use. Whether there is a third security execution module associated with the second security execution module in the online-to-offline quantum key distribution system differs in specific implementation. Specifically, if the online-to-offline quantum key distribution system does not have a third security execution module associated with the second security execution module, the target quantum key only needs to be distributed to the second security execution module; if the online-to-offline quantum key distribution system has a third security execution module associated with the second security execution module, the target quantum key needs to be distributed not only to the second security execution module, but also to the third security execution module associated with the second security execution module, that is, Figure 7 As shown, step 203 may include:
[0081] Step 2013, forwarding the target quantum key to the second secure execution module.
[0082] Step 2023, through the callback mechanism, the target quantum key is called back to the third security execution module. Among them, the third security execution module is still managed by the integrated security management platform, and the third security execution module is not connected to the quantum key distribution network. The association between the second security execution module and the third security execution module refers to the encrypted communication between the client connected to the second security execution module and the client connected to the third security execution module, such as the establishment of a quantum virtual private network (VPN) tunnel between the client connected to the second security execution module and the client connected to the third security execution module.
[0083] In this way, through the callback mechanism, the second security execution module and the associated third security execution module can obtain the same target quantum key, avoiding the problem of abnormal communication caused by inconsistent quantum keys obtained between clients performing encrypted communication.
[0084] At least one embodiment of the present application also provides a method for quantum key distribution from online to offline, which is applicable to a second security execution module, the second security execution module and the first security execution module are centrally managed by a fusion security management platform, the first security execution module is connected to a quantum key distribution network, and the second security execution module is not connected to the quantum key distribution network. The flowchart of the method for quantum key distribution from online to offline provided in the embodiment of the present application is as follows: Figure 8 As shown, including:
[0085] Step 801: receiving a quantum key request, wherein the quantum key request is initiated by a client connected to a second secure execution module.
[0086] Step 802: forward the quantum key request to the fusion security management platform, and obtain the target quantum key from the quantum key pool built into the first security execution module through the fusion security management platform, wherein the quantum key pool pre-stores a number of quantum keys obtained from the quantum key distribution network.
[0087] Step 803: forward the target quantum key to the client.
[0088] In this way, since the first security execution module is connected to the quantum key distribution network, the first security execution module can obtain the quantum key online from the quantum key distribution network and pre-store it in the built-in quantum key pool. In this way, after the client initiates a quantum key request, the quantum key request can be sent to the first security execution module through the second security execution module and the fusion security management platform connected to the client, so that the first security execution module can obtain the target quantum key requested by the quantum key request from the pre-stored acquisition in the built-in quantum key pool, and return it to the client in an offline manner through the fusion security management platform and the corresponding second security execution module. In the case where the client does not need to access the quantum key distribution network, the quantum key distributed to the client from online to offline is realized, which no longer depends on the client accessing the quantum key distribution network, so the quantum key distribution network does not need to cover the area where the client is located, and can support services within the coverage range of the quantum key distribution network. At the same time, since the target quantum key distributed is obtained from the quantum key distribution network online and then stored in the quantum key pool offline, the quantum key generation efficiency of the quantum key distribution network can be improved, and quantum keys can be distributed to more clients at the same time, that is, it can support services with large key volume requirements and high real-time performance, and can also reduce the waiting time of clients. This is conducive to reducing the requirements for the coverage of the quantum key distribution network, supporting more business types, and improving the real-time performance, concurrency and stability of quantum key distribution.
[0089] In order to facilitate those skilled in the art to better understand the above embodiments, they will be described below.
[0090] In step 801, it is substantially the same as the aforementioned step 201, except that the quantum key request also involves an initialization request. Specifically, Fig. 9 As shown, step 801 includes:
[0091] Step 8011, receiving an initialization request and performing initialization according to the initialization request, where the initialization request is a client initialization request initiated by a client connected to the second secure execution module;
[0092] Step 8021: receiving a session application request after initialization is completed, where the session application request is a client session application request initiated by a client connected to the second security execution module;
[0093] Step 8031, forwarding the client session application request to the converged security management platform;
[0094] Step 8041, when a session is established, receiving a client quantum key request.
[0095] In step 8011, the initialization request is a POST request for requesting initialization, and the request carries the address (IP+port number) of the requesting device and the preset public key prekey. Specifically, receiving the initialization request can be implemented as follows: receiving a POST request initiated by a client through a URL, wherein the URL points to the QKS_InitializeKM interface, and the POST request carries the IP address, port number, and preset public key prekey of the requesting device.
[0096] Moreover, it will be different in specific implementation depending on whether there is a third security execution module associated with the second security execution module in the online-to-offline quantum key distribution system. Specifically, if there is no third security execution module associated with the second security execution module in the online-to-offline quantum key distribution system, the IP address, port number and preset public key prekey of the requesting device are stored; if there is a third security execution module associated with the second security execution module in the online-to-offline quantum key distribution system, not only the IP address, port number and preset public key prekey of the requesting device need to be stored, but also an asynchronous callback function needs to be set.
[0097] Among them, the asynchronous callback function can include the following functions:
[0098] Asynchronous callback function of session application / session destruction function: uint32_t__exportManageSessionCallback(uint64_t*sessionID, uint32_t peerDevID, uint16_t type); ManageSessionCallback means to call back the result of the function QKS_ManageSession_Apply pointed to by the URL of the aforementioned session application request. sessionID means the session ID, peerDevID means the device ID of the session receiving end, type[in] means the session application type, 1 means session application, 2 means session destruction.
[0099] Asynchronous callback function for quantum key application: uint32_t__export ApplyKeyCallback(uint64_tsessionID, uint32_t identifier, uint32_t keyLen, char*keyBuf); where ApplyKeyCallback indicates a callback to the function QKS_ApplyKey pointed to by the URL of the aforementioned quantum key request. sessionID indicates the session ID, identifier indicates the key reading identifier, keyLen indicates the key cache length, and keyBuf indicates the key cache status information.
[0100] Asynchronous callback function for consistency check: uint32_t__export ConsistencyCheckCallback(uint64_t sessionID, char*information); where ConsistencyCheckCallback indicates a callback to the function QKS_ConsistencyCheck pointed to by the URL of the aforementioned quantum key request. sessionID indicates the session ID, and information indicates the consistency check information.
[0101] In this way, by setting the asynchronous callback function, the second security execution module and the third security execution module associated with the second security execution module can implement the same operation based on the callback mechanism and obtain the same data.
[0102] In addition, for the associated second security execution module and the third security execution module, not only whether the same operation can be implemented and the same data can be obtained, but also whether the client disconnects from the second security execution module (or the third security execution module) will affect the normal encrypted communication between the clients. This is because once the connection is disconnected, the two clients may not be able to guarantee the same quantum key, and normal encrypted communication cannot be guaranteed. Therefore, the online-to-offline quantum key distribution method also includes: the second security execution module detects the connected client through heartbeat detection, wherein when the detection result is that the client connection is disconnected (i.e., the client is offline), the second security execution module also notifies the third security execution module of the client connection disconnection information. After the third security execution module is notified, it can respond by taking offline processing or canceling the association processing. In addition, the heartbeat detection cycle can be set according to demand, such as 20s, half a minute or 35s.
[0103] The session application request and client quantum key request involved in steps 8021-8041 are substantially the same as the session application request and client quantum key request described above, and will not be described in detail here.
[0104] In step 802, the quantum key request is forwarded to the fusion security management platform, and the target quantum key is obtained from the quantum key pool built into the first security execution module through the fusion security management platform, wherein the quantum key pool pre-stores a number of quantum keys obtained from the quantum key distribution network.
[0105] In step 803, the target quantum key is forwarded to the client. As mentioned above, the target quantum key is encrypted through the confidentiality service provided by the offline secret service in the second secure execution module. Therefore, in order to ensure the accuracy and non-tampering of the target quantum key received by the client, the client will also initiate a consistency check. And because the Cache Control type of the quantum key request is "no-cache", after obtaining the target quantum key and completing the consistency check, the session will be destroyed and the device will be deinitialized. Specifically, Fig.10 As shown, step 803 includes:
[0106] Step 8013, forward the target quantum key to the client.
[0107] Step 8023: Receive a consistency check request, wherein the consistency check request is initiated by a client connected to the second security execution module.
[0108] Step 8033: When the consistency check is completed, a session destruction request is received and the session is destroyed according to the session destruction request, wherein the session destruction request is initiated by a client connected to the second security execution module.
[0109] Step 8043: When the session is destroyed, a deinitialization request is received and deinitialization is performed according to the deinitialization request, wherein the deinitialization request is initiated by a client connected to the second security execution module.
[0110] In step 8023, the consistency check request is a POST request for requesting consistency check of the target quantum key, and the request carries a session ID and consistency check information. Specifically, step 8023 can be implemented as follows: a POST request initiated by a client is received through a URL, the URL points to the QKS_ConsistencyCheck interface, and the request body includes a session ID and consistency check information. For example, the specific content of a consistency check request is as follows:
[0111] The content of the POST request is as follows:
[0112] POST / api / v1 / module / service / customer / consistencyCheck?HTTP / 1.0
[0113] HOST:127.0.0.1;8091
[0114] User-Agent:QG1 Http 0.1
[0115] Cache-Control:no-cache
[0116] Content-Type:application / json
[0117] Postman-Token:8d4d5783-4460-c219-8644-e2e7dad68500
[0118] Authorization:Basics cm9hbTJmcmVl0mx5bmttYXhfdGVzda==
[0119] Accept:* / *
[0120] Content-Length:93
[0121] {“sessionIDD”:143165579373120713,“information”:“TkFOLnRlc3Rlc3QAAAAAAAAAAAAAAAA=”}
[0122] Among them, the request method is "POST / api / v1 / module / service / customer / consistencyCheck?HTTP / 1.0", the host address (IP and port number) is "127.0.0.1;8091", the browser name is "QG1 Http 0.1", the Cache Control type is "no-cache", the resource file type is "application / json", the authentication information is "8d4d5783-4460-c219-8644-e2e7dad68500" and "Basicscm9hbTJmcmVl0mx5bmttYXhfdGVzda==", the transmission file type is "* / *", the request length and request body are "93", the request body includes the session ID "143165579373120713" and the consistency check information "TkFOLnRlc3Rlc3QAAAAAAAAAAAAAAAA=", and the length of the consistency check information is fixed at 32 bytes.
[0123] In step 8033, the session destruction request is a POST request for requesting to destroy the session, and the request carries the session ID. Specifically, step 8033 can be implemented as follows: a POST request initiated by the client is received through a URL, the URL points to the QKS_ManageSession_Delete interface, and the request body includes the session ID.
[0124] In step 8043, the deinitialization request is a POST request for requesting deinitialization. Specifically, step 6043 can be implemented in the following manner: receiving a POST request initiated by a client through a URL, the URL pointing to a QKS_DeinitializeKM interface.
[0125] Through the above-mentioned implementation mode of the present invention, since the first security execution module is connected to the quantum key distribution network, the first security execution module can obtain the quantum key online from the quantum key distribution network and pre-store it in the built-in quantum key pool. In this way, after the client initiates a quantum key request, the quantum key request can be sent to the first security execution module through the second security execution module and the fusion security management platform connected to the client, so that the first security execution module can obtain the target quantum key requested by the quantum key request pre-stored in the built-in quantum key pool, and return it to the client in an offline manner through the fusion security management platform and the corresponding second security execution module. In the case where the client does not need to access the quantum key distribution network, the quantum key distributed to the client from online to offline is realized, which no longer depends on the client accessing the quantum key distribution network, so that the quantum key distribution network does not need to cover the area where the client is located, and can support services within the coverage range of the quantum key distribution network. At the same time, since the target quantum key distributed is obtained from the quantum key distribution network online and then stored in the quantum key pool offline, the quantum key generation efficiency of the quantum key distribution network can be improved, and quantum keys can be distributed to more clients at the same time, that is, it can support services with large key volume requirements and high real-time performance, and can also reduce the waiting time of clients. This is conducive to reducing the requirements for the coverage of the quantum key distribution network, supporting more business types, and improving the real-time performance, concurrency and stability of quantum key distribution.
[0126] To facilitate those skilled in the art to better understand the online-to-offline quantum key distribution method provided by the above embodiment, the following will be combined with Fig.11 and Fig.12 Two different communication scenarios are shown to illustrate this.
[0127] like Fig.11 In the communication scenario shown, the second security execution module does not have an associated third security execution module, the first security execution module and the second security execution module are deployed at site 1 and site 2 respectively, and client 1 establishes a connection with the second security execution module to access the online-to-offline quantum key distribution method. At this time, the interaction process between the various parts and the client in the online-to-offline quantum key distribution system is as follows: Fig.13 As shown:
[0128] Step 1301: The client initiates an initialization request to the second security execution module.
[0129] Step 1302: The second security execution module feeds back a response to the initialization request to the client.
[0130] Step 1303: The client initiates a session request to the second security execution module according to the configuration information of the virtual key management terminal, and the configuration information of the virtual key management terminal is issued by the second security execution module.
[0131] Step 1304: The second security execution module forwards the session request to the converged security management platform.
[0132] Step 1305: The converged security management platform feeds back a response to the session request to the second security execution module, wherein the response to the session request is generated based on whether the configuration information passes the verification.
[0133] Step 1306: The second security execution module feeds back a response to the session request to the client. When the session is successfully established, the second security execution module successfully establishes a connection with the client through the virtual network.
[0134] Step 1307: When the session is successfully established, the client initiates a quantum key request to the second secure execution module.
[0135] Step 1308: The second security execution module forwards the quantum key request to the integrated security management platform by calling the virtual key management terminal.
[0136] Step 1309: The integrated security management platform forwards the quantum key request to the first security execution module.
[0137] Step 1310: The first security execution module returns the quantum key requested by the quantum key request to the integrated security management platform.
[0138] Step 1311: The fusion security management platform returns the received quantum key to the second security execution module.
[0139] Step 1312: The second security execution module returns the encrypted quantum key to the client. The encrypted quantum key is obtained by the second security execution module calling the offline secret service to encrypt the received quantum key.
[0140] Step 1313: After receiving the encrypted quantum key, the client initiates a consistency check request to the second security execution module according to the configuration information of the offline secret service, and the configuration information is issued by the second security execution module.
[0141] Step 13014: The second security execution module feeds back a response to the consistency check request to the client.
[0142] Step 1315: The client initiates a session cleanup request to the second security execution module.
[0143] Step 1316: The second security execution module feeds back a response to the session cleanup request to the client.
[0144] Step 1317: The client initiates a deinitialization request to the second secure execution module.
[0145] In step 1318, the second security execution module feeds back a response to the deinitialization request to the client.
[0146] like Fig.12 In the communication scenario shown, the second security execution module is associated with the third security execution module, the first security execution module, the second security execution module and the third security execution module are deployed at site 1, site 2 and site 3 respectively, and the client accesses the online-to-offline quantum key distribution method by establishing connections with the second security execution module and the third security execution module respectively. At this time, the interaction process between the various parts and the client in the online-to-offline quantum key distribution system is as follows: Fig.14 As shown:
[0147] Step 1401: The client connected to the second security execution module initiates an initialization request to the second security execution module.
[0148] Step 1402: The second security execution module feeds back a response to the initialization request to the connected client.
[0149] Step 1403, when the initialization is completed, the second security execution module initiates a session request to the second security execution module according to the configuration information of the virtual key management terminal, and the configuration information of the virtual key management terminal is issued by the second security execution module.
[0150] Step 1404: The second security execution module forwards the session request to the converged security management platform.
[0151] Step 1405: The converged security management platform feeds back a response to the session request to the second security execution module, wherein the response to the session request is generated based on whether the configuration information passes verification.
[0152] Step 1406: The second security execution module feeds back a response to the session request to the connected client. When the session is successfully established, the second security execution module successfully establishes a connection with the connected client through the virtual network.
[0153] Step 1407: When the session is successfully established, the client connected to the second security execution module initiates a quantum key request to the second security execution module.
[0154] Step 1408: The second security execution module forwards the quantum key request to the integrated security management platform by calling the virtual key management terminal.
[0155] Step 1409: The integrated security management platform forwards the quantum key request to the first security execution module.
[0156] Step 1410: The first security execution module returns the quantum key requested by the quantum key request to the integrated security management platform.
[0157] Step 1411: The fusion security management platform returns the received quantum key to the second security execution module.
[0158] Step 1412: The second security execution module returns the encrypted quantum key to the connected client. The encrypted quantum key is obtained by the second security execution module calling the offline secret service to encrypt the received quantum key.
[0159] Step 1413: After receiving the encrypted quantum key, the client connected to the second security execution module initiates a consistency verification request to the second security execution module according to the configuration information of the offline secret service, and the configuration information is issued by the second security execution module.
[0160] Step 1414: The second security execution module feeds back a response to the consistency check request to the connected client.
[0161] Step 1415: The client connected to the second security execution module initiates a session cleanup request to the second security execution module.
[0162] In step 1416, the second security execution module feeds back a response to the session cleanup request to the connected client.
[0163] Step 1417: The client connected to the second security execution module initiates a deinitialization request to the second security execution module.
[0164] Step 1418: The second secure execution module feeds back a response to the deinitialization request to the connected client.
[0165] Step 1419: Through the callback mechanism, the third security execution module notifies the connected client of the session information.
[0166] Step 1420: Through the callback mechanism, the third secure execution module notifies the connected client of the target quantum key.
[0167] Step 1421: Through the callback mechanism, the third security execution module initiates a consistency check request to the connected client.
[0168] Step 1422: The client connected to the third security execution module returns a response to the consistency check request to the third security execution module.
[0169] Step 1423: Through the callback mechanism, the third security execution module notifies the connected client of the session cleanup request.
[0170] in, Fig.13 and Fig.14 The interactive flow chart of the online-to-offline quantum key distribution method shown is roughly the same, the main difference is Fig.14 The callback is also implemented based on the associated third security execution module, which will not be described here one by one.
[0171] The step division of the above methods is only for the purpose of clear description. When implemented, they can be combined into one step or some steps can be split and decomposed into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this patent; adding insignificant modifications to the algorithm or process or introducing insignificant designs without changing the core design of the algorithm and process are all within the scope of protection of this patent.
[0172] It is not difficult to find that this embodiment is a method embodiment corresponding to the system embodiment, and this embodiment can be implemented in conjunction with the system embodiment. The relevant technical details mentioned in the system embodiment are still valid in this embodiment, and in order to reduce repetition, they are not repeated here. Accordingly, the relevant technical details mentioned in this embodiment can also be applied in the system embodiment.
[0173] At least one embodiment of the present application also provides a converged security management platform, such as Fig.15 As shown, it includes: at least one processor 1501; and a memory 1502 that is communicatively connected to the at least one processor 1501; wherein the memory 1502 stores instructions that can be executed by the at least one processor 1501, and the instructions are executed by the at least one processor 1501, so that the at least one processor 1501 can execute the online-to-offline quantum key distribution method suitable for a fusion security management platform as described in any of the above method embodiments.
[0174] Among them, the memory 1502 and the processor 1501 are connected in a bus manner, and the bus may include any number of interconnected buses and bridges, and the bus connects various circuits of one or more processors 1501 and the memory 1502 together. The bus can also connect various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and are therefore not further described herein. The bus interface provides an interface between the bus and the transceiver. The transceiver can be one element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices on a transmission medium. The data processed by the processor 1501 is transmitted on a wireless medium through an antenna, and further, the antenna also receives data and transmits the data to the processor 1501.
[0175] The processor 1501 is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management and other control functions. The memory 1502 can be used to store data used by the processor 1501 when performing operations.
[0176] At least one embodiment of the present application further provides a secure execution module, such as Fig.16 As shown, it includes: at least one processor 1601; and a memory 1602 that is communicatively connected to the at least one processor 1601; wherein the memory 1602 stores instructions that can be executed by the at least one processor 1601, and the instructions are executed by the at least one processor 1601, so that the at least one processor 1601 can execute the online-to-offline quantum key distribution method applicable to the second security execution module described in any of the above method embodiments.
[0177] Among them, the memory 1602 and the processor 1601 are connected in a bus manner, and the bus may include any number of interconnected buses and bridges, and the bus connects various circuits of one or more processors 1601 and the memory 1602 together. The bus can also connect various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are all well known in the art, and therefore, are not further described herein. The bus interface provides an interface between the bus and the transceiver. The transceiver can be one element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices on a transmission medium. The data processed by the processor 1601 is transmitted on a wireless medium through an antenna, and further, the antenna also receives data and transmits the data to the processor 1601.
[0178] The processor 1601 is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management and other control functions. The memory 1602 can be used to store data used by the processor 1601 when performing operations.
[0179] Those skilled in the art will appreciate that the above embodiments are specific embodiments for implementing the present application, and in actual applications, various changes may be made thereto in form and detail without departing from the spirit and scope of the present application.
Claims
1. A quantum key distribution method from online to offline, characterized in that: Applicable to a fusion security management platform, the fusion security management platform centrally controls a first security execution module and a second security execution module, the first security execution module is connected to a quantum key distribution network, and the second security execution module is not connected to the quantum key distribution network, including: receiving a quantum key request, wherein the quantum key request is a client quantum key request forwarded by a second secure execution module; Forwarding the quantum key request to a first security execution module, and obtaining a target quantum key from a quantum key pool built into the first security execution module, wherein the quantum key pool pre-stores a number of quantum keys obtained from a quantum key distribution network; The target quantum key is forwarded to the second secure execution module, wherein the second secure execution module sends the target quantum key to the client for use.
2. The quantum key distribution method according to claim 1, wherein the quantum key distribution network comprises a key management terminal and a key management device, and the key management terminal is connected to the first security execution module via the key management device, characterized in that: Before receiving a quantum key request, it also includes: Constructing a virtual network of a second security execution module, wherein the virtual network includes a virtual key management terminal and an offline secret service, the second security execution module is connected to the virtual key management terminal through the offline secret service, the virtual key management terminal is used to simulate the key management terminal, and the offline secret service is used to simulate the key management device; Control the second security execution module to send configuration information of the virtual key management terminal and the offline key service to the client, wherein the client initiates a connection to the second security execution module according to the configuration information.
3. The quantum key distribution method according to claim 2, characterized in that: Receiving a quantum key request includes: receiving a session application request, wherein the session application request is a client session application request forwarded by the second security execution module; The virtual key management terminal is controlled to take over the session application request and receive the client quantum key request when a session is established.
4. The quantum key distribution method according to claim 3, characterized in that: The session application request is a POST request, and receiving the session application request includes: The POST request initiated by the client and forwarded by the second security execution module is received through a URL, wherein the URL points to a QKS_ManageSession_Apply interface, and the POST request carries a request type code, a session ID, and a session receiving device ID.
5. The quantum key distribution method according to claim 3, wherein the client quantum key request is a POST request, characterized in that: The request to obtain the client quantum key includes: A POST request initiated by the client and forwarded by the second security execution module is received through a URL, wherein the URL points to a QKS_ApplyKey interface, and the POST request carries a keyLen parameter, a key reading identifier, and a session ID.
6. The quantum key distribution method according to claim 1, characterized in that: Also included is a third security execution module associated with the second security execution module, the integrated security management platform also centrally controls the third security execution module, the third security execution module is not connected to the quantum key distribution network, and forwarding the target quantum key to the second security execution module includes: Forwarding the target quantum key to a second secure execution module; Through a callback mechanism, the target quantum key is called back to the third secure execution module.
7. A quantum key distribution method from online to offline, characterized in that: Applicable to the second security execution module, the second security execution module and the first security execution module are centrally managed by the integrated security management platform, the first security execution module is connected to the quantum key distribution network, and the second security execution module is not connected to the quantum key distribution network, including: receiving a quantum key request, wherein the quantum key request is initiated by a client connected to the second secure execution module; Forwarding the quantum key request to the fusion security management platform, and obtaining a target quantum key from a quantum key pool built into the first security execution module through the fusion security management platform, wherein the quantum key pool pre-stores a number of quantum keys obtained from a quantum key distribution network; The target quantum key is forwarded to the client.
8. A fusion security management platform, characterized in that: include: at least one processor; And a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the online-to-offline quantum key distribution method as described in any one of claims 1 to 6.
9. A secure execution module, characterized in that: include: at least one processor; And a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the online-to-offline quantum key distribution method as described in claim 7.
10. An online-to-offline quantum key distribution system, characterized in that: include: A first security execution module, wherein the first security execution module is connected to a quantum key distribution network; A second security execution module, wherein the second security execution module is not connected to a quantum key distribution network, and the second security execution module is the security execution module according to claim 9; The integrated security management platform as described in claim 8, wherein the integrated security management platform centrally controls the first security execution module and the second security execution module.