4. 可信发布基础
车载固件可信发布的核心问题不是“文件能不能传下去”，而是“接收方凭什么相信这个文件来自合法发布者、内容没有被篡改、并且确实适用于当前车型与ECU”。要回答这个问题，必须建立一套从可信根出发、经由证书与签名逐级传递的信任体系。本节围绕可信根、信任链、哈希、非对称加密、数字签名、证书体系与PKI，说明它们在车载场景中的组合方式与工程落地要点。
一、核心原理：信任必须从不可变的锚点开始
可信根（Root of Trust, RoT）是整个信任体系的起点，通常由硬件提供，例如HSM、SHE、TPM或芯片内固化的一次性可编程区域。可信根具备三个特征：不可篡改、可验证、可度量。它保存根公钥或根证书的哈希，并在启动或升级时作为第一个被信任的对象。
信任链（Chain of Trust）是把可信根逐级延伸到应用固件的过程。每一级在加载下一级之前，先用上一级公钥验证下一级的签名或哈希，验证通过才移交执行权。车载场景中常见的层级为：硬件可信根 → BootROM → 一级引导 → 二级引导 → 操作系统/RTOS → 应用固件。任何一级验证失败，都应停止启动或回滚到已知安全版本。
关键结论：哈希保证完整性，非对称加密保证来源真实性，数字签名把两者绑定，证书体系解决公钥分发问题，PKI负责证书的签发、吊销与生命周期管理。可信根与信任链则决定这些机制在设备上“从哪里开始被相信”。
二、哈希、非对称加密与数字签名如何协同
哈希算法把任意长度固件映像压缩为固定长度摘要，例如SHA-256输出32字节。它的价值在于：输入微小变化会导致摘要显著不同，且难以从摘要反推原文。车载固件体积大，直接对整包做非对称运算代价高，因此标准做法是“先哈希、再签名”。
非对称加密使用一对密钥：私钥签名，公钥验签。发布方在受控环境中用私钥对固件摘要签名，车辆端用预置公钥验证签名。私钥不出签名服务器或HSM，公钥可以公开分发。数字签名把“摘要值”和“发布者身份”绑定在一起，使接收方能够同时确认完整性与来源。
# 典型固件签名与验签流程（示意）
sha256sum firmware_v2.3.1.bin
# 输出：9f2c...e1a7 firmware_v2.3.1.bin
openssl dgst -sha256 -sign release_private.pem \
-out firmware_v2.3.1.sig firmware_v2.3.1.bin
openssl dgst -sha256 -verify release_public.pem \
-signature firmware_v2.3.1.sig firmware_v2.3.1.bin
# 输出：Verified OK
在车载ECU端，验签通常由HSM或安全启动代码完成，而不是由应用层软件完成。这样可避免应用被攻破后绕过验签逻辑。验签通过后，系统还应检查版本号、车型适配标识、防回滚计数器等元数据，防止合法签名的旧版本被重放。
三、证书体系与PKI在车载场景中的落地
如果每辆车的ECU都直接预置发布方公钥，密钥轮换和车型差异会带来巨大维护成本。证书体系通过CA（证书颁发机构）解决这一问题：根CA签发中间CA，中间CA签发发布者证书或ECU证书。车辆端只需信任根CA，即可验证由该CA体系签发的所有合法证书。
PKI在车载场景中不仅用于固件签名，还用于车云通信、诊断授权、OTA通道建立和V2X身份认证。一个典型的车载PKI层次如下：
- 根CA：离线保存，生命周期长，仅签发中间CA。
- 中间CA：按用途划分，如固件签名CA、车云通信CA、诊断CA。
- 发布者证书：绑定固件签名私钥，由固件签名中间CA签发。
- ECU证书：绑定车辆或ECU身份，用于双向TLS和诊断会话。
- CRL/OCSP：用于吊销泄露或过期的证书，车辆端需支持离线缓存与定期更新。
车载PKI与互联网PKI的关键差异在于：车辆可能长期离线，证书更新不能依赖实时在线；ECU资源受限，证书链长度和验签算法需裁剪；车辆生命周期长达10年以上，根CA和算法必须考虑后量子迁移路径。
四、车载场景中的典型流程与参数清单
以一次OTA固件发布为例，可信发布流程可概括为：构建产物 → 计算哈希 → 私钥签名 → 打包签名与证书链 → 上传发布平台 → 车辆下载 → 验证证书链 → 验证签名 → 校验元数据 → 写入备用分区 → 重启切换。每一步都需要明确的失败处理策略。
| 环节 | 关键对象 | 典型参数/算法 | 失败处理 |
|---|---|---|---|
| 可信根 | HSM/SHE/OTP | 根公钥哈希、安全启动使能 | 停止启动，进入恢复模式 |
| 哈希 | 固件映像 | SHA-256、SM3 | 拒绝安装，记录安全日志 |
| 签名 | 发布者私钥 | ECDSA P-256、RSA-3072、SM2 | 验签失败，丢弃升级包 |
| 证书链 | 根CA→中间CA→发布者 | X.509 v3、证书有效期 | 链不完整或过期则拒绝 |
| 元数据 | 版本、车型、ECU ID | 防回滚计数器、适配白名单 | 不匹配则拒绝安装 |
| 吊销 | CRL/OCSP | 离线缓存、定期同步 | 证书被吊销则拒绝 |
五、案例与误区复盘
某主机厂曾出现一次OTA升级失败：车辆端验签通过，但安装后无法启动。排查发现，发布方对固件签名正确，但打包时误将测试车型的适配标识写入元数据，导致目标ECU加载了不匹配的固件。这说明“签名正确”不等于“发布正确”，元数据校验与签名验证同等重要。
另一个常见误区是把哈希当作签名使用。仅提供SHA-256摘要，攻击者可以同时替换固件和摘要，接收方无法确认来源。哈希只能防意外损坏，不能防恶意篡改。只有数字签名才能把摘要与发布者身份绑定。
排障提示：当车辆端报“签名验证失败”时，应按以下顺序排查：证书链是否完整且未过期；根CA是否与车辆预置一致；签名算法是否在ECU支持列表内；固件是否在传输中被截断；系统时间是否错误导致证书有效期判断异常；防回滚计数器是否已超过当前版本。
在工程实践中，建议将签名私钥保存在HSM中并设置双人授权，证书链长度控制在3级以内，ECU端预置根CA哈希而非完整根证书以节省空间，同时为离线车辆设计证书吊销的缓存与宽限期策略。只有把可信根、信任链、哈希、非对称加密、数字签名、证书体系与PKI作为一个整体来设计，车载固件发布才能具备可验证、可追溯、可恢复的可信基础。