Method and system for synchronising QKD nodes

Abstract

Methods and systems are disclosed for synchronising a first block of quantum key material in a first QKD node with a second QKD node. The first QKD node and the second QKD node share a quantum key material generator. The method comprises ingesting, by the first QKD node, the first block of quantum key material from the quantum key material generator and storing, by the first QKD node, the first block of quantum key material in association with a first state of a first finite-state machine. The first state of the first finite-state machine may indicate that the first block of quantum key material has not been synchronised. The method further comprises sending, by the first QKD node, a synchronisation request to the second QKD node and associating the first block of quantum key material with a second state of the first finite-state machine. The synchronisation request identifies the first block of quantum key material. The second state of the first finite-state machine may indicate that the first block of quantum key material is in a process of being synchronised. The method further comprises in dependence on a response being received, by the first QKD node, from the second QKD node, associating the first block of quantum key material with an updated state of the first finite-state machine.

Description

[0001] WO40965 / SV-TD

[0002] Method and system for synchronising QKD nodes

[0003] Technical field

[0004] The disclosure relates to synchronisation of quantum key distribution nodes, and in particular, though not exclusively, to methods and systems for synchronising quantum key distribution nodes, and to computer program products enabling computer systems to perform such methods.

[0005] Background

[0006] In a Quantum Key Distribution (QKD) system, QKD key material is created from quantum bits on two remote End Nodes connected by a classical network. This QKD key material should be stored only if it is identical on both End Nodes. This must be the case in all eventualities, including network communication failure between the End Nodes, an End Node functioning unreliably, actions by malicious actors, et cetera. In order to prevent the quantum key from being compromised, the quantum key material itself may not be sent over the classical network. Furthermore, when an End Node delivers QKD key material (or a quantum key based on such QKD key material) to a user — e.g., for use as a key for encrypted communication over the classical network — the End Node must ensure that each bit of the QKD key material is delivered at most once.

[0007] US 10326591 B2 describes a protocol for synchronisation of key blocks based on a time sequence identifier and a hash of the key block. If the synchronisation is successful, the key block and time sequence identifier are stored in a local key pool. Upon reception of a key request, the key block is retrieved from the key pool and validated with a partner system based on the hash of the key block and the time sequence identifier. However, the sending of the hash of the quantum key material poses a potential security risk. Moreover, the described system is not robust against failures due to, e.g., communication failures between the nodes, potentially leading to a waste of quantum key material

[0008] Hence, from the above, it follows that there is a need in the art for a robust and secure system and method for synchronising QKD nodes.

[0009] It is an aim of embodiments in this disclosure to provide a system and method for synchronising QKD nodes that avoids, or at least reduces the drawbacks of the prior art. In a first aspect, embodiments in this disclosure relate to a computer-implemented method for synchronising a first block of quantum key material in a first QKD node with a second QKD node. The first QKD node and the second QKD node share a quantum key material generator. The method comprises ingesting, by the first QKD node, the first block of quantum key material from the quantum key material generator and storing, by the first QKD node, the first block of quantum key material in association with a first state of a first finite- state machine of the first QKD node. The first state of the first finite-state machine may indicate that the first block of quantum key material has not been synchronised. The method further comprises sending, by the first QKD node, a synchronisation request to the second QKD node and associating the first block of quantum key material with a second state of the first finite-state machine. The synchronisation request identifies the first block of quantum key material. The second state of the first finite-state machine may indicate that the first block of quantum key material is in a process of being synchronised. The method further comprises in dependence on a response being received, by the first QKD node, from the second QKD node, associating the first block of quantum key material with an updated state of the first finite-state machine.

[0010] As used herein, two QKD nodes sharing a quantum key material generator means that the two QKD nodes are communicatively connected and configured to generate quantum key material, typically using known hardware and algorithms.

[0011] A finite-state machine is a well-known mathematical model of computation, also known as a finite-state automaton. As used herein, a finite-state machine defines a plurality of states and transitions between states. The transitions may be associated with triggers (also known as inputs or conditions); such triggers cause the transition with which they are associated to occur. The plurality of states is exhaustive, and the states are mutually exclusive; in other words, the system is always in exactly one state of the plurality of states. A finite-state machine cannot go from one state to a next state, if no corresponding transition has been defined; in other words, the defined transitions form an exhaustive list of possible transitions. There can be more than one transition between two states, which may be associated, e.g., with different triggers. A state can also transition to itself (e.g., if a trigger does not alter that state). A finite state machine may be represented by a directed graph.

[0012] The use of a finite-state machine to track the status of the blocks of quantum key material results in a robust framework that allows for retries, e.g., if one of the nodes has processed more of the quantum key material than the other node, in case of network failures, or in case of system failures at one of the nodes.

[0013] Additionally, the use of the finite-state machine allows to continuously maintain the synchronisation of the blocks of quantum key material by comparing the states of the block between the two QKD nodes. For example, due to some internal or system issues or due to a network failure, one QKD node might have a block of quantum key material in the third state (e.g., ‘Committed’), while the corresponding block of quantum key material at the other QKD node may have be in the fourth state (e.g., ‘CommitLost’). This information is synchronised during runtime of the system (e.g., during key generation) resulting in less failures.

[0014] In an embodiment, associating the first block of quantum key material with an updated state of the first finite-state machine comprises at least one of:

[0015] - if and only if the response indicates that the second QKD node stores second block of quantum key material corresponding to the first block of quantum key material, associating the first block of quantum key material with a third state of the first finite-state machine;

[0016] - if the response indicates that the second QKD node does not store the second block of quantum key material corresponding to the first block of quantum key material, associating the first block of quantum key material with the first state of the first finite-state machine or a fourth state of the first finite-state machine;

[0017] - if the response indicates that the second QKD node has lost the second block of quantum key material corresponding to the first block of quantum key material, associating the first block of quantum key material with the fourth state of the first finite-state machine;

[0018] - if no response is received within a predetermined time limit, associating the first block of quantum key material with the first state of the first finite-state machine or the fourth state of the first finite-state machine.

[0019] Herein, the third state of the first finite-state machine may indicate that the first block of quantum key material has been synchronised, and the fourth state of the first finite-state machine may indicate that the synchronisation of the first block of quantum key material has (permanently) failed.

[0020] It has been found that a finite-state machine with these four states strikes a good balance between level of detail and amount of overhead / system complexity. Other embodiments may use fewer, additional, and / or different states.

[0021] Thus, in a specific example, the method may comprise: ingesting, by the first QKD node, the first block of quantum key material from the quantum key material generator; storing, by the first QKD node, the first block of quantum key material in association with a first state of a first finite-state machine of the first QKD node, the first state of the first finite- state machine indicating that the first block of quantum key material has not been synchronised; sending, by the first QKD node, a synchronisation request to the second QKD node, the synchronisation request identifying the first block of quantum key material, and associating the first block of quantum key material with a second state of the first finite-state machine, the second state of the first finite-state machine indicating that the first block of quantum key material is in a process of being synchronised; in reaction to either not receiving by the first QKD node a response from the second QKD node within a predetermined time limit, or receiving by the first QKD node a response from the second QKD node indicating that the second QKD node does not store the second block of quantum key material corresponding to the first block of quantum key material, associating the first block of quantum key material with the first state of the first finite-state machine; and sending, by the first QKD node, a new synchronisation request to the second QKD node, the synchronisation request identifying the first block of quantum key material, and associating the first block of quantum key material with the second state of the first finite-state machine.

[0022] In a further example, the method may comprise: ingesting, by the first QKD node, the first block of quantum key material from the quantum key material generator; storing, by the first QKD node, the first block of quantum key material in association with a first state of a first finite-state machine of the first QKD node, the first state of the first finite-state machine indicating that the first block of quantum key material has not been synchronised; sending, by the first QKD node, a synchronisation request to the second QKD node, the synchronisation request identifying the first block of quantum key material, and associating the first block of quantum key material with a second state of the first finite-state machine, the second state of the first finite-state machine indicating that the first block of quantum key material is in a process of being synchronised; in reaction to either not receiving by the first QKD node a response from the second QKD node within a predetermined time limit, or receiving by the first QKD node a response from the second QKD node indicating that the second QKD node does not store the second block of quantum key material corresponding to the first block of quantum key material, associating the first block of quantum key material with the first state of the first finite-state machine; receiving, by the first QKD node, a further synchronisation request from the second QKD node, the further synchronisation request identifying the first block of quantum key material; determining, by the first QKD node, whether the first QKD node stores the first block of quantum key material; if the first QKD node stores the first block of quantum key material, associating the first block of quantum key material with the second state of the first finite-state machine of the first QKD node; and sending, by the first QKD node, a response to the second QKD node, the response indicating whether the first QKD node stores the first block of quantum key material and, if the first QKD node stores the first block of quantum key material, the response being based on the state of the first finite-state machine of the first QKD node associated with the first block of quantum key material.

[0023] In an embodiment, the synchronisation request comprises metadata based on the first block of quantum key material, e.g., the metadata comprising a first block ID uniquely identifying the first block of quantum key material. Additionally or alternatively, the metadata may comprise a length of the first block of quantum key material. Blocks of quantum key material may have different lengths, that may depend on the particulars of the algorithm(s) used to generate the quantum key material. Including the length of the block allows for using different-sized blocks, and adds an additional check that two blocks to be synchronised are indeed identical to each other. In particular, if the block ID is based on preliminary (raw) quantum key material, including a size of a block of processed (security-enhanced) quantum key material may act as a check that both QKD nodes obtained the same final block from the same input data.

[0024] In an embodiment, the first block ID is based on a hash of the first block of quantum key material or based on a hash of preliminary quantum key material used to generate the first block of quantum key material. A hash of the quantum key material can be implemented more easily, as it only needs the already generated quantum key material. However, using a hash of preliminary quantum key material may increase the security of the synchronisation algorithm, in case the synchronisation message is captured, as in general, no or at least less information on the final quantum key material may be derived from a hash of the preliminary quantum key material (as opposed to from a hash of the final quantum key material).

[0025] In a further aspect, embodiments in this disclosure relate to a computer-implemented method for synchronising a first block of quantum key material in a first QKD node with second block of quantum key material in a second QKD node, the first QKD node and the second QKD node sharing a block of quantum key material generator. The method comprises receiving, by the second QKD node, a synchronisation request from the first QKD node, the synchronisation request identifying the first block of quantum key material; determining, by the second QKD node, whether the second QKD node stores the second block of quantum key material corresponding to the first block of quantum key material and, if the second QKD node stores the second block of quantum key material, associating the second block of quantum key material with an updated state of a first finite-state machine of the second QKD node. The method further comprises sending, by the second QKD node, a response to the first QKD node, the response indicating whether the second QKD node stores the second block of quantum key material and, if the second QKD node stores the second block of quantum key material, the response being based on the state of the first finite-state machine of the second QKD node associated with the second block of quantum key material.

[0026] The correspondence between the first block of quantum key material and the second block of quantum key material may be determined based on information in the synchronisation request (uniquely) identifying the first block of quantum key material. For instance, this information may comprise metadata related to or based on the block of quantum key material and / or related to or based on the preliminary quantum key material from which the block of quantum key material is derived.

[0027] In an embodiment, the sending the response comprises: if and only if the second QKD node does not store the second block of quantum key material corresponding to the first block of quantum key material, then the response indicating that the second QKD node does not store second block of quantum key material corresponding to the first block of quantum key material; else, if and only if the second QKD node determines that the second block of quantum key material is associated with a first state of a first finite-state machine, a second state of a first finite-state machine, or a third state of a first finite-state machine, then the response indicating that the second QKD node stores the second block of quantum key material corresponding to the first block of quantum key material, and associating the second block of quantum key material with the third state of the first finite-state machine; else, if and only if the second QKD node determines that the second block of quantum key material is associated with a fourth state of the first finite-state machine, then the response indicating that the second QKD node has lost the second block of quantum key material corresponding to the first block of quantum key material.

[0028] Herein, the first state of the first finite-state machine may indicating that the second block of quantum key material has not been synchronised, the second state of the first finite- state machine may indicate that the second block of quantum key material is in a process of being synchronised, the third state of the first finite-state machine may indicate that the second block of quantum key material has been synchronised, and the fourth state of the first finite-state machine may indicating that the synchronisation of the second block of quantum key material has (permanently) failed.

[0029] In a specific example, the method may comprise: receiving, by the second QKD node, a synchronisation request from the first QKD node, the synchronisation request identifying the first block of quantum key material; determining, by the second QKD node, that the second QKD node does not store the second block of quantum key material corresponding to the first block of quantum key material; sending, by the second QKD node, a response to the first QKD node, the response indicating that the second QKD node does not store the second block of quantum key material; ingesting, by the second QKD node, the second block of quantum key material from the quantum key material generator; storing, by the second QKD node, the second block of quantum key material in association with a first state of a first finite-state machine of the second QKD node, the first state of the first finite-state machine indicating that the second block of quantum key material has not been synchronised; sending, by the second QKD node, a synchronisation request to the first QKD node, the synchronisation request identifying the second block of quantum key material, and associating the second block of quantum key material with a second state of the first finite- state machine, the second state of the first finite-state machine indicating that the second block of quantum key material is in a process of being synchronised; and in dependence on a response being received, by the second QKD node, from the first QKD node, associating the second block of quantum key material with an updated state of the first finite-state machine. In a further aspect, embodiments in this disclosure relate to a computer-implemented method for synchronising a first quantum key in a first QKD node with a second QKD node. The first QKD node and the second QKD node have access to synchronised blocks of quantum key material, and the first QKD node and the second QKD node are configured to use an identical key generation algorithm. The method comprises receiving, by the first QKD node, a key request; generating, by the first QKD node, the first quantum key using the identical key generation algorithm, based on a first synchronised block of quantum key material; and associating the first quantum key with a first state of a second finite-state machine. The first state of the second finite-state machine may indicate that the first quantum key has not been synchronised. The method further comprises sending, by the first QKD node, a key synchronisation request to the second QKD node, and associating the first quantum key with a second state of a second finite-state machine. The key synchronisation request comprises a key ID identifying the first quantum key and key generation data, which key generation data comprises a first block ID uniquely identifying the first synchronised block of quantum key material. The second state of the second finite-state machine may indicate that the first quantum key is in a process of being synchronised. The method further comprises receiving, by the first QKD node, a response from the second QKD node, the response indicating whether or not the second QKD node successfully generated a second quantum key based on the key generation data. The method further comprises, if and only if the response indicates that the second quantum key was successfully generated, associating the first quantum key with a third state of the second finite-state machine, the third state of the second finite-state machine indicating that the first quantum key has been synchronised; and providing the first quantum key and the key ID.

[0030] Once the quantum key material has been synchronised, identical quantum keys may be generated by the first and second QKD nodes by using (corresponding portions of) the synchronised quantum key material and an identical (deterministic) quantum key generation algorithm.

[0031] The use of a finite-state machine again results in a safe and robust system.

[0032] Typically, once a block of quantum key material, or part thereof, has been used to generate a quantum key, the corresponding block of quantum key material or part thereof is deleted.

[0033] In an embodiment, the key synchronisation request further comprises at least one of: a key length and a key address. This allows to uniquely determine the bits of quantum key material to be used to generate the requested quantum key in a flexible manner. Other embodiments may use, e.g., fixed-length keys. Some embodiments may use each block of quantum key material only once; but by using a key address, several keys may be generated from a single key material block. This saves on quantum key material, making the method more efficient. In an embodiment, the method further comprises, if the response indicates that the generation of the second quantum key by the second QKD node failed, associating the first quantum key with a fourth state of second finite-state machine, the fourth state of the second finite-state machine indicating that synchronisation of the first quantum key failed.

[0034] In some embodiments, if the synchronisation failed, the quantum key may be removed. In some cases, a new quantum key may, at a subsequent point in time, be generated using the same quantum key material. Depending on the particulars of the system, that may result in an identical quantum key. In other embodiments, the failure can be either temporary (in which case a synchronisation may be retried) or permanent (in which case the generated key may be deleted). Further examples are provided below.

[0035] The synchronised blocks of quantum key material may have been synchronised according to one of the methods described above. In such cases, the first synchronised block of quantum key material may be associated with the third state of the first finite-state machine as described.

[0036] In an embodiment, the method further comprises, if the response indicates that the block of quantum key material is not found by the second QKD node or that the block of quantum key material is associated with the fourth state of the first finite-state machine, associating, by the first QKD node, the block of quantum key material with the fourth state of the first finite-state machine and associating, by the first QKD node, the first quantum key with the fourth state of the second finite-state machine.

[0037] If the key synchronisation indicates that the block used by the first QKD node is not in a committed state on the second QKD node (e.g., the block is not found, or marked as lost or otherwise unusable), the corresponding block may be deleted and / or marked as lost.

[0038] In an embodiment, the method may further comprise, if no response is received by the first QKD node from the second QKD node within a predetermined time limit or if a response is received by the first QKD node from the second QKD node indicative of a temporary failure of the second QKD node to generate the quantum key, associating the first quantum key with the first state of the second finite-state machine. The first quantum key being associated with the first state of the second finite-state machine of the first QKD node, a new synchronisation attempt may be undertaken, e.g., by repeating one or more of the synchronisation steps defined above.

[0039] A computer-implemented method for synchronising a first quantum key in a first QKD node with a second QKD node, the first QKD node and the second QKD node having access to synchronised blocks of quantum key material, the first QKD node and the second QKD node being configured to use an identical key generation algorithm, the method comprising: receiving, by the second QKD node, a key synchronisation request from the first QKD node, the key synchronisation request comprising a key ID and key generation data, the key generation data comprising a first block ID uniquely identifying a first synchronised block of quantum key material; if the first synchronised block of quantum key material is not available to the second QKD node, then sending, by the second QKD node, a ‘failed’ response to the first QKD node, the ‘failed’ response indicating that the first synchronised block of quantum key material is not available to the second QKD node; else generating, by the second QKD node, a second quantum key using the identical key generation algorithm, based on the first synchronised block of quantum key material, and associating the second quantum key with the key ID, and associating the second quantum key with a third state of a second finite-state machine, the third state of the second finite-state machine indicating that the second quantum key has been synchronised; and in response to receiving a key request comprising the key ID, providing the second quantum key.

[0040] In a further aspect, embodiments of this disclosure relate to one or more QKD nodes configured to perform one or more of the methods described herein.

[0041] For example, an embodiment relates to a QKD node configured to be communicatively connectable to a further QKD node, the QKD node and the further QKD node sharing a quantum key material generator, the QKD node comprising a processor and a memory, the memory storing computer-readable instructions that, when executed by the processor, configure the QKD node to: ingest a first block of quantum key material from the quantum key material generator; store the first block of quantum key material in association with a first state of a first finite-state machine, the first state of the first finite-state machine indicating that the first block of quantum key material has not been synchronised; send a synchronisation request to the further QKD node, the synchronisation request identifying the first block of quantum key material, and associating the first block of quantum key material with a second state of the first finite-state machine, the second state of the first finite-state machine indicating that the first block of quantum key material is in a process of being synchronised; and in dependence on a response being received by the QKD node from the further QKD node, associate the first block of quantum key material with an updated state of the first finite-state machine.

[0042] An embodiment relates to a QKD node configured to be communicatively connectable to a further QKD node, the QKD node and the further QKD node sharing a quantum key material generator, the QKD node comprising a processor and a memory, the memory storing computer-readable instructions that, when executed by the processor, configure the QKD node to: receive a synchronisation request from the further QKD node, the synchronisation request identifying the first block of quantum key material; determine whether the QKD node stores the second block of quantum key material corresponding to the first block of quantum key material; if the QKD node stores the second block of quantum key material, associate the second block of quantum key material with an updated state of the first finite-state machine; and send a response to the further QKD node, the response indicating whether the QKD node stores the second block of quantum key material and, if the QKD node stores the second block of quantum key material, the response being based on the state of a first finite-state machine associated with the second block of quantum key material.

[0043] An embodiment relates to a QKD node configured to be communicatively connectable to a further QKD node, the QKD node and the further QKD node having access to synchronised blocks of quantum key material, the QKD node and the further QKD node being configured to use an identical key generation algorithm, the QKD node comprising a processor and a memory, the memory storing computer-readable instructions that, when executed by the processor, configure the QKD node to: receive a key request; generate a first quantum key using the identical key generation algorithm, based on a first synchronised block of quantum key material, and associating the first quantum key with a first state of a second finite-state machine, the first state of the second finite-state machine indicating that the first quantum key has not been synchronised; send a key synchronisation request to the further QKD node, the key synchronisation request comprising a key ID identifying the first quantum key and key generation data, the key generation data comprising a first block ID uniquely identifying the first synchronised block of quantum key material, and associate the first quantum key with a second state of the second finite-state machine, the second state of the second finite-state machine indicating that the first quantum key is in a process of being synchronised; receive a response from the further QKD node, the response indicating whether or not the further QKD node successfully generated a second quantum key based on the key generation data; if and only if the response indicates that the second quantum key was successfully generated: associate the first quantum key with a third state of the second finite-state machine, the third state of the second finite-state machine indicating that the first quantum key has been synchronised; and provide the first quantum key and the key ID.

[0044] An embodiment relates to a QKD node configured to be communicatively connectable to a further QKD node, the QKD node and the further QKD node having access to synchronised blocks of quantum key material, the QKD node and the further QKD node being configured to use an identical key generation algorithm, the QKD node comprising a processor and a memory, the memory storing computer-readable instructions that, when executed by the processor, configure the QKD node to: receive a key synchronisation request from the further QKD node, the key synchronisation request comprising a key ID and key generation data, the key generation data comprising a first block ID uniquely identifying a first synchronised block of quantum key material; if the first synchronised block of quantum key material is not available to the second QKD node, then send a ‘failed’ response to the further QKD node, the ‘failed’ response indicating that the first synchronised block of quantum key material is not available to the second QKD node; else generate a second quantum key using the identical key generation algorithm, based on the first synchronised block of quantum key material, and associate the second quantum key with the key ID, and associate the second quantum key with a third state of a second finite-state machine, the third state of the second finite-state machine indicating that the second quantum key has been synchronised; and in response to receiving a key request comprising the key ID, provide the second quantum key.

[0045] One or more of the QKD nodes described above may be further configured to execute relevant method steps as described herein.

[0046] In an aspect, embodiments relate to a QKD system comprising two or more QKD nodes as described above, configured to communicate with each other.

[0047] One aspect of this disclosure relates to a computer, e.g. a QKD node as described herein, comprising a computer-readable storage medium having computer-readable program code embodied therewith, and a processor, preferably a microprocessor, coupled to the computer readable storage medium, wherein responsive to executing the computer readable program code, the processor is configured to perform any of the methods described herein.

[0048] One aspect of this disclosure relates to a computer program or suite of computer programs comprising at least one software code portion or a computer program product storing at least one software code portion, the software code portion, when run on a computer system, e.g. a QKD node as described herein, being configured for executing any of the methods described herein.

[0049] One aspect of this disclosure relates to a non-transitory computer-readable storage medium storing at least one software code portion, the software code portion, when executed or processed by a computer, being configured to perform any of the methods described herein.

[0050] As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system”. Functions described in this disclosure may be implemented as an algorithm executed by a microprocessor of a computer. Furthermore, aspects of the present embodiments may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied, e.g., stored, thereon.

[0051] Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but 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 (a non- exhaustive list) of the computer readable storage medium would include the following: an electrical connection having 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 fibre, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0052] A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

[0053] Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fibre, cable, RF, etc., or any suitable combination of the foregoing. Computer program code for carrying out operations for aspects of the present embodiments may be written in any combination of one or more programming languages, including a functional or an object oriented programming language such as Java(TM), Scala, C++, Python or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on the remote computer, server or virtualized server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0054] Aspects of the present embodiments are described below with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the embodiments. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor, in particular a microprocessor or central processing unit (CPU), or graphics processing unit (GPU), of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer, other programmable data processing apparatus, or other devices create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0055] These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function / act specified in the flowchart and / or block diagram block or blocks.

[0056] The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0057] The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present embodiments. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

[0058] The embodiments will be further illustrated with reference to the attached drawings, which schematically will show embodiments according to the invention. It will be understood that the invention is not in any way restricted to these specific embodiments. Identical reference signs refer to identical, or at least similar elements.

[0059] Brief description of the drawings

[0060] Fig. 1 schematically depicts a QKD node for a quantum key distribution (QKD) system according to an embodiment; Fig. 2 schematically depicts a quantum key distribution system according to an embodiment;

[0061] Fig. 3A and 3B are flowcharts of methods for synchronising a block of quantum key material in a first QKD node with a second QKD node according to embodiments;

[0062] Fig. 4A and 4B are flowcharts of a method for synchronising a quantum key in a first QKD node with a second QKD node according to an embodiment;

[0063] Fig. 5A is a schematic representation of the first finite-state machine according to an embodiment, Fig. 5B is a schematic representation of the second finite-state machine according to an embodiment, and Fig. 5C is a flowchart of a method for synchronising a block of quantum key material according to an embodiment;

[0064] Fig. 6A and 6B are flowcharts of methods for synchronisation of a block of quantum key material according to various embodiments;

[0065] Fig. 7A and 7B are flowcharts of methods for synchronisation of a quantum key according to various embodiments;

[0066] Fig. 8 is a flow diagram showing an example of a method for synchronisation of a block of quantum key material according to an embodiment;

[0067] Fig. 9 is a flow diagram showing an example of a method for synchronisation of a quantum key according to an embodiment; and

[0068] Fig. 10 is a block diagram illustrating an exemplary data processing system that may be used for executing methods and software products described in this disclosure.

[0069] Detailed description

[0070] Fig. 1 schematically depicts a QKD node for a quantum key distribution (QKD) system according to an embodiment. A QKD system typically includes at least two such QKD nodes (also known as end nodes), which may be communicatively connected to each other either directly or indirectly, e.g., via one or more intermediate nodes (not shown here) or via a central node. Such QKD systems comprising a plurality of QKD nodes are well known in the art.

[0071] The QKD node 100 may include a first qubit generating module 110. The qubit generating module may be configured to prepare qubits and send them via an optical fibre 106i to a further QKD node (not shown), e.g., an intermediate node or a second QKD node substantially equal to the depicted QKD node. These optical fibres 106I,2 may be part of a conventional optical fibre communication network.

[0072] The qubit generating module 110 may include an optical controller 112 for controlling a laser system 114, such as a continuous wave laser, to generate coherent optical pulses. In some embodiments, the optical controller 112 may comprise a pulse generating system for generating, each clock cycle, a pulse signal wherein the pulse signal may either include zero, one or two pulses. The optical pulses generated by the laser system may be processed by one or more intensity modulators 116 and / or one or more phase modulators 118. The intensity modulators and / or phase modulators may be controlled, e.g., by the optical controller 112, and / or by pulses generated by the pulse generating system.

[0073] In some embodiments, based on a pulse signal, photonic qubits may be defined using, e.g., time-bin optical modes. The qubits may be transmitted via fibre connection 106i to a communicatively connected further QKD node, intermediate node, or central node. Depending on the implementation, the optical modes transmitted by the qubit generating module may be indistinguishable in all degrees of freedom (spatial, spectral, polarization and temporal).

[0074] In some embodiments, the QKD node may receive an external (optical) clock signal, e.g. from the further QKD node or a central node. This clock signal may be transmitted via the optical fibre 1062to the qubit generating module, which use this high-quality clock signal to both synchronise the qubit generation and to produce a high-quality clock signal for generating the pulses that drive the optical components.

[0075] The QKD system can be, for example, an MDI-QKD design as described by Valivarthi et al., ‘A cost-effective measurement-independent quantum key distribution system for quantum networks’, Quantum Sic. Technol. 2 (2017). However, the embodiments in this application may be advantageously used in any QKD system, such as BB84 protocol based QKD systems, decoy-state QKD systems, Coherent One-Way (COW) QKD systems, and Twin-Field QKD systems.

[0076] The techniques of this disclosure may be implemented in a wide variety of devices or apparatuses, including a wireless handset, an integrated circuit (IC) or a set of ICs (e.g., a chip set). Various components, modules, or units are described in this disclosure to emphasize functional aspects of devices configured to perform the disclosed techniques, but do not necessarily require realization by different hardware units. Rather, as described above, various units may be combined in a codec hardware unit or provided by a collection of interoperative hardware units, including one or more processors as described above, in conjunction with suitable software and / or firmware.

[0077] Thus, the qubit generating module 110 can generate a stream of random digits that at least in principle is equal to a further stream of random digits at the further QKD node. In a typical embodiment, the key material generator provides blocks of raw quantum key material. These blocks of raw quantum key material may be stored in a buffer 124. The QKD Key Material Generator transforms a block of the raw quantum data generated by the qubit generating module into a secure final QKD Key Material block by processing the raw data using a “Post-Processing Pipeline”. The Post-Processing Pipeline passes the raw quantum data, for instance, through the following stages:

[0078] 1. Sifting 2. Parameter Estimation

[0079] 3. Error Correction

[0080] 4. Verification

[0081] 5. Privacy Amplification

[0082] In general, each step processes the raw quantum data into more secure data, typically reducing the amount of data. Thus, the final QKD Key Material block (or “final block” for short) has less bits (but more secure bits) than the raw data. In general, the Postprocessing Pipeline is a deterministic pipeline, so that identical input results in identical output; consequently, if the QKD node and the further QKD node have identical raw quantum key material and are configured to use the same Post-Processing Pipeline, they will obtain identical final blocks. These final blocks may be stored in a block storage 126.

[0083] The Post-Processing Pipeline may also generate a block ID for the final block. The block ID may be based on the raw quantum data, e.g., based on a hash of the raw quantum data. It is noted that using a hash of the raw quantum data may be more secure than using a hash of the final block, especially when the block ID is shared with a different system, e.g., the further QKD node. Nevertheless, in some embodiments, the block ID may instead be determined based on the final block, or based on an intermediate block.

[0084] These final blocks may be used to generate quantum keys, as described in more detail below. The quantum keys may be stored in a quantum key storage 128.

[0085] The QKD node 100 may further comprise a processor 130 and a memory 132, communicatively connected to the processor. The memory may store computer-readable instructions that, when executed, configure the QKD node to perform one or more of the method steps described herein. The QKD node may further comprise a communication interface 134 communicatively connected to the processor for communicating with the further QKD node using a classical communication connection 136.

[0086] Although depicted as separate elements, storages 124, 126, and 128 may relate to the same physical structure. Similarly, memory 132 may be the same physical structure as one or more the storages. Likewise, quantum communication channels 106I,2 and classical communication channel 136 may use (fully or partially) the same hardware.

[0087] Fig. 2 schematically depicts a quantum key distribution system according to an embodiment. The system comprises a first QKD node 200i and a second QKD node 2002. Each of the first and second nodes may be a QKD node as described above with reference to Fig. 1. In general, a quantum key generation process comprises the following steps. First, the first and second QKD nodes generate 202I,2 shared quantum key material that is (in principle) identical in both QKD nodes, using a shared quantum key material generator. The quantum key material is generally processed to increase the security. Subsequently, blocks of the generated quantum key material are synchronised 204I,2, to ensure both QKD nodes can use the same (processed) quantum key material for generating quantum keys. The blocks of synchronised quantum key material are stored until a key request is received at either QKD node. Then, quantum keys are generated and synchronised 206I,2. These quantum keys are used to encrypt information 208I,2 to allow for secure communication between the QKD nodes. Cryptographic protocols for secure communication based on shared quantum keys are well-known in the art.

[0088] The first and second QKD nodes are connected, or at least connectable, via a quantum communication channel which can be used to exchange quantum information 210. The first and second QKD nodes are configured to generate 202I,2, together, quantum key material that is identical in both QKD nodes. Such a configuration may also be referred to as a shared quantum key material generator. Various such systems are known in the art, for example, systems based on the BB84 protocol, E91 entanglement-based protocol, Measurement-Device-Independent QKD (MDI-QKD) protocol, and decoy-state protocol. The MDI-QKD protocol may eliminate detector vulnerabilities by relying on Bell-state measurements at an untrusted central node.

[0089] When a block of quantum key material has been generated by the shared quantum key material generator, each of the first and second QKD nodes may ingest the generated block of quantum key material. In general, this does not happen exactly synchronously; for ease of reference, it is assumed that the first quantum key node ingests the block of quantum key material earlier than the second QKD node. A block of quantum key material may comprise, for example, the quantum key material that has been generated during a fixed amount of cycles, e.g., about 0.1-10 s, possibly depending on the achieved bit rate. For example, If the distance between the nodes (QKD node 1 to QKD node 2, possibly via an intermediate node) is 25 dB (approximately 125 km with current technology), then a quantum key material generation rate of 500 bits / s or more can be achieved. Depending on the details of the system, the rate can be as high as 5 kilobits / s. Due to the stochastic nature of the quantum process used by the quantum key generator, these blocks may have a variable length. The quantum key material that is ingested may also be referred to as raw quantum key material.

[0090] The raw quantum key material may be processed to create processed quantum key material. This processing may increase the randomness of the quantum key material. In general, a block of processed quantum key material is shorter (comprises fewer bits) than the block of raw quantum key material from which it was generated. This processing is deterministic, so that both quantum nodes performing an agreed-upon processing step, so that if the raw quantum key material is identical, then so is the processed quantum key material. The block of (processed) quantum key material may be stored 220 in association with a first state of a first finite-state machine, e.g. ‘Uncommitted’. The first state of the first finite-state machine may indicate that the first block of quantum key material has not been synchronised. In some embodiments, metadata may be generated that identifies the block of quantum key material. Such metadata may include one or more of: a length of the block of raw quantum key material, a hash of the block of raw quantum key material, a length of the block of processed quantum key material, and a hash of the block of processed quantum key material.

[0091] When an unsynchronised block of quantum key material is detected, a process may be initiated to synchronise the block 222. While the block is being synchronised, the block may be associated with a second state of the first finite-state machine, e.g., ‘PreparedToCommit’. The second state of the first finite-state machine may indicate that the first block of quantum key material is in a process of being synchronised. The synchronisation process may comprise sending a synchronisation request 212 to the second QKD node using a classical communication channel. The synchronisation request (uniquely) identifies the first block of quantum key material, e.g., using the generated metadata. In some embodiments, an additional block ID may be sent; in other embodiments, (part of) the metadata can be used as the block ID.

[0092] In dependence on the response received from the second QKD node (including the lack of response), the block of quantum key material may be associated with an updated state of the first finite-state machine. For example, if the response message indicates that the synchronisation was successful 224, the block of quantum key material may be associated 226 with a third state of the first finite-state machine, e.g., ‘Committed’. The third state of the first finite-state machine may indicate that the block of quantum key material has been synchronised. If the response message indicates a failure, or if no response message is received within a predetermined amount of time, the block may be deleted 228, or the block may be associated with the first state of the first finite-state machine (so that a retry 228 can be attempted at a later point in time), or the block may be associated with a fourth state of the first finite-state machine, e.g., ‘CommitLost’ . The fourth state of the first finite-state machine may indicate that the synchronisation has (permanently) failed.

[0093] At this point, the first and second QKD nodes know of each other that they both store identical blocks of quantum key material, and they have a way to uniquely identify these blocks.

[0094] At a second stage, one of the QKD nodes may receive a key request 230. For each of reference, it is again assumed that the first QKD node is the node receiving the key request, but it will be evident that it is not necessary that the node that initiates the synchronisation is also the node that first receives the key request.

[0095] In response to receiving the key request, the first node may generate a quantum key using a synchronised block of quantum key material, using a key generation algorithm that is shared by both QKD nodes. The quantum key may be associated with a first state of a second finite-state machine, e.g., ‘Uncommitted’. The first state of the second finite-state machine may indicate that the first quantum key has not been synchronised.

[0096] When the quantum key has been successfully generated, the QKD nodes may synchronise 232 the quantum key. To that end, the first node may send a key synchronisation request to the second QKD node via the classical communication channel. The key synchronisation request 214 may comprise a key ID identifying the first quantum key and key generation data. The key generation data may comprising a first block ID uniquely identifying the first synchronised block of quantum key material, and when necessary other key generation parameters, such as key length (in implementations with variable-length keys) and key offset (when each block may be used to generate more than one quantum key). The first quantum key may be associated with a second state of a second finite-state machine, e.g., ‘PreparedToCommit’. The second state of the second finite-state machine may indicate that the quantum key is in a process of being synchronised.

[0097] If a message indicating success 234 is received by the first QKD node, the quantum key may be stored 236, and may be associated with a third state of the second finite-state machine, e.g., ‘Committed’. The third state of the second finite-state machine may indicate that the quantum key has been synchronised. If the response message indicates a failure 234, or if no response message is received within a predetermined amount of time, the quantum key may be deleted 238, or, depending on the implementation, the quantum key may be associated with the first state of the first finite-state machine (so that a retry 238 can be attempted at a later point in time), or the quantum key may be associated with a fourth state of the second finite-state machine, e.g., ‘CommitLost’. The fourth state of the second finite-state machine may indicate that the key synchronisation has (permanently) failed.

[0098] If the response indicates that the second QKD node has lost the block of quantum key material, the first QKD node may furthermore delete the corresponding block of quantum key material, and / or associate it with the fourth state of the first finite state engine.

[0099] In some embodiments, the QKD nodes are equal, and either QKD node may initiate a block synchronisation protocol. In other embodiments, only one QKD node may be configured to initiate the block synchronisation protocol.

[0100] Fig. 3A and 3B are flowcharts of a method for synchronising a block of quantum key material in a first QKD node with a second QKD node according to an embodiment. In particular, Fig. 3A is a flowchart of the method executed by the first QKD node, which may also be referred to as a Starter node, and Fig. 3B is a flowchart of the (corresponding) method executed by the second QKD node, which may also be referred to as the Peer node. The first and second QKD nodes share a quantum key material generator. Thus, Fig. 3A may correspond to block 204i in Fig. 2, and Fig. 3B may correspond to block 2042 in Fig. 2.

[0101] The method of Fig. 3A may be executed in response to the first QKD node receiving a block of QKD key material from the (shared) quantum key material generator. In that case, a first step 302i may comprise storing the block of quantum key material. Depending on the implementation, this step may include generating metadata uniquely identifying the block of quantum key material; in other implementations, the metadata, or part thereof, may be received together with the block of quantum key material. The metadata is stored in association with the block of quantum key material. The metadata may comprise, e.g., a block ID that is generated using at least part of the quantum key material.

[0102] Step 302i also comprises associating the block of quantum key material with a first state of a first finite-state machine. The first finite-state machine may be a finite-state machine as described with reference to Fig. 5A. The first state of the first finite-state machine may indicate that the first block of quantum key material has not been synchronised. For ease of reference, such state may be referred to as the ‘Uncommitted’ state herein.

[0103] In other embodiments, the method of Fig. 3A may be executed in response to the first QKD node detecting a stored block of quantum key material associated with the ‘Uncommitted’ state. For example, the first QKD node may be configured to periodically check for blocks of quantum key material in the ‘Uncommitted’ state, e.g., using a background service.

[0104] The same or a similar procedure 3022 may be performed by the second QKD node.

[0105] A step 304 comprises sending, by the first QKD node, a block synchronisation request to the second QKD node. The block synchronisation request identifies the block of quantum key material, e.g., using the metadata stored in association with the block of quantum key material. In other embodiments, the information identifying the block of quantum key material may be generated when the block synchronisation request is sent; yet other embodiments may use a mix of stored and newly generated information. For example, the block synchronisation request may comprise a block ID identifying the block, which block ID may have been generated based on the raw quantum key material and / or the block of quantum key material. The block synchronisation request may further comprise, e.g., a block length, one or more time stamps indicating when the raw quantum key material was generated, et cetera.

[0106] Step 304 further comprises associating the block of quantum key material with a second state of the first finite-state machine. The second state of the first finite-state machine may indicate that the block of quantum key material is in a process of being synchronised. For ease of reference, such state may be referred to as the ‘PreparedToCommit’ state herein. This ‘PreparedToCommit’ state may indicate that a block synchronisation process is running for this block of quantum key material, and may hence prevent a new block synchronisation process from being started for the same block of quantum key material. The status may also affect processing of the block of quantum key material is a block synchronisation request for the same block of quantum key material is received from the second QKD node.

[0107] Subsequently, the first QKD node may wait for a response from the second QKD node. If no response is received (typically within a predetermined amount of time), the first QKD node may retry, by repeating step 304 sending a new block synchronisation request. Optionally, the first QKD node may, in a step 318, wait before retrying. While the first QKD node is waiting, the block of quantum key material may be associated with the ‘Uncommitted’ state of the first finite-state machine. The first QKD node may wait, for instance, for a predetermined amount of time, e.g., a couple of minutes, or based on a schedule. Depending on the implementation, it is possible that during this waiting period, the first QKD node receives a block synchronisation request for the block of quantum key material from the second QKD node. In that case, the block of quantum key material may be synchronised or abandoned, so that the process comes to an end.

[0108] A step 306 comprises receiving a block synchronisation response from the second QKD node, e.g., due to the second QKD node performing any one of steps 336, 340, or 344 (which will be described in more detail below). In general, the response indicates at least a success or a failure, the success indicating that the second QKD node could identify the block of quantum key material and could successfully commit the block of quantum key material. Thus, the first QKD node may test 308 whether the block synchronisation response from the second QKD node indicates a success.

[0109] If the block synchronisation response from the second QKD node indicates a success, the first QKD node, in a step 310 associates the first block of quantum key material with a third state of the first finite-state machine. The third state of the first finite-state machine may indicate that the first block of quantum key material has been synchronised. For ease of reference, such state may be referred to as the ‘Committed’ state herein.

[0110] Once the block of quantum key material has been committed, the block of quantum key material may be used, in a step 312i, by the first QKD node, typically to generate one or more quantum keys. Similarly, the second QKD node may use 3122 the corresponding block of quantum key material, typically to generate one or more matching quantum keys. The block of quantum key material may then be associated with a fourth state of the first finite- state machine. The fourth state of the first finite-state machine may indicate that the block of quantum key material is abandoned, which can be due to a (permanently) failed block synchronisation or due to usage of the block of quantum key material. For ease of reference, such state may be referred to as the ‘CommitLost’ state herein. The block of quantum key material may also be deleted.

[0111] If, in step 308, the block synchronisation response from the second QKD node indicates a failure, then the first QKD node may (in the depicted embodiment) determine a type of failure. In other embodiments, only a single failure state may be used, skipping, e.g., blocks 314 and 320. If, in step 314, the block synchronisation response from the second QKD node indicates that the (corresponding) block of quantum key material has not been found, the first QKD node may determine 316 whether a retry should be performed, e.g., by testing whether a retry limit has been met. The retry limit can be, e.g., a number that is compared with a counter that is incremented at each block synchronisation attempt. Thus, the retry limit may be met after a predetermined amount of block synchronisation attempts. In another example, the retry limit can be an amount of time, e.g., since the block of quantum key material was ingested, or since the first block synchronisation attempt.

[0112] If the retry limit has not been met, the first QKD node may return to step 304, optionally after a waiting step 318 as described above. If the second QKD node indicates that the block of quantum key material has not been found, this may mean that the block is still being processed, and will be available shortly. Hence, in such cases, it may be beneficial to have at least one retry. Advantageously, this retry attempt does not follow too quickly on the first attempt, e.g., after a waiting period of 1 , 2, 5, or 10 minutes.

[0113] If the retry limit has been met, the block of quantum key material may be removed in a step 316. The block of quantum key material may then be associated with the fourth state of the first finite-state machine, i.e., the ‘CommitLost’ state.

[0114] If in step 314, the block synchronisation response from the second QKD node indicates a failure other than that the block of quantum key material has not been found, the first QKD node may test 320 whether the block synchronisation response from the second QKD node indicates that the (corresponding) block of quantum key at the second QKD node has been lost (e.g., the block was corrupted, or the second node has already exceeded its retry limit on synchronising the block of quantum key material).

[0115] In the current example, both outcomes lead to the same result of the block of quantum key material being removed and the state being updated to ‘CommitLost’ (step 322). Hence, step 320 can be omitted without impacting the flow. However, in some embodiments, different (further) actions, not shown here, may be taken based on the outcome of step 320, e.g., different feedback to a III or API.

[0116] Similarly, although in the current flowchart step 318 can be reached either by receiving a (specific) failure response from the second QKD node, or by receiving no response at all, in practice, there may be further actions that are not shown in the flowchart, such as a warning to check the connection if no response is received.

[0117] As noted above, Fig. 3B is a flowchart of the method that may be executed by the second QKD node. A step 330 comprises receiving, from the first QKD node, the block synchronisation request identifying the block of quantum key material. Prior to that, the second QKD node may or may not have ingested the block of quantum key material that corresponds to the block of quantum key material identified in the block synchronisation request. As noted before, corresponding blocks of quantum key material should be identical. In a step 332, the second QKD node identifies the block of quantum key material based on the metadata in the block synchronisation request, determines whether the corresponding block of quantum key material is stored by the second QKD node, and determines the state of the first finite-state machine with which the corresponding block of quantum key material is associated.

[0118] If the corresponding block of quantum key material is in an ‘Uncommitted’ state and the metadata match, the state is updated to ‘PreparedToCommit’. If the corresponding block of quantum key material is already in the ‘PreparedToCommit’ state (e.g., because of a block synchronisation collision) and the metadata match, the state is maintained as ‘PreparedToCommit’.

[0119] If the metadata do not match, the state is updated to ‘CommitLost’. It is noted that the metadata may contain several pieces of data. For example, if the block ID is based on the raw quantum key material, the metadata may also comprise, e.g., a block length of the (final, processed) block of quantum key material. If on either QKD node an error occurred in the Post-Processing Pipeline, this may be detected by comparing the metadata based on the final block of quantum key material.

[0120] A step 334 comprises determining whether the corresponding block of quantum key material was found. If not, a block synchronisation response indicating a failure may be sent 336. In the depicted example, the specific failure ‘Block not found’ may be indicated by the block synchronisation response.

[0121] If step 334 indicates that the corresponding block of quantum key material was found, a step 338 comprises determining whether the block of quantum key material is ready for commission. If the block of quantum key material is in the ‘PreparedToCommit’ state, a block synchronisation response indicating a success is sent 340 to the first QKD node, the block of quantum key material is committed 342, and the block of quantum key material is associated with the ‘Committed’ state. Once the block of quantum key material has been committed, it may be used 3122 by the second QKD node, after which the state of the block of quantum key material may be updated to ‘CommitLost’.

[0122] If in step 338 it is determined that the block of quantum key material is already in the ‘CommitLost’ state, the second QKD node sends, in a step 344, a block synchronisation response indicating the failure to the first QKD node. Additionally, the block of quantum key material may removed, and its state is maintained as ‘CommitLost’.

[0123] Fig. 4A and 4B are flowcharts of a method for synchronising a quantum key in a first QKD node with a second QKD node according to an embodiment. In particular, Fig. 4A is a flowchart of the method executed by the first QKD node, which may also be referred to as a Initiator node, and Fig. 4B is a flowchart of the (corresponding) method executed by the second QKD node, which may also be referred to as the Responder node. Thus, Fig. 4A may correspond to block 206i in Fig. 2, and Fig. 4B may correspond to block 2062 in Fig. 2. The first and second QKD nodes have access to synchronised block of quantum key material. For example, the block of quantum key material may have been synchronised as described above with reference to Fig. 3A and 3B. In that case, the block of quantum key material may be associated with the third state of the first finite-state machine. Although the same terms “first and second QKD node” are used, it is understood that the first QKD node of the method of Fig. 4A can be either the first QKD node or the second QKD node of Fig. 3A and 3B.

[0124] The first and second QKD nodes are configured to use an identical (deterministic) key generation algorithm; thus, by using the same key generation algorithm on the same quantum key material, identical keys are generated.

[0125] A first step 402 comprises receiving, by the first QKD node, a key request. The key request may indicate that a new quantum key should be generated. The key request may comprise key parameters such as a key length (expressed, e.g., in bits).

[0126] In response to receiving the key request, in a step 404, the first QKD node generates a quantum key using the key generation algorithm, based on a synchronised block of quantum key material. The quantum key is associated with a first state of a second finite- state machine. The second finite-state machine may be a finite-state machine as described with reference to Fig. 5B. The first state of the second finite-state machine may indicate that the quantum key has not been synchronised. For ease of reference, such state may be referred to as the ‘Unsynchronised’ state herein.

[0127] Once the quantum key is generated, the first QKD node sends, in a step 406, a key synchronisation request to the second QKD node. The key synchronisation request comprises a key ID identifying the quantum key and key generation data. The key generation data enables the second QKD node to generate an identical quantum key, i.e. , identical to the key generated in step 404. The key generation data comprises a block ID uniquely identifying a synchronised block of quantum key material. The key generation data may further comprise, e.g., the key length and a key address (e.g., an offset relative to a start of the block of quantum key material). If the key length is larger than a size of the block of quantum key material, two or more blocks of quantum key material may be indicated. In some embodiments, a key may always be generated with a fixed offset (potentially zero), so that there is no need to specify the offset.

[0128] Step 406 further comprises associating the quantum key with a second state of a second finite-state machine. The second state of the second finite-state machine may indicate that the quantum key is in a process of being synchronised. For ease of reference, such state may be referred to as the ‘PreparedToSynchronise’ state herein.

[0129] Subsequently, the first QKD node may wait for a response from the second QKD node. If no response is received (typically within a predetermined amount of time), e.g., due to a network error, the first QKD node may delete the quantum key and retry, by repeating steps 404 and 406, generating a new quantum key and sending a new key synchronisation request. This may result in the same or a different quantum key. In other embodiments, the quantum key may be stored in the ‘Unsynchronised state’, and only step 406 may be repeated. Not storing the unsynchronised quantum key reduces the possibility that the key is accessed by an unauthorized user. In some embodiments, an error may be sent to the entity from which the key request was received.

[0130] Optionally, the first QKD node may, in a step 408, wait before retrying. In embodiments wherein the quantum key is not deleted, the quantum key may be associated with the ‘Unsynchronised’ state of the second finite-state machine while the first QKD node is waiting. The first QKD node may wait, for instance, for a predetermined amount of time, e.g., a couple of minutes, or based on a schedule. Depending on the implementation, it is possible that during this waiting period, the first QKD node receives a key synchronisation request from the second QKD node, indicating the same block of quantum key material. In that case, the current quantum key may be removed, so that the process comes to an end (whilst continuing with the process initiated by the second QKD node).

[0131] A step 410 comprises receiving, by the first QKD node, a response from the second QKD node. The response indicates whether or not the second QKD node successfully generated a corresponding quantum key based on the key generation data.

[0132] A step 412 comprises determining whether the response indicates that the second QKD node successfully generated the corresponding quantum key. If the response indicates that the generation of the corresponding quantum key by the second QKD node failed, a step 414 comprises removing the quantum key. Step 414 further comprises associating the quantum key (e.g., via the key ID) with a fourth state of second finite-state machine. The fourth state of the second finite-state machine may indicating that synchronisation of the quantum key failed. For ease of reference, such state may be referred to as the ‘SynchroniseLost’ state herein.

[0133] Step 414 may further comprise associating the block of quantum key material with the fourth state (‘CommitLost’) of the first finite-state machine, in particular when the response indicates that the failure is due to the second QKD node not having the block of quantum key material in the ‘Committed’ state of the first finite state engine; for example, the response may indicate that the block of quantum key material is not found by the second QKD node or that the block of quantum key material is associated with the ‘CommitLost’ of the first finite- state machine.

[0134] If (and only if) the response indicates that the corresponding quantum key was successfully generated, a step 416 comprises storing the quantum key. Step 416 further comprises associating the quantum key with a third state of the second finite-state machine. The third state of the second finite-state machine may indicate that the quantum key has been synchronised. For ease of reference, such state may be referred to as the ‘Synchronised’ state herein.

[0135] A step 418 comprises providing the quantum key and the key ID, typically to the entity from which the key request was received. That entity may use the key ID to indicate to an entity connected to the second QKD node which quantum key to use. Step 418 further comprises associating the quantum key with the ‘SynchroniseLost’ of the second finite-state machine. This prevents reuse of the same quantum key.

[0136] As noted above, Fig. 4B is a flowchart of the method that may be executed by the second QKD node. A step 422 comprises receiving, by the second QKD node, the key synchronisation request from the first QKD node (sent in step 406).

[0137] A step 424 comprises identifying the (synchronised) block of quantum key material based on the block ID. A step 426 comprises determining whether the block of quantum key material was found (successfully identified). Step 426 may further comprise determining whether the block of quantum key material is associated with the ‘Committed’ state of the first finite state engine.

[0138] If the synchronised block of quantum key material is not available to the second QKD node (e.g., because the block of quantum key material is not found or is not in the ‘Committed’ state), then a step 428 comprises sending, by the second QKD node, a ‘failed’ response to the first QKD node. The ‘failed’ response indicates that the first synchronised block of quantum key material is not available to the second QKD node.

[0139] Else, if the synchronised block of quantum key material is available to the second QKD node, a step 430 comprises generating, by the second QKD node, a corresponding quantum key using the key generation algorithm, based on the synchronised block of quantum key material. Step 430 further comprises storing the corresponding quantum key and associating the corresponding quantum key with the key ID. Step 430 further comprises associating the corresponding quantum key with the ‘Synchronised’ state of the second finite-state machine.

[0140] A step 434 comprises receiving, by the second QKD node, a key request comprising the key ID. In response to receiving the key request, a step 436 comprises providing the corresponding quantum key (based on the key ID), typically to the entity from which the key request was received. Step 436 further comprises associating the corresponding quantum key with the ‘SynchroniseLost’ of the second finite-state machine.

[0141] Fig. 5A is a schematic representation of a first finite-state machine according to an embodiment. Each block of quantum key material may be associated with a state of the first finite-state machine. The depicted finite-state machine comprises four states: a first state 501 labelled ‘Uncommitted’, a second state 502 labelled ‘PreparedToCommit’, a third state 503 labelled ‘Committed’, and a fourth state 504 labelled ‘CommitLost’. In this example, the first state is the initial state and the fourth state is the final state. The finite-state machine can transition from the first state 501 to the second state 502 when a block synchronisation process is started. In some embodiments, the finite-state machine can also transition from the first state to the fourth state 504, e.g., when a block of quantum key material is too old 505. This can happen when, for some reason, no block synchronisation process is started for the block of quantum key material, or when one or more block synchronisation processes have been started for the block of quantum key material but resulted in the block of quantum key material returning to the ‘Uncommitted’ state.

[0142] The finite-state machine can transition from the second state 502 to the third state 503 when the block synchronisation process is completed successfully. The finite-state machine can also transition from the second state 502 to the fourth state 504 when the block synchronisation process did not complete successfully 507 due to a mismatch between blocks of quantum key material that are to be synchronised, or due to an error associated with one of the blocks of quantum key material in one of the QKD nodes. In some embodiments, the finite-state machine can also transition 506 from the second state to the first state 501 , e.g., when the block synchronisation process failed but a retry is still possible; for example, if the block synchronisation process failed due to a network error, or because the second QKD node has not yet ingested and / or processed the corresponding block of quantum key material, rather than to a mismatch of corresponding blocks of quantum key material.

[0143] The finite-state machine can transition from the third state 503 to the fourth state 504, e.g., because the block of quantum key material is used 508 (typically to generate a quantum key). The finite-state machine can also transition from the third state to the fourth state for other reasons (indicated by the unlabelled arrow), e.g., because the block of quantum key material is too old, or because of an error during a key synchronisation process.

[0144] Fig. 5B is a schematic representation of a second finite-state machine according to an embodiment. Each quantum key may be associated with a state of the second finite-state machine. The depicted finite-state machine comprises four states: a first state 511 labelled ‘Unsynchronised’, a second state 512 labelled ‘PreparedToSynchronise’, a third state 513 labelled ‘Synchronised’, and a fourth state 514 labelled ‘SynchroniseLost’. In this example, the first state is the initial state and the fourth state is the final state.

[0145] The finite-state machine can transition from the first state 511 to the second state 512 when a key synchronisation process is started. It is noted that whereas quantum key material is in principle scarce, and hence should not be discarded without a good reason, quantum keys can be generated as long as there is sufficient quantum key material available; hence, quantum keys may be removed when there is no risk they have been compromised, and there is generally no reason to transition quantum keys directly from ‘Unsynchronised’ to ‘SynchroniseLost’. The finite-state machine can transition from the second state 512 to the third state 513 when the key synchronisation process is completed successfully. The finite-state machine can also transition from the second state 512 to the fourth state 514 when the key synchronisation process did not complete successfully 517 due to a failure to generate a corresponding quantum key. This can be caused, for example, by a mismatch between blocks of quantum key material that are to be used for quantum key generation, or due to an error associated with one of the quantum keys in one of the QKD nodes. In some embodiments, the finite-state machine can also transition 516 from the second state to the first state 511 , e.g., when the key synchronisation process failed but a retry is still possible; for example, if the key synchronisation process failed due to a network error, rather than to a mismatch of corresponding blocks of quantum key material or a quantum key generation failure.

[0146] The finite-state machine can transition from the third state 513 to the fourth state 514, e.g., because the quantum key is used 518, or at least provided to a user. The finite-state machine can also transition from the third state to the fourth state for other reasons, e.g., because the quantum key is too old (expired; not labelled in the Figure).

[0147] Fig. 5C is a flowchart of a method for synchronising a block of quantum key material according to an embodiment. The method may be performed by a QKD node as described herein. The method may be run, e.g., as a background process. A first step 522 comprises receiving or ingesting a block of quantum key material.

[0148] A step 524 comprises synchronising blocks of quantum key material that have not yet been synchronised, e.g., blocks that are associated with the ‘Uncommitted’ state. Step 524 may be performed in response to the QKD node receiving or ingesting the block of quantum key material. Additionally or alternatively, step 524 may be performed based on a schedule, e.g., periodically. During step 524, the block(s) of quantum key material that are being synchronised may be in the ‘PreparedToCommit’ state. If after the (unsuccessful) synchronisation process the block of quantum key material is returned to the ‘Uncommitted’ state, step 524 may be performed again, e.g., with a fixed delay or according to a fixed schedule.

[0149] A step 526 comprises deleting blocks of quantum key material that exceed a retry limit. Such a retry limit may be based, e.g., on a number of synchronisation attempts, and / or on an amount of time since step 522. Step 526 may also comprise deleting blocks of quantum key material that are in the ‘CommitLost’ state, either due to a failed commissioning process or due to usage of the block. Step 526 may also comprise deleting expired keys, e.g., keys that have not been used within a certain amount of time after being generated, or keys with the ‘SynchroniseLost’ state.

[0150] Fig. 6A and 6B are flowcharts of methods for synchronisation of a block of quantum key material according to various embodiments. In particular, Fig. 6A is a flowchart of a method executed by a first QKD node for synchronising a block of quantum key material in the first QKD node with a corresponding block of quantum key material in a further QKD node. The first QKD node and the further QKD node share a quantum key material generator.

[0151] A step 602i comprises ingesting the block of quantum key material from the quantum key material generator. A step 604i comprises storing the block of quantum key material in association with a first state of a first finite-state machine, e.g., a finite state engine as discussed with reference to Fig. 5A. The first state of the first finite-state machine may indicate that the block of quantum key material has not been synchronised.

[0152] A step 610 comprises sending a synchronisation request to the further QKD node. The synchronisation request identifies the block of quantum key material, e.g., using metadata related to or based on the block of quantum key material and / or related to or based on preliminary quantum key material used to generate the block of quantum key material. For example, the metadata may comprise a block ID uniquely identifying the block of quantum key material and / or a length of the block of quantum key material. The block ID may be based, for instance, on a hash of the block of quantum key material or based on a hash of the preliminary quantum key material used to generate the block of quantum key material. The further QKD node may use the same algorithm to determine the metadata, so that the metadata of two blocks of quantum key material being equal is an indication of the blocks of quantum key material being equal.

[0153] A step 612 comprises associating the block of quantum key material with a second state of the first finite-state machine. The second state of the first finite-state machine may indicate that the block of quantum key material is in a process of being synchronised.

[0154] A step 614 comprises receiving a response from the further QKD node. The response may comprise an indication whether the further QKD node stores a corresponding block of quantum key material and if so, an indication of the state of the first finite-state machine associated with the corresponding block of quantum key material (e.g., ‘CommitLost’ or a different state).

[0155] A step 616 comprises associating the block of quantum key material with an updated state of the first finite-state machine in dependence on the response. Associating the block of quantum key material with an updated state of the first finite-state machine may comprises at least one of:

[0156] - if and only if the response indicates that the further QKD node stores a corresponding block of quantum key material, associating the block of quantum key material with a third state of the first finite-state machine;

[0157] - if the response indicates that the further QKD node does not store a corresponding block of quantum key material, associating the block of quantum key material with the first state of the first finite-state machine or with a fourth state of the first finite- state machine;

[0158] - if the response indicates that the further QKD node has lost the corresponding block of quantum key material, associating the block of quantum key material with the fourth state of the first finite-state machine;

[0159] - if no response is received within a predetermined time limit, associating the block of quantum key material with the first state of the first finite-state machine or with the fourth state of the first finite-state machine.

[0160] Herein, the third state of the first finite-state machine may indicate that the block of quantum key material has been synchronised, and the fourth state of the first finite-state machine may indicate that the synchronisation of the block of quantum key material has (permanently) failed.

[0161] Fig. 6B is a flowchart of a method executed by the further QKD node in response to the further QKD node receiving the synchronisation request from the first QKD node. Before receiving the synchronisation request from the first QKD node, the second QKD node may or may not have executed the steps of ingesting 6022 a corresponding block of quantum key material from the quantum key material generator, and storing 6042 the corresponding block of quantum key material in association with the first state of the first finite-state machine. The generation and processing of blocks of quantum key material may not be completely synchronised between the two QKD nodes. Hence, the further QKD node may receive the synchronisation request before it has completed ingesting the corresponding block of quantum key material.

[0162] A step 620 comprises receiving the synchronisation request from the first QKD node. The synchronisation request identifies the block of quantum key material.

[0163] A step 622 comprises determining whether the further QKD node stores the corresponding block of quantum key material. A correspondence between blocks of quantum key material may be determined based on information in the synchronisation request (uniquely) identifying the block of quantum key material, e.g., as described for step 610.

[0164] If the further QKD node has stored the corresponding block of quantum key material, a step 624 comprises associating the corresponding block of quantum key material with an updated state of the first finite-state machine. If an error is detected (e.g., a sanity check is failed, or the metadata do not match), then the corresponding block of quantum key material may be associated with the fourth state of the first finite state engine; else, the corresponding block of quantum key material may be associated with the third state of the first finite state engine.

[0165] A step 626 comprises sending a response to the first QKD node. The response indicates whether the further QKD node has stored the corresponding block of quantum key material. Furthermore, if the further QKD node has stored the corresponding block of quantum key material, the response indicates the state of a first finite-state machine associated with the corresponding block of quantum key material.

[0166] In particular, if (and only if) the further QKD node determines that the corresponding block of quantum key material is associated with the first, second, or third state of the first finite-state machine, then the response may indicate a success, else, the response may indicating that the further QKD node has lost the corresponding block of quantum key material.

[0167] Fig. 7A and 7B are flowcharts of methods for synchronisation of a quantum key according to various embodiments. In particular, Fig. 7A is a flowchart of a method executed by a first QKD node for synchronising a quantum key with a further QKD node. The QKD node and the further QKD node have access to synchronised blocks of quantum key material. The synchronised blocks of quantum key material may have been synchronised by executing the method of Fig. 6A and 6B, for example. The QKD node and the further QKD node are configured to use an identical key generation algorithm.

[0168] A step 702 comprises receiving a key request. A step 704 comprises generating a quantum key based on a synchronised block of quantum key material. The quantum key is generated using the key generation algorithm that is identical in both QKD nodes. The quantum key is associated with a key ID. A step 706 comprises associating the quantum key with a first state of a second finite-state machine. The first state of the second finite-state machine may indicate that the quantum key has not been synchronised.

[0169] A step 708 comprises sending a key synchronisation request to the further QKD node. The key synchronisation request comprises the key ID for identifying the quantum key, and key generation data. The key generation data may comprise information for identifying the first synchronised block of quantum key material, e.g., a block ID.

[0170] A step 710 comprises associating the quantum key with a second state of the second finite-state machine. The second state of the second finite-state machine may indicate that the quantum key is in a process of being synchronised.

[0171] A step 712 comprises receiving a response from the further QKD node. The response indicates whether or not the further QKD node successfully generated a corresponding quantum key based on the key generation data.

[0172] A step 714 comprises associating the quantum key with a third state of the second finite-state machine, if (and only if) the response indicates that the corresponding quantum key was successfully generated by the further QKD node. Otherwise, the quantum key may be removed and, depending on the implementation and potentially on the error type, the method may be retried at a later point. The third state of the second finite-state machine may indicate that the quantum key has been synchronised;

[0173] A step 716 comprises providing the quantum key and the key ID, e.g., to a user. Fig. 7B is a flowchart of a method executed by the further QKD node in response to the further QKD node receiving the key synchronisation request from the first QKD node, as described in step 708.

[0174] A step 722 comprises receiving a key synchronisation request from the first QKD node. The key synchronisation request comprises a key ID and key generation data, as described in step 708.

[0175] A step 724 comprises generating a corresponding quantum key using the key generation data. The further QKD node uses the key generation algorithm that is identical to the key generation algorithm used by the first QKD node. Step 724 further comprises associating the corresponding quantum key with the key ID. A step 726 comprises associating the corresponding quantum key with the third state of the second finite-state machine.

[0176] A step 728 comprises sending a response to the first QKD node. If the generation of the corresponding quantum key was successful, response may indicate a success. If the generation of the corresponding quantum key failed, the response may indicate that the key generation failed, and optionally, a cause of failure. A cause of failure can be that the synchronised block of quantum key material is not available to the further QKD node, either because it cannot be found, or because the block is associated with a state indicating that the block is not valid, e.g., that synchronisation of the block has failed. An example of such a state is the ‘CommitLost’ state described herein.

[0177] An optional step 730 comprises receiving a key request comprising the key ID. An optional step 732 comprises providing the corresponding quantum key, e.g., to a user. The corresponding quantum key may be retrieved based on the key ID associated with the quantum key.

[0178] Fig. 8 is a flow diagram showing an example of a method for synchronisation of a block of quantum key material according to an embodiment. In a successful block synchronisation process, both the first and second QKD node ingest identical blocks of quantum key material. Node 1 sends a block synchronisation request to Node 2; the block synchronisation request contains information to identify and verify the block of quantum key material to be synchronised. Node 2 receives the block synchronisation request, and identifies and verifies the corresponding block of quantum key material. Node 2 sends a block synchronisation response to Node 1 , indicating the result of the identification and verification. If the identification and verification was successful, both nodes commit the synchronised block of quantum key material.

[0179] The user layer of the QKD nodes is not involved in this process.

[0180] Fig. 9 is a flow diagram showing an example of a method for synchronisation of a quantum key according to an embodiment. In a successful block synchronisation process, both the first and second QKD node have committed synchronised (identical) blocks of quantum key material.

[0181] The user of Node 1 sends a key request to the key store of Node 1. The key store of Node 1 receives the key request, generates a new key from the committed block, and associates the new key with a (unique) key ID. The key store of Node 1 sends a key synchronisation request to the key store of Node 2. The key synchronisation request contains an identifier of the committed block and the key ID. The key store of Node 2 receives the key synchronisation request and generates a corresponding key from the committed block identified by the identifier from the key synchronisation request. The key store of Node 2 associates the corresponding key with the key ID. The key store of Node 2 sends a key synchronisation response to the key store of Node 1 , indicating whether the corresponding key was successfully generated. If the corresponding key was successfully generated, both key store commit the key in association with the key ID. The key store of Node 1 provides the key and the key ID to the user of Node 1.

[0182] The user of Node 1 sends the key ID to the user of Node 2. The user of Node 2 sends a key request containing the key ID to the key store of Node 2. The key store of Node 2 identifies the (corresponding) key based on the key ID and provides the corresponding key to the user of Node 2. The user of Node 2 receives the corresponding key.

[0183] The users of both nodes may now securely communicate by encrypting and / or decrypting messages using the key.

[0184] Fig. 10 is a block diagram illustrating exemplary data processing systems described in this disclosure. Data processing system 1000 may include at least one processor 1002 coupled to memory elements 1004 through a system bus 1006. As such, the data processing system may store program code within memory elements 1004. Further, processor 1002 may execute the program code accessed from memory elements 1004 via system bus 1006. In one aspect, data processing system may be implemented as a computer that is suitable for storing and / or executing program code. It should be appreciated, however, that data processing system 1000 may be implemented in the form of any system including a processor and memory that is capable of performing the functions described within this specification.

[0185] Memory elements 1004 may include one or more physical memory devices such as, for example, local memory 1008 and one or more bulk storage devices 1010. Local memory may refer to random access memory or other non-persistent memory device(s) generally used during actual execution of the program code. A bulk storage device may be implemented as a hard drive or other persistent data storage device. The processing system 1000 may also include one or more cache memories (not shown) that provide temporary storage of at least some program code in order to reduce the number of times program code must be retrieved from bulk storage device 1010 during execution. Input / output (I / O) devices depicted as key device 1012 and output device 1014 optionally can be coupled to the data processing system. Examples of key device may include, but are not limited to, for example, a keyboard, a pointing device such as a mouse, or the like. Examples of output device may include, but are not limited to, for example, a monitor or display, speakers, or the like. Key device and / or output device may be coupled to data processing system either directly or through intervening I / O controllers. A network adapter 1016 may also be coupled to data processing system to enable it to become coupled to other systems, computer systems, remote network devices, and / or remote storage devices through intervening private or public networks. The network adapter may comprise a data receiver for receiving data that is transmitted by said systems, devices and / or networks to said data and a data transmitter for transmitting data to said systems, devices and / or networks. Operation modems, cable operation modems, and Ethernet cards are examples of different types of network adapter that may be used with data processing system 1000.

[0186] As pictured in FIG. 10, memory elements 1004 may store an application 1018. It should be appreciated that data processing system 1000 may further execute an operating system (not shown) that can facilitate execution of the application. Application, being implemented in the form of executable program code, can be executed by data processing system 1000, e.g., by processor 1002. Responsive to executing application, data processing system may be configured to perform one or more operations to be described herein in further detail.

[0187] In one aspect, for example, data processing system 1000 may represent a client data processing system. In that case, application 1018 may represent a client application that, when executed, configures data processing system 1000 to perform the various functions described herein with reference to a “client”. Examples of a client can include, but are not limited to, a personal computer, a portable computer, a mobile phone, or the like.

[0188] In another aspect, data processing system may represent a server. For example, data processing system may represent an (HTTP) server in which case application 1018, when executed, may configure data processing system to perform (HTTP) server operations. In another aspect, data processing system may represent a module, unit or function as referred to in this specification.

[0189] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and / or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present embodiments has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.

Claims

36CLAIMS1. A computer-implemented method for synchronising a first block of quantum key material in a first QKD node with a second QKD node, the first QKD node and the second QKD node sharing a quantum key material generator, the method comprising: ingesting, by the first QKD node, the first block of quantum key material from the quantum key material generator; storing, by the first QKD node, the first block of quantum key material in association with a first state of a first finite-state machine of the first QKD node, the first state of the first finite-state machine indicating that the first block of quantum key material has not been synchronised; sending, by the first QKD node, a synchronisation request to the second QKD node, the synchronisation request identifying the first block of quantum key material, and associating the first block of quantum key material with a second state of the first finite-state machine, the second state of the first finite-state machine indicating that the first block of quantum key material is in a process of being synchronised; and in dependence on a response being received, by the first QKD node, from the second QKD node, associating the first block of quantum key material with an updated state of the first finite-state machine.

2. The method as claimed in claim 1 , wherein associating the first block of quantum key material with an updated state of the first finite-state machine comprises at least one of:- if and only if the response indicates that the second QKD node stores a second block of quantum key material corresponding to the first block of quantum key material, associating the first block of quantum key material with a third state of the first finite-state machine, the third state of the first finite-state machine indicating that the first block of quantum key material has been synchronised;- if the response indicates that the second QKD node does not store the second block of quantum key material corresponding to the first block of quantum key material, associating the first block of quantum key material with the first state of the first finite-state machine, or a fourth state of the first finite-state machine, the fourth state of the first finite-state machine indicating that the synchronisation has failed;- if the response indicates that the second QKD node has lost the second block of quantum key material corresponding to the first block of quantum key material, associating the first block of quantum key material with the fourth state of the first finite-state machine;37- if no response is received within a predetermined time limit, associating the first block of quantum key material with the first state of the first finite-state machine, or the fourth state of the first finite-state machine.

3. The method as claimed in claim 1 or 2, wherein the synchronisation request comprises metadata based on the first block of quantum key material, preferably the metadata comprising a first block ID uniquely identifying the first block of quantum key material and / or the metadata comprising a length of the first block of quantum key material.

4. The method as claimed in claim 3, wherein the first block ID is based on a hash of the first block of quantum key material or based on a hash of preliminary quantum key material used to generate the first block of quantum key material.

5. A computer-implemented method for synchronising a first block of quantum key material in a first QKD node with second block of quantum key material in a second QKD node, the first QKD node and the second QKD node sharing a block of quantum key material generator, the method comprising: receiving, by the second QKD node, a synchronisation request from the first QKD node, the synchronisation request identifying the first block of quantum key material; determining, by the second QKD node, whether the second QKD node stores the second block of quantum key material corresponding to the first block of quantum key material; if the second QKD node stores the second block of quantum key material, associating the second block of quantum key material with an updated state of a first finite-state machine of the second QKD node; and sending, by the second QKD node, a response to the first QKD node, the response indicating whether the second QKD node stores the second block of quantum key material and, if the second QKD node stores the second block of quantum key material, the response being based on the state of the first finite-state machine of the second QKD node associated with the second block of quantum key material.

6. The method as claimed in claim 5, wherein: if and only if the second QKD node does not store the second block of quantum key material corresponding to the first block of quantum key material, then sending, by the second QKD node, a response to the first QKD node, the response indicating that the second QKD node does not store second block of quantum key material corresponding to the first block of quantum key material;else, if and only if the second QKD node determines that the second block of quantum key material is associated with a first state of a first finite-state machine, a second state of a first finite-state machine, or a third state of a first finite-state machine, the first state of the first finite-state machine indicating that the second block of quantum key material has not been synchronised, the second state of the first finite-state machine indicating that the second block of quantum key material is in a process of being synchronised, and the third state of the first finite-state machine indicating that the second block of quantum key material has been synchronised, , then sending, by the second QKD node, a response to the first QKD node, the response indicating that the second QKD node stores second block of quantum key material corresponding to the first block of quantum key material, and associating the second block of quantum key material with the third state of the first finite- state machine; else, if and only if the second QKD node determines that the second block of quantum key material is associated with a fourth state of the first finite-state machine, the fourth state of the first finite-state machine indicating that the synchronisation has failed, then sending, by the second QKD node, a response to the first QKD node, the response indicating that the second QKD node has lost the second block of quantum key material corresponding to the first block of quantum key material.

7. A computer-implemented method for synchronising a first quantum key in a first QKD node with a second QKD node, the first QKD node and the second QKD node having access to synchronised blocks of quantum key material, the first QKD node and the second QKD node being configured to use an identical key generation algorithm, the method comprising: receiving, by the first QKD node, a key request; generating, by the first QKD node, the first quantum key using the identical key generation algorithm, based on a first synchronised block of quantum key material, and associating the first quantum key with a first state of a second finite-state machine, the first state of the second finite-state machine indicating that the first quantum key has not been synchronised; sending, by the first QKD node, a key synchronisation request to the second QKD node, the key synchronisation request comprising a key ID identifying the first quantum key and key generation data, the key generation data comprising a first block ID uniquely identifying the first synchronised block of quantum key material, and associating the first quantum key with a second state of the second finite-state machine, the second state of the second finite-state machine indicating that the first quantum key is in a process of being synchronised;receiving, by the first QKD node, a response from the second QKD node, the response indicating whether or not the second QKD node successfully generated a second quantum key based on the key generation data; if and only if the response indicates that the second quantum key was successfully generated:- associating the first quantum key with a third state of the second finite-state machine, the third state of the second finite-state machine indicating that the first quantum key has been synchronised; and- providing the first quantum key and the key ID.

8. The method as claimed in claim 7, wherein the key synchronisation request further comprises at least one of: a key length and a key address.

9. The method as claimed in claim 7 or 8, further comprising: if the response indicates that the generation of the second quantum key by the second QKD node failed, associating the first quantum key with a fourth state of second finite-state machine, the fourth state of the second finite-state machine indicating that synchronisation of the first quantum key failed.

10. The method as claimed in any one of claims 7-9, wherein the synchronised blocks of quantum key material have been synchronised according to the method as claimed in any one of claims 1-5, and wherein the first synchronised block of quantum key material is associated with the third state of the first finite-state machine.

11. The method as claimed in claim 10, further comprising: if the response indicates that the block of quantum key material is not found by the second QKD node or that the block of quantum key material is associated with the fourth state of the first finite-state machine, associating, by the first QKD node, the block of quantum key material with the fourth state of the first finite-state machine and associating, by the first QKD node, the first quantum key with the fourth state of the second finite-state machine.

12. A computer-implemented method for synchronising a first quantum key in a first QKD node with a second QKD node, the first QKD node and the second QKD node having access to synchronised blocks of quantum key material, the first QKD node and the second QKD node being configured to use an identical key generation algorithm, the method comprising:receiving, by the second QKD node, a key synchronisation request from the first QKD node, the key synchronisation request comprising a key ID and key generation data, the key generation data comprising a first block ID uniquely identifying a first synchronised block of quantum key material; if the first synchronised block of quantum key material is not available to the second QKD node, then sending, by the second QKD node, a ‘failed’ response to the first QKD node, the ‘failed’ response indicating that the first synchronised block of quantum key material is not available to the second QKD node; else generating, by the second QKD node, a second quantum key using the identical key generation algorithm, based on the first synchronised block of quantum key material, and associating the second quantum key with the key ID, and associating the second quantum key with a third state of a second finite-state machine, the third state of the second finite- state machine indicating that the second quantum key has been synchronised; and in response to receiving a key request comprising the key ID, providing the second quantum key.

13. A QKD node configured to be communicatively connectable to a further QKD node, the QKD node and the further QKD node sharing a quantum key material generator, the QKD node comprising a processor and a memory, the memory storing computer- readable instructions that, when executed by the processor, configure the QKD node to: ingest a first block of quantum key material from the quantum key material generator; store the first block of quantum key material in association with a first state of a first finite-state machine, the first state of the first finite-state machine indicating that the first block of quantum key material has not been synchronised; send a synchronisation request to the further QKD node, the synchronisation request identifying the first block of quantum key material, and associating the first block of quantum key material with a second state of the first finite-state machine, the second state of the first finite-state machine indicating that the first block of quantum key material is in a process of being synchronised; and in dependence on a response being received by the QKD node from the further QKD node, associate the first block of quantum key material with an updated state of the first finite-state machine.

14. A QKD node configured to be communicatively connectable to a further QKD node, the QKD node and the further QKD node sharing a quantum key material generator, the QKD node comprising a processor and a memory, the memory storing computer- readable instructions that, when executed by the processor, configure the QKD node to:41 receive a synchronisation request from the further QKD node, the synchronisation request identifying the first block of quantum key material; determine whether the QKD node stores the second block of quantum key material corresponding to the first block of quantum key material; if the QKD node stores the second block of quantum key material, associate the second block of quantum key material with an updated state of the first finite-state machine; and send a response to the further QKD node, the response indicating whether the QKD node stores the second block of quantum key material and, if the QKD node stores the second block of quantum key material, the response being based on the state of a first finite- state machine associated with the second block of quantum key material.

15. A QKD node configured to be communicatively connectable to a further QKD node, the QKD node and the further QKD node having access to synchronised blocks of quantum key material, the QKD node and the further QKD node being configured to use an identical key generation algorithm, the QKD node comprising a processor and a memory, the memory storing computer-readable instructions that, when executed by the processor, configure the QKD node to: receive a key request; generate a first quantum key using the identical key generation algorithm, based on a first synchronised block of quantum key material, and associating the first quantum key with a first state of a second finite-state machine, the first state of the second finite-state machine indicating that the first quantum key has not been synchronised; send a key synchronisation request to the further QKD node, the key synchronisation request comprising a key ID identifying the first quantum key and key generation data, the key generation data comprising a first block ID uniquely identifying the first synchronised block of quantum key material, and associate the first quantum key with a second state of the second finite-state machine, the second state of the second finite-state machine indicating that the first quantum key is in a process of being synchronised; receive a response from the further QKD node, the response indicating whether or not the further QKD node successfully generated a second quantum key based on the key generation data; if and only if the response indicates that the second quantum key was successfully generated:- associate the first quantum key with a third state of the second finite-state machine, the third state of the second finite-state machine indicating that the first quantum key has been synchronised; and- provide the first quantum key and the key ID.4216. A QKD node configured to be communicatively connectable to a further QKD node, the QKD node and the further QKD node having access to synchronised blocks of quantum key material, the QKD node and the further QKD node being configured to use an identical key generation algorithm, the QKD node comprising a processor and a memory, the memory storing computer-readable instructions that, when executed by the processor, configure the QKD node to: receive a key synchronisation request from the further QKD node, the key synchronisation request comprising a key ID and key generation data, the key generation data comprising a first block ID uniquely identifying a first synchronised block of quantum key material; if the first synchronised block of quantum key material is not available to the second QKD node, then send a ‘failed’ response to the further QKD node, the ‘failed’ response indicating that the first synchronised block of quantum key material is not available to the second QKD node; else generate a second quantum key using the identical key generation algorithm, based on the first synchronised block of quantum key material, and associate the second quantum key with the key ID, and associate the second quantum key with a third state of a second finite-state machine, the third state of the second finite-state machine indicating that the second quantum key has been synchronised; and in response to receiving a key request comprising the key ID, provide the second quantum key.

17. A QKD system comprising: a first QKD node as claimed in claim 13 and a second QKD node, different from the first QKD node, as claimed in claim 14; and / or a third QKD node as claimed in claim 15 and a fourth QKD node, different from the third QKD node, as claimed in claim 16.

18. A computer program product comprising instructions which, when the computer program is executed by a QKD node as defined in any one of claims 13-16, cause the QKD node to perform the method steps as claimed in any one of claims 1-12.

19. A computer-readable storage medium comprising instructions which, when executed by a computer, cause the computer to perform the method steps as claimed in any one of claims 1-12.4320. A computer-implemented method for synchronising a first block of quantum key material in a first QKD node with a second QKD node, the first QKD node and the second QKD node sharing a quantum key material generator, the method comprising: ingesting, by the first QKD node, the first block of quantum key material from the quantum key material generator; storing, by the first QKD node, the first block of quantum key material in association with a first state of a first finite-state machine of the first QKD node, the first state of the first finite-state machine indicating that the first block of quantum key material has not been synchronised; sending, by the first QKD node, a synchronisation request to the second QKD node, the synchronisation request identifying the first block of quantum key material, and associating the first block of quantum key material with a second state of the first finite-state machine, the second state of the first finite-state machine indicating that the first block of quantum key material is in a process of being synchronised; in reaction to either not receiving by the first QKD node a response from the second QKD node within a predetermined time limit, or receiving by the first QKD node a response from the second QKD node indicating that the second QKD node does not store the second block of quantum key material corresponding to the first block of quantum key material, associating the first block of quantum key material with the first state of the first finite-state machine; and sending, by the first QKD node, a new synchronisation request to the second QKD node, the synchronisation request identifying the first block of quantum key material, and associating the first block of quantum key material with the second state of the first finite- state machine.

Images