2. 车云通信安全威胁建模

车云通信不是一条“车到云”的直线，而是一张由车辆端、云端服务、TSP（Telematics Service Provider，车联网服务提供商）、OTA平台、远程控制通道共同组成的多跳信任网络。威胁建模的第一步，是把这张网络拆成可独立分析的信任边界，再判断mTLS（双向TLS）究竟能覆盖哪些边界、不能覆盖哪些边界。mTLS解决的是“通信双方是否持有可信证书并完成双向身份验证”，它不解决应用层越权、业务逻辑漏洞、证书私钥泄露后的冒用，也不解决车内CAN总线上的伪造报文。

一、先画信任边界，再谈攻击面

从车辆端看，典型通信实体包括T-Box（Telematics Box）、IVI（In-Vehicle Infotainment）、网关、OTA代理和远程控制执行单元。T-Box通常作为车云通信的主通道，持有设备证书，与TSP或车云网关建立mTLS连接；IVI可能通过T-Box代理或独立蜂窝链路访问云端；OTA代理负责下载固件包并校验签名；远程控制执行单元（如车门、空调、充电）接收云端下发的控制指令。云端侧则包括接入网关、设备身份服务、TSP业务服务、OTA管理平台、远程控制服务和证书签发/吊销服务。TSP往往承担设备鉴权、指令路由和业务编排，是车辆与云端业务之间的“中间信任代理”。

这些实体之间的连接关系，决定了攻击面分布。下图给出一个简化的车云通信信任边界与mTLS覆盖范围示意，重点标出mTLS能保护的双向认证段，以及mTLS无法直接覆盖的应用层与车内段。

二、典型攻击面与威胁模型

车辆端攻击面。最直接的威胁是T-Box或IVI中的设备私钥被提取。攻击者通过物理接触、调试接口、固件逆向或系统漏洞获取私钥后，可以伪造合法设备身份与云端建立mTLS连接。此时mTLS的证书校验会通过，因为攻击者持有的是“真证书”。因此，mTLS防护边界止于“证书私钥未被泄露”这一前提。工程上需要配合安全启动、密钥存储于SE/TEE、证书绑定车架号与设备指纹、异常连接行为检测来缩小这一风险。另一个攻击面是IVI应用层越权：IVI通过T-Box代理访问云端时，若代理只做通道转发而不做应用层鉴权，攻击者可在IVI上调用未授权接口。mTLS保护的是T-Box到云端的通道，不保护IVI内部应用之间的调用关系。

云端与TSP攻击面。云端接入网关是mTLS终止点，也是攻击者关注的重点。常见威胁包括：证书校验配置错误（如未校验客户端证书链、未检查吊销状态）、TLS版本或密码套件降级、网关被绕过直接访问后端服务。TSP作为业务中间层，若其内部服务间调用未做身份传递，攻击者一旦突破接入网关，就可能横向移动到OTA或远程控制服务。威胁模型上，应把TSP视为“已认证但未必已授权”的区域：mTLS证明设备身份，但设备是否有权调用某条远程控制指令，需要独立的授权决策。

OTA攻击面。OTA链路通常包含“云端下发固件包—车辆下载—车辆校验—写入分区”四个阶段。mTLS保护下载通道的机密性与完整性，但固件包本身必须额外做签名校验和哈希比对。典型威胁是攻击者通过DNS劫持或代理劫持将车辆引导到伪造的OTA服务器；若车辆只校验服务器证书而不校验固件签名，就可能安装恶意固件。另一个威胁是降级攻击：攻击者重放旧版本固件包，利用旧版本已知漏洞。防护上需要版本号单调递增、防回滚计数器、固件签名与mTLS证书分离管理。

远程控制攻击面。远程控制指令（解锁、启动、空调、充电）具有直接物理后果，是威胁建模中风险最高的场景。攻击路径包括：伪造云端指令、重放历史指令、篡改指令参数（如把“解锁”改为“启动”）、利用TSP业务逻辑漏洞越权控制他人车辆。mTLS能保证指令来自持有合法证书的云端或车辆，但不能保证指令内容在应用层未被篡改，也不能保证指令发起者有权控制这辆车。因此远程控制必须叠加指令级签名、时间戳/随机数防重放、车辆与用户绑定关系校验、以及执行前的二次确认或安全策略判断。

三、mTLS防护边界：能做什么、不能做什么

把上述场景归纳成一张边界表，可以更清楚地看到mTLS的覆盖范围与缺口。下表以“防护对象—mTLS是否覆盖—需要补充的机制”三列组织，便于在工程设计中直接对照。

四、威胁建模的落地检查项

在实际项目中，可以按以下顺序做一次最小可用的威胁建模检查。第一，列出所有车云通信实体和连接，标注每条连接是否使用mTLS、证书由谁签发、私钥存放在哪里。第二，对每条连接标注“mTLS覆盖”和“mTLS不覆盖”的部分，形成边界清单。第三，针对不覆盖部分，逐项指定补偿控制：应用层鉴权、指令签名、固件签名、防重放、审计日志。第四，定义证书生命周期事件：签发、轮换、吊销、过期，并确认车辆端在证书失效时能否安全降级或拒绝连接。第五，用攻击者视角复核：如果私钥泄露、如果网关被绕过、如果TSP内部被横向移动，分别会发生什么，现有检测和响应能否在造成物理后果前阻断。

以远程控制为例，一个合理的mTLS+应用层组合是：车辆与云端建立mTLS通道，云端在通道内下发带指令签名的控制报文，报文包含车辆VIN、指令类型、时间戳、随机数和过期时间；车辆端校验mTLS证书、校验指令签名、检查时间戳与随机数是否在有效窗口内、确认该指令与当前车辆绑定关系一致，全部通过后才交给执行单元。这样，mTLS负责“谁在说话”，指令签名和授权负责“说的话是否算数”，两者缺一不可。

威胁建模的输出不应是一份静态文档，而应随着OTA版本、TSP接口变更、证书策略调整而更新。每次新增一条车云通信路径，都应重新回答三个问题：这条路径的mTLS边界在哪里？边界之外还有什么攻击面？如果边界被突破，最坏后果是什么、如何检测和止损？把这三个问题固化到设计评审和上线检查中，mTLS才能真正成为车云身份认证工程的有效底座，而不是一个被默认信任的黑盒。