Quantum key management method, system, device and medium

Abstract

This application relates to the field of quantum key distribution technology, and particularly to a quantum key management method, system, device, and medium. A first process receives a first message sent by a user terminal. The first message carries first information indicating the service type to be performed by the user terminal and second information indicating the quantum key to be obtained. The service type indicated by the first information belongs to the service type associated with the first process. The first process checks whether it supports responding to the first message. If it does not support responding to the first message, the first process forwards the first message layer by layer to the next lower-level process until the first message is forwarded to a local process that supports responding to the first message. The local process that supports responding to the first message then obtains the quantum key from its corresponding local adjacency key pool based on the second information and sends it to the user terminal. This reduces latency, improves response efficiency, and enhances user experience.

Description

Technical Field

[0001] This application relates to the field of quantum key distribution technology, and in particular to a quantum key management method, system, device and medium. Background Technology

[0002] Quantum Key Distribution (QKD) systems realize "key generation, transmission, storage, and management." Essentially, they establish physically layer-unobservable symmetric keys between nodes using quantum optical signals (such as single-photon polarization states), providing secure key support for upper-layer data encryption and other services. Key characteristics include: security (relying on the quantum no-cloning principle and the measurement perturbation theorem, preventing third parties from stealing the key), consistency (ensuring key consistency between the two nodes through quantum state comparison and error correction), and resource dependence (requiring collaborative work from node devices, transmission channels, and key pools). The core objective is to distribute keys efficiently and stably on demand while ensuring security, meeting the needs of different network sizes and business requirements.

[0003] However, the response efficiency and user experience of existing quantum key management schemes still need improvement. Summary of the Invention

[0004] This application provides a quantum key management method, system, device, and medium, which at least helps to reduce latency, improve response efficiency, and enhance user experience.

[0005] This application provides a quantum key management method, comprising: a first node applied in a quantum key distribution system for managing quantum keys, wherein at least two local adjacency key pools are running on the first node for storing quantum keys shared with another first node in the quantum key distribution system; and at least two local processes that correspond one-to-one with and manage the corresponding local adjacency key pools, the local processes having a bottom-up hierarchical relationship. The method includes: the first process receiving a first message sent by a user terminal, wherein the first process is any of the local processes, and the first message carrying a first message indicating the service type of the service to be performed by the user terminal. The first information and a second information indicating the quantum key to be acquired, wherein the service type indicated by the first information belongs to the service type associated with the first process; the first process detects whether it supports responding to the first message based on the state of the local adjacency key pool corresponding to its own process; if the first process does not support responding to the first message, it forwards the first message to the lower-level processes layer by layer until the first message is forwarded to the local process that supports responding to the first message, so that the local process that supports responding to the first message can acquire the quantum key from the local adjacency key pool corresponding to its own process based on the second information and send it to the user terminal.

[0006] A second aspect of this application also provides a quantum key distribution system, comprising: a plurality of first nodes for managing quantum keys and a plurality of second nodes for generating quantum keys, each of the first nodes being connected to at least one of the second nodes, the first nodes being used to implement the method as described in any one of the first aspects.

[0007] A third aspect of this application also provides an electronic device, 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 to enable the at least one processor to perform the method as described in any one of the first aspects.

[0008] A fourth aspect of this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method as described in any one of the first aspects.

[0009] The technical solution provided in this application has at least the following advantages: By establishing a connection between local processes and service types at the first node used for quantum key management, requests initiated by user terminals can be assigned to the corresponding local processes for processing based on service type, rather than accumulating on a single process. This distributes the response load across different processes, reducing the processing pressure on individual processes, slowing down the consumption of quantum keys in the local adjacency key pool managed by each process, reducing the risk of key shortages, and minimizing latency caused by key shortages. Furthermore, when keys are insufficient, there is no longer a need to wait for the current process to replenish the managed adjacency key pool; instead, the current process can forward the request to lower-level processes to find an adjacency key pool with sufficient managed keys, further reducing latency caused by waiting for the adjacency key pool to replenish. Ultimately, overall, reducing latency improves response efficiency and significantly enhances the user experience. Attached Figure Description

[0010] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0011] Figure 1 This is a schematic diagram of the structure of a quantum key distribution system provided in one embodiment of this application; Figure 2 This is a schematic diagram illustrating an application scenario of the quantum key distribution system provided in one embodiment of this application; Figure 3 This is a schematic diagram of a structure of the first node provided in one embodiment of this application; Figure 4 This is a schematic diagram of the process hierarchy on the first node provided in one embodiment of this application; Figure 5 This is a flowchart of a quantum key management method provided in one embodiment of this application; Figure 6 This is a schematic diagram of process interaction in the first node provided in one embodiment of this application; Figure 7 This is another flowchart of the quantum key management method provided in one embodiment of this application; Figure 8 This is a logical partitioning diagram of the first node provided in one embodiment of this application; Figure 9 This is another flowchart of a quantum key management method provided in one embodiment of this application; Figure 10 This is another flowchart of the quantum key management method provided in one embodiment of this application. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the various embodiments of this application will be described in detail below with reference to the accompanying drawings. However, those skilled in the art will understand that many technical details have been presented in the various embodiments of this application to enable readers to better understand this application. However, the technical solutions claimed in this application can be implemented even without these technical details and various changes and modifications based on the following embodiments.

[0013] The division of the following embodiments is for ease of description and should not constitute any limitation on the specific implementation of this application. The various embodiments can be combined with and referenced by each other without contradiction.

[0014] This application provides a quantum key distribution system, such as... Figure 1 As shown, the quantum key distribution system includes a key production layer, a key management layer, and a key service layer. The key production layer generates quantum keys between adjacent first nodes (which manage quantum keys) in the system. The key management layer manages the storage, scheduling, synchronization, and forwarding of the link quantum keys generated between adjacent first nodes, and provides end-to-end shared quantum keys to both communicating parties based on key requests from user terminals. The key service layer provides end-to-end shared quantum keys for encryption and decryption to both communicating parties based on service requests from user terminals; the key service layer is primarily service-related.

[0015] In some embodiments, the key management layer can determine the key transmission path based on the first node (i.e., the source node) that the user terminal accesses in the quantum key distribution system, the first node (i.e., the destination node) that the communication peer of the user terminal accesses in the quantum key distribution system, and the service requirements. It can then use the link quantum keys already generated between adjacent nodes on the path to complete the collaborative generation or secure forwarding of end-to-end quantum keys, enabling both communicating parties to obtain a consistent shared key and perform encrypted communication based on the shared key.

[0016] In some embodiments, the first node in the key management layer can achieve end-to-end key transmission through a trusted relay. That is, when there is no direct quantum key distribution link between the first nodes of two user terminals, key relay can be performed through one or more intermediate first nodes. The intermediate first node can use the link quantum key shared with its neighboring first nodes to encrypt and protect the key information to be transmitted, and forward it hop by hop to the destination node, so that the source node and the destination node obtain the same end-to-end shared key.

[0017] Furthermore, in some embodiments, the key production layer may include a plurality of second nodes for producing quantum keys, and the second nodes connected to adjacent first nodes may be connected through quantum channels and classical channels to generate shared quantum keys between adjacent first nodes.

[0018] In some embodiments, the key management layer may include a plurality of first nodes. The first nodes can be connected according to the topology of the quantum key distribution system, forming a chain, ring, mesh, or hierarchical system structure. In some cases, each physical site of the key management layer corresponds to one first node (also called a key management node), and a key management node can connect to and manage multiple pairs of second nodes within its physical site. In some embodiments, in Figure 1 Based on the three-tier system architecture shown, such as Figure 2 As shown, each first node in the key management layer is connected to at least one second node in the key production layer. Figure 2 For clarity, only one second node connected to the first node is shown (but this does not mean that the first node can only connect to one second node), so that each first node in the key management layer can obtain the quantum key through the connected second node.

[0019] Furthermore, in some embodiments, the first node may be as follows: Figure 3 The electronic device shown.

[0020] like Figure 3 As shown, the electronic device may 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, the instructions being executed by the at least one processor to enable the at least one processor to perform a corresponding method.

[0021] The memory and processor are connected via a bus, which can include any number of interconnecting buses and bridges, connecting various circuits of one or more processors and memories. 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 will not be described further herein. The bus interface provides an interface between the bus and the transceiver. The transceiver can be a single element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. Data processed by the processor is transmitted over the wireless medium via an antenna, which further receives data and transmits it to the processor.

[0022] The processor manages the bus and general processing, and also provides various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory is used to store data used by the processor during operation.

[0023] In some embodiments, the second node in the key production layer may include one or more of the following devices: a quantum key distribution terminal (or quantum key distribution device; in this application, the second node is mainly referred to as a quantum key distribution device, and will not be described in detail hereafter), a quantum random number generator, a synchronization module, a quantum channel interface, a classical channel interface, and a key post-processing module, etc., which will not be listed here.

[0024] In some embodiments, the first node in the key management layer may include a key management (KM) device, etc., which will not be listed here.

[0025] Based on the quantum key distribution system provided in the above embodiments, this application also provides a quantum key management method. This method is applied to the first node in the quantum key distribution system, specifically, it can be the first node in the key management layer of the foregoing embodiments. Furthermore, as... Figure 4 As shown, the first node runs at least two local neighbor key pools (NPs) for storing quantum keys shared with another first node in the quantum key distribution system, and at least two local processes that correspond one-to-one with and manage the corresponding local neighbor key pools. The local processes have a bottom-up hierarchical relationship as indicated by direction X. In some embodiments, this can be achieved through... Figure 5 The steps shown implement quantum key management during the user terminal's quantum key request process: Step S11: The first process receives a first message sent by the user terminal. The first process is any local process. The first message carries first information indicating the service type of the service to be performed by the user terminal and second information indicating the quantum key to be obtained. The service type indicated by the first information belongs to the service type associated with the first process.

[0026] Step S12: The first process checks whether it supports responding to the first message based on the status of the local neighbor key pool corresponding to this process.

[0027] In step S13, if the first process does not support responding to the first message, it forwards the first message to the next lower-level process layer by layer until the first message is forwarded to the local process that supports responding to the first message. The local process that supports responding to the first message then obtains the quantum key from the local adjacency key pool corresponding to its own process based on the second information and sends it to the user terminal.

[0028] In this way, by establishing a connection between local processes and service types at the first node used for managing quantum keys, requests initiated by user terminals can be assigned to the corresponding local processes for processing based on service type, instead of accumulating in a single process. This distributes the response pressure across different processes, reducing the processing load on individual processes, slowing down the consumption of quantum keys in the local adjacency key pool managed by each process, reducing the risk of key shortages, and minimizing latency caused by key shortages. Furthermore, when keys are insufficient, there is no longer a need to wait for the current process to replenish the managed adjacency key pool. Instead, the current process can forward the request layer by layer to lower-level processes, searching for an adjacency key pool with sufficient managed keys to respond, further reducing latency caused by waiting for the adjacency key pool to replenish. Ultimately, overall, reducing latency improves response efficiency and significantly enhances the user experience.

[0029] To facilitate understanding of the above embodiments, the steps will be described below.

[0030] In step S11, since the services to be executed by the user terminal are diverse, each of the at least two local processes on the first node may receive the first message sent by the user terminal. That is, at least two local processes on the first node may respond as the first process in a certain response.

[0031] It should be noted that the "receiving the first message sent by the user terminal" described here refers to the message sent directly by the user terminal, which is different from the first message forwarded by the upper-layer process.

[0032] It should also be noted that the embodiments of this application do not limit the specific content of the first information and the second information. For example, the first message may be a string, sequence number, etc., pre-agreed for various business types. Similarly, the second information may be the key length and / or derived algorithm of a quantum key. Furthermore, the embodiments of this application do not limit the format of the first message or whether it has other fields. For example, the first message may be a GET request in Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol Secure (HTTPS). Additionally, the first message may also carry the device identifier of the user terminal, etc., which will not be elaborated further here.

[0033] Furthermore, this application does not limit the manner in which the first process receives the first message. In some embodiments, such as... Figure 6As shown, the first node also runs a management process for managing local processes; the quantum key management method further includes: the management process receiving a first request sent by the user terminal; the management process forwarding the first request to the first process associated with the service type indicated by the first information. This allows the management process to distribute the first message, which is beneficial for load balancing, ensuring a balanced distribution of processing pressure across different processes. This further slows down the quantum key consumption rate of the local adjacency key pool for process management, thereby further reducing the risk of key shortage, reducing latency caused by key shortage, improving response efficiency, and enhancing user experience. In some embodiments, the user terminal can directly determine the local process to process the first message based on the type of service to be executed, and use the physical port corresponding to that local process as the destination communication port for the first message, so as to directly send the first message to the corresponding local process. This reduces the process execution pressure on the first node and provides more resources for the local process to run.

[0034] It should be noted that the management process is just one example. Other processes may also run on the first node, such as security processes for detecting whether communication information is secure, etc., which will not be listed here.

[0035] In step S12, as described in subsequent steps, the first message will eventually trigger the local process on the first node to send a quantum key to the user terminal. That is, the first message is the message sent by the user terminal when requesting the first node to provide a quantum key. Therefore, the response to the first message requires that the quantum key in the adjacent key pool corresponding to the local process can provide the quantum key required by the user terminal, so that the state of the local adjacent key pool corresponding to the process can be used to detect whether it is supported to respond to the first message.

[0036] As mentioned above, the second information may indicate the required quantum key length or the derivation algorithm used by the required quantum key. Therefore, based on different contents of the second information, it will be necessary to adaptively check different states of the local adjacent key pool corresponding to this process. For example, if the second information indicates the required quantum key length, the first process can check whether it supports responding to the first message based on whether the length of the quantum key in its local adjacent key pool is not less than the length of the quantum key indicated by the second information. Similarly, if the second information indicates the derivation algorithm used by the required quantum key, it can check whether the derivation algorithm supported by the quantum key in its local adjacent key pool overlaps with the derivation algorithm used by the quantum key indicated by the second information to check whether it supports responding to the first message. Furthermore, if the second information indicates both the required quantum key length and the derivation algorithm used by the required quantum key, the first process can check whether it supports responding to the first message based on whether the length of the quantum key derived from the quantum key in its local adjacent key pool using the derivation algorithm indicated by the second information is not less than the length of the quantum key indicated by the second information. Of course, the second information may also include other possible information, which will utilize the different states of the local adjacent key pool to detect whether a response to the first message is supported. These will not be listed here.

[0037] In step S13, the first process forwards the first message to the lower-level processes layer by layer. This can be done by directly forwarding the first message or by encapsulating the first message according to the inter-process communication format between nodes before forwarding it.

[0038] In some embodiments, inter-process communication messages can be encapsulated in TLV (Type-Length-Value) format, where the message header contains one or a combination of the following information: request identifier, source node identifier, destination node identifier, service level, required key length, timeout / deadline, key pool segment description (pool identifier, offset, length), etc. A transmission channel is constructed using a message queue. The device internally allocates at least two logical channels corresponding to instances generated by different processes. Each instance receives messages through a subscription mechanism and specifies the target channel when sending, avoiding direct inter-layer dependencies.

[0039] Of course, the above are just examples of inter-process communication implemented through message queues. In some cases, inter-process communication messages can also be implemented using shared memory and other methods, which will not be listed here.

[0040] In some embodiments, considering that the first process can be any local process on the first node, for example, it can be the lowest-level process. In this case, the lowest-level process does not have lower-level processes. Therefore, when the first process does not support responding to the first message, it can forward the first message to the lower-level processes layer by layer in the following way: when the first process does not support responding to the received first message and the process has lower-level processes, it forwards the first message to the lower-level processes.

[0041] In some embodiments, considering that the first process can be any local process on the first node, for example, it can be the lowest-level process. In this case, the lowest-level process does not have any lower-level processes. Therefore, the lowest-level local process can be configured to connect to the second node. Accordingly, if the first process does not support responding to the received first message and does not have any lower-level processes, it will obtain the quantum key from the second node it is connected to, and select the quantum key that matches the second information from the quantum keys obtained from the second node to send to the user terminal. Thus, a first message processing scheme that enables upper-level processes to reach the lowest-level processes is provided, ensuring the completeness of the first message response, reducing the risk of response failure, and improving the user experience.

[0042] Of course, if the system supports responding to the first message, the first process can obtain the corresponding quantum key from the adjacent key pool corresponding to its own process based on the second information and send it to the user terminal. These will not be listed one by one here.

[0043] Based on this, in some embodiments, it can be achieved through methods such as Figure 7 The steps shown implement quantum key management during the user terminal's quantum key request process: Step S21: The first process receives a first message sent by the user terminal. The first process is any local process. The first message carries first information indicating the service type of the service to be performed by the user terminal and second information indicating the quantum key to be obtained. The service type indicated by the first information belongs to the service type associated with the first process.

[0044] Step S22: The first process checks whether it supports responding to the first message based on the status of the local neighbor key pool corresponding to this process.

[0045] In step S23, if the first process does not support responding to the first message, it forwards the first message to the next lower-level process layer by layer until the first message is forwarded to the local process that supports responding to the first message. The local process that supports responding to the first message then obtains the quantum key from the local adjacency key pool corresponding to its own process based on the second information and sends it to the user terminal.

[0046] In step S24, if the first process supports responding to the first message, it obtains the corresponding quantum key from the adjacent key pool corresponding to the current process according to the second information and sends it to the user terminal.

[0047] In step S25, before sending the quantum key to the user terminal, the first process or its lower-level process sends a second message to another first node indicated by the third information. The other first node sends the corresponding quantum key to another user terminal indicated by the fourth information based on the received second message, so that the other user terminal receives the same quantum key as the user terminal. The first message also carries the third information indicating the other first node and the fourth information indicating the other user terminal accessing the other first node.

[0048] In this way, by sending the second message, another first node is triggered to send the corresponding quantum key to another user terminal, so that the two user terminals involved in the service can obtain the symmetric quantum key. In the subsequent execution of the service, they can perform encryption and decryption communication based on the symmetric quantum key, ensuring the quantum-resistant security of the service and improving the user experience.

[0049] To facilitate understanding of the above embodiments, the steps will be described below. Steps S21 to S23 are largely the same as steps S11 to S13 described above, and step S24 is largely the same as the next process response first message in step S13 described above, so they will not be described in detail here.

[0050] In step S25, the sending of the second message involves communication between the first nodes. This application embodiment does not limit its implementation method. For example, it can be combined with the process configuration on the first node to use the socket method to carry out inter-process communication across the first node. Alternatively, it can use inter-device communication to realize communication between the first nodes, and then dispatch it to the corresponding process for processing through the message allocation mechanism of the management process. These have been described in related technologies and will not be repeated here.

[0051] In some embodiments, each local process is bound to one of the following routing methods: static routing, dial-up routing, and dynamic routing. Correspondingly, sending a second message to another first node can be achieved as follows: the first process or its lower-level process determines a route to another first node based on the routing method bound to it, and encrypts and transmits the first information to the next-hop first node in the route using the quantum key shared by the next-hop first node in the route. This allows the second message to be encrypted and transmitted hop-by-hop to the target process on the other first node according to the route. The target process then obtains the quantum key indicated by the second message from the adjacency key pool corresponding to its own process and sends it to another user terminal. In this way, local processes in the first node can flexibly configure static routing, dial-up routing, and dynamic routing, enabling flexible communication between the first nodes to ensure communication stability, flexibility, and reliability.

[0052] It should be noted that this application does not limit the specific implementation of routing. For example, when using static routing, the local process provides communication routes between the first nodes by preloading a static hop-by-hop forwarding table and embedding it in memory; when using dial-up routing, the local process can have built-in "call-answer-keep-alive" state control logic to initiate key relay and synchronization as needed to establish virtual links (or logical links, adjacency links, virtual adjacencies, virtual connections, etc.); when using dynamic routing, the local process can maintain a dynamic routing table by integrating a link state database, where routes in the dynamic routing table can be established and updated by periodically triggering topology scans to establish and update virtual links (or logical links, virtual adjacencies, virtual connections, etc.). Thus, the first node can support Layer 3 key exchange functionality by deploying the above three routing methods in parallel. Since the above processing relies on processes, and processes can be flexibly created and closed, the above routing methods can manage the interface to start and stop any process or instance generated by the process, achieving hot-swapping.

[0053] It should also be noted that the embodiments of this application do not limit the establishment methods of the various routes mentioned above. Taking dynamic routing as an example, in some embodiments, a management queue and interface queue for listening to logical links can be deployed on the first node, and a timed task can be set to trigger the adjacency link establishment process. When the adjacency link establishment process is triggered, a peer name request will be sent and a peer name notification will be received to establish a "peer name - peer service identifier" mapping. Then, an interface identifier request will be sent and an interface identifier notification will be received to complete the consistency negotiation of interface parameters (such as the length of the local domain mask, the length of the parent domain mask, the default exit flag, etc.), and the interfaces on the two first nodes will be bound to the adjacency key pool to form a definite send and receive exit. The link between these send and receive exits can be used as the established adjacency link. Of course, the above are just examples. It is understood that the relevant solutions for static routing, dial-up routing, and dynamic routing provided in the related technologies can all be applied to the routing implementation on the local process, and will not be elaborated on here.

[0054] Based on this, such as Figure 2 and Figure 8 As shown, from the perspective of communication between first nodes, local processes within the same first node are divided into three communication layers from bottom to top according to routing methods: static layer, dial-up layer, and link state layer (or dynamic layer). Each layer can contain one or more local processes using the corresponding routing method. For a given first node, it may not run local processes belonging to the dial-up layer and / or link state layer. In this case, the dial-up layer and / or link state layer can be considered an empty set. However, this first node can still support the subsequent addition of processes to the corresponding communication layer and the establishment of its association with processes in the next lower communication layer without affecting the operation of the original processes.

[0055] In some embodiments, considering the dynamic changing characteristics of dynamic routing, it is also possible to use, for example... Figure 9 The steps shown implement quantum key management during the user terminal's quantum key request process: Step S31: The second process periodically checks the status of the local adjacency key pool corresponding to this process, wherein the second process is any local process bound to a dynamic route.

[0056] In step S32, when the second process detects that the local adjacency key pool corresponding to the second process needs to be filled, it cancels the virtual neighborhood connection between the second process and another first node from the routing table maintained by the second process, and sends a third message to the third process, wherein the third process is a local process located at the next level of the second process, and the third message carries fifth information indicating at least one quantum key in the local adjacency key pool corresponding to the third process.

[0057] In step S33, the third process determines the route to another first node according to the routing method bound to this process, and encrypts and transmits the third message to the next-hop first node in the route according to the quantum key shared with the next-hop first node in the route, so that the third message is encrypted and transmitted hop by hop to the process at the same level as the third process on the other first node according to the route, so that the process at the same level as the third process on the other first node can obtain the quantum key indicated by the fifth information from the adjacent key pool corresponding to this process and send it to the upper-layer process.

[0058] In step S34, the third process obtains the quantum key indicated by the fifth information from the adjacent key pool corresponding to this process and sends it to the second process.

[0059] In step S35, the second process writes the quantum key sent by the third process into the local adjacency key pool corresponding to this process, generates a virtual neighborhood connection with another first node, and associates the generated virtual neighborhood connection with another first node with the physical port of the first node to record it in the routing table maintained by this process.

[0060] In this way, through communication between the first nodes and the cooperation of the lower-level local processes, the corresponding filling of the adjacent key pools between the two first nodes can be achieved. While supporting quantum key synchronization, it is also possible to dynamically maintain the link state based on the filling of the adjacent key pool, thus maintaining the stability of the dynamic link.

[0061] In step S31, that is, for dynamic routing (or dynamic links, virtual adjacencies, etc.), a state detection mechanism is introduced to detect the state of the local adjacency key pool corresponding to this process, so as to avoid adverse situations that affect the availability and stability of the link.

[0062] It should be noted that the embodiments of this application do not limit the method of state detection. For example, the introduced state detection mechanism can be an availability query mechanism, that is, periodically checking whether the length of the quantum key in the corresponding neighboring key pool is lower than a preset threshold. Or, the introduced state detection mechanism can be a consumption rate query mechanism, that is, periodically checking whether the average quantum key consumption rate of the corresponding neighboring key pool in the most recent preset time period is lower than a preset threshold, etc., which will not be listed here.

[0063] In step S32, an invalidation mechanism is configured for virtual neighborhood connections (also known as virtual adjacencies) to prevent their use during key filling, ensuring the security and stability of communication between the first nodes. This is especially crucial during quantum key exchange, ensuring the stability of the exchange and further guaranteeing quantum key synchronization between the first nodes. Here, a virtual neighborhood connection is a connection formed using a method other than a physical connection, such as... Figure 2As shown, the connection formed between local processes located in the link state layer on two first nodes, indicated by a bidirectional arrow, is a virtual domain connection (also known as a virtual link, etc.). The connection formed between local processes located in the same dialing layer on two first nodes, indicated by a bidirectional arrow, is also a virtual domain connection.

[0064] It should be noted that the embodiments of this application do not limit the fifth information, which can be a key segment description. The key segment description may include one or a combination of: a pool identifier for indicating the adjacent key pool of the quantum key to be acquired, the offset position of the quantum key to be acquired, the key length of the quantum key to be acquired, etc.

[0065] It should also be noted that before sending the third message to the third process, the second process can also detect whether the third process can provide enough quantum keys. Only after receiving a supplyable response will the second process send the third message to the lower layer.

[0066] The routing determination method in step S33 has been explained previously and will not be repeated here.

[0067] It should be noted that before executing step S34, some deterministic mechanisms for the two first-node quantum key symmetry processing can be introduced. For example, a destination-end consistent write and acknowledgment mechanism and a timeout rollback mechanism can be introduced. That is, after the destination first node of the third message verifies the integrity of the quantum key fragment, it writes the quantum key to the adjacent key pool according to the segment to which it belongs and returns an acknowledgment. At the same time, if the sending first node of the third message does not receive an acknowledgment within the timeout period, it triggers the rollback mechanism and re-initiates synchronization, thereby ensuring key consistency. Specifically, after the lower-level process of the destination first node receives the third message, it hands over the key data and the fifth information to the upper-level process of the destination first node; the upper-level process writes the data to the receiving pool according to the segment and generates a "write acknowledgment message" and returns it to the third process; only after the third process receives the "write acknowledgment message" does it advance the local read / write pointer and deliver the key to the upper layer, realizing the transaction closed loop of end-to-end consistent write. Furthermore, if the third process does not receive the "write acknowledgment message" within the timeout period, the third process triggers a rollback operation.

[0068] In other words, when the NP value (the key length of the quantum key in the adjacent key pool) is lower than a preset threshold, a corresponding message is sent to the lower-level process. The lower-level process reads the corresponding key data in the local adjacent key pool and generates a "key relay message". At the same time, it triggers the lower-level process at the other end to send a consistent key to the pool at the other end according to the same segment description, so as to ensure that the corresponding segments at both ends are consistent.

[0069] In step S34, when indicating the quantum key, the fifth information can have a function that is roughly the same as the second information mentioned above. The acquisition of the quantum key based on the second information has been explained before, so it will not be repeated here.

[0070] In step S35, after the quantum key is written into the local neighbor key pool corresponding to this process, the neighbor key pool is restored. Correspondingly, the previously failed connection can also be restored to complete the maintenance of a virtual neighbor connection.

[0071] It should be noted that the embodiments of this application do not limit the implementation methods of virtual neighborhood connection failure and generation. For example, for a virtual neighborhood connection that has already been activated, it can be implemented by adding a label for the corresponding state. In this case, the original associated physical port can be kept unchanged, which is convenient for user terminal access. Alternatively, failure can be achieved by deleting the association information between the virtual neighborhood connection and the corresponding physical port, and generation can be achieved by writing the association information between the virtual neighborhood connection and the corresponding physical port, etc., which will not be elaborated here.

[0072] Furthermore, based on the interaction process of inter-node communication described above, message sending and receiving can be implemented by separating the control plane and data plane. For example, a control plane is constructed for generating and updating routing tables, and a data plane is constructed based on a standardized data model. This data plane is the foundation for forwarding. The standardized data model includes one or a combination of the following: an adjacency key pool for storing end-to-end key indices and available quantities; a sending pool for outputting keys to the upper layer and a receiving pool for receiving consistent keys from the peer; a remote link (LK, Link) for recording remote node name information; a Virtual Quantum Link Identifier (VQI) for identifying the association between logical links and physical ports, which can be constructed in an encoded form; and a forwarding table for indicating the mapping table from the destination node to the next hop. Each local process instance only needs to read / update the above unified data plane to complete forwarding and resource judgment, avoiding redundant implementation, supporting hot-swapping without affecting the normal operation of other processes, and without requiring data migration.

[0073] It should also be noted that, in addition to message sending and receiving, communication between the aforementioned first nodes may also involve message relay. Therefore, in some embodiments, it can be achieved through methods such as... Figure 10 The steps shown implement quantum key management during the user terminal's quantum key request process: Step S41: The fourth process receives the ciphertext of the fourth message sent by the previous hop node, wherein the fourth process is any local process, and the fourth message carries sixth information indicating at least one quantum key in the adjacent key pool corresponding to the destination process of the fourth message.

[0074] In step S42, the fourth process decrypts the ciphertext of the fourth message using the quantum key shared with the previous hop node to obtain the plaintext of the fourth message.

[0075] Step S43: The fourth process checks whether it is the destination process of the fourth message based on the plaintext of the fourth message.

[0076] Step S44: If the fourth process is the destination process of the fourth message, it obtains the corresponding quantum key from the local adjacency key pool corresponding to the fourth message and sends it to the upper layer process.

[0077] In step S45, if the fourth process is not the destination process of the fourth message, it determines the next-hop node, encrypts the fourth message according to the quantum key shared by the current process and the next-hop node, and sends it to the next-hop node.

[0078] This provides a hop-by-hop message relay mechanism, enabling efficient and stable reliable communication between nodes over long distances.

[0079] It should be noted that the above embodiments are largely the same as the hop-by-hop encrypted relay mechanism provided in related technologies. The main difference is that the hop-by-hop encrypted relay occurs on the node provided in this application and involves inter-process communication. The implementation methods will not be described in detail here.

[0080] It should also be noted that in the above embodiments, when performing hop-by-hop relay as a relay node, the information indicating the quantum key can be kept consistent. For example, the key segment description can be kept consistent, or the length and identifier of the quantum key segment can be kept unchanged. Finally, the destination end confirms the writing result and sends back confirmation to ensure that the key pool between the two nodes is consistent.

[0081] Furthermore, to ensure the stability and reliability of message transmission, idempotency processing can be introduced during relaying. Relay nodes process messages using a "read local adjacent key pool—perform hop-by-hop XOR with upstream key—encapsulate and forward" method. This ensures that key data appears only as a one-time key protected in each hop, and records the consumed segment description and request identifier locally for idempotency and rollback. When needed, the read / write pointers involved in the current message can be frozen or rolled back, and the node can choose to switch to an alternative communication layer or alternative path to re-initiate the message. All messages carry a request identifier and segment description; and when a node receives a duplicate request, it performs idempotency processing based on the request identifier to avoid inconsistencies caused by duplicate key consumption or duplicate writes.

[0082] Of course, communication between nodes may not require relays, etc., which will not be elaborated here.

[0083] Therefore, the quantum key management method provided in this application can address three typical business scenarios of quantum key distribution systems: small fixed scenarios (such as enterprise parks, with stable topology and high latency requirements, using static routing); medium-sized flexible scenarios (such as urban cross-domain networks, with fluctuating topology and business needs, using dynamic routing); and backbone / cross-domain scenarios (such as national-level networks, with wide coverage and many nodes, requiring link state awareness to optimize paths for dynamic routing). The network architecture must meet the following basic conditions: node interconnection (fiber optic / free-space channels to ensure quantum and control signal transmission), resource adaptation (configuration of a key pool for key storage), and protocol compatibility (unified node routing and key exchange logic). Different communication layers are established to associate with different routes, namely: 1. Static Layer: Adapts to small fixed topologies. A predefined forwarding table is stored in a non-volatile storage area. During forwarding, the receiving end extracts the VQI in the frame and directly looks up the table to obtain the next-hop information, achieving low-latency forwarding. When the topology changes, the forwarding table can be updated online without interrupting the service.

[0084] 2. Dial-up layer: For cross-regional or elastic business scenarios, a virtual link is established through a "call-response-keep" mechanism. The source node sends a request containing an identifier and priority. The intermediate node forwards the request according to the longest prefix matching rule and allocates a dynamic VQI. The link is activated after the destination node responds. The link is maintained through periodic keep-alive messages. If no message is received within the timeout period, the resources are released.

[0085] 3. Link-State Layer: For large-scale networks, a key-aware path lookup mechanism is introduced based on the link-state routing protocol, using Dijkstra's algorithm to query paths. A virtual adjacency folding mechanism is adopted, with nodes periodically flooding link-state information to synchronize the topology. When the available NP at both ends is greater than or equal to a threshold, multi-hop paths are marked as virtual adjacencies and participate in shortest path calculation; when the available NP is lower than the threshold or the path is abnormal, the virtual adjacency is revoked, triggering the next layer to supplement the key, and then republishing it after completion.

[0086] Compared to traditional quantum key distribution networks, which often use a single routing plane for link resources, routing control, and key pool management, making them unsuitable for different scenarios: small fixed topologies require low latency but struggle to avoid redundant computations; medium to large cross-domain networks require elastic scaling but face slow convergence when topology fluctuates; and metropolitan / backbone networks require global optimization but suffer from excessive computational load due to frequent flooding. Meanwhile, the tight coupling between layers and the lack of flexibility to adapt to different business levels not only increase the cost of function modification, but also easily lead to invalid key consumption, which restricts the overall network transmission efficiency and service stability. To break the strong coupling of fixed layers, cross-layer dynamic rebinding triggered by indicators such as key quantity and latency is introduced to map users to the corresponding routing layer. Combined with the multi-layer key synchronization method of upper layer declaration of intent and lower layer hop-by-hop execution, it realizes parallel decoupling of multiple routing modes, SLA-based dynamic mapping, and end-to-end key writing transaction closed loop with absolute consistency. This enables on-demand resource scheduling, shortens convergence time, reduces inter-layer communication costs, reduces key waste, improves overall network efficiency and service continuity, and ensures the reproducibility and consistency of key delivery, improves key resource utilization, and reduces control plane overhead.

[0087] It should be noted that in the above embodiments, a local process may act as a first process, a second process, or a third process, depending on the process's current working state and whether it is sending or receiving corresponding messages. Furthermore, the designations "first," "second," etc., in the above examples are merely for ease of understanding the roles of processes, messages, and information in different scenarios, and are not intended to limit them.

[0088] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this application. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this application.

[0089] It is not difficult to see that the above method embodiments are implemented in conjunction with the above device and system embodiments, and the method embodiments can be implemented in conjunction with the device and system embodiments. The relevant technical details mentioned in the method embodiments remain valid in the device and system embodiments, and will not be repeated here to reduce repetition. Correspondingly, the relevant technical details mentioned in the device and system embodiments can also be applied to the method embodiments.

[0090] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the above-described method embodiments.

[0091] That is, those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0092] Those skilled in the art will understand that the above embodiments are specific embodiments for implementing this application, and in practical applications, various changes can be made to them in form and detail without departing from the spirit and scope of this application.

Claims

1. A quantum key management method, characterized in that, A first node in a quantum key distribution system is used to manage quantum keys. The first node runs at least two local adjacency key pools for storing quantum keys shared with another first node in the quantum key distribution system, and at least two local processes that correspond one-to-one with and manage the respective local adjacency key pools. These local processes have a bottom-up hierarchical relationship. The method includes: The first process receives a first message sent by the user terminal, wherein the first process is any of the local processes, and the first message carries first information indicating the service type of the service to be performed by the user terminal and second information indicating the quantum key to be obtained, wherein the service type indicated by the first information belongs to the service type associated with the first process. The first process checks whether it supports responding to the first message based on the state of the local adjacency key pool corresponding to the process. If the first process does not support responding to the first message, it forwards the first message to the next lower-level process layer by layer until the first message is forwarded to the local process that supports responding to the first message. The local process that supports responding to the first message then obtains the quantum key from the local adjacency key pool corresponding to its own process based on the second information and sends it to the user terminal.

2. The method according to claim 1, characterized in that, If the first process does not support responding to the first message, it forwards the first message to the next lower-level process, including: If the first process does not support responding to the received first message and the first process has a lower-level process, it forwards the first message to the lower-level process. The lowest-level local process connects to the second node in the quantum key distribution system used for producing quantum keys, and the method further includes: If the first process does not support responding to the received first message and does not have a lower-level process, it obtains a quantum key from the second node connected to the first process, and selects a quantum key that matches the second information from the quantum keys obtained from the second node and sends it to the user terminal.

3. The method according to claim 1 or 2, characterized in that, The first message also carries third information indicating the other first node and fourth information indicating another user terminal accessing the other first node; The method further includes: Before sending the quantum key to the user terminal, the first process or its lower-level process sends a second message to the other first node indicated by the third information, so that the other first node sends the corresponding quantum key to the other user terminal indicated by the fourth information according to the received second message, so that the other user terminal receives the same quantum key as the user terminal.

4. The method according to claim 3, characterized in that, Each of the local processes is bound to one of the following routing methods: static routing, dial-up routing, and dynamic routing; Sending the second message to the other first node includes: The first process or its lower-level process determines a route to the other first node according to the routing method bound to this process, and encrypts and transmits the first information to the next-hop first node in the route according to the quantum key shared by the next-hop first node in the route, so that the second message is encrypted and transmitted hop by hop to the target process on the other first node according to the route, so that the target process can obtain the quantum key indicated by the second message from the adjacency key pool corresponding to this process and send it to the other user terminal.

5. The method according to claim 1 or 2, characterized in that, The method further includes: The second process periodically checks the status of the local adjacency key pool corresponding to this process, wherein the second process is any local process bound to a dynamic route; When the second process detects that the local adjacency key pool corresponding to the current process needs to be filled, it causes the virtual neighborhood connection between the current process and the other first node to fail from the routing table maintained by the current process, and sends a third message to the third process, wherein the third process is the local process located at the next level of the second process, and the third message carries fifth information indicating at least one quantum key in the local adjacency key pool corresponding to the third process. The third process determines a route to the other first node based on the routing method bound to this process, and encrypts and transmits the third message to the next-hop first node in the route according to the quantum key shared with the next-hop first node in the route. This allows the third message to be encrypted and transmitted hop-by-hop to the process at the same level as the third process on the other first node according to the route. The process at the same level as the third process on the other first node can then obtain the quantum key indicated by the fifth information from the adjacency key pool corresponding to this process and send it to the upper-layer process. The third process obtains the quantum key indicated by the fifth information from the adjacent key pool corresponding to this process and sends it to the second process; The second process writes the quantum key sent by the third process into the local adjacency key pool corresponding to this process, generates a virtual neighborhood connection with the other first node, and associates the generated virtual neighborhood connection with the other first node with the physical port of the first node to record it in the routing table maintained by this process.

6. The method according to claim 1 or 2, characterized in that, The method further includes: The fourth process receives the ciphertext of the fourth message sent by the first node of the previous hop, wherein the fourth process is any of the local processes, and the fourth message carries sixth information indicating at least one quantum key in the adjacent key pool corresponding to the destination process of the fourth message; The fourth process decrypts the ciphertext of the fourth message using the quantum key shared with the first node of the previous hop, to obtain the plaintext of the fourth message; The fourth process detects whether it is the destination process of the fourth message based on the plaintext of the fourth message. When the fourth process is the destination process of the fourth message, it obtains the corresponding quantum key from the local adjacency key pool corresponding to the current process and sends it to the upper-layer process according to the fourth message. If the current process is not the destination process of the fourth message, the fourth process determines the next hop first node, encrypts the fourth message according to the quantum key shared by the current process and the next hop first node, and sends it to the next hop first node.

7. The method according to claim 1 or 2, characterized in that, The first node also runs a management process for managing the local processes; The method further includes: The management process receives the first request sent by the user terminal; The management process forwards the first request to the first process associated with the service type indicated by the first information.

8. A quantum key distribution system, characterized in that, include: A plurality of first nodes for managing quantum keys and a plurality of second nodes for generating quantum keys, each of the first nodes being connected to at least one of the second nodes, the first nodes being used to implement the method as described in any one of claims 1 to 7.

9. An electronic device, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 7.

Images