4、安全启动与固件验证：安全启动流程、固件签名与验证、安全固件更新(OTA)机制
安全启动和固件验证，说白了就是给设备装上一道「从娘胎里就开始的信任链」。我见过太多设备因为启动阶段被篡改，整个网络都跟着遭殃。Matter 在这方面做得挺绝——它不光要求芯片上电后逐级校验，还把 OTA 更新也纳入了完整的签名链里。
这一章，咱们就掰开揉碎聊聊：安全启动到底怎么跑？固件签名怎么搞？OTA 更新怎么保证不被中间人塞进恶意代码？
4.1 安全启动流程
安全启动不是某个单一动作，而是一连串的「接力验证」。我习惯把它分成三个阶段：
- 不可变根（BootROM）——芯片出厂时固化，谁都没法改。它只做一件事：校验下一级 Bootloader 的签名。
- 第一级 Bootloader——通常由芯片厂商提供，负责初始化硬件、校验第二级 Bootloader 或直接校验固件。
- 应用固件——也就是 Matter 设备跑的主程序，必须携带有效签名才能被加载。
你想想看，如果 BootROM 本身能被改，那整个信任链就塌了。所以芯片厂商都会把 BootROM 做成只读，连 JTAG 都读不出来。我在一个智能锁项目里遇到过，某款芯片的 BootROM 有个漏洞，攻击者可以通过电压毛刺让它跳过签名校验……嗯，那批货最后全换了方案。
4.2 固件签名与验证
Matter 强制要求固件使用 ECDSA（椭圆曲线数字签名算法），曲线是 NIST P-256。为什么不用 RSA？因为 IoT 设备资源有限，P-256 的签名更短、验签更快。
签名流程大致是这样：
- 厂商用私钥对固件哈希签名，生成签名文件。
- 设备端用公钥验签，公钥要么烧死在芯片 OTP 里，要么由证书链逐级颁发。
- 验签通过，固件才能被加载执行。
这里有个容易踩的坑——公钥存储位置。我曾经见过一个产品，公钥放在 Flash 里，结果攻击者直接替换了公钥和自己的固件，设备就「合法」跑起了恶意代码。正确的做法是：公钥必须放在一次性可编程（OTP）区域，或者由硬件安全模块（HSM）保护。
| 存储位置 | 安全性 | 典型场景 |
|---|---|---|
| OTP（一次性可编程） | 高，不可篡改 | 根公钥、芯片身份 |
| Flash（明文） | 低，可被替换 | 不推荐用于安全启动 |
| HSM 内部 | 极高，硬件隔离 | 高端 IoT、网关设备 |
4.3 安全固件更新（OTA）机制
OTA 更新是 Matter 设备生命周期里最脆弱的环节。为什么？因为设备跑起来之后，网络环境不可控，攻击者可能伪造更新服务器、劫持下载链接、甚至直接篡改固件包。
Matter 的 OTA 安全机制，我总结为「三层防护」：
- 传输层加密——OTA 下载必须走 TLS 或 DTLS，防止中间人篡改固件包。
- 固件包签名——固件包本身携带 ECDSA 签名，设备下载后先验签再写入。
- 回滚保护——设备必须记录当前固件版本号，禁止安装比当前版本更旧的固件。
回滚保护这块，我吃过亏。有一次客户反馈设备批量离线，查了半天发现是 OTA 服务器配置错了，把旧版本固件推给了设备。设备验签通过（签名没问题），但版本回退导致协议栈不兼容。从那以后，我坚持在固件头里加一个单调递增的版本计数器，硬件层面保证不能降级。
1. 下载完成后必须校验整个固件包的哈希。
2. 写入 Flash 时使用双备份区（A/B 分区），更新失败还能回滚到旧版本。
4.4 安全启动与 OTA 的完整流程
下面这张图，是我自己画的安全启动 + OTA 更新流程图。你可以把它当作一个「信任链全景图」来看。
从图上你能看到，安全启动和 OTA 其实是同一个信任链的延伸。BootROM 信任 Bootloader，Bootloader 信任应用固件，应用固件又通过 OTA 信任下一个版本的自己。每一环都靠签名说话。
4.5 常见问题与排查思路
最后，我列几个实际项目中经常遇到的问题，你可以对照排查：
- 设备启动卡死——先看 BootROM 有没有正常跑，用串口看启动日志。如果日志都没有，八成是硬件问题。
- OTA 更新失败——检查签名算法是否匹配。我遇到过厂商用了 SHA-256，设备端却只支持 SHA-1，结果验签永远过不了。
- 设备变砖——大概率是 A/B 分区没做好，或者回滚保护太死。建议保留一个「恢复模式」，通过物理按键强制进入。
- 验签通过但固件跑不起来——可能是固件头里的加载地址或大小字段错了。用 hexdump 对比一下原始固件和写入 Flash 的内容。