موفِّر الخدمات

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

عندما يتحقّق المستخدمون من كلمات المرور، يُصدر Gatekeeper رمز مصادقة موقَّعًا باستخدام مفتاح HMAC لكل عملية تشغيل، ولا يتوفّر هذا المفتاح إلا للمكوّنات الآمنة، ويتم إرسال هذا الرمز إلى Keystore المستنِد إلى الأجهزة. يعني ذلك أنّ رمز مصادقة Gatekeeper يُعلم Keystore بأنّه يمكن للتطبيقات استخدام المفاتيح المرتبطة بالمصادقة (على سبيل المثال، المفاتيح التي أنشأتها التطبيقات).

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

يتضمّن Gatekeeper ثلاثة مكوّنات رئيسية:

• gatekeeperd (برنامج Gatekeeper الخفي): هي خدمة Binder بلغة C++ في Android تحتوي على منطق مستقل عن النظام الأساسي ينفّذ واجهة IGateKeeperService AIDL، استنادًا إلى تنفيذ أساسي خاص بالمورِّد لواجهة IGatekeeper.
• خدمة طبقة التجريد للأجهزة (HAL) في Gatekeeper: هي تنفيذ خاص بالمورِّد لواجهة IGatekeeper AIDL. تعمل خدمة HAL هذه في Android، ولكن يجب أن تعمل وظائف Gatekeeper الأساسية في بيئة آمنة، لذا تتواصل عادةً مع تطبيق Gatekeeper الموثوق (TA).
• تطبيق Gatekeeper الموثوق (TA): هو تنفيذ خاص بالمورِّد يعمل في بيئة التنفيذ الموثوقة (TEE)، ويُجري عملية التحقّق الفعلية من كلمة المرور أو النمط.

يُرسل LockSettingsService طلبًا (من خلال Binder) يصل إلى البرنامج الخفي gatekeeperd في نظام التشغيل Android. بعد ذلك، يُرسل البرنامج الخفي gatekeeperd طلبًا إلى خدمة IGatekeeper HAL، ويصل هذا الطلب بدوره إلى تطبيق Gatekeeper الموثوق (TA) المقابل في بيئة التنفيذ الموثوقة (TEE):

الشكل 1: مخطط انسياب تدفق البيانات عالي المستوى للمصادقة من خلال GateKeeper

يمنح البرنامج الخفي gatekeeperd واجهات برمجة تطبيقات إطار عمل Android إمكانية الوصول إلى طبقة التجريد للأجهزة (HAL)، ويشارك في إرسال تقارير عن عمليات مصادقة الأجهزة إلى Keystore. يعمل البرنامج الخفي gatekeeperd في عملية خاصة به ومنفصلة عن خادم النظام.

تنفيذ طبقة التجريد للأجهزة (HAL)

يستخدم البرنامج الخفي gatekeeperd طبقة التجريد للأجهزة IGatekeeper للتفاعل مع تطبيق Gatekeeper الموثوق (TA) الأساسي من أجل مصادقة كلمة المرور. يجب أن يكون تنفيذ تطبيق Gatekeeper الموثوق (TA) قادرًا على توقيع (تسجيل) الكائنات الثنائية الكبيرة والتحقّق منها. من المتوقّع أن تلتزم جميع عمليات التنفيذ بالتنسيق العادي لرمز المصادقة (HardwareAuthToken) الذي يتم إنشاؤه في كل عملية تحقّق ناجحة من كلمة المرور. للحصول على تفاصيل حول محتوى HardwareAuthToken ودلالاته، يُرجى الاطّلاع على HardwareAuthToken.aidl تعريف.

يجب أن تنفّذ عمليات تنفيذ طبقة التجريد للأجهزة IGatekeeper الخاصة بالمورِّد الدالتَين enroll وverify:

• تأخذ طريقة enroll كائنًا ثنائيًا كبيرًا لكلمة المرور وتوقّعه وتعرض التوقيع كمقبض. يجب أن يكون للكائن الثنائي الكبير الذي يتم عرضه (من طلب إلى enroll) البنية الموضّحة في system/gatekeeper/include/gatekeeper/password_handle.h.
• يجب أن تقارن الدالة verify التوقيع الذي تم إنشاؤه باستخدام كلمة المرور المقدَّمة والتأكّد من أنّه يطابق مقبض كلمة المرور المسجَّلة.

يجب ألا يتغيّر المفتاح المستخدَم للتسجيل والتحقّق منه أبدًا، ويجب أن يكون قابلاً لإعادة الاشتقاق في كل عملية تشغيل للجهاز.

Trusty وعمليات التنفيذ الأخرى

نظام التشغيل Trusty هو نظام تشغيل موثوق ومفتوح المصدر من Google لبيئات التنفيذ الموثوقة (TEE)، ويتضمّن تنفيذًا معتمَدًا لـ Gatekeeper. ومع ذلك، يمكن لأي نظام تشغيل لبيئة تنفيذ موثوقة (TEE) تنفيذ Gatekeeper طالما أنّ بيئة التنفيذ الموثوقة (TEE) يمكنها الوصول إلى مفتاح مستند إلى الأجهزة وساعة رتيبة وآمنة تعمل في وضع التعليق.

يستخدم Trusty نظام التواصل البيني للعمليات (IPC) لنقل المفتاح السري المشترك مباشرةً بين KeyMint (المعروف سابقًا باسم Keymaster) وتنفيذ Trusty لـ Gatekeeper (Trusty Gatekeeper). يُستخدم هذا المفتاح السري المشترك لتوقيع رموز AuthToken التي يتم إرسالها إلى Keystore لتقديم إثباتات التحقّق من كلمة المرور. يطلب Trusty Gatekeeper المفتاح من KeyMint في كل مرة يتم استخدامه، ولا يحفظ القيمة أو يخزّنها مؤقتًا. يمكن لعمليات التنفيذ مشاركة هذا السر بأي طريقة لا تعرّض الأمان للخطر.

يتم اشتقاق مفتاح HMAC المستخدَم لتسجيل كلمات المرور والتحقّق منها وحفظه في Gatekeeper فقط.

يوفر Android تنفيذًا عامًا لـ Gatekeeper بلغة C++ لا يتطلب سوى إضافة إجراءات روتينية خاصة بالجهاز حتى يكتمل، ويستند تنفيذ Trusty إلى هذا التنفيذ. لتنفيذ Gatekeeper لبيئة تنفيذ موثوقة (TEE) باستخدام رمز خاص بالجهاز لبيئة التنفيذ الموثوقة (TEE)، يُرجى الرجوع إلى الدوال والتعليقات في system/gatekeeper/include/gatekeeper/gatekeeper.h. تشمل المسؤوليات الأساسية لعملية التنفيذ المتوافقة ما يلي:

• الالتزام بطبقة التجريد للأجهزة IGatekeeper.
• يجب تنسيق رموز المصادقة المعروضة وفقًا لمواصفات HardwareAuthToken (الموضّحة في المصادقة).
• يجب أن يكون Gatekeeper لبيئة التنفيذ الموثوقة (TEE) قادرًا على مشاركة مفتاح HMAC مع KeyMint، إما من خلال طلب المفتاح من خلال نظام اتصال بين العمليات (IPC) لبيئة التنفيذ الموثوقة (TEE) عند الطلب أو الاحتفاظ بنسخة مؤقتة صالحة من القيمة في جميع الأوقات.

معرّفات المستخدمين الآمنة (SIDs)

معرّف المستخدم الآمن (SID) هو تمثيل للمستخدم في بيئة التنفيذ الموثوقة (TEE) (بدون اتصال قوي بمعرّف مستخدم Android). يتم إنشاء معرّف المستخدم الآمن (SID) باستخدام مولّد أرقام عشوائية زائفة (PRNG) مشفّر كلما سجّل المستخدم كلمة مرور جديدة بدون تقديم كلمة مرور سابقة. يُعرف ذلك باسم إعادة التسجيل غير الموثوق بها ولا يحدث عادةً إلا عندما يضبط المستخدم كلمة مرور أو نمطًا لأول مرة.

تحدث عملية إعادة التسجيل الموثوق بها عندما يقدّم المستخدم كلمة مرور سابقة صالحة، مثل تغيير كلمة المرور. في هذه الحالة، تتم عملية نقل معرّف المستخدم الآمن (SID) إلى مقبض كلمة المرور الجديدة، ما يحافظ على المفاتيح المرتبطة به.

يتم تضمين معرّف المستخدم الآمن (SID) في مصادقة HMAC مع كلمة المرور في مقبض كلمة المرور عند تسجيل كلمة المرور.

يتم تضمين معرّفات المستخدمين الآمنة (SIDs) في HardwareAuthToken الذي تعرضه الدالة verify() ، وترتبط بجميع مفاتيح Keystore المرتبطة بالمصادقة (للحصول على تفاصيل حول تنسيق HardwareAuthToken وKeystore، يُرجى الاطّلاع على المصادقة).

يُرجى العِلم أنّه بما أنّ طلبًا غير موثوق به للدالة enroll() يغيّر معرّف المستخدم الآمن (SID)، فإنّ الطلب يجعل المفاتيح المرتبطة بكلمة المرور هذه غير صالحة. يمكن للمهاجمين تغيير كلمة مرور الجهاز إذا كانوا يتحكّمون في نظام التشغيل Android، ولكنهم يدمّرون المفاتيح الحساسة المحمية على مستوى الجذر في هذه العملية.

الحدّ من عدد الطلبات

يجب أن يكون Gatekeeper قادرًا على الحدّ بشكل آمن من محاولات القوة الغاشمة على بيانات اعتماد المستخدم. كما هو موضّح في GatekeeperVerifyResponse.aidl، تتيح طبقة التجريد للأجهزة (HAL) عرض مهلة بالملّي ثانية. تُعلم المهلة العميل بعدم الاتصال بـ Gatekeeper مرة أخرى إلا بعد انتهاء المهلة. يجب ألا يعالج Gatekeeper الطلبات إذا كانت هناك مهلة معلّقة.

يجب أن يكتب Gatekeeper عدّادًا للفشل قبل التحقّق من كلمة مرور المستخدم. إذا نجحت عملية التحقّق من كلمة المرور، يجب محو عدّاد الفشل. يمنع ذلك الهجمات التي تمنع الحدّ من عدد المحاولات من خلال إيقاف وحدة MMC المضمّنة (eMMC) بعد إصدار طلب verify. تتحقّق الدالة enroll أيضًا من كلمة مرور المستخدم (إذا تم تقديمها)، ويجب الحدّ من عدد محاولاتها بالطريقة نفسها.

إذا كان الجهاز يتيح ذلك، يُنصح بشدة بكتابة عدّاد الفشل في وحدة تخزين آمنة. إذا كان الجهاز لا يتيح التشفير المستند إلى الملفات، أو إذا كانت وحدة التخزين الآمنة بطيئة جدًا، يمكن لعمليات التنفيذ استخدام Replay Protected Memory Block (RPMB) مباشرةً.