Çip üzerindeki bir sistemde güvenilir yürütme ortamının kullanılabilirliği (SoC), Android cihazlara donanım destekli, donanım destekli Android OS'ten platform hizmetlerine ve hatta üçüncü taraf uygulamaları. Android'e özel uzantılar arayan geliştiricilerin web sitesini ziyaret etmesi gerekir android.security.keystore adresine gönderin.
Android 6.0'dan önce Android'de donanım destekli basit bir kripto zaten vardı Keymaster Donanım sürümünün 0.2 ve 0.3 sürümleri tarafından sağlanan hizmetler API'si Soyutlama Katmanı (HAL). Anahtar deposu tarafından sağlanan dijital imzalama ve doğrulama işlemleri, ayrıca asimetrik imzalama anahtar çiftlerinin oluşturulması ve içe aktarılması. Bu ancak çoğu cihazda uygulanmasına rağmen, yalnızca bir imza API'sıyla gerçekleştirilemez. Android 6.0'da anahtar deposu Keystore API'yi daha geniş bir özellik yelpazesi sunmak için genişletti.
Android 6.0'da, Anahtar Deposu eklendi simetrik kriptografik temel öğeleri, AES ve HMAC ile donanım destekli anahtarlar için bir erişim kontrol sistemi. Erişme Kontroller, anahtar oluşturma sırasında belirtilir ve gerekir. Anahtarlar, yalnızca kullanıcı işlemi gerçekleştirildikten sonra kullanılabilir ve yalnızca belirtilen amaçlar için veya belirtilen kriptografik özellik ile parametreleridir. Daha fazla bilgi için Yetkilendirme Etiketleri ve İşlevler sayfaları
Temel kriptografi öğelerinin kapsamını genişletmenin yanı sıra Android 6.0'a aşağıdaki özellikler eklendi:
- Anahtar kullanımının kısıtlanmasını sağlayarak anahtarların hatalı kullanımından kaynaklanan güvenlik ihlali riski
- Anahtarların belirli kullanıcılarla kısıtlanmasını sağlayan bir erişim kontrol şeması ve tanımlanmış bir zaman aralığı
Android 7.0'da Keymaster 2, anahtar onayı ve sürümü için destek ekledi bağlama'yı tıklayın. Anahtar onayı anahtarın ayrıntılı açıklamasını içeren ortak anahtar sertifikalarını sağlar ve erişim denetimlerini kullanarak anahtarın güvenli donanım ve donanım üzerindeki varlığını uzaktan doğrulanabilir.
Sürüm bağlama anahtarları, işletim sistemine ve yama düzeyindeki sürüme bağlar. Böylece proje daha sistemin eski bir sürümünde bir zayıflık olduğunu keşfeden veya TEE yazılımları bir cihazı güvenlik açığı içeren sürüme geri döndüremez ve anahtarları kullanamaz yeni sürümle oluşturulur. Ayrıca, belirli bir sürüme sahip bir anahtar Daha yeni bir sürüme geçirilen cihazlarda yama düzeyi kullanılıyorsa anahtarın kullanılmadan önce yeni sürüme geçirilmesi ve anahtar sürümü geçersiz kılındı. Cihaz yükseltilirken "mandallı" tuşları cihazla birlikte yönlendirilmelidir, ancak cihazın önceki bir sürüme geri döndürülmesi anahtarların kullanılamaz hale gelmesine neden olur.
Android 8.0'da Keymaster 3, eski stil C yapısında bulunan Donanımdan geçiş yaptı Bir tanımdan oluşturulan C++ HAL arayüzüne soyutlama katmanı (HAL) yeni Donanım Arayüzü Tanımlama Dili'nde (HIDL) bulabilirsiniz. Bu değişikliğin bir parçası olarak, birçok bağımsız değişken türü değişti, ancak tür ve yöntemler bire bir eski türlerle ve HAL yapı yöntemleriyle yazışmaktır. Bkz. Daha fazlası için İşlevler sayfasında bolca fırsat sunuyor.
Bu arayüz düzeltmesine ek olarak, Android 8.0 genişletilmiş Keymaster 2 onay özelliğini kullanarak Kimlik onayı. Kimlik onayı, güçlü onay için sınırlı ve isteğe bağlı bir mekanizma sağlar cihaz seri numarası, ürün adı ve telefon gibi donanım tanımlayıcılarına kimliği (IMEI / MEID). Android 8.0, bu eklemeyi uygulamak için ASN.1'i değiştirdi. onay şeması oluşturun. Keymaster uygulamalarının yanı sıra ilgili veri öğelerini almanın güvenli bir yolunu bulmanın yanı sıra, özelliği güvenli ve kalıcı olarak devre dışı bırakma mekanizmasıdır.
Android 9'da güncellemeler şunları içeriyordu:
- Şu sürüme güncelle: Anahtar Yöneticisi 4
- Yerleştirilmiş Güvenlik Unsuru desteği
- Güvenli anahtarı içe aktarma desteği
- 3DES şifreleme desteği
- Sürüm bağlamada yapılan, boot.img ve system.img komutlarını içeren değişiklikler bağımsız güncellemelere olanak tanımak için sürümleri ayrı ayrı ayarlayın
Sözlük
Keystore bileşenleri ve bunların ilişkilerine hızlıca genel bir bakışı burada bulabilirsiniz.
AndroidKeystore, Android Framework API ve kullanılan bileşendir
Anahtar Deposu işlevine erişmek için uygulamalar tarafından etkinleştirilir. Gelecekteki projelerinizde
API'lerden oluşur ve geliştirilen Java kodundan oluşur.
uygulamanın kendi işlem alanında çalışır. AndroidKeystore, uygulamayı karşılıyor
anahtar deposu arka plan programına yönlendirerek Anahtar Deposu davranışı isteklerinden bahsedeceğiz.
keystore arka plan programı bir Android sistem arka plan programıdır; Binder API aracılığıyla tüm Anahtar Deposu işlevlerine erişebilir. Bunlar, anahtar blob'ları depolamak için gerçek gizli anahtar materyalini içerir. Anahtar Deposu bunları depolayabilir, ancak açıklamayacaktır.
keymasterd, şuraya erişim sağlayan bir HIDL sunucusudur: Keymaster TA. (Bu ad standart hale getirilmemiştir ve kavram amaçlıdır.)
Keymaster TA (güvenilir uygulama) sağlayan, ARM SoC'deki TrustZone'da genellikle anahtar deposu işlemlerini gerçekleştirmenize yardımcı olur, ham anahtar materyaline erişebilir, tüm anahtarlardaki erişim denetimi koşulları gibi.
LockSettingsService, bu programdan sorumlu Android sistem bileşenidir
(kullanıcı kimlik doğrulaması için) (hem şifre hem de parmak izi) destekler. Bu hizmet,
Anahtar deposu, ancak birçok Anahtar Deposu anahtar işlemi kullanıcı gerektirdiği için önemlidir
kimlik doğrulama. LockSettingsService, Kapı Görevlisi ile etkileşim kuruyor
TA ve Parmak İzi TA'nın kimlik doğrulama jetonlarını alması için
anahtar deposu arka plan programıdır ve nihai olarak Keymaster TA tarafından kullanılan
bir uygulamadır.
Gatekeeper TA (güvenilir uygulama) başka bir bileşendir. kullanıcı kimliğini doğrulamaktan sorumlu olan güvenli bağlamda Keymaster TA'ya bunu kanıtlamak için kullanılan şifreler ve kimlik doğrulama jetonları oluşturma bir kullanıcı için kimlik doğrulamasının belli bir noktada yapıldığını gerekir.
Parmak İzi TA (güvenilir uygulama) başka bir bileşendir kullanıcının kimliğini doğrulamaktan sorumlu güvenli bağlamda çalışan Keymaster'a kendini kanıtlamak için kullanılan dijital parmak izleri ve kimlik doğrulama jetonları oluşturma TA, bir kimlik doğrulama işleminin belirli bir noktada belirli bir kullanıcı için yapıldığını gösterir gerekiyor.
Mimari
Android Keystore API ve temel Keymaster HAL verilerin şifrelenmesine izin vermek için temel ancak yeterli miktarda temel kriptografi Protokollerin uygulanması için erişim kontrollü, donanım destekli anahtarlar kullanır.
Keymaster HAL, OEM tarafından sağlanan ve dinamik olarak yüklenebilen bir kitaplıktır. Anahtar Deposu hizmetini kullanarak donanım destekli şifreleme hizmetleri sunabilirsiniz. Saklamak için HAL uygulamaları, başka hiçbir veri deposunda hassas işlemler hatta çekirdek alanında bile olmayabilir. Hassas işlemler bir güvenli işlemciye kadar (ör. belirli çekirdek arayüzleri) Elde edilen mimari şöyle görünür:
Şekil 1. Keymaster'a Erişim
Android cihazlarda "istemci" Keymaster HAL şunlardan oluşur: birden fazla katman (ör. uygulama, çerçeve, Keystore arka plan programı) içerir, ancak bu yoksayılabilir bu belgenin amaçları doğrultusunda kullanılması. Bu, açıklanan Keymaster HAL'nin API alt düzey olup dahili platform bileşenleri tarafından kullanılır ve uygulamaya açılmaz birlikte çalışır. Üst düzey API, Android Developers sitesinde açıklanmaktadır.
Keymaster HAL'nin amacı, güvenlik açısından hassas güvenli dünyaya sunmaları için yalnızca marşal ve mareşal kaldırma talepleri ile çalışmaktadır. İlgili içeriği oluşturmak için kullanılan kablo biçimi, uygulama tarafından tanımlanmıştır.
Önceki sürümle uyumluluk sürümler
Keymaster 1 HAL, önceden yayınlanan HAL'ler (ör. Keymaster 0.2 ve 0.3. Kolaylaştırmak için Android 5.0 ve önceki sürümleri çalıştıran cihazlarda birlikte çalışabilirlik Keymaster HAL'lerini geride bırakırken Keystore, Mevcut donanım kitaplığına yapılan çağrıları olan Keymaster 1 HAL. Sonuç, Keymaster 1 HAL'de tüm işlevleri sunar. Özellikle, yalnızca RSA ve ECDSA algoritmalarını ve tüm anahtar yetkilendirme işlevlerini destekler. güvenli olmayan ortamda bağdaştırıcı tarafından uygulanır.
Keymaster 2,
get_supported_* yöntemleri ve finish() izin verdiği için
yöntemini kullanın. Bu da TEE'ye yapılan gidiş dönüş sayısının
tüm bunların aynı anda kullanılabilir olduğu ve proje yaşam döngüsünün
AEAD şifre çözme.
Android 8.0'da Keymaster 3, eski stil C yapısından geçiş yaptı
Yeni
Donanım Arayüzü Tanımlama Dili (HIDL). Yeni tarz bir HAL
uygulama, oluşturulan verinin alt sınıflandırılmasıyla
IKeymasterDevice sınıf ve saf sanal uygulama
yöntemlerine göz atın. Bu değişiklik kapsamında, birçok bağımsız değişken türü değişti.
ancak türler ve yöntemler eski öğelerle bire bir
ve HAL struct yöntemleridir.
HIDL'ye genel bakış
Donanım Arayüzü Tanımlama Dili (HIDL), sistemdeki donanım arayüzlerini belirtmek için dilden bağımsız bir mekanizma. HIDL araçları şu anda C++ ve Java arayüzlerinin oluşturulmasını desteklemektedir. Bu beklenen bir şey En Güvenilir Yürütme Ortamı (TEE) uygulayıcılarının C++ kullanımına daha uygun olduğu için bu belgede yalnızca C++ temsili ele alınmaktadı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ılandırabilirsiniz. HIDL hakkında daha fazla bilgi için Referans bölümüne göz atın.
Keymaster 3 IKeymasterDevice.hal'deki örnek bir yöntem şunlardır:
generateKey(vec<KeyParameter> keyParams)
generates(ErrorCode error, vec<uint8_t> keyBlob,
KeyCharacteristics keyCharacteristics);
Bu, keymaster2 HAL'deki aşağıdakilere 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 bağımsız değişkeni
kapalıdır. params bağımsız değişkeni artık
key_parameter_t nesne dizisine referans veren işaretçi, ancak
KeyParameter nesne içeren vec (vektör). İlgili içeriği oluşturmak için kullanılan
dönüş değerleri "generates" içinde listeleniyor her bir açıklamanın
anahtar blobu için uint8_t değerlerinin vektörü.
HIDL derleyicisi tarafından oluşturulan C++ sanal yöntemi:
Return<void> generateKey(const hidl_vec<KeyParameter>& keyParams,
generateKey_cb _hidl_cb) override;
Burada generateKey_cb, şu şekilde tanımlanan bir işlev işaretçisidir:
std::function<void(ErrorCode error, const hidl_vec<uint8_t>& keyBlob,
const KeyCharacteristics& keyCharacteristics)>
Yani generateKey_cb, döndürülen değerleri alan bir işlevdir
create yan tümcesinde listelenir. HAL uygulama sınıfı bunu geçersiz kılar
generateKey yöntemini kullanır ve generateKey_cb işlevini çağırır
işaretçisini kullanın. Fonksiyonu not edin
İşaretçi çağrısı eşzamanlıdır. Arayan
generateKey ve generateKey, sağlanan çağrıyı yapar
sonuna kadar yürütülen fonksiyon işaretçisini kullanın ve kontrolü
generateKey uygulanması, daha sonra çağrıya geri döner.
Ayrıntılı bir örnek için
hardware/interfaces/keymaster/3.0/default/KeymasterDevice.cpp
Varsayılan uygulama,
Keymaster0, keymaster1 veya keymaster2 HALS.
Erişim denetimi
Anahtar deposu erişim denetiminin en temel kuralı, her uygulamanın kendi ad alanına sahip olmanız gerekir. Ancak her kuralın bir istisnası vardır. Anahtar deposunda ve diğer belirli sistem bileşenlerinin sistem bileşenlerine erişmesine olanak ad alanları. Bu, tek bir bileşene sahip olduğu başka bir ad alanı üzerinde tam kontrol sahibidir. İkincisi de teslimatları yapmak, istemci olarak ele alacağız. Elimizde şu an için hiçbir şekilde bir WPA tedarikçisi gibi tedarikçi bileşenleri için ad alanı.
Tedarikçi firma bileşenlerini yerleştirmek ve erişim kontrolünü genelleştirmek için Keystore 2.0, sabit kodlu istisnalar olmadan, alan adlarını ve SELinux'u kullanıma sunar ad alanları.
Anahtar Deposu Alan Adları
Anahtar deposu alan adlarıyla, ad alanlarını UID'lerden ayırabiliriz. Müşteriler Anahtar Deposu'nda bir anahtara erişmek; alan adını, ad alanını ve takma adı belirtmelidir otomatik olarak oluşturabilirsiniz. Bu unsura ve arayan kişinin kimliğine dayanarak arayanın hangi tuşa erişmek istediğini ve bunun uygun olup olmadığını belirleyebilir izin verir.
Anahtarlara nasıl erişilebileceğini belirleyen beş alan parametresini kullanıma sunduk. Anahtar tanımlayıcının ad alanı parametresinin anlamını kontrol eder ve nasıl gerçekleştirileceğini anlatır.
DOMAIN_APP: Uygulama alanı, eski davranış. Java Anahtar Deposu SSA'sı varsayılan olarak bu alan adını kullanır. Bu alan adı kullanılırsa ad alanı bağımsız değişkeni yoksayılır ve çağrıyı yapanın UID'si kullanılır. Bu alana erişim, SELinux politikasındakikeystore_keysınıfı.DOMAIN_SELINUX: Bu alan adı, ad alanının SELinux politikasında bir etiketi vardır. Ad alanı parametresi çevrildiğini ve hedef bağlama çevrildiğini düşünmesinin ardındankeystore_keysınıfı için çağrı yapan SELinux bağlamı. belirtilen işlem için izin oluşturulduysa, söz konusu işlem için tam defter kullanılır kontrol edebilirsiniz.DOMAIN_GRANT: Hibe alan adı, ad alanı parametresi bir izin tanımlayıcısıdır. Takma ad parametresi yoksayılır. SELinux denetimleri izin oluşturulduğunda gerçekleştirilir. Daha fazla erişim denetimi yalnızca arayan UID'sinin, istenen iznin alan UID'si ile eşleşip eşleşmediğini kontrol eder.DOMAIN_KEY_ID: Bu alan adı, ad alanı parametresi, benzersiz bir anahtar kimliğidir. Anahtarın kendisi oluşturulmuş olabilirDOMAIN_APPveyaDOMAIN_SELINUXile. İzin Kontrol,domainvenamespacesonrasında yapılır blob'un yüklenmesi ile aynı şekilde anahtar veritabanından yüklenmiş olmalıdır. alan adı, ad alanı ve takma ad grubuna göre belirlenir. Anahtar kimliği alanının gerekçesi devamlılıktır. Bir anahtara takma adla erişildiğinde, sonraki çağrılar Çünkü yeni bir anahtar oluşturulmuş veya içe aktarılmış ve bağlanmış olabilir. bu takma ada. Ancak anahtar kimliği hiçbir zaman değişmez. Anahtar kimliğine göre bir anahtar kullanırken takma adı kullanarak Anahtar Deposu veritabanından yüklendikten sonra, ikinci bir anahtar kimliği mevcut olduğu sürece bu anahtarın aynı anahtar olduğundan emin olabilir. Bu işlevselliği, uygulama geliştiricilere sunulmaz. Bunun yerine, Kullanılsa bile daha tutarlı bir deneyim sağlamak için Android Anahtar Deposu SSA'sı güvenli bir şekilde eş zamanlı olarak kaybetmez.DOMAIN_BLOB: Blob alanı, blob'u kendisi yönetir. Bu bölüm, şunları yapması gereken müşteriler için kullanılır: Anahtar Deposu'na erişim sağlayabilirsiniz. Temel blob anahtar tanımlayıcınınblobalanına eklenir.
SELinux alanını kullanarak tedarikçi bileşenlerinin Örneğin, iletişim kutusunu açar.
keystore_key için SELinux politikası
Ad alanı etiketleri, keystore2_key_context kullanılarak yapılandırılır.
dosyası olarak kaydedebilirsiniz.
.
Bu dosyalardaki her satır, bir sayısal ad alanı kimliğini bir SELinux etiketiyle 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 bu anahtar ad alanına erişim verebiliriz.
uygun bir politika ekleyerek. Örneğin,
Yeni ad alanında anahtarları alıp kullanmak için wpa_supplicant
şu satırı hal_wifi_supplicant.te öğesine ekleyin:
allow hal_wifi_supplicant wifi_key:keystore2_key { get, use };
Yeni ad alanını oluşturduktan sonra, AndroidKeyStore neredeyse
her zamanki gibi. Tek fark, ad alanı kimliğinin belirtilmesidir. Örneğin,
Anahtarlar'dan ve Anahtar Deposu'na anahtarlar yüklenirken ve içe aktarılırken, ad alanı kimliği
(AndroidKeyStoreLoadStoreParameter) kullanarak. Ö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 anahtar oluşturmak için ad alanı kimliği sağlanmalıdır
KeyGenParameterSpec.Builder#setNamespace(): kullanılıyor
import android.security.keystore.KeyGenParameterSpec; KeyGenParameterSpec.Builder specBuilder = new KeyGenParameterSpec.Builder(); specBuilder.setNamespace(102);
Aşağıdaki bağlam dosyaları, Keystore 2.0 SELinux'u yapılandırmak için kullanılabilir ad alanları. Her bölümün 10.000 ad alanılık farklı ayrılmış bir aralığı vardır kimlikler kullanılır.
| Bölüm | Aralık | 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 |
| Satıcı | 30.000 ... 39.999 | /vendor/etc/selinux/vendor_keystore2_key_contexts, /vendor_keystore2_key_contexts |
İstemci SELinux alanını ve istenen
sanal ad alanını sayısal kimliğine göre (bu örnekte "wifi_key") belirtir.
Bunların üzerinde aşağıdaki ad alanları tanımlanmıştır. Değiştirilirse benzersiz kuralların bulunduğu UID, aşağıdaki tabloda .
| Ad alanı kimliği | SEPolitika Etiketi | Benzersiz Kimlik | Açıklama |
|---|---|---|---|
| 0 | su_anahtarı | Yok | Süper kullanıcı anahtarı. Yalnızca userdebug ve eng derlemelerinde test yapmak için kullanılır. Değil alakalı olabilir. |
| 1 | kabuk_anahtarı | Yok | Kabuk için kullanılabilir ad alanı. Çoğunlukla test amaçlı kullanılır, ancak komut satırından da yükleyebilirsiniz. |
| 100 | ses_anahtarı | Yok | Vold tarafından kullanılmak üzere tasarlanmıştır. |
| 101 | nostalji_anahtarı | Yok | Cihaz üzerinde imzalama arka plan programı tarafından kullanılır. |
| 102 | wifi_anahtarı | AID_WIFI(1010) | wpa_supplicant dahil olmak üzere Android'in kablosuz sibsistemi tarafından kullanılır. |
| 120 | yeniden başlatma_anahtarı_devam ederken | AID_SİSTEM(1000) | Android'in sistem sunucusu tarafından yeniden başlatma sırasında devam etmeyi desteklemek için kullanılır. |
Vektörlere erişme
keystore_key SELinux sınıfı epey zaman geçti ve
verify veya sign gibi izinler kayboldu
anlamları vardır. Yeni izin grubu olan keystore2_key aşağıda verilmiştir
Anahtar Deposu 2.0'ın zorunlu kılacağından emin olun.
| İzin | Anlamı |
|---|---|
delete
|
Anahtar Deposu'ndan anahtar kaldırılırken kontrol edilir. |
get_info
|
Bir anahtarın meta verileri istendiğinde kontrol edilir. |
grant
|
Arayanın, hedefteki anahtara erişim hakkı oluşturmak için bu izne ihtiyacı var bağlam. |
manage_blob
|
Arayan, belirtilen SELinux ad alanında DOMAIN_BLOB kullanabilir.
böylece blob'ları
kendi başlarına yönetebilirler. Bu özellikle de
cilt |
rebind
|
Bu izin, bir takma adın yeni bir anahtara tekrar bağlanıp bağlanmayacağını kontrol eder. Bu ekleme için gereklidir ve önceden bağlanmış anahtarın silindi. Temel olarak ekleme iznidir ancak anlamsal bilgiyi yakalar. daha iyi hale getiriyoruz. |
req_forced_op
|
Bu izne sahip istemciler, kısaltılamayan işlemler oluşturabilir ve İşlem oluşturma işlemi, tüm işlem aralıkları işlemleri de içerir. |
update
|
Bir anahtarın alt bileşenini güncellemek için gerekir. |
use
|
Anahtar materyalini kullanan bir Keymint işlemi oluştururken kontrol edilir (ör. şifreleme/şifre çözme işlemleri için kullanılır. |
use_dev_id
|
Cihaz kimliği gibi cihaz tanımlama bilgileri oluşturulurken gereklidir tasdik. |
Ayrıca, anahtarlara özgü olmayan bir dizi anahtar deposu iznini
SELinux güvenlik sınıfı keystore2:
| İzin | Anlamı |
|---|---|
add_auth
|
Gatekeeper veya BiometricsManager gibi kimlik doğrulama sağlayıcıları için gereklidir yetkilendirme jetonu eklemek için. |
clear_ns
|
Önceden clear_uid olan bu izin, bir ad alanının sahibi olmayan kullanıcılara bu ad alanındaki tüm anahtarları siler. |
list
|
Anahtarları çeşitli özelliklere göre numaralandırmak için sistem tarafından gereklidir. Örneğin,
sahiplik veya kimlik doğrulama sınırlılığı. Bu izin arayanlar için gerekli değildir
kendi ad alanlarını sıralayabilir. Bu,
get_info izni. |
lock
|
Bu izin, Anahtar Deposu'nun kilitlenmesine, yani kullanılamaz hale gelir. |
reset
|
Bu izin, Anahtar Deposu'nun fabrika varsayılanına sıfırlanmasına olanak tanır. Bu izin, anahtar kelimelerinin olduğunu unutmayın. |
unlock
|
Bu izin, kimlik doğrulama amacıyla ana anahtarın kilidinin açılmaya çalışılması için gereklidir bağlı anahtarlar. |