4. 安全启动与信任根：硬件信任根（RoT）、安全启动链、固件完整性校验、Matter中的安全启动要求
安全启动这个话题，说白了就是解决一个问题：你怎么知道你设备上跑的程序是可信的？
我早年做IoT设备时，遇到过一件挺尴尬的事。客户反馈说设备半夜自己重启，行为异常。后来一查，是攻击者通过串口刷入了篡改过的固件。从那以后，我对安全启动的重视程度直接拉满。
在Matter体系里，安全启动是设备身份可信的基石。如果启动链被攻破，后面所有的加密、认证都是白搭。今天我们就从硬件信任根开始，一步步把这条链讲清楚。
4.1 硬件信任根（RoT）
信任根，英文叫Root of Trust，简称RoT。它是整个安全体系的锚点。你想想看，如果连最底层的代码都不确定是否可信，那上层验证再多也没用。
硬件信任根通常是一个不可篡改的、物理隔离的安全元件或安全区域。它负责存储最核心的密钥，并执行最初始的代码度量。
核心原则：信任根必须是不可变的（Immutable）。它要么是ROM代码，要么是一次性可编程（OTP）的熔丝。任何软件都无法修改它。
常见的硬件信任根实现方式有几种：
| 类型 | 描述 | 典型场景 |
|---|---|---|
| 独立安全芯片（SE） | 单独的芯片，通过总线与主控通信。安全性最高，但成本也高。 | 高端网关、金融支付设备 |
| 片上安全区域（TEE） | 主芯片内部划分出的安全执行环境，如ARM TrustZone。 | 手机SoC、智能音箱 |
| OTP熔丝 + Boot ROM | 芯片出厂时烧录公钥哈希，Boot ROM只认这个公钥签名的代码。 | 低成本MCU、Matter终端设备 |
我个人习惯在项目初期就确定RoT的方案。如果是做Matter设备，我建议优先考虑OTP熔丝 + Boot ROM的方案。成本可控，安全性也够用。
经验之谈：我曾经在一个项目里选了独立SE，结果因为I2C通信时序问题，导致启动时信任根读取失败，整批设备无法开机。后来改用片上方案，问题就解决了。选型时一定要考虑生产环节的可靠性。
4.2 安全启动链
有了信任根，接下来就是怎么把信任传递下去。这就是安全启动链（Secure Boot Chain）。
它的工作流程是这样的：
- Boot ROM 上电执行。它用内置的公钥验证下一级Bootloader的签名。
- 验证通过后，Bootloader 获得控制权。它继续验证下一级Bootloader或OS内核。
- 每一级都验证下一级的签名和完整性，直到整个系统启动完成。
这个过程就像接力赛。每一棒都要确认下一棒是“自己人”。
注意：安全启动链不能有“断点”。如果某一级跳过了验证，那整个链就废了。我在审核代码时，最关注的就是有没有“无条件跳转”或“跳过验证”的后门。
下面这张图展示了典型的安全启动链结构：
4.3 固件完整性校验
安全启动链的核心操作就是固件完整性校验。它通常包含两个步骤：
- 身份认证：验证固件是否由受信任的厂商签名。
- 完整性检查：验证固件内容是否被篡改。
具体实现上，最常用的是数字签名方案。流程如下：
- 厂商用私钥对固件哈希值签名，生成签名文件。
- 设备端用公钥解密签名，得到原始哈希值。
- 设备计算当前固件的哈希值，与解密得到的哈希值对比。
- 如果一致，说明固件是完整的、可信的。
关键点：公钥的存储位置决定了安全性。公钥必须存储在信任根内部，比如OTP熔丝或安全元件中。如果公钥可以被替换，那签名验证就形同虚设。
下面是一个简化的固件签名验证流程代码示例：
// 伪代码：固件签名验证
bool verify_firmware(const uint8_t* firmware, size_t fw_len,
const uint8_t* signature, size_t sig_len) {
// 1. 从信任根读取公钥
uint8_t public_key[32];
ro_read_public_key(public_key);
// 2. 计算固件哈希
uint8_t hash[32];
sha256_calculate(firmware, fw_len, hash);
// 3. 用公钥验证签名
return ecdsa_verify(public_key, hash, signature);
}避坑指南：我曾经见过一个产品，固件校验通过了，但设备还是被黑了。后来发现是攻击者利用了回滚攻击——刷入了一个旧版本但签名合法的固件。所以，完整性校验一定要配合版本号检查，防止回滚。
4.4 Matter中的安全启动要求
Matter协议对安全启动有明确的要求。它不规定具体实现，但定义了必须满足的能力。我整理了一下核心要点：
| 要求项 | 描述 | Matter规范参考 |
|---|---|---|
| 硬件信任根 | 设备必须有一个不可变的信任根，用于存储设备身份密钥（DAC）和启动公钥。 | Matter Core Spec, 6.2.1 |
| 安全启动链 | 从Boot ROM到应用固件，每一级都必须验证下一级的签名。 | Matter Core Spec, 6.2.2 |
| 固件签名 | 所有OTA固件更新必须使用ECDSA签名，且签名密钥必须与设备信任根绑定。 | Matter Core Spec, 11.20.4 |
| 防回滚 | 设备必须记录当前固件版本，拒绝低于当前版本的固件更新。 | Matter Core Spec, 11.20.4.2 |
| 安全状态指示 | 设备启动后，必须向Matter控制器报告其安全状态（如是否通过了安全启动）。 | Matter Core Spec, 6.2.3 |
嗯，这里要注意一点。Matter的认证测试（PICS）里，安全启动是强制项。如果你的设备没有实现安全启动，是拿不到Matter认证的。
重要提醒：Matter要求设备在出厂时，必须将DAC（Device Attestation Certificate）私钥存储在信任根中。这个私钥是设备身份的凭证。如果泄露，攻击者可以伪造设备身份。我建议在生产环节使用安全产线，在芯片贴片前就把密钥烧录进OTP。
最后，我想强调一点。安全启动不是一劳永逸的。它需要配合安全更新机制一起使用。比如，当发现Bootloader有漏洞时，你需要一个安全的机制来更新它。这通常涉及到双重镜像或恢复模式。这部分内容，我们会在后续章节详细展开。
好了，安全启动与信任根的内容就讲到这里。记住一句话：信任不能传递，只能验证。每一级代码都要自己确认下一级的可信度，这才是安全启动的精髓。