À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.

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

HIDL de l'authentification faciale

Présentation

L'authentification faciale permet aux utilisateurs de déverrouiller leur appareil en regardant simplement la face avant. Android 10 ajoute la prise en charge d'une nouvelle pile d'authentification faciale qui peut traiter les images de la caméra de manière sécurisée, 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 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 méthodes d'authentification biométrique, y compris la reconnaissance faciale, par empreinte digitale et par iris. Le HAL Face interagit avec les composants suivants.

FaceManager

FaceManager est une interface privée qui maintient une connexion avec FaceService. Il est utilisé par Keyguard pour 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 à états d'authentification et d'enregistrement de base, ainsi que divers autres assistants (par exemple, l'énumération). En raison de problèmes de stabilité et de sécurité, aucun code fournisseur n'est autorisé à s'exécuter dans ce processus. L'ensemble du code du fournisseur est accessible via l'interface HIDL Face 1.0.

confronté

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

Face HIDL

Pour implémenter l'interface 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 à états à l'état idle après leur envoi. La plupart des messages comportent une chaîne visible par 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 la HAL revient à un état inactif après l'envoi d'un message d'erreur.

Messages d'acquisition

Les messages d'acquisition sont diffusés lors de l'inscription ou de l'authentification. Ils sont destinés à guider l'utilisateur pour qu'il puisse s'inscrire ou s'authentifier. Chaque ordinal est associé à un message du fichier FaceAuthenticationManager.java. Vous pouvez ajouter des messages spécifiques aux fournisseurs à condition de fournir les chaînes d'aide correspondantes. 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 aboutit à un état terminal où aucune progression n'est possible, le HAL doit faire suivre les messages d'acquisition d'un message d'erreur (par exemple, lorsque l'image est trop sombre et le reste trop pour que la progression soit possible). 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 de biométrie forte pour Android 10, ils doivent disposer d'un matériel sécurisé afin de garantir l'intégrité des données faciales et la comparaison ultime pour l'authentification. 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 nécessaire pour le traitement et la reconnaissance sécurisés. De plus, un matériel de caméras sécurisé est nécessaire pour éviter les attaques par injection sur l'authentification faciale. Par exemple, les pages 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 l'appareil photo 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 renvoyer immédiatement 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é par `FaceService` pour renvoyer tous les messages à lui-même.
`setActiveUser()`	Définit l'utilisateur actif auquel toutes les opérations HAL ultérieures 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 challenge 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 renvoie `faced` à l'état inactif.
`enumerate()`	Énumère tous les modèles de visage associés à l'utilisateur actif.
`remove()`	Supprime un 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. L'utilisation de cette méthode lorsque le HAL n'est pas dans l'un de ces états renvoie `OPERATION_NOT_SUPPORTED`. L'appel de cette méthode alors que la 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 refusés, `faced` doit passer en é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 l'état interne de manière sécurisée. Réinitialise le verrouillage uniquement pour l'utilisateur actuel.

Les trois méthodes restantes sont toutes synchrones et doivent bloquer le moins de temps possible 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, le schéma ou le 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'indiqué par la valeur par défaut ou par un appel à `setFeature()` ci-dessus. Si l'identification faciale 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 ci-dessous.