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

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

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

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

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

• ‫gatekeeperd (الخادم الدائم لنظام التحكّم في الوصول) - خدمة Binder لنظام التشغيل C++ في Android تحتوي على منطق مستقل عن النظام الأساسي ينفذ واجهة IGateKeeperService AIDL، استنادًا إلى تنفيذ أساسي خاص بالمورّد لملف IGatekeeper.
• خدمة طبقة تجريد الأجهزة (HAL) في بوابة العبور: هي عملية تنفيذ خاصة بالمورّد لسمة واجهة AIDL في IGatekeeper. تعمل خدمة HAL هذه في Android، ولكن يجب تنفيذ الوظيفة الأساسية لـ Gatekeeper في بيئة آمنة، لذا يتم عادةً التواصل مع وحدة التحكّم في الوصول (TA) في Gatekeeper.
• تطبيق موثوق للحارس (TA): هو عملية تنفيذ خاصة بالمورّد تتم في بيئة التنفيذ الموثوق (TEE) وتعمل على إثبات صحة كلمة المرور أو النمط.

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

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

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

تنفيذ HAL

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

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

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

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

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

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

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

يتم اشتقاق مفتاح HMAC المستخدَم لتسجيل كلمات المرور وإثبات صحتها والاحتفاظ به فقط في Gatekeeper.

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

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

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

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

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

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

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

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

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

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

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

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