0


鉴源实验室 | AUTOSAR SecOC:保障汽车通信的安全

**作者 | **沈平 上海控安可信软件创新研究院汽车网络安全组

来源 | 鉴源实验室

社群 | 添加微信号“TICPShanghai”加入“上海控安51fusa安全社区”

在现代汽车行业中,随着电子控制单元(ECUs)的普及以及车与车之间通信的不断增加,确保通信安全变得尤为关键。AUTOSAR (Automotive Open System Architecture) 的 SecOC (Secure Onboard Communication) 模块,正是为应对这种挑战而设计的。AUTOSAR作为一套开放的汽车软件标准,其中的SecOC模块在其架构中起到了至关重要的角色,它主要职责是确保车辆内部的通讯数据安全无虞。通常,SecOC模块是位于AUTOSAR通讯堆栈的PDU Router与更底层的通讯驱动之间,确保所有通过这个堆栈的信息都得到了适当的加密和保护。实际应用中,SecOC模块还能与HSM (Hardware Security Module) 模块相结合,借助硬件来更快速地进行数据加密和消息认证。

图片

图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机制。

参考文档:

AUTOSAR. (2022). Specification of Secure Onboard Communication. AUTOSAR Standard Working Specification.

标签: 汽车 安全 网络

本文转载自: https://blog.csdn.net/TICPSH/article/details/133705768
版权归原作者 上海控安 所有, 如有侵权,请联系我们删除。

“鉴源实验室 | AUTOSAR SecOC:保障汽车通信的安全”的评论:

还没有评论