基于SecOC的CANsec解决方案

1. 动机

CAN Bus 不安全可能是当今汽车网络中被提及最多的安全问题。已经发表了许多关于为什么车辆容易受到攻击的论文，其中 CAN 总线是这些声明的核心。其根本原因在于，上世纪 80 年代发明的 CAN 总线并未考虑网络威胁，这或许是可以理解的，因为车辆连接性尚未纳入范围。随着车辆功能的发展和对安全性的需求变得越来越明显，提出了许多安全解决方案来解决 CAN 不安全问题。也许最有说服力的解决方案是 AUTOSAR 提出的解决方案，它依赖于使用共享对称密钥验证 CAN 帧并包括新鲜度保护：

图像

图 1 Autosar 中的 SecOC 流程

由于 AUTOSAR 的普及，该解决方案是当今最流行的解决方案，但由于执行新鲜度管理和数据认证任务需要多层软件，因此会对主机 CPU 造成性能损失。

图像

图 2 Autosar 分层架构中的 SecOC BSW

如上所示，当收到一个安全的PDU时，它会被路由到SecOC进行MAC验证。SecOC 依靠新鲜度值管理器 （FVM） 来确定接收到的新鲜度值是否在可接受的窗口内。在这里，可以根据 OEM 偏好使用各种 FVM 策略。由于 CAN 有效载荷长度有限，许多解决方案需要截断的新鲜度值，这导致需要定期同步完整的新鲜度值。在 FVM 的响应之后，SecOC 将请求发送到加密服务管理器 （CSM） 以执行加密功能以验证 MAC。在将结果返回给 SecOC 之前，CSM 可能依赖软件库或 HSM 加密驱动程序来执行这项工作。最后，如果验证成功，则 SecOC 将 PDU 转发到 PDU 路由器，或者引发错误标志并丢弃帧。这些任务对应的 CPU 工作量很大。

由于趋势是消息和 CAN 通道的数量增加，CPU 开销惩罚的问题只会变得更糟。为了满足吞吐量需求，芯片供应商提供集成在硬件安全模块 （HSM） 中的 AES 加速器。但经验表明，负责处理数百条消息的身份验证请求的中央 HSM 由于数据复制进出 HSM 的开销而成为瓶颈。请注意，AES 引擎延迟仅占 HSM 执行身份验证所花费的总时间的一小部分。大部分延迟是由于作业设置、数据传输、作业调度、密钥获取和响应主机的软件开销造成的。随着 CAN XL 的推出，它将支持高达 2048 字节长的有效载荷和高达 10Mbps 的波特率，对 HSM 的性能要求必然会变得更差。如果除了身份验证之外还需要加密，那么将数据传输出 HSM 的额外开销将进一步增加主机 CPU 传输或接收数据的总体延迟。显然，今天的安全硬件和软件架构是不够的。

2. 威胁模型

CAN总线面临许多威胁。此处的列表显示了最令人担忧的威胁：

欺骗：由于 CAN 总线的广播特性，任何 CAN 节点都可以通过欺骗 CAN ID、DLC 和有效载荷来发送任何消息

嗅探和重放：由于 CAN 数据的开放性和丰富的 CAN 分析工具，CAN 帧可以很容易地被嗅探和重放，以使 ECU 执行某些功能，例如解锁门或应用中断

否认：由于 CAN 总线的广播特性，当传输恶意 CAN 帧时，无法证明哪个 ECU 负责发送虚假消息

资源耗尽：当使用 AUTOSAR SecOC 启用消息身份验证时，恶意攻击者可以发送精心挑选的新鲜值，使接收者忙于验证同一帧的真实性以耗尽 CPU 资源

拒绝服务：恶意 ECU 可以连续发送零 ID 消息，导致它们始终赢得仲裁并拒绝其他 ECU 在总线上成功传输。此外，不合格的 CAN 硬件可以通过破坏某些字段（例如插入填充位或修改物理层 CRC）来杀死特定的 CAN 帧，从而导致目标 ECU 进入 BusOff 状态。

CANsec 可以解决除拒绝服务之外的所有上述威胁，拒绝服务需要额外的检测和预防机制。

3. 安全 CAN 控制器

为了在降低 CPU 开销的同时应对数据认证的吞吐量和带宽不断增长的需求，建议将 CANsec 层集成到 CAN 控制器中，以支持线速的认证和/或加密。

图像

图 3 CANsec 架构

在 ECU 启动期间，车载通信密钥从 HSM 安全存储器缓存到 CAN 控制器专用 KEY RAM。此 RAM 只能由 HSM 通过专用总线访问，以防止恶意 CPU 访问。它也只能由 CAN 控制器内的 AES 引擎直接访问。添加了额外的 CAN 寄存器以允许用户为每个安全通道标识符 （SCI） 指定密钥索引映射。类似地，为每个消息添加一个专用寄存器来存储帧新鲜度值。后者必须在 ECU 关闭之前存储到安全内存中，以确保在下一个引导周期同步。当接收到 CAN 传输请求时，CAN 控制器执行以下序列：

根据 SCI 的密钥索引获取密钥明文值并加载到 AES 引擎中

获取新鲜度值并将其增加 1

输入 CAN ID | 下载内容 | CAN 负载 | Freshness Value， Payload Type， 进入 AES 引擎生成完整性校验值 （ICV）

当帧以线速传输时，将 CANsec 标头（新鲜度值）和 ICV 插入有效负载

在接收期间，将遵循类似的过程，并附加将接收到的新鲜度值和 ICV 与预期值进行比较的步骤。为了检查新鲜度，将接收到的值与存储的新鲜度值加上预配置的接受窗口进行比较。这对于允许可能不同步的 ECU 重新同步到接收到的新鲜度值是必要的，而无需复杂的新鲜度值管理策略。如果 Freshness 和 ICV 值都符合预期，CAN 控制器会使用接收到的值更新 Freshness Value 寄存器并设置接收标志以让应用程序处理数据。否则，它会设置错误标志以通知主机 CPU 接收到帧但数据无效。

4. 概念证明

瑞萨电子进行了一项可行性研究，以证明实施 CANsec 概念是有意义的。基于 CiA 613-2 CANsec 规范的早期版本，在 FPGA 中实现了原型 CANsec 实现。为了比较苹果和苹果，我们还在软件中实现了 CANsec 协议。由于上述原因，不适合使用 SecOC。

该图显示了基于软件的实现所需的 CPU 性能。处理时间与 Payload 数据量成正比，这是显而易见的，因为更多的数据需要更多的时间来处理。预计 CANsec 软件的 RX 延迟和 TX 延迟不会有不同的斜率。相反，模型应该具有几乎相同的斜率。但是在 SW 中还有一个更大的步骤是为了发送帧而不是为了接收帧。这可能是软件优化的一个领域。但是，接收和发送的总体趋势是相同的。

图像

图4 CANsec CPU处理时间

该软件在 1.2GHz 的 R-Car H3 SoC 的 ARM 内核上运行。如果这个数据会被分解到一个 400MHz 的 MCU；那么在 100% 的总线负载下，CPU 将被占用 25%（@252byte 有效负载）。这是一项相当大的工作，考虑到这样的 MCU 有多个 CAN-XL 通道，那么 CPU 很快就会过载。因此，将其实现为 CAN-XL IP 中的硬件加速功能是有意义的。

下图显示了硬件实现的处理延迟。CANsec 模块在 CAN 控制器的数据路径中实现。为此，延迟必须比 CAN 总线上的 CAN-XL 帧处理时间短，以确保以线速进行处理。在我们的原型实现中，CANsec 模块的时钟频率为 80MHz，并使用 16 个 S-Box 进行 AES 算法，通过这种设置，我们得到的值远低于 CAN 总线上消息的占用时间。例如，可以通过使用更少的 S-Box 来消耗更少的芯片尺寸来实现进一步的优化。

图像

图 5 CANsec 硬件延迟时间

5. 结论

CANsec 是一种实用的解决方案，可保护 CAN 总线免受 CAN 网络面临的最常见威胁，同时减少主机 CPU 开销和对更大、更强大 HSM 的需求。将高速身份验证/加密任务从 HSM 卸载到分布在外围设备中的加密引擎可以减轻 CPU 负担。通过以线速执行身份验证，它以最小的信号延迟为应用程序提供无缝的安全性。让 HSM 控制密钥缓存可以创建安全策略，以限制 ECU 在应用程序不再被视为受信任时发送安全消息的能力。

进一步表明，在硬件和软件中实现 CANsec 是可行的。当然，在软件中实现将具有与今天基于 SecOC 的实现相同的缺点。然而，软件实现将允许在开始时平滑迁移该技术，当时并非所有控制器都支持 CANsec 的硬件实现。

审核编辑：郭婷