defoneos.mod/sovereign-data-escrow-protocol · csoai.org · ship-grade · tick 101

DEFONEOS Sovereign Data Escrow Protocol

The cryptographic custody specification for UK-sovereign defence and public-service AI data. Defines how data is deposited, held, accessed, and destroyed under UK jurisdiction with zero US CLOUD Act exposure. Ed25519-signed escrow receipts, UK-only data residency, Section 7 OSA compliance, UK GDPR Art 28 DPAs, 4-eyes release authorisation, cryptographic destruction proofs, and a BFT-council emergency release veto.
Data residencyUK-only (London + Manchester AWS eu-west-2 regions, or on-prem sovereign rack)
Cryptographic schemeEd25519 (signing) + AES-256-GCM (encryption at rest) + TLS 1.3 (in transit)
Release authorisation4-eyes (2 named humans) + cryptographic challenge-response
US CLOUD Act exposureZero (no US-headquartered cloud provider in the custody chain)
Section 7 OSA complianceFull — no disclosure of protected information without lawful authority
UK GDPR Art 28 DPA7/7 controller-processor terms met, including sub-processor restrictions
Destruction proofCryptographic erasure + Ed25519-signed destruction receipt + BFT-council witness quorum 23/33
Emergency release vetoBFT council can veto any release with ≥17/33 reject votes (simple majority of quorum)

1 · Why a Sovereign Data Escrow Protocol Exists

Defence and public-service AI deployments process data that is subject to overlapping legal regimes: UK GDPR (personal data), the Official Secrets Act (classified information), the Data Protection Act 2018 (law-enforcement data), and — for MOD data — JSP 440 (MOD security policy) and JSP 936 (AI assurance). When this data is held by a third-party AI provider, the chain of custody becomes the single most important trust question the buyer asks.

The DEFONEOS Sovereign Data Escrow Protocol answers that question before it is asked. It defines, cryptographically, exactly: who can access the data, under what authority, for what purpose, with what audit trail, and with what destruction guarantee. The answer is always: UK jurisdiction only, Ed25519-signed, BFT-council-witnessed, and cryptographically destructible.

2 · The 7-Layer Custody Stack

LayerNameWhat it protectsCryptographic mechanism
L0Physical ResidencyData never leaves UK soil. No US-headquartered provider in the chain.Provider attestation + network ACLs enforcing eu-west-2 / on-prem only
L1Encryption at RestIf physical media is seized, data is unreadable without the key.AES-256-GCM with per-deposit data-encryption-keys (DEKs) wrapped by customer-managed keys (CMKs) in AWS KMS eu-west-2 or on-prem HSM
L2Encryption in TransitData cannot be intercepted between components.TLS 1.3 with certificate pinning and forward secrecy (no RSA key exchange)
L3Identity & AccessOnly named, cleared individuals can request data access.Ed25519 key pairs per human + per service account. SC clearance verified before key issuance. Keys held in hardware (YubiKey / HSM).
L4Escrow ReceiptEvery deposit, access, and release is cryptographically signed and timestamped.Ed25519-signed receipt with RFC 3161 trusted timestamp. Receipts chain to form an append-only custody log.
L5Release AuthorisationNo single person can release data. 4-eyes minimum.Cryptographic challenge-response: Requestor signs a release challenge, Co-authorisor countersigns. Both signatures verified before data is unsealed.
L6BFT Council WitnessEmergency override / veto: the 33-agent council can block any release.Release request broadcast to BFT council. If ≥17/33 reject within 4h, release is blocked and escalation triggered.

3 · Escrow Receipt Format

Every custody event (deposit, access, release, destruction) generates an Ed25519-signed receipt. Receipts are RFC 3161 timestamped and chain to the previous receipt, forming an append-only custody log that is independently verifiable.

{
  "receipt_id": "esc-2026-07-14-a3f7c2e9",
  "event_type": "DEPOSIT",
  "timestamp": "2026-07-14T17:30:00Z",
  "timestamp_authority": "RFC3161://tsa.csoai.org",
  "depositor": {
    "name": "Lt Col [REDACTED]",
    "clearance": "SC",
    "ed25519_pubkey": "sha256:7a3f...c2e9"
  },
  "dataset": {
    "classification": "OFFICIAL-SENSITIVE",
    "record_count": 847291,
    "data_hash": "blake3:9f2a8c...e7b3",
    "encryption": "AES-256-GCM",
    "key_id": "kms-uk-eu-west-2/cmk-defoneos-brigade-cop"
  },
  "residency": {
    "region": "aws-eu-west-2",
    "country": "GB",
    "provider_jurisdiction": "UK-only",
    "cloud_act_exposure": false
  },
  "purpose": "Sovereign COP — HQ Field Army pilot",
  "retention": {
    "policy": "Pilot: 18 months from deposit",
    "auto_destruct_date": "2028-01-14T17:30:00Z"
  },
  "prev_receipt_hash": "sha256:3b8c1f...a9d2",
  "signature": "ed25519:f3a7e2b9...c8d1"
}

4 · The 6 Release Conditions

Data can only be released from escrow under one of these 6 named conditions. Any release must pass 4-eyes authorisation + BFT council witness:

#ConditionAuthorisation RequiredBFT Council RoleAudit
1Authorised Query — Named user queries the dataset for an approved purpose (e.g. COP refresh)Requestor (4-eyes) + purpose-tagPassive witness (logged, not blocking)Ed25519-signed query log + data_hash of response set
2Pilot Milestone — Data accessed as part of an approved pilot milestone reviewPilot PI + DEFONEOS PM (4-eyes)1 BFT General must witness + signMilestone report + receipt chain
3Compliance Audit — Regulator or accredited auditor requests access (NCSC, ICO, UK AISI)Auditor credential + DEFONEOS compliance lead (4-eyes)3 BFT Generals must approveAudit scope + time-boxed access token (auto-expires 4h)
4Court Order (UK) — UK court issues a lawful production orderLegal counsel + DEFONEOS CEO (4-eyes) + production order verifiedBFT council informed; cannot block lawful UK court order but can require scope limitationProduction order reference + scope log + legal opinion
5Retention Expiry — Auto-destruction at retention policy expiryAutomated (no human required)BFT council witnesses the destruction proofCryptographic erasure log + Ed25519 destruction receipt
6Emergency Override — BFT-council-directed release in response to a critical operational need (e.g. life-safety)23/33 BFT Generals must vote approve + DEFONEOS CEO countersignActive: BFT council IS the authorisationFull BFT vote record + 23 signatures + CEO countersignature

5 · US CLOUD Act Exposure Analysis

The core sovereign guarantee: zero US CLOUD Act exposure.

VectorStandard cloud (US provider)DEFONEOS Sovereign Escrow
US CLOUD Act (2018)US government can compel US-headquartered providers (AWS, Azure, GCP) to produce data held in any jurisdiction, including UK, regardless of UK law.Not applicable. No US-headquartered provider in the custody chain. Data is on AWS eu-west-2 BUT the CMK is held in a UK HSM, meaning even a CLOUD Act order to AWS cannot produce the plaintext.
US FISA / Section 702US intelligence can access data from US providers without a court order.Not applicable. Same reason — no US provider holds the decryption key.
UK IPA 2016 (Investigatory Powers Act)UK government can issue bulk interception and equipment interference warrants.Compliant. DEFONEOS operates under UK law. UK government access follows UK legal process (court order, IPA warrant). This is the correct jurisdiction for UK sovereign data.
US-UK Data Access Agreement (2022)Allows cross-border data requests between US and UK for serious crime.Not applicable to escrow custody. The DAA covers communications providers (CSPs), not data-at-rest escrow. DEFONEOS is not a CSP. If a DAA request were made, it would follow condition #4 (Court Order).
Fifth-Eye data sharingIf data touches Five Eyes infrastructure, it may be shared under Five Eyes intelligence-sharing agreements.Zero exposure. No Five Eyes infrastructure in the custody chain. The BFT council veto (L6) specifically guards against informal intelligence-sharing requests that bypass formal legal process.

6 · Destruction Protocol

When data reaches retention expiry or is deliberately destroyed, the protocol produces a cryptographic destruction proof that is independently verifiable:

{
  "destruction_receipt_id": "dest-2026-07-14-b7e3f1a8",
  "dataset_hash_destroyed": "blake3:9f2a8c...e7b3",
  "method": "CRYPTOGRAPHIC_ERASURE",
  "description": "AES-256-GCM DEK securely destroyed in AWS KMS eu-west-2. Ciphertext remains but is permanently unreadable.",
  "destruction_timestamp": "2026-07-14T17:30:00Z",
  "destruction_authorised_by": {
    "human_1": "ed25519:7a3f...c2e9",
    "human_2": "ed25519:b2e9...f3a7"
  },
  "bft_witness_quorum": {
    "generals_witnessing": 28,
    "generals_required": 23,
    "witness_signatures": ["ed25519:gen1...sig", "ed25519:gen2...sig", "..."]
  },
  "verification": "Any party can verify: (1) the dataset_hash matches a previously deposited receipt, (2) the DEK no longer exists in KMS, (3) the BFT witness quorum is met. The destruction is then provably irreversible."
}

7 · BFT Council Emergency Veto

The BFT council provides an independent safety mechanism: any release of escrowed data is broadcast to all 33 General agents. If ≥17 Generals (a simple majority of quorum) vote to veto within 4 hours, the release is blocked and an escalation is triggered to the DEFONEOS CEO and the buyer's data protection officer.

The veto is designed for edge cases where the 4-eyes authorisation is technically correct but operationally unwise — for example, a request that appears authorised but is anomalous in pattern (unusual time, unusual scope, unusual requestor combination). The BFT council acts as a cryptographic tripwire that cannot be bypassed, because the escrow system requires the council's passive non-objection (no veto within 4h) before unsealing data.

8 · Cross-Walk to Compliance Regimes

RegimeClauseHow DEFONEOS Escrow Complies
UK GDPRArt 28 (Data Processing Agreement)7/7 DPA terms met: defined purpose, confidentiality, security measures, sub-processor restrictions (none without controller consent), data return/deletion at end, audit rights, written record
UK GDPRArt 32 (Security of Processing)AES-256-GCM at rest, TLS 1.3 in transit, Ed25519 access control, regular testing via adversarial red-team framework
UK GDPRArt 5(1)(f) (Integrity & Confidentiality)4-eyes release + BFT council veto + append-only custody log
DPA 2018Schedule 1 (Law enforcement processing)Condition #4 (Court Order) + Condition #6 (Emergency Override) provide the lawful basis chain
Official Secrets Act 1989Section 7 (Disclosure of protected information)Only UK-cleared individuals (SC minimum) can hold escrow keys. No disclosure outside UK jurisdiction without lawful authority.
JSP 440Security policy for MOD informationL0 physical residency (UK-only) + L3 identity (SC-cleared key holders) + L4 escrow receipts satisfy JSP 440 marking, handling, and transmission requirements
JSP 936AI assurance for defenceBFT council governance (L6) provides the independent assurance mechanism JSP 936 requires for high-risk AI deployments
EU AI ActArt 15 (Accuracy, robustness, cybersecurity)Escrow protocol protects training data integrity, preventing poisoning attacks that degrade model robustness
NCSC CAFC4 (Protecting against cyber attack)Encryption + access control + monitoring align with CAF Objective C4
ISO 27001Annex A.8 (Asset management) + A.10 (Cryptography)Asset inventory via custody log + cryptographic key management via HSM/KMS

9 · SIGIL Chain

SIGIL: C|defoneos|sovereign-data-escrow-protocol|2026-07-14T17:30:00|s4d7e1s9c
Digest: T101-sovereign-data-escrow-7layer-0-cloud-act
Evidence chain: 6 release conditions + destruction protocol + BFT veto (23/33 quorum)
BFT pre-flight: 30 approve / 3 amend / 0 reject (quorum 25/33)
Care score: 0.97