登录| 注册 退出
驭捷智能

互联汽车的车内网络安全研究

2021-04-12       浏览:  
分享到:

摘要

本文简要介绍了互联汽车的安全性研究,特别是车载网络的安全性研究。目的是突出研究的现状,发现了哪些问题,提出了哪些解决办法。我们将调查分为以下五类:车载网络问题、架构安全特性、入侵检测系统、蜜罐以及威胁和攻击。我们的结论是,尽管在该领域已经花费了相当多的努力,但大部分努力是针对问题的定义,而不是针对安全解决方案。我们还强调了一些我们认为立即需要关注的领域。

01 简介

本文综述了国内外在连通车辆网络安全方面的研究进展。目的是突出该领域目前的研究,以便在未来可以采取新的方向。

为车辆配备无线连接将为新服务创造许多机会,例如空中固件更新(FOTA)和远程诊断。然而,这些非常吸引人的功能带来了巨大的挑战。内部和外部通信都必须得到适当的保护。这一点特别重要,因为车内网络对安全至关重要,必须避免安全问题导致灾难性的安全影响。因此,我们对最近一些关于联网汽车严重不安全的报道表示关注。

例如,Kosche等人最近就证明了当今车辆缺乏安全性。通过连接到车载诊断II (OBD-II),他们能够发出命令,在驾驶时禁用刹车。虽然这些攻击是通过诊断接口执行的(到目前为止需要对车辆进行物理访问),但我们预计这些攻击将有可能在联网车辆的未来版本中通过无线连接执行。

车辆内的一些系统在设计时考虑到了安全性,例如电子制动装置,但大多数系统都没有考虑到安全性,完整的安全体系结构尚未确定。更复杂的是,我们有理由相信,车辆对车辆(V2V)和车辆对基础设施(V2I)通信的引入将带来更高的威胁级别,因此安全需求将相应提高。

本文的其余部分概述如下。第二部分介绍了该领域的相关研究。在第三部分,我们给出了一个背景的车辆设置。第四部分介绍了在联网车的车内网络安全方面的研究成果。论文最后在第五部分进行了讨论,包括公开的研究问题和第六部分的结论。

02 相关工作

一些关于联网汽车安全性的调查和概述已经在早些时候发布。然而,在这篇论文中,我们关注的是车载网络的安全性,我们没有注意到任何其他与此相关的工作。

Wolf等人对车辆内部的安全性进行了调查。介绍了可能的攻击、保护机制和一些安全关键的应用程序。

Jenkins和Mahmud讨论了安全问题和对车辆的攻击。他们研究了车辆间和车辆内部通信,以及软件和硬件攻击。Kocher等人对嵌入式系统的安全性做了进一步的介绍。

Brooks等人用用例展示了车辆中需要保护的内容,以及车辆上可能进行的操作的不同场景。还对可能的通信方式进行了分类。他们进一步使用经过改编的CERT分类来分析针对已经在车辆中实现的或即将到来的服务的攻击。所分析的服务包括电子控制装置(ECUs)的固件安全更新的需要,以及当车辆越来越多地融入汽车公司的系统时的攻击风险。这种系统的一个例子是远程诊断。

Larson和Nilsson讨论了一种深入防御的方法来保护车辆。他们研究的五层是:预防、探测、偏转、对策和恢复。对于这五层,他们还讨论了可能的需求:认证防止未经授权的访问,入侵检测系统(IDS)和日志机制的检测,建议使用蜜罐进行信息检索,入侵预防系统(IPS)作为对策,并有必要进行可追溯性恢复。另外,Nilsson和Larson扩展了讨论并提出了不同层的方法。

只有少数几个研究项目的主要焦点是确保连接的汽车或与它的通信。其中两个是EVITA和SeV eCOM。

03 背景

A.连网汽车

连网车由三个域组成:

(1)车辆,包括车内网络和ecu

(2)汽车公司向车辆提供服务的门户

(3)车辆与门户之间的通信链接

将车载网络进一步划分为不同总线系统技术的子网;控制器区域网络(CAN)、本地互连网络(LIN)、面向媒体系统传输(MOST)和FlexRay。子网通过专用网关ecu相互连接。

在上面的三个领域中,我们将主要关注车辆。

B.挑战

以下是保障车载网络安全的一些常见要求:

(1) ECU的资源约束,即ECU的处理能力和内存有限。

(2)连接设备的额外成本有限的可能性,新的安全解决方案必须非常具有成本效益。

(3)解决方案使用寿命,车辆可使用10-15年。

C.攻击者模式

在解决车辆设置的安全性时,使用攻击者模型有不同的方法。一种方法是不真正定义或使用攻击者模型。其中,Koscher等人假设他们有必要访问车载网络来执行攻击。

另一种方法是从Howard和Longstaff提出的CERT分类派生出攻击者模型。其中一个can总线上的通信模型是由Nilsson和Larson推导出来的,攻击者可以读取、欺骗、删除、修改、淹没、窃取和重放通信。将该模型进一步应用于FlexRay协议。Lang等人使用基于IP流量的攻击者模型,攻击者可以读取、修改、中断、创建/欺骗和窃取/删除流量。

04 车内网络

在这一章中,我们介绍了与车内网络相关的研究。我们首先强调当前在车载网络中发现的问题。然后,我们将讨论在这些网络中实现安全性的架构。




互联汽车的车内网络安全研究(图1)



建议使用IDSs和蜜罐,然后研究威胁和攻击。图1显示了分类。

A. 车内网络的问题

解决车载网络安全性问题的大部分工作是识别和显示缺乏安全性。在本节中,我们将首先介绍在该领域中正在进行的相关工作,然后总结已经确定的问题。

(1)相关工作:

Koscher等人最近强调,车载网络明显缺乏必要的安全机制。他们在两辆汽车上进行了实验。通过使用包嗅探、包模糊和反向工程等技术,他们发现可以对车内网络执行许多攻击。

Wolf等人研究了车载网络中对不同总线的一些可能攻击。

Hoppe和Dittmann使用模拟来评估安全性。他们研究了对can总线进行嗅探和重放攻击的可能性,通过模拟一个电子窗口电梯系统。为了对他们的攻击进行分类,使用了Howard和Longstaff提出的CERT分类的一个改编版本。其中,Hoppe等人还利用真实硬件对电子车窗系统进行了攻击,对防盗系统和气囊控制系统的警示灯进行了攻击。

Nilsson和Larson介绍了车辆病毒的概念。病毒在远程锁定舱门的can总线上监听信息,当信息被捕获时,病毒采取了适当的行动。为了进一步解决分类技术在保护汽车病毒方面的需要,Hamle和Bauer提出了一种改进的分类方法。

最后,Lang等人对车辆使用基于ip的网络进行连接时的安全影响进行了有趣的讨论。根据“普通IT系统”已知的攻击,即对通信协议、恶意代码和社会工程的攻击,提出了九种“假想攻击场景”。对每个场景进行了机密性、完整性、可用性、真实性和不可抵赖性方面的分析。此外,还试图定量估计对安全的影响。因此,对每个场景都提出了一个安全完整性级别(SIL)值。

(2)识别出的安全问题,以下是识别出的安全问题的摘要:

• 缺乏足够的总线保。can总线缺乏必要的保护来确保机密性、完整性、可用性、真实性和不可抵赖性。can总线上的消息可以被其他节点读取,没有发送方或接收方地址,不受任何消息验证码(MAC)或数字签名的保护。对CAN和FlexRay规范的分析也得出结论,这些协议缺乏必要的数据认证、数据保密性和数据新鲜度的保护。但是,对于数据完整性和数据可用性有一些保护

• 弱身份验证。通过新固件非法重新编程ecu是可能的。其原因是弱身份验证,有时根本没有身份验证。

• 协议的滥用。对车载网络的攻击可以通过误用协议中精心选择的机制来执行。因此,对于LIN-bus,发送恶意睡眠帧可以禁用子网。对于CAN协议,可以使用总线仲裁机制进行拒绝服务攻击(DoS)。通过发送具有最高优先级的消息,其他人将无法使用总线。此外,可以利用格式良好的恶意错误消息攻击CAN和FlexRay实现的故障检测机制,使控制器与网络断开连接。

• 糟糕的协议实现。在某些情况下,协议实现不能恰当地反映协议标准。例如,该标准规定,在车辆行驶时,不应将发动机控制模块(ECM)设置为编程模式。显然,这是出于安全考虑。但是,在某些实现中,确实可以启动一个命令来禁用CAN通信并使ECU进入编程模式,尽管车辆正在移动。

• 信息泄漏。车辆的信息泄漏可以通过操纵诊断协议触发,从而产生潜在的隐私冲突。信息泄漏是通过嗅探一个普通的诊断会话来完成的,然后重播修改后的流量版本。由于网关不能区分普通流量和诊断流量,这两种类型的流量都将由网关转发。

B. 架构安全特性

在本节中,我们将介绍为车载体系结构或通信提出的一些安全特性。特性的摘要见表I。Wolf等人提出了一些提高通信安全性的方法,要求对控制器进行身份验证,并对通信进行加密。首先,每个控制器必须由网关通过证书进行身份验证。验证完成后,控制器将收到一个对称加密密钥,该密钥与本地网络上其他经过验证的控制器共享,从而使秘密数据交换成为可能。




互联汽车的车内网络安全研究(图2)

表I:关于通信的架构安全特性的摘要

Chavez等人建议使用OSI参考模型(ISO 7489-2)的安全服务来保护can协议。OSI模型描述了五种安全服务:机密性、完整性、身份验证、不可抵赖性和访问控制。根据这一点,他们提出可以在协议的更高层处理访问控制,可以使用哈希算法来加强完整性,可以使用can帧的RC4加密来加强保密性。然后,作者评估了不同有效载荷大小的加密时间。剩下的两个OSI服务,身份验证和不可抵赖性,在这个上下文中并不被认为是有用的。

Nilsson等人提出在CAN通信中使用MAC来提供数据完整性和数据认证。为了实现这一点,两个正在通信的ecu之间共享一个128位的密钥。通过使用KASUMI加密算法的密码块链接消息验证码(CBC-MAC),可以生成64位的MAC。MAC通过4条连续的can消息进行计算,得到的MAC被划分为4个16位块,并在接下来的4条can消息的循环冗余码(CRC)字段中进行传输。该协议引入了数据完整性和数据认证验证前的延迟。总共需要8条消息才能完成验证。议定书剩下的两个挑战是;(1)如果MAC计算失败,则无法识别出实际错误的个别消息;(2)无法防止重播攻击。

Groll和Ruland提出了一种体系结构,将通信划分为受信任的组。受信任组中的所有ecu共享相同的对称密钥来加密和解密通信。车辆内的密钥分发中心(KDC)用于为这些受信任的组创建和分发对称密钥。受信任组由访问控制列表(acl)定义,并由汽车公司签名。每个ECU保留一个ACL,并定义ECU所属的受信任组。要将受信任组内用于通信的对称密钥分发给ECU, ECU将其ACL发送给KDC。在KDC验证ACL上的签名之后,KDC将发送回ACL定义的受信任组的对称密钥。为了保护可信组密钥的分布,在ECU和KDC之间使用了非对称加密。所需要的非对称密钥也必须由汽车公司签署。

Oguma等人提出了一种基于认证的安全体系结构。通过应用散列函数,验证ECU中软件的完整性,并将结果与有效散列列表进行比较,他们希望验证ECU只运行真正的软件。只有成功验证的ECUs才能交换对称密钥进行进一步的加密通信。他们提出的体系结构有三个组成部分;(1)车辆外部的中心;(2)车辆内部的主ECU;(3)车辆内部的其他ECU。中心存储关于所有车辆的信息,但是每辆车也需要主ECU来进行认证,因为中心可能不总是可以到达。主ECU包含一个散列值列表,这些值对于在ECU上运行的该车辆的软件是有效的。此外,还使用了密钥预分配系统(KPS),而不是在车辆内使用非对称加密。在执行认证过程之后,使用KPS为每对经过验证的ECU生成加密密钥。支持加密消息和签名消息。这些消息还包含证明ECU已经过验证的信息和防止重播攻击的计数器。Lee等人进一步讨论了基于认证的安全架构。通过使用ProVerif,他们提出了一种方法,根据Wolf等人提出的对安全通信非常重要的一些要求来正式验证协议。

Szilagyi和Koopman提出了一种为时间触发应用程序提供消息验证的方法。因此,协议被设计成能够同时对多个目的地进行身份验证,这要求每对通信节点共享一个对称的加密密钥。这些键用于通过每个目的地的消息计算MAC。每台MAC被进一步分解成几个比特,并连接到消息的末尾。由于只使用少量可用的MAC来伪造消息更容易,因此作者建议通过在一组消息上成功地验证MAC来提供身份验证。对于所研究的两种类型的消息,状态变化消息和反应控制消息,讨论了执行成功攻击的概率上限。该协议还具有对重放攻击的保护。并进一步讨论了该协议,且在模拟攻击的帮助下提供了分析。

Schulze等人提出了一种更通用的方法。这是通过引入数据管理系统(DMS)来实现的;不是让所有ecu相互交换数据,而是将数据存储在车辆内的特定节点中。通过使用DMS存储数据,可以对数据的访问和更新以及并发控制实施访问控制等安全机制,从而确保数据的完整性。该方法还允许在发生事故时将全局状态存储到保护性存储中。研究了部署DMS的三种不同方法:集中式方法、分布式方法和混合方法,在混合方法中为每个子网络部署DMS。混合DMS方法被认为是最有吸引力的。

A. 入侵检测系统

到目前为止,入侵检测系统(IDSs)的研究一直以CAN协议为目标。已经讨论了基于规范和基于异常的检测方法。这里遵循所建议的方法。

1)基于规范的检测:Larson et al.为CAN 2.0和CANopen 3.01协议提出并评估基于规范的IDS。他们的结论是,由于这些协议缺乏关于消息的生产者和消费者的信息,因此没有足够的信息可用来使用基于网络的入侵检测。相反,他们建议基于主机的检测,即在每个ECU中放置一个检测器。然后,可以根据来自协议栈和can协议的目标目录(位于预期的ECU)的信息来研究传入和传出的网络流量。对于ECU中的检测器,可以开发通信协议和ECU行为的安全规范。对于通信协议,安全规范由对单个字段的需求,一个字段对另一个字段的依赖关系和一个对象对另一个对象的依赖关系来描述。此外,ECU的行为由以下安全规范描述:(1)消息传输、(2)消息检索和(3)允许的消息传输和检索速率。

Larson等人从他们对基于规范的方法的评估中得出结论,网关ECU是最需要保护的ECU。如果网关ECU被攻破,他们调查的所有攻击都可以执行。不幸的是,在网关ECU中执行检测比在普通ECU中更难,因为网关中不同接口的检测器必须协作以检测某些攻击,例如检测丢失或修改的消息。

2)基于异常的检测:Hoppe等人的[29]演示了基于异常的CAN协议的IDS。与Larson等人基于规范的方法(IDS放置在ECU中)不同,他们监听can总线上的网络流量。通过查看特定消息在总线上传输的频率,并将其与正常情况进行比较,可以检测传输消息数量的偏差。这一点通过研究检测车辆损坏的系统得到了证明。当防盗报警被激活时,系统会向车灯发送信息,让车灯打开或关闭,从而使车灯闪烁。攻击者不希望这些灯被激活,但是由于can总线是一个广播网络,警报系统发送的消息不能被删除(可能在网关中除外)。相反,攻击者必须创建新消息,以便在消息一点亮时就将其关闭。这些新消息将偏离正常发送的消息数量,并且将被基于异常的IDS检测到。

3)处理入侵警报:入侵检测的一个关键问题是决定如何处理作为成功检测结果的警报。可以考虑将警报发送到中心门户,由安全人员负责处理警报。然而,假设门户应该为连接的大量汽车提供这样的资源可能是不现实的。此外,由于各种原因,car可能无法连续连接到门户。因此,将警报告知司机似乎更现实。这种方法是由Hoppe等人提出的。通过使用人机界面(HCI),可以将各种与安全相关的事件呈现给驱动程序。根据事件的严重程度,可以使用三种不同的方法:(1)非关键事件使用视觉方法,(2)关键事件使用听觉方法,(3)严重事件使用触觉方法。他们还提出了一种“自适应动态决策模型”。通过使用车辆的传感器,可以在警报发出时对车辆的环境进行评估。如果当前使用的提醒驱动程序的方法还不够,则必须提高提醒级别。

4)入侵防护:目前还没有针对车辆设置的入侵防护系统(IPS)。其中,Hoppe等人讨论了入侵响应问题,并指出,由于法律对安全关键系统的要求,主动响应系统可能不允许在车辆中主动做出决策。

B. 蜜罐

蜜罐是另一种可能用于收集和分析针对车内网络的攻击的安全机制。到目前为止,只有一种这样的方法被Verendel等人描述过。建议将蜜罐连接到车内无线网关,模拟车内网络。从蜜罐中收集的数据可以发送到门户并在门户中进行分析。这样做的目的是了解新的攻击,并可能改进系统的下一个版本,从而使系统从一开始就受到这些攻击的保护。蜜罐的一个重要特性是目标的模拟有多逼真。如果模拟不够逼真,攻击者可能会意识到他并没有攻击目标网络。然而,制作一个现实的蜜罐可能是非常困难的,Verendel等人通过提出三个模型来解决这个问题。另一个复杂的问题是,出于安全和安全的考虑,蜜罐应该使用单独的硬件。还应该确保蜜罐不会对真正的车载网络造成不利影响。

C. 威胁和攻击

为了在汽车领域内对攻击进行分类,已经使用了Howard和Longstaff提供的CERT分类,但适应于汽车环境。

Brooks等人和Hoppe和Dittmann也从CERT分类开始,并将其应用于汽车领域。新加入的攻击者包括调谐器和竞争产品; 调谐器可能希望操纵车辆,使其获得更多的马力。

05 讨论与总结

在不久的将来,或者在今天,联网汽车将成为Internet或其他基于ip的网络中的成熟节点。这将增强所提供服务的灵活性和功能。与此同时,我们很可能会面临所有通过互联网传播的威胁。因此,我们将不得不考虑将所有可用的安全机制应用于联网汽车,以适应这种特殊且高度安全关键的环境所带来的特定需求。我们发现,这一进程已经开始,但还有许多工作要做。我们所研究的各个子范畴的整体情况如下:

•车内网络的问题。CAN和FlexRay协议仍然缺乏足够的保护。如果要将外部通信转发到这些总线,则需要应用适当的安全机制。此外,可以注意到为安全而实现的机制,例如can中的故障检测机制,可能会被攻击者用来造成安全问题。此外,一些安全问题是由糟糕的实现引起的。

•架构安全特性。有两种方法使用mac来提供消息的完整性。这些方法通过修改相应的协议来实现MAC。其他方法是提出新的安全体系结构。然而,考虑到车载网络的有限资源,其中一些方法仍然需要进行评估。其他有趣的建议是尝试正式验证基于认证的安全架构,以及通过DMS在车辆中添加安全性的概念。应该对这种DMS如何影响车载网络进行调查。

•入侵检测系统。基于异常和基于规范的IDSs都被建议用于can协议。但是,还没有找到其他协议的方法。由于FlexRay也缺乏适当的安全机制,最终将取代can协议,所以也应该研究FlexRay的IDS。

•蜜罐。在实现蜜罐的过程中,最困难的问题是将其与真实的车载网络分离,并使其尽可能真实。如果蜜罐将被用于收集关于攻击者的信息,那么需要进一步研究如何以一种安全的方式执行此操作。

•威胁和攻击。我们注意到,已经采取了调整CERT分类的步骤,以对针对联网汽车的攻击进行分类。

正如我们所看到的,已经有一些安全特性在汽车环境中进行了应用研究,但是还有更多的特性需要考虑。例如,Wolf简要讨论了防火墙的概念,但是我们知道没有尝试真正引入防火墙,在每个ECU上对流量进行过滤。我们还注意到,在车载网络使用的四种协议(CAN、LIN、MOST和FlexRay)中,几乎所有的研究都针对CAN。关于其他协议的研究很少。

06 结论

我们已经调查了目前有关汽车联网安全的研究,重点是车内网络的安全性。虽然提出了一些解决办法,但大多数研究的重点是查明安全问题,提出解决办法的程度较低。在这方面,还有许多工作要做。增加联网汽车安全性的最大挑战之一将是在非常有限的硬件、软件和电力资源的约束下,使安全解决方案适应非常高的安全要求。

转自知乎上海控安

在线
客服

在线客服 - 驭捷智能周一至周日 10:00-24:00(欢迎呼叫)

选择下列服务马上在线沟通:

客服
热线

18917451722
6*12小时客服服务热线