51学通信

深度解析 3GPP TS 33.517：4.2.2 信任的基石 (密码材料隔离与身份校验)

20分钟阅读

深度解析 3GPP TS 33.517：4.2.2 信任的基石 (密码材料隔离与身份校验)

本文技术原理深度参考了3GPP TS 33.517 V18.0.0 (2023-06) Release 18规范中，关于“4.2 SEPP-specific adaptations of security functional requirements and related test cases”及其子章节“4.2.2.1 至 4.2.2.4”的核心内容。本文将带您深入5G漫游安全的心脏地带，揭示SEPP作为“国门卫士”最核心的职责：如何建立跨国界的初始信任，严格隔离和校验各方密码学凭证，并确保每一个跨域信令都来源清晰、身份无误。

“国门卫士”的第一道岗哨：验证外交官的“全套凭证”

在为“Guardian-SEPP”项目举行了庄严的“上岗仪式”后，项目总监周工带领新成员小雅，开始了核心防御系统的构建。他们要建立的，是这座“边境哨所”的第一道，也是最关键的一道岗哨——信任建立与身份验证。

“小雅，”周工在白板上画了两个国家的边境线，中间还有一个代表IPX的“中立区”，“我们的哨所（SEPP）每天都要处理成百上千次来自‘友军哨所’的通信请求。我们的第一个，也是最重要的任务，就是要学会如何鉴别‘外交官’的全套凭证。这套凭证非常复杂，它不仅包括了‘外交官’本人的护照（对端SEPP的证书），还可能包括了‘国际快递公司’（IPX提供商）的运货单（IPX的签名证书）。我们的职责，就是要确保绝不混淆这两者，并且要对凭证上的每一个细节，如国籍、有效期等，进行最严格的核查。任何一点疏忽，都可能导致间谍渗透或情报泄露。”

这番话，让小雅立刻明白了接下来的任务有多么艰巨。他们要面对的，不是单一的信任关系，而是一个涉及多方、信任链条脆弱的复杂博弈。

1. 奠定基础：强制遵循5G安全架构 (4.2.2.1)

在进入具体的安全要求之前，规范首先在4.2.2.1节下达了一道不容置疑的“最高指令”。

4.2.2.1 Security functional requirements on the SEPP deriving from 3GPP specifications – general approach

…an SEPP shall satisfy the following:

  • It is assumed for the purpose of the present SCAS that an SEPP conforms to all mandatory security-related provisions pertaining to an SEPP in:
  • 3GPP TS 33.501: “Security architecture and procedures for 5G system”;

深度解读:

这段话的核心是强制合规。它明确规定，进行本SCAS测试的前提是，被测的SEPP产品必须已经完全符合了5G安全总纲TS 33.501中所有与SEPP相关的强制性安全规定。这等于是在说：“在你参加这场‘特种兵’选拔（SCAS测试）之前，你必须已经是一名合格的‘正规军’（符合33.501）。” 这为后续所有更具体的安全测试，奠定了坚实的基础。

2. 密码材料的严格隔离 (4.2.2.2)：绝不混淆“外交官”与“快递员”

这是SEPP作为密码学网关最核心的安全职责之一，也是防止复杂漫游场景下中间人攻击的关键。

2.1 威胁：当“快递员”拿到了“外交官”的印章

在5G漫游场景中，两个运营商（A国和B国）的SEPP之间的通信，通常会经过一个或多个IPX（IP eXchange）提供商。IPX提供商在转发消息时，也可能需要对消息进行修改（如添加路由信息）并签名，以证明“此消息经我手，内容无误”。

这就产生了两类完全不同性质的密码材料：

  1. SEPP的密码材料：用于SEPP之间的端到端（End-to-End）认证和应用层加密，代表了通信的最终端点。这好比是A国外交官的“国徽印章”。

  2. IPX的密码材料：用于**逐跳（Hop-by-Hop）**认证，证明消息经过了某个中间节点。这好比是国际快递公司FedEx的“转运章”。

核心威胁：如果SEPP无法清晰地区分这两类密码材料，会发生什么？一个恶意的（或被攻破的）IPX，就可以：

  • 伪造签名：它在修改了消息内容后，不用自己的“转运章”，而是盗用或伪造A国外交官的“国徽印章”来签名。B国的SEPP如果信以为真，就会认为这些修改是A国SEPP做的，从而接受了可能包含恶意代码或虚假信息的篡改内容。

2.2 规范原文

4.2.2.2 Correct handling of cryptographic material of peer SEPPs and IPX providers

Requirement Name: Correct handling of cryptographic material of peer SEPPs and IPX providers

Requirement Description: The SEPP is able to clearly differentiate between certificates used for authentication of peer SEPPs and certificates used for authentication of intermediates performing message modifications.

Test Case:

Test Name: TC_CRYPT_MATERIAL_SEPP_IPX_SEPARATION

Purpose: Verify that the SEPP under test does not accept raw public keys/certificates by intermediate IPX-providers for N32-c TLS connection establishment. The opposite is to be ensured as well: The SEPP under test shall not accept N32-f JSON patches signed with raw public keys/certificates of peer SEPPs.

2.3 深度解读与测试实践

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

  • 核心要求：SEPP必须能够清晰地区分并隔离用于端到端SEPP认证的密码材料和用于中间IPX认证的密码材料，且绝不混用。

  • 为何重要？ 这是为了在存在可信度较低的中间网络（IPX）时，依然能够建立真正意义上的、端到端的安全信任链。它确保了“快递员”永远只能扮演“快递员”的角色，绝不能染指“外交官”的权力。

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

这个测试用例设计了两个巧妙的、互为反向的场景来验证这种隔离能力。

  • 场景一：验证“快递员”不能建立“外交热线” (Misusing IPX key for N32-c)

    1. 正常流程：两个SEPP（SEPP-A和SEPP-B）先建立正常的N32连接。在这个过程中，它们可能会交换IPX提供商的公钥，以便后续验证IPX的签名。

    2. 攻击模拟：测试工具现在扮演一个恶意角色，它尝试使用刚刚得知的那个IPX提供商的私钥，来与SEPP-B发起一条全新的N32-c TLS连接。

    3. 预期结果：SEPP-B必须拒绝这个连接请求。因为建立N32-c这种“外交热线”的凭证，必须是对方SEPP的证书，而绝不能是IPX的证书。

  • 场景二：验证“快递员”不能盗用“国徽印章” (Misusing SEPP key for N32-f patch)

    1. 正常流程：SEPP-A通过一个模拟的IPX系统，向SEPP-B发送一条N32-f消息。

    2. 攻击模拟：模拟的IPX系统对这条消息进行修改（例如，添加一个JSON-patch），然后需要对这个修改进行签名。但它不使用自己的IPX私钥，而是盗用了SEPP-A的私钥来签名。

    3. 预期结果：当SEPP-B收到这个被篡改和伪造签名的消息时，它必须丢弃那个被伪造签名的JSON-patch。因为它期望来自IPX的修改，必须由IPX的密钥来签名。

3. 密码材料的“连接专属”原则 (4.2.2.3)：昨天的通行证不能用于今天

信任不仅要区分角色，还要有时效性和上下文的绑定。

3.1 威胁：跨连接的凭证滥用

假设A国和B国的SEPP之间，因为不同的业务，建立了两条并行的N32连接（Connection-1和Connection-2）。在Connection-1中，它们交换了IPX-Provider-X的公钥（KEY_X）。在Connection-2中，它们交换了IPX-Provider-Y的公钥（KEY_Y）。

核心威胁：如果一个消息在Connection-1上传输，但中间的IPX-Provider-Y（它本应只在Connection-2中活动）截获并修改了它，然后用自己的KEY_Y来签名。如果接收方SEPP没有将密钥和连接进行严格绑定，它可能会错误地接受这个签名，因为它确实认识KEY_Y。这就造成了跨连接的权限滥用。

3.2 规范原文

4.2.2.3 Connection-specific scope of cryptographic material by IPX-providers

Requirement Description: Cryptographic material from IPX providers … is only valid for the N32 connection it is exchanged in. The SEPP under test shall not accept N32-f message modifications signed by IPX-providers other than the ones whose cryptographic material has been exchanged as part of the IPX security information list via the related N32-c connection.

3.3 深度解读与测试实践

  • 核心要求：从一个IPX提供商获取的密码材料（公钥/证书），其有效范围仅限于交换该材料的那条特定的N32连接。

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

    1. 建立连接1：两个SEPP建立N32连接-1，并在此连接中交换IPX的公钥KEY_A。

    2. 建立连接2：两个SEPP并行地建立N32连接-2，并在此连接中交换IPX的公钥KEY_B。

    3. 攻击模拟：测试工具在连接-1上发送一条N32-f消息。模拟的IPX对该消息进行修改，但使用KEY_B（属于连接-2）的私钥来签名。

    4. 预期结果：接收方SEPP必须丢弃这个修改。因为它在处理连接-1上的消息时，只认可使用KEY_A签名的修改。

4. “国籍”校验：信使与信件的PLMN ID必须一致 (4.2.2.4)

最后一道身份校验，是确保消息内容与其传输通道的身份相符。

4.1 威胁：身份声明与实际身份不符

A国SEPP和B国SEPP已经通过了严格的TLS相互认证，建立了N32-c连接。此时，B国SEPP确信，这条通道的对端就是A国SEPP。

核心威胁：A国的一个NF（如AMF）要发一个请求到B国。这个请求本身，会通过OAuth2.0机制，包含一个access token，token中会有一个subject claim，声明了“我是A国（PLMN-ID of A）的AMF”。但如果一个恶意的A国NF，伪造了这个token，在subject claim里写的却是“我是C国（PLMN-ID of C）的AMF”，然后通过A国SEPP发送出来。如果B国SEPP只校验了TLS连接的身份，而没有校验消息内部token的身份，会怎么样？它可能会错误地相信这个请求来自C国，并可能根据与C国的漫游策略来处理它，造成安全策略的绕过。

4.2 规范原文

4.2.2.4 Correct handling of serving PLMN ID mismatch

Requirement Description: The receiving SEPP verifies that the PLMN-ID contained in the incoming N32-f message matches the PLMN-ID in the related N32-f context…

4.3 深度解读与测试实践

  • 核心要求：接收方SEPP在收到N32-f消息时，必须校验消息内部access token的subject claim中所含的PLMN ID，是否与该N32连接对端SEPP的PLMN ID相匹配。

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

    1. A国SEPP（对等SEPP）和B国SEPP（被测SEPP）建立N32连接。B国SEPP记录下A国的PLMN ID。

    2. 攻击模拟：测试工具构造一个NF服务请求，其中包含一个access token。在这个token的subject claim里，故意填上一个不等于A国PLMN ID的C国PLMN ID。

    3. A国SEPP将这个包含伪造token的消息发送给B国SEPP。

    4. 预期结果：B国SEPP必须检测到这个不匹配，并向A国SEPP发送一个错误信令，拒绝处理该消息。

总结：信任链的精雕细琢

通过对这三项核心要求的攻坚，小雅深刻地认识到，5G漫游安全的信任，不是一次性的握手，而是一个持续的、多维度的、精雕细琢的校验过程。SEPP作为“国门卫士”，其第一道岗哨就设立了三重关卡：

  1. 角色关（Role Verification）：严格区分“外交官”（SEPP）和“快递员”（IPX），确保权责分明，防止角色冒用。

  2. 时空关（Context Verification）：确保凭证的有效性严格绑定在特定的时间（连接）和空间（上下文）中，防止权限的跨界滥用。

  3. 内容关（Content Verification）：确保“信件内容”的身份声明与“信使”的身份完全一致，防止内容欺诈。

这三重关卡，共同构成了5G漫游信任的基石，确保了环球旅行家“Alex”的每一次跨国通信，都建立在一条真正端到端、可验证、不可伪造的安全链路之上。

FAQ 环节

Q1：N32-c和N32-f到底是什么关系？

A1：可以这样比喻：N32-c是两国SEPP之间建立“外交关系”和“安全热线”的控制通道。它们通过N32-c进行相互的TLS认证，协商后续通信要使用的安全策略（比如，哪些IE需要加密）。而N32-f是建立在N32-c所建立的信任基础之上的业务转发通道，用于实际传输两国NF之间的信令消息。先有N32-c的安全建联，后有N32-f的安全转发。

Q2：为什么需要IPX来签名？它不是应该只负责转发吗？

A2：在复杂的漫游协议栈（GTP-C over S8的替代方案）中，IPX提供商可能不仅仅是纯粹的IP转发，还可能需要扮演一些应用层的角色，比如修改一些路由信息。为了保证这些修改是可追溯、可审计的，并且防止非法的修改，3GPP的架构允许（并推荐）IPX对其所做的修改进行数字签名（使用JWS）。SEPP则需要有能力去验证这些签名，从而信任这些修改。

Q3：什么是JSON Patch和JWS？为什么SEPP需要处理它们？

A3：JSON Patch是一种标准的、用于描述如何修改一个JSON文档的格式。例如，一个patch可以描述“将/user/name字段的值替换为’Alex’”。**JWS（JSON Web Signature）**是一种为任意数据（包括JSON Patch）进行数字签名的标准格式。在N32-f的流程中，IPX或SEPP对原始消息的修改，就是通过生成一个JSON Patch来描述的，然后用JWS对这个Patch进行签名，以保证修改的完整性和来源的真实性。因此，SEPP必须精通JWS的验证和JSON Patch的应用。

Q4：这些测试看起来非常复杂，需要模拟SEPP、IPX等多个角色，实际中如何进行？

A4：这些测试确实对测试工具和环境提出了很高的要求。在实际的认证测试中，通常会使用专业的5G核心网信令模拟器。这种模拟器可以同时扮演对等SEPP、IPX提供商、以及内部NF（如AMF）等多个角色，并具备强大的脚本能力，可以精确地构造出规范中描述的各种正常和异常的消息（如使用错误的密钥签名、包含不匹配的PLMN ID等）。

Q5：如果SEPP检测到了PLMN ID不匹配，它为什么是向对等SEPP发送错误，而不是直接丢弃？

A5：这是为了保证通信的明确性和可调试性。直接静默丢弃，会导致发送方（对等SEPP）超时，无法得知失败的具体原因。而通过在N32-c信道上返回一个明确的错误信令（包含错误码），接收方SEPP可以清晰地告知发送方：“你发来的这条N32-f消息存在身份不匹配问题，我拒绝处理。” 这使得发送方可以记录日志、触发告警，并帮助网络管理员快速定位问题是源自恶意攻击还是配置错误。

关系图谱