1、安全启动概述：什么是安全启动、为什么需要安全启动、安全启动的信任链模型
各位好，我是老张。做嵌入式安全这行十几年了，今天咱们聊聊安全启动。
说实话，我刚入行那会儿，压根没把启动安全当回事。那时候觉得，只要代码能跑起来，产品能出货，就万事大吉。直到有一次，我在一个物联网网关项目里栽了个大跟头——产品量产三个月后，客户反馈设备频繁被远程控制，数据也被篡改了。一查才发现，攻击者通过串口刷入了恶意固件，整个信任体系直接崩塌。
那次之后，我彻底明白了：启动阶段的安全，是整个设备安全的基石。如果连第一步都守不住，后面做再多防护都是白搭。
什么是安全启动
安全启动，说白了就是让设备只运行经过授权的、未被篡改的代码。从芯片上电的第一条指令开始，到操作系统内核加载完毕，每一步都要验证代码的完整性和合法性。
你想想看，如果设备启动时能随便加载一个第三方固件，那跟把家门钥匙挂在门外有什么区别？
安全启动的核心机制其实不复杂：
- 数字签名验证：每一段代码都带有签名，启动时先验签，签名不对直接拒绝执行
- 硬件信任根：验证的起点是芯片内部不可篡改的硬件单元，比如一次性编程的熔丝或OTP存储器
- 逐级校验：前一级代码验证后一级代码，形成一条完整的信任链
核心要点：安全启动不是单一技术，而是一套从硬件到软件的完整验证体系。它保证设备启动的每一步都"可信"。
为什么需要安全启动
我经常被问到：加个密码保护不就行了？干嘛搞这么复杂？
嗯，这里要注意。密码保护只能防住"人"，防不住"代码"。攻击者可以通过物理接触、网络漏洞、供应链攻击等多种方式，把恶意固件塞进你的设备里。没有安全启动，这些攻击几乎畅通无阻。
具体来说，安全启动解决这几个核心问题：
- 防止固件被篡改：攻击者修改了Flash里的固件，设备启动时能检测出来，直接拒绝启动
- 防止回滚攻击：攻击者把设备降级到有漏洞的旧版本固件，安全启动能阻止这种操作
- 防止未授权固件运行：只有经过厂商签名的固件才能启动，第三方恶意固件无法运行
- 建立信任基础：为后续的安全功能（如安全存储、安全通信）提供可信的执行环境
我曾经在一个车规级项目中遇到过这样的场景：客户要求设备在OTA升级后，必须验证新固件的签名才能重启。如果没有安全启动，攻击者完全可以伪造一个升级包，让整车控制器"中毒"。那后果，想想都后怕。
避坑提醒：不要以为安全启动只在高端芯片上才有。现在很多MCU都支持了，比如STM32的Secure Boot、NXP的HAB、TI的HSM。选型时一定要确认芯片是否支持硬件级安全启动，纯软件方案很容易被绕过。
安全启动的信任链模型
信任链模型，是安全启动的骨架。它的设计思路很简单：从一个绝对可信的起点开始，一级验证一级，直到整个系统启动完成。
我习惯把这个过程比作"接力赛"——每一棒都要确认下一棒的身份，交接棒时还要检查"接力棒"有没有被调包。
典型的信任链模型包含以下几个层级：
| 层级 | 组件 | 验证方式 | 我的经验 |
|---|---|---|---|
| 第1级 | 硬件信任根（ROM Boot） | 芯片出厂时固化，不可修改 | 这是最关键的层级，一旦被攻破，整个信任链就完了 |
| 第2级 | Bootloader（SPL/FSBL） | 由ROM代码验证签名 | 很多芯片的Bootloader可以回滚，记得在代码里加版本检查 |
| 第3级 | 主Bootloader（UBoot/ATF） | 由上一级Bootloader验证 | 这里容易出问题的是签名算法选择，别用MD5或SHA1 |
| 第4级 | 操作系统内核 | 由主Bootloader验证 | 内核镜像的签名和校验逻辑要写在Bootloader里，别依赖内核自身 |
| 第5级 | 应用程序/文件系统 | 由内核或init进程验证 | 应用层的签名验证容易被忽略，但攻击者往往从这里入手 |
下面这张图，是我自己画的一个信任链流程图，你可以直观地看到整个验证过程：
从这张图你能看到，信任链的每一级都承担着"验证者"和"被验证者"的双重角色。除了第一级——硬件信任根，它是整个链条的起点，没有任何前置验证者。
我的建议：在实际项目中，不要只关注Bootloader和内核的签名验证。应用层的签名验证同样重要。我曾经见过一个项目，Bootloader和内核都做了签名，但应用层直接加载未签名的脚本文件，结果被攻击者利用这个漏洞植入了后门。记住：信任链的强度，取决于最弱的一环。
另外，信任链模型还有一个容易被忽视的点：回滚保护。攻击者不一定非要刷入恶意固件，他们可以把设备降级到有已知漏洞的旧版本。所以，每一级Bootloader和固件版本号都要做递增检查，防止回滚。
嗯，关于安全启动的概述，今天就聊到这儿。信任链模型是整个安全启动的骨架，理解了它，后面讲具体配置和实现时，你就能明白每一步设计背后的逻辑了。