Authentication

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

• ذخیره سازی کلید رمزنگاری و ارائه دهنده خدمات. Android Keystore خدمات رمزنگاری سخت افزاری را برای برنامه ها ارائه می دهد. سیستم Android Keystore در سطح چارچوب توسط سرویس سیستم keystore2 پشتیبانی می شود. این به نوبه خود مبتنی بر پیاده‌سازی KeyMint (که قبلاً Keymaster بود) ویژه فروشنده است که تضمین می‌کند مواد کلیدی فقط در یک محیط امن با پشتوانه سخت‌افزار، مانند یک محیط اجرای مورد اعتماد (TEE) یا یک عنصر امن (SE) قابل دسترسی است.
• احراز هویت کاربر تأیید اعتبار موفقیت آمیز کاربر را تأیید کنید. اندروید از اجزای احراز هویت زیر پشتیبانی می کند:
  • دروازه‌بان برای احراز هویت پین، الگو یا رمز عبور در TEE.
  • (اختیاری) Weaver برای احراز هویت پین، الگو یا رمز عبور در یک عنصر امن.
  • اثر انگشت برای احراز هویت اثر انگشت.
  • سایر روش های احراز هویت بیومتریک دستگاه‌هایی که با Android 9 یا بالاتر عرضه می‌شوند، می‌توانند از BiometricPrompt به عنوان یک نقطه ادغام برای اثر انگشت و بیومتریک اضافی استفاده کنند.
  این مؤلفه‌ها وضعیت احراز هویت خود را با سرویس keystore2 از طریق استفاده از نشانه‌های احراز هویت با پشتوانه سخت‌افزاری (AuthTokens) در میان می‌گذارند.

هر یک از این مؤلفه‌ها مختص فروشنده است، اما پیاده‌سازی فروشنده برای برآوردن مشخصات رابط لایه انتزاعی سخت‌افزار (HAL) و گذراندن آزمایش‌های مجموعه تست فروشنده (VTS) مربوطه مورد نیاز است.

پیاده سازی های فروشنده نیز معمولاً به دو بخش تقسیم می شوند که توسط یک مکانیسم ارتباطی خاص فروشنده به هم متصل می شوند:

• یک سرویس HAL به عنوان یک فرآیند سیستم اندروید اجرا می شود و درخواست های Binder را از سیستم اندروید دریافت می کند.
• یک برنامه قابل اعتماد (TA) در محیط امن اجرا می شود و عملیات ایمن واقعی را انجام می دهد.

ثبت نام

در اولین راه‌اندازی دستگاه پس از بازنشانی کارخانه، همه احراز هویت‌کنندگان برای دریافت ثبت‌نام اعتبار از کاربر آماده می‌شوند. کاربر باید ابتدا یک پین، الگو یا رمز عبور را در Gatekeeper (یا Weaver، در صورت وجود) ثبت کند. این ثبت‌نام اولیه یک شناسه امن کاربر 64 بیتی (SID) به‌طور تصادفی ایجاد می‌کند که به عنوان یک شناسه برای کاربر و به عنوان یک نشانه الزام‌آور برای مواد رمزنگاری کاربر عمل می‌کند. این SID کاربر از نظر رمزنگاری به رمز عبور کاربر متصل است. احراز هویت موفق Gatekeeper منجر به AuthToken هایی می شود که حاوی SID کاربر برای آن رمز عبور است.

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

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

احراز هویت

این بخش یک جریان احراز هویت معمولی را توصیف می کند که شامل تعاملات بین چندین مؤلفه هم در Android و هم در محیط امن است. توجه داشته باشید که همه اجزای امن یک کلید مخفی HMAC (در هر بوت) مشترک دارند که از آن برای احراز هویت پیام های یکدیگر استفاده می کنند.

پس از اینکه کاربر یک اعتبارنامه را تنظیم کرد و یک SID کاربر به او اختصاص داد، می‌تواند احراز هویت را شروع کند، که زمانی شروع می‌شود که کاربر یک پین، الگو، رمز عبور، اثر انگشت یا سایر بیومتریک‌های قوی ارائه کند.

شکل 1. جریان احراز هویت

1. یک کاربر یک روش احراز هویت را ارائه می دهد و سرویس مرتبط درخواستی را به سرویس HAL می دهد.
   • برای پین، الگو یا رمز عبور، LockSettingsService درخواستی از gatekeeperd می‌کند.
   • جریان‌های احراز هویت مبتنی بر بیومتریک به نسخه Android بستگی دارد. در دستگاه‌هایی که Android نسخه 8.x و پایین‌تر دارند، FingerprintService درخواست fingerprintd می‌کند. در دستگاه‌های دارای Android 9 و بالاتر، BiometricPrompt با استفاده از کلاس Biometric Manager مناسب، مانند FingerprintManager یا FaceManager ، از دیمون بیومتریک مناسب (به عنوان مثال، fingerprintd برای اثر انگشت یا faced برای چهره) درخواست می‌کند. صرف نظر از نسخه، احراز هویت بیومتریک به صورت ناهمزمان پس از ارسال درخواست انجام می شود.
2. سرویس HAL داده ها را به همتای خود TA می فرستد که یک AuthToken تولید می کند:
   • برای احراز هویت پین/الگو/رمز عبور، gatekeeperd پین، الگو یا هش رمز عبور را از طریق سرویس Gatekeeper HAL به Gatekeeper TA در TEE می‌فرستد. اگر احراز هویت در TEE موفقیت آمیز باشد، Gatekeeper TA یک AuthToken حاوی SID کاربر مربوطه (امضا شده با کلید HMAC مشترک) منتشر می کند.
   • برای احراز هویت اثر انگشت، fingerprintd به رویدادهای اثر انگشت گوش می‌دهد و داده‌ها را از طریق HAL اثر انگشت به Fingerprint TA در TEE ارسال می‌کند. اگر احراز هویت در TEE موفقیت آمیز باشد، اثر انگشت TA یک AuthToken (که با کلید AuthToken HMAC امضا شده است) منتشر می کند.
   • برای سایر احراز هویت بیومتریک، شبح بیومتریک مناسب به رویداد بیومتریک گوش می دهد و آن را به سرویس HAL و TA بیومتریک مناسب می فرستد.
3. AuthToken امضا شده از طریق رابط Binder به سرویس سیستم keystore2 ارسال می شود.
4. سرویس keystore2 AuthTokens را برای درخواست KeyMint (که قبلاً Keymaster بود) برای انجام عملیات رمزنگاری متصل می‌کند. سرویس KeyMint HAL آنها را به KeyMint TA ارسال می کند، که آنها را با استفاده از کلید HMAC مشترک با Gatekeeper و اجزای بیومتریک TEE تأیید می کند. KeyMint به مهر زمانی در نشانه به عنوان آخرین زمان احراز هویت اعتماد می کند، تصمیم می گیرد که آیا اجازه استفاده از کلید را بر اساس مهر زمانی بدهد.

جریان احراز هویت نیازی به ارتباط مستقیم بین TAها در محیط امن ندارد: AuthTokenها از TA احراز هویت کننده به سرویس keystore2 در اندروید جریان می یابند که به نوبه خود آنها را به KeyMint TA منتقل می کند. این همچنین به سرویس keystore2 اجازه می‌دهد تا به سرعت درخواست‌هایی را که ممکن است شکست بخورند، رد کند، زیرا از AuthToken‌های موجود در سیستم آگاهی دارد و یک IPC بالقوه پرهزینه را در TEE ذخیره می‌کند.

فرمت AuthToken

فرمت AuthToken با مشخصات AIDL در HardwareAuthToken.aidl ارائه شده است.

جریان بوت دستگاه

در هر بوت یک دستگاه، کلید AuthToken HMAC باید تولید و با تمام اجزای TEE (Gatekeeper، KeyMint/Keymaster، و TAهای بیومتریک پشتیبانی شده) به اشتراک گذاشته شود. برای جلوگیری از حملات مجدد، هر بار که دستگاه راه اندازی مجدد می شود، کلید HMAC باید به طور تصادفی تولید شود.

دو راه متداول وجود دارد که TAها به این کلید HMAC مشترک دسترسی پیدا می کنند:

• قرارداد مخفی مشترک: سرویس keystore2 یک پروتکل توافقنامه کلید چند طرفه را هنگام راه‌اندازی دستگاه اجرا می‌کند و امکان استخراج امن کلید HMAC را بین آن دسته از TAهای شرکت‌کننده فراهم می‌کند. با این حال، TAهای شرکت کننده باید به یک راز مشترک از قبل به اشتراک گذاشته شده دسترسی داشته باشند.
• دسترسی مستقیم: TAهایی که در یک محیط امن قرار دارند می‌توانند از یک مکانیسم ارتباطی داخلی (که وابسته به پلتفرم است) برای به اشتراک گذاشتن کلید HMAC استفاده کنند.

در هر صورت، کلید HMAC هرگز نباید خارج از TEE در دسترس قرار گیرد.

سیستم عامل Trusty که در کنار اندروید اجرا می شود، نمونه ای از TEE است، اما می توان به جای آن از سایر TEE ها استفاده کرد. Trusty از یک سیستم IPC داخلی برای برقراری ارتباط مستقیم بین KeyMint و Gatekeeper یا TA بیومتریک مناسب استفاده می کند. کلید HMAC فقط در KeyMint نگهداری می شود. اثر انگشت و Gatekeeper برای هر بار استفاده، کلید را از KeyMint درخواست می‌کنند و مقدار را ثابت یا کش نکنید.