导语：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（根密钥） |
自身之外所有角色的公钥 |
泄露 = 整条链可被伪造，灾难性 |
| Timestamp（时间戳） |
当前"已知最新版本号" |
泄露可重放过期元数据 |
| Snapshot（快照） |
哪些 Targets/Metadata 存在 |
泄露可误导 ECU 找错文件 |
| Targets（目标清单） |
镜像哈希、长度、路径 |
泄露可推送错误版本 |
| Director（整车编排） |
哪些 ECU 装哪些 Targets |
泄露可制造"混搭攻击" |
| Supplier（供应商） |
原始镜像签名（Tier-1/Tier-2） |
泄露可植入后门模块 |
关键设计在于：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 变砖 |
A/B 存储回滚仍能启动 |
| ECU 版本不一致 |
没人查 |
整车清单自动核查 |
| 重放旧版本 |
无时间维度 |
时间戳 + 时间服务器双保险 |
一句话总结：简单签名解决"镜像对不对"，Uptane 解决"在汽车这种复杂环境里升级整件事可不可信"。
五、五星安全框架——OTA 之外的整车安全面
I Am The Cavalry 在 2015 年提出的五星框架（5-Star Automotive Cyber Safety Framework）可以看作 OTA 安全的"宏观指导思想"，Uptane 只是其中一颗"★"的具体技术实现：
- Safety by Design：把安全嵌进 SSDLC。
- Third Party Collaboration：按 ISO 29147/30111 发布协调披露政策。
- Evidence Capture：车内 ECU 操作留可取证、防篡改日志。
- Updateability：所有 ECU 支持安全 OTA——这是 Uptane 直接落地的那颗 ★。
- Segmentation & Isolation：车内网络按安全等级分段，OBD-II 与动力域严格隔离。
五星全做到，OTA 才真正安全。只做第 4 颗星而忽略其他四颗，攻击者照样能从诊断口、调试接口、合作伙伴后门绕进来。
六、OTA 攻击实战思路
红队视角下，OTA 攻击面可以从五个方向展开试探：
- 签名密钥：OEM 的 Release/Targets 密钥是不是硬编码在镜像里？能不能从泄露的刷写工具里提取出来？
- 镜像仓库：Web 端点有没有未授权访问？能不能在推送过程中做 MITM？
- 车内网络：CAN 总线上能不能伪造 Primary 广播元数据？
- ECU 刷写：诊断服务（UDS 0x34/0x36/0x37）有没有鉴权？能不能绕过 OEM 刷入第三方镜像？
- 回滚机制：OEM 是不是支持"降级到任意版本"？如果是，攻击者可以把修复过 CVE 的 ECU 强制刷回漏洞版。
实战里第 1 项最值钱：2022 年就有勒索组织靠偷到某 Tier-1 供应商的镜像签名密钥，给客户车企的车队推送了加密整个车机系统的"OTA 包"。
七、防御建议
- 完整部署 Uptane：不是只做"镜像签名"，四大特性一起上。
- Root 密钥 HSM 隔离：永远离线、不联网、多人授权。
- 按五星框架做差距分析：每年评审一次五个能力的覆盖度。
- 供应商管理：Tier-1/Tier-2 的签名密钥纳入 OEM 的 KMS，合同里写明"泄露即召回"。
- 车内网络分段：动力域、底盘域、车身域、信息娱乐域物理隔离，OBD-II 只允许读、不允许写。
OTA 升级做对了，整车安全跃升一个台阶；做错了，每辆车都成了攻击者的后门。
八、思考题
- 攻击者拿到 Release 和 Snapshot 密钥但拿不到 Director 密钥，能推一个让整车跑起来的恶意固件吗？为什么？
- A/B 存储在空间紧张的传感器 ECU 上不现实，Uptane 的"差分 delta"方案怎么落地？
- 整车版本清单由 Primary 汇总再上报 Director，这本身会不会成为单点失败？
九、素材出处
发表于 2 小时前
|
查看: 4|
回复: 0
