The evidence vault

Some things should take more than one person to open.

Sealed raw evidence takes more than one key to open — not an admin's, not one person's under a court order, not ours. It takes a quorum of trustees turning their keys together, and every attempt, opened or refused, goes on a signed, tamper-evident record. Try it below with real cryptography.

Break the glass yourself ↓ Why it's built this way

Three ideas do all the work

Sealed

A Canary's sealed snapshots are encrypted to a key it doesn't hold — it can't read them back.

Quorum

It takes a set number of trustees, signing together, to authorize opening it. One approval doesn't.

On the record

Every attempt — granted or denied — is signed into an append-only log where any later edit shows.
What "break-glass" means
01what break-glass means

An emergency door that takes several keys at once.

“Break-glass” is how you reach sealed raw evidence when there's a real reason — an insurance claim, an incident. It opens only when a quorum of trustees approve together, and breaking it is loud and logged.

In plain terms: think of a bank's safe-deposit box that needs two keys turned at once — yours and the bank's. Sealed Canary evidence is like that, but you pick how many keys and who holds them. The camera can drop things into the box; it has no key to take anything back out. And every time someone tries the door, the attempt is written down and signed — success or failure.

Why that's different — and useful to you: “we promise not to look” is a policy, and policies bend under pressure — a rogue employee, a breach, a subpoena aimed at one person. Here, with a quorum of two or more, no single key opens the vault. The safeguard is arithmetic, not trust.

02who holds the keys

First — where do the keys even come from?

A quorum only means something if you know whose keys count. So before anything is sealed, you choose your trustees — the people or roles you'd trust with a hard call — and each one brings their own key. There's no override key, and we're not one of the holders.

In plain terms: each trustee makes a key pair on their own device and gives you only the public half (a fingerprint). You pin the fingerprints and pick the threshold — say 2 of 3. From then on only those keys can approve; a stranger's key does nothing.

Your trustee roster

real keys, made here

Each fingerprint below is a genuine Ed25519 public key generated in your browser — the very keys the trustees sign with in the demo just below.

policy: — of 3 · pinning keys…

🔒 The secret half of each key never leaves its trustee — the vault stores only the public halves.

setting the policy — one line, on your own kernelshell · securaCV
# pin the trustees' PUBLIC keys and pick the threshold (2 of 3)
break_glass policy set --threshold 2 \\
  --trustee avery:<avery-ed25519-pubkey> \\
  --trustee bailey:<bailey-ed25519-pubkey> \\
  --trustee cameron:<cameron-ed25519-pubkey>

That's the whole enrollment. Changing it later is itself signed into the record.

Why that matters: because the keyholders are yours, no one upstream — not the maker, not a cloud account, not a lone admin — is quietly on the list. You can even make one trustee a lawyer or a friend in another city, so a single local pressure point can't turn every key at once.

03break the glass

Try it: gather the trustees, or fail to force it open.

It takes two of your three trustees to open this vault. Each “Approve” is a genuine Ed25519 signature by a key enrolled above, counted by the same rule the kernel uses. Try forcing it open with too few.

Break-glass request

real Ed25519 quorum

preparing request…

cam-porch-0007 · sealed evidence
purpose: insurance claim · encrypted, device can't read it back
🔒 sealed
0 of 2 approvals

—

the receipt log — every attempt, signed & append-only
No attempts yet. Approve, then break the glass — or try to force it.
what the vault counts, in your browserJavaScript · this page
// count DISTINCT trustee keys carrying a valid approval
function countDistinct(approvals) {
  const keys = new Set();
  for (const a of approvals)
    if (a.valid) keys.add(a.keyHex);
  return keys.size;              // granted iff >= n
}
the same rule, in the kernelRust · src/break_glass/core.rs
// re-derived at the unseal gate — never trusts a recorded outcome,
// so a device-key holder can't forge Granted with too few approvals
for approval in approvals {
    if !verify_approval(&t.public_key, request_hash, &approval.signature) { continue; }
    distinct.insert(t.public_key);   // dedup on the KEY
}
distinct.len() >= policy.n            // → Granted

Same rule, both sides. Deduping on the key means one trustee can't fill two slots by approving twice, and a stolen device key can't mint a grant with zero real approvals — the kernel re-derives the quorum from the signatures every time, exactly like the demo above.

04the guardrails

Six rules that close the single-person door.

Each one closes a loophole an attacker — or a well-meaning insider — would reach for.

No solo access

The old single-approval code path is deprecated and now returns an error. The quorum is the only way through — there is no self-service door for raw evidence.

defeats · a rogue admin acting alone

A grant is re-checked, not trusted

The kernel re-derives the quorum from the trustees' signatures at the moment of unsealing. A validly device-signed “granted” is refused if the real approvals aren't there.

defeats · a stolen device / signing key

Single-use

Each authorization mints a token with a random nonce that's burned before any plaintext exists. Replaying the same token is refused.

defeats · replay & token re-use

Expires fast

A token is bound to a specific envelope, ruleset, and a 10-minute time bucket. It goes stale almost immediately — no stockpiling access for later.

defeats · a hoarded, reusable key

Always receipted

Every decision — granted or denied — is signed into an append-only, hash-chained log. Opening the vault is never quiet, and erasing an attempt would break the chain.

defeats · silent, deniable access

Not even us

The makers hold no key to your vault. The trustees are whoever you choose; the quorum is yours to set. We can't be compelled to open what we hold no key to.

defeats · a subpoena aimed at the vendor

05the honest details

How it actually works under the hood — no hand-waving.

For makers: the seal, the trustees, and why the key is never split

The key isn't split into pieces. This isn't “chop the password into shards” (Shamir) or a fancy joint signature. It's simpler and sturdier: several trustees each sign an approval, and enough distinct valid signatures authorize a single-use token that unlocks the vault. The vault's own encryption key is never divided — it's held by the kernel and wrapped under the device's master key.

  • The seal — each sealed object is encrypted with ChaCha20-Poly1305 using a fresh random key, which is then wrapped under the device's master key. Tampering with a single header byte breaks the seal.
  • Trustees & operator — trustees hold their own Ed25519 signing keys (which never leave them); an operator runs the request → approve → authorize → unseal flow but can't approve on anyone's behalf.
  • The device's own snapshots go a step further: they're sealed to an operator's public key, so the Canary is write-only — it stores only the public half and cannot decrypt what it wrote. Opening happens off-device.

Status, honestly: the classical seal (ChaCha20-Poly1305) and the N-of-M quorum are implemented and tested. A post-quantum mode (ML-KEM-768) exists behind a build flag and is optional/experimental. And the demo above is real Ed25519 in your browser — the bulk encryption step is illustrated, because browsers don't expose that exact cipher (the live lab page says so too).

Not “we promise not to peek.” Peeking takes a quorum.

One person under pressure can break a promise. Opening this takes more keys than one hand holds, and every attempt lands in a record you can check.

See how the signing works → Open the full lab demo