ملف تخزين مفاتيح مستنِد إلى الجهاز

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

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

في Android 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. يمكنك الاطّلاع على يمكنك الاطّلاع على صفحة الدوال لمزيد من المعلومات. التفاصيل.

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

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

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

مسرد المصطلحات

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

AndroidKeystore هي واجهة برمجة تطبيقات إطار عمل Android والمكوِّن المستخدم من التطبيقات للوصول إلى وظيفة ملف تخزين المفاتيح. ويتم تنفيذه كامتداد واجهات برمجة التطبيقات القياسية لبنية تشفير Java، وتتألف من رمز Java الذي في مساحة المعالجة الخاصة بالتطبيق. إكمال "AndroidKeystore" لتنفيذ التطبيق بشأن سلوك ملف تخزين المفاتيح من خلال إعادة توجيهها إلى البرنامج الخفي لملف تخزين المفاتيح.

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

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

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

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

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

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

هندسة معمارية

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

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

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

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

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

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

لا يتوافق Keymaster 1 HAL تمامًا مع HALs تم إصدارها سابقًا، مثل الإصدار 0.2 و0.3 من Keymaster. لتسهيل إمكانية التشغيل التفاعلي على الأجهزة التي تعمل بنظام التشغيل Android 5.0 والإصدارات الأقدم التي تم إطلاقها مع HALs القديمة لـ Keymaster، توفر 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) بنمط جديد عن طريق تصنيف النتائج الفرعية فئة واحدة (IKeymasterDevice) وتنفيذ الاستخدام الافتراضي الخالص الطرق. وكجزء من هذا التغيير، تغيّرت العديد من أنواع الوسيطات، على الرغم من أن الأنواع والطرق لها ارتباط فردي مع البيانات القديمة وطرق هيكلة HAL.

نظرة عامة على شهادة HIDL

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

تتألّف واجهات HIDL من مجموعة من الطرق، يتم التعبير عنها على النحو التالي:

  methodName(INPUT ARGUMENTS) generates (RESULT ARGUMENTS);

هناك العديد من الأنواع المحددة مسبقًا، ويمكن أن تحدد HALs قيمًا جديدة للتعداد وأنواع الهياكل. لمزيد من التفاصيل حول شهادة HIDL، يُرجى الاطّلاع على قسم "المراجع".

في ما يلي أمثلة على طريقة IKeymasterDevice.hal من Keymaster 3:

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 لكائن الكائن الثنائي الكبير (blob) الرئيسي.

الطريقة الافتراضية لـ 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. ليس لدينا حاليًا أي طريقة لإنشاء مساحة الاسم لمكونات المورد، على سبيل المثال، WPA supplicant.

لاستيعاب مكونات البائع وتعميم التحكم في الوصول بدون استثناءات غير قابلة للتغيير في البرنامج، يقدّم Keystore 2.0 النطاقات وSELinux ومساحات الاسم.

نطاقات تخزين المفاتيح

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

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

• DOMAIN_APP: يغطي نطاق التطبيق السلوك القديم. وتستخدم واجهة برمجة تطبيقات ملف تخزين مفاتيح Java هذا النطاق تلقائيًا. عندما يكون هذا يتم استخدام النطاق، ويتم تجاهل وسيطة مساحة الاسم ويكون المُعرّف الفريد للمتصل استخدامه بدلاً من ذلك. يتم التحكّم في الوصول إلى هذا النطاق من خلال تصنيف ملف تخزين المفاتيح إلى الفئة keystore_key في سياسة SELinux.
• DOMAIN_SELINUX: يشير هذا النطاق إلى أن مساحة الاسم لها تسمية في سياسة SELinux. يتم البحث عن معلَمة مساحة الاسم. وترجمته إلى سياق مستهدف، وإجراء تحقق من الأذونات سياق استدعاء SELinux لفئة keystore_key. عندما تم إنشاء إذن للعملية المحددة، يتم استخدام الصف الكامل للبحث عن المفتاح.
• DOMAIN_GRANT: يشير نطاق المنح إلى أن معلمة مساحة الاسم هي معرف منح. ويتم تجاهل معلمة الاسم المستعار. يتم تنفيذ عمليات فحص SELinux عند إنشاء المنحة. مزيد من التحكم في الوصول تتحقق فقط مما إذا كان المعرّف الفريد للمتصل يطابق المعرّف الفريد (UID) المستفيد من المنح المطلوب.
• DOMAIN_KEY_ID: يشير هذا النطاق إلى أن معلمة مساحة الاسم هي معرّف مفتاح فريد. يُحتمَل أنّه تم إنشاء المفتاح نفسه. مع DOMAIN_APP أو DOMAIN_SELINUX. الإذن يتم إجراء عملية التحقّق بعد domain وnamespace. من قاعدة البيانات الرئيسية بالطريقة نفسها كما لو تم تحميل الكائن الثنائي الكبير (blob) حسب النطاق ومساحة الاسم وصف الاسم المستعار. أسباب تحديد نطاق المعرّف الرئيسي هي الاستمرارية. عند الوصول إلى مفتاح باستخدام اسم مستعار، قد يتم تشغيل المكالمات اللاحقة على مفاتيح مختلفة، لأن مفتاحًا جديدًا ربما تم إنشاؤه أو استيراده وربطه بهذا الاسم المستعار. ومع ذلك، لا يتغير معرّف المفتاح أبدًا. لذلك، عند استخدام مفتاح حسب معرّف المفتاح بعد أن يتم تحميله من قاعدة بيانات ملف تخزين المفاتيح باستخدام الاسم المستعار مرة واحدة، يمكننا التأكد من أنه نفس المفتاح طالما أن معرّف المفتاح لا يزال موجودًا. هذا النمط لا يتم عرض وظائفها لمطوّري التطبيقات. بدلاً من ذلك، يتم استخدامه ضمن واجهة برمجة تطبيقات ملف تخزين مفاتيح Android لتوفير تجربة أكثر اتساقًا حتى عند استخدامها بشكل متزامن بطريقة غير آمنة.
• DOMAIN_BLOB: يشير نطاق الكائن الثنائي الكبير (blob) إلى أن يدير المتصل الكائن الثنائي الكبير بنفسه. يُستخدم هذا للعملاء الذين يحتاجون إلى الوصول إلى ملف تخزين المفاتيح قبل تثبيت قسم البيانات. الكائن الثنائي الكبير الرئيسي هو في الحقل 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_key: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 ومساحات الاسم. يحتوي كل قسم على نطاق محجوز مختلف يبلغ 10,000 مساحة اسم المعرفات لتجنب الاصطدامات.

/system/etc/selinux/keystore2_key_contexts, /plat_keystore2_key_contexts

/system_ext/etc/selinux/system_ext_keystore2_key_contexts, /system_ext_keystore2_key_contexts

/product/etc/selinux/product_keystore2_key_contexts, /product_keystore2_key_contexts

/vendor/etc/selinux/vendor_keystore2_key_contexts, /vendor_keystore2_key_contexts

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

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

الوصول إلى المتجهات

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

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