做车联网安全这几年，最常被问的一句话是：“车联网安全到底难在哪？”每次我都想反问一句：你平时手机上那些App的漏洞，可能只是丢点数据。但车上随便一个漏洞，轻则被远程锁门、恶意刹车，重则开着一辆几十万的钢铁机器在高速上被人控制。这个“安全观”，跟做互联网安全的还真不一样。
“车联网安全观（2026年第5期）”这个主题，我把它当成一次阶段性的行业复盘来写。这一期我不打算堆概念，而是把车联网安全的整体架构、攻击路径、防护手段、合规落地和实操中踩过的坑，完完整整地梳理一遍。不管你是刚入行的安全工程师，还是整车厂、Tier 1供应商的项目经理，又或者只是买了一辆智能电动车、想弄清楚它到底安不安全的车主，这篇文章都能给你一个清晰的视角。
1. 车联网安全的整体攻防格局：从“功能安全”到“网络安全”
早些年搞汽车安全，大家谈的是功能安全，也就是ISO 26262那套，核心是“系统出故障了别伤人”。但车联网起来之后，威胁模型彻底变了。现在的智能汽车，本质上就是一台装了四个轮子的数据中心加传感器平台，它既有传统的CAN总线、ECU，又有4G/5G蜂窝网络、Wi-Fi、蓝牙、甚至超宽带UWB。当这些外部通信接口开放之后，攻击者就不需要物理接触车辆了，坐在家里、蹲在停车场，用一台笔记本甚至一部手机就能开始试探。
1.1 车载网络的开放带来攻击面激增
传统汽车电子电气架构是相对封闭的，所有ECU之间用CAN总线连接，诊断口OBD、网关、T-Box这些节点虽然能被访问，但多数场景要求攻击者至少能摸到车。现在的新能源和智能网联车，车内的智能座舱域、自动驾驶域、车身域大多基于以太网，域控制器之间高速通信。同时车端长期连接着云平台，还有一对多的App远程控制通道，再加上越来越多的V2X路测通信、OTA升级、数据采集上报，攻击面已经不再局限在物理车身了。
从安全视角看，车联网系统的攻击面大致分成“端、管、云、边、数”五块。端是车端零部件，包括IVI（车载信息娱乐系统）、T-Box（远程通信终端）、网关、智驾域控制器、传感器等等；管是V2X、蜂窝、蓝牙、Wi-Fi等无线通信链路；云包括车厂云平台、第三方服务接口、车队管理系统；边是路侧单元和边缘计算节点；数据则贯穿所有环节，包括车辆位置、驾驶行为、生物特征甚至车主支付信息。任何一块没有防守，整条链路的可信度就会坍塌。
1.2 汽车安全的特点：攻击后果直接落到物理世界
我做互联网安全的朋友经常问，车联网安全不就是“移动IoT安全”加个壳吗？真不是。Web安全里的漏洞，最坏的结果是服务器被拿、用户数据泄露，但车联网安全漏洞它直接连着物理执行机构。攻击者一旦掌握了某条CAN总线或者网关上某个服务的控制权，就可能影响转向、制动、动力系统。哪怕不搞什么高级攻击，仅仅是让仪表盘被篡改、导航被劫持、远程解锁被滥用，也足以造成严重事故。
所以车联网安全必须遵循一个核心原则：以物理后果为核心做风险排序。一个能阻止远程刹车指令的漏洞，和一个能让车机弹广告的漏洞，严重程度完全不是一个量级。在做威胁分析和风险评估时，不能只看技术上的可利用性，还得叠加功能安全视角——也就是漏洞可能导致车辆进入什么状态，该状态的失控是否危及人身安全。这里就引出了一个做过实车测试的人才会懂的问题：安全方案不能为了防攻击而牺牲系统的实时性和确定性。刹车指令延迟300毫秒可能都是不可接受的，这跟IT系统里加一个安全网关随便做深度包检测的思路完全不同。
2. 常见攻击路径与典型案例：安全漏洞是怎么被一步步打开的
聊完整体格局，我挑几条已经被公开验证过的攻击路径展开讲。不用把它们当猎奇故事看，每条路径背后都是具体的技术决策失误或设计盲区。
2.1 无钥匙进入系统：中继攻击是“老熟人”
无钥匙进入与启动系统（PEPS）在几乎所有车型上都标配了，大家习惯走到车旁边拉门就开。但低频数字钥匙基于RFID通信，传统上缺乏双向测距的抗中继能力。攻击者拿两个信号放大器，一个人站在车主旁边，另一个站在车旁，两个人配合就能把车钥匙的信号“接续”过去，让车辆以为车主就在旁边，从而实现开门、启动。
这个问题的根源是“信号存在即信任”，而不是“信号距离被验证”。后来行业普遍引入UWB（超宽带）做距离测算，利用飞行时间精确测距，才把中继攻击的门槛抬高。如果你正在做数字钥匙的选型，我强烈建议优先考虑UWB加蓝牙的融合方案，并且要确保安全测距的密钥在硬件安全模块里协商，而不是只在应用层做个简单的时间戳。2019年前后有多起真实盗车案件曝出，说明这不是理论漏洞，是会被黑产利用的。
2.2 车机与T-Box：一旦拿到Root权限，车辆就“裸奔”了
IVI和T-Box是车联网里最容易被攻击的两个部件。IVI往往跑的是基于Linux或Android的车载系统，功能复杂、开源组件多，供第三方App加载，暴露面巨大。T-Box则是车辆与云端的通信枢纽，管理远程控制指令的收发，如果T-Box失守，攻击者就能冒充云端下发指令。
我曾经跟踪过一个典型的车载Android系统漏洞链：攻击者先利用IVI上某个老版本WebView的渲染漏洞，构造一个恶意网页诱导车主点击，拿到应用层代码执行；再通过内核提权漏洞变成Root；随后利用车机与网关的调试接口，直接在CAN总线或部分以太网上发送伪造报文。这一整条链路下来，从“让女朋友帮你在车上点了个链接”到“远程打开车门”，可能只需要几十秒的脚本执行时间。
T-Box还有一个被忽视的软肋——调试接口。很多供应商为了产线维护方便，默认开放ADB、UART或者Telnet，即使上线前关掉一部分，还是会在售后固件版本里重新打开。这个属于“上线一时爽，维护火葬场”的经典案例。如果实车测试条件允许，建议每次固件更新后都重新做一遍端口扫描和调试接口检查。
2.3 云平台与服务接口：最容易被低估的突破口
车厂的安全团队往往把大量精力放在车端安全上，但真正的重灾区其实是云端。车联网云平台提供车辆远程控制、状态查询、用户账户体系，这些接口如果存在越权、逻辑漏洞，攻击者连车端漏洞都不用找，直接通过API就能操控任意车辆。
印象很深的一次测试，是某平台的车主绑定逻辑，只校验了VIN码（车辆识别码）是否在库里，没校验请求者与车辆的关系。也就是说，我只要拿到别人的VIN，再随便注册一个账号，就能把他车的位置、行程、门锁状态全部拉出来，甚至下发远程寻车、开关空调指令。这是典型的对象级越权。做云端接口设计的时候，每条API都得问自己一句：发起者真的有权限做这件事吗？很多人以为有Token就安全了，但实际上Token只是身份凭证，不解决授权问题。
2.4 CAN总线与车内以太网：从“能读”到“能控”的距离
很多入门教程会告诉你，CAN总线上可以直接发报文控制车窗、灯光甚至刹车。但在新型架构里，直接裸读CAN的机会已经不多了，车型普遍部署了安全网关，区分可信域与非可信域。困难点在于CAN协议本身不提供加密和认证，网关策略如果放行了一些“伪诊断”报文，或者某条域的过滤规则写得太宽，后续就可能有大量的横向移动空间。
我建议做车端安全测试时，除了关注CAN报文合法性，还要关注以太网上的服务发现、ARP欺骗、DNS劫持这类传统网络攻击手法。现在很多车型使用SOME/IP做服务通信，如果服务发现报文不加密、不做认证，攻击者可以注册一个服务替代合法的ECU响应，实现中间人篡改。这是从传统IT安全延续过来的老问题，只是换了个工业协议的马甲。
3. 车联网安全防护体系建设：端管云协同的技术框架
讲完了攻击面，就该说怎么防守。车联网安全必须是端管云协同，不可能靠单点防护解决全部问题。下面我拆成四个层面来讲：车端可信基座、通信安全、车云安全与业务安全、以及监测响应。
3.1 车端可信基座：硬件安全模块与安全启动是基石
车端安全最底层的根基是信任根，也就是硬件安全模块。HSM是一个独立的安全岛，密钥材料只能在这个岛内使用，哪怕SoC被完全攻破，HSM里的私钥也掏不走。很多车规级安全方案要求在MCU或SoC里集成HSM，主要就是干这几件事：启动验证、通讯建立会话密钥、签名验签、安全存储。
安全启动是另一个必备项。现在的主流做法是“链式信任验证”：BootROM先校验Bootloader的签名，Bootloader再校验内核、系统镜像的签名，任何一环的哈希对不上，就拒绝启动。这套机制能有效防止攻击者篡改系统固件，但前提是密钥管理得当。我做项目评审时见过不少反面教材——开发环境私钥直接打包在测试固件里，或者所有量产车共用一个签名密钥。这类问题一旦出现，安全启动就形同虚设，黑客拿到了私钥就等于拿到了根权限。
提示：车端密钥的存储和更新必须走安全生命周期管理，量产和调试要严格分离。调试模式下哪怕开了全权限，也不能用包含量产密钥的固件。
3.2 通信安全：双向认证加加密，还要关注协议实现细节
车与云端的通信目前主流是TCP/TLS或者基于MQTT/TLS的安全通道。光有传输层加密还不够，还得做双向TLS认证，也就是车要验证云端身份，云端也要验证车的身份。车端用HSM里的证书签发会话密钥，云端用PKI体系识别车辆身份，这样才能防止中间人攻击。
V2X场景的安全认证则有一套专用体系，业内通常叫“V2X证书管理系统”或缩写为PKI，涉及注册证书、假名证书、应用证书的分类管理。车与车、车与路侧设备之间要用证书实时签名广播消息，防止位置伪造和信息篡改。假名证书的概念很关键，它的作用是在保护位置隐私的同时保证消息可追溯，比如每5分钟换一个假名，但后台还能通过可信机构追溯到真实身份。这套设计在L3以上自动驾驶和交叉路口碰撞预警里尤为重要，信号延迟必须控制在毫秒级，任何过重的加密算法都不适用。
3.3 车云安全与业务安全：接口鉴权、数据合规与风控
云端安全的核心是权限和边界。上面提到的越权漏洞，对应的技术解决方案是全链路API鉴权和细粒度访问控制。建议所有车辆功能都要先经过一个统一授权网关做策略决策，而不是在业务代码里散落着各种if else判断当前用户有没有权限。VIN作为请求参数也得注意，不能让用户任意传，要封装在Token里并且由服务器侧解析。
另一个容易忽略的点是数据合规。车联网采集的数据里有大量个人信息和位置轨迹，从收集、存储、传输到删除，全生命周期都要有合规策略。我们在做架构设计时，会先梳理哪些是“最小必要”的数据，避免无意识地采集过量信息。云端的日志里也往往藏着敏感数据，核心日志要做脱敏和访问审计。这些在安全等级保护测评或ISO 21434合规审查当中都是重点审查项。
业务风控层面主要面向车控异常行为和黑产链条。比如短时间内同一个账号对大量车辆下发指令、某个车机证书异常跳动、流量请求频率明显偏离正常行为，这些要接入车联网安全运营中心做实时监控。甚至远程控制指令还需要增加一次动态验证码或生物识别，防止Token被偷后直接被滥用。
3.4 车端入侵检测与OTA安全：让车辆具备“免疫力”和救治能力
再强的边界防护也会被打穿，所以车端必须部署入侵检测与防护系统。车端IDPS的核心是感知车辆状态数据，包括CAN报文、以太网流量、系统进程、文件完整性、系统调用序列等，经过轻量化规则和本机特征学习后识别异常。比如某台车在深夜突然出现了大量诊断请求，或者某个域控制器的CPU飙高且对外发起了异常回连，这些都会被标记为可疑事件。
IDPS最麻烦的点在于车端算力和存储都有限，不可能像云端的EDR那样日志全量往上传。所以要做事件裁剪和分级策略：哪些必须实时上报，哪些本地记录等启动时再传，哪些直接丢弃。这个策略得结合车型实际算力来梳理，不能照搬参考架构。
OTA是安全运营中最重要的“救治”通道。一个漏洞被发现之后，能不能在短时间内把修复补丁推送到每一台受影响车辆上，是对整个车厂的考验。OTA安全设计至少要考虑：版本包完整性校验、加密传输、防回滚、安装失败后的回退机制，以及安装包签名密钥的安全管理。其中防回滚非常关键，如果没有这个机制，攻击者可以把车机刷回一个存在旧漏洞的固件版本，然后重新利用。
4. 从标准到落地：合规要求、测试方法与应急响应流程
说到合规和流程，很多工程师第一反应是“这些都是文档工作，跟技术无关”。但实际做下来，它跟技术选型强相关，而且决定了一个安全功能能不能量产交付、出了问题会不会被一票否决。
4.1 看懂ISO 21434与相关准入要求
ISO/SAE 21434是当前车联网安全领域最核心的标准，它规定的是全生命周期的网络安全工程流程，包括概念阶段的风险评估、开发阶段的安全设计、量产后的持续监控与响应。这里有一个关键概念叫“网络安全案例”，跟功能安全里的Safety Case类似，你可以理解成一份“论证书”，向监管和客户证明你的产品实现了期望的安全目标。做这个案例的过程，会逼着团队把每一条威胁路径都映射到具体的缓解措施，而不是嘴上说“我们很安全”。
除了ISO 21434，国内还有相应的整车信息安全准入要求，以及年在逐步落到实处的软件升级备案要求。简单说，新车上市之前，车厂需要自证网络安全管理能力，还要通过包括渗透测试在内的一系列测评。2026年的行业环境里，这条线只会更严。
4.2 渗透测试、模糊测试与安全验证
我实际参与过多个车型的安全测试项目，测试方法基本可以分为三类：静态分析、动态测试和渗透测试。静态分析主要查固件里的安全配置和源码级漏洞，动态测试侧重运行时的行为验证，渗透测试则是结合前两者做全链路漏洞链验证。
模糊测试（Fuzzing）在车端尤其值得投入。车端协议多、格式多，UDS诊断、CAN信号、SOME/IP、MQTT、Wi-Fi管理帧，这些都有一个特点：输入极其复杂，光靠人工代码审计很难覆盖全。用AFL这类工具做覆盖引导的模糊测试，往往能在短时间内触发内存破坏、逻辑异常。我曾经在一个T-Box的OTA模块里跑了一晚上的模糊测试，就撞出了三个崩溃，其中一个能稳定触发越界写。这类问题在互联网软件里可能只是崩溃，在车里就可能变成安全控制模块失效。
4.3 安全运营中心与漏洞应急响应
量产不是安全的终点，而是长期运行的起点。车厂要建自己的SOC或安全运营中心，负责监控车端上报的异常事件、云端告警、以及外部白帽提交的漏洞报告。有了告警还不够，得形成闭环流程：发现事件→评估影响→决定是否召回或OTA修复→发布修复包→验证→推送→确认。
应急响应中有一个有趣且现实的问题：如何确定漏洞影响哪些车型和哪些固件版本。建议在架构设计初期就把软件物料清单（SBOM）管理起来，否则漏洞爆发时只能靠人工翻表格，效率非常低。SBOM要做细，不光记录开源组件版本，还得记录组件之间的依赖关系。行业内不止一家车厂因为某个第三方库漏洞，被弄得焦头烂额，就是因为不知道哪些车型、哪些ECU用了这个库。
5. 实操心得：车联网安全项目里的常见问题与避坑指南
技术大框架都搭完了，后面这些是我经历过多个项目之后积累的一些实战观察，希望对正在推进车联网安全的团队有点帮助。
5.1 误把“合规材料”当“安全能力”
第一个坑是过度重视文档、轻视落地效果。ISO 21434要求做TARA（威胁分析与风险评估），很多团队做个Excel表格，把风险清单列得漂漂亮亮，但问到底层措施有没有实现、有没有测试验证，就很难回答。真正拉通的做法是让TARA输出直接落到安全需求和测试用例里，每一个风险项都有对应的验证记录。一份没有和测试闭环的TARA，实际上就是废纸。
5.2 忽略供应链安全
智能汽车里四分之三以上的代码可能来自供应商。很多团队把安全要求写在采购合同里，但交付之后没有做验收。我的建议是，在供应商定点阶段就明确安全交付物清单，包括SBOM、设计文档、自测报告、已知漏洞清单，量产前必须做一次供应商代码抽查或关键模块渗透测试。ABB供应链出问题的故事，在汽车行业只会被放得更大。
5.3 车联网安全组织的协作难题
车联网安全项目往往横跨多个团队：安全团队、嵌入式开发团队、云平台团队、测试团队、甚至法务合规。项目里最耗时的往往不是技术突破，而是跨团队的沟通。我自己带项目时，会主动做一件事：用一周时间把所有相关团队的安全测试结果和风险项汇总成一张风险看板，每周更新一次。不要指望一份大而全的报告能推动所有人行动，看板里只留下三条：最紧急的问题、决策人、截止时间。这比任何制度都高效。
5.4 车主视角的几点现实建议
我自己作为智能电动车车主，也给身边朋友提过几个用车建议。第一，尽量在正规渠道下载App和升级车机系统，不在陌生网络环境里给车机开热点或者连接未知Wi-Fi，避免手机和车辆同时暴露在可疑网络环境下。第二，不要把车机账户密码设成和银行卡、邮箱一样的密码，防止撞库。第三，如果是二手车，接收后第一时间在车机端退出原车主的账户，并重置数字钥匙和蓝牙配对列表。第四，如果发现车辆出现了异常行为，比如远程控制失灵、行驶中车机反复重启、定位漂移，及时联系车厂客服做安全检测。
给团队的建议是：安全测试不是一次性的，每半年都应该重新做一轮精简版的安全评审，重点检查新功能模块和第三方SDK的引入情况。我见过很多事故，都是老系统稳如老狗，新加的一个娱乐小程序把整个安全边界撕开了口子。
写在最后：做车联网安全的一点个人体会
这一期“安全观”梳理下来，我的最大体会是：车联网安全没有真正的“银弹”。硬件安全模块、安全启动、加密通信、IDPS、合规流程，这些都是必要的拼图，但每一块都依赖执行者的细节。真正决定一款车安全水平的，不是它宣传册上写了多少防护手段，而是安全团队在面对“成本、工期、体验”压力时，能守住多少底线。
当初我刚入行的时候，有位前辈跟我说，做汽车安全的人，要有一颗“怕死”的心。当时觉得是玩笑，后来踩过坑、看过真实漏洞利用演示之后，才明白这话的重量。电子电气架构越集成，软件定义汽车越普及，安全这口饭只会越来越重要。希望这篇内容能给你理出一条清晰的车联网安全全景路线图，也期待在评论区看到大家的实战经验。
