up:: [[Navon MoC]] related:: [[Navon Security Offering]] | [[Quantum Security MOC]] | [[Cryptography MOC]] | [[Hardware Security Modules (HSM) MOC]] # Security Testbed Deployment MOC This MOC captures the infrastructure requirements, architecture, and deployment logic for a **Quantum-Safe Network (QSN) testbed** — a controlled environment to validate [[Post Quantum Cryptography|post-quantum cryptography]], [[QKD Protocol Quantumness|quantum key distribution]], and [[Crypto-agility|crypto-agile]] infrastructure before sovereign-grade production rollout. Source document: *QSN Infrastructure Requirements (2025)* --- ## 1. Purpose & Strategic Context The testbed exists to de-risk [[Navon Sovereign Vaults|Sovereign Vault]] deployments by validating quantum-safe technologies in a realistic but contained environment. It bridges the gap between laboratory demonstrations and production-grade [[Data Embassies|data embassy]] infrastructure. Core objectives: - Validate interoperability of [[Hybrid Cryptography as the bridge to Post Quantum Security|hybrid cryptographic]] stacks (classical + PQC) under operational conditions - Benchmark [[Hardware Security Modules (HSM) MOC|HSM]] performance with PQC algorithm loads ([[HSM x PQC]]) - Test QKD link stability, key rates, and integration with conventional network infrastructure - Prove [[Crypto-agility]] — the ability to hot-swap cryptographic algorithms without service interruption - Generate evidence for [[promised based to evidence based security|evidence-based security]] claims to sovereign clients This maps directly to [[Quantum Readiness Program|Phase 3 (Quantum Risk Mitigation)]] and [[The Road to Post-Quantum Cryptography (PQC) - A Migration Timeline|the PQC migration timeline]] target of operational readiness by 2028. --- ## 2. Network Architecture ### 2.1 Quantum-Safe Network Topology The QSN testbed architecture layers quantum security across the [[Security x Comms Protocols x Impact of QKD and PQC|OSI stack]]: - **Physical Layer (L1):** Dark fiber links for QKD channels. Dedicated fiber pairs separate quantum signals from classical data to prevent crosstalk. This is where [[QKD Protocol Quantumness|QKD's quantum properties]] — non-orthogonal states, wavefunction collapse — operate directly on the optical medium. - **Network/Transport Layers (L3/L4):** [[TLS|TLS 1.3]] upgraded with PQC key encapsulation (ML-KEM / Kyber) and PQC signatures (ML-DSA / Dilithium), aligned with [[NIST PQC Standards]]. IPSec tunnels hardened with hybrid key exchange. - **Application Layer (L7):** Key management APIs exposing quantum-derived keys to applications. Integration points for [[SOAR - security orchestration automation and response|SOAR]] and security analytics platforms. ### 2.2 Key Infrastructure Components | Component | Role | Vault Link | |---|---|---| | QKD Transmitter/Receiver Nodes | Generate and distribute quantum keys over fiber | [[QKD Protocol Quantumness]] | | PQC-Enabled HSMs | Secure key storage, PQC algorithm execution | [[HSM x PQC]], [[HSM First Principles]] | | QRNG Modules | Physics-grade entropy for key generation | [[Quantum Randomness - Strengthening Cybersecurity with Unpredictability]], [[Quantum Random Number Generator MOC]] | | Key Management System (KMS) | Orchestrate key lifecycle across classical + quantum domains | [[Crypto-agility]] | | Crypto-Agility Controller | Monitor, classify, and trigger algorithm migration | [[Why Cryptographic Inventory Matters]] | | Network Encryptors | Line-rate encryption at L2/L3 with PQC support | [[Encryption]], [[Symmetric Cryptography]] | --- ## 3. QKD Infrastructure Requirements ### 3.1 Fiber Requirements QKD demands dedicated dark fiber with stringent specifications: - Single-mode fiber (SMF-28e+ or equivalent) with insertion loss below 0.2 dB/km at 1550 nm - Maximum span of ~80-100 km between trusted nodes without quantum repeaters - Dedicated fiber pairs — quantum channel cannot share wavelengths with classical amplified traffic - Splice loss budget and [[Insertion Loss]] monitoring at every junction For the Navon testbed, this implies co-locating QKD nodes at [[Modular Data Center Design Principles|modular DC]] sites connected by owned or leased [[Dark Fiber]] infrastructure. [[Optical Fibers|Fiber type selection]] directly impacts achievable key rates and maximum distance. ### 3.2 QKD Protocol Selection The testbed should validate multiple QKD protocols to maintain [[Crypto-agility]]: - **BB84 variants** — the workhorse, well-understood security proofs - **Coherent One-Way (COW)** — practical for long-distance fiber, referenced in [[QKD Protocol Quantumness]] - **Measurement-Device-Independent (MDI) QKD** — removes detector side-channel attacks - **Twin-Field QKD** — extends range beyond standard QKD limits Protocol performance metrics: key generation rate (bits/s), quantum bit error rate (QBER), and secure key rate under realistic channel conditions. ### 3.3 Trusted Node Architecture For distances exceeding single-span QKD limits, the testbed deploys trusted relay nodes — physically secured intermediate points where keys are decrypted, re-encrypted, and forwarded. Each trusted node requires: - Physical tamper protection (aligned with [[HSM First Principles|HSM tamper-resistance principles]]) - [[Confidential Computing]] enclaves for key relay operations - Independent [[Quantum Randomness - Strengthening Cybersecurity with Unpredictability|QRNG]] entropy source --- ## 4. PQC Integration Layer ### 4.1 Algorithm Suite Following [[NIST PQC Standards]] and [[The End of One-Size-Fits-All Cryptography - Adapting to Diverging Standards|diverging international standards]]: | Function | Primary Algorithm | Backup / Alternative | Standard | |---|---|---|---| | Key Encapsulation | ML-KEM (Kyber-768) | BIKE, HQC | NIST FIPS 203 | | Digital Signatures | ML-DSA (Dilithium-3) | FALCON-512 | NIST FIPS 204 | | Hash-Based Signatures | SLH-DSA (SPHINCS+) | XMSS, LMS | NIST FIPS 205 | The testbed must validate these in [[hybrid cryptography|hybrid mode]] — pairing each PQC algorithm with its classical counterpart (e.g., ML-KEM + ECDH, ML-DSA + ECDSA) as specified in [[Hybrid Cryptography as the bridge to Post Quantum Security]]. ### 4.2 HSM Hardening for PQC Per [[HSM x PQC]], current HSMs lack native PQC support. The testbed validates: - Custom cryptographic module loading into FIPS 140-3 Level 3+ HSMs - PQC key generation, storage, and signing operations within the secure boundary - Performance benchmarking: PQC operations are computationally heavier — latency and throughput must be characterized for [[Payment Protocols x PQC x QKD Impact x Cryptoagility|payment protocol]] and [[Digital Certificates - SSL,TLS,HTTPS|TLS handshake]] use cases - [[Arm Cortex M Series]] embedded device compatibility for constrained environments --- ## 5. QRNG & Entropy Management [[Quantum Randomness - Strengthening Cybersecurity with Unpredictability|QRNG]] provides Level 4 entropy — randomness derived from quantum physical processes, not algorithmic [[Pseudorandom number generators|PRNGs]]. The testbed integrates QRNG at three points: 1. **HSM seeding** — quantum entropy feeds directly into HSM key generation 2. **QKD protocol support** — basis selection and nonce generation 3. **Application-layer API** — entropy-as-a-service for client applications requiring [[RNG source classification|certified randomness]] Entropy health monitoring must be continuous, with automatic failover if QRNG output deviates from expected statistical profiles. This connects to [[Information - Quantum vs Classical|the fundamental distinction]] between quantum and classical information: quantum randomness is provably unpredictable, not merely computationally hard to predict. --- ## 6. Key Management & Crypto-Agility Engine The testbed's key management system must demonstrate: - **Unified key lifecycle** across QKD-derived keys, PQC-generated keys, and classical keys - **Automated key rotation** triggered by policy (time-based, usage-based) and threat intelligence - **Cryptographic inventory** — continuous discovery and classification of all cryptographic assets, per [[The Pillars of Cryptographic Discovery and Inventory - A Blueprint for Post-Quantum Security|the five pillars of cryptographic discovery]]: external encryption, internal encryption, cryptographic assets, databases, code - **Algorithm migration orchestration** — the ability to re-encrypt data stores and rotate session keys to new algorithms without downtime, validating [[Content Needed to Describe an Organizations Uses of Cryptography|organizational crypto documentation]] This engine is the operational core of [[Crypto-agility]] and the primary differentiator for [[Navon Security Offering|Navon's security proposition]]. --- ## 7. Compliance & Standards Validation The testbed must generate compliance artifacts for multiple jurisdictions, reflecting [[Navon Sovereign Vaults|Sovereign Vault]] standards-awareness: | Standard | Scope | Testbed Validation | |---|---|---| | NIST SP 800-208 | PQC algorithm recommendations | Algorithm suite conformance | | FIPS 140-3 Level 3+ | Cryptographic module security | HSM boundary and tamper testing | | ETSI QKD ISG | QKD implementation standards | Protocol conformance, key rate certification | | Common Criteria EAL4+ | Security assurance | Evaluation of crypto-agility controller | | ISO/IEC 27001 | Information security management | Testbed operational procedures | | [[IEC 61508]] | Functional safety (for critical infrastructure variants) | Safety integrity validation | Jurisdictional mapping: [[NIST PQC Standards|NIST PQC (U.S.)]], ETSI Quantum-Safe (EU), BSI TR-02102 (Germany), OSCCA (China), STQC (India). --- ## 8. Testbed Deployment Phases Aligned with [[Quantum Readiness Program]] staging: ### Phase A: Foundation (Months 1-3) - Deploy fiber infrastructure and QKD nodes between two testbed sites - Install PQC-enabled HSMs and QRNG modules - Establish baseline classical encrypted links for comparison ### Phase B: Integration (Months 4-6) - Activate QKD key exchange over dedicated fiber - Enable hybrid PQC/classical encryption on all network layers - Deploy crypto-agility controller with automated inventory scanning - Initial [[PQC Roadmap Questions to ask Vendors|vendor integration testing]] ### Phase C: Validation (Months 7-9) - Stress testing: key rates under load, failover scenarios, algorithm hot-swap - [[Misconceptions about Post Quantum Cryptography|Demystification workshops]] for client stakeholders - Compliance audit preparation and documentation - Generate [[Executive Summary of Quantum-Safe Preparation|executive-ready]] reporting ### Phase D: Sovereign Pilot (Months 10-12) - Connect testbed to [[Navon Sovereign Vaults|Sovereign Vault]] prototype - Run sovereign use cases: citizen registry encryption, [[Building Cryptographic Agility in the Financial Sector|financial sector]] key management, [[Payment Protocols x PQC x QKD Impact x Cryptoagility|payment protocol]] PQC upgrade - Client demonstrations and [[Questions to assess the PQC posture of a 3rd party|PQC posture assessments]] --- ## 9. Use Case Mapping Testbed scenarios mapped to [[Navon Security Offering]] client segments: **Criticality-driven (Governments, Defense)** - QKD-secured command links between sovereign vault nodes - PQC-encrypted citizen identity databases with 30+ year data lifecycle - Air-gapped Offline Quantum Pod validation **Compliance-driven (Financial Services, Healthcare)** - [[Building Cryptographic Agility in the Financial Sector|Crypto-as-a-service]] for automated PQC algorithm updates - [[Payment Protocols x PQC x QKD Impact x Cryptoagility|TLS, SWIFT, IPSec]] PQC upgrade path validation - Healthcare record encryption with multi-decade retention **Sovereignty-driven (Emerging Markets, GCC)** - [[Kenya Telco Market x Navon Role|Edge security]] for fiber backbone infrastructure - [[Navon Data Embassies|Data embassy]] quantum protection validation - Multilateral governance key management for shared digital infrastructure --- ## 10. Risk Register | Risk | Impact | Mitigation | |---|---|---| | QKD distance limitations | Restricts deployment geography | Trusted node architecture; monitor quantum repeater R&D | | PQC algorithm vulnerability discovered | Undermines protection claims | [[Hybrid Cryptography as the bridge to Post Quantum Security\|Hybrid mode]] ensures classical fallback; [[Crypto-agility]] enables rapid swap | | HSM firmware incompatibility with PQC modules | Blocks key management | Multi-vendor HSM testing; [[HSM Providers\|provider diversification]] | | Fiber availability in target deployment regions | Delays testbed activation | [[Dark Fiber]] leasing strategy; satellite QKD as future alternative | | Standards divergence across jurisdictions | Complicates compliance | [[The End of One-Size-Fits-All Cryptography - Adapting to Diverging Standards\|Standards-aware design]]; modular compliance engine | --- ## Related Notes - [[Navon Security Offering]] — full security thesis and commercial positioning - [[Quantum Security Thesis]] — market dynamics and acquisition logic - [[Quantum Security MOC]] — quantum threat landscape and readiness best practices - [[Navon Sovereign Vaults]] — deployment models (National Vaults, Data Embassies, Offline Quantum Pods) - [[Cryptography MOC]] — foundational cryptographic concepts - [[Data Center MoC]] — physical infrastructure layer - [[Sovereign AI Positioning]] — sovereign market positioning strategy - [[The Quantum Threat - Why your organisation needs to act now]] - [[Recommended quantum readiness best practices]] --- Tags: #deeptech #security #quantum #navon #testbed #kp