Panoramica
L'autenticazione volti consente agli utenti di sbloccare il dispositivo semplicemente guardando la parte anteriore. Android 10 aggiunge il supporto per un nuovo stack di autenticazione facciale in grado di elaborare in modo sicuro i frame della fotocamera, preservando la sicurezza e la privacy durante l'autenticazione facciale sull'hardware supportato. Android 10 offre inoltre un modo semplice per le implementazioni conformi alla sicurezza di abilitare l'integrazione delle applicazioni per le transazioni, come l'online banking o altri servizi.
La suite di autenticazione volti di Android è una nuova implementazione in Android 10. La nuova implementazione introduce le interfacce IBiometricsFace.hal,
IBiometricsFaceClientCallback.hal,
e types.hal.
Architettura
L'API BiometricPrompt include tutta l'autenticazione biometrica, tra cui volto, dito e iride. L'HAL Face interagisce con i seguenti componenti.
Figura 1. Impianto biometrico.
FaceManager
FaceManager è un'interfaccia privata che mantiene una connessione con FaceService. Viene utilizzato dalla schermata di blocco per accedere all'autenticazione volti con un'interfaccia utente personalizzata. Le app non hanno accesso a FaceManager e devono utilizzare BiometricPrompt.
FaceService
Questa è l'implementazione del framework che gestisce l'accesso all'hardware per l'autenticazione dei volti. Contiene macchine di stato di registrazione e autenticazione di base, nonché vari altri helper (ad esempio l'enumerazione). Per motivi di stabilità e sicurezza, in questo processo non è consentito eseguire alcun codice del fornitore. A tutto il codice del fornitore si accede tramite l'interfaccia HIDL di Face 1.0.
di fronte
Si tratta di un file eseguibile Linux che implementa l'interfaccia HIDL di Face 1.0 utilizzata da FaceService. Si registra come IBiometricsFace@1.0 in modo che FaceService
possa trovarlo.
Implementazione
HIDL per il volto
Per implementare l'HIDL di Face, devi implementare tutti i metodi di IBiometricsFace.hal
in una libreria specifica del fornitore.
Messaggi di errore
I messaggi di errore vengono inviati da una chiamata di callback e restituiscono la macchina a stati allo stato idle dopo l'invio. La maggior parte dei messaggi ha una stringa rivolta all'utente corrispondente per informare l'utente dell'errore, ma non tutti gli errori hanno questa stringa rivolta all'utente. Per ulteriori informazioni sui messaggi di errore, consulta
types.hal.
Tutti i messaggi di errore rappresentano uno stato terminale, il che significa che il framework presuppone che l'HAL ritorni a uno stato inattivo dopo aver inviato un messaggio di errore.
Messaggi di acquisizione
I messaggi di acquisizione vengono inviati durante la registrazione o l'autenticazione e hanno lo scopo di guidare l'utente verso una registrazione o un'autenticazione riuscite.
Ogni ordinale ha un messaggio associato del file FaceAuthenticationManager.java. È possibile aggiungere messaggi specifici del fornitore, a condizione che vengano fornite le stringhe di aiuto corrispondenti. I messaggi di acquisizione non sono stati di per sé stati terminali; l'HAL dovrebbe inviarne quanti necessari per completare la registrazione o l'autenticazione in corso. Se un messaggio di acquisizione
determina uno stato terminale in cui non è possibile avanzare, l'HAL deve
seguire i messaggi di acquisizione con un messaggio di errore, ad esempio se
l'immagine è troppo scura e rimane troppo scura per poter procedere. In questo caso, è ragionevole inviare UNABLE_TO_PROCESS dopo aver effettuato diversi tentativi, ma non è possibile fare ulteriori progressi.
Hardware
Affinché i dispositivi siano conformi ai requisiti di autenticazione biometrica per Android 10, devono avere hardware sicuro per garantire l'integrità dei dati del volto e il confronto di autenticazione definitivo. Il Compatibility Definition Document (CDD) di Android illustra il livello di sicurezza richiesto e il tasso di accettazione dello spoofing (SAR) accettabile. Per l'elaborazione e il riconoscimento sicuri è necessario un ambiente di esecuzione affidabile (TEE). Inoltre, è necessario hardware della fotocamera sicuro per difendersi dagli attacchi di inserimento sull'autenticazione facciale. Ad esempio, le pagine di memoria associate ai dati delle immagini potrebbero essere privilegiate e contrassegnate come di sola lettura, in modo che solo l'hardware della fotocamera possa aggiornarle. Idealmente, nessun processo dovrebbe avere accesso, tranne il TEE e l'hardware.
Poiché l'hardware per l'autenticazione dei volti varia notevolmente, è necessario sviluppare driver specifici per l'hardware per abilitare l'autenticazione dei volti, a seconda dell'architettura specifica del dispositivo. Di conseguenza, non esiste un'implementazione di riferimento per faced.
Metodi
I seguenti metodi sono tutti asincroni e devono tornare immediatamente al framework. In caso contrario, il sistema sarà lento e potrebbero verificarsi potenziali reset del watchdog. È consigliabile avere una coda di messaggi con più thread per evitare di bloccare il chiamante. Ove possibile, tutte le richieste GET devono memorizzare nella cache le informazioni in modo che il chiamante venga bloccato per un periodo di tempo minimo.
| Metodo | Descrizione |
|---|---|
setCallback() |
Chiamato da FaceService per riassegnare tutti i messaggi a se stesso. |
setActiveUser() |
Imposta l'utente attivo a cui vengono applicate tutte le operazioni HAL successive. L'autenticazione è sempre per questo utente finché questo metodo non viene chiamato di nuovo. |
revokeChallenge() |
Completa la transazione sicura invalidando la verifica generata da generateChallenge(). |
enroll() |
Registra il volto di un utente. |
cancel() |
Annulla l'operazione in corso (ad esempio registrazione, autenticazione, rimozione o enumerazione) e restituisce faced allo stato inattivo. |
enumerate() |
Elenca tutti i modelli di viso associati all'utente attivo. |
remove() |
Rimuove un modello di viso o tutti i modelli di viso associati all'utente attivo. |
authenticate() |
Autentica l'utente attivo. |
userActivity() |
Questo metodo deve essere utilizzato solo quando l'HAL è in stato di autenticazione o di standby. L'utilizzo di questo metodo quando l'HAL non è in uno di questi stati
restituisce OPERATION_NOT_SUPPORTED. Se chiami questo metodo mentre l'HAL è già in fase di autenticazione, il tempo di ricerca di un volto da parte del sistema potrebbe prolungarsi. |
resetLockout() |
Quando vengono rifiutati troppi volti, faced deve inserire uno stato di blocco (LOCKOUT o LOCKOUT_PERMANENT). In questo caso, deve inviare il tempo rimanente al framework in modo che possa mostrarlo all'utente. Come per setFeature(), questo metodo richiede un
token di autenticazione hardware (HAT) attivo per reimpostare in sicurezza lo stato interno. Reimposta il blocco
solo per l'utente corrente. |
I tre metodi rimanenti sono tutti sincroni e dovrebbero bloccarsi per il tempo minimo necessario per evitare di bloccare il framework.
| Metodo | Descrizione |
|---|---|
generateChallenge() |
Genera un token casuale univoco e crittograficamente sicuro utilizzato per indicare l'inizio di una transazione sicura. |
setFeature() |
Attiva o disattiva una funzionalità per l'utente corrente. Per motivi di sicurezza, è necessario che un HAT controlli il PIN/la sequenza/la password dell'utente in base alla verifica precedente |
getFeature() |
Recupera lo stato di attivazione corrente della funzionalità, come stabilito dall'impostazione predefinita o da una chiamata a setFeature() sopra. Se il Face ID non è valido, l'implementazione deve restituire ILLEGAL_ARGUMENT |
getAuthenticatorId() |
Restituisce un identificatore associato all'insieme di volti corrente. Questo identificatore deve cambiare ogni volta che viene aggiunto un volto |
Diagramma di stato
Il framework si aspetta che faced segua il diagramma di stato riportato di seguito.
Figura 2. Flusso dello stato dell'autenticazione volti.