51学通信

深度解析 3GPP TS 33.501：Annex F-I (特殊场景安全) - EAP框架、隐私与专网

19分钟阅读

好的，我们继续深入解读3GPP TS 33.501规范。

深度解析 3GPP TS 33.501：Annex F-I (特殊场景安全) - EAP框架、隐私与专网

本文技术原理深度参考了3GPP TS 33.501 V18.9.0 (2025-03) Release 18规范中，关于“Annex F: 3GPP 5G profile for EAP-AKA’”、“Annex G: Application layer security on the N32 interface”、“Annex H: Void”和“Annex I: Non-public networks”的核心章节，旨在为读者系统性地梳理5G安全在一些关键特殊场景下的具体实现与适配，包括EAP-AKA’的5G定制、N32接口安全的细节，以及非公共网络（专网）的安全框架。

在前几篇文章中，我们已经详细剖析了5G安全的主体流程和核心密码学机制。然而，3GPP规范的精髓不仅在于其主体框架的宏伟，更在于其附录（Annex）中对各种特殊场景的周密考量和精细定义。这些附录，如同主体规范的“高清补丁”和“扩展模块”，确保了5G安全能够平滑地应用于各种复杂的现实世界场景。

今天，我们将深入解读规范的附录F至附录I。这四个附录分别解决了5G安全在四个重要维度上的具体化和扩展问题：

  • 附录F (EAP-AKA’ 5G Profile)：为EAP-AKA’这个“通用集装箱”贴上了“5G专用”的标签，解决了它在5G环境下身份处理的细节问题。
  • 附录G (N32应用层安全)：以信息性的方式，为我们更直观地描绘了SEPP之间PRINS协议的运作流程。
  • 附录H (Void)：一个占位章节。
  • 附录I (非公共网络安全)：为5G专网（SNPN）的安全部署提供了框架性的指导，明确了其与公网在认证方法、身份管理等方面的核心差异和扩展。

为了贯穿这些场景，我们的主角将再次多样化。信息安全专家“白帽”将尝试对EAP-AKA’的身份交互进行深度分析；核心网工程师“李工”将为我们展示N32接口的报文结构；而工业AGV“智行一号”将在其全自动化的工厂专网中，执行一次独特的、基于企业证书的EAP-TLS认证。

1. Annex F: EAP-AKA’的5G配置文件 - “通用认证”的5G适配

我们在6.1.3节已经知道，EAP-AKA’是5G支持的一种重要主认证方法。但EAP-AKA’本身是一个为3G/4G设计的通用框架（RFC 5448），它的一些默认行为与5G的隐私保护原则存在冲突。附录F（规范性）的核心任务，就是为EAP-AKA’在5G中的使用，制定一套“本地化规则”，以确保其行为与5G的安全理念完全对齐。

F.2 Subscriber privacy TS 33.501 assumes that the SUCI is sent outside the EAP messages, however, the peer may still receive EAP-Request/Identity or EAP-Request/AKA-Identity messages. Table F.2-1 specifies how the 5G UE shall behave when receiving such requests.

核心问题：如何处理身份请求？ 在传统的EAP流程中，认证服务器（AUSF）在开始时，可能会向UE发送一个EAP-Request/Identity，要求UE明文回复其永久身份。这在5G中是不可接受的，因为会暴露SUPI。

附录F通过 Table F.2-1 给出了UE必须遵守的“三不原则”：

  1. 不回明文SUPI：当收到EAP-Request/AKA-Identity AT_PERMANENT_REQ（请求永久身份）时，UE绝不能回复SUPI。它必须回复一个客户端错误，并终止认证。UE会假设这是一个恶意网络的“钓鱼”行为。
  2. 不回临时身份GUTI：当收到EAP-Request/AKA-Identity请求时，UE也不会回复5G-GUTI。
  3. 只回加密身份SUCI：在任何情况下，如果被要求提供身份，UE的唯一合法回应就是发送在NAS层已经准备好的SUCI。

F.3 Subscriber identity and key derivation If the AT_KDF_INPUT parameter contains the prefix “5G:”, … the UE shall set as the Identity for key derivation… When the SUPI Type is IMSI, the Identity shall be set to IMSI…

另一个关键适配：密钥派生中的身份 在EAP-AKA’的密钥派生公式中，需要用到用户的“Identity”作为输入。附录F明确规定，在5G场景下（通过一个特殊的”5G:“前缀来识别），这个“Identity”必须是UE的明文SUPI（IMSI或NAI格式），而不是SUCI或任何临时身份。

这是否矛盾？ 不矛盾。这个SUPI只在UE和AUSF各自的“密室”内部，作为本地计算的输入参数使用，它从未在任何信令中明文传输。UE侧，它从USIM中获取；AUSF侧，它在认证成功后从UDM处获取。这个规定确保了密钥派生的根源始终是用户的永久身份，保证了密钥的唯一性和正确性。

附录F的意义在于，它通过对EAP-AKA’的“行为重塑”，确保了即使在使用这个源自前代技术的通用认证框架时，5G最核心的隐私保护原则（SUPI绝不在线明文传输）也得到了不折不扣的贯彻。

2. Annex G: N32应用层安全 - PRINS协议的直观展示

附录G是信息性的（Informative），它为我们在13.2节学习的、极其复杂的PRINS协议，提供了一个更直观的图解和解释。

G.2 Structure of HTTP Message Figure G.2-1 Typical structure of the HTTP message received by SEPP Figure 13.2.1-1: Overview of PRINS

附录G通过图示，清晰地展示了一个普通的HTTP请求，是如何被发送方SEPP“大卸八块”，然后封装成JWE和JWS对象，在N32接口上传输，最后又被接收方SEPP“重新组装”的。它帮助我们更形象地理解了：

  • 消息重构：原始的HTTP请求（包含请求行、头、体）是如何被拆分为clearTextEncapsulatedMessage和dataToIntegrityProtectAndCipher两个JSON对象的。
  • JWE封装：这两个JSON对象如何分别被置于JWE的AAD（附加认证数据）和Plaintext部分，并最终生成加密的JWE对象。
  • JWS附加：中间的漫游代理（IPX）是如何生成JWS对象，并将其附加在消息流中的。

虽然不包含新的规范性内容，但附录G对于开发者和调试人员来说，是一份非常有价值的“参考图纸”，它将抽象的PRINS协议具象化了。

3. Annex H: Void - 占位符

本附录为空白（Void），在此特别说明，以保持解读的完整性。

4. Annex I: 非公共网络 (NPN) 安全 - 5G专网的安全“定制指南”

附录I是规范性的，对于理解和部署5G专网至关重要。它详细定义了独立非公共网络（SNPN, Standalone Non-Public Network）在安全实现上，与公共网络（PLMN）相比，有哪些关键的差异和扩展。

I.2.1 General One of the major differences of non-public networks is that authentication methods other than AKA based ones may be used in a standalone non-public network (SNPN). When an AKA-based authentication method is used, clause 6.1 shall apply. When an authentication method other than 5G AKA or EAP-AKA’ is used, only the non-AKA specific parts of clause 6.1 shall apply. An example of running such an authentication method is given in Annex B with EAP-TLS.

核心差异：认证方法的“百花齐放” 专网与公网最核心的区别在于认证的灵活性。公网为了全球互通，认证方法高度统一（主要是AKA）。而专网是一个封闭的、自洽的“独立王国”，它可以根据自身的IT环境和安全需求，选择更多样化的认证方法。

附录I明确了SNPN中认证的几种模式：

  • 模式一：使用公网认证体系 (I.2.4)：SNPN可以与一个公网运营商（作为“凭证持有者”，Credentials Holder）合作，继续使用基于USIM的AKA认证。此时，认证流程与漫游场景类似，SNPN的AMF会通过SEPP，将认证请求发往公网运营商的AUSF/UDM。
  • 模式二：使用企业自有认证体系 (I.2.2.2)：这是专网最常见的场景。SNPN会与企业自己的AAA服务器集成。此时，AUSF扮演EAP认证器，NSSAAF扮演AAA代理，认证方法可以是任何企业支持的EAP方法，如EAP-TLS（基于证书）、EAP-TTLS/MSCHAPv2（基于用户名/密码）等。
  • 模式三：SNPN内部认证：SNPN也可以自建一个完整的、基于AKA或EAP-TLS的认证体系，包含自己的UDM和AUSF。

I.3 Serving network name for standalone non-public networks SN Id = PLMN ID:NID

另一个关键差异：身份标识的扩展 在公网中，服务网络ID（SN Id）就是PLMN ID。而在SNPN中，为了能在一个PLMN ID下区分多个不同的专网，引入了NID（Network Identifier）。SNPN的SN Id变成了PLMN ID + NID的组合。这个扩展后的SN Id，会参与到K_SEAF等关键密钥的派生中，确保了为不同专网派生的密钥是相互隔离的。

场景代入： “智行一号”所在的工厂，就是一个典型的SNPN。

  1. 认证选择：工厂的IT策略要求所有设备都使用证书进行认证。因此，UDM中为“智行一号”配置的认证方法是EAP-TLS。
  2. 认证流程：当“智行一号”发起注册时，AMF/SEAF最终会通过AUSF，与“智行一号”启动一场EAP-TLS认证。
    • AUSF向“智行一号”出示自己的服务器证书。
    • “智行一号”验证证书合法性后，也向AUSF出示自己内置的客户端证书。
    • AUSF验证证书有效后，认证成功。
  3. 密钥派生：EAP-TLS成功后，会协商出EMSK。后续的K_AUSF → K_SEAF → K_AMF… 的派生流程，与附录B中描述的完全一致，完美地复用了5G的统一密钥体系。
  4. 专网标识：在派生K_SEAF时，使用的serving network name将是工厂专网的唯一标识，例如"5G:mcc999.mnc01:nid-0001-aabbcc"。

附录I的意义在于，它为5G安全适应千差万别的专网需求，提供了标准化的“适配框架”。它使得企业可以在保留5G核心安全架构（如统一密钥体系、NAS/AS安全）的同时，灵活地将其“认证前端”替换为自己熟悉的、可控的IT身份认证系统。

5. 总结

本章我们深入解读了附录F至I，它们如同5G安全规范的“精密部件”和“适配接口”，极大地增强了主体框架的完整性和适用性。

  • 附录F (EAP-AKA’ Profile)：通过对身份处理的“微调”，确保了传统认证方法在5G隐私框架下的合规性。
  • 附录G (N32 Security)：通过可视化的方式，增强了对复杂PRINS协议的可理解性。
  • 附录I (Non-Public Networks)：通过引入灵活的认证前端和扩展的网络标识，为5G专网的安全部署提供了可定制的框架，是5G赋能垂直行业的关键安全篇章。

这些附录，充分展现了3GPP在制定标准时的深思熟虑：既要构建一个统一、强大的主体框架，又要为各种特殊场景和未来演进，预留出足够的灵活性和扩展空间。

FAQ

Q1：EAP-AKA’和EAP-TLS，对于一个企业专网来说，哪种认证方法更好？ A1：没有绝对的好坏，取决于企业的具体需求和IT基础。

  • EAP-AKA’：如果企业希望利用运营商的SIM/eSIM生态系统，实现设备的“开箱即用”和统一的凭证管理，那么选择与运营商合作，使用EAP-AKA’是一个很好的选择。设备管理更简单。
  • EAP-TLS：如果企业已经拥有成熟的PKI（公钥基础设施）和证书管理体系，希望将5G设备无缝纳入现有的IT身份认证框架（例如，员工电脑、Wi-Fi、5G设备都使用同一套证书认证），那么EAP-TLS是理想的选择。它提供了最高级别的安全性（基于非对称密码学），并且与企业的IT安全策略高度一致。

Q2：SNPN（独立非公共网络）和PWS（公共预警系统）中的“专网”有什么区别？ A2：它们是完全不同的概念。SNPN是指一个完整的、独立的5G网络，拥有自己的核心网和无线网，通常部署在企业园区、工厂等特定区域，服务于特定的组织。而PWS是公网运营商提供的一项功能，用于在发生自然灾害等紧急情况时，向特定区域的所有用户广播预警消息。PWS是在公共网络（PLMN）之上运行的一项服务，而SNPN是一个独立的网络实体。

Q3：在SNPN中，如果企业选择自己部署UDM/AUSF，那么还需要SEPP吗？ A3：这取决于SNPN是否需要与其他网络（如公网或其他SNPN）互联。

  • 如果这是一个完全隔离的SNPN（Isolated SNPN），所有通信都在网络内部闭环，那么它不需要与外界通信，自然也就不需要SEPP。
  • 如果这是一个需要与公网互联的SNPN（例如，为了让专网内的设备也能访问互联网，或者与公网用户通话），那么在SNPN与公网的边界，就必须部署SEPP，以保护两者之间的信令交互。

Q4：附录I中提到的SUPI隐私，在专网中还那么重要吗？ A4：依然重要，但其优先级和实现方式可能有所不同。在一个人数有限、边界清晰的专网中，通过空口监听来追踪特定设备的风险相对较低。因此，企业可能会根据自己的安全评估，选择更简单的隐私保护方案。例如，附录I提到，如果EAP方法本身（如EAP-TLS）已经提供了强大的身份保护，那么NAS层的SUCI机制甚至可以简化。但是，遵循完整的5G隐私保护框架，仍然是最佳的安全实践。

Q5：学习完这些附录，我感觉5G安全好像把所有能用上的安全技术都用上了，它会不会过于复杂和“过度安全”？ A5：5G安全确实是一个集大成的复杂体系，但其复杂性源于它所要应对的复杂场景。5G的目标是成为未来数十年社会数字化的基础设施，它要承载的不仅是娱乐流量，还有工业控制、自动驾驶、远程医疗等性命攸关的业务。这种“适度冗余”和“纵深防御”的设计，正是为了确保在面对多样化、高风险的应用场景时，仍能提供最高级别的安全保障。对于不同的场景（如公网、专网、物联网），规范也提供了不同的安全“套餐”（如5G AKA vs. EAP-TLS, 完整UP安全 vs. 控制面优化），允许网络根据需求进行“剪裁”，从而在安全、性能和成本之间找到最佳平衡。

关系图谱