网络安全| 关于AUTOSAR E2E及测试开发实践

原创北汇蒋露张恒北汇信息

前言

上期文章“聊聊网络安全的5W1H”对网络安全知识体系和技术脉络做了深入浅出的介绍，提到AUTOSAR所定义的网络和通信安全相关的技术，本期我们将介绍其中的E2E策略（严格来说属于Safety的范围），并分享在项目中的测试实践。

E2E概念介绍

E2E是什么

E2E全称为End to End，代表的是AUTOSAR中的一种数据保护机制，从名称中可以看出，这是一个终端到终端的逻辑。那么这里的终端是指ECU吗？

答案是否定的。在AUTOSAR的架构中，最上层为包含SW-C（Software Component）的应用层，类似于手机应用程序中的各种APP。对于E2E来说，数据的传递不是针对ECU到ECU的层级而是SW-C到SW-C层级。

图1 AUTOSAR软件概貌

在车载网络中，信息交换通常是从一个ECU发送信号，另一个ECU接收信号。对E2E而言，通常是从源SW-C生成信号，经过RTE（Run-Time Environment）、BSW（Basic Software）并在物理总线上传输后到达目标SW-C。

在这个过程中，信号的传递可能由于一些故障情况（比如软件运行错误）无法到达目标终端，或是信号本身被干扰/损坏，尤其对于安全相关的信号（车速、档位、车辆/电源模式等）来说，这种情况会带来很大的隐患。而E2E正是通过一些机制，使发送终端和接收终端的数据保持一致，保证信息的完整性。

图2 错误来源的示意

E2E的适用范围

E2E可适用于各种总线通信，以北汇信息参与的项目为例，E2E机制已应用于CAN、CAN FD、LIN、FlexRay总线通信中，对于以太网当然可应用E2E机制，但是需考虑和留意如下的问题：

不同于上文介绍的发送端/接收端的通信模式，以太网中将会广泛应用基于SoA的客户端/服务器的通信模式，将涉及诸如客户端及其操作的序列号变化、超时检测等问题，对此应该如何定义E2E机制？
在TSN网络中Follow_Up报文每次经过交换机后都会更新其内容，此时的E2E机制又应该做何种变化？

关于E2E与SecOC

除了E2E保护机制外，AUTOSAR还定义了针对PDU（Protocol Data Unit）的保护策略，即SecOC（Secure Onboard Communication）。

关于SecOC更多细节后续将有专门文章介绍，先对SecOC与E2E两者进行简要对比如下图3，供大家参考。

图3 SecOC与E2E简要对比图

E2E的机制介绍

E2E策略的整体思路是CRC校验和计数，在原始数据的基础上增加控制段形成E2E报头，AUTOSAR提供了多种E2E的配置来适用各种场景，本文以E2E Profile 1这种配置为例来说明。

图4 E2E报头

在E2E Profile 1中，发送到RTE的数据需要包含3个部分：

其中Counter为计数器，每发送一次值就增加；CRC按照E2E Profile 1的计算方式，对Data ID、Counter和原数据进行CRC计算，并将结果填入CRC字节：

图5 E2E Profile 1配置示意图

Data ID是一个预先定义的密钥，不会被发送到总线上。整个E2E的过程为：

图6 E2E流程示例

当然，与数据发送方相比，数据接收方需要处理的内容就显得更加复杂。包含序列丢失处理、序列无效处理、序列重复处理、超时处理等。

图7 E2E接收行为示例

E2E本身有很大的灵活性，除了本文示例外（本文示例使用了E2E Protection Wrapper），还有多种使用方式（比如COM E2E Callouts），感兴趣的小伙伴可以参考AUTOSAR规范。

E2E测试实践

对于网络中的ECU而言，E2E测试包含E2E发送测试和E2E接收测试。

典型的E2E发送测试是将ECU发送的包含E2E信息的数据源按照E2E Profile 1的方式，计算一个CRC，如果与原始发送的CRC相等则验证通过，反之亦然。
E2E接收测试包括正向和逆向测试，逆向测试主要是验证ECU在接收到错误的E2E时的行为（如丢弃该数据信息，记录E2E错误DTC等）以及再次接收到正确E2E时的行为测试。此类测试需软件层面的支持，比如定义相关的DTC方可实现黑盒测试，或提供相关的内部数据的访问接口和方法，或与功能测试相结合，总之依赖特定的条件。

本文将主要介绍E2E发送测试。以CAN总线为例，当接收到总线上发送的一帧包含E2E信息的报文时，首先获取该E2E对应的所有信号的值，然后将信号组成数据位流进行CRC计算，在这个过程需要注意以下几点：