Keymaster-Funktionen

Diese Seite enthält Details für die Implementierung von Keymaster Hardware-Abstraktionsschichten (HALs). Sie behandelt jede Funktion im und in welcher Keymaster-Version beschreibt die Standardimplementierung. Informationen zu Tags finden Sie in der Keymaster-Tags.

Allgemeine Implementierungsrichtlinien

Die folgenden Richtlinien gelten für alle Funktionen der API.

Eingabezeigerparameter

Version: 1, 2

Eingabezeigerparameter, die für einen bestimmten Aufruf nicht verwendet werden, können NULL Der Aufrufer muss keine Platzhalter angeben. Beispielsweise dürfen einige Schlüsseltypen und -Modi keine Werte aus dem inParams-Argument für begin fest, sodass der Aufrufer möglicherweise Legen Sie inParams auf NULL fest oder geben Sie einen leeren Parameter an festgelegt. Aufrufer können auch nicht verwendete Parameter bereitstellen. Keymaster-Methoden sollten keine Fehler.

Wenn ein erforderlicher Eingabeparameter NULL ist, sollten Keymaster-Methoden Folgendes zurückgeben: ErrorCode::UNEXPECTED_NULL_POINTER

Ab Keymaster 3 gibt es keine Zeigerparameter. Alle Parameter werden als Wert- oder const-Verweise übergeben.

Ausgabezeigerparameter

Version: 1, 2

Ähnlich wie Eingabezeigerparameter können nicht verwendete Ausgabezeigerparameter kann NULL sein. Ob eine Methode Daten in einer Ausgabe zurückgeben muss NULL ist, sollte er Folgendes zurückgeben: ErrorCode::OUTPUT_PARAMETER_NULL.

Ab Keymaster 3 gibt es keine Zeigerparameter. Alle Parameter werden als Wert- oder const-Verweise übergeben.

API-Missbrauch

Version: 1, 2, 3

Es gibt viele Möglichkeiten, wie Aufrufer Anfragen stellen können, sind zwar töricht, aber technisch gesehen nicht falsch. Keymaster-Implementierungen die in solchen Fällen fehlschlagen oder eine Diagnose durchführen müssen. Die Verwendung von zu kleinen Tasten, Spezifikation irrelevanter Eingabeparameter, Wiederverwendung von IVs oder Nonces, ohne Zweck (also nutzlos) zu generieren. Implementierung diagnostiziert werden. Weglassen erforderlicher Parameter, Angabe von ungültige erforderliche Parameter und ähnliche Fehler müssen diagnostiziert werden.

Apps, das Framework und der Android Keystore dass die Aufrufe von Keymaster-Modulen sinnvoll und nützlich sind.

Funktionen

getHardwareFeatures

Version: 3

Die neue Methode getHardwareFeatures stellt Clients einige wichtige Merkmale der zugrunde liegenden sicheren Hardware. Die Methode akzeptiert keine Argumente und gibt vier Werte zurück, alle boolesche Werte:

  • isSecure ist true, wenn Schlüssel gespeichert sind in sichere Hardware (TEE usw.) und verlasse sie niemals.
  • supportsEllipticCurve ist true, wenn das Die Hardware unterstützt Elliptic-Curve-Kryptografie mit NIST-Kurven (P-224, P-256, P-384 und P-521).
  • „supportsSymmetricCryptography“ ist „true“ Die Hardware unterstützt symmetrische Kryptografie, einschließlich AES und HMAC.
  • supportsAttestation ist true, wenn das die Generierung von Public-Key-Attestierungszertifikaten für Keymaster unterstützt, mit einem Schlüssel signiert, der in einer sicheren Umgebung eingefügt wurde.

Die einzigen Fehlercodes, die diese Methode zurückgeben kann, sind ErrorCode:OK. ErrorCode::KEYMASTER_NOT_CONFIGURED oder einer der Fehlercodes , das auf einen Fehler bei der Kommunikation mit der sicheren Hardware hinweist. 

getHardwareFeatures()
    generates(bool isSecure, bool supportsEllipticCurve, bool supportsSymmetricCryptography,
              bool supportsAttestation, bool supportsAllDigests, string keymasterName,
              string keymasterAuthorName);

konfigurieren

Version: 2

Diese Funktion wurde in Keymaster 2 eingeführt und in Keymaster eingestellt. da diese Informationen in den Dateien mit den Systemeigenschaften verfügbar sind, und Implementierungen diese Dateien beim Start lesen.

Konfiguriert Keymaster. Diese Methode wird einmal nach dem Öffnen des Geräts aufgerufen und bevor sie verwendet wird. Sie dienen dazu, KM_TAG_OS_VERSION und KM_TAG_OS_PATCHLEVEL bis Keymaster. Bis zum Aufruf dieser Methode geben alle anderen Methoden KM_ERROR_KEYMASTER_NOT_CONFIGURED Die von diesem werden vom Keymaster nur einmal pro Start akzeptiert. Im Anschluss -Aufrufe geben KM_ERROR_OK zurück, führen aber nichts aus.

Wenn die Keymaster-Implementierung auf sicherer Hardware läuft, die Betriebssystemversion und Die angegebenen Werte auf Patchebene stimmen nicht mit den Werten überein, die für das sichere Hardware durch den Bootloader (oder wenn der Bootloader keine Werte bereitgestellt hat), gibt diese Methode KM_ERROR_INVALID_ARGUMENT zurück und alle anderen -Methoden geben weiterhin KM_ERROR_KEYMASTER_NOT_CONFIGURED zurück.

keymaster_error_t (*configure)(const struct keymaster2_device* dev,
                               const keymaster_key_param_set_t* params);

addRngEntropy

Version: 1, 2, 3

Diese Funktion wurde in Keymaster 1 als add_rng_entropy eingeführt und in Keymaster 3 umbenannt.

Fügt dem von der Keymaster 1-Implementierung verwendeten Pool die vom Anrufer bereitgestellte Entropie hinzu zum Generieren von Zufallszahlen, für Schlüssel, IVs usw.

Bei Keymaster-Implementierungen müssen die bereitgestellten Entropie in ihren Pool, der auch intern generierte Entropie von einem Hardware-Zufallszahlengenerator. Die Kombination sollte so gewählt werden, dass ein Angreifer, der die volle Kontrolle hat, der von addRngEntropy bereitgestellten Bits oder der hardwaregenerierten haben bei der Vorhersage der Bits keinen vernachlässigbaren Vorteil. die aus dem Entropiepool generiert wurden.

Keymaster-Implementierungen, die versuchen, die Entropie in ihrem dass die von ihm bereitgestellten Daten addRngEntropy enthält keine Entropie. Keymaster-Implementierungen können ErrorCode::INVALID_INPUT_LENGTH zurückgeben, wenn mehr als 2 angegeben wird KiB an Daten in einem einzelnen Aufruf.

Schlüssel generieren

Version: 1, 2, 3

Diese Funktion wurde in Keymaster 1 als generate_key eingeführt und in Keymaster 3 umbenannt.

Generiert einen neuen kryptografischen Schlüssel, der zugehörige Autorisierungen angibt, die dauerhaft an den Schlüssel gebunden sind. Mit Keymaster-Implementierungen Verwendung eines Schlüssels auf eine Weise, die den Autorisierungen nicht entspricht, ist nicht möglich. bei der Erstellung angegeben wurde. In Bezug auf Autorisierungen, die die sichere die Hardware nicht durchsetzen kann, sind die Pflichten der sicheren Hardware beschränkt auf Sie sicherstellen, dass die nicht durchsetzbaren Autorisierungen, die mit dem Schlüssel verknüpft sind, geändert werden, sodass bei jedem Aufruf getKeyCharacteristics gibt den ursprünglichen Wert zurück. Außerdem werden die von den generateKey weist Autorisierungen korrekt zwischen den hardwareerzwungene und durch Software erzwungene Listen. Weitere Informationen finden Sie unter getKeyCharacteristics.

Die für generateKey bereitgestellten Parameter hängen vom Schlüsseltyp ab generiert wird. In diesem Abschnitt werden die erforderlichen und optionalen Tags für für jeden Schlüsseltyp. Tag::ALGORITHM immer erforderlich ist, um den Typ anzugeben.

RSA-Schlüssel

Die folgenden Parameter sind erforderlich, um einen RSA-Schlüssel zu generieren.

  • Tag::KEY_SIZE gibt die Größe des öffentlichen Modulus in Bit an. Bei Auslassung gibt die Methode ErrorCode::UNSUPPORTED_KEY_SIZE zurück. Unterstützte Werte sind 1.024, 2.048, 3.072 und 4.096. Empfohlene Werte sind Schlüsselgrößen, die ein Vielfaches von 8 sind.
  • Tag::RSA_PUBLIC_EXPONENT gibt den öffentlichen RSA-Exponentenwert an. Bei Auslassung wird die Methode gibt ErrorCode::INVALID_ARGUMENT zurück. Unterstützte Werte sind 3 und 65.537. Empfohlene Werte: alle Primwerte bis 2^64.

Die folgenden Parameter sind zum Generieren eines RSA-Schlüssels nicht erforderlich, aber Wenn Sie ohne diese einen RSA-Schlüssel erstellen, ist der Schlüssel unbrauchbar. Die Die Funktion generateKey gibt keinen Fehler zurück, wenn diese Parameter werden weggelassen.

  • Mit Tag::PURPOSE wird angegeben, zulässigen Zwecken dienen. Alle Zwecke müssen für RSA-Schlüssel unterstützt werden, in einer beliebigen Kombination.
  • Mit Tag::DIGEST wird angegeben, Digest-Algorithmen, die mit dem neuen Schlüssel verwendet werden können. Implementierungen die nicht alle Digest-Algorithmen unterstützen, müssen die Schlüsselgenerierung akzeptieren Anfragen mit nicht unterstützten Digests. Die nicht unterstützten Digests sollten in der „softwareerzwungenen“ in den zurückgegebenen Schlüsselmerkmalen. Das liegt daran, dass der Schlüssel mit diesen anderen Digests verwendet werden kann, die in Software ausgeführt werden. Dann wird Hardware aufgerufen, um den Vorgang auszuführen. mit Digest::NONE.
  • Tag::PADDING steht für Folgendes: Padding-Modi, die mit dem neuen Schlüssel verwendet werden können. Implementierungen die nicht alle Digest-Algorithmen unterstützen, PaddingMode::RSA_PSS und PaddingMode::RSA_OAEP Zoll die durch die Software erzwungene Liste der Schlüsselmerkmale, falls diese nicht unterstützt werden Digest-Algorithmen angegeben sind.

ECDSA-Schlüssel

Nur Tag::KEY_SIZE ist die zum Generieren eines ECDSA-Schlüssels erforderlich sind. Damit wird die EC-Gruppe ausgewählt. Unterstützte Werte sind 224, 256, 384 und 521. NIST-Kurven p-224, p-256, p-384 und p521

Tag::DIGEST für einen nützlichen ECDSA-Schlüssel erforderlich, für die Generierung nicht erforderlich ist.

AES-Schlüssel

Nur Tag::KEY_SIZE um einen AES-Schlüssel zu generieren. Bei Auslassung gibt die Methode ErrorCode::UNSUPPORTED_KEY_SIZE Unterstützte Werte: 128 und 256, mit optionaler Unterstützung für 192-Bit-AES-Schlüssel.

Die folgenden Parameter sind insbesondere für AES-Schlüssel relevant, jedoch nicht die erforderlich sind, um eines zu generieren:

  • Tag::BLOCK_MODE gibt die Blockmodi an, mit denen kann der neue Schlüssel verwendet werden.
  • Tag::PADDING gibt die Padding-Modi an, die sein können verwendet. Dies ist nur für den ECB- und CBC-Modus relevant.

Wenn der GCM-Blockmodus angegeben ist, geben Sie Tag::MIN_MAC_LENGTH. Wenn keine Angabe gemacht wird, gibt die Methode ErrorCode::MISSING_MIN_MAC_LENGTH zurück. Der Wert des Tags ist ein Vielfaches von 8 und liegt zwischen 96 und 128.

HMAC-Schlüssel

Die folgenden Parameter sind für die Generierung von HMAC-Schlüsseln erforderlich:

  • Tag::KEY_SIZE gibt die Schlüsselgröße in Bit an. Werte kleiner als 64 und Werte, die kein Vielfaches von 8 sind, werden nicht unterstützt. Alle Vielfache von 8 von 64 bis 512 werden unterstützt. Größere Werte können unterstützt.
  • Tag::MIN_MAC_LENGTH gibt die Mindestlänge der MACs, die mit diesem Schlüssel generiert oder überprüft werden können. Der Wert ist ein Vielfaches von 8 und mindestens 64.
  • Tag::DIGEST gibt den Digest-Algorithmus für den Schlüssel an. Genau Ein Digest ist angegeben, andernfalls wird zurückgegeben: ErrorCode::UNSUPPORTED_DIGEST Wenn der Digest nicht unterstützt wird durch Trustlet, Rückgabe ErrorCode::UNSUPPORTED_DIGEST

Hauptmerkmale

Wenn das Argument für die Eigenschaften nicht NULL ist, gibt generateKey den folgenden Wert zurück: die Eigenschaften des neu generierten Schlüssels entsprechend hardwareerzwungene und durch Software erzwungene Listen. Weitere Informationen finden Sie unter getKeyCharacteristics für eine Beschreibung welche Eigenschaften in welche Liste aufgenommen werden sollen. Die zurückgegebenen Merkmale Alle für die Schlüsselgenerierung angegebenen Parameter einschließen, außer Tag::APPLICATION_ID und Tag::APPLICATION_DATA Wenn diese Tags in den Schlüsselparametern enthalten waren, werden sie aus den der zurückgegebenen Merkmale, sodass es nicht möglich ist, ihre Werte zu finden. indem Sie das zurückgegebene Schlüssel-BLOB untersuchen. Sie sind jedoch kryptografisch gebunden. in das Schlüssel-Blob ein, sodass bei nicht korrekten Werten beim Schlüssel verwendet wird, schlägt die Nutzung fehl. In ähnlicher Weise Tag::ROOT_OF_TRUST ist kryptografisch an den Schlüssel gebunden, kann aber während Schlüsselerstellung oder -import und wird nie zurückgegeben.

Zusätzlich zu den bereitgestellten Tags enthält das Trustlet auch fügt Tag::ORIGIN hinzu, mit dem Wert KeyOrigin::GENERATED, Wenn der Schlüssel Rollback-resistent ist,

Tag::ROLLBACK_RESISTANT

Rollback-Sperre

Rollback-Widerstand bedeutet, dass ein Schlüssel gelöscht wird, deleteKey oder deleteAllKeys wird durch sichere Hardware garantiert. nie wieder nutzbar zu sein. Implementierungen ohne Rollback-Widerstand das generierte oder importierte Schlüsselmaterial als Schlüssel-BLOB, ein und authentifiziertes Formular erhalten. Wenn der Schlüsselspeicher das Schlüssel-BLOB löscht, ist der Schlüssel aber ein Angreifer, der zuvor das Schlüsselmaterial kann es möglicherweise auf dem Gerät wiederherstellen.

Ein Schlüssel ist Rollback-resistent, wenn die sichere Hardware garantiert, dass Schlüssel können später nicht wiederhergestellt werden. Dies geschieht in der Regel durch Speichern eines zusätzlichen Schlüssels an einem vertrauenswürdigen Ort speichern, der von einem Angreifer nicht manipuliert werden kann. An wird der Mechanismus hierfür in der Regel "Geschützten Speicher erneut abspielen" Blocks (RPMB): Da die Anzahl der Schlüssel, die erstellt werden können, im Wesentlichen unbegrenzt und der vertrauenswürdige Speicher, der für die Widerstandsfähigkeit gegen Rollbacks verwendet wird, ist möglicherweise begrenzt muss diese Methode auch dann erfolgreich sein, wenn ein Rollback-Widerstand besteht. kann für den neuen Schlüssel nicht angegeben werden. In diesem Fall Tag::ROLLBACK_RESISTANT sollten nicht zu den Hauptmerkmalen hinzugefügt werden.

getKeyCharacteristics

Version: 1, 2, 3

Diese Funktion wurde in Keymaster 1 als get_key_characteristics und in Keymaster 3 umbenannt.

Gibt Parameter und Autorisierungen zurück, die mit dem bereitgestellten Schlüssel verknüpft sind, in zwei Gruppen unterteilt: hardware- und softwaregesteuert. Die Beschreibung gilt gleichermaßen für die Listen der Schlüsselmerkmale, die von generateKey und importKey zurückgegeben werden.

Wenn Tag::APPLICATION_ID bei der Schlüsselgenerierung angegeben wurde oder importieren, wird derselbe Wert im Argument clientId an. Andernfalls wird der gibt ErrorCode::INVALID_KEY_BLOB zurück. In ähnlicher Weise wenn Tag::APPLICATION_DATA bei der Generierung angegeben wurde oder importieren, wird derselbe Wert im Argument appData an.

Die von dieser Methode zurückgegebenen Merkmale beschreiben den Typ vollständig und Verwendung des angegebenen Schlüssels.

Die allgemeine Regel, die entscheidet, ob ein bestimmtes Tag in den Hardware- oder Softwareerzwungene Liste bedeutet, wird vollständig durch sichere Hardware gesichert und die Hardware wird erzwungen. Andernfalls erzwungen wird. Unten sehen Sie eine Liste der Tags, deren ist möglicherweise unklar:

  • Tag::ALGORITHM, Tag::KEY_SIZE, und Tag::RSA_PUBLIC_EXPONENT sind unveränderliche Eigenschaften des Schlüssels. Für jeden Schlüssel, der mit Hardware gesichert ist, werden diese Tags in der Liste mit erzwungener Hardware aufgeführt.
  • Tag::DIGEST-Werte die von der sicheren Hardware unterstützt werden, befinden sich Hardware-Liste unterstützt. Nicht unterstützte Digests werden in der Liste der softwareunterstützten Digests aufgeführt.
  • Tag::PADDING-Werte werden in der Regel in die Liste der hardwareunterstützten Inhalte aufgenommen, es sei denn, es gibt die Möglichkeit, dass ein bestimmter Padding-Modus von der Software ausgeführt werden muss. In diesem Fall werden sie in die Liste mit erzwungener Software aufgenommen. Eine solche Möglichkeit ergibt sich für RSA-Schlüssel, die PSS- oder OAEP-Padding mit Digest-Algorithmen zulassen die nicht von der sicheren Hardware unterstützt werden.
  • Tag::USER_SECURE_ID und Tag::USER_AUTH_TYPE werden nur hardwareerzwungen, wenn die Nutzerauthentifizierung hardwareerzwingt. Bis das Keymaster-Trustlet und die entsprechende Authentifizierung Trustlet muss sicher sein und einen geheimen HMAC-Schlüssel gemeinsam nutzen, Authentifizierungstokens validieren. Weitere Informationen finden Sie in der Authentifizierung.
  • Tag::ACTIVE_DATETIME Tag::ORIGINATION_EXPIRE_DATETIME, und Tag::USAGE_EXPIRE_DATETIME-Tags eine nachweislich korrekte Wanduhr erforderlich ist. Sicherste Hardware Zugriff auf Zeitinformationen hat, die vom nicht sicheren Betriebssystem bereitgestellt werden, bedeutet, dass die Tags durch Software erzwungen werden.
  • Tag::ORIGIN ist immer in der Hardwareliste für hardwaregebundene Schlüssel. Ihre Präsenz in diesen Bereichen ist die Art und Weise, wie höhere Schichten bestimmen, dass ein Schlüssel hardware-gestützt ist.

Importschlüssel

Version: 1, 2, 3

Diese Funktion wurde in Keymaster 1 als import_key eingeführt und in Keymaster 3 umbenannt.

Importiert Schlüsselmaterial in die Keymaster-Hardware. Wichtige Definitionsparameter und wie die Ausgabeeigenschaften behandelt werden wie für generateKey, mit folgenden Ausnahmen:

  • Tag::KEY_SIZE und Tag::RSA_PUBLIC_EXPONENT (nur für RSA-Schlüssel) sind bei den Eingabeparametern nicht erforderlich. Falls nicht angegeben, Das Trustlet leitet die Werte aus dem bereitgestellten Schlüsselmaterial ab und fügt Tags und Werte mit den Schlüsselmerkmalen verknüpfen. Wenn die Parameter werden sie vom Trustlet anhand des Schlüsselmaterials validiert. Im einer Abweichung gibt die Methode ErrorCode::IMPORT_PARAMETER_MISMATCH zurück.
  • Das zurückgegebene Tag::ORIGIN enthält denselben Wert wie KeyOrigin::IMPORTED.

Exportschlüssel

Version: 1, 2, 3

Diese Funktion wurde in Keymaster 1 als export_key eingeführt und in Keymaster 3 umbenannt.

Exportiert einen öffentlichen Schlüssel aus einem Keymaster-RSA- oder EC-Schlüsselpaar.

Wenn Tag::APPLICATION_ID bei der Schlüsselgenerierung oder wird dieser Methode in der Methode clientId-Argument Andernfalls gibt die Methode ErrorCode::INVALID_KEY_BLOB Gleichermaßen gilt: Tag::APPLICATION_DATA beim Generieren oder Importieren bereitgestellt wurde, wird derselbe Wert im Argument appData an.

Schlüssel löschen

Version: 1, 2, 3

Diese Funktion wurde in Keymaster 1 als delete_key eingeführt und in Keymaster 3 umbenannt.

Löscht den angegebenen Schlüssel. Diese Methode ist optional und nur die von Keymaster-Modulen implementiert wurden, die Rollbacks verhindern.

deleteAllKeys

Version: 1, 2, 3

Diese Funktion wurde in Keymaster 1 als delete_all_keys eingeführt und in Keymaster 3 umbenannt.

Löscht alle Schlüssel. Diese Methode ist optional und nur implementiert von Keymaster-Modulen, die Rollbacks verhindern.

LöschenAttestationIds

Version: 3

Die Methode destroyAttestationIds() wird verwendet, um das neue deaktivieren (optional, aber dringend empfohlen) ID-Attestierung . Wenn der TEE nicht sicherstellen kann, dass die Bestätigung per Ausweis dauerhaft erfolgt deaktiviert ist, darf die ID-Attestierung nicht implementiert werden. In diesem Fall passiert mit dieser Methode nichts gibt ErrorCode::UNIMPLEMENTED zurück. Wenn die ID-Attestierung unterstützt, muss diese Methode implementiert und dauerhaft deaktiviert werden. alle zukünftigen ID-Attestierungsversuche. Die Methode kann beliebig viele Mal. Wenn die ID-Attestierung bereits dauerhaft deaktiviert ist, tut die Methode nichts und gibt ErrorCode::OK zurück.

Die einzigen Fehlercodes, die diese Methode zurückgeben kann, sind ErrorCode::UNIMPLEMENTED (wenn die ID-Attestierung nicht unterstützt wird) ErrorCode:OK, ErrorCode::KEYMASTER_NOT_CONFIGURED oder Einer der Fehlercodes, der auf einen Fehler bei der Kommunikation mit dem sicheren Hardware.

beginnen

Version: 1, 2, 3

Startet einen kryptografischen Vorgang mit dem angegebenen Schlüssel für die angegebene Zweck mit den angegebenen Parametern (je nach Bedarf) und gibt ein Vorgangs-Handle, das mit update und complete verwendet wird, um den Vorgang abzuschließen. Die Vorgangs-Zugriffsnummer ist wird auch als „Challenge“ in authentifizierten Vorgängen verwendet werden. Vorgänge ist im Feld challenge der Authentifizierungstoken.

Eine Keymaster-Implementierung unterstützt mindestens 16 gleichzeitige Geschäftsabläufe. Der Schlüsselspeicher verwendet bis zu 15 Speicher, sodass ein Passwort in einem Schlüsselspeicher verwendet werden kann. Verschlüsselung. Wenn für den Schlüsselspeicher 15 Vorgänge laufen (begin hat wurde angerufen, aber finish oder abort wurden noch nicht und eine Anfrage zum Starten einer 16. erhalten, ruft er abort für den zuletzt verwendeten Vorgang, um die Anzahl der aktive Vorgänge auf 14 hoch, bevor begin zum Starten der neu angeforderter Vorgang.

Wenn Tag::APPLICATION_ID oder Tag::APPLICATION_DATA angegeben wurden Beim Generieren oder Importieren von Schlüsseln beinhalten Aufrufe an begin diese Tags mit den ursprünglich angegebenen Werten im Argument inParams auf diese Methode anwenden.

Erzwingung der Autorisierung

Bei dieser Methode werden die folgenden Schlüsselautorisierungen vom wenn sie bei der Implementierung im "hardwareerzwungenen" und ob der Vorgang kein öffentlicher Schlüssel ist. Öffentlicher Schlüssel Vorgänge, also KeyPurpose::ENCRYPT und KeyPurpose::VERIFY, mit RSA- oder EC-Schlüsseln erfolgreich sind, auch wenn die Autorisierung Anforderungen nicht erfüllt sind.

  • Tag::PURPOSE: der Zweck begin() muss einem der Zwecke entsprechen, in den Schlüsselautorisierungen, es sei denn, der angeforderte Vorgang ist ein öffentlicher Schlüssel . Wenn der angegebene Zweck nicht übereinstimmt und der Vorgang nicht Public-Key-Vorgang zurückgegeben, gibt begin ErrorCode::UNSUPPORTED_PURPOSE. Public-Key-Vorgänge sind asymmetrische Verschlüsselungs- oder Verifizierungsvorgänge.
  • Tag::ACTIVE_DATETIME kann nur erzwungen werden, wenn eine vertrauenswürdige UTC-Zeitquelle verfügbar ist. Wenn die das aktuelle Datum und die aktuelle Uhrzeit vor dem Tag-Wert liegen, gibt die Methode ErrorCode::KEY_NOT_YET_VALID
  • Tag::ORIGINATION_EXPIRE_DATETIME kann nur erzwungen werden, wenn eine vertrauenswürdige UTC-Zeitquelle verfügbar ist. Wenn die Das aktuelle Datum und die aktuelle Uhrzeit liegen nach dem Tag-Wert und der Zweck ist KeyPurpose::ENCRYPT oder KeyPurpose::SIGN, die Methode gibt ErrorCode::KEY_EXPIRED zurück.
  • Tag::USAGE_EXPIRE_DATETIME kann nur erzwungen werden, wenn eine vertrauenswürdige UTC-Zeitquelle verfügbar ist. Wenn die Das aktuelle Datum und die aktuelle Uhrzeit liegen nach dem Tag-Wert und der Zweck ist KeyPurpose::DECRYPT oder KeyPurpose::VERIFY, die Methode gibt ErrorCode::KEY_EXPIRED zurück.
  • Tag::MIN_SECONDS_BETWEEN_OPS mit einem Timer für die letzte Verwendung eines den Schlüssel. Wenn die letzte Nutzung plus der Tag-Wert kleiner als die aktuelle Zeit ist, gibt die Methode ErrorCode::KEY_RATE_LIMIT_EXCEEDED zurück. Weitere Informationen finden Sie in der Tag-Beschreibung .
  • Tag::MAX_USES_PER_BOOT mit einem sicheren Zähler verglichen, der die Verwendung des Schlüssels seit dem Booten. Wenn die Anzahl der vorherigen Verwendungen den Tag-Wert überschreitet, wird der Wert gibt ErrorCode::KEY_MAX_OPS_EXCEEDED zurück.
  • Tag::USER_SECURE_ID wird von dieser Methode nur erzwungen, wenn der Schlüssel auch Tag::AUTH_TIMEOUT. Enthält der Schlüssel beides, muss diese Methode einen gültigen Tag::AUTH_TOKEN in inParams Damit das Authentifizierungstoken gültig ist, müssen alle der folgenden muss wahr sein: <ph type="x-smartling-placeholder">
      </ph>
    • Das HMAC-Feld wird korrekt validiert.
    • Mindestens eines der folgenden Elemente Tag::USER_SECURE_ID -Werte aus dem Schlüssel mit mindestens einem der sicheren ID-Werte im Token.
    • Der Schlüssel hat ein Tag::USER_AUTH_TYPE der mit dem Authentifizierungstyp im Token übereinstimmt.

    Wenn eine dieser Bedingungen nicht erfüllt ist, gibt die Methode ErrorCode::KEY_USER_NOT_AUTHENTICATED

  • Tag::CALLER_NONCE ermöglicht es dem Aufrufer, eine Nonce oder einen Initialisierungsvektor (IV) anzugeben. Wenn der Schlüssel enthält dieses Tag nicht, aber der Aufrufer hat Tag::NONCE zu dieser Methode hinzufügen, ErrorCode::CALLER_NONCE_PROHIBITED wird zurückgegeben.
  • Tag::BOOTLOADER_ONLY gibt an, dass nur der Bootloader den Schlüssel verwenden darf. Wenn diese Methode mit einem Bootloader-Schlüssel aufgerufen, nach dem der Bootloader ausgeführt wurde, wird ErrorCode::INVALID_KEY_BLOB zurückgegeben.

RSA-Schlüssel

Für alle RSA-Schlüsselvorgänge ist in inParams genau ein Padding-Modus angegeben. Falls nicht angegeben oder mehrmals angegeben, gibt die Methode ErrorCode::UNSUPPORTED_PADDING_MODE

RSA-Signatur- und ‐Bestätigungsvorgänge sowie die RSA-Verschlüsselung benötigen einen Digest und Entschlüsselungsvorgänge mit dem OAEP-Padding-Modus. In diesen Fällen kann der Anrufer gibt genau einen Digest in inParams an. Wenn nicht angegeben oder angegeben Mehr als einmal gibt die Methode ErrorCode::UNSUPPORTED_DIGEST zurück.

Vorgänge mit privatem Schlüssel (KeyPurpose::DECYPT und KeyPurpose::SIGN) brauchen eine Autorisierung für Digest und Padding, was bedeutet, dass die Schlüsselautorisierungen müssen die angegebenen Werte enthalten. Andernfalls gibt die Methode ErrorCode::INCOMPATIBLE_DIGEST oder ErrorCode::INCOMPATIBLE_PADDING. Vorgänge mit öffentlichem Schlüssel (KeyPurpose::ENCRYPT und KeyPurpose::VERIFY) sind zulässig mit nicht autorisierten Digest oder Padding.

Mit Ausnahme von PaddingMode::NONE sind alle RSA-Padding-Modi die nur für bestimmte Zwecke gelten. Genauer gesagt: PaddingMode::RSA_PKCS1_1_5_SIGN und PaddingMode::RSA_PSS unterstützen nur die Signatur und Bestätigung, während PaddingMode::RSA_PKCS1_1_1_5_ENCRYPT und PaddingMode::RSA_OAEP nur Verschlüsselung und Entschlüsselung. Die Methode gibt ErrorCode::UNSUPPORTED_PADDING_MODE zurück, wenn die Der angegebene Modus unterstützt den angegebenen Zweck nicht.

Zwischen Padding-Modi und Digests gibt es einige wichtige Interaktionen:

  • PaddingMode::NONE gibt an, dass ein „Roh“-Wert RSA-Operation ist durchgeführt wurde. Beim Signieren oder Bestätigen wird Digest::NONE der für den Digest angegeben ist. Für die Verschlüsselung ohne Padding ist kein Digest erforderlich. der Datenentschlüsselung.
  • Für das Padding von PaddingMode::RSA_PKCS1_1_5_SIGN ist ein Digest erforderlich. Die Digest kann Digest::NONE sein. In diesem Fall hat der Keymaster -Implementierung kann keine richtige PKCS#1 v1.5-Signaturstruktur aufbauen, kann die DigestInfo-Struktur nicht hinzugefügt werden. Stattdessen muss die Implementierung erstellt 0x00 || 0x01 || PS || 0x00 || M, wobei M die Variable ist. bereitgestellter Nachricht und PS ist der Padding-String. Die Größe des RSA-Schlüssels muss mindestens 11 Byte größer als die Nachricht. Andernfalls gibt die Methode ErrorCode::INVALID_INPUT_LENGTH
  • Für PaddingMode::RSA_PKCS1_1_1_5_ENCRYPT-Padding ist kein Digest erforderlich.
  • Für PaddingMode::RSA_PSS-Padding ist ein Digest erforderlich, der möglicherweise nicht Digest::NONE. Wenn Digest::NONE angegeben ist, gibt ErrorCode::INCOMPATIBLE_DIGEST zurück. Darüber hinaus enthält der Die Größe des RSA-Schlüssels muss mindestens 2 + D Byte größer als die Ausgabe sein Größe des Digests, wobei D die Größe des Digest in Byte ist. Andernfalls gibt die Methode ErrorCode::INCOMPATIBLE_DIGEST zurück. Die Salzgröße ist D.
  • Für PaddingMode::RSA_OAEP-Padding ist ein Digest erforderlich, der möglicherweise nicht Digest::NONE. Wenn Digest::NONE angegeben ist, gibt ErrorCode::INCOMPATIBLE_DIGEST zurück.

EC-Schlüssel

EC-Schlüsselvorgänge geben genau einen Padding-Modus in inParams an. Falls nicht oder mehrmals angegeben, wird die Methode gibt ErrorCode::UNSUPPORTED_PADDING_MODE zurück.

Vorgänge mit privatem Schlüssel (KeyPurpose::SIGN) erfordern eine Autorisierung von Digest und Padding, was bedeutet, dass die Schlüsselautorisierungen müssen die angegebenen Werte enthalten. Falls nicht, geben Sie ErrorCode::INCOMPATIBLE_DIGEST Vorgänge mit öffentlichem Schlüssel (KeyPurpose::VERIFY) sind mit nicht autorisiertem Digest oder Padding zulässig.

AES-Schlüssel

AES-Schlüsselvorgänge geben genau einen Blockmodus und einen Padding-Modus an in „inParams“. Wenn einer der Werte nicht angegeben oder angegeben ist als einmal, geben Sie ErrorCode::UNSUPPORTED_BLOCK_MODE oder ErrorCode::UNSUPPORTED_PADDING_MODE. Die angegebenen Modi müssen autorisiert wurde. Andernfalls gibt die Methode ErrorCode::INCOMPATIBLE_BLOCK_MODE oder ErrorCode::INCOMPATIBLE_PADDING_MODE.

Ist der Blockmodus BlockMode::GCM, inParams Tag::MAC_LENGTH angibt und der der angegebene Wert ist ein Vielfaches von 8 und nicht größer als 128 oder kleiner als der Wert von Tag::MIN_MAC_LENGTH in der Schlüsselautorisierungen. Für MAC-Längen über 128 oder ein Nicht-Vielfaches von 8, gib ErrorCode::UNSUPPORTED_MAC_LENGTH zurück. Für Werte kleiner als die Mindestlänge des Schlüssels ist, wird ErrorCode::INVALID_MAC_LENGTH zurückgegeben.

Ist der Blockmodus BlockMode::GCM oder BlockMode::CTR, muss der angegebene Padding-Modus PaddingMode::NONE sein. Für BlockMode::ECB oder BlockMode::CBC lautet der Modus möglicherweise PaddingMode::NONE oder PaddingMode::PKCS7. Wenn der Padding-Modus diese Bedingungen nicht erfüllt, wird ErrorCode::INCOMPATIBLE_PADDING_MODE zurückgegeben.

Ist der Blockmodus BlockMode::CBC, BlockMode::CTR, oder BlockMode::GCM ist ein Initialisierungsvektor oder eine Nonce erforderlich. In den meisten Fällen sollten Anrufer keine IV oder Nonce angeben. In diesem Fall Die Keymaster-Implementierung generiert eine zufällige IV oder Nonce und gibt sie über Tag::NONCE in outParams. CBC- und CTR-IVs sind 16 Byte. GCM-Nonces haben eine Größe von 12 Byte. Wenn der Schlüssel Autorisierungen enthalten Tag::CALLER_NONCE, kann der Aufrufer eine IV/Nonce mit Tag::NONCE in inParams Wenn eine Nonce angegeben wird, Tag::CALLER_NONCE nicht autorisiert ist, geben Sie ErrorCode::CALLER_NONCE_PROHIBITED zurück. Wird keine Nonce angegeben, wenn Tag::CALLER_NONCE eine zufällige IV/Nonce generieren.

HMAC-Schlüssel

HMAC-Schlüsselvorgänge geben Tag::MAC_LENGTH in inParams an. Der angegebene Wert muss ein Vielfaches von 8 sein und nicht größer als die Digest-Länge oder kleiner als der Wert von Tag::MIN_MAC_LENGTH Schlüsselautorisierungen. Für MAC-Längen, die größer als die Digest-Länge oder Nicht-Vielfaches von 8, wird ErrorCode::UNSUPPORTED_MAC_LENGTH zurückgegeben. Für Werte, die kleiner als die Mindestlänge des Schlüssels sind, wird Folgendes zurückgegeben: ErrorCode::INVALID_MAC_LENGTH

Aktualisieren

Version: 1, 2, 3

Stellt Daten zur Verarbeitung in einem laufenden Vorgang bereit, der mit begin gestartet wird. Der Vorgang wird durch den Parameter operationHandle angegeben.

Um mehr Flexibilität bei der Pufferbehandlung zu bieten, sind Implementierungen dieser Methode die Möglichkeit haben, weniger Daten zu verbrauchen, als bereitgestellt wurde. Der Anrufer ist ist für die Schleife verantwortlich, mit der die übrigen Daten bei nachfolgenden Aufrufen eingespeist werden. Die Der Umfang der verbrauchten Eingabe wird im Parameter inputConsumed zurückgegeben. Implementierungen verbrauchen immer mindestens ein Byte, es sei denn, das kann keine weiteren akzeptieren. wenn mehr als null Byte angegeben werden Byte verbraucht werden, betrachten Aufrufer dies als Fehler und brechen den Vorgang ab.

Bei Implementierungen kann auch festgelegt werden, wie viele Daten zurückgegeben werden sollen. aktualisieren. Dies ist nur für Ver- und Entschlüsselungsvorgänge relevant, Beim Signieren und bei der Bestätigung werden bis zum Fertigstellen keine Daten zurückgegeben. Geben Sie Daten so früh wie möglich zurück, anstatt sie zwischenzuspeichern.

Fehlerbehandlung

Wenn diese Methode einen anderen Fehlercode als ErrorCode::OK zurückgibt, Der Vorgang wird abgebrochen und die Vorgangs-Zugriffsnummer ungültig. Beliebig können Sie mit dieser Methode abschließen oder abbrechen, gibt ErrorCode::INVALID_OPERATION_HANDLE zurück.

Erzwingung der Autorisierung

Die Erzwingung der Schlüsselautorisierung wird hauptsächlich in begin ausgeführt. Die einzige Ausnahme ist, wenn der Schlüssel Folgendes enthält:

In diesem Fall erfordert der Schlüssel eine Autorisierung pro Vorgang und die Aktualisierung ein Tag::AUTH_TOKEN im Argument inParams. HMAC prüft, ob das Token gültig ist und enthält eine übereinstimmende sichere Nutzer-ID, die mit der Tag::USER_AUTH_TYPE und enthält die Vorgangs-Zugriffsnummer des aktuellen Vorgangs in der Challenge-Feld. Sind diese Bedingungen nicht erfüllt, ErrorCode::KEY_USER_NOT_AUTHENTICATED

Der Aufrufer stellt das Authentifizierungstoken für jeden Aufruf von update bereit und Finish (Fertigstellen). Die Implementierung muss das Token nur einmal validieren, wenn dies gewünscht wird.

RSA-Schlüssel

Bei Signatur- und Verifizierungsvorgängen mit Digest::NONE Diese Methode akzeptiert den gesamten Block zur Signatur oder Bestätigung in einem einzelnen aktualisieren. Er darf nicht nur einen Teil des Blocks verbrauchen. Wenn der Aufrufer jedoch die Daten in mehreren Updates bereitstellen, werden sie von dieser Methode akzeptiert. Wenn der Aufrufer mehr Daten zum Signieren bereitstellt, als verwendet werden können (Länge der Daten größer sind als der RSA-Schlüssel), geben Sie ErrorCode::INVALID_INPUT_LENGTH zurück.

ECDSA-Schlüssel

Bei Signatur- und Verifizierungsvorgängen mit Digest::NONE Diese Methode akzeptiert den gesamten Block zur Signatur oder Bestätigung in einem einzelnen aktualisieren. Diese Methode verbraucht möglicherweise nicht nur einen Teil des Blocks.

Wenn der Aufrufer die Daten jedoch in mehreren Updates bereitstellt, diese Methode akzeptiert. Wenn der Anrufer weitere Daten zum Unterschreiben bereitstellt als verwendet werden können, werden die Daten ohne Meldung abgeschnitten. (anders als die Umgang mit überzähligen Daten, die in ähnlichen RSA-Vorgängen bereitgestellt werden. Der Grund dafür ist, ist die Kompatibilität mit Legacy-Clients.)

AES-Schlüssel

Der AES-GCM-Modus unterstützt "Verknüpfte Authentifizierungsdaten", über das Tag::ASSOCIATED_DATA im Argument inParams. Die zugehörigen Daten können in wiederholten Aufrufen bereitgestellt werden (wichtig, wenn die Daten sind zu groß, um in einem einzelnen Block gesendet zu werden, aber Daten immer vorangestellt sind zu entschlüsseln oder zu entschlüsseln. Bei einem Aktualisierungsaufruf können beide zugehörigen Daten empfangen werden. und Daten zum Verschlüsseln bzw. Entschlüsseln. Bei nachfolgenden Aktualisierungen sind zugehörige Daten. Wenn der Anrufer nach einem Anruf in einem Update-Aufruf zugehörige Daten bereitstellt die Daten zum Verschlüsseln/Entschlüsseln enthält, wird ErrorCode::INVALID_TAG zurückgegeben.

Bei der GCM-Verschlüsselung wird das Tag durch Finish gesetzt. Während der Entschlüsselung Tag::MAC_LENGTH Byte der Daten, die der letzten "update" ist das Tag. Da ein bestimmter Aufruf von update nicht wissen, ob es sich um den letzten Aufruf handelt, werden alle Daten bis auf die Tag-Länge verarbeitet und die möglichen Tag-Daten zwischengespeichert während Finish.

Abschließen

Version: 1, 2, 3

Beendet einen laufenden Vorgang, der mit begin begonnen hat, Verarbeitung aller noch nicht verarbeiteten Daten, Aktualisierung(en).

Diese Methode ist die letzte, die in einem Vorgang aufgerufen wird. verarbeitete Daten zurückgegeben.

Ob sie erfolgreich abgeschlossen wird oder einen Fehler zurückgibt, wird mit dieser Methode abgeschlossen. Vorgang ausführen und damit die angegebene Vorgangs-Zugriffsnummer ungültig wird. Beliebig mit dieser Methode oder mit update oder abort, gibt ErrorCode::INVALID_OPERATION_HANDLE zurück.

Bei Signaturvorgängen wird die Signatur als Ausgabe zurückgegeben. Überprüfungsvorgänge die Signatur im Parameter signature akzeptieren und keine Ausgabe zurückgeben.

Erzwingung der Autorisierung

Die Erzwingung der Schlüsselautorisierung wird hauptsächlich in begin zurück. Die einzige Ausnahme ist, wenn der Schlüssel Folgendes enthält:

In diesem Fall erfordert der Schlüssel eine Autorisierung pro Vorgang und die Aktualisierung ein Tag::AUTH_TOKEN im Argument inParams. Mit HMAC wird bestätigt, dass das Token ist gültig und enthält eine entsprechende sichere Nutzer-ID, stimmt mit der ID des Schlüssels überein Tag::USER_AUTH_TYPE und enthält die Vorgangs-Zugriffsnummer des aktuellen Vorgangs in der Challenge-Feld. Sind diese Bedingungen nicht erfüllt, ErrorCode::KEY_USER_NOT_AUTHENTICATED

Der Aufrufer stellt das Authentifizierungstoken für jeden Aufruf von Aktualisieren und Beenden. Die Implementierung muss das Token nur einmal validieren, wenn dies gewünscht wird.

RSA-Schlüssel

Je nach Padding-Modus gelten einige zusätzliche Anforderungen:

  • PaddingMode::NONE Bei Signatur- und Verschlüsselungsvorgängen ohne Auffüllung Sind die bereitgestellten Daten kürzer als der Schlüssel, werden die Daten vor der Signatur/Verschlüsselung bleibt. Wenn die Daten die gleiche Länge wie der Schlüssel haben, aber numerisch größer ist, wird ErrorCode::INVALID_ARGUMENT zurückgegeben. Für Verifizierungs- und Entschlüsselungsvorgängen durchgeführt haben, müssen die Daten genau so lang sein, als Schlüssel ein. Andernfalls wird ErrorCode::INVALID_INPUT_LENGTH. zurückgegeben.
  • PaddingMode::RSA_PSS Für mit PSS aufgefüllte Signaturvorgänge PSS-Salt ist die Größe des Nachrichten-Digests und wird zufällig generiert. Der mit Tag::DIGEST angegebene Digest in inputParams am begin wird als PSS-Digest verwendet und als MGF1-Digest-Algorithmus.
  • PaddingMode::RSA_OAEP Der Digest, der mit Tag::DIGEST in inputParams am begin wird als OAEP verwendet Hash-Algorithmus und SHA1 wird als MGF1-Digest-Algorithmus verwendet.

ECDSA-Schlüssel

Wenn die Daten für die Signatur oder Bestätigung ohne Padding zu lang sind, kürzen Sie sie. .

AES-Schlüssel

Einige zusätzliche Bedingungen, abhängig vom Blockmodus:

  • BlockMode::ECB oder BlockMode::CBC. Wenn der Abstand PaddingMode::NONE ist und der Datenlänge nicht ein Vielfaches der AES-Blockgröße ist, geben Sie ErrorCode::INVALID_INPUT_LENGTH. Wenn der Abstand PaddingMode::PKCS7, füllen Sie die Daten gemäß der PKCS#7-Spezifikation auf. PKCS#7 empfiehlt, einen zusätzlichen Padding-Block hinzuzufügen. wenn die Daten ein Vielfaches der Blocklänge sind.
  • BlockMode::GCM Während der Verschlüsselung, nach der Verarbeitung Nur Klartext, Tag berechnen (Tag::MAC_LENGTH Byte) und an den zurückgegebenen Geheimtext anhängen. Während der Entschlüsselung das letzte Tag::MAC_LENGTH Bytes als Tag verwenden. Schlägt die Tag-Überprüfung fehl, geben Sie ErrorCode::VERIFICATION_FAILED

abbrechen

Version: 1, 2, 3

Bricht den laufenden Vorgang ab. Führen Sie nach dem Abbrechen-Aufruf ErrorCode::INVALID_OPERATION_HANDLE für jede nachfolgende Verwendung des angegebenen Vorgangs-Handles mit update, Beenden oder abbrechen.

get_supported_algorithms (Unterstützte_Algorithmen)

Version: 1

Gibt die Liste der von der Keymaster-Hardware unterstützten Algorithmen zurück Implementierung. Eine Softwareimplementierung gibt eine leere Liste zurück. Hybrid -Implementierung gibt eine Liste zurück, die nur die Algorithmen enthält, die von der Hardware unterstützt werden.

Keymaster 1-Implementierungen unterstützen RSA, EC, AES und HMAC.

Get_supported_block_modes

Version: 1

Gibt die Liste der von der Keymaster-Hardware unterstützten AES-Blockmodi zurück für einen bestimmten Algorithmus und Zweck.

Für RSA, EC und HMAC, bei denen es sich nicht um Blockverschlüsselungen handelt, gibt die Methode ein leere Liste für alle gültigen Zwecke. Ungültige Zwecke sollten dazu führen, dass die Methode ErrorCode::INVALID_PURPOSE zurückgeben.

Keymaster 1-Implementierungen unterstützen ECB, CBC, CTR und GCM für AES. Verschlüsselung und Entschlüsselung.

get_supported_padding_modes

Version: 1

Gibt die Liste der Padding-Modi zurück, die von der Keymaster-Hardware unterstützt werden. für einen bestimmten Algorithmus und Zweck.

Für HMAC und EC gibt es kein Padding, daher gibt die Methode eine leere Liste zurück. für alle gültigen Zwecke. Ungültige Zwecke sollten dazu führen, dass die Methode ErrorCode::INVALID_PURPOSE

Für RSA werden Implementierungen von Keymaster 1 unterstützt:

  • Verschlüsselung, Entschlüsselung, Signatur und Überprüfung ohne Padding. Für nicht gepolsterte Verschlüsselung und Signatur, wenn die Nachricht kürzer ist als das öffentliche Datenvolumen, müssen bei Implementierungen links mit Nullen aufgefüllt werden. Für die Entschlüsselung ohne Auffüllung muss die Eingabelänge der öffentlichen Modulo-Größe entsprechen.
  • Modi für PKCS#1 v1.5-Verschlüsselung und Signierabstände
  • PSS mit einer Salzlänge von mindestens 20
  • OAEP

Bei AES im ECB- und CBC-Modus unterstützen Keymaster 1-Implementierungen keine und PKCS#7-Padding. Im CTR- und GCM-Modus wird nur kein Abstand unterstützt.

Get_supported_digests

Version: 1

Gibt die Liste der von der Keymaster-Hardware unterstützten Digest-Modi zurück für einen bestimmten Algorithmus und Zweck.

AES-Modi werden nicht unterstützt oder erfordern kein Digesting, sodass die Methode ein leeres für gültige Zwecke.

Bei Implementierungen von Keymaster 1 kann eine Teilmenge der Digests. Implementierungen bieten SHA-256, MD5, SHA1, SHA-224, SHA-256, SHA384 und SHA512 (alle definierten Digests).

get_supported_import_formats

Version: 1

Gibt die Liste der von der Keymaster-Hardware unterstützten Importformate zurück Implementierung eines angegebenen Algorithmus.

Implementierungen von Keymaster 1 unterstützen das PKCS#8-Format (ohne Passwort). -Schutz) zum Importieren von RSA- und EC-Schlüsselpaaren und unterstützen den RAW-Import von AES- und HMAC-Schlüsselmaterial.

Unterstützte Exportformate

Version: 1

Gibt die Liste der von der Keymaster-Hardware unterstützten Exportformate zurück Implementierung eines angegebenen Algorithmus.

Keymaster1-Implementierungen unterstützen das X.509-Format für den Export von RSA und Öffentliche EC-Schlüssel. Der Export von privaten Schlüsseln oder asymmetrischen Schlüsseln wird nicht unterstützt.

Historische Funktionen

Keymaster 0

Die folgenden Funktionen gehören zur ursprünglichen Definition von Keymaster 0. Sie in Keymaster 1 struct keymaster1_device_t. In Keymaster 1.0 wurden sie nicht implementiert und ihre Funktionszeiger wurden auf NULL gesetzt.

  • generate_keypair
  • import_keypair
  • get_keypair_public
  • delete_keypair
  • delete_all
  • sign_data
  • Verify_data

Keymaster 1

Die folgenden Funktionen gehören zur Definition von Keymaster 1, wurden jedoch zusammen mit den oben aufgeführten Keymaster 0-Funktionen in Keymaster 2 entfernt.

  • get_supported_algorithms
  • get_supported_block_modes
  • get_supported_padding_modes
  • get_supported_digests
  • get_supported_import_formats
  • get_supported_export_formats

Keymaster 2

Die folgenden Funktionen gehören zur Definition von Keymaster 2, wurden zusammen mit den oben aufgeführten Funktionen von Keymaster 1 entfernt.

  • configure