1.前言
我们知道,在车载网络中,大部分的数据都是以明文方式广播发送且无认证接收。这种方案在以前有着低成本、高性能的优势,但是随着当下智能网联化的进程,这种方案所带来的安全问题越来越被大家所重视。
为了提高车载通信的安全性,各OEM已经采用针对敏感数据增加诸如RollingCounter和Checksum的信息,但其能实现的安全性十分有限。
而随着车载网络技术的发展,我们有了更多的方式来实现网络安全。之前我们曾介绍过E2E(End to End)的技术,本期我们将介绍SecOC方案。
2.SecOC简介
SecOC全称Secure Onboard Communication,主要用于对车内敏感信息进行认证。
其数据结构如下:Authentic I-PDU是需要被保护的数据;Authenticator为认证信息(通常使用消息认证码,即Message Authentication Code,简称MAC,后文以MAC来简称此内容);Secured I-PDU Header为可选用的报头;Freshness Value为可选用的新鲜度值。
图1 Secured I-PDU结构
而在实际使用中,新鲜度值和MAC可能会使用较多长度的数据来提高安全性,但这又会消耗大量的带宽等资源,所以常使用截取的方式做平衡处理。新鲜度值和MAC都按照完整的值来生成,但是在发送和认证的时候只会截取一部分,如下图所示:
图2 Secured I-PDU的截取
以CANoe demo中的ARXML为例,其节点ECU1发送的Secured_PDU_1分别包含了8个字节的Authentic I-PDU,1个字节的新鲜度值(实际长度8字节)和3个字节的MAC(实际长度16字节)。
图3 Secured I-PDU在ARXML中的排布示例
接下来我们就以此Demo为例,来详细谈谈SecOC中2个重要的组成部分:新鲜度值管理(Freshness Value Manager,简称FVM)和MAC生成。
3.新鲜度值管理
在SecOC中,给出了多种新鲜度值管理方案:
1)基于counter的递增,即包含了原有方案的机制
2)基于全局时间戳,源于时间戳的唯一性
3)基于同步的复合counter
这里我们主要谈一下第三种方案。在此方案中,完整的新鲜度值包括同步计数器(Trip Counter)、重置计数器(Reset Counter)、重置标志值(Reset Flag)和消息计数器(Message Counter)。其中消息计数器又分为高值和低值,而真正在报文中发送的值只包含消息计数器的低值和重置标志值。
图4新鲜度值结构
新鲜度值的更新如下所示,完整的新鲜度值为0x10000040F,实际发送的新鲜度值为0xF。而由于重置标志值为1 bit,消息计数器虽然以步长1递增,实际发送到总线上的新鲜度值则是以2的步长递增。
图5新鲜度值示例
从上述内容可以看出,新鲜度值存在2个重要的基准:同步计数器和重置计数器,这2个计数器需要接收方和发送方保持一致。SecOC在新鲜度值管理上提出了主从模式的框架,由主节点向接收方和发送方分发同步计数器和重置计数器,从而达到同步的目的。
图6主从模式的新鲜度值管理
图7新鲜度值的分发示例
4.MAC生成
MAC是对受保护数据的身份认证。其中涉及的加密算法多种多样,每个算法还可以有多个配置。这里我们以SecOC提供的一个方案Profile 1进行说明,其使用CMAC/AES-128的算法,截取8 bit的新鲜度值和24 bit的MAC,配置信息如下所示。
图8 Profile 1配置
除此配置外,MAC生成还需要128 bit的密钥(这里预先定义了0x0102030405060708090A0B0C0D0E0F10)、16 bit的Data ID(这里预先定义了33)、完整的新鲜度值和需要认证的数据。Data ID是用来标识I-PDU的数据,可以给密钥管理机制提供支持。以Demo中时间戳为8.300203的I-PDU进行说明,需要认证的数据为0xE8030000000000FF,完整的新鲜度值为0x100000405,实际进行加密运算的数据为Data ID、待认证数据和完整新鲜度值的拼接,计算后的实际MAC为0x498330e818f3fbb068759ff3b72d015f,截取24 bit后发送的MAC为0x498330。
图9 MAC发送示例
这里使用的加密为对称加密,以更快地进行I-PDU的交换。通常的做法还包括利用非对称加密的方式来传递对称加密的密钥,以此完成密钥的定期更新。通过对Data ID、I-PDU和密钥的映射,以及密钥的更新和分发,可以做到一个非常完整的密钥管理方案。
5. SecOC测试开发
从上面可以看出,SecOC的机制是比较复杂的,按照过往的项目经验,需要测试验证的内容包括新鲜度值管理、MAC认证、密钥分发等。
为了保证ECU的运行环境,并监测ECU自身的行为,我们需要仿真其外部条件,包括同步报文、ECU接收的SecOC报文等。为了实现此仿真环境,可以使用CANoe提供的Security模块。
在CANoe的Security Configuration中,对SecOC方案的进行选择与配置,并将其与控制器的端口形成映射。
图10 Security Configuration配置
在ARXML中,可直接配置相关的信息,包括Data ID、新鲜度值的长度等。通过这种方式,可以对每个I-PDU进行不同Data ID的配置从而形成I-PDU和Data ID的映射。
图11 ARXML相关配置
在CANoe的Security Manager中,可以对Data ID进行其密钥的写入,实现密钥与Data ID的映射。
图12 Security Manager相关配置
除了使用CANoe的Security模块,还可以集成CANoe的SecOC接口函数等进行编程来实现仿真环境。解决了仿真环境后,需要依据所开发的测试用例实现测试脚本。一方面验证正向的SecOC流程,另一方面验证SecOC机制的防“攻击”特性。通过使用CANoe的各个内置函数及外部第三方编程接口,对仿真条件进行相应的输入控制器,并监测ECU的反馈,就可以高效地完成SecOC的验证。
图13 SecOC测试用例展示
6.总结
在网络安全领域,越高的安全性要求,意味安全机制的复杂性,对系统资源消耗和性能的更高要求。那么,需分析和确认哪些数据需要被保护、网络安全等级如何定义也尤为重要。结合应用场景,考虑数据的敏感性、实时性等要求,才能选择合适的方案。不管是E2E更偏向数据完整性的校验,还是SecOC中更关注身份合法性的认证,包括SSL、TLS提供的保密性,都是可供选择的方案。
北汇信息专注于汽车电子测试、与众多OEM合作,在总线网络诊断测试开发相关领域积累了丰富的经验。本次为大家简单介绍了SecOC,后续将会为大家带来更多信息安全的相关内容。关于车内的通信、诊断刷写中各类网络安全相关的测试验证方案,欢迎垂询和沟通,共同探讨。
注:文中图片来源于AUTOSAR、Vector CANoe
参考文献
[1] AUTOSAR_SWS_SecureOnboardCommunication
[2] AUTOSAR_SWS_CryptoServiceManager
[3]NIST Special Publication 800-38B
-
车载网络
+关注
关注
6文章
159浏览量
31765 -
网络安全
+关注
关注
10文章
3155浏览量
59698
发布评论请先 登录
相关推荐
评论