51学通信

深度解析 3GPP TS 33.501：6.10 Dual connectivity (双连接安全)

17分钟阅读

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

深度解析 3GPP TS 33.501：6.10 Dual connectivity (双连接安全)

本文技术原理深度参考了3GPP TS 33.501 V18.9.0 (2025-03) Release 18规范中，关于“6.10 Dual connectivity”的核心章节，旨在为读者深度剖析5G中一种独特且强大的组网模式——双连接（DC）下的安全机制。

在前面的文章中，我们已经详细探讨了UE在单个连接下的各种安全场景，包括静止状态的转换和高速移动中的切换。然而，5G为了追求极致的性能和可靠性，引入了一种更为复杂的连接模式——双连接（Dual Connectivity, DC）。在这种模式下，一个UE可以同时与两个基站建立并维持RRC连接。

今天，我们将深入解读规范的6.10节——双连接安全。这一节将为我们揭示，当一个UE从“单线程”工作模式切换到“双线程”模式时，网络是如何为这第二条连接安全地“授权”和“赋能”的。我们将了解到：

  • 双连接中的“主节点”（MN）和“辅节点”（SN）是如何进行安全分工的？
  • 为辅节点（SN）生成的专属密钥K_SN是如何被安全地派生和分发的？
  • 当UE需要更新辅节点的密钥时，又该如何操作？

为了更好地理解这个场景，我们的主角“安安”正在体验一款沉浸式的VR游戏，这款游戏需要极高的带宽和极低的延迟。为了保障她的极致体验，她所在的网络为她启动了5G最强大的“涡轮增压”模式——NR-DC双连接。她的手机将同时连接到一个宏基站和一个微基站，一条链路负责稳定的控制和基础数据，另一条则全力冲刺高速下载。而核心网工程师“李工”，将为我们剖析，这个“涡轮增压”模式的安全引擎是如何被点燃的。

1. 6.10.1 双连接简介 - “主副驾”协同驾驶

双连接的核心思想，是将UE的连接控制分为“主”和“辅”。

  • 主节点 (Master Node, MN)：UE最先连接上的基站，负责与核心网AMF的主要信令交互（通过NG-C接口），并终结控制平面的RRC信令。它就像汽车的“主驾驶员”。
  • 辅节点 (Secondary Node, SN)：由主节点（MN）根据业务需求为UE引入的第二个基站。它主要用于分担用户平面的数据流量，拥有独立的调度器，但其控制权由主节点掌握。它就像一位“副驾驶员”，可以帮忙操控方向盘的一部分，但最终的路线决策由主驾驶员做出。

6.10.1.2 Dual Connectivity protocol architecture for MR-DC with 5GC The architecture has the following variants:

  • NGEN-DC: ng-eNB (MN) + gNB (SN)
  • NE-DC: gNB (MN) + ng-eNB (SN)
  • NR-DC: gNB (MN) + gNB (SN)

双连接有多种组合方式，可以是4G基站和5G基站的组合（NGEN-DC, NE-DC），也可以是两个5G基站的组合（NR-DC）。安安体验VR游戏时，网络为她启用了最高性能的NR-DC模式。

2. 6.10.2 & 6.10.3 SN安全上下文的建立 - “副驾”的上岗仪式

双连接安全的核心，就是如何为主节点（MN）之外的辅节点（SN）建立一个独立且安全的上下文。这个过程完全由主节点（MN）主导。

2.1 K_SN密钥的派生与分发 (6.10.2.1, 6.10.3.2)

当MN决定为UE添加一个SN时，它需要为SN生成一个专用的会话密钥K_SN。

6.10.3.2 Derivation of keys The UE and MN shall derive the security key KSN of the SN as defined in Annex A.16 of the present document.

K_SN的派生遵循了5G一贯的安全原则：

  • 父密钥：K_SN的父密钥是MN持有的K_gNB。
  • 新鲜性来源：为了确保每次为SN生成的K_SN都是全新的，MN会维护一个专门的计数器——SN Counter。每次需要生成新的K_SN时，MN都会将这个计数器的值加1。
  • 派生过程：MN和UE都会独立地使用K_gNB和当前SN Counter的值作为输入，通过KDF（密钥派生函数），计算出完全相同的K_SN。

When the MN establishes security context between an SN and the UE for the first time… the MN generates the KSN for the SN and sends it to the SN over the Xn-C.

  • 密钥分发：MN计算出K_SN后，会通过安全的Xn-C接口（MN和SN之间的控制面接口，受IPsec/DTLS保护）将其发送给SN。

场景代入： 安安的VR游戏流量激增，她手机当前连接的宏基站（MN）决定启用附近的一个微基站（SN）来分流。

  1. MN决策：MN查询了自己维护的SN Counter，当前值为0x05。
  2. MN派生K_SN：MN使用自己持有的、用于安安这个会话的K_gNB和SN Counter=0x05，计算出了一个新的密钥K_SN。
  3. MN通知UE：MN通过RRC连接重配置消息，告诉安安的手机：“我们要添加一个副驾驶，请你用SN Counter=0x05来为他准备一把钥匙。”安安的手机收到后，也用自己的K_gNB和0x05计算出了同一个K_SN。
  4. MN通知SN：同时，MN通过Xn接口，将计算好的K_SN直接发给了微基站（SN），并告知：“准备接收一个新用户，这是他的会话密钥。”

2.2 完整的SN添加流程 (Figure 6.10.2.1-1)

整个SN添加的安全流程可以概括为：

  1. 协商 (Step 2)：MN向SN发起SN Addition/Modification Request，其中包含了UE的安全能力和SMF下发的UP安全策略。
  2. SN决策 (Step 3)：SN根据UE的能力和自己的策略，选择AS安全算法。如果收到了K_SN，它会立即用K_SN派生出SN侧的RRC和UP密钥。
  3. SN响应 (Step 4)：SN向MN回复Acknowledge消息，告知自己选择的算法。
  4. MN指令UE (Step 5)：MN向UE发送RRC Connection Reconfiguration消息，其中包含了SN Counter（用于UE派生K_SN）和SN选择的算法。
  5. UE执行与确认 (Step 6)：UE派生K_SN和后续密钥，配置新承载，并向MN回复RRC Reconfiguration Complete。
  6. MN通知SN (Step 7)：MN向SN发送SN Reconfiguration Complete，告知UE侧已配置完成。

至此，SN的“上岗仪式”全部完成。UE现在同时与MN和SN保持着安全的连接。

3. 6.10.2.2 SN密钥更新 - “副驾”的密钥更换

The SN shall request the Master Node to update the KSN over the Xn-C, when uplink and/or downlink PDCP COUNTs are about to wrap around for any of the SCG DRBs or SCG SRB.

与主连接一样，辅连接（SCG, Secondary Cell Group）上的PDCP COUNT计数器也有可能耗尽。为了防止密钥流重用，必须及时更新K_SN。

  • 触发者是SN：当SN检测到其与UE之间的某个承载的COUNT即将回绕时，它会主动向MN发起SN Modification Required请求，并在请求中明确指出“需要更新密钥”。
  • 执行者是MN：MN收到请求后，会履行其“主驾驶员”的职责。它会将SN Counter加1，派生出一个全新的K_SN，然后通过SN Modification流程，将新的SN Counter告知UE，并将新的K_SN分发给SN。
  • MN主动更新：MN也可以基于本地策略，在任何时候主动发起SN密钥更新流程。

这个机制确保了即使在长期、大流量的双连接会话中，辅节点的安全性也能得到持续的保障。

4. 6.10.4 流量保护 - “主副驾”各自守好自己的“车道”

The SN RRC and UP keys shall be derived from the KSN both at the SN and the UE… When the SN is a gNB, the RRC traffic protection directly between the UE and SN is done using the mechanism described in subclause 6.5…

一旦SN的安全上下文建立，UE与SN之间的流量保护，就遵循与UE和MN之间完全相同的机制。

  • SN侧密钥：SN和UE会基于共享的K_SN，派生出专用于SN链路的RRC密钥（K_SRB-SN_int/enc）和UP密钥（K_DRB-SN_int/enc）。
  • 独立保护：UE与MN之间的流量，使用基于K_gNB的密钥进行保护；UE与SN之间的流量，使用基于K_SN的密钥进行保护。这两套密钥体系是完全独立、互不干扰的。

场景代入： 安安的手机正在运行VR游戏。

  • 上行：游戏的控制信令（数据量小，但时延要求高）通过与MN的连接发送；而高清的VR视频上传流，则通过与SN的高带宽连接发送。
  • 保护：控制信令受到了K_gNB派生密钥的保护，视频流则受到了K_SN派生密钥的保护。两路流量在PDCP层被“兵分两路”，各自进行了独立的加密和完整性保护，然后在物理层被同时发送出去。

5. 总结

本章深入解读的6.10节，为我们揭示了5G双连接模式下精巧而健壮的安全体系。

  • MN主导的中心化控制：所有与SN相关的安全决策、密钥生成和分发，都由主节点（MN）统一管理。这形成了一个清晰的指挥链，避免了多头管理带来的安全风险和复杂性。
  • 基于SN Counter的新鲜性机制：通过引入一个由MN维护的SN Counter，确保了每一次为SN生成的密钥K_SN都是全新的、不可预测的，保障了辅连接的安全性。
  • 独立的密钥体系：MN和SN拥有各自独立的密钥体系（分别源于K_gNB和K_SN），实现了两条链路之间的安全隔离。一条链路的安全问题不会影响到另一条。
  • 主动的密钥更新：SN具备主动请求密钥更新的能力，确保了在长期大流量场景下，能够有效防止COUNT回绕等密码学风险。

双连接安全机制，是5G能够提供超越前代网络性能和可靠性的重要基石。它以一种看似复杂但逻辑严谨的方式，将单连接的安全模型成功地扩展到了“双核驱动”的场景，为VR/AR、工业控制等超高性能要求的应用提供了坚实的安全保障。

FAQ

Q1：K_gNB和K_SN之间是什么关系？ A1：是父子派生关系。K_gNB是主节点（MN）持有的、从核心网AMF获得的AS层根密钥。当需要为辅节点（SN）建立连接时，MN会使用K_gNB作为父密钥，再结合一个“新鲜性”参数SN Counter，通过KDF派生出子密钥K_SN。因此，K_SN的信任根源自K_gNB，进而源自K_AMF。

Q2：为什么不让AMF直接为SN也生成一个K_gNB？ A2：这是为了降低核心网的信令复杂度和开销。双连接是一个非常频繁且动态的无线侧操作，可能在一个会话中多次添加、释放和更换SN。如果每一次操作都需要MN去请求核心网AMF介入并生成新密钥，将会产生大量的NGAP信令交互，增加核心网的负担，并可能影响双连接建立的时延。通过授权MN基于其已有的K_gNB自行派生K_SN，将安全上下文的建立过程“下沉”到了无线接入网（RAN）内部，实现了高效的本地化管理。

Q3：UE和SN之间的RRC信令（SRB）是如何保护的？SN也有自己的RRC吗？ A3：是的。在双连接模式下，可能会建立一个或多个辅信令无线承载（SRB, a.k.a. SRB3 in NR-DC），专门用于UE和SN之间传输一些特定的RRC消息（例如，SN侧的测量报告）。这条SRB的保护，就是使用从K_SN派生出的K_SRB-SN_int和K_SRB-SN_enc密钥。而UE与MN之间的主信令承载（SRB1/SRB2）则继续使用从K_gNB派生的密钥进行保护。

Q4：如果UE在双连接状态下发生切换（Handover），会发生什么？ A4：这取决于切换的类型。

  • MN切换：如果主节点（MN）发生切换，整个双连接会话通常会先被“拆解”，即释放SN的连接。UE首先完成向新的MN的切换，建立起与新MN的安全上下文。然后，新的MN再根据需要，重新为UE发起一次全新的SN Addition流程。
  • SN切换：如果只是辅节点（SN）需要更换，MN会执行SN Modification或SN Release + SN Addition的流程，平滑地将UE的数据流从旧SN迁移到新SN，而与MN的连接保持不变。

Q5：SN Counter和之前提到的NCC（Next Hop Chaining Counter）有什么区别？ A5：它们都是用于提供“新鲜性”的计数器，但用途完全不同。

  • NCC是与切换（Handover）相关的，它与“前向安全”密钥NH绑定，用于在不同gNB之间传递信任链。
  • SN Counter是与双连接（Dual Connectivity）相关的，它由MN独立维护，用于在同一个MN的控制下，为不同的SN或同一次SN的不同生命周期派生出不同的K_SN。 它们是服务于两种不同移动性场景的、独立的计数器机制。

关系图谱