51学通信

深度解析 3GPP TS 33.514：4.2.1 用户隐私保护 (SUCI解密的攻防艺术)

20分钟阅读

深度解析 3GPP TS 33.514：4.2.1 用户隐私保护 (SUCI解密的攻防艺术)

本文技术原理深度参考了3GPP TS 33.514 V18.3.0 (2024-06) Release 18规范中，关于“4.2.1 User Privacy Procedure”及其子章节“4.2.1.1 至 4.2.1.3”的核心内容。本文将带您深入5G隐私保护的核心腹地，揭示UDM是如何安全地解开用户临时的加密面具（SUCI），还原其真实身份（SUPI），并抵御针对这一过程的各种恶意攻击。

开工！为“数字保险库”安装第一道精密门锁

在上一篇文章中，新人工程师小王和导师陈姐为“FutureComm”公司的UDM产品“IdentiCore-UDM”绘制了宏伟的施工蓝图。现在，万事俱备，真正的建造工作开始了。

陈姐将第一个，也是最艰巨的任务交给了小王：“小王，你的第一个任务，就是为我们的‘保险库’安装第一道，也是最精密的一道门锁。这道锁，就是用户隐私保护程序——SUCI解密模块。它不像物理门锁那样用钥匙开，而是用复杂的密码学算法。它不仅要能为合法用户（带着正确的‘加密信物’SUCI）打开大门，更要能识别并拒绝所有伪造的、格式错误的、甚至‘有毒’的信物，同时保证自己不会被这些恶意信物‘毒’死。去吧，把规范4.2.1节的每一个要求，都变成我们产品中坚不可摧的代码。”

小王深知这项任务的份量。SUCI的正确解密，是整个5G认证流程的起点，也是5G相对于4G在隐私保护上的革命性进步。他打开了规范4.2.1节，开始了这场与密码学和安全健壮性的正面交锋。

1. SUCI解密 (4.2.1.1)：“ happy path”下的身份还原

测试的第一步，永远是验证核心功能在正常情况下的正确性，也就是我们常说的“happy path”。

1.1 从“加密面具”到真实身份的艺术

在深入测试之前，陈姐先给小王巩固了SUCI的工作原理。她打了一个生动的比方： “想象一下，用户（UE）要给UDM寄一封包含自己真实身份（SUPI）的绝密信件。他不能直接寄，因为信使（空口）可能会偷看。”

  1. 准备信封：用户会用一张一次性的、只有自己知道的“临时信纸”（UE的临时密钥对）来写信。
  2. 加密信件：他会用运营商公开发布的“保险箱公钥”（归属网络公钥 Home Network Public Key）将这封装有SUPI的信件锁进一个“加密保险箱”里。
  3. 附上回邮地址：最后，他会把那张“临时信纸”对应的“公钥”贴在保险箱外面，作为“回邮地址”。 这个包含了“加密保险箱”和“回邮地址”的包裹，就是SUCI。

当UDM收到这个SUCI后，其内部的**SIDF（身份解密功能）**会用自己珍藏的“保险箱私钥”打开保险箱，从而安全地获得用户的真实SUPI。

1.2 规范原文

4.2.1.1 De-concealment of SUPI from the SUCI based on the protection scheme used to generate the SUCI Requirement Name: De-concealment of SUPI from the SUCI based on the protection scheme used to generate the SUCI. Requirement Reference: TS 33.501, clause 5.8.2. Requirement Description: The SIDF resolves the SUPI from the SUCI based on the protection scheme used to generate the SUCI as specified in TS 33.501, clause 5.8.2. Threat References: TR 33.926, clause E.2.2.1, Incorrect SUCI de-concealment.

Test Case: Test Name: TC_DE-CONCEAL_SUPI_from_SUCI_UDM Purpose: Verify that the SIDF De-conceals the SUPI from the SUCI based on the protection scheme used to generate the SUCI.

1.3 深度解读与测试实践

需求解读 (The “What” and “Why”)

  • 核心要求：UDM的SIDF功能必须能够根据正确的加密方案（如Profile B的ECIES），从一个合法的SUCI中正确地解密出原始的SUPI。
  • 为何重要？ 这是整个功能的基础。如果一个合法的用户，发送了一个完全正确的SUCI，而UDM却无法解密，那么这个用户将永远无法接入网络。这会造成大范围的合法用户服务中断（Denial of Service）。

测试用例解读 (The “How to Verify”)

  • 目标 (Purpose)：验证UDM在正常路径下，能正确地“解信封”。
  • 测试环境 (Pre-Condition)：
    • 搭建一个包含待测UDM、模拟AUSF和模拟AMF的网络环境。
    • 测试人员必须预先知道UE的真实SUPI，以便后续进行比对。这是一个典型的“白盒测试”。
  • 执行步骤 (Execution Steps)：
    1. 测试工具模拟一个UE，使用归属网络的公钥，将一个已知的SUPI加密成一个合法的SUCI。
    2. 模拟UE发起注册流程，将这个SUCI发送给网络。
    3. 使用抓包工具（如Wireshark，并配置好TLS解密），捕获UDM与AUSF之间的N13接口（或者UDM/AUSF与AMF之间的N12接口）的交互报文。
    4. 在抓包结果中，找到UDM发给AUSF的Nudm_UEAuthentication_Get Response消息，或者AUSF发给AMF的Nausf_UEAuthentication_Authenticate Response消息。根据5G AKA流程，认证成功后，这些消息中会包含由UDM解密出的SUPI。
    5. 核心比对：将消息中提取出的SUPI，与我们第一步中已知的原始SUPI进行逐位比对。
  • 预期结果 (Expected Results)：两者必须完全一致。这证明了UDM的SIDF解密功能是正确无误的。

2. 拒绝“毒苹果” (4.2.1.2)：抵御携带无效公钥的SUCI攻击

验证完“happy path”，真正的安全测试开始了。陈姐告诉小王：“现在，你要扮演一个坏人。你不想正面破解密码，你只想把我们的UDM搞死。有一种办法，就是喂给它一个‘有毒的苹果’——一个包含了在数学上根本不成立的公钥的SUCI。”

2.1 威胁：攻击密码库，而非密码本身

椭圆曲线密码学（ECC）是构建在严格的数学基础之上的。一个公钥，在ECC中表现为一个曲线上的“点”。如果攻击者构造一个不在约定曲线上的“点”作为UE的临时公钥来生成SUCI，会发生什么？

一个编码不健壮的密码学库，在处理这种非法的数学输入时，可能会出现除零错误、陷入死循环、或者抛出未处理的异常，最终导致整个UDM服务进程崩溃。这是一种非常阴险的、旨在造成拒绝服务的健壮性攻击。

2.2 规范原文

4.2.1.2 Rejection of SUCIs using an ECIES protection scheme with an invalid public key. Requirement Name: Rejection of SUCIs using an ECIES protection scheme with an invalid public key. Threat References: TR 33.926, clause E.2.2.6, Invalid public key.

TEST CASE: Test Name: TC_REJECT_SUCI_PROFILE_B_INVALID_PUBKEY_UDM Purpose: Verify that the SIDF rejects the SUCI if it uses an ECIES protection scheme and contains an invalid point as the UE’s public key for Profile B. Execution Steps:

  1. The tester selects an invalid point (NOTE 1) and uses the point as a public key to encrypt the SUPI…
  2. The tester sends the SUCI to the Nudm_UEAuthentication_Get service of the UDM/SIDF under test. Expected Results: The UDM/SIDF rejects the SUCI, and the UDM sends a Nudm_UEAuthentication_Get Response message with an HTTP status code “403 Forbidden” and may include additional error information…

2.3 深度解读与测试实践

需求解读 (The “What” and “Why”)

  • 核心要求：UDM的SIDF在执行解密操作之前，必须先对SUCI中包含的UE临时公钥进行数学有效性校验。如果该点不在指定的椭圆曲线上，必须立刻拒绝该SUCI。
  • 为何重要？ 这是对UDM密码学组件健壮性的“生死考验”。一个合格的UDM，绝不能因为收到恶意的、不符合数学规范的输入而崩溃。

测试用例解读 (The “How to Verify”)

  • 目标 (Purpose)：验证UDM能拒绝包含无效公钥的SUCI。
  • “毒苹果”的配方：最棒的是，规范非常贴心地在NOTE 1中，直接给出了一个经过验证的、可用于Profile B的“无效点”的例子！这大大降低了测试的准备难度。
  • 执行步骤 (Execution Steps)：
    1. 构造恶意SUCI：测试工程师使用规范中提供的那个“无效点”作为UE的临时公钥，并遵循ECIES加密流程，加密一个任意的SUPI，从而构造出一个“有毒”的SUCI。
    2. API调用：直接通过API测试工具（如Postman），调用UDM的Nudm_UEAuthentication_Get服务接口，将这个恶意的SUCI作为请求参数发送过去。
  • 预期结果 (Expected Results)：
    • UDM绝不能崩溃。这是最重要的黄金标准。
    • UDM必须拒绝这个请求。
    • UDM必须返回一个标准的HTTP 403 Forbidden错误码。
    • 更进一步，规范要求其响应体（Body）中应包含一个ProblemDetails元素，其中的错误原因可能是AUTHENTICATION_REJECTED或INVALID_SCHEME_OUTPUT。这体现了对SBA接口错误处理规范性的要求。

3. 遵守规则的洁癖 (4.2.1.3)：拒绝使用未压缩公钥的SUCI

最后一道防线，考验的是UDM对协议规范“一丝不苟”的遵守能力。

3.1 效率与安全的统一：为何要强制压缩？

在椭圆曲线密码学中，一个点（公钥）可以用(x, y)坐标对来表示。但由于曲线的对称性，知道了x和y的一个比特（奇偶性），就可以计算出完整的y。**点压缩（Point Compression）**技术就是利用这一点，只传输x和y的一个比特，从而将公钥的大小缩减近一半（例如，从65字节减为33字节）。

3GPP为SUCI加密的Profile B方案强制规定，必须使用点压缩格式。这不仅仅是为了节省一点点的空口带宽，更重要的是：

  • 消除歧义：标准中只允许一种格式，可以避免因支持多种格式而可能引入的解析器漏洞。
  • 强化合规：一个连标准格式都不遵守的终端，很可能是恶意的或有缺陷的。严格拒绝非标格式，是一种有效的安全策略。

3.2 规范原文

4.2.1.3 Rejection of SUCIs using an uncompressed point with Profile B. Requirement Name: Rejection of SUCIs using an uncompressed point with Profile B. Requirement Description: Profile B shall use point compression to save overhead…

TEST CASE: Test Name: TC_REJECT_SUCI_PROFILE_B_NO_COMPRESSION_UDM Purpose: Verify that the SIDF rejects the SUCI if it uses the ECIES Profile B protection scheme and contains an uncompressed point as the UE’s public key. Execution Steps:

  1. The tester shall generate a SUCI … The ephemeral public key of the UE should be in the uncompressed point format…

3.3 深度解读与测试实践

需求解读 (The “What” and “Why”)

  • 核心要求：当使用Profile B方案时，UDM的SIDF必须拒绝那些包含未压缩格式公钥的SUCI。
  • 为何重要？ 这是对UDM协议遵从性的严格考验。一个安全的系统，必须对所有输入执行严格的格式校验，任何偏离规范的行为都应被视为潜在的威胁。

测试用例解读 (The “How to Verify”)

  • 执行步骤 (Execution Steps)：
    1. 构造非标SUCI：测试工程师这次使用一个数学上有效但格式不合规的公钥（即未压缩格式，规范在NOTE 1中给出了其格式特征：65字节，且以0x04开头）来生成SUCI。
    2. API调用：同样，通过API工具将这个非标的SUCI发送给UDM。
  • 预期结果 (Expected Results)：与上一个测试完全相同。UDM必须保持稳定，并返回HTTP 403 Forbidden错误，同时附带详细的错误原因。

总结：UDM隐私门锁的三重保险

经过这轮严苛的测试，小王成功地为“IdentiCore-UDM”构建并验证了其第一道，也是最核心的安全门锁。这道锁具备了三重保险：

  1. 功能保险 (Correctness)：能为合法用户正确开锁 (4.2.1.1)。
  2. 健壮性保险 (Robustness)：能识别并拒绝“有毒”的、数学上无效的钥匙，且自身不会被毒死 (4.2.1.2)。
  3. 合规性保险 (Compliance)：能识别并拒绝“样式不符”的、不符合标准格式的钥匙 (4.2.1.3)。

这三项要求层层递进，从功能、健壮性和协议遵从性三个维度，完整地定义了UDM在处理用户隐私标识时的安全行为。通过这些测试，确保了UDM不仅能完成任务，还能在面对恶意攻击时，优雅、安全地拒绝服务，从而守护整个5G网络的入口安全。小王的征程，才刚刚开始。

FAQ 环节

Q1：什么是SUCI加密的Profile A和Profile B？ A1：这是3GPP定义的两种SUPI保护方案。Profile A是“空加密方案”（null-scheme），它实际上并不加密SUPI，只是对其进行格式封装，适用于那些拥有其他安全机制（如在安全的物理线路中）或隐私要求不高的场景。Profile B则是基于ECIES（椭圆曲线集成加密方案）的强加密方案，它使用归属网络的公钥来加密SUPI，是实现5G用户防追踪隐私保护的核心技术。本章节的所有测试都是针对Profile B的。

Q2：测试用例中提到的HTTP “403 Forbidden”是什么意思？为什么不用”400 Bad Request”？ A2：这是一个关于API设计哲学的体现。“400 Bad Request”通常表示客户端发送的请求在语法上就是错误的（比如，JSON格式损坏）。而在这里，客户端发送的SUCI请求，其JSON结构和语法都是正确的，但其“内容”——SUCI本身，因为安全策略（无效公钥、非标格式）而被服务器拒绝。因此，“403 Forbidden”（服务器理解请求，但拒绝执行）是更语义化、更准确的错误码，表明这是一个认证/授权/策略层面的拒绝。

Q3：构造这些恶意的SUCI，对测试工程师的技能要求是不是很高？ A3：是的，这需要测试工程师具备一定的密码学知识和编程能力。他们需要理解ECIES的基本流程，并能够使用Python的cryptography库或类似工具，来精确控制椭圆曲线点的生成（包括生成无效点和未压缩点），并完成加密和编码。不过，3GPP规范在这方面非常友好，它直接提供了无效点的具体数值和未压缩点的格式特征，大大降低了测试的门槛，使得测试的可复现性非常高。

Q4：如果一个UDM产品没能通过4.2.1.2（拒绝无效公钥）的测试，最坏的后果是什么？ A4：最坏的后果是，攻击者可以通过互联网，向运营商网络中的UDM发送一个精心构造的SUCI，导致UDM的核心服务进程崩溃并重启。如果攻击者持续不断地发送这种“毒苹果”，就可以让UDM陷入一个“崩溃-重启-再崩溃”的循环中，从而导致全网（或大片区域）的所有用户都无法进行注册和认证，造成灾难性的拒绝服务攻击。

Q5：这些测试是在实验室环境完成的。在真实的现网环境中，UDM还会面临哪些与SUCI相关的其他挑战？ A5：现网环境更复杂。除了要抵御恶意攻击，UDM还需要应对：1) 归属网络公钥的管理：公钥需要定期轮换，UDM需要能够平滑地处理新旧公钥的更替。2) 性能挑战：在城市中心等高话务区域，UDM的SIDF需要具备极高的性能，每秒可能要处理成千上万个SUCI的解密请求。3) 多厂商终端的兼容性：需要确保能够正确处理来自全球不同手机厂商、遵循相同规范但实现细节可能略有差异的终端所生成的SUCI。

关系图谱