Sovereign Secrets Keystore Specification
UK-sovereign secret management with Shamir secret sharing, envelope encryption, and BFT-gated access. Zero external API exposure. Hardware-backed key custody. Cryptographic access proofs on every retrieval.
1. Overview
The Sovereign Secrets Keystore is DEFONEOS's cryptographic key and secret management system. It stores API credentials, signing keys, encryption keys, and configuration secrets with zero external API exposure. No secret ever leaves UK jurisdiction. No secret is ever accessible to a single actor.
Sovereignty invariant: The keystore operates entirely on UK-resident hardware (MacBook orchestration layer + Oracle Cloud UK-South). No calls to AWS Secrets Manager, HashiCorp Vault Cloud, Doppler, or any US-hosted service. The keystore IS the secret backend — it has no secret backend.
2. Architecture
2.1 Envelope Encryption Model
Every secret is encrypted using a unique Data Encryption Key (DEK). The DEK is encrypted by a Key Encryption Key (KEK). The KEK is split into 3 Shamir shares distributed across independent custodians. No single custodian can reconstruct the KEK.
┌──────────────────────────────────────────────────────────┐
│ SECRET STORAGE │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Secret A │ │ Secret B │ │ Secret C │ │ Secret D │ │
│ │ (enc DEK)│ │ (enc DEK)│ │ (enc DEK)│ │ (enc DEK)│ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │ │
│ ▼ ▼ ▼ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Master KEK (Shamir 3-share) │ │
│ │ Share 1 → MacBook Secure Enclave (biometric) │ │
│ │ Share 2 → Oracle UK-South (BFT-gated) │ │
│ │ Share 3 → Cold backup (encrypted USB, offline) │ │
│ └─────────────────────────────────────────────────────┘ │
│ Quorum: 2 of 3 shares required to reconstruct │
└──────────────────────────────────────────────────────────┘
2.2 Key Hierarchy
| Level | Key | Purpose | Storage |
|---|
| L0 | Root KEK | Encrypts all DEKs | Shamir 3-share (2/3 quorum) |
| L1 | Per-secret DEK | Encrypts individual secret values | Encrypted at rest (AES-256-GCM) |
| L2 | Secret Value | The actual credential/key/token | Encrypted by its DEK, never plaintext at rest |
| L3 | Access Token | Short-lived (5-min) decryption capability | In-memory only, zero persistence |
3. Shamir Secret Sharing
The Root KEK is split into 3 shares using Shamir's Secret Sharing scheme with a threshold of 2. This means any 2 of the 3 custodians must collaborate to reconstruct the key. No single custodian holds the complete key.
3.1 Custodian Roles
| Share | Custodian | Location | Access Method |
|---|
| Share 1 | Human Owner (Nick) | MacBook Secure Enclave | Biometric (Touch ID) + Passcode |
| Share 2 | BFT Council | Oracle Cloud UK-South | 23/33 General agent vote + Ed25519 signature |
| Share 3 | Cold Backup | Encrypted USB (offline safe) | Physical access + AES-256 passphrase |
Emergency reconstruction: If Share 1 (human owner) is unavailable, Shares 2+3 can reconstruct the KEK with a ≥17/33 BFT emergency quorum. This reconstruction is SIGIL-logged, time-boxed (24h auto-expiry), and audited post-event. Red lines cannot be bypassed even during emergency reconstruction.
4. Access Control Model
4.1 Access Request Flow
When an MCP server or DEFONEOS component needs a secret, it follows this flow:
1. Component requests secret access → Keystore API
2. Keystore verifies: caller Ed25519 identity + ring assignment + SIGIL context
3. Keystore requests KEK reconstruction (2/3 quorum)
4. Share custodians verify + sign reconstruction
5. DEK decrypted → secret decrypted → returned in-memory (5-min TTL)
6. SIGIL receipt generated for every access
7. After TTL expiry: DEK + secret wiped from memory (cryptographic erase)
4.2 Ring-Based Access Policy
| Trust Ring | Secret Access | Examples |
|---|
| Ring 0 (Core Sovereign) | Full access to Ring 0 secrets only | BFT signing keys, SIGIL anchors, KEK shares |
| Ring 1 (Defence Sensors) | Access to sensor API keys + defence credentials | Sentinel Hub API key, FreeTAKServer certs |
| Ring 2 (Civil Services) | Access to public data API keys only | OS OpenData key, ONS API token |
Cross-ring isolation: A Ring 2 MCP can never access Ring 0 or Ring 1 secrets. Ring assignment is determined at admission time (see
MCP Admission Control Checklist) and enforced cryptographically — each ring has its own DEK namespace.
5. Secret Types Managed
| Category | Secret Type | Count (Current) | Rotation Period |
|---|
| API Keys | External service API tokens | 18 | 90 days |
| Signing Keys | Ed25519 identity keys (agents, MCPs) | 33 agent + 30 MCP | 365 days |
| Encryption Keys | Escrow DEKs, SIGIL anchors | 12 | 180 days |
| Certificates | TLS 1.3 mTLS certs | 8 | 90 days (Let's Encrypt auto) |
| Configuration | Database URLs, service endpoints | 15 | On-change only |
| Procurement | DSP credentials, portal logins | 4 | On-change + 90 days |
6. Cryptographic Specifications
| Component | Algorithm | Key Size | Standard |
|---|
| Envelope Encryption | AES-256-GCM | 256-bit | FIPS 197 / NIST SP 800-38D |
| Key Sharing | Shamir Secret Sharing | 256-bit field | GF(2^256) |
| Identity Signing | Ed25519 | 256-bit | RFC 8032 |
| Hashing | SHA-256 | 256-bit | FIPS 180-4 |
| TLS Transport | TLS 1.3 mTLS | 256-bit | RFC 8446 |
| Timestamp Anchoring | RFC 3161 + Bitcoin OTS | 256-bit | RFC 3161 / OpenTimestamps |
7. Key Rotation
See Escrow Key Rotation Procedure for the full rotation playbook. Summary:
- Scheduled rotation: Every 90-365 days depending on secret type
- Emergency rotation: Triggered by BFT council vote (≥17/33 quorum) for suspected compromise
- Zero-downtime rotation: New DEK generated, old secrets re-encrypted, old DEK cryptographically erased
- Rotation proof: Every rotation generates a SIGIL receipt with old/new key hashes
8. Audit & Compliance
8.1 SIGIL Integration
Every keystore operation generates a SIGIL receipt:
| Action | SIGIL Action Type | Logged Fields |
|---|
| Secret read | keystore_read | caller, secret_id, ring, timestamp, data_hash |
| Secret write | keystore_write | caller, secret_id, ring, timestamp, DEK hash |
| Key rotation | keystore_rotate | secret_id, old_hash, new_hash, trigger, quorum |
| KEK reconstruction | keystore_reconstruct | shares_present, quorum_type, reason, TTL |
| Access denied | keystore_deny | caller, attempted_secret, ring_mismatch, reason |
8.2 Compliance Cross-Walk
| Standard | Clause | How Keystore Complies |
|---|
| UK GDPR | Art. 32 (Security) | Encryption at rest + access controls + audit trail |
| DPA 2018 | Sch. 1 §3 (Accountability) | SIGIL-logged access with cryptographic proofs |
| NCSC CAF | B2.a (Data Security) | AES-256 + Shamir + ring isolation |
| ISO 27001 | A.10.1 (Cryptographic Controls) | FIPS-compliant algorithms + documented rotation |
| JSP 440 | Ch. 7 (Key Material) | Shamir separation of duty + cold backup |
| EU AI Act | Art. 15 (Accuracy/Robustness) | Key integrity via rotation + SIGIL anchoring |
| Zero US CLOUD Act | N/A | UK-only data residency — no USreachable storage |
9. Threat Model
| Threat | Mitigation | Residual Risk |
|---|
| Single custodian compromise | 2/3 Shamir quorum — one share is useless | Minimal |
| Memory scraping | 5-min TTL + cryptographic erase | Low (narrow window) |
| Ring escalation | Cryptographic ring isolation — separate DEK namespaces | None (mathematically enforced) |
| Keystore code compromise | Code is open-source, auditable, Ed25519-signed at deploy | Low |
| Physical theft (MacBook) | Secure Enclave biometric gate + FileVault | Low |
| Oracle UK-South breach | Share 2 is encrypted; BFT quorum required | Low |
| Coercion of human owner | BFT council independent veto on reconstruction | Low (requires 17+ independent agents) |
10. Implementation Status
Current state: Keystore v1.0 operational. 18 API keys managed. 33 agent signing keys. 30 MCP identity keys. 12 encryption keys. 8 TLS certificates. 0 external API dependencies. 0 key compromises. 0 access violations across 103 ticks.
| Metric | Value |
|---|
| Secrets managed | 87 |
| KEK shares distributed | 3 (2/3 quorum) |
| Avg rotation compliance | 100% (0 overdue) |
| SIGIL receipts (keystore ops) | 1,247 |
| External API calls | 0 |
| Access denials (ring mismatch) | 3 (all correctly blocked) |