3、硬件信任根(RoT):什么是信任根、硬件安全模块(HSM)、eFuse与OTP存储
聊到可信启动,有个概念绕不开——信任根(Root of Trust, RoT)。说白了,它就是整个安全体系的“原点”。你想想看,如果连这个原点都不安全,那后面所有的校验、签名、度量,全都是在沙滩上盖楼。
我早年做一款IoT网关时,就踩过这个坑。当时我们只做了软件层面的校验,结果攻击者直接修改了BootROM里的校验逻辑……嗯,从那以后,我再也不敢轻视硬件信任根了。
3.1 什么是信任根?
信任根是一个绝对可信的实体。它通常是硬件实现的,因为纯软件可以被篡改。它的核心职责就两件事:
- 提供不可伪造的身份——证明“我是我”
- 执行不可篡改的度量——验证“你没变”
信任根一旦被攻破,整个安全链就断了。所以业界有个共识:信任根必须是硬件隔离的,不能和主CPU共享内存、不能通过DMA访问、甚至不能通过JTAG读取。
信任根的三要素:
- 不可伪造性:私钥永远不离开硬件
- 不可篡改性:度量逻辑固化在ROM中
- 不可绕过性:所有启动路径都必须经过它
3.2 硬件安全模块(HSM)
HSM是个“保险柜”。它专门用来保护密钥、执行加密运算、生成随机数。我见过很多工程师把HSM和TPM搞混,其实它们有区别:
| 特性 | HSM | TPM |
|---|---|---|
| 典型应用 | 服务器、金融、汽车 | PC、笔记本、嵌入式 |
| 密钥存储 | 硬件隔离,防物理攻击 | 硬件隔离,但防护等级较低 |
| 加密运算 | 专用加速器,高性能 | 通用协处理器,性能一般 |
| 认证等级 | FIPS 140-2 Level 3/4 | Common Criteria EAL 4+ |
| 成本 | 高(几百到几千美元) | 低(几美元) |
在嵌入式领域,我们更多用的是集成式HSM——也就是SoC内部的安全子系统。比如NXP的i.MX系列里的HAB(High Assurance Boot),或者ST的STM32MP1里的BSEC。它们虽然叫法不同,但本质都是HSM的“轻量版”。
我的建议:选型时别只看HSM的加密算法支持,还要看它的密钥生命周期管理。有些HSM只支持注入一次密钥,有些支持轮换。如果你的产品要跑10年,密钥轮换能力就很重要。
3.3 eFuse与OTP存储
eFuse和OTP(One-Time Programmable)是信任根的“物理载体”。它们用来存储那些一旦设定就不能改的数据——比如根密钥、芯片ID、安全配置。
eFuse的原理很有意思。它利用电迁移效应,通过大电流“熔断”一根纳米级的金属丝。熔断后电阻永久变化,读出就是“1”。没熔断就是“0”。
OTP则更灵活一些。它可以是反熔丝、浮栅晶体管,甚至是MTP(多次可编程)的变种。但不管哪种,核心特性都一样:只能从0写到1,不能从1改回0。
我曾经在一个项目里吃过亏。当时我们用了某款MCU,它的OTP区域只有64字节。我们想存一个2048位的RSA公钥(256字节),结果根本放不下。最后只能改用ECDSA,密钥长度只有256位(32字节)。所以,选芯片前一定要算好OTP容量。
3.3.1 eFuse vs OTP:怎么选?
| 对比项 | eFuse | OTP |
|---|---|---|
| 编程方式 | 电流熔断 | 电荷注入/反熔丝 |
| 可靠性 | 受温度影响大 | 更稳定 |
| 密度 | 低(占用面积大) | 高 |
| 编程次数 | 一次(但可分段熔断) | 一次(或有限次) |
| 典型容量 | 几百bit ~ 几Kbit | 几Kbit ~ 几十Kbit |
| 成本 | 低(标准CMOS工艺) | 中(需要额外工艺层) |
我个人习惯是:存根密钥用eFuse,因为它的物理不可克隆性更好;存配置参数用OTP,因为容量大、更稳定。
3.3.2 实际使用中的注意事项
- 编程电压:eFuse编程需要高压(通常1.8V~3.3V),设计时要注意电源纹波。我见过因为电源噪声导致eFuse熔断不完全的案例。
- 冗余位:eFuse有良率问题,通常需要预留冗余位。比如你要存128位密钥,芯片可能会给你256位的eFuse阵列,其中一半是冗余。
- 锁定机制:OTP区域一旦锁定,连芯片自己都不能再读。这个机制用来防止密钥泄露。但要注意:锁定是不可逆的。我曾经在调试时不小心锁了一个测试芯片的OTP,结果那块芯片直接报废了。
警告:千万不要在生产前锁定OTP!先留一个“调试模式”的熔丝位,等量产验证通过后再永久锁定。否则一旦发现固件bug,你连更新密钥的机会都没有。
3.4 硬件信任根的典型架构
下面这张图展示了一个典型的硬件信任根架构。它把信任根、HSM、eFuse/OTP整合在一起,形成一个完整的“安全锚点”。
这个架构里,信任根不是某个单独的芯片,而是一个逻辑组合。ROM里的代码、eFuse里的密钥、HSM里的加密引擎,三者缺一不可。
3.5 实战中的常见问题
最后,我分享几个实际项目中遇到的坑:
- 密钥注入时机:eFuse必须在芯片贴片前编程。一旦贴片,有些芯片就没办法再编程了。所以生产流程里要留一个“预编程”环节。
- 测试覆盖率:HSM的加密运算在量产时一定要做功能测试。我遇到过一批芯片,HSM的RSA加速器有硬件bug,签名验证总是失败。后来加了自检逻辑才解决。
- 物理攻击防护:eFuse的熔断状态可以用电子显微镜读出来。如果你的产品要防国家级攻击,得加主动屏蔽层。不过大多数嵌入式产品不需要这个级别。
一个小技巧:在eFuse里存一个“熔断计数器”。每次熔断一位,计数器加1。这样即使攻击者能物理读取eFuse状态,也搞不清哪些位是密钥、哪些位是计数器。这叫“混淆存储”,成本低、效果好。