Technical Resources

Overview

VaultWard is built on a modern, containerized microservices architecture designed for high availability, security, and scalability. Our infrastructure follows the principle of Defense in Depth.

Frontend Layer

• Astro Static Site Minimal JavaScript attack surface with progressive enhancement
• Web Crypto API Client-side AES-256-GCM encryption using browser-native cryptography
• Zero-Knowledge All encryption/decryption happens exclusively in your browser

API Gateway

• TLS 1.3 Only Enforcing the latest security protocols with strong cipher suites
• Strict CSP Content Security Policy mitigating XSS attacks
• Rate Limiting HAProxy-based rate limiting for DoS protection

Philosophy

We can't access what we don't have. VaultWard never sees your unencrypted data or encryption keys. Your passkey-derived key never leaves your device.

Cryptographic Stack

• AES-256-GCM Authenticated encryption with unique nonces per document
• HKDF-SHA256 Key derivation from WebAuthn PRF output to derive vault keys
• X25519 Elliptic curve Diffie-Hellman for contact key exchange
• NaCl Box Authenticated public-key encryption (XSalsa20-Poly1305) for key shares

Key Hierarchy

• PRF Output Raw bytes from WebAuthn PRF extension (tied to your passkey)
• KEK Key Encryption Key derived from PRF output using HKDF
• DEK Data Encryption Key encrypted by KEK, used to encrypt vault items
• Contact Keys Per-contact X25519 keypairs for secure DEK sharing

Concept

The Dead Man's Switch is an automated inheritance protocol. If you become unresponsive for a configured period, access is transferred to your trusted contacts through a secure, multi-party cryptographic process.

Key Generation & Derivation

┌─────────────────────────────────────────────────────────────────┐
│                     YOUR PASSKEY (Hardware)                      │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│              WebAuthn PRF Extension Output (32 bytes)            │
│                   (Unique per credential + salt)                 │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼ HKDF-SHA256
┌─────────────────────────────────────────────────────────────────┐
│                    KEK - Key Encryption Key                      │
│                        (256-bit AES key)                         │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼ AES-256-GCM
┌─────────────────────────────────────────────────────────────────┐
│                    DEK - Data Encryption Key                     │
│              (Random 256-bit key, encrypted by KEK)              │
│                      Stored in database                          │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼ AES-256-GCM
┌─────────────────────────────────────────────────────────────────┐
│                     Your Encrypted Documents                     │
│                (Each with unique nonce, stored in DB)            │
└─────────────────────────────────────────────────────────────────┘

Contact Key Distribution

┌──────────────────────────────────────────────────────────────────────────┐
│                         CONTACT REGISTRATION                              │
└──────────────────────────────────────────────────────────────────────────┘

  Contact's Passkey                Your Browser (with DEK)
        │                                    │
        ▼ PRF + HKDF                         │
  ┌───────────┐                              │
  │ X25519    │                              │
  │ Private   │◄─────── kept secret          │
  │ Key       │         on contact's         │
  └───────────┘         device               │
        │                                    │
        ▼ Curve25519                         │
  ┌───────────┐         uploaded      ┌─────────────┐
  │ X25519    │ ─────────────────────►│  Database   │
  │ Public    │         to server     │  (contact   │
  │ Key       │                       │  record)    │
  └───────────┘                       └─────────────┘
                                             │
                                             ▼
                              ┌──────────────────────────┐
                              │  Your browser fetches    │
                              │  contact's public key    │
                              └──────────────────────────┘
                                             │
                                             ▼
┌──────────────────────────────────────────────────────────────────────────┐
│                         KEY SHARE CREATION                                │
│                                                                           │
│   DEK ──────►  NaCl Box Encryption  ◄────── Contact's Public Key         │
│                (X25519 + XSalsa20-Poly1305)                               │
│                        │                                                  │
│                        ▼                                                  │
│              ┌─────────────────┐                                          │
│              │ Encrypted Share │ ──────► Stored in database              │
│              │ + Ephemeral Key │         (contact_key_shares table)       │
│              │ + Nonce         │                                          │
│              └─────────────────┘                                          │
└──────────────────────────────────────────────────────────────────────────┘

Each contact gets their OWN encrypted copy of the DEK.
Only they can decrypt it with their private key.

Emergency Access Flow

1. You configure check-in interval (e.g., 30 days) and quorum threshold (e.g., 2 of 3)
2. VaultWard sends check-in reminders via email as deadline approaches
3. If you miss check-ins, contacts can log in and request emergency access
4. Each request is logged with timestamp, IP, and user agent
5. When quorum is reached (e.g., 2 contacts have requested), waiting period begins
6. Owner receives alert and can cancel by checking in at any time
7. After waiting period expires, key shares are marked as "released"
8. Contacts can now download vault and decrypt with their private keys

Emergency Release Process

┌────────────────────────────────────────────────────────────────────┐
│                    QUORUM + WAITING PERIOD MET                      │
└────────────────────────────────────────────────────────────────────┘
                                │
                                ▼
┌────────────────────────────────────────────────────────────────────┐
│              Server marks key shares as "RELEASED"                  │
│                    (status: active → released)                      │
└────────────────────────────────────────────────────────────────────┘
                                │
        ┌───────────────────────┼───────────────────────┐
        ▼                       ▼                       ▼
   ┌─────────┐            ┌─────────┐            ┌─────────┐
   │Contact 1│            │Contact 2│            │Contact 3│
   └─────────┘            └─────────┘            └─────────┘
        │                       │                       │
        ▼                       ▼                       ▼
  Download their          Download their          Download their
  encrypted share         encrypted share         encrypted share
        │                       │                       │
        ▼                       ▼                       ▼
  ┌───────────┐           ┌───────────┐           ┌───────────┐
  │ Decrypt   │           │ Decrypt   │           │ Decrypt   │
  │ with own  │           │ with own  │           │ with own  │
  │ X25519    │           │ X25519    │           │ X25519    │
  │ private   │           │ private   │           │ private   │
  │ key       │           │ key       │           │ key       │
  └───────────┘           └───────────┘           └───────────┘
        │                       │                       │
        ▼                       ▼                       ▼
      DEK                     DEK                     DEK
        │                       │                       │
        ▼                       ▼                       ▼
  Decrypt vault           Decrypt vault           Decrypt vault
  documents               documents               documents

Security Properties

• No Single Point of Failure Multiple contacts required—server, VaultWard staff, or any single contact cannot access alone
• End-to-End Encryption DEK encrypted to each contact's public key; server never sees plaintext DEK
• Owner Override Check in at any time during waiting period to cancel all pending requests
• Waiting Period Configurable delay (24 hours to 30 days) gives you time to respond to alerts
• Per-Contact Keys Each contact has unique keypair; revoking one contact doesn't affect others
• Transparency Log All requests, releases, and downloads logged with IP/timestamp for audit

Overview

VaultWard uses Ory Kratos for hardened, passwordless identity management via FIDO2/WebAuthn passkeys with PRF extension for key derivation.

Passkey Benefits

• Phishing Resistant Credentials are cryptographically bound to our domain
• No Password Database Nothing to steal in a breach—no passwords stored
• Biometric Support Use Face ID, Touch ID, or hardware security keys
• Key Derivation WebAuthn PRF extension derives encryption keys from your passkey

Contact Authentication

Trusted contacts also authenticate with passkeys. When they accept your invitation, their PRF-derived X25519 public key is registered, enabling secure end-to-end encryption of their key shares.

Attack Vectors Mitigated

• Server Compromise Attackers only get encrypted data they cannot decrypt—no plaintext or keys stored
• Database Breach All sensitive data is encrypted with keys derived from user passkeys
• Insider Threat VaultWard staff cannot access your data; quorum prevents single-actor abuse
• Contact Collusion Waiting period and owner notifications prevent unauthorized early access
• Key Theft Keys are derived from passkeys and never stored; X25519 keys are per-contact

Transparency & Audit

All emergency access attempts, key share releases, and vault downloads are logged in an immutable transparency log. You can review access history at any time, and the log provides cryptographic proof of events.