نظرة عامة
تتيح ميزة "التحقّق من الوجه" للمستخدمين فتح قفل أجهزتهم ببساطة من خلال النظر إلى الجانب الأمامي من أجهزتهم. يتوافق Android 10 مع حزمة جديدة للتعرّف على الوجه يمكنها معالجة إطارات الكاميرا بأمان والحفاظ على الأمان والخصوصية أثناء مصادقة الوجه على الأجهزة المتوافقة. يقدّم نظام التشغيل Android 10 أيضًا طريقة سهلة لعمليات التنفيذ المتوافقة مع الأمان من أجل تفعيل دمج التطبيقات في المعاملات، مثل الخدمات المصرفية على الإنترنت أو الخدمات الأخرى.
حِزمة المصادقة بالتعرّف على الوجه في Android هي عملية تنفيذ جديدة في الإصدار Android
10. يقدّم الإجراء الجديد واجهات IBiometricsFace.hal،
IBiometricsFaceClientCallback.hal،
وtypes.hal.
هندسة معمارية
تتضمّن BiometricPrompt API جميع عمليات المصادقة بالمقاييس الحيوية، بما في ذلك الوجه والإصبع والقزحية. تتفاعل واجهة HAL للوجه مع المكونات التالية.
الشكل 1: حزمة المقاييس الحيوية
FaceManager
FaceManager هي واجهة خاصة تحافظ على
الاتصال بـ FaceService. ويستخدمه تطبيق "قفل الشاشة" ل
الوصول إلى ميزة "التعرّف على الوجه" باستخدام واجهة مستخدم مخصّصة. لا يمكن للتطبيقات
الوصول إلى FaceManager ويجب استخدام BiometricPrompt بدلاً من ذلك.
FaceService
هذا هو إطار عمل التنفيذ الذي يدير الوصول إلى أجهزة التعرّف على الوجه. يحتوي على آلات أساسية لحالة التسجيل والمصادقة، بالإضافة إلى العديد من الأدوات المساعدة الأخرى (مثل التعداد). وبسبب المخاوف المتعلقة بالثبات والأمان، لا يُسمح بتشغيل أي رمز مورد في هذه العملية. يتم الوصول إلى جميع رموز المورّدين من خلال واجهة Face 1.0 HIDL.
واجه
هذا ملف قابل للتنفيذ في نظام التشغيل Linux ينفِّذ واجهة Face 1.0 HIDL المستخدَمة
في 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.
الطرق
جميع الطرق التالية غير متزامنة ويجب أن تعود إلى الإطار مباشرةً. ويؤدي عدم تنفيذ ذلك إلى بطء النظام وإعادة ضبط مراقب النظام. ننصحك بإنشاء قائمة انتظار للرسائل تتضمّن سلاسل محادثات متعددة لتجنُّب حظر المتصل. يجب أن تخزن جميع طلبات 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. مسار حالة المصادقة بالوجه