بوت تایید شده نیاز به تایید رمزنگاری تمام کدهای اجرایی و داده هایی دارد که بخشی از نسخه اندرویدی است که قبل از استفاده بوت می شود. این شامل هسته (بارگیری شده از پارتیشن boot )، درخت دستگاه (بارگیری شده از پارتیشن dtbo )، پارتیشن system ، پارتیشن vendor و غیره است.
پارتیشن‌های کوچکی مانند boot و dtbo که فقط یک بار خوانده می‌شوند، معمولاً با بارگیری کل محتویات در حافظه و سپس محاسبه هش آن تأیید می‌شوند. سپس این مقدار هش محاسبه شده با مقدار هش مورد انتظار مقایسه می شود. اگر مقدار مطابقت نداشته باشد، Android بارگیری نمی‌شود. برای جزئیات بیشتر، Boot Flow را ببینید.
پارتیشن‌های بزرگتر که در حافظه قرار نمی‌گیرند (مانند سیستم‌های فایل) ممکن است از درخت هش استفاده کنند که در آن تأیید یک فرآیند پیوسته است که با بارگیری داده‌ها در حافظه انجام می‌شود. در این حالت، هش ریشه درخت هش در طول زمان اجرا محاسبه می‌شود و با مقدار هش ریشه مورد انتظار بررسی می‌شود. اندروید شامل درایور dm-verity برای تایید پارتیشن های بزرگتر است. اگر در نقطه ای هش ریشه محاسبه شده با مقدار هش ریشه مورد انتظار مطابقت نداشته باشد، از داده ها استفاده نمی شود و اندروید وارد حالت خطا می شود. برای جزئیات بیشتر، فساد dm-verity را ببینید.
هش های مورد انتظار معمولاً در انتهای یا ابتدای هر پارتیشن تأیید شده، در یک پارتیشن اختصاصی یا هر دو ذخیره می شوند. مهمتر از همه، این هش ها (به طور مستقیم یا غیر مستقیم) توسط ریشه اعتماد امضا می شوند. به عنوان مثال، پیاده سازی AVB از هر دو رویکرد پشتیبانی می کند، برای جزئیات بیشتر به Android Verified Boot مراجعه کنید.
حفاظت برگشتی
حتی با یک فرآیند به‌روزرسانی کاملاً ایمن، این امکان وجود دارد که یک اکسپلویت هسته اندرویدی غیردائم به صورت دستی نسخه قدیمی‌تر و آسیب‌پذیرتر اندروید را نصب کند، در نسخه آسیب‌پذیر راه‌اندازی مجدد شود و سپس از آن نسخه اندروید برای نصب یک اکسپلویت دائمی استفاده کند. از آنجا مهاجم به طور دائم مالک دستگاه است و می تواند هر کاری انجام دهد، از جمله غیرفعال کردن به روز رسانی ها.
حفاظت در برابر این دسته از حملات ، محافظت برگشتی نامیده می شود. محافظت برگشتی معمولاً با استفاده از فضای ذخیره‌سازی آشکار برای ضبط جدیدترین نسخه اندروید و امتناع از بوت کردن اندروید در صورتی که پایین‌تر از نسخه ضبط شده باشد، اجرا می‌شود. نسخه ها معمولاً بر اساس هر پارتیشن ردیابی می شوند.
برای جزئیات بیشتر در مورد نحوه عملکرد AVB از محافظت های برگشتی، به AVB README مراجعه کنید.
رسیدگی به خطاهای تایید
راستی‌آزمایی می‌تواند در زمان راه‌اندازی (مثلاً اگر هش محاسبه‌شده در پارتیشن boot با هش مورد انتظار مطابقت نداشته باشد) یا در زمان اجرا (مانند اگر dm-verity با خطای تأیید در پارتیشن system مواجه شود) با شکست مواجه شود. اگر تأیید در زمان بوت ناموفق باشد، دستگاه نمی تواند بوت شود و کاربر نهایی باید مراحل بازیابی دستگاه را طی کند.
اگر تأیید در زمان اجرا با شکست مواجه شود، جریان کمی پیچیده‌تر است. اگر دستگاه از dm-verity استفاده می کند، باید در حالت restart پیکربندی شود. در حالت restart ، اگر با خطای تأیید مواجه شد، دستگاه بلافاصله با یک پرچم مشخص برای نشان دادن دلیل راه اندازی مجدد می شود. بوت لودر باید متوجه این پرچم شود و dm-verity را برای استفاده از حالت خطای ورودی/خروجی ( eio ) روی آن تغییر دهد و تا زمانی که به‌روزرسانی جدید نصب نشود، در این حالت بماند.
هنگام بوت شدن در حالت eio ، دستگاه صفحه خطایی را نشان می دهد که به کاربر اطلاع می دهد که خرابی شناسایی شده است و ممکن است دستگاه به درستی کار نکند. صفحه نمایش داده می شود تا زمانی که کاربر آن را رد کند. در حالت eio درایور dm-verity دستگاه را مجددا راه اندازی نمی کند اگر با خطای تأیید مواجه شود، در عوض یک خطای EIO برگردانده می شود و برنامه باید با خطا مقابله کند.
هدف این است که یا به‌روزرسانی‌کننده سیستم اجرا شود (بنابراین سیستم‌عامل جدیدی بدون خطاهای خراب نصب شود) یا کاربر بتواند تا حد امکان اطلاعات خود را از دستگاه دریافت کند. هنگامی که سیستم عامل جدید نصب شد، بوت لودر متوجه سیستم عامل تازه نصب شده می شود و به حالت restart برمی گردد.