Authentication

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

  • Provider di servizi e archiviazione di chiavi di crittografia. 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 di KeyMint (in precedenza Keymaster) specifica del fornitore che garantisce che il materiale della chiave sia accessibile solo in un ambiente sicuro basato su hardware, come un Trusted Execution Environment (TEE) o un Secure Element (SE).
  • Autenticatori utente. Attesta l'autenticazione riuscita dell'utente. Android supporta i seguenti componenti di autenticazione:
    • Gatekeeper per l'autenticazione tramite PIN, sequenza o password nel TEE.
    • (Facoltativo) Weaver per l'autenticazione tramite PIN, sequenza o password in un elemento sicuro.
    • Impronta per l'autenticazione tramite impronta.
    • Altri metodi di autenticazione biometrica. I dispositivi forniti con Android 9 o versioni successive possono utilizzare BiometricPrompt come un unico punto di integrazione per l'impronta e altri dati biometrici.
    Questi componenti comunicano il proprio stato di autenticazione con il servizio keystore2 tramite l'utilizzo di token di autenticazione (AuthToken) basati su 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) corrispondente.

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

  • Un servizio HAL viene eseguito come processo di sistema Android e riceve 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 da parte 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 dell'utente (SID) di 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 è legato in modo criptato alla password dell'utente. Le autenticazioni riuscite a Gatekeeper generano token Auth che contengono l'SID utente per quella password.

Un utente che vuole modificare una credenziale esistente deve presentarla. Se una credenziale esistente viene verificata correttamente, l'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 alcuni casi, 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 andranno perse definitivamente.

Autenticazione

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

Dopo aver configurato una credenziale e aver ricevuto un SID utente, l'utente può iniziare l'autenticazione, che viene avviata quando 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 PIN, sequenza o 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 invia una richiesta a fingerprintd. Sui dispositivi con Android 9 e versioni successive, BiometricPrompt invia 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 controparte TA, che genera un AuthToken:
    • Per l'autenticazione tramite PIN/sequenza/password, gatekeeperd invia l'hash del PIN, della sequenza o della password all'agente di autenticazione Gatekeeper nel TEE tramite il servizio HAL Gatekeeper. Se l'autenticazione nel TEE ha esito positivo, il TA Gatekeeper emette un token Auth contenente l'SID utente corrispondente (firmato con la chiave HMAC condivisa).
    • Per l'autenticazione tramite impronta, fingerprintd ascolta gli eventi di impronta e invia i dati all'ATT Fingerprint nel TEE tramite l'HAL Fingerprint. Se l'autenticazione nel TEE ha esito positivo, la TA Fingerprint emette un AuthToken (firmato con la chiave HMAC AuthToken).
    • Per altri tipi di autenticazione biometrica, il daemon biometrico appropriato monitora l'evento biometrico e lo invia al servizio HAL e al TA biometrici appropriati.
  3. L'AuthToken firmato risultante viene passato al servizio di sistema keystore2 tramite un'interfaccia Binder.
  4. Il servizio keystore2 allega gli AuthToken per richiedere a KeyMint (in precedenza Keymaster) di eseguire operazioni crittografiche. Il servizio HAL KeyMint le passa all'agente di autenticazione KeyMint, che le verifica utilizzando la chiave HMAC condivisa con Gatekeeper e i componenti TEE biometrici supportati. KeyMint considera attendibile il timestamp nel token come data e 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 gli AT nell'ambiente sicuro: gli AuthToken passano dall'AT di autenticazione al servizio keystore2 in Android, che a sua volta li passa all'AT KeyMint. In questo modo, il servizio keystore2 può anche rifiutare rapidamente le richieste destinate a non andare a buon fine, poiché conosce gli AuthToken disponibili nel sistema, evitando un IPC potenzialmente costoso nel TEE.

Formato AuthToken

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

Procedura 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/Keymaster e TA di autenticazione biometrica supportati). Per evitare attacchi di replay, la chiave HMAC deve essere generata in modo casuale ogni volta che il dispositivo si riavvia.

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

  • Contratto con segreto condiviso:il servizio keystore2 esegue un protocollo di accordo sulle chiavi multidirezionale all'avvio del dispositivo, consentendo la derivazione sicura della chiave HMAC tra i TA partecipanti. Tuttavia, i TA partecipanti devono avere accesso a un segreto precompartito comune.
  • Accesso diretto:gli agenti di transizione che si trovano nello stesso ambiente sicuro possono utilizzare un meccanismo di comunicazione interprocessuale interno (che dipende 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. Trusty utilizza un sistema IPC interno per comunicare direttamente tra KeyMint e Gatekeeper o il TA biometrico appropriato. La chiave HMAC viene conservata esclusivamente in KeyMint. Fingerprint e Gatekeeper richiedono la chiave a KeyMint per ogni utilizzo e non la memorizzano nella cache o la mantengono.