前言

在没开发过SecOC之前，总听别人说SecOC有什么新鲜度值、MAC，甚至还需要一条叫什么同步报文的东西。

新鲜度值？技术这么枯燥的东西，居然跟食物这么沾边！

另外，大家都知道，SecOC关键目的也是报文校验嘛，所以MAC我能理解，就类似于CRC校验的Checksum，无非就是算法复杂一些，算出来的结果占用报文位置多一些。

但是，SecOC的同步报文我就不理解了。

我校验我自己，为啥还会跟你 (同步报文) 有关系呀？

如果是CRC校验，我只需要知道我自己这条报文的数据和校验算法就可以了呀！

另外，还有密钥 (Key），这啥呀这是？

如果接触的多一些，还会了解到，SecOC还跟存储、HSM有关。

HSM？这可是到信息安全领域了呀？

如果是用Autosar配置的话，又涉及各种加密模块：SecOC、Csm、CryIf、Crypto

SecOC整这么复杂的吗？

......

朋友们，别慌，其实SecOC的复杂，主要是它涉及到东西有点多，但真正去实现一遍，会发现它其实就是纸老虎，主打一个什么都蹭一点：

比如HSM：实际上只是调用了HSM的一个计算校验值的接口。

又比如存储，不知道的以为多厉害，要存多少东西呢，其实就存了一个东西：ECU上电次数。

好了朋友们，废话不多说，我们一步步去拆解SecOC的完整功能。因为有新鲜度值的存在，SecOC报文才能抵御重放攻击。我们先从CRC校验讲起，然后深入新鲜度值的组成，最后讲解加密算法和Autosar相关配置。

1 CRC校验

在研究SecOC之前，我们先看看我们熟悉的报文CRC校验（或E2E）。

报文CRC校验很简单，它关键就2个东西：Checksun和Counter

举个栗子：一帧报文8个字节。

Checksum放在Byte0，Counter放在Byte1的低四位。

如下图所示：

①所谓Checksum，就是把Byte1～Byte7的数据用CRC校验算法算出一个结果，然后把这个结果放到Byte0。

②所谓Counter，就是发送方每发送一帧报文，这个报文内的Counter值就+1，加到14或15就重新回到0继续重新累加。（需要注意的是，Counter也会加入到Crc校验中）

实际报文数据举例如下：

校验过程简单举例如下（另外，如E2E_Profile01的校验，在Crc校验之前，还会在校验数据前面加入DataID）：

由上可见，报文CRC校验是非常简单的，它东西都是流于报文表面的，只要知道了CRC校验算法就行了。

关于报文CRC，我们稍微总结一下：

1、CRC校验的关键点：Checksum和Counter

2、从校验层面来看，CRC校验报文的结构就两部分：待校验数据+校验结果

2 从CRC报文角度

理解SecOC报文

好了，了解了CRC校验，我们接下来用CRC报文跟SecOC报文做对比，进而理解SecOC报文。

我们先贴一张SecOC的报文图留个印象。

如下图所示，这是一帧16Byte的SecOC报文。

我们从下面两个点入手，让SecOC报文跟CRC报文做对比。

1、首先，SecOC报文中关键的东西也是只有2个：FreshValue、MAC

①SecOC的MAC，Crc的Checksum：你可以理解成同一个东西，都是通过校验算法后，得出来的结果而已。只不过SecOC用的算法高级一点，算出的结果要叫做MAC（Message Authentication Code）。

②SecOC的FreshValue，Crc的Counter：你也可以理解成同一个东西，只不过，Crc的Counter简单一点，只有报文计数功能：从0-14（或15）计数。而FreshValue的功能则多一些，不仅仅只有报文计数功能（至于其它功能，我们先不管）。

2、其次，SecOC报文跟CRC报文结构实际上是一样的，都是：待校验数据+校验结果。

它们的区别在于：

CRC校验报文，它不跟你表面一套背地一套，它表面是什么，那么需要校验的东西就是什么。

而SecOC就有点恶心人了，SecOC报文的“待校验数据”中新鲜度值（FreshValue）是不完整的、“校验结果”也不是完整的，如下图所示：

图中的Secured I-PDU是指总线中的一条报文数据。

可见，报文里面放的中新鲜度值（FreshValue）是截取完整中的一部分，“校验结果”（MAC）也是截取的也是完整的一部分。

所以，概括来说，SecOC就是CRC的加强升级版本罢了。

我们要实现CRC报文时，就2个步骤：

第一步：实现Counter功能（每发一帧Counter+1，达到最大值后重置为0）

第二步：使用CRC算法，校验待校验数据，算出Checksum。

实际上，我们要实现一帧SecOC报文，也是2个步骤：

第一步：获取完整的FreshValue

第二步：使用算法，校验完整的待校验数据，算出MAC。

所以，我们只要把FreshValue和Mac搞明白了，SecOC功能就清楚了。

3 报文重放攻击

SecOC的Freshness Value即新鲜度值。

朋友们，为啥它不叫别的名字，非要叫新鲜度值呢？

其实，就如它的字面意思一样理解：ECU发出的每条SecOC报文要一直保持新鲜，如不新鲜的话，接收方就不收了。

在了解新鲜度值的作用之前，我们又需要掏出CRC报文来说一说了。

对于CRC报文，我们前面说过，CRC报文所有的关键信息都是流于报文表面的。

如下图所示，CRC报文的接收方一直只做了一件固定的事情：

即：把待校验数据经过一下CRC算法计算，再把算出来的校验结果与接收的校验结果做对比，如果对比通过，则认为这条报文是正确的。

朋友们，现假设我们用CAN盒子采集ECU-A发出来的CRC报文。

然后在车上把这个ECU-A去掉，再把我们之前录下来的ECU-A的CRC报文发到车上去。

那么，别的ECU会不会收我们CAN盒子发的这些CAN数据呢？

答案必然是必然会收的。

因为我们录下来CRC报文，Counter是连续且正常累加的，Checksum的值也是对的。

朋友们，这就是所谓的报文重放攻击。

现在我们假设，我们ECU实现了一种升级版的CRC报文：Counter计数没有最大值，每发出一条报文，Counter可以一直累加，永远不会重置回到0。

并且，接收方收到一条报文后，会先判断这条CRC报文的Counter值是否比前面接收的那条大1，如果不是，就不接收这条报文。

这种情况下，如果你再用CAN盒子录下ECU这种升级版的CRC报文，然后进行重放攻击。

结果如何呢？

虽然说，你录制的报文的Checksum肯定是对的，但你录制的这种升级版的CRC报文，它的Counter永远是旧的、永远“不新鲜”。

因此，重放的每一条报文接收方都不会接收。

所以，接收方能防御你的重放攻击。

而SecOC报文的新鲜度值（FreshValue），就是起了这种升级版Counter的一个作用，只不过，新鲜度值并不是简单的报文次数累加。

那么，新鲜度值如果不是简单的报文发送次数累加，它是如何做到每帧发出来的都如此“新鲜”呢？

4 新鲜度值组成结构

新鲜度值（Freshness Value）的完整组成如下图所示：

由图可见，新鲜度值总共由3个部分组成：

①TripCounter ②ResetCounter ③MessageCounter

明明图中还有最后一部分ResetFlag，为啥说实际上是3部分呢？

因为最后面的那个ResetFlag就是指ResetCounter的低位。（具体是最低的多少位，则取决于客户要求，有可能是最低1位，也可能是最低2位）。

可见，新鲜度值的组成是比较复杂的。

因此，需要有个模块专门管理这个新鲜度值，于是，大家常听到的FVM (Freshness Value Management) 就是指这个模块。

这里需要提一嘴的是，FVM并不是Autosar规范中BSW的某个模块（大家可以去官网找找，它是没有专门描述FVM模块的文档的）。

好了，回归正题，接下来，我们看看这3个Counter分别代表什么意思。

1、TripCnt

关于TripCnt，官方解释如下图所示

关于图里面的Master和Slave，我们先不管。

图中简单概括来说即如下几点：

①当TripCnt自身达到最大值时，重设为初始值。(ECU首次上电也会设初始值）

②TripCnt初始值为0或者1。(具体是0还是1，我们后面再讲）

③当ECU唤醒、复位，TripCnt需要+1。

④TripCnt的最大长度是24Bit，即3个Byte。

所以，所谓TripCnt，你可以简单理解为：上电次数计数器。

朋友们，这里其实你就看出来了，TripCnt这玩意在ECU没电的时候，它是需要一直存储起来的。

我们文章前面提到，SecOC会涉及到存储（NvM）功能，实际上存的就是TripCnt。

2、ResetCnt

关于ResetCnt，官方解释如下图所示

①当TripCnt+1时，ResetCnt重设为初始值。

②ResetCnt初始值为0或者1。(具体是0还是1，取决于ECU是Master还是Slave，这个我们后面再讲）

③每固定的一个时间间隔计时达到时(例如每30秒ResetCnt＋1），ResetCnt+1。

④TripCnt的最大长度是24Bit，即3个Byte。

3、MsgCnt

关于MsgCnt，官方解释如下图所示

①当ResetCnt+1或ResetCnt初始化时，MsgCnt设为初始值。

②MsgCnt初始值为0。

③什么时候MsgCnt需要+1？

④TripCnt的最大长度是48Bit，即6个Byte。

当然了，仅从字面意思理解新鲜度值的这3个部分会比较抽象。

所以，我们再看看下面这张图，就很容易理解了。

从上面图中可以看出来，TripCnt、ResetCnt、MsgCnt组成的新鲜度值，永远都是“新鲜”的。

5 鲜度值的长度

关于新鲜度值的长度，Autosar官方规范如下：

简单来说，就是新鲜度值的总长度不能超过64bit，即完整的新鲜度值最大是8Byte。

且在实际项目当中，新鲜度值一般就是8个Byte。

但是，我们前面讲新鲜度值的各个组成时候，提到过每个部分的最大长度，如下图所示：

若按照各个部分的最大长度计算：

TripCnt（24bit）+ ResetCnt（24bit）+ MsgCnt（48bit）+ ResetFlag（2bit）

总长度已经到了10几个Byte了，这是不允许的。

因此，对于不同的项目，新鲜度值各个组成部分的长度是变化的。

完整新鲜度值各个部分长度举例如下图所示：

而在报文中截取的新鲜度值，一般是2个Byte。

……

好了，朋友们，新鲜度值现在被我们搞明白了。

但是，如果到此为止，新鲜度值的功能还是有问题的。

6 SecOC的主从节点

大家想想，如果每个ECU都自己管理自己的新鲜度值，都以自己的新鲜度值为准。

这就会导致一些问题。

就以ResetCnt的计时来说，总线上由数十个ECU，如果每个ECU都自己计时自己的，那么，各个ECU的计时偏差一定是存在的，ECU单次运行的越久，偏差则越大。

因此，SecOC功能中规定，新鲜度值的TripCnt和ResetCnt只由总线中固定1个ECU管理。

而这个管理新鲜度值的TripCnt和ResetCnt的ECU，就是主节点（Master），其它的ECU则是从节点（Slave）。

7 SecOC的同步报文

由于从节点（Slave）不会自己独立管理TripCnt和ResetCnt。

因此，主节点必须通过一种方式告诉从节点当前的TripCnt和ResetCnt，否则从节点搞不到完整的新鲜度值，就要罢工了。

所以，这就是为什么SecOC功能需要专门额外的一条报文：

同步报文，即synchronization message。

同步报文的结构如下：

需要注意的是，同步报文也是跟其它SecOC报文一样，是需要被加密的。

即跟我们前面说的SecOC报文一样，同步报文也是由：待校验数据 + 校验结果组成。

只不过，同步报文中的TripCounter和ResetCounter是完整的，不是截取的。

了解了主从节点也同步报文，此时就可以补一下前面留下的坑了：

关于TripCnt和ResetCnt，Master和Slave的初始值是不一样。

TripCnt和ResetCnt，对于Master ECU，初始值都是1，对于Slave ECU，初始值都是0。

并且，无论主从节点，TripCnt都需要实现下电存储。

SecOC的同步请求报文

如果某个时刻，有个Slave节点出现了BusOff，并且BusOff好几分钟，然后恢复了。

而这个Slave节点恢复之后是需要发送或者接收SecOC报文的，但是Slave节点记录着的新鲜度值早就“不新鲜”了。

这可咋办，Slave节点总不能先罢工，干等着Master下一次发同步报文吧。

因此，Slave节点这时就需要主动去请求Master发同步报文。

这条报文就叫做同步请求报文。

至于同步请求报文的格式，这个就完全看项目了。

但一般情况下，同步报文都是不需要进行加密的。

如同步请求报文格式可以为：CANID为0x450，报文长度固定为8，Byte0固定为0x88，Byte1~Byte7固定为0x00。

当Master节点收到同步请求时，立即向外发送同步报文，且ResetCnt+1。

8 SecOC报文类型

好了，到目前为止，SecOC功能所有的报文我们都接触了一遍。

我们稍微整理一下。

首先，现在有一条原始报文，里面只有普通的信号，如点火信号状态。

这条报文如果要实现SecOC功能，那么这条报文就需要预留有新鲜度值和MAC的位置。有了这些之后，这条报文就叫做：安全报文（Secured-I-PDU）

对于新鲜度值相关功能的报文。

Master节点发出，Slave节点接收的，叫做：同步报文

Slave节点发出，Master节点接收的，叫做：同步请求报文

因此，一个完整的SecOC功能，这3种类型的报文是必不可少的。

9 AES-128-CMAC

算法在SecOC中的应用

首先我们要知道，AES-128-CMAC算法是一个固定的标准算法。

因此，当我们开发完SecOC功能要测试验证，就可以使用CANoe工具写测试脚本，在CAPL脚本中直接调用CANoe自带的AES-128-CMAC算法接口函数。

好了，我们看看AES-128-CMAC算法的接口：

可以看到，总共有4个参数：①Key，②InputData，③DataLen，④CmacOut

1、Key：密钥，听着高大上，实际就是一串固定16Byte的数据。

在实际项目中，一般车企都会对这个Key又加一层额外操作：

比如车企会要求，最终的Key是通过原始Key、VIN码以及另外的算法，算出来的。（具体什么算法，我们不用管，车企会直接给算法代码）

通过这样的方式，使得Key更加复杂、强度更高。

2、InputData：输入数据，就是会参与CMAC计算的数据。

①对于SecOC的安全报文来说，InputData组成如下：

②对于SecOC的同步报文来说，InputData组成如下：

需要注意的是，DataID一般是报文的CANID。

3、DataLen：即数据长度，它指的是InputData的总长度。

4、CmacOut：即AES-128-CMAC计算输出结果。

需要注意的是，这个算法的计算结果长度固定是16Byte。

10 对称加密与非对称加密

在了解了AES-128-CMAC算法的参数的Key之后。

我们就能分辨网上常看到的什么对称加密、非对称加密的意思了。

所谓对称加密：就是加密和解密用同一把密钥。

对于AES-128-CMAC算法来说，加密和解密，就必须使用同一个Key，否则两边计算出来的CMAC就对不上了。

所以AES-128-CMAC算法就是对称加密。

如下图所示，确实很对称对吧。

对于什么是非对称加密。

如果你用过git的ssh密钥，就知道有个私钥和公钥。

对于Git的私钥，我们就保存在自己的电脑，公钥就传到 Git服务器。

这就是非对称加密，具体细节，我们就不展开研究了。

11 Autosar架构中

SecOC涉及的相关模块

以CAN总线报文为例。

对于普通无SecOC功能的应用报文，我们知道BSW的相关模块链路非常简单：

而对于有SecOC功能的应用报文，它的BSW相关链路是这样的：

对于完全没接触过SecOC的工程师，第一次看SecOC功能的链路图可能就会被吓到了：

“SecOC功能也太复杂了吧，涉及这么多加密的模块，这怎么搞！”

朋友们，不要慌，到现在为止，我们现在已经抓住了SecOC的本质了：获取完整新鲜度值、算出CMAC。

因此，理解上图的那些模块就很简单：

①获取完整新鲜度值：由FVM模块实现，这个是SWC模块实现的，也就是完全由软件工程师手写代码去实现的，这个没啥问题。

②CMAC：由加密相关模块实现，也就是说，对于SecOC功能，图中右边这么多加密相关的模块，目的只有一个：计算CMAC。（当然了，如果深入研究加密相关模块、涉及HSM，就会稍微复杂一些，这里我们就不展开了）

12 SecOC报文

相关Autosar配置

我们以如下这条报文举例：

该报文的相关SecOC功能配置项如下：

关键配置如下：

SecOCAuthInfoTxLength：即在报文截取的CMAC长度，从报文Layout图可见，CMAC截取的长度是8Byte（64bit）

SecOCFreshnessValueLength：新鲜度值的完整长度，此处我们的是8Byte（64bit）

SecOCFreshnessValueTxLength：即在报文截取的新鲜度值长度，从报文Layout图可见，CMAC截取的长度是2Byte（16bit）

SecOCSecuredTxPduLength：报文中安全数据长度，如报文Layout所示，长度为6Byte

SecOC报文在各个模块中的长度

最后，需要注意的是，安全报文在各个模块的长度。

此处我们以发送报文为例。

由于新鲜度值、CMAC是在SecOC模块进行处理并组装至CAN报文中的。

因此，在Com模块，报文的长度是6Byte，即不包含新鲜度值、CMAC的数据。

SecOC报文在各个模块长度如下图所示。

13 SecOC报文

CAN总线数据举例

如下图所示，为某条安全报文。

报文中从左到右依次为：

安全数据长度6Byte、报文中截取的新鲜度值长度2Byte、报文中截取的CMAC8Byte：

这里我们解析一下截取的新鲜度值数据：

解析截取的新鲜度值的MsgCnt（低14Bit）、ResetCnt（低2Bit）如下：

可见，MsgCnt是不断在累加的，且当ResetCnt+1后，MsgCnt又会从0开始重新计数。

14 结 语

好了，朋友们，当你看到这里，相信关于整个SecOC的功能你基本明白得七七八八了。

当然了，当你真正去开发SecOC功能，还是会有很多细节我们这里没有提及。

但是，相信在了解了我们所讲的这些内容后，剩余的SecOC功能开发细节至少不会让你一头雾水了。