Google is committed to advancing racial equity for Black communities. See how.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Gatekeeper

Il sottosistema Gatekeeper esegue l'autenticazione con pattern / password del dispositivo in un TEE (Trusted Execution Environment). Gatekeeper registra e verifica le password tramite un HMAC con una chiave segreta supportata da hardware. Inoltre, Gatekeeper limita i tentativi di verifica non riusciti consecutivi e deve rifiutare le richieste di servizio in base a un determinato timeout e un determinato numero di tentativi falliti consecutivi.

Quando gli utenti verificano le proprie password, Gatekeeper utilizza il segreto condiviso derivato da TEE per firmare un attestato di autenticazione da inviare al Keystore supportato da hardware . Ovvero, un'attestazione Gatekeeper notifica a Keystore che le chiavi associate all'autenticazione (ad esempio, le chiavi create dalle app) possono essere rilasciate per l'uso da parte delle app.

Architettura

Gatekeeper coinvolge tre componenti principali:

  • gatekeeperd (demone Gatekeeper). Un servizio binder C ++ contenente logica indipendente dalla piattaforma e corrispondente GateKeeperService Java GateKeeperService .
  • Gatekeeper Hardware Abstraction Layer (HAL) . L'interfaccia HAL in hardware/libhardware/include/hardware/gatekeeper.h il modulo di implementazione.
  • Gatekeeper (TEE) . La controparte TEE di gatekeeperd . Un'implementazione basata su TEE di Gatekeeper.

Gatekeeper richiede l'implementazione del Gatekeeper HAL (in particolare le funzioni in hardware/libhardware/include/hardware/gatekeeper.h ) e il componente Gatekeeper specifico per TEE (basato in parte sul file di intestazione system/gatekeeper/include/gatekeeper/gatekeeper.h che include funzioni virtuali pure per creare / accedere a chiavi e firme informatiche).

Il LockSettingsService effettua una richiesta (tramite Binder) che raggiunge il demone gatekeeperd nel sistema operativo Android. Il demone gatekeeperd effettua quindi una richiesta che raggiunge la sua controparte (Gatekeeper) nel TEE:

Flusso di gatekeeper
Figura 1. Flusso di dati di alto livello per l'autenticazione da GateKeeper

Il daemon gatekeeperd consente alle API del framework Android di accedere all'HAL e partecipa alla segnalazione delle autenticazioni del dispositivo al Keystore. Il daemon gatekeeperd viene eseguito nel proprio processo ed è separato dal server di sistema.

Implementazione di HAL

Il daemon gatekeeperd utilizza l'HAL per interagire con la controparte TEE del daemon gatekeeperd per l'autenticazione della password. L'implementazione di HAL deve essere in grado di firmare (registrare) e verificare i BLOB. Si prevede che tutte le implementazioni aderiscano al formato standard per il token di autenticazione (AuthToken) generato ad ogni verifica della password riuscita. Per i dettagli sul contenuto e la semantica dell'AuthToken, vedere il formato AuthToken .

Le implementazioni del file di intestazione hardware/libhardware/include/hardware/gatekeeper.h devono implementare le funzioni di enroll e verify :

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

La chiave utilizzata per la registrazione e la verifica non deve mai cambiare e dovrebbe essere ri-derivabile ad ogni avvio del dispositivo.

Trusty e altre implementazioni

Il sistema operativo Trusty è il sistema operativo affidabile open source di Google per ambienti TEE e contiene un'implementazione approvata di GateKeeper. Tuttavia, è possibile utilizzare qualsiasi sistema operativo TEE per implementare Gatekeeper purché il TEE abbia accesso a una chiave supportata da hardware e un orologio monotono e sicuro che ticchetta in sospensione .

Trusty utilizza un sistema IPC interno per comunicare un segreto condiviso direttamente tra Keymaster e l'implementazione Trusty di Gatekeeper (il Trusty Gatekeeper ). Questo segreto condiviso viene utilizzato per firmare gli AuthToken inviati a Keystore per fornire attestati di verifica della password. Trusty Gatekeeper richiede la chiave a Keymaster per ogni utilizzo e non conserva o 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 registrare e verificare le password viene derivata e conservata esclusivamente in GateKeeper.

Android fornisce un'implementazione C ++ generica di GateKeeper che richiede solo l'aggiunta di routine specifiche del dispositivo per essere completata. Per implementare un system/gatekeeper/include/gatekeeper/gatekeeper.h TEE con codice specifico del dispositivo per il TEE, fare riferimento alle funzioni e ai commenti in system/gatekeeper/include/gatekeeper/gatekeeper.h . Per TEE GateKeeper, le responsabilità principali di un'implementazione conforme includono:

  • Adesione al Gatekeeper HAL.
  • Gli AuthToken restituiti devono essere formattati in base alla specifica AuthToken (descritta in Autenticazione ).
  • Il gatekeeper TEE deve essere in grado di condividere una chiave HMAC con Keymaster, richiedendo la chiave tramite un IPC TEE su richiesta o mantenendo una cache valida del valore in ogni momento.

ID utente protetti (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 nuova registrazione non attendibile e non è consentita dal framework Android in circostanze normali. Una nuova registrazione attendibile si verifica quando un utente fornisce una password precedente valida; in questo caso, il SID utente viene migrato al nuovo handle della password, conservando le chiavi che erano associate ad esso.

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

I SID utente vengono scritti nell'AuthToken restituito dalla funzione di verify e associati a tutte le chiavi del keystore legate all'autenticazione (per i dettagli sul formato AuthToken e sul Keystore, vedere Autenticazione ). Poiché una chiamata non attendibile alla funzione di enroll cambierà il SID utente, la chiamata renderà inutili le chiavi associate a quella password. Gli aggressori possono modificare la password del dispositivo se controllano il sistema operativo Android, ma durante il processo distruggeranno le chiavi sensibili e protette da root.

Richiedi limitazione

GateKeeper deve essere in grado di limitare in modo sicuro i tentativi di forza bruta su una credenziale utente. Come mostrato in hardware/libhardware/include/hardware/gatekeeper.h , 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 dovrebbe servire le richieste se c'è un timeout in sospeso.

GateKeeper deve scrivere un contatore di errori prima di verificare una password utente. Se la verifica della password riesce, il contatore degli errori dovrebbe essere cancellato. Ciò impedisce gli attacchi che impediscono la limitazione disabilitando la MMC incorporata (eMMC) dopo aver emesso una chiamata di verify . La funzione di enroll verifica anche la password dell'utente (se fornita) e deve essere limitata allo stesso modo.

Se supportato dal dispositivo, si consiglia vivamente di scrivere il contatore degli errori nell'archivio protetto. Se il dispositivo non supporta la crittografia basata su file o se l'archiviazione sicura è troppo lenta, le implementazioni possono utilizzare direttamente Replay Protected Memory Block (RPMB).