好的，这是本系列解读的第三篇文章。继上一篇我们深入剖析了RRC信令的“三层护盾”后，现在我们将目光从控制面转向用户面，看看我们日常上网、看视频、玩游戏时产生的数据流，在5G空中接口上是如何被金钟罩铁布衫般保护起来的。
深度解析 3GPP TS 33.511：4.2.2.1 空口用户面安全 (User Plane Protection)
本文技术原理深度参考了3GPP TS 33.511 V18.3.0 (2024-03) Release 18规范，我们将聚焦于第4章中与用户平面（User Plane, UP）安全相关的核心条款：4.2.2.1.2, 4.2.2.1.5, 4.2.2.1.7, 4.2.2.1.8, 4.2.2.1.10, 4.2.2.1.11。本文旨在为读者揭示5G相对于4G在数据安全上的革命性进步，以及gNodeB在其中扮演的关键角色。
引言：李明的新挑战——为自动驾驶数据保驾护航
在“星辰通信”的实验室里，工程师李明刚刚因为出色地完成了RRC信令安全的验证工作而受到导师艾米的表扬。然而，他还没来得及庆祝，一项更严峻的挑战就摆在了面前。
“李明，祝贺你掌握了控制面的安全机制，” 艾米递给他一份新的项目需求文档，“但对我们的客户而言，他们更关心的是实际业务数据的安全。我们的一个潜在重要客户——‘智行汽车’，希望利用5G网络传输他们自动驾驶车辆的实时遥测和控制数据。他们对数据的机密性和完整性要求是最高级别的。你今天的任务，就是彻底搞懂并验证Orion-gNB 9000的用户面安全功能。”
李明打开文档，立刻感受到了压力。“智行汽车”的需求非常具体：任何情况下都不能允许车辆的传感器数据在空中被篡改，哪怕一个字节都不行；同时，车辆的行驶轨迹、控制算法等商业机密数据绝不能被窃听。
“这正是5G用户面安全的用武之地，” 艾米补充道，“与4G时代用户面完整性保护只是‘选配’不同，5G将其提升到了‘标配’的高度，但这套机制的启动与否，比RRC信令要复杂。gNodeB不再是唯一的决策者。去吧，深入规范，找出答案。”
李明带着新的使命，再次投入到对3GPP TS 33.511的研读中。他知道，用户面安全，是守护亿万用户数据隐私和关键行业应用安全的最后一道，也是最重要的一道空中防线。
1. 谁来发令？—— SMF在用户面安全中的决定性作用
李明首先发现了一个与RRC安全显著的不同之处：用户面数据的保护并不是默认开启的，而是由核心网的“大脑”——SMF（Session Management Function，会话管理功能）来决策的。
4.2.2.1.10 Ciphering of user data based on the security policy sent by the SMF Requirement Description: The gNB activates ciphering of user data based on the security policy sent by the SMF as specified in TS 33.501, clause 5.3.2.
4.2.2.1.11 Integrity of user data based on the security policy sent by the SMF Requirement Description: The gNB activates integrity protection of user data based on the security policy sent by the SMF as specified in TS 33.501, clause 5.3.2.
【李明的深度解读】
这两条需求明确指出，gNodeB只是一个“执行者”，而“发令者”是SMF。
在一个用户（比如一部手机，或者“智行汽车”的车载单元）发起PDU会话（可以理解为一次上网连接）时，SMF会根据多种信息来决定这个会话的用户面安全策略（UP Security Policy）。这些信息可能包括：
- 用户的签约数据（例如，这是一个高安全等级的物联网套餐）。
- 所连接的数据网络（DNN）的特性（例如，连接的是企业内网还是公共互联网）。
- 具体的业务类型（QoS Flow）。
SMF制定的策略分为三个等级：
- Required (必须): gNodeB必须对该会話的用户数据启用加密和/或完整性保护。如果因为某些原因（如UE能力不支持）无法满足，会话建立就会失败。对于“智行汽车”这样的客户，他们的签约数据里，这个策略一定是“Required”。
- Preferred (首选): gNodeB应优先尝试启用安全保护。但如果UE不支持，会话仍然可以建立，只是数据是“裸奔”的。这适用于一些对安全不那么敏感，但希望兼容老旧设备的场景。
- Not Needed (不需要): 无需启用安全保护。
gNodeB在收到SMF通过AMF传递过来的安全策略后，必须不折不扣地执行。
【实验室实战：复现TC-UP-DATA-CIP-SMF与TC-UP-DATA-INT-SMF测试】
为了验证这一点，李明使用了核心网模拟器，扮演SMF的角色，向Orion-gNB 9000发送不同的安全策略。
- 场景一 (策略：Required): 李明配置模拟SMF，在PDU会话建立过程中，向gNodeB下发“完整性保护：Required”的策略。然后，他观察到gNodeB在后续的
RRCReconfiguration消息中，明确地向UE指示了需要开启用户面完整性保护。 - 场景二 (策略：Not Needed): 接着，李明发起另一个PDU会话，但这次SMF下发的策略是“完整性保护：Not Needed”。如他所料，gNodeB这次发送的
RRCReconfiguration消息中，就没有包含开启用户面完整性保护的指示。
Expected Results: When the received UP integrity protection is set to “required”, the user plane packets are integrity protected based on the security policy sent by the SMF. When the received UP integrity protection is set to “not needed”, the user plane packets are not integrity protected based on the security policy sent by the SMF.
这个实验清晰地证明了Orion-gNB 9000能够正确地听从SMF的指挥，担当好安全策略执行者的角色。
2. 用户数据的“三重锁”：坚不可摧的空中数据保险箱
一旦SMF下令“保护”，gNodeB就会为用户数据加上一套与RRC信令保护机制类似，但使用独立密钥的“三重锁”。
2.1 第一重锁：完整性保护 (Integrity Protection) - 捍卫数据的真实性
这是5G相对于4G在用户面安全上最大的飞跃。
4.2.2.1.2 Integrity protection of user data between the UE and the gNB Requirement Name: Integrity protection of user data between the UE and the gNB. Requirement Description: The gNB supports integrity protection and replay protection of user data between the UE and the gNB as specified in TS 33.501, clause 5.3.3. NOTE: This requirement does not apply to the gNB that is used as a secondary node connecting to the EPC.
【李明的深度解读】
“为什么‘智行汽车’如此看重完整性？”李明想，“因为对于自动驾驶，错误的数据比没有数据更可怕。”
想象一下，一辆自动驾驶汽车正在高速行驶，它通过5G网络实时接收来自路边单元（RSU）的交通信息。如果一个攻击者能够篡改这些数据，将“前方绿灯”篡改成“前方红灯”，或者将“前方无障碍”篡改成“前方有障碍”，都可能导致严重的交通事故。
5G的用户面完整性保护，就是为了杜绝这种风险。它使用一套专用于用户面的完整性密钥（KUPint），对每一个上行和下行的用户数据包（PDCP PDU）计算MAC-I。其原理与RRC完整性保护完全相同，但密钥是独立的，确保了控制面和用户面安全的分离。
【实验室实战：复现TC-UP-DATA-INT_gNB测试用例】
李明搭建了端到端的测试环境，模拟“智行汽车”的数据传输。
- 策略设置: 他首先确保核心网模拟器下发了“UP Integrity Protection: Required”的策略。
- 启动业务: 他在模拟UE和网络侧服务器之间发起了一段UDP数据流，模拟车载摄像头画面的上传。
- 捕获与验证: 使用空口分析仪，李明捕获到了这些UDP数据包。在每个数据包的PDCP PDU尾部，他都看到了一个4字节的MAC-I。他将数据包内容和预置的KUPint密钥输入验证工具，结果完美匹配。
实验证明，Orion-gNB 9000为“智行汽车”的数据流加上了第一把、也是最关键的一把锁。
2.2 第二重锁：机密性保护 (Ciphering) - 守护数据的隐私
4.2.2.1.7 Ciphering of user data between the UE and the gNB Requirement Name: Ciphering of user data between the UE and the gNB. Requirement Description: The gNB supports ciphering of user data between the UE and the gNB as specified in TS 33.501, clause 5.3.2.
【李明的深度解读】
机密性保护，即加密，是为了防止数据被窃听。“智行汽车”的自动驾驶算法、车辆的精确GPS轨迹、甚至车内乘客的语音交互数据，都属于高度敏感的商业和个人隐私。如果这些数据在空中“裸奔”，就可能被竞争对手或黑客获取。
用户面加密使用另一把独立的密钥——KUPenc。在启用后，所有用户数据的载荷都会被加密成无法被解读的密文，只有拥有正确密钥的gNodeB和UE才能将其还原。
【实验室实战：复现TC-UP-DATA-CIP_gNB测试用例】
李明继续他的测试。
- 策略设置: SMF模拟器下发“UP Ciphering: Required”策略。
- 捕获与解密: 他再次捕获了模拟摄像头上传的UDP数据流。在空口分析仪上，数据包的载荷部分显示为一堆毫无规律的乱码。但当他将这段密文和KUPenc密钥导入到测试工具的解密模块后，清晰的原始图像数据立刻呈现了出来。
第二把锁也稳稳地锁上了。
2.3 第三重锁：抗重放保护 (Replay Protection) - 确保数据的时效性
4.2.2.1.8 Replay protection of user data between the UE and the gNB Requirement Name: Replay protection of user data between the UE and the gNB. Requirement Description: The gNB supports integrity protection and replay protection of user data as specified in TS 33.501, clause 5.3.3.
【李明的深度解读】
重放攻击在用户面同样危险。李明设想了一个场景：攻击者录制了一段“智行汽车”发出的合法数据包，内容是“请求紧急刹车”。然后，在几分钟后，当车辆在空旷的高速公路上正常行驶时，攻击者将这段录制的数据包重放给网络。如果gNodeB接收并处理了这条过时的指令，可能会错误地触发车辆的紧急制动，造成追尾事故。
用户面的抗重放机制与RRC信令一样，依赖于单向递增的PDCP COUNT值。由于COUNT值参与了MAC-I的计算，任何重放的、带有过时COUNT值的数据包，都会因为MAC-I校验失败（如果接收方用当前的COUNT去计算）或者被接收窗口拒绝而被gNodeB丢弃。
【实验室实战：复现TC-UP-DATA-REPLAY_gNB测试用例】
李明最后一次扮演“黑客”。
- 捕获: 他捕获了一个合法的、COUNT值为N的用户数据包。
- 重放: 等待片刻，他将这个COUNT值为N的数据包重新发送给Orion-gNB 9000。
- 验证: 通过检查gNodeB的底层日志，他确认gNodeB的PDCP层因为检测到这是一个重复的或过期的COUNT值而将其丢弃，上层的应用对此毫无察觉。
第三把锁也验证无误。Orion-gNB 9000为用户数据构建了一个坚固的空中保险箱。
3. 入侵应对：用户面完整性校验失败的处理
4.2.2.1.5 UP integrity check failure Requirement Name: UP integrity check failure Requirement Reference: TS 33.501, clause 6.6.4 Requirement Description: If the gNB or the UE receives a PDCP PDU which fails integrity check with faulty or missing MAC-I after the start of integrity protection, the PDU is discarded as specified in TS 33.501, clause 6.6.4.2.
【李明的深度解读】
与RRC信令一样，当gNodeB收到一个完整性校验失败的用户数据包时，唯一的正确动作就是静默丢弃 (discarded)。对于每秒可能包含成千上万个数据包的高速用户数据流来说，这一点尤为重要。如果对每个坏包都产生告警或响应，不仅会给系统带来巨大负担，还可能被利用于发起拒绝服务攻击。
李明在实验室里，向Orion-gNB 9000发送了大量缺少MAC-I或MAC-I错误的用户数据包，gNodeB都如规范所要求的那样，稳定地将它们一一丢弃，保证了正常业务流不受影响。
FAQ 环节
Q1：5G用户面完整性保护相比4G，最大的不同是什么？ A1：最大的不同在于，4G（LTE）的用户面完整性保护是可选的（Optional），在实际商用网络中很少部署。而5G将其定义为一项基础安全能力，虽然其开启与否受核心网SMF的策略控制，但gNodeB和UE必须支持该功能。这使得为高安全需求业务（如自动驾驶、工业控制）提供端到端的完整性保护成为可能，是5G安全的一大进步。
Q2：用户面的密钥（KUPint, KUPenc）和控制面的密钥（KRRCint, KRRCenc）是相同的吗？ A2：不相同。它们是两套完全独立的密钥。这两套密钥都是由gNodeB基于从核心网AMF获取的根密钥KgNB派生出来的，但是使用不同的派生算法和参数。这种设计确保了控制面和用户面之间的安全隔离，即使一套密钥出现问题，也不会影响另一套的安全性。
Q3：如果SMF下发的策略是“Preferred”，gNodeB会如何处理？ A3：如果策略是“Preferred”，gNodeB会首先检查UE上报的安全能力，看它是否支持所要求的安全算法。如果UE支持，gNodeB就会启动安全保护，这与“Required”的行为类似。但如果UE不支持，gNodeB将不会启动安全保护，但PDU会话依然会成功建立，只是数据会在没有保护的情况下传输。
Q4：所有用户数据都会被加密和完整性保护吗？ A4：不是的。是否进行保护，以及具体是进行加密保护、完整性保护还是两者都进行，完全取决于SMF为该PDU会话设定的安全策略。例如，对于一个普通的手机上网业务，运营商可能会设定为“Ciphering: Preferred, Integrity: Not Needed”；而对于“智行汽车”的专网业务，则一定会设定为“Ciphering: Required, Integrity: Required”。
Q5：为什么处理完整性校验失败时，gNodeB要“静默丢弃”？ A5：这主要是出于两个安全考虑：1) 防止信息泄露：不给攻击者任何关于其攻击是否成功或失败的反馈信息。2) 增强系统鲁棒性：用户数据流量巨大，如果对每一个坏包都进行上报或响应，会消耗大量系统资源，容易被攻击者利用发起DoS（拒绝服务）攻击。静默丢弃是最有效、最安全、资源消耗最小的处理方式。