<!-- title: 5G SUCI隐私保护与ECIES双Profile加密信令拆解 -->
<!-- domain: security -->

# 5G SUCI隐私保护与ECIES双Profile公钥加密方案信令拆解

## 一、SUPI隐私威胁与SUCI的设计动机

### 1.1 从IMSI Catcher到SUPI保护

在4G EPS中，UE的永久标识IMSI以明文形式通过空口传输，这一设计缺陷被广泛利用——伪基站（IMSI Catcher / Stingray）只需被动监听Radio Interface，即可捕获用户的IMSI，进而实施用户追踪、行为分析甚至定向攻击。3GPP SA3工作组在5G系统安全架构设计之初，就将"空口用户永久标识保护"列为核心安全目标之一。

3GPP TS 33.501 Section 5.9明确提出：**SUPI（Subscriber Permanent Identifier）不得以明文形式通过空口传输**（紧急呼叫等特殊场景除外）。取而代之的是**SUCI（Subscription Concealed Identifier）**——一个基于公钥加密的SUPI隐藏标识。

### 1.2 SUCI设计的核心安全属性

SUCI方案在TS 33.501 Section 6.12中定义，其设计目标是实现以下安全属性：

| 安全属性 | 实现机制 | 规范依据 |
|----------|---------|---------|
| **机密性** | ECIES公钥加密，仅归属网SIDF可解密 | TS 33.501 §6.12.2/6.12.3 |
| **不可关联性** | 每次Registration生成新的临时密钥对 | TS 33.501 §6.12.1 |
| **完整性** | HMAC-SHA-256 MAC标签防篡改 | TS 33.501 Annex C.6 |
| **前向安全性** | 临时密钥对 + 静态公钥的ECDH | TS 33.501 §6.12.2 |
| **抗重放** | 临时公钥每次不同，无法复用 | TS 33.501 §6.12.1 |

```mermaid
graph TB
    subgraph "4G EPS - IMSI暴露"
        UE4[UE] -->|IMSI 明文| ENB4[eNodeB]
        ENB4 -->|IMSI 明文| MME4[MME]
        ATK[伪基站/IMSI Catcher] -.->|被动监听IMSI| UE4
    end

    subgraph "5GS - SUCI保护"
        UE5[UE/USIM] -->|SUCI 加密| GNB5[gNB]
        GNB5 -->|SUCI 加密| AMF5[AMF]
        AMF5 -->|SUCI 加密| SIDF5[UDM/SIDF]
        SIDF5 -->|解密获得SUPI| SIDF5
        ATK5[攻击者] -.->|仅见密文| UE5
    end

    style ATK fill:#ff6b6b,color:#fff
    style ATK5 fill:#51cf66,color:#fff
```

## 二、SUCI格式结构详解

### 2.1 SUCI的组成字段

SUCI的格式定义在TS 23.003 Section 2.2A和TS 24.501 Section 9.11.3.4中。以IMSI类型的SUPI为例，完整的SUCI结构如下：

```
SUCI = <SUPI Type> <MCC> <MNC> <Routing Indicator> <Protection Scheme ID> <Home Network Public Key ID> <Scheme Output>
```

| 字段 | 长度 | 说明 | 取值示例 |
|------|------|------|---------|
| **SUPI Type** | 4 bits | 标识类型：0=IMSI, 1=NAI | 0 (IMSI) |
| **MCC** | 12 bits | 移动国家码 | 460 (中国) |
| **MNC** | 8-12 bits | 移动网络码 | 00 (中国移动) |
| **Routing Indicator** | 1-4 digits | 路由指示，用于SUCI在归属网路由 | 0001 |
| **Protection Scheme ID** | 4 bits | 保护方案：0=Null, 1=Profile A, 2=Profile B | 1 (Profile A) |
| **Home Network PK ID** | 8 bits | 归属网公钥标识符 | 01 |
| **Scheme Output** | 变长 | 加密方案输出（含临时公钥+密文+MAC） | 见下文 |

### 2.2 Scheme Output内部结构

Scheme Output是SUCI中最关键的部分，其内部结构根据使用的Protection Scheme不同而不同：

**ECIES Profile A（Curve25519）的Scheme Output：**

| 字段 | 长度 | 说明 |
|------|------|------|
| Ephemeral Public Key | 32 bytes (Curve25519) | UE生成的临时公钥 |
| Encrypted MSIN | ~40 bits变长 | AES-128-CTR加密的MSIN |
| MAC Tag | 16 bytes | HMAC-SHA-256截断后的MAC标签 |

**ECIES Profile B（secp256r1）的Scheme Output：**

| 字段 | 长度 | 说明 |
|------|------|------|
| Ephemeral Public Key | 64 bytes (secp256r1未压缩) | UE生成的临时公钥 |
| Encrypted MSIN | ~40 bits变长 | AES-128-CTR加密的MSIN |
| MAC Tag | 16 bytes | HMAC-SHA-256截断后的MAC标签 |

> **关键设计要点**：MCC、MNC和Routing Indicator以明文形式包含在SUCI中，这是因为拜访网络（Visited Network）的AMF需要用这些信息将Registration消息路由到正确的归属网UDM/SIDF。真正被加密保护的是**MSIN（Mobile Subscription Identification Number）**——即SUPI中能够唯一标识用户的那部分。

### 2.3 Null Scheme（保护方案0）

TS 33.501还定义了Null Scheme（Protection Scheme ID = 0），此时Scheme Output直接就是未加密的MSIN明文。这种情况发生在：
- USIM未配置归属网公钥
- 紧急呼叫场景
- 某些运营商尚未部署SUCI保护

Null Scheme下的SUCI本质上等价于4G的IMSI明文传输，不具备隐私保护能力。

## 三、ECIES双Profile加密方案深度解析

### 3.1 Profile A与Profile B对比

3GPP在TS 33.501 Annex C中定义了两种ECIES保护方案，其核心区别在于使用的椭圆曲线和密钥协商算法：

| 参数 | Profile A (Scheme ID=1) | Profile B (Scheme ID=2) |
|------|------------------------|------------------------|
| **椭圆曲线** | Curve25519 (Montgomery) | secp256r1 (NIST P-256) |
| **密钥协商** | X25519 | ECDH |
| **临时公钥长度** | 32 bytes | 64 bytes (未压缩) |
| **KDF** | HKDF-SHA-256 | HKDF-SHA-256 |
| **加密算法** | AES-128-CTR | AES-128-CTR |
| **MAC算法** | HMAC-SHA-256 (16B) | HMAC-SHA-256 (16B) |
| **参考章节** | TS 33.501 §6.12.2, Annex C.3.4 | TS 33.501 §6.12.3, Annex C.2 |
| **优势** | 密钥短、计算快、侧信道抗性强 | 兼容性好、NIST标准化 |

### 3.2 Profile A加密流程（Curve25519 / X25519）

Profile A基于Daniel J. Bernstein设计的Curve25519，使用Montgomery ladder算法实现X25519密钥协商。完整加密流程分为四个阶段：

```mermaid
flowchart TB
    subgraph "Phase 1: 密钥协商"
        A1["USIM读取归属网静态公钥 PK_HN<br/>(预置在USIM中)"]
        A2["UE生成临时密钥对 (sk_E, pk_E)<br/>Curve25519"]
        A3["计算共享密钥<br/>EK = X25519(sk_E, PK_HN)"]
        A1 --> A2 --> A3
    end

    subgraph "Phase 2: 密钥推衍"
        B1["输入: EK (共享密钥)"]
        B2["KDF: HKDF-SHA-256<br/>FC = 0x6B (SUCI Profile A)"]
        B3["输出: Enc Key (16B) + MAC Key (32B)"]
        B1 --> B2 --> B3
    end

    subgraph "Phase 3: 加密MSIN"
        C1["明文: MSIN (SUPI的用户标识部分)"]
        C2["AES-128-CTR 加密<br/>Key = Enc Key"]
        C3["密文: Encrypted MSIN"]
        C1 --> C2 --> C3
    end

    subgraph "Phase 4: 完整性保护"
        D1["输入: pk_E || Encrypted MSIN"]
        D2["HMAC-SHA-256<br/>Key = MAC Key"]
        D3["MAC Tag (截断至16 bytes)"]
        D1 --> D2 --> D3
    end

    A3 --> B1
    B3 --> C2
    B3 --> D2

    subgraph "最终输出: Scheme Output"
        E["pk_E (32B) || Encrypted MSIN || MAC Tag (16B)"]
    end

    C3 --> E
    D3 --> E
```

### 3.3 KDF密钥推衍函数详解

两种Profile使用相同的KDF框架，定义在TS 33.501 Annex A.2中。KDF基于HKDF-SHA-256：

```
KDF输入参数：
  FC = 0x6B (Profile A) / 0x6C (Profile B)
  P0 = EK (共享密钥, 32 bytes)
  L0 = length(P0)
  P1 = || (空, 无附加参数)
  L1 = 0

KDF输出：
  Key = SHA-256(EK || FC || L0 || P0 || L1 || P1)
  
  从输出中截取：
  - Enc Key = Key[0:16]     (16 bytes, AES-128密钥)
  - MAC Key = Key[16:48]    (32 bytes, HMAC密钥)
```

### 3.4 Profile B加密流程（secp256r1 / ECDH）

Profile B使用NIST P-256曲线和标准ECDH密钥协商。其流程与Profile A结构完全相同，差异在于：

1. **临时密钥对生成**：在secp256r1曲线上生成，公钥为64字节（未压缩格式 04 || x || y）
2. **密钥协商**：使用标准ECDH算法（非X25519）
3. **KDF中的FC值**：使用0x6C而非0x6B

### 3.5 为什么设计两种Profile？

3GPP设计双Profile的考量是一个有趣的安全与标准化博弈：

| 考量因素 | Profile A (Curve25519) | Profile B (P-256) |
|----------|----------------------|-------------------|
| **安全界信任度** | 高（避开NIST潜在后门嫌疑） | 高（NIST FIPS合规） |
| **政府合规要求** | 部分国家不认可 | 满足多数国家合规 |
| **实现复杂度** | 低（Montgomery ladder简单） | 中（需要完整的EC运算库） |
| **侧信道抗性** | 天然抗侧信道（常数时间算法） | 需额外防护措施 |
| **密钥尺寸** | 32 bytes（更紧凑） | 64 bytes（未压缩） |
| **互操作性** | 需要较新的USIM/ME支持 | 兼容性好 |

运营商可根据自身合规要求和设备生态选择部署哪种Profile。大多数部署同时支持两种Profile，USIM中预置的Protection Scheme ID决定了UE使用哪种方案。

## 四、Registration流程中的SUCI信令全解析

### 4.1 初始注册中的SUCI使用

在5G初始注册流程中（TS 23.502 Section 4.2.2.2），SUCI的使用贯穿整个注册过程。以下信令时序图展示了完整的SUCI加密与解密流程：

```mermaid
sequenceDiagram
    participant UE as UE/USIM
    participant gNB as gNB
    participant AMF as AMF<br/>(Visited Network)
    participant AUSF as AUSF
    participant UDM as UDM/SIDF
    participant ARPF as ARPF
    
    Note over UE: 1. 构造SUCI
    UE->>UE: a) 读取USIM中的归属网公钥 PK_HN<br/>和Protection Scheme ID
    UE->>UE: b) 生成临时密钥对 (sk_E, pk_E)
    UE->>UE: c) ECDH/X25519协商共享密钥 EK
    UE->>UE: d) KDF推衍 Enc Key + MAC Key
    UE->>UE: e) AES-128-CTR加密MSIN
    UE->>UE: f) HMAC-SHA-256计算MAC Tag
    UE->>UE: g) 组装SUCI = SUPI Type + MCC/MNC<br/>+ Routing Indicator + Scheme ID<br/>+ PK ID + Scheme Output
    
    rect rgb(230, 245, 255)
    Note over UE,gNB: 2. Registration Request (NAS)
    UE->>gNB: RRC: RRCSetupRequest<br/>含5G-S-TMSI或random value
    UE->>gNB: RRC: ULInformationTransfer<br/>携带NAS Registration Request
    Note over UE,gNB: NAS消息中 <mobile identity> = SUCI<br/>(非明文SUPI!)
    end
    
    gNB->>AMF: N2: Initial UE Message<br/>含Registration Request (SUCI)
    
    Note over AMF: 3. AMF路由决策
    AMF->>AMF: 解析SUCI中的MCC/MNC<br/>+ Routing Indicator<br/>确定归属网UDM地址
    
    AMF->>AUSF: Nausf_UEAuthentication<br/>Authenticate Request<br/>(含SUCI, SN-Name)
    AUSF->>UDM: Nudm_UEAuthentication<br/>Get Request (SUCI, SN-Name)
    
    rect rgb(255, 240, 230)
    Note over UDM,ARPF: 4. SIDF解密SUCI (TS 33.501 §6.12.5)
    UDM->>UDM: a) 根据Scheme ID和PK ID<br/>查找对应的私钥 sk_HN
    UDM->>UDM: b) 从Scheme Output提取<br/>临时公钥 pk_E
    UDM->>UDM: c) ECDH/X25519(sk_HN, pk_E)<br/>计算共享密钥 EK'
    UDM->>UDM: d) KDF推衍 Enc Key' + MAC Key'
    UDM->>UDM: e) 验证MAC Tag<br/>(HMAC-SHA-256)
    UDM->>UDM: f) MAC验证通过后<br/>AES-128-CTR解密MSIN
    UDM->>UDM: g) 恢复完整SUPI
    end
    
    UDM->>ARPF: 用SUPI查找用户订阅数据<br/>获取K/OPc等认证凭据
    ARPF->>UDM: 生成5G-AKA认证向量<br/>(RAND, AUTN, XRES*, KAUSF)
    
    UDM->>AUSF: Nudm_UEAuthentication<br/>Get Response (SUPI, AV)
    Note over UDM,AUSF: 此时SIDF已完成SUCI→SUPI解密<br/>后续流程使用SUPI而非SUCI
    AUSF->>AMF: Nausf_UEAuthentication<br/>Authenticate Response<br/>(RAND, AUTN, HXRES*)
    
    AMF->>UE: DL NAS: Authentication Request<br/>(RAND, AUTN)
    UE->>UE: USIM验证AUTN<br/>计算RES*
    UE->>AMF: UL NAS: Authentication Response<br/>(RES*)
    
    AMF->>AUSF: Nausf_UEAuthentication<br/>Authenticate Complete (RES*)
    AUSF->>AUSF: 验证 RES* == XRES*
    AUSF->>AMF: 认证成功 + KSEAF
    
    AMF->>UE: DL NAS: Security Mode Command<br/>建立NAS安全上下文
    UE->>AMF: UL NAS: Security Mode Complete
    
    Note over AMF,UE: 后续所有NAS消息均受加密和完整性保护<br/>UE获得5G-GUTI替代SUCI用于后续注册
    AMF->>UE: DL NAS: Registration Accept<br/>(含5G-GUTI)
```

### 4.2 关键信令消息中的IE分析

#### NAS Registration Request中的SUCI IE

根据TS 24.501 Section 9.11.3.4，Registration Request中的`<mobile identity>` IE编码如下：

| 字节偏移 | 字段 | 值（示例） | 说明 |
|----------|------|-----------|------|
| Byte 1 | IEI | 0x77 | Mobile Identity IE标识 |
| Byte 2-3 | Length | 变长 | IE总长度 |
| Byte 4 bits 7-4 | SUPI Type | 0b0000 | IMSI类型 |
| Byte 4 bits 3 | Odd/Even | 0b0 | 偶数位 |
| Byte 4 bits 2-1 | Type of Identity | 0b01 | SUCI标识 |
| Byte 5-7 | MCC+MNC | 64F000 | MCC=460, MNC=00 (BCD编码) |
| Byte 8 | Routing Indicator | 0x01 | 路由指示器 |
| Byte 9 bits 7-4 | Protection Scheme ID | 0x01 | Profile A |
| Byte 9 bits 3-0 | Home Network PK ID | 0x01 | 公钥ID=1 |
| Byte 10+ | Scheme Output | 变长 | pk_E || Enc(MSIN) || MAC |

> **抓包要点**：在Wireshark中，NAS Registration Request消息的Mobile Identity字段，当`Type of Identity = 0b01`（SUCI）时，解析器会展开显示SUCI的各子字段。如果看到Protection Scheme ID = 0，说明使用Null Scheme（无加密保护）。

### 4.3 SIDF解密过程的严格验证

SIDF（Subscription Identifier De-concealing Function）位于UDM中（TS 33.501 Section 6.12.5），其解密过程有严格的安全检查：

1. **公钥ID查找**：根据SUCI中的Protection Scheme ID和Home Network Public Key ID，查找对应的私钥`sk_HN`
2. **共享密钥计算**：使用私钥和UE的临时公钥计算共享密钥
3. **MAC验证优先于解密**：先验证MAC Tag的正确性（MAC-then-decrypt模式），防止padding oracle攻击
4. **解密MSIN**：MAC验证通过后才执行AES-128-CTR解密
5. **SUPI恢复**：将解密的MSIN与SUCI中明文的MCC/MNC组合，恢复完整SUPI

如果MAC验证失败，SIDF必须拒绝解密并向AMF返回错误，这是为了防止篡改攻击。

## 五、SUCI使用的状态转换与安全策略

### 5.1 UE标识使用的状态机

```mermaid
stateDiagram-v2
    [*] --> InitialRegistration: UE开机/失联
    
    state "标识选择决策" as Decision {
        InitialRegistration --> HasValidGUTI: 检查5G-GUTI
        HasValidGUTI --> UseGUTI: 5G-GUTI有效
        HasValidGUTI --> CheckSUCI: 5G-GUTI无效/过期
        CheckSUCI --> UseSUCI: USIM有公钥
        CheckSUCI --> UseNullSUCI: USIM无公钥
        UseSUCI --> RegistrationWithECIES: ECIES加密
        UseNullSUCI --> RegistrationWithNull: Null Scheme
        UseGUTI --> RegistrationWithGUTI: 明文GUTI
    }
    
    RegistrationWithECIES --> AuthSuccess: 5G-AKA认证成功
    RegistrationWithNull --> AuthSuccess
    RegistrationWithGUTI --> AuthSuccess
    RegistrationWithGUTI --> GUTIFailed: AMF找不到GUTI
    GUTIFailed --> UseSUCI: Identity Request→SUCI响应
    
    AuthSuccess --> AssignedGUTI: 获得新5G-GUTI
    AssignedGUTI --> SubsequentRegistration: 后续注册
    
    SubsequentRegistration --> HasValidGUTI
```

### 5.2 SUCI的不可关联性分析

SUCI方案的一个关键安全目标是**不可关联性（Unlinkability）**——攻击者无法将不同时间点的SUCI关联到同一个用户。这通过以下机制保证：

| 关联维度 | 攻击场景 | SUCI防护 |
|----------|---------|---------|
| **跨次关联** | UE两次Registration的SUCI相同？ | 每次生成新的临时密钥对，SUCI必然不同 |
| **时间关联** | 固定时间间隔出现相同SUCI？ | 临时密钥的随机性打破时间规律 |
| **位置关联** | 不同基站收到相同SUCI？ | Ephemeral key不同，即使同一MSIN也产生不同密文 |
| **流量关联** | 某SUCI的数据流特征关联？ | SUCI仅在初始注册使用，后续用GUTI |

但需注意以下关联性泄露风险：
- **MCC/MNC明文泄露**：攻击者可知道UE的归属运营商
- **Routing Indicator明文泄露**：可缩小用户范围到特定路由域
- **SUPI Type明文泄露**：可知道标识类型（IMSI/NAI）
- **Null Scheme**：完全无隐私保护

## 六、实战：抓包识别与排错指南

### 6.1 Wireshark抓包识别SUCI流程

在5G SA核心网抓包中，识别SUCI相关的关键消息：

| 消息 | 协议层 | 关键过滤条件 | 关注字段 |
|------|--------|-------------|---------|
| Registration Request | NAS 5GS | `nas_5gs.reg.message_type == 0x41` | Mobile Identity IE |
| Identity Request | NAS 5GS | `nas_5gs.reg.message_type == 0x5C` | Identity Type |
| Identity Response | NAS 5GS | `nas_5gs.reg.message_type == 0x5D` | Mobile Identity (SUCI) |
| Nudm_UEAuth_Get | HTTP/2 | `http2.headers.path contains "ue-authentications"` | SUCI in body |
| Registration Accept | NAS 5GS | `nas_5gs.reg.message_type == 0x42` | 5G-GUTI |

**Wireshark过滤示例**：
```
# 查看所有携带SUCI的NAS Registration消息
nas_5gs.reg.message_type == 0x41 && nas_5gs.mobile_identity.type_of_identity == 1

# 查看使用Null Scheme的注册（安全风险）
nas_5gs.reg.protection_scheme_id == 0
```

### 6.2 常见故障场景与排错

#### 场景1：USIM公钥与UDM私钥不匹配

**现象**：UE发送携带ECIES加密SUCI的Registration Request，但UDM/SIDF返回MAC验证失败。

**排查步骤**：
1. 检查USIM中预置的Home Network Public Key ID
2. 检查UDM/SIDF中对应ID的私钥是否匹配
3. 确认Protection Scheme ID一致（Profile A vs Profile B）
4. 验证公钥格式（Profile A: 32B Curve25519, Profile B: 64B secp256r1）

**典型错误日志**：
```
UDM/SIDF: SUCI deconcealment failed - MAC verification failure
  Protection Scheme: Profile A (Curve25519)
  Home Network PK ID: 0x03
  Error: No matching private key found for PK ID 0x03
```

#### 场景2：SUCI中的Routing Indicator配置错误

**现象**：AMF无法将SUCI路由到正确的UDM实例。

**排查步骤**：
1. 检查USIM中配置的Routing Indicator值
2. 确认AMF的路由表中该Routing Indicator对应的UDM地址
3. 注意Routing Indicator在SUCI中以BCD编码

#### 场景3：Null Scheme降级

**现象**：UE使用Null Scheme发送Registration，空口可见明文MSIN。

**排查步骤**：
1. 检查USIM是否预置了归属网公钥（EF_SUCI文件）
2. 检查USIM中的Protection Scheme ID是否为0（Null）
3. 确认运营商是否已部署SUCI保护
4. 使用`AT+CSIM`命令读取USIM中的公钥信息
## 七、常见问题

**Q1: SUCI与4G中的GUTI有什么本质区别？**
A: GUTI是网络分配的临时标识，用于后续注册时的标识替换，但首次注册仍需发送明文IMSI。SUCI则解决了首次注册时的永久标识保护问题——即使用户首次附着网络，SUPI也不会以明文暴露。SUCI基于公钥加密（UE主动保护），GUTI基于网络分配（网络侧保护），两者互补构成完整的隐私保护体系。

**Q2: Profile A和Profile B能否在同一网络中混用？**
A: 可以。USIM中预置的Protection Scheme ID决定UE使用哪种Profile。运营商可以为不同批次USIM配置不同Profile。UDM/SIDF必须同时支持两种Profile，根据SUCI中的Scheme ID字段选择对应的解密算法。但同一张USIM在一次Registration中只能使用一种Profile。

**Q3: SUCI加密只保护MSIN，不保护MCC/MNC，这是否构成隐私泄露？**
A: 这是有意的设计权衡。MCC/MNC标识运营商而非用户，泄露运营商信息不会直接威胁单个用户的隐私。拜访网络的AMF需要MCC/MNC和Routing Indicator来路由Registration消息到归属网。如果加密这些字段，将无法完成路由。实际攻击中，知道"某UE属于某运营商"的价值远低于知道"某UE的具体标识"。

**Q4: UE每次注册都生成新的临时密钥对，这对性能有何影响？**
A: Curve25519的密钥生成仅需约100微秒，对UE的注册时延影响可忽略。Profile B的secp256r1密钥生成稍慢但仍在毫秒级。真正的性能瓶颈在UDM/SIDF侧——当大量UE同时注册时，SIDF需要为每个SUCI执行ECDH计算。运营商通常通过SIDF实例化和硬件加速（HSM）来应对。

**Q5: 如果攻击者获得了归属网的私钥，能否解密所有历史SUCI？**
A: 不能完全解密。每个SUCI使用不同的临时密钥对（ephemeral key pair），即使攻击者获得私钥，也需要同时拥有UE当时生成的临时私钥才能计算共享密钥。而临时私钥在生成SUCI后即被销毁（UE不会存储）。这提供了类似前向安全性的保护——但严格来说，如果攻击者记录了所有SUCI，获得私钥后可以尝试离线暴力破解MAC Key验证来关联用户（虽然计算量极大）。

## 参考来源

1. [3GPP TS 33.501 V18.10.0](https://www.etsi.org/deliver/etsi_ts/133500_133599/133501/18.10.00_60/ts_133501v181000p.pdf) — Section 6.12 SUCI计算, Annex C ECIES保护方案, Annex A KDF定义
2. [3GPP TS 23.003 V18.3.0](https://www.3gpp.org/DynaReport/23003.htm) — Section 2.2A SUCI格式定义
3. [3GPP TS 24.501 V18.7.0](https://www.3gpp.org/DynaReport/24501.htm) — Section 9.11.3.4 SUCI IE编码
4. [NIST CSWP 36A - Protecting Subscriber Identifiers with SUCI](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.36A.ipd.pdf) — ECIES方案详细技术分析
5. [5G6G Academy - SUPI vs SUCI](https://www.5g6gacademy.com/learn/supi-vs-suci) — Profile A/B方案对比与实际部署经验

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