security model
Security model
The whole architecture exists to make one statement true — not as a policy promise, but by construction.
Even if Stillvault-the-company is breached or subpoenaed, we cannot produce your secrets — we never hold a key that opens them.
three planes
The vendor side is blind; the keys live on your side.
Three planes, split by a single boundary. Above it, the vendor cloud routes
and authorises but holds only ciphertext. Below it — on your side — the
broker, the consumer wrapper, the Org Identity key , and the
phone that performs the biometric decrypt and re-seal.
threat model
What it defends, what it does not, and what it trusts.
Stated plainly, with no softening. The middle list is a feature: knowing exactly what a system does not protect is how you decide whether to trust it.
Defends against
- Theft of disk, backups, or snapshots — only ciphertext at rest, on the server and in the vendor cloud.
- A compromised but idle server — no active lease means nothing to steal.
- A compromised or malicious vendor — the broker is a blind relay; it can deny service or observe metadata, but cannot read secrets.
- Silent or automated exfiltration — every release needs a human biometric, so a background attacker can't quietly pull secrets without a visible push landing on a phone.
Does not defend against
- The requesting host compromised during an active lease — plaintext is in the consumer's RAM by necessity.
- A compromised phone where the attacker can pass biometric — they have you and your finger.
- Coerced approval — you tapping approve under duress.
- Metadata exposure to the vendor — which secrets exist, access times, who approved — a residual leak with a hardening path.
Trust anchors
- The phone's secure enclave / hardware keystore (Android StrongBox / iOS Secure Enclave) — holds the passkey private key, non-exportable.
- The Org Identity key, customer-held and never given to the vendor — anchors that a per-request consumer key is authentic and not vendor-substituted.
- The requesting consumer process's RAM integrity during a lease only.
Explicitly not trusted: the vendor cloud / managed
broker , the push channel , the network .
cryptographic core
Two moves make the relay blind — even to a malicious vendor.
Move 1 — the phone decrypts and re-seals.
The phone unwraps the wrapped_DEK with the
biometric-derived key, decrypts secret_ciphertext to
plaintext, then re-seals that plaintext to the requesting consumer's
per-request ephemeral public key and returns only that. The DEK never
leaves the phone; the broker relays a blob it cannot open.
Move 2 — the consumer key is org-signed.
Otherwise the vendor could substitute its own pubkey and MITM the
seal. Per-request consumer ephemeral pubkeys are signed by your
long-term Org Identity key ; the phone verifies that
signature against the org public key pinned at enrollment. The vendor
never holds the org private key, so it cannot forge an endpoint — only
deny service or observe metadata.
store_entry {
secret_ciphertext : AEAD(DEK, secret) // never decryptable without a phone
wrapped_DEK[] : one envelope per enrolled approver
policy : { type: any-of | m-of-n, m, n }
}Why PRF, and not "the phone signs an approval": a signature proves consent, but the key holder can still decrypt — the broken model. PRF makes the biometric a required input to the decryption itself. No phone, no key.
stated plainly
The one thing it cannot protect.
The consumer must hand plaintext to, for example, a database driver — so the plaintext exists in that process's RAM at time of use. Any scheme has this property. What Stillvault does is make that window short, explicit, biometric-gated, and confined to your own consumer process.
An attacker who captures the plaintext during a lease has compromised that one secret — until the underlying credential is rotated out of band. Stillvault limits this to your consumer host during an active, approved lease: never the broker, never the vendor. Rotation is the only true remediation, and it is out of scope today.
residuals & roadmap
Known residuals, and where we're headed.
Metadata hardening is the main residual: the control plane today sees secret labels, access times, and approver identities, and the hardening path is opaque secret IDs and encrypted labels so the cloud sees only ciphertext and routing tokens. On compliance, SOC 2 Type II then ISO 27001 are on the roadmap, not achievements — we make no certification claims we have not earned.
Found something? Responsible disclosure:
security@stillvault.com .