<!-- title: 4G/5G安全认证与密钥层级全图解 -->

# 4G/5G安全认证与密钥层级全图解：从根密钥到空口加密的完整链路

## 一、为什么需要理解安全认证？

想象你住在一栋高级公寓里。每次回家，你需要经过三道门禁：小区大门、单元门、自家门。每道门都有不同的钥匙，而且物业还定期换锁。移动通信的安全认证体系，本质上就是一套类似的"多级门禁系统"——只不过它保护的不是你家门，而是你和基站之间每一比特数据的机密性和完整性。

很多工程师在日常工作中会接触到"鉴权失败""安全模式拒绝""IMSI unknown"等告警，但很少有人真正理解这些错误背后的安全架构。理解4G/5G安全认证原理，能帮你：

- 快速定位鉴权失败的根本原因（是密钥不匹配还是SQN不同步？）
- 理解为什么5G要引入SUCI替代明文IMSI
- 搞清楚"安全锚点"SEAF为什么是5G安全架构的关键创新
- 掌握密钥层级派生关系，理解每一次切换时密钥如何更新

## 二、安全认证的核心问题：我们到底在保护什么？

移动通信安全要解决三个根本问题：

| 安全目标 | 通俗理解 | 技术手段 |
|---------|---------|---------|
| **身份认证** | 你是谁？证明给我看 | AKA（认证与密钥协商）协议 |
| **数据加密** | 别人偷听不到我们说话 | 空口加密（ ciphering） |
| **数据完整性** | 没人偷偷改了我们的对话 | 完整性保护（integrity protection） |

为了实现这三个目标，通信系统采用了一个核心设计思想：**层层派生、逐级隔离**的密钥层级体系。

## 三、一个类比：理解密钥层级的核心逻辑

把密钥层级想象成一个公司的权限体系：

- **CEO（根密钥K）**：最核心的权限，永远锁在保险柜里（USIM卡和运营商核心网各持一份）
- **VP（KAUSF/KSEAF）**：由CEO授权的高级管理密钥，负责不同层级的"安全锚定"
- **部门经理（KAMF）**：负责一个AMF管辖范围内的安全上下文
- **一线员工（KNASenc, KRRCint, KUPenc...）**：各司其职的具体会话密钥，分别负责NAS加密、RRC完整性、用户面加密等

**关键设计原则**：上级密钥可以派生下级密钥，但下级密钥被破解后，绝不能反推上级密钥。这就是"单向派生"——用密码学中的KDF（密钥派生函数）来实现，底层算法是HMAC-SHA-256。

$$K_{\text{derived}} = \text{KDF}(K_{\text{parent}}, \text{P}_0, \text{L}_0, \text{P}_1, \text{L}_1, \ldots)$$

其中P₀、P₁...是输入参数（如服务网络标识、算法类型等），L₀、L₁...是对应参数的长度。

## 四、4G EPS-AKA：安全认证的基石

### 4.1 参与方与角色

```
┌─────────┐         ┌─────────┐         ┌─────────┐
│   UE    │◄────────►│   MME   │◄───────►│   HSS   │
│ (手机)   │  无线接口  │(移动管理) │  S6a接口 │(归属用户)│
│  USIM卡  │         │         │         │  服务器  │
└─────────┘         └─────────┘         └─────────┘
   持有: K            持有: KASME         持有: K
```

- **UE**：用户设备，SIM卡中存储根密钥K
- **MME**：4G核心网的控制面节点，负责认证的中间人角色
- **HSS**：归属用户服务器，存储所有用户的根密钥K和签约数据

### 4.2 4G认证流程详解

```mermaid
sequenceDiagram
    participant UE as UE/USIM
    participant MME as MME
    participant HSS as HSS/AuC

    Note over UE,HSS: 阶段一：认证向量请求
    MME->>HSS: 认证数据请求<br/>(IMSI, SN ID)
    Note right of HSS: HSS用根密钥K生成认证向量AV
    HSS->>MME: 返回AV(RAND, XRES, AUTN, KASME)

    Note over UE,HSS: 阶段二：挑战-响应
    MME->>UE: 用户认证请求<br/>(RAND, AUTN)
    Note left of UE: USIM验证AUTN:<br/>1.计算XMAC，与MAC比对<br/>2.检查SQN序列号
    UE->>MME: 用户认证响应<br/>(RES)

    Note over UE,HSS: 阶段三：验证结果
    Note right of MME: MME比对XRES与RES
    MME->>UE: 安全模式命令<br/>(加密/完整性算法)
    UE->>MME: 安全模式完成
```

**通俗理解**：这个过程就像银行的"双向核验"——银行（HSS）给你出了一道只有你的银行卡（USIM）才能解的题（RAND），同时给你一个防伪标识（AUTN）让你确认题目确实来自真银行而非骗子。双方确认身份后，才建立加密通信。

### 4.3 4G密钥层级体系

```mermaid
graph TD
    K["K<br/>(根密钥·128/256bit)<br/>USIM ⟷ HSS共享"]
    K -->|KDF + SN_ID| KASME["KASME<br/>(接入安全管理密钥)<br/>MME与UE各自派生"]
    KASME --> KNASenc["KNASenc<br/>NAS加密密钥"]
    KASME --> KNASint["KNASint<br/>NAS完整性密钥"]
    KASME --> KeNB["KeNB<br/>eNodeB密钥"]
    KeNB --> KRRCenc["KRRCenc<br/>RRC加密密钥"]
    KeNB --> KRRCint["KRRCint<br/>RRC完整性密钥"]
    KeNB --> KUPenc["KUPenc<br/>用户面加密密钥"]

    style K fill:#ff6b6b,color:#fff
    style KASME fill:#ffa502,color:#fff
    style KeNB fill:#2ed573,color:#fff
    style KNASenc fill:#70a1ff,color:#fff
    style KNASint fill:#70a1ff,color:#fff
    style KRRCenc fill:#a29bfe,color:#fff
    style KRRCint fill:#a29bfe,color:#fff
    style KUPenc fill:#a29bfe,color:#fff
```

| 密钥 | 派生位置 | 用途 | 保护范围 |
|------|---------|------|---------|
| **K** | USIM + HSS预置 | 根密钥，永不传输 | 全部安全的根基 |
| **KASME** | HSS生成→MME, UE本地派生 | 中间密钥，NAS层安全锚点 | 接入安全管理 |
| **KNASenc** | MME, UE | NAS信令加密 | UE ↔ MME之间 |
| **KNASint** | MME, UE | NAS信令完整性保护 | UE ↔ MME之间 |
| **KeNB** | MME → eNB, UE | 基站层密钥 | UE ↔ eNB之间 |
| **KRRCenc** | eNB, UE | RRC信令加密 | 无线信令面 |
| **KRRCint** | eNB, UE | RRC信令完整性保护 | 无线信令面 |
| **KUPenc** | eNB, UE | 用户面数据加密 | 用户数据传输 |

## 五、5G-AKA：安全架构的重大升级

### 5.1 5G安全架构的四大变化

为什么5G需要重新设计安全架构？因为4G存在几个关键安全缺陷：

| 4G安全缺陷 | 具体问题 | 5G解决方案 |
|-----------|---------|-----------|
| **IMSI明文传输** | 攻击者可用伪基站（IMSI Catcher）被动监听用户标识 | 引入**SUCI**，用公钥加密SUPI |
| **网络不认证** | UE无法验证所连接的网络是否合法 | 5G-AKA中UE验证AUTN，**增强归属网络控制** |
| **安全锚不灵活** | KASME绑定在MME，不支持跨接入技术 | 引入**SEAF安全锚点**，统一3GPP/非3GPP接入 |
| **密钥分离不够** | 某些场景下密钥复用 | **更细粒度的密钥层级**，新增用户面完整性保护 |

### 5.2 5G安全架构实体

```mermaid
graph TD
    UE["UE<br/>(USIM + ME)"]
    RAN["gNodeB<br/>(无线接入网)"]
    AMF["AMF<br/>(含SEAF)<br/>接入与移动管理"]
    AUSF["AUSF<br/>认证服务器"]
    UDM["UDM<br/>(含ARPF+SIDF)<br/>统一数据管理"]

    UE ---|"Uu接口"| RAN
    RAN ---|"NG-C接口"| AMF
    AMF ---|"N12/N8接口"| AUSF
    AUSF ---|"N13接口"| UDM

    style UE fill:#74b9ff,color:#000
    style AMF fill:#fdcb6e,color:#000
    style AUSF fill:#e17055,color:#fff
    style UDM fill:#d63031,color:#fff
```

**核心变化**：4G的"MME+HSS"二人组变成了"AMF(SEAF)+AUSF+UDM"三人组。为什么要拆开？

- **AMF/SEAF**：负责接入管理，同时充当安全锚点——不管你用什么方式接入（5G NR、Wi-Fi、固网），安全上下文都锚定在这里
- **AUSF**：专职做认证——将认证功能从移动管理中独立出来，职责更清晰
- **UDM/ARPF/SIDF**：UDM存储用户数据，ARPF（认证凭证仓库）存储根密钥K，SIDF（订阅标识去隐藏功能）负责把SUCI解密回SUPI

### 5.3 SUPI与SUCI：5G隐私保护的核心

4G时代，IMSI在某些场景（如初始附着）会以明文形式在空口传输。这就像你的身份证号直接写在T恤上走在街上——任何人都能看到。5G引入了SUPI/SUCI机制来解决这个问题。

**SUPI（Subscription Permanent Identifier）**：5G中的永久用户标识，相当于4G的IMSI。它永远不应该在空口以明文传输。

**SUCI（Subscription Concealed Identifier）**：SUPI的加密形态。UE使用归属网络的公钥（预置在USIM中），通过ECIES（椭圆曲线集成加密方案）将SUPI加密为SUCI。

```
加密过程（在UE/USIM中完成）：
SUPI + 归属网络公钥(PK_HN) → ECIES加密 → SUCI

解密过程（在UDM/SIDF中完成）：
SUCI + 归属网络私钥(SK_HN) → ECIES解密 → SUPI
```

**为什么用公钥加密而不是对称加密？** 因为公钥加密不需要UE和网络事先共享加密密钥——USIM只需要预存运营商的公钥即可。即使攻击者截获了SUCI，没有私钥也无法还原SUPI。

### 5.4 5G-AKA认证流程

```mermaid
sequenceDiagram
    participant UE as UE/USIM
    participant SEAF as AMF/SEAF
    participant AUSF as AUSF
    participant UDM as UDM<br/>(ARPF+SIDF)

    Note over UE,UDM: 阶段一：注册请求
    UE->>SEAF: Registration Request<br/>(携带SUCI或5G-GUTI)

    Note over UE,UDM: 阶段二：认证启动
    SEAF->>AUSF: Nausf_UEAuthentication<br/>Authenticate Request<br/>(SUCI, SNN)
    AUSF->>UDM: Nudm_UEAuthentication<br/>Get Request<br/>(SUCI)
    Note right of UDM: SIDF解密SUCI→SUPI<br/>ARPF查找根密钥K<br/>生成5G认证向量AV
    UDM->>AUSF: 返回AV<br/>(RAND, HXRES*, AUTN, KAUSF)
    AUSF->>SEAF: 返回(RAND, AUTN, HXRES*)

    Note over UE,UDM: 阶段三：挑战-响应
    SEAF->>UE: Authentication Request<br/>(RAND, AUTN)
    Note left of UE: USIM验证:<br/>1.用K计算XMAC vs MAC<br/>2.验证SQN序列号<br/>3.计算RES*
    UE->>SEAF: Authentication Response<br/>(RES*)
    SEAF->>AUSF: Nausf_UEAuthentication<br/>Authenticate Confirm<br/>(RES*)

    Note over UE,UDM: 阶段四：验证与密钥派生
    Note right of AUSF: AUSF比对HXRES*与H(RES*)<br/>验证通过→派生KSEAF
    AUSF->>SEAF: 返回KSEAF + Auth Result
    Note right of SEAF: SEAF用KSEAF派生KAMF<br/>再派生各层会话密钥
    SEAF->>UE: Security Mode Command<br/>(安全算法选择)
    UE->>SEAF: Security Mode Complete
```

### 5.5 5G密钥层级体系

```mermaid
graph TD
    K5G["K<br/>(根密钥·128/256bit)<br/>USIM ⟷ UDM/ARPF共享"]
    K5G -->|"AKA运算"| CKIK["CK ‖ IK<br/>(加密密钥+完整性密钥)"]
    CKIK -->|"KDF + SN_ID + SUPI"| KAUSF["KAUSF<br/>(AUSF密钥)<br/>5G新增"]
    KAUSF -->|"KDF + SNN"| KSEAF["KSEAF<br/>(安全锚密钥)<br/>⭐ 5G核心创新"]
    KSEAF -->|"KDF + SUPI + ABBA"| KAMF["KAMF<br/>(AMF密钥)"]
    KAMF --> KNASenc5["KNASenc<br/>NAS加密"]
    KAMF --> KNASint5["KNASint<br/>NAS完整性"]
    KAMF --> KgNB["KgNB / KN3IWF<br/>基站层密钥"]
    KgNB --> KRRCenc5["KRRCenc<br/>RRC加密"]
    KgNB --> KRRCint5["KRRCint<br/>RRC完整性"]
    KgNB --> KUPenc5["KUPenc<br/>用户面加密"]
    KgNB --> KUPint["KUPint<br/>用户面完整性<br/>⭐ 5G新增"]

    style K5G fill:#d63031,color:#fff
    style KAUSF fill:#e17055,color:#fff
    style KSEAF fill:#fdcb6e,color:#000
    style KAMF fill:#00b894,color:#fff
    style KUPint fill:#0984e3,color:#fff
```

| 密钥 | 派生参数 | 用途 | 与4G的对应关系 |
|------|---------|------|--------------|
| **K** | 预置 | 根密钥 | 同4G |
| **CK/IK** | K + RAND | 加密/完整性中间密钥 | 同4G |
| **KAUSF** | CK\|\|IK + SN_ID + SUPI | AUSF级密钥 | 新增（4G无对应） |
| **KSEAF** | KAUSF + SNN | **安全锚密钥** | 新增（替代KASME的角色但更灵活） |
| **KAMF** | KSEAF + SUPI + ABBA | AMF级密钥 | 对应4G的KASME重新派生 |
| **KNASenc/int** | KAMF + 算法ID | NAS层安全 | 同4G |
| **KgNB** | KAMF + 基站信息 | 基站层密钥 | 对应4G的KeNB |
| **KUPint** | KgNB + 算法ID | **用户面完整性** | ⭐ 5G新增（4G无用户面完整性保护） |

## 六、4G vs 5G：认证与密钥体系全面对比

| 对比维度 | 4G EPS-AKA | 5G-AKA |
|---------|-----------|--------|
| **用户标识** | IMSI（明文） | SUPI → SUCI（公钥加密） |
| **核心网认证实体** | HSS | UDM/ARPF + AUSF |
| **接入网认证实体** | MME | AMF（内含SEAF） |
| **安全锚密钥** | KASME（存储在MME） | KSEAF（存储在SEAF/AMF） |
| **归属网络控制** | HSS生成AV后全权交给MME | AUSF参与最终验证，归属网控制更强 |
| **密钥层级深度** | K → KASME → KeNB → 会话密钥（3层） | K → KAUSF → KSEAF → KAMF → KgNB → 会话密钥（5层） |
| **用户面完整性** | ❌ 无 | ✅ 新增KUPint |
| **跨接入支持** | 仅3GPP接入 | 统一锚点支持3GPP + 非可信非3GPP |
| **认证方法** | EPS-AKA | 5G-AKA 或 EAP-AKA'（可选） |
| **隐私保护** | IMSI可被嗅探 | SUCI加密，抗IMSI Catcher |

## 七、密钥派生函数（KDF）：层级体系的"发动机"

所有密钥派生都通过同一个KDF完成，其核心算法是HMAC-SHA-256：

$$K_{\text{out}} = \text{HMAC-SHA-256}(K_{\text{in}}, \text{P}_0 \| \text{L}_0 \| \text{P}_1 \| \text{L}_1 \| \ldots)$$

以KSEAF的派生为例：

$$K_{\text{SEAF}} = \text{KDF}(K_{\text{AUSF}}, \text{FC} = 0x6A, \text{P}_0 = \text{SNN}, \text{L}_0 = \text{len(SNN)})$$

其中**SNN（Serving Network Name）** 是服务网络的标识，格式如`5G:mnc070.mcc901.3gppnetwork.org`。将SNN绑定到密钥派生中，意味着同一个KAUSF派生给不同服务网络的KSEAF是不同的——这就是"密钥分离"原则的体现：**一把钥匙只开一把锁**。

**为什么用HMAC-SHA-256而不是直接用SHA-256？** 因为HMAC需要一个密钥作为输入，确保只有持有父密钥的实体才能派生子密钥。这比单纯哈希更安全——即使攻击者知道所有派生参数，没有父密钥也无法算出子密钥。

## 八、切换场景下的密钥更新

移动通信中，UE会频繁在基站间切换。每次切换时，密钥如何更新？

### 8.1 4G中的切换密钥更新

$$K_{\text{eNB}}^{*} = \text{KDF}(K_{\text{eNB}}, \text{Target PCI} \| \text{EARFCN-DL})$$

每次切换时，当前eNB用KeNB和目标基站的物理参数派生出新的KeNB*，传给目标eNB。这个过程叫**水平派生**。

### 8.2 5G中的切换密钥更新

5G引入了更安全的机制，支持**水平派生**和**垂直派生**两种方式：

- **水平派生**：同一AMF下，gNB之间切换时，用当前KgNB和目标基站参数派生新KgNB*
- **垂直派生**：当AMF变更时，需要从KAMF重新派生KgNB，安全层级更高

```mermaid
graph LR
    subgraph "4G 切换密钥更新"
        KeNB1["KeNB(源eNB)"] -->|"KDF + Target PCI"| KeNB2["KeNB*(目标eNB)"]
    end

    subgraph "5G 切换密钥更新"
        KgNB1["KgNB(源gNB)"] -->|"水平派生<br/>KDF + Target PCI"| KgNB2["KgNB*(目标gNB)"]
        KAMF5["KAMF"] -->|"垂直派生(AMF变更时)"| KgNB3["KgNB(新AMF下)"]
    end
```

**实战连接**：如果你在做路测时发现切换后出现短暂的数据中断或安全模式失败，可能的原因之一就是密钥派生参数（如PCI混淆、EARFCN配置错误）导致目标基站无法正确派生密钥。

## 九、5G安全算法体系

密钥派生完成后，实际的加密和完整性保护由具体算法执行：

| 算法编号 | 名称 | 用途 | 算法基础 |
|---------|------|------|---------|
| **NEA0** | 空加密 | 不加密（调试用） | 无 |
| **NEA1** | 128-EEA1 | 加密 | SNOW 3G |
| **NEA2** | 128-EEA2 | 加密 | AES-CTR |
| **NEA3** | 128-EEA3 | 加密 | 祖冲之（ZUC） |
| **NIA0** | 空完整性 | 不保护（仅特殊场景） | 无 |
| **NIA1** | 128-EIA1 | 完整性 | SNOW 3G |
| **NIA2** | 128-EIA2 | 完整性 | AES-CMAC |
| **NIA3** | 128-EIA3 | 完整性 | 祖冲之（ZUC） |

**为什么中国运营商特别关注ZUC（祖冲之算法）？** 因为NEA1/NIA1（SNOW 3G）来自欧洲，NEA2/NIA2（AES）来自美国，而NEA3/NIA3（ZUC）是中国自主设计的密码算法。国内商用网络中，通常优先使用ZUC算法。

## 十、实战调试：安全认证问题的排查思路

### 10.1 常见错误与定位

| 错误类型 | 可能原因 | 排查方向 |
|---------|---------|---------|
| **Authentication Failure (MAC Failure)** | USIM中的K与HSS/UDM中的K不匹配 | 检查SIM卡配卡数据 |
| **Authentication Failure (SQN Failure)** | SQN序列号不同步（如长期离线后首次注册） | USIM会触发重新同步流程 |
| **Security Mode Reject** | UE与网络支持的加密算法无交集 | 检查UE能力与网络配置的算法列表 |
| **Registration Reject (#10) Implicitly deregistered** | 安全上下文过期或丢失 | 检查AMF中的安全上下文状态 |
| **IMSI Unknown** | SUCI解密失败或用户数据未录入 | 检查UDM中的用户签约数据 |

### 10.2 SQN同步问题详解

SQN（Sequence Number）是防止重放攻击的核心机制。USIM中维护一个计数器，每次成功认证后递增。如果HSS/UDM侧的SQN与USIM的SQN偏差太大（比如用户长期关机），UE会返回"SQN Failure"并触发重新同步：

```
UE → SEAF → AUSF → UDM: AUTS（包含USIM当前的SQN和MAC-S）
UDM重新计算合理的SQN，生成新的AV
```

**调试陷阱**：在实验室环境中反复测试同一张SIM卡时，容易出现SQN不同步。解决办法是在HSS/UDM中重置SQN，或换一张新的测试卡。

## 十一、5G-AKA vs EAP-AKA'：两种认证方法的区别

5G支持两种主要的认证方法：

| 特性 | 5G-AKA | EAP-AKA' |
|------|--------|----------|
| **定义方** | 3GPP（蜂窝专用） | IETF（通用框架） |
| **协议层级** | NAS层直接承载 | EAP框架承载（NAS之上） |
| **响应验证** | AUSF验证H(RES*) | AUSF直接验证RES* |
| **归属控制** | 强（AUSF参与验证） | 更强（完整的EAP-Success/Failure流程） |
| **适用场景** | 主流5G接入 | 非可信非3GPP接入、特殊企业场景 |

**通俗理解**：5G-AKA是运营商的"自研系统"，专门为蜂窝网络优化，效率更高；EAP-AKA'是基于IETF标准的"通用框架"，兼容性更好，但信令开销稍大。

## 常见问题

**Q: 4G的KASME和5G的KSEAF有什么本质区别？**
A: 表面上它们都是"安全锚密钥"，但KSEAF的设计有本质提升。KASME直接由HSS生成后发给MME，MME独占安全控制权；而KSEAF由AUSF派生，SEAF只是使用方——认证的最终验证权在归属网络（AUSF），而不是拜访网络（SEAF/AMF）。这种设计让归属运营商对安全有更强的控制力。此外，KSEAF天然支持跨接入技术锚定（3GPP/非3GPP），而KASME仅支持3GPP接入。

**Q: 为什么5G要新增用户面完整性保护（KUPint），4G为什么不需要？**
A: 4G只对用户面做加密，不做完整性保护。这在大多数场景下够用，但存在一个攻击面：攻击者虽然无法解密数据，但可以在不知道密钥的情况下**篡改密文**（比特翻转攻击），接收端解密后得到的是被篡改的数据。5G新增KUPint后，每个用户面数据包都带一个完整性校验码（MAC-I），接收端可以检测到任何篡改。这对物联网等低安全能力的设备尤其重要。

**Q: SUCI加密用的ECIES是什么？为什么不用RSA？**
A: ECIES（椭圆曲线集成加密方案）是基于椭圆曲线密码学的加密方案。相比RSA，ECIES在相同安全强度下密钥长度更短（256bit ECC ≈ 3072bit RSA），计算量更小，非常适合USIM这种计算资源有限的场景。SIM卡的芯片性能有限，用ECIES可以更快完成加密运算，减少注册时延。

**Q: 在实际网络中，安全认证失败的常见原因有哪些？**
A: 最常见的三大原因：(1) **SIM卡数据不一致**——USIM中的K与核心网中存储的K不匹配，常见于新卡激活或测试环境；(2) **SQN不同步**——用户长期关机或USIM被频繁用于测试后，序列号偏差过大；(3) **算法协商失败**——UE和网络支持的加密/完整性算法列表没有交集，常见于国际漫游场景或使用了定制终端。

**Q: 5G的"归属网络控制增强"具体体现在哪里？**
A: 在4G中，HSS生成认证向量后把XRES交给MME，由MME独立完成验证——如果MME被攻破，攻击者可以伪造认证结果。5G中，AUSF（位于归属网络）直接参与最终验证：SEAF只把RES*的哈希值HXRES*用于初步检查，真正的验证由AUSF完成。这意味着即使拜访网络的AMF被攻破，攻击者也无法伪造归属网络的认证结果。

## 参考来源

1. [5G Security Architecture: Authentication, Encryption, and What Changed](https://www.5g6gacademy.com/learn/5g-security-architecture) — 5G安全架构全景，涵盖密钥层级、5G-AKA与EAP-AKA对比
2. [Introduction to 5G AKA - free5GC](https://free5gc.org/blog/20251029/20251029/) — 开源5G核心网项目free5GC的5G-AKA认证流程详解
3. [5G Security vs 4G Security — 3GPP Technical Analysis](https://www.cafetele.com/articles/article-5g-vs-4g-security.html) — 基于3GPP规范的4G/5G安全机制深度对比
4. [Authentication and Key Agreement (AKA) in 4G and 5G - P1 Security](https://www.p1sec.com/blog/breaking-down-aka-authentication-key-agreement-protocols-in-mobile-networks) — 安全厂商对AKA协议的技术分析
5. [从IMSI到SUCI：5G终端标识的加密升级与隐私保护](https://blog.csdn.net/weixin_42525385/article/details/160365229) — SUPI/SUCI机制详解与4G隐私缺陷分析

---
> 本文由「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)