Introduction
Pilot 3 addresses the transition to Post-Quantum Cryptography (PQC) in the software environments used by telecommunications operators and network providers. It focuses on two main challenges:
- Mass adoption of network virtualization and programmability architectures such as Network Functions Virtualization (NFV) and Software-Defined Networking (SDN), which decouple control and data planes and enable dynamic programmability.
- Integration of complementary transition technologies in the post-quantum transition, like Quantum Key Distribution (QKD), leveraging existing data-center infrastructure to host physical QKD systems.
This pilot aligns the PQC transition with container-based virtualization and secure data-plane interconnectivity, applying hybridization strategies combining on demand PQC with QKD programmatically to virtual-node interconnections.
The pilot is built on an IKE-less IPsec technology, which implements a controller-based IPsec configuration and leverages hybrid PQC/QKD without the need for the IKEv2 protocol, which is vulnerable to quantum computers’ attacks to key exchange protocols.
System Architecture
The proposed solution secures communications within Kubernetes (K8s) clusters by deploying a hybrid quantum-safe architecture that integrates advanced cryptographic technologies and centralized network management. The system is organized into two main parts: the Kubernetes Controller Node and the Kubernetes Worker Nodes, each fulfilling distinct roles to ensure robust, quantum-resilient security for virtualized workloads.
Controller Node
At the core of the architecture, the K8s Controller Node orchestrates the overall management of virtual networks. Virtual networks are K8s resources in charge of interconnecting workloads (pods) within a cluster as if they were co-located in the same geographical location. For this purpose, L2S-M creates an overlay network to build a programmable data plane that enables the traffic exchange between workloads. In this regard, the L2S-M Controller is responsible for managing both the lifecycle of virtual networks and overlays within the cluster, including its creation, configuration, and deletion. These overlays consist of a couple of virtual switches and VXLAN endpoints on worker nodes, ensuring seamless connectivity across the cluster. To incorporate the programmability aspect for the dynamic management of virtual networks, the SDN Controller programs the forwarding tables of these virtual switches using OpenFlow, thereby enabling precise traffic steering based on the membership of Pods in each virtual network.
A critical component of the Control plane is the Centrally Controlled IPsec (CCIPS) Controller, which supervises the establishment and maintenance of CCIPS tunnels. This controller initiates the quantum-secure tunnel setup process by distributing Security Association parameters to the worker nodes using RFC 9061-compliant JSON messages. Between those parameters are the data plane protection mechanisms in IPsec, which utilize SHA-256 for integrity and either AES-GCM or AES-CBC for encryption, ensuring the confidentiality and authenticity of the connections. Before any tunnel can be established, the Trust Manager steps in to perform remote attestation of the worker node software components. This process verifies the authenticity and integrity of all relevant modules, providing a foundation of trust before sensitive operations commence.
Worker Nodes
On the Kubernetes Worker Nodes, the switch leverages VXLAN interfaces to establish secure, scalable connectivity with other nodes in the cluster (L2S-M overlay network). Each worker node also hosts a CCIPS Module, which includes CCIPS Agents, a Proxy Agent, and the Hybridization component. This module is designed to establish quantum-secure IPsec tunnels without relying on traditional IKEv2 negotiated keys, instead utilizing a controller-driven approach in line with RFC 9061.
The Proxy Agent receives messages in RFC 9061 JSON format from the CCIPS Controller. Based on the information received, it generates an ETSI GS QKD 004 request addressed to the Hybridization component, which is responsible for correlating the different endpoints involved in the IPsec tunnel.
Upon receiving the request, the Hybridization component processes it in two distinct paths:
- Quantum key extraction: The module interfaces with QKD devices using standard ETSI GS QKD 004 messages.
- Post-quantum key generation: In parallel, the module establishes an agreement with its peer Hybridization Modules to derive a shared key using post-quantum cryptography algorithms, such as ML-KEM-512.
Once both keys (quantum and post-quantum) are obtained, the Hybridization Module applies a hybridization technique, such as XOR or HMAC, to combine them securely. If only one key source is available, the module derives an auxiliary key deterministically using hashing functions.
All configuration steps are orchestrated by the CCIPS Module in the initial phase, aligning the endpoints according to network policies or administrator-defined requirements.
Finally, the resulting hybrid key is returned to the Proxy Agent, which, along with the Security Association parameters received from CCIPS Controller, converts the data into RFC 9061 XML messages. These messages are then sent to the CCIPS Agents via NETCONF, completing the setup of the IPsec tunnel secured with a hybrid quantum/post-quantum key.
The Hybridization Module interfaces with QKD systems via an API server compliant with standard ETSI GS QKD 004. This server delivers quantum key material to both endpoints using an index-based synchronization mechanism, ensuring identical keys are available simultaneously at each node. Key features include:
- Hardware agnosticism: Seamless compatibility with any QKD systems.
- Containerized deployment: Fully Dockerized and automated solution (API server, client, test modules, and QKD simulator).
For this pilot, the QKD link is deployed over an urban free-space channel, and BB84 protocol with single-photon polarization encoding is employed to perform the quantum key exchange. Post-processing for information reconciliation includes error correction via LDPC belief propagation decoding. Finally, privacy amplification hashing algorithms, such as Toeplitz universal hash, are used to minimize eavesdropper information gain.
Generated keys are stored locally in QKD devices and delivered to the CCIPS agent via the ETSI GS QKD 004 interface.
Operational Workflow
The operational workflow begins with the deployment of the L2S-M Operator and SDN Controller on the Controller Node using standard Kubernetes command-line tools. The L2S-M overlay is then configured using the K8s CLI, and L2S-M switches along with VXLAN endpoints are deployed across the worker nodes based on the specifications defined in its deployment. When secure communication is required, the L2S-M Controller instructs the CCIPS Controller to initiate hybrid key negotiation, combining PQ KEM and QKD material, and triggers the attestation process. The Trust Manager coordinates remote attestation across the relevant worker nodes, and upon successful verification, authorizes the creation of the tunnel. The CCIPS Controller then sends setup requests to the CCIPS Agents, which acquire and hybridize keys from QKD and PQC sources. The Proxy Agent delivers the necessary configuration to the CCIPS Agents, which bring up the tunnel and confirm activation to the controller, thereby enabling secure intra-cluster communication.
When deploying cloud-native functions (CNFs), administrators create the virtual networks as K8s resources using the Kubernetes CLI. If pods want to take advantage of QUBIP’s connectivity solution their deployment will include the corresponding annotation of one, or several, virtual networks. With this information, the L2S-M Controller assigns interfaces on the L2S-M switches of the nodes where the pods were deployed, while the SDN Controller programs the forwarding rules through the OpenFlow protocol according to the virtual network members. All overlay links between nodes operate over quantum-secure IPsec tunnels, with key material combined from ML-KEM-512 and QKD sources using either XOR or HMAC hybridization, ensuring robust protection against both classical and quantum adversaries.
This architecture provides a centralized, standards-based approach to quantum-resilient security within Kubernetes clusters. By combining post-quantum cryptography and quantum key distribution, enforcing remote attestation, and leveraging open standards such as OpenFlow, VXLAN, RFC 9061, NETCONF, and ETSI QKD 004, the solution delivers highly automated, interoperable, and future-proof secure communications for cloud-native environments.
The pilot enables the validation of the PQC transition in a realistic telecom solution, assessing compatibility with technologies such as QKD, in scenarios involving secure communications between virtualized network functions.
Conclusions
This pilot delivers an end-to-end solution for migrating data plane communications to post-quantum cryptography in virtualized telecom networks. By combining an IKE-less IPsec with PQC + QKD hybridization under RFC 9061 and ETSI QKD 004 standards, it provides robust, scalable, and standards-compliant secure communications for cloud-native network functions.
