Escrow Key Rotation Procedure
The zero-downtime playbook for rotating encryption keys, DEKs, and KEKs across the DEFONEOS sovereign escrow. Scheduled and emergency rotation. BFT-gated. SIGIL-attested. Cryptographic destruction of retired keys.
1. Purpose & Scope
This document defines the procedure for rotating cryptographic keys in the DEFONEOS Sovereign Escrow system. It covers scheduled rotation (routine key lifecycle management) and emergency rotation (incident response to suspected compromise). The procedure ensures zero downtime, full SIGIL audit trail, and cryptographic destruction of retired keys.
Scope: This procedure covers DEKs (Data Encryption Keys), KEKs (Key Encryption Keys), Ed25519 identity keys, and TLS certificates. It does NOT cover BFT council voting keys — those follow the
BFT Emergency Session Protocol.
2. Key Lifecycle
| State | Description | Transition Trigger |
|---|
| GENERATED | New key created, not yet in use | Creation by keystore or rotation procedure |
| ACTIVE | Key is encrypting/decrypting data | Activation after verification |
| DEPRECATED | Key still decrypts (for old data) but no new encryption | Rotation completion |
| RETIRED | Key no longer used for any operation | All data re-encrypted with new key |
| DESTROYED | Key cryptographically erased, proven non-recoverable | Destruction procedure complete |
3. Scheduled Rotation
3.1 Rotation Schedule
| Key Type | Rotation Period | Lead Time | Quorum Required |
|---|
| API Keys (external) | 90 days | 7 days | Automated (no BFT vote) |
| Per-secret DEKs | 180 days | 14 days | Automated (no BFT vote) |
| TLS Certificates | 90 days (Let's Encrypt) | 30 days (auto-renew) | Automated (ACME) |
| Ed25519 Identity Keys (agents) | 365 days | 30 days | BFT 17/33 quorum |
| Ed25519 Identity Keys (MCPs) | 365 days | 30 days | BFT 17/33 quorum |
| Escrow Encryption Keys | 180 days | 14 days | BFT 23/33 quorum |
| Root KEK | 730 days (2 years) | 60 days | BFT 23/33 + Human Owner |
3.2 Scheduled Rotation Procedure (DEK)
Step 1: Rotation scheduler detects key approaching expiry (lead time threshold)
Step 2: New DEK generated (AES-256-GCM, CSPRNG)
Step 3: New DEK encrypted by current KEK → stored at rest
Step 4: VERIFY — new DEK can encrypt + decrypt test vector
Step 5: All secrets encrypted with old DEK re-encrypted with new DEK (batch)
Step 6: Old DEK marked DEPRECATED (still decrypts, no new encryption)
Step 7: VERIFY — all secrets decryptable with new DEK (spot check 10%)
Step 8: SIGIL receipt: keystore_rotate {old_hash, new_hash, trigger: "scheduled"}
Step 9: Wait 7-day observation period (old DEK available for rollback)
Step 10: VERIFY — 7 days zero decrypt errors with new DEK
Step 11: DESTROY — old DEK cryptographically erased (memory zeroed + disk overwrite ×3)
Step 12: DESTROY PROOF — SIGIL receipt: keystore_destroy {key_hash, method: "crypto_erase", verification: "sha256 mismatch confirmed"}
Step 13: Old DEK marked DESTROYED. Rotation complete.
4. Emergency Rotation
Emergency rotation is triggered when a key is suspected compromised. It bypasses the observation period but maintains all SIGIL audit controls.
4.1 Emergency Triggers
| Trigger | Source | Quorum | Response Time |
|---|
| Suspected key compromise | BFT council vote | ≥17/33 (emergency) | 5 minutes |
| Red-line violation detected | Automated scan | None (auto-trigger) | Immediate |
| Supply chain alert (dependency) | Red team scan | None (auto-trigger) | Immediate |
| Physical security event | Human owner | Human override | Immediate |
| Custodian share suspected leaked | BFT or human | ≥17/33 | 5 minutes |
4.2 Emergency Rotation Procedure
Step 1: Emergency trigger received → BFT emergency session convened (T+0)
Step 2: BFT quorum achieved (≥17/33) → Emergency rotation authorised (T+60s)
Step 3: New DEK generated immediately
Step 4: ALL secrets re-encrypted with new DEK (priority batch, no observation period)
Step 5: IMMEDIATE DESTROY — old DEK cryptographically erased (no deprecation period)
Step 6: SIGIL receipt: keystore_rotate {trigger: "emergency", quorum: "17/33", reason: "..."}
Step 7: DESTROY PROOF — old DEK crypto-erased, SIGIL-anchored
Step 8: Post-incident review within 24h (BFT council reviews SIGIL trail)
Step 9: All dependent services notified of key change (Ed25519 re-verification)
Step 10: If KEK rotation needed: 2/3 Shamir reconstruction required (separate procedure)
No rollback in emergency: Emergency rotation destroys old keys immediately. There is no observation period. If the new key is faulty, the system fails-safe (data encrypted but inaccessible until manual recovery). This is deliberate — a suspected compromise with a rolling observation window is more dangerous than temporary data inaccessibility.
5. KEK Rotation (Root Key)
Rotating the Root KEK is the most sensitive operation in the keystore. It requires reconstructing the current KEK (2/3 Shamir quorum), generating a new KEK, re-encrypting all DEKs, and splitting the new KEK into new Shamir shares.
Step 1: BFT vote (23/33 standard quorum) + Human Owner approval
Step 2: Current KEK reconstructed (2/3 Shamir shares assembled)
Step 3: New KEK generated (CSPRNG, 256-bit)
Step 4: All DEKs decrypted with old KEK, re-encrypted with new KEK
Step 5: VERIFY — all DEKs decryptable with new KEK (100% check)
Step 6: New KEK split into 3 new Shamir shares
Step 7: New shares distributed to custodians (Share 1 → Secure Enclave, Share 2 → Oracle UK-South, Share 3 → Cold USB)
Step 8: VERIFY — new shares can reconstruct new KEK (test reconstruction)
Step 9: DESTROY — old KEK shares cryptographically erased at all 3 custodians
Step 10: DESTROY PROOF — SIGIL receipt with old/new KEK hashes + destruction method
Step 11: SIGIL receipt: keystore_rotate {type: "root_kek", quorum: "23/33", human_owner: true}
6. Zero-Downtime Guarantee
Rotation never causes service interruption. The mechanism:
| Phase | Duration | Service Impact | Mechanism |
|---|
| Pre-rotation | ~1 second | None | New key generated in parallel |
| Re-encryption | ~5 seconds (87 keys) | None | Atomic swap: old DEK stays active until new DEK verified |
| Verification | ~2 seconds | None | Spot-check decryption with new key |
| Cutover | <1 second | None | Atomic flag flip: new DEK becomes primary |
| Deprecation | 7 days (scheduled) / 0 (emergency) | None | Old key available for rollback only |
| Destruction | ~1 second | None | Crypto-erase of old key material |
Total rotation window: <10 seconds for 87 keys. Zero service downtime. Zero data loss. Zero accessibility gap.
7. Cryptographic Destruction
When a key is destroyed, it must be provably non-recoverable. DEFONEOS uses a multi-pass destruction method:
| Step | Action | Verification |
|---|
| 1 | Memory zeroing (memset to 0 ×3 passes) | Memory scan confirms all-zero |
| 2 | Disk overwrite (random data ×3 passes) | SHA-256 of disk region → random hash |
| 3 | Key material hash compared (pre vs post) | Hash mismatch confirms destruction |
| 4 | SIGIL receipt: keystore_destroy with proof hashes | Bitcoin OTS anchor for permanent proof |
Physical media: Cold backup USBs containing KEK Share 3 are physically destroyed (drill + incinerate) when rotated, not just overwritten. A physical destruction certificate is SIGIL-logged with witness signatures.
8. SIGIL Audit Trail
Every rotation generates permanent, tamper-evident SIGIL receipts:
| SIGIL Action | When | Key Fields |
|---|
keystore_rotate | Rotation initiated | key_id, old_hash, new_hash, trigger, quorum |
keystore_reencrypt | Each secret re-encrypted | secret_id, old_dek_hash, new_dek_hash |
keystore_verify | Post-rotation verification | keys_verified, spot_check_pct, result |
keystore_destroy | Old key destroyed | key_hash, destruction_method, proof_hash |
keystore_emergency | Emergency rotation (if applicable) | trigger, bft_session_id, response_time |
9. Compliance Cross-Walk
| Standard | Clause | How Rotation Complies |
|---|
| UK GDPR | Art. 32(1)(a) | Pseudonymisation + encryption with regular key rotation |
| DPA 2018 | Sch. 1 §3 | Documented rotation procedure with audit trail |
| NCSC CAF | B2.a.4 | Key management with defined lifecycle + destruction |
| ISO 27001 | A.10.1.2 | Key management policy with rotation + protection |
| JSP 440 | Ch. 7 §4 | Key material rotation with separation of duty |
| EU AI Act | Art. 15(5) | Cybersecurity measures with documented key management |
| NIST SP 800-57 | §8.3.4 | Cryptoperiod management + key destruction |
10. Rotation History & Metrics
All-time record (Ticks 1-103): 142 scheduled rotations completed. 0 emergency rotations triggered. 0 downtime events. 0 data loss events. 100% compliance with rotation schedule. 0 keys overdue.
| Metric | Value |
|---|
| Scheduled rotations completed | 142 |
| Emergency rotations triggered | 0 |
| Keys currently overdue | 0 |
| Avg rotation time (DEK batch) | 7.2 seconds |
| Avg rotation time (KEK) | 14.8 seconds |
| Total keys destroyed | 142 (all with SIGIL destruction proof) |
| Downtime caused by rotation | 0 seconds |
| Data loss caused by rotation | 0 bytes |