当DoIP遇上TLS-电子发烧友网

DoIP规范

距离上一篇DoIP文章“DoIP测试开发实践”已经过去两年了，当时使用的规范是ISO 13400-2 2012版，随后新版规范13400-2 2019版正式释放，不过时至今日大部分OEM的以太网诊断刷写规范依然参考2012版本。DoIP协议大家已经非常熟悉，虽然对于以太网内部节点的DoIP策略各个主机厂需求不尽相同（比如有的要求内部节点支持部分DoIP报文、有的要求支持完整DoIP协议，还有的要求支持自定义DoIP报文），但对于边缘节点的要求基本符合2012版DoIP规范，那么，2019版的DoIP规范有什么特殊定义呢？

ISO 13400-2 2019版

2019版规范相较于2012版主要的变化点：

（1）更新文档结构：增加“内部诊断仪“概念，完善相关细节描述（如Tester可使用Alive Check Response报文来维持DoIP session）等。

（2）增加TLS（Transport Layer Security）内容。

本文将主要介绍TLS协议，篇幅有限，具体的协议细节建议参考相关标准：

▲TLS1.2 IETF RFC 5246

▲TLS1.3 IETF RFC 8446

TLS简介

TLS Transport 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-2 2019版

（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化趋势比较明显，谁将勇立潮头，且看风云变幻。