La biometria offre un modo più comodo, 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. La biometria rientra nel livello secondario dell'autenticazione e offre 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 dei volti e dell'impronta. 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
- Introduce 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.
- Include il supporto 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
class che gli sviluppatori possono utilizzare per eseguire query sulla disponibilità dell'autenticazione biometrica. - Include l'integrazione dell'autenticazione tramite impronta e 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 da utilizzare
BiometricPrompt
eBiometricManager
. - Sono stati aggiornati i test dello strumento di verifica CTS
FingerprintManager
per testareBiometricPrompt
conBiometricPromptBoundKeysTest
.
Implementazione
Per garantire che utenti e sviluppatori possano avere un'esperienza biometrica senza interruzioni,
integra il tuo stack biometrico con le API BiometricPrompt
,
BiometricManager
e ACTION_BIOMETRIC_ENROLL
. I dispositivi con sensori biometrici devono rispettare questi requisiti
di forza.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 il dato biometrico può essere presentato solo se soddisfa la sicurezza richiesta. Se il dispositivo supporta più di una, questa azione dovrebbe presentare un elenco tra cui l'utente può scegliere.
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 relativi 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, impedisci la copia dei dati biometrici di un utente diverso sullo stesso dispositivo o da 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 eseguire la pulizia 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 spiega i rischi associati al dato biometrico (ad esempio, una tua foto potrebbe sbloccare il dispositivo).
Stringhe di autenticazione specifiche per il dispositivo
A partire da Android 12, le stringhe di autenticazione contestuale vengono rese disponibili agli 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 |
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 registrati (se possibile) che soddisfano i requisiti di autenticazione |
Utilizza la stringa solo biometrica (ad esempio "Usa impronta") |
getPromptMessage() |
Messaggio visualizzato su BiometricPrompt durante l'autenticazione |
Solo tipi registrati (se possibile) che soddisfano i requisiti di autenticazione |
Usa stringa di blocco schermo combinata (ad es. "Usa la tua impronta o il tuo PIN per continuare") |
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 di autenticazione |
Utilizza la stringa combinata di blocco schermo e dati biometrici (ad esempio, "Usa l'impronta o il blocco schermo") |
Ad esempio, prendi 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 seguente tabella fornisce stringhe di esempio per ogni combinazione di autenticatori consentiti e metodo BiometricManager.Strings richiamato:
autenticatori consentiti |
getButtonLabel() |
getPromptMessage() |
getSettingName() |
---|---|---|---|
Dati biometrici di classe 3 (BIOMETRIC_STRONG) |
"Usa l'impronta" (solo l'impronta soddisfa i requisiti dell'authenticator) |
"Usa la tua 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) |
"Utilizza 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 il 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 schermo soddisfano i requisiti; viene registrato solo il PIN) |
"Usa l'impronta o il blocco schermo" (l'impronta e qualsiasi blocco schermo soddisfano i requisiti) |
Blocco schermo biometrico OR 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 CTS
- BiometricPrompt CTS (test di conformità e approfonditi basati 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)