【无人驾驶系列九】无人驾驶系统安全

目前针对无人车攻击的方法有许多,如何防御这些攻击以保证无人车的安全是个重要的课题。本文是无人驾驶技术系列的第九篇,详细介绍针对无人车传感器、操作系统、控制系统、车联网的攻击手段以及防御方法。

针对无人驾驶的安全威胁

对于无人驾驶系统来说,安全性至关重要。任何无人车如果达不到安全要求就上路是极其危险的。目前,针对无人车攻击的方法五花八门,渗透到无人驾驶系统的每个层次,包括传感器、操作系统、控制系统、车联网通信系统等。首先,针对传感器的攻击不需要进入无人驾驶系统内部,这种外部攻击法技术门槛相当低,既简单又直接。 第二,如果进入无人驾驶操作系统,黑客可以造成系统崩溃导致停车,也可以窃取车辆敏感信息。第三,如果进入无人驾驶控制系统,黑客可以直接操控机械部件,劫持无人车去伤人,是极其危险的。第四,车联网连接不同的无人车,以及中央云平台系统,劫持车联网通信系统也可以造成无人车间的沟通混乱。本文将详细介绍每种攻击手段,并且讨论相应的防御方法。

无人驾驶传感器的安全

由于传感器处于整个无人驾驶计算的最前端,最直接攻击无人车的方法就是攻击传感器。这种外部攻击法并不需要入侵到无人驾驶系统内部,使得入侵的技术门槛相当低。正是因为入侵的门槛低,我们需要在传感器做大量的工作来保证其安全。如图1所示,对各种传感器,我们都可以轻易地攻击与误导。无人驾驶系列文章《GPS及惯性传感器在无人驾驶中的应用》(《程序员》2016年9月)提到可以使用惯性传感器IMU辅助无人驾驶定位,但是IMU对磁场很敏感,如果使用强磁场干扰IMU,就有可能影响IMU的测量。对于GPS,如果在无人车附近设置大功率假GPS信号,就可以覆盖原来的真GPS信号,从而误导无人车定位。通过两种简单攻击方法的结合,GPS与IMU的定位系统会轻易被攻破。除了GPS与IMU外,通常我们也可以使用轮测距技术辅助无人车定位。轮测距是通过测量轮子的转速乘与轮子的周长进行测距,如果黑客破坏了轮子,这个定位辅助技术也会受影响。

无人驾驶系列文章《光学雷达(LiDAR)在无人驾驶技术中的应用》(《程序员》2016年4月)提到激光雷达是目前无人驾驶最主要的传感器,而无人车也依赖于激光雷达数据与高精地图的匹配进行定位。但激光雷达也可以轻易地被干扰。首先激光雷达是通过测量激光反射时间来计算深度的。如果在无人车周围放置强反光物,比如镜子,那么激光雷达的测量就会被干扰,返回错误信息。除此之外, 如果黑客使用激光照射激光雷达,测量也会受干扰,会分不清哪些是自身发出的信号,哪些是外部激光的信号。另外,无人车会不断下载更新的高精地图,如果黑客把下载的地图掉包,也会造成定位失效。

图片描述
图1 针对传感器的攻击

无人驾驶系列文章《基于计算机视觉的无人驾驶感知系统》(《程序员》2016年7月)提到计算机视觉可以辅助无人车完成许多感知的任务,比如交通灯识别、行人识别和车辆行驶轨迹跟踪等等。在交通灯识别的场景中,无人车上的摄像机如果检测到红灯,就会停下来。如果检测到行人,也会停下以免发生意外。黑客可以轻易地在路上放置假的红绿灯以及假的行人,迫使无人车停车并对其进行攻击。

既然每个传感器都可以轻易被攻击,如何保证无人车安全?对此,需要使用多传感器融合技术互相纠正。攻击单个传感器很容易,但是如果同时攻击所有传感器难度相当大。当无人车发现不同传感器的数据相互间不一致,就知道自己可能正在被攻击。例如,无人车检查到交通灯,但是高精地图在此处并未标注有交通灯,那么就很可能是被攻击了。又例如GPS系统与LiDAR系统定位的位置极不一致,无人车也很可能是被攻击了。

无人驾驶操作系统安全

针对传感器的攻击是外部攻击,不需要进入无人驾驶系统。第二种攻击方式是入侵到无人驾驶操作系统,劫持其中一个节点并对其进行攻击。在无人驾驶系列文章《基于ROS的无人驾驶系统》(《程序员》2016年5月)中提到,目前的无人驾驶操作系统基本是基于ROS的框架实现。但是ROS本身安全性有一定问题,总结有以下两种攻击方法:第一,其中一个ROS的节点被劫持,然后不断地进行分配内存,导致其系统内存消耗殆尽,造成系统OOM而开始关闭不同的ROS节点进程,造成整个无人驾驶系统崩溃。第二,ROS的topic或service被劫持, 导致ROS节点之间传递的信息被伪造,从而导致无人驾驶系统的异常行为。造成第一个问题的原因是ROS Node本身是一个进程,可以无节制分配资源导致奔溃,另外的原因是ROS Node可以访问磁盘以及网络资源,并无很好的隔离机制。为了解决这个问题,可以使用Linax容器技术(LXC)来管理每一个ROS节点进程。简单来说,LXC提供轻量级的虚拟化,以便隔离进程和资源,而且不需要提供指令解释机制以及全虚拟化等其他复杂功能,相当于C++中的NameSpace。LXC有效地将由单个操作系统管理的资源划分到孤立的群组中,以更好地在孤立的群组之间平衡有冲突的资源使用需求。对于无人驾驶场景来说,LXC最大的好处是性能损耗小。我们测试发现,在运行时LXC只造成了5%左右的CPU损耗。除了资源限制外,LXC也提供了沙盒支持,使得系统可以限制ROS节点进程的权限。为避免可能有危险性的ROS节点进程破坏其他的ROS节点进程运行,沙盒技术可以限制其进程访问磁盘、内存以及网络资源。

至于第二个问题,主要原因是通信的信息并没有被加密,以至于攻击者可以轻易得知通信内容。目前业界有不少对ROS节点间通信的加密尝试,比如使用DES加密算法。在通信的信息量十分小的时候,加密与否对性能影响不大。但随着信息量变大,加密时间相对信息量成几何级增长。另外,由于ROS通信系统的设计缺陷,加密时间也与接收信息的节点数量有直接关系。当接受信息的节点数量增长时,加密时间也随之增长。无人驾驶系列文章《基于ROS的无人驾驶系统》提出了几个改进ROS通信系统的机制,在这些机制中,加密对性能影响将大大减少。

无人驾驶控制系统安全

如图3所示,车辆的CAN总线连接着车内的所有机械以及电子控制部件,是车辆的中枢神经。CAN总线具有布线简单、典型总线型结构、可最大限度节约布线与维护成本、稳定可靠、实时、抗干扰能力强、传输距离远等特点。由于CAN总线本身只定义ISO/OSI模型中的第一层(物理层)和第二层(数据链路层),通常情况下,CAN总线网络都是独立网络,所以没有网络层。在实际使用中,用户还需要自己定义应用层的协议,因此在CAN总线的发展过程中出现了各种版本的CAN应用层协议。CAN总线采用差分信号传输,通常情况下只需要两根信号线(CAN-H和CAN-L)就可以进行正常的通信。在干扰比较强的场合,还需要用到屏蔽地即CAN-G(主要功能是屏蔽干扰信号)。CAN总线上任意节点均可在任意时刻主动的向其它节点发起通信,节点没有主从之分,但在同一时刻优先级高的节点能获得总线的使用权。
图片描述
图2 无人车操作系统安全

图片描述
图3 CAN总线安全

如果CAN被劫持,那么黑客将为所欲为,造成极其严重的后果。一般来说,要进入CAN系统是极其困难的。但是一般车辆的娱乐系统以及检修系统的OBD-II端口都连接到CAN总线,这就给了黑客进入CAN的机会。攻击的方式包括以下几点:

  •     OBD-II入侵: OBD-II端口主要用于检测车辆状态,通常在车辆进行检修时,技术人员会使用每个车厂开发的检测软件接入OBD-II端口并对汽车进行检测。由于OBD-II连接到CAN总线,只要黑客取得这些检测软件,包括 Ford的NGS、Nissan的Consult II、Toyota的Diagnostic Tester等,便能轻易截取车辆信息。
  •     电动车充电器入侵:最近电动车越来越普及,充电设备成为电动车生态必不可少的核心部件。由于电动车的充电装置在充电时会与外部充电桩通信,而且电动车的充电装置会连接CAN总线,这就给了黑客们通过外部充电桩入侵CAN系统的机会。
  •     车载CD机入侵:曾经有攻击的案例是把攻击代码编码到音乐CD中,当用户播放CD时,恶意攻击代码便会通过CD播放机侵入CAN总线,从而可以取得总线控制以及盗取车辆核心信息。
  •     蓝牙入侵:另一个攻击入口是蓝牙。如今蓝牙连接手机与汽车通讯以及娱乐系统已经成为标配。由于用户可以通过蓝牙给CAN发送信息以及从CAN读取信息,这也给黑客们攻击的窗口。除了取得车主手机的控制权,由于蓝牙的有效范围是10米,黑客们也可以使用蓝牙进行远程攻击。
  •     TPMS入侵: TPMS是车轮压力管理系统,也有黑客对TPMS展开攻击。在这种攻击方法中,黑客先把攻击代码放置在车辆TPMS ECU中,然后当TPMS检测到某个胎压值的时候,恶意代码便会被激活,从而对车辆进行攻击。

一个通用的解决方法是对ECU接收的信息进行加密验证,以保证信息是由可信的MCU,而不是由黑客发出。使用加密验证,我们可以选择对称或者非对称密码。对称密码的计算量小但是需要通信双方预先知道密码。非对称密码无需预先知道密码,但是计算量大。由于大部分车用ECU计算能力与内存有限,现在通用做法是使用对称密码加密,然后密钥在生产过程中被写入ECU。这样的后果是有许多ECU复用同一个密钥,当一个ECU密钥被破解后,同批的ECU都会有风险。为了解决这个问题,学术界和业界也提出了几种解决方案:

  •     TLS安全协议沿用非对称密码的算法对通信双方进行验证。
  •     Kerberos是一个通用的基于对称密码算法的验证平台。
  •     TESLA安全协议(注意:这个TESLA安全协议与Tesla汽车没有关系)提出了使用对称密码机制去模拟非对称密码的做法,从而达到既安全又能降低计算量的目的。
  •     LASAN安全协议使用两步验证的机制实时让通信双方交换密钥,然后使用对称密码的算法对信息进行验证。

车联网通讯系统的安全性

当无人车上路后,它会成为车联网的一部分。V2X是车联网通信机制的总称。可以说,V2X是泛指各种车辆通讯的情景,包括V2V车车通讯、V2I车路通讯、V2P车与路人通讯等。通过V2X车辆可以获得实时路况、道路、行人等一系列交通信息,从而带来远距离环境信号。比如V2V,最普遍的应用场景是在城市街道、高速公路,车辆之间可以相互通信,发送数据,实现信息的共享。这样的数据包括:车辆的时速、相对位置、刹车、直行还是左拐等所有与行驶安全的数据提前提供给周围的车辆,使得周围车辆都能够预判其他车辆的驾驶行为,从而实现主动的安全策略。V2X安全防护是自动驾驶必要技术和智慧交通的重要一环,接下来我们讨论V2X的潜在安全风险及解决方案。

图片描述
图4 ECU安全加密系统

确保V2X通信安全的系统要满足以下两个基本条件:第一,确认消息来自合法的发送设备,这个需要通过验证安全证书来保证。第二,确认消息传输过程中没有被修改,这个需要接受信息后计算信息的完整性。为了实现V2X的安全,欧盟发起了V2X安全研究项目PRESERVE并在项目中提出了符合V2X安全标准的硬件、软件,以及安全证书架构。

  •     硬件:在每个车辆中存储了大量密钥,如果使用普通的Flash与RAM,密钥会被轻易盗取。另外,使用加密解密技术会对计算资源消耗极大。为了解决这些问题,PRESEVER提出了设计安全存储硬件,以及使用ASIC硬件加速加解密。

图片描述
图5 车联网V2X系统

  •     软件:在安全硬件上,PRESEVER提供了一整套开源软件栈提供安全通信。这套软件栈提供了加密解密的软件库、电子证书认证库、与受信任的证书颁发机构的安全通信库等。
  •     安全证书:为了确保信息来源于可信设备,可以使用受信任的证书颁发机构来提供安全证书与密钥。当汽车A向汽车B放送信息时,汽车A的发送器会在信息上添加电子签名,并用密钥对信息进行加密。汽车B接受信息时,会首先对信息的电子证书进行认证,确认信息是由汽车A发送,然后使用公钥对信息进行解密,并对信息的完整性进行验证。

图片描述
图6 PRESERVE系统架构

安全模型校验方法

为了保证无人驾驶系统的安全性,我们需要从纵向对系统的每个层面进行校验。这些层面包括代码、电子控制单元(ECU)、控制算法、车内及车外网、自动车整体与物理环境结合的网宇实体系统,甚至需要多部车辆互相通讯的车联网。越往上层系统的复杂度越大,校验也越困难。所以一般在对上层系统的分析会基于下层的分析结果做抽象化处理。比如在分析车内网的时候,对与网络链接的电子控制单元一般只考虑通讯接口的模型,而不会考虑电子控制单元内的具体功能及软件。在对每个层面在做安全分析时,也需要考虑各种不同的威胁模型和攻击向量。比如说,代码的安全校验除了需要考虑缓冲区溢出,还要考虑其他模块通过利用API来侵入,或者是第三方软件里载有木马的威胁。在对车内网的分析时,要考虑在某个电子控制单元被黑客控制下可能出现的各种情况,包括阻断服务攻击(Denial of Service Attack),修改通讯件的内容,伪造通讯件的来源等。由于无人驾驶系统对处理速度和容量的要求远远高于传统车辆控制系统,一部分单核的电子控制单元在不久的将来会被多核芯片或GPU取代。每个新的电子控制单元将会支持多个功能或多个功能的部分实现,而这些功能会通过虚拟机来管理硬件资源分配。从安全的角度来说,就需要对虚拟机管理器进行分析,比如虚拟机与虚拟机之间的通讯(intra-VM communication)保证不被第三方干扰或窃听。无人车加入了很多新的自动行驶功能,比如最简单的自动刹车,对于这些功能的控制算法,验证时也需要全面地考虑前文所提到的一系列威胁,包括某个传感器的信息被恶意修改,通讯渠道被堵所引起的信息滞后等等。因为无人车需要强大的AI系统做支持,对这些AI系统的不同攻击方式也在校验的考虑范围内。最近有研究指出,深度学习系统(特别应用在图像识别上)也很容易被攻击。比如修改一张图像中的几个像素就可能使识别结果大相径庭。这个隐患大大增加了系统被黑客攻破的可能性。在车联网的层面上,常见的安全问题有通讯信息被篡改,被黑客控制的车辆故意提供假信息或伪造身份,阻断服务攻击,女巫攻击(sybil attack:单辆车通过控制多个身份标识来对网络整体进行攻击),以及盗取其他车主的私密信息(比如所在位置)。

对于这些安全问题及攻击向量的分析涉及的技术非常广。本文重点介绍关于车内网(比如前面提到的CAN)和控制系统的安全模型和验证。现有的车内网安全协议一般建立在一些基本的加密单元上,比如对称密钥加密和非对称密钥加密。一般初始身份鉴别时需要用非对程密钥加密,而之后的通讯就可以用相对更快的对称密钥加密。根据不同的安全等级需求,密钥的长度会不一样。长的密钥会更安全,但也会增加加密和解密的时间,因此影响到控制系统的性能。另外,长的密钥会增加通信的负担。不管是CAN还是TDMA类的车内网协议,这些附加的安全信息都可能导致通讯超时(结果可能是来不及刹车)。所以在安全校验的同时也必须考虑增加安全机制所产生的延时。最后,密钥的分发和管理也至关重要。这是当前的一个技术难点,还没有特别好的解决方案。对于协议本身的验证方法有几种。一般来说,首先要校验协议的数学模型。最近提出的LASAN就是先用形式化验证工具Scyther来证明协议的安全性,然后做仿真来测试性能。对于控制系统,分析时是会侧重考虑攻击对数据所产生的影响(比如说延时,丢失或假数据),然后对相应的安全方案(比如传感器数据混合处理或状态估计)做数学证明来达到校验的目的。类似的方法也被应用在验证一些车联网的功能上,像合作的可变巡航控制。总体来说,无人车的安全问题至关重要,车辆如果被黑客攻击或控制会危及生命。但是,不管从技术还是标准化的角度看,现阶段对于无人车安全问题的校验尚未成熟,还需要学术界和工业界的深入研究与大力开发。

作者简介:

    刘少山,PerceptIn联合创始人。加州大学欧文分校计算机博士,研究方向智能 感知计算、系统软件、体系结构与异构计算。现在PerceptIn主要专注 于SLAM技术及其在智能硬件上的实现与优化。
    李文超,美国波士顿大学助理教授。加州大学伯克利分校电子工程与计算机科学博士。研究方向包括自动化设计与检测,可靠及容错计算机系统,计算证明法,网宇实体系统。
    唐洁,华南理工大学计算机科学与工程学院副教授。主要从事面向无人驾驶和机器人的大数据计算与存储平台、面向人工智能的计算体系架构、面向机器视觉的嵌入式系统研究。

你可能感兴趣的:(资源整合,无人驾驶,无人驾驶安全)