کنترل‌کننده

زیرسیستم Gatekeeper اصالت‌سنجی الگو/گذرواژه دستگاه را در «محیط اجرای امن» (TEE) انجام می‌دهد. Gatekeeper گذرواژه‌ها را بااستفاده از کلید مخفی با پشتیبانی سخت‌افزاری ثبت و تأیید می‌کند. علاوه‌براین، Gatekeeper تلاش‌های ناموفق متوالی برای درستی‌سنجی را محدود می‌کند و باید از ارائه خدمات به درخواست‌ها براساس زمان استراحت مشخص و تعداد مشخصی از تلاش‌های ناموفق متوالی خودداری کند.

وقتی کاربران گذرواژه‌هایشان را درستی‌سنجی می‌کنند، Gatekeeper یک کد اصالت‌سنجی صادر می‌کند که با کلید HMAC هر راه‌اندازی امضا شده است و فقط برای مؤلفه‌های امن دردسترس است، و این کد به Keystore با پشتیبانی سخت‌افزاری ارسال می‌شود. یعنی، یک کد اصالت‌سنجی Gatekeeper به Keystore اطلاع می‌دهد که کلیدهای محدود به اصالت‌سنجی (برای مثال، کلیدهایی که برنامه‌ها ایجاد کرده‌اند) می‌توانند توسط برنامه‌ها استفاده شوند.

معماری

«دروازه‌بان» شامل سه مؤلفه اصلی است:

• gatekeeperd (Gatekeeper daemon) — A C++ Binder service in Android that contains platform-independent logic implementing the IGateKeeperService AIDL interface, based on an underlying vendor-specific implementation of IGatekeeper.
• سرویس لایه انتزاعی سخت‌افزار (HAL) Gatekeeper — پیاده‌سازی مختص فروشنده از میانای IGatekeeper AIDL. این سرویس HAL در Android اجرا می‌شود، اما عملکرد اصلی Gatekeeper باید در محیطی امن اجرا شود، بنابراین معمولاً با Gatekeeper TA ارتباط برقرار می‌کند.
• برنامه مورداعتماد Gatekeeper‏ (TA) — پیاده‌سازی مختص فروشنده که در TEE اجرا می‌شود و درستی‌سنجی واقعی گذرواژه یا الگو را انجام می‌دهد.

‫LockSettingsService درخواستی (ازطریق Binder) ایجاد می‌کند که به دیمون gatekeeperd در سیستم‌عامل Android می‌رسد. سپس دیمون gatekeeperd درخواستی از سرویس HAL IGatekeeper می‌کند و این درخواست به‌نوبه خود به همتای Gatekeeper TA در TEE می‌رسد:

شکل ۱. جریان داده سطح بالا برای اصالت‌سنجی توسط GateKeeper.

دیمن gatekeeperd به میاناهای برنامه‌سازی کاربردی چارچوب Android امکان دسترسی به HAL را می‌دهد و در گزارش کردن اصالت‌سنجی‌های دستگاه به Keystore مشارکت می‌کند. دیمن gatekeeperd در فرایند خودش اجرا می‌شود و از سرور سیستم جدا است.

پیاده‌سازی HAL

دیمن gatekeeperd از IGatekeeper HAL برای تعامل با Gatekeeper TA زیربنایی برای اصالت‌سنجی گذرواژه استفاده می‌کند. پیاده‌سازی Gatekeeper TA باید بتواند حباب‌ها را امضا (ثبت‌نام) و تأیید کند. انتظار می‌رود همه پیاده‌سازی‌ها از قالب استاندارد برای کد اصالت‌سنجی (HardwareAuthToken) که در هر درستی‌سنجی موفق گذرواژه تولید می‌شود پیروی کنند. برای جزئیات مربوط به محتوا و معناشناسی HardwareAuthToken، به تعریف HardwareAuthToken.aidl مراجعه کنید.

پیاده‌سازی‌های فروشنده IGatekeeper HAL باید عملکردهای enroll و verify را پیاده‌سازی کند:

• روش enroll یک حباب گذرواژه را می‌گیرد، آن را امضا می‌کند، و امضا را به‌عنوان دسته برمی‌گرداند. حباب برگردانده‌شده (از تماس با enroll) باید ساختار نشان‌داده‌شده در system/gatekeeper/include/gatekeeper/password_handle.h را داشته باشد.
• تابع verify باید امضای تولیدشده توسط گذرواژه ارائه‌شده را مقایسه کند و مطمئن شود که با شناسه گذرواژه ثبت‌شده مطابقت دارد.

کلید مورداستفاده برای ثبت‌نام و درستی‌سنجی هرگز نباید تغییر کند و باید در هر راه‌اندازی دستگاه قابل‌استخراج مجدد باشد.

Trusty و پیاده‌سازی‌های دیگر

سیستم‌عامل Trusty سیستم‌عامل مورداعتماد متن‌باز Google برای محیط‌های «محیط اجرای امن» است و حاوی پیاده‌سازی تأییدشده Gatekeeper است. بااین‌حال، هر سیستم‌عامل TEE می‌تواند Gatekeeper را پیاده‌سازی کند، به‌شرطی که TEE به یک کلید پایدار با پشتوانه سخت‌افزاری و یک ساعت یکنواخت امن که در حالت تعلیق کار می‌کند دسترسی داشته باشد.

Trusty از یک سیستم IPC داخلی برای برقراری ارتباط مستقیم یک راز مشترک بین KeyMint (قبلاً Keymaster) و پیاده‌سازی Trusty از Gatekeeper (Trusty Gatekeeper) استفاده می‌کند. این رمز مشترک برای امضای نشانه‌های اصالت‌سنجی ارسال‌شده به Keystore برای ارائه گواهی‌های درستی‌سنجی گذرواژه استفاده می‌شود. Trusty Gatekeeper برای هر استفاده، کلید را از KeyMint درخواست می‌کند و مقدار را حفظ یا ذخیره موقت نمی‌کند. پیاده‌سازی‌ها می‌توانند این کلید خصوصی را به هر روشی که امنیت را به‌خطر نیندازد هم‌رسانی کنند.

کلید HMAC مورداستفاده برای ثبت‌نام و درستی‌سنجی گذرواژه‌ها فقط در Gatekeeper مشتق و نگهداری می‌شود.

Android یک پیاده‌سازی عمومی C++ Gatekeeper ارائه می‌دهد که برای تکمیل شدن فقط به افزودن روال‌های خاص دستگاه نیاز دارد؛ پیاده‌سازی Trusty براساس این است. برای پیاده‌سازی TEE Gatekeeper با کد مختص دستگاه برای TEE، به عملکردها و نظرات در system/gatekeeper/include/gatekeeper/gatekeeper.h مراجعه کنید. مسئولیت‌های اصلی پیاده‌سازی مطابق با خط‌مشی عبارت‌اند از:

• پیروی از IGatekeeper HAL.
• قالب نشان‌های اصالت‌سنجی برگردانده‌شده باید مطابق با مشخصات HardwareAuthToken باشد (در HardwareAuthToken.aidl شرح داده شده است).
• ‫TEE Gatekeeper باید بتواند بااستفاده از یکی از موارد زیر، کلید HMAC را با KeyMint هم‌رسانی کند:
  • توافق محرمانه مشترک: Gatekeeper می‌تواند با پیاده‌سازی ISharedSecret HAL در مذاکره کلید HMAC در هر راه‌اندازی شرکت کند. این امر مستلزم آن است که Gatekeeper و KeyMint هر دو به یک راز پیش‌اشتراکی مشترک دسترسی داشته باشند.
  • دسترسی مستقیم: Gatekeeper می‌تواند کلید HMAC را از KeyMint بااستفاده از سازوکار ارتباط میان‌پردازشی داخلی TEE، به‌صورت درخواستی یا در اولین استفاده (که پس‌از آن ذخیره می‌شود)، بازیابی کند.

شناسه‌های امن کاربر (SID)

شناسه امنیتی کاربر، نمایش TEE از کاربر است (بدون اتصال قوی به شناسه کاربر Android). هرگاه کاربر گذرواژه جدیدی را بدون ارائه گذرواژه قبلی ثبت کند، SID با تولیدکننده عدد شبه‌تصادفی رمزنگاری (PRNG) تولید می‌شود. این به‌عنوان ثبت‌نام مجدد غیرقابل‌اعتماد شناخته می‌شود و معمولاً فقط زمانی اتفاق می‌افتد که کاربر برای اولین‌بار گذرواژه یا الگو تنظیم می‌کند.

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

شناسه امنیتی کاربر در اصالت‌سنجی HMAC به‌همراه گذرواژه در دسته گذرواژه هنگام ثبت گذرواژه گنجانده می‌شود.

شناسه‌های امنیتی کاربر در HardwareAuthToken که توسط تابع verify() برگردانده شده است گنجانده شده‌اند و با همه کلیدهای Keystore محدود به اصالت‌سنجی مرتبط هستند (برای جزئیات درباره قالب HardwareAuthToken و Keystore، به اصالت‌سنجی مراجعه کنید).

توجه داشته باشید که چون تماس غیرقابل‌اعتماد با تابع enroll() شناسه امنیتی کاربر را تغییر می‌دهد، تماس باعث می‌شود کلیدهای محدود به آن گذرواژه بی‌استفاده شوند. مهاجمان می‌توانند گذرواژه دستگاه را تغییر دهند اگر سیستم‌عامل Android را کنترل کنند، اما در این فرایند کلیدهای حساس محافظت‌شده با ریشه را ازبین می‌برند.

محدود کردن درخواست

Gatekeeper باید بتواند تلاش‌های جستجوی فراگیر برای دسترسی به اطلاعات کاربری کاربر را به‌طور ایمن محدود کند. همان‌طور که در GatekeeperVerifyResponse.aidl نشان داده شده است، HAL امکان برگرداندن زمان استراحت را به میلی‌ثانیه فراهم می‌کند. زمان اتمام به مشتری اطلاع می‌دهد که تا زمانی که زمان اتمام سپری نشده است، دوباره با Gatekeeper تماس نگیرد. اگر مهلت معلقی وجود داشته باشد، Gatekeeper نباید به درخواست‌ها رسیدگی کند.

Gatekeeper باید قبل‌از تأیید گذرواژه کاربر، شمارنده خطا بنویسد. اگر درستی‌سنجی گذرواژه موفقیت‌آمیز باشد، شمارنده شکست باید پاک شود. این کار از حملاتی که با غیرفعال کردن MMC جاسازی‌شده (eMMC) پس‌از صدور تماس verify از محدودسازی جلوگیری می‌کنند، پیشگیری می‌کند. تابع enroll همچنین گذرواژه کاربر را (درصورت ارائه) تأیید می‌کند و باید به همان روش محدود شود.

اگر دستگاه از آن پشتیبانی می‌کند، اکیداً توصیه می‌شود که شمارنده خرابی در فضای ذخیره‌سازی ایمن نوشته شود. اگر دستگاه از رمزگذاری مبتنی بر فایل پشتیبانی نکند یا اگر فضای ذخیره‌سازی ایمن خیلی کند باشد، پیاده‌سازی‌ها ممکن است مستقیماً از «بلوک حافظه محافظت‌شده دربرابر بازپخش» (RPMB) استفاده کنند.