The model in one sentence
Each chip stores a 32-byte vault wrap key inside an authenticated encrypted file. Every credential we hold for you is encrypted under that key. To decrypt anything, the chip must physically be in the reader field, complete a mutual AES-128 authentication, and the server must read the wrap key out. No chip in field, no plaintext.
Layered defence
The chip itself (NXP MIFARE DESFire EV3)
Tamper-resistant secure element from NXP, one of the leading manufacturers of NFC and contactless payment chips worldwide. AES-128 mutual authentication with the server using DESFire EV2 authentication mode. NXP-signed originality certificate so we can verify the silicon is genuine. Without successful authentication, the chip refuses every operation.
Chip-bound encryption (zero-knowledge)
Per-credential keys derived via HKDF-SHA256 from the chip's vault wrap key. ChaCha20-Poly1305 AEAD, a modern encryption standard used by Cloudflare, Google services, and the Signal protocol. Associated data binding (user, site, credential id) prevents ciphertext-swap attacks. The server stores ciphertext only.
Transport & session security
TLS 1.3, the current internet security standard, with HSTS preload. Strict Content Security Policy, Cross-Origin Opener Policy, and Cross-Origin Resource Policy headers. SameSite=Strict cookies on operator sessions. Per-IP rate limits on authentication, lockout after repeated failed login attempts. All session tokens are SHA-256 hashed at rest.
Operations & recovery
Three independent recovery paths so you can never be permanently locked out: a backup chip, a printable Shamir-split key, and a multi-step identity verification process. Every destructive action requires multi-operator approval. Encrypted backups protected with an age private key stored on a separate isolated system.
Threat model
We are honest about what this technology can and cannot defend against.
What we defend against
- Phishing. Passkeys are origin-bound; phishing fails by construction.
- Stolen credentials. Each site has a unique, server-generated credential. There is no master password to crack.
- Server compromise. The server holds ciphertext. Without the chip, an attacker reads garbage.
- Network eavesdropping. TLS 1.3 and HSTS preload across all endpoints.
- Stolen device. Every fresh sign-in requires a chip tap.
- Backup leakage. Backups are encrypted at rest with an age public key whose private half lives on a separate isolated system.
- Insider attack. Our operators cannot decrypt vaults. Recovery actions require multi-operator approval and a full audit log.
What we don't defend against
- Physical removal of the chip. Your body, your decision.
- Coercion. If someone forces you to scan, the system cannot tell.
- Compromise of your device while the chip is tapped. The window is bounded to the moment of tap.
- Targeted state-level adversaries with arbitrary code execution on your unlocked device. No consumer authenticator defends against this.
Cryptographic primitives
We are transparent about every algorithm we use. Each encrypted blob carries a one-byte version so we can rotate algorithms without disruption.
| Use | Algorithm |
|---|---|
| Chip mutual authentication | AES-128 (NXP DESFire EV3, EV2 mode) |
| Vault key on chip | 32 bytes random, stored in an authenticated file |
| Per-credential encryption | ChaCha20-Poly1305 AEAD with HKDF-SHA256 |
| FIDO assertion signing | ECDSA P-256 with SHA-256 (FIDO2 and WebAuthn, COSE ES256) |
| Chip originality verification | ECDSA secp224r1, NXP-signed at manufacture |
| Recovery key sharing | Shamir Secret Sharing |
| Operator passwords | PBKDF2-HMAC-SHA256, OWASP-recommended iteration count |
| Backup at rest | age (X25519 key exchange, ChaCha20-Poly1305 symmetric) |
| Constant-time comparison | Standard library constant-time compare |
| Random number generation | OS-provided CSPRNG |
| TLS | TLS 1.3 with HSTS preload |
Operator panel hardening
Our customer service staff sign in to a separate panel with its own authentication model. They cannot decrypt customer vaults. They can review state, approve recovery requests, and trigger destructive actions only with peer approval.
- Our staff cannot read your data, period.
- Any sensitive action requires multiple staff approvals.
- Every action is logged with a full audit trail.
- Staff sessions automatically expire and lock after failed attempts.
For the full operator security model, see the technical architecture page.