QKD-KEM: Hybrid QKD Integration into TLS with OpenSSL Providers

TL;DR

The paper tackles quantum threats to TLS by proposing a hybrid QKD-KEM that integrates QKD with post-quantum cryptography through OpenSSL providers. It introduces two integration flows to accommodate both stateful ETSI 004 and stateless ETSI 014 QKD interfaces, leveraging a unified KEM that concatenates PQC secrets with QKD key material, so the total shared secret satisfies $|SS| = |K_{\mathrm{PQC}}| + |K_{\mathrm{QKD}}|$. The authors implement this in publicly available repositories, detailing architecture atop a forked Open Quantum Safe provider and ETSI API wrappers, and demonstrate feasibility with preliminary performance showing acceptable overhead in TLS handshakes (300–350 ms on production hardware) while highlighting the benefits of server-initiated versus client-initiated flows. The work shows that quantum-safe TLS can be approached with dual-layer security, indicating practical pathways toward production-ready quantum-threat resilience, albeit with considerations around key exposure in PoC deployments and the need for co-located QKD endpoints in real networks.

Abstract

Quantum Key Distribution (QKD) promises information-theoretic security, yet integrating QKD into existing protocols like TLS remains challenging due to its fundamentally different operational model. In this paper, we propose a hybrid QKD-KEM protocol with two distinct integration approaches: a client-initiated flow compatible with both ETSI 004 and 014 specifications, and a server-initiated flow similar to existing work but limited to stateless ETSI 014 APIs. Unlike previous implementations, our work specifically addresses the integration of stateful QKD key exchange protocols (ETSI 004) which is essential for production QKD networks but has remained largely unexplored. By adapting OpenSSL's provider infrastructure to accommodate QKD's pre-distributed key model, we maintain compatibility with current TLS implementations while offering dual layers of security. Performance evaluations demonstrate the feasibility of our hybrid scheme with acceptable overhead, showing that robust security against quantum threats is achievable while addressing the unique requirements of different QKD API specifications.

Figures (5)

• Figure 1: Client-initiated QKD-KEM handshake flow using both ETSI 004 and ETSI 014 APIs. The diagram shows QKD API calls during key generation, encapsulation, and decapsulation. Here, $p_k$ is the public key, $c_t$ is the ciphertext, and $s_s$ is the shared secret; $PQ \ c_t$ and $PQ \ s_s$ denote the post-quantum ciphertext and shared secret, respectively; $ctx$ represents the OpenSSL context. QKD-related API calls and cryptographic/key materials are highlighted in blue, while PQC-related ones are shown in green.
• Figure 2: Architecture of the hybrid PQC+QKD integration into TLS via the QKD-KEM Provider.
• Figure 3: Performance comparison of key generation, encapsulation, and decapsulation operations for different post-quantum KEM algorithms. Times shown in logarithmic scale (milliseconds).
• Figure 4: Performance comparison of key generation, encapsulation, and decapsulation operations for hybrid QKD-KEM algorithms. The increased times in key generation and encapsulation reflect the ETSI 014 API calls overhead. Times shown in logarithmic scale (milliseconds).
• Figure 5: Performance comparison of TLS handshake times using RSA-2048 certificates for standard PQC and hybrid QKD-KEM approaches with production Cerberis XGR QKD hardware. Tests conducted between Madrid (client/server endpoints) and University of Vigo (QKD nodes) show reduced latency compared to simulator-based tests. Times shown in logarithmic scale (milliseconds).