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

تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

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

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

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

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

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

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

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

في الإصدار 8.0 من Android، تم نقل 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 إصدارات محدّدة بشكل منفصل للسماح بإجراء تحديثات مستقلة

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

في ما يلي نظرة عامة سريعة على مكوّنات "متجر المفاتيح" وعلاقاتها.

AndroidKeystore هو واجهة برمجة تطبيقات وعنصر إطار عمل Android المستخدَمَين من قِبل التطبيقات للوصول إلى وظائف Keystore. ويتم تنفيذها كإضافة إلى واجهات برمجة تطبيقات Java Cryptography Architecture العادية، وتتألف من رمز Javaبرمجي يُنفَّذ في مساحة عملية التطبيق. تلبّي AndroidKeystoreطلبات التطبيقات المتعلّقة بسلوك ملف تخزين المفاتيح من خلال إعادة توجيهها إلى الخادم الدائم لملف تخزين المفاتيح.

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

‫keymasterd هو خادم HIDL يوفر إمكانية الوصول إلى ملف APK الخاص بتطبيق Keymaster TA. (هذا الاسم غير موحّد ويُستخدَم لأغراض مفهومية).

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

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

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

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

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

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

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

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

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

لا يهدف Keymaster HAL إلى تنفيذ Algorithms التي تتعامل مع الأمان، بل إلى ترتيب الطلبات وتحويلها إلى تنسيق قابل للقراءة من قِبل الأجهزة الآمنة فقط. يتم تحديد تنسيق السلسلة من خلال عملية التنفيذ.

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

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

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

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

نظرة عامة على HIDL

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

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

  methodName(INPUT ARGUMENTS) generates (RESULT ARGUMENTS);

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

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

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

هذا هو الإجراء المكافئ لما يلي من HAL keymaster2:

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. يوفر التنفيذ التلقائي توافقًا مع الإصدارات القديمة للأجهزة التي تحتوي على واجهة HAL لـ keymaster0 أو keymaster1 أو keymaster2 القديمة.

التحكّم في الوصول

القاعدة الأساسية لإدارة الوصول إلى "متجر المفاتيح" هي أنّ لكل تطبيق مساحة اسم خاصة به. ولكن لكل قاعدة استثناء. يحتوي "متجر المفاتيح" على بعض الخرائط المُبرمَجة بشكلٍ ثابت التي تسمح لمكونات معيّنة من النظام بالوصول إلى مساحات имен معيّنة أخرى. هذه أداة حادة جدًا من حيث أنّها تمنح مكوّنًا واحدًا التحكّم الكامل في مساحة اسم أخرى. ثم هناك مسألة مكونات العميل التابعة للمورّد في "متجر المفاتيح". لا تتوفّر لدينا حاليًا طريقة لإنشاء ملف تعريف باسم ‎ namespace لمكوّنات المورّد، مثل WPA supplicant.

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

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

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

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

• DOMAIN_APP: يشمل نطاق التطبيق السلوك القديم. يستخدم Java Keystore SPI هذا النطاق تلقائيًا. عند استخدام هذا النطاق، يتم تجاهل وسيطة مساحة الاسم ويتم استخدام معرّف المستخدم للمتصل بدلاً من ذلك. يتم التحكّم في الوصول إلى هذا النطاق من خلال تصنيف "متجر المفاتيح" للملف الذي ينتمي إلى الفئة keystore_key في سياسة SELinux.
• DOMAIN_SELINUX: يشير هذا النطاق إلى أنّ مساحة имен تتضمن تصنيفًا في سياسة SELinux. يتم البحث عن مَعلمة مساحة الاسم وترجمتها إلى سياق مستهدَف، ويتم إجراء عملية التحقّق من الأذونات لسياق SELinux الذي يُجري عملية الاتصال لفئة keystore_key. عند تحديد الإذن للعملية المحدّدة، يتم استخدام المجموعة الكاملة لبحث المفتاح.
• DOMAIN_GRANT: يشير نطاق الإذن إلى أنّ مَعلمة مساحة الاسم هي معرّف إذن. يتم تجاهل مَعلمة الاسم المعرِّف. يتم إجراء عمليات التحقّق من SELinux عند إنشاء الإذن. لا يتحقّق التحكّم الإضافي في الوصول سوى مما إذا كان معرّف المستخدِم المُتصل يتطابق مع معرّف المستخدِمين الممنوحين للمنحة المطلوبة.
• DOMAIN_KEY_ID: يشير هذا النطاق إلى أنّ مَعلمة النطاق هي معرّف مفتاح فريد. قد يكون المفتاح نفسه قد تم إنشاؤه باستخدام DOMAIN_APP أو DOMAIN_SELINUX. يتم إجراء التحقّق من الإذن بعد تحميل domain وnamespace من قاعدة بيانات المفاتيح بالطريقة نفسها التي يتم بها تحميل ملف البيانات المتعدّدة العناصر من خلال النطاق ومساحة الاسم ومجموعة القيم المستعارة. يستند المنطق المستخدَم في نطاق رقم تعريف المفتاح إلى الاستمرارية. عند الوصول إلى مفتاح باستخدام الاسم المعرِّف، يمكن أن تعمل المكالمات اللاحقة باستخدام مفاتيح مختلفة، لأنّه قد يتم إنشاء مفتاح جديد أو استيراده وربطه بهذا الاسم المعرِّف. ومع ذلك، لا يتغيّر معرّف المفتاح مطلقًا. وبالتالي، عند استخدام مفتاح حسب رقم تعريف المفتاح بعد تحميله من قاعدة بيانات Keystore باستخدام الاسم المعرِّف مرّة واحدة، يمكن التأكّد من أنّه المفتاح نفسه ما دام رقم تعريف المفتاح لا يزال متوفّرًا. ولا تظهر هذه الميزة لمطوّري التطبيقات. بدلاً من ذلك، يتم استخدامه ضمن واجهة برمجة التطبيقات لـ Android Keystore لتوفير تجربة أكثر اتساقًا حتى عند استخدامه بشكل متزامن بطريقة غير آمنة.
• ‫DOMAIN_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);

يمكن استخدام ملفات السياق التالية لضبط مساحات أسماء SELinux في Keystore 2.0. يحتوي كل قسم على نطاق محجوز مختلف من 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: