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

Keystore con supporto hardware

La disponibilità di un ambiente di esecuzione affidabile in un sistema su chip (SoC) offre ai dispositivi Android un'opportunità per fornire servizi di sicurezza robusti e supportati da hardware al sistema operativo Android, ai servizi della piattaforma e persino alle app di terze parti. Gli sviluppatori che cercano le 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 del Keymaster Hardware Abstraction Layer (HAL). Keystore ha fornito operazioni di firma e verifica digitale, oltre alla generazione e all'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 con una sola API di firma. Keystore in Android 6.0 estende 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 chiavi con supporto hardware. I controlli di accesso vengono specificati durante la generazione della chiave e applicati per la durata della chiave. Le chiavi possono essere limitate per essere utilizzabili solo dopo che l'utente si è autenticato e solo per scopi specifici o con parametri crittografici specificati. Per ulteriori informazioni, vedere le pagine Tag di autorizzazione e funzioni .

Oltre ad espandere la gamma di primitive crittografiche, Keystore in Android 6.0 aggiunge 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 abilitare la restrizione delle chiavi a utenti, client 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 di 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 protetto e la sua configurazione.

L'associazione della versione associa 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 del 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 un livello di patch più recenti, la chiave viene aggiornata prima di poter essere utilizzata e la versione precedente della chiave viene invalidata. Man mano che il dispositivo viene aggiornato, le chiavi si spostano in avanti insieme al dispositivo, ma qualsiasi ripristino del dispositivo a una versione precedente rende le chiavi inutilizzabili.

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

Oltre a questa revisione dell'interfaccia, Android 8.0 estende la funzione di attestazione di Keymaster 2 per supportare l' attestazione dell'ID . L'attestazione dell'ID fornisce un meccanismo limitato e facoltativo per attestare con forza 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, modificare lo schema di attestazione ASN.1 per aggiungere l'attestazione ID. Le implementazioni di Keymaster devono trovare un modo sicuro per recuperare gli elementi di dati rilevanti, oltre a definire un meccanismo per disabilitare in modo sicuro e permanente la funzione.

In Android 9, gli aggiornamenti includono:

  • Aggiorna a Keymaster 4
  • Supporto per elementi protetti incorporati
  • Supporto per l'importazione sicura delle chiavi
  • Supporto per la crittografia 3DES
  • Modifiche all'associazione di versione in modo che boot.img e system.img abbiano versioni impostate separatamente per consentire aggiornamenti indipendenti

Glossario

Ecco una rapida panoramica dei componenti del Keystore e delle loro relazioni.

AndroidKeystore è l'API di Framework Android e il componente utilizzato dalle app per accedere alla funzionalità di archivio chiavi . È implementato come un'estensione delle API Java Cryptography Architecture standard e consiste in codice Java che viene eseguito nello spazio di elaborazione dell'app. AndroidKeystore soddisfa le richieste delle app per il comportamento del keystore inoltrandole al daemon del keystore.

Il daemon del keystore è un daemon del sistema Android che fornisce l'accesso a tutte le funzionalità del Keystore tramite un'API Binder . È responsabile della memorizzazione dei "blob di chiavi", che contengono il materiale della chiave segreta effettiva, crittografato in modo che Keystore possa archiviarlo ma non usarlo o rivelarlo.

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, il più delle volte in TrustZone su un SoC ARM, che fornisce tutte le operazioni di Keystore sicure, ha accesso al materiale della chiave grezza, 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 i 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 protetto, 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 determinato momento.

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

Architettura

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

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

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, daemon Keystore), ma che possono essere ignorati ai fini di questo documento. Ciò significa che l'API Keymaster HAL descritta è di basso livello, utilizzata dai componenti interni alla piattaforma e non esposta agli sviluppatori di app. L'API di livello superiore è descritta sul sito per sviluppatori Android .

Lo scopo del Keymaster HAL non è quello di implementare gli algoritmi sensibili alla sicurezza, ma solo di effettuare il marshalling e l'annullamento del marshalling delle richieste nel mondo protetto. Il formato del filo è definito dall'implementazione.

Compatibilità con le versioni precedenti

Il Keymaster 1 HAL è 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 precedenti Keymaster HAL, Keystore fornisce un adattatore che implementa l'HAL Keymaster 1 con chiamate alla libreria hardware esistente. Il risultato non può fornire l'intera gamma di funzionalità nel Keymaster 1 HAL. In particolare, supporta solo algoritmi RSA ed ECDSA e tutta l'applicazione dell'autorizzazione della chiave viene eseguita dall'adattatore, nel mondo non protetto.

Keymaster 2 ha ulteriormente semplificato l'interfaccia HAL rimuovendo i metodi get_supported_* e consentendo al metodo finish() di accettare l'input. Ciò riduce il numero di round trip 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 dalla vecchia struttura a C HAL all'interfaccia C ++ HAL generata da una definizione nel nuovo HIDL (Hardware Interface Definition Language). Un'implementazione HAL di nuovo stile viene creata creando una sottoclasse della classe IKeymasterDevice generata e implementando i metodi virtuali puri. Come parte del cambiamento, molti dei tipi di argomenti sono cambiati, sebbene i tipi ei metodi abbiano una corrispondenza uno a uno con i vecchi tipi e con i metodi della struttura HAL.

Panoramica di 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 di Trusted Execution Environment (TEE) 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 maggiori dettagli su HIDL, vedere 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 dal keymaster2 HAL:

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 chiavi.

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

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

Dove generate_cb è un puntatore a funzione definito come:

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

Cioè, generate_cb è una funzione che accetta i valori di ritorno elencati nella clausola generate. La classe di implementazione HAL sovrascrive questo metodo generateKey e chiama il puntatore alla funzione generate_cb per restituire il risultato dell'operazione al chiamante. Notare che la chiamata del puntatore alla funzione è sincrona . Il chiamante chiama generateKey e generateKey chiama il puntatore a funzione fornito, che viene eseguito fino al completamento, restituendo il controllo all'implementazione generateKey , che quindi 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.