يتيح توفُّر بيئة تنفيذ موثوقة (TEE) في نظام على شريحة (SoC) لأجهزة Android تقديم خدمات أمان قوية ومستندة إلى الأجهزة لنظام التشغيل Android وخدمات النظام الأساسي وحتى تطبيقات الجهات الخارجية (في شكل إضافات خاصة بنظام Android إلى بنية Java القياسية للتشفير، راجِع KeyGenParameterSpec).
مسرد المصطلحات
في ما يلي نظرة عامة سريعة على مكوّنات Keystore وعلاقاتها.
AndroidKeyStore- واجهة برمجة التطبيقات وإطار عمل Android والمكوّن المستخدَم
من قِبل التطبيقات للوصول إلى وظائف Keystore وهي عبارة عن تنفيذ لواجهات برمجة التطبيقات المتوافقة مع معيار بنية تشفير Java، ولكنها تضيف أيضًا إضافات خاصة بنظام Android وتتألف من رمز Java البرمجي الذي يتم تنفيذه في مساحة العملية الخاصة بالتطبيق. تنفِّذ
AndroidKeyStoreطلبات التطبيقات المتعلقة بسلوك Keystore من خلال إعادة توجيهها إلى برنامج Keystore الخفي. - keystore daemon
- برنامج خفي لنظام التشغيل Android يتيح الوصول إلى جميع وظائف Keystore من خلال واجهة برمجة تطبيقات Binder. هذه العملية المساعِدة مسؤولة عن تخزين keyblobs التي تم إنشاؤها بواسطة تنفيذ KeyMint (أو Keymaster) الأساسي، والتي تحتوي على مادة المفتاح السري، ويتم تشفيرها حتى يتمكّن Keystore من تخزينها بدون استخدامها أو الكشف عنها.
- خدمة KeyMint HAL
- خادم AIDL ينفّذ
واجهة
IKeyMintDeviceHAL، ما يتيح الوصول إلى بيئة التنفيذ الموثوقة (TA) الأساسية في KeyMint. - تطبيق KeyMint الموثوق (TA)
- برنامج يتم تشغيله في سياق آمن، وغالبًا ما يكون في TrustZone على نظام ARM SoC، ويوفر جميع عمليات التشفير الآمنة. يتمكّن هذا التطبيق من الوصول إلى مواد المفاتيح الأولية، ويتحقّق من جميع شروط التحكّم في الوصول إلى المفاتيح قبل السماح باستخدامها.
LockSettingsService- مكوّن نظام التشغيل Android المسؤول عن مصادقة المستخدم، سواء باستخدام كلمة المرور أو بصمة الإصبع لا يشكّل هذا الجزء جزءًا من Keystore، ولكنّه ذو صلة لأنّ Keystore يتيح استخدام المفاتيح المرتبطة بالمصادقة، وهي مفاتيح لا يمكن استخدامها إلا إذا تمت مصادقة المستخدم.
يتفاعل
LockSettingsServiceمع Gatekeeper TA وFingerprint TA للحصول على رموز المصادقة المميزة التي يقدّمها إلى برنامج KeyStore الخفي، وتستهلكها KeyMint TA. - Gatekeeper TA
- العنصر الذي يتم تشغيله في البيئة الآمنة والمسؤول عن مصادقة كلمات مرور المستخدمين وإنشاء رموز مميزة للمصادقة تُستخدَم لإثبات أنّ عملية المصادقة قد تمت لمستخدم معيّن في وقت معيّن إلى KeyMint TA.
- Fingerprint TA
- العنصر الذي يعمل في البيئة الآمنة والمسؤول عن مصادقة بصمات المستخدمين وإنشاء رموز مميّزة للمصادقة تُستخدَم لإثبات أنّ عملية المصادقة قد تمت لمستخدم معيّن في وقت معيّن، وذلك في KeyMint TA.
البنية
توفّر واجهة برمجة التطبيقات Android Keystore وKeyMint HAL الأساسي مجموعة أساسية ولكنها كافية من العناصر الأولية للتشفير للسماح بتنفيذ البروتوكولات باستخدام مفاتيح محمية بأجهزة ومحدودة الوصول.
KeyMint HAL هي خدمة توفّرها الشركة المصنّعة للمعدات الأصلية وتستخدمها خدمة Keystore لتوفير خدمات تشفير تستند إلى الأجهزة. للحفاظ على أمان مواد المفتاح الخاص، لا تنفّذ عمليات HAL أي عمليات حساسة في مساحة المستخدم أو حتى في مساحة النواة. بدلاً من ذلك، تفوِّض خدمة KeyMint HAL التي تعمل في Android العمليات الحسّاسة إلى بيئة تنفيذ موثوقة تعمل في نوع من البيئات الآمنة، وذلك عادةً من خلال تحويل الطلبات إلى تنسيق سلكي محدّد في التنفيذ وتحويلها مرة أخرى.
تبدو البنية الناتجة على النحو التالي:
الشكل 1. الوصول إلى KeyMint
واجهة برمجة التطبيقات KeyMint HAL هي واجهة منخفضة المستوى تستخدمها المكوّنات الداخلية للنظام الأساسي، ولا يتم عرضها لمطوّري التطبيقات. يمكنك الاطّلاع على وصف لواجهة برمجة التطبيقات Java ذات المستوى الأعلى والمتاحة للتطبيقات على موقع "مطوّرو تطبيقات Android" الإلكتروني.
التحكّم في إمكانية الوصول
توفّر خدمة Android Keystore مكوّنًا مركزيًا لتخزين واستخدام مفاتيح التشفير المستندة إلى الأجهزة، وذلك لكل من التطبيقات ومكوّنات النظام الأخرى. وبالتالي، يقتصر الوصول إلى أي مفتاح فردي عادةً على التطبيق أو جزء النظام الذي أنشأ المفتاح.
نطاقات ملف تخزين المفاتيح
ولإتاحة التحكّم في الوصول، يتم تعريف المفاتيح في Keystore باستخدام وصف مفتاح. يشير واصف المفتاح هذا إلى نطاق ينتمي إليه الواصف، بالإضافة إلى هوية ضمن هذا النطاق.
تصل تطبيقات Android إلى Keystore باستخدام بنية تشفير لغة البرمجة Java العادية، والتي تحدّد المفاتيح باستخدام اسم مستعار عبارة عن سلسلة. يتم ربط طريقة التعريف هذه بنطاق APP في Keystore داخليًا، كما يتم تضمين المعرّف الفريد للمتصل لتجنُّب الغموض بشأن المفاتيح من التطبيقات المختلفة، ما يمنع أحد التطبيقات من الوصول إلى مفاتيح تطبيق آخر.
داخليًا، يتلقّى رمز الأُطر أيضًا معرّفًا
فريدًا بعد تحميل المفتاح. يُستخدَم هذا المعرّف الرقمي كمعرّف لأوصاف المفاتيح ضمن نطاق KEY_ID. ومع ذلك، يظل يتم تنفيذ عملية التحكّم في الوصول: حتى إذا اكتشف أحد التطبيقات معرّف مفتاح لتطبيق آخر، لا يمكنه استخدامه في الظروف العادية.
ومع ذلك، يمكن لتطبيق منح إذن استخدام مفتاح لتطبيق آخر (يتم تحديده بواسطة معرّف UID). تعرض عملية منح الإذن هذه معرّفًا فريدًا لمنح الإذن،
ويُستخدَم هذا المعرّف كمعرّف لواصفات المفاتيح ضمن
النطاق GRANT. مرة أخرى، سيظل يتم التحكّم في الوصول: حتى إذا عثر تطبيق تابع لجهة خارجية على معرّف الإذن لمفتاح أحد المستلمين، لن يتمكّن من استخدامه.
تتيح خدمة Keystore أيضًا نطاقَين آخرَين لواصفات المفاتيح، ويتم استخدامهما لمكوّنات النظام الأخرى ولا يتوفّران للمفاتيح التي تنشئها التطبيقات:
- يشير النطاق
BLOBإلى أنّه لا يوجد معرّف للمفتاح في واصف المفتاح، بل يحتوي واصف المفتاح على keyblob نفسه ويتولّى العميل معالجة تخزين keyblob. يتم استخدام هذا الخيار من قِبل البرامج (مثلvold) التي تحتاج إلى الوصول إلى Keystore قبل تحميل قسم البيانات. - يسمح النطاق
SELINUXلمكوّنات النظام بمشاركة المفاتيح، ويتم تنظيم إذن الوصول من خلال معرّف رقمي يتوافق مع تصنيف SELinux (راجِع سياسة SELinux الخاصة بـ keystore_key).
سياسة SELinux لـ keystore_key
يتم ضبط قيم المعرّفات المستخدَمة في واصفات مفاتيح Domain::SELINUX في ملف سياسة keystore2_key_context SELinux.
يربط كل سطر في هذه الملفات رقمًا بتصنيف 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) |
يستخدمه نظام Wi-Fi الفرعي في Android، بما في ذلك wpa_supplicant. |
| 103 | locksettings_key |
لا ينطبق | يستخدمه LockSettingsService |
| 120 | resume_on_reboot_key |
AID_SYSTEM(1000) |
يستخدمه خادم نظام Android لإتاحة استئناف العمل بعد إعادة التشغيل. |
متجهات الوصول
تتيح خدمة Keystore التحكّم في العمليات التي يمكن تنفيذها على أحد المفاتيح، بالإضافة إلى التحكّم في إمكانية الوصول إلى المفتاح بشكل عام. يتم وصف أذونات keystore2_key في ملف KeyPermission.aidl.
أذونات النظام
بالإضافة إلى عناصر التحكّم في الوصول لكل مفتاح الموضّحة في سياسة SELinux لمفتاح keystore_key، يوضّح الجدول التالي أذونات SELinux الأخرى المطلوبة لتنفيذ عمليات مختلفة للنظام والصيانة:
| الإذن | المعنى |
|---|---|
add_auth
|
مطلوب لإضافة رموز المصادقة إلى Keystore، ويتم استخدامه من قِبل موفّري خدمات المصادقة، مثل Gatekeeper أو BiometricManager. |
clear_ns
|
مطلوب لحذف جميع المفاتيح في مساحة اسم معيّنة، ويُستخدَم كعملية صيانة عند إلغاء تثبيت التطبيقات. |
list
|
يطلبها النظام لتعداد المفاتيح حسب خصائص مختلفة، مثل الملكية أو ما إذا كانت مرتبطة بالمصادقة. لا يحتاج المتصلون إلى هذا الإذن إذا كانوا يعددون مساحات الأسماء الخاصة بهم (يغطيه الإذن get_info). |
lock
|
مطلوب لإعلام خدمة تخزين المفاتيح بأنّه تم قفل الجهاز، ما يؤدي بدوره إلى إزالة المفاتيح الفائقة لضمان عدم توفّر المفاتيح المرتبطة بالمصادقة. |
unlock
|
يجب إعلام خدمة تخزين المفاتيح بأنّه تم فتح قفل الجهاز، ما يؤدي إلى استعادة إمكانية الوصول إلى المفاتيح الفائقة التي تحمي المفاتيح المرتبطة بالمصادقة. |
reset
|
مطلوب لإعادة ضبط Keystore على الإعدادات الأصلية وحذف جميع المفاتيح غير الضرورية لتشغيل نظام التشغيل Android. |
السجلّ
في الإصدار 5 من نظام التشغيل Android والإصدارات الأقدم، كان نظام التشغيل يتضمّن واجهة برمجة تطبيقات بسيطة للخدمات التشفيرية تستند إلى الأجهزة، وقد تم توفيرها من خلال الإصدارَين 0.2 و0.3 من طبقة تجريد الأجهزة (HAL) الخاصة بـ Keymaster. يوفّر ملف تخزين المفاتيح عمليات التوقيع الرقمي والتحقّق، بالإضافة إلى إنشاء واستيراد أزواج مفاتيح التوقيع غير المتماثلة. تم تنفيذ ذلك على العديد من الأجهزة، ولكن هناك العديد من أهداف الأمان التي لا يمكن تحقيقها بسهولة باستخدام واجهة برمجة تطبيقات التوقيع فقط. أضاف الإصدار 6.0 من نظام التشغيل Android إمكانات أوسع إلى واجهة برمجة التطبيقات Keystore API.
Android 6.0
في الإصدار 6.0 من نظام التشغيل Android، أضاف 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.
بالإضافة إلى مراجعة الواجهة هذه، وسّع الإصدار 8.0 من نظام التشغيل Android ميزة "التصديق" في Keymaster 2 لتتيح تصديق المعرّف. توفّر خدمة إثبات صحة المعرّف آلية محدودة واختيارية لإثبات صحة معرّفات الأجهزة، مثل الرقم التسلسلي للجهاز واسم المنتج ومعرّف الهاتف (IMEI أو MEID). لتنفيذ هذه الإضافة، غيّر نظام التشغيل Android 8.0 مخطط ASN.1 الخاص بشهادة التصديق لإضافة شهادة التصديق الخاصة بالمعرّف. يجب أن توفّر عمليات تنفيذ Keymaster طريقة آمنة لاسترداد عناصر البيانات ذات الصلة، بالإضافة إلى تحديد آلية لإيقاف الميزة بشكل آمن ودائم.
Android 9
في نظام التشغيل Android 9، تضمنت التحديثات ما يلي:
- تعديل على Keymaster 4
- إتاحة "العناصر الآمنة" المضمّنة
- إتاحة استيراد مفتاح آمن
- إتاحة تشفير 3DES
- تغييرات على ربط الإصدارات بحيث يكون لكل من
boot.imgوsystem.imgإصدارات مضبوطة بشكل منفصل للسماح بتحديثات مستقلة
Android 10
قدّم الإصدار 10 من نظام التشغيل Android الإصدار 4.1 من طبقة تجريد الأجهزة (HAL) الخاصة بخدمة Keymaster، والتي أضافت ما يلي:
- إتاحة استخدام المفاتيح فقط عندما يكون الجهاز غير مقفل
- إتاحة استخدام المفاتيح في مراحل بدء التشغيل المبكرة فقط
- إتاحة مفاتيح التخزين المحمي بالأجهزة بشكل اختياري
- إتاحة المصادقة الفريدة للجهاز في StrongBox بشكل اختياري
Android 12
قدَّم نظام التشغيل Android 12 طبقة تجريد الأجهزة (HAL) الجديدة KeyMint التي تحلّ محل طبقة تجريد الأجهزة (HAL) Keymaster ولكنها توفّر وظائف مشابهة. بالإضافة إلى جميع الميزات المذكورة أعلاه، تتضمّن طبقة تجريد الأجهزة KeyMint أيضًا ما يلي:
- إتاحة الاتفاق على مفتاح ECDH
- إتاحة مفاتيح التأكيد التي يحدّدها المستخدم
- إتاحة استخدام المفاتيح لعدد محدود من المرات
يتضمّن نظام التشغيل Android 12 أيضًا إصدارًا جديدًا من البرنامج الخفي لنظام keystore،
تمت إعادة كتابته بلغة Rust ويُعرف باسم keystore2
Android 13
أضاف نظام التشغيل Android 13 الإصدار 2 من KeyMint HAL، الذي يتيح استخدام Curve25519 للتوقيع واتفاقية المفتاح.