Sovereign Data Escrow Protocol

7-layer custody stack · zero US CLOUD Act exposure · UK-only data residency · 6 named release conditions · cryptographic destruction proofs · BFT council veto.

7
Custody Layers
0
US Exposure
6
Release Conditions
23/33
BFT Veto Quorum

1. Purpose

The Sovereign Data Escrow Protocol ensures that all data processed through DEFONEOS remains within UK jurisdiction, is cryptographically protected at every layer, and can only be released through explicitly named conditions with multi-party governance.

Core principle: Data enters UK jurisdiction, is processed in UK jurisdiction, and only leaves UK jurisdiction through a BFT-approved, human-witnessed, cryptographically-proven release. There is no backdoor, no US CLOUD Act exposure, and no fifth-party access.

2. The 7-Layer Custody Stack

L6 — BFT Council Veto: 33-agent BFT governance council can veto any data release. Standard: 23/33 majority. Emergency: 17/33.
L5 — 4-Eyes Release Gate: No single operator can release data. Two authorised humans + BFT witness required.
L4 — Escrow Receipts (RFC3161): Every data access, release, or destruction is timestamped via RFC3161 Trusted Timestamp Authority + Bitcoin OTS anchor.
L3 — Ed25519 Identity: Every actor (human or agent) is identified by an Ed25519 key pair. No anonymous access.
L2 — TLS 1.3 In Transit: All data in transit encrypted with TLS 1.3 with mTLS for internal service mesh.
L1 — AES-256-GCM At Rest: Per-record Data Encryption Key (DEK) wrapped by Shamir-split Key Encryption Key (KEK). No single key compromise exposes data.
L0 — UK Physical Residency: All data physically stored in UK data centres or on UK-sovereign hardware (MLX on Apple Silicon). No foreign cloud.

3. Zero US CLOUD Act Exposure

The US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) allows US law enforcement to compel US-based cloud providers to produce data stored abroad. DEFONEOS has zero exposure because:

Result: No US court order can compel DEFONEOS data production. Only UK courts with jurisdiction over UK-based entities can compel access, and only through the 6 named release conditions below.

4. Six Named Release Conditions

Data may only be released from the escrow under one of these six explicitly named conditions. All releases are SIGIL-recorded, RFC3161-timestamped, and BFT-witnessed.

RC-1: Lawful Warrant — UK court warrant or lawful authority issued under RIPA 2000, Investigatory Powers Act 2016, or equivalent. Requires warrant number, issuing authority, and scope. BFT verifies warrant validity before release.
RC-2: Subject Access Request (SAR) — UK GDPR Article 15 subject access request. Data subject identity verified. Response provided within 1 month (statutory limit). Only personal data of the requesting subject is released.
RC-3: Data Controller Consent — The data controller (typically the deploying government department) provides written, Ed25519-signed consent for data release to a named third party.
RC-4: Destruction Order — Cryptographic destruction order issued by the data controller or by BFT council (23/33 quorum). Data is cryptographically erased (see Section 5) with destruction proof generated.
RC-5: Emergency Release — Emergency release for immediate threat-to-life scenarios. Requires 17/33 BFT emergency quorum + human-owner authorisation + 24-hour post-hoc review. All emergency releases are publicly logged.
RC-6: Operational Release — Routine operational release for legitimate processing (e.g., sharing situational awareness data with a partner agency). Requires 4-eyes gate + BFT witness + SIGIL receipt.

5. Cryptographic Destruction Protocol

When data is ordered destroyed (RC-4), DEFONEOS performs cryptographic destruction — not deletion:

  1. DEK Identification: All Data Encryption Keys protecting the target data are identified.
  2. Shamir Burn: The 3-share Shamir KEK fragments protecting those DEKs are cryptographically destroyed. Without the KEK, the DEKs cannot be recovered, and the data is permanently unreadable.
  3. Destruction Proof: A cryptographic proof of destruction is generated: SHA-256 of destroyed KEK shares, timestamp (RFC3161), Ed25519 signature of witnessing BFT agents (23/33 quorum).
  4. Bitcoin OTS Anchor: The destruction proof is anchored to the Bitcoin blockchain via OpenTimestamps, providing tamper-evident permanent record.
  5. SIGIL Ledger Entry: Full destruction record logged to SIGIL ledger with permanent retention.
Key property: Even if physical storage media is seized, the data cannot be recovered without the destroyed KEK. This is stronger than overwriting — it is mathematically irreversible destruction.

6. BFT Council Veto

The 33-agent BFT governance council can veto any data release at any stage:

Veto TypeQuorumTrigger
Standard Veto23/33Block any RC-1, RC-3, or RC-6 release that violates red lines or governance rules
Emergency Veto17/33Block RC-5 emergency release if evidence suggests abuse
Permanent Freeze23/33Freeze all data access for a named actor or MCP pending investigation

7. Compliance Cross-Walk

RegulationClauseDEFONEOS Coverage
UK GDPRArt 28 (processor)DEFONEOS acts as a data processor with escrow-grade controls. DPA with data controller documented.
UK GDPRArt 32 (security)AES-256-GCM + TLS 1.3 + per-record DEK + Shamir KEK. State-of-the-art.
UK GDPRArt 17 (erasure)Cryptographic destruction (stronger than deletion) with Bitcoin-anchored proof.
DPA 2018Schedule 1Schedule 1 conditions for processing of special category data documented.
OSA (Official Secrets Act)Section 7All escrow logs redacted per OSA s7 before any public disclosure.
JSP 440§4 / §8Information security controls align with JSP 440 MOD security manual.
JSP 936AI governanceEscrow protocol is the data custody layer of JSP 936 compliance.
EU AI ActArt 15Data governance, accuracy, and robustness requirements met through escrow controls.
NCSC CAFPrinciple C4Data security controls exceed NCSC Cyber Assessment Framework requirements.
ISO 27001A.8 / A.10Asset management + cryptography controls documented and auditable.