Authentication

Android ha il concetto di autenticatori utente che vengono utilizzati per sbloccare il dispositivo e per controllare l'accesso alle chiavi di crittografia. Ciò comporta i seguenti componenti:

  • Archiviazione delle chiavi di crittografia e fornitore di servizi. Android Keystore fornisce servizi di crittografia basati su hardware per le app. Il sistema Android Keystore a livello di framework è supportato dal servizio di sistema keystore2. Questo si basa a sua volta su un'implementazione KeyMint (in precedenza Keymaster) specifica del fornitore che garantisce che il materiale delle chiavi sia accessibile solo in un ambiente sicuro con crittografia hardware, come un Trusted Execution Environment (TEE) o un Secure Element (SE), ad esempio StrongBox.
  • Autenticatori utente. Attestare l'avvenuta autenticazione dell'utente. Android supporta i seguenti componenti di autenticazione:
    • Gatekeeper per l'autenticazione con PIN, sequenza o password nel TEE.
    • (Facoltativo) Weaver per l'autenticazione con PIN, sequenza o password in un Secure Element.
    • Impronta per l'autenticazione tramite impronta.
    • Altri metodi di autenticazione biometrica. I dispositivi con Android 9 o versioni successive possono utilizzare BiometricPrompt come unico punto di integrazione per l'impronta e altri dati biometrici.
    Questi componenti comunicano il loro stato di autenticazione al servizio keystore2 tramite l'utilizzo di token di autenticazione (AuthToken) con crittografia hardware.

Ognuno di questi componenti è specifico del fornitore, ma l'implementazione del fornitore deve soddisfare una specifica dell'interfaccia Hardware Abstraction Layer (HAL) e superare i test della suite di test del fornitore (VTS) corrispondenti.

In genere, anche le implementazioni dei fornitori sono suddivise in due parti, collegate da un meccanismo di comunicazione specifico del fornitore :

  • Un servizio HAL viene eseguito come processo di sistema Android, ricevendo richieste Binder dal sistema Android.
  • Un'applicazione attendibile (TA) viene eseguita nell'ambiente sicuro, eseguendo le operazioni di sicurezza effettive.

Registrazione

Al primo avvio del dispositivo dopo un ripristino dei dati di fabbrica, tutti gli autenticatori sono preparati a ricevere le registrazioni delle credenziali dall'utente. Un utente deve inizialmente registrare un PIN, una sequenza o una password con Gatekeeper (o Weaver, se disponibile). Questa registrazione iniziale crea un identificatore sicuro dell'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 è associato in modo crittografico alla password dell'utente. Le autenticazioni riuscite a Gatekeeper generano AuthToken che contengono il SID utente per quella password.

Un utente che vuole modificare una credenziale esistente deve presentarla. 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.

In alcune situazioni, un amministratore del dispositivo può eseguire una registrazione non attendibile per registrare una nuova credenziale senza presentare una credenziale esistente. In questo modo l'utente può accedere al dispositivo, ma le chiavi create con il vecchio SID utente vengono perse definitivamente.

Autenticazione

Questa sezione descrive un tipico flusso di autenticazione, che prevede interazioni tra più componenti sia in Android che nell'ambiente sicuro. Tieni presente che tutti i componenti sicuri condividono una chiave HMAC segreta (per avvio) che utilizzano per autenticare i messaggi degli altri.

Dopo che un utente ha configurato una credenziale e gli è stato assegnato un SID utente, può avviare l'autenticazione, che inizia quando l'utente fornisce un PIN, una sequenza, una password, un'impronta o un altro dato biometrico avanzato. Flusso di autenticazione

Figura 1. Flusso di autenticazione

  1. Un utente fornisce un metodo di autenticazione e il servizio associato invia una richiesta al servizio HAL.
    • Per il PIN, la sequenza o la password, LockSettingsService invia 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 le impronte o faced per il volto) utilizzando la classe BiometricManager appropriata, come FingerprintManager o FaceManager. Indipendentemente dalla versione, l'autenticazione biometrica avviene in modo asincrono dopo l'invio della richiesta.
  2. Il servizio HAL invia i dati alla TA corrispondente, che genera un AuthToken:
    • Per l'autenticazione tramite PIN/sequenza/password, gatekeeperd invia l'hash del PIN, della sequenza o della password al Gatekeeper TA nel TEE, tramite il servizio Gatekeeper HAL. Se l'autenticazione nel TEE ha esito positivo, il Gatekeeper TA emette un AuthToken contenente il SID utente corrispondente (firmato con la chiave HMAC condivisa).
    • Per l'autenticazione tramite impronta, fingerprintd rimane in ascolto degli eventi relativi alle impronte e invia i dati alla TA dell'impronta nel TEE tramite l'HAL dell'impronta. Se l'autenticazione nel TEE va a buon fine, l'app attendibile per l'impronta emette un AuthToken (firmato con la chiave HMAC AuthToken).
    • Per un'altra autenticazione biometrica, il daemon biometrico appropriato ascolta l'evento biometrico e lo invia al servizio HAL biometrico e al TA appropriati.
  3. L'AuthToken firmato risultante viene passato al servizio di sistema keystore2 tramite un'interfaccia Binder.
  4. Il servizio keystore2 allega gli AuthToken alla richiesta per KeyMint (in precedenza Keymaster) per eseguire operazioni crittografiche. Il servizio HAL KeyMint li trasmette al TA KeyMint, che li verifica utilizzando la chiave HMAC condivisa con Gatekeeper e i componenti TEE biometrici supportati. KeyMint considera il timestamp nel token come l'ora dell'ultima autenticazione e decide se consentire l'utilizzo della chiave in base al timestamp.

Il flusso di autenticazione non richiede la comunicazione diretta tra le TA nell'ambiente sicuro: gli AuthToken passano dalla TA dell'autenticatore al servizio keystore2 in Android, che a sua volta li trasmette alla TA KeyMint. In questo modo, il servizio keystore2 può anche rifiutare rapidamente le richieste che non andranno a buon fine, poiché conosce gli AuthToken disponibili nel sistema, risparmiando un IPC potenzialmente costoso nel TEE.

Formato AuthToken

Il formato di AuthToken è fornito dalla specifica AIDL in HardwareAuthToken.aidl.

Flusso di avvio del dispositivo

A ogni avvio di un dispositivo, la chiave HMAC AuthToken deve essere generata e condivisa con tutti i componenti TEE (Gatekeeper, KeyMint e TA biometriche supportate). Per evitare attacchi di tipo replay, la chiave HMAC deve essere generata in modo casuale ogni volta che il dispositivo viene riavviato.

Esistono due modi comuni in cui i TA acquisiscono l'accesso a questa chiave HMAC condivisa:

  • Accordo sul secret condiviso: il servizio keystore2 esegue un protocollo di accordo sulla chiave a più vie all'avvio del dispositivo, consentendo la derivazione sicura della chiave HMAC tra le TA partecipanti. Tuttavia, le TA partecipanti devono avere accesso a un secret precondiviso comune.
  • Accesso diretto: le TA che risiedono nello stesso ambiente sicuro possono utilizzare un meccanismo di comunicazione tra processi interno (che dipende dalla piattaforma) per condividere la chiave HMAC.

In entrambi i casi, la chiave HMAC non deve mai essere resa disponibile all'esterno del TEE.

Il sistema operativo Trusty, che viene eseguito insieme ad Android, è un esempio di TEE, ma è possibile utilizzare altri TEE. Trusty utilizza un sistema IPC interno per comunicare direttamente tra KeyMint e Gatekeeper o la TA biometrica appropriata. La chiave HMAC viene conservata esclusivamente in KeyMint; Fingerprint e Gatekeeper richiedono la chiave a KeyMint per ogni utilizzo e non mantengono o memorizzano nella cache il valore.

Poiché alcuni TEE non dispongono di un'infrastruttura IPC, non avviene alcuna comunicazione tra le applet nel TEE. In questo modo, il servizio Keystore può anche rifiutare rapidamente le richieste destinate a non andare a buon fine, poiché conosce la tabella di autenticazione nel sistema, risparmiando un IPC potenzialmente costoso nel TEE.