01 · OTA法规与标准体系
软件定义汽车（SDV）使OTA从"增值功能"变为"合规义务与安全生命线"。当前对OTA作出强制性要求的规范体系：
| 规范 | 性质 | 关键要求 | 实施时间 |
|---|---|---|---|
| UNECE R156（SUMS） | 法规（缔约方强制） | 制造商必须建立软件更新管理体系（SUMS）：更新过程受控、可记录、可审计；OTA更新须保证完整性与真实性、具备失败安全机制、并向用户告知更新内容与影响 | 2021年1月生效；欧盟2022年7月新车型强制、2024年7月全部新车 |
| GB 44496—2024 | 强制性国家标准 | 《汽车软件升级通用技术要求》：软件升级管理体系要求＋升级包安全与车端执行要求＋相应测试方法，与R156体系衔接 | 2024年8月23日发布；第1号修改单（2026年1月28日批准）调整为：新申请型式批准车型自2026年7月1日起执行，已获批准车型自2028年1月1日起执行 |
| ISO 24089:2023 | 工程方法标准 | 《道路车辆 软件更新工程》：将软件更新作为独立工程过程（需求、验证、发布、后发布监测），衔接21434与R156 | 2023年发布（自愿采用） |
| ISO/SAE 21434 | 工程方法标准 | 更新链路自身的TARA、更新引入新功能的回溯分析、退役前更新支持承诺 | 2021年8月发布 |
1.1 SOTA与FOTA
- SOTA（Software OTA）：升级应用层软件、地图、语音模型、控制策略参数——粒度小、频率高、风险相对可控；
- FOTA（Firmware OTA）：升级MCU固件、系统内核、Bootloader——影响面广、变砖风险高，需更严格的条件检查与回滚保护；
- 差分升级：以差分补丁（如bsdiff类算法）降低流量与时长，但引入"补丁应用过程被篡改"的新风险点，仍需整包或块级完整性校验。
02 · OTA系统架构
- 云端：版本与配置管理、SBOM维护、灰度发布策略（按车型/地区/批次圈选）、任务监控与撤回机制、签名服务（签名密钥置于HSM/密钥管理系统，多人控制）。
- 传输层：CDN分发＋TLS加密下载，断点续传；包元数据（版本、目标ECU、前置条件）与载荷分离签名。
- 车端：升级代理（负责下载调度与条件检查）→ 验签模块（HSM内验签，私钥不出安全区）→ 写入目标分区 → 激活与回滚保护。
- 分区策略：A/B双分区（inactive分区写入→校验→重启切换）＋Recovery兜底；安全相关ECU的启动加载器须拒绝回退到旧版本。
03 · 安全要求清单
| 控制域 | 要求 | 典型失效后果 |
|---|---|---|
| 完整性与真实性 | 升级包经私钥签名、车端HSM验签通过方可安装；哈希二次校验 | 恶意固件植入、车辆被控 |
| 防回滚 | 版本单调计数/安全存储白名单/eFuse熔断；安全相关ECU禁止版本回退 | 降级攻击利用旧漏洞 |
| 传输保护 | 全链路TLS加密；下载源身份验证 | 传输中被替换/篡改 |
| 安装前置条件 | 电量、车速（驻车）、环境温度、网络条件不满足时拒绝安装并提示 | 行驶中变砖、安全功能中断 |
| 原子性与恢复 | A/B分区＋Recovery；升级失败自动回退原版本且不影响用车 | 批量变砖、售后瘫痪 |
| 密钥管理 | 签名密钥HSM离线保护、多人控制、分级分权；车端验签公钥固化于信任根 | 签名体系整体失守 |
| 用户告知 | 更新内容、影响、时长的事前告知与事后确认（R156/GB 44496要求） | 合规风险与信任损失 |
| 审计追溯 | 升级任务、版本、结果全量日志；支持按VIN追溯 | 问题批次无法定位与撤回 |
04 · SUMS过程安全
- 变更管理：每次OTA对应明确的变更单：变更内容、影响分析（含功能安全回溯）、回滚预案、审批链。
- 发布管理：灰度发布（小批量观察→扩大范围）、健康度监控（失败率、异常报文）、一键撤回能力。
- 构建链安全：构建环境隔离、依赖锁定、制品仓库访问控制——2020年代多起软件供应链事件（SolarWinds式投毒）提示：若构建环境失守，再强的签名也只是在为恶意代码"背书"。
- 与功能安全一致性：更新不得破坏ISO 26262相关安全机制；更新后需完成回归验证（V&V证据归档）。
- EOL策略：车型停产前的最后安全更新与漏洞响应承诺须明示（与子课题01的EOL处置策略同构）。
05 · 真实案例：OTA的能力与边界
| 时间 | 案例 | 事实与启示 |
|---|---|---|
| 2015.8 | Jeep Cherokee远程入侵事件 | Uconnect漏洞被远程利用后，克莱斯勒因当时车辆不具备远程OTA能力，只能通过USB补丁＋经销商召回约140万辆车——OTA缺失使一次软件缺陷演变为公共安全事件；反向看，OTA能力本身也要求其升级链路达到第03节所列全部要求 |
| 2018.9 | Tesla应对KU Leuven钥匙研究 | KU Leuven披露Model S钥匙中继攻击面后，Tesla通过OTA快速新增"PIN to Drive"功能并后续更换钥匙方案——OTA将传统车企需要数月召回的修复压缩到数天，展示了OTA作为安全缓解手段的价值 |
| 持续实践 | Tesla常态化安全OTA | 其长期以OTA方式持续推送安全与功能更新，使"软件定义汽车"的安全修复节奏接近IT行业；但前提是签名、防回滚与灰度体系持续有效 |
边界提示：OTA不是漏洞管理的"免罪符"——①升级链路自身须通过渗透测试与代码审计；②硬件层缺陷（如密码算法被硬件实现固化）OTA无法根治；③EOL车辆失去更新承诺即转入持续暴露状态，需在车型生命周期规划中预先安排（衔接第8页合规要求）。
06 · OTA测试与验证
- 链路渗透测试：模拟中间人、恶意下载源、元数据篡改、重放旧包，验证车端拒绝行为。
- 异常注入：升级中断电、弱网、存储写满、时间回拨（防回滚绕过的常见探测）。
- 灰度健康度验证：台架＋小批量实车双轨验证失败率阈值与回滚触发逻辑。
- 合规测试对照：按GB 44496—2024的测试方法逐条准备证据，与型式试验机构提前对齐口径（详见第8页）。
本节参考来源（第5页）
UNECE UN Regulation No. 156 — Software update and software update management systems：unece.org/transport/vehicle-regulations/wp29。
GB 44496—2024《汽车软件升级通用技术要求》（2024年8月23日发布，原定2026年1月1日实施；第1号修改单于2026年1月28日批准，新申请型式批准车型自2026年7月1日起执行、已获批准车型自2028年1月1日起执行）：openstd.samr.gov.cn（国家标准全文公开系统）。
ISO 24089:2023 Road vehicles — Software update engineering：iso.org/standard/77796.html。
Miller & Valasek《Remote Exploitation of an Unaltered Passenger Vehicle》（2015）：illmatics.com——Jeep事件技术细节与召回背景。
KU Leuven COSIC Tesla Model S无钥匙进入研究（2018年9月披露，DST80分析）：esat.kuleuven.be/cosic；Tesla随后OTA新增PIN to Drive（2018年10月软件更新说明）。
ISO/SAE 21434:2021（软件更新相关条款）；ISO 26262:2018（更新后功能安全一致性验证要求）。