自动驾驶安全架构实战：威胁建模、纵深防御与传感器欺骗防护

做自动驾驶安全这几年我经常被问到一个问题车上的安全架构和云安全、终端安全到底有什么本质区别明明都是加密、认证、防火墙那一套为什么非要单独开一个系列来聊说实话这也是我写这个系列的原因——如果只是把服务器上的安全方案直接搬进车里那大概率会在量产阶段摔得很惨。前两篇我们把自动驾驶为什么需要安全架构这件事聊透了这篇我打算落到工程层面威胁建模怎么做、纵深防御怎么搭、传感器欺骗为什么是最难啃的骨头以及标准落地时那些没人明说的坑。如果你正在做自动驾驶相关的产品、研发或者安全合规这篇文章应该能帮你省下不少自己摸索的时间。我会把我在实际项目中踩过、填过、验证过的东西讲清楚尽量少讲虚的。1. 自动驾驶安全与传统安全的分水岭保护对象从数据变成了决策先说一个很多刚转行过来的人会忽略的点传统的企业信息安全核心保护对象是数据——客户信息、财务数据、源代码丢了数据就是出了大事。但自动驾驶系统里安全架构最终保护的是一条决策链路感知、定位、规划、控制。攻击者篡改一条报文、伪造一个障碍物、欺骗一个GPS坐标最终影响的不是信息泄露而是车辆决策错误。这个差异决定了整个架构的设计逻辑完全不同。1.1 实时性约束让安全方案必须减肥做云端安全的同事习惯了一套很成熟的做法传输层上TLS应用层上OAuth数据层全量加密每一次请求都做鉴权和审计。这套组合拳放到自动驾驶的控制器里第一个撞上的就是实时性墙。我举个例子一个典型的AEB自动紧急制动决策链路从传感器数据进入算平台到规划模块输出刹车指令留给整套软件栈的端到端时延一般是100毫秒左右激进一点的项目压到50毫秒。你在这个链路上加一层证书校验、来一次非对称解密几十毫秒就没了刹车还没反应过来车已经撞上了。所以自动驾驶安全架构的第一原则不是能上多重的安全手段而是在满足实时性预算的前提下把安全做到最优。这有点像机场安检和急诊抢救的区别机场可以慢慢核查每一件行李但急诊室给病人用药所有核验必须快、准、还不能出错。车里很多安全机制设计出来就是急诊室模式——轻量、高效、尽量不打断主流程。1.2 功能安全与信息安全从对立走向协同自动驾驶安全圈子里有两套标准绕不开ISO 26262管功能安全ISO 21434管信息安全。很多团队一开始把它们当成两套独立的事情做结果在落地时发现它们经常打架。典型冲突是失效模式的处理逻辑。功能安全的默认策略是fail-safe——检测到系统异常就降级甚至停机这样最安全。但信息安全场景下如果检测到异常就直接停机车辆在高速上突然失去动力后果可能比被攻击还严重。所以设计上要做取舍哪些异常触发降级哪些异常触发隔离哪些异常只是记录告警继续运行。我见过一个很有意思的案例某项目在安全网关里检测到某条总线报文被篡改第一版策略是直接切断网关通信结果测试时车辆在行驶中突然失去所有网络控制。后来我们改成了拒绝该报文并告警、连续超阈值才切断问题才解决。这个过程中最大的经验是功能安全和信息安全的团队必须从架构阶段就坐在一起否则后面改一次就是一次大返工。1.3 生命周期和安全更新的根本差异手机平均两三年就换汽车的设计寿命普遍是十年以上。这意味着安全架构不能只考虑出厂时是安全的还要考虑出厂五年后依然防得住新的攻击手法。这是自动驾驶安全架构和其他安全体系最本质的时间维度差异。带来的直接后果是OTA升级能力几乎成了安全架构的刚需。漏洞修复、密钥轮换、策略更新都必须能通过安全的远程通道完成。这又反过来要求你在设计之初就把升级链路做成安全链路——签名、防重放、灰度发布、回滚机制哪一环缺失后续的安全运营就是空谈。我后面会专门讲OTA这条链路里藏着的坑。2. 威胁建模实操把攻击面摊开再让攻击树告诉你先防谁很多刚入行的朋友拿到一个项目第一反应是问用什么安全产品——上什么防火墙、装什么IDS、加什么加密芯片。但做安全架构的第一步不是选产品而是搞清楚敌人能从哪里进来、进来之后能走多远。威胁建模做不好后面所有防御都是瞎忙。2.1 自动驾驶系统的六大攻击入口我习惯把自动驾驶系统按攻击入口拆成六层来看这样讨论起来不容易漏。攻击入口典型载体攻击难度潜在影响传感器层GPS欺骗、LiDAR注入、摄像头眩光、超声波干扰中偏低感知偏差、漏检误检车内网络OBD接口、CAN/CAN-FD/Ethernet报文注入、网关漏洞中控制指令篡改、数据伪造无线通信4G/5G、WiFi、蓝牙、V2X、遥控钥匙低远程入侵、车辆被盗云端服务OTA平台、远程诊断、数据采集服务中到高批量远程控制、数据泄露移动应用车主App、代驾平台、共享出行服务低到中越权控制、隐私窃取物理接口USB口、调试串口、JTAG、未锁的诊断口高需要接近车辆密钥提取、固件逆向这个表我建议团队里人手一份每次讨论新功能时先对着表格过一遍看看这个功能会不会打开新的攻击通道。比如你要上一个远程哨兵模式车主通过手机查看车辆周围摄像头画面这就同时打开了移动应用、无线通信、车内网络摄像头数据回传三条链路每条链路都要单独做威胁分析。2.2 从攻击树到风险排序先防谁后防谁攻击面梳理清楚之后下一步是对每一条可能的攻击路径做攻击树分析。攻击树是经典方法但真正落地时很多人把它做成了学术练习画了一堆树最后不知道怎么用。我自己的做法是对每条路径给三个维度打分——攻击成本需要什么设备、什么技能、被利用概率在真实世界是否容易被触发、影响严重度最终能控制什么、破坏什么。三个维度综合排序分数最高的前几项就是安全架构必须优先覆盖的。举一个我们实际分析过的例子通过手机App远程控制车辆。攻击树是这样的入侵车主手机 → 拿到App的密钥或凭证 → 伪造App与云端通信 → 云端下发指令 → 车辆执行远程控制。你也可以走另一条支路直接攻击云端接口 → 越权调用控制API → 同样的最终效果。两条支路的攻击成本都很低一条需要先攻手机一条需要挖云端漏洞影响都很严重能解锁车门甚至启动车辆所以这个风险在架构上必须优先防御。我们的方案是App端凭证绑定设备指纹、云端接口做严格的权限校验和风控、车辆端对远程控制指令强制二次认证。三层都做了之后这条路径的攻击成本被抬高了好几个数量级。另一个容易犯的错是只看技术难度不看攻击者的真实动机。你可能会觉得物理接触攻击成本高难度大不用太在意。但如果是共享汽车或者网约车场景攻击者每天都有机会物理接触车辆那OBD接口、USB口这类入口的风险等级就得往上调。3. 纵深防御的三层协同云端、管道、车端缺一不可威胁建模做完接下来就是搭防御体系。自动驾驶安全架构我习惯分成三层来看云端、管道、车端。三层不是各管各的而是互相配合任何一个单点被突破都不能让攻击者直接拿到关键控制权。这就是纵深防御的核心思想——不指望某一层永远不被攻破而是保证被攻破之后还有下一层兜底。3.1 云端防线OTA与数据管道的安全云端是自动驾驶系统里最像传统IT的部分但有几个汽车行业的特殊点。第一个是OTA升级链路。每次推送升级包之前必须对升级包做数字签名车辆端验签通过才允许安装。这个签名听着简单实际落地有一堆细节签名私钥必须放在硬件安全模块里不能出现在任何开发机、CI服务器或运维脚本里私钥要分环境管理开发环境、测试环境、生产环境生产环境的私钥访问需要多人审批每次签名要留审计日志防止内部人员作恶这个威胁模型。第二个是车辆数据采集链路。自动驾驶车辆每天会产生海量的传感器数据、定位数据、车内视频片段这些数据回传云端时如果不加密、权限控制做得不到位就等于把用户的隐私和车辆的运行细节直接暴露出去。很多项目在早期只关注了控制指令的安全忽略了数据管道也需要同等强度的保护直到出现数据泄露事故才回头补课。我的建议是数据链路从一开始就按个人敏感数据的标准来设计加密传输、最小化采集、分级存储、严格的访问审计。第三个是云端API的防护。远程控制、远程诊断、电子围栏、车队管理这些API一旦被越权调用后果等同于远程控制整车。我的经验是云端接口的权限校验不能只靠网关做一次每个业务接口内部还必须再做一遍资源级授权——比如用户A只能控制自己的车不能通过改一个参数就去控制用户B的车。这种水平越权漏洞在自动驾驶云端服务里出现频率非常高测试时一定要重点覆盖。3.2 车端架构从根信任到域隔离车端是自动驾驶安全架构的主战场我先说几个关键组件。根信任与安全启动。整车的信任链要从一个不可篡改的根开始芯片内置的HSM硬件安全模块或TEE可信执行环境作为信任根逐级验证Bootloader、操作系统、应用程序的签名任何一级校验失败都不启动。这条链一旦设计好攻击者想植入持久化的恶意固件就非常困难。但我也要提醒安全启动不是配了就算完成你必须在量产阶段确认每辆车都能顺利走完这条链并且有机制处理验签失败的车辆比如进入恢复模式允许授权的离线刷写否则售后会非常痛苦。安全网关。网关是整个车内网络的边界控制点所有跨域通信都应该经过它。它的职责不光是路由报文还要做访问控制哪个域能访问哪个域、哪些诊断服务允许哪些ID调用、物理接口OBD口接入时默认进入受限模式。很多OEM在早期网关设计里只做了路由功能安全策略后面才补结果导致网关成了整个系统里最容易被突破的一环。域隔离与资源隔离。现代自动驾驶架构里信息娱乐域IVI和自动驾驶域ADAS应该严格隔离。IVI域跑的是安卓这类开放系统攻击面大、漏洞多如果它能直接访问ADAS域的网络或内存那攻击者只要攻破一个娱乐系统App就能威胁行车安全。隔离手段包括网络层通过网关隔离系统层通过虚拟化或独立的SoC物理隔离。我的经验是物理隔离最省心但成本高虚拟化方案灵活但性能隔离和安全审计难度更大需要专业团队长期维护。3.3 通信信任体系车内总线与V2X证书车内网络从CAN总线演进到CAN-FD、车载以太网攻击手法也在升级。CAN总线本身没有认证机制任何节点都能往总线上发报文这是长期存在的短板。现在的常规做法是引入SecOC安全车载通信机制给关键信号做消息认证码和新鲜度值校验防止报文被篡改和重放。但SecOC在CAN总线上的带宽受限不可能覆盖所有报文所以架构上要确定哪些信号必须受保护转向、制动、驱动哪些可以放行娱乐信息、非安全相关状态。V2X车路协同这块信任模型的构建方式跟车内完全不同。V2X通信发生在外网环境节点之间互不认识所以要用一套公钥基础设施体系来管理证书。目前主流方案是给每辆车发放批量假名证书——证书定期轮换防止车辆位置轨迹被长期关联追踪。这套体系的设计难点在于证书的签发、吊销、跨域信任、隐私保护都要同时做好。我见过不少项目把V2X安全当成加个证书就行结果CSMS证书管理系统上线后证书轮换时延、吊销名单分发不及时、跨厂商信任不互通实际跑起来问题一大堆。4. 传感器欺骗攻击者最爱、防御方最头疼的战场前面聊的几层防御本质上是数字世界的安全——报文、密钥、证书、权限这些都有比较成熟的手段。但自动驾驶还有一个非常特殊的攻击面传感器。攻击者不需要破解任何密码不需要写任何恶意代码只需要在物理世界里制造假象就能让车辆做出错误决策。这是自动驾驶安全里最让我觉得头疼但必须面对的部分。4.1 三类典型欺骗攻击的实测观察先说GPS欺骗。GPS信号是公开格式、无认证的攻击者用一台百来块的软件无线电设备就能伪造卫星信号。我们在测试场地做过实验给测试车辆发射了一个偏移几十米的虚假定位信号车辆导航立即显示偏离路线如果这时候自动驾驶依赖的是纯GPS定位它就会按错误位置规划路径。防御思路是定位冗余——融合IMU惯性测量单元、轮速计、视觉里程计、高精地图匹配做交叉校验GPS信号如果跟其他信源偏差过大就降低其权重或直接丢弃。这套思路在量产车上已经开始普及但底层逻辑很清楚永远不要把单一传感器当成唯一的真相来源。其次是摄像头干扰。最简单的是用强红外光照射摄像头让画面过曝导致目标丢失更高级的是用对抗样本比如在停止牌上贴一些特殊图案让视觉模型把停车识别成限速。我们在实车上做过贴纸测试某些模型确实会被特定图案骗到。这类攻击的现实风险在于成本极低——一个强光手电筒就能触发感知降级。防御方向有两个一是感知层面做异常检测比如画面整体过曝时判定传感器受攻击并进入保守模式二是决策层面做冗余视觉丢了还能靠雷达和激光雷达兜底系统整体不会因为单一传感器失效就失去安全能力。激光雷达攻击更复杂但也更致命。攻击者可以伪造激光点云凭空制造一个障碍物逼车辆急刹也可以隐藏真实障碍物让车辆撞上去。相比GPS和摄像头激光雷达攻击需要攻击者对传感器原理和算法有深入了解攻击成本更高所以目前更多还是实验室研究阶段。但我们在做评估时已经把点云数据一致性校验和多帧连续性检测作为必选防御项——比如一个障碍物只在单帧出现、没有任何历史轨迹、也不符合物理运动规律那就要打上高不确定性标签宁可慢一点也不要被它带偏。4.2 为什么传感器防御只能缓解难以根治把话说透传感器欺骗在原理上是无解的。因为传感器本来就是感知物理世界的设备攻击者伪造的物理现象和真实物理现象在信号层面很难区分。你不可能给光、给雷达波都加上数字签名。所以这一层防御的目标不是杜绝欺骗而是降低欺骗的可行性和影响。设计上我总结了三板斧多源融合不同物理原理的传感器视觉、毫米波、激光、惯导交叉验证单一信源被欺骗时融合结果不会完全失真。物理合理性校验感知结果必须符合物理规律——障碍物不会凭空出现又消失速度不会突变GPS轨迹不会瞬间跳变。超过物理边界的数据判定为异常。安全降级策略当系统检测到传感器数据异常时不要硬着头皮继续跑而是主动降级——降速、加强人工接管提醒、切换到安全停车模式。这三板斧不能保证100%防住所有欺骗但能把攻击者从轻松得手逼到必须付出极高代价、而且大概率被系统识破的状态。对于安全架构来说这就已经达到了可接受的风险水平。5. 从标准到量产ISO 21434落地与工程里的实战教训最后聊点压箱底的经验。安全架构写得再漂亮最终要落在量产车上而量产意味着要跟供应链、产线、售后、成本反复博弈。这一节我讲几个真实的踩坑经历都是文档里不会写的东西。5.1 ISO 21434落地的两个误区ISO 21434是目前汽车信息安全领域最重要的标准它把网络安全工程引入到车辆全生命周期从概念、开发、生产、运营到报废每个阶段都有要求。但我在审核过多个供应商项目之后发现落地时最常见的误区有两个。第一个误区是把TARA威胁分析与风险评估做成了一次性文档。很多团队为了过审核在项目初期请咨询公司做了一份厚厚的TARA文档然后就束之高阁。实际上TARA应该是一个持续更新的过程——每次新增功能、每次架构变更、每次引入新供应商都要回头重新审视威胁模型和风险等级。我见过一个项目最初TARA里明确写了远程控制必须二次认证结果后来为了用户体验把二次认证砍掉了TARA文档没有同步更新直到安全测试时才被发现返工成本极高。第二个误区是把符合性等同于安全性。通过ISO 21434的流程审计只能说明你的工程过程是规范的不能说明你的产品一定安全。安全最终要靠漏洞测试、渗透测试、模糊测试来验证。我建议项目团队把安全验证当成和功能测试同等重要的工作项至少在以下三个环节强制安排单元开发完成后的安全代码审计、集成阶段的车内网络渗透测试、量产前的云管端全链路红队演练。5.2 我踩过的几个工程坑产线密钥注入的坑。每辆车出厂时都要注入唯一的密钥和证书这个环节如果设计不好要么产线节拍被打爆要么密钥在注入过程中被泄露。我们的解决方案是产线使用独立的密钥注入工位注入设备与整车网络物理隔离密钥由HSM直接写入安全存储区全程不留日志明文。但第一次上线时我们忘了处理测试车辆的密钥管理导致测试车和量产车混用了一套密钥体系排查了好几天才解决。这个教训是密钥体系从第一天起就要区分测试环境和量产环境后面切换成本太高。调试接口未锁死。很多开发板为了方便调试出厂时默认开启了串口打印、JTAG调试、ADB调试。到了量产阶段如果这些接口忘了禁用或者只是软件禁用攻击者就可以通过物理接触拿到调试权限进而dump固件、提取密钥。我们的规则是量产版本的调试接口要么物理移除要么必须通过安全认证流程才能临时开启开启操作要有审计记录。这个规则看起来简单但在多供应商项目中很容易漏一定要在量产前专门做一轮调试接口排查。日志泄露敏感数据。自动驾驶系统运行时会记录大量日志包括GPS坐标、车辆速度、摄像头数据、用户操作等。如果日志以明文形式存到本地或者上传云端一旦日志文件被获取就等于把用户隐私和车辆轨迹交了出去。我们的做法是日志分级分类敏感字段加密存储日志采集走独立的高安全通道日志保留周期设上限。这个模块不起眼却是安全审计里被挑出问题最多的地方之一。5.3 关于可运营的安全安全架构上线不是终点。车辆交付之后你还需要一套持续运营的机制车辆在运行中上报安全事件异常登录、异常报文、异常升级请求云端安全运营中心对这些事件做监控、分析、响应发现新的漏洞时要通过OTA快速下发修复补丁。我见过一些团队把安全架构做成了一次性交付后续不监控、不运营结果安全能力在不知不觉中退化——证书过期没人管、异常事件堆积没人看、漏洞情报出来没人跟进。安全不是一款产品而是一个需要持续投入运营的过程。把这个观念植入团队和项目流程比任何技术方案都重要。最后分享一点个人体会做自动驾驶安全架构这几年我最深的感受是这个领域不存在做完的那一天。攻击手法在进化整车架构在演进标准在更新甚至威胁模型本身都会随着新功能的出现而改变。我们能做的是把整套机制从设计、验证到运营都跑顺让安全的基因长在产品和流程里。如果你也在做类似的事希望这篇漫谈能给你的架构决策提供一点参考。下一篇我打算聊聊自动驾驶安全测试的具体方法和工具链到时候再细聊。