در این مقاله ادامه زنجیره اعتماد ورود AVB vbmeta و dm-verity Rollback Protection Locked و Unlocked

تا اینجا دیدیم Bootloader می تواند مرحله بعد را پیدا کند و آن را در RAM قرار دهد. اما در یک گوشی امن فقط پیدا شدن یک Image کافی نیست. سیستم باید مطمئن شود کدی که قرار است اجرا شود همان کدی است که سازنده یا یک Root of Trust معتبر اجازه اجرای آن را داده است.

این بررسی از Boot ROM شروع شده و تا Android ادامه پیدا می کند. در بخش های ابتدایی، Secure Boot خود SoC مسئول اعتماد به Firmware و Boot Stageهای بعدی است. وقتی به Bootloader Android می رسیم، Android Verified Boot یا AVB ادامه همین زنجیره را برای Imageها و پارتیشن های Android بر عهده می گیرد.

یک زنجیره، چند مرحله اعتماد

Hardware Root of Trust
        ↓
Boot ROM
        ↓ verifies
Early Bootloader
        ↓ verifies
Main Bootloader
        ↓ AVB
Android boot images / partitions

هر مرحله قبل از تحویل کنترل به مرحله بعد باید بتواند به آن اعتماد کند. اگر یکی از حلقه ها بدون بررسی اجرا شود، مهاجم می تواند همان نقطه را جایگزین کند و تمام بررسی های بعدی را بی اثر کند.

Hash و Signature، دو نقش متفاوت

Hash مثل اثر انگشت Data است. اگر حتی یک بخش کوچک از Image عوض شود، Hash آن هم تغییر می کند. اما Hash به تنهایی هویت سازنده Image را ثابت نمی کند، چون مهاجم می تواند هم Image و هم Hash جدید را جایگزین کند.

اینجاست که Signature وارد می شود. Image یا Metadata با Private Key امضا می شود و Bootloader با Public Key مورد اعتماد بررسی می کند که Signature معتبر باشد. به این ترتیب هم تغییر Data قابل تشخیص است و هم منبع اعتماد مشخص می شود.

AVB، ادامه Verification در بخش Android

Android Verified Boot یا AVB پیاده سازی مرجع Verified Boot در Android 8 و جدیدتر است. Bootloader با استفاده از libavb می تواند Metadata مربوط به Imageها، زنجیره های Verification و Rollback Protection را بررسی کند.

پس Secure Boot و AVB دقیقا یک چیز نیستند. Secure Boot معمولا از ROM و Firmware اولیه SoC شروع می شود، AVB در لایه بالاتر زنجیره اعتماد را داخل دنیای Android ادامه می دهد. 

SoC Secure Boot
ROM → firmware → boot stages

Android Verified Boot
Bootloader → vbmeta → Android images / partitions

vbmeta، نقشه امنیتی AVB

vbmeta یک Kernel یا Bootloader اجرایی نیست. این Image حاوی Metadata موردنیاز AVB است و به Bootloader می گوید چه چیزهایی باید Verify شوند و اعتماد چگونه به پارتیشن های دیگر ادامه پیدا کند. 

Trusted key
    ↓
  vbmeta
    ├─ hash → boot
    ├─ hash → init_boot
    ├─ chain → vendor vbmeta
    └─ hashtree metadata → large partitions

برای Imageهای کوچک می توان Hash را مستقیما بررسی کرد. اما برای پارتیشن های بزرگ مثل system یا vendor، خواندن تمام محتوا هنگام Boot منطقی نیست. Android برای این بخش از dm-verity استفاده می کند.

dm-verity، بررسی Data هنگام استفاده

dm-verity یک Hash Tree برای Blockهای پارتیشن می سازد. Root Hash این درخت از مسیر مورد اعتماد AVB می آید. بعد در زمان کار، وقتی Blockی خوانده می شود Integrity آن با این درخت بررسی می شود.

به این ترتیب Verified Boot فقط لحظه شروع Kernel را پوشش نمی دهد، Data روی Filesystemهای مهم هم می تواند هنگام دسترسی بررسی شود.

🛠 Flash شدن با Boot شدن یکی نیست

ممکن است ابزار تعمیر یا Fastboot بتواند یک Image را روی پارتیشن بنویسد، اما دستگاه Locked همان Image را هنگام Boot به دلیل AVB رد کند. توان نوشتن روی Storage و اجازه اجرای کد مورد اعتماد دو Policy جدا هستند.

Rollback Protection، جلوگیری از برگشت به نسخه آسیب پذیر

یک Firmware قدیمی ممکن است Signature کاملا معتبر داشته باشد، چون واقعا توسط سازنده امضا شده است. اما همان نسخه می تواند یک Vulnerability شناخته شده داشته باشد.

Rollback Protection برای همین ساخته شده است. سیستم یک Rollback Index یا اطلاعات معادل را در Storage امن نگه می دارد و اجازه نمی دهد دستگاه به نسخه ای پایین تر از حد مجاز برگردد. 

Signature valid?        YES
Version acceptable?     NO
                         ↓
                   Reject image

Locked و Unlocked، تغییر سیاست اعتماد

در حالت Locked، Bootloader باید فقط Chain مورد اعتماد را اجرا کند. Unlock کردن Bootloader برای اجرای Software سفارشی استفاده می شود و معمولا با تایید کاربر و پاک شدن Data همراه است.

در حالت Unlocked زنجیره اعتماد کارخانه دیگر همان ضمانت قبلی را ندارد، به همین دلیل Android Verified Boot وضعیت دستگاه را متفاوت گزارش می کند. این به معنی خاموش شدن همه مکانیزم های امنیتی Android نیست، بلکه Policy مربوط به اجازه Boot تغییر کرده است.

🔍 عمیق تر بشویم، GREEN و YELLOW و ORANGE دقیقا چه هستند

Android برای Verified Boot State چند وضعیت شناخته شده دارد. GREEN به زنجیره اعتماد کامل با Root مورد اعتماد سازنده اشاره می کند. ORANGE معمولا برای Bootloader باز شده است. YELLOW می تواند زمانی دیده شود که دستگاه Locked است اما از یک Root of Trust سفارشی مورد اعتماد کاربر استفاده می کند. 

Locked + manufacturer root → GREEN
Locked + user root         → YELLOW, if supported
Unlocked                   → ORANGE
Verification failed        → RED / failure state

پشتیبانی از Root of Trust قابل تنظیم توسط کاربر روی همه دستگاه ها اجباری نیست. بنابراین Custom OS همیشه به معنی یک رفتار یکسان روی تمام گوشی ها نیست.

Recovery path هم می تواند تحت Secure Boot باشد

EDL در Qualcomm یا BROM Download Mode در MediaTek ذاتا مسیر دور زدن امنیت نیستند. روی دستگاه های امن، Programmer در Qualcomm یا Download Agent در MediaTek می تواند قبل از اجرا نیاز به Authentication داشته باشد.

این نکته مهم است، چون همان Root of Trust که Normal Boot را محافظت می کند می تواند Recovery و Flash path را هم محدود کند.

⭐ چیزی که از این مقاله باید بماند

Boot امن یک بررسی واحد نیست، یک زنجیره است. ROM به Bootloader اعتماد می دهد، Bootloader با AVB اعتماد را به Imageها و پارتیشن های Android ادامه می دهد، dm-verity Data را هنگام استفاده بررسی می کند و Rollback Protection جلوی بازگشت به نسخه آسیب پذیر را می گیرد.

واژه نامه کوتاه

AVB
Android Verified Boot، سازوکار استاندارد Android برای Verification زنجیره Boot و پارتیشن ها.
vbmeta
Image حاوی Metadata مربوط به AVB و زنجیره Verification.
dm-verity
مکانیزم Integrity برای بررسی Blockهای پارتیشن هنگام خواندن.
Rollback Protection
جلوگیری از Boot نسخه قدیمی تر و احتمالا آسیب پذیر.
Root of Trust
نقطه اولیه اعتماد که کل زنجیره Verification به آن متکی است.

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