一、Secure Boot：上电即验证
Secure Boot（安全启动）是 ECU 最底层的一道防线。它的逻辑很朴素：控制器每次上电，先验证待执行固件的数字签名，只有签名来自可信私钥，才放行执行；否则直接拒绝启动。
这保证了"即便攻击者把恶意固件刷进了存储芯片，芯片上电时也不会运行它"。对 ADAS 域控、动力域、车身域等安全关键 ECU 而言，这一机制是功能安全与网络安全的共同基础。
而信任链能否成立，完全取决于一个前提：签名私钥是可信且受保护的。
二、签名私钥泄露 = 信任链崩塌
如果签名私钥可以轻易被获取，Secure Boot 就等于形同虚设------攻击者能用同一把私钥给任意恶意固件签名，芯片会"心甘情愿"地执行。
传统代码签名方案的薄弱环节很典型：
- 签名私钥存放在构建服务器的文件系统里，内部人员可复制；
- 构建系统被入侵，密钥随之泄露；
- 多个项目共用一套签名密钥，单点泄露影响全线产品；
- 签名操作无审计记录，出事后无法溯源责任。
上图（内容图）对比了"私钥存服务器"与"私钥在 HSM"两种模式的信任链差异：前者密钥可被提取，后者密钥生成并永久驻留硬件，签名运算在加密机内闭环。
三、CI/CD 如何在不接触密钥的情况下签名
现代车企的固件构建跑在 CI/CD 流水线上，开发者频繁提交、自动构建。要求"开发者不能接触密钥"与"构建需要签名"看似矛盾，解法是用代理式签名：
- 构建流水线完成编译后，把固件文件（或摘要）通过 API 提交给密钥管理系统；
- 密钥管理系统将请求转发至 HSM，由硬件内部用签名私钥完成签名运算；
- HSM 返回签名结果，流水线把签名写入固件镜像；
- 开发者与 CI 节点全程不接触私钥明文。
以安当CAS为例，其固件签名服务即采用这种 API 代理模式：CI/CD 流水线提交固件，CAS 调用 HSM 完成 RSA/ECDSA/SM2 签名并返回结果，签名私钥生成并永久驻留 HSM 永不导出；每次签名请求留存完整日志，支持合规审计。开发者拿到了自动签名能力，安全团队保住了密钥不出硬件。
四、按车型/版本隔离签名密钥
一个常被忽视的风险点是"所有车型共用一把签名密钥"。一旦这把密钥需要轮换（或泄露），影响范围是全产品线的所有 ECU------召回与重签成本极高。
更稳健的做法是按车型/版本分配独立签名密钥，配合项目隔离管理：
- 单车型密钥轮换不影响其他车型；
- 某项目密钥泄露，影响面被限制在对应车型；
- 密钥与车型绑定，便于合规审计时按项目追溯。
安当CAS 支持按车型/平台/供应商划分项目，为不同项目分配独立签名密钥与管理员、操作员、审计员三类角色，正是针对上述隔离需求。
五、小结
Secure Boot 的可靠性，不取决于验证算法有多强，而取决于签名私钥有多安全。把私钥生成与运算锁进 HSM、用 CI/CD 代理式签名消除"开发者接触密钥"的难题、再辅以车型级密钥隔离，汽车固件的信任链才算真正闭合。
方案参考：安当CAS（汽车密钥管理系统）提供固件签名服务，对接 FIPS 140-2/3 认证 HSM，签名私钥永不导出，支持 RSA/ECDSA/SM2 与 CI/CD API 代理签名、按车型/项目隔离签名密钥及全链路审计，满足 GB 44495、UNECE R155/R156 对固件签名与 Secure Boot 的合规要求。