Ç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:
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ındakikeystore_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 vekeystore_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 kendisiDOMAIN_APP
veyaDOMAIN_SELINUX
ile oluşturulmuş olabilir. İzin kontrolü,domain
venamespace
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 adla ilişkilendirilmiş 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ınblob
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. |