E2E 系统，软件，测试人员需要了解

点击上方蓝字谈思实验室

获取更多汽车网络安全资讯

overview

E2E 的保护概念是针对软件在运行时数据交换的保护。运行时数据发生问题的地方可能有很多。

数据链路，外围收发，单片机硬件，传输过程等等等等。外围电路的电池干扰等也都可能会对数据造成影响。这里End 2 End 就是为了检验出数据有没有发生问题。

从数据发送端到接收端，可能是两个ECU 也可以是两个SWC，甚至数据的上下环节都可以做E2E校验。下面以ECU之间的端到端检测例子。

Overview of E2E communication protection between a sender and a receiver

1.1 Pdu 简单介绍

所以这个数据到底是什么？我们有必要了解一下不同位置的数据的名字。因为在保护的过程是需要有针对性的。而且不同的层级保护路径覆盖是不一样的。也就意味着安全等级是可能不一样的。

传统互联网分层的报文与autosar定义的相对比。

应用层——消息

传输层——数据段/报文段(segment) (注：TCP叫TCP报文段，UDP叫UDP数据报,也有人叫UDP段)

网络层——分组、数据包（packet）

链路层——帧（frame）

物理层——P-PDU（bit）

互联网的定义

autosar的定义

从上面图可以看出来，在autosar体系中，只要从驱动出来到了中间件（BSW）统一都叫做PDU. 只是前缀可能不一致。更为具体细致的pdu了解可以见下图，不过和本文关系不大。

现在我们知道了autosar体系中，每个层级的pdu 简单定义。下面我们来从几个角度说E2E 本身的事情。

1.2 保护路径

从过上面不同位置的PDU 的介绍，我们在数据保护的角度就需要找到可能发生数据出问题的路径，然后针对性的保护。

可以说有很多路径都会出现问题。所以我们就需要制定“比较好”的解决方案。

这里比较好可以从成本，安全性，便捷性等方面去考虑。所以这里引出了三种保护方案。

1.3 Frame & pdu

通过前面的学习，我们知道，在autosar体系的内部，所有流动的数据，都可以叫做PDU. 我们以总线报文的收发来作为例子说一下。

1.3.1 pdu分类

说到总线报文和软件内部的PDU 进行保护，那么问题来了，frame 和 pdu的关系呢？注意了 E2E 保护的是什么。保护的是PDU. 可以理解为报文（frame）的一部分。我们来详细说一下 frame， pdu

在Arxml文件中定义的有如下类型：

上海众华律师事务所接受上海探偲商务信息咨询有限公司(以下称“委托人”的委托，指派本律师事务所胡晓光律师，就个别公司涉嫌不正当竞争，严重损害委托人合法权益事宜，作如下声明。

说这个好像也没啥用，我的目的是为了说 frame = pdu*n + 额外信息这里的n >= 1.

也就是说一帧frame 里面可以包含几个pdu的话，这帧报文就可能需要多次保护，因为保护的单位是pdu.

说到这个要说一下现在autosar 里面的定义了。

1.3.2 Autosar定义的PDU

对于普通CAN报文来说，一个message对应一个PDU，对于CANFD报文来说，引入Container PDU和contained I-PDU实现一个message对应多组PDU。

考虑这样做的优势：

不同的contained I-PDU可以映射到不同的Container PDU的不同位置。不仅提高了灵活性，而且也会降低总线负载率。

有了这些知识，我们来聊一下autosar提到的三种E2E 实现方式。

E2E 实现方式

从保护的角度来说，最终的算法无论是callout 还是 wrapper 还是transformer 都是一样的。假设用CRC8 来计算，那么最终给PDU 添加的计算算法都是CRC8, 下面三种方式不一样的指的是路径不一样，和集成方式不一样。我们详细说一说。

2.1 Callout

Callout 指的是com callout. 举个例子，我们有一个pdu从asw 发出来，经过RTE 到达了COM. COM中维护的PDU 配置可以选择callout.

COM 中 PDU 配置界面

所以就是说 PDU 的tx 的内容需要调用一个函数，然后继续往下走。这里面调用的函数就是callout. 我们在这里面去调用E2E 的相关接口。把PDU 内部的数据进行计算，进行更新。

然后从COM 出去之后的数据就是经过了E2E 计算，赋值的数据包了。

从链路上来看，有一段处于空白，就是ASW 到COM 的阶段，这里面是没有保护的，所以这里是有可能发生数据错误的。我们从callout的角度来说，没办法去识别出来。

从下图也可以看出来调用callout的位置。

callout

所以callout 的保护只是发送端的com 到对等接收端的com. 如果com之上发生了错误，这种E2E方法是无法检测到的。所以为了可靠性，我们需要更进一步的去覆盖保护范围。

2.2 Wrapper

说不出来词形容wrapper. 用一个不昏不素来形容吧。wrapper的实现有两种。目的是什么呢。目的就是保护 pdu从swc发出的那一刻一直到对端swc 接收到pdu的时候。

确实挺好的设计，但是为什么说不昏不素呢。autosar 给了两种方式。

2.2.1 Wrapper behind SWC

大家都知道SWC 发送接收 pdu 走的是 RTE_Read,,,,,, 和 RTE_Write,,,,,, 两种实现方式一种是可以说是修改了RTE 的接口，在调用RTE 的接口的时候，先走了一遍 E2ELib. 也就是说在SWC 的下方多了个Wrapper的适配层。如下图所示

保护的内容确实挺好，但是是不是每一个SWC 都需要这样的一个适配层。而且SWC 没办法调到原生的RTE 接口了。

2.2.2 Wrapper within SWC - Transmission Manager

然后呢，又来了个不昏不素的wrapper 实现。

既然想要原生的RTE 接口，那就把这个适配层放在RTE 接口和 SWC 之间。但是问题还是一样，每个SWC 都需要有这么个适配层。如下图，

所以可能就是前面提到的两个缺点，引入了一种新的方式，保护的方式，内容，路径和wrapper 是一致的。只是从系统的角度去实现。

2.3 Transformer

为什么说是系统的角度去实现，因为transformer 在做系统描述的时候，就已经去设计好了这一点。不需要在SWC 的设计阶段去做保护。

可以看得到，在系统描述文件的角度，已经把pdu 和相对应的E2E 都连接好了。最终的实现是在RTE 内部进行实现。

那么问题来了，系统描述怎么知道pdu呢。毕竟在系统层面还是前面提到的frame啊。这里我CSDN 找了个写的比较好的。抄一段来说明一个message 包含多个pdu的概念。

2.3.1 CANFD ContainerPDU定义

ContainerPDU并不是frame，但可以设置ContainerPDU包含frame所有的数据位。ContainerPDU是包含在frame中的。对于一个CANFD-frame,定义如下：

注：若CANFD报文实际只有8字节，那么就和普通报文一样，定义一个I-Signal-PDU就够了，不需要引入容器PDU。

Container-I-PDU定义如下：

Header Type有三种选择:

IpduM支持两种不同的动态Container Pdu的头大小(参见ECUC_IpduM_00183: IpduMContainerHeaderSize):

IPDUM_HEADERTYPE_SHORT, 24位ID, 8位长度

IPDUM_HEADERTYPE_LONG, 32位ID, 32位长度

如果是选择的ShortHeader,那么实际数据位中会有三个byte为ID，一个byte为DLC，8个byte为数据位，在Container-PDU定义页可以选择包含的PDU及设置PDU对应的ID。

2.3.2 CANFD Signal-I-PDU定义

这个Signal-I-PDU就类似普通的CAN报文，里面定义了具体的信号信息，及layout信息。

2.3.3 CANFD实际数据解析

CANFD带Container的报文，实际数据长度为24，包含两个Signal-I-PDU（每个12个byte）

对应的Signal-I-PDU还可以继续展开解析后的信号具体信息

回归主题，有了上面的介绍，Transformer 带来的好处就是无需手动代码。

SWC 自己的接口实现，无需关注自己的read 和 write 是否需要 E2E, 因为他所调用的RTE 接口，已经在系统描述的阶段做好了E2E.

2.3.4 总结

好了这里三种方式说完了。说了半天也没说到具体的计算算法，其实保护算法本身没有什么含量。关键的点在于知道什么时候该用这三种方式，针对性的对我们的系统进行设计。

E2E 保护机制

前面系统的层面去说了E2E 的为什么，和怎么去选择，去设计。这一章我们说一下具体E2E 内部是怎么实现的。为什么不在前面说，因为实现的本身是一样的。

思路是下图这样的。

那么我们从比较书面的方式去解释。

就拿E2E_Profile1A 来举例子

3.1 E2E_Profile1A 概述

上面我手画的保护信息值得就是下图

注意规定好了保护方式后，保护的报文的某些字节需要放什么数据，是已经确定好了的。

最终形成的PDU 如下。

这里问个问题，上图是存在于哪里？

答：上图是被保护的单元，可能共同属于一个frame, 也可能就是一个frame 甚至属于多个frame的集合。

那么我们怎么去实现呢。

3.2 E2E_Profile1A 实现

我们以发送pdu, 来保护这个pdu 为例子说明。

C
Std_ReturnType E2E_P01Protect(const E2E_P01ConfigType* ConfigPtr, E2E_P01ProtectStateType* StatePtr, uint8* DataPtr)

看一下这里面的形参

C
/** @brief Protects the array/buffer to be transmitted using the E2E profile 1.
*This includes checksum calculation, handling of counter and Data ID.
*
*@param ConfigPtr Pointer to static configuration.
*@param StatePtr Pointer to port/data communication state.
*@param DataPtr Pointer to Data to be transmitted.
*
*@return Error code (E2E_E_INPUTERR_NULL || E2E_E_INPUTERR_WRONG || E2E_E_INTERR || E2E_E_OK).
*/

我们需要对pdu进行参数配置。配置的内容如下

这些的信息如果看清楚了前面我手画的信息，就很容易明白了，实际上就是各个参数的位置，长度，以及判断失败的标准。

第二个参数是counter. E2E 是有CRC + Counter的。这个counter 也是需要这个算法本身去维护的。

第三个就是数据本身。

跟着源码一步一步解释

C
Std_ReturnType E2E_P01Protect(const E2E_P01ConfigType* ConfigPtr, E2E_P01ProtectStateType* StatePtr, uint8* DataPtr) {

Std_ReturnType status;
status = E2E_E_OK;
Std_ReturnType returnValue = checkConfigP01(ConfigPtr);

if (E2E_E_OK != returnValue) {
status = returnValue;
}

else if ((StatePtr == NULL_PTR) || (DataPtr == NULL_PTR)) {
status = E2E_E_INPUTERR_NULL;
}

else {
/* Put counter in data*/
if ((ConfigPtr->CounterOffset % 8) == 0) {
DataPtr[ConfigPtr->CounterOffset/8] = (DataPtr[(ConfigPtr->CounterOffset/8)] & 0xF0u) | (StatePtr->Counter & 0x0Fu);
}
else {
DataPtr[ConfigPtr->CounterOffset/8] = (DataPtr[ConfigPtr->CounterOffset/8] & 0x0Fu) | ((StatePtr->Counter<<4) & 0xF0u);
}

/* Put counter in data for E2E_P01_DATAID_NIBBLE */ // ASR4.2.2
if (ConfigPtr->DataIDMode == E2E_P01_DATAID_NIBBLE) {
if ((ConfigPtr->DataIDNibbleOffset % 8) == 0) {
DataPtr[ConfigPtr->DataIDNibbleOffset/8] = (DataPtr[(ConfigPtr->DataIDNibbleOffset/8)] & 0xF0u) | ((uint8)((ConfigPtr->DataID>>8) & 0x0Fu));
}
else {
DataPtr[ConfigPtr->DataIDNibbleOffset/8] = (DataPtr[ConfigPtr->DataIDNibbleOffset/8] & 0x0Fu) | ((uint8)((ConfigPtr->DataID>>4) & 0xF0u));
}
}

/* Calculate CRC */
DataPtr[(ConfigPtr->CRCOffset/8)] = calculateCrcP01(ConfigPtr, StatePtr->Counter, DataPtr);

/* Update counter */
StatePtr->Counter = (StatePtr->Counter+1) % 15;
}

return status;
}

保护数据的前面，需要对Counter进行赋值。前面介绍到了counter的位置是固定的，也是有配置信息，的所以进行了赋值。不过有个需要注意的点就是mode。

E2E_P01DataIDMode = E2E_P01_DATAID_NIBBLE

这个是什么意思呢。

这里的DataID 的一部分，需要放到counter的位置里面去。所以说在更新counter的时候。用到了一部分DataId.

其他的点都很好理解。

这里counter已经更新完毕。我们开始计算CRC

C
uint8 calculateCrcP01(const E2E_P01ConfigType* Config, uint8 Counter, const uint8* Data)

在计算CRC, 需要用到什么。

DataId 需要计算

Counter 需要计算

Data 需要计算。

DataId 如何计算去觉得Config->DataIDMode 的配置。

唯一的数据 ID 用于验证每个传输的安全相关数据元素的身份。

二字节Data ID计算一字节CRC有以下四种包含方式：1. E2E_P01_DATAID_BOTH：CRC中包含两个字节（双ID配置），先低字节后高字节（请参见变体 1A - PRS_E2EProtocol_00227）或 2. E2E_P01_DATAID_ALT：取决于计数器的奇偶校验（交替 ID 配置），包括高字节和低字节（参见变体 1B - PRS_E2EProtocol_00228）。对于偶数计数器值，包括低字节，对于奇数计数器值，包括高字节。3. E2E_P01_DATAID_LOW：只包含低字节，从不使用高字节。这相当于数据 ID（在给定应用进程中）只有 8 位的情况。

这就是计算过程。

那么具体怎么算的呢。这个就是比较标准的做法。不多解释，直接给码

C
uint8 Crc_CalculateCRC8(const uint8* Crc_DataPtr, uint32 Crc_Length, uint8 Crc_StartValue8, boolean Crc_IsFirstCall) {

uint8 crc = 0;/* Default return value if NULL pointer */
#if Crc_8_Mode == CRC_8_TABLE
static const uint8 Crc_8_Tab[256] = {0x0, 0x1d, 0x3a, 0x27, 0x74, 0x69, 0x4e, 0x53,
0xe8, 0xf5, 0xd2, 0xcf, 0x9c, 0x81, 0xa6, 0xbb,
0xcd, 0xd0, 0xf7, 0xea, 0xb9, 0xa4, 0x83, 0x9e,
0x25, 0x38, 0x1f, 0x2, 0x51, 0x4c, 0x6b, 0x76,
0x87, 0x9a, 0xbd, 0xa0, 0xf3, 0xee, 0xc9, 0xd4,
0x6f, 0x72, 0x55, 0x48, 0x1b, 0x6, 0x21, 0x3c,
0x4a, 0x57, 0x70, 0x6d, 0x3e, 0x23, 0x4, 0x19,
0xa2, 0xbf, 0x98, 0x85, 0xd6, 0xcb, 0xec, 0xf1,
0x13, 0xe, 0x29, 0x34, 0x67, 0x7a, 0x5d, 0x40,
0xfb, 0xe6, 0xc1, 0xdc, 0x8f, 0x92, 0xb5, 0xa8,
0xde, 0xc3, 0xe4, 0xf9, 0xaa, 0xb7, 0x90, 0x8d,
0x36, 0x2b, 0xc, 0x11, 0x42, 0x5f, 0x78, 0x65,
0x94, 0x89, 0xae, 0xb3, 0xe0, 0xfd, 0xda, 0xc7,
0x7c, 0x61, 0x46, 0x5b, 0x8, 0x15, 0x32, 0x2f,
0x59, 0x44, 0x63, 0x7e, 0x2d, 0x30, 0x17, 0xa,
0xb1, 0xac, 0x8b, 0x96, 0xc5, 0xd8, 0xff, 0xe2,
0x26, 0x3b, 0x1c, 0x1, 0x52, 0x4f, 0x68, 0x75,
0xce, 0xd3, 0xf4, 0xe9, 0xba, 0xa7, 0x80, 0x9d,
0xeb, 0xf6, 0xd1, 0xcc, 0x9f, 0x82, 0xa5, 0xb8,
0x3, 0x1e, 0x39, 0x24, 0x77, 0x6a, 0x4d, 0x50,
0xa1, 0xbc, 0x9b, 0x86, 0xd5, 0xc8, 0xef, 0xf2,
0x49, 0x54, 0x73, 0x6e, 0x3d, 0x20, 0x7, 0x1a,
0x6c, 0x71, 0x56, 0x4b, 0x18, 0x5, 0x22, 0x3f,
0x84, 0x99, 0xbe, 0xa3, 0xf0, 0xed, 0xca, 0xd7,
0x35, 0x28, 0xf, 0x12, 0x41, 0x5c, 0x7b, 0x66,
0xdd, 0xc0, 0xe7, 0xfa, 0xa9, 0xb4, 0x93, 0x8e,
0xf8, 0xe5, 0xc2, 0xdf, 0x8c, 0x91, 0xb6, 0xab,
0x10, 0xd, 0x2a, 0x37, 0x64, 0x79, 0x5e, 0x43,
0xb2, 0xaf, 0x88, 0x95, 0xc6, 0xdb, 0xfc, 0xe1,
0x5a, 0x47, 0x60, 0x7d, 0x2e, 0x33, 0x14, 0x9,
0x7f, 0x62, 0x45, 0x58, 0xb, 0x16, 0x31, 0x2c,
0x97, 0x8a, 0xad, 0xb0, 0xe3, 0xfe, 0xd9, 0xc4};
#endif

/* @req SWS_BSW_00212 NULL pointer checking */
if (Crc_DataPtr != NULL_PTR) {

crc = (TRUE == Crc_IsFirstCall) ? Crc_8_StartValue : (Crc_StartValue8 ^ Crc_8_Xor);

#if Crc_8_Mode == CRC_8_RUNTIME
crc = calculateCRC8(Crc_DataPtr, Crc_Length, crc, Crc_8_Polynomial);
#elif Crc_8_Mode == CRC_8_TABLE
for (uint32 byte = 0; byte < Crc_Length; byte++) {
crc = Crc_8_Tab[crc ^ *Crc_DataPtr];
Crc_DataPtr++;
}
#endif

/* Only XOR value if any calculation was done */
crc = crc ^ Crc_8_Xor;
}

return crc;
}