1. 信息安全概述：车联网安全背景、法规标准与攻击面分析
1.1 车联网安全背景：为什么我们坐不住了？
说实话，五年前我刚接触车载信息安全时，很多同事觉得这是“过度设计”。
“车又不会中病毒，搞这个干嘛？”——这是我当时听到最多的话。
但你看现在，一辆智能网联汽车有超过1亿行代码，4G/5G、Wi-Fi、蓝牙、UWB、V2X全堆上去。说白了，这就是一个装了轮子的服务器。服务器能不被黑吗？
我给大家讲个真实案例。2015年，两位研究员Charlie Miller和Chris Valasek远程入侵了一辆Jeep Cherokee。他们通过车机的蜂窝网络，控制了转向、刹车、甚至变速箱。结果呢？FCA召回了140万辆车。嗯，从那以后，整个行业都醒了。
为什么会这样？因为车联网的架构变了：
- 传统车：封闭网络，CAN总线为主，攻击者得物理接触
- 智能网联车：T-Box、IVI、OTA、云端、手机App全打通，攻击面从物理扩展到了远程
我在项目中遇到过一件事：某OEM的T-Box固件没做签名校验，攻击者通过伪造OTA包直接刷写了恶意固件。你想想看，这要是量产车在路上跑，后果不堪设想。
核心观点：车联网安全不是“要不要做”的问题，而是“怎么做才够”的问题。攻击者已经从炫技转向了利益驱动——勒索、窃取数据、甚至远程控制车辆。
1.2 法规标准：UN R155 和 ISO 21434
聊完背景，咱们得说说规矩。现在做车载信息安全，有两个东西绕不开：UN R155 和 ISO 21434。
1.2.1 UN R155：合规的硬门槛
UN R155是联合国欧洲经济委员会（UNECE）发布的法规，2021年1月生效。它要求所有新车型必须通过网络安全管理系统（CSMS）认证，才能获得整车型式认证。
说白了，没有R155认证，你的车就别想在欧洲卖了。中国、日本、韩国也在跟进。
R155的核心要求我总结为三点：
- 建立CSMS：OEM必须有一个覆盖全生命周期的安全管理体系
- 风险评估：对每个车型进行TARA（威胁分析与风险评估）
- 事件响应：必须有能力检测、响应、上报安全事件
我的建议：别把R155当成一次性的合规任务。我见过有些团队为了赶节点，TARA做得特别粗糙，结果后期发现漏洞还得返工。CSMS应该是持续运转的流程，不是一张纸。
1.2.2 ISO 21434：落地的技术指南
ISO 21434是2021年8月发布的国际标准，全称《道路车辆——网络安全工程》。它和R155是“姊妹篇”——R155说“你要做安全”，ISO 21434说“具体怎么做”。
我个人习惯把ISO 21434的框架分成四个阶段：
| 阶段 | 内容 | 关键输出 |
|---|---|---|
| 概念阶段 | 定义系统边界、资产识别、威胁分析 | TARA报告、安全目标 |
| 开发阶段 | 安全需求分解、架构设计、安全机制实现 | 安全需求规范、设计文档 |
| 验证阶段 | 渗透测试、模糊测试、代码审计 | 测试报告、漏洞清单 |
| 运维阶段 | OTA升级、事件监控、漏洞响应 | 安全事件日志、补丁记录 |
嗯，这里要注意：ISO 21434不是“一刀切”的标准。它允许你根据风险评估的结果来决定安全措施的强度。比如，一个车窗控制器和一个自动驾驶域控制器，安全等级肯定不一样。
避坑指南：我曾经见过一个团队，把ISO 21434的每个条款都当成“必须做”的 checklist，结果文档写了一堆，实际防护效果很差。记住，标准是工具，不是目的。你的目标是降低风险，不是填表格。
1.3 攻击面分析：黑客从哪里下手？
好了，法规讲完了，咱们聊聊实战。攻击面分析，说白了就是“如果你是黑客，你会从哪里打进来？”
我习惯把攻击面分成四层：
1.3.1 外部通信接口
- 蜂窝网络（4G/5G）：T-Box的基带处理器是重灾区。攻击者可以通过伪基站、IMSI捕获器发起中间人攻击
- Wi-Fi/蓝牙：IVI系统的Wi-Fi热点如果没做隔离，攻击者可以跳板进入CAN网络
- V2X：DSRC或C-V2X的消息如果没有签名验证，伪造的碰撞预警可能导致连环追尾
我记得有一次做渗透测试，发现某款车的蓝牙配对过程没有使用安全简单配对（SSP），而是用了古老的“固定PIN码”方式。攻击者只要在车旁边，就能连上车机，然后通过蓝牙漏洞提权。你说危不危险？
1.3.2 内部网络
- CAN总线：传统CAN没有认证和加密，攻击者只要接入OBD-II端口，就能发送任意报文
- 车载以太网：DoIP、SOME/IP等协议如果没有做访问控制，攻击者可以跨域攻击
- 域控制器间通信：智能座舱域和自动驾驶域之间的数据交换，如果没做隔离，一个漏洞就能波及全车
关键点：现在的车已经不再是“一个网络”了。网关、域控制器、中央计算平台把网络分成了多个安全域。攻击面分析的核心就是找出这些域之间的“薄弱连接”。
1.3.3 云端与移动端
- OEM云平台：API接口、用户认证、数据存储——任何一个环节出问题，都可能泄露数百万车辆的数据
- 手机App：远程控车、车辆状态查询、数字钥匙——App的逆向工程和API劫持是常见攻击手法
你想想看，如果攻击者攻破了OEM的云平台，他就能拿到所有车辆的VIN、位置、甚至驾驶行为数据。这已经不是“一辆车”的问题了，而是整个车队的安全。
1.3.4 物理接口
- OBD-II端口：虽然现在很多车做了OBD端口保护，但仍有不少车可以直接通过OBD刷写ECU
- USB/调试串口：IVI系统的USB口如果没做权限控制，插入恶意U盘就能执行代码
- JTAG/SWD调试接口：量产车上如果没熔断调试接口，攻击者可以直接读取固件和密钥
我的经验：做攻击面分析时，别只盯着“高大上”的远程攻击。物理攻击往往是最容易被忽视的。我曾经在一个项目中，发现某款车的调试串口直接暴露在手套箱后面，连个盖子都没有。攻击者只要拆几颗螺丝，就能拿到root shell。
1.4 小结：安全是设计出来的，不是补上去的
好了，第一章的内容就到这里。咱们回顾一下：
- 背景：车联网让攻击面从物理扩展到了远程，安全不再是可选项
- 法规：UN R155是合规门槛，ISO 21434是落地指南，两者缺一不可
- 攻击面：外部通信、内部网络、云端、物理接口——每一层都有风险
我个人习惯在项目启动的第一天就做攻击面分析。别等到开发完了再补安全，那成本高得吓人。记住一句话：安全是设计出来的，不是补上去的。
下一章，咱们会深入聊聊TARA（威胁分析与风险评估）的具体做法。到时候我会拿一个真实的域控制器案例，手把手带大家做一遍。敬请期待。
课后思考：如果你现在负责一款新车型的信息安全，你会优先防护哪个攻击面？为什么？欢迎在留言区讨论。