Autenticazione

Android utilizza il concetto di chiavi crittografiche controllate dall'autenticazione dell'utente che richiede i seguenti componenti:

• Fornitore di servizi e archiviazione di chiavi crittografiche. Memorizza le chiavi crittografiche e fornisce routine crittografiche standard su tali chiavi. Android supporta un Keystore e un Keymaster supportati da hardware per i servizi di crittografia, inclusa la crittografia supportata da hardware per l'archiviazione delle chiavi che potrebbe includere un Trusted Execution Environment (TEE) o Secure Element (SE), come Strongbox.
• Autenticatori dell'utente. Attestare la presenza dell'utente e/o l'avvenuta autenticazione. Android supporta Gatekeeper per l'autenticazione PIN/sequenza/password e Fingerprint per l'autenticazione tramite impronta digitale. I dispositivi forniti con Android 9 e versioni successive possono utilizzare BiometricPrompt come singolo punto di integrazione per impronte digitali e dati biometrici aggiuntivi. Questi componenti comunicano il proprio stato di autenticazione con il servizio archivio chiavi tramite un canale autenticato. (Il sistema Android Keystore a livello di framework è supportato anche dal servizio keystore.)

I componenti Gatekeeper, Fingerprint e Biometric funzionano con Keystore e altri componenti per supportare l'uso di token di autenticazione supportati da hardware (AuthToken).

Iscrizione

Al primo avvio del dispositivo dopo il ripristino delle impostazioni di fabbrica, tutti gli autenticatori sono pronti a ricevere le registrazioni delle credenziali dall'utente. Un utente deve inizialmente registrare un PIN/una sequenza/una password con Gatekeeper. Questa registrazione iniziale crea un identificatore sicuro utente (SID) a 64 bit generato in modo casuale che funge da identificatore per l'utente e da token di associazione per il materiale crittografico dell'utente. Questo SID utente è crittograficamente associato alla password dell'utente; le autenticazioni riuscite a Gatekeeper danno come risultato AuthToken che contengono il SID utente per quella password.

Un utente che desidera modificare una credenziale deve presentare una credenziale esistente. Se una credenziale esistente viene verificata correttamente, il SID utente associato alla credenziale esistente viene trasferito alla nuova credenziale, consentendo all'utente di continuare ad accedere alle chiavi dopo aver modificato una credenziale. Se un utente non presenta una credenziale esistente, la nuova credenziale viene registrata con un SID utente completamente casuale. L'utente può accedere al dispositivo, ma le chiavi create con il SID utente precedente verranno perse in modo permanente. Questa operazione è nota come registrazione non attendibile .

In circostanze normali, il framework Android non consente una registrazione non attendibile, quindi la maggior parte degli utenti non vedrà mai questa funzionalità. Tuttavia, la reimpostazione forzata della password, effettuata da un amministratore del dispositivo o da un utente malintenzionato, potrebbe causare questo problema.

Autenticazione

Dopo che un utente ha configurato una credenziale e ricevuto un SID utente, può avviare l'autenticazione, che inizia quando un utente fornisce un PIN, una sequenza, una password o un'impronta digitale. Tutti i componenti TEE condividono una chiave segreta che utilizzano per autenticare i reciproci messaggi.

1. Un utente fornisce un metodo di autenticazione e il servizio associato effettua una richiesta al daemon associato.
   • Per PIN, sequenza o password, LockSettingsService effettua una richiesta a gatekeeperd .
   • I flussi di autenticazione basati sulla biometria dipendono dalla versione di Android. Sui dispositivi con Android 8.x e versioni precedenti, FingerprintService effettua una richiesta a fingerprintd ). Sui dispositivi con Android 9 e versioni successive, BiometricPrompt effettua una richiesta al daemon biometrico appropriato (ad esempio, fingerprintd per impronte digitali o faced per volto) utilizzando la classe Biometric Manager appropriata, come FingerprintManager o FaceManager . Indipendentemente dalla versione, l'autenticazione biometrica avviene in modo asincrono dopo l'invio della richiesta.
2. Il demone invia i dati alla sua controparte, che genera un AuthToken:
   • Per l'autenticazione tramite PIN/sequenza/password, gatekeeperd invia il PIN, la sequenza o l'hash della password a Gatekeeper nel TEE. Se l'autenticazione nel TEE ha esito positivo, Gatekeeper nel TEE invia un AuthToken contenente il SID utente corrispondente (firmato con la chiave AuthToken HMAC) alla sua controparte nel sistema operativo Android.
   • Per l'autenticazione tramite impronta digitale, fingerprintd ascolta gli eventi relativi all'impronta digitale e invia i dati a Fingerprint nel TEE. Se l'autenticazione nel TEE ha esito positivo, Fingerprint nel TEE invia un AuthToken (firmato con la chiave AuthToken HMAC) alla sua controparte nel sistema operativo Android.
   • Per altre autenticazioni biometriche, il demone biometrico appropriato ascolta l'evento biometrico e lo invia al componente TEE biometrico appropriato.
3. Il daemon riceve un AuthToken firmato e lo passa al servizio archivio chiavi tramite un'estensione dell'interfaccia Binder del servizio archivio chiavi. ( gatekeeperd notifica inoltre al servizio di archivio chiavi quando il dispositivo viene nuovamente bloccato e quando la password del dispositivo cambia.)
4. Il servizio di archivio chiavi passa gli AuthToken a Keymaster e li verifica utilizzando la chiave condivisa con il Gatekeeper e il componente TEE biometrico supportato. Keymaster considera attendibile il timestamp nel token come ultimo orario di autenticazione e basa la decisione sul rilascio della chiave (per consentire a un'app di utilizzare la chiave) sul timestamp.

Formato token di autenticazione

Per garantire la condivisione e la compatibilità dei token tra linguaggi e componenti, il formato AuthToken è descritto in hw_auth_token.h . Il formato è un semplice protocollo di serializzazione con campi di dimensione fissa.

Flusso di avvio del dispositivo

Ad ogni avvio di un dispositivo, la chiave AuthToken HMAC deve essere generata e condivisa con tutti i componenti TEE (Gatekeeper, Keymaster e trustlet biometrici supportati). Pertanto, per una maggiore protezione contro gli attacchi di riproduzione, la chiave HMAC deve essere generata in modo casuale ogni volta che il dispositivo si riavvia.

Il protocollo per condividere questa chiave HMAC con tutti i componenti è una funzionalità di implementazione dipendente dalla piattaforma. La chiave non deve mai essere resa disponibile all'esterno del TEE. Se un sistema operativo TEE non dispone di un meccanismo di comunicazione interprocesso interna (IPC) e deve trasferire i dati tramite il sistema operativo non attendibile, il trasferimento deve essere effettuato tramite un protocollo di scambio di chiavi sicuro.

Il sistema operativo Trusty , che funziona accanto ad Android, è un esempio di TEE, ma al suo posto possono essere utilizzati altri TEE. Trusty utilizza un sistema IPC interno per comunicare direttamente tra Keymaster e Gatekeeper o il trustlet biometrico appropriato. La chiave HMAC è conservata esclusivamente in Keymaster; Fingerprint e Gatekeeper richiedono la chiave da Keymaster per ogni utilizzo e non mantengono né memorizzano nella cache il valore.

Poiché alcuni TEE non dispongono di un'infrastruttura IPC, non avviene alcuna comunicazione tra gli applet nel TEE. Ciò consente inoltre al servizio di archivio chiavi di negare rapidamente le richieste destinate a fallire poiché è a conoscenza della tabella di autenticazione nel sistema, risparmiando un IPC potenzialmente costoso nel TEE.