Keystore المدعومة بالأجهزة

يوفر توفر بيئة تنفيذ موثوقة في نظام على شريحة (SoC) فرصة لأجهزة Android لتوفير خدمات أمان قوية ومدعومة بالأجهزة لنظام التشغيل Android ، وخدمات النظام الأساسي ، وحتى لتطبيقات الجهات الخارجية. يجب على مطوري تسعى ملحقات الروبوت محددة تذهب إلى android.security.keystore .

قبل Android 6.0 ، كان لدى Android بالفعل واجهة برمجة تطبيقات خدمات تشفير بسيطة مدعومة بالأجهزة ، يتم توفيرها بواسطة الإصدارين 0.2 و 0.3 من Keymaster Hardware Abstraction Layer (HAL). قدمت Keystore عمليات التوقيع والتحقق الرقمية ، بالإضافة إلى إنشاء واستيراد أزواج مفاتيح التوقيع غير المتماثلة. تم تنفيذ هذا بالفعل على العديد من الأجهزة ، ولكن هناك العديد من أهداف الأمان التي لا يمكن تحقيقها بسهولة باستخدام توقيع API فقط. يعمل Keystore في Android 6.0 على توسيع Keystore API لتوفير نطاق أوسع من الإمكانات.

في أندرويد 6.0، وأضاف تخزين المفاتيح البدائيون متماثل التشفير ، AES وHMAC، ونظام التحكم في الوصول لمفاتيح المدعومة من الأجهزة. يتم تحديد عناصر التحكم في الوصول أثناء إنشاء المفتاح ويتم فرضها طوال عمر المفتاح. يمكن تقييد استخدام المفاتيح فقط بعد مصادقة المستخدم ، ولأغراض محددة فقط أو باستخدام معلمات تشفير محددة. لمزيد من المعلومات، راجع تفويض الكلمات و ظائف الصفحات.

بالإضافة إلى توسيع نطاق أساسيات التشفير ، يضيف Keystore في Android 6.0 ما يلي:

  • نظام التحكم في الاستخدام للسماح بتحديد استخدام المفتاح ، للتخفيف من مخاطر الاختراق الأمني ​​بسبب إساءة استخدام المفاتيح
  • نظام التحكم في الوصول لتمكين تقييد المفاتيح لمستخدمين معينين وعملاء ونطاق زمني محدد

في Android 7.0 ، أضاف Keymaster 2 دعمًا للمصادقة الرئيسية وربط الإصدار. شهادة الرئيسية توفر شهادات المفاتيح العمومية التي تحتوي على وصف تفصيلي للمفتاح وضوابط الوصول، وذلك لجعل وجود المفتاح في الأجهزة آمنة والتكوين عن بعد يمكن التحقق منها.

نسخة ملزم يربط مفاتيح لنظام التشغيل والنسخة مستوى التصحيح. هذا يضمن أن المهاجم الذي يكتشف نقطة ضعف في إصدار قديم من النظام أو برنامج TEE لا يمكنه إعادة الجهاز إلى الإصدار الضعيف واستخدام المفاتيح التي تم إنشاؤها باستخدام الإصدار الأحدث. بالإضافة إلى ذلك ، عند استخدام مفتاح بإصدار معين ومستوى تصحيح على جهاز تمت ترقيته إلى إصدار أحدث أو مستوى تصحيح ، تتم ترقية المفتاح قبل إمكانية استخدامه وإبطال الإصدار السابق من المفتاح. أثناء ترقية الجهاز ، "تضاعف" المفاتيح للأمام مع الجهاز ، ولكن أي ارتداد للجهاز إلى إصدار سابق يتسبب في أن تصبح المفاتيح غير قابلة للاستخدام.

في Android 8.0 ، انتقل Keymaster 3 من طبقة تجريد الأجهزة ذات البنية C القديمة (HAL) إلى واجهة C ++ HAL التي تم إنشاؤها من تعريف في لغة تعريف واجهة الأجهزة الجديدة (HIDL). كجزء من التغيير ، تم تغيير العديد من أنواع الوسيطات ، على الرغم من أن الأنواع والطرق لها تطابق واحد لواحد مع الأنواع القديمة وطرق HAL Struct. اطلع على وظائف الصفحة لمزيد من التفاصيل.

وبالإضافة إلى هذه الواجهة مراجعة، الروبوت 8.0 يمتد ميزة شهادة Keymaster 2 لدعم شهادة ID . يوفر إثبات الهوية آلية محدودة واختيارية للتصديق بقوة على معرفات الأجهزة ، مثل الرقم التسلسلي للجهاز واسم المنتج ومعرف الهاتف (IMEI / MEID). لتنفيذ هذه الإضافة ، قم بتغيير مخطط تصديق ASN.1 لإضافة تصديق المعرف. تحتاج تطبيقات Keymaster إلى إيجاد طريقة آمنة لاسترداد عناصر البيانات ذات الصلة ، بالإضافة إلى تحديد آلية لتعطيل الميزة بشكل آمن ودائم.

في Android 9 ، تتضمن التحديثات ما يلي:

  • تحديث Keymaster 4
  • دعم العناصر الآمنة المضمنة
  • دعم استيراد المفتاح الآمن
  • دعم تشفير 3DES
  • التغييرات في ربط الإصدار بحيث يكون لكل من boot.img و system.img إصدارات محددة بشكل منفصل للسماح بالتحديثات المستقلة

قائمة المصطلحات

فيما يلي نظرة عامة سريعة على مكونات Keystore وعلاقاتها.

AndroidKeystore هو API إطار الروبوت وعنصر المستخدمة من قبل التطبيقات للوصول إلى وظيفة تخزين المفاتيح. يتم تنفيذه كامتداد لواجهات برمجة تطبيقات Java Cryptography Architecture القياسية ، ويتكون من كود Java يتم تشغيله في مساحة العملية الخاصة بالتطبيق. AndroidKeystore يلبي طلبات التطبيق لسلوك تخزين المفاتيح من قبل إحالتها إلى شيطان تخزين المفاتيح.

البرنامج الخفي تخزين المفاتيح هو شيطان نظام أندرويد الذي يوفر الوصول إلى جميع وظائف تخزين المفاتيح عن طريق API الموثق . إنه مسؤول عن تخزين "النقاط الرئيسية" ، التي تحتوي على مادة المفتاح السري الفعلي ، المشفرة بحيث يمكن لـ Keystore تخزينها دون استخدامها أو الكشف عنها.

keymasterd هو خادم HIDL التي توفر الوصول إلى Keymaster TA. (هذا الاسم غير موحد ولأغراض مفاهيمية.)

Keymaster TA (تطبيق موثوق به) هو برنامج تشغيل في سياق آمن، في معظم الأحيان في TrustZone على شركة نفط الجنوب ARM، والذي يوفر كافة عمليات تخزين المفاتيح آمنة، لديه حق الوصول إلى المواد الأساسية الخام، ويؤكد كل الشروط لمراقبة الدخول على مفاتيح ، إلخ.

LockSettingsService هو العنصر نظام أندرويد مسؤولة عن مصادقة المستخدم، كلمة المرور على حد سواء وبصمات الأصابع. إنه ليس جزءًا من Keystore ، ولكنه ذو صلة لأن العديد من عمليات مفتاح Keystore تتطلب مصادقة المستخدم. LockSettingsService يتفاعل مع البواب TA وبصمات الأصابع TA للحصول على الرموز والتوثيق، والتي تنص على أن البرنامج الخفي تخزين المفاتيح، والتي يتم استهلاكها في نهاية المطاف من تطبيق Keymaster TA.

البواب TA (التطبيق الموثوق به) هو مكون آخر قيد التشغيل في سياق آمن، وهي المسؤولة عن توثيق كلمات مرور المستخدم وتوليد التوثيق الرموز المميزة المستخدمة لتثبت للKeymaster TA أن مصادقة تم القيام به لمستخدم معين في نقطة معينة من الزمن.

بصمة TA (التطبيق الموثوق به) هو مكون آخر قيد التشغيل في سياق آمن المسؤولة عن توثيق بصمات المستخدم وتوليد التوثيق الرموز المميزة المستخدمة لتثبت للKeymaster TA أن مصادقة تم القيام به لمستخدم معين في نقطة معينة من الزمن.

بنيان

توفر واجهة برمجة تطبيقات Android Keystore و Keymaster HAL الأساسي مجموعة أساسية ولكن مناسبة من أساسيات التشفير للسماح بتنفيذ البروتوكولات باستخدام مفاتيح التحكم في الوصول والمدعومة من الأجهزة.

Keymaster HAL هي مكتبة قابلة للتحميل ديناميكيًا توفرها الشركة المصنعة للمعدات الأصلية وتستخدمها خدمة Keystore لتقديم خدمات تشفير مدعومة بالأجهزة. للحفاظ على أمان الأشياء ، لا تؤدي تطبيقات HAL أي عمليات حساسة في مساحة المستخدم ، أو حتى في مساحة kernel. يتم تفويض العمليات الحساسة إلى معالج آمن يتم الوصول إليه من خلال بعض واجهات kernel. تبدو البنية الناتجة كما يلي:

الوصول إلى Keymaster

الشكل 1. الوصول إلى Keymaster

داخل جهاز Android ، يتكون "العميل" لـ Keymaster HAL من طبقات متعددة (مثل التطبيق ، والإطار ، و Keystore daemon) ، ولكن يمكن تجاهل ذلك لأغراض هذا المستند. هذا يعني أن Keymaster HAL API الموصوفة منخفضة المستوى ، وتستخدمها المكونات الداخلية للنظام الأساسي ، ولا تتعرض لمطوري التطبيقات. يوصف API ذات المستوى العالي على موقع المطور الروبوت .

الغرض من Keymaster HAL ليس تنفيذ الخوارزميات الحساسة للأمان ولكن فقط لتنظيم الطلبات وإلغاء تنظيمها في العالم الآمن. يتم تحديد تنسيق السلك حسب التنفيذ.

التوافق مع الإصدارات السابقة

Keymaster 1 HAL غير متوافق تمامًا مع HALs التي تم إصدارها مسبقًا ، مثل Keymaster 0.2 و 0.3. لتسهيل التشغيل البيني على الأجهزة التي تعمل بنظام التشغيل Android 5.0 والإصدارات الأقدم التي تم إطلاقها مع Keymaster HALs الأقدم ، يوفر Keystore محولًا ينفذ Keymaster 1 HAL مع المكالمات إلى مكتبة الأجهزة الموجودة. لا يمكن أن توفر النتيجة النطاق الكامل للوظائف في Keymaster 1 HAL. على وجه الخصوص ، فهو يدعم فقط خوارزميات RSA و ECDSA ، ويتم تنفيذ جميع عمليات إنفاذ ترخيص المفتاح بواسطة المهايئ ، في العالم غير الآمن.

Keymaster 2 مبسطة كذلك واجهة HAL عن طريق إزالة get_supported_* أساليب والسماح finish() طريقة لقبول الإدخال. هذا يقلل من عدد الرحلات ذهابًا وإيابًا إلى TEE في الحالات التي يكون فيها الإدخال متاحًا دفعة واحدة ، ويبسط تنفيذ فك تشفير AEAD.

في Android 8.0 ، انتقل Keymaster 3 من النمط القديم C- بنية HAL إلى واجهة C ++ HAL التي تم إنشاؤها من تعريف في لغة تعريف واجهة الأجهزة الجديدة (HIDL). يتم إنشاء تنفيذ HAL-نمط جديد من شاء subclasses ترث ولدت IKeymasterDevice الطبقة وتنفيذ الطرق الافتراضية نقية. كجزء من التغيير ، تم تغيير العديد من أنواع الوسائط ، على الرغم من أن الأنواع والطرق لها تطابق واحد لواحد مع الأنواع القديمة وطرق HAL Struct.

نظرة عامة HIDL

توفر لغة تعريف واجهة الأجهزة (HIDL) آلية تنفيذ مستقلة عن اللغة لتحديد واجهات الأجهزة. تدعم أدوات HIDL حاليًا إنشاء واجهات C ++ و Java. من المتوقع أن يجد معظم منفذي بيئة التنفيذ الموثوقة (TEE) أدوات C ++ أكثر ملاءمة ، لذلك يناقش هذا المستند تمثيل C ++ فقط.

تتكون واجهات HIDL من مجموعة من الأساليب ، يتم التعبير عنها على النحو التالي:

  methodName(INPUT ARGUMENTS) generates (RESULT ARGUMENTS);

هناك أنواع مختلفة محددة مسبقًا ، ويمكن لـ HALs تحديد أنواع هيكلية ومعدودة جديدة. لمزيد من التفاصيل حول HIDL، راجع قسم المرجعي .

طريقة سبيل المثال من Keymaster 3 IKeymasterDevice.hal هو:

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

هذا يعادل ما يلي من keymaster2 HAL:

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، و dev تتم إزالة حجة، لأنه ضمني. و params الحجة لم تعد البنية تحتوي على مؤشر الرجوع إلى مجموعة من key_parameter_t الأشياء، ولكن vec (ناقلات) التي تحتوي على KeyParameter الكائنات. يتم سرد قيم الإرجاع في " generates " شرط، بما في ذلك ناقلات uint8_t قيم النقطة الرئيسية.

الطريقة الافتراضية C ++ التي تم إنشاؤها بواسطة مترجم HIDL هي:

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

حيث generate_cb هو مؤشر دالة معرفة على النحو التالي:

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

وهذا هو، generate_cb هو دالة التي تأخذ القيم عودة المدرجة في بند توليد. الطبقة تنفيذ HAL يتجاوز هذا generateKey طريقة وتدعو generate_cb مؤشر الدالة لإرجاع النتيجة العملية للمتصل. ملاحظة استدعاء دالة مؤشر غير متزامن. ويدعو المتصل generateKey و generateKey يدعو مؤشر الدالة الموردة، الذي ينفذ على الانتهاء، والعودة التحكم إلى generateKey التنفيذ، والتي ثم يعود إلى الطالب.

لمثال مفصل، انظر تطبيق الافتراضي في hardware/interfaces/keymaster/3.0/default/KeymasterDevice.cpp . يوفر التطبيق الافتراضي التوافق مع الإصدارات السابقة للأجهزة ذات النمط القديم keymaster0 أو keymaster1 أو keymaster2 HALS.

صلاحية التحكم صلاحية الدخول

القاعدة الأساسية للتحكم في الوصول إلى Keystore هي أن لكل تطبيق مساحة الاسم الخاصة به. لكن لكل قاعدة استثناء. يحتوي Keystore على بعض الخرائط المشفرة الثابتة التي تسمح لمكونات نظام معينة بالوصول إلى بعض مساحات الأسماء الأخرى. هذه أداة حادة جدًا من حيث أنها تمنح عنصرًا واحدًا تحكمًا كاملاً في مساحة اسم أخرى. ثم هناك مسألة مكونات البائع كعملاء لـ Keystore. ليس لدينا حاليًا أي طريقة لإنشاء مساحة اسم لمكونات البائع ، على سبيل المثال ، طالب WPA.

من أجل استيعاب مكونات البائع وتعميم التحكم في الوصول دون استثناءات مشفرة ، يقدم Keystore 2.0 المجالات ومساحات أسماء selinux.

مجالات Keystore

باستخدام نطاقات Keystore ، يمكننا فصل مساحات الأسماء عن uids. يجب على العملاء الذين يصلون إلى مفتاح في مخزن المفاتيح تحديد النطاق ومساحة الاسم والاسم المستعار الذي يريدون الوصول إليه. بناءً على هذه المجموعة وهوية المتصل ، يمكننا تحديد المفتاح الذي يريد المتصل الوصول إليه وما إذا كان لديه الأذونات المناسبة.

نقدم خمس معلمات للمجال تحكم كيفية الوصول إلى المفاتيح. يتحكمون في دلالات معلمة مساحة الاسم لواصف المفتاح وكيفية تنفيذ التحكم في الوصول.

  • DOMAIN_APP : المجال التطبيق يشمل السلوك القديم. يستخدم Java Keystore SPI هذا المجال افتراضيًا. عند استخدام هذا المجال ، يتم تجاهل وسيطة مساحة الاسم ويتم استخدام uid الخاص بالمتصل بدلاً من ذلك. يتم التحكم الوصول إلى هذا المجال من قبل التسمية تخزين المفاتيح إلى فئة keystore_key في السياسة سيلينو.
  • DOMAIN_SELINUX : يشير هذا المجال الذي يحتوي على مساحة الاسم التسمية في السياسة سيلينو. وبدا المعلمة مساحة تصل وترجمتها في سياق الهدف، ويتم تنفيذ عملية الاختيار إذن لسياق سيلينو تدعو إلى keystore_key الصف. عندما يتم إنشاء الإذن للعملية المحددة ، يتم استخدام المجموعة الكاملة للبحث عن المفتاح.
  • DOMAIN_GRANT : يشير المجال منحة أن المعلمة مساحة الاسم هو المعرف المنحة. تم تجاهل معلمة الاسم المستعار. يتم إجراء فحوصات Selinux عند إنشاء المنحة. يتحقق مزيد من التحكم في الوصول فقط مما إذا كان معرف المتصل يتطابق مع معرف المستفيدين من المنحة المطلوبة.
  • DOMAIN_KEY_ID : يشير هذا المجال الذي المعلمة مساحة الاسم هو مفتاح معرف فريد. قد تم إنشاؤها المفتاح نفسه مع DOMAIN_APP أو DOMAIN_SELINUX . يتم تنفيذ الاختيار إذن بعد domain و namespace تم تحميلها من قاعدة البيانات الرئيسية في بنفس الطريقة كما لو تم تحميل سائل كتبها المجال، مساحة، والصفوف (tuple) الاسم المستعار. الأساس المنطقي لمجال معرف المفتاح هو الاستمرارية. عند الوصول إلى مفتاح بالاسم المستعار ، قد تعمل المكالمات اللاحقة على مفاتيح مختلفة ، لأنه ربما تم إنشاء مفتاح جديد أو استيراده وربطه بهذا الاسم المستعار. ومع ذلك ، فإن معرف المفتاح لا يتغير أبدًا. لذلك عند استخدام مفتاح بواسطة معرف المفتاح بعد تحميله من قاعدة بيانات keystore باستخدام الاسم المستعار مرة واحدة ، يمكن للمرء التأكد من أنه نفس المفتاح طالما أن معرف المفتاح لا يزال موجودًا. لا يتم عرض هذه الوظيفة لمطوري التطبيقات ، وبدلاً من ذلك يتم استخدامها داخل Android Keystore SPI لتوفير تجربة أكثر اتساقًا حتى عند استخدامها بشكل متزامن بطريقة غير آمنة.
  • DOMAIN_BLOB : يشير المجال سائل أن المتصل يدير سائل في حد ذاته. يستخدم هذا للعملاء الذين يحتاجون إلى الوصول إلى Keystore قبل تحميل قسم البيانات. يتم تضمين النقطة الرئيسية في blob مجال واصف الرئيسيين.

باستخدام مجال SELinux ، يمكننا منح مكونات البائع إمكانية الوصول إلى مساحات أسماء ملفات تخزين المفاتيح المحددة جدًا والتي يمكن مشاركتها بواسطة مكونات النظام مثل مربع حوار الإعدادات.

سياسة SELinux لـ keystore_key

يتم تكوين تسميات مساحة باستخدام keystore2_key_context الملف.
يقوم كل سطر في هذه الملفات بتعيين معرف مساحة اسم رقمي لتسمية SELinux. على سبيل المثال،

# 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

بعد إعداد مساحة اسم مفتاح جديدة بهذه الطريقة ، يمكننا منح الوصول إليها عن طريق إضافة سياسة مناسبة. على سبيل المثال، للسماح wpa_supplicant للحصول على واستخدام مفاتيح في مساحة الاسم الجديد الذي من شأنه أن يضيف السطر التالي إلى hal_wifi_supplicant.te :

allow hal_wifi_supplicant wifi_keys:keystore2_key { get, use };

بعد إعداد مساحة الاسم الجديدة ، يمكن استخدام AndroidKeyStore كالمعتاد تقريبًا. الاختلاف الوحيد هو أنه يجب تحديد معرف مساحة الاسم. لتحميل واستيراد مفاتيح من وإلى تخزين المفاتيح، يتم تحديد هوية مساحة باستخدام AndroidKeyStoreLoadStoreParameter . على سبيل المثال،

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

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

لإنشاء مفتاح في مساحة معينة، ويجب إعطاء هوية باستخدام مساحة KeyGenParameterSpec.Builder#setNamespace():

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

يمكن استخدام ملفات السياق التالية لتكوين مساحات أسماء Keystore 2.0 SELinux. يحتوي كل قسم على نطاق محجوز مختلف من 10000 معرف مساحة اسم لتجنب التصادمات.

تقسيم نطاق ملفات التكوين
نظام 0 ... 9999
/system/etc/selinux/keystore2_key_contexts, /plat_keystore2_key_contexts
نظام موسع 10000 ... 19999
/system_ext/etc/selinux/system_ext_keystore2_key_contexts, /system_ext_keystore2_key_contexts
منتج 20000 ... 29999
/product/etc/selinux/product_keystore2_key_contexts, /product_keystore2_key_contexts
بائع 30000 ... 39999
/vendor/etc/selinux/vendor_keystore2_key_contexts, /vendor_keystore2_key_contexts

يطلب العميل مفتاح عن طريق طلب المجال سيلينو ومساحة الاسم الظاهري المطلوب، هنا "wifi_keys" ، من خلال المعرف الخاص به الرقمية.

وفوق ذلك تم تحديد مساحات الأسماء التالية. عند استبدال القواعد الخاصة ، يشير الجدول التالي إلى المعرف الفريد العمومي (UID) الذي استخدموه للتوافق معه.

معرف مساحة الاسم تسمية وثيقة التأمين المعرف الفريد وصف
0 su_key غير متاح مفتاح المستخدم الفائق. تستخدم فقط للاختبار على بنيات userdebug و eng. غير ذي صلة ببنيات المستخدم.
1 shell_key غير متاح Namespace المتاحة للقصف. تستخدم في الغالب للاختبار ، ولكن يمكن استخدامها في إنشاءات المستخدم أيضًا من سطر الأوامر.
100 vold_key غير متاح مخصص للاستخدام من قبل vold.
101 odsing_key غير متاح مستخدمة بواسطة البرنامج الخفي للتوقيع على الجهاز.
102 wfi_key AID_WIFI (1010) يستخدمه نظام Wifi لنظام Android بما في ذلك wpa_supplicant.
120 استئناف_على_إعادة_التمهيد_مفتاح AID_SYSTEM (1000) يستخدمه خادم نظام Android لدعم الاستئناف عند إعادة التشغيل.

نواقل الوصول

الطبقة سيلينو keystore_key والذين تتراوح أعمارهم قليلا جدا، وبعض من الأذونات، مثل verify أو sign قد فقدت معناها. هنا هو مجموعة جديدة من الأذونات، keystore2_key ، أن تخزين المفاتيح 2.0 وإنفاذها.

الإذن المعنى
delete تم الفحص عند إزالة المفاتيح من Keystore.
get_info يتم فحصه عند طلب البيانات الوصفية للمفتاح.
grant يحتاج المتصل إلى هذا الإذن لإنشاء منحة للمفتاح في السياق الهدف.
manage_blob قد تستخدم المتصل DOMAIN_BLOB على مساحة سيلينو معين، وبالتالي إدارة النقط في حد ذاته. هذا مفيد بشكل خاص لـ vold.
rebind يتحكم هذا الإذن في إمكانية ارتداد الاسم المستعار إلى مفتاح جديد. هذا مطلوب للإدراج ويعني أنه سيتم حذف المفتاح المرتبط مسبقًا. إنه في الأساس إذن إدخال ، لكنه يلتقط دلالات keystore بشكل أفضل.
req_forced_op قد ينشئ العملاء الذين لديهم هذا الإذن عمليات غير قابلة للتنفيذ ، ولا يفشل إنشاء العملية أبدًا ما لم يتم أخذ جميع فتحات التشغيل من خلال عمليات غير قابلة للتشغيل.
update مطلوب لتحديث المكون الفرعي للمفتاح.
use تم التحقق منه عند إنشاء عملية Keymint التي تستخدم المادة الأساسية ، على سبيل المثال ، للتوقيع ، en / فك التشفير.
use_dev_id مطلوب عند إنشاء معلومات تعريف الجهاز ، مثل تصديق معرف الجهاز.

بالإضافة إلى ذلك، يمكننا تقسيم من مجموعة من أذونات محددة تخزين المفاتيح الرئيسية غير في فئة الأمن سيلينو keystore2 :

الإذن المعنى
add_auth مطلوب من قِبل موفر المصادقة مثل Gatekeeper أو BiometricsManager لإضافة رموز المصادقة.
clear_ns كان هذا الإذن سابقًا clear_uid ، يسمح لغير مالك مساحة الاسم بحذف جميع المفاتيح في مساحة الاسم هذه.
list مطلوب من قبل النظام لتعداد المفاتيح حسب الخصائص المختلفة ، مثل الملكية أو حدود المصادقة. هذا الإذن غير مطلوب من قبل المتصلين الذين يقومون بتعداد مساحات الأسماء الخاصة بهم. وتغطي هذه من قبل get_info إذن.
lock يسمح هذا الإذن بقفل Keystore ، أي طرد المفتاح الرئيسي ، بحيث تصبح مفاتيح المصادقة غير قابلة للاستخدام وغير قابلة للإنشاء.
reset يسمح هذا الإذن بإعادة تعيين Keystore إلى إعدادات المصنع الافتراضية ، وحذف جميع المفاتيح غير الحيوية لعمل نظام التشغيل Android
unlock هذا الإذن مطلوب لمحاولة إلغاء قفل المفتاح الرئيسي لمفاتيح المصادقة المرتبطة.