标签: DoIP

背景 车载以太网系列 文章 “当DoIP遇上TLS 当DoIP遇上TLS-面包板社区 (eet-china.com) ”介绍了新版ISO 13400 - 2规范变化点 、TLS简介以及CANoe TLS demo工程的数据流 ，其中TLS DoIP 数据流分为 4 部分，1 .建立TCP连接 ，2 .TLS握手流程 ，3 .路由激活 ，4 .诊断数据交互 。接下来小编结合北汇已执行的项目，分享下TLS DoIP 测试开发经验。 图 1 简易TLS握手流程 TLS DoIP测试实践 1 . 测试 配置 TLS协议可以为信息传输提供三个基本保证：加密、身份验证、数据完整性，上篇文章介绍过TLS借助密码学中的非对称加密和对称加密来协商秘钥以及应用数据加密，防止数据泄露以及篡改，通过证书机制做身份验证，防止第三方伪造通讯节点。在执行测试前需要确认OEM对控制器TLS的配置要求，比如认证类型、支持的密码套件等信息。Vector CANoe软件的Security Manager模块具备安全相关测试配置功能 ， 测试人员基于此模块完成证书 、 密码套件配置工作 。 图 2 CANoe安全管理配置界面 依据被测控制器的特性，为测试模块选择相应的安全配置文件，完成测试配置。 图3：配置文件的选择 2 . 测试仿真节点开发 为实现 TLS DoIP 的测试，需开发仿真节点以实现与 DUT 的交互，如下为针对 某控制器 TLS DoIP 交互过程及交互数据流。 TCP连接 ：使用3 496端口号与控制器建立TCP连接 TLS握手流程 ：采用双向认证方案的TLS握手流程 DoIP路由激活数据 ：TCP连接建立后，两秒内完成路由激活（加密传输-测试模块知晓协商过的秘钥，故可解析DoIP数据） 诊断数据 ：诊断数据加密传输 图 4 TLS DoIP数据流 1 图 5 TLS DoIP数据流2 3.TLS DoIP 测试内容和测试工程 测试内容包括TLS 流程测试 、证书 测试 、协议版本测试、 密码套件测试 、 端口号测试等等 ，其测试工程北汇通过Vector C AN oe. CAPL 结合其他第三方编程语言定制实现。 如下为一典型测试用例的示例，该用例是为了完成TLS DoIP正向流程 测试。 图6 测试用例示例 如下为TLS DoIP测试工程和测试报告的示例。 图7 TLS DoIP测试工程 图8 某控制器TLS DoIP诊断报文 测试报告 总结 北汇信息时刻关注汽车电子测试的前沿技术，包括DDS、TSN、OTA、 自驾和网 联等领域，为客户 提供 完整交钥匙工程服务，包括：设计需求规范的审核完善、测试 规范 开发、 测试脚本 定制开发和测试实施服务。目前，北汇信息已经完成TLS DoIP测试方案的 落地， 感兴趣的 朋友请联系 我们。 参考文献 ： 【1】ISO 13400 - 2

DoIP简介 以太网最早由BMW引入车内，其应用场景就是刷写，满足类似HMI的地图数据、液晶仪表等软件数据更新，感兴趣的可查阅Thomas Konigseder 的 Automotive Ethernet 书中的介绍。由于其突出的特性，而后得到主要OEM的推崇和更广泛的应用，遂开始了国际标准化（汽车行业一直以来的“套路”）。 DoIP全称：Diagnostic communication over Internet Protocol。顾名思义，通过以太网来实现车辆诊断，其对应的国际标准为ISO 13400，其定义了DoIP协议（基于UDS）并描述了外部测试设备与车辆进行诊断数据交互的流程。 下图为DoIP及基于以太网诊断在OSI 7层模型中及在“7层之外”的“角色”和“位置”。 图1 DoIP及以太网诊断规范框架 DoIP协议要点简述 DoIP报文 DoIP报文在以太网报文中的位置如下图。 图2 DoIP报文在以太网报文中的位置示意图 DoIP报文分为三大类：节点管理类、车辆信息类、诊断类。 节点管理类主要包括报头处理流程、车辆信息获取（如EID、GID、VIN等）、路由激活流程（包括授权以及确认功能）、TCP_DATA socket处理流程。 图3 节点管理类DoIP报文 车辆信息类主要包括获取DoIP实体状态信息、车辆电源模式信息。 图4 车辆信息类DoIP报文 诊断类主要包括诊断报文处理流程以及UDS数据交互。 图5 诊断类DoIP报文示 DoIP会话流程 关闭TCP_DATA socket。 图6 DoIP会话流程 图片来源：ISO 13400-2:Road vehicles - Diagnostic communication over Internet Protocol 边缘和内部节点差异 关于DoIP协议，ISO 13400规范做了框架性的定义，但OEM会依据整车功能需求自定义细节内容，同时会区分边缘节点和内部以太网节点，聊到此处有的小伙伴可能会有疑问，“以太网节点为何要区分边缘节点和内部节点？两者是否可以支持完整的DoIP协议？”接下来我们通过实例讨论边缘节点和内部节点在DoIP报文配置方面的差别。 问题一：内部节点需要支持诊断报文肯定应答(0x8002)么？ 分析：当Tester向内部节点发送诊断请求时，首先边缘节点会先向Tester发送0x8002报文，如果内部节点也支持0x8002报文，随后边缘节点又再一次转发内部节点发送的0x8002报文和诊断应答报文到Tester。 根据DoIP协议，Tester完成诊断报文发送后会等待0x8002报文同时开启P6Client定时器来接收诊断应答报文(暂时不考虑0x8003)。所以如果内部节点支持0x8002报文从系统设计方面考虑不符合DoIP协议，而且会导致以太网系统级诊断刷写测试P6Client参数超时。 图7 内部节点支持0x8002报文交互过程示例 问题二，笔者抛块砖：不同类型节点对路由激活报文该采用何种策略？ 有兴趣的，可就此类技术细节约聊，同样此话题可扩展包括DoIP其他报文针对边缘和内部节点不同的配置和支持方案，当然还有区别最明显的对硬线激活特性支持的差异。 万变不离其宗，以太网节点DoIP报文的配置要服务于整车功能,这部分更应该是OEM设计工程师需要从应用场景角度考虑而进行设计的。仁者见仁,智者见智,在不同拓扑、不同需求情况下设计方案也应当有所差异。 DoIP及以太网诊断测试方案和实践 DoIP及以太网诊断测试实现可以分层来介绍,当然在各层中OEM会在ISO标准需求的基础上做自定义开发。 针对ISO 13400-2的测试 测试内容包括DoIP报文格式、DoIP流程以及DoIP时间参数等，其测试脚本和测试工程通过CANoe（CAPL）定制实现。 图8 基于CANoe开发的部分测试项及测试脚本 图9 某控制器Alive_Check_Message测试报告 针对ISO 13400-3的测试 测试内容包括激活使能线等相关的测试，测试脚本同样通过CANoe（CAPL）开发实现，测试环境需借助于Vector的VT板卡，如VT2004实现硬线的仿真。 针对ISO 14229-1/-5的测试 可基于CANoe Option DiVa可实现，DiVa是Vector公司一款便捷、高效的诊断测试用例生成工具，使用DiVa实现UDSonCAN的测试大家都比较熟悉，那么对于以太网UDS测试DiVa是否也可以覆盖？答案是肯定的。DiVa可基于DoIP协议（ISO 13400）生成以太网UDS测试工程，即按照标准DoIP流程与ECU进行诊断数据交互。 图10 基于DiVa的以太网UDS测试工程 介绍到这里小伙伴们可能会有疑问，对于非标准DoIP协议的以太网节点是否也可用DiVa覆盖其测试需求？比如笔者曾遇到的OEM所定义的以太网节点仅支持DoIP净荷类型中特定的报文，或者以太网节点仅支持OEM自定义格式的诊断报文等情形。 总结 接着上面的问题，对于支持非标准DoIP协议的以太网节点UDS测试需做一 定的定制开发方可。另外，DiVa自动生成的UDS测试工程是否直接满足边缘和内部两种类型节点的测试需求呢，该如何适配？这也是笔者在项目实践过程中遇到的一些工程问题，还曾“遭遇”在DoIP测试过程中由于ARP配置而引起的“异象”以及端口固定等各类疑难杂症！限于篇幅，不做一一介绍了，感兴趣的小伙伴约起来吧！ 北汇信息已为多家主流OEM完成DoIP、以太网诊断、刷写测试相关的项目，为客户提供完整交钥匙工程服务，包括： 设计需求规范的审核完善 测试规范开发 测试脚本定制开发和测试实施服务 车载以太网技术扩散越来越快，相关测试验证工作及对测试验证深度、广度的要求也备受重视，所以实践实战的经验积累、对系统宏观层面的了解也更为关键，北汇信息希望与各位共同进步，价值分享。

当DoIP遇上TLS 金陵汤包 DoIP 规范 距离上一篇DoIP文章“DoIP测试开发实践”已经过去两年了，当时使用的规范是ISO 13400-2 2012版，随后新版规范13400-2 2019版正式释放，不过时至今日大部分OEM的以太网诊断刷写规范依然参考2012版本。DoIP协议大家已经非常熟悉，虽然对于以太网内部节点的DoIP策略各个主机厂需求不尽相同（比如有的要求内部节点支持部分DoIP报文、有的要求支持完整DoIP协议，还有的要求支持自定义DoIP报文），但对于边缘节点的要求基本符合2012版DoIP规范，那么，2019版的DoIP规范有什么特殊定义呢？ ISO13400-2 2019 版 2019版规范相较于2012版主要的变化点： （1）更新文档结构 ：增加“内部诊断仪“概念，完善相关细节描述（如Tester可使用Alive Check Response报文来维持DoIP session）等。 （2）增加TLS（TransportLayer Security）内容 。 本文将主要介绍TLS协议，篇幅有限，具体的协议细节建议参考相关标准： ▲TLS1.2IETF RFC 5246 ▲TLS1.3IETF RFC 8446 TLS 简介 TLSTransport Layer Security，由于基于TCP协议传输数据时，数据包可能被其他人截取、篡改，这给网络信息安全带来了极大的挑战。基于此问题，网景公司提出SSL协议，IETF在标准化SSL协议时，将其命名为TLS，也就是说TLS属于SSL升级版。TLS借助密码学中的非对称加密和对称加密来协商密钥以及应用数据加密，防止数据泄露以及篡改，通过证书机制做身份验证，防止第三方伪造通信节点。 TLS 组成 TLS协议是由TLS记录协议（TLS record Protocol）和TLS握手协议（TLS handshake protocol）两层协议组成的，其中TLS握手协议又分为握手协议、密码规格变更协议、警告协议、应用数据协议。 握手协议负责在客户端和服务器之间协商密码算法和共享密钥，包括证书的认证操作。密码规格变更协议负责向通信对象传达变更密码方式的信号，警告协议负责在发生错误时将错误传达给对方，应用数据协议将应用数据传达给通信对象的协议，TLS记录协议负责消息的压缩、加密以及数据的认证。 基于TLS的DoIP会话流程 对于支持基于TLS的节点，DoIP安全会话流程如下图： 出自ISO 13400-22019版 （1）完成物理连接以及车辆发现流程 （2）建立TCP连接（注*端口号3496） （3）完成TLS握手流程 （4）路由激活、诊断数据交互(已被加密) 基于TLS的DoIP数据流 使用Vector公司CANoe软件仿真基于TLS的DoIP通信，数据流如下图： 对于支持安全DoIP会话的节点，由于诊断仪跳过TLS握手协议，直接发送路由激活请求，DoIP节点返回路由激活应答码为0x07的路由激活响应报文，路由激活失败，如下图： 将数据保存重新导入CANoe回访数据，由于CANoe未知对称加密密钥，所以无法解析数据。 基于TLS的DoIP测试要点 针对支持TLS的DoIP节点，相应测试用例也需同步增加，如TLS-DoIP流程正向测试、TLS-DoIP端口号测试、握手协议跳过测试，逆向测试等，该部分测试就基于CANoe的CAPL脚本定制开发实现。 总结与思考 鉴于TLS协议的安全性、可识别性和一致性，TLS目前在IT行业被广泛使用，特别是HTTPS协议。在汽车行业，基于TLS的DoIP协议后期可能更多应用于OTA以及无线刷写场景，以增加数据传输的安全性。 但是DoIP引入TLS有些问题仍需要考虑，首先，诊断内容需要经过对称加密算法加密，即只能被通信双方解析，第三方想要解析数据必须知晓二者之间的密钥，也就是说测试工程师若分析一段基于TLS的DoIP数据，必须从诊断仪获取密钥，所以获取密钥的方式以及便利性需要评估。其次，诊断数据传输基于TCP协议，ISO 14229-5规范定义编程模式的进入或退出以及ECUReset会导致TCP重连，对于诊断协议测试，控制器可能会不断地进入退出编程模式以及执行ECU HardReset，在此期间诊断仪和控制器间的密钥可能会随之变化，那么后期测试分析如何解析整段数据？当然以上只是个人看法，网络安全重要性不言而喻，新特性的引入需结合应用场景迭代、优化。为支持OTA和远程诊断，对应技术的IT化趋势比较明显，谁将勇立潮头，且看风云变幻。 诊断技术的IT化 图片来源：网络 北汇信息时刻关注汽车电子的前沿技术，提供交钥匙的测试解决方案，包括：设计需求规范的审核、测试规范/用例开发、测试脚本/工程的实现和测试实施服务。 注：文中部分图片来源于Vector。