汽车固件签名：从 “纸面安全” 到治理觉醒

一句话答案：签名不是终点，而是起点 —— 真正的安全，在于谁签的、用什么签的、签了之后能不能管得住。

---

一、“我们签了名，车还是被刷了”

去年底，朋友老李 —— 新势力车企的 OTA 平台负责人 —— 在饭局上喝多了，半开玩笑半认真地说：“我们每版 ECU 固件都签了名，结果黑客还是通过售后诊断口，刷进了一段带后门的 Bootloader。你说气不气？”

我问：“签名没校验？”

他摇头：“校验了，但密钥三年没换，算法还是 SHA1+RSA1024…… 更糟的是，那把私钥，就存在一个普通 Windows 服务器上，运维都能直接访问。”

这不是孤例。

随着智能汽车普及，整车 ECU 数量突破 100 个，从动力域到座舱域，从 T-Box 到毫米波雷达，每个模块都要频繁 OTA 升级。而固件签名，成了保障升级安全的第一道防线。

但现实是：

• 签名流程跑通了，就算 “安全落地”；
• 私钥存在共享文件夹里；
• 算法多年不更新；
• 离职员工仍能签发固件；
• 一旦出事，无法追溯是谁签的哪一版。

问题本质：很多车企把签名当成 “交付前的一个勾选项”，而不是 “贯穿研发 - 生产 - 售后的安全治理闭环”。

---

二、第一阶段：“能签就行”—— 签名即合规

五年前，行业对固件签名的要求很简单：“只要能验证就行”。

典型做法：

• 用 OpenSSL 生成一对 RSA 密钥；
• 私钥存开发机D:\keys\ecu_private.key；
• 构建脚本调用openssl dgst -sign生成签名；
• ECU 启动时用公钥验签。

听起来没问题？但隐患早已埋下：

风险 1：私钥裸奔

• 开发、测试、运维多人共用同一把私钥；
• 无访问日志，不知道谁用了密钥；
• 服务器被入侵，私钥直接泄露。

风险 2：算法过时

• 仍在用 MD5/SHA1，已被证明可碰撞；
• RSA 密钥长度 1024 位，现代算力可破解。

风险 3：无版本控制

• 同一把密钥签所有 ECU、所有版本；
• 一旦怀疑泄露，只能全车召回换密钥 —— 成本超亿元。

这个阶段的核心逻辑是：“只要流程跑通，监管检查能过，就行。”

结果：签名成了 “纸面安全”，经不起实战检验。

---

三、第二阶段：“签得规范”—— 引入 CAS 体系

随着 UNECE R155/R156 法规落地，以及 ISO/SAE 21434 标准推行，车企意识到：签名必须体系化。

于是，“汽车固件签名系统”（CAS, Car Authentication System）开始登场。

它的核心升级有三点：

1. 密钥分层管理

不再一把密钥打天下，而是建立信任链（Chain of Trust）：

[根密钥 Root CA] ←─ 离线保存，十年不用一次
     │
     ▼
[中间密钥 Sub CA] ←─ 按域划分：动力域CA、座舱域CA、底盘域CA
     │
     ▼
[ECU设备证书] ←─ 每个ECU出厂预置唯一证书

• 根密钥由安全委员会保管，物理隔离；
• 中间 CA 用于日常签发，可定期轮换；
• 即使某个域 CA 泄露，不影响其他域。

2. 硬件级密钥保护

私钥不再存文件系统，而是放入：

• HSM（硬件安全模块）：如 Thales、江南科友；
• eSIM/eHSM：集成在 T-Box 或域控制器中；
• 国密芯片：支持 SM2/SM3 算法，满足国内合规。

效果：私钥永不离开硬件，即使服务器被控，也无法导出。

3. 签名流程标准化

• 签名需审批：开发提交 → 安全团队审核 → 自动签名；
• 签名记录审计：谁、何时、签了哪个版本、用哪个 CA；
• 支持国密算法：SM2 签名 + SM3 摘要，替代 RSA+SHA256。

这个阶段的目标是：“让签名过程本身不可篡改、可追溯、可审计。”

---

四、第三阶段：“签后能管”—— 走向安全治理

但问题还没完。

某车企曾遇到这种情况：

• OTA 平台推送了一个合法签名的固件；
• 结果该固件包含高危漏洞；
• 黑客利用漏洞提权，再刷入未签名恶意代码。

签名只保证 “来源可信”，不保证 “内容安全”。

于是，领先的车企开始把 CAS 从 “签名工具” 升级为 “固件安全治理平台”。

治理能力 1：签名与 SBOM 联动

• 每次签名前，自动扫描固件的软件物料清单（SBOM）；
• 若包含已知 CVE 漏洞组件（如 Log4j），自动拦截签名；
• 实现 “不安全的固件，连签名资格都没有”。

治理能力 2：动态吊销机制

传统做法：一旦怀疑密钥泄露，只能召回换密钥 —— 几乎不可能。

新做法：

• ECU 支持证书吊销列表（CRL）或 OCSP 在线验证；
• 安全中心发现异常签名，立即吊销对应证书；
• 后续 OTA 升级自动拒绝被吊销证书签发的固件。

案例：某供应商私钥泄露，车企 2 小时内吊销其 CA 证书，避免百万辆车风险。

治理能力 3：全链路追溯

从代码提交到车辆运行，全程绑定签名信息：

环节	关联签名数据
Git 提交	关联开发者证书
CI 构建	记录构建环境指纹
签名	记录 CA、时间、审批人
OTA 推送	绑定车辆 VIN、ECU 序列号
ECU 运行	日志上报当前固件签名哈希

效果：一旦出问题，5 分钟内定位到 “哪个开发者、在哪台机器、用哪个版本、签了哪辆车”。

---

五、真实挑战：车企落地 CAS 的三大坎

坎 1：历史 ECU 不支持新签名机制

• 老车型 ECU 资源有限，只认 RSA，不支持证书链；
• 解法：采用 “双轨制”—— 新车用 CAS，老车维持旧签名，但加强网络隔离。

坎 2：供应商协同难

• 100 + 供应商，有的连 CI/CD 都没有；
• 要求他们接入 CAS？阻力巨大。
• 解法：提供 “签名即服务”（Signing-as-a-Service）—— 供应商上传固件，车企统一签名，密钥完全自主。

坎 3：性能与安全的平衡

• 座舱域 ECU 启动时间要求 < 2 秒，验签不能拖慢；
• 解法：
  • 使用 SM2（比 RSA 快 3 倍）；
  • 验签并行化（多核 ECU）；
  • 关键模块（如 Bootloader）强验签，非关键模块弱验证。

---

六、某头部车企实践：从 “被动合规” 到 “主动防御”

背景

• 年产 50 万辆智能电动车；
• 8 大域控制器，200+ECU 类型；
• 曾因供应商固件漏洞导致大规模 OTA 回滚。

他们的 CAS 演进路径

阶段 1（2020）：完成签名

• 用脚本 + OpenSSL 实现基础签名；
• 通过 ASPICE L2 认证。

阶段 2（2022）：体系化

• 引入 HSM 保护根密钥；
• 按域划分 CA；
• 签名流程接入 Jenkins 审批。

阶段 3（2024）：治理化

• 自建 CAS 平台，集成：
  • 国密 SM2/SM3 支持；
  • SBOM 漏洞扫描；
  • 证书吊销中心；
  • 全链路审计看板。
• 供应商通过 API 提交固件，平台自动签名并返回结果。

成果

• 固件签名 100% 自动化，人工干预归零；
• 密钥泄露风险下降 90%；
• 顺利通过 UNECE R155 国际认证；
• 一次拦截含高危漏洞的供应商固件，避免潜在召回损失超 2 亿元。

老李后来跟我说：“现在我不怕签名了，我怕没签名。”

---

七、自研还是采购？理性选择

很多车企纠结：“CAS 要不要自己做？”

先看自研成本：

• 需要密码学专家（稀缺）；
• 需对接 HSM、KMS、CI/CD、OTA 平台；
• 需通过国密认证、等保三级、ISO 21434；
• 长期维护密钥轮换、算法升级、应急响应。

现实是：除非是特斯拉、比亚迪这种年销百万辆的巨头，否则 ROI 极低。

更优解：采用成熟 CAS 平台，专注业务创新。

在上海，已推出面向汽车行业的 CAS 固件签名治理平台。它支持：

• 国密 SM2/SM3/SM9 全栈算法；
• 与主流 HSM（江南科友、飞天诚信）深度集成；
• 提供供应商自助签名门户；
• 内置 UNECE R155/ISO 21434 合规模板；
• 已在多家新势力和 Tier1 落地。

不是所有安全基建都值得重造，尤其是涉及密码学和合规的。

---

八、未来：签名只是入口，安全才是生态

随着 SOA 架构、中央计算平台兴起，汽车软件将更像 “智能手机”—— 应用可动态安装、服务可远程更新。

未来的 CAS 将不止于签名，而是演进为：

• 应用市场安全网关：所有车载 APP 上架前强制签名 + 沙箱检测；
• 运行时完整性监控：ECU 持续校验内存中代码是否被篡改；
• 零信任 OTA：每次升级都验证设备身份 + 固件合法性 + 网络环境。

而这一切的起点，是把签名从 “流程终点” 变成 “治理起点”。

---

九、写在最后：别让签名成为 “安全幻觉”

回到开头的问题：“我们签了名，车还是被刷了”—— 为什么？

因为签名只是信任的载体，不是信任本身。

真正的安全，来自于：

• 密钥是否真正受控？
• 算法是否足够强壮？
• 流程是否可审计？
• 出事后能否快速止损？

如果这些没做到，那么 “完成签名”，不过是给自己一张 “安全幻觉” 的安慰券。

而聪明的车企已经明白：签名的价值，不在 “签” 那一刻，而在 “签之后” 的每一分钟。

文章作者：五台