5G NH链式推演与切换前向安全机制拆解

一、机制定位与设计动机

5G网络中，UE在gNB间频繁切换是常态。每一次切换都意味着一个新的基站需要获得与UE共享的会话密钥K~gNB~。如果密钥推演方式不当，目标基站被攻破后可能危及此前或此后的所有通信——这就是前向安全（Forward Security）和后向安全（Backward Security）问题。

3GPP TS 33.501 Release 18 Section 6.9定义了一套基于NH（Next Hop）链式密钥推演的切换安全框架。其核心思想是：AMF作为信任锚点，预先派生一条NH密钥链，在切换时将链上的密钥材料分发给目标gNB，确保每个gNB只能获得当前密钥，无法推演出过去或将来的密钥。

这套机制源自LTE时代TS 33.401的设计，在5G中沿袭并增强了密钥分离和算法体系。与EPS相比，5G引入了K~AMF~替代K~ASME~作为根密钥，密钥层级更深，NH链的绑定参数也更为丰富（PCI + ARFCN-DL双重绑定）。

二、密钥层级全景图

在展开NH链之前，先明确5G完整密钥层级中切换相关密钥的位置：

graph TD
    K["K (USIM + UDM共享根密钥)"]
    K --> CK["CK, IK (AKA输出)"]
    CK --> KAMF["K_AMF (AMF根密钥)"]
    KAMF --> KgNB["K_gNB (gNB会话密钥)"]
    KAMF --> NH1["NH[1] = KDF(K_AMF, NH[0])"]
    NH1 --> NH2["NH[2] = KDF(K_AMF, NH[1])"]
    NH2 --> NH3["NH[3] = KDF(K_AMF, NH[2])"]
    NH3 --> NHN["...NH[n]"]
    KgNB --> KgNBstar_h["K_gNB* (水平推演)"]
    NH1 --> KgNBstar_v["K_gNB* (垂直推演)"]
    KgNB --> KRRCint["K_RRCint"]
    KgNB --> KRRCenc["K_RRCenc"]
    KgNB --> KUPenc["K_UPenc"]
    KgNB --> KNRint["K_NRint"]

    style K fill:#f9f,stroke:#333,stroke-width:2px
    style KAMF fill:#bbf,stroke:#333,stroke-width:2px
    style KgNB fill:#bfb,stroke:#333,stroke-width:2px
    style NH1 fill:#fbb,stroke:#333,stroke-width:2px
    style NH2 fill:#fbb,stroke:#333,stroke-width:2px
    style NH3 fill:#fbb,stroke:#333,stroke-width:2px

关键密钥说明：

三、NH链的推演算法（TS 33.501 Annex A.4）

3.1 NH链的生成

NH链是一条由AMF单方面预计算的单向密钥链，使用HMAC-SHA-256作为KDF：

NH[0] = K_AMF                           (初始种子)
NH[n+1] = KDF(K_AMF, NH[n])            (链式推演)

具体KDF输入参数编码（FC = 0x11）：

NH[n+1] = HMAC-SHA-256(
    Key  = K_AMF,
    Msg  = FC || P0 || L0
)
其中:
  FC = 0x11              (NH推演标识符)
  P0 = NH[n]             (前一个NH值)
  L0 = 0x00 0x20         (长度32字节=256bit)

设计意图：NH链是单向的——从NH[n]可以推演NH[n+1]，但反方向在计算上不可行（HMAC的单向性）。即使攻击者获取了某个NH[n]，也无法回推NH[n-1]及更早的密钥。AMF可以预先计算大量NH值缓存备用。

3.2 切换时的K~gNB~*推演

切换时，源gNB为目标gNB推演新的K~gNB~*，有两条路径：

水平推演（Horizontal Derivation）：

K_gNB* = KDF(K_gNB, PCI || ARFCN-DL)

KDF输入编码（FC = 0x15）：

K_gNB* = HMAC-SHA-256(
    Key  = K_gNB,                    (当前会话密钥)
    Msg  = FC || P0 || L0 || P1 || L1
)
其中:
  FC = 0x15                          (K_gNB推演标识符)
  P0 = Target PCI                    (目标小区物理标识)
  L0 = 0x00 0x02                     (2字节)
  P1 = Target ARFCN-DL              (目标下行SSB频率)
  L1 = 0x00 0x04                     (4字节)

垂直推演（Vertical Derivation）：

K_gNB* = KDF(NH[n], PCI || ARFCN-DL)

输入编码与水平推演相同（FC = 0x15），但密钥输入从K~gNB~替换为NH[n]。

3.3 两种推演路径的安全属性对比

flowchart LR
    subgraph 初始附着
        A[K_AMF] --> B[K_gNB, NCC=0]
        A --> C[NH[1], NCC=1]
    end

    subgraph 第一次切换
        B -->|水平: K_gNB* = KDF_KgNB_PCI_ARFCN| D[K_gNB*, NCC=0 → 不变]
        C -->|垂直: K_gNB* = KDF_NH_PCI_ARFCN| E[K_gNB*, NCC=1]
    end

    subgraph 第二次切换
        D -->|继续水平| F[K_gNB**, NCC=0]
        E -->|可用水平或垂直| G[K_gNB**, NCC=1或2]
    end

    style C fill:#fbb
    style E fill:#bfb
    style G fill:#bfb

四、三种切换场景的密钥处理流程

4.1 Xn切换（TS 33.501 Section 6.9.1）

Xn切换是gNB间通过Xn接口直接协调的切换，AMF不参与切换准备阶段。

sequenceDiagram
    participant UE
    participant SgNB as 源gNB
    participant TgNB as 目标gNB
    participant AMF

    Note over UE,SgNB: 当前持有K_gNB, NCC=n, NH[n]可选

    UE->>SgNB: 测量报告
    SgNB->>SgNB: 判断: NH可用? (NCC_current < NCC_AMF提供)

    alt NH可用 → 垂直推演
        SgNB->>SgNB: K_gNB* = KDF(NH[n], PCI_T, ARFCN_T)
        SgNB->>TgNB: Xn: HANDOVER REQUEST<br/>{K_gNB*, NCC=n+1}
    else NH不可用 → 水平推演
        SgNB->>SgNB: K_gNB* = KDF(K_gNB, PCI_T, ARFCN_T)
        SgNB->>TgNB: Xn: HANDOVER REQUEST<br/>{K_gNB*, NCC=n}
    end

    TgNB->>SgNB: Xn: HANDOVER REQUEST ACKNOWLEDGE
    SgNB->>UE: RRC Reconfiguration<br/>{targetCellID, NCC}
    UE->>UE: 根据NCC决定推演路径<br/>同步派生K_gNB*

    UE->>TgNB: RRC Reconfiguration Complete
    TgNB->>AMF: N2: PATH SWITCH REQUEST
    AMF->>AMF: 推演新的NH[n+1]
    AMF->>TgNB: N2: PATH SWITCH REQUEST ACKNOWLEDGE<br/>{NH[n+1], NCC=n+2}

    Note over TgNB: 缓存{NH[n+1], NCC=n+2}<br/>为下次切换准备

关键信令IE解析：

1. HANDOVER REQUEST（XnAP消息）： - SourceUE-XnAP-ID：源侧UE标识 - TargetUE-XnAP-ID：目标侧分配 - UE-Security-Capabilities：UE支持的加密/完整性算法列表 - Security-Context：包含{K~gNB~*, NCC}，这是目标gNB获得密钥材料的唯一途径 - Security-Algorithm：选定的算法对

2. RRC Reconfiguration（TS 38.331）： - reconfigurationWithSync容器中包含：

   • targetCellID（PCI + ARFCN-DL）
   • newUE-Identity（C-RNTI）
   • ncc字段——UE用它判断走水平还是垂直推演

3. PATH SWITCH REQUEST ACKNOWLEDGE（NGAP消息）： - 携带新的{NH, NCC}对，AMF借此"补充"密钥链

4.2 N2切换（TS 33.501 Section 6.9.2）

N2切换（也称NG切换）通过核心网中转，AMF全程参与，天然具备垂直推演条件。

sequenceDiagram
    participant UE
    participant SgNB as 源gNB
    participant AMF
    participant TgNB as 目标gNB

    UE->>SgNB: 测量报告
    SgNB->>AMF: N2: HANDOVER REQUIRED<br/>{Source-NG-RAN-Node-ID, Target-ID}<br/>{K_gNB, NCC_current}

    AMF->>AMF: 推演NH[n+1] = KDF(K_AMF, NH[n])
    AMF->>AMF: K_gNB* = KDF(NH[n+1], PCI_T, ARFCN_T)

    AMF->>TgNB: N2: HANDOVER REQUEST<br/>{K_gNB*, NCC=n+1}<br/>{UE Security Capabilities}

    TgNB->>TgNB: 从K_gNB*派生AS子密钥<br/>K_RRCint, K_RRCenc, K_UPenc
    TgNB->>AMF: N2: HANDOVER REQUEST ACKNOWLEDGE

    AMF->>SgNB: N2: HANDOVER COMMAND<br/>{Target ID, NCC=n+1}
    SgNB->>UE: RRC Reconfiguration<br/>{targetCellID, NCC=n+1}

    UE->>UE: NCC增大 → 垂直推演<br/>K_gNB* = KDF(NH[n+1], PCI_T, ARFCN_T)
    UE->>TgNB: RRC Reconfiguration Complete

    TgNB->>AMF: N2: HANDOVER NOTIFY

N2切换的天然优势：由于AMF直接参与，每次切换必定使用垂直推演（NH可用），天然保证前向安全。AMF在收到HANDOVER REQUIRED后立即计算NH[n+1]并用其推演K~gNB~*。

4.3 Intra-gNB切换

gNB内部切换（小区间但同一gNB）无需密钥更新，gNB内部管理即可。但如果涉及不同PCI的小区，gNB可以选择更新密钥以增强安全分离。

五、NCC同步博弈：UE与网络的状态对齐

NCC（NH Chaining Counter）是整个机制中最精妙的同步控制参数。它的值决定了UE走哪条推演路径。

5.1 NCC状态机

stateDiagram-v2
    [*] --> Attached: 初始附着
    Attached --> NCC0: K_gNB派生完成<br/>NCC=0, NH[1]由AMF预计算

    NCC0 --> NCC1_Vertical: N2切换<br/>或Xn+PathSwitch后AMF补充NH
    NCC0 --> NCC0_Horizontal: Xn切换(NH未就绪)

    NCC1_Vertical --> NCC2_Vertical: N2切换
    NCC1_Vertical --> NCC1_Horizontal: Xn切换(NH已耗尽)

    NCC0_Horizontal --> NCC0_Horizontal2: 连续Xn切换<br/>(前向安全降级!)

    note right of NCC0_Horizontal
        危险区域：连续多次Xn切换
        且无AMF补充NH时，前向安全
        不断退化
    end note

    NCC2_Vertical --> NCC3_Vertical: N2切换恢复<br/>前向安全

5.2 UE侧NCC同步逻辑

UE在收到RRC Reconfiguration中的ncc字段后执行以下判定（TS 33.501 Section 6.9.3.2）：

UE侧NH链更新算法：

for i = 1 to (NCC_new - NCC_current):
    NH = KDF(K_AMF, NH)    // 逐步推演NH链
end for
K_gNB* = KDF(NH, PCI_target, ARFCN-DL_target)
NCC_current = NCC_new

UE能独立推演NH链，因为它持有K~AMF~（在5G-AKA期间获得）和当前NH值。这是5G安全架构的关键设计——AMF和UE可以独立维护同步的NH链状态。

5.3 NCC失步场景分析

六、前向安全性的形式化验证与已知攻击面

6.1 前向安全的形式化定义

2021年ETH Zurich的论文"A Comprehensive Formal Analysis of 5G Handover"（WiSec 2021）使用Tamarin Prover对5G切换协议进行了形式化验证，定义了以下安全属性：

• gNB Forward Security：如果gNB~i~在时刻t被攻破，攻击者无法获得t时刻之前任何gNB~j~（j ≠ i）的会话密钥
• AMF Forward Security：即使攻破gNB，无法获得K~AMF~
• Key Independence：不同gNB的K~gNB~相互独立，无法互推

6.2 前向安全断裂攻击（SECRYPT 2023）

2023年Linköping大学的论文"5G Handover: When Forward Security Breaks"揭示了一个关键问题：

攻击条件：当连续发生多次Xn切换且全部使用水平推演时（即NH链未刷新），前向安全属性将断裂。

攻击链:
HO1: gNB1 → gNB2 (水平: K_gNB2* = KDF(K_gNB1, PCI2, ARFCN2))
HO2: gNB2 → gNB3 (水平: K_gNB3* = KDF(K_gNB2*, PCI3, ARFCN3))
...
HOn: gNBn → gNBn+1 (水平: K_gNB(n+1)* = KDF(K_gNBn*, PCIn+1, ARFCNn+1))

如果gNB3被攻破:
  攻击者持有K_gNB3*
  由于K_gNB3* = KDF(K_gNB2*, PCI3, ARFCN3)
  而K_gNB2* = KDF(K_gNB1, PCI2, ARFCN2)
  K_gNB3*与K_gNB1通过可逆的KDF链连接（虽然HMAC本身不可逆，但密钥链是线性依赖的）

核心问题：水平推演中，K~gNB~*的密钥输入是前一个K~gNB~，攻击者获得一个节点后，由于HMAC的单向性虽不能回推，但若攻击者本身就是链上的gNB（被攻破的合法gNB），它在被攻破前持有的K~gNB~可以推演后续所有水平派生的密钥（因为它知道K~gNB~和目标PCI/ARFCN）。

缓解措施：3GPP的设计意图是通过Path Switch Request流程确保AMF在每次Xn切换完成后都补充新的{NH, NCC}对，使下次切换可以回到垂直推演。但在快速连续切换场景下（如高铁），NH补充可能跟不上切换速度。

6.3 实际网络中的安全等级

七、与LTE切换密钥机制的对比

5G相比LTE的主要增强点： 1. 更细粒度的AS密钥分离：K~gNB~不再直接用于加密，而是派生出4个独立子密钥 2. 256-bit算法支持：NEA3/NIA3（ZUC-256）等新算法 3. non-3GPP统一：通过K~AMF~统一3GPP和非3GPP接入的密钥体系

八、抓包识别与排错实战

8.1 抓包识别要点

Wireshark过滤：

# XnAP Handover Request
xnap.handoverRequest
# NGAP Handover Required/Request
ngap.procedureCode == 23   # HandoverResourceAllocation
# RRC Reconfiguration with reconfigurationWithSync
rrc.reconfigurationWithSync

关键IE提取路径：

8.2 常见故障点

故障1：NCC不匹配导致切换失败

现象：UE收到RRC Reconfiguration后发起RRC Reestablishment而非完成切换。 根因：UE本地NCC与网络下发的NCC不一致（如UE漏收了前一次切换命令）。 排查： 1. 检查源gNB日志中的ncc值 2. 对比UE侧维护的NCC（可通过UE log获取） 3. 检查AMF是否正确在Path Switch后补充了{NH, NCC}

故障2：连续Xn切换后密钥不同步

现象：多次快速Xn切换后，某次切换UE无法正确派生K~gNB~*。 根因：AMF提供的NH链已耗尽，源gNB回退到水平推演，但UE侧NH链状态与gNB不一致。 排查： 1. 统计连续Xn切换次数 2. 检查Path Switch Request Acknowledge是否携带了新{NH, NCC} 3. 检查AMF的NH预计算缓存是否充足

故障3：N2切换后AS安全激活失败

现象：UE在目标gNB发起Security Mode Control失败。 根因：AMF推演的K~gNB~*与UE推演的不一致（通常是因为K~AMF~状态不同步）。 排查： 1. 检查AMF是否使用了正确的K~AMF~（是否存在AMF变更场景） 2. 检查NH推演步数是否正确 3. 验证PCI和ARFCN-DL参数编码是否正确（字节序问题）

九、Release 18增强与演进方向

TS 33.501 V18.10.0在切换安全方面的主要增强：

1. Conditional Handover安全增强（Section 6.9.4）：CHO场景下预配置多个候选目标小区，每个候选小区预分配{K~gNB~*, NCC}，引入CHO-specific的密钥绑定参数防止密钥重用。

2. LPHO（Late Path Switch HO）安全：针对LPHO场景（数据转发延迟），增加了中间密钥状态的安保护，防止在Path Switch完成前密钥泄露。

3. 双连接安全增强：MN（Master Node）和SN（Secondary Node）的密钥分离进一步加强，SN Change时也支持NH链式推演。

4. AI/ML辅助切换的安全考量：R18引入的AI/ML辅助移动性决策对密钥预分配提出了新要求——预分配密钥的有效期和撤销机制。

常见问题

Q1: 为什么Xn切换有时走水平推演而非垂直推演？水平推演不是不安全吗？

A: 这是因为源gNB可能已耗尽AMF提供的NH。每次Xn切换的Path Switch后AMF只补充一个{NH, NCC}对。如果UE在AMF补充NH之前又发生了一次Xn切换，源gNB只能回退到水平推演。3GPP的设计是尽力提供前向安全而非强制前向安全——在快速移动场景下，信令延迟可能使NH补充跟不上切换速度。

Q2: UE如何知道走哪条推演路径？它又没有直接收到NH。

A: 关键在于NCC值。RRC Reconfiguration消息中携带ncc字段。UE比较收到的NCC与自己本地存储的NCC——如果收到的NCC大于本地NCC，说明网络使用了垂直推演（NCC增大意味着消耗了新的NH），UE就自行推演NH链（UE持有K~AMF~可以独立推演），然后用NH推演K~gNB~*。如果NCC没有增大，UE走水平推演。这个机制是5G安全设计的精妙之处。

Q3: NH链有没有长度限制？如果NH耗尽会怎样？

A: TS 33.501没有规定NH链的硬性上限。AMF可以无限推演NH[n+1] = KDF(K~AMF~, NH[n])。实际实现中，AMF通常预计算一批NH缓存备用。即使缓存耗尽，AMF可以在下次交互时即时计算。真正的问题不是NH耗尽，而是NH传递延迟——AMF计算好NH后，需要通过NGAP信令传递给gNB，这个传递可能跟不上快速切换的速度。

Q4: 5G的NH机制和LTE有什么本质区别？

A: 算法层面没有本质变化——NH推演函数、FC值、KDF输入参数结构基本一致。核心区别在于密钥层级更丰富：5G的K~gNB~不再直接用于加密/完整性保护，而是派生出K~RRCint~、K~RRCenc~、K~UPenc~、K~NRint~四个独立子密钥，提供了更细粒度的密钥分离。此外，5G支持256-bit算法（NEA3/NIA3），密钥空间更大。

Q5: 如果源gNB被完全攻破（攻击者获得K~gNB~和所有缓存的NH），安全性如何？

A: 攻击者可以推演出后续所有水平推演产生的K~gNB~（因为水平推演使用当前K~gNB~作为输入）。但攻击者无法*推演垂直推演产生的密钥，因为垂直推演使用NH作为输入，而攻击者只持有当前NCC对应的NH，无法从K~AMF~推演更高NCC的NH值（因为攻击者没有K~AMF~）。同时攻击者也无法回推历史密钥（HMAC单向性）。所以只要网络及时进行垂直推演刷新，攻击面是有限的。

参考来源

1. 3GPP TS 33.501 V18.10.0 — Section 6.9（切换安全处理）、Section 6.2（密钥层级）、Annex A.4（KDF定义）
2. TS 33.501 Section 6.9 — iTecSpec — 切换安全处理章节在线解读
3. A Comprehensive Formal Analysis of 5G Handover — ETH Zurich (WiSec 2021) — 5G切换协议的形式化安全验证
4. 5G Handover: When Forward Security Breaks — LiU (SECRYPT 2023) — Xn切换前向安全断裂分析
5. NH (Next Hop key) — 3GPP Explorer — NH密钥术语解释与历史沿革
6. 5G NR Key Derivation — sqimway — 5G密钥层级与KDF参数编码参考

本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。