حارس البوابات

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

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

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

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

• gatekeeperd (برنامج Gatekeeper الخفي) خدمة ربط C++ تحتوي على منطق لا يعتمد على النظام الأساسي ومتوافقة مع واجهة Java GateKeeperService
• طبقة تجريد الأجهزة (HAL) في برنامج Gatekeeper واجهة HAL في hardware/libhardware/include/hardware/gatekeeper.h، والوحدة التنفيذية
• Gatekeeper (بيئة تنفيذ موثوقة): هو العنصر المقابل لبيئة التنفيذ الموثوقة في gatekeeperd. تنفيذ Gatekeeper المستنِد إلى بيئة التنفيذ الموثوقة

يتطلّب تطبيق Gatekeeper تنفيذ HAL لتطبيق Gatekeeper (وتحديدًا الدوالّ الواردة في hardware/libhardware/include/hardware/gatekeeper.h) ومكوّن Gatekeeper المخصّص لوحدة TEE (استنادًا جزئيًا إلى ملف الرأس system/gatekeeper/include/gatekeeper/gatekeeper.h الذي يحتوي على دوالّ افتراضية خالصة لإنشاء المفاتيح أو الوصول إليها وحساب التوقيعات).

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

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

يمنح الخادم الدائم gatekeeperd واجهات برمجة تطبيقات إطار عمل Android إذن الوصول إلى HAL، ويشارك في إعداد تقارير عن عمليات مصادقة الجهاز في ملف تخزين المفاتيح. يتم تشغيل برنامج gatekeeperd الخفي في عملية خاصة به وهو منفصل عن خادم النظام.

تنفيذ HAL

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

يجب أن تُنفِّذ عمليات تنفيذملف الرأس hardware/libhardware/include/hardware/gatekeeper.h دالتَي enroll وverify:

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

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

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

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

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

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

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

• الالتزام بواجهة برمجة التطبيقات HAL الخاصة ببوابة الربط
• يجب تنسيق AuthTokens المُرسَلة وفقًا لمواصفات AuthToken (الموضَّحة في المصادقة).
• يجب أن يكون حارس TEE قادرًا على مشاركة مفتاح HMAC مع Keymaster، إما عن طريق طلب المفتاح من خلال واجهة برمجة تطبيقات TEE IPC عند الطلب أو الاحتفاظ بملف cache صالح للقيمة في جميع الأوقات.

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

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

يتم استخدام معيار HMAC مع معرّف المستخدم وكلمة المرور في معرّف كلمة المرور عند تسجيل كلمة المرور.

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

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

يجب أن يكون بإمكان GateKeeper الحدّ من محاولات القوة الغاشمة على بيانات اعتماد المستخدِم بأمان. كما هو موضّح في المثال التالي: hardware/libhardware/include/hardware/gatekeeper.h، يقدّم HAL قيمة مهلة بالمللي ثانية. يُعلم وقت الاستراحة العميل بعدم الاتصال بخدمة GateKeeper مرة أخرى إلا بعد انقضاء وقت الاستراحة، ويجب ألا تعالج خدمة GateKeeper الطلبات إذا كان هناك وقت استراحة معلّق.

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

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