اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.

تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

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

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

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

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

AndroidKeyStore: واجهة برمجة التطبيقات ووحدة Android Framework API المستخدَمة من قِبل التطبيقات للوصول إلى وظائف Keystore وهو عبارة عن تنفيذ لواجهتَي برمجة التطبيقات العاديتَين لبنية تشفير Java، ولكنه يضيف أيضًا امتدادات خاصة بنظام التشغيل Android ويتألف من رمز Java الذي يتم تشغيله في مساحة عملية التطبيق. تلبي AndroidKeyStore طلبات التطبيقات بشأن سلوك "متجر المفاتيح" من خلال إعادة توجيهها إلى الخادم الخفي لمتجر المفاتيح.
الخادم الدائم لملف تخزين المفاتيح: خدمة خلفية لنظام Android توفّر إمكانية الوصول إلى جميع وظائف "متجر المفاتيح" من خلال واجهة برمجة تطبيقات Binder هذا الخادم الدائم مسؤول عن تخزين مجموعات مفاتيح التشفير التي تم إنشاؤها من خلال التنفيذ الأساسي لـ KeyMint (أو Keymaster)، والتي تحتوي على مادة المفتاح السري المشفَّرة بحيث يمكن لـ Keystore تخزينها ولكن ليس استخدامها أو الكشف عنها.
خدمة KeyMint HAL: خادم AIDL الذي ينفِّذ IKeyMintDevice HAL، ما يتيح الوصول إلى وحدة KeyMint TA الأساسية
تطبيق KeyMint الموثوق به (TA): البرامج التي تعمل في سياق آمن، غالبًا في TrustZone على شريحة منظومة مكاملة لشرائح ARM، والتي توفّر كل العمليات المشفّرة الآمنة يمكن لهذا التطبيق الوصول إلى مادة المفتاح الأولية، والتحقّق منvalidity جميع شروط التحكّم في الوصول إلى المفاتيح قبل السماح باستخدامها.
LockSettingsService: مكوّن نظام Android المسؤول عن مصادقة المستخدم، سواء باستخدام كلمة المرور أو بصمة الإصبع وهي ليست جزءًا من Keystore، ولكنها ذات صلة لأنّ Keystore يتيح استخدام المفاتيح المرتبطة بالمصادقة: وهي مفاتيح لا يمكن استخدامها إلا إذا تم مصادقة المستخدم. يتفاعل LockSettingsService مع وحدة التحكّم في الوصول (TA) و وحدة التحكّم في بصمة الإصبع (TA) للحصول على رموز المصادقة التي يوفّرها لملف تخزين مفاتيح التشغيل (DSK) ويستهلكها ملف التحكّم في إنشاء المفاتيح (TA).
Gatekeeper TA: المكوّن الذي يعمل في البيئة الآمنة والمكلّف بمصادقة كلمات مرور المستخدمين وإنشاء الرموز المميّزة للمصادقة المستخدَمة لإثبات أنّه تمت مصادقة مستخدم معيّن في وقت معيّن لمسؤول النقل في KeyMint
Fingerprint TA: المكوّن الذي يعمل في البيئة الآمنة والمُستخدَم لمصادقة بصمات مستخدمين وإنشاء الرموز المميّزة للمصادقة المستخدَمة لإثبات أنّه تمت مصادقة مستخدم معيّن في وقت معيّن لمسؤول النقل في KeyMint

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

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

‫KeyMint HAL هي خدمة يوفّرها المصنّع الأصلي للجهاز وتستخدمها خدمة Keystore لتوفير خدمات التشفير المستندة إلى الأجهزة. للحفاظ على أمان مادة المفتاح الخاص، لا تُنفِّذ عمليات HAL أي عمليات حسّاسة في مساحة المستخدم أو حتى في مساحة النواة. بدلاً من ذلك، تفوض خدمة KeyMint HAL التي تعمل في Android العمليات الحسّاسة إلى وحدة تحكّم في التطبيقات (TA) تعمل في نوع من البيئة الآمنة، وذلك عادةً من خلال تجميع الطلبات وتحويلها إلى تنسيق برمجي في تنسيق سلك محدّد التنفيذ.

تظهر البنية الناتجة على النحو التالي:

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

واجهة برمجة التطبيقات KeyMint HAL API من المستوى المنخفض، وتستخدمها المكوّنات الداخلية للنظام الأساسي، ولا يتم إتاحتها لمطوّري التطبيقات. يمكنك الاطّلاع على واجهة برمجة التطبيقات Java API ذات المستوى الأعلى المتوفّرة للتطبيقات على موقع "مطوّرو تطبيقات Android" الإلكتروني.

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

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

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

لدعم ميزة التحكّم في الوصول هذه، يتم تحديد المفاتيح في "متجر المفاتيح" باستخدام وصف المفتاح. يشير هذا الوصف الرئيسي إلى نطاق الذي ينتمي إليه الوصف، بالإضافة إلى هوية ضمن هذا النطاق.

تحصل تطبيقات Android على إذن الوصول إلى ملف تخزين المفاتيح باستخدام بنية Java Cryptography المعيارية التي تحدِّد المفاتيح باستخدام اسم بديل لسلاسل الأحرف. وتتطابق طريقة تحديد هوية العميل هذه مع نطاق Keystore APP داخليًا، ويتم أيضًا تضمين رقم تعريف العميل المتصل لإزالة الغموض عن المفاتيح من التطبيقات المختلفة، ما يمنع أحد التطبيقات من الوصول إلى مفاتيح تطبيق آخر.

داخليًا، يتلقّى رمز الإطارات أيضًا مفتاحًا رقميًا فريدًا بعد تحميل مفتاح. يُستخدَم هذا المعرّف الرقمي كمعرّف لموصِفِي المفاتيح ضمن نطاق KEY_ID. ومع ذلك، يستمر التحكّم في الوصول: حتى إذا اكتشف تطبيق معيّن رقم تعريف مفتاح لتطبيق آخر، لا يمكنه استخدامه في الظروف العادية.

ومع ذلك، يمكن للتطبيق منح إذن استخدام مفتاح لتطبيق مختلف (كما هو محدّد من خلال المعرّف الفريد). تُعرِض عملية منح الأذونات معرّفًا فريدًا لمنح الأذونات، يُستخدَم كمعرّف لموصِّفي المفاتيح ضمن نطاق GRANT. يبقى التحكّم في الوصول ساريًا: حتى إذا اكتشف تطبيق ثالث معرّف منح المفتاح الخاص بالممنوح، لن يتمكّن من استخدامه.

يتيح "متجر المفاتيح" أيضًا نطاقَين آخرين لموصّفي المفاتيح، ويتم استخدامهما لمكونات النظام الأخرى ولا يتوفّران للمفاتيح التي أنشأها التطبيق:

يشير نطاق BLOB إلى عدم توفّر معرّف للمفتاح في وصف المفتاح، وبدلاً من ذلك، يحتوي وصف المفتاح على ملف keyblob نفسه ويعالج العميل تخزين ملف keyblob. ويستخدمه العملاء (مثل vold) الذين يحتاجون إلى الوصول إلى "متجر المفاتيح" قبل تركيب قسم البيانات.
يسمح نطاق SELINUX لمكونات النظام بمشاركة المفاتيح، مع تحديد إمكانية الوصول من خلال معرّف رقمي يتوافق مع تصنيف SELinux (راجِع سياسة SELinux لمفتاح keystore_key).

سياسة SELinux لمفتاح keystore_key

يتم ضبط قيم المعرّفات المستخدَمة لموصّفات مفاتيح Domain::SELINUX في ملف سياسة SELinux الخاص بـ 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

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

allow hal_wifi_supplicant wifi_key:keystore2_key { get, use };

يتم تقسيم المعرّفات الرقمية لمفاتيح Domain::SELINUX إلى نطاقات لتتوافق مع الأقسام المختلفة بدون حدوث تعارضات:

قسم	النطاق	ملفات الإعداد
النظام	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`

تم تحديد القيم المحدّدة التالية لقسيمة النظام:

الرقم التعريفي لمساحة الاسم	تصنيف SEPolicy	UID	الوصف
0	`su_key`	لا ينطبق	مفتاح المستخدم المتميّز لا يتم استخدامه إلا للاختبار على إصدارات userdebug وeng. لا يسري هذا الإجراء على إصدارات المستخدمين.
1	`shell_key`	لا ينطبق	مساحة الاسم متاحة لوحدة التحكّم. تُستخدَم هذه الطريقة في الغالب للاختبار، ولكن يمكن استخدامها أيضًا في ملفّات برمجة المستخدمين من سطر الأوامر.
100	`vold_key`	لا ينطبق	مخصّص لاستخدام vold
101	`odsign_key`	لا ينطبق	يُستخدَم من قِبل برنامج التشغيل الخفي للتوقيع على الجهاز.
102	`wifi_key`	`AID_WIFI(1010)`	يستخدمه نظام Wifi الفرعي في Android، بما في ذلك `wpa_supplicant`.
103	`locksettings_key`	لا ينطبق	المستخدِم: `LockSettingsService`
120	`resume_on_reboot_key`	`AID_SYSTEM(1000)`	يستخدمه خادم نظام Android للسماح بمواصلة العمل عند إعادة التشغيل.

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

يتيح لك "متجر المفاتيح" التحكّم في العمليات التي يمكن تنفيذها على مفتاح، بالإضافة إلى التحكّم في الوصول العام إلى مفتاح. يتم وصف أذونات keystore2_key فيملف KeyPermission.aidl.

أذونات النظام

بالإضافة إلى عناصر التحكّم في الوصول إلى كل مفتاح موضّحة في سياسة SELinux لمفتاح keystore_key، يصف الجدول التالي أذونات SELinux الأخرى المطلوبة لتنفيذ مختلف عمليات النظام والصيانة:

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

السجلّ

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

Android 6.0

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

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

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

Android 7.0

في الإصدار 7.0 من نظام Android، أضاف Keymaster 2 ميزة إثبات ملكية المفتاح وربط الإصدار.

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

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

Android 8.0

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

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

Android 9

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

التحديث إلى Keymaster 4
إتاحة عناصر الأمان المضمّنة
إتاحة استيراد مفاتيح الأمان
إتاحة استخدام خوارزمية الترميز 3DES
تغييرات على ربط الإصدارات لكي يكون لدى boot.img وsystem.img إصدارات تم ضبطها بشكل منفصل للسماح بإجراء تحديثات مستقلة

Android 10

طرح نظام التشغيل Android 10 الإصدار 4.1 من Keymaster HAL، والذي أضاف ما يلي:

إتاحة مفاتيح لا يمكن استخدامها إلا عندما يكون الجهاز غير مقفل
إتاحة استخدام مفاتيح لا يمكن استخدامها إلا في مراحل التشغيل المبكّرة
إتاحة اختيارية لمفاتيح التخزين المضمّنة في الأجهزة
إتاحة اختيارية للمصادقة الفريدة على الجهاز في StrongBox

Android 12

قدّم نظام التشغيل Android 12 طبقة KeyMint HAL الجديدة التي تحلّ محلّ Keymaster HAL، ولكنها توفّر وظائف مشابهة. بالإضافة إلى جميع الميزات المذكورة أعلاه، يتضمّن KeyMint HAL أيضًا ما يلي:

إتاحة ميزة الاتفاق على مفتاح التشفير المتماثل (ECDH)
إتاحة مفاتيح الإثبات التي يحدّدها المستخدم
إتاحة مفاتيح ذات عدد محدود من الاستخدامات

يتضمّن نظام التشغيل Android 12 أيضًا إصدارًا جديدًا من الخادم الدائم لنظام تخزين المفاتيح، الذي تمت إعادة كتابته بلغة Rust ويُعرف باسم keystore2.

Android 13

أضاف نظام Android 13 الإصدار 2 من KeyMint HAL، الذي يضيف إمكانية استخدام Curve25519 لكل من التوقيع واتفاقية المفتاح.