A system and method for cryptograpic key distribution

Abstract

A method and system for operating a key management system comprising at least two nodes arranged to generate shared entropy, and comprising: the at least two nodes cooperating to generate shared entropy at the at least two nodes; at each of the at least two nodes: allocating a first portion of the generated shared entropy for internal use within the system based on the amount of shared symmetric encryption key material for internal use stored at least one of the at least two nodes and allocating a second portion of the generated shared entropy for external use; using the first portion of the generated shared entropy to generate shared symmetric encryption keys for internal use; and storing the shared symmetric encryption keys for internal use.

Description

A SYSTEM AND METHOD FOR CRYPTOGRAPIC KEY DISTRIBUTION

[0001] The present application relates to a method of controlling key distribution in a cryptographic key distribution system, and a system and software for carrying out the method.

[0002] Cryptography is used to protect billions of transactions every day from, without limitation, for example Transport Layer Security (TLS) security for online shopping and banking to ultra-secure government communications. These transactions rely on reliable and secure means for at least two or more transacting parties to share a secret key, enabling encryption of data by one party and subsequent decryption by the other party(ies). When commercially usable universal quantum computers become available, a variety of these types of transactions, tasks and applications including, without limitation, for example digital banking, web certification, Know Your Customer (KYC), digital asset transfer, and authentication will be vulnerable. These transactions, tasks and applications are currently provided using software systems that typically use conventional cryptography and / or encryption techniques and protocols that are not sufficiently resilient enough to withstand an attack from such quantum computers (QCs).

[0003] Theory suggests that QCs can potentially crack many cryptograph protocols which rely on asymmetric algorithms such as RSA almost effortlessly. Research is producing Quantum Computers of increasing power and sophistication, allowing them to perform ever more complex tasks. Whilst Quantum Computers are not currently able to decrypt communications that rely upon asymmetric algorithms, these communications are susceptible to "store now, decrypt later" attacks.

[0004] The field of “Quantum Cryptography” aims to address these risks by developing secure key distribution methods, such as Quantum Key Distribution (QKD) techniques. However, even reliably performing QKD at scale for a wide range of users from small to large corporations and / or individuals is still a costly and time consuming exercise. QKD is a method that allows two distant parties to share symmetric cryptographic keys in an information theoretic secure manner that is guaranteed by the laws of physics. Various methods and protocols have been developed for QKD over optical fibres and through free space. The symmetric cryptographic keys may be used to encrypt data in transit or at rest in a secure manner.

[0005] In order to use symmetric cryptographic key based techniques, a common symmetric cryptographic key must be known at all involved cryptographic endpoints. Therefore, the cryptographic keys must either be preloaded at each endpoint or distributed during theoperating life of the cryptographic system. This is especially true for a system serving end users or devices. In systems where cryptographic keys are preloaded at each endpoint the operating life of each endpoint is limited by the number of preloaded cryptographic keys and the number of uses of each cryptographic key. Reuse of the same cryptographic key reduces the level of security provided, so that this approach tends to lead to a trade-off between the cost and complexity of preloading and storing a large number of cryptographic keys at each endpoint, the operating lifetime of each endpoint, and the number of times each cryptographic key is reused, potentially reducing the level of cryptographic security provided. Further, in examples where the cryptographic keys are distributed during the life or operation of the cryptographic system a common symmetric cryptographic key must be known at any Key Management system responsible for managing the security of the key distribution network carrying out the key distribution and each of the cryptographic endpoints served by the Key Management system, since the lifetime of the Key Management system is constrained by the number of uses of a cryptographic Key, because reuse of the same cryptographic key reduces the level of security provided, and the Key Management system may be compromised by a failure in the key storage. The management of symmetric cryptographic key material is challenging because it relies on the sharing of Highly-Entropic Strings that can only be known by the endpoints

[0006] There is a desire for a robust, secure and cost effective approach for carrying out key distribution, such as by QKD. However, it is difficult to ensure correct and reliable delivery of cryptographic keys to the different end users in a key distribution system such as a QKD system.

[0007] The embodiments described below are not limited to implementations which solve any or all of the disadvantages of the known approaches described above.Summary

[0008] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to determine the scope of the claimed subject matter; variants and alternative features which facilitate the working of the invention and / or serve to achieve a substantially similar technical effect should be considered as falling into the scope of the invention disclosed herein.

[0009] In a general sense, the present disclosure provides methods of operating a key management system, and a key management system for carrying out the methods, in which shared entropy generated between different nodes of the system is harvested and used togenerate encryption keys for internal use within the system, wherein the decision to harvest shared entropy and / or the amount of shared entropy harvested is based on the amount of encryption key material for internal use stored at at least one of the nodes.

[0010] In a first aspect of the present disclosure, there is provided a method of operating a key management system comprising at least two nodes arranged to generate shared entropy, the method comprising: the at least two nodes cooperating to generate shared entropy at the at least two nodes; at each of the at least two nodes: allocating a first portion of the generated shared entropy for internal use within the system and allocating a second portion of the generated shared entropy for external use, wherein the size of the first portion of the generated shared entropy allocated for internal use is based on the amount of shared symmetric encryption key material for internal use stored at at least one of the at least two nodes; using the first portion of the generated shared entropy to generate shared symmetric encryption keys for internal use; and storing the shared symmetric encryption keys for internal use.

[0011] In some embodiments, the size of the first portion of the generated shared entropy allocated for internal use is based on a comparison of the amount of shared symmetric encryption key material for internal use stored at at least one of the at least two nodes with a threshold value.

[0012] In some embodiments, the size of the first portion of the generated shared entropy allocated for internal use is based on a length of time that the amount of shared symmetric encryption key material for internal use stored at at least one of the at least two nodes is expected to last.

[0013] In a second aspect of the present disclosure, there is provided a method of operating a key management system comprising at least two nodes arranged to generate shared entropy, the method comprising: the at least two nodes cooperating to generate shared entropy at the at least two nodes; determining an amount of shared symmetric encryption key material for internal use within the system stored at at least one of the at least two nodes; and based on the determination, either: at each of the at least two nodes: allocating a first portion of the generated shared entropy for internal use within the system and allocating a second portion of the generated shared entropy for external use; and using the first portion of the generated shared entropy to generate shared symmetric encryption keys for internal use; and storing the shared symmetric encryption keys for internal use; or at each of the at least two nodes, allocating all of the generated shared entropy for external use.

[0014] In some embodiments, the determination is based on a comparison of the amount of shared symmetric encryption key material for internal use stored at at least one of the at least two nodes with a threshold value.

[0015] In some embodiments, the determination is based on a length of time that the amount of shared symmetric encryption key material for internal use stored at at least one of the at least two nodes is expected to last.

[0016] In some embodiments, the size of the first portion of the generated shared entropy allocated for internal use is based on the amount of shared symmetric encryption key material for internal use stored at at least one of the at least two nodes.

[0017] In some embodiments, internal use within the system comprises using the shared encryption keys for encryption and / or authentication between the at least two nodes.

[0018] In some embodiments, the method may further comprise using the stored shared symmetric encryption keys for communication and / or authentication between the at least two nodes.

[0019] In some embodiments, the shared symmetric encryption key material for internal use comprises shared symmetric encryption keys for internal use.

[0020] In some embodiments, the generated shared entropy comprises symmetric Highly- Entropic Strings.

[0021] In some embodiments, external use comprises use by end point devices for the purpose of cryptographic services.

[0022] In some embodiments, external use comprises providing symmetric encryption keys to end point devices.

[0023] In some embodiments, the at least two nodes use the second portion of the generated shared entropy to generate symmetric encryption keys for external use.

[0024] In some embodiments, the system provides the generated symmetric encryption keys to end point devices.

[0025] In some embodiments, each of the at least two nodes stores the shared symmetric encryption keys for internal use separately from any symmetric encryption keys for external use.

[0026] In some embodiments, the allocating a first portion of the generated shared entropy for internal use is carried out after key post processing of the shared entropy between the at least two nodes.

[0027] In some embodiments, wherein the allocating a first portion of the generated shared entropy for internal use is carried out before key post processing of the shared entropy between the at least two nodes, and the method further comprises: separately carrying out key post processing of the first portion of the generated shared entropy and key post processing of the second portion of the generated shared entropy.

[0028] In some embodiments, the at least two nodes comprise a quantum key distribution (QKD) transmitter and a QKD receiver.

[0029] In some embodiments, the at least two nodes comprise a QKD transmitter and at least two QKD receivers.

[0030] In some embodiments, said one of the at least two nodes sends a request for allocation of a first portion of the generated shared entropy for internal use to another one of the at least two nodes based on the amount of shared symmetric encryption key material for internal use stored at said one of the at least two nodes.

[0031] In some embodiments, the key management system further comprises a control node, and the control node sends a request for allocation of a first portion of the generated shared entropy for internal use to the at least two nodes based on the amount of shared symmetric encryption key material for internal use stored at least one of the at least two nodes.

[0032] In some embodiments, the key management system is a Quantum Key Agreement (QKA) system.

[0033] In some embodiments, the key management system is a Satellite Quantum Key Agreement (SQKA) system.

[0034] In some embodiments, the method is a computer implemented method.

[0035] In a third aspect of the present disclosure, there is provided a key management system comprising at least two nodes and arranged to carry out the method according to the first aspect or the second aspect.

[0036] In a fourth aspect of the present disclosure, there is provided a computer-readable medium comprising code or computer instructions stored thereon, which when executed by aprocessor, causes the processor to perform the computer-implemented method according to the first aspect or the second aspect.

[0037] In another aspect of the present disclosure, there is provided a method of operating a key management system comprising at least two nodes arranged to generate shared entropy, the method comprising: the at least two nodes cooperating to generate shared entropy at the at least two nodes; at each of the at least two nodes: allocating a first portion of the generated shared entropy for internal use within the system and allocating a second portion of the generated shared entropy for external use; using the first portion of the generated shared entropy to generate shared symmetric encryption keys for internal use; and storing the shared symmetric encryption keys for internal use, wherein each of the at least two nodes stores the shared symmetric encryption keys for internal use separately from any symmetric encryption keys for external use.

[0038] In another aspect of the present disclosure, there is provided a method of operating a key management system comprising at least two nodes arranged to generate shared entropy, the method comprising: the at least two nodes cooperating to generate shared entropy at the at least two nodes; at each of the at least two nodes: allocating a first portion of the generated shared entropy for internal use within the system and allocating a second portion of the generated shared entropy for external use; using the first portion of the generated shared entropy to generate shared symmetric encryption keys for internal use; and storing the shared symmetric encryption keys for internal use, wherein the allocating a first portion of the generated shared entropy for internal use is carried out before key post processing of the shared entropy between the at least two nodes.

[0039] In an fifth aspect of the present disclosure, there is provided a method of distributing symmetric highly-entropic material in a system comprising three or more nodes, the method comprising: defining a set of group IDs where each group ID corresponds to a different node or group of two or more nodes; assigning highly-entropic material a group ID corresponding to the current distribution of the material among the nodes; and when delivery of the material to a new node has been confirmed, changing the group ID to a new group ID corresponding to the new distribution of the material among the nodes

[0040] In some embodiments, the method further comprises organizing the highly-entropic material into data items, each data item comprising a set of one or more highly-entropic materials and a group ID.

[0041] In some embodiments, the highly entropic material comprises symmetric Highly- Entropic Strings.

[0042] In some embodiments, the method further comprises using the distributed highly- entropic material to generate encryption keys (also known as cryptographic keys).

[0043] In some embodiments, the method further comprises using the distributed highly- entropic material to support cryptographic services, such as encryption key based services.

[0044] In some embodiments, the system further comprises a system manager arranged to maintain a record of the highly entropic material together with the corresponding group IDs, and at least one agent arranged to deliver highly-entropic material to the nodes; wherein, when the at least one agent successfully delivers highly-entropic material to a node, the at least one agent informs the system manager of the corresponding change in the group ID of that highly entropic material; and the system manager updates the corresponding record accordingly.

[0045] In some embodiments, the set of group IDs further comprises a group ID corresponding to no node.

[0046] In some embodiments, the group IDs do not indicate the order in which the highly- entropic material was distributed to different nodes.

[0047] In some embodiments, at least some of the group IDs indicate the order in which the highly-entropic material was distributed to different nodes.

[0048] In some embodiments, each data item comprises the same amount of highly-entropic material.

[0049] In some embodiments, the system is a Quantum Key Agreement (QKA) system.

[0050] In some embodiments, the system is a Satellite Quantum Key Agreement (SQKA) system.

[0051] In some embodiments, the system is a Satellite Quantum Key Agreement (SQKA) system, each of the one or more agents is on a satellite, and the system manager and each node are at ground stations.

[0052] In some embodiments, the method is a computer implemented method.

[0053] In a sixth aspect of the present disclosure, there is provided a key management system comprising at least three nodes and arranged to carry out the method according to the fifth aspect.

[0054] In a seventh aspect of the present disclosure, there is provided a computer-readable medium comprising code or computer instructions stored thereon, which, when executed by a processor unit, causes the processor unit to perform the computer-implemented method according to the sixth aspect.

[0055] In an eighth aspect of the present disclosure, there is provided a method of managing data items in a system comprising a plurality of agents and a system manager, the method comprising: an agent of the plurality of agents having a request to carry out a session with one or more data items of the plurality of data items; the system manager checking whether the one or more data items have a stored affinity with an agent in a data store; if the one or more data items have a stored affinity with the agent of the plurality of agents having the request, the system manager instructing the agent to carry out the request; or if the one or more data items have no stored affinity with an agent, the system manager instructing the agent of the plurality of agents having the request to carry out the request, and storing an affinity with that agent for the one or more data items in a data store; or if the one or more data items have a stored affinity with another agent of the plurality of agents than the agent of the plurality of agents having the request, the system manager instructing the agent to not carry out the request.

[0056] In some embodiments, the session comprises modification of the one or more data items by the agent.

[0057] In some embodiments, the session comprises deletion of the one or more data items by the agent.

[0058] In some embodiments, if the system manager instructs the agent to carry out the request the system manager records in association the agent, a session ID, a data store, and identities of the one or more data items that have been modified.

[0059] In some embodiments, the session comprises reading of the one or more data items by the agent.

[0060] In some embodiments, if the system manager instructs the agent to carry out the request the system manager records in association the agent, a session ID, a data store, and identities of the one or more data items that have been read.

[0061] In some embodiments, the method further comprises a data item creation method comprising: an agent of the plurality of agents having a request to create one or more data items in a data item creation session; the system manager selecting a data store for the created one or more data items and assigning a session ID to the data item creation session;the agent creating the data items, writing the created data items into the selected data store, and attaching the assigned session ID to the created data items; and the system manager recording in association the agent, a session ID, the data store and the identities of the one or more created data items, and storing an affinity with the creating agent for the one or more created data items in a data store.

[0062] In some embodiments, the method further comprises a data item synchronization method comprising: the system manager making a determination to synchronize one or more sessions; the system manager identifying the agent of the plurality of agents having a stored affinity with the one or more data items associated with the one or more sessions; the system manager creating a session command to synchronise the one or more sessions; the system manager sending the session command to each agent of the plurality of agents having or requiring an instance of the one or more data items associated with the one or more sessions; each agent receiving a session command synchronising the one or more sessions and then sending confirmation that this has been done to the system manager; the system manager, after receiving confirmations from all of the commanded agents, deleting the stored affinity of the one or more data items associated with the one or more sessions with the agent of the plurality of agents.

[0063] In some embodiments, no session command is sent to the agent of the plurality of agents.

[0064] In some embodiments, the synchronising comprises creating, modifying or deleting an instance of the one or more data items.

[0065] In some embodiments, the one or more data items comprise Highly-Entropic material.

[0066] In some embodiments, the one or more data items comprise symmetric Highly-Entropic Strings.

[0067] In some embodiments, the system is a key distribution system.

[0068] In some embodiments, the system is a Quantum Key Agreement (QKA) system.

[0069] In some embodiments, the system is a Satellite Quantum Key Agreement (SQKA) system.

[0070] In some embodiments, preceding claim, wherein the method is a computer implemented method.

[0071] In a ninth aspect of the present disclosure, there is provided a key management system comprising a system manager and at least two nodes and arranged to carry out the method according to the eighth aspect.

[0072] In a tenth aspect of the present disclosure, there is provided a computer-readable medium comprising code or computer instructions stored thereon, which, when executed by a processor unit, causes the processor unit to perform the computer-implemented method according to the eighth aspect.

[0073] In a eleventh aspect of the present disclosure, there is provided a method of producing symmetric keys in a key management system comprising a plurality of nodes, the method comprising, at a node: obtaining shared highly-entropic string and storing the shared highly-entropic string in a buffer store of the node; obtaining a key recipe and storing the recipe in a key recipe store of the node; receiving a request for one or more symmetric formatted keys, and, in response to the request: using stored shared highly-entropic string from the buffer store to generate one or more symmetric formatted keys by applying a key recipe from the key recipe store; and providing the generated one or more symmetric formatted keys.

[0074] In some embodiments, the request is received from an end user device, and the generated one or more symmetric formatted keys are provided to the requesting end user device.

[0075] In some embodiments, the obtaining shared highly-entropic string comprises receiving or creating the shared highly-entropic string.

[0076] In some embodiments, the obtaining a key recipe comprises agreeing or receiving the key recipe.

[0077] In some embodiments, each key recipe comprises: an ID for formatted keys to be generated; a size of the formatted keys to be generated; identities of end nodes at which the formatted keys are to be generated; portion(s) of highly-entropic strings to be used to generate the formatted keys; the method to be used to generate the formatted keys.

[0078] In some embodiments, the system is a Quantum Key Agreement (QKA) system.

[0079] In some embodiments, the system is a Satellite Quantum Key Agreement (SQKA) system.

[0080] In some embodiments, the method is a computer implemented method.

[0081] In a twelfth aspect of the present disclosure, there is provided a key management system comprising a system manager and at least two nodes and arranged to carry out the method according to the eleventh aspect.

[0082] In a thirteenth aspect of the present disclosure, there is provided a computer- readable medium comprising code or computer instructions stored thereon, which, when executed by a processor unit, causes the processor unit to perform the computer- implemented method according to the eleventh aspect.

[0083] The methods described herein may be performed by software in machine readable form on a tangible storage medium e.g. in the form of a computer program comprising computer program code means adapted to perform all the steps of any of the methods described herein when the program is run on a computer and where the computer program may be embodied on a computer readable medium. Examples of tangible (or non-transitory) storage media include disks, thumb drives, memory cards etc. and do not include propagated signals. The software can be suitable for execution on a parallel processor or a serial processor such that the method steps may be carried out in any suitable order, or simultaneously.

[0084] This application acknowledges that firmware and software can be valuable, separately tradable commodities. It is intended to encompass software, which runs on or controls “dumb” or standard hardware, to carry out the desired functions. It is also intended to encompass software which “describes” or defines the configuration of hardware, such as HDL (hardware description language) software, as is used for designing silicon chips, or for configuring universal programmable chips, to carry out desired functions.

[0085] The preferred features may be combined as appropriate, as would be apparent to a skilled person, and may be combined with any of the aspects of the invention.Brief Description of the Drawings

[0086] Embodiments of the invention will be described, by way of example, with reference to the following drawings, in which:

[0087] Figure 1 is a schematic diagram illustrating an example of a quantum key distribution system useable in the present invention;

[0088] Figure 2 is a diagram illustrating a method of quantum key distribution useable by the system of figure 1 ;

[0089] Figure 3 is a schematic diagram illustrating a key management system according to a first embodiment;

[0090] Figure 4 is a schematic diagram illustrating a quantum key agreement system which may be a part of the key management system of figure 3;

[0091] Figure 5 illustrates a key harvesting method useable in the system of figures 3 and 4;

[0092] Figure 6 illustrates a determining method which may optionally be used with the method of figure 5;

[0093] Figure 7 is a schematic diagram illustrating a key management system manager according to a second embodiment;

[0094] Figure 8 is a schematic diagram illustrating a key management system according to a second embodiment;

[0095] Figure 9 illustrates a data item generation method useable in the system of figure 8;

[0096] Figure 10 illustrates a data item useable in the system of figure 8;

[0097] Figure 11 illustrates a distribution method useable in the system of figure 8;

[0098] Figure 12 is an overview illustrating a data item access session method useable by a key management system according to a third embodiment;

[0099] Figure 13 illustrates a data item modification method useable by a key management system according to a third embodiment;

[0100] Figure 14 illustrates a data item reading method useable by a key management system according to a third embodiment;

[0101] Figure 15 illustrates a data item creation method useable by a key management system according to a third embodiment;

[0102] Figure 16 illustrates a synchronization method useable by a key management system according to a third embodiment;

[0103] Figure 17 is a schematic diagram illustrating a part of a key management system according to a fourth embodiment; and

[0104] Figure 18 illustrates a key formatting method useable by a key management system according to the fourth embodiment.

[0105] Common reference numerals are used throughout the figures to indicate similar features.Detailed Description

[0106] Embodiments of the present invention are described below by way of example only. These examples represent the best mode of putting the invention into practice that are currently known to the Applicant although they are not the only ways in which this could be achieved. The description sets forth the functions of the example and the sequence of steps for constructing and operating the example. However, the same or equivalent functions and sequences may be accomplished by different examples.

[0107] In overview, the present application relates to methods and processes to make the overall operation, key management and key distribution more efficient and effective using the stored shared symmetric encryption keys for communication and / or authentication between the at least two nodes in a symmetric key management system. The present application may be used for secure key distribution to provide encryption keys in a system comprising multiple endpoint devices, for example in Quantum Key Distribution (QKD) to provide encryption keys in a wider symmetric Quantum Key Agreement (QKA) system, comprising multiple end point devices.

[0108] Figure 1 is a schematic diagram illustrating an example of a simple quantum key distribution (QKD) system 100 which may be used in the present invention, while figure 2 shows a method 200 used by the QKD system 100. Quantum Key Distribution (QKD) is a process for generating symmetric Highly-Entropic material in an information theoretic secure manner between two nodes. However, the present invention is not limited to the use of QKD, and may use other methods for generating symmetric Highly-Entropic material in a secure manner, and in particular in an information theoretic secure manner, between different nodes.

[0109] QKD is one method allowing two parties, or nodes, to generate symmetric Highly- Entropic material in an information theoretic secure manner that is guaranteed by the laws of physics. Various methods and protocols have been developed for QKD over fibre and through free space, and using other sources of entropy, such as Quantum Random Number Generators (QRNGs). Figures 1 and 2 illustrate a simple example of a prepare and measure QKD protocol.

[0110] The QKD system 100 comprises a QKD transmitter 102 and a QKD receiver 104. The method 200 begins by the QKD transmitter 102 using a quantum encoder 106 to encode a variable into quantum states in an encoding block 202. The encoded variable may be a quantum variable or a classical (non-quantum) variable. For example, the encoded variablemay a random number output from a Quantum Random Number Generator (QRNG) or a Random Number Generator (RNG).

[0111] Then, in a transmitting block 204, the QKD transmitter 102 transmits a signal comprising the encoded quantum states over a quantum channel 108. The quantum channel 108 may be optical. In a receiving block 206, the QKD receiver 104 receives the signal comprising the encoded quantum states through the quantum channel 108.

[0112] Then, in a measuring block 208, the QKD receiver 104 uses a measuring unit 110 to measure the received signal using randomly selected bases.

[0113] Finally, in a key post processing block 210, the QKD transmitter 102 and the QKD receiver 104 use a classical (that is, non-quantum) communication channel 112 to conduct key post processing to generate a mutually agreed secure Highly-Entropic String which is shared by the QKD transmitter 102 and the QKD receiver 104. By the highly-entropic string being shared by the QKD transmitter 102 and the QKD receiver 104, it is meant that the highly-entropic string is duplicated at the QKD transmitter 102 and the QKD receiver 104, that is, the QKD transmitter 102 and the QKD receiver 104 have identical copies of the highly- entropic string. The key post processing may, for example, comprise sifting, error correction and privacy amplification steps. A highly-entropic string, which may also be referred to as highly-entropic material, is an information theoretic secure String of bits with high entropy. As is explained herein, this highly-entropic material may be generated through QKD, and after generation, may shared to multiple places within a system.

[0114] The highly-entropic string or material is referred to as highly-entropic because the "bit entropy" or "entropy per bit" of the string or material is high. The entropy per bit of data is a measure of the predictability of the data. If, given full knowledge of all historical bits that have been generated, a user is unable to predict the next generated bit and if there is an equal chance of this bit being a 1 or a 0. Then there is effectively 1 bit of entropy per bit of data. String or material having 1 bit, or close to one bit, of entropy per bit of data is regarded as highly-entropic. In contrast, if a user is able to predict the next bit in the sequence this may indicate that the sequence has low entropy, for example if the system is more likely to generate 1 than 0 as the next bit in the ratio of 9 to 1 , then the system can be said to have 0.1 entropy per bit of data, this would be low-entropy system. Accordingly, the string or material being highly entropic can be quantified with respect to the randomness and distribution of the generated data values making up the string or material.

[0115] The QKD system may form a part of a key management system, and the symmetric Highly-Entropic strings produced by the QKD system and method may be delivered to end users in a form (such as cryptographic Keys) that can be used or consumed by end pointdevices for the purpose of cryptographic services, and may also be harvested for use by the key management system as part of the internal operations of the key management system itself.

[0116] The QKD system and method of figures 1 and 2 is an example of a suitable method for generating symmetric Highly-Entropic material which may be used in the present invention. However, the use of QKD is not essential, and the present invention may be used with other methods of generating shared entropy between different nodes.

[0117] Figure 3 shows a schematic diagram of an example of a symmetric key management system 300 according to an embodiment of the present invention. The key management system 300 manages the generation, distribution, and use of symmetric Key material to different nodes, and / or the generation, distribution, and use of any Highly-Entropic material to be shared for the generation of symmetric Keys.

[0118] The overall function of the key management system 300 is to deliver symmetric keys, which are typically symmetric encryption keys, to a plurality of user end point devices 302, in the illustrated example 302a to 302n, for use by the end point devices 302 in encryption functions outside the key management system 300 itself. In the illustrated example of figure 3 the end point devices 302 are connected by a number of end user networks indicated generally as 304. The end user networks 304 may have any required configuration and arrangement. It will be understood that the function of the illustrated key management system 300 is the delivery of symmetric encryption keys to end point devices 302, and that the key management system 300 is not involved in the subsequent use of the delivered symmetric encryption keys to provide encryption services, such as secure communications, between the end point devices 302 through the end user networks 304.

[0119] The key management system 300 comprises a system manager 306, which controls and governs the operation of the key management system 300, coordinating the operation of the other system elements. The key management system 300 further comprises one or more key agreement agents 308, in the illustrated example 308a to 308m, which serve to generate and / or distribute symmetric Highly-Entropic String material for both internal functions of the key management system 300 and user functions by the end point devices 302 through the end user networks 304. The key management system 300 further comprises one or more key agreement nodes 310, in the illustrated example 310a to 31 Op, which act as interfaces with the end point devices 302, providing symmetric keys to these end point devices 302. The key agreement nodes 310 act as access points for the end point devices 302 and their users to access the key management system 300. A symmetric key, also referred to herein as a "key" is a cryptographic key that may be used for encryption, decryption and authentication ofinformation, among other uses. Each key comprises a ‘payload’ - the shared secret used for the cryptographic functions, and the ‘metadata’ - the ancillary data that describes the properties, to support the management and use of the key.

[0120] In operation of the key management system 300, each of the key agreement agents 308 cooperates with one the key agreement nodes 310 to carry out a QKD process and generate symmetric Highly-Entropic Strings shared by that key agreement agent 308 and that key agreement node 310 in an information theoretic secure process. The QKD process is repeated between different ones of the key agreement agents 308 and key agreement nodes 310 as necessary to provide a required amount of symmetric Highly-Entropic Strings at the key agreement agents 308 and key agreement nodes 310. Further, the key agreement agents 308 are arranged to use the symmetric Highly-Entropic Strings at different ones of the key agreement nodes 310 in order to generate symmetric Highly-Entropic Strings shared by these different key agreement nodes 310. In the illustrated embodiment a QKD process is used to generate symmetric Highly-Entropic Strings shared by a key agreement agent 308 and a key agreement node 310. However, this is not essential. In other examples an alternative process which is not QKD could be used to generate symmetric Highly-Entropic Strings shared by a key agreement agent 308 and a key agreement node 310. Also, although the generation of highly-entropic strings is convenient, it is not essential, and in some examples the generated symmetric Highly-Entropic material shared by a key agreement agent 308 and a key agreement node 310 may take a form other than strings.

[0121] The key agreement agents 308 and the key agreement nodes 302 cooperate under the control of the system manager 306 to carry out Quantum Key Agreement (QKA). Quantum key agreement (QKA) is a concept that uses QKD between a number of nodes in a system, to allow for the sharing of symmetric Highly-Entropic material over a wider Key management system. In the key management system 300 of figure 3, the QKD between the key agreement agents 308 and the key agreement nodes 302 is the basis for the sharing of symmetric Highly-Entropic material over the Key management system 300 as a whole. In the illustrated embodiment QKA is carried out using QKD for the sharing of symmetric Highly- Entropic material over a wider Key management system. This is not essential. In other examples an alternative process could be used for the sharing of symmetric Highly-Entropic material over the wider Key management system.

[0122] The symmetric keys provided to the end point devices 302 may be used to support cryptographic services between different end point devices 302 and the users associated with the end point devices 302, such as encryption key based services. One example of such an encryption key based cryptographic service is encrypted communications, where the encryption keys may be used to encrypt transmissions over a conventional communicationchannel (e.g. a phone line, an internet connection, a radio frequency transmission, a fibre optic network, a private or proprietary secure network, such as a network using the Arqit secure communications methodology, etc.) between different users / end point devices 302 in order to maintain confidentiality of the communications. Other examples of encryption key based cryptographic services include other security related services such as confidentiality, data integrity, data / message origin authentication, entity identification, and non-repudiation. This list is not intended to be exhaustive. Other encryption key based services may be supported in some examples.

[0123] The illustrated example of figure 3 is provided by way of example only, and the specific number and composition of the parts of the symmetric Key Management system 300 are not essential. For example, the key management system 300 may have a single or multiple System Manager and / or Key Agreement Agent. Additionally, the implementation may have each element clearly separated, or entities may have overlapping functions or multiple roles. In particular, although the illustrated example of figure 3 comprises a single system manager 306, three key agreement agents 308, four key agreement nodes 310, and seven end point devices 302, these numbers are not essential, and are used by way of example only. In practice, the key management system 300 may provide symmetric keys to a very large number of end point devices 302.

[0124] The key management system 300 may be regarded as functioning as two subsystems, a User Key Management system (UKMS), including the functions and components supporting Key delivery to the end point devices 302 for use externally to the system 300, and an Internal Key Management system (IKMS), including the functions and components supporting Internal system security which itself is required to ensure security of keys delivered to the end point devices 302 by the key management system 300. This division into two subsystems relates to the functionality provided and does not require that separate components are used to provide two physically separate sub-systems, the various parts of the symmetric Key Management system 300 set out above generally support the functionality of both subsystems.

[0125] The key management system 300 enables the generating and sharing of symmetric Key material amongst pairs and groups of key agreement agents 308 and key agreement nodes 310. Each key agreement agent 308 and key agreement node 310 may be regarded as a Node of the system 300. These Nodes consume symmetric Highly-Entropic material, either externally to provide the end point devices 302 with Keys for use in external cryptographic operations, or, as will be explained in more detail below, internally for security of the system 300 elements and resources.

[0126] The key management system 300 may operate according to a variety of specific generation and distribution mechanics. In the illustrated example, the key management system 300 operates as a Quantum Key Agreement (QKA) system. The key agreement nodes 310 form a group, and are served by the key agreement agents 308, which may be regarded as QKD agents, in order to generate symmetrical Highly-Entropic Strings at the key agreement agents 308 and the key agreement nodes 310 in an information theoretic secure process. Typically, each instance of a process to generate symmetrical Highly-Entropic Strings is carried out between a key agreement agent 308 and a key agreement node 310. Further, in the illustrated example, different ones of the key agreement agents 308 can cooperate with different key agreement nodes 310 to generate symmetrical Highly-Entropic Strings, as indicated by the illustrated interconnections between the key agreement agents 308 and key agreement nodes 310. It will be understood that the key management system 300 may use any suitable method to generate symmetrical Highly-Entropic Strings between key agreement agents 308 and key agreement nodes 310. A number of such methods are known.

[0127] Further, in the illustrated example, different ones of the key agreement agents 308 can cooperate with different groups of multiple key agreement nodes 310 to use symmetrical Highly-Entropic Strings at the key agreement agent 308 and the multiple key agreement nodes 310 to generate symmetrical Highly-Entropic Strings shared between the group of key agreement nodes 310. It will be understood that the key management system 300 may use any suitable method to generate symmetrical Highly-Entropic Strings between groups of key agreement nodes 310. A number of such methods are known.

[0128] As discussed above, the illustrated example of figure 3 is by way of example only and the key management system 300 may have different numbers of parts. The minimum requirement for the key management system 300 to operate as a QKA system would be for the system 300 to have two Nodes, for example with the two nodes being a key agreement agent 308 and a key agreement node 310, one acting as a QKD Transmitter sending photons to the other acting as a QKD Receiver. This minimum amount can be extensible to any size of key management system 300 acting as a QKA system, with any number of key agreement agents 308 and key agreement nodes 310 acting as QKD Transmitters and QKD Receivers. More complex systems may have multiple Nodes served by single QKD Transmitters or Receivers. It will be understood that the larger and more complex the key management system 300 is, and the greater the number of key agreement agents 308 and key agreement nodes 310 it comprises, the more complex the requirements for the system manager 306 to control the other parts of the system 300 will be.

[0129] The symmetric Key Management system 300 may be implemented in various ways depending upon the requirements for generating and sharing symmetric Key material amongst pairs and groups of Nodes in any specific implementation.

[0130] The present disclosure is agnostic of the specific generation and distribution mechanics used in the key management system 300. However, as an illustrative example, the key management system 300 may operate as a satellite quantum key agreement (SQKA) system. Satellite quantum key agreement (SQKA) is a specific implementation of a QKA system that uses a number of satellites to provide global or near-global coverage. This may be beneficial for generating and agreeing symmetric Keys to Nodes over a large geospatial area. Where the key management system 300 operates as an SQKA system, a typical implementation might be a ground station acting as a centralised System manager 306, commanding one or more Satellites (acting as Key Agreement Agents 308), to deliver to a global network of Ground Terminals (acting as Key Agreement Nodes 310), which serve the user end points devices 302 with symmetric Key material on demand. In alternative examples the key management system 300 may operate as a terrestrial QKA system, with all of the parts of the system 300 communicatively connected by terrestrial means, for example by optical fibres.

[0131] In general terms, in a first aspect, the present disclosure provides a method of key harvesting to provide symmetric encryption keys which can be used for encryption and authentication within a key management system, such as, for example, the key management system 300. The Nodes of the key management system 300 require symmetric encryption keys, for example, for authentication and / or encryption of messages exchanged during link establishment and Key Post Processing (KPP), and possibly for other purposes. This key harvesting may be understood as a process of siphoning off or separating out a portion of Highly-Entropic material generated so that it can be used for authentication and encryption between Nodes of the key management system 300.

[0132] The disclosed method of key harvesting may be applied to any Key Management system using shared entropy, such as symmetric Highly-Entropic Strings, to secure internal cryptographic endpoints and functions, and provide Key data to any number of end users / devices.

[0133] As is discussed above, the minimum requirement for a QKA system is two Nodes, comprising a QKD transmitter and a QKD receiver, and more complex QKA systems comprise larger numbers of such Nodes.

[0134] Figure 4 shows a more detailed schematic illustration of a QKA system 400, which may be a minimal QKA system in its own right, or a part of the key management system 300.The QKA system 400 of figure 4 comprises a QKD transmitter 402 and a QKD receiver 404. As shown in figure 4, there may be one or more QKD receivers 404 associated with the QKD transmitter 402. The QKA system 400 of figure 4 may be a part of the key management system 300 of figure 3, where the QKD transmitter 402 is one of the key agreement agents 308, and each of the one or more QKD receivers 404 is one of the key agreement nodes 310. However, this is only one possible specific implementation of the key management system 300.

[0135] As shown in figure 4, the QKD transmitter 402 is connected to the QKD receiver 404 by a quantum communication channel 406 and a classical (non-quantum) bidirectional communication channel 408.

[0136] The QKD transmitter 402 comprises an optical source and quantum encoding unit 410, a post-processing unit 412, a temporary key store 414 and an internal key store 416. The post- process I ng unit 412 comprises a key post processing (KPP) module 418 and a classical (non-quantum) communications transceiver 420.

[0137] The QKD receiver 404 comprises an optical receiver and photon detector unit 422, a post-processing unit 424, a user key store 426 and an internal key store 428. The postprocessing unit 424 comprises a key post processing (KPP) module 430 and a classical (non- quantum) communications transceiver 432.

[0138] In operation, the QKD transmitter 402 uses the optical source and quantum encoding unit 410 to encode a classical (that is, non-quantum) variable into optical quantum states and transmits the optical quantum states, typically as single photons, along the quantum communications channel 406 to the optical receiver and photon detector unit 422 of the QKD receiver 404. The quantum communications channel 406 is provided between the optical source and quantum encoding unit 410 and the optical receiver and photon detector unit 422. The optical source and quantum encoding unit 410 also provides the transmitted quantum states to the post-processing unit 418. The QKD transmitter 402 and the QKD receiver 404 can use any known QKD protocol, for example a Prepare and Measure QKD Protocol, such as the BB-82 protocol. Other protocols may be used in alternative examples.

[0139] The optical receiver and photon detector unit 422 of the QKD receiver 404 receives the encoded optical quantum states through the quantum channel 108, measures the received signal using randomly selected bases, and provides the results of the measurement to the post- process I ng unit 424.

[0140] In exemplary implementations where the QKA system 400 is an SQKA system, the quantum communications channel 406 may be a free space optical path between a satellitebased QKD transmitter 402 and a ground based QKD receiver 404, or vice-versa. In exemplary implementations where the QKA system 400 is a terrestrial fiber based QKA system, the quantum communications channel 406 may be an optical fiber connecting a QKD transmitter 402 and a QKD receiver 404. In other examples of QKA systems alternative forms of quantum communications channel 406 may be used.

[0141] The KPP module 418 of the QKD transmitter 402 and KPP module 430 of the QKD receiver 404 then use the classical communications transceiver 420 and the classical communications transceiver 432 connected through the classical communication channel 408 to conduct key post processing to agree symmetric Highly-Entropic Strings at the QKD transmitter 402 and the QKD receiver 404. Key post processing (KPP) is a process used in a QKD protocol to agree Highly-Entropic strings at both end points, involving key sifting, error correction, parameter estimation and privacy amplification.

[0142] The agreed Highly-Entropic strings at the QKD transmitter 402 and the QKD receiver 404 are then used to generate symmetric encryption keys. Any known method of generating symmetric encryption keys from highly-entropic strings may be used, as convenient in any specific implementation. The QKD receiver 404 stores the generated symmetric encryption keys in a user key store 426 for subsequent issue 434 to user end point devices 302. The QKD transmitter 402 stores the generated symmetric encryption keys in a temporary key store 414 for subsequent use and distribution.

[0143] In order to provide security to the classical communication channel 408 the QKD transmitter 402 and the QKD receiver 404 have corresponding symmetric encryption keys stored in the respective internal key stores 416 and 428. These symmetric encryption keys are used to enable KPP for authentication and encryption across the classical communication channel 408. The symmetric encryption keys stored in the respective internal key stores 416 and 428 may also be used for other purposes within the QKA system 400 as required. The QKD transmitter 402, which may be one of the key agreement agents 308 of the key management system 300 of figure 3, the QKD receivers 404, which may be key agreement nodes 310 of the key management system 300 of figure 3, use Symmetric Keys, for example, for authentication and / or encryption of messages exchanged during link establishment and Key Post Processing (KPP). Thus, the symmetric encryption keys intended for internal use in the internal key stores 416 and 428 are stored separately from the symmetric encryption keys in the user key store 426 and temporary key store 414 for issue to user end point devices 302.

[0144] According to a first embodiment of the present invention, key harvesting 440 is carried out by the KPP module 418 of the QKD transmitter 402 to provide symmetricencryption keys which are stored in the internal key store 416. Similarly, key harvesting 442 is carried out by the KPP module 430 of the QKD receiver 404 to provide corresponding symmetric encryption keys which are stored in the internal key store 428. Accordingly, during operation of the QKA system 400, the internal key stores 416 and 428 are provided with harvested symmetric encryption keys to replace those used in the operation of the QKA system 400, such as for authentication and encryption.

[0145] In order to allow the QKD process to be carried out when the QKA system 400 first begins operating, the QKD transmitter 402 and QKD receiver 404 are pre-stocked with a supply of symmetric encryption keys which are stored in the internal key stores 416 and 428. This initial supply of keys can be used to perform KPP between the QKD transmitter 402 and the QKD receiver 404 for the first QKD session or sessions, and restocked with harvested keys in operation as required, based on the amount of shared encryption keys which are stored in the internal key stores 416 and 428.

[0146] Conventionally, the QKD transmitter 402 and QKD receiver 404 would be provided with a pre-loaded store of symmetric encryption keys in their respective internal key stores, which stock would have to last for the operating life of the QKD transmitter 402 and QKD receiver 404, or be periodically replenished by some external process. Accordingly, the use of key harvesting allows the requirement for pre-loading of keys to be greatly reduced, and / or the operating life of the QKD transmitter 402 and QKD receiver 404 to be greatly extended, both without reducing the security of the QKA system 400 by increasing re-use of keys. Further, any requirement for an external process to provide additional keys to replenish the stock of keys can be avoided.

[0147] In examples where the QKA system 400 of figure 4 is a part of a more complex and extensive key management system 300 as shown in figure 3, the different QKD transmitters 402 and QKD receivers 404, that is, the different key agreement agents 308 and key agreement nodes 310 may also cooperate to generate symmetrical Highly-Entropic Strings shared between groups of key agreement nodes 310.

[0148] Further, the different QKD transmitters 402 and QKD receivers 404, that is, the different key agreement agents 308 and key agreement nodes 310 may also distribute the harvested symmetric encryption keys in their internal key stores to other parts of the QKA system 300, and use these harvested symmetric encryption keys to carry out authenticated and encrypted communication with other parts of the QKA system 300.

[0149] In the illustrated embodiment of figure 4 the QKD transmitter 402 and the QKD receiver 404 comprise an optical source and an optical receiver and photon detecting unit respectively, and accordingly the quantum communication channel 406 is an opticalcommunication channel carrying optical quantum states. This is not essential. In other examples the QKD transmitter 402, the QKD receiver 404, and the quantum communication channel 406 may not be optical, and may instead comprise a non-optical mechanism for sharing information securely between the QKD transmitter 402 and the QKD receiver 404.

[0150] In the illustrated embodiment of figure 4 a QKD process is used to generate highly- entropic strings. However, this is not essential. Although the generation of highly-entropic strings is convenient, it is not essential, and in some examples the generated highly-entropic material shared by the QKD transmitter 402 and the QKD receiver 404 may take a form other than strings. Further, in other examples an alternative process which is not QKD could be used to generate highly entropic material, such as highly-entropic strings, shared by the transmitter 402 and the receiver 404. It will be understood that in such examples the transmitter 402 and receiver 404 will no longer be a "QKD" transmitter and receiver.

[0151] Figure 5 shows a schematic diagram of an example of a method 500 of key harvesting which may be used in the key management system 300 according to a first embodiment. The method 500 of key harvesting may, for example, be used to carry out the key harvesting 440 discussed above to provide symmetric encryption keys which are stored in the internal key store 416 in the example of figure 4.

[0152] In the illustrated example of figure 5, the key harvesting is caried out by a QKD transmitter 402 and two QKD receivers 404a and 404b. The QKD transmitter may be a key agreement agent 308 of the key management system 300, while the QKD receivers 404a and 404b may be key agreement nodes 310.

[0153] In a first generate entropy step 502 the QKD transmitter 402 cooperates with a first QKD receiver 404a of the two QKD receivers 404a and 404b to generate first shared entropy KAshared between the QKD transmitter 402 and the first QKD receiver 404a. This first shared entropy KAmay take the form of symmetric Highly-Entropic Strings shared by the QKD transmitter 402 and the first QKD receiver 404a. The first shared entropy KA is stored in the temporary key store 414 of the QKD transmitter 402 and the internal key store 428 of the first QKD receiver 404a.

[0154] In the illustrated example of figure 5, the process used to generate shared entropy may be a known Prepare & Measure QKD protocol, for example as discussed above, which transfers encoded photons over the quantum communications channel 406. After this exchange of raw data, post-processing steps are carried out to agree photon receipt (sifting) then perform error correction, parameter estimation, and privacy amplification to generate symmetric Highly-Entropic Strings at both ends of the quantum communications channel 406. This process requires messaging over the classical communication channel 408, and requiresthe use of pre-established symmetric keys at the transmitter and receiver ends, for mutual authentication and / or Integrity protection of data exchanges.

[0155] Then, in a first harvest entropy step 504, each of the QKD transmitter 402 and the first QKD receiver 404a allocates or selects a first, internal entropy, portion KAI of the first shared entropy KAfor internal use and a second, external entropy, portion KAu of the first shared entropy K^for use to generate user keys, or to provide other services. The QKD transmitter 402 and the first QKD receiver 404a determine the size of the selected first, internal entropy, portion KAI based on the amount of shared symmetric encryption keys for internal use stored at at least one of the QKD transmitter 402 and the first QKD receiver 404a. Conveniently, the second, external entropy, portion KAu of the first shared entropy KAcan comprise the remainder of the first shared entropy KAwhich has not been selected as the first, internal entropy, portion KAI. It will be understood that the terms "first" and "second" portion are used only as nomenclature to distinguish between the different portions, and do not indicate the order of the first portion and the second portion. That is, it is not necessary that the first portion must be a part of the first shared entropy which is produced before the second portion. The first portion and the second portion may be selected or allocated from the first shared entropy in any desired manner, as convenient in any specific implementation.

[0156] In a second generate entropy step 506 the QKD transmitter 402 cooperates with a second QKD receiver 404b of the two QKD receivers 404a and 404b to generate second shared entropy KBshared between the QKD transmitter 402 and the second QKD receiver 404b. This second shared entropy KBmay take the form of symmetric Highly-Entropic Strings shared by the QKD transmitter 402 and the second QKD receiver 404b. The second shared entropy KBis stored in the temporary key store 414 of the QKD transmitter 402 and the internal key store 428 of the second QKD receiver 404b. In the illustrated embodiment the second shared entropy KBhas the same size as the first shared entropy KAFor example, the same quantity of symmetric Highly-Entropic Strings.

[0157] Then, in a second harvest entropy step 508, each of the QKD transmitter 402 and the second QKD receiver 404b allocates or selects a first, internal entropy, portion KBI of the second shared entropy KBfor internal use and a second, external entropy, portion KBu of the second shared entropy KBfor use to generate user keys, or to provide other services. The QKD transmitter 402 and the second QKD receiver 404b determine the size of the selected first, internal entropy, portion KBI based on the amount of shared symmetric encryption keys for internal use stored at at least one of the QKD transmitter 402 and the second QKD receiver 404b. Conveniently, the second, external entropy, portion KBUof the second shared entropy KBcan comprise the remainder of the second shared entropy KBwhich has not been selected as the first, internal entropy, portion KBI. In the illustrated embodiment the selectedfirst, internal entropy, portions KAI and KBI have the same size and the selected second, external entropy, portions KAU and KBU have the same size. It will be understood that the terms "first" and "second" portion are used only as nomenclature to distinguish between the different portions, and do not indicate the order of the first portion and the second portion. That is, it is not necessary that the first portion must be a part of the second shared entropy which is produced before the second portion. The first portion and the second portion may be selected or allocated from the second shared entropy in any desired manner, as convenient in any specific implementation.

[0158] Then, in a transfer entropy step 510, the QKD transmitter 402 and the first and second QKD receivers 404a and 404b cooperate to use the second portion KAU of the first shared entropy KAand the second portion KBu of the second shared entropy KBto distribute shared entropy to the first and second QKD receivers 404a and 404b. In the illustrated example of figure 5, this is carried out by the QKD transmitter 402 XORing the second portion KAU of the first shared entropy KAand the second portion KBUof the second shared entropy KB, and sending the result to the second QKD receiver 404b. the QKD transmitter 402 then deletes the second portion KAU of the first shared entropy KAand the second portion KBUof the second shared entropy KBfrom the temporary key store 414. The second QKD receiver 404b then XORs the received results with the second portion KBU of the second shared entropy Ks, to recover the second portion KAU of the first shared entropy KA, so that the first and second QKD receivers 404a and 404b share the second portion KAU of the first shared entropy KA, and the second portion KAU of the first shared entropy KAis no longer stored by the QKD transmitter 402.

[0159] Accordingly, following the method 500 of figure 5, the first and second QKD receivers 404a and 404b share the same entropy bits KAU, while the entropy bits KAI are shared by the QKD transmitter 402 and the first QKD receiver 404a, and the entropy bits KBI are shared by the QKD transmitter 402 and the second QKD receiver 404b.

[0160] The first and second QKD receivers 404a and 404b can then use their shared entropy, in the illustrated example of figure 5 the second portion KAU of the first shared entropy KA, to generate symmetric encryption keys for distribution to user devices, such as end point devices 302. These encryption keys may be stored in the respective user key stores 426 of the first and second QKD receivers 404a and 404b, as discussed above. Any suitable method of generating symmetric encryption keys may be used.

[0161] Further, the QKD transmitter 402 and the first QKD receiver 404a can use the entropy KAI shared by the QKD transmitter 402 and the first QKD receiver 404a to generate shared symmetrical encryption keys for system internal use. These shared symmetric encryptionkeys can then be stored in the respective internal key stores 416 and 428 of the QKD transmitter 402 and the first QKD receiver 404a for future use. For example, for future use for authentication and encryption between the QKD transmitter 402 and the first QKD receiver 404a. Similarly, the QKD transmitter 402 and the second QKD receiver 404b can use the entropy KBI shared by the QKD transmitter 402 and the second QKD receiver 404b to generate shared symmetrical encryption keys for system internal use. These shared symmetric encryption keys can then be stored in the respective internal key stores 416 and 428 of the QKD transmitter 402 and the second QKD receiver 404a for future use. For example, for future use for authentication and encryption between the QKD transmitter 402 and the second QKD receiver 404b.

[0162] Then, in a third harvest entropy step 512, the first and second QKD receivers 404a and 404b can also harvest a part of their shared entropy, in the illustrated example of figure 5 this shared entropy is the second portion KAU of the first shared entropy KA In the third harvest entropy step 512, each of the first QKD receiver 404a and the second QKD receiver 404b allocates or selects a first, internal entropy, portion KAUI of the shared entropy KAU for internal use, and a second, external entropy, portion of the shared entropy KAU for use to generate user keys, or to provide other services. The first QKD receiver 404a and the second QKD receiver 404b determine the size of the selected first, internal entropy, portion KAUI based on the amount of shared symmetric encryption keys for internal use stored at at least one of the first QKD receiver 404a and the second QKD receiver 404b. Conveniently, the second, external entropy, portion of the shared entropy KAU can comprise the remainder of the shared entropy KAU which has not been selected as the first, internal entropy, portion KAUI This harvested entropy KAUI can then be used to generate shared symmetrical encryption keys for system internal use between the first and second QKD receivers 404a and 404b. These shared symmetric encryption keys can then be stored in the respective internal key stores 428 of the first and second QKD receivers 404a and 404b for future use. For example, for future use for authentication and encryption between the first and second QKD receivers 404a and 404b.

[0163] Again, it will be understood that the terms "first" and "second" portion are used only as nomenclature to distinguish between the different portions, and do not indicate the order of the first portion and the second portion. That is, it is not necessary that the first portion must be a part of the shared entropy (KAU) which is produced before the second portion. The first portion and the second portion may be selected or allocated from the shared entropy (KAU) in any desired manner, as convenient in any specific implementation.

[0164] It will be understood that the steps of the method 500 do not have to be carried out in the order shown in figure 5. The steps may be carried out in a different order, or simultaneously, or at overlapping times, as convenient in any specific implementation.

[0165] In the illustrated embodiment, in each of the entropy harvesting operations the size of the selected internal entropy portion is based on the amount of shared symmetric encryption keys for internal use stored at at least one of the nodes carrying out the entropy harvesting operation. In some examples, this basis may be direct, for example by basing the size of the selected internal entropy portion on an inverse ratio of the amount of shared symmetric encryption keys with a suitable ratio value so that a smaller internal entropy portion is selected when the amount of shared symmetric encryption keys for internal use is larger, and a larger internal entropy portion is selected when the amount of shared symmetric encryption keys for internal use is larger. The ratio value used will depend on the properties of the system in any specific implementation. In other examples an alternative method for deriving the size of the selected internal entropy portion from the amount of stored shared symmetric encryption keys for internal use may be used, for example by setting the size of the selected internal entropy portion to different values in a stepwise manner based on a comparison of the amount of shared symmetric encryption keys for internal use stored at at least one of the nodes to one or more threshold values. In other examples, the size of the selected internal entropy portion may be based on how long the amount of stored shared symmetric encryption keys for internal use are expected to last at predicted use rates.

[0166] Figure 6 shows a schematic diagram of an example of a method 550 of determining whether to carry out key harvesting which may optionally be used in the key management system 300 according to the first embodiment in conjunction with the method 500 of key harvesting of figure 5. The method 550 of figure 6 may be carried out before any or each of the first, second and third harvest entropy steps 504, 506 and 512 of the method 500. The illustrated example will be explained with reference to the first harvest entropy step 504.

[0167] In a first, determination, step 552 an amount of shared symmetric encryption keys for internal use stored at at least one of the QKD transmitter 402 and the first QKD receiver 404a generating entropy is determined. Then, in a comparison step 554, the determined amount is compared to a first threshold value.

[0168] If the determined amount is below the first threshold value, then in a first instruction step 556, the method 550 instructs carrying out the first harvest entropy step 504, as shown in figure 5.

[0169] Alternatively, if the determined amount is above the first threshold value, then in a second instruction step 558, the method 550 instructs not to carry out the first harvest entropy step 504. In this case, the method 500 of figure 5 will omit the first harvest entropy step 504.

[0170] The method 550 is carried out in a similar manner before the second and third harvest entropy steps 506 and 512 to provide instructions whetherthe second and third harvest entropy steps 506 and 512 respectively will be carried out or omitted. When carried out before the second harvest entropy step 506 an amount of shared symmetric encryption keys for internal use stored at at least one of the QKD transmitter 402 and the second QKD receiver 404b is determined, and the determined amount is compared to a second threshold value. When carried out before the third harvest entropy step 512 an amount of shared symmetric encryption keys for internal use stored at at least one of the first QKD receiver 404a and the second QKD receiver 404b is determined, and the determined amount is compared to a third threshold value. The first to third threshold values may be the same, or different, depending on the details of the system 300 in any specific implementation.

[0171] In the illustrated example the decision whether to carry out the harvest entropy steps is based on a comparison of the amount of shared symmetric encryption keys for internal use stored at at least one of the nodes to a threshold value. This is not essential. In other examples, the decision may be based on how long the amount of stored shared symmetric encryption keys for internal use are expected to last at predicted use rates.

[0172] In some examples, the different methods may be carried out in combination, with the harvest entropy steps being carried out when instructed by the method 550, and the size of the selected internal entropy portion being based on the amount of shared symmetric encryption keys for internal use stored at at least one of the nodes.

[0173] The method 500 of figure 5 is carried out between three nodes, a QKD transmitter 402 and two QKD receivers 404a and 404b. However, the method 500 may be altered and carried out between any plural number of nodes. The method 500 could be carried out between two nodes, a QKD transmitter 402 and a single QKD receiver 404, by carrying out the steps 502 and 504 only. Alternatively, the method 500 could be carried out between four or more nodes, a QKD transmitter 402 and three or more QKD receivers 404, by carrying out the steps 502 and 504 (or the steps 506 and 508) for the third QKD receiver, and each additional QKD receiver after the third, and making appropriate changes to the step 510 to transfer shared entropy between the different QKD receivers as required.

[0174] In the illustrated embodiments the size of the selected internal entropy portion, or the decision to carry out key harvesting by selecting an internal energy portion, is based on the amount of shared symmetric encryption keys for internal use stored at at least one of thenodes carrying out the entropy harvesting operation. This is not essential. In other examples the size of the selected internal entropy portion, or the decision to carry out key harvesting by selecting an internal energy portion may be based on the amount of shared symmetric encryption key material for internal use stored at at least one of the nodes carrying out the entropy harvesting operation. Such shared symmetric encryption key material may comprise shared symmetric encryption keys, but may alternatively, or additionally, comprise stored shared entropy allocated to generate shared symmetric encryption keys for internal use, and / or material in intermediate processing states between shared entropy and encryption keys. This may be advantageous, for example, in systems where the shared symmetric encryption key material is stored in a "raw" shared entropy state, and is used to generate shared symmetric encryption keys on an as needed basis.

[0175] As is explained above, the operation of the QKA system, and the QKD process, require messaging over classical communication channels, and so requires the use of pre- established symmetric keys, for mutual authentication and / or Integrity protection of data exchanges. In addition, communication between the elements of the QKA system also requires authenticated and encrypted communication. Conventionally, these links may use symmetric Keys provisioned during commissioning phase. However, either a large number of symmetric Keys must be initially provisioned, or it will be necessary to arrange for the periodic delivery of new symmetric keys in operation. By use of the key harvesting method discussed above, the stocks of symmetric keys held at the QKD transmitter 402 and the QKD receivers 404, which may be the key agreement agents 308 and the key agreement nodes 310 respectively, may be replenished during operation, removing the need for large initial stocks of symmetric keys and / or periodic delivery of new keys by some means external to the system 300. The disclosed method allows for dynamic replenishment of internal system Keys, overcoming the reliance on preloaded Key material or external key delivery. By basing the decision whether to carry out key harvesting and / or the amount of shared entropy harvested on the amount of shared symmetric encryption key material for internal use stored at at least one of the nodes the provision of new harvested shared entropy for internal use can be matched over time to the amount of internal system Keys used, which may be difficult to accurately predict in advance. Accordingly, the advantages may be provided of avoiding running out of internal system Keys and avoiding harvesting more shared entropy than is required, which may limit the amount of symmetric encryption keys available to the system for external use.

[0176] The Key Harvesting method is described herein with reference to figures 4 to 6 for use between two or three Nodes, specifically a key agreement agent 308 and one or two key agreement nodes 310 acting as QKD Transmitters and QKD Receivers respectively. The example here refers to a QKA system, where each Node either has a direct quantum link, or asingle node (trusted or entangled transmitter) in between. However, this may also be applied to a larger system, for example one with multiple trusted or untrusted nodes. In both cases, the process of harvesting the cryptographic key data is the same, however the method of transferring differs: in the case with trusted nodes, the key data must be distributed through the system using other cryptographic data to encrypt the harvested key payload. For a network of untrusted nodes, this will rely on entanglement swapping protocols. Any known methods and protocols for distributing key data among the nodes may be used.

[0177] In the illustrated embodiments the harvesting method is applied to a QKD system. However, the present disclosure is not limited to the use of QKD, and may be applied to systems using other methods for generating symmetric Highly-Entropic material in a secure manner, and in particular in an information theoretic secure manner, between different nodes.

[0178] The present disclosure provides a method for harvesting a portion of the shared Highly-Entropic String generated in operation, for example between the QKD T ransmitter 402 and QKD Receiver 404 where the method is applied to a QKD system, for future use as internal system Keys. Since these symmetric keys are independently created by both parties, this replenishment process can provide the advantage that the security of the created symmetric keys it is not constrained by the strength of the security of a communication link, as in typical asymmetric Key agreement process. Traditional methods of authentication using asymmetric public Key infrastructure does not provide the level of security required for secure key distribution, such as in a QKD system. A further advantage is that the QKD transmitters 402 and QKD receivers 404 only require a small number of initial keys to begin operation, and do not require a large initial stock of preloaded encryption keys, such as a stock sufficient for their expected operating life, because additional symmetric keys are harvested and / or generated in operation. In an extreme example, all that is required is one initial set of Keys to establish the first QKD session, it will be understood that the method does not remove the need for some initial key loading, since the first key harvesting session requires authentication from an existing buffer of symmetric keys to set up and start a QKD session to enable key harvesting to be carried out. Corresponding advantages will apply in non-QKD systems.

[0179] The disclosed method using a portion of the symmetric data / entropy generated at both end points by a QKD protocol for the QKD process itself, as well as for wider system encryption and authentication, is an enhancement over traditional Key replenishment methods, since the resulting Keys benefit from the security properties of QKD.

[0180] The disclosed method of Key Harvesting allows dynamic replenishment of buffers of internal system keys. Without this, any cryptographic system must either use symmetric keys from a finite preloaded pool, or non-information theoretic secure asymmetric cryptographickey algorithms, or an external method of providing additional keys such as a manual key fill process similar to that used to provide the initial bootstrapping keys on commissioning the system. Accordingly, this method can provide the advantage of removing any lifetime constraint on a system while ensuring security of any cryptographic endpoint, and reduce the complexity and cost of operating the system.

[0181] Further, the disclosed method may provide the advantage that it allows forthe dynamic management of the available internal keys since their specific use can be determined during operation, and the number stored in the buffer at each system node can be varied on demand as necessary to meet operational requirements. Further, initiating the harvesting process is intrinsically flexible, any of the system nodes, such as the QKD nodes, can perform a handshake or request to agree the Highly-Entropic Strings or symmetric Key material, such as key blocks, to be harvested, or a direct command can reserve specific Highly-Entropic Strings or key blocks for harvesting as part of the QKD session scheduling. The former mode provides autonomy to the system while the latter removes the need for the initial handshake or request.

[0182] In some examples the harvesting of Highly-Entropic Strings may be controlled locally by the individual nodes of the key management system. For example, by the individual key agreement nodes 310 and key agreement agents 302 of the key management system 300. Such local control may be based on the quantity of encryption key material such as encryption keys available to each node for system internal use, for example stored in the internal key buffers of the nodes, compared to threshold amounts, or based on how long the encryption keys available to each node for system internal use are expected to last at predicted use rates. For example, when the quantity or expected duration of use of the encryption keys available to a node for system internal use drops below a predetermined threshold the node may send a request or handshake to another node to carry out key harvesting on mutual QKD activity between the nodes. In other examples the harvesting of Highly-Entropic Strings may be controlled centrally by a control node of the key management system, for example by the system manager 306 of the key management system 300. Such central control may be based on the quantity of encryption keys available to each node for system internal use as reported to the control node by other nodes of the system. For example, when the reported quantity or expected duration of use of the encryption keys available to a node for system internal use drops below a predetermined threshold the control node may send instructions to that node and another node to carry out key harvesting on mutual QKD activity between those nodes. In some examples the amount of the encryption keys available to a node for system internal use may be measured separately for each other node in the system, or each other node in the system which the node is expected to communicate with.

[0183] Local control of key harvesting may provide advantages by allowing for autonomy of the Nodes, whereby they can maintain a required number of Keys in their internal key store / buffer, avoiding any dependency on a central controller or system Manager. This approach may remove the risk of a central point of failure, and reduce the amount of internal communications required within the system. Central control of key harvesting by commands from a control node which is a third party (relative to the harvesting process) may provide the advantages of allowing the harvesting process to be specifically scheduled, and removing the need for the handshaking process between the two Nodes.

[0184] Internal Keys may be used in various steps of Key Post processing, allowing for symmetric processes to be performed at both endpoints in an information theoretic secure manner. These include Key Bases sifting, error correction, strong authentication and verification, and privacy amplification.

[0185] As is explained above, the internal Keys required for internal use by the QKA system 300 in Key Post Processing (KPP) are replenished by harvesting Highly-Entropic material between the two QKD end points (i.e. the transmitter 308, 402 and each receiver 310, 404). In the example of figure 5, QKD transmitter 402 generates symmetric Highly Entropic String KAand KBwith receiver A 404a (step 502) and Receiver B 440b (step 504) respectively. A portion of KA referred as KAI is harvested for use in future post processing sessions between the transmitter 402 and Receiver A 404a. similarly KBI is harvested from the KBfor post processing between the transmitter 402 and receiver B 404b. It will be understood that the harvested Highly-Entropic material may also be used to produce keys used for other system internal purposes.

[0186] It is not essential to use any specific method for selecting the bits to harvest for the internal Highly-Entropic Strings in steps 504, 508 and 512 of the method of figure 5. For example, it is equally acceptable to select the first or last n bits from the agreed Highly- Entropic String (i.e. at the end of the KPP process), or by selecting an arbitrary number of bits from arbitrary places within the Highly-Entropic String. The only requirement is that the bit selection method is previously agreed between the QKD Transmitter 402 and Receiver 404, or the two QKD Receivers 404 (in the case of harvesting of distributed Entropy between QKA Nodes).

[0187] As can be understood from the above, it is essential that the stocks of symmetric keys held at different nodes (i.e., transmitters and receivers) of the system are replenished with new harvested symmetric keys. However, it is not essential that any specific method carrying out this replenishment is used. The specifics of maintaining the required internal key buffers of harvested Keys may be selected as appropriate in any specific implementation. Forexample, the internal key buffer of each node may be topped up based on defined minimum and maximum thresholds i.e., if the buffer is below the minimum threshold, Keys will be harvested until the buffer reaches the maximum threshold.

[0188] In the examples described above of a QKA system 300 the Highly-Entropic material used to generate the internal keys is all extracted from the same Highly-Entropic String (after KPP). However, this is not essential. The method does not limit the use of the Highly-Entropic material for the purpose of generating the internal Keys. In some examples, alternatively, separate pools of Raw key material may be apportioned and processed by independent KPP threads, providing additional separation between Internal and External Highly Entropic strings. In other words, the highly-entropic material of the generated shared entropy may be harvested and allocated into an internal entropy portion and an external entropy portion after completion of key post processing (KPP), or, alternatively, the highly-entropic material of the generated shared entropy may be harvested and allocated into an internal entropy portion and an external entropy portion before KPP, and KPP of the internal entropy portion can then be carried out separately from KPP of the external entropy portion.

[0189] The harvested internal keys may have any desired length or type, as required for the intended use of the Harvested Keys. In the example of KPP Keys, as shown in Table 1 , the length varies depending on the application. In general, the size of the Harvested Keys should be determined as appropriate to the intended usage of the Key, for example those laid out by NIST Key Management Recommendations. The disclosed method allows for the harvesting of a wide range of sizes and numbers of Internal Keys, and the flexibility allows control over the process which is desirable for a system which potentially generates short or few Highly- Entropic Strings, for example in S-QKA where bit rates may be low and infrequent. The harvested Highly-Entropic material can be used to generate a desired number of symmetric Keys of a given length, according to the appropriate Key generation method, for example those laid out by NIST Key Management Recommendations.

[0190] As is explained above, the disclosed method also allow harvesting of keys for authentication and encryption between QKA nodes, such as the key agreement nodes 310, through harvesting of the distributed Highly-Entropic Strings (KAU in the illustrated example). This allows for all nodes and elements of a QKA system to utilise the harvested keys which share the informatic theoretic secure nature of QKD.

[0191] A significant benefit of this method is that the harvesting process is dynamic: an arbitrary sized buffer of Keys can be replenished on demand at any Node, and any actor in the system can command the process. This may add flexibility and redundancy to the QKD system.

[0192] In addition, the method is also agnostic to the QKD protocol. In all cases, harvesting between the two receivers (i.e., from KAU) is always supported, while for the link between the each QKD Transmitter and Receiver, the only requirement is that these endpoints are capable of establishing a shared symmetric Highly-Entropic String. In the case of entanglement-base protocols, this implies that the transmitter must have the capability to receive one of the pair of entangled photons.

[0193] The key harvesting concept is discussed above with reference to the illustrated examples of use of key harvesting in QKA systems, such as QKD systems. Although QKA and QKD systems can usefully employ the key harvesting approach, the use of key harvesting is not limited to QKA and / or QKD systems. Any system which shares keys and / or key material between different parts of the system may employ key harvesting to provide keys for use in internal system functions, such as to support secure communications between different parts of the system.

[0194] In general terms, in a second aspect, the present disclosure provides a method of key management to track the sharing of Highly-Entropic Strings, or symmetric encryption keys generated from the strings, amongst a group of Nodes, such as QKA Nodes, over time. This method may be used within a key management system, for example in the key management system 300. In this second aspect, the delivery of Highly-Entropic Strings is tracked via communications with each Node.

[0195] It will be understood that in order for cryptographic services between different users to be supported, the key agreement nodes 310 associated with the user end point devices 302 participating in the cryptographic services must be provided with the same, common, encryption keys by the key management system 300, so that the key agreement nodes 310 can in turn provide the user end point devices 302 participating in the cryptographic services with the same, common, encryption keys. Depending upon the details of the cryptographic services being supported this may require any number of end point devices 310 associated with the same or different key agreement nodes to be provided with the same common encryption keys, for example, two user end point devices 302, or three user end point devices 302, or more, and potentially a large number of user end point devices 302. The key management system 300 manages the supply of encryption key data to the different key agreement nodes 310 in order to ensure that the required encryption keys can be made available by the different key agreement nodes 310 to the user end point devices 302 associated with them.

[0196] As is explained above, particularly with reference to figure 3, in order for the key management system 300 to be able to provide key material, such as symmetric keys, to theend point devices 302 it is necessary for the key agreement nodes 310 associated with the end point devices 302 requiring common key material to share symmetric Highly-Entropic material, such as Highly-Entropic Strings, which shared Highly-Entropic material is used by the different key agreement nodes 310 to generate the common key material shared by the different end point devices 302. In operation of the key management system 300, different ones of the key agreement agents 308 can cooperate with different groups of multiple key agreement nodes 310 to use symmetrical Highly-Entropic Strings at the key agreement agent 308 and the multiple key agreement nodes 310 to generate and / or distribute symmetrical Highly-Entropic Strings shared between the group of key agreement nodes 310. These symmetrical Highly-Entropic Strings shared between the group of key agreement nodes 310 can then be used to generate common key material, such as common symmetric keys, shared by a group of end user devices 302 associated with the group of key agreement nodes 310. Such common key material shared by a group of end user devices 302 may be referred to as group keys.

[0197] It will be understood that in general any number of any of the end user devices 302, up to and including all of the end user devices 302, may be comprised in a group requiring group keys (that is, common key material, such as common symmetric keys) for mutual encryption key based cryptographic services between the members of the group. One example of such an encryption key based cryptographic service is encrypted communications, and other examples are identified above. Accordingly, any number of any of the key agreement nodes 310 associated with the end user devices 302, up to and including all of the key agreement nodes 310, may require shared symmetric Highly-Entropic material, such as Highly-Entropic Strings in order to generate the required group keys for a group of end user devices 302.

[0198] In order to ensure that all of the necessary key agreement nodes 310 have the necessary common shared symmetric Highly-Entropic material required to support any particular request for group keys shared by a group of end user devices 302, the key management system 300 may comprise a group key distribution management function which maintains a group key distribution history which tracks and records the delivery of Highly- Entropic material, such as Highly-Entropic Strings, to the different key agreement nodes 310 of the key management system 300. As will be explained in more detail below, the group key distribution history records the sharing of the Highly-Entropic material, such as Highly- Entropic Strings, amongst groups of key agreement nodes 310 over time based on communications with each key agreement node 310 by the group key distribution management function.

[0199] As was explained above, in order to supports the distribution of Key material to a group of users, i.e. , for producing Group Keys, it is necessary to track the distribution of the material used to generate the Keys for the endpoints amongst the desired group of Nodes. In the illustrated embodiment this is the distribution of Highly-Entropic material, such as Highly- Entropic Strings for use to generate group keys for the end user devices 302 amongst the desired group of key agreement nodes 310, but other arrangements are possible in different examples. This is essential for a system using symmetric Key cryptography since instances of the same cryptographic material must be present at each Node. The importance of tracking this distribution so that the key management system 300 has knowledge of the instantaneous state of the distribution of Highly-Entropic material to the different Nodes is greater for a system with high latency or sporadic connectivity between Nodes, for example a S-QKA system. In such a case, the Highly-Entropic material may take a long time to be fully distributed to the desired different nodes.

[0200] The illustrated embodiment of the key management system 300 in figure 3 is a QKD system. However, the present disclosure is not limited to the use of QKD, and may use other methods for generating symmetric Highly-Entropic material in a secure manner, and in particular in an information theoretic secure manner, between different nodes.

[0201] Figure 7 shows a schematic diagram of an example of a system manager 600 of a symmetric key management system according to an embodiment of the present invention. The system manager 600 may be the system manager 306 of the key management system 300 of figure 3.

[0202] As shown in figure 7, the system manager 600 comprises a group key distribution management module 602 and a data store 604. As will be explained in more detail below, the group key distribution management module 602 carries out a group key distribution management function which stores and maintains a group key distribution history in the data store 604. This group key distribution history records the delivery of Highly-Entropic material, to different nodes of a system. In the example of figure 3 the group key distribution history records the delivery of Highly-Entropic Strings, to the different key agreement nodes 310 of the key management system 300, but other examples may operate differently.

[0203] The group key distribution management module 602 carries out the group key distribution management function to track and command the distribution of symmetric Highly- Entropic material to the different key agreement nodes 310 as required to enable the generation of the required group keys for use by the end user devices 30. As is explained above, in the illustrated example of figure 3, the Highly-Entropic material comprises Symmetric Highly-Entropic String. Each Symmetric Highly-Entropic String comprises a uniquestring with high entropy that must be stored, accessed, and modified across multiple system Nodes, such as the key agreement nodes, to generate the require group keys. There will be multiple instances of each Highly-Entropic String, i.e. duplicated instances, throughout the key management system 300 at different key agreement nodes 310 in order to allow group keys to be generated.

[0204] To allow the distribution of the Symmetric Highly-Entropic Strings to be tracked and controlled, the group key distribution management module 602 arranges the Symmetric Highly-Entropic Strings into Data Items, by dynamically grouping the Symmetric Highly- Entropic Strings into sets. Each Data Item comprises a set of one or more Symmetric Highly- Entropic Strings together with associated metadata describing the distribution state (that is, the nodes to which the Data Item has been distributed) and the intended use of the set of Symmetric Highly-Entropic Strings of the Data Item. For example, the metadata may indicate that the set of Symmetric Highly-Entropic Strings are for system internal use (that is, they have been harvested for internal uses as set out above), or that the set is for use in distributing other Symmetric Highly-Entropic Strings (for example by being used as a one time pad), or that the set is to be delivered to end point devices. This list of possible uses is by way of example only, and is not intended to be exhaustive. The group key distribution management module 602 maintains in the data store 604 a record of each of the different Data Items. Each Data Item is recorded in association with information indicating the distribution history (that is, the nodes to which the Data Item has been distributed) and the fully distributed state (that is, the nodes to which the Data item is intended to be distributed) of that Data Item.

[0205] In operation of the key management system 300, the system manager 600 uses the stored Data Item records and associated distribution history and fully distributed state information to generate instructions to Agents to deliver specific data items to specific nodes in order to distribute the Highly-Entropic Strings comprised in the data items to the required nodes so that the desired group keys can be generated. The Agents distribute the data items through the key management system. In the illustrated example of figure 3 of the key management system 300, the Agents are the key agreement agents 308, which distribute highly entropic material to the key agreement nodes 310. The generated instructions to the Agents take the form of sessions, where each session comprises a set of instructions to an Agent, instructing the delivery of specific Data Items to a Node, which set of instructions may be regarded as defining a data delivery session.

[0206] In order to allow the current and intended distribution of the different data items to nodes to be reported, tracked, and recorded, the embodiment uses groupings of the data items. Each grouping identifies a different group of nodes. Accordingly, the distribution historyof a data item may be identified as a group of nodes, which group corresponds to the nodes (i.e., the key agreement nodes 310) to which the Data Item has been distributed. This grouping can be referred to as a ‘Group ID’ (GID), which may be a single data field. This single data field corresponds to the Distribution History of the Data Item, and only this data field needs to be tracked by the System Manager 600, simplifying the task of tracking and recording the distribution histories of the different data items.

[0207] In general, the defined set of useable Group IDs in a system includes a Group ID corresponding to every possible delivery state of data items to the different nodes in a system. The possible delivery states may comprise "delivered to none of the nodes", for each of the nodes "delivered to only that node", for each possible group of less than all nodes "delivered only to all nodes in that group" and "delivered to all nodes". In some examples, where some of these delivery states are not possible, for example if the maximum number of nodes in a group is less than the total number of nodes, there may be a smaller number of possible delivery states.

[0208] Figure 8 shows an example of a key management system 700. As shown in figure 8, the key management system 700 comprises three nodes 710a to 710c, an agent 708 and a system manager 600. The three nodes 710a to 710c are arranged to provide group keys to respective corresponding endpoints 702a to 702c. The key management system 700 operates in the same manner as described above for the key management system 300.

[0209] The key management system 700 may be a small, or simple, version of the key management system 300, with the nodes 710 being key agreement nodes 310, the agent 708 being a key agreement agent 308, the system manager 600 being a system manager 300, and the endpoints 702 being user end point devices 302.

[0210] In operation of the key management system 700, under instructions from the system manager 600, and specifically from the group key distribution management module 602, the agent 708 delivers highly entropic material to the three nodes 710a to 710c. Although this example comprises three nodes 710, it will be understood that there may any number of nodes which it three or more (It will be understood that there must be at least three nodes in order for there to be more than one possible group of nodes).

[0211] In the illustrated embodiment of figure 8, the Agent 708 cannot guarantee that an attempt to deliver a Highly-Entropic String to a given Node 710a to 710c will succeed due to an unreliable communications link between them. For example, the system 700 may be an S- QKD system where the agent 708 is a satellite and the Nodes 710 are ground stations, so that reliable operation of the Satellite-to-Ground links between them cannot be guaranteed,being subject to interruption by clouds and the like. Other forms of key distribution may have corresponding reasons why delivery attempts cannot be guaranteed to succeed.

[0212] In the illustrated embodiment of figure 8, the communications link between the Agent 708 and the System Manager 600 has a highly constrained bandwidth (for example a Satellite telemetry and telecommand link), and assuming the Agent 708 is required to deliver a very large number of Highly-Entropic Strings, for example many millions of Highly-Entropic Strings, as will usually be the case in practice. As a result, individually addressing each Highly- Entropic String to be used to generate each group Key is infeasible because the available communications bandwidth is insufficient.

[0213] In the illustrated embodiment of figure 8, the communications link between the Agent 708 and the System Manager 600 is sporadic and cannot support a constant stream of delivery instructions. For example, the system 700 may be an S-QKD system where the agent 708 can only communicate with the system manger 600 when the orbit of the Agent 708 satellite passes over a system manager 600 ground station.

[0214] As will be explained in more detail below, the Distribution History is only tracked by the System Manager 600, while the Agent 708 uses a corresponding Group ID.

[0215] Table 1 below lists an exhaustive set of unique Group IDs corresponding to all of the possible groups of Nodes, that is combinations of Nodes, to which a Data Item may be delivered. Accordingly, any delivery action carried out by the Agent 708 which delivers an existing Data Item to a new Node 710 will necessarily move Data Items between these possible groups, and so can be represented by changing the Group ID associated with the Data Item. In this example, only the existence of a Data Item at a Node is important, but the order of distribution of the Data Item to the different nodes is not significant, and so is not represented or recorded in the Group IDs. The Group IDs map to the distribution of Data Items amongst the set of Nodes.

[0216] When a Highly-Entropic String is first generated it will be in existence at a combination of nodes corresponding to one of the possible combinations of nodes identified in Table 1 , which corresponds to one of the listed Group IDs. For example, a Highly-Entropic String could be generated outside of the nodes 710 of the system 700, for example by the Agent 708, and so be present at none of the nodes 710, or a Highly-Entropic String could be generated by cooperation between a node 710 and the Agent 708 of the system 700, for example using a QKD Highly-Entropic String generation protocol, and so be present at one of the nodes 710, or a Highly-Entropic String could be generated between two nodes 710 of the system 700, for example using an entanglement based QKD Highly-Entropic String generation protocol, and so be present at a group of two of the nodes 710.

[0217] Figure 9 shows a data item generation method 800 carried out by the system 700 in operation.

[0218] It will be understood that in order for the data item generation method 800 to be carried out, there must be some pre-existing Highly-Entropic String available to the system 700. This Highly-Entropic String may be generated by any suitable method, for example the methods discussed above. Each highly-entropic string is assigned an identifier and is stored at appropriate locations in the system 700 together with this identifier. For example, a highly entropic string may be stored only at the Agent 708, and not at any node 710, may be stored at only one node 710, or may be stored at two of the nodes 710.

[0219] In a first, define data item block 802, the System manager 600 organizes the Highly- Entropic String available to the system 700 to form a Data Item. Figure 10 shows a schematic diagram of a Data Item 900. As is explained above, each Data Item 900 comprises a set 902 of one or more Symmetric Highly-Entropic Strings 902i to 902ntogether with associated metadata 904 describing the distribution state (that is, the nodes to which the Data Item 900 has been distributed). The set 902 of one or more Symmetric Highly-Entropic Strings 902i to 902ncomprised in a single Data Item 900 are selected to all have the same presence at the nodes 710, that is, all corresponding to the same Group ID. The system manager 600 assigns the Data item 900 the Group ID corresponding to the common node presence of the set 902 of constituent Symmetric Highly-Entropic Strings, and a data item identifier 906. In some examples each Data Item 900 may be arranged to comprise the same quantity of Symmetric Highly-Entropic String material. However, this is not essential, and in other examples different Data Items 900 may comprise different quantities of Symmetric Highly-Entropic String material. Conveniently, in examples where the Symmetric Highly-Entropic Strings have a common standard size, each Data Item 900 may be arranged to comprise the same number of Symmetric Highly-Entropic Strings. However, this is not essential, and in other examplesdifferent data items may comprise different amounts of Symmetric Highly-Entropic String material.

[0220] For example, if the data item 900 comprises Symmetric Highly-Entropic Strings not stored at any node 710 (for example because they are stored at the Agent 708 only), this data item is assigned the Group ID 1 , as shown in Table 1 . In another example, if the data item 900 comprises Symmetric Highly-Entropic Strings stored only at node 710A, this data item is assigned the Group ID 2. In another example, if the data item 900 comprises Symmetric Highly-Entropic Strings stored only at nodes 710A and 710B, this data item is assigned the Group ID 3. The Group IDs corresponding to all possible Node presences are shown in Table 1.

[0221] Then, in a record data item block 804, the system manager 600 records the identities of the set 902 of constituent Symmetric Highly-Entropic Strings 902i to 902nof the data item, 900 together with the Group ID 904 and data item identifier 906 in the data store 604. Further, the system manager 600 informs the system components (that is, in the illustrated embodiment, the Agent 708 and the nodes 710) where the set 902 Symmetric Highly-Entropic Strings are located of the formation of the data item 900, and each of these components records the data item by storing the identified set 902 of Symmetric Highly-Entropic Strings 902i to 902n together with the Group ID 904 and data item identifier 906.

[0222] It will be understood that the data item generation method 800 will define and record a single data item 900. Accordingly, the data item generation method will be repeated multiple times as necessary to define and record the required data items 900 in operation of the system 700.

[0223] The organizing of the Highly-Entropic String available to the key management system 700 into Data Items 900 may reduce the amount of record keeping and communications required in order to correctly distribute the Highly-Entropic String around the system 700. It will be understood that in a practical key management system 700 a very large number of Highly-Entropic Strings must be distributed around the key management system 700, so that tracking and recording these Highly-Entropic Strings individually may impose a significant burden of required record keeping and communications. This may be reduced by grouping plural highly-entropic strings into each data item 900 and tracking and recording delivery of data items 900. However, this is not essential, and individual highly-entropic strings may be tracked and recorded, this corresponding to a data item 900 comprising a set of one highly- entropic string.

[0224] Figure 11 shows a distribution method 1000 carried out by the system 700 in operation. It will be understood that in the usual situation where the system 700 is alreadyoperating, there will generally be some, and typically a large amount, of Highly-Entropic String already organized into Data Blocks 900, and stored an recorded by the system 700.

[0225] In a first group key requirements block 1002, the system manager 600 of the key management system 700 determines requirements for common Highly-Entropic Strings at groups of two or more nodes 710a to 710c in order to enable the nodes 710a to 710c to generate required group keys and provide them to these groups of endpoints 702a to 702c. The requirements for common Highly-Entropic Strings may be pre-set, and / or may be determined by the system manager 600 based on requests for group keys from the endpoints 702a to 702c.

[0226] Then, in a string requirements block 1004, the system manager 600 compares the determined requirements for common Highly-Entropic Strings at each group of two or more nodes 710a to 710c to the amount of common Highly-Entropic Strings available to each group of two or more nodes 710a to 710c in the data items 900 commonly stored at that group of nodes 710a to 710c, and determines the amount of additional common Highly-Entropic Strings required by each group of nodes 710a to 710c. The system manager 600 can determine the amount of common Highly-Entropic Strings available to each group of two or more nodes 710a to 710c from the records of the data items 900 stored in the data store 604 based on the Group IDs of the different data items 900. In the illustrated embodiment there are four groups of two or modes 710a to 710c, specifically, 710a and 710b, 710a and 710c, 710b and 710c, and 710a and 710b and 710c. However, in other examples there may be any number of such groups of two or more nodes.

[0227] Then, in a distribution requirements block 1006, the system manager compares the determined amount of additional common Highly-Entropic Strings required by each group of nodes 710a to 710c to the record of all of the data items 900 stored in the key management system 700, and determines a number of data items 900 for distribution to the different groups of two or more nodes 710a to 710c which are required in orderto satisfy these determined requirements either completely, or in part (In some circumstances it may not be possible to completely fulfil the determined requirements until additional Highly-Entropic Strings have been generated). This selection is based upon the current distribution of the data items 900 to the different nodes 900 as indicated by the respective Group IDs of the Data Items 900. Accordingly, Data Items 900 are selected based upon their distribution to be delivered to specific Nodes 710. These actions only require to be indexed by the Group ID since any singular Data Item 900 will exist in a specific distribution state indicated by its Group ID.

[0228] Then, in a calculate actions block 1008, the system manager 600 calculates a number of Data Item delivery actions to be carried out in by the Agent 708 in order to order to deliver the data items 900 selected for distribution. Each delivery action identifies a destination node 710 at which the action is to be carried out, a source group ID from which the transferred data items 900 are to be selected, a maximum number of data items 900 to be transferred during the action, and a destination group ID which is to be assigned to the data items 900 after transfer (It will be understood from the above that the delivery of a data item 900 to a node 710 must always cause a change in distribution of the data item 900 corresponding to a change in group ID).

[0229] Then, in a send actions block 1010, the system manager 600 sends the calculated actions to the Agent 708, which stores the actions for subsequent execution.

[0230] The Agent 708 conducts Data Item delivery sessions to the different nodes 710 when possible. In some examples, the Agent 708 may be able to conduct a delivery session to a specific node 710 at any time, in other examples, the Agent 708 may only be able to conduct a delivery session to a specific node 710 at particular times. For example, the system 700 may be an S-QKD system where the agent 708 is a satellite and the Nodes 710 are ground stations, so that Data Item delivery sessions between the agent 708 and a specific node 710 can only be carried out when the agent 708 visits the node 710, that is, when the Agent 708 satellite is at a suitable orbital position relative to the node 710 ground station.

[0231] When the Agent 708 conducts a delivery session to a specific node 710, for example when the Agent 708 visits the node 708, the Agent 708 conducts a series of the stored actions previously sent from the system manager 600 which are to be carried out at the node 708 with which the Agent 708 is conducting the delivery session, in a conduct session block 1012. An example of a possible distribution session is shown below as Table 2.Table 2

[0232] As is shown in Table 2, the distribution session describes a series of actions to be taken by the Agent 708 with the current node 708. In the example of Table 2, a distribution session to be taken with the node 710a (Node A) is show. As is explained above, each delivery action identifies a source group ID from which transferred data items 900 are to be selected, a maximum number of data items 900 to be transferred during the action, and a destination group ID which is to be assigned to the data items 900 after transfer.

[0233] In the example of Table 1 , the Agent 708 is tasked to perform the following actions:1. Take 100 Data Items that have not been delivered to any Nodes, and so have the Group ID 1 , deliver them to Node 710a (Node A) and record, for those where delivery succeeds, that those Data Items have been delivered to Node 710a (Node A) only by changing their Group ID to Group ID 2. (It will be understood that only delivery at Node 710a will correspond to this change of Group ID from 1 to 2).2. Take 100 Data Items that have previously been delivered to Node 710b (Node B), which have the Group ID 6, deliver them to Node 710a (Node A) and record that they have now been delivered to both Nodes 710a and 710b (Node A and Node B) by changing their Group ID to Group ID 3.3. Take 100 Data Items that have previously been delivered to both of Nodes 710b and 710c (Node B and Node C), which have the Group ID 7, deliver them to Node A and record that they have now been delivered to all of Nodes 710a to 710c (Nodes A, B and C) by changing their Group ID to Group ID 4.4. Take 100 Data Items that have previously been delivered to Node 710c (Node C) only, which have the Group ID 8, deliver them to Node 107a (Node A) and record that they have now been delivered to Nodes 107a and 107c (Nodes A and C) by changing their Group ID to Group ID 5.

[0234] In all cases, the Group ID is changed only for those Data Items that are successfully delivered. If delivery fails the Group ID associated with a Data Item is not updated.

[0235] Then, in a report delivery block 1014, the Agent 708 reports the changed Group IDs of the successfully delivered Data Items to the group key distribution management module 602, which updates the records of these data items in the data store 604 accordingly.

[0236] Thus, the Group ID associated with each data item at the Agent 708 and the data store 604 of the system manager 600 is updated to indicate the new current distribution status of each data item after each distribution session. This is on a per-ltem basis and implies and corresponds to a movement of the Data Item between groups.

[0237] The conduct session block 1012 and the report delivery block 1014 are carried out for each node 710 separately.

[0238] The blocks of the method 1000 may be carried out asynchronously and in different orders, and some blocks may be carried out multiple times before other blocks are carried out. For example, the Agent 708 may carry out the conduct sessions block 1012 with the same or different Nodes 710 before being able to conduct the report deliver block 1014. This is particularly likely if the system 700 is an S-QKD system. In other examples the conduct sessions block 1012 and the report deliver block 1014 may be carried out simultaneously, with the delivery of each Data Item being reported at the same time as subsequent Data Items are being delivered.

[0239] The method 1000 is described for a single distribution session. It will be understood that the method 1000 will be carried out multiple times, and probably substantially continuously, during operation of the system 700 as Data Items are delivered to different Nodes. In practice, different blocks of the method 1000 will be carried out asynchronously, and often simultaneously, by different parts of the system.

[0240] In the illustrated embodiment a Data Item can be delivered to any or all Nodes in any order, and if delivery to a specific Node fails for a Data Item, this may be reattempted in a future Session. Failure to deliver a Data Item is implicitly reported by the Agent 708 not changing its Group ID. There is no requirement to use additional communications resources by positively reporting failure to deliver a Data Item.

[0241] It will be understood that in the illustrated embodiment the different Group IDs correspond only to the current deliver state of a Data Item, and do not identify the order in which the Data Item was delivered to different Nodes 710. Accordingly, Data Items having different delivery histories, that is Data Items which were distributed to specific Nodes 710 in a different order, may have the same Group ID.

[0242] The different multiple different potential delivery orders between the Nodes 710a to 710c, starting from the undistributed state (Group ID 1) and finishing with the Data Item delivered to all of the Nodes 710a to 710c (Group ID4) is illustrated by way of example in Table 3. Table 3 shows the potential delivery routes for a Data Item from no nodes to all Nodes and indicates the series of associated Group IDs, where interstitial equivalent groups (e.g. A AB = BflA) that have been reconciled are indicated with an asterisk. In Table 3, Node 710a is identified as A, Node 710b is identified as B, and Node 710c is indicated as C.Table 3

[0243] In the illustrated embodiment the Group IDs correspond to the current delivery state of a Data Item, and do not identify the order in which the Data Item was delivered to different Nodes 710. In alternative examples the Group IDs may indicate both the current delivery state of a Data Item and the order in which the Data Item was delivered to different Nodes 710. It will be understood that this will generally require more Group IDs to be defined. By defining Group IDs which correspond to specific orders of delivery to different nodes, Data Items which have been delivered to different nodes in specific orders can be segregated and distinguished in applications where the order of delivery is significant.

[0244] For example, the system may distribute some Data Items to Node 710a and then to Node 720b and put these Data Items in a group having a Group ID, for example Group ID1 , in one distribution process. In another distribution process the system might have distributed other Data Items to Node 710b first and then distributed these other Data Items to Node 710b. In the another distribution process the system could either put the Data Items in the same group having the same Group ID1 (since both distribution processes end up with Data Items at Node 710a and 710b, so that they have the same delivery state) or alternatively the system could put the Data Items from the another distribution process in a different group with a different Group ID, for example Group ID2, to track and record that the although all of these Data Items have the same delivery state the Data Items with Group ID1 have been distributed in the sequence A->B while the Data Items with Group ID2 have been distributed in the sequence B->A.

[0245] The present disclosure provides key management which is highly flexible and agnostic to any rigid definition of Distribution Groups. It supports variable definitions andredefinitions of the final distribution of any particular Highly-Entropic String, and is robust to the order and route of delivery. The disclosed method is highly flexible, and allows the dynamic creation, assignment to, and destruction of specific groups, by adding or removing corresponding Group IDs, and does not requiring either an exhaustive or a predefined list of allowed distributions. This therefore implicitly supports expansion and contraction of a Key Management system, where distribution groups may be created, and Nodes may be added or removed ad hoc.

[0246] The present disclosure allows for simplification of the control and reporting messaging between the Agents, Nodes and the System Manager, as well simplification of the metadata describing the state at these entities: The Distribution History may be stored abstractly as a Group ID at the Agents and Nodes, which maps to a known definition at the System Manager. This allows for minimal messaging between the different entities, so this enhancement can support systems with constraints on communication bandwidths and sporadic connections.

[0247] The present disclosure does not require the use of any specific method by which the Key Management system generates or delivers the Data Items. It is agnostic to the Agent and can support any symmetric Key delivery agent, for example this is applicable to, but not limited to an QKA or QKD system, such as an S-QKA system.

[0248] The illustrated embodiments relate to systems which use QKD to generate and deliver Highly-Entropic String. However, the present disclosure is not limited to the use of QKD or Highly-Entropic String, and may use other methods for generating symmetric Highly- Entropic material in a secure manner, and in particular in an information theoretic secure manner.

[0249] The present disclosure can provide advantages in at least any of the following situations, but is not limited to any or all of these situations applying:1) The execution of a Session cannot be guaranteed to succeed.2) It is not possible to control the precise distribution of an individual Data Item throughout the system, e.g. in a system which may control many thousands or millions of Objects it may not be possible to provide precise instructions for each Data Item.3) The final distribution of an individual Data Item is not defined at the time of creation, i.e. the distribution may be updated over time.4) Verifiable proof for each distribution step is required.5) The distribution of a Data Item must be constrained such that it is delivered only to the intended set of Nodes.6) The order that a Data Item is distributed amongst the Nodes is unimportant.7) Efficiency of messaging is a primary concern, i.e. the communications link between the Nodes and the rest of the system has a reduced bandwidth which constrains the message size of the Schedule.8) A continuous direct connection between the Nodes and the rest of the system, is not available, i.e. the Agent may be out of contact for prolonged periods of time.9) Distribution actions are constrained to subsets of Nodes at any given time, which may not intersect with the set of Nodes for the final distribution (e.g. a concept of Agent Affinity).

[0250] The illustrated embodiments only track the state of distribution of the Data Items, and do not track the order in which the Data Items are distributed to the different Nodes. The present disclosure is not limited to only tracking the state of distribution, and may be extended to also track the order if desired. Accordingly, the Highly-Entropic Strings may be grouped by delivery order if required.

[0251] The illustrated embodiments are described in terms of the Distribution Groups map to Nodes. However the present disclosure is extensible to any system- required mapping, including explicitly tracking the order of distribution. This also supports explicit control over the distribution of unique Data Items, for example specific sets of singular or groups of Highly- Entropic Strings. In this case a Group ID may be created to uniquely categorise and manipulate the Data Items differently from similar Item distributions (i.e. those with otherwise matching distributions amongst system Nodes).

[0252] It will be understood that when highly-entropic strings are distributed through a key management system, such as the key management system of figure 3, comprising multiple nodes, such as agents or other nodes, such as key agreement agents 308, there may be issues with synchronisation of the state of the system at any time. This is because any Agent or Node of the system cannot be guaranteed to have a current knowledge of the state of all instances of the highly-entropic strings and related data throughout the full system. For example, if one agent or node takes an action in relation to a particular instance of highly- entropic string it will take a finite time for other nodes of the system to be informed of this, giving rise to a risk that different nodes of the system will make different changes to different instances of the same highly-entropic string, desynchronizing the highly-entropic strings and related data, and so render these different instances of the highly-entropic string unusable. Such desynchronization of data across the system can be extremely harmful to operation of the system, for example potentially rendering the keys provided to end users useless. The time taken for other nodes of the system to be informed of a change made by a node may beparticularly long in examples where some communications links of the system are not always available, for example satellite communications links in an SQKD system.

[0253] In general terms, in a third aspect, the present disclosure provides a method of synchronising the state of data, such as highly-entropic strings and related data, across the system at any time, which addresses this problem. In the present application, this approach uses a concept referred to as Key Distribution Agent Affinity or agent affinity. This is an Internal and User Key Management concept, which can be used when Highly-Entropic Strings are to be distributed to a group of nodes, such as QKA Nodes, over time, whereby the distribution state of each Highly-Entropic String is managed to ensure that there are no conflicts between different actors across the system, for example, as a result of communication latency.

[0254] Any data management system consisting of multiple Agents that generate, distribute and store data will necessarily have potential issues with synchronisation of the state of the system at any time. Any Agent or other Node can never be guaranteed of having current knowledge of the state of all instances of the data throughout the full system. For example, in the key management system 300 of figure 3, any of the key agreement agents 308 and the key agreement nodes 310 cannot be guaranteed of having current knowledge of the state of all instances of a highly-entropic string throughout all of the other key agreement agents 308 and key agreement nodes 310 of the key management system 300.

[0255] As discussed previously, a Symmetric Highly-Entropic String is a unique string with high entropy along with associated metadata, describing the distribution state and use, that must be stored, accessed, and modified across multiple system Nodes in operation of a key distribution and / or management system. There will be multiple instances of each Highly- Entropic String , i.e. duplicated instances of the same highly-entropic string, throughout the System at different Nodes. In the present method the highly-entropic strings are formed into uniquely identifiable Data items, which may each be a Highly-Entropic String or a Store of multiple Highly-Entropic Strings.

[0256] A key distribution system comprises a plurality of agents. Each Agent is an entity that can read, write, and modify the data (typically the Highly-Entropic String metadata) within a Storage Array collectively formed by a collection of Key Stores which collectively form the Key distribution system. Each Key Store is a device that enables the storage and retrieval of the Highly-Entropic Strings, and these Key Stores typically reside within the domain of individual Agents.

[0257] The key distribution system further comprises at least one system manager, which is a governing entity that manages the actions on the data within the Storage Array (i.e. reading,writing and synchronisation of Keys and metadata). These actions are enacted by commanding the actions of individual Agents. As will be explained below, the at least one system manager enforces the Agent Affinity.

[0258] In examples where the method is carried out by the key management system 300 of figure 3 acting as the key distribution system, key agreement agents 308 and the key agreement nodes 310 will act as the Agents, with the Storage Array being formed by the various key stores 414, 416, 426 and 428 associated with the different key agreement agents 308 and key agreement nodes 310. The system manager 306 will operate as the one or more system manager(s) controlling sessions carried out by the key agreement agents 308 and key agreement nodes 310, and setting and releasing affinity of Data Items to different ones of the key agreement agents 308 and key agreement nodes 310.

[0259] In the key distribution agent affinity method, one or more System Manager(s) enforce an Agent Affinity to each Data Item (i.e. Highly-Entropic String or a Store of Highly-Entropic Strings), such that only the Agent with the Affinity may create, modify, delete, or in any other way access the data item, for a use other than inspecting the state of the Highly-Entropic String (without changing that state). Such an access to the data item is referred to as a ‘Session’ herein. A session is a unique interaction between an Agent and a System Manager, during which Highly-Entropic Strings are either created, modified, or deleted. Locking a Data Item to a single Agent in this way means that only one instance of a particular Data Item may be modified at any one time, preventing multiple conflicting copies throughout the system. This Affinity is applicable to all instances of a Data Item in the system. This concept requires that all Sessions are controlled by the System Manager(s) and no Agent may have the ability to perform an action on a Data Item without command or permission from a system manager. This method may also enable the one or more System Manager(s) to have full knowledge of the state of the Key distribution system at any one time.

[0260] Since the Affinity of a single Data Item is locked upon modification in a session, the key distribution agent affinity method also provides for System Manager(s) to unlock a data Item for Sessions with other Agents. In order to do this, at an arbitrary point, the system manager(s) may command a Synchronisation process to reconcile any changes introduced to the Data Item across all instances of the Data Item throughout the system. In the synchronisation process the Agent currently with Affinity of the Data Item communicates the changes to all other Agents throughout the system (typically via the System Manager(s)). The other Agents which have an instance of the data item then perform Synchronisation Sessions, updating their respective instances of the Data Item to match the current state of the data item according to the Agent currently with Affinity of the Data Item. Once all Agents have confirmed the updates to the System Managers, the instances of the data item areknown to be synchronised across the entire system, the Affinity is unlocked and Sessions of the data item with other agents may be created, and a new Affinity assigned to the Data Item accordingly.

[0261] A specific example of a system where the Agent Affinity mechanism may be useful is a system comprising multiple geospatially distributed Key Stores, managed by several Agents. In such a system, the large geospatial separation imposes challenges to the Synchronisation of Data Items.

[0262] Figure 12 shows a general overview of a method 1100 which may be carried out by a key distribution and / or management system, such as the system 300, when it is desired to carry out a session in which an agent, such as one of the key agreement agents 308 and key agreement nodes 310, accesses a specific data item stored in the system 300. In the example where the method 100 is carried out by the system 300 the data item will be stored in a key store of the key agreement agent 308 or key agreement node 310 which is the agent, but other examples may have alternative or additional key stores.

[0263] The method 1100 begins with an initial request session block 1102 in which the agent 308 / 310 interacts with the system manager 306 and the agent 308 / 310 requests, or is requested / instructed by the system manager 306, to carry out a session with one or more data items. The agent 308 / 310 requesting or being requested to carry out a session is described as the agent 308 / 310 having a request to carry out a session, this wording being agnostic regarding the source of the request, which may originate from the agent 308 / 310 or the system manager 306.

[0264] Then, in a check affinity block 1104, the system manager 306 checks whether each of the one or more data items has an affinity stored, and if so, to which agent. In the illustrated example the affinities of data items to agents are stored in the data store 604 of the system manager 306. However, this is not essential, and other storage locations may be used in alternative examples.

[0265] If the check affinity block 1104 determines that the one or more data items have a stored affinity to the agent 308 / 310 carrying out the method 1100 having the session request (that is, which made or received the session request), the system manager 306 instructs the agent 308 / 310 to proceed with the requested session with the one or more data items in a proceed block 1106. The stored affinity of the one or more data items is not changed.

[0266] Alternatively, if the check affinity block 1104 determines that the one or more data items have no stored affinity to any agent, the system manager 306 instructs the agent 308 / 310 to proceed with the requested session with the one or more data items, and storesan affinity of the one or more data items to the agent 308 / 310 carrying out the method 1100 in the data store 604 in a proceed and store affinity block 1108.

[0267] Alternatively, if the check affinity block 1104 determines that the one or more data items have a stored affinity to another agent different from the agent 308 / 310 carrying out the method 1100, the system manager 306 instructs the agent 308 / 310 not to proceed with the requested session with the one or more data items in a do not proceed block 1110. The stored affinity of the one or more data items is not changed.

[0268] It will be understood that the method 1100 may be triggered by either the agent 308 / 310 or the system manager 306, as necessary in operation of the system 300.

[0269] Figure 13 shows a more detailed data item modification method 1200 which may be carried out by a key distribution and / or management system, such as the system 300, when one or more data items are to be modified within the storage array. The data modification method 1200 is a more detailed and specific version of the method 1100. The modification method 1200 includes the modification of the data items being the deletion of the data items, so the modification method 1200 may be regarded as a modification or deletion method. In examples where the system 300 is an S-QKA system the modification method 1200 may be carried out as part of the Agreement session. For modification, this could apply to the updates applied to the metadata in the Nodes with existing instances of the Data Items, after a creation step. For deletion, this could apply to a fully distributed state, or a point where the Highly-Entropic material of the data item is consumed (e.g. Key Formatting or Key Harvesting), or where the data must be removed from the system, for example on detection of corruption or compromise of a data item.

[0270] The data modification method 1200 begins with an initial request modification / deletion block 1202 in which the agent 308 / 310 interacts with the system manager 306 and the agent 308 / 310 requests, or is requested / instructed by the system manager 306, to modify or delete one or more data items. The agent 308 / 310 requesting or being requested to modify or delete is described as the agent 308 / 310 having a request to modify or delete, this wording being agnostic regarding the source of the request, which may originate from the agent 308 / 310 or the system manager 306.

[0271] Then, in a check affinity block 1204, the system manager 306 checks whether each of the one or more data items has an affinity stored, and if so, to which agent. In the illustrated example the affinities of data items to agents are stored in the data store 604 of the system manager 306. However, this is not essential, and other storage locations may be used in alternative examples.

[0272] If the check affinity block 1204 determines that the one or more data items have a stored affinity to the agent 308 / 310 carrying out the method 1200 which made or received the modify or delete request, in a proceed block 1206, the system manager 306 instructs the agent 308 / 310 to proceed with the requested modification or deletion with the one or more data items. Then, in a recording block 1212, the system manager 306 records in association the Agent, Session ID, data store (for example Key Store), and Data ltem(s) IDs that have been modified or deleted. This recording may be made in the data store 604. In this case the stored Affinity of the Data ltem(s) to the agent 308 / 310 is not changed.

[0273] Alternatively, if the check affinity block 1204 determines that the one or more data items have no stored affinity to any agent, in a proceed block 1208 the system manager 306 instructs the agent 308 / 310 to proceed with the requested modification or deletion with the one or more data items. Then, in a recording block 1214, the system manager 306 records in association the Agent, Session ID, data store (for example Key Store) and Data ltem(s) IDs that have been modified or deleted, and stores an Affinity of the Data ltem(s) to the agent 308 / 310. This recording may be made in the data store 604.

[0274] Alternatively, if the check affinity block 1204 determines that the one or more data items have a stored affinity to another agent different from the agent 308 / 310 carrying out the method 1200 which made or received the modify or delete request, the system manager 306 instructs the agent 308 / 310 not to proceed with the requested modification or deletion with the one or more data items in a do not proceed block 1210. The stored affinity of the one or more data items is not changed.

[0275] It may be regarded as counter-intuitive to store an affinity of a data item which has been deleted, but this is necessary until the deletion has been synchronized across the entire system, in order to ensure that the deletion of the data item is carried out across all instances of the data item held by the system.

[0276] Figure 14 shows a more detailed data item reading method 1300 which may be carried out by a key distribution and / or management system, such as the system 300, when one or more data items are to be read within the storage array by an agent. The data reading method 1300 is a more detailed and specific version of the method 1100. In examples where the system 300 is an QKA system, such as an S-QKA system, the data reading method 1300 may be carried out as part of a polling of the state of the system by a Node, Agent or System Manager.

[0277] The data reading method 1300 begins with an initial request reading block 1302 in which the agent 308 / 310 interacts with the system manager 306 and the agent 308 / 310 requests, or is requested / instructed by the system manager 306, to read one or more dataitems. The agent 308 / 310 requesting or being requested to read is described as the agent 308 / 310 having a request to read, this wording being agnostic regarding the source of the request, which may originate from the agent 308 / 310 or the system manager 306.

[0278] Then, in a check affinity block 1304, the system manager 306 checks whether each of the one or more data items has an affinity stored, and if so, to which agent. In the illustrated example the affinities of data items to agents are stored in the data store 604 of the system manager 306. However, this is not essential, and other storage locations may be used in alternative examples.

[0279] If the check affinity block 1304 determines that the one or more data items have a stored affinity to the agent 308 / 310 carrying out the method 1300 which made or received the read request, in a proceed block 1306, the system manager 306 instructs the agent 308 / 310 to proceed with the requested data read with the one or more data items. Then, in a recording block 1312, the system manager 306 records in association the Agent, Session ID, data store (for example Key Store) and Data ltem(s) IDs that have been read. This recording may be made in the data store 604. In this case the stored Affinity of the Data ltem(s) to the agent 308 / 310 is not changed.

[0280] Alternatively, if the check affinity block 1304 determines that the one or more data items have no stored affinity to any agent, in a proceed block 1208 the system manager 306 instructs the agent 308 / 310 to proceed with the requested read with the one or more data items. Then, in a recording block 1314, the system manager 306 records in association the Agent, Session ID, data store (for example Key Store) and Data ltem(s) IDs that have been read, and stores an Affinity of the Data ltem(s) to the agent 308 / 310. This recording may be made in the data store 604.

[0281] Alternatively, if the check affinity block 1304 determines that the one or more data items have a stored affinity to another agent different from the agent 308 / 310 carrying out the method 1300 which made or received the read request, the system manager 306 instructs the agent 308 / 310 not to proceed with the requested read with the one or more data items in a do not proceed block 1310. The stored affinity of the one or more data items is not changed. In some circumstances, a polling for state information regarding the one or more Data ltem(s) may still be carried out if necessary.

[0282] Although a read of the data items will not change the data items, if the data items are not synchronized across the system, it is important that only the "correct" version for which the reading Agent has affinity should be read because this is the version to which all instances of the data items will be synchronized in due course. Further, it is important that after the data items have been read by an Agent the data items are not changed by anotherAgent before the reading agent takes action based on the results of the read. Accordingly, any read data items having no affinity will have an affinity with the reading Agent stored, to block other Agents from making changes to the data items. It will be understood that actions should only be taken based on a polling of the state of the system which is based on reading synchronized data items, or the version of the data item which the system is going to be synchronised to.

[0283] Figure 15 shows a data item creation method 1400 used by the system 300 when data items are created within the storage array. Although the method 1400 has similarities to the method 1100, the data creation method 1400 is not a version of the method 1100. It will be understood that the data creation method 1400 begins with the data items not yet existing, so that the method 1100 cannot be applied.

[0284] In examples where the system 300 is an QKA system, such as an S-QKA system, the data creation method 1400 may be used in the QKD session, generating the Highly-Entropic Strings comprising a data item between the Agent (QKD Satellite) and Node (QKD Ground Station). In another example, the method 1400 may also be applicable to an allocation step, where the Highly-Entropic material and any related metadata of the data item must be created at a Node that does not currently have an instance of the Highly-Entropic material.

[0285] The data creation method 1400 begins with an initial request data creation block 1402 in which the agent 308 / 310 interacts with the system manager 306 and the agent 308 / 310 requests, or is requested / instructed by the system manager 306, to create one or more data items. The agent 308 / 310 requesting or being requested to create data items is described as the agent 308 / 310 having a request to create data items, this wording being agnostic regarding the source of the request, which may originate from the agent 308 / 310 or the system manager 306.

[0286] In a selection block 1404, the system manager 306 selects a key store where the created one or more data items are to be stored. In the illustrated example where the system 300 carries out the method 1400 this may be a key store of the agent 308 / 310. However, other data stores may be used instead of a key store in alternative examples. Further, in a create ID step 1406, the system manager 306 creates and assigns a unique session ID to identify the data creation session, that is, the interaction with the Agent, associated with the action on the Data Items(s). The unique session ID does not need to be universally unique, provided that it is sufficiently unique that there are no duplicate session IDs in use on the system at the same time.

[0287] The agent 308 / 310 carries out the appropriate action necessary to create the requested one or more data items in a create data items block 1407. The process used tocreate the data items is not significant for the method 1400, and any suitable process may be used. The agent 308 / 310 then, in a write block 1408, writes the created one or more data items to the selected key store and attaches the created session ID to each of the created one or more data items.

[0288] Finally, in a recording block 1410, the system manager 306 records in association the Agent, Session ID, data store (for example Key Store) and Data ltem(s) IDs that have been created, and sets and stores the Affinity of the Data ltem(s) to the creating agent 308 / 310.

[0289] Figure 16 shows a data item synchronization method 1500 used by the system 300 in order to synchronize the status of one or more data items throughout the system 300. The synchronization method 1500 is not a version of the method 1100. The synchronization method 1500 may be regarded as a specific version of data item modification where any element of the system 300 may be required to update the state of an instance of one or more data items in line with one or more sessions executed at another element of the system 300.

[0290] The synchronization method 1500 begins with an initial request synchronization block 1502 in which the system manager 306 determines that one or more agents 308 / 310 in the system 300 should synchronize one or more sessions. This determination may be made on any desired basis as appropriate to a particular implementation of the system and method. In order for synchronization to be required there must be data items that are not synchronized present at one or more agent 308 / 310 of the system 300. However, the determination that synchronization should be carried out is not necessarily made immediately it is known that there are unsynchronized data items, although synchronization may be caried out immediately in some examples. In other examples, the synchronization may be carried out periodically, and / or based on the availability of intermittent communication links, such as satellite communication links, and / or based on the refusal of requested sessions because the relevant data items are not synchronized. This list of examples is not intended to be exhaustive.

[0291] Then, in a check affinity block 1504 the system manager 306 looks up the stored affinity related to the session ID(s) of the one or more sessions in the data store 604 and identifies the agent with affinity. That is, the agent having stored affinity of the one or more data items related to the session ID(s) of the one or more sessions (As is explained above, the Agent, Session ID, and Data ltem(s) IDs are all stored in association). In the illustrated example this is stored in the data store 604 of the system manager 306. However, this is not essential, and other storage locations may be used in alternative examples.

[0292] Then, in a session command block 1506, the system manager 306 creates a Session command to synchronise the one or more sessions and sends the created session commandto all of the Agents 308 / 310 which have, or require, an instance of the Data ltem(s) associated with the one or more sessions, and so require synchronization. This Session command will include metadata for the Session ID, data store (for example Key Store) and Data ltem(s) IDs.

[0293] Then, after receiving the respective session command, in a command execution block 1508, each of the commanded Agents 308 / 310 receiving the command synchronizes the instance of the Data ltem(s) associated with the one or more sessions stored in their data store (for example the key store) with the instance(s) of the Data ltem(s) stored in the data store (for example the key store) of the Agent 308 / 310 identified as having affinity. Each of the commanded agents 308 / 310 compares the Data ltem(s) stored in its data store with the Data ltem(s) stored in the data store of the Agent 308 / 310 having affinity, and executes the necessary functionality (creating, modifying or deleting an instance of the Data ltem(s)) in their data store to bring the stored Data ltem(s) into agreement, and then sends confirmation of synchronisation confirming that this has been done to the system manager 306. For example, if a data item W is present in an Agent data store and is not present in the data store of the Agent having affinity, the Agent data store will create a copy the data item Wto synchronise, if a data item X is present, but different, in the two data stores, the Agent data store will modify the data item X to synchronise, if a data item Y is present and the same in both data stores, the Agent data store will take no action, if a data item Z is missing in the data store of the agent having affinity but is present in the Agent data store, the Agent data store will delete data item Z to synchronise.

[0294] In an alternative arrangement of the command execution block 1508, each of the commanded Agents 308 / 310 receiving the command instructs their data store (for example their key store) to synchronizes the stored instance of the Data ltem(s) associated with the one or more sessions. The data stores then cooperate to compare the Data Items(s) they have stored and to create, modify or delete the stored Data ltem(s), or parts thereof, to synchronise their stored Data ltem(s). In order to resolve conflicts between the Data ltem(s) stored in the different data stores the Session IDs are used, with the data store with the latest (that is, most recent) Session ID being taken as having the "true" or current intended version of the Data ltem(s) and other data stores creating, modifying or deleting the stored Data ltem(s), or parts thereof, to agree with this true version. For example, if a data item W is present in data store 1 and not present in Data store 2, and the session ID of data store 1 is more advanced than that of data store 2, data store 2 will create a copy the data item W to synchronise, if a data item X is present, but different, in the two data stores, the data store 2 will update data item X as per the data store 2, to synchronise, if a data item Y is present and the same in both data stores, the data store 2 will take no action, if a data item Z is missing in data store 1 but is present in data store 2, data store 2 will delete data item Z to synchronise.At the end of the process data store 2 will update its session ID to be same as that of data store 1 and both data stores have same data blocks and there is no need for affinity till something changes in one of the data stores. It will be understood that the data store of the Agent 308 / 310 having affinity will have the latest session ID, so this alternative arrangement of the command execution block will have the same result of synchronisation of the Data ltem(s).

[0295] On receipt of the confirmation of synchronisation from all of the commanded Agents 308 / 310, in a clear affinity block 1510, the System Manager 306 will clear (that is, delete or otherwise remove) the stored Affinity of the one or more Data ltem(s) in the data store 604. It will be understood that there is no requirement to assign an affinity to Data Items which are synchronized.

[0296] Accordingly, the one or more sessions and one or more data items will be synchronized across the system 300.

[0297] In the example of set out above, in the session command block 1506, the system manager 306 sends the session command to all of the Agents 308 / 310 which have, or require, an instance of the Data ltem(s) associated with the one or more sessions. In some examples, the system manager may not send the session command to the Agent 308 / 310 having affinity because the Agent 308 / 310 having affinity will not need to synchronise Data Items to other Agents 308 / 310.

[0298] The use of the methods set out above ensures that synchronisation of data items throughout the system is explicitly tracked and managed by the one or more system Managers, allowing for flexible commanding of actions on the Highly-Entropic String material (such as delivery or otherwise modifying). As is explained in the examples above, this may be implemented as actions being carried out on-command from the system manager(s) or carried out on-request from agents and / or nodes of the system, provided that a central system Manager will have full knowledge of the state of the actions carried out and the Agents with allowable control, using the methods to prevent conflicting modifications.

[0299] The description above separately describes single instances of each of the methods 1100 to 1500. However, it will be understood that in operation of the key distribution system or key management system their will typically be a large number, and possibly a very large number, of different ones of the methods 1100 to 1500 being executed by the system at any time.

[0300] Although the methods set out above are described in terms of a sequence of ordered blocks, it will be understood that the order in which the different blocks are carried out may bechanged from the order described. In particular, some of the different blocks of the methods may be carried out simultaneously. Further, it will be understood that multiple different instances of the different methods may be carried out simultaneously by the system 300 in relation to different data items.

[0301] The disclosed methods of synchronising the state of data according to the third aspect described above provide the concept of controlling the ownership of multiple uniquely identifiable, independent Data Items, such that they may be stored, accessed, and modified across multiple Nodes across a system, whilst maintaining data consistency between them, for example to enable Group key delivery of identical encryption keys to multiple different nodes of the system. Accordingly, the disclosed methods provide a method of tracking and reconciling the state of the Key material distribution amongst groups of Agents, overcoming challenges of maintaining conflict-free distribution.

[0302] The disclosed methods may be particularly advantageous in systems where one or more of the following holds true:Multiple Data Items must be stored across multiple Storage Devices.Data Items can only be created or modified or deleted by one Storage Device at a time.Access to data items by any Agent from any storage device must be secured and / or logged.Synchronisation of Data Items between Storage Devices can only occur infrequently, i.e. Reading and writing Data Items occurs more frequently than synchronisation.Synchronisation of Data Items may randomly fail to complete.However, the use of the disclosed methods is not limited to systems having one or more of these characteristics.

[0303] The use of the method in a Key Management system, such as the key management system 300, that distributes symmetric Highly-Entropic Strings may provide advantages and enhance and improve operation of the system, since it allows for multiple instances of a Highly-Entropic String to exist across multiple Nodes of the system, where multiple agents may update any one instance, with this update being propagated / synchronised amongst the rest of the instances of the Highly-Entropic String system-wide. This prevents an update of one instance of the Highly-Entropic string at one node from invalidating the other copies of the Highly-Entropic string elsewhere across the system. This is especially beneficial for a systemwhere there is high latency or sporadic connectivity between Nodes, for example an S-QKA system, where communicating updates of the state to all agents may take a long time, so there is a high likelihood of the distribution and consumption of entropy while an update elsewhere in the system is awaiting communication.

[0304] It should be noted that the described method of synchronising the state of data according to the third aspect is not prescriptive about the ownership of the creation of Sessions. As is discussed above for the individual method examples, for any action other than for system-wide synchronisation, both the System Manager or any individual Agent may command or request an action. As is explained above, while it is not essential, it may be advantageous for the System Manager to act as the central arbiter of Sessions and to operate to not allow a requested action to take place for an Agent and Data Item if the Affinity of the Data Item is associated with another Agent. This enhancement allows for flexibility of the system implementation with the potential for a more distributed control of the Storage Array and system Nodes, without the risk of desynchronization where instances of the same data item at different nodes are different, rather than identical.

[0305] The described method of synchronising the state of data according to the third aspect does not prescribe or require the Highly-Entropic material being associated with the Affinity in any specific way. The Highly-Entropic material may be associated with the Affinity in any convenient manner in any specific implementation. The term Data Item has been used herein, and this is intended to be an abstraction covering both a Data Item being an individually- addressable Highly-Entropic String or strings, and a Data Item being a partial or entire Key Stores within the system, which may comprise large numbers of Highly-Entropic Strings, and any other scale. This enhancement allows for the flexibility of controlling the activities for different aspects of a Key management system as desired in any specific implimentation.

[0306] The described method of synchronising the state of data according to the third aspect does not constrain or specify the method of symmetric Highly-Entropic String distribution used by the system executing the method. The method is applicable to any scale of system with multiple Agents controlling a number of Key Stores where there are multiple instances of unique Highly-Entropic Strings. QKA is an example of a system that falls into this category, since it may have multiple QKD Transmitters creating Highly-Entropic Strings with a number of QKD Receivers. These Highly-Entropic Strings are pairwise, however a QKA system that further distributes these Highly-Entropic Strings amongst groups of QKA Nodes in an allocation step may use the described method to ensure that any of the Nodes (either the distribution entities, e.g. Satellites for an S-QKA system, or QKA nodes) do not cause conflicts.

[0307] The use of the The Group Key Distribution History and Key Distribution Agent Affinity concepts allow for flexible systems made up of many Agents and Nodes, supporting group Keys and a non-prescriptive delivery process. This includes dynamic Key material indexing and also removes any need for constraints on the delivery timeliness or order. This enables a Key Management system to cope with challenging implementations, for example a S-QKA system, where bandwidth and connectivity are not guaranteed.

[0308] The Agent Affinity method of the third embodiment is described herein in terms of application to a Key management system. However, the Agent Affinity method is not limited to use in a key management system, and may be used in other types of systems comprising distributed data instances.

[0309] The illustrated third embodiment of the agent affinity method is described with reference to the use of the method with the key management system 300 of figure 3, which uses QKD. However, the present disclosure is not limited to systems which use QKD, and may be used in systems using other methods for generating symmetric Highly-Entropic material in a secure manner, and in particular in an information theoretic secure manner, between different nodes.

[0310] The first to third aspects described above provide methods whereby shared Highly- Entropic Strings may be distributed throughout a system, such as the key management system 300 of figure 3. However, although the provision of shared Highly-Entropic Strings to appropriate points in a key management system is required in order to allow the system to provide symmetric keys on demand to end users, or for internal system use, this is not sufficient in itself to ensure that the required symmetric keys can be provided. In practice, in addition to distributing shared Highly-Entropic Strings throughout a system, it is also necessary to ensure that the correct symmetric material is correctly formatted into Keys at the different nodes of the system requiring Keys for use or for issue as end user keys in order to ensure that the instances of each key at the different nodes are identical.

[0311] This is especially a concern where the Highly-Entropic Strings may not be distributed / generated at the Nodes on demand, for example in the case where there is a potential delay in the distribution process for either pairwise or group Keys to two or more nodes, such as in an S-QKA Key Management system where QKD sessions are dependent on intermittent Satellite visibility.

[0312] In such examples where the highly-entropic strings may be received at different nodes at significantly different times conventional methods of generating keys from the received highly-entropic strings at the different nodes have been found to suffer from problems in ensuring correct and consistent mapping at the different nodes of the receivedhighly-entropic strings to the corresponding formatted keys, such as system keys or user keys. Any inconsistency in this mapping at the different nodes will result in the generated keys at the different nodes not matching, so that they cannot be used.

[0313] In general terms, in a fourth embodiment, the present disclosure provides a method whereby, in such cases, the shared Highly-Entropic String (or set of Strings) may be buffered at the Node, and used to generate the Symmetric Keys on demand, through a process defined as ‘Key Formatting’. The buffering of Highly-Entropic String material at the system Nodes also allows for on demand Symmetric Formatted Keys to be created from the shared highly-Entropic String(s), using an appropriate method to generate the end user / device Keys.

[0314] This key formatting according to the fourth embodiment is a User Key Management concept, useable once the Highly-Entropic Strings have been distributed to the pair / group of QKA Nodes over time, whereby the next step of the key management and distribution process can consume the shared Highly-Entropic String in a synchronous way, such that every QKA node delivers the same Formatted Keys to the end user / devices, tracking the Formatted Key delivery process.

[0315] An overview of the key formatting according to the fourth embodiment is that when the Highly-Entropic String material is shared and distributed across multiple Nodes, at each node the Highly-Entropic String material is buffered on creation or distribution and is subsequently taken from the buffer and dynamically used to generate the Formatted Keys based upon the real time instantaneous demand by the end users / devices for keys.

[0316] Figure 17 shows a shows a schematic diagram of an example of a part of the key management system 300 arranged to use key formatting according to the fourth embodiment.

[0317] As shown in figure 17, the key formatting method is executed within the key agreement nodes 310 of the key management system 300. Figure 16 shows three of the key agreement nodes 310, key agreement nodes 310a, 310b and 31 On, but there may be any number of key agreement nodes 310 in the system 300.

[0318] As shown in figure 17, similarly to the system 300 shown in figure 3, each key agreement node 310a-n receives shared highly entropic material, specifically highly-entropic string material from other parts of the system 300, and in particular from the key agreement agents 308, as described above with reference to figure 3. Further, also similarly to the system 300 shown in figure 3, each key agreement node 310a-n provides formatted user keys to one or more respective end user devices 302a-n.

[0319] As shown in figure 17, each key agreement node 310 comprises a respective key buffer store 1600, key recipe store 1602, and key formatter 1604. As is explained above, in operation of the key management system 300, each key agreement node 310 receives or creates highly entropic material, specifically highly-entropic string material, from, or in cooperation with, other parts of the system 300, and in particular the key agreement agents 308, and stores the received or created highly-entropic string material in the buffer store 1600. Further, in operation of the key management system 300 each key agreement node 310 is provided with shared formatting instructions, referred to as key recipes, from other parts of the system 300, and stores these key recipes in the key recipe store 1602.Accordingly, each key agreement node 310 is provided with a respective pool of shared Highly-Entropic Strings, as well as shared formatting instructions, so that all of the key agreement nodes 310 can use these shared Highly-Entropic Strings and shared formatting instructions to generate the same formatted keys on demand.

[0320] In some examples, each set of shared formatting instructions (key recipe) may include, for one or more keys to be generated: an ID for the formatted keys to be generated, a size of the formatted keys to be generated, identities of end nodes at which the formatted keys are to be generated; portion(s) of the highly-entropic strings to be used to generate the formatted keys, and the method to be used to generate the formatted keys from the portion(s) of highly-entropic strings. This list of possible contents is by way of example only, and the shared formatting instructions may include additional or fewer elements in other examples.

[0321] Figure 18 shows a method 1700 used by a key agreement node 310 of the system 300 in order to provide formatted user keys to one or more respective end user devices 302.

[0322] In operation of the system 300, when the key agreement node 310 obtains shared highly-entropic string, by creating or receiving the shared highly-entropic string, the key agreement node 310 buffers or stores the highly-entropic string in the buffer store 1600, in a buffering block 1702.

[0323] Further, when the key agreement node 310 obtains a key recipe, by agreeing or receiving the key recipe, the key agreement node 310 stores the key recipe in the key recipe store 1602, in a recipe storing block 1704. Each key recipe includes identifiers of the parts, typically expressed as bits or blocks, of the symmetric highly-entropic strings which map to identifiers for the formatted keys to be generated. Optionally, each key recipe may also specify a process or method that describes how the formatted key is to be generated from the symmetric highly-entropic strings.

[0324] Then, in a key request block 1706, the key agreement node 310 receives a request for a number of formatted symmetric keys from an end user device 302, the requestidentifying the other end user devices 302 with which the requested formatted symmetric keys are to be used. This may be one other end user device 302 for a bilocation key shared by two end user devices 302, or plural other end user devices 302 for a group key shared by multiple (three or more) end user devices 302. In response, in a key generation block 1708, the key formatter 1604 of the key agreement node 310 uses highly-entropic string from the buffer store 1600 which is shared with the identified end user device(s) 302 and follows a key recipe from the key recipe store 1602 which is shared with the identified end user device(s) 302 to generate formatted keys.

[0325] Then, in a deliver keys block 1710, the key agreement node 310 delivers the formatted keys generated by the key formatter 1604 to the end user device 302.

[0326] It will be understood that because the key formatters 1604 of the different key agreement nodes 310 providing respective end user devices with shared symmetric keys each use a respective pool of shared Highly-Entropic Strings, and shared formatting instructions, to generate the shared symmetric keys, all of the respective generated shared symmetric keys are identical. This approach of buffering the shared Highly-Entropic String material on generation or reception, and subsequent use to generate symmetric keys on demand provides more consistent mapping of the shared highly entropic string material to shared symmetric keys at the different key agreement nodes 310, providing shared symmetric keys at the different nodes which matching more reliably, improving the reliability and efficiency of the key management system 300.

[0327] The fourth embodiment is not limited to any specific method for generating or sharing key recipes between the different key agreement nodes 310, and the method used may be selected as appropriate in any specific implementation. One example of a possible method is a node-initiated, generated, approach in which a Recipe may be shared on demand by a Node, where one Node will generate a Recipe and this Recipe is then shared amongst the rest of the Nodes, or the rest of the subset of Nodes requiring a common shared set of Symmetric Formatted Keys. Another example of a possible method is a Node-Initiated, Preshared approach where a set of predefined Recipes may be shared amongst the Nodes, based on the predicted Symmetric Key demand by the end users / devices. When a Key is requested, a recipe may be drawn from a pool of predefined Recipes, agreed with all Nodes serving the endpoint Users. Another example of a possible method is a Node- Initiated, Centrally Generated approach where a Recipe may be generated on demand by a central System Management entity, on request from a Node. This recipe will then be distributed amongst the rest of the Nodes. Another example of a possible method is Managed, where a Recipe may be pre-shared or generated on demand by a central System Management entity and distributed to the Nodes.

[0328] In the listed examples, in the Node-initiated methods, one Node will act as the lead Node, commanding the Formatting and Recipe selection. The lead node may be determined in any convenient manner in any specific implementation.

[0329] This fourth embodiment is not limited to the use of any specific method for the Highly- Entropic Strings to be generated / distributed to the Nodes, or to be stored in the system, or any specific method for the Formatting process to index the data to be used to generate the Formatted Keys. For example the Highly-Entropic String(s) may be a single string of data, with Formatting reading an indexed portion, or alternatively the symmetric data may be stored in discrete blocks, with Formatting addressing specific objects. This allows flexibility in the system implementation which may have additional factors to consider.

[0330] The illustrated fourth embodiment of the key formatting method is described with reference to the use of the method with the key management system 300 of figure 3, which uses QKD. However, the present disclosure is not limited to systems which use QKD, and may be used in systems using other methods for generating symmetric Highly-Entropic material in a secure manner, and in particular in an information theoretic secure manner, between different nodes

[0331] Although the methods set out above are described in terms of a sequence of ordered blocks, it will be understood that the order in which the different blocks are carried out may be changed from the order described. In particular, some of the different blocks of the methods may be carried out simultaneously. Further, it will be understood that multiple different instances of the different methods may be carried out simultaneously by the system 300.

[0332] In the illustrated example the key agreement nodes 310 generate shared symmetric keys and provide the keys to end user devices. In other examples the generated shared symmetric keys may be provided to other elements requiring shared symmetric keys.

[0333] The embodiments described above are fully automatic. In some examples a user or operator of the system may manually instruct some steps of the method to be carried out.

[0334] In the described embodiments of the invention parts of the system may be implemented as a form of a computing and / or electronic device. Such a device may comprise one or more processors which may be microprocessors, controllers or any other suitable type of processors for processing computer executable instructions to control the operation of the device in order to gather and record routing information. In some examples, for example where a system on a chip architecture is used, the processors may include one or more fixed function blocks (also referred to as accelerators) which implement a part of the method in hardware (rather than software or firmware). Platform software comprising an operatingsystem or any other suitable platform software may be provided at the computing-based device to enable application software to be executed on the device.

[0335] Various functions described herein can be implemented in hardware, software, or any combination thereof. If implemented in software, the functions can be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer- readable media may include, for example, computer-readable storage media. Computer- readable storage media may include volatile or non-volatile, removable or non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. A computer-readable storage media can be any available storage media that may be accessed by a computer. By way of example, and not limitation, such computer-readable storage media may comprise RAM, ROM, EEPROM, flash memory or other memory devices, CD-ROM or other optical disc storage, magnetic disc storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Disc and disk, as used herein, include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and blu- ray disc (BD). Further, a propagated signal is not included within the scope of computer- readable storage media. Computer-readable media also includes communication media including any medium that facilitates transfer of a computer program from one place to another. A connection, for instance, can be a communication medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of communication medium. Combinations of the above should also be included within the scope of computer-readable media.

[0336] Alternatively, or in addition, the functionality described herein can be performed, at least in part, by one or more hardware logic components. For example, and without limitation, hardware logic components that can be used may include Field-programmable Gate Arrays (FPGAs), Program-specific Integrated Circuits (ASICs), Program-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), etc.

[0337] Although illustrated as a single system, it is to be understood that a computing device may be a distributed system. Thus, for instance, several devices may be in communication by way of a network connection and may collectively perform tasks described as being performed by the computing device. Although illustrated as a local device it will be appreciated that the computing device may be located remotely and accessed via a network or other communication link (for example using a communication interface).

[0338] The term 'computer' is used herein to refer to any device with processing capability such that it can execute instructions. Those skilled in the art will realise that such processing capabilities are incorporated into many different devices and therefore the term 'computer' includes PCs, servers, mobile telephones, personal digital assistants and many other devices.

[0339] Those skilled in the art will realise that storage devices utilised to store program instructions can be distributed across a network. For example, a remote computer may store an example of the process described as software. A local or terminal computer may access the remote computer and download a part or all of the software to run the program.Alternatively, the local computer may download pieces of the software as needed, or execute some software instructions at the local terminal and some at the remote computer (or computer network). Those skilled in the art will also realise that by utilising conventional techniques known to those skilled in the art that all, or a portion of the software instructions may be carried out by a dedicated circuit, such as a DSP, programmable logic array, or the like.

[0340] It will be understood that the benefits and advantages described above may relate to one embodiment or may relate to several embodiments. The embodiments are not limited to those that solve any or all of the stated problems or those that have any or all of the stated benefits and advantages. Variants should be considered to be included into the scope of the invention.

[0341] Any reference to 'an' item refers to one or more of those items. The term 'comprising' is used herein to mean including the method steps or elements identified, but that such steps or elements do not comprise an exclusive list and a method or apparatus may contain additional steps or elements.

[0342] As used herein, the terms "component" and "system" are intended to encompass computer-readable data storage that is configured with computer-executable instructions that cause certain functionality to be performed when executed by a processor. The computerexecutable instructions may include a routine, a function, or the like. It is also to be understood that a component or system may be localized on a single device or distributed across several devices.

[0343] Further, as used herein, the term "exemplary" is intended to mean "serving as an illustration or example of something".

[0344] Further, to the extent that the term "includes" is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term "comprising" as "comprising" is interpreted when employed as a transitional word in a claim.

[0345] The figures illustrate exemplary methods. While the methods are shown and described as being a series of acts that are performed in a particular sequence, it is to be understood and appreciated that the methods are not limited by the order of the sequence. For example, some acts can occur in a different order than what is described herein. In addition, an act can occur concurrently with another act. Further, in some instances, not all acts may be required to implement a method described herein.

[0346] Moreover, the acts described herein may comprise computer-executable instructions that can be implemented by one or more processors and / or stored on a computer-readable medium or media. The computer-executable instructions can include routines, sub-routines, programs, threads of execution, and / or the like. Still further, results of acts of the methods can be stored in a computer-readable medium, displayed on a display device, and / or the like.

[0347] The order of the steps of the methods described herein is exemplary, but the steps may be carried out in any suitable order, or simultaneously where appropriate. Additionally, steps may be added or substituted in, or individual steps may be deleted from any of the methods without departing from the scope of the subject matter described herein. Aspects of any of the examples described above may be combined with aspects of any of the other examples described to form further examples without losing the effect sought.

[0348] It will be understood that the above description of a preferred embodiment is given by way of example only and that various modifications may be made by those skilled in the art. What has been described above includes examples of one or more embodiments. It is, of course, not possible to describe every conceivable modification and alteration of the above devices or methods for purposes of describing the aforementioned aspects, but one of ordinary skill in the art can recognize that many further modifications and permutations of various aspects are possible. Accordingly, the described aspects are intended to embrace all such alterations, modifications, and variations that fall within the scope of the appended claims.

Claims

Claims1 . A method of operating a key management system comprising at least two nodes arranged to generate shared entropy, the method comprising: the at least two nodes cooperating to generate shared entropy at the at least two nodes; at each of the at least two nodes: allocating a first portion of the generated shared entropy for internal use within the system and allocating a second portion of the generated shared entropy for external use, wherein the size of the first portion of the generated shared entropy allocated for internal use is based on the amount of shared symmetric encryption key material for internal use stored at at least one of the at least two nodes; using the first portion of the generated shared entropy to generate shared symmetric encryption keys for internal use; and storing the shared symmetric encryption keys for internal use.

2. The method as claimed in claim 1 , wherein the size of the first portion of the generated shared entropy allocated for internal use is based on a comparison of the amount of shared symmetric encryption key material for internal use stored at at least one of the at least two nodes with a threshold value.

3. The method as claimed in claim 1 , wherein the size of the first portion of the generated shared entropy allocated for internal use is based on a length of time that the amount of shared symmetric encryption key material for internal use stored at at least one of the at least two nodes is expected to last.

4. A method of operating a key management system comprising at least two nodes arranged to generate shared entropy, the method comprising: the at least two nodes cooperating to generate shared entropy at the at least two nodes; determining an amount of shared symmetric encryption key material for internal use within the system stored at at least one of the at least two nodes; and based on the determination, either: at each of the at least two nodes: allocating a first portion of the generated shared entropy for internal use within the system and allocating a second portion of the generated shared entropy for external use; andusing the first portion of the generated shared entropy to generate shared symmetric encryption keys for internal use; and storing the shared symmetric encryption keys for internal use; or at each of the at least two nodes, allocating all of the generated shared entropy for external use.

5. The method as claimed in claim 4, wherein the determination is based on a comparison of the amount of shared symmetric encryption key material for internal use stored at at least one of the at least two nodes with a threshold value.

6. The method as claimed in claim 4, wherein the determination is based on a length of time that the amount of shared symmetric encryption key material for internal use stored at at least one of the at least two nodes is expected to last.

7. The method as claimed in any one of claims 4 to 6, wherein the size of the first portion of the generated shared entropy allocated for internal use is based on the amount of shared symmetric encryption key material for internal use stored at at least one of the at least two nodes.

8. The method as claimed in any preceding claim, wherein internal use within the system comprises using the shared encryption keys for encryption and / or authentication between the at least two nodes.

9. The method as claimed in any preceding claim, further comprising using the stored shared symmetric encryption keys for communication and / or authentication between the at least two nodes.

10. The method as claimed in any preceding claim, wherein the shared symmetric encryption key material for internal use comprises shared symmetric encryption keys for internal use.11 . The method as claimed in any preceding claim, wherein the generated shared entropy comprises symmetric Highly-Entropic Strings.

12. The method as claimed in any preceding claim, wherein external use comprises use by end point devices for the purpose of cryptographic services.

13. The method as claimed in any preceding claim, wherein external use comprises providing symmetric encryption keys to end point devices.

14. The method as claimed in any preceding claim, wherein the at least two nodes use the second portion of the generated shared entropy to generate symmetric encryption keys for external use.

15. The method as claimed in claim 14, wherein the system provides the generated symmetric encryption keys to end point devices.

16. The method as claimed in claim 14 or claim 15, wherein each of the at least two nodes stores the shared symmetric encryption keys for internal use separately from any symmetric encryption keys for external use.

17. The method as claimed in any preceding claim, wherein the allocating a first portion of the generated shared entropy for internal use is carried out after key post processing of the shared entropy between the at least two nodes.

18. The method as claimed in any one of claims 1 to 16, wherein the allocating a first portion of the generated shared entropy for internal use is carried out before key post processing of the shared entropy between the at least two nodes, and the method further comprises: separately carrying out key post processing of the first portion of the generated shared entropy and key post processing of the second portion of the generated shared entropy.

19. The method as claimed in any preceding claim, wherein, when the at least two nodes comprise a quantum key distribution (QKD) transmitter and a QKD receiver.

20. The method as claimed in any preceding claim, wherein the at least two nodes comprise a QKD transmitter and at least two QKD receivers.21 . The method as claimed in any preceding claim, wherein one of the at least two nodes sends a request for allocation of a first portion of the generated shared entropy for internal use to another one of the at least two nodes based on the amount of shared symmetric encryption key material for internal use stored at said one of the at least two nodes.

22. The method as claimed in claim 21 , wherein the key management system further comprises a control node, and the control node sends a request for allocation of a first portion of the generated shared entropy for internal use to the at least two nodes based on the amount of shared symmetric encryption key material for internal use stored at at least one of the at least two nodes.

23. The method as claimed in any preceding claim, wherein the key management system is a Quantum Key Agreement (QKA) system.

24. The method as claimed in claim 23, wherein the key management system is a Satellite Quantum Key Agreement (SQKA) system.

25. The method as claimed in any preceding claim, wherein the method is a computer implemented method.

26. A key management system comprising at least two nodes and arranged to carry out the method according to any preceding claim.

27. A computer-readable medium comprising code or computer instructions stored thereon, which, when executed by a processor unit, causes the processor unit to perform the computer-implemented method according to any one of claims 1 to 25.

Images