要理解5G的密钥层级，必须先理解4G时代遗留的结构性缺陷。EPS（4G）的密钥体系以K_eNB为核心：MME从K_ASME推导出K_eNB下发给基站，切换时通过"Next Hop（NH）"参数做密钥链式更新。这套设计有两个广受批评的问题：
3GPP在TS 33.501《Security architecture and procedures for 5G System》第6章中给出的答案是：一个七级密钥派生树 + 全程绑定身份/算法/计数器的KDF输入设计 + NH/NCC双轨密钥更新机制。本文聚焦其中最核心的三段机制：锚点密钥推导（K_AUSF→K_SEAF→K_AMF）、接入密钥分裂（K_gNB与K_NAS系列）、以及切换时最容易被误解的水平/垂直密钥推导（Section 6.9）。
TS 33.501 Figure 6.1.1-1定义了完整的密钥层级。用一张图梳理每级密钥的锚点、存放位置与用途：
flowchart TB
K["K（USIM与UDM/ARPF共享的永久根密钥）"]
CKIK["CK / IK（AKA认证向量输出）"]
KAUSF["K_AUSF<br/>锚定认证结果 · 存于AUSF"]
KSEAF["K_SEAF<br/>锚定服务网络 · 存于SEAF（与AMF合设）"]
KAMF["K_AMF<br/>锚定UE-AMF安全上下文 · 存于AMF与UE"]
KGNB["K_gNB<br/>基站级密钥 · AMF下发"]
KRR["K_RRC_int / K_RRC_enc<br/>RRC完整性/加密"]
KUP["K_UPint / K_UPenc<br/>用户面完整性/加密"]
KNAS["K_NAS_int / K_NAS_enc<br/>NAS层完整性/加密"]
K -->|"AKA运行（5G-AKA或EAP-AKA'）"| CKIK
CKIK -->|"KDF(FC=0x6A, '5G-AKA')<br/>或 EAP-AKA'的EMSK"| KAUSF
KAUSF -->|"KDF(FC=0x6C, SUPI)"| KSEAF
KSEAF -->|"KDF(FC=0x6D, SUPI/SUCI, ABBA)"| KAMF
KAMF -->|"KDF(FC=0x69, 算法标识)"| KNAS
KAMF -->|"垂直: KDF(FC=0x6E, UL NAS COUNT)<br/>水平: K_gNB = KDF(K_gNB旧, PCI, NCC)"| KGNB
KGNB --> KRR
KGNB --> KUP
这张树有几个关键设计约束，每一条都对应一个具体的安全目标：
| 设计约束 | 具体体现 | 安全目标 |
|---|---|---|
| 逐级单向派生 | 上级密钥推导下级密钥后可删除上级 | 中间人攻破一级不殃及上级域 |
| 身份绑定 | K_AMF推导输入含SUPI（或SUCI） | 密钥不可跨用户移植 |
| 网络绑定 | K_SEAF推导输入含服务网络标识（SN ID） | 防跨网络重放（EAP-AKA'的本质改进） |
| 算法绑定 | K_NAS/K_RRC推导输入含算法标识（NIA/NEA编号） | 算法协商结果进入密钥，防降级 |
| 计数器绑定 | K_gNB垂直推导输入含Uplink NAS COUNT | 同一安全上下文内永不重用相同密钥输入 |
5G所有密钥推导共用TS 33.203附录定义、并在TS 33.501 Annex A中实例化的同一套KDF：本质是HMAC-SHA-256，输入为 KDF(锚点密钥, FC, P0, L0, P1, L1, ...)，其中FC（Function Characteristic）是1字节的功能区分码，P是变长参数。各段推导的输入参数如下表（FC取值以TS 33.501 Annex A现行版本为准，此处为Rel-17及以后各版本通行的分配）：
| 密钥 | 锚点密钥 | FC | P0 / P1（关键输入） | 推导位置 |
|---|---|---|---|---|
| K_AUSF（5G-AKA） | CK ‖ IK | 0x6A | P0 = "5G-AKA"（6字节ASCII） | AUSF、UE |
| K_AUSF（EAP-AKA'） | EMSK | — | 直接取EAP-AKA'主会话密钥EMSK，无需KDF | AUSF、UE |
| K_SEAF | K_AUSF | 0x6C | P0 = SUPI | AUSF→SEAF传递 |
| K_AMF | K_SEAF | 0x6D | P0 = SUPI或SUCI，P1 = ABBA（2字节） | SEAF、UE |
| K_NAS_int / K_NAS_enc | K_AMF | 0x69 | P0 = 算法标识（NIA1/NIA2/NIA3或NEA0~NEA3的4字节编码），P1 = 密钥用途区分 | AMF、UE |
| K_gNB（垂直，初始/AMF内迁移） | K_AMF | 0x6E | P0 = Uplink NAS COUNT | AMF、UE |
| NH（首次） | K_AMF | 0x6F | P0 = K_AMF派生输入 | AMF |
| NH（后续） | K_AMF | 0x6F | P0 = 上一次NH | AMF |
| K_gNB*（水平推导中间值） | K_gNB（旧） | — | P0 = PCI，P1 = 目标NCC | gNB、UE |
| K_RRC_int / K_RRC_enc | K_gNB | 0x70 | P0 = 算法标识 | gNB、UE |
| K_UPint / K_UPenc | K_gNB | 0x71 | P0 = 算法标识，P1 = UP安全策略区分 | gNB、UE |
为什么必须逐级携带这么多参数？ 这是5G相对4G最本质的改进——每一级推导都把“这条密钥为谁、在哪、用什么算法、第几次使用”写进了HMAC输入。任何一项变化都会产生完全不同的密钥，因此攻击者无法把一个网络里截获的密钥材料搬到另一个上下文中使用（这是形式化分析结论，Basin等人在CCS 2018对5G-AKA的符号化验证支持这类不可链接性结论）。
K_AMF推导中的ABBA参数是初学者最容易忽略却最能体现设计功力的IE。它长2字节：第一字节是NAS下行/上行安全算法集的编码，第二字节是其按位取反（例如0x02 0xFD表示NEA2/NIA2这套算法组合）。取反校验的目的是让AMF和UE能快速识别被篡改或实现错误导致的非法取值。
它的安全意义在于：UE记录安全激活发生时刻的算法集，此后任何一次K_AMF重推导（如mobility registration update）时，双方都把“上次激活的算法集”喂进KDF。如果中间存在攻击者把NGAP信令中的算法列表改弱（迫使UE和AMF选用80位安全强度的NEA1而非128位的NEA2），两侧算出的K_AMF就对不上，安全激活必然失败——降级攻击被转化为可检测的密钥不一致。这就是TS 33.501 Section 6.1.2.3所描述的"the ABBA parameter... protects against bidding down attacks"。
把密钥层级映射到TS 23.502 Section 4.2.2.2.2定义的Primary Authentication流程（消息编号沿用该节），可以看到每级密钥“诞生”的精确时刻：
sequenceDiagram
participant UE as UE/USIM
participant AMF as AMF(SEAF)
participant AUSF as AUSF
participant UDM as UDM/ARPF
Note over UE,UDM: 各方预置：K（USIM/ARPF）
AMF->>AUSF: ① Nausf_UEAuthentication_Authenticate<br/>(SUCI, SN Name)
AUSF->>UDM: ② Nudm_UEAuthentication_Get<br/>(SUCI, SN Name)
UDM->>UDM: ③ SIDF解出SUPI，生成RAND/AUTN/XRES*<br/>K_AUSF = KDF(CK||IK, 0x6A, "5G-AKA")
UDM-->>AUSF: ④ 5G HE AV (RAND, AUTN, HXRES*, K_AUSF)<br/>注意：XRES*与CK/IK不出UDM
AUSF->>AUSF: ⑤ 由XRES*算HXRES*，暂存K_AUSF<br/>删除XRES*
AUSF-->>AMF: ⑥ 5G SE AV (RAND, AUTN, HXRES*)
AMF-->>UE: ⑦ Authentication Request<br/>(ngKSI, ABBA, RAND, AUTN)
Note over UE: ⑧ USIM验证AUTN，产出CK/IK/RES*<br/>K_AUSF→K_SEAF→K_AMF本地全推导
UE-->>AMF: ⑨ Authentication Response (RES*)
AMF->>AUSF: ⑩ Nausf确认 (RES*)
AUSF-->>AMF: ⑪ 校验RES*==XRES*，返回K_SEAF
AMF->>AMF: ⑫ K_SEAF + SUPI + ABBA → K_AMF<br/>生成ngKSI标记安全上下文
Note over UE,AMF: 此后NAS SMC（Security Mode Complete）<br/>激活K_NAS_int/enc，密钥链路闭合
三个值得协议工程师注意的细节：
这是本文的重点，也是现网切换掉话、安全模式失败排查中高频出错的一段。TS 33.501 Section 6.9定义了两种K_gNB获取方式：
KDF(K_AMF, 0x6E, Uplink NAS COUNT) 全新推导K_gNB，通过NGAP HANDOVER REQUEST（或INITIAL CONTEXT SETUP REQUEST）发给目标gNB。因为输入包含UE当前的上行NAS COUNT，每一次推导的输入都不同，从数学上排除了密钥重用。K_gNB* = KDF(K_gNB_old, PCI_target, NCC)，直接经XnAP HANDOVER REQUEST发给目标gNB，AMF全程不参与。目标gNB收到后需将K_gNB*与NH做一次合成运算得到最终K_gNB。NH（Next Hop）参数本身永不出现在UE和gNB之间，双方只同步一个3比特的计数器NCC（Next Hop Chaining Counter）。规则如下：
stateDiagram-v2
[*] --> NCC0: 初始AS安全激活<br/>AMF垂直推导K_gNB, NCC=0<br/>同时预推NH(1), NCC=1
NCC0 --> NCC1: Xn切换且源gNB有NH(1)<br/>水平推导K_gNB*, NCC=1
NCC0 --> Vertical1: N2切换或NH缺失<br/>AMF垂直推导, NCC=1
Vertical1 --> NCC1: 路径收敛
NCC1 --> NCC2: Xn切换用NH(2)水平推导<br/>或N2切换垂直推导
NCC2 --> NCC7: NCC逐次+1
NCC7 --> NCC1: NCC=7后回绕到1<br/>触发AMF重跑认证上下文刷新
切换执行时，目标侧gNB通过HANDOVER COMMAND把新NCC带给UE；UE对比自己缓存的NCC与收到的NCC：
| UE缓存的NCC | 收到的NCC | UE行为 |
|---|---|---|
| = n | = n+1 | 有对应NH缓存（水平推导过），用K_gNB*路径合成新K_gNB |
| = n | > n+1 | 中间跳数过多（NH链断了），UE执行垂直推导：用K_AMF + UL NAS COUNT重新算K_gNB |
| = n | < n | 异常：NCC回退，视为网络错误，切换后NAS完整性校验必然失败 |
完整的Xn切换密钥流转时序如下：
sequenceDiagram
participant SgNB as 源gNB
participant TgNB as 目标gNB
participant AMF as AMF
participant UE as UE
Note over SgNB: 持有K_gNB(n-1), NH(n), NCC=n
SgNB->>TgNB: ① XnAP HANDOVER REQUEST<br/>K_gNB* = KDF(K_gNB(n-1), PCI_T, NCC=n)<br/>+ 新NCC=n
TgNB->>TgNB: ② 合成 K_gNB(n) = K_gNB* ⊕-style合成 NH(n)<br/>（33.501定义的KDF合成，非异或）
TgNB-->>SgNB: ③ XnAP HANDOVER REQUEST ACK
SgNB->>UE: ④ RRCReconfiguration<br/>(handoverCommand, 新NCC=n)
Note over UE: ⑤ UE比对NCC：缓存n-1，收到n → 可水平推导<br/>K_gNB* = KDF(K_gNB(n-1), PCI_T, NCC=n)<br/>UE同样合成NH得到K_gNB(n)
UE->>TgNB: ⑥ RRCReconfigurationComplete<br/>（用新K_RRC_int保护）
Note over UE,TgNB: 新AS安全上下文激活完毕<br/>AMF不知晓本次推导（Xn路径）
设计意图：Xn切换把密钥更新时延压到gNB之间（AMF不参与，省掉NGAP往返），但代价是AMF的K_AMF与现役K_gNB“脱节”——AMF必须把NH链预先生成好（每完成一次AS安全或N2切换，AMF就预推下一级NH），才能保证gNB随时有NH可用。NCC回绕到7之后系统强制回到垂直推导并由NAS层刷新安全上下文，防止无限链式推导导致的密钥材料代际模糊。
垂直推导K_gNB的输入是Uplink NAS COUNT，这个计数器有24位超帧号（overflow）+ 8位（TS 24.501 Section 9.2.3.1，实际构成5G NAS COUNT的32位逻辑空间）。UE每次上行NAS消息+1，AMF侧严格跟踪。如果UE上行消息丢失导致两侧COUNT失步，AMF会在下一次安全激活时发现推导不出一致密钥——这反过来成为检测NAS重放攻击的机制：攻击者重放旧的上行NAS消息，其加密/完整性标签对应的COUNT早已被网络“用过”，校验必败。
这也是为什么现网把NAS COUNT失步列为高危故障：它不仅影响认证推导，还会直接导致后续所有AS/NAS完整性校验连锁失败，UE只能重新注册。
Authentication Request（PDU会话无关，protocol discriminator = mobility management, message type 0x56）中的ngKSI和ABBA字段是密钥推导起点；紧随其后的Security Mode Command（0x5D）里的算法IE（NEA/NIA各4比特）决定K_NAS推导输入。InitialContextSetupRequest或HandoverRequest中的SecurityKey IE就是K_gNB本体（永远只有gNB级密钥，K_AMF绝不出AMF），伴随的NextHopChainingCounter IE即NCC。HANDOVER REQUEST中的Security Information IE含K_gNB*与NCC。抓到Xn切换却看不到AMF参与，属正常现象。| 现象 | 根因定位方向 | 判据 |
|---|---|---|
| 切换后上行数据静默丢失、RRC重配完成不达 | 目标gNB未正确合成NH | 对比XnAP HANDOVER REQUEST中的NCC与源gNB本地NH链状态 |
| UE频繁发起re-registration，伴随integrity check fail | NAS COUNT失步 | 抓NAS计数：UE侧上行COUNT vs AMF记录值；常见于测试USIM未实现overflow |
| Security Mode Command后UE不回Complete | ABBA非法值（高字节≠低字节取反） | 解码ABBA两字节，校验反码关系 |
| N2切换后UE侧密钥错误 | AMF垂直推导输入的UL NAS COUNT取值错误 | 检查AMF日志中推导时刻的COUNT与UE实际已发计数是否一致 |
| NCC回退导致切换后必败 | 多AMF/多gNB间安全上下文同步缺陷 | 检查跨AMF N2切换（HANDOVER REQUIRED→HANDOVER COMMAND）中NCC IE的传递链 |
| ## 常见问题 |
Q: K_SEAF和K_AMF为什么不合并成一个密钥？ A: 因为两者锚定的信任域不同。K_SEAF由归属域AUSF下发，代表“服务网络被授权使用该用户的认证结果”；K_AMF则进一步绑定UE身份（SUPI/SUCI）和ABBA算法集，属于特定UE-AMF对的安全上下文锚点。合并意味着AMF更换（如AMF change场景）时必须重新联系AUSF取密钥，而分离设计允许SEAF在不同AMF间（经K_AMF重推导）完成上下文迁移，减少归属域信令。
Q: 水平推导和垂直推导的本质区别是什么？ A: 区别在于锚点密钥和触发路径：垂直推导以K_AMF为锚、由AMF执行、输入含UL NAS COUNT，用于初始激活和N2切换；水平推导以旧K_gNB为锚、由gNB执行、输入含目标PCI和新NCC，用于Xn切换。垂直推导安全代际更清晰但需要AMF参与，水平推导零核心网信令但每次链式推导都会累积对旧密钥的依赖。
Q: UE怎么知道自己该用水平还是垂直推导？ A: UE不需要“知道”路径——它只对比切换命令中的NCC与本地缓存：NCC恰好+1且本地存有对应NH派生材料时走水平，NCC跳变时退回垂直推导（用K_AMF+UL NAS COUNT现算）。两条路径算出的K_gNB必然一致，因为AMF预推的NH与gNB水平推导的中间量在数学上设计为可合成出同一结果。
Q: 为什么认证后还要做Security Mode Command，不能在Authentication里直接激活NAS安全吗？ A: 认证流程只建立了密钥材料（K_AMF），但算法协商需要AMF根据UE能力和网络策略另行决定，且NAS SMC消息本身要受完整性保护——这是一个“用密钥确认密钥”的自校验闭环：UE若未推导出正确的K_NAS_int，就无法通过SMC的MAC校验，激活自然失败。把两件事分开才能让认证失败和算法协商失败产生不同的错误码。
Q: 5G-AKA和EAP-AKA'的K_AUSF来源不同，会影响后面的密钥层级吗？ A: 不会。两者的分叉点仅在K_AUSF：5G-AKA用KDF(CK‖IK, FC=0x6A, "5G-AKA")推导，EAP-AKA'直接取EAP主会话密钥EMSK作为K_AUSF。从K_SEAF开始的整棵密钥树完全相同，运营商可按归属域策略（是否要求服务网络标识绑定的EAP-AKA'）任选，接入侧无感知。
本文由「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 等场景全覆盖。