51学通信

深度解析 3GPP TS 33.501：6.6 UP security mechanisms (用户平面安全机制)

21分钟阅读

深度解析 3GPP TS 33.501：6.6 UP security mechanisms (用户平面安全机制)

本文技术原理深度参考了3GPP TS 33.501 V18.9.0 (2025-03) Release 18规范中，关于“6.6 UP security mechanisms”的核心章节，旨在为读者深入剖析5G中用于保护实际用户数据的“装甲卡车”——用户平面（UP）安全机制。

在前面的文章中，我们已经深入探讨了保护5G“神经系统”的NAS安全和RRC安全机制。我们了解到，无论是UE与核心网AMF之间的“中央指令”，还是UE与基站gNB之间的“现场调度”，都受到了严密的保护。然而，这些都属于控制平面（Control Plane）的安全。对于用户来说，他们真正关心的，是他们的数据——观看的视频、发送的消息、游戏的数据流——能否安全传输。

今天，我们将聚焦于保护这些“数字货物”的用户平面（User Plane, UP）安全机制，即规范的6.6节。如果说控制平面安全是保护“指挥系统”的安全，那么用户平面安全就是保护“运输系统”的安全。本章将详细揭示：

  • 用户数据的安全策略由谁制定？是基站还是核心网？
  • 这个安全策略是如何从“大脑”传达到“前线”并被执行的？
  • 保护用户数据的“装甲”——加密与完整性保护——具体是如何实施的？

我们的工业主角，AGV“智行一号”，已经成功与网络建立了安全的控制连接。现在，它即将开始执行其核心任务：利用其搭载的8K超高清摄像头，对生产线上的产品进行实时质量检测，并将视频流实时回传到工厂的AI分析服务器。这段高清视频流，就是典型的用户平面数据。它的机密性和完整性直接关系到工厂的生产质量和商业秘密。核心网工程师“李工”的任务，就是确保这辆“装甲卡车”运送的“珍贵货物”万无一失。

1. 战场剖析：UP安全 vs. CP安全 - “货物”与“指令”的分野

在深入细节之前，我们必须再次强调用户平面（UP）安全与控制平面（CP, 包括NAS和RRC）安全的核心区别。

特性控制平面安全 (NAS/RRC)用户平面安全 (UP)
保护对象信令消息 (控制指令)用户数据 (视频、网页、游戏数据等)
数据路径UE ←> AMF (NAS)
UE ←> gNB (RRC)		UE ←> gNB ←> UPF ←> 数据网络
策略制定者AMF (NAS), gNB (AS)SMF (Session Management Function)
激活方式安全模式命令 (SMC)RRC连接重配置 (承载建立过程)

场景代入： 李工指着网络拓扑图解释道：“‘智行一号’和AMF之间的NAS信令，决定了它‘去哪里’、‘它的身份是什么’。它和gNB之间的RRC信令，决定了它‘走哪条车道’、‘车速是多少’。这些都是指令。而‘智行一号’摄像头拍下的视频流，是它要运送的货物。货物最终要送到数据网络（DN）里的AI服务器，途中会经过一个叫UPF（用户平面功能）的‘高速中转站’。我们今天要谈的UP安全，就是保护这些货物在从‘智行一号’到gNB这段最危险的空中路途上的安全。”

2. 6.6.1 UP安全策略 - 来自“会话大脑”SMF的“安全指令”

与控制信令的安全性由AMF和gNB主导不同，用户平面数据的安全策略，其最高决策者是SMF（会話管理功能）。

The SMF shall provide UP security policy for a PDU session to the ng-eNB/gNB during the PDU session establishment procedure as specified in TS 23.502. The UP security policy shall indicate whether UP confidentiality and/or UP integrity protection shall be activated or not for all DRBs belonging to that PDU session.

解读：

  1. 决策者是SMF：SMF是PDU会话（可以理解为UE的一次数据连接）的“大脑”，它负责IP地址分配、QoS策略、计费策略等。因此，与该会话相关的安全策略也自然由它来制定。
  2. 下达时机：在PDU会话建立的过程中，SMF会将UP安全策略通过AMF，最终传递给gNB。
  3. 策略内容：策略非常明确，它会针对这个PDU会话下的所有数据无线承载（DRB），分别规定机密性保护（加密）和完整性保护的策略。策略有三种：
    • Required (需要)：强制要求开启。如果gNB或UE因为某种原因无法满足，则该PDU会话建立会失败。
    • Preferred (首选)：建议开启。gNB会尽力开启，但如果因为资源等原因无法满足，也可以不开启。
    • Not Needed (不需要)：明确指示无需开启。

The ng-eNB/gNB shall activate UP confidentiality and/or UP integrity protection per each DRB, according to the received UP security policy… If the ng-eNB/gNB cannot activate UP … protection when the received UP security policy is “Required”, the ng-eNB/gNB shall reject establishment of UP resources…

gNB的角色：忠实的执行者 gNB在UP安全中，完全是一个策略执行者。它严格按照SMF下发的“安全指令”来配置无线承载。如果SMF要求“Required”，而gNB做不到（例如，自身处理能力达到上限），它就必须拒绝为这个PDU会话分配无线资源。

场景代入： 李工正在为“智行一号”的PDU会话配置策略。

  • 会话一：实时视频流。这是核心生产数据，机密且不容篡改。李工在SMF上将这个会话的UP安全策略配置为：Confidentiality=Required, Integrity=Required。
  • 会话二：设备心跳和日志。这些数据敏感度较低，但为了防止被伪造，需要完整性。李工配置为：Confidentiality=Not Needed, Integrity=Preferred。 当“智行一号”请求建立视频流会话时，SMF会将{Required, Required}这条策略下发给gNB。gNB收到后，就会在后续的配置中，强制为承载视频流的DRB开启加密和完整性保护。

3. 6.6.2 UP安全激活机制 - 一场由RRC主导的“上锁仪式”

策略已经制定，如何将其在UE和gNB之间落地执行？这个“上锁仪式”是通过**RRC连接重配置（RRC Connection Reconfiguration）**流程来完成的，这个流程同时也是建立数据无线承载（DRB）的流程。

规范中的 Figure 6.6.2-1: User plane (UP) security activation mechanism 详细描绘了这一过程。

核心步骤拆解：

1a. This RRC Connection Reconfiguration procedure … shall be performed only after RRC security has been activated… 前提 (Step 1a)：必须先完成RRC安全激活（AS SMC流程）。这意味着，执行UP安全的“指令”本身，是在一条已经受保护的RRC信道（SRB）上传输的，确保了指令本身不会被篡改。

1b. The gNB/ng-eNB shall send the RRC Connection Reconfiguration message to the UE for UP security activation containing indications for the activation of UP integrity protection and ciphering for each DRB according to the security policy. 指令下达 (Step 1b)：gNB向UE发送RRC Connection Reconfiguration消息。这条消息的核心内容是：“请为XX业务建立一个新的DRB，并对这个DRB开启/关闭加密，开启/关闭完整性保护。”（这里的开关指令就源自SMF的策略）。

1c. If UP integrity protection is activated…, the gNB/ng-eNB shall generate KUPint… Similarly, if UP ciphering is activated…, the gNB/ng-eNB shall generate KUPenc… gNB侧准备 (Step 1c)：在发送指令的同时，gNB会立即从K_gNB派生出用户平面专用的**K_UPint和K_UPenc**密钥。准备工作就绪后，它就开始使用这些新密钥保护即将发往UE的下行用户数据。

2a. UE shall verify the RRC Connection Reconfiguration message. If successful: 2a.1/2a.2 …the UE shall generate KUPint… the UE shall generate KUPenc… UE侧执行 (Step 2a)：UE收到RRC Connection Reconfiguration消息后，首先用已有的RRC安全密钥验证其完整性。验证通过后，UE也从自己的K_gNB派生出与gNB完全相同的K_UPint和K_UPenc。准备工作就绪后，它就开始使用新密钥保护即将发往gNB的上行用户数据。

2b. If the UE successfully verifies integrity…, the UE shall send the RRC Connection Reconfiguration Complete message to the gNB/ng-eNB. 确认完成 (Step 2b)：UE发送RRC Connection Reconfiguration Complete消息，告知gNB：“指令已收到并成功执行，新DRB的安全通道已建立。” 这条确认消息本身也是在受RRC安全保护的信道上发送的。

至此，一个用户平面的安全承载就成功建立了。

4. 6.6.3 & 6.6.4 机密性与完整性机制 - “装甲”的技术细节

这部分的原理与RRC和NAS安全高度一致，都是在PDCP层实现，并使用严格定义的参数集。

6.6.3 UP confidentiality mechanisms The input parameters to the 128-bit NEA algorithms … are the message packet, an 128-bit cipher key KUPenc as KEY, a 5-bit bearer identity BEARER…, DIRECTION…, LENGTH… and a 32-bit input COUNT…

6.6.4 UP integrity mechanisms The input parameters to the 128-bit NIA algorithms … are, the message packet, a 128-bit integrity key KUPint as KEY, a 5-bit bearer identity BEARER…, DIRECTION…, and a 32-bit input COUNT…

核心参数解读：

  • KEY: 专用的**K_UPenc和K_UPint**，派生自K_gNB。
  • COUNT: 32位的PDCP COUNT。关键在于，每一个DRB（数据无线承载）都有自己独立的一套上行和下行PDCP COUNT。这意味着，“智行一号”的视频流承载和它的日志承载，各自有独立的序列号计数器，互不干扰，确保了各自的防重放保护。
  • BEARER: DRB的ID。这个ID将数据包与正确的密钥、正确的COUNT计数器关联起来。
  • DIRECTION: 0 for uplink, 1 for downlink。

场景代入： “智行一号”的摄像头捕捉到一帧8K视频画面，将其打包成一个IP包。

  1. 这个IP包被送往手机模组的PDCP层。
  2. PDCP层识别出这个包属于视频流DRB。
  3. 它取出视频流DRB专用的K_UPint和K_UPenc。
  4. 它读取该DRB的上行COUNT计数器，假设当前是5001。
  5. 它首先用K_UPint和COUNT=5001等参数计算出MAC值。
  6. 然后，它用K_UPenc和COUNT=5001等参数生成密钥流，对IP包和MAC值一起进行加密。
  7. 最后，将加密后的数据包和PDCP头（包含COUNT的序列号部分）一起发送给gNB。
  8. 同时，本地的上行COUNT计数器增加为5002，为下一个数据包做准备。

5. 总结

本章深入解读的6.6节，为我们揭示了5G用户平面安全的完整运作逻辑，它是一套策略与执行分离、高度灵活且安全可靠的系统。

  • 策略核心在SMF：用户数据的安全等级（是否加密、是否完整性保护）最终由核心网的SMF根据业务属性和签约策略来决定，体现了网络对业务的精细化控制能力。
  • 执行枢纽在gNB：gNB作为策略的忠实执行者，负责将SMF的策略通过安全的RRC信令，转化为UE和gNB之间具体的安全行为。
  • 实现在PDCP：所有的加密和完整性保护操作都在PDCP层完成，通过专用的UP密钥（K_UPenc/K_UPint）和独立的DRB计数器，为每一条用户数据流提供了独立的、强大的安全保障。
  • 流程环环相扣：从NAS安全，到RRC安全，再到UP安全，这是一个层层递进、信任逐级传递的过程。没有安全的NAS，就没有可信的K_AMF；没有K_AMF，就没有可信的K_gNB；没有K_gNB和安全的RRC信道，就无法安全地激活UP安全。

这一整套机制，确保了无论是“智行一号”传输的工业数据，还是安安观看的高清视频，在飞越最脆弱的无线空口时，都乘坐在一辆量身定制的、坚不可摧的“装甲卡车”之中。

FAQ

Q1：为什么用户平面（UP）安全的策略制定者是SMF，而不是AMF？ A1：这是由5G核心网的职责划分决定的。AMF（接入和移动性管理功能）的核心职责是“连接管理”，它关心UE“在哪里”、“是否合法接入”、“是否在线”。而SMF（会话管理功能）的核心职责是“会话管理”，它关心UE的“数据通道”是什么样的，包括IP地址、QoS（服务质量）、计费规则，以及与之配套的安全策略。用户数据的安全等级与业务类型（如视频、网页、物联网）紧密相关，而这些业务属性正是在PDU会话层面由SMF管理的。因此，将UP安全策略的决策权放在SMF，是最符合其功能定位的。

Q2：如果一个PDU会话中有多个数据流（QoS Flow），它们的UP安全策略都一样吗？ A2：在一个PDU会话内，所有的数据流（QoS Flow）会映射到一个或多个数据无线承载（DRB）。规范6.6.1节规定，SMF下发的UP安全策略是针对整个PDU会话的，因此，属于同一个PDU会话的所有DRB，都将遵循相同的UP安全策略。如果你需要为不同的数据流设置不同的安全策略（例如，视频流高安全，普通网页浏览低安全），那么你需要建立两个不同的PDU会话，并由SMF为它们分别配置不同的UP安全策略。

Q3：开启UP完整性保护对性能的影响到底有多大？ A3：影响主要体现在两个方面：1) 吞吐量下降：每个数据包都需要增加一个4字节（32位）的MAC值，这会带来固定的协议开销。对于小包业务，这个开销比例会比较高。2) 处理时延增加和功耗增大：UE和gNB的PDCP层都需要为每个数据包执行一次额外的MAC计算和验证，这会消耗CPU/硬件资源，带来微秒级的处理时延，并增加设备的功耗。对于追求极致低时延的URLLC业务和对功耗极其敏感的mMTC设备，这个影响是需要认真评估的。

Q4：如果gNB在执行UP安全激活时，收到的SMF策略是Preferred，它会如何决策？ A4：如果策略是Preferred（首选），gNB拥有一定的决策权。它会综合考虑多种因素来决定是否开启保护，例如：

  • 自身资源：gNB当前的处理负荷是否允许增加额外的密码学计算开销？
  • 无线环境：当前的无线信号质量如何？是否需要为了对抗高误码率而牺牲一点性能来换取更高的可靠性？
  • UE能力：虽然UE必须支持标准算法，但不同芯片的性能可能有差异。
  • 本地策略：运营商可能在gNB本地配置一些更细化的策略，例如“在负载低于70%时，Preferred策略等同于Required”。

Q5：我使用VPN时，数据已经是端到端加密了，5G的UP加密还有必要吗？ A5：非常有必要，它们工作在不同层面，提供互补的保护。

  • VPN：通常是应用层或网络层的端到端加密，保护的是从你的设备（如PC或手机）到VPN服务器（可能在千里之外）的整条路径。它不关心中间经过了Wi-Fi还是5G。
  • 5G UP加密：是数据链路层（PDCP层）的逐跳加密，它只保护UE到gNB这一段最脆弱的无线空口。 两者结合，提供了“隧道中的隧道”式的纵深防御。即使UP加密在理论上被攻破，你的数据依然受到VPN的保护。反之，如果VPN配置错误或存在漏洞，UP加密依然能保护你的数据不被附近的空口窃听者获取。对于高安全需求的用户，同时使用两者是最佳实践。

关系图谱