Donanım destekli Anahtar Deposu

Bir çip üzerindeki bir sistemde (SoC) güvenilir bir yürütme ortamının bulunması, Android cihazların Android işletim sistemine, platform hizmetlerine ve hatta üçüncü taraf uygulamalara donanım destekli, güçlü güvenlik hizmetleri sağlama fırsatı sunar. Android'e özel uzantıları arayan Geliştiriciler gitmeli android.security.keystore .

Android 6.0'dan önce Android, Keymaster Donanım Soyutlama Katmanı'nın (HAL) 0.2 ve 0.3 sürümleri tarafından sağlanan basit, donanım destekli bir kripto hizmetleri API'sine sahipti. Anahtar deposu, dijital imzalama ve doğrulama işlemlerinin yanı sıra asimetrik imzalama anahtar çiftlerinin oluşturulmasını ve içe aktarılmasını sağladı. Bu zaten birçok cihazda uygulanmaktadır, ancak yalnızca bir imza API'si ile kolayca ulaşılamayan birçok güvenlik hedefi vardır. Android 6.0'daki anahtar deposu, daha geniş bir yetenek yelpazesi sağlamak için Anahtar Deposu API'sini genişletti.

Android 6.0 yılında Keystore eklendi simetrik şifreleme ilkeller , AES ve HMAC ve donanım destekli anahtarlar için bir erişim kontrol sistemi. Erişim denetimleri, anahtar oluşturma sırasında belirlenir ve anahtarın ömrü boyunca uygulanır. Anahtarlar, yalnızca kullanıcının kimliği doğrulandıktan sonra ve yalnızca belirtilen amaçlar için veya belirtilen şifreleme parametreleriyle kullanılabilir olacak şekilde kısıtlanabilir. Daha fazla bilgi için, bkz Yetkilendirme Etiketler ve Fonksiyonlar sayfaları.

Android 6.0'daki Keystore, şifreleme temel öğelerinin kapsamını genişletmeye ek olarak şunları ekledi:

  • Anahtarların yanlış kullanımından kaynaklanan güvenlik ihlali riskini azaltmak için anahtar kullanımının sınırlandırılmasına izin veren bir kullanım kontrol şeması
  • Anahtarların belirli kullanıcılara, istemcilere ve tanımlanmış bir zaman aralığına kısıtlanmasını sağlayan bir erişim kontrol şeması

Android 7.0'da Keymaster 2, anahtar doğrulama ve sürüm bağlama desteği ekledi. Anahtar tasdik uzaktan doğrulanabilir güvenli donanım ve onun yapılandırmasında anahtarın varlığını yapmak, anahtarın ve bunun erişim kontrollerinin ayrıntılı bir açıklama içeren genel anahtar sertifikaları sağlar.

Sürüm bağlayıcı işletim sistemi ve yama seviyesi sürümüne bağlar anahtarları. Bu, sistemin eski bir sürümünde veya TEE yazılımında bir zayıflık keşfeden bir saldırganın, bir cihazı savunmasız sürüme geri almamasını ve daha yeni sürümle oluşturulan anahtarları kullanmamasını sağlar. Ayrıca, daha yeni bir sürüme veya yama düzeyine yükseltilmiş bir cihazda belirli bir sürüm ve yama düzeyine sahip bir anahtar kullanıldığında, anahtar kullanılmadan önce yükseltilir ve anahtarın önceki sürümü geçersiz kılınır. Cihaz yükseltilirken, tuşlar cihazla birlikte "mandallanır", ancak cihazın herhangi bir önceki sürüme döndürülmesi, tuşların kullanılamaz hale gelmesine neden olur.

Android 8.0'da Keymaster 3, eski tarz C yapısı Donanım Soyutlama Katmanından (HAL) yeni Donanım Arayüzü Tanımlama Dili'ndeki (HIDL) bir tanımdan oluşturulan C++ HAL arayüzüne geçiş yaptı. Değişikliğin bir parçası olarak, argüman türlerinin çoğu değişti, ancak türler ve yöntemler, eski türler ve HAL yapı yöntemleriyle birebir örtüşüyor. Bkz Fonksiyonlar Daha fazla ayrıntı için sayfa.

Bu arayüz revizyon ek olarak, Android 8.0 desteği Keymaster 2'nin tasdik özelliği genişletilmiş kimlik teyidi . Kimlik onayı, aygıt seri numarası, ürün adı ve telefon kimliği (IMEI / MEID) gibi donanım tanımlayıcılarını güçlü bir şekilde doğrulamak için sınırlı ve isteğe bağlı bir mekanizma sağlar. Bu eklemeyi uygulamak için Android 8.0, ASN.1 onay şemasını kimlik onayı eklemek üzere değiştirdi. Keymaster uygulamalarının, ilgili veri öğelerini almanın güvenli bir yolunu bulması ve özelliği güvenli ve kalıcı olarak devre dışı bırakmak için bir mekanizma tanımlaması gerekir.

Android 9'da güncellemeler şunları içeriyordu:

  • Güncelle Keymaster 4
  • Yerleşik Güvenli Öğeler için destek
  • Güvenli anahtar içe aktarma desteği
  • 3DES şifreleme desteği
  • Boot.img ve system.img'nin bağımsız güncellemelere izin vermek için ayrı ayrı ayarlanmış sürümleri olması için sürüm bağlamada yapılan değişiklikler

Sözlük

Anahtar deposu bileşenlerine ve ilişkilerine hızlı bir genel bakış burada.

AndroidKeystore erişim Keystore işlevselliğine uygulamalar tarafından kullanılan Android Çerçeve API ve bileşenidir. Standart Java Kriptografi Mimarisi API'lerinin bir uzantısı olarak uygulanır ve uygulamanın kendi işlem alanında çalışan Java kodundan oluşur. AndroidKeystore deposu cini yönlendirerek Keystore davranışı için uygulama istekleri yerine getirir.

Deposu cin bir yoluyla tüm Keystore işlevselliğine erişim sağlayan bir Android sistem servistir Bağlayıcı API . Gerçek gizli anahtar malzemesini içeren "anahtar bloblarını" saklamaktan sorumludur, böylece Keystore bunları saklayabilir, ancak kullanamaz veya gösteremez.

keymasterd Keymaster TA erişim sağlayan bir HIDL sunucusudur. (Bu isim standart değildir ve kavramsal amaçlar içindir.)

Anahtar Sorumlusu TA (Güvenilir uygulama), güvenli Keystore operasyonların tüm sağlayan ham anahtar materyale erişimi olan bir ARM SoC üzerinde TrustZone en sık, güvenli bir bağlamda çalışan yazılım, olduğu tuşlarını erişim kontrol koşulların tümü doğrular , vesaire.

LockSettingsService kullanıcı kimlik doğrulaması, şifre ve parmak izi hem sorumlu Android sistem bileşenidir. Anahtar Deposu'nun bir parçası değildir, ancak birçok Anahtar Deposu anahtar işlemi kullanıcı kimlik doğrulaması gerektirdiğinden alakalıdır. LockSettingsService Geçit TA ve parmak izi TA ile etkileşime girdiği bu deposu artalan sağlar ve sonuçta Keymaster ta uygulama tarafından tüketildiği kimlik doğrulama bilgilerini elde etmek için.

Geçit TA (Güvenilir uygulama) kimlik doğrulaması kullanıcı şifreleri doğrulanması ve üretilmesi için sorumlu olan bir kimlik doğrulama zaman içinde belirli bir noktada belirli bir kullanıcı için yapıldığını Keymaster ta kanıtlamak için kullanılır jetonudur güvenli bağlamında çalışan başka bir bileşenidir.

Parmak izi TA (Güvenilir uygulama) kimlik doğrulaması kullanıcı parmak izi doğrulanması ve üretilmesi için sorumlu olan bir kimlik doğrulama zaman içinde belirli bir noktada belirli bir kullanıcı için yapıldığını Keymaster ta kanıtlamak için kullanılır jetonudur güvenli bağlamında çalışan başka bir bileşenidir.

Mimari

Android Anahtar Deposu API'si ve temeldeki Keymaster HAL, erişim kontrollü, donanım destekli anahtarlar kullanılarak protokollerin uygulanmasına izin vermek için temel ancak yeterli bir şifreleme ilkel kümesi sağlar.

Keymaster HAL, donanım destekli şifreleme hizmetleri sağlamak için Keystore hizmeti tarafından kullanılan, OEM tarafından sağlanan, dinamik olarak yüklenebilir bir kitaplıktır. İşleri güvende tutmak için, HAL uygulamaları kullanıcı alanında ve hatta çekirdek alanında herhangi bir hassas işlem gerçekleştirmez. Hassas işlemler, bazı çekirdek arabirimleri aracılığıyla ulaşılan güvenli bir işlemciye devredilir. Ortaya çıkan mimari şöyle görünür:

Keymaster'a erişim

Keymaster için Şekil 1. Erişim

Bir Android aygıtında, Keymaster HAL'nin "istemcisi" birden çok katmandan oluşur (örn. uygulama, çerçeve, Anahtar deposu arka plan programı), ancak bu belgenin amaçları doğrultusunda bu katmanlar göz ardı edilebilir. Bu, açıklanan Keymaster HAL API'sinin düşük seviyeli olduğu, platformun dahili bileşenleri tarafından kullanıldığı ve uygulama geliştiricilerine açık olmadığı anlamına gelir. Üst düzey API üzerinde açıklanmıştır Android Geliştirici sitesinde .

Keymaster HAL'ın amacı, güvenliğe duyarlı algoritmaları uygulamak değil, yalnızca güvenli dünyaya yönelik istekleri sıraya koymak ve sıraya koymaktır. Tel formatı uygulama tanımlıdır.

Önceki sürümlerle uyumluluk

Keymaster 1 HAL, daha önce yayınlanan HAL'lerle, örneğin Keymaster 0.2 ve 0.3 ile tamamen uyumsuzdur. Eski Keymaster HAL'leri ile başlatılan Android 5.0 ve önceki sürümleri çalıştıran cihazlarda birlikte çalışabilirliği kolaylaştırmak için Keystore, mevcut donanım kitaplığına yapılan çağrılarla Keymaster 1 HAL'ı uygulayan bir bağdaştırıcı sağlar. Sonuç, Keymaster 1 HAL'de tam işlevsellik sağlayamaz. Özellikle, yalnızca RSA ve ECDSA algoritmalarını destekler ve tüm anahtar yetkilendirme zorlaması, güvenli olmayan dünyada adaptör tarafından gerçekleştirilir.

Keymaster 2 başka kaldırarak HAL arayüzü basitleştirilmiş get_supported_* yöntem ve izin finish() girişi kabul etmek için bir yöntem. Bu, girdinin tamamının aynı anda mevcut olduğu durumlarda TEE'ye gidiş dönüş sayısını azaltır ve AEAD şifre çözme uygulamasını basitleştirir.

Android 8.0'da Keymaster 3, eski tarz C yapısı HAL'den yeni Donanım Arayüzü Tanımlama Dili'ndeki (HIDL) bir tanımdan oluşturulan C++ HAL arayüzüne geçiş yaptı. Yeni tarzda HAL uygulanması oluşturulan sınıflara göre oluşturulan IKeymasterDevice sınıf ve saf sanal yöntemleri uygulamak. Değişikliğin bir parçası olarak, argüman türlerinin çoğu değişti, ancak türler ve yöntemler, eski türler ve HAL yapı yöntemleriyle birebir örtüşüyor.

HIDL'ye genel bakış

Donanım Arabirim Tanımlama Dili (HIDL), donanım arabirimlerini belirtmek için uygulama dilinden bağımsız bir mekanizma sağlar. HIDL araçları şu anda C++ ve Java arabirimlerinin oluşturulmasını desteklemektedir. Çoğu Güvenilir Yürütme Ortamı (TEE) uygulayıcısının C++ araçlarını daha uygun bulması beklenir, bu nedenle bu belgede yalnızca C++ gösterimi ele alınmaktadır.

HIDL arayüzleri, şu şekilde ifade edilen bir dizi metottan oluşur:

  methodName(INPUT ARGUMENTS) generates (RESULT ARGUMENTS);

Önceden tanımlanmış çeşitli türler vardır ve HAL'ler yeni numaralandırılmış ve yapı türleri tanımlayabilir. HIDL hakkında daha fazla ayrıntı için bkz Referans bölümü .

Keymaster 3 bir örnek yöntemi IKeymasterDevice.hal olduğu:

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

Bu, keymaster2 HAL'den aşağıdakilerin eşdeğeridir:

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);

HIDL versiyonunda, dev argümanı bu örtülü olduğu için, kaldırılır. params argüman artık bir dizi referans işaretçi ihtiva eden bir yapı olan key_parameter_t nesneler, ancak vec ihtiva eden (vektör) KeyParameter nesneleri. Dönüş değerleri "listelenen generates bir vektörü içeren," madde uint8_t anahtar damla değerleri.

HIDL derleyicisi tarafından oluşturulan C++ sanal yöntemi:

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

Burada generate_cb bir işlev işaretçisi olarak tanımlanır:

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

Yani, generate_cb oluşturmak madde gösterilen dönüş değerleri alan bir fonksiyonudur. HAL uygulama sınıfı bu geçersiz generateKey yöntem ve aramaları generate_cb arayana işleminin sonucunu geri işlev işaretçisi. İşlev işaretçisi arama uyumlu olduğuna dikkat edin. Arayan çağırır generateKey ve generateKey denetim dönen tamamlanması için çalıştırır verilen işlev işaretçisi, aramalar generateKey uygulama, arayana daha sonra geri döner.

Ayrıntılı bir örnek için, varsayılan uygulama görmek hardware/interfaces/keymaster/3.0/default/KeymasterDevice.cpp . Varsayılan uygulama, eski tarz keymaster0, keymaster1 veya keymaster2 HALS ile cihazlar için geriye dönük uyumluluk sağlar.

Giriş kontrolu

Anahtar deposu erişim denetiminin en temel kuralı, her uygulamanın kendi ad alanına sahip olmasıdır. Ancak her kuralın bir istisnası vardır. Anahtar deposu, belirli sistem bileşenlerinin belirli diğer ad alanlarına erişmesine izin veren bazı sabit kodlanmış haritalara sahiptir. Bu, bir bileşene başka bir ad alanı üzerinde tam kontrol sağladığı için çok kör bir araçtır. Ve sonra, Keystore'un istemcileri olarak satıcı bileşenleri meselesi var. Şu anda, örneğin WPA sağlayıcısı gibi satıcı bileşenleri için bir ad alanı oluşturma yolumuz yok.

Satıcı bileşenlerini barındırmak ve sabit kodlanmış istisnalar olmadan erişim kontrolünü genelleştirmek için Keystore 2.0, etki alanlarını ve SELinux ad alanlarını sunar.

Anahtar Deposu Etki Alanları

Anahtar deposu etki alanları ile ad alanlarını UID'lerden ayırabiliriz. Anahtar Deposunda bir anahtara erişen istemciler, erişmek istedikleri etki alanını, ad alanını ve diğer adı belirtmelidir. Bu demete ve arayanın kimliğine dayanarak, arayanın hangi anahtara erişmek istediğini ve uygun izinlere sahip olup olmadığını belirleyebiliriz.

Anahtarlara nasıl erişilebileceğini yöneten beş etki alanı parametresi sunuyoruz. Anahtar tanımlayıcının ad alanı parametresinin anlamını ve erişim denetiminin nasıl gerçekleştirildiğini kontrol ederler.

  • DOMAIN_APP : Uygulama alanı eski davranışı kapsar. Java Anahtar Deposu SPI, varsayılan olarak bu etki alanını kullanır. Bu etki alanı kullanıldığında, ad alanı argümanı yok sayılır ve bunun yerine arayanın UID'si kullanılır. Bu etki alanına erişim sınıfı için Keystore etiketi ile kontrol edilir keystore_key SELinux'un politikası.
  • DOMAIN_SELINUX : Bu alan ad SELinux'un ilkesinde bir etiket olduğunu gösterir. Ad parametresi baktı ve bir hedef bağlamında çevrilmiş ve izin onay çağrısında SELinux'un bağlam için yapılır edilir keystore_key sınıfa. Verilen işlem için izin oluşturulduğunda, anahtar araması için tam demet kullanılır.
  • DOMAIN_GRANT : hibe alan ad parametresi bir hibe tanımlayıcı olduğunu gösterir. Diğer ad parametresi yoksayılır. SELinux kontrolleri, hibe oluşturulduğunda gerçekleştirilir. Daha fazla erişim kontrolü, yalnızca arayan UID'sinin, talep edilen iznin verilen UID'si ile eşleşip eşleşmediğini kontrol eder.
  • DOMAIN_KEY_ID : Bu alan ad parametre benzersiz bir anahtar kimliği olduğunu gösterir. Anahtar kendisi ile oluşturulmuş olabilir DOMAIN_APP veya DOMAIN_SELINUX . Sonra izin onay gerçekleştirilir domain ve namespace blob alanı, ad ve takma ilişki aracılığıyla yüklenmiş gibi aynı şekilde anahtar veritabanından yüklendi. Anahtar kimlik alanının mantığı sürekliliktir. Bir anahtara takma adla erişilirken, sonraki çağrılar farklı anahtarlarda çalışabilir, çünkü yeni bir anahtar oluşturulmuş veya içe aktarılmış ve bu takma adla ilişkilendirilmiş olabilir. Ancak anahtar kimliği asla değişmez. Bu nedenle, takma ad kullanılarak Anahtar Deposu veritabanından yüklendikten sonra anahtar kimliğine göre bir anahtar kullanıldığında, anahtar kimliği hala var olduğu sürece bunun aynı anahtar olduğundan emin olunabilir. Bu işlevsellik, uygulama geliştiricilerine açık değildir. Bunun yerine, aynı anda güvenli olmayan bir şekilde kullanıldığında bile daha tutarlı bir deneyim sağlamak için Android Keystore SPI içinde kullanılır.
  • DOMAIN_BLOB : blob alanı arayan tek başına damla yönetir belirtir. Bu, veri bölümü monte edilmeden önce Anahtar Deposuna erişmesi gereken istemciler için kullanılır. Anahtar damla dahildir blob anahtar tanımlayıcısı alanında.

SELinux etki alanını kullanarak, satıcı bileşenlerine, ayarlar iletişim kutusu gibi sistem bileşenleri tarafından paylaşılabilen çok özel Anahtar Deposu ad alanlarına erişim verebiliriz.

keystore_key için SELinux politikası

Ad alanı etiketleri kullanılarak yapılandırılan keystore2_key_context dosyayı.
Bu dosyalardaki her satır, sayısal bir ad alanı kimliğini bir SELinux etiketine eşler. Örneğin,

# 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

Bu şekilde yeni bir key namespace ayarladıktan sonra uygun bir politika ekleyerek ona erişim verebiliriz. Örneğin, izin wpa_supplicant biz aşağıdaki satırı eklersiniz yeni ad alanında olsun ve kullanım tuşları için hal_wifi_supplicant.te :

allow hal_wifi_supplicant wifi_key:keystore2_key { get, use };

Yeni ad alanını ayarladıktan sonra, AndroidKeyStore neredeyse her zamanki gibi kullanılabilir. Tek fark, ad alanı kimliğinin belirtilmesi gerektiğidir. Dan ve anahtar deposu içine anahtarları yükleme ve içe aktarmak için, ad kimliği kullanılarak belirtilir AndroidKeyStoreLoadStoreParameter . Örneğin,

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

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

Belirli bir ad alanında bir anahtar oluşturmak için, ad kimliği kullanılarak verilmelidir KeyGenParameterSpec.Builder#setNamespace():

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

Keystore 2.0 SELinux ad alanlarını yapılandırmak için aşağıdaki bağlam dosyaları kullanılabilir. Her bölüm, çarpışmaları önlemek için farklı bir ayrılmış 10.000 ad alanı kimliği aralığına sahiptir.

bölme Menzil Yapılandırma dosyaları
sistem 0 ... 9,999
/system/etc/selinux/keystore2_key_contexts, /plat_keystore2_key_contexts
Genişletilmiş Sistem 10.000 ... 19.999
/system_ext/etc/selinux/system_ext_keystore2_key_contexts, /system_ext_keystore2_key_contexts
Ürün 20.000 ... 29.999
/product/etc/selinux/product_keystore2_key_contexts, /product_keystore2_key_contexts
SATICI 30.000 ... 39.999
/vendor/etc/selinux/vendor_keystore2_key_contexts, /vendor_keystore2_key_contexts

İstemci bu durumda, SELinux'un domain ve istenilen sanal ad isteyerek anahtarı istediğinde "wifi_key" kendi sayısal kimliğine göre.

Bunun üzerinde, aşağıdaki ad alanları tanımlanmıştır. Özel kuralların yerini alırlarsa, aşağıdaki tablo, karşılık gelen UID'yi gösterir.

Ad alanı kimliği SE Politikası Etiketi kullanıcı kimliği Açıklama
0 su_key Yok Süper kullanıcı anahtarı. Yalnızca userdebug ve eng yapılarını test etmek için kullanılır. Kullanıcı yapılarında alakalı değil.
1 shell_key Yok Kabuk için kullanılabilir ad alanı. Çoğunlukla test için kullanılır, ancak komut satırından kullanıcı derlemelerinde de kullanılabilir.
100 vold_key Yok vold tarafından kullanılmak üzere tasarlanmıştır.
101 odsing_key Yok Cihazdaki imzalama arka plan programı tarafından kullanılır.
102 wifi_key AID_WIFI(1010) wpa_supplicant dahil olmak üzere Android'in Wifi sybsystem tarafından kullanılır.
120 özgeçmiş_on_reboot_key AID_SYSTEM(1000) Yeniden başlatma sırasında devam etmeyi desteklemek için Android'in sistem sunucusu tarafından kullanılır.

Vektörlere Erişim

SELinux'un sınıf keystore_key biraz ve bazı izinler, gibi yaşlı verify veya sign anlamlarını yitirmişlerdir. İşte izinleri, yeni dizi keystore2_key Keystore 2.0 zorunlu kılar ki.

İzin Anlam
delete Anahtar deposundan anahtarları kaldırırken kontrol edildi.
get_info Bir anahtarın meta verileri istendiğinde kontrol edilir.
grant Arayanın, hedef bağlamda anahtara bir hibe oluşturmak için bu izne ihtiyacı vardır.
manage_blob Arayan kullanabilir DOMAIN_BLOB böylece kendisi tarafından blob'ları yönetmek, verilen SELinux'un ad üzerinde. Bu özellikle vold için kullanışlıdır.
rebind Bu izin, bir diğer adın yeni bir anahtara geri döndürülüp döndürülemeyeceğini kontrol eder. Bu, ekleme için gereklidir ve önceden bağlanmış anahtarın silineceği anlamına gelir. Temelde bir ekleme iznidir, ancak anahtar deposunun anlamını daha iyi yakalar.
req_forced_op Bu izne sahip istemciler, kesintiye uğramayan işlemler oluşturabilir ve işlem oluşturma, tüm işlem yuvaları kesintiye uğramayan işlemler tarafından alınmadıkça asla başarısız olmaz.
update Bir anahtarın alt bileşenini güncellemek için gereklidir.
use Anahtar malzemesini kullanan bir Keymint işlemi oluştururken kontrol edilir, örneğin imzalama, şifreleme/şifre çözme için.
use_dev_id Cihaz kimliği onayı gibi cihaz tanımlama bilgileri oluşturulurken gereklidir.

Ayrıca, SELinux güvenlik sınıfı olmayan anahtar spesifik anahtar deposu izin kümesi dışarı bölmek keystore2 :

İzin Anlam
add_auth Kimlik doğrulama belirteçleri eklemek için Gatekeeper veya BiometricsManager gibi kimlik doğrulama sağlayıcısı tarafından gereklidir.
clear_ns Önceden clear_uid, bu izin, bir ad alanının sahibi olmayan bir kişinin o ad alanındaki tüm anahtarları silmesine izin verir.
list Sahiplik veya yetki sınırı gibi çeşitli özelliklere göre anahtarları numaralandırmak için sistem tarafından gereklidir. Bu izin, kendi ad alanlarını numaralandıran arayanlar için gerekli değildir. Bu kaplıdır get_info izni.
lock Bu izin, Anahtar Deposu'nun kilitlenmesine, yani ana anahtarın çıkarılmasına, böylece yetkilendirme bağlantılı anahtarların kullanılamaz ve oluşturulamaz hale gelmesine izin verir.
reset Bu izin, Android işletim sisteminin çalışması için hayati önem taşımayan tüm anahtarları silerek Keystore'u fabrika varsayılanına sıfırlamaya izin verir.
unlock Bu izin, yetkilendirme bağlantılı anahtarlar için ana anahtarın kilidini açmaya çalışmak için gereklidir.