freshness

基于CANoe的SecOC实现

基于CANoe的SecOC实现

在今天的车载⽹络中，⼤部分数据传输是在没有任何特殊安全措施的情况下进⾏的。因此，⼀旦能够直接访问车辆的总线，任何

⼈都可以读取总线上传输的原始数据，甚⾄可以截获这些数据并且修改后重新发送到总线系统中。加密传输的数据不仅可以确保此信息只能由授权接收⽅接收，更重要的是它也会使拦截或修改报⽂变得更加困难。

如今的车辆是⾼度复杂的系统，由诸多传感器和执⾏器组成，并通初一上册英语单词表 过总线系统不断交换数据。在绝⼤多数情况下，控制器以原始

数据的形式传输数据。即使接收节点能对数据进⾏合理性检查，这些措施对数据可靠性的提升也是有限的。接收节点⽆法验证数

据来⾃于期望的发送节点还是其他节点，即⽆法验证数据是否真实。同时，总线上传输的数据也是可以⾃由访问的，因此可以通过分析总线上传输的原始数据来反推得到其表⽰的内容。这样的数据传输既不进⾏保密也不进⾏认证。

在最近⼏年中，新闻媒体已经报道了多起针对汽车⽹络的恶意攻击⾏为。这些报道引发了⼤家的热烈讨论：恶意攻击是否能够实

质上影响车载⽹络通信？是否可以通过车载的⽆线终端或者OBD接⼝影响车的⾏为？对于这些恶意的攻击，我们有哪些反制⼿段？

因此，加密通信（CyberSecurity或SecurityOnboardCommunication）受到了越来越多的关注。为了响应汽车⾏业对数据加密和

验证的需求，AUTOSAR组织提出了⼀系列通信加密和验证的标准。在本⽂中，我们以⽬前应⽤⽐较⼴泛的SecurityOnboard

Communication为例介绍其实现⽅式以及CANoe的⽀持情况。SecurityOnboardCommunication简称为SecOC，该模块的主要作⽤是为总线上传输的数据提供⾝份验证，它可以有效地检测出数据回放、欺骗以及篡改等攻击⼿段。

从⽬前已知的攻击⼿段来看，远程控制⼀辆汽车的唯⼀障碍就是如何获取车辆总线的访问权。⼀旦能够直接访问车内⽹络，⿊客

就可以模拟⼀个合法的数据发送节点来操控整个汽车。使⽤了SecOC机制后，⿊客除了获取总线访问权以外还需要知道发送节点

的密钥才能模拟出合法的数据。脚褪皮是什么原因 通过合理的密钥分发机制可以保证密钥不会泄漏给汽车整车⼚以外的其他任何⼈。因此SecOC可以有效地阻⽌⿊客对汽车⽹络的攻击。

在SecOC标准中，AUTOSAR主要基于两种⼿段来实现数据的真实性和完整性的校验：基于MAC的⾝份验证和基于Freshness的

防重放攻击。数据⾝份验证

MAC（MessageAuthenticationCode）是保障信息完整性和认证的密码学⽅法之⼀，其中常作为车载总线加密认证⽅案的为

CMAC（Cipher–badMessageAuthenticationCode）。MAC的作⽤不是防⽌有效数据被泄露，⽽是为了保护数据不会被攻击⽅篡改，即完成数据来源的认证。如需保护通信数据不被攻击⽅监听，则报⽂的有效数据还需要进⾏额外的加密。

在AUTOSAR中，需要加密保护的数据信息被称为AuthenticI-PDU。SecOC模块根据AuthenticI-PDU和密钥使⽤CMAC算法可以

得到Authenticator（即MAC值）。Authenticator和AuthenticI-PDU再加上⼀些必要的报头即得到SecuredI-PDU，其数据结构如图

1所⽰。发送节点在发送有效数据（AuthenticI-PDU）前，会根据上述⽅法得到对应的SecuredI-PDU，然后再将SecuredI-PDU发送到总线上。

图1SecuredI-PDU内容结构1

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

在接收节点，SecOC模块使⽤同样的算法和密钥对收到的AuthenticI-PDU计算Authenticator。如果接收节点计算出的

Authenticator和SecuredI-PDU中的Authenticator相同，则接收节点认为该数据来源于合法的发送节点。反之，则接收节点认为该

PDU来⾃⾮法的发送节点，相关数据将会被直接丢弃。

另外，由于传统CAN报⽂每帧最多传输8个字节的数据，如果在传统CAN总线上使⽤SecOC，那么Authenticator和PDUHeader通

常会占⽤掉⼀半的数据场，这样会导致CAN报⽂的有效利⽤率过低。相⽐之下CANFD有长达64个字节的数据场长度，因此

CANFD总线更适合使⽤SecOC通信。防⽌重放攻击

在上述的通信机制中，Authenticator的计算依据只包含有效数据和密钥，因此只要有效数据相同，那么Authenticator⼀定是相同

的。这意味着攻击⽅可以使⽤重放攻击⼲扰控制器的正常通信甚⾄控制车辆的⾏为。重放攻击指的是攻击者记录下合法数据源和接收节点之间的正常通信数据，并在必要时将记录下的数据重新发送给接收节点从⽽达到控制接收节点的⼀种攻击⼿段。此时接

收节点⽆法检查报⽂是否来⾃合法的发送节点。

为了避免上述情况，在对AuthenticI-PDU加密过程中，SecOC规定Authenticator计算时还需要加⼊FreshnessValue（新鲜度

值），并在SecuredI-PDU中也需要包含FreshnessValue。

FreshnessValue是⼀个根据⼀定逻辑不断更新的数值，FreshnessValue的更新⽅法多种多样，如使⽤报⽂计数器、整车各节点

统⼀的时钟作为更新源等⽅式。若将FreshnessValue值结合有效数据和密钥⼀同作为计算对象计算Authenticator，那么由于每次

数据传输FreshnessValue值的变化，Authenticator也将随之改变。攻击⽅在监听到报⽂后，⽆法将Authenticator与相应的有效数据匹配，

若重复发送带有错误FreshnessValue的报⽂，接收节点将对其丢弃，也就⽆法形成有效的重放攻击（接⼊总线后进⾏的“DoS攻

击”不在讨论范围内）。加⼊FreshnessValue的SecuredI-PDU如图2所⽰：

图2SecuredI-PDU内容结构2

对于使⽤全局时钟的FreshnessValue，各节点将周期性的进⾏时钟同步，FreshnessValue随时间戳改变⽽改变。若使⽤报⽂计

数器作为Freshness炒酸豆角 Value的更新⽅法，其值可由发送节点提权威的意思 供，计数器值仅与报⽂发送次数相关；也可由专门的Freshness

Value管理节点进⾏同步控制。

我们可设置⼀个专门的ECU节点负责管理FreshnessValue，它周期地发送同步报⽂⾄所有发送节点和接收节点；也可使所有的发

送节点都作为管理节点，它将发送同步报⽂⾄相关接收节点。对于这两种⽅案，FreshnessValue不仅与报⽂发送次数相关，还将

与ECU唤醒、重置、上下电、运⾏时间等因素相关。

在分析FreshnessValue的应⽤逻辑前，我们需要先简单介绍其加密过程。在发送节点，SecOC模块向待发送的AuthenticI-PDU添

加认证信息从⽽创建SecuredI-PDU。认证信息包括Authenticator（e.g.来⾃CMAC）和FreshnessValue。⽆论FreshnessValue

是否包含在打包后的SecuredI-PDU中，在⽣成Authenticator期间都会考虑FreshnessValue。

在接收节点，SecOC模块通过验证收到的SecuredI-PDU中包含的Authenticator来判断AuthenticI-PDU的来源。为了实现认证，接

收节点除了需要AuthenticI-PDU外还需要知道发送节点计算Authenticator时使⽤的FreshnessValue。

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

发送节点在⽣成SecuredI-PDU的过程中，可以将FreshnessValue完整地包含在其中，⽽为了提⾼有效数据的传输空间，通常

SecOC模块只截取FreshnessValue的低⼏位添加到SecuredI-PDU中。结合图4，简单说明其构建原理：

图4接收节点FreshnessValue构建流程

若SecuredI-PDU包含完整的FreshnessValue，则接收节点可直接使⽤该值作为验证⽤值进⾏⾝份验证。

若SecuredI-PDU只包含FreshnessValue的低字节部分，则接收节点在接收到SecuredI-PDU后，需要根据从其中提取的部分

FreshnessValue（新）与上次验证使⽤的FreshnessValue（旧）的低位部分进⾏⼤⼩⽐较。若FreshnessValue（新）较⼤，则接受此

FreshnessValue值，与上次验证使⽤的FreshnessValue（旧）⾼位部分合并作为新的完整FreshnessValue，⽤于本次接收的

Authenticator验证赵炅 计算；若FreshnessValue（新）较

⼩，考虑到可能出现进位的情况，需要将上次验证使⽤的FreshnessValue（旧）⾼位部分+1后，再与FreshnessValue（新）合

并，作为新的完整FreshnessValue，进⾏后续验证使⽤。

若接收节点SecOC模块计算的Authenticator与收到的SecuredI-PDU中的Authenticator相同，则验证通过，接收⽅正常处理

SecuredI-PDU中包含的有效数据。反之，则认为本次收到的SecuredI-PDU不可信，接收⽅将直接丢弃它。

实际使⽤过程中，FreshnessValue的更新与构建逻辑也许会⾮常复杂。参考⽂献[1]中给出了⼀种构建逻辑⽰例，但整车⼚在具体

应⽤时通常定义私有的加密和⾝份认证规范。

CANoe对安全加密通信的⽀持

当整车⼚在车辆上应⽤安全通信技术之后，从开发和测试的⾓度来说，由于传统⼯具⽆法⽀持通信加密和验证功能，整车⼚和供应商将⽆法继续使⽤传统的测试⼯具及⽅法。

测试⼯程师虽可通过⼆次开发使已有的测试⼯具⽀持整车⼚提出的加密通信的残余总线仿真以及测试，但将耗费很⼤的⼈⼒和时间，并且难以保证所有⼯具使⽤者对通信加密和解密的⼀致性。

CANoe⾃10.0SP3版本开始陆续集成安全加密通信。CANoe在安装时将附带配置安全加密通信的⼯具：SecurityManager。⽤户

可以在SecurityManager中配置不同的密钥来源和加密⽅案，CANoe可调⽤SecurityManager配置的密钥及加密算法对总线数据

⾃动加密和验证。另外CANoe还附带了相关的故障注⼊及状态获取的API，⽅便对ECU的加密通信机制进⾏验证。

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

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

SecurityaccordingtoAUTOSARwithtrip-badfreshnessmanagement

SecurityaccordingtoAUTOSARwithJASPARfreshnessmanagement

SecurityaccordingtoAUTOSARwithtime-badfreshness

ExamplecertificateconfigurationforSmartCharging(ISO15118)PublicKeyInfrastructurefortheCANoeTLSChatonEthernetDemo

在SecurityManager中将对FreshnessValue、密钥等信息进⾏配置，配置完成后在CANoe的Simulation标签下的Security

Configuration中即可直接看到对应的描述几个月加辅食 ⽂件更新。测试⼯程师只需要导⼊包含加密信息的ARXML数据库，并且关联CANoe⾃带

的，即可完成⽀持测试所需的安全加密通信部分的残余总线仿真环境搭建。

图6SecurityManager配置界⾯

图7CANoe中Security配置界⾯

图8CANoe实际加密通信运⾏界⾯

除AUTOSAR推荐的加密通信⽅案外，Vector也与众多整车⼚达成合作定制整车⼚私有的安全加密通信SecurityPackage。通过定

制的SecurityPackage可将整车⼚的加密通信⽅案集成在CANoe中，⽅便整车⼚及其供应商够快速构建涉及CyberSecurity的

ECU测试、仿真晋愍帝 环境，保证测试⼯具的质量。Vector愿与中国整车⼚深化合作，在已⼴泛使⽤的测试⼯具CANoe中扩展定制整车

⼚私有的SecurityPackage，满⾜应⽤所需。参考⽂献：

[1]SpecificationofSecureOnboardCommunicationAUTOSARCPRelea4.4.0