📚 课程目录第3章安全威胁与风险分析

3. 安全威胁与风险分析

OTA（Over-The-Air）升级把“软件分发”从工厂搬到了开放网络，它既是车辆功能迭代的生命线，也是攻击者眼中一条直通车辆核心控制器的“高速公路”。理解 OTA 安全，第一步不是急着加密，而是把攻击面、威胁模型、漏洞类型和真实事件四件事串成一条完整的风险链：谁在什么位置、通过什么接口、利用什么缺陷、最终能造成什么后果。只有把这条链画清楚，后续的签名、验签、回滚保护才有明确的防御目标。

一、OTA 的攻击面：从云端到 ECU 的五个入口

OTA 不是单一接口，而是一条跨越云、管、端、车的长链路。攻击面可以按数据流方向拆成五层：

云端与后台：升级包仓库、版本管理服务、签名服务、发布 API。若账号权限或 API 鉴权薄弱，攻击者可篡改升级包或伪造发布。
传输通道：车辆与 OTA 服务器之间的 HTTPS/MQTT 连接。中间人攻击、证书校验缺失、降级到明文是典型风险。
车端 OTA 客户端：负责下载、校验、解包、安装的代理程序。它是攻击者最常瞄准的“信任枢纽”，一旦被绕过，后续所有校验形同虚设。
车内网络：CAN、CAN-FD、以太网、LIN 等总线。OTA 客户端把固件分发给各 ECU 时，若总线无认证，攻击者可注入伪造刷写指令。
目标 ECU 与 Bootloader：真正执行写入的引导程序。刷写模式、调试口、回滚机制是最后一道闸门。

这五层中，车端 OTA 客户端和Bootloader是信任链的两个关键节点：前者决定“装不装”，后者决定“写不写”。多数真实攻击都围绕这两点展开。

二、威胁模型：用 STRIDE 给 OTA 链路“分诊”

威胁模型的价值在于把“可能被黑”变成“哪一类攻击、打哪个资产、造成什么影响”。对 OTA 链路，推荐用 STRIDE 六类威胁逐层对照：

威胁类型	OTA 场景中的表现	典型资产	防御要点
Spoofing 仿冒	伪造 OTA 服务器或 ECU 身份	服务器证书、ECU 身份	双向 TLS、设备证书
Tampering 篡改	修改升级包或刷写指令	固件镜像、元数据	数字签名、哈希校验
Repudiation 抵赖	升级操作无审计记录	升级日志、发布记录	签名日志、时间戳
Info Disclosure 泄露	升级包内含密钥或隐私数据	固件、配置、凭证	加密分发、最小化打包
DoS 拒绝服务	反复触发升级导致车辆不可用	OTA 客户端、总线	限流、回滚、看门狗
Elevation 提权	绕过验签获得刷写权限	Bootloader、调试口	安全启动、关闭调试

其中篡改与提权是 OTA 最致命的两类：前者让恶意固件“合法”落地，后者让攻击者获得持久控制权。威胁建模时应优先为这两类分配防御资源。

三、常见漏洞类型：从代码缺陷到流程缺陷

OTA 漏洞不全是“高深密码学问题”，大量真实案例来自工程实现和流程疏忽。常见类型包括：

签名校验缺失或可绕过：只校验哈希不验签，或验签失败后仍继续安装。
回滚保护缺失：允许安装旧版本，攻击者借此降级到已知漏洞版本。
证书校验不严：客户端不校验服务器证书，或接受自签名证书，导致中间人攻击。
调试接口未关闭：UART、JTAG、ADB 在量产车上仍可访问，可直接刷写。
权限与鉴权缺陷：OTA 发布 API 越权、令牌泄露、默认口令。
总线无认证：CAN 报文可伪造，攻击者注入刷写指令。
供应链污染：第三方 SDK 或构建环境被植入后门。

常见误区：很多团队认为“用了 HTTPS 就安全了”。HTTPS 只保护传输通道，无法防止云端仓库被篡改、客户端被绕过、ECU 被物理刷写。OTA 安全必须覆盖“云—管—端—车”全链路，任何一层失守都可能导致信任链断裂。

四、真实安全事件案例与复盘

过去十年，多起公开事件证明了 OTA 链路的脆弱性：

2015 年 Jeep Cherokee 远程入侵：研究人员通过蜂窝网络入侵车机，进而向 CAN 总线注入指令，远程控制转向和刹车，导致 140 万辆汽车召回。核心问题是车机与总线之间缺乏隔离与认证。
2016 年 Nissan Leaf 应用漏洞：手机 App 的认证缺陷可被利用远程开启空调和读取电池状态，暴露了云端 API 鉴权薄弱的风险。
2019 年 Tesla 密钥卡与 OTA 研究：研究者通过蓝牙密钥卡漏洞配对新钥匙，同时指出 OTA 更新机制若被滥用可成为攻击入口。
2022 年多个车厂 OTA 客户端漏洞：安全团队发现部分车型 OTA 客户端未严格校验签名或允许降级，攻击者可在获得车机权限后安装恶意固件。

复盘这些事件，可以提炼出三条共性教训：第一，信任不能只放在一个节点，车机被攻破不等于整车失守，但总线无认证就会放大后果；第二，降级就是漏洞，必须强制版本单调递增；第三，OTA 安全是流程问题，密钥管理、发布审批、日志审计缺一不可。

# 典型的 OTA 升级包校验伪代码（示意）
def verify_update(package, signature, pubkey):
    digest = sha256(package)
    if not rsa_verify(digest, signature, pubkey):
        raise SecurityError("签名校验失败，拒绝安装")
    if package.version <= current_version:
        raise SecurityError("检测到降级，拒绝安装")
    if not check_rollback_counter(package.counter):
        raise SecurityError("回滚计数器异常")
    return install(package)

工程建议：在威胁分析阶段，建议为每个攻击面标注“攻击者位置、所需权限、影响等级、现有缓解措施”，形成一张可追踪的风险清单。OTA 安全不是一次性工作，而应随版本迭代持续更新威胁模型。

综上，OTA 的攻击面横跨云、管、端、车，威胁模型帮助我们系统分类风险，常见漏洞多集中在验签、回滚、鉴权和调试接口，而真实事件反复证明：任何单点信任都不可靠，只有把签名、验签、回滚保护、总线认证和审计日志串成完整信任链，才能让 OTA 真正成为安全的升级通道。