/ 导读 /

在当今主机厂的新车发布会上，车联网相关功能作为特色卖点仍占据半壁江山，如远程开空调、远程座椅加热、远程升级等。通过将车辆联网，并搭载各类传感器、控制器、执行器等智能硬件，汽车开始具有了交互和服务的能力，并从单纯的交通工具向连接万物的超级智能终端进化。

车联网让汽车焕发青春的同时，也让原本相对封闭的汽车一下子暴露在了开放的网络环境中，并随时可能受到来自网络信息安全的威胁。而车联网系统中包含的车主个人信息、常用联系人、常用地址等敏感信息，一旦被非法窃取，轻则隐私泄露财产损失，重则人身安全受到伤害。

因汽车信息安全问题导致车辆被召回的典型事件发生在2015年的菲亚特克莱斯勒汽车公司（FCA）身上。在一次信息安全测试，多名信息安全专家利用FCA生产的汽车上拆下来的娱乐主机的联网通道以及对外的物理接口，入侵了FCA的云端，并伪造发送了车辆的远程控制指令，结果顺利打开了车辆的空调、仪表、雨刷等模块。且这类攻击既可发生于车辆尚未启动时，也可发生于汽车行驶过程中，存在极大的安全风险。随后，FCA宣布在美国召回140万辆存在此信息安全风险的轿车和卡车。

处于开放网络环境中的汽车面临的信息安全风险主要来自于车载终端、云服务平台、通信链路和外部生态等方面。主机厂在经历车联网业务野蛮生长之后，开始越来越重视车联网的信息安全，并通过各种手段提升车辆的信息安全防护能力。包括加强车联网数据在全生命周期的分级分类管理和访问控制；完善车辆研发、生产、使用过程中的身份认证体系；搭建多方联动、信息共享、实时精准的安全服务平台等。

国家相关机构作为行业的监管方，也正在逐步建立建全有关网联汽车的安全管理体系（国标、行业规范），强化汽车行业对于信息安全的风险防控以及安全防御能力。

本文作为车联网圈黑话第五期，通过对车联网中典型的车云架构进行剖析，分析潜在的信息安全威胁，并介绍一些通用的信息安全方案。

车联网车云业务整体架构

车联网的常用架构为云管端架构，云指云服务平台，端指车载终端，管指连接云服务平台与车载终端的通信链路，通用的云管端架构方案如下图所示。

云服务平台一般有两个APN（Access Point Name，网络接入点），一个负责接入公网域，一个负责接入私网域。公网域一般负责文件存储、云计算等对存储资源要求高、计算能力要求大的应用。私网域主要负责车辆敏感数据交互以及车控、FOTA等业务，是主机厂车联网业务的生命线，同时需具备比公网域更高的信息安全要求。因此设置设备接入网关，对接入车载终端进行身份验证和路由服务。

车载终端以内置4G/5G通信模块的TBOX/智能网关为主。对外通过远程通信技术与云服务平台进行通信，对内通过CAN/LIN/车载以太网与车内其他ECU进行通信。从而提供行车数据采集、远程查询和控制、远程诊断、远程升级等服务。

至于连接云服务平台与车载终端的通信链路，公网域与车载终端一般采用HTTPS协议，私网域与车载终端一般采用TCP/IP协议。而对接入车辆/设备多的场景可在网络的应用层采用MQTT协议。

如同其他涉及云端和设备端的系统，车联网云管端架构面临的信息安全威胁主要包括：云端的被篡改、通信链路的监听、车端密钥的泄露、本地网络的通信安全等。

一、服务器安全

汽车领域的云服务平台与传统互联网领域云平台类似，容易遭受服务器被入侵的风险，导致敏感数据泄露、关键指令被篡改，从而损害车主的权益。比如攻击者通过入侵服务器来篡改车辆远程控制报文，轻则导致车辆操作异常，重则影响车辆正常行驶，危及用户的生命安全。

各主机厂一般采用将敏感数据和重要服务“关在家中”的手段来保证信息安全。通过专线网络、身份认证、设置独立机房专业运维等措施，阻止非法用户的访问。

二、服务接口安全

由于微服务架构具有部署灵活，弹性扩容等优点，[敏感词]搭建的云服务平台普遍采用以SpringCloud为代表的框架作为开发的基础。主机厂部分车联网业务需要获取用户、车辆、零件的相关数据，并将这些数据作为业务流转的基础。跨平台和跨系统间的数据共享和数据通信一般通过微服务的Web Service接口方式来实现。

为了验证发送方身份，并保证数据的完整性，数据传输接口一般使用HTTPS协议，来保证发送方身份的真实性。同时通过定期更换对称密钥，对报文加密或增加MAC验证字段等手段，来验证数据的完整性。主机厂还可以在报文中添加新鲜度字段（如时间戳）等手段，对新鲜度进行管理，以防攻击者使用相同的数据进行重放攻击。

云管端架构中存在多条通信链路，包括云服务平台与基站通信链路，基站与车载终端通信链路，手机与基站通信链路等。

车联网公网域主要承载车端的非敏感文件或日志的上传/下载、云存储等业务，采用HTTPS协议便能满足信息安全的需求。然而对于部署敏感数据交互和车控功能等业务的私网域，通信端需要能够应对更高等级的信息安全威胁。这些威胁包括车载终端被伪造，非法连接云服务平台；云服务平台被钓鱼；指令或业务数据明文传输被截获，敏感信息泄露；指令或业务数据被截获篡改，执行错误请求，造成安全事故等。

在通信链路攻击中，攻击者可以通过伪基站、DNS劫持等手段劫持会话，窃取车辆的知识产权或敏感数据。如在FOTA业务中监听窃取车辆的升级包，以反向工程ECU固件。

攻击者还可通过车辆物理接口，篡改云端通信路径，使用伪造的服务器对车辆实施攻击。例如执行无休止的数据攻击，从而使车端的控制器耗尽其存储空间，无法进行正常的业务操作。或是拷贝TBOX软件版本至其他设备，伪装成合法车辆对云服务平台非法访问。

通过对上述风险的分析，结合车联网业务流程涉及车云两端的频繁交互，迫切需要为参与车联网业务的核心实体对象（云服务平台、车载终端等）赋予高强度的身份标识，保证实体对象的唯一性，同时基于各实体对象的身份标识，实现车载终端接入车联网服务平台的双向高强度身份校验。

公钥基础设施（Public Key Infrastructure， PKI）通过采用非对称密码算法技术，提供信息安全服务，是一种通用并遵循标准的密钥管理平台。它能够为所有网络应用透明地提供采用加密和数字签名等密码服务所必需的密钥和证书管理。在车联网应用中，PKI可为各类实体对象提供身份的可信描述，为对象签发统一的数字身份标识—数字证书，从而构建可信的网络虚拟环境。为实现信息的保密性、完整性，不可抵赖性提供基础支撑。

PKI子系统之间的逻辑关系如下图所示。

云端的设备接入网关、车载终端均需由PKI签发证书，对于TBOX、AVN等控制器的激活操作，即PKI中的证书签发，步骤简述如下：

步骤1：TBOX产生公私钥对并构造P10申请（P10中包含证书主题、有效期、公钥以及上述信息的签名），将申请发送至云端；

步骤2：云端证书管理服务接收到请求后，对上传的信息进行校验，并将P10和车辆其他信息封装成PKI识别的证书请求，PKI签发证书；

步骤3：云端将签发后的PKI证书返回至车端TBOX存储。

在云端和设备端均激活（证书签发）后，通信实体与云端便可基于数字证书进行通信。

汽车普遍采用CAN总线连接车内的其他ECU或传感器设备。由于CAN总线通信无认证能力，缺乏加密通信功能，攻击者可利用其广播机制入侵总线上的任一节点，在取得总线的控制权后便可以向总线其他节点发送报文。因此CAN总线面临多类攻击方式的风险，包括重放攻击、洪泛攻击、修改攻击和丢弃攻击等。

HSM（Hardware Security Module，硬件安全模块）是车端安全方案的基础支撑，后文将要介绍的两种车端信息安全策略TrustZone/TEE执行环境和SecOC协议，也均是基于HSM实现。HSM将算法、密钥、加密方式等信息写入无法篡改的硬件模块中，并处理安全性相关任务包括安全的车载通信、运行时的操作检测以及安全的启动、刷新、日志记录和调试等。以此来阻止攻击者通过绕过与安全性相关的ECU接口，获得对车载网络的访问权限。

一、Trustzone/TEE执行环境

TrustZone是ARM A-profile架构中的安全架构。TrustZone将CPU的工作状态分为两种，NWS（Normal World Status，正常世界状态）和SWS（Secure World Status，安全世界状态）。支持TrustZone技术的芯片提供了对外围硬件资源的硬件级别的保护和安全隔离。当CPU处于NWS时，任何应用都无法访问安全硬件设备，也无法访问属于SWS的内存、缓存以及其他外围安全硬件设备。它们之间具有系统级别的硬件强制隔离。

操作系统和应用运行在NWS，TEE运行在SWS。通常一个 TEE包括多个由轻量级内核托管的可信服务，提供诸如密钥管理之类的功能，并为开发人员提供相应的API。

一个完整的SoC由ARM内核、系统总线、片上RAM、片上ROM以及其他外围设备组件构成。对于ARM内核的控制器，需要支持TrustZone，同时配合相应的组件，才能实现整个系统芯片达到硬件级别的保护和隔离措施。下图是一个支持TrustZone的SoC的硬件框图。

TrustZone技术之所以能提高系统的安全性，是因为对外部资源和内存资源的硬件隔离。这些硬件隔离包括中断隔离、片上RAM和ROM的隔离、片外RAM和ROM的隔离、外围设备的硬件隔离、外部RAM和ROM的隔离等。

实现硬件层面的各种隔离，需要对整个系统的硬件和处理器核做出相应的扩展，包括将CPU内核进行虚拟化，将CPU的运行状态分为安全状态和非安全状态；在总线增加安全位读写信号线；增加内存管理单元（Memory Management Unit，MMU）页表的安全位；缓存增加安全位；其他外围组件提供安全操作权限控制和安全操作信号等。

二、SecOC协议

最近几年车内总线的加密通信受到了越来越多的关注。为了响应汽车行业对数据加密和验证的需求，AUTOSAR组织补充了SecOC（Secure Onboard Communication）组件，为车载通讯总线引入了一套通信加密和验证的标准，是车载网络上一种有效的信息安全方案。

SecOC是在AUTOSAR软件包中添加的信息安全组件，该模块增加了加解密运算、密钥管理、新鲜值管理和分发等一系列的功能和新要求。SecOC模块能够给CAN/CANFD总线上的报文数据提供有效可行的身份验证机制，与当前的AUTOSAR的ARA通信机制集成良好，对资源消耗小。该规范基于对称算法的MAC认证。与非对称算法相比，使用更短的密钥实现了相同级别的安全性。

若通信的控制器之间需要实现SecOC协议，则发送和接收控制器都必须集成SecOC模块。原始报文称为Authentic I-PDU，SecOC模块基于原始数据和密钥，使用约定的算法得到MAC值。报文头、原始报文、新鲜度和MAC组装后得到Secured I-PDU，结构如下图所示。

SecOC主要基于两种手段来实现数据的真实性和完整性的校验，分别是基于MAC的身份验证和基于新鲜度的防重放攻击。首先MAC是保障信息完整性和认证的密码学方法之一，SecOC协议中MAC消息认证码的作用是验证报文数据的真实性，然而保证报文的机密性还需要进行额外的安全措施。

其次，为了降低重复攻击的风险，则需要在Secured I-PDU中加入新鲜度值，新鲜度值是一个根据一定逻辑不断更新的数值， AUTOSAR推荐计数器或基于时间戳生成新鲜度值。OEM在实施 SecOC 方案时需要定义和做好两个关键部分：新鲜度值管理和密钥管理。下图为基于SecOC的通讯加密和认证过程。

发送节点的SecOC模块在生成新鲜度和MAC，和原始报文组装为Secured I-PDU，并通过CAN总线广播。

接收节点的SecOC模块通过验证MAC来判断原始报文的来源和完整性。新鲜度值验证该报文是否重复并合法。

随着车联网技术的发展，汽车电子架构的革新，自动驾驶量产的推进，汽车在信息安全方面将面临更多更严重的威胁。各主机厂和Tier1需要通过安全防护体系的建立以及持续性的风险分析和攻防策略优化，提升各车联网平台的信息安全能力。


（本文采摘自网络，意见与观点不代表本站立场。如有侵权，请联系我们删除！）