بیومتریک

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

احراز هویت صفحه قفل ادغام BiometricPrompt فروشگاه کلید (کلید مبتنی بر زمان) فروشگاه کلید (کلید مبتنی بر عملیات)
BIOMETRIC_STRONG (کلاس 3) آره آره آره آره
BIOMETRIC_WEAK (کلاس 2) آره آره خیر خیر
BIOMETRIC_CONVENIENCE
(کلاس 1)
آره خیر خیر خیر
DEVICE_CREDENTIAL آره آره آره آره

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

منبع

اندروید 12

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

اندروید 11

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

اندروید 10

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

اندروید 9

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

پیاده سازی

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

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

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

دستورالعمل اجرای HAL

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

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

سفارشی سازی

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

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

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


روش

هدف رشته

نوع(های) احراز هویت برای گنجاندن

اگر بیومتریک(های) و قفل صفحه هر دو امکان پذیر باشد

getButtonLabel()

برچسبی برای دکمه ای که BiometricPrompt را فعال می کند، برچسب بزنید

فقط انواع ثبت‌شده (در صورت امکان) که الزامات احراز هویت را برآورده می‌کنند

از رشته فقط بیومتریک استفاده کنید (مانند «استفاده از اثر انگشت»)

getPromptMessage()

هنگام احراز هویت، پیامی در BiometricPrompt نشان داده می‌شود

فقط انواع ثبت‌شده (در صورت امکان) که الزامات احراز هویت را برآورده می‌کنند

از رشته بیومتریک و قفل صفحه ترکیبی استفاده کنید (مثلاً «از اثر انگشت یا پین خود برای ادامه استفاده کنید»)

getSettingName()

نام تنظیمی که BiometricPrompt را برای احراز هویت فعال می کند

همه انواع پشتیبانی شده توسط دستگاه (حتی اگر ثبت نام نکرده باشند) که الزامات احراز هویت را برآورده می کنند

استفاده از رشته بیومتریک و قفل صفحه ترکیبی (مانند «استفاده از اثر انگشت یا قفل صفحه»)

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


احراز هویت مجاز

getButtonLabel()

getPromptMessage()

getSettingName()

بیومتریک کلاس 3 ( BIOMETRIC_STRONG )

"استفاده از اثر انگشت"
(فقط اثر انگشت الزامات احراز هویت را برآورده می کند)

"از اثر انگشت خود برای ادامه استفاده کنید"
(فقط اثر انگشت الزامات احراز هویت را برآورده می کند)

"استفاده از اثر انگشت"
(فقط اثر انگشت الزامات احراز هویت را برآورده می کند)

بیومتریک کلاس 2 ( BIOMETRIC_WEAK )

"استفاده از چهره"
(چهره و اثر انگشت الزامات را برآورده می کند؛ فقط چهره ثبت نام می شود)

"از چهره خود برای ادامه استفاده کنید"
(چهره و اثر انگشت الزامات را برآورده می کند؛ فقط چهره ثبت نام می شود)

"استفاده از چهره یا اثر انگشت"
(چهره و اثر انگشت الزامات را برآورده می کند؛ دستگاه از هر دو پشتیبانی می کند)

قفل صفحه ( DEVICE_CREDENTIAL )

"استفاده از پین"
(هر قفل صفحه الزامات را برآورده می کند؛ پین ثبت شده است)

"برای ادامه پین ​​خود را وارد کنید"
(هر قفل صفحه الزامات را برآورده می کند؛ پین ثبت شده است)

"استفاده از قفل صفحه"
(هر قفل صفحه الزامات را برآورده می کند)

قفل صفحه بیومتریک OR کلاس 3

"استفاده از پین"
(اثر انگشت و هرگونه قفل صفحه الزامات را برآورده می کند؛ فقط پین ثبت می شود)

"برای ادامه پین ​​خود را وارد کنید"
(اثر انگشت و هرگونه قفل صفحه الزامات را برآورده می کند؛ فقط پین ثبت می شود)

"استفاده از اثر انگشت یا قفل صفحه"
(اثر انگشت و هرگونه قفل صفحه الزامات را برآورده می کند)

قفل صفحه بیومتریک OR کلاس 2

"استفاده از چهره"
(چهره، اثر انگشت و هرگونه قفل صفحه الزامات را برآورده می کند؛ چهره ثبت شده و جایگزین پین می شود)

"برای ادامه از چهره یا پین خود استفاده کنید"
(چهره، اثر انگشت و هرگونه قفل صفحه الزامات را برآورده می کند؛ چهره و پین ثبت شده است)

"استفاده از بیومتریک یا قفل صفحه"
(چهره، اثر انگشت و هرگونه قفل صفحه الزامات را برآورده می کند)

اعتبار سنجی

اجرای بیومتریک شما باید تست های زیر را پشت سر بگذارد:

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

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