Authentication

يستخدم نظام التشغيل Android مفهوم مفاتيح التشفير التي يتم التحكّم فيها من خلال مصادقة المستخدمين، ويتطلب ذلك المكونات التالية:

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

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

التسجيل

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

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

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

المصادقة

بعد أن يُعدّ المستخدم بيانات اعتماد ويتلقّى رقم تعريف مستخدم، يمكنه بدء عملية مصادقة تبدأ عندما يقدّم المستخدم رقم تعريف شخصي أو نقشًا أو كلمة مرور أو بصمة إصبع. تشترك جميع مكوّنات TEE في مفتاح سري تستخدمه هذه المكوّنات لمصادقة رسائل بعضها البعض.

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

تنسيق AuthToken

لضمان مشاركة الرموز المميّزة والتوافق مع جميع اللغات والمكوّنات، описан تنسيق AuthToken في hw_auth_token.h. التنسيق هو بروتوكول تسلسل بسيط يحتوي على حقول بحجم ثابت.

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

مسار تشغيل الجهاز

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

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

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

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