Android utilizza il concetto di chiavi crittografiche controllate dall'autenticazione dell'utente che richiede i seguenti componenti:
- Fornitore di servizi e archiviazione di chiavi crittografiche. Memorizza le chiavi crittografiche e fornisce routine crittografiche standard su tali chiavi. Android supporta un Keystore e un Keymaster supportati da hardware per i servizi di crittografia, inclusa la crittografia supportata da hardware per l'archiviazione delle chiavi che potrebbe includere un Trusted Execution Environment (TEE) o Secure Element (SE), come Strongbox.
- Autenticatori dell'utente. Attestare la presenza dell'utente e/o l'avvenuta autenticazione. Android supporta Gatekeeper per l'autenticazione PIN/sequenza/password e Fingerprint per l'autenticazione tramite impronta digitale. I dispositivi forniti con Android 9 e versioni successive possono utilizzare
BiometricPromptcome singolo punto di integrazione per impronte digitali e dati biometrici aggiuntivi. Questi componenti comunicano il proprio stato di autenticazione con il servizio archivio chiavi 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 (AuthToken).
Iscrizione
Al primo avvio del dispositivo dopo il 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/una sequenza/una password con Gatekeeper. 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 associazione per il materiale crittografico dell'utente. Questo SID utente è crittograficamente associato alla password dell'utente; le autenticazioni riuscite a Gatekeeper danno come risultato 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 SID utente precedente verranno perse in modo permanente. Questa operazione è nota come registrazione 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, effettuata da un amministratore del dispositivo o da un utente malintenzionato, potrebbe causare questo problema.
Autenticazione
Dopo che un utente ha configurato 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 reciproci messaggi.
- Un utente fornisce un metodo di autenticazione e il servizio associato effettua una richiesta al daemon 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 impronte digitali ofacedper volto) 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/sequenza/password,
gatekeeperdinvia il PIN, la sequenza 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 AuthToken HMAC) alla sua controparte nel sistema operativo Android. - Per l'autenticazione tramite impronta digitale,
fingerprintdascolta gli eventi relativi all'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 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.
- Per l'autenticazione tramite PIN/sequenza/password,
- Il daemon riceve un AuthToken firmato e lo passa al servizio archivio chiavi tramite un'estensione dell'interfaccia Binder del servizio archivio chiavi. (
gatekeeperdnotifica inoltre al servizio di archivio chiavi quando il dispositivo viene nuovamente bloccato e quando la password del dispositivo cambia.) - Il servizio di archivio chiavi passa gli AuthToken a Keymaster e li verifica utilizzando la chiave condivisa con il Gatekeeper e il componente TEE biometrico supportato. Keymaster considera attendibile il timestamp nel token come ultimo orario di autenticazione e basa la decisione sul rilascio della chiave (per consentire a un'app di utilizzare la chiave) sul timestamp.
Formato token di autenticazione
Per garantire la condivisione e la compatibilità dei token tra linguaggi e componenti, il formato AuthToken è descritto in hw_auth_token.h . Il formato è un semplice protocollo di serializzazione con campi di dimensione fissa.
| Campo | Tipo | Necessario | Descrizione |
|---|---|---|---|
| Versione del token di autenticazione | 1 byte | SÌ | Tag di gruppo per tutti i campi sottostanti. |
| Sfida | Intero senza segno a 64 bit | NO | Un numero intero casuale per impedire attacchi di riproduzione. Di solito l'ID di un'operazione di crittografia richiesta. Attualmente utilizzato dalle autorizzazioni delle impronte digitali transazionali. Se presente, l'AuthToken è valido solo per operazioni crypto contenenti la stessa challenge. |
| ID utente | Intero senza segno a 64 bit | SÌ | Identificatore utente non ripetitivo legato crittograficamente a tutte le chiavi associate all'autenticazione del dispositivo. Per i dettagli, vedere Gatekeeper . |
| ID dell'autenticatore (ASID) | Intero senza segno a 64 bit nell'ordine di rete | NO | Identificatore utilizzato per associarsi a una policy di autenticazione specifica. Tutti gli autenticatori hanno il proprio valore 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 nell'ordine di rete | SÌ | Tempo (in millisecondi) dall'avvio del sistema più recente. |
| Token di autenticazione 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 AuthToken HMAC 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 condividere questa chiave HMAC con tutti i componenti è una funzionalità di implementazione dipendente dalla piattaforma. La chiave non deve mai essere resa disponibile all'esterno del TEE. Se un sistema operativo TEE non dispone di un meccanismo di comunicazione interprocesso interna (IPC) e deve trasferire i dati tramite il 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 al suo posto possono essere utilizzati 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 mantengono né memorizzano nella cache il valore.
Poiché alcuni TEE non dispongono di un'infrastruttura IPC, non avviene alcuna comunicazione tra gli applet nel TEE. Ciò consente inoltre al servizio di archivio chiavi di negare rapidamente le richieste destinate a fallire poiché è a conoscenza della tabella di autenticazione nel sistema, risparmiando un IPC potenzialmente costoso nel TEE.