汽车 ECU TARA 实例：从 OBD-II、UDS 编程到电机控制器固件风险

一份好的 ECU TARA 不应该从“黑客能控制车辆”这种宽泛描述开始。工程师应先问清具体入口、服务、权限和资产。下面以一个假设的电机控制器为例，展示如何构建能够检查的攻击路径。这是教学案例，不代表某款量产车辆存在相同缺陷。

先画出真正相关的系统边界

假设动力系统包含车载诊断接口、中央网关、动力 CAN 网络、电机控制器 MCU，以及存放控制固件的闪存。外部诊断工具通过 OBD-II 连接。网关负责转发相关诊断通信。

UDS 是道路车辆诊断服务体系。ISO 14229-1:2026 描述诊断工具与 ECU 之间的应用层诊断服务，包括读取数据、执行例程和其他诊断操作。是否允许编程、如何授权、哪些网络可达，取决于实际车辆实现。^S6

对当前分析，资产是 MCU 固件的完整性。还需要关注诊断权限状态、编程流程和固件有效性检查。不要把“支持 UDS”直接写成“任何人可以刷写”。

从资产写出损害情景

一个合理的损害情景是“MCU 固件被未经授权修改，导致控制器输出错误或进入不可用状态”。但安全影响不应由网络安全工程师独自宣布。车辆功能、降级模式和故障响应需要功能安全团队确认。

另一种损害是产品在维护时无法完成固件更新，造成维修延迟或停机。两种后果性质不同，应分开评估，不能仅凭一个高严重性标签概括。

用明确的前提描述攻击路径

这条假设路径按顺序记录：攻击者接触诊断设备，设备进入车辆诊断接口，网关允许目标诊断通信，MCU 接收编程请求，某项授权检查失效，未经批准的固件被安装。

每个步骤都有待验证的条件。诊断连接是否可由攻击者接触？是否存在需要的会话状态？网关是否限制源地址、服务和目标？ECU 是否验证固件签名与版本？这些问题会决定整条路径能否成立。

路径分析的目的不是证明攻击一定成功。它帮助团队定位假设、验证控制，并给攻击可行性评估提供证据。分析方法和记录应与 ISO/SAE 21434 的风险管理要求保持一致。^S3

安全控制应放在哪一层？

诊断入口。 通过受控的诊断权限、会话管理和访问限制，减少未授权编程机会。远程或本地访问条件应分别评估。

网关。 检查路由限制和网络边界，判断不相关的诊断通信能否跨区。网络分段只在确实限制攻击路径时才被计入控制。

MCU 更新流程。 检查固件真实性、完整性、适用版本和防回退规则。安全启动验证启动链，不会自动解决所有诊断权限问题。HSM 能保护密钥操作，也不能单独替代访问控制。

故障处理。 更新失败后的安全状态、恢复机制和可用性影响需要单独验证。不能只写“升级失败后重启即可”。

可行性和剩余风险怎样记录？

先记录攻击者需要的时间、专业知识、目标信息、接触窗口和设备条件。计算方法必须与项目选定的评价体系一致。安装控制之后，再根据真实限制重新评估。不要把控制名称当成可行性降低的证据。

报告中应保留原始可行性、控制实施状态、验证材料、剩余可行性和批准记录。这样，客户不必相信一句“风险已经很低”，而能找到其工程依据。

为什么可视化架构比长表更容易审核？

同一条攻击路径同时涉及物理诊断口、网关和 MCU。平铺表格可以记录字段，但图形界面更适合展示每一步跨过的网络和信任边界。QuickTARA 支持在产品架构中展示攻击路径，并查看控制影响，适合用这个示例做技术演示。

常见问题

存在 OBD-II 接口就意味着 ECU 可被刷写吗？ 不意味着。访问条件、网关转发、诊断服务授权与固件验证共同决定路径是否成立。

用了 HSM 和安全启动就不需要其他控制了吗？ 不行。两者覆盖特定信任与密钥问题，诊断权限和网络入口仍需独立分析。