مدى توفُّر بيئة تنفيذ موثوقة في نظام على شريحة (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. تبدو البنية الناتجة كما يلي:
![الوصول إلى Keymaster](https://source.android.com/static/docs/security/images/access-to-keymaster.png?authuser=9&hl=ar)
الشكل 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 مساحة اسم المعرفات لتجنب الاصطدامات.
قسم | النطاق | ملفات الإعداد |
---|---|---|
النظام | 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"
، من خلال معرّفها الرقمي.
أعلى ذلك، تم تحديد مساحات الاسم التالية. إذا استبدلا قواعد خاصة، يشير الجدول التالي إلى المعرّف الفريد الذي تم استخدامه للتوافق إليه.
الرقم التعريفي لمساحة الاسم | تصنيف SEPolicy | المعرّف الفريد | الوصف |
---|---|---|---|
0 | مفتاح_سو | لا ينطبق | مفتاح المستخدم المميز. يُستخدَم فقط لاختبار بُنى userdebug وeng. لا وثيق الصلة في بُنى المستخدم. |
1 | مفتاح_الصدفة | لا ينطبق | مساحة الاسم متاحة لنظام واجهة الأوامر. يُستخدم في الغالب للاختبار، ولكن يمكن استخدامه على المستخدم أيضًا من سطر الأوامر. |
100 | مفتاح_فولد | لا ينطبق | مخصص للاستخدام بواسطة vold. |
101 | مفتاح_odsing | لا ينطبق | يستخدمه البرنامج الخفي للتوقيع على الجهاز فقط. |
102 | مفتاح_wifi | AID_WIFI(1010) | ويستخدمه نظام إدارة شبكات Wi-Fi في Android بما في ذلك wpa_supplicant. |
120 | الاستئناف_على_مفتاح_إعادة التشغيل | AID_SYSTEM(1000) | يستخدمه خادم نظام Android لدعم الاستئناف عند إعادة التشغيل. |
الوصول إلى المتجهات
فئة SELinux keystore_key
قديمة جدًا وبعض
فقدت الأذونات، مثل verify
أو sign
معناها. ها هي مجموعة الأذونات الجديدة، keystore2_key
،
الذي سيفرضه ملف تخزين المفاتيح 2.0.
الإذن | المعنى |
---|---|
delete
|
تم وضع علامة في المربّع عند إزالة المفاتيح من ملف تخزين المفاتيح. |
get_info
|
يتم وضع علامة في المربّع عندما يتم طلب البيانات الوصفية لمفتاح. |
grant
|
يحتاج المتصل إلى هذا الإذن لإنشاء منح للمفتاح في الهدف. السياق. |
manage_blob
|
قد يستخدم المتصل DOMAIN_BLOB في مساحة اسم SELinux المحددة،
وبالتالي إدارة النقاط الثنائية الكبيرة بمفردها. يعد ذلك مفيدًا على وجه التحديد
المجلد |
rebind
|
يتحكّم هذا الإذن في ما إذا كان بإمكان الاسم المستعار العودة إلى مفتاح جديد. هذا هو مطلوب للإدراج ويشير إلى أن المفتاح المرتبط سابقًا سيتم حذف. هو في الأساس إذن إدراج، ولكنه يلتقط الدلالة ملف تخزين المفاتيح بشكل أفضل. |
req_forced_op
|
يمكن للعملاء الذين لديهم هذا الإذن إنشاء عمليات غير قابلة للتنفيذ. لا يفشل إنشاء العملية أبدًا ما لم يتم اختيار جميع خانات العمليات بواسطة والعمليات غير القابلة للقطع. |
update
|
مطلوب لتعديل المكوِّن الفرعي لمفتاح. |
use
|
يتم التحقق منه عند إنشاء عملية Keymint التي تستخدم المادة الرئيسية، مثل، للتوقيع، أو فك التشفير. |
use_dev_id
|
مطلوبة عند إنشاء معلومات لتحديد هوية الجهاز، مثل رقم تعريف الجهاز والتحقق. |
بالإضافة إلى ذلك، نقسم مجموعة من أذونات تخزين المفاتيح غير المحددة للمفاتيح في
فئة أمان SELinux keystore2
:
الإذن | المعنى |
---|---|
add_auth
|
مطلوبة من مقدِّم خدمات المصادقة، مثل Gatekeeper أو BiometricsManager لإضافة رموز المصادقة. |
clear_ns
|
كان هذا الإذن يُعرف سابقًا باسم clear_uid، ويسمح لغير مالك مساحة الاسم حذف كل المفاتيح في مساحة الاسم هذه. |
list
|
يطلبه النظام لتعداد المفاتيح حسب الخصائص المختلفة، مثل
حدود الملكية أو المصادقة لا يطلب المتصلون هذا الإذن.
مع تعداد مساحات الاسم الخاصة بها. ويتم تغطية ذلك من خلال
إذن get_info . |
lock
|
يتيح هذا الإذن قفل ملف تخزين المفاتيح، بمعنى إزالة المفتاح الرئيسي، أن المفاتيح المرتبطة بالمصادقة تصبح غير قابلة للاستخدام وغير قابلة للإنشاء. |
reset
|
يتيح هذا الإذن إعادة ضبط ملف تخزين المفاتيح على الإعدادات الأصلية التلقائية، ما يؤدي إلى حذف جميع غير الحيوية لعمل نظام التشغيل Android. |
unlock
|
هذا الإذن مطلوب لمحاولة فتح قفل المفتاح الرئيسي للمصادقة. المرتبطة. |