一、安全启动概述
1.1 什么是安全启动
安全启动，说白了就是一套「谁启动谁负责」的链式校验机制。
从设备上电那一刻起，每一级启动代码都要先验证下一级的签名和完整性，通过才能执行。一旦某级校验失败，系统立刻停止启动——这就是安全启动的核心动作。
我最早接触这个概念是在做一款车规级网关的时候。客户要求「从第一行代码开始就不能被篡改」。当时我还在想，不就是个启动吗？后来踩了坑才明白，没有安全启动的设备，就跟没锁门的房子一样。
安全启动的本质：在信任链上，每一环都只信任上一环的签名，直到根。
1.2 为什么需要安全启动
你想想看，现在的嵌入式设备有多复杂？
- 攻击者可以通过物理接口（JTAG、UART）直接改写 Flash
- OTA 升级包可能被中间人替换成恶意固件
- Bootloader 漏洞可能被利用加载未授权代码
没有安全启动，这些攻击路径全部畅通无阻。
我记得有一次做安全审计，发现某款 IoT 设备的 Bootloader 根本不校验内核镜像。攻击者只需要把恶意固件写到 SPI Flash 的对应偏移位置，重启后设备就「叛变」了。修复成本极高——因为硬件已经定型了。
注意：安全启动不是可选项，而是现代嵌入式系统的底线。尤其是车规、医疗、工业控制场景，法规已经强制要求。
1.3 安全启动的核心目标
安全启动要解决三个问题：
- 完整性验证——代码有没有被改过？
- 来源认证——代码是不是来自可信方？
- 执行控制——非法代码能不能阻止执行？
这三个目标缺一不可。我曾经见过一个方案，只做了完整性校验（哈希比对），但没有签名验证。结果攻击者直接把合法固件和恶意代码一起替换掉，哈希值当然能对上——因为整个镜像都被换了。这就是典型的「只防了一半」。
| 目标 | 实现手段 | 常见失败案例 |
|---|---|---|
| 完整性 | 哈希（SHA-256 等） | 只做哈希，不做签名 |
| 来源认证 | 非对称签名（RSA/ECDSA） | 公钥存储在可写区域 |
| 执行控制 | 硬件强制校验失败停机 | 校验失败后仍允许降级启动 |
1.4 信任根（Root of Trust）
信任根是整个安全启动的基石。它必须满足两个条件：
- 不可篡改——物理上或逻辑上无法改写
- 不可绕过——系统第一条指令必须来自它
常见的信任根实现方式：
- ROM Bootloader：出厂固化在芯片 ROM 中，无法修改。这是最常用的方案。
- eFuse / OTP：一次性可编程存储，用于存放根公钥哈希或芯片唯一密钥。
- 硬件安全模块（HSM / TPM）：独立的安全协处理器，负责密钥管理和签名验证。
我个人习惯把信任根比作「保险箱的锁芯」。锁芯坏了，整个保险箱就没意义了。所以信任根的设计必须极端保守——代码量要少、逻辑要简单、测试要全覆盖。
实战建议：信任根代码建议用纯汇编或受限 C 编写，避免依赖运行时库。我在一个项目里就因为用了 memset() 导致 ROM 空间不够，最后不得不手写循环——嗯，从那以后我写信任根代码都先看反汇编。
1.5 安全启动的信任链模型
整个安全启动流程是一条链：
ROM Boot → Bootloader → 内核 → 文件系统 / 应用
每一级都负责验证下一级的签名。如果任何一级验证失败，链就断了，系统停止启动。
下面这张图展示了典型的信任链结构：
这张图里，每一级箭头都代表一次签名验证。信任根在最底层，它不依赖任何其他代码——这就是「根」的含义。
1.6 安全启动的常见误区
我这些年看过不少安全启动方案，有几个误区反复出现：
- 误区一：公钥放在 Flash 里就行——攻击者可以同时替换公钥和固件。公钥必须存储在 OTP 或 ROM 中。
- 误区二：哈希校验就够了——哈希只能防意外损坏，防不了恶意篡改。必须配合签名。
- 误区三：校验失败后可以降级启动——这等于给攻击者留了后门。安全启动必须是「非黑即白」的。
避坑指南：我曾经在一个项目里看到，Bootloader 校验内核失败后，居然打印了一条警告然后继续启动。美其名曰「开发模式」。结果产品出货时忘了关这个开关——嗯，后果可想而知。
1.7 小结
安全启动不是某个单一技术，而是一套从信任根开始的链式验证体系。它的核心就三件事：完整性、来源认证、执行控制。信任根是这条链的起点，必须做到不可篡改、不可绕过。
后面的章节，我会带你一步步拆解每个环节的具体实现——从 ROM Boot 的代码设计，到签名算法的选型，再到异常阻断的硬件机制。准备好了吗？