Une connexion biométrique qu’un callback intercepté ne peut pas falsifier

La connexion biométrique fait partie des fonctionnalités que les utilisateurs apprécient le plus dans les apps bancaires : un regard ou un simple contact du doigt au lieu d’un code PIN. C’est aussi l’une des plus faciles à implémenter d’une manière qui semble sécurisée sans l’être.

Lors de l’audit de sécurité de l’app Android d’une banque de détail, l’authentification biométrique faisait partie des points que nous avons renforcés. Dans cet article, nous expliquons la faiblesse courante, comment le fait de lier la biométrie à un CryptoObject la corrige, et ce que cela ne résout toujours pas.

---

La faiblesse courante : se fier au callback

Le BiometricPrompt d’Android communique le résultat d’une vérification via un callback. Dans sa logique, l’implémentation la plus simple ressemble à ceci :

1. Afficher l’invite biométrique.

2. Attendre onAuthenticationSucceeded.

3. Déverrouiller la session.

Le problème se situe à l’étape 3. Sur un appareil compromis, un outil de hooking comme Frida peut appeler directement le callback de succès. L’app n’a aucun moyen de distinguer une véritable correspondance biométrique d’un appel de méthode falsifié.

📌 À retenir :

Un callback dit « quelque chose a signalé un succès ». Une clé cryptographique que seul le système peut déverrouiller dit « une véritable vérification biométrique a eu lieu ».

---

La solution : lier l’authentification biométrique à une clé

Au lieu de se fier au callback, l’app lie la connexion à une opération cryptographique :

1. Créer une clé dans l’Android Keystore qui exige l’authentification de l’utilisateur avant chaque utilisation.

2. Encapsuler un Cipher ou une Signature utilisant cette clé dans un CryptoObject et le transmettre à BiometricPrompt.

3. Ce n’est qu’après une véritable correspondance biométrique que le système déverrouille la clé pour cette opération.

4. Utiliser le cipher déverrouillé pour déchiffrer un secret de session ou signer un challenge du serveur. La connexion n’aboutit que si cette opération réussit.

Si un attaquant falsifie le callback, le cipher n’a jamais été déverrouillé. Le déchiffrement ou la signature échoue, et la connexion avec.

---

Les choix de conception qui comptent

1. Déchiffrer ou signer quelque chose de réel

Le CryptoObject doit protéger un élément dont la connexion dépend réellement — un secret de session ou une signature vérifiée par le serveur. Appeler le cipher sur des données factices en ignorant le résultat réintroduit directement la faiblesse.

2. Décider de ce qui se passe quand la biométrie change

Les clés peuvent être configurées pour devenir invalides lorsqu’une nouvelle empreinte ou un nouveau visage est enregistré. Cela bloque une personne qui ajoute sa propre biométrie sur un téléphone déverrouillé. Cela signifie aussi que l’app doit prévoir un parcours clair pour réactiver la biométrie par code PIN ou mot de passe.

3. Prévoir une solution de repli

La biométrie échoue : doigts mouillés, masques, nouveaux téléphones. Le repli sur un code PIN ou un mot de passe fait partie de la conception, et il doit être aussi bien protégé que le parcours biométrique.

4. La combiner avec d’autres contrôles

La liaison au CryptoObject comble une faille. La détection du root et du hooking, la validation des sessions côté serveur et la limitation du nombre de tentatives en comblent d’autres.

---

Biométrie par callback seul ou liée à un CryptoObject

Critère	Callback seul	Liée à un CryptoObject
Ce qui prouve le succès	Un appel de méthode	Une clé déverrouillée par le système
Callback falsifié avec un outil de hooking	La connexion réussit	La connexion échoue
Effort d’implémentation	Faible	Modéré
Changement pour l’expérience utilisateur	—	Aucun pour l’utilisateur

Comment Mobian vous aide

Chez Mobian, la biométrie liée à un CryptoObject était l’un des contrôles d’un plan de remédiation de 124 tâches pour l’app Android d’une banque de détail, aux côtés de la protection contre les overlays, de la détection du hooking et des émulateurs, et de contrôles anti-repackaging. Chaque contrôle a été vérifié par un pack de sécurité QA indépendant, et pas seulement par le développeur qui l’avait réalisé.

Conclusion

Une connexion biométrique qui se fie à un callback n’est pas plus solide que l’appareil sur lequel elle tourne. Lier la connexion à une clé du Keystore que le système déverrouille après une véritable correspondance garantit qu’un callback falsifié ne rapporte rien à l’attaquant. L’expérience utilisateur reste la même ; la différence n’apparaît que lorsque quelqu’un tente de tricher.

Questions fréquentes

Quel est le problème si l’on vérifie seulement le callback de succès biométrique ?

Si une app déverrouille une session dès que onAuthenticationSucceeded est appelé, un attaquant disposant d’un outil de hooking comme Frida sur un appareil compromis peut appeler cette méthode directement. L’app constate un succès sans qu’aucune empreinte ni aucun visage n’ait jamais été vérifié.

Qu’est-ce qu’un CryptoObject dans la biométrie Android ?

Un CryptoObject encapsule une opération cryptographique, comme un Cipher ou une Signature, qui utilise une clé de l’Android Keystore. Lorsque cette clé est créée de façon à exiger l’authentification de l’utilisateur, l’opération ne fonctionne qu’après une véritable vérification biométrique par le système. Un callback falsifié ne donne à l’attaquant qu’un cipher inutilisable.

La biométrie liée à un CryptoObject protège-t-elle contre toutes les attaques ?

Non. Elle comble la faille du callback falsifié, mais elle doit être combinée à d’autres contrôles, comme la détection du root et du hooking, la vérification des sessions côté serveur et une solution de repli par code PIN ou mot de passe. Aucun contrôle ne suffit à lui seul à sécuriser une app.

Que se passe-t-il lorsqu’un utilisateur enregistre une nouvelle empreinte ?

Les clés peuvent être configurées pour devenir invalides lorsque de nouvelles données biométriques sont enregistrées. Cela empêche une personne qui ajoute sa propre empreinte sur un téléphone déverrouillé de s’en servir pour se connecter, mais l’app a alors besoin d’un parcours de réactivation clair, généralement par code PIN ou mot de passe.

Quelle catégorie OWASP cela couvre-t-il ?

Principalement M3 : Insecure Authentication/Authorization (authentification et autorisation non sécurisées) dans l’OWASP Mobile Top 10 (2024). Lier la clé à la biométrie va aussi dans le sens des bonnes pratiques de la catégorie M10, Insufficient Cryptography.