3. 固件签名与验证：PKI体系结构、X.509证书格式、固件签名流程、固件验证流程
固件签名这事儿，说白了就是给固件打上一个「防伪标签」。你想想看，设备在野外运行，怎么知道收到的固件更新是官方发的，还是黑客塞的？我早年做IoT网关项目时，就遇到过设备被刷入恶意固件导致整个网络瘫痪的案例。从那以后，我对签名验证这件事就特别较真。
这一章，我们就把PKI、X.509证书、签名和验证流程彻底讲透。嗯，内容有点硬核，但都是实战中必须啃下来的骨头。
3.1 PKI体系结构：信任的锚点
PKI（公钥基础设施）不是某个具体算法，而是一整套管理密钥和证书的框架。我个人习惯把它理解成「数字世界的户籍系统」——你得先证明你是谁，别人才敢信你。
PKI的核心角色有这几个：
- CA（证书颁发机构）：信任的根。它签发证书，也负责吊销证书。
- RA（注册机构）：帮CA做身份审核，但不直接签发证书。
- 证书持有者：比如固件签名用的私钥持有者。
- 依赖方：验证证书的一方，比如设备上的Bootloader。
这里有个关键点：信任链。根CA自签名，然后签发中间CA，中间CA再签发终端实体证书。设备只需要预置根CA证书，就能递归验证整条链。我在项目中见过有人直接把根私钥放在生产服务器上签名——这是大忌。根私钥必须离线存储，最好放在HSM里。
信任链验证原则：验证方只信任预置的根证书，中间证书和终端证书必须能回溯到这个根。任何一环断裂，验证就失败。
3.2 X.509证书格式：一张结构化的身份证
X.509是证书的标准格式。v3版本最常用，里面塞了很多扩展字段。我刚开始看证书结构时，觉得它就是个嵌套的ASN.1结构体，后来用openssl asn1parse解析过几次，才真正搞明白每个字段的用途。
一个典型的X.509 v3证书包含以下核心字段：
| 字段 | 说明 | 实战注意 |
|---|---|---|
| 版本号 | 目前几乎都是v3 | v1/v2已废弃，别用了 |
| 序列号 | CA分配的唯一整数 | 吊销时靠它定位 |
| 签名算法 | 如sha256WithRSAEncryption | 别用SHA1，不安全 |
| 颁发者 | CA的DN（Distinguished Name） | 必须与CA证书的Subject一致 |
| 有效期 | notBefore / notAfter | 固件证书建议设短有效期 |
| 主体 | 证书持有者的DN | 固件签名证书用设备类型或厂商名 |
| 公钥 | 算法+公钥值 | RSA 2048位起步，推荐ECC P-256 |
| 扩展 | Key Usage、Basic Constraints等 | 签名证书必须设置digitalSignature |
我的习惯：固件签名证书的Key Usage只保留digitalSignature，不要加keyEncipherment。多一个用途就多一分风险。
3.3 固件签名流程：从代码到安全镜像
签名不是把证书塞进固件就完事了。它有一套严格的步骤。我曾经在产线上遇到过签名脚本漏掉哈希校验的bug，导致一批设备无法升级——嗯，从那以后我写签名工具时都会加双重校验。
标准签名流程如下：
- 计算固件哈希：对原始固件二进制做SHA-256（或SHA-384）哈希。
- 签名哈希：用签名私钥对哈希值做非对称加密（RSA或ECDSA）。
- 封装签名数据：将签名值、证书链、固件版本号、哈希算法ID打包成签名块。
- 附加到固件：签名块通常追加在固件末尾，或嵌入固件头部的预留区域。
- 可选加密：如果固件需要保密，先加密再签名，或者先签名再加密。我个人推荐先签名后加密。
下面是一个简化的签名流程示意图：
避坑指南：我曾经在签名时忘记包含固件版本号，结果设备无法区分回滚攻击。攻击者拿着旧版本签名固件就能降级设备。版本号必须签在哈希里，不能只放在明文头部。
3.4 固件验证流程：信任的兑现
验证是签名的逆过程，但更复杂。因为验证方（Bootloader或安全芯片）资源受限，不能做太重的计算。我优化过一个基于Cortex-M4的验证流程，把RSA 2048验签时间从800ms压到了120ms——关键就是选对了算法和实现库。
标准验证流程：
- 提取签名块：从固件镜像尾部或头部解析出签名块。
- 验证证书链：从终端证书开始，逐级向上验证，直到信任的根证书。每一步检查签名、有效期、Key Usage、是否被吊销。
- 提取公钥：从验证通过的终端证书中取出公钥。
- 验签：用公钥解密签名值，得到哈希值A；同时计算当前固件的哈希值B。比较A和B。
- 检查版本号：确保固件版本不低于当前运行版本（防回滚）。
- 决定是否启动：全部通过则跳转执行，否则进入恢复模式。
这里有个容易被忽略的细节：证书吊销检查。很多设备不做这一步，结果就是私钥泄露后，攻击者拿着泄露的证书签的固件照样能通过验证。我建议至少支持CRL（证书吊销列表）或OCSP Stapling。
验证失败处理原则：任何一步失败，设备都不能执行新固件。不要尝试「部分验证」或「降级验证」。安全没有中间态。
3.5 实战中的证书配置策略
证书配置不是一次性的活儿。产品生命周期内，证书会过期、会泄露、需要轮换。我总结了几条经验：
- 根证书用ECC P-384：根证书长期有效，安全性要求高。ECC P-384比RSA 4096更快，密钥更小。
- 签名证书用ECC P-256或RSA 2048：平衡安全性和性能。P-256在资源受限设备上验签更快。
- 证书有效期：根证书5-10年，中间CA 2-3年，签名证书1年以内。我见过根证书设20年的项目——说实话，20年后SHA-256可能都不安全了。
- 密钥生成：必须在安全环境中生成。生产环境用HSM，开发环境用加密的PKCS#12文件。
- 证书存储：设备端只存根证书和中间CA证书。签名证书的私钥永远不上设备。
| 证书类型 | 推荐算法 | 推荐有效期 | 存储位置 |
|---|---|---|---|
| 根CA | ECC P-384 | 5-10年 | 离线HSM |
| 中间CA | ECC P-256 | 2-3年 | 在线HSM或安全服务器 |
| 固件签名证书 | ECC P-256 / RSA 2048 | 1年 | 签名服务器（私钥加密存储） |
| 设备端信任锚 | — | 与设备生命周期一致 | 设备OTP或安全存储 |
我的建议：在开发阶段就用自动化脚本管理证书生命周期。手动生成证书太容易出错了——我见过有人把测试证书签到了生产固件上，结果设备全部验证失败。CI/CD流水线里加上证书有效性检查，能省很多麻烦。