疫情当下,各种消息满天飞,不如一起在家看SecOC!!!
通讯加密的必要性
随着汽车电子的发展及整车功能复杂性的提高,车载控制器数量从之前的寥寥几个增加至规模复杂的上百个。基于功能的需求,各个控制器每时每刻需要进行大量数据的交互,数据交互的方式也多种多样,比如Lin、CAN、CANFD、FlexRay 、车载Ethernet等。
其中成本低、可靠性高、应用普遍的有Lin、CAN通讯,而FlexRay、车载Ethernet等基于成本因素,目前主要在高端车型中使用(FlexRay后续得到普遍应用的可能性较小,楼主主要认为其比较尴尬,首先成本方面接近车载以太网而通讯速率又远低于它,而伴随着未来智能化、网联化的趋势,车载Ethernet在未来得到推广的可能性要比FlexRay高很多)。
但在目前的车载网络中,大部分数据传输都是在没任何安全措施的情况下进行的,即使有安全措施也大都非常简陋。因此在绝大多数情况下,控制器基本以原始数据的形式进行数据交互。即使接收节点能对数据进行合理性检查,这些措施对数据可靠性的提升也是有限的。接收节点无法验证数据来自于期望的发送节点还是其他节点,即无法验证数据是否真实。同时,总线上传输的数据也是可以自由访问的,因此可以通过分析总线上传输的原始数据来反推得到其表示的内容,这样的数据传输既不进行保密也不进行认证。例如应用最广的CAN通讯设计之初是没有考虑过信息安全问题的。其明文传输、报文广播传输、极少网络分段等特性,让进入整车网络的黑客如同进了游乐场,轻松便可以伪造报文对车辆进行控制。
为了给CAN通讯增加一定的安全性,攻城狮们在CAN报文的负载中做文章,即在报文中增加RollingCounter和Checksum进行报文丢帧和数据准确性的检验,RollingCounter就不说了,我个人感觉就是心理安慰罢了,报文计数符合一定的累加原则就可以仿造,而Checksum的计算方法大部分OEM定义的也比较简单,很容易被破解从而对总线的数据进行篡改,一旦能够直接访问车辆的总线,任何人都可以读取总线上传输的原始数据,甚至可以截获这些数据并且修改后重新发送到总线系统中,这毫无疑问会影响整车的功能和安全性;另一方面,一个标准CAN报文的数据部分最多有8个字节,本身需要承载很多车辆运行的功能数据,从中拿出任何Bit用于承载RollingCounter和Checksum都会对总线的繁忙程度产生负面影响,因此OEM尽量使用少的Bit位来承载RollingCounter和Checksum,这也让黑客较容易就可逆向出算法。
所以,加密通信(Cyber Security或Security Onboard Communication)近年来受到了越来越多的关注,因最近几年也发生了很多对车载网络的恶意攻击事件。为了响应汽车行业对数据加密和验证的需求,AUTOSAR组织补充了全称为Secure Onboard Communication(SecOC)的组件,为车载通讯总线引入了一套通信加密和验证的标准,可以说SecOC是目前为止车载网络上一种有效的信息安全方案。
SecOC介绍
SecOC是在AUTOSAR软件包中添加的信息安全组件(组件位置及可应用的通讯方式如下图所示),该Feature增加了加解密运算、秘钥管理、新鲜值管理和分发等一系列的功能和新要求。SecOC模块在PDU级别上为关键数据提供有效可行的身份验证机制。认证机制与当前的AUTOSAR通信系统无缝集成,同时对资源消耗的影响应尽可能小,以便可为旧系统提供附加保护。该规范主要使用带有消息认证码(MAC)的对称认证方法。与不对称方法相比,它们使用更小的密钥实现了相同级别的安全性,并且可以在软件和硬件中紧凑高效地实现。但是,规范提供了两种方法必要的抽象级别,因此对称和非对称身份验证方法都可使用。
1．对称加密算法
对称加密算法的加密和解密使用的密匙是相同的,也就是说如果通讯两方如果使用对称加密算法来加密通讯数据,那么通讯双方就需要都知道这个密匙,收到通讯数据后用这个密匙来解密数据。
2．非对称加密算法
非对称算法中用到的密匙有两个,分别是公匙和私匙,要求通讯双方都有自己的公匙和私匙,自己公匙加密的数据只有自己的私匙才能解开,自己私匙加密的数据也只有自己的公匙才能解开。公匙是可以公布在网络上的,相当于一个公共的电话簿,可以被其他人获取到的。
以一个通信的例子来说明非对称算法:
A 要和 B 进行通信,A在网络上获取到B的公匙,然后把数据用B的公匙进行加密发送给B,B收到了数据后就用自己的私匙进行解密数据,然后就可以看到数据内容了,即使在网络传输中加密数据被黑客截取,由于黑客没有对应的私匙,他也无法解密数据进行查看。
在通信中对称加密算法比较高效,但是需要告知对方加密钥匙,在实际运用时比较麻烦,所以一般都是用非对称加密算法来加密对称加密算法的钥匙,然后发送给对方,对方收到对称加密算法的钥匙后,后续通信就用对称加密算法来加密消息内容了
若控制器之间实现SecOC功能,则需要发送和接收控制器都集成并实现SecOC模块。在AUTOSAR中,需要加密保护的数据信息被称为Authentic I-PDU。SecOC模块基于Authentic I-PDU和密钥使用一定的加密算法得到Authenticator(例如 MAC)。Authenticator和Authentic I-PDU再加上一些必要的报头即得到Secured I-PDU,Secured I-PDU也可选包含新鲜度值Freshness Value,Secured I-PDU的结构如下图所示:
其中MAC和新鲜度分别具有不同的作用,在SecOC标准中,AUTOSAR主要基于两种手段来实现数据的真实性和完整性的校验:基于MAC的身份验证和基于Freshness的防重放攻击。首先MAC(Message Authentication Code)是保障信息完整性和认证的密码学方法之一,其中CMAC(Cipher–based Message Authentication Code,CMAC一般用于对称加密,整车厂可在车辆下线刷写程序时静态分配密钥,也可选择使用云端服务器动态地给车辆分配密钥。)是车载总线加密认证常用方案。MAC的作用不是防止有效数据被泄露,而是为了保护数据不会被攻击方篡改,即完成数据来源的认证。如需保护通信数据不被攻击方监听,则报文的有效数据还需要进行额外的加密。
为了降低重复攻击的风险,则需要在Secured I-PDU中加入新鲜度值,Freshness Value是一个根据一定逻辑不断更新的数值,Freshness Value的更新方法多种多样,AUTOSAR 标准将计数器或基于时间的新鲜度值作为典型选项。具体使用何种和具体的加密方式,以及如何定义新鲜度度其实并不在标准之内,这就给OEM有了各自定制化方案的可选余地,因此OEM 在实施 SecOC 方案时需要定义和做好两个关键部分:新鲜度值管理和密钥管理。
基于SecOC的通讯加密和认证过程如下所示:
在发送节点,SecOC模块向待发送的Authentic I-PDU添加认证信息从而创建Secured I-PDU。认证信息包括Authenticator(例如CMAC)和可选的Freshness Value。无论Freshness Value是否包含在打包后的Secured I-PDU中,在生成Authenticator期间都会考虑Freshness Value。
在接收节点,SecOC模块通过验证收到的Secured I-PDU中包含的Authenticator来判断Authentic I-PDU的来源。为了实现认证,接收节点除了需要Authentic I-PDU外还需要知道发送节点计算Authenticator时使用的Freshness Value。
总结
车载通讯加密除了AUTOSAR推荐的方案,也有很多私有的定制化方案,其目的都是保证整车通讯的安全性,这在未来的汽车电子发展中是非常重要的一方面,但是实施SecOC后,其会大量占用CAN报文负载,对于只有可怜巴巴的8字节传统CAN通讯来说可能无福消受了,因认证信息的强度和信息长度强相关。在传统CAN上应用不仅导致总线负载率提升、通信实时性下降,甚至可能影响正常功能,最终既得不到预想的信息安全强度,又牺牲了相当大的CAN通信能力,因此SecOC更适合配合CANFD协议使用。
参考文献:
1、Autosar 、Vector、EB、CSDN等资料)
