3、网络安全基础概念：车载网络安全威胁模型、攻击面分析、安全目标
好，我们进入第三个章节。说实话，很多刚接触车载安全的工程师，一上来就盯着各种协议和工具，反而把最基础的东西忽略了。我个人习惯是，先搞清楚“敌人是谁”、“从哪里打进来”、“我们要守住什么”。这三个问题搞明白了，后面的测试才有方向。
这一章，我们就来聊聊车载网络安全的威胁模型、攻击面分析，以及四个核心安全目标：机密性、完整性、可用性、真实性。
3.1 威胁模型：先搞清楚敌人长什么样
威胁模型，说白了就是“假设谁要搞破坏，他能怎么搞”。你想想看，如果连攻击者可能的动机和手段都不清楚，那防御就是瞎忙活。
在车载领域，我习惯把威胁来源分成三类：
- 外部攻击者：比如通过蓝牙、Wi-Fi、4G/5G 远程入侵的黑客。这是最常见的威胁模型。
- 物理接触者：比如通过 OBD-II 接口、USB 端口直接连接设备的维修工或恶意人员。
- 内部组件失效：比如某个 ECU 被恶意软件感染后，从内部发起攻击。
核心观点：威胁模型不是一成不变的。同一辆车，在研发阶段、生产阶段、售后阶段，威胁模型完全不同。我在项目中遇到过，某 OEM 在研发阶段只考虑了远程攻击，结果量产车被一个维修工用 OBD 刷写工具搞瘫痪了整条 CAN 总线。嗯，这就是威胁模型没覆盖全的代价。
常用的威胁建模方法有 STRIDE 和 EVITA。我个人更推荐 EVITA，因为它专门针对汽车场景，把威胁分成了“安全”、“财务”、“隐私”等维度，更贴近实际。
3.2 攻击面分析：敌人从哪里打进来？
攻击面，就是所有可能被攻击者利用的入口。我经常跟团队说：“你连门在哪都不知道，怎么锁门？”
车载网络的攻击面，我总结为以下几个主要区域：
| 攻击面 | 典型入口 | 风险等级 |
|---|---|---|
| 无线通信 | 蓝牙、Wi-Fi、4G/5G、NFC | 高 |
| 有线接口 | OBD-II、USB、以太网接口 | 中高 |
| 传感器/执行器 | 摄像头、雷达、GPS 信号 | 中 |
| 内部总线 | CAN、CAN FD、LIN、FlexRay、车载以太网 | 高 |
| 云端/后端 | TSP 平台、OTA 服务器 | 高 |
这里我要特别提一下 CAN 总线。很多工程师觉得 CAN 总线是“内部网络”，攻击者进不来。但你想，如果攻击者通过 OBD 接口或者一个被攻破的网关 ECU 进入了 CAN 网络，那整个车内通信就相当于裸奔了。我曾经在测试中发现，某车型的 CAN 报文完全没有认证机制，一个伪造的刹车指令就能让车辆误动作。这就是攻击面分析没做到位。
我的建议：做攻击面分析时，不要只盯着“外部接口”。内部总线之间的隔离、网关的过滤规则、ECU 之间的信任关系，这些才是真正的薄弱环节。我习惯用 CANoe 的“攻击面扫描”功能，配合 CAPL 脚本模拟各种攻击向量，快速定位暴露点。
3.3 安全目标：我们要守住什么？
安全目标，就是我们要保护的核心资产。在车载网络安全里，最经典的就是 CIA 三元组，再加上一个“真实性”，变成 CIAA。
3.3.1 机密性（Confidentiality）
机密性，就是防止信息被未授权的人看到。在车载场景里，哪些数据需要保密？
- 车辆身份信息（VIN、密钥）
- 用户隐私数据（位置、驾驶习惯）
- 诊断数据（某些敏感参数）
但说实话，在 CAN 总线上，机密性往往不是最优先的。因为 CAN 报文本来就是广播的，所有节点都能看到。真正需要机密性的是 OTA 升级包、远程诊断会话这类场景。我建议用 AES-128 或更高强度的加密算法来保护这些数据。
3.3.2 完整性（Integrity）
完整性，就是确保数据没有被篡改。这个在车载网络里太重要了。你想想，如果攻击者篡改了刹车指令的报文，后果是什么？
完整性保护通常靠两种手段：
- 消息认证码（MAC）：比如 CAN 报文尾部附加 4 字节的 CMAC。
- 哈希校验：比如固件升级包的 SHA-256 校验。
避坑指南：我曾经遇到一个项目，工程师在 CAN 报文里加了 CRC 校验就以为保证了完整性。但 CRC 是防随机错误的，不是防恶意篡改的。攻击者完全可以重新计算 CRC。记住，完整性保护必须用密码学方法，不是简单的校验和。
3.3.3 可用性（Availability）
可用性，就是系统在需要的时候能正常工作。在车载环境里，可用性比什么都重要。你想想，如果攻击者通过发送大量高优先级报文，把 CAN 总线占满，导致刹车信号发不出去——这就是典型的“拒绝服务攻击”。
保护可用性的常见方法：
- 总线负载监控：用 CANoe 监控总线负载率，超过阈值就告警。
- 优先级隔离：关键安全报文使用最高优先级 ID。
- 速率限制：限制每个节点发送报文的频率。
我记得有一次做渗透测试，我用一个简单的 CAPL 脚本，每秒往 CAN 总线发送 1000 条 0x000 的报文，结果目标 ECU 直接死机了。这就是可用性被破坏的典型案例。
3.3.4 真实性（Authenticity）
真实性，就是确认消息的来源是可信的。说白了，就是“谁发的”。在 CAN 总线上，默认情况下任何节点都可以发送任何 ID 的报文，这就是“伪造攻击”的根源。
真实性保护的核心手段：
- 消息认证码（MAC）：发送方用密钥计算 MAC，接收方验证。
- 数字签名：用于 OTA 升级包等场景。
- 身份认证协议：比如基于对称密钥的挑战-响应认证。
关键点：真实性和完整性经常一起实现。比如 AUTOSAR 的 SecOC（安全板载通信）模块，就是在 CAN 报文里同时提供完整性和真实性保护。我建议在项目初期就把 SecOC 集成进去，后期再加成本高很多。
3.4 四个目标的优先级排序
在实际项目中，这四个目标不是同等重要的。我个人的经验排序是：
- 可用性：安全第一，系统必须能工作。
- 完整性：数据不能被篡改。
- 真实性：来源必须可信。
- 机密性：在车载场景里，优先级相对靠后。
当然，这个排序不是绝对的。比如在 V2X 通信中，机密性可能比完整性更重要。具体问题具体分析。
好了，这一章的内容就到这里。下一章我们会深入 CANoe 工具，看看怎么用 CAPL 脚本实现这些安全目标的测试。到时候我会带大家写几个实用的测试脚本。