Panoramica
L'autenticazione facciale consente agli utenti di sbloccare il proprio dispositivo semplicemente guardando la parte anteriore del dispositivo. Android 10 aggiunge il supporto per un nuovo stack di autenticazione facciale in grado di elaborare in modo sicuro i fotogrammi della fotocamera, preservando sicurezza e privacy durante l'autenticazione facciale sull'hardware supportato. Android 10 fornisce inoltre un modo semplice per implementare implementazioni conformi alla sicurezza per consentire l'integrazione delle applicazioni per le transazioni, come servizi bancari online o altri servizi.
Lo stack di autenticazione facciale 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, inclusi viso, dito e iride. L'HAL Face interagisce con i seguenti componenti.
FaceManager
FaceManager è un'interfaccia privata che mantiene una connessione con FaceService . Viene utilizzato da Keyguard per accedere all'autenticazione facciale con un'interfaccia utente personalizzata. Le app non hanno accesso a FaceManager e devono invece utilizzare BiometricPrompt .
FaceService
Questa è l'implementazione del framework che gestisce l'accesso all'hardware di autenticazione facciale. Contiene macchine a stati di registrazione e autenticazione di base, nonché vari altri aiutanti (ad esempio, l'enumerazione). Per motivi di stabilità e sicurezza, in questo processo non è consentita l'esecuzione di alcun codice fornitore. È possibile accedere a tutto il codice del fornitore tramite l' interfaccia Face 1.0 HIDL .
affrontato
Questo è un eseguibile Linux che implementa l'interfaccia HIDL Face 1.0 utilizzata da FaceService . Si registra come IBiometricsFace@1.0 in modo che FaceService possa trovarlo.
Implementazione
Faccia HIDL
Per implementare Face HIDL, è necessario implementare tutti i metodi di IBiometricsFace.hal in una libreria specifica del fornitore.
Messaggio di errore
I messaggi di errore vengono inviati tramite una richiamata e riportano la macchina a stati allo stato inattivo dopo l'invio. La maggior parte dei messaggi hanno 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, vedere types.hal . Tutti i messaggi di errore rappresentano uno stato terminale, il che significa che il framework presuppone che l'HAL ritorni in uno stato inattivo dopo aver inviato un messaggio di errore.
Messaggi di acquisizione
I messaggi di acquisizione vengono recapitati durante la registrazione o l'autenticazione e hanno lo scopo di guidare l'utente verso una registrazione o un'autenticazione corretta. A ogni ordinale è associato un messaggio dal file FaceAuthenticationManager.java . È possibile aggiungere messaggi specifici del fornitore purché vengano fornite le stringhe di aiuto corrispondenti. I messaggi di acquisizione non sono stati terminali di per sé; si prevede che l'HAL ne invii il numero necessario per completare la registrazione o l'autenticazione corrente. Se un messaggio di acquisizione risulta in uno stato terminale in cui non è possibile fare alcun progresso, allora l'HAL dovrebbe seguire i messaggi di acquisizione con un messaggio di errore, ad esempio, dove 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 senza che sia possibile fare ulteriori progressi.
Hardware
Affinché i dispositivi siano conformi ai severi requisiti biometrici di Android 10, devono disporre di hardware sicuro per garantire l'integrità dei dati facciali e il confronto di autenticazione definitivo. Il documento di definizione della compatibilità Android (CDD) delinea il livello di sicurezza richiesto e il tasso di accettazione dello spoofing (SAR) accettabile richiesto. Per l'elaborazione e il riconoscimento sicuri è necessario un ambiente di esecuzione affidabile (TEE). Inoltre, è necessario un hardware sicuro per la fotocamera per prevenire attacchi di injection all'autenticazione facciale. Ad esempio, le pagine di memoria associate ai dati di immagine 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 TEE e l'hardware.
Poiché l'hardware per l'autenticazione facciale varia considerevolmente, è necessario sviluppare driver specifici dell'hardware per abilitare l'autenticazione facciale, a seconda dell'architettura specifica del dispositivo. Pertanto, 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 il potenziale ripristino del watchdog. Si consiglia di avere una coda di messaggi con più thread per evitare di bloccare il chiamante. Tutte le richieste GET dovrebbero memorizzare nella cache le informazioni ove possibile in modo che il chiamante venga bloccato per un periodo di tempo minimo.
| Metodo | Descrizione |
|---|---|
setCallback() | Chiamato da FaceService per ricondurre tutti i messaggi a se stesso. |
setActiveUser() | Imposta l'utente attivo a cui verranno applicate tutte le operazioni HAL successive. L'autenticazione è sempre per questo utente finché questo metodo non viene chiamato nuovamente. |
revokeChallenge() | Termina la transazione sicura invalidando la sfida generata da generateChallenge() . |
enroll() | Registra il volto di un utente. |
cancel() | Annulla l'operazione corrente (ad esempio, registrazione, autenticazione, rimozione o enumerazione) e ritorna allo stato faced . |
enumerate() | Enumera tutti i modelli di volti associati all'utente attivo. |
remove() | Rimuove un modello di volto o tutti i modelli di volto associati all'utente attivo. |
authenticate() | Autentica l'utente attivo. |
userActivity() | Questo metodo deve essere utilizzato solo quando l'HAL è nello stato di autenticazione o di standby. L'utilizzo di questo metodo quando l'HAL non è in uno di questi stati restituisce OPERATION_NOT_SUPPORTED . Chiamare questo metodo mentre l'HAL sta già effettuando l'autenticazione può prolungare il tempo in cui il sistema cerca un volto. |
resetLockout() | Quando vengono rifiutati troppi volti, è necessario che faced entri in uno stato di blocco ( LOCKOUT o LOCKOUT_PERMANENT ). Quando lo fa, è necessario inviare il tempo rimanente al framework in modo che possa visualizzarlo per l'utente. Come con setFeature() , questo metodo richiede un token di autenticazione hardware (HAT) attivo per reimpostare in modo sicuro lo stato interno. Reimposta il blocco solo per l'utente corrente. |
I tre metodi rimanenti sono tutti sincroni e dovrebbero bloccarsi per un periodo di tempo minimo per evitare lo stallo del framework.
| Metodo | Descrizione |
|---|---|
generateChallenge() | Genera un token casuale univoco e crittograficamente sicuro utilizzato per indicare l'inizio di una transazione sicura. |
setFeature() | Abilita o disabilita una funzionalità per l'utente corrente. Per motivi di sicurezza, ciò richiede che un HAT controlli il pin/modello/password dell'utente rispetto alla verifica di cui sopra |
getFeature() | Recupera lo stato di abilitazione corrente della funzionalità, come indicato dall'impostazione predefinita o da una chiamata a setFeature() sopra. Se l'ID volto non è valido, l'implementazione deve restituire ILLEGAL_ARGUMENT |
getAuthenticatorId() | Restituisce un identificatore associato al set di volti corrente. Questo identificatore deve cambiare ogni volta che viene aggiunto un volto |
Diagramma di stato
Il framework prevede che faced seguano il diagramma di stato riportato di seguito.
