<!-- title: 5G SUCI加密保护ECIES全链拆解 -->
<!-- domain: security -->

# 5G SUCI 加密保护机制（ECIES）全链拆解：从 SUPI 到 SIDF 解密

## 一、为什么 5G 必须发明 SUCI：IMSI Catcher 的终结

在 4G/LTE 时代，用户首次接入网络时，永久身份 IMSI 会以**明文形式**通过空口传输。这一设计缺陷催生了 IMSI Catcher（伪基站）这一最经典、最廉价的移动通信攻击手段：攻击者只需伪装成基站广播一个陌生的 PLMN，并主动发起 Identity Request，UE 就会老老实实地把自己的 IMSI 明文回传——此后跟踪、定位、用户画像、重放攻击均可展开。Stingray、IMSI-catcher 类设备在 4G 网络中几乎没有门槛。

5G 系统在 3GPP TS 33.501（Security Architecture and Procedures）中给出了根本性的修复方案：**永久标识符 SUPI（Subscription Permanent Identifier）永不以明文在空口出现**。UE 在初始注册时，先用部署在 USIM 上的**归属网络公钥（Home Network Public Key, HNpk）**对 SUPI 的可路由部分之外的 MSIN 进行非对称加密，生成**用户隐藏标识符 SUCI（Subscription Concealed Identifier）**，再把 SUCI 作为 Registration Request 消息中的 `5GS registration type` 携带的 mobile identity 发送出去。空口上监听者能看到的只有加密后的密文，无法回溯到具体的 SUPI。

这一机制的密码学核心是 **ECIES（Elliptic Curve Integrated Encryption Scheme，椭圆曲线集成加密方案）**，定义在 TS 33.501 Annex C。本文将逐比特、逐信令消息地拆解 SUCI 的生成、传输、在 SIDF（Subscription Identifier De-concealing Function）中解密还原 SUPI 的完整链路，并给出抓包识别方法和排错实战。

> 本文聚焦 TS 33.501 Annex C.3（ECIES Protection Scheme）与 TS 23.502 Section 4.2.2.2（Registration）中的身份标识使用，不泛泛讨论安全架构。

## 二、核心标识符与角色：SUPI、SUCI、GUTI、SIDF

在拆解信令前，必须厘清 5G 身份标识体系中的几组关键概念，它们构成了隐私保护的"轮换梯队"。

| 标识符 | 全称 | 明文/密文 | 空口可见 | 用途 | 定义 |
|--------|------|-----------|----------|------|------|
| **SUPI** | Subscription Permanent Identifier | 明文（内部） | 否（永不） | 永久身份，IMSI/SUPI 是它的子集 | TS 23.501 §5.9.2 |
| **SUCI** | Subscription Concealed Identifier | 密文 | 是（首次注册） | 隐藏 SUPI 的可路由信息 | TS 33.501 Annex C |
| **5G-GUTI** | 5G Globally Unique Temporary UE Identity | 临时 | 是 | 认证成功后轮换，避免重复用 SUCI | TS 23.501 §5.9.4 |
| **PEI** | Permanent Equipment Identity | 明文 | 是（加密后） | 设备标识（IMEI） | TS 23.501 §5.9.5 |
| **GUAMI** | Globally Unique AMF Identifier | 明文 | 是 | AMF 寻址 | TS 23.501 §5.9.3 |

**SUPI 的结构**（IMSI 类型）：`MCC + MNC + MSIN`。其中 MCC（移动国家码）、MNC（移动网络码）是**公开的路由信息**，必须明文以便网络路由；而 MSIN（移动用户标识号）才是真正标识"具体哪个人"的隐私核心。SUCI 的设计正是：**保留 MCC/MNC/Routing Indicator 明文以供路由，仅加密 MSIN**。

**SIDF（Subscription Identifier De-concealing Function）**是 5G 核心网中唯一持有**归属网络私钥 HNpriv** 的逻辑功能。它在 TS 33.501 中被规定为 UDM（Unified Data Management）的一个组成部分（deployment 上可分离部署以隔离私钥）。当 AMF 收到一个无法用 5G-GUTI 解析的 SUCI 时，会调用 UDM 的 `Nudm_UEAuthentication_Get` 服务，SIDF 用 HNpriv 完成 ECIES 的逆运算，恢复出 SUPI，再据此执行鉴权向量获取。

## 三、USIM 侧的预置：HNpk、Protection Scheme ID 与 Routing Indicator

ECIES 能否工作的前提，是 USIM 上已经预置了归属网络的公钥体系。根据 TS 31.102（USIM 应用特性），USIM 文件系统 `ADF(USIM)/USIM/` 下必须包含以下与 SUCI 相关的字段（EF 文件）：

| USIM EF | 字段 | 作用 |
|---------|------|------|
| `EF_IMSI` (6F07) | IMSI | 明文 SUPI 来源（含 MCC/MNC/MSIN） |
| `EF_Keys` / `EF_USIM_AUTH_KEYS` | Home Network Public Key (HNpk) | ECIES 公钥（Profile A/B 对应不同曲线） |
| `EF_USIM_AUTH_KEYS` | Protection Scheme ID | 0=null, 1=Profile A, 2=Profile B |
| `EF_USIM_AUTH_KEYS` | Home Network Public Key ID | 公钥标识符（0-255），用于公钥轮换 |
| `EFRoutingIndicator` (4F01) | Routing Indicator | 路由指示符，用于 AMF/UDM 路由 |

**设计意图**：Home Network Public Key ID 这个字段至关重要。它允许运营商在不换卡的前提下**滚动更新公钥**（key rotation）。一旦某把公钥被怀疑泄露或需要按周期更换，运营商只需在网络侧部署新公钥并赋予新的 Key ID，新发的 SUCI 会携带新 Key ID，SIDF 据此选择对应的私钥解密。旧公钥可在过渡期内继续服务存量用户。这是一种典型的"密钥版本管理"思想。

**为什么把公钥放进 USIM 而非 ME（手机）？**因为 ME 是不可信的——可以被刷机、root、替换。将 HNpk 绑定在 USIM（一个独立的、防篡改的安全芯片环境）上，可以保证即使用户更换手机，SUCI 加密能力依然随卡走，且运营商对密钥分发有完全控制权。

## 四、SUCI 生成全链：ECIES 逐比特运算

这是本文最核心的部分。我们以 **ECIES Profile A（NIST P-256 曲线）** 为例，逐字节拆解 USIM/ME 如何把 MSIN 变成 SUCI 的 scheme-output。算法定义在 **TS 33.501 Annex C.3.2**。

### 4.1 SUCI 的总体结构

```
SUCI = <suci-type> || <Home Network Identifier (MCC-MNC)> || <Routing Indicator>
       || <Protection Scheme ID> || <Home Network Public Key ID>
       || <Scheme Output>
```

其中：
- `suci-type`：标识 SUPI 类型（0=IMSI-based，1=Network-specific）
- `Home Network Identifier`：MCC + MNC，**明文**，用于路由
- `Routing Indicator`：明文，1-4 位，用于跨运营商网络时引导到正确的 UDM/归属网络
- `Protection Scheme ID`：保护方案标识（0/1/2）
- `Home Network Public Key ID`：公钥 ID（0-255）
- `Scheme Output`：**全部密文部分**，含临时公钥 + 密文 + MAC

明文部分（MCC/MNC/Routing Indicator）和密文部分（Scheme Output）的分界，正是隐私保护的关键边界：监听者能知道"这是哪个运营商的卡"，但**无法知道是哪张卡**。

### 4.2 ECIES Profile A 计算流程

```mermaid
flowchart TD
    A[USIM 取出 MSIN + HNpk + Key ID + Scheme ID] --> B[UE 生成临时私钥 d 随机数]
    B --> C[计算临时公钥 R = d · G<br/>G 为 P-256 基点]
    C --> D[ECDH 共享点 S = d · HNpk<br/>S = x, y]
    D --> E[KDF Oakley-IPP<br/>输入: x坐标 &#124;&#124; 临时公钥R<br/>Key: 16字节全0]
    E --> F[派生 eK 加密密钥 16B<br/>派生 iK 完整性密钥 16B]
    F --> G[AES-128-CTR 加密 MSIN<br/>IV = 全0, 输出 ciphertext]
    G --> H[HMAC-SHA-256 iK, ciphertext<br/>取前8字节 = MAC-tag]
    C --> I[Scheme Output = R &#124;&#124; ciphertext &#124;&#124; MAC]
    H --> I
    I --> J[拼接明文路由信息<br/>生成完整 SUCI]
    J --> K[放入 Registration Request<br/>mobile identity 字段]
```

**第一步：生成临时密钥对。**UE 为每次 SUCI 生成生成一个全新的随机临时私钥 `d`（256 bit），计算临时公钥 `R = d · G`（G 是 P-256 的基点）。临时公钥 R 在 Profile A 下是 **65 字节**（未压缩点格式：`0x04 || x(32B) || y(32B)`）。每次注册都换新的临时密钥对，这是 ECIES 提供**前向保密**语义的关键——即使 HNpriv 将来被泄露，已捕获的 SUCI 密文也无法被追溯解密（因为临时私钥 d 用完即弃，从不存储或传输）。

**第二步：ECDH 共享密钥派生。**UE 计算 ECDH 共享点 `S = d · HNpk`（用 UE 的临时私钥 d 与运营商公钥 HNpk 做标量乘法），得到点 `S = (x, y)`。这是一个**椭圆曲线离散对数困难问题**——攻击者即使同时捕获了临时公钥 R 和 HNpk，也无法反推出 d 或 S。

**第三步：KDF（密钥派生函数）。**TS 33.501 定义了一个基于 HMAC-SHA-256 的 KDF（Annex C.3.2）：

```
key  = 0x00000000000000000000000000000000   (16 字节全 0)
msg  = (x-coordinate of S, 32B) || (ephemeral public key R, 65B for Profile A)
out  = HMAC-SHA-256(key, msg)              (32 字节)
eK   = out[0:16]                           (加密密钥)
iK   = out[16:32]                          (完整性密钥)
```

注意 KDF 的输入同时包含了**共享密钥的 x 坐标**和**临时公钥 R**——后者把"这次会话的临时密钥"绑定进了派生过程，防止重放与混淆。

**第四步：加密 MSIN。**用 eK 对 MSIN 做 **AES-128 in CTR mode**（计数器模式），IV 固定为全 0。CTR 模式是流密码性质，密文长度等于明文长度。Profile A 与 Profile B **加密算法相同**（都用 AES-128-CTR）。

**第五步：完整性 MAC。**用 iK 对密文做 **HMAC-SHA-256**，并取**前 8 字节（64 bit）**作为 MAC-tag。这 64 位 MAC 在空口带宽约束下提供了足够的完整性保护，能检测密文被篡改、替换。最终：

```
Scheme Output = ephemeral public key R (65B) || ciphertext (len(MSIN)) || MAC-tag (8B)
```

### 4.3 Profile A vs Profile B 对比

| 维度 | ECIES Profile A | ECIES Profile B |
|------|----------------|----------------|
| **Protection Scheme ID** | 1 | 2 |
| **椭圆曲线** | NIST P-256 (secp256r1) | Curve25519 |
| **临时公钥长度** | 65 字节（未压缩点） | 32 字节 |
| **加密算法** | AES-128-CTR | AES-128-CTR |
| **MAC 算法** | HMAC-SHA-256（取 8B） | HMAC-SHA-256（取 8B） |
| **KDF** | HMAC-SHA-256 based | HMAC-SHA-256 based |
| **空口开销** | 较大（R 占 65B） | 较小（R 占 32B） |
| **抗侧信道** | P-256 实现需注意常时间运算 | Curve25519 原生抗侧信道 |

**设计意图**：保留两套曲线是 3GPP 标准的典型"保险"策略。NIST P-256 是美国 NIST 标准化曲线，生态成熟、硬件加速普及；Curve25519 由 Daniel J. Bernstein 设计，被认为在实现安全性（抗时序侧信道）和效率上更优，被 IETF/TLS 广泛采纳。运营商可按部署偏好选择，USIM 中通过 Protection Scheme ID 标识使用了哪一套。

### 4.4 Null Scheme（空方案）

Protection Scheme ID = 0 表示 **Null Scheme**——SUPI/MSIN 以**明文形式直接放入 scheme-output**，不做任何加密。这等同于 4G 的 IMSI 明文传输，**彻底丧失隐私保护**。

为什么标准要保留它？作为**兜底方案**：当 USIM 未预置 HNpk、或 HNpk 不可用、或测试/应急场景时，保证基本流程可通。但在生产网络中，开启 Null Scheme 等于把 5G 的隐私优势退化为 4G，运营商应严格监控并避免。

## 五、空口信令链路：SUCI 如何进入 Registration Request

SUCI 生成后，通过 NAS 层进入空口。完整的初始注册信令链路见 TS 23.502 Section 4.2.2.2（Registration procedure）。

```mermaid
sequenceDiagram
    autonumber
    participant UE
    participant gNB
    participant AMF
    participant UDM as UDM/SIDF
    participant AUSF as AUSF
    participant ARPF as ARPF

    Note over UE: 本地无有效 5G-GUTI<br/>或 GUTI 在 AMF 解析失败
    UE->>UE: USIM 用 HNpk 对 MSIN<br/>做 ECIES 生成 SUCI
    UE->>gNB: RRC SetupRequest
    gNB->>UE: RRC Setup
    UE->>gNB: RRC SetupComplete<br/>(携带 NAS Registration Request)
    Note over UE,gNB: NAS msg: Registration Request<br/>mobile identity = SUCI
    gNB->>AMF: NGAP Initial UE Message<br/>(含 Registration Request, SUCI)
    AMF->>UDM: Nudm_UEAuthentication_Get<br/>(SUCI, SNN)
    Note over UDM: SIDF 用 HNpriv 做 ECIES 逆运算<br/>恢复 SUPI 明文
    UDM->>ARPF: 取得 SUPI, 生成鉴权向量<br/>RAND/AUTN/XRES*
    ARPF-->>UDM: 鉴权向量
    UDM-->>AMF: 返回 SUPI + 5G AV (RAND/AUTN/XRES*/KAUSF)
    AMF->>AUSF: Nausf_UEAuthentication_Authenticate
    AUSF->>UE: NAS Authentication Request<br/>(RAND, AUTN, ngKSI)
    Note over UE: USIM 验证 AUTN<br/>计算 RES*
    UE-->>AUSF: NAS Authentication Response (RES*)
    AUSF->>AUSF: 验证 RES* == XRES*
    AUSF-->>AMF: 鉴权成功
    AMF->>UE: NAS Security Mode Command<br/>(激活 NAS 安全, 加密算法)
    Note over UE,AMF: 此后 NAS 信令加密+完整性保护
    AMF->>UE: Registration Accept<br/>(分配新 5G-GUTI)
    Note over UE,AMF: 后续用 5G-GUTI 标识,<br/>避免重复使用 SUCI
```

### 关键 Information Element 解析

**消息①：NAS Registration Request（TS 24.501 §8.2.7）**

这是 SUCI 进入网络的核心载体。关键 IE：

| IE | 含义 | 取值示例 |
|----|------|----------|
| `Extended protocol discriminator` | 协议鉴别 | 0x7E（5GS mobility management） |
| `Security header type` | 安全头类型 | 0（未保护，明文 NAS） |
| `5GS registration type` | 注册类型 | 001 = initial registration |
| `ngRAN generation` / `5GS registration type` | 注册原因 | initial / periodic 等 |
| **`Mobile identity`** | **移动身份标识** | **此处携带 SUCI** |
| `NgKSI` | 鉴权密钥集标识 | 初始注册时无效 |

`Mobile identity` 这个 IE 内部又分多个子字段来编码 SUCI（TS 24.501 §9.11.3.4）：
- `type of identity`：010 = SUCI
- `SUCI` 内含：`SUPI type` + `MCC/MNC` + `Routing Indicator` + `Protection scheme ID` + `Home network public key ID` + `Scheme output`

**设计意图**：注意第 2 步——`Security header type = 0`，意味着 Registration Request 是**明文 NAS**。这是必然的"鸡生蛋"困境：要加密 NAS 就要先建立密钥，而建立密钥（鉴权）又要先知道 SUPI，知道 SUPI 又要先传 SUCI。所以 SUCI 这条消息必须在 NAS 安全激活之前发送，它**只能依赖 ECIES 自身的密码学保护**，而非 NAS 层加密。这就是为什么 SUCI 不能用简单的对称加密——空口上 UE 和网络之间此时还没有任何共享密钥。

**消息④：Nudm_UEAuthentication_Get（SBI 服务，TS 29.503）**

AMF 向 UDM 发起的 SBI HTTP 请求，请求体中携带 SUCI。UDM 内的 SIDF 触发解密。SBI 接口走的是 HTTPS（TLS），所以 SUCI 在核心网内部传输是受 TLS 保护的，但 ECIES 是额外的一层端到端保护——只有归属网络的 SIDF 能解密，途经的任何 AMF（哪怕是漫游地的 V-AMF）都无法获知 SUPI。

## 六、SIDF 侧解密还原 SUPI：ECIES 逆运算

SIDF 持有归属网络私钥 HNpriv，对应于 USIM 中 HNpk 的那一对密钥。解密是 ECIES 正向运算的镜像（TS 33.501 Annex C.3.2）：

```mermaid
flowchart TD
    A[SIDF 收到 SUCI] --> B[解析出 Protection Scheme ID<br/>和 Home Network Public Key ID]
    B --> C[据 Key ID 选取对应的 HNpriv]
    C --> D[取出 Scheme Output 中的<br/>临时公钥 R, ciphertext, MAC-tag]
    D --> E[ECDH 共享点 S' = HNpriv · R<br/>S' = x', y']
    E --> F[同样的 KDF<br/>输入: x' &#124;&#124; R]
    F --> G[派生 eK, iK]
    G --> H[HMAC-SHA-256 iK, ciphertext<br/>取前8字节, 校验 == MAC-tag]
    H --> I{MAC 校验通过?}
    I -->|否| J[拒绝, SUCI 被篡改/伪造]
    I -->|是| K[AES-128-CTR 解密 eK, ciphertext<br/>恢复 MSIN 明文]
    K --> L[拼接 MCC/MNC + MSIN<br/>还原完整 SUPI]
    L --> M[返回 SUPI 给鉴权流程]
```

**关键密码学保证**：

1. **ECDH 对称性**：UE 算 `S = d · HNpk`，SIDF 算 `S' = HNpriv · R = HNpriv · (d · G) = d · (HNpriv · G) = d · HNpk = S`。两者得到**完全相同的共享点**（椭圆曲线标量乘法的结合律），这是 ECIES 双方能独立派生出相同密钥的数学基础，整个过程从不交换私钥。

2. **MAC 先验校验**：解密前先验 MAC-tag，保证只有持有正确 HNpriv 的 SIDF 才能通过校验，且能检测任何传输/篡改。这是"先认证后解密"（encrypt-then-MAC）的正确顺序，避免对篡改密文做无意义解密，也防御选择密文攻击。

3. **Key ID 路由**：SIDF 根据 Home Network Public Key ID 从私钥库中选取对应的 HNpriv，支撑公钥滚动更新。

SIDF 解密出 SUPI 后，将 SUPI 传给 ARPF（Authentication Repository and Processing Function）生成鉴权向量，5G-AKA'/EAP-AKA' 鉴权流程随之展开。注意：**SUCI 只在首次注册（或 GUTI 失效）时使用一次**，鉴权成功并分配 5G-GUTI 后，后续所有信令都用临时的 5G-GUTI 标识 UE，SUCI 被尽量少用。

## 七、SUCI 使用频率限制：防主动去匿名化

TS 33.501 §6.12.2 规定了一个重要的防攻击机制：**UE 必须限制生成新 SUCI 的频率**。攻击者的一种去匿名化手段是反复触发 UE 发送 SUCI（例如反复让 UE 重选到恶意基站），结合时间/位置关联来缩小候选范围。

为此，UE 实现中维护一个"上次生成 SUCI 的时间戳"，只有当**距离上次使用 SUCI 超过运营商配置的最小间隔**（provisioning 给定），或**当前无有效 5G-GUTI**时，才允许重新生成 SUCI。配合 5G-GUTI 的轮换，正常情况下 SUCI 在网络中长期只出现有限次数，极大压缩了关联攻击的窗口。

## 八、抓包识别与排错实战

### 8.1 抓包如何识别 SUCI 流程

在 5G 核心网抓包（NGAP/NAS over N2、SBI over N8）中：

- **N2 接口（NGAP）**：`Initial UE Message` 中携带的 NAS `Registration Request`，查看 `Mobile identity` IE，`type of identity = 010`（SUCI）。可读出明文的 MCC/MNC/Routing Indicator/Protection Scheme ID/Key ID，以及密文的 Scheme Output。
- **N8 接口（SBI）**：`POST /ue-authentications/{suci}/security-information`，URL 中直接以 SUCI 作为路径参数，HTTP body 为 `{suci: "...", servingNetworkName: "..."}`。
- **tshark 过滤**：`nas_5gs.mm.mobile_identity.type == 2`（SUCI 类型）；SBI 过滤 `http.request.uri contains "ue-authentications"`。

### 8.2 常见故障点

| 故障现象 | 可能原因 | 排错思路 |
|----------|----------|----------|
| SIDF 解密失败、MAC 校验不过 | USIM 的 HNpk 与网络 HNpriv 不匹配（公私钥对不一致） | 核对 USIM 烧录的 HNpk 与 UDM/SIDF 配置的密钥对是否同源；检查 Key ID 映射 |
| 用了 Null Scheme，SUPI 明文暴露 | USIM 未预置 HNpk 或 Scheme ID=0 | 确认 USIM 烧录脚本写入正确的 Protection Scheme ID（1 或 2）和 HNpk |
| 漫游场景 SUCI 路由错误 | Routing Indicator 配置错误 | 核对 USIM 的 Routing Indicator，确保跨网时引导到正确归属 UDM |
| 公钥轮换后旧用户解密失败 | Key ID 映射缺失 | SIDF 私钥库需同时保留新旧 HNpriv，按 Key ID 路由 |
| Profile A/B 实现互操作失败 | 加密曲线实现不一致 | 抓包核对 Protection Scheme ID，确认双方曲线/编码一致 |
## 九、常见问题

**Q1：SUCI 和 5G-GUTI 有什么区别？什么时候用哪个？**
A：SUCI 是**永久身份 SUPI 的加密形态**，只在首次注册、或 UE/AMF 没有可用 5G-GUTI 时使用一次，目的是让网络在安全上下文建立前识别"你是谁"。5G-GUTI 是**临时身份**，由 AMF 在鉴权成功后分配，此后所有信令都用 5G-GUTI 标识，避免反复使用 SUCI。一句话：SUCI 解决"首次如何安全地报上永久身份"，5G-GUTI 解决"如何长期不暴露永久身份"。

**Q2：为什么 SUCI 加密用非对称 ECIES，而不是对称加密？**
A：因为 Registration Request 发送时，UE 和网络之间**还没有任何共享密钥**（密钥要等鉴权后才有）。对称加密要求双方先共享密钥，陷入"先有鸡还是先有蛋"。非对称加密让 UE 用网络的公钥加密、网络用私钥解密，无需预先共享秘密，正好契合"首次接触、零信任前置"的场景。

**Q3：ECIES 用了临时密钥对，这带来什么安全收益？**
A：临时密钥对提供**前向保密（forward secrecy）语义**。临时私钥 d 用完即弃、从不存储或传输。即使将来 HNpriv 被泄露，攻击者也无法解密历史上抓取的 SUCI 密文——因为他们无法恢复每次会话的 d。同时，每次 SUCI 用不同的临时公钥，密文每次都不同，阻断了基于密文重复的关联。

**Q4：Profile A 和 Profile B 怎么选？**
A：技术上两者都能满足安全要求。Profile A（P-256）生态成熟、硬件加速广泛、与 NIST 标准化体系一致，适合追求兼容与合规审计的部署。Profile B（Curve25519）临时公钥更短（省空口带宽）、原生抗时序侧信道、实现安全性更优，适合追求实现安全与效率的部署。选择取决于运营商的密钥策略与设备支持情况，USIM 中通过 Protection Scheme ID 标明。

**Q5：如果 USIM 没有 HNpk，会发生什么？**
A：UE 将退回 **Null Scheme**（Protection Scheme ID=0），SUPI/MSIN 以明文放入 SUCI 的 scheme-output，等同 4G 的 IMSI 明文传输，丧失隐私保护。这是兜底行为，生产网络应确保所有在网 USIM 都预置了 HNpk 并配置正确的 Scheme ID，避免退化为明文。

## 参考来源

1. [3GPP TS 33.501 — Security Architecture and Procedures for 5G System](https://www.3gpp.org/dynareport/33501.htm) — Annex C.3 ECIES Protection Scheme、§6.12 Subscription Identifier Privacy
2. [3GPP TS 23.502 — Procedures for the 5G System](https://www.3gpp.org/dynareport/23502.htm) — Section 4.2.2.2 Registration Procedure
3. [3GPP TS 23.501 — System Architecture for the 5G System](https://www.3gpp.org/dynareport/23501.htm) — §5.9 Identifier handling、SIDF/UDM 功能
4. [NIST White Paper — Protecting Subscriber Identifiers with Subscription Concealed Identifier (SUCI) Protection](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.36A.pdf) — SUCI 启用机制与隐私分析
5. [ShareTechNote / Techplayon — 5G SUPI and SUCI NAS Signalling](https://www.techplayon.com/5g-identifiers-supi-and-suci/) — NAS 消息中 SUCI 编码与抓包识别

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