نمای کلی
احراز هویت با چهره به کاربران این امکان را می‌دهد که قفل دستگاه خود را تنها با نگاه کردن به جلوی دستگاه باز کنند. اندروید ۱۰ از یک پشته جدید احراز هویت با چهره پشتیبانی می‌کند که می‌تواند فریم‌های دوربین را به طور ایمن پردازش کند و امنیت و حریم خصوصی را در حین احراز هویت با چهره روی سخت‌افزارهای پشتیبانی‌شده حفظ کند. اندروید ۱۰ همچنین راهی آسان برای پیاده‌سازی‌های سازگار با امنیت فراهم می‌کند تا ادغام برنامه‌ها برای تراکنش‌ها، مانند بانکداری آنلاین یا سایر خدمات، امکان‌پذیر شود.
پشته احراز هویت چهره اندروید یک پیاده‌سازی جدید در اندروید ۱۰ است. این پیاده‌سازی جدید، رابط‌های IBiometricsFace.hal ، IBiometricsFaceClientCallback.hal و types.hal را معرفی می‌کند.
معماری
رابط برنامه‌نویسی کاربردی BiometricPrompt شامل تمام احراز هویت‌های بیومتریک از جمله چهره، انگشت و عنبیه است. Face HAL با اجزای زیر تعامل دارد.
شکل ۱. مجموعه بیومتریک.
مدیر چهره
FaceManager یک رابط خصوصی است که ارتباط با FaceService را حفظ می‌کند. Keyguard از آن برای دسترسی به احراز هویت چهره با یک رابط کاربری سفارشی استفاده می‌کند. برنامه‌ها به FaceManager دسترسی ندارند و باید به جای آن از BiometricPrompt استفاده کنند.
خدمات چهره
این پیاده‌سازی چارچوبی است که دسترسی به سخت‌افزار احراز هویت چهره را مدیریت می‌کند. این شامل ماشین‌های وضعیت ثبت‌نام و احراز هویت اولیه و همچنین کمک‌کننده‌های مختلف دیگر (به عنوان مثال، شمارش) است. به دلیل نگرانی‌های مربوط به پایداری و امنیت، هیچ کد فروشنده‌ای مجاز به اجرا در این فرآیند نیست. تمام کدهای فروشنده از طریق رابط Face 1.0 HIDL قابل دسترسی هستند.
مواجه شد
این یک فایل اجرایی لینوکس است که رابط Face 1.0 HIDL مورد استفاده FaceService را پیاده‌سازی می‌کند. این فایل خود را با نام IBiometricsFace@1.0 ثبت می‌کند تا FaceService بتواند آن را پیدا کند.
پیاده‌سازی
صورت HIDL
برای پیاده‌سازی Face HIDL، باید تمام متدهای IBiometricsFace.hal را در یک کتابخانه مختص فروشنده پیاده‌سازی کنید.
پیام‌های خطا
پیام‌های خطا توسط یک فراخوانی برگشتی ارسال می‌شوند و پس از ارسال، دستگاه حالت را به حالت بیکار برمی‌گردانند. اکثر پیام‌ها دارای یک رشته‌ی مربوط به کاربر هستند تا کاربر را از خطا مطلع کنند، اما همه خطاها این رشته‌ی مربوط به کاربر را ندارند. برای اطلاعات بیشتر در مورد پیام‌های خطا، به types.hal مراجعه کنید. همه پیام‌های خطا نشان‌دهنده یک حالت ترمینال هستند، به این معنی که چارچوب فرض می‌کند که HAL پس از ارسال پیام خطا به حالت بیکار برمی‌گردد.
پیام‌های خرید
پیام‌های اکتساب در طول ثبت‌نام یا احراز هویت ارسال می‌شوند و برای هدایت کاربر به سمت ثبت‌نام یا احراز هویت موفق در نظر گرفته شده‌اند. هر عدد ترتیبی دارای یک پیام مرتبط از فایل FaceAuthenticationManager.java است. پیام‌های خاص فروشنده می‌توانند تا زمانی که رشته‌های کمکی مربوطه ارائه شوند، اضافه شوند. پیام‌های اکتساب به خودی خود حالت‌های پایانی نیستند؛ انتظار می‌رود HAL تا حد امکان از این پیام‌ها برای تکمیل ثبت‌نام یا احراز هویت فعلی ارسال کند. اگر یک پیام اکتساب منجر به حالت پایانی شود که در آن هیچ پیشرفتی حاصل نشود، HAL باید پیام‌های اکتساب را با یک پیام خطا دنبال کند، به عنوان مثال، جایی که تصویر خیلی تاریک است و برای پیشرفت خیلی تاریک می‌ماند. در این حالت، ارسال UNABLE_TO_PROCESS پس از چندین تلاش انجام شده اما هیچ پیشرفت بیشتری حاصل نمی‌شود، منطقی است.
سخت‌افزار
برای اینکه دستگاه‌ها بتوانند الزامات قوی بیومتریک اندروید ۱۰ را رعایت کنند، باید سخت‌افزار امنی داشته باشند تا یکپارچگی داده‌های چهره و مقایسه نهایی احراز هویت تضمین شود. سند تعریف سازگاری اندروید (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 از نمودار حالت زیر پیروی کند.
شکل ۲. جریان حالت احراز هویت چهره.