Funktionen

Diese Seite enthält Informationen zu den kryptografischen Funktionen des Android Keystore, die von der zugrunde liegenden KeyMint- (oder Keymaster-)Implementierung bereitgestellt werden.

Kryptografische Primitive

Keystore bietet die folgenden Kategorien von Vorgängen:

  • Erstellen von Schlüsseln, was zu privaten oder geheimen Schlüsseln führt, auf die nur die sichere Umgebung zugreifen kann. Clients können Schlüssel auf folgende Arten erstellen:
    • Generierung eines neuen Schlüssels
    • Import von unverschlüsseltem Schlüsselmaterial
    • Import von verschlüsseltem Schlüsselmaterial
  • Schlüsselattestierung: Beim Erstellen eines asymmetrischen Schlüssels wird ein Zertifikat mit dem öffentlichen Schlüsselteil des Schlüsselpaars generiert. Dieses Zertifikat enthält optional auch Informationen zu den Metadaten für den Schlüssel und zum Status des Geräts, die alle durch eine Schlüsselverknüpfung zurück zu einer vertrauenswürdigen Wurzel signiert sind.
  • Kryptografische Vorgänge:
    • Symmetrische Verschlüsselung und Entschlüsselung (AES, 3DES)
    • Asymmetrische Entschlüsselung (RSA)
    • Asymmetrische Signatur (ECDSA, RSA)
    • Symmetrische Signatur und Bestätigung (HMAC)
    • Asymmetrische Schlüsselvereinbarung (ECDH)

Keystore und KeyMint unterstützen keine öffentlichen Schlüsselvorgänge für asymmetrische Schlüssel.

Protokollelemente wie Zweck, Modus und Padding sowie Zugriffssteuerungsbeschränkungen werden beim Generieren oder Importieren von Schlüsseln angegeben und dauerhaft an den Schlüssel gebunden, damit er nicht anderweitig verwendet werden kann.

Die Primitiven und Modi, die von der KeyMint-Implementierung unterstützt werden müssen, sind in der IKeyMintDevice-HAL-Schnittstellenspezifikation beschrieben.

Die zugrunde liegende KeyMint-Implementierung muss eine Zufallszahlengenerierung ausführen, um die Schlüsselgenerierung und das Erstellen von zufälligen Paddings oder Initialisierungsvektoren (IVs) zu unterstützen. Dazu stellt das Android-System der KeyMint-Implementierung regelmäßig zusätzliche Entropie zur Verfügung.

Schlüsselzugriffssteuerung

Hardwarebasierte Schlüssel, die niemals vom Gerät extrahiert werden können, bieten nicht viel Sicherheit, wenn ein Angreifer sie nach Belieben verwenden kann. Sie sind jedoch sicherer als Schlüssel, die exfiltriert werden können. Daher ist es wichtig, dass der Keystore Zugriffssteuerungen erzwingt.

Zugriffssteuerungen werden als „Autorisierungsliste“ von Tag/Wert-Paaren definiert. Autorisierungs-Tags sind 32-Bit-Ganzzahlen und die Werte können unterschiedliche Typen haben. Einige Tags können wiederholt werden, um mehrere Werte anzugeben. Ob ein Tag wiederholt werden kann, wird in der HAL-Schnittstelle von KeyMint (früher Keymaster) angegeben.

Die unterstützten Tag-Werte sind in der Datei Tag.aidl definiert. Jedem Wert ist ein TagType zugeordnet, der den Typ des zugehörigen Werts (z. B. Ganzzahl oder Byte) und angibt, ob er wiederholt werden kann, um mehrere unterstützte Werte anzugeben.

Wenn KeyMint einen Schlüssel erstellt, gibt der Aufrufer eine Autorisierungsliste für den Schlüssel an. Diese Liste wird von Keystore und KeyMint geändert, um zusätzliche Einschränkungen hinzuzufügen. Die zugrunde liegende KeyMint-Implementierung codiert die endgültige Autorisierungsliste in den zurückgegebenen Schlüssel-Blob. Die codierte Autorisierungsliste ist kryptografisch an den Key-Blob gebunden. Jeder Versuch, die Autorisierungsliste zu ändern (einschließlich der Reihenfolge), führt zu einem ungültigen Key-Blob, der nicht für kryptografische Vorgänge verwendet werden kann.

Hardware- und Software-Enforcement

Nicht alle sicheren Hardwareimplementierungen enthalten dieselben Funktionen. Um eine Vielzahl von Ansätzen zu unterstützen, unterscheidet KeyMint zwischen sicherer und nicht sicherer Zugriffssteuerung, bzw. zwischen Hardware- und Software-Durchsetzung.

In der KeyMint API wird dies mit dem Feld securityLevel vom Typ KeyCharacteristics bereitgestellt. Die sichere Hardware ist dafür verantwortlich, die Autorisierungen in KeyCharacteristics mit der entsprechenden Sicherheitsebene zu platzieren, je nachdem, was sie erzwingen kann. Diese Informationen sind auch in den Attestierungsdatensätzen für asymmetrische Schlüssel enthalten: Schlüsselmerkmale für SecurityLevel::TRUSTED_ENVIRONMENT oder SecurityLevel::STRONGBOX sind in der Liste hardwareEnforced aufgeführt und Merkmale für SecurityLevel::SOFTWARE oder SecurityLevel::KEYSTORE in der Liste softwareEnforced.

Einschränkungen für das Datums- und Zeitintervall, in dem ein Schlüssel verwendet werden kann, werden beispielsweise in der sicheren Umgebung in der Regel nicht erzwungen, da sie keinen zuverlässigen Zugriff auf Datums- und Zeitinformationen hat. Daher werden Autorisierungen wie Tag::ORIGINATION_EXPIRE_DATETIME von Keystore in Android erzwungen und haben SecurityLevel::KEYSTORE.

Weitere Informationen dazu, wie Sie feststellen, ob Schlüssel und ihre Autorisierungen hardwaregestützt sind, finden Sie unter Schlüsselattestierung.

Autorisierungen für die Erstellung kryptografischer Nachrichten

Mit den folgenden Tags werden die kryptografischen Eigenschaften von Vorgängen mit dem zugehörigen Schlüssel definiert:

  • Tag::ALGORITHM
  • Tag::KEY_SIZE
  • Tag::BLOCK_MODE
  • Tag::PADDING
  • Tag::CALLER_NONCE
  • Tag::DIGEST
  • Tag::MGF_DIGEST

Die folgenden Tags sind wiederholbar, d. h., einem einzelnen Schlüssel können mehrere Werte zugeordnet werden:

  • Tag::BLOCK_MODE
  • Tag::PADDING
  • Tag::DIGEST
  • Tag::MGF_DIGEST

Der zu verwendende Wert wird zum Zeitpunkt des Vorgangs angegeben.

Zweck

Schlüsseln sind mehrere Zwecke zugeordnet, die als ein oder mehrere Autorisierungseinträge mit dem Tag::PURPOSE-Tag ausgedrückt werden. Darin wird festgelegt, wie sie verwendet werden können. Die Zwecke sind in KeyPurpose.aidl definiert.

Beachten Sie, dass einige Kombinationen von Zweckwerten zu Sicherheitsproblemen führen können. Ein RSA-Schlüssel, der sowohl zum Verschlüsseln als auch zum Signieren verwendet werden kann, ermöglicht es einem Angreifer, das System dazu zu bringen, beliebige Daten zu entschlüsseln, um Signaturen zu generieren.

Schlüsselimport

KeyMint unterstützt den Import von:

  • Asymmetrische Schlüsselpaare im DER-codierten PKCS#8-Format (ohne passwortbasierte Verschlüsselung)
  • Symmetrische Schlüssel als Rohbytes

Damit importierte Schlüssel von sicher generierten Schlüsseln unterschieden werden können, ist Tag::ORIGIN in der entsprechenden Schlüsselautorisierungsliste enthalten. Wenn ein Schlüssel beispielsweise in sicherer Hardware generiert wurde, wird Tag::ORIGIN mit dem Wert KeyOrigin::GENERATED in der Liste hw_enforced der Schlüsselmerkmale gefunden. Ein Schlüssel, der in sichere Hardware importiert wurde, hat den Wert KeyOrigin::IMPORTED.

Nutzerauthentifizierung

Bei sicheren KeyMint-Implementierungen wird keine Nutzerauthentifizierung implementiert, sondern sie sind auf andere vertrauenswürdige Apps angewiesen, die dies tun. Die von diesen Apps implementierte Benutzeroberfläche finden Sie auf der Seite „Gatekeeper“.

Die Anforderungen an die Nutzerauthentifizierung werden über zwei Tag-Sets angegeben. Die erste Gruppe gibt an, für welche Authentifizierungsmethoden der Schlüssel verwendet werden kann:

  • Tag::USER_SECURE_ID ist ein 64‑Bit-Zahlenwert, der die sichere Nutzer-ID angibt, die in einem sicheren Authentifizierungstoken bereitgestellt wird, um die Verwendung des Schlüssels zu entsperren. Bei Wiederholung kann der Schlüssel verwendet werden, wenn einer der Werte in einem sicheren Authentifizierungstoken angegeben ist.

Der zweite Satz gibt an, ob und wann der Nutzer authentifiziert werden muss. Wenn keines dieser Tags vorhanden ist, aber Tag::USER_SECURE_ID, ist für jede Verwendung des Schlüssels eine Authentifizierung erforderlich.

  • Tag::NO_AUTHENTICATION_REQUIRED gibt an, dass keine Nutzerauthentifizierung erforderlich ist. Der Zugriff auf den Schlüssel ist jedoch weiterhin auf die App beschränkt, der er zugewiesen ist, und auf alle Apps, denen sie Zugriff gewährt.
  • Tag::AUTH_TIMEOUT ist ein numerischer Wert, der in Sekunden angibt, wie aktuell die Nutzerauthentifizierung sein muss, um die Schlüsselnutzung zu autorisieren. Zeitüberschreitungen gelten nicht für Neustarts. Nach einem Neustart werden alle Authentifizierungen ungültig. Die Zeitüberschreitung kann auf einen hohen Wert festgelegt werden, um anzugeben, dass die Authentifizierung einmal pro Start erforderlich ist (2^32 Sekunden entspricht etwa 136 Jahren; Android-Geräte werden vermutlich häufiger neu gestartet).

Entsperren des Geräts erforderlich machen

Schlüssel mit Tag::UNLOCKED_DEVICE_REQUIRED können nur verwendet werden, wenn das Gerät entsperrt ist. Die detaillierte Semantik finden Sie unter KeyProtection.Builder#setUnlockedDeviceRequired(boolean).

UNLOCKED_DEVICE_REQUIRED wird von Keystore und nicht von KeyMint erzwungen. Unter Android 12 und höher schützt der Keystore jedoch UNLOCKED_DEVICE_REQUIRED-Schlüssel kryptografisch, während das Gerät gesperrt ist, damit sie in den meisten Fällen nicht verwendet werden können, selbst wenn der Keystore manipuliert wird, während das Gerät gesperrt ist.

Dazu „superverschlüsselt“ der Keystore alle UNLOCKED_DEVICE_REQUIRED-Schlüssel, bevor er sie in seiner Datenbank speichert. Wenn möglich, werden die Superverschlüsselungsschlüssel (Superschlüssel) geschützt, während das Gerät so gesperrt ist, dass sie nur durch eine erfolgreiche Geräteentsperreung wiederhergestellt werden können. Der Begriff „Superverschlüsselung“ wird verwendet, weil diese Verschlüsselungsebene zusätzlich zur Verschlüsselungsebene angewendet wird, die KeyMint bereits auf alle Schlüssel anwendet.

Jeder Nutzer (einschließlich Profile) hat zwei Superschlüssel, die mit UNLOCKED_DEVICE_REQUIRED verknüpft sind:

  • Der symmetrische Superschlüssel „UnlockedDeviceRequired“. Dies ist ein AES‑256‑GCM-Schlüssel. Es verschlüsselt UNLOCKED_DEVICE_REQUIRED-Schlüssel, die importiert oder generiert werden, während das Gerät für den Nutzer entsperrt ist.
  • Der asymmetrische Superschlüssel „UnlockedDeviceRequired“. Dies ist ein ECDH-P‑521-Schlüsselpaar. Es verschlüsselt UNLOCKED_DEVICE_REQUIRED-Schlüssel, die importiert oder generiert werden, während das Gerät für den Nutzer gesperrt ist. Schlüssel, die mit diesem asymmetrischen Schlüssel verschlüsselt sind, werden bei der ersten Verwendung noch einmal mit dem symmetrischen Schlüssel verschlüsselt. Dies kann nur erfolgen, wenn das Gerät entsperrt ist.

Der Keystore generiert diese Superschlüssel beim Erstellen des Nutzers und speichert sie in seiner Datenbank, verschlüsselt mit dem synthetischen Passwort des Nutzers. So können sie mit einer PIN, einem Muster oder einem Passwort wiederhergestellt werden.

Der Keystore speichert diese Superschlüssel auch im Arbeitsspeicher, sodass er mit UNLOCKED_DEVICE_REQUIRED-Schlüsseln arbeiten kann. Die geheimen Teile dieser Schlüssel werden jedoch nur dann im Cache gespeichert, wenn das Gerät für den Nutzer entsperrt ist. Wenn das Gerät für den Nutzer gesperrt ist, setzt der Schlüsselspeicher die zwischengespeicherte Kopie der geheimen Teile dieser Superschlüssel nach Möglichkeit auf Null. Wenn das Gerät für den Nutzer gesperrt ist, wählt der Schlüsselspeicher eine von drei Schutzebenen für die Superschlüssel „UnlockedDeviceRequired“ des Nutzers aus und wendet sie an:

  • Wenn der Nutzer nur eine PIN, ein Muster oder ein Passwort aktiviert hat, setzt der Keystore die geheimen Teile der zwischengespeicherten Superschlüssel auf Null. Dadurch können die Superschlüssel nur über die verschlüsselte Kopie in der Datenbank wiederhergestellt werden, die nur mit einer PIN, einem Muster oder einem Passwort-Äquivalent entschlüsselt werden kann.
  • Wenn der Nutzer nur biometrische Verfahren der Klasse 3 („stark“) und eine PIN, ein Muster oder ein Passwort aktiviert hat, sorgt der Schlüsselspeicher dafür, dass die Superschlüssel mit einem der registrierten biometrischen Verfahren der Klasse 3 (in der Regel ein Fingerabdruck) des Nutzers wiederhergestellt werden können, als Alternative zu einer PIN, einem Muster oder einem Passwort. Dazu wird ein neuer AES‑256‑GCM-Schlüssel generiert, die geheimen Teile der Superschlüssel damit verschlüsselt, der AES‑256‑GCM-Schlüssel als biometrisch gebundener Schlüssel in KeyMint importiert und die Klartextkopien aller dieser Schlüssel auf Null gesetzt.
  • Wenn der Nutzer ein biometrisches Gerät der Klasse 1 („Komfort“) oder der Klasse 2 („schwach“) oder einen aktiven vertrauenswürdigen Entsperr-Agenten hat, speichert der Schlüsselspeicher die Superschlüssel im Klartext im Cache. In diesem Fall wird keine kryptografische Sicherheit für UNLOCKED_DEVICE_REQUIRED-Schlüssel bereitgestellt. Nutzer können diesen weniger sicheren Fallback vermeiden, indem sie diese Entsperrmethoden nicht aktivieren. Die gängigsten Entsperrmethoden, die in diese Kategorien fallen, sind die Gesichtserkennung auf vielen Geräten und die Entsperrung mit einer gekoppelten Smartwatch.

Wenn das Gerät für den Nutzer entsperrt ist, stellt der Schlüsselspeicher nach Möglichkeit die Superschlüssel „UnlockedDeviceRequired“ des Nutzers wieder her. Beim Entsperren mit PIN, Muster oder Passwort wird die in der Datenbank gespeicherte Kopie dieser Schlüssel entschlüsselt. Andernfalls wird geprüft, ob eine Kopie dieser Schlüssel mit einem biometrisch gebundenen Schlüssel gespeichert wurde. Falls ja, wird versucht, diese zu entschlüsseln. Dies ist nur möglich, wenn sich der Nutzer innerhalb der letzten 15 Sekunden mit einem biometrischen Verfahren der Klasse 3 authentifiziert hat, das von KeyMint (nicht Keystore) erzwungen wird.

Clientbindung

Die Clientbindung, also die Verknüpfung eines Schlüssels mit einer bestimmten Client-App, erfolgt über eine optionale Client-ID und einige optionale Clientdaten (Tag::APPLICATION_ID und Tag::APPLICATION_DATA). Der Keystore behandelt diese Werte als opake Blobs und sorgt nur dafür, dass bei jeder Verwendung dieselben Blobs wie bei der Schlüsselgenerierung/dem Schlüsselimport angezeigt werden und byteweise identisch sind. Die Clientbindungsdaten werden von KeyMint nicht zurückgegeben. Der Anrufer muss ihn kennen, um den Schlüssel verwenden zu können.

Diese Funktion ist für Apps nicht verfügbar.

Ablaufdatum

Der Keystore unterstützt die Einschränkung der Schlüsselnutzung nach Datum. Beginn und Ablauf der Gültigkeit eines Schlüssels können mit einem Schlüssel verknüpft werden. Der Keystore führt keine Schlüsselvorgänge aus, wenn das aktuelle Datum und die aktuelle Uhrzeit nicht innerhalb des gültigen Bereichs liegen. Der Gültigkeitsbereich des Schlüssels wird mit den Tags Tag::ACTIVE_DATETIME, Tag::ORIGINATION_EXPIRE_DATETIME und Tag::USAGE_EXPIRE_DATETIME angegeben. Die Unterscheidung zwischen „Herkunft“ und „Verwendung“ hängt davon ab, ob der Schlüssel verwendet wird, um einen neuen Geheimtext/eine neue Signatur usw. zu „erstellen“ oder einen vorhandenen Geheimtext/eine vorhandene Signatur usw. zu „verwenden“. Diese Unterscheidung ist für Apps nicht sichtbar.

Die Tags Tag::ACTIVE_DATETIME, Tag::ORIGINATION_EXPIRE_DATETIME und Tag::USAGE_EXPIRE_DATETIME sind optional. Wenn die Tags fehlen, wird davon ausgegangen, dass der betreffende Schlüssel immer zum Entschlüsseln/Überprüfen von Nachrichten verwendet werden kann.

Da die Zeitangaben von der nicht sicheren Umgebung bereitgestellt werden, sind die Tags für das Ablaufdatum in der Liste der softwaregestützten Tags enthalten.

Root of Trust-Bindung

Für den Keystore müssen Schlüssel an einen Root of Trust gebunden sein. Das ist ein Bitstring, der beim Start der sicheren KeyMint-Hardware bereitgestellt wird, vorzugsweise vom Bootloader. Dieser Bitstring ist kryptografisch an jeden von KeyMint verwalteten Schlüssel gebunden.

Die Vertrauensbasis besteht aus dem Hash des öffentlichen Schlüssels, mit dem die Signatur im Boot-Image und der Sperrstatus des Geräts überprüft werden. Wenn der öffentliche Schlüssel geändert wird, um die Verwendung eines anderen System-Images zu ermöglichen, oder wenn der Sperrstatus geändert wird, können keine der vom vorherigen System erstellten KeyMint-geschützten Schlüssel verwendet werden, es sei denn, die vorherige Root of Trust wird wiederhergestellt und ein System, das mit diesem Schlüssel signiert ist, wird gestartet. Ziel ist es, den Wert der softwaregestützten Zugriffssteuerung für Schlüssel zu erhöhen, indem es einem von einem Angreifer installierten Betriebssystem unmöglich gemacht wird, KeyMint-Schlüssel zu verwenden.

Zufallszahlengenerator neu initialisieren

Da sichere Hardware Zufallszahlen für Schlüsselmaterial und Initialisierungsvektoren (IVs) generiert und Hardware-Zufallszahlengeneratoren nicht immer vollständig vertrauenswürdig sind, bietet die KeyMint HAL eine Schnittstelle, über die der Keystore zusätzliche Entropie bereitstellen kann, die in die generierten Zufallszahlen einfließt.

Verwenden Sie einen Hardware-Zufallszahlengenerator als primäre Seed-Quelle. Die über die externe API bereitgestellten Startdaten dürfen nicht die einzige Quelle für Zufälligkeit bei der Generierung von Zahlen sein. Außerdem muss der verwendete Mischvorgang dafür sorgen, dass die Zufallsausgabe unvorhersehbar ist, wenn eine der Startquellen unvorhersehbar ist.