Archivio chiavi supportato da hardware

La disponibilità di un ambiente di esecuzione affidabile in un sistema su chip (SoC) offre ai dispositivi Android l'opportunità di fornire servizi di sicurezza avanzati supportati da hardware al sistema operativo Android, ai servizi della piattaforma e persino alle app di terze parti. Gli sviluppatori che cercano estensioni specifiche per Android dovrebbero andare su android.security.keystore .

Prima di Android 6.0, Android disponeva già di una semplice API per servizi di crittografia supportata da hardware, fornita dalle versioni 0.2 e 0.3 di Keymaster Hardware Abstraction Layer (HAL). Keystore ha fornito operazioni di firma digitale e verifica, oltre alla generazione e importazione di coppie di chiavi di firma asimmetrica. Questo è già implementato su molti dispositivi, ma ci sono molti obiettivi di sicurezza che non possono essere facilmente raggiunti solo con un'API di firma. Keystore in Android 6.0 ha esteso l'API Keystore per fornire una gamma più ampia di funzionalità.

In Android 6.0, Keystore ha aggiunto primitive crittografiche simmetriche , AES e HMAC e un sistema di controllo degli accessi per le chiavi supportate da hardware. I controlli di accesso vengono specificati durante la generazione della chiave e applicati per tutta la durata della chiave. È possibile limitare l'utilizzo delle chiavi solo dopo che l'utente è stato autenticato e solo per scopi specifici o con parametri crittografici specifici. Per ulteriori informazioni, vedere le pagine Tag e funzioni di autorizzazione.

Oltre ad espandere la gamma di primitive crittografiche, Keystore in Android 6.0 ha aggiunto quanto segue:

  • Uno schema di controllo dell'utilizzo per consentire di limitare l'utilizzo delle chiavi, per mitigare il rischio di compromissione della sicurezza a causa dell'uso improprio delle chiavi
  • Uno schema di controllo dell'accesso per consentire la restrizione delle chiavi a utenti, client specificati e un intervallo di tempo definito

In Android 7.0, Keymaster 2 ha aggiunto il supporto per l'attestazione della chiave e l'associazione della versione. L'attestazione della chiave fornisce certificati a chiave pubblica che contengono una descrizione dettagliata della chiave e dei relativi controlli di accesso, per rendere verificabile in remoto l'esistenza della chiave in un hardware sicuro e la sua configurazione.

L'associazione della versione vincola le chiavi al sistema operativo e alla versione a livello di patch. Ciò garantisce che un utente malintenzionato che scopre un punto debole in una vecchia versione del sistema o nel software TEE non possa riportare un dispositivo alla versione vulnerabile e utilizzare le chiavi create con la versione più recente. Inoltre, quando una chiave con una determinata versione e livello di patch viene utilizzata su un dispositivo che è stato aggiornato a una versione o a un livello di patch più recente, la chiave viene aggiornata prima di poter essere utilizzata e la versione precedente della chiave viene invalidata. Man mano che il dispositivo viene aggiornato, i tasti "si spostano" in avanti insieme al dispositivo, ma qualsiasi ripristino del dispositivo a una versione precedente rende i tasti inutilizzabili.

In Android 8.0, Keymaster 3 è passato dal vecchio HAL (Hardware Abstraction Layer) con struttura C all'interfaccia HAL C++ generata da una definizione nel nuovo HIDL (Hardware Interface Definition Language). Come parte della modifica, molti tipi di argomenti sono cambiati, sebbene tipi e metodi abbiano una corrispondenza uno a uno con i vecchi tipi e i metodi della struttura HAL. Consulta la pagina Funzioni per maggiori dettagli.

Oltre a questa revisione dell'interfaccia, Android 8.0 ha esteso la funzionalità di attestazione di Keymaster 2 per supportare l'attestazione dell'ID . L'attestazione dell'ID fornisce un meccanismo limitato e facoltativo per attestare in modo sicuro gli identificatori hardware, come il numero di serie del dispositivo, il nome del prodotto e l'ID del telefono (IMEI/MEID). Per implementare questa aggiunta, Android 8.0 ha modificato lo schema di attestazione ASN.1 per aggiungere l'attestazione ID. Le implementazioni di Keymaster devono trovare un modo sicuro per recuperare i dati rilevanti, nonché definire un meccanismo per disabilitare in modo sicuro e permanente la funzionalità.

In Android 9, gli aggiornamenti includevano:

  • Aggiornamento a Keymaster 4
  • Supporto per Secure Elements incorporati
  • Supporto per l'importazione di chiavi sicure
  • Supporto per la crittografia 3DES
  • Modifiche all'associazione della versione in modo che boot.img e system.img abbiano versioni impostate separatamente per consentire aggiornamenti indipendenti

Glossario

Di seguito è riportata una rapida panoramica dei componenti Keystore e delle relative relazioni.

AndroidKeystore è l'API e il componente Android Framework utilizzato dalle app per accedere alla funzionalità Keystore. È implementato come estensione delle API Java Cryptography Architecture standard ed è costituito da codice Java eseguito nello spazio di processo dell'app. AndroidKeystore soddisfa le richieste dell'app per il comportamento del keystore inoltrandole al daemon del keystore.

Il demone del keystore è un demone del sistema Android che fornisce l'accesso a tutte le funzionalità del keystore tramite un'API Binder . È responsabile dell'archiviazione di "blob di chiavi", che contengono il materiale della chiave segreta effettiva, crittografato in modo che Keystore possa archiviarli ma non utilizzarli o rivelarli.

keymasterd è un server HIDL che fornisce l'accesso a Keymaster TA. (Questo nome non è standardizzato ed è per scopi concettuali.)

Keymaster TA (applicazione attendibile) è il software in esecuzione in un contesto sicuro, molto spesso in TrustZone su un SoC ARM, che fornisce tutte le operazioni sicure del Keystore, ha accesso al materiale grezzo della chiave, convalida tutte le condizioni di controllo dell'accesso sulle chiavi , eccetera.

LockSettingsService è il componente del sistema Android responsabile dell'autenticazione dell'utente, sia della password che dell'impronta digitale. Non fa parte di Keystore, ma è rilevante perché molte operazioni chiave di Keystore richiedono l'autenticazione dell'utente. LockSettingsService interagisce con Gatekeeper TA e Fingerprint TA per ottenere token di autenticazione, che fornisce al daemon del keystore e che vengono infine utilizzati dall'applicazione Keymaster TA.

Gatekeeper TA (applicazione attendibile) è un altro componente in esecuzione nel contesto sicuro, responsabile dell'autenticazione delle password degli utenti e della generazione di token di autenticazione utilizzati per dimostrare al Keymaster TA che è stata eseguita un'autenticazione per un particolare utente in un particolare momento.

Fingerprint TA (applicazione attendibile) è un altro componente in esecuzione nel contesto sicuro che è responsabile dell'autenticazione delle impronte digitali dell'utente e della generazione di token di autenticazione utilizzati per dimostrare al Keymaster TA che è stata eseguita un'autenticazione per un particolare utente in un particolare momento.

Architettura

L'API Android Keystore e il Keymaster HAL sottostante forniscono un set base ma adeguato di primitive crittografiche per consentire l'implementazione di protocolli utilizzando chiavi supportate da hardware e con accesso controllato.

Keymaster HAL è una libreria caricabile dinamicamente fornita dall'OEM utilizzata dal servizio Keystore per fornire servizi di crittografia supportati da hardware. Per mantenere le cose sicure, le implementazioni HAL non eseguono operazioni sensibili nello spazio utente o anche nello spazio kernel. Le operazioni sensibili sono delegate a un processore sicuro raggiunto tramite alcune interfacce del kernel. L'architettura risultante è simile alla seguente:

Accesso a Keymaster

Figura 1. Accesso a Keymaster

All'interno di un dispositivo Android, il "client" del Keymaster HAL è costituito da più livelli (ad esempio app, framework, demone Keystore), ma ciò può essere ignorato ai fini di questo documento. Ciò significa che l'API HAL Keymaster descritta è di basso livello, utilizzata da componenti interni alla piattaforma e non esposta agli sviluppatori di app. L'API di livello superiore è descritta sul sito degli sviluppatori Android .

Lo scopo del Keymaster HAL non è quello di implementare gli algoritmi sensibili alla sicurezza ma solo di inviare e annullare il marshalling delle richieste al mondo sicuro. Il formato del cavo è definito dall'implementazione.

Compatibilità con le versioni precedenti

L'HAL Keymaster 1 è completamente incompatibile con gli HAL rilasciati in precedenza, ad esempio Keymaster 0.2 e 0.3. Per facilitare l'interoperabilità sui dispositivi che eseguono Android 5.0 e versioni precedenti lanciate con i vecchi Keymaster HAL, Keystore fornisce un adattatore che implementa Keymaster 1 HAL con chiamate alla libreria hardware esistente. Il risultato non può fornire la gamma completa di funzionalità nell'HAL Keymaster 1. In particolare, supporta solo gli algoritmi RSA ed ECDSA e tutta l'applicazione delle autorizzazioni chiave viene eseguita dall'adattatore, nel mondo non sicuro.

Keymaster 2 ha ulteriormente semplificato l'interfaccia HAL rimuovendo i metodi get_supported_* e consentendo al metodo finish() di accettare input. Ciò riduce il numero di viaggi di andata e ritorno al TEE nei casi in cui l'input è disponibile tutto in una volta e semplifica l'implementazione della decrittografia AEAD.

In Android 8.0, Keymaster 3 è passato dall'HAL con struttura C vecchio stile all'interfaccia HAL C++ generata da una definizione nel nuovo Hardware Interface Definition Language (HIDL). Viene creata un'implementazione HAL di nuovo stile creando una sottoclasse della classe IKeymasterDevice generata e implementando i metodi virtuali puri. Come parte del cambiamento, molti tipi di argomenti sono cambiati, sebbene tipi e metodi abbiano una corrispondenza uno a uno con i vecchi tipi e i metodi della struttura HAL.

Panoramica dell'HIDL

L'HIDL (Hardware Interface Definition Language) fornisce un meccanismo di implementazione indipendente dal linguaggio per specificare le interfacce hardware. Gli strumenti HIDL attualmente supportano la generazione di interfacce C++ e Java. Si prevede che la maggior parte degli implementatori TEE (Trusted Execution Environment) troveranno gli strumenti C++ più convenienti, quindi questo documento discute solo la rappresentazione C++.

Le interfacce HIDL sono costituite da un insieme di metodi, espressi come:

  methodName(INPUT ARGUMENTS) generates (RESULT ARGUMENTS);

Esistono vari tipi predefiniti e gli HAL possono definire nuovi tipi enumerati e di struttura. Per ulteriori dettagli su HIDL, consultare la sezione Riferimenti .

Un metodo di esempio da Keymaster 3 IKeymasterDevice.hal è:

generateKey(vec<KeyParameter> keyParams)
        generates(ErrorCode error, vec<uint8_t> keyBlob,
                  KeyCharacteristics keyCharacteristics);

Questo è l'equivalente di quanto segue dall'HAL keymaster2:

keymaster_error_t (*generate_key)(
        const struct keymaster2_device* dev,
        const keymaster_key_param_set_t* params,
        keymaster_key_blob_t* key_blob,
        keymaster_key_characteristics_t* characteristics);

Nella versione HIDL, l'argomento dev viene rimosso perché è implicito. L'argomento params non è più una struttura contenente un puntatore che fa riferimento a un array di oggetti key_parameter_t , ma un vec (vettore) contenente oggetti KeyParameter . I valori restituiti sono elencati nella clausola " generates ", incluso un vettore di valori uint8_t per il BLOB di chiave.

Il metodo virtuale C++ generato dal compilatore HIDL è:

Return<void> generateKey(const hidl_vec<KeyParameter>& keyParams,
                         generateKey_cb _hidl_cb) override;

Dove generateKey_cb è un puntatore a funzione definito come:

std::function<void(ErrorCode error, const hidl_vec<uint8_t>& keyBlob,
                   const KeyCharacteristics& keyCharacteristics)>

Cioè, generateKey_cb è una funzione che accetta i valori restituiti elencati nella clausola generate. La classe di implementazione HAL sovrascrive questo metodo generateKey e chiama il puntatore alla funzione generateKey_cb per restituire il risultato dell'operazione al chiamante. Si noti che la chiamata del puntatore a funzione è sincrona . Il chiamante chiama generateKey e generateKey chiama il puntatore alla funzione fornito, che viene eseguito fino al completamento, restituendo il controllo all'implementazione generateKey , che poi ritorna al chiamante.

Per un esempio dettagliato, vedere l'implementazione predefinita in hardware/interfaces/keymaster/3.0/default/KeymasterDevice.cpp . L'implementazione predefinita fornisce la compatibilità con le versioni precedenti per i dispositivi con HALS keymaster0, keymaster1 o keymaster2 vecchio stile.

Controllo di accesso

La regola più elementare del controllo dell'accesso al Keystore è che ogni app ha il proprio spazio dei nomi. Ma per ogni regola c'è un'eccezione. Keystore dispone di alcune mappe codificate che consentono a determinati componenti del sistema di accedere a determinati altri spazi dei nomi. Questo è uno strumento molto schietto in quanto dà a un componente il pieno controllo su un altro spazio dei nomi. E poi c'è la questione dei componenti del fornitore come clienti di Keystore. Al momento non abbiamo modo di stabilire uno spazio dei nomi per i componenti del fornitore, ad esempio il supplicant WPA.

Per accogliere i componenti dei fornitori e generalizzare il controllo degli accessi senza eccezioni codificate, Keystore 2.0 introduce domini e spazi dei nomi SELinux.

Domini archivio chiavi

Con i domini Keystore, possiamo disaccoppiare gli spazi dei nomi dagli UID. I client che accedono a una chiave in Keystore devono specificare il dominio, lo spazio dei nomi e l'alias a cui desiderano accedere. Sulla base di questa tupla e dell'identità del chiamante possiamo determinare a quale chiave il chiamante desidera accedere e se dispone delle autorizzazioni appropriate.

Introduciamo cinque parametri di dominio che regolano il modo in cui è possibile accedere alle chiavi. Controllano la semantica del parametro dello spazio dei nomi del descrittore di chiave e il modo in cui viene eseguito il controllo dell'accesso.

  • DOMAIN_APP : il dominio dell'app copre il comportamento legacy. La SPI Java Keystore utilizza questo dominio per impostazione predefinita. Quando viene utilizzato questo dominio, l'argomento namespace viene ignorato e viene utilizzato invece l'UID del chiamante. L'accesso a questo dominio è controllato dall'etichetta Keystore sulla classe keystore_key nella policy SELinux.
  • DOMAIN_SELINUX : questo dominio indica che lo spazio dei nomi ha un'etichetta nella politica SELinux. Il parametro namespace viene cercato e tradotto in un contesto di destinazione, e viene eseguito un controllo dei permessi per il contesto SELinux chiamante per la classe keystore_key . Una volta stabilita l'autorizzazione per una determinata operazione, per la ricerca della chiave viene utilizzata la tupla completa.
  • DOMAIN_GRANT : il dominio di concessione indica che il parametro dello spazio dei nomi è un identificatore di concessione. Il parametro alias viene ignorato. I controlli SELinux vengono eseguiti al momento della creazione della concessione. Un ulteriore controllo dell'accesso verifica solo se l'UID del chiamante corrisponde all'UID del beneficiario della sovvenzione richiesta.
  • DOMAIN_KEY_ID : questo dominio indica che il parametro dello spazio dei nomi è un ID chiave univoco. La chiave stessa potrebbe essere stata creata con DOMAIN_APP o DOMAIN_SELINUX . Il controllo delle autorizzazioni viene eseguito dopo che il domain e lo namespace sono stati caricati dal database delle chiavi come se il BLOB fosse stato caricato dal dominio, dallo spazio dei nomi e dalla tupla dell'alias. La logica alla base del dominio ID chiave è la continuità. Quando si accede a una chiave tramite alias, le chiamate successive potrebbero operare su chiavi diverse, perché una nuova chiave potrebbe essere stata generata o importata e associata a questo alias. L'ID della chiave, tuttavia, non cambia mai. Pertanto, quando si utilizza una chiave per ID chiave dopo che è stata caricata dal database Keystore utilizzando l'alias una volta, si può essere certi che si tratti della stessa chiave purché l'ID chiave esista ancora. Questa funzionalità non è esposta agli sviluppatori di app. Viene invece utilizzato all'interno dell'SPI di Android Keystore per fornire un'esperienza più coerente anche se utilizzato contemporaneamente in modo non sicuro.
  • DOMAIN_BLOB : il dominio BLOB indica che il chiamante gestisce il BLOB da solo. Viene utilizzato per i client che devono accedere al keystore prima che la partizione dati venga montata. Il blob chiave è incluso nel campo blob del descrittore chiave.

Utilizzando il dominio SELinux, possiamo fornire ai componenti del fornitore l'accesso a spazi dei nomi Keystore molto specifici che possono essere condivisi dai componenti di sistema come la finestra di dialogo delle impostazioni.

Politica SELinux per keystore_key

Le etichette dello spazio dei nomi vengono configurate utilizzando il file keystore2_key_context .
Ogni riga in questi file mappa un ID numerico dello spazio dei nomi su un'etichetta SELinux. Per esempio,

# wifi_key is a keystore2_key namespace intended to be used by wpa supplicant and
# Settings to share keystore keys.
102            u:object_r:wifi_key:s0

Dopo aver impostato un nuovo spazio dei nomi della chiave in questo modo, possiamo consentirne l'accesso aggiungendo una policy appropriata. Ad esempio, per consentire wpa_supplicant di ottenere e utilizzare le chiavi nel nuovo spazio dei nomi aggiungeremmo la seguente riga a hal_wifi_supplicant.te :

allow hal_wifi_supplicant wifi_key:keystore2_key { get, use };

Dopo aver impostato il nuovo spazio dei nomi, AndroidKeyStore può essere utilizzato quasi come al solito. L'unica differenza è che l'ID dello spazio dei nomi deve essere specificato. Per caricare e importare chiavi da e in Keystore, l'ID dello spazio dei nomi viene specificato utilizzando AndroidKeyStoreLoadStoreParameter . Per esempio,

import android.security.keystore2.AndroidKeyStoreLoadStoreParameter;
import java.security.KeyStore;

KeyStore keystore = KeyStore.getInstance("AndroidKeyStore");
keystore.load(new AndroidKeyStoreLoadStoreParameter(102));

Per generare una chiave in un determinato spazio dei nomi, è necessario fornire l'ID dello spazio dei nomi utilizzando KeyGenParameterSpec.Builder#setNamespace():

import android.security.keystore.KeyGenParameterSpec;
KeyGenParameterSpec.Builder specBuilder = new KeyGenParameterSpec.Builder();
specBuilder.setNamespace(102);

I seguenti file di contesto possono essere utilizzati per configurare gli spazi dei nomi SELinux Keystore 2.0. Ogni partizione ha un intervallo riservato diverso di 10.000 ID di spazio dei nomi per evitare collisioni.

Partizione Allineare File di configurazione
Sistema 0...9.999
/system/etc/selinux/keystore2_key_contexts, /plat_keystore2_key_contexts
Sistema esteso 10.000...19.999
/system_ext/etc/selinux/system_ext_keystore2_key_contexts, /system_ext_keystore2_key_contexts
Prodotto 20.000...29.999
/product/etc/selinux/product_keystore2_key_contexts, /product_keystore2_key_contexts
Venditore 30.000...39.999
/vendor/etc/selinux/vendor_keystore2_key_contexts, /vendor_keystore2_key_contexts

Il client richiede la chiave richiedendo il dominio SELinux e lo spazio dei nomi virtuale desiderato, in questo caso "wifi_key" , tramite il suo ID numerico.

Oltre a ciò, sono stati definiti i seguenti spazi dei nomi. Se sostituiscono regole speciali, la tabella seguente indica l'UID a cui corrispondevano.

ID dello spazio dei nomi Etichetta SEPolicy UID Descrizione
0 su_key N / A Chiave superutente. Utilizzato solo per testare userdebug e build eng. Non rilevante per le build degli utenti.
1 chiave_shell N / A Spazio dei nomi disponibile per la shell. Utilizzato principalmente per i test, ma può essere utilizzato anche sulle build degli utenti dalla riga di comando.
100 vold_key N / A Destinato all'uso da parte di vold.
101 odsing_key N / A Utilizzato dal demone di firma sul dispositivo.
102 chiave_wifi AIUTO_WIFI(1010) Utilizzato dal sistema Wi-Fi di Android incluso wpa_supplicant.
120 curriculum_on_reboot_key AIUTO_SISTEMA(1000) Utilizzato dal server di sistema di Android per supportare la ripresa al riavvio.

Accedere ai vettori

La classe keystore_key di SELinux è invecchiata un po' e alcuni permessi, come verify o sign , hanno perso il loro significato. Ecco il nuovo set di autorizzazioni, keystore2_key , che verrà applicato da Keystore 2.0.

Autorizzazione Senso
delete Selezionato durante la rimozione delle chiavi da Keystore.
get_info Selezionato quando vengono richiesti i metadati di una chiave.
grant Il chiamante necessita di questa autorizzazione per creare una concessione alla chiave nel contesto di destinazione.
manage_blob Il chiamante può utilizzare DOMAIN_BLOB sul namespace SELinux specificato, gestendo quindi i BLOB da solo. Questo è particolarmente utile per vold.
rebind Questa autorizzazione controlla se un alias può essere ricollegato a una nuova chiave. Questo è necessario per l'inserimento e implica che la chiave precedentemente associata verrà eliminata. Si tratta fondamentalmente di un'autorizzazione di inserimento, ma cattura meglio la semantica del keystore.
req_forced_op I client con questa autorizzazione possono creare operazioni non eliminabili e la creazione dell'operazione non fallisce mai a meno che tutti gli slot operativi non vengano occupati da operazioni non eliminabili.
update Necessario per aggiornare il sottocomponente di una chiave.
use Selezionato durante la creazione di un'operazione Keymint che utilizza il materiale della chiave, ad esempio, per la firma, la codifica/decrittografia.
use_dev_id Obbligatorio quando si generano informazioni di identificazione del dispositivo, ad esempio l'attestazione dell'ID del dispositivo.

Inoltre, abbiamo suddiviso una serie di permessi del keystore non specifici per la chiave nella classe di sicurezza keystore2 di SELinux:

Autorizzazione Senso
add_auth Richiesto dal provider di autenticazione come Gatekeeper o BiometricsManager per l'aggiunta di token di autenticazione.
clear_ns Precedentemente clear_uid, questa autorizzazione consente a chi non è proprietario di uno spazio dei nomi di eliminare tutte le chiavi in ​​quello spazio dei nomi.
list Richiesto dal sistema per enumerare le chiavi in ​​base a varie proprietà, ad esempio la proprietà o i limiti di autenticazione. Questa autorizzazione non è richiesta ai chiamanti che enumerano i propri spazi dei nomi. Ciò è coperto dall'autorizzazione get_info .
lock Questa autorizzazione consente di bloccare Keystore, ovvero di eliminare la chiave principale, in modo tale che le chiavi associate all'autenticazione diventino inutilizzabili e non creabili.
reset Questa autorizzazione consente di ripristinare le impostazioni di fabbrica di Keystore, eliminando tutte le chiavi che non sono vitali per il funzionamento del sistema operativo Android.
unlock Questa autorizzazione è necessaria per tentare di sbloccare la chiave master per le chiavi associate all'autenticazione.