📚 课程目录第1章课程导入

1. 课程导入

智能网联汽车正在从“机械定义”走向“软件定义”。一辆现代智能汽车往往包含 70～150 个电子控制单元（ECU），固件代码规模可达上亿行，且在全生命周期内需要持续通过 OTA（Over-The-Air）进行功能迭代、缺陷修复与安全补丁下发。固件一旦在发布或升级环节被篡改、回滚或降级，轻则导致功能异常，重则引发批量召回甚至远程控制风险。因此，车载固件可信发布与升级安全工程要解决的核心问题是：如何让“正确的固件，以正确的方式，安装到正确的车辆上，并且全过程可验证、可追溯、可恢复”。

一、学习目标：从“能升级”到“可信升级”

本课程不是单纯讲解某一种刷写工具或某一家云平台，而是建立一套贯穿“云端—车端—ECU”的端到端安全工程能力。学完本课程，应达到以下四层目标：

概念层：理解可信根（RoT）、安全启动、镜像签名、防回滚、A/B 分区、差分升级、密钥生命周期等核心概念及其相互关系。
原理层：掌握数字签名与哈希链如何保证固件完整性与来源真实性，理解信任链如何从硬件可信根逐级传递到应用固件。
工程层：能够设计固件发布流水线，配置签名服务、版本策略、灰度发布与回滚机制，并落地到具体工具链。
合规层：熟悉 UN R155/R156、ISO 21434、GB 44495 等法规标准对固件升级与软件更新管理（SUMS）的强制要求。

核心判断：一次“成功”的 OTA 不等于一次“安全”的 OTA。安全升级必须同时满足真实性、完整性、机密性、可用性、可回滚性五个属性。

二、核心概念与整体框架

车载固件可信发布与升级安全工程可以抽象为一条“信任链 + 数据流”的双主线结构。信任链解决“凭什么相信这个固件”，数据流解决“固件如何安全地到达并生效”。下图展示了从固件构建、签名发布、云端分发、车端下载、ECU 校验到最终激活的完整链路，以及各环节对应的安全机制。

三、方法流程：一次可信 OTA 的完整生命周期

把上图展开为可执行流程，一次可信 OTA 通常包含六个阶段，每个阶段都有明确的输入、动作与验证点：

构建与签名：CI 产出固件镜像，计算哈希，使用离线私钥或 HSM 签名，生成 manifest（含版本号、目标 ECU、依赖关系、防回滚计数器）。
发布与存储：签名后的固件包上传至 OTA 平台，按车型、VIN、区域、版本建立发布策略，并生成差分包以降低流量。
下发与下载：车端 OTA 客户端通过 TLS 与云端建立安全通道，校验包元数据后分块下载，支持断点续传与限速。
车端校验：下载完成后，网关或升级代理先验签 manifest，再校验镜像哈希，确认版本高于当前版本且未被撤销。
写入与激活：写入备用分区（A/B 或双备份），写入完成后再次校验，通过后切换启动标志，重启进入新固件。
确认与回滚：新固件启动后上报健康状态，云端确认升级成功；若启动失败或校验不通过，自动回滚到旧分区。

工程实践中，“先校验、后写入、再确认”是三条不可颠倒的顺序。任何跳过车端二次校验、直接信任云端下发的设计，都会把攻击面从云端扩大到整车。

四、典型场景与误区复盘

以某车企一次真实 OTA 故障为例：云端签名服务正常，但车端升级代理在下载后仅校验了文件大小与 CRC，未验证数字签名。攻击者通过中间人劫持替换了差分包，导致部分车辆写入异常固件，仪表黑屏。复盘发现三个问题：一是信任链在车端断裂，二是缺少防回滚计数器，三是没有灰度发布与自动回滚。修复方案包括：在升级代理中强制验签、引入 HSM 存储公钥、增加版本单调递增策略、按 1%→5%→20%→100% 灰度放量，并设置 30 分钟健康观察窗口。

常见误区还包括：把“加密传输”等同于“固件可信”；把“签名一次”等同于“全生命周期安全”；忽略密钥轮换与吊销；在产线或售后使用调试口绕过安全启动。这些都会让前期投入的安全机制形同虚设。

五、法规与标准清单

标准/法规	关注重点	对本课程的约束
UN R155	网络安全管理体系 CSMS	要求 OEM 建立覆盖升级过程的威胁分析与风险评估
UN R156	软件更新管理体系 SUMS	要求记录升级前后版本、可追溯、可回滚、用户告知
ISO 21434	道路车辆网络安全工程	提供 TARA 方法与安全需求分解框架
GB 44495	汽车整车信息安全技术要求	对 OTA 升级提出完整性、真实性与访问控制要求
ISO 24089	软件更新工程	规范更新包结构、签名、安装与验证流程

六、关键参数与配置示例

在后续章节的实操中，会反复接触以下参数。这里先给出一个典型的升级 manifest 片段，帮助建立直观印象：

{
  "ecu_id": "VCU-0x18",
  "fw_version": "2.4.1",
  "min_version": "2.3.0",
  "rollback_counter": 17,
  "hash_algo": "SHA-256",
  "image_hash": "9f2c...e1a7",
  "signature": "MEUCIQ...",
  "sign_key_id": "oem-fw-sign-2024",
  "target_partition": "B",
  "activate_after_reboot": true
}

其中 rollback_counter 必须单调递增，min_version 用于阻止降级到存在已知漏洞的版本，sign_key_id 用于密钥轮换与吊销。这些字段共同构成“可信发布”的最小数据集。

不要把私钥放在 CI 构建节点上。签名私钥应存放在 HSM 或离线签名机中，构建节点只提交哈希，由签名服务返回签名结果。私钥一旦泄露，整条信任链即告失效。

本课程后续将沿着“概念—原理—工具—实操—排障—复盘”的路径展开，从可信根与安全启动讲起，逐步深入到签名服务、差分升级、A/B 分区、灰度发布、回滚策略与合规审计，最终形成一套可落地的车载固件可信发布与升级安全工程方法。