Funktionen

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

Kryptografische Primitive

Keystore bietet die folgenden Kategorien von Vorgängen:

• Erstellung von Schlüsseln, die zu privatem oder geheimem Schlüsselmaterial führen, auf das nur die sichere Umgebung zugreifen kann. Clients können Schlüssel auf folgende Weise erstellen:
  • Neue Schlüssel generieren
  • 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 mit einem Schlüssel signiert sind, der auf eine vertrauenswürdige Root zurückgeht.
• Kryptografische Vorgänge:
  • Symmetrische Ver- und Entschlüsselung (AES, 3DES)
  • Asymmetrische Entschlüsselung (RSA)
  • Asymmetrisches Signieren (ECDSA, RSA)
  • Symmetrisches Signieren und Bestätigen (HMAC)
  • Asymmetrische Schlüsselvereinbarung (ECDH)

Protokollelemente wie Zweck, Modus und Auffüllung sowie Einschränkungen für die Zugriffssteuerung werden beim Generieren oder Importieren von Schlüsseln angegeben und sind dauerhaft an den Schlüssel gebunden. So wird sichergestellt, dass der Schlüssel nicht auf andere Weise verwendet werden kann.

Zusätzlich zur obigen Liste gibt es einen weiteren Dienst, der von KeyMint-Implementierungen (früher Keymaster) bereitgestellt wird, aber nicht als API verfügbar ist: die Generierung von Zufallszahlen. Diese Funktion wird intern zum Generieren von Schlüsseln, Initialisierungsvektoren (IVs), zufälligem Padding und anderen Elementen sicherer Protokolle verwendet, die Zufälligkeit erfordern.

Erforderliche Primitiven

Alle KeyMint-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)
  • Auffüllmodi für die RSA-Signierung:
    • RSASSA-PSS (PaddingMode::RSA_PSS)
    • RSASSA-PKCS1-v1_5 (PaddingMode::RSA_PKCS1_1_5_SIGN)
  • Zusammenfassungsmodi für die RSA-Signierung:
    • 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 224-, 256-, 384- und 521-Bit-Schlüssel unterstützt, wobei die Kurven NIST P-224, P-256, P-384 bzw. P-521 verwendet werden.
  • Digest-Modi für ECDSA:
    • Kein Kurzfassung (eingestellt, wird in Zukunft entfernt)
    • SHA-256
• AES
  • 128- und 256-Bit-Schlüssel werden unterstützt
  • CBC, CTR, ECB und GCM. Die GCM-Implementierung lässt keine Verwendung von Tags mit weniger als 96 Bit oder Nonce-Längen, die nicht 96 Bit betragen, zu.
  • Die Auffüllmodi PaddingMode::NONE und PaddingMode::PKCS7 werden für die CBC- und ECB-Modi unterstützt. Ohne Auffüllung schlägt die CBC- oder ECB-Modusverschlüsselung fehl, wenn die Eingabe kein Vielfaches der Blockgröße ist.
• HMAC SHA-256 mit einer beliebigen Schlüsselgröße bis zu mindestens 32 Byte.

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

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

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

Schlüsselzugriffssteuerung

Hardwarebasierte Schlüssel, die niemals vom Gerät extrahiert werden können, bieten nicht viel Sicherheit, wenn ein Angreifer sie beliebig verwenden kann (obwohl sie sicherer sind als Schlüssel, die extrahiert werden können). Daher ist es wichtig, dass Keystore die Zugriffssteuerung erzwingt.

Zugriffssteuerungen werden als „Autorisierungsliste“ von Tag/Wert-Paaren definiert. Autorisierungstags sind 32-Bit-Ganzzahlen und die Werte sind von verschiedenen Typen. Einige Tags können wiederholt werden, um mehrere Werte anzugeben. Ob ein Tag wiederholt werden kann, wird in der KeyMint-HAL-Schnittstelle angegeben. Wenn ein Schlüssel erstellt wird, gibt der Aufrufer eine Autorisierungsliste an. Die KeyMint-Implementierung, die Keystore zugrunde liegt, ändert die Liste, um einige zusätzliche Informationen anzugeben, z. B. ob der Schlüssel einen Rollback-Schutz hat. Außerdem wird eine „finale“ Autorisierungsliste zurückgegeben, die im zurückgegebenen Schlüssel-Blob codiert ist. Jeder Versuch, den Schlüssel für einen kryptografischen Vorgang zu verwenden, schlägt fehl, wenn die endgültige Autorisierungsliste geändert wird.

Für Keymaster 2 und früher ist die Menge der möglichen Tags in der Aufzählung keymaster_authorization_tag_t definiert und dauerhaft festgelegt (kann aber erweitert werden). Namen hatten das Präfix KM_TAG. Die vier höchstwertigen Bits der Tag-IDs werden verwendet, um den Typ anzugeben.

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 in der Enumeration keymaster_purpose_t definiert.

ENUM_REP:Wie ENUM, mit dem Unterschied, dass das Tag in einer Autorisierungsliste wiederholt werden kann. Wiederholung weist auf mehrere autorisierte Werte hin. Ein Verschlüsselungsschlüssel hat beispielsweise wahrscheinlich KeyPurpose::ENCRYPT und KeyPurpose::DECRYPT.

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 Keyblob. Die codierte Autorisierungsliste ist kryptografisch an das Keyblob gebunden. Jeder Versuch, die Autorisierungsliste zu ändern (einschließlich der Reihenfolge), führt zu einem ungültigen Keyblob, das nicht für kryptografische Vorgänge verwendet werden kann.

Hardware- und Software-Durchsetzung

Nicht alle Implementierungen sicherer Hardware enthalten dieselben Funktionen. Um verschiedene Ansätze zu unterstützen, unterscheidet Keymaster zwischen der Erzwingung der Zugriffssteuerung für die sichere und die nicht sichere Welt bzw. zwischen der Erzwingung durch Hardware und Software.

Dies wird in der KeyMint API mit dem Feld securityLevel vom Typ KeyCharacteristics bereitgestellt. Die sichere Hardware ist dafür verantwortlich, die Autorisierungen mit dem entsprechenden Sicherheitsniveau in KeyCharacteristics zu platzieren, basierend darauf, was sie erzwingen kann. Diese Informationen werden auch in den Attestierungsdatensätzen für asymmetrische Schlüssel verfügbar gemacht: Schlüsselmerkmale für SecurityLevel::TRUSTED_ENVIRONMENT oder SecurityLevel::STRONGBOX werden in der Liste hardwareEnforced angezeigt 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 Regel nicht von der sicheren Umgebung erzwungen, da sie keinen vertrauenswürdigen Zugriff auf Datums- und Zeitinformationen hat. Daher werden Autorisierungen wie Tag::ORIGINATION_EXPIRE_DATETIME von Keystore in Android erzwungen und hätten SecurityLevel::KEYSTORE.

Weitere Informationen dazu, ob Schlüssel und ihre Autorisierungen hardwarebasiert sind, finden Sie unter Schlüsselattestierung.

Autorisierungen zum Erstellen kryptografischer Nachrichten

Die folgenden Tags werden verwendet, um die kryptografischen Merkmale von Vorgängen mit dem zugehörigen Schlüssel zu definieren:

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

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

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

Der zu verwendende Wert wird zum Zeitpunkt des Vorgangs angegeben.

Zweck

Schlüssel haben eine zugehörige Reihe von Zwecken, die als ein oder mehrere Autorisierungseinträge mit dem Tag::PURPOSE-Tag ausgedrückt werden. Dadurch wird definiert, wie sie verwendet werden können. Die Zwecke sind in KeyPurpose.aidl definiert.

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

Schlüsselimport

Keymaster unterstützt nur den Export öffentlicher Schlüssel im X.509-Format und 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, wird Tag::ORIGIN in die entsprechende Liste der Schlüsselautorisierungen aufgenommen. Wenn beispielsweise ein Schlüssel in sicherer Hardware generiert wurde, ist Tag::ORIGIN mit dem Wert KeyOrigin::GENERATED in der Liste hw_enforced der Schlüsselmerkmale zu finden. Ein Schlüssel, der in sichere Hardware importiert wurde, hat den Wert KeyOrigin::IMPORTED.

Nutzerauthentifizierung

Sichere KeyMint-Implementierungen implementieren keine Nutzerauthentifizierung, sondern sind auf andere vertrauenswürdige Apps angewiesen, die dies tun. Informationen zur Schnittstelle, die diese Apps implementieren, finden Sie auf der Gatekeeper-Seite.

Die Anforderungen an die Nutzerauthentifizierung werden über zwei Gruppen von Tags angegeben. Die erste Gruppe gibt an, welche Authentifizierungsmethoden die Verwendung des Schlüssels zulassen:

• Tag::USER_SECURE_ID hat einen 64‑Bit-Zahlenwert, der die sichere Nutzer-ID angibt, die in einem sicheren Authentifizierungstoken enthalten ist, 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 zugehörige App (und alle Apps, denen sie Zugriff gewährt) beschränkt.
• Tag::AUTH_TIMEOUT ist ein numerischer Wert, der in Sekunden angibt, wie aktuell die Nutzerauthentifizierung sein muss, um die Verwendung von Schlüsseln zu autorisieren. Timeouts werden nicht über Neustarts hinweg beibehalten. Nach einem Neustart werden alle Authentifizierungen ungültig. Das Zeitlimit kann auf einen großen Wert festgelegt werden, um anzugeben, dass die Authentifizierung einmal pro Start erforderlich ist (2^32 Sekunden entsprechen etwa 136 Jahren; Android-Geräte werden vermutlich häufiger neu gestartet).

Entsperrtes Gerät erforderlich

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 werden UNLOCKED_DEVICE_REQUIRED-Schlüssel jedoch kryptografisch durch Keystore geschützt, während das Gerät gesperrt ist. So wird dafür gesorgt, dass sie in den meisten Fällen nicht verwendet werden können, selbst wenn Keystore kompromittiert wird, während das Gerät gesperrt ist.

Für alle in diesem Abschnitt beschriebenen kryptografischen Verfahren und die Generierung von Zufallszahlen wird BoringSSL verwendet, sofern nicht ausdrücklich die Verwendung von KeyMint erwähnt wird. Alle Secrets werden gelöscht, sobald sie nicht mehr benötigt werden.

Super-Schlüssel für UnlockedDeviceRequired

Um UNLOCKED_DEVICE_REQUIRED-Schlüssel kryptografisch zu schützen, werden sie von Keystore „superverschlüsselt“, bevor sie in der Datenbank gespeichert werden. Wenn möglich, werden die Superverschlüsselungsschlüssel (Superschlüssel) geschützt, während das Gerät gesperrt ist. Sie können nur durch ein erfolgreiches Entsperren des Geräts wiederhergestellt werden. 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 Profilen) hat zwei Super-Schlüssel, die mit UNLOCKED_DEVICE_REQUIRED verknüpft sind:

• Der symmetrische Super-Schlüssel „UnlockedDeviceRequired“. Dies ist ein AES‑256‑GCM-Schlüssel. Damit werden UNLOCKED_DEVICE_REQUIRED-Schlüssel verschlüsselt, die importiert, generiert oder verwendet werden, während das Gerät für den Nutzer entsperrt ist.
• Der asymmetrische Super-Schlüssel „UnlockedDeviceRequired“. Dies ist ein ECDH-Schlüsselpaar mit P‑521. Damit werden UNLOCKED_DEVICE_REQUIRED-Schlüssel verschlüsselt, die importiert oder generiert werden, während das Gerät für den Nutzer gesperrt ist. Weitere Informationen finden Sie unter Schlüssel speichern, während das Gerät gesperrt ist.

Superschlüssel generieren und schützen

Wenn ein Nutzer erstellt wird, generiert Keystore die Super-Schlüssel „UnlockedDeviceRequired“ des Nutzers und speichert sie verschlüsselt (indirekt) mit dem synthetischen Passwort des Nutzers in seiner Datenbank:

1. Der Systemserver leitet das Keystore-Passwort des Nutzers aus dem synthetischen Passwort des Nutzers mithilfe einer SP800‑108-KDF ab.
2. Der Systemserver übergibt das Keystore-Passwort des Nutzers an Keystore.
3. Keystore generiert die Super-Schlüssel des Nutzers.
4. Für jeden der Super-Schlüssel des Nutzers:
   1. Keystore generiert einen zufälligen Salt.
   2. Keystore leitet einen AES‑256‑GCM-Schlüssel aus dem Keystore-Passwort des Nutzers und dem Salt mithilfe von HKDF‑SHA256 ab.
   3. Keystore verschlüsselt den geheimen Teil des Super-Schlüssels mit diesem AES‑256‑GCM-Schlüssel.
   4. Im Schlüsselspeicher werden der verschlüsselte Super-Schlüssel und sein Salt in der Datenbank gespeichert. Bei einem asymmetrischen Schlüssel wird auch die öffentliche Hälfte des Schlüssels unverschlüsselt gespeichert.

Mit diesem Verfahren können diese Super-Schlüssel entschlüsselt werden, wenn das synthetische Passwort des Nutzers bekannt ist, z. B. wenn die richtige PIN, das richtige Muster oder das richtige Passwort des Nutzers eingegeben wird.

Keystore speichert diese Super-Schlüssel auch im Cache, sodass sie für UNLOCKED_DEVICE_REQUIRED-Schlüssel verwendet werden können. Die geheimen Teile dieser Schlüssel werden jedoch nur im Cache gespeichert, wenn das Gerät für den Nutzer entsperrt ist. Wenn das Gerät für den Nutzer gesperrt ist, löscht Keystore nach Möglichkeit die zwischengespeicherte Kopie der geheimen Teile dieser Super-Schlüssel. Wenn das Gerät für den Nutzer gesperrt ist, wählt Keystore eine von drei Schutzstufen für die UnlockedDeviceRequired-Superschlüssel des Nutzers aus und wendet sie an:

• Wenn der Nutzer nur PIN, Muster oder Passwort aktiviert hat, löscht Keystore die geheimen Teile der zwischengespeicherten Super-Schlüssel. 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 entsprechenden Passwort entschlüsselt werden kann.
• Wenn der Nutzer nur Biometrie der Klasse 3 („stark“) und PIN, Muster oder Passwort aktiviert hat, sorgt Keystore dafür, dass die Super-Schlüssel durch alle registrierten biometrischen Verfahren der Klasse 3 des Nutzers (in der Regel Fingerabdruck) wiederhergestellt werden können, als Alternative zu PIN, Muster oder Passwort. Dazu wird ein neuer AES‑256‑GCM-Schlüssel generiert, die geheimen Teile der Überschlüssel werden damit verschlüsselt, der AES‑256‑GCM-Schlüssel wird als biometrisch gebundener Schlüssel in KeyMint importiert, für den die biometrische Authentifizierung in den letzten 15 Sekunden erfolgreich gewesen sein muss, und die Klartextkopien aller dieser Schlüssel werden gelöscht.
• Wenn der Nutzer ein biometrisches Verfahren der Klasse 1 („Komfort“), ein biometrisches Verfahren der Klasse 2 („schwach“) oder einen aktiven Trust-Agent für die Entsperrung aktiviert hat, werden die Super-Schlüssel im Keystore im Klartext zwischengespeichert. 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 häufigsten Entsperrmethoden, die in diese Kategorien fallen, sind die Gesichtsentsperrung auf vielen Geräten und die Entsperrung mit einer gekoppelten Smartwatch.

Wenn das Gerät für den Nutzer entsperrt ist, ruft Keystore die Super-Schlüssel des Nutzers mit der Kennzeichnung „UnlockedDeviceRequired“ ab, sofern möglich. Bei der Entsperrung mit PIN, Muster oder Passwort wird die Kopie dieser Schlüssel entschlüsselt, die in der Datenbank gespeichert ist. Andernfalls wird geprüft, ob eine Kopie dieser Schlüssel verschlüsselt mit einem biometrisch gebundenen Schlüssel gespeichert wurde. Wenn dies der Fall ist, wird versucht, diese Kopie zu entschlüsseln. Dies ist nur möglich, wenn sich der Nutzer in den letzten 15 Sekunden erfolgreich mit einem biometrischen Verfahren der Klasse 3 authentifiziert hat. Dies wird von KeyMint (nicht Keystore) erzwungen.

Schlüssel speichern, während das Gerät gesperrt ist

Mit Keystore können Nutzer UNLOCKED_DEVICE_REQUIRED-Schlüssel importieren und generieren, während das Gerät gesperrt ist. Dabei wird ein hybrides Verschlüsselungsschema verwendet, damit die Daten nur entschlüsselt werden können, wenn das Gerät später entsperrt wird:

• Verschlüsselung (Importieren oder Generieren eines UNLOCKED_DEVICE_REQUIRED-Schlüssels, während das Gerät gesperrt ist):
  1. Keystore generiert ein neues kurzlebiges ECDH P‑521-Schlüsselpaar.
  2. Keystore generiert ein gemeinsames Geheimnis, indem es einen ECDH-Schlüsselaustausch zwischen dem privaten Schlüssel dieses kurzlebigen Schlüsselpaars und der öffentlichen Hälfte des asymmetrischen Super-Schlüssels „UnlockedDeviceRequired“ durchführt.
  3. Keystore generiert einen zufälligen Salt.
  4. Keystore leitet einen AES‑256‑GCM-Schlüssel aus dem gemeinsamen Secret und dem Salt mit HKDF‑SHA256 ab.
  5. Keystore verschlüsselt den UNLOCKED_DEVICE_REQUIRED-Schlüssel mit diesem AES‑256‑GCM-Schlüssel.
  6. Im Keystore werden der verschlüsselte UNLOCKED_DEVICE_REQUIRED-Schlüssel, das Salt und die öffentliche Hälfte des kurzlebigen Schlüsselpaars in der Datenbank gespeichert.
• Entschlüsselung (mit dem erstellten UNLOCKED_DEVICE_REQUIRED-Schlüssel, während das Gerät entsperrt ist):
  1. Keystore lädt den verschlüsselten UNLOCKED_DEVICE_REQUIRED-Schlüssel, den Salt und die öffentliche Hälfte des kurzlebigen Schlüsselpaars aus der Datenbank.
  2. Keystore generiert ein gemeinsames Secret, indem es einen ECDH-Schlüsselaustausch zwischen der öffentlichen Hälfte des kurzlebigen Schlüsselpaars und der privaten Hälfte des asymmetrischen Super-Schlüssels „UnlockedDeviceRequired“ durchführt. Der private Schlüssel ist verfügbar, weil das Gerät entsperrt ist.
  3. Keystore leitet einen AES‑256‑GCM-Schlüssel aus dem gemeinsamen Secret und dem Salt mit HKDF‑SHA256 ab. Dieser AES‑256‑GCM-Schlüssel ist derselbe wie der, der während der Verschlüsselung abgeleitet wurde.
  4. Keystore entschlüsselt den UNLOCKED_DEVICE_REQUIRED-Schlüssel mit dem AES‑256‑GCM-Schlüssel.
  5. Der Keystore verschlüsselt den UNLOCKED_DEVICE_REQUIRED-Schlüssel mit dem symmetrischen Super-Schlüssel „UnlockedDeviceRequired“ neu. Dies hat keine Auswirkungen auf die Sicherheitseigenschaften des Schlüssels, ermöglicht aber einen schnelleren Zugriff später.

Mit dieser Funktion können Apps Daten speichern, während das Gerät gesperrt ist. Die Daten können dann nur entschlüsselt werden, wenn das Gerät entsperrt ist. Dazu sollten Apps die folgenden Schritte ausführen:

1. Generieren Sie einen AES‑256‑GCM-Schlüssel außerhalb des Schlüsselspeichers.
2. Daten mit dem AES‑256‑GCM-Schlüssel verschlüsseln
3. Importieren Sie den AES‑256‑GCM-Schlüssel in den Keystore mit der Schlüssel-Schutzstufe setUnlockedDeviceRequired(true).
4. Löschen Sie die Originalkopie des Schlüssels.

Um die Daten zu entschlüsseln, während das Gerät entsperrt ist, verwenden Sie den Schlüssel, der in den Keystore importiert wurde.

Clientbindung

Die Clientbindung, also die Zuordnung eines Schlüssels zu einer bestimmten Client-App, erfolgt über eine optionale Client-ID und einige optionale Clientdaten (Tag::APPLICATION_ID bzw. Tag::APPLICATION_DATA). Im Keystore werden diese Werte als undurchsichtige Blobs behandelt. Es wird nur dafür gesorgt, dass die Blobs, die bei der Schlüsselgenerierung bzw. beim Schlüsselimport präsentiert werden, bei jeder Verwendung präsentiert werden und bytegenau identisch sind. Die Clientbindungsdaten werden nicht von KeyMint zurückgegeben. Der Anrufer muss ihn kennen, um den Schlüssel verwenden zu können.

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

Ablauffrist

Keystore unterstützt die Einschränkung der Schlüsselnutzung nach Datum. Einem Schlüssel können ein Gültigkeitsbeginn und ein Ablaufdatum zugewiesen werden. Keymaster lehnt die Ausführung von Schlüsselvorgängen ab, wenn das aktuelle Datum/die aktuelle Uhrzeit außerhalb des gültigen Bereichs liegt. 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 „Ursprung“ und „Verwendung“ basiert darauf, ob der Schlüssel verwendet wird, um einen neuen Geheimtext, eine neue Signatur usw. zu „erstellen“, oder um einen vorhandenen Geheimtext, eine vorhandene Signatur usw. zu „verwenden“. Diese Unterscheidung wird Apps nicht zur Verfügung gestellt.

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 Wanduhrzeit von der nicht sicheren Welt bereitgestellt wird, befinden sich die Ablauf-bezogenen Tags in der Liste der softwarebasierten Durchsetzung.

Root of Trust-Bindung

Für Keystore müssen Schlüssel an einen Root of Trust gebunden werden. Das ist ein Bitstring, der der KeyMint-Sicherheitshardware beim Start zur Verfügung gestellt wird, vorzugsweise vom Bootloader. Dieser Bitstring ist kryptografisch an jeden von KeyMint verwalteten Schlüssel gebunden.

Der Root of Trust besteht aus dem öffentlichen Schlüssel, der zum Überprüfen der Signatur des Boot-Images verwendet wird, und dem Sperrzustand des Geräts. Wenn der öffentliche Schlüssel geändert wird, um die Verwendung eines anderen Systemabbilds zu ermöglichen, oder wenn der Sperrzustand geändert wird, sind keine der von KeyMint geschützten Schlüssel, die vom vorherigen System erstellt wurden, verwendbar, es sei denn, der vorherige Root of Trust wird wiederhergestellt und ein System, das mit diesem Schlüssel signiert ist, wird gestartet. Ziel ist es, den Wert der softwarebasierten Schlüsselzugriffskontrollen zu erhöhen, indem es für ein von einem Angreifer installiertes Betriebssystem unmöglich gemacht wird, KeyMint-Schlüssel zu verwenden.

Eigenständige Schlüssel

Bei einigen KeyMint-kompatiblen Sicherheitsmodulen kann das Schlüsselmaterial intern gespeichert und Handles anstelle von verschlüsseltem Schlüsselmaterial zurückgegeben werden. Es kann auch andere Fälle geben, in denen Schlüssel erst verwendet werden können, wenn eine andere nicht sichere oder sichere Systemkomponente verfügbar ist. Mit der KeyMint-HAL kann der Aufrufer über das Tag TAG::STANDALONE anfordern, dass ein Schlüssel „standalone“ ist. Das bedeutet, dass außer dem Blob und dem laufenden KeyMint-System keine Ressourcen erforderlich sind. Die mit einem Schlüssel verknüpften Tags können geprüft werden, um festzustellen, ob ein Schlüssel eigenständig ist. Derzeit sind nur zwei Werte definiert:

• KeyBlobUsageRequirements::STANDALONE
• KeyBlobUsageRequirements::REQUIRES_FILE_SYSTEM

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

Geschwindigkeit

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

Der einfache Ansatz zur Implementierung von Geschwindigkeitsbegrenzungen ist eine Tabelle mit Schlüssel-IDs und Zeitstempeln der letzten Verwendung. Diese Tabelle hat eine begrenzte Größe, bietet aber Platz für mindestens 16 Einträge. Wenn die Tabelle voll ist und keine Einträge aktualisiert oder verworfen werden können, sind sichere Hardwareimplementierungen „fehlersicher“ und lehnen alle geschwindigkeitsbegrenzten Schlüsselvorgänge ab, bis einer der Einträge abläuft. Es ist akzeptabel, wenn alle Einträge beim Neustart ablaufen.

Schlüssel können auch auf n Verwendungen pro Bootvorgang mit TAG::MAX_USES_PER_BOOT begrenzt werden. Dazu ist auch eine Tracking-Tabelle erforderlich, die mindestens vier Schlüssel aufnehmen kann und ausfallsicher ist. Apps können keine Schlüssel erstellen, die auf den jeweiligen Neustart beschränkt sind. Diese Funktion ist nicht über den Keystore verfügbar und für Systemvorgänge reserviert.

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

Neues Seeding des Zufallszahlengenerators

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

Verwenden Sie einen Hardware-Zufallszahlengenerator als primäre Seed-Quelle. Die über die externe API bereitgestellten Ausgangsdaten dürfen nicht die einzige Quelle für Zufallszahlen sein, die für die Zahlengenerierung verwendet werden. Außerdem muss der verwendete Mischvorgang dafür sorgen, dass die zufällige Ausgabe unvorhersehbar ist, wenn eine der Seed-Quellen unvorhersehbar ist.