تأیید بوت

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

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

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

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

محافظت در برابر برگشت

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

محافظت در برابر این دسته از حملات Rollback Protection نامیده می شود. محافظت در برابر برگشت به طور معمول با استفاده از فضای ذخیره سازی قابل اثبات برای ضبط جدیدترین نسخه Android و امتناع از راه اندازی Android در صورت پایین بودن از نسخه ضبط شده ، اجرا می شود. نسخه ها معمولاً بر اساس هر قسمت تقسیم می شوند.

برای جزئیات بیشتر در مورد چگونگی برخورد AVB با حفاظت از بازگشت ، به AVB README مراجعه کنید .

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

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

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

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

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