Google is committed to advancing racial equity for Black communities. See how.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Autenticazione facciale HIDL

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 la sicurezza e la privacy durante l'autenticazione del viso sull'hardware supportato. Android 10 fornisce anche un modo semplice per implementazioni conformi alla sicurezza per abilitare l'integrazione dell'applicazione per le transazioni, come l'online banking o altri servizi.

Lo stack di autenticazione facciale Android è una nuova implementazione in Android 10. La nuova implementazione introduce le IBiometricsFace.hal , IBiometricsFaceClientCallback.hal e types.hal .

Architettura

L'API BiometricPrompt include tutta l'autenticazione biometrica, inclusi viso, dito e iride. The Face HAL interagisce con i seguenti componenti.

Stack biometrico
Figura 1. Stack biometrico

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 la registrazione di base e le macchine a stati di autenticazione, nonché vari altri helper (ad esempio, l'enumerazione). A causa di problemi di stabilità e sicurezza, nessun codice del fornitore può essere eseguito in questo processo. Si accede a tutto il codice 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 da una richiamata e riportano la macchina a stati allo stato inattivo dopo essere stati inviati. 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, vedere types.hal . Tutti i messaggi di errore rappresentano uno stato terminale, il che significa che il framework presume che l'HAL ritorni a uno stato inattivo dopo aver inviato un messaggio di errore.

Messaggi di acquisizione

I messaggi di acquisizione vengono consegnati durante la registrazione o l'autenticazione e hanno lo scopo di guidare l'utente verso una registrazione o autenticazione corretta. Ogni ordinale ha un messaggio associato dal file FaceAuthenticationManager.java . È possibile aggiungere messaggi specifici del fornitore a condizione che vengano fornite le stringhe della guida corrispondenti. I messaggi di acquisizione non sono stati terminali in sé e per sé; si prevede che l'HAL invii tutti i dati necessari per completare la registrazione o l'autenticazione corrente. Se un messaggio di acquisizione risulta in uno stato terminale in cui non è possibile effettuare alcun progresso, l'HAL dovrebbe seguire i messaggi di acquisizione con un messaggio di errore, ad esempio, in cui l'immagine è troppo scura e rimane troppo scura per il progresso. In questo caso, è ragionevole inviare UNABLE_TO_PROCESS dopo diversi tentativi, ma non è possibile fare ulteriori progressi.

Hardware

Affinché i dispositivi siano conformi ai severi requisiti biometrici per Android 10, devono disporre di hardware sicuro per garantire l'integrità dei dati del viso e il massimo confronto di autenticazione. L'Android Compatibility Definition Document (CDD) delinea il livello di sicurezza richiesto e il tasso di accettazione dello spoofing (SAR) accettabile richiesto. Un ambiente di esecuzione affidabile (TEE) è necessario per l'elaborazione e il riconoscimento sicuri. Inoltre, è necessario un hardware sicuro per la fotocamera per prevenire attacchi di iniezione all'autenticazione facciale. Ad esempio, le pagine di memoria associate per i dati di immagine potrebbero essere privilegiate e contrassegnate come di sola lettura in modo che solo l'hardware della telecamera possa aggiornarle. Idealmente, nessun processo dovrebbe avere accesso tranne TEE e l'hardware.

Poiché l'hardware di autenticazione facciale varia notevolmente, è necessario sviluppare driver specifici per l'hardware per abilitare l'autenticazione facciale, a seconda dell'architettura specifica del dispositivo. In quanto tale, non esiste un'implementazione di riferimento per faced .

Metodi

I metodi seguenti sono tutti asincroni e devono tornare immediatamente al framework. In caso contrario, si verificherà un sistema lento e potenziali reimpostazioni di Watchdog. Si consiglia di avere una coda messaggi con più thread per evitare di bloccare il chiamante. Tutte le richieste GET dovrebbero memorizzare le informazioni nella cache, ove possibile, in modo che il chiamante venga bloccato per un periodo di tempo minimo.

Metodo Descrizione
setCallback() Chiamato da FaceService per FaceService tutti i messaggi a se stesso.
setActiveUser() Imposta l'utente attivo, al quale vengono applicate tutte le successive operazioni HAL. L'autenticazione è sempre per questo utente fino a quando questo metodo non viene chiamato di nuovo.
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, iscriversi, autenticazione, rimuovere o enumerate) e ritorna faced allo stato di riposo.
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 è in stato di autenticazione o standby. L'utilizzo di questo metodo quando l'HAL non si trova in uno di questi stati restituisce OPERATION_NOT_SUPPORTED . Chiamare questo metodo mentre l'HAL è già in fase di autenticazione può prolungare il tempo in cui il sistema cerca un volto.
resetLockout() Quando vengono rifiutate troppe facce, è necessario che la 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 attivo (HAT) per ripristinare 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 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() Abilita o disabilita una funzionalità per l'utente corrente. Per motivi di sicurezza, ciò richiede che un HAT controlli il pin / pattern / password dell'utente rispetto alla sfida di cui sopra
getFeature() Recupera lo stato di abilitazione corrente della funzione, come stabilito dal valore predefinito o da una chiamata a setFeature() sopra. Se l'ID viso non è valido, l'implementazione deve restituire ILLEGAL_ARGUMENT
getAuthenticatorId() Restituisce un identificatore associato al gruppo di facce corrente. Questo identificatore deve cambiare ogni volta che viene aggiunto un volto

Diagramma di stato

Il quadro si aspetta che faced segua il diagramma di stato sottostante.

Diagramma di stato
Figura 2. Flusso dello stato dell'autenticazione facciale