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

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

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

البنية

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

• ‫gatekeeperd (برنامج Gatekeeper الخفي) هو خدمة C++ Binder في نظام Android تحتوي على منطق مستقل عن النظام الأساسي ينفّذ واجهة IGateKeeperService AIDL، استنادًا إلى تنفيذ أساسي خاص بالمورّد لـ IGatekeeper.
• خدمة Gatekeeper HAL: هي تنفيذ خاص بالمورّد لواجهة 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 HAL للتفاعل مع Gatekeeper TA الأساسي من أجل مصادقة كلمة المرور. يجب أن يكون تنفيذ Gatekeeper TA قادرًا على توقيع (تسجيل) البيانات الثنائية الكبيرة والتحقّق منها. من المتوقّع أن تلتزم جميع عمليات التنفيذ بالتنسيق العادي لرمز المصادقة المميز (HardwareAuthToken) الذي يتم إنشاؤه عند إثبات صحة كلمة المرور بنجاح في كل مرة. للحصول على تفاصيل حول محتوى HardwareAuthToken ودلالته، يُرجى الاطّلاع على تعريف HardwareAuthToken.aidl.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

تقييد الطلبات

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

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

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