دروازه بان

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

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

معماری

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

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

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

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

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

پیاده‌سازی HAL

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

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

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

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

پیاده‌سازی‌های قابل اعتماد و سایر پیاده‌سازی‌ها

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

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

کلید HMAC که برای ثبت و تأیید رمزهای عبور استفاده می‌شود، منحصراً در Gatekeeper استخراج و نگهداری می‌شود.

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

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

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

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

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

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

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

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

درخواست تنظیم سرعت

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

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

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