qcve-logo

Build Quantum-safe Shields Today for Defence against Harvest-now-decrypt-later Attacks

Copilot (with prompts from the pQCee Content Team)

Copilot (with prompts from the pQCee Content Team)

Quantum computing introduces a structural break in how key establishment must be designed. Even though large‑scale cryptanalytic quantum computers are not yet available, attackers are already collecting encrypted traffic across public networks, cloud backbones, and inter‑site VPNs. This Harvest‑Now‑Decrypt‑Later (HNDL) pattern means that any long‑lived or high‑value data transmitted today using classical key exchange (DH/ECDH/RSA) may be decrypted in the future.

For technical architects, the challenge is immediate: How do you protect data‑in‑transit now, while your organization is still mapping cryptographic assets and planning a full PQC migration?

This blog explains how Quantum Key Infrastructure (QKI)—specifically pQCee’s QKDLite combined with Thales Luna HSM—provides a deploy‑today, standards‑aligned upgrade path for IPsec VPNs using IETF RFC 8784.

1. Why Classical IPsec Key Exchange Is Insufficient

IPsec tunnels typically rely on:

  • Diffie‑Hellman (DH)
  • Elliptic‑Curve Diffie‑Hellman (ECDH)
  • RSA‑based authentication
  • IKEv2 key derivation using classical primitives

All of these are vulnerable to future quantum attacks. Even if the tunnel is secure today, any adversary capturing ESP packets can decrypt them later once quantum computers mature.

From an architectural perspective, this creates a temporal vulnerability window:

+ Today: Data transmitted → Captured by attacker → Stored

++ Future: Quantum computer arrives → Classical keys broken → Data decrypted

This is why technical architects cannot rely solely on long‑term migration plans. You need a quantum‑safe key establishment layer now.

2. Introducing Quantum Key Infrastructure (QKI)

QKI is an architectural pattern that adds a quantum‑safe key source outside the classical key exchange path. Instead of replacing IPsec, QKI augments it with dynamic short-lived Post‑Quantum Preshared Keys (PPK) delivered through a secure out‑of‑band channel.

pQCee’s QKDLite implements this pattern using:

  • NIST PQC algorithms (ML‑KEM & ML-DSA)
  • QRNG entropy
  • Thales Luna HSM for FIPS‑140 key protection
  • RFC 8784 for hybrid IPsec key establishment

This allows existing VPN gateways to operate in a quantum‑safe hybrid mode without firmware upgrades or hardware replacement.

3. How QKDLite + Luna HSM Works (Technical Flow)

Below is the architectural flow, written for engineers and architects:

Step 1 — PQC PPK Generation

QKDLite orchestrates PQC PPK generation using a combination of secure entropy with FIPS‑based mechanisms. The private key material is stored and protected inside a Thales Luna HSM, ensuring:

  • FIPS‑140‑validated protection
  • CNSA 2.0 alignment
  • Secure entropy injection via QRNG

Step 2 — Out‑of‑Band PPK Delivery

QKDLite establishes a secure management channel between sites. Through this channel, it delivers a Post‑Quantum Preshared Key (PPK) that is:

  • Independently generated
  • Periodically refreshed
  • Cryptographically isolated from IKEv2’s classical exchange

Step 3 — IPsec Integration (RFC 8784)

The PPK is injected into the IPsec stack on both ends via ETSI QKD 014 API. IKEv2 then performs a hybrid key derivation:

Code

Final Key = Classical DH/ECDH output

          + PQC PPK

          + Additional entropy

This hybrid model ensures that even if classical DH/ECDH is broken in the future, the PQC PPK prevents retrospective decryption.

Step 4 — Quantum‑Safe Tunnel Established

The resulting IPsec tunnel is:

  • Resistant to HNDL attacks
  • Compatible with existing VPN gateways
  • Automatically refreshed without downtime
  • Transparent to applications and routing layers

This has already been deployed with:

  • Fortinet FortiGate
  • StrongSwan‑based VPNs
  • Multi‑site and hybrid cloud architectures

No changes to routing, firewall rules, or overlay networks are required.

4. Operational Considerations for Technical Architects

Deployment Model

QKDLite can be deployed:

  • As a virtual appliance
  • As a containerized service
  • As a hardware‑secured module paired with Luna HSM

Key Refresh Policies

Architects can define:

  • Refresh intervals
  • Entropy sources
  • Failover behavior
  • Multi‑site key distribution topologies

Monitoring & Observability

QKDLite exposes metrics for:

  • Key generation events
  • PPK refresh cycles
  • Tunnel health
  • Cryptographic compliance status

Integration with Existing Security Architecture

QKDLite fits naturally into:

  • Zero‑trust network overlays
  • SD‑WAN architectures
  • Cloud‑to‑cloud encrypted backbones
  • Multi‑region data center connectivity

5. Future‑Ready: QKD Integration Path

While PQC is the immediate priority, QKDLite is architected to accept QKD‑derived keys in the future. This means:

  • No redesign of your IPsec architecture
  • No change to routing or tunnel topology
  • QKD keys simply become another input source for the PPK mechanism

Architects can plan for a PQC → hybrid PQC+QKD → full QKD evolution without disruption.

Conclusion for Technical Architects

Quantum‑safe migration is a multi‑year program involving discovery, inventory, remediation, and crypto‑agility. But data‑in‑transit cannot wait for those programs to finish.

Deploying pQCee’s QKDLite with Thales Luna HSM gives you:

  • A deploy‑today quantum‑safe key establishment layer
  • RFC 8784‑compliant hybrid IPsec tunnels
  • Protection against HNDL attacks
  • FIPS‑140 and CNSA 2.0 alignment
  • A future‑ready path to QKD

This is the first quantum‑safe shield you can implement immediately while you continue building your long‑term cryptographic migration roadmap.

Catalog

Built with Konigle