Security Architecture

Stratos Vault implements a defense-in-depth security model designed for enterprise requirements.

Overview

Traditional crypto wallets rely on seed phrases - a fundamentally flawed security model for enterprise use:

Traditional Approach	Problem
Seed phrases	Users write them down, lose them, or get phished
Passwords	Weak passwords, credential stuffing, phishing
Hardware wallets	Poor UX, lost devices, complex backup
Custodial solutions	Counterparty risk, regulatory complexity

Stratos Vault eliminates these issues with WebAuthn passkey authentication.

WebAuthn Authentication

How It Works

┌──────────────────┐         ┌──────────────────┐
│   User Device    │         │  Stratos Vault   │
│  ┌────────────┐  │         │                  │
│  │  Passkey   │  │         │                  │
│  │ (Biometric │◄─┼─────────┼─── Challenge     │
│  │  or Key)   │  │         │                  │
│  └─────┬──────┘  │         │                  │
│        │         │         │                  │
│  Sign Challenge  │         │                  │
│        │         │         │                  │
│        └─────────┼────────>│ Verify Signature │
│                  │         │                  │
└──────────────────┘         └──────────────────┘

User initiates login - Scans fingerprint or uses security key
Cryptographic challenge - Server sends random challenge
Hardware signing - Device signs with private key (never leaves device)
Server verification - Public key verifies signature

Security Properties

Property	Benefit
Phishing-resistant	Credential is bound to origin - fake sites can't use it
No shared secrets	Server only has public key - breach doesn't expose credentials
Hardware-backed	Private key in secure enclave or security key
User-friendly	Touch fingerprint instead of typing passwords
Cross-platform	Works on any modern device

Key Derivation

Blockchain keys are derived from WebAuthn credentials using the PRF extension:

┌─────────────────────────────────────────────────────────────┐
│                   User Authentication                        │
│                          │                                   │
│              WebAuthn PRF Extension                         │
│                          │                                   │
│                    PRF Output                                │
│                     (32 bytes)                               │
│                          │                                   │
│              ┌───────────┴───────────┐                      │
│              │                       │                       │
│         Master Seed            Encryption Key               │
│         (BIP-39)               (Local Storage)              │
│              │                                               │
│     BIP-32/44 Derivation                                    │
│              │                                               │
│    ┌─────────┼─────────┬─────────┬─────────┐               │
│    │         │         │         │         │                │
│   EVM     Solana    Bitcoin    TRON      TON               │
│ m/44'/60' m/44'/501' m/84'/0' m/44'/195'                   │
└─────────────────────────────────────────────────────────────┘

Key Properties

Deterministic - Same passkey always derives same addresses
No backup required - Re-derive from any device with same passkey
Device-bound - Keys only accessible with biometric/security key
Memory-only - Keys exist only during signing, then cleared

MPC Signing (Multi-Party Computation)

Stratos Vault supports MPC threshold signing as an advanced security mode. When enabled, private keys are never held in full by any single party - instead, key shares are split between the client and server, and a cryptographic protocol produces valid signatures without ever reconstructing the full key.

Architecture

┌─────────────────────────────────────────────────────────────┐
│                     MPC Signing Flow                         │
│                                                              │
│  ┌──────────────────┐              ┌──────────────────────┐ │
│  │   Client Device  │              │   MPC Signer Worker  │ │
│  │                  │              │  (Durable Object)    │ │
│  │  PRF decrypts    │    Round 1   │                      │ │
│  │  client share    ├─────────────>│  Retrieve server     │ │
│  │  (x1 / f(1))    │  Nonce commit│  share from storage  │ │
│  │                  │<─────────────┤  (x2 / f(2))        │ │
│  │  Compute partial │    Round 2   │                      │ │
│  │  signature       ├─────────────>│  Combine partials    │ │
│  │                  │<─────────────┤  Return signature    │ │
│  │  Full key NEVER  │              │  Session zeroed      │ │
│  │  reconstructed   │              │  after use           │ │
│  └──────────────────┘              └──────────────────────┘ │
└─────────────────────────────────────────────────────────────┘

Supported Protocols

Chain Type	Protocol	Description
EVM, Bitcoin, TRON (secp256k1)	Lindell 2PC-ECDSA	Multiplicative key sharing with Paillier homomorphic encryption
Solana, TON (ed25519)	FROST 2-of-2	RFC 9591 threshold signatures with Feldman VSS

Lindell 2PC-ECDSA (secp256k1)

Used for chains based on the secp256k1 elliptic curve:

Key Generation - Full key x is split as x = x1 * x2 mod N (multiplicative sharing)
Client holds x1 (encrypted with PRF, stored locally)
Server holds x2 (stored in Durable Object)
Signing uses Paillier homomorphic encryption across 3 rounds:
- Round 1: Client and server exchange nonce commitments (R1 = k1*G, R2 = k2*G)
- Round 2: Client sends Paillier ciphertext encoding partial signature
- Round 3: Server decrypts, computes final (r, s, v) signature

FROST 2-of-2 (ed25519)

Used for chains based on the ed25519 curve:

Key Generation - Polynomial secret sharing f(x) = a0 + a1*x using Feldman VSS
Client holds share f(1) with commitments
Server holds share f(2) with commitments
Signing follows the FROST protocol in 2 rounds:
- Round 1: Both parties exchange nonce commitments (D, E points)
- Round 2: Each computes partial signature z_i; server combines into final 64-byte signature

Security Properties

Property	Detail
No full key reconstruction	Key shares are never combined; signing is computed directly on shares
One-time sessions	Each signing session is used exactly once, then deleted
Session expiry	Sessions expire after 30 seconds
Nonce zeroing	All nonces are explicitly zeroed after use
Server isolation	Server shares stored in Cloudflare Durable Objects with per-key isolation
Transparent dispatch	Chain signers use the same API regardless of local or MPC mode

Migration from Local to MPC

Existing users with PRF-only (full-key) wallets can upgrade to MPC:

User authenticates, PRF decrypts the full key
Client splits key into MPC shares (same protocol as keygen)
Server share sent to /api/mpc/keygen
Client share re-encrypted with PRF and stored via /api/mpc/migrate
Database updated: key_type = 'mpc_share', mpc_key_id set

Configuration

MPC is controlled per-instance:

Setting	Description
`MPC_ENABLED`	Feature flag to enable MPC signing
`MPC_SIGNER`	Service binding to the MPC Signer worker
`MPC_AUTH_SECRET`	Shared secret for worker-to-worker auth

Administrators can enable MPC via the admin panel, and monitor key status via the /api/mpc/status endpoint (superadmin only).

Session Security

JWT Token Management

httpOnly cookies - Not accessible to JavaScript
Secure flag - Only transmitted over HTTPS
Short expiry - Sessions expire after configured period
Server-side invalidation - Can revoke sessions immediately

Session Lifecycle

Register → Create Credential → Issue JWT → Active Session → Expire/Logout
                                              ↑
                                    Re-authenticate to extend

Data Protection

Database Isolation

Each Stratos Vault instance has a completely separate database:

Data	Storage	Encryption
User profiles	D1 Database	At-rest encryption
WebAuthn credentials	D1 Database	Public keys only
Sessions	D1 Database	Signed JWTs
Private keys (local mode)	Never stored server-side	PRF-encrypted locally
Client key shares (MPC mode)	D1 Database	PRF-encrypted
Server key shares (MPC mode)	Durable Object	Isolated per-key storage

Key Storage Model

Stratos Vault supports two key management modes:

Mode	Client Storage	Server Storage	Use Case
Local (PRF-only)	Full key encrypted with PRF	None - no server-side keys	Simple deployments
MPC (Threshold)	Client share encrypted with PRF	Server share in Durable Object	Enhanced security

In both modes:

No seed phrases are ever generated or stored
No plaintext keys are persisted to disk
Keys/shares exist in memory only during signing, then zeroed

Attack Resistance

Phishing

Traditional: User enters credentials on fake site → Attacker captures credentials

Stratos Vault: Passkey is origin-bound → Fake site gets cryptographic error, not credentials

Credential Stuffing

Traditional: Attacker tries leaked passwords → Some accounts compromised

Stratos Vault: No passwords to stuff → Attack vector eliminated

Server Breach

Traditional: Attacker gets encrypted keys → Offline brute-force possible

Stratos Vault (Local mode): Server has only public keys → No private material to steal

Stratos Vault (MPC mode): Server holds only one key share → Useless without client share and PRF authentication

Man-in-the-Middle

Traditional: Attacker intercepts session → Can replay or hijack

Stratos Vault: Challenge-response with hardware signing → Replay impossible

Device Theft

Traditional: Seed phrase on paper stolen → All funds lost

Stratos Vault: Passkey requires biometric → Thief can't authenticate

Compliance Considerations

Stratos Vault's architecture supports common compliance requirements:

Requirement	How Stratos Vault Helps
MFA	Passkeys are inherently multi-factor (possession + biometric)
Audit Trail	All admin actions logged with timestamps
Access Control	Role-based permissions (user/admin)
Data Residency	Deploy in specific Cloudflare regions
Key Management	Local mode: keys never leave device. MPC mode: threshold signing with no single point of compromise

Canton Network for Regulated Assets

For regulated financial instruments, Canton Network provides:

Privacy - Data visible only to authorized parties
Auditability - Complete transaction history for regulators
Determinism - Predictable smart contract execution
Interoperability - Controlled sharing between institutions

Security Best Practices

For Administrators

Use hardware security keys for admin accounts
Limit admin count to essential personnel
Review access logs regularly
Configure appropriate session timeouts
Use dedicated RPC endpoints (not public nodes)

For Users

Register passkeys on multiple devices for backup
Use platform authenticators (device biometric) or security keys
Verify transaction details before signing
Report suspicious activity immediately

Next Steps

MPC Architecture - Deep dive into MPC signing protocols
Platform Overview - Full platform capabilities
Canton Integration - Regulated smart contracts
Deployment Model - How instances are deployed

Security Architecture ​

Overview ​

WebAuthn Authentication ​

How It Works ​

Security Properties ​

Key Derivation ​

Key Properties ​

MPC Signing (Multi-Party Computation) ​

Architecture ​

Supported Protocols ​

Lindell 2PC-ECDSA (secp256k1) ​

FROST 2-of-2 (ed25519) ​

Security Properties ​

Migration from Local to MPC ​

Configuration ​

Session Security ​

JWT Token Management ​

Session Lifecycle ​

Data Protection ​

Database Isolation ​

Key Storage Model ​

Attack Resistance ​

Phishing ​

Credential Stuffing ​

Server Breach ​

Man-in-the-Middle ​

Device Theft ​

Compliance Considerations ​

Canton Network for Regulated Assets ​

Security Best Practices ​

For Administrators ​

For Users ​

Next Steps ​

Security Architecture

Overview

WebAuthn Authentication

How It Works

Security Properties

Key Derivation

Key Properties

MPC Signing (Multi-Party Computation)

Architecture

Supported Protocols

Lindell 2PC-ECDSA (secp256k1)

FROST 2-of-2 (ed25519)

Security Properties

Migration from Local to MPC

Configuration

Session Security

JWT Token Management

Session Lifecycle

Data Protection

Database Isolation

Key Storage Model

Attack Resistance

Phishing

Credential Stuffing

Server Breach

Man-in-the-Middle

Device Theft

Compliance Considerations

Canton Network for Regulated Assets

Security Best Practices

For Administrators

For Users

Next Steps