首页 › security › 5G-AKA主认证与密钥推演全链拆解

5G-AKA主认证与密钥推演全链拆解

引言:为什么5G必须重新设计AKA

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'的关键差异。


一、5G-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

二、5G-AKA完整信令时序图

以下是基于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

三、逐步信令消息深度解析

步骤①:Registration Request — SUCI保护的身份传递

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。

步骤②-③:SEAF→AUSF→UDM 认证请求链

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生成5G HE AV — 核心密码学操作

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侧认证处理 — 双重校验

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)。

步骤⑦:SEAF本地预检 — 5G新增的关键防线

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参数说明

ABBA(Anti-Bidding Down Between Architectures)是一个关键的安全参数,用于防止从5G安全架构降级到4G。ABBA参数在KAMF推导中作为输入,确保即使攻击者试图让UE认为网络是4G的,密钥也无法被重用。

ABBA值 含义
0x0000 5G安全上下文(默认)
其他值 保留

五、NAS安全模式控制 — 密钥激活

认证完成后,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(空完整性)不允许用于正常注册流程。


六、5G-AKA vs EAP-AKA':两种认证方法对比

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输入实现等效的绑定效果。


七、抓包识别与故障排查

7.1 Wireshark抓包识别

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...

7.2 常见故障点与排错

故障现象 根因 排查步骤
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: 去注册

九、5G-AKA安全增强总结

9.1 相对于4G EPS-AKA的五大增强

# 增强项 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三级分离 更细粒度的密钥隔离

9.2 已知安全局限

尽管5G-AKA做了大量增强,学术界仍发现了若干可利用的攻击面:

  1. 链接攻击(Linkability Attack):攻击者可通过重放之前的Authentication Request来检测特定UE是否在线(TS 33.501未完全防御)
  2. SQN泄露:AUTN中的SQN⊕AK仍可被用于追踪(尽管需要知道AK)
  3. 占用攻击(Bidding Down):如果UE和网络不支持NEA3/NIA3,可能被迫使用较弱算法

常见问题

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失败。


参考来源

  1. 3GPP TS 33.501 V18.10.0 — Security architecture and procedures for 5G System — Sections 6.1.3.2, 6.2, Annex A
  2. Introduction to 5G AKA — free5GC — 5G AKA协议流程与free5GC实现解析
  3. 5G Authentication and Key Management — Techplayon — 5G-AKA认证向量生成与密钥管理详解
  4. 5G NR Key Derivation Procedure — 3glteinfo — 5G安全密钥层级与推导参数说明
  5. 5G Security — ShareTechnote — NAS安全模式控制与AS安全流程图解
  6. TS 33.501 Section 6.1.3.2 — iTecSpec — 5G AKA规范原文索引
  7. 5G Authentication — Devopedia — 5G认证方法对比与安全架构综述

本文由「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 等场景全覆盖。

51学通信知识星球海报-扫码加入