首页 › security › 5G-AKA与EAP-AKA'双轨认证机制拆解

5G-AKA与EAP-AKA'双轨认证机制拆解:从SUCI加密到密钥层级全链推演

5G系统引入了全新的安全架构,最核心的变化之一是在主认证(Primary Authentication)层面同时支持 5G-AKA 和 EAP-AKA' 两种认证方法。这两种方法虽然都基于相同的长期密钥K,但在协议封装、密钥推演路径、认证向量构造和归属网络控制粒度上存在根本性差异。本文基于 3GPP TS 33.501 V18.9.0 Section 6.1及Annex A/C,逐信令消息拆解双轨认证的完整机制。

一、5G主认证框架总览(TS 33.501 Section 6.1.1)

1.1 设计目标与架构角色

5G主认证的核心目标是实现UE与网络之间的双向认证,并生成锚点密钥 K~SEAF~(Security Anchor Function Key)。整个认证框架由以下安全功能节点协作完成:

功能节点 英文全称 核心职责
SEAF Security Anchor Function 与AMF共部署,作为服务网络的认证锚点
AUSF Authentication Server Function 归属网络认证服务器,验证UE响应
UDM/ARPF Unified Data Management / Authentication Credential Repository and Processing Function 存储长期密钥K,生成认证向量
SIDF Subscription Identifier De-concealing Function UDM内嵌功能,从SUCI解密出SUPI

关键设计原则(TS 33.501 Section 6.1.1.1):

1.2 EAP框架映射(Section 6.1.1.2)

当使用EAP-AKA'时,5G系统对RFC 3748定义的EAP框架角色映射如下:

graph TD
    UE["UE<br/>(EAP Peer)"] -->|"EAP-Request/Response<br/>经NAS透传"| SEAF["SEAF/AMF<br/>(Pass-through<br/>Authenticator)"]
    SEAF -->|"Nausf_UEAuthentication<br/>SBI服务"| AUSF["AUSF<br/>(Backend<br/>Authentication Server)"]
    AUSF -->|"Nudm_UEAuthentication_Get"| UDM["UDM/ARPF<br/>(凭证仓库)"]

    style UE fill:#4CAF50,color:white
    style SEAF fill:#2196F3,color:white
    style AUSF fill:#FF9800,color:white
    style UDM fill:#9C27B0,color:white

关键区别:5G-AKA不使用EAP框架,而是直接通过NAS层的Authentication Request/Response消息完成质询-应答;EAP-AKA'则在NAS消息内封装EAP包,SEAF做透传。

二、认证发起与方法选择(TS 33.501 Section 6.1.2)

2.1 发起条件

SEAF可以在任何建立信令连接的过程中发起认证(如注册、服务请求),核心流程如下:

sequenceDiagram
    participant UE
    participant SEAF as SEAF/AMF
    participant AUSF
    participant UDM as UDM/ARPF

    UE->>SEAF: Registration Request<br/>(含SUCI或5G-GUTI)
    SEAF->>AUSF: Nausf_UEAuthentication_Authenticate Request<br/>(SUCI/SUPI + serving network name)
    AUSF->>AUSF: 验证SEAF是否有权使用<br/>该serving network name
    AUSF->>UDM: Nudm_UEAuthentication_Get Request<br/>(SUCI/SUPI + SN-Name)
    UDM->>UDM: SIDF解密SUCI→SUPI<br/>(如收到SUCI)
    UDM->>UDM: ARPF选择认证方法<br/>(5G-AKA或EAP-AKA')
    UDM-->>AUSF: Nudm_UEAuthentication_Get Response<br/>(认证向量+方法指示)

方法选择逻辑(Section 6.1.2原文): - 认证方法由归属网络运营商决定,基于SUPI选择 - AUSF需验证SEAF使用的serving network name是否被授权(通过3gpp-Sbi-Originating-Network-Id头校验) - SEAF发送的请求必须包含serving network name

2.2 Serving Network Name构造(Section 6.1.1.4)

serving network name的构造规则对两种认证方法都至关重要——它直接参与密钥推演:

Serving Network Name = "5G:" + SN Id

其中SN Id标识服务PLMN(定义在TS 24.501),格式示例:5G:mnc070.mcc460.3gppnetwork.org

设计意图:将serving network name纳入KDF输入,实现锚点密钥与服务网络的密码学绑定,防止一个服务网络伪装成另一个(Section 6.1.1.3)。

三、5G-AKA认证信令全链拆解(Section 6.1.3.2)

3.1 完整信令时序图

sequenceDiagram
    participant UE as UE (USIM+ME)
    participant SEAF as SEAF/AMF
    participant AUSF as AUSF
    participant UDM as UDM/ARPF

    rect rgb(240,248,255)
    Note over UE,UDM: 阶段一:认证向量生成
    SEAF->>AUSF: ① Nausf_UEAuthentication_Authenticate Request<br/>SUCI/SUPI, SN-Name
    AUSF->>UDM: ② Nudm_UEAuthentication_Get Request<br/>SUCI/SUPI, SN-Name
    UDM->>UDM: ③ SIDF解密SUCI→SUPI<br/>生成AV(RAND,AUTN,CK,IK,XRES)<br/>AMF separation bit=1<br/>推导K_AUSF(Annex A.2)<br/>计算XRES*(Annex A.4)<br/>构造5G HE AV
    UDM-->>AUSF: ④ Nudm_UEAuthentication_Get Response<br/>5G HE AV(RAND,AUTN,XRES*,K_AUSF)<br/>+ SUPI + 方法指示=5G AKA
    end

    rect rgb(255,248,240)
    Note over UE,AUSF: 阶段二:服务网络认证向量处理
    AUSF->>AUSF: ⑤ 存储XRES*+SUCI/SUPI<br/>计算HXRES*(Annex A.5)<br/>计算K_SEAF(Annex A.6)<br/>构造5G SE AV
    AUSF-->>SEAF: ⑥ Nausf_UEAuthentication_Authenticate Response<br/>5G SE AV(RAND,AUTN,HXRES*)
    end

    rect rgb(240,255,240)
    Note over UE,SEAF: 阶段三:UE质询-应答
    SEAF->>UE: ⑦ NAS Authentication Request<br/>RAND, AUTN, ngKSI, ABBA
    UE->>UE: ⑧ USIM验证AUTN→计算RES<br/>ME计算RES*(Annex A.4)<br/>计算K_AUSF(A.2)→K_SEAF(A.6)
    UE-->>SEAF: ⑨ NAS Authentication Response<br/>RES*
    SEAF->>SEAF: ⑩ 计算HRES*(Annex A.5)<br/>比较HRES* vs HXRES*
    end

    rect rgb(255,240,255)
    Note over SEAF,AUSF: 阶段四:归属网络确认
    SEAF->>AUSF: ⑪ Nausf_UEAuthentication_Authenticate Request<br/>RES*
    AUSF->>AUSF: ⑫ 比较RES* vs XRES*<br/>通知UDM认证结果
    AUSF-->>SEAF: ⑬ Nausf_UEAuthentication_Authenticate Response<br/>认证成功/失败 + K_SEAF + SUPI
    SEAF->>SEAF: ⑭ 推导K_AMF(Annex A.7)<br/>提供ngKSI+K_AMF给AMF
    end

3.2 关键信令消息IE详解

步骤①:SEAF→AUSF 认证请求

IE名称 说明 来源
SUCI/SUPI 首次用SUCI,重认证用SUPI TS 33.501 Section 6.1.2
Serving Network Name "5G:" + SN Id Section 6.1.1.4
Disaster Roaming指示 可选 TS 23.502 Section 4.2.2.2

步骤③:UDM/ARPF 生成5G HE AV

这是5G-AKA最关键的步骤之一。UDM/ARPF的内部处理:

  1. 生成原始AV:(RAND, AUTN, CK, IK, XRES),AMF separation bit 必须设为1
  2. 推导 K~AUSF~(Annex A.2): KEY = CK || IK S = FC(0x6A) || SN-Name || L0 || SQN⊕AK || L1(0x00 0x06) K_AUSF = KDF(KEY, S)
  3. 计算 XRES*(Annex A.4): KEY = CK || IK S = FC(0x6B) || SN-Name || L0 || RAND || L1(0x00 0x10) || XRES || L2 XRES* = KDF最低128位输出
  4. 构造 5G HE AV = (RAND, AUTN, XRES*, K_AUSF)

设计意图:XRES* 将原始XRES与RAND和serving network name绑定,防止跨网络重放攻击。

步骤⑤:AUSF 构造 5G SE AV

AUSF在此步骤完成双层保护设计:

关键安全设计:服务网络(SEAF)永远无法获得 XRES* 和 K~AUSF~。SEAF只能看到HXRES*(哈希值),无法反推原始响应。这确保了归属网络对认证结果的最终控制权。

步骤⑦⑨:空口认证交互

消息 方向 关键IE
NAS Authentication Request SEAF→UE RAND, AUTN, ngKSI, ABBA
NAS Authentication Response UE→SEAF RES*

UE侧处理(Section 6.1.3.2 Step 7-8): 1. ME将RAND/AUTN转发给USIM 2. USIM验证AUTN新鲜性(检查SQN),计算RES,返回RES/CK/IK给ME 3. ME从CK||IK推导K~AUSF~(与ARPF相同的KDF) 4. ME从RES计算RES*(与ARPF相同的KDF) 5. ME进一步计算K~SEAF~

ABBA参数(Annex A.7.1):当前版本固定为 0x0000,用于未来安全特性的降级保护(anti-bidding-down)。

步骤⑩⑫:双层验证——5G相对4G的核心改进

这是5G-AKA相对EPS-AKA最重要的安全增强:

flowchart TD
    A["SEAF收到RES*"] --> B["计算HRES*<br/>SHA-256(RAND||RES*)"]
    B --> C{"HRES* == HXRES*?"}
    C -->|是| D["服务网络认证通过<br/>(第一层验证)"]
    C -->|否| E["服务网络认证失败<br/>可能为伪造UE"]
    D --> F["发送RES*给AUSF"]
    F --> G{"AUSF: RES* == XRES*?"}
    G -->|是| H["归属网络认证通过<br/>(第二层验证)<br/>返回K_SEAF+SUPI"]
    G -->|否| I["归属网络认证失败<br/>通知SEAF"]

    style D fill:#4CAF50,color:white
    style H fill:#2196F3,color:white
    style E fill:#f44336,color:white
    style I fill:#f44336,color:white

TS 33.501原文(Section 6.1.3.2.0):"5G AKA enhances EPS AKA by providing the home network with proof of successful authentication of the UE from the visited network."

在4G EPS-AKA中,MME既持有XRES又负责验证,归属网络无法确认访问网络是否真的完成了UE认证。5G-AKA通过分离HXRES*(给SEAF)和XRES*(仅AUSF持有) 实现了归属网络对认证结果的独立验证。

四、EAP-AKA'认证信令全链拆解(Section 6.1.3.1)

4.1 完整信令时序图

sequenceDiagram
    participant UE as UE (USIM+ME)
    participant SEAF as SEAF/AMF
    participant AUSF as AUSF
    participant UDM as UDM/ARPF

    rect rgb(240,248,255)
    Note over UE,UDM: 认证向量生成
    AUSF->>UDM: Nudm_UEAuthentication_Get Request<br/>SUCI/SUPI, SN-Name
    UDM->>UDM: 生成AV(RAND,AUTN,CK,IK,XRES)<br/>计算CK',IK'(Annex A.3)<br/>构造转换后AV'
    UDM-->>AUSF: AV'(RAND,AUTN,XRES,CK',IK')<br/>+ 方法指示=EAP-AKA'
    end

    rect rgb(255,248,240)
    Note over UE,AUSF: EAP质询-应答
    AUSF-->>SEAF: EAP-Request/AKA'-Challenge<br/>(封装在Nausf Response中)
    SEAF->>UE: NAS Authentication Request<br/>EAP-Request/AKA'-Challenge<br/>+ ngKSI, ABBA
    UE->>UE: USIM验证AUTN→RES,CK,IK<br/>ME推导CK',IK'(Annex A.3)
    UE-->>SEAF: NAS Authentication Response<br/>EAP-Response/AKA'-Challenge
    SEAF->>AUSF: Nausf Request<br/>(透传EAP-Response/AKA'-Challenge)
    AUSF->>AUSF: 比较XRES vs RES
    end

    rect rgb(240,255,240)
    Note over UE,AUSF: 密钥推演与确认
    AUSF->>AUSF: 从CK',IK'推导EMSK<br/>取EMSK最高256位=K_AUSF<br/>推导K_SEAF(Annex A.6)
    AUSF-->>SEAF: EAP-Success<br/>(含K_SEAF, SUPI)
    SEAF->>UE: NAS消息<br/>EAP-Success + ngKSI + ABBA
    UE->>UE: 推导EMSK→K_AUSF→K_SEAF→K_AMF
    end

4.2 EAP-AKA'与5G-AKA的关键差异

比较维度 5G-AKA EAP-AKA'
协议框架 NAS直接承载(非EAP) EAP框架封装(RFC 3748)
规范章节 Section 6.1.3.2 Section 6.1.3.1
认证向量 5G HE AV (RAND, AUTN, XRES*, K~AUSF~) 转换后AV' (RAND, AUTN, XRES, CK', IK')
K~AUSF~来源 ARPF从CK||IK推导(Annex A.2) AUSF/UE从EMSK最高256位取得
中间密钥 CK/IK→K~AUSF~→K~SEAF~ CK/IK→CK'/IK'→EMSK→K~AUSF~→K~SEAF~
认证确认 RES* vs XRES*(AUSF验证) RES vs XRES(AUSF验证)
服务网络预验证 HXRES* vs HRES*(SEAF验证) 无(SEAF仅透传EAP消息)
归属网络证明 有(RES*确认机制) 无(与4G EAP-AKA'类似)
成功消息 无显式成功(依赖后续NAS SMC) EAP-Success消息
适用场景 3GPP接入(NR/LTE) 非可信非3GPP接入(Wi-Fi via N3IWF)、SNPN
消息开销 较低(2条NAS消息) 较高(EAP封装+额外Notification)

五、密钥层级全链推演(Section 6.2, Annex A)

5.1 完整密钥层级树

flowchart TD
    K["K<br/>(长期密钥, 128/256bit<br/>存储于USIM和ARPF)"]

    K -->|"5G-AKA"| CK_IK["CK, IK<br/>(USIM生成)"]
    K -->|"EAP-AKA'"| CK_IK2["CK, IK<br/>(USIM生成)"]

    CK_IK --> KAUSF_5G["K_AUSF<br/>FC=0x6A<br/>KEY=CK||IK<br/>P0=SN-Name, P1=SQN⊕AK"]
    CK_IK2 --> CKP_IKP["CK', IK'<br/>FC=via TS 33.402 A.2<br/>KEY=CK||IK<br/>P0=SN-Name"]
    CKP_IKP --> EMSK["EMSK (512bit)<br/>RFC 5448 / Annex F"]
    EMSK --> KAUSF_EAP["K_AUSF<br/>EMSK最高256位"]

    KAUSF_5G --> KSEAF["K_SEAF<br/>锚点密钥<br/>FC=0x6C<br/>KEY=K_AUSF<br/>P0=SN-Name"]
    KAUSF_EAP --> KSEAF

    KSEAF --> KAMF["K_AMF<br/>FC=0x6D<br/>KEY=K_SEAF<br/>P0=SUPI, P1=ABBA"]

    KAMF --> KNAS["NAS密钥"]
    KAMF --> KAS["AS/接入网密钥"]
    KAMF --> KN3IWF["非3GPP密钥<br/>K_N3IWF<br/>FC=0x6E"]

    KNAS --> KNASint["K_NASint<br/>FC=0x69<br/>NAS完整性"]
    KNAS --> KNASenc["K_NASenc<br/>FC=0x69<br/>NAS加密"]

    KAS --> KgNB["K_gNB<br/>FC=0x6E<br/>KEY=K_AMF<br/>P0=UL NAS COUNT"]
    KgNB --> KRRCint["K_RRCint<br/>FC=0x69"]
    KgNB --> KRRCenc["K_RRCenc<br/>FC=0x69"]
    KgNB --> KUPenc["K_UPenc<br/>FC=0x69"]
    KgNB --> KUPint["K_UPint<br/>FC=0x69"]
    KAMF --> NH["NH<br/>FC=0x6F<br/>前向安全链"]

    style K fill:#f44336,color:white
    style KSEAF fill:#FF9800,color:white
    style KAMF fill:#2196F3,color:white
    style KgNB fill:#4CAF50,color:white

5.2 KDF通用接口(Annex A.1)

所有5GC密钥推演使用TS 33.220 Annex B.2.0定义的KDF:

KDF(KEY, S) = HMAC-SHA-256(KEY, S)
其中 S = FC || P0 || L0 || P1 || L1 || ... || Pn || Ln

FC(Function Code)值分配范围:0x69 ~ 0x79, 0x7B ~ 0x7D, 0x83 ~ 0x84

5.3 关键KDF参数汇总

KDF步骤 FC值 输入KEY 参数P0 参数P1 参数P2 输出
K~AUSF~推导(5G-AKA) 0x6A CK||IK SN-Name SQN⊕AK - K~AUSF~
CK'/IK'推导(EAP-AKA') TS 33.402 CK||IK SN-Name - - CK',IK'
RES*/XRES*推导 0x6B CK||IK SN-Name RAND RES/XRES RES*/XRES*
HRES*/HXRES*推导 - - RAND RES*/XRES* - SHA-256输出最低128位
K~SEAF~推导 0x6C K~AUSF~ SN-Name - - K~SEAF~
K~AMF~推导 0x6D K~SEAF~ SUPI ABBA - K~AMF~
NAS/AS算法密钥 0x69 K~AMF~/K~gNB~ 算法类型区分符 算法ID - 具体算法密钥
K~gNB~推导 0x6E K~AMF~ UL NAS COUNT 接入类型区分符 - K~gNB~
NH推导 0x6F K~AMF~ SYNC-input - - NH

六、SUCI加密机制:SUPI隐私保护(Annex C)

6.1 SUCI结构

SUCI = <SUPI Type> || <MCC> || <MNC> || <Routing Indicator> || <Protection Scheme ID> || <Home Network PK ID> || <Scheme Output>
字段 说明
SUPI Type 0=IMSI, 1=NAI, 2=GCI, 3=GLI
Protection Scheme ID 0x0=null-scheme, 0x1=Profile A, 0x2=Profile B
Home Network PK ID 标识使用的公钥对
Scheme Output 加密后的MSIN/username部分

6.2 ECIES加密方案

5G为SUPI保护定义了两种ECIES profile,均由ME和SIDF实现:

参数 Profile A Profile B
椭圆曲线 Curve25519 (RFC 7748) secp256r1 (SEC 2)
DH原语 X25519 EC Cofactor DH
点压缩 不适用 使用
KDF ANSI-X9.63-KDF ANSI-X9.63-KDF
Hash SHA-256 SHA-256
MAC HMAC-SHA-256, 64bit tag HMAC-SHA-256, 64bit tag
加密 AES-128 CTR mode AES-128 CTR mode
Scheme Output大小 256bit公钥 + 64bit MAC + 输入大小 264bit公钥 + 64bit MAC + 输入大小

UE侧加密流程(Annex C.3.2):

flowchart TD
    A["SUPI中的MSIN<br/>(明文)"] --> B["生成ECC临时<br/>公私钥对"]
    B --> C["ECDH协商<br/>UE临时私钥×HN公钥"]
    C --> D["KDF生成密钥材料<br/>EK + ICB + MK"]
    D --> E["AES-128-CTR加密<br/>MSIN→密文"]
    D --> F["HMAC-SHA-256<br/>计算MAC tag"]
    E --> G["Scheme Output =<br/>临时公钥+密文+MAC"]
    F --> G

    style G fill:#4CAF50,color:white

归属网络侧解密(Annex C.3.3):SIDF使用收到的UE临时公钥和归属网络私钥执行ECDH,恢复共享密钥后解密。

6.3 SUCI计算位置选择

TS 33.501 Section 6.12规定:SUCI的计算可以由USIM或ME完成,由USIM中的SUCI calculation indication决定。如果USIM不支持该指示位,则默认由ME计算。

七、同步失败与MAC失败处理(Section 6.1.3.3)

7.1 失败场景状态机

stateDiagram-v2
    [*] --> AuthPending: 收到RAND/AUTN
    AuthPending --> VerifyAUTN: USIM验证AUTN

    VerifyAUTN --> AuthSuccess: AUTN验证通过
    VerifyAUTN --> MACFailure: MAC验证失败
    VerifyAUTN --> SyncFailure: SQN不同步

    MACFailure --> SendAuthReject: UE发送<br/>Authentication Failure<br/>CAUSE=MAC failure
    SyncFailure --> SendSyncFail: UE发送<br/>Authentication Failure<br/>CAUSE=Sync failure<br/>+AUTS参数

    SendSyncFail --> ARPFReSync: ARPF验证AUTS<br/>重新生成AV
    ARPFReSync --> AuthPending: 新RAND/AUTN

    SendAuthReject --> [*]: 网络决定<br/>重试或拒绝
    AuthSuccess --> [*]

AUTS参数(TS 33.102):包含UE侧的SQN~MS~和MAC~S~,允许ARPF检测SQN偏移并重新同步。归属网络的同步恢复流程在Section 6.1.3.3.2中定义。

八、实战连接

8.1 抓包识别

步骤 协议层 Wireshark过滤器 关键字段
Registration Request 5G-NAS nas-5gs.reg.message_type == 0x41 SUCI或5G-GUTI
Authentication Request 5G-NAS nas-5gs.reg.message_type == 0x53 RAND(16B), AUTN(16B), ngKSI
Authentication Response 5G-NAS nas-5gs.reg.message_type == 0x55 RES*
Authentication Failure 5G-NAS nas-5gs.reg.message_type == 0x5C Cause(20=Sync, 26=MAC)
Nausf Authenticate Req HTTP2/JSON http2.headers.path contains "nausf-auth" servingNetworkName
Nudm UEAuth Get HTTP2/JSON http2.headers.path contains "nudm-ueauth" suciOrSupi

8.2 常见故障点

故障现象 可能原因 排查思路
Authentication Failure (MAC failure) USIM与ARPF密钥K不一致、AUTN被篡改 检查Ki/K同步、核查传输完整性
Authentication Failure (Sync failure) USIM的SQN与ARPF的SQN偏差过大 检查ARPF SQN管理策略(如SQN max delta)
AUSF返回"serving network not authorized" SN-Name与3gpp-Sbi-Originating-Network-Id不匹配 核查SEAF/AUSF配置、SEPP路由
HRES*≠HXRES*(SEAF验证失败) UE计算错误或中间人攻击 对比UE和AUSF的KDF输入参数
SUCI解密失败 公私钥对不匹配、Profile配置不一致 检查Home Network PK ID和Profile ID
## 常见问题

Q1: 5G-AKA和EAP-AKA'能否在同一注册流程中切换使用? A: 不能在同一次认证中切换。方法由UDM/ARPF在收到认证请求时一次性选定,并告知AUSF。但不同次注册可以使用不同方法(如3GPP接入用5G-AKA,非3GPP接入用EAP-AKA')。

Q2: 5G-AKA中SEAF验证(HRES*)失败后会发生什么? A: 根据Section 6.1.3.2.2,SEAF仍会将RES*发送给AUSF进行归属网络验证,但最终会根据AUSF的响应决定是否发送Authentication Reject(如果初始用SUCI)或发起Identification过程获取SUCI重试(如果初始用5G-GUTI)。

Q3: null-scheme下的SUCI是否安全? A: 不安全。null-scheme(Protection Scheme ID=0x0)不提供任何隐私保护,SUCI等同于明文SUPI。仅当USIM未配置Home Network Public Key时才使用。运营商应确保所有USIM预置ECIES公钥。

Q4: K~AUSF~为什么需要存储在AUSF中? A: 用于后续的重认证优化——AUSF可基于存储的K~AUSF~执行后续认证,无需每次都访问ARPF。此外还用于Steering of Roaming(SoR)、UE Parameter Update(UPU)和AKMA等特性。但TS 33.501明确指出,基于存储K~AUSF~的认证安全性略弱于直接涉及ARPF/USIM的认证。

Q5: 5G密钥层级中NH链的作用是什么? A: NH(Next Hop)用于提供前向安全性。每次切换时,NH从K~AMF~或前一个NH推演(FC=0x6F),形成链式结构。即使当前K~gNB~泄露,攻击者也无法推算之前的密钥,因为NH推演是单向的。

参考来源

  1. 3GPP TS 33.501 V18.9.0 — Security architecture and procedures for 5G System, Section 6.1 (Primary authentication), Section 6.2 (Key hierarchy), Annex A (KDF), Annex C (SUCI protection schemes)
  2. 3GPP TS 29.509 V18.5.0 — Nausf_UEAuthentication Service API, Section 5.2/6.1
  3. IETF RFC 9048 — Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')
  4. IETF RFC 5448 — Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')
  5. 3GPP TS 33.102 — 3G Security: Security Architecture (原始AV生成、AUTN/AUTS结构)

本文由「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学通信知识星球海报-扫码加入