يستخدم Android مفهوم مفاتيح التشفير ذات بوابة مصادقة المستخدم والتي تتطلب المكونات التالية:
- تخزين مفتاح التشفير ومزود الخدمة. يقوم بتخزين مفاتيح التشفير ويوفر إجراءات تشفير قياسية فوق تلك المفاتيح. يدعم Android Keystore وKeymaster المدعومين بالأجهزة لخدمات التشفير، بما في ذلك التشفير المدعوم بالأجهزة لتخزين المفاتيح والذي قد يتضمن بيئة تنفيذ موثوقة (TEE) أو عنصر آمن (SE)، مثل Strongbox.
- المصادقون المستخدم. تشهد على وجود المستخدم و/أو المصادقة الناجحة. يدعم Android برنامج Gatekeeper لمصادقة رقم التعريف الشخصي/النمط/كلمة المرور وبصمة الإصبع لمصادقة بصمة الإصبع. يمكن للأجهزة التي تعمل بنظام Android 9 والإصدارات الأحدث استخدام
BiometricPromptكنقطة تكامل واحدة لبصمات الأصابع والقياسات الحيوية الإضافية. تقوم هذه المكونات بتوصيل حالة المصادقة الخاصة بها مع خدمة تخزين المفاتيح من خلال قناة تمت مصادقتها. (يتم أيضًا دعم نظام Android Keystore على مستوى إطار العمل بواسطة خدمة keystore.)
تعمل مكونات Gatekeeper وبصمة الإصبع والقياسات الحيوية مع Keystore والمكونات الأخرى لدعم استخدام رموز المصادقة المدعومة بالأجهزة (AuthTokens).
التسجيل
عند التشغيل الأول للجهاز بعد إعادة ضبط المصنع، يكون جميع المصادقين مستعدين لتلقي تسجيلات بيانات الاعتماد من المستخدم. يجب على المستخدم في البداية تسجيل رقم التعريف الشخصي/النمط/كلمة المرور في برنامج Gatekeeper. يقوم هذا التسجيل الأولي بإنشاء معرف آمن للمستخدم (SID) 64 بت يتم إنشاؤه عشوائيًا والذي يعمل كمعرف للمستخدم وكرمز ربط لمواد التشفير الخاصة بالمستخدم. يرتبط معرف SID الخاص بالمستخدم بشكل مشفر بكلمة مرور المستخدم؛ تؤدي المصادقة الناجحة لبرنامج Gatekeeper إلى ظهور AuthTokens التي تحتوي على معرف الأمان (SID) الخاص بالمستخدم لكلمة المرور هذه.
يجب على المستخدم الذي يريد تغيير بيانات الاعتماد تقديم بيانات اعتماد موجودة. إذا تم التحقق من بيانات الاعتماد الموجودة بنجاح، فسيتم نقل معرف SID الخاص بالمستخدم المرتبط ببيانات الاعتماد الحالية إلى بيانات الاعتماد الجديدة، مما يمكّن المستخدم من الاستمرار في الوصول إلى المفاتيح بعد تغيير بيانات الاعتماد. إذا لم يقدم المستخدم بيانات اعتماد موجودة، فسيتم تسجيل بيانات الاعتماد الجديدة باستخدام معرف مستخدم عشوائي بالكامل. يمكن للمستخدم الوصول إلى الجهاز، ولكن المفاتيح التي تم إنشاؤها ضمن معرف الأمان (SID) الخاص بالمستخدم القديم ستفقد نهائيًا. يُعرف هذا بالتسجيل غير الموثوق به .
في ظل الظروف العادية، لا يسمح إطار عمل Android بالتسجيل غير الموثوق به، لذلك لن يتمكن معظم المستخدمين من رؤية هذه الوظيفة على الإطلاق. ومع ذلك، قد تؤدي عمليات إعادة تعيين كلمة المرور القسرية، إما بواسطة مسؤول الجهاز أو أحد المهاجمين، إلى حدوث ذلك.
المصادقة
بعد قيام المستخدم بإعداد بيانات الاعتماد وتلقي معرف SID الخاص بالمستخدم، يمكنه بدء المصادقة، والتي تبدأ عندما يقدم المستخدم رقم PIN أو النمط أو كلمة المرور أو بصمة الإصبع. تشترك جميع مكونات TEE في المفتاح السري الذي تستخدمه لمصادقة رسائل بعضها البعض.
- يوفر المستخدم طريقة مصادقة وتقوم الخدمة المرتبطة بتقديم طلب إلى البرنامج الخفي المرتبط.
- بالنسبة لرقم التعريف الشخصي أو النمط أو كلمة المرور، تقوم
LockSettingsServiceبتقديم طلب إلىgatekeeperd. - تعتمد تدفقات المصادقة المستندة إلى القياسات الحيوية على إصدار Android. على الأجهزة التي تعمل بنظام التشغيل Android 8.x والإصدارات الأقدم، تقدم
FingerprintServiceطلبًا لأخذfingerprintd). على الأجهزة التي تعمل بنظام Android 9 والإصدارات الأحدث، يقدمBiometricPromptطلبًا إلى برنامج القياسات الحيوية المناسب (على سبيل المثال،fingerprintdلبصمات الأصابع أوfacedللوجه) باستخدام فئةBiometric Managerالمناسبة، مثلFingerprintManagerأوFaceManager. بغض النظر عن الإصدار، تحدث المصادقة البيومترية بشكل غير متزامن بعد إرسال الطلب.
- بالنسبة لرقم التعريف الشخصي أو النمط أو كلمة المرور، تقوم
- يرسل البرنامج الخفي البيانات إلى نظيره، الذي يقوم بإنشاء AuthToken:
- بالنسبة لمصادقة رقم التعريف الشخصي/النمط/كلمة المرور، يرسل
gatekeeperdرقم التعريف الشخصي أو النمط أو تجزئة كلمة المرور إلى برنامج حماية البوابة في TEE. إذا نجحت المصادقة في TEE، يرسل Gatekeeper في TEE AuthToken الذي يحتوي على SID الخاص بالمستخدم المقابل (الموقّع باستخدام مفتاح AuthToken HMAC) إلى نظيره في نظام التشغيل Android. - للمصادقة على بصمة الإصبع، تستمع
fingerprintdإلى أحداث بصمة الإصبع وترسل البيانات إلى Fingerprint في TEE. إذا نجحت المصادقة في TEE، فإن Fingerprint في TEE يرسل AuthToken (موقّع باستخدام مفتاح AuthToken HMAC) إلى نظيره في نظام التشغيل Android. - بالنسبة للمصادقة البيومترية الأخرى، يستمع البرنامج الخفي البيومتري المناسب لحدث البيومترية ويرسله إلى مكون TEE البيومتري المناسب.
- بالنسبة لمصادقة رقم التعريف الشخصي/النمط/كلمة المرور، يرسل
- يتلقى البرنامج الخفي AuthToken موقعًا ويمرره إلى خدمة تخزين المفاتيح من خلال امتداد لواجهة Binder الخاصة بخدمة تخزين المفاتيح. (يقوم
gatekeeperdأيضًا بإعلام خدمة تخزين المفاتيح عند إعادة قفل الجهاز وعند تغيير كلمة مرور الجهاز.) - تقوم خدمة تخزين المفاتيح بتمرير AuthTokens إلى Keymaster والتحقق منها باستخدام المفتاح المشترك مع Gatekeeper ومكون TEE البيومتري المدعوم. يثق Keymaster في الطابع الزمني الموجود في الرمز المميز باعتباره آخر وقت للمصادقة ويبني قرار إصدار المفتاح (للسماح للتطبيق باستخدام المفتاح) على الطابع الزمني.
تنسيق AuthToken
لضمان مشاركة الرمز المميز والتوافق عبر اللغات والمكونات، تم وصف تنسيق AuthToken في hw_auth_token.h . التنسيق عبارة عن بروتوكول تسلسلي بسيط مع حقول ذات حجم ثابت.
| مجال | يكتب | مطلوب | وصف |
|---|---|---|---|
| إصدار AuthToken | 1 بايت | نعم | علامة المجموعة لجميع الحقول أدناه. |
| تحدي | عدد صحيح غير موقّع 64 بت | لا | عدد صحيح عشوائي لمنع هجمات الإعادة. عادةً ما يكون معرف عملية التشفير المطلوبة. يُستخدم حاليًا من خلال تراخيص بصمات الأصابع للمعاملات. إذا كان AuthToken موجودًا، فسيكون صالحًا فقط لعمليات التشفير التي تحتوي على نفس التحدي. |
| معرف معرف المستخدم (SID) للمستخدم | عدد صحيح غير موقّع 64 بت | نعم | معرف المستخدم غير المتكرر مرتبط بشكل مشفر بجميع المفاتيح المرتبطة بمصادقة الجهاز. لمزيد من التفاصيل، راجع حارس البوابة . |
| معرف المصادقة (ASID) | عدد صحيح غير موقّع 64 بت في ترتيب الشبكة | لا | المعرف المستخدم للربط بسياسة مصادقة محددة. يتمتع جميع الموثقين بقيمتهم الخاصة لـ ASID والتي يمكنهم تغييرها وفقًا لمتطلباتهم الخاصة. |
| نوع المصادقة | عدد صحيح غير موقّع 32 بت في ترتيب الشبكة | نعم |
|
| الطابع الزمني | عدد صحيح غير موقّع 64 بت في ترتيب الشبكة | نعم | الوقت (بالمللي ثانية) منذ آخر عملية تمهيد للنظام. |
| رمز المصادقة HMAC (SHA-256) | فقاعة 256 بت | نعم | تم استخدام مفتاح SHA-256 MAC لجميع الحقول باستثناء حقل HMAC. |
تدفق تمهيد الجهاز
في كل عملية تمهيد لجهاز، يجب إنشاء مفتاح AuthToken HMAC ومشاركته مع جميع مكونات TEE (Gatekeeper وKeymaster وصناديق القياسات الحيوية المدعومة). وبالتالي، لمزيد من الحماية ضد هجمات إعادة التشغيل، يجب إنشاء مفتاح HMAC بشكل عشوائي في كل مرة يتم فيها إعادة تشغيل الجهاز.
يعد بروتوكول مشاركة مفتاح HMAC هذا مع كافة المكونات إحدى ميزات التنفيذ المعتمدة على النظام الأساسي. يجب ألا يكون المفتاح متاحًا أبدًا خارج TEE. إذا كان نظام تشغيل TEE يفتقر إلى آلية الاتصال الداخلي بين العمليات (IPC) ويحتاج إلى نقل البيانات من خلال نظام تشغيل غير موثوق به، فيجب أن يتم النقل من خلال بروتوكول تبادل مفاتيح آمن.
يعد نظام التشغيل Trusty ، الذي يعمل بجوار Android، مثالاً على TEE، ولكن يمكن استخدام TEEs أخرى بدلاً من ذلك. يستخدم Trusty نظام IPC داخلي للتواصل مباشرة بين Keymaster وGatekeeper أو الثقة البيومترية المناسبة. يتم الاحتفاظ بمفتاح HMAC فقط في Keymaster؛ تطلب بصمة الإصبع وGatekeeper المفتاح من Keymaster لكل استخدام ولا تستمر القيمة أو تخزنها مؤقتًا.
نظرًا لأن بعض TEEs تفتقر إلى البنية الأساسية لـ IPC، فلا يحدث أي اتصال بين التطبيقات الصغيرة في TEE. يسمح هذا أيضًا لخدمة تخزين المفاتيح برفض الطلبات التي من المحتم أن تفشل بسرعة نظرًا لأنها تمتلك معرفة بجدول المصادقة في النظام، مما يوفر IPC قد يكون مكلفًا في TEE.