Key Management

Sovereign key lifecycle management governs all cryptographic material within the QECNet mesh. Keys are generated, distributed, rotated, and destroyed according to strict operational protocols enforced by the platform.

CONTENTS

--Key Lifecycle --QKD Distribution Mesh --Rotation Protocols --Compromise Recovery --Key Type Reference --Lifecycle Flow Diagram

Key Lifecycle

Every cryptographic key in QECNet follows a deterministic lifecycle managed by the sovereign hub. Keys transition through defined states with each transition logged to the immutable audit chain.

KEY STATE TRANSITIONS

GENERATED ──> DISTRIBUTED ──> ACTIVE ──> ROTATING ──> RETIRED
     │              │            │           │
     │              │            │           └──> ACTIVE (new key)
     │              │            │
     │              │            └──[compromise]──> REVOKED
     │              │
     │              └──[distribution_failure]──> DESTROYED
     │
     └──[generation_failure]──> (no record created)

All transitions are atomic. Partial state is not permitted.
Failed distributions trigger automatic retry with new key material.

GENERATED

Key material created from local entropy source. Hardware RNG where available. Minimum entropy requirement: 256 bits.

DISTRIBUTED

Key securely transmitted to designated nodes via QKD channel. Receipt confirmation required from all participants before activation.

ACTIVE

Key in operational use for encryption/decryption. Subject to continuous integrity monitoring. Usage counters tracked.

ROTATING

Replacement key being distributed. Old key remains active until all nodes confirm receipt of new material. Overlap period configurable.

RETIRED

Key removed from operational use. Retained in secure archive for audit/recovery purposes. Automatic destruction after retention period.

REVOKED

Key invalidated due to suspected compromise. All nodes instructed to purge material immediately. Emergency rotation triggered.

QKD Distribution Mesh

The quantum key distribution mesh forms the cryptographic backbone of QECNet. Each node in the mesh maintains direct or relayed quantum channels to the sovereign hub and to designated peer nodes.

The mesh topology is dynamically reconfigured in response to node status changes. When a node is isolated, its mesh connections are severed and neighboring nodes re-establish direct channels to maintain coverage.

MESH PARAMETERS

Topology

Full mesh with sovereign hub

Key refresh interval

300s (configurable)

Channel verification

Continuous QBER monitoring

Minimum key rate

1 kbps per channel

Error threshold

QBER < 11% (BB84 limit)

Fallback protocol

ML-KEM-1024 hybrid exchange

Rotation Protocols

Key rotation occurs under three conditions: scheduled rotation (time-based), triggered rotation (event-based), and emergency rotation (compromise-based). Each protocol follows distinct procedures with different latency and coordination requirements.

SCHEDULED ROTATION

TRIGGERTimer expiry (configurable: 1h — 24h)

PROCEDURENew key generated → distributed via QKD → nodes confirm receipt → old key retired → audit record created

LATENCY< 5s total mesh convergence

IMPACTZero downtime. Overlap period ensures continuous protection.

TRIGGERED ROTATION

TRIGGERAnomaly detection, policy change, or operator command

PROCEDURERotation initiated by decision engine → accelerated distribution → old key marked for early retirement

LATENCY< 2s total mesh convergence

IMPACTMinimal disruption. In-flight sessions re-keyed transparently.

EMERGENCY ROTATION

TRIGGERConfirmed or suspected key compromise

PROCEDUREAll instances of compromised key immediately revoked → emergency distribution from pre-staged material → full mesh re-key

LATENCY< 500ms revocation, < 3s re-key

IMPACTBrief service interruption possible during re-key. Affected sessions terminated.

Compromise Recovery

When key compromise is detected, the system initiates an automated recovery sequence. Recovery is designed to restore full cryptographic integrity within seconds while maintaining operational continuity for unaffected segments.

COMPROMISE RECOVERY SEQUENCE

01DETECTCompromise signal validated by decision engine. False positive rate < 0.01% at this stage.

02ISOLATEAffected node removed from mesh. All channels to/from node severed. Key material on node marked compromised.

03REVOKEAll key instances shared with compromised node purged from mesh. Neighboring nodes notified.

04RE-KEYEmergency key distribution initiated from pre-staged material. Mesh rebuilds without compromised node.

05VERIFYPost-recovery integrity check. All nodes confirm new key material. Mesh topology validated.

06REPORTIncident record created in audit chain. Compromised key material archived for forensic analysis.

Key Type Reference

TYPE

ALGORITHM

SIZE

ROTATION

SOVEREIGN_MASTER

AES-256-GCM

256-bit

24h

MESH_SESSION

ChaCha20-Poly1305

256-bit

5min

QKD_TRANSPORT

OTP (QKD-derived)

Variable

Continuous

NODE_IDENTITY

Ed25519 + ML-DSA-65

Hybrid

90d

AUDIT_SIGNING

Ed25519

256-bit

365d

EPHEMERAL_SESSION

X25519 + ML-KEM-768

Hybrid

Per-session

Lifecycle Flow Diagram

KEY LIFECYCLE FLOWGeneration → distribution → activation → rotation → retirement flow

ROTATION TIMING DIAGRAMScheduled, triggered, and emergency rotation timing reference