查看原文
其他

汽车网络安全测试方法

哆啦安全 2022-12-05

The following article is from 智能汽车开发者平台 Author 明琴


摘要

联网汽车内的计算复杂性越来越高,随着自动驾驶汽车的出现,制造商如何测试网络安全保障?联网汽车的计算复杂度不断增加,随着自动驾驶汽车的出现,制造商如何测试网络安全保证?模糊测试是一种成功的黑盒测试方法,黑客们用它来发现各个领域的安全弱点。因此,SAEJ3061中提到的模糊测试(没有任何细节)是否应更广泛地应用于车辆系统开发过程中,以帮助减少漏洞?为了研究这个问题,我们开发了一个自定义模糊器,允许对目标车辆的CAN总线(用作车辆的ecu的数据互连)进行实验。结果表明,模糊测试是车辆系统在准备进行系列生产之前需要进行的众多安全测试之一。然而,以前在对汽车进行网络测试时提出的问题也得到了证实。因此,在将模糊测试加入汽车工程工具箱时,提出了一些需要在未来研究中解决的问题。


I.简介

所有大规模制造的车辆都需要内部联网的计算机才能正常运行。车辆上的计算机被称为电子控制单元(ECUs)。CU运行着从发动机到车内照明的所有设备,通常与低成本的控制器区域网络(CAN)数据总线互连。在车辆中发现的其他网络包括FlexRay、面向媒体的系统传输(MOST)、本地互连网(LIN)和两线制以太网(100BASE-T1)。这些车辆系统可能直接或间接地连接到互联网。这是通过内置的蜂窝通信,或通过司机或乘客的小工具,如智能手机来实现的。这使得我们驾驶的汽车或使用的交通工具成为网络物理系统(CPS)和物联网(IoT)设备。这些联网汽车已被证明患有类似的网络安全漏洞,就像其他基于计算机的网络系统,无论是家庭、办公室还是工业。因此,联网和自动驾驶汽车(CAV)需要能够抵御网络攻击。所以,网络安全测试已被添加到制造商的车辆工程流程的任务清单中,或应成为其一部分,正如政府现在所规定的那样。

由于汽车领域的特殊技术和CPS环境,将既定的网络安全测试方法应用于汽车工程是具有挑战性的。模糊测试是一种成熟的软件动态测试方法,对汽车领域来说是一个有价值的补充吗?本文的贡献是通过一个定制的模糊测试程序来研究这个问题,并开始解决将模糊测试引入汽车系统测试的挑战。

A简要介绍了模糊测试之后,研究了将其应用于车辆系统的现有工作。本文介绍了测试CPS系统的动机和挑战。然后介绍了经过模糊测试的车辆技术,即CAN总线。在讨论观察和进一步的工作和结论之前,将介绍运行自定义软件和结果输出。在讨论观察结果和进一步的工作以及结论之前,介绍了运行定制软件和结果输出。

A. 什么是模糊测试?

模糊测试是一种动态分析测试方法。它是针对正在运行的系统执行的(与对源代码的静态分析相反)。模糊器是一个执行模糊测试的程序。向目标系统生成随机输入数据是模糊器的主要功能。然而,为了更有效率,从而更有效,模糊测试器可以在了解系统数据格式、通信协议和接口的情况下运行。模糊测试的本质是:

-随机输入(fuzz)被发送到系统的接口。

-系统的反应被监测。

-如果系统发生故障,会记录导致故障的条件并重置系统。

-这个过程要重复大量的次数,以覆盖一个大的输入值空间。

-由于执行了大量的测试,模糊测试是自动化的,以提高效率。

能够使软件失效是攻击者用来渗透系统的方法之一。因此,模糊测试现在是一种成熟的、完善的方法,可以发现应用程序和操作系统中的漏洞,并被用来帮助对汽车系统进行逆向工程。然而,它在汽车系统的一般测试中的应用却很低(图1)。

图1 汽车行业的测试方法,来自于[7]的数据


II.相关工作

对车辆黑客的研究通常关注的是证明联网车辆的漏洞。一些研究人员确实在攻击的同时提供解决方案。尽管早期在破坏控制器区域网络(CAN)方面进行了实际演示,但直到2010年大众媒体广泛宣传了实际的联网汽车网络攻击,人们才对针对车辆的网络攻击产生了兴趣。实现媒体广泛报道的2010年的原始研究指出:

事实上,由于有效的CAN包的范围相当小,通过简单的包模糊(即随机或部分随机包的迭代测试)可以造成严重的损害。事实上,对于寻求无差别破坏的攻击者来说,模糊化本身就是一种有效的攻击。

尽管他们对模糊的主要用途是帮助对目标车辆的系统进行反向工程。然而,在网络服务和一般信息系统中,模糊技术被用来破解软件。然而,到目前为止,汽车黑客的模糊测试的价值在于帮助发现汽车系统的功能。这是因为车辆内部系统的操作细节是商业机密。通常情况下,确定一个特定的CAN信息的唯一方法是在操作车辆功能时捕获网络数据包。在生产前的安全测试中,关于模糊测试的有用性的工作做得很少。在汽车系统的模糊测试方面有哪些可用的方法?

[13]提供了一个用于ECU诊断的统一诊断服务(UDS)模糊器的设计。该报告主要关注模糊器的设计,并在UDS模拟器上进行了测试。它确实发现了模拟器的UDS实现中的弱点,尽管没有提供深入的结果介绍。

测试谕问题(如何确定系统的正确响应)对cps来说是一个挑战,特别是在自动化整个安全测试过程方面。在[15]中,提出了一个从一个硬件循环(HIL)和软件循环(SIL)测试和开发系统到基于Python的开源模糊器的链接,称为booFuzz。他们提出了几种解决测试谕问题的方法:

-网络通信监控。

-通过组件调试接口进行监控。通常不用于硬件调试,一旦开始生产,通常就不能使用。

-对模拟器内部可用的系统信号的直接和间接监测。

-使用汽车通用测量和校准协议(XCP),允许远程访问ECU的内部。

-用外部传感器监测系统的物理反应。

然而,没有考虑到任何额外的监测能力可能被攻击者利用,他们会寻找任何信息来源来帮助破坏系统。因此,支持XCP可能有助于详细的ECU诊断,但它提供了另一个可能被利用的渠道。注意到的一个有趣的问题是,汽车ECU有不同的操作模式。在其寿命的大部分时间里,ECU都在提供正常的操作功能。然而,在车辆维修期间,ECU可以被锁定或解锁,以便通过UDS进行软件更新。对于系统测试人员来说,覆盖ECU的所有状态是很重要的,因为这些不同的状态之前已经被利用了。

在[16]中提供了如何配置一个商业模糊器来连接到一个汽车网络。没有给出实际应用,只发布关于数据包吞吐量率的结果。在[17]中,另一个商业模糊工具用于测试单个ECU。测试环境定义了一个比较模块,作为测试参数,在模糊CAN消息时验证ECU的正确操作。

表一列出了已发表的参考工作中所使用的模糊器,加上Peach模糊器,它被宣传为支持汽车测试1。大多数是通用的商业产品,booFuzz是开源的,Peach也有一个开源版本。他们都需要对汽车系统的工作进行调整。两种主要方法是:1)协议,使用CAN数据包的格式(表三),或 2)从系统设计中输入,即对数据包内容有预先的了解(可以从ECU中运行的源代码中得知)。在下面的章节中,将对汽车模糊测试的需求进行研究。


III.动机

安全是汽车的一个关键设计目标。汽车的操作正确性、认证以及与国际和国家标准的一致性都要进行测试。国家间标准化组织(ISO)发布了ISO 26262,用于电气和电子系统的功能安全。然而,对于联网汽车来说,网络攻击是一种超越正常功能操作的威胁。如何解决这种威胁呢?汽车工程师协会(SAE)J3061出版物为CPS提供了一些最佳实践指南,作为引入安全意识的过程和设计的起点,另外ISO/SAE AWI 21434(道路车辆,网络安全工程)正在开发中。然而,对于系统工程师来说,需要适用的方法。

A. 从物理锁到网络锁

从根本上说,安全是一个经济问题,必须在一个系统中加入足够的安全性来劝阻对手。安全措施曾经只是物理性的,比如说更强的锁。现在,网络锁需要认证、数据和通信加密以及其他密码学措施来保护安全属性,其形式为CIA三要素。

•保密性--防止敏感数据被查看。

•完整性--防止数据值的改变。

•可用性--保护系统运行。

然而,网络锁并不能保证系统的安全。计算机代码的一般问题是它很少没有错误。尽管在一个计算系统中尽了最大努力消除错误,但在数十万行代码(LOC)中仍会有一个给定的错误率。攻击者的目标是找到可以用来获取收益的代码错误。寻找弱点所涉及的努力(即成本)越大,攻击者就越有可能寻找其他地方。然而,制造商面临着一个困境,在某种程度上,减少系统中的错误数量变得指数级困难的,任何项目都有有限的资源。因此,能够缓解这种紧张关系的方法是有益的。

B. CPS模糊测试的挑战

如果黑客使用模糊测试来破坏系统,为什么不在生产前的测试中部署同样的技术来提高网络安全的复原力。事实上,模糊测试是广受好评的微软安全开发生命周期(SDL)的一部分,并被列入了J3061。然而,在J3061中并没有涵盖任何帮助制造商的资源,而且在将模糊测试应用于CPS领域的深入研究也很少。让模糊测试在汽车行业得到更广泛的应用,有哪些挑战?

1)车辆的CPS性质:对于现在部署在我们周围的CPS来说,计算命令和控制的结果是物理上的非计算操作。车辆驾驶员按下开关可以导致数字命令通过数据网络发送,该动作导致现实世界的输出,例如,一个灯被打开。因此,对被测系统(SUT)或被测设备(DUT)的监测增加了CPS的复杂性。然而,对于生产前的车辆设计阶段,这种CPS监测的复杂性可以借助于硬件在环和软件在环设备来模拟物理世界而得到缓解。

2)车辆产生的大量数据:随着更多的计算系统被纳入汽车,车辆内部不断产生的数据量只会增加。数据量问题在传统的IT安全中并不陌生。此外,在汽车行业中部署了不同的通信协议,另外还有一系列的数据类型和格式需要处理。车辆数据处理是另一个大数据问题。

3)不完整的知识:针对一个组件的已知规格和接口的功能测试是很容易确定的。然而,可能会存在为其他用途而开发的额外功能,如支持其他客户或用于组件测试。未文档化的应用编程接口(API)以及未经测试的代码路径可能会被利用。汽车工程师需要考虑到这些未知因素。

4)定义可测量度量:CPS的复杂性意味着没有两个类似的系统或类似的组件是可以比较的。这意味着测量模糊测试的有效性是困难的。在其他领域,模糊测试是以发现的错误数量的最终计数为导向的。然而,这只能是相对于同一系统上的其他运行,另外,由于模糊测试的随机性,比较只能是近似值。对于攻击者来说,发现的缺陷总数并不重要。他们所追求的是使他们有能力违反CIA三原则的那一个漏洞。而系统制造商则需要在系统交付前尽可能多地发现这些漏洞。然而,如果没有发现漏洞,这并不意味着不存在漏洞,这只是意味着测试没有触发任何东西。

鉴于上述动机和挑战,假设模糊测试对于提高车辆中联网ECU的安全性是有益的。如果是真的,那么在J3061中列出的车辆测试方法中加入模糊测试就是一个有效的论断。这里,一个定制的模糊测试器被用来对目标车辆进行模糊测试。这里使用一个自定义模糊器将模糊测试应用于目标车辆。通过这样做,我们可以学会哪些什么来应对这些挑战呢?模糊器需要如何调整?未来在汽车领域的模糊测试应用需要什么?虽然确实存在将模糊测试应用于汽车系统的经验性结果,但很少有发表的实验与可用的经验教训。

在这里,模糊测试器是通过CAN总线与车辆对接的,因此对CAN进行了简要介绍。


IV.汽车CAN总线

CAN总线是在20世纪80年代引入的,对于那些对比特级协议感兴趣的人来说,[23]有大量的可用的资源。总线上的每个节点(ECU)都可以启动数据传输,一次只传输一个节点。对于一个标准的CAN数据帧来说,11位的仲裁标识符(又称数据包标识符)允许最高优先级的信息在两到多个节点同时传输的情况下继续传输。一个标准的CAN数据包有多达八个字节(64位)的数据。节点中的CAN收发器芯片自动处理协议,向高层应用提供id、数据长度和数据字节。表二显示了从目标车辆上捕获的一些CAN数据包。按照今天的标准,标准CAN的传输速度并不高,被设计为支持高达1Mb/s。汽车中常用的传输速度是500kb/s。

图2 用于汽车测试的基于PC的模糊器

CAN的设计没有考虑到安全问题,因此很容易进入。与CAN接口的设备成本很低。CAN总线通常通过开放的车内诊断(OBD)端口暴露在车辆中,另外,只要车辆的线路可以接触到,就可以进行线切割。这些因素使得对CAN数据的操纵有了直接的研究。被破坏的ECU或中间人(MITM)攻击(例如连接到车辆的OBD连接器的售后设备)可以欺骗传输的信息,影响正常操作并威胁到车辆和乘客的安全。这种CAN操纵是针对车辆的网络攻击成功的一个要素。加强CAN的安全性是一个有用的措施,然而,尽管有几个方案可以为CAN增加加密,但没有一个方案符合在批量生产中部署的所有标准。


V.方法

表一中列出的可用的商业和混合许可模糊器是专门定制的,用于汽车系统。这里介绍的定制模糊器(图2)是为HORIBA MIRA有限公司开发的,是专门为处理CAN格式而编程的。该模糊器的设计很简单,与[15]相比,它的子组件数量较少,[15]执行时在Python和.NET技术之间跳转。

1)基于PC的模糊器:模糊测试软件是在一台连接到矢量车辆模拟器的计算机上开发的(图8)。矢量设备在工业上被广泛用于网络控制系统的设计、验证、HIL和SIL测试,包括基于CAN的车辆系统。车辆模拟器的使用简化了开发周期,因为在开发过程中不需要访问目标车辆。

用于模糊测试的软件是用C#计算机编程语言编写的。使用的集成开发环境(IDE)是Microsoft Visual Studio。软件模糊测试程序的主要功能项目是用于命令和控制的用户界面(UI)屏幕、常规CAN数据传输的定时线程、模糊CAN消息的随机字节发生器、通信API处理模块和CAN总线流量监视器。

2)通过车辆数据总线或ECU接口连接到SUT或DUT:使用一个通用串行总线(USB)到CAN的硬件适配器来连接模糊器软件到CAN总线,这里使用的是PEAK- System生产的PCAN-USB产品。PCAN-USB设备有一个应用编程接口(API),可以通过C#语言访问该设备。

图3 配置CAN模糊器的用户界面

USB CAN适配器需要9路D型插座,其接线符合CANopen规范(CiA303-1)2。两根CAN通信线被称为CAN High和CAN Low,CAN High连接到9针连接器的针脚7,CAN Low连接到针脚2(一个相同的插座用于连接到模拟器硬件)。

模糊器是通过其用户界面进行配置的,提供对注入到SUT或DUT(通过CAN总线)的数据的控制,图3。通过用户界面,模糊器可以被编程,以产生一个单一信息中的一个位,到每个信息中的每个位。由于CAN数据流的组合爆炸问题,这个功能很重要。一个具有11位id和一个字节有效载荷的标准CAN数据包有50万个数据包组合(219)。在1ms的传输频率下(目前这个模糊器的最小值),传输所有的组合需要8分钟以上。再加上一个数据字节,所有组合的传输时间为1.5天。除此之外,进一步增加数据长度是不切实际的,因此需要有针对性地进行模糊处理(例如,通过在CAN总线上监测到的已知消息ID进行模糊处理,或者通过设计来通知)。

一旦配置好,模糊器就会针对SUT或DUT执行,发送随机的CAN数据。它监视目标系统,记录对注入的信息的反应并采取行动。


VI.结果与分析

目标车辆使用标准的CAN数据包(11位ID)。可供模糊处理的数据包参数(ID、数据长度、有效载荷字节)见表三。根据模糊器中定义的参数,生成随机的CAN数据包见表四。

该模糊器分析了CAN数据,以便进行数据完整性检查。图4显示了每个字节位置的平均数据字节值,是从目标车辆的网络中捕获的100,000个CAN数据包计算出来的。它显示了一个非线性分布的八位数值。相比之下,图5显示了对由模糊器生成的66144个CAN数据包的相同计算结果。该线性分布,即所有消息中所有字节的总体平均值为127,这证明了模糊器正确地生成了字节值的均匀分布。

来自模糊器的随机CAN数据包的影响可以在矢量模拟器中进行测量。正常的车辆信号如图6所示。图7,在比图6更短的时间内被捕获,说明了随机数据包对信号的影响。

当模糊器运行并注入CAN数据包时,模拟器的反应很不稳定。这是由畸形的CAN数据所引起的信号的快速变化造成的。在图8中,模拟的车辆显示了一个负的发动机转速,这表明车辆模拟处理物理上无效值的方式与处理物理上合理的值相同。

一旦模糊测试软件投入使用,就可以用来对付物理目标,即车辆和车辆部件。以前的汽车黑客研究表明,对车辆的永久性破坏是可能的,例如,使ECU失效(制动)。因此,在对目标车辆进行测试之前,对目标车辆上使用的现有仪表盘进行了模糊处理。

图4 从100000条捕获的车辆CAN报文中每个数据字节位置的平均值

图5 来自66144个随机生成的CAN报文的每个数据字节位置的平均值

图6 模拟车辆信号

图7 模糊化对信号的影响

图8 通过模糊处理在车辆模拟器上显示不适当的值

图9 因模糊而导致的车辆部件崩溃

对着仪表盘运行模糊器,立即导致故障指示灯(MIL)亮起、警告声和不稳定的仪表针。此外,一个数字显示器开始有规律地显示崩溃这个词。循环供电给集束器,消除了任何变得亮起的MIL。不幸的是,碰撞信息不会清除。

该组件的损坏要求重新评估对目标车辆使用模糊器的情况,这是一种共享资源,如果被损坏会产生维修费用。因此,该实验仅限于检查模糊器是否对目标车辆产生影响。与其在整个CAN消息空间中运行模糊器,不如只对一小部分消息进行模糊处理。这些信息的ID是以前在车辆的CAN总线上观察到的正常操作,例如,已知的影响仪表盘表针的信息。使用OBD电缆(通过USB到CAN适配器)将模糊器连接到车辆上,模糊信息被送入空转的目标车辆。目标车辆有两条CAN总线,模糊器在两条总线上都进行了测试。该车表现出与集群测试类似的行为, 即各种MIL灯的点亮、仪表区的警告声、仪表读数的变化、车辆中央控制台的错误信息以及发动机怠速转速的不稳定。一旦发现模糊处理有明显的影响,就会停止,以防止可能的损害,如图9所示。为了防止对焦油车部件的损害,对模糊器的进一步测试是针对台式硬件配置进行的。基于工作台的配置是为了代表互联汽车越来越普遍的特征,即通过应用程序控制车辆功能,见图10。

一个CAN总线目标是由带有CAN接口的Arduino单板计算机(SBC)构建的。每个SBC在网络上充当一个ECU。CAN总线上的信息是在目标车辆的CAN总线上传输的信息的一个小子集。其中一个ECU作为车身控制模块(BCM),其发光二极管(LED)代表车辆的锁定状态(off代表锁定,on代表解锁),见图11。

图12显示了复制功能的图示。外部手机应用程序向车辆信息娱乐系统ECU(又称车头装置)发送解锁命令。 

图10 通过制造商的智能手机应用程序控制车辆,可从应用程序商店获得

图11 连接三个作为ECU的单板计算机的CAN总线

这是一个安全的连接(或应该是)。信息娱乐装置通过车辆的CAN总线传输解锁命令。模糊器是作为一个恶意的单元连接到车辆网络(通过OBD端口或一个被破坏的ECU)。当模糊器运行时,它不知道激活锁的CAN信息。

在这个实验中,一个PC应用作为智能手机应用,图13,作为信息娱乐系统ECU的代理发送锁定和解锁命令。这导致LED灯的开启和关闭,表明在锁定和解锁车门方面的正常系统操作。用模糊器,见图3,在随机产生的CAN数据几分钟后,解锁(或锁定)功能被激活。为了帮助检测解锁状态,测试平台被增强以传送解锁确认的CAN消息。对于真正的车辆还需要另一种检测机制,例如门锁上的传感器。

图12 远程车辆解锁功能

图13 PC车辆锁定/解锁应用程序

模糊器目前的最大信息传输率为每毫秒一条信息。在这个速率下,根据12次运行的小样本,引起解锁反应的平均时间是431秒,见表五。解锁代码测试的是一个具有特定ID的信息中第一字节位置的特定字节值。当代码被修改为包括测试数据包的长度时,平均时间增加到1959秒。代码的这一简单变化大大增加了模糊器找到正确解锁信息的时间。如果改变为检查两个字节的值,时间的增加会更多。


VII.探讨

事实证明,这些实验已经被证明是有用的,可以从少数现有的工作中收集出几条信息。

关于在车辆CAN总线上应用模糊测试。实验结果证实了之前关于车辆模糊测试的声明,即:

-模糊测试可用于对车辆信息进行反向工程。

-破坏车辆的通信网络并非难事。

-模糊测试可以作为网络攻击的一种形式。

-网络安全测试车辆及其部件可导致车辆部件损坏。

由于模糊测试对运行中的车辆和模拟器有不利的影响,它表明车辆系统需要额外的逻辑来忽略无意义的CAN消息值,以及这些值的序列。因此,很明显,CAN总线在互联汽车中运行时需要额外的工程考虑。因此,保护CAN总线和车辆部件不受外部网络攻击,现在已经成为互联汽车系统设计的一个功能要求。对于这样的系统,这些实验的目的是展示可以用来开始将模糊测试纳入测试制度的方法。

事实也表明,模糊测试可以用来验证系统是否符合CIA三原则。模糊测试能够在不事先了解系统设计的情况下激活安全功能(保密性),能够改变仪器上显示的数值(完整性),并破坏组件和车辆的运行(可用性)。这意味着,对于互联车辆来说,设计功能以正确隔离安全问题必须是一个考虑因素。事实上,在较新的车辆中使用网关ECU表明制造商正在应对这一问题。此外,对设计的简单修改可以提高安全性。在这里,通过改变CAN信息来激活解锁,因此,增加了通过随机模糊测试发现该功能的时间。

所开发的软件将被用于进一步研究汽车系统的模糊测试,并加以扩展。这是一个有价值的研究领域,因为在汽车系统上运行这种测试的定量数据很少。该工作可以扩展的其他方式包括:

-利用模糊测试来确定保护措施的有效性,例如车辆防火墙和网关,或对ECU软件的补充,以减轻网络攻击。

-研究在位级对模糊CAN协议控制位(数据链路层)的数据包的操作。

-将这些技术应用于灵活数据速率(FD)版本的CAN。

-对车辆工程工具(如CAN接口设备)的API进行模糊处理,以确保其弹性。例如,对研究中使用的PEAK USB CAN适配器的API进行模糊处理。

-使用视频处理软件,例如OpenCV,来监测被模糊测试的车辆和设备的网络物理行为。

参考文献:
[1]C. Valasek and C. Miller, “Remote Exploitation of an Unaltered Pas- senger Vehicle,” Black Hat USA, vol. 2015, pp. 1–91, 2015.
[2]SAE International, “J3061 - Cybersecurity Guidebook for Cyber- Physical Vehicle Systems,” Warrendale, 2016.
[3]HM Government, “The Key Principles of Cyber Security for Connected and Automated Vehicles,” HM Government, Tech. Rep., 2017.
[4]N. Rathaus and G. Evron, Open Source Fuzzing Tools. Burlington: Syngress, 2007.
[5]P. Godefroid, M. Y. Levin, and D. Molnar, “SAGE: Whitebox Fuzzing  for Security Testing,” Queue, vol. 10, no. 1, pp.  20:20—-20:27,  jan 2012. [Online]. Available:  http://doi.acm.org/10.1145/2090147.2094081
[6]C. Smith, The Car Hacker’s Handbook : A Guide for the Penetration Tester. No Starch Press, 2016.
[7]H. Altinger, F. Wotawa, and M.  Schurius,  “Testing  methods  used  in the automotive industry: results from a survey,” in Proceedings of the 2014 Workshop on Joining AcadeMiA and Industry  Contributions  to Test Automation and Model-Based Testing - JAMAICA 2014. San Jose, California: ACM, 2014, pp. 1–6.
[8]I. Foster, A. Prudhomme, K. Koscher, and S. Savage, “Fast and Vulner- able: A Story of Telematic Failures,” in Proceedings of the USENIX Workshop On Offensive Technologies (WOOT). Washington, D.C.: USENIX, 2015.
[9]S. Woo, H. J. Jo,  and  D.  H.  Lee,  “A  Practical  Wireless  Attack  on the Connected Car and Security Protocol for In-Vehicle CAN,” IEEE Transactions on Intelligent Transportation Systems, vol. 16, no. 2, pp. 993–1006, 2015.
[10]T. Hoppe and J. Dittman, “Sniffing/replay attacks on can buses: A simulated attack on the electric window lift classified using an adapted cert taxonomy,” in Proceedings of the 2nd workshop on embedded systems security (WESS), 2007, pp. 1–6.
[11]BBC, “Hack attacks mounted on car control systems,” p. 1, 2010. [Online]. Available: http://www.bbc.co.uk/news/10119492
[12]K. Koscher, A. Czeskis, F. Roesner, S. Patel, T. Kohno, S. Checkoway,D. McCoy, B. Kantor, D. Anderson, H. Shacham, and S. Savage, “Experimental Security Analysis of a Modern Automobile,” in Security and Privacy (SP), 2010 IEEE Symposium on, 2010, pp. 447–462.
[13]S. Bayer and A. Ptok, “Don’t Fuss about Fuzzing: Fuzzing In-Vehicular Networks,” in escar Europe 2015. Cologne: isits AG  International School of IT Security AG, 2015, pp. 1–10.
[14]E. T. Barr, M. Harman, P. McMinn, M. Shahbaz, and S.  Yoo, “The Oracle Problem in Software Testing: A Survey,” IEEE Transactions on Software Engineering, vol. 41, no. 5, pp. 507–525, 5 2015.
[15]P.  Lapczynski,  H.  Heinemann,  T.  Scho¨neberger,  and  E.  Metzker,  “Au- tomatically Generating Fuzz Tests from Automotive Communication Databases,” isits AG International School of IT Security, Detroit, Tech. Rep., jun 2017.
[16]R. Nishimura, R. Kurachi, K. Ito, T. Miyasaka, M. Yamamoto, and M. Mishima, “Implementation of the CAN-FD protocol in the fuzzing tool beSTORM,” in 2016 IEEE International Conference on Vehicular Electronics and Safety (ICVES), jul 2016, pp. 1–6.
[17]D. K. Oka, A. Yvard, S. Bayer, and T. Kreuzinger, “Enabling Cyber Security Testing of Automotive ECUs by Adding Monitoring Capabil- ities,” in Embedded Security in Cars Conference, 15th escar Europe. Berlin: isits AG, 2016, pp. 1–13.
[18]ISO,  “ISO  26262-1:2011   Road   vehicles   -   Functional   safety   -  Part 1: Vocabulary,” Geneva, p. 23, 2011. [Online]. Available: https://www.iso.org/standard/43464.html
[19]R. J. Anderson, Security Engineering: A Guide to Building Dependable Distributed Systems, 2nd ed. Indianapolis: Wiley Publishing Inc., 2008.
[20]B. G. Kolkhorst and A. J. Macina, “Developing error-free software,” IEEE Aerospace and Electronic Systems Magazine, vol. 3, no. 11, pp. 25–31, nov 1988.
[21]T. Menzies, Z. Milton, B. Turhan, B. Cukic, Y. Jiang, and
A.Bener, “Defect prediction from static  code  features:  current  results, limitations, new approaches,” Automated Software Engineering, vol. 17, no. 4, pp. 375–407, dec 2010. [Online]. Available: https://doi.org/10.1007/s10515-010-0069-5
[22]M. Meng and W. Khoo, “An  Analysis  of  Secure  Software Development Lifecycle from an Automotive Development Perspective,” SAE, Warrendale, Tech.Rep., 2016. [Online]. Available: https://doi.org/10.4271/2016-01-0040
[23]Bosch, “CAN Specification Version 2.0,” Robert Bosch GmbH, Tech. Rep., 1991.
[24]N. Nowdehi, A. Lautenbach, and T. Olovsson, “In-vehicle can message authentication: An evaluation based on industrial criteria,” in 2017 IEEE 86th Vehicular Technology Conference (VTC-Fall), Sept 2017, pp. 1–7.
[25]S. Checkoway, D. McCoy, B. Kantor, D. Anderson, H. Shacham,
S. Savage, K. Koscher, A. Czeskis, F. Roesner, T. Kohno et al., “Comprehensive experimental analyses of automotive attack surfaces.”  in 20th USENIX Security Symposium. San Francisco, 2011.
[26]K. Strandberg, T. Olovsson, and E. Jonsson, “Securing the connected  car: A security-enhancement methodology,” IEEE Vehicular Technology Magazine, vol. 13, no. 1, pp. 56–65, March 2018.
[27]D. S. Fowler, M. Cheah, S. A. Shaikh, and J. Bryans, “Towards A Testbed for Automotive Cybersecurity,” in Software Testing, Verification, and Validation, ICST, International Conference on. Tokyo: IEEE, 2017.
END

推荐阅读

kali渗透测试环境搭建

Web安全|docker环境搭建(2)

Web安全攻防实战零基础速成培训班

强烈推荐Google系列Android机型(Android逆向的最佳机型)

APP逆向分析/渗透测试/安全检测/隐私合规如何选择手机机型或系统

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存