聚焦规范:3GPP TS 33.501 V18.10.0(Release 18)Section 6.1 ~ 6.2
核心机制:5G-AKA主认证完整信令流、认证向量(5G HE AV / 5G AV)生成、多级密钥推演函数(KDF)链式调用
5G系统安全架构定义于TS 33.501 Section 5,包含六个安全特征域:网络接入安全(I)、网络域安全(II)、用户域安全(III)、应用域安全(IV)、SBA域安全(V)、可视化安全(VI)。主认证(Primary Authentication)属于网络接入安全(I)的基石,它解决三个核心问题:
与4G EPS-AKA相比,5G-AKA引入了SEAF/AUSF双层锚点架构、SUPI隐私保护(SUCI)以及服务网络名称绑定(SN_name binding)三大核心改进。
| 逻辑功能 | 物理部署 | 核心职责 | TS 33.501章节 |
|---|---|---|---|
| SEAF (Security Anchor Function) | 共址于AMF | 接收认证向量、发起NAS认证、验证HXRES* | §6.1.3 |
| AUSF (Authentication Server Function) | HPLMN核心网 | 向UDM请求认证向量、验证RES*、推演KSEAF | §6.1.2 |
| UDM/ARPF (Authentication Repository) | HPLMN核心网 | 存储K、生成5G HE AV、管理SQN | §6.1.1 |
| SIDF (SUPI Subscription Identifier De-concealing Function) | UDM内 | 解密SUCI恢复SUPI | §6.12 |
| UE/USIM | 终端侧 | 存储K、计算RES*、验证AUTN | §6.1.3.2 |
| ## 二、5G-AKA完整信令时序图 |
以下信令流严格对齐TS 33.501 Section 6.1.1.2(5G-AKA主认证流程)和TS 23.502 Section 4.2.2.2(注册过程中的认证):
sequenceDiagram
participant UE as UE/USIM
participant SEAF as SEAF(AMF)
participant AUSF as AUSF
participant UDM as UDM/ARPF/SIDF
Note over UE,UDM: 阶段0: 注册请求触发
UE->>SEAF: Registration Request<br/>SUCI或5G-GUTI + SNN
Note over SEAF,UDM: 阶段1: 认证向量请求
SEAF->>AUSF: Nausf_UEAuthentication Authenticate Request<br/>SUCI(或SUPI) + SNN(Serving Network Name)
AUSF->>UDM: Nudm_UEAuthentication Get Request<br/>SUCI + SNN
Note over UDM: 阶段2: SIDF解密SUCI→SUPI
Note over UDM: ARPF生成5G HE AV<br/>K,Milenage算法→CK,IK,RAND,AUTN<br/>KDF(CK||IK,...)→KAUSF<br/>KDF(KAUSF,...)→KSEAF<br/>KDF(CK||IK,...)→XRES*
UDM->>AUSF: 5G HE AV[RAND, AUTN, XRES*, KAUSF]
Note over AUSF: 阶段3: AUSF构造5G AV
Note over AUSF: 计算HXRES*=SHA-256(XRES*)<br/>推演KSEAF=KDF(KAUSF,FC=0x6C,SNN)
AUSF->>SEAF: 5G AV[RAND, AUTN, HXRES*]
Note over SEAF,UE: 阶段4: NAS认证挑战
SEAF->>UE: Authentication Request<br/>RAND + AUTN + ngKSI
Note over UE: 阶段5: UE侧认证计算
Note over UE: USIM验证AUTN(MAC=XMAC?)<br/>验证SQN范围<br/>计算RES*<br/>KDF(CK||IK,...)→KAUSF→KSEAF
UE->>SEAF: Authentication Response<br/>RES*
Note over SEAF: 阶段6: SEAF初步验证
Note over SEAF: 计算HRES*=SHA-256(RES*)<br/>比较HRES*==HXRES*?
SEAF->>AUSF: Nausf_UEAuthentication Authenticate Request<br/>RES*(完整值)
Note over AUSF: 阶段7: AUSF最终验证
Note over AUSF: 比较RES*==XRES*?<br/>认证成功→存储KSEAF
AUSF->>SEAF: Nausf_UEAuthentication Authenticate Response<br/>Result=SUCCESS + KSEAF + SUPI
Note over SEAF: 阶段8: 推演KAMF
Note over SEAF: KAMF=KDF(KSEAF,FC=0x6D,SUPI,ABBA)
SEAF->>UE: Security Mode Command<br/>选定的NAS安全算法 + ngKSI
UE->>SEAF: Security Mode Complete<br/>(NAS安全激活)
由UDM/ARPF基于长期共享密钥K生成,定义于TS 33.501 Section 6.1.1.3。整个生成过程基于Milenage算法集(TS 35.206)和HMAC-SHA-256 KDF。
flowchart TD
K[长期共享密钥 K<br/>128/256-bit] --> M[Milenage算法集<br/>f1~f5函数]
RAND[RAND<br/>128-bit随机数] --> M
M --> CK[CK Cipher Key<br/>128-bit]
M --> IK[IK Integrity Key<br/>128-bit]
M --> AK[AK Anonymity Key<br/>48-bit]
M --> SQN[SQN Sequence Number]
M --> MAC_A[MAC-A<br/>64-bit消息认证码]
SQN --> AUTN_GEN[AUTN生成]
AK --> AUTN_GEN
MAC_A --> AUTN_GEN
AUTN_GEN --> AUTN[AUTN Authentication Token<br/>SQN⊕AK --> |AMF| MAC-A<br/>共128-bit]
CK --> CONCAT[CK || IK<br/>256-bit]
IK --> CONCAT
CONCAT --> KDF_KAUSF["KDF(CK||IK, FC=0x6A)<br/>P0=SNN, P1=SQN⊕AK"]
KDF_KAUSF --> KAUSF["KAUSF<br/>256-bit"]
KAUSF --> KDF_KSEAF["KDF(KAUSF, FC=0x6C)<br/>P0=SNN"]
KDF_KSEAF --> KSEAF["KSEAF<br/>256-bit"]
CONCAT --> KDF_XRES["KDF(CK||IK, FC=0x6B)<br/>P0=SNN, P1=RAND, P2=RES"]
KDF_XRES --> XRES_STAR["XRES*<br/>可变长度"]
style K fill:#f9d5d5,stroke:#c0392b
style AUTN fill:#d5e8f9,stroke:#2980b9
style KSEAF fill:#d5f9e8,stroke:#27ae60
style KAUSF fill:#f9f0d5,stroke:#f39c12
| IE名称 | 长度 | 生成方 | 作用 | TS 33.501章节 |
|---|---|---|---|---|
| RAND | 128-bit | UDM/ARPF | 随机挑战值,每次认证唯一 | §6.1.1.3 |
| AUTN | 128-bit | UDM/ARPF | 认证令牌=SQN⊕AK(48bit) || AMF(16bit) || MAC-A(64bit) | §6.1.1.3 |
| XRES* | 可变 | UDM/ARPF | KDF(CK||IK, 0x6B, SNN, RAND, RES)推演的期望响应 | Annex A.2 |
| HXRES* | 256-bit | AUSF | SHA-256(XRES*)的哈希值,交由SEAF做初步验证 | §6.1.3.3 |
| KAUSF | 256-bit | UDM/ARPF | AUSF锚点密钥=KDF(CK||IK, 0x6A, SNN, SQN⊕AK) | Annex A.2 |
| KSEAF | 256-bit | AUSF | SEAF锚点密钥=KDF(KAUSF, 0x6C, SNN) | Annex A.2 |
| ngKSI | 3-bit | SEAF | NAS安全上下文标识,用于关联Security Mode Command | §6.1.3.3 |
AUTN是UE验证网络合法性的核心令牌,其内部编码结构如下:
AUTN (128 bits total):
┌─────────────────┬──────────┬──────────────────────────────┐
│ SQN ⊕ AK │ AMF │ MAC-A │
│ (48 bits) │ (16 bits)│ (64 bits) │
└─────────────────┴──────────┴──────────────────────────────┘
字节0-5 字节6-7 字节8-15
SQN ⊕ AK: 序列号与匿名密钥的异或值,UE通过AK还原SQN
AMF: Authentication Management Field,包含分离指示符
MAC-A: 基于K和RAND计算的消息认证码,f1(K, RAND, SQN, AMF)
UE验证逻辑(TS 33.501 §6.1.3.2): 1. USIM使用K和RAND通过f5算法计算出AK 2. 还原SQN = (SQN ⊕ AK) ⊕ AK 3. 使用K、RAND、还原的SQN、AMF通过f1计算XMAC-A 4. 比较XMAC-A与收到的MAC-A → 网络认证 5. 检查SQN是否在可接受范围内 → 重放攻击保护
5G密钥层级采用自顶向下的KDF链式推演,每一级的输入密钥来自上一级的输出。所有KDF统一使用HMAC-SHA-256(TS 33.220 Annex B)。
Derived Key = HMAC-SHA-256(Key, FC || P0 || L0 || P1 || L1 || ... || Pn || Ln)
其中: - Key: 输入密钥(256-bit) - FC: 函数码(1字节,标识推演用途) - Pi: 第i个参数值 - Li: 第i个参数的长度(2字节,大端编码)
flowchart TD
subgraph USIM_UDM["USIM / UDM (共享K)"]
K["K<br/>永久密钥"] --> Milenage
RAND2["RAND"] --> Milenage
Milenage["Milenage<br/>f1~f5"] --> CK_IK["CK || IK"]
end
subgraph ARPF_KDF["ARPF密钥推演"]
CK_IK -->|"FC=0x6A<br/>P0=SNN, P1=SQN⊕AK"| KAUSF["KAUSF"]
CK_IK -->|"FC=0x6B<br/>P0=SNN, P1=RAND, P2=RES"| XRES2["XRES*"]
KAUSF -->|"FC=0x6C<br/>P0=SNN"| KSEAF["KSEAF"]
end
subgraph AMF_KDF["AMF(SEAF)密钥推演"]
KSEAF -->|"FC=0x6D<br/>P0=SUPI, P1=ABBA"| KAMF["KAMF"]
KAMF -->|"FC=0x6E<br/>P0=UL NAS COUNT, P1=AccessType"| KgNB["KgNB"]
KAMF -->|"FC=0x69<br/>P0=算法类型+算法ID"| KNAS["KNASint / KNASenc"]
end
subgraph GNB_KDF["gNB密钥推演"]
KgNB -->|"FC=0x6F"| KRRC["KRRCint / KRRCenc"]
KgNB -->|"FC=0x70"| KUP["KUPint / KUPenc"]
end
style K fill:#f9d5d5,stroke:#c0392b
style KSEAF fill:#d5f9e8,stroke:#27ae60
style KAMF fill:#d5e8f9,stroke:#2980b9
style KgNB fill:#f9f0d5,stroke:#f39c12
| 推演目标 | FC | 输入密钥 | P0 | P1 | P2 | 规范章节 |
|---|---|---|---|---|---|---|
| KAUSF | 0x6A | CK||IK | SNN | SQN⊕AK | — | Annex A.2 |
| XRES* | 0x6B | CK||IK | SNN | RAND | RES/XRES | Annex A.2 |
| KSEAF | 0x6C | KAUSF | SNN | — | — | Annex A.2 |
| KAMF | 0x6D | KSEAF | SUPI | ABBA(0x0000) | — | Annex A.3 |
| KgNB | 0x6E | KAMF | UL NAS COUNT | AccessType | — | Annex A.4 |
| KNASint | 0x69 | KAMF | algo_type||algo_id | — | — | Annex A.3 |
| KNASenc | 0x69 | KAMF | algo_type||algo_id | — | — | Annex A.3 |
| KRRCint | 0x6F | KgNB | algo_type||algo_id | — | — | Annex A.7 |
| KRRCenc | 0x6F | KgNB | algo_type||algo_id | — | — | Annex A.7 |
| KUPint | 0x70 | KgNB | algo_type||algo_id | — | — | Annex A.7 |
| KUPenc | 0x70 | KgNB | algo_type||algo_id | — | — | Annex A.7 |
| ## 五、5G-AKA vs EAP-AKA'双轨认证对比 |
TS 33.501 Section 6.1定义了两种主认证方法。5G-AKA用于3GPP接入(NR→5GC),EAP-AKA'用于非3GPP接入(Wi-Fi→N3IWF/TNGF→5GC)。
flowchart LR
subgraph FiveG_AKA["5G-AKA (3GPP接入)"]
direction TB
F1["Authentication Request<br/>RAND+AUTN+ngKSI"] --> F2["Authentication Response<br/>RES*"]
F2 --> F3["(隐式确认)<br/>Security Mode Command"]
end
subgraph EAP_AKAP["EAP-AKA' (非3GPP接入)"]
direction TB
E1["EAP-Request/AKA'-Challenge<br/>RAND+AUTN+AT_KDF+MAC"] --> E2["EAP-Response/AKA'-Challenge<br/>RES*+MAC"]
E2 --> E3["EAP-Success<br/>(显式确认)"]
E3 --> E4["Security Mode Command"]
end
style F3 fill:#f9d5d5,stroke:#c0392b
style E3 fill:#d5f9e8,stroke:#27ae60
| 对比维度 | 5G-AKA | EAP-AKA' |
|---|---|---|
| 确认机制 | 隐式(Security Mode Command隐含认证成功) | 显式(EAP-Success消息明确确认) |
| 协议来源 | 3GPP原生协议 | IETF RFC 9048(原RFC 5448) |
| 密钥绑定 | KDF中绑定SN_name | AT_KDF属性协商 + 网络名绑定 |
| 额外KDF步骤 | 无(直接从CK||IK推演KAUSF) | 先推演CK'||IK'再推演KAUSF |
| 消息轮次 | 较少(2轮NAS认证) | 较多(EAP-Request/Response多轮交互) |
| 适用场景 | 3GPP接入(NR/LTE→5GC) | 非可信非3GPP接入(Wi-Fi via N3IWF) |
| 选择方 | UDM/ARPF根据接入类型和签约决定 | 同左 |
| SQN重同步 | AUTS在Authentication Failure中发送 | EAP-Response/AKA'-Synchronization-Failure |
这是一个关键的设计决策(TS 33.501 §6.1.3.3): - 在4G EPS-AKA中,认证成功后没有显式确认,存在假基站攻击的可能 - 5G-AKA的改进在于:SEAF验证HXRES*后再发送Security Mode Command,该命令使用从KAMF推演的KNASint进行完整性保护 - UE收到经过完整性保护的Security Mode Command = 隐式证明网络确实拥有K并成功验证了RES* - 这比4G更安全(完整性保护证实了密钥持有),但不如EAP-AKA'的显式EAP-Success明确
5G-AKA引入了一个4G没有的关键创新——SEAF初步验证 + AUSF最终验证的双层机制。
HXRES* = SHA-256(XRES*)[0:128] — 由AUSF计算,发送给SEAF
HRES* = SHA-256(RES*)[0:128] — 由SEAF在收到UE响应后计算
判断条件:HRES* == HXRES* ?
设计意图:SEAF(即AMF)位于访问网络(VPLMN),而AUSF位于归属网络(HPLMN)。HXRES*机制使得VPLMN可以在不暴露完整XRES*给SEAF的情况下,让SEAF独立完成初步验证。只有通过初步验证的RES*才会上送到AUSF做最终验证,减少HPLMN与VPLMN之间的信令交互。
AUSF直接比较RES*(来自SEAF转发)与XRES*(来自UDM),执行完整的比特级比对。这是最终认证判决点。
stateDiagram-v2
[*] --> WAIT_AUTH: Registration Request received
WAIT_AUTH --> WAIT_RES: Authentication Request sent<br/>(RAND+AUTN+ngKSI)
WAIT_RES --> SEAF_VERIFY: Authentication Response<br/>RES* received
SEAF_VERIFY --> AUSF_VERIFY: HRES*==HXRES* ✓<br/>(初步验证通过)
SEAF_VERIFY --> AUTH_FAIL: HRES*!=HXRES* ✗<br/>(初步验证失败)
AUSF_VERIFY --> AUTH_SUCCESS: RES*==XRES* ✓<br/>(AUSF最终验证通过)
AUSF_VERIFY --> AUTH_FAIL: RES*!=XRES* ✗<br/>(AUSF最终验证失败)
AUTH_SUCCESS --> SMC_SENT: KSEAF+SUPI received<br/>KAMF推演完成<br/>Security Mode Command sent
SMC_SENT --> SECURITY_ACTIVE: Security Mode Complete<br/>NAS安全激活
AUTH_FAIL --> WAIT_AUTH: 可能重试<br/>(新认证向量)
SECURITY_ACTIVE --> [*]
5G引入的SUCI(Subscription Concealed Identifier)是相对4G的重大安全增强,定义于TS 33.501 Section 6.12。
SUCI = SUPI Type (4bit) | MCC (3 digits) | MNC (2~3 digits) |
Routing Indicator (1~4 digits) |
Protection Scheme ID (4bit) |
Home Network Public Key ID (8bit) |
Scheme Output (可变长度)
| 字段 | 长度 | 说明 |
|---|---|---|
| SUPI Type | 4-bit | 0=IMSI, 1=NAI, 2=GCI, 3=GLI |
| MCC+MNC | 5~6 digits | 归属网络PLMN标识 |
| Routing Indicator | 1~4 digits | 路由到UDM的指示符 |
| Protection Scheme ID | 4-bit | 0=null-scheme, 1=ECIES, 2=... |
| Home Network PK ID | 8-bit | 归属网络公钥索引 |
| Scheme Output | 可变 | ECIES加密的SUPI(使用HN公钥) |
当Protection Scheme ID=1时,采用椭圆曲线集成加密方案(ECIES)保护SUPI:
5G NAS Authentication Request(DL,未加密):
- Wireshark过滤器:nas-5gs.message_type == 0x56
- 关键字段:RAND(16字节随机数)、AUTN(16字节认证令牌)、ngKSI(安全上下文标识)
5G NAS Authentication Response(UL,未加密):
- Wireshark过滤器:nas-5gs.message_type == 0x57
- 关键字段:RES*(可变长度认证响应)
5G NAS Authentication Failure(UL,未加密):
- Wireshark过滤器:nas-5gs.message_type == 0x5c
- 关键字段:5GMM Cause(#20=MAC failure, #21=Synch failure, #26=Security mode rejected)
Nausf SBI接口(HTTP/2):
- 过滤器:http2.headers.path contains "nausf-auth/v1/ue-authentications"
- 观察AuthType字段确认使用5G-AKA还是EAP-AKA'
| 故障现象 | 可能原因 | 排查思路 |
|---|---|---|
| Authentication Failure #20 (MAC failure) | K不匹配、RAND生成异常、USIM与HSS密钥不一致 | 检查USIM的KI/K/OPC配置与UDM是否一致 |
| Authentication Failure #21 (Synch failure) | SQN超出可接受范围(USIM与UDM不同步) | 检查USIM的SQN值与UDM侧SQN差距;关注AUTS中携带的SQN_MS |
| Authentication Reject | AUSF验证失败或签约限制 | 查看AUSF日志中RES*比对结果;检查UDM签约数据 |
| Security Mode Reject | 算法协商失败(UE不支持网络选定的算法) | 检查UE NAS Security Capability IE与AMF配置的算法优先级 |
| 循环认证(不断重发Auth Request) | HXRES*验证反复失败或SQN持续不同步 | 抓包分析每轮的RAND/AUTN是否更新;检查UDM的SQN管理策略 |
| ## 九、5G-AKA的已知安全局限与演进 |
根据近年学术研究(如arxiv 2507.17491、MDPI Sensors 2024文章):
Q1: 5G-AKA中HXRES*和XRES*为什么不直接发给SEAF?
A: SEAF位于VPLMN(访问网络),如果直接将完整XRES*发给VPLMN,则VPLMN可以冒充UE。HXRES*=SHA-256(XRES*)的哈希值仅允许SEAF做等值比对而无法反推XRES*,确保只有HPLMN的AUSF才能执行最终的完整验证。这是归属网络控制(Home Control)原则的体现。
Q2: 5G-AKA的ngKSI和4G的KSI_ASME有什么区别?
A: 功能类似,都是安全上下文的标识符。但5G-AKA的ngKSI长度为3-bit(0~7),而4G的KSI_ASME为3-bit。关键区别在于ngKSI关联的是5G安全上下文(基于KAMF),而非4G的EPS安全上下文(基于KASME)。在N2切换时,ngKSI用于目标AMF索引正确的安全上下文。
Q3: SUPI在什么场景下会以明文(null-scheme)传输?
Q4: 为什么KAMF推演中需要ABBA参数?
A: ABBA(Anti-Bidding down Between Architectures)参数用于防止安全降级攻击。ABBA=0x0000表示5G安全架构,确保攻击者无法将5G认证降级到4G EPS-AKA的安全等级。ABBA的引入使得KAMF与特定的安全架构版本绑定,即使KSEAF相同,不同的ABBA值也会产生不同的KAMF。
Q5: 5G-AKA中如果UE检测到SQN不同步,会触发什么流程?
A: UE在AUTN验证中检查SQN是否在可接受窗口内。如果SQN超出范围,UE发送Authentication Failure(5GMM Cause #21 = Synch failure),并在AUTS字段中携带UE侧的SQN_MS(经过AK加密保护)。UDM收到AUTS后解密SQN_MS,与自身SQN_H比较,据此调整SQN_H并生成新的5G HE AV。这就是SQN重同步流程(TS 33.501 §6.1.3.2)。
本文由「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 等场景全覆盖。
