Magazyn kluczy wspierany sprzętowo

Dostępność zaufanego środowiska wykonawczego w systemie na chipie (SoC) umożliwia urządzeniom z Androidem zapewnianie wspieranych sprzętowo, silnych usług bezpieczeństwa dla systemu operacyjnego Android, usług platformowych, a nawet aplikacji innych firm. Programiści poszukujący rozszerzeń specyficznych dla Androida powinni udać się do sklepu android.security.keystore .

Przed wersją Androida 6.0 system Android miał już prosty, sprzętowy interfejs API usług kryptograficznych, udostępniany w wersjach 0.2 i 0.3 warstwy abstrakcji sprzętu Keymaster (HAL). Magazyn kluczy zapewniał cyfrowe operacje podpisywania i weryfikacji, a także generowanie i importowanie asymetrycznych par kluczy podpisujących. Jest to już zaimplementowane na wielu urządzeniach, ale istnieje wiele celów związanych z bezpieczeństwem, których nie można łatwo osiągnąć za pomocą samego interfejsu API sygnatur. Magazyn kluczy w systemie Android 6.0 rozszerzył interfejs API magazynu kluczy, aby zapewnić szerszy zakres możliwości.

W systemie Android 6.0 Keystore dodał symetryczne prymitywy kryptograficzne , AES i HMAC oraz system kontroli dostępu dla kluczy wspieranych sprzętowo. Kontrola dostępu jest określana podczas generowania klucza i egzekwowana przez cały okres istnienia klucza. Klucze można ograniczyć tak, aby można było ich używać dopiero po uwierzytelnieniu użytkownika i wyłącznie do określonych celów lub przy określonych parametrach kryptograficznych. Aby uzyskać więcej informacji, zobacz strony Tagi autoryzacji i funkcje .

Oprócz rozszerzenia zakresu prymitywów kryptograficznych, Keystore w systemie Android 6.0 dodał co następuje:

  • Schemat kontroli użycia umożliwiający ograniczenie użycia kluczy w celu ograniczenia ryzyka naruszenia bezpieczeństwa w wyniku niewłaściwego użycia kluczy
  • Schemat kontroli dostępu umożliwiający ograniczenie kluczy do określonych użytkowników, klientów i określonego zakresu czasu

W systemie Android 7.0 Keymaster 2 dodał obsługę zaświadczania kluczy i wiązania wersji. Certyfikat klucza zapewnia certyfikaty klucza publicznego, które zawierają szczegółowy opis klucza i jego kontroli dostępu, dzięki czemu istnienie klucza na bezpiecznym sprzęcie i jego konfiguracji można zdalnie zweryfikować.

Powiązanie wersji wiąże klucze z systemem operacyjnym i wersją poziomu poprawki. Dzięki temu osoba atakująca, która odkryje słabość w starej wersji systemu lub oprogramowaniu TEE, nie będzie mogła przywrócić urządzenia do wersji podatnej na ataki i użyć kluczy utworzonych w nowszej wersji. Dodatkowo, gdy klucz o danej wersji i poziomie poprawki zostanie użyty na urządzeniu, które zostało zaktualizowane do nowszej wersji lub poziomu poprawki, klucz zostanie zaktualizowany zanim będzie można go użyć, a poprzednia wersja klucza unieważnia się. W miarę aktualizacji urządzenia klawisze „przesuwają się” do przodu wraz z urządzeniem, ale jakiekolwiek przywrócenie urządzenia do poprzedniej wersji powoduje, że klucze stają się bezużyteczne.

W systemie Android 8.0 Keymaster 3 przeszedł ze starej warstwy abstrakcji sprzętu C (HAL) do interfejsu C++ HAL wygenerowanego na podstawie definicji w nowym języku definicji interfejsu sprzętowego (HIDL). W ramach tej zmiany zmieniło się wiele typów argumentów, chociaż typy i metody mają bezpośredni związek ze starymi typami i metodami struktur HAL. Więcej szczegółów znajdziesz na stronie Funkcje .

Oprócz tej wersji interfejsu, w systemie Android 8.0 rozszerzono funkcję atestacji Keymaster 2 o obsługę atestacji ID . Zaświadczanie identyfikatora zapewnia ograniczony i opcjonalny mechanizm silnego potwierdzania identyfikatorów sprzętu, takich jak numer seryjny urządzenia, nazwa produktu i identyfikator telefonu (IMEI/MEID). Aby zaimplementować ten dodatek, w systemie Android 8.0 zmieniono schemat zaświadczenia ASN.1, dodając zaświadczenie identyfikatora. Implementacje Keymaster muszą znaleźć jakiś bezpieczny sposób na odzyskanie odpowiednich elementów danych, a także zdefiniować mechanizm bezpiecznego i trwałego wyłączenia tej funkcji.

W systemie Android 9 aktualizacje obejmowały:

  • Zaktualizuj do Keymastera 4
  • Obsługa osadzonych bezpiecznych elementów
  • Obsługa bezpiecznego importu kluczy
  • Obsługa szyfrowania 3DES
  • Zmiany w powiązaniu wersji, dzięki czemu pliki boot.img i system.img mają oddzielnie ustawione wersje, co pozwala na niezależne aktualizacje

Słowniczek

Oto krótki przegląd komponentów magazynu kluczy i ich relacji.

AndroidKeystore to interfejs API i komponent systemu Android Framework używany przez aplikacje w celu uzyskania dostępu do funkcji magazynu kluczy. Jest zaimplementowany jako rozszerzenie standardowych interfejsów API architektury Java Cryptography i składa się z kodu Java działającego we własnej przestrzeni procesowej aplikacji. AndroidKeystore spełnia żądania aplikacji dotyczące zachowania magazynu kluczy, przekazując je do demona magazynu kluczy.

Demon magazynu kluczy to demon systemu Android, który zapewnia dostęp do wszystkich funkcji magazynu kluczy za pośrednictwem interfejsu API Binder . Odpowiada za przechowywanie „kluczowych obiektów blob”, które zawierają rzeczywisty tajny klucz, zaszyfrowany, aby magazyn kluczy mógł je przechowywać, ale nie mógł ich używać ani ujawniać.

keymasterd to serwer HIDL zapewniający dostęp do Keymaster TA. (Nazwa ta nie jest znormalizowana i służy celom koncepcyjnym.)

Keymaster TA (zaufana aplikacja) to oprogramowanie działające w bezpiecznym kontekście, najczęściej w TrustZone na ARM SoC, które zapewnia wszystkie bezpieczne operacje Keystore, ma dostęp do surowego materiału klucza, sprawdza wszystkie warunki kontroli dostępu na kluczach itp.

LockSettingsService to komponent systemu Android odpowiedzialny za uwierzytelnianie użytkowników, zarówno hasłem, jak i odciskiem palca. Nie jest częścią magazynu kluczy, ale jest istotny, ponieważ wiele operacji na kluczach magazynu kluczy wymaga uwierzytelnienia użytkownika. LockSettingsService współdziała z Gatekeeper TA i Fingerprint TA w celu uzyskania tokenów uwierzytelniających, które dostarcza demonowi magazynu kluczy i które ostatecznie są wykorzystywane przez aplikację Keymaster TA.

Gatekeeper TA (zaufana aplikacja) to kolejny komponent działający w bezpiecznym kontekście, który odpowiada za uwierzytelnianie haseł użytkowników i generowanie tokenów uwierzytelniających, które służą do udowodnienia Keymasterowi TA, że dla konkretnego użytkownika dokonano uwierzytelnienia w określonym momencie.

Fingerprint TA (zaufana aplikacja) to kolejny komponent działający w bezpiecznym kontekście, odpowiedzialny za uwierzytelnianie odcisków palców użytkowników i generowanie tokenów uwierzytelniających, które służą do udowodnienia Keymasterowi TA, że dla konkretnego użytkownika dokonano uwierzytelnienia w określonym momencie.

Architektura

Interfejs API Android Keystore i bazowa warstwa Keymaster HAL zapewniają podstawowy, ale odpowiedni zestaw prymitywów kryptograficznych, umożliwiający implementację protokołów przy użyciu kluczy sprzętowych z kontrolą dostępu.

Keymaster HAL to dostarczana przez producenta OEM, dynamicznie ładowana biblioteka używana przez usługę Keystore do świadczenia usług kryptograficznych wspieranych sprzętowo. Aby zapewnić bezpieczeństwo, implementacje HAL nie wykonują żadnych wrażliwych operacji w przestrzeni użytkownika ani nawet w przestrzeni jądra. Wrażliwe operacje są delegowane do bezpiecznego procesora, do którego można uzyskać dostęp za pośrednictwem interfejsu jądra. Powstała architektura wygląda następująco:

Dojazd do Keymaster

Rysunek 1. Dostęp do Keymastera

W urządzeniu z Androidem „klient” Keymaster HAL składa się z wielu warstw (np. aplikacji, frameworku, demona Keystore), ale na potrzeby tego dokumentu można to zignorować. Oznacza to, że opisane API Keymaster HAL jest niskopoziomowe, używane przez komponenty wewnętrzne platformy i nieudostępniane twórcom aplikacji. Interfejs API wyższego poziomu jest opisany w witrynie dla programistów Androida .

Celem Keymaster HAL nie jest implementacja algorytmów wrażliwych na bezpieczeństwo, ale jedynie kierowanie i cofanie żądań do bezpiecznego świata. Format przewodu jest zdefiniowany w implementacji.

Kompatybilność z poprzednimi wersjami

Keymaster 1 HAL jest całkowicie niekompatybilny z wcześniej wydanymi HAL, np. Keymaster 0.2 i 0.3. Aby ułatwić interoperacyjność na urządzeniach z systemem Android 5.0 i wcześniejszym, który został uruchomiony ze starszymi warstwami HAL Keymaster, firma Keystore udostępnia adapter, który implementuje warstwę HAL Keymaster 1 z wywołaniami do istniejącej biblioteki sprzętowej. Wynik nie może zapewnić pełnego zakresu funkcjonalności Keymaster 1 HAL. W szczególności obsługuje tylko algorytmy RSA i ECDSA, a całe egzekwowanie autoryzacji kluczy jest wykonywane przez adapter w niezabezpieczonym świecie.

Keymaster 2 jeszcze bardziej uprościł interfejs HAL, usuwając metody get_supported_* i umożliwiając metodzie finish() akceptowanie danych wejściowych. Zmniejsza to liczbę podróży w obie strony do TEE w przypadkach, gdy dane wejściowe są dostępne w całości na raz, i upraszcza wdrażanie deszyfrowania AEAD.

W systemie Android 8.0 Keymaster 3 przeszedł ze starego interfejsu HAL o strukturze C do interfejsu HAL C++ wygenerowanego na podstawie definicji w nowym języku definicji interfejsu sprzętowego (HIDL). Implementacja HAL w nowym stylu jest tworzona poprzez podklasę wygenerowanej klasy IKeymasterDevice i implementację czysto wirtualnych metod. W ramach tej zmiany zmieniło się wiele typów argumentów, chociaż typy i metody mają bezpośredni związek ze starymi typami i metodami struktur HAL.

Przegląd HIDL-a

Język definicji interfejsu sprzętowego (HIDL) zapewnia niezależny od języka implementacji mechanizm określania interfejsów sprzętowych. Narzędzia HIDL obsługują obecnie generowanie interfejsów C++ i Java. Oczekuje się, że większość implementatorów Trusted Execution Environment (TEE) uzna narzędzia C++ za wygodniejsze, dlatego w tym dokumencie omówiono tylko reprezentację C++.

Interfejsy HIDL składają się z zestawu metod wyrażonych jako:

  methodName(INPUT ARGUMENTS) generates (RESULT ARGUMENTS);

Istnieją różne wstępnie zdefiniowane typy, a warstwy HAL mogą definiować nowe typy wyliczeniowe i typy struktur. Aby uzyskać więcej informacji na temat HIDL, zobacz sekcję Informacje .

Przykładowa metoda z Keymaster 3 IKeymasterDevice.hal to:

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

Jest to odpowiednik poniższego z HAL-a 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 został usunięty, ponieważ jest ukryty. Argument params nie jest już strukturą zawierającą wskaźnik odwołujący się do tablicy obiektów key_parameter_t , ale wektorem vec zawierającym obiekty KeyParameter . Zwracane wartości są wymienione w klauzuli „ generates ” i obejmują wektor wartości uint8_t dla kluczowego obiektu blob.

Wirtualna metoda C++ wygenerowana przez kompilator HIDL to:

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 jest funkcją, która przyjmuje wartości zwracane wymienione w klauzuli generate. Klasa implementacji HAL zastępuje tę metodę generateKey i wywołuje wskaźnik funkcji generateKey_cb w celu zwrócenia wyniku operacji do obiektu wywołującego. Należy zauważyć, że wywołanie wskaźnika funkcji jest synchroniczne . Obiekt wywołujący wywołuje generateKey , a generateKey wywołuje dostarczony wskaźnik funkcji, który wykonuje się do końca, zwracając kontrolę do implementacji generateKey , która następnie wraca do wywołującego.

Szczegółowy przykład można znaleźć w domyślnej implementacji w hardware/interfaces/keymaster/3.0/default/KeymasterDevice.cpp . Domyślna implementacja zapewnia kompatybilność wsteczną dla urządzeń ze starym typem HALS keymaster0, keymaster1 lub keymaster2.

Kontrola dostępu

Najbardziej podstawową zasadą kontroli dostępu do magazynu kluczy jest to, że każda aplikacja ma własną przestrzeń nazw. Ale od każdej reguły jest wyjątek. Magazyn kluczy zawiera zakodowane na stałe mapy, które umożliwiają określonym komponentom systemu dostęp do określonych innych przestrzeni nazw. Jest to bardzo tępy instrument, ponieważ daje jednemu komponentowi pełną kontrolę nad inną przestrzenią nazw. Następnie pojawia się kwestia komponentów dostawców jako klientów magazynu kluczy. Obecnie nie mamy możliwości ustalenia przestrzeni nazw dla komponentów dostawcy, na przykład suplikant 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 i przestrzenie nazw SELinux.

Domeny magazynu kluczy

Dzięki domenom magazynu kluczy możemy oddzielić przestrzenie nazw od identyfikatorów UID. Klienci uzyskujący dostęp do klucza w magazynie kluczy muszą określić domenę, przestrzeń nazw i alias, do których chcą uzyskać dostęp. Na podstawie tej krotki i tożsamości osoby wywołującej możemy określić, do jakiego klucza osoba wywołująca chce uzyskać dostęp i czy ma odpowiednie uprawnienia.

Wprowadzamy pięć parametrów domeny, które regulują sposób dostępu do kluczy. Kontrolują semantykę parametru przestrzeni nazw deskryptora klucza i sposób wykonywania kontroli dostępu.

  • DOMAIN_APP : domena aplikacji obejmuje starsze zachowanie. Interfejs SPI magazynu kluczy Java domyślnie używa tej domeny. Gdy używana jest ta domena, argument przestrzeni nazw jest ignorowany i zamiast tego używany jest UID obiektu wywołującego. Dostęp do tej domeny jest kontrolowany przez etykietę Keystore do klasy keystore_key w polityce SELinux.
  • DOMAIN_SELINUX : Ta domena wskazuje, że przestrzeń nazw ma etykietę w polityce SELinux. Parametr przestrzeni nazw jest sprawdzany i tłumaczony na kontekst docelowy, a dla wywołującego kontekstu SELinux przeprowadzana jest kontrola uprawnień dla klasy keystore_key . Po ustaleniu uprawnień dla danej operacji do wyszukiwania klucza używana jest pełna krotka.
  • DOMAIN_GRANT : Domena grantu wskazuje, że parametr przestrzeni nazw jest identyfikatorem grantu. Parametr aliasu jest ignorowany. Kontrole SELinux są przeprowadzane podczas tworzenia grantu. Dalsza kontrola dostępu sprawdza tylko, czy identyfikator UID osoby wywołującej jest zgodny z identyfikatorem UID stypendystów żądanego przydziału.
  • DOMAIN_KEY_ID : Ta domena wskazuje, że parametr przestrzeni nazw jest unikalnym identyfikatorem klucza. Sam klucz mógł zostać utworzony w DOMAIN_APP lub DOMAIN_SELINUX . Sprawdzanie uprawnień odbywa się po załadowaniu domain i namespace z bazy danych kluczy w taki sam sposób, jak w przypadku załadowania obiektu BLOB przez domenę, przestrzeń nazw i krotkę aliasów. Uzasadnieniem dla domeny identyfikatora klucza jest ciągłość. Podczas uzyskiwania dostępu do klucza za pomocą aliasu kolejne wywołania mogą działać na różnych kluczach, ponieważ mógł zostać wygenerowany lub zaimportowany nowy klucz i powiązany z tym aliasem. Jednak identyfikator klucza nigdy się nie zmienia. Zatem używając klucza według identyfikatora klucza po jego załadowaniu z bazy danych magazynu kluczy przy użyciu aliasu, można mieć pewność, że jest to ten sam klucz, o ile identyfikator klucza nadal istnieje. Ta funkcja nie jest dostępna dla twórców aplikacji. Zamiast tego jest używany w interfejsie SPI Android Keystore, aby zapewnić bardziej spójne działanie, nawet jeśli jest używany jednocześnie w niebezpieczny sposób.
  • DOMAIN_BLOB : Domena typu BLOB wskazuje, że obiekt wywołujący samodzielnie zarządza obiektem BLOB. Jest to używane w przypadku klientów, którzy muszą uzyskać dostęp do magazynu kluczy przed zamontowaniem partycji danych. Kluczowy obiekt blob jest zawarty w polu obiektu blob deskryptora klucza.

Korzystając z domeny SELinux, możemy zapewnić komponentom dostawcy dostęp do bardzo specyficznych przestrzeni nazw Keystore, które mogą być współdzielone przez komponenty systemu, takie jak okno dialogowe ustawień.

Polityka SELinux dla klucz_magazynu kluczy

Etykiety przestrzeni nazw są konfigurowane przy użyciu pliku keystore2_key_context .
Każda linia w tych plikach odwzorowuje 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 udostępnić ją dodając odpowiednią politykę. Na przykład, aby umożliwić wpa_supplicant pobieranie i używanie kluczy w nowej przestrzeni nazw, dodalibyśmy następujący wiersz do hal_wifi_supplicant.te :

allow hal_wifi_supplicant wifi_key:keystore2_key { get, use };

Po skonfigurowaniu nowej przestrzeni nazw AndroidKeyStore może być używany prawie jak zwykle. Jedyna różnica polega na tym, że należy określić identyfikator przestrzeni nazw. W przypadku ładowania i importowania kluczy z magazynu kluczy i do magazynu kluczy identyfikator przestrzeni nazw jest określany za pomocą 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ć identyfikator przestrzeni nazw za pomocą metody KeyGenParameterSpec.Builder#setNamespace():

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

Poniższe pliki kontekstowe mogą zostać użyte do skonfigurowania przestrzeni nazw Keystore 2.0 SELinux. Każda partycja ma inny zarezerwowany zakres 10 000 identyfikatorów przestrzeni nazw, aby uniknąć kolizji.

Przegroda Zakres Pliki konfiguracyjne
System 0... 9999
/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
Sprzedawca 30 000 ... 39 999
/vendor/etc/selinux/vendor_keystore2_key_contexts, /vendor_keystore2_key_contexts

Klient żąda klucza, żądając domeny SELinux i żądanej wirtualnej przestrzeni nazw, w tym przypadku "wifi_key" , za pomocą jej identyfikatora numerycznego.

Powyżej zdefiniowano następujące przestrzenie nazw. Jeśli zastępują reguły specjalne, poniższa tabela wskazuje UID, któremu odpowiadały.

Identyfikator przestrzeni nazw Etykieta SEPolityki UID Opis
0 su_key Nie dotyczy Klucz superużytkownika. Używany tylko do testowania debugowania użytkownika i kompilacji eng. Nie dotyczy kompilacji użytkowników.
1 klucz_powłoki Nie dotyczy Przestrzeń nazw dostępna dla powłoki. Używany głównie do testowania, ale można go również używać w kompilacjach użytkowników z wiersza poleceń.
100 klucz_wolny Nie dotyczy Przeznaczony do użytku przez vold.
101 odsing_key Nie dotyczy Używany przez demona podpisywania na urządzeniu.
102 klucz_wifi AID_WIFI(1010) Używany przez system Wi-Fi Androida, w tym wpa_supplicant.
120 CV_on_reboot_key POMOC_SYSTEM(1000) Używany przez serwer systemu Android do obsługi wznawiania po ponownym uruchomieniu.

Wektory dostępu

Klasa SELinux keystore_key dość się zestarzała i niektóre uprawnienia, takie jak verify czy sign , straciły na znaczeniu. Oto nowy zestaw uprawnień, keystore2_key , który będzie egzekwowany przez Keystore 2.0.

Pozwolenie Oznaczający
delete Sprawdzane podczas usuwania kluczy z magazynu kluczy.
get_info Sprawdzane, gdy żądane są metadane klucza.
grant Obiekt wywołujący potrzebuje tego uprawnienia, aby utworzyć przyznanie klucza w kontekście docelowym.
manage_blob Osoba wywołująca może używać DOMAIN_BLOB w danej przestrzeni nazw SELinux, w ten sposób samodzielnie zarządzając obiektami BLOB. Jest to szczególnie przydatne w przypadku vold.
rebind To uprawnienie kontroluje, czy alias może zostać powiązany z nowym kluczem. Jest to wymagane do wstawienia i oznacza, że ​​wcześniej powiązany klucz zostanie usunięty. Zasadniczo jest to pozwolenie na wstawianie, ale lepiej oddaje semantykę magazynu kluczy.
req_forced_op Klienci z tym uprawnieniem mogą tworzyć operacje, których nie można wyczyścić, a tworzenie operacji nigdy nie kończy się niepowodzeniem, chyba że wszystkie miejsca operacji zostaną zajęte przez operacje, których nie można wyczyścić.
update Wymagane do aktualizacji podskładnika klucza.
use Sprawdzane podczas tworzenia operacji Keymint wykorzystującej materiał klucza, np. do podpisywania, szyfrowania/odszyfrowywania.
use_dev_id Wymagane podczas generowania informacji identyfikujących urządzenie, takich jak poświadczenie identyfikatora urządzenia.

Dodatkowo podzieliliśmy zestaw uprawnień do magazynu kluczy innych niż klucze w keystore2 klasy zabezpieczeń SELinux:

Pozwolenie Oznaczający
add_auth Wymagane przez dostawcę uwierzytelniania, takiego jak Gatekeeper lub BiometricsManager, do dodawania tokenów uwierzytelniania.
clear_ns Uprawnienie to, dawniej clear_uid, umożliwia osobie niebędącej właścicielem przestrzeni nazw usunięcie wszystkich kluczy z tej przestrzeni nazw.
list Wymagane przez system do wyliczania kluczy według różnych właściwości, takich jak własność lub ograniczenia uwierzytelniania. To uprawnienie nie jest wymagane w przypadku obiektów wywołujących wyliczających własne przestrzenie nazw. Jest to objęte uprawnieniem get_info .
lock To uprawnienie umożliwia zablokowanie magazynu kluczy, czyli wykluczenie klucza głównego, tak że klucze powiązane z autoryzacją staną się bezużyteczne i nie da się ich utworzyć.
reset To uprawnienie pozwala zresetować Keystore do ustawień fabrycznych, usuwając wszystkie klucze, które nie są niezbędne do funkcjonowania systemu operacyjnego Android.
unlock To uprawnienie jest wymagane do podjęcia próby odblokowania klucza głównego w przypadku kluczy powiązanych z autoryzacją.