Funktionen

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

Hinweis: Tags und Funktionen sind im Keymaster 3-Stil geschrieben. Weitere Informationen finden Sie in der HIDL-Übersicht .

Kryptografische Grundelemente

Keystore bietet die folgenden Kategorien von Vorgängen:

• Schlüsselgenerierung
• Import und Export asymmetrischer Schlüssel (kein Schlüsselumbruch)
• Import roher symmetrischer Schlüssel (kein Schlüsselumbruch)
• Asymmetrische Verschlüsselung und Entschlüsselung mit geeigneten Auffüllmodi
• Asymmetrisches Signieren und Verifizieren mit Digesting und geeigneten Auffüllmodi
• 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 Auffüllung sowie Einschränkungen der Zugriffskontrolle werden beim Generieren oder Importieren von Schlüsseln angegeben und sind dauerhaft an den Schlüssel gebunden, um sicherzustellen, dass der Schlüssel nicht auf andere Weise verwendet werden kann.

Zusätzlich zur obigen Liste gibt es einen weiteren Dienst, den Keymaster-Implementierungen bereitstellen, der jedoch nicht als API bereitgestellt wird: Zufallszahlengenerierung. Dies wird intern zur Generierung von Schlüsseln, Initialisierungsvektoren (IVs), zufälligem Auffüllen und anderen Elementen sicherer Protokolle verwendet, die Zufälligkeit erfordern.

Notwendige Grundelemente

Alle Keymaster-Implementierungen bieten:

• RSA
  • Unterstützung für 2048-, 3072- und 4096-Bit-Schlüssel
  • Unterstützung für den öffentlichen Exponenten F4 (2^16+1)
  • Auffüllmodi für RSA-Signierung:
    • RSASSA-PSS ( PaddingMode::RSA_PSS )
    • RSASSA-PKCS1-v1_5 ( PaddingMode::RSA_PKCS1_1_5_SIGN )
  • Digest-Modi für RSA-Signierung:
    • SHA-256
  • Auffüllmodi für RSA-Verschlüsselung/-Entschlüsselung:
    • Ungepolstert
    • RSAES-OAEP ( PaddingMode::RSA_OAEP )
    • RSAES-PKCS1-v1_5 ( PaddingMode::RSA_PKCS1_1_5_ENCRYPT )
• ECDSA
  • Unterstützt werden 224-, 256-, 384- und 521-Bit-Schlüssel unter Verwendung der NIST-Kurven P-224, P-256, P-384 bzw. P-521
  • Digest-Modi für ECDSA:
    • Kein Digest (veraltet, wird in Zukunft entfernt)
    • SHA-256
• AES
  • Es werden 128- und 256-Bit-Schlüssel unterstützt
  • CBC , CTR, ECB und GCM. Die GCM-Implementierung lässt die Verwendung von Tags mit weniger als 96 Bit oder anderen Nonce-Längen als 96 Bit nicht zu.
  • Die Auffüllmodi PaddingMode::NONE und PaddingMode::PKCS7 werden für die Modi CBC und ECB unterstützt. Ohne Auffüllung schlägt die Verschlüsselung im CBC- oder ECB-Modus fehl, wenn die Eingabe kein Vielfaches der Blockgröße ist.
• HMAC SHA-256 , mit jeder Schlüsselgröße bis zu mindestens 32 Byte.

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

Einige Grundelemente 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üsselzugangskontrolle

Hardwarebasierte Schlüssel, die niemals aus dem Gerät extrahiert werden können, bieten keine große Sicherheit, wenn ein Angreifer sie nach Belieben verwenden kann (obwohl sie sicherer sind als Schlüssel, die exfiltriert werden können ). Daher ist es von entscheidender Bedeutung, dass Keystore Zugriffskontrollen erzwingt.

Zugriffskontrollen werden als „Berechtigungsliste“ von Tag/Wert-Paaren definiert. Autorisierungs-Tags sind 32-Bit-Ganzzahlen und die Werte sind unterschiedlicher Art. Einige Tags können wiederholt werden, um mehrere Werte anzugeben. Ob ein Tag wiederholt werden darf, ist in der Dokumentation zum Tag angegeben. Beim Erstellen eines Schlüssels gibt der Aufrufer eine Berechtigungsliste an. Die dem Keystore zugrunde liegende Keymaster-Implementierung ändert die Liste, um einige zusätzliche Informationen anzugeben, z. B. ob der Schlüssel über einen Rollback-Schutz verfügt, und gibt eine „endgültige“ Autorisierungsliste zurück, die im zurückgegebenen Schlüsselblob codiert ist. Jeder Versuch, den Schlüssel für eine kryptografische Operation zu verwenden, schlägt fehl, wenn die endgültige Autorisierungsliste geändert wird.

Für Keymaster 2 und früher ist der Satz möglicher Tags in der Enumeration keymaster_authorization_tag_t definiert und dauerhaft festgelegt (kann jedoch erweitert werden). Den Namen wurde KM_TAG vorangestellt. Die oberen vier Bits der Tag-IDs werden zur Angabe des Typs verwendet.

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

Mögliche Typen sind:

ENUM : Die Werte vieler Tags werden in Enumerationen definiert. Beispielsweise sind die möglichen Werte von TAG::PURPOSE in der Aufzählung keymaster_purpose_t definiert.

ENUM_REP : Wie ENUM , außer dass das Tag in einer Autorisierungsliste wiederholt werden darf. Eine Wiederholung weist auf mehrere autorisierte Werte hin. Ein Verschlüsselungsschlüssel hat beispielsweise wahrscheinlich KeyPurpose::ENCRYPT und KeyPurpose::DECRYPT .

UINT : 32-Bit-Ganzzahlen ohne Vorzeichen. Beispiel: TAG::KEY_SIZE

UINT_REP : Wie UINT , außer dass das Tag in einer Autorisierungsliste wiederholt werden kann. Eine Wiederholung weist auf mehrere autorisierte Werte hin.

ULONG : 64-Bit-Ganzzahlen ohne Vorzeichen. Beispiel: TAG::RSA_PUBLIC_EXPONENT

ULONG_REP : Wie ULONG , außer dass das Tag in einer Autorisierungsliste wiederholt werden darf. Eine Wiederholung weist auf mehrere autorisierte Werte hin.

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

BOOL : Wahr oder falsch. Ein Tag vom Typ BOOL wird als „false“ angenommen, wenn der Tag nicht vorhanden ist, und als „wahr“, wenn er 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 Bytes. Beispiel: TAG::ROOT_OF_TRUST

Durchsetzung von Hardware vs. Software

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

Alle Implementierungen:

• Erzwingen Sie eine exakte Übereinstimmung (keine Durchsetzung) aller Berechtigungen. Autorisierungslisten in Schlüsselblobs stimmen genau mit den während der Schlüsselgenerierung zurückgegebenen Autorisierungen überein, einschließlich der Reihenfolge. Jede Nichtübereinstimmung führt zu einer Fehlerdiagnose.
• Deklarieren Sie die Berechtigungen, deren semantische Werte erzwungen werden.

Der API-Mechanismus zum Deklarieren hardwareerzwungener Autorisierungen befindet sich in der Struktur keymaster_key_characteristics_t . Es unterteilt die Autorisierungsliste in zwei Unterlisten, hw_enforced und sw_enforced . Die sichere Hardware ist dafür verantwortlich, in jedem die entsprechenden Werte zu platzieren, je nachdem, was sie durchsetzen kann.

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

Betrachten Sie beispielsweise eine TrustZone-basierte Implementierung, die das Ablaufen von Schlüsseln nicht unterstützt. Es kann weiterhin 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 Keystore nach den Schlüsselmerkmalen wird dieses Tag in der sw_enforced Liste gefunden und die sichere Hardware erzwingt die Ablaufanforderung nicht. Versuche, den Schlüssel nach Ablauf zu verwenden, werden jedoch von Keystore abgelehnt.

Wenn das Gerät dann mit sicherer Hardware aktualisiert wird, die den Ablauf unterstützt, wird bei einer Anfrage nach Schlüsselmerkmalen TAG::ORIGINATION_EXPIRE_DATETIME in der hw_enforced Liste gefunden, und Versuche, den Schlüssel nach Ablauf zu verwenden, schlagen fehl, selbst wenn der Schlüsselspeicher irgendwie unterwandert oder umgangen wird .

Weitere Informationen zum Ermitteln, ob Schlüssel hardwaregestützt sind, finden Sie unter Schlüsselbescheinigung .

Berechtigungen für die Erstellung kryptografischer Nachrichten

Die folgenden Tags werden verwendet, um die kryptografischen Eigenschaften von Vorgängen mithilfe des zugehörigen Schlüssels zu definieren: 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, was bedeutet, dass einem einzelnen Schlüssel mehrere Werte zugeordnet werden können und der zu verwendende Wert zum Zeitpunkt der Operation angegeben wird.

Zweck

Mit Schlüsseln ist eine Reihe von Zwecken verbunden, ausgedrückt als ein oder mehrere Autorisierungseinträge mit dem Tag TAG::PURPOSE , der definiert, 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. Beispielsweise ermöglicht ein RSA-Schlüssel, der sowohl zum Verschlüsseln als auch zum Signieren verwendet werden kann, einem Angreifer, der das System dazu verleiten kann, beliebige Daten zu entschlüsseln, um Signaturen zu generieren.

Import und Export

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

• Öffentliche und private Schlüsselpaare im DER-codierten PKCS#8-Format, ohne passwortbasierte Verschlüsselung
• Symmetrische Schlüssel als Rohbytes

Um sicherzustellen, dass importierte Schlüssel von sicher generierten Schlüsseln unterschieden werden können, wird TAG::ORIGIN in die entsprechende Schlüsselberechtigungsliste aufgenommen. Wenn beispielsweise ein Schlüssel in sicherer Hardware generiert wurde, wird TAG::ORIGIN mit dem Wert KeyOrigin::GENERATED in der hw_enforced Liste der Schlüsselmerkmale gefunden, während ein Schlüssel, der in sichere Hardware importiert wurde, den Wert KeyOrigin::IMPORTED hat. KeyOrigin::IMPORTED .

Benutzerauthentifizierung

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

Benutzerauthentifizierungsanforderungen werden über zwei Sätze von Tags angegeben. Der erste Satz gibt an, welcher Benutzer den Schlüssel verwenden kann:

• TAG::ALL_USERS gibt an, dass der Schlüssel von allen Benutzern verwendet werden kann. Falls vorhanden, sind TAG::USER_ID und TAG::USER_SECURE_ID nicht vorhanden.
• TAG::USER_ID hat einen numerischen Wert, der die ID des autorisierten Benutzers angibt. Beachten Sie, dass es sich hierbei um die Android-Benutzer-ID (für Mehrbenutzer) handelt, nicht um die Anwendungs-UID, und dass sie nur von nicht sicherer Software erzwungen wird. Falls vorhanden, ist TAG::ALL_USERS nicht vorhanden.
• TAG::USER_SECURE_ID verfügt über einen numerischen 64-Bit-Wert, der die sichere Benutzer-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 bereitgestellt wird.

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

• NO_AUTHENTICATION_REQUIRED gibt an, dass keine Benutzerauthentifizierung erforderlich ist, obwohl der Schlüssel weiterhin nur von Apps verwendet werden darf, die als der/die Benutzer ausgeführt werden, die durch TAG::USER_ID angegeben sind.
• TAG::AUTH_TIMEOUT ist ein numerischer Wert, der in Sekunden angibt, wie aktuell die Benutzerauthentifizierung sein muss, um die Schlüsselverwendung zu autorisieren. Dies gilt nur für Operationen mit privaten/geheimen Schlüsseln. Für Vorgänge mit öffentlichen Schlüsseln ist keine Authentifizierung erforderlich. Timeouts wirken sich nicht auf Neustarts aus; Nach einem Neustart werden alle Schlüssel „nie authentifiziert“. Das Zeitlimit kann auf einen großen Wert eingestellt werden, um anzugeben, dass eine Authentifizierung einmal pro Start erforderlich ist (2^32 Sekunden sind ~136 Jahre; vermutlich werden Android-Geräte häufiger neu gestartet).

Kundenbindung

Die Clientbindung, die Zuordnung eines Schlüssels zu einer bestimmten Clientanwendung, 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 stellt lediglich sicher, dass dieselben Blobs, die während der Schlüsselgenerierung/-import angezeigt werden, bei jeder Verwendung angezeigt werden und Byte für Byte identisch sind. Die Client-Bindungsdaten werden von Keymaster nicht zurückgegeben. Der Anrufer muss es kennen, um den Schlüssel verwenden zu können.

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

Ablauf

Keystore unterstützt die Einschränkung der Schlüsselnutzung nach Datum. Schlüsselgültigkeitsbeginn und Schlüsselablauf können mit einem Schlüssel verknüpft werden und Keymaster verweigert die Ausführung von Schlüsseloperationen, 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 „Entstehung“ und „Verwendung“ basiert darauf, ob der Schlüssel verwendet wird, um einen neuen Chiffretext/eine neue Signatur usw. zu „entstehen“ oder einen vorhandenen Chiffretext/eine neue Signatur usw. zu „verwenden“. Beachten Sie, dass diese Unterscheidung nicht für Anwendungen gilt.

Die TAG::ACTIVE_DATETIME , TAG::ORIGINATION_EXPIRE_DATETIME und TAG::USAGE_EXPIRE_DATETIME sind optional. Fehlen die Tags, wird davon ausgegangen, dass der betreffende Schlüssel immer zum Entschlüsseln/Verifizieren von Nachrichten verwendet werden kann.

Da die Wall-Clock-Zeit von der nicht sicheren Welt bereitgestellt wird, ist es unwahrscheinlich, dass die ablaufbezogenen Tags in der durch Hardware erzwungenen Liste enthalten sind. Die Hardware-Durchsetzung des Ablaufs würde erfordern, dass die sichere Welt auf irgendeine Weise vertrauenswürdige Zeit und Daten erhält, beispielsweise über ein Challenge-Response-Protokoll mit einem vertrauenswürdigen Remote-Zeitserver.

Root-of-Trust-Bindung

Keystore erfordert, dass Schlüssel an einen Vertrauensstamm gebunden sind, bei dem es sich um eine Bitfolge handelt, die der sicheren Keymaster-Hardware während des Startvorgangs, vorzugsweise vom Bootloader, bereitgestellt wird. Dieser Bitstring ist kryptografisch an jeden von Keymaster verwalteten Schlüssel gebunden.

Die Vertrauensbasis besteht aus dem öffentlichen Schlüssel, der zur Überprüfung der Signatur auf dem Boot-Image und des Sperrstatus des Geräts verwendet wird. Wenn der öffentliche Schlüssel geändert wird, um die Verwendung eines anderen Systemabbilds zu ermöglichen, oder wenn der Sperrstatus geändert wird, sind keine der durch Keymaster 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 gebootet. Ziel ist es, den Wert der softwaregesteuerten Schlüsselzugriffskontrollen zu steigern, indem es einem von einem Angreifer installierten Betriebssystem unmöglich gemacht wird, Keymaster-Schlüssel zu verwenden.

Eigenständige Schlüssel

Einige sichere Keymaster-Hardware speichert das Schlüsselmaterial möglicherweise lieber intern und gibt Handles zurück als verschlüsseltes Schlüsselmaterial. Oder es kann andere Fälle geben, in denen Schlüssel erst verwendet werden können, wenn eine andere nicht sichere oder sichere Weltsystemkomponente verfügbar ist. Mit dem Keymaster-HAL kann der Aufrufer über das Tag TAG::STANDALONE anfordern, dass ein Schlüssel „eigenständig“ ist, was bedeutet, dass keine anderen Ressourcen als der Blob und das laufende Keymaster-System erforderlich sind. Die einem Schlüssel zugeordneten Tags können überprü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 Anwendungen nicht verfügbar.

Geschwindigkeit

Bei der Erstellung kann die maximale Nutzungsgeschwindigkeit mit TAG::MIN_SECONDS_BETWEEN_OPS angegeben werden. TrustZone-Implementierungen verweigern die Durchführung kryptografischer Operationen mit diesem Schlüssel, wenn eine Operation 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 wird wahrscheinlich von begrenzter Größe sein, bietet aber Platz für mindestens 16 Einträge. Für den Fall, dass die Tabelle voll ist und keine Einträge aktualisiert oder verworfen werden können, sind sichere Hardware-Implementierungen „ausfallsicher“ und verweigern vorzugsweise alle geschwindigkeitsbegrenzten Tastenoperationen, bis einer der Einträge abläuft. Es ist akzeptabel, dass alle Einträge beim Neustart ablaufen.

Mit TAG::MAX_USES_PER_BOOT können Schlüssel auch auf n Verwendungen pro Start beschränkt werden. Dazu ist auch ein Tracking-Tisch erforderlich, der mindestens vier Schlüssel unterbringt und zudem ausfallsicher ist. Beachten Sie, dass Anwendungen keine begrenzten Schlüssel pro Start erstellen können. Diese Funktion wird nicht über Keystore verfügbar gemacht und ist für Systemvorgänge reserviert.

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

Neuaussaat 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 der Keymaster HAL eine Schnittstelle, die es dem Client ermöglicht, zusätzliche Entropie bereitzustellen, die dem Zufall beigemischt wird Zahlen generiert.

Verwenden Sie einen Hardware-Zufallszahlengenerator als primäre Seed-Quelle. Die über die externe API bereitgestellten Startdaten können nicht die einzige Zufallsquelle sein, die für die Zahlengenerierung verwendet wird. Darüber hinaus muss der verwendete Mischvorgang sicherstellen, dass die Zufallsausgabe unvorhersehbar ist, wenn eine der Startquellen unvorhersehbar ist.

Diese Funktion ist nicht für Anwendungen verfügbar, sondern wird vom Framework verwendet, das der sicheren Hardware regelmäßig zusätzliche Entropie bereitstellt, die von einer Java SecureRandom-Instanz abgerufen wird.