Android utilizza il concetto di chiavi crittografiche dipendenti dall'autenticazione dell'utente che richiede i seguenti componenti:
- Archiviazione di chiavi crittografiche e fornitore di servizi. Memorizza le chiavi crittografiche e fornisce routine crittografiche standard su tali chiavi. Android supporta Keystore e Keymaster con supporto hardware per i 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'avvenuta autenticazione. Android supporta Gatekeeper per l'autenticazione tramite PIN/modello/password e Fingerprint per l'autenticazione tramite impronta digitale. I dispositivi forniti con Android 9 e versioni successive possono utilizzare
BiometricPromptcome un unico punto di integrazione per impronte digitali e dati biometrici aggiuntivi. Questi componenti comunicano il loro stato di autenticazione con il servizio keystore 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 (AuthTokens).
Iscrizione
Al primo avvio del dispositivo dopo un ripristino delle impostazioni di fabbrica, tutti gli autenticatori sono preparati a ricevere le registrazioni delle credenziali dall'utente. Un utente deve inizialmente registrare un PIN/modello/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 di associazione per il materiale crittografico dell'utente. Questo SID utente è vincolato crittograficamente alla password dell'utente; le autenticazioni riuscite a Gatekeeper generano 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 vecchio SID utente vengono perse definitivamente. Questo è noto come un'iscrizione 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, da parte di un amministratore del dispositivo o di un utente malintenzionato, può causare ciò.
Autenticazione
Dopo che un utente ha impostato 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 messaggi degli altri.
- Un utente fornisce un metodo di autenticazione e il servizio associato effettua una richiesta al demone associato.
- Per PIN, sequenza o password,
LockSettingsServiceeffettua una richiesta agatekeeperd. - I flussi di autenticazione basati sulla biometria dipendono dalla versione di Android. Sui dispositivi con Android 8.x e versioni precedenti,
FingerprintServiceeffettua una richiesta afingerprintd). Sui dispositivi con Android 9 e versioni successive,BiometricPrompteffettua una richiesta al daemon biometrico appropriato (ad esempio,fingerprintdper le impronte digitali ofacedper il viso) utilizzando la classeBiometric Managerappropriata, comeFingerprintManageroFaceManager. Indipendentemente dalla versione, l'autenticazione biometrica avviene in modo asincrono dopo l'invio della richiesta.
- Per PIN, sequenza o password,
- Il demone invia i dati alla sua controparte, che genera un AuthToken:
- Per l'autenticazione tramite PIN/modello/password,
gatekeeperdinvia il PIN, il modello 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 HMAC AuthToken) alla sua controparte nel sistema operativo Android. - Per l'autenticazione dell'impronta digitale,
fingerprintdascolta gli eventi dell'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 HMAC AuthToken) alla sua controparte nel sistema operativo Android. - Per altre autenticazioni biometriche, il daemon biometrico appropriato ascolta l'evento biometrico e lo invia al componente TEE biometrico appropriato.
- Per l'autenticazione tramite PIN/modello/password,
- Il demone riceve un AuthToken firmato e lo passa al servizio keystore tramite un'estensione dell'interfaccia Binder del servizio keystore. (
gatekeeperdnotifica anche al servizio keystore quando il dispositivo viene ribloccato e quando la password del dispositivo cambia.) - Il servizio keystore passa gli AuthToken a Keymaster e li verifica utilizzando la chiave condivisa con Gatekeeper e il componente TEE biometrico supportato. Keymaster considera attendibile il timestamp nel token come ultima ora 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 dei token e la compatibilità tra linguaggi e componenti, il formato AuthToken è descritto in hw_auth_token.h . Il formato è un semplice protocollo di serializzazione con campi di dimensioni fisse.
| Campo | Tipo | Necessario | Descrizione |
|---|---|---|---|
| Versione AuthToken | 1 byte | sì | Tag di gruppo per tutti i campi sottostanti. |
| Sfida | Intero senza segno a 64 bit | No | Un numero intero casuale per prevenire attacchi di ripetizione. Di solito l'ID di un'operazione crittografica richiesta. Attualmente utilizzato dalle autorizzazioni delle impronte digitali transazionali. Se presente, l'AuthToken è valido solo per operazioni crittografiche contenenti la stessa sfida. |
| SID utente | Intero senza segno a 64 bit | sì | Identificatore utente non ripetuto legato crittograficamente a tutte le chiavi associate all'autenticazione del dispositivo. Per i dettagli, vedere Gatekeeper . |
| ID autenticatore (ASID) | Intero senza segno a 64 bit in ordine di rete | No | Identificatore utilizzato per eseguire l'associazione a una politica di autenticazione specifica. Tutti gli autenticatori hanno il proprio valore di ASID che possono modificare in base alle proprie esigenze. |
| Tipo di autenticatore | Intero senza segno a 32 bit nell'ordine di rete | sì |
|
| Timestamp | Intero senza segno a 64 bit in ordine di rete | sì | Tempo (in millisecondi) dall'ultimo avvio del sistema. |
| AuthToken HMAC (SHA-256) | Blob a 256 bit | sì | 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 AuthToken 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 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 non dispone di un meccanismo di comunicazione interprocesso interno (IPC) e deve trasferire i dati tramite il sistema operativo non attendibile, il trasferimento deve essere eseguito tramite un protocollo di scambio di chiavi sicuro.
Il sistema operativo Trusty , che gira accanto ad Android, è un esempio di TEE, ma possono essere usati 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 a Keymaster per ogni utilizzo e non mantengono o memorizzano il valore nella cache.
Poiché alcuni TEE non dispongono di un'infrastruttura IPC, non si verifica alcuna comunicazione tra le applet nel TEE. Ciò consente inoltre al servizio keystore di rifiutare rapidamente le richieste destinate a fallire poiché è a conoscenza della tabella di autenticazione nel sistema, risparmiando un IPC potenzialmente costoso nel TEE.