文：岡 健五，译：牛喀网
由于汽车软件规模增长和复杂度不断增加，通过无线网络空中升级(OTA：Over-the-Air)的实际应用需求愈发强烈。同样的，使用无线网络远程诊断的需求也日益增长。OTA和远程诊断技术也对网路安全有要求。
汽车软件故障频繁引发召回事件
现在一部车搭载的软件规模已经达到8千万到1亿行，据说2015年度量产的车辆，有一半以上的成本都是电子产品。为了实现更高级的功能，车载软件越来越复杂，同时由于软件故障带来的危险也在增加。
最近2到3年，因为车载软件的故障引发召回的车辆有几百万台。针对这个问题，主机厂一直抱有很大期待的解决方案就是基于无限网络的空中升级技术。官方名称叫做SOTA(Software Updates Over-The-Air)。像特斯拉已经在使用SOTA技术。 SOTA有几个优点：
因为不需要汽车4S店和修理厂介入召回过程，所以召回成本会显著下降。
即便是考虑汽车网络安全的脆弱性，也可以随时更新。也就是说搭载易受攻击的软件的车辆在路上存在的时间减少了。因为针对很多车辆同时进行软件更新变得更加容易。
当然，这些前提都是汽车网络安全。如果网络不够安全的话，攻击者可以制作特殊功能的软件、用可以引发事故的病毒软件或者蠕虫等攻击脆弱的SOTA。比如让开到一定速度的车辆失去制动能力。
远程诊断可以让主机厂收集车辆相关的信息，利用这些信息进行适当的调查和分析。 远程诊断的好处有以下几点：
在故障车辆运到修理厂的过程中，工厂的工程师可以远程诊断出问题，进行事前分析，准备好需要的配件。这样车主在修理厂的等待时间缩短，只需要等待零部件更换时间。
为了降低潜在故障发生的可能性，或者改善故障发生时候的处理效果，可以适当的收集大量的数据进行分析。
要利用远程诊断技术，只有有权限的人才可以访问车载软件。显然，必须要设定特定的安全机制。针对不同的诊断功能，要慎重的考虑安全属性。
如果不这样做，攻击者可以恶意利用远程诊断获取机密信息。更严重的话，可能启动安全相关的功能测试，引发交通事故。
EVITA的3个安全等级
提供SOTA和远程诊断功能的基础设施需要适当的安全解决方案。要实现这样的解决方案，需要有信任锚。这个信任锚是在硬件安全模块(HSM)的基础上，附加高级的安全解决方案。
2008年到2011年期间，欧盟的FP7(Framework Programme)中，实施了EVITA(E-safety vehicle intrusion protected applications)项目。该项目的核心是研究适合汽车使用环境的硬件安全解决方案。
该项目考虑了汽车业界面对的多种情况，比如，车载系统追求的耐高温，振动特性，以及严格的成本控制要求。
EVITA的硬件解决方案有三个等级。可以让汽车行业根据需要选择安全等级。
最高的安全等级是EVITA Full.它包括ECC(Elliptic Curve Cryptography)加密加速器，惠而浦散列引擎，AES(高级加密标准)加密加速器，Whirlpool哈希加速器引擎，AES加密加速器，RAM，ROM，专用安全CPU，随机数发生器(TRNG)和伪随机数生成器(PRNG)。EVITA Full是适合于所有像V2X的通信中的车辆对车辆和道路与车辆通信一样，需要ECC加密加速器的安全解决方案。
第二高的安全等级是EVITA Medium，除了去掉了ECC加密加速器和哈希加速引擎之外，和EVITA Full没有区别。EVITA Medium适用于汽车需要的大部分安全解决方案。虽然没有ECC加密加速器，但是如果需要的话可以安装非对称加密软件。虽然处理速度低很多，但是适用于非时效(也就是非关键安全)的用例。
図1 搭载到处理器上的EVITA Medium HSM
最后是EVITA Light， 和EVITA Medium相似，单是没有采用专用安全CPU， RAM和ROM的容量也减少了。只适用于以AES引擎为基础的安全解决方案。比如数据的加密/解密，数据的MAC(Message Authentication Code)生成/认证解决方案。
SOTA的步骤
汽车的各种ECU按照用途可以适用于各个等级的EVITA.我们假设V2X站点适用于EVITA Full，发动机ECU，网关ECU，防盗控制器适用EVITAMedium,制动ECU和门控ECU适用于EVITA Light。
在EVITA的安全硬件基础上，可以开发支持SOTA和远程诊断这样的功能的安全解决方案。
对于SOTA,防止程序刷写数据和过程被攻击者篡改是非常重要的。因此，后端收到软件刷写数据后，临时存储在Flashing Gateway中，Flashing Gateway利用EVITA Medium HSM这样的硬件安全模块确认该请求，然后对目标ECU的软件实施更新。
図2 SOTA过程概要
典型的步骤入下：
ECU供应商或主机厂制作软件升级包，OTA硬件在数据包上添加电子签名。
通过OTA后端到FlashingGateway的通信回路将签名的软件包下载下来。
Flashing Gateway的HSM对下载的软件包进行签名认证，通过UDS安全服务动作来通过目标ECU认证。
HSM将目标ECU和安全访问用的秘钥、验证下载的数据签名的秘钥以安全的形式保存起来。
认证成功后，对目标ECU进行软件更新。软件更新前，bootloade会对下载的软件签名进行验证。签名验证通过后，bootloader启动新的软件。
远程诊断的功能分类
所谓远程诊断就是车辆和诊断工具通过无线连接，没有物理接触。
远程诊断的步骤如下：首先主机厂服务器发出诊断命令，目标车辆收取命令。诊断命令可以认为是由主机厂的工程师(数据收集)或者修理厂的工程师(故障诊断)发送的。
诊断命令经由车载网络发送到目标ECU处理。诊断结果通过车联网模块传回主机厂的服务器。诊断的功能有很多，什么样的功能适合远程诊断需要弄清楚，需要把这些功能分组。
図3 诊断的分类
诊断的程序可以分为被动和主动两种。被动诊断是指工程师不需要对车辆进行物理操作。反之，主动诊断是指工程师需要对车辆进行物理操作。无论是主动还是被动诊断程序，都不需要车主来操做。
表1是各种诊断功能组是否适合可能或适合远程诊断的分析结果。也表明了相关的安全属性。适合远程诊断的所有功能，都有真实性和完整性要求。
表1 关于远程诊断的分析结果
远程诊断分组
可能性
适用性
真实性
完整性
机密性
Passive-ReadDataList | Y | Y | ○ | ○ | △ |
Passive-ReadDTC | Y | Y | ○ | ○ | △ |
Passive-ReadFreezeFrame | Y | Y | ○ | ○ | △ |
Passive-ClearDTC | Y | Y* | ○ | ○ | × |
Passive-InspectionTests | Y | Y | ○ | ○ | △ |
Passive-Adjustment Tests | Y | N | NA | NA | NA |
Active-InspectionTests | N | N | NA | NA | NA |
Active-Adjustment Tests | N | N | NA | NA | NA |
*问题可以远程解决情况下适用，否则不适用。
○：必须，△：送信数据机密的时候必须；×：不需要
