5G主认证（Primary Authentication）在3GPP TS 33.501中定义了两种并行的认证方法：一种是3GPP体系内部演化而来的5G-AKA，另一种是基于IETF EAP框架的EAP-AKA'（EAP-AKA-prime）。两种方法最终都要在UE与网络之间建立唯一的锚定密钥 K_SEAF，并由此向下派生NAS/接入层密钥，但二者的报文载体、密钥派生数学结构、以及对网络侧功能实体的角色划分截然不同。本文聚焦EAP-AKA'这一支——从 SBI 服务调用、EAP 属性（AT_RAND/AT_AUTN/AT_KDF/AT_RES/AT_MAC）逐字节交互，到 MK→MSK→K_AUSF 的派生链，再到fast re-authentication（快速重认证）状态机，做一次面向协议开发与抓包分析的工程级拆解。所有引用均锚定到具体TS章节号，便于回查。
在EPS（4G）时代，主认证只有EPS-AKA一种形态，USIM卡与HSS之间通过长期密钥K完成挑战应答。到了5G，3GPP引入SBA（Service-Based Architecture）后，认证被拆成 AUSF（认证服务器功能）、UDM/ARPF（统一数据管理/认证凭证存储与处理）、SIDF（订阅标识符去隐藏）等多个NF，同时把锚定密钥从MME上移到 SEAF（安全锚定功能，逻辑上位于AMF）。这种重构天然带来一个选择：AUSF在SBI上是EAP的自然载体——IETF EAP-AKA'（RFC 5448，2021年由RFC 9048更新）早已在Wi-Fi与3GPP互通场景中成熟应用，把它"原样"挂到5G AUSF上，可以让运营商沿用统一的AAA/EAP生态（例如对接企业DN的二次认证、对接Wi-Fi的untrusted non-3GPP接入）。
因此TS 33.501 Clause 6.1.3明确：当UDM/ARPF根据用户签约数据中的"Authentication Method"字段选择EAP-AKA'时，AUSF即作为EAP Server、UE作为EAP Peer，二者之间通过NAS消息的"EAP message"信息元素（IE）承载EAP报文，AMF只做透明转发，不参与EAP语义解析。这是EAP-AKA'与5G-AKA最本质的架构分野——5G-AKA中AMF（SEAF）是认证报文的"半个验证者"，而EAP-AKA'中AMF纯粹是EAP报文的搬运工。
flowchart TD
UE["UE (EAP Peer)<br/>USIM持长期密钥K"]
USIM["USIM<br/>执行UMTS-AKA算法"]
RAN["(R)AN<br/>gNB / N3IWF"]
AMF["AMF<br/>内含SEAF<br/>分配ngKSI"]
AUSF["AUSF<br/>EAP Server角色<br/>派生K_SEAF"]
UDM["UDM/ARPF<br/>生成AV<br/>选择认证方法"]
SIDF["SIDF<br/>SUCI去隐藏"]
UE -.含.-> USIM
UE -->|NAS| RAN --> AMF
AMF -->|Nausf SBI| AUSF -->|Nudm SBI| UDM
UDM -.调用.-> SIDF
AUSF -.|K_SEAF反馈.-> AMF
这里有几个关键边界值得在排错时记住：
下图是EAP-AKA'在full authentication（完全认证）模式下的端到端信令，对应TS 33.501 Clause 6.1.3.2与TS 29.509 Nausf_UEAuthentication服务定义：
sequenceDiagram
autonumber
participant UE as UE (EAP Peer)
participant AN as (R)AN
participant AMF as AMF/SEAF
participant AUSF as AUSF (EAP Server)
participant UDM as UDM/ARPF
UE->>AN: Registration Request<br/>(SUCI 或 5G-GUTI)
AN->>AMF: N2 Initial UE Message
Note over AMF: AMF决定发起主认证<br/>生成servingNetworkName<br/>分配ngKSI
rect rgb(235, 245, 255)
Note over AMF,UDM: 步骤① 取认证向量 (SBI)
AMF->>AUSF: Nausf_UEAuthentication_Assign<br/>POST /nausf-auth/v1/ue-authentications/{suci}<br/>{servingNetworkName, indication}
AUSF->>UDM: Nudm_UEAuthentication_Get<br/>GET /nudm-ueau/v1/{supi}/security-information<br/>{servingNetworkName, ausfInstanceId}
Note over UDM: ARPF基于长期密钥K生成AV<br/>方法=EAP-AKA',含RAND/AUTN/XRES*
UDM-->>AUSF: {authType=EAP-AKA', RAND, AUTN, XRES*, ...}
end
rect rgb(240, 255, 240)
Note over AUSF,UE: 步骤② EAP质询下发
Note over AUSF: AUSF构造EAP-Request/AKA'-Challenge<br/>AT_RAND,AT_AUTN,AT_KDF(=0x01),<br/>AT_KDF_INPUT(servingNetworkName),AT_MAC(=0)
AUSF-->>AMF: Assign Response<br/>{EAP-Request/AKA'-Challenge, ngKSI, ABBA}
AMF->>AN: N2 Downlink NAS Transport
AN->>UE: NAS Authentication Request<br/>(ngKSI, ABBA, EAP message)
end
rect rgb(255, 250, 235)
Note over UE,AUSF: 步骤③ USIM验证网络并应答
Note over UE: USIM用K验证AUTN(SQN/MAC)<br/>若通过,计算RES/CK/IK<br/>派生CK'/IK'(绑定网络名)<br/>派生MK,计算AT_MAC
UE->>AN: NAS Authentication Response<br/>(EAP message = EAP-Response/AKA'-Challenge)<br/>含 AT_RES, AT_MAC
AN->>AMF: N2 Uplink NAS Transport
AMF->>AUSF: Nausf_UEAuthentication_Authenticate<br/>PUT .../ue-authentications/{authCtxId}<br/>{EAP-Response/AKA'-Challenge}
Note over AUSF: 验证AT_RES==XRES*<br/>验证AT_MAC完整性
end
rect rgb(245, 235, 255)
Note over AUSF,UE: 步骤④ 认证成功与锚定密钥
Note over AUSF: 成功→K_AUSF=MSK[256 LSB]<br/>K_SEAF=KDF(K_AUSF,"5G AKA",SN name)
AUSF-->>AMF: Authenticate Response<br/>{authResult=SUCCESS, Kseaf,<br/>EAP-Success}
AMF->>AN: N2 Downlink NAS Transport
AN->>UE: NAS Authentication Result<br/>(含 EAP-Success, ngKSI)
AMF->>UE: NAS Security Mode Command<br/>(用K_SEAF派生的K_NAS保护)
end
步骤①：AMF通过 Nausf_UEAuthentication_Assign（TS 29.509）发起，请求体里最关键的是 servingNetworkName——这是后续CK'/IK'绑定的输入，格式必须是RFC 9048定义的FQDN形式，例如 5G:mnc001.mcc460.3gppnetwork.org。AUSF随后用 Nudm_UEAuthentication_Get（TS 29.503 Clause 5.4.2）向UDM取向量，UDM/ARPF基于K生成AV。注意UDM返回的authType字段决定了走5G-AKA还是EAP-AKA'，AUSF据此决定自己是否进入EAP Server角色。
步骤②：AUSF把UDM给的RAND/AUTN封装进EAP-Request/AKA'-Challenge。这条NAS消息（TS 24.501 Clause 8.2.6.1）里，5G-AKA会带独立的RAND/AUTN IE，而EAP-AKA'RAND和AUTN只在EAP message的AT_RAND/AT_AUTN里，NAS层不重复携带——这是抓包识别两种方法的第一特征。
步骤③：UE的USIM执行UMTS AKA（输入RAND+K，输出RES/CK/IK，并验证AUTN中的SQN与MAC）。验证通过后，UE在本地完成CK'/IK'和MK的派生，再用K_aut计算AT_MAC填入EAP-Response/AKA'-Challenge，连同AT_RES一起回传。这条回传同样封装在NAS Authentication Response（TS 24.501 Clause 8.2.6.2）的EAP message里，AMF原样 PUT 给AUSF。
步骤④：AUSF验证AT_RES与自身预期的XRES*一致、AT_MAC正确，则认证成功。此刻AUSF拥有MK（因为它从UDM也拿到了CK/IK推演所需的对称输入，或直接从XRES/RES和K的镜像计算），派生MSK，取其256个最低有效位得到K_AUSF（TS 33.501 Annex A.2.1）。随后AUSF再用 K_SEAF = KDF(K_AUSF, FC=0x6E, "5G AKA"||SN name) 得到锚定密钥，连同 authResult=SUCCESS 返回给AMF。
EAP-AKA'的密钥派生是整个机制最精巧、也最容易在实现中出错的部分。它比5G-AKA多了"绑定网络名"和"MK主密钥中间层"两道工序：
flowchart TD
K["长期主密钥 K<br/>(仅USIM与ARPF持有)"]
AKAV["UMTS-AKA算法<br/>输入: RAND"]
CKIK["CK ‖ IK<br/>(各128 bit)"]
CKIKp["CK' ‖ IK'<br/>绑定servingNetworkName<br/>FC=0x20, RFC 9048"]
MK["MK 主密钥<br/>MK = SHA256(Identity‖IK'‖CK')<br/>(256 bit)"]
Kencr["K_encr 128b<br/>AT_PADDING加密"]
Kaut["K_aut 128b<br/>AT_MAC完整性"]
Kre["K_re 256b<br/>快速重认证用"]
MSK["MSK 主会话密钥<br/>(512 bit = 640 b)"]
EMSK["EMSK 扩展MSK<br/>(512 bit)"]
KAUSF["K_AUSF<br/>= MSK 256 LSB<br/>(TS 33.501 A.2.1)"]
KSEAF["K_SEAF 锚定密钥<br/>KDF(K_AUSF, FC=0x6E,<br/>'5G AKA'‖SN name)"]
KAMF["K_AMF<br/>(在SEAF/AMF派生)"]
K --> AKAV --> CKIK --> CKIKp --> MK
MK -->|FIPS186-2 PRF| Kencr
MK -->|FIPS186-2 PRF| Kaut
MK -->|FIPS186-2 PRF| Kre
MK -->|FIPS186-2 PRF| MSK
MK -->|FIPS186-2 PRF| EMSK
MSK --> KAUSF --> KSEAF --> KAMF
style MK fill:#fff3cd,stroke:#d39e00,stroke-width:2px
style KAUSF fill:#d4edda,stroke:#28a745,stroke-width:2px
style KSEAF fill:#cce5ff,stroke:#007bff,stroke-width:2px
逐段说明这套派生为什么这样设计：
CK'/IK'绑定（防降级的核心）：原始EAP-AKA（RFC 4187）的CK/IK直接来自UMTS AKA，没有网络身份绑定，理论上可以被诱导去服务一个攻击者控制的假网络。EAP-AKA'用TS 33.220定义的KDF（FC=0x20，参数P0=servingNetworkName）把CK、IK升级成CK'、IK'，使派生结果密码学地绑定到服务网络名。这样一来，即便攻击者重放质询，由于network name不匹配，UE派生出的MK也不同，AT_MAC必然校验失败。这就是AT_KDF属性存在的意义——它告诉对端"我用哪个KDF、绑定的是哪个网络名"。
MK主密钥中间层：RFC 9048规定 MK = SHA-256(Identity ‖ IK' ‖ CK')，其中Identity是16字节的永久身份（左对齐，右侧0x00填充）。这一层把"会话相关材料（IK'‖CK'）"与"身份材料（Identity）"在哈希域混合，使得MK同时具备双向认证的语义。MK之后用FIPS 186-2 PRF展开成多个子密钥。
K_AUSF = MSK的256 LSB：这是EAP体系（MSK/EMSK，各512 bit）与5G锚定密钥体系（K_AUSF，256 bit）的对接点。TS 33.501 Annex A.2.1明确取MSK的最低256位。这一选择看似随意，实则有意——MSK的高位留给其它用途（如AKMA的K_AKMA、二次认证），低位留给5G接入锚定，避免跨域密钥复用。
K_SEAF派生：从K_AUSF往上，EAP-AKA'与5G-AKA完全汇合，使用相同的KDF（FC=0x6E，输入"5G AKA"字符串+SN name）。这意味着只要认证成功，后续的K_AMF、K_gNB、K_NAS_int/enc、K_RRC_int/enc派生与切换密钥链对两种方法是无差别的。运营商在切换认证方法时，接入层与切换流程不需要任何改动。
EAP-AKA'所有语义都封装在EAP属性里，RFC 9048与TS 38.508-1 Clause 4.7.3对这些属性有精确定义。下表是抓包时最常出现的几类：
| 属性 | 方向 | 含义 | 关键要点 |
|---|---|---|---|
| AT_RAND | Server→Peer | 携带RAND（128b） | 挑战随机数，USIM输入 |
| AT_AUTN | Server→Peer | 携带AUTN（128b） | 含SQN+AMF+MAC，USIM验证网络 |
| AT_KDF | Server→Peer | KDF标识（0x01） | 标识使用绑定式派生，防降级 |
| AT_KDF_INPUT | Server→Peer | servingNetworkName及其长度 | 派生CK'/IK'的网络名输入 |
| AT_RES | Peer→Server | 携带RES | 位长限3840b，明文传输 |
| AT_MAC | 双向 | 消息完整性MAC（K_aut派生） | 发送方先填0，计算后回填 |
| AT_NEXT pseudonym | Server→Peer | 临时身份别名 | 下次full auth可用别名 |
| AT_NEXT_REAUTH_ID | Server→Peer | 重认证身份 | fast re-auth的标识 |
| AT_COUNTER | 双向 | 重认证计数器 | 防重放，每轮递增 |
| AT_CHECKCODE | 双向 | 派生密钥的校验码 | 校验KDF输入一致 |
AT_MAC的计算顺序是一个经典实现坑：发送方构造EAP消息时，AT_MAC字段先填全0，对整个EAP包用K_aut派生的密钥计算HMAC，再把结果回填进AT_MAC。接收方反之——先把AT_MAC保存、置0、校验，再读出。如果实现顺序错了，双方永远对不上MAC。
AT_RES明文性是EAP-AKA'相对5G-AKA的一个安全弱点：5G-AKA中UE回传的是RES*（对RES做了hash扩展拼接），有MAC保护；EAP-AKA'中AT_RES是明文RES。因此TS 33.501要求AT_RES的位长不能超过3840位，且实际部署中运营商应限制RES长度。
| 维度 | EAP-AKA' | 5G-AKA |
|---|---|---|
| 标准来源 | RFC 9048 + TS 33.501 A.2 | 3GPP专用，TS 33.501 6.1.3.1 |
| 报文框架 | EAP（EAP-Request/Response/Success） | NAS原生认证消息 |
| AMF角色 | EAP透传，不解析 | "半个验证者"，做MAC初步检查 |
| AUSF角色 | EAP Server | 验证者，校验XRES* |
| UE响应字段 | AT_RES（明文RES） | RES*（hash扩展） |
| 网络名绑定 | AT_KDF + AT_KDF_INPUT | ABBA + SN name |
| 快速重认证 | 支持（fast re-auth, K_re） | 不支持，每次都full auth |
| 典型应用 | 非可信非3GPP接入、跨域、企业DN | 主流移动宽带默认 |
| 失败处理 | EAP-Failure | MAC failure / Synch failure二次确认 |
| 密钥汇聚点 | K_AUSF = MSK[256 LSB] | K_AUSF直接从RES*派生 |
一个常被忽略的点：5G-AKA独有的"二次确认"机制——当AMF收到UE的Authentication Response后，AMF会用AUTN验证，若失败会把失败也反馈，让AUSF/UDM知道UE是否真的拒绝了网络；而EAP-AKA'没有这个特性，失败直接以EAP-Failure结束。这意味着在漫游场景下，如果担心"假基站诱导UE暴露拒绝行为"的隐私问题，运营商更倾向于配置5G-AKA。
EAP-AKA'独有的fast re-auth是它相对5G-AKA的显著省信令优势——当后续认证发生时（例如再次注册或某些触发条件），不必走完整的UMTS-AKA质询，而是复用上一轮派生的K_re：
stateDiagram-v2
[*] --> Initial
Initial --> FullAuth: 触发认证<br/>(无K_re)
state FullAuth {
[*] --> IdentityExch
IdentityExch --> Challenge: EAP-Request/AKA'-Challenge
Challenge --> Success: AT_RES验证通过<br/>派生MK→K_re→MSK
Success --> [*]: 下发AT_NEXT_REAUTH_ID<br/>AT_COUNTER=0
}
FullAuth --> Ready: K_re已建立
Ready --> FastReauth: 触发认证<br/>(持reauth_id)
state FastReauth {
[*] --> ReqReauth: EAP-Request/AKA'-Reauthentication<br/>(AT_COUNTER+1, AT_MAC)
ReqReauth --> Verify: UE校验AT_COUNTER
Verify --> NewMSK: 用K_re+AT_COUNTER<br/>派生新MSK→新K_AUSF
NewMSK --> [*]: EAP-Success
Verify --> FullAuth: counter异常/失败<br/>回退完全认证
}
FastReauth --> Ready: 成功,counter递增
FastReauth --> FullAuth: 重认证失败<br/>清空K_re
Fast re-auth的关键在于：新MSK由K_re与递增的AT_COUNTER再次派生，而不是重新触发USIM计算。这绕过了USIM的运算（每次full auth都要求USIM执行一次AKA），对低性能物联网USIM尤其友好。但代价是AT_COUNTER必须严格单调递增，一旦UE发现计数器回退（counter too small）或服务器校验失败，必须立即清空K_re回退到full auth——这是状态图中那条"回退"边的来源。
5G-AKA没有这个机制，每次PDU会话激活、再注册、idle态唤醒后的认证都是full auth。这就是为什么在频繁认证的M2M场景下，运营商有时会主动把签约方法配成EAP-AKA'。
links字段或eapPayload会携带Base64编码的EAP-Request；失败时 authResult 会是FAILURE。| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| AT_MAC校验失败 | servingNetworkName两边不一致 | 检查AMF配置的SN name与UE USIM/ME期望是否一致；FQDN大小写敏感 |
| 认证一直full auth，从不re-auth | UDM未下发AT_NEXT_REAUTH_ID | 检查AUSF是否在Success中携带重认证身份 |
| UE拒绝AUTN（SQN失败） | USIM的SQN超前于UDM | 触发TS 33.102的重同步流程（AUTS） |
| 抓包看到AT_KDF=0x00 | 对端试图用旧EAP-AKA（无绑定） | 拒绝并要求0x01，这是降级攻击征兆 |
| EAP方法被错配成5G-AKA | UDM签约Authentication Method字段 | 核对UDM用户profile |
| ## 九、常见问题 |
Q1：既然都派生出K_SEAF，为什么5G不统一用一种方法？ A：因为它们服务不同的生态。EAP-AKA'让运营商能复用AAA/EAP基础设施（Wi-Fi互通、企业DN二次认证、untrusted non-3GPP接入认证都天然走EAP），而5G-AKA是为3GPP原生接入优化的精简流程（信令少、有二次确认）。保留两条路径是架构灵活性的体现，运营商按用户profile选择。
Q2：EAP-AKA'的AT_RES明文传输，安全性是否弱于5G-AKA的RES*？ A：在"被动窃听抗分析"维度上确实弱一点——5G-AKA的RES*是hash扩展且受MAC保护，EAP-AKA'的AT_RES是明文。但EAP-AKA'有K_aut保护的AT_MAC做完整性兜底，且AT_RES位长受限。R16之后对AT_RES的隐私增强一直是讨论热点。
Q3：AT_KDF和AT_KDF_INPUT各自的作用？ A：AT_KDF标识KDF版本（0x01=绑定式，0x00=旧式，应拒绝），AT_KDF_INPUT携带绑定的servingNetworkName。二者配合实现"网络名绑定"，是EAP-AKA'区别于EAP-AKA、抵御降级攻击的密码学根基。如果抓包看到AT_KDF=0x00，应视为可疑。
Q4：fast re-auth为什么能省信令？它安全吗？ A：fast re-auth复用上一轮的K_re，配合单调递增的AT_COUNTER派生新MSK，绕过了USIM的完整AKA运算。安全性依赖AT_COUNTER的单调性——一旦发现回退就清空K_re回退full auth，因此只要counter逻辑实现正确是安全的，且特别适合物联网低性能USIM。
Q5：切换认证方法（5G-AKA↔EAP-AKA'）对用户感知有影响吗？ A：无感知。两种方法在K_AUSF之上完全汇合（K_SEAF及以下派生一致），所以一旦认证成功，NAS/接入层安全上下文、切换密钥链都是同一套。影响仅在认证阶段的信令条数与延迟（EAP-AKA'略多一轮EAP交互）。
本文由「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 等场景全覆盖。