如何防御无人驾驶系统安全问题？

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

针对无人驾驶的安全威胁

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

无人驾驶传感器的安全

由于传感器处于整个无人驾驶计算的最前端，最直接攻击无人车的方法就是攻击传感器。这种外部攻击法并不需要入侵到无人驾驶系统内部，使得入侵的技术门槛相当低。正是因为入侵的门槛低，我们需要在传感器做大量的工作来保证其安全。

如图所示，对各种传感器，我们都可以轻易地攻击与误导。对于GPS，如果在无人车附近设置大功率假GPS信号，就可以覆盖原来的真GPS信号，从而误导无人车定位。通过两种简单攻击方法的结合，GPS与IMU的定位系统会轻易被攻破。除了GPS与IMU外，通常我们也可以使用轮测距技术辅助无人车定位。轮测距是通过测量轮子的转速乘与轮子的周长进行测距，如果黑客破坏了轮子，这个定位辅助技术也会受影响。

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

计算机视觉可以辅助无人车完成许多感知的任务，比如交通灯识别、行人识别和车辆行驶轨迹跟踪等等。在交通灯识别的场景中，无人车上的摄像机如果检测到红灯，就会停下来。如果检测到行人，也会停下以免发生意外。黑客可以轻易地在路上放置假的红绿灯以及假的行人，迫使无人车停车并对其进行攻击。

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

无人驾驶操作系统安全

针对传感器的攻击是外部攻击，不需要进入无人驾驶系统。第二种攻击方式是入侵到无人驾驶操作系统，劫持其中一个节点并对其进行攻击。目前的无人驾驶操作系统基本是基于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通信系统的设计缺陷，加密时间也与接收信息的节点数量有直接关系。当接受信息的节点数量增长时，加密时间也随之增长。

无人驾驶控制系统安全

CAN总线安全

车辆的CAN总线连接着车内的所有机械以及电子控制部件，是车辆的中枢神经。CAN总线具有布线简单、典型总线型结构、可最大限度节约布线与维护成本、稳定可靠、实时、抗干扰能力强、传输距离远等特点。由于CAN总线本身只定义ISO/OSI模型中的第一层（物理层）和第二层（数据链路层），通常情况下，CAN总线网络都是独立网络，所以没有网络层。

在实际使用中，用户还需要自己定义应用层的协议，因此在CAN总线的发展过程中出现了各种版本的CAN应用层协议。CAN总线采用差分信号传输，通常情况下只需要两根信号线（CAN-H和CAN-L）就可以进行正常的通信。在干扰比较强的场合，还需要用到屏蔽地即CAN-G（主要功能是屏蔽干扰信号）。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的潜在安全风险及解决方案。

ECU安全加密系统

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

车联网V2X系统

软件：在安全硬件上，PRESEVER提供了一整套开源软件栈提供安全通信。这套软件栈提供了加密解密的软件库、电子证书认证库、与受信任的证书颁发机构的安全通信库等。

安全证书：为了确保信息来源于可信设备，可以使用受信任的证书颁发机构来提供安全证书与密钥。当汽车A向汽车B放送信息时，汽车A的发送器会在信息上添加电子签名，并用密钥对信息进行加密。汽车B接受信息时，会首先对信息的电子证书进行认证，确认信息是由汽车A发送，然后使用公钥对信息进行解密，并对信息的完整性进行验证。

PRESERVE系统架构

安全模型校验方法

为了保证无人驾驶系统的安全性，我们需要从纵向对系统的每个层面进行校验。这些层面包括代码、电子控制单元（ECU）、控制算法、车内及车外网、自动车整体与物理环境结合的网宇实体系统，甚至需要多部车辆互相通讯的车联网。越往上层系统的复杂度越大，校验也越困难。所以一般在对上层系统的分析会基于下层的分析结果做抽象化处理。比如在分析车内网的时候，对与网络链接的电子控制单元一般只考虑通讯接口的模型，而不会考虑电子控制单元内的具体功能及软件。

对于这些安全问题及攻击向量的分析涉及的技术非常广。本文重点介绍关于车内网（比如前面提到的CAN）和控制系统的安全模型和验证。现有的车内网安全协议一般建立在一些基本的加密单元上，比如对称密钥加密和非对称密钥加密。一般初始身份鉴别时需要用非对程密钥加密，而之后的通讯就可以用相对更快的对称密钥加密。根据不同的安全等级需求，密钥的长度会不一样。长的密钥会更安全，但也会增加加密和解密的时间，因此影响到控制系统的性能。另外，长的密钥会增加通信的负担。不管是CAN还是TDMA类的车内网协议，这些附加的安全信息都可能导致通讯超时（结果可能是来不及刹车）。所以在安全校验的同时也必须考虑增加安全机制所产生的延时。最后，密钥的分发和管理也至关重要。这是当前的一个技术难点，还没有特别好的解决方案。

对于协议本身的验证方法有几种。一般来说，首先要校验协议的数学模型。最近提出的LASAN就是先用形式化验证工具Scyther来证明协议的安全性，然后做仿真来测试性能。对于控制系统，分析时是会侧重考虑攻击对数据所产生的影响（比如说延时，丢失或假数据），然后对相应的安全方案（比如传感器数据混合处理或状态估计）做数学证明来达到校验的目的。类似的方法也被应用在验证一些车联网的功能上，像合作的可变巡航控制。总体来说，无人车的安全问题至关重要，车辆如果被黑客攻击或控制会危及生命。但是，不管从技术还是标准化的角度看，现阶段对于无人车安全问题的校验尚未成熟，还需要学术界和工业界的深入研究与大力开发。