Hardwaregestützter Schlüsselspeicher

Die Verfügbarkeit einer vertrauenswürdigen Ausführungsumgebung in einem System-on-a-Chip (SoC) bietet Android-Geräten die Möglichkeit, hardwaregestützte, starke Sicherheitsdienste für das Android-Betriebssystem, Plattformdienste und sogar Apps von Drittanbietern bereitzustellen. Entwickler, die nach den Android-spezifischen Erweiterungen suchen, sollten zu android.security.keystore gehen.

Vor Android 6.0 verfügte Android bereits über eine einfache, hardwaregestützte API für Kryptodienste, die von den Versionen 0.2 und 0.3 des Keymaster Hardware Abstraction Layer (HAL) bereitgestellt wurde. Keystore stellte digitale Signatur- und Verifizierungsvorgänge sowie die Generierung und den Import asymmetrischer Signaturschlüsselpaare bereit. Dies ist bereits auf vielen Geräten implementiert, aber es gibt viele Sicherheitsziele, die nicht einfach nur mit einer Signatur-API erreicht werden können. Keystore in Android 6.0 erweiterte die Keystore-API, um ein breiteres Spektrum an Funktionen bereitzustellen.

In Android 6.0 fügte Keystore symmetrische kryptografische Primitive , AES und HMAC sowie ein Zugriffskontrollsystem für hardwaregestützte Schlüssel hinzu. Zugriffskontrollen werden während der Schlüsselgenerierung festgelegt und für die Lebensdauer des Schlüssels durchgesetzt. Schlüssel können so eingeschränkt werden, dass sie nur verwendbar sind, nachdem der Benutzer authentifiziert wurde, und nur für bestimmte Zwecke oder mit bestimmten kryptografischen Parametern. Weitere Informationen finden Sie auf den Seiten Autorisierungs-Tags und -Funktionen .

Neben der Erweiterung des Bereichs kryptografischer Primitive fügte Keystore in Android 6.0 Folgendes hinzu:

• Ein Nutzungskontrollschema, das die Einschränkung der Schlüsselnutzung ermöglicht, um das Risiko einer Sicherheitsgefährdung aufgrund von Missbrauch von Schlüsseln zu mindern
• Ein Zugriffskontrollschema, um die Beschränkung von Schlüsseln auf bestimmte Benutzer, Clients und einen definierten Zeitraum zu ermöglichen

In Android 7.0 fügte Keymaster 2 Unterstützung für Schlüsselnachweis und Versionsbindung hinzu. Die Schlüsselbestätigung stellt öffentliche Schlüsselzertifikate bereit, die eine detaillierte Beschreibung des Schlüssels und seiner Zugriffskontrollen enthalten, um die Existenz des Schlüssels in sicherer Hardware und seine Konfiguration aus der Ferne überprüfbar zu machen.

Die Versionsbindung bindet Schlüssel an das Betriebssystem und die Patch-Level-Version. Dadurch wird sichergestellt, dass ein Angreifer, der eine Schwachstelle in einer alten Version des Systems oder der TEE-Software entdeckt, ein Gerät nicht auf die verwundbare Version zurücksetzen und Schlüssel verwenden kann, die mit der neueren Version erstellt wurden. Wenn ein Schlüssel mit einer bestimmten Version und Patchebene auf einem Gerät verwendet wird, das auf eine neuere Version oder Patchebene aktualisiert wurde, wird der Schlüssel außerdem aktualisiert, bevor er verwendet werden kann, und die vorherige Version des Schlüssels wird ungültig. Wenn das Gerät aktualisiert wird, "ratschen" die Schlüssel zusammen mit dem Gerät vorwärts, aber jede Zurücksetzung des Geräts auf eine frühere Version führt dazu, dass die Schlüssel unbrauchbar werden.

In Android 8.0 wechselte Keymaster 3 von der alten C-Struktur Hardware Abstraction Layer (HAL) zur C++ HAL-Schnittstelle, die aus einer Definition in der neuen Hardware Interface Definition Language (HIDL) generiert wurde. Als Teil der Änderung haben sich viele der Argumenttypen geändert, obwohl Typen und Methoden eine Eins-zu-Eins-Entsprechung mit den alten Typen und den HAL-Strukturmethoden haben. Weitere Einzelheiten finden Sie auf der Seite Funktionen .

Zusätzlich zu dieser Überarbeitung der Benutzeroberfläche hat Android 8.0 die Beglaubigungsfunktion von Keymaster 2 erweitert, um die ID-Beglaubigung zu unterstützen. Die ID-Bestätigung bietet einen begrenzten und optionalen Mechanismus zum starken Bestätigen von Hardwarekennungen wie Geräteseriennummer, Produktname und Telefon-ID (IMEI/MEID). Um diesen Zusatz zu implementieren, hat Android 8.0 das ASN.1-Bestätigungsschema geändert, um eine ID-Bestätigung hinzuzufügen. Keymaster-Implementierungen müssen einen sicheren Weg finden, um die relevanten Datenelemente abzurufen, sowie einen Mechanismus zum sicheren und dauerhaften Deaktivieren der Funktion definieren.

In Android 9 enthaltene Updates:

• Update auf Keymaster 4
• Unterstützung für eingebettete sichere Elemente
• Unterstützung für sicheren Schlüsselimport
• Unterstützung für 3DES-Verschlüsselung
• Änderungen an der Versionsbindung, sodass boot.img und system.img separat festgelegte Versionen haben, um unabhängige Updates zu ermöglichen

Glossar

Hier ist ein kurzer Überblick über Keystore-Komponenten und ihre Beziehungen.

AndroidKeystore ist die Android Framework API und Komponente, die von Apps verwendet wird, um auf die Keystore-Funktionalität zuzugreifen. Es wird als Erweiterung der standardmäßigen Java Cryptography Architecture-APIs implementiert und besteht aus Java-Code, der im eigenen Prozessbereich der App ausgeführt wird. AndroidKeystore erfüllt App-Anforderungen für das Keystore-Verhalten, indem es sie an den Keystore-Daemon weiterleitet.

Der Keystore-Daemon ist ein Android-System-Daemon, der über eine Binder-API Zugriff auf alle Keystore-Funktionen bietet. Es ist verantwortlich für das Speichern von „Schlüssel-Blobs“, die das eigentliche geheime Schlüsselmaterial enthalten, verschlüsselt, sodass Keystore sie speichern, aber nicht verwenden oder offenlegen kann.

keymasterd ist ein HIDL-Server, der Zugriff auf den Keymaster TA bietet. (Dieser Name ist nicht standardisiert und dient konzeptionellen Zwecken.)

Keymaster TA (Trusted Application) ist die Software, die in einem sicheren Kontext ausgeführt wird, meistens in TrustZone auf einem ARM-SoC, der alle sicheren Keystore-Operationen bereitstellt, Zugriff auf das Rohschlüsselmaterial hat und alle Zugriffskontrollbedingungen für Schlüssel validiert , etc.

LockSettingsService ist die Android-Systemkomponente, die für die Benutzerauthentifizierung, sowohl Passwort als auch Fingerabdruck, verantwortlich ist. Es ist nicht Teil von Keystore, aber relevant, da viele Keystore-Schlüsseloperationen eine Benutzerauthentifizierung erfordern. LockSettingsService interagiert mit dem Gatekeeper-TA und dem Fingerabdruck-TA, um Authentifizierungstoken zu erhalten, die er dem Keystore-Daemon bereitstellt und die letztendlich von der Keymaster-TA-Anwendung verbraucht werden.

Gatekeeper TA (Trusted Application) ist eine weitere Komponente, die im sicheren Kontext ausgeführt wird und für die Authentifizierung von Benutzerpasswörtern und die Generierung von Authentifizierungstoken verantwortlich ist, die verwendet werden, um dem Keymaster TA zu beweisen, dass eine Authentifizierung für einen bestimmten Benutzer zu einem bestimmten Zeitpunkt durchgeführt wurde.

Fingerprint TA (Trusted Application) ist eine weitere Komponente, die im sicheren Kontext ausgeführt wird und für die Authentifizierung von Benutzerfingerabdrücken und die Generierung von Authentifizierungstoken verantwortlich ist, die verwendet werden, um dem Keymaster TA zu beweisen, dass eine Authentifizierung für einen bestimmten Benutzer zu einem bestimmten Zeitpunkt durchgeführt wurde.

Die Architektur

Die Android Keystore API und die zugrunde liegende Keymaster HAL bieten einen grundlegenden, aber ausreichenden Satz kryptografischer Primitiven, um die Implementierung von Protokollen mit zugriffsgesteuerten, hardwaregestützten Schlüsseln zu ermöglichen.

Die Keymaster HAL ist eine vom OEM bereitgestellte, dynamisch ladbare Bibliothek, die vom Keystore-Dienst verwendet wird, um hardwaregestützte kryptografische Dienste bereitzustellen. Um die Dinge sicher zu halten, führen HAL-Implementierungen keine sensiblen Operationen im Benutzerbereich oder sogar im Kernelbereich durch. Sensible Operationen werden an einen sicheren Prozessor delegiert, der über eine Kernel-Schnittstelle erreicht wird. Die resultierende Architektur sieht folgendermaßen aus:

Abbildung 1. Zugriff auf Keymaster

Innerhalb eines Android-Geräts besteht der „Client“ des Keymaster HAL aus mehreren Schichten (z. B. App, Framework, Keystore-Daemon), aber das kann für die Zwecke dieses Dokuments ignoriert werden. Das bedeutet, dass die beschriebene Keymaster-HAL-API Low-Level ist, von plattforminternen Komponenten verwendet wird und nicht App-Entwicklern ausgesetzt ist. Die übergeordnete API wird auf der Android-Entwickler-Website beschrieben.

Der Zweck der Keymaster-HAL besteht nicht darin, die sicherheitssensiblen Algorithmen zu implementieren, sondern lediglich Anforderungen an die sichere Welt zu ordnen und zu entpacken. Das Wire-Format ist implementierungsdefiniert.

Kompatibilität mit früheren Versionen

Der Keymaster 1 HAL ist vollständig inkompatibel mit den zuvor veröffentlichten HALs, zB Keymaster 0.2 und 0.3. Um die Interoperabilität auf Geräten mit Android 5.0 und früher zu erleichtern, die mit den älteren Keymaster-HALs gestartet wurden, stellt Keystore einen Adapter bereit, der die Keymaster 1-HAL mit Aufrufen an die vorhandene Hardwarebibliothek implementiert. Das Ergebnis kann nicht den vollen Funktionsumfang des Keymaster 1 HAL bieten. Insbesondere unterstützt es nur RSA- und ECDSA-Algorithmen, und die gesamte Durchsetzung der Schlüsselautorisierung wird vom Adapter in der nicht sicheren Welt durchgeführt.

Keymaster 2 vereinfachte die HAL-Schnittstelle weiter, indem es die get_supported_* Methoden entfernte und es der finish() Methode ermöglichte, Eingaben zu akzeptieren. Dies reduziert die Anzahl der Roundtrips zum TEE in Fällen, in denen die Eingabe auf einmal verfügbar ist, und vereinfacht die Implementierung der AEAD-Entschlüsselung.

In Android 8.0 wechselte Keymaster 3 von der alten C-Struktur-HAL zur C++-HAL-Schnittstelle, die aus einer Definition in der neuen Hardware Interface Definition Language (HIDL) generiert wurde. Eine neue HAL-Implementierung wird erstellt, indem die generierte IKeymasterDevice -Klasse in Unterklassen umgewandelt und die reinen virtuellen Methoden implementiert werden. Als Teil der Änderung haben sich viele der Argumenttypen geändert, obwohl Typen und Methoden eine Eins-zu-Eins-Entsprechung mit den alten Typen und den HAL-Strukturmethoden haben.

HIDL-Übersicht

Die Hardware Interface Definition Language (HIDL) stellt einen von der Implementierungssprache unabhängigen Mechanismus zum Spezifizieren von Hardwareschnittstellen bereit. Das HIDL-Tooling unterstützt derzeit die Generierung von C++- und Java-Schnittstellen. Es wird davon ausgegangen, dass die meisten Implementierer von Trusted Execution Environment (TEE) die C++-Tools bequemer finden werden, daher behandelt dieses Dokument nur die C++-Darstellung.

HIDL-Schnittstellen bestehen aus einer Reihe von Methoden, ausgedrückt als:

  methodName(INPUT ARGUMENTS) generates (RESULT ARGUMENTS);

Es gibt verschiedene vordefinierte Typen, und HALs können neue Aufzählungs- und Strukturtypen definieren. Weitere Einzelheiten zu HIDL finden Sie im Abschnitt „Referenz“ .

Eine Beispielmethode aus Keymaster 3 IKeymasterDevice.hal ist:

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

Dies ist das Äquivalent zu Folgendem aus dem 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);

In der HIDL-Version wird das dev -Argument entfernt, da es implizit ist. Das params Argument ist keine Struktur mehr, die einen Zeiger enthält, der auf ein Array von key_parameter_t Objekten verweist, sondern ein vec (Vektor), der KeyParameter Objekte enthält. Die Rückgabewerte sind in der Klausel „ generates “ aufgelistet, einschließlich eines Vektors von uint8_t Werten für das Schlüssel-Blob.

Die vom HIDL-Compiler generierte virtuelle C++-Methode lautet:

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

Wobei generateKey_cb ein Funktionszeiger ist, der wie folgt definiert ist:

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

Das heißt, generateKey_cb ist eine Funktion, die die in der generate-Klausel aufgelisteten Rückgabewerte annimmt. Die HAL-Implementierungsklasse überschreibt diese Methode generateKey und ruft den Zeiger der Funktion generateKey_cb auf, um das Ergebnis der Operation an den Aufrufer zurückzugeben. Beachten Sie, dass der Aufruf des Funktionszeigers synchron ist. Der Aufrufer ruft generateKey auf, und generateKey ruft den bereitgestellten Funktionszeiger auf, der bis zum Abschluss ausgeführt wird und die Steuerung an die generateKey -Implementierung zurückgibt, die dann an den Aufrufer zurückgibt.

Ein detailliertes Beispiel finden Sie in der Standardimplementierung in hardware/interfaces/keymaster/3.0/default/KeymasterDevice.cpp . Die Standardimplementierung bietet Abwärtskompatibilität für Geräte mit keymaster0-, keymaster1- oder keymaster2-HALS im alten Stil.

Zugangskontrolle

Die grundlegendste Regel der Keystore-Zugriffssteuerung ist, dass jede App ihren eigenen Namespace hat. Aber für jede Regel gibt es eine Ausnahme. Keystore verfügt über einige hartcodierte Zuordnungen, die es bestimmten Systemkomponenten ermöglichen, auf bestimmte andere Namespaces zuzugreifen. Dies ist ein sehr grobes Instrument, da es einer Komponente die volle Kontrolle über einen anderen Namensraum gibt. Und dann ist da noch die Frage der Herstellerkomponenten als Clients für Keystore. Wir haben derzeit keine Möglichkeit, einen Namensraum für Anbieterkomponenten einzurichten, z. B. WPA-Supplicant.

Um Anbieterkomponenten aufzunehmen und die Zugriffskontrolle ohne hartcodierte Ausnahmen zu verallgemeinern, führt Keystore 2.0 Domänen und SELinux-Namespaces ein.

Keystore-Domänen

Mit Keystore-Domains können wir Namespaces von UIDs entkoppeln. Clients, die auf einen Schlüssel in Keystore zugreifen, müssen die Domäne, den Namespace und den Alias ​​angeben, auf die sie zugreifen möchten. Anhand dieses Tupels und der Identität des Aufrufers können wir bestimmen, auf welchen Schlüssel der Aufrufer zugreifen möchte und ob er über die entsprechenden Berechtigungen verfügt.

Wir führen fünf Domänenparameter ein, die bestimmen, wie auf Schlüssel zugegriffen werden kann. Sie steuern die Semantik des Namensraumparameters des Schlüsseldeskriptors und wie die Zugriffskontrolle durchgeführt wird.

• DOMAIN_APP : Die App-Domäne deckt das Legacy-Verhalten ab. Das Java Keystore SPI verwendet diese Domäne standardmäßig. Bei Verwendung dieser Domain wird das Namespace-Argument ignoriert und stattdessen die UID des Aufrufers verwendet. Der Zugriff auf diese Domäne wird durch das Keystore-Label der Klasse keystore_key in der SELinux-Richtlinie gesteuert.
• DOMAIN_SELINUX : Diese Domäne gibt an, dass der Namespace eine Bezeichnung in der SELinux-Richtlinie hat. Der Namespace-Parameter wird gesucht und in einen Zielkontext übersetzt, und es wird eine Berechtigungsprüfung für den aufrufenden SELinux-Kontext für die keystore_key -Klasse durchgeführt. Wenn die Berechtigung für die gegebene Operation eingerichtet wurde, wird das vollständige Tupel für die Schlüsselsuche verwendet.
• DOMAIN_GRANT : Die Gewährungsdomäne gibt an, dass der Namespace-Parameter eine Gewährungskennung ist. Der Alias-Parameter wird ignoriert. SELinux-Prüfungen werden durchgeführt, wenn die Berechtigung erstellt wird. Eine weitere Zugriffskontrolle prüft nur, ob die Anrufer-UID mit der Berechtigungs-UID der angeforderten Bewilligung übereinstimmt.
• DOMAIN_KEY_ID : Diese Domäne gibt an, dass der Namespace-Parameter eine eindeutige Schlüssel-ID ist. Der Schlüssel selbst wurde möglicherweise mit DOMAIN_APP oder DOMAIN_SELINUX . Die Berechtigungsprüfung wird durchgeführt, nachdem die domain und der namespace aus der Schlüsseldatenbank geladen wurden, und zwar auf die gleiche Weise, als ob das Blob von der Domäne, dem Namespace und dem Alias-Tupel geladen wurde. Der Grund für die Schlüssel-ID-Domäne ist Kontinuität. Wenn auf einen Schlüssel per Alias ​​zugegriffen wird, können nachfolgende Aufrufe auf anderen Schlüsseln arbeiten, da ein neuer Schlüssel möglicherweise generiert oder importiert und an diesen Alias ​​gebunden wurde. Die Schlüssel-ID ändert sich jedoch nie. Wenn also ein Schlüssel nach Schlüssel-ID verwendet wird, nachdem er einmal mit dem Alias ​​aus der Keystore-Datenbank geladen wurde, kann man sicher sein, dass es sich um denselben Schlüssel handelt, solange die Schlüssel-ID noch existiert. Diese Funktionalität ist App-Entwicklern nicht zugänglich. Stattdessen wird es innerhalb des Android Keystore SPI verwendet, um ein konsistenteres Erlebnis zu bieten, selbst wenn es gleichzeitig auf unsichere Weise verwendet wird.
• DOMAIN_BLOB : Die Blobdomäne gibt an, dass der Aufrufer das Blob selbst verwaltet. Dies wird für Clients verwendet, die auf den Schlüsselspeicher zugreifen müssen, bevor die Datenpartition bereitgestellt wird. Der Schlüssel-Blob ist im blob -Feld des Schlüsseldeskriptors enthalten.

Mithilfe der SELinux-Domäne können wir Anbieterkomponenten Zugriff auf sehr spezifische Keystore-Namespaces gewähren, die von Systemkomponenten wie dem Einstellungsdialog gemeinsam genutzt werden können.

SELinux-Richtlinie für keystore_key

Namespace-Labels werden mithilfe der Datei keystore2_key_context konfiguriert.
Jede Zeile in diesen Dateien ordnet eine numerische Namespace-ID einem SELinux-Label zu. Zum Beispiel,

# 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

Nachdem wir auf diese Weise einen neuen Schlüsselnamensraum eingerichtet haben, können wir den Zugriff darauf gewähren, indem wir eine entsprechende Richtlinie hinzufügen. Um beispielsweise wpa_supplicant zu erlauben, Schlüssel im neuen Namespace zu erhalten und zu verwenden, würden wir die folgende Zeile zu hal_wifi_supplicant.te :

allow hal_wifi_supplicant wifi_key:keystore2_key { get, use };

Nach dem Einrichten des neuen Namensraums kann AndroidKeyStore fast wie gewohnt verwendet werden. Der einzige Unterschied besteht darin, dass die Namespace-ID angegeben werden muss. Zum Laden und Importieren von Schlüsseln aus und in Keystore wird die Namespace-ID mit AndroidKeyStoreLoadStoreParameter angegeben. Zum Beispiel,

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

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

Um einen Schlüssel in einem bestimmten Namespace zu generieren, muss die Namespace-ID mit KeyGenParameterSpec.Builder#setNamespace():

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

Die folgenden Kontextdateien können verwendet werden, um Keystore 2.0 SELinux-Namespaces zu konfigurieren. Jede Partition hat einen anderen reservierten Bereich von 10.000 Namespace-IDs, um Kollisionen zu vermeiden.

/system/etc/selinux/keystore2_key_contexts, /plat_keystore2_key_contexts

/system_ext/etc/selinux/system_ext_keystore2_key_contexts, /system_ext_keystore2_key_contexts

/product/etc/selinux/product_keystore2_key_contexts, /product_keystore2_key_contexts

/vendor/etc/selinux/vendor_keystore2_key_contexts, /vendor_keystore2_key_contexts

Der Client fordert den Schlüssel an, indem er die SELinux-Domäne und den gewünschten virtuellen Namensraum, in diesem Fall "wifi_key" , anhand seiner numerischen ID anfordert.

Darüber hinaus wurden die folgenden Namensräume definiert. Wenn sie Sonderregeln ersetzen, gibt die folgende Tabelle an, welcher UID sie früher entsprachen.

Greifen Sie auf Vektoren zu

Die SELinux-Klasse keystore_key ist ziemlich in die Jahre gekommen, und einige der Berechtigungen, wie z. B. verify oder sign haben ihre Bedeutung verloren. Hier ist der neue Satz von Berechtigungen, keystore2_key , die Keystore 2.0 erzwingen wird.

Darüber hinaus teilen wir eine Reihe von nicht schlüsselspezifischen Schlüsselspeicherberechtigungen in der SELinux-Sicherheitsklasse keystore2 auf: