يستخدم Android مفهوم أدوات مصادقة المستخدمين التي تُستخدم لفتح قفل الجهاز والتحكّم في الوصول إلى مفاتيح التشفير. يتضمن ذلك المكونات التالية:
- مقدّم خدمة تخزين مفاتيح التشفير يوفّر ملف تخزين مفاتيح Android خدمات تشفير مستنِدة إلى الأجهزة للتطبيقات. يستند نظام تخزين مفاتيح Android على مستوى إطار العمل إلى خدمة نظام
keystore2. ويستند هذا بدوره إلى عملية تنفيذ KeyMint (المعروف سابقًا باسم Keymaster) الأساسية الخاصة بالمورّد والتي تضمن عدم إمكانية الوصول إلى مواد المفاتيح إلا في بيئة آمنة مستندة إلى الأجهزة، مثل بيئة التنفيذ الموثوقة (TEE) أو عنصر آمن (SE)، مثل StrongBox. - أدوات مصادقة المستخدمين: إثبات نجاح مصادقة المستخدم
يتيح Android استخدام مكوّنات المصادقة التالية:
- Gatekeeper لمصادقة رقم التعريف الشخصي أو النقش أو كلمة المرور في بيئة التنفيذ الموثوقة (TEE)
- (اختياري) Weaver للمصادقة باستخدام رقم التعريف الشخصي أو النقش أو كلمة المرور في عنصر آمن
- بصمة الإصبع للمصادقة ببصمة الإصبع
- طرق المصادقة الأخرى بالمقاييس الحيوية يمكن للأجهزة التي تعمل بنظام التشغيل Android 9 أو إصدار أحدث استخدام
BiometricPromptكنقطة دمج واحدة لبصمة الإصبع والمقاييس الحيوية الإضافية.
keystore2بشأن حالة المصادقة من خلال استخدام رموز المصادقة المميّزة (AuthTokens) المستندة إلى الأجهزة.
يختلف كل مكوّن من هذه المكوّنات حسب المورّد، ولكن يجب أن يستوفي تنفيذ المورّد مواصفات واجهة طبقة تجريد الأجهزة (HAL) وأن يجتاز اختبارات حزمة اختبار المورّد (VTS) المقابلة.
تنقسم عمليات التنفيذ التي يجريها المورّد عادةً إلى جزأين، يرتبطان ببعضهما من خلال آلية تواصل خاصة بالمورّد :
- تعمل خدمة HAL كعملية في نظام Android، وتتلقّى طلبات Binder من نظام Android.
- يتم تشغيل تطبيق موثوق (TA) في البيئة الآمنة، لتنفيذ العمليات الآمنة الفعلية.
التسجيل
عند تشغيل الجهاز لأول مرة بعد إعادة الضبط على الإعدادات الأصلية، يتم إعداد جميع أدوات المصادقة لتلقّي عمليات تسجيل بيانات الاعتماد من المستخدم. يجب أن يسجّل المستخدم في البداية رقم تعريف شخصي أو نقشًا أو كلمة مرور باستخدام Gatekeeper (أو Weaver، إذا كان متاحًا). تؤدي عملية التسجيل الأولية هذه إلى إنشاء معرّف آمن للمستخدم (SID) مكوّن من 64 بت يتم إنشاؤه عشوائيًا، ويعمل كمعرّف للمستخدم ورمز مميّز ملزم لمواد التشفير الخاصة بالمستخدم. يرتبط معرّف SID الخاص بالمستخدم تشفيريًا بكلمة مرور المستخدم، وتؤدي عمليات المصادقة الناجحة في Gatekeeper إلى إنشاء رموز AuthTokens التي تحتوي على معرّف SID الخاص بالمستخدم لكلمة المرور هذه.
على المستخدم الذي يريد تغيير بيانات اعتماد حالية تقديم بيانات الاعتماد هذه. إذا تم التحقّق من بيانات الاعتماد الحالية بنجاح، يتم نقل معرّف SID الخاص بالمستخدم والمرتبط ببيانات الاعتماد الحالية إلى بيانات الاعتماد الجديدة، ما يتيح للمستخدم مواصلة الوصول إلى المفاتيح بعد تغيير بيانات الاعتماد.
في بعض الحالات، يمكن لمشرف الجهاز إجراء تسجيل غير موثوق به لتسجيل بيانات اعتماد جديدة بدون تقديم بيانات اعتماد حالية. يسمح هذا للمستخدم بالوصول إلى الجهاز، ولكن يتم فقدان المفاتيح التي تم إنشاؤها ضمن معرّف الأمان القديم للمستخدم بشكل دائم.
المصادقة
يصف هذا القسم عملية مصادقة نموذجية تتضمن تفاعلات بين مكونات متعددة في كل من Android والبيئة الآمنة. يُرجى العِلم أنّ جميع المكوّنات الآمنة تشارك مفتاح HMAC سريًا (لكل عملية تشغيل) تستخدمه لمصادقة رسائل بعضها البعض.
بعد أن يضبط المستخدم بيانات الاعتماد ويتم منحه معرّف أمان، يمكنه
بدء المصادقة التي تبدأ عندما يقدّم المستخدم رقم تعريف شخصي أو نقشًا أو
كلمة مرور أو بصمة إصبع أو مقياسًا حيويًا قويًا آخر.
الشكل 1: عملية المصادقة
- يقدّم المستخدم طريقة مصادقة، وتُرسل الخدمة المرتبطة بها طلبًا إلى خدمة HAL.
- بالنسبة إلى رقم التعريف الشخصي أو النقش أو كلمة المرور، يرسل تطبيق "
LockSettingsService" طلبًا إلى "gatekeeperd". - تعتمد عمليات المصادقة المستندة إلى المقاييس الحيوية على إصدار Android.
على الأجهزة التي تعمل بالإصدار Android 8.x والإصدارات الأقدم، يرسل
FingerprintServiceطلبًا إلىfingerprintd. وعلى الأجهزة التي تعمل بالإصدار Android 9 والإصدارات الأحدث، يرسلBiometricPromptطلبًا إلى برنامج الخلفية المناسب للمقاييس الحيوية (على سبيل المثال،fingerprintdلبصمات الأصابع أوfacedللوجه) باستخدام فئةBiometricManagerالمناسبة، مثلFingerprintManagerأوFaceManager. بغض النظر عن الإصدار، تتم المصادقة بالمقاييس الحيوية بشكل غير متزامن بعد إرسال الطلب.
- بالنسبة إلى رقم التعريف الشخصي أو النقش أو كلمة المرور، يرسل تطبيق "
- ترسل خدمة HAL البيانات إلى وكيل الثقة المقابل لها، والذي ينشئ
AuthToken:
- للمصادقة باستخدام رقم التعريف الشخصي أو النقش أو كلمة المرور، يرسل
gatekeeperdتجزئة رقم التعريف الشخصي أو النقش أو كلمة المرور إلى Gatekeeper TA في بيئة التنفيذ الموثوق بها (TEE)، من خلال خدمة Gatekeeper HAL. إذا نجحت المصادقة في بيئة التنفيذ الموثوقة (TEE)، يُصدر Gatekeeper TA رمز AuthToken يحتوي على معرّف SID للمستخدم المقابل (موقَّع باستخدام مفتاح HMAC المشترَك). - بالنسبة إلى المصادقة ببصمة الإصبع، يستمع
fingerprintdإلى أحداث بصمة الإصبع ويرسل البيانات إلى تطبيق TA لبصمة الإصبع في بيئة التنفيذ الموثوقة (TEE) من خلال طبقة HAL لبصمة الإصبع. في حال نجاح المصادقة في بيئة التنفيذ الموثوق بها (TEE)، يُصدر التطبيق الموثوق به (TA) لبصمة الإصبع رمز AuthToken (موقَّع باستخدام مفتاح AuthToken HMAC). - بالنسبة إلى المصادقة بالمقاييس الحيوية الأخرى، تستمع العملية الخلفية المناسبة للمقاييس الحيوية إلى حدث المقاييس الحيوية وترسله إلى خدمة HAL المناسبة للمقاييس الحيوية والتطبيق الموثوق به.
- للمصادقة باستخدام رقم التعريف الشخصي أو النقش أو كلمة المرور، يرسل
- يتم تمرير رمز AuthToken الموقَّع الناتج إلى خدمة نظام
keystore2من خلال واجهة Binder. - تُرفق خدمة
keystore2رموز AuthToken بطلب KeyMint (المعروف سابقًا باسم Keymaster) لإجراء عمليات التشفير. وتمرّر خدمة KeyMint HAL هذه الرموز المميّزة إلى KeyMint TA، الذي يتحقّق منها باستخدام مفتاح HMAC المشترَك مع Gatekeeper ومكوّنات TEE المتوافقة مع المقاييس الحيوية. يثق KeyMint في الطابع الزمني في الرمز المميّز باعتباره آخر وقت للمصادقة، ويقرّر ما إذا كان سيسمح باستخدام المفتاح استنادًا إلى الطابع الزمني.
لا تتطلّب عملية المصادقة التواصل المباشر بين التطبيقات الموثوقة في
البيئة الآمنة: تتدفق رموز المصادقة المميّزة من التطبيق الموثوق للمصادقة إلى
خدمة keystore2 في Android، والتي بدورها تمررها إلى التطبيق الموثوق KeyMint.
يسمح هذا أيضًا لخدمة keystore2 برفض الطلبات التي من المؤكد فشلها بسرعة، لأنّها على عِلم برموز AuthToken المتاحة في النظام، ما يوفّر تكلفة محتملة لعملية الاتصال بين العمليات (IPC) في بيئة التنفيذ الموثوق بها (TEE).
تنسيق AuthToken
يتم تحديد تنسيق AuthToken من خلال مواصفات AIDL في
HardwareAuthToken.aidl.
مسار تشغيل الجهاز
عند كل عملية تشغيل للجهاز، يجب إنشاء مفتاح HMAC لرمز AuthToken ومشاركته مع جميع مكوّنات بيئة التنفيذ الموثوق بها (Gatekeeper وKeyMint والتطبيقات الموثوقة المتوافقة مع المقاييس الحيوية). لمنع هجمات إعادة التشغيل، يجب إنشاء مفتاح HMAC عشوائيًا في كل مرة تتم فيها إعادة تشغيل الجهاز.
هناك طريقتان شائعتان يحصل من خلالهما المهاجمون على إذن الوصول إلى مفتاح HMAC المشترَك هذا:
- اتفاقية الرمز السري المشترك: تنفّذ خدمة
keystore2بروتوكول اتفاقية مفتاح متعدد الاتجاهات عند بدء تشغيل الجهاز، ما يسمح بالاشتقاق الآمن لمفتاح HMAC بين تطبيقات TA المشارِكة. ومع ذلك، يجب أن تتمكّن تطبيقات TA المشارِكة من الوصول إلى مفتاح سري مشترك مسبقًا. - الوصول المباشر: يمكن للتطبيقات الموثوقة التي تقع ضمن البيئة الآمنة نفسها استخدام آلية داخلية للتواصل البيني للعمليات (تعتمد على النظام الأساسي) لمشاركة مفتاح HMAC.
وفي كلتا الحالتين، يجب عدم إتاحة مفتاح HMAC خارج "بيئة التنفيذ الموثوق بها".
يُعدّ نظام التشغيل Trusty الذي يعمل إلى جانب Android مثالاً على بيئة تنفيذ موثوقة، ولكن يمكن استخدام بيئات تنفيذ موثوقة أخرى بدلاً منه. يستخدم نظام Trusty نظامًا داخليًا للاتصال بين العمليات (IPC) للتواصل مباشرةً بين KeyMint وGatekeeper أو التطبيق الموثوق به (TA) المناسب للمقاييس الحيوية. يتم الاحتفاظ بمفتاح HMAC في KeyMint فقط، ويطلب كل من Fingerprint وGatekeeper المفتاح من KeyMint لكل استخدام ولا يحتفظان بالقيمة أو يخزّنانها مؤقتًا.
بما أنّ بعض بيئات التنفيذ الموثوقة تفتقر إلى بنية أساسية لبروتوكول IPC، لا يحدث أي اتصال بين التطبيقات الصغيرة في بيئة التنفيذ الموثوقة. ويسمح هذا أيضًا لخدمة تخزين المفاتيح برفض الطلبات التي من المؤكد فشلها بسرعة، لأنّها على دراية بجدول المصادقة في النظام، ما يوفّر تكلفة محتملة لعملية الاتصال بين العمليات (IPC) في بيئة التنفيذ الموثوق بها (TEE).