Authentication

Android ha il concetto di autenticatori utente che vengono utilizzati per sbloccare il dispositivo e per limitare l'accesso alle chiavi di crittografia. Sono coinvolti i seguenti componenti:

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

In genere, 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 sicure effettive.

Registrazione

Al primo avvio del dispositivo dopo un ripristino dei dati di fabbrica, tutti gli autenticatori sono pronti a ricevere le registrazioni delle credenziali dell'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 utente (SID) a 64 bit generato in modo casuale che funge da identificatore per l'utente e da token di binding per il materiale di crittografia dell'utente. Questo SID utente è associato crittograficamente 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 presentarne una 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 flusso di autenticazione tipico, che prevede interazioni tra più componenti sia in Android sia nell'ambiente sicuro. Tieni presente che tutti i componenti sicuri condividono una chiave HMAC segreta (per avvio) che utilizzano per autenticare i messaggi reciproci.

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

Figura 1. Flusso di autenticazione

  1. Un utente fornisce un metodo di autenticazione e il servizio associato effettua una richiesta al servizio HAL.
    • 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 le impronte digitali o faced per il volto) utilizzando la classe BiometricManager appropriata, ad esempio 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 con PIN/sequenza/password, gatekeeperd invia l'hash del PIN, della sequenza o della password alla TA Gatekeeper nel TEE, tramite il servizio HAL Gatekeeper. Se l'autenticazione nel TEE ha esito positivo, la TA Gatekeeper emette un AuthToken contenente il SID utente corrispondente (firmato con la chiave HMAC condivisa).
    • Per l'autenticazione con impronta digitale, fingerprintd ascolta gli eventi dell'impronta digitale e invia i dati alla TA Impronta digitale nel TEE, tramite l'HAL Impronta digitale. Se l'autenticazione nel TEE ha esito positivo, la TA Impronta digitale emette un AuthToken (firmato con la chiave HMAC AuthToken).
    • Per altre autenticazioni biometriche, il daemon biometrico appropriato ascolta l'evento biometrico e lo invia al servizio HAL biometrico e alla TA appropriati.
  3. Il daemon riceve un AuthToken firmato e lo passa al servizio Keystore tramite un'estensione dell'interfaccia Binder del servizio Keystore. (gatekeeperd invia una notifica al servizio Keystore anche quando il dispositivo viene bloccato di nuovo e quando la password del dispositivo cambia.)
  4. Il servizio Keystore passa gli AuthToken a KeyMint e li verifica utilizzando la chiave condivisa con il componente TEE biometrico supportato e Gatekeeper. KeyMint considera il timestamp nel token come l'ultimo orario di autenticazione e basa una decisione di rilascio della chiave (per consentire a un'app di utilizzare la chiave) sul 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 passa alla TA KeyMint. Ciò consente inoltre al servizio keystore2 di negare rapidamente le richieste che non andranno a buon fine, in quanto conosce gli AuthToken disponibili nel sistema, risparmiando un IPC potenzialmente costoso nel TEE.

Formato AuthToken

Il formato dell'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 trustlet biometrici supportati). Pertanto, per una maggiore protezione dagli attacchi di riproduzione, la chiave HMAC deve essere generata in modo casuale ogni volta che il dispositivo viene riavviato.

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

  • Accordo segreto condiviso: il servizio keystore2 esegue un protocollo di accordo chiave multi-way 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 interprocesso interno (dipendente dalla piattaforma) per condividere la chiave HMAC.

In entrambi i casi, la chiave HMAC non deve mai essere resa disponibile al di fuori del TEE.

Il sistema operativo Trusty, che viene eseguito accanto ad Android, è un esempio di TEE, ma è possibile utilizzare altri TEE invece. Trusty utilizza un sistema IPC interno per comunicare direttamente tra KeyMint e Gatekeeper o il trustlet biometrico appropriato. La chiave HMAC viene conservata esclusivamente in KeyMint; Impronta digitale e Gatekeeper richiedono la chiave a KeyMint per ogni utilizzo e non persistono o memorizzano nella cache il valore.

Poiché alcuni TEE non dispongono di un'infrastruttura IPC, non si verifica alcuna comunicazione tra gli applet nel TEE. Ciò consente inoltre al servizio Keystore di negare rapidamente le richieste che non andranno a buon fine, in quanto conosce la tabella di autenticazione nel sistema, risparmiando un IPC potenzialmente costoso nel TEE.