Authentication

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

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

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

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

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

ثبت‌نام

در اولین راه‌اندازی دستگاه پس‌از بازنشانی کارخانه‌ای، همه اصالت‌سنج‌ها برای دریافت ثبت‌نام‌های اطلاعات کاربری از کاربر آماده می‌شوند. کاربر باید ابتدا پین، الگو، یا گذرواژه‌ای را در Gatekeeper (یا Weaver، درصورت دردسترس بودن) ثبت کند. این ثبت‌نام اولیه یک شناسه ایمن کاربر (SID) ۶۴ بیتی به‌طور تصادفی تولید می‌کند که به‌عنوان شناسه‌ای برای کاربر و به‌عنوان کد الزام‌آور برای مطالب رمزنگاری کاربر عمل می‌کند. این شناسه امنیتی کاربر به‌صورت رمزنگاری‌شده به گذرواژه کاربر متصل است؛ اصالت‌سنجی‌های موفق در Gatekeeper به AuthTokens منجر می‌شود که حاوی شناسه امنیتی کاربر برای آن گذرواژه است.

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

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

اصالت‌سنجی

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

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

شکل ۱. جریان اصالت‌سنجی

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

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

قالب AuthToken

قالب AuthToken توسط مشخصات AIDL در HardwareAuthToken.aidl ارائه شده است.

جریان راه‌اندازی دستگاه

در هر راه‌اندازی دستگاه، کلید AuthToken HMAC باید تولید شود و با همه مؤلفه‌های TEE (Gatekeeper،‏ KeyMint، و TAهای زیست‌سنجشی پشتیبانی‌شده) هم‌رسانی شود. برای جلوگیری از حملات بازپخش، کلید HMAC باید هربار که دستگاه بازراه‌اندازی می‌شود به‌صورت تصادفی تولید شود.

دو روش رایج وجود دارد که برنامه‌های کاربردی معتمد ازطریق آن‌ها به این کلید HMAC مشترک دسترسی پیدا می‌کنند:

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

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

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

ازآنجایی‌که برخی‌از TEEها فاقد زیرساخت IPC هستند، هیچ ارتباطی بین برنامک‌ها در TEE برقرار نمی‌شود. این کار همچنین به سرویس keystore اجازه می‌دهد تا درخواست‌هایی را که قطعاً ناموفق خواهند بود به‌سرعت رد کند، زیرا از جدول اصالت‌سنجی در سیستم مطلع است و این امر باعث صرفه‌جویی در IPC بالقوه پرهزینه در TEE می‌شود.