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. AES-128 mutual authentication with the server. 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 with associated data binding (user, site, credential id) to prevent ciphertext-swap attacks. The server stores ciphertext only.
Transport & session security
TLS 1.3 with HSTS preload. Strict CSP, COOP, CORP headers. SameSite=Strict cookies on operator sessions. Per-IP rate limits on auth, lockout after 5 failed login attempts. All session tokens are SHA-256 hashed at rest.
Operations & recovery
Three independent recovery paths (backup chip, printable Shamir-split key, KYC + cooling-off + multi-operator approval). Every destructive action requires 2-of-N operator votes. Nightly encrypted backups with off-server age-encrypted private key.
Threat model
What we defend against
- Phishing. Passkeys are origin-bound; phishing fails by construction.
- Stolen credentials. Each site has a unique, server-generated credential. There's no master password to crack.
- Server compromise. The server holds ciphertext. Without the chip, an attacker reads garbage.
- Network eavesdropping. TLS 1.3, HSTS preload, certificate pinning on iOS.
- Stolen device. Every fresh sign-in requires a chip tap.
- Backup leakage. Backups encrypted at rest with an age public key whose private half lives off-VPS.
- Insider attack. Operators cannot decrypt vaults. Recovery actions require multi-operator approval and 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 can't 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
Every primitive we use is documented and replaceable. Each encrypted blob carries a one-byte version so we can rotate algorithms without flag days.
| Use | Algorithm |
|---|---|
| Chip mutual authentication | AES-128 EV2First (NXP DESFire EV3) |
| Vault key on chip | 32 bytes random, written to authenticated file |
| Per-credential encryption | ChaCha20-Poly1305 AEAD + HKDF-SHA256 |
| FIDO assertion signing | ECDSA P-256 + SHA-256 (FIDO2 / RFC 8152) |
| Originality verification | ECDSA secp224r1 (NXP-signed at fab) |
| Recovery key sharing | Shamir Secret Sharing over GF(2⁸) |
| Operator passwords | PBKDF2-HMAC-SHA256, 600,000 iters (OWASP 2023) |
| Backup at rest | age (X25519 + ChaCha20-Poly1305) |
| Constant-time compare | hmac.compare_digest (Python stdlib) |
| Random number generation | CSPRNG: getrandom(2) / SecRandom / SecureRandom |
| TLS | TLS 1.3 (nginx default), HSTS preload |
Operator panel hardening
Customer-service staff sign in to a separate panel with its own auth model. Operators cannot decrypt customer vaults; they can review state, approve recovery requests, and trigger destructive actions only with peer approval.
- Three-tier roles: support (view + low-risk), senior (approve recovery), super (manage other operators).
- SameSite=Strict session cookies make CSRF structurally impossible on cookie-authenticated state changes.
- Defense-in-depth: every state-changing endpoint requires the X-Requested-With: fetch header on top of the cookie.
- 5 failed login attempts per account causes a 15-minute lockout. 10 attempts per IP per 15 minutes triggers an IP-level block (defeats password spraying).
- Sessions: 30-minute idle timeout, 8-hour absolute cap, hashed at rest, immediate revocation on password change.
- Multi-operator approval (2-of-N) for: account recovery completion, chip key rotation, account deletion. A single reject vote rejects the request immediately.
- Every operator-initiated action lands in the audit log with operator id, before/after state, reason, and IP.
Disclosure & bug bounty
Security research is welcome. Email support@skinid.ch with reproduction steps; we acknowledge within 48 hours and aim to assess within 5 business days. Coordinated disclosure: 90 days.
We commit to crediting reporters in our advisories (unless you ask us not to) and not pursuing legal action for research conducted within the scope detailed in our disclosure policy.
For technical reviewers
CISOs, security engineers, and technical buyers running due diligence: the deep architecture page covers protocol details, key lifecycle, server hardening, threat model, and our compliance map.
For source-level review (under NDA), contact us. SkinID is an independent Swiss company; nothing here depends on third-party cloud providers for cryptographic operations.