Bootloader می‌تواند Stage بعدی را پیدا کند، اما یک دستگاه مدرن باید مطمئن شود آن Stage دستکاری نشده است. اینجاست که SoC Secure Boot و Android Verified Boot به هم می‌رسند.

Secure Boot و AVB یک چیز نیستند

SoC Secure Boot: ROM → early firmware → boot stages
Android Verified Boot: bootloader → Android boot metadata/images/partitions

اولی معمولاً Vendor-specific است؛ دومی معماری استاندارد Android برای ادامه verification تا OS است.

Chain of Trust

Hardware Root of Trust
   ↓
Immutable ROM
   ↓ verifies
Early stage
   ↓ verifies
Main bootloader
   ↓ AVB
boot/vbmeta/system/vendor...

Signature و Hash

Hash تغییر Data را نشان می‌دهد، اما Hash جدید هم قابل‌جایگزینی است. Signature باعث می‌شود Hash/metadata فقط وقتی معتبر باشد که توسط Private Key مورداعتماد امضا شده و با Public Key معتبر Verify شود.

AVB چیست؟

Android 8 به بعد Android Verified Boot 2.0 یا AVB را ارائه می‌کند. libavb در Bootloader integrate می‌شود و verification partitionها، chained metadata و rollback protection را استاندارد می‌کند.

vbmeta

vbmeta یک تصویر executable نیست؛ container metadataهای AVB است. Descriptorها می‌توانند Hash یک partition، Hash Tree یا chain به vbmetaهای دیگر را مشخص کنند.

Root key → vbmeta
            ├─ hash → boot
            ├─ hash → init_boot
            ├─ chain → vendor vbmeta
            └─ hashtree metadata → large filesystems

dm-verity

برای partitionهای بزرگ مثل system/vendor، خواندن کامل image در Boot عملی نیست. dm-verity از Merkle hash tree استفاده می‌کند و Blockها را هنگام دسترسی verify می‌کند. Root hash آن باید از طریق AVB مورداعتماد باشد.

Rollback Protection

یک Image قدیمی می‌تواند Signature کاملاً معتبر داشته باشد اما vulnerability شناخته‌شده داشته باشد. Rollback index اجازه می‌دهد دستگاه نسخه پایین‌تر از حد ثبت‌شده را Reject کند.

Signature valid? YES
Rollback index acceptable? NO
→ reject old image

Locked / Unlocked

در Locked state فقط chain مورداعتماد باید Boot شود. Unlock اجازه Software سفارشی می‌دهد و معمولاً Data wipe و warning لازم دارد. AOSP Boot stateهایی مثل GREEN، YELLOW، ORANGE و RED را برای وضعیت‌های مختلف تعریف می‌کند.

A/B و AVB

در دستگاه A/B، Slot انتخاب‌شده باید Verify شود. Boot control metadata، successful flag و rollback metadata با Update flow هماهنگ‌اند.

Qualcomm/MediaTek قبل از AVB

قبل از AVB، Secure Boot Vendor شروع شده است: Qualcomm PBL Stage بعد را authenticate می‌کند و MediaTek BROM نیز در Secure configuration BL2/DA را verify می‌کند. Bootloader سطح بالاتر سپس Android images را با AVB می‌سنجد.

Flash شدن مساوی Boot شدن نیست

ممکن است ابزاری بتواند partition را بنویسد، اما Device Locked همان Image را به دلیل AVB رد کند. توان نوشتن و اجازه اجرای مورداعتماد دو policy جدا هستند.

EDL/BROM هم می‌توانند Secure باشند

ROM-level Download مسیر bypass ذاتی نیست. Qualcomm signed programmer و MediaTek DAA مثال‌هایی هستند که Recovery path را هم تحت policy اعتماد قرار می‌دهند.

Bootloader → AVB verify → valid?
                      ├─ yes → load Kernel
                      └─ no  → error/recovery policy

منابع رسمی برای مطالعه بیشتر

قبلی: Bootloaderبعدی: Boot Imagesبازگشت به مقالاتصفحه اصلی