3、网络安全基础：威胁分析与风险评估（TARA）、安全通信与加密基础、安全启动与安全更新
各位好，欢迎来到第三章。这一章我们聊点硬核的——网络安全基础。
说实话，车联网安全这几年越来越受重视。以前大家觉得车就是机械，现在呢？车就是个带轮子的电脑。你想想看，一个能联网、能 OTA、能跟手机交互的系统，怎么可能没有安全风险？
我个人习惯把网络安全分成三个层面来看：先知道谁要攻击你（TARA），再学会怎么保护通信（加密），最后确保系统本身是干净的（安全启动与更新）。咱们一个一个来。
3.1 威胁分析与风险评估（TARA）
TARA 这个词，做功能安全的朋友应该不陌生。但在网络安全领域，它的含义略有不同。功能安全关注的是“系统失效会不会伤人”，网络安全关注的是“系统被攻击会不会导致危害”。
我在一个项目中遇到过这样的情况：客户要求我们做 TARA，但团队里没人知道从哪下手。后来我们按照 ISO 21434 的流程走了一遍，发现其实没那么玄乎。
3.1.1 TARA 的核心流程
说白了，TARA 就是回答四个问题：
- 资产是什么？——哪些东西需要保护？比如 ECU、CAN 报文、用户数据。
- 威胁是什么？——攻击者可能怎么搞破坏？比如篡改固件、窃取密钥。
- 风险有多高？——结合攻击难度和后果严重性来评估。
- 怎么处理？——降低风险、转移风险、还是接受风险？
嗯，这里要注意：TARA 不是一次性工作。产品迭代、架构变化、甚至新漏洞出现，都可能需要重新评估。
3.1.2 威胁建模方法
常用的威胁建模方法有 STRIDE 和攻击树。我个人更习惯用 STRIDE，因为它覆盖了六种威胁类型：
| 威胁类型 | 含义 | 车规场景举例 |
|---|---|---|
| Spoofing（欺骗） | 冒充合法实体 | 伪造 ECU 身份发送虚假 CAN 报文 |
| Tampering（篡改） | 修改数据或代码 | 篡改 OTA 升级包注入恶意代码 |
| Repudiation（抵赖） | 否认做过某操作 | 攻击者否认发送过攻击指令 |
| Information Disclosure（信息泄露） | 敏感数据被窃取 | 窃取车辆定位或用户隐私 |
| Denial of Service（拒绝服务） | 系统不可用 | 向 CAN 总线发送大量垃圾报文导致总线瘫痪 |
| Elevation of Privilege（权限提升） | 获得更高权限 | 从普通用户权限提权到系统管理员权限 |
3.1.3 风险等级评估
风险等级通常由两个维度决定：攻击可行性和影响严重性。ISO 21434 推荐使用 CVSS（通用漏洞评分系统）来量化风险。
我曾经在一个项目中，评估了一个“远程控制刹车”的威胁。攻击可行性很高（因为 OTA 接口暴露），影响严重性也极高（涉及人身安全）。最后我们把它定为最高风险等级，必须强制缓解。
3.2 安全通信与加密基础
通信安全，说白了就是保证数据在传输过程中不被偷看、不被篡改、不被冒充。这三点分别对应：机密性、完整性、真实性。
3.2.1 对称加密 vs 非对称加密
加密算法分两大类。我刚开始接触时也搞混过，后来用一句话记住了：对称加密像一把钥匙开一把锁，非对称加密像一把公钥锁、一把私钥开。
| 特性 | 对称加密 | 非对称加密 |
|---|---|---|
| 密钥数量 | 1 个（共享密钥） | 2 个（公钥 + 私钥） |
| 速度 | 快（适合大数据量） | 慢（适合小数据量） |
| 典型算法 | AES-128/256 | RSA、ECC |
| 车规应用 | CAN 报文加密、文件加密 | 数字签名、密钥交换 |
实际项目中，我们通常混合使用：用非对称加密交换对称密钥，再用对称加密加密实际数据。这样既安全又高效。
3.2.2 哈希与消息认证码（MAC）
哈希函数用来保证完整性。你发一个文件，我算一下哈希值，跟你的对比一下，就知道文件有没有被改过。
但哈希有个问题：如果攻击者同时篡改了文件和哈希值，你就发现不了。所以需要消息认证码（MAC）——用密钥参与计算，只有持有密钥的双方才能验证。
3.2.3 安全通信协议
常见的车规安全通信协议有：
- SecOC（安全车载通信）——用于 CAN/CAN-FD 总线，给报文加新鲜值和 MAC。
- TLS/DTLS——用于以太网通信，比如 V2X、OTA 下载。
- IPsec——用于网络层加密，适合网关之间的隧道通信。
我记得有一次调试 SecOC，发现新鲜值同步出了问题，导致所有报文都被丢弃。查了两天才发现是时间戳精度不一致。嗯，细节决定成败。
3.3 安全启动与安全更新
安全启动和安全更新，是车规安全的最后一道防线。你想想看，如果攻击者能随便刷个恶意固件到 ECU 里，那前面做的所有加密都白费了。
3.3.1 安全启动（Secure Boot）
安全启动的核心思想是：从硬件信任根开始，逐级验证，确保每一级代码都是可信的。
典型的流程是这样的：
- 芯片上电，执行 ROM 中的 BootROM（不可修改）。
- BootROM 验证第一级 Bootloader 的签名。
- 第一级 Bootloader 验证第二级 Bootloader 或 OS 的签名。
- OS 验证应用程序的签名。
任何一级验证失败，系统就停止启动或进入安全模式。
3.3.2 安全更新（Secure Update）
安全更新，也就是我们常说的 OTA（空中升级）。但 OTA 不只是“把文件下载下来刷进去”那么简单。它必须满足：
- 来源认证——更新包必须来自合法的服务器。
- 完整性校验——更新包在传输过程中没有被篡改。
- 防回滚——不能把系统降级到有漏洞的旧版本。
- 失败恢复——如果更新失败，系统还能恢复到可用状态。
防回滚这一点，我特别想强调。攻击者有时候不会直接攻击你，而是诱导你装回旧版本，再利用旧版本的漏洞。所以，一定要在更新包里带上版本号，并在 ECU 里记录“最低允许版本”。
3.3.3 安全启动与安全更新的关系
这两者其实是相辅相成的。安全启动保证系统启动时是干净的，安全更新保证系统运行时能保持干净。没有安全启动，安全更新刷进去的固件可能被篡改；没有安全更新，安全启动只能保证第一次启动是安全的，后续漏洞无法修补。
下面这张图展示了它们的关系：
3.4 本章小结
这一章我们聊了三个核心主题：
- TARA——帮你识别威胁、评估风险、制定对策。这是所有安全工作的起点。
- 安全通信与加密——用对称/非对称加密、哈希、MAC 来保护数据在传输过程中的安全。
- 安全启动与安全更新——从硬件信任根开始，确保系统始终运行在可信状态。
说实话，网络安全没有银弹。没有哪个算法或协议能解决所有问题。但只要你把基础打牢了，把流程走对了，大部分攻击都能防住。