第一章：信任链的起点——为什么需要信任？从硬件复位到第一条指令，信任的种子在哪里？
你有没有想过一个问题：电脑开机，按下电源键的那一刻，凭什么相信它接下来执行的每一行代码都是“干净”的？
我早年做嵌入式固件时，遇到过一件挺尴尬的事。一块板子，明明固件烧录校验都过了，量产时却有千分之几的设备在开机后行为诡异——后来查出来，是攻击者在芯片启动的最早期，通过调试接口注入了恶意指令。嗯，从那时起我才真正意识到：信任，必须从硬件复位的那一刻就开始建立。
核心观点：信任传递链的起点，不是操作系统，不是引导加载程序（Bootloader），甚至不是固件——而是芯片复位后执行的第一条指令。这条指令的源头，就是信任的“种子”。
1.1 为什么需要信任？——没有信任，就没有安全
说白了，计算机系统本质上是一个“盲目执行者”。它不关心代码是谁写的，只关心指令是否合法。如果攻击者能在你之前注入恶意代码，系统就会乖乖执行。
我习惯把信任链比作“接力赛”：
- 第一棒：硬件复位逻辑，决定从哪里取第一条指令。
- 第二棒：固化在芯片内部的只读代码（Boot ROM），验证下一级固件。
- 第三棒：引导加载程序，验证操作系统内核。
- 第四棒：内核，验证关键驱动和模块。
每一棒都必须验证下一棒的身份和完整性。如果第一棒就出了问题，后面再怎么加固也是白搭。
避坑指南：我曾经在一个项目中，团队花了大半年加固操作系统层，结果发现攻击者直接绕过了所有软件防护，通过物理手段篡改了SPI Flash中的引导代码。教训是什么？信任链必须从硬件层开始，软件层的安全措施无法弥补硬件层的信任缺失。
1.2 硬件复位：信任的“零时刻”
芯片上电或复位后，CPU内部会发生什么？
- 复位信号释放：电源稳定后，复位控制器释放复位信号。
- CPU内部状态初始化：寄存器、缓存、MMU等被置为已知状态。
- 取第一条指令：CPU从预定义的复位向量地址读取指令。
这个复位向量地址，就是信任的“种子”所在的位置。它通常指向芯片内部的一块只读存储器——Boot ROM。
| 组件 | 角色 | 是否可篡改 |
|---|---|---|
| 复位向量 | 定义第一条指令的地址 | 通常由硬件固定，不可改 |
| Boot ROM | 存放不可变的初始引导代码 | 芯片制造时固化，物理只读 |
| 外部Flash | 存放可更新的固件 | 可被物理或逻辑篡改 |
你想想看，如果复位向量指向的是外部可篡改的存储器，攻击者只要改掉外部Flash的内容，就能控制整个启动流程。所以，信任的种子必须种在芯片内部、物理不可篡改的存储介质中。
1.3 信任的种子：Boot ROM 与硬件信任根
Boot ROM 是芯片出厂时固化的一段代码。它有几个关键特性：
- 物理只读：制造完成后无法修改，即使芯片在用户手中。
- 不可绕过：复位向量强制指向它，没有其他路径可以跳过。
- 最小化：代码量极少（通常几KB到几十KB），便于形式化验证。
Boot ROM 的首要任务是什么？验证下一级代码的签名和完整性。它手里握着芯片厂商预置的公钥，用这个公钥去校验外部固件的数字签名。只有签名验证通过，才把控制权交给下一级。
注意：Boot ROM 本身不负责“安全启动”的全部工作，它只负责建立第一个信任锚点。如果 Boot ROM 有漏洞（比如缓冲区溢出），整个信任链就会崩塌。所以，芯片厂商对 Boot ROM 的代码审查和测试极其严格——我见过有的团队用形式化验证工具逐行分析 Boot ROM 的汇编代码，确保没有任何后门或漏洞。
1.4 信任传递的完整流程（第一阶段）
从复位到 Boot ROM 交出控制权，大致经历以下步骤：
- 硬件复位：CPU 从复位向量加载 PC（程序计数器）。
- 执行 Boot ROM：初始化最小硬件环境（时钟、栈、内存控制器）。
- 读取外部固件：从预定义的存储介质（如 SPI Flash、eMMC）读取固件头部。
- 验证签名：使用硬件公钥验证固件数字签名。
- 跳转执行：验证通过后，跳转到固件入口点。
下面这张图展示了这个流程：
1.5 硬件信任根的几种实现方式
不同芯片厂商对“信任种子”的实现略有差异。我整理了几种主流方案：
| 方案 | 信任根位置 | 典型芯片 | 特点 |
|---|---|---|---|
| Boot ROM + 一次性可编程存储器（OTP） | 芯片内部ROM + OTP存储公钥哈希 | ARM Cortex-M系列、某些SoC | 公钥哈希固化在OTP中，Boot ROM用其验证固件签名 |
| 硬件安全模块（HSM） | 独立安全芯片或安全协处理器 | TPM、Titan M、SE | 安全芯片独立执行验证，与主CPU隔离 |
| 熔丝（Fuse） | 芯片内部熔丝阵列 | 某些FPGA、定制ASIC | 熔丝状态决定信任策略，不可逆 |
我个人比较偏爱 Boot ROM + OTP 的组合。原因很简单：Boot ROM 代码量小，容易做形式化验证；OTP 存储的公钥哈希可以在芯片生命周期内更新（通过安全协议），灵活性更好。
经验之谈：我曾经参与过一个物联网芯片的设计，当时团队在“是否在Boot ROM中实现完整的加密算法”上争论了很久。最后我们选择了只实现哈希和签名验证，把复杂的加解密放到下一级固件中。为什么？因为Boot ROM一旦有bug，整个芯片就废了——保持Boot ROM最小化，是降低风险的关键。
1.6 常见误区与避坑
- 误区一：信任链可以从Bootloader开始。 不对。如果Bootloader本身没有被验证，攻击者可以直接替换它。信任链必须从硬件复位开始。
- 误区二：Boot ROM 不需要更新。 理论上是的，但实践中如果发现Boot ROM有漏洞，芯片厂商只能通过“安全更新”机制打补丁——这需要硬件支持动态信任根（如Intel的Boot Guard）。
- 误区三：只要签名验证了就安全。 签名验证只是第一步。如果公钥被篡改，或者签名算法有实现缺陷，攻击者照样能绕过。我见过一个案例，某厂商把公钥存储在外部Flash中，结果攻击者直接替换了公钥和自己的固件——公钥必须存储在不可篡改的硬件中。
1.7 小结
信任传递链的起点，是硬件复位后执行的第一条指令。这条指令来自芯片内部的 Boot ROM，而 Boot ROM 的不可篡改性，就是整个系统的信任种子。
记住三个关键点：
- 复位向量必须硬件固定，不能由软件配置。
- Boot ROM 必须物理只读，且代码量最小化。
- 公钥或公钥哈希必须存储在不可篡改的硬件中（如OTP、熔丝）。