SDV Security Architecture

Engineered for the next 30 years of threat, not the last 30.

Every design decision in SDV assumes a future with working quantum computers. The same cryptography that secures a $15M sovereign deployment secures a $500 personal vault - CRYSTALS-Kyber FIPS 203 for key encapsulation, Dilithium-III FIPS 204 for signatures, SHA-3-512 for integrity, all anchored on JIL L1 with 14-of-20 Byzantine Fault Tolerant quorum.

Layer 1 · Encryption

Three layers of cryptographic protection.

Your documents pass through a defense-in-depth pipeline before a single byte reaches SDV storage. At rest, in transit, and during every operation - each layer uses algorithms specifically chosen to resist both classical and quantum attacks.

AES-256-GCM

At-rest encryption

Each file is encrypted client-side with its own per-file data encryption key (DEK). DEKs are wrapped by your master key - JIL never sees the plaintext.

CRYSTALS-Kyber · FIPS 203

Post-quantum key encapsulation

Your master key is protected by Kyber-1024, NIST's first standardized post-quantum KEM (FIPS 203, August 2024). Resistant to Shor's algorithm on future quantum hardware.

CRYSTALS-Dilithium-III · FIPS 204

Post-quantum signatures

Every vault operation (upload, modify, share, release) is signed with Dilithium-III. Hybrid Ed25519 + Dilithium-III signatures run during the transition period for backward compatibility.

TLS 1.3 + PQ hybrid KEX

In-transit encryption

Every client-to-server connection uses TLS 1.3 with a post-quantum hybrid key exchange (X25519Kyber768). Harvest-now-decrypt-later attacks do not work against SDV transport.

Layer 2 · Integrity

Every file. Every hash. Sealed on JIL L1.

Encryption protects confidentiality; hashing and blockchain anchoring protect integrity. SDV computes a SHA-3-512 hash of every encrypted file, seals it with a Dilithium-III signature, and commits it to JIL Layer 1 - a production blockchain with 10 active Sovereign Compliance Network (SCN) validators across 13 jurisdictions running a 14-of-20 Byzantine Fault Tolerant consensus.

The result: any modification, corruption, or substitution of a vault file - even by someone with full server access - invalidates the seal and is cryptographically detectable. Your heirs can prove, years or decades later, that the document they receive is byte-for-byte the document you stored.

Hash algorithm
SHA-3-512 (Keccak, FIPS 202). Quantum-resistant for collision and preimage resistance.
Signature algorithm
CRYSTALS-Dilithium-III (FIPS 204) for post-quantum signatures. Hybrid Ed25519 + Dilithium-III for transition-period compatibility with existing systems.
Anchor target
JIL Layer 1 blockchain. Every commit is observable on the public JIL block explorer.
Quorum
14-of-20 BFT quorum across 13 jurisdictions signs each L1 block. A 70% SCN validator compromise is required to forge an anchor - by which point the blockchain would have already forked.
Verification
Recompute the file hash, compare against the L1-anchored hash, and verify the Dilithium-III signature. Independent - does not require JIL cooperation.
Layer 3 · Zero-knowledge architecture

JIL cannot read your vault.

SDV is engineered as a zero-knowledge service: file encryption happens on your device using keys derived from your quantum-resistant master key. What JIL stores is opaque ciphertext plus metadata (file size, content hash, beneficiary rules, access log). What JIL cannot see: the contents.

This is not a policy choice that can be quietly reversed. It is an architectural invariant - the server-side code has no path to plaintext that doesn't route through your client. A compromised database, a rogue employee, a court subpoena directed at JIL's cloud provider - none of these yield plaintext documents. They yield ciphertext for which JIL does not hold the key.

What JIL can see

What JIL cannot see

Layer 4 · Death-trigger verification

Posthumous release that survives adversarial scrutiny.

A death-triggered release is only useful if its verification workflow can stand up to a fraud attempt. SDV's release pipeline is multi-source, release-windowed, and cryptographically auditable - every step produces a sealed record that a court, insurer, or trustee can verify independently.

Primary data source
U.S. Social Security Administration Death Master File (DMF) via authorized data provider.
Secondary sources
State-level vital records feeds where contracted. Manual death-certificate upload by family with document verification.
False-positive protection
On initial signal, SDV pauses vault activity and sends a verification request to the owner. Only proceeds after the release window (90/30/24 hours / same-day by tier) with no owner response.
Secondary verification
Multi-source confirmation required (DMF + state record, or certificate + court order). Legacy Plus adds human phone outreach to named contacts.
Audit trail
Every step - signal detection, owner notification, verification completion, beneficiary access - is sealed on JIL L1 with a Dilithium-III signature. Fully court-admissible.
Reversal
False-positive releases can be cryptographically reverted within the verification window. Owner-initiated dispute freezes the release.
Layer 5 · Sharing + access control

Granular. Revocable. Audited.

Every share is a per-file, per-recipient, per-permission cryptographic grant. Revocation rotates the relevant keys immediately - no delay, no propagation window. Every access is logged with timestamp, IP address, device fingerprint, and action taken.

Standards & certifications

Built on, and compliant with, recognized standards.

The same crypto protecting sovereign deployments, protecting your family's documents.

SDV runs on the same JIL L1 production infrastructure used by institutional settlement customers - 250 microservices, 10 SCN validators across 13 jurisdictions, 14-of-20 BFT quorum, 53-claim patent portfolio.

See pricing → From $500/yr