Lennart Poettering پیشنهادی را برای نوسازی فرآیند بوت برای توزیع‌های لینوکس منتشر کرده است که هدف آن حل مشکلات موجود و ساده‌سازی سازماندهی یک بوت تأیید شده کامل است که قابلیت اطمینان هسته و محیط سیستم زیربنایی را تأیید می‌کند. تغییرات مورد نیاز برای پیاده سازی معماری جدید قبلاً در پایگاه کد systemd گنجانده شده است و مؤلفه هایی مانند systemd-stub، systemd-measure، systemd-cryptenroll، systemd-cryptsetup، systemd-pcrphase و systemd-creds را تحت تأثیر قرار می دهد.
تغییرات پیشنهادی به ایجاد یک تصویر جهانی واحد UKI (تصویر هسته یکپارچه)، ترکیب تصویر هسته لینوکس، یک کنترل کننده برای بارگیری هسته از UEFI (خرد بوت UEFI) و محیط سیستم initrd بارگذاری شده در حافظه، که برای مقداردهی اولیه در مرحله قبل از نصب root FS. به جای یک تصویر دیسک RAM initrd، کل سیستم را می توان در UKI بسته بندی کرد، که به شما امکان می دهد محیط های سیستمی کاملاً تأیید شده را در RAM ایجاد کنید. تصویر UKI به عنوان یک فایل اجرایی با فرمت PE فرمت شده است، که نه تنها با استفاده از بوت لودرهای سنتی قابل بارگیری است، بلکه می تواند مستقیماً از سیستم عامل UEFI نیز فراخوانی شود.
امکان تماس از UEFI به شما امکان می دهد از بررسی یکپارچگی امضای دیجیتال استفاده کنید که نه تنها هسته، بلکه محتویات initrd را نیز پوشش می دهد. در عین حال، پشتیبانی از تماس از بوت لودرهای سنتی به شما این امکان را می دهد که ویژگی هایی مانند تحویل چندین نسخه از هسته و بازگشت خودکار به یک هسته در حال کار را در صورت شناسایی مشکلات با هسته جدید پس از نصب به روز رسانی حفظ کنید.
در حال حاضر، در اکثر توزیع‌های لینوکس، فرآیند اولیه‌سازی از زنجیره «سیستم‌افزار → لایه شیم مایکروسافت با امضای دیجیتالی → بارگذار بوت GRUB امضا شده دیجیتالی توسط توزیع → هسته لینوکس با امضای دیجیتالی → محیط initrd بدون امضا → root FS» استفاده می‌کند. فقدان تأیید initrd در توزیع‌های سنتی مشکلات امنیتی ایجاد می‌کند، زیرا از جمله موارد دیگر، در این محیط کلیدهای رمزگشایی سیستم فایل ریشه بازیابی می‌شوند.
تأیید تصویر initrd پشتیبانی نمی‌شود زیرا این فایل در سیستم محلی کاربر تولید می‌شود و نمی‌تواند با امضای دیجیتال کیت توزیع تأیید شود، که سازماندهی تأیید را هنگام استفاده از حالت SecureBoot بسیار پیچیده می‌کند (برای تأیید initrd، کاربر باید کلیدهای خود را تولید کند و آنها را در سیستم عامل UEFI بارگذاری کند). علاوه بر این، سازمان راه‌اندازی فعلی اجازه استفاده از اطلاعات ثبت‌کننده‌های TPM PCR (Platform Configuration Register) را برای کنترل یکپارچگی اجزای فضای کاربر به غیر از shim، grub و هسته نمی‌دهد. از جمله مشکلات موجود، پیچیدگی به روز رسانی بوت لودر و عدم محدودیت دسترسی به کلیدهای موجود در TPM برای نسخه های قدیمی سیستم عامل که پس از نصب آپدیت نامربوط شده اند نیز ذکر شده است.
اهداف اصلی معرفی معماری جدید بارگذاری عبارتند از:
- ارائه یک فرآیند بوت کاملاً تأیید شده که از سیستم عامل تا فضای کاربر را در بر می گیرد و اعتبار و یکپارچگی اجزای بارگیری شده را تأیید می کند.
- پیوند دادن منابع کنترل شده به رجیسترهای TPM PCR، جدا شده توسط مالک.
- امکان پیش محاسبه مقادیر PCR بر اساس هسته، initrd، پیکربندی و شناسه سیستم محلی مورد استفاده در هنگام بوت.
- محافظت در برابر حملات بازگشتی مرتبط با بازگشت به نسخه آسیب پذیر قبلی سیستم.
- ساده سازی و افزایش قابلیت اطمینان به روز رسانی.
- پشتیبانی از به‌روزرسانی‌های سیستم‌عامل که نیازی به استفاده مجدد یا ارائه محلی منابع محافظت‌شده با TPM ندارند.
- سیستم برای تأیید صحت سیستم عامل بارگذاری شده و تنظیمات آماده صدور گواهی از راه دور است.
- توانایی پیوست کردن داده های حساس به مراحل بوت خاص، به عنوان مثال، استخراج کلیدهای رمزگذاری برای سیستم فایل ریشه از TPM.
- ارائه یک فرآیند ایمن، خودکار و بدون کاربر برای باز کردن قفل کلیدها برای رمزگشایی درایو پارتیشن ریشه.
- استفاده از تراشه هایی که از مشخصات TPM 2.0 پشتیبانی می کنند، با قابلیت بازگشت به سیستم های بدون TPM.
منبع: opennet.ru