حارس البوابة

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

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

هندسة عامة

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

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

يتطلب برنامج Gatekeeper تنفيذ Gatekeeper HAL (على وجه التحديد الوظائف في 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 ، ويشارك في الإبلاغ عن مصادقات الجهاز إلى Keystore. يعمل برنامج gatekeeperd الخفي في العملية الخاصة به وهو منفصل عن خادم النظام.

تنفيذ HAL

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

يجب أن تنفذ تطبيقات ملف الرأس hardware/libhardware/include/hardware/gatekeeper.h وظائف enroll verify :

  • تأخذ وظيفة enroll blob لكلمة المرور ، وتوقعها ، وترجع التوقيع كمقبض. يجب أن تحتوي النقطة المرتجعة (من مكالمة enroll ) على البنية الموضحة في system/gatekeeper/include/gatekeeper/password_handle.h .
  • يجب أن تقارن وظيفة verify بين التوقيع الناتج عن كلمة المرور المقدمة والتأكد من مطابقتها لمقبض كلمة المرور المسجل.

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

موثوقة والتطبيقات الأخرى

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

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

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

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

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

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

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

يكون User SID مرتبطًا بـ HMAC جنبًا إلى جنب مع كلمة المرور في مقبض كلمة المرور عند تسجيل كلمة المرور.

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

طلب الاختناق

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

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

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