一、通讯加密的必要性
随着汽车电子的发展及整车功能复杂性的提高，车载控制器数量从之前的寥寥几个增加至规模复杂的上百个。基于功能的需求，各个控制器每时每刻需要进行大量数据的交互，数据交互的方式也多种多样，比如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协议使用。
本文转自https://zhuanlan.zhihu.com/p/105353137
