Car2X Communication: Securing the Last Meter

Car2X通讯:确保最后一个里程表
一种使用车内对称加密确保Car2X应用程序信任的经济有效的方法

摘要

Car2X通信的有效性在很大程度上取决于对接收到的数据的信任。确保车内通信的安全是实现此目标必不可少的步骤，但到目前为止，我们仍然忽略了这一步骤。我们提出了一种基于使用受廉价硬件保护的对称密钥材料的方法。 涉及的密码和网络协议展示了它们在汽车总线系统中的适用性，并通过分析和仿真方法得出了其合理性的结论。正在进行的项目中，设想在真实车辆中实现原型。

机载协议； 汽车； 安全; 总线系统； 嵌入式通信 通讯协定

1 介绍

近年来，Car2X通信一直是安全性和交通效率方案的主要研究主题，而安全性和隐私性对于这些方案至关重要。 大多数解决方案一直专注于节点之间，尤其是车辆之间的通信。 但是，正如[1]所指出的，基于Car2X的应用程序才刚刚开始满足节点内安全性和隐私性的需求。 我们在欧洲资助的EVITA项目中进行的最新研究专门针对那些要求和适用于车载网络的解决方案。

本文介绍了一种用于Car2X actor的新通信安全体系结构。 我们特别描述了一种密钥分发协议，该协议是汽车车载网络内完整性和真实性的基础，以及一种用于车内通信的安全传输协议。 我们的方法是针对车载安全性量身定制的，可以根据应用程序要求和车辆的车载拓扑结构进行调整，以达到一定的安全级别。 它旨在确保ECU之间的一对一通信以及一对多通信，并确保在将此类数据发送到其他车辆之前信息的可靠性和车载数据聚合过程。

车载机载通信体系结构是针对功能要求而设计的，例如错误恢复，低延迟和对电磁干扰的高容忍度。 总线系统的安全性在很大程度上是通过模糊性来实现的，即通过物理上隐藏电线并防止散布有关数据格式和计算机接口的内部知识来实现。这意味着安全性必须“在顶部”添加 必须设计和部署现有解决方案或新的通信系统和协议。 由于成本限制，后者对于汽车行业而言几乎是不可能的。

传统上，存在几种建立安全通道的方法。 他们要么依赖共享机密，要么依赖非对称密码学和公共密钥基础结构。 后者很难在车内实现，而前者在许多Car2X场景中对于建立信任而言都太弱了，尽管它使维护变得困难。 相反，我们的安全解决方案可确保在ECU之间建立基于开放但对称加密的信任关系。 它集成到车辆的现有基础结构中，我们唯一的假设就是引入安全硬件模块，出于加密加速的原因，这些模块都是必需的。

当今车辆中最常用的通信总线是CAN总线，其运行速度约为500 kbit / s，每个数据包可提供8字节的数据有效负载。 从安全性的角度来看，安全性有效载荷的八个字节的一部分不能提供足够的保护。 另一方面，包括较大的有效载荷字段或专用于安全性的字段是不可行的。 我们展示了如何将已用于车辆其他目的的高级协议用于解决此特定问题。

2 部署架构

A 对称密钥的非对称用法

由于成本和嵌入限制，我们使用共享机密（即对称密钥）。 部署这些密钥需要一个小的硬件组件，即每个ECU的硬件安全模块（HSM）。 HSM实现了加速的加密原语，还提供了安全的（即防篡改）密钥存储，从而防止了任何ECU妥协扩散到我们的密钥基础架构。 HSM还中介对加密密钥的访问。 后者带有元数据，例如到期日期，验证码或所谓的使用标记。 这些使用标志使HSM可以区分特定密钥可以或不能使用的功能。 通常，HSM会根据以下使用标记对对称密钥访问存储区实施一些使用控制：例如，可以将对称密钥标记为在单个HSM上签名（即生成MAC），而完全相同的密钥位于其他多个HSM。 标记仅用于验证。

这种使用控制可以强制执行密钥材料的非对称使用，而计算本身则有效地基于对称密码学。 在下文中，我们将密钥kn，g称为ECUn的会话密钥的发送（生成）密钥，以及作为接收（验证）ECU1的kl，v。

贯穿本文使用的其他两个使用标记是出口和运输标记。 前者允许将密钥以加密形式导出，而后者允许将其用于加密另一个密钥以进行导出（该另一个密钥必须是可导出的）。 加密密钥在任何情况下都不能使HSM处于未加密状态。

EVITA项目区分了三种不同类型的HSM。 虽然完整的和中等的HSM支持并加速不对称加密，但我们专注于轻型HSM的使用，后者仅提供基于硬件的对称加密原语实现。 这种类型的模块最适合集成到低成本传感器和执行器中。 可以在[2]中找到全面详细的规范，包括与HIS SHE模块的比较。

B 动态密钥交换

我们的解决方案避免了全局共享密钥（如果泄露了这些密钥，那么它们肯定会损害整个系统的安全性）。通信伙伴之间的密钥分配是通过称为密钥主控（KM）的实体完成的。车辆网络上的每个ECU ei与KM共享两个密钥。第一个密钥ki，a用于相对于彼此认证实体，而第二个密钥ki，t用于对生成的密钥进行传输加密。 KM是一个逻辑实体，可以存在于一个或多个ECU中。可能有多个KM（例如，每个域一个KM），因此密钥仅为有限数量的主机共享。为了简洁起见，我们讨论了在车辆网络中仅存在一个中央KM的简化部署（见图1）。对于多个KM，必须在密钥分发协议内建立相关密钥主机之间的附加连接。我们使用分布式策略系统来授权此类跨域连接。

C 安全通信的多标准设置

我们的工作被集成到一个安全框架中，该框架特别提供API抽象以用于（i）实体身份验证，（ii）安全通信（完整性，机密性）和（iii）访问控制以及策略管理。 应用程序员可以使用给定的安全属性集SP和安全级别SL打开从A到B的通信通道。 接收者B可以是n个接收者节点的组，从而创建1：n通信信道。 安全属性集包含通道属性（例如，真实或机密），而安全级别则指对特定MAC强度的选择，如第III-C节所述。 通信模块根据这些属性启动密钥交换并建立安全通道。 直接和组通信在访问控制框架中进行管理，访问控制框架与通信API以及密钥分发协议进行交互。

3 协议

我们提出了一种用于密钥分发的协议，另一个协议使用交换的会话密钥来确保车内通信的安全。 为了解释这些协议，假设了一个简化的多播通信场景：一个节点将消息发送到一组接收者，就像在当今的车辆中常见的那样。

A 密钥分发和实体认证

在下面的内容中，我们说明如何通过密钥主节点交换安全通信的密钥。 该示例也适用于用于加密通信的会话密钥，尽管随后使用了身份验证代码生成和验证标志。

通过以下步骤在ECU e1和i ECU ei的组gx之间建立安全的通信会话s。 所有加密操作（例如生成或导入/导出）都在相应的HSM内部进行。

1）在e1：密钥对ks，g和ks，v的本地生成，其中只有ks，v可导出。 密钥的有效时间有限。
2）导出ks，v，使用传输密钥k1，t加密并使用k1，a进行身份验证。我们称此密钥为blob b1。
3）在e1和KM之间打开未经身份验证的通信通道。
4）在KM：根据策略授权e1到组gx的通信。
5）将经过身份验证的密钥blob b1（= ks，v）导入KM的HSM。
6）用相应的传输和身份验证密钥ki，t和ki，a将bs中的所有ECU ei的导入密钥ks，v重新导出。
7）打开从KM到所有ei的未经身份验证的通信通道。
8）在每个ei：将已认证的密钥blob bi（= ks，v）导入ei的HSM。
9）确认成功导入KM。
10）在KM：确认已成功分发给发起方e1。

在图2中，我们显示了此协议的序列图。 影响加密材料的所有步骤（即生成，导入和导出步骤）在受影响的ECU的硬件安全模块中执行。

请注意，由于HSM的使用标记，尽管有对称密钥，但没有ECU可以模拟一组发件人。 这也是将密钥生成和重新密钥发送给发件人的HSM的理由，因为密钥管理员将能够模拟发送ECU。

根据目前的标准，我们预计关键材料的使用寿命有限。 具体而言，预计会话将持续一个驱动周期或最多48小时，之后该会话将不再有效。

B CAN上的传输协议

由于车辆总线系统受到许多限制（例如消息有效负载）的限制，因此我们使用了传输协议。 例如，CAN总线仅在有效负载的八个字节处受到限制，使得不可能在一个数据包中传输加密密钥或签名。 在具有分组大小的载波上实现大数据块传输的标准过程是数据分段。 对于单独的数据包，需要附加的控制信息。 至少，需要保留一个序列号以解决乱序传输和潜在的数据包丢失的问题。

为了发送数据，将一系列数据分组发送到接收节点。 数据分段会产生一个额外的延迟，直到接收到所有数据。 对于n个段，这至少是数据包传输和处理时间的n倍，以及每个数据包进入总线之前的仲裁延迟。 由于CAN使用按位的CSMA / CA媒体访问仲裁，因此这种延迟在很大程度上取决于总线负载和仲裁的结果。 仲裁等待时间直接关系到CAN总线上其他消息的优先级。

主要用于诊断的ISO15765-2标准对有效载荷进行分段。 协议已在[4]中通过CTP（通用传输协议）的通用寻址方案进行了增强，该协议基于CAN 2.0 B，与通常使用的11个标识符相比，支持29位标识符的扩展寻址方案。

为了实现ECU之间的安全通信，我们使用强制性安全标头增强了该协议，该标头提供了有关用于当前数据的加密有效负载类型的信息（有关更多详细信息，请参见[3]）。

C 截断密码验证码

并非所有的车辆通信都需要相同级别的安全性和私密性。 大多数通信从未公开，因此侵犯了隐私。 除了隐私要求之外，最需要的是完整性和真实性。 在[5]中进行了一项研究，其中包括超过一百种不同要求的目录，这些要求涵盖了针对不同汽车应用的隐私，真实性和机密性。 这些都与风险和攻击可能性（即与安全相关的事件的可能性以及成功发起的攻击的严重性）结合在一起。 在图3中，您可以看到中低风险水平的累积，这意味着基本的安全措施已经可以满足许多应用程序的安全要求。

鉴于基本的安全性已经可以保护大多数应用程序，并且带宽是汽车总线上的稀缺资源，我们决定允许MAC截断。即仅使用计算出的MAC的一部分。根据NIST和FIPS的建议[7] [8]，如果不采取其他措施来限制验证率，则密码验证码的最小长度应为64位。在我们的环境中，我们已经有几个环境限制，例如总线速度（低）和总线负载（高）。此外，我们在HSM上将任何给定密钥句柄的验证试验的硬性限制设置为每秒100个。因此，我们可以进一步限制认证代码的大小，并允许最小长度为32位：考虑到我们的限制，针对32位MAC的暴力冲突攻击的预期时间超过35周。我们认为这是一个合理的值，尤其是因为通常会采用其他措施，例如涉及多个信息源的真实性检查。

4 分析与模拟

我们已经分析了密钥分发协议以及具有许多不同MAC分数（即帧段）的传输协议的性能。 对于汽车环境而言，这是至关重要的，这一点尤其重要。 我们期望在车辆的唤醒过程中已经初始化用于启动时已知的循环消息的通信通道。 这将新通道的建立等待时间限制为动态通信。

A 密钥分发

我们对以下III中描述的简化方案进行了建模：发射ECU，密钥主机和接收ECU，它们均连接到同一CAN总线并配备了HSM。该模型包括有关处理器和网络媒体的频率和负载的几个假设。具体来说，我们假设HSM的加密引擎的时钟频率为100MHz，并且需要60个时钟周期（包括调度程序周期）来对一个块进行加密（基于AES）。 CAN总线的负载为30％，每个数据包的仲裁以p = 0.5的概率获胜。消息传输包括CAN上的开销（39位报头，25位尾部，3位空闲，省略位填充）和分段的开销（第一个帧为2个字节，连续帧为1个字节）。 HSM密钥的构造如[2]中所述，因此除了密钥长度为256位和验证码为128位之外，还包含86位的标头字段。因此，为了通过CAN上的CTP成功传输HSM密钥结构，将发送9个帧：9 = 1 + d（470−48）/（7×8）e.2我们假设CAN总线速度为500kbit / s，如下这种速度通常用于车辆。

该系统已使用DIPLODOCUS UML配置文件[9]进行了建模，并使用TTool [10]的仿真引擎进行了仿真。 DIPLODOCUS配置文件及其仿真引擎明确考虑了系统的硬件元素，即CPU，总线，内存和硬件加速器（HSM）。

在上述负载和速度假设下，包括确认在内的完整密钥分发周期平均在9毫秒内执行。 尽管这对于硬实时应用程序是不够的，但是在启动时对所有静态已知的通信组执行密钥交换当然是可行的。 当前的HSM实施允许每个ECU参加64个小组。

B 具有MAC分数的传输协议

为了模拟传输协议，我们使用了更深入的仲裁阶段模拟。 我们在TrueTIME 2.0 [11]（一种Matlab-Simulink工具包）中为CAN总线上的三个节点建模，该工具包支持CAN网络的仿真。 一个节点会产生60％的高优先级背景噪声，始终会优先于我们的有效负载。 第二和第三节点为控制器和传感器/角色节点建模。 对于传感器和控制器之间的通信，我们用有效的传输协议封装有效负载并更改MAC长度。 您可以在图4的表中看到产生的延迟。

为了消除协议开销，还可以为每32位有效负载直接添加一个小的32位MAC（即，将有效负载和MAC装入单个帧）。 第一列显示了单帧传输的预期延迟。 仿真模型包括每个ECU每次发送0.4ms和每次接收操作0.2ms的处理开销。

5 相关工作

车辆领域长期以来一直受到功能需求的驱动。 安全功能仅被添加到选定的功能中，例如防盗锁或远程门解锁。 最近的分析表明，攻击车辆总线系统的风险已不再具有理论性质[12]。 甚至被认为安全可靠的功能，例如远程解锁车辆，也被证明是有问题的[13]

随着新的wirelels访问技术的集成，以支持基于Car2X和互联网通信的应用程序，对车载网络提出了新的安全威胁。 此外，为了启用某些基于通信的安全功能，必须使用车载网络中的专用安全措施来确保对源数据的信任。 尽管大多数研究都集中在保护外部通信上，但车载网络的安全性仅得到部分解决。

对于即将到来的Car2X通信，已在研究中讨论了几种方法。 大多数都依赖于非对称密码学[14]，但也考虑了组密码学[15]和定时对称[16]机制。

对于车载体系结构，许多作者提到对安全性的需求[17]，[18]，[19]。但是，很少提出解决方案。车载网络内部安全性的基础是通过预先部署密钥来建立信任关系，例如在[20]中提出的车载密钥分发机制。他们的方法基于所谓的“密钥预分发系统”。它们使用n×n生成矩阵，该矩阵存储在专用的主ECU中，所有n个ECU的零件（行）都存储在其中。和我们一样，他们的系统使用对称加密和可信硬件。但是，我们看到，这种方法的实用性在很大程度上受到以下事实的限制：在整个车辆使用寿命内，配置必须是静态的。尽管不更改完整的键控矩阵就不可能进行车辆升级，但是维护工作（例如更换ECU）非常复杂。在[21]中讨论了另一种用于车载安全的方法。提出的安全框架还依赖于主/从分区。在那里，会话密钥仅在主服务器上生成。

两种方法都适合于嵌入式系统，但是忽略了车辆网络的重要方面。 都不支持与多个接收器的通信，这是当前车载网络中的核心用例，在该网络中，数据被发送到多个接收器。 另外，到目前为止，还没有考虑到嵌入式车辆网络即车辆总线的约束以及所提出的方法的实际实现。

6 结论与未来工作

随着车辆与外部设备，车辆和基础设施服务的互连越来越多，车载网络面临新的安全威胁。 而且，为了确保来自车辆的信息信任，机载安全措施需要在提供的数据中提供保证。 尽管最近的研究已经广泛讨论了实体之间无线链路的安全性，但车载安全性仅得到部分解决，仅考虑了车载网络的约束。 我们已经将众所周知的密钥分发协议应用于车载板载体系结构，并提出了一种解决方案，用于针对特定的应用程序需求扩展预期的安全级别。 基于模拟方法，我们已经表明，大多数应用程序都可以成功部署用于车载通信。

目前，我们正在为车载环境实现原型设计，以便就安全性，总线过载和延迟之间的权衡取舍提供进一步的结果和分析。

从概念上讲，我们目前正在研究启用Car2X通信应用程序所需的保证级别，以及对车载网络中所需的安全配置的影响。