À partir de 2026, pour nous aligner sur notre modèle de développement stable et garantir la stabilité de la plate-forme pour l'écosystème, nous publierons le code source sur AOSP au deuxième et au quatrième trimestre. Pour créer et contribuer dans AOSP, utilisez android-latest-release. La branche de fichier manifeste android-latest-release fera toujours référence à la version la plus récente envoyée à AOSP. Pour en savoir plus, consultez Modifications apportées à AOSP.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

HIDL de l'authentification faciale

Présentation

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 nouvelle pile d'authentification faciale qui peut traiter en toute sécurité les images de l'appareil photo, 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 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, le doigt et l'iris. La HAL faciale interagit avec les composants suivants.

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 de base pour l'enregistrement et l'authentification, 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 que IBiometricsFace@1.0 afin que FaceService puisse le trouver.

Implémentation

HIDL faciale

Pour implémenter la HIDL faciale, 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 la 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. La HAL est censée 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 dans lequel aucune progression n'est possible, la HAL doit faire suivre les messages d'acquisition d'un message d'erreur. Par exemple, si l'image est trop sombre et le reste trop longtemps 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 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 finale de 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 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 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 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 immédiatement revenir au framework. Dans le cas contraire, le système sera lent et des réinitialisations Watchdog seront possibles. 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 destinée à 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, enregistrer, authentifier, supprimer ou énumérer) 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 la HAL est en état d'authentification ou de veille. Si vous utilisez cette méthode lorsque la HAL n'est pas dans l'un de ces états, `OPERATION_NOT_SUPPORTED` est renvoyé. 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 rejetés, `faced` doit passer à un état de verrouillage (`LOCKOUT` ou `LOCKOUT_PERMANENT`). Dans ce cas, il est nécessaire d'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 ci-dessous.