首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >虹科干货 | 避免百万级召回!车辆安全网关的防护要点

虹科干货 | 避免百万级召回!车辆安全网关的防护要点

原创
作者头像
用户11291338
发布2025-05-22 14:21:09
发布2025-05-22 14:21:09
1840
举报

摘要 控制器局域网(CAN)安全网关通常用于将车辆的不可信部分与可信部分隔离开来。尽管从概念上讲,它很简单,但有时可能会造成一些难以察觉的问题。这些问题在测试阶段可能不会被发现,直到车辆投入使用或遭遇复杂的安全攻击时才会显现出来。特别是在处理传输帧时,常见的问题有加密保护间歇性失效、消息丢失或损坏,以及受保护的CAN总线上的通信中断。想要构建稳健安全的网关就必须避免这些问题

01. 引言

安全网关是保障CAN总线安全的常用技术(与加密消息传递、入侵检测和硬件安全一同使用 [1])。其主要目的是保护硬实时机电控制总线,使其免受无线连接的易受攻击设备的干扰,例如远程信息处理控制单元(TCU)和车载信息娱乐系统(IVI)。这是非常必要的,因为(对于足够复杂的系统而言,是「何时」而非「是否」[2])当这些易受攻击的设备在攻击中被攻破时,安全网关等技术可以保证攻击者无法危及车辆的基本控制功能

安全网关在车辆网络中还有第二个用途:将CAN总线划分为多个网段,能做到当某个网段受到物理攻击时,其他网段仍能继续正常运行而不受干扰。例如,CAN注入攻击[3]通过汽车上易于触及的部位(如大灯连接器)接入CAN总线,使盗窃装置能够伪造消息(例如发送禁用防盗器或解锁车门的指令)。而在易于窃入的CAN总线与车辆其他部分之间设置安全网关,就可以防止此类攻击。

图1 概念上简单的CAN安全网关
图1 概念上简单的CAN安全网关

一种常见的定义安全性的方法是通过「CIA 三元组」:保密性(Confidentiality)、完整性(Integrity)、可用性(Availability)。对于CAN总线来说,最常见的攻击是完整性攻击:攻击者选择CAN标识符来发送伪造消息,使接收者误以为是真实消息并据此执行操作。

因此,CAN安全网关在概念上很简单:它是一个连接两条CAN总线的设备,能够过滤帧,仅将合适的子集从一条总线复制到另一条总线(见图 1)。

但是,安全网关有许多容易被忽视的细节,尤其是在可用性方面。如果处理不当,将会导致网络不安全或无法正常运行。

美国国家汽车货运协会(NMFTA)制定了一套安全网关的要求,以确保其正确运行。这些要求以正式的需求语言定义,并已公开[5]。本文基于这些要求,重点讨论CAN安全网关的两个关键方面:1)帧传输;2)帧丢弃

02. 帧传输

帧的传输看似简单,实则暗藏陷阱。首先是传输顺序问题。CAN安全网关绝不能重新排序帧,因为事件的顺序对应用程序至关重要。例如,ISO-TP[6]传输协议会从一系列CAN帧中组合一条大消息,如果帧的顺序被打乱,整个消息的接收可能会失败(每个CAN帧都附有序列号,但有些检错实现方式只是检查是否有间隙,然后触发错误,甚至有些直接忽略序列号)。

图2 因帧重排序导致的消息接收问题
图2 因帧重排序导致的消息接收问题

当帧受到加密保护时,也会出现这个问题,例如使用SecOC[7]或CryptoCAN[8]。加密方案旨在防范重放攻击[9],即攻击者复制合法帧并在稍后重新发送,以诱使接收者执行操作。这些方案通常会将重排序的帧视为重放攻击的尝试,这往往会导致误报,而过多的误报会导致真正的攻击被忽视。

图3 网关可能导致重放攻击误报
图3 网关可能导致重放攻击误报

CAN帧通常不是由专门编写的安全网关软件重新排序,而是由CAN控制器硬件造成的。大多数CAN控制器都有一个传输优先级队列,队列中的下一个要发送的帧不是队首的帧,而是CAN标识符最低的帧。有些控制器硬件通过一组比较器电路来比较每个帧缓冲区槽的标识符,有些则通过状态机顺序扫描帧缓冲区槽,跟踪目前看到的最低数值。无论哪种方式,当队列中有两个或更多具有相同标识符的CAN帧时,就会出现问题:硬件必须决定先发送哪一个。在大多数情况下,这种「平局」是随机解决的(例如根据帧缓冲区槽的编号,或者顺序扫描中最后看到的帧)。

图4 传输队列状态序列,ID为0x10的帧无序传输
图4 传输队列状态序列,ID为0x10的帧无序传输

两个具有相同标识符的帧同时出现在传输队列中的一个原因是帧到达抖动(Frame Arrival Jitter)。一般来说,抖动是指周期性事件特定时间的变化性。车辆控制网络中的大多数CAN帧是周期性生成的(通常它们携带由电子控制单元ECU中的周期性控制回路产生的数据)。虽然它们是严格周期性生成的(即生成一个帧与下一个帧之间有固定的时间间隔),但到达接收者的时间并不相同:基本周期相同,但到达时间存在抖动(见图5)。

图5 由于等待仲裁的时间不同,帧按周期排队,但到达时间存在抖动
图5 由于等待仲裁的时间不同,帧按周期排队,但到达时间存在抖动

抖动意味着如果将周期性帧直接从输入的CAN控制器先进先出队列(FIFO)复制到输出的优先级队列中,那么同一时间队列中可能会有多个具有相同标识符的帧(见图6)。

帧抖动是一个特别棘手的问题,因为在运行时观察到的给定帧的抖动取决于两条CAN总线上的特定流量模式。在测试期间,可能不会观察到CAN帧的重排序,但在两条总线处于特定负载情况下,安全或ISO-TP消息传递可能会出现高度间歇性故障,从而暴露这个问题。在后期制作环境中可能根本无法追踪此类故障的原因,而且在任何情况下,故障都不是简单的错误造成的,而是安全网关的设计缺陷。

图6 帧抖动导致帧重排序
图6 帧抖动导致帧重排序

解决重排序问题的方法是在传输队列中采用FIFO缓冲。然而,这又会直接导致另一个问题:CAN优先级反转[4]。当FIFO队列的前端是一个低优先级帧,而紧急的高优先级帧在其后时,就会发生优先级反转。如果总线长时间被更高优先级的流量占用,队列前端的帧将长时间无法赢得仲裁,从而导致紧急帧被长时间延迟(见图7)。

图7 网关可能导致重放攻击误报
图7 网关可能导致重放攻击误报

与帧抖动一样,优先级反转也可能是间歇性的:它可能在测试中不会出现,因为这取决于总线上排队和传输的CAN帧的特定顺序。但若发生其后果同样严重:一个周期为10ms的紧急帧有时可能会被延迟90ms,这可能会导致各种故障(包括触发超时,使组件被误认为发生故障)。在量产车辆中,此类故障的后果可能非常严重。

解决既要保证优先级又要保证FIFO传输这一看似矛盾的问题的方法是,认识到FIFO传输的要求是针对具有相同标识符的帧。这意味着网关中正确的帧传输策略不是仅设置一个优先级队列,而是为每个帧标识符设置一个FIFO,再将其输入到优先级队列中(见图8)。

图8 多个FIFO队列输入到一个优先级队列
图8 多个FIFO队列输入到一个优先级队列

帧抖动还会给安全网关带来另一个问题:它会破坏目标总线的实时特性

从图6中可以看出,CAN A的到达抖动会导致帧在时间上「聚集」,而安全网关会将这些帧立即放入CAN B的队列中,这使得两个帧在比在CAN A上短得多的时间内排队。而这意味着在短时间间隔内,由于转发帧导致的总线负载会高得多(当然,在长时间间隔内,总线负载是相同的,但实时系统关注的是短期利用率)。

安全网关导致的这种较高的短期总线负载意味着攻击者可以在CAN总线上精心设计一种流量模式,在受安全网关保护的CAN总线上引发定时故障,从而导致故障(例如上文提到的错过超时)。在CIA三元组中,这是可用性故障的一个例子,属于一种拒绝服务攻击。

为了抵御这种类型的攻击(并消除由于抖动导致的间歇性定时故障),安全网关应实施帧延迟机制:在自上一个帧排队起至少经过一个帧周期时间之前,不应将帧放入其传输FIFO中(见图9)。

图9 延迟提前到达的帧
图9 延迟提前到达的帧

通过将帧延迟到其周期时间结束,目标总线上的定时行为与原始发送 ECU 直接排队该帧时没有区别。唯一的区别是,在这种情况下,延迟会增加第二个帧的延迟时间。但是,通过网关的额外延迟不会导致最坏情况下的延迟增加:实际上,抖动会使帧比预期更早出现,而延迟机制仅适用于提前到达的帧。通过延迟提前到达的帧,安全网关可以维持现有CAN定时分析[10]所保证的最坏情况延迟,从而维持从一条CAN总线到另一条CAN总线的端到端延迟保证。

03. 帧丢弃

CAN在常见的现场总线中独具特色,它提供原子广播功能。这一特性对于构建稳健的系统非常有用,许多应用程序都依赖于它(即使是在不知情的情况下)。当发送方将消息标记为「已发送」时,发送方就知道每个在线节点都接收到了该消息的有效副本。

实际上,CAN在硬件层面实现了共识机制。而对于其他协议,如以太网,如果接收到的消息不正确(例如以太网帧的CRC,即帧校验序列不匹配),则该帧将被丢弃。这意味着总线上的简单噪声就可能导致节点对系统状态的看法出现分歧(一个接收方只能看到旧的传感器读数,而另一个接收方看到的是较新的读数)。分布式共识是稳健的分布式实时控制系统的关键组成部分,要在非稳健的现场总线上通过软件协议实现这一特性非常困难。事实上,兰伯特的拜占庭将军问题就源于一个试图解决此问题的研究项目[11]。

这就对安全网关提出了一个重要要求:维护CAN的分布式共识特性。引入安全网关不应破坏现有应用程序的假设,尤其是那些隐含的假设。换句话说,安全网关绝不能丢弃帧(当然,除非系统确实存在故障,这里的「故障」包括对系统的攻击)。

当然,有时为了抵御攻击,安全网关必须丢弃某些帧。例如,除非连接了合法的诊断测试仪,否则诊断测试仪帧应被丢弃;在遭受泛洪攻击时,相关帧也应被丢弃等。但是,安全网关也绝不能因为瞬态过载导致缓冲区空间不足而丢弃帧。

在接收端,这意味着必须以CAN总线的全速接收和处理帧:如果两个具有相同标识符的帧连续到达,CAN控制器硬件及其驱动软件绝不能丢失其中任何一个帧。通常,这意味着要通过中断服务程序(ISR)来处理CAN帧,并且CPU的调度必须能够在各自的截止时间内处理来自所有CAN控制器的所有中断(以及CPU的所有其他需求)。这通常需要对CPU进行仔细的调度,并了解ISR的最坏情况执行时间。对于CAN帧的传输,必须有足够的空间来存储所有待发送的帧(包括延迟的帧)。

一种限制缓冲区空间的方法,类似于在ECU软件中限制堆栈空间,即不断增加缓冲区空间,直到不再出现溢出情况。显然,这不是一种好方法,因为它依赖于在测试期间观察到最坏情况(因此,几乎不可能同时观察到两条CAN总线上的最坏情况流量模式)。更好的方法是通过计算给定帧在队列中可能停留的最长时间(即其在CAN目标总线上的最坏情况延迟)、可以延迟但仍存储的时间,以及在这些时间内从源CAN总线合法接收的最大次数,来限制缓冲区空间。

总结

安全网关必须满足一些非功能性要求,以充分保护CAN总线免受攻击,同时也不能给系统引入故障。美国国家汽车货运协会(NMFTA)已经用正式的描述语言列举了此类网关的所有要求,并将其公开。

安全网关在保护CAN总线的实时性和分布式共识特性方面有非常具体的要求,这需要在传输CAN帧时仔细处理帧的顺序和缓冲,以避免常见CAN控制器硬件设计的陷阱以及CAN总线上的帧到达抖动问题。

在设计阶段如果不考虑这些问题,可能会在瞬态过载情况下导致故障。这些故障在测试期间可能难以观察到,但在量产车辆数百万小时的运行过程中很可能会显现出来,进而引发可靠性和安全问题,甚至可能导致业务层面的失败。能够限制CAN总线的实时行为是确保在开发过程中通过分析发现问题的关键,而不是将问题留到实际使用中才被发现。


文章来源

本文基于Ben Gardiner(美国国家货运协会,NMFTA)、John Maag(康明斯)、Dr. Ken Tindell(JK能源)在第18届国际CAN大会(iCC)的演讲。已刊于《第18届iCC会议论文集》2024版,由CiA出版。虹科智能互联团队翻译并分享,旨在与行业同仁共享前沿技术成果。

参考文献

[1]    Defending The CAN Bus: Security Gateways (https://kentindell.github.io/2021/11/24/cansecurity-part-3)

[2]    Pwn2Own Automotive 2024 (https://vicone.com/pwn2own-automotive)

[3]    CVE-2023-29389 (https://nvd.nist.gov/vuln/detail/CVE-2023-29389)

[4]     CAN Priority Inversion (https://kentindell.github.io/2020/06/29/can-priority-inversion)

[5]     Implementation Requirements for Secured Gateways, NMFTA (https://nmfta.org/whitepaper/implementation-requirements-for- secured-gateways)

[6]     ISO 15765-2:2016 Road vehicles, Diagnostic communication over Controller Area Network (DoCAN) Part 2: Transport protocol andmnetwork layer services

[7]    Specifcation of Secure Onboard ommunication Protocol, AUTOSAR 969 R23-11 2023-11-23

[8]    Securing CAN: Introduction to CryptoCAN, CAN Newsletter December 2022, (CAN in  Automation)

[9]    Replay attack (https://en.wikipedia.org/wiki Replay_attack)

[10]  Guaranteeing Message Latencies on

Controller Area Network (CAN), K. Tindell    and A. Burns, Proceedings 1st International CAN Conference, 1994

[11]  The Byzantine Generals Problem, L. Lamport, R. Shostak, M. Pease, ACM Transactions on Programming Languages and SystemsVolume 4 Issue 3, 1982


虹科是一家在通讯领域,尤其是汽车电子和智能自动化领域拥有超过16年经验的高科技公司,致力于为客户提供CAN/CAN FD、LIN、车载以太网、TSN等全方位的一站式智能互联解决方案。​​​​

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 01. 引言
  • 02. 帧传输
  • 03. 帧丢弃
  • 总结
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档