Cette page a été traduite par l'API Cloud Translation.

Authentification faciale HIDL

Présentation

L'authentification faciale permet aux utilisateurs de déverrouiller leur appareil simplement en le regardant. Android 10 prend en charge une nouvelle pile d'authentification faciale capable de traiter de manière sécurisée les images de la caméra, ce qui préserve la sécurité et la confidentialité lors de l'authentification faciale sur le matériel compatible. Android 10 fournit également un moyen simple pour les implémentations conformes aux exigences de sécurité d'intégrer des applications pour les transactions, telles que la banque en ligne ou d'autres services.

La pile d'authentification faciale Android est une nouvelle implémentation dans Android 10. La nouvelle 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, l'empreinte digitale et l'iris. Le HAL Face interagit avec les composants suivants.

FaceManager

FaceManager est une interface privée qui maintient une connexion avec FaceService. Il permet à Keyguard d'accéder à l'authentification faciale avec une UI 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. Il contient des machines d'état d'enregistrement et d'authentification de base, ainsi que divers autres outils d'assistance (par exemple, l'énumération). Pour des raisons de stabilité et de sécurité, aucun code fournisseur n'est autorisé à s'exécuter dans ce processus. L'accès à l'ensemble du code du fournisseur s'effectue via l'interface HIDL Face 1.0.

face

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 que IBiometricsFace@1.0 pour que FaceService puisse le trouver.

Implémentation

HIDL du visage

Pour implémenter le HIDL Face, 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 idle après leur envoi. La plupart des messages comportent une chaîne destinée à l'utilisateur pour l'informer de l'erreur, mais ce n'est pas le cas de 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'inscription ou de l'authentification et sont destinés à guider l'utilisateur vers une inscription ou une authentification réussie. Chaque ordinal est associé à un message du fichier FaceAuthenticationManager.java. Vous pouvez ajouter des messages spécifiques au fournisseur tant que les chaînes d'aide correspondantes sont fournies. Les messages d'acquisition ne sont pas des états terminaux en soi. Le HAL doit envoyer autant de messages que nécessaire pour terminer l'enregistrement ou l'authentification en cours. Si un message d'acquisition génère un état final où aucun progrès ne peut être effectué, le HAL doit suivre les messages d'acquisition avec un message d'erreur, par exemple, où l'image est trop sombre et reste trop sombre pour que la progression puisse être effectuée. Dans ce cas, il est raisonnable d'envoyer UNABLE_TO_PROCESS après plusieurs tentatives, mais aucune autre progression ne peut être effectuée.

Matériel

Pour que les appareils respectent les exigences de biométrie renforcée d'Android 10, ils doivent disposer d'un matériel sécurisé pour garantir l'intégrité des données faciales 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 des falsifications (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 d'appareil photo sécurisé est nécessaire pour éviter les attaques par injection sur l'authentification par reconnaissance 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 doit y avoir accès, sauf le TEE et le 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'y a pas d'implémentation de référence pour faced.

Méthodes

Les méthodes suivantes sont toutes asynchrones et doivent immédiatement retourner au framework. Dans le cas contraire, le système sera lent et des réinitialisations du chien de garde peuvent se produire. Il est recommandé d'utiliser 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é par `FaceService` pour renvoyer tous les messages vers lui-même.
`setActiveUser()`	Définit l'utilisateur actif auquel toutes les opérations HAL ultérieures sont appliquées. L'authentification est toujours appliquée à cet utilisateur jusqu'à ce que cette méthode soit rappelée.
`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, l'enregistrement, l'authentification, la suppression ou l'énumération) et rétablit l'état inactif de `faced`.
`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 cours d'authentification ou en veille. L'utilisation de cette méthode lorsque le HAL n'est pas dans l'un de ces états renvoie `OPERATION_NOT_SUPPORTED`. Appeler cette méthode alors que le HAL est déjà en cours d'authentification peut prolonger le temps de recherche d'un visage par le système.
`resetLockout()`	Lorsque trop de visages sont refusé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 avec `setFeature()`, cette méthode nécessite un jeton d'authentification matérielle (HAT) actif pour réinitialiser de manière sécurisée l'état interne. Réinitialise le verrouillage uniquement pour l'utilisateur actuel.

Les trois méthodes restantes sont toutes synchrones et doivent bloquer pendant la 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 qu'un HAT vérifie le code/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é, comme indiqué 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é au jeu 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 des états ci-dessous.