CV-QKD Network Architecture

Scaling the PIC-based continuous-variable QKD link to a metropolitan-scale trusted-node backbone, with hybrid PQC + QKD key management and a detector-attack threat model.

Phase 2 shipped · source on GitHub

What this is

A systems-engineering project that takes the existing single-span PIC-based CV-QKD link and asks the next question: what does it take to operate a real network of these? The answer is not just more photonics. The hard problems live in topology, key management, integration with classical PKI, and a threat model that takes implementation attacks seriously.

The deliverable on this page is the architecture and trade-space artifact. Simulation and protocol code are the next phase; the artifacts here are what scope and justify that work.

System requirements

ID	Requirement	Source
`SR-01`	Metropolitan-scale coverage (≤ 100 km between trusted nodes over standard SMF-28)	Project scope
`SR-02`	Secret key rate ≥ 1 kbps end-to-end at 50 km, finite-size composable security	ETSI GS QKD 002 V1.1.1
`SR-03`	Integration with classical PKI; QKD-derived keys used for AES-256-GCM session keys via hybrid KDF	ETSI GS QKD 014; NIST SP 800-56C
`SR-04`	Co-existence with classical DWDM traffic on the same fiber where physically possible	Operational realism
`SR-05`	Resilient to single-trusted-node compromise (defense in depth via PQC overlay)	Threat model
`SR-06`	Standardized northbound API for key delivery (ETSI GS QKD 014)	Standards compliance
`SR-07`	Documented detector-attack countermeasures (calibration attack, Trojan-horse, saturation)	Threat model

Network architecture

The proposed architecture is a trusted-node backbone with hybrid PQC+QKD key derivation at every hop. End-to-end key material is the XOR of a QKD-derived key and a PQC-derived key (per ETSI GS QKD 014 hybrid mode), so a compromise of either layer alone does not break confidentiality.

Metropolitan-scale CV-QKD trusted-node backbone Site A Trusted Node 1 Trusted Node 2 Site B +----------+ +-----------+ +-----------+ +----------+ | App / KMS| | CV-QKD Tx | | CV-QKD Tx | | App / KMS| +----+-----+ | + Rx | | + Rx | +----+-----+ | | + Key mgr | | + Key mgr | | | ETSI 014 API +-----+-----+ +-----+-----+ ETSI 014 API| v | | v +----+------+ | k_AB^QKD | k_BC^QKD +-----+----+ | Hybrid KDF|<------- QKD --+----- single span ------>+---- span ---->| Hybrid | | (QKD xor | | (CV-QKD over fiber) | | KDF | | PQC) | | | | | +-----------+ +-----+-----+ +-----+-----+ +----------+ | PQC (Kyber| | PQC (Kyber| | 768) KEM | | 768) KEM | +-----------+ +-----------+ shared k_AB^PQC shared k_BC^PQC (classical channel) (classical channel) End-to-end key k_AB = HKDF( k_AB^QKD || k_AB^PQC ), similar for k_BC. Trusted-node compromise leaks one hop's k_QKD but not the PQC overlay end-to-end.

Layer model

L1 Physical: CV-QKD with Gaussian-modulated coherent states; homodyne or heterodyne detection (trade study below).
L2 Sift & reconcile: multi-dimensional reconciliation (LDPC with rate ≥ 95% of Shannon limit); slice or RAW reconciliation per literature.
L3 Privacy amplification: finite-size composable security accounting per Pirandola et al, ETSI GS QKD 002.
L4 Key management: per-hop QKD key store + PQC KEM overlay; HKDF combines both into the application key.
L5 Application: ETSI GS QKD 014 REST API (get_key / get_key_with_key_ids) for downstream consumers (IPsec, MACsec, TLS-with-EKMS).

Trade studies

1. Network topology

Option	Reach	End-to-end trust assumptions	Cost	Verdict
Point-to-point only	≤ 80 km	Endpoints only	Low	Baseline (matches existing link work)
Trusted-node chain	Unlimited (per added node)	Every node trusted	Medium	V1 selection
Star (hub-and-spoke QKD switch)	≤ 80 km radius	Hub trusted	Medium (single hub failure)	Considered for campus deployments
Measurement-Device-Independent QKD	Asymmetric reach	Endpoints only (untrusted relay)	High (MDI-QKD hardware not yet at this maturity for CV)	V2 roadmap
End-to-end via quantum repeaters	Unlimited	Endpoints only	Out of band (research-only)	Out of scope

Trusted-node is the only topology with a credible deployment path at metropolitan scale today. Hybrid PQC overlay compensates for the trust assumption so a single compromised node does not collapse end-to-end confidentiality.

2. Detection scheme

Option	Information per pulse	Hardware	Side-channel exposure	Verdict
Homodyne (X xor P, switched basis)	1 quadrature	Single balanced receiver + active LO basis switch	LO calibration attack surface	—
Heterodyne (X and P simultaneously)	Both quadratures (with 3 dB penalty)	Dual balanced + 90° hybrid	Wider RF surface but no basis-switching exploit	Selected (no-switching protocol)

3. PQC overlay primitive

Option	Throughput	FIPS approval	Verdict
ML-KEM-768 (Kyber768)	High	FIPS 203, Aug 2024	Selected
ML-KEM-1024	High	FIPS 203	Optional for category-5 deployments
Classic McEliece	Low (giant pub keys)	Not yet FIPS-approved	Rejected (key-size impractical)

Direct synergy with the PQC-on-RISC-V system project: the trusted-node hardware can host the same Kyber768 accelerator used as the network-overlay primitive here.

Threat model

CV-QKD's information-theoretic security proof holds for the protocol but not automatically for its implementation. The catalog below is what an attacker can actually try against a deployed CV-QKD network, and how this architecture defends.

Threat	Vector	Mitigation	Residual risk
Trusted-node compromise	Physical or insider access to one relay	Hybrid PQC overlay: end-to-end key remains computationally secure under PQC assumption even if one hop's QKD key leaks	Multiple-node compromise still possible (out of scope of single-vector defense)
Local-oscillator calibration attack	Eve manipulates LO intensity reference to fake low shot noise	Real-time shot-noise calibration with per-pulse monitoring; outlier rejection	Sophisticated correlated attacks not fully addressed in V1
Trojan-horse attack	Eve injects bright light into Tx to probe modulator state	Optical isolator (> 80 dB) and spectral filter at Tx output; backlight monitor	Low
Detector saturation	Eve forces detector into nonlinear regime	Variable optical attenuator with calibrated set-point; live linearity monitoring	Bandwidth-limited; documented for integrators
Side-channel on classical post-processing	Timing or power analysis of reconciliation / privacy amplification	Constant-time LDPC decoding; hardware-accelerated HKDF	Same posture as the PQC project — TVLA target
Quantum-computer attack on PQC overlay	Future CRQC breaks Kyber	QKD layer remains information-theoretically secure under one assumption (correct implementation); rotate to ML-KEM-1024 + larger if CNSA guidance changes	Tracked via NIST PQC bulletins

Standards alignment

ETSI GS QKD 002 — use cases, finite-size security accounting
ETSI GS QKD 014 — REST API for key delivery to applications
ETSI GS QKD 015 — control interface for SDN-managed networks
NIST SP 800-56C — KDF for combining QKD and PQC key material
CNSA 2.0 — operational guidance on PQC migration; provides the framing for the hybrid overlay

Performance budget

Targets, not measurements. Will be back-annotated as the simulation model produces numbers.

Span loss target

≤ 10 dB (≈ 50 km SMF)

Excess noise target

ξ ≤ 0.02 SNU

Reconciliation efficiency

β ≥ 0.95

Secret key rate @ 50 km

≥ 1 kbps (finite-size)

Per-hop key store

≥ 10 Mb buffered

API latency (ETSI 014)

≤ 100 ms p95

PQC overlay throughput

≥ 1k handshakes/s

Composable security ε

≤ 10⁻¹⁰

Verification & validation plan

Link-level simulation — Python / NumPy model of single-span CV-QKD with realistic excess noise, finite-size effects, and reconciliation cost. Output: secret key rate vs distance curves.
Network-level simulation — NS-3 or OMNeT++ model of the trusted-node backbone; trace key consumption against application demand profiles (IPsec rekey rate, MACsec, TLS).
Protocol-level fuzzing — formal-style property tests on the ETSI GS QKD 014 API: replay safety, key-ID uniqueness, key destruction on read.
Threat-model exercise — for each entry in the threat table, document the experiment that would validate the mitigation if hardware were available (testbed list).
Standards conformance — REST API exposed by the simulator passes the ETSI GS QKD 014 test vector pack.

Roadmap

Phase 1 (shipped): Architecture, topology trade studies, threat model, performance budget — this document.
Phase 2 (shipped): Single-span Python simulator (asymptotic + finite-size SKR), multi-hop trusted-node backbone with hybrid PQC + QKD HKDF, and the FastAPI ETSI GS QKD 014 reference server. 44 tests passing (1 documented xfail on an asymptotic-SKR approximation). Source: cvqkd-network.
Phase 3: Multi-hop NS-3 model with per-hop key stores, application demand, and PQC overlay rekey.
Phase 4: ETSI GS QKD 014 reference server in Python; conformance tests.
Phase 5: Integration story with the PQC-on-RISC-V accelerator: trusted-node hardware bill of materials.

Source & documentation

Repository · github.com/alovladi007/cvqkd-network
Phase 2 is in: Python single-span simulator (asymptotic + finite-size SKR), multi-hop trusted-node backbone with hybrid PQC + QKD HKDF, working ETSI GS QKD 014 REST API stub (FastAPI), 44 tests passing (one xfail with a documented limitation in the asymptotic SKR formula), and CI booting the REST server on every push.

Source & tests Protocol doc Threat model Related: PIC-based CV-QKD link optimizer Related: PQC on RISC-V (sister project) ETSI GS QKD 014 ETSI GS QKD 002