Funktionen

Diese Seite enthält Informationen zu den kryptografischen Funktionen des Keystore in Android 6.0 und höher.

Kryptografische Primitive

Keystore bietet die folgenden Kategorien von Vorgängen:

  • Schlüsselgenerierung
  • Import und Export asymmetrischer Schlüssel (kein Schlüsselverpacken)
  • Import von Rohsymmetrieschlüsseln (kein Schlüsselverpacken)
  • Asymmetrische Verschlüsselung und Entschlüsselung mit geeigneten Padding-Modi
  • Asymmetrische Signatur und Überprüfung mit Hash-Technologie und geeigneten Padding-Modi
  • Symmetrische Verschlüsselung und Entschlüsselung in geeigneten Modi, einschließlich eines AEAD-Modus
  • Generierung und Überprüfung symmetrischer Nachrichtenauthentifizierungscodes

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.

Zusätzlich zu den oben aufgeführten Diensten gibt es noch einen weiteren Dienst, den Keymaster-Implementierungen bereitstellen, der aber nicht als API verfügbar ist: die Generierung von Zufallszahlen. Dieser wird intern zur Generierung von Schlüsseln, Initialisierungsvektoren (IVs), Zufalls-Padding und anderen Elementen sicherer Protokolle verwendet, die Zufälligkeit erfordern.

Erforderliche Primitive

Alle Keymaster-Implementierungen bieten:

  • RSA
    • Unterstützung von 2.048-, 3.072- und 4.096-Bit-Schlüsseln
    • Unterstützung für den öffentlichen Exponenten F4 (2^16+1)
    • Padding-Modi für die RSA-Signatur:
      • RSASSA-PSS (PaddingMode::RSA_PSS)
      • RSASSA-PKCS1-v1_5 (PaddingMode::RSA_PKCS1_1_5_SIGN)
    • Digest-Modi für die RSA-Signatur:
      • SHA-256
    • Padding-Modi für die RSA-Verschlüsselung/-Entschlüsselung:
      • Ungepolstert
      • RSAES-OAEP (PaddingMode::RSA_OAEP)
      • RSAES-PKCS1-v1_5 (PaddingMode::RSA_PKCS1_1_5_ENCRYPT)
  • ECDSA
    • Es werden Schlüssel mit 224, 256, 384 und 521 Bit unterstützt, wobei jeweils die NIST-Kurven P-224, P-256, P-384 und P-521 verwendet werden.
    • Digest-Modi für ECDSA:
      • Kein Digest (veraltet, wird in Zukunft entfernt)
      • SHA-256
  • AES
    • 128- und 256-Bit-Schlüssel werden unterstützt
    • CBC, CTR, ECB und GCM. Die GCM-Implementierung erlaubt keine Tags mit einer Länge von weniger als 96 Bit oder eine andere Länge als 96 Bit.
    • Die Padding-Modi PaddingMode::NONE und PaddingMode::PKCS7 werden für die CBC- und ECB-Modi unterstützt. Ohne Padding schlägt die Verschlüsselung im CBC- oder ECB-Modus fehl, wenn die Eingabe kein Vielfaches der Blockgröße ist.
  • HMAC SHA-256 mit einer Schlüsselgröße von mindestens 32 Byte.

SHA1 und die anderen Mitglieder der SHA2-Familie (SHA-224, SHA384 und SHA512) werden für Keymaster-Implementierungen dringend empfohlen. Der Keystore stellt sie in Software bereit, wenn sie nicht von der Hardware-Keymaster-Implementierung bereitgestellt werden.

Einige Primitive werden auch für die Interoperabilität mit anderen Systemen empfohlen:

  • Kleinere Schlüsselgrößen für RSA
  • Beliebige öffentliche Exponenten für RSA

Zugriffssteuerung für Schlüssel

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. Beim Erstellen eines Schlüssels gibt der Aufrufer eine Autorisierungsliste an. Die Keymaster-Implementierung, die dem Keystore zugrunde liegt, ändert die Liste, um einige zusätzliche Informationen anzugeben, z. B. ob der Schlüssel einen Rollback-Schutz hat, und gibt eine „finale“ Autorisierungsliste zurück, die im zurückgegebenen Schlüssel-Blob codiert ist. Alle Versuche, den Schlüssel für kryptografische Vorgänge zu verwenden, schlagen fehl, wenn die endgültige Autorisierungsliste geändert wird.

Bei Keymaster 2 und niedriger ist die Gruppe der möglichen Tags in der Aufzählung keymaster_authorization_tag_t definiert und kann nicht geändert werden (kann aber erweitert werden). Namen haben das Präfix KM_TAG. Die ersten vier Bits der Tag-IDs geben den Typ an.

Keymaster 3 hat das Präfix KM_TAG in Tag:: geändert.

Mögliche Typen:

ENUM:Die Werte vieler Tags sind in Aufzählungen definiert. Die möglichen Werte von TAG::PURPOSE sind beispielsweise im Enum keymaster_purpose_t definiert.

ENUM_REP:Entspricht ENUM, mit der Ausnahme, dass das Tag in einer Autorisierungsliste wiederholt werden kann. Wiederholungen weisen auf mehrere autorisierte Werte hin. Ein Verschlüsselungsschlüssel enthält beispielsweise wahrscheinlich KeyPurpose::ENCRYPT und KeyPurpose::DECRYPT.

UINT:Vorzeichenlose 32-Bit-Ganzzahlen. Beispiel: TAG::KEY_SIZE

UINT_REP:Entspricht UINT, mit der Ausnahme, dass das Tag in einer Autorisierungsliste wiederholt werden kann. Wiederholungen weisen auf mehrere autorisierte Werte hin.

ULONG:Vorzeichenlose 64-Bit-Ganzzahlen. Beispiel: TAG::RSA_PUBLIC_EXPONENT

ULONG_REP:Entspricht ULONG, mit der Ausnahme, dass das Tag in einer Autorisierungsliste wiederholt werden kann. Wiederholungen weisen auf mehrere autorisierte Werte hin.

DATE:Datums-/Uhrzeitwerte, ausgedrückt in Millisekunden seit dem 1. Januar 1970. Beispiel: TAG::PRIVKEY_EXPIRE_DATETIME

BOOL: „Wahr“ oder „Falsch“. Für ein Tag vom Typ BOOL wird „false“ angenommen, wenn das Tag nicht vorhanden ist, und „true“, wenn es vorhanden ist. Beispiel: TAG::ROLLBACK_RESISTANT

BIGNUM:Ganzzahlen beliebiger Länge, ausgedrückt als Byte-Array in Big-Endian-Reihenfolge. Beispiel: TAG::RSA_PUBLIC_EXPONENT

BYTES:Eine Folge von Byte. Beispiel: TAG::ROOT_OF_TRUST

Hardware- und Software-Erzwigung

Nicht alle sicheren Hardwareimplementierungen enthalten dieselben Funktionen. Um eine Vielzahl von Ansätzen zu unterstützen, unterscheidet Keymaster zwischen der Durchsetzung der Zugriffssteuerung für sichere und unsichere Welten bzw. für Hardware- und Software-Durchsetzung.

Alle Implementierungen:

  • Erzwingen Sie die genaue Übereinstimmung (nicht die Erzwingung) aller Autorisierungen. Autorisierungslisten in Schlüssel-Blobs stimmen genau mit den Autorisierungen überein, die bei der Schlüsselgenerierung zurückgegeben wurden, einschließlich der Reihenfolge. Abweichungen führen zu einer Fehlerdiagnose.
  • Deklarieren Sie die Autorisierungen, deren semantische Werte erzwungen werden.

Der API-Mechanismus zum Deklarieren von hardwaregestützten Autorisierungen befindet sich in der Struktur keymaster_key_characteristics_t. Die Autorisierungsliste wird in zwei Teillisten unterteilt: hw_enforced und sw_enforced. Die sichere Hardware ist dafür verantwortlich, die entsprechenden Werte anhand der erzwingbaren Informationen einzusetzen.

Darüber hinaus implementiert Keystore die softwarebasierte Durchsetzung aller Autorisierungen, unabhängig davon, ob sie von der sicheren Hardware erzwungen werden oder nicht.

Angenommen, Sie verwenden eine TrustZone-basierte Implementierung, die das Ablaufen von Schlüsseln nicht unterstützt. Es kann jedoch trotzdem ein Schlüssel mit Ablaufdatum erstellt werden. Die Autorisierungsliste dieses Schlüssels enthält das Tag TAG::ORIGINATION_EXPIRE_DATETIME mit dem Ablaufdatum. Bei einer Anfrage an den Keystore für die Schlüsselmerkmale wird dieses Tag in der Liste sw_enforced gefunden und die sichere Hardware erzwingt nicht die Ablaufanforderung. Versuche, den Schlüssel nach Ablauf zu verwenden, werden jedoch vom Keystore abgelehnt.

Wenn das Gerät dann auf eine sichere Hardware umgestellt wird, die das Ablaufdatum unterstützt, wird bei einer Anfrage nach Schlüsselmerkmalen TAG::ORIGINATION_EXPIRE_DATETIME in der Liste hw_enforced gefunden. Versuche, den Schlüssel nach Ablauf zu verwenden, schlagen fehl, auch wenn der Schlüsselspeicher manipuliert oder umgangen wird.

Weitere Informationen dazu, wie Sie feststellen, ob Schlüssel 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 und TAG::DIGEST.

TAG::PADDING, TAG::DIGEST und PaddingMode::BLOCK_MODE sind wiederholbar, d. h., einem einzelnen Schlüssel können mehrere Werte zugeordnet werden. Der zu verwendende Wert wird zum Zeitpunkt der Ausführung angegeben.

Zweck

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

  • KeyPurpose::ENCRYPT
  • KeyPurpose::DECRYPT
  • KeyPurpose::SIGN
  • KeyPurpose::VERIFY

Jeder Schlüssel kann eine beliebige Teilmenge dieser Zwecke haben. Beachten Sie, dass einige Kombinationen Sicherheitsprobleme verursachen 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.

Importieren und exportieren

Keymaster unterstützt nur den Export öffentlicher Schlüssel im X.509-Format und den Import folgender Elemente:

  • Öffentliche und private 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 Secure Keymaster-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 zu Gatekeeper.

Die Anforderungen an die Nutzerauthentifizierung werden über zwei Tag-Sets angegeben. Die erste Gruppe gibt an, welcher Nutzer den Schlüssel verwenden kann:

  • TAG::ALL_USERS gibt an, dass der Schlüssel von allen Nutzern verwendet werden kann. Wenn vorhanden, sind TAG::USER_ID und TAG::USER_SECURE_ID nicht vorhanden.
  • TAG::USER_ID hat einen numerischen Wert, der die ID des autorisierten Nutzers angibt. Hinweis: Dies ist die Android-Nutzer-ID (für mehrere Nutzer), nicht die UID der App. Sie wird nur von nicht sicherer Software erzwungen. Wenn „present“ angegeben ist, ist TAG::ALL_USERS nicht vorhanden.
  • TAG::USER_SECURE_ID hat einen 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.

  • NO_AUTHENTICATION_REQUIRED gibt an, dass keine Nutzerauthentifizierung erforderlich ist. Der Schlüssel kann jedoch nur von Apps verwendet werden, die als die mit TAG::USER_ID angegebenen Nutzer ausgeführt werden.
  • TAG::AUTH_TIMEOUT ist ein numerischer Wert, der in Sekunden angibt, wie aktuell die Nutzerauthentifizierung sein muss, um die Schlüsselnutzung zu autorisieren. Dies gilt nur für Vorgänge mit privaten/geheimen Schlüsseln. Für Public-Key-Vorgänge ist keine Authentifizierung erforderlich. Timeouts gelten nicht über einen Neustart hinaus. Nach einem Neustart werden nie alle Schlüssel authentifiziert. 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 vom Schlüsselspeicher und nicht von Keymaster 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, da diese Verschlüsselungsebene zusätzlich zur Verschlüsselungsebene angewendet wird, die Keymaster 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 Klasse-3-Biometrie („stark“) und PIN, Muster oder 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 Fingerabdruck) des Nutzers wiederhergestellt werden können, als Alternative zu PIN, Muster oder Passwort. Dazu generiert er einen neuen AES‑256‑GCM-Schlüssel, verschlüsselt damit die geheimen Teile der Superschlüssel, importiert den AES‑256‑GCM-Schlüssel als biometrisch gebundenen Schlüssel in Keymaster, für den innerhalb der letzten 15 Sekunden eine biometrische Authentifizierung erfolgreich durchgeführt werden musste, und setzt die Klartextkopien aller dieser Schlüssel auf Null.
  • 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. Dieser Vorgang wird von Keymaster (nicht von Keystore) erzwungen.

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 verwendet werden und byteweise identisch sind. Die Clientbindungsdaten werden von Keymaster 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. Keymaster 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, ist es unwahrscheinlich, dass die Tags mit Ablaufdatum in der hardwaregestützten Liste enthalten sind. Für die Hardwaredurchsetzung des Ablaufdatums müsste die sichere Umgebung auf irgendeine Weise vertrauenswürdige Zeit und Daten abrufen, z. B. über ein Abfrage-Antwort-Protokoll mit einem vertrauenswürdigen Remote-Zeitserver.

Root of Trust-Bindung

Für den Keystore müssen Schlüssel an einen Root of Trust gebunden sein. Dabei handelt es sich um einen Bitstring, der beim Starten der sicheren Keymaster-Hardware bereitgestellt wird, vorzugsweise vom Bootloader. Dieser Bitstring ist kryptografisch an jeden von Keymaster verwalteten Schlüssel gebunden.

Die Vertrauensbasis besteht aus dem öffentlichen Schlüssel, der zum Verifizieren der Signatur im Boot-Image und zum Entsperren des Geräts verwendet wird. 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 Keymaster-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 Angreifern installierten Betriebssystem unmöglich gemacht wird, Keymaster-Schlüssel zu verwenden.

Eigenständige Schlüssel

Einige sichere Keymaster-Hardware kann Schlüsselmaterial intern speichern und Handles anstelle von verschlüsseltem Schlüsselmaterial zurückgeben. Es kann auch andere Fälle geben, in denen Schlüssel erst verwendet werden können, wenn eine andere unsichere oder sichere Systemkomponente verfügbar ist. Mit der Keymaster HAL kann der Aufrufer über das TAG::STANDALONE-Tag anfordern, dass ein Schlüssel „eigenständig“ ist. Das bedeutet, dass keine anderen Ressourcen als der Blob und das laufende Keymaster-System erforderlich sind. Anhand der mit einem Schlüssel verknüpften Tags lässt sich feststellen, ob es sich um einen eigenständigen Schlüssel handelt. Derzeit sind nur zwei Werte definiert:

  • KeyBlobUsageRequirements::STANDALONE
  • KeyBlobUsageRequirements::REQUIRES_FILE_SYSTEM

Diese Funktion ist für Apps nicht sichtbar.

Geschwindigkeit

Beim Erstellen kann die maximale Nutzungsgeschwindigkeit mit TAG::MIN_SECONDS_BETWEEN_OPS angegeben werden. TrustZone-Implementierungen lehnen kryptografische Vorgänge mit diesem Schlüssel ab, wenn vor weniger als TAG::MIN_SECONDS_BETWEEN_OPS Sekunden ein Vorgang ausgeführt wurde.

Die einfachste Methode zur Implementierung von Geschwindigkeitslimits ist eine Tabelle mit Schlüssel-IDs und Zeitstempeln der letzten Verwendung. Diese Tabelle ist begrenzt, bietet aber Platz für mindestens 16 Einträge. Wenn die Tabelle voll ist und keine Einträge aktualisiert oder verworfen werden können, reagieren sichere Hardwareimplementierungen „fail-safe“ und lehnen alle geschwindigkeitsbegrenzten Schlüsselvorgänge ab, bis einer der Einträge abläuft. Es ist zulässig, dass alle Einträge nach einem Neustart ablaufen.

Mit TAG::MAX_USES_PER_BOOT können Schlüssel auch auf n Verwendungen pro Start begrenzt werden. Dazu ist auch eine Tracking-Tabelle erforderlich, die mindestens vier Schlüssel aufnehmen und auch fehlersicher sein muss. Apps können keine pro Boot eingeschränkten Schlüssel erstellen. Diese Funktion wird nicht über den Keystore bereitgestellt und ist für Systemvorgänge reserviert.

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

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 Keymaster HAL eine Schnittstelle, über die der Client 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.

Diese Funktion ist für Apps nicht sichtbar, wird aber vom Framework verwendet, das der sicheren Hardware regelmäßig zusätzliche Entropie aus einer Java SecureRandom-Instanz zur Verfügung stellt.