احراز هویت

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

• ذخیره سازی کلید رمزنگاری و ارائه دهنده خدمات. کلیدهای رمزنگاری را ذخیره می کند و روال های رمزنگاری استاندارد را در بالای آن کلیدها ارائه می دهد. Android از Keystore و Keymaster با پشتوانه سخت‌افزاری برای سرویس‌های رمزنگاری پشتیبانی می‌کند، از جمله رمزنگاری سخت‌افزاری برای ذخیره‌سازی کلید که ممکن است شامل یک محیط اجرای مطمئن (TEE) یا Secure Element (SE) مانند Strongbox باشد.
• احراز هویت کاربر حضور کاربر و/یا احراز هویت موفق را تأیید کنید. اندروید از Gatekeeper برای احراز هویت پین/الگو/رمز عبور و اثر انگشت برای احراز هویت با اثر انگشت پشتیبانی می‌کند. دستگاه‌هایی که با Android 9 و بالاتر عرضه می‌شوند می‌توانند از BiometricPrompt به عنوان یک نقطه ادغام برای اثر انگشت و بیومتریک اضافی استفاده کنند. این مولفه ها وضعیت احراز هویت خود را از طریق یک کانال احراز هویت شده با سرویس keystore ارتباط می دهند. ( سیستم Android Keystore در سطح چارچوب نیز توسط سرویس Keystore پشتیبانی می شود.)

مؤلفه‌های Gatekeeper، Fingerprint و Biometric با Keystore و سایر مؤلفه‌ها کار می‌کنند تا از توکن‌های احراز هویت با پشتوانه سخت‌افزاری (AuthTokens) پشتیبانی کنند.

ثبت نام

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

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

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

احراز هویت

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

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

فرمت AuthToken

برای اطمینان از اشتراک توکن و سازگاری بین زبان‌ها و مؤلفه‌ها، قالب AuthToken در hw_auth_token.h توضیح داده شده است. فرمت یک پروتکل سریال سازی ساده با فیلدهای اندازه ثابت است.

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

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

پروتکل به اشتراک گذاری این کلید HMAC با تمام اجزاء یک ویژگی پیاده سازی وابسته به پلتفرم است. کلید هرگز نباید خارج از TEE در دسترس قرار گیرد. اگر سیستم عامل TEE فاقد مکانیزم ارتباط بین فرآیندی داخلی (IPC) باشد و نیاز به انتقال داده ها از طریق سیستم عامل غیرقابل اعتماد داشته باشد، انتقال باید از طریق یک پروتکل تبادل کلید امن انجام شود.

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

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