做车联网安全这几年最常被问的一句话是“车联网安全到底难在哪”每次我都想反问一句你平时手机上那些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、合规流程这些都是必要的拼图但每一块都依赖执行者的细节。真正决定一款车安全水平的不是它宣传册上写了多少防护手段而是安全团队在面对“成本、工期、体验”压力时能守住多少底线。当初我刚入行的时候有位前辈跟我说做汽车安全的人要有一颗“怕死”的心。当时觉得是玩笑后来踩过坑、看过真实漏洞利用演示之后才明白这话的重量。电子电气架构越集成软件定义汽车越普及安全这口饭只会越来越重要。希望这篇内容能给你理出一条清晰的车联网安全全景路线图也期待在评论区看到大家的实战经验。