المصادقة

يستخدم 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. يوفر المستخدم طريقة مصادقة وتقوم الخدمة المرتبطة بتقديم طلب إلى البرنامج الخفي المرتبط.
   • بالنسبة إلى رقم التعريف الشخصي أو النمط أو كلمة المرور ، تقدم 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 . التنسيق عبارة عن بروتوكول تسلسل بسيط بحقول ذات حجم ثابت.

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

في كل عملية تمهيد للجهاز ، يجب إنشاء مفتاح 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.