虹科干货 | CAN XL安全实践：深度防御下的密钥协商优化

摘要

随着汽车以太网的兴起和车载通信系统数量的增加，网络整合成为控制复杂性和成本的关键。当前架构呈现明确分层：以太网（100/1000Mbit/s）支撑信息娱乐、ADAS等高带宽应用，而CAN/CAN FD（0.5-5Mbit/s）处理发动机管理等实时控制。未来CAN XL和10BASE-T1S将瞄准中速控制领域。值得注意的是，当前约90%的车载节点通信速率仍≤10Mbit/s，凸显了中低速通信的基础性地位。

虹科PCAN XL套件

01. 深度防御

过去数十年间，IT行业始终秉持深度防御（Defense-in-Depth）核心理念，通过在信息技术系统中部署多层级独立安全控制机制，为潜在的单点失效提供冗余防护。基于这一理念，在车载10Mbit/s通信领域同步构建两种技术体系的安全防护层，已成为汽车行业应对网络整合趋势的必然要求。

本文针对多点数据层安全架构建设中的两个关键难题展开研究：其一聚焦于高效密钥协商协议的开发，其二探索桥接设备跨网络连接场景下的端到端加密实现方案。

需要特别说明的是，本文提出的安全增强方案严格遵循分层防护理念，其设计目标并非取代现有OSI协议栈中的安全机制（如车载SecOC协议、IPSec或TLS等），而是通过纵向协同构建更完备的防御体系。

02. MACsec 和 CANsec

以太网已经有了MACsec及其配套的密钥协商协议MKA，且已定义了十年之久，而国际CiA协会正通过CiA613-2为CAN XL制定CANsec规范。MACsec和CANsec的目标都是在各自的数据层之上，以线速性能提供保密性、完整性和认证性。

图1 MACsec / CANsec

为满足这些要求，这两种技术都使用具有提供认证加密和相关数据（AEAD）操作模式的分组密码。MACsec只支持AES，而CANsec则计划以 ASCON[3]的形式支持轻量级加密。

受保护的帧携带一个单调递增的分组编号（PN），以防止重放攻击。这个分组编号用于生成一个随机数（Nonce），该随机数是相应AEAD算法所需的输入。

那么有了这些基石，就不可能在网络的整个生命周期中使用永久有效的加密密钥，因为使用相同密钥意味着重复使用随机数，这样实际上会使加密无效。

因此，需要一种机制来协商一个临时有效的会话密钥，或者根据MKA规范称为安全关联密钥（SAK），并定期更换该密钥。

03. 10Mbit/s速率领域的MKA

以太网拥有经过充分验证、功能丰富但也相当复杂的MACsec密钥协议，专门用于解决这一难题，因此，选择MKA作为CANsec(CAN XL)和MACsec(10BASE- T1S)的密钥协议解决方案也是很自然的。

MKA是围绕零知识和零假设方法设计的，每个参与者只依赖自己的实施质量。由于MKA使用专用的MACsec密钥协议数据单元 (MKPDU)，它不需要知道有多少参与者正在、将要或曾经在线，也不要求参与者以一定的频率发送数据。此外，每个参与者在启动时生成的随机成员标识符确保了重放保护。如果相关参与者的随机数生成器质量较高，则该参与者可以安全地抵御MKA控制信息的重放攻击。

不过，典型的MKA应用与在10Mbit/s速率领域的预期应用之间存在两个决定性差异。

首先，虽然MACsec密钥协商是为任意数量的参与者（或根据IEEE 802.1标准称为对等节点）制定的，但实际使用中很少超过两个参与者。

其次，MKA的Hello时间为两秒。因此，建立密钥协商至少需要两秒，平均需要三秒。

虽然这种密钥协议时间在数据中心等典型的以太网环境中是可以接受的，但在汽车或其他对时间更敏感的环境中就不行了。对于增加一个安全层所造成的通信延迟具体有多少是可以接受的，目前还没有达成共识。观点有从几毫秒到一百多毫秒不等。这完全取决于具体的使用情况，但对于大多数（汽车）使用情况来说，MKA所需的平均3秒钟太慢了。

04. 更快的MKA

以下优化措施的目标都是在不违反现有规范[2]的情况下，缩短密钥协商时间（即从所有参与者上线到所有参与者能够相互通信的时间间隔）。因此，MKPDU，尤其是其中包含的所有参数集都不会以任何方式进行修改，也不会违反IEEE规范中的任何「应」和「可」规则。

2021年，Völker博士[1]提出了一些修改建议，以优化密钥协商时间。其基本思路是：根据MKPDU的内容对其进行分类，并相应地修改发送频率。

最直观的，你能想到的规则是，每当有有助于达成密钥协议的消息要发送时，每个参与者都要发送一个更新的MKPDU。这些规则是：

(1) 潜在对等节点或活动对等节点列表发生了变化

(2) 需要分发新的安全关联密钥

(3) 已安装新的安全关联密钥，需要进行确认

(4) 新参与者想要加入连接关联

我们将这组规则称为基本配置文件。

如文献[1]所示，这些修改产生了显著效果，将密钥协议所需的时间减少到了30毫秒以下。

05. 多节点应用场景

让我们将这些修改应用于MKA，将参与者数量扩展到n，并从理论上分析需要交换多少消息，以及每个参与者必须处理多少消息。

如果所有参与者同时上线，每个参与者都会生成一个MKA Hello消息，其中包含其随机生成的成员标识符。每个参与者都会收到n-1条这样的消息，每次处理一条，就向其潜在对等节点列表中添加n-1个条目，并回复n-1次。那么总共会发送n²条消息，每个参与者必须处理n²-n条消息。因此，密钥协商的这一初始步骤与参与者数量并非呈线性关系。

图2 基本资料——参与方发现

如果我们将规则稍作修改，这个问题就可以得到解决：

(1) 在潜在对等节点或活动对等节点列表中添加一个密钥服务器对等节点。

我们将这组修改后的规则称为优化配置文件。在典型设置中，通常只有一两个具备密钥服务器功能的参与者。

这使得每个参与者必须处理的消息数量减少到O(n)。

图3 优化配置文件——参与方发现

在密钥分发过程中也能观察到类似的现象。根据MKA规范，如果有参与者添加到活动对等节点列表中，密钥服务器应分发新的SAK。

在我们的系统启动场景中，密钥服务器在收到第一个MKA Hello响应时会发出一个新的SAK，收到第二个响应时再发出一个，如此继续，直到活动对等节点列表最终包含所有参与者的成员标识符。总共会分发n-1个SAK，但只有最后一个会得到所有参与者的确认。不幸的是，所有SAK都会被其MKA Hello消息最先被密钥服务器处理的参与者确认，除第一个SAK外，其他SAK都会被其MKA Hello消息第二个被处理的参与者确认，如此继续，直到最后分发的SAK最终被所有参与者接受和确认。为了完成密钥协商，每个参与者总共必须处理O(n²) 数量的消息。

图4 基本配置文件——密钥分发

为了解决这个问题，必须减少密钥服务器分发的密钥分发消息数量。一种实现方法是让密钥服务器知道参与者的数量。有了这个信息，密钥服务器可以有意延迟SAK的分发，直到收到所有预期参与者的MKA Hello消息。但这需要完全静态的网络设置，因此并不适用于所有用例。例如，若有一个参与者的启动速度明显慢于其他参与者，就会导致网络中的其他部分无法通信。

另一种保持MKA对网络拓扑无感知特性的方法是限制新SAK的发布。密钥服务器在处理完一个传入的MKPDU后，会进入一个需要发布新SAK的状态。此时，它不是立即发送相应的MKPDU，而是将发送延迟一定时间。这使密钥服务器有时间处理其他传入的MKA Hello消息（见图5），并发布一个可供更多甚至所有参与者使用的SAK。让我们将这种行为添加到优化配置文件中。

图5 优化后的剖面图

在对16个参与者进行的模拟中，这种优化将分发的SAK数量减少到两个，从而消除了运行时间随参与者数量呈二次方增长的问题。这种方法具有很大的灵活性。根据网络设置，你可以选择合适的延迟时间来优化密钥协商时间。

例如：

(1) 所有参与者速度相同。你可以将延迟时间设置为一个较小的值，但要足够让密钥服务器处理所有MKA Hello响应。

(2) 有一个参与者比其他参与者慢得多，但它提供了重要信息。你可以将延迟时间设置为能让这个慢的参与者有足够时间发送其MKA Hello响应的值。

更有利的是，如果连接的参与者不提供此选项，或者你无法访问其配置，那么只需对密钥服务器应用此配置即可。

06. MKA的替代方案

密钥协商协议的选择取决于对密钥协商的具体要求，以及协议名称所隐含的特性。如果你的保护目标是使密钥协商不会受到来自孤立参与者的有效记录流量的攻击，那么密钥协商协议需要包含一些挑战响应协议部分，强制加入一个潜在攻击者无法控制且质量良好（尽可能随机）的值（即挑战）。

有两种方法可以实现这一点。第一种方法需要一个高度同步的公共时间源，这本身就是一个难题，本文不对此进行讨论。第二种方法要求每个参与者生成一个随机数，并将其发送给所有其他参与者，而其他参与者则必须在响应中包含所有这些随机数（在MKA中称为成员标识符）。

这正是MKA所采用的方式。任何替代方案都必须采取类似的做法，并且不可避免地至少需要一个消息往返，因此会涉及传输和处理时间。如果没有设置时间，就无法实现能够抵御这种重放攻击的密钥协商。

07. 小结

仿真结果清楚地表明，MKA可以优化到在典型网络设置中，最多16个参与者的密钥协商能够在50毫秒内完成。与标准MKA相比，这是一个巨大的改进，因为我们只是对时间进行了更精确的调整，并分析了关键因素。

这种优化方法保留了MKA的所有优点（功能丰富、经过充分验证、与网络无关），使其适用于许多需要更快通信启动时间的用例。

08. 桥接场景中的端到端 CANsec

在某些用例中，桥接设备是两个或更多CAN XL网络的一部分，用于实现消息在CAN总线A和CAN总线B之间的转发。

图6 桥接的CAN XL网络

可能会出现这样的情况：CAN总线A上的消息的优先级标识符已被CAN总线B中的CAN XL节点使用，因此如果不进行修改就转发消息，会导致优先级标识符冲突。

如果你想使用CANsec保护这样的系统，可以为总线A和总线B分别建立不同的连接关联。桥接设备对传入的消息进行解密，根据需要修改优先级标识符，然后重新加密消息。考虑到深度防御原则，这可能不是最佳选择，因为这意味着桥接设备必须拥有两个关联的长期密钥，这使其成为攻击者的主要目标。

从安全角度来看，端到端加密更为理想，即桥接设备不进行加密操作，因此无需访问任何密钥。为了在CANsec中实现这种场景，当前的CiA 613-2草案规定了一些选项，可以将优先级标识符和虚拟CAN标识符（VCID）排除在CANsec提供的完整性保护之外。

虽然这些选项确实使实现此类场景成为可能，但请确保你极其谨慎地使用它们，因为优先级标识符和VCID都不能包含语义信息，这一点至关重要。

09. 切勿将优先级标识符用作标识符

CAN XL相较于传统CAN和CAN FD的改进之一，是它打破了标识符字段在语义上不太合理的双重用途。在CAN XL出现之前，标识符字段既是物理层的优先级指令，又是消息标识符。因此，在不改变消息含义的情况下，无法更改标识符字段。而在CAN XL中，优先级指令由优先级标识符承担，接受字段（AF）负责识别消息的含义。

在理想情况下，设计CAN XL网络的系统工程师会牢记这一点，不会混淆这两个字段的独立用途。在这种情况下，CANsec的排除选项支持端到端加密的桥接。但是，如果至少有一个CAN XL节点只是对现有CAN FD实现的简单迁移，会发生什么情况呢？

很可能优先级标识符只是遗留项目中的CAN标识符，因为这是将项目迁移到CAN XL的最简单方法。这样一来，优先级标识符的含义超出了预期，在不失去CANsec保护的情况下，无法桥接CAN XL消息。

遗憾的是，当前的CANsec草案并未针对这种情况提供安全的解决方案。

CANsec排除选项的另一个缺点是，网络中的所有节点都必须预先配置，以表明某些消息要进行转发，并因此将优先级标识符从其完整性校验值（ICV）计算中排除。如果不更改配置，就无法通过桥接设备连接第二条CAN总线，而这可能由于无法访问所有节点而无法实现，这限制了扩展选项。