CN115865334A - Quantum key distribution method and device and electronic equipment - Google Patents

Quantum key distribution method and device and electronic equipment Download PDF

Info

Publication number
CN115865334A
CN115865334A CN202211486216.4A CN202211486216A CN115865334A CN 115865334 A CN115865334 A CN 115865334A CN 202211486216 A CN202211486216 A CN 202211486216A CN 115865334 A CN115865334 A CN 115865334A
Authority
CN
China
Prior art keywords
key
protocol
end node
message
node
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202211486216.4A
Other languages
Chinese (zh)
Other versions
CN115865334B (en
Inventor
方堃
李诣非
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Baidu Netcom Science and Technology Co Ltd
Original Assignee
Beijing Baidu Netcom Science and Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Baidu Netcom Science and Technology Co Ltd filed Critical Beijing Baidu Netcom Science and Technology Co Ltd
Priority to CN202211486216.4A priority Critical patent/CN115865334B/en
Publication of CN115865334A publication Critical patent/CN115865334A/en
Application granted granted Critical
Publication of CN115865334B publication Critical patent/CN115865334B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Abstract

The disclosure provides a quantum key distribution method, a quantum key distribution device and electronic equipment, and relates to the technical field of quantum computing, in particular to the technical field of quantum communication. The specific implementation scheme is as follows: receiving a first message sent by a first end node through a first protocol; generating a second message with the message type of the first message type through a second protocol based on the first request identifier, the first distribution path, the first node identifier and the key characteristic information, and sending the second message to a second end node through the first protocol; under the condition of receiving a third message, wherein the message type sent by a second end node aiming at the second message is the second message type, based on the types and key characteristic information of two adjacent nodes of the relay node, first keys between the relay node and the two nodes are obtained through a second protocol and/or a third protocol; a key cipher text generated based on the first key is sent to the target end node via the first protocol.

Description

Quantum key distribution method and device and electronic equipment
Technical Field
The present disclosure relates to the field of quantum computing technologies, and in particular, to a quantum key distribution method and apparatus, and an electronic device.
Background
The quantum network is a mode for enabling the classical network through a quantum technology, and through the use of quantum resources and a quantum communication technology, the information processing capacity of the classical network is improved, the safety of information transmission is enhanced, and a brand-new internet service is provided.
One particularly important application in Quantum networks is Quantum Key Distribution (QKD), which utilizes Quantum mechanical properties to ensure communication security, enabling both parties to generate and share a random, secure classical Key to encrypt and decrypt messages.
At present, quantum key distribution in quantum networks is usually designed from responses to single quantum key distribution requests.
Disclosure of Invention
The disclosure provides a quantum key distribution method and device and electronic equipment.
According to a first aspect of the present disclosure, there is provided a quantum key distribution method applied to a relay node of a quantum key distribution network, including:
receiving a first message sent by a first end node through a first protocol, wherein the first message comprises a first request identifier of a quantum key distribution request initiated by the first end node, a first distribution path, a first node identifier of a second end node and key feature information, and the first protocol is used for determining a sending path of the message in the process of quantum key distribution performed by the quantum key distribution network;
under the condition that the number of resources required by a quantum key distribution request corresponding to the first request identifier is determined not to exceed the processing capacity of the relay node, generating a second message with a message type of a first message type through a second protocol based on the first request identifier, the first distribution path, the first node identifier and the key feature information, and sending the second message to the second end node through the first protocol, wherein the second protocol is used for scheduling the received quantum key distribution request, and the first message type is used for identifying that a sender of the quantum key distribution request initiates the quantum key distribution request;
under the condition that a third message of which the message type is the second message type is received, which is sent by the second end node for the second message, based on the types of two nodes adjacent to the relay node and the key feature information, acquiring first keys between the relay node and the two nodes respectively through the second protocol and/or the third protocol, wherein the second message type is used for identifying a resource reservation request initiated by a receiver of a quantum key distribution request, and the third protocol is used for using quantum bits as an information carrier to distribute keys;
and sending a key ciphertext generated based on the first key to a target end node through the first protocol, wherein the target end node is the first end node or the second end node, the key ciphertext is used for determining a target key shared by the first end node and the second end node, and the target key is used for mutual communication between the first end node and the second end node.
According to a second aspect of the present disclosure, there is provided a quantum key distribution method, applied to a first end node of a quantum key distribution network, comprising:
generating a fifteenth message through a fourth protocol, where the fourth protocol is used to initiate a quantum key distribution request, and the fifteenth message includes a first request identifier of the quantum key distribution request initiated by the first end node, a first distribution path, a first node identifier of a second end node, and key feature information;
generating a first message with a message type of a first message type through a second protocol based on the first request identifier, the first distribution path, the first node identifier and the key feature information, wherein the second protocol is used for processing the message according to the role type of the end node and the message type corresponding to the received message, and the first message type is used for identifying that a sender of the quantum key distribution request initiates the quantum key distribution request;
sending the first message to the second end node through a first protocol, wherein the first protocol is used for determining a sending path of the message in the process of quantum key distribution by the quantum key distribution network;
and under the condition that a third message, which is sent by the second end node aiming at the first message and has a second message type, is received, acquiring a target key shared with the second end node through a third protocol, wherein the target key is used for mutual communication between the first end node and the second end node, the third protocol is used for using quantum bits as an information carrier to distribute keys, and the second message type is used for identifying a resource reservation request initiated by a receiver of a quantum key distribution request.
According to a third aspect of the present disclosure, there is provided a quantum key distribution method applied to a second end node of a quantum key distribution network, including:
receiving a first message sent by a first end node through a first protocol, wherein the first message is generated by the first end node through a fourth protocol and a second protocol, the first protocol is used for determining a sending path of the message in the process of quantum key distribution performed by the quantum key distribution network, the second protocol is used for processing the message according to the role type of an end node and the message type corresponding to the received message, the fourth protocol is used for initiating a quantum key distribution request, and the first message comprises a first request identifier of the quantum key distribution request initiated by the first end node, a first distribution path, a first node identifier of the second end node and key feature information;
generating a third message with a message type of a second message type through the first protocol, the second protocol and the fourth protocol based on the first request identifier, the first distribution path, the first node identifier and the key feature information, wherein the second message type is used for identifying a resource reservation request initiated by a receiver of a quantum key distribution request;
and returning the third message to the first end node through the first protocol, and acquiring a target key shared with the first end node through a third protocol, wherein the target key is used for mutual communication between the first end node and the second end node, and the third protocol is used for using quantum bits as an information carrier to distribute keys.
According to a fourth aspect of the present disclosure, there is provided a quantum key distribution device applied to a relay node of a quantum key distribution network, including:
a first receiving module, configured to receive, through a first protocol, a first packet sent by a first end node, where the first packet includes a first request identifier of a quantum key distribution request initiated by the first end node, a first distribution path, a first node identifier of a second end node, and key feature information, and the first protocol is used to determine a sending path of the packet in a quantum key distribution process of the quantum key distribution network;
a first generating module, configured to generate, based on the first request identifier, the first distribution path, the first node identifier, and the key feature information, a second packet with a message type of a first message type through a second protocol when it is determined that the number of resources required by a quantum key distribution request corresponding to the first request identifier does not exceed the processing capability of the relay node, where the second protocol is used to schedule the received quantum key distribution request, and the first message type is used to identify a sender of the quantum key distribution request to initiate the quantum key distribution request;
a first sending module, configured to send the second packet to the second end node through the first protocol;
a first obtaining module, configured to, when a third packet that is sent by the second end node for the second packet and has a message type of a second message type is received, obtain, through the second protocol and/or a third protocol, first keys between the relay node and the two nodes, respectively, based on types of the two nodes adjacent to the relay node and the key feature information, where the second message type is used to identify a resource reservation request initiated by a receiver of a quantum key distribution request, and the third protocol is used to distribute keys using quantum bits as an information carrier;
a second sending module, configured to send, through the first protocol, a key ciphertext generated based on the first key to a target end node, where the target end node is the first end node or the second end node, the key ciphertext is used to determine a target key shared by the first end node and the second end node, and the target key is used for mutual communication between the first end node and the second end node.
According to a fifth aspect of the present disclosure, there is provided a quantum key distribution apparatus applied to a first end node of a quantum key distribution network, including:
a seventh generating module, configured to generate a fifteenth packet through a fourth protocol, where the fourth protocol is used to initiate a quantum key distribution request, and the fifteenth packet includes a first request identifier of the quantum key distribution request initiated by the first end node, a first distribution path, a first node identifier of a second end node, and key feature information;
an eighth generating module, configured to generate, based on the first request identifier, the first distribution path, the first node identifier, and the key feature information, a first packet with a message type of a first message type through a second protocol, where the second protocol is used to process a packet according to a role type of an end node and a message type corresponding to the received packet, and the first message type is used to identify a sender of a quantum key distribution request to initiate a quantum key distribution request;
an eighth sending module, configured to send the first packet to the second end node through a first protocol, where the first protocol is used to determine a sending path of a packet in a quantum key distribution process of the quantum key distribution network;
a second obtaining module, configured to, when a third packet that is sent by the second end node for the first packet and has a second message type is received, obtain, through a third protocol, a target key shared with the second end node, where the target key is used for mutual communication between the first end node and the second end node, the third protocol is used for performing key distribution using a quantum bit as an information carrier, and the second message type is used for identifying a resource reservation request initiated by a receiver of a quantum key distribution request.
According to a sixth aspect of the present disclosure, there is provided a quantum key distribution device applied to a second end node of a quantum key distribution network, including:
a fourth receiving module, configured to receive a first packet sent by a first end node through a first protocol, where the first packet is generated by the first end node through a fourth protocol and a second protocol, the first protocol is used to determine a sending path of the packet in a process of quantum key distribution performed by the quantum key distribution network, the second protocol is used to process the packet according to a role type of an end node and a message type corresponding to the received packet, the fourth protocol is used to initiate a quantum key distribution request, and the first packet includes a first request identifier of the quantum key distribution request initiated by the first end node, a first distribution path, a first node identifier of the second end node, and key feature information;
a ninth generating module, configured to generate, based on the first request identifier, the first distribution path, the first node identifier, and the key feature information, a third packet with a message type of a second message type through the first protocol, the second protocol, and the fourth protocol, where the second message type is used to identify a resource reservation request initiated by a receiver of a quantum key distribution request;
a ninth sending module, configured to send the third packet to the first end node through the first protocol;
a third obtaining module, configured to obtain, through a third protocol, a target key shared by the first end node, where the target key is used for performing mutual communication between the first end node and the second end node, and the third protocol is used for performing key distribution by using a quantum bit as an information carrier.
According to a seventh aspect of the present disclosure, there is provided an electronic apparatus comprising:
at least one processor; and
a memory communicatively coupled to the at least one processor; wherein the content of the first and second substances,
the memory stores instructions executable by the at least one processor to enable the at least one processor to perform any one of the methods of the first aspect, or to perform any one of the methods of the second aspect, or to perform any one of the methods of the third aspect.
According to an eighth aspect of the present disclosure, there is provided a non-transitory computer readable storage medium having stored thereon computer instructions for causing a computer to perform any one of the methods of the first aspect, or to perform any one of the methods of the second aspect, or to perform any one of the methods of the third aspect.
According to a ninth aspect of the present disclosure, there is provided a computer program product comprising a computer program which, when executed by a processor, implements any of the methods of the first aspect, or performs any of the methods of the second aspect, or performs any of the methods of the third aspect.
According to the technology disclosed by the invention, the problem of poor request scheduling performance of the quantum key distribution network is solved, and the scheduling performance of the quantum key distribution network on the quantum key distribution request can be improved.
It should be understood that the statements in this section do not necessarily identify key or critical features of the embodiments of the present disclosure, nor do they limit the scope of the present disclosure. Other features of the present disclosure will become apparent from the following description.
Drawings
The drawings are included to provide a better understanding of the present solution and are not to be construed as limiting the present disclosure. Wherein:
fig. 1 is a schematic flow diagram of a quantum key distribution method according to a first embodiment of the disclosure;
fig. 2 is a schematic diagram of a protocol stack in a network architecture of a quantum key distribution network system;
FIG. 3 is a schematic diagram of a process flow of an end-to-end quantum key distribution request being rejected upon failure to join a request queue;
FIG. 4 is a diagram of an end-to-end quantum key distribution request beyond a relay node R 1 A processing capacity of the processing system is rejected;
fig. 5 is a schematic flow chart diagram of a quantum key distribution method according to a specific example provided in the present disclosure;
fig. 6 is a schematic flow diagram of a quantum key distribution method according to a second embodiment of the disclosure;
fig. 7 is a schematic flow diagram of a quantum key distribution method according to a third embodiment of the present disclosure;
fig. 8 is a schematic structural diagram of a quantum key distribution device according to a fourth embodiment of the present disclosure;
fig. 9 is a schematic structural diagram of a quantum key distribution device according to a fifth embodiment of the present disclosure;
fig. 10 is a schematic structural diagram of a quantum key distribution device according to a sixth embodiment of the present disclosure;
FIG. 11 is a schematic block diagram of an example electronic device used to implement embodiments of the present disclosure.
Detailed Description
Exemplary embodiments of the present disclosure are described below with reference to the accompanying drawings, in which various details of the embodiments of the disclosure are included to assist understanding, and which are to be considered as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the present disclosure. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.
First embodiment
Quantum key distribution provides a method for securely distributing keys between two communication parties, and the security of the method is ensured by the basic principle of quantum mechanics. According to the quantum unclonable principle, an unknown quantum state cannot be perfectly cloned, which prohibits an eavesdropper from copying transmitted information. Meanwhile, any eavesdropping operation in the quantum key distribution process can change the transmitted quantum state, so that the error rate is increased, and therefore two communication parties can detect the existence of an eavesdropper.
As shown in fig. 1, the present disclosure provides a quantum key distribution method applied to a relay node of a quantum key distribution network, including the following steps:
step S101: receiving a first message sent by a first end node through a first protocol, wherein the first message comprises a first request identifier of a quantum key distribution request initiated by the first end node, a first distribution path, a first node identifier of a second end node and key feature information, and the first protocol is used for determining a sending path of the message in the process of quantum key distribution performed by the quantum key distribution network;
step S102: under the condition that the number of resources required by a quantum key distribution request corresponding to the first request identifier is determined not to exceed the processing capacity of the relay node, generating a second message with a message type of a first message type through a second protocol based on the first request identifier, the first distribution path, the first node identifier and the key feature information, and sending the second message to the second end node through the first protocol, wherein the second protocol is used for scheduling the received quantum key distribution request, and the first message type is used for identifying that a sender of the quantum key distribution request initiates the quantum key distribution request;
step S103: under the condition that a third message of which the message type is the second message type is received, which is sent by the second end node for the second message, based on the types of two nodes adjacent to the relay node and the key feature information, acquiring first keys between the relay node and the two nodes respectively through the second protocol and/or the third protocol, wherein the second message type is used for identifying a resource reservation request initiated by a receiver of a quantum key distribution request, and the third protocol is used for using quantum bits as an information carrier to distribute keys;
step S104: and sending a key ciphertext generated based on the first key to a target end node through the first protocol, wherein the target end node is the first end node or the second end node, the key ciphertext is used for determining a target key shared by the first end node and the second end node, and the target key is used for mutual communication between the first end node and the second end node.
In the embodiment, the quantum key distribution method relates to the technical field of quantum computing, in particular to the technical field of quantum communication, and can be widely applied to a communication scene based on a key. The quantum key distribution method of the embodiments of the present disclosure may be executed by the quantum key distribution apparatus of the embodiments of the present disclosure. The quantum key distribution device of the embodiments of the present disclosure may be configured in any electronic device to perform the quantum key distribution method of the embodiments of the present disclosure. The electronic device may be a device corresponding to a relay node of a quantum key distribution network.
The quantum key distribution method of this embodiment is applied to a quantum key distribution network, which may include a first end node, a second end node, and a relay node, where the first end node may be an initiating node of a quantum key distribution request, and the second end node may be a node in end-to-end communication with the first end node.
The first end node and the second end node are called end nodes of a quantum key distribution network collectively, the quantum key distribution network may include a plurality of end nodes and a plurality of relay nodes, it is assumed that two end nodes in the quantum key distribution network want to communicate, and in order to ensure the confidentiality of communication, it is requested to use quantum key distribution to share a session key securely so as to encrypt and transmit data communicated by the session key. Several such requests are generated in a quantum key distribution network over a certain period of time.
When the quantum network processes the request, in addition to performance indexes such as bandwidth, time delay, packet loss rate and the like in the classical network, some factors such as fidelity, success probability, decoherence and the like with quantum communication characteristics need to be considered. Therefore, the structure and design in classical networks often cannot be directly applied to quantum networks.
In addition, the current industry is at a preliminary stage of research on quantum network architecture, and many different network architectures and designs are proposed by researchers, but a unified network architecture standard is lacking. In addition, most researches on quantum key distribution in the quantum network currently only study the response flow of the network to a single request and corresponding performance parameters, and the response process when the quantum network receives a plurality of quantum key distribution requests and the performance parameters of different nodes in the process of responding to a plurality of requests are rarely analyzed from the perspective of the whole network.
The purpose of this embodiment is to enable a quantum key distribution network to schedule and execute a quantum key distribution request through the design of the quantum key distribution network, so that a multi-user request can be scheduled for the quantum key distribution network processing, best effort delivery of the request and efficient utilization of network performance are ensured, an end-to-end key is efficiently and safely established for different end nodes, and communication security between the end nodes is improved.
Quantum Key Distribution (QKD) ensures communication security by using Quantum mechanical characteristics, and enables two communicating parties to generate and share a random and secure Key to encrypt and decrypt messages.
In the network architecture of the quantum key distribution network, a protocol stack carried by a relay node can have three layers, namely a scheduling layer, a network layer and a link layer from top to bottom, and the relay node is respectively provided with a protocol stack containing three layers of protocols.
As shown in fig. 2, in the relay node, a first protocol of the network layer, such as QKDRouting protocol, may determine a transmission path of the packet, and specifically may determine a downstream node adjacent to the transmission path.
The resource evaluation and scheduling can be carried out on the received quantum key distribution request through a second protocol of the scheduling layer, such as a QKDRMP protocol, so that the quantum key distribution network can process the request for scheduling multiple users, the scheduling and response to multiple requests on the whole network layer are realized, and the normal work of the network and the normal delivery of the requests are ensured.
A third protocol, such as the key generation protocol (e.g., BB84 protocol, etc.), passing through the link layer may establish keys with neighboring nodes, so that different end nodes may be enabled to obtain shared keys for communicating with each other.
Correspondingly, the protocol stack carried by the end node can have four layers, from top to bottom, an application layer, a scheduling layer, a network layer and a link layer are respectively arranged, and the end node is respectively provided with a protocol stack containing four layers of protocols.
As shown in fig. 2, in the end node, a quantum key distribution request may be initiated or handled by a fourth protocol at the application layer (at the top of the protocol stack), such as the QKDApp protocol.
The second protocol, such as the QKDRMP protocol, through the dispatch layer (at the third layer of the protocol stack) passes the request information to lower or upper layer protocols as appropriate depending on whether the end node is the initiator or the recipient of the request.
The sending path of the packet, and in particular, the downstream node adjacent to the sending path under the sending path, may be determined through a first protocol of a network layer (located at a second layer of a protocol stack), such as QKDRouting protocol.
A third protocol, such as the key generation protocol (e.g., BB84 protocol, etc.), passing through the link layer (at the first layer of the protocol stack), may establish keys with neighboring nodes, thereby allowing different end nodes to obtain shared keys for communicating with each other.
It should be noted that the network architecture of the quantum key distribution network system is independent of the specific protocol used by each layer, for example, in the QKDRouting protocol, the routing table may be generated by configuring a static route or according to a dynamic routing algorithm, in the key generation protocol, any quantum key distribution protocol such as BB84, B92 may be used, and even different key distribution protocols may be selected between different adjacent nodes according to needs or experimental equipment limitations.
In addition, in the network architecture of the quantum key distribution network, a message structure of the QKDRMPMessage message is designed for the QKDRMP protocol of the second layer of the protocol stack, as shown in table 1 below, to control operations of the scheduling layer on different types of messages in the quantum key distribution process. The message structure of the QKDRMPMessage mainly comprises four parts, namely a source node, a destination node, a message processing protocol and data content.
Table 1 message structure table of qkdrmmessage message
Figure BDA0003962450390000101
The source node refers to a sender of the message, the destination node refers to a receiver of the message, and the message type can be set in the data content to indicate different types of messages and carry out corresponding processing behaviors. As shown in table 2, for an exemplary type of message involved in the QKDRMPMessage message in the quantum key distribution process, this is described in detail below in describing the quantum key distribution process.
Table 2 message type table related to QKDRMPMessage message in quantum key distribution process
Figure BDA0003962450390000102
Figure BDA0003962450390000111
Similarly, the QKDRouting protocol located at the lower layer of the QKDRMP in the protocol stack sets the same message structure and similar message types to realize the interaction with the QKDRMP, so as to realize the step-by-step processing of the request.
In the network architecture of the quantum key distribution network system, a message structure of the QKDMessage message is designed for the QKDRouting protocol of the second layer of the protocol stack, and the message structure is the same as that of the qkdrmmessage, as shown in table 3 below.
Table 3 message structure table of QKDMessage message
Figure BDA0003962450390000112
As shown in table 4, for an example of the type of messages involved in the QKDMessage in the quantum key distribution process, this is described in detail below in the description of the quantum key distribution process.
Table 4 information type table related to QKDMessage in quantum key distribution process
Figure BDA0003962450390000113
Figure BDA0003962450390000121
Before step S101, if the first end node needs to establish a key with the second end node, a quantum key distribution request may be initiated, and the QKDApp protocol in its own protocol stack generates a qkdrmmessage (i.e., a fifteenth message) with a message type of a seventh message type PATH according to the corresponding message, as shown in table 5. The data may include information such as the path of the request (first distribution path), the number of keys, the key length (key characteristic information), the request id (first request identifier, unique identifier for distinguishing different requests), and the first node identifier of the second end node.
TABLE 5 Structure Table of the fifteenth message
Figure BDA0003962450390000122
Then, the message is transmitted to the QKDRMP protocol of the lower layer for processing, after the QKDRMP protocol of the first end node judges that the message type is PATH, a QKDMessage message (i.e. a first message) with the message type being the first message type REQUEST is generated according to the data of the PATH message, as shown in table 6, and is transmitted to the QKDRouting protocol of the lower layer.
Table 6 structure table of first message
Figure BDA0003962450390000123
The QKDrouting protocol in the first end node judges whether the message type is REQUEST, whether a direct connection channel exists between the first end node and the second end node or not is judged, if yes, the REQUEST message is transmitted through the direct connection channel, and if not, the REQUEST message (a first message) is transmitted through the relay node.
The first packet may include a first request identifier of a quantum key distribution request initiated by a first end node, a first distribution path, a first node identifier of a second end node, and key feature information.
Correspondingly, when the quantum key distribution request initiated by the first end node needs to be transmitted to the second end node through the relay node, in step S101, the relay node may receive the first packet sent by the first end node through the first protocol (i.e., QKDRouting protocol).
In step S102, after receiving the REQUEST message, the relay node adds itself to the path information of the REQUEST message (i.e., updates the first distribution path), and meanwhile, determines whether the number of resources required by the quantum key distribution REQUEST corresponding to the first REQUEST identifier exceeds the processing capability of the relay node, for example, determines whether the number of resources corresponding to the key feature information, the number of resources required by the processing REQUEST, and the like exceed the processing capability of the relay node.
In an optional implementation manner, the information can be unpacked through a QKDRouting protocol, and a qkdrmmessage with a message type of PATH is generated according to the data in the unpacked information and is transmitted to an upper layer of a protocol stack.
And after the QKDRMP protocol of the upper layer receives the PATH message, evaluating the quantum key distribution request represented by the message. For example, if the number of resources corresponding to the requested key feature information does not exceed the processing capability of the relay node, a QKDMessage message (i.e., a second message whose message type is a first message type REQUEST) consistent with the content of a previously received REQUEST message (i.e., a first message) may be generated by the QKDRMP protocol and delivered to the lower layer of the protocol stack based on the first REQUEST identifier, the first distribution path, the first node identifier, and the key feature information.
The fact that the number of resources corresponding to the requested key feature information does not exceed the processing capability of the relay node may mean that the number of resources corresponding to the requested key feature information does not exceed the maximum capacity of a key pool pre-constructed by the relay node, where the key pool stores keys generated by the relay node in advance through a key generation protocol.
Correspondingly, the QKDRouting protocol of the lower layer forwards the message to the next-hop node on the path according to the routing table stored in the node under the condition that the message type is determined to be the first message type REQUEST, so as to send the second message to the second end node.
In this way, the REQUEST message can reach the second end node by forwarding it layer by layer through the relay node between the first end node and the second end node.
After receiving the REQUEST message, the second end node adds itself to the PATH information of the message (i.e. updates the first distribution PATH), and generates a qkdrmmessage with a corresponding message type of PATH according to the information in the REQUEST message through a QKDRouting protocol, and transmits the message to the upper layer of the protocol stack.
The QKDRMP protocol continues to transmit the PATH message upward to the upper layer of the protocol stack, and after receiving the PATH message, the QKDApp protocol of the upper layer generates a qkdrmmessage (as shown in table 7) with a message type of the third message type RESV according to the first request identifier, the first distribution PATH, the first node identifier, and the key feature information in the PATH message, and transmits the QKDRMP message to the lower layer of the protocol stack.
Table 7 structure table of RESV message
Figure BDA0003962450390000141
After receiving the RESV message, the QKDRMP in the lower layer generates a QKDMessage (i.e., a third message) with the message type of the second message type ACCEPT according to the requested data information, as shown in table 8, and continues to deliver the QKDRMP to the lower layer of the protocol stack.
Table 8 structure table of the third packet
Figure BDA0003962450390000142
When the QKDrouting protocol at the lower layer receives the ACCEPT message, the ACCEPT message is forwarded to the previous hop node of the second end node according to the path information contained in the message; and meanwhile, starting a local KeyGeneration protocol, and waiting for starting key distribution with an upstream node.
Accordingly, in step S103, the relay node may receive, through the first protocol, a third message, i.e., an ACCEPT message, returned by the second end node with respect to the second message, i.e., the REQUEST message.
Then, based on the type and key feature information of the two adjacent nodes of the relay node, the first keys between the relay node and the two nodes may be obtained through the second protocol and/or the third protocol.
After receiving the ACCEPT message, the relay node firstly judges the types of the adjacent upstream node and downstream node of the relay node through QKDrouting protocol. If the relay node has an end node in two adjacent nodes, the key establishment protocol through the third protocol is started immediately to establish a key with the relay node so as to acquire a first key between the relay node and the two adjacent nodes.
If another relay node exists in the two adjacent nodes, the relay node can generate a corresponding RESV message through the QKDrouting protocol and transmit the RESV message to an upper layer of a protocol stack. Correspondingly, the relay node can schedule each end node and the quantum key distribution request passing through the relay node based on RESV information through a QKDRMP protocol, and perform corresponding resource management.
When the QKDRMP schedules and processes the quantum key distribution request corresponding to the first request identifier, the QKDRouting protocol located at the lower layer of the QKDRMP may receive the scheduling message, and obtain the first keys between the relay node and its two adjacent nodes respectively based on the key feature information.
In step S104, in the case that the two first keys are obtained, the two first keys are subjected to an exclusive or operation to generate a key ciphertext, and the key ciphertext is sent to the target end node through the QKDRouting protocol.
In an optional embodiment, the key transfer direction is from the first end node to the second end node, at this time, the key ciphertext may be sent to the second end node through the QKDRouting protocol, and the second end node completes the key exchange operation to obtain the target key.
In another optional implementation, the key transfer direction is from the second end node to the first end node, and at this time, the key ciphertext may be sent to the first end node through the QKDRouting protocol, and the first end node completes the key exchange operation to obtain the target key.
The key exchange operation is to perform exclusive or operation on a key established by the end node and the adjacent relay node and the received key ciphertext to obtain a key shared with the other end node.
In the embodiment, through the design of the quantum key distribution network, the QKDRMP protocol is designed on the relay node, so that the quantum key distribution request initiated by the end node can be scheduled and executed, thereby processing and scheduling multi-user requests for the quantum key distribution network, realizing the scheduling and processing of multiple requests in the quantum key distribution network, ensuring the best delivery of the requests and the efficient utilization of network performance, efficiently and safely establishing an end-to-end key for different end nodes, and improving the communication security between the end nodes.
And the QKDRMP protocol of each relay node can schedule the request according to parameters such as the arrival time of the request, the number of required resources and the like, so that the scheduling and response of a plurality of requests on the whole network level are realized, and the normal work of the network and the normal delivery of the request are ensured.
Optionally, the step S103 specifically includes at least one of the following:
under the condition that the types of the two nodes comprise a first type, obtaining a first key matched with the key feature information from a target key pool of N key pools of the relay node, which is constructed in advance, through the second protocol, wherein the target key pool is a key pool corresponding to an adjacent relay node of the relay node under the first distribution path, the first type indication node is the relay node, and N is a positive integer;
and under the condition that the types of the two nodes comprise a second type, establishing a first key with an adjacent end node of the relay node under the first distribution path through the third protocol, wherein the second type indicates that the node is an end node. In the key generation protocol, an upstream node may be selected as a sender of quantum information and a downstream node may be selected as a receiver, or vice versa. Without loss of generality, the upstream node can be unified as a sender of quantum information and the downstream node can start key distribution as a receiver of information during description.
In the present embodiment, in the entire quantum key distribution network, each relay node is provided with a structure for storing a key, which is referred to as a key pool. The key pools store keys generated between two adjacent relay nodes in the form of classical information, a plurality of key pools exist in one relay node, and the keys stored in different key pools can be used by requests passing through different links.
The key pool is an important structure for managing resources, interacts with the QKDRMP protocol and the QKDrouting protocol of the relay node and delivers the keys to the request. And the end node does not have a key pool structure and needs to establish a key with the relay node immediately.
That is, when the type of the two adjacent relay nodes includes the first type, that is, when there is a relay node in the two adjacent relay nodes, the relay node may generate a corresponding RESV message through the QKDRouting protocol and deliver the RESV message to an upper layer of the protocol stack. Correspondingly, the relay node can schedule each end node and the quantum key distribution request passing through the relay node based on RESV information through a QKDRMP protocol, and perform corresponding resource management.
When the QKDRMP schedules and processes the quantum key distribution request corresponding to the first request identifier, a QKDrouting protocol positioned at the lower layer of the QKDRMP can receive the scheduling message, and a first key matched with the key characteristic information is obtained from a target key pool in N key pools of the pre-constructed relay nodes through the QKDrouting protocol. The target key pool is a key pool corresponding to a relay node adjacent to the relay node in the first distribution path, that is, the key pool corresponding to a link between the relay node and the adjacent relay node.
Therefore, through the key pool structure and the QKDRMP protocol, the management and the distribution of network resources can be realized, the speed of the quantum key distribution network for delivering the key to the request can be improved, the best delivery of the request is ensured, and the performance parameters of different nodes in the network when responding to a plurality of requests are improved.
When the type of the two nodes adjacent to the relay node includes the second type, i.e., the end node exists in the two nodes adjacent to the relay node, the relay node may immediately start establishing the first key with the relay node through the third protocol, i.e., the key generation protocol.
Therefore, the relay node can adopt different operations according to the types of two adjacent nodes of the relay node, so as to realize the acquisition of the first secret key between the relay node and each of the two nodes and ensure the normal work of the network on secret key distribution.
Optionally, the obtaining, by the second protocol, a first key matched with the key feature information from a target key pool of N key pools of the relay node that is constructed in advance includes:
generating a fourth message with a message type of a third message type through the first protocol, wherein the third message type is used for identifying a resource reservation request initiated by a receiver of a quantum key distribution request, and the fourth message carries the key characteristic information and the first request identification;
under the condition that the number of the requests in the pre-constructed request queue is determined to be smaller than a first preset threshold value through the second protocol, adding the fourth message into the request queue;
and under the condition that the fourth message corresponding to the first request identifier is obtained from the request queue, obtaining a first key matched with the key characteristic information from the target key pool.
In this embodiment, if at least one side of the relay node is a relay node, the QKDRouting protocol may generate an RESV message (i.e., a fourth packet) whose message type is a third message type, and transmit the RESV message to an upper layer of the protocol stack.
When the QKDRMP receives the RESV message, it may be determined whether the number of requests in the pre-constructed request queue reaches a first preset threshold, and if not, the RESV message may be added to the request queue (i.e., the request corresponding to the fourth message is added to the request queue). The first preset threshold may be set according to actual conditions, and is not specifically limited herein.
The present embodiment designs a request queue structure to implement the receiving, scheduling, and processing of requests. When a relay node receives the request, the QKDrouting protocol judges whether the request needs the assistance of the key pool, if so, the request is transmitted to the upper layer of the protocol stack, and if not, the key generation protocol of the lower layer of the protocol stack is informed to start to establish the key. The QKDRMP protocol at the upper layer may add the request (e.g., RESV message for the request) to the request queue upon receipt of the request. In this way, when the relay node receives the RESV message, it can add the RESV message into the request queue to wait for scheduling, and further limit the traffic of the relay node by the request queue with fixed capacity.
The QKDRMP protocol of each relay node may schedule the request according to parameters such as the time of arrival of the request and the number of resources required. The request queue can determine the execution sequence of the requests according to a first-in first-out principle or other scheduling principles, and monitor whether the relay node is in a state of processing the requests in real time. If the relay node is in an idle state, a request is thrown for processing. After each request is processed, the relay node also informs the request queue to throw the next request.
When the request queue throws a request, for example, a request corresponding to the first request identifier is thrown, that is, the relay node may obtain the fourth packet corresponding to the first request identifier from the request queue. Accordingly, the relay node can obtain the first key matched with the key feature information from the target key pool.
Therefore, by designing a network structure for resource management and request scheduling of the quantum key distribution network, namely by designing the QKDRMP protocol and the request queue, the relay node can realize quantity evaluation and ordered scheduling processing of quantum key distribution requests by combining the QKDRMP protocol and the request queue, thereby being beneficial to efficiently exerting the performance of the network and ensuring the quality of user service and having important theoretical and practical significance.
Optionally, the method further includes:
under the condition that the number of the requests in the request queue is determined to be greater than or equal to the first preset threshold value through the second protocol, generating a fifth message with two message types as a fourth message type through the second protocol, wherein the fourth message type is used for identifying that a resource reservation request is rejected by the relay node, the fifth message carries an error type field, and the error type field is used for indicating the sending direction of the message;
and respectively sending the fifth message to an end node corresponding to the first request identifier in the quantum key distribution network through the first protocol based on the value of the error type field in the fifth message.
In this embodiment, after receiving the request, if the QKDRMP protocol at the upper layer determines that the request queue is full (that is, it is determined that the number of requests in the request queue is greater than or equal to the first preset threshold), the QKDRMP protocol determines that the relay node is busy at this time and cannot process the request, which may cause failure in adding the fourth packet into the request queue, and the relay node rejects the quantum key distribution request corresponding to the fourth packet, generates a relevant rejection message, and invokes the QKDRouting protocol to send the relevant rejection message to the upstream node and the downstream direction.
At this time, two QKDMessage messages (i.e. fifth messages) with a message type of the fourth message type REJECT may be generated through the QKDRMP protocol, as shown in table 9 and table 10.
TABLE 9 Structure Table of the fifth message
Figure BDA0003962450390000191
Table 10 structure table of another fifth message
Figure BDA0003962450390000192
The source nodes of both REJECT messages are current relay nodes (with relay node R) p For example), and the destination nodes are Alice and Bob, respectively.
In addition, both the two fifth packets, i.e., the two REJECT messages, may carry an error type field, and the values of the error type field err _ type in the data content may be set to 2 and 3, respectively. The QKDRMP protocol may pass REJECT messages to the lower layers of the protocol stack.
After the QKDrouting protocol positioned at the lower layer of the QKDRMP in the protocol stack receives the message from the QKDRMP protocol, different operations are adopted according to the type of the message.
In one scenario, if a REJECT message is received, the QKDRouting protocol first determines the error type field err _ type in its data content, and if err _ type =2 of the REJECT message and the destination node is Alice (i.e., the first end node), the QKDRouting protocol forwards the REJECT message to the previous-hop node for transmission to the first end node.
If err _ type =3 and the destination node is Bob (i.e., the second end node), the QKDRouting protocol forwards the REJECT message to the next-hop node for transmission to the second end node. Correspondingly, when the downstream node of the relay node receives the REJECT message, a QKDRMPMessage message with the message type of REJECT can be generated according to the REJECT message through the QKDRouting protocol and transmitted to the upper layer of the protocol stack. When receiving the REJECT message, the QKDRMP protocol at the upper layer checks whether a RESV message corresponding to the same request exists in its request queue using the request id field in the message, discards the RESV message if the RESV message exists, and records the key corresponding to the request as an invalid key (i.e., records the state of the key as invalid) if the RESV message does not mean that the request is executed at the current relay node, and synchronizes the message of the invalid key to the second end node Bob.
The process flow of an end-to-end quantum key distribution request that is rejected upon failure to join the request queue is shown in fig. 3. Wherein the figure is that the quantum key distribution request is at the relay node R 2 Communication flow diagram after a failure to join a request queue, as shown in FIG. 3, superscript 1 Indicating when the request is at the relay node R 2 When the attempt to join the request queue fails, the relay node R 2 The QKDRMP protocol generates two REJECT messages to be transmitted downwards, and the QKDrouting protocol transmits the two REJECTsMessages are transmitted upstream/downstream, respectively. Upper label 2 Indicating that if the request is not present in the request queue at that time, meaning that the request has been scheduled and delivered, the relay node R at that time 3 The request corresponding key may be recorded as an invalid key.
Therefore, by designing the REJECT message to inform that the quantum key distribution request reaching the relay node is rejected, the resources of the relay node can be effectively managed, the request can be effectively processed, and the request can be efficiently processed.
Optionally, the method further includes:
under the condition that a sixth message with a fourth message type is received and the value of an error type field carried by the sixth message is a first target value, if a message corresponding to a second request identifier carried by the sixth message is inquired in the request queue, deleting the message corresponding to the second request identifier in the request queue;
if the message corresponding to the second request identifier carried by the sixth message is not queried in the request queue, recording the key corresponding to the second request identifier as an invalid key.
In this embodiment, the relay node may send a REJECT message carrying the first request identifier according to the condition of the queue request, and other relay nodes may also send a REJECT message according to the condition of the queue request, and when the relay node receives a REJECT message (i.e., a sixth packet) carrying the second request identifier, the relay node may determine a value of an error type field carried by the REJECT message, and if the value of the error type field carried by the REJECT message is a first target value (for example, the first target value is 3), the relay node may generate a QKDRMPMessage message with a message type of REJECT according to the REJECT message through a QKDRouting protocol and transmit the QKDRMPMessage message to an upper layer of a protocol stack.
When receiving the REJECT message, the QKDRMP protocol at the upper layer checks whether a RESV message corresponding to the same request exists in its request queue using the request id (i.e., the second request identifier) in the REJECT message, discards the RESV message if the RESV message exists, and records the key corresponding to the request as an invalid key if the RESV message does not exist, which means that the request has been executed at the current relay node, and synchronizes the message of the invalid key to the second end node Bob. Therefore, resources of the relay node can be effectively managed, and normal work of the network and normal and accurate delivery of other requests are guaranteed.
Optionally, after the adding the fourth packet to the request queue, the method further includes:
generating a seventh message with a message type of the second message type through the second protocol, where the seventh message carries an operation type field and the first distribution path, and the operation type field is used to indicate an operation mode for the message;
and sending the seventh packet to the first end node through the first protocol based on the first distribution path under the condition that the value of the operation type field is determined to be a second target value.
In this embodiment, if the fourth message is successfully added to the request queue, a QKDMessage (that is, a seventh message) whose message type is a second message type ACCEPT is generated by using a QKDRMP protocol, and is delivered to the lower layer of the protocol stack, where the ACCEPT message may include an operation type field and a first distribution path, and the operation type field may be set to 'forwarded'.
After the QKDrouting protocol positioned at the lower layer of the QKDRMP in the protocol stack receives the message from the QKDRMP protocol, different operations are adopted according to the type of the message. If the ACCEPT message is received and the value of the operation type field is a second target value, such as 'Forward', the QKDRouting protocol forwards the ACCEPT message to the previous-hop node of the current node according to the path information in the ACCEPT message, so as to send the ACCEPT message to the first end node, and waits for the request to be thrown out by the request queue.
Therefore, the resource reservation of the request can be realized, and the forwarding of the resource reservation message of the second end node to the first end node is realized, so that the normal operation of the network is ensured.
Optionally, after the adding the fourth packet to the request queue, the method further includes:
generating an eighth message with a message type of a fifth message type through the second protocol, where the eighth message includes the first distribution path and the first node identifier, and the fifth message type is used to identify that the relay node successfully adds the resource reservation request to the request queue;
and sending the eighth packet to the second end node through the first protocol based on the first distribution path and the first node identifier.
In this embodiment, if the fourth message is successfully added to the request queue, a QKDMessage (i.e., an eighth message) with a message type of the fifth message type CONF is generated through the QKDRMP protocol, and as shown in table 11, the QKDMessage is transmitted to the lower layer of the protocol stack as a credential requesting that the current relay node successfully add to the request queue.
Table 11 structure table of eighth packet
Figure BDA0003962450390000221
After QKDrouting protocol positioned at the lower layer of QKDRMP in the protocol stack receives the message from QKDRMP protocol, different operations are taken according to the message type. And if the CONF message is received, forwarding the CONF message to a next hop node according to the destination node and the path information in the CONF message. And the downstream node directly forwards the CONF message after receiving the CONF message until the CONF message reaches the second end node Bob.
Therefore, the normal operation of the network can be realized by designing the CONF message as a feedback mechanism for receiving the quantum key distribution request.
Optionally, the obtaining, from the target key pool, the first key matched with the key feature information under the condition that the fourth packet corresponding to the first request identifier is obtained from the request queue includes:
under the condition that the fourth message corresponding to the first request identifier is acquired from the request queue, based on the fourth message, generating a ninth message with a message type of the second message type through the second protocol, wherein the ninth message carries an operation type field;
and under the condition that the value of the operation type field is determined to be a third target value, acquiring a first key matched with the key characteristic information from the target key pool through the first protocol.
In this embodiment, when the request queue throws a request, for example, when the relay node obtains the fourth packet corresponding to the first request identifier from the request queue, the relay node may generate, by using the QKDRMP according to the RESV message thrown in the request queue, a QKDMessage (that is, a ninth packet) whose message type is a second message type ACCEPT, where the ACCEPT message may include an operation type field, and a value of the operation type field may be set to 'operation', and the message is transmitted to a protocol stack lower layer.
After receiving the ACCEPT message representing that the request is scheduled, the QKDRouting protocol located at the lower layer of the QKDRMP confirms that the value of the operation type field is a third target value, such as 'operation', and then takes different operations according to the types of two nodes adjacent to the relay node, so as to obtain a first key matched with the key characteristic information from the target key pool through a first protocol.
Specifically, the relay node is a relay node R p For example, when the relay node R p When both ends are relay nodes, the QKDrouting protocol respectively takes out first keys between the two target key pools and the upstream node/downstream node respectively, and the first keys are respectively expressed as
Figure BDA0003962450390000231
And &>
Figure BDA0003962450390000232
If the relay node R p One end is a relay node, the other end is an end node, the QKDrouting protocol takes a first key from a target key pool corresponding to the relay node end, and the other end establishes the first key with the end node by starting a KeyGeneration protocol.
Therefore, the quantum key distribution request can be dispatched through the request queue, the key delivery of the relay node to the request can be realized through the key pool, and therefore the multi-user request can be processed and dispatched for the quantum key distribution network, and the network resources can be effectively managed.
Optionally, after the first key matched with the key feature information is obtained from the target key pool through the first protocol, at least one of the following is further included:
performing exclusive or operation on two first keys respectively obtained from the target key pool under the condition that the types of the two nodes are the first type to obtain the key ciphertext;
and under the condition that the types of the two nodes are the first type and the second type respectively, if the relay node and the two nodes finish key distribution respectively after inquiry, performing exclusive or operation on a first key acquired from the target key pool and a first key established through the third protocol to obtain the key ciphertext.
In this embodiment, when two adjacent nodes of the relay node are both relay nodes, when two first keys are obtained from the target key pool, an exclusive or operation may be performed on the two first keys to generate a key ciphertext, and the key ciphertext may be used as the key ciphertext
Figure BDA0003962450390000241
And (4) showing.
Under the condition that one relay node and the other relay node are end nodes in two adjacent relay nodes, when the first key is acquired from the target key pool, whether the key establishment process on the other side is completed or not can be inquired, if so, the two first keys are subjected to exclusive-or operation to generate a key ciphertext, and if not, the first key acquired from the target key pool can be temporarily stored locally. Similarly, when the first key establishment on the other side is completed, whether the key on the key pool side is delivered completely is queried, and the same subsequent operation is taken.
Thus, the normal operation of the network can be realized.
Optionally, the step S104 specifically includes:
generating a tenth message with a message type of a sixth message type through the first protocol, wherein the tenth message comprises the first distribution path and the key ciphertext, and the sixth message type is used for identifying the key ciphertext generated by the relay node according to the keys of two adjacent nodes;
sending the tenth message to the target end node over the first protocol based on the first distribution path.
In this embodiment, under the condition of obtaining the key CIPHERTEXT, a QKDMessage (that is, a tenth packet) whose message type is a sixth message type CIPHERTEXT may be generated through a QKDRouting protocol, as shown in table 12, the CIPHERTEXT message may carry the first distribution path and the key CIPHERTEXT, and the CIPHERTEXT message is sent to the target end node according to the path through which the CIPHERTEXT message is transmitted and the key distribution direction. For example, if the key distribution direction is from the first end node to the second end node, the cipherext message may be sent to the next-hop node of the current relay node, so that the cipherext message reaches the second end node.
Table 12 structure table of the tenth packet
Figure BDA0003962450390000242
Figure BDA0003962450390000251
Therefore, the normal operation of the key distribution work of the network to different end nodes can be ensured.
Optionally, the method further includes:
analyzing the first message through the first protocol;
generating an eleventh message with a message type of a seventh message type through the first protocol based on the analyzed first request identifier, the analyzed first distribution path, the analyzed first node identifier of the second end node, and the analyzed key feature information, wherein the seventh message type is used for identifying and sending out a quantum key distribution request;
generating a twelfth message with a message type of a fourth message through the second protocol under the condition that the number of resources corresponding to the key feature information is determined to exceed the maximum capacity of a target key pool of the N key pools of the relay node, which are constructed in advance, based on the eleventh message;
and sending the twelfth message to the first end node through the first protocol based on the first distribution path under the condition that the value of the error type field carried by the twelfth message is determined to be a fourth target value.
In this embodiment, after receiving the REQUEST message (i.e., the first packet) through the QKDRouting protocol, the relay node may add itself to the PATH of the REQUEST message, unpack the REQUEST message through the QKDRouting protocol, generate a QKDRMPMessage message (i.e., the eleventh packet) with a message type of the seventh message type PATH according to the data (including the first REQUEST identifier, the first distribution PATH, the first node identifier of the second end node, and the key feature information) therein, and transmit the QKDRMPMessage message to the upper layer of the protocol stack.
After receiving the PATH message, the QKDRMP protocol at the upper layer performs resource evaluation on the request represented by the PATH message, and rejects the quantum key distribution request corresponding to the PATH message if the resource number corresponding to the key feature information exceeds the maximum capacity of a target key pool (a key pool corresponding to a transmission link for the quantum key distribution request) of the relay node.
At this time, the QKDRMP protocol may generate a QKDMessage (i.e., the twelfth packet) with a message type of the fourth message type REJECT, set the value of the error type field in the data to 1, as shown in table 13, and deliver the error type field to the lower layer of the protocol stack.
TABLE 13 Structure Table of the twelfth message
Figure BDA0003962450390000261
And the QKDrouting of the lower layer takes different operations according to the message type of the received QKDmessage. If the REJECT message is received, the QKDrouting protocol judges whether the value of the error type field is a fourth target value such as 1, if so, the REJECT message is forwarded to the previous hop node according to the path information contained in the REJECT message. After receiving the REJECT message, the relay nodes on the upstream path directly forward the REJECT message upstream until the REJECT message reaches the first end node.
When receiving the REJECT message, the first end node can transmit the REJECT message layer by layer upwards to a QKDApp protocol, and the QKDApp protocol discards the corresponding quantum key distribution request.
An end-to-end quantum key distribution request exceeds the relay node R 1 The processing capacity of (4) is rejected and the flow of the process is shown in fig. 4. Therefore, when the QKDRMP protocol of the relay node receives the PATH message, the quantum key distribution request can be roughly evaluated, the request exceeding the processing capacity of the relay node is filtered, the quantum key distribution request from end to end in the network can be effectively scheduled and processed, the efficiency of the network is improved, and the applicable scene is more in line with the actual requirement.
Optionally, after step S104, the method further includes:
receiving a thirteenth message which is sent by the target end node aiming at the key ciphertext and has an eighth message type;
and the eighth message type is used for identifying that the target end node confirms to receive the key ciphertext sent by the relay node.
In this embodiment, a target end node, such as a second end node, receives a signal from a relay node R q When the QKDMessage (namely the tenth message) with the message type of CIPHERTEX is the QKDRMmessage of CIPHERTEX, the QKDrouting protocol directly generates a QKDRMPMessage with the corresponding message type of CIPHERTEX and transmits the QKDRMPMessage to an upper layer, and after the QKDRMP protocol receives the QKDRMPMessage with the message type of CIPHERTEX, the QKDRMP protocol receives the QKDRMPMessage with the relay node R q The key cryptogram and the CIPHERTEXT message is transmitted on to the upper layer.
After receiving the CIPHERTEXT message, the QKDApp protocol stores the CIPHERTEXT message locally and generates a target node which is a relay node R q The QKDRMPMessage message with the eighth message type ACKNOWLEDGE is passed to the lower layer as shown in table 14.
Table 14 structure table of QKDRMPMessage message of ACKNOWLEDGE
Figure BDA0003962450390000271
After receiving the message, the QKDRMP protocol of the lower layer generates a QKDMessage (i.e., a thirteenth packet) corresponding to the eighth message type ACKNOWLEDGE, and continues to deliver the message to the lower layer as shown in table 15. The QKDrouting protocol forwards the ACKNOWLEDGE message to the upper-hop node until the relay node R is reached q 。
Table 15 structure table of QKDMessage of ACKNOWLEDGE
Figure BDA0003962450390000272
Therefore, a feedback mechanism of the ACKNOWLEDGE message is designed, and the normal operation of the network is ensured.
Optionally, after step S104, the method further includes:
receiving a fourteenth message, which is sent by the target end node for the key ciphertext and has a message type of a ninth message type, where the fourteenth message carries the first distribution path, and the ninth message type is used to identify that establishment of a key shared by the first end node and the second end node is completed;
and sending the fourteenth message to the other end node sharing the key with the target end node through the first protocol based on the first distribution path.
In this embodiment, each time the QKDApp protocol of the target end node, such as the second end node Bob, receives a cipher key CIPHERTEXT and stores the cipher key CIPHERTEXT, the target end node checks whether the cipher key CIPHERTEXTs of all relay nodes are received, and if so, performs the following decryption operation (i.e., key exchange operation) on the cipher key CIPHERTEXTs to obtain the cipher key CIPHERTEXT shared with the first end node AliceTarget key, key exchange operation being
Figure BDA0003962450390000281
Meanwhile, the QKDApp protocol in the protocol stack generates a qkdrmmessage whose destination node is the first end node Alice and whose message type is the ninth message type DONE, and transmits the qkdrmmessage to the lower layer of the protocol stack as shown in table 16, the QKDRMP protocol of the lower layer generates a QKDMessage message whose corresponding message type is DONE (i.e. the fourteenth message) according to the DONE message, and continues to transmit to the lower layer as shown in table 17, and the QKDRouting protocol is responsible for transmitting the DONE message to the first end node Alice.
Table 16DONE structure table of qkdrmmessage message
Figure BDA0003962450390000282
Table 17 structure table of QKDMessage message of DONE
Figure BDA0003962450390000283
/>
In this way, key establishment for two different end nodes can be achieved.
As shown in fig. 5, assuming that a user Alice (corresponding to a first end node) in the network wishes to establish a target key with another user Bob (corresponding to a second end node) through quantum key distribution, a specific flow from generation to delivery of a quantum key distribution request is as follows:
initiating a key REQUEST (namely a quantum key distribution REQUEST) by Alice, generating a REQUEST message and sending the REQUEST message to a next hop node;
2. the relay node receives the REQUEST message and selects to forward or reject the message according to the requirement of the message on resources;
bob receives the REQUEST message, the protocol stack processes the message, and returns ACCEPT message;
4. receiving ACCEPT information by relay nodes along the way, and adding corresponding requests into a request queue;
5, the Alice receives the ACCEPT message and starts to distribute the key with the downstream node;
6. the end node stores the key generated by the upstream/downstream;
after receiving the Clohertext message from the relay node, bob records and returns an acknowledgement message ACKNOWLEDGE;
b, confirming that the key ciphertexts of all the relay nodes are received, decrypting the key ciphertexts to obtain an end-to-end target key, and sending a DONE message back to Alice;
9. the relay node forwards the DONE message;
and 10.Alice receives the DONE message.
In FIG. 5, superscripts are shown 1 The judgment condition at (2) is whether the number of requested resources is greater than the maximum capacity of the key pool.
At this point, alice and Bob complete the key establishment.
Second embodiment
As shown in fig. 6, the present disclosure provides a quantum key distribution method applied to a first end node of a quantum key distribution network, including the following steps:
step S601: generating a fifteenth message through a fourth protocol, where the fourth protocol is used to initiate a quantum key distribution request, and the fifteenth message includes a first request identifier of the quantum key distribution request initiated by the first end node, a first distribution path, a first node identifier of a second end node, and key feature information;
step S602: generating a first message with a message type of a first message type through a second protocol based on the first request identifier, the first distribution path, the first node identifier and the key feature information, wherein the second protocol is used for processing the message according to the role type of the end node and the message type corresponding to the received message, and the first message type is used for identifying that a sender of the quantum key distribution request initiates the quantum key distribution request;
step S603: sending the first message to the second end node through a first protocol, wherein the first protocol is used for determining a sending path of the message in the process of quantum key distribution of the quantum key distribution network;
step S604: and under the condition that a third message, which is sent by the second end node aiming at the first message and has a second message type, is received, acquiring a target key shared with the second end node through a third protocol, wherein the target key is used for mutual communication between the first end node and the second end node, the third protocol is used for using quantum bits as an information carrier to distribute keys, and the second message type is used for identifying a resource reservation request initiated by a receiver of a quantum key distribution request.
In this embodiment, in step S601, if the first end node needs to establish a key with the second end node, a quantum key distribution request may be initiated, and the qkdapps protocol in its own protocol stack generates a QKDRMPMessage message (i.e., a fifteenth message) with a message type of the seventh message type PATH according to the corresponding message, as shown in table 5. The data may include information such as the path of the request (first distribution path), the number of keys, the key length (key characteristic information), the request id (first request identifier, unique identifier for distinguishing different requests), and the first node identifier of the second end node.
In step S602, the message is transmitted to the lower QKDRMP protocol for processing, and after the QKDRMP protocol of the first end node determines that the message type is PATH, a QKDMessage message (i.e. a first packet) with a message type of first message type REQUEST is generated according to the data of the PATH message, as shown in table 6, and is transmitted to the lower QKDRouting protocol.
In step S603, the QKDRouting protocol in the first end node determines that the message type is REQUEST, determines whether a direct connection channel exists between the first end node and the second end node, and transmits the REQUEST message through the direct connection channel if the direct connection channel exists, or transmits the REQUEST message (the first packet) through the relay node. The detailed process of transmitting the REQUEST message (the first packet) through the relay node and reaching the second end node has been described in detail in the first embodiment, and is not described herein again.
In step S604, after receiving the first message, if the second end node has sufficient local resources, the second end node may add the node identifier of its own node to the first distribution path, generate a third message including complete path information, key feature information to be established, and the like, which may be referred to as an ACCEPT message, and return the ACCEPT message in an original path according to the path information. And meanwhile, starting a KeyGeneration protocol to distribute quantum keys with the upstream nodes adjacent to the second end node, and establishing keys.
When the second end node returns a third message, namely an ACCEPT message, if the first end node and the second end node are not directly connected, the relay node on the way receives the ACCEPT message, performs resource evaluation, and then adds the request into the request queue, and when the request is thrown out from the request queue to perform scheduling processing of the request, according to key feature information such as the number and length of keys, the key of the upstream/downstream node is obtained from the key pool, a key ciphertext is generated and then sent to the target end node, so that the end node obtains a target key shared between the first end node and the second end node.
When the first end node receives a third packet, which is sent by the second end node for the first packet and has the message type of the second message, the third protocol, namely, the key generation protocol, may be started, and the downstream node adjacent to the first end node performs quantum key distribution to establish a key. The detailed process of the second end node sending the third packet with the second message type for the first packet has already been described in detail in the first embodiment, and is not described herein again.
Accordingly, in a case where both the first end node and the second end node initiate the KeyGeneration protocol, the first end node may acquire the target key shared with the second end node through the KeyGeneration protocol, and the second end node may also acquire the target key shared with the first end node through the KeyGeneration protocol.
In an optional embodiment, if the first end node and the second end node are directly connected, that is, a direct quantum channel exists between the first end node and the second end node, the target key generated by the end node (the first end node or the second end node) may be encoded into a quantum bit by using a key generation protocol, and transmitted to the other end node through the direct quantum channel.
In another optional implementation manner, if the first end node and the second end node are not directly connected, that is, the quantum key distribution needs to be performed through the relay node in the middle, at this time, a key ciphertext sent by the relay node may be obtained, and the target key generated based on the end node is exchanged to the other end node by means of the key ciphertext of the relay node, so that the other end node may obtain the target key communicated with the end node.
In this embodiment, through the design of the quantum key distribution network, the QKDRMP protocol is designed on the first end node, and the consistency of the protocol design of each node in the network is maintained, so that the relay node can schedule and execute the quantum key distribution request initiated by the end node, and thus, a multi-user request can be scheduled for the quantum key distribution network, the scheduling and processing of multiple requests in the quantum key distribution network are realized, the best effort delivery of the requests and the efficient utilization of network performance are ensured, an end-to-end key is efficiently and safely established for different end nodes, and the communication security between the end nodes is improved.
Optionally, the step S604 specifically includes any one of the following steps:
establishing a target key for mutual communication with a downstream node adjacent to the first end node under the first distribution path through the third protocol, so that the second end node obtains the target key for communication with the first end node;
receiving first quantum information sent by the second end node through the third protocol under the condition that the second end node is a downstream node adjacent to the first end node in the first distribution path, wherein the first quantum information carries a target key, and the target key is a key which is generated by the second end node and is communicated with the first end node;
receiving a thirteenth message respectively sent by the M relay nodes through the first protocol under the condition that M relay nodes exist between the first end node and the second end node, and performing exclusive OR operation on a second key and a key ciphertext carried by the thirteenth message to obtain the target key, wherein the key ciphertext is obtained by performing exclusive OR operation on two first keys, the two first keys are keys shared by the relay node and an adjacent upstream node and an adjacent downstream node respectively, the second key is a key established by the first end node and the adjacent downstream node through the third protocol, and M is a positive integer.
In this embodiment, the obtaining of the target key shared with the second end node through the third protocol may include three scenarios.
The first scenario is: the first end node establishes a target key with a downstream node adjacent to the first end node through a third protocol, and transmits the target key to the second end node, so that the second end node obtains the target key communicated with the first end node, namely the key transmission direction is from the first end node to the second end node.
The method for establishing the target key by the first end node and the adjacent downstream node thereof through the third protocol may include two methods, the first end node may generate the target key, encode the target key into the quantum bits through the third protocol, and distribute the target key to the downstream node through the quantum channel, that is, distribute the key from upstream to downstream, or establish the key by the adjacent downstream node, encode the target key into the quantum bits through the third protocol, and distribute the target key to the first end node through the quantum channel, that is, distribute the key from downstream to upstream. Where the concepts of downstream and upstream are relative to a distribution path, the distribution path may be defined as a path from a first end node to a second end node.
The second scenario is: the key transmission direction is from the second end node to the first end node, the second end node can establish a target key with an upstream node thereof through a third protocol, under the condition that the first end node is directly connected with the second end node, the second end node can directly send quantum information carrying the target key to the first end node, and correspondingly, the first end node can receive the quantum information sent through the third protocol to obtain the target key.
The way in which the second end node can establish the target key with its upstream node through the third protocol may be similar to the way in which the first end node establishes the target key with its adjacent downstream node through the third protocol, and is not described herein again.
The third scenario is: in this scenario, the relay node may obtain the first key and obtain a key ciphertext by using the method of the first embodiment, where the key established by the second end node and the upstream node thereof may be a target key, and the key established by the first end node and the downstream node thereof may be a second key.
The relay node sends the tenth message carrying the key ciphertext to the first end node, and the first end node may perform joint decryption on the received key ciphertext through the second key, and specifically may perform an exclusive or operation on the second key and the key ciphertext carried in the tenth message to obtain the target key.
In this embodiment, a suitable transmission mode may be selected according to an actual scenario of key transmission, so that both the first end node and the second end node may obtain a target key for end-to-end communication between the first end node and the second end node.
Optionally, the first key includes at least one of:
under the condition that the M relay nodes comprise first relay nodes, the first key is obtained by the first relay node from a target key pool in N key pools of the first relay node which is constructed in advance based on the key characteristic information, at least one of the first relay node and the adjacent downstream node is a node of the relay node, the target key pool is a key pool corresponding to the adjacent relay node of the first relay node, and N is a positive integer;
in a case where the M relay nodes include a second relay node, the first key is a key that the second relay node establishes with a neighboring end node through the third protocol, the second relay node being a node of which at least one of a neighboring upstream node and a neighboring downstream node is an end node.
In this embodiment, through the key pool structure and the QKDRMP protocol, management and distribution of network resources can be achieved, the speed of the quantum key distribution network for delivering the key to the request can be increased, best delivery of the request is guaranteed, and performance parameters of different nodes in the network in responding to multiple requests are increased.
Optionally, after step S604, the method further includes:
under the condition that the first end node generates a sixteenth message with a message type of a tenth message type through the first protocol, storing a secret key carried by the sixteenth message through the second protocol and a fourth protocol;
wherein the tenth message type is used to identify that the first end node established a key with an adjacent downstream node via the third protocol.
In this embodiment, after the first end node and the second end node successfully establish the key through the KeyGeneration protocol, the QKDRouting protocol may generate a QKDMessage (that is, a sixteenth message) with a message type of the tenth message type READY, as shown in table 18, store the generated key therein, and then the QKDRouting protocol transmits the READY message to the upper layer.
Table 18 structure table of QKDMessage message of READY
Figure BDA0003962450390000341
After receiving the message, the QKDRMP protocol in the upper layer generates a qkdrmmessage corresponding to the message type READY, and as shown in table 19, the QKDRMP protocol continues to transmit to the upper layer of the protocol stack. And after the QKDApp protocol at the top layer receives the message, the key is stored.
Table 19 structure table of QKDRMPMessage message of READY
Figure BDA0003962450390000342
Figure BDA0003962450390000351
In this way, storage of the key is achieved.
Optionally, the sixteenth packet further carries a completion field, where the completion field is used to indicate whether establishment of a key shared by the first end node and the second end node is completed, and the method further includes:
setting a value of the completion field to a fifth target value when the first end node and the second end node are directly connected, the fifth target value indicating that establishment of a key shared by the first end node and the second end node is completed;
setting a value of a completion field to a sixth target value indicating that establishment of a key shared by the first end node and the second end node is not complete, if the first end node and the second end node are not directly connected.
In this embodiment, after the first end node and the second end node successfully establish the key through the key generation protocol, it may be determined whether further key exchange operation needs to be performed through the QKDRouting protocol. A completion field may be carried in the READY message to indicate whether further key exchange operations need to be performed, such as completion flags shown in tables 18 and 19.
If there is a direct connection between the first end node and the second end node, the end-to-end key establishment has been completed without a subsequent key exchange operation. Accordingly, the completion field carried in the READY message may be set to a fifth target value, and the fifth target value may be tune.
Accordingly, the first end node and the second end node can learn that the process of establishing the end-to-end key is completed according to the value of the completion field (i.e. completion flag) in the data content of the message, store the key, and end the quantum key distribution request at the end node side.
If no directly connected channel exists between the first end node and the second end node, further key exchange operations need to be performed to complete the establishment of the end-to-end key. At this time, the value of the completion field of the data content in the READY message generated by the QKDRouting and QKDRMP protocols is set as a sixth target value, the sixth target value may be False, and the QKDApp node saves the key after receiving the READY message and waits for a subsequent key exchange operation.
In this way, preservation of the key can be achieved.
Optionally, after step S604, the method further includes:
storing the target key through the second protocol and the fourth protocol when receiving a fourteenth message, which is returned by the second end node for the first message and has a message type of a ninth message type, through the first protocol, or when the first end node generates the fourteenth message, which has a message type of the ninth message type, through the first protocol;
wherein the ninth message type is used to identify that key establishment shared by the first end node and the second end node is complete.
In this embodiment, the message type of the fourteenth message is DONE, the indicator completes end-to-end key establishment, and ends the quantum key distribution process.
In a scenario, if the key transmission direction is from the first end node to the second end node, after the end-to-end key establishment is completed, the second end node may generate a DONE message and send the DONE message to the first end node, and the first end node may receive the DONE message, store the target key, and end the quantum key distribution process.
In another scenario, if the key transmission direction is from the second end node to the first end node, after the end-to-end key establishment is completed, the first end node may generate a DONE message, store the target key, send the DONE message to the second end node, and end the quantum key distribution process.
Thus, quantum key distribution can be realized, and end-to-end keys of the first end node and the second end node are established.
Third embodiment
As shown in fig. 7, the present disclosure provides a quantum key distribution method applied to a second end node of a quantum key distribution network, including the following steps:
step S701: receiving a first message sent by a first end node through a first protocol, wherein the first message is generated by the first end node through a fourth protocol and a second protocol, the first protocol is used for determining a sending path of the message in the process of quantum key distribution performed by the quantum key distribution network, the second protocol is used for processing the message according to the role type of an end node and the message type corresponding to the received message, the fourth protocol is used for initiating a quantum key distribution request, and the first message comprises a first request identifier of the quantum key distribution request initiated by the first end node, a first distribution path, a first node identifier of the second end node and key feature information;
step S702: generating a third message with a message type of a second message type through the first protocol, the second protocol and the fourth protocol based on the first request identifier, the first distribution path, the first node identifier and the key feature information, wherein the second message type is used for identifying a resource reservation request initiated by a receiver of the quantum key distribution request;
step S703: returning the third packet to the first end node through the first protocol;
step S704: and acquiring a target key shared with the first end node through a third protocol, wherein the target key is used for mutual communication between the first end node and the second end node, and the third protocol is used for using quantum bits as an information carrier to distribute keys.
In this embodiment, the steps S701 to S704 are respectively detailed in the first embodiment and the second embodiment, and are not described again here.
In this embodiment, through the design of the quantum key distribution network, the QKDRMP protocol is designed on the second end node, and the consistency of the design of each node protocol in the network is maintained, so that the relay node can schedule and execute the quantum key distribution request initiated by the end node, and thus, a multi-user request can be scheduled for the quantum key distribution network, so as to implement scheduling and processing of multiple requests in the quantum key distribution network, and ensure the best effort delivery of the requests and efficient utilization of network performance, efficiently and safely establish an end-to-end key for different end nodes, and improve the communication security between end nodes.
Optionally, the step S704 includes any one of:
establishing a target key for communicating with an upstream node adjacent to the second end node under the first distribution path through the third protocol, so that the first end node obtains the target key for communicating with the second end node;
receiving second quantum information sent by the first end node through the third protocol under the condition that the first end node is an upstream node adjacent to the second end node in the first distribution path, wherein the second quantum information carries a target key, and the target key is a key generated by the first end node and communicated with the second end node;
receiving a thirteenth message respectively sent by the M relay nodes through the first protocol under the condition that M relay nodes exist between the first end node and the second end node, and performing exclusive OR operation on a third key and a key ciphertext carried by the thirteenth message to obtain the target key, wherein the key ciphertext is obtained by performing exclusive OR operation on two first keys, the two first keys are keys shared by the relay node and an adjacent upstream node and an adjacent downstream node respectively, the third key is a key established by the second end node and the adjacent upstream node through the third protocol, and M is a positive integer.
In this embodiment, a suitable transmission mode may be selected according to an actual scenario of key transmission, so that both the first end node and the second end node may obtain a target key for end-to-end communication between the first end node and the second end node.
Fourth embodiment
As shown in fig. 8, the present disclosure provides a quantum key distribution device 800 applied to a relay node of a quantum key distribution network, including:
a first receiving module 801, configured to receive a first packet sent by a first end node through a first protocol, where the first packet includes a first request identifier of a quantum key distribution request initiated by the first end node, a first distribution path, a first node identifier of a second end node, and key feature information, and the first protocol is used to determine a sending path of the packet in a quantum key distribution process of the quantum key distribution network;
a first generating module 802, configured to generate, based on the first request identifier, the first distribution path, the first node identifier, and the key feature information, a second packet with a message type of a first message type through a second protocol when it is determined that the number of resources required by a quantum key distribution request corresponding to the first request identifier does not exceed the processing capability of the relay node, where the second protocol is used to schedule the received quantum key distribution request, and the first message type is used to identify a sender of the quantum key distribution request to initiate the quantum key distribution request;
a first sending module 803, configured to send the second packet to the second end node through the first protocol;
a first obtaining module 804, configured to, when a third packet that is sent by the second end node for the second packet and has a second message type is received, obtain, based on types of two nodes adjacent to the relay node and the key feature information, first keys between the relay node and the two nodes respectively through the second protocol and/or the third protocol, where the second message type is used to identify a resource reservation request initiated by a receiver of a quantum key distribution request, and the third protocol is used to use a quantum bit as an information carrier to distribute keys;
a second sending module 805, configured to send, through the first protocol, a key ciphertext generated based on the first key to a target end node, where the target end node is the first end node or the second end node, the key ciphertext is used to determine a target key shared by the first end node and the second end node, and the target key is used for mutual communication between the first end node and the second end node.
Optionally, the first obtaining module 804 includes:
a first obtaining submodule, configured to obtain, from a target key pool of N key pools of the relay node that are pre-constructed, a first key that is matched with the key feature information through the second protocol when the types of the two nodes include a first type, where the target key pool is a key pool corresponding to a relay node adjacent to the relay node in the first distribution path, the first type indicating node is a relay node, and N is a positive integer;
and the first establishing submodule is used for establishing a first key with an adjacent end node of the relay node under the first distribution path through the third protocol under the condition that the types of the two nodes include a second type, and the second type indicates that the node is an end node.
Optionally, the first obtaining sub-module includes:
a first generating unit, configured to generate, through the first protocol, a fourth packet with a message type of a third message type, where the third message type is used to identify a resource reservation request initiated by a receiver of a quantum key distribution request, and the fourth packet carries the key feature information and the first request identifier;
the adding unit is used for adding the fourth message to the request queue under the condition that the number of the requests in the request queue which is constructed in advance is determined to be smaller than a first preset threshold value through the second protocol;
a first obtaining unit, configured to obtain, from the request queue, a first key that matches the key feature information from the target key pool when the fourth packet corresponding to the first request identifier is obtained.
Optionally, the method further includes:
a second generating module, configured to generate, through the second protocol, a fifth packet with two message types as a fourth message type when it is determined that the number of requests in the request queue is greater than or equal to the first preset threshold through the second protocol, where the fourth message type is used to identify that a resource reservation request is rejected by the relay node, and the fifth packet carries an error type field, where the error type field is used to indicate a sending direction of the packet;
and a third sending module, configured to send, based on the value of the error type field in the fifth packet, the fifth packet to an end node corresponding to the first request identifier in the quantum key distribution network through the first protocol.
Optionally, the method further includes:
a deleting module, configured to, when a sixth message whose message type is a fourth message type is received and a value of an error type field carried in the sixth message is a first target value, delete a message corresponding to a second request identifier in the request queue if a message corresponding to the second request identifier carried in the sixth message is queried in the request queue;
and the recording module is used for recording a key corresponding to the second request identifier as an invalid key if a message corresponding to the second request identifier carried by the sixth message is not queried in the request queue.
Optionally, the method further includes:
a third generating module, configured to generate, through the second protocol, a seventh packet with a message type of the second message type, where the seventh packet carries an operation type field and the first distribution path, and the operation type field is used to indicate an operation mode for the packet;
a fourth sending module, configured to send, based on the first distribution path, the seventh packet to the first end node through the first protocol when it is determined that the value of the operation type field is a second target value.
Optionally, the method further includes:
a fourth generating module, configured to generate, through the second protocol, an eighth packet with a fifth message type, where the eighth packet includes the first distribution path and the first node identifier, and the fifth message type is used to identify that the relay node successfully adds the resource reservation request to the request queue;
a fifth sending module, configured to send the eighth packet to the second end node through the first protocol based on the first distribution path and the first node identifier.
Optionally, the first obtaining unit is specifically configured to:
under the condition that the fourth message corresponding to the first request identifier is acquired from the request queue, based on the fourth message, generating a ninth message with a message type of the second message type through the second protocol, wherein the ninth message carries an operation type field;
and under the condition that the value of the operation type field is determined to be a third target value, acquiring a first key matched with the key characteristic information from the target key pool through the first protocol.
Optionally, the method further includes:
a first exclusive-or operation module, configured to perform exclusive-or operation on two first keys respectively obtained from the target key pool to obtain the key ciphertext when the types of the two nodes are both the first type;
and a second exclusive-or operation module, configured to, if it is found that the relay node completes key distribution with the two nodes respectively when the types of the two nodes are the first type and the second type, perform exclusive-or operation on the first key obtained from the target key pool and the first key established by the third protocol to obtain the key ciphertext.
Optionally, the second sending module 805 is specifically configured to:
generating a tenth message with a message type of a sixth message type through the first protocol, wherein the tenth message comprises the first distribution path and the key ciphertext, and the sixth message type is used for identifying the key ciphertext generated by the relay node according to the keys of two adjacent nodes;
sending the tenth message to the target end node via the first protocol based on the first distribution path.
Optionally, the method further includes:
the analysis module is used for analyzing the first message through the first protocol;
a fifth generation module, configured to generate, based on the analyzed first request identifier, the first distribution path, the first node identifier of the second end node, and the key feature information, an eleventh packet with a message type of a seventh message type through the first protocol, where the seventh message type is used to identify that a quantum key distribution request is sent;
a sixth generating module, configured to generate, by using the second protocol, a twelfth packet with a message type of a fourth message when it is determined, based on the eleventh packet, that the number of resources corresponding to the key feature information exceeds a maximum capacity of a target key pool of the N key pools of the relay node that are constructed in advance;
a sixth sending module, configured to send, based on the first distribution path, the twelfth packet to the first end node through the first protocol when it is determined that a value of an error type field carried by the twelfth packet is a fourth target value.
Optionally, the method further includes:
a second receiving module, configured to receive a thirteenth message, where a message type sent by the target end node for the key ciphertext is an eighth message type;
and the eighth message type is used for identifying that the target end node confirms to receive the key ciphertext sent by the relay node.
Optionally, the method further includes:
a third receiving module, configured to receive a fourteenth packet, where a message type sent by the target end node for the key ciphertext is a ninth message type, where the fourteenth packet carries the first distribution path, and the ninth message type is used to identify that establishment of a key shared by the first end node and the second end node is completed;
a seventh sending module, configured to send, based on the first distribution path, the fourteenth packet to another end node that shares a key with the target end node through the first protocol.
The quantum key distribution device 800 provided by the present disclosure can implement each process implemented by the first embodiment of the quantum key distribution method, and can achieve the same beneficial effects, and for avoiding repetition, details are not repeated here.
Fifth embodiment
As shown in fig. 9, the present disclosure provides a quantum key distribution device 900 applied to a first end node of a quantum key distribution network, including:
a seventh generating module 901, configured to generate a fifteenth packet through a fourth protocol, where the fourth protocol is used to initiate a quantum key distribution request, and the fifteenth packet includes a first request identifier of the quantum key distribution request initiated by the first end node, a first distribution path, a first node identifier of the second end node, and key feature information;
an eighth generating module 902, configured to generate, based on the first request identifier, the first distribution path, the first node identifier, and the key feature information, a first packet with a message type of a first message type through a second protocol, where the second protocol is used to process a packet according to a role type of an end node and a message type corresponding to the received packet, and the first message type is used to identify a sender of a quantum key distribution request to initiate a quantum key distribution request;
an eighth sending module 903, configured to send the first packet to the second end node through a first protocol, where the first protocol is used to determine a sending path of the packet in a process of quantum key distribution performed by the quantum key distribution network;
a second obtaining module 904, configured to, when a third packet that is sent by the second end node for the first packet and has a message type of a second message type is received, obtain, through a third protocol, a target key shared with the second end node, where the target key is used for mutual communication between the first end node and the second end node, the third protocol is used for performing key distribution by using a quantum bit as an information carrier, and the second message type is used for identifying a resource reservation request initiated by a receiver of a quantum key distribution request.
Optionally, the second obtaining module 904 includes:
a second establishing submodule, configured to establish, through the third protocol, a target key that is in mutual communication with a downstream node adjacent to the first end node in the first distribution path, so that the second end node obtains the target key that is in communication with the first end node;
a first receiving submodule, configured to receive first quantum information sent by the second end node through the third protocol when the second end node is a downstream node adjacent to the first end node in the first distribution path, where the first quantum information carries a target key, and the target key is a key generated by the second end node and communicated with the first end node;
a first xor operation sub-module, configured to, when M relay nodes exist between the first end node and the second end node, receive a thirteenth packet sent by the M relay nodes through the first protocol, and perform xor operation on a second key and a key ciphertext carried by the thirteenth packet to obtain the target key, where the key ciphertext is obtained by performing xor operation on two first keys, the two first keys are keys shared by the relay node and an adjacent upstream node and an adjacent downstream node, the second key is a key established by the first end node and an adjacent downstream node through the third protocol, and M is a positive integer.
Optionally, the first key includes at least one of:
under the condition that the M relay nodes comprise first relay nodes, the first key is obtained by the first relay node from a target key pool in N key pools of the first relay node which is constructed in advance based on the key characteristic information, at least one of the first relay node and the adjacent downstream node is a node of the relay node, the target key pool is a key pool corresponding to the adjacent relay node of the first relay node, and N is a positive integer;
in a case where the M relay nodes include a second relay node, the first key is a key that the second relay node establishes with an adjacent end node through the third protocol, and the second relay node is a node at which at least one of an adjacent upstream node and an adjacent downstream node is an end node.
Optionally, the method further includes:
a first storage module, configured to store, through the second protocol and the fourth protocol, a secret key carried in a sixteenth message when the sixteenth message whose message type is a tenth message type is generated by the first end node through the first protocol;
wherein the tenth message type is used to identify that the first end node established a key with an adjacent downstream node via the third protocol.
Optionally, the sixteenth packet further carries a completion field, where the completion field is used to indicate whether establishment of a key shared by the first end node and the second end node is completed, and the apparatus further includes:
a first setting module, configured to set a value of the completion field to a fifth target value when the first end node and the second end node are directly connected, where the fifth target value indicates that establishment of a key shared by the first end node and the second end node is completed;
a second setting module, configured to set a value of a completion field to a sixth target value when the first end node and the second end node are not directly connected, where the sixth target value indicates that establishment of a key shared by the first end node and the second end node is not completed.
Optionally, the method further includes:
a second storage module, configured to store the target key through the second protocol and the fourth protocol when a fourteenth packet, of which a message type is a ninth message type and which is returned by the second end node for the first packet is received through the first protocol, or the fourteenth packet, of which a message type is a ninth message type and which is generated by the first end node through the first protocol, is received;
wherein the ninth message type is used to identify that the key establishment shared by the first end node and the second end node is complete.
The quantum key distribution device 900 provided by the present disclosure can implement each process implemented by the second embodiment of the quantum key distribution method, and can achieve the same beneficial effects, and for avoiding repetition, details are not repeated here.
Sixth embodiment
As shown in fig. 10, the present disclosure provides a quantum key distribution device 1000 applied to a second end node of a quantum key distribution network, including:
a fourth receiving module 1001, configured to receive a first packet sent by a first end node through a first protocol, where the first packet is generated by the first end node through a fourth protocol and a second protocol, the first protocol is used to determine a sending path of the packet in a process of quantum key distribution performed by the quantum key distribution network, the second protocol is used to process the packet according to a role type of an end node and a message type corresponding to the received packet, the fourth protocol is used to initiate a quantum key distribution request, and the first packet includes a first request identifier of the quantum key distribution request initiated by the first end node, a first distribution path, a first node identifier of the second end node, and key feature information;
a ninth generating module 1002, configured to generate, based on the first request identifier, the first distribution path, the first node identifier, and the key feature information, a third packet with a message type of a second message type through the first protocol, the second protocol, and the fourth protocol, where the second message type is used to identify a resource reservation request initiated by a receiver of a quantum key distribution request;
a ninth sending module 1003, configured to send the third packet to the first end node through the first protocol;
a third obtaining module 1004, configured to obtain, through a third protocol, a target key shared with the first end node, where the target key is used for mutual communication between the first end node and the second end node, and the third protocol is used for key distribution using a quantum bit as an information carrier.
Optionally, the third obtaining module 1004 includes:
a third establishing submodule, configured to establish, through the third protocol, a target key that is in mutual communication with an upstream node adjacent to the second end node in the first distribution path, so that the first end node obtains the target key that is in communication with the second end node;
a second receiving submodule, configured to receive second quantum information sent by the first end node through the third protocol when the first end node is an upstream node adjacent to the second end node in the first distribution path, where the second quantum information carries a target key, and the target key is a key generated by the first end node and communicated with the second end node;
a second exclusive-or operation sub-module, configured to receive, when M relay nodes exist between the first end node and the second end node, thirteenth packets sent by the M relay nodes through the first protocol, and perform exclusive-or operation on a third key and a key ciphertext carried by the thirteenth packet to obtain the target key, where the key ciphertext is obtained by performing exclusive-or operation on two first keys, the two first keys are keys shared by the relay node and an adjacent upstream node and an adjacent downstream node, the third key is a key established by the second end node and the adjacent upstream node through the third protocol, and M is a positive integer.
The quantum key distribution device 1000 provided by the present disclosure can implement each process implemented by the third embodiment of the quantum key distribution method, and can achieve the same beneficial effects, and for avoiding repetition, details are not repeated here.
In the technical scheme of the disclosure, the collection, storage, use, processing, transmission, provision, disclosure and other processing of the personal information of the related user are all in accordance with the regulations of related laws and regulations and do not violate the good customs of the public order.
The present disclosure also provides an electronic device, a readable storage medium, and a computer program product according to embodiments of the present disclosure.
FIG. 11 shows a schematic block diagram of an example electronic device that may be used to implement embodiments of the present disclosure. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be examples only, and are not meant to limit implementations of the disclosure described and/or claimed herein.
As shown in fig. 11, the device 1100 comprises a computing unit 1101, which may perform various appropriate actions and processes according to a computer program stored in a Read Only Memory (ROM) 1102 or a computer program loaded from a storage unit 1108 into a Random Access Memory (RAM) 1103. In the RAM 1103, various programs and data necessary for the operation of the device 1100 may also be stored. The calculation unit 1101, the ROM 1102, and the RAM 1103 are connected to each other by a bus 1104. An input/output (I/O) interface 1105 is also connected to bus 1104.
A number of components in device 1100 connect to I/O interface 1105, including: an input unit 1106 such as a keyboard, a mouse, and the like; an output unit 1107 such as various types of displays, speakers, and the like; a storage unit 1108 such as a magnetic disk, optical disk, or the like; and a communication unit 1109 such as a network card, a modem, a wireless communication transceiver, and the like. The communication unit 1109 allows the device 1100 to exchange information/data with other devices through a computer network such as the internet and/or various telecommunication networks.
The computing unit 1101 can be a variety of general purpose and/or special purpose processing components having processing and computing capabilities. Some examples of the computing unit 1101 include, but are not limited to, a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), various dedicated Artificial Intelligence (AI) computing chips, various computing units running machine learning model algorithms, a Digital Signal Processor (DSP), and any suitable processor, controller, microcontroller, and the like. The calculation unit 1101 performs the respective methods and processes described above, such as the quantum key distribution method. For example, in some embodiments, the quantum key distribution method may be implemented as a computer software program tangibly embodied in a machine-readable medium, such as storage unit 1108. In some embodiments, part or all of the computer program may be loaded and/or installed onto device 1100 via ROM 1102 and/or communication unit 1109. When the computer program is loaded into RAM 1103 and executed by computing unit 1101, one or more steps of the quantum key distribution method described above may be performed. Alternatively, in other embodiments, the computing unit 1101 may be configured to perform the quantum key distribution method by any other suitable means (e.g., by means of firmware).
Various implementations of the systems and techniques described here above may be implemented in digital electronic circuitry, integrated circuitry, field Programmable Gate Arrays (FPGAs), application Specific Integrated Circuits (ASICs), application Specific Standard Products (ASSPs), system on a chip (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include: implemented in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, receiving data and instructions from, and transmitting data and instructions to, a storage system, at least one input device, and at least one output device.
Program code for implementing the methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the processor or controller, cause the functions/operations specified in the flowchart and/or block diagram to be performed. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.
In the context of this disclosure, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to a user; and a keyboard and a pointing device (e.g., a mouse or a trackball) by which a user can provide input to the computer. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic, speech, or tactile input.
The systems and techniques described here can be implemented in a computing system that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local Area Networks (LANs), wide Area Networks (WANs), and the Internet.
The computer system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The server may be a cloud server, a server of a distributed system, or a server combining a blockchain.
It should be understood that various forms of the flows shown above, reordering, adding or deleting steps, may be used. For example, the steps described in the present disclosure may be executed in parallel or sequentially or in different orders, and are not limited herein as long as the desired results of the technical solutions disclosed in the present disclosure can be achieved.
The above detailed description should not be construed as limiting the scope of the disclosure. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may be made in accordance with design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present disclosure should be included in the scope of protection of the present disclosure.

Claims (45)

1.A quantum key distribution method is applied to a relay node of a quantum key distribution network, and comprises the following steps:
receiving a first message sent by a first end node through a first protocol, wherein the first message comprises a first request identifier of a quantum key distribution request initiated by the first end node, a first distribution path, a first node identifier of a second end node and key feature information, and the first protocol is used for determining a sending path of the message in the process of quantum key distribution performed by the quantum key distribution network;
under the condition that the number of resources required by a quantum key distribution request corresponding to the first request identifier is determined not to exceed the processing capacity of the relay node, generating a second message with a message type of a first message type through a second protocol based on the first request identifier, the first distribution path, the first node identifier and the key feature information, and sending the second message to the second end node through the first protocol, wherein the second protocol is used for scheduling the received quantum key distribution request, and the first message type is used for identifying that a sender of the quantum key distribution request initiates the quantum key distribution request;
under the condition that a third message of which the message type is the second message type is received, which is sent by the second end node for the second message, based on the types of two nodes adjacent to the relay node and the key feature information, acquiring first keys between the relay node and the two nodes respectively through the second protocol and/or the third protocol, wherein the second message type is used for identifying a resource reservation request initiated by a receiver of a quantum key distribution request, and the third protocol is used for using quantum bits as an information carrier to distribute keys;
and sending a key ciphertext generated based on the first key to a target end node through the first protocol, wherein the target end node is the first end node or the second end node, the key ciphertext is used for determining a target key shared by the first end node and the second end node, and the target key is used for mutual communication between the first end node and the second end node.
2. The method according to claim 1, wherein the obtaining, based on the type of the two nodes adjacent to the relay node and the key feature information, a first key between the relay node and each of the two nodes through the second protocol and/or a third protocol includes at least one of:
under the condition that the types of the two nodes comprise a first type, acquiring a first key matched with the key feature information from a target key pool of N key pools of the pre-constructed relay node through the second protocol, wherein the target key pool is a key pool corresponding to an adjacent relay node of the relay node under the first distribution path, the first type indication node is the relay node, and N is a positive integer;
and under the condition that the types of the two nodes comprise a second type, establishing a first key with an adjacent end node of the relay node under the first distribution path through the third protocol, wherein the second type indicates that the node is an end node.
3. The method according to claim 2, wherein the obtaining, by the second protocol, a first key matching the key feature information from a target key pool of N key pools of the relay node that are pre-constructed comprises:
generating a fourth message with a message type of a third message type through the first protocol, wherein the third message type is used for identifying a resource reservation request initiated by a receiver of a quantum key distribution request, and the fourth message carries the key characteristic information and the first request identification;
under the condition that the number of the requests in the pre-constructed request queue is determined to be smaller than a first preset threshold value through the second protocol, adding the fourth message into the request queue;
and under the condition that the fourth message corresponding to the first request identifier is obtained from the request queue, obtaining a first key matched with the key feature information from the target key pool.
4. The method of claim 3, further comprising:
under the condition that the number of the requests in the request queue is determined to be greater than or equal to the first preset threshold value through the second protocol, generating a fifth message with two message types as a fourth message type through the second protocol, wherein the fourth message type is used for identifying that a resource reservation request is rejected by the relay node, the fifth message carries an error type field, and the error type field is used for indicating the sending direction of the message;
and respectively sending the fifth message to an end node corresponding to the first request identifier in the quantum key distribution network through the first protocol based on the value of the error type field in the fifth message.
5. The method of claim 4, further comprising:
under the condition that a sixth message with a fourth message type is received and the value of an error type field carried by the sixth message is a first target value, if a message corresponding to a second request identifier carried by the sixth message is inquired in the request queue, deleting the message corresponding to the second request identifier in the request queue;
if the message corresponding to the second request identifier carried by the sixth message is not queried in the request queue, recording the key corresponding to the second request identifier as an invalid key.
6. The method of claim 3, after the adding the fourth packet to the request queue, further comprising:
generating a seventh message with a message type of the second message type through the second protocol, where the seventh message carries an operation type field and the first distribution path, and the operation type field is used to indicate an operation mode for the message;
and sending the seventh packet to the first end node through the first protocol based on the first distribution path under the condition that the value of the operation type field is determined to be a second target value.
7. The method of claim 3, after the adding the fourth packet to the request queue, further comprising:
generating an eighth message with a message type of a fifth message type through the second protocol, where the eighth message includes the first distribution path and the first node identifier, and the fifth message type is used to identify that the relay node successfully adds the resource reservation request to the request queue;
and sending the eighth packet to the second end node through the first protocol based on the first distribution path and the first node identifier.
8. The method according to claim 3, wherein the obtaining a first key matching the key feature information from the target key pool in the case of obtaining the fourth packet corresponding to the first request identifier from the request queue includes:
under the condition that the fourth message corresponding to the first request identifier is acquired from the request queue, based on the fourth message, generating a ninth message with a message type of the second message type through the second protocol, wherein the ninth message carries an operation type field;
and under the condition that the value of the operation type field is determined to be a third target value, acquiring a first key matched with the key characteristic information from the target key pool through the first protocol.
9. The method of claim 8, further comprising at least one of the following after obtaining the first key matching the key feature information from the pool of target keys via the first protocol:
performing exclusive-or operation on two first keys respectively obtained from the target key pool under the condition that the types of the two nodes are the first type to obtain the key ciphertext;
and under the condition that the types of the two nodes are the first type and the second type respectively, if the relay node and the two nodes finish key distribution respectively after inquiry, performing exclusive or operation on a first key acquired from the target key pool and a first key established through the third protocol to obtain the key ciphertext.
10. The method of claim 1, wherein said transmitting, via said first protocol, a key cipher generated based on said first key to a target end node comprises:
generating a tenth message with a message type of a sixth message type through the first protocol, wherein the tenth message comprises the first distribution path and the key ciphertext, and the sixth message type is used for identifying the key ciphertext generated by the relay node according to the keys of two adjacent nodes;
sending the tenth message to the target end node via the first protocol based on the first distribution path.
11. The method of claim 1, further comprising:
analyzing the first message through the first protocol;
generating an eleventh message with a message type of a seventh message type through the first protocol based on the analyzed first request identifier, the analyzed first distribution path, the analyzed first node identifier of the second end node, and the analyzed key feature information, wherein the seventh message type is used for identifying and sending out a quantum key distribution request;
generating a twelfth message with a message type of a fourth message type through the second protocol under the condition that the number of resources corresponding to the key feature information is determined to exceed the maximum capacity of a target key pool in the N key pools of the relay node, which are constructed in advance, based on the eleventh message;
and under the condition that the value of the error type field carried by the twelfth message is determined to be a fourth target value, sending the twelfth message to the first end node through the first protocol based on the first distribution path.
12. The method of claim 1, further comprising, after sending, via the first protocol, a key cipher text generated based on the first key to a target end node:
receiving a thirteenth message which is sent by the target end node aiming at the key ciphertext and has an eighth message type;
and the eighth message type is used for identifying that the target end node confirms to receive the key ciphertext sent by the relay node.
13. The method of claim 1, further comprising, after sending, via the first protocol, a key cipher text generated based on the first key to a target end node:
receiving a fourteenth message, which is sent by the target end node for the key ciphertext and has a message type of a ninth message type, where the fourteenth message carries the first distribution path, and the ninth message type is used to identify that establishment of a key shared by the first end node and the second end node is completed;
and sending the fourteenth message to the other end node sharing the key with the target end node through the first protocol based on the first distribution path.
14. A quantum key distribution method is applied to a first end node of a quantum key distribution network, and comprises the following steps:
generating a fifteenth message through a fourth protocol, where the fourth protocol is used to initiate a quantum key distribution request, and the fifteenth message includes a first request identifier of the quantum key distribution request initiated by the first end node, a first distribution path, a first node identifier of a second end node, and key feature information;
generating a first message with a message type of a first message type through a second protocol based on the first request identifier, the first distribution path, the first node identifier and the key feature information, wherein the second protocol is used for processing the message according to the role type of the end node and the message type corresponding to the received message, and the first message type is used for identifying that a sender of the quantum key distribution request initiates the quantum key distribution request;
sending the first message to the second end node through a first protocol, wherein the first protocol is used for determining a sending path of the message in the process of quantum key distribution of the quantum key distribution network;
and under the condition that a third message, which is sent by the second end node aiming at the first message and has a second message type, is received, acquiring a target key shared with the second end node through a third protocol, wherein the target key is used for mutual communication between the first end node and the second end node, the third protocol is used for using quantum bits as an information carrier to distribute keys, and the second message type is used for identifying a resource reservation request initiated by a receiver of a quantum key distribution request.
15. The method of claim 14, wherein the obtaining a target key shared with the second end node via a third protocol comprises any one of:
establishing a target key for mutual communication with a downstream node adjacent to the first end node under the first distribution path through the third protocol, so that the second end node obtains the target key for communication with the first end node;
receiving first quantum information sent by the second end node through the third protocol under the condition that the second end node is a downstream node adjacent to the first end node in the first distribution path, wherein the first quantum information carries a target key, and the target key is a key which is generated by the second end node and is communicated with the first end node;
receiving thirteenth messages respectively sent by the M relay nodes through the first protocol under the condition that M relay nodes exist between the first end node and the second end node, and performing exclusive-or operation on a second key and a key ciphertext carried by the thirteenth messages to obtain the target key, wherein the key ciphertext is obtained by performing exclusive-or operation on two first keys, the two first keys are keys shared by the relay nodes and adjacent upstream nodes and adjacent downstream nodes respectively, the second key is a key established by the first end node and the adjacent downstream nodes through the third protocol, and M is a positive integer.
16. The method of claim 15, wherein the first key comprises at least one of:
under the condition that the M relay nodes comprise first relay nodes, the first key is obtained by the first relay node from a target key pool in N key pools of the first relay node which is constructed in advance based on the key characteristic information, at least one of the first relay node and the adjacent downstream node is a node of the relay node, the target key pool is a key pool corresponding to the adjacent relay node of the first relay node, and N is a positive integer;
in a case where the M relay nodes include a second relay node, the first key is a key that the second relay node establishes with an adjacent end node through the third protocol, and the second relay node is a node at which at least one of an adjacent upstream node and an adjacent downstream node is an end node.
17. The method of claim 14, after obtaining the target key shared with the second end node via the third protocol, further comprising:
under the condition that the first end node generates a sixteenth message with a message type of a tenth message type through the first protocol, storing a secret key carried by the sixteenth message through the second protocol and a fourth protocol;
wherein the tenth message type is used to identify that the first end node established a key with an adjacent downstream node via the third protocol.
18. The method according to claim 17, wherein the sixteenth packet further carries a completion field, and the completion field is used to indicate whether establishment of the key shared by the first end node and the second end node is completed, and the method further comprises:
setting a value of the completion field to a fifth target value indicating completion of establishment of a key shared by the first end node and the second end node, if the first end node and the second end node are directly connected;
setting a value of a completion field to a sixth target value indicating that establishment of a key shared by the first end node and the second end node is not complete, if the first end node and the second end node are not directly connected.
19. The method of claim 14, after obtaining the target key shared with the second end node via the third protocol, further comprising:
storing the target key through the second protocol and the fourth protocol when receiving a fourteenth message, which is returned by the second end node for the first message and has a message type of a ninth message type, through the first protocol, or when the first end node generates the fourteenth message, which has a message type of the ninth message type, through the first protocol;
wherein the ninth message type is used to identify that the key establishment shared by the first end node and the second end node is complete.
20. A quantum key distribution method is applied to a second end node of a quantum key distribution network, and comprises the following steps:
receiving a first message sent by a first end node through a first protocol, wherein the first message is generated by the first end node through a fourth protocol and a second protocol, the first protocol is used for determining a sending path of the message in the process of quantum key distribution performed by the quantum key distribution network, the second protocol is used for processing the message according to the role type of an end node and the message type corresponding to the received message, the fourth protocol is used for initiating a quantum key distribution request, and the first message comprises a first request identifier of the quantum key distribution request initiated by the first end node, a first distribution path, a first node identifier of the second end node and key feature information;
generating a third message with a message type of a second message type through the first protocol, the second protocol and the fourth protocol based on the first request identifier, the first distribution path, the first node identifier and the key feature information, wherein the second message type is used for identifying a resource reservation request initiated by a receiver of a quantum key distribution request;
and returning the third message to the first end node through the first protocol, and acquiring a target key shared with the first end node through a third protocol, wherein the target key is used for mutual communication between the first end node and the second end node, and the third protocol is used for key distribution by using a quantum bit as an information carrier.
21. The method of claim 20, wherein the obtaining a target key shared with the first end node via a third protocol comprises any one of:
establishing a target key for communicating with an upstream node adjacent to the second end node under the first distribution path through the third protocol, so that the first end node obtains the target key for communicating with the second end node;
receiving second quantum information sent by the first end node through the third protocol under the condition that the first end node is an upstream node adjacent to the second end node in the first distribution path, wherein the second quantum information carries a target key, and the target key is a key which is generated by the first end node and is communicated with the second end node;
receiving thirteenth messages respectively sent by the M relay nodes through the first protocol under the condition that M relay nodes exist between the first end node and the second end node, and performing exclusive-or operation on a third key and a key ciphertext carried by the thirteenth messages to obtain the target key, wherein the key ciphertext is obtained by performing exclusive-or operation on two first keys, the two first keys are keys shared by the relay nodes and adjacent upstream nodes and adjacent downstream nodes respectively, the third key is a key established by the second end node and the adjacent upstream nodes through the third protocol, and M is a positive integer.
22. A quantum key distribution device is applied to a relay node of a quantum key distribution network, and comprises:
a first receiving module, configured to receive, through a first protocol, a first packet sent by a first end node, where the first packet includes a first request identifier of a quantum key distribution request initiated by the first end node, a first distribution path, a first node identifier of a second end node, and key feature information, and the first protocol is used to determine a sending path of the packet in a quantum key distribution process of the quantum key distribution network;
a first generating module, configured to generate, based on the first request identifier, the first distribution path, the first node identifier, and the key feature information, a second packet with a message type of a first message type through a second protocol when it is determined that the number of resources required by a quantum key distribution request corresponding to the first request identifier does not exceed the processing capability of the relay node, where the second protocol is used to schedule the received quantum key distribution request, and the first message type is used to identify a sender of the quantum key distribution request to initiate the quantum key distribution request;
a first sending module, configured to send the second packet to the second end node through the first protocol;
a first obtaining module, configured to, when a third packet that is sent by the second end node for the second packet and has a message type of a second message type is received, obtain, through the second protocol and/or a third protocol, first keys between the relay node and the two nodes, respectively, based on types of the two nodes adjacent to the relay node and the key feature information, where the second message type is used to identify a resource reservation request initiated by a receiver of a quantum key distribution request, and the third protocol is used to distribute keys using quantum bits as an information carrier;
a second sending module, configured to send, through the first protocol, a key ciphertext generated based on the first key to a target end node, where the target end node is the first end node or the second end node, the key ciphertext is used to determine a target key shared by the first end node and the second end node, and the target key is used for mutual communication between the first end node and the second end node.
23. The apparatus of claim 22, wherein the first obtaining means comprises:
a first obtaining submodule, configured to obtain, from a target key pool of N key pools of the relay node that are pre-constructed, a first key that is matched with the key feature information through the second protocol when the types of the two nodes include a first type, where the target key pool is a key pool corresponding to a relay node adjacent to the relay node in the first distribution path, the first type indicating node is a relay node, and N is a positive integer;
and the first establishing submodule is used for establishing a first key with an adjacent end node of the relay node under the first distribution path through the third protocol under the condition that the types of the two nodes include a second type, and the second type indicates that the node is an end node.
24. The apparatus of claim 23, wherein the first acquisition submodule comprises:
a first generating unit, configured to generate, through the first protocol, a fourth packet with a message type being a third message type, where the third message type is used to identify a resource reservation request initiated by a receiver of a quantum key distribution request, and the fourth packet carries the key feature information and the first request identifier;
the adding unit is used for adding the fourth message to the request queue under the condition that the number of the requests in the request queue which is constructed in advance is determined to be smaller than a first preset threshold value through the second protocol;
a first obtaining unit, configured to obtain, from the request queue, a first key that matches the key feature information from the target key pool when the fourth packet corresponding to the first request identifier is obtained.
25. The apparatus of claim 24, further comprising:
a second generating module, configured to generate, through the second protocol, a fifth packet with two message types as a fourth message type when it is determined that the number of requests in the request queue is greater than or equal to the first preset threshold through the second protocol, where the fourth message type is used to identify that a resource reservation request is rejected by the relay node, and the fifth packet carries an error type field, where the error type field is used to indicate a sending direction of the packet;
and a third sending module, configured to send, based on the value of the error type field in the fifth packet, the fifth packet to an end node corresponding to the first request identifier in the quantum key distribution network through the first protocol.
26. The apparatus of claim 25, further comprising:
a deleting module, configured to, when a sixth message whose message type is a fourth message type is received and a value of an error type field carried in the sixth message is a first target value, delete a message corresponding to a second request identifier in the request queue if a message corresponding to the second request identifier carried in the sixth message is queried in the request queue;
and the recording module is used for recording a key corresponding to the second request identifier as an invalid key if a message corresponding to the second request identifier carried by the sixth message is not queried in the request queue.
27. The apparatus of claim 24, further comprising:
a third generating module, configured to generate, through the second protocol, a seventh packet with a message type of the second message type, where the seventh packet carries an operation type field and the first distribution path, and the operation type field is used to indicate an operation mode for the packet;
a fourth sending module, configured to send the seventh packet to the first end node through the first protocol based on the first distribution path when it is determined that the value of the operation type field is a second target value.
28. The apparatus of claim 24, further comprising:
a fourth generating module, configured to generate, through the second protocol, an eighth packet with a fifth message type, where the eighth packet includes the first distribution path and the first node identifier, and the fifth message type is used to identify that the relay node successfully adds the resource reservation request to the request queue;
a fifth sending module, configured to send the eighth packet to the second end node through the first protocol based on the first distribution path and the first node identifier.
29. The apparatus according to claim 24, wherein the first obtaining unit is specifically configured to:
generating a ninth message with a message type of the second message type through the second protocol based on the fourth message under the condition that the fourth message corresponding to the first request identifier is acquired from the request queue, wherein the ninth message carries an operation type field;
and under the condition that the value of the operation type field is determined to be a third target value, acquiring a first key matched with the key characteristic information from the target key pool through the first protocol.
30. The apparatus of claim 29, further comprising:
a first exclusive-or operation module, configured to perform exclusive-or operation on two first keys respectively obtained from the target key pool to obtain the key ciphertext when the types of the two nodes are both the first type;
and a second xor operation module, configured to, if it is found that the relay node completes key distribution with the two nodes respectively when the types of the two nodes are the first type and the second type, perform xor operation on a first key obtained from the target key pool and a first key established through the third protocol to obtain the key ciphertext.
31. The apparatus of claim 22, wherein the second sending module is specifically configured to:
generating a tenth message with a message type of a sixth message type through the first protocol, wherein the tenth message comprises the first distribution path and the key ciphertext, and the sixth message type is used for identifying the key ciphertext generated by the relay node according to the keys of two adjacent nodes;
sending the tenth message to the target end node over the first protocol based on the first distribution path.
32. The apparatus of claim 22, further comprising:
the analysis module is used for analyzing the first message through the first protocol;
a fifth generation module, configured to generate, based on the analyzed first request identifier, the first distribution path, the first node identifier of the second end node, and the key feature information, an eleventh packet with a message type of a seventh message type through the first protocol, where the seventh message type is used to identify that a quantum key distribution request is sent;
a sixth generating module, configured to generate, by using the second protocol, a twelfth packet with a message type of a fourth message when it is determined, based on the eleventh packet, that the number of resources corresponding to the key feature information exceeds a maximum capacity of a target key pool of N key pools of the relay node, where the target key pool is pre-constructed;
a sixth sending module, configured to send, based on the first distribution path, the twelfth packet to the first end node through the first protocol when it is determined that a value of an error type field carried by the twelfth packet is a fourth target value.
33. The apparatus of claim 22, further comprising:
a second receiving module, configured to receive a thirteenth packet, of which the message type sent by the target end node for the key ciphertext is an eighth message type;
and the eighth message type is used for identifying that the target end node confirms to receive the key ciphertext sent by the relay node.
34. The apparatus of claim 22, further comprising:
a third receiving module, configured to receive a fourteenth packet, where a message type sent by the target end node for the key ciphertext is a ninth message type, where the fourteenth packet carries the first distribution path, and the ninth message type is used to identify that establishment of a key shared by the first end node and the second end node is completed;
a seventh sending module, configured to send, based on the first distribution path, the fourteenth packet to another end node sharing a key with the target end node through the first protocol.
35. A quantum key distribution device is applied to a first end node of a quantum key distribution network, and comprises:
a seventh generating module, configured to generate a fifteenth packet through a fourth protocol, where the fourth protocol is used to initiate a quantum key distribution request, and the fifteenth packet includes a first request identifier of the quantum key distribution request initiated by the first end node, a first distribution path, a first node identifier of a second end node, and key feature information;
an eighth generating module, configured to generate, based on the first request identifier, the first distribution path, the first node identifier, and the key feature information, a first packet with a message type of a first message type through a second protocol, where the second protocol is used to process a packet according to a role type of an end node and a message type corresponding to the received packet, and the first message type is used to identify a sender of a quantum key distribution request to initiate a quantum key distribution request;
an eighth sending module, configured to send the first packet to the second end node through a first protocol, where the first protocol is used to determine a sending path of the packet in a process of quantum key distribution performed by the quantum key distribution network;
a second obtaining module, configured to, when a third packet that is sent by the second end node for the first packet and has a second message type is received, obtain, through a third protocol, a target key shared with the second end node, where the target key is used for mutual communication between the first end node and the second end node, the third protocol is used for performing key distribution using a quantum bit as an information carrier, and the second message type is used for identifying a resource reservation request initiated by a receiver of a quantum key distribution request.
36. The apparatus of claim 35, wherein the second obtaining means comprises:
a second establishing submodule, configured to establish, through the third protocol, a target key that is in mutual communication with a downstream node adjacent to the first end node in the first distribution path, so that the second end node obtains the target key that is in communication with the first end node;
a first receiving submodule, configured to receive first quantum information sent by the second end node through the third protocol when the second end node is a downstream node adjacent to the first end node in the first distribution path, where the first quantum information carries a target key, and the target key is a key generated by the second end node and communicated with the first end node;
a first exclusive-or operation sub-module, configured to receive, when M relay nodes exist between the first end node and the second end node, thirteenth packets sent by the M relay nodes through the first protocol, and perform exclusive-or operation on a second key and a key ciphertext carried by the thirteenth packet to obtain the target key, where the key ciphertext is obtained by performing exclusive-or operation on two first keys, the two first keys are keys shared by the relay node and an adjacent upstream node and an adjacent downstream node, the second key is a key established by the first end node and the adjacent downstream node through the third protocol, and M is a positive integer.
37. The apparatus of claim 36, wherein the first key comprises at least one of:
under the condition that the M relay nodes comprise first relay nodes, the first key is obtained by the first relay node from a target key pool in N key pools of the first relay node which is constructed in advance based on the key characteristic information, at least one of the first relay node and the adjacent downstream node is a node of the relay node, the target key pool is a key pool corresponding to the adjacent relay node of the first relay node, and N is a positive integer;
in a case where the M relay nodes include a second relay node, the first key is a key that the second relay node establishes with a neighboring end node through the third protocol, the second relay node being a node of which at least one of a neighboring upstream node and a neighboring downstream node is an end node.
38. The apparatus of claim 35, further comprising:
a first storage module, configured to store, by using the second protocol and a fourth protocol, a key carried in a sixteenth message when the first end node generates the sixteenth message whose message type is a tenth message type through the first protocol;
wherein the tenth message type is used to identify that the first end node established a key with an adjacent downstream node via the third protocol.
39. The apparatus according to claim 38, wherein the sixteenth packet further carries a completion field, and the completion field is used to indicate whether establishment of the key shared by the first end node and the second end node is completed, the apparatus further comprising:
a first setting module, configured to set a value of the completion field to a fifth target value when the first end node and the second end node are directly connected, where the fifth target value indicates that establishment of a key shared by the first end node and the second end node is completed;
a second setting module, configured to set a value of a completion field to a sixth target value when the first end node and the second end node are not directly connected, where the sixth target value indicates that establishment of a key shared by the first end node and the second end node is not completed.
40. The apparatus of claim 35, further comprising:
a second storage module, configured to store the target key through the second protocol and the fourth protocol when a fourteenth packet, of which a message type is a ninth message type and which is returned by the second end node for the first packet is received through the first protocol, or the fourteenth packet, of which a message type is a ninth message type and which is generated by the first end node through the first protocol, is received;
wherein the ninth message type is used to identify that key establishment shared by the first end node and the second end node is complete.
41. A quantum key distribution device is applied to a second end node of a quantum key distribution network, and comprises:
a fourth receiving module, configured to receive a first packet sent by a first end node through a first protocol, where the first packet is generated by the first end node through a fourth protocol and a second protocol, the first protocol is used to determine a sending path of the packet in a process of quantum key distribution performed by the quantum key distribution network, the second protocol is used to process the packet according to a role type of an end node and a message type corresponding to the received packet, the fourth protocol is used to initiate a quantum key distribution request, and the first packet includes a first request identifier of the quantum key distribution request initiated by the first end node, a first distribution path, a first node identifier of the second end node, and key feature information;
a ninth generating module, configured to generate, based on the first request identifier, the first distribution path, the first node identifier, and the key feature information, a third packet with a second message type through the first protocol, the second protocol, and the fourth protocol, where the second message type is used to identify a resource reservation request initiated by a receiver of a quantum key distribution request;
a ninth sending module, configured to send the third packet to the first end node through the first protocol;
a third obtaining module, configured to obtain, through a third protocol, a target key shared by the first end node, where the target key is used for mutual communication between the first end node and the second end node, and the third protocol is used for performing key distribution by using a quantum bit as an information carrier.
42. The apparatus of claim 41, wherein the third obtaining means comprises:
a third establishing submodule, configured to establish, through the third protocol, a target key that is in mutual communication with an upstream node adjacent to the second end node in the first distribution path, so that the first end node obtains the target key that is in communication with the second end node;
a second receiving submodule, configured to receive second quantum information sent by the first end node through the third protocol when the first end node is an upstream node adjacent to the second end node in the first distribution path, where the second quantum information carries a target key, and the target key is a key generated by the first end node and communicated with the second end node;
a second exclusive-or operation sub-module, configured to receive, when M relay nodes exist between the first end node and the second end node, thirteenth packets sent by the M relay nodes through the first protocol, and perform exclusive-or operation on a third key and a key ciphertext carried by the thirteenth packet to obtain the target key, where the key ciphertext is obtained by performing exclusive-or operation on two first keys, the two first keys are keys shared by the relay node and an adjacent upstream node and an adjacent downstream node, the third key is a key established by the second end node and the adjacent upstream node through the third protocol, and M is a positive integer.
43. An electronic device, comprising:
at least one processor; and
a memory communicatively coupled to the at least one processor; wherein the content of the first and second substances,
the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-13, or to perform the method of any one of claims 14-19, or to perform the method of any one of claims 20-21.
44. A non-transitory computer readable storage medium having stored thereon computer instructions for causing a computer to perform the method of any one of claims 1-13, or to perform the method of any one of claims 14-19, or to perform the method of any one of claims 20-21.
45. A computer program product comprising a computer program which, when executed by a processor, implements the method according to any one of claims 1-13, or implements the method according to any one of claims 14-19, or implements the method according to any one of claims 20-21.
CN202211486216.4A 2022-11-24 2022-11-24 Quantum key distribution method and device and electronic equipment Active CN115865334B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211486216.4A CN115865334B (en) 2022-11-24 2022-11-24 Quantum key distribution method and device and electronic equipment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211486216.4A CN115865334B (en) 2022-11-24 2022-11-24 Quantum key distribution method and device and electronic equipment

Publications (2)

Publication Number Publication Date
CN115865334A true CN115865334A (en) 2023-03-28
CN115865334B CN115865334B (en) 2023-07-21

Family

ID=85666147

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211486216.4A Active CN115865334B (en) 2022-11-24 2022-11-24 Quantum key distribution method and device and electronic equipment

Country Status (1)

Country Link
CN (1) CN115865334B (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116319097A (en) * 2023-05-19 2023-06-23 广东广宇科技发展有限公司 Multi-node data transmission method based on quantum encryption

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108023725A (en) * 2016-11-04 2018-05-11 华为技术有限公司 A kind of quantum key trunking method and device based on centralized management with control network
CN109995510A (en) * 2017-12-29 2019-07-09 成都零光量子科技有限公司 A kind of quantum key relay services method
CN110266473A (en) * 2019-04-22 2019-09-20 北京邮电大学 Method, relay node and the distribution method of relay node distribution quantum key
WO2020221085A1 (en) * 2019-04-29 2020-11-05 科大国盾量子技术股份有限公司 Relay method for quantum key, device, system, apparatus, and storage medium
CN112953710A (en) * 2021-01-28 2021-06-11 西安电子科技大学 Wireless/wired hybrid QKD network based on trusted relay
CN113765663A (en) * 2021-09-26 2021-12-07 清华大学 Method and device for strengthening security of quantum key distribution network
CN114124388A (en) * 2022-01-27 2022-03-01 济南量子技术研究院 Gossip protocol synchronization method based on quantum key
CN114362939A (en) * 2020-12-31 2022-04-15 广东国腾量子科技有限公司 Trusted relay quantum secret communication network-based dynamic routing forwarding method, storage device and intelligent terminal
CN114900293A (en) * 2022-05-06 2022-08-12 浙江九州量子信息技术股份有限公司 Quantum key global relay method and system based on scheduling center
CN114978477A (en) * 2021-02-18 2022-08-30 国科量子通信网络有限公司 Open type key distribution network architecture based on physical system
CN115276976A (en) * 2022-07-25 2022-11-01 北京百度网讯科技有限公司 Quantum key distribution method and device and electronic equipment

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108023725A (en) * 2016-11-04 2018-05-11 华为技术有限公司 A kind of quantum key trunking method and device based on centralized management with control network
CN109995510A (en) * 2017-12-29 2019-07-09 成都零光量子科技有限公司 A kind of quantum key relay services method
CN110266473A (en) * 2019-04-22 2019-09-20 北京邮电大学 Method, relay node and the distribution method of relay node distribution quantum key
WO2020221085A1 (en) * 2019-04-29 2020-11-05 科大国盾量子技术股份有限公司 Relay method for quantum key, device, system, apparatus, and storage medium
CN114362939A (en) * 2020-12-31 2022-04-15 广东国腾量子科技有限公司 Trusted relay quantum secret communication network-based dynamic routing forwarding method, storage device and intelligent terminal
CN112953710A (en) * 2021-01-28 2021-06-11 西安电子科技大学 Wireless/wired hybrid QKD network based on trusted relay
CN114978477A (en) * 2021-02-18 2022-08-30 国科量子通信网络有限公司 Open type key distribution network architecture based on physical system
CN113765663A (en) * 2021-09-26 2021-12-07 清华大学 Method and device for strengthening security of quantum key distribution network
CN114124388A (en) * 2022-01-27 2022-03-01 济南量子技术研究院 Gossip protocol synchronization method based on quantum key
CN114900293A (en) * 2022-05-06 2022-08-12 浙江九州量子信息技术股份有限公司 Quantum key global relay method and system based on scheduling center
CN115276976A (en) * 2022-07-25 2022-11-01 北京百度网讯科技有限公司 Quantum key distribution method and device and electronic equipment

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ZHANG QIN;LIU YIKAI;YU XIAOSONG;ZHAO YONGLI;ZHANG JIE, PHOTONICS, vol. 9, no. 4, pages 239 - 239 *
杨超;张红旗;苏锦海;王凯;姜皇勤;曾光;: "基于可信中继的广域量子密钥网络模型研究", 工程科学与技术, no. 02, pages 158 - 166 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116319097A (en) * 2023-05-19 2023-06-23 广东广宇科技发展有限公司 Multi-node data transmission method based on quantum encryption
CN116319097B (en) * 2023-05-19 2023-09-22 广东广宇科技发展有限公司 Multi-node data transmission method based on quantum encryption

Also Published As

Publication number Publication date
CN115865334B (en) 2023-07-21

Similar Documents

Publication Publication Date Title
CN109995510B (en) Quantum key relay service method
CN107040378A (en) A kind of key dispatching system and method based on Multi-user Remote Communication
US10148565B2 (en) OPENFLOW communication method and system, controller, and service gateway
CN115276976B (en) Quantum key distribution method and device and electronic equipment
AU2020377536A1 (en) A system and method for satellite quantum key distribution
CN110741573A (en) Method and system for selectively propagating transactions using network coding in a blockchain network
TWI640177B (en) Data delivery method and system in software defined network
CN101379755A (en) Digital object title authentication
CN102394745A (en) Quality of service realization method applied to quantum key distribution network
CN103650433A (en) Route distributing method, system and controller
CN107147492A (en) A kind of cipher key service System and method for communicated based on multiple terminals
WO2017006361A1 (en) A device within a wireless peer-to-peer network, wireless communication system and control method
WO2023000936A1 (en) Data processing method, function device and readable storage medium
Zhang et al. Fragmentation-aware entanglement routing for quantum networks
CN108964961A (en) A kind of method, apparatus and system of management transmission network slice
CN115865334B (en) Quantum key distribution method and device and electronic equipment
US8055897B2 (en) Digital object title and transmission information
CN113691313A (en) Satellite-ground integrated quantum key link virtualization application service system
EP4060931A1 (en) System and method for optimizing the routing of quantum key distribution (qkd) key material in a network
CN115865332B (en) Request processing method and device and electronic equipment
CN108900584B (en) Data transmission method and system for content distribution network
CN114362939B (en) Dynamic route forwarding method, storage device and intelligent terminal based on trusted relay quantum secret communication network
CN114362938B (en) Quantum communication key management dynamic route generation network architecture and method
CN115865333B (en) Quantum entanglement establishment method and device and electronic equipment
CN106487890A (en) A kind of cross-node communication network requesting method based on XMPP

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant