最近在使用 MSE102X GD32F527RS 模拟车辆充电的过程其中基于 ISO15118 协议有一段 V2G 的过程需要使用到 TLS1.2 或者 TLS1.3抓到的 wireshark 包不好分析交互过程中的数据是否存在异常或者跟其他的设备进行模拟充电时无法判断交互数据是否正确带来了比较大的麻烦。然后从网上找到了方式可以进行 DEBUG 调试特此记录下过程和内容方便有需要的同学后续根据相关方法拓展和调试使用目录存在问题问题处理WIRESHARK 插件集成修改功能验证可能存在问题及处理存在问题完整的交互流程可以参考 EVCC/EVSE充电全过程在模拟车辆充电过程中V2G使用TLS1.2或者TLS1.3在构建会话后所有应用数据都使用了秘钥进行加密后续无法查看交互报文导致无法判断交互报文是否正常。可以看到当 V2G 建立起来之后后续的所有报文都使用了 TLS1.2 进行加密如果想要从 wireshark 中查看 DEBUG 看相关的交互流程或者报文是否正确就会变得比较麻烦。从报文解析也可以看到报文内容都是经过了加密导致无法详细查看 DEBUG 看报文是否正常问题处理是否有办法能够在 wireshark 中通过一些手段或者方式帮忙解析或者查看相关报文方法是有的不过需要注意此方法仅用于调试、测试阶段使用严禁在生产环境中使用有可能导致秘钥泄露WIRESHARK 插件这里要使用到的 WIRESHARK 叫做 v2gtlssecret这个 dSPACE 公司为 Wireshark 开发的一个插件属于 dsV2Gshark 工具集中的一个协议解析器Dissector它的核心功能是实现V2G车联网通信中TLS流量的实时解密它本身不是一种你需要主动“拼装”的通用通信协议而是一种用于实时传递TLS会话密钥的、特定格式的UDP报文。你需要做的是按照它规定的格式构造并发送UDP数据包。需要注意的是该插件在 wireshark 3.5.0 或者更高版本才支持这个工具的格式报文如下v2gtlssecret插件通过解析特定的UDP数据包来获取密钥。该UDP报文需满足以下要求传输层使用UDP协议。源端口通常在49152-65535的临时端口范围内。包大小有效载荷Payload大小在175 到 1800 字节之间。内容格式有效载荷为ASCII 文本其格式遵循Wireshark的NSS Key Log 格式其核心内容是一行文本格式为标签 客户端随机数 密钥TLS 1.2使用CLIENT_RANDOM标签CLIENT_RANDOM 32字节客户端随机数(十六进制) 48字节主密钥(十六进制)TLS 1.3根据密钥用途使用不同标签如CLIENT_HANDSHAKE_TRAFFIC_SECRET、SERVER_TRAFFIC_SECRET_0等TLS1.3标签 32字节客户端随机数(十六进制) 密钥(十六进制)这里以 TLS1.2 为例简单阐述下该插件运行逻辑1、该插件严格依赖于从完整的 TLS 握手过程中提取关键信息2、针对 TLS1.2该插件会从 Client Hello 消息中获取 client_random 字段3、然后根据 SSLKEYLOGFILE 中的 client_random 和 Pre-Master Secret 来推导会话秘钥集成修改1、该插件在 wireshark 3.5.0 或更高版本中以及集成插件无需单独安装2、我们需要按照规定的格式使用 UDP 将 TLS1.2 中的 CLIENT_RANDOM 或者 TLS1.3 中的 CLIENT_HANDSHAKE_TRAFFIC_SECRET/SERVER_HANDSHAKE_TRAFFIC_SECRET、CLIENT_TRAFFIC_SECRET_0/SERVER_TRAFFIC_SECRET_0 发送出来即可。3、因为我们自己的 SDK 使用的 MbedTLS 软件加解密方式可以直接使用对应的回调即可所以这里的修改都是按照 MbedTLS 的方式修改①使用的回调接口 mbedtls_ssl_set_export_keys_cb这里需要注意需要将对应的 MbedTLS 的宏打开包括但不限于 MBEDTLS_SSL_SESSION_TICKETS②配置导出秘钥位置需要注意这里配置需要放置在交互之前否则可能因为流程不完整无法导出或者导出失败③注册回调函数// 发送 UDP 报文IPv6 组播示例 static void v2g_udp_send_nss_key_log(const char *line, uint16_t len) { int sock -1; struct sockaddr_in6 src_addr, dst_addr; if (line NULL || len 0) return; sock socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP); if (sock 0) { UNI_LOG_WARN(Init Socke Err); return; } // 绑定源端口必须为 49152-65535 uni_memset(src_addr, 0x00, sizeof(struct sockaddr_in6)); src_addr.sin6_family AF_INET6; src_addr.sin6_port htons(NSS_KEY_SRC_PORT); src_addr.sin6_addr in6addr_any; if (bind(sock, (struct sockaddr *)src_addr, sizeof(src_addr)) 0) { UNI_LOG_WARN(Bind Err); close(sock); return; } // 目标地址 uni_memset(dst_addr, 0x00, sizeof(struct sockaddr_in6)); dst_addr.sin6_family AF_INET6; dst_addr.sin6_port htons(NSS_KEY_DST_PORT); dst_addr.sin6_scope_id uni_netif_get_scope_id(uni_netif_get_handle()); if (inet_pton(AF_INET6, NSS_KEY_MCAST6_ADDR, dst_addr.sin6_addr) ! 1) { UNI_LOG_WARN(inet_pton Err); close(sock); return; } if (-1 sendto(sock, line, len, 0, (struct sockaddr *)dst_addr, sizeof(dst_addr))) { UNI_LOG_WARN(Send to Sock: %d, %d err, sock, len); } close(sock); }void mbedtls_v2g_key_export_callback(void *p_expkey, mbedtls_ssl_key_export_type secret_type, const unsigned char *secret, size_t secret_len, const unsigned char client_random[32], const unsigned char server_random[32], mbedtls_tls_prf_types tls_prf_type) { // 将 client_random 转为十六进制 char key_line[2048] {0}; const char *label NULL; char *client_hex NULL, *secret_hex NULL; int total_len 0; client_hex bin_to_hex(client_random, 32); if (client_hex NULL) { UNI_LOG_ERROR(Client hex err); goto EXPORT_FINISH; } // 将 secret 转为十六进制 secret_hex bin_to_hex(secret, secret_len); if (secret_hex NULL) { UNI_LOG_ERROR(Secret hex err); goto EXPORT_FINISH; } // 根据 secret_type 判断是 TLS 1.2 还是 1.3并确定标签 switch (secret_type) { // ----- TLS 1.2 ----- case MBEDTLS_SSL_KEY_EXPORT_TLS12_MASTER_SECRET: // TLS 1.2 使用 CLIENT_RANDOM 标签 label CLIENT_RANDOM; break; // ----- TLS 1.3 握手密钥 ----- #ifndef CONFIG_EVSE_ROLE case MBEDTLS_SSL_KEY_EXPORT_TLS1_3_CLIENT_HANDSHAKE_TRAFFIC_SECRET: label CLIENT_HANDSHAKE_TRAFFIC_SECRET; break; #endif #ifdef CONFIG_EVSE_ROLE case MBEDTLS_SSL_KEY_EXPORT_TLS1_3_SERVER_HANDSHAKE_TRAFFIC_SECRET: label SERVER_HANDSHAKE_TRAFFIC_SECRET; break; #endif // ----- TLS 1.3 应用密钥0-RTT 和 1-RTT ----- case MBEDTLS_SSL_KEY_EXPORT_TLS1_3_CLIENT_APPLICATION_TRAFFIC_SECRET: label CLIENT_TRAFFIC_SECRET_0; break; case MBEDTLS_SSL_KEY_EXPORT_TLS1_3_SERVER_APPLICATION_TRAFFIC_SECRET: label SERVER_TRAFFIC_SECRET_0; break; // 其他类型如 early 密钥可按需扩展 default: label NULL; goto EXPORT_FINISH; } // 如果是 TLS 1.3 的某个密钥构造对应行 if (label ! NULL) { total_len snprintf(key_line, sizeof(key_line), %s %s %s, label, client_hex, secret_hex); if (total_len 0) { v2g_udp_send_nss_key_log(key_line, total_len); UNI_LOG_INFO(NSS KEY LOG(%d): %s, total_len, key_line); } } EXPORT_FINISH: if (secret_hex) uni_free(secret_hex); if (client_hex) uni_free(client_hex); }功能验证1、从 wireshark 中可以抓到对应的 V2G Secret 报文2、查看报文是否可以看到内容从下图可以看到后续的交互报文都已经可以看到并且解析出对应的报文内容预期实现完成可能存在问题及处理存在问题在实际过程中可能出现了以下情况一个方向解析是正常的另外一个方向无法解析还是使用了 TLS 进行了加密问题原因在Wireshark中解密引擎按数据包处理TLS记录。如果TCP流由于丢失或无序数据包而中断Wireshark将无法知道后续数据包的TLS记录起始位置长度字段被加密或者它丢失了先前数据包的尾部。而在我们的报文中交互流程中TCP 包出现了异常导致后续的交互存在异常而引起此问题。修复方式找到 wireshark - 编辑 - 首选项 - Protocols - TLS按照如下修改即可