L'authentification faciale permet aux utilisateurs de déverrouiller leur appareil simplement en regardant l'avant de celui-ci. Android 10 est compatible avec une pile d'authentification faciale qui peut traiter en toute sécurité les images de la caméra, tout en préservant la sécurité et la confidentialité lors de l'authentification faciale sur le matériel compatible. Android 10 permet également aux implémentations conformes aux exigences de sécurité d'activer facilement l'intégration d'applications pour les transactions, telles que les services bancaires en ligne ou d'autres services.
La pile d'authentification faciale Android est une implémentation dans Android 10. L'implémentation introduit les interfaces IBiometricsFace.hal,
IBiometricsFaceClientCallback.hal,
et types.hal.
Architecture
L'API BiometricPrompt inclut toutes les authentifications biométriques, y compris le visage, le doigt et l'iris. L'interface HAL du visage interagit avec les composants suivants.
Figure 1. Pile biométrique.
FaceManager
FaceManager est une interface privée qui maintient une connexion avec FaceService. Elle est utilisée par Keyguard pour accéder à l'authentification faciale avec une interface utilisateur personnalisée. Les applications n'ont pas accès à FaceManager et doivent utiliser BiometricPrompt à la place.
FaceService
Il s'agit de l'implémentation du framework qui gère l'accès au matériel d'authentification faciale. Elle contient des machines d'état d'enregistrement et d'authentification de base, ainsi que divers autres assistants (par exemple, l'énumération). Pour des raisons de stabilité et de sécurité, aucun code de fournisseur n'est autorisé à s'exécuter dans ce processus. Tous les codes de fournisseur sont accessibles via l'interface HIDL Face 1.0.
faced
Il s'agit d'un exécutable Linux qui implémente l'interface HIDL Face 1.0 utilisée par FaceService. Il s'enregistre en tant qu'IBiometricsFace@1.0 afin que FaceService puisse le trouver.
Implémentation
HIDL du visage
Pour implémenter le HIDL du visage, vous devez implémenter toutes les méthodes de IBiometricsFace.hal
dans une bibliothèque spécifique au fournisseur.
Messages d'erreur
Les messages d'erreur sont envoyés par un rappel et renvoient la machine d'état à l'état inactif une fois qu'ils sont envoyés. La plupart des messages comportent une chaîne visible par l'utilisateur correspondante pour l'informer de l'erreur, mais ce n'est pas le cas pour toutes les erreurs. Pour en savoir plus sur les messages d'erreur, consultez
types.hal.
Tous les messages d'erreur représentent un état final, ce qui signifie que le framework suppose que le HAL revient à un état inactif après l'envoi d'un message d'erreur.
Messages d'acquisition
Les messages d'acquisition sont envoyés lors de l'enregistrement ou de l'authentification, et sont destinés à guider l'utilisateur vers un enregistrement ou une authentification réussis.
Chaque ordinal a
un message associé du FaceAuthenticationManager.java
fichier. Des messages spécifiques au fournisseur peuvent être ajoutés à condition que les chaînes d'aide correspondantes soient fournies. Les messages d'acquisition ne sont pas des états finaux en soi. Le HAL est censé en envoyer autant que nécessaire pour terminer l'enregistrement ou l'authentification en cours. Si un message d'acquisition entraîne un état final où aucun progrès ne peut être réalisé, le HAL doit suivre les messages d'acquisition avec un message d'erreur, par exemple, lorsque l'image est trop sombre et reste trop sombre pour que des progrès soient réalisés. Dans ce cas, il est
raisonnable d'envoyer UNABLE_TO_PROCESS après plusieurs tentatives infructueuses.
Matériel
Pour que les appareils soient conformes aux exigences biométriques fortes d'Android 10, ils doivent disposer d'un matériel sécurisé afin de garantir l'intégrité des données de reconnaissance faciale et la comparaison d'authentification finale. Le document de définition de compatibilité Android (CDD) décrit le niveau de sécurité requis et le taux d'acceptation de spoofing (SAR) acceptable. Un environnement d'exécution sécurisé (TEE) est requis pour le traitement et la reconnaissance sécurisés. De plus, un matériel de caméra sécurisé est nécessaire pour éviter les attaques par injection sur l'authentification faciale. Par exemple, les pages de mémoire associées aux données d'image peuvent être privilégiées et marquées en lecture seule afin que seul le matériel de la caméra puisse les mettre à jour. Idéalement, aucun processus ne devrait avoir accès, à l'exception du TEE et du matériel.
Étant donné que le matériel d'authentification faciale varie considérablement, il est nécessaire de développer des pilotes spécifiques au matériel pour activer l'authentification faciale, en fonction de l'architecture spécifique de l'appareil. Par conséquent, il n'existe aucune implémentation de référence pour faced.
Méthodes
Les méthodes suivantes sont toutes asynchrones et doivent immédiatement revenir au framework. Dans le cas contraire, le système sera lent et des réinitialisations Watchdog pourront se produire. Il est recommandé d'avoir une file d'attente de messages avec plusieurs threads pour éviter de bloquer l'appelant. Toutes les requêtes GET doivent mettre en cache les informations dans la mesure du possible afin que l'appelant soit bloqué pendant une durée minimale.
| Méthode | Description |
|---|---|
setCallback |
Appelée par FaceService pour renvoyer tous les messages à lui-même. |
setActiveUser |
Définit l'utilisateur actif, auquel toutes les opérations HAL suivantes sont appliquées. L'authentification est toujours pour cet utilisateur jusqu'à ce que cette méthode soit appelée à nouveau. |
revokeChallenge |
Termine la transaction sécurisée en invalidant le défi généré
par generateChallenge. |
enroll |
Enregistre le visage d'un utilisateur. |
cancel |
Annule l'opération en cours (par exemple, enregistrement, authentification,
suppression ou énumération) et renvoie faced à l'état inactif. |
enumerate |
Énumère tous les modèles de visage associés à l'utilisateur actif. |
remove |
Supprime un modèle de visage ou tous les modèles de visage associés à l'utilisateur actif. |
authenticate |
Authentifie l'utilisateur actif. |
userActivity |
Cette méthode ne doit être utilisée que lorsque le HAL est en état d'authentification ou de
veille. Si vous utilisez cette méthode lorsque le HAL n'est pas dans l'un de ces
états, OPERATION_NOT_SUPPORTED est renvoyé. L'appel
de cette méthode alors que le HAL est déjà en cours d'authentification peut prolonger la
durée pendant laquelle le système recherche un visage. |
resetLockout |
Lorsque trop de visages sont rejetés, faced doit passer à un état de verrouillage (LOCKOUT ou LOCKOUT_PERMANENT). Dans ce cas, il
doit envoyer le temps restant au framework afin qu'il puisse l'afficher pour l'utilisateur. Comme pour setFeature, cette méthode nécessite un
jeton d'authentification matérielle (HAT) actif pour réinitialiser en toute sécurité l'état interne. Réinitialise le verrouillage
uniquement pour l'utilisateur actuel. |
Les trois méthodes restantes sont toutes synchrones et doivent bloquer pendant une durée minimale pour éviter de bloquer le framework.
| Méthode | Description |
|---|---|
generateChallenge |
Génère un jeton aléatoire unique et sécurisé cryptographiquement utilisé pour indiquer le début d'une transaction sécurisée. |
setFeature |
Active ou désactive une fonctionnalité pour l'utilisateur actuel. Pour des raisons de sécurité, cela nécessite un HAT pour vérifier le code PIN/schéma/mot de passe de l'utilisateur par rapport au défi ci-dessus. |
getFeature |
Récupère l'état d'activation actuel de la fonctionnalité, tel qu'il est défini par
la valeur par défaut ou par un appel à setFeature ci-dessus. Si l'ID de visage n'est pas valide, l'
implémentation doit renvoyer ILLEGAL_ARGUMENT |
getAuthenticatorId |
Renvoie un identifiant associé à l'ensemble de visages actuel. Cet identifiant doit changer chaque fois qu'un visage est ajouté. |
Diagramme d'état
Le framework s'attend à ce que faced suive le diagramme d'état de la figure :
Figure 2. Flux d'état de l'authentification faciale.