# Quantum Key Distribution in Kubernetes Clusters
## 2 Background
### Quantum Software Stack and the ETSI Standards  
The authors of [3] presented a first attempt in developing a software stack to enable cloud infrastructures, and more in general software-defined infrastructures, to use QKD. The above solution was called Quantum Software Stack (QSS) and released with an open-source license alongside that paper. QSS intends to fill the gap between QKD devices (that are often tailored to specific protocols and proprietary interfaces) and modern infrastructures, whose services need to be scaled, migrated, and reconfigured with great flexibility. QSS has also been designed to be compliant with the European Telecommunications Standards Institute (ETSI) standards on QKD [13]. As depicted in Figure 1, the first version of QSS was designed on four different layers. The lowest layer defines either QKD devices or QKD simulators useful for testing purposes. At this layer, QKD protocols take place with all their related requirements. For example, we generally need two communication channels for carrying on any protocols: a classical authenticated channel for sharing additional information during a key exchange(e.g., chosen bases, privacy amplification or error correction info) and a quantum channel where quantum information flows (i.e., encoded in photons). The layer immediately above contains the QKD module (QKDM) which serves as a wrapper for the QKD device so that each device in the QKD network could expose the same interface to the upper layer. This interface is called the southbound interface. Inter QKDM communication within the network takes place through the sync interface. A layer above, we find the Quantum Key Server (QKS), which is the core of the QSS and manages all the information regarding the exchange, stores the generated keys, triggers the exchange process, and collects routing information to reach peers in the QKD network. The highest layer is the Secure Application Entity (SAE) one. This level contains high-level applications that require cryptographic keys through the QKS using the northbound interface. Figure 2 provides a more detailed view of the QKS. In Section 3, we discuss some of the architectural components, such as the Redis and Routing modules that are part of the new QSS version presented in this paper. The other architectural modules remained almost unchanged from the previous version but they consistently improved with new features and enhancements (Section 3). To summarize the primary logic behind the QSS, we could start from the QKDM perspective, where there is a continuous exchange of keys with one of its peers within the QKD network. We identify this flow of key material as _Key Stream (KS)_. The QKS controls the life-cycle management of a KS. Each QKS could have different QKDMs to allow the management of several devices and thus reach different destinations. This feature also allows making QKSs within a QKD network acting as trusted repeaters (feature introduced in Section 3.2). Besides, we could imagine mapping more QKDMs on the same physical device to sustain different flows when devices support multiple streams. As represented in Figure 1, we could have a PTP exchange among Node A and Node B, or we could reach Node C from Node A passing through Node B (trusted repeater). In the first version of QKS, this feature was not available (Section 3.2). The QKS, in its original version, was mainly in charge of serving SAE key requests and providing QKDMs with information on where to store generated keys (e.g., ad-hoc Vault tokens). When an SAE wants to communicate securely with another one over the same QKD network, a _Key Reservation Process (KRP)_ is required. In particular, when a source SAE (master or mSAE) contacts its QKS and requires key material with the getKey call, it specifies the number of keys, their length, and the destination SAE (slave SAE or sSAE). Then, the KRP takes place between source and destination QKSs (where SAEs are located). If the KRP succeeds, the source QKS returns the required keys and their IDs.