Google setzt sich dafür ein, die Rassengerechtigkeit für schwarze Gemeinschaften zu fördern. Siehe wie.
Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

Hardware-gestützter Keystore

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

Vor Android 6.0 verfügte Android bereits über eine einfache, hardwareunterstützte Kryptodienst-API, die von den Versionen 0.2 und 0.3 des Keymaster Hardware Abstraction Layer (HAL) bereitgestellt wurde. Keystore lieferte digitale Signatur- und Verifizierungsvorgänge sowie die Generierung und den Import von Schlüsselpaaren für asymmetrische Signaturen. Dies ist bereits auf vielen Geräten implementiert, aber es gibt viele Sicherheitsziele, die mit einer Signatur-API nicht einfach erreicht werden können. Keystore in Android 6.0 erweitert die Keystore-API um ein breiteres Spektrum an Funktionen.

In Android 6.0 fügte Keystore symmetrische kryptografische Grundelemente, AES und HMAC sowie ein Zugriffskontrollsystem für hardwaregestützte Schlüssel hinzu. Zugriffskontrollen werden während der Schlüsselgenerierung angegeben und für die Lebensdauer des Schlüssels erzwungen. Die Verwendung von Schlüsseln kann eingeschränkt werden, nachdem der Benutzer sich authentifiziert hat, und nur für bestimmte Zwecke oder mit bestimmten kryptografischen Parametern. Weitere Informationen finden Sie auf den Seiten Autorisierungs-Tags und -Funktionen .

Keystore in Android 6.0 erweitert nicht nur den Bereich der kryptografischen Grundelemente, sondern fügt auch Folgendes hinzu:

  • Ein Nutzungskontrollschema, mit dem die Verwendung von Schlüsseln eingeschränkt werden kann, um das Risiko von Sicherheitsrisiken aufgrund von Schlüsselmissbrauch zu verringern
  • Ein Zugriffssteuerungsschema, mit dem Schlüssel auf bestimmte Benutzer, Clients und einen definierten Zeitraum beschränkt werden können

In Android 7.0 hat Keymaster 2 Unterstützung für die Schlüsselbescheinigung und Versionsbindung hinzugefügt. Die Schlüsselbescheinigung bietet Zertifikate für öffentliche Schlüssel, 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 die Schlüssel an das Betriebssystem und die Version auf Patch-Ebene. 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 anfällige Version zurücksetzen und mit der neueren Version erstellte Schlüssel verwenden kann. Wenn ein Schlüssel mit einer bestimmten Version und Patch-Ebene auf einem Gerät verwendet wird, das auf eine neuere Version oder Patch-Ebene aktualisiert wurde, wird der Schlüssel aktualisiert, bevor er verwendet werden kann, und die vorherige Version des Schlüssels wird ungültig. Während das Gerät aktualisiert wird, "ratschen" die Schlüssel zusammen mit dem Gerät weiter, aber jede Umkehrung des Geräts zu einer früheren Version führt dazu, dass die Schlüssel unbrauchbar werden.

In Android 8.0 wechselte Keymaster 3 von der alten C-Struktur-Hardware-Abstraktionsschicht (HAL) zur C ++ - HAL-Schnittstelle, die aus einer Definition in der neuen Hardware-Schnittstellendefinitionssprache (HIDL) generiert wurde. Im Rahmen der Änderung haben sich viele der Argumenttypen geändert, obwohl Typen und Methoden eine Eins-zu-Eins-Entsprechung zu den alten Typen und den HAL-Strukturmethoden aufweisen. Weitere Informationen finden Sie auf der Seite Funktionen .

Zusätzlich zu dieser Überarbeitung der Benutzeroberfläche erweitert Android 8.0 die Bestätigungsfunktion von Keymaster 2, um die ID-Bestätigung zu unterstützen. Die ID-Bescheinigung bietet einen eingeschränkten und optionalen Mechanismus zur eindeutigen Bestätigung von Hardware-IDs wie der Seriennummer des Geräts, dem Produktnamen und der Telefon-ID (IMEI / MEID). Um diesen Zusatz zu implementieren, ändern Sie das ASN.1-Attestierungsschema, um eine ID-Attestierung hinzuzufügen. Keymaster-Implementierungen müssen einen sicheren Weg finden, um die relevanten Datenelemente abzurufen, und einen Mechanismus zum sicheren und dauerhaften Deaktivieren der Funktion definieren.

In Android 9 umfassen die Updates:

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

Glossar

Hier finden Sie eine kurze Übersicht über Keystore-Komponenten und ihre Beziehungen.

AndroidKeystore ist die Android Framework-API und -Komponente, mit der Apps auf die Keystore-Funktionalität zugreifen. Es ist als Erweiterung der Standard-APIs für Java Cryptography Architecture 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 "Key Blobs", die das eigentliche geheime Schlüsselmaterial enthalten, verschlüsselt, damit Keystore es 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. Sie bietet alle sicheren Keystore-Vorgänge, hat Zugriff auf das Rohmaterial und validiert alle Zugriffssteuerungsbedingungen für Schlüssel , etc.

LockSettingsService ist die Android-Systemkomponente, die für die Benutzerauthentifizierung sowohl für das Kennwort als auch für den 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 Fingerprint TA, um Authentifizierungstoken zu erhalten, die es dem Keystore-Daemon zur Verfügung stellt und die letztendlich von der Keymaster TA-Anwendung verwendet werden.

Gatekeeper TA (vertrauenswürdige Anwendung) ist eine weitere Komponente, die im sicheren Kontext ausgeführt wird. Sie ist für die Authentifizierung von Benutzerkennwörtern und die Generierung von Authentifizierungstoken verantwortlich, mit denen dem Keymaster TA nachgewiesen wird, dass zu einem bestimmten Zeitpunkt eine Authentifizierung für einen bestimmten Benutzer durchgeführt wurde.

Fingerprint TA (vertrauenswürdige Anwendung) 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, mit denen dem Keymaster TA nachgewiesen wird, dass zu einem bestimmten Zeitpunkt eine Authentifizierung für einen bestimmten Benutzer durchgeführt wurde.

Die Architektur

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

Der Keymaster HAL ist eine vom OEM bereitgestellte, dynamisch ladbare Bibliothek, die vom Keystore-Dienst zur Bereitstellung hardwarebasierter kryptografischer Dienste verwendet wird. Um die Sicherheit zu gewährleisten, führen HAL-Implementierungen keine vertraulichen Vorgänge im Benutzerbereich oder sogar im Kernelbereich aus. Sensible Vorgänge werden an einen sicheren Prozessor delegiert, der über eine Kernelschnittstelle erreicht wird. Die resultierende Architektur sieht folgendermaßen aus:

Zugriff auf Keymaster

Abbildung 1. Zugriff auf Keymaster

Innerhalb eines Android-Geräts besteht der "Client" des Keymaster HAL aus mehreren Ebenen (z. B. App, Framework, Keystore-Daemon), die jedoch für die Zwecke dieses Dokuments ignoriert werden können. Dies bedeutet, dass die beschriebene Keymaster HAL-API auf niedriger Ebene ausgeführt wird, von plattforminternen Komponenten verwendet wird und nicht für App-Entwickler verfügbar ist. Die übergeordnete API wird auf der Android Developer-Website beschrieben .

Der Zweck des Keymaster HAL besteht nicht darin, die sicherheitsrelevanten Algorithmen zu implementieren, sondern nur Anforderungen an die sichere Welt zu marshallen und zu marshallen. Das Drahtformat ist implementierungsdefiniert.

Kompatibilität mit früheren Versionen

Der Keymaster 1 HAL ist vollständig inkompatibel mit den zuvor veröffentlichten HALs, z. B. Keymaster 0.2 und 0.3. Um die Interoperabilität auf Geräten mit Android 5.0 und früheren Versionen zu erleichtern, die mit den älteren Keymaster HALs gestartet wurden, bietet Keystore einen Adapter, der den Keymaster 1 HAL mit Aufrufen der vorhandenen Hardwarebibliothek implementiert. Das Ergebnis kann im Keymaster 1 HAL nicht den gesamten Funktionsumfang bieten. Insbesondere werden nur RSA- und ECDSA-Algorithmen unterstützt, und die gesamte Durchsetzung der Schlüsselautorisierung wird in der nicht sicheren Welt vom Adapter ausgeführt.

Keymaster 2 hat die HAL-Schnittstelle weiter vereinfacht, indem die Methoden get_supported_* und die Methode finish() Eingaben akzeptiert hat. 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 C-Struktur-HAL im alten Stil zur C ++ HAL-Schnittstelle, die aus einer Definition in der neuen Hardware Interface Definition Language (HIDL) generiert wurde. Eine HAL-Implementierung neuen Stils wird erstellt, indem die generierte IKeymasterDevice Klasse in Unterklassen IKeymasterDevice und die rein virtuellen Methoden implementiert werden. Im Rahmen der Änderung haben sich viele der Argumenttypen geändert, obwohl Typen und Methoden eine Eins-zu-Eins-Entsprechung zu den alten Typen und den HAL-Strukturmethoden aufweisen.

HIDL-Übersicht

Die Hardware Interface Definition Language (HIDL) bietet einen implementierungssprachunabhängigen Mechanismus zum Festlegen von Hardwareschnittstellen. Das HIDL-Tool unterstützt derzeit die Generierung von C ++ - und Java-Schnittstellen. Es wird erwartet, dass die meisten TEE-Implementierer (Trusted Execution Environment) das C ++ - Tool bequemer finden. In diesem Dokument wird daher nur die C ++ - Darstellung erläutert.

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 Informationen 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 entspricht dem folgenden Ergebnis von 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 Argument params ist keine Struktur mehr, die einen Zeiger enthält, der auf ein Array von key_parameter_t Objekten key_parameter_t , sondern ein vec (Vektor), der KeyParameter Objekte enthält. Die Rückgabewerte sind in der Klausel " generates " aufgeführt, einschließlich eines Vektors von uint8_t Werten für den Key-Blob.

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

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

Wobei generate_cb ein Funktionszeiger ist, der definiert ist als:

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

Das heißt, generate_cb ist eine Funktion, die die in der generate-Klausel aufgeführten Rückgabewerte verwendet. Die HAL-Implementierungsklasse überschreibt diese generateKey Methode und ruft den Funktionszeiger generate_cb auf, um das Ergebnis der Operation an den Aufrufer zurückzugeben. Beachten Sie, dass der Funktionszeigeraufruf synchron ist . Der Aufrufer ruft generateKey und generateKey ruft den angegebenen Funktionszeiger auf, der vollständig ausgeführt wird, und gibt die Steuerung an die generateKey Implementierung zurück, die dann an den Aufrufer zurückkehrt.

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.