51学通信

深度解析 3GPP TS 33.210：第6章 Other 3GPP profiles (5G安全工具箱的“瑞士军刀”)

18分钟阅读

好的，我们继续进行系列的下一篇深度解读。

深度解析 3GPP TS 33.210：第6章 Other 3GPP profiles (5G安全工具箱的“瑞士军刀”)

本文技术原理深度参考了3GPP TS 33.210 V18.1.0 (2024-06) Release 18规范中，关于“第6章 Other 3GPP profiles”的核心章节，旨在为读者提供一个关于5G网络在IP层之上，如何利用TLS、JWE/JWS等现代密码学工具构建分层安全体系的全景解析。

引言：从“装甲隧道”到“带锁的公文包”

“陈工，我们已经学会了用IPsec为运营商之间构建‘装甲隧道’（Za接口），确保了所有跨国信令的底层传输安全。”在一次关于5G服务化架构（SBA）安全的专题讨论会上，小林提出了新的思考，“但在SBA架构内部，NF之间都是通过HTTP/2 API进行交互的。这些API流量，也跑在IPsec隧道里吗？如果都用IPsec，会不会太‘重’了？有没有更轻量、更灵活的保护方式？”

资深架构师陈默赞许地点点头：“小林，你的问题非常关键，触及了现代网络安全设计的一个核心原则——分层防御 (Layered Security)。IPsec是网络层的‘重装甲’，非常适合保护‘城门’和‘主干道’。但对于城市内部，两个办公室（NF）之间传递一份份‘公文’（API消息），如果每次都要动用装甲车来护送，不仅成本高，而且不够灵活。我们需要的是更轻便的工具，比如一个‘带密码锁的公文包’。”

他将TS 33.210切换到第6章。“‘Other 3GPP profiles’，这一章就是3GPP为我们提供的，除了IPsec之外的‘安全工具箱’。它不再局限于IP网络层，而是向上延伸，为传输层和应用层的安全提供了标准化的‘瑞士军刀’。其中最核心的两个工具，就是TLS协议——负责为‘公文’的传递过程提供一条加密的‘气动管道’；以及JWE/JWS——负责将‘公文’本身变成一个‘加密’或‘签名’的数字信封。”

“今天，我们就来打开这个‘工具箱’，学习如何将不同的安全工具，应用在最合适的场景，构建一个多层次、纵深化的5G安全防御体系。”

1. “点对点”的安全通道：TLS Protocol Profiles (6.2)

当5G核心网的AMF需要向SMF发起一个服务请求时，它会建立一个基于HTTP/2的连接。为了保护这个连接上所有API交互的机密性和完整性，SBA架构强制要求使用TLS (Transport Layer Security, 传输层安全性协议)。TLS就是我们日常浏览器访问HTTPS网站时，地址栏上那把“小锁”背后的技术。

6.2.1 General

The present clause contains the general 3GPP TLS profile… New specifications using TLS should refer to this profile with as few exceptions as possible.

1.1 深度解析：3GPP的TLS“使用指南”

与IPsec一样，TLS标准本身也极其庞大和复杂。第6.2节的核心工作，同样是进行Profiling (裁剪与定制)，为3GPP网络制定一套统一、安全的TLS“使用指南”。

1.1.1 版本的演进：淘汰旧标准，拥抱新标准

TLS versions

  • SSL 1.0, SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1 and DTLS 1.0 shall not be supported.
  • TLS 1.2 as specified in RFC 5246 shall be supported.
  • TLS 1.3 as specified in RFC 8446 shall be supported.

  • 深度解析:

    规范以非常强硬的措辞（shall not be supported），禁用了所有已被证明存在严重安全漏洞的旧版本协议（如SSLv3的POODLE攻击，TLS 1.0的BEAST攻击）。同时，它强制要求支持业界当前的主流标准TLS 1.2，并推荐支持最新、更安全的TLS 1.3。这确保了5G网络的安全基线，始终与互联网安全技术的最新进展保持同步。

1.1.2 算法的选择：强制使用“前向保密”与“认证加密”

6.2.3 Profiling for TLS 1.2

  • Only cipher suites with AEAD (e.g. GCM) and PFS (e.g. ECDHE, DHE) shall be supported.
  • Mandatory to support: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • Recommended to use: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

  • 深度解析:

    规范对TLS 1.2的密码套件（Cipher Suite）做出了两个至关重要的强制要求：

    1. 必须支持PFS (Perfect Forward Secrecy, 完美前向保密): 强制使用ECDHE或DHE作为密钥交换算法。这意味着即使服务器的长期私钥在未来某天泄露，攻击者也无法解密过去截获的通信流量。

    2. 必须支持AEAD (Authenticated Encryption, 认证加密): 强制使用GCM等模式。这确保了加密和完整性校验在一次操作中完成，更高效，也更安全。

    规范还给出了必须支持和推荐使用的具体密码套件，这为不同厂商NF之间的互操作性提供了“最大公约数”。

1.1.3 场景化应用：保护SBA的“神经元”连接

当AMF要去发现一个SMF时，它首先会查询NRF。AMF与NRF之间的这次HTTP/2 API交互，就必须由一个遵循3GPP TLS Profile的TLS连接来保护。

  1. TLS握手: AMF（客户端）与NRF（服务器）进行TLS握手。

  2. 算法协商: 它们会协商出一套双方都支持的、且符合3GPP Profile的密码套件，例如TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256。

  3. 安全通道建立: 握手成功后，一条点对点的、加密的TLS安全通道就建立了。

  4. API交互: AMF的GET /nnrf-nfm/v1/nf-instances?service-type=SMF请求，以及NRF返回的SMF实例列表，都在这条TLS通道内被加密传输。

洞察： TLS Profile，为SBA架构中成千上万个NF之间的“神经元连接”，提供了轻量、高效、点对点的安全保护。它确保了核心网内部的“悄悄话”，不会被任何潜在的内部攻击者所窃听或篡改。

2. “数字信封”与“电子签名”：JWE and JWS profiles (6.3)

TLS保护的是传输过程，但如果数据本身需要被存储或跨多个节点转发，我们又该如何保证它的安全呢？这时，就需要用到JWE和JWS。它们是IETF为JSON对象定义的一套加密和签名标准。

6.3.1 General

JWS (JSON Web Signature) and JWE (JSON Web Encryption) are used to integrity protect and encrypt JSON objects.

2.1 JWE (JSON Web Encryption)：打造“加密公文包”

JWE允许你将一个JSON对象（如用户信息）进行加密，并封装成一个紧凑的、URL安全的字符串。这个字符串可以被安全地存储或传输，只有拥有密钥的接收方才能解密并读取原始内容。

6.3.2 JWE profile

  • “enc” parameter A128GCM … shall be supported.
  • “alg” parameter “dir” (Direct use of a shared symmetric key as the CEK) shall be supported.

  • 深度解析:

    3GPP同样对JWE进行了裁剪，规定了必须支持的加密算法（enc），如A128GCM；以及密钥管理算法（alg），如dir（直接使用预共享的对称密钥）。

2.2 JWS (JSON Web Signature)：盖上“防伪公章”

JWS则允许你对一个JSON对象进行数字签名，生成一个带有签名信息的字符串。接收方可以通过验证签名，来确认这份“公文”确实是合法的发送方签署的，并且在传输途中没有被篡改过。

6.3.3 JWS profile

  • “alg” parameter ES256 (ECDSA using P-256 and SHA-256) shall be supported.
  • The “none” “alg” parameter shall not be supported.

  • 深度解析:

    规范规定了必须支持的签名算法（alg），如ES256（基于椭圆曲线的数字签名算法），并明确禁止了alg="none"这种“不签名”的不安全选项。

2.3 场景化应用：保护跨域传递的“授权令牌”

在5G与第三方应用交互的场景中，JWE/JWS扮演着关键角色。例如，当一个用户通过OAuth 2.0授权一个第三方App（AF）访问其网络信息时：

  1. 认证服务器（如AUSF）可能会生成一个包含用户权限的JSON对象。

  2. 为了安全地将这个“授权令牌”传递给AF，认证服务器可以使用JWS对其进行签名，以防篡改。

  3. 如果令牌中包含了敏感信息，还可以再用JWE对其进行加密，只有AF才能解密。

  4. AF收到这个经过JWE加密和JWS签名的对象后，先解密，再验签，就能安全地获取到用户的授权信息。

洞察： JWE/JWS Profile，为5G网络中需要在不同信任域之间传递的结构化数据（JSON），提供了一套标准化的“数字信封”和“电子签名”解决方案。它实现了对数据本身的安全保护，与保护传输通道的TLS/IPsec形成了完美的互补。

结论：分层防御，各司其职

通过对第6章的学习，我们打开了5G安全工具箱的另外几层，看到了一个更加立体和纵深的防御体系。

  1. IPsec (网络层): 像“装甲车队”，提供强大的、基于IP地址的网络间安全隔离。它保护的是“路”。

  2. TLS (传输层): 像“加密气动管道”，提供高效的、点对点的连接安全。它保护的是“信道”。

  3. JWE/JWS (应用层): 像“带锁的公文包”和“电子签名”，提供对数据内容本身的保护，使其无论身处何处（传输中或存储中）都是安全的。它保护的是“信”。

这三层防御体系，各司其职，又相互补充。在5G这个日益开放、复杂和云化的网络中，没有任何一种单一的安全技术能包打天下。只有通过这种分层、纵深的“工具箱”模式，根据不同的场景、不同的信任级别，灵活地组合使用最合适的安全工具，才能构建起真正坚不可摧的“大安全”防线。

FAQ 环节

Q1：既然SBA接口已经强制使用TLS了，为什么还需要IPsec？

A1：这是为了应对不同的安全威胁模型和部署场景，实现深度防御。TLS能有效保护通信双方的点对点连接，防止中间人攻击。但它无法防止更底层的网络攻击，例如，一个内部网络的攻击者，可能无法破解TLS，但他可以通过IP欺骗，伪装成一个合法的NF，去尝试与另一个NF建立TLS连接并发起攻击。而如果在底层部署了IPsec，这个伪造的IP包因为没有正确的IPsec封装，在第一关就会被SEG丢弃。此外，当NF跨越不受信任的传输网络（如公共互联网）部署时，IPsec可以提供一层额外的、独立于应用层的“堡垒式”保护。

Q2：TLS 1.3相比TLS 1.2有哪些主要的安全性提升？为什么规范要推荐支持它？

A2：TLS 1.3相比1.2，在安全性和性能上都有重大提升。主要包括：1）更快的握手： 将握手过程从2-RTT（往返）减少到了1-RTT，甚至0-RTT（对于会话恢复），大大降低了连接建立时延。2）更强的安全性： 废除了一系列老旧、不安全的密码算法和特性（如CBC模式、RC4、SHA-1等）；默认实现了前向保密（PFS）；对更多的握手信息进行了加密，更好地保护了隐私。3GPP推荐支持TLS 1.3，正是为了让5G核心网能够享受到这些最新的安全和性能优势。

Q3：JWE/JWS和我们常说的数字证书、PKI是什么关系？

A3：它们是整个公钥基础设施（PKI）生态中的不同组件。数字证书是用于证明一个公钥确实属于某个实体（如一个NF）的“数字身份证”，由权威的证书颁发机构（CA）签发。**JWS（签名）**正是利用这种“身份证”（证书里的公钥/私钥对）来对数据进行签名和验签的。JWE（加密）也可能利用证书中的公钥，进行非对称加密来安全地交换对称加密密钥。可以说，PKI和数字证书，为JWS/JWE提供了可信的密钥管理和身份认证基础。

Q4：这些“Other Profiles”是不是只适用于5G核心网的SBA架构？

A4：虽然它们在SBA架构中应用最广，但并不局限于此。规范指出，它们是“3GPP profiles of protocols above the IP layer”，是通用的。例如，TLS Profile也可以被用于保护其他基于TCP的信令接口，如 Diameter over TCP。JWE/JWS则可以被用于任何需要安全传输JSON对象的场景，例如OAM系统与NF之间的接口。它们是3GPP为所有基于IP的应用层协议提供的一套通用的安全“最佳实践”。

Q5：作为一名网络工程师，我需要深入学习这些密码学协议的每一个细节吗？

A5：不一定需要成为密码学家，但理解其核心原理、目标和3GPP的Profiling选择至关重要。你需要知道：1）每种工具（IPsec, TLS, JWE/JWS）分别解决了什么安全问题？2）3GPP为什么强制要求/禁用了某些特定的算法和模式？（例如，知道PFS的重要性，知道为什么不能用TLS 1.1）。3）在进行网络配置和故障排查时，能够根据这些Profile，检查设备的配置是否合规，以及分析TLS握手失败等问题的日志。这种“知其然，并知其所以然”的能力，是高级网络工程师和安全工程师的必备素质。

关系图谱