Verfügbarkeit einer vertrauenswürdigen Ausführungsumgebung in einem System-on-Chip (SoC) bietet Android-Geräten die Möglichkeit, hardwaregestützte, für das Android-Betriebssystem, Plattformdienste und sogar Drittanbieter-Apps. Entwickler, die nach Android-spezifischen Erweiterungen suchen, sollten auf android.security.keystore.
Vor Android 6.0 hatte Android bereits eine einfache, hardwaregestützte Kryptowährung Services API, bereitgestellt von den Versionen 0.2 und 0.3 der Keymaster Hardware Abstraktionsschicht (HAL). Von Schlüsselspeicher bereitgestellte digitale Signatur und Verifizierung sowie Generierung und Import asymmetrischer Signaturschlüsselpaare. Dies ist die auf vielen Geräten implementiert sind, aber es gibt viele Sicherheitsziele, lässt sich nicht allein mit einem Signatur-API erreichen. Schlüsselspeicher in Android 6.0 haben die Keystore API erweitert, um eine breitere Palette von Funktionen bereitzustellen.
In Android 6.0 wurde Keystore symmetrische kryptografische Primitive AES und HMAC sowie ein Zugriffssteuerungssystem für hardwaregestützte Schlüssel. Zugriff Steuerelemente werden während der Schlüsselgenerierung angegeben und für die Lebensdauer von den Schlüssel. Schlüssel können so eingeschränkt werden, dass sie nur verwendet werden können, wenn der Nutzer nur für bestimmte Zwecke oder mit spezifizierten kryptografischen Parameter. Weitere Informationen finden Sie in der Autorisierungs-Tags und Funktionen.
Neben der Erweiterung der Bandbreite an kryptografischen Primitiven bietet Keystore in Android 6.0 hat Folgendes hinzugefügt:
- Ein Nutzungskontrollschema, um die Schlüsselnutzung zu begrenzen und Risiko eines Sicherheitsrisikos durch Schlüsselmissbrauch
- Ein Zugriffskontrollschema, um die Beschränkung von Schlüsseln auf bestimmte Nutzer zu ermöglichen, und einem definierten Zeitraum
In Android 7.0 bietet Keymaster 2 nun Unterstützung für Schlüsselattestierung und -version. Bindung. Schlüsselattestierung stellt Public-Key-Zertifikate bereit, die eine detaillierte Beschreibung des Schlüssels enthalten und seiner Zugriffskontrollen, um die Existenz des Schlüssels auf sicherer Hardware und seiner Konfiguration remote überprüfbar.
Versionsbindung Bindet Schlüssel an das Betriebssystem und die Patchversion. Dadurch wird sichergestellt, ein Angreifer, der eine Schwachstelle in einer alten Version des Systems oder Die TEE-Software kann das Gerät nicht auf die anfällige Version zurücksetzen und keine Schlüssel verwenden die mit der neueren Version erstellt wurden. Wenn ein Schlüssel mit einer bestimmten Version und der Patch-Level auf einem Gerät verwendet wird, das auf eine neuere Version aktualisiert wurde. Patch- oder Patchebene wird der Schlüssel aktualisiert, bevor er verwendet werden kann, und die vorherige Version Version des Schlüssels ungültig gemacht. Wenn das Gerät aktualisiert wird, werden die Tasten mit dem Gerät vorwärts, aber bei jedem Umkehren lassen die Tasten unbrauchbar.
In Android 8.0 wurde Keymaster 3 von der alten C-Struktur-Hardware umgestellt. Abstraktionsschicht (Abstraktionsschicht, HAL) zur C++ HAL-Schnittstelle, die von einer Definition generiert wurde in der neuen Hardware Interface Definition Language (HIDL) verfügbar. Im Rahmen dieser Änderung Viele der Argumenttypen haben sich geändert, obwohl Typen und Methoden jeweils nur eine 1:1-Beziehung haben. Korrespondenz mit den alten Typen und den HAL-Struktur-Methoden. Weitere Informationen finden Sie in der Funktionen. Details.
Zusätzlich zu dieser Überarbeitung der Benutzeroberfläche wurde die zu unterstützendes Attestierungsfeature ID-Attestierung. Die ID-Attestierung bietet einen eingeschränkten und optionalen Mechanismus für starke Attestierungen auf Hardware-IDs wie die Seriennummer des Geräts, den Produktnamen oder die Telefonnummer ID (IMEI / MEID). Um diese Ergänzung zu implementieren, wurde in Android 8.0 die ASN.1 geändert. Attestierungsschema, um eine ID-Attestierung hinzuzufügen. Keymaster-Implementierungen müssen die relevanten Datenelemente sicher abrufen und einen Mechanismus zur sicheren und dauerhaften Deaktivierung der Funktion.
Android 9 umfasste folgende Updates:
- Aktualisieren auf Keymaster 4
- Unterstützung für eingebettete Secure Elements
- Unterstützung für den Import sicherer Schlüssel
- Unterstützung für 3DES-Verschlüsselung
- Änderungen an der Versionsbindung, sodass für boot.img und system.img Folgendes gilt: Versionen separat festlegen, um unabhängige Updates zu ermöglichen
Glossar
Hier erhalten Sie einen kurzen Überblick über die Schlüsselspeicherkomponenten und ihre Beziehungen.
AndroidKeystore ist die Android Framework API und die verwendete Komponente.
um auf die Schlüsselspeicherfunktionen zuzugreifen. Sie ist als Erweiterung der
standardmäßigen Java Cryptography Architecture APIs und besteht aus Java-Code, der
im eigenen Prozessbereich der App ausgeführt. AndroidKeystore
erfüllt die App
für das Verhalten des Schlüsselspeichers, indem sie an den Schlüsselspeicher-Daemon weitergeleitet werden.
Der Schlüsselspeicher-Daemon ist ein Android-System-Daemon, der Zugriff auf alle Schlüsselspeicherfunktionen über eine Binder API. Er ist für die Speicherung von Schlüssel-BLOBs zuständig, das eigentliche geheime Schlüsselmaterial enthalten, verschlüsselt, damit der Schlüsselspeicher sie speichern kann, nicht verwenden oder offenlegen.
keymasterd ist ein HIDL-Server, der Zugriff auf den Keymaster TA. (Dieser Name ist nicht standardisiert und dient nur zu konzeptionellen Zwecken.)
Keymaster TA (vertrauenswürdige Anwendung) ist die Software, die in einer in TrustZone auf einem ARM-SoC, das alle sichere Schlüsselspeichervorgänge, hat Zugriff auf das Rohschlüsselmaterial, validiert alle Bedingungen für die Zugriffssteuerung auf Tasten usw.
LockSettingsService ist die Android-Systemkomponente,
für die Nutzerauthentifizierung (Passwort und Fingerabdruck). Es gehört nicht zu
Schlüsselspeicher, der aber relevant ist, da viele Schlüsselspeicher-Schlüsselvorgänge Nutzer
Authentifizierung. LockSettingsService
interagiert mit dem Gatekeeper
TA und Fingerprint TA, um Authentifizierungs-Tokens zu erhalten, die sie dem
Schlüsselspeicher-Daemon, der letztendlich vom Keymaster TA verbraucht wird.
.
Gatekeeper TA (vertrauenswürdige Anwendung) ist eine weitere Komponente im sicheren Kontext ausgeführt, die für die Authentifizierung des Nutzers Passwörter und Generieren von Authentifizierungstokens zur Bestätigung gegenüber dem Keymaster TA dass eine Authentifizierung für einen bestimmten Nutzer zu einem bestimmten Zeitpunkt im .
Fingerprint TA (vertrauenswürdige Anwendung) ist eine weitere Komponente im sicheren Kontext ausgeführt, der für die Authentifizierung des Nutzers Fingerabdrücke generieren und Authentifizierungstokens generieren, die als Nachweis gegenüber dem Keymaster verwendet werden. TA, dass eine Authentifizierung für einen bestimmten Nutzer zu einem bestimmten Zeitpunkt durchgeführt wurde mit der Zeit kommen.
Architektur
Die Android Keystore API und der zugrunde liegende Keymaster HAL grundlegende, aber ausreichende kryptografische Primitive bereitstellen, Implementierung von Protokollen mit zugriffsgesteuerten, hardwaregestützten Schlüsseln.
Der Keymaster HAL ist eine vom OEM bereitgestellte, dynamisch ladbare Bibliothek, die von Schlüsselspeicherdienst zur Bereitstellung hardwaregestützter kryptografischer Dienste. Beibehalten sicher sind, führen HAL-Implementierungen keine sensiblen Vorgänge in User-Space oder sogar im Kernel-Bereich. Sensible Vorgänge werden an eine sicheren Prozessor, der über eine Kernel-Schnittstelle erreicht wird. Die resultierende Architektur sieht so aus:
![Zugriff auf Keymaster](https://source.android.com/static/docs/security/images/access-to-keymaster.png?authuser=2&hl=de)
Abbildung 1: Zugriff auf Keymaster
Auf einem Android-Gerät ist der „Client“ des Keymaster HAL besteht aus mehrere Schichten (z. B. App, Framework, Keystore-Daemon), die aber ignoriert werden können. für die Zwecke dieses Dokuments. Das bedeutet, dass der beschriebene Keymaster HAL API ist auf niedriger Ebene, wird von plattforminternen Komponenten verwendet und ist nicht für die App zugänglich zu entwickeln. Die übergeordnete API wird auf der Website für Android-Entwickler beschrieben.
Der Zweck des Keymaster HAL besteht nicht darin, die sicherheitsrelevante sondern nur um Anfragen in der sicheren Welt zusammenzuführen und zu verarbeiten. Die Das Überweisungsformat ist implementierungsdefiniert.
Kompatibilität mit vorherigen Versionen
Der Keymaster 1 HAL ist nicht kompatibel mit dem zuvor veröffentlichte HALs, z.B. Keymaster 0.2 und 0.3. Um die Interoperabilität auf Geräten mit Android 5.0 und niedriger, älteren Keymaster HALs bietet Keystore einen Adapter, mit dem die Keymaster 1 HAL mit Aufrufen der vorhandenen Hardwarebibliothek. Das Ergebnis darf nicht bieten alle Funktionen von Keymaster 1 HAL. Insbesondere Es unterstützt nur RSA- und ECDSA-Algorithmen sowie alle wird vom Adapter in einer unsicheren Umgebung erzwungen.
Keymaster 2 vereinfachte die HAL-Schnittstelle weiter, indem die Funktion
get_supported_*
-Methoden und zulassen, dass finish()
, um die Eingabe zu akzeptieren. Dies reduziert die Anzahl der Umläufe zum TEE in
in denen alle Eingaben auf einmal zur Verfügung stehen, und vereinfacht die
AEAD-Entschlüsselung.
In Android 8.0 ist Keymaster 3 von der alten C-Struktur übergegangen.
HAL in die C++ HAL-Schnittstelle ein, die aus einer Definition im neuen
Hardware Interface Definition Language (HIDL) Ein HAL im neuen Stil
-Implementierung erstellt, indem eine Unterklasse der generierten
IKeymasterDevice
und die Implementierung der rein virtuellen
. Im Rahmen dieser Änderung haben sich viele
Argumenttypen geändert.
Obwohl Typen und Methoden eine Eins-zu-Eins-Übereinstimmung mit den alten
und die HAL-Struktur-Methoden.
HIDL – Übersicht
Die Hardware Interface Definition Language (HIDL) bietet eine sprachunabhängigen Mechanismus zur Angabe von Hardwareschnittstellen. Das HIDL unterstützen derzeit die Generierung von C++- und Java-Schnittstellen. Erwartungsgemäß dass die meisten TEE-Implementierungen die C++- . Deshalb wird in diesem Dokument nur die C++-Darstellung behandelt.
HIDL-Schnittstellen bestehen aus einer Reihe von Methoden, die folgendermaßen ausgedrückt werden:
methodName(INPUT ARGUMENTS) generates (RESULT ARGUMENTS);
Es gibt verschiedene vordefinierte Typen und HALs können neue Strukturtypen. Weitere Informationen zum HIDL finden Sie im Abschnitt „Referenzen“.
Eine Beispielmethode der IKeymasterDevice.hal
von Keymaster 3 ist:
generateKey(vec<KeyParameter> keyParams) generates(ErrorCode error, vec<uint8_t> keyBlob, KeyCharacteristics keyCharacteristics);
Dies entspricht dem folgenden String aus dem 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. Das Argument params
ist keine Struktur mit einem
Zeiger, der auf ein Array von key_parameter_t
-Objekten verweist, aber ein
vec
(Vektor) mit KeyParameter
Objekten. Die
Rückgabewerte sind in der Spalte "generates
" Klausel, einschließlich einer
Vektor der uint8_t
-Werte für das Schlüssel-BLOB.
Die vom HIDL-Compiler generierte virtuelle C++-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)>
Das heißt, generateKey_cb
ist eine Funktion, die die Rückgabewerte
in der Generate-Klausel aufgelistet. Die HAL-Implementierungsklasse überschreibt dies
Methode generateKey
und ruft die Funktion generateKey_cb
auf
Zeiger, um das Ergebnis des Vorgangs an den Aufrufer zurückzugeben. Beachten Sie die Funktion
Der Zeigeraufruf erfolgt synchron. Der Anrufer ruft an
generateKey
und generateKey
rufen die bereitgestellten
Funktionszeiger, der bis zum Ende ausgeführt wird und die Steuerung an den
generateKey
-Implementierung, die dann an den Aufrufer zurückgegeben wird.
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
keymaster0, keymaster1 oder keymaster2 HALS.
Zugriffssteuerung
Die einfachste Regel der Schlüsselspeicher-Zugriffssteuerung besagt, dass jede Anwendung eigenen Namespace. Aber für jede Regel gibt es eine Ausnahme. Schlüsselspeicher enthält einige hartcodierten Karten, die es bestimmten Systemkomponenten ermöglichen, auf bestimmte andere Namespaces. Das ist ein sehr stumpfes Instrument, da es einer Komponente uneingeschränkte Kontrolle über einen anderen Namespace. Dann ist die Frage des Anbieters, als Clients für Keystore. Derzeit gibt es keine Möglichkeit, Namespace für Anbieterkomponenten, z. B. WPA supplicant.
Um Anbieterkomponenten zu berücksichtigen und die Zugriffssteuerung zu verallgemeinern Ohne hartcodierte Ausnahmen bietet Keystore 2.0 Domains und SELinux Namespaces.
Schlüsselspeicher-Domains
Mit Schlüsselspeicher-Domains können Namespaces von UIDs entkoppelt werden. Kunden Für den Zugriff auf einen Schlüssel im Schlüsselspeicher müssen die Domain, der Namespace und der Alias angegeben werden. auf die sie zugreifen möchten. Anhand dieses Tupels und der Identität des Aufrufers kann feststellen, auf welche Taste der Anrufer zugreifen möchte und ob er Berechtigungen.
Wir führen fünf Domainparameter ein, die steuern, wie auf Schlüssel zugegriffen werden kann. Sie steuern die Semantik des Namespace-Parameters des Schlüsseldeskriptors und wie die Zugriffssteuerung durchgeführt wird.
DOMAIN_APP
: Die App-Domain deckt die auf das alte Verhalten. Das Java Keystore SPI verwendet diese Domain standardmäßig. Wenn diese Domain verwendet wird, wird das Namespace-Argument ignoriert und die UID des Aufrufers lautet verwendet werden. Der Zugriff auf diese Domain wird über das Schlüsselspeicherlabel für den Klassekeystore_key
in der SELinux-Richtlinie.DOMAIN_SELINUX
: Diese Domain gibt an, dass die Namespace hat ein Label in der SELinux-Richtlinie. Der Namespace-Parameter wird und in einen Zielkontext übertragen, und es wird eine Berechtigungsprüfung für den aufrufenden SELinux-Kontext für diekeystore_key
-Klasse. Wenn der Parameter Berechtigung für den gegebenen Vorgang eingerichtet wurde, wird das vollständige Tupel verwendet. für die Schlüsselsuche aus.DOMAIN_GRANT
: Die Gewährungsdomain gibt an, dass Der Namespace-Parameter ist eine Berechtigungskennung. Der Alias-Parameter wird ignoriert. SELinux-Prüfungen werden durchgeführt, wenn die Erteilung erstellt wird. Weitere Zugriffssteuerung Prüft nur, ob die Aufrufer-UID mit der UID des Empfängers der angeforderten Erteilung übereinstimmt.DOMAIN_KEY_ID
: Diese Domain gibt an, dass die Namespace-Parameter ist eine eindeutige Schlüssel-ID. Der Schlüssel selbst wurde möglicherweise erstellt. mitDOMAIN_APP
oderDOMAIN_SELINUX
. Die Berechtigung Die Prüfung wird nachdomain
undnamespace
durchgeführt aus der Schlüsseldatenbank geladen werden, genauso wie beim Laden des Blobs. durch das Tupel „Domain“, „Namespace“ und „Alias“. Die Begründung für die Schlüssel-ID-Domain ist Kontinuität. Beim Zugriff auf einen Schlüssel über Alias können nachfolgende Aufrufe auf verschiedene Schlüssel, da möglicherweise ein neuer Schlüssel generiert oder importiert und gebunden wurde an diesen Alias. Die Schlüssel-ID ändert sich jedoch nie. Wenn Sie also einen Schlüssel nach Schlüssel-ID verwenden, nachdem er aus der Schlüsselspeicher-Datenbank einmal mit dem Alias geladen wurde, kann sicher sein, dass es sich um denselben Schlüssel handelt, solange die Schlüssel-ID noch existiert. Dieses nicht den App-Entwicklern zugänglich gemacht wird. Stattdessen wird es im Android Keystore SPI, um eine einheitlichere User Experience zu bieten, selbst wenn sie verwendet wird auf unsichere Weise erfolgen.DOMAIN_BLOB
: Die Blob-Domain gibt an, dass verwaltet der Aufrufer das Blob selbst. Dieser wird für Clients verwendet, die bevor die Datenpartition bereitgestellt wird. Das Schlüssel-BLOB ist im Feldblob
des Schlüsseldeskriptors enthalten.
Über die SELinux-Domain können wir Anbieterkomponenten bestimmte Schlüsselspeicher-Namespaces, die von Systemkomponenten wie das Dialogfeld mit den Einstellungen.
SELinux-Richtlinie für keystore_key
Namespace-Labels werden mithilfe der keystore2_key_context
-Datei.
Jede Zeile in diesen Dateien ordnet eine numerische Namespace-ID einem 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 Sie einen neuen Schlüssel-Namespace auf diese Weise eingerichtet haben, können wir Zugriff darauf gewähren
indem Sie eine entsprechende Richtlinie hinzufügen. Um beispielsweise
wpa_supplicant
zum Abrufen und Verwenden von Schlüsseln im neuen Namespace.
fügen Sie die folgende Zeile zu hal_wifi_supplicant.te
hinzu:
allow hal_wifi_supplicant wifi_key:keystore2_key { get, use };
Nach der Einrichtung des neuen Namespace kann AndroidKeyStore fast als
Üblicherweise. Der einzige Unterschied besteht darin, dass die Namespace-ID angegeben werden muss. Für
Beim Laden und Importieren von Schlüsseln aus dem und in den Schlüsselspeicher wird die Namespace-ID angegeben.
mit AndroidKeyStoreLoadStoreParameter
. Beispiel:
import android.security.keystore2.AndroidKeyStoreLoadStoreParameter; import java.security.KeyStore; KeyStore keystore = KeyStore.getInstance("AndroidKeyStore"); keystore.load(new AndroidKeyStoreLoadStoreParameter(102));
Zum Generieren eines Schlüssels in einem bestimmten Namespace muss die Namespace-ID angegeben werden
mit KeyGenParameterSpec.Builder#setNamespace():
import android.security.keystore.KeyGenParameterSpec; KeyGenParameterSpec.Builder specBuilder = new KeyGenParameterSpec.Builder(); specBuilder.setNamespace(102);
Die folgenden Kontextdateien können zur Konfiguration von Keystore 2.0 SELinux verwendet werden. Namespaces. Jede Partition hat einen anderen reservierten Bereich von 10.000 Namespaces IDs, um Konflikte 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 die gewünschte
virtuellen Namespace, in diesem Fall "wifi_key"
, durch seine numerische ID.
Darüber wurden die folgenden Namespaces definiert. Wenn sie Regeln gelten, wird in der folgenden Tabelle die UID angegeben, an.
Namespace-ID | SEPolicy-Label | UID | Beschreibung |
---|---|---|---|
0 | Su-Schlüssel | – | Superuser-Schlüssel. Wird nur zum Testen von UserDebug- und Entwickler-Builds verwendet. Nicht relevant für Nutzer-Builds. |
1 | Shell-Schlüssel | – | Für Shell verfügbarer Namespace. Wird hauptsächlich für Tests verwendet, kann aber auch für über die Befehlszeile ausführen. |
100 | Vold-Schlüssel | – | Vorgesehen für die Verwendung mit vold. |
101 | Odsing-Schlüssel | – | Wird vom Signatur-Daemon auf dem Gerät verwendet. |
102 | WLAN-Schlüssel | AID_WIFI(1010) | Wird vom Android-WLAN-System verwendet, einschließlich wpa_supplicant. |
120 | Fortsetzung_bei_Neustart | AID_SYSTEM(1.000) | Wird vom Android-Systemserver verwendet, um das Fortsetzen beim Neustart zu unterstützen. |
Auf Vektoren zugreifen
Die SELinux-Klasse keystore_key
ist in die Jahre gekommen und einige
die Berechtigungen wie verify
oder sign
verloren gegangen sind
deren Bedeutung. Hier sind die neuen Berechtigungen: keystore2_key
den Keystore 2.0 durchsetzt.
Berechtigung | Bedeutung |
---|---|
delete
|
Wird beim Entfernen von Schlüsseln aus dem Schlüsselspeicher aktiviert. |
get_info
|
Wird geprüft, wenn die Metadaten eines Schlüssels angefordert werden. |
grant
|
Der Aufrufer benötigt diese Berechtigung, um eine Erteilung für den Schlüssel im Zielbereich zu erstellen Kontext. |
manage_blob
|
Der Aufrufer kann DOMAIN_BLOB im angegebenen SELinux-Namespace verwenden,
und damit die Blobs selbst verwalten. Dies ist besonders nützlich für
vold. |
rebind
|
Diese Berechtigung steuert, ob ein Alias an einen neuen Schlüssel neu gebunden werden kann. Dies ist zum Einfügen erforderlich ist, und impliziert, dass der zuvor gebundene Schlüssel gelöscht. Es handelt sich im Grunde um eine Einfügeberechtigung, aber sie erfasst die semantische des Schlüsselspeichers verbessern. |
req_forced_op
|
Clients mit dieser Berechtigung können nicht gekürzte Vorgänge erstellen. Die Vorgangserstellung schlägt nie fehl, es sei denn, alle Vorgangsslots werden von nicht bereinigte Vorgänge. |
update
|
Erforderlich, um die Unterkomponente eines Schlüssels zu aktualisieren. |
use
|
Wird beim Erstellen eines Keymint-Vorgangs aktiviert, der das Schlüsselmaterial verwendet, z.B. zum Signieren und Entschlüsseln. |
use_dev_id
|
Erforderlich beim Generieren von Informationen zur Identifizierung des Geräts, z. B. der Geräte-ID Attestierung. |
Außerdem haben wir eine Reihe von
nicht schlüsselspezifischen Schlüsselspeicherberechtigungen
die SELinux-Sicherheitsklasse keystore2
:
Berechtigung | Bedeutung |
---|---|
add_auth
|
Vom Authentifizierungsanbieter wie Gatekeeper oder BiometricsManager erforderlich zum Hinzufügen von Authentifizierungstokens. |
clear_ns
|
Mit dieser Berechtigung, früher „clear_uid“, kann ein Nicht-Inhaber eines Namespace Folgendes tun: Alle Schlüssel in diesem Namespace löschen. |
list
|
Vom System erforderlich, um Schlüssel anhand verschiedener Attribute aufzuzählen, z. B.
Eigentümerschafts- oder Authentifizierungsgrenze. Diese Berechtigung ist für Aufrufer nicht erforderlich
Eigene Namespaces auflisten. Dies wird vom
Berechtigung „get_info “. |
lock
|
Diese Berechtigung ermöglicht das Sperren des Schlüsselspeichers, d. h. das Entfernen des Masterschlüssels, dass mit Authentifizierung gebundene Schlüssel unbrauchbar und nicht erzeugbar werden. |
reset
|
Mit dieser Berechtigung kann der Schlüsselspeicher auf die Werkseinstellungen zurückgesetzt werden. Dabei werden alle Tasten, die für das Funktionieren des Android-Betriebssystems nicht entscheidend sind. |
unlock
|
Diese Berechtigung ist erforderlich, um zu versuchen, den Masterschlüssel für die Authentifizierung zu entsperren gebundenen Schlüssel. |