伴随着ADAS往高阶自动驾驶的演进,要实现更高阶的自动驾驶,车企需要更强大的算力来支撑越来越多新型传感器的融合应用。这就涉及在域控设计过程中纳入更多更大能力的芯片作为内置硬件模块。不可否认,从一块小小的芯片,到整车组装完毕,汽车的开发要求始终在动态变化中。在这其中,无论是功能安全还是信息安全都已经成为了汽车开发全生命周期的核心需求。也是其SoC必须考虑的因素,将信息安全和功能安全纳入汽车开发生命周期的全流程是必然的。
本文将十分详细的讲解信息安全在为整个汽车安全系统保障中如何做才能真正从细节上保证汽车安全。这些内容包括系统软件完整性保护、安全升级保护、密钥安全存储、数据加密、设备证书管理、安全信息采集、通信安全、应用防火墙、TLS双向认证、安全调试、代码安全、系统安全配置等多个方面。从整车的整个链路上对业务的关键控制流、数据链路、硬件覆盖、软件模块算法等几个大的方面进行一一拆解分析。设计一种多层次纵深防护的方案,抵御攻击,支撑整体信息安全方案的有效运行。
自动驾驶软件安全保护
对于自动驾驶系统而言,最重要的是建立对中央域控的安全纵深防护。这方面主要是为了确保控车安全,重点是防止黑客攻击,而恶意控车。因为任何环节的引导文件如果被篡改或恶意篡改,将会破坏系统完整性,威胁控车安全。为了防止出现这种情况,需要针对每个步骤进行检验,确保加载的程序是可信的。这一过程主要是针对域控软件而言,涉及如下几方面的保护机制:
1)软件安全导入:域控的启动首先是通过依次加载和执行一系列驱动程序,通过写入启动镜像的签名密钥信息的方式,在线托管服务加密,从而防止密钥泄露,确保打开安全启动。其中的密钥签名主要针对MCU、SOC这类域控核心固件信息。加载信息流程为:MCU加载器验证启动—>MCU应用程序验证启动—>SOC(CPU)OS验证启动——>SOC(NPU)验证启动。
2)软件完整性守护:需要保持域控软件完整性,防止攻击者篡改内部软件;
由于自动驾驶域控制器设备主要通过FOTA升级固件,SOTA升级软件,整个FOTA、SOTA过程也是最容易被植入恶意软件的过程。因此,对两种软件升级过程的完整性保护是整个软件完整性保护的重点。软件完整性保护主要是通过一定的比对方法(如MD5值验签)对运行软件包和在线升级软件包中的软件文件进行一致性检测和验签的过程。比如OTA软件包的验签过程主要是对升级文件的属性、MD5值进行文件列表存储,并适时的对升级文件采用数字证书系统上托管的秘钥进行文件签名。最后在该升级文件包中加入列表信息文件、签名文件、验签秘钥,这样就可以有效的防止软件包被篡改。通过这种文件校验的方式,在一定程度上可以很好的确保自动驾驶上层升级软件的完整性、真实性。
3)软件机密性保护:软件机密性保护主要分为两个层面:软件本身及软件秘钥的保护。软件本身主要是需要保护域控自身软件机密性,防止密钥、数据、隐私等重要数据的泄露;软件秘钥主要是对验签软件的秘钥关键数据进行加密,因为除开黑客本身可能对秘钥信息的恶意窃取外,诸如存储介质、文件系统异常、写入异常等发生时也可能导致秘钥损坏。这类不安全因素都需要通过秘钥安全存储及保护进行规避。
很明显,对于自动驾驶软件升级包而言,其存储着相应的程序、配置、算法、数据等重要内容。因此,需要通过线上、线下等方式将通过一定加密手段的安全升级包分发给车企,再通过DoIP协议为固件和软件进行有效升级,确保其机密性,防止数据泄露。
在解密阶段,通常会利用调用解包工具对封装的AES秘钥进行解密和验签。这样就能很好的保证软件升级包的机密性。
4)软件可信度保护:需要适时认证远程控车请求,防止伪造控车请求,破坏车辆行驶安全。
5)软件通信保护:需要确保通信的稳定性、可信度。防止窃听、伪造、篡改、重放等常见的攻击。
从硬件安全保护的角度出发,整车厂通常会通过在汽车SoC中采用硬件信任根的方式,一方面确保只有对应的整车厂身份可以被准确识别并授权访问系统。另一方面,可以创建能够为远程管理设备和部署服务创建安全通道。
数据安全保护
对于自动驾驶域控制器而言,存储了大量的数据明文存储信息,比如驾驶路线中涉及驾驶员个人隐私,地图中涉及许多测绘数据,回传数据中会涉及图片、位置信息等。因此,有必要对自动驾驶采集过程中的数据进行加密存储。对于高阶域控制器而言,通常SOC侧都会采用ARM核支持高级加密标准AES,会极大提升加密解密性能,降低对系统性能影响。同时,如果在域控的底层软件中使用的操作系统采用Linux,则可以使用其本身带有的文件系统进行高级标准加密。这类文件加密过程,其加解密对应用程序透明公开,无需开发任何代码。当然如果使用的QNX操作系统上,也可以通过账户加密方式处理,防止串口或网口被引出后攻破。
对于数据信息采集而言,需要充分对运行中的系统进行实时监控,检测系统运行的文件、配置、进程、会话、网络通信等。及时发现数据采集系统中出现的异常行为,在车端检测到异常事件后,会将异常日志存储到加密数据分区。该过程中会生成安全事件,上报至云端数据端口进行分析。其终极目标是通知运维人员对安全隐患事件进行有效处理,避免在后续的数据闭环中对运维系统带来更大的影响。
对于高阶域控来说,在数据安全方面最容易受到攻击的几个部分主要是指包含与数据有关的几个大方向:如数据采集、数据回传、数据下发、数据本地端处理等,这些服务通常需要与云端服务器进行交互,交互设备包括TSP、TBOX等云端连接服务单元。特别是高精地图维护,通常是需要定时定期从云端进行数据下载的,这也是最容易被攻击的一个方面。因此车企为了防止数据这方面的通信被攻击,通常会选择在数据通信过程中利用签发的设备证书进行发端到收端的双向认证,保护数据安全的同时也规避通信过程中的攻击。如果域控内部的模块想要访问外部服务数据,则需要获得相关的设备证书,通过安全传输协议TLS进行双向认证后,校验需要访问的服务端数据有效性和真实性后,便可以放心的访问该服务器。
为了实现ECU之间的数字证书有效验签,需要由证书管理模块实现各硬件软件模块之间的安全传输协议TLS,并且验签过程中需要确保收发端的时间同步已完成。
通信安全保护
对于下一代自动驾驶系统架构来说,围绕域控制器及其周边通过CAN、Flexray或ETH实现车辆整个ECU的通信连接,域控制器内部的连接方式更加丰富,比如包含SPI、IIC、ETH等,通常在车端主要通过车载以太网实现通信的数据闭环。整个通信承载设备内外部采用的芯片之间通信方式的不同,其面临的通信威胁方面也不一样。对于纵深防御来讲也需要采用不同的通信防御手段。
如下两图分别表示了高阶自动驾驶系统架构中外层和内层两方面不同的防御手段。
对于域控与周边关联件来说,其通信防护主要是针对CAN和ETH。作为车内主干网,CAN总线目前仍然承载了重要的车内信息的交互和通讯。发动机、刹车、油门、转向、辅助驾驶模块、安全模块、ESP、ABS、OBD、邮箱、后备箱、车门……等众多电子部件都连接到Can-Bus进行通讯。因此,需要首先抓住Can-Bus这一汽车的中枢神经的重点防护。对于通常CAN通信采用SecOC技术,同时,因为车辆的众多接口链接到Can-Bus的缘故,车联与外部的通讯接口理论上都存在被利用的可能,而这些接口一旦被劫持,对应的控制单元都可能被攻击。而在过去一段时间内,因为车内的电子部件少,并未联网的缘故,这一切安全隐患都未被关注,随着国内外智能网联汽车的大跨步发展,信息安全问题将成为关系到车辆安全的一大难关。
ETH采用TLS防护技术,内部防护机制主要是针对各芯片主节点和从节点间、SOC和MCU之间的通信,内部局域网VLAN的通信应该与外部完全隔离开来,即便外部的网络被攻击也不能影响内部网络。为了实现这一目的,在域控内部的主节点控制过程中,是不允许内部网络通过任何方式通过VLAN通信方式对外部网络发起通信申请的,比如域控内部的设备应用有包含数据闭环、高精地图等都需要通过类似TSP服务连接外网。如果网络未授权则可能存在安全漏洞,容易被黑客攻击,增加入侵风险。针对这类风险,通常也会采用类似防火墙技术进行网络访问限制(可以应用一定动态匹配规则对授权的网络进行白名单匹配,匹配通过的网络才能访问内部网络),检测异常网络事件,记录安全日志等,最终实现有效的安全防护。
写在最后
面向智能网联的自动驾驶系统更加依赖对于软件升级及实时联网的方式来进行车辆控制。而这一方面从信息安全的角度来说很容易被互联网的黑客攻击,无论是从源代码甚至是反汇编二进制程序都可以获得自动驾驶系统的关键代码。除开对软件代码的攻击外,通过植入一些木马程序也可以直接入侵智驾设备,这类攻击对于自动驾驶系统来说将是不可逆的、且致命的。因此,本文供软件、通信、数据等几个大的方面分别进行了相应的防攻击方案说明。总结起来主要是有以下几方面:
1)代码防护使用安全秘钥进行编码;
2)对外通信程序采用数字证书验签的方式进行收发程序数字验签;
3)针对通信介质的不同类型采用不同的防护方式;
此外,如果在自动驾驶系统调试过程中可能出现的一系列攻击风险,从源头上首先需要检测软硬件调试环境的一致性前提下进行,甚至在很多时候也有必要限制软件调试接口或者干脆关闭整个硬件的调试接口。
原文始发于微信公众号(焉知智能汽车):全方位解析智能网联汽车设计中信息安全保障策略(一)—-安全保障概述