<!-- title: 图解5G认证与密钥推导体系 -->

# 图解5G认证与密钥推导体系：手机开机后的"验明正身"到底发生了什么

做过现网注册问题排查的工程师，几乎都遇到过这样的场景：用户投诉"手机显示仅限紧急呼叫"，你在核心网侧抓包，看到Initial Registration被拒；你满心以为能在信令里找到用户的IMSI来定位用户，结果翻遍整个NAS消息，只看到一个长得像乱码的字符串`SUCI: h'01 25 00 0F ...`。再往深查，同事提醒你："去查一下鉴权五元组"、"看看是不是SQN不同步"、"K_AMF刷新了吗"——一堆密钥名词扑面而来。

这篇文章就把5G的认证与密钥体系彻底讲透：**网络怎么确认"你是你"，你怎么确认"网络是网络"，以及一次认证之后，那一整棵密钥树是怎么长出来的。**理解了这套体系，注册类故障的排查逻辑会清晰很多。

## 一、认证到底在"认证"什么？

先建立一个直觉：移动网络的认证从来不是单向的"查身份证"，而是**双向的相互认证**：

- **网络验用户**：确认这个SIM卡是本网合法用户，不是蹭网的假卡；
- **用户验网络**：确认这个基站背后的网络真的能和我的归属运营商"对上暗号"，而不是伪基站。

这两个动作在一次流程里同时完成，而且附带一个"副产品"——双方各自算出一把相同的会话密钥。所以这项技术的全名叫 **AKA（Authentication and Key Agreement，认证与密钥协商）**：认证和发钥匙，一个流程，两件事一起办。

一个日常类比：你住酒店，前台不是只核对你的身份证（网络验你），你也会通过订单号、门锁授权确认"这家酒店确实认我的预订"（你验网络）；核验通过的同时，双方约定好了房卡密码（密钥协商）——之后开锁（加密通信）用的就是这把房卡，而不是你的身份证原件。

## 二、5G为什么要推倒重来？4G的老毛病

5G没有沿用4G的认证架构照搬，而是做了两处关键重构。要理解"为什么这样设计"，得先看旧架构的痛点。

**痛点一：用户身份明文裸奔。** 在4G及之前的系统里，手机开机后第一次通信时要发送明文的IMSI（国际移动用户识别码）。这就像每次进小区都在大门口喊出自己的身份证号。空口嗅探设备（所谓"伪基站"/IMSI catcher）可以被动监听这个消息，把用户身份、位置轨迹全部收集走。

**痛点二：拜访网络权力过大。** 4G时代认证向量（含期望响应和根密钥材料）会从归属网络下发到拜访网络的MME，拜访网络深度参与认证的裁决过程。在漫游场景下，这意味着拜访运营商拿到了相当敏感的凭据。

5G对应的两个解法，构成本文的两条主线：

1. **SUCI**：把用户标识"加密后再出门"；
2. **密钥锚点上移**：认证的主导权和根密钥的裁决权收归归属网络的AUSF（鉴权服务功能），拜访网络（SEAF）只拿得到"散列过的答卷"。

## 三、SUCI：开机第一件事，先"戴上口罩"

SUCI（Subscription Concealed Identifier，隐匿订阅标识）是SUPI（真实永久标识，通常就是IMSI）的加密形态。它的原理用一句话概括：**终端用归属运营商的公钥把IMSI加密，只有归属网络用私钥才能解开。**

```mermaid
flowchart TD
    SUPI["SUPI 真实标识<br/>即IMSI"] --> ENC["终端执行ECIES加密"]
    PK["归属网络公钥<br/>预置在USIM中"] --> ENC
    ENC --> SUCI["SUCI 临时化名"]
    SUCI --> NET["空口与信令中传输"]
    NET --> DEC["归属网络UDM用私钥解密"]
    DEC --> OUT["还原出SUPI"]
```

几个工程上值得注意的细节：

- **加密用的是椭圆曲线体制（ECIES）**，可选曲线包括Curve25519、P-256等。每次加密使用临时随机密钥对，因此**同一个SUPI每次生成的SUCI都不一样**——空口抓包者连"这两个消息是不是同一个用户发的"都难以关联。
- 公钥从哪来？归属运营商把**归属网络公钥预置到USIM里**，并配套一个"公钥标识"告诉归属网络"我是用你哪一把公钥加的密"。这样运营商将来换钥匙、配多把钥匙都不影响存量卡。
- SUCI中还带有**路由指示器（Routing Indicator）**，帮助归属网络把解密请求路由到正确的UDM分组——相当于信封上写的"分拣区号"。

这就是为什么你在注册信令里永远抓不到明文IMSI：**明文只存在于终端和归属网络UDM这两个端点，中间的gNB、AMF、AUSF看到的都是密文。** 调试时如果要确认用户身份，只能从归属侧（UDM/签约数据）反查SUCI对应的SUPI，这也是很多新工程师第一次做注册排查时最不适应的地方。

## 四、5G-AKA主流程：一场"背对背批卷"

理解了身份隐藏，我们看认证主体流程。5G-AKA默认流程的时序如下（简化版，省略了部分中间应答）：

```mermaid
sequenceDiagram
    participant UE as 终端与USIM
    participant S as AMF扮演SEAF
    participant A as AUSF 归属网络
    participant H as UDM与ARPF
    UE->>S: 初始注册消息 携带SUCI
    S->>A: 转发认证请求 携带SUCI和网络名SNN
    A->>H: 请求认证向量
    H->>A: 下发五元组 RAND AUTN XRES* CK IK
    A->>A: 计算K_AUSF与K_SEAF 生成HXRES*
    A->>S: 返回RAND AUTN HXRES*
    S->>UE: NAS Authentication Request
    UE->>UE: USIM校验AUTN 推导RES*
    UE->>S: NAS Authentication Response 携带RES*
    S->>S: 比对RES*哈希与HXRES*
    S->>A: 发送认证结果
    A->>A: 比对RES*与XRES*
    A->>S: 确认通过 下发K_SEAF
```

流程里有三个"为什么这样设计"，是理解5G认证精髓的关键：

**为什么答卷要"背对背批两次"？** 注意拜访网络SEAF手里只有**HXRES\***（期望响应的哈希值），而不是完整的期望响应XRES\*。终端交卷（RES\*）后，SEAF先比对哈希做"初判"，AUSF再拿归属侧保密的XRES\*做"终判"。这样设计的好处是：**拜访网络全程接触不到完整答卷，即使它被攻破，攻击者也拿不到可用于伪造认证的凭据**。漫游场景下，这一点的价值尤其大。

**AUTN里藏了什么？** USIM收到RAND（随机数挑战）和AUTN后，会做两件事：用根密钥K验证AUTN里的消息鉴权码MAC（确认"挑战确实来自掌握K的归属网络"，用户验网络就在这一步）；检查其中的**序列号SQN**是否在正常范围内（防止攻击者重放旧的认证挑战）。如果SQN异常，终端会回送AUTS触发**重同步流程**，归属网络校准计数器后重新发起认证。

**SNN是什么？** 服务网络名（Serving Network Name）标明了"终端正在为哪个PLMN做认证"。归属网络签发认证向量时把SNN绑进去，防止拜访网络把一份认证材料挪用到别的网络——这是对漫游场景的又一道防线。

## 五、密钥推导树：一棵会自己修剪的树

认证成功只是拿到密钥的"许可证"，真正的密钥体系是一棵**逐级派生的树**。根密钥K从出厂就封存在USIM卡和归属网络的鉴权中心里，**任何环节都不传输、不落盘**，网络里流动的永远只是派生物：

```mermaid
flowchart TD
    K["根密钥K<br/>封存于USIM与归属网络"] --> CKIK["CK 与 IK"]
    CKIK --> KAUSF["K_AUSF<br/>归属侧锚点密钥"]
    KAUSF --> KSEAF["K_SEAF<br/>拜访侧锚点密钥"]
    KSEAF --> KAMF["K_AMF<br/>接入管理密钥"]
    KAMF --> KNAS["K_NASint 与 K_NASenc<br/>保护NAS信令"]
    KAMF --> KGNB["K_gNB<br/>基站密钥"]
    KGNB --> KRRC["K_RRCint 与 K_RRCenc<br/>保护RRC信令"]
    KGNB --> KUP["K_UPint 与 K_UPenc<br/>保护用户面数据"]
```

各级密钥的派生关系可以简化表示为（实际KDF还包含固定前缀等参数，此处为便于理解做了精简）：

$$K_{AUSF} = \mathrm{KDF}(CK \,\|\, IK,\ SNN)$$

$$K_{SEAF} = \mathrm{KDF}(K_{AUSF},\ SNN)$$

$$K_{AMF} = \mathrm{KDF}(K_{SEAF},\ ABBA,\ SNN)$$

$$K_{gNB} = \mathrm{KDF}(K_{AMF},\ \text{NAS上行COUNT})$$

$$K_{RRCint} = \mathrm{KDF}(K_{gNB},\ \text{完整性算法编号})$$

这棵树每个分支的设计意图，值得逐条品味：

| 密钥 | 生成/持有的位置 | 保护对象 | 什么时候更新 |
|------|----------------|----------|--------------|
| K | USIM与归属鉴权中心 | 一切密钥之根 | 永不更新，永不传输 |
| K_AUSF | AUSF | 派生拜访侧锚点 | 每次认证 |
| K_SEAF | SEAF（通常与AMF共址） | 派生K_AMF | 每次认证成功后由AUSF下发 |
| K_AMF | AMF | NAS信令与基站密钥 | AMF变更或周期性刷新 |
| K_gNB | gNB | RRC与用户面密钥 | **每次切换/换基站都刷新** |
| K_RRCint/enc | gNB与UE | RRC信令 | 随K_gNB更新 |
| K_UPint/enc | gNB与UE | 用户面数据 | 随K_gNB更新 |

**为什么要长成树，而不是认证完直接发一把"万能钥匙"？** 三个理由：

1. **域隔离**：NAS密钥从K_AMF派生，空口密钥从K_gNB派生，两条分支互不推导。即使基站被攻破、空口密钥泄露，攻击者也无法反推出NAS层的密钥，更不可能逆推到根密钥K——KDF是单向函数，"只能往下生，不能往上爬"。
2. **新鲜性**：K_gNB的派生输入里绑定了NAS层的COUNT计数器，每换一次基站、每触发一次密钥刷新，空口密钥就换一套。这意味着攻击者即使录下了一段空口流量，这段流量的密钥也不会被复用到下一段——切换本身就成了"自动换锁"。
3. **权限下放的最小化**：AMF只需要NAS密钥和派生基站密钥的能力；gNB只拿到自己的那套空口密钥；AUSF和归属网络则始终不把任何下层密钥交出去。每一级节点只持有"往下看一层"的密钥，暴露面被压到最小。

还有一个容易被忽略的小角色：**ABBA参数**。它在派生K_AMF时参与输入，作用是把"本次安全激活使用的算法编号"绑定进密钥材料里，**防止攻击者把算法协商消息重放/篡改，诱使网络和终端降级到弱算法**（所谓"算法降级攻击"）。调试安全模式失败问题时，算法能力协商与ABBA的配合是值得检查的一环。

## 六、5G-AKA与EAP-AKA'：标准里的"二选一"

一个常见的认知盲区是以为5G只有一种认证方法。实际上标准定义了两种：**5G-AKA**和**EAP-AKA'**。由归属网络根据签约/卡的能力选择，拜访网络照单执行。两者的核心差异：

| 维度 | 5G-AKA | EAP-AKA' |
|------|--------|----------|
| 协议形态 | NAS层私有的请求-响应消息 | 借用成熟的EAP协议框架，消息封装在NAS里传输 |
| 认证裁决点 | AUSF（两轮比对，拜访侧先比哈希） | EAP服务器（AUSF）主导三轮EAP消息交互 |
| 结果通知 | 终端无法从认证消息本身获知"归属侧是否终判通过" | 有显式的EAP-Success/EAP-Failure，**结果对终端透明** |
| 密钥原料 | CK/IK直接派生K_AUSF | 先把SNN混入派生CK'/IK'，再派生K_AUSF |
| 复杂度 | 消息轮次少，时延略优 | 交互轮次多，但复用既有EAP生态，扩展性好 |

两种方法殊途同归：最终都产生K_AUSF，之后进入同一棵密钥推导树。至于现网部署选哪种，标准允许多种实现，具体以运营商网络配置和USIM能力为准。

## 七、现网实战：这套原理在哪些调试场景里救你

### 7.1 注册拒绝的排查地图

注册被拒时，拒绝消息里携带的原因值是第一线索。与认证/安全强相关的常见原因：

| 现象 | 可能原因 | 排查方向 |
|------|----------|----------|
| 注册被拒，原因为"非法UE" | 卡被列入黑名单/非法卡 | 查归属网络签约状态与EIR |
| 注册被拒，"5G业务不允许" | 签约数据未开通5G、HLR/UDM数据不一致 | 核对签约数据同步状态 |
| 认证响应后收到Security Mode Reject或MAC failure | 完整性校验失败：双方密钥不一致或算法不匹配 | 核对USIM状态、算法能力协商、AMF侧安全上下文 |
| 认证响应携带Synch failure | SQN序列号异常 | 触发重同步；排查是否卡被拔插到多台设备、虚拟卡滥用 |
| 注册被拒，"UE安全能力不匹配" | 终端上报的安全算法能力与网络期望不符 | 核对终端5G-EA/IA能力上报与网络配置 |

再配一张排查决策图，遇到注册拒绝可以按图索骥：

```mermaid
flowchart TD
    REJ["收到注册拒绝"] --> Q{"看拒绝原因值"}
    Q -->|非法UE| A1["查签约与EIR黑名单"]
    Q -->|5G业务不允许| A2["查HLR与UDM签约数据同步"]
    Q -->|安全能力不匹配| A3["查终端算法能力上报与网络配置"]
    Q -->|MAC失败| A4["查SQN状态与重同步记录"]
    Q -->|拥塞| A5["过一会再试 属正常负荷控制"]
```

### 7.2 抓包与日志的正确姿势

- **别再找IMSI了**：注册初始消息里只有SUCI。要定位真实用户，走归属侧UDM的SUCI-SUPI映射查询，或者用UE的 PEI/5G-GUTI 等辅助信息交叉定位。
- **密钥永远不出现在信令里**：NGAP/NAS日志里你只会看到**算法指示**（用了哪个加密算法、哪个完整性算法）和密钥刷新计数（NCC），任何日志里出现"明文密钥"都意味着设备实现有严重安全问题。
- **认证成功不等于安全激活完成**：认证之后网络还要下发Security Mode Command完成NAS安全激活，这一步失败同样会导致注册中断。排查时把"Authentication"和"Security Mode"两个阶段分开看，能少走很多弯路。

### 7.3 三个常见误解

**误解一："SUCI加密了，所以所有信令都是安全的。"** 错。SUCI只保护初始注册时的用户标识这一个字段，真正的信令保护要等NAS安全激活完成、K_NASint/K_NASenc启用之后才开始。在认证完成之前的那几条明文NAS消息（如注册请求本身），恰好是协议设计上刻意最小化的。

**误解二："认证失败就是卡坏了。"** SQN不同步、归属网络签约数据不一致、算法能力不匹配，表现都可能是认证或安全激活失败。先分清失败发生在哪个阶段、携带什么原因值，再下结论。

**误解三："5G-GUTI和SUCI是一回事。"** 恰恰相反，它们是一对互补设计：SUCI用于"注册前还不知道网络是谁"的首次亮相，5G-GUTI用于注册成功后的日常身份（网络分配的临时标识，周期性更换）。日常场景下终端用5G-GUTI，只有网络认不出它时才退回用SUCI重新亮明身份（隐藏形态）。

## 常见问题

**Q: 5G-AKA和EAP-AKA'到底有什么本质区别？**
A: 本质区别在**认证裁决权和结果通知机制**。5G-AKA里拜访网络先用哈希初判、AUSF终判，但终端拿不到"归属侧是否认可"的显式回执；EAP-AKA'复用EAP框架，归属侧主导，终端能明确收到EAP-Success或Failure。安全目标两者都能达成，工程上主要差异是消息轮次和生态兼容性。选择权在归属网络，拜访网络被动适配。

**Q: 密钥树里为什么偏偏是K_gNB每次切换都更新，而K_AMF不用？**
A: 这体现"暴露面与刷新频率成正比"的思路。gNB数量最多、物理暴露风险最高、且服务千变万化的空口环境，所以给它配最高频的密钥轮换——切换一次换一把，即使某把空口密钥泄露，影响范围也被限制在一次切换窗口内。而AMF数量少、位于运营商机房深处，K_AMF只在注册/AMF变更等关键节点刷新即可，频繁刷新反而引入信令开销。

**Q: 用户面的数据默认加密吗？不加密会怎样？**
A: 空口用户面**加密是可协商的**（网络在安全激活时指示），但**完整性保护是新引入的可选能力**——4G时代用户面完全没有完整性保护，5G首次支持了它。对话音、视频这类流量，业界通常认为加密收益有限（内容本身不敏感且开销大）；但对工业控制、遥测类小包敏感数据，开启UP完整性保护价值很高。这正是5G面向行业场景的安全设计之一。

**Q: 用户投诉"换卡后频繁注册失败"，从密钥体系角度怎么分析？**
A: 最典型的是**SQN计数器失步**：归属网络里记录的SQN与卡内计数器严重偏离（比如卡在其他设备/网络环境被过度使用），认证时终端判定序列号异常，反复触发Synch failure和重同步。排查时先在归属侧看该用户的鉴权重同步记录，确认失步后按流程处理，通常一次成功的重同步即可恢复。

**Q: 手机丢了，捡到的人能用我的5G吗？**
A: 密钥体系的设计让这件事非常困难。根密钥K封在USIM卡的安全芯片里，读不出来；认证挑战每次都是新的随机数，录制的认证响应无法重放（SQN会挡住）；PIN锁开启时卡本身也无法使用。真正薄弱环节从来不是密码学，而是**没有设PIN的卡+挂失不及时**——所以安全机制再好，运营流程（快速挂失、卡冻结）才是最后一环。

## 参考来源

3. [3GPP 5G System Security](https://www.3gpp.org/technologies/5g-system-security) — 3GPP官方对5G安全架构要点的介绍
4. [RFC 5448: EAP-AKA'](https://www.rfc-editor.org/rfc/rfc5448) — EAP-AKA'认证方法的标准定义文档

---
> 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。
> 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。