Node for quantum communication network, quantum communication network, and method for creating signed message

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 DISCLOSURE 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 at two remote nodes a completely random quantum key that can be used for data encryption to ensure secure communication. The basic working 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 description of the drawings]

[0003] [Figure 1A] FIG. 1A is a schematic diagram showing 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. [Diagram 2] FIG. 2 is a schematic diagram of a node of a QKD system according to one embodiment. [Diagram 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. [Diagram 5] FIG. 5 is a schematic diagram showing the key combiner decision logic interacting with the key modules. [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 an 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 PREFERRED EMBODIMENTS

[0004] In a first embodiment, there is provided a node for a quantum communications 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 communication network to form an authenticated channel; The quantum key distribution unit is configured to enable distribution of a quantum key between the node and a second node, the quantum key 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 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 allow authentication to occur using keys generated by an electronic subsystem that can combine various component cryptographic and private keys, including those from a pre-shared key (PSK) store, 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 functions 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 policies, 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 calculated independently by the receiver (which has a similar authentication engine that communicates with the sender to ensure that they process the key in the same way to obtain a symmetric key for use in the message authentication code calculation). The authenticity of the message 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 a Wegman-Carter protocol, where 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 perform the encryption of the hash. The cryptographic keys used for the hash function and the 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 (aka quantum-resistant algorithms), whose security is based on assumptions 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 may be configured to select multiple keys of different types and combine the selected keys to produce an authentication key. This allows the node to adapt to different requirements over time. The QKD key provides the ITS. However, as QKD is relatively new, it has not yet been standardized. Thus, despite its high level of security, a non-quantum key exchange policy is often required to certify a security system. Combining the 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 of the combination complies with the policy.

[0010] In one embodiment, the quantum key distribution unit is configured to generate and add a plurality of keys to a key store of a plurality of keys shared with the second node via the quantum key distribution unit. Thus, the QKD key store is continuously replenished. However, the authentication unit can determine whether the replenishment rate meets the usage rate, and thus reduce the use of the QKD keys to avoid exhausting 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 another node.

[0011] In one embodiment, the authentication unit uses an asymmetric key exchange algorithm (using a conventional classical algorithm or PQC) to create a cryptographic key for authentication to authenticate 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 may be used by the authentication engine when needed (reducing latency compared to performing 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 pipeline process. 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 nodes 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 indicative of 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 (optionally) different key combination scheme is 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 first generated, where each node has a single private key and all public keys installed, allowing new nodes to be added by simply installing one of the pre-generated private keys. This allows key exchange using asymmetric cryptography, where the key is then used for message authentication code. 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 the 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 communication 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 of 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, a quantum communication system is provided, the quantum communication system comprising: a first node, said node being 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 which public key to use.

[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 communications 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 communications 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-described embodiments.

[0023] The above embodiments may be implemented in software or with hardware acceleration (e.g., ASIC / FPGA / GPU, etc.). They may also be applied to free-space QKD, fiber-based QKD, or a mixture thereof. The QKD networks used above may be selected, for example, from 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 showing 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 considered 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 encoded photons. In particular, in this example, polarization encoding is described, but any type of encoding can be used, such as phase, energy / time, etc. In this example, the transmitter 1101 comprises four lasers 1105, 1107, 1109, and 1111, each emitting horizontally polarized light. The output from laser 1105 is fed towards polarization combining optics 1139. The output from laser 1107 is fed towards 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 towards 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 towards polarization combining optics 1139 via a half wave plate configured to convert horizontally polarized light to oppositely 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) is provided to randomly select the 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 further 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 further components to chop the output into pulses.

[0027] And an attenuator (not shown) is 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 comprises a 50:50 beam splitter 1205 that directs the incoming pulse along either the first measurement channel 1207 or the second measurement channel 1209. Since the pulse contains less than one photon on average, the 50:50 beam splitter 1205 randomly directs the pulse along either the first measurement channel or the second measurement channel. This results in a measurement basis selection in the X(D / A) basis or the Z(H / V) basis. The non-polarizing beam splitter 1205 functions to allow a 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 the half-wave plate 1211 is then directed towards a polarizing beam splitter 1213, which directs pulses with opposite polarities towards an opposite-angle detector 1215 and pulses with diagonal polarities towards a diagonal detector 1217. Detectors 1215 and 1217 are single-photon detectors, for example avalanche photodiodes.

[0030] Pulses directed along the second measurement channel are measured in a Z basis to determine whether they are horizontal or vertical. Here, pulses directed into the second measurement channel are directed towards a 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 sent to be measured in the Z basis along the second measurement channel 1209, there is a high probability that one of the detectors 1221, 1223 will register a count. However, this result may 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 selection process in step S9 where each of them reveals to the other which measurement basis they used after communication. The other then checks which results need to be discarded because they were not measured with the correct basis. This is the selection process in step S9.

[0033] Then, 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 into account the measured error rate to produce the final key. This is then stored in the key management system in step S15.

[0034] The above system is a point-to-point QKD system, however any type of system can be used, 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) could possess 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 is 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 knowledge that it is hard for a computer to perform certain tasks. These assumptions have been 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 works 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 change the state. This can therefore be detected based on post-processing (with various stages including sorting, 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 general combinability framework).

[0039] One technique for message authentication is the asymmetric digital signature scheme, in which Alice applies a mathematical algorithm to her message using her private key, 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 the ownership of the public key. The management of CAs and the handling of certificates is often described in terms of Public Key Infrastructure (PKI).

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

[0043] In the case of QKD, Alice and Bob communicate a post-processing message for each QKD session. Each message can be authenticated by an iteration of the digital signature scheme described above. However, this approach is not ideal for QKD, since the security of asymmetric signature and verification algorithms relies on computational hardness assumptions. Classically, digital signature schemes are built on hardness assumptions for 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 communication network. The node 101 comprises a quantum optical device subsystem 103. The quantum optical device subsystem 103 is a receiver, a transmitter, or a combination of a receiver and a transmitter capable of encoding and / or decoding information onto an optical signal, where each quantum of the optical signal has an average number of photons less than one. The generation and measurement of the QKD encoded signal is handled by the 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) or receiver (Bob) node, but could be both, i.e. a transceiver). Possible configurations of the quantum optical device subsystem 103 have been described above with reference to FIG. 1B and FIG. 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] The quantum measurements (e.g., photon generation / 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 FIG. 2, the classical channel is shown physically separate from the quantum channel. However, both the quantum and classical channels may be in a single fiber. The classical communication stack 105 is used to communicate with a second node to perform sorting and other operations as 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. It participates in this by using an authentication engine 107.

[0049] Post-processing information communicated between different QKD systems passes through an authentication engine 107 before handling by a classical communication stack 105 (which handles standard communication 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 are sharing 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, the 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 command line interface of the QKD system. 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 either directly to a post-processing module or to the key management subsystem, where the metadata is stored together with the key itself (ready to be retrieved by the user at any time).

[0050] FIG. 3 is a general illustration of 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 for the task of authenticating QKD post-processing communications. Moreover, Wegman-Carter MACs enable authentication that is information-theoretically secure (ITS), 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" (aka "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 that the authenticity and integrity of the message is good, 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 by using a pseudorandom function (PRF).

[0054] Thus, given the finite initial amount of keys pre-shared between Alice and Bob, authentication cannot be performed 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 individual physically installing a new key into 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, part 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 a challenge, but the generated QKD material can then be used for subsequent authentication sessions. This is a robust method, but 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 execute classical key exchange algorithms that have computational security, 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 algorithms that have computational security but whose underlying problems are considered difficult even for quantum computers.

[0058] Next, a (non-PQC) classical key exchange using the Diffie-Hellman technique is described and illustrated in FIG. 6. First, both parties agree a priori or publicly on certain parameters (a large prime number (p) and a primitive root (g) modulo p) in step S251. Then, both parties generate a private key (random number) in step S253 and use this to calculate a public key by raising the agreed primitive root g to the power of their private key modulo the prime number p in step S255. 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 the prime number p. Bob uses the public key received from Alice to raise the public key to the power of his private key modulo the prime number p. Both parties obtain an independently calculated shared secret key as the output from 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 compute the shared secret key without significant computational resources. The resulting shared secret key may be stored in the classical key agreement module 117. The classical key agreement module may store pre-shared keys using the method described with reference to FIG. 6 such that such keys are ready for use, or the classical key agreement module 117 may be configured to initiate the process of FIG. 6 to obtain such keys once the authentication engine indicates a need for such keys.

[0060] The key management subsystem 111 also comprises a post-quantum key sharing module 119 that supplies shared keys using PQC, which includes post-quantum classical information key encapsulation using algorithms that have computational security but where the 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). It is noted that both the PQC Digital Signature Scheme (DSS) and the PQC Key Encapsulation Mechanism (KEM) are being standardized.

[0061] FIG. 7 shows the general process of the KEM algorithm. It starts with one of the users (here Alice) creating a public / private key pair and sharing the public key with the other in step S271 (see below for an explanation of public key sharing). Bob then generates a random secret key to be shared in step S273 and "encapsulates" this 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" it from it in step S275 using her private key. Now Alice and Bob have 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 keys pre-shared using the method described with reference to FIG. 7 such 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 the module lattice. To briefly (and simplisticly) explain how it works (note that all calculations are implicitly done using modulo arithmetic with some pre-agreed (non-secret) modulus), the generation stage of the public / private key pair first comprises 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. To re-derive the private key from the public key, an attacker would need to solve the module-learning-with-errors (MLWE) problem, which is believed to be difficult even for a quantum computer.

[0063] For Bob to encapsulate a random binary string (to be used as a shared key) to send to Alice, the string is encoded as a polynomial, and Bob also computes some random value polynomials to use in the calculation. Ciphertexts are formed by multiplying Alice's public key by these polynomials and adding the shared key. The ciphertexts are then sent to Alice.

[0064] Alice decapsulates the ciphertext by multiplying one part of the ciphertext with her private key taken from another part of the ciphertext. The output is a noisy version of the shared secret key (because Bob intentionally added errors), but Alice is able to round off the noise perfectly to obtain the shared key because the errors are small. As a result, Alice and Bob are left with a shared secret key that can be used by the post-quantum key sharing module 119. The post-quantum key sharing module 119 can store pre-shared keys using the methods described above such that such keys are ready to be used, or the post-quantum key sharing module 119 can be configured to initiate the process described above to obtain such keys once the authentication engine indicates a need for a key.

[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 an authentication key. When generating the authentication key, the authentication engine: (i) selecting a type of key from the key management subsystem 111; (ii) combining the selected key; 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, and can then use this information to estimate how available the QKD key will be, and possibly deprioritize its use when it expects the rate to be low. (iii) QKD metrics (e.g., QBER, count rate, SBR) The QKD metric is used in the same way as the link metric. However, since the QKD metric is a QKD measurement, it has higher accuracy than the link metric. The QKD metric can be estimated from the link metric, which may 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. Thus, if the session is very short, the system may know that a lot of key material may be needed to use for authentication, and therefore may favor using PQC to avoid exhaustion of QKD keys. (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 the PQC key in combination with all other keys. Other organizations may always require the use of the QKD key to secure the ITS. Other organizations with some flexibility may define more complex rules (e.g., try to use QKD for authentication unless there is a scarce key pool for the application). Thus, weighting is applied, i.e. giving priority to certain key inputs over others. (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, whereas network policy is set by the network. In some cases, the user 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 manufacture 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 by using a pseudorandom function (PRF). Thus, given a 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 any ITS key 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 any ITS key below the 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 a key obtained from the classical key agreement module 117: As a shorthand expression, this is referred to as a "classical key", which is taken to mean a key 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: As a shorthand expression, 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 above, the key combiner decision logic 131 also accepts input from the key management subsystem, for example, which allows the user to set security policies and priorities for the organization. This information is translated into policy rules / configurations for the authentication engine (described below). In other embodiments, the policies / configurations 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. The key combiner decision logic 131 has been described above and it selects keys for combination 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. In Figure 8 the selection is illustrated by include modules 143, 145, 147 and 149 provided at the outputs of the PSK key store 113, the QKD key store 115, the classical key agreement module 117 and the post-quantum key agreement module 119 respectively. The key combiner decision logic 131 provides a control output to each include module 143, 145, 147 and 149 to indicate whether a key from the PSK key store 113, the QKD key store 115, the classical key agreement module 117 or the 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 if 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 state of the key pool (i.e., availability of QKD keys and PSKs), as well as user-defined / network-defined security policies. The output(s) from this 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 the PSK or QKD keying material is insufficient, the PSK and QKD keys may 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 can run multiple different classical and PQC algorithms. Even for the chosen algorithm, the combiner can vary the parameters of the algorithm, e.g., key size. One can imagine that a network administrator defines a list of organizationally approved algorithms that will be input as a security policy to the combiner, so it knows it is only using the approved ones.

[0082] For computationally secure key exchange methods, i.e. classical and PQC key exchange, 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 affect the security level, but it can increase the amount of available keys. Asymmetric cryptography is inherently computationally intensive, and classical / PQC key exchange often runs much slower than the QKD key generation speed. Therefore, the use of a PRF can equalize the size of the generated keys from each component being combined. The key combiner decision logic 131 can adjust the parameters and declare whether a PRF is used or not.

[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 low QKD key generation rates are possible (e.g., high loss, high QBER, low count rate, etc.), the combiner may preferentially select classical / PQC keys to use as component keys. This avoids using up 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 authenticated 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 selects 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] Figure 8 shows an XOR-based combining function, although 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 pipeline process in which the classical and PQC stages are performed sequentially, and also includes optional input state such as a session counter or a 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 FIG. 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] The key combination offers two practical advantages (even when the QKD key is available). 1) Compliance In controlled industries (e.g. finance), they set current regulatory requirements (e.g. NIST FIPS). It is understood that RSA / ECC will not work in the future, but current standards in 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 that their hardware works properly, but customers want peace of mind about new technology. With an XOR combiner, the final key is only as secure as one other part 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 an advantage over not having a combiner and generating a completely insecure key if QKD 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. This information may be stored as metadata along with the QKD keys generated during each authenticated post-processing session and made available to the user when the user requests the keys.

[0092] It was mentioned above with reference to Figure 4 that a key is used to compute the hash in S203 and then encrypt in S205. A different key is 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 individual 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 get input from various sources as described above. This may include a pre-shared symmetric key (PSK) installed in Alice and Bob by the vendor at 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 symmetric private keys 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 in order 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 to 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 issued as this indicates that the system has been compromised.

[0096] Above we used a MAC as a method to authenticate a message using a combined key, however the combined key may be used with any type of signature, even asymmetric signatures in some cases.

[0097] Figure 11 is a schematic diagram of a quantum communications 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 above key exchange techniques, which are performed over classical channels (conventional and PQC), require that a public key for a user (e.g. Alice) is available for use by another user (e.g. Bob). Care must be taken in obtaining the public key, since an attacker can act as a man-in-the-middle if he is capable of "tricking" a user into using an incorrect public key. Thus, keys exchanged classically during this time are likely to be insecure and should not be used for input to the key combiner (it is acknowledged that the advantage of the key combiner stage is that one bad key input cannot break the overall QKD authentication, but it is still important to minimize the risk of this happening by careful public key management).

[0099] For a QKD network with multiple systems 501, 503, and 505, with a central switch 507 for example to reconfigure which units are connected, 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 in 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 in the network manager / vendor and installed in the new system. All of the indexed public keys are also installed in the new QKD system 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 the need to send a key. If an attacker were to trick the system into entering using a different key, for example by changing the ID, the attacker would still not be able to authenticate with the system since he would not have the private key for any of the pre-generated secure keys and therefore would not be able to pose as a man-in-the-middle.

[0102] In a further embodiment, many private keys are pre-allocated to each system, thus allowing them to rotate the keys after a given time frame. For large networks, the 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 communication 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 to the combiner just in time. Alternatively, the classical key exchange stage may be run as a daemon to continuously populate a key pool of classical and PQC keys. When the key combiner is ready to be input at any time, the keys can be obtained from the pool. The advantage of this is zero delay in obtaining classical keys, but it 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 communications 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 high speed execution on FPGAs or dedicated ASICs / GPUs, allowing faster classical key changes and reduced power consumption.

[0106] When referring to random numbers throughout 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, since 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 to avoid unnecessary repetition like reference numerals are used to denote like features. 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 may be used to connect the nodes. Additionally, QKD protocols and designs such as Measurement Device Independent (MDI) and quantum repeaters such as Twin Field (TF) QKD are also possible, which may use the same authentication techniques to verify the integrity and authenticity of post-processing messages.

[0110] Although 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 other various 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 form or modification that falls 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 a quantum key between the node and the second node, the quantum key 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; A 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 controlling 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 pseudorandom 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 to 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 multiple keys shared with the second node over a classical communication channel are selected from one or more keys shared using multiple classical key exchange protocols and multiple post-quantum key exchange protocols.

9. The node of 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 and a second key is used for encryption, the first key and the second key are different and both 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 a plurality of keys to a key store of 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 that the authentication unit generates from the message with a signature received with the message, and the authentication unit is configured to determine that the message is authentic if the signatures match.

17. A first node, which is a node according to claim 2; A second node, which is a node according to claim 16; 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 look-up table, the authentication unit being configured to receive an index from the look-up table indicating which public key to use.

19. 1. A method for producing a signed message for authentication in a quantum communication network, comprising: Receiving a message to be sent over an authenticated channel; generating an authentication key; generating a signature from the message using the authentication key; Equipped with 11. The method of claim 10, wherein creating the authentication key comprises receiving information regarding operation of the quantum communications 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 over a classical communications channel.

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

Images