Hardwarebasierter Schlüsselspeicher

Verfügbarkeit einer vertrauenswürdigen Ausführungsumgebung in einem System-on-Chip (SoC) bietet Android-Geräten die Möglichkeit, hardwaregestützte, für das Android-Betriebssystem, Plattformdienste und sogar Drittanbieter-Apps. Entwickler, die nach Android-spezifischen Erweiterungen suchen, sollten auf android.security.keystore.

Vor Android 6.0 hatte Android bereits eine einfache, hardwaregestützte Kryptowährung Services API, bereitgestellt von den Versionen 0.2 und 0.3 der Keymaster Hardware Abstraktionsschicht (HAL). Von Schlüsselspeicher bereitgestellte digitale Signatur und Verifizierung sowie Generierung und Import asymmetrischer Signaturschlüsselpaare. Dies ist die auf vielen Geräten implementiert sind, aber es gibt viele Sicherheitsziele, lässt sich nicht allein mit einem Signatur-API erreichen. Schlüsselspeicher in Android 6.0 haben die Keystore API erweitert, um eine breitere Palette von Funktionen bereitzustellen.

In Android 6.0 wurde Keystore symmetrische kryptografische Primitive AES und HMAC sowie ein Zugriffssteuerungssystem für hardwaregestützte Schlüssel. Zugriff Steuerelemente werden während der Schlüsselgenerierung angegeben und für die Lebensdauer von den Schlüssel. Schlüssel können so eingeschränkt werden, dass sie nur verwendet werden können, wenn der Nutzer nur für bestimmte Zwecke oder mit spezifizierten kryptografischen Parameter. Weitere Informationen finden Sie in der Autorisierungs-Tags und Funktionen.

Neben der Erweiterung der Bandbreite an kryptografischen Primitiven bietet Keystore in Android 6.0 hat Folgendes hinzugefügt:

• Ein Nutzungskontrollschema, um die Schlüsselnutzung zu begrenzen und Risiko eines Sicherheitsrisikos durch Schlüsselmissbrauch
• Ein Zugriffskontrollschema, um die Beschränkung von Schlüsseln auf bestimmte Nutzer zu ermöglichen, und einem definierten Zeitraum

In Android 7.0 bietet Keymaster 2 nun Unterstützung für Schlüsselattestierung und -version. Bindung. Schlüsselattestierung stellt Public-Key-Zertifikate bereit, die eine detaillierte Beschreibung des Schlüssels enthalten und seiner Zugriffskontrollen, um die Existenz des Schlüssels auf sicherer Hardware und seiner Konfiguration remote überprüfbar.

Versionsbindung Bindet Schlüssel an das Betriebssystem und die Patchversion. Dadurch wird sichergestellt, ein Angreifer, der eine Schwachstelle in einer alten Version des Systems oder Die TEE-Software kann das Gerät nicht auf die anfällige Version zurücksetzen und keine Schlüssel verwenden die mit der neueren Version erstellt wurden. Wenn ein Schlüssel mit einer bestimmten Version und der Patch-Level auf einem Gerät verwendet wird, das auf eine neuere Version aktualisiert wurde. Patch- oder Patchebene wird der Schlüssel aktualisiert, bevor er verwendet werden kann, und die vorherige Version Version des Schlüssels ungültig gemacht. Wenn das Gerät aktualisiert wird, werden die Tasten mit dem Gerät vorwärts, aber bei jedem Umkehren lassen die Tasten unbrauchbar.

In Android 8.0 wurde Keymaster 3 von der alten C-Struktur-Hardware umgestellt. Abstraktionsschicht (Abstraktionsschicht, HAL) zur C++ HAL-Schnittstelle, die von einer Definition generiert wurde in der neuen Hardware Interface Definition Language (HIDL) verfügbar. Im Rahmen dieser Änderung Viele der Argumenttypen haben sich geändert, obwohl Typen und Methoden jeweils nur eine 1:1-Beziehung haben. Korrespondenz mit den alten Typen und den HAL-Struktur-Methoden. Weitere Informationen finden Sie in der Funktionen. Details.

Zusätzlich zu dieser Überarbeitung der Benutzeroberfläche wurde die zu unterstützendes Attestierungsfeature ID-Attestierung. Die ID-Attestierung bietet einen eingeschränkten und optionalen Mechanismus für starke Attestierungen auf Hardware-IDs wie die Seriennummer des Geräts, den Produktnamen oder die Telefonnummer ID (IMEI / MEID). Um diese Ergänzung zu implementieren, wurde in Android 8.0 die ASN.1 geändert. Attestierungsschema, um eine ID-Attestierung hinzuzufügen. Keymaster-Implementierungen müssen die relevanten Datenelemente sicher abrufen und einen Mechanismus zur sicheren und dauerhaften Deaktivierung der Funktion.

Android 9 umfasste folgende Updates:

• Aktualisieren auf Keymaster 4
• Unterstützung für eingebettete Secure Elements
• Unterstützung für den Import sicherer Schlüssel
• Unterstützung für 3DES-Verschlüsselung
• Änderungen an der Versionsbindung, sodass für boot.img und system.img Folgendes gilt: Versionen separat festlegen, um unabhängige Updates zu ermöglichen

Glossar

Hier erhalten Sie einen kurzen Überblick über die Schlüsselspeicherkomponenten und ihre Beziehungen.

AndroidKeystore ist die Android Framework API und die verwendete Komponente. um auf die Schlüsselspeicherfunktionen zuzugreifen. Sie ist als Erweiterung der standardmäßigen Java Cryptography Architecture APIs und besteht aus Java-Code, der im eigenen Prozessbereich der App ausgeführt. AndroidKeystore erfüllt die App für das Verhalten des Schlüsselspeichers, indem sie an den Schlüsselspeicher-Daemon weitergeleitet werden.

Der Schlüsselspeicher-Daemon ist ein Android-System-Daemon, der Zugriff auf alle Schlüsselspeicherfunktionen über eine Binder API. Er ist für die Speicherung von Schlüssel-BLOBs zuständig, das eigentliche geheime Schlüsselmaterial enthalten, verschlüsselt, damit der Schlüsselspeicher sie speichern kann, nicht verwenden oder offenlegen.

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

Keymaster TA (vertrauenswürdige Anwendung) ist die Software, die in einer in TrustZone auf einem ARM-SoC, das alle sichere Schlüsselspeichervorgänge, hat Zugriff auf das Rohschlüsselmaterial, validiert alle Bedingungen für die Zugriffssteuerung auf Tasten usw.

LockSettingsService ist die Android-Systemkomponente, für die Nutzerauthentifizierung (Passwort und Fingerabdruck). Es gehört nicht zu Schlüsselspeicher, der aber relevant ist, da viele Schlüsselspeicher-Schlüsselvorgänge Nutzer Authentifizierung. LockSettingsService interagiert mit dem Gatekeeper TA und Fingerprint TA, um Authentifizierungs-Tokens zu erhalten, die sie dem Schlüsselspeicher-Daemon, der letztendlich vom Keymaster TA verbraucht wird. .

Gatekeeper TA (vertrauenswürdige Anwendung) ist eine weitere Komponente im sicheren Kontext ausgeführt, die für die Authentifizierung des Nutzers Passwörter und Generieren von Authentifizierungstokens zur Bestätigung gegenüber dem Keymaster TA dass eine Authentifizierung für einen bestimmten Nutzer zu einem bestimmten Zeitpunkt im .

Fingerprint TA (vertrauenswürdige Anwendung) ist eine weitere Komponente im sicheren Kontext ausgeführt, der für die Authentifizierung des Nutzers Fingerabdrücke generieren und Authentifizierungstokens generieren, die als Nachweis gegenüber dem Keymaster verwendet werden. TA, dass eine Authentifizierung für einen bestimmten Nutzer zu einem bestimmten Zeitpunkt durchgeführt wurde mit der Zeit kommen.

Architektur

Die Android Keystore API und der zugrunde liegende Keymaster HAL grundlegende, aber ausreichende kryptografische Primitive bereitstellen, Implementierung von Protokollen mit zugriffsgesteuerten, hardwaregestützten Schlüsseln.

Der Keymaster HAL ist eine vom OEM bereitgestellte, dynamisch ladbare Bibliothek, die von Schlüsselspeicherdienst zur Bereitstellung hardwaregestützter kryptografischer Dienste. Beibehalten sicher sind, führen HAL-Implementierungen keine sensiblen Vorgänge in User-Space oder sogar im Kernel-Bereich. Sensible Vorgänge werden an eine sicheren Prozessor, der über eine Kernel-Schnittstelle erreicht wird. Die resultierende Architektur sieht so aus:

Abbildung 1: Zugriff auf Keymaster

Auf einem Android-Gerät ist der „Client“ des Keymaster HAL besteht aus mehrere Schichten (z. B. App, Framework, Keystore-Daemon), die aber ignoriert werden können. für die Zwecke dieses Dokuments. Das bedeutet, dass der beschriebene Keymaster HAL API ist auf niedriger Ebene, wird von plattforminternen Komponenten verwendet und ist nicht für die App zugänglich zu entwickeln. Die übergeordnete API wird auf der Website für Android-Entwickler beschrieben.

Der Zweck des Keymaster HAL besteht nicht darin, die sicherheitsrelevante sondern nur um Anfragen in der sicheren Welt zusammenzuführen und zu verarbeiten. Die Das Überweisungsformat ist implementierungsdefiniert.

Kompatibilität mit vorherigen Versionen

Der Keymaster 1 HAL ist nicht kompatibel mit dem zuvor veröffentlichte HALs, z.B. Keymaster 0.2 und 0.3. Um die Interoperabilität auf Geräten mit Android 5.0 und niedriger, älteren Keymaster HALs bietet Keystore einen Adapter, mit dem die Keymaster 1 HAL mit Aufrufen der vorhandenen Hardwarebibliothek. Das Ergebnis darf nicht bieten alle Funktionen von Keymaster 1 HAL. Insbesondere Es unterstützt nur RSA- und ECDSA-Algorithmen sowie alle wird vom Adapter in einer unsicheren Umgebung erzwungen.

Keymaster 2 vereinfachte die HAL-Schnittstelle weiter, indem die Funktion get_supported_*-Methoden und zulassen, dass finish() , um die Eingabe zu akzeptieren. Dies reduziert die Anzahl der Umläufe zum TEE in in denen alle Eingaben auf einmal zur Verfügung stehen, und vereinfacht die AEAD-Entschlüsselung.

In Android 8.0 ist Keymaster 3 von der alten C-Struktur übergegangen. HAL in die C++ HAL-Schnittstelle ein, die aus einer Definition im neuen Hardware Interface Definition Language (HIDL) Ein HAL im neuen Stil -Implementierung erstellt, indem eine Unterklasse der generierten IKeymasterDevice und die Implementierung der rein virtuellen . Im Rahmen dieser Änderung haben sich viele Argumenttypen geändert. Obwohl Typen und Methoden eine Eins-zu-Eins-Übereinstimmung mit den alten und die HAL-Struktur-Methoden.

HIDL – Übersicht

Die Hardware Interface Definition Language (HIDL) bietet eine sprachunabhängigen Mechanismus zur Angabe von Hardwareschnittstellen. Das HIDL unterstützen derzeit die Generierung von C++- und Java-Schnittstellen. Erwartungsgemäß dass die meisten TEE-Implementierungen die C++- . Deshalb wird in diesem Dokument nur die C++-Darstellung behandelt.

HIDL-Schnittstellen bestehen aus einer Reihe von Methoden, die folgendermaßen ausgedrückt werden:

  methodName(INPUT ARGUMENTS) generates (RESULT ARGUMENTS);

Es gibt verschiedene vordefinierte Typen und HALs können neue Strukturtypen. Weitere Informationen zum HIDL finden Sie im Abschnitt „Referenzen“.

Eine Beispielmethode der IKeymasterDevice.hal von Keymaster 3 ist:

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

Dies entspricht dem folgenden String 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 Argument dev entfernt, da es implizit. Das Argument params ist keine Struktur mit einem Zeiger, der auf ein Array von key_parameter_t-Objekten verweist, aber ein vec (Vektor) mit KeyParameter Objekten. Die Rückgabewerte sind in der Spalte "generates" Klausel, einschließlich einer Vektor der uint8_t-Werte 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;

Dabei ist generateKey_cb ein Funktionszeiger, der so 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 Rückgabewerte in der Generate-Klausel aufgelistet. Die HAL-Implementierungsklasse überschreibt dies Methode generateKey und ruft die Funktion generateKey_cb auf Zeiger, um das Ergebnis des Vorgangs an den Aufrufer zurückzugeben. Beachten Sie die Funktion Der Zeigeraufruf erfolgt synchron. Der Anrufer ruft an generateKey und generateKey rufen die bereitgestellten Funktionszeiger, der bis zum Ende ausgeführt wird und die Steuerung an den generateKey-Implementierung, die dann an den Aufrufer zurückgegeben wird.

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.

Zugriffssteuerung

Die einfachste Regel der Schlüsselspeicher-Zugriffssteuerung besagt, dass jede Anwendung eigenen Namespace. Aber für jede Regel gibt es eine Ausnahme. Schlüsselspeicher enthält einige hartcodierten Karten, die es bestimmten Systemkomponenten ermöglichen, auf bestimmte andere Namespaces. Das ist ein sehr stumpfes Instrument, da es einer Komponente uneingeschränkte Kontrolle über einen anderen Namespace. Dann ist die Frage des Anbieters, als Clients für Keystore. Derzeit gibt es keine Möglichkeit, Namespace für Anbieterkomponenten, z. B. WPA supplicant.

Um Anbieterkomponenten zu berücksichtigen und die Zugriffssteuerung zu verallgemeinern Ohne hartcodierte Ausnahmen bietet Keystore 2.0 Domains und SELinux Namespaces.

Schlüsselspeicher-Domains

Mit Schlüsselspeicher-Domains können Namespaces von UIDs entkoppelt werden. Kunden Für den Zugriff auf einen Schlüssel im Schlüsselspeicher müssen die Domain, der Namespace und der Alias angegeben werden. auf die sie zugreifen möchten. Anhand dieses Tupels und der Identität des Aufrufers kann feststellen, auf welche Taste der Anrufer zugreifen möchte und ob er Berechtigungen.

Wir führen fünf Domainparameter ein, die steuern, wie auf Schlüssel zugegriffen werden kann. Sie steuern die Semantik des Namespace-Parameters des Schlüsseldeskriptors und wie die Zugriffssteuerung durchgeführt wird.

• DOMAIN_APP: Die App-Domain deckt die auf das alte Verhalten. Das Java Keystore SPI verwendet diese Domain standardmäßig. Wenn diese Domain verwendet wird, wird das Namespace-Argument ignoriert und die UID des Aufrufers lautet verwendet werden. Der Zugriff auf diese Domain wird über das Schlüsselspeicherlabel für den Klasse keystore_key in der SELinux-Richtlinie.
• DOMAIN_SELINUX: Diese Domain gibt an, dass die Namespace hat ein Label in der SELinux-Richtlinie. Der Namespace-Parameter wird und in einen Zielkontext übertragen, und es wird eine Berechtigungsprüfung für den aufrufenden SELinux-Kontext für die keystore_key-Klasse. Wenn der Parameter Berechtigung für den gegebenen Vorgang eingerichtet wurde, wird das vollständige Tupel verwendet. für die Schlüsselsuche aus.
• DOMAIN_GRANT: Die Gewährungsdomain gibt an, dass Der Namespace-Parameter ist eine Berechtigungskennung. Der Alias-Parameter wird ignoriert. SELinux-Prüfungen werden durchgeführt, wenn die Erteilung erstellt wird. Weitere Zugriffssteuerung Prüft nur, ob die Aufrufer-UID mit der UID des Empfängers der angeforderten Erteilung übereinstimmt.
• DOMAIN_KEY_ID: Diese Domain gibt an, dass die Namespace-Parameter ist eine eindeutige Schlüssel-ID. Der Schlüssel selbst wurde möglicherweise erstellt. mit DOMAIN_APP oder DOMAIN_SELINUX. Die Berechtigung Die Prüfung wird nach domain und namespace durchgeführt aus der Schlüsseldatenbank geladen werden, genauso wie beim Laden des Blobs. durch das Tupel „Domain“, „Namespace“ und „Alias“. Die Begründung für die Schlüssel-ID-Domain ist Kontinuität. Beim Zugriff auf einen Schlüssel über Alias können nachfolgende Aufrufe auf verschiedene Schlüssel, da möglicherweise ein neuer Schlüssel generiert oder importiert und gebunden wurde an diesen Alias. Die Schlüssel-ID ändert sich jedoch nie. Wenn Sie also einen Schlüssel nach Schlüssel-ID verwenden, nachdem er aus der Schlüsselspeicher-Datenbank einmal mit dem Alias geladen wurde, kann sicher sein, dass es sich um denselben Schlüssel handelt, solange die Schlüssel-ID noch existiert. Dieses nicht den App-Entwicklern zugänglich gemacht wird. Stattdessen wird es im Android Keystore SPI, um eine einheitlichere User Experience zu bieten, selbst wenn sie verwendet wird auf unsichere Weise erfolgen.
• DOMAIN_BLOB: Die Blob-Domain gibt an, dass verwaltet der Aufrufer das Blob selbst. Dieser wird für Clients verwendet, die bevor die Datenpartition bereitgestellt wird. Das Schlüssel-BLOB ist im Feld blob des Schlüsseldeskriptors enthalten.

Über die SELinux-Domain können wir Anbieterkomponenten bestimmte Schlüsselspeicher-Namespaces, die von Systemkomponenten wie das Dialogfeld mit den Einstellungen.

SELinux-Richtlinie für keystore_key

Namespace-Labels werden mithilfe der keystore2_key_context -Datei.
Jede Zeile in diesen Dateien ordnet eine numerische Namespace-ID einem SELinux-Label zu. 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 Sie einen neuen Schlüssel-Namespace auf diese Weise eingerichtet haben, können wir Zugriff darauf gewähren indem Sie eine entsprechende Richtlinie hinzufügen. Um beispielsweise wpa_supplicant zum Abrufen und Verwenden von Schlüsseln im neuen Namespace. fügen Sie die folgende Zeile zu hal_wifi_supplicant.te hinzu:

allow hal_wifi_supplicant wifi_key:keystore2_key { get, use };

Nach der Einrichtung des neuen Namespace kann AndroidKeyStore fast als Üblicherweise. Der einzige Unterschied besteht darin, dass die Namespace-ID angegeben werden muss. Für Beim Laden und Importieren von Schlüsseln aus dem und in den Schlüsselspeicher wird die Namespace-ID angegeben. mit AndroidKeyStoreLoadStoreParameter. Beispiel:

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

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

Zum Generieren eines Schlüssels in einem bestimmten Namespace muss die Namespace-ID angegeben werden mit KeyGenParameterSpec.Builder#setNamespace():

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

Die folgenden Kontextdateien können zur Konfiguration von Keystore 2.0 SELinux verwendet werden. Namespaces. Jede Partition hat einen anderen reservierten Bereich von 10.000 Namespaces IDs, um Konflikte 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-Domain und die gewünschte virtuellen Namespace, in diesem Fall "wifi_key", durch seine numerische ID.

Darüber wurden die folgenden Namespaces definiert. Wenn sie Regeln gelten, wird in der folgenden Tabelle die UID angegeben, an.

Auf Vektoren zugreifen

Die SELinux-Klasse keystore_key ist in die Jahre gekommen und einige die Berechtigungen wie verify oder sign verloren gegangen sind deren Bedeutung. Hier sind die neuen Berechtigungen: keystore2_key den Keystore 2.0 durchsetzt.

Außerdem haben wir eine Reihe von nicht schlüsselspezifischen Schlüsselspeicherberechtigungen die SELinux-Sicherheitsklasse keystore2: