📚 课程目录第4章安全通信需求分析

4. 安全通信需求分析

车载安全通信不是把IT安全术语照搬到车上，而是要把机密性、完整性、可用性、认证性、不可否认性这五个安全目标，翻译成ECU、网关、域控制器、T-Box、V2X OBU之间真实报文交互时可验证、可度量、可落地的工程要求。车载网络与办公网络最大的差异在于：通信链路既有CAN/CAN FD、LIN、FlexRay这类广播式总线，也有Automotive Ethernet、SOME/IP、DDS、MQTT等面向服务的链路；节点算力、存储、带宽和实时性约束极强；同时车辆还涉及功能安全与OTA升级，安全目标之间经常需要权衡。

本节的核心判断是：五性不是并列的口号，而是一组相互约束的需求集合。机密性解决“谁能看到”，完整性解决“有没有被改”，可用性解决“关键时刻能不能用”，认证性解决“对方是不是它声称的身份”，不可否认性解决“事后能不能证明某条指令确实由某主体发出”。在车载场景中，任何一项缺失都可能从信息安全问题演变为功能安全问题。

一、核心原理：五性在车载通信中的具体含义

机密性在车载场景中主要保护三类数据：诊断数据（UDS 0x27安全访问、0x2E写数据）、OTA升级包与签名元数据、V2X中的位置与意图消息。对CAN总线而言，报文本身是广播的，任何接入OBD或网关的节点都能监听，因此机密性通常不靠链路层加密，而靠应用层加密或网关过滤。对以太网链路，可用MACsec、IPsec、TLS/DTLS实现。需要强调的是，车内很多控制报文（如车速、转向角）本身不敏感，但一旦与身份、位置、用户行为关联，就可能构成隐私泄露。

完整性是车载安全通信的第一优先级。刹车指令、扭矩请求、转向命令、OTA包、诊断例程控制，一旦被篡改，后果直接指向功能安全。完整性保护通常用CMAC、HMAC、GMAC或数字签名实现。CAN FD受限于8/64字节载荷，常用截断MAC（如24位或32位）配合新鲜度计数器；以太网SOME/IP则可用TLS或IPsec ESP提供完整性与抗重放。

可用性在车载场景中意味着：安全机制不能把实时通信拖垮。CAN周期报文通常要求毫秒级确定性，若每帧都做非对称签名验证，ECU无法承受。因此可用性要求安全设计必须考虑计算开销、带宽开销、启动时延和故障降级策略。例如，安全启动失败时是禁止通信还是进入受限模式，必须提前定义。

认证性分为实体认证与消息认证。实体认证解决“ECU A是不是真的ECU A”，常用挑战-响应、证书、预共享密钥；消息认证解决“这条报文是不是由合法节点发出且未被重放”，常用MAC+新鲜度值。车载场景中，网关需要认证下游节点，T-Box需要认证云端，V2X需要认证其他车辆与路侧单元。

不可否认性在车载场景中主要出现在三类事件：OTA升级记录、诊断操作审计、V2X事故取证。它要求发送方不能事后否认自己发出过某条指令或某个版本包。实现上通常依赖数字签名与时间戳，并由PKI或审计日志提供证据链。对实时控制报文，不可否认性通常不是强制项，因为签名开销大且控制指令生命周期极短。

二、方法流程：从需求到可验证的安全通信设计

把五性落到工程上，建议按以下流程推进：

资产与数据流梳理：列出ECU、网关、T-Box、OBU、云端、诊断仪之间的所有通信路径，标注协议、周期、载荷长度、实时性等级。
威胁建模：针对每条路径识别窃听、篡改、重放、伪造、拒绝服务、越权诊断等威胁。
安全目标映射：把威胁映射到五性，明确每条报文需要哪几项保护，避免“全加密”或“全签名”的过度设计。
机制选型：根据算力、带宽、实时性选择SecOC、MACsec、IPsec、TLS、DDS Security或应用层签名。
密钥与新鲜度管理：定义密钥层级、更新周期、吊销流程、新鲜度计数器同步策略。
验证与测试：用渗透测试、模糊测试、重放测试、时延测试验证五性是否达标。

下面是一个典型的车载安全通信需求映射示例，可作为需求分析阶段的检查清单：

通信场景	机密性	完整性	可用性	认证性	不可否认性
CAN周期控制报文	低	高（SecOC）	极高	高（MAC+新鲜度）	低
UDS诊断会话	中	高	中	高（0x27/证书）	高（审计日志）
OTA升级包下发	高	高	中	高（双向证书）	高（签名+时间戳）
V2X BSM消息	中（隐私）	高	极高	高（PKI证书）	中（取证）
车云SOME/IP服务	高	高	中	高（TLS/DDS Security）	中

三、案例/场景：一次刹车指令被重放引发的复盘

某车型在台架测试中，攻击者通过OBD接入CAN总线，录制了一段包含“制动请求”的CAN帧，并在车辆低速行驶时重放。由于该报文没有新鲜度校验，ECU接受了重放帧，导致车辆出现非预期制动。复盘发现：该报文有CMAC完整性保护，但新鲜度计数器在ECU休眠唤醒后未同步，攻击者利用窗口期完成了重放。

这个案例说明：完整性不等于抗重放，认证性必须与新鲜度绑定。在车载场景中，新鲜度值可以基于计数器、时间戳或挑战-响应。对CAN这种广播总线，计数器同步策略必须考虑节点休眠、唤醒、总线关闭和密钥更新。工程上常用“新鲜度值+MAC”的SecOC方案，并在网关侧做集中同步与异常检测。

SecOC 报文结构示例（简化）：
[ CAN ID ][ 新鲜度值 FV ][ 截断MAC ][ 应用数据 ]
FV：单调递增计数器，按报文周期或事件触发更新
MAC：CMAC-AES-128 截断为 24/32 bit
校验失败处理：丢弃报文 + 记录DTC + 触发降级策略

四、误区与复盘：五性需求分析中最容易犯的错

误区一：把五性当成“全部都要最高等级”。车载ECU算力有限，全量非对称签名会直接破坏可用性。正确做法是按报文分级，控制类报文优先完整性+认证性，诊断与OTA优先机密性+不可否认性。

误区二：只做链路层加密，忽略端到端保护。网关内部、域控制器内部、虚拟机之间仍可能被绕过。安全通信需求应覆盖端到端路径，而不是只保护某一段总线。

误区三：忽略密钥生命周期。密钥一旦泄露，机密性、完整性、认证性同时失效。必须定义密钥注入、更新、吊销、销毁流程，并考虑产线、售后、报废各阶段。

复盘建议：在需求分析阶段就建立“安全目标—通信路径—机制—验证用例”的追踪矩阵。每条安全需求都要有对应的测试用例，例如重放测试、篡改测试、证书过期测试、时延测试、降级测试。只有能验证的需求，才是工程上可交付的需求。

总结来看，车载安全通信需求分析的关键，不是把五个词写进文档，而是把每个词拆成可验证的工程约束：用什么算法、密钥多长、新鲜度怎么同步、时延增加多少、失败后如何降级、日志如何审计。只有把五性与具体报文、具体协议、具体ECU资源绑定，安全通信才真正具备可实施性。