Donanım destekli Anahtar Deposu

Ç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 zaten 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 uygulanıyor ancak yalnızca bir imza API'si ile kolayca ulaşılamayacak birçok güvenlik hedefi var. Android 6.0'daki Keystore, Keystore API'sini daha geniş bir yetenek yelpazesi sağlayacak şekilde genişletti.

Android 6.0'da Keystore, simetrik şifreleme temel öğelerini , AES ve HMAC'yi ve donanım destekli anahtarlar için bir erişim kontrol sistemini ekledi. Erişim kontrolleri 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 belirli amaçlarla veya belirli şifreleme parametreleriyle kullanılabilecek şekilde sınırlandırılabilir. Daha fazla bilgi için Yetkilendirme Etiketleri ve İşlevler sayfalarına bakın.

Android 6.0'daki Keystore, kriptografik temel öğelerin aralığını genişletmenin yanı sıra aşağıdakileri de 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 olanak tanıyan 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 için destek ekledi. Anahtar doğrulama, anahtarın güvenli donanımdaki varlığını ve yapılandırmasını uzaktan doğrulanabilir hale getirmek için anahtarın ve erişim kontrollerinin ayrıntılı bir açıklamasını içeren ortak anahtar sertifikaları sağlar.

Sürüm bağlama, anahtarları işletim sistemine ve yama düzeyi sürümüne 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, cihazı güvenlik açığı bulunan sürüme geri döndürememesi ve yeni sürümle oluşturulan anahtarları kullanamaması anlamına gelir. Ayrıca, belirli bir sürüme ve yama düzeyine sahip bir anahtar, daha yeni bir sürüme veya yama düzeyine yükseltilmiş bir cihazda kullanıldığında, anahtar kullanılmadan önce yükseltilir ve anahtarın önceki sürümü geçersiz kılınır. Cihaz yükseltildikçe, tuşlar cihazla birlikte ileri doğru "mandallanır", ancak cihazın önceki bir sürüme geri döndürülmesi, tuşların kullanılamaz olmasına 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, türler ve yöntemler eski türler ve HAL yapı yöntemleriyle birebir örtüşse de argüman türlerinin çoğu değişti. 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ğrulamayı destekleyecek şekilde genişletti. Kimlik doğrulaması, cihazın seri numarası, ürün adı ve telefon kimliği (IMEI / MEID) gibi donanım tanımlayıcılarının güçlü bir şekilde doğrulanması için sınırlı ve isteğe bağlı bir mekanizma sağlar. Bu eklemeyi uygulamak için Android 8.0, ASN.1 kanıtlama şemasını kimlik doğrulaması ekleyecek şekilde değiştirdi. Keymaster uygulamalarının, ilgili veri öğelerini almak için güvenli bir yol bulması ve özelliğin güvenli ve kalıcı olarak devre dışı bırakılması için bir mekanizma tanımlaması gerekir.

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

  • Keymaster 4'e güncelleme
  • Gömülü 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ümlere sahip olması için sürüm bağlamada yapılan değişiklikler

Sözlük

Burada Keystore bileşenlerine ve bunların ilişkilerine hızlı bir genel bakış verilmiştir.

AndroidKeystore , uygulamalar tarafından Anahtar Deposu işlevine erişmek için kullanılan Android Çerçeve API'si ve bileşenidir. 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 Anahtar Deposu davranışına yönelik uygulama isteklerini anahtar deposu arka plan programına ileterek yerine getirir.

Anahtar deposu arka plan programı , 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 materyalini içeren "anahtar bloblarının" şifrelenmiş olarak saklanmasından sorumludur, böylece Keystore bunları saklayabilir ancak kullanamaz veya ifşa edemez.

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

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

LockSettingsService , hem şifre hem de parmak izi olarak kullanıcı kimlik doğrulamasından sorumlu Android sistem bileşenidir. Bu, Anahtar Deposu'nun bir parçası değildir, ancak birçok Anahtar Deposu anahtar işleminin kullanıcı kimlik doğrulaması gerektirmesi nedeniyle alakalıdır. LockSettingsService anahtar deposu arka plan programına sağladığı ve sonuçta Keymaster TA uygulaması tarafından tüketilen kimlik doğrulama belirteçlerini elde etmek için Gatekeeper TA ve Fingerprint TA ile etkileşime girer.

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

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

Mimari

Android Anahtar Deposu API'si ve temeldeki Keymaster HAL, erişim kontrollü, donanım destekli anahtarlar kullanan protokollerin uygulanmasına izin vermek için temel ancak yeterli bir şifreleme ilkelleri seti 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üklenebilen bir kitaplıktır. HAL uygulamaları, işleri güvende tutmak için kullanıcı alanında, hatta çekirdek alanında herhangi bir hassas işlem gerçekleştirmez. Hassas işlemler, bazı çekirdek arayüzleri aracılığıyla ulaşılan güvenli bir işlemciye devredilir. Ortaya çıkan mimari şuna benzer:

Keymaster'a erişim

Şekil 1. Keymaster'a Erişim

Bir Android cihazında, Keymaster HAL'nin "istemcisi" birden fazla katmandan oluşur (örn. uygulama, çerçeve, Keystore arka plan programı), ancak bu belgenin amaçları açısından bunlar göz ardı edilebilir. Bu, açıklanan Keymaster HAL API'nin düşük düzeyde olduğu, platformun dahili bileşenleri tarafından kullanıldığı ve uygulama geliştiricilerin kullanımına sunulmadığı anlamına gelir. Üst düzey API, Android Geliştirici sitesinde açıklanmaktadır.

Keymaster HAL'in amacı güvenliğe duyarlı algoritmaları uygulamak değil, yalnızca istekleri güvenli dünyaya sıralamak ve sıralamayı kaldırmaktır. Wire formatı uygulama tanımlıdır.

Önceki sürümlerle uyumluluk

Keymaster 1 HAL, daha önce yayınlanmış olan HAL'lerle (örn. Keymaster 0.2 ve 0.3) tamamen uyumsuzdur. Eski Keymaster HAL'lerle 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, Keymaster 1 HAL'yi mevcut donanım kitaplığına yapılan çağrılarla uygulayan bir bağdaştırıcı sağlar. Sonuç, Keymaster 1 HAL'deki tüm işlevleri sağlayamaz. Özellikle yalnızca RSA ve ECDSA algoritmalarını destekler ve tüm anahtar yetkilendirme uygulamaları, 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 arayüzünü daha da basitleştirdi. Bu, girişin aynı anda mevcut olduğu durumlarda TEE'ye gidiş-dönüş sayısını azaltır ve AEAD şifre çözmenin uygulanması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ının alt sınıflanması ve saf sanal yöntemlerin uygulanmasıyla yeni stilde bir HAL uygulaması oluşturulur. Değişikliğin bir parçası olarak, türler ve yöntemler eski türler ve HAL yapı yöntemleriyle birebir örtüşse de argüman türlerinin çoğu değişti.

HIDL'ye genel bakış

Donanım Arayüzü Tanımlama Dili (HIDL), donanım arayüzlerini belirlemek için uygulama dilinden bağımsız bir mekanizma sağlar. HIDL araçları şu anda C++ ve Java arayüzlerinin oluşturulmasını desteklemektedir. Çoğu Güvenilir Yürütme Ortamı (TEE) uygulayıcısının C++ araçlarını daha kullanışlı bulması beklenmektedir, bu nedenle bu belge yalnızca C++ gösterimini ele almaktadır.

HIDL arayüzleri şu şekilde 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ürlerini 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ğıdakine eşdeğerdir:

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 sürümünde dev argümanı örtülü olduğundan kaldırılmıştır. params argümanı artık bir key_parameter_t nesneleri dizisine başvuran bir işaretçi içeren bir yapı değil, KeyParameter nesnelerini içeren bir vec (vektör) şeklindedir. Dönüş değerleri, anahtar blob için uint8_t değerlerinin bir vektörü de dahil olmak üzere " generates " cümlesinde listelenir.

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

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 yer:

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

Yani, generateKey_cb created cümleciğinde 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 çağırana 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ğunu unutmayın. Arayan, generateKey çağırır ve generateKey , sağlanan işlev işaretçisini çağırır; bu, tamamlanana kadar yürütülür, kontrolü generateKey uygulamasına geri verir ve daha sonra arayan kişiye geri döner.

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

Giriş kontrolu

Keystore erişim kontrolünün en temel kuralı, her uygulamanın kendi ad alanına sahip olmasıdır. Ancak her kuralın bir istisnası vardır. Anahtar deposunda, belirli sistem bileşenlerinin diğer belirli ad alanlarına erişmesine izin veren bazı sabit kodlanmış haritalar bulunur. Bu, bir bileşene başka bir ad alanı üzerinde tam kontrol sağladığından çok kör bir araçtır. Ve sonra Keystore'un istemcileri olarak satıcı bileşenleri meselesi var. Şu anda satıcı bileşenleri için, örneğin WPA istemcisi için bir ad alanı oluşturma yöntemimiz 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 Alan Adları

Keystore alan adlarıyla ad alanlarını UID'lerden ayırabiliriz. Anahtar Deposunda bir anahtara erişen istemcilerin, erişmek istedikleri etki alanını, ad alanını ve takma adı belirtmeleri gerekir. Bu tuple 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 kontrolünün 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ı bağımsız değişkeni göz ardı edilir ve bunun yerine arayanın UID'si kullanılır. Bu etki alanına erişim, SELinux politikasındaki keystore_key sınıfının Anahtar Deposu etiketi tarafından kontrol edilir.
  • DOMAIN_SELINUX : Bu alan adı, SELinux politikasında ad alanının bir etikete sahip olduğunu belirtir. Ad alanı parametresi aranır ve hedef bağlama çevrilir ve keystore_key sınıfı için çağrılan SELinux bağlamı için bir izin kontrolü gerçekleştirilir. Verilen işlem için izin oluşturulduğunda anahtar arama için tam tuple kullanılır.
  • DOMAIN_GRANT : Hibe alanı, ad alanı parametresinin bir hibe tanımlayıcısı olduğunu belirtir. Takma ad parametresi göz ardı edilir. Hibe oluşturulduğunda SELinux kontrolleri gerçekleştirilir. Daha fazla erişim kontrolü yalnızca arayan UID'nin, talep edilen yetkinin yetkilendirilen UID'siyle 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 belirtir. Anahtarın kendisi DOMAIN_APP veya DOMAIN_SELINUX ile oluşturulmuş olabilir. İzin kontrolü, domain ve namespace blob etki alanı, ad alanı ve takma ad tanımlama grubu tarafından yüklenmiş gibi aynı şekilde anahtar veritabanından yüklendikten sonra gerçekleştirilir. Anahtar kimlik alanının mantığı sürekliliktir. Bir anahtara takma adla erişildiğinde, yeni bir anahtar oluşturulmuş veya içe aktarılmış ve bu takma ada bağlanmış olabileceğinden sonraki çağrılar farklı anahtarlar üzerinde gerçekleştirilebilir. Ancak anahtar kimliği hiçbir zaman değişmez. Bu nedenle, takma adı kullanarak Keystore veritabanından yüklendikten sonra anahtar kimliğine göre bir anahtar kullanıldığında, anahtar kimliği hala mevcut 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 Anahtar Deposu SPI'sı 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ü bağlanmadan önce Anahtar Deposuna erişmesi gereken istemciler için kullanılır. Anahtar blob, anahtar tanımlayıcı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.

Anahtar deposu_anahtarı 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 anahtar ad alanı oluşturduktan sonra uygun bir politika ekleyerek ona erişim verebiliriz. Örneğin, wpa_supplicant yeni ad alanındaki anahtarları almasına ve kullanmasına izin vermek için hal_wifi_supplicant.te dosyasına aşağıdaki satırı ekleyeceğiz:

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 belirtilmesinin zorunlu olmasıdır. Anahtarları Keystore'a 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ğinin 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ün, çarpışmaları önlemek için 10.000 ad alanı kimliğinden oluşan farklı bir ayrılmış aralığı vardır.

Bölüm 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 istenen sanal ad alanını (bu durumda "wifi_key" sayısal kimliğiyle isteyerek anahtarı ister.

Bunun üzerinde aşağıdaki ad alanları tanımlanmıştır. Özel kuralların yerine geçerlerse aşağıdaki tablo, bunların karşılık geldiği UID'yi gösterir.

Ad alanı kimliği SEPolitika Etiketi UID Tanım
0 su_key Yok Süper kullanıcı anahtarı. Yalnızca kullanıcı hata ayıklama ve eng yapılarında test yapmak için kullanılır. Kullanıcı yapılarıyla alakalı değil.
1 kabuk_anahtarı Yok Kabuk için kullanılabilir ad alanı. Çoğunlukla test amaçlı kullanılır, ancak kullanıcı yapılarında komut satırından da kullanılabilir.
100 vold_key Yok vold tarafından kullanılmak üzere tasarlanmıştır.
101 ossing_key Yok Cihazdaki imzalama programı tarafından kullanılır.
102 wifi_anahtarı AID_WIFI(1010) Wpa_supplicant dahil olmak üzere Android'in Wifi sistemi tarafından kullanılır.
120 devam_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 oldukça eskidi ve verify veya sign gibi bazı izinler anlamını yitirdi. İşte Keystore 2.0'ın uygulayacağı keystore2_key adlı yeni izinler kümesi.

İzin Anlam
delete Anahtar deposundan anahtarlar kaldırılırken kontrol edilir.
get_info Bir anahtarın meta verileri istendiğinde işaretlenir.
grant Arayanın, hedef bağlamda anahtara bir yetki oluşturmak için bu izne ihtiyacı vardır.
manage_blob Arayan, 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 takma 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ğlanan 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, budanamayan işlemler oluşturabilir ve tüm işlem yuvaları budanamayan işlemler tarafından alınmadığı sürece işlem oluşturma asla başarısız olmaz.
update Bir anahtarın alt bileşenini güncellemek için gereklidir.
use Anahtar materyalini kullanan bir Keymint işlemi (örn. imzalama, şifreleme/şifre çözme) oluşturulurken kontrol edilir.
use_dev_id Cihaz kimliği onayı gibi cihaz tanımlama bilgileri oluşturulurken gereklidir.

Ek olarak, SELinux güvenlik sınıfı keystore2 deposu2'de anahtara özgü olmayan bir dizi anahtar deposu izinlerini ayırdık:

İzin Anlam
add_auth Kimlik doğrulama belirteçlerinin eklenmesi için Gatekeeper veya BiometricsManager gibi kimlik doğrulama sağlayıcıları tarafından gereklidir.
clear_ns Eskiden clear_uid olan bu izin, bir ad alanının sahibi olmayan birinin o ad alanındaki tüm anahtarları silmesine olanak tanır.
list Anahtarların sahiplik veya kimlik doğrulama sınırlılığı gibi çeşitli özelliklere göre numaralandırılması için sistem tarafından gereklidir. Bu izin, kendi ad alanlarını numaralandıran arayanlar için gerekli değildir. Bu, get_info izninin kapsamındadır.
lock Bu izin, Anahtar Deposunun kilitlenmesine, yani kimlik doğrulamaya bağlı anahtarların kullanılamaz ve oluşturulamaz hale gelmesi için ana anahtarın çıkarılmasına olanak tanır.
reset Bu izin, Android işletim sisteminin işleyişi için hayati önem taşımayan tüm anahtarları silerek Anahtar Deposunu fabrika varsayılanına sıfırlamanıza olanak tanır.
unlock Bu izin, kimlik doğrulama anahtarlarına ilişkin ana anahtarın kilidini açmaya çalışmak için gereklidir.