测试工具视角下，车载对外重要接口如何保障网络安全

以前车是独立系统，相对安全，外界很难受到相应的攻击。但是随着联网、车载OBD、智能充电、OTA系统、蓝牙无线的引入，整个系统已经不再安全，需要采用相应的技术来保证车辆的安全。但是在保证整个技术落地的过程中，需要有相应的工具进行相应的开发和测试。以前在整个系统的开发过程中，相关数据都是“明码”，没有加密，所以任何工具都可以获取相关数据，读写相应的数据，还可以做模拟和回放。然而，系统通信数据加密后，许多功能用常规工具无法满足。比如数据加密的时候，简单的数据分析会遇到很大的麻烦。然而，并不是所有的工具都支持加密系统的开发和测试。

现在所有使用的开发和测试工具都必须考虑产品面临相关问题时如何支持安全相关的应用，尤其是供应商，因为供应商在不同的通信应用层会面对不同OEM的不同项目，每个项目的每个通信层都依赖不同的加密系统进行加密。供应商不可能在每个OEM的每个项目中都采购和学习全新的工具链。作为知名的车载网络安全供应商，Victor在网络安全工具的开发和测试方面也有很多独特的经验。

带TLS的DoIP

随着以太网相关技术的引入，在诊断系统中使用DoIP进行相应的诊断应用。但出于安全诊断的考虑，2019年将发布新版本的ISO13400-2，该版本定义的DoIP可以通过TLS实现安全诊断。按照具体流程，整个通信过程中，车辆连接后会先通过端口13400激活路由，当收到07拒绝响应时，表示需要TLS进行安全诊断。然后测试设备发送消息关闭传统DoIP的13400端口服务，然后打开支持TLS的3496端口。然后建立TLS“握手”，实现诊断设备与ECU或相应的车辆安全钥匙或证书之间的安全通信连接。最后，TLS协议被再次激活，然后整个诊断服务处理将在TLS协议下传输。

诊断完成后，需要相应关闭3496端口。在整个过程中，我们可以看到数据是通过TLS加密的，经过相应的开发、调试和测试，需要工具来支持DoIP的TLS协议。对于CANoe来说，嵌入式功能可以完全支持2019版的真实DoIP协议。同时可以在CANoe中配置和处理相关的DoIP配置，也可以开发TLS本身的协议测试。其他相应的矢量工具，如Viktor的画笔工具vFlash和诊断仪Indigo，都是根据同样的思路和原理实现TLS的DoIP，最新版本是可以支持DoIP的TLS协议。

出口的新能源汽车面临ISO15118的加密充电。

车辆互联时，还有一个重要的接口，就是充电接口。在计费部分，目前国内相应的计费处理是基于GB/T 27930协议。但我相信国内的新能源汽车公司都是做整车出口业务的，所以在欧美的充电基础设施体系下，不得不面对相应充电的需求。在欧洲收费系统下，需要面对一个重要的规范:ISO15118。这个协议本身一直在做相应的迭代更新，很明显在整个系统中，随着15118-20协议新版本的发布，TLS是一个强制要求。

也就是说，在收费方面，协议上也有相应的加密。在开发过程和调试过程中，OEM和供应商都要依靠相应的工具来解决:ISO15118支持这个协议吗？在工具和设备方面，另一个重要的考虑因素将是ISO15118-2和刚才提到的-20所需的TLS零件是否能得到完全支持。

为了整个发展……收费系统的t流程，收费部分与实际传统开发流程相同。会有相应的虚拟SiL原型、A/B样车、C样车和量产车。在产品开发初期，需要模拟充电桩(EVSE)或者车辆(EV)，因为EV和EVSE之间的通信是用TLS加密通信的，模拟充电桩本身也要能支持TLS协议。实际充电后期，连接真实桩进行相应的数据传输，数据里面也有TLS协议。一方面数据可以收集，另一方面解密工作需要工具来处理。

无论是以太网还是PLC，通信时都可以在CANoe中加密解密数据。测试完成后，系统的ECU与车辆集成。整合后会处理车辆和相应设备的数据，里面也会处理证书，这是TLS中的一些应用处理。在CANoe中，PKI及其对应的证书可以通过安全管理器模块进行处理。

在实际测量中，还会提供一个经济的方案，方便大家提取实车和安装之间的对应数据，做相关分析。比如这是真车，真桩，上面的通讯数据是通过PLC通讯的，数据是加密的，所以充电时异常数据的采集和分析会是个问题。在这里，Victor将为PLC通信提供“监控”设备，以监控PLC数据，数据将传输到CANoe。和图中的物理系统一样，Vector通过耦合直接从充电中捕获相应的数据，而不会破坏相应的真实充电的线缆。在解密方面，Victor在工具中提供了多种方式来解密相应的数据。当然具体解密需要看实际环境和获取的信息。在工具层面，如何在CANoe中实现相关的解密处理。当然，对于这里提供的四种解密TLS通信的方式，当然也适用于DoIP和刚才提到的一些/IP，这些都可以在CANoe中实现。

车联网-V2X的安全性

在车辆外部互联接口方面，尤其是V2X，在国内，我们看到很多实验区，包括三跨、四跨，也在进行相应的开发和应用。整个系统内部:在整个链路中，无论是车辆与车辆之间的通信，还是车辆与其他设备之间的通信，V2X的数据都可以通过PC5进行传输，传输的数据会用相应的证书进行加密。并且相应的数据进入车内后，车端的通信应用OEM车载安全技术对数据进行相应的加密。

所以在车联网的V2X方面，选择工具也有很多需要考虑的条件。当然，很多供应商和OEM不仅会面对中国的项目，还会支持全球的项目。在安全方面，中国的V2X安全规范仍是草案版本，但欧美的安全规范ETSI TS 103 097和IEEE 1602.2处于发布状态。在工具选择上，必须能够支撑相应国家的安全。还需要支持各种主机厂的车载通信的安全加密和解密。此外，这些工具需要支持传统车辆通信开发和测试的要求，如arxml、用于诊断的cdd以及用于车辆通信的1000/100BASE-T1和CAN FD。实现V2X安全的处理需要从长远角度规划相应的工具和设备。

CANoe Option Car2X模块，Car2X的插件，在安全测试工具CANoe中提供。其中，提供2D场景设计功能，实现功能测试所需的测试场景，配置生成V2X数据库，满足开发测试阶段所需的密钥，包括密钥的导入和生成，对应证书的管理和有效期的配置等。，在安全通信的证书和安全性测试中也得到了有效的支持。

关于中国的安全标准，虽然目前国家标准还没有发布，独木舟选择车……工具中已经包含了中国的草案版本规范。通过工具可以看到，加密异常通信时，可以看到通信的实时数据在分析窗口中以紫色突出显示。CANoe Option Car2X还提供了一系列API函数，方便安全测试和验证。

安全互连连接

越来越多的主机厂会让车辆与云和后台进行交互，而随着SOA的引入，整个系统不仅仅是一辆车，更是一个包括车+后台、车+交车后、手机等在内的通讯应用。车辆互联中的主要通信技术:MQTT和HTTP。在与外部互联网通信时，我们需要对相应的数据进行加密和处理。在这种情况下，还需要CANoe等工具来支持MQTT或HTTP等协议。

可能有两种情况需要考虑。一种情况是会连接真正的ECU，ECU一端是车内常规通信，CANoe本身擅长并支持；ECU另一端的通信需要通过MQTT或HTTP与云端后台进行交互。当然，在CANoe中，可以通过相应的开发，直接与车辆外部实现相应的通讯应用。

还有一种应用场景，在开发初期需要与云应用交互时，可以将整个软件系统的功能完全部署在虚拟环境中。在虚拟环境中直接访问软件接口，可以用比真实控制器的接口更方便的方式直接实现，并且可以在自己的PC和相应的环境中构建虚拟环境，实现MQTT和HTTP协议的互联。CANoe或CANoe4SW可用于实现车载或云端软件系统的互联测试。

举个真实的例子，这里有一个SUT，可以通过CANoe或者CANoe4SW在虚拟环境中测试。基于MQTT传输数据，将相应的数据传输到MQTT的代理端，再通过代理端将相应的数据传输到测试工具进行相应的处理。

在整个系统中，会有一个与安全相关的证书部分，因为整个数据在通信时需要实现相应的安全通信应用，相应的会有不同的证书需要配置。比如在证书方面，有PM格式或者PFX格式的证书，会产生CANoe需要的证书和SUT匹配的证书，这样整个通信链路本身也可以实现相应的加密通信应用。

另外，MQTT用于互联通信服务时，不同开发阶段需要的测试环境是不同的。在MQTT中进行相应的数据处理时，需要链接相应的MQTT Booker。在CANoe工具层面，可以支持云后台的Broker桥接，局域网内的build，CANoe内的building Booker。在CANoe中直接建立MQTT Booker可以非常方便实现、故障注入和时间测试。当然，在MQTT的整个通信层面，可以通过Google Protocol Buffer协议或者JSON实现MQTT数据的虚拟化和逆序传输应用。无论哪种方式，目前在CANoe中都支持。

但是，我们也看到，在实际应用中，有些应用对云和后台的访问是有限的。此时的开发和测试提供了一个更实惠的CANoe级别的解决方案，供用户参考。CANoe匹配物联网使能硬件:VH4110。在这个硬件上，利用自身的一些功能扩展了很多互连协议，如低功耗BLE、BT、LoRaWAN、ZigBee等，这样就可以利用CANoe控制VH4110，将测试控制器自身功能时需要的外部互连信号直接发送给ECU。当网络和后台无法访问时，两者之间的交互也是一种经济、实用、便捷的处理手段。

6以前汽车是独立系统，相对安全，外界很难受到相应的攻击。但是随着联网、车载OBD、智能充电、OTA系统、蓝牙无线的引入，整个系统已经不再安全，需要采用相应的技术来保证车辆的安全。但是在保证整个技术落地的过程中，需要有相应的工具进行相应的开发和测试。以前在整个系统的开发过程中，相关数据都是“明码”，没有加密，所以任何工具都可以获取相关数据，读写相应的数据，还可以做模拟和回放。然而，系统通信数据加密后，许多功能用常规工具无法满足。比如数据加密的时候，简单的数据分析会遇到很大的麻烦。然而，并不是所有的工具都支持加密系统的开发和测试。

现在，所有使用的开发和测试工具都必须考虑当产品面临相关问题时，如何支持安全相关的应用，尤其是供应商，因为供应商在不同的沟通渠道会面临不同OEM厂商的不同项目……应用层，每个项目的每个通信层依赖不同的加密系统进行加密。供应商不可能在每个OEM的每个项目中都采购和学习全新的工具链。作为知名的车载网络安全供应商，Victor在网络安全工具的开发和测试方面也有很多独特的经验。

带TLS的DoIP

随着以太网相关技术的引入，在诊断系统中使用DoIP进行相应的诊断应用。但出于安全诊断的考虑，2019年将发布新版本的ISO13400-2，该版本定义的DoIP可以通过TLS实现安全诊断。根据具体流程，整个通信过程中，车辆连接后会先通过13400端口激活路由，当收到07拒绝响应时，表示需要TLS进行安全诊断。然后测试设备发送消息关闭传统DoIP的13400端口服务，然后打开支持TLS的3496端口。然后建立TLS“握手”，实现诊断设备与ECU或相应的车辆安全钥匙或证书之间的安全通信连接。最后，TLS协议被再次激活，然后整个诊断服务处理将在TLS协议下传输。

诊断完成后，需要相应关闭3496端口。在整个过程中，我们可以看到数据是通过TLS加密的，经过相应的开发、调试和测试，需要工具来支持DoIP的TLS协议。对于CANoe来说，嵌入式功能可以完全支持2019版的真实DoIP协议。同时可以在CANoe中配置和处理相关的DoIP配置，也可以开发TLS本身的协议测试。其他相应的矢量工具，如Viktor的画笔工具vFlash和诊断仪Indigo，都是根据同样的思路和原理实现TLS的DoIP，最新版本是可以支持DoIP的TLS协议。

出口的新能源汽车面临ISO15118的加密充电。

车辆互联时，还有一个重要的接口，就是充电接口。在计费部分，目前国内相应的计费处理是基于GB/T 27930协议。但我相信国内的新能源汽车公司都是做整车出口业务的，所以在欧美的充电基础设施体系下，不得不面对相应充电的需求。在欧洲收费系统下，需要面对一个重要的规范:ISO15118。这个协议本身一直在做相应的迭代更新，很明显在整个系统中，随着15118-20协议新版本的发布，TLS是一个强制要求。

也就是说，在收费方面，协议上也有相应的加密。在开发过程和调试过程中，OEM和供应商都要依靠相应的工具来解决:ISO15118支持这个协议吗？在工具和设备方面，另一个重要的考虑因素将是ISO15118-2和刚才提到的-20所需的TLS零件是否能得到完全支持。

对于整个收费系统的开发过程来说，收费部分和实际的传统开发过程是一样的。会有相应的虚拟SiL原型、A/B样车、C样车和量产车。在产品开发初期，需要模拟充电桩(EVSE)或者车辆(EV)，因为EV和EVSE之间的通信是用TLS加密通信的，模拟充电桩本身也要能支持TLS协议。实际充电后期，连接真实桩进行相应的数据传输，数据里面也有TLS协议。一方面数据可以收集，另一方面解密工作需要工具来处理。

无论是以太网还是PLC，通信时都可以在CANoe中加密解密数据。测试完成后，系统的ECU与车辆集成。整合后会处理车辆和相应设备的数据，里面也会处理证书，这是TLS中的一些应用处理。在CANoe中，PKI及其对应的证书可以通过安全管理器模块进行处理。

在实际测量中……ent，还会提供一个经济的方案，方便大家提取实车和安装之间的对应数据，做相关分析。比如这是真车，真桩，上面的通讯数据是通过PLC通讯的，数据是加密的，所以充电时异常数据的采集和分析会是个问题。在这里，Victor将为PLC通信提供“监控”设备，以监控PLC数据，数据将传输到CANoe。和图中的物理系统一样，Vector通过耦合直接从充电中捕获相应的数据，而不会破坏相应的真实充电的线缆。在解密方面，Victor在工具中提供了多种方式来解密相应的数据。当然具体解密需要看实际环境和获取的信息。在工具层面，如何在CANoe中实现相关的解密处理。当然，对于这里提供的四种解密TLS通信的方式，当然也适用于DoIP和刚才提到的一些/IP，这些都可以在CANoe中实现。

车联网-V2X的安全性

在车辆外部互联接口方面，尤其是V2X，在国内，我们看到很多实验区，包括三跨、四跨，也在进行相应的开发和应用。整个系统内部:在整个链路中，无论是车辆与车辆之间的通信，还是车辆与其他设备之间的通信，V2X的数据都可以通过PC5进行传输，传输的数据会用相应的证书进行加密。并且相应的数据进入车内后，车端的通信应用OEM车载安全技术对数据进行相应的加密。

所以在车联网的V2X方面，选择工具也有很多需要考虑的条件。当然，很多供应商和OEM不仅会面对中国的项目，还会支持全球的项目。在安全方面，中国的V2X安全规范仍是草案版本，但欧美的安全规范ETSI TS 103 097和IEEE 1602.2处于发布状态。在工具选择上，必须能够支撑相应国家的安全。还需要支持各种主机厂的车载通信的安全加密和解密。此外，这些工具需要支持传统车辆通信开发和测试的要求，如arxml、用于诊断的cdd以及用于车辆通信的1000/100BASE-T1和CAN FD。实现V2X安全的处理需要从长远角度规划相应的工具和设备。

CANoe Option Car2X模块，Car2X的插件，在安全测试工具CANoe中提供。其中，提供2D场景设计功能，实现功能测试所需的测试场景，配置生成V2X数据库，满足开发测试阶段所需的密钥，包括密钥的导入和生成，对应证书的管理和有效期的配置等。，在安全通信的证书和安全性测试中也得到了有效的支持。

关于中国的安全标准，虽然目前国家标准还没有发布，但是CANoe Option Car2X已经在工具中包含了中国的草案版本规范。通过工具可以看到，加密异常通信时，可以看到通信的实时数据在分析窗口中以紫色突出显示。CANoe Option Car2X还提供了一系列API函数，方便安全测试和验证。

安全互连连接

越来越多的主机厂会让车辆与云和后台进行交互，而随着SOA的引入，整个系统不仅仅是一辆车，更是一个包括车+后台、车+交车后、手机等在内的通讯应用。车辆互联中的主要通信技术:MQTT和HTTP。在与外部互联网通信时，我们需要对相应的数据进行加密和处理。在这种情况下，还需要CANoe等工具来支持MQTT或HTTP等协议。

可能有两种情况需要考虑。一种情况是会连接真正的ECU，ECU一端是车内常规通信，CANoe本身擅长并支持；ECU另一端的通信需要通过MQTT或HTTP与云端后台进行交互。当然，在CANoe中，可以通过相应的开发，直接与车辆外部实现相应的通讯应用。

还有一种应用场景，在开发初期需要与云应用交互时，可以将整个软件系统的功能完全部署在虚拟环境中。在虚拟环境中直接访问软件接口，可以用比真实控制器的接口更方便的方式直接实现，并且可以在自己的PC和相应的环境中构建虚拟环境，实现MQTT和HTTP协议的互联。CANoe或CANoe4SW可用于实现车载或云端软件系统的互联测试。

举个真实的例子，这里有一个SUT，可以通过CANoe或者CANoe4SW在虚拟环境中测试。基于MQTT传输数据，将相应的数据传输到MQTT的代理端，再通过代理端将相应的数据传输到测试工具进行相应的处理。

在整个系统中，会有一个与安全相关的证书部分，因为整个数据在通信时需要实现相应的安全通信应用，相应的会有不同的证书需要配置。比如在证书方面，有PM格式或者PFX格式的证书，会产生CANoe需要的证书和SUT匹配的证书，这样整个通信链路本身也可以实现相应的加密通信应用。

另外，MQTT用于互联通信服务时，不同开发阶段需要的测试环境是不同的。在MQTT中进行相应的数据处理时，需要链接相应的MQTT Booker。在CANoe工具层面，可以支持云后台的Broker桥接，局域网内的build，CANoe内的building Booker。在CANoe中直接建立MQTT Booker可以非常方便实现、故障注入和时间测试。当然，在MQTT的整个通信层面，可以通过Google Protocol Buffer协议或者JSON实现MQTT数据的虚拟化和逆序传输应用。无论哪种方式，目前在CANoe中都支持。

但是，我们也看到，在实际应用中，有些应用对云和后台的访问是有限的。此时的开发和测试提供了一个更实惠的CANoe级别的解决方案，供用户参考。CANoe匹配物联网使能硬件:VH4110。在这个硬件上，利用自身的一些功能扩展了很多互连协议，如低功耗BLE、BT、LoRaWAN、ZigBee等，这样就可以利用CANoe控制VH4110，将测试控制器自身功能时需要的外部互连信号直接发送给ECU。当网络和后台无法访问时，两者之间的交互也是一种经济、实用、便捷的处理手段。

标签：

汽车资讯热门资讯