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

This is not a seed-based wallet. Recovery depends on encrypted vault + guardian shares, not mnemonic regeneration of keys.

Keys are NOT derived from the mnemonic. They are generated with full-strength OS randomness (CSPRNG).
Mnemonic derives the vault encryption key ONLY via SHAKE256 (post-quantum safe).
Vault contains actual PQ key material encrypted with AES-256-GCM. Nonce from CSPRNG per encryption.
Loss of mnemonic alone = cannot decrypt vault. Keys still exist encrypted.
Loss of mnemonic + all guardians = permanent loss.
Guardians hold vault key shares (Shamir + Kyber encrypted), not raw keys.

Scenario	Recovery Path
Lost device, have mnemonic	Mnemonic → vault key → decrypt vault backup
Lost mnemonic, have device	Vault still unlockable via biometric on device
Lost both	k-of-n guardians reconstruct vault key
Guardian compromise	Remaining guardians + mnemonic = sufficient

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, exfiltrate mnemonic during display, 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	Mnemonic + device still operational. Re-enroll new guardians.
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 — mnemonic generation, vault key derivation, Dilithium signing, zeroize. 174KB WASM binary, pure Rust.
Server: Proprietary (GitLab). FHE biometric matching, H33-74 attestation, security gate, policy engine. The moat.
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, mnemonic, vault
E2E (1): Full lifecycle: mnemonic → 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. Mnemonic during display. 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. Mnemonic.
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.

Back to Digital SCIF View Source

144 patent claims pending · H33.ai, Inc. · #19/645,499