Secure Boot: مرز باریک بین امضای درست و دستگاه امن
خلاصهٔ کاملتر
قبل از اینکه هیچ سیستمعاملی مثل لینوکس بالا بیاد، یه چیزی باید بایتهای اول رو از حافظه انتخاب کنه و کنترل رو بهشون بده؛ این قدم اول تقریباً هیچکدوم از دفاعهای معمول رو نداره. پایهی این اعتماد یه حافظهی فقطخواندنی غیرقابلتغییر (ROM) بههمراه یه بخش یهبار-برنامهریزیشونده (OTP) هست که بهش میگن Root of Trust. Secure Boot، Measured Boot و Remote Attestation هر سه از همین پایه استفاده میکنن: اولی میگه مرحلهی بعد مجازه یا نه، دومی انتقال رو ثبت میکنه، سومی مدرکش رو امضا میکنه.
نکتهی مرکزی مقاله اینه که یه امضای معتبر خیلی کمتر از چیزیه که فکرشو میکنیم ثابت میکنه. مثلاً معلوم نمیکنه همهی بایتهایی که لودر بعداً میخونه واقعاً داخل همون امضا بودن، یا اینکه امضاکننده همین ایمیج رو برای همین تراشه و همین نسخه در نظر داشته، یا اینکه ایمیج آپدیته، یا حتی اینکه بافر تأییدشده تا لحظهی اجرا دستنخورده مونده. نویسنده این فرق رو با دو مفهوم authentication (آیا امضا معتبره) و validation (آیا این ایمیج، نسخه و سیاست درسته) روشن میکنه.
برای اینکه بحث عینیتر بشه، نویسنده یه فرضیهی حمله میسازه: مهاجمی که به فلش خارجی یا بستهی آپدیت دسترسی داره، میتونه دستگاه رو فیزیکی ریست کنه و شاید تو یه مرحلهی قابلتغییر کد اجرا کنه، ولی نمیتونه امضای تولید رو جعل کنه یا ROM/فیوزها رو عوض کنه. تو این مدل، Secure Boot جلوی جایگزینی دائمی firmware و برگشت به نسخهی قدیمی (rollback) رو میگیره، ولی جلوی اکسپلویت شبکهای روی firmware اصیل رو نمیگیره.
بهعنوان یه نمونهی واقعی، نویسنده زنجیرهی بوت کوالکام رو نشون میده: بوتلودر اولیه (PBL) روی ROM اجرا میشه، بعد موتور TME ایمیجهای بعدی مثل XBL-SC رو تأیید میکنه و این زنجیره تا Android Verified Boot (AVB) و ساختار امضاشدهی VBMeta ادامه پیدا میکنه که پارتیشنهای سیستم رو با dm-verity (یعنی چک بلوکبهبلوک فایلسیستم موقع خوندن) تأیید میکنه. نویسنده تأکید میکنه برچسبها تو هر وندور فرق میکنه ولی منطق تأیید-و-تحویل زیرش یکیه.
چون یه طرف راه دور نمیتونه مستقیم ببینه تو بوت چی گذشته، Remote Attestation وارد بازی میشه: دستگاه یه مدرک امضاشده از اندازهگیریها به همراه یه nonce (یعنی یه عدد یهبارمصرف که جلوی replay رو میگیره) میفرسته و طرف تأییدکننده اینها رو با مقادیر مرجع مقایسه میکنه. برای دستگاههای ارزونتر که TPM ندارن، نویسنده مفهوم DICE رو معرفی میکنه: یه راز یکتای هر دستگاه (UDS) با اندازهگیری کد بعدی (TCI) ترکیب میشه و یه هویت رمزنگاریشدهی مخصوص همون ترکیب کد و سختافزار (CDI) میسازه.
نکات کلیدی:
- امضای معتبر فقط ثابت میکنه یه کلید مجاز اون بایتها رو امضا کرده، نه اینکه کد برای همین دستگاه، نسخه و لحظه درسته
- Secure Boot، Measured Boot و Remote Attestation سه نقش جدان: مجازسازی، ثبت، و گزارش امضاشده برای طرف بیرونی
- rollback protection با یه شمارندهی یکطرفه تو eFuse/OTP انجام میشه؛ باید برای هر کامپوننت جدا باشه
- تو زنجیرهی کوالکام، PBL و TME تا Android Verified Boot (VBMeta) و dm-verity همین قرارداد امضا-و-تحویل رو تکرار میکنن
- DICE با ترکیب راز یکتای دستگاه (UDS) و اندازهگیری کد (TCI) یه هویت رمزنگاریشده (CDI) میسازه، برای دستگاههای بدون TPM
