Stockage securise de biometrie — patterns et comparaison ProbatioVault¶
Resume¶
Thread pedagogique de @irukanji_invest sur le stockage securise de donnees biometriques. Principes exposes :
- Ne jamais stocker l'image brute (empreinte, iris)
- Calculer les minuties avec un algorithme proprietaire (decalage X/Y, rotation)
- Chiffrer le tout en stockage a froid + RAM
- Privilegier la decentralisation via Passkey/FIDO
- Faire intervenir un cryptographe sur le sujet
Mentionne OpenAI/Worldcoin et leur approche FIDO decentralisee.
Analyse critique¶
Vulgarisation correcte mais basique. Les principes sont connus dans la communaute securite : template protection (ISO/IEC 24745), cancelable biometrics, feature transformation. Le thread ne mentionne pas ces standards, ni la distinction entre feature-level et score-level protection. La partie OpenAI/FIDO est speculative.
Utile pour sensibiliser un public non-expert. Pas de profondeur technique nouvelle.
Le thread assume un cas centralise (biometrie stockee dans le cloud) — le pire scenario en termes de risque. La recommandation Passkey/FIDO (decentralise) est la bonne conclusion, mais elle arrive comme un ajout plutot que comme l'architecture de reference.
Pertinence ProbatioVault¶
ProbatioVault a implemente l'authentification biometrique dans PD-107 (iOS, Done) et PD-118 (Android, To Do). Comparaison point par point :
| Recommandation thread | ProbatioVault PD-107 | Statut |
|---|---|---|
| Ne pas stocker l'image brute | INV-107-06 : donnees biometriques brutes JAMAIS collectees. LocalAuthentication retourne un booleen, jamais de template | Conforme |
| Calculer les minuties avec algo proprietaire | Non applicable — aucune extraction de minuties. Tout delegue au Secure Enclave iOS. L'app ne touche jamais au signal biometrique | Au-dela |
| Chiffrer en stockage a froid + RAM | K_bio dans Keychain avec BIOMETRY_CURRENT_SET + WHEN_UNLOCKED_THIS_DEVICE_ONLY. Zeroization memoire (TC-107-056). PD-174 efface le password de la RAM au lock | Conforme |
| Decentralisation (Passkey/FIDO) | 100% device-local. K_bio ne quitte jamais l'appareil. Pas de sync iCloud. Backend ne recoit que des events d'audit (userId, timestamp, type) | Conforme |
| Faire bosser un cryptographe | HKDF pour deriver K_bio depuis la preuve SRP-6a, AES-GCM pour l'enveloppe, Keychain invalide automatiquement si l'enrollment biometrique change | Conforme |
Ce que ProbatioVault fait en plus (non mentionne dans le thread) :
- INV-107-01/02 : la biometrie ne remplace pas le mot de passe — c'est un mecanisme de deverrouillage, pas d'authentification. SRP-6a reste obligatoire au login
- Revocation automatique : ajout d'un doigt/visage → iOS invalide K_bio via
kSecAccessControlBiometryCurrentSet→ fallback password immediat - Policy engine : 3 echecs → lockout, 30 min inactivite → password, reboot → password, changement MDP → password
- Anti-tampering : detection jailbreak (Frida) via module Swift natif, fail-closed
- Audit HSM : chaque evenement biometrique (succes, echec, revocation) signe par HSM, append-only avec hash chain
Verdict architecture : ProbatioVault est plus strict que les recommandations du thread. Le thread parle de stocker des minuties transformees cote serveur — ProbatioVault ne stocke rien cote serveur et ne touche meme pas au signal biometrique. C'est le pattern le plus sur : delegation totale a l'OS/Secure Enclave, l'app ne recoit qu'un booleen.