Dostępność zaufanego środowiska wykonawczego w systemie opartym na układzie scalonym (SoC) pozwala urządzeniom z Androidem dostarczać sprzętowe w systemie operacyjnym Android, usługach platformowych, a nawet aplikacje innych firm. Deweloperzy, którzy szukają rozszerzeń dotyczących Androida, powinni do android.security.keystore.
Przed Androidem 6.0 w Androidzie istniała prosta, wspierana sprzętowo kryptowaluta Services API udostępnianego przez wersje 0.2 i 0.3 sprzętu Keymaster Hardware Warstwa abstrakcji (HAL). Cyfrowe podpisywanie i weryfikacja w magazynie kluczy oraz generowanie i importowanie asymetrycznych par kluczy podpisywania. To jest są już wdrożone na wielu urządzeniach, ale istnieje wiele celów związanych z bezpieczeństwem, nie można łatwo osiągnąć za pomocą interfejsu Signature API. Magazyn kluczy w Androidzie 6.0 Rozszerzyliśmy interfejs Keystore API, aby zapewnić szerszy zakres możliwości.
W Androidzie 6.0 dodano magazyn kluczy symetryczne podstawowe elementy kryptograficzne, AES i HMAC oraz system kontroli dostępu do kluczy sprzętowych. Dostęp elementy sterujące są określane podczas generowania klucza i egzekwowane przez cały okres klucz. Klucze można ograniczyć tak, aby można było ich używać tylko wtedy, gdy użytkownik uwierzytelnionych i wyłącznie w określonych celach lub za pomocą określonych metod kryptograficznych, . Więcej informacji: Tagi autoryzacji oraz na stronie Funkcje.
Oprócz rozszerzenia zakresu prymitywów kryptograficznych magazyn kluczy W Androidzie 6.0 dodaliśmy te funkcje:
- schemat kontroli wykorzystania, który umożliwia ograniczenie użycia klucza w celu ograniczenia ryzyko naruszenia bezpieczeństwa w wyniku niewłaściwego użycia kluczy
- schemat kontroli dostępu umożliwiający nadawanie ograniczeń kluczy określonym użytkownikom; klientów i określonego przedziału czasu,
W Androidzie 7.0 Keymaster 2 obsługuje atest i wersję klucza i powiązania. Atestacja klucza udostępnia certyfikaty klucza publicznego ze szczegółowym opisem klucza i kontroli dostępu, aby zapewnić ich bezpieczeństwo w bezpiecznym sprzęcie którą można zdalnie zweryfikować.
Powiązanie wersji wiąże klucze z systemem operacyjnym i wersją na poziomie poprawek. Dzięki temu atakującego, który zauważy słabość w starej wersji systemu Oprogramowanie TEE nie może przywrócić na urządzeniu wersji z lukami w zabezpieczeniach ani użyć kluczy utworzona w nowszej wersji. Ponadto, gdy klucz z określoną wersją a poziom poprawek jest używany na urządzeniu, który został uaktualniony do nowszej wersji. lub wersji poprawki, klucz jest uaktualniany, zanim będzie można go użyć, a poprzedni unieważniona wersja klucza. Po uaktualnieniu urządzenia klucze „zapadkowe” wzdłuż urządzenia, ale dowolne przywrócenie urządzenia do poprzedniego sprawia, że klucze są bezużyteczne.
W Androidzie 8.0 Keymaster 3 przeszli ze starego sprzętu o strukturze C Warstwa abstrakcji (HAL) do interfejsu C++ HAL wygenerowany na podstawie definicji w nowym języku Hardware Interface Definition Language (HIDL). W ramach tej zmiany wiele typów argumentów zostało zmienionych, chociaż typy i metody mają bezpośrednio ustawione ze starymi typami i metodami struktury HAL. Zobacz Więcej informacji znajdziesz na stronie Funkcje. .
Oprócz tej wersji interfejsu Android 8.0 rozszerzył funkcja atestu na potrzeby obsługi Atest tożsamości. Atest identyfikatora zapewnia ograniczony i opcjonalny mechanizm silnego poświadczania do identyfikatorów sprzętu, takich jak numer seryjny urządzenia, nazwa produktu i numer telefonu Identyfikator (IMEI / MEID). Aby wdrożyć to uzupełnienie, w Androidzie 8.0 zmienił się ASN.1 schemat atestu do dodania atestu identyfikatora. Implementacje Keymaster muszą: znaleźć jakiś bezpieczny sposób na pobieranie odpowiednich elementów danych, a także zdefiniować mechanizm bezpiecznego i trwałego wyłączania danej funkcji.
Aktualizacje Androida 9 obejmują:
- Zaktualizuj do Keymaster 4
- Obsługa osadzonych elementów zabezpieczonych
- Obsługa importowania bezpiecznych kluczy
- Obsługa szyfrowania 3DES
- Zmieniono wiązanie wersji w taki sposób, aby pliki Boot.img i system.img osobno ustawiaj wersje, aby umożliwić niezależne aktualizacje
Słowniczek
Oto krótkie omówienie komponentów magazynu kluczy i ich relacji.
AndroidKeystore to interfejs API i komponent Android Framework
przez aplikacje, aby uzyskać dostęp do funkcji magazynu kluczy. Jest ona wdrażana jako rozszerzenie
standardowy interfejs Java Cryptography Architecture API i składa się z kodu w Javie,
działa
w swoim własnym obszarze procesów aplikacji. AndroidKeystore
realizuje zadania z aplikacji
do działania magazynu kluczy, przesyłając je do demona magazynu kluczy.
Daemon Keystore to demon Androida, który: dostęp do wszystkich funkcji magazynu kluczy za pomocą interfejsu API Binder. Odpowiada za przechowywanie „kluczowych blobów”, które zawierają zaszyfrowany materiał klucza obiektu tajnego, dzięki czemu magazyn kluczy może go przechowywać, nie należy ich używać ani ujawniać.
keymasterd to serwer HIDL, który zapewnia dostęp do Keymaster TA. (Ta nazwa nie jest ustandaryzowana i służy tylko do celów koncepcyjnych).
Keymaster TA (zaufana aplikacja) to oprogramowanie działające w w bezpiecznym kontekście, najczęściej w TrustZone na układzie SoC ARM, który zapewnia wszystkie do bezpiecznych operacji magazynu kluczy, ma dostęp do surowego materiału klucza, weryfikuje wszystkie warunki kontroli dostępu do kluczy itd.
LockSettingsService to komponent systemu Android odpowiedzialny za
do uwierzytelniania użytkowników
przy użyciu hasła i odcisku palca. Nie jest częścią
Magazyn kluczy, który ma znaczenie, ponieważ wiele operacji na kluczach magazynu kluczy wymaga użytkownika
uwierzytelnianie. LockSettingsService
komunikuje się ze strażnikiem.
TA i Odcisk palca TA w celu uzyskania tokenów uwierzytelniania, które przekazuje
które są wykorzystywane przez narzędzie Keymaster TA.
aplikacji.
Kolejnym komponentem jest Gatekeeper TA (zaufana aplikacja). działające w bezpiecznym kontekście, który odpowiada za uwierzytelnianie użytkownika haseł i generowania tokenów uwierzytelniania, które są używane do potwierdzania dostępu do konta Keymaster TA. uwierzytelnianie określonego użytkownika w określonym momencie obecnie się znajdujesz.
Kolejnym komponentem jest Fingerprint TA (zaufana aplikacja). działające w bezpiecznym kontekście, który jest odpowiedzialny za uwierzytelnianie użytkownika odciski palców i generowanie tokenów uwierzytelniających używanych do uwierzytelniania Keymasterem TA, że w określonym momencie przeprowadzono uwierzytelnianie określonego użytkownika w odpowiednim czasie.
Architektura
Interfejs Android Keystore API i podstawowa wersja HAL Keymaster HAL zapewnia podstawowy, ale wystarczający zestaw prymityw kryptograficznych, który umożliwia implementacji protokołów za pomocą kluczy wspieranych sprzętowo, z kontrolą dostępu.
Biblioteka Keymaster HAL to dostarczana przez OEM, dynamicznie ładowana biblioteka, używana przez magazyn kluczy, który zapewnia wspierane sprzętowo usługi kryptograficzne. Aby zachować zabezpieczeń, wdrożenia HAL nie wykonują żadnych poufnych operacji użytkownika, a nawet w przestrzeni jądra. Operacje o charakterze wrażliwym są delegowane do do bezpiecznego procesora, do których dostęp jest uzyskiwany za pomocą interfejsu jądra. Uzyskana architektura będzie wyglądała tak:
![Dostęp do Keymaster](https://source.android.com/static/docs/security/images/access-to-keymaster.png?hl=pl)
Rysunek 1. Dostęp do Keymaster
Na urządzeniu z Androidem „klient” platformy Keymaster HAL składa się z wielowarstwowe (np. aplikacja, platforma, demon magazynu kluczy), które można zignorować do celów tego dokumentu. Oznacza to, że opisana zawartość HAL Keymaster Interfejs API jest niskiego poziomu, używany przez wewnętrzne komponenty platformy i nie jest dostępny dla aplikacji dla programistów. Interfejs API wyższego poziomu opisano na stronie dla deweloperów aplikacji na Androida.
Celem interfejsu HAL Keymaster nie jest wdrażanie funkcji ale tylko do wysyłania i usuwania żądań do bezpiecznego świata. jest zdefiniowany przez wdrożenie.
Zgodność z poprzednimi wersjami wersje
Klucz HAL Keymaster 1 jest całkowicie niezgodny z wcześniej opublikowane HAL, np. Keymaster 0.2 i 0.3. Ułatwianie na urządzeniach z Androidem 5.0 lub starszym, które zostały udostępnione do starszych list HAL Keymaster, magazyn kluczy zawiera adapter, który udostępnia Keymaster 1 HAL z wywołaniami istniejącej biblioteki sprzętowej. Wynik nie może zapewniają pełny zakres funkcji w programie Keymaster 1 HAL. W szczególności obsługuje wyłącznie algorytmy RSA i ECDSA, a wszystkie mechanizmy autoryzacji kluczy jest przeprowadzany przez adapter w niezabezpieczonym świecie.
Keymaster 2 dodatkowo uprościł interfejs HAL, usuwając
Metody get_supported_*
i zezwalanie na finish()
. Zmniejsza to liczbę lotów w obie strony do TEE w
w przypadkach, gdy dane wejściowe są dostępne w całości, i upraszcza implementację
Odszyfrowywanie AEAD.
W Androidzie 8.0 Keymaster 3 przeszli ze starej struktury C
Interfejs HAL do interfejsu C++ HAL wygenerowany na podstawie definicji w nowym interfejsie
Hardware Interface Definition Language (HIDL). HAL w nowym stylu
przez podklasyfikację wygenerowanego
IKeymasterDevice
i implementowanie tylko środowiska wirtualnego
. W wyniku tych zmian zmieniły się wiele typów argumentów.
chociaż typy i metody mają bezpośredni związek
i metody struktury HAL.
Omówienie HIDL
Język HIDL (Hardware Interface Definition Language) zapewnia niezależnego od języka mechanizmu do określania interfejsów sprzętowych. HIDL Obecnie narzędzie obsługuje generowanie interfejsów C++ i Java. To normalne że większość zaufanych osób wdrażających środowisko wykonawcze Z tego względu w tym dokumencie omówiono tylko wersję C++.
Interfejsy HIDL składają się z zestawu metod wyrażonych:
methodName(INPUT ARGUMENTS) generates (RESULT ARGUMENTS);
Istnieją różne wstępnie zdefiniowane typy, a HAL może definiować nowe wyliczane i typów struktur. Więcej informacji na temat HIDL znajdziesz w sekcji z materiałami referencyjnymi.
Przykładowa metoda z IKeymasterDevice.hal
Keymaster 3:
generateKey(vec<KeyParameter> keyParams) generates(ErrorCode error, vec<uint8_t> keyBlob, KeyCharacteristics keyCharacteristics);
Jest to odpowiednik tego z interfejsu HAL keymaster2:
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);
W wersji HIDL argument dev
jest usuwany, ponieważ jest to
domyślnie. Argument params
nie jest już obiektem struct zawierającym
wskaźnik odwołujący się do tablicy obiektów key_parameter_t
, ale
vec
(wektor) zawierający KeyParameter
obiektów.
zwracane wartości są wymienione w kolumnie „generates
” klauzulę, w tym
wektor uint8_t
wartości klucza blob.
Wirtualna metoda w języku C++ wygenerowana przez kompilator HIDL:
Return<void> generateKey(const hidl_vec<KeyParameter>& keyParams, generateKey_cb _hidl_cb) override;
Gdzie generateKey_cb
jest wskaźnikiem funkcji zdefiniowanym jako:
std::function<void(ErrorCode error, const hidl_vec<uint8_t>& keyBlob, const KeyCharacteristics& keyCharacteristics)>
Oznacza to, że generateKey_cb
to funkcja, która przyjmuje zwracane wartości.
wymienione w klauzuli generującej. Klasa implementacji HAL zastępuje tę
metoda generateKey
i wywołuje funkcję generateKey_cb
wskaźnik do zwrócenia wyniku operacji elementowi wywołującemu. Zwróć uwagę na funkcję
wywołanie wskaźnika jest synchroniczne. Rozmówca dzwoni
generateKey
i generateKey
wywołuje podany
wskaźnik funkcji, który wykonuje działanie do zakończenia, zwracając element sterujący do funkcji
implementacji generateKey
, która następnie wraca do elementu wywołującego.
Szczegółowy przykład znajdziesz w sekcji domyślnej implementacji
hardware/interfaces/keymaster/3.0/default/KeymasterDevice.cpp
Domyślna implementacja zapewnia zgodność wsteczną na urządzeniach z
w starszym stylu keymaster0, keymaster1 lub keymaster2 HALS.
Kontrola dostępu
Podstawowa zasada kontroli dostępu do magazynu kluczy jest taka, że każda aplikacja ma lub mają własną przestrzeń nazw. Każda reguła ma jednak wyjątek. Magazyn kluczy ma zakodowane na stałe mapy, które umożliwiają niektórym komponentom systemu dostęp do innych przestrzeni nazw. To bardzo tępy instrument, ponieważ składa się pełną kontrolę nad inną przestrzenią nazw. Kolejna kwestia jako klienty do magazynu kluczy. Obecnie nie ma możliwości stworzenia na potrzeby komponentów dostawcy, np. dostawcy WPA.
Aby uwzględnić komponenty dostawców i uogólnić kontrolę dostępu bez zakodowanych na stałe wyjątków, Keystore 2.0 wprowadza domeny, a SELinux przestrzeni nazw.
Domeny magazynu kluczy
Dzięki domenom magazynu kluczy możemy oddzielić przestrzenie nazw od identyfikatorów UID. Klienci uzyskiwanie dostępu do klucza w magazynie kluczy musi określać domenę, przestrzeń nazw i alias do których chcą uzyskać dostęp. Na podstawie tej krotki i tożsamości rozmówcy może określić, do którego klawisza chce uzyskać dostęp i czy ma on odpowiednie uprawnień.
Wprowadzamy 5 parametrów domeny, które określają sposób uzyskiwania dostępu do kluczy. Kontrolują semantykę parametru przestrzeni nazw deskryptora klucza oraz jak działa kontrola dostępu.
DOMAIN_APP
: domena aplikacji obejmuje działania Google Ads. Ta domena jest domyślnie używana przez interfejs dostawcy kluczy Java Keystore. Kiedy to domena jest używana, argument przestrzeni nazw jest ignorowany, a identyfikator UID elementu wywołującego to . Dostęp do tej domeny jest kontrolowany przez etykietę magazynu kluczykeystore_key
w zasadzie SELinux.DOMAIN_SELINUX
: ta domena wskazuje, że przestrzeń nazw ma etykietę w zasadzie SELinux. Sprawdzany jest parametr przestrzeni nazw. i przekształcanie w kontekst docelowy. Przeprowadzana jest też kontrola uprawnień dla klasykeystore_key
wywołujące kontekst SELinux. Gdy dla danej operacji ustanowiono uprawnienia, używana jest pełna krotka przy wyszukiwaniu klucza.DOMAIN_GRANT
: domena przyznania wskazuje, że Parametr przestrzeni nazw jest identyfikatorem przyznania. Parametr aliasu jest ignorowany. Kontrole SELinux są wykonywane po utworzeniu uwierzytelnienia. Dodatkowa kontrola dostępu sprawdza tylko, czy identyfikator UID wywołujący jest zgodny z identyfikatorem UID użytkownika, któremu przyznano dostęp.DOMAIN_KEY_ID
: ta domena wskazuje, że Parametr przestrzeni nazw jest unikalnym identyfikatorem klucza. Możliwe, że sam klucz został utworzony korzystając z funkcjiDOMAIN_APP
lubDOMAIN_SELINUX
. Uprawnienia sprawdzanie jest wykonywane podomain
inamespace
zostały wczytane z bazy danych kluczy w taki sam sposób, jak przy wczytywaniu obiektu blob według domeny, przestrzeni nazw i aliasu krotki. uzasadnienie domeny identyfikatora klucza. jest ciągłość. W przypadku uzyskiwania dostępu do klucza za pomocą aliasu kolejne wywołania mogą być wykonywane na różnych kluczy ze względu na możliwość wygenerowania lub zaimportowania nowego klucza i powiązania go do tego aliasu. Identyfikator klucza nigdy się nie zmienia. Zatem w przypadku klucza za pomocą identyfikatora klucza po wczytaniu go z bazy danych magazynu kluczy przy użyciu aliasu jednorazowo, możesz mieć pewność, że jest to ten sam klucz, o ile nadal istnieje jego identyfikator. Ten nie są widoczne dla deweloperów aplikacji. Zamiast tego jest używany w funkcji Interfejs SPI Android Keystore zapewnia bardziej spójną obsługę nawet w przypadku używania jednocześnie w niebezpieczny sposób.DOMAIN_BLOB
: domena bloba wskazuje, że wywołujący samodzielnie zarządza obiektem blob. Jest ono używane w przypadku klientów, którzy muszą dostępu do magazynu kluczy przed podłączeniem partycji danych. Kluczowym obiektem blob jest w polublob
deskryptora klucza.
Przy użyciu domeny SELinux możemy dać komponentom dostawcy dostęp do przestrzenie nazw magazynu kluczy, które mogą być współużytkowane przez komponenty systemu, takie jak okno ustawień.
Zasada SELinux dla keystore_key
Etykiety przestrzeni nazw są konfigurowane za pomocą interfejsu keystore2_key_context
.
Każdy wiersz w tych plikach mapuje numeryczny identyfikator przestrzeni nazw na etykietę SELinux.
Na przykład
# 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
Po skonfigurowaniu w ten sposób nowej przestrzeni nazw klucza możemy przyznać do niej dostęp
dodając odpowiednią zasadę. Aby na przykład zezwolić na
wpa_supplicant
w celu pobrania kluczy i użycia ich w nowej przestrzeni nazw,
dodaj do hal_wifi_supplicant.te
ten wiersz:
allow hal_wifi_supplicant wifi_key:keystore2_key { get, use };
Po skonfigurowaniu nowej przestrzeni nazw AndroidKeyStore może być używany prawie jako
jak zwykle. Jedyną różnicą jest to, że należy określić identyfikator przestrzeni nazw. Dla:
wczytuję i importuję klucze z i do magazynu kluczy, określono identyfikator przestrzeni nazw
za pomocą funkcji AndroidKeyStoreLoadStoreParameter
. Na przykład
import android.security.keystore2.AndroidKeyStoreLoadStoreParameter; import java.security.KeyStore; KeyStore keystore = KeyStore.getInstance("AndroidKeyStore"); keystore.load(new AndroidKeyStoreLoadStoreParameter(102));
Aby wygenerować klucz w danej przestrzeni nazw, należy podać jej identyfikator
przy użyciu: KeyGenParameterSpec.Builder#setNamespace():
import android.security.keystore.KeyGenParameterSpec; KeyGenParameterSpec.Builder specBuilder = new KeyGenParameterSpec.Builder(); specBuilder.setNamespace(102);
Do skonfigurowania magazynu kluczy 2.0 SELinux można użyć tych plików kontekstowych przestrzeni nazw. Każda partycja ma inny zarezerwowany zakres obejmujący 10 000 przestrzeni nazw identyfikatory pozwalające uniknąć kolizji.
Partycja | Zakres | Pliki konfiguracyjne |
---|---|---|
System | 0 ... 9 999 | /system/etc/selinux/keystore2_key_contexts, /plat_keystore2_key_contexts |
Rozszerzony 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 |
Dostawca | 30 000 ... 39 999 | /vendor/etc/selinux/vendor_keystore2_key_contexts, /vendor_keystore2_key_contexts |
Klient żąda klucza, wysyłając żądanie domeny SELinux i żądanego
wirtualnej przestrzeni nazw, w tym przypadku "wifi_key"
, według identyfikatora numerycznego.
Powyżej zdefiniowano następujące przestrzenie nazw. Jeśli zastąpią specjalnych reguł, w poniższej tabeli podano UID, które zostały użyte do do.
Identyfikator przestrzeni nazw | Etykieta SEPolicy | Identyfikator UID | Opis |
---|---|---|---|
0 | klucz_su | Nie dotyczy | Klucz superużytkownika. Używany tylko do testowania kompilacji userdebug i eng. Nie istotne w przypadku kompilacji. |
1 | klucz_powłoki | Nie dotyczy | Przestrzeń nazw dostępna dla powłoki. Głównie używany do testowania, ale może być używany ale także kompilacje użytkowników z poziomu wiersza poleceń. |
100 | klucz_vold | Nie dotyczy | Przeznaczone do użytku przez wold. |
101 | klucz_odingu | Nie dotyczy | Używany przez demona podpisywania na urządzeniu. |
102 | Klucz_Wi-Fi | AID_WIFI(1010) | Używany przez system Wi-Fi na Androidzie, w tym wpa_supplicant. |
120 | wznawianie_klucza_ponownego uruchamiania | AID_SYSTEM(1000) | Używany przez serwer systemowy Androida do obsługi wznawiania po ponownym uruchomieniu. |
Dostęp do wektorów
Klasa SELinux keystore_key
nieco się podeszła.
utracone uprawnienia takie jak verify
lub sign
ich znaczenia. Oto nowy zestaw uprawnień: keystore2_key
,
które wymusi stosowanie magazynu kluczy w wersji 2.0.
Uprawnienia | Znaczenie |
---|---|
delete
|
Sprawdzane podczas usuwania kluczy z magazynu kluczy. |
get_info
|
Sprawdzane, gdy wymagane są metadane klucza. |
grant
|
Element wywołujący potrzebuje tego uprawnienia, aby utworzyć uwierzytelnienie do klucza w miejscu docelowym i dodaje kontekst. |
manage_blob
|
Element wywołujący może używać zasady DOMAIN_BLOB w danej przestrzeni nazw SELinux,
co pozwala samodzielnie zarządzać obiektami blob. Jest to szczególnie przydatne w przypadku:
wold. |
rebind
|
To uprawnienie decyduje o tym, czy alias może być powiązany z nowym kluczem. To jest wymagane do wstawienia i oznacza, że poprzednio powiązany klucz zostanie Usunięto. Jest to w zasadzie uprawnienie do wstawiania, ale rejestruje semantykę i dopracowania magazynu kluczy. |
req_forced_op
|
Klienty z tym uprawnieniem mogą tworzyć operacje, których nie można przywrócić. tworzenie operacji nigdy się nie powiedzie, chyba że wszystkie przedziały operacji zostaną wykonane przez niemożliwych do wykonania operacji. |
update
|
Wymagane do aktualizowania podkomponentu klucza. |
use
|
Sprawdzane podczas tworzenia operacji Keymint korzystającej z materiału klucza, np. do podpisywania, szyfrowania/odszyfrowywania. |
use_dev_id
|
Wymagane podczas generowania informacji umożliwiających identyfikację urządzenia (np. jego identyfikatora) atestacji. |
Poza tym podzieliliśmy zestaw uprawnień, które nie są związane z magazynem kluczy,
klasa zabezpieczeń SELinux keystore2
:
Uprawnienia | Znaczenie |
---|---|
add_auth
|
Wymagane przez dostawcę uwierzytelniania, taki jak Gatekeeper lub BiometricsManager . |
clear_ns
|
To uprawnienie, które wcześniej nosiło nazwę clear_uid, umożliwia osobom bez właściciela przestrzeni nazw usuń wszystkie klucze z tej przestrzeni nazw. |
list
|
Wymagane przez system do wyliczania kluczy przez różne właściwości, takie jak
prawo własności lub uwierzytelnianie. Te uprawnienia nie są wymagane przez elementy wywołujące
wyliczając własne przestrzenie nazw. Obejmuje to
Uprawnienie get_info . |
lock
|
To uprawnienie umożliwia zablokowanie magazynu kluczy, czyli usunięcie klucza głównego, że klucze powiązane z uwierzytelnianiem stają się bezużyteczne i niemożliwe do utworzenia. |
reset
|
To uprawnienie pozwala przywrócić magazyn kluczy do ustawień fabrycznych, usuwając wszystkie klawiszy, które nie są niezbędne do działania systemu operacyjnego Android. |
unlock
|
To uprawnienie jest wymagane do próby odblokowania klucza głównego na potrzeby uwierzytelniania powiązane klucze. |