51学通信

深度解析 3GPP TS 33.517：4.2.2.5-8 应用层防护 (SEPP的“信令手术刀”)

19分钟阅读

深度解析 3GPP TS 33.517：4.2.2.5-8 应用层防护 (SEPP的“信令手术刀”)

本文技术原理深度参考了3GPP TS 33.517 V18.0.0 (2023-06) Release 18规范中，关于“4.2.2.5 至 4.2.2.8”的核心章节。本文将带您深入5G漫游安全的核心操作室，揭示SEPP作为应用层网关（ALG），如何挥舞起“信令手术刀”，对每一个跨域消息进行精密的检查、加密、整形和校验，从而在端到端加密的传输管道之上，再构建一道坚不可摧的应用层防线。

“国门卫士”的深度安检：打开每一个“外交邮袋”

在上一篇文章中，新人工程师小雅在项目总监周工的指导下，为“Guardian-SEPP”项目成功建立了第一道岗哨——信任建立与身份验证。他们确保了只有合法的“友军哨所”才能建立连接，并且严格区分了“外交官”和“快递员”的凭证。

“很好，小雅，”周工对前一阶段的工作表示肯定，“我们现在已经能确保所有来到我们国门口的，都是持有合法护照的、身份无误的外交官。但这只是第一步。一个真正的国门卫士，绝不能只看护照就放行。我们还必须对他们携带的每一个‘外交邮袋’（N32-f消息）进行开箱安检。我们的任务，不是简单地转发，而是要像一位顶尖的外科医生一样，对每一个信包进行‘微创手术’。”

周工在白板上画了一个信封，上面标满了各种需要检查和修改的区域。“今天，我们的任务就是学习并实现这套‘信令手术’的四大核心技术：第一，为敏感情报打上加密马赛克（IE加密替换）；第二，核对双方的安检标准是否一致（策略不匹配处理）；第三，只认可最顶级的防伪签章算法（JWS算法限制）；第四，防止有人恶意展示加密情报的索引卡（加密IE防错位）。这四项技术，是SEPP作为应用层网关的灵魂所在。”

1. 为敏感情报打上马赛克 (4.2.2.5)：IE加密与替换

这是SEPP应用层保护最核心、最直观的功能，旨在实现拓扑隐藏和端到端敏感信息保护。

1.1 威胁：当“外交电报”泄露了内部军事部署

假设A国的一个AMF要向B国的一个PCF发送一个策略请求。这个原始的HTTP/2请求中，可能包含了A国AMF的内部IP地址，或者用户的某个内部标识符。如果这个原始请求被直接转发到B国网络，即使N32传输通道是加密的，B国的运营商（或者被攻破的B国PCF）也能看到这些本应属于A国内部的信息。

1.2 规范原文

4.2.2.5 Confidential IEs replacement handling in original N32-f message Requirement Name: Confidential IEs replacement handling in original N32-f message Requirement Description: Based on the protection policy exchanged between the SEPPs, the sending SEPP prepares an input for the JWE ciphering and integrity protection… Information elements in the original message that require encryption according to the Data-type encryption policy are replaced with the value ” encBlockIdx “.

Test Case: Purpose: Verify that the SEPP under test correctly replaces information elements requiring encryption with the value ” encBlockIdx “.

1.3 深度解读与测试实践

  • 核心要求：发送方SEPP在转发N32-f消息之前，必须根据与对端SEPP预先协商好的加密策略，识别出消息中需要加密的信息元素（IEs），对它们进行**JWE（JSON Web Encryption）**加密，然后用一个占位符（encBlockIdx，指向加密后密文块的索引）替换掉原始的明文内容。
  • “信令手术”过程：
    1. 识别病灶：根据策略，找到JSON消息体中需要加密的字段（如supi或internalGroupId）。
    2. 切除并加密：将这些字段的值提取出来，使用JWE加密成一串密文。
    3. 缝合与标记：将原始字段的值替换为一个指向该密文的索引，例如"supi": "encBlockIdx:0"。
    4. 打包密文：将所有加密后的密文块打包，放在消息的一个特殊部分（protectedData）中。
  • 测试用例解读 (The “How to Verify”)：
    1. 在被测SEPP（发送方）上配置一个加密策略，例如，要求加密HTTP请求体中的/subscriber/id字段。
    2. 从SEPP的内网侧，发送一个包含明文/subscriber/id字段的HTTP请求。
    3. 捕获SEPP发往外网的N32-f消息。
    4. 预期结果：在捕获的消息中，原始的/subscriber/id字段的值必须已经被替换为"encBlockIdx"。同时，消息中必须包含一个加密的JWE对象，该对象解密后，可以还原出原始的ID值。

2. 核对安检标准 (4.2.2.6)：策略不匹配处理

“手术”的成功，前提是两位“医生”（两端SEPP）使用的是同一套手术方案。如果方案不一致，就会出问题。

2.1 威胁：当两国卫兵的“违禁品清单”不同

在N32-c建链时，A国SEPP和B国SEPP会交换各自的保护策略（包括加密策略和修改策略）。但运营商也可能为特定的漫游伙伴在SEPP上进行手动配置。

核心威胁：如果A国SEPP上为B国手动配置的策略，与B国SEPP实际发来的策略不一致（例如，A国认为supi要加密，B国发来的策略却说supi不需要加密），会发生什么？如果A国SEPP盲目遵循B国发来的策略，就会导致supi以明文形式发送，造成信息泄露。

2.2 规范原文

4.2.2.6 Correct handling of protection policy mismatch Requirement Name: Correct handling of protection policy mismatch Requirement Description: “When a SEPP receives a data-type encryption or modification policy on N32-c …, it compares it to the one that has been manually configured for this specific roaming partner… If a mismatch occurs …, the SEPP performs one of the following actions, according to operator policy: Send the error message … or Create a local warning”

Test Case: Test Name: TC_SEPP_POLICY_MISMATCH

2.3 深度解读与测试实践

  • 核心要求：SEPP在收到对端SEPP通过N32-c发来的保护策略时，必须将其与本地为该伙伴手动配置的策略进行比对。如果发生不匹配，SEPP必须根据本地策略，执行发送错误消息或创建本地告警的操作。
  • 测试用例解读 (The “How to Verify”)：
    1. 在被测SEPP（A国）上，为对等SEPP（B国）手动配置一套保护策略 (d, m)。
    2. 配置被测SEPP，使其在遇到策略不匹配时，选择“发送错误消息”的行为。
    3. 模拟对等SEPP（B国），向被测SEPP发起N32-c连接，并发送一套不同的保护策略 (d', m')。
    4. 预期结果：被测SEPP必须能够检测到不匹配，并向对等SEPP的N32-c连接上返回一个错误信令消息，明确指出策略不匹配。

3. 只认最强签章 (4.2.2.7)：JWS算法限制

安全不仅要做对，还要做得足够强。

3.1 威胁：使用过时的“防伪印章”

JWS（JSON Web Signature）支持多种签名算法。如果允许使用一些已被证明不够安全的旧算法（如基于SHA-1的算法），攻击者就可能伪造IPX或SEPP的签名，从而注入恶意修改。

3.2 规范原文

4.2.2.7 JWS profile restriction Requirement Name: JWS profile restriction Requirement Description: SEPPs and IPXs follow the JWS profile as defined in TS 33.210 with the restriction that they shall only use ES256 algorithm.

Test Case: Test Name: TC_JWS_PROFILE_RESTRICTION

3.3 深度解读与测试实践

  • 核心要求：SEPP和IPX在进行JWS签名时，必须且只能使用ES256算法（基于P-256椭圆曲线和SHA-256的ECDSA签名）。SEPP在验证签名时，必须拒绝任何使用非ES256算法的签名。
  • 测试用例解读 (The “How to Verify”)：
    1. 建立一个包含SEPP和模拟IPX的测试环境。
    2. 攻击模拟：模拟IPX在修改一条N32-f消息后，使用一个非ES256的算法（例如，ES384或任何一种RSA算法）对其进行JWS签名。
    3. IPX将这条被修改并用错误算法签名的消息，转发给被测SEPP。
    4. 预期结果：被测SEPP必须能够识别出签名的算法不合规，并丢弃这条被修改的消息（或至少丢弃那个非法的修改部分）。

4. 防止情报被恶意示众 (4.2.2.8)：加密IE防错位

这是对一种极其狡猾的应用层逻辑攻击的防御。

4.1 威胁：加密索引的“乾坤大挪移”

假设A国SEPP将supi字段加密后，替换为"encBlockIdx:0"。一个恶意的IPX在转发时，耍了一个花招：它将这个键值对"supi": "encBlockIdx:0"，从消息的一个加密区域，移动或复制到了一个公开的、非加密的区域，比如"publicInfo": {"comment": "encBlockIdx:0"}。

核心威胁：虽然密文本身没有被破解，但攻击者通过移动密文的“索引”，可能会触发接收端NF的非预期行为，或者泄露元数据（例如，“这个用户的评论区包含一个加密信息”），甚至在某些有缺陷的实现中，可能导致这个加密索引在后续的流程中被当作战术明文信息错误地处理和转发。

4.2 规范原文

4.2.2.8 No misplacement of encrypted IEs in JSON object by IPX Requirement Name: No misplacement of encrypted IE in JSON object by IPX Requirement Description: … A SEPP verifies that an intermediate IPX has not moved or copied an encrypted IE to a location that would be reflected from the producer NF in an IE without encryption…

4.3 深度解读与测试实践

  • 核心要求：接收方SEPP必须能够验证，一个代表加密IE的索引（encBlockIdx），没有被中间IPX移动或复制到一个根据策略本应是明文的字段中。
  • 测试用例解读 (The “How to Verify”)：
    1. 发送方SEPP发送一个N32-f消息，其中包含一个被加密替换的IE。
    2. 攻击模拟：模拟IPX修改该消息，将那个encBlockIdx插入到一个明文字段中。
    3. IPX将这条被恶意篡改结构的消息，转发给被测SEPP。
    4. 预期结果：被测SEPP必须能够检测到这种非法的结构篡改，并丢弃整条N32-f消息，同时通过N32-c接口发送一个错误。

总结：SEPP，信令的“外科圣手”与“结构工程师”

通过今天对这四项核心要求的攻坚，小雅对SEPP的理解达到了一个全新的高度。她明白了，SEPP绝不是一个简单的“转发代理”，它是一位技艺精湛的“信令外科医生”和“结构工程师”。

在每一次跨国信令的转发中，SEPP都执行了一套精密的“手术”流程：

  1. 加密手术 (Encryption)：为敏感信息进行应用层加密，实现深度隐藏。
  2. 方案核对 (Policy Check)：确保手术双方遵循完全一致的手术方案。
  3. 工具校验 (Algorithm Check)：确保手术中使用的所有器械（签名算法）都是最顶级的、不可伪造的。
  4. 结构审计 (Structure Check)：确保手术后的“组织结构”（JSON结构）没有被恶意篡改，防止“器官错位”。

这四项“手术”技术，共同构成了SEPP应用层安全防护的核心，确保了环球旅行家“Alex”的每一次漫游通信，其信令内容在跨越国境时，都得到了最深度的、最精细的、最智能的安全保障。

FAQ 环节

Q1：为什么需要JWE应用层加密？N32接口不是已经有TLS加密了吗？ A1：这是为了实现“纵深防御”和应对“中间人可信度”问题。TLS保护的是SEPP-A到SEPP-B之间的传输管道。但漫游路径上可能存在IPX等中间节点，它们在TLS的端点之内，可以看到解密后的HTTP/2消息。JWE应用层加密，是为消息中的特定敏感内容再加一把“端到端”的锁，这把锁只有最终的SEPP才能打开，中间的IPX也无法窥视。这确保了即使中间网络不可信，最敏感的信息依然是安全的。

Q2：什么是“保护策略”（Protection Policy）？它具体长什么样？ A2：保护策略是两个SEPP之间协商的一套规则，用于定义在N32-f上如何处理信令消息。它通常包含两部分：1) 数据类型加密策略（Data-type encryption policy），定义了哪些JSON信息元素（IEs）或HTTP头部需要被JWE加密。2) 修改策略（Modification policy），定义了IPX提供商被允许修改哪些信息。这些策略通常以JSON格式在N32-c接口上交换。

Q3：为什么3GPP强制要求JWS只能使用ES256算法？ A3：这是为了保证整个5G漫游生态系统有一个统一的、高强度的安全基线。ES256（使用P-256曲线和SHA-256的ECDSA）在当前被认为是兼具高安全性和良好性能的标准化签名算法。通过强制要求所有SEPP和IPX都使用这一种算法，可以避免因为某些厂商支持了较弱的算法而产生的“短板效应”，简化了互联互通的复杂性，并使得整个系统的安全性更容易被评估和信任。

Q4：“加密IE错位”攻击听起来非常高级和少见，它在现实中真的有威胁吗？ A4：是的，这是一种典型的应用层逻辑攻击，在复杂的系统中尤其危险。攻击者利用的是系统中不同组件对数据“上下文”的不同理解。例如，一个组件认为某个字段是“加密索引”，而另一个组件可能把它当成一个普通的“评论ID”。攻击者通过移动数据，来欺骗后者的处理逻辑。在安全领域，任何对协议“想当然”的解析和处理，都可能被攻击者利用。因此，对数据结构的严格校验，是防范这类高级逻辑攻击的关键。

Q5：这些复杂的应用层处理，会不会让SEPP成为漫游性能的瓶颈？ A5：确实，这些深度的加解密、签名验签和JSON解析操作，会带来显著的性能开销。这也是为什么SEPP产品通常被设计为高性能的专用网络设备。它们往往会使用硬件加速卡来处理TLS和JWE/JWS等密码学运算，并通过优化的软件架构来高效地处理HTTP/2和JSON。性能是SEPP设计时与安全性同等重要的核心指标。一个合格的SEPP产品，必须能够在满足这些严苛安全要求的同时，依然提供线速的、低延迟的信令转发能力。

关系图谱