3、安全启动与信任根：硬件安全模块(HSM)、信任根(RoT)、安全启动链验证
设备注册的第一步，其实是证明「我是谁」。
你想想看，如果一台设备连自己的身份都证明不了，那它往云端发注册请求，谁敢信？所以这一章我们要聊的，就是设备在通电之后、联网之前，怎么通过硬件级的手段，给自己建立一个不可伪造的身份。
3.1 信任根（RoT）—— 一切信任的起点
信任根，英文叫 Root of Trust，简称 RoT。说白了，它就是整个安全体系里那个「绝对可信」的起点。
我习惯把 RoT 比作一个公证人。这个公证人不会撒谎，不会被收买，而且它说的话，所有人都认。在物联网设备里，RoT 通常是一个物理上不可篡改的硬件单元，它负责做三件事：
- 存储根密钥：设备最核心的私钥，永远不离开这个硬件。
- 提供身份证明：用根密钥签名，证明设备是合法的。
- 启动信任链：从第一行代码开始，逐级验证后续的固件。
核心原则：信任根必须是「不可伪造」且「不可提取」的。如果攻击者能读出根密钥，那整个安全体系就崩塌了。
我在项目中遇到过一种情况：某厂商把根密钥直接写死在 Flash 里，结果固件被 dump 出来之后，密钥也跟着暴露了。嗯，那批设备后来全部需要召回。所以记住，RoT 必须硬件隔离，不能跟普通存储混在一起。
3.2 硬件安全模块（HSM）—— 把密钥锁进保险柜
HSM，全称 Hardware Security Module。你可以把它理解成一个专门干密码学活儿的「黑盒子」。
这个黑盒子有几个特点：
- 物理防护：有人试图拆开它，里面的密钥会自动销毁。
- 专用算力：加解密、签名验签，比通用 CPU 快得多。
- 密钥不出模块：所有密码运算都在 HSM 内部完成，密钥永远不暴露在总线上。
在物联网设备里，HSM 可以是独立的芯片，也可以是 SoC 内部的一个安全区域（比如 ARM 的 TrustZone 配合安全子系统）。我个人更推荐独立 HSM，因为隔离得更彻底。
| 对比维度 | 独立 HSM 芯片 | SoC 内置安全区域 |
|---|---|---|
| 安全隔离度 | 极高（物理隔离） | 较高（逻辑隔离） |
| 成本 | 高（额外 BOM） | 低（集成在 SoC 内） |
| 性能 | 专用硬件，速度快 | 受主 CPU 影响 |
| 适用场景 | 金融、车规、工业 | 消费类 IoT |
我的建议：如果你的产品要通过 PSA Certified 或 Common Criteria EAL 认证，尽量上独立 HSM。别为了省几毛钱，后面补合规补到哭。
3.3 安全启动链验证 —— 从第一行代码开始信任
设备上电后，CPU 执行的第一段代码叫 BootROM。这段代码是出厂固化的，不可修改。它就是信任链的起点。
安全启动的流程大致是这样的：
- BootROM 加载第一阶段引导程序（通常是 SPL 或 U-Boot SPL）。
- BootROM 用 RoT 中的公钥验证 SPL 的签名。验证通过，才执行 SPL。
- SPL 加载第二阶段引导程序（比如 U-Boot 主程序）。
- SPL 用同样的公钥或派生密钥验证 U-Boot 的签名。
- U-Boot 加载操作系统内核（如 Linux Kernel）。
- U-Boot 验证内核的签名。
- 内核启动后，验证文件系统或应用层的关键组件。
你看，每一级都验证下一级的签名，形成一条链。只要起点（BootROM）是可信的，整条链就是可信的。
曾经踩过的坑：我曾经见过一个方案，BootROM 验证了 SPL，但 SPL 没有验证 U-Boot，结果攻击者直接替换了 U-Boot，绕过了整个安全启动。所以记住，链上每一个环节都不能断，断了就等于没做。
3.4 安全启动链的完整架构图
下面这张图，是我自己画的安全启动链流程。你可以对照着看，理解每一级的关系。
3.5 代码示例：使用 OpenSSL 生成签名并验证
在实际项目中，我们通常会用 OpenSSL 来生成密钥对，并对固件进行签名。下面是一个典型的流程：
# 1. 生成 ECDSA 密钥对（推荐 P-256 曲线）
openssl ecparam -genkey -name prime256v1 -out device_key.pem
# 2. 提取公钥，烧录到设备的 RoT 中
openssl ec -in device_key.pem -pubout -out device_pub.pem
# 3. 对固件镜像进行签名
openssl dgst -sha256 -sign device_key.pem -out firmware.sig firmware.bin
# 4. 验证签名（在设备端 BootROM 中执行）
openssl dgst -sha256 -verify device_pub.pem -signature firmware.sig firmware.bin个人习惯：我一般用 ECDSA P-256 而不是 RSA。原因很简单——同样的安全强度下，ECDSA 的签名更短，密钥更小，对 IoT 设备的存储和算力更友好。
3.6 合规要点
如果你要通过一些主流的安全认证，下面这些点是必须覆盖的：
- NIST SP 800-193：要求平台固件必须支持安全启动，且信任根不可更改。
- PSA Certified Level 2/3：要求 RoT 必须硬件隔离，且安全启动链必须覆盖从 BootROM 到应用层。
- IEC 62443-4-2：要求设备具备安全启动能力，且密钥管理必须符合 CR 4.1 要求。
- GDPR / 等保 2.0：虽然没有直接要求安全启动，但设备身份不可伪造是数据保护的基础。
曾经踩过的坑：我曾经帮一家客户做 PSA Level 2 认证，结果发现他们的 BootROM 居然没有做物理写保护。攻击者可以通过 JTAG 直接修改 BootROM 代码。嗯，那一次我们花了三周重新流片。所以记住，RoT 不仅要逻辑上可信，物理上也要防篡改。
3.7 小结
安全启动和信任根，是物联网设备注册安全的基石。没有它们，后面所有的注册流程、身份认证、数据加密，都是空中楼阁。
我个人觉得，做 IoT 安全，最忌讳的就是「差不多就行」。你想想看，攻击者只要攻破一个环节，整条链就断了。所以从 BootROM 到 HSM，从密钥生成到签名验证，每一步都要做到位。
嗯，这一章的内容就到这里。记住一句话：信任不能传递，只能验证。