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

يُجري نظام 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 واجهة HAL IGatekeeper للتفاعل مع 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) كلما سجّل المستخدم كلمة مرور جديدة بدون تقديم كلمة مرور سابقة. يُعرف ذلك باسم إعادة التسجيل غير الموثوق بها، ولا يحدث عادةً إلا عندما يضبط المستخدم كلمة مرور أو نقشًا لأول مرة.

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

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

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

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

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

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

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

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