احراز هویت چهره HIDL

نمای کلی

احراز هویت چهره به کاربران این امکان را می دهد که قفل دستگاه خود را به سادگی با نگاه کردن به جلوی دستگاه خود باز کنند. اندروید 10 پشتیبانی از یک پشته احراز هویت چهره جدید را اضافه می کند که می تواند به طور ایمن فریم های دوربین را پردازش کند و امنیت و حریم خصوصی را در حین احراز هویت روی سخت افزار پشتیبانی شده حفظ کند. اندروید 10 همچنین راه آسانی را برای پیاده سازی های سازگار با امنیت فراهم می کند تا یکپارچه سازی برنامه ها را برای تراکنش ها، مانند بانکداری آنلاین یا سایر خدمات، فعال کند.

پشته احراز هویت چهره اندروید یک پیاده سازی جدید در Android 10 است. پیاده سازی جدید رابط های IBiometricsFace.hal ، IBiometricsFaceClientCallback.hal و types.hal را معرفی می کند.

معماری

BiometricPrompt API شامل تمام احراز هویت بیومتریک از جمله چهره، انگشت و عنبیه است. Face HAL با اجزای زیر تعامل دارد.

شکل 1. پشته بیومتریک.

FaceManager

FaceManager یک رابط خصوصی است که با FaceService ارتباط برقرار می کند. توسط Keyguard برای دسترسی به احراز هویت چهره با یک رابط کاربری سفارشی استفاده می‌شود. برنامه ها به FaceManager دسترسی ندارند و باید به جای آن از BiometricPrompt استفاده کنند.

فیس سرویس

این پیاده سازی چارچوبی است که دسترسی به سخت افزار احراز هویت چهره را مدیریت می کند. این شامل ماشین‌های اولیه ثبت‌نام و احراز هویت و همچنین کمک‌کننده‌های مختلف (مثلاً شمارش) است. به دلیل ثبات و نگرانی های امنیتی، هیچ کد فروشنده ای مجاز به اجرا در این فرآیند نیست. همه کدهای فروشنده از طریق رابط HIDL Face 1.0 قابل دسترسی هستند.

مواجه شد

این یک فایل اجرایی لینوکس است که رابط Face 1.0 HIDL مورد استفاده توسط FaceService را پیاده سازی می کند. خود را به عنوان IBiometricsFace@1.0 ثبت می کند تا FaceService بتواند آن را پیدا کند.

پیاده سازی

با HIDL روبرو شوید

برای پیاده سازی Face HIDL، باید تمام متدهای IBiometricsFace.hal را در یک کتابخانه خاص فروشنده پیاده سازی کنید.

پیام های خطا

پیام‌های خطا توسط یک تماس برگشتی ارسال می‌شوند و پس از ارسال، دستگاه حالت را به حالت غیرفعال برمی‌گردانند. بیشتر پیام‌ها دارای یک رشته مربوط به کاربر هستند تا کاربر را از خطا مطلع کنند، اما همه خطاها این رشته رو به کاربر را ندارند. برای اطلاعات بیشتر در مورد پیام های خطا، به types.hal مراجعه کنید. همه پیام های خطا نشان دهنده یک حالت ترمینال هستند، به این معنی که چارچوب فرض می کند که HAL پس از ارسال یک پیام خطا به حالت بیکار باز می گردد.

پیام های کسب

پیام‌های جذب در حین ثبت‌نام یا احراز هویت تحویل داده می‌شوند و به منظور راهنمایی کاربر به سمت ثبت نام یا احراز هویت موفق هستند. هر دستوری یک پیام مرتبط از فایل FaceAuthenticationManager.java دارد. تا زمانی که رشته های راهنمای مربوطه ارائه شده باشد، می توان پیام های خاص فروشنده را اضافه کرد. پیام های اکتساب به خودی خود حالت پایانی نیستند. انتظار می رود که HAL هر تعداد از این موارد را برای تکمیل ثبت نام یا احراز هویت فعلی ارسال کند. اگر پیام اکتساب منجر به یک حالت پایانی شود که در آن هیچ پیشرفتی حاصل نشود، HAL باید پیام‌های کسب را با یک پیام خطا دنبال کند، برای مثال، جایی که تصویر خیلی تاریک است و برای پیشرفت خیلی تاریک باقی می‌ماند. در این مورد، منطقی است که UNABLE_TO_PROCESS پس از چندین بار تلاش ارسال کنید، اما هیچ پیشرفت دیگری حاصل نمی شود.

سخت افزار

برای اینکه دستگاه‌ها با الزامات بیومتریک قوی اندروید 10 مطابقت داشته باشند، باید سخت‌افزار ایمن برای اطمینان از یکپارچگی داده‌های چهره و مقایسه نهایی احراز هویت داشته باشند. سند تعریف سازگاری اندروید (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()	هنگامی که تعداد زیادی از چهره ها رد می شوند، برای وارد شدن به حالت قفل ( LOCKOUT یا LOCKOUT_PERMANENT ) faced نیاز است. وقتی این کار انجام شد، باید زمان باقیمانده را به فریمورک ارسال کند تا بتواند آن را برای کاربر نمایش دهد. همانند setFeature() ، این روش برای بازنشانی ایمن حالت داخلی نیاز به یک نشانه تأیید هویت سخت افزاری فعال (HAT) دارد. قفل را فقط برای کاربر فعلی بازنشانی می کند.

سه روش باقیمانده همگی همزمان هستند و باید برای حداقل زمان مسدود شوند تا فریم ورک متوقف نشود.

روش	توضیحات
generateChallenge()	یک توکن تصادفی منحصر به فرد و امن رمزنگاری ایجاد می کند که برای نشان دادن شروع یک تراکنش امن استفاده می شود.
setFeature()	یک ویژگی را برای کاربر فعلی فعال یا غیرفعال می کند. به دلایل امنیتی، این نیاز به یک کلاه از بررسی پین / الگو / رمز عبور کاربر در برابر چالش فوق دارد.
getFeature()	وضعیت فعال سازی فعلی ویژگی را، همانطور که پیش فرض یا فراخوانی به setFeature() در بالا دیکته شده است، بازیابی می کند. اگر شناسه چهره نامعتبر است، پیاده سازی باید ILLEGAL_ARGUMENT برگرداند
getAuthenticatorId()	یک شناسه مرتبط با مجموعه چهره فعلی را برمی‌گرداند. هر زمان که چهره ای اضافه می شود، این شناسه باید تغییر کند

نمودار حالت

چارچوب انتظار دارد که faced از نمودار وضعیت زیر پیروی کند.

شکل 2. جریان وضعیت احراز هویت چهره.