A partire dal 27 marzo 2025, ti consigliamo di utilizzare android-latest-release anziché aosp-main per compilare e contribuire ad AOSP. Per ulteriori informazioni, vedi Modifiche ad AOSP.
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Sui dispositivi con sensore di impronte digitali, gli utenti possono registrare una o più impronte e utilizzarle per sbloccare il dispositivo ed eseguire altre attività. Android utilizza il linguaggio di definizione dell'interfaccia hardware per le impronte
(HIDL) per connettersi a una libreria specifica del fornitore e all'hardware per le impronte (ad esempio, un sensore di impronte).
Per implementare l'HIDL Fingerprint, devi implementare IBiometricsFingerprint.hal
in una libreria specifica del fornitore.
Corrispondenza dell'impronta
Il sensore di impronte digitali di un dispositivo è generalmente inattivo. Tuttavia, in risposta a
una chiamata a authenticate o enroll, il
sensore di impronte digitali rileva un tocco (lo schermo potrebbe anche riattivarsi quando un utente
tocca il sensore di impronte digitali). Il flusso generale della corrispondenza delle impronte
include i seguenti passaggi:
L'utente appoggia un dito sul sensore di impronte digitali.
La libreria specifica del fornitore determina se esiste una corrispondenza dell'impronta
nell'insieme corrente di modelli di impronte registrati.
I risultati corrispondenti vengono passati a FingerprintService.
Questo flusso presuppone che un'impronta sia già stata registrata sul dispositivo, ovvero
la libreria specifica del fornitore abbia registrato un modello per l'impronta. Per maggiori
dettagli, vedi Autenticazione.
Architettura
L'HAL Fingerprint interagisce con i seguenti componenti.
BiometricManager interagisce direttamente con un'app in un processo dell'app.
Ogni app ha un'istanza di IBiometricsFingerprint.hal
FingerprintService opera nel
processo di sistema, che gestisce la comunicazione con l'HAL delle impronte.
Fingerprint HAL è un'implementazione C/C++ dell'interfaccia
IBiometricsFingerprint HIDL. Contiene la libreria specifica del fornitore
che comunica con l'hardware specifico del dispositivo.
I componenti API Keystore e KeyMint (in precedenza Keymaster) forniscono
crittografia basata su hardware per l'archiviazione sicura delle chiavi in un ambiente sicuro,
come il Trusted Execution Environment (TEE).
Figura 1. Flusso di dati di alto livello per l'autenticazione
tramite impronta
Un'implementazione HAL specifica del fornitore deve utilizzare il protocollo di comunicazione
richiesto da un TEE. Le immagini non elaborate e le funzionalità di impronta elaborate non devono
essere trasmesse in una memoria non attendibile. Tutti questi dati biometrici devono essere archiviati
nell'hardware sicuro, ad esempio il TEE. Il rooting non deve
essere in grado di compromettere i dati biometrici.
FingerprintService e fingerprintd effettuano chiamate tramite l'HAL delle impronte all'interno della libreria specifica del fornitore per registrare le impronte ed eseguire altre operazioni.
Figura 2. Interazione del daemon delle impronte
con la libreria specifica del fornitore di impronte
Linee guida per l'implementazione
Le seguenti linee guida HAL per le impronte sono progettate per garantire che
i dati delle impronte non vengano divulgati e vengano rimossi
quando un utente viene rimosso da un dispositivo:
I dati grezzi delle impronte o i derivati (ad esempio i modelli) non devono mai essere accessibili dall'esterno del driver del sensore o del TEE. Se l'hardware supporta
un TEE, l'accesso all'hardware deve essere limitato al TEE e protetto da norme SELinux. Il canale Serial Peripheral Interface (SPI) deve essere accessibile solo al TEE e deve essere presente una norma SELinux esplicita su tutti i file del dispositivo.
L'acquisizione, la registrazione e il riconoscimento delle impronte devono avvenire all'interno del TEE.
I dati relativi alle impronte possono essere memorizzati nel file
system solo in forma criptata, anche se il file system stesso è criptato.
I modelli di impronta devono essere firmati con una chiave privata specifica del dispositivo.
Per l'Advanced Encryption Standard (AES), un modello deve essere firmato almeno
con il percorso assoluto del file system, il gruppo e l'ID impronta in modo che i file
del modello non siano utilizzabili su un altro dispositivo o da chiunque altro che non sia l'utente che
li ha registrati sullo stesso dispositivo. Ad esempio, copiare i dati delle impronte di un utente diverso sullo stesso dispositivo o da un altro dispositivo non deve funzionare.
Le implementazioni devono utilizzare il percorso del file system fornito dalla funzione
setActiveGroup() o fornire un modo per cancellare tutti i dati dei modelli utente quando l'utente viene rimosso. È consigliabile
che i file modello delle impronte vengano archiviati in formato criptato e nel percorso fornito. Se ciò
non è fattibile a causa dei requisiti di archiviazione TEE, l'implementatore deve aggiungere hook per
garantire la rimozione dei dati quando l'utente viene rimosso.
Passa alla macchina a stati HAL per avviare la
raccolta e l'archiviazione di un modello di impronta. Al termine della registrazione o dopo un timeout, la macchina a stati HAL torna allo stato inattivo.
preEnroll()
Genera un token univoco per indicare l'inizio di una
registrazione dell'impronta. Fornisce un token alla funzione enroll per
assicurarsi che sia stata eseguita un'autenticazione precedente, ad esempio utilizzando una password. Per evitare
manomissioni, il token viene eseguito il wrapping dopo la conferma
delle credenziali del dispositivo. Il token deve essere controllato durante la registrazione per verificare
che sia ancora valido.
getAuthenticatorId()
Restituisce un token associato al
set di impronte corrente.
cancel()
Annulla le operazioni di registrazione o autenticazione in attesa. La
macchina a stati HAL torna allo stato di inattività.
enumerate()
Chiamata sincrona per enumerare tutti i modelli di impronte noti.
remove()
Elimina un modello di impronta.
setActiveGroup()
Limita un'operazione HAL a un insieme di
impronte che appartengono a un gruppo specificato, identificato da un identificatore di gruppo
(GID).
authenticate()
Autentica un'operazione correlata all'impronta
(identificata da un ID operazione).
setNotify()
Registra una funzione utente che riceve
le notifiche dall'HAL. Se la macchina a stati HAL è in uno stato occupato, la
funzione viene bloccata finché HAL non esce dallo stato occupato.
postEnroll()
Termina l'operazione di registrazione e invalida la
sfida preEnroll() generata. Questo metodo deve essere chiamato alla fine di una
sessione di registrazione multifinger per indicare che non è possibile aggiungere altre dita.
I campioni di contenuti e codice in questa pagina sono soggetti alle licenze descritte nella Licenza per i contenuti. Java e OpenJDK sono marchi o marchi registrati di Oracle e/o delle sue società consociate.
Ultimo aggiornamento 2025-07-27 UTC.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Mancano le informazioni di cui ho bisogno","missingTheInformationINeed","thumb-down"],["Troppo complicato/troppi passaggi","tooComplicatedTooManySteps","thumb-down"],["Obsoleti","outOfDate","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Problema relativo a esempi/codice","samplesCodeIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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)."]]