Donanım destekli Anahtar Deposu

Bir çip üzerindeki bir sistemde (SoC) güvenilir bir yürütme ortamının bulunması, Android cihazlarını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 özgü uzantıları arayan geliştiriciler, android.security.keystore adresine gitmelidir.

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'da Keystore, simetrik şifreleme ilkelleri , AES ve HMAC ve donanım destekli anahtarlar için bir erişim kontrol sistemi ekledi. 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 Yetkilendirme Etiketleri ve İşlevler sayfalarına bakın.

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ğlamak için bir erişim kontrol şeması

Android 7.0'da Keymaster 2, anahtar doğrulama ve sürüm bağlama desteği ekledi. Anahtar onayı, anahtarın güvenli donanımdaki varlığını ve yapılandırmasını uzaktan doğrulanabilir kılmak için anahtarın ve erişim kontrollerinin ayrıntılı bir tanımını içeren ortak anahtar sertifikaları sağlar.

Sürüm bağlama , anahtarları işletim sistemine ve yama düzeyindeki sürüme bağlar. 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. Daha fazla ayrıntı için İşlevler sayfasına bakın.

Bu arayüz revizyonuna ek olarak, Android 8.0, Keymaster 2'nin doğrulama özelliğini kimlik doğrulamasını destekleyecek şekilde genişletti. 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:

  • Keymaster 4'e güncelleme
  • 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 verecek şekilde 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 , Android Framework API'si ve uygulamalar tarafından Anahtar Deposu işlevine erişmek için kullanılan bileşendir. Standart Java Şifreleme Mimarisi API'lerinin bir uzantısı olarak uygulanır ve uygulamanın kendi işlem alanında çalışan Java kodundan oluşur. AndroidKeystore , Keystore davranışına yönelik uygulama isteklerini anahtar deposu arka plan programına ileterek karşılar.

Anahtar deposu arka plan programı , bir Binder API aracılığıyla tüm Anahtar Deposu işlevlerine erişim sağlayan bir Android sistem arka plan programıdır. Gerçek gizli anahtar malzemesini içeren "anahtar bloblarını" depolamaktan sorumludur, böylece Keystore bunları saklayabilir, ancak kullanamaz veya gösteremez.

keymasterd , Keymaster TA'ya erişim sağlayan bir HIDL sunucusudur. (Bu ad standardize edilmemiştir ve kavramsal amaçlıdır.)

Keymaster TA (güvenilir uygulama), güvenli bir bağlamda, çoğunlukla bir ARM SoC'de TrustZone'da çalışan, tüm güvenli Anahtar Deposu işlemlerini sağlayan, ham anahtar malzemesine erişimi olan, anahtarlar üzerindeki tüm erişim kontrol koşullarını doğrulayan yazılımdır. , vb.

LockSettingsService , hem parola hem de parmak izi olmak üzere kullanıcı kimlik doğrulamasından 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 , anahtar deposu arka plan programına sağladığı ve nihai olarak Keymaster TA uygulaması tarafından tüketilen kimlik doğrulama belirteçlerini almak için Gatekeeper TA ve Fingerprint TA ile etkileşime girer.

Gatekeeper TA (güvenilir uygulama), güvenli bağlamda çalışan ve kullanıcı parolalarının kimliğinin doğrulanmasından ve belirli bir zamanda belirli bir kullanıcı için bir kimlik doğrulamasının yapıldığını Keymaster TA'ya kanıtlamak için kullanılan kimlik doğrulama belirteçlerinin oluşturulmasından sorumlu olan başka bir bileşendir.

Parmak İzi TA (güvenilir uygulama), güvenli bağlamda çalışan ve kullanıcı parmak izlerinin kimliğinin doğrulanmasından ve belirli bir zamanda belirli bir kullanıcı için bir kimlik doğrulamasının yapıldığını Keymaster TA'ya kanıtlamak için kullanılan kimlik doğrulama belirteçlerinin oluşturulmasından sorumlu olan başka bir bileşendir.

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

Şekil 1. Keymaster'a Erişim

Bir Android aygıtında, Keymaster HAL'nin "istemcisi" birden çok katmandan (ör. uygulama, çerçeve, Keystore arka plan programı) oluşur, ancak bu, bu belgenin amaçları doğrultusunda 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, Android Geliştirici sitesinde açıklanmaktadır.

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, get_supported_* yöntemlerini kaldırarak ve finish() yönteminin girişi kabul etmesine izin vererek HAL arabirimini daha da basitleştirdi. 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ı. Oluşturulan IKeymasterDevice sınıfı alt sınıflara ayrılarak ve saf sanal yöntemler uygulanarak yeni stil bir HAL uygulaması oluşturulur. 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++ temsili ele alınmaktadır.

HIDL arabirimleri, aşağıdaki gibi ifade edilen bir dizi yöntemden 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 Referans bölümüne bakın .

Keymaster 3 IKeymasterDevice.hal örnek bir yöntem:

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, örtük olduğu için dev argümanı kaldırılmıştır. params argümanı artık KeyParameter nesnelerinin bir dizisine başvuran bir işaretçi içeren bir yapı değil, key_parameter_t nesnelerini içeren bir vec (vektör). Anahtar blobu için bir uint8_t değerleri vektörü de dahil olmak üzere, dönüş değerleri " generates " yan tümcesinde listelenir.

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

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

generateKey_cb şu şekilde tanımlanan bir işlev işaretçisi olduğu yerde:

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

Yani, generateKey_cb , create yan tümcesinde listelenen dönüş değerlerini alan bir işlevdir. HAL uygulama sınıfı, bu generateKey yöntemini geçersiz kılar ve işlemin sonucunu arayana döndürmek için generateKey_cb işlev işaretçisini çağırır. İşlev işaretçisi çağrısının eşzamanlı olduğuna dikkat edin. Çağıran, generateKey çağırır ve generateKey , sağlanan işlev işaretçisini çağırır; bu, tamamlanana kadar yürütülür ve denetimi, generateKey uygulamasına geri döndürür ve ardından, arayana geri döner.

Ayrıntılı bir örnek için, hardware/interfaces/keymaster/3.0/default/KeymasterDevice.cpp içindeki varsayılan uygulamaya bakın. 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 etki 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, SELinux ilkesindeki keystore_key sınıfının Keystore etiketi tarafından kontrol edilir.
  • DOMAIN_SELINUX : Bu etki alanı, ad alanının SELinux ilkesinde bir etiketi olduğunu gösterir. Ad alanı parametresi aranır ve bir hedef bağlama çevrilir ve keystore_key sınıfı için çağıran SELinux bağlamı için bir izin denetimi gerçekleştirilir. Verilen işlem için izin oluşturulduğunda, anahtar araması için tam demet kullanılır.
  • DOMAIN_GRANT : Hibe etki alanı, ad alanı parametresinin bir hibe tanımlayıcısı olduğunu belirtir. 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 hibe alan UID'si ile eşleşip eşleşmediğini kontrol eder.
  • DOMAIN_KEY_ID : Bu etki alanı, ad alanı parametresinin benzersiz bir anahtar kimliği olduğunu gösterir. Anahtarın kendisi DOMAIN_APP veya DOMAIN_SELINUX ile oluşturulmuş olabilir. İzin denetimi, domain ve namespace , blob etki alanı, ad alanı ve diğer ad demeti tarafından yüklenmiş gibi, anahtar veritabanından yüklendikten sonra gerçekleştirilir. Anahtar kimlik alanının mantığı sürekliliktir. Bir anahtara takma adla erişirken, 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 etki alanı, arayanın blobu kendi başına yönettiğini gösterir. Bu, veri bölümü monte edilmeden önce Anahtar Deposuna erişmesi gereken istemciler için kullanılır. Anahtar blob, anahtar tanımlayıcısının blob alanına dahil edilir.

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 sağlayabiliriz.

keystore_key için SELinux politikası

Ad alanı etiketleri, keystore2_key_context dosyası kullanılarak yapılandırılır.
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, wpa_supplicant yeni ad alanında anahtarları almasına ve kullanmasına izin vermek için hal_wifi_supplicant.te aşağıdaki satırı ekleriz:

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. Anahtarları Keystore'dan yüklemek ve Keystore'a aktarmak için ad alanı kimliği AndroidKeyStoreLoadStoreParameter kullanılarak belirtilir. Ö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 alanı kimliği 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, SELinux etki alanını ve bu durumda "wifi_key" istenen sanal ad alanını sayısal kimliğiyle talep ederek anahtarı ister.

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 Tanım
0 su_key Yok Süper kullanıcı anahtarı. Yalnızca userdebug ve eng yapılarında test yapmak 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 sınıfı keystore_key biraz eskidi ve verify veya sign gibi bazı izinler anlamlarını kaybetti. Keystore 2.0'ın uygulayacağı yeni izinler keystore2_key buradadır.

İ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 Çağıran, verilen SELinux ad alanında DOMAIN_BLOB kullanabilir, böylece blobları kendi başına yönetebilir. 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.

Ek olarak, SELinux güvenlik sınıfı keystore2 bir dizi anahtara özgü olmayan anahtar deposu izinlerini böldük:

İ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 olan 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, get_info izni kapsamındadır.
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.