حارس البوابة

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

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

بنيان

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

• gatekeeperd (حارس البوابة الخفي). خدمة ربط C++ تحتوي على منطق مستقل عن النظام الأساسي وتتوافق مع واجهة GateKeeperService Java.
• طبقة تجريد أجهزة حارس البوابة (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 بعد ذلك بتقديم طلب يصل إلى نظيره (حارس البوابة) في TEE:

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

تنفيذ هال

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

يستخدم Trusty نظام IPC داخلي لتوصيل سر مشترك مباشرة بين Keymaster وتنفيذ Trusty لبرنامج Gatekeeper ( Trusty 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)

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

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

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

طلب اختناق

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

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

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