HIDL autenticazione volti

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. Stack biometrico.

Gestore facciale

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

Si tratta dell'implementazione del framework che gestisce l'accesso all'hardware di autenticazione dei volti. Contiene VM di base per la registrazione e l'autenticazione, nonché vari altri helper (ad esempio l'enumerazione). Per motivi di stabilità e sicurezza, in questo processo non è consentito eseguire alcun codice del fornitore. È possibile accedere a tutto il codice del fornitore tramite l'interfaccia Face 1.0 HIDL.

faccia a faccia

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 puoi trovarlo.

Implementazione

HIDL per il volto

Per implementare Face HIDL, 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 funzione di callback e restituiscono la macchina a stati allo stato idle dopo l'invio. La maggior parte dei messaggi ha una stringa corrispondente rivolta all'utente che informa 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 sulle acquisizioni

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. A ogni ordinale è associato un messaggio 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 avanzata per Android 10, devono disporre di 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 per i dati delle immagini potrebbero essere contrassegnate con privilegi 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 facciale varia notevolmente, è necessario sviluppare driver specifici per l'hardware per abilitare l'autenticazione facciale, 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. Consigliamo di 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 viene sempre eseguita per questo utente fino a quando questo metodo non viene richiamato.
revokeChallenge()	Completa la transazione sicura annullando la verifica 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 di inattività.
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 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()	Se 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 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, questo richiede che un HAT controlli il PIN/la sequenza/la password dell'utente in base alla verifica precedente
getFeature()	Recupera lo stato di abilitazione attuale della funzionalità, come dettato per 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.