# 5G AKA 主认证机制全链拆解：从 SUCI 到密钥层级归属网络确认 ## 一、为什么 5G 必须重新设计 AKA 在 4G EPS-AKA 中，归属网络（Home Network, HN）只负责生成鉴权向量（Authentication Vector, AV）并把 `XRES` 下发给服务网络（Serving Network, SN）的 MME，最终 `RES == XRES` 的比对完全发生在 MME 内。这意味着归属网络在挑战-响应之后**完全退出认证流程**——一个被攻陷或恶意的服务网络只要拿到一次 AV，就可以反复欺骗 UE（这被称为 " malicious SN " 的 IMSI-catching 与 false base station 攻击的根源）。 3GPP TS 33.501 在 5G 时代引入 **5G AKA**（Clause 6.1.3），其灵魂改动有三点： 1. **归属网络最终确认**（Home Network Confirmation）：UE 回送的不再是明文 `RES`，而是经过 KDF 加固的 `RES*`；AUSF 必须参与最终比对，服务网络拿到的只是哈希 `HXRES*`。 2. **服务网络名绑定**：密钥派生链每一级都把 Serving Network Name（SN Name）作为输入，实现"这张卡只能在这个 SN 下用"的密钥隔离，杜绝跨服务网络重放。 3. **SUPI 永不上空口**：UE 永远只发送 SUCI（基于 ECIES 加密），仅归属网络的 SIDF 能解 conceal。 本文聚焦 TS 33.501 Clause 6.1.3 / Annex A.2/A.5/A.7 的 5G AKA 完整信令链、`RES*`/`XRES*` 构造、双确认（HXRES* 与 XRES*）机制、密钥层级推演，以及 NAS 层抓包识别与故障排错。 ## 二、参与的网元功能与职责划分 5G 把鉴权职责在归属域与服务域之间做了**功能正交**的拆分，这是理解整条信令链的基础： | 网元/功能 | 所属域 | 核心职责 | 规范出处 | |-----------|--------|----------|----------| | **USIM/ME** | 终端 | 持有长期密钥 K；校验 AUTN；计算 RES*；本地保存 K_AUSF | TS 33.102, TS 31.102 | | **SEAF**（嵌入 AMF） | 服务域 | 触发鉴权；用 HXRES* 做本地预确认；向 AUSF 转发 RES* | TS 33.501 §6.1.1 | | **AUSF** | 归属域 | 用 XRES* 做归属网络最终确认；派生 K_AUSF；提供 K_SEAF 给 SEAF | TS 33.501 §6.1.3, TS 29.509 | | **UDM** | 归属域 | 持有签约数据；选择鉴权方法；调用 ARPF | TS 29.503 | | **ARPF** | 归属域 | 持有长期密钥 K；运行 f1–f5*；生成 SQN、RAND、AUTN、XRES*、CK'、IK' | TS 33.501 §6.1.2 | | **SIDF**（UDM 内） | 归属域 | 用 HN 私钥对 SUCI 解 conceal 还原 SUPI | TS 33.501 §C.3, TS 29.503 | ```mermaid flowchart LR subgraph 终端["UE (USIM+ME)"] U["长期密钥 K
HN公钥"] end subgraph 服务域["Serving Network (拜访)"] S["SEAF / AMF
触发+HXRES*预确认"] end subgraph 归属域["Home Network (归属)"] A["AUSF
XRES*最终确认
派生K_AUSF"] D["UDM
选方法/路由"] R["ARPF
f1~f5*生成AV"] I["SIDF
SUCI→SUPI"] end U -- "SUCI / RES*" --> S S -- "RAND,AUTN" --> U S -- "RES*" --> A A -- "HXRES*, RAND, AUTN" --> S A -- "K_SEAF" --> S A --> D --> R I -. "解conceal" .- D ``` 关键设计意图：**ARPF 与 AUSF 是物理可分离的**。ARPF 是密钥保险箱（永远不出 K），AUSF 是"鉴权代理"，对外通过 SBI（`Nausf_UEAuthentication`）暴露鉴权服务。这种拆分让 K 的暴露面被压到最小，符合零信任原则。 ## 三、完整信令时序：以注册触发的 5G AKA 为例 5G AKA 不是一条独立信令，而是**嵌在 Registration 流程内部**（TS 23.502 §4.2.2.2）。AMF 在收到 Registration Request 且当前没有可用的安全上下文时，会发起鉴权。下图给出从 SUCI 上行到 K_SEAF 下发的完整链路： ```mermaid sequenceDiagram autonumber participant UE as UE (USIM/ME) participant AMF as SEAF/AMF participant AUSF as AUSF (HN) participant UDM as UDM/SIDF/ARPF (HN) Note over UE: USIM 用 HN 公钥以 ECIES 加密 SUPI → SUCI UE->>AMF: Registration Request (SUCI, Requested NSSAI) Note over AMF: 无有效安全上下文 → 触发主认证 AMF->>AUSF: Nausf_UEAuthentication Authenticate
(SUCI, SN Name "5G:mnc.mcc.3gppnetwork.org") AUSF->>UDM: Nudm_UEAuthentication Get
(SUCI, SN Name, methodName?) Note over UDM: SIDF 用 HN 私钥解 conceal: SUCI→SUPI Note over UDM: ARPF 生成 RAND, 计算
SQN, AUTN=f1(K), XRES*=f2..f5*
CK'=f3, IK'=f4, AK=f5 UDM->>AUSF: AV(RAND, AUTN, XRES*, KAUSF)
(KAUSF 由 CK'||IK' 派生) Note over AUSF: 计算 HXRES*=SHA256(RAND||XRES*)[256] AUSF->>AMF: Nausf 响应
(RAND, AUTN, HXRES*, 5G-AKA 标记) AMF->>UE: NAS Authentication Request
(RAND, AUTN, ngKSI) Note over UE: 校验 AUTN(MAC=f1)
查 separation bit=1 → 5G AKA
校验 SQN 新鲜 Note over UE: RES=f2(K,RAND)
RES*=KDF_FC0x6B(RES, SN Name, RAND) UE->>AMF: NAS Authentication Response (RES*) Note over AMF: 本地预确认:
HRES*=SHA256(RAND||RES*)[256]
比对 HRES* ?= HXRES* AMF->>AUSF: Nausf Authenticate Confirm (RES*) Note over AUSF: 归属网络最终确认:
比对 RES* ?= XRES* Note over AUSF: 成功 → 派生 K_SEAF
K_SEAF=KDF_FC0x6C(KAUSF, SN Name) AUSF->>AMF: 响应 (AuthResult=SUCCESS, K_SEAF) Note over AMF: K_AMF=KDF_FC0x6E(K_SEAF, SUPI, ABBA) AMF->>UE: NAS Security Mode Command
(selected algo, ngKSI, replayed UE sec cap) UE->>AMF: NAS Security Mode Complete (完整性保护) ``` 逐步解析关键 IE（信息元素）： - **第 1 步 SUCI**：结构为 `SUPI 类型(4bit) + 归属网ID + 路由指示 + 保护方案ID + 公钥ID + 方案输出`。空口上 SUPI 永不出现，这是 5G 相对 4G 的硬性隐私提升。 - **第 3 步 SN Name**：这是整条密钥链的"锚点"，AMF 必须按 TS 23.003 格式（`5G:mncXXX.mccYYY.3gppnetwork.org`）构造，USIM 侧用同一字符串算 RES*，两侧不一致必导致鉴权失败。 - **第 6 步 AV**：UDM 返回的 AV 里**包含 XRES\***（注意：在 5G AKA 中 AUSF 持有 XRES*；在 EAP-AKA' 中则封装为 EAP 消息）。 - **第 7 步 HXRES\***：AUSF 只给 AMF **哈希值**——这就是"归属网络控制"的精髓：AMF 永远拿不到完整的 XRES*，无法伪造 UE 回应。 - **第 9 步 separation bit**：AUTN 内 AMF 字段的某一位为 `1`，USIM 据此判定走 5G AKA（启用归属网络确认），否则按 EPS 行为处理。 - **第 11 步 ngKSI**：5G 密钥集标识符，标识本次建立的安全上下文，后续 NAS SMC 与 AS 安全都引用它。 ## 四、RES\* / XRES\* / HRES\* 的密码学构造（TS 33.501 Annex A.5） 这是 5G AKA 与 EPS-AKA 差别最大、也最容易踩坑的部分。三层响应值的关系如下： ```mermaid flowchart TD R["RAND (128bit, ARPF随机)"] --> F2["f2(K, RAND)"] K["长期密钥 K (USIM+ARPF)"] --> F2 F2 --> RES["RES (64~256bit)"] RES --> KDF1["KDF, FC=0x6B
Key=RES
P0=SN Name, P1=RAND"] SN["Serving Network Name"] --> KDF1 R --> KDF1 KDF1 --> RESs["RES* (256bit, UE侧)"] KDF1x["KDF FC=0x6B
Key=XRES"] --> XRESs["XRES* (256bit, ARPF侧)"] RESs --> H1["SHA256(RAND‖RES*)[256]"] XRESs --> H2["SHA256(RAND‖XRES*)[256]"] H1 --> CMP1{"SEAF 本地预确认
HRES* ?= HXRES*"} H2 --> CMP1 RESs --> CMP2{"AUSF 归属确认
RES* ?= XRES*"} XRESs --> CMP2 ``` 设计意图解读： 1. **为什么 RES\* 要把 SN Name 塞进 KDF？**——为了绑定服务网络。即便攻击者截获某 SN 下的 `RES*`，换一个 SN Name 重放也会因为 KDF 输入不同而失效，这是对 false base station 跨域重放的根本防御。 2. **为什么要 HXRES\* 这一层哈希？**——让 AMF 能在"等 AUSF 回包"之前**先做一次本地快速校验**，快速剔除明显错误的回应（如终端实现 bug 导致 RES* 计算错误），同时不让 AMF 触碰真实 XRES*。 3. **为什么 AUSF 还要再比一次 XRES\*？**——因为 HXRES* 是 SHA-256 单向的，AMF 拿到 HXRES* 也无法反推 XRES*，所以**最终判定权必须留在归属网络**。一个恶意 AMF 即使伪造了 HRES* 比对，也无法通过 AUSF 的 XRES* 比对，UE 因此得到真正的归属网络背书。这就是 TS 33.501 反复强调的 "home network control of authentication confirmation"。 ## 五、密钥层级推演：从 K 到 K_gNB 的完整派生树 主认证成功的唯一产物是 `K_AUSF`，其后所有密钥都由它逐级派生（TS 33.501 §6.2, Annex A.2/A.6/A.7）： | 派生密钥 | 派生自 | FC 值 | 关键输入 | 持有者 | 用途 | |----------|--------|-------|----------|--------|------| | **K_AUSF** | CK'‖IK' | — (ARPF 内) | SQN⊕AK, SN Name | UE, AUSF | 鉴权锚定密钥 | | **K_SEAF** | K_AUSF | 0x6C | SN Name | UE, SEAF | 服务域锚点 | | **K_AMF** | K_SEAF | 0x6E | SUPI, ABBA | UE, AMF | NAS 根密钥 | | **K_NAS_int** | K_AMF | 0x69 | NAS 完整性算法 | UE, AMF | NAS 信令完整性 | | **K_NAS_enc** | K_AMF | 0x68 | NAS 加密算法 | UE, AMF | NAS 信令加密 | | **K_gNB** | K_AMF | 0x6E | (切换时更新) | UE, gNB | AS 域根密钥 | | **K_RRC_int / enc** | K_gNB | 0x69/0x6E | AS 算法 | UE, gNB | RRC 完整性/加密 | | **UP_int / enc** | K_gNB | 0x6F/0x66 | AS 算法 | UE, gNB | 用户面保护 | ```mermaid flowchart TD K["K (USIM/ARPF 长期密钥, 128/256bit)"] --> CKIK["CK', IK' (f3,f4)"] CKIK --> KAUSF["K_AUSF = KDF(CK'‖IK')
FC=0x6A, P0=SQN⊕AK, P1=SN Name"] KAUSF --> KSEAF["K_SEAF = KDF(K_AUSF)
FC=0x6C, P0=SN Name"] KSEAF --> KAMF["K_AMF = KDF(K_SEAF)
FC=0x6E, P0=SUPI, P1=ABBA"] KAMF --> KNASi["K_NAS_int"] KAMF --> KNASe["K_NAS_enc"] KAMF --> KGNB["K_gNB"] KGNB --> KRRCi["K_RRC_int"] KGNB --> KRRCe["K_RRC_enc"] KGNB --> KUP["K_UP_int / K_UP_enc"] style KAUSF fill:#ffe0b2 style KSEAF fill:#c8e6c9 style KAMF fill:#bbdefb ``` 这套层级有三个工程价值： - **前向/水平隔离**：切换时 `K_AMF` 不变，但 `K_gNB` 用目标小区 PCI/频点重新派生（即 horizontal key derivation），新旧 gNB 密钥不互通。 - **算法可协商**：密钥派生把"算法标识"作为输入，意味着 NAS SMC 协商出什么算法，就生成对应密钥；算法降级攻击会被密钥不匹配直接挡掉。 - **AKMA 的种子**：`K_AUSF` 还能进一步派生 `K_AKMA`（TS 33.535），为第三方应用提供应用层认证，主认证因此成为整个 5G 安全生态的信任根。 ## 六、5G AKA vs EAP-AKA'：两种主认证方法的工程对比 TS 33.501 §6.1.3（5G AKA）与 §6.1.4（EAP-AKA'）是并列的主认证方法。运营商在 UDM 侧按签约选择，UE 不参与方法选择。下表是工程实践中最常被问到的差异： | 对比维度 | 5G AKA | EAP-AKA' | |----------|--------|----------| | **规范** | TS 33.501 §6.1.3 | TS 33.501 §6.1.4 + RFC 9048 | | **载体** | NAS 原生消息 | EAP 协议封装于 NAS | | **最终确认方** | AUSF 直接比 XRES* | AUSF 作为 EAP 服务器，比 XRES* | | **服务网络预确认** | 有（HXRES*） | 无独立预确认（EAP 成功即结束） | | **典型场景** | 3GPP 接入（gNB） | 非 3GPP 接入（如可信 WLAN、Wireline） | | **密钥产出** | K_AUSF | K_AUSF（同样接入 5G 密钥链） | | **抗 false base station** | 强（双确认） | 强（EAP 端到端） | | **实现复杂度** | 低（NAS 原生） | 高（需 EAP 栈） | 一个常被误解的点：**两者最终都产出 K_AUSF 并接入同一棵密钥树**，所以对 NAS/AS 安全而言没有强度差异；选择 EAP-AKA' 主要是为了复用成熟的 EAP 框架以支持非 3GPP 接入与可信接入融合。 ## 七、AUTN 校验与失败处理：MAC failure 与 SQN 同步失败 UE 收到 `Authentication Request` 后，USIM 执行三件事（TS 33.102 §6.3.x）：① 用 f1 重算 MAC 并与 AUTN 内 MAC 比对；② 检查 AMF 字段 separation bit；③ 校验 SQN 是否在 USIM 可接受窗口内。任一失败都会回 `Authentication Failure`，5GMM cause value 见 TS 24.501： | Cause | 含义 | 触发条件 | 网络侧处理 | |-------|------|----------|------------| | **#20** MAC failure | AUTN 中 MAC 校验失败 | K 不匹配 / 篡改 / 算法错 | 通常是配卡错误，AMF 直接判定鉴权失败 | | **#21** Synch failure | SQN 越界 | USIM 的 SQN 落后或被重放 | 携带 AUTS 触发重同步 | | **#17** (5GMM) | 网络失败 | — | AMF 决定后续策略 | **SQN 重同步流程**（TS 33.102 §6.3.5, TS 33.501 §6.1.3）：UE 在 Synch failure 中回送 `AUTS`（含 USIM 侧当前 SQN 的掩码）。ARPF 用 f1\* 解出 USIM 侧 SQN，据此调整自己的 SQN 并重新生成 AV。这是实战中最常见的"卡第一次插上就鉴权失败、重试一次就好"的根因。 ```mermaid sequenceDiagram autonumber participant UE participant AMF participant AUSF participant ARPF AMF->>UE: Auth Request (RAND, AUTN) Note over UE: MAC OK 但 SQN < USIM窗口 UE->>AMF: Auth Failure (Synch failure, AUTS) AMF->>AUSF: Confirm (failure, AUTS) AUSF->>ARPF: 转发 AUTS Note over ARPF: f1* 解出 USIM侧SQN
重置自己SQN, 生成新AV ARPF-->AUSF: 新 AV(RAND',AUTN',XRES*',KAUSF') AUSF->>AMF: HXRES*', RAND', AUTN' AMF->>UE: Auth Request (RAND', AUTN') Note over UE: SQN 校验通过 → RES*' UE->>AMF: Auth Response (RES*') ``` ## 八、抓包识别与故障排错（实战篇） ### 8.1 如何在 Wireshark 里识别 5G AKA 在 N2（NGAP）+ N1（NAS）联合抓包中，鉴权流程的标志性消息如下： 1. **NGAP: Initial UE Message**（携带 Registration Request，含 SUCI）。 2. **NAS: Authentication Request**（Message Type 0x39，IE：`ngKSI`、`ABBA`、`RAND`(16 字节)、`AUTN`(16 字节)）。此时消息**未加密未完整性保护**。 3. **NAS: Authentication Response**（Message Type 0x3A，IE：`RES*`，长度可变，TS 24.501 §9.9.3.16）。 4. **NAS: Security Mode Command**（消息进入完整性保护，Wireshark 若无 K_NAS_int 则只能看到密文）。 排错技巧：若看到 Authentication Request 后立刻出现 Authentication Reject 或 Mobility Management 拒绝，先把 RAND/AUTN 的 hex 与 USIM 配置的 K/SQN 对比；用 `pcap-analyzer` 类工具可批量提取鉴权消息并比对 XRES*。 ### 8.2 三大高频故障点 | 故障现象 | 根因 | 排查方向 | |----------|------|----------| | **MAC failure (#20)** | USIM 的 K 与 UDM 的 K 不一致 | 检查制卡/写卡参数、OPc 计算是否正确 | | **Synch failure (#21)** 循环 | SQN 漂移、重同步逻辑未实现 | 检查 ARPF 是否处理 AUTS；free5GC/open5gs 早期版本对重同步支持不完整 | | **HXRES\* 不匹配** | SN Name 构造不一致（mnc 补零、大小写） | 对齐 UE 与 AMF 的 SN Name 字符串；注意 MNC 2 位补零规则 | ## 九、常见问题 **Q1: 5G AKA 相比 EPS-AKA 最大的安全提升是什么？** A: 是**归属网络确认**。EPS-AKA 里 MME 拿到 XRES 自行比对，归属网络不参与最终判定，恶意 SN 可重放 AV 欺骗 UE。5G AKA 让 AUSF 在归属域用 XRES* 做最终比对，且只向 AMF 下发哈希 HXRES*，使服务网络无法伪造认证结果。 **Q2: HXRES\* 已经能比对，为什么 AUSF 还要再比一次 XRES\*？** A: 因为 HXRES\* 是单向哈希，AMF 无法反推 XRES\*。HXRES\* 仅用于 AMF 本地快速预筛（剔除明显错误回应）；真正的认证确认必须在归属网络完成（AUSF 比 XRES*），这是把信任锚点钉死在归属域的关键。 **Q3: RES\* 为什么要把 Serving Network Name 塞进 KDF？** A: 绑定服务网络身份。即便攻击者截获某 SN 下的 RES\*，换一个 SN Name 重放时 KDF 输入改变，RES\* 计算结果不同，比对必然失败。这是对跨域/跨网重放攻击的根本防御。 **Q4: SUCI 的 null-scheme（空方案）安全吗？** A: null-scheme 只做 MAC 不做加密，SUPI 实际明文（仅做完整性），**仅用于运营商未部署公钥保护时的过渡**。生产环境应启用 ECIES（Profile A/B），只有持有 HN 私钥的 SIDF 才能解 conceal，实现空口身份隐私。 **Q5: 鉴权成功后 K_SEAF 直接用了吗？** A: 否。K_SEAF 是服务域锚点，AMF 进一步派生 K_AMF（绑定 SUPI 与 ABBA），再分别派生 NAS 完整性/加密密钥与 K_gNB。切换时 K_gNB 水平派生，K_AMF 不变，保证移动中密钥连续性。 ## 参考来源 1. [3GPP TS 33.501 — Security architecture and procedures for 5G system](https://www.3gpp.org/dynareport/33501.htm) — Clause 6.1.3 (5G AKA), Annex A.2/A.5/A.7 (KDF) 2. [Introduction to 5G AKA — free5GC](https://free5gc.org/blog/20251029/20251029/) — 开源实现的密钥层级 K_SEAF/K_AMF 派生与 AUSF 设计 3. [5G-AKA and EAP-AKA Prime: Complete Authentication Procedure — 5g6gacademy](https://www.5g6gacademy.com/learn/5g-authentication-flow) — 双确认机制与 EPS-AKA 差异 4. [EAP AKA Prime Explained: AKA' vs EAP AKA — P1 Security](https://www.p1sec.com/blog/eap-aka-prime-what-aka-changes-and-why-it-matters-in-mobile-network-security) — 5G AKA vs EAP-AKA' 安全分析 5. [5G NAS Authentication Failures Cause Values — Techplayon](https://www.techplayon.com/5g-nas-authentication-failures-cause-values/) — MAC failure/Synch failure 排错与 SQN 重同步 6. [Protecting Subscriber Identifiers with SUCI — NIST CSWP 36A](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.36A.pdf) — ECIES Profile A/B 保护方案密码学分析 7. [5G Core Authentication — ShareTechnote](https://www.sharetechnote.com/html/5G/5G_Core_Authentication.html) — AUTN/SQN/HRES* 信令流程图解 8. [5G SA Authentication Failure: SQN synchronization — free5GC Forum](https://forum.free5gc.org/t/5g-sa-authentication-failure-with-free5gc-oai-gnb-usrp-b210-sqn-synchronization-issues/2845) — 开源网元 SQN 重同步实战问题 --- > 本文由「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 等场景全覆盖。