مخزن المفاتيح المدعوم بالأجهزة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

بنيان

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

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

الوصول إلى Keymaster

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

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

الغرض من 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 من النمط القديم HAL للبنية C إلى واجهة C++ HAL التي تم إنشاؤها من تعريف في لغة تعريف واجهة الأجهزة الجديدة (HIDL). يتم إنشاء تطبيق HAL بنمط جديد عن طريق تصنيف فئة فرعية لفئة IKeymasterDevice التي تم إنشاؤها وتنفيذ الأساليب الافتراضية البحتة. كجزء من التغيير، تم تغيير العديد من أنواع الوسيطات، على الرغم من أن الأنواع والأساليب لها توافق واحد لواحد مع الأنواع القديمة وأساليب بنية HAL.

نظرة عامة على 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;

حيث يعتبر generateKey_cb مؤشر دالة محددًا على النحو التالي:

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

أي أن generateKey_cb هي دالة تأخذ قيم الإرجاع المدرجة في جملة الإنشاء. تتجاوز فئة تنفيذ HAL طريقة generateKey هذه وتستدعي مؤشر الدالة generateKey_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، يمكننا فصل مساحات الأسماء عن UIDs. يتعين على العملاء الذين يصلون إلى مفتاح في Keystore تحديد المجال ومساحة الاسم والاسم المستعار الذي يريدون الوصول إليه. بناءً على هذا الصف وهوية المتصل يمكننا تحديد المفتاح الذي يريد المتصل الوصول إليه وما إذا كان لديه الأذونات المناسبة.

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

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

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

سياسة 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_key:keystore2_key { get, use };

بعد إعداد مساحة الاسم الجديدة، يمكن استخدام AndroidKeyStore كالمعتاد تقريبًا. والفرق الوحيد هو أنه يجب تحديد معرف مساحة الاسم. لتحميل واستيراد المفاتيح من وإلى Keystore، يتم تحديد معرف مساحة الاسم باستخدام 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 ... 9,999
/system/etc/selinux/keystore2_key_contexts, /plat_keystore2_key_contexts
النظام الموسع 10,000 ... 19,999
/system_ext/etc/selinux/system_ext_keystore2_key_contexts, /system_ext_keystore2_key_contexts
منتج 20,000 ... 29,999
/product/etc/selinux/product_keystore2_key_contexts, /product_keystore2_key_contexts
بائع 30,000 ... 39,999
/vendor/etc/selinux/vendor_keystore2_key_contexts, /vendor_keystore2_key_contexts

يطلب العميل المفتاح عن طريق طلب مجال SELinux ومساحة الاسم الافتراضية المطلوبة، في هذه الحالة "wifi_key" ، من خلال المعرف الرقمي الخاص به.

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

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

ناقلات الوصول

أصبح مفتاح keystore_key الخاص بفئة SELinux قديمًا بعض الشيء وفقدت بعض الأذونات، مثل verify أو sign ، معناها. إليك مجموعة الأذونات الجديدة، keystore2_key ، التي سيفرضها Keystore 2.0.

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

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

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