4、硬件信任根（RoT）：eFuse与OTP、硬件安全模块（HSM）、安全元件（SE）
聊安全启动，绕不开一个核心问题：信任从哪里开始？
你想想看，整个启动链是一级验证一级，BootROM 验 Bootloader，Bootloader 验 Kernel。但 BootROM 自己谁来验？总得有个「第一级信任」吧。这个第一级，就是硬件信任根（Root of Trust，RoT）。
说白了，RoT 是一个不可篡改的硬件实体。它存储了最底层的密钥、哈希值，或者执行最初始的度量。一旦这个根被攻破，整条链就全完了。我在项目中见过有人只做软件校验，结果 BootROM 被直接 patch 掉——嗯，那场面挺尴尬的。
核心观点：硬件信任根是安全启动的「锚点」。它不依赖任何外部软件，自身必须防篡改、防读取、防物理攻击。
这一章，我们拆开来看三种最常见的硬件 RoT 实现：eFuse/OTP、HSM、SE。它们各有各的脾气，选型时得心里有数。
4.1 eFuse 与 OTP：芯片出厂时的「烙印」
eFuse 和 OTP（One-Time Programmable）是芯片上的一小块特殊存储区域。出厂时全是 0，你只能把某些位从 0 烧成 1，烧完就回不去了。
我个人习惯把 eFuse 比作芯片的「烙印」。它最适合存什么？根公钥的哈希、芯片唯一 ID、安全配置位。BootROM 上电后第一件事，就是读 eFuse 里的哈希，跟自己算出来的公钥哈希比对——对不上，直接锁死。
实战技巧：量产时一定要预留几根 eFuse 作为「熔断锁」。我见过一个产品，所有 eFuse 都用来存密钥了，结果发现 JTAG 没关——嗯，只能重新流片。留 2-4 根 eFuse 做调试接口的硬件开关，是行业惯例。
eFuse 的物理实现有两种主流方式：
| 特性 | Poly Fuse（多晶硅熔丝） | Anti-Fuse（反熔丝） |
|---|---|---|
| 编程原理 | 大电流熔断多晶硅 | 击穿栅氧化层形成导通 |
| 编程后状态 | 开路（1→0） | 短路（0→1） |
| 可靠性 | 受温度影响，可能「愈合」 | 非常稳定，几乎不可逆 |
| 面积 | 较大 | 较小 |
| 常见工艺 | 较老工艺（65nm 以上） | 先进工艺（28nm 以下） |
注意：Poly Fuse 有个坑——高温下熔断的多晶硅可能「再生长」，导致位恢复。我曾经在车规项目上吃过这个亏，高温老化测试后 eFuse 值变了。后来全部换成 Anti-Fuse 方案。车规、工控场景，优先选 Anti-Fuse。
eFuse 的编程流程一般长这样：
// 伪代码：eFuse 编程流程
1. 进入安全编程模式（通常需要特定电压序列）
2. 写入目标地址和数据
3. 施加编程电压（通常 1.8V - 3.3V，持续几微秒）
4. 回读校验（Verify）
5. 如果校验失败，标记该芯片为次品
// 注意：编程电压和时序必须严格遵循 Datasheet
// 电压过高会烧穿相邻位，电压过低则烧不彻底4.2 硬件安全模块（HSM）：SoC 内部的「安全岛」
eFuse 只能存数据，不能做运算。那验签、解密这些操作谁来干？让主 CPU 干？不行，主 CPU 跑着 Linux，攻击面太大。
所以就有了 HSM——一个集成在 SoC 内部的独立安全协处理器。它有自己的小 CPU、专用 SRAM、硬件加速器（AES、RSA、ECC、Hash），甚至有自己的真随机数发生器（TRNG）。
我参与过一个车规芯片的设计，HSM 模块占了整个 die 面积的 3% 左右。当时团队有人觉得浪费，我说：「你想想看，没有 HSM，主 CPU 上跑验签，密钥被侧信道攻击一把梭，整个安全启动就是个摆设。」
HSM 的典型架构：
+------------------+ +------------------+
| 主 CPU (AP) | | HSM 协处理器 |
| 运行 Linux | | 运行安全固件 |
| 不安全域 | | 安全域 |
+--------+---------+ +--------+---------+
| |
| Mailbox / 共享内存 |
+------------------------+
| |
v v
+-----+-----+ +------+------+
| 系统总线 | | 专用密钥存储 |
+-----------+ | (eFuse/SRAM)|
+-------------+HSM 在安全启动中的职责很清晰：
- 启动度量：HSM 在 BootROM 之后接管，度量下一级镜像的哈希
- 签名验证：使用存储在 HSM 内部的根密钥，验证镜像签名
- 密钥派生：从根密钥派生会话密钥，用于后续的加密通信
- 安全存储：保护敏感数据（如设备证书、私钥）不被主 CPU 读取
关键设计原则：HSM 和主 CPU 之间必须做到强隔离。HSM 的密钥存储、安全 SRAM 对主 CPU 完全不可见。通信只能通过受限的 Mailbox 接口，且 HSM 固件必须独立签名和更新。
4.3 安全元件（SE）：独立的安全「保险柜」
HSM 再强，它还是集成在 SoC 内部的。如果攻击者用聚焦离子束（FIB）探针直接扒开芯片顶层，还是有可能读到总线上的密钥。
安全元件（SE）就不一样了。它是一颗独立的芯片，封装在自己的塑料壳里，有独立的电源、时钟、甚至金属屏蔽层。SE 通常通过 SPI 或 I2C 与主 SoC 通信。
你可能会问：「都 2025 年了，为什么还要多放一颗芯片？」
原因很简单：安全等级不在一个量级。SE 通常通过 CC EAL6+ 认证，能抵抗物理探针、电磁分析、激光故障注入。HSM 能做到 CC EAL4+ 就不错了。
| 对比维度 | eFuse/OTP | HSM | SE |
|---|---|---|---|
| 物理形态 | SoC 内部存储单元 | SoC 内部模块 | 独立芯片 |
| 安全等级 | 低（易被探针读取） | 中（CC EAL4+） | 高（CC EAL6+） |
| 计算能力 | 无 | 强（硬件加速） | 中（专用指令集） |
| 密钥存储 | 只读，不可运算 | 内部 SRAM/eFuse | 内部 EEPROM/Flash |
| 典型成本 | <$0.1 | $0.5 - $2 | $1 - $5 |
| 应用场景 | IoT、消费电子 | 汽车、工业 | 金融、身份认证 |
选型建议：做智能门锁、摄像头这类产品，eFuse + 软件验签就够了。做 T-Box、网关，必须上 HSM。做支付终端、数字车钥匙，老老实实加 SE。别为了省几毛钱把安全等级降级——我曾经见过一个支付终端用 HSM 替代 SE，结果被侧信道攻击一把梭，密钥全丢。
4.4 实战：如何选择硬件信任根方案
讲完理论，咱们落地到选型。我一般按这个思路来：
- 先看威胁模型：你的对手是谁？是脚本小子，还是有物理接触的专业攻击者？
- 再看成本预算：BOM 成本允许加多少钱？SE 比 HSM 贵 2-3 倍。
- 最后看性能需求：启动时间要求多快？HSM 硬件加速验签只要几毫秒，SE 走 SPI 通信可能要几十毫秒。
举个例子。我去年做的一个车规项目，要求安全启动时间 < 100ms，同时要防物理攻击。最终方案是：
- SoC 内部集成 HSM（用于快速验签和密钥派生）
- 外加一颗 SE（存储根私钥，HSM 的根密钥由 SE 派生）
- eFuse 只存芯片 ID 和安全配置位（如 JTAG 熔断位）
这个方案成本高了点，但通过了车规的 EVITA Full 等级认证。
避坑指南：千万不要把根密钥直接硬编码在代码里！我曾经接手过一个项目，根密钥写在 BootROM 源码的注释里——嗯，注释里。攻击者拿到固件，直接字符串搜索就找到了。根密钥必须存储在 eFuse 或 HSM/SE 内部，且永远不能被软件读取。
最后说一句。硬件信任根不是万能的，但没有硬件信任根是万万不能的。选型时多花点心思，后面少流几次片。嗯，今天就到这。