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.

Questa pagina è stata tradotta dall'API Cloud Translation.

Biometria

La biometria offre un modo più pratico, ma potenzialmente meno sicuro, per confermare la tua identità con un dispositivo. Nel modello di autenticazione a più livelli, l'autenticazione principale (ovvero le modalità basate su fattori di conoscenza come PIN, sequenza e password) fornisce il massimo livello di sicurezza. I dati biometrici fanno parte del secondo livello di autenticazione e offrono un equilibrio tra comodità e sicurezza. La definizione di compatibilità Android definisce tre classi di robustezza biometrica: classe 3 (in precedenza Molto elevata), classe 2 (in precedenza Bassa) e classe 1 (in precedenza Comodità). Ogni corso ha un insieme di prerequisiti, privilegi e vincoli. Per maggiori dettagli, consulta il CDD riportato sopra. Tutte e tre le classi possono essere integrate con la schermata di blocco, ma solo gli autenticatori di tipo Forte e Debole possono essere integrati con le API android.hardware.biometrics. Questa tabella descrive ogni autenticatore e le funzionalità supportate.

Authenticator	Schermata di blocco	Integrazione di BiometricPrompt	Archivio chiavi (chiave basata sul tempo)	Archivio chiavi (chiave basata sulle operazioni)
BIOMETRIC_STRONG (classe 3)	Sì	Sì	Sì	Sì
BIOMETRIC_WEAK (classe 2)	Sì	Sì	No	No
BIOMETRIC_CONVENIENCE (Classe 1)	Sì	No	No	No
DEVICE_CREDENTIAL	Sì	Sì	Sì	Sì

Il framework Android include il supporto per l'autenticazione biometrica tramite volto e impronte digitali. Android può essere personalizzato per supportare altre modalità biometriche (ad esempio l'iride). Tuttavia, l'integrazione biometrica dipenderà dalla sicurezza biometrica, non dalla modalità. Per maggiori dettagli sulle specifiche di sicurezza biometrica, consulta Misurare la sicurezza dello sblocco biometrico.

Fonte

Android 12

Viene introdotta l'API BiometricManager.Strings, che fornisce stringhe localizzate per le app che utilizzano BiometricPrompt per l'autenticazione. Queste stringhe devono essere consapevoli del dispositivo e fornire maggiori dettagli sui tipi di autenticazione che possono essere utilizzati.
È inclusa la funzionalità del sensore di impronte digitali integrato nel display (UDFPS).

Android 11

Introduce l'interfaccia BiometricManager.Authenticators, che fornisce costanti che gli sviluppatori possono utilizzare per specificare i tipi di autenticazione accettati dalle loro app.
Aggiunge l'azione intent ACTION_BIOMETRIC_ENROLL, che gli sviluppatori possono utilizzare per indirizzare l'utente alla registrazione di un metodo di autenticazione che soddisfi i requisiti delle loro app.
Aggiunge il AuthenticationResult#getAuthenticationType() metodo, che gli sviluppatori possono utilizzare per verificare se l'utente si è autenticato utilizzando una credenziale biometrica o una credenziale del dispositivo.
Fornisce un supporto aggiuntivo per le chiavi auth-per-use all'interno della classe BiometricPrompt.

Android 10

Introduce la BiometricManager classe che gli sviluppatori possono utilizzare per eseguire query sulla disponibilità dell'autenticazione biometrica.
Include l'integrazione dell'autenticazione tramite impronta e riconoscimento del volto per BiometricPrompt

Android 9

Include l'integrazione dell'impronta solo per BiometricPrompt.
La classe FingerprintManager è deprecata. Se le app integrate e di sistema utilizzano questo gruppo, aggiornale in modo che utilizzino BiometricPrompt e BiometricManager.
Sono stati aggiornati i test del verificatore CTS di FingerprintManager per testare BiometricPrompt utilizzando BiometricPromptBoundKeysTest.

Implementazione

Per garantire a utenti e sviluppatori un'esperienza biometrica fluida, integra la tua suite biometrica con le API BiometricPrompt,BiometricManager e ACTION_BIOMETRIC_ENROLL. I dispositivi con sensori biometrici devono rispettare questi requisiti di robustezza.Inoltre, tutte le implementazioni devono superare il modulo CTS CtsBiometricsTestCases.

Per integrare lo stack biometrico con l'API ACTION_BIOMETRIC_ENROLL:

Modifica BiometricEnrollActivity per presentare il flusso di registrazione. Tieni presente che i dati biometrici possono essere presentati solo se soddisfano la sicurezza richiesta. Se il dispositivo supporta più di uno, questa azione dovrebbe presentare un elenco tra cui l'utente può scegliere.

**Figura 1.** Architettura di BiometricPrompt

Linee guida per l'implementazione di HAL

Segui queste linee guida per l'HAL biometrico per assicurarti che i dati biometrici non vengano divulgati e vengano rimossi quando un utente viene rimosso da un dispositivo:

Assicurati che i dati biometrici non elaborati o i dati derivati (ad esempio i modelli) non siano mai accessibili dall'esterno dell'ambiente sicuro e isolato (ad esempio il TEE o l'elemento sicuro). Tutti i dati memorizzati devono essere criptati con una chiave specifica per il dispositivo nota solo al TEE (Trusted Execution Environment). Se l'hardware lo supporta, limita l'accesso hardware all'ambiente isolato sicuro e proteggilo con un criterio SELinux. Rendi il canale di comunicazione (ad esempio SPI, I2C) accessibile solo all'ambiente isolato sicuro con un criterio SELinux esplicito su tutti i file del dispositivo.
L'acquisizione, la registrazione e il riconoscimento biometrico devono avvenire all'interno di un ambiente sicuro e isolato per prevenire violazioni dei dati e altri attacchi. Questo requisito si applica solo alla biometria di classe 3 (in precedenza Molto sicura) e di classe 2 (in precedenza Poco sicura).
Per proteggerti dagli attacchi di replay, firma i modelli biometrici con una chiave privata specifica per il dispositivo. Per Advanced Encryption Standard (AES), firma almeno un modello con il percorso assoluto del file system, il gruppo e l'ID biometrico in modo che i file modello non siano operativi su un altro dispositivo o per chiunque non sia l'utente che li ha registrati sullo stesso dispositivo. Ad esempio, impediscono la copia degli dati biometrici di un utente diverso sullo stesso dispositivo o su un altro dispositivo.
Se devi archiviare i dati al di fuori del TEE, utilizza il percorso del file system fornito dal setActiveUser() HIDL method o fornisci un altro modo per cancellare tutti i dati del modello utente quando l'utente viene rimosso. Il motivo è proteggere la fuga di dati utente. I dispositivi che non utilizzano questo percorso devono essere ripuliti dopo la rimozione dell'utente. Il CDD richiede che i dati biometrici e i file derivati vengano archiviati criptati, in particolare se non in TEE. Se ciò non è fattibile a causa dei requisiti di archiviazione dell'ambiente isolato sicuro, aggiungi hook per garantire la rimozione dei dati quando l'utente viene rimosso o il dispositivo viene resettato. Vedi LockSettingsService.removeBiometricsForUser()

Personalizzazione

Se il dispositivo supporta più metodi biometrici, l'utente dovrebbe essere in grado di specificare un valore predefinito nelle impostazioni. L'implementazione di BiometricPrompt dovrebbe dare la preferenza al dato biometrico di classe 3 (in precedenza "Forte") come valore predefinito, a meno che l'utente non lo sostituisca esplicitamente. In questo caso, deve essere visualizzato un messaggio di avviso che spieghi i rischi associati al dato biometrico (ad esempio, una tua foto potrebbe sbloccare il dispositivo).

Stringhe di autenticazione specifiche del dispositivo

A partire da Android 12, le stringhe di autenticazione contestuale vengono messe a disposizione degli sviluppatori tramite l'API BiometricManager.Strings. Puoi personalizzare i valori delle risorse restituiti da questa API per implementare stringhe specifiche per il dispositivo. In questo caso, assicurati che le nuove stringhe siano tradotte per tutte le lingue supportate dal dispositivo. Inoltre, assicurati che le seguenti proprietà vengano conservate:

Metodo	Scopo della stringa	Tipo o tipi di autenticazione da includere	Se sono possibili sia i dati biometrici sia il blocco schermo
getButtonLabel()	Etichetta per un pulsante che attiva BiometricPrompt	Solo tipi di registrazione (se possibile) che soddisfano i requisiti degli autenticatori	Utilizza la stringa solo biometrica (ad esempio "Usa impronta")
getPromptMessage()	Messaggio visualizzato su BiometricPrompt durante l'autenticazione	Solo tipi di registrazione (se possibile) che soddisfano i requisiti degli autenticatori	Utilizza la stringa combinata di blocco schermo e dati biometrici (ad es. "Per continuare, usa la tua impronta o il tuo PIN")
getSettingName()	Nome di un'impostazione che attiva BiometricPrompt per l'autenticazione	Tutti i tipi supportati dal dispositivo (anche se non registrati) che soddisfano i requisiti degli autenticatori	Utilizza la stringa combinata di blocco schermo e dati biometrici (ad esempio, "Usa l'impronta o il blocco schermo")

Ad esempio, prendiamo in considerazione un dispositivo con un sensore di rilevamento del volto di classe 2 con un volto registrato, un PIN registrato e un sensore di impronte di classe 3 con nessuna impronta registrata. La tabella seguente fornisce stringhe di esempio per ogni combinazione di autenticatori consentiti e metodo BiometricManager.Strings invocato:

Autenticatori consentiti	getButtonLabel()	getPromptMessage()	getSettingName()
Dati biometrici di classe 3 (BIOMETRIC_STRONG)	"Usa l'impronta" (solo l'impronta soddisfa i requisiti dell'authenticator)	"Usa l'impronta per continuare" (solo l'improntasoddisfa i requisiti dell'autenticatore)	"Usa l'impronta" (solo l'impronta soddisfa i requisiti dell'authenticator)
Dati biometrici di classe 2 (BIOMETRIC_WEAK)	"Usa il volto" (il volto e l'impronta soddisfano i requisiti; è registrato solo il volto)	"Usa il tuo volto per continuare" (il volto e l'improntasoddisfano i requisiti; è registrato solo il volto)	"Usa il volto o l'impronta" (il volto e l'impronta soddisfano i requisiti; il dispositivo supporta entrambi)
Blocco schermo (DEVICE_CREDENTIAL)	"Usa PIN" (qualsiasi blocco schermo soddisfa i requisiti; il PIN è registrato)	"Inserisci il PIN per continuare" (qualsiasi blocco schermo soddisfa i requisiti; il PIN è registrato)	"Usa blocco schermo" (qualsiasi blocco schermo soddisfa i requisiti)
Blocco schermo OPPURE biometrico di classe 3	"Usa PIN" (l'impronta e qualsiasi blocco schermo soddisfano i requisiti; è registrato solo il PIN)	"Inserisci il PIN per continuare" (l'impronta e qualsiasi blocco dello schermosoddisfano i requisiti; è registrato solo il PIN)	"Usa l'impronta o il blocco schermo" (l'impronta e qualsiasi blocco schermo soddisfano i requisiti)
Blocco schermo OPPURE biometrico di Classe 2	"Usa il volto" (il volto, l'impronta e qualsiasi blocco schermosoddisfano i requisiti; il volto è registrato e sostituisce il PIN)	"Per continuare, devi usare il tuo volto o il tuo PIN" (il volto, l'impronta e qualsiasi blocco schermo soddisfano i requisiti; il volto e il PIN sono registrati)	"Usa i dati biometrici o il blocco schermo" (il volto, l'impronta e qualsiasi blocco schermo soddisfano i requisiti)

Convalida

L'implementazione biometrica deve superare i seguenti test:

BiometricManager di CTS
BiometricPrompt CTS (controllo di attendibilità, i test approfonditi si basano sul verificatore)
Sezione del test biometrico CtsVerifier: deve essere superato singolarmente con ogni modalità supportata dal dispositivo

Inoltre, se il dispositivo supporta un dato biometrico con un HIDL AOSP (fingerprint@2.1, fingerprint@2.2, face1.0), deve superare il test VTS pertinente (fingerprint, face)