汽车安全入门13 OTA升级安全与Uptane框架：从签名到整车版本清单

导语：OTA 升级正在成为现代汽车的标配，但升级通道本身就是攻击面——一旦升级链路被劫持，攻击者可以让整支车队同时变成”砖头”或”定时炸弹”。本文拆解 Uptane 框架的六大角色、四大设计特性，对照五星安全框架，看清整车 OTA 升级到底要防什么。

一、OTA 升级为什么是新战场

传统召回要 4S 店跑一趟。OTA 把这个流程压缩成”睡一觉醒来的事”——夜里推送、白天生效、几万辆同时完成。

但 OTA 通道本身就是超级攻击面。签名密钥泄露、推送通道被劫持、ECU 刷写校验被绕过，每一项都能让攻击者批量刷写、变砖攻击、降级回滚、静默植入。2015 年 Jeep 事件 Miller 和 Valasek 攻击的就是车内刷写通道，2016 年腾讯科恩远程黑入特斯拉最后一步也是改写车机固件。从那以后，OTA 安全就成了汽车安全里”必须做对”的一环。

二、Uptane 是什么：TUF 之上长出来的车载 OTA 框架

TUF（The Update Framework）是 2009 年纽约大学提出的通用软件升级安全框架，已经被 Docker、Python pip、RubyGems 等采纳。核心思路是多角色签名链——把升级流程的每个环节拆成不同角色，每个角色用自己的密钥签名，单点妥协不会击穿整条链。

TUF 是为服务器和桌面机设计的，搬到车上遇到三个新问题：ECU 种类繁多（从车机到刹车 ECU，从几 KB 到几 GB，验证成本太高）、整车一致性（不同 ECU 装的模块必须同一时间、同一版本、互相兼容）、网络不可信（车内 CAN/Ethernet 并不比公网更安全）。

Uptane 就是为这三点对 TUF 做的车载化扩展，由 NYU、密歇根大学、Lear、SwRI 联合设计，2016 年发表在 ESCAR，是 OEM 做 OTA 升级的事实标准。

三、Uptane 的角色链——六种密钥各管一摊

Uptane 把升级流程拆成 6 种角色，每种角色有自己的密钥和签发范围：

关键设计：Root 密钥离线保存——永远不联网；其他角色密钥可热备。分层让”任何单点泄露都不会让攻击者推一个能上车的镜像”——他们需要攻破多个角色，攻击成本被显著抬高。

四、四大设计特性——Uptane 的硬核补丁

双份存储防无尽数据攻击。攻击者在车内 MITM 可以给 ECU 灌随机数据，bootloader 一验”哈希对不上”就变砖。Uptane 要求 ECU 保留 A/B 两份存储：刷写时先写 B 区，校验通过才切到 B 区启动。进阶做法是只存”差分 delta”，空间省一半效果一样。

元数据广播防混搭攻击。如果 Primary ECU 给不同 Secondary ECU 发不同元数据，攻击者可制造”半车新版、半车老版”的混搭。Uptane 要求 Primary 通过 CAN/Ethernet 广播元数据，所有 Secondary 收到同一份副本，攻击者想篡改就得同时欺骗所有 ECU。

整车版本清单防半安装攻击。升级因网络抖动或 ECU 掉电中断后，Uptane 让每个 ECU 用 OEM 预置对称密钥对自己”已装版本”做签名，汇总成”整车版本清单”上报。OEM 一对比就能发现”我推了 17 个 ECU 升 8.1，清单里只有 16 个说装了”。

时间服务器防冻结攻击。ECU 没可信时钟，攻击者可反复重放”旧元数据”让 ECU 永远停在老版本。Uptane 让 Primary 定期从外部时间服务器拉取时间，ECU 验签后更新本地时钟，验元数据发现”过期”直接拒。

五、Uptane vs 简单签名——差距在哪

很多 OEM 早期 OTA 就是”镜像 RSA 签名 + ECU 验签后刷写”，有四个 Uptane 显式解决的盲点：密钥被偷直接伪造新版本推送（Uptane 需偷多角色，单点不致命）；MITM 篡改 bootloader 一验就拒，ECU 变砖（Uptane A/B 回滚还能启动）；ECU 版本不一致没人查（Uptane 整车清单自动核查）；重放旧版本无时间维度（Uptane 时间戳+时间服务器双保险）。

一句话总结：简单签名解决”镜像对不对”，Uptane 解决”在汽车这种复杂环境里升级整件事可不可信”。

六、五星安全框架——OTA 之外的整车安全面

I Am The Cavalry 2015 年提出的五星框架（5-Star Automotive Cyber Safety Framework）是 OTA 安全的”宏观指导思想”，Uptane 是其中一个”★”的具体技术实现：

1. Safety by Design：把安全嵌进 SSDLC
2. Third Party Collaboration：按 ISO 29147/30111 发布协调披露政策
3. Evidence Capture：车内 ECU 操作留可取证、防篡改日志
4. Updateability：所有 ECU 支持安全 OTA——这是 Uptane 直接落地的 ★
5. Segmentation & Isolation：车内网络按安全等级分段，OBD-II 与动力域严格隔离

五星全做到 OTA 才真正安全。只做第 4 颗星忽略其他四颗，攻击者会从诊断口、调试接口、合作伙伴后门绕进来。

七、OTA 攻击实战思路

红队看 OTA 攻击面可以从五个方向入手：

1. 签名密钥：OEM 的 Release/Targets 密钥是不是硬编码在镜像里？能不能从泄露的刷写工具里提取？
2. 镜像仓库：Web 端点有没有未授权访问？能不能在推送过程中 MITM？
3. 车内网络：CAN 总线上能不能伪造 Primary 广播元数据？
4. ECU 刷写：诊断服务（UDS 0x34/0x36/0x37）有没有鉴权？能不能绕过 OEM 刷入第三方镜像？
5. 回滚机制：OEM 是不是支持”降级到任意版本”？如果是，攻击者可以把修复过 CVE 的 ECU 强制刷回漏洞版

实战里第 1 项最值钱：2022 年一个勒索组织就靠偷到某 Tier-1 供应商的镜像签名密钥，给客户车企的车队推送了加密整个车机系统的”OTA 包”。

八、防御建议

1. 完整部署 Uptane：不是只做”镜像签名”，四大特性一起上
2. Root 密钥 HSM 隔离：永远离线、不联网、多人授权
3. 按五星框架做差距分析：每年评审一次五个能力的覆盖度
4. 供应商管理：Tier-1/Tier-2 的签名密钥纳入 OEM 的 KMS，合同里写明”泄露即召回”
5. 车内网络分段：动力域、底盘域、车身域、信息娱乐域物理隔离，OBD-II 只允许读不解

OTA 升级做对了，整车安全跃升一个台阶；做错了，每辆车都成了攻击者的后门。

九、思考题

1. 攻击者拿到 Release 和 Snapshot 密钥但拿不到 Director 密钥，能推一个让整车跑起来的恶意固件吗？为什么？
2. A/B 存储在空间紧张的传感器 ECU 上不现实，Uptane 的”差分 delta”方案怎么落地？
3. 整车版本清单由 Primary 汇总再上报 Director，这本身会不会成为单点失败？

十、素材出处

• 论文：Kuppusamy et al. “Uptane: Securing Software Updates for Automobiles”，ESCR 2016 – https://www.weimerskirch.org/files/KuppusamyEtAl_UPTANE.pdf
• 论文：Kuppusamy et al. “Uptane: Security and Customizability of Software Updates for Vehicles”，USENIX 2022 – https://www.researchgate.net/publication/322881541
• 框架官网：Uptane – https://uptane.github.io/
• 五星框架：I Am The Cavalry “5-Star Automotive Cyber Safety Program”（2015） – https://iamthecavalry.org/5star
• 形式化分析：Sage et al. “A Comprehensive, Automated Security Analysis of the Uptane”，RAID 2024 – https://dl.acm.org/doi/10.1145/3678890.3678927
• Awesome 列表条目：#62 5-Star Framework、#117 Uptane