1. 项目概述为什么我们要深入GB35114的SIP双向认证如果你正在从事视频监控、安防平台开发或者负责相关系统的安全运维那么“GB35114”这个标准你一定不陌生。它不仅仅是一个技术规范更是国内公共安全视频监控联网系统信息安全的强制性要求。标准里涉及大量密码学应用其中SIP会话初始协议信令的双向认证是设备接入平台的第一道也是最关键的一道安全关卡。很多开发者在对接时往往只关注接口是否调通对底层“握手”的细节一知半楚一旦遇到认证失败排查起来就像盲人摸象。我经历过多次现场调试设备反复注册失败日志只给个笼统的“认证错误”。这时候仅靠看代码和日志是远远不够的你必须能“看见”网络上流动的每一个数据包亲眼验证SM2签名是否被正确计算、SM3摘要是否匹配、SIP消息体的构造是否符合标准预期。这就是Wireshark这类抓包工具无可替代的价值——它让你从“猜测”走向“实证”。本次实战我们就聚焦于一个核心场景使用Wireshark抓取并深度解析一台GB35114合规设备与SIP服务器SIP Server之间的双向认证流程。我们会像法医解剖一样逐层拆解SIP信令并重点揭示其中SM2、SM3国密算法的应用细节。无论你是开发者、测试工程师还是安全研究员掌握这套方法就等于掌握了定位GB35114认证类问题的“手术刀”。2. 环境准备与核心概念澄清在开始抓包前我们需要一个清晰的实验环境和明确的技术概念避免后续分析时产生混淆。2.1 实验环境搭建要点一个理想的抓包环境需要满足“流量可见”和“场景可控”两个条件。网络拓扑设计最简单的办法是使用网络集线器Hub或者配置端口镜像的交换机。将待分析的GB35114设备如IPC摄像机、SIP服务器以及运行Wireshark的抓包主机全部连接到同一个广播域。如果条件有限也可以在设备或服务器所在的单台电脑上安装Wireshark抓取本地回环或物理网卡流量但这要求设备或服务器软件本身运行在该机器上。设备与服务器配置设备端准备一台支持GB35114-C级及以上安全要求的摄像机或编码器。确保其已正确配置SIP服务器的地址、端口、本地SIP ID如34020000001320000001以及对应的SM2私钥证书。服务器端搭建或使用一个支持GB35114标准的SIP服务器如某些开源媒体服务器国密插件或商业安防平台。确保服务器端已导入设备对应的SM2公钥证书。关键一步在设备上触发一次“注册”或“心跳”操作。通常设备上电或手动重启SIP服务后会主动向服务器发起注册请求这是抓取双向认证流程的最佳时机。Wireshark安装与基础配置从官网下载安装最新稳定版。安装时注意勾选“Install Npcap”或“WinPcap”这是抓包所必需的驱动。首次启动在“捕获”-“选项”中选择正确的网络接口通常是连接实验网络的那块网卡。为了快速定位SIP流量我们可以在捕获过滤器中输入port 5060或port 5061如果使用TLS。GB35114中SIP默认使用5060端口进行非加密传输信令本身有数字签名保护但有时也会用5061的SIPS。先抓5060端口是通用做法。2.2 GB35114 SIP双向认证的核心逻辑这里需要先理清几个容易混淆的概念这对后续看懂数据包至关重要。双向认证 vs 单项认证双向认证意味着通信的双方设备与服务器要互相证明“我是我”。设备向服务器注册时要证明自己是合法设备服务器接受注册前也要向设备证明自己是合法的平台。这不同于只需输入密码的单向认证。数字签名与摘要算法的作用SM3这是一种密码杂凑算法你可以理解为一种特殊的“指纹提取器”。它会把任意长度的原始数据如SIP消息头消息体转换成一个固定长度256位的唯一“数字指纹”摘要。只要原始数据有一个比特的改动这个指纹就会完全不同。在GB35114中SM3主要用于生成待签名数据的摘要。SM2这是一种基于椭圆曲线的非对称密码算法包含加密、解密、签名和验签功能。在SIP双向认证中我们主要用到其数字签名功能。流程是发送方如设备用自身的SM2私钥对SM3生成的“数据指纹”进行签名运算生成一个签名值并将这个签名值连同原始数据、自身的公钥证书一起发送出去。接收方如服务器则用发送方的SM2公钥去验证这个签名如果验证通过就证明了两件事1. 数据在传输过程中未被篡改完整性2. 数据确实来自于持有对应私钥的发送方身份真实性。SIP消息中的承载方式在GB35114中SM2签名信息通常封装在SIP消息的Authorization或Proxy-Authorization头域中或者作为特定的消息体如application/gb35114-xxx类型的一部分。具体格式需参照标准文档但核心元素一般包括算法标识如SM2、签名随机数、签名值本身等。注意很多初学者会把SM2签名和SM3加密混为一谈。记住在这个场景里SM3不加密它只生成摘要SM2不直接加密数据它用私钥对摘要进行签名。整个流程的目的是防篡改和身份认证而非对信令内容进行加密信令内容本身可能是明文的。3. Wireshark抓包实战与关键过滤器应用环境就绪后我们开始实际的抓包操作。漫无目的地抓取海量数据包效率极低必须熟练运用Wireshark的过滤技巧。3.1 启动捕获与初步过滤在Wireshark中选择正确的网卡点击“开始捕获”按钮。触发设备的SIP注册过程。捕获到一定数量的包后点击“停止”。你可能会看到大量ARP、TCP、HTTP等无关流量。应用显示过滤器在过滤器栏输入sip。Wireshark会智能过滤出所有被识别为SIP协议的数据包。这是最常用的一步。3.2 深度过滤技巧定位认证相关报文仅仅过滤SIP还不够我们需要精准定位到携带认证信息的特定消息。过滤特定SIP方法注册流程通常始于REGISTER请求。可以使用过滤器sip.Method REGISTER。你会看到设备发往服务器的REGISTER请求和服务器回复的401 Unauthorized、200 OK等响应。过滤含有认证头域的消息认证信息主要在Authorization头域。过滤器可以写为sip.Authorization。或者更精确地结合方法一起过滤sip.Method REGISTER and sip.Authorization。跟踪完整SIP对话在任意一个SIP数据包上右键选择“追踪流” - “TCP流”或“UDP流”SIP通常用UDP但也有用TCP的。Wireshark会弹出一个新窗口只显示该次SIP会话的所有相关数据包并按顺序排列这对于分析一个完整的注册交互流程非常直观。基于IP地址过滤如果你知道设备和服务器的IP可以直接用ip.src 192.168.1.100 or ip.dst 192.168.1.100这样的过滤器再结合sip进行二次过滤。实操心得我习惯先用sip过滤器看全局找到一个REGISTER请求后右键其“SIP Call-ID”字段选择“作为过滤器应用” - “选中”。这样就能把属于同一次注册会话的所有SIP包都筛选出来上下文非常完整。4. 逐包解析一个完整的GB35114 SIP双向认证流程假设我们抓取到了一个完整的成功注册流程。下面我们按照时间顺序拆解其中最关键的几个数据包。4.1 第一回合设备发起挑战REGISTER - 401 Unauthorized数据包1设备发送初始REGISTER请求在Wireshark中找到第一个REGISTER包。查看SIP详情点击包详情窗口的“”号展开。你会看到典型的SIP头Via,From,To,Call-ID,CSeq,Contact等。关键观察点这个初始请求的Authorization头域是空的或者不包含有效的签名。这是因为设备还不知道服务器本次会话要求使用哪种认证方式Digest算法。它只是在声明“我是34020000001320000001我想注册。”在To和From字段你会看到设备的SIP URI通常格式是sip:34020000001320000001domain。数据包2服务器回复401 Unauthorized服务器收到未经验证的注册请求后会回复401 Unauthorized。这是认证开始的标志展开这个响应包重点查看WWW-Authenticate头域。这个头域包含了服务器下发的“挑战”信息。在GB35114中它可能看起来像这样WWW-Authenticate: Digest realm34020000002000000001, nonce7a1f2c83e5d9b4, algorithmSM2, qopauth, sm2-sign-algSM3字段解读realm认证域通常是服务器的SIP ID。nonce一个服务器生成的随机数每次401响应都不同。这是防止重放攻击的关键。设备在后续计算签名时必须将这个nonce值纳入待签名数据中。algorithm指明使用SM2算法进行签名。sm2-sign-alg指明签名时使用的摘要算法为SM3。qop保护质量auth表示只进行身份认证。注意事项这个nonce至关重要。很多认证失败的问题就出在这里——设备端没有正确地从401响应中提取这个nonce或者提取了但没有在后续签名计算中使用它。务必在Wireshark中核对设备发出的第二个REGISTER请求中的nonce是否与此处服务器下发的一致。4.2 第二回合设备应答挑战带签名的REGISTER数据包3设备发送带Authorization的REGISTER请求设备收到401挑战后会重新构造一个REGISTER请求这次会携带完整的Authorization头域。展开这个请求包详细查看Authorization头域。这是整个分析的核心。其内容会比标准的SIP Digest认证复杂包含了国密特有的字段。一个简化示例如下Authorization: Digest username34020000001320000001, realm34020000002000000001, nonce7a1f2c83e5d9b4, algorithmSM2, responsexxxx...很长一串Base64编码的SM2签名值, sign-algSM3, certMI...Base64编码的设备SM2公钥证书关键字段深度解析username设备SIP ID。realm和nonce必须与服务器401响应中下发的完全一致。algorithm和sign-alg同上声明使用SM2和SM3。response这就是SM2签名值经过Base64编码。这个值是如何产生的呢根据GB35114待签名的数据即SM3的输入通常包括username、realm、nonce、SIP方法REGISTER、SIP Request-URI等字段按照特定格式拼接而成的字符串。设备用自身的SM2私钥对这个字符串的SM3摘要进行签名得到签名结果编码后放入response。cert设备SM2公钥证书的DER格式再进行Base64编码。服务器需要用这个证书里的公钥来验证上面的response签名。这里就是最容易出错的环节。你需要理解response字段不是密码而是一个密码学运算的结果。验证双方必须对“待签名数据字符串的拼接规则”有完全一致的约定。标准中对此有明确定义但不同厂商在实现时可能有细微差异。4.3 第三回合服务器验证并回应200 OK / 4xx数据包4服务器回复200 OK 或 4xx错误服务器收到带签名的REGISTER后会进行验签操作从cert字段解析出设备的SM2公钥。按照同样的规则自己拼接出待验证的“数据字符串”。使用SM3计算该字符串的摘要。使用SM2公钥对response字段解码后的签名值进行验签运算核对是否与计算出的摘要匹配。如果验签成功服务器会回复200 OK表示注册成功。这个响应包本身也可能包含一个Authentication-Info头域其中携带了服务器对设备的挑战信息如一个新的nonce以及服务器自身的签名以此完成服务器对设备的认证即“双向”中的另一向。你需要检查这个头域其格式可能与Authorization类似但使用了SM2等算法标识。如果验签失败服务器会回复403 Forbidden等4xx错误。此时Wireshark抓包就派上了用场。你可以对比设备发送的Authorization头和服务器期望的格式逐一检查每个字段。5. 国密算法细节在数据包中的体现仅仅看到字段名是不够的我们需要知道如何验证这些密码学操作。5.1 如何验证SM3摘要的正确性虽然Wireshark无法直接解析国密算法但我们可以进行手动验证这对定位问题极有帮助。提取待签名数据根据GB35114标准附录或你的实现文档确定待签名数据的精确拼接格式。例如可能是username:realm:nonce:method:uri这样的字符串。计算SM3摘要使用一个在线的SM3计算工具搜索“SM3在线计算”或本地国密库如gmssl将上一步拼接的字符串输入计算其SM3哈希值一个64位的十六进制字符串。记作HASH_LOCAL。从response中反推response是SM2签名值。SM2签名是基于SM3摘要和椭圆曲线数字签名算法ECDSA产生的。我们无法直接从签名值反推出摘要。但是我们可以用服务器同样的方法来验证使用设备的公钥和这个签名去验证我们本地计算的HASH_LOCAL。这需要编写简单的脚本或使用gmssl命令行工具。实操示例使用OpenSSL/GmSSL命令行思路 假设你已拥有设备的SM2公钥文件device_pub.pem和从数据包中提取的待签名原始数据data_to_sign.txt以及Base64解码后的签名值signature.bin。# 1. 计算数据的SM3摘要 (使用gmssl) gmssl sm3 -hex -in data_to_sign.txt # 输出摘要值例如66c7f0f462eeedd9d1f2d46bdc10e4e24167c4875cf2f7a2297da02b8f4ba8e0 # 2. 使用SM2公钥验证签名 (此命令为示例具体参数需参考gmssl文档) gmssl sm2utl -verify -in data_to_sign.txt -sigfile signature.bin -pubin -inkey device_pub.pem -id 1234567812345678 # 如果验证成功会输出“Verification Success”踩过的坑待签名数据的拼接规则必须百分百准确包括字段顺序、分隔符是冒号、逗号还是空格、字段本身是否包含引号、是否对URI进行了规范化处理如去除transport参数等。一个字符的差异都会导致SM3摘要完全不同从而使验签失败。务必与服务器侧开发人员确认拼接规则。5.2 解析SM2公钥证书Authorization头中的cert字段是Base64编码的DER格式证书。你可以将其复制出来保存为cert.b64然后解码并查看内容。# 将Base64编码的证书解码为DER二进制文件 base64 -d cert.b64 cert.der # 使用openssl查看证书内容如果是X.509格式GB35114证书通常基于X.509 openssl x509 -in cert.der -inform DER -text -noout查看证书内容确认其主题Subject中的CN通用名称是否与设备的SIP ID一致确保证书在有效期内并且其公钥算法标识为sm2。6. 常见问题排查与Wireshark高级技巧当认证失败时利用Wireshark进行对比分析是最高效的手段。6.1 典型认证失败场景排查表现象 (Wireshark观察)可能原因排查思路设备持续发送不带Authorization的REGISTER服务器持续回复401设备未正确处理401挑战或配置中未启用国密认证。检查设备日志确认是否收到并解析了401。检查设备安全等级配置是否为GB35114 C级或以上。设备发送带Authorization的REGISTER后立即收到403 Forbidden签名验证失败。这是最常见的问题。1.核对nonce对比设备请求中的nonce与服务器上一次401响应的nonce是否一致。2.核对证书检查cert字段是否完整能否正确解析出公钥。3.验证签名按照第5.1节的方法手动验证签名。重点检查待签名数据拼接规则。服务器回复200 OK后连接很快断开或没有后续信令服务器对设备的认证通过了但设备对服务器的认证双向可能失败。检查服务器的200 OK响应中是否包含Authentication-Info头域以及设备是否正确处理了其中的服务器签名。Wireshark中完全看不到SIP协议解析显示为UDP数据Wireshark未正确解码SIP流量。可能端口非标准或数据加密。1. 尝试右键数据包 - “解码为...” - 选择SIP协议。2. 检查是否使用了TLSSIPS如果是需要配置RSA密钥解密国密场景复杂通常信令不加密。Authorization头中algorithm字段不是SM2设备与服务器认证算法协商不一致。检查设备能力集和服务器支持的算法列表。确保双方都支持并首选SM2。6.2 Wireshark高级分析技巧自定义显示列在包列表栏右键选择“列首选项”可以添加自定义列。例如添加“SIP Call-ID”和“SIP CSeq”列能让你更容易跟踪同一会话的不同请求/响应。使用“专家信息”Wireshark底部有一个“专家信息”标签页它会汇总抓包文件中的警告、错误、注释。例如如果SIP消息格式有误这里可能会有提示。导出对象如果SIP消息体中携带了证书文件等数据可以尝试使用“文件”-“导出对象”-“HTTP”来提取。对比分析抓取一次成功的注册包和一次失败的注册包保存为两个文件。使用Wireshark的“比较”功能需要借助第三方插件或手动并列窗口逐字段对比两个Authorization头的差异往往能快速定位问题。我个人在实际排查中最常用的一招是在设备端和服务器端的关键代码处打日志分别打印出它们各自拼接的待签名字符串和计算出的SM3摘要。然后在Wireshark中抓包把这两个日志值和网络上的数据包信息进行比对。一旦发现设备端计算的摘要与服务器端根据收到的数据计算出的摘要不一致那么问题就一定出在数据拼接环节。这个“三角核对法”几乎能解决所有因算法实现差异导致的认证问题。通过这样一次从环境搭建、抓包过滤、逐包解析到算法验证的完整旅程你不仅能看懂GB35114 SIP双向认证的数据包更能掌握一套定位和解决复杂认证问题的通用方法论。下次再遇到“认证失败”你大可以淡定地打开Wireshark让数据包告诉你真相。
Wireshark实战解析GB35114 SIP双向认证与国密算法应用
1. 项目概述为什么我们要深入GB35114的SIP双向认证如果你正在从事视频监控、安防平台开发或者负责相关系统的安全运维那么“GB35114”这个标准你一定不陌生。它不仅仅是一个技术规范更是国内公共安全视频监控联网系统信息安全的强制性要求。标准里涉及大量密码学应用其中SIP会话初始协议信令的双向认证是设备接入平台的第一道也是最关键的一道安全关卡。很多开发者在对接时往往只关注接口是否调通对底层“握手”的细节一知半楚一旦遇到认证失败排查起来就像盲人摸象。我经历过多次现场调试设备反复注册失败日志只给个笼统的“认证错误”。这时候仅靠看代码和日志是远远不够的你必须能“看见”网络上流动的每一个数据包亲眼验证SM2签名是否被正确计算、SM3摘要是否匹配、SIP消息体的构造是否符合标准预期。这就是Wireshark这类抓包工具无可替代的价值——它让你从“猜测”走向“实证”。本次实战我们就聚焦于一个核心场景使用Wireshark抓取并深度解析一台GB35114合规设备与SIP服务器SIP Server之间的双向认证流程。我们会像法医解剖一样逐层拆解SIP信令并重点揭示其中SM2、SM3国密算法的应用细节。无论你是开发者、测试工程师还是安全研究员掌握这套方法就等于掌握了定位GB35114认证类问题的“手术刀”。2. 环境准备与核心概念澄清在开始抓包前我们需要一个清晰的实验环境和明确的技术概念避免后续分析时产生混淆。2.1 实验环境搭建要点一个理想的抓包环境需要满足“流量可见”和“场景可控”两个条件。网络拓扑设计最简单的办法是使用网络集线器Hub或者配置端口镜像的交换机。将待分析的GB35114设备如IPC摄像机、SIP服务器以及运行Wireshark的抓包主机全部连接到同一个广播域。如果条件有限也可以在设备或服务器所在的单台电脑上安装Wireshark抓取本地回环或物理网卡流量但这要求设备或服务器软件本身运行在该机器上。设备与服务器配置设备端准备一台支持GB35114-C级及以上安全要求的摄像机或编码器。确保其已正确配置SIP服务器的地址、端口、本地SIP ID如34020000001320000001以及对应的SM2私钥证书。服务器端搭建或使用一个支持GB35114标准的SIP服务器如某些开源媒体服务器国密插件或商业安防平台。确保服务器端已导入设备对应的SM2公钥证书。关键一步在设备上触发一次“注册”或“心跳”操作。通常设备上电或手动重启SIP服务后会主动向服务器发起注册请求这是抓取双向认证流程的最佳时机。Wireshark安装与基础配置从官网下载安装最新稳定版。安装时注意勾选“Install Npcap”或“WinPcap”这是抓包所必需的驱动。首次启动在“捕获”-“选项”中选择正确的网络接口通常是连接实验网络的那块网卡。为了快速定位SIP流量我们可以在捕获过滤器中输入port 5060或port 5061如果使用TLS。GB35114中SIP默认使用5060端口进行非加密传输信令本身有数字签名保护但有时也会用5061的SIPS。先抓5060端口是通用做法。2.2 GB35114 SIP双向认证的核心逻辑这里需要先理清几个容易混淆的概念这对后续看懂数据包至关重要。双向认证 vs 单项认证双向认证意味着通信的双方设备与服务器要互相证明“我是我”。设备向服务器注册时要证明自己是合法设备服务器接受注册前也要向设备证明自己是合法的平台。这不同于只需输入密码的单向认证。数字签名与摘要算法的作用SM3这是一种密码杂凑算法你可以理解为一种特殊的“指纹提取器”。它会把任意长度的原始数据如SIP消息头消息体转换成一个固定长度256位的唯一“数字指纹”摘要。只要原始数据有一个比特的改动这个指纹就会完全不同。在GB35114中SM3主要用于生成待签名数据的摘要。SM2这是一种基于椭圆曲线的非对称密码算法包含加密、解密、签名和验签功能。在SIP双向认证中我们主要用到其数字签名功能。流程是发送方如设备用自身的SM2私钥对SM3生成的“数据指纹”进行签名运算生成一个签名值并将这个签名值连同原始数据、自身的公钥证书一起发送出去。接收方如服务器则用发送方的SM2公钥去验证这个签名如果验证通过就证明了两件事1. 数据在传输过程中未被篡改完整性2. 数据确实来自于持有对应私钥的发送方身份真实性。SIP消息中的承载方式在GB35114中SM2签名信息通常封装在SIP消息的Authorization或Proxy-Authorization头域中或者作为特定的消息体如application/gb35114-xxx类型的一部分。具体格式需参照标准文档但核心元素一般包括算法标识如SM2、签名随机数、签名值本身等。注意很多初学者会把SM2签名和SM3加密混为一谈。记住在这个场景里SM3不加密它只生成摘要SM2不直接加密数据它用私钥对摘要进行签名。整个流程的目的是防篡改和身份认证而非对信令内容进行加密信令内容本身可能是明文的。3. Wireshark抓包实战与关键过滤器应用环境就绪后我们开始实际的抓包操作。漫无目的地抓取海量数据包效率极低必须熟练运用Wireshark的过滤技巧。3.1 启动捕获与初步过滤在Wireshark中选择正确的网卡点击“开始捕获”按钮。触发设备的SIP注册过程。捕获到一定数量的包后点击“停止”。你可能会看到大量ARP、TCP、HTTP等无关流量。应用显示过滤器在过滤器栏输入sip。Wireshark会智能过滤出所有被识别为SIP协议的数据包。这是最常用的一步。3.2 深度过滤技巧定位认证相关报文仅仅过滤SIP还不够我们需要精准定位到携带认证信息的特定消息。过滤特定SIP方法注册流程通常始于REGISTER请求。可以使用过滤器sip.Method REGISTER。你会看到设备发往服务器的REGISTER请求和服务器回复的401 Unauthorized、200 OK等响应。过滤含有认证头域的消息认证信息主要在Authorization头域。过滤器可以写为sip.Authorization。或者更精确地结合方法一起过滤sip.Method REGISTER and sip.Authorization。跟踪完整SIP对话在任意一个SIP数据包上右键选择“追踪流” - “TCP流”或“UDP流”SIP通常用UDP但也有用TCP的。Wireshark会弹出一个新窗口只显示该次SIP会话的所有相关数据包并按顺序排列这对于分析一个完整的注册交互流程非常直观。基于IP地址过滤如果你知道设备和服务器的IP可以直接用ip.src 192.168.1.100 or ip.dst 192.168.1.100这样的过滤器再结合sip进行二次过滤。实操心得我习惯先用sip过滤器看全局找到一个REGISTER请求后右键其“SIP Call-ID”字段选择“作为过滤器应用” - “选中”。这样就能把属于同一次注册会话的所有SIP包都筛选出来上下文非常完整。4. 逐包解析一个完整的GB35114 SIP双向认证流程假设我们抓取到了一个完整的成功注册流程。下面我们按照时间顺序拆解其中最关键的几个数据包。4.1 第一回合设备发起挑战REGISTER - 401 Unauthorized数据包1设备发送初始REGISTER请求在Wireshark中找到第一个REGISTER包。查看SIP详情点击包详情窗口的“”号展开。你会看到典型的SIP头Via,From,To,Call-ID,CSeq,Contact等。关键观察点这个初始请求的Authorization头域是空的或者不包含有效的签名。这是因为设备还不知道服务器本次会话要求使用哪种认证方式Digest算法。它只是在声明“我是34020000001320000001我想注册。”在To和From字段你会看到设备的SIP URI通常格式是sip:34020000001320000001domain。数据包2服务器回复401 Unauthorized服务器收到未经验证的注册请求后会回复401 Unauthorized。这是认证开始的标志展开这个响应包重点查看WWW-Authenticate头域。这个头域包含了服务器下发的“挑战”信息。在GB35114中它可能看起来像这样WWW-Authenticate: Digest realm34020000002000000001, nonce7a1f2c83e5d9b4, algorithmSM2, qopauth, sm2-sign-algSM3字段解读realm认证域通常是服务器的SIP ID。nonce一个服务器生成的随机数每次401响应都不同。这是防止重放攻击的关键。设备在后续计算签名时必须将这个nonce值纳入待签名数据中。algorithm指明使用SM2算法进行签名。sm2-sign-alg指明签名时使用的摘要算法为SM3。qop保护质量auth表示只进行身份认证。注意事项这个nonce至关重要。很多认证失败的问题就出在这里——设备端没有正确地从401响应中提取这个nonce或者提取了但没有在后续签名计算中使用它。务必在Wireshark中核对设备发出的第二个REGISTER请求中的nonce是否与此处服务器下发的一致。4.2 第二回合设备应答挑战带签名的REGISTER数据包3设备发送带Authorization的REGISTER请求设备收到401挑战后会重新构造一个REGISTER请求这次会携带完整的Authorization头域。展开这个请求包详细查看Authorization头域。这是整个分析的核心。其内容会比标准的SIP Digest认证复杂包含了国密特有的字段。一个简化示例如下Authorization: Digest username34020000001320000001, realm34020000002000000001, nonce7a1f2c83e5d9b4, algorithmSM2, responsexxxx...很长一串Base64编码的SM2签名值, sign-algSM3, certMI...Base64编码的设备SM2公钥证书关键字段深度解析username设备SIP ID。realm和nonce必须与服务器401响应中下发的完全一致。algorithm和sign-alg同上声明使用SM2和SM3。response这就是SM2签名值经过Base64编码。这个值是如何产生的呢根据GB35114待签名的数据即SM3的输入通常包括username、realm、nonce、SIP方法REGISTER、SIP Request-URI等字段按照特定格式拼接而成的字符串。设备用自身的SM2私钥对这个字符串的SM3摘要进行签名得到签名结果编码后放入response。cert设备SM2公钥证书的DER格式再进行Base64编码。服务器需要用这个证书里的公钥来验证上面的response签名。这里就是最容易出错的环节。你需要理解response字段不是密码而是一个密码学运算的结果。验证双方必须对“待签名数据字符串的拼接规则”有完全一致的约定。标准中对此有明确定义但不同厂商在实现时可能有细微差异。4.3 第三回合服务器验证并回应200 OK / 4xx数据包4服务器回复200 OK 或 4xx错误服务器收到带签名的REGISTER后会进行验签操作从cert字段解析出设备的SM2公钥。按照同样的规则自己拼接出待验证的“数据字符串”。使用SM3计算该字符串的摘要。使用SM2公钥对response字段解码后的签名值进行验签运算核对是否与计算出的摘要匹配。如果验签成功服务器会回复200 OK表示注册成功。这个响应包本身也可能包含一个Authentication-Info头域其中携带了服务器对设备的挑战信息如一个新的nonce以及服务器自身的签名以此完成服务器对设备的认证即“双向”中的另一向。你需要检查这个头域其格式可能与Authorization类似但使用了SM2等算法标识。如果验签失败服务器会回复403 Forbidden等4xx错误。此时Wireshark抓包就派上了用场。你可以对比设备发送的Authorization头和服务器期望的格式逐一检查每个字段。5. 国密算法细节在数据包中的体现仅仅看到字段名是不够的我们需要知道如何验证这些密码学操作。5.1 如何验证SM3摘要的正确性虽然Wireshark无法直接解析国密算法但我们可以进行手动验证这对定位问题极有帮助。提取待签名数据根据GB35114标准附录或你的实现文档确定待签名数据的精确拼接格式。例如可能是username:realm:nonce:method:uri这样的字符串。计算SM3摘要使用一个在线的SM3计算工具搜索“SM3在线计算”或本地国密库如gmssl将上一步拼接的字符串输入计算其SM3哈希值一个64位的十六进制字符串。记作HASH_LOCAL。从response中反推response是SM2签名值。SM2签名是基于SM3摘要和椭圆曲线数字签名算法ECDSA产生的。我们无法直接从签名值反推出摘要。但是我们可以用服务器同样的方法来验证使用设备的公钥和这个签名去验证我们本地计算的HASH_LOCAL。这需要编写简单的脚本或使用gmssl命令行工具。实操示例使用OpenSSL/GmSSL命令行思路 假设你已拥有设备的SM2公钥文件device_pub.pem和从数据包中提取的待签名原始数据data_to_sign.txt以及Base64解码后的签名值signature.bin。# 1. 计算数据的SM3摘要 (使用gmssl) gmssl sm3 -hex -in data_to_sign.txt # 输出摘要值例如66c7f0f462eeedd9d1f2d46bdc10e4e24167c4875cf2f7a2297da02b8f4ba8e0 # 2. 使用SM2公钥验证签名 (此命令为示例具体参数需参考gmssl文档) gmssl sm2utl -verify -in data_to_sign.txt -sigfile signature.bin -pubin -inkey device_pub.pem -id 1234567812345678 # 如果验证成功会输出“Verification Success”踩过的坑待签名数据的拼接规则必须百分百准确包括字段顺序、分隔符是冒号、逗号还是空格、字段本身是否包含引号、是否对URI进行了规范化处理如去除transport参数等。一个字符的差异都会导致SM3摘要完全不同从而使验签失败。务必与服务器侧开发人员确认拼接规则。5.2 解析SM2公钥证书Authorization头中的cert字段是Base64编码的DER格式证书。你可以将其复制出来保存为cert.b64然后解码并查看内容。# 将Base64编码的证书解码为DER二进制文件 base64 -d cert.b64 cert.der # 使用openssl查看证书内容如果是X.509格式GB35114证书通常基于X.509 openssl x509 -in cert.der -inform DER -text -noout查看证书内容确认其主题Subject中的CN通用名称是否与设备的SIP ID一致确保证书在有效期内并且其公钥算法标识为sm2。6. 常见问题排查与Wireshark高级技巧当认证失败时利用Wireshark进行对比分析是最高效的手段。6.1 典型认证失败场景排查表现象 (Wireshark观察)可能原因排查思路设备持续发送不带Authorization的REGISTER服务器持续回复401设备未正确处理401挑战或配置中未启用国密认证。检查设备日志确认是否收到并解析了401。检查设备安全等级配置是否为GB35114 C级或以上。设备发送带Authorization的REGISTER后立即收到403 Forbidden签名验证失败。这是最常见的问题。1.核对nonce对比设备请求中的nonce与服务器上一次401响应的nonce是否一致。2.核对证书检查cert字段是否完整能否正确解析出公钥。3.验证签名按照第5.1节的方法手动验证签名。重点检查待签名数据拼接规则。服务器回复200 OK后连接很快断开或没有后续信令服务器对设备的认证通过了但设备对服务器的认证双向可能失败。检查服务器的200 OK响应中是否包含Authentication-Info头域以及设备是否正确处理了其中的服务器签名。Wireshark中完全看不到SIP协议解析显示为UDP数据Wireshark未正确解码SIP流量。可能端口非标准或数据加密。1. 尝试右键数据包 - “解码为...” - 选择SIP协议。2. 检查是否使用了TLSSIPS如果是需要配置RSA密钥解密国密场景复杂通常信令不加密。Authorization头中algorithm字段不是SM2设备与服务器认证算法协商不一致。检查设备能力集和服务器支持的算法列表。确保双方都支持并首选SM2。6.2 Wireshark高级分析技巧自定义显示列在包列表栏右键选择“列首选项”可以添加自定义列。例如添加“SIP Call-ID”和“SIP CSeq”列能让你更容易跟踪同一会话的不同请求/响应。使用“专家信息”Wireshark底部有一个“专家信息”标签页它会汇总抓包文件中的警告、错误、注释。例如如果SIP消息格式有误这里可能会有提示。导出对象如果SIP消息体中携带了证书文件等数据可以尝试使用“文件”-“导出对象”-“HTTP”来提取。对比分析抓取一次成功的注册包和一次失败的注册包保存为两个文件。使用Wireshark的“比较”功能需要借助第三方插件或手动并列窗口逐字段对比两个Authorization头的差异往往能快速定位问题。我个人在实际排查中最常用的一招是在设备端和服务器端的关键代码处打日志分别打印出它们各自拼接的待签名字符串和计算出的SM3摘要。然后在Wireshark中抓包把这两个日志值和网络上的数据包信息进行比对。一旦发现设备端计算的摘要与服务器端根据收到的数据计算出的摘要不一致那么问题就一定出在数据拼接环节。这个“三角核对法”几乎能解决所有因算法实现差异导致的认证问题。通过这样一次从环境搭建、抓包过滤、逐包解析到算法验证的完整旅程你不仅能看懂GB35114 SIP双向认证的数据包更能掌握一套定位和解决复杂认证问题的通用方法论。下次再遇到“认证失败”你大可以淡定地打开Wireshark让数据包告诉你真相。
