Node for quantum communication network, quantum communication network, and method for producing signed messages

Abstract

To provide a node for a quantum communication network, a quantum communication network, and a method for creating a signed message.SOLUTION: In a node 101 of a quantum key distribution (QKD) system which is connected to any number of other QKD nodes to form a quantum communication network, a quantum optical element subsystem 103 is a receiver, a transmitter or a combination of a receiver and a transmitter which encodes and / or decodes information onto an optical signal, and handles generation and measurement of QKD-coded signals. A post-processing module 109 processes a raw measurement into s secure key by applying filtering, error correction and privacy amplification algorithms. A key management subsystem 111 handles storage of keys and delivery of keys to user applications. A classical communication stack 105 communicates with a second node to perform filtering and the other operations as described above. An authentication engine 107 is used to determine whether a signal being received from the second node is trustworthy.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] SUMMARY OF THE INVENTION The embodiments described herein relate to nodes for a quantum communication network, a quantum communication network, and a method for creating signed messages. [Background technology]

[0002] Quantum key distribution is a technique for generating a completely random quantum key at two remote nodes that can be used for data encryption to ensure secure communication. The basic operating principle of QKD relies on encoding and measuring a quantum state, followed by a discussion between the two nodes over an authenticated classical channel. [Brief explanation of the drawings]

[0003] [Figure 1A] FIG. 1A is a schematic diagram illustrating the steps of a quantum key distribution (QKD) method. [Figure 1B] FIG. 1B is a schematic diagram of an exemplary transmitter for use in QKD. [Figure 1C] FIG. 1C is a schematic diagram of an exemplary receiver for use in QKD. [Figure 2] FIG. 2 is a schematic diagram of a node of a QKD system according to one embodiment. [Figure 3] FIG. 3 is a schematic diagram illustrating a method for authenticating a message using a MAC tag. [Figure 4] FIG. 4 is a schematic diagram illustrating a method for calculating a MAC tag. [Figure 5] FIG. 5 is a schematic diagram showing the key combiner decision logic interacting with the key module. [Figure 6] FIG. 6 is a schematic diagram illustrating a method for classical (non-post-quantum) key agreement. [Figure 7] FIG. 7 is a schematic diagram illustrating a method for quantum-resistant algorithm (post-quantum) key agreement. [Figure 8]FIG. 8 is a schematic diagram of a key combiner according to one embodiment. [Figure 9] FIG. 9 is a schematic diagram of a variation of the key combiner of FIG. [Figure 10] FIG. 10 is a schematic diagram of a method for signing a message according to one embodiment. [Figure 11] FIG. 11 is a schematic diagram of a quantum network with a shared public key database. [Figure 12] FIG. 12 is a schematic diagram of a quantum network having the nodes of FIG. DETAILED DESCRIPTION OF THE INVENTION

[0004] In a first embodiment, there is provided a node for a quantum communication network, the node comprising: an authentication unit and a quantum key distribution unit; the authentication unit is configured to authenticate a channel between the node and a second node in the quantum communications network to form an authenticated channel; the quantum key distribution unit is configured to enable distribution of quantum keys between the node and a second node, the quantum keys being selected and processed using communications over the authenticated channel to establish a first quantum key for the node and the second node; the authentication unit comprises key management logic, the key management logic configured to provide access to a plurality of different key types, the plurality of key types being provided by at least a plurality of pre-shared keys, a plurality of keys shared with the second node via the quantum key distribution unit, and a key shared with the second node via a classical communication channel; The authentication unit is configured to receive information regarding the operation of the quantum communications network and select at least one key type from a plurality of key types accessible via the key management logic to create an authentication key, and the authentication unit is configured to authenticate the channel using the authentication key.

[0005] The nodes enable authentication using a pre-shared key (PSK) store, keys generated by an electronic subsystem capable of combining various component cryptographic and private keys, including those from quantum cryptographic sources, as well as non-quantum cryptographic asymmetric key exchange primitives (using both classical and “quantum-resistant” algorithms). The selection, component parameters, and key combination function to form the authentication key can be dynamically adjusted depending on logic / algorithms that use as input, for example, entered key availability, user input / security policy, and / or various link and system performance metrics (which may change over time). The key is used as part of a message authentication code, which is generated based on the key and the classical communication message being authenticated. The message authentication code is transmitted with the message and independently calculated by the receiver (which has a similar authentication engine that communicates with the transmitter to ensure they process the key in the same way to obtain a symmetric key for use in the message authentication code calculation). Message authenticity is established if the recomputed code and the received code match.

[0006] The authentication unit may be configured to authenticate the channel by creating a signature for a message to be sent from the first node to the second node, the authenticated first node, where the signature is created by encrypting or hashing and encrypting at least a portion of the message using an authentication key. For example, the authentication unit may be configured to authenticate the channel using the Wegman-Carter protocol, in which the message is subjected to a keyed hash to create a tag of known length and then encrypted using the authentication key. Wegman-Carter codes provide information-theoretic security (ITS). Wegman-Carter message authentication codes may be computed using cryptographic keying material both to key the hash function and to encrypt the hash. The cryptographic keys used for the hash function and encryption may have different security properties.

[0007] In one embodiment, the key type is selected from PSK, QKD, and non-quantum cryptographic key exchange. Non-quantum cryptographic key exchange primitives include post-quantum cryptography (PQC) key encapsulation mechanism algorithms (also known as quantum-resistant algorithms), whose security is based on the assumption of the difficulty of certain problems for quantum computers. This includes classes of mathematical problems such as error-correcting codes (code-based cryptography), lattice theory problems (lattice-based cryptography), hash functions (hash-based cryptography), and multivariate equation systems (multivariate cryptography). The PQC key encapsulation algorithm may be Crystals-KYBER. Non-quantum cryptographic key exchange primitives may include conventional classical cryptography that relies on computational assumptions such as the difficulty of factorization (i.e., RSA-type algorithms) and the difficulty of the discrete logarithm problem (i.e., elliptic curve-type algorithms).

[0008] The information regarding operation of the quantum communications network is selected from at least one of a plurality of policies controlling the quantum communications network, a number of a plurality of pre-shared keys and a plurality of keys shared with the second node via the quantum key distribution unit and a plurality of keys shared with the second node via a non-quantum key exchange, a plurality of measurements regarding operation of the quantum communications network, and a plurality of parameters of a quantum key distribution session.

[0009] The authentication unit can be configured to select multiple keys of different types and combine the selected keys to create an authentication key. This allows the node to adapt to different requirements over time. QKD keys provide ITS. However, because QKD is relatively new, it has not yet been standardized. Therefore, despite its high level of security, a non-quantum key exchange policy is often required to certify the security system. Combining keys using a function such as XOR allows the combined key to comply with the agreed-upon policy, provided that one of the component keys in the combination complies with the policy.

[0010] In one embodiment, the quantum key distribution unit is configured to generate and add multiple keys to a key store of multiple keys shared with the second node via the quantum key distribution unit. Thus, the QKD key store is continuously replenished. However, the authentication unit determines whether the replenishment rate meets the usage rate, and can therefore reduce the usage of QKD keys to avoid depleting the QKD key store. Some QKD keys are used for authentication, while other QKD keys are used to encrypt messages (other than authentication messages) sent to other nodes.

[0011] In one embodiment, the authentication unit uses an asymmetric key exchange algorithm (using a conventional classical algorithm or PQC) to create authentication cryptographic keys for authenticating new users on the network where no pre-shared key or QKD keying material is available. In a further embodiment, the classical key exchange algorithm may be run continuously to populate a key pool of classical keys, which can be used by the authentication engine when needed (reducing latency compared to key exchange on demand). In other embodiments, classical key exchange is performed on demand.

[0012] In one embodiment, a conventional key exchange algorithm is pipelined using a pseudorandom function before being XORed with a pre-shared key and / or QKD keying material to form a final key. An input such as a counter or a cryptographic nonce may seed the pipelined processing. In one embodiment, the authentication unit is configured to combine two of a plurality of keys of a plurality of different types by using one key to seed a pseudorandom function used to increase the length of another key.

[0013] The node can be used in a quantum communication system employing the authentication unit for classical communications involving quantum post-processing, with the resulting quantum key having associated metadata indicating the authentication characteristics of the link when performing post-processing.

[0014] The node may be used in a quantum communication network employing the authentication unit for classical communication between all nodes, where a different key combination scheme is (optionally) selected for adding a new node to the network compared to communication between previously authenticated nodes.

[0015] In a further embodiment, a quantum communication network is provided in which a database of private / public key pairs is initially generated, where each node has a single private key and all public keys installed, allowing new nodes to join by simply installing one of the pre-generated private keys. This allows for key exchange using asymmetric cryptography, where the key is then used for message authentication codes. This avoids the need to communicate public keys over the network. In this embodiment, each node uses a lookup table to find the public key for a remote node in the database when initiating a new connection. The public key can be for an asymmetric conventional key encapsulation mechanism or a PQC key encapsulation mechanism.

[0016] In a further embodiment, a quantum communications network is provided in which a PQC PKI is established, including a certificate authority (CA) that issues digital certificates containing public keys for each node in the network. The certificates are signed using a PQC signature algorithm (e.g., CRYSTALS Dilthium). Each node can use the certificate to validate another node's public key, which can then be used to perform key encapsulation, where the resulting key is then used for QKD authentication.

[0017] In a further embodiment, a quantum random number generator (QRNG) is used for public / private key generation and whenever randomness is needed for the execution of classical cryptographic algorithms. Alternatively, a QKD key may be obtained from a key management system and used as the random number.

[0018] In a further embodiment, there is provided a quantum communication system, the quantum communication system comprising: a first node, said node; and a second node, also as described above, having an authentication unit configured to compare a signature generated by the authentication unit from the message with a signature received with the message, the authentication unit configured to determine that the message is authenticated if the signatures match.

[0019] In the quantum communication system, each node comprises a classical key store comprising a plurality of public keys in a look-up table, and the authentication unit is configured to receive an index from the look-up table indicating the public key to be used.

[0020] In a further embodiment, there is provided a method of creating a signed message for authentication in a quantum communications network, the method comprising: receiving a message sent over an authenticated channel; generating an authentication key; generating a signature from the message using an authentication key; Creating the authentication key comprises receiving information regarding operation of the quantum communication network and selecting at least one key type from a plurality of different key types based on the received information, the plurality of key types being selected from a plurality of pre-shared keys, a plurality of keys obtained by sharing keys via a quantum key distribution unit, and a plurality of keys shared via a classical communication channel.

[0021] Creating an authentication key may comprise combining two or more keys of multiple key types.

[0022] A carrier medium may be provided with code adapted to cause a computer executing the code to perform the methods of the above embodiments.

[0023] The above embodiments can be implemented in software or with hardware acceleration (e.g., ASIC / FPGA / GPU, etc.). They can also be applied to free-space QKD, fiber-based QKD, or a mixture thereof. The QKD network used above can be selected from, for example, point-to-point QKD, CV QKD, DV QKD (including BB84 QKD and derivatives, MDI QKD, and TF QKD).

[0024] Figure 1A is a schematic diagram illustrating quantum key distribution. In the example described with reference to Figure 1A, a sender, Alice 1, prepares quantum states in step S5 and sends them to a receiver, called Bob 3. Bob receives the quantum states and decrypts them in step S7. This is an example of a point-to-point QKD system, where Alice 1 can be thought of as the sender and Bob 3 as the receiver.

[0025] One example of a possible transmitter is shown in FIG. 1B as 1101. The transmitter can be any type of quantum transmitter capable of emitting coded photons. In this example, polarization coding is described, but any type of coding, such as phase, energy / time, etc., can be used. In this example, transmitter 1101 includes four lasers 1105, 1107, 1109, and 1111, each emitting horizontally polarized light. The output from laser 1105 is fed to polarization combining optics 1139. The output from laser 1107 is fed to polarization combining optics 1139 via a half-wave plate configured to convert horizontally polarized light to diagonally polarized light. The output from laser 1109 is fed to polarization combining optics 1139 via a half-wave plate configured to convert horizontally polarized light to vertically polarized light. The output from laser 1111 is fed to polarization combining optics 1139 via a half-wave plate configured to convert horizontally polarized light to diagonally polarized light.

[0026] The polarization combining optics allows different polarizations to be randomly combined into a stream of pulses with different polarizations. This can be achieved in many different ways. For example, the lasers may be pulsed lasers, and a controller (not shown) may be provided to randomly select a laser from lasers 1105, 1107, 1109, and 1111 to randomly output pulses, such that one pulse at a time reaches the polarization combining optics. In other embodiments, the polarization combining optics or additional components may be configured to randomly select the output from one laser or randomly selectively block the output from three lasers to provide a pulsed output stream. The pulses may be generated by a pulsed laser, or a cw laser may be used with additional components to chop the output into pulses.

[0027] An attenuator (not shown) is then used to attenuate the power of the pulses so that they contain less than one photon on average. Alternatively, single-photon emitters can be used in place of lasers 1105, 1107, 1109, and 1111.

[0028] A simplified form of the receiver is shown in FIG. 1C. The receiver includes a 50:50 beam splitter 1205 that directs incoming pulses along either a first measurement channel 1207 or a second measurement channel 1209. Because the pulses contain less than one photon on average, the 50:50 beam splitter 1205 randomly directs the pulses along either the first or second measurement channel. This results in a measurement basis selection: the X(D / A) basis or the Z(H / V) basis. The non-polarizing beam splitter 1205 functions to enable random selection of one of the two bases.

[0029] The first measurement channel is for the X basis, which corresponds to the D / A basis. Here, a half-wave plate 1211 is provided to rotate the polarization by 45 degrees between the two detection branches, giving two measurement bases, X and Z. The output of half-wave plate 1211 is then directed towards polarizing beam splitter 1213, which directs pulses with opposite polarities towards opposite-angle detector 1215 and pulses with diagonal polarities towards diagonal detector 1217. Detectors 1215 and 1217 are single-photon detectors, such as avalanche photodiodes.

[0030] Pulses directed along the second measurement channel are measured in the Z-base to determine whether they are horizontal or vertical. Here, pulses directed into the second measurement channel are directed towards polarizing beam splitter 1219, which directs vertically polarized pulses towards detector 1221 and horizontally polarized pulses towards detector 1223. Again, detectors 1221 and 1223 are single-photon detectors.

[0031] If a photon polarized in the D / A basis is received and randomly routed to be measured in the Z basis along the second measurement channel 1209, it is likely that one of the detectors 1221, 1223 will register a count. However, this result can contribute to an increased quantum bit error rate, as there is a 50:50 chance that a photon received at the polarizing beam splitter 1219 will be directed towards either the vertical or horizontal detector.

[0032] To establish the key, Alice 1 and Bob 3 go through a culling process in step S9 where each party reveals to the other which measurement basis they used after communicating. The other party then checks which results need to be discarded because they were not measured with the correct basis. This is the culling process in step S9.

[0033] Next, in step S11, both parties perform error correction to correct any bit errors and calculate the number of errors. Privacy amplification is then performed in step S13 to take the measured error rate into account to produce the final key, which is then stored in the key management system in step S15.

[0034] The above system is a point-to-point QKD system, but any type of system can be used, such as, for example, CV QKD, DV QKD (including BB84 QKD and derivatives, MDI QKD and TF QKD).

[0035] QKD, as described above, is a cryptographic primitive for generating a random digital key shared between remote users (conventionally called Alice and Bob), where the security of the key exchange process can be quantified using only theoretical principles (specifically, information theory and quantum theory). This means that QKD is secure against attacks in which an eavesdropper (conventionally called Eve) possesses maximum computational power (e.g., a large-scale fault-tolerant quantum computer). This is known as "information-theoretic security" (ITS), and security is quantified as a security parameter, ε, which describes the probability that the scheme will fail. With proper system design, ε can be made negligibly small, thus providing unprecedented security.

[0036] This feature of QKD stands in stark contrast to traditional public key cryptography methods of key exchange (e.g., RSA, elliptic curve cryptography, etc.), which all rely on computational assumptions, i.e., the recognition that certain tasks are intractable for computers. These assumptions are broken in the era of quantum computing, making it even possible for an attacker to harvest current data transmissions sent using classical encryption and then decrypt them in the future using a more powerful computer (a "harvest-now-decrypt-later attack").

[0037] In summary, QKD generally operates by transmitting (from Alice), measuring (at Bob), and then post-processing the measurements to output a secure key, as illustrated in Figure 1A. Due to the laws of quantum mechanics, any attempt by Eve to eavesdrop on the quantum state will inevitably alter the state, which can therefore be detected based on post-processing (comprising various stages including screening, error correction, and privacy amplification) performed using measurements at Bob and communication over an authenticated classical channel between Alice and Bob.

[0038] The requirement for authentication over classical communication channels is in fact a non-trivial issue, especially when considering how QKD scales to build larger networks. In fact, it is also a crucial issue to consider, since the security of the overall QKD system depends on the security of its authentication scheme (e.g., when analyzing the overall system within the widely used generalized composability framework).

[0039] One technique for message authentication is the asymmetric digital signature scheme, in which Alice uses her private key to apply a mathematical algorithm to her message, resulting in a unique digital signature. This digital signature is sent along with the message to Bob. Upon receipt, Bob applies a verification algorithm to the message and signature, which also uses Alice's public key as input. The verification algorithm returns true if no tampering has occurred, thus ensuring the authenticity and integrity of the message.

[0040] But how does Bob get a copy of Alice's public key to use for verification? It is a simple matter for a man-in-the-middle (Eve) to defeat the security of the scheme if he can trick Alice into believing that Eve's public key actually comes from Bob. This problem is traditionally solved using certificates.

[0041] A certificate is a digital file that binds a public key to a particular entity. It is issued by a Certification Authority (CA), a third-party organization that is considered trustworthy by Alice and Bob (such as a root CA company or an equipment vendor's CA). A CA acts as a trusted authority that validates an entity's identity and verifies ownership of its public key. The management of CAs and the handling of certificates is often described in terms of a Public Key Infrastructure (PKI).

[0042] Returning to the original message authentication problem, Alice can then first share her CA-signed certificate with Bob. Assuming Bob trusts the CA, he can extract Alice's public key from this, thus enabling a fully descriptive message authentication scheme.

[0043] In QKD, Alice and Bob communicate a post-processing message for each QKD session. Each message can be authenticated by iterating the digital signature scheme described above. However, this approach is not ideal for QKD because the security of asymmetric signature and verification algorithms relies on the assumption of computational intractability. Classically, digital signature schemes have been built on the assumption of intractability of the discrete logarithm problem (e.g., DSA, ECDSA, EdDSA) and the integer factorization problem (e.g., RSA).

[0044] FIG. 2 is a schematic diagram of a node 101 of a QKD system according to one embodiment. A single QKD node is shown, which may be connected to any number of other QKD nodes to form a quantum communications network. Node 101 includes a quantum optical device subsystem 103. Quantum optical device subsystem 103 is a receiver, transmitter, or combination of receiver and transmitter capable of encoding and / or decoding information onto an optical signal, each quantum of which has an average number of photons less than one. The generation and measurement of QKD-encoded signals is handled by quantum optical device subsystem 103, which includes random pattern generation, encoded single-photon generation, and / or single-photon detection (depending on whether the node is a transmitter (Alice) node or a receiver (Bob) node, but could also be both, i.e., a transceiver). Possible configurations of quantum optical device subsystem 103 are described above with reference to FIGS. 1B and 1C.

[0045] The quantum optical device subsystem 103 is connected to a quantum channel, which may be a free-space channel, a fiber-based channel, or a mixture of both. A quantum channel is a channel capable of carrying an optical signal from the quantum optical device subsystem, where the signal is encoded onto quanta of the optical signal.

[0046] Quantum measurements (e.g., photon production / detection signals) are passed to a post-processing module 109, which applies filtering, error correction, and privacy amplification algorithms to process the raw measurements into secure keys. A key management subsystem 111 handles key storage and delivery to user applications (e.g., hosting a server capable of responding to key requests via an internationally standardized key delivery API).

[0047] A classical communication stack 105 is provided connected to the classical channel. In Figure 2, the classical channel is shown physically separate from the quantum channel. However, the quantum and classical channels may both be in a single fiber. The classical communication stack 105 is used to communicate with a second node to perform sorting and other operations described above.

[0048] For the reasons stated above, the second node needs to be authenticated to determine whether the signal being received from the second node can be trusted, which it does by using an authentication engine 107.

[0049] Post-processing information communicated between different QKD systems passes through an authentication engine 107 before being handled by a classical communications stack 105 (which handles standard communications tasks such as classical error correction and interfacing with physical network adapters such as pluggable SFPs). The authentication engine accepts input from the post-processing stage, including information about the QKD system performance and the link (e.g., quantum bit error rate, secure bit rate, link distance / loss, whether any other “bright” data channels share the link, etc.). The authentication engine also accepts input from a key management subsystem 111, which allows the user to set security policies and their organizational priorities. This information is translated into policy rules / configurations for the authentication engine (described below). In other embodiments, policies / configurations for authentication may be communicated from the user to the system by other means, for example, using a software-defined networking controller or direct local access to the QKD system's command line interface. Finally, the authentication engine may also accept keys as input from the key management subsystem, where these QKD-generated keys will be used as part of the authentication process. The authentication engine 107 may record authentication-related information as key metadata, which may be passed directly to either a post-processing module or to the key management subsystem, where the metadata is stored along with the key itself (ready to be retrieved by the user at any time).

[0050] FIG. 3 is a diagram generally illustrating a possible authentication process according to one embodiment, which is based on a symmetrically keyed message authentication code (MAC).

[0051] Message authentication codes (MACs) using pre-shared symmetric keys, for example according to the Wegman-Carter formula, are well suited to the task of authenticating QKD post-processing communications. Furthermore, Wegman-Carter MACs enable information-theoretically secure (ITS) authentication; in other words, they provide "perfect security" (not based on computational assumptions) with a quantifiable probability of failure.

[0052] The operation of the Wegman-Carter MAC in authentication will now be described with reference to FIGS. 1. For each message communicated from a first node (call it Alice) to a second node (call it Bob), Alice computes a "tag" (also known as a "code") in S201 using digital key material pre-shared with Bob. As shown in Figure 4, the tag is formed by applying a keyed hash function to the message in S203, and then applying a one-time pad to encrypt the hash in step S205 (other algorithms may be used). 2. The tag is sent along with the message to Bob. 3. Bob recalculates the tag based on the received message in step S207 (this requires that Bob have a copy of the same pre-shared key that Alice used) and compares it to the received tag in step S209. If they match, Bob can be sure of the authenticity and integrity of the message, since only someone who knows the secret pre-shared key can generate the correct tag.

[0053] In the ITS Wegman-Carter scheme, authentication keys can only be used once: they cannot be reused or extended, for example, using a pseudorandom function (PRF).

[0054] Thus, given the finite initial amount of keys pre-shared between Alice and Bob, authentication cannot occur indefinitely. Figure 5 is a schematic diagram of the key management subsystem 111. The key management subsystem 111 has multiple key modules, each of which can provide a key to the authentication engine to form an authentication key. The authentication engine then determines which keys to select and combines the selected keys.

[0055] The PSK key store 113 is used to store pre-shared keys that were provided within the node when the node was manufactured or that were otherwise securely provided to the node; for example, keys may be installed in the node during servicing or by a trusted person physically installing a new key in the node.

[0056] It is also possible for ITS-grade keys to be generated by the QKD protocol. During QKD, as described with reference to FIG. 1A, a key is shared between two nodes. This key is intended to encrypt messages sent between the two nodes. However, some of this key material is also used for authentication and may be provided to the QKD store 115 for this use. This ability to distribute keys with provable security is unique to quantum communications. To provide an authentication system for QKD, initial authentication (e.g., connecting new remote nodes together without a prior pre-shared key) is challenging, but the generated QKD material can then be used for subsequent authentication sessions. While this is a robust method, it has the downside of using up the generated QKD keys rather than making them available to users.

[0057] In addition to the PSK key store 113 and the QKD key store 115, stores for keys that can be shared over classical channels are provided. Specifically, the key management subsystem 111 may implement a computationally secure classical key exchange algorithm, such as Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH). Such algorithms are already part of international cybersecurity standards (e.g., FIPS standards), which motivates their use as part of a combined key for QKD session authentication. Furthermore, the key management subsystem 111 may also implement PQC classical information-key encapsulation, which uses an algorithm that is computationally secure but whose underlying problem is considered difficult even for quantum computers.

[0058] Next, we will explain classical key exchange (non-PQC) using the Diffie-Hellman technique, as shown in Figure 6. First, in step S251, both parties agree a priori or publicly on certain parameters: a large prime number (p) and a primitive root (g) modulo p. Then, in step S253, both parties generate a private key (random number), which they use to calculate a public key in step S255 by raising the agreed-upon primitive root g to the power of their private key, modulo prime p. Public keys A and B are shared between the two parties. Alice then uses the public key received from Bob to raise the public key to the power of her private key, modulo prime p. Bob uses the public key received from Alice to raise the public key to the power of his private key, modulo prime p. Both parties obtain an independently calculated shared secret key as the output of this calculation in step S257.

[0059] The security of the Diffie-Hellman key exchange relies on the computational intractability of solving the discrete logarithm problem. Given values of p, g, and either A or B, it is computationally infeasible to determine the private key (a or b) used to calculate the shared secret key without significant computational resources. The resulting shared secret key may be stored in classical key agreement module 117. The classical key agreement module may store pre-shared keys using the method described with reference to FIG. 6 so that such keys are ready for use, or classical key agreement module 117 may be configured to initiate the process of FIG. 6 to obtain such keys when the authentication engine indicates a need for them.

[0060] The key management subsystem 111 also includes a post-quantum key sharing module 119 that supplies shared keys using PQC, including post-quantum classical information key encapsulation using algorithms that are computationally secure but whose underlying problems are believed to be difficult even for quantum computers. This includes classes of mathematical problems such as error-correcting codes (code-based cryptography), lattice-theoretic problems (lattice-based cryptography), hash functions (hash-based cryptography), and multivariate equation systems (multivariate cryptography). Such algorithms are currently being standardized (e.g., by NIST). Note that both the PQC Digital Signature Scheme (DSS) and the PQC Key Encapsulation Mechanism (KEM) are being standardized.

[0061] Figure 7 shows the general process of the KEM algorithm. It begins in step S271 with one of the users (here, Alice) creating a public / private key pair and sharing the public key with the other (see below for an explanation of public key sharing). Bob then generates a random secret key to be shared in step S273 and "encapsulates" it in a ciphertext using Alice's public key. The ciphertext is sent publicly to Alice, but is computationally difficult for an attacker to reverse if it is intercepted, thus protecting the private key. Once Alice receives the ciphertext, she "decapsulates" the private key from it in step S275 using her private key. Alice and Bob have now shared a private key in step S277, which is stored in the post-quantum key sharing module 119. The post-quantum key sharing module 119 may store pre-shared keys using the method described with reference to FIG. 7 so that such keys are ready to be used, or the post-quantum key sharing module 119 may be configured to initiate the process of FIG. 7 to obtain such keys once the authentication engine indicates a need for them.

[0062] In one embodiment, the post-quantum key sharing module 119 implements CRYSTALS-Kyber as a PQC KEM. Kyber's security is based on the difficulty of solving the learning-with-errors (LWE) problem over a modular lattice. To briefly (and simplisticly) explain how it works (note that all calculations are implicitly performed using modulo arithmetic with some pre-agreed (non-secret) modulus), the generation stage of a public / private key pair first involves Alice calculating a private key that includes random values representing the coefficients of multiple polynomials. The public key is formed by generating a matrix of random polynomials. Some additional random error vector (of the polynomial coefficients) is added, and a vector is calculated as the product of this matrix and the private key. The public key comprises both the matrix of polynomials and the derived vector. Re-deriving the private key from the public key requires an attacker to solve the module-learning-with-errors (MLWE) problem, which is believed to be difficult even for a quantum computer.

[0063] To encapsulate a random binary string (to be used as a shared key) for Bob to send to Alice, the string is encoded as a polynomial, and Bob also calculates several random-value polynomials to use in the calculation. Ciphertext is formed by multiplying Alice's public key by these polynomials and adding the shared key. The ciphertext is then sent to Alice.

[0064] Alice decapsulates the ciphertext by multiplying one part of it by her private key, which she took from another part of the ciphertext. The output is a noisy version of the shared secret key (because Bob intentionally added an error), but the error is so small that Alice can perfectly filter out the noise by rounding to obtain the shared key. As a result, Alice and Bob are left with a shared secret key that can be used by post-quantum key sharing module 119. Post-quantum key sharing module 119 can store pre-shared keys using the methods described above so that such keys are ready to be used, or post-quantum key sharing module 119 can be configured to initiate the process described above to obtain such keys when the authentication engine indicates a need for them.

[0065] The authentication engine can then seek keys from the PSK key store 113, the QKD key store 115, the classical key agreement module 117, and the post-quantum key agreement module 119 to generate the authentication key. When generating the authentication key, the authentication engine: (i) selecting a key type from the key management subsystem 111; (ii) combining the selected keys; This involves two steps:

[0066] (i) The selection of the key type from the key management subsystem is performed by the key combiner decision logic 131 shown in FIG.

[0067] The key management subsystem may store or have access to the different types of keys mentioned above. Depending on the network requirements, the key combiner decision logic may or may not want to select a particular type of key.

[0068] The key combiner decision logic can receive many different inputs, for example: (i) The size of the key pool (both PSK and QKD) If the PSK or QKD keystore is running low, the use of these keys can be deprioritized to avoid complete exhaustion of the keystore. (ii) Link metric (e.g., distance / loss) If a QKD system measures the link prior to running QKD, it will know that high loss / long distance will result in a low QKD key rate, so it can use this information to estimate how many QKD keys will be available and possibly deprioritize their use when it expects the rate to be low. (iii) QKD metrics (e.g., QBER, count rate, SBR) QKD metrics are used in the same way as link metrics. However, because they are QKD measurements, they are more accurate than link metrics. QKD metrics can be estimated from link metrics, which can be faster / simpler than relying on real-time measurements. (iv) QKD session information (e.g., index / timing) When performing QKD, the concept of a session refers to a single window in which QKD is performed. For each session (depending on the security policy), an authentication key may be used. Therefore, if the session is very short, the system may realize that a lot of key material may be needed to use for authentication, and therefore may support using PQC to avoid QKD key exhaustion. (v) User security policies (e.g., weightings) The embodiments described herein allow users to define the exact combination scheme based on their needs. Some organizations may require the use of a PQC key combined with all other keys. Other organizations may always require the use of a QKD key to secure the ITS. Other organizations with some flexibility may define more complex rules (e.g., attempt to use QKD for authentication unless there is an insufficient key pool for the application). Thus, weighting, i.e., giving priority to certain key inputs over others, may be applied. (vi) Network policies (e.g., from an SDN controller) This is similar to the considerations above for user policy settings: user policy will be set by the local user, while network policy is set by the network. In some cases, users may be allowed to override network policy.

[0069] The PSK key store 113 contains keys that were pre-stored in the key management subsystem during device manufacturing or servicing by a "trusted vendor." They have not been communicated over a communication system (either quantum or classical) and are therefore ITS-grade keys.

[0070] However, the number of PSK keys is finite. To ensure ITS-grade keys, they cannot be reused. They also cannot be expanded, for example, using a pseudorandom function (PRF). Therefore, given the finite initial amount of keys pre-shared between Alice and Bob, authentication cannot be performed indefinitely.

[0071] As part of the selection process, the key combiner decision logic 131 may consider one or more of the following parameters to determine whether to select a PSK: (a) The number of PSKs available from the store. If the number is below a threshold, you cannot select a PSK. (b) A requirement that ITS keys below the threshold must be used in combination with multiple QKD keys.

[0072] As part of the selection process, the key combiner decision logic 131 may consider one or more of the following parameters to determine whether to select a QKD key: (a) The number of QKD keys available from the store. If the number is below a threshold, no QKD keys can be selected. (b) A requirement that ITS keys below a threshold must be used in combination with multiple PSKs. (c) QKD metric or link metric. For example, if the QBER is above a threshold, generating more QKD keys will slow down, which suggests that the QKD keys should not be used. (d) The length of the QKD session, which suggests that the QKD keys are consumed quickly during authentication.

[0073] As part of the selection process, the key combiner decision logic 131 may consider one or more of the following parameters to determine whether to include keys obtained from the classical key agreement module 117: For brevity, this is referred to as a "classical key," which is taken to mean a key that has been shared over a classical channel using non-post-quantum cryptography techniques. (a) The network is operating under at least one security policy (either user-level or network-level) that requires the use of classical keys of the type obtained by classical key agreement module 117.

[0074] As part of the selection process, the key combiner decision logic 131 may consider one or more of the following parameters to determine whether to include the key obtained from the post-quantum key sharing module 119: For brevity, this is referred to as a "PQC key", which is taken to mean a key shared over a classical channel using post-quantum cryptography techniques: (a) The network is operating under at least one security policy (either user-level or network-level) that requires the use of a PQC key of the type obtained by the post-quantum key sharing module 119.

[0075] As can be seen from the above, the key combiner decision logic 131 also accepts input from the key management subsystem, which, for example, allows the user to set security policies and priorities for the organization. This information is translated into policy rules / configuration for the authentication engine (described below). In other embodiments, the policy / configuration for authentication may be communicated from the user to the system by other means, for example, using direct local access to the software-defined networking controller or the command line interface of the QKD system.

[0076] (ii) The authentication engine then combines the keys using a key combiner of the type described with reference to Figure 8. Key combiner decision logic 131 is described above and selects keys for combination from PSK key store 113, QKD key store 115, classical key agreement module 117, and post-quantum key agreement module 119. In Figure 8, the selection is indicated by include modules 143, 145, 147, and 149 provided at the outputs of PSK key store 113, QKD key store 115, classical key agreement module 117, and post-quantum key agreement module 119, respectively. Key combiner decision logic 131 provides a control output to each include module 143, 145, 147, and 149 to indicate whether a key from PSK key store 113, QKD key store 115, classical key agreement module 117, or post-quantum key agreement module 119 should be included in the output key.

[0077] An example of a possible rule for selecting a key is given above.

[0078] The key combiner can selectively use any of the above inputs to form the final key to be used for the MAC calculation. The key combiner should preserve the security of each input primitive, such that the overall security of the system is preserved as long as at least one of the input primitives remains secure.

[0079] The key combiner takes as input many possible factors into a decision logic module, including measured link parameters (e.g., distance / loss), QKD performance metrics, post-processing session information and key pool state (i.e., availability of QKD keys and PSKs), and user-defined / network-defined security policies, the output(s) from which control the key derivation function that produces the final key for authentication.

[0080] At the most basic level, the combiner can selectively enable / disable each of the four possible components. For example, if the input key pool information suggests that there is insufficient PSK or QKD keying material, the PSK and QKD keys can be excluded from use in the combined key.

[0081] The combiner can also adjust the parameters of all algorithms involved. For example, the combiner can select different classical or PQC key exchange algorithms. In one possible embodiment, the combiner may run multiple different classical and PQC algorithms. Even for the chosen algorithm, the combiner can vary the algorithm's parameters, such as key size. One could imagine a network administrator defining a list of organizationally approved algorithms that would be input as a security policy into the combiner, so it knows it is only using approved ones.

[0082] For computationally secure key exchange schemes, i.e., classical and PQC key exchanges, it may be desirable to increase the key length by using a pseudorandom function (PRF) 151 for the PQC key and a PRF 153 for the classical key. This may impact the security level, but it can increase the amount of available keys. Asymmetric cryptography is inherently computationally intensive, and classical / PQC key exchanges often run much slower than QKD key generation speeds. Therefore, using a PRF can ensure that the generated keys from each component being combined are equal in size. The key combiner decision logic 131 can adjust parameters and declare whether a PRF is used.

[0083] The combiner decision logic can also include more complex algorithms to optimize QKD system performance. For example, if the link metrics and QKD metrics suggest that only a low QKD key generation rate is possible (e.g., high loss, high QBER, low count rate, etc.), the combiner may preferentially select classical / PQC keys for use as component keys. This avoids running out of QKD keys for authentication when they can instead be given to users for their applications.

[0084] Similarly, the decision logic can take into account QKD session information, including timing, to define the combination technique and how long a single authentication session is (i.e., how long to use a single authentication key). When initially connecting to a new QKD system, neither PSK nor QKD keying material may be available, so the key combiner will select either the classical or PQC technique to initialize the authenticated classical channel.

[0085] The selected keys are combined by a combiner 155, in this case using an XOR function to combine the keys to produce an output key k out 157 is produced.

[0086] XOR is a bitwise operation on k out = k1 + k2 + k3 + k4. In practice, this is implemented by summing each bit modulo 2. This can be applied to any number of inputs in any order (XOR is both commutative and associative). For example: K1=0000 K2=0010 K3=1111 K4=0111 K out =1010

[0087] The key combiner can also dynamically adjust the key combining function itself: for example, if the QBER improves, the combiner may initiate QKD key selection.

[0088] While Figure 8 shows an XOR-based combining function, other approaches are possible. Figure 9 shows a further variation of the key combiner of Figure 8. To avoid unnecessary repetition, like reference numbers are used to indicate like features. Figure 9 is based on a pipelined process in which the classical and PQC stages are performed sequentially, and also includes optional input state such as a session counter or cryptographic nonce. In Figure 9, the classical key is used as a seed for the PRF 151, which is used to extend the PQC key.

[0089] However, in Figure 9, QKD and PSK are still combined with the outputs from the PQC and classical stages using XOR to preserve their properties (as QKD and PSK can be information-theoretically secure).

[0090] Key combinations offer two practical advantages (even when the QKD keys are available): 1) Compliance Regulated industries (e.g., finance) set current regulatory requirements (e.g., NIST FIPS). It is understood that RSA / ECC will not work in the future, but current standards for cybersecurity require their use. PQC will also be standardized before QKD. The combiner approach makes the system robust and allows it to adapt to new encryption techniques as they become standardized. 2) As a fail-safe QKD vendors do their best to ensure their hardware functions correctly, but customers want peace of mind about new technology. With an XOR combiner, the final key is only as secure as one of the other parts of the combined key is secure. Thus, if the QKD system fails in a hypothetical insecure way, the output key is still secure to the level of the next best key. This has the advantage over not having a combiner and generating a completely insecure key if the QKD system fails silently in some way.

[0091] In one embodiment, the key combiner may record the technique used for each authentication session and relay this information to the post-processing / key management subsystem, which may store this information as metadata along with the QKD keys generated during each authenticated post-processing session and make it available to the user when they request the keys.

[0092] It was noted above with reference to Figure 4 that keys are used to calculate the hash in S203 and then encrypt in S205. Different keys are used in both of these steps. One or both of the keys may be provided from the key combiner of Figure 8 or Figure 9. In one embodiment, the keys required for at least the encryption stage S205 are provided from the key combiner of Figure 8 or Figure 9. The above embodiment allows the keys for S203 and S205 to be adapted independently to the respective policy requirements of the keys for S203 and S205.

[0093] Figure 10 is a schematic diagram used to summarise the above process: In step S151, a message m to be authenticated is received. In step S151, a MAC tag t is calculated from the message m.

[0094] The key for computing the tag t is obtained from a tunable key combiner 153, which is a key combiner of the type described with reference to Figures 8 and 9. The tunable key combiner 153 can take input from a variety of sources, as described above. This may include a pre-shared symmetric key (PSK) installed in Alice and Bob by the vendor during device manufacture (or manually installed by the user). A generated QKD key may also be used by the key combiner when retrieved, for example, from the system's key management system. The authentication engine also includes functionality to exchange a symmetric private key using asymmetric classical cryptography in S161 to feed into the key combiner stage. Such a classical key exchange involves sharing classical (non-quantum) information between Alice and Bob to compute a symmetric private key that is identical for both. The key may also be shared over a classical channel using post-quantum cryptography in S159.

[0095] The message m and tag t are sent to Bob over communication channel 157. At Bob's receiver, in step S163, the same key obtained from Bob's key combiner 165 is used to combine Bob's MAC tag t from the received message m. b In step S167, Bob's calculated tag t b is compared with the received tag t. If the tags match, the message is authenticated in S169. If the tags do not match, the message is not authenticated in S171. If the message is not authenticated, an alarm may be raised as this indicates that the system has been compromised.

[0096] Above we used a MAC as a method for authenticating a message using a combined key. However, combined keys can be used with any type of signature, even asymmetric signatures, in some cases.

[0097] Figure 11 is a schematic diagram of a quantum communication network. The network comprises a first system 501, a second system 503, and a third system 505. The first, second, and third systems are connected via a switch 507 that allows selective communication between the systems. A network manager / vendor 509 manages the systems.

[0098] The key exchange techniques described above, which take place over classical channels (conventional and PQC), require that the public key for a user (e.g., Alice) be available for use by another user (e.g., Bob). Care must be taken when obtaining the public key, since an attacker can act as a man-in-the-middle if they are capable of "tricking" a user into using an incorrect public key. Thus, keys exchanged classically during this time are likely insecure and should not be used for input to the key combiner. (It is acknowledged that an advantage of the key combiner stage is that a single bad key input cannot break the overall QKD authentication, but it is still important to minimize the risk of this happening through careful public key management.)

[0099] In the case of a QKD network with multiple systems 501, 503, and 505, with a central switch 507 to reconfigure which units are connected for example, the QKD nodes need to talk to the other systems, each with its own public key, which cannot simply be sent over the public internet as it could be intercepted / manipulated.

[0100] The system of Figure 11 uses pre-shared public keys. For example, when Alice and Bob communicate in person, Alice's public key can be pre-installed on Bob, and vice versa. Pre-installation of public keys corresponding to different users is separate from the concept of pre-installed pre-shared symmetric keying material (for direct use to key MACs) discussed above. However, this does not scale beyond networks of a few users.

[0101] One approach to scaling to medium-sized networks is shown in FIG. 11, where a large number of indexed private / public key pairs are pre-generated by either the network operator or the network vendor 509. All of these key pairs are securely stored in a central database (shown at vendor 509). As each new system is manufactured or provisioned, it can be assigned an ID and associated with a public / private key pair from the database. The private key is extracted from a secure key table at the network manager / vendor and installed in the new system. All indexed public keys are also installed in the new QKD systems 501, 503, 505. Thus, whenever a node wants to do QKD with a new system, it can simply query it for its private / public key index and look up the public key in its own database without having to send a key. If an attacker were to trick the system into entering using a different key, for example by changing the ID, they would not be able to pose as a man-in-the-middle because they would still not be able to authenticate with the system because they would not have the private keys for any of the pre-generated secure keys.

[0102] In a further embodiment, many private keys are pre-allocated to each system, allowing them to rotate the keys after a given time frame. For large networks, public keys can also be obtained from certificates in a public key infrastructure setting. Such a PKI is well established for classical key exchange. Although a PQC PKI is not yet available, it is expected that the concepts of CAs and certificates can also all be used with the PQC algorithm.

[0103] The authentication engine can be implemented in software and can, for example, leverage the classical communications stack of the QKD system to perform the classical and PQC key exchange stages. The classical and PQC key exchanges can be performed on demand, i.e., the authentication engine obtains the keys to input into the combiner just in time. Alternatively, the classical key exchange stages may be run as a daemon to continuously populate a key pool of classical and PQC keys. Keys can be obtained from the pool when the key combiner is ready to be input. The advantage of this is zero delay in obtaining classical keys, but this is generally considered best practice to minimize key lifetimes, so this can be left as a user policy item to choose whether to obtain classical keys on demand or using a pre-filled pool (where the pool expiration time can also be set).

[0104] Thus, the authentication engine has been described above as using a classical communication link as part of a QKD system to share keys. However, in alternative embodiments, the classical key exchange may occur out-of-band, for example, using a public Internet connection between Alice and Bob.

[0105] The authentication engine may be implemented as software, or alternatively using hardware acceleration. For example, many of the core routines of cryptographic related algorithms are well suited for fast execution on FPGAs or dedicated ASICs / GPUs, allowing for faster classical key changes and reduced power consumption.

[0106] When referring to random numbers within this document, e.g., used for key generation and for key exchange / encapsulation algorithms, the source of randomness may be a pseudorandom number generator (PRNG). In other embodiments, the source of randomness may be a quantum random number generator, such as those built into QKD systems. Alternatively, QKD keys may be used as random numbers, as they are effectively generated from quantum randomness.

[0107] Figure 12 shows a three-node QKD network comprising three QKD systems 601, 603, and 605. Each system is of the type described with reference to Figure 2, and so like reference numerals are used to denote like features to avoid unnecessary repetition. The authentication engine 107 described above is capable of authenticating with all other nodes on the network.

[0108] The quantum and classical channels from each node are multiplexed together onto a single fiber. Systems 601, 603, and 605 are connected via an optical crosspoint switch 607.

[0109] Other implementations are possible. For example, free space or satellite links could be used to connect the nodes. Additionally, QKD protocols and designs such as quantum repeaters, such as Measurement Device Independent (MDI) and Twin-Field (TF) QKD, are also possible, which could use the same authentication techniques to verify the integrity and authenticity of post-processed messages.

[0110] While specific embodiments have been described, these embodiments are presented by way of example only and are not intended to limit the scope of the invention. The novel devices and methods described herein may be embodied in a variety of other forms, and various omissions, substitutions, and changes in the form of the devices, methods, and products described herein may be made without departing from the spirit of the invention. The appended claims and their equivalents are intended to cover any such forms or modifications that come within the scope and spirit of the invention.

Claims

1. 1. A node for a quantum communications network, comprising: an authentication unit and a quantum key distribution unit; the authentication unit is configured to authenticate a channel between the node and a second node in the quantum communications network to form an authenticated channel; the quantum key distribution unit is configured to enable distribution of quantum keys between the node and the second node, the quantum keys being selected and processed using communications over the authenticated channel to establish first quantum keys for the node and the second node; the authentication unit comprises key management logic configured to provide access to a plurality of different key types provided by at least one of a plurality of pre-shared keys, a plurality of keys shared with the second node via the quantum key distribution unit, and a key used in a classical key exchange algorithm shared with the second node via a classical communication channel; The node, wherein the authentication unit is configured to receive information regarding operation of the quantum communications network and select at least one key type from the plurality of key types accessible via the key management logic to create an authentication key, and the authentication unit is configured to authenticate the channel using the authentication key.

2. 2. The node of claim 1, wherein the authentication unit is configured to authenticate the channel by creating a signature for a message to be sent from the node to the second node, the signature being created by hashing and encrypting at least a portion of the message using the authentication key.

3. 2. The node of claim 1, wherein the information regarding operation of the quantum communications network is selected from at least one of a plurality of policies governing the quantum communications network, a plurality of pre-shared keys and a number of keys shared with the second node via the quantum key distribution unit, a plurality of measurements regarding operation of the quantum communications network, and a plurality of parameters of a quantum key distribution session.

4. The node of claim 1 , wherein the authentication unit is configured to increase key length using a pseudo-random function.

5. 5. The node of claim 4, wherein the authentication unit is configured to combine two of a plurality of keys of a plurality of different types by using one key to seed a pseudorandom function used to increase the length of another key.

6. The node of claim 1 , wherein the authentication unit is configured to select a plurality of keys of a plurality of different types and combine the selected plurality of keys to produce an authentication key.

7. The node of claim 6 , wherein the multiple keys are combined using an XOR function.

8. 2. The node of claim 1, wherein the plurality of keys shared with the second node over a classical communication channel are selected from one or more keys shared using a plurality of classical key exchange protocols and a plurality of post-quantum key exchange protocols.

9. The node according to claim 8 , wherein the plurality of post-quantum key exchange protocols are a plurality of protocols that are a plurality of quantum-resistant cryptographic algorithms.

10. 10. The node of claim 9, wherein the plurality of quantum-resistant cryptographic algorithms are selected from code-based cryptography, lattice-based cryptography, hash-based cryptography, multivariate cryptography, and a plurality of key encapsulation mechanisms.

11. 9. The node of claim 8, wherein the plurality of classical key exchange protocols are selected from Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH).

12. 2. The node of claim 1, wherein the authentication unit is configured to authenticate the channel using a Wegman-Carter protocol in which a message is subjected to a keyed hash to produce a tag of known length and then encrypted using the authentication key.

13. 13. The node of claim 12, wherein the authentication unit is configured to select a first key to create the keyed hash, a second key is used for encryption, the first key and the second key are different and both are created using the key management logic, and multiple different combinations of multiple key types are used for the first key and the second key.

14. 2. The node of claim 1, wherein the authentication unit is configured to generate a plurality of keys shared with the second node via the classical communication channel using at least one selected from a plurality of classical key generation algorithms and a plurality of PQC key generation algorithms, and enables the generated plurality of keys to be stored in a state ready for use.

15. 2. The node of claim 1, wherein the quantum key distribution unit is configured to generate and add multiple keys to a key store of multiple keys shared with the second node via the quantum key distribution unit.

16. 3. The node of claim 2, wherein the authentication unit is configured to compare the signature generated by the authentication unit from a second message sent to the node from the second node with a signature received with the second message, and wherein the authentication unit is configured to determine that the second message is authenticated if the signatures match.

17. a first node, which is a node according to claim 2; 2. A second node according to claim 1, wherein a second authentication unit of the second node is configured to compare a signature generated by the second authentication unit from a message sent from the first node to the second node with a signature received with the message, and the second authentication unit is configured to determine that the message is authenticated if the signatures match; A quantum communication system comprising:

18. 18. The quantum communication system of claim 17, wherein each node comprises a classical key store comprising a plurality of public keys in a lookup table, and wherein the authentication unit is configured to receive an index from the lookup table indicating the public key to use.

19. 1. A method performed at a node in a quantum communications network, comprising the steps of: the node is configured to authenticate a channel between the node and a second node in the quantum communications network to form an authenticated channel, the node being configured to enable distribution of a quantum key between the node and the second node; the quantum keys are selected and processed using communications over the authenticated channel to establish a first quantum key for the node and the second node; the node is configured to provide access to a plurality of different key types provided by a plurality of pre-shared keys, a plurality of keys shared with the second node, and / or a key used in a classical key exchange algorithm shared with the second node over a classical communication channel; receiving information relating to the operation of the quantum communications network; selecting at least one key type from a plurality of different key types based on the received information to create an authentication key; and authenticating the channel using the authentication key.

20. 20. The method of claim 19, wherein creating the authentication key comprises combining two or more keys of the plurality of key types.

Images