Hardwaregestützter Schlüsselspeicher

Die Verfügbarkeit einer vertrauenswürdigen Ausführungsumgebung in einem System-on-a-Chip (SoC) bietet Android-Geräten die Möglichkeit, hardwaregestützte, starke Sicherheitsdienste für das Android-Betriebssystem, Plattformdienste und sogar Apps von Drittanbietern bereitzustellen. Entwickler der Android-spezifische Erweiterungen suchen , sollten gehen android.security.keystore .

Vor Android 6.0 verfügte Android bereits über eine einfache, hardwaregestützte Kryptodienst-API, die von den Versionen 0.2 und 0.3 des Keymaster Hardware Abstraction Layer (HAL) bereitgestellt wurde. Keystore bietet digitale Signatur- und Verifizierungsvorgänge sowie die Generierung und den Import von asymmetrischen Signaturschlüsselpaaren. Dies ist bereits auf vielen Geräten implementiert, jedoch gibt es viele Sicherheitsziele, die mit einer Signatur-API nicht ohne weiteres erreicht werden können. Keystore in Android 6.0 hat die Keystore-API erweitert, um eine breitere Palette von Funktionen bereitzustellen.

In Android 6.0 hinzugefügt Schlüsselspeicher symmetrische Verschlüsselungs Primitiven , AES und HMAC, und ein Zugangskontrollsystem für Hardware-unterstützte Tasten. Zugriffskontrollen werden während der Schlüsselgenerierung festgelegt und für die Lebensdauer des Schlüssels durchgesetzt. Schlüssel können nur nach Authentifizierung des Benutzers und nur für bestimmte Zwecke oder mit bestimmten kryptografischen Parametern verwendet werden. Weitere Informationen finden Sie in den Authorization Stichworte und Funktionen Seiten.

Zusätzlich zur Erweiterung des Angebots an kryptografischen Primitiven hat Keystore in Android 6.0 Folgendes hinzugefügt:

  • Ein Nutzungskontrollschema, mit dem die Schlüsselnutzung eingeschränkt werden kann, um das Risiko einer Sicherheitsverletzung durch Missbrauch von Schlüsseln zu mindern
  • Ein Zugriffskontrollschema, um die Beschränkung von Schlüsseln auf bestimmte Benutzer, Clients und einen definierten Zeitraum zu ermöglichen

In Android 7.0 hat Keymaster 2 die Unterstützung für die Schlüsselbestätigung und die Versionsbindung hinzugefügt. Key Bescheinigung bietet Public - Key - Zertifikate , die eine detaillierte Beschreibung des Schlüssels und seine Zugangskontrollen enthalten, den Schlüssels des Existenz in sicherer Hardware und deren Konfiguration der Ferne überprüfbar zu machen.

Version Bindung binden Schlüssel für das Betriebssystem und Patch - Level - Version. Dadurch wird sichergestellt, dass ein Angreifer, der eine Schwachstelle in einer alten Version des Systems oder der TEE-Software entdeckt, ein Gerät nicht auf die anfällige Version zurücksetzen und mit der neueren Version erstellte Schlüssel verwenden kann. Wenn ein Schlüssel mit einer bestimmten Version und einem bestimmten Patch-Level auf einem Gerät verwendet wird, das auf eine neuere Version oder Patch-Level aktualisiert wurde, wird der Schlüssel außerdem aktualisiert, bevor er verwendet werden kann, und die vorherige Version des Schlüssels wird ungültig gemacht. Wenn das Gerät aktualisiert wird, "rasten" die Schlüssel zusammen mit dem Gerät vorwärts, aber jede Rückstellung des Geräts auf eine frühere Version führt dazu, dass die Schlüssel unbrauchbar werden.

In Android 8.0 wechselte Keymaster 3 von der alten C-Struktur Hardware Abstraction Layer (HAL) auf die C++ HAL-Schnittstelle, die aus einer Definition in der neuen Hardware Interface Definition Language (HIDL) generiert wurde. Als Teil der Änderung haben sich viele der Argumenttypen geändert, obwohl Typen und Methoden eine Eins-zu-Eins-Entsprechung mit den alten Typen und den HAL-Strukturmethoden haben. Sehen Sie sich die Funktionen für weitere Details.

Zusätzlich zu dieser Schnittstelle Revision, Android 8.0 erweitert Bescheinigung des Keymaster 2 - Funktion Unterstützung ID Bescheinigung . Die ID-Bestätigung bietet einen eingeschränkten und optionalen Mechanismus zur starken Bestätigung von Hardware-Identifikatoren, wie z. B. Geräteseriennummer, Produktname und Telefon-ID (IMEI / MEID). Um diese Ergänzung zu implementieren, hat Android 8.0 das ASN.1-Bestätigungsschema geändert, um eine ID-Bestätigung hinzuzufügen. Keymaster-Implementierungen müssen einen sicheren Weg finden, um die relevanten Datenelemente abzurufen, sowie einen Mechanismus zum sicheren und dauerhaften Deaktivieren der Funktion definieren.

In Android 9 enthaltene Updates:

  • Update Keymaster 4
  • Unterstützung für eingebettete Secure Elements
  • Unterstützung für sicheren Schlüsselimport
  • Unterstützung für 3DES-Verschlüsselung
  • Änderungen an der Versionsbindung, sodass boot.img und system.img separat festgelegte Versionen haben, um unabhängige Updates zu ermöglichen

Glossar

Hier ist ein kurzer Überblick über Keystore-Komponenten und ihre Beziehungen.

AndroidKeystore ist der Android Framework - API und die Komponente von Anwendungen für den Zugriff Schlüsselspeicher - Funktionalität verwendet. Es wird als Erweiterung der Standard-APIs der Java Cryptography Architecture implementiert und besteht aus Java-Code, der im eigenen Prozessraum der App ausgeführt wird. AndroidKeystore erfüllt App - Anfragen für Schlüsselspeicher Verhalten von ihnen zu den Schlüsselspeicher - Daemon weiterzuleiten.

Der Schlüsselspeicher - Daemon ist ein Android - System - Daemon, der Zugriff auf alle Schlüsselspeicher - Funktionalität über einen bietet Binder API . Es ist für das Speichern von "Key Blobs" verantwortlich, die das eigentliche geheime Schlüsselmaterial enthalten, verschlüsselt, sodass Keystore sie speichern, aber nicht verwenden oder preisgeben kann.

keymasterd ist ein HIDL Server, der den Zugriff auf die Keymaster TA zur Verfügung stellt. (Dieser Name ist nicht standardisiert und dient konzeptionellen Zwecken.)

Keymaster TA (vertrauenswürdige Anwendung) ist die Software in einem sicheren Kontext ausgeführt wird , am häufigsten in Trustzone auf einem ARM - SoC, die mit allen von sicheren Schlüsselspeicher - Operationen bietet, hat Zugriff auf das rohe Schlüsselmaterial, überprüft alle Zugriffskontrollbedingungen auf Tasten , etc.

LockSettingsService ist die Android - System - Komponente verantwortlich für die Benutzerauthentifizierung, sowohl Passwort und Fingerabdruck. Es ist nicht Teil von Keystore, aber relevant, da viele Keystore-Schlüsseloperationen eine Benutzerauthentifizierung erfordern. LockSettingsService wirkt mit dem Torwächter TA und TA - Fingerabdruck - Authentifizierungstoken zu erhalten, die es den Schlüsselspeicher - Dämon stellt, und die durch die Anwendung Keymaster TA schließlich verbraucht werden.

Torwächter TA (vertrauenswürdige Anwendung) ist ein weiterer Baustein in dem sicheren Kontext ausgeführt wird , die für die Authentifizierung von Benutzerpassworten und zum Erzeugen von Authentifizierungs verantwortlich ist Token verwendet , um die Keymaster TA zu beweisen , dass eine Authentifizierung für einen bestimmten Benutzer zu einem bestimmten Zeitpunkt durchgeführt wurde.

Fingerabdruck - TA (vertrauenswürdige Anwendung) ist ein weitere Komponente in dem gesicherten Kontext ausgeführt wird, die für die Authentifizierung von Fingerabdruck Benutzer und zum Erzeugen von Authentifizierungs - Tokens ist verantwortlich zum Keymaster TA beweisen , dass eine Authentifizierung für einen bestimmten Benutzer an einem bestimmten Punkt in der Zeit durchgeführt wurde.

Die Architektur

Die Android Keystore API und die zugrunde liegende Keymaster HAL stellen einen grundlegenden, aber ausreichenden Satz kryptografischer Grundelemente bereit, um die Implementierung von Protokollen mit zugriffskontrollierten, hardwaregestützten Schlüsseln zu ermöglichen.

Die Keymaster HAL ist eine vom OEM bereitgestellte, dynamisch ladbare Bibliothek, die vom Keystore-Dienst verwendet wird, um hardwaregestützte kryptografische Dienste bereitzustellen. Um die Sicherheit zu gewährleisten, führen HAL-Implementierungen keine sensiblen Operationen im Benutzerbereich oder sogar im Kernelbereich aus. Sensible Operationen werden an einen sicheren Prozessor delegiert, der über eine Kernel-Schnittstelle erreicht wird. Die resultierende Architektur sieht wie folgt aus:

Zugang zu Keymaster

Abbildung 1. Der Zugang zu Keymaster

Innerhalb eines Android-Geräts besteht der „Client“ des Keymaster HAL aus mehreren Schichten (zB App, Framework, Keystore-Daemon), die jedoch für die Zwecke dieses Dokuments ignoriert werden können. Dies bedeutet, dass die beschriebene Keymaster HAL-API auf niedriger Ebene ist, von plattforminternen Komponenten verwendet wird und nicht für App-Entwickler verfügbar ist. Je höher-Level - API ist auf der beschriebenen Android Developer - Website .

Der Zweck des Keymaster HAL besteht nicht darin, die sicherheitskritischen Algorithmen zu implementieren, sondern nur, Anfragen an die sichere Welt zu ordnen und abzumelden. Das Drahtformat ist implementierungsdefiniert.

Kompatibilität mit früheren Versionen

Der Keymaster 1 HAL ist völlig inkompatibel mit den zuvor veröffentlichten HALs, zB Keymaster 0.2 und 0.3. Um die Interoperabilität auf Geräten mit Android 5.0 und früheren Versionen, die mit den älteren Keymaster-HALs gestartet wurden, zu erleichtern, bietet Keystore einen Adapter, der die Keymaster 1-HAL mit Aufrufen an die vorhandene Hardwarebibliothek implementiert. Das Ergebnis kann nicht den vollen Funktionsumfang des Keymaster 1 HAL bieten. Insbesondere unterstützt er nur RSA- und ECDSA-Algorithmen, und die gesamte Erzwingung der Schlüsselautorisierung wird vom Adapter in der nicht sicheren Welt durchgeführt.

Keymaster 2 weiter die HAL - Schnittstelle vereinfacht , indem die Entfernungs get_supported_* Methoden und ermöglicht das finish() Methode Eingabe zu akzeptieren. Dies reduziert die Anzahl der Roundtrips zum TEE in Fällen, in denen die Eingabe auf einmal verfügbar ist, und vereinfacht die Implementierung der AEAD-Entschlüsselung.

In Android 8.0 wechselte Keymaster 3 von der alten C-Struktur-HAL auf die C++ HAL-Schnittstelle, die aus einer Definition in der neuen Hardware Interface Definition Language (HIDL) generiert wurde. Ein neuer Stil HAL Implementierung wird durch Subklassen die erzeugte erstellt IKeymasterDevice Klasse und Umsetzung der rein virtuellen Methoden. Als Teil der Änderung haben sich viele der Argumenttypen geändert, obwohl Typen und Methoden eine Eins-zu-Eins-Entsprechung mit den alten Typen und den HAL-Strukturmethoden haben.

HIDL-Übersicht

Die Hardware Interface Definition Language (HIDL) stellt einen von der Implementierungssprache unabhängigen Mechanismus zum Spezifizieren von Hardwareschnittstellen bereit. Das HIDL-Tooling unterstützt derzeit die Generierung von C++- und Java-Schnittstellen. Es wird erwartet, dass die meisten Trusted Execution Environment (TEE)-Implementierer die C++-Tools bequemer finden, daher wird in diesem Dokument nur die C++-Darstellung behandelt.

HIDL-Schnittstellen bestehen aus einer Reihe von Methoden, ausgedrückt als:

  methodName(INPUT ARGUMENTS) generates (RESULT ARGUMENTS);

Es gibt verschiedene vordefinierte Typen, und HALs können neue Aufzählungs- und Strukturtypen definieren. Weitere Einzelheiten zu HIDL finden Sie im Referenzteil .

Ein beispielhaftes Verfahren der Keymaster 3 IKeymasterDevice.hal ist:

generateKey(vec<KeyParameter> keyParams)
        generates(ErrorCode error, vec<uint8_t> keyBlob,
                  KeyCharacteristics keyCharacteristics);

Dies entspricht dem Folgenden aus der keymaster2 HAL:

keymaster_error_t (*generate_key)(
        const struct keymaster2_device* dev,
        const keymaster_key_param_set_t* params,
        keymaster_key_blob_t* key_blob,
        keymaster_key_characteristics_t* characteristics);

In der HIDL Version, die dev wird Argument entfernt, weil es implizit. Die params Argument ist nicht mehr ein struct einen Zeiger referenzieren enthält ein Array von key_parameter_t Objekte, sondern eine vec (Vektor) enthält KeyParameter Objekten. Die Rückgabewerte sind in dem Abschnitt „ generates “ -Klausel, einen Vektor von einschließlich uint8_t für den Schlüssel BLOB - Werte.

Die vom HIDL-Compiler generierte virtuelle C++-Methode lautet:

Return<void> generateKey(const hidl_vec<KeyParameter>& keyParams,
                         generateKey_cb _hidl_cb) override;

Wo generate_cb ein Funktionszeiger ist wie folgt definiert:

std::function<void(ErrorCode error, const hidl_vec<uint8_t>& keyBlob,
                   const KeyCharacteristics& keyCharacteristics)>

Das heißt, generate_cb ist eine Funktion, die Rückgabewerte aufgeführt in der Erzeugung Klausel nimmt. Die HAL - Implementierungsklasse überschreibt diese generateKey Methode und ruft die generate_cb Funktionszeiger das Ergebnis der Operation an den Anrufer zurück. Beachten Sie die Funktionszeiger Anruf synchron ist. Der Anrufer ruft generateKey und generateKey ruft die bereitgestellte Funktion Zeiger, der zur Vollendung ausgeführt wird , die Steuerung an die Rückkehr generateKey Implementierung, die dann kehrt zum Aufrufer zurück .

Ein ausführliches Beispiel finden Sie in der Default - Implementierung in hardware/interfaces/keymaster/3.0/default/KeymasterDevice.cpp . Die Standardimplementierung bietet Abwärtskompatibilität für Geräte mit altmodischem keymaster0, keymaster1 oder keymaster2 HALS.

Zugangskontrolle

Die grundlegendste Regel der Keystore-Zugriffskontrolle lautet, dass jede App ihren eigenen Namespace hat. Aber für jede Regel gibt es eine Ausnahme. Keystore verfügt über einige hartcodierte Zuordnungen, die es bestimmten Systemkomponenten ermöglichen, auf bestimmte andere Namespaces zuzugreifen. Dies ist ein sehr stumpfes Instrument, da es einer Komponente die volle Kontrolle über einen anderen Namespace gibt. Und dann ist da noch die Frage der Herstellerkomponenten als Clients für Keystore. Wir haben derzeit keine Möglichkeit, einen Namensraum für Herstellerkomponenten, beispielsweise WPA-Supplicant, einzurichten.

Um Herstellerkomponenten unterzubringen und die Zugriffskontrolle ohne hartcodierte Ausnahmen zu verallgemeinern, führt Keystore 2.0 Domänen und SELinux-Namespaces ein.

Keystore-Domains

Mit Keystore-Domains können wir Namespaces von UIDs entkoppeln. Clients, die auf einen Schlüssel in Keystore zugreifen, müssen die Domäne, den Namespace und den Alias ​​angeben, auf die sie zugreifen möchten. Anhand dieses Tupels und der Identität des Anrufers können wir feststellen, auf welche Taste der Anrufer zugreifen möchte und ob er über entsprechende Berechtigungen verfügt.

Wir stellen fünf Domänenparameter vor, die bestimmen, wie auf Schlüssel zugegriffen werden kann. Sie steuern die Semantik des Namespace-Parameters des Schlüsseldeskriptors und wie die Zugriffskontrolle durchgeführt wird.

  • DOMAIN_APP : Die App - Domäne umfasst das Erbe Verhalten. Das Java Keystore SPI verwendet diese Domäne standardmäßig. Bei Verwendung dieser Domäne wird das Namespace-Argument ignoriert und stattdessen die UID des Aufrufers verwendet. Der Zugang zu diesem Bereich wird durch die Schlüsselspeicher - Label der Klasse kontrolliert keystore_key in der SELinux - Richtlinie.
  • DOMAIN_SELINUX : Dieser Bereich zeigt an, dass der Namespace ein Etikett in der SELinux - Richtlinie hat. Die Namespace - Parameter werden nachgeschlagen und in einen Zielkontext übersetzt und eine Berechtigungsprüfung für den Aufruf SELinux Kontext für die geleistete keystore_key Klasse. Wenn die Berechtigung für die angegebene Operation eingerichtet wurde, wird das vollständige Tupel für die Schlüsselsuche verwendet.
  • DOMAIN_GRANT : Die Gewährung Domäne zeigt an, dass der Namespace - Parameter ein Zuschuss Kennung ist. Der Alias-Parameter wird ignoriert. SELinux-Prüfungen werden durchgeführt, wenn die Bewilligung erstellt wird. Die weitere Zugriffskontrolle prüft nur, ob die Anrufer-UID mit der Bewilligungs-UID der beantragten Bewilligung übereinstimmt.
  • DOMAIN_KEY_ID : Dieser Bereich zeigt an, dass die Namespace - Parameter eine eindeutige Schlüssel - ID ist. Der Schlüssel selbst kann mit erstellt DOMAIN_APP oder DOMAIN_SELINUX . Die Berechtigungsprüfung wird durchgeführt , nachdem die domain und die namespace haben aus der Schlüsseldatenbank in der gleichen Art und Weise , als ob der Blob durch die Domäne, Namespace und Alias Tupel geladen wurde geladen. Die Begründung für die Schlüssel-ID-Domäne ist Kontinuität. Beim Zugriff auf einen Schlüssel über einen Alias ​​können nachfolgende Aufrufe auf anderen Schlüsseln ausgeführt werden, da möglicherweise ein neuer Schlüssel generiert oder importiert und an diesen Alias ​​gebunden wurde. Die Schlüssel-ID ändert sich jedoch nie. Wenn Sie also einen Schlüssel nach Schlüssel-ID verwenden, nachdem er einmal mit dem Alias ​​aus der Keystore-Datenbank geladen wurde, kann man sicher sein, dass es sich um denselben Schlüssel handelt, solange die Schlüssel-ID noch existiert. Diese Funktionalität ist für App-Entwickler nicht verfügbar. Stattdessen wird es innerhalb des Android Keystore SPI verwendet, um ein konsistenteres Erlebnis zu bieten, selbst wenn es gleichzeitig auf unsichere Weise verwendet wird.
  • DOMAIN_BLOB : Die Blob - Domäne zeigt an, dass der Anrufer selbst das Blob verwaltet. Dies wird für Clients verwendet, die auf den Keystore zugreifen müssen, bevor die Datenpartition gemountet wird. Der Schlüssel BLOB wird in dem mitgelieferten blob - Feld des Schlüssel Deskriptors.

Mit der SELinux-Domäne können wir Herstellerkomponenten Zugriff auf sehr spezifische Keystore-Namespaces gewähren, die von Systemkomponenten wie dem Einstellungsdialog gemeinsam genutzt werden können.

SELinux-Richtlinie für keystore_key

Namensraum - Etiketten sind konfiguriert , um die Verwendung von keystore2_key_context Datei.
Jede Zeile in diesen Dateien ordnet eine numerische Namespace-ID einem SELinux-Label zu. Zum Beispiel,

# wifi_key is a keystore2_key namespace intended to be used by wpa supplicant and
# Settings to share keystore keys.
102            u:object_r:wifi_key:s0

Nachdem wir auf diese Weise einen neuen Schlüsselnamensraum eingerichtet haben, können wir darauf zugreifen, indem wir eine entsprechende Richtlinie hinzufügen. Zum Beispiel , damit wpa_supplicant erhalten und mit den Tasten im neuen Namensraum wir die folgende Zeile würden hinzufügen hal_wifi_supplicant.te :

allow hal_wifi_supplicant wifi_key:keystore2_key { get, use };

Nach dem Einrichten des neuen Namensraums kann AndroidKeyStore fast wie gewohnt verwendet werden. Der einzige Unterschied besteht darin, dass die Namespace-ID angegeben werden muss. Zum Laden und Schlüssel aus und in den Schlüsselspeicher, die Namespace - ID wird mit angegeben , die dem Import AndroidKeyStoreLoadStoreParameter . Zum Beispiel,

import android.security.keystore2.AndroidKeyStoreLoadStoreParameter;
import java.security.KeyStore;

KeyStore keystore = KeyStore.getInstance("AndroidKeyStore");
keystore.load(new AndroidKeyStoreLoadStoreParameter(102));

Um einen Schlüssel in einem bestimmten Namensraum zu erzeugen, muss die Namespace - ID wird über die angegebenen KeyGenParameterSpec.Builder#setNamespace():

import android.security.keystore.KeyGenParameterSpec;
KeyGenParameterSpec.Builder specBuilder = new KeyGenParameterSpec.Builder();
specBuilder.setNamespace(102);

Die folgenden Kontextdateien können verwendet werden, um Keystore 2.0 SELinux-Namespaces zu konfigurieren. Jede Partition hat einen anderen reservierten Bereich von 10.000 Namespace-IDs, um Kollisionen zu vermeiden.

Partition Bereich Konfigurationsdateien
System 0 ... 9.999
/system/etc/selinux/keystore2_key_contexts, /plat_keystore2_key_contexts
Erweitertes System 10.000 ... 19.999
/system_ext/etc/selinux/system_ext_keystore2_key_contexts, /system_ext_keystore2_key_contexts
Produkt 20.000 ... 29.999
/product/etc/selinux/product_keystore2_key_contexts, /product_keystore2_key_contexts
Verkäufer 30.000 ... 39.999
/vendor/etc/selinux/vendor_keystore2_key_contexts, /vendor_keystore2_key_contexts

Der Client fordert den Schlüssel durch die SELinux - Domäne anfordert und den gewünschten virtuellen Namespace, in diesem Fall "wifi_key" durch ihre numerische ID.

Darüber hinaus wurden die folgenden Namensräume definiert. Wenn sie Sonderregeln ersetzen, gibt die folgende Tabelle die UID an, der sie früher entsprachen.

Namespace-ID SEPolicy-Label UID Beschreibung
0 su_key N / A Super-Benutzerschlüssel. Wird nur zum Testen von Userdebug- und Eng-Builds verwendet. Nicht relevant für Benutzer-Builds.
1 shell_key N / A Namespace für Shell verfügbar. Wird hauptsächlich zum Testen verwendet, kann aber auch für Benutzer-Builds über die Befehlszeile verwendet werden.
100 vold_key N / A Vorgesehen für die Verwendung von Vold.
101 odsing_key N / A Wird vom Signatur-Daemon auf dem Gerät verwendet.
102 wifi_key AID_WIFI(1010) Wird vom Wifi-System von Android verwendet, einschließlich wpa_supplicant.
120 fortsetzen_on_reboot_key AID_SYSTEM(1000) Wird vom Systemserver von Android verwendet, um die Wiederaufnahme beim Neustart zu unterstützen.

Zugriffsvektoren

Die SELinux Klasse keystore_key gealtert ist ziemlich viel , und einige der Berechtigungen, wie verify oder sign haben ihre Bedeutung verloren. Hier ist die neue Reihe von Berechtigungen, keystore2_key , dass Schlüsselspeicher 2.0 erzwingen wird.

Erlaubnis Bedeutung
delete Wird beim Entfernen von Schlüsseln aus Keystore überprüft.
get_info Wird aktiviert, wenn die Metadaten eines Schlüssels angefordert werden.
grant Der Aufrufer benötigt diese Berechtigung, um eine Gewährung des Schlüssels im Zielkontext zu erstellen.
manage_blob Der Anrufer kann verwenden DOMAIN_BLOB auf dem angegebenen SELinux - Namensraum, wodurch Blobs selbst zu verwalten. Dies ist besonders nützlich für Vold.
rebind Diese Berechtigung steuert, ob ein Alias ​​an einen neuen Schlüssel zurückgebunden werden kann. Dies ist zum Einfügen erforderlich und bedeutet, dass der zuvor gebundene Schlüssel gelöscht wird. Es handelt sich im Grunde um eine Einfügeberechtigung, die jedoch die Semantik von Keystore besser erfasst.
req_forced_op Clients mit dieser Berechtigung können nicht bereinigte Operationen erstellen, und die Erstellung von Operationen schlägt nie fehl, es sei denn, alle Operationsslots werden von nicht bereinigten Operationen belegt.
update Erforderlich, um die Unterkomponente eines Schlüssels zu aktualisieren.
use Wird beim Erstellen einer Keymint-Operation aktiviert, die das Schlüsselmaterial verwendet, z. B. zum Signieren, Ver-/Entschlüsseln.
use_dev_id Erforderlich beim Generieren von Geräteidentifizierungsinformationen, wie z. B. der Bestätigung der Geräte-ID.

Darüber hinaus teilen wir uns in der SELinux - Sicherheitsklasse eine Reihe von nicht spezifischen Schlüssel Schlüsselspeicher Berechtigungen aus keystore2 :

Erlaubnis Bedeutung
add_auth Erforderlich von Authentifizierungsanbietern wie Gatekeeper oder BiometricsManager zum Hinzufügen von Authentifizierungstoken.
clear_ns Diese Berechtigung (früher clear_uid) ermöglicht es einem Nicht-Eigentümer eines Namespaces, alle Schlüssel in diesem Namespace zu löschen.
list Wird vom System zum Aufzählen von Schlüsseln nach verschiedenen Eigenschaften benötigt, z. B. Besitz oder Beschränktheit der Authentifizierung. Diese Berechtigung wird von Aufrufern nicht benötigt, die ihre eigenen Namespaces aufzählen. Dies wird durch die überdachte get_info Erlaubnis.
lock Diese Berechtigung ermöglicht es, den Keystore zu sperren, d. h. den Hauptschlüssel zu entfernen, sodass an die Authentifizierung gebundene Schlüssel unbrauchbar und nicht erstellbar werden.
reset Diese Berechtigung ermöglicht es, Keystore auf die Werkseinstellungen zurückzusetzen und alle Schlüssel zu löschen, die für das Funktionieren des Android-Betriebssystems nicht wichtig sind.
unlock Diese Berechtigung ist erforderlich, um zu versuchen, den Hauptschlüssel für authentifizierte Schlüssel zu entsperren.