À 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.
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Sur les appareils équipés d'un capteur d'empreinte digitale, les utilisateurs peuvent enregistrer une ou plusieurs empreintes digitales et les utiliser pour déverrouiller l'appareil et effectuer d'autres tâches. Android utilise le langage de définition d'interface matérielle (HIDL) pour empreintes digitales afin de se connecter à une bibliothèque spécifique au fournisseur et au matériel d'empreintes digitales (par exemple, un capteur d'empreintes digitales).
Pour implémenter le HIDL d'empreinte digitale, vous devez implémenter IBiometricsFingerprint.hal dans une bibliothèque spécifique au fournisseur.
Correspondance des empreintes digitales
Le lecteur d'empreinte digitale d'un appareil est généralement inactif. Toutefois, en réponse à un appel à authenticate ou enroll, le capteur d'empreinte digitale détecte un contact (l'écran peut également s'allumer lorsqu'un utilisateur touche le capteur d'empreinte digitale). Le processus de mise en correspondance des empreintes digitales comprend les étapes suivantes :
L'utilisateur place un doigt sur le lecteur d'empreinte digitale.
La bibliothèque spécifique au fournisseur détermine s'il existe une empreinte digitale correspondante dans l'ensemble actuel de modèles d'empreintes digitales enregistrés.
Les résultats correspondants sont transmis à FingerprintService.
Ce flux suppose qu'une empreinte digitale a déjà été enregistrée sur l'appareil, c'est-à-dire que la bibliothèque spécifique au fournisseur a enregistré un modèle pour l'empreinte digitale. Pour en savoir plus, consultez la section Authentification.
Architecture
Le HAL d'empreinte digitale interagit avec les composants suivants.
BiometricManager interagit directement avec une application dans un processus d'application.
Chaque application possède une instance de IBiometricsFingerprint.hal.
FingerprintService fonctionne dans le processus système, qui gère la communication avec le HAL d'empreinte digitale.
Fingerprint HAL est une implémentation C/C++ de l'interface IBiometricsFingerprint HIDL. Elle contient la bibliothèque spécifique au fournisseur qui communique avec le matériel spécifique à l'appareil.
Les composants Keystore API et KeyMint (anciennement Keymaster) fournissent un chiffrement matériel pour le stockage sécurisé des clés dans un environnement sécurisé, tel que l'environnement d'exécution sécurisé (TEE).
Figure 1 : Flux de données de haut niveau pour l'authentification par empreinte digitale
Une implémentation HAL spécifique au fournisseur doit utiliser le protocole de communication requis par un TEE. Les images brutes et les caractéristiques d'empreinte digitale traitées ne doivent pas être transmises dans une mémoire non fiable. Toutes ces données biométriques doivent être stockées dans le matériel sécurisé, tel que l'environnement d'exécution sécurisé (TEE). L'activation du mode root ne doit pas pouvoir compromettre les données biométriques.
FingerprintService et fingerprintd effectuent des appels via le HAL d'empreinte digitale vers la bibliothèque spécifique au fournisseur pour enregistrer les empreintes digitales et effectuer d'autres opérations.
Figure 2. Interaction du démon d'empreinte digitale avec la bibliothèque spécifique au fournisseur d'empreinte digitale
Consignes d'implémentation
Les consignes suivantes concernant le HAL d'empreinte digitale sont conçues pour garantir que les données d'empreinte digitale ne sont pas divulguées et sont supprimées lorsqu'un utilisateur est supprimé d'un appareil :
Les données brutes d'empreinte digitale ou leurs dérivés (par exemple, les modèles) ne doivent jamais être accessibles en dehors du pilote du capteur ou du TEE. Si le matériel est compatible avec un TEE, l'accès au matériel doit se limiter au TEE et être protégé par une règle SELinux. Le canal SPI (Serial Peripheral Interface) doit être accessible uniquement au TEE, et une règle SELinux explicite doit s'appliquer à tous les fichiers de l'appareil.
L'acquisition, l'enregistrement et la reconnaissance de l'empreinte digitale doivent avoir lieu dans le TEE.
Seule la version chiffrée des données concernant votre empreinte digitale peut être stockée dans le système de fichiers, même si celui-ci est lui-même chiffré.
Les modèles d'empreintes digitales doivent être signés avec une clé privée spécifique à l'appareil.
Pour la norme AES (Advanced Encryption Standard), un modèle doit au minimum être signé avec le chemin d'accès absolu au système de fichiers, le groupe et l'ID d'empreinte digitale, de sorte que les fichiers de modèle soient inutilisables sur un autre appareil ou par toute personne autre que l'utilisateur qui les a enregistrés sur le même appareil. Par exemple, il ne doit pas être possible de copier les données concernant l'empreinte digitale d'un autre utilisateur ou issues d'un autre appareil sur l'appareil en question.
Les implémentations doivent utiliser le chemin du système de fichiers fourni par la fonction setActiveGroup() ou fournir un moyen d'effacer toutes les données de modèle utilisateur lorsque l'utilisateur est supprimé. Nous vous recommandons vivement de stocker les fichiers de modèles d'empreintes digitales sous forme chiffrée et dans le chemin d'accès fourni. Si cela n'est pas possible en raison des exigences de stockage TEE, l'implémenteur doit ajouter des hooks pour s'assurer que les données sont supprimées lorsque l'utilisateur est supprimé.
Méthodes d'empreinte digitale
L'interface Fingerprint HIDL contient les principales méthodes suivantes dans IBiometricsFingerprint.hal.
Méthode
Description
enroll()
Permet à la machine à états HAL de démarrer la collecte et le stockage d'un modèle d'empreinte digitale. Une fois l'enregistrement terminé ou après un délai d'inactivité, la machine à états HAL revient à l'état inactif.
preEnroll()
Génère un jeton unique pour indiquer le début de l'enregistrement d'une empreinte digitale. Fournit un jeton à la fonction enroll pour s'assurer qu'une authentification préalable a été effectuée, par exemple à l'aide d'un mot de passe. Pour éviter toute falsification, le jeton est encapsulé une fois les identifiants de l'appareil confirmés. Le jeton doit être vérifié lors de l'enregistrement pour s'assurer qu'il est toujours valide.
getAuthenticatorId()
Renvoie un jeton associé à l'ensemble d'empreintes digitales actuel.
cancel()
Annule les opérations d'enregistrement ou d'authentification en attente. La machine à états HAL revient à l'état inactif.
enumerate()
Appel synchrone pour énumérer tous les modèles d'empreintes digitales connus.
remove()
Supprime un modèle d'empreinte digitale.
setActiveGroup()
Restreint une opération HAL à un ensemble d'empreintes digitales appartenant à un groupe spécifié, identifié par un identifiant de groupe (GID).
authenticate()
Authentifie une opération liée à l'empreinte digitale (identifiée par un ID d'opération).
setNotify()
Enregistre une fonction utilisateur qui reçoit des notifications du HAL. Si la machine à états HAL est occupée, la fonction est bloquée jusqu'à ce que HAL quitte l'état occupé.
postEnroll()
Termine l'opération d'enregistrement et invalide le défi preEnroll() généré. Cette méthode doit être appelée à la fin d'une session d'enregistrement de plusieurs empreintes digitales pour indiquer qu'aucun autre doigt ne peut être ajouté.
Le contenu et les exemples de code de cette page sont soumis aux licences décrites dans la Licence de contenu. Java et OpenJDK sont des marques ou des marques déposées d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/27 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/07/27 (UTC)."],[],[],null,["# Fingerprint HIDL\n\nOn devices with a fingerprint sensor, users can enroll one or more\nfingerprints and use those fingerprints to unlock the device and perform other\ntasks. Android uses the Fingerprint Hardware Interface Definition Language\n(HIDL) to connect to a vendor-specific library and fingerprint hardware (for\nexample, a fingerprint sensor).\n\nTo implement the Fingerprint HIDL, you must implement [`IBiometricsFingerprint.hal`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/biometrics/fingerprint/2.1/IBiometricsFingerprint.hal)\nin a vendor-specific library.\n\nFingerprint matching\n--------------------\n\nThe fingerprint sensor of a device is generally idle. However, in response to\na call to `authenticate` or `enroll`, the\nfingerprint sensor listens for a touch (the screen might also wake when a user\ntouches the fingerprint sensor). The high-level flow of fingerprint matching\nincludes the following steps:\n\n1. User places a finger on the fingerprint sensor.\n2. The vendor-specific library determines if there is a fingerprint match in the current set of enrolled fingerprint templates.\n3. Matching results are passed to `FingerprintService`.\n\nThis flow assumes that a fingerprint has already been enrolled on the device, that is,\nthe vendor-specific library has enrolled a template for the fingerprint. For more\ndetails, see [Authentication](/docs/security/features/authentication).\n| **Note:** The more fingerprint templates stored on a device, the more time required for fingerprint matching.\n\nArchitecture\n------------\n\nThe Fingerprint HAL interacts with the following components.\n\n- `BiometricManager` interacts directly with an app in an app process. Each app has an instance of `IBiometricsFingerprint.hal`\n- `FingerprintService` operates in the system process, which handles communication with fingerprint HAL.\n- **Fingerprint HAL** is a C/C++ implementation of the IBiometricsFingerprint HIDL interface. This contains the vendor-specific library that communicates with the device-specific hardware.\n- **Keystore API and KeyMint (previously Keymaster)** components provide hardware-backed cryptography for secure key storage in a secure environment, such as the Trusted Execution Environment (TEE).\n\n**Figure 1.** High-level data flow for fingerprint authentication\n\nA vendor-specific HAL implementation must use the communication protocol\nrequired by a TEE. Raw images and processed fingerprint features must not\nbe passed in untrusted memory. All such biometric data needs to be stored\nin the secure hardware such as the TEE. Rooting **must not**\nbe able to compromise biometric data.\n\n`FingerprintService` and `fingerprintd` make calls through the Fingerprint HAL to\nthe vendor-specific library to enroll fingerprints and perform other\noperations.\n**Figure 2.** Interaction of the fingerprint daemon with the fingerprint vendor-specific library\n\nImplementation guidelines\n-------------------------\n\nThe following Fingerprint HAL guidelines are designed to ensure that\nfingerprint data is **not leaked** and is **removed**\nwhen a user is removed from a device:\n\n- Raw fingerprint data or derivatives (for example, templates) must never be accessible from outside the sensor driver or TEE. If the hardware supports a TEE, hardware access must be limited to the TEE and protected by an SELinux policy. The Serial Peripheral Interface (SPI) channel must be accessible only to the TEE and there must be an explicit SELinux policy on all device files.\n- Fingerprint acquisition, enrollment, and recognition must occur inside the TEE.\n- Only the encrypted form of the fingerprint data can be stored on the file system, even if the file system itself is encrypted.\n- Fingerprint templates must be signed with a private, device-specific key. For Advanced Encryption Standard (AES), at a minimum a template must be signed with the absolute file-system path, group, and finger ID such that template files are inoperable on another device or for anyone other than the user that enrolled them on the same device. For example, copying fingerprint data from a different user on the same device or from another device must not work.\n- Implementations must either use the file-system path provided by the `setActiveGroup()` function or provide a way to erase all user template data when the user is removed. It's strongly recommended that fingerprint template files be stored as encrypted and stored in the path provided. If this is infeasible due to TEE storage requirements, the implementer must add hooks to ensure removal of the data when the user is removed.\n\nFingerprint methods\n-------------------\n\nThe Fingerprint HIDL interface contains the following major methods in\n[`IBiometricsFingerprint.hal`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/biometrics/fingerprint/2.1/IBiometricsFingerprint.hal).\n\n| Method | Description |\n|------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| `enroll()` | Switches the HAL state machine to start the collection and storage of a fingerprint template. When enrollment is complete, or after a timeout, the HAL state machine returns to the idle state. |\n| `preEnroll()` | Generates a unique token to indicate the start of a fingerprint enrollment. Provides a token to the `enroll` function to ensure there was prior authentication, for example, using a password. To prevent tampering, the token is wrapped after the device credential is confirmed. The token must be checked during enrollment to verify that it's still valid. |\n| `getAuthenticatorId()` | Returns a token associated with the current fingerprint set. |\n| `cancel()` | Cancels pending enroll or authenticate operations. The HAL state machine is returned to the idle state. |\n| `enumerate()` | Synchronous call for enumerating all known fingerprint templates. |\n| `remove()` | Deletes a fingerprint template. |\n| `setActiveGroup()` | Restricts a HAL operation to a set of fingerprints that belong to a specified group, identified by a group identifier (GID). |\n| `authenticate()` | Authenticates a fingerprint-related operation (identified by an operation ID). |\n| `setNotify()` | Registers a user function that receives notifications from the HAL. If the HAL state machine is in a busy state, the function is blocked until the HAL leaves the busy state. |\n| `postEnroll()` | Finishes the enroll operation and invalidates the `preEnroll()` generated challenge. This must be called at the end of a multifinger enrollment session to indicate that no more fingers may be added. |\n\nFor more details on these, refer to the comments in [`IBiometricsFingerprint.hal`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/biometrics/fingerprint/2.1/IBiometricsFingerprint.hal)."]]
