تلتزم Google بتعزيز المساواة العرقية للمجتمعات السوداء. أنظر كيف.
ترجمت واجهة Cloud Translation API‏ هذه الصفحة.
Switch to English

برنامج حماية البوابة

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

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

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

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

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

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

تنفيذ HAL

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

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

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

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

تطبيقات موثوقة وتنفيذية أخرى

و مضمونة نظام التشغيل هو مصدر غوغل مفتوحة الوثوق OS لبيئات TEE ويحتوي على تنفيذ المعتمد من البواب. ومع ذلك ، يمكنك استخدام أي نظام تشغيل 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)

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

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

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

طلب التحكم

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

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

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