【论文阅读】基于隐蔽带宽的汽车控制网络鲁棒认证（一）

Abstract

汽车工业最近的进步为汽车配备了复杂的娱乐和导航系统，这些系统可以连接到互联网等广泛的网络。随着车载嵌入式设备的出现，这些新奇的东西可以远程访问，汽车内部网络也随之暴露出来，并扩展到它们连接的所有组件。控制器区域网络(CAN)广泛用于控制车辆边界内的通信，并且本质上对远程(可能是恶意的)访问它们所带来的安全威胁几乎没有抵抗力。考虑到CAN的安全关键应用领域，远程攻击者在不受限制的情况下可能会造成巨大的危害。
一些现有的安全机制在加固CAN节点和嵌入式设备方面是有效的，通常可以防止这种增加的恶意活动。例如，加密协议已经到位，以建立CAN通信的真实性。然而，这种特定于通信的安全措施是以带宽、计算资源和实时保证为代价的。它们对性能和及时性的影响违背了汽车应用的本质，从而暗示了它们对车辆安全的影响。

考虑到这些因素，最近的研究建议使用隐蔽通道实现CAN通信安全措施，隐蔽通道本质上是不增加网络负载的附带传输形式，以实现强大的安全保证，而不会像现有解决方案那样损害安全性。这篇硕士论文从三个主要方面进一步探讨了这种方法。首先，构建了适用于CAN的隐蔽和类似隐蔽的带宽源的概述，它扩展了现有工作中考虑的隐蔽信道集。其次，从概述中选择基于定时的隐蔽信道，并在不同的实际实现中进行评估，每个实现都设计为比其先例提供更强的性能和可靠性保证。第三，提出了对现有CAN应用安全框架的扩展，该扩展加强了其消息认证机制，防止通过相同的定时通道丢包。对这种方法的安全影响进行了分析，发现它不会损害该框架的原始安全保障。

本硕士论文调查和评估CAN中的隐蔽带宽机会，并将其应用于增强现有安全框架的CAN消息认证方法的实际背景。

第一章 引言

本导论章通过分别讨论硕士论文的问题陈述、研究假设和主要贡献，对论文的工作进行了激励和总结。最后，给出了本文其余部分的大纲。

1.1 问题陈述

现代车辆配备了数量空前的嵌入式计算设备，这些设备调节并增强了驾驶员和乘客的体验。控制器区域网络(CAN)用于连接这些车载组件，广泛应用于汽车工业，以及建筑自动化，工厂控制和农业。考虑到这些应用领域，CAN通常在安全关键、实时敏感的功能中发挥重要作用，例如紧急制动和停车辅助。
因此，为了性能和时效性，牺牲了访问控制和消息认证等形式的CAN网络安全。这是一种合理的方法，假设CAN网络在汽车环境中的车辆边界之外是不可访问的。然而，车载娱乐和导航系统的兴起打破了这一假设，不仅将一部分嵌入式组件连接到CAN，还连接到互联网等更广泛的网络。因此，引入了一种用于渗透CAN网络的远程访问向量，这导致了针对CAN网络的广泛已知实际攻击，并扩展了它们连接的设备[12,35,6]。这些发现表明，鉴于嵌入式组件执行的安全关键功能，CAN通信被篡改可能会造成重大危害。
用于消息验证的加密协议[36,34,55]，以及使用这些协议保护软件的可信执行环境[31,32,51]，已经被提出并实施，以加强CAN节点免受此类恶意活动的攻击。然而，尽管现有的消息认证措施具有强大的安全性保证，但它们使CAN总线拥塞量增加了一倍，从而削弱了应用程序的实时性，从而再次危及车辆安全。
因此，在CAN应用程序中存在一种困难的平衡，一方面是采用资源要求高的安全措施，另一方面是诉诸于攻击者敏感的性能增强。两者都是出于汽车环境的安全需求，但从定义上讲是不相容的。因此，TACAN[58]建议通过在消息验证措施的实现中使用隐蔽通道来减轻消息验证措施的资源需求。这些非传统的传输形式利用了常规、带宽消耗流量的行为特性作为其信息载体，因此不会产生额外的网络负载。因此，它们在不影响车辆安全的情况下提供强大的安全保障。

1.2 研究假设

正如TACAN[58]引入的那样，CAN中的隐蔽通道提供了补充带宽，可以用来减轻现有消息身份验证机制引起的安全问题，而不会损害其安全保证。VulCAN[51]是安全设计的一个具体示例，它可以从将隐蔽通信纳入其消息验证方法中获益。尽管它在实现中表现出极大的效率，但VulCAN的性能和可用性仍然存在一些挑战，例如在其非nonce同步机制中。隐蔽通道可以缓解这些问题，例如，通过在不损害VulCAN性能的情况下实现显式nonce传输。

从这些考虑中产生了本工作的研究假设，即隐蔽带宽是增强CAN中现有消息认证措施的有用资源。在调查这一假设时，本硕士论文探讨了 CAN 中存在哪些隐蔽通道，这些隐蔽通道与常规、非隐蔽通信的关系如何，它们提供的带宽和可靠性的数量，以及它们如何增强 VulCAN 的非 nonce 同步方法。

1.3 贡献

本文的主要目标是模拟CAN中隐蔽传输，评估隐蔽传输在实践中的可行性，并将其应用于现有安全框架中的防御目的。所作的主要贡献如下。

1. 对适用于CAN的隐蔽和类似隐蔽的带宽源进行了宽度优先的探索，并在矩阵结构中进行了系统的总结。后者允许根据为说明实际可用性而构造的属性集对已识别的传输方法进行直接比较。
2. 对CAN中基于时序的隐蔽通信进行了深入的研究。该分析得到了MSP430硬件上的消息到达时间通道的实际实现和定量评估的支持，该通道为了计时测量精度而扩展了专用于CAN消息到达的中断机制。此实现可在https://github.com/Stienvdh/Sancus-IAT上公开获得。
3. 提出对现有VulCAN[51]设计的扩展，该设计为其 vatiCAN 后端配备了基于定时传输的可用性增强的非 nonce 同步策略。讨论了该方法的安全含义。此外，还完成了这个VulCAN扩展的实际实现和评估，并在https://github.com/Stienvdh/vulcan/tree/iat-nonce上公开可用。

1.4 大纲

下面是本论文其余部分的大纲。

第二章提供了与本研究相关的背景资料。首先介绍CAN协议本身、它的漏洞和一组已知的实际攻击。然后，详细阐述了可信执行的概念，以及Sancus和VulCAN。最后，讨论了侧信道攻击和侧信道本身，并用具体的例子说明了这些攻击。

第三章概述了适用于CAN的隐蔽信道。首先讨论了各通道的机制和特点。接下来，该信息被构造成一个矩阵，这样就可以直接比较其构成通道。

第4章详细阐述了一个依赖于数据包到达间隔时间的隐蔽通道，通过Java中的概念验证实现。本章首先介绍了该通道的核心设计要素，然后对其性能和可靠性进行了评估。

第5章将前一章中介绍的数据包到达间时间通道迁移到底层技术。它解决了在该实现中所做的设计选择，然后对其进行评估并与Java对应实现进行比较。为了进一步提高信道性能，本章介绍并评估了一种可选的中断驱动实现。最后，它列出了该数据包到达间时间通道通常受到的噪声源。

第6章描述了前一章中低级包到达间时间通道的具体应用上下文。在 VulCAN 的非 nonce 同步方法中的安全和性能相关挑战的激励下，以及从隐蔽通信中获得的好处，它提出了对VulCAN的 vatiCAN 后端的扩展，该后端利用上述定时通道进行非 nonce 同步。本章最后对提议的VulCAN扩展进行了广泛的安全分析。

第7章是对这项工作的总结，通过重复其主要贡献，承认其局限性，并提出未来研究的领域。

第二章 背景和相关工作

本章将本工作的其余部分置于CAN安全威胁，可信执行和侧信道攻击的先前研究的背景下。从这些领域的结合中出现了本硕士论文的目的，即试图通过将侧通道从攻击向量重新利用到软件控制的补充带宽来提高CAN应用程序的安全性，假设这种方法对CAN的汽车上下文施加的及时性和性能的强约束施加压力，而不是现有的可信执行设计。

2.1 CAN安全威胁

本节介绍了以往CAN安全研究中的一些核心问题，以及它们的不足。首先讨论CAN协议，介绍导致其随后描述的漏洞和实际攻击场景的机制。

2.1.1 CAN协议设计

应用程序上下文。控制器局域网(CAN)协议[45]被汽车工业用于车辆内部通信。它的作用是将汽车刹车的电子元件与泊车传感器连接起来，或将仪表盘速度计与车轮连接起来。这样的各方连接到CAN总线被称为电气控制单元，或ECU。图2.1显示了一个简单的CAN网络拓扑，其中多个 ECU 连接到同一 CAN 总线。
CAN总线。为了适应这种主要参与CAN通信的嵌入式计算设备的环境，CAN 建立在没有寻址机制的广播媒体上，从而减轻了与连接管理和/或网络加入和离开相关的任何开销。此外，ECU 在访问 CAN 总线时不同步，这意味着所有连接的 ECU 都可以在任何时候从 CAN 总线上传输和读取。由于这种设计，防止不稳定的总线行为，0位被认为是主导的，这意味着它的传输覆盖(隐性)1位。总线本身的时钟频率是可以配置的。

图2.1：连接车辆内不同组件的示例CAN网络拓扑的图形表示

CAN数据帧设计。CAN数据帧由不同的字段组成，表2.1给出了一个简化的概述。首先，在没有寻址机制的情况下，利用ID字段将消息关联到相应的应用程序和/或发送方。在原始CAN中它的长度为11位，在CAN 2.0[45]中扩展到29位。接下来，一个4位的数据长度代码(DLC)以字节为单位宣布当前消息所携带的有效负载数据的大小，其长度可变，最高可达8字节。循环冗余码(CRC)[4]是在传输的消息上计算形成一个15位校验和，用于检测错误传输。在帧的末尾的确认(ACK)位由CAN总线上的任何节点设置，以确认传输。
总线仲裁。为了保证一定程度的避免碰撞，CAN节点只有在检测到连续3个空闲CAN总线周期后才能启动传输。此外，它们在传输时检测总线是否广播期望的比特值，并在检测到差异时停止传输。显然，后者只有在两个并发传输节点中的一个发送显性(0)比特，而另一个发送隐性(1)比特时才会发生。
因此，ID字段不仅用于表示其消息的来源，还用于表示其优先级。实际上，帧的ID越低，它在传输其数据负载之前保留总线占用的机会就越大。

2.1.2 CAN网络攻击

现代汽车不仅仅是内部联网，还可以通过连接互联网的系统远程访问，用于娱乐和导航。因此，它们的内部CAN网络以及它们连接的车载组件现在暴露给远程攻击者，而在CAN协议设计中几乎没有采取安全措施。下面，讨论了CAN网络攻击者的概况和一些实际的攻击场景。

攻击概况
广泛的CAN网络攻击能力已经被描述为CAN通信的性质及其远程可访问性[12,18,56]。

攻击的执行需要获得对CAN总线上面ECU传输逻辑的控制，无论是通过车载组件[35]的物理附件，还是通过利用外部车辆可访问性的远程代码注入[6]。下面列出了ECU被控制后的主要功能。

• 窃听：由于CAN是建立在没有任何访问控制机制的广播媒体上，ecu可以自由地记录和检查它们所连接的CAN总线上的所有流量。此外，CAN在其设计中没有提供保密机制，这意味着恶意节点接收到的明文数据与它们窃听的良性节点接收到的明文数据相同。

• 消息插入：由于CAN不提供任何总线访问控制和/或发送器认证，恶意ECU可以在CAN总线上注入任何ID和数据负载的消息，并使其成功被该网络上的其他节点接收，只要它符合CAN帧格式的规范，其CRC字段携带合适的校验和。

• 消息删除：如前面2.1.1节所述，CAN总线上的任何1位都可以被0位覆盖，CAN节点一旦检测到这种覆盖就会停止消息传输。因此，恶意ECU适当定时的0位传输可以导致删除任何can消息。

拒绝服务攻击
大多数现有的CAN攻击场景利用之前介绍的消息删除功能来发起拒绝服务(DoS)攻击，例如，抑制控制制动动作的CAN数据包[35,12]。在这种汽车环境中，车辆的这种瘫痪显然会产生重大的安全相关后果，例如阻塞制动信息，或删除警告组件故障的数据包。由于CAN中缺乏身份验证或访问控制机制，因此易受此类拒绝服务攻击的应用程序集是没有限制的。

拒绝服务攻击的不同方法已经被描述过了，从总线拥塞到抑制所有CAN流量，到更复杂的、旨在规避检测的选择性攻击。由于前面提到的窃听能力，恶意节点能够在发起DoS攻击时监视其CAN总线，因此可以根据其关联的CAN消息ID选择仅针对一组选定的车辆操作。此外，由于消息传输在任何1位覆盖时都被停止，即使只是一个精心计时的0位传输也足以抑制一个完整的CAN消息[35]。因此，恶意节点可以在只传输少量额外流量的情况下造成巨大的危害，这使它们在面对入侵检测系统[28]时受益，相比之下，[28]可以很容易地检测到同样有害的总线泛滥。

例如，检测这种恶意比特或消息注入可以通过首先对特定can总线上良性流量的时间特征进行建模，并使用这些结果来评估随后监控的流量[28]的可信度来完成。当某些节点被这种方案检测到有恶意行为时，可以利用这些发起DoS攻击的已知技术，通过迫使该节点保持沉默来提高安全性，而不是造成伤害。

2.1.3 CAN应用攻击

车辆内部网络的远程访问不可避免地成为远程代码注入的攻击载体，目标是连接到它们的ecu上运行的应用程序。这种威胁已经被几次劫持的实际攻击所证明，例如，用于制动和门锁的车载应用[27,6,18,15,26]。在这种汽车环境下，应用程序逻辑修改的后果可能是严重的，以停车辅助软件的速度调节妥协为例。这类攻击扩展了2.1.2节中列出的攻击者的能力，具有更高级别的恶意活动，即不仅在CAN流量本身，而且在其管理和处理中。因此，这里考虑的应用程序攻击者概述方法具有在附加到其目标CAN网络的节点上执行任意代码的附加功能，从而使其更加强大。

一种特别危险的应用程序攻击场景是对网关ECU的攻击，该网关ECU被安装用于连接两个具有不同安全权限的网段[18,26]，例如一个控制车辆速度，另一个容纳娱乐系统。由于后者根据定义可以远程访问，因此该网关暴露于远程代码注入，从而使应用程序攻击者也可以访问安全关键段。请注意，如果不限制远程的车辆访问，这种攻击就像恶意软件感染的智能手机连接到目标汽车的蓝牙[6]一样容易执行。

2.2 可信执行

面对2.1节中讨论的CAN应用程序安全威胁，已经提出了一些措施 ???，旨在削弱网络攻击者的能力，并加强软件模块的安全性。

本节将从理论和实践两个层面详细阐述这些努力的一个子集。首先，介绍一些安全概念，然后在讨论具体实现时加以说明。

2.2.1 软件认证

在软件认证中，对组件执行的逻辑进行验证是有针对性的。更具体地说，它的软件将被证明与一些预定义的、可信的版本相等，以确保没有恶意篡改。具体来说，证明可以通过以下方式完成：证明者节点计算其加载代码的哈希值，验证者组件将该值与预期加载的可信代码的预计算哈希值进行比较。这样的比较就得出了认证的结论，因此它应该由一个受信任的方来完成，被认为是安全的。此外，如果没有加载正确的软件，任何组件都不应该能够生成所需的证明哈希值，这意味着安全的证明需要一个可信任的组件来计算暂定的哈希值。
为了满足这些先决条件，人们开发了多种架构来支持硬件级别的软件认证 [23]，例如 Sancus [31, 32] 和 Intel SGX [24]。 其中大多数通过软件隔离来扩展其认证功能，这对属于已认证软件模块的代码和数据施加访问控制。 因此，它禁止不受信任的各方篡改此类模块，以便初始证明结果保留其真实值。 此外，为了防止面向返回的编程攻击，隔离的软件只能从预定义的入口点开始执行。
这种传统的证明者到验证者证明方案在某些应用场景中可能被认为不适合，例如，出于性能考虑，这就是提出替代方法的原因。 一个这样的例子是相互证明机制[47]，其中证明者和验证者双方扮演两个角色，从而减轻对单一用途验证组件的需求。 “经典”证明的另一项进步利用了聚合的概念，并将证明者和验证者之间的一对一关系扩展到多对一替代方案。 SANA [1] 是一个支持此类聚合软件证明的示例协议，并引入了聚合器的概念，它将证明者或其他聚合器的证明消息组合成一条消息，以便由单个验证者进行评估。 因此，多个证明者的软件（例如一群物联网设备）可以在单个验证者交互中得到证明。

2.2.2 消息身份认证

认证（在启用隔离时）在软件初始化时执行一次，并涉及对整个模块进行散列处理，而消息身份验证则在每个数据包传输时执行，并在其过程中将利害攸关的消息作为参数。更具体地说，为了对消息进行身份验证，它的发送方通常会在(1)消息本身，(2)一些秘密密钥和(3)提供新鲜度的nonce值上计算消息验证码(MAC)。第2.2.5节，并将该MAC与手头的消息一起发送。然后，接收方可以通过验证要在适当的消息、秘密和随机数上计算的MAC值来验证数据包来源的身份。

显然，消息认证提供了不同于软件认证的安全保证。后者用于安全引导，而消息身份验证的目标是运行时安全性。因此，在确保应用程序b[33]的真实执行时，两者都是必需的。没有软件认证的消息认证提供了经过身份验证的流量，这些流量可能由恶意逻辑生成，而没有消息认证的软件认证对运行时通信的安全性保证为零。实际上，尽管某些组件执行的代码通过了认证，但在后一种情况下，无法验证消息的来源。

已经专门为CAN开发了几个身份验证协议。例如:vatiCAN[34]、LiBrA-CAN[13]、CANAuth[55]和LeiA[36]。这些协议的主要共同点是它们的目标是向后兼容，也就是说，当CAN总线上的其他组件启用身份验证通信时，不支持其身份验证形式的CAN节点不应该中断。AUTOSAR针对这种向后兼容的车载报文认证[2]制定了标准化的指南，并由梵帝安[34]和LeiA[36]遵守。

2.2.3 可信执行环境

正如之前在 2.2.1 节中提到的，某些架构为其加载的软件模块提供了硬件级别的证明和隔离保证。 其中大多数实例化了可信执行环境（TEE） 的概念[42,23,52]，它被定义为支持屏蔽 受保护模块（PM） 中的安全关键软件组件，同时利用一些可信计算基础（TCB） ，在任何架构级别（例如，硬件中的 Sancus [32]、虚拟机管理程序级别的 Fides [43]、操作系统内核中的 Salus [41]）。

受保护的模块（PM）。 受保护的模块（PM） 或飞地分为代码部分和数据部分。 两者都与未受保护的内存驻留在相同的地址空间中，但受到不同的、更严格的访问控制策略的约束，该策略将受保护的内存与未受保护的内存分开。 该访问控制机制通常由基于程序计数器的模型定义[42, 44]，这意味着对内存位置的访问权限的授予取决于该位置本身以及尝试访问它时的程序计数器值 。 表 2.2 列出了屏蔽 enclave 内存 [42] 的正确访问控制规则。 请注意，这些规则认为所考虑的 PM 之外的所有内存均不受保护，其中包括其他 PM。
本质上，这些规则强制受保护的代码段为只读，且非可信代码只能从其预定义的入口点开始执行。 另一方面，受保护的数据部分只能通过其相应的代码部分进行读取和写入访问。

表2.2:在可信执行环境中，当程序计数器的值设置为From时，授予内存位置to的访问权限。RWX =读/写/执行访问

可信计算基础（TCB）。TEE 提供的安全保证假定精心设计的 TEE 特定硬件和/或软件组件集的正确功能，这些组件构成了 TCB。 TEE 的 TCB 用于禁止其外部行为不当的组件损害 TEE 安全保证，因此希望尽可能小。 事实上，缩小 TCB 会减少 TEE 中关键组件的数量，从而增强其安全保证对更强大攻击者的抵抗力。 此外，从安全角度来看，架构的 TCB 更倾向于驻留在硬件而不是软件中，因为硬件组件通常不易受到损害。 然而，基于软件的 TCB 允许跨平台更大的可移植性，这使得最佳 TCB 设计必须针对特定环境。

2.2.4 Sancus

Sancus[31,32]是一个在硬件级别实现的开源[30] TEE，并通过扩展其节点来执行基于程序计数器的访问控制，该节点使用一个 保护存储区域(PSA) 来保存元数据（即 PM 代码和数据段位置）以及属于加载在其内存中的 PM 的加密信息。
它的设计假设一个由 基础设施提供商 IP 构建的支持 sancus 的节点 N，软件提供商 SP 在其上部署一个或多个 受保护的软件模块 SM_i 。基于这些实体，每个 PM 被分配一个软件模块密钥 KN、SP、SM_i，该密钥存储在相应节点的 PSA 中。

密钥管理。软件模块的KN、SP、SM的创建从节点主密钥KN开始，先随机生成节点主密钥KN，然后由IP安全存储，最后加载到n的PSA中。软件提供商密钥KN、SP由KN派生，再由一个公共SP标识符派生，IP在此基础上与SP安全共享KN、SP。最后，KN,SP,SM由KN,SP和SM标识符派生而来，SM标识符是其代码段和其代码段和数据段存储位置形成的布局的哈希。此构造中涉及的两个关键派生都是通过硬件实现的功能完成的，以确保它们不受恶意软件的影响。如前所述，KN,SP,SM存储在PSA中，因此软件无法访问。然而，Sancus中包含了特殊的指令，允许间接使用KN、SP、SM，以保证它仅在执行属于其相应SM的可信代码段期间使用。

远程认证。 此外，Sancus 还提供了强大的远程证明保证[10]，因为 SP 部署的受保护模块 SM 的完整性可以由 SP 高度保证地进行证明。 由于 SM 和 SP 都可以访问 KN、SP、SM，因此两者都可以分别计算 SM 的加载内容和预期内容的哈希值。 然后，将先前生成的散列值验证传输到 SP，从而产生远程（即，不在 N 本身上）验证 SM 内容完整性的能力。由于 KN、SP、SM 只能从其相应的 SM 代码部分获得，因此 SP 对正确的证明响应 (1) 已由已证明的 SM 计算以及 (2) SM 未被篡改具有很高的信心。

2.2.5 VulCAN

VulCAN [51] 旨在 在 CAN 应用的特定环境中实现消息身份验证和软件认证/隔离。 本节讨论其设计中的关键原则，并作为本文进一步研究的应用程序上下文的前奏，重点讨论其随机数同步方法。

VulCAN Design

VulCAN[51,49]将Sancus enclave(参见第2.2.4节)的使用迁移到汽车环境中，以启用经过身份验证的CAN通信(参见第2.2.2节)，以及软件认证和软件隔离(参见第2.2.1节)保证。

它明确地从TCB中排除了操作系统、网络和I/O交互软件，从而允许CAN流量和未受保护的ECU应用程序逻辑被攻击者接管，同时保留其安全保证。

VulCAN中的消息身份验证是通过在每个应用程序消息传输中附带一个后续身份验证帧来完成的，该身份验证帧用于携带经过前一个计算的64位MAC值。两个消息认证协议，即梵蒂冈[34]和LeiA[36]，由于它们符合autosar[51,2]，被选择来管理MAC计算和MAC传输细节，每个协议都依赖于Sancus的加密原语，以最小限度地扩大VulCAN的TCB大小，超出它从Sancus继承的TCB。更具体地说，在VulCAN的TCB中需要实现这些认证协议的软件，并且利用已经存在的Sancus设计来安全存储mac相关计算中使用的关键材料，从而降低了其大小。除了在CAN通信中至关重要的特定应用软件之外，VulCAN不向TCB添加其他组件。为了确保基于软件的TCB部分的可信执行，VulCAN还可以配置为在Sancus飞地中隔离。

Nonce Synchronisation in VulCAN

下面首先讨论nonce同步的一般目的和遇到的困难。 随后详细阐述了两个 VulCAN 后端如何处理这个概念，以及它们各自在该领域的弱点是什么，使这些困难变得更加具体。

Nonce synchronisation（随机数同步），在 VulCAN 中实现的消息身份验证上下文中，随机数的目的是提供消息新鲜度。 更具体地说，计数器值或随机数与每个应用程序消息相关联，并用作该消息的 MAC 的计算和验证中的参数。 与在 MAC 计算中用作另一个参数的加密密钥相反，随机数可以安全地透露给任何一方。 事实上，获得与某些有效负载关联的随机数不足以让攻击者构造有效的相应 MAC，因为通常假设无法访问该秘密密钥。

通过为每条消息使用唯一的nonce，使用不同的nonce计算任意两个有效的MAC值，这意味着这些值本身很可能不相等，这取决于MAC算法的强度。 因此，有效的MAC值在某种程度上保证与新消息相对应，即之前没有经过身份验证和处理的消息。因此，无法产生有效MAC值的攻击者无法成功地在CAN总线上重放经过身份验证的流量并欺骗接收器接受它。

这种机制在发送(MAC计算)和接收(MAC验证)节点之间的nonce同步中提出了一个重要的挑战，即，在呈现接收器时，当它验证MAC时，知道发送方在计算MAC时使用的nonce。两个VulCAN后端目前都使用32位的nonce，如果nonce与其消息一起传输，在CAN总线上会有很大的负载。因此，部分恢复到隐式nonce同步是可取的，例如，通过让发送方和接收方都存储一个本地nonce，它们在成功传输(分别到达)经过身份验证的消息时增加该nonce。然而，发生消息丢失时（就可能不同步了），这种方法引入了自己的复杂性，因为接收节点的本地nonce可能落后于发送节点。

此外，一个额外的挑战在于保证nonce的唯一性，从而保证消息的新鲜度【及时性】，同时受限于有限的nonce空间。针对这些考虑实现了不同的策略，其中两种策略适用于VulCAN，因此将在下面讨论，每种策略对带宽使用和安全保证都有自己的含义。

LeiA backend. VulCAN 的 LeiA [36] 后端利用应用程序消息和身份验证消息的扩展 CAN ID 字段来传输 16 位计数器，该计数器构成与其关联的随机数的下半部分，并且在每次身份验证消息传输时递增 1 。 为了说明与消息相关的高 16 个随机数位，LeiA 使用本地存储的纪元值，这些纪元值在 ECU 重置、16 位计数器溢出或 MAC 验证失败时都会递增并在 CAN 总线上显式传输。

因此，LeiA 的优点是可以减轻完整随机数传输的总线负载，同时通过显式传输部分随机数值来保持针对消息丢失的鲁棒性。 然而，LeiA 对扩展 CAN ID 字段的使用破坏了功能依赖于它的应用程序的向后兼容性。 事实上，它们不能再使用 29 位消息 ID 空间，因为其中一部分被 LeiA 保留。 此外，VulCAN 评估 [51] 显示了该方案如何对不使用扩展 ID 的遗留应用程序的性能造成相当大的压力，因为它意味着传输中需要额外的 CAN 总线交互。

vatiCAN backend. 与 LeiA 相比，vatiCAN 不会为了随机数同步而修改常规 CAN 流量。 相反，发送节点和接收节点保留本地随机数值，该值在成功的身份验证帧传输或到达时递增。 正如前面提到的，这种方案在消息丢失方面会受到破坏。 图 2.2 说明了在数据包丢失后，由于后续通信中本地接收者随机数 n_R 与本地发送者随机数 n_S 不同，vatiCAN 身份验证确实失败。

图2.2:由于 VulCAN 的 vatiCAN 后端消息丢失，发送方和接收方 nonces n_S和 n_R 不同步的示意图。消息丢失后，在后续通信中身份验证失败，因为接收方期望使用的 nonce 比发送方在 MAC 计算中实际使用的 nonce 要低。

为了防止消息丢失后的所有通信因身份验证失败而被丢弃，vatiCAN 提供了随机数生成器 (NG) 组件，该组件定期广播随机生成的值，用于重新同步所有参与方的本地随机数。 然而，这种方法使得 vatiCAN 容易受到高级重放攻击，因为这种随机化会导致随机数重用，如 VulCAN [51] 所示。 消除这种威胁的现有主要努力是将 vatiCAN 随机数大小增加到 64 位 [7]，但这并不是合适的缓解措施。 认识到该漏洞后，VulCAN 将 NG 从其 vatiCAN 后端中排除，从而以消息丢失恢复来抵抗重放攻击。

2.3 侧信道攻击

一般原则。 尽管在嵌入式系统中建立安全保障做出了许多努力，如第 2.2 节所述，但最近的工作揭示了先前被忽视的侧信道攻击类别的严重性。 用作攻击向量的侧通道并不驻留在架构级别本身，因为飞地执行通常可以成功地将可信软件与其不可信环境隔离开来，但会遵循微架构级别引起的状态变化[17,22,50, 40]或应用程序级别[39,21,20]，这些可以被受保护模块之外的各方观察到。 当作为攻击媒介有效时，侧通道通常会泄露有关此类可信模块的执行和数据的私人信息。

旁路攻击（侧信道攻击）的一些实际示例利用推测执行 [17,22,50] 或缓存访问 [57] 后的微架构泄漏。 具体来说，在 Sancus 中，Nemesis [54] 攻击将中断延迟时间暴露为泄漏正在进行的 enclave 执行的私人信息，随后可以从中推断出 enclave 的秘密，例如密码和 PIN 码。 更常见的副作用也可以携带此类私人信息，以网络传输中的数据包时序作为本工作其余部分特别感兴趣的示例。 下面详细阐述了利用此类定时通道的一些现有攻击场景，说明了它们可以携带的信息量和类型。

定时攻击。 出于对实时性的考虑，大多数网络协议的目标是尽可能减少传输中的延迟。如果没有任何软件级的对策，利用这种网络的应用程序的定时属性就会传播到网络流量本身。当恶意方还可以实时窃听该流量时，这些定时信息就会随之公开。因此，通过网络数据包定时泄露敏感数据的应用程序很容易受到基于定时的各种攻击的影响。

Lipp等[21]和KeyDrown[39]描述了特定的定时攻击实例，利用击键中断时间来推断键盘上按下的相应键。这些漏洞随后会泄露敏感信息，比如插入的密码和个人识别码。当只有受信任的各方才能访问这些泄露时，它们是无害的，但面对越来越强大的攻击者，这种假设往往过于强烈。

探测此类攻击本身就是一项艰巨的任务，因为窃听通常不会留下任何痕迹。因此，KeyDrown[39]等预防措施提供了更有效的缓解策略。KeyDrown建议注入虚拟击键来“淹没”真实的击键，以混淆包含在其时间中的信息。然而，当将该概念转换为在CAN中插入虚拟流量时，该方法施加了明显的带宽限制，这是大多数汽车网络无法容纳的，因此该方法不适用于CAN。另一种带宽要求较低的预防策略需要在击键消息传输[38]中引入随机延迟，这可能会破坏某些应用程序的实时依赖功能，这是一个缺点。

从这些考虑中，出现了一个在现有研究中形式化的匿名三难困境[8,20]。实际上，匿名性、延迟和消耗的带宽之间存在三种权衡，因为匿名消息时间跟踪的所有方法要么需要额外的总线拥塞，要么需要偏离常规帧传输延迟。在最初的CAN设计中，为了满足应用程序上下文对性能和时效性的严格限制，牺牲了匿名性，这导致了2.1节中列出的相当大的CAN攻击者能力集。最近关于基于CAN的系统设计的工作b[29]明确指出，由于现代远程攻击者的能力，这种不平衡如何不再合理[27,6]，并提出了新的设计原则，以寻求安全，性能和实时保证之间更适当的平衡。

实用示例：VulCAN缓冲区比较。VulCAN[51,49]，如2.2.5节所述，旨在通过比较自计算的MAC和接收到的MAC来对接收方的消息进行身份验证，目前大约实现【两个链接】如下：

虽然这是正确的，但这种方法可能会引入一个侧信道。实际上，这种MAC比较，在其编译成机器语言时，可以转换为for循环，随后检查8个MAC字节对是否相等，并在不同的字节对上退出。这是一个有效的转换，因为一旦任何8个对应的位不匹配，就不需要检查所涉及的MAC值的其余部分。然而，执行这样一个循环所花费的时间揭示了如果身份验证失败，哪个字节对导致它过早退出。因此，测量该时间会产生恶意方关于mac_me的部分信息，这意味着一系列精心设计的mac_recv有效负载可能会完全泄漏mac_me，这反过来可能导致恶意流量注入mac_me，从而不正确地通过身份验证。这种攻击场景取决于攻击者的能力，因为它可以利用其消息插入能力进行mac_recv有效负载注入，并利用其窃听能力进行MAC比较计时。

这个侧通道目前在VulCAN中不存在，但考虑到前向编译器的独立性，应该加以阻止。作为本论文的一个小贡献，一个扩展VulCAN的实现，具有执行有保证的恒定时间缓冲区比较的能力，并在MAC比较中使用它，在https://github.com/Stienvdh/ VulCAN /tree/ct-time-compare上公开提供。

2.4 结论

CAN网络的现有工作已经揭示了其对各种攻击的实质性漏洞，主要是由于缺乏访问控制和消息认证机制。这些安全漏洞被用来换取性能和实时性的保证，这在CAN的应用领域是合理的，因为它连接的电子元件驻留在一个可能不超过车辆边界的网络中。然而，汽车行业的最新发展，通过整合互联网连接的GPS设备和娱乐系统，将这些内部网络暴露给了远远超出这些边界的各方。这种远程访问使得目标车辆之外的攻击者能够渗透到其未受保护的CAN网络中，从而对其安全造成巨大伤害，例如通过抑制制动动作。

由于这些演变，导致需要采取安全措施来加强CAN通信本身以及控制它的应用程序，以抵御这种新的、更强大的攻击者配置文件。本章讨论了这些措施的一个子集，主要关注软件隔离和消息认证保证，以及这些概念如何在Sancus和VulCAN中实现。尽管取得了这些成功，但一种相对较新的侧信道攻击揭示了一些仍然存在的安全威胁，同时也暴露了非传统传输信道中可以携带的信息量。文章来源地址https://www.toymoban.com/news/detail-757086.html

到了这里，关于【论文阅读】基于隐蔽带宽的汽车控制网络鲁棒认证（一）的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！