我最近刚做完一台智能车型的常态化安全评估，过程比想象中顺利得多——准确说，是有些过于顺利了。我们只花了几分钟，就通过车联网云端App的一个越权接口拿到了远程控制权限。那台车不是没有防护，T-Box、安全网关、通信加密模块都在，但云端业务逻辑的一个漏洞，让前面整套车端加固全部空转。这就是车联网安全最典型的现实：攻击者根本不碰车身，只要在云端或通信链路里找到一条缝隙，就能把指令一路送到车辆总线。车联网安全威胁分析如果还停留在“给车机装杀毒软件、给App加个加固壳”的层面，大概率是防不住真实攻击的。这篇文章想从一个安全团队的实际评估视角出发，把智能汽车从云端、管端到车端的攻击面完整拆一遍，再讲我们落地时用的防护思路。车厂的安全工程师、车载系统开发者、车联网产品负责人，以及刚接触智能汽车安全的研究者，应该都能从中找到可参考的路径。

1. 智能汽车为什么天然带着一套“新攻击面”

1.1 汽车正在变成“轮子上的服务器”

传统汽车内部的电子控制单元虽然不少，但大部分时间是一个相对封闭的本地网络。车载网络通过CAN总线连接发动机、变速箱、ABS、车身控制等ECU，对外几乎不开放通信接口，攻击者想控制车辆，得先有物理接触的机会，或者通过OBD诊断口、娱乐系统的USB口慢慢渗透。这种模型决定了传统汽车的安全问题主要集中在物理攻击和少数无线钥匙攻击上，边界相对清晰。

智能网联汽车完全不同。整车出厂就会带T-Box远程通信终端，通过4G/5G保持在线；车载娱乐系统默认连接Wi-Fi和蓝牙；用户手机App可以直接访问云端控制接口。相当于汽车在原有物理边界之外，又开出了两条数字化入口：一条从云端来，一条从近距离无线来。攻击者不用站在车旁边，只要能拿下App账号、云端接口或者通信链路中的某个薄弱点，就能远程定位、解锁、开关空调，甚至在某些架构缺陷下触碰制动和转向相关总线。汽车的本质正在从“交通工具”变成“轮子上的服务器”，攻击面也随之被重新定义。

1.2 车规环境的硬约束：为什么不能像修服务器一样修车

网络安全领域的人经常想当然地按IT思路给汽车打补丁，但真正接触车规环境之后会发现很多条条框框。第一是实时性要求，底盘和动力相关的ECU对消息延迟极其敏感，一条CAN报文晚到几毫秒就可能影响控制策略，安全防护不能给关键控制链路增加不可控时延。第二是算力约束，车规级MCU的CPU主频和内存远不如云端服务器，很多高性能加解密算法跑不动，必须选用轻量级密码算法。第三是生命周期约束，一台车要服役十年以上，但车载算力、芯片性能和存储空间都是固定的，安全补丁的兼容性周期远比服务器长。

第四是运营场景约束。服务器异常时可以重启、回滚，汽车在行驶中出问题不能随便重启，升级失败还会直接把用户困在路上。第五是供应链复杂度，一台车有成百上千个ECU，来自不同供应商，安全水平参差不齐，任何一个二级供应商的库文件带漏洞，都会成为整车攻击链的跳板。这些约束组合在一起，决定了车联网安全不能照搬IT安全那套“监测-告警-重启-打补丁”的循环，必须在架构设计阶段就提前做好规划。

2. 威胁建模：把云端、管端、车端三层拆开看

对一个车联网体系，与其笼统地说“汽车被攻击了”，不如把系统按数据流切成三层：云端业务平台、管端通信链路、车端车载系统。我们在实际评估里都用这个模型起步，每次都能快速定位到底哪一环是攻击者最容易切入的点。

2.1 云端攻击面：业务接口越权是重灾区

云端层包括车企的用户账号体系、车辆远程控制API、大数据平台、OTA服务系统，以及车端上报数据的处理服务。这一层最大的特点是代码迭代速度快、业务逻辑复杂、和互联网直接打通。在实际攻防中最常遇到的就是越权访问：用户A调用接口时使用了用户B的车辆标识，服务端没校验归属关系，导致A能对B的车辆下发指令。

为什么越权问题在车联网里格外致命？因为车辆标识号在很多业务系统里是半公开的，甚至能从行驶证、保险单据、App分享功能里拿到。攻击者只要拿到VIN，再配合云端越权接口，就能拼凑出“远程控制任意车辆”的攻击链。除了越权，云端常见的还有批量注册刷接口、短信验证码绕过、车辆状态数据未授权读取、OTA升级包上传接口未校验签名等。这些问题单看都不算高深漏洞，但落在车控场景里，危害等级和传统Web漏洞完全不在一个量级。

2.2 管端攻击面：通信协议里藏着控制指令的地图

管端是车辆与云端之间传输指令和数据的通道，典型协议包括MQTT、HTTP/HTTPS、WebSocket和部分厂商私有TCP长连接。车端T-Box需要通过这个通道上报位置、电量、车况，也要接收远程控制指令。风险评估时，我们一般重点看三个细节：是否启用双向认证，传输层加密是否完备，以及指令是否具备防重放能力。

在多个评估项目里都见过这样的实现：服务端下发指令时确实用了TLS加密，但T-Box的设备证书以明文文件形式放在文件系统里，攻击者从IVI或者调试口拿到该文件后就能仿冒设备。也遇到过MQTT主题名直接包含VIN，客户端只要订阅对应主题就能监听其他车辆的指令流，这是主题级权限控制缺失导致的横向越权。重放攻击则更隐蔽，指令本身有签名，但签名里没有时间戳和单次使用的随机数，攻击者把历史指令原样重发一遍仍然有效。举一个很实际的场景，如果重放的是远程加热功能，反复触发影响的是能源和部件寿命；如果重放的是中控锁指令，后果就可想而知了。

2.3 车端攻击面：真正拿到车辆总线控制权的关键一步

车端是最后也是最难守的一段。典型的车端节点包括T-Box、IVI车机、网关、动力域控制器、车身域控制器、ADAS控制器，以及各类执行器ECU。T-Box是远程指令进入车内网络的桥头堡，IVI是攻击者最容易接触到的智能终端，网关则负责不同域之间的报文隔离和转发。

这里根本性的难点在于CAN总线协议本身是一种广播式总线，设计之初没有源身份认证，所有接入总线的节点都可以收发报文。所以只要攻击者能突破某一条可联网的链路进到车内网络，后续横向扩展就不需要再破解什么复杂密码，只要识别出各控制器的报文ID格式，就能伪造指令。OBD-II诊断接口、IVI的USB口、Wi-Fi和蓝牙模组都可能成为物理或近距离突破口。车端的威胁不是“某个电子元件有漏洞”，而是整车电子电气架构在初始设计时是否足够隔离，让任何单一入口都无法直达关键控制总线。

3. 一条从云端越权到CAN指令的完整攻击链复盘

理论说再多不如完整走一遍。这部分是我们团队在一个模拟车型评估项目里的测试过程，目标很明确：验证一个仅有App和车辆标识的普通用户，能否在不接触车辆的情况下控制一辆同品牌车。全程都在受控环境、封闭场地中进行。

3.1 云端越权：用VIN号找到别人的车辆控制接口

第一站是车主App。我们在一台测试手机上安装App后开启抓包代理，正常走完注册、登录、绑定车辆的流程，很快就能看到App调用的远端域名和接口列表。常规接口包括获取车辆信息、获取车辆状态、远程车控等。这时把请求中代表当前车辆标识的参数从一个合法VIN换成另一个测试车的VIN，服务端就返回了那台车的实时位置和电量信息。继续遍历接口，发现远程解锁接口也一样，完全没校验车辆归属关系。

这个漏洞利用起来的复杂度非常低，就是我们平时在Web渗透里常说的“对象级越权”。但它对车联网的影响被放大了：App端有防止重放或风控机制吗？完全没有，服务端逻辑就没有做归属校验。为了确认利用范围，我们批量注册了一批测试账号去遍历，发现任意注册用户都能控制任意已激活车辆。整个过程不需要任何特殊工具，一个抓包软件加一个脚本就能完成。

# 仅演示越权测试思路，参数已脱敏 curl -X POST https://api.example-cloud.com/v1/vehicle/control/unlock \ -H "Authorization: Bearer <普通用户Token>" \ -d '{"vin":"测试车辆VIN","command":"unlock"}'

这是代写示例，用来展示测试思路，真实环境中的接口封装会复杂很多。但核心逻辑不变：只要服务端信任了客户端传过来的车辆标识，而没有在后端重新校验归属，越权就成立。

3.2 管端重放：一条指令的“身份证”缺失

云端接口的问题暴露后，我们继续向管端深挖。抓取车控指令到达T-Box前后的通信数据时发现，车云链路虽然使用了TLS，但服务器对设备没有做双向认证，设备侧证书也不具备独立身份绑定。更关键的是，车控指令里没有时间戳和随机数，一条合法的“远程解锁”指令被完整记录后，我们可以无限次原样发给T-Box，每次都执行成功。

这个问题的本质是“指令真实性”和“指令时效性”同时缺失。真实性缺失意味着攻击者可以伪造来源；时效性缺失意味着即便攻击者解不开通信加密，只要在某一次合法下发过程中抓包成功，就能反复触发同一操作。防护方案其实并不复杂，在指令中增加单调递增计数器和时间戳，设备端记录最近一次已使用的计数，重复报文直接丢弃。但很多车型在设计时只考虑了加密，没有考虑到“重放也是一种攻击”，这类细节只有在渗透测试后复盘时才会被重视。

3.3 总线横向移动：从OBD接口到车身控制域

最后一段是车端总线。我们在封闭场地的测试车辆上，通过OBD-II接口接入CAN分析工具。正常情况下，诊断口的对外数据会经过网关过滤，但测试车型的网关策略只对部分诊断服务做了限制，远程空调、车窗、门锁等控制指令所在的报文域几乎可以直通。通过捕获正常开关锁动作的流量，分析报文ID和data字段，很快就建立了一套指令模板。

之后我们尝试通过网关白名单放行的ID段构造伪造报文，去触发车窗和后备箱动作。由于网关对报文周期和信号范围没有校验，伪造报文直接被控制器执行。这一步完成后，整条攻击链闭环了：云端越权拿到接口，管端重放拿到指令持久控制力，总线伪造拿到物理执行效果。攻击者不需要站在车旁边，也不需要破解车端任何密码体系，就完成了一次典型的远程控制攻击。

看到这里可能有读者会问，如果网关隔离做得很严格，攻击还能成功吗？答案是难度会大幅提升，但攻击路径仍然存在，只是需要多突破一层防护。所以车联网安全防护的核心逻辑就是：每一层都要设卡，不让任何单点失守直接导致整车沦陷。

4. 车联网防护思路：从单车可信根一路管到云端

防护思路必须对应攻击链反向设计。我们落地的时候一般分四层推进：车端可信根、通信链路防护、总线与网关加固、云端和运营侧纵深配套。四层缺一不可，但顺序有讲究：先解决车辆本身的可信问题，再谈通信和云端防护。

4.1 车端可信根：安全启动和HSM密钥管理

第一层要解决“设备是否可信”的问题。车端T-Box、IVI和网关芯片在启动时要从BootROM开始逐级验签，固件、内核、应用层都必须有合法签名才能执行，否则设备可能被刷入劫持固件。光有安全启动还不够，密钥必须放在HSM安全模块或SE安全单元里，确保固件被读取甚至逆向时，私钥不会暴露。

实际项目里有个容易被忽视的点：安全启动和密钥管理的方案要跟着芯片选型走。如果硬件平台本身不带HSM，后期靠软件实现密钥保护很难达到同样的强度。我们通常建议整车厂在选T-Box和网关芯片时，就把安全启动、安全存储、真随机数发生器作为刚性需求，而不是等到软硬件设计完成后再去补。这个决策看起来只是选型问题，实际上决定了整个安全体系的地基质量。

4.2 通信链路防护：双向认证、防重放与车规PKI

车云通信必须使用双向TLS或者更高强度的mTLS，车端证书由整车厂的PKI体系签发，并且做到一车一证书、支持远程轮换。通信内容层还要考虑指令防重放，在协议设计里加入时间戳、随机数和单调计数器。这里有必要强调：很多方案只做TLS加密，以为加密就等于安全，但加密解决的是“看得见”的问题，身份认证和防重放解决的是“能不能信”的问题，两者缺一不可。

密钥轮换也经常被忽略。证书有效期动辄五年十年，一旦算法被破解或私钥泄露，修复成本极高。我们一般建议OTA系统具备证书和密钥的远程轮换能力，密钥下发本身也要走加密通道，并配合车端安全存储模块完成安装。这套体系一旦建立，设备失窃后即使被物理拆解，也无法仿冒合法身份接入云端。

4.3 总线与网关加固：白名单报文过滤加异常行为检测

总线层防护的关键不是给CAN加“密码”，而是尽量让不可信节点进不了关键总线。网关要做区域隔离，把动力域、座舱域、车身域、诊断域分成独立的安全区域，区域之间的报文按白名单路由，只放行业务确实需要转发的报文ID，其他一律丢弃。门锁、车窗这类控制最好由车身域控制器统一管理，IVI和T-Box不能直接发控制CAN帧。

之前测试中暴露的“越权控制车窗”问题，靠的就是网关报文过滤。在此基础上，网关和域控制器上可以做轻量级入侵检测：很多厂商的周期型报文发送间隔是有规律的，攻击者伪造报文时发送节奏会偏离基线，网关按周期抖动、报文长度、信号范围等特征做异常判定，一旦发现可疑报文就隔离来源节点并上报警告。这套机制不需要重型AI，轻量统计模型就能跑在车规MCU上，在工程上完全可行。

4.4 云端与运营侧：接口权限最小化加安全运营闭环

云端不能只做账号密码保护。API网关需要做细粒度权限校验，车辆归属关系必须在服务端完成校验，不能信任App传入的VIN；账号要绑定设备指纹和风控策略，异常调用直接拦截；所有车控操作必须记录操作日志，包括操作人、时间、车辆、指令内容，做到可审计。

比较容易被忽视的是安全运营闭环。车联网安全不单是静态防护，车辆上报的安全事件需要接入安全运营中心，由分析人员处理告警，再决定是否召回升级或通过OTA修复。我们见过不少车厂花大价钱部署了车端IDS，但告警没人看，事件没人跟，安全能力等于没有。可以简单理解：车端安全设备是“眼睛”，安全运营中心才是“大脑”，没有大脑的眼睛没什么用。

5. 防护落地时最常踩的几个坑

思路正确只是第一步。真正落地的过程中，我们踩过不少坑，也见过同行踩坑，这里把典型问题拿出来说，希望能帮大家少走弯路。

5.1 密钥放在代码里：看似加密了，实则裸奔

第一个坑是证书和密钥的存放位置。有些方案在通信里确实做了加密和签名，但车端私钥直接以文件形式放在文件系统里，甚至还有App把内置证书打包进安装包，攻击者解包就能提取。私有密钥一旦泄露，整个通信链路的安全假设就瓦解了。安全的做法是私钥必须保存在HSM或SE中，只能被动调用，不能被导出。项目评审时如果看到“私钥文件”这种字眼，基本可以判定方案不合规。

这个坑之所以频繁出现，是因为很多研发团队习惯把“加密”等同于“安全”，但密码学体系里密钥管理才是真正的核心。算法可以公开，密钥必须保密，这句话在车联网场景里同样成立。

5.2 OTA只做签名校验，没有兼容检查和回滚机制

第二个坑出现在远程升级环节。一次OTA升级，云端对升级包做了签名，车端验签也通过了，但升级包与当前底层的Bootloader版本不兼容，刷写后车机无法启动。因为没有回滚机制，车辆只能拖回维修站处理，用户对品牌的信任损失远比一次普通故障大得多。

OTA安全不是“验签通过就完事”，还要做版本兼容矩阵检查、分批次灰度发布、失败自动回滚、双分区备份。车联网安全设计要把“升级失败本身也是一种事故”考虑进去，不能只盯着加解密算法，忽略升级链路本身的健壮性。我们在做项目评审时，现在都会加一条硬性检查项：如果升级中断，车辆能否自动回到上一个可用版本。这一条能拦住很多潜在的生产事故。

5.3 安全测试介入太晚：等量产才想起来做评估

第三个坑是时间线问题。很多车厂把安全测试放在SOP前几个月才开始，结果在冬季标定或者路测阶段已经冻结的软硬件，被安全评估推倒重来，改一个网关隔离策略就要重新走一遍测试，成本和时间完全失控。安全评估应该从架构阶段就开始，威胁建模、代码审计、渗透测试分批滚动进行。

一个很现实的经验：在选T-Box芯片的时候就把安全要求提进去，比车造好后再加HSM便宜一个数量级。安全前置说起来容易，但需要安全团队深入整车开发流程，跟着项目节点走，而不是等节点结束了才进场。另外，供应链侧的SBOM物料清单管理也要尽早建立，车端软件组件繁多，第三方库如果没有清单追踪，漏洞爆发后整车厂根本不知道哪些车型受影响，这比安全测试本身更考验组织能力。

做了这些年车联网安全评估，一个很直接的体会是：这个领域没有“一招制敌”的防护，无论云端加固得多好，车端总线总会暴露新的入口；无论车端隔离做得多严，供应链第三方库的漏洞也会冷不丁冒出来。与其追求一套完美方案，不如先把基础闭环搭好——云端接口做对权限校验，车端密钥放进硬件安全模块，网关做好白名单隔离，告警事件有人跟进。这四个基础动作如果都做到位，绝大多数攻击者的成本都会大幅上升。最后再分享一个小建议：如果你的团队刚开始接触车联网安全，不要一上来追求覆盖所有攻击面，先挑自己产品里最值钱的资产，比如远程车控链路或OTA链路，做一次从云端到车端的完整渗透测试，拿到结果再回头补架构。安全这东西，越早看越便宜，越晚补越贵。