بیومتریک

بیومتریک‌ها روشی راحت‌تر، اما به طور بالقوه با امنیت کمتر، برای تأیید هویت شما با یک دستگاه ارائه می‌دهند. در مدل احراز هویت لایه‌ای، احراز هویت اولیه (یعنی روش‌های مبتنی بر عامل دانش مانند پین، الگو و رمز عبور) بالاترین سطح امنیت را فراهم می‌کند. بیومتریک‌ها در لایه دوم احراز هویت قرار دارند و تعادلی از راحتی و امنیت را ارائه می‌دهند. CDD اندروید سه کلاس از قدرت بیومتریک را تعریف می‌کند: کلاس ۳ (قبلاً قوی)، کلاس ۲ (قبلاً ضعیف) و کلاس ۱ (قبلاً راحتی). هر کلاس مجموعه‌ای از پیش‌نیازها، امتیازات و محدودیت‌ها را دارد - لطفاً برای جزئیات بیشتر به CDD بالا مراجعه کنید. هر سه کلاس مجاز به ادغام با صفحه قفل هستند، اما فقط احرازگرهای قوی و ضعیف مجاز به ادغام با APIهای android.hardware.biometrics هستند. این جدول هر احرازگر و عملکردی را که پشتیبانی می‌کنند شرح می‌دهد.

تأییدکننده	قفل صفحه	ادغام BiometricPrompt	ذخیره کلید (کلید مبتنی بر زمان)	کلید ذخیره شده (کلید مبتنی بر عملیات)
بیومتریک_قوی (کلاس ۳)	بله	بله	بله	بله
بیومتریک_ضعیف (کلاس ۲)	بله	بله	خیر	خیر
راحتی بیومتریک (کلاس ۱)	بله	خیر	خیر	خیر
اعتبارنامه دستگاه	بله	بله	بله	بله

چارچوب اندروید شامل پشتیبانی از احراز هویت بیومتریک چهره و اثر انگشت است. اندروید را می‌توان طوری سفارشی کرد که از سایر روش‌های بیومتریک (مانند عنبیه چشم) نیز پشتیبانی کند. با این حال، ادغام بیومتریک به امنیت بیومتریک بستگی دارد، نه به روش. برای جزئیات بیشتر در مورد مشخصات امنیتی بیومتریک، به اندازه‌گیری امنیت باز کردن قفل بیومتریک مراجعه کنید.

منبع

اندروید ۱۲

• رابط برنامه‌نویسی کاربردی BiometricManager.Strings را معرفی می‌کند که رشته‌های محلی‌شده را برای برنامه‌هایی که از BiometricPrompt برای احراز هویت استفاده می‌کنند، فراهم می‌کند. این رشته‌ها به گونه‌ای طراحی شده‌اند که از دستگاه آگاه باشند و در مورد نوع(های) احراز هویتی که ممکن است استفاده شوند، دقت بیشتری ارائه دهند.
• شامل پشتیبانی از حسگر اثر انگشت زیر نمایشگر (UDFPS) می‌شود.

اندروید ۱۱

• رابط BiometricManager.Authenticators را معرفی می‌کند، که ثابت‌هایی را ارائه می‌دهد که توسعه‌دهندگان می‌توانند از آنها برای مشخص کردن انواع احراز هویت پذیرفته شده توسط برنامه‌های خود استفاده کنند.
• اکشن اینتنت ACTION_BIOMETRIC_ENROLL را اضافه می‌کند که توسعه‌دهندگان می‌توانند از آن برای هدایت کاربر به ثبت یک روش احراز هویت که الزامات برنامه‌هایشان را برآورده می‌کند، استفاده کنند.
• متد AuthenticationResult #getAuthenticationType () را اضافه می‌کند که توسعه‌دهندگان می‌توانند از آن برای بررسی اینکه آیا کاربر با استفاده از اعتبارنامه بیومتریک یا اعتبارنامه دستگاه احراز هویت شده است، استفاده کنند.
• پشتیبانی بیشتری برای کلیدهای احراز هویت به ازای هر بار استفاده در کلاس BiometricPrompt ارائه می‌دهد.

اندروید ۱۰

• کلاس BiometricManager را معرفی می‌کند که توسعه‌دهندگان می‌توانند از آن برای پرس‌وجو در مورد در دسترس بودن احراز هویت بیومتریک استفاده کنند.
• شامل ادغام احراز هویت اثر انگشت و چهره برای BiometricPrompt

اندروید ۹

• شامل ادغام اثر انگشت فقط برای BiometricPrompt است.
• کلاس FingerprintManager را منسوخ می‌کند. اگر برنامه‌های همراه و سیستمی شما از این کلاس استفاده می‌کنند، آنها را به‌روزرسانی کنید تا به جای آن از BiometricPrompt و BiometricManager استفاده کنند.
• تست‌های تأییدکننده‌ی FingerprintManager CTS به‌روزرسانی شد تا BiometricPrompt با استفاده از BiometricPromptBoundKeysTest تست شود.

پیاده‌سازی

برای اطمینان از اینکه کاربران و توسعه‌دهندگان یک تجربه بیومتریک یکپارچه دارند، پشته بیومتریک خود را با BiometricPrompt ، BiometricManager و ACTION_BIOMETRIC_ENROLL APIها ادغام کنید. دستگاه‌های دارای حسگرهای بیومتریک باید این الزامات قدرت را رعایت کنند. علاوه بر این، تمام پیاده‌سازی‌ها باید ماژول CTS CtsBiometricsTestCases را با موفقیت پشت سر بگذارند.

برای ادغام پشته بیومتریک خود با API ACTION_BIOMETRIC_ENROLL:

1. BiometricEnrollActivity را برای نمایش روند ثبت‌نام خود تغییر دهید. توجه داشته باشید که اطلاعات بیومتریک شما فقط در صورتی نمایش داده می‌شود که قدرت درخواستی را داشته باشد. اگر دستگاه شما بیش از یک مورد را پشتیبانی می‌کند، این اقدام باید فهرستی را ارائه دهد که کاربر بتواند از بین آنها انتخاب کند.

شکل ۱. معماری BiometricPrompt

دستورالعمل‌های پیاده‌سازی HAL

برای اطمینان از اینکه داده‌های بیومتریک فاش نمی‌شوند و هنگام جدا شدن کاربر از دستگاه، حذف می‌شوند، این دستورالعمل‌های بیومتریک HAL را دنبال کنید:

• مطمئن شوید که داده‌های خام بیومتریک یا مشتقات (مانند الگوها) هرگز از خارج از محیط ایزوله امن (مانند TEE یا Secure Element) قابل دسترسی نیستند. تمام داده‌های ذخیره شده باید با یک کلید مخصوص دستگاه که فقط برای محیط اجرای قابل اعتماد (TEE) شناخته شده است، رمزگذاری شوند. اگر سخت‌افزار از آن پشتیبانی می‌کند، دسترسی سخت‌افزار به محیط ایزوله امن را محدود کنید و آن را با یک سیاست SELinux محافظت کنید. کانال ارتباطی (به عنوان مثال، SPI، I2C) را فقط برای محیط ایزوله امن با یک سیاست صریح SELinux در تمام فایل‌های دستگاه قابل دسترسی کنید.
• اخذ، ثبت و شناسایی اطلاعات بیومتریک باید در یک محیط ایزوله و امن انجام شود تا از نقض داده‌ها و سایر حملات جلوگیری شود. این الزام فقط در مورد اطلاعات بیومتریک کلاس ۳ (قبلاً قوی) و کلاس ۲ (قبلاً ضعیف) اعمال می‌شود.
• برای محافظت در برابر حملات بازپخش، الگوهای بیومتریک را با یک کلید خصوصی مخصوص دستگاه امضا کنید. برای استاندارد رمزگذاری پیشرفته (AES)، حداقل یک الگو را با مسیر سیستم فایل، گروه و شناسه بیومتریک مطلق امضا کنید تا فایل‌های الگو در دستگاه دیگر یا برای هر کسی غیر از کاربری که آنها را در همان دستگاه ثبت کرده است، غیرقابل اجرا باشند. به عنوان مثال، از کپی کردن داده‌های بیومتریک از یک کاربر دیگر در همان دستگاه یا از دستگاه دیگر جلوگیری کنید.
• اگر نیاز به ذخیره داده‌ها خارج از TEE دارید، از مسیر سیستم فایل ارائه شده توسط setActiveUser() HIDL method استفاده کنید یا راه دیگری برای پاک کردن تمام داده‌های الگوی کاربر هنگام حذف کاربر ارائه دهید. دلیل این کار محافظت از نشت داده‌های کاربر است. دستگاه‌هایی که از این مسیر استفاده نمی‌کنند باید پس از حذف کاربر پاکسازی شوند. طبق CDD، داده‌های بیومتریک و فایل‌های مشتق شده باید رمزگذاری شده ذخیره شوند - به خصوص اگر در TEE نباشند. اگر این کار به دلیل الزامات ذخیره‌سازی محیط ایزوله امن امکان‌پذیر نیست، قلاب‌هایی اضافه کنید تا از حذف داده‌ها هنگام حذف کاربر یا پاک شدن دستگاه اطمینان حاصل شود. به LockSettingsService.removeBiometricsForUser() مراجعه کنید.

سفارشی‌سازی

اگر دستگاه شما از چندین بیومتریک پشتیبانی می‌کند، کاربر باید بتواند یک پیش‌فرض را در تنظیمات مشخص کند. پیاده‌سازی BiometricPrompt شما باید بیومتریک کلاس ۳ (که قبلاً Strong بود) را به عنوان پیش‌فرض ترجیح دهد، مگر اینکه کاربر صریحاً آن را لغو کند، سپس باید یک پیام هشدار نمایش داده شود که خطرات مرتبط با بیومتریک را توضیح دهد (برای مثال، عکسی از شما ممکن است دستگاه شما را باز کند ).

رشته‌های احراز هویت مختص دستگاه

از اندروید ۱۲ به بعد، رشته‌های احراز هویت متنی از طریق API BiometricManager.Strings در اختیار توسعه‌دهندگان قرار می‌گیرند. شما می‌توانید مقادیر منابع برگردانده شده توسط این API را برای پیاده‌سازی رشته‌های مختص دستگاه سفارشی کنید. در این صورت، مطمئن شوید که هر رشته جدید برای تمام زبان‌هایی که دستگاه پشتیبانی می‌کند، ترجمه شده است. علاوه بر این، مطمئن شوید که ویژگی‌های زیر حفظ شده‌اند:

روش	هدف رشته	نوع(های) احراز هویتی که باید لحاظ شود	اگر هم قفل بیومتریک و هم قفل صفحه نمایش امکان‌پذیر باشد
تابع getButtonLabel()	برچسب برای دکمه‌ای که BiometricPrompt را فعال می‌کند	فقط انواع ثبت‌شده (در صورت امکان) که الزامات احراز هویت را برآورده می‌کنند	فقط از رشته‌های بیومتریک استفاده کنید (مانند «استفاده از اثر انگشت»)
تابع getPromptMessage()	پیام نمایش داده شده در BiometricPrompt هنگام احراز هویت	فقط انواع ثبت‌شده (در صورت امکان) که الزامات احراز هویت را برآورده می‌کنند	از ترکیبی از رشته‌های بیومتریک و قفل صفحه استفاده کنید (مثلاً «برای ادامه از اثر انگشت یا پین خود استفاده کنید»)
دریافت نام تنظیمات ()	نام تنظیماتی که BiometricPrompt را برای احراز هویت فعال می‌کند	تمام انواع پشتیبانی‌شده توسط دستگاه (حتی اگر ثبت نشده باشند) که الزامات احراز هویت را برآورده می‌کنند	از ترکیب رشته‌های بیومتریک و قفل صفحه استفاده کنید (مانند «استفاده از اثر انگشت یا قفل صفحه»)

برای مثال، دستگاهی را در نظر بگیرید که دارای یک حسگر چهره کلاس ۲ با چهره ثبت‌شده ، یک پین ثبت‌شده و یک حسگر اثر انگشت کلاس ۳ بدون اثر انگشت ثبت‌شده است . جدول زیر رشته‌های نمونه‌ای را برای هر ترکیب از احراز هویت‌کننده‌های مجاز و متد BiometricManager.Strings فراخوانی‌شده ارائه می‌دهد:

احراز هویت کننده های مجاز	تابع getButtonLabel()	تابع getPromptMessage()	دریافت نام تنظیمات ()
بیومتریک کلاس ۳ ( BIOMETRIC_STRONG )	«استفاده از اثر انگشت» (فقط اثر انگشت الزامات احراز هویت را برآورده می‌کند)	«برای ادامه از اثر انگشت خود استفاده کنید» (فقط اثر انگشت الزامات احراز هویت را برآورده می‌کند)	«استفاده از اثر انگشت» (فقط اثر انگشت الزامات احراز هویت را برآورده می‌کند)
بیومتریک کلاس ۲ ( BIOMETRIC_WEAK )	«از چهره استفاده کنید» (چهره و اثر انگشت الزامات را برآورده می‌کنند؛ فقط چهره ثبت می‌شود)	«از صورتت برای ادامه دادن استفاده کن» (چهره و اثر انگشت الزامات را برآورده می‌کنند؛ فقط چهره ثبت می‌شود)	«استفاده از چهره یا اثر انگشت» (چهره و اثر انگشت الزامات را برآورده می‌کنند؛ دستگاه از هر دو پشتیبانی می‌کند)
قفل صفحه ( اعتبار دستگاه )	«استفاده از پین» (هر قفل صفحه‌ای الزامات را برآورده می‌کند؛ پین ثبت شده است)	«برای ادامه، پین خود را وارد کنید» (هر قفل صفحه‌ای الزامات را برآورده می‌کند؛ پین ثبت شده است)	«استفاده از قفل صفحه» (هر قفل صفحه‌ای الزامات را برآورده می‌کند)
قفل صفحه نمایش بیومتریک یا کلاس ۳	«استفاده از پین» (اثر انگشت و هر قفل صفحه نمایشی الزامات را برآورده می‌کند؛ فقط پین ثبت می‌شود)	«برای ادامه، پین خود را وارد کنید» (اثر انگشت و هر قفل صفحه نمایشی الزامات را برآورده می‌کند؛ فقط پین ثبت می‌شود)	«استفاده از اثر انگشت یا قفل صفحه» (اثر انگشت و هر قفل صفحه نمایشی الزامات را برآورده می‌کند)
قفل صفحه نمایش بیومتریک یا کلاس ۲	«از چهره استفاده کنید» (چهره، اثر انگشت و هر قفل صفحه نمایشی الزامات را برآورده می‌کند؛ چهره ثبت شده و جایگزین پین می‌شود)	«برای ادامه از چهره یا پین خود استفاده کنید» (چهره، اثر انگشت و هر قفل صفحه‌ای الزامات را برآورده می‌کند؛ چهره و پین ثبت شده‌اند)	«از بیومتریک یا قفل صفحه استفاده کنید» (چهره، اثر انگشت و هر قفل صفحه نمایشی الزامات را برآورده می‌کند)

اعتبارسنجی

پیاده‌سازی بیومتریک شما باید آزمون‌های زیر را با موفقیت پشت سر بگذارد:

• مدیر بیومتریک CTS
• CTS BiometricPrompt (تست سلامت عقل و عمیق به تأییدکننده متکی است)
• بخش تست بیومتریک CtsVerifier: باید به صورت جداگانه با هر روشی که دستگاه پشتیبانی می‌کند، پذیرفته شود.

علاوه بر این، اگر دستگاه شما از یک بیومتریک که دارای AOSP HIDL است ( اثر انگشت@2.1 ، اثر انگشت@2.2 ، چهره1.0 ) پشتیبانی می‌کند، باید آزمون VTS مربوطه ( اثر انگشت ، چهره ) را با موفقیت پشت سر بگذارد.