Gatekeeper

Il sottosistema Gatekeeper esegue l'autenticazione della sequenza/password del dispositivo in un Trusted Execution Environment (TEE). Gatekeeper registra e verifica le password utilizzando una chiave segreta basata sulla crittografia hardware. Inoltre, Gatekeeper limita i tentativi di verifica falliti consecutivi e deve rifiutare di gestire le richieste in base a un determinato timeout e a un determinato numero di tentativi falliti consecutivi.

Quando gli utenti verificano le proprie password, Gatekeeper emette un token di autenticazione firmato con una chiave HMAC per avvio disponibile solo per i componenti sicuri e questo token viene inviato al Keystore con crittografia hardware. Ciò significa che un token di autenticazione Gatekeeper notifica a Keystore che le chiavi associate all'autenticazione (ad esempio le chiavi create dalle app) possono essere utilizzate dalle app.

Architettura

Gatekeeper include tre componenti principali:

• gatekeeperd (daemon Gatekeeper): un servizio Binder C++ in Android che contiene una logica indipendente dalla piattaforma che implementa l'IGateKeeperService interfaccia AIDL, basata su un'implementazione sottostante specifica del fornitore di IGatekeeper.
• Servizio del livello di astrazione hardware (HAL) Gatekeeper : un' implementazione specifica del fornitore dell' interfaccia AIDL IGatekeeper. Questo servizio HAL viene eseguito in Android, ma la funzionalità principale di Gatekeeper deve essere eseguita in un ambiente sicuro, quindi in genere comunica con il TA Gatekeeper.
• Applicazione attendibile (TA) Gatekeeper : un'implementazione specifica del fornitore che viene eseguita nel TEE ed esegue la verifica effettiva della password o della sequenza.

LockSettingsService effettua una richiesta (tramite Binder) che raggiunge il daemon gatekeeperd nel sistema operativo Android. Il daemon gatekeeperd effettua quindi una richiesta del servizio HAL IGatekeeper, che a sua volta raggiunge la controparte TA Gatekeeper nel TEE:

Figura 1. Flusso di dati di alto livello per l'autenticazione tramite Gatekeeper.

Il daemon gatekeeperd fornisce alle API del framework Android l'accesso all'HAL e partecipa alla segnalazione delle autenticazioni dei dispositivi a Keystore. Il daemon gatekeeperd viene eseguito nel proprio processo ed è separato dal server di sistema.

Implementazione HAL

Il daemon gatekeeperd utilizza l'HAL IGatekeeper per interagire con il TA Gatekeeper sottostante per l'autenticazione della password. L'implementazione del TA Gatekeeper deve essere in grado di firmare (registrare) e verificare i blob. Tutte le implementazioni devono rispettare il formato standard per il token di autenticazione (HardwareAuthToken) generato a ogni verifica della password riuscita. Per informazioni dettagliate sul contenuto e sulla semantica di HardwareAuthToken, consulta la HardwareAuthToken.aidl definizione.

Le implementazioni del fornitore dell'HAL IGatekeeper devono implementare le funzioni enroll e verify:

• Il metodo enroll accetta un blob della password, lo firma e restituisce la firma come handle. Il blob restituito (da una chiamata a enroll) deve avere la struttura mostrata in system/gatekeeper/include/gatekeeper/password_handle.h.
• La funzione verify deve confrontare la firma prodotta dalla password fornita e assicurarsi che corrisponda all'handle della password registrata.

La chiave utilizzata per la registrazione e la verifica non deve mai cambiare e deve essere nuovamente derivabile a ogni avvio del dispositivo.

Trusty e altre implementazioni

Il sistema operativo Trusty è il sistema operativo attendibile open source di Google per gli ambienti TEE e contiene un'implementazione approvata di Gatekeeper. Tuttavia, qualsiasi sistema operativo TEE può implementare Gatekeeper a condizione che il TEE abbia accesso a una chiave con integrazione hardware persistente e a un orologio sicuro e monotono che funziona in sospensione.

Trusty utilizza un sistema IPC interno per comunicare un segreto condiviso direttamente tra KeyMint (in precedenza Keymaster) e l'implementazione Trusty di Gatekeeper (il Trusty Gatekeeper). Questo segreto condiviso viene utilizzato per firmare gli AuthToken inviati a Keystore per fornire attestazioni della verifica della password. Trusty Gatekeeper richiede la chiave a KeyMint per ogni utilizzo e non conserva né memorizza nella cache il valore. Le implementazioni sono libere di condividere questo segreto in qualsiasi modo che non comprometta la sicurezza.

La chiave HMAC utilizzata per la registrazione e la verifica delle password viene derivata e conservata esclusivamente in Gatekeeper.

Android fornisce un'implementazione generica di Gatekeeper in C++ che richiede solo l'aggiunta di routine specifiche del dispositivo per essere completata; l'implementazione Trusty si basa su questa. Per implementare un Gatekeeper TEE con codice specifico del dispositivo per il tuo TEE, consulta le funzioni e i commenti in system/gatekeeper/include/gatekeeper/gatekeeper.h. Le responsabilità principali di un'implementazione conforme includono:

• Rispetto dell'HAL IGatekeeper.
• I token di autenticazione restituiti devono essere formattati in base alla HardwareAuthToken specifica (descritta in Autenticazione).
• Il Gatekeeper TEE deve essere in grado di condividere una chiave HMAC con KeyMint, richiedendo la chiave tramite un IPC TEE on demand o mantenendo una cache valida del valore in qualsiasi momento.

ID sicuri utente (SID)

Un SID utente è la rappresentazione TEE di un utente (senza una connessione forte a un ID utente Android). Il SID viene generato con un generatore di numeri pseudocasuali crittografici (PRNG) ogni volta che un utente registra una nuova password senza fornirne una precedente. Questa operazione è nota come registrazione non attendibile e in genere si verifica solo quando un utente imposta per la prima volta una password o una sequenza.

Una registrazione attendibile si verifica quando un utente fornisce una password precedente valida, ad esempio quando cambia la password. In questo caso, il SID utente viene migrato al nuovo handle della password, conservando le chiavi a cui era associato.

Il SID utente è incluso nell'autenticazione HMAC insieme alla password nell'handle della password quando la password viene registrata.

I SID utente sono inclusi in HardwareAuthToken restituito dalla verify() funzione e associati a tutte le chiavi Keystore associate all'autenticazione (per informazioni dettagliate sul formato HardwareAuthToken e su Keystore, consulta Autenticazione).

Tieni presente che, poiché una chiamata non attendibile alla funzione enroll() modifica il SID utente, la chiamata rende inutili le chiavi associate a quella password. Gli autori di attacchi possono modificare la password del dispositivo se controllano il sistema operativo Android, ma distruggono le chiavi sensibili protette da root durante il processo.

Limitazione delle richieste

Gatekeeper deve essere in grado di limitare in modo sicuro i tentativi di attacco di forza bruta su una credenziale utente. Come mostrato in GatekeeperVerifyResponse.aidl, l'HAL prevede la restituzione di un timeout in millisecondi. Il timeout informa il client di non chiamare nuovamente Gatekeeper fino a quando non è trascorso il timeout. Gatekeeper non deve gestire le richieste se è in attesa un timeout.

Gatekeeper deve scrivere un contatore di errori prima di verificare la password di un utente. Se la verifica della password ha esito positivo, il contatore di errori deve essere cancellato. In questo modo si prevengono gli attacchi che impediscono la limitazione disattivando l'MMC (eMMC) incorporato dopo l'emissione di una chiamata verify. La funzione enroll verifica anche la password dell'utente (se fornita) e deve essere limitata nello stesso modo.

Se il dispositivo lo supporta, è vivamente consigliato di scrivere il contatore di errori in uno spazio di archiviazione sicuro. Se il dispositivo non supporta la crittografia basata su file o se lo spazio di archiviazione sicuro è troppo lento, le implementazioni possono utilizzare direttamente il blocco di memoria protetta da replay (RPMB).