Quantum Security Controller (QuSeC)

• Quantum Security Controller (QuSeC) is a programmable module that enforces and orchestrates quantum-safe security protocols across networked systems.
• It integrates hardware-embedded and software-defined controllers to mediate between quantum and classical resources while enforcing cryptographic policies.
• QuSeC supports adaptive key management, secure communication protocols, and dynamic security assignments to build scalable, robust quantum-safe infrastructures.

A Quantum Security Controller (QuSeC) is a programmable, logically centralized or hardware-embedded module that orchestrates, enforces, or cryptographically supports quantum-safe or quantum-enhanced security operations for networked systems, cloud quantum computing, secure direct communication, or control architectures. QuSeC designs span hardware enclaves enforcing quantum isolation, software-defined controllers for QKD networks, adaptive key management for heterogeneous networks, quantum-resistant mobile agent C&C, and controllers for controlled quantum secure direct communication protocols. Although the exact function and implementation varies by domain, the QuSeC pattern unifies programmable policy enforcement, cryptographic service orchestration, and security-critical decision-making interfaces between quantum and classical resources.

1. Core Architectural Patterns and Logical Placement

QuSeCs are instantiated as either hardware-embedded modules (e.g., quantum trusted execution environments), software-defined centralized controllers (e.g., in SDN-enabled quantum networks), or distributed protocol entities (e.g., as measured ancilla holders in CQSDC). The architectural role always involves a demarcation between trusted and untrusted components, mediation of quantum and classical flows, and the enforcement, derivation, or control of keys or state update privileges.

Logical Layers and Examples

Layer/Plane	QuSeC Role Example	Reference
Physical/Hardware	Quantum TEE, QC-TEE	(Ma et al., 2021, Trochatos et al., 2023)
Control/Management Plane	SDN QuSeC, Key Path Selection	(Sanz et al., 11 Sep 2025, Tessinari et al., 2023)
Security Management	Adaptive Security Level Assignment	(Sanz et al., 27 Nov 2025)
Protocol Entity	Quantum Direct Communication Controller	(Patwardhan et al., 2015)

QuSeC typically presents standardized APIs northbound to higher applications (REST, ETSI GS QKD 014/015), and programmable or hardware-enforced southbound interfaces to KMSs, quantum hardware, or secure protocol submodules.

2. QuSeC Instantiations: Hardware-Enforced Quantum Isolation

Notable hardware QuSeC implementations include the QEnclave (Ma et al., 2021) and the QC-TEE security manager (Trochatos et al., 2023). These constructions enforce privacy, tamper-resistance, and side-channel resilience by encapsulating essential quantum operations within physically shielded modules.

• QEnclave attaches to a quantum server, accepting single-qubit “wires,” applying client-specified $Z(\theta)$ rotations (with $\theta$ encrypted/authenticated via a post-quantum secure channel established through attestation), and outputting rotated states—all within a hardware enclave, implementing the Remote State Rotation (RSR) resource. The classical TEE oversees state, decryption, and attestation, while the quantum module is physically isolated in a FIPS-140 style package. No quantum information ever leaves the shielded volume except the rotated qubits; all classical controls are encrypted (Ma et al., 2021).
• QC-TEE Security Manager enforces obfuscation of quantum circuits by (1) requiring users to embed decoy microwave pulses within their gate sequences and (2) selectively attenuating those decoy pulses via RF switches under bitwise classical control inside the dilution refrigerator. The input bitmap (real vs. decoy) is encrypted using post-quantum KEM and only decrypted inside the cryogenic QuSeC. Tamper-detection erases secrets upon breach. The protection is quantified using total variational distance $\delta(P, P')$, demonstrated to be in the 0.16–0.26 range, meaning circuit structure leakage is strongly limited (Trochatos et al., 2023).

3. Orchestration of Quantum Networks and Key Management

In multi-node QKD architectures and hybrid quantum-safe networks, QuSeC is realized as a logically centralized, software-defined controller with global topology knowledge and programmable policy enforcement.

• In SDN-inspired QKD architectures, QuSeC oversees three main logical modules (Sanz et al., 11 Sep 2025):
  • Topology Database: collects real-time link status, key rates, quantum bit error rates (QBER), and trust levels via ETSI GS QKD 015 APIs.
  • Path Computation Engine (PCE): computes multi-hop relay/key-distribution paths using optimization criteria combining link metrics, trust, and policy constraints (Dijkstra variant; complexity $O(|E| + |V| \log |V|)$).
  • Policy Manager: interprets administrative policies (max hops, trust, vendor list) to approve or reject computed paths, then programs per-node instructions (relay_path_install) to local KMS agents.

End-to-end key relay leverages vKMS/KMS abstractions, northbound/southbound message exchanges, and policy-driven path installation. Throughout, QuSeC never handles actual key material; only control-plane metadata flows through it (Sanz et al., 11 Sep 2025).

4. Adaptive Security Levels in Heterogeneous Networks

Modern QuSeC implementations support dynamic assignment of quantum-safe security levels based on real-time network state and node capabilities (Sanz et al., 27 Nov 2025). The Security-Level Assignment Function (SLAF) operates as:

$$SL(\text{src},\text{dst}) = \begin{cases} 1 & \text{if } \text{src},\text{dst} \in QN \land \operatorname{directQKD}(\text{src},\text{dst}) \ 2 & \text{if } \text{src},\text{dst} \in QN \land \exists \text{ trusted relay path} \ 3 & \text{if } \{\text{src},\text{dst}\} \cap QN \ne \emptyset \land \exists \text{trusted relay to QN} \ 4 & \text{otherwise} \end{cases}$$

QuSeC mediates between application-layer key requests and per-node vKMS instances:

1. Application requests session key.
2. vKMS queries QuSeC for optimal security level.
3. QuSeC computes (using global state) and returns security level and required relay/configuration path.
4. Key derivation employs QKD, PQC-KEMs, or hybrid HKDF-combined keys per assigned security level.

Validation on Kubernetes testbed with SimulaQron plus PQC-KEM (CRYSTALS-Kyber) demonstrates median key establishment latencies: 73 ms (direct QKD), 170 ms (multi-hop QKD), 155 ms (hybrid), and 92 ms (pure PQC) (Sanz et al., 27 Nov 2025).

5. Integration with Software-Defined Networks and Control-Plane Security

QuSeC architectures for QKD-enabled SDN integrate SDN controllers, QKD key managers, and secure channel provisioning (Tessinari et al., 2023). The QKD SDN Controller (housed within the node) interacts with the KMS using REST over mutual TLS, with application entities requesting QKD-derived key blocks for encryption. Control-plane messages (NETCONF, RESTCONF) can be fully or partially (field-selected) OTP/AES encrypted using session QKD keys, significantly reducing quantum key consumption under constrained key rates.

Automated failover and link reconfiguration leverages QuSeC’s global network view. Partial field encryption enables continued secure operations under degraded QKD secret bit rates. Authentication and channel confidentiality is maintained via X.509 plus QKD-encrypted payloads.

6. Quantum-Safe C&C for Mobile Agents

A QuSeC can be instantiated as a cryptographic control core integrating application-layer post-quantum signatures (e.g., qTESLA), network-layer PQC IPSec (NTRU+BLISS), and key management for secure command and control of mobile agents (Varma et al., 2020). Platform integration with ROS introduces:

• Post-quantum handshake (IKEv2+NTRU/BLISS)
• Layered signing prior to pub-sub
• Periodic key/cert rotation and revocation Empirically, qTESLA incurs $\sim$1 ms signature costs for 1 kB messages, NTRU-192 + BLISS + AES256 achieves secure tunnels at 430 Mbps throughput with $\sim$14% CPU utilization.

7. CQSDC and Quantum-Enabled Access Control

In controlled quantum secure direct communication (CQSDC), the QuSeC is reified as one or more “controller” parties that possess exclusive quantum information to enforce access. For instance:

• In cluster-state CQSDC, the QuSeC holds a qubit, performing an essential Z-basis measurement; without their classical bit, the recipient cannot learn the full message.
• In threshold CQSDC with Brown states, a coalition of QuSeCs (controllers) is required for message retrieval, formally enforcing a $(k,n)$ access structure (Patwardhan et al., 2015).

The security of CQSDC QuSeC protocols is information-theoretic, with strict bounds on adversarial information leakage without controller(s)' cooperation. Efficiency (bits sent/qubits used) is superior or comparable to prior art.

8. Security, Composability, Standards, and Extensibility

QuSeCs are typically engineered for composable security in the universal composability (UC) or Abstract Cryptography frameworks (Ma et al., 2021). All QuSeC-mediated exchanges are enforced over authenticated, integrity-protected control channels—mutual TLS, post-quantum KEMs, or hardware means.

Standardization is central:

• ETSI GS QKD 014 (RESTful KMS and key delivery interfaces)
• ETSI GS QKD 015 (control plane APIs for QKD devices and SDN)
• ETSI GS QKD 020 (inter-KMS relay APIs)

By strictly decoupling control from data—in alignment with SDN/NFV design—QuSeC frameworks enable heterogeneous, multi-vendor interoperability and systematic scaling. Key material never traverses QuSeC: only control-plane guidance, configuration state, and relay topology instructions are managed.

The QuSeC pattern also generalizes naturally: any protocol requiring limited quantum operations (stabilizer checks, state rotations) or programmable enforcement over quantum resources can be modularized with a QuSeC.

9. Performance, Scaling, and Open Directions

Path computation and security level assignment in QuSeC are computationally efficient ($O(|E|+|V|\log|V|)$ for typical Dijkstra formulations), with control-plane-induced latencies accounting for only 10–70 ms in medium-scale topologies (Sanz et al., 11 Sep 2025, Sanz et al., 27 Nov 2025). Hardware QuSeC modules add negligible delay and physical overhead (<0.002% volume, <200 mW cryo-power even at scale).

Remaining challenges include:

• Caching and policy state synchronization across distributed QuSeCs
• Dynamic trust/revocation management in path computation
• Federated/quorum QuSeC frameworks for cross-domain QKD
• Integration of true quantum repeaters and entanglement routing
• Formal verification of policy engines and protocol correctness

10. Summary

Quantum Security Controllers (QuSeC) encompass a rapidly evolving set of hardware and software architectures unifying quantum/classical control, programmable cryptographic enforcement, and adaptive policy management for quantum-safe systems. Whether enforcing blind DQC with optimal resource efficiency, orchestrating scalable multi-hop QKD networks, securing cloud quantum computing, or realizing efficient controlled direct communication, QuSeCs serve as the critical programmable trust boundary—decoupling and abstracting security enforcement from underlying quantum and classical hardware (Ma et al., 2021, Sanz et al., 11 Sep 2025, Sanz et al., 27 Nov 2025, Trochatos et al., 2023, Tessinari et al., 2023, Varma et al., 2020, Patwardhan et al., 2015).