4G EPS-AKA存在一个重大安全缺陷:归属网络无法确认拜访网络是否真正完成了UE认证。MME在收到HSS返回的认证向量后,自行执行认证并向UE转发,整个过程中归属网络处于"盲区"——它无法验证UE是否真的回应了挑战。攻击者可以利用这一缺陷,通过伪基站发动IMSI捕获攻击。
5G-AKA(定义于TS 33.501 Section 6.1.3.2)对此进行了根本性重构:引入AUSF(认证服务器功能)和SEAF(安全锚点功能)两层网元,实现归属网络对认证结果的端到端确认。同时,SUCI(用户隐藏标识符)替代了明文IMSI,从根本上消除了空口身份暴露的风险。
本文将基于TS 33.501 V18.10.0,逐步拆解5G-AKA的完整信令流、密钥推演链、以及与EAP-AKA'的关键差异。
在深入信令流之前,必须先理解每个安全网元的职责边界。
| 网元 | 协议位置 | 核心职责 | 密钥持有 |
|---|---|---|---|
| UE/USIM | TS 33.501 §6.1 | 存储长期密钥K,计算RES*,验证AUTN | K → CK, IK → RES* |
| SEAF(驻留在AMF) | TS 33.501 §6.1.1.2 | 发起认证请求,执行HXRES*本地验证 | KSEAF → KAMF |
| AUSF | TS 33.501 §6.1.3.2 | 验证RES*,向归属网络提供认证证据 | KAUSF → KSEAF |
| UDM | TS 33.501 §6.1.2 | 选择认证方法(5G-AKA或EAP-AKA') | 通过ARPF间接持有K |
| ARPF(驻留在UDM) | TS 33.501 §6.1.1.1 | 存储长期密钥K,生成5G HE AV | K → RAND, AUTN, XRES*, KAUSF |
| SIDF(驻留在UDM) | TS 33.501 §6.12 | 解密SUCI还原SUPI | ECIES私钥 |
设计意图:4G中MME既当运动员又当裁判——它发起认证、执行认证、还汇报结果。5G将认证验证权上收到归属网络(AUSF),拜访网络(SEAF/AMF)只能做"预检",无法伪造认证成功。
graph TB
subgraph 归属网络["归属网络 (Home Network)"]
UDM["UDM<br/>选择认证方法"]
ARPF["ARPF<br/>存储K, 生成5G HE AV"]
SIDF["SIDF<br/>解密SUCI→SUPI"]
AUSF["AUSF<br/>验证RES*, 生成KSEAF"]
UDM --- ARPF
UDM --- SIDF
end
subgraph 拜访网络["拜访网络 (Serving Network)"]
SEAF["SEAF (AMF)<br/>发起认证, HXRES*预检"]
AMF["AMF<br/>NAS安全模式控制"]
SEAF --- AMF
end
subgraph 终端["终端侧"]
UE["UE/USIM<br/>存储K, 计算RES*"]
end
UE -- "SUCI/RAND/AUTN<br/>(NAS信令)" --> SEAF
SEAF -- "Nausf_UEAuthentication" --> AUSF
AUSF -- "Nudm_UEAuthentication_Get" --> UDM
ARPF -- "5G HE AV" --> AUSF
以下是基于TS 33.501 Section 6.1.3.2的完整信令流程。与4G EPS-AKA最大的区别在于步骤⑦-⑪的双重验证机制。
sequenceDiagram
participant UE as UE/USIM
participant SEAF as SEAF(AMF)
participant AUSF as AUSF
participant UDM as UDM/ARPF
Note over UE,SEAF: ① Registration Request
UE->>SEAF: Registration Request<br/>(SUCI or 5G-GUTI)
Note over SEAF,AUSF: ② SEAF发起认证请求
SEAF->>AUSF: Nausf_UEAuthentication_Authenticate Request<br/>(SUCI/SUPI, servingNetworkName)
Note over AUSF,UDM: ③ AUSF向UDM请求认证数据
AUSF->>UDM: Nudm_UEAuthentication_Get Request<br/>(SUPI, servingNetworkName)
Note over UDM: ④ UDM/ARPF生成5G HE AV<br/>RAND, AUTN, XRES*, KAUSF
UDM-->>AUSF: Nudm_UEAuthentication_Get Response<br/>(5G HE AV: RAND, AUTN, HXRES*, KAUSF)
Note over AUSF: ⑤ AUSF存储HXRES*用于后续验证
AUSF-->>SEAF: Nausf_UEAuthentication_Authenticate Response<br/>(5G SE AV: RAND, AUTN, HXRES*)
Note over SEAF: ⑤' SEAF存储HXRES*用于本地预检
SEAF->>UE: Authentication Request<br/>(RAND, AUTN, ngKSI, ABBA)
Note over UE: ⑥ UE/USIM处理<br/>a) 验证AUTN(网络认证)<br/>b) 从K计算CK,IK<br/>c) 计算RES*<br/>d) 推导KAUSF, KSEAF
UE->>SEAF: Authentication Response<br/>(RES*)
Note over SEAF: ⑦ SEAF本地预检<br/>计算HXRES* = SHA-256(RES* || RAND)<br/>比较HXRES*与存储的HXRES*
alt HXRES*验证失败
SEAF->>AUSF: Nausf_UEAuthentication_Authenticate Request<br/>(Auth Failure)
AUSF-->>SEAF: Authentication Failure
else HXRES*验证通过
Note over SEAF,AUSF: ⑧ SEAF向AUSF确认
SEAF->>AUSF: Nausf_UEAuthentication_Authenticate Request<br/>(RES*, servingNetworkName)
Note over AUSF: ⑨ AUSF执行归属网络验证<br/>比较XRES*与RES*
alt XRES*验证通过
Note over AUSF: ⑩ 认证成功,推导KSEAF
AUSF-->>SEAF: Nausf_UEAuthentication_Authenticate Response<br/>(Auth Success, KSEAF, SUPI)
Note over SEAF: ⑪ SEAF推导KAMF
else XRES*验证失败
AUSF-->>SEAF: Nausf_UEAuthentication_Authenticate Response<br/>(Auth Failure)
end
end
UE在Registration Request中携带SUCI而非明文SUPI。SUCI通过ECIES(Elliptic Curve Integrated Encryption Scheme)加密生成(TS 33.501 §6.12):
| IE参数 | 含义 | 格式示例 |
|---|---|---|
| SUCI | 隐藏的用户标识 | suci-0-460-11-0-0-<加密部分> |
| Registration Type | 注册类型 | Initial Registration / Mobility Registration |
| 5G-GUTI | 临时标识(如有) | 5G-GUTI-0-460-11-... |
SUCI结构(TS 23.003 §28.7.3):
SUCI = <supi-type> <mcc> <mnc> <routing-indicator> <protection-scheme-id> <home-network-pk-id> <scheme-output>
其中<scheme-output>包含ECIES加密后的SUPI。SIDF(SUPI解密功能)驻留在UDM中,使用对应的ECIES私钥解密。
设计意图:4G中IMSI在空口以明文传输,伪基站可通过"Identity Request"主动索取IMSI。5G的SUCI使得即使攻击者截获了空口信令,也无法还原SUPI。
Nausf_UEAuthentication_Authenticate Request(SBI接口,TS 29.509):
| 参数 | 来源 | 说明 |
|---|---|---|
suciOrSupi |
UE注册请求 | SUCI或已解密的SUPI |
servingNetworkName |
AMF配置 | 格式:5G:mnc<mnc>.mcc<mcc>.3gppnetwork.org |
resynchronizationInfo |
可选 | 当UE返回AUTS时携带,用于SQN重同步 |
Nudm_UEAuthentication_Get Request(SBI接口,TS 29.503):
AUSF将SUCI/SUPI和servingNetworkName转发给UDM。UDM首先判断:
- 如果收到SUCI → 调用SIDF解密为SUPI
- 根据SUPI查询订阅数据 → ARPF选择认证方法
- 根据subscription data中的authMethod字段决定使用5G-AKA还是EAP-AKA'
ARPF执行以下密码学计算(TS 33.501 §6.1.3.2, Annex A.2):
输入:长期密钥K, SQN(序列号)
① 传统AKA计算(与4G相同):
RAND = 随机数(128 bit)
f1~f5* 算法(通常为Milenage)
AUTN = SQN ⊕ AK || AMF || MAC
XRES = f2(K, RAND) // 期望响应
CK = f3(K, RAND) // 加密密钥
IK = f4(K, RAND) // 完整性密钥
AK = f5*(K, RAND) // 匿名密钥
② 5G扩展计算:
XRES* = XRES || RAND // 扩展XRES(绑定RAND防止重放)
KAUSF = KDF(CK || IK,
0x6A || SN_id || L_SN_id ||
SQN ⊕ AK || L_SQN⊕AK) // FC=0x6A
HXRES* = SHA-256(RAND || XRES*) // 归属网络期望的哈希响应
关键设计:XRES*将XRES与RAND绑定,确保每次认证的期望响应都不同。HXRES*允许SEAF在不暴露XRES*的情况下执行本地预检。
ARPF生成的5G HE AV(Home Environment Authentication Vector)包含:
- RAND:128-bit随机挑战
- AUTN:128-bit网络认证令牌
- HXRES*:期望哈希响应(用于SEAF预检)
- KAUSF:AUSF密钥
AUSF收到后:
1. 存储HXRES*用于步骤⑨的比对
2. 构造5G SE AV(Serving Environment AV)返回给SEAF:
- RAND + AUTN + HXRES*
- 不包含KAUSF和XRES*(最小权限原则)
SEAF收到5G SE AV后存储HXRES*。
UE收到Authentication Request后,USIM执行:
① 从AUTN中提取SQN ⊕ AK, AMF, MAC
② 用本地K计算f1~f5*
③ 验证MAC == XMAC(验证网络真实性)
④ 检查SQN是否在有效窗口(防重放)
⑤ 计算RES = f2(K, RAND)
⑥ 计算5G扩展:
RES* = RES || RAND
KAUSF = KDF(CK || IK, 0x6A || SN_id || SQN⊕AK) // 与网络侧相同
KSEAF = KDF(KAUSF, 0x6C || SUPI || L_SUPI) // FC=0x6C
AUTN验证失败的处理:如果SQN不在有效窗口,UE返回
AUTS(Authentication Failure with SYNCH failure),触发UDM/ARPF执行SQN重同步过程(TS 33.501 §6.1.3.3)。
flowchart TD
A["SEAF收到RES*"] --> B["计算 HXRES* = SHA-256(RAND || RES*)"]
B --> C{"HXRES* == 存储的HXRES*?"}
C -->|否| D["❌ 认证失败<br/>向AUSF报告失败<br/>不转发RES*"]
C -->|是| E["✅ 本地预检通过<br/>将RES*转发给AUSF"]
E --> F["AUSF执行最终验证"]
style D fill:#ff6b6b,color:#fff
style E fill:#51cf66,color:#fff
style F fill:#339af0,color:#fff
这是5G-AKA相对于4G EPS-AKA的核心增强:
| 对比项 | 4G EPS-AKA | 5G-AKA |
|---|---|---|
| 拜访网络验证 | 无(MME直接比对RES==XRES) | SEAF计算HXRES*进行本地预检 |
| 归属网络验证 | 无(MME自行决定认证结果) | AUSF比对XRES*与RES* |
| RES传输 | MME已知XRES,自行比对 | SEAF不知XRES*,必须转发给AUSF |
| 安全保障 | 依赖拜访网络诚实性 | 归属网络独立确认认证结果 |
AUSF收到RES*后执行最终验证:
① 比较 RES* 与 XRES*
② 若匹配:
- 标记认证成功
- 推导 KSEAF = KDF(KAUSF, 0x6C || SUPI || L_SUPI)
- 返回 {KSEAF, SUPI} 给SEAF
③ 若不匹配:
- 标记认证失败
- 返回失败结果
5G密钥层级是理解整个安全架构的骨架。每一层密钥的推导都有明确的输入参数和KDF函数编码。
graph TD
K["K<br/>(长期主密钥, 128/256bit)<br/>存储于USIM和ARPF"]
K -->|"Milenage算法<br/>f2,f3,f4,f5*"| AKA["CK || IK<br/>(加密+完整性密钥)"]
AKA -->|"KDF FC=0x6A<br/>P1=SN_id<br/>P2=SQN⊕AK"| KAUSF["KAUSF<br/>(AUSF密钥)<br/>共享: UE ↔ AUSF"]
KAUSF -->|"KDF FC=0x6C<br/>P1=SUPI"| KSEAF["KSEAF<br/>(安全锚点密钥)<br/>共享: UE ↔ SEAF"]
KSEAF -->|"KDF FC=0x6D<br/>P1=SUPI<br/>P2=ABBA"| KAMF["KAMF<br/>(AMF锚点密钥)<br/>共享: UE ↔ AMF"]
KAMF -->|"KDF FC=0x69<br/>P1=algorithm type<br/>P2=NAS uplink count"| KNAS_INT["KNAS-int<br/>(NAS完整性密钥)"]
KAMF -->|"KDF FC=0x69<br/>P1=algorithm type<br/>P2=NAS uplink count"| KNAS_ENC["KNAS-enc<br/>(NAS加密密钥)"]
KAMF -->|"KDF FC=0x6E<br/>P1=access type"| KgNB["KgNB<br/>(gNB密钥)"]
KgNB -->|"KDF FC=0x69"| KRRC_INT["KRRC-int<br/>(RRC完整性密钥)"]
KgNB -->|"KDF FC=0x69"| KRRC_ENC["KRRC-enc<br/>(RRC加密密钥)"]
KgNB -->|"KDF FC=0x69"| KUP_ENC["KUP-enc<br/>(用户面加密密钥)"]
KgNB -->|"KDF FC=0x69"| KUP_INT["KUP-int<br/>(用户面完整性密钥)"]
style K fill:#e03131,color:#fff
style KAUSF fill:#f08c00,color:#fff
style KSEAF fill:#2b8a3e,color:#fff
style KAMF fill:#1971c2,color:#fff
style KgNB fill:#6741d9,color:#fff
| 密钥 | KDF FC | 输入参数 | 输出长度 | TS 33.501章节 |
|---|---|---|---|---|
| KAUSF | 0x6A | CK‖IK, SN_id, SQN⊕AK | 256 bit | Annex A.2 |
| KSEAF | 0x6C | KAUSF, SUPI | 256 bit | Annex A.3 |
| KAMF | 0x6D | KSEAF, SUPI, ABBA | 256 bit | Annex A.4 |
| KNAS-int | 0x69 | KAMF, algorithm type distinguisher, NAS uplink COUNT | 128/256 bit | Annex A.7 |
| KNAS-enc | 0x69 | KAMF, algorithm type distinguisher, NAS uplink COUNT | 128/256 bit | Annex A.7 |
| KgNB | 0x6E | KAMF, access type(3GPP) | 256 bit | Annex A.10 |
| KRRC-int | 0x69 | KgNB, algorithm type, COUNT | 128/256 bit | Annex A.9 |
| KRRC-enc | 0x69 | KgNB, algorithm type, COUNT | 128/256 bit | Annex A.9 |
| KUP-enc | 0x69 | KgNB, algorithm type, COUNT | 128/256 bit | Annex A.9 |
| KUP-int | 0x69 | KgNB, algorithm type, COUNT | 128/256 bit | Annex A.9 |
所有KDF均使用HMAC-SHA-256(TS 33.501 Annex A.1),通用格式为:
Key = HMAC-SHA-256(Key_input, FC || P0 || L0 || P1 || L1 || ...)
ABBA(Anti-Bidding Down Between Architectures)是一个关键的安全参数,用于防止从5G安全架构降级到4G。ABBA参数在KAMF推导中作为输入,确保即使攻击者试图让UE认为网络是4G的,密钥也无法被重用。
| ABBA值 | 含义 |
|---|---|
0x0000 |
5G安全上下文(默认) |
| 其他值 | 保留 |
认证完成后,AMF通过NAS Security Mode Command激活NAS安全上下文(TS 24.501 §5.4.2.2):
sequenceDiagram
participant AMF
participant UE
Note over AMF: AMF已获得KAMF<br/>选择NAS安全算法
AMF->>UE: NAS Security Mode Command<br/>(selectedAlgorithms, ngKSI,<br/>replayOfSNSSAIList, replayOfAllowedTACList)
Note over AMF: 使用KNAS-int进行完整性保护<br/>该消息尚未加密(首次激活)
Note over UE: UE验证完整性MAC<br/>推导KNAS-int, KNAS-enc<br/>存储ngKSI映射的安全上下文
UE->>AMF: NAS Security Mode Complete<br/>(IMEISV, NAS message container)
Note over UE,AMF: 从此刻起,后续NAS消息<br/>使用KNAS-enc加密 + KNAS-int完整性保护
NAS安全算法协商表(TS 33.501 Annex D):
| 算法类型 | 算法标识 | 说明 |
|---|---|---|
| NEA0 | 0x0 | 空加密(仅用于紧急呼叫) |
| 128-NEA1 | 0x1 | 基于SNOW 3G |
| 128-NEA2 | 0x2 | 基于AES |
| 128-NEA3 | 0x3 | 基于ZUC(国密算法) |
| NIA0 | 0x0 | 空完整性(不允许用于正常注册) |
| 128-NIA1 | 0x1 | 基于SNOW 3G |
| 128-NIA2 | 0x2 | 基于AES |
| 128-NIA3 | 0x3 | 基于ZUC |
AMF根据UE的安全能力(在Registration Request中携带)和运营商策略选择算法。NIA0(空完整性)不允许用于正常注册流程。
TS 33.501定义了两种主认证方法,分别适用于不同接入类型:
graph LR
subgraph 3GPP接入["3GPP接入 (NR/LTE)"]
A1["5G-AKA<br/>NAS承载"]
end
subgraph 非3GPP接入["非3GPP接入 (Wi-Fi/可信)"]
A2["EAP-AKA'<br/>EAP框架承载"]
end
A1 --> KSEAF1["→ KSEAF → KAMF"]
A2 --> KSEAF2["→ KSEAF → KAMF"]
KSEAF1 --> SAME["相同的密钥层级"]
KSEAF2 --> SAME
| 对比维度 | 5G-AKA | EAP-AKA' |
|---|---|---|
| 适用接入 | 3GPP接入(NR/LTE通过N1 NAS) | 非3GPP接入(Wi-Fi通过N2/Y2) |
| 协议框架 | 原生NAS challenge-response | EAP框架(RFC 5448/9048) |
| 消息载体 | Authentication Request/Response(NAS) | EAP-Request/Response(封装在IKEv2或N2中) |
| RES格式 | RES* = RES ‖ RAND | EAP-Response/AKA'-Challenge(RES + MAC) |
| 密钥绑定 | KDF FC=0x6A绑定SN_id和SQN⊕AK | KDF'绑定网络名到CK'/IK'推导 |
| 归属网络确认 | AUSF验证RES*(强制) | AUSF作为EAP Server验证RES(强制) |
| SUCI支持 | ✅ 原生支持 | ⚠️ 有限支持(可用pseudonym) |
| KSEAF推导 | 从KAUSF推导(FC=0x6C) | 从MSK(CK'‖IK')推导 |
| TS章节 | §6.1.3.2 | §6.1.3.1 |
核心差异:EAP-AKA'的密钥推导引入了网络名绑定(将serving network name作为CK'/IK'推导的输入),这是RFC 5448相对于原始EAP-AKA的关键增强。而5G-AKA通过KAUSF推导时的SN_id输入实现等效的绑定效果。
5G-AKA认证流程在抓包中涉及两层协议:
| 接口 | 协议 | 过滤器 | 关键字段 |
|---|---|---|---|
| Uu空口 | 5G-NAS (DL/UL) | nas-5gs.msg_type == 0x56 (Auth Request) |
RAND, AUTN, ngKSI |
| Uu空口 | 5G-NAS (DL/UL) | nas-5gs.msg_type == 0x57 (Auth Response) |
RES* |
| N1 (NAS) | 5G-NAS | nas-5gs.security_header_type |
完整性/加密标识 |
| SBI (Nausf) | HTTP/2 | http2.headers.path contains "nausf" |
JSON body中的SUCI/RES* |
| SBI (Nudm) | HTTP/2 | http2.headers.path contains "nudm" |
JSON body中的5G HE AV |
Auth Request的Wireshark解码:
5G NAS Mobility Management
Message Type: Authentication Request (0x56)
ngKSI: 0x05 (Security Context 5)
ABBA: 0x0000
Authentication Parameter RAND: 0x1234567890abcdef...
Authentication Parameter AUTN: 0xaabbccdd...
| 故障现象 | 根因 | 排查步骤 |
|---|---|---|
| Auth Failure #3GPP cause=20 (MAC failure) | UE计算的XMAC与AUTN中的MAC不匹配 | 检查USIM中的K值与UDM/ARPF中的K值是否一致 |
| Auth Failure #3GPP cause=21 (SQN failure) | USIM中的SQN与ARPF中的SQN不同步 | 检查UE返回的AUTS值,触发UDM重同步 |
| AUSF返回Auth Failure | RES*≠XRES* | 检查USIM与ARPF的K值、算法配置是否一致 |
| SEAF预检失败 | HXRES*不匹配 | 检查SEAF的SHA-256计算是否正确 |
| SUCI解密失败 | SIDF中的ECIES私钥不匹配 | 检查运营商PKI配置,USIM中的公钥哈希 |
| NAS SMC失败 | 算法协商不一致 | 检查UE安全能力与AMF策略配置 |
| ## 八、5G-AKA安全状态机 |
UE在认证过程中经历的状态转换如下(TS 33.501 §6.1.3.2.0):
stateDiagram-v2
[*] --> DEREGISTERED: 初始状态
DEREGISTERED --> AUTH_INITIATED: 收到Auth Request(RAND,AUTN)
state AUTH_INITIATED {
[*] --> AUTN_VERIFY: 验证AUTN
AUTN_VERIFY --> MAC_CHECK: 提取并计算XMAC
MAC_CHECK --> SQN_CHECK: MAC匹配
MAC_CHECK --> AUTH_FAIL_MAC: MAC不匹配
SQN_CHECK --> COMPUTE_RES: SQN有效
SQN_CHECK --> AUTH_FAIL_SYNC: SQN不同步
COMPUTE_RES --> SEND_RES: 计算RES*,KAUSF,KSEAF
SEND_RES --> WAIT_RESULT: 发送Auth Response
}
AUTH_INITIATED --> SECURITY_ACTIVE: 收到NAS SMC<br/>(认证成功)
AUTH_INITIATED --> DEREGISTERED: 认证失败
SECURITY_ACTIVE --> REGISTERED: NAS SMC Complete
REGISTERED --> SECURITY_ACTIVE: 服务请求(已有上下文)
REGISTERED --> DEREGISTERED: 去注册
| # | 增强项 | 4G EPS-AKA | 5G-AKA | 安全收益 |
|---|---|---|---|---|
| 1 | 归属网络确认 | MME自行判定认证结果 | AUSF独立验证RES* | 防止拜访网络伪造认证 |
| 2 | 空口身份保护 | IMSI明文传输 | SUCI加密传输 | 防止IMSI捕获攻击 |
| 3 | 服务网络绑定 | SN_id仅在KASME推导中使用 | SN_id在KAUSF推导中使用(更早绑定) | 防止跨网密钥重用 |
| 4 | ABBA降级防护 | 无 | ABBA参数参与KAMF推导 | 防止5G→4G安全降级 |
| 5 | 密钥分离 | KASME直接用于所有安全域 | KAUSF→KSEAF→KAMF三级分离 | 更细粒度的密钥隔离 |
尽管5G-AKA做了大量增强,学术界仍发现了若干可利用的攻击面:
Q1: HXRES*和XRES*的区别是什么?为什么需要双重验证?
A: HXRES* = SHA-256(RAND ‖ XRES*),是XRES*的哈希摘要。它由ARPF生成,经AUSF传递给SEAF。SEAF用收到的RES*计算HXRES* = SHA-256(RAND ‖ RES*),与存储值比对。这是"本地预检",目的有两个:(1)快速过滤无效响应,避免向AUSF发送无意义的验证请求;(2)即使SEAF被攻破,攻击者也无法从HXRES*反推出XRES*。最终的安全决策权在AUSF(归属网络)手中。
Q2: 5G-AKA中的SQN重同步是如何工作的?
A: 当UE检测到SQN不在有效窗口时,UE返回AUTS(Authentication Failure, cause=21, SYNCH failure)。AUTS中包含UE当前的SQN(经AK'加密保护)。UDM/ARPF收到AUTS后解密出UE的SQN,如果该值在合理范围内,ARPF更新本地SQN并重新生成认证向量。注意:ARPF不会无条件接受UE的SQN,而是有一个"宽松窗口"(通常比正常窗口大),防止攻击者通过伪造AUTS来强制SQN重置。
Q3: 为什么5G-AKA不直接使用EAP-AKA'统一所有接入?
A: 设计选择基于三个原因:(1)性能:5G-AKA是精简的challenge-response,消息交互少(2个来回),EAP框架需要更多消息;(2)兼容性:3GPP接入已有成熟的NAS安全机制,无需EAP封装开销;(3)分离关注点:3GPP接入的安全由3GPP完全控制,非3GPP接入需要与IETF EAP生态互通。两者最终都收敛到相同的KSEAF→KAMF密钥层级。
Q4: KDF中的FC编号为什么是不连续的(0x6A, 0x6C, 0x6D, 0x6E)?
A: FC(Function Code)编号的分配是按时间顺序的。在TS 33.501的演进过程中,某些FC编号被分配后又被废弃或重新定义。0x6B就曾用于一个已移除的功能。编号不连续不影响安全性——重要的是每个FC值全局唯一,确保不同密钥推导的输入参数不同。
Q5: 国密算法(128-NEA3/128-NIA3,基于ZUC)在5G-AKA中的使用有何特殊考虑?
A: 128-NEA3/NIA3基于祖冲之(ZUC)算法,是中国运营商的必选算法。在KDF推导过程中,算法类型不影响密钥推导本身——KAMF、KgNB的推导与算法选择无关。算法差异仅体现在最终使用密钥的加解密/完整性校验模块中。UE在Registration Request中通过UESecurityCapability IE上报支持的算法列表,AMF根据运营商策略选择。如果UE只支持NEA0+NEA3而AMF只配置了NEA2,将导致NAS SMC失败。
本文由「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 等场景全覆盖。
