بوت را تأیید کنید

بوت تأیید شده مستلزم تأیید رمزنگاری تمام کدها و داده‌های اجرایی است که بخشی از نسخه اندروید در حال بوت شدن هستند، قبل از استفاده. این شامل هسته (بارگذاری شده از پارتیشن boot )، درخت دستگاه (بارگذاری شده از پارتیشن dtbo )، پارتیشن system ، پارتیشن vendor و غیره می‌شود.

پارتیشن‌های کوچک، مانند boot و dtbo ، که فقط یک بار خوانده می‌شوند، معمولاً با بارگذاری کل محتوا در حافظه و سپس محاسبه هش آن تأیید می‌شوند. این مقدار هش محاسبه شده سپس با مقدار هش مورد انتظار مقایسه می‌شود. اگر مقدار مطابقت نداشته باشد، اندروید بارگذاری نمی‌شود. برای جزئیات بیشتر، به Boot Flow مراجعه کنید.

پارتیشن‌های بزرگ‌تری که در حافظه جا نمی‌شوند (مانند سیستم‌های فایل) ممکن است از یک درخت هش استفاده کنند که در آن تأیید یک فرآیند مداوم است که همزمان با بارگذاری داده‌ها در حافظه اتفاق می‌افتد. در این حالت، هش ریشه درخت هش در طول زمان اجرا محاسبه می‌شود و با مقدار هش ریشه مورد انتظار بررسی می‌شود. اندروید درایور dm-verity را برای تأیید پارتیشن‌های بزرگ‌تر در نظر گرفته است. اگر در مقطعی هش ریشه محاسبه شده با مقدار هش ریشه مورد انتظار مطابقت نداشته باشد، داده‌ها استفاده نمی‌شوند و اندروید وارد حالت خطا می‌شود. برای جزئیات بیشتر، به dm-verity corruption مراجعه کنید.

هش‌های مورد انتظار معمولاً در انتها یا ابتدای هر پارتیشن تأیید شده، در یک پارتیشن اختصاصی یا هر دو ذخیره می‌شوند. نکته مهم این است که این هش‌ها (مستقیم یا غیرمستقیم) توسط ریشه اعتماد امضا می‌شوند. به عنوان مثال، پیاده‌سازی AVB از هر دو رویکرد پشتیبانی می‌کند، برای جزئیات بیشتر به Android Verified Boot مراجعه کنید.

محافظت در برابر بازگشت به حالت اولیه

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

محافظت در برابر این دسته از حملات، محافظت در برابر بازگشت به نسخه قبلی (Rollback Protection) نامیده می‌شود. محافظت در برابر بازگشت به نسخه قبلی معمولاً با استفاده از ذخیره‌سازی آشکار در برابر دستکاری (tamper-evident storage) برای ثبت جدیدترین نسخه اندروید و امتناع از بوت شدن اندروید در صورت پایین‌تر بودن آن از نسخه ثبت شده، پیاده‌سازی می‌شود. نسخه‌ها معمولاً بر اساس هر پارتیشن ردیابی می‌شوند.

برای جزئیات بیشتر در مورد نحوه مدیریت محافظت‌های برگشتی توسط AVB، به فایل راهنمای AVB مراجعه کنید.

مدیریت خطاهای تأیید

تأیید می‌تواند یا در زمان بوت شدن (مثلاً اگر هش محاسبه‌شده روی پارتیشن boot با هش مورد انتظار مطابقت نداشته باشد) یا در زمان اجرا (مثلاً اگر dm-verity با خطای تأیید روی پارتیشن system مواجه شود) با شکست مواجه شود. اگر تأیید در زمان بوت شدن با شکست مواجه شود، دستگاه نمی‌تواند بوت شود و کاربر نهایی باید مراحلی را برای بازیابی دستگاه طی کند.

اگر تأیید در زمان اجرا با شکست مواجه شود، روند کمی پیچیده‌تر می‌شود. اگر دستگاه از dm-verity استفاده می‌کند، باید در حالت restart پیکربندی شود. در حالت restart ، اگر با خطای تأیید مواجه شود، دستگاه بلافاصله با تنظیم یک پرچم خاص برای نشان دادن دلیل، مجدداً راه‌اندازی می‌شود. بوت لودر باید متوجه این پرچم شود و dm-verity را به حالت خطای ورودی/خروجی ( eio ) تغییر دهد و تا زمانی که به‌روزرسانی جدید نصب شود، در این حالت بماند.

هنگام بوت شدن در حالت eio ، دستگاه یک صفحه خطا نشان می‌دهد که به کاربر اطلاع می‌دهد که خرابی شناسایی شده است و ممکن است دستگاه به درستی کار نکند. این صفحه تا زمانی که کاربر آن را رد کند، نمایش داده می‌شود. در حالت eio ، درایور dm-verity در صورت مواجهه با خطای تأیید، دستگاه را مجدداً راه‌اندازی نمی‌کند، در عوض یک خطای EIO برمی‌گرداند و برنامه باید به رفع خطا بپردازد.

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