Il modello in una frase
Ogni chip memorizza una chiave di wrapping del vault da 32 byte all'interno di un file cifrato autenticato. Ogni credenziale che custodiamo per te è cifrata sotto quella chiave. Per decifrare qualsiasi cosa, il chip deve trovarsi fisicamente nel campo del lettore, completare un'autenticazione reciproca AES-128, e il server deve leggere la chiave di wrapping. Niente chip nel campo, niente testo in chiaro.
Difesa a livelli
Il chip stesso (NXP MIFARE DESFire EV3)
Secure element a prova di manomissione di NXP, uno dei principali produttori al mondo di chip NFC e di pagamento contactless. Autenticazione reciproca AES-128 con il server in modalità DESFire EV2. Certificato di originalità firmato da NXP che ci permette di verificare l'autenticità del silicio. Senza un'autenticazione riuscita, il chip rifiuta ogni operazione.
Crittografia legata al chip (zero-knowledge)
Chiavi per credenziale derivate tramite HKDF-SHA256 dalla chiave di wrapping del chip. ChaCha20-Poly1305 AEAD, uno standard di crittografia moderno utilizzato da Cloudflare, dai servizi Google e dal protocollo Signal. Il binding dei dati associati (utente, sito, ID credenziale) impedisce attacchi di sostituzione del testo cifrato. Il server memorizza solo testo cifrato.
Sicurezza di trasporto e sessione
TLS 1.3, l'attuale standard di sicurezza internet, con HSTS preload. Header rigorosi di Content Security Policy, Cross-Origin Opener Policy e Cross-Origin Resource Policy. Cookie SameSite=Strict per le sessioni operatore. Limiti di velocità per IP sull'autenticazione, blocco dopo ripetuti tentativi di accesso falliti. Tutti i token di sessione sono hashati in SHA-256 a riposo.
Operazioni e recupero
Tre percorsi di recupero indipendenti perché tu non possa mai rimanere bloccato in modo permanente: un chip di backup, una chiave Shamir stampabile e un processo di verifica dell'identità in più passaggi. Ogni azione distruttiva richiede l'approvazione di più operatori. Backup cifrati protetti con una chiave privata age memorizzata su un sistema isolato separato.
Modello di minaccia
Siamo onesti su ciò che questa tecnologia può e non può difendere.
Da cosa difendiamo
- Phishing. Le passkey sono vincolate all'origine; il phishing fallisce per costruzione.
- Credenziali rubate. Ogni sito ha una credenziale unica generata dal server. Non c'è una password master da forzare.
- Compromissione del server. Il server contiene testo cifrato. Senza il chip, un aggressore legge solo rumore.
- Intercettazione di rete. TLS 1.3 e HSTS preload su tutti gli endpoint.
- Dispositivo rubato. Ogni nuovo accesso richiede un tap del chip.
- Fuga di backup. I backup sono cifrati a riposo con una chiave pubblica age la cui metà privata vive su un sistema isolato separato.
- Attacco interno. I nostri operatori non possono decifrare i vault. Le azioni di recupero richiedono l'approvazione di più operatori e un audit log completo.
Da cosa non difendiamo
- Rimozione fisica del chip. Il tuo corpo, la tua decisione.
- Coercizione. Se qualcuno ti costringe a scansionare, il sistema non può rilevarlo.
- Compromissione del tuo dispositivo mentre il chip è in contatto. La finestra è limitata al momento del tap.
- Avversari statali mirati con esecuzione arbitraria di codice sul tuo dispositivo sbloccato. Nessun autenticatore per consumatori difende da questo.
Primitive crittografiche
Siamo trasparenti su ogni algoritmo che utilizziamo. Ogni blob cifrato porta una versione di un byte così possiamo ruotare gli algoritmi senza interruzioni.
| Uso | Algoritmo |
|---|---|
| Autenticazione reciproca del chip | AES-128 (NXP DESFire EV3, EV2 mode) |
| Chiave del vault sul chip | 32 byte casuali, memorizzati in un file autenticato |
| Crittografia per credenziale | ChaCha20-Poly1305 AEAD with HKDF-SHA256 |
| Firma di asserzione FIDO | ECDSA P-256 with SHA-256 (FIDO2 and WebAuthn, COSE ES256) |
| Verifica dell'originalità del chip | ECDSA secp224r1, firmato da NXP in produzione |
| Condivisione della chiave di recupero | Shamir Secret Sharing |
| Password operatore | PBKDF2-HMAC-SHA256, numero di iterazioni raccomandato da OWASP |
| Backup a riposo | age (X25519 key exchange, ChaCha20-Poly1305 symmetric) |
| Confronto a tempo costante | Confronto a tempo costante dalla libreria standard |
| Generazione di numeri casuali | CSPRNG fornito dal sistema operativo |
| TLS | TLS 1.3 con HSTS preload |
Hardening del pannello operatore
Il nostro personale di assistenza clienti accede a un pannello separato con il proprio modello di autenticazione. Non possono decifrare i vault dei clienti. Possono visualizzare lo stato, approvare richieste di recupero e attivare azioni distruttive solo con l'approvazione di pari.
- Il nostro personale non può leggere i tuoi dati, punto.
- Qualsiasi azione sensibile richiede l'approvazione di più membri del personale.
- Ogni azione viene registrata con un audit trail completo.
- Le sessioni del personale scadono automaticamente e si bloccano dopo tentativi falliti.
Per il modello di sicurezza completo per gli operatori, consulta la pagina architettura tecnica.