51学通信

深度解析 3GPP TS 33.513：4.1 & 4.2.2 接口安全（Part 1 - N3 & N9 用户面隧道保护）

26分钟阅读

深度解析 3GPP TS 33.513：4.1 & 4.2.2 接口安全（Part 1 - N3 & N9 用户面隧道保护）

本文技术原理深度参考了3GPP TS 33.513 V18.1.0 (2023-12) Release 18规范中，关于“4.1 Introduction”、“4.2 UPF-specific security functional requirements and related test cases”及其子章节“4.2.2.1 至 4.2.2.4”的核心内容，旨在为读者抽丝剥茧，深入解析5G用户面最关键的数据传输链路——N3和N9接口的安全要求与测试方法。

进入实战：守护无人机的“数据生命线”

在彻底消化了规范的前三章后，新人工程师小林已经做好了攻坚克难的准备。他知道，接下来要面对的第四章，是整本规范的心脏，里面充满了具体而严苛的技术要求。

导师李工看出了小林的兴奋与紧张，他笑着说：“别急，我们一口一口地吃。第四章虽然庞杂，但逻辑清晰。今天，我们先来解决UPF最核心的职责——保护用户数据在网络中的传输安全。为了让你有更直观的感受，我们来想象一个具体的场景。”

李工在白板上画了一个简图：“想象一下，我们的客户是一家能源公司，他们使用一架名为‘鹰眼-01’的工业级巡检无人机，去检查一座跨海大桥的钢缆结构。‘鹰眼-01’会实时回传8K超高清视频流和激光雷达点云数据，这些数据对桥梁的安全评估至关重要。这些数据从无人机发出，通过5G基站，最终汇入我们公司的‘DataStorm 5000’ UPF进行处理和分发。我们的任务，就是确保这条‘数据生命线’绝对安全。”

这个场景让小林立刻来了精神。他知道，接下来的每一条规范，都直接关系到“鹰眼-01”回传的关键数据是否会被窃取、篡改或干扰。

1. 纲领先行：4.1 & 4.2.1 引言解读

在深入具体的接口安全之前，李工坚持让小林先仔细阅读4.1和4.2.1节，理解整个第四章的结构布局。

1.1 规范原文

4.1 Introduction The present document describes the following security requirements and the related test cases for UPF:

  • Security functional requirements and the related test cases (clause 4.2),
  • Adaptations of hardening requirements and the related test cases (clause 4.3), and
  • Adaptations of basic vulnerability testing requirements and the related test cases (clause 4.4).

4.2.1 Introduction The security functional requirements and the related test cases specific for UPF are described in the clause.

1.2 深度解读

“你看，这又是作者在给我们画地图，”李工指着屏幕说，“4.1节开宗明义，再次强调了我们上一篇文章总结的三大支柱：”

  • 原生功能安全 (Security functional requirements)：这是UPF作为5G网元与生俱来的安全职责，也是我们今天的主角，规定在4.2节。
  • 平台加固 (Hardening requirements)：这是对UPF运行环境的通用安全要求，规定在4.3节。
  • 漏洞测试 (Basic vulnerability testing)：这是主动的安全“攻击”测试，规定在4.4节。

而4.2.1节则是一个引子，告诉我们接下来的所有内容，都将围绕第一个支柱——“原生功能安全”展开。这种层层递进的结构，让复杂的规范变得条理分明。

2. 第一道防线：N3接口安全铁三角 (4.2.2.1 - 4.2.2.3)

李工解释道：“‘鹰眼-01’无人机的数据，首先会通过无线信号到达5G基站(gNB)，然后基站会通过N3接口将这些数据转发给UPF。N3接口是用户数据进入5G核心网的第一道大门，它的安全性是重中之重。3GPP为这道大门设计了‘安全铁三角’：机密性、完整性和抗重放。”

2.1 N3接口的机密性保护 (4.2.2.1 Confidentiality Protection)

机密性，通俗来讲就是“加密”，确保数据就算被截获了，也看不懂内容。

2.1.1 规范原文

Requirement Name: Confidentiality protection of user data transported over N3 interface. Requirement Reference: TS 33.501, Clause 9.3 Requirement Description: The transported user data between gNB and UPF is confidentiality protected as specified in TS 33.501, clause 9.3. Threat Reference: TR 33.926, Clause L.2.2, “No protection or weak protection for user plane data “.

TEST CASE: Test Name: TC_UP_DATA_CONF_UPF Purpose: Verify that the transported user data between gNB and UPF are confidentiality protected over N3 interface. Pre-Condition:

  • UPF network product is connected in simulated/real network environment.
  • The tunnel mode IPsec ESP and IKE certificate authentication is implemented.
  • Tester shall have knowledge of the security parameters of tunnel for decrypting the ESP packets.
  • Tester shall have access to the N3 interface between gNB and UPF.
  • Tester shall have knowledge of the confidentiality algorithm and confidentiality protection keys used for encrypting the encapsulated payload. …

2.1.2 深度解读

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

  • 核心要求：gNB和UPF之间传输的用户数据必须被机密性保护（加密）。
  • “鹰眼-01”场景：这意味着，无人机回传的8K视频流和激光雷达数据，在从基站到UPF的路上，必须是加密的。
  • 为何如此重要？ 李工提出一个尖锐的问题：“如果N3接口不加密，会发生什么？”小林立刻反应过来：“竞争对手可能在基站附近通过物理或网络手段窃听N3链路。他们一旦拿到‘鹰眼-01’的原始数据，就能知道这座跨海大桥的结构健康状况，甚至可能发现一些未公开的结构弱点。这在商业竞争甚至国家安全层面都是灾难性的！”
  • 技术溯源：规范明确指出，这一要求的“法理依据”来自5G安全总纲TS 33.501，其技术实现通常依赖IPsec ESP隧道加密。

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

李工强调，读懂测试用例是检验产品是否合规的关键。

  • 目标 (Purpose)：非常直接——验证N3接口的数据确实被加密了。
  • 前置条件 (Pre-Condition)：这是测试环境的搭建要求，每一条都至关重要。
    • UPF in network environment：你需要一个最小化的5G网络环境，至少包含一个模拟的gNB和待测试的UPF。
    • IPsec ESP and IKE implemented：明确了技术栈。测试前必须在gNB和UPF上成功配置和激活IPsec隧道。IKE（Internet Key Exchange）负责自动协商加密密钥，ESP（Encapsulating Security Payload）负责对数据包进行加密和封装。
    • Tester shall have knowledge... for decrypting：这是测试的关键！这是一个“白盒”或“灰盒”测试。测试人员必须事先知道用于加密的密钥。为什么？因为验证加密是否成功的唯一方法，就是用正确的密钥去解密，看能否还原出原始数据。如果你没有密钥，你抓到的只是一堆乱码，无法判断这乱码是正确的加密结果还是单纯的传输错误。
  • 执行步骤 (Execution Steps)：
    1. 在模拟gNB和UPF之间的N3接口上启动抓包工具（如Wireshark）。
    2. 模拟“鹰眼-01”无人机发送数据流通过gNB。
    3. 观察抓包工具，捕获到的数据包应该是IPsec ESP格式的，其载荷部分应是无法直接阅读的加密数据。
    4. 使用预知的密钥和算法，在Wireshark中或使用其他工具尝试解密捕获的数据包。
  • 预期结果 (Expected Results)：
    1. 直接观察抓包，数据是加密的（乱码）。
    2. 使用正确的密钥后，能够成功解密，还原出原始的GTP-U数据包，内容与“鹰眼-01”发送的完全一致。
    3. 提供解密前后的抓包截图作为证据（Evidence）。

2.2 N3接口的完整性保护 (4.2.2.2 Integrity Protection)

完整性保护，是确保数据在传输过程中没有被“动手脚”。

2.2.1 规范原文

Requirement Name: Integrity protection of user data transported over N3 interface. Requirement Description: The transported user data between gNB and UPF is integrity protected as specified in TS 33.501, clause 9.3. … TEST CASE: Test Name: TC_UP_DATA_INT_UPF … Pre-Condition: …

  • Tester shall have knowledge of the authentication algorithm (Hash Message Authentication Code) and the protection keys.

2.2.2 深度解读

需求解读

  • 核心要求：N3接口传输的数据必须有完整性保护，防止被篡改。
  • “鹰眼-01”场景：小林立刻想到了一个惊悚的场景：“如果一个恶意攻击者截获了N3数据，虽然他因为加密而看不懂，但他可以尝试随机修改数据包的几个比特位再发出去。如果UPF收到了被篡改的数据，可能会导致解码出的桥梁视频出现关键的马赛克，或者激光雷达的点云数据发生偏移，让工程师做出错误的判断——把一道细微的裂缝判断为安全，或者反之。”
  • 技术实现：IPsec ESP在加密的同时，也会计算一个消息认证码（MAC或HMAC），就像是给数据包盖上一个“防伪印章”。接收方会用同样的密钥和算法重新计算一遍印章，如果对不上，就说明数据在路上被改动过，这个数据包将被丢弃。

测试用例解读

测试完整性的方法与机密性类似，但关注点不同。

  • 前置条件：除了加密密钥，测试人员还必须知道用于计算“防伪印章”的认证算法（如HMAC-SHA256）和密钥。
  • 执行步骤：
    1. 正常情况下抓包，验证IPsec ESP包中存在有效的认证码字段。
    2. 主动攻击：使用工具（如Scapy）捕获一个合法的ESP包，故意修改其中载荷的一个比特，然后将这个被篡改的包重新注入到网络中，发给UPF。
  • 预期结果：
    1. UPF应该能够检测到“防伪印章”不匹配。
    2. UPF必须丢弃这个被篡改的数据包，并且可能会记录一次完整性校验失败的日志或告警。
    3. 提供UPF丢弃非法包的日志或统计数据作为证据。

2.3 N3接口的抗重放保护 (4.2.2.3 Replay Protection)

抗重放，是防止攻击者将合法的数据包重新发送，以达到恶意目的。

2.3.1 规范原文

Requirement Name: Replay protection of user data transported over N3 interface Requirement Description: The transported user data between gNB and UPF is replay protected as specified in TS 33.501, clause 9.3. … TEST CASE: Test Name: TC_UP_DATA_REPLAY_UPF …

2.3.2 深度解读

需求解读

  • 核心要求：防止N3接口上的合法数据包被恶意重放。
  • “鹰眼-01”场景：李工启发小林：“假设在上午10点，‘鹰眼-01’传回数据显示大桥一切正常。攻击者捕获了这段‘正常’的数据包。到了下午3点，大桥因为极端天气出现了一道危险的裂缝，无人机正在回传‘危险’的实时数据。此时，攻击者发动重放攻击，把上午10点的‘正常’数据包大量地重新发给UPF。会发生什么？”
  • 严重后果：小林倒吸一口凉气：“UPF和后端的监控中心会持续收到‘一切正常’的旧数据，而真正告警的‘危险’数据可能被淹没或延迟处理。这将导致运维人员错过了最佳的预警和处置时机！”
  • 技术实现：IPsec协议中有一个“序列号”机制。发送方发出的每一个包都有一个递增且唯一的序列号。接收方会维护一个“窗口”，只接受序列号落在窗口内且未被接收过的数据包。任何重复的或序列号过时的包都会被视为重放攻击而被丢弃。

测试用例解读

  • 执行步骤：
    1. 建立正常的IPsec连接，并发送一些数据包，用抓包工具捕获它们。
    2. 从捕获的数据包中，挑选一个（或多个）合法的、已经被UPF成功接收的ESP包。
    3. 将这个（些）包原封不动地再次注入网络，发送给UPF。
  • 预期结果：
    1. UPF必须能够识别出这是一个重放包（因为其序列号已经被接收过）。
    2. UPF必须丢弃这个重放包。
    3. 提供UPF丢弃重放包的日志或统计计数作为证据。

3. 深入腹地：N9接口安全保护 (4.2.2.4)

李工继续说：“有时候，网络结构比较复杂。比如‘鹰眼-01’从大桥的一端飞到另一端，可能会跨越两个基站的覆盖范围，甚至这两个基站连接的UPF都不是同一个。这时，数据就需要从第一个UPF（我们称之为V-UPF）通过N9接口，转发到第二个UPF（H-UPF）。N9接口是核心网内部UPF之间的通道，同样需要保护。”

3.1 规范原文

Requirement Name: Protection of user data transported over N9 interface Within a PLMN. Requirement Reference: TS 33.501, Clause 9.9 Requirement Description: As specified in clause 9.9 in TS 33.501, interfaces internal to the 5G Core can be used to transport signalling data as well as privacy sensitive material, such as user and subscription data… Therefore, confidentiality and integrity protection is required. … TEST CASE: Test Name: TC_UP_DATA_CONF_UPF_N9

3.2 深度解读

需求解读

  • 核心要求：在同一个运营商网络（PLMN）内，UPF之间的N9接口也必须提供机密性和完整性保护。
  • 为何重要？ 小林提出疑问：“N9接口不是已经在运营商自己的机房里了吗？物理上应该很安全，为什么还需要这么强的保护？”
  • 纵深防御：李工解释道：“这叫‘零信任’和‘纵深防御’原则。我们不能假设内部网络就是绝对安全的。攻击者可能通过其他漏洞已经渗透到了核心网内部。如果N9接口是明文传输的，那一旦内网失陷，所有流经N9的数据将全部暴露。保护N9，是在外部防线被突破后，保护核心数据流的最后一道保险。”
  • “鹰眼-01”场景：无人机的数据在从边缘UPF转发到中心UPF进行AI分析的途中，如果N9不设防，就已经渗透到内网的攻击者就能轻松窃取或篡改这些高价值数据。

测试用例解读

N9接口的测试用例（如TC_UP_DATA_CONF_UPF_N9）在原理上与N3接口的测试非常相似。

  • 环境搭建差异：测试环境不再是“gNB ←> UPF”，而是“UPF-A ←> UPF-B”。你需要能够同时控制和监控两个UPF实例。
  • 测试方法：同样采用IPsec ESP，测试机密性、完整性和抗重放的方法论完全一致：
    • 机密性：抓包验证数据加密，用密钥解密验证内容正确。
    • 完整性：篡改数据包，验证接收方UPF会丢弃。
    • 抗重放：重放合法数据包，验证接收方UPF会丢弃。
  • 关注点：测试的重点在于验证UPF产品不仅能作为IPsec的终端（N3场景），也能作为IPsec的发起端和接收端（N9场景），与另一个同类设备建立安全的隧道。

总结：为用户面数据流穿上“三层防护服”

小林在笔记本上画下了一幅图：无人机“鹰眼-01”的数据包，像一个珍贵的包裹。

  1. 当它离开基站，踏上N3接口之旅时，UPF和gNB为它穿上了第一件“IPsec防护服”。这件衣服是：

    • 不透明的（机密性），外面的人看不见里面是什么。
    • 带防伪封条的（完整性），任何撕开或改动的痕迹都会被发现。
    • 带一次性邮票的（抗重放），用过的邮票无法再次投递。

  2. 当这个包裹需要在UPF之间接力，踏上N9接口之旅时，两个UPF会为它再穿上一件同样坚固的“IPsec防护服”，确保内部转运过程万无一失。

通过对4.2.2.1到4.2.2.4的精读，小林深刻理解了UPF是如何通过这“安全铁三角”来守护用户数据的。他知道，这不仅仅是枯燥的技术要求，而是对亿万用户数据安全做出的庄严承诺。下一站，他将挑战更为复杂的N4接口——控制面与用户面交汇的十字路口，那里的安全博弈将更加精彩。

FAQ 环节

Q1：N3接口和N9接口的安全保护机制有什么本质区别吗？ A1：从技术实现上讲，两者本质上没有太大区别，都推荐使用IPsec ESP来提供机密性、完整性和抗重放保护。最大的区别在于应用场景和连接的两端：N3接口连接的是接入网（gNB）和核心网（UPF），是核心网的边界入口；而N9接口连接的是核心网内部的两个UPF，是核心网的内部数据通道。因此，对N3的安全防护是抵御外部威胁，而对N9的防护则体现了“零信任”和“纵深防御”思想，防范内部威胁或边界失陷后的横向移动攻击。

Q2：测试用例中要求测试者必须知道加密密钥，这在现实攻击中是不可能的。这样的测试有意义吗？ A2：非常有意义。这种测试方法被称为“白盒测试”或“灰盒测试”。它的目的不是模拟一个完全不知道任何信息的外部黑客（黑盒测试），而是为了“验证功能是否正确实现”。我们需要密钥来解密，正是为了确认加密过程本身是正确的、可逆的、符合标准的。如果连拥有密钥的合法测试者都无法解密，那说明产品功能本身就有缺陷。这类测试是确保产品符合规范要求的基础。

Q3：规范中提到的IPsec和IKE是什么？它们和我们平时上网用的HTTPS有什么不同？ A3：IPsec（Internet Protocol Security）是一个工作在网络层（IP层）的安全协议套件，可以为IP数据包提供安全服务。IKE（Internet Key Exchange）是IPsec体系中用于自动协商密钥和建立安全关联（SA）的协议。它能为整个设备的所有IP通信（或特定策略的通信）提供保护。而HTTPS工作在应用层，主要用于保护Web浏览器和服务器之间的HTTP通信。简单比喻：IPsec像是为整辆运钞车提供了装甲保护，车里运什么都安全；而HTTPS像是只给运钞车里的一个钱箱上了锁。

Q4：如果UPF检测到了一个完整性校验失败或重放的包，它会怎么做？会通知gNB吗？ A4：根据IPsec的标准行为，UPF会默默地丢弃这个无效的数据包。它通常不会为此专门通知gNB，因为这被认为是网络传输中可能发生的正常异常（或攻击），IPsec协议本身就设计了应对机制。但是，一个设计良好的UPF产品应该会在本地记录这类事件的日志，并增加相关的性能计数器（如“IPsec完整性校验失败包计数”）。网络管理员可以通过监控这些日志和计数器来发现潜在的网络攻击。

Q5：规范测试用例的NOTE 1中经常提到“This test case is only applicable to UPF supporting IPSec in N3 interface without the use of a SEG”。这句话是什么意思？ A5：SEG（Security Gateway，安全网关）是一个独立的网络设备，专门用于提供IPsec加密/解密功能。在某些网络部署方案中，UPF本身不处理IPsec，而是将所有进出流量都先送到一个SEG，由SEG来负责加解密。这个NOTE的意思是，本测试用例只适用于那些UPF自身集成了IPsec功能的场景。如果UPF依赖外部的SEG，那么这个IPsec功能的测试就应该对SEG去进行，而不是对UPF进行。这明确了测试的边界和被测对象（DUT）的能力范围。

关系图谱