Le modèle en une phrase
Chaque puce stocke une clé d'enveloppement de coffre de 32 octets à l'intérieur d'un fichier chiffré authentifié. Chaque identifiant que nous conservons pour vous est chiffré sous cette clé. Pour déchiffrer quoi que ce soit, la puce doit physiquement se trouver dans le champ du lecteur, effectuer une authentification mutuelle AES-128, et le serveur doit extraire la clé. Pas de puce dans le champ, pas de texte clair.
Défense en couches
La puce elle-même (NXP MIFARE DESFire EV3)
Élément sécurisé inviolable de NXP, l'un des principaux fabricants mondiaux de puces NFC et de paiement sans contact. Authentification mutuelle AES-128 avec le serveur en mode DESFire EV2. Certificat d'originalité signé par NXP qui permet de vérifier l'authenticité du silicium. Sans authentification réussie, la puce refuse toute opération.
Chiffrement lié à la puce (zero-knowledge)
Clés par identifiant dérivées via HKDF-SHA256 à partir de la clé d'enveloppement de la puce. ChaCha20-Poly1305 AEAD, un standard de chiffrement moderne utilisé par Cloudflare, les services Google et le protocole Signal. La liaison des données associées (utilisateur, site, identifiant) empêche les attaques par échange de texte chiffré. Le serveur ne stocke que du texte chiffré.
Sécurité du transport et des sessions
TLS 1.3, le standard actuel de sécurité internet, avec HSTS preload. Politiques strictes de Content Security Policy, Cross-Origin Opener Policy et Cross-Origin Resource Policy. Cookies SameSite=Strict pour les sessions opérateurs. Limites de débit par IP sur l'authentification, blocage après plusieurs tentatives de connexion échouées. Tous les jetons de session sont hachés en SHA-256 au repos.
Opérations et récupération
Trois voies de récupération indépendantes pour ne jamais vous retrouver bloqué de manière permanente : une puce de secours, une clé Shamir imprimable et un processus de vérification d'identité en plusieurs étapes. Chaque action destructive nécessite l'approbation de plusieurs opérateurs. Sauvegardes chiffrées protégées par une clé privée age stockée sur un système isolé distinct.
Modèle de menace
Nous sommes honnêtes sur ce que cette technologie peut défendre et ce qu'elle ne peut pas.
Ce contre quoi nous défendons
- Hameçonnage. Les passkeys sont liées à l'origine ; l'hameçonnage échoue par construction.
- Identifiants volés. Chaque site possède un identifiant unique généré par le serveur. Pas de mot de passe maître à casser.
- Compromission du serveur. Le serveur ne contient que du texte chiffré. Sans la puce, un attaquant ne lit que du bruit.
- Écoute du réseau. TLS 1.3 et HSTS preload sur tous les points de terminaison.
- Vol d'appareil. Chaque nouvelle connexion nécessite un tap de puce.
- Fuite des sauvegardes. Les sauvegardes sont chiffrées au repos avec une clé publique age dont la moitié privée vit sur un système isolé distinct.
- Attaque interne. Nos opérateurs ne peuvent pas déchiffrer les coffres. Les actions de récupération exigent l'approbation de plusieurs opérateurs et un journal d'audit complet.
Ce contre quoi nous ne défendons pas
- Retrait physique de la puce. Votre corps, votre décision.
- Contrainte. Si quelqu'un vous force à scanner, le système ne peut pas le détecter.
- Compromission de votre appareil pendant que la puce est touchée. La fenêtre est limitée à l'instant du tap.
- Adversaires étatiques ciblés avec exécution arbitraire de code sur votre appareil déverrouillé. Aucun authentifiant grand public ne défend contre cela.
Primitives cryptographiques
Nous sommes transparents sur chaque algorithme que nous utilisons. Chaque blob chiffré porte une version d'un octet afin de pouvoir faire tourner les algorithmes sans interruption.
| Usage | Algorithme |
|---|---|
| Authentification mutuelle de la puce | AES-128 (NXP DESFire EV3, EV2 mode) |
| Clé du coffre sur la puce | 32 octets aléatoires, stockés dans un fichier authentifié |
| Chiffrement par identifiant | ChaCha20-Poly1305 AEAD with HKDF-SHA256 |
| Signature d'assertion FIDO | ECDSA P-256 with SHA-256 (FIDO2 and WebAuthn, COSE ES256) |
| Vérification d'originalité de la puce | ECDSA secp224r1, signé par NXP à la fabrication |
| Partage de clé de récupération | Shamir Secret Sharing |
| Mots de passe opérateurs | PBKDF2-HMAC-SHA256, nombre d'itérations recommandé par l'OWASP |
| Sauvegarde au repos | age (X25519 key exchange, ChaCha20-Poly1305 symmetric) |
| Comparaison à temps constant | Comparaison à temps constant de la bibliothèque standard |
| Génération de nombres aléatoires | CSPRNG fourni par le système d'exploitation |
| TLS | TLS 1.3 avec HSTS preload |
Renforcement du panneau opérateur
Notre personnel de service client se connecte à un panneau séparé avec son propre modèle d'authentification. Ils ne peuvent pas déchiffrer les coffres clients. Ils peuvent consulter l'état, approuver les demandes de récupération et déclencher des actions destructives uniquement avec l'approbation de pairs.
- Notre personnel ne peut pas lire vos données, point.
- Toute action sensible nécessite l'approbation de plusieurs membres du personnel.
- Chaque action est consignée avec une piste d'audit complète.
- Les sessions du personnel expirent automatiquement et se verrouillent après les tentatives échouées.
Pour le modèle de sécurité complet des opérateurs, consultez la page architecture technique.