FIDO2 hardware key · Deniable by design
One key.
As many truths
as you carry.
VeePKey is a FIDO2 security key that holds several independent identities under one PIN pad. Enter one code and it's an ordinary authenticator. Enter another and it's a different one entirely — indistinguishable, even under inspection, from a key that only ever had one.
“Hand over your phone, or the interview doesn't happen.”
Standard FIDO2 keys were never designed for coercion. They hold one PIN and one set of credentials. If you're asked to unlock it, you either comply completely or you refuse — and refusing is itself a signal.
Journalists crossing hostile borders, human rights workers whose devices are searched at checkpoints, and anyone who has simply decided their key shouldn't reveal everything they've ever touched — all run into the same wall: a device that can only ever tell one story.
VeePKey gives it more than one. You decide, PIN by PIN, which story it tells — and the device carries no trace of the ones you didn't.
How it works
The protocol doesn't change. What sits behind it does.
VeePKey speaks standard CTAP2 / WebAuthn to your browser or OS — it registers and authenticates exactly like any FIDO2 key. The difference happens earlier, before that handshake even starts. Read how the three-layer lock actually works →
Set up to eight profiles
Each one gets its own PIN, its own resident-key store and its own retry counter. Storage for every profile — used or not — is written in an identical format, so nothing on the flash chip marks which ones actually hold data.
The PIN selects the profile
Enter a PIN and the device loads that profile's credentials into the standard FIDO2 session. A relying party sees only an ordinary authenticator with an ordinary set of passkeys — never a hint that others exist.
One PIN is a complete, honest answer
Give up a single profile and it holds up on its own — its own accounts, its own history, its own failure behaviour. There is nothing to notice, because there is nothing designed to be noticed — starting with the shell itself, which carries no branding or marking that would tell anyone this key is capable of holding more than one.
Who it's for
Built with people who already think this way.
VeePKey isn't for everyone, and it isn't trying to be. It's for people whose devices are already assumed to be interesting to someone else.
Journalists
Cross a border with the profile that holds your itinerary and your editor's contact. Leave your sources somewhere a customs officer can't find them, because there's nothing to find.
Human rights defenders
Checkpoints and confiscations are a known risk of the work. A key that only ever shows what you choose to show doesn't remove that risk — but it stops one device from ending it.
Lawyers & researchers
Carry client files, unpublished findings, or embargoed data across jurisdictions without a single unlock exposing everything else you hold.
Privacy enthusiasts
Separate identities aren't only for high-risk work. Keep work, personal and pseudonymous accounts on one key you actually enjoy using — and never have to explain the boundary between them.
Included with every key
Every key opens a vault, too.
Register a VeePKey and 5GB of encrypted storage comes with it — no account, no email, no name attached anywhere. The key is the only credential that exists. Possession of it is the only proof of access there is.
-
No registration
Plug in a FIDO2 key and the vault behind it exists. There's no sign-up form to leave a record on, because there's no form.
-
Encrypted at the edge
Files are encrypted and decrypted in your browser, never on our servers. Storage admins see ciphertext with no way to tell which key it belongs to, let alone what's in it.
-
Shared by key, revocable by nickname
Register a second FIDO2 key to the vault and give it a nickname — visible only to you, encrypted inside the vault, never on our servers. Revoke that nickname later and the key it belongs to loses access; everyone else keeps theirs.
-
Grows in 100GB blocks
Past the free 5GB, buy a block on a separate storefront that sells nothing but redemption codes. Open the vault, enter the code once, and the storage is allocated — the code is destroyed on use, so there's never a record connecting a purchase to a vault.
With every key, no account, no expiry.
One-off, paid for life. Delivered as a code, redeemed in the vault, gone after that.
Specification
Nothing in here is aspirational.
| Protocol | FIDO2 / CTAP2, WebAuthn resident & non-resident credentials, backward-compatible U2F |
| Profiles | Up to 8, each independently PIN-protected, provisioned identically whether in use or not |
| Storage per profile | Up to 25 discoverable credentials (passkeys) |
| Vault storage | 5GB included per key, client-side encrypted, no account required. Additional 100GB blocks bought as a one-off, life-of-the-vault purchase via a separate storefront, redeemed in-vault as a single-use code with no link back to the purchase |
| Vault sharing | Register additional FIDO2 keys to grant access, each given an owner-only nickname stored encrypted inside the vault. Revoke a nickname to cut off that key without affecting any other |
| Connector | USB-C only |
| Firmware | Clean-room implementation of the CTAP2 specification. Full source available for review under a commercial non-disclosure agreement |
| Body | No branding, logo, or model markings — deliberately generic so nothing about the exterior signals it holds more than one credential. No external indicator of which profile is active |
| Compatibility | Any browser, OS or relying party that supports WebAuthn — nothing to install |
For the people who'll actually check
Standards-compliant, nothing extra.
Full CTAP2 (FIDO_2_1) alongside legacy U2F for backward compatibility. The detail behind every line here is available under the source access terms below.
- Credentials — resident and non-resident, up to 25 resident credentials per profile
- PIN / UV — PIN protocols one and two, with permissioned auth tokens
- Extensions — hmac-secret, credProtect, credBlob, largeBlobKey, minPinLength
- Algorithms — ES256, EdDSA, ES384, ES512, ES256K
- Attestation — self attestation, WebAuthn "packed" format
- Management — full credential and PIN-length configuration, no biometric or vendor-specific extensions
- Not implemented — biometric enrollment, enterprise attestation, always-UV mode, any transport beyond USB
Source & audit
The source is real. Access to it isn't public.
VeePKey's firmware and hardware design exist in full, and they're available to security teams, independent auditors and press — under a commercial non-disclosure agreement, the same terms most hardware security vendors use for code protecting people who can't afford it leaking.
Request full access
Sign an NDA and we'll open the repository, the schematics, and the build pipeline to your team. Typical turnaround is under a week for security researchers and press with a verifiable affiliation.
Request NDA termsAsk a specific question first
If you don't need the whole codebase — just an answer about how one mechanism works — our source-access agent can query the current firmware and design docs directly and answer without starting the NDA process.
storage/profile_table.c.
Physical attack surface
What unfettered physical access to the hardware actually gets someone.
VeePKey runs on the ESP32-S3. This is the honest state of that chip's public security record — what's actually been demonstrated, not what we'd like to claim.
| Secure Boot v2 | Unbroken in the public record on S3 specifically. Confirmed EMFI/glitching bypasses exist against the plain ESP32 and the C3/C6 family — none has been published against S3. |
| Flash encryption | The only publicly demonstrated break of S3's flash encryption is a correlation-power-analysis technique against external QSPI flash. VeePKey uses in-package flash, which forecloses the physical access that technique depends on. |
| PIN | A firmware-enforced gate, not a value key material is derived from. Stored credentials aren't encrypted under the PIN — the PIN determines whether the firmware will act on them. A hypothetical successful flash extraction therefore bypasses it entirely: it exposes credentials directly, with no PIN brute-force standing in between. |
There is, as of the current public record, no complete, demonstrated, reproducible chain from physical possession of a properly configured VeePKey to extracted credentials. The only viable public path for an attacker is original, unpublished research — a decapsulation or micro-probing side-channel attack against in-package flash. That's a nontrivial, uncertain, five-figure-plus undertaking with no confirmed prior success against this specific target, not an off-the-shelf technique anyone can apply. It's also worth being direct about the outcome if that undertaking succeeded: because the PIN is a gate rather than a cryptographic input, a successful extraction wouldn't need to go on and brute-force a PIN — it would already have what it came for.
Read this the way we mean it
- This is meaningfully different from the plain ESP32, C3, or C6 — all of which have public, reproducible, complete bypass chains covering both secure boot and flash encryption. S3 with in-package flash currently sits outside that broken set.
- A well-resourced adversary, or research disclosed after today, could still close that gap. This assessment is a snapshot of the public record, not a guarantee that holds indefinitely.
Before you rely on this
What deniability can't promise.
A tool that oversells itself here is more dangerous than no tool at all. Read this before you decide what to trust it with.
Read this first
- Deniability protects what's on the device. It does nothing for data that's already synced, backed up, or visible in an account's activity history elsewhere.
- Legal protection around compelled disclosure varies enormously by country, and in some places refusing to disclose a key is itself an offence. This is engineering, not legal advice — talk to a lawyer who knows your jurisdiction before you're relying on this somewhere it matters.
- We can make the device's behaviour identical whether a profile is real or empty. We can't make the fact that VeePKey exists, and that VeePKey devices can hold hidden profiles, unknown to anyone who recognises the product.
- These claims aren't published as open source, so don't take them on trust either — request source access under NDA, or put a specific question to the source-access agent below, before you carry sensitive material on it.
- The vault has no account to recover. If every key registered to it is lost, its contents are gone with them — there's no password reset, and no one holds a spare key on your behalf.
- Revoking a shared key stops future access — it doesn't undo anything that key's holder already saw, copied, or downloaded before you revoked it. Revocation isn't retroactive, for the same reason no encryption scheme's is.
- Naming a shared key means that name has to live somewhere. It's encrypted inside the vault and readable only with your own key — so if your key is compromised, whoever holds it can see that other keys have access. Whether that tells them anything is up to you: a nickname like "J" or "courier" reveals nothing beyond "someone else can open this," but a name, initials, or anything else that identifies a person defeats the point of encrypting the list at all.
Stay in the loop
Get notified about what's next.
No mailing list spam, no marketing funnel — just a note about future runs, new products like vault storage codes, and priority handling on source access requests.
Contact
Something else — press, partnerships, anything.
For questions that don't fit early access or source access, reach us directly and we'll get back to you.