OTA升级包签名被伪造，13万辆车被迫召回：签名链路安全怎么做才对？
一、一次代价13万台的OTA签名事故
2024年底，欧洲某主流品牌发布紧急召回：旗下13万台纯电动车的OTA升级包签名验证环节存在漏洞，攻击者可以伪造升级包，在车辆静止时刷入恶意固件。
召回公告里的技术描述是冷冰冰的，但背后的过程很真实：
这家厂商的OTA签名链路是这样的——升级包在云端签名，签名服务器调用HSM做SHA-256哈希 + RSA-2048签名，签完把签名值打进升级包头，车端ECU收到升级包后做验签，通过才允许刷写。
听起来没毛病，对吧？
问题出在"签名服务器调用HSM"这个环节：签名服务器和HSM之间的通信，用的是明文TCP套接字，没有做双向认证。内网里任何一台被渗透的机器，都可以伪装成签名服务器，向HSM发送"请签名这段数据"的请求——HSM无法区分请求是来自合法的签名服务，还是来自攻击者。
最终攻击者通过一台被攻陷的编译服务器，绕过了整个签名链路，成功伪造了合法签名。
二、OTA签名链路的五个关键节点
一次完整的OTA签名，实际上要经过以下五个节点：
[ 固件编译完成 ] ↓ [ 签名请求发起（签名服务）] ↓ ← ⚠️ 最容易被绕过的节点 [ HSM / KMS 签名执行 ] ↓ [ 签名值写入升级包 ] ↓ [ 车端ECU验签 ] ↓ [ 刷写执行 ]
每个节点，都是一次潜在的攻击面。
节点1：签名请求发起
这是整个链路的第一道门。签名服务在发起签名请求时，必须证明自己的身份。
正确做法：
- 签名服务持有自己的服务身份证书（非对称密钥对）
- 向HSM发送签名请求时，附带自己的数字签名（证明请求确实来自签名服务）
- HSM验证签名服务的身份证书，只接受白名单内的服务发起的签名请求
错误做法（上面召回案例的做法）：
- 签名服务通过IP白名单做鉴权 → 内网IP伪造可以实现绕过
- 签名服务通过共享密钥（对称密钥）做鉴权 → 密钥一旦在编译服务器上被窃取，全线失守
节点2：HSM签名执行
HSM（硬件安全模块）是签名链路的信任根。私钥永远不能离开HSM。
但现实里有很多"看起来是HSM，实际上不是"的方案：
| 方案 | 私钥是否出HSM | 合规性 | 风险 |
|---|---|---|---|
| 硬件HSM（FIPS 140-2 L3） | ❌ 不出 | 满足 | 低 |
| 软件HSM（软算法库） | ✅ 出（内存中） | 不满足 | 高 |
| 云KMS（BYOK模式） | ❌ 不出 | 满足（需审计） | 中 |
| TPM/Secure Element | ❌ 不出 | 满足（算力度弱） | 低 |
关键原则：用来给OTA升级包签名的私钥，必须放在FIPS 140-2 Level 3及以上的硬件环境里。
节点3：签名值写入升级包
签名值写入升级包时，必须同时写入签名元数据：
- 签名算法标识（防止算法降级攻击）
- 签名时间戳（防止重放攻击）
- 签名者证书链（车端验签时需要验证证书链）
很多厂商只写入签名值本身，不写入完整元数据——这导致车端ECU无法做完整的证书链验证，只能验证签名值，变相降低了安全门槛。
节点4：车端ECU验签
这是整个链路的最后一道防线。
ECU验签的正确流程：
- 检查升级包格式完整性（头部校验和）
- 提取签名值和签名者证书链
- 验证证书链（根证书必须预置在ECU安全存储区）
- 用签名者的公钥验证签名值
- 检查签名时间戳（拒绝超过有效期的签名）
- 全部通过→ 才允许固件刷写
现实中的缩水版验签（不推荐）：
- 只验证签名值，不验证证书链 → 攻击者可以用自签名证书伪造
- 证书链验证但不检查吊销状态 → 私钥泄露后的时间窗口无法关闭
节点5：刷写执行
即便验签通过，刷写执行阶段也要做分段校验：每写入一个固件段，就做一次哈希校验，确保刷写过程中没有被篡改。
三、国密算法在OTA签名中的落地
2026年7月1日之后，新申请车型必须支持国密算法（SM2/SM3/SM4）。OTA签名链路也要同步支持国密。
SM2 vs RSA：实际性能对比
| 指标 | SM2 (256bit) | RSA (2048bit) | 说明 |
|---|---|---|---|
| 签名速度 | ~10ms | ~50ms | SM2快5倍 |
| 验签速度 | ~3ms | ~2ms | 差距不大 |
| 签名长度 | 64字节 | 256字节 | SM2短很多 |
| 升级包大小影响 | 小 | 大（每台车省~200字节） | 对大批量OTA有影响 |
结论：SM2在签名侧性能优势明显，对云端签名服务器的并发处理能力帮助很大。车端验签性能差距不大，两个算法都在毫秒级。
国密落地的三个注意点
注意点1：双算法并行过渡期
2026年7月之前的在售车型，已经用了RSA做OTA签名。7月之后不能一刀切换成SM2——已经下发的车端ECU不支持SM2验签。
正确做法：升级包同时携带RSA签名和SM2签名，车端ECU根据自己支持的算法做对应验签。过渡期建议保留3年。
注意点2：HSM的国密认证
用来做SM2签名的HSM，必须拿到国密局的商用密码产品认证证书。市面上很多标榜"支持国密"的HSM，实际上是在通用HSM上跑国密软件算法——这不满足合规要求。
注意点3：根证书的国有化
SM2签名体系需要一套独立的国密证书链。根证书建议由国密局认可的CA机构签发，而不是企业自建根。否则在合规性审查时会遇到麻烦。
在密钥管理基础设施中，可选用支持国密算法的KMS（如安当KMS）统一管理SM2密钥对和证书生命周期，确保签名链路与合规要求对齐。
四、三条马上可以做的改进
如果你负责OTA系统，这三条可以马上自查：
① 检查签名服务与HSM之间的通信是否加密、是否有双向认证
拿一台内网机器，尝试直接TCP连接HSM的签名端口——如果能连上并且发送签名请求成功，说明链路缺乏认证。
② 检查车端ECU是否验证完整的证书链
找一份OTA升级包，把里面的签名者证书换成自签名证书，看ECU是否拒绝——如果通过，说明证书链验证缺失。
③ 检查是否有签名日志审计
每次签名操作（谁、什么时候、签了什么固件）必须有不可篡改的审计日志。这是ISO 21434合规的强制要求。
OTA签名链路不是一个"加了签名就安全"的问题。它是密码学、硬件安全、软件开发流程三个域的交叉点，任何一个节点的疏忽，都会让整个链路归零。
你们公司的OTA签名链路，是哪种方案？有没有做过签名绕过的渗透测试？
\n篇幅所限，国密SM4在固件加密传输中的应用，下篇文章展开讲。