Security

We assume we're the weak point

AmberKey is built so that trusting us is never required: not to keep your secrets, not to recover them, not even to stay in business. This page explains why, twice: first in plain language for everyone, then in technical depth for those who want to check our work. Every claim comes with its honest limit.

In plain terms · For the technically minded

In plain terms

The four promises underneath everything else. If you read nothing else on this page, read these.

No one here can read your vault

Your information is scrambled on your own device before it reaches us. We hold locked boxes and no keys. Not "we promise not to peek", we genuinely cannot.

No single person can open it

Your key is split across the people you choose. It takes several of them, together, so no one person, and no thief with one card, can get in.

Your access never depends on us

The cards, your saved file, and a free offline tool are all your family needs, and that tool is mirrored in several independent places. AmberKey is a convenience on top, never the thing standing between them and the vault.

You’ll always know if someone tries

Any attempt to recover early alerts you everywhere, then waits days before anything can happen. A single check-in from you stops it cold.

Your questions, answered honestly

The real questions people ask, each with the reassuring part and the honest catch.

Could my family open the vault while I’m still alive, or be pressured into it?

Not quietly, and not alone. It takes several of the people you chose, acting together, and only after a waiting period during which you’re alerted on every device. One tap from you stops it. Honest limit: if everyone you trusted colludes and you can’t respond for a week or more, they can succeed. No system can protect you from all the people you chose at once.

What if someone loses a card, or a card is stolen?

One card on its own is useless: it reveals nothing and names nobody. We check in quarterly to catch a lost card early, and you can reprint the whole set with one button, which instantly makes the old cards worthless. Honest limit: if a thief gathers enough cards to meet your threshold, and knows where your bundle is, that defeats it. Spread your cards among people who aren’t all in one place.

If hackers break into AmberKey’s servers, can they read my stuff?

No. Everything is scrambled on your own device before it ever reaches us, and we never hold the key. A break-in finds only locked boxes and no keys. Honest limit: an attacker could see who’s in your circle and send fake reminder emails, but they still can’t open the vault without your family’s physical cards.

What if AmberKey goes out of business?

Your family still gets in. The printed cards, your saved bundle file, and a free tool that works on any computer with no internet are all they need, and that tool is mirrored in several places that don’t depend on us. Honest limit: the conveniences (reminders, coordination) stop, so recovery becomes more manual. It gets slower, never impossible.

What if I’m in hospital or off-grid and miss check-ins? Will it release by mistake?

No, not from silence alone. Missing check-ins starts a slow series of reminders (email, then text, then a nudge to a trusted contact), each with days of grace, before your circle can even begin. Then there’s still a waiting period on top. Even at the fastest settings that’s close to two months of chances to say “I’m still here.” One check-in resets everything.

What if my own computer or phone has a virus?

This is the one risk we can’t fully solve, and we won’t pretend otherwise: if your device is compromised while you’re actually using your secrets, malware can see what you see. We shrink the window as much as possible. Best practice: set up on a device you trust, and do any real recovery on a clean, offline computer.

Could a court force AmberKey to hand over my secrets?

We can only hand over what we have, and we don’t have your secrets or the key. A court can get the same limited routing information a hacker could, and it can also order the people holding your cards directly, because the cards are physical objects. But there’s nothing on our servers that opens your vault.

So what CAN AmberKey actually see about me?

The bare minimum needed to send reminders: that you have a vault, your email and phone, your circle members’ contact details and which group they’re in, and your check-in timing. Not their names, not your secrets, not what’s in your vault. We’d rather tell you this plainly than pretend we’re invisible.

For the technically minded

The architecture, the standards, the full threat matrix, and an invitation to break it. The canonical engineering document lives in the repository: spec/threat-model.md.

The blind server

All encryption and key handling happens on your devices, in open-source code anyone can read and check (written in Rust, a language chosen for memory safety). The vault master key is an age X25519 identity generated client-side at onboarding; your continuity bundle is a single age-encrypted file. The key is then split with SLIP-39 (Shamir's secret sharing with group thresholds) across your recovery circle's printed cards. The scheme is information-theoretic: below the threshold, the cards reveal nothing, not a weaker key, nothing.

Our servers store exactly four kinds of things:

Ciphertext: your encrypted continuity bundles, versioned.
Liveness state: check-in schedules and escalation position.
Contact routing: how to reach you and your circle (emails, phone numbers, card IDs).
Schedules and audit logs: timers, ceremony state, an owner-visible append-only log.

No keys. No shares. No plaintext. Not "we promise not to look", there is nothing to look at.

Threat matrix

Every threat lists an honest residual risk. A security page without residual risks is marketing; this is the summary of our engineering document.

Threat	Mitigation	Honest residual risk
Premature or coerced reconstruction Circle members collude, or are pressured, to open the vault while the owner is alive.	Group thresholds mean no single person, and no single household, can reconstruct. Every ceremony notifies the owner on all channels and holds a 3–14 day veto window; one owner check-in cancels it and resets liveness. A duress PIN lets a coerced owner check in while silently flagging the account.	A quorum that jointly decides to betray the owner, and an owner unable to respond during the veto window, can succeed. Secret sharing distributes trust; it cannot manufacture it. Choose the circle accordingly.
Share loss or theft A printed card is lost, stolen, destroyed, or photographed.	One card below the threshold carries zero usable information about the key (Shamir security guarantee, per SLIP-39). Cards carry no owner name, holder name, or hint of other holders. Quarterly health-check attestations detect loss early; one-button re-share regenerates all cards and revokes the old set.	Enough simultaneous thefts to reach a threshold (plus knowledge of whose cards to steal and where the bundle is) defeats the scheme. Loss of too many cards without re-sharing can also make recovery impossible; health checks exist to catch this while the owner can still act.
Provider compromise An attacker fully controls AmberKey infrastructure.	The server is blind: it stores only ciphertext, liveness state, contact routing, and schedules. No keys, no shares, no plaintext. There is nothing to exfiltrate that decrypts anything. All cryptography runs client-side in an open-source core.	A breach exposes metadata (see below) and could send false notifications or tamper with liveness timing. It cannot read the vault or shorten the cryptographic path to it. Reconstruction still requires the physical cards.
Provider death or bankruptcy AmberKey shuts down, is acquired and gutted, or simply disappears.	Recovery never depends on us: printed cards + the owner’s bundle copy + the open-source offline tool (mirrored on GitHub, Codeberg, Software Heritage, Internet Archive) are sufficient. Standard formats only (SLIP-39, age, tar). ToS commits to a 12-month wind-down with conversion to a fully offline flow.	The convenience layer dies with us: check-ins, notifications, and ceremony coordination become manual. Recovery gets slower and more manual, never impossible. An owner who ignored bundle-export nags could hold a stale packet.
False triggers Hospitalization, travel off-grid, or lost devices make a living owner look dead.	The escalation ladder is slow by design: base interval 30/60/90 days, then email, SMS, and a trusted-contact query, each with a 7-day grace period, before the circle can even initiate. The ceremony then adds its own veto window, and any check-in resets everything.	An owner unreachable for the full ladder plus the veto window (roughly 7+ weeks at the shortest settings) whose circle proceeds in good faith will have the vault opened. That is the designed trade-off against the opposite failure: a real death never releasing anything.
Device compromise Malware on the owner’s computer or phone during setup or use.	Client-side crypto cannot protect against a compromised client, and we will not pretend otherwise. We reduce the window: secrets exist in plaintext only during explicit operations, the web app ships a locked-down CSP with no external script origins, and the recovery tool is a single auditable file usable on a clean, offline machine.	A fully compromised device during onboarding or bundle editing can capture everything it sees. This is the strongest practical attack on AmberKey, as it is on every end-to-end encrypted system. Use a trusted device for setup; use a clean machine for recovery.
Legal seizure / subpoena A court compels AmberKey to hand over what it has.	We can only produce what we hold: ciphertext, contact-routing records, liveness timestamps, and audit logs. We cannot decrypt the vault or reconstruct the key. The shares exist only on paper, in your circle’s hands.	Metadata is producible (who is in a circle, when checks happened). Courts can also compel circle members directly: cards are physical evidence like any other, and no protocol prevents a lawful order to the humans who hold them.
Metadata exposure What the routing data itself reveals, to us or to anyone who obtains it.	We minimize on purpose: circle routing stores contact handles, card IDs, and group assignments. Member names, share words, and packet contents never appear. Cards are anonymous. Health checks transmit only a card ID and two words’ worth of confirmation, never the mnemonic.	The existence of your vault, your circle’s size and contact points, and your check-in rhythm are visible to us; routing requires it. Treat that as known-to-provider. This is documented honestly rather than wished away; the canonical threat model in the repo details every stored field.

Open formats, on principle

No custom cryptography, no proprietary share variants, ever. The vault key is split with standard SLIP-39; the bundle is standard age v1 encryption over a standard tar archive. Any conforming SLIP-39 implementation can reconstruct the key; any conforming age implementation can then decrypt the bundle. Our formats are specified in public documents (bundle-format, recovery, share-card) and decryption of every published bundle version remains supported forever.

The recovery tool is reproducibly built and minisign-signed, so anyone can verify that the file in their hands is the file we published. See the verification instructions.

Audit us

The crypto core, the recovery tool, and the specifications are open source (Apache-2.0). We want adversarial eyes on all of it. Report vulnerabilities to security@amberkey.app; disclosure process and scope are in SECURITY.md. If you find a way for us, or anyone, to read a vault without the circle's cards, we very much want to know before anyone else does.