← Digital SCIF
Security Transparency
Full disclosure of the Digital SCIF security architecture. Threat model, custody model, device trust, policy engine, key rotation, recovery adversary model, and audit architecture.
The system is designed under the assumption that both client and server environments may be partially adversarial. 82 tests validate correctness under adversarial, concurrent, and failure conditions.
Execution layer owns full state transition: key → policy → signing → broadcast → confirmation → reorg recovery. This system does not just sign transactions. It manages UTXO/nonce state, broadcast with retry, chain-specific finality, and failed transaction recovery.
82 Tests Passing
Zero Errors
3 PQ Families
Open Source Client
FHE Biometric
Critical
Custody Model
H33 stores zero plaintext biometric data. The server never receives plaintext biometrics, vault keys, match scores, or signing keys by design. Server-side compromise does not expose biometric templates; client compromise remains a separate endpoint risk controlled by device attestation, Secure Enclave/TEE, revocation, and behavioral anomaly detection. No seed phrases. No paper backups.
Biometric Security Architecture
- Client holds the FHE secret key. Biometrics are encrypted on your device before leaving it. The server holds only the public key and evaluation keys.
- Server computes on ciphertexts only. FHE inner product produces an encrypted match score. The server cannot decrypt it.
- Client decrypts the match score and signs a Dilithium match assertion bound to: challenge nonce, template ID, encrypted result hash, timestamp, and policy version. Non-replayable, non-forgeable.
- H33 stores zero biometric data. Enrolled templates are ciphertexts. Without the client's secret key, they are computationally infeasible to decrypt, even with a quantum computer (lattice-based RLWE).
- Anti-spoofing: 17 liveness checks (printed photo, screen replay, 3D mask, deepfake, voice clone, gait mimicry) run before biometric capture, without decrypting anything.
Key Custody & Recovery
- Keys are NOT derived from words. They are generated with full-strength OS randomness (CSPRNG).
- Recovery key is 256-bit random, Shamir-split across 3 trusted devices. Any 2 of 3 reconstruct.
- Each share is ML-KEM encrypted (FIPS 203, ML-KEM-768) to the device's public key. Shares are information-theoretically secure.
- Guardian social recovery: Shamir shares encrypted with ML-KEM to trusted guardians (family, attorney). Independent polynomial from device shares. 72-hour time delay + owner notification.
- Biometric re-enrollment: Prove you're you on a new device via FHE match against stored encrypted template. Authorizes share release.
- Multi-device: If you have Digital SCIF on two devices, one recovers the other via share transfer (re-encrypted to new device's ML-KEM key).
- Vault contains actual PQ key material encrypted with AES-256-GCM. Nonce from CSPRNG per encryption.
- Loss of 1 device = remaining 2 devices reconstruct. No interruption.
- Loss of 2+ devices = contact remaining device + re-enroll biometric. Recovery event H33-74 attested.
- Every recovery event is cryptographically attested via H33-74 (ML-DSA + FALCON + SLH-DSA).
| Scenario | Recovery Path |
|---|
| Lost 1 device | 2 remaining devices contribute shares → reconstruct → re-enroll |
| Lost device, have biometric | Vault still unlockable via biometric on any paired device |
| New device | Biometric auth on existing device → pair new device → redistribute shares |
| All devices lost | Guardian recovery (enterprise) or permanent loss (by design — no backdoor) |
Adversary Classes
Threat Model
1. Malicious Server
CAN: deny service, delay responses, return stale data
CANNOT: decrypt biometrics (FHE), decrypt vault (key client-side), forge attestations (3 PQ private keys required)
2. Malicious Client (JS tampering, WASM injection)
CAN: modify displayed data, intercept share distribution during pairing, substitute signing payloads
Enforced: CSP headers + WASM integrity hash in production builds. Subresource integrity on all script loads. Server-side payload validation before attestation.
3. Compromised Device
CAN: capture biometric before FHE encryption, exfiltrate vault key from memory
Mitigated: device attestation (TPM/Secure Enclave/WebAuthn), quarantine + revocation, biometric bound to device state
4. RPC/Provider Manipulation
CAN: return false balances, fake confirmations, censor transactions
Mitigated: multiple independent RPCs, cross-verification, reorg detection (block hash tracking)
5. Evil Twin WiFi
CAN: intercept all network traffic, MITM all connections
Mitigated: CCRA NetworkDna fingerprinting detects evil twins. Wallet refuses ALL operations when detected. PQ VPN required for Cold tier.
6. Biometric Spoof (17 attack types)
CAN attempt: printed photo, digital screen, 3D mask, mannequin, deepfake, video replay, voice cloning, gait mimicry
Mitigated: anti-spoofing runs in FHE domain (before decryption). k-of-n collective authority — no single party holds decryption key.
7. Replay + Rollback Attacks
CAN: replay signed transactions on different chains
Mitigated: chain_id in H33-74 commitment, nonce/UTXO tracking, timestamp + nonce in every attestation
8. Guardian Collusion
k guardians CAN reconstruct vault key (by design)
Mitigated: time-delayed recovery (anti-theft window), owner notification, geographic distribution, 72-hour cooldown on guardian changes
9. Chain Reorg
CAN: reverse confirmed transactions below finality threshold
Mitigated: per-chain confirmation policy (BTC: 3, ETH: 12, SOL: 1), reorg detection + transaction replay
10. Side-Channel
CAN: timing analysis on WASM PQ signing (FALCON is variable-time)
Mitigated: Dilithium (constant-time) runs client-side. FALCON + SPHINCS+ run server-side. Server-side is protected hardware.
Enforcement
Security Gate — Tier Requirements
Security Gate enforces runtime invariants across key usage, device identity, and execution context. All cryptographic operations are blocked unless policy, device attestation, and vault state are valid.
| Check | Hot | Warm | Cold |
|---|
| CCRA connection score | ≥ 0.7 | ≥ 0.7 | ≥ 0.9 |
| Device attested | Required | Required | Required |
| Binary integrity (ZK-Verify) | — | Required | Required |
| PQ VPN active | — | — | Required |
| ZK-Phish scanning | — | — | Required |
| BotShield token | Required | Required | Required |
| Evil twin detected | Blocks ALL tiers immediately |
Governance
Policy Engine
All actions are evaluated against policy before execution, not just cryptographic validity.
- Roles: Owner (full access), Guardian (recovery only), Admin (enterprise policy), ReadOnly (view only)
- Spend limits: per-transaction, per-day rolling window, per-asset
- Multisig escalation: amounts above threshold require k-of-n threshold signing
- Time locks: 72-hour cooldown on estate changes and guardian changes
- KYC-linked: certain actions require verified ZK-KYC proof (zero PII transmitted)
Device
Device Trust Model
Biometric verification is bound to trusted device state. A valid biometric on an untrusted device is not sufficient.
- Enrollment: first trust event, binds device fingerprint to identity
- Attestation: TPM 2.0, Apple Secure Enclave, Android Keystore, WebAuthn, or WASM self-attest
- Session binding: device + biometric + vault state = session. All three required.
- Revocation: instant, propagates to all active sessions on that device
- Quarantine: compromised devices locked out, existing sessions invalidated
- Maximum 5 devices per wallet. New enrollment blocked after limit.
Crypto Agility
Key Rotation
Keys are not static. The system supports forward-secure rotation without breaking prior attestations.
- Full rotation: all three families + Kyber replaced simultaneously
- Partial rotation: single family (e.g. Dilithium only) when crypto agility requires it
- Old attestations remain valid: keyed by attestation ID, not current key
- Identity re-attested: Token-C soulbound NFT updated with new public key commitment
- Emergency rotation: bypasses cooldowns on compromise detection
Adversarial Recovery
Recovery Resilience
No single party — including the server — can recover a wallet. Recovery requires quorum and cannot be bypassed. Recovery is resilient to loss, compromise, and adversarial coordination, not just happy-path reconstruction.
| Scenario | Outcome |
|---|
| Single guardian lost | System continues. Remaining k-1 of n-1 still meets threshold. |
| Guardian compromised | One share alone is useless (Shamir requires k shares). Rotate guardian. |
| k guardians collude | CAN reconstruct vault key (by design). Mitigated by time delay + owner notification. |
| All guardians lost | Device shares still operational. Re-enroll new guardians from any 2-of-3 devices. |
| Theft attempt via recovery | 72-hour time delay + owner notification + geographic lock |
| Death / legal trigger | Estate execution: dormancy detection (120 days) + beneficiary distribution |
Observability
Audit Architecture
Every action is both provable and observable. Every audit entry is anchored to an H33-74 attestation, making logs independently verifiable rather than self-reported.
- Append-only log: SHA3-256 hash-chained entries. Tampering detectable.
- H33-74 anchored: Each log entry references its attestation hash. Third parties can verify any entry without trusting the server.
- Searchable: by operation type, time range, wallet ID, device ID
- Policy evaluation logs: records WHY an action passed or failed
- Security gate blocks logged: which check failed, what score was
- Exportable: JSON compliance reports for audit
Transparency
Open Source
The wallet client is fully open source. Every line of code that touches your keys is auditable.
- Client (WASM): github.com/H33ai-postquantum/digital-scif-wallet — PQ key generation, vault key derivation, Dilithium signing, zeroize. Pure Rust.
- Server: Proprietary. FHE biometric matching, H33-74 attestation, security gate, policy engine.
- Standard: HATS v1.0 conformance — independently verifiable evidence that the system satisfies defined controls.
Validation
Test Coverage
82 tests validate correctness under normal, adversarial, and failure conditions:
- KAT (18): Known Answer Tests for Dilithium, FALCON, SPHINCS+, Kyber, TripleSig, H33-74, recovery key, vault
- E2E (1): Full lifecycle: key generation → vault → sign → verify → attest → tamper → recover
- Security Gate (10): All-down, evil twin, device not attested, no VPN, CCRA staleness
- Identity (2): PQ commitment determinism, binding preparation
- Adversarial (24): Double unlock, sign-after-lock, cross-key verify, binding tamper, guardian can't sign, spend limit, device revocation, UTXO insufficient, nonce replacement, reorg detection, audit chain integrity
- Policy (3): Role enforcement, readonly blocked, enterprise spend limits
Architecture
System Boundary
| Component | Holds | Does Not Hold |
|---|
| Client (WASM/native) | Decrypted state post-unlock. Recovery key share in memory. Signing keys in memory. | Nothing persisted in plaintext. Zeroized on lock/drop. |
| Server | Encrypted vault blobs. FHE-encrypted biometric templates. H33-74 attestation keys. | Plaintext keys. Plaintext biometrics. Vault encryption key. Recovery key. |
| Guardians | Individual Kyber-encrypted Shamir shares of the vault key. | Raw vault key (requires k-of-n quorum). Any signing keys. |
| Chains | 32-byte H33-74 commitments. Public key commitments (Token-C). | Trust decisions. Key material. Biometric data. |
| H33-74 Attestations | Source of truth. Independently verifiable. Three PQ signatures per attestation. | Revocable state. Attestations are immutable once minted. |
Chains anchor commitments, not trust. The server processes ciphertext, not secrets. Guardians hold shares, not keys. Attestations are the source of truth.
300+ patent claims pending · H33.ai, Inc. · #19/645,499