4、固件安全基线：固件签名与校验、安全启动链（Secure Boot）、固件加密与防回滚机制
固件安全，说白了就是设备的「出厂设置」到底靠不靠谱。我见过太多企业，买了摄像头、网关、传感器回来，直接连上内网就用。结果呢？攻击者通过一个未签名的固件漏洞，直接拿到了设备 root 权限。嗯，今天我们就来聊聊固件安全的四个核心防线。
核心观点：固件安全不是单一技术，而是一条从「代码是谁写的」到「代码是否被篡改」再到「代码是否过期」的完整信任链。
4.1 固件签名与校验：给固件贴上「防伪标签」
固件签名，本质上就是给二进制文件打上一个数字签名。谁打的？设备厂商的私钥。谁验证？设备启动时的 Bootloader 或者安全芯片。
我习惯把签名校验分成两个阶段：
- 构建阶段：厂商用私钥对固件哈希签名，生成签名文件。
- 部署阶段：设备用预置的公钥验证签名是否匹配。
这里有个常见的坑——公钥存储位置。我曾经见过一个项目，公钥直接明文写在 Flash 里，攻击者读出来就能伪造签名。正确的做法是：
- 公钥存储在一次性可编程（OTP）区域
- 或者由硬件安全模块（HSM）保护
- 再或者，至少也要做公钥的完整性校验
我的经验：签名算法别用 MD5 或 SHA-1 了。现在至少 SHA-256 起步，配合 RSA-2048 或 ECDSA。我在一个智能门锁项目里用过 ECDSA，签名长度短，对资源受限的 IoT 设备很友好。
4.2 安全启动链（Secure Boot）：从第一行代码开始信任
Secure Boot 不是单个校验点，而是一条链。你想想看，设备上电后，最先执行的是 ROM 里的 BootROM。BootROM 校验 Bootloader，Bootloader 校验 OS Kernel，Kernel 校验文件系统……每一级都验证下一级的签名。
这就是所谓的「信任链传递」。只要第一级（Root of Trust）是安全的，后面的信任就能一级级传递下去。
这里有个关键点：BootROM 必须是硬件写死的，不能通过软件更新。我遇到过一家厂商，BootROM 居然放在可擦写的 Flash 里，结果被攻击者直接替换了。嗯，这等于把保险柜的钥匙挂在门上。
警告：Secure Boot 不是「配置一下就能用」的功能。它需要芯片级支持。采购 IoT 设备时，务必确认芯片是否支持 eFuse 或 OTP 来存储根信任公钥。没有硬件信任根的 Secure Boot，都是纸老虎。
4.3 固件加密：防的不是用户，是物理接触
签名解决的是「固件是否被篡改」，加密解决的是「固件是否被偷看」。你想想看，攻击者如果拿到你的设备，拆开外壳，用 SPI Flash 编程器直接读 Flash 内容，固件就裸奔了。
固件加密通常有两种模式：
| 模式 | 加密范围 | 密钥存储 | 典型场景 |
|---|---|---|---|
| 全盘加密 | 整个 Flash | 芯片内置密钥 | 高安全要求设备 |
| 分区加密 | 仅敏感分区 | OTP 或 Key Ladder | 资源受限设备 |
我个人更推荐分区加密。全盘加密虽然安全，但解密速度慢，而且密钥一旦泄露，所有固件都得重新加密。分区加密的话，你可以只加密核心算法、配置文件和私钥区域，Bootloader 和 Kernel 保持明文（反正有签名保护）。
避坑指南：我曾经遇到一个项目，工程师把 AES 密钥硬编码在代码里，还觉得「反正代码也加密了」。结果攻击者通过侧信道攻击拿到了密钥。记住：密钥永远不要和加密数据放在同一个存储介质里。用 HSM 或 TEE 来保护密钥，才是正道。
4.4 防回滚机制：堵住「降级攻击」的漏洞
防回滚，说白了就是「新固件可以装，旧固件不能装」。为什么？因为攻击者经常利用旧版本固件的已知漏洞来攻击设备。你辛辛苦苦打了补丁，攻击者一个降级操作，所有努力白费。
实现防回滚，常见做法有三种：
- 版本号校验：固件头里带版本号，Bootloader 检查新版本号必须大于等于当前版本号。
- 熔丝（eFuse）方案：每次升级后，烧断一组熔丝，表示「这个版本已经用过了」。硬件不可逆。
- 安全计数器：在安全存储区维护一个单调递增的计数器，每次升级计数器加一。
这里我要特别说一下版本号校验的坑。纯软件版本号校验，攻击者可以修改版本号字段。我见过一个案例，攻击者把固件头的版本号改成 99.99.99，然后刷入一个旧版本固件，设备直接「升级」成功。嗯，这就是典型的「版本号欺骗」。
警告：防回滚必须结合签名校验一起使用。版本号字段本身也要被签名保护。否则，攻击者可以同时篡改版本号和固件内容。另外，熔丝方案虽然安全，但一旦烧断就无法恢复，生产测试时要格外小心。
4.5 四道防线的协同工作
签名、安全启动、加密、防回滚，这四者不是孤立的。它们共同构成一个完整的固件安全体系：
- 签名保证固件来源可信
- 安全启动保证运行过程可信
- 加密保证存储内容保密
- 防回滚保证版本更新不可逆
我习惯用一个简单的检查清单来评估设备固件安全水平：
| 检查项 | 合格标准 | 常见失败原因 |
|---|---|---|
| 固件签名 | 使用 SHA-256 + RSA-2048 或 ECDSA | 使用 MD5、SHA-1、或未签名 |
| 安全启动 | 硬件信任根 + 链式校验 | BootROM 可写、公钥未保护 |
| 固件加密 | 分区加密 + 密钥独立存储 | 密钥硬编码、全盘加密性能不足 |
| 防回滚 | 硬件熔丝或安全计数器 | 纯软件版本号、未签名版本号 |
最后说一句：固件安全基线不是「做完就完事」的。设备出厂后，密钥管理、升级策略、应急响应，每一步都可能出问题。但至少，先把这四道防线立起来。剩下的，我们后面章节慢慢聊。