10 — Encryption & Key Management
Confidentiality in transit, at rest, and (optionally) end-to-end. Builds on ADR-0014 (envelope encryption). The standout property: per-tenant keys enable crypto-shredding — instant, provable erasure by deleting a key.
1. In transit
- TLS 1.3 for all external traffic; HSTS; modern cipher policy; certs via cert-manager + ACME (auto-rotated, platform/09).
- mTLS between internal services (zero trust, platform/02).
- Presigned transfers ride the object store’s TLS; URLs themselves are short-lived capabilities (06).
2. At rest — the key hierarchy
flowchart TB
classDef k fill:#fecaca,stroke:#b91c1c,color:#111827;
classDef t fill:#fde68a,stroke:#b45309,color:#111827;
classDef d fill:#bbf7d0,stroke:#15803d,color:#111827;
root["Root KEK — in KMS/HSM (never exported)"]:::k
root --> tkek["Per-TENANT KEK (wrapped by root)"]:::t
tkek --> dek["Per-object DEK (random; wrapped by tenant KEK)"]:::d
dek --> data["encrypted chunks (storage/02, AES-256-GCM)"]:::d
byok["BYOK/HYOK: tenant KEK = customer's KMS key"]:::t -.-> tkek
- Envelope encryption (ADR-0014): a root KEK in KMS/HSM (never leaves) wraps per-tenant KEKs, which wrap per-object DEKs.
- Per-tenant keys = cryptographic isolation even within the shared (pool) database — a rogue DBA reading raw rows/backups gets ciphertext they can’t decrypt (05).
- etcd Kubernetes Secrets encrypted via a KMS provider; backups encrypted with separate keys (platform/12).
3. Crypto-shredding (the elegant erasure primitive)
Because each tenant (and optionally each object) has its own key, erasure = key deletion: destroy the tenant KEK and all its ciphertext — live, replicated, and in backups — becomes permanently unrecoverable, instantly. This is how BitVault implements:
- GDPR right-to-erasure (11) without hunting every replica/backup,
- tenant offboarding (05 §7),
- BYOK kill-switch (customer revokes their key → we lose access, by design).
This is the single highest-leverage security primitive in the design: it turns “delete data everywhere” (hard, unverifiable) into “delete one key” (easy, provable).
4. Customer-managed keys (BYOK / HYOK)
- BYOK: the tenant KEK is a key in the customer’s KMS — they can rotate/revoke it, cutting our access on demand (product/02 E1).
- HYOK: the key never leaves the customer’s HSM; unwrap happens via their endpoint — stricter, with an availability coupling to that endpoint.
5. End-to-end encryption (opt-in, zero-knowledge)
The Private Vaults tier (product/01 §4) encrypts client-side; the server stores only ciphertext and cannot read it. Sharing re-wraps the per-file key per recipient’s public key. Honest tradeoff (revisits NG3): E2E disables server-side search, previews, dedup, and Functions on that data — so it’s opt-in, not default.
6. Crypto agility
Algorithm identifiers are stored per object (e.g. BLAKE3 vs SHA-256 mode, ADR-0016), so a hash/cipher migration is a lazy/background re-encrypt, not a flag day — including a future post-quantum transition. Integrity hashing (BLAKE3, storage/04) is distinct from confidentiality encryption; both apply.
7. Threats addressed & residual
| Threat | Control | Residual |
|---|---|---|
| Network eavesdrop / MITM | TLS 1.3 + mTLS + content-hash verify | very low |
| Rogue DBA / stolen backup | per-tenant envelope encryption | low |
| Incomplete erasure | crypto-shredding (key deletion) | very low |
| Operator can read data | BYOK/HYOK or E2E for zero-knowledge | tier-dependent |
| Key compromise | KMS, no export, rotation, per-tenant blast radius | low |
References
- NIST envelope encryption / KMS patterns: https://csrc.nist.gov/projects/key-management
- Crypto-shredding: https://en.wikipedia.org/wiki/Crypto-shredding
- TLS 1.3 (RFC 8446): https://www.rfc-editor.org/rfc/rfc8446