HIDL di autenticazione dei volti

Panoramica

L'autenticazione del volto consente agli utenti di sbloccare il dispositivo semplicemente guardando la parte anteriore del dispositivo. Android 10 aggiunge il supporto per un nuovo stack di autenticazione del volto in grado di elaborare in modo sicuro i frame della videocamera, preservando la sicurezza e la privacy durante l'autenticazione del volto su hardware supportato. Android 10 offre anche un modo semplice per implementazioni conformi alla sicurezza per abilitare l'integrazione delle applicazioni per transazioni, come l'online banking o altri servizi.

Lo stack 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 tutte le autenticazioni biometriche, tra cui volto, dito e iride. Face HAL interagisce con i seguenti componenti.

Figura 1. Stack biometrico.

FaceManager

FaceManager è un'interfaccia privata che mantiene una connessione con FaceService. Viene utilizzato da Keyguard per accedere all'autenticazione dei 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 a stati di registrazione e autenticazione di base, nonché vari altri helper (ad esempio, l'enumerazione). Per motivi di stabilità e sicurezza, non è consentito eseguire alcun codice fornitore in questo processo. A tutto il codice fornitore si accede tramite l'interfaccia HIDL Face 1.0.

affrontato

Si tratta di 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

Face HIDL

Per implementare l'interfaccia HIDL per il volto, devi implementare tutti i metodi di IBiometricsFace.hal in una libreria specifica del fornitore.

Messaggi di errore

I messaggi di errore vengono inviati da un callback e riportano la macchina a stati allo stato inattivo dopo l'invio. La maggior parte dei messaggi ha una stringa visibile all'utente corrispondente per informarlo dell'errore, ma non tutti gli errori hanno questa stringa visibile all'utente. Per ulteriori informazioni sui messaggi di errore, vedi types.hal. Tutti i messaggi di errore rappresentano uno stato terminale, il che significa che il framework presuppone che l'HAL torni a uno stato di inattività dopo l'invio di un messaggio di errore.

Messaggi sull'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 riuscita. Ogni ordinale ha un messaggio associato dal 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 terminali di per sé; l'HAL deve inviarne il numero necessario per completare la registrazione o l'autenticazione corrente. Se un messaggio di acquisizione genera uno stato terminale in cui non è possibile fare progressi, l'HAL deve seguire i messaggi di acquisizione con un messaggio di errore, ad esempio quando l'immagine è troppo scura e rimane troppo scura per fare progressi. In questo caso, è ragionevole inviare UNABLE_TO_PROCESS dopo diversi tentativi senza ulteriori progressi.

Hardware

Per rispettare i requisiti di biometria avanzata per Android 10, i dispositivi devono disporre di hardware sicuro per garantire l'integrità dei dati del volto e il confronto finale per l'autenticazione. Il Compatibility Definition Document (CDD) di Android 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 Trusted Execution Environment (TEE). Inoltre, è necessario un hardware della videocamera sicuro per prevenire attacchi di iniezione sull'autenticazione del volto. 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 videocamera possa aggiornarle. Idealmente, nessun processo dovrebbe avere accesso, tranne TEE e l'hardware.

Poiché l'hardware per l'autenticazione del volto varia notevolmente, è necessario sviluppare driver specifici per l'hardware per attivare l'autenticazione del volto, 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 potrebbero verificarsi ripristini di Watchdog. È consigliabile avere una coda di messaggi con più thread per evitare di bloccare il chiamante. Tutte le richieste GET devono 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 inviare 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 sfida generata da generateChallenge().
enroll()	Registra il volto di un utente.
cancel()	Annulla l'operazione corrente (ad esempio registrazione, autenticazione, rimozione o enumerazione) e riporta faced allo stato inattivo.
enumerate()	Elenca tutti i modelli del volto associati all'utente attivo.
remove()	Rimuove un modello del volto o tutti i modelli del 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 standby. L'utilizzo di questo metodo quando l'HAL non si trova in uno di questi stati restituisce OPERATION_NOT_SUPPORTED. La chiamata di questo metodo mentre l'HAL è già in fase di autenticazione potrebbe prolungare il tempo in cui il sistema cerca un volto.
resetLockout()	Quando vengono rifiutati troppi volti, faced deve entrare in uno stato di blocco (LOCKOUT o LOCKOUT_PERMANENT). In questo caso, deve inviare il tempo rimanente al framework in modo che possa visualizzarlo per l'utente. Come per 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 devono bloccare 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 HAT verifichi il PIN/la sequenza/la password dell'utente rispetto alla sfida precedente.
getFeature()	Recupera lo stato di attivazione corrente della funzionalità, come indicato dalla chiamata predefinita o a setFeature() sopra. Se l'ID viso 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 segua il diagramma di stato riportato di seguito.

Figura 2. Flusso di stati dell'autenticazione volti.