Authentication

يتضمّن Android مفهوم مصادقة المستخدمين الذي يُستخدَم لفتح قفل الجهاز وللسماح بالوصول إلى مفاتيح التشفير. ويشمل ذلك المكونات التالية:

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

يرتبط كل مكوّن من هذه المكوّنات بالمورّد، ولكن يجب أن يستوفي تنفيذ المورّد مواصفات واجهة Hardware Abstraction Layer (HAL) ، وأن يجتاز اختبارات مجموعة أدوات اختبار المورّد (VTS) المقابلة.

تنقسم عمليات التنفيذ التي يجريها المورّدون عادةً أيضًا إلى جزأين، يتم ربطهما بآلية تواصل خاصة بالمورّد :

• يتم تشغيل خدمة HAL كعملية لنظام Android، وتتلقّى طلبات Binder من نظام Android.
• يتم تشغيل التطبيق الموثوق (TA) في البيئة الآمنة، وينفّذ العمليات الآمنة الفعلية.

التسجيل

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

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

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

المصادقة

يوضِّح هذا القسم عملية مصادقة نموذجية، والتي تتضمّن تفاعلات بين مكوّنات متعدّدة في كلّ من Android والبيئة المؤمّنة. تجدر الإشارة إلى أنّ جميع المكوّنات الآمنة تشترك في مفتاح HMAC سري (لكل عملية تمهيد) تستخدمه للمصادقة على رسائل بعضها البعض.

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

الشكل 1: مسار المصادقة

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

لا تتطلّب عملية المصادقة تواصلًا مباشرًا بين وحدات التحكّم في الوصول (TA) في البيئة الآمنة: يتم نقل AuthTokens من وحدة التحكّم في الوصول (TA) الخاصة بالمصادقة إلى خدمةkeystore2 في Android، والتي بدورها ترسلها إلى وحدة التحكّم في الوصول (TA) الخاصة بتطبيق KeyMint. ويسمح ذلك أيضًا لخدمة keystore2 برفض الطلبات التي من المؤكد أنّها ستتعذّر إكمالها، لأنّها على دراية بـ AuthTokens المتاحة في النظام، ما يجنب إجراء عملية تبادل بيانات بين العمليات (IPC) قد تكون باهظة التكلفة في TEE.

تنسيق AuthToken

يتم تحديد تنسيق AuthToken من خلال مواصفات AIDL في HardwareAuthToken.aidl.

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

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

هناك طريقتان شائعتان يحصل من خلالهما خبراء الدعم الفني على إذن الوصول إلى مفتاح HMAC المشترَك هذا:

• اتفاقية المفتاح السري المشترَك: تُنفِّذ خدمة keystore2 بروتوكولًا متعدد الاتجاهات لاتفاقية المفتاح عند بدء تشغيل الجهاز، ما يسمح بإنشاء مفتاح HMAC بأمان بين جهات إدارة الاعتماد المشارِكة. ومع ذلك، يجب أن يتمكن خبراء الدعم المشاركون من الوصول إلى مفتاح سري مشترك مشترَك مسبقًا.
• الوصول المباشر: يمكن للعمليات التي تُجري عمليات معالجة داخلية في بيئة آمنة نفسها استخدام آلية داخلية للتواصل بين العمليات (تعتمد على النظام الأساسي) لمشاركة مفتاح HMAC.

في كلتا الحالتَين، يجب عدم إتاحة مفتاح HMAC خارج وحدة TEE.

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