سوالی که اخیراً در بحث پیرامون انطباق با قانون سایبری (CRA) مطرح شد، این بود که آیا بوت امن (Secure Boot) واقعاً الزامی است یا صرفاً توصیه می‌شود. پاسخ کوتاه این است: بوت امن یک ضرورت است؛ زیرا بدون آن، هیچ‌یک از دیگر اقدامات امنیتی شما به‌درستی کار نخواهند کرد.
دستگاهی که فریم‌ور تأییدنشده‌ای را بوت می‌کند، دستگاهی است که مهاجم می‌تواند کنترل کامل آن را به‌دست بگیرد؛ فرقی نمی‌کند که معماری امنیتی شما تا چه حد قوی باشد.
وقتی دستگاهی بدون بوت امن راه‌اندازی می‌شود چه اتفاقی می‌افتد
هنگامی که میکروکنترلر شما روشن می‌شود، اجرای کد را از یک مکان حافظه مشخص آغاز می‌کند. در بیشتر پلتفرم‌های توکار، این بخش بوت‌لودر است؛ کد کوچکی که سخت‌افزار را مقداردهی اولیه کرده و فریم‌ور اصلی برنامه را بارگذاری می‌کند.
بدون بوت امن، بوت‌لودر هر فریم‌وری را که در آدرس مورد انتظار پیدا کند، بارگذاری می‌کند. این بخش بررسی نمی‌کند که آیا آن فریم‌ور توسط شما نوشته شده است یا خیر، از زمان عرضه‌تان تاکنون تغییر یافته است یا خیر، و آیا به هیچ وجه اصالت دارد یا نه. بوت‌لودر صرفاً آن را اجرا می‌کند.
این یعنی مهاجم می‌تواند از طریق کانال به‌روزرسانی فریم‌ور، رابط دیباگ، دسترسی فیزیکی یا وجود یک آسیب‌پذیری در مکانیزم به‌روزرسانی، حافظه فلش دستگاه شما را بنویسد و فریم‌ور دلخواه خود را جایگزین کند. دستگاه بدون هیچ‌گونه اعتراضی آن را بوت می‌کند. در ظاهر هم هم‌چنان عادی به نظر می‌رسد، اما در واقع در حال اجرای کد مهاجم است.
مهاجم نیازی به شکستن رمزگذاری شما ندارد و حتی به کلیدهای خصوصی شما احتیاج پیدا نمی‌کند. او فقط باید فریم‌ور خود را روی دستگاه قرار دهد و دستگاه آن را اجرا خواهد کرد.
این یک سناریوی فرضی نیست. این روش، حمله استاندارد علیه دستگاه‌های اینترنت اشیایی است که فاقد مکانیزم تأیید یکپارچگی فریم‌ور هستند. بات‌نت میرای (Mirai) که زیرساخت‌های مهم اینترنت را در سال ۲۰۱۶ از کار انداخت، تا حد زیادی روی دستگاه‌هایی ساخته شده بود که اصلاح فریم‌ور در آن‌ها بسیار آسان بود.
بوت امن چگونه کار می‌کند: زنجیره اعتماد
بوت امن با وادار کردن دستگاه به بررسی اصالت فریم‌ور پیش از اجرای آن، این مشکل را حل می‌کند. این مکانیزم یک زنجیره اعتماد رمزنگاری‌شده است که از سطح سخت‌افزار شروع می‌شود.
در ادامه می‌بینید که این زنجیره گام‌به‌گام چگونه کار می‌کند.
گام اول
ریشه اعتماد در سخت‌افزار. این فرآیند با چیزی شروع می‌شود که پس از ساخت قابل تغییر نیست: هش کلید عمومی که روی حافظه قابل برنامه‌ریزی یک‌بارمصرف (OTP) سوزانده شده است، یا کلیدی که در عناصر امنیتی سخت‌افزاری روی تراشه ذخیره می‌شود. این همان ریشه اعتماد سخت‌افزاری است. این بخش، لنگر کل زنجیره محسوب می‌شود؛ یعنی تنها چیزی که مهاجم نمی‌تواند آن را جایگزین کند.
گام دوم
تأیید بوت‌لودر. وقتی دستگاه روشن می‌شود، کد بوت مرحله اول (که در حافظه ROM قرار دارد و غیرقابل تغییر است) بوت‌لودر را از روی حافظه فلش می‌خواند و امضای رمزنگاری آن را با کلید عمومی موجود در حافظه OTP مقایسه می‌کند. اگر امضا معتبر باشد، بوت‌لودر اصالت دارد و اجرای کد ادامه می‌یابد. اگر امضا مطابقت نداشته باشد، فرآیند بوت متوقف می‌شود.
گام سوم
تأیید فریم‌ور برنامه. بوت‌لودر که اکنون اعتبارش تأیید شده است، همین بررسی را روی فریم‌ور اصلی برنامه انجام می‌دهد. این بخش تصویر فریم‌ور را می‌خواند، امضای آن را با یک کلید عمومی معتبر تطبیق می‌دهد و تنها در صورت اعتبار امضا، اجازه اجرای برنامه را صادر می‌کند.
گام چهارم
ادامه زنجیره. هر جزء تأییدشده می‌تواند زنجیره را فراتر ببرد؛ مواردی مانند تأیید داده‌های پیکربندی، بررسی نسخه‌های نرم‌افزاری و اعتبارسنجی بسته‌های به‌روزرسانی پیش از اعمال آن‌ها.
نتیجه این است که دستگاه تنها کدهایی را اجرا می‌کند که با کلید خصوصی شما امضا شده باشند. مهاجمی که فریم‌ور شما را با نسخه ساخت خودش جایگزین کند، نمی‌تواند آن را با کلید شما امضا کند. دستگاه آن را پس می‌زند و از بوت شدن خودداری می‌کند.
چرا قانون CRA بوت امن را به‌عنوان یک مبنا در نظر می‌گیرد
پیوست اول (Annex I) قانون سایبری (CRA) تولیدکنندگان را ملزم می‌کند تا یکپارچگی نرم‌افزارهای در حال اجرا روی محصولات متصل را تضمین کنند. نیاز خاص این قانون آن است که محصولات باید شامل مکانیزم‌هایی برای بررسی اصالت و یکپارچگی نرم‌افزار باشند؛ هم در زمان بوت و هم در طول به‌روزرسانی‌ها.
بوت امن نیاز زمان بوت را برآورده می‌کند. بدون آن، هیچ مبنایی وجود ندارد که ادعا کنید نرم‌افزار در حال اجرا روی دستگاه ارسالی، همان نرم‌افزاری است که قصد داشتید ارسال کنید.
به همین دلیل است که CRA بوت امن را نه یک ویژگی امنیتی پیشرفته، بلکه یک پایه اساسی می‌داند؛ یعنی حداقل زیرساختی که بدون آن همه چیز غیرقابل اعتماد خواهد بود. ارتباطات رمزگذاری‌شده تنها زمانی معنا پیدا می‌کنند که بتوانید اعتماد کنید دستگاهی که ارتباط را برقرار می‌کند، در حال اجرای فریم‌ور قانونی است. هویت منحصربه‌فرد دستگاه نیز تنها زمانی معتبر است که نتوان آن را به همراه تعویض فریم‌ور جایگزین کرد.
بوت امن پیش‌نیازی است که بقیه معماری امنیتی را قابل اعتماد می‌سازد.
پیاده‌سازی روی تراشه‌های Nordic nRF و STM32
Nordic nRF (مدل‌های nRF5340، nRF9160 و سری nRF52)
معماری امنیتی نوردیک بر پایه محیط اجرای قابل اعتماد (TrustZone-M روی هسته‌های Cortex-M33) و NSIB (بوت‌لودر تغییرناپذیر امن نوردیک) استوار است. NSIB در ناحیه معادل ROM دستگاه قرار دارد و ریشه اعتماد سخت‌افزاری در این پلتفرم‌ها محسوب می‌شود.
زنجیره بوت امن معمولی در nRF به این صورت است:
- NSIB بوت‌لودر مرحله اول (MCUboot) را با استفاده از یک کلید عمومی تعبیه‌شده در واحد مدیریت کلید (KMU) یا ثبات‌های UICR دستگاه تأیید می‌کند.
- MCUboot پیش از بارگذاری تصویر برنامه، امضای آن را بررسی می‌کند.
- تصاویر فریم‌ور به عنوان بخشی از فرآیند ساخت، با استفاده از الگوریتم ECDSA (معمولاً با جفت کلید P-256) امضا می‌شوند.
کیف توسعه nRF Connect SDK نوردیک شامل یکپارچه‌سازی MCUboot است. مدیریت کلید — شامل تولید کلیدهای امضا، تهیه کلیدهای عمومی روی دستگاه و امضای تصاویر در زمان ساخت — بخشی است که اکثر تیم‌ها باید برای آن تلاش آگاهانه صرف کنند. ابزارها وجود دارند، اما نیازمند راه‌اندازی آگاهانه هستند.
تراشه‌های STM32 (سری‌های STM32L5، STM32U5 و STM32H5 مجهز به TrustZone)
شرکت ST بوت امن را از طریق کتابخانه بوت امن و به‌روزرسانی امن فریم‌ور (SBSFU) و اخیراً از طریق مکانیزم‌های داخلی بوت امن (STiROT و OBKey) در سری‌های جدیدتر پیاده‌سازی می‌کند.
زنجیره امنیتی در STM32:
- بوت‌لودر غیرقابل تغییر ROM، پیکربندی بوت امن و هش کلید عمومی را از بخش Option Bytes (معادل حافظه OTP) می‌خواند.
- پیش از اجازه دادن به اجرای کد، تصویر برنامه را اعتبارسنجی می‌کند.
- حفاظت در برابر بازگشت نسخه (Anti-rollback) از طریق یک شمارنده یک‌نواخت در بخش Option Bytes اعمال می‌شود؛ یعنی دستگاه فریم‌ور قدیمی‌تر از نسخه فعلی نصب‌شده را رد خواهد کرد.
یک نکته مهم در STM32 این است که گزینه‌های Option Bytes باید پیش از عرضه قفل شوند. بردهای توسعه‌دهنده با Option Bytes باز ارسال می‌شوند که امکان دسترسی دیباگ و جایگزینی کلید را فراهم می‌کند. عرضه دستگاهی با Option Bytes قفل‌نشده به این معناست که مهاجم با دسترسی فیزیکی می‌تواند کلید ریشه اعتماد را مجدداً پیکربندی کند. این یک گام پیکربندی است که باید بخشی از فرآیند تولید شما باشد.
خطایی که روی تعداد زیادی از محصولات دیده می‌شود
غیرفعال بودن بوت امن در نسخه نهایی تولیدی (Production Build).
این اتفاق بیشتر از آنچه باید رخ دهد اتفاق می‌افتد و دلیل آن هم قابل درک است: بوت امن جریان کاری توسعه و تست را پیچیده می‌کند. امضای هر تصویر فریم‌ور، مدیریت کلیدها و سر و کار داشتن با دستگاه‌هایی که از بوت کردن نسخه‌های دیباگ امضاننشده خودداری می‌کنند، اصطکاک ایجاد می‌کند. بنابراین تیم‌ها آن را در معماری امنیتی فعال می‌کنند، مکانیزم را به‌درستی پیاده‌سازی می‌کنند و سپس یک پرچم یا پیکربندی ساخت باقی می‌گذارند که تأیید امضا را در تولید دور می‌زند.
دستگاه عرضه می‌شود، تست‌های داخلی را پشت سر می‌گذارد، ویژگی بوت امن در پایگاه کد وجود دارد، اما هیچ کاری انجام نمی‌دهد؛ زیرا نسخه تولیدی تأیید اعتبار را غیرفعال کرده یا کلید امضا صرفاً یک مقدار پیش‌فرض است که هرگز به‌درستی راه‌اندازی نشده است.
رویکرد درست این است که پیکربندی تولید — شامل قفل شدن Option Bytes، غیرفعال شدن رابط‌های دیباگ، راه‌اندازی کلید امضا و اعمال تأیید اعتبار — به عنوان یک مرحله رسمی در فرآیند تولید همراه با بررسی اعتبار خاص خود در نظر گرفته شود؛ نه صرفاً یک وظیفه توسعه‌ای که کسی بعداً به آن رسیدگی کند.
پرسش‌های متداول
آیا قانون CRA به‌طور خاص نامی از بوت امن برده است؟
این مقررات از اصطلاح «بوت امن» استفاده نمی‌کند؛ بلکه تولیدکنندگان را ملزم می‌کند تا «از یکپارچگی داده‌های ذخیره‌شده، منتقل‌شده یا به‌نحوی‌دیگر پردازش‌شده، اعم از شخصی یا غیرشخصی، دستورات، برنامه‌ها و پیکربندی‌ها در برابر هرگونه دستکاری یا تغییر غیرمجاز توسط کاربر محافظت کنند» (پیوست ۱، بخش ۱، بند ۲(ف)). بوت امن پیاده‌سازی استاندارد این الزام برای دستگاه‌های توکار است. دستگاهی که نمی‌تواند یکپارچگی فریم‌ور را در زمان بوت تأیید کند، الزامات پیوست ۱ را برآورده نمی‌کند.
آیا می‌توانم بوت امن را روی سخت‌افزاری که ریشه اعتماد سخت‌افزاری ندارد پیاده‌سازی کنم؟
به‌طور جزئی بله. برخی از میکروکنترلرهای رده‌پایین فاقد حافظه OTP یا ذخیره‌سازی کلید سخت‌افزاری هستند. در این موارد، پیاده‌سازی‌های صرفاً نرم‌افزاری تضمین‌های ضعیف‌تری ارائه می‌دهند؛ مهاجمی که به حافظه فلش دسترسی داشته باشد می‌تواند به‌طور بالقوه هم کد تأیید و هم کلید را جایگزین کند. برای انطباق با CRA، ریشه اعتماد مبتنی بر سخت‌افزار رویکرد درست است. این تصمیمی در خصوص انتخاب سخت‌افزار است که باید در مرحله معماری اتخاذ شود، نه پس از طراحی برد.
آیا بوت امن جلوی تمام حملات فریم‌وری را می‌گیرد؟
خیر. بوت امن فقط تأیید می‌کند که فریم‌ور در زمان بارگذاری اصالت دارد. این ویژگی از آسیب‌پذیری‌های درون خود فریم‌ور قانونی محافظت نمی‌کند؛ یک تصویر فریم‌ور که به‌درستی امضا شده است هم‌چنان می‌تواند حاوی باگ‌هایی باشد که مهاجمان در زمان اجرا از آن‌ها سوءاستفاده کنند. بوت امن تنها یک لایه از معماری دفاع در عمق است و به تنهایی یک راه حل کامل محسوب نمی‌شود.
اگر کلید امضای من به خطر بیفتد چه اتفاقی می‌افتد؟
اگر کلید امضای خصوصی شما به خطر بیفتد، مهاجم می‌تواند فریم‌ور مخربی را امضا کند که از مرحله تأیید اعتبار عبور کند. مدیریت کلید — شامل تولید امن کلیدها، ذخیره کلیدهای خصوصی در ماژول‌های امنیت سخت‌افزاری و چرخش کلیدها در صورت شک به نشت — به اندازه خود پیاده‌سازی اهمیت دارد. پیاده‌سازی بوت امن تنها به اندازه مدیریت کلید پیرامون آن قوی است.
ما بوت امن را پیاده‌سازی کرده‌ایم. آیا این یعنی از نظر یکپارچگی فریم‌ور با CRA مطابقت داریم؟
بوت امن یکپارچگی زمان بوت را پوشش می‌دهد. قانون CRA همچنین نیازمند تأیید یکپارچگی برای به‌روزرسانی‌های فریم‌ور است؛ مکانیزم به‌روزرسانی OTA باید اصالت و یکپارچگی بسته‌های به‌روزرسانی را قبل از اعمال آن‌ها تأیید کند. این‌ها الزامات مرتبط اما جداگانه‌ای هستند و هر دو باید در جای خود پیاده‌سازی شوند.
منبع: What is Secure Boot and Why Every IoT Device Needs It — IoT For All؛ نویسنده: Platanor Technologies
منبع: iotforall