1. Overview¶

1.1. Background¶

Quantum Key Distribution (QKD) promises quantum keys that are unpredictable and indeterministic. But the transient (one-time-use) and point-to-point nature of QKD is not suitable for all types of use cases.

Store-and-forward protocols (e.g., secure email), permanent storage (e.g., file transfer), periodic usage (e.g., payment master keys) are some use cases that will benefit from using quantum keys, but require a more persistent means to store these keys for subsequent usage.

This is where QKDLite comes in. Using QKDLite together with a Hardware Security Module (HSM) infrastructure and a QKD infrastructure, we are able to bridge the difference in key management requirements between what QKD provides versus what business applications need.

QKDLite also supports quantum-safe communications alongside existing HSM and QKD infrastructures. This is achieved with the seamless integration of pQCee’s pqTLS, which enables quantum-safe protocols with QKDLite nodes while maintaining backward compatibility with classical Transport Layer Security (TLS) in existing IT infrastructure.

1.2. Key Terms and Concepts¶

This manual uses key words and concepts from the quantum cybersecurity domain, in particular, from the ETSI standards context. For readers who are not familiar in this area, you are encouraged to read this section before proceeding to the other parts of the manual.

1.2.1. Quantum Key¶

A quantum key is a random secret key generated from a quantum physical process. The quantum key is inherently more secure than a classical key because it is generated from a truly random quantum physical process, whereas a classical key is usually generated from a deterministic algorithm that can be vulnerable to attacks.

For easy differentiation, we refer to a QKD quantum key as a secret key generated from a QKD process, and a quantum key as a secret key generated from a non-QKD quantum physical process.

1.2.2. QKD Entity¶

The Quantum Key Distribution (QKD) Entity is a hardware appliance that provides the QKD function. A minimum of two QKD Entities are required to perform a QKD process with each other using QKD protocols. At the end of the QKD process, both QKD Entities will derive the same QKD quantum key.

1.2.3. KME¶

The QKD Entity usually integrates a key management component, known as the Key Management Entity (KME), that exposes an IT interface compliant with the ETSI GS QKD 014 protocol. Security appliances can connect to this KME interface to request for QKD quantum keys.

For example, a VPN appliance that supports **post-quantum preshared keys (PPK)** can request for QKD quantum keys from the KME of a QKD Entity.

1.2.4. QRNG¶

The Quantum Random Number Generator (QRNG) is a device that utilises a quantum physical process to generate quantum keys. A QRNG can be considered as a True Random Number Generator or a Hardware Random Number Generator.

1.2.5. Quantum-safe Communications¶

Network communications between computers on the internet today largely relies on secure communications protocols (e.g., TLS and SSH) that utilises classical ciphers to secure network data. Quantum-safe communications, are secure communication protocols that utilises post-quantum cryptography (PQC) ciphers to secure network data.

Some examples of PQC ciphers are ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205).

1.3. Technical Architecture¶

A QKDLite node connects to at least one other QKDLite node, to provide key replication activity from the main node to the remote node. The main node is the QKDLite node that initiates the creation of a quantum key locally and it controls replication of this quantum key to at least one other remote node.

The minimal setup is a pair of QKDLite nodes performing key replication from the main node to the remote node. Additionally, the QKDLite node can also be configured to connect to a HSM appliance, to a QKD Entity, and to a QRNG source.

Each QKDLite node contains the following components:

Transport Key Utility - a program named Insert2HSM allows the customer to provision a Transport Key in the QKDLite node. The Transport Key is a 256-bit secret key involved in the wrapping of keys during export and unwrapping of keys during import. QKDLite nodes must be provisioned with the same Transport Key to replicate keys to one another.
QKDLite Utility - a program named QKD2HSM that interfaces with both PKCS #11 key storage and ETSI GS QKD 014 KME interfaces to handle QKD/QRNG quantum key operations, namely key creation, key deletion, key listing, key count, key retrieval, key export and key import. The QKDLite Utility is also used to select the PKCS #11 key storage to save and retrieve quantum keys.
QKDLite Scripts - a suite of scripts that facilitate key management workflows via the QKDLite Utility and perform fail-safe replication of key activity across QKDLite nodes.
Local Key Storage - a software-based PKCS #11 key storage module to store and retrieve quantum keys in the filesystem in the QKDLite node. This is the default PKCS #11 key storage location when QKDLite is installed out of the box.
ETSI Server - a HTTP server named QKDLite_ETSI that enables security appliances to connect and request for quantum keys using ETSI GS QKD 014 protocol.

QKDLite nodes connect to one another using quantum-safe connection. A QKDLite node uses a quantum-safe key encapsulation algorithm to securely send sensitive key material to HSM appliances. The QKDLite node uses quantum-safe connection to QKD appliances.

1.4. Deployment Configuration¶

QKDLite is designed for seamless integration with network appliances that support quantum-safe TLS. This deployment scenario is described in Configuration #1 below.

Although some network appliances are limited to classical TLS, quantum-safe TLS can be achieved by placing pQCee’s pqTLS in front of the network appliance.

1.4.1. Configuration #1: QKDLite with quantum-safe TLS Capable Appliance¶

Fig. 1.1 QKDLite with PQC TLS Capable Appliance¶

Each HSM Entity consists of a Business App and the HSM appliance itself. The Business App consumes secret keys from the HSM appliance to perform secure business transactions daily.

The QKD Entity connects together in a pair to derive new QKD quantum keys. QKDLite nodes interfaces with the QKD Entities request for new QKD quantum keys and stores the QKD quantum keys in the HSMs.

Within each QKD-enabled site, QKDLite communicates with both HSM and QKD Entity to generate and store QKD quantum keys. QKDLite can be paired to replicate key management activity from one site to another site in a quantum-safe and fail-safe manner. This pairing can also be extended to sites without access to a QKD infrastructure.

In the context of a triple-site-replication setup, QKDLite can be deployed to HSM and QKD infrastructures as shown in the diagram above. Site A (left column containing HSM A) and Site B (middle column containing HSM B) are operational HSM sites located in regions that have connections to a common QKD infrastructure. Site C (right column containing HSM C) is an operational HSM site located in a different region that has no QKD infrastructure. QKDLite replicates key management activity from Site A to Site B, and from Site B to Site C. In this manner, although Site C has no access to a QKD infrastructure, QKD quantum keys remain accessible to the Business App at Site C.

1.4.2. Configuration #2: QKDLite with pQCee pqTLS¶

The deployment setup is similar to Configuration #1 earlier with one difference: the inclusion of pQCee pqTLS.

pqTLS will be co-located with the QKD appliances in a higher trust zone and will front all external incoming traffic on behalf of the QKD appliances. QKDLite will communicate with the QKD appliances using quantum-safe TLS via pqTLS, thus enabling quantum-safe communication with the QKD appliances.

1.4.3. Configuration #3: Digital QKD¶

A typical digital QKD configuration involves deploying two QKDLite nodes and two VPN gateways supporting PPK. Each VPN gateway will request for quantum keys from a QKDLite node. As shown in the diagram above, the main node will generate quantum keys from its QRNG source and replicate the quantum keys to the remote node over the internet.

1.4.4. Configuration #4: Digital QKD with pQCee pqTLS¶

If the VPN gateway supports only a classical connection, pQCee pqTLS can be co-located together with the VPN gateways in a higher trust zone to provide a quantum-safe connection to the QKDLite node over the internet. As shown in diagram above, the connections over the internet are all quantum-safe connections.

1.4.5. Configuration #5: High-availability QKDLite¶

In high-availability configuration, a cluster of QKDLite nodes are used in place of both the main node and remote node. In this configuration, QKD key management gracefully failovers across each pair of QKDLite nodes should an error arise in the node. Each QKDLite node also gracefully failovers across KMEs for QKD Entities should an issue arise with accessing a KME. This configuration ensures a continuously operational and resilient QKD infrastructure accessible to critical business applications, such as site-to-site VPN gateways.