一、可信启动概述
什么是可信启动
可信启动，说白了就是让设备在开机时，从第一行代码开始就确保自己是「干净的」。
我刚开始接触嵌入式安全时，觉得这概念挺玄乎。后来在项目中吃过亏才明白——你想想看，如果芯片上电后执行的第一个程序就被篡改了，那后面所有安全措施都是白搭。
可信启动的核心思路很简单：逐级验证，层层把关。就像进一栋大楼，先刷门禁卡，再过安检，最后还要指纹确认。每一级都验证上一级的合法性，一旦发现异常，立即停止启动。
关键定义：可信启动（Secure Boot）是一种硬件级的安全机制，确保设备只运行经过授权和签名的固件代码。它从芯片内部不可篡改的只读存储器（ROM）开始，逐级验证后续加载的每个固件组件。
为什么需要可信启动
这个问题我经常被问到。有人觉得：「我产品又不做金融，谁会来攻击我？」
嗯，我以前也这么想。直到有一次，客户反馈设备莫名其妙连不上服务器。排查了三天，最后发现是固件被植入了挖矿脚本。那台设备在用户家里偷偷挖了两个月，电费都算在用户头上。
从那以后，我深刻理解了可信启动的必要性。具体来说，有这几个原因：
- 防止固件篡改：攻击者通过物理接口（如JTAG、UART）或远程漏洞，替换掉你的固件。没有可信启动，设备就成了别人的「肉鸡」。
- 阻止恶意软件持久化：很多恶意软件会把自己写入Flash，每次开机自动运行。可信启动能在加载阶段就把它拦下来。
- 保护知识产权：你的算法、业务逻辑都在固件里。可信启动能防止别人直接替换固件来逆向分析。
- 满足合规要求：现在很多行业标准（如IEC 62443、GDPR）都明确要求设备具备安全启动能力。
注意：可信启动不是万能的。它只保证启动过程的完整性，不负责运行时安全。启动之后的内存保护、访问控制，那是另一套机制的事。
可信启动的信任链模型
信任链模型，是可信启动的骨架。我习惯把它理解成「接力赛」——每一棒选手都要确认上一棒的身份，然后自己再跑下一段。
典型的信任链是这样的：
- 根信任（Root of Trust）：芯片内部固化的ROM代码，出厂时烧录，物理上不可修改。这是整个信任链的起点。
- 一级引导加载程序（FSBL）：ROM代码从Flash中加载FSBL，并验证其签名。验证通过后，控制权交给FSBL。
- 二级引导加载程序（SSBL）：FSBL加载SSBL（通常是U-Boot或类似程序），同样验证签名。通过后移交控制权。
- 操作系统内核：SSBL加载操作系统内核（如Linux Kernel），验证内核镜像的签名。
- 应用程序：内核加载根文件系统和应用程序，同样需要验证签名。
每一级都只信任上一级传递过来的公钥。这个公钥通常存储在芯片的一次性可编程（OTP）区域，或者由硬件安全模块（HSM）管理。
我的经验：在实际项目中，我建议把公钥的存储和验证逻辑放在ROM里。ROM代码是芯片出厂就固化好的，攻击者想改也改不了。我曾经见过一个方案，把公钥放在外部Flash里，结果被人用逻辑分析仪读出来，伪造了签名——那叫一个惨。
下面我用一张流程图来展示这个信任链模型：
这张图里，从上到下每一层都依赖上一层的验证。ROM代码是绝对的信任根，它谁都不信，只信自己。后面的每一级，都要拿着上一级给的公钥，去验证下一级的签名。
核心要点：信任链的本质是「信任的传递」。根信任是硬件保证的，后续的信任是通过密码学验证建立的。只要根信任不被攻破，整个链条就是安全的。
在实际项目中，我见过不少团队在信任链设计上翻车。最常见的问题有两个：
- 信任链断裂：某级验证跳过了，或者验证逻辑有漏洞。比如FSBL加载SSBL时没检查签名，那攻击者就能直接替换SSBL。
- 根信任泄露：私钥被偷了，或者OTP区域的公钥被覆盖了。一旦根信任出问题，整个信任链就崩塌了。
避坑指南：我曾经在一个IoT项目里，发现开发团队把签名私钥直接放在代码仓库里。嗯，你没看错，就是GitHub公开仓库。那台设备的安全启动形同虚设。记住：私钥必须离线存储，最好用硬件安全模块（HSM）管理。
最后说一句，可信启动不是一锤子买卖。随着产品迭代，固件会更新，签名密钥也可能需要轮换。设计信任链时，一定要考虑密钥管理和更新机制。否则，产品上市后想换密钥，那可就麻烦了。
好了，这一章就到这里。下一章我们聊聊具体的签名工具和操作流程。