KeepsakeCan a passkey or a YubiKey unlock an encrypted document vault, rather than just log me in?
Can a passkey or a YubiKey unlock an encrypted document vault, rather than just log me in?
Only if the app derives the encryption key from the credential. WebAuthn's PRF extension returns 32 bytes that the same key and salt always reproduce and no other key can; run those through HKDF and they unwrap the master key, with no server asked at all. A key that only signs a login gates a door, not the documents. Keep a password or recovery phrase behind it — hardware gets lost.
"Supports security keys" is one of those lines that means two completely different things depending on where the encryption lives.
In most products it means the key gates a login. You touch the key, the key signs a challenge, a server checks the signature and then sends you your files — files it was holding in a form it could read the whole time. The hardware protects the door. It does not protect the documents, because the documents were never locked to the person walking through it.
In Keepsake it means the key holds a piece of the encryption. The authenticator produces a secret only it can produce, that secret unwraps the master key, and no server is consulted at any point — because there is no server in this product to consult. If the key is not present, the envelope stays shut, and there is nobody who can be persuaded to open it.
What actually happens when you touch the key
Four steps, and it is worth reading them because the third is the one that makes this different from a login:
- The app asks your authenticator — a YubiKey, a phone, or the passkey store built into your laptop — to evaluate a pseudo-random function over a fixed salt. A browser reaches it through WebAuthn's PRF extension; the Windows app asks the key for it directly over CTAP2, where the same function is called hmac-secret.
- The key answers with 32 bytes. The same key and the same salt always give the same 32 bytes; no other key can produce them; and they exist only for the moment after the prompt was answered.
- Those bytes go through HKDF together with the id of the vault you are opening, and the result is used to unwrap the master key from a slot in the keyring. This is the step that makes it encryption rather than permission.
- The vault opens. Nothing was sent anywhere, nothing was checked by anyone, and the 32 bytes are wiped.
Because the vault id rides in step 3, one key can hold slots on several vaults without any of them sharing a secret — and a key enrolled on your vault is useless against somebody else's, even if they have the same model of key and the same salt.
What a passkey does not do
The complete list, taken from the same file the apps read:
- It is not a login. No server is asked whether you may proceed, because no server has anything to do with it.
- The secret is not stored. It is not synced, not written down and not recoverable from the vault file. It exists for the moment it is used.
- It is never the only way in. Enrolling one is refused until a password or a recovery phrase exists, and removing the last remaining way in is refused outright.
- Enrolling on one device does not enrol it everywhere. Windows Hello and Android unlock are tied to the device that holds them; a passkey or a security key travels, and can be enrolled on the copy of the vault on each device.
- Keepsake never sees a fingerprint, a face or the private key. It receives a fixed-length secret from hardware that has already decided, and it can prove nothing about you beyond that the hardware said yes.
Why it refuses to be your only key
Hardware is lost. It is left in a drawer in another country, dropped in a sink, revoked by a firmware update, or simply stops being carried. A vault whose only key is one of those is not protected by hardware — it has a countdown on it.
So the rule is enforced in the code, on all three platforms, in the same words: a key a device holds is never the only way into a vault. Enrolling is refused while there is no password and no recovery phrase, and it is refused before the prompt appears rather than after you have answered it. Removing a key is refused when it is the last thing standing between you and a file nobody can open.
That is the same rule from both ends, and it applies to the password too: the last way in is the last way in, whichever kind it happens to be.
Where each kind of hardware works
| Method | Where | Travels? |
|---|---|---|
| Passkey or security key (WebAuthn PRF) | The web app, in Chrome, Edge or Safari on a recent version | Yes — the same key can be enrolled on the vault on each device |
| Security key (CTAP2 hmac-secret) | The Windows app, on Windows 10 1903 or later, with the key plugged in or held to the reader | Yes — and it is the same credential the web app enrolled, because both derive the wrapping key the same way |
| Windows Hello | The Windows app, on a machine with a TPM and an enrolled credential | No — the key lives in that machine's TPM |
| Fingerprint or face unlock | The Android app, through the Android Keystore | No — the key never leaves that phone's Keystore |
All four reach the same kind of slot in the same keyring, and all four are governed by the same file. What differs is only what the hardware is and whether it can be carried. The one place the browser and the desktop could have silently disagreed is the salt: a browser hashes it before handing it to the authenticator, so the Windows app reproduces that hash rather than sending the salt raw — otherwise the same key would produce different bytes on the two surfaces, and a vault enrolled in one would refuse to open in the other while looking exactly like broken hardware.
If your browser or key says no
Two refusals are worth recognising, because they are not the same problem.
"This browser has no passkey support at all." Nothing was attempted. Your password still opens the vault, and always will.
"This browser or this key cannot do what Keepsake needs." The passkey worked, but the PRF extension was not available — so the key can prove who you are and cannot produce the secret that opens anything. That is not a partial success worth accepting: a credential that cannot derive the key is a credential that unlocks nothing, and pretending otherwise would mean putting the master key somewhere the login could reach it. Recent Chrome, Edge and Safari support PRF with most modern authenticators.
Step by step
- Open the web app or the Windows app and unlock your vault. Enrolling requires the vault to be open — the master key has to exist before anything can wrap it. This is also why enrolling cannot be done from the lock screen.
- Make sure you have a password or a Recovery Kit. You will have both already unless you deliberately removed one. If neither exists, the add button is disabled with the reason, before any prompt appears.
- Settings → Passkeys and security keys → Add a passkey (in the Windows app: Settings → Vault Security → Add a security key). Name the key first — "YubiKey", "this laptop" — so a list of three is still readable in a year. Then touch the key or answer the prompt.
- Lock the vault and try it. A new line appears on the unlock screen: "Unlock with a passkey" in the browser, "Sign in with a security key" in the Windows app. Use it once now, while your password is fresh in your mind, rather than discovering the setup was wrong on the day you need it.
- Enrol the same key on your other devices if you want. Each device holds its own copy of the vault, so each copy needs its own slot. The same physical key produces a different secret for each vault, which is why one key can hold several without any of them opening another.
Questions
Is this the same as signing in with a passkey?
No, and the difference is the whole point. Signing in with a passkey proves your identity to a server, which then decides to hand over files it could already read. Here the key produces a secret that unwraps the encryption itself. There is no server to ask and no permission to be granted — if the key is absent, the envelope stays shut.
Can I use a YubiKey with the Windows or Android app?
On Windows, yes: Settings → Vault Security → Add a security key, and the same key that opens the vault in the browser opens it in the app. On Android, not today — the phone unlocks with the hardware it already has, the Keystore gated by fingerprint or face, and that does not travel to another device.
What happens if I lose the key?
You open the vault with your password or your Recovery Kit, exactly as before, and remove the slot the lost key was using. This is why enrolling is refused until one of those exists: the answer to a lost key must never be "your documents are gone".
Does Keepsake see my fingerprint or my face?
No. It receives a fixed-length secret from hardware that has already made its own decision. It never sees the biometric, never sees the private key, and can prove nothing about you beyond that the hardware said yes.
Can one key open two different vaults?
Yes, and neither vault can open the other. The vault id is mixed into the key derivation, so the same physical key produces a different secret for each — which is what lets a household share a key without sharing a vault.
Is the secret stored anywhere?
No. It exists for the moment the prompt is answered and is wiped afterwards. What is stored in the vault file is the credential id — a public handle that lets the browser offer the right key — and an envelope that only the derived secret opens.
Where Keepsake fits
Keepsake is our product, so read this part with that in mind. Everything above is true whether or not you use it, and most of it you can do with a folder and an afternoon.
A passkey is one more way into the same keyring every other method uses: a password, a Recovery Kit, a paired device, and on the desktop and the phone the hardware those devices already have. Adding one changes nothing about how documents are stored — see how Keepsake protects your documents for the format itself, and the encrypted vault for the rest.
What decides all of it lives in one file, shared/device-unlock.json, read by the Windows app, the Android app and the web app alike. That is why all three refuse in the same words, and why the rule that a device is never the only way in cannot be true on one platform and forgotten on another.