图1 SecOC在BSW中的架构图

SecOC通信流程依赖于两大核心组件：消息认证与新鲜度值（Freshness Value，FV）。为了确保消息的真实性与完整性，SecOC利用消息认证码（Message Authentication Code，MAC）进行核实。在消息发送过程中，系统会利用预定的密钥生成MAC，并将其附加在原消息之后。而在消息接收端，系统会再次利用相同的密钥计算MAC，并与接收到的MAC进行校验。如若不符，则表明消息在传输过程中可能遭到了篡改，或者并非来自一个合法的发送方。而Freshness Value（FV）的存在主要是为了应对“重放攻击”。为此，每一条消息都会伴随一个FV值。这是一个不断变化的动态值，如计数器或时间戳，确保每一条发送的消息均具有其独特性。在MAC的生成过程中，FV也起到了关键作用。这一整个流程如图2所示。

图2 SecOC通讯流程图

接下来，我们将根据AUTOSAR SecOC官方文档的附录11.4，深入探讨基于多新鲜度计数器的SecOC机制是如何实现的。在此示例中，我们遇到三个关键运行实体，它们是：新鲜度管理器ECU（即“Master”），以及负责接收和发送报文的ECU（我们称之为“Slave”）。在此机制中，Slave的任务是接收来自Master广播的Freshness Value（FV）计数，以便同步更新其本地的FV计数。简单地说，Master负责维护并广播当前的FV计数，而Slave根据接收到的计数进行更新，确保它们的计数值保持一致。这种同步机制是为了确保在整个系统中，每次的通信都有一个独特的、不断更新的FV，以加强安全性。这三者之间的交互和关系可以在图3中看到。

图3 多新鲜度计数器管理关系图

在SecOC通信流程中，所有的数据传输都默认采用大端模式。发送者发送的安全报文（简称S-I-PDU）由几个部分组成：S-I-PDU报文头、待保护的交互层协议数据单元（I-PDU）、Freshness Value（FV）和Authenticator（也称为MAC）。值得注意的是，S-I-PDU报文头和FV并不是每次都必须的，它们是可选组件。另外，I-PDU不一定包含原始报文中的所有载荷（payload），它可能仅包含部分数据。进一步说，通常情况下，我们不会完整地发送FV和MAC的所有数据。为了效率和安全性的考虑，我们通常只选取其中的部分数据包含在S-I-PDU中。具体来说，对于FV，我们从其低位开始，选取一定长度的数据；而对于MAC，我们则从其高位开始，选取一定长度的数据。这种数据组织和截取的方式确保了在有限的报文长度内，我们可以传输最关键的、具有代表性的数据。如图4和图5所详细展示。

图4 安全报文构成图

图5 FV和MAC截取示意图

MAC（消息认证码）的计算是关于数据完整性和真实性验证的核心。在SecOC中，其生成主要采用对称加密算法。例如，通过使用AES算法，我们可以得到CMAC（加密消息认证码）。为了计算MAC，我们需要考虑几个关键部分：

· Data Id：这是一个两字节的数据标识符，它有助于区分和识别不同的I-PDU。

· I-PDU的保护部分：这并不是完整的I-PDU数据，而是我们选择需要加密保护的部分。

· 完整的FV (Freshness Value)：如前所述，FV是一个动态的值，用于确保每条消息的独特性，避免重放攻击。

将这三个部分组合起来，我们就可以得到MAC的输入数据。然后通过应用特定的加密算法（如AES生成CMAC），将这些输入转化为独特的MAC值。如图6所示。

图6 生成MAC数据构成图

在此示例中，完整的Freshness Value（FV）是由以下四个部分构成的：

· Trip Counter (TripCnt)：由主Freshness Value Manager（主FVM）控制，每一次“trip”（如车辆启动和关闭的周期）都会递增。它主要记录了车辆启动的次数。上下电时触发。

· Reset Counter (ResetCnt)：由主FVM管理，它基于配置的周期（ResetCycle）进行周期性递增。可以看作是一个中间级别的计数器，用于追踪系统重置的次数。

· Message Counter (MsgCnt)：与发送器ECU相关，每次发送信息时都会递增。用于追踪特定ECU发送的消息数量。

· Reset Flag (ResatFlag)：与ResetCnt同步更新。它直接取自ResetCnt的低位数据，大小通常为两个bit。作为一个标志位，它提供了关于系统重置状态的快速参考。

当我们谈到需要截取的FV时，特指Reset Flag和MsgCntLower（消息计数器的低位部分）。如图7所示，这些组件如何组合以形成完整的FV。同时，它们之间的更新关系和如何相互影响可以在图8中看到。这种设计确保了在保持消息的唯一性和安全性的同时，系统能够高效地进行操作。

图7 FV构成与截取图

图8 FVCnt更新逻辑图

接下来，我们将探讨SecOC的同步报文（称为SyncMsg）及其结构。在SecOC的上下文中，同步报文起着至关重要的作用，它确保系统中的所有实体（例如Slave）与主控制实体（例如Master或通常在整车中的网关）保持同步。简而言之，它允许这些实体对关键的计数器值和状态有一个统一的理解，从而确保整个通信过程的安全性。同步报文的构成如下：TripCnt、ResetCnt和MAC。如图9所示，这三个部分组合形成了完整的同步报文。Master（通常是网关）会定期发送这些同步报文，确保系统中的所有Slave能够与之保持同步，从而维护整个系统的安全通信。

图9 SyncMsg构成

同步报文的MAC计算与安全报文的MAC确实存在细微差异。在同步报文的环境中，为了确保消息的真实性和完整性，我们需要使用稍有不同的数据元素来生成MAC。在同步报文中，生成MAC需要以下数据：

· Message ID (MsgID)：这是一个唯一标识该消息的值。它有助于区分和识别不同的同步报文。MsgID通常占用两个Byte。

· Freshness Value (FV)：在这种上下文中，FV由TripCnt和ResetCnt组成。

为了确保整体数据长度为整个Byte，如果这两个计数器的组合不构成完整的Byte长度，那么后续的空白部分会用0来补齐。如图10所示，MsgID、TripCnt和ResetCnt是顺序排列的，然后将这些数据输入加密算法来生成MAC。

图10 同步报文MAC生成数据构成图

上文为大家浅析了SecOC的通讯机制。接下来，我们将模拟这一机制进行实验。利用特定的CAN总线仿真工具，我们配置了一个Master节点和一个Slave发送节点。为确保仿真节点的SecOC机制无误，我们还使用了某CAN总线测试工具进行验证和检验。

将同步报文ID配置为0x100、TripCnt的长度配置为24 bit、ResetCnt的长度配置为18 bit以及MAC的长度配置为16 bit，MAC生成的对称加密算法选择为AES-128，密钥为12345678901234567890123456789012。将以上同步报文以2秒将ResetCnt递增的方式。具体信息如图11所示。

图11 同步报文配置信息表

将安全报文ID配置为0x0、IPDU长度配置为40 bit，FV的长度配置为8 bit以及MAC的长度配置为16 bit。MAC生成的对称加密算法选择为AES-128，密钥为12345678901234567890123456789012。具体信息如图12所示。

图12 安全报文配置信息表

在仿真节点中完成以上参数的配置后，在测试工具中完成相应的参数配置，并进行SecOC机制的验证，通过测试结果调试自己的仿真节点逻辑。如图13、14、15所示。

图13 SecOC机制参数配置图

图14 安全报文验证图

在图14中，红色框中内容表示测试工具作为安全报文接收节点，收到发送节点（仿真节点）发送的安全报文信息，其中要保护的I-PDU为78901234，截断的FV为00，截断的MAC为E27277（16进制）。绿色框中内容表示安全报文生成MAC时所需的数据。蓝色框中内容为测试工具根据配置信息所生成的MAC值。只有测试工具计算的MAC值与收到的截断MAC值匹配才测试通过。

图15 同步报文验证图

在图15中，红色框中内容表示测试工具作为同步报文接收方，收到主节点发送的同步报文信息，其中TripCnt值为91，ResetCnt值为77，截断的MAC为D608（16进制）。绿色框中内容表示测试工具根据配置信息整合出来要生成MAC的数据（16进制，符合前文图10结构）。蓝色框中内容表示测试工具计算得到的MAC值。只有测试工具计算的MAC值与收到的截断MAC值匹配才测试通过。

本文对AUTOSAR SecOC通讯机制进行了简单的阐述，并通过建立仿真节点实现SecOC通讯机制，随后通过测试工具验证所实现的SecOC机制。