4. 车载安全威胁模型
可信启动解决的是“从哪一级开始信任、信任如何逐级传递”的问题，而威胁模型回答的是另一个更前置的问题：我们到底在防谁、防什么、从哪里被攻破、以及哪些条件被默认成立。如果威胁模型缺失，可信启动很容易退化为“把 BootROM 到应用层的每一级都做签名校验”，却忽略了调试口、诊断服务、OTA 通道、车内总线等真实入口，最终形成“链内很硬、链外很软”的假安全。
一、核心原理：威胁模型四要素
车载威胁模型可以用四个相互约束的要素来描述：攻击面（Attack Surface）、威胁主体（Threat Actor）、攻击路径（Attack Path）与安全假设（Security Assumption）。攻击面是系统对外暴露的所有可交互入口；威胁主体是具备不同能力与动机的攻击者；攻击路径是攻击者从入口到目标的实际步骤链；安全假设则是我们默认成立、但一旦被打破整套信任就会崩塌的前提条件。
四者之间存在明确的推导关系：攻击面决定威胁主体能接触到的资源，威胁主体的能力决定其可选的攻击路径，而安全假设决定了这些路径是否被有效阻断。可信启动的验证设计，本质上就是围绕“假设是否成立”来布置检测点。
二、方法流程：从攻击面到验证点的映射
建立威胁模型不是写一份文档，而是把攻击面逐条映射为可信启动中的验证点与检测手段。推荐按以下流程推进：
- 枚举攻击面：按物理、无线、总线、诊断、OTA、供应链、用户侧七类逐一列出接口与协议。
- 标注威胁主体：对每个攻击面判断哪些主体可接触、具备何种能力等级。
- 构造攻击路径：从入口到目标资产（如密钥、固件、控制指令）画出步骤链。
- 识别安全假设：标出路径中依赖的每一个“默认成立”的前提。
- 布置验证点：在启动链的对应层级加入签名校验、度量、回滚保护或调试口锁定。
- 验证假设：通过渗透测试、故障注入、日志审计确认假设未被打破。
三、案例场景：OTA 降级攻击路径分析
以 OTA 通道为例，攻击者若获取到旧版本固件包，可能尝试将其重新签名或直接重放，使 ECU 回退到存在已知漏洞的版本。该路径依赖三个安全假设：版本号不可伪造、防回滚计数器不可重置、签名校验覆盖版本字段。
攻击路径：OTA 服务器 → 车端代理 → ECU 刷写
步骤1：截获或获取旧版本固件包（v1.2）
步骤2：修改版本号字段为 v2.0，或直接重放旧包
步骤3：绕过签名校验（若版本字段未纳入签名范围）
步骤4：ECU 接受并刷写，回退到漏洞版本
步骤5：利用 v1.2 已知漏洞获取控制权
对应验证点：
- 签名覆盖范围必须包含版本号与防回滚计数器
- 防回滚计数器存储于一次性可写区域或 HSM
- 启动时校验当前版本 ≥ 最低允许版本该案例说明：攻击路径的每一步都对应一个可验证的假设。若签名未覆盖版本字段，则“版本不可伪造”这一假设不成立，整条路径即可走通。
四、误区与复盘
复盘时应回到四要素表，逐条核对：攻击面是否全部覆盖、威胁主体能力是否被正确评估、攻击路径是否有对应验证点、安全假设是否经过实测确认。下表可作为威胁模型评审清单。
| 攻击面 | 典型威胁主体 | 关键安全假设 | 可信启动验证点 |
|---|---|---|---|
| 调试口 / JTAG | 车主、维修人员、技术型攻击者 | 量产状态已锁定调试口 | 启动时检测调试状态位，锁定则拒绝进入调试模式 |
| OTA 通道 | 有组织犯罪、国家级攻击者 | 签名覆盖版本与防回滚计数器 | 刷写前校验签名、版本号与回滚计数器 |
| 诊断服务 UDS | 维修人员、技术型攻击者 | 安全访问等级不可绕过 | 刷写前要求安全解锁，校验刷写权限 |
| 车内总线 CAN | 机会型攻击者、内部人员 | 网关隔离与报文认证有效 | 网关启动时校验固件签名，启用报文认证 |
| 供应链固件 | 内部人员、国家级攻击者 | 构建环境与密钥未泄露 | 启动时校验固件签名，比对已知哈希 |
| 密钥存储 | 技术型攻击者、国家级攻击者 | HSM 或安全区不可提取密钥 | 启动时校验密钥完整性，检测侧信道防护状态 |
威胁模型的价值不在于列出所有可能的攻击，而在于让团队清楚：哪些假设是可信启动成立的前提，哪些验证点负责守护这些假设。当攻击面、威胁主体、攻击路径与安全假设四者形成闭环，可信启动的验证设计才有明确的靶心，而不是盲目堆砌校验步骤。