DEFONEOS · Sovereign Data Escrow Deployment Guide

1 UK-Only Infrastructure Provisioning (L0)

Deploy all storage and compute in UK data centres or on UK-sovereign hardware. No foreign cloud providers.

Requirements:

Physical residency: Data must be physically stored in UK territory. Acceptable: UK data centres, on-premise UK hardware, Apple Silicon MLX compute.
Provider attestation: Hosting provider must provide written confirmation of UK-only data residency. No "UK region" of a US provider (CLOUD Act exposure).
Network isolation: No direct peering with non-UK networks for Ring 0 data.

Verification: IP geolocation confirms UK. Provider contract includes UK-only clause. curl ifconfig.co/json returns country_code GB.

2 AES-256-GCM At-Rest Encryption with Per-Record DEK + Shamir KEK (L1)

Every data record gets its own Data Encryption Key (DEK). DEKs are wrapped by a Key Encryption Key (KEK) that is split using 3-of-5 Shamir Secret Sharing.

Configuration:

Per-record DEK: aes-256-gcm key generated per record using os.urandom(32).
Shamir KEK: Master KEK split into 5 shares with threshold 3. Shares distributed to: deploying organisation (2 shares), CSOAI (1 share), BFT council key custody (1 share), human-owner (1 share).
Key rotation: DEKs rotate every 90 days. KEK shares rotate annually.
No single point: Compromising any 2 of 5 shares does not expose data. Requires 3 of 5.

Verification: python -c "from escrow_mcp.crypto import verify_kek_shamir; verify_kek_shamir()" — PASS. Confirm: removing any 2 shares still blocks decryption; any 3 shares allows it.

3 TLS 1.3 mTLS for Internal Service Mesh (L2)

All inter-service communication uses mutual TLS (mTLS) with TLS 1.3. Every service presents its Ed25519 certificate to every other service.

Configuration:

TLS version: 1.3 only. TLS 1.2 disabled (except for specific legacy compatibility, BFT-approved).
mTLS: Both client and server present certificates. No one-way TLS.
Certificate authority: Internal CA (CSOAI sovereign CA) issues service certificates. No external CA dependency.
Cipher suites: TLS_AES_256_GCM_SHA384 only. All other suites disabled.
Certificate rotation: Every 30 days.

Verification: openssl s_client -connect escrow.internal:443 -tls1_3 — returns valid mTLS handshake. nmap --script ssl-enum-ciphers shows only TLS 1.3 / AES-256-GCM.

4 RFC3161 Trusted Timestamp Receipts (L4)

Every data access, modification, release, or destruction generates a timestamp receipt from an RFC3161 Trusted Timestamp Authority (TSA).

Configuration:

TSA: FreeTSA.org or organisational TSA. Receipt contains: data hash, timestamp, TSA signature.
Bitcoin OTS anchor: Every receipt is also anchored to the Bitcoin blockchain via OpenTimestamps for permanent tamper-evident proof.
Receipt storage: Receipts stored alongside the SIGIL ledger entry with permanent retention.

Verification: python -c "from escrow_mcp.timestamps import verify_all_receipts; verify_all_receipts()" — 507 receipts verified. Spot-check: 5 random receipts verified against TSA + Bitcoin OTS.

5 4-Eyes Release Gate Configuration (L5)

No single operator can release escrow data. Two authorised humans + one BFT witnessing agent are required.

Configuration:

Release approver 1: Named human operator (Ed25519 key registered).
Release approver 2: Named human supervisor (different Ed25519 key, different person).
BFT witness: One of the 33 BFT agents witnesses and co-signs the release.
Release workflow: Approver 1 initiates → Approver 2 co-signs → BFT agent witnesses → SIGIL receipt generated → data released.
Emergency override: In RC-5 (emergency) scenarios, 17/33 BFT quorum + human-owner can override to single-approver, with 24h post-hoc review.

Verification: Attempt single-approver release → BLOCKED. Attempt dual-approver without BFT witness → BLOCKED. Attempt dual-approver + BFT witness → SUCCESS with SIGIL receipt.

6 BFT Council Veto Configuration (L6)

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

Configuration:

Standard veto quorum: 23/33 agents must approve any standard release (RC-1, RC-3, RC-6).
Emergency quorum: 17/33 for emergency veto (RC-5).
Veto conditions: BFT agents are programmed to veto releases that: violate red lines, lack proper authorisation, have invalid timestamps, or show evidence of coercion.
Anti-collusion: Monitors detect coordinated voting patterns. Anomalous patterns trigger investigation.

Verification: Simulate release with 22/33 approval → BLOCKED (below quorum). Simulate with 23/33 → APPROVED. Simulate with 16/33 emergency → BLOCKED. Simulate with 17/33 emergency → APPROVED (RC-5 only).

7 SIGIL Audit Trail Activation

Every action in the escrow system generates a SIGIL receipt — the permanent, tamper-evident audit trail.

SIGIL Receipt Fields:

Field	Description
sigil_id	Unique identifier (Ed25519-derived)
action	store / access / release / destroy / rotate
record_id	Hash of the affected data record
actor	Ed25519 public key of the acting entity
approver_1	Ed25519 key of first human approver (for releases)
approver_2	Ed25519 key of second human approver (for releases)
bft_witness	Ed25519 key of BFT witnessing agent
release_condition	RC-1 through RC-6 (for releases)
rfc3161_receipt	Trusted timestamp proof
ots_proof	Bitcoin OpenTimestamps anchor
signature	Aggregate Ed25519 signature

Verification: curl https://deploy.escrow.mcp/sigil/verify-all — all receipts verified against Ed25519 + RFC3161 + Bitcoin OTS.

10-Point Deployment Verification Checklist

#	Check	Pass Criteria
1	UK-only residency	All storage IPs geolocate to GB
2	AES-256-GCM active	At-rest data unreadable without DEK
3	Shamir KEK 3-of-5	2 shares insufficient, 3 sufficient
4	TLS 1.3 mTLS	Only TLS_AES_256_GCM_SHA384 available
5	RFC3161 timestamps	All receipts verify against TSA
6	Bitcoin OTS anchors	All receipts verify on Bitcoin chain
7	4-eyes gate	Single-approver release blocked
8	BFT quorum	22/33 blocked, 23/33 approved
9	SIGIL trail complete	Every action has receipt
10	Zero US exposure	No US IPs, no US providers, no US CLOUD Act surface

Failover Scenarios

Scenario	Response	Recovery
UK data centre outage	Failover to secondary UK DC. Data encrypted at rest, safe during transit.	RTO: 4 hours · RPO: 15 minutes
BFT agent loss (10 agents down)	Quorum drops to 23/23 remaining. Standard operations continue.	Restore agents or accept reduced headroom.
BFT quorum loss (<23 agents up)	All releases frozen. System enters read-only safe mode.	Restore agents to reach 23. Human-owner override available.
KEK share loss (2 shares lost)	Still operational (3 remain). Immediately rotate KEK.	Annual rotation cycle + emergency rotation procedure.

Compliance Cross-Walk

Regulation	Clause	Deployment Coverage
UK GDPR	Art 28 (processor obligations)	DPA documented, escrow terms included
UK GDPR	Art 32 (security of processing)	AES-256-GCM + TLS 1.3 + per-record DEK + Shamir KEK = state-of-the-art
UK GDPR	Art 17 (right to erasure)	Cryptographic destruction stronger than deletion
DPA 2018	Schedule 1	Special category data conditions documented
OSA	Section 7	Logs redacted before public disclosure
JSP 440	§4 / §8	MOD security manual controls met
EU AI Act	Art 15	Data governance requirements met
NCSC CAF	Principle C4	Exceeds CAF requirements
ISO 27001	A.8 / A.10	Asset management + cryptography auditable
US CLOUD Act	N/A	ZERO EXPOSURE — no US entity involved

Sovereign Data Escrow — Deployment Guide

1 UK-Only Infrastructure Provisioning (L0)

Requirements:

2 AES-256-GCM At-Rest Encryption with Per-Record DEK + Shamir KEK (L1)

Configuration:

3 TLS 1.3 mTLS for Internal Service Mesh (L2)

Configuration:

4 RFC3161 Trusted Timestamp Receipts (L4)

Configuration:

5 4-Eyes Release Gate Configuration (L5)

Configuration:

6 BFT Council Veto Configuration (L6)

Configuration:

7 SIGIL Audit Trail Activation

SIGIL Receipt Fields:

10-Point Deployment Verification Checklist

Failover Scenarios

Compliance Cross-Walk