# Quantum Key Distribution in Kubernetes Clusters
## 7 Conclusions  
This paper, starting from the work in [3], proposes a new version of QSS that presents multiple enhancements: an increase in performance due to an asynchronous and multiprocess approach, the compliance with multi-hop long-distance QKD using trusted repeaters, and a routing module to select the best path for an MH exchange. Moreover, the solution has been integrated into Kubernetes as an operator, allowing the containerized application to leverage keys exchanged with QKD. This approach is modular, scalable, and almost entirely agnostic to high-level security applications. The source code is publicly available on GitHub [40; 41]. Some existing limitations, such as the maximum throughput in key exchange among QKDMs and possible straightforward remediations, have been discussed. Even if this solution is still at its early stage, it is promising and as a future work it could be interesting to test it in actual use case scenarios.  
Two of the most relevant outcomes of this work are the fact that this is an entirely open-source vendor-agnostic framework, the first trying to simplify the integration of QKD in Kubernetes, and the possible applications to interesting scenarios such as the blockchain technologies. In future work, it would be interesting to test practical blockchain applications using the QSS operator and a multi-cluster Kubernetes architecture. In addition, targeting  
Figure 11: Average convergence time of the routing algorithm depending on the number of nodes in the QKD network.  
large and complex QKD networks is still a challenging task. In this regard, it would be intriguing to introduce SDN technology to simplify the management of the QKD network apparatuses offloading the routing module. Another relevant aspect for the future of QKD networks will impact the choice of relays: overcoming trusted repeaters in favour of quantum-based relays. Finally, multiple aspects regarding the security of the QSS software itself running on a cluster shall be considered in the future: being compliant with the paradigms of Confidential Computing as well as adopting consistent software protection techniques.  
Conceptualization, I.P. and A.L.; methodology, I.P.; software, I.P.; validation, I.P.; formal analysis, I.P.; investigation, I.P.; resources, I.P. and A.L.; data curation, I.P.; writing--original draft preparation, I.P. and A.L; writing--review and editing, I.P. and A.L.; visualization, I.P. and A.L.; supervision, A.L.; funding acquisition, A.L. All authors have read and agreed to the published version of the manuscript.  
This work was supported by the European Union's Horizon 2020 Project \"CyberSec4 Europe\" under Grant 830929.  
Not applicable.  
We acknowledge the contribution of [PERSON] to the implementation of the solution.  
The authors declare no conflict of interest.  
The following abbreviations are used in this manuscript:  
\begin{tabular}{l l} AES & Advanced Encryption Standard \\ API & Application Programming Interface \\ CR & Custom Resource \\ CV-QKD & Continuous-Variable QKD \\ DV-QKD & Discrete-Variable QKD \\ ECDSA & Elliptic Curve Digital Signature Algorithm \\ ETSI & European Telecommunications Standards Institute \\ ETSI ISG & ETSI Industry Specification Group \\ KRP & Key Reservation Process \\ KS & Key Stream \\ GIL & Global Interpeter Lock \\ IoT & Internet of Things \\ IPsec & Internet Protocol Security \\ MDI-QKD & measurement-device-independent QKD \\ MH & Multi-Hop \\ mSAE & master SAE \\ LSA & Link State Advertisement \\ NFV & Network Functions Virtualisation \\ NIST & National Institute of Standards and Technology \\ OSPF & Open Shortest Path First \\ PQC & Post-Quantum Cryptography \\ PTP & Point-to-Point \\ QKD & Quantum Key Distribution \\ QKDM & QKD Module \\ QKRA & Quantum Key Reservation Approach \\ QKS & Quantum Key Server \\ QoS & Quality of Service \\ \end{tabular}