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

ملخص

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

يعد مكدس مصادقة الوجه في Android تطبيقًا جديدًا في Android 10. يقدم التطبيق الجديد واجهات IBiometricsFace.hal و IBiometricsFaceClientCallback.hal و types.hal .

بنيان

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

كومة البيومترية
الشكل 1. كومة البيومترية

FaceManager

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

خدمة الوجه

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

واجه

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

تطبيق

وجه هيدل

لتنفيذ 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() تمكين أو تعطيل ميزة للمستخدم الحالي. لأسباب أمنية، يتطلب ذلك وجود قبعة للتحقق من رقم التعريف الشخصي/النمط/كلمة المرور الخاصة بالمستخدم مقابل التحدي المذكور أعلاه
getFeature() يسترد حالة التمكين الحالية للميزة، كما تمليها الحالة الافتراضية أو استدعاء setFeature() أعلاه. إذا كان معرف الوجه غير صالح، فيجب أن يُرجع التنفيذ ILLEGAL_ARGUMENT
getAuthenticatorId() إرجاع معرف مرتبط بمجموعة الوجه الحالية. يجب أن يتغير هذا المعرف عند إضافة وجه

الرسم التخطيطي للدولة

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

الرسم التخطيطي للدولة
الشكل 2. تدفق حالة مصادقة الوجه