Funktionen

Auf dieser Seite finden Sie 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:

• Erstellung von Schlüsseln, die zu privatem oder geheimem Schlüsselmaterial führen, auf das nur über die sichere Umgebung zugegriffen werden 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 einen vertrauenswürdigen Root zurückgeht.
• Kryptografische Vorgänge:
  • Symmetrische Ver- und Entschlüsselung (AES, 3DES)
  • Asymmetrische Entschlüsselung (RSA)
  • Asymmetrisches Signieren (ECDSA, RSA)
  • Symmetrische Signierung und Bestätigung (HMAC)
  • Asymmetrische Schlüsselvereinbarung (ECDH)

Beachten Sie, dass Keystore und KeyMint keine Vorgänge für öffentliche Schlüssel für asymmetrische Schlüssel verarbeiten.

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älligen Füllzeichen 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 NIST-Kurven P-224, P-256, P-384 bzw. 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 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 Primitives 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 nach Belieben verwenden kann (obwohl sie sicherer sind als Schlüssel, die extrahiert werden können). Daher ist es wichtig, dass in Keystore Zugriffssteuerungen erzwungen werden.

Zugriffssteuerungen werden als „Autorisierungsliste“ von Tag/Wert-Paaren definiert. Autorisierungstags sind 32-Bit-Ganzzahlen und die Werte sind von unterschiedlichen 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.

Bei 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 haben 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 den Keyblob gebunden. Jeder Versuch, die Autorisierungsliste zu ändern (einschließlich der Reihenfolge), führt zu einem ungültigen Keyblob, der 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. der Erzwingung von 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 für die Erstellung 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 Reihe von zugehörigen Zwecken, die als ein oder mehrere Autorisierungseinträge mit dem Tag::PURPOSE-Tag ausgedrückt werden und definieren, 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 Schlüsselautorisierungsliste 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 von anderen vertrauenswürdigen Apps abhängig, 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 ist ein 64‑Bit-Zahlenwert, der die sichere Nutzer-ID angibt, die in einem sicheren Authentifizierungstoken enthalten ist, um die Verwendung des Schlüssels zu entsperren. Wenn der Schlüssel wiederholt wird, kann er 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 Schlüsselnutzung zu autorisieren. Timeouts werden nicht über Neustarts hinweg beibehalten. Nach einem Neustart sind 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. In 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.

Dazu „superverschlüsselt“ Keystore alle UNLOCKED_DEVICE_REQUIRED-Schlüssel, 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 Supersicherheitsschlüssel „UnlockedDeviceRequired“. Dies ist ein AES‑256‑GCM-Schlüssel. Damit werden UNLOCKED_DEVICE_REQUIRED-Schlüssel verschlüsselt, die importiert oder generiert werden, während das Gerät für den Nutzer entsperrt ist.
• Der asymmetrische Supersicherheitsschlü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. Mit diesem asymmetrischen Schlüssel verschlüsselte Schlüssel werden bei der ersten Verwendung mit dem symmetrischen Schlüssel neu verschlüsselt. Das kann nur erfolgen, wenn das Gerät entsperrt ist.

Keystore generiert diese Superschlüssel bei der Nutzererstellung und speichert sie in der Datenbank, verschlüsselt mit dem synthetischen Passwort des Nutzers. Sie können dann mit einer PIN, einem Muster oder einem Passwort wiederhergestellt werden.

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 Hauptschlüssel nur über die verschlüsselte Kopie in der Datenbank wiederhergestellt werden, die nur mit einer PIN, einem Muster oder einem 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 über alle registrierten Biometrie der Klasse 3 des Nutzers (in der Regel Fingerabdruck) als Alternative zu PIN, Muster oder Passwort wiederhergestellt werden können. Dazu wird ein neuer AES‑256‑GCM-Schlüssel generiert, die geheimen Teile der Super-Schlüssel damit verschlüsselt, der AES‑256‑GCM-Schlüssel 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 gängigsten Entsperrmethoden, die in diese Kategorien fallen, sind die Gesichtserkennung auf vielen Geräten und das Entsperren mit einer gekoppelten Smartwatch.

Wenn das Gerät für den Nutzer entsperrt wird, ruft Keystore die UnlockedDeviceRequired-Superschlüssel des Nutzers 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 ja, wird versucht, diese 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.

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 bzw. Tag::APPLICATION_DATA). Keystore behandelt diese Werte als undurchsichtige Blobs und sorgt nur dafür, 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 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

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 weigert sich, Schlüsselvorgänge auszuführen, 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 „Erstellung“ und „Verwendung“ basiert darauf, ob der Schlüssel zum „Erstellen“ eines neuen Geheimtexts/einer neuen Signatur usw. oder zum „Verwenden“ eines vorhandenen Geheimtexts/einer vorhandenen Signatur usw. verwendet wird. 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 ablaufbezogenen Tags in der softwarebasierten Liste.

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 System-Images 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 Sicherheitschips 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 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, 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 mit TAG::MAX_USES_PER_BOOT auf n Verwendungen pro Bootvorgang beschränkt werden. Dazu ist auch eine Tracking-Tabelle erforderlich, die mindestens vier Schlüssel aufnehmen kann und ebenfalls ausfallsicher ist. Apps können keine Schlüssel erstellen, die auf den jeweiligen Startvorgang beschränkt sind. Diese Funktion ist nicht über den Keystore verfügbar und ist 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.