3. 公钥基础设施
固件签名验签并不是“拿一个公钥去解签名”这么简单。真正决定安全强度的是:这个公钥从哪来、它是否可信、它是否仍然有效、它是否被吊销、它对应的私钥是否还在受控状态。公钥基础设施(PKI)正是为回答这些问题而存在的一整套体系。在固件场景中,PKI 把“信任”从单个密钥扩展为可管理、可撤销、可审计的信任网络。
核心原理:证书、CA 与信任链
PKI 的基本构件是数字证书。证书把“公钥”和“身份信息”绑定在一起,并由一个可信第三方——CA(证书颁发机构)——用其私钥对绑定内容签名。固件验签时,设备并不直接信任固件签名公钥,而是先验证该公钥的证书是否由受信任的 CA 签发。
当存在多级 CA 时,就形成信任链:根 CA 自签名并预置在设备信任库中;中间 CA 由根 CA 签发;固件签名证书由中间 CA 签发。验签过程是自下而上逐级验证签名,直到锚定到设备内置的根证书。任何一级签名失败、有效期越界或用途不符,整条链即判定为不可信。
固件场景的关键约束:设备端通常没有实时网络、没有完整证书库、算力和存储受限。因此信任链必须“短而稳”,根证书必须固化在不可篡改区域(如 OTP、ROM 或受保护的密钥槽),中间 CA 数量应尽量少,以降低验证开销和信任面。
吊销机制:CRL 与 OCSP
证书在有效期内也可能因私钥泄露、设备退役或误签发而需要提前失效,这就是吊销。PKI 提供两种主要查询方式:
- CRL(证书吊销列表):CA 定期发布被吊销证书序列号的列表,设备下载后本地比对。优点是离线可用、实现简单;缺点是列表可能很大、更新有延迟,且设备需要存储空间。
- OCSP(在线证书状态协议):设备向 OCSP 响应器实时查询某张证书的状态,返回“有效 / 吊销 / 未知”。优点是实时、响应小;缺点是需要网络,且存在隐私与可用性问题,可配合 OCSP Stapling 缓解。
在固件启动认证中,若设备完全离线,通常采用“短有效期证书 + 定期联网刷新 CRL”或“启动时不做吊销检查、由更新服务端把关”的折中策略。需要明确:吊销检查的缺失是风险,而不是漏洞,必须在威胁模型中显式记录。
密钥生命周期管理
密钥不是“生成一次用一辈子”。完整的生命周期包括:生成、分发、使用、轮换、归档、吊销和销毁。固件场景中,最敏感的是签名私钥,它通常存放在 HSM(硬件安全模块)中,永不导出;设备端的验签公钥或根证书则固化在只读区域,防止被替换。
| 阶段 | 固件场景做法 | 风险点 |
|---|---|---|
| 生成 | 在 HSM 内生成非对称密钥对,私钥不出模块 | 弱随机数导致密钥可预测 |
| 分发 | 公钥/根证书烧录到设备 OTP 或受保护分区 | 产线被篡改,植入攻击者根证书 |
| 使用 | 签名服务调用 HSM 完成固件签名 | 签名接口被滥用,签出恶意固件 |
| 轮换 | 预置下一代根证书,支持双证书过渡 | 轮换窗口设计不当导致设备变砖 |
| 吊销 | 通过 CRL/OCSP 或服务端黑名单标记失效 | 离线设备无法及时获知吊销 |
| 销毁 | HSM 密钥安全删除,旧证书归档留审计 | 残留密钥材料被恢复 |
案例场景:一次固件签名证书轮换
某厂商的固件签名证书有效期 3 年,设备内置根 CA 和一张中间 CA 证书。轮换时,若直接替换中间 CA,已出厂设备将无法验证新固件。正确做法是:在设备出厂前预置“当前 + 下一代”两张中间 CA 证书,验签逻辑支持遍历信任链;新固件用下一代证书签名,旧设备仍能通过预置的下一代中间 CA 完成验证。轮换完成后,再通过一次固件更新移除旧中间 CA。
# 设备端信任库示例(伪配置)
trust_anchors:
- root_ca.pem
intermediate_cas:
- intermediate_2024.pem # 当前
- intermediate_2027.pem # 下一代,预置
verify_order: [current, next]
revocation:
mode: crl
crl_url: https://pki.example.com/fw.crl
refresh_interval: 7d
误区与复盘
误区一:把根证书当普通文件放在可写分区。攻击者一旦替换根证书,就能用自签证书通过验签。根证书必须固化在不可篡改介质中。
误区二:忽略证书用途字段。签名证书的 Key Usage 应包含 digitalSignature,Extended Key Usage 应明确为代码签名。若验签逻辑不检查用途,可能被其他类型证书冒用。
误区三:认为“有证书就等于安全”。证书只是信任载体,私钥保护、吊销机制、轮换策略和产线安全同样决定最终强度。
复盘时建议检查三点:信任链是否锚定到不可篡改根、吊销策略是否与设备联网能力匹配、密钥轮换是否预留了双证书过渡窗口。这三点决定了 PKI 在固件场景中是否真正可用,而不只是“纸面合规”。