اندروید مفهومی به نام احراز هویت کاربر دارد که برای باز کردن قفل دستگاه و دسترسی به کلیدهای رمزنگاری استفاده میشود. این شامل اجزای زیر است:
- ذخیرهسازی کلید رمزنگاری و ارائهدهنده خدمات. کلیدهای رمزنگاری را ذخیره کرده و روالهای استاندارد رمزنگاری را بر روی آن کلیدها ارائه میدهد. اندروید از یک Keystore و KeyMint (که قبلاً Keymaster نام داشت) با پشتیبانی سختافزاری برای سرویسهای رمزنگاری، از جمله رمزنگاری با پشتیبانی سختافزاری برای ذخیرهسازی کلید که ممکن است شامل یک محیط اجرای قابل اعتماد (TEE) یا عنصر امن (SE)، مانند StrongBox باشد، پشتیبانی میکند.
- تأییدکنندههای هویت کاربر. تأیید حضور کاربر و/یا تأیید هویت موفقیتآمیز. اندروید از Gatekeeper برای تأیید هویت با پین/الگو/رمز عبور و از Fingerprint برای تأیید هویت با اثر انگشت پشتیبانی میکند. دستگاههایی که با اندروید ۹ و بالاتر عرضه میشوند میتوانند
BiometricPromptبه عنوان یک نقطه ادغام واحد برای اثر انگشت و بیومتریکهای اضافی استفاده کنند. این اجزا وضعیت تأیید هویت خود را از طریق یک کانال تأیید شده با سرویس keystore ارتباط میدهند. ( سیستم Android Keystore در سطح چارچوب نیز توسط سرویس keystore پشتیبانی میشود.)
هر یک از این اجزا مختص فروشنده است، اما پیادهسازی فروشنده برای برآورده کردن مشخصات رابط لایه انتزاعی سختافزار (HAL) و گذراندن آزمونهای مجموعه تست فروشنده (VTS) مربوطه لازم است.
پیادهسازیهای فروشنده معمولاً به دو بخش تقسیم میشوند که توسط یک مکانیسم ارتباطی خاص فروشنده به هم متصل میشوند:
- یک سرویس HAL به عنوان یک فرآیند سیستم اندروید اجرا میشود و درخواستهای Binder را از سیستم اندروید دریافت میکند.
- یک برنامه کاربردی قابل اعتماد (TA) در یک محیط امن اجرا میشود و عملیات امنیتی واقعی را انجام میدهد.
ثبت نام
در اولین بوت دستگاه پس از تنظیم مجدد کارخانه، همه احراز هویتکنندگان آماده دریافت ثبت نامهای اعتبار از کاربر هستند. کاربر ابتدا باید یک پین، الگو یا رمز عبور را با Gatekeeper (یا Weaver ، در صورت وجود) ثبت کند. این ثبت اولیه یک شناسه امن کاربر (SID) 64 بیتی تصادفی ایجاد میکند که به عنوان شناسه برای کاربر و به عنوان یک توکن اتصال برای محتوای رمزنگاری کاربر عمل میکند. این SID کاربر به صورت رمزنگاری به رمز عبور کاربر متصل است. احراز هویتهای موفقیتآمیز با Gatekeeper منجر به AuthTokenهایی میشود که حاوی SID کاربر برای آن رمز عبور هستند.
کاربری که میخواهد یک اعتبارنامه موجود را تغییر دهد، باید آن اعتبارنامه را ارائه دهد. اگر اعتبارنامه موجود با موفقیت تأیید شود، SID کاربر مرتبط با اعتبارنامه موجود به اعتبارنامه جدید منتقل میشود و کاربر را قادر میسازد تا پس از تغییر اعتبارنامه، به کلیدهای دسترسی ادامه دهد.
در برخی شرایط، مدیر دستگاه میتواند بدون ارائه اعتبارنامه موجود، یک ثبت نام غیرقابل اعتماد برای ثبت یک اعتبارنامه جدید انجام دهد. این به کاربر اجازه میدهد تا به دستگاه دسترسی پیدا کند، اما کلیدهای ایجاد شده تحت SID کاربر قدیمی برای همیشه از بین میروند.
احراز هویت
این بخش یک جریان احراز هویت معمول را شرح میدهد که شامل تعاملات بین اجزای متعدد در اندروید و محیط امن است. توجه داشته باشید که همه اجزای امن یک کلید مخفی HMAC (در هر بوت) را به اشتراک میگذارند که برای احراز هویت پیامهای یکدیگر از آن استفاده میکنند.
پس از اینکه کاربر اعتبارنامه خود را تنظیم کرد و یک SID کاربری به او اختصاص داده شد، میتواند احراز هویت را شروع کند، که با ارائه پین، الگو، رمز عبور، اثر انگشت یا سایر بیومتریکهای قوی توسط کاربر آغاز میشود. 
شکل ۱. جریان احراز هویت
- کاربر یک روش احراز هویت ارائه میدهد و سرویس مرتبط درخواستی را به سرویس HAL ارسال میکند.
- برای پین، الگو یا رمز عبور،
LockSettingsServiceدرخواستی بهgatekeeperdارسال میکند. - جریانهای احراز هویت مبتنی بر بیومتریک به نسخه اندروید بستگی دارند. در دستگاههایی که اندروید ۸.x و پایینتر دارند،
FingerprintServiceدرخواستی برایfingerprintdارسال میکند. در دستگاههایی که اندروید ۹ و بالاتر دارند،BiometricPromptبا استفاده از کلاسBiometric Managerمناسب، مانندFingerprintManagerیاFaceManager، درخواستی را به daemon بیومتریک مناسب (مثلاًfingerprintdبرای اثر انگشت یاfacedبرای چهره) ارسال میکند. صرف نظر از نسخه، احراز هویت بیومتریک پس از ارسال درخواست به صورت غیرهمزمان انجام میشود.
- برای پین، الگو یا رمز عبور،
- سرویس 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 مربوطه ارسال میکند.
- برای احراز هویت با پین/الگو/رمز عبور،
- این سرویس (daemon) یک AuthToken امضا شده دریافت میکند و آن را از طریق افزونهای به رابط Binder سرویس keystore به سرویس keystore ارسال میکند. (
gatekeeperdهمچنین قفل مجدد دستگاه و تغییر رمز عبور دستگاه را به سرویس keystore اطلاع میدهد.) - سرویس Keystore، توکنهای AuthToken را به KeyMint ارسال میکند و آنها را با استفاده از کلید مشترک با Gatekeeper و مؤلفه TEE بیومتریک پشتیبانیشده، تأیید میکند. KeyMint به مهر زمانی موجود در توکن به عنوان آخرین زمان احراز هویت اعتماد میکند و تصمیم آزادسازی کلید (برای اجازه دادن به یک برنامه برای استفاده از کلید) را بر اساس مهر زمانی میگیرد.
جریان احراز هویت نیازی به ارتباط مستقیم بین TAها در محیط امن ندارد: AuthTokenها از TA احراز هویتکننده به سرویس keystore2 در اندروید جریان مییابند، که به نوبه خود آنها را به TA KeyMint منتقل میکند. این امر همچنین به سرویس keystore2 اجازه میدهد تا به سرعت درخواستهایی را که محکوم به شکست هستند، رد کند، زیرا از AuthTokenهای موجود در سیستم آگاهی دارد و در نتیجه یک IPC بالقوه پرهزینه را در TEE صرفهجویی میکند.
فرمت AuthToken
قالب AuthToken توسط مشخصات AIDL در HardwareAuthToken.aidl ارائه شده است.
جریان بوت دستگاه
در هر بار بوت شدن دستگاه، کلید AuthToken HMAC باید تولید و با تمام اجزای TEE (Gatekeeper، KeyMint و trustlet های بیومتریک پشتیبانی شده) به اشتراک گذاشته شود. بنابراین، برای محافظت بیشتر در برابر حملات بازپخش، کلید HMAC باید هر بار که دستگاه دوباره راه اندازی میشود، به طور تصادفی تولید شود.
دو روش رایج وجود دارد که دستیاران مالی (TA) به این کلید HMAC مشترک دسترسی پیدا میکنند:
- توافق راز مشترک: سرویس
keystore2یک پروتکل توافق کلید چندطرفه را در هنگام راهاندازی دستگاه اجرا میکند و امکان استخراج امن کلید HMAC را بین TAهای شرکتکننده فراهم میکند. با این حال، TAهای شرکتکننده باید به یک راز از پیش مشترک دسترسی داشته باشند. - دسترسی مستقیم: TAهایی که در یک محیط امن قرار دارند، میتوانند از یک مکانیسم ارتباط بینپردازشی داخلی (که وابسته به پلتفرم است) برای به اشتراک گذاشتن کلید HMAC استفاده کنند.
در هر صورت، کلید HMAC هرگز نباید خارج از TEE در دسترس قرار گیرد.
سیستم عامل Trusty که در کنار اندروید اجرا میشود، نمونهای از TEE است، اما میتوان از TEE های دیگر نیز به جای آن استفاده کرد. Trusty از یک سیستم IPC داخلی برای ارتباط مستقیم بین KeyMint و Gatekeeper یا trustlet بیومتریک مناسب استفاده میکند. کلید HMAC منحصراً در KeyMint نگهداری میشود؛ Fingerprint و Gatekeeper برای هر بار استفاده، کلید را از KeyMint درخواست میکنند و مقدار را ذخیره یا ذخیره نمیکنند.
از آنجایی که برخی از TEEها فاقد زیرساخت IPC هستند، هیچ ارتباطی بین اپلتها در TEE برقرار نمیشود. این امر همچنین به سرویس keystore اجازه میدهد تا به سرعت درخواستهایی را که محکوم به شکست هستند، رد کند، زیرا از جدول احراز هویت در سیستم آگاهی دارد و در نتیجه یک IPC بالقوه پرهزینه را در TEE صرفهجویی میکند.