Google si impegna a promuovere l'equità razziale per le comunità nere. Vedi come.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Autenticazione

Android utilizza il concetto di chiavi crittografiche con autenticazione utente che richiede i seguenti componenti:

  • Memoria chiave crittografica e provider di servizi. Memorizza le chiavi crittografiche e fornisce routine crittografiche standard in cima a tali chiavi. Android supporta un Keystore e Keymaster con supporto hardware per servizi di crittografia, inclusa la crittografia con supporto hardware per l'archiviazione delle chiavi che potrebbe includere un Trusted Execution Environment (TEE) o Secure Element (SE), come Strongbox.
  • Autenticatori utente. Attestare la presenza dell'utente e / o l'autenticazione riuscita. Android supporta Gatekeeper per l'autenticazione tramite PIN / sequenza / password e Impronta digitale 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 biometria aggiuntiva. Questi componenti comunicano il loro stato di autenticazione con il servizio keystore attraverso un canale autenticato. (Anche il sistema Android Keystore a livello di framework è supportato dal servizio keystore.)

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

Iscrizione

Al primo avvio del dispositivo dopo un 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 / sequenza / password con Gatekeeper. Questa registrazione iniziale crea un identificatore sicuro utente (SID) a 64 bit generato casualmente che funge da identificatore per l'utente e come token vincolante per il materiale crittografico dell'utente. Questo SID utente è crittografato in modo crittografico con la password dell'utente; le autenticazioni riuscite su Gatekeeper generano AuthTokens che contengono il SID dell'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 dell'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 vecchio SID dell'utente vengono perse in modo permanente. Questo è noto come iscrizione non attendibile .

In circostanze normali, il framework Android non consente un'iscrizione non attendibile, quindi la maggior parte degli utenti non vedrà mai questa funzionalità. Tuttavia, i ripristini forzati della password, da parte di un amministratore del dispositivo o di un utente malintenzionato, possono causare ciò.

Autenticazione

Dopo che un utente ha impostato una credenziale e ha 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 autenticarsi reciprocamente i messaggi.

Flusso di autenticazione
Figura 1. Flusso di autenticazione
  1. Un utente fornisce un metodo di autenticazione e il servizio associato invia una richiesta al demone associato.
    • Per PIN, sequenza o password, LockSettingsService una richiesta a gatekeeperd .
    • I flussi di autenticazione basati sulla biometria dipendono dalla versione di Android. Sui dispositivi che eseguono Android 8.xe versioni precedenti, FingerprintService invia una richiesta di fingerprintd ). Sui dispositivi con Android 9 e versioni successive, BiometricPrompt invia una richiesta al demone biometrico appropriato (ad esempio, fingerprintd per impronte digitali o faced per viso) 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 PIN / sequenza / password, gatekeeperd invia l'hash PIN, sequenza o password a Gatekeeper in TEE. Se l'autenticazione nel TEE ha esito positivo, Gatekeeper nel TEE invia un AuthToken contenente il SID utente corrispondente (firmato con la chiave HMAC AuthToken) alla sua controparte nel sistema operativo Android.
    • Per l'autenticazione delle impronte fingerprintd , fingerprintd ascolta gli eventi relativi alle impronte digitali e invia i dati a Fingerprint nel TEE. Se l'autenticazione nel TEE ha esito positivo, l'impronta digitale 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 di archivio chiavi tramite un'estensione dell'interfaccia Binder del servizio di archivio chiavi. ( gatekeeperd avvisa anche il servizio di archivio chiavi quando il dispositivo viene ricollegato e quando la password del dispositivo cambia.)
  4. Il servizio keystore passa gli AuthTokens a Keymaster e li verifica utilizzando la chiave condivisa con Gatekeeper e il componente biometrico TEE supportato. Keymaster considera attendibile il timestamp nel token come ultimo tempo di autenticazione e basa una decisione di rilascio della chiave (per consentire a un'app di utilizzare la chiave) sul timestamp.

Formato AuthToken

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

Campo genere necessario Descrizione
Versione autenticata 1 byte Tag di gruppo per tutti i campi sottostanti.
Sfida Numero intero senza segno a 64 bit No Un numero intero casuale per impedire gli attacchi di riproduzione. Di solito l'ID di un'operazione di crittografia richiesta. Attualmente utilizzato dalle autorizzazioni transazionali per le impronte digitali. Se presente, AuthToken è valido solo per operazioni di crittografia contenenti la stessa sfida.
SID utente Numero intero senza segno a 64 bit Identificatore utente non ripetuto legato crittograficamente a tutte le chiavi associate all'autenticazione del dispositivo. Per i dettagli, consultare Gatekeeper .
ID autenticatore (ASID) Numero intero senza segno a 64 bit nell'ordine di rete No Identificatore utilizzato per associare una specifica politica di autenticazione. Tutti gli autenticatori hanno il proprio valore di ASID che possono cambiare in base alle proprie esigenze.
Tipo di autenticatore Numero intero senza segno a 32 bit nell'ordine di rete
  • 0x00 è Gatekeeper.
  • 0x01 è l'impronta digitale.
timestamp Numero intero senza segno a 64 bit nell'ordine di rete Tempo (in millisecondi) dall'avvio del sistema più recente.
AuthToken HMAC (SHA-256) BLOB a 256 bit MAC SHA-256 con chiave di tutti i campi tranne il campo HMAC.

Flusso di avvio del dispositivo

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

Il protocollo per la condivisione di questa chiave HMAC con tutti i componenti è una funzionalità di implementazione dipendente dalla piattaforma. La chiave non deve mai essere resa disponibile al di fuori del TEE. Se un sistema operativo TEE è privo di un meccanismo di comunicazione tra processi interni (IPC) e deve trasferire i dati attraverso un 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 è possibile utilizzare 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 persistono o memorizzano nella cache il valore.

Poiché alcuni TEE non dispongono di un'infrastruttura IPC, non si verifica alcuna comunicazione tra applet nel TEE. Ciò consente inoltre al servizio keystore di negare rapidamente richieste che sono destinate a fallire in quanto è a conoscenza della tabella di autenticazione nel sistema, risparmiando un IPC potenzialmente costoso nel TEE.