مصادقة الوجه HIDL

نظرة عامة

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

حِزمة المصادقة بالتعرّف على الوجه في Android هي عملية تنفيذ جديدة في الإصدار Android 10. يقدّم الإجراء الجديد واجهات IBiometricsFace.hal وIBiometricsFaceClientCallback.hal وtypes.hal.

هندسة معمارية

تتضمّن BiometricPrompt API جميع عمليات المصادقة بالمقاييس الحيوية، بما في ذلك الوجه والإصبع والقزحية. يتفاعل Face HAL مع المكونات التالية.

مجموعة المقاييس الحيوية

الشكل 1: حزمة المقاييس الحيوية

FaceManager

FaceManager هي واجهة خاصة تحافظ على الاتصال بـ FaceService. ويستخدمه تطبيق "قفل الشاشة" ل الوصول إلى ميزة "التعرّف على الوجه" باستخدام واجهة مستخدم مخصّصة. لا يمكن للتطبيقات الوصول إلى FaceManager ويجب استخدام BiometricPrompt بدلاً من ذلك.

FaceService

هذا هو إطار عمل التنفيذ الذي يدير الوصول إلى أجهزة التعرّف على الوجه. يحتوي على آلات أساسية لحالة التسجيل والمصادقة، بالإضافة إلى العديد من الأدوات المساعدة الأخرى (مثل التعداد). بسبب المخاوف المتعلّقة بالثبات والأمان، لا يُسمح بتشغيل أي رمز مورّد في هذه العملية. يتم الوصول إلى جميع رموز المورّدين من خلال واجهة Face 1.0 HIDL.

واجه

هذا ملف قابل للتنفيذ في نظام التشغيل Linux ينفِّذ واجهة HIDL لنظام التشغيل Face 1.0 التي يستخدمهاFaceService. يسجّل نفسه باسم IBiometricsFace@1.0 حتى يتمكّن FaceService من العثور عليه.

التنفيذ

Face HIDL

لتنفيذ Face HIDL، يجب تنفيذ جميع الطرق الخاصة بـ IBiometricsFace.hal في مكتبة خاصة بالمورّد.

رسائل الخطأ

يتم إرسال رسائل الخطأ من خلال دالة استدعاء وتعيد آلة الحالات إلى حالة الخمول بعد إرسالها. تحتوي معظم الرسائل على سلسلة مخصّصة للمستخدم لإعلامه بالخطأ، ولكن ليس كل الأخطاء تتضمّن هذه السلسلة الموجَّهة للمستخدم. لمزيد من المعلومات عن رسائل الخطأ، يُرجى الاطّلاع على types.hal. تمثّل جميع رسائل الخطأ حالة نهائية، ما يعني أنّ الإطار المتّبع يفترض أن يعود ملف برمجة التطبيقات HAL إلى حالة الخمول بعد إرسال رسالة خطأ.

رسائل اكتساب المستخدمين

يتم إرسال رسائل اكتساب المستخدمين أثناء التسجيل أو المصادقة، ويهدف ذلك إلى توجيه المستخدم نحو إكمال عملية التسجيل أو المصادقة بنجاح. يحتوي كل رقم ترتيبي على رسالة مرتبطة من ملف FaceAuthenticationManager.java. يمكن إضافة رسائل خاصة بالمورّد شرط توفير سلاسل المساعدة المقابلة. لا تُعدّ رسائل اكتساب الأجهزة حالات نهائية بحد ذاتها، ومن المتوقّع أن ترسل وحدة HAL أكبر عدد ممكن من هذه الرسائل لتمتيع عملية التسجيل أو المصادقة الحالية. إذا أدّت رسالة اكتساب بيانات إلى حالة نهائية لا يمكن فيها تحقيق أي تقدّم، يجب أن يتبع HAL رسائل اكتساب البيانات برسالة خطأ، على سبيل المثال، عندما تكون الصورة مظلمة جدًا وتظل مظلمة جدًا لدرجة أنّه لا يمكن تحقيق أي تقدّم. في هذه الحالة، من المقبول إرسال UNABLE_TO_PROCESS بعد إجراء عدة محاولات ولكن لا يمكن إحراز أي تقدّم إضافي.

الأجهزة

لكي تكون الأجهزة متوافقة مع متطلبات المقاييس الحيوية القوية لنظام التشغيل Android 10، يجب أن تكون مزوّدة بأجهزة آمنة لضمان سلامة بيانات الوجه ومقارنة مصادقة فائقة. يوضّح مستند تعريف التوافق مع Android (CDD) مستوى الأمان المطلوب ونسبة قبول التزوير المقبولة (SAR). يجب توفُّر بيئة تنفيذ موثوقة (TEE) لإجراء المعالجة والتعرّف على البصمة بشكل آمن. بالإضافة إلى ذلك، يجب توفُّر أجهزة كاميرا آمنة لمنع هجمات الحقن على المصادقة بالتعرّف على الوجه. على سبيل المثال، يمكن أن تكون صفحات الذاكرة المرتبطة ببيانات الصور مميّزة ومميّزة للقراءة فقط حتى لا يتمكّن من تعديلها سوى جهاز الكاميرا. من الناحية المثالية، يجب ألا تحصل أي عملية على إذن الوصول إلى البيانات إلا TEE والأجهزة.

بسبب الاختلاف الكبير في أجهزة التعرّف على الوجه، من الضروري تطوير برامج تشغيل خاصة بالأجهزة لتفعيل ميزة التعرّف على الوجه، وذلك استنادًا إلى بنية الجهاز المحدّدة. ولذلك، لا يتوفّر مرجع تنفيذي لـ faced.

الطرق

جميع الأساليب التالية غير متزامنة ويجب أن تعود إلى الإطار المرجعي على الفور. يؤدي عدم إجراء ذلك إلى إبطاء النظام وإعادة ضبط وظائف Watchdog. ننصحك بإنشاء قائمة انتظار للرسائل تتضمّن سلاسل محادثات متعددة لتجنُّب حظر المتصل. يجب أن تخزِّن جميع طلبات GET المعلومات في ذاكرة التخزين المؤقت كلما أمكن ذلك حتى يتم حظر المتصل لفترة زمنية قصيرة.

الطريقة الوصف
setCallback() يتم استدعاء FaceService لإعادة توجيه جميع الرسائل إلى نفسها.
setActiveUser() تُستخدَم لضبط المستخدم النشط الذي يتم تطبيق جميع عمليات HAL اللاحقة عليه. تكون المصادقة دائمًا لهذا المستخدم إلى أن يتم استدعاء هذه الطريقة مرة أخرى.
revokeChallenge() تُنهي المعاملة الآمنة من خلال إلغاء صلاحية التحدي الذي تم إنشاؤه بواسطة generateChallenge().
enroll() تسجيل وجه المستخدم
cancel() يؤدي هذا الإجراء إلى إلغاء العملية الحالية (مثل التسجيل أو المصادقة أو الإزالة أو التعداد) ويعيد faced إلى حالة التوقف المؤقت.
enumerate() يُدرِج جميع نماذج الوجوه المرتبطة بالمستخدم النشط.
remove() تزيل نموذج وجه أو جميع نماذج الوجه المرتبطة بالمستخدم نشط.
authenticate() مصادقة المستخدم النشط
userActivity() يجب عدم استخدام هذه الطريقة إلا عندما يكون HAL في حالة المصادقة أو في حالة الاستعداد. يؤدي استخدام هذه الطريقة عندما لا يكون HAL في أحد هذه الحالات إلى عرض القيمة OPERATION_NOT_SUPPORTED. قد يؤدي استدعاء هذه الطريقة أثناء مصادقة HAL إلى إطالة مدّة البحث عن الوجه في النظام.
resetLockout() عند رفض عدد كبير جدًا من الوجوه، يجب أن يدخل faced في حالة قفل (LOCKOUT أو LOCKOUT_PERMANENT). وعند التحوّل إلى هذه الحالة، يجب إرسال الوقت المتبقّي إلى إطار العمل لكي تتمكّن من عرضه للمستخدم. كما هو الحال مع setFeature()، تتطلّب هذه الطريقة استخدام رمز مصادقة نشط للأجهزة (HAT) لإعادة ضبط الحالة الداخلية بأمان. تؤدي هذه القيمة إلى إعادة ضبط قفل الحساب فقط للمستخدم الحالي.

الطرق الثلاث المتبقية هي طرق متزامنة، ومن المفترض أن تؤدي إلى ازدحام الشبكة لفترة زمنية قصيرة لتجنّب توقُّف إطار العمل.

الطريقة الوصف
generateChallenge() تُنشئ رمزًا مميّزًا عشوائيًا وآمنًا بطريقة مشفَّرة يُستخدَم لتحديد بداية معاملة آمنة.
setFeature() تفعيل ميزة أو إيقافها للمستخدم الحالي لأسباب تتعلّق بالأمان، يتطلّب ذلك من HAT التحقّق من مطابقة رقم التعريف الشخصي/النمط/كلمة المرور الخاصة بالمستخدم مع التحدّي أعلاه.
getFeature() يسترجع حالة تفعيل الميزة الحالية، وفقًا لتحديد الإعداد التلقائي أو طلب setFeature() أعلاه. إذا كان معرّف الوجه غير صالح، يجب أن يعرض التنفيذ القيمة ILLEGAL_ARGUMENT.
getAuthenticatorId() لعرض معرّف مرتبط بمجموعة الوجوه الحالية. يجب تغيير هذا المعرّف عند إضافة أي وجه.

مخطّط الحالة

يتوقّع إطار العمل أن يتّبع faced الرسم البياني للحالات أدناه.

مخطّط الحالة

الشكل 2: مسار حالة المصادقة بالوجه