دروازه بان

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

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

معماری

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

• gatekeeperd (دیمون دروازه بان). یک سرویس بایندر C++ حاوی منطق مستقل از پلتفرم و متناظر با رابط جاوا GateKeeperService .
• لایه انتزاعی سخت افزار Gatekeeper (HAL) . رابط HAL در hardware/libhardware/include/hardware/gatekeeper.h و ماژول پیاده سازی.
• دروازه بان (TEE) . همتای TEE gatekeeperd . اجرای Gatekeeper مبتنی بر TEE.

Gatekeeper به پیاده‌سازی Gatekeeper HAL (مخصوصاً توابع در hardware/libhardware/include/hardware/gatekeeper.h ) و مؤلفه Gatekeeper خاص TEE (بر اساس بخشی از فایل هدر system/gatekeeper/include/gatekeeper/gatekeeper.h نیاز دارد. که شامل توابع مجازی خالص برای ایجاد/دسترسی به کلیدها و امضاهای محاسباتی است).

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

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

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

اجرای HAL

شبح gatekeeperd از HAL برای تعامل با همتای TEE gatekeeperd برای احراز هویت رمز عبور استفاده می کند. اجرای HAL باید بتواند حباب ها را امضا (ثبت نام) و تأیید کند. انتظار می‌رود همه پیاده‌سازی‌ها به فرمت استاندارد نشانه احراز هویت (AuthToken) که در هر تأیید موفقیت آمیز رمز عبور ایجاد می‌شود، پایبند باشند. برای جزئیات بیشتر در مورد محتوا و معنای AuthToken، به قالب AuthToken مراجعه کنید.

اجرای فایل هدر hardware/libhardware/include/hardware/gatekeeper.h باید توابع enroll و verify اجرا کند:

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

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

اجراهای قابل اعتماد و دیگر

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

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

کلید HMAC که برای ثبت و تأیید رمزهای عبور استفاده می شود، مشتق شده و تنها در GateKeeper نگهداری می شود.

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

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

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

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

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

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

درخواست throttling

GateKeeper باید بتواند به‌طور ایمن تلاش‌های brute-force را در یک اعتبار کاربری کنترل کند. همانطور که در hardware/libhardware/include/hardware/gatekeeper.h نشان داده شده است، HAL امکان بازگرداندن مهلت زمانی را در میلی ثانیه فراهم می کند. مهلت زمانی به مشتری اطلاع می دهد که دیگر با GateKeeper تماس نگیرد تا زمانی که مهلت سپری شده باشد. GateKeeper نباید درخواست‌ها را سرویس دهد اگر یک بازه زمانی معلق وجود دارد.

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

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