Skip to main content
abadge has four explicit trust tiers. The capability matrix flows directly from these boundaries.

​
Tier overview

​
Tier 1 — Local daemon

vaultd is the primary trust boundary for zero-knowledge operations. What it protects:
  • Unlocked root keys (held in process memory only)
  • Per-item DEK decryption
  • Secret injection into spawned subprocesses
Attack surface:
  • Unix domain socket (0600 permissions, owner-only, inside a 0700 directory)
  • Process memory (mitigated by a 15-minute inactivity auto-lock that zeroes key buffers with Uint8Array.fill(0); best-effort only — the JS runtime does not guarantee every copy is erased)
  • Swap or core dumps (not mitigated: abadge does not mlock key pages)
Honest limitation. A local attacker with root or sudo access can read process memory. The daemon protects against network attackers and server compromise — not local root.

​
Tier 2 — Browser

The browser holds the derived root key in JavaScript memory for the session. Additional attack surface beyond the daemon:
  • XSS — if achieved, the attacker can steal the unlocked root key. Catastrophic.
  • Malicious JS bundle — if the server ships compromised code it can exfiltrate the key.
  • Browser extensions can read page memory.
  • Tab persistence — the key is lost on tab close (no localStorage or IndexedDB).
Honest limitation. The browser is a convenience surface. Users who need the strongest guarantees should use the CLI plus daemon.

​
Tier 3 — Server (zero-knowledge for ZK items)

The server stores only ciphertext, wrapped keys, salts, and KDF parameters for ZK items. What the server cannot do:
  • Decrypt ZK item ciphertext
  • Derive the user’s root key or KEK
  • Recover a profile without the master password or recovery key
What the server can do:
  • Decrypt server-managed items (by design)
  • See item IDs, storage modes, timestamps, and sizes for all items
  • Delete or corrupt ciphertext (availability attack, not confidentiality)
  • Serve malicious JS to browser clients (see Tier 2)
  • Observe access patterns
What a full server breach exposes:
  • All server-managed item plaintext (assuming ENCRYPTION_KEY is also obtained)
  • ZK item ciphertext (useless without root keys)
  • Wrapped root keys (useless without master passwords)
  • KDF parameters (enables offline brute-force of weak master passwords)
  • Access patterns and audit metadata

​
Tier 4 — Remote agents

Remote agents (cloud workers, CI runners, webhook handlers) authenticate with short-lived Ed25519 keypair sessions (abs_) and can only access server-managed items with read permissions. What a compromised remote agent exposes:
  • Only the server-managed items it has permissions for
  • Only until the permission expires or is revoked
What it cannot access:
  • Any zero-knowledge item (no decryption capability)
  • Any item without an explicit grant

​
Threats and mitigations

​
Server-breach impact by storage mode

​
Explicit non-goals (v1)

  • Protection against local root or admin attackers
  • Hardware security module integration
  • Secure multi-party computation for shared secrets
  • Organization-level vault cryptography
  • Tamper-evident audit log chaining
  • Protection against compromised build/deploy pipelines serving malicious JS