# 5G主鉴权密钥层级推演机制拆解：从K到K_gNB的完整密钥衍生气 在5G系统中，一次成功的注册不仅是身份确认，更是一次从根密钥K出发、贯穿UDM→AUSF→AMF→gNB四层网元的**密钥瀑布式衍生**过程。3GPP在TS 33.501中定义的这套密钥层级（Key Hierarchy），用"锚点密钥逐级隔离、横向纵向交织更新"的设计，把长期密钥K永远锁在USIM与ARPF这两个安全边界之内，却又能让服务网络、接入网各自拿到独立的会话密钥。本文聚焦TS 33.501 Section 6.1.3（5G AKA流程）与Section 6.2（密钥层级与分发），逐信令、逐IE拆解密钥是如何一步步被"算出来"并"分下去"的。 --- ## 一、为什么5G要重做密钥架构：EPS-AKA的三大痛点 在拆解机制前，必须先理解设计意图。4G的EPS-AKA密钥体系（K→CK/IK→K_ASME→K_eNB→各层密钥）存在三个被学术界和3GPP SA3工作组反复诟病的缺陷，TS 33.501正是针对这些缺陷做了重构： | 痛点（EPS-AKA） | 后果 | 5G应对机制（TS 33.501） | |---|---|---| | IMSI明文空口传输，可被主动追踪 | 用户隐私泄露、IMSI Catcher攻击 | SUPI经ECIES加密为SUCI（§6.12），空口永不出现明文标识 | | 服务网络不参与鉴权向量运算，CK/IK直接下发 | 漫游场景下归属网络对SN信任过载 | 引入**K_AUSF**，且K_SEAF的衍生绑定**SNN（服务网络名）**，SN伪造身份即被切断 | | 鉴权失败仍可能泄露RES，存在链接性（linkability） | 攻击者可关联同一UE多次会话 | 5G引入**RES\*/XRES\***扩展响应，并要求UE侧同步刷新，失败即换SQN | 核心设计哲学一句话概括：**长期密钥K永不离开安全边界，每一次衍生都把"网络身份"和"序列号"作为输入绑进密钥材料**，让密钥既不可伪造也不可重放。 --- ## 二、5G AKA完整信令流：密钥在哪一步被算出来 5G AKA遵循挑战-响应（challenge-response）范式，但与4G的关键区别在于：**归属网络的鉴权向量被拆成两部分**——5G HE AV（归属环境向量，含XRES*、K_AUSF，留在AUSF）和5G SE AV（服务环境向量，含HXRES*、K_SEAF，下发到AMF/SEAF）。这种"双向量"结构正是为了让AMF可以**本地验证**UE，而不必每次回AUSF。 ```mermaid sequenceDiagram participant UE participant SEAF as SEAF/AMF participant AUSF participant UDM as UDM/ARPF UE->>SEAF: Registration Request (SUCI) SEAF->>AUSF: Nausf_UEAuthentication Auth (SUCI, SNN) AUSF->>UDM: Nudm_UEAuthentication Get (SUCI, SNN) Note over UDM: SIDF解密SUCI→SUPI
读取K,生成RAND/AUTN/RES Note over UDM: 计算XRES*=KDF(CK‖IK,FC=0x6B,SNN,RAND,RES)
计算K_AUSF=KDF(CK‖IK,FC=0x6A,SNN,SQN⊕AK) UDM-->>AUSF: 5G HE AV(RAND,AUTN,XRES*,K_AUSF) Note over AUSF: HXRES*=SHA256(RAND‖XRES*)取低128位
K_SEAF=KDF(K_AUSF,FC=0x6C,SNN,SUPI) AUSF-->>SEAF: 5G SE AV(RAND,AUTN,HXRES*,K_SEAF) SEAF->>UE: NAS Authentication Request(RAND,AUTN,ngKSI) Note over UE: USIM验MAC与SQN新鲜度
算RES*,算K_AUSF,K_SEAF UE->>SEAF: NAS Authentication Response(RES*) Note over SEAF: HRES*=SHA256(RAND‖RES*)低128位
本地比对 HRES* ?= HXRES* SEAF->>AUSF: Nausf_Confirm(RES*) Note over AUSF: 比对 RES* ?= XRES* AUSF-->>SEAF: Auth Success Note over SEAF,UE: 双向鉴权完成,各自推K_AMF Note over UE: K_AMF=KDF(K_SEAF,FC=0x6D,ABBA,SUPI) Note over SEAF: K_AMF=KDF(K_SEAF,FC=0x6D,ABBA,SUPI) SEAF->>UE: Security Mode Command ``` 逐步拆解每个消息中的关键IE： **① Registration Request（UE→AMF）** - 携带`SUCI`而非IMSI。SUCI是SUPI经ECIES（椭圆曲线集成加密方案）加密后的密文，scheme-output中包含临时公钥、密文、MAC。注意：如果UE尚无归属网络公钥，会退化为**null-scheme**（仅拼接+填充，不加密），这是工程中常见的"半保护"状态，抓包能看到SUCI但实际可被SIDF无密钥解出。 **② Nausf_UEAuthentication_Get（AUSF→UDM）** - 关键IE：`SUCI`、`Serving Network Name (SNN)`。SNN的格式严格规定为`5G:mnc.mcc.3gppnetwork.org`。**SNN会被绑入K_SEAF的推导**，这是防止服务网络伪造身份的核心——任何篡改SNN的中间人，都会导致AMF与UE算出的K_SEAF不同，后续SMC必然失败。 **③ UDM/ARPF生成鉴权向量** - USIM与ARPF共享长期密钥**K**，运行Milenage算法集（f1~f5）得到：MAC=f1(K,SQN,RAND,AMF)、AK=f5(K,RAND)、SQN⊕AK、CK=f3、IK=f4。 - AUTN的16字节结构为：`SQN⊕AK ‖ AMF ‖ MAC`。SQN的 freshness 是抗重放的关键。 **④ NAS Authentication Request（AMF→UE）** - IE：`RAND`（16字节随机挑战）、`AUTN`（16字节鉴权令牌）、`ngKSI`（密钥集标识，用于后续密钥索引）、`ABBA`（防降级参数）。 - `ngKSI`是5G特有的，取值0~6，用于在多次重鉴权时区分不同密钥集，避免混淆。 **⑤ UE侧验证与响应计算** - UE先校验`MAC`是否等于本地f1计算值，再校验`SQN`是否在有效窗口（防重放）。校验通过后： - 计算`RES=f2(K,RAND)`，再扩展为`RES*` - UE侧独立推导`K_AUSF`、`K_SEAF`，与网络侧使用**完全相同的KDF输入**，这是密钥协商的基础。 **⑥ SEAF本地验证 + AUSF终验** - SEAF计算`HRES*=SHA256(RAND‖RES*)`的低128位，与HXRES*比对。这一步**无需联系AUSF**即可判断UE是否持有正确密钥，大幅减少漫游回程信令。只有本地验证通过，才向AUSF发起确认，AUSF做最终的`RES* vs XRES*`严格比对。 --- ## 三、密钥层级架构：一棵从K长出的密钥树 TS 33.501 §6.2.1定义的密钥层级是一棵严格的树，每一层的衍生都遵循"父密钥+领域隔离参数→子密钥"的模式。 ```mermaid flowchart TD K["K（根密钥）
USIM ↔ ARPF"] CKIK["CK, IK
Milenage f3/f4"] KAUSF["K_AUSF
锚定于AUSF"] KSEAF["K_SEAF
服务网络锚点密钥"] KAMF["K_AMF
AMF锚点密钥"] KGNB["K_gNB
基站锚点密钥"] KNASenc["K_NASenc"] KNASint["K_NASint"] KRRCenc["K_RRCenc"] KRRCint["K_RRCint"] KUPenc["K_UPenc"] KUPint["K_UPint（仅N3IWF等）"] K --> CKIK CKIK -->|FC=0x6A| KAUSF KAUSF -->|FC=0x6C + SNN| KSEAF KSEAF -->|FC=0x6D + ABBA,SUPI| KAMF KAMF -->|FC=0x6E 算法区分| KNASenc KAMF -->|FC=0x6F 算法区分| KNASint KAMF -->|FC=0x70| KGNB KGNB -->|FC=0x69| KRRCenc KGNB -->|FC=0x6A-AS| KRRCint KGNB -->|FC=0x6B-AS| KUPenc KGNB --> KUPint classDef root fill:#ffe4b5,stroke:#333 classDef anchor fill:#87ceeb,stroke:#333 classDef leaf fill:#90ee90,stroke:#333 class K root class KAUSF,KSEAF,KAMF,KGNB anchor class KNASenc,KNASint,KRRCenc,KRRCint,KUPenc,KUPint leaf ``` **设计意图**：每一层密钥都对应一个**安全终结点（termination point）**。NAS层密钥（K_NAS*）终结在UE与AMF之间，gNB根本拿不到；AS层密钥（K_RRC*、K_UP*）终结在UE与gNB之间，AMF也不存储它们。这种"按终结点分层"的设计，使得即使某个gNB被攻破，攻击者也只拥有该gNB的K_gNB，无法反推K_AMF，更无法解密历史NAS信令——这就是TS 33.501反复强调的**密钥隔离（key separation）**原则。 --- ## 四、KDF推演机制：HMAC-SHA-256如何吃进参数 5G所有密钥衍生都使用同一个KDF（TS 33.220定义），底层是HMAC-SHA-256。其输入结构是定长的TLV式拼接： ```mermaid flowchart LR subgraph KDF输入 FC["FC
1字节函数码
标识衍生哪种密钥"] P0L0["P0 ‖ L0
参数0 + 2字节长度"] P1L1["P1 ‖ L1
参数1 + 2字节长度"] PN["... ‖ PN ‖ LN"] end KEY["父密钥
作为HMAC的Key"] OUT["KDF输出
256位
截断为所需长度"] FC --> S["HMAC-SHA256"] P0L0 --> S P1L1 --> S PN --> S KEY --> S S --> OUT ``` 具体公式：`KDF(Key, S) = HMAC-SHA-256(Key, S)`，其中`S = FC ‖ P0 ‖ L0 ‖ P1 ‖ L1 ‖ ... ‖ Pn ‖ Ln`，每个Li是该参数的字节长度（大端2字节）。 以K_AMF的衍生为例（TS 33.501 §6.2.2，Annex A.5）： | 参数 | 取值 | 说明 | |---|---|---| | Key | K_SEAF | 父密钥，256位 | | FC | 0x6D | K_AMF衍生函数码 | | P0 | ABBA | 防降级参数集 | | L0 | 0x0002 | ABBA长度 | | P1 | SUPI | 订阅永久标识，绑身份 | | L1 | SUPI字节长度 | — | **为什么要把SUPI绑进K_AMF？** 这是为了防止**密钥混淆攻击**：如果某个攻击者能让AMF误以为这是另一个SUPI的会话，由于SUPI是K_AMF的输入，推导出的密钥完全不同，攻击者无法复用旧密钥。ABBA参数则用于防止5G→4G的**降级攻击（bidding down attack）**——它编码了UE支持的安全特性集合，若被篡改导致降级，密钥推导会因ABBA不一致而失败。 各密钥的FC函数码速查（TS 33.501 Annex A.5）： | 子密钥 | FC | 关键输入参数 | 推导位置 | |---|---|---|---| | RES* / XRES* | 0x6B | CK‖IK, SNN, RAND, RES | UDM / UE | | K_AUSF | 0x6A | CK‖IK, SNN, SQN⊕AK | UDM/ARPF / UE | | K_SEAF | 0x6C | K_AUSF, SNN, SUPI | AUSF / UE | | K_AMF | 0x6D | K_SEAF, ABBA, SUPI | AMF / UE | | K_NASenc/int | 0x6E/0x6F | K_AMF, 算法区分符 | AMF / UE | | K_gNB | 0x70 | K_AMF | AMF→gNB | | K_RRCenc/int | 0x69/0x69 | K_gNB, 算法区分符 | gNB / UE | | K_UPenc | 0x6B-AS | K_gNB | gNB / UE | --- ## 五、接入网horizontal/vertical密钥推演：切换时的密钥更新 密钥层级树的静态部分讲完了，但UE是移动的——每次切换，gNB都可能换。如果每个新gNB都直接用K_AMF推K_gNB，那么所有gNB的K_gNB完全相同，密钥隔离形同虚设。TS 33.501 §6.9设计了**horizontal与vertical两种密钥推演模式**，用NH参数和NCC计数器实现"每切一次换一个密钥"。 ```mermaid flowchart TD KAMF0["K_AMF"] KGNB0["K_gNB(初始)
NCC=0"] NH1["NH1=KDF(K_AMF,K_gNB)
NCC=1"] NH2["NH2=KDF(K_AMF,NH1)
NCC=2"] KAMF0 --> KGNB0 KAMF0 --> NH1 NH1 --> NH2 KGNB0 -->|水平 H0| T1["K_gNB'=KDF(K_gNB,0x6E,PCI,ARFCN)
源gNB本地推,无需回AMF"] NH1 -->|垂直 V1| T2["K_gNB''=KDF(NH,0x6F,PCI,ARFCN)
AMF提供NH,前向安全更强"] classDef horiz fill:#ffb6c1,stroke:#333 classDef vert fill:#b0e0e6,stroke:#333 class T1 horiz class T2 vert ``` **水平推演（horizontal key derivation，FC=0x6E）**： - 新密钥`K_gNB' = KDF(K_gNB, 0x6E, target-cell-PCI, ARFCN-DL)`。 - 由**源gNB**在本地完成，无需回AMF。 - 优点：快，适合Xn切换的紧急场景。 - 缺点：新gNB的密钥仍可由源gNB推导出来，**前向安全性弱**——若源gNB被攻破，后续一串水平衍生的密钥全部暴露。 **垂直推演（vertical key derivation，FC=0x6F）**： - 新密钥`K_gNB'' = KDF(NH, 0x6F, target-cell-PCI, ARFCN-DL)`。 - NH（Next Hop）参数由AMF从K_AMF迭代推导：`NH_n = KDF(K_AMF, NH_{n-1})`。 - 优点：新gNB的密钥**无法**从源gNB的K_gNB反推，前向安全性强。即使源gNB被攻破，已用垂直推演切换到的新gNB密钥仍然安全。 - NCC（Next hop Chaining Counter）随每次推演递增，UE与网络据此同步使用哪一个NH。 工程权衡：默认优先垂直推演（前向安全），仅当AMF无法及时提供NH时退化为水平推演。这就是为什么切换命令（Handover Command）中会携带`NCC`和可能的`NH`参数。 --- ## 六、5G AKA vs EAP-AKA'：两种鉴权方式的密钥差异 5G支持两种主鉴权：5G AKA（TS 33.501 §6.1.3）和EAP-AKA'（§6.1.2）。后者用于非3GPP接入（如可信非3GPP接入、Wireline接入）。两者的密钥源头都是K，但衍生路径不同。 | 维度 | 5G AKA | EAP-AKA' | |---|---|---| | 适用接入 | 3GPP接入（NR/E-UTRA） | 非可信非3GPP接入 | | 鉴权向量 | 5G HE AV / 5G SE AV双向量 | EAP-AKA'向量，复用3G机制+MK重新计算 | | 响应值 | RES* / XRES*（256位扩展） | RES / EAP消息 | | 服务网络本地验证 | HRES*本地比对（有） | 无本地验证，依赖AUSF | | 锚点密钥 | K_SEAF | K_AUSF（EAP后转K_SEAF） | | SNN绑定 | 强制 | 强制（通过AT_RAND改写） | 5G AKA的"双向量+HRES*本地验证"是EAP-AKA'所没有的优化，这正是5G AKA为漫游场景量身定制的原因——漫游时服务网络要频繁鉴权，本地验证省去了大量到归属网络的回程。 --- ## 七、抓包识别与故障排错 ### 7.1 抓包识别要点 用Wireshark/TShark过滤5G-NAS协议，识别5G AKA流程： - **Authentication Request**：消息类型`0x56`（5G MM），IE含`RAND`（16字节）、`AUTN`（16字节）、`ngKSI`、`ABBA`。 - **Authentication Response**：消息类型`0x57`，IE含`RES*`。注意RES*比4G的RES长得多（最长256位），这是5G扩展响应的标志。 - **Security Mode Command**：消息类型`0x5C`，携带选定的加密/完整性算法（如NEA2/NEA3、NIA2）、`ngKSI`、`REPLAYED UE SECURITY CAPABILITY`。SMC的出现标志着K_AMF已就绪、NAS安全上下文激活。 ### 7.2 常见故障点 | 故障现象 | 根因 | 排错思路 | |---|---|---| | Authentication Reject | UE算出的MAC≠网络MAC，或SQN失步 | 检查USIM的K/OPc与HSS是否一致；查SQN是否需重同步 | | SQN失步（#MAC失败但SQN不对） | USIM本地SQN与HSS严重不同步 | UE发起**Re-synchronization**，用AUTS携带，UDM调整SQN | | Security Mode Reject | K_AMF两侧不一致，SMC完整性校验失败 | 抓包核对SNN、ABBA、SUPI三参数是否被中间设备篡改 | | 切换后业务中断 | NCC失步，UE与gNB用的NH不对 | 检查Handover Command中的NCC/NH，确认水平/垂直推演模式一致 | **SQN重同步**是高频故障：当UE认为收到的SQN"太旧或超出窗口"，会拒绝鉴权并回`Authentication Failure`（cause=Synch failure），携带`AUTS`字段。UDM据此用特殊算法反推正确的SQN值，重新生成向量。这是5G AKA继承自3G/4G的经典机制。 ## 八、常见问题 **Q1：K_AUSF和K_SEAF都是"锚点密钥"，为什么要分两层？** A：K_AUSF锚定在**归属网络**（AUSF），绑定SQN⊕AK，与具体服务网络无关；K_SEAF锚定在**服务网络**（SEAF/AMF），绑定SNN。分两层是为了让归属网络和服务网络各持一段不可由对方反推的密钥材料——服务网络无法冒用归属网络身份，归属网络也不直接持有服务网络会话密钥。这把信任边界切得很干净。 **Q2：为什么5G要在RES基础上扩展成RES\*？** A：4G的RES长度仅64位，存在被暴力枚举和关联分析的风险，且响应值本身可被攻击者用于链接同一UE的多次会话（linkability）。RES\*用KDF把RES扩展到最长256位并混入RAND、SNN，既增加熵又破坏可链接性。HXRES\*/HRES\*则是RES\*的SHA-256哈希，让SEAF能在不持有K_AUSF的前提下本地验证UE。 **Q3：水平推演不安全，为什么还要保留？** A：水平推演由源gNB本地完成，**零回程信令、零额外时延**，在Xn切换的紧急移动场景下是唯一能满足时延要求的方式。垂直推演虽前向安全，但需要AMF提供NH，增加一次N2交互。标准让二者并存，由切换场景的时延敏感度决定取舍——这正是协议设计的工程现实感。 **Q4：K_AMF推K_gNB用的是FC=0x70，但K_gNB推K_RRC用的是0x69，会不会与K_AUSF的0x6A冲突？** A：不会。每个KDF的**输入密钥（Key）不同**——K_AUSF衍生时Key是CK‖IK，K_RRC衍生时Key是K_gNB。HMAC的输出依赖Key，即使FC相同，只要Key不同，输出就完全无关。不过为可读性，标准尽量让不同语义的衍生用不同FC。 **Q5：USIM能存K_AMF吗？换卡换机后如何恢复安全上下文？** A：可以。TS 33.501 §6.2.3规定，若USIM支持5G参数存储，K_AMF应存在USIM中；否则存在ME的非易失性存储器。换机时若USIM存了K_AMF，新ME可恢复安全上下文（安全上下文可携带）；若存在旧ME且ME未正确清除，存在残留密钥风险，这是设备回收时需注意的安全点。 --- ## 参考来源 1. [3GPP TS 33.501 V18.10.0](https://www.etsi.org/deliver/etsi_ts/133500_133599/133501/18.10.00_60/ts_133501v181000p.pdf) — Security architecture and procedures for 5G system，§6.1.3（5G AKA流程）、§6.2（密钥层级与分发）、Annex A.5（KDF函数码） 2. [3GPP TS 33.220](https://www.3gpp.org/dynareport/33220.htm) — Generic Authentication Architecture (GAA)，Generic Key Derivation Function (HMAC-SHA-256 KDF) 的算法定义 3. [Introduction to 5G AKA — free5GC](https://free5gc.org/blog/20251029/20251029/) — 含free5GC开源实现中XRES\*、HXRES\*衍生的真实Go代码，可作为协议落地的工程参考 4. [5G NR Key Derivation Procedure — 3GLTEInfo](https://www.3glteinfo.com/call-flows/5g-key-derivation-procedure/) — 5G密钥层级树与各层密钥用途的图文讲解 5. [ShareTechnote — 5G Core Authentication & Security](https://www.sharetechnote.com/html/5G/5G_Security.html) — 5G AKA与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 等场景全覆盖。