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:34020000001320000001@domain。
数据包2：服务器回复401 Unauthorized
- 服务器收到未经验证的注册请求后，会回复401 Unauthorized。
- 这是认证开始的标志！展开这个响应包，重点查看WWW-Authenticate头域。这个头域包含了服务器下发的“挑战”信息。在GB35114中，它可能看起来像这样：
```
WWW-Authenticate: Digest realm="34020000002000000001", nonce="7a1f2c83e5d9b4", algorithm=SM2, qop="auth", sm2-sign-alg=SM3
```
- 字段解读：
  - 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 username="34020000001320000001", realm="34020000002000000001", nonce="7a1f2c83e5d9b4", algorithm=SM2, response="xxxx...（很长一串Base64编码的SM2签名值）", sign-alg=SM3, cert="MI...（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后，会进行验签操作：
  1. 从cert字段解析出设备的SM2公钥。
  2. 按照同样的规则，自己拼接出待验证的“数据字符串”。
  3. 使用SM3计算该字符串的摘要。
  4. 使用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. 检查是否使用了TLS（SIPS），如果是，需要配置RSA密钥解密（国密场景复杂，通常信令不加密）。
`Authorization`头中`algorithm`字段不是`SM2`	设备与服务器认证算法协商不一致。	检查设备能力集和服务器支持的算法列表。确保双方都支持并首选SM2。

6.2 Wireshark高级分析技巧

自定义显示列：在包列表栏右键，选择“列首选项”，可以添加自定义列。例如，添加“SIP Call-ID”和“SIP CSeq”列，能让你更容易跟踪同一会话的不同请求/响应。
使用“专家信息”：Wireshark底部有一个“专家信息”标签页，它会汇总抓包文件中的警告、错误、注释。例如，如果SIP消息格式有误，这里可能会有提示。
导出对象：如果SIP消息体中携带了证书文件等数据，可以尝试使用“文件”->“导出对象”->“HTTP”来提取。
对比分析：抓取一次成功的注册包和一次失败的注册包，保存为两个文件。使用Wireshark的“比较”功能（需要借助第三方插件或手动并列窗口），逐字段对比两个Authorization头的差异，往往能快速定位问题。

我个人在实际排查中最常用的一招是：在设备端和服务器端的关键代码处打日志，分别打印出它们各自拼接的待签名字符串和计算出的SM3摘要。然后，在Wireshark中抓包，把这两个日志值和网络上的数据包信息进行比对。一旦发现设备端计算的摘要与服务器端根据收到的数据计算出的摘要不一致，那么问题就一定出在数据拼接环节。这个“三角核对法”几乎能解决所有因算法实现差异导致的认证问题。

通过这样一次从环境搭建、抓包过滤、逐包解析到算法验证的完整旅程，你不仅能看懂GB35114 SIP双向认证的数据包，更能掌握一套定位和解决复杂认证问题的通用方法论。下次再遇到“认证失败”，你大可以淡定地打开Wireshark，让数据包告诉你真相。