المصادقة

يستخدم Android مفهوم مفاتيح التشفير المصادقة على بوابات المستخدم والتي تتطلب المكونات التالية:

  • تخزين مفتاح التشفير ومزود الخدمة. يخزن مفاتيح التشفير ويوفر إجراءات تشفير قياسية فوق تلك المفاتيح. يدعم Android Keystore و Keymaster المدعومين من الأجهزة لخدمات التشفير ، بما في ذلك التشفير المدعوم بالأجهزة لتخزين المفاتيح التي قد تتضمن بيئة تنفيذ موثوقة (TEE) أو عنصر آمن (SE) ، مثل Strongbox.
  • المصادقون من المستخدم. يشهد على وجود المستخدم و / أو المصادقة الناجحة. يدعم Android Gatekeeper لمصادقة رقم التعريف الشخصي / النمط / كلمة المرور وبصمة الإصبع لمصادقة بصمات الأصابع. يمكن للأجهزة التي تعمل بنظام Android 9 والإصدارات الأحدث استخدام BiometricPrompt كنقطة تكامل واحدة لبصمات الأصابع والقياسات الحيوية الإضافية. تنقل هذه المكونات حالة المصادقة الخاصة بها مع خدمة keystore من خلال قناة مصادقة. ( نظام Android Keystore على مستوى إطار العمل مدعوم أيضًا بخدمة keystore.)

تعمل مكونات Gatekeeper و Fingerprint و Biometric مع Keystore والمكونات الأخرى لدعم استخدام رموز المصادقة المدعومة بالأجهزة (AuthTokens).

التسجيل

عند التشغيل الأول للجهاز بعد إعادة تعيين إعدادات المصنع ، يكون جميع المصدقين على استعداد لتلقي تسجيلات بيانات الاعتماد من المستخدم. يجب على المستخدم تسجيل رمز PIN / النمط / كلمة المرور مبدئيًا مع Gatekeeper. ينشئ هذا التسجيل الأولي معرفًا آمنًا للمستخدم (SID) يتم إنشاؤه عشوائيًا ، 64 بت والذي يعمل كمعرف للمستخدم وكرمز مميز ملزم لمواد التشفير الخاصة بالمستخدم. يرتبط SID هذا المستخدم بشكل مشفر بكلمة مرور المستخدم ؛ تؤدي المصادقات الناجحة إلى Gatekeeper إلى AuthTokens التي تحتوي على SID للمستخدم لكلمة المرور هذه.

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

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

المصادقة

بعد أن يقوم المستخدم بإعداد بيانات الاعتماد وتلقيه SID للمستخدم ، يمكنه بدء المصادقة ، والتي تبدأ عندما يقدم المستخدم رمز PIN أو النمط أو كلمة المرور أو بصمة الإصبع. تشترك جميع مكونات TEE في مفتاح سري يستخدمونه لمصادقة رسائل بعضهم البعض.

تدفق المصادقة
الشكل 1. تدفق المصادقة
  1. يوفر المستخدم طريقة مصادقة وتقوم الخدمة المرتبطة بتقديم طلب إلى البرنامج الخفي المرتبط.
    • بالنسبة إلى رقم التعريف الشخصي أو النمط أو كلمة المرور ، تقدم LockSettingsService طلبًا إلى gatekeeperd .
    • تعتمد تدفقات المصادقة المستندة إلى المقاييس الحيوية على إصدار Android. على الأجهزة التي تعمل بنظام Android 8.x والإصدارات الأقدم ، تقدم FingerprintService طلبًا fingerprintd ). على الأجهزة التي تعمل بنظام Android 9 والإصدارات الأحدث ، تقدم BiometricPrompt طلبًا إلى البرنامج الخفي للقياسات الحيوية المناسبة (على سبيل المثال ، fingerprintd لبصمات الأصابع أو faced للوجه) باستخدام فئة Biometric Manager المناسبة ، مثل FingerprintManager أو FaceManager . بغض النظر عن الإصدار ، تحدث المصادقة البيومترية بشكل غير متزامن بعد إرسال الطلب.
  2. يرسل البرنامج الخفي البيانات إلى نظيره ، مما يؤدي إلى إنشاء AuthToken:
    • لمصادقة رقم التعريف الشخصي / النمط / كلمة المرور ، يرسل برنامج حماية gatekeeperd رقم PIN أو النمط أو تجزئة كلمة المرور إلى Gatekeeper في TEE. إذا نجحت المصادقة في TEE ، فإن Gatekeeper في TEE يرسل AuthToken يحتوي على المستخدم المقابل SID (موقّع بمفتاح AuthToken HMAC) إلى نظيره في نظام التشغيل Android.
    • للمصادقة ببصمة الإصبع ، تستمع fingerprintd الإصبع لأحداث بصمات الأصابع وترسل البيانات إلى Fingerprint في TEE. إذا كانت المصادقة في TEE ناجحة ، فإن Fingerprint في TEE ترسل AuthToken (موقّعًا باستخدام مفتاح AuthToken HMAC) إلى نظيره في نظام التشغيل Android.
    • بالنسبة للمصادقة البيومترية الأخرى ، يستمع البرنامج الخفي للقياسات الحيوية المناسبة إلى حدث القياسات الحيوية ويرسله إلى مكون TEE المناسب.
  3. يتلقى البرنامج الخفي AuthToken موقعًا ويمرره إلى خدمة keystore من خلال امتداد لواجهة Binder الخاصة بخدمة مخزن المفاتيح. (يقوم برنامج حماية gatekeeperd أيضًا بإعلام خدمة تخزين المفاتيح عند إعادة توصيل الجهاز وعندما تتغير كلمة مرور الجهاز.)
  4. تقوم خدمة keystore بتمرير AuthTokens إلى Keymaster والتحقق منها باستخدام المفتاح المشترك مع Gatekeeper ومكون TEE المدعوم البيومتري. يثق Keymaster في الطابع الزمني في الرمز المميز باعتباره آخر وقت مصادقة ويؤسس قرار إصدار مفتاح (للسماح لتطبيق ما باستخدام المفتاح) على الطابع الزمني.

تنسيق AuthToken

لضمان مشاركة الرمز المميز والتوافق عبر اللغات والمكونات ، يتم وصف تنسيق AuthToken في hw_auth_token.h . التنسيق عبارة عن بروتوكول تسلسل بسيط بحقول ذات حجم ثابت.

مجال يكتب مطلوب وصف
نسخة أوثتوكين 1 بايت نعم علامة المجموعة لجميع الحقول أدناه.
تحدي 64 بت عدد صحيح بدون إشارة رقم عدد صحيح عشوائي لمنع هجمات الإعادة. عادة ما يكون معرّف عملية التشفير المطلوبة. تُستخدم حاليًا من خلال أذونات بصمة المعاملات. إن وجدت ، فإن AuthToken صالحًا فقط لعمليات التشفير التي تحتوي على نفس التحدي.
SID المستخدم 64 بت عدد صحيح بدون إشارة نعم معرف مستخدم غير متكرر مرتبط بشكل مشفر بجميع المفاتيح المرتبطة بمصادقة الجهاز. للحصول على التفاصيل ، راجع برنامج حماية البوابة .
معرف المصادقة (ASID) 64 بت عدد صحيح بدون إشارة بترتيب الشبكة رقم المعرف المستخدم للالتزام بسياسة مصادقة معينة. جميع المصدقين لديهم قيمة ASID الخاصة بهم والتي يمكنهم تغييرها وفقًا لمتطلباتهم الخاصة.
نوع المصدق 32 بت عدد صحيح بدون إشارة بترتيب الشبكة نعم
  • 0x00 هو برنامج حماية البوابة.
  • 0x01 هي بصمة الإصبع.
الطابع الزمني 64 بت عدد صحيح بدون إشارة بترتيب الشبكة نعم الوقت (بالملي ثانية) منذ آخر تمهيد للنظام.
AuthToken HMAC (SHA-256) 256 بت نعم مفتاح SHA-256 MAC لجميع الحقول باستثناء حقل HMAC.

تدفق تمهيد الجهاز

في كل عملية تمهيد للجهاز ، يجب إنشاء مفتاح AuthToken HMAC ومشاركته مع جميع مكونات TEE (Gatekeeper و Keymaster و Trustlets المقاييس الحيوية المدعومة). وبالتالي ، لمزيد من الحماية ضد هجمات إعادة التشغيل ، يجب إنشاء مفتاح HMAC بشكل عشوائي في كل مرة يتم فيها إعادة تشغيل الجهاز.

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

يعد نظام التشغيل Trusty ، الذي يعمل بجانب Android ، مثالاً على TEE ، ولكن يمكن استخدام TEEs الأخرى بدلاً من ذلك. تستخدم Trusty نظام IPC داخليًا للاتصال مباشرة بين Keymaster و Gatekeeper أو Trustlet البيومترية المناسبة. يتم الاحتفاظ بمفتاح HMAC فقط في Keymaster ؛ تطلب Fingerprint و Gatekeeper المفتاح من Keymaster لكل استخدام ولا تستمر في الاحتفاظ بالقيمة أو تخزينها مؤقتًا.

نظرًا لأن بعض TEEs تفتقر إلى البنية التحتية IPC ، فلا يحدث اتصال بين التطبيقات الصغيرة في TEE. يسمح هذا أيضًا لخدمة keystore برفض الطلبات التي لا بد أن تفشل بسرعة نظرًا لأن لديها معرفة بجدول المصادقة في النظام ، مما يوفر IPC الذي يحتمل أن يكون مكلفًا في TEE.