<!-- title: 5G-AKA与EAP-AKA'双轨认证机制拆解 -->
<!-- domain: security -->

# 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）：

- **K~SEAF~** 由归属网络AUSF提供给服务网络SEAF，作为锚点密钥
- 从一次认证可派生多个安全上下文的密钥（如3GPP接入和非3GPP接入可共享）
- K~SEAF~ 由中间密钥 **K~AUSF~** 推导，K~AUSF~ 建立在UE和归属网络之间
- UE和服务网络**必须同时支持** 5G-AKA 和 EAP-AKA'（Section 6.1.1.1原文）

### 1.2 EAP框架映射（Section 6.1.1.2）

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

```mermaid
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可以在**任何建立信令连接的过程**中发起认证（如注册、服务请求），核心流程如下：

```mermaid
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 完整信令时序图

```mermaid
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在此步骤完成**双层保护**设计：

- 计算 **HXRES\***（Annex A.5）：`SHA-256(RAND || XRES*)` 的最低128位
- 计算 **K~SEAF~**（Annex A.6）：`KDF(K_AUSF, FC(0x6C) || SN-Name || L0)`
- 从5G HE AV中移除XRES\*和K~AUSF~，替换为HXRES\*，得到 **5G SE AV** = `(RAND, AUTN, HXRES*)`

**关键安全设计**：服务网络（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最重要的安全增强：

```mermaid
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 完整信令时序图

```mermaid
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 完整密钥层级树

```mermaid
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）：

```mermaid
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 失败场景状态机

```mermaid
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](https://www.3gpp.org/DynaReport/33501.htm) — 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](https://www.3gpp.org/DynaReport/29509.htm) — Nausf_UEAuthentication Service API, Section 5.2/6.1
3. [IETF RFC 9048](https://www.rfc-editor.org/rfc/rfc9048) — Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')
4. [IETF RFC 5448](https://www.rfc-editor.org/rfc/rfc5448) — Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')
5. [3GPP TS 33.102](https://www.3gpp.org/DynaReport/33102.htm) — 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学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)