5G-AKA(Authentication and Key Agreement)是5G系统最核心的安全锚点机制,定义于TS 33.501 Section 6.1。与4G EPS-AKA相比,5G-AKA引入了三层关键改进:服务网络显式鉴权、XRES*扩展响应机制和KSEAF安全锚点密钥层级。
本文聚焦TS 33.501 V18.10.0 Section 6.1.1中定义的5G-AKA主鉴权流程,深入拆解从UDM/ARPF生成5G HE AV(Home Environment Authentication Vector)到UE侧完成AUTN验证并推衍完整密钥层级的过程,特别是XRES*/HXRES*双端验证这一5G独有的安全增强设计。
sequenceDiagram
participant UE as UE/USIM
participant SEAF as SEAF(AMF)
participant AUSF as AUSF
participant UDM as UDM/SIDF/ARPF
Note over UE,UDM: 阶段一:初始注册触发鉴权
UE->>SEAF: Registration Request(SUCI/5G-GUTI)
Note right of SEAF: AMF决定需要执行主鉴权<br/>触发Nausf服务调用
Note over UE,UDM: 阶段二:鉴权向量请求与生成
SEAF->>AUSF: Nausf_UEAuthentication Authenticate Request<br/>(SUCI/SUPI, SNN)
AUSF->>UDM: Nudm_UEAuthentication Get Request<br/>(SUCI/SUPI, SNN)
Note over UDM: SIDF解密SUCI→SUPI<br/>ARPF检索长期密钥K<br/>执行MILENAGE算法集<br/>生成5G HE AV{RAND,AUTN,XRES*,KAUSF}
UDM->>AUSF: Nudm_UEAuthentication Get Response<br/>(5G HE AV: RAND,AUTN,XRES*,KAUSF)
Note over AUSF: 从XRES*派生HXRES*<br/>HXRES*=SHA-256(RAND⊕XRES*)<br/>存储XRES*和KAUSF
AUSF->>SEAF: Nausf_UEAuthentication Authenticate Response<br/>(RAND,AUTN,HXRES*)
Note over UE,UDM: 阶段三:UE侧鉴权挑战与响应
SEAF->>UE: DL NAS Transport: Authentication Request<br/>(RAND,AUTN,ngKSI)
Note over UE: USIM执行:<br/>1)f1(K,RAND,SQN,AMF)→XMAC<br/>2)比对XMAC==AUTN中MAC<br/>3)验证SQN freshness<br/>4)f2(K,RAND)→RES<br/>5)KDF→RES*<br/>6)KDF→CK',IK'→KAUSF
UE->>SEAF: UL NAS Transport: Authentication Response<br/>(RES*)
Note over UE,UDM: 阶段四:双端验证与密钥确认
Note over SEAF: SEAF计算HRES*=SHA-256(RAND⊕RES*)<br/>比对HRES*==HXRES*<br/>(第一重验证:服务网络侧)
SEAF->>AUSF: Nausf_UEAuthentication Authenticate Request<br/>(RES*)
Note over AUSF: AUSF比对RES*与存储的XRES*<br/>(第二重验证:归属网络侧)<br/>若匹配,推衍KSEAF<br/>KSEAF=KDF(KAUSF,SNN)
AUSF->>SEAF: Nausf_UEAuthentication Authenticate Confirmation<br/>(KSEAF,"true"/Supi)
Note over SEAF: SEAF收到KSEAF<br/>KAMF=KDF(KSEAF,ABBA,SUPI)<br/>→派生NAS/RAN层密钥
SEAF->>UE: Security Mode Command<br/>(NAS安全算法,ngKSI)
UE->>SEAF: Security Mode Complete
鉴权向量的生成是整个5G-AKA的信任根。在UDM内部的ARPF(Authentication credential Repository and Processing Function)中,使用长期共享密钥K和算法配置参数OPc,通过MILENAGE算法集(TS 35.206)生成中间参数。
flowchart TB
subgraph ARPF["UDM/ARPF内部"]
K["长期密钥 K<br/>(128/256-bit)"]
OPC["算法配置 OPc<br/>(128-bit)"]
RAND["随机数 RAND<br/>(128-bit)"]
SQN["序列号 SQN<br/>(48-bit)"]
AMF["鉴权管理字段 AMF<br/>(16-bit)"]
K --> MIL["MILENAGE算法集<br/>TS 35.206"]
OPC --> MIL
RAND --> MIL
MIL --> f1["f1/f1*: MAC/XMAC<br/>(64-bit)"]
MIL --> f2["f2: RES<br/>(≤256-bit)"]
MIL --> f3["f3: CK<br/>(128-bit)"]
MIL --> f4["f4: IK<br/>(128-bit)"]
MIL --> f5["f5: AK<br/>(48-bit)"]
f1 --> AUTN["AUTN构造<br/>= SQN⊕AK ‖ AMF ‖ MAC"]
f5 --> AUTN
SQN --> AUTN
AMF --> AUTN
f2 --> XRES_STAR["XRES*派生<br/>= KDF_CK‖IK<br/>('5G AKA',RAND,XRES)"]
f3 --> XRES_STAR
f4 --> XRES_STAR
f3 --> KAUSF["KAUSF派生<br/>= KDF_CK‖IK<br/>(SN_Id,SQN⊕AK)"]
f4 --> KAUSF
f5 --> KAUSF
end
AUTN --> AV["5G HE AV<br/>{RAND,AUTN,XRES*,KAUSF}"]
XRES_STAR --> AV
KAUSF --> AV
表1:5G HE AV四元组参数说明
| 参数 | 长度 | 来源/算法 | 作用 |
|---|---|---|---|
| RAND | 128-bit | ARPF随机数生成器 | 挑战值,确保每次鉴权新鲜性 |
| AUTN | 128-bit | f1(K,RAND,SQN,AMF)+SQN⊕AK+AMF | 网络鉴权令牌,UE据此验证网络真实性 |
| XRES* | 可变(≤512-bit) | KDF(CK||IK, "5G AKA"||RAND||XRES) | 扩展期望响应,AUSF侧验证UE |
| KAUSF | 256-bit | KDF(CK||IK, SN_Id||SQN⊕AK) | AUSF锚点密钥,后续推衍KSEAF的基础 |
AUTN内部结构(128-bit):
| 字段 | 比特位 | 长度 | 说明 |
|---|---|---|---|
| SQN⊕AK | [0:47] | 48-bit | 序列号异或匿名密钥,防止SQN被窃听 |
| AMF | [48:63] | 16-bit | 鉴权管理字段,bit0=0表示5G-AKA |
| MAC | [64:127] | 64-bit | 消息鉴权码,f1算法输出 |
USIM在收到RAND和AUTN后,执行以下验证序列:
AK = f5(K, RAND)SQN = (SQN⊕AK) ⊕ AK,从AUTN前48-bit恢复明文SQNXMAC = f1(K, RAND, SQN, AMF)XMAC == AUTN[64:127],若不等则返回MAC FailureRES = f2(K, RAND)RES* = KDF(CK||IK, "5G AKA" || RAND || RES)stateDiagram-v2
[*] --> ReceiveChallenge: 收到RAND+AUTN
ReceiveChallenge --> ComputeAK: f5(K,RAND)→AK
ComputeAK --> RecoverSQN: SQN=(SQN⊕AK)⊕AK
RecoverSQN --> ComputeXMAC: f1(K,RAND,SQN,AMF)→XMAC
ComputeXMAC --> CheckMAC: XMAC==MAC?
CheckMAC --> MACFailure: 不匹配
MACFailure --> [*]: 返回#2626(MAC Failure)
CheckMAC --> CheckSQN: 匹配
CheckSQN --> SQNFailure: SQN不在窗口
SQNFailure --> [*]: 返回#2628(SYNC Failure)<br/>携带AUTS参数
CheckSQN --> ComputeRES: SQN新鲜
ComputeRES --> DeriveKeys: f2→RES, f3→CK, f4→IK
DeriveKeys --> ComputeRESStar: RES*=KDF(CK‖IK,...)
ComputeRESStar --> SendResponse: 发送Authentication Response(RES*)
SendResponse --> [*]
5G-AKA最关键的创新之一是引入了双重响应验证机制。4G中MME直接比对RES与XRES,而5G中将验证分为SEAF侧和AUSF侧两重独立验证。
在4G EPS-AKA中,MME直接拿到完整的鉴权向量(包含XRES),这意味着: - 服务网络拥有完整的XRES明文 - 归属网络对鉴权结果缺乏独立确认能力 - 恶意服务网络可能伪造鉴权成功
5G-AKA通过以下设计解决了这些问题: - AUSF不向SEAF发送XRES*,只发送其哈希HXRES* - SEAF只能验证UE响应的哈希值(第一重),无法获知完整密钥材料 - AUSF独立完成XRES*与RES*的精确比对(第二重)
根据TS 33.501 Annex A.5:
HXRES* = SHA-256(RAND || XRES*)[:128]
即取RAND与XRES*拼接后经SHA-256运算的前128-bit。
表2:SEAF与AUSF双重验证对比
| 维度 | SEAF侧验证 | AUSF侧验证 |
|---|---|---|
| 输入 | HXRES*(预存) vs HRES*(现场计算) | XRES*(预存) vs RES*(来自SEAF) |
| 比对方式 | 哈希值相等性比对 | 完整参数精确比对 |
| 通过后动作 | 转发RES*给AUSF | 推衍KSEAF并下发 |
| 安全语义 | 确认UE确实持有密钥K | 确认UE身份且授权服务网络 |
| 失败处理 | 向UE返回Reject#3GPP(2625) | 向SEAF返回"false" |
HRES* = SHA-256(RAND || RES*)[:128]
验证:HRES* == HXRES* ?
5G-AKA的密钥推演是一棵从K到各层会话密钥的树状结构。所有KDF均基于HMAC-SHA-256,定义于TS 33.501 Annex A。
flowchart TD
K["K (长期共享密钥)<br/>USIM ↔ ARPF"]
K --> MILENAGE["MILENAGE算法集"]
MILENAGE --> CK["CK (128-bit)"]
MILENAGE --> IK["IK (128-bit)"]
MILENAGE --> RES["RES"]
MILENAGE --> AK["AK"]
CK --> KAUSF_Input["CK‖IK"]
IK --> KAUSF_Input
KAUSF_Input -->|"KDF(CK‖IK, FC=0x6A,<br/>P0=SN_Id, P1=SQN⊕AK)"| KAUSF["KAUSF (256-bit)<br/>AUSF锚点密钥"]
KAUSF -->|"KDF(KAUSF, FC=0x6C,<br/>P0=SNN)"| KSEAF["KSEAF (256-bit)<br/>服务网络锚点密钥"]
KSEAF -->|"KDF(KSEAF, FC=0x6F,<br/>P0=ABBA, P1=SUPI)"| KAMF["KAMF (256-bit)<br/>AMF锚点密钥"]
KAMF -->|"KDF(KAMF, FC=0x69,<br/>P0=NAS-int-AlgId)"| KNAS_INT["KNASint<br/>NAS完整性密钥"]
KAMF -->|"KDF(KAMF, FC=0x69,<br/>P0=NAS-enc-AlgId)"| KNAS_ENC["KNASenc<br/>NAS加密密钥"]
KAMF -->|"KDF(KAMF, FC=0x6D,<br/>P0=AccessType)"| KGNB["KgNB<br/>gNB锚点密钥"]
KGNB --> KRRC_INT["KRRCint"]
KGNB --> KRRC_ENC["KRRCenc"]
KGNB --> KUP_ENC["KUPenc"]
KGNB --> KUP_INT["KUPint"]
style K fill:#e74c3c,color:#fff
style KAUSF fill:#e67e22,color:#fff
style KSEAF fill:#f39c12,color:#fff
style KAMF fill:#27ae60,color:#fff
style KGNB fill:#3498db,color:#fff
表3:密钥层级KDF参数一览(TS 33.501 Annex A)
| 密钥 | KDF输入(FC值) | 关键参数P0/P1 | 生成的层级 |
|---|---|---|---|
| KAUSF | FC=0x6A | P0=SN_Id, P1=SQN⊕AK | 归属网络层 |
| KSEAF | FC=0x6C | P0=SNN(Serving Network Name) | 服务网络层 |
| KAMF | FC=0x6F | P0=ABBA参数, P1=SUPI | 接入与移动性层 |
| KNASint | FC=0x69 | P0=0x01‖NAS-int-AlgId | NAS完整性 |
| KNASenc | FC=0x69 | P0=0x02‖NAS-enc-AlgId | NAS加密性 |
| KgNB | FC=0x6D | P0=AccessType(0=3GPP) | RAN层 |
KAMF推衍中引入的ABBA(Anti-Bidding-down Between Architecture)参数是5G特有的防降级机制。ABBA参数确保即使攻击者试图将5G安全上下文降级到4G级别,密钥推衍结果也会不同:
TS 33.501 Section 6.1定义了两种主鉴权方法:5G-AKA和EAP-AKA'。网络侧通过AMF字段(AUTN[48:63])的bit 0区分:
表4:5G-AKA与EAP-AKA'关键差异对比
| 对比维度 | 5G-AKA | EAP-AKA' |
|---|---|---|
| TS参考 | TS 33.501 §6.1.1 | TS 33.501 §6.1.2 |
| AMF bit0 | 0 | 1 |
| UE响应消息 | Authentication Response(RES*) | EAP Response(RES*) |
| 挑战传输 | 直接NAS消息 | EAP封装(EAP-5G容器) |
| 典型适用场景 | 3GPP接入(NR/E-UTRA) | Non-3GPP接入(N3IWF/Wi-Fi) |
| 密钥推衍起点 | KAUSF→KSEAF | MK→MSK→KSEAF |
| 服务网络鉴权 | SNN嵌入KDF链 | RE-Auth值+SNN嵌入 |
| HXRES*机制 | SEAF执行哈希比对 | SEAF执行EAP Success/ailure |
# NAS Authentication Request
nas-5gs.mm.message_type == 0x56
# NAS Authentication Response
nas-5gs.mm.message_type == 0x57
# NAS Authentication Failure
nas-5gs.mm.message_type == 0x58
# NAS Authentication Reject
nas-5gs.mm.message_type == 0x59
# SBI: Nausf_UEAuthentication
http2.path contains "nausf-ueauth"
# SBI: Nudm_UEAuthentication
http2.path contains "nudm-ueauth"
表5:5G-AKA常见故障诊断表
| 故障现象 | NAS Cause值 | 可能原因 | 排错步骤 |
|---|---|---|---|
| MAC Failure | #2626 (0x20) | K/OPc不匹配、RAND被篡改 | ①核对USIM与UDM的K/OPc ②检查RAND传输完整性 |
| SYNC Failure | #2628 (0x22) | SQN不同步 | ①检查UDM侧SQN计数器 ②验证AUTS中的SQN_MS ③触发重新同步流程 |
| Authentication Reject | #2625 (0x21) | XRES*比对失败/订阅无效 | ①检查AUSF日志中XRES*比对结果 ②核实UDM中订阅状态 |
| SBI超时无响应 | N/A | UDM不可达/AUSF配置错误 | ①检查NRF中UDM/AUSF注册状态 ②验证SBI路由可达性 |
| HRES*不匹配 | 内部错误 | SEAF计算异常/RES*传输损坏 | ①在SEAF(AMF)日志比对HRES*与HXRES* ②检查NAS消息完整性 |
| ## 八、SQN同步失败与恢复机制 |
当UE检测到SQN不在可接受窗口内时,USIM返回AUTS参数触发重同步流程(TS 33.501 Section 6.1.1.2):
AUTS = SQN_MS ⊕ f5*(K, RAND) || MAC-S
其中: - SQN_MS:USIM侧当前维护的序列号 - f5*:特殊匿名密钥函数(仅在重同步中使用,与f5区分) - MAC-S = f1*(K, RAND, SQN_MS, AMF):重同步消息鉴权码
重同步流程: 1. UE发送Authentication Failure(SYNC Failure, AUTS) 2. SEAF转发AUTS给AUSF 3. AUSF发送Nudm_UEAuthentication_Get(携带AUTS)给UDM 4. UDM/ARPF验证MAC-S,从AUTS恢复SQN_MS 5. UDM调整SQN并生成新的5G HE AV 6. 新AV下发给UE重新发起鉴权挑战
5G-AKA的每一层设计都有明确的安全目标:
Q1: 5G-AKA和4G EPS-AKA最核心的区别是什么? A: 三个核心差异:①5G-AKA引入KSEAF密钥层级将服务网络身份(SNN)绑定到密钥推衍链,UE可显式验证服务网络;②XRES*比4G XRES长得多(最多512-bit vs 128-bit),提供更强的密钥材料;③HXRES*双端验证机制使SEAF无法获取完整鉴权向量。
Q2: AUTN中的AMF字段有什么作用? A: AMF(Authentication Management Field,16-bit)有两个关键用途:①bit 0区分5G-AKA(=0)和EAP-AKA'(=1);②运营商可自定义其他bit位实现差异化鉴权策略(如指示设备类型、触发特定密钥推衍路径)。
Q3: 为什么SEAF不直接比对RES*和XRES*? A: 因为AUSF不向SEAF发送XRES*明文,只发送其哈希HXRES*。这是为了防止恶意或被入侵的SEAF(AMF)获取完整鉴权向量后冒充UE。SEAF只能验证"UE确实计算了正确的RES*",但无法利用这个信息伪造UE身份。
Q4: SQN同步失败后一定会触发重同步吗? A: 不一定。UE侧维护SQN接受窗口,只有当SQN略超前或滞后时才会触发重同步。如果SQN偏差过大(如长期未使用的SIM卡),UDM可能直接重置SQN。部分运营商实现中连续多次SYNC Failure后会锁定USIM并要求用户到营业厅处理。
Q5: MILENAGE和TUAK两种算法集有什么区别? A: MILENAGE(TS 35.206)基于AES-128,是3G/4G/5G默认算法集。TUAK(TS 35.231)基于Keccak/SHA-3,是Rel-12引入的可选替代方案。两者功能等价(均实现f1-f5函数族),但TUAK提供更好的长期安全裕度。运营商在USIM和UDM中必须使用相同算法集。
本文由「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 等场景全覆盖。
