基于CANoe的SecOC实现

在今天的车载网络中，大部分数据传输是在没有任何特殊安全措施的情况下进行的。因此，一旦能够直接访问车辆的总线，任何人都可以读取总线上传输的原始数据，甚至

在今天的车载网络中，大部分数据传输是在没有任何特殊安全措施的情况下进行的。因此，一旦能够直接访问车辆的总线，任何人都可以读取总线上传输的原始数据，甚至可以截获这些数据并且修改后重新发送到总线系统中。加密传输的数据不仅可以确保此信息只能由授权接收方接收，更重要的是它也会使拦截或修改报文变得更加困难。
 

如今的车辆是高度复杂的系统，由诸多传感器和执行器组成，并通过总线系统不断交换数据。在绝大多数情况下，控制器以原始数据的形式传输数据。即使接收节点能对数据进行合理性检查，这些措施对数据可靠性的提升也是有限的。接收节点无法验证数据来自于期望的发送节点还是其他节点，即无法验证数据是否真实。同时，总线上传输的数据也是可以自由访问的，因此可以通过分析总线上传输的原始数据来反推得到其表示的内容。这样的数据传输既不进行保密也不进行认证。
 

在最近几年中，新闻媒体已经报道了多起针对汽车网络的恶意攻击行为。这些报道引发了大家的热烈讨论：恶意攻击是否能够实质上影响车载网络通信？是否可以通过车载的无线终端或者OBD接口影响车的行为？对于这些恶意的攻击，我们有哪些反制手段？
 

因此，加密通信（Cyber Security或Security onboard Communication）受到了越来越多的关注。为了响应汽车行业对数据加密和验证的需求，AUTOSAR组织提出了一系列通信加密和验证的标准。在本文中，我们以目前应用比较广泛的Security onboard Communication为例介绍其实现方式以及CANoe的支持情况。Security onboard Communication简称为SecOC，该模块的主要作用是为总线上传输的数据提供身份验证，它可以有效地检测出数据回放、欺骗以及篡改等攻击手段。
 

从目前已知的攻击手段来看，远程控制一辆汽车的唯一障碍就是如何获取车辆总线的访问权。一旦能够直接访问车内网络，黑客就可以模拟一个合法的数据发送节点来操控整个汽车。使用了SecOC机制后，黑客除了获取总线访问权以外还需要知道发送节点的密钥才能模拟出合法的数据。通过合理的密钥分发机制可以保证密钥不会泄漏给汽车整车厂以外的其他任何人。因此SecOC可以有效地阻止黑客对汽车网络的攻击。
 

在SecOC标准中，AUTOSAR主要基于两种手段来实现数据的真实性和完整性的校验：基于MAC的身份验证和基于Freshness的防重放攻击。
 

数据身份验证
 

MAC（Message Authentication Code）是保障信息完整性和认证的密码学方法之一，其中常作为车载总线加密认证方案的为CMAC（Cipher–based Message Authentication Code）。MAC的作用不是防止有效数据被泄露，而是为了保护数据不会被攻击方篡改，即完成数据来源的认证。如需保护通信数据不被攻击方监听，则报文的有效数据还需要进行额外的加密。
 

在AUTOSAR中，需要加密保护的数据信息被称为AuthenticI-PDU。SecOC模块根据AuthenticI-PDU和密钥使用CMAC算法可以得到Authenticator（即MAC值）。Authenticator和AuthenticI-PDU再加上一些必要的报头即得到SecuredI-PDU，其数据结构如图1所示。发送节点在发送有效数据（AuthenticI-PDU）前，会根据上述方法得到对应的SecuredI-PDU，然后再将SecuredI-PDU发送到总线上。

图1 Secured I-PDU内容结构1
 

CMAC一般用于对称加密，对称加密要求发送节点和接收节点都具有相同的密钥。整车厂可选择在车辆下线刷写程序时静态分配密钥，也可选择使用云端服务器动态地给车辆分配密钥。
 

在接收节点，SecOC模块使用同样的算法和密钥对收到的AuthenticI-PDU计算Authenticator。如果接收节点计算出的Authenticator和SecuredI-PDU中的Authenticator相同，则接收节点认为该数据来源于合法的发送节点。反之，则接收节点认为该PDU来自非法的发送节点，相关数据将会被直接丢弃。
 

另外，由于传统CAN报文每帧最多传输8个字节的数据，如果在传统CAN总线上使用SecOC，那么Authenticator和PDU Header通常会占用掉一半的数据场，这样会导致CAN报文的有效利用率过低。相比之下CANFD有长达64个字节的数据场长度，因此CANFD总线更适合使用SecOC通信。
 

防止重放攻击

在上述的通信机制中，Authenticator的计算依据只包含有效数据和密钥，因此只要有效数据相同，那么Authenticator一定是相同的。这意味着攻击方可以使用重放攻击干扰控制器的正常通信甚至控制车辆的行为。重放攻击指的是攻击者记录下合法数据源和接收节点之间的正常通信数据，并在必要时将记录下的数据重新发送给接收节点从而达到控制接收节点的一种攻击手段。此时接收节点无法检查报文是否来自合法的发送节点。
 

为了避免上述情况，在对AuthenticI-PDU加密过程中，SecOC规定Authenticator计算时还需要加入Freshness Value（新鲜度值），并在SecuredI-PDU中也需要包含FreshnessValue。
 

Freshness Value是一个根据一定逻辑不断更新的数值，Freshness Value的更新方法多种多样，如使用报文计数器、整车各节点统一的时钟作为更新源等方式。若将Freshness Value值结合有效数据和密钥一同作为计算对象计算Authenticator，那么由于每次数据传输Freshness Value值的变化，Authenticator也将随之改变。攻击方在监听到报文后，无法将Authenticator与相应的有效数据匹配，若重复发送带有错误Freshness Value的报文，接收节点将对其丢弃，也就无法形成有效的重放攻击（接入总线后进行的“DoS攻击”不在讨论范围内）。加入Freshness Value的SecuredI-PDU如图2所示：

图2 Secured I-PDU内容结构2
 

对于使用全局时钟的Freshness Value，各节点将周期性的进行时钟同步，Freshness Value随时间戳改变而改变。若使用报文计数器作为Freshness Value的更新方法，其值可由发送节点提供，计数器值仅与报文发送次数相关；也可由专门的Freshness Value管理节点进行同步控制。

我们可设置一个专门的ECU节点负责管理Freshness Value，它周期地发送同步报文至所有发送节点和接收节点；也可使所有的发送节点都作为管理节点，它将发送同步报文至相关接收节点。对于这两种方案，Freshness Value不仅与报文发送次数相关，还将与ECU唤醒、重置、上下电、运行时间等因素相关。
 

在分析Freshness Value的应用逻辑前，我们需要先简单介绍其加密过程。在发送节点，SecOC模块向待发送的AuthenticI-PDU添加认证信息从而创建SecuredI-PDU。认证信息包括Authenticator（e.g.来自CMAC）和Freshness Value。无论Freshness Value是否包含在打包后的SecuredI-PDU中，在生成Authenticator期间都会考虑Freshness Value。
 

在接收节点，SecOC模块通过验证收到的SecuredI-PDU中包含的Authenticator来判断AuthenticI-PDU的来源。为了实现认证，接收节点除了需要AuthenticI-PDU外还需要知道发送节点计算Authenticator时使用的Freshness Value。

图3 基于MAC的报文加密认证过程
 

发送节点在生成SecuredI-PDU的过程中，可以将FreshnessValue完整地包含在其中，而为了提高有效数据的传输空间，通常SecOC模块只截取Freshness Value的低几位添加到SecuredI-PDU中。结合图4，简单说明其构建原理：

图4 接收节点Freshness Value构建流程

• 若SecuredI-PDU包含完整的Freshness Value，则接收节点可直接使用该值作为验证用值进行身份验证。
• 若SecuredI-PDU只包含Freshness Value的低字节部分，则接收节点在接收到SecuredI-PDU后，需要根据从其中提取的部分Freshness Value（新）与上次验证使用的Freshness Value（旧）的低位部分进行大小比较。若Freshness Value（新）较大，则接受此Freshness Value值，与上次验证使用的Freshness Value（旧）高位部分合并作为新的完整Freshness Value，用于本次接收的Authenticator验证计算；若FreshnessValue（新）较小，考虑到可能出现进位的情况，需要将上次验证使用的Freshness Value（旧）高位部分+1后，再与Freshness Value（新）合并，作为新的完整Freshness Value，进行后续验证使用。
• 若接收节点SecOC模块计算的Authenticator与收到的SecuredI-PDU中的Authenticator相同，则验证通过，接收方正常处理SecuredI-PDU中包含的有效数据。反之，则认为本次收到的Secured I-PDU不可信，接收方将直接丢弃它。

实际使用过程中，Freshness Value的更新与构建逻辑也许会非常复杂。参考文献[1]中给出了一种构建逻辑示例，但整车厂在具体应用时通常定义私有的加密和身份认证规范。
 

CANoe对安全加密通信的支持
 

当整车厂在车辆上应用安全通信技术之后，从开发和测试的角度来说，由于传统工具无法支持通信加密和验证功能，整车厂和供应商将无法继续使用传统的测试工具及方法。
 

测试工程师虽可通过二次开发使已有的测试工具支持整车厂提出的加密通信的残余总线仿真以及测试，但将耗费很大的人力和时间，并且难以保证所有工具使用者对通信加密和解密的一致性。
 

CANoe自10.0SP3版本开始陆续集成安全加密通信。CANoe在安装时将附带配置安全加密通信的工具：Security Manager。用户可以在Security Manager中配置不同的密钥来源和加密方案，CANoe可调用Security Manager配置的密钥及加密算法对总线数据自动加密和验证。另外CANoe还附带了相关的故障注入及状态获取的API，方便对ECU的加密通信机制进行验证。

图5 CANoe加密通信实现拓扑逻辑

Security Manager默认附带AUTOSAR推荐的三种加密方案及对公钥基础设施（PKI、TLS1.2）的支持：

• Security according to AUTOSAR with trip-basedfreshness management
• Security according to AUTOSAR with JASPARfreshness management
• Security according to AUTOSAR with time-basedfreshness
• Example certificate configuration for SmartCharging (ISO 15118)
• Public Key Infrastructure for the CANoe TLSChat on Ethernet Demo

在Security Manager中将对Freshness Value、密钥等信息进行配置，配置完成后在CANoe的Simulation标签下的Security Configuration中即可直接看到对应的描述文件更新。测试工程师只需要导入包含加密信息的ARXML数据库，并且关联CANoe自带的SecMgrCANoeClient.dll，即可完成支持测试所需的安全加密通信部分的残余总线仿真环境搭建。

图6 Security Manager配置界面

图7 CANoe中Security配置界面

图8 CANoe实际加密通信运行界面

除AUTOSAR推荐的加密通信方案外，Vector也与众多整车厂达成合作定制整车厂私有的安全加密通信Security Package。通过定制的Security Package可将整车厂的加密通信方案集成在CANoe中，方便整车厂及其供应商够快速构建涉及Cyber Security的ECU测试、仿真环境，保证测试工具的质量。Vector愿与中国整车厂深化合作，在已广泛使用的测试工具CANoe中扩展定制整车厂私有的Security Package，满足应用所需。

参考文献：

[1]Specification of Secure onboard Communication AUTOSAR CP Release 4.4.0