دروازه بان

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

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

معماری

دروازه بان شامل سه جزء اصلی است:

• gatekeeperd (شیب دروازه‌بان) - یک سرویس C++ Binder در Android که حاوی منطق مستقل از پلتفرم است که رابط IGateKeeperService AIDL را بر اساس پیاده‌سازی IGatekeeper خاص فروشنده زیربنایی اجرا می‌کند.
• سرویس لایه انتزاعی سخت افزار Gatekeeper (HAL) - یک پیاده سازی خاص فروشنده از رابط IGatekeeper AIDL. این سرویس HAL در اندروید اجرا می‌شود، اما عملکرد اصلی Gatekeeper باید در یک محیط امن اجرا شود، بنابراین معمولاً با Gatekeeper TA ارتباط برقرار می‌کند.
• Gatekeeper Trusted Application (TA) - یک پیاده سازی خاص فروشنده است که در TEE اجرا می شود و رمز عبور واقعی یا تأیید الگو را انجام می دهد.

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

شکل 1. جریان داده در سطح بالا برای احراز هویت توسط GateKeeper.

شبح gatekeeperd به APIهای فریمورک اندروید دسترسی به 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 سیستم عامل منبع باز مورد اعتماد Google برای محیط های TEE است و شامل اجرای تایید شده Gatekeeper است. با این حال، هر سیستم‌عامل TEE می‌تواند Gatekeeper را پیاده‌سازی کند تا زمانی که TEE به یک کلید ثابت سخت‌افزاری و یک ساعت ایمن و یکنواخت که در حالت تعلیق تیک تاک می‌کند، دسترسی داشته باشد.

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

کلید HMAC که برای ثبت نام و تأیید گذرواژه ها استفاده می شود، مشتق شده و صرفاً در Gatekeeper نگهداری می شود.

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

• پایبندی به IGatekeeper HAL.
• نشانه های احراز هویت برگشتی باید مطابق با مشخصات HardwareAuthToken (شرح شده در Authentication ) قالب بندی شوند.
• TEE Gatekeeper باید بتواند یک کلید HMAC را با KeyMint به اشتراک بگذارد، چه با درخواست کلید از طریق IPC TEE در صورت تقاضا یا حفظ یک حافظه پنهان معتبر از مقدار در هر زمان.

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

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

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

SID کاربر در احراز هویت HMAC به همراه رمز عبور در دسته گذرواژه هنگام ثبت رمز وارد می شود.

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

توجه داشته باشید که از آنجایی که یک فراخوانی نامعتبر به تابع enroll() SID کاربر را تغییر می‌دهد، این فراخوانی کلیدهای متصل به آن رمز عبور را بی‌استفاده می‌کند. مهاجمان در صورت کنترل سیستم عامل اندروید می توانند رمز عبور دستگاه را تغییر دهند، اما در این فرآیند کلیدهای حساس و محافظت شده از ریشه را از بین می برند.

درخواست throttling

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

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

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