Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.

Diese Seite wurde von der Cloud Translation API übersetzt.

Hardwarebasierter Schlüsselspeicher

Die Verfügbarkeit einer vertrauenswürdigen Ausführungsumgebung in einem System-on-a-Chip (SoC) bietet Android-Geräten die Möglichkeit, dem Android-Betriebssystem, Plattformdiensten und sogar Drittanbieter-Apps hardwaregestützte, leistungsstarke Sicherheitsdienste zur Verfügung zu stellen. Entwickler, die die Android-spezifischen Erweiterungen suchen, sollten android.security.keystore aufrufen.

Vor Android 6.0 gab es bereits eine einfache, hardwaregestützte Crypto-Services API, die von den Versionen 0.2 und 0.3 der Keymaster Hardware Abstraction Layer (HAL) bereitgestellt wurde. Der Schlüsselspeicher unterstützte digitale Signatur- und Überprüfungsvorgänge sowie die Generierung und den Import von asymmetrischen Signaturschlüsselpaaren. Dies ist bereits auf vielen Geräten implementiert, aber es gibt viele Sicherheitsziele, die sich nicht einfach nur mit einer Signatur-API erreichen lassen. Der Keystore in Android 6.0 hat die Keystore API um eine Reihe weiterer Funktionen erweitert.

In Android 6.0 wurden dem Keystore symmetrische kryptografische Primitive, AES und HMAC sowie ein Zugriffskontrollsystem für hardwaregestützte Schlüssel hinzugefügt. Zugriffssteuerungen werden während der Schlüsselgenerierung festgelegt und während der gesamten Lebensdauer des Schlüssels erzwungen. Schlüssel können so eingeschränkt werden, dass sie nur nach der Authentifizierung des Nutzers und nur für bestimmte Zwecke oder mit bestimmten kryptografischen Parametern verwendet werden können. Weitere Informationen finden Sie auf der Seite Autorisierungs-Tags.

Neben der Erweiterung des Angebots an kryptografischen Primitiven wurden dem Keystore in Android 6.0 die folgenden Funktionen hinzugefügt:

Ein Nutzungskontrollsystem, mit dem die Schlüsselnutzung eingeschränkt werden kann, um das Risiko von Sicherheitsverletzungen durch Missbrauch von Schlüsseln zu verringern
Ein Zugriffssteuerungsschema, mit dem Schlüssel auf bestimmte Nutzer, Clients und einen bestimmten Zeitraum beschränkt werden können

In Android 7.0 wurde in Keymaster 2 die Unterstützung für die Schlüsselattestierung und die Versionsbindung hinzugefügt. Die Schlüsselattestierung bietet Public-Key-Zertifikate mit einer detaillierten Beschreibung des Schlüssels und seiner Zugriffssteuerung, damit das Vorhandensein des Schlüssels in sicherer Hardware und seine Konfiguration aus der Ferne überprüft werden können.

Bei der Versionsbindung werden Schlüssel an die Betriebssystemversion und die Patchebene gebunden. So wird verhindert, dass ein Angreifer, der eine Schwachstelle in einer alten Version des Systems oder der TEE-Software entdeckt, ein Gerät 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 Patchebene auf einem Gerät verwendet wird, das auf eine neuere Version oder Patchebene umgestellt wurde, wird der Schlüssel aktualisiert, bevor er verwendet werden kann, und die vorherige Version des Schlüssels ungültig. Wenn das Gerät aktualisiert wird, werden die Schlüssel zusammen mit dem Gerät weitergeschaltet. Wenn das Gerät jedoch auf eine vorherige Version zurückgesetzt wird, können die Schlüssel nicht mehr verwendet werden.

In Android 8.0 wurde Keymaster 3 von der alten C-Struktur-Hardware Abstraction Layer (HAL) zur C++ HAL-Schnittstelle migriert, die aus einer Definition in der neuen Hardware Interface Definition Language (HIDL) generiert wurde. Im Rahmen dieser Änderung haben sich viele Argumenttypen geändert, obwohl Typen und Methoden genau den alten Typen und HAL-Struct-Methoden entsprechen.

Zusätzlich zu dieser Schnittstellenüberprüfung wurde in Android 8.0 die Attestierungsfunktion von Keymaster 2 um die Unterstützung der ID-Attestierung erweitert. Die ID-Attestierung bietet einen eingeschränkten und optionalen Mechanismus zur starken Attestierung von Hardware-IDs wie der Geräteseriennummer, dem Produktnamen und der Smartphone-ID (IMEI / MEID). Zur Implementierung dieser Ergänzung wurde in Android 8.0 das ASN.1-Attestierungsschema geändert, um die ID-Attestierung hinzuzufügen. Keymaster-Implementierungen müssen eine sichere Möglichkeit zum Abrufen der relevanten Datenelemente finden und einen Mechanismus zum sicheren und dauerhaften Deaktivieren der Funktion definieren.

In Android 9 umfassten Updates Folgendes:

Aktualisieren auf 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 für „boot.img“ und „system.img“ separat festgelegte Versionen vorhanden sind, um unabhängige Updates zu ermöglichen

Glossar

Hier finden Sie einen kurzen Überblick über die Komponenten des Schlüsselspeichers und ihre Beziehungen.

AndroidKeystore ist die Android Framework API und ‑Komponente, die von Apps zum Zugriff auf die Keystore-Funktionen verwendet wird. Sie wird als Erweiterung der standardmäßigen Java Cryptography Architecture APIs implementiert und besteht aus Java-Code, der im eigenen Prozessbereich der App ausgeführt wird. AndroidKeystore erfüllt App-Anfragen zum Verhalten des Schlüsselspeichers, indem sie an den Schlüsselspeicher-Daemon weitergeleitet werden.

Der Keystore-Daemon ist ein Android-System-Daemon, der über eine Binder API Zugriff auf alle Keystore-Funktionen bietet. Er ist für das Speichern von „Schlüssel-Blobs“ verantwortlich, die das eigentliche geheime Schlüsselmaterial enthalten. Diese sind so verschlüsselt, dass der Schlüsselspeicher sie zwar speichern, aber nicht verwenden oder offenlegen kann.

keymasterd ist ein HIDL-Server, der Zugriff auf den Keymaster-TA gewährt. (Dieser Name ist nicht standardisiert und dient nur zu konzeptionellen Zwecken.)

Die Keymaster-TA (Trusted App) ist die Software, die in einem sicheren Kontext ausgeführt wird, meist in TrustZone auf einem ARM-SoC. Sie bietet alle sicheren Keystore-Vorgänge, hat Zugriff auf das Rohschlüsselmaterial, validiert alle Zugriffssteuerungsbedingungen für Schlüssel usw.

LockSettingsService ist die Android-Systemkomponente, die für die Nutzerauthentifizierung verantwortlich ist, sowohl für das Passwort als auch für den Fingerabdruck. Sie ist nicht Teil des Keystores, aber relevant, da für viele Keystore-Schlüsselvorgänge eine Nutzerauthentifizierung erforderlich ist. LockSettingsService interagiert mit dem Gatekeeper-TA und dem Fingerabdruck-TA, um Authentifizierungstokens abzurufen, die an den Keystore-Daemon übergeben und letztendlich von der Keymaster-TA-App verwendet werden.

Die Gatekeeper-TA (Trusted App) ist eine weitere Komponente, die im sicheren Kontext ausgeführt wird. Sie ist für die Authentifizierung von Nutzerpasswörtern und das Generieren von Authentifizierungstokens verantwortlich, mit denen der Keymaster-TA nachgewiesen wird, dass eine Authentifizierung für einen bestimmten Nutzer zu einem bestimmten Zeitpunkt durchgeführt wurde.

Die Fingerprint-TA (Trusted App) ist eine weitere Komponente, die im sicheren Kontext ausgeführt wird. Sie ist für die Authentifizierung von Nutzerfingerabdrücken und das Generieren von Authentifizierungstokens verantwortlich, mit denen der Keymaster-TA nachgewiesen wird, dass eine Authentifizierung für einen bestimmten Nutzer zu einem bestimmten Zeitpunkt durchgeführt wurde.

Architektur

Die Android Keystore API und die zugrunde liegende Keymaster HAL bieten eine grundlegende, aber ausreichende Reihe kryptografischer Primitive, um Protokolle mit nutzungskontrollierten, hardwaregestützten Schlüsseln zu implementieren.

Die Keymaster HAL ist eine vom OEM bereitgestellte, dynamisch ladbare Bibliothek, die vom Keystore-Dienst verwendet wird, um hardwaregestützte kryptografische Dienste bereitzustellen. Aus Sicherheitsgründen führen HAL-Implementierungen keine sensiblen Vorgänge im Nutzer- oder Kernelbereich aus. Vertrauliche Vorgänge werden an einen sicheren Prozessor delegiert, der über eine Kernel-Schnittstelle erreicht wird. Die resultierende Architektur sieht so aus:

Abbildung 1: Zugriff auf Keymaster

Auf einem Android-Gerät besteht der „Client“ der Keymaster HAL aus mehreren Schichten (z. B. App, Framework, Keystore-Daemon). Diese können jedoch für die Zwecke dieses Dokuments ignoriert werden. Das bedeutet, dass die beschriebene Keymaster HAL API Low-Level ist, von platforminternen Komponenten verwendet wird und nicht für App-Entwickler freigegeben ist. Die API der höheren Ebene wird auf der Website für Android-Entwickler beschrieben.

Der Zweck der Keymaster HAL besteht nicht darin, die sicherheitssensiblen Algorithmen zu implementieren, sondern nur, Anfragen an die sichere Welt zu marshallen und zu unmarshallen. Das Bitübertragungsformat wird von der Implementierung bestimmt.

Kompatibilität mit früheren Versionen

Die Keymaster 1 HAL ist vollständig inkompatibel mit den zuvor veröffentlichten HALs, z. B. Keymaster 0.2 und 0.3. Um die Interoperabilität auf Geräten mit Android 5.0 und niedriger zu ermöglichen, die mit den älteren Keymaster HALs eingeführt wurden, bietet Keystore einen Adapter, der die Keymaster 1 HAL mit Aufrufen der vorhandenen Hardwarebibliothek implementiert. Das Ergebnis kann nicht die gesamte Funktionalität der Keymaster 1-HAL bieten. Insbesondere werden nur RSA- und ECDSA-Algorithmen unterstützt. Die gesamte Schlüsselautorisierung wird vom Adapter in der nicht sicheren Umgebung durchgeführt.

In Keymaster 2 wurde die HAL-Oberfläche weiter vereinfacht, indem die get_supported_*-Methoden entfernt und die finish()-Methode für die Eingabe zugelassen wurde. Dadurch wird die Anzahl der TEE-Wechsel reduziert, wenn die Eingabe auf einmal verfügbar ist, und die Implementierung der AEAD-Entschlüsselung vereinfacht.

In Android 8.0 wurde Keymaster 3 von der alten C-Struktur-HAL zur C++ HAL-Schnittstelle migriert, die aus einer Definition in der neuen Hardware Interface Definition Language (HIDL) generiert wurde. Eine HAL-Implementierung des neuen Typs wird erstellt, indem die generierte IKeymasterDevice-Klasse als Unterklasse definiert und die rein virtuellen Methoden implementiert werden. Im Rahmen dieser Änderung haben sich viele der Argumenttypen geändert. Typen und Methoden entsprechen jedoch genau den alten Typen und HAL-Struct-Methoden.

HIDL – Übersicht

Die Hardware Interface Definition Language (HIDL) bietet einen implementierungsunabhängigen Mechanismus zur Angabe von Hardwareschnittstellen. Das HIDL-Tooling unterstützt derzeit die Generierung von C++- und Java-Schnittstellen. Wir gehen davon aus, dass die meisten TEE-Implementierer (Trusted Execution Environment) die C++-Tools als praktischer empfinden. Daher wird auf dieser Seite nur die C++-Darstellung behandelt.

HIDL-Schnittstellen bestehen aus einer Reihe von Methoden, die so ausgedrückt werden:

  methodName(INPUT ARGUMENTS) generates (RESULT ARGUMENTS);

Es gibt verschiedene vordefinierte Typen und HALs können neue enumerierte und Strukturtypen definieren. Weitere Informationen zu HIDL finden Sie im Referenzabschnitt.

Eine Beispielmethode aus Keymaster 3 IKeymasterDevice.hal:

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

Dies entspricht dem folgenden Code 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 wird das Argument dev entfernt, da es implizit ist. Das params-Argument ist kein Struct mehr, das einen Verweis auf ein Array von key_parameter_t-Objekten enthält, sondern ein vec (Vektor), der KeyParameter-Objekte enthält. Die Rückgabewerte sind in der Klausel „generates“ aufgeführt, einschließlich eines Vektors von uint8_t-Werten für den Schlüssel-Blob.

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

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

Dabei ist generateKey_cb ein Funktionszeiger, der so definiert ist:

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

generateKey_cb ist also eine Funktion, die die in der generate-Klausel aufgeführten Rückgabewerte verwendet. Die HAL-Implementierungsklasse überschreibt diese generateKey-Methode und ruft den generateKey_cb-Funktionspointer auf, um das Ergebnis des Vorgangs an den Aufrufer zurückzugeben. Der Funktionszeigeraufruf ist synchron. Der Aufrufer ruft generateKey auf und generateKey ruft den bereitgestellten Funktionszeiger auf, der bis zum Ende ausgeführt wird. Die Steuerung wird dann an die generateKey-Implementierung zurückgegeben, die dann an den Aufrufer zurückgibt.

Ein detailliertes Beispiel finden Sie in der Standardimplementierung in hardware/interfaces/keymaster/3.0/default/KeymasterDevice.cpp. Die Standardimplementierung bietet Abwärtskompatibilität für Geräte mit alten HALs vom Typ „keymaster0“, „keymaster1“ oder „keymaster2“.

Zugriffssteuerung

Die grundlegendste Regel der Keystore-Zugriffssteuerung ist, dass jede App ihren eigenen Namespace hat. Aber für jede Regel gibt es eine Ausnahme. Der Keystore enthält einige hartcodierte Zuordnungen, die es bestimmten Systemkomponenten ermöglichen, auf bestimmte andere Namespaces zuzugreifen. Dies ist ein sehr grobes Instrument, da es einer Komponente die vollständige Kontrolle über einen anderen Namespace gibt. Und dann gibt es noch die Frage der Anbieterkomponenten als Kunden des Keystores. Derzeit ist es nicht möglich, einen Namensbereich für Anbieterkomponenten wie WPA-Supplicant festzulegen.

Um Anbieterkomponenten zu berücksichtigen und die Zugriffssteuerung ohne hartcodierte Ausnahmen zu verallgemeinern, werden in Keystore 2.0 Domains und SELinux-Namespaces eingeführt.

Schlüsselspeicherdomains

Mit Keystore-Domains können wir Namespaces von UIDs entkoppeln. Clients, die auf einen Schlüssel im Keystore zugreifen, müssen die Domain, den Namespace und den Alias angeben, auf den sie zugreifen möchten. Anhand dieses Tupels und der Identität des Aufrufers können wir ermitteln, auf welchen Schlüssel der Aufrufer zugreifen möchte und ob er die entsprechenden Berechtigungen hat.

Wir führen fünf Domainparameter ein, die festlegen, wie auf Schlüssel zugegriffen werden kann. Sie steuern die Semantik des Namespaceparameters des Schlüssel-Descriptors und die Zugriffssteuerung.

DOMAIN_APP: Die App-Domain deckt das bisherige Verhalten ab. Die Java Keystore SPI verwendet diese Domain standardmäßig. Wenn diese Domain verwendet wird, wird das Namespace-Argument ignoriert und stattdessen die UID des Aufrufers verwendet. Der Zugriff auf diese Domain wird durch das Keystore-Label für die Klasse keystore_key in der SELinux-Richtlinie gesteuert.
DOMAIN_SELINUX: Diese Domain gibt an, dass der Namespace ein Label in der SELinux-Richtlinie hat. Der Namespaceparameter wird abgerufen und in einen Zielkontext umgewandelt. Außerdem wird eine Berechtigungsprüfung für den aufrufenden SELinux-Kontext für die keystore_key-Klasse durchgeführt. Wenn die Berechtigung für den jeweiligen Vorgang festgelegt wurde, wird das vollständige Tupel für die Schlüsselsuche verwendet.
DOMAIN_GRANT: Die Grant-Domain gibt an, dass der Namespaceparameter eine Grant-ID ist. Der Aliasparameter wird ignoriert. SELinux-Prüfungen werden beim Erstellen der Berechtigung durchgeführt. Bei der weiteren Zugriffssteuerung wird nur geprüft, ob die UID des Aufrufers mit der UID des Begünstigten der angeforderten Berechtigung übereinstimmt.
DOMAIN_KEY_ID: Diese Domain gibt an, dass der Namespaceparameter eine eindeutige Schlüssel-ID ist. Der Schlüssel selbst wurde möglicherweise mit DOMAIN_APP oder DOMAIN_SELINUX erstellt. Die Berechtigungsprüfung wird durchgeführt, nachdem domain und namespace aus der Schlüsseldatenbank geladen wurden, genau wie wenn das Blob durch das Tupel „Domain, Namespace und Alias“ geladen wurde. Die Domain für die Schlüssel-ID dient der Kontinuität. Wenn Sie über einen Alias auf einen Schlüssel zugreifen, können nachfolgende Aufrufe auf andere Schlüssel angewendet 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 anhand der Schlüssel-ID verwenden, nachdem er einmal über den Alias aus der Schlüsselspeicherdatenbank geladen wurde, können Sie sicher sein, dass es sich um denselben Schlüssel handelt, solange die Schlüssel-ID noch vorhanden ist. Diese Funktion ist für App-Entwickler nicht sichtbar. Stattdessen wird er im Android Keystore SPI verwendet, um für eine einheitlichere Nutzung zu sorgen, auch wenn er gleichzeitig auf unsichere Weise verwendet wird.
DOMAIN_BLOB: Die Blob-Domain gibt an, dass der Aufrufer den Blob selbst verwaltet. Diese Option wird für Clients verwendet, die vor dem Bereitstellen der Datenpartition auf den Schlüsselspeicher zugreifen müssen. Der Schlüssel-Blob ist im Feld blob des Schlüssel-Descriptors enthalten.

Mit der SELinux-Domain können wir Anbieterkomponenten Zugriff auf sehr spezifische Keystore-Namespaces gewähren, die von Systemkomponenten wie dem Einstellungsdialogfeld gemeinsam genutzt werden können.

SELinux-Richtlinie für „keystore_key“

Namespace-Labels werden über die Datei keystore2_key_context konfiguriert.
Jede Zeile in diesen Dateien ordnet einer numerischen Namespace-ID ein SELinux-Label zu. 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üssel-Namespace eingerichtet haben, können wir durch Hinzufügen einer geeigneten Richtlinie Zugriff darauf gewähren. Wenn wpa_supplicant beispielsweise Schlüssel im neuen Namespace abrufen und verwenden soll, fügen wir hal_wifi_supplicant.te die folgende Zeile hinzu:

allow hal_wifi_supplicant wifi_key:keystore2_key { get, use };

Nach der Einrichtung des neuen Namespaces kann AndroidKeyStore fast wie gewohnt verwendet werden. Der einzige Unterschied besteht darin, dass die Namespace-ID angegeben werden muss. Beim Laden und Importieren von Schlüsseln aus und in den Schlüsselspeicher wird die Namespace-ID mithilfe von AndroidKeyStoreLoadStoreParameter angegeben. Beispiel:

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

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

Wenn Sie einen Schlüssel in einem bestimmten Namespace generieren möchten, muss die Namespace-ID mit KeyGenParameterSpec.Builder#setNamespace(): angegeben werden.

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

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

Partition	Bereich	Konfigurationsdateien
System	0 bis 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
Vendor	30.000 … 39.999	/vendor/etc/selinux/vendor_keystore2_key_contexts, /vendor_keystore2_key_contexts

Der Client fordert den Schlüssel an, indem er die SELinux-Domain und den gewünschten virtuellen Namespace, in diesem Fall "wifi_key", anhand seiner numerischen ID anfordert.

Darüber hinaus wurden die folgenden Namespaces definiert. Wenn sie spezielle Regeln ersetzen, ist in der folgenden Tabelle die UID angegeben, der sie zuvor entsprochen haben.

Namespace-ID	SEPolicy-Label	UID	Beschreibung
0	su_key	–	Superuser-Schlüssel. Wird nur für Tests auf userdebug- und eng-Builds verwendet. Nicht relevant für Nutzerbuilds.
1	shell_key	–	Namespace, der für die Shell verfügbar ist. Wird hauptsächlich für Tests verwendet, kann aber auch über die Befehlszeile für Nutzerbuilds verwendet werden.
100	vold_key	–	Für die Verwendung durch vold gedacht.
101	odsing_key	–	Wird vom On-Device-Signatur-Daemon verwendet.
102	wifi_key	AID_WIFI(1010)	Wird vom WLAN-Subsystem von Android einschließlich wpa_supplicant verwendet.
120	resume_on_reboot_key	AID_SYSTEM(1000)	Wird vom Systemserver von Android verwendet, um die Wiederaufnahme nach dem Neustart zu unterstützen.

Zugriffsvektoren

Die SELinux-Klasse keystore_key ist schon ziemlich alt und einige Berechtigungen wie verify oder sign haben ihre Bedeutung verloren. Hier sind die neuen Berechtigungen keystore2_key, die von Keystore 2.0 erzwungen werden.

Berechtigung	Bedeutung
`delete`	Wird geprüft, wenn Schlüssel aus dem Schlüsselspeicher entfernt werden.
`get_info`	Wird geprüft, wenn die Metadaten eines Schlüssels angefordert werden.
`grant`	Der Aufrufer benötigt diese Berechtigung, um eine Berechtigung für den Schlüssel im Zielkontext zu erstellen.
`manage_blob`	Der Aufrufer kann `DOMAIN_BLOB` für den angegebenen SELinux-Namespace verwenden und Blobs so selbst verwalten. Das ist besonders für gewaltverherrlichende Inhalte nützlich.
`rebind`	Mit dieser Berechtigung wird festgelegt, ob ein Alias einem neuen Schlüssel neu zugewiesen werden kann. Dies ist für das Einfügen erforderlich und bedeutet, dass der zuvor verknüpfte Schlüssel gelöscht wird. Es handelt sich um eine Insert-Berechtigung, die die Semantik des Schlüsselspeichers jedoch besser erfasst.
`req_forced_op`	Clients mit dieser Berechtigung können nicht kürzbare Vorgänge erstellen. Die Vorgangserstellung schlägt nur dann fehl, wenn alle Vorgangsslots von nicht kürzbaren Vorgängen belegt sind.
`update`	Erforderlich, um die Unterkomponente eines Schlüssels zu aktualisieren.
`use`	Wird beim Erstellen eines Keymint-Vorgangs geprüft, bei dem das Schlüsselmaterial verwendet wird, z. B. für die Signatur, Verschlüsselung oder Entschlüsselung.
`use_dev_id`	Erforderlich, wenn Informationen zur Geräteidentifikation generiert werden, z. B. die Attestierung der Geräte-ID.

Außerdem haben wir eine Reihe nicht schlüsselspezifischer Schlüsselspeicherberechtigungen in der SELinux-Sicherheitsklasse keystore2 unterteilt:

Berechtigung	Bedeutung
`add_auth`	Erforderlich für Authentifizierungsanbieter wie Gatekeeper oder BiometricsManager zum Hinzufügen von Authentifizierungstokens.
`clear_ns`	Diese Berechtigung, die früher „clear_uid“ hieß, ermöglicht es Nutzern, die nicht Inhaber eines Namespaces sind, alle Schlüssel in diesem Namespace zu löschen.
`list`	Vom System für die Aufzählung von Schlüsseln nach verschiedenen Eigenschaften wie Inhaberschaft oder Authentifizierungsbeschränkung erforderlich. Diese Berechtigung ist für Aufrufer, die ihre eigenen Namespaces auflisten, nicht erforderlich. Das ist durch die Berechtigung `get_info` abgedeckt.
`lock`	Mit dieser Berechtigung können Sie den Schlüsselspeicher sperren, d. h. den Masterschlüssel entfernen, sodass authentifizierte Schlüssel unbrauchbar und nicht mehr erstellbar werden.
`reset`	Mit dieser Berechtigung kann der Schlüsselspeicher auf die Werkseinstellungen zurückgesetzt werden. Dabei werden alle Schlüssel gelöscht, die nicht für die Funktion des Android-Betriebssystems erforderlich sind.
`unlock`	Diese Berechtigung ist erforderlich, um den Masterschlüssel für authentifizierte Schlüssel zu entsperren.