# 5G SUCI 基于 ECIES 的 SUPI 隐藏加密机制全链拆解 > 聚焦规范：3GPP TS 33.501 V19.x（5G 安全架构与流程）第 6.12 节「用户标识隐私」与附录 C「SUCI 计算方法」；配合 TS 23.003 第 28.7 节 SUCI 编码格式、TS 24.501 第 9.11.3.4 节 SUCI IE、TS 31.102/31.103 USIM 侧密钥与路由指示存储。 ## 一、为什么 5G 必须发明 SUCI：从 IMSI Catcher 说起 在 4G/EPS 及之前，用户永久标识 **IMSI**（International Mobile Subscriber Identity）在以下两个场景会**以明文**通过空口发送： 1. 终端首次附着（Initial Attach）或网络无法识别临时标识 GUTI 时，UE 直接上报 IMSI； 2. 网络发起 Identity Request 时，UE 在**未建立安全上下文**的连接上回送 IMSI。 这催生了著名的 **IMSI Catcher（伪基站）攻击**：攻击者只需伪装成基站、强制终端发起一次新的注册或 Identity 过程，就能在空口明文捕获 IMSI，进而完成用户定位、追踪、用户画像甚至定向中间人攻击。这是一类**主动攻击**（active attack），门槛低、危害大，且在 3G/4G 体制内长期无法根治——因为网络在认证之前必须先知道"我是谁"。 5G 系统给出的标准答案就是 **SUPI / SUCI** 双标识体系： - **SUPI（Subscription Permanent Identifier）**：5G 的永久标识，IMSI-based SUPI 在数值上等价于 IMSI，是用户唯一身份； - **SUCI（Subscription Concealed Identifier）**：SUPI 的**加密隐藏版本**，是真正在空口传输的身份标识。 其核心思想一句话概括：**在空口永远不传明文 SUPI，而是用基于公钥密码（ECIES）的方案把 SUPI 中可识别用户身份的部分（MSIN）加密后再传；只有归属网络（Home Network）的 UDM/SIDF 持有私钥，才能将其"解隐藏"还原为 SUPI。** 这是从"明文身份 + 共享密钥认证"到"隐藏身份 + 非对称加密 + 后续认证"的范式跃迁。 本文将逐字节、逐信令拆解这一机制在 TS 33.501 附录 C 中的具体实现。 ## 二、SUPI 的拆分：加密什么、不加密什么 这是理解整个 SUCI 设计的关键。IMSI-based SUPI 由两部分构成： | SUPI 组成 | 长度/位数 | 说明 | 是否加密 | |-----------|-----------|------|----------| | **MCC + MNC（Home Network Identifier）** | MCC 3 位 + MNC 2~3 位 | 归属国家码 + 运营商码，用于路由 | **不加密，明文保留** | | **MSIN（Mobile Subscription Identification Number）** | 最多 10 位十进制 | 订阅识别号，区分具体用户 | **加密（ECIES）** | 也就是说，SUCI **只加密 MSIN**，而把 MCC/MNC 明文留在 SUCI 里。这个看似"不彻底"的设计是深思熟虑的结果，后文设计意图部分会专门分析。 ```mermaid flowchart LR subgraph SUPI["SUPI（永久标识，等价 IMSI）"] M["MCC+MNC
(归属网络)"] S["MSIN
(用户唯一号)"] end M -->|"明文保留"| SUCI1["SUCI.Home Network ID"] S -->|"ECIES 加密"| SUCI2["SUCI.Scheme-Output
(密文+临时公钥+MAC)"] SUCI1 --> OUT["SUCI（空口传输）"] SUCI2 --> OUT style S fill:#ffd6d6 style SUCI2 fill:#ffe9b3 style OUT fill:#d6f5d6 ``` ## 三、SUCI 的编码结构（TS 23.003 §28.7.4 / TS 24.501 §9.11.3.4） 在 NAS 层，SUCI 作为一个 **Mobile Identity IE** 携带，其 type 字段值为 `SUCI`。IE 的逻辑结构如下（IMSI-based SUPI 格式）： ```mermaid flowchart TB A["SUCI IE"] --> A1["SUPI Format（4 bit）
0 = IMSI-based"] A --> A2["Home Network Identifier
MCC + MNC（明文）"] A --> A3["Routing Indicator（明文，1~4 位）"] A --> A4["Protection Scheme Identifier（4 bit）
0=null / 1=Profile A / 2=Profile B"] A --> A5["Home Network Public Key ID（8 bit）
1~255，标识使用的归属公钥"] A --> A6["Scheme-Output
临时公钥E ‖ 密文C ‖ MAC tag"] style A4 fill:#fff3b0 style A5 fill:#fff3b0 style A6 fill:#ffd6d6 ``` 为了便于人类可读与信令追踪，TS 23.003 还定义了一种 URI 风格的 SUCI 字符串表示： ``` suci------- ``` 举两个具体例子： - **空方案（Null Scheme）**：`suci-0-208-93-0-0-0-0000001234` scheme-id=0，MSIN 以明文出现在 scheme-output 中（`0000001234`）； - **ECIES Profile A**：`suci-0-208-93-0-1-27-3a7f9c…（64 hex）` scheme-id=1（Profile A），key-id=27，scheme-output 为临时公钥+密文+MAC 的十六进制串。 **各字段说明表：** | 字段 | 作用 | 关键取值与含义 | |------|------|----------------| | SUPI Format | 标识 SUPI 类型 | 0=IMSI-based（本文重点）；1=Network-specific（NAI/用户名） | | MCC/MNC | 归属网络路由 | 明文，拜访网据此把信令路由到归属网 | | Routing Indicator | UDM/SIDF 内部路由 | 默认 0；分布式 UDM 部署时用于定位持有私钥的 UDM 实例 | | Protection Scheme | 保护方案 | **0 = Null 空方案**；**1 = ECIES Profile A**；**2 = ECIES Profile B** | | HN Public Key ID | 归属公钥标识 | 1~255，支持密钥轮换（一台终端可预置多把公钥） | | Scheme-Output | 加密负载 | Null：明文 MSIN；ECIES：`E‖C‖tag` | ## 四、ECIES 保护方案：Profile A 与 Profile B 3GPP 为 SUCI 定义了两个标准的椭圆曲线集成加密方案（ECIES）配置（TS 33.501 附录 C.3）。两者在密钥协商曲线上不同，其余对称加密与 MAC 算法相同。 | 参数 | Profile A（scheme-id=1） | Profile B（scheme-id=2） | |------|--------------------------|--------------------------| | 椭圆曲线 | **Curve25519** | **secp256r1（NIST P-256）** | | ECDH 运算 | X25519 标量乘 | 标准 ECDH（NIST） | | 临时公钥长度 | 32 字节 | 33 字节（压缩）/ 65 字节 | | KDF | 基于 X9.63 的 KDF（SHA-256） | 同左 | | 对称加密 | **AES-128-CTR** | **AES-128-CTR** | | MAC | **HMAC-SHA-256（截断 64 bit）** | **HMAC-SHA-256（截断 64 bit）** | > 为什么提供两个 Profile？Curve25519（A）实现简洁、抗侧信道能力强、无确定性问题，被许多现代密码库优先推荐；而 secp256r1（B）与 NIST/FIPS 体系兼容，便于满足部分监管或硬件加速要求。终端与网络通过 scheme-id 协商使用哪一个，二者必须支持对应曲线才能完成解隐藏。 归属网络在 USIM 中预置（provision）的内容包括： - **HNpk（Home Network Public Key，归属网络公钥）**：对应所选曲线； - **HN Public Key ID**：与 HNpk 绑定的标识； - **默认保护方案与默认 key-id**； - **Routing Indicator**（TS 31.102）。 而对应的 **HNpriv（归属网络私钥）** 永远不出现在终端侧，只安全存储于归属网络 **UDM 的 SIDF（Subscription Identifier De-concealing Function，用户标识解隐藏功能）** 中。 ## 五、UE 侧 SUCI 计算完整流程（TS 33.501 §C.3.2） 下面逐步拆解终端如何把 SUPI 变成 SUCI。以 Profile A（Curve25519）为例： ```mermaid flowchart TD Start(["UE 持有 SUPI + HNpk(USIM预置)"]) --> E1["① 生成临时密钥对 (e, E)
E = X25519(e, 9)"] E1 --> E2["② ECDH 共享密钥
Z = X25519(e, HNpk)"] E2 --> E3["③ KDF 派生 (X9.63 + SHA-256)
得 eK(16B) ‖ iV(16B) ‖ mK(32B)"] E3 --> E4["④ AES-128-CTR 加密 MSIN
C = AES-128-CTR(eK, iV, MSIN)"] E4 --> E5["⑤ HMAC-SHA-256 计算 MAC
tag = MAC(mK, C) 截断 64bit"] E5 --> E6["⑥ 组装 Scheme-Output
= E ‖ C ‖ tag"] E6 --> E7["⑦ 拼装 SUCI
HN-ID ‖ RI ‖ scheme-id ‖ key-id ‖ (E‖C‖tag)"] E7 --> Send(["空口发送 SUCI 给 AMF"]) style E2 fill:#ffe0b3 style E4 fill:#ffd6d6 style E6 fill:#d6e0ff ``` **关键密码学细节：** 1. **临时密钥对（ephemeral key pair）**：每次注册都重新生成一对临时私钥 `e` 与临时公钥 `E`。这是 SUCI 每次取值都不同的根本原因，也是**抗用户追踪（linkability）**的核心机制。 2. **共享密钥 Z**：`Z = X25519(e, HNpk)`，由 ECDH 保证。由于对称性，网络侧用 `X25519(HNpriv, E)` 会得到**同一个 Z**。 3. **KDF**：基于 X9.63（ANSI-X9.63-KDF）配合 SHA-256，从 Z 派生三段密钥材料——加密密钥 `eK`（16 字节）、计数器初值 `iV`（16 字节，供 CTR 模式用）、MAC 密钥 `mK`（32 字节）。 4. **加密**：用 `eK` 和 `iV` 以 **AES-128-CTR**（流密码模式）加密 MSIN 得密文 `C`。CTR 模式无需分组填充，长度基本保持。 5. **完整性（encrypt-then-MAC）**：用 `mK` 对密文 `C` 计算 HMAC-SHA-256，并**截断取高 64 bit** 作为 `tag`。这一步确保 SUCI 在传输中若被篡改，SIDF 侧 MAC 校验会失败。 6. **scheme-output = E ‖ C ‖ tag**：临时公钥 `E` 必须明文带上，否则网络侧无法计算 Z。 > 设计上必须把 `E`（临时公钥）以明文包含在 SUCI 里——这是非对称方案的"代价"，但 `E` 是随机的、且与用户身份无固定绑定，因此不会泄露隐私。 ## 六、UDM/SIDF 解隐藏与端到端信令时序 终端在以下两种情况会在 Registration Request 中携带 SUCI（而非 5G-GUTI）： 1. 首次注册、终端没有任何可用 5G-GUTI； 2. 网络通过 Identity Request 显式索要 SUCI（典型场景：AMF 更换、旧 AMF 不可达、GUTI 无法解析）。 下面是**首次注册 + Identity 流程**的完整信令时序，把 SUCI 的产生、传输、解隐藏串成一条链： ```mermaid sequenceDiagram autonumber participant UE as UE/USIM participant gNB as (R)AN / gNB participant AMF as AMF（拜访/归属） participant SIDF as UDM/SIDF
(持有 HNpriv) Note over UE: USIM 预置 HNpk、key-id、Routing Indicator UE->>UE: 计算 SUCI = ECIES(SUPI, HNpk) UE->>gNB: RRC Setup / InitialUEMessage gNB->>AMF: NGAP Initial UE Message
(含 Registration Request) Note over AMF: 解析 Mobile Identity IE = SUCI alt 仅有 SUCI，需解析为 SUPI（获取鉴权向量） AMF->>SIDF: Nudm_UEAU_Get(SUCI)
或 Nudm_SDM_Info Note over SIDF: ① 取 HNpriv
② Z=X25519(HNpriv, E)
③ KDF→eK/iV/mK
④ 验 MAC tag
⑤ AES-128-CTR 解密 MSIN SIDF-->>AMF: 返回 SUPI（+ 鉴权向量 AV） else AMF 持有 GUTI 但解析失败 AMF->>UE: NAS Identity Request（type=SUCI） UE-->>AMF: NAS Identity Response（SUCI） AMF->>SIDF: 解隐藏请求（SUCI） SIDF-->>AMF: SUPI end Note over UE,AMF: 进入 5G AKA / EAP-AKA' 主认证 ``` **几个必须强调的信令要点：** - **AMF 自己无法解隐藏**。AMF 拿到的就是一串 SUCI，它只能原样转发给 UDM/SIDF。这保证了即便拜访网络也是"看不懂"的，隐私边界止于归属网络。 - **MAC 校验先于解密**。SIDF 解隐藏时先用 `mK` 校验 `tag`，通过后再用 `eK`/`iV` 解密。这是为了抵抗选择密文/篡改攻击。 - **解隐藏是按需的**。一旦 5G-GUTI 分配下来，后续注册都用 GUTI（也是临时标识、本身具有隐私性），SUCI 的使用频率很低，SIDF 的计算压力可控。 - **Routing Indicator 路由**：在分布式 UDM 部署中，AMF/UDM 根据 SUCI 中明文的 Routing Indicator 把解隐藏请求路由到真正持有对应 `HNpriv` 的 UDM 实例；默认值 0 表示任意 UDM 都可处理。 ## 七、设计意图：每一个"看起来奇怪"的取舍 **1. 为什么 MCC/MNC 不加密？** 因为拜访网络（VPLMN）在认证之前必须知道这封信要往哪个归属网络（HPLMN）送。如果连国家码运营商码都加密，整个路由体系就崩了。这是路由需要与隐私保护之间的必然折中——泄露的是"你是某国某运营商用户"这一较粗粒度信息，保护的是"你具体是哪个号"。 **2. 为什么用非对称（ECIES）而不是对称加密？** 如果用对称加密，密钥必须同时存在终端和网络，且很可能要分发到拜访网络，信任域被放大、密钥管理灾难化。ECIES 让终端只需**公开的 HNpk**（可随意分发、可预置多把），而**唯一私钥 HNpriv 只在归属网 UDM/SIDF**。这意味着：只有归属网络能解隐藏，拜访网络、AMF、传输节点全部"看不懂"，隐私边界清晰、信任域最小化。 **3. 为什么每次都用临时密钥（ephemeral key）？** 若用固定密文，同一用户的 SUCI 永远相同，攻击者可凭 SUCI 的恒定模式实现**跨小区/跨时间追踪**。临时密钥让每次 SUCI 在概率上互不相同，破坏可链接性（unlinkability）。 **4. 为什么有 MAC（完整性）？** 防止攻击者篡改 SUCI 中的 `E` 或密文 `C`，诱导网络走入异常分支或进行选择密文探测。Encrypt-then-MAC + 截断 64bit 是性能与安全的平衡。 **5. 为什么留一个 Null 空方案？** 兼容性与渐进部署。早期 5G USIM 可能未预置 HNpk（或运营商尚未完成密钥分发体系），此时回退到空方案——MSIN 明文传输。**这是 5G 隐私保护最大的现实短板**：在空方案下，5G 与 4G 一样暴露于 IMSI Catcher。 ## 八、Null 空方案与真实部署的隐私短板 TS 33.501 明确把 `scheme-id=0` 定义为"空方案"：scheme-output 直接是明文 MSIN。它存在的意义是**互操作兜底**，但在工程上带来了重要风险： - 终端是否启用 ECIES，**取决于 USIM 是否预置了 HNpk 与 key-id**。许多运营商在 5G 商用初期并未完成 USIM 侧的公钥预置，于是大量商用 5G 终端实际仍在用 Null 方案； - 因此"5G 天然抗 IMSI Catcher"这一说法**有条件性**——只有 ECIES 方案真正生效时才成立； - 此外，即使是 ECIES，MCC/MNC + Routing Indicator 仍明文可读，攻击者虽拿不到 MSIN，仍可做粗粒度运营商级识别。 这也是为什么 NIST 等机构专门发布白皮书推动 SUCI 保护的"使能（enabling）"——核心就是督促运营商完成 HNpk 预置与密钥管理（KMS）建设。 ## 九、抓包识别与故障排查 **如何在 pcap 里识别 SUCI 流程？** 使用 Wireshark/TShark 的 5G NAS（5GMM）解析器： - 在 `Registration request` 消息里看 **Mobile identity** IE，若 type=SUCI，则进一步展开； - 关注 **Protection scheme id** 字段：`0` 说明是 Null 方案（MSIN 明文，隐私暴露）；`1/2` 是 ECIES（scheme-output 为不透明十六进制）； - 若出现 `Identity request`（identity type=5GS mobile identity / SUCI）+ `Identity response`，说明 AMF 主动向 UE 索要了 SUCI； - 在 N1 接口之外，可在 Nudm 接口（HTTP/2 SBI）看到 `Nudm_UEAU_Get` 请求体携带 SUCI、响应体携带 SUPI 与鉴权向量——这是 SIDF 解隐藏发生在 SBI 层的证据。 ```mermaid stateDiagram-v2 [*] --> NoGUTI: 首次注册/GUTI失效 NoGUTI --> UseSUCI: UE 构造 SUCI(ECIES) UseSUCI --> Deconceal: AMF→UDM/SIDF Deconceal --> AuthOK: 解隐藏成功→主认证 Deconceal --> DeconcealFail: key-id无匹配/MAC失败 DeconcealFail --> RegFail: 注册失败 AuthOK --> AssignGUTI: 分配 5G-GUTI AssignGUTI --> UseGUTI: 后续用 GUTI(临时,隐身) UseGUTI --> [*] ``` **常见故障点：** | 故障现象 | 根因 | 排查思路 | |----------|------|----------| | 注册失败，UDM 返回 SUCI 解隐藏错误 | USIM 用的 key-id 与 UDM 持有的私钥不匹配（密钥轮换后 USIM 未同步） | 比对 SUCI 中的 key-id 与 UDM KMS 中该 key-id 对应私钥是否存在；检查密钥轮换与 OTA 预置流程 | | 大量注册时延升高、SIDF CPU 飙高 | ECIES（X25519/P-256）+ AES + HMAC 计算密集，突发注册风暴压垮 SIDF | 评估 SIDF 实例数、引入分布式 SIDF；观察 Routing Indicator 路由是否均衡 | | 终端始终走 Null 方案 | USIM 未预置 HNpk 或默认 scheme=0 | 检查 USIM 文件（TS 31.102）中 home network public key 数据；运营商侧补预置 | | 同一用户被持续定位追踪 | 虽用 ECIES 但 Routing Indicator + MCC/MNC 暴露，或回退 GUTI 频繁失败 | 优化 GUTI 重分配策略；评估 Routing Indicator 是否过于暴露用户子集 | | 跨厂商互通解隐藏失败 | Profile A/B 曲线实现差异、字节序/压缩点编码不一致 | 用 TS 33.501 附录 C 官方测试向量做交叉验证 | ## 常见问题 **Q1：SUCI 和 SUPI 的本质区别是什么？** A：SUPI 是永久明文标识（等价 IMSI），永远只在受信域内使用；SUCI 是 SUPI 的加密隐藏形态，是真正穿越空口和拜访网络的标识。SUCI 用 ECIES 只加密 MSIN，MCC/MNC 与 Routing Indicator 明文保留以支持路由。 **Q2：为什么 AMF 不能自己解隐藏 SUCI？** A：因为 ECIES 的私钥 HNpriv 只存在归属网络的 UDM/SIDF 中，AMF（尤其拜访网 AMF）没有私钥。这是非对称设计刻意构造的信任边界，确保除归属网外任何节点都无法获得 SUPI。 **Q3：空方案（Null Scheme）下 5G 还抗 IMSI Catcher 吗？** A：基本不抗。scheme-id=0 时 MSIN 以明文出现在 scheme-output，等同 4G 暴露面。只有当 USIM 预置了 HNpk 并使用 ECIES（scheme-id=1/2）时，5G 才真正具备用户标识隐私保护。 **Q4：每次注册 SUCI 为什么都不一样？** A：因为 UE 每次都用新生成的临时密钥对 (e, E) 做 ECDH，密文 C 与 MAC tag 随之改变。这种随机化破坏了 SUCI 的可链接性，使攻击者无法用恒定 SUCI 追踪用户。 **Q5：Profile A（Curve25519）和 Profile B（P-256）该怎么选？** A：密码学强度相当。Profile A 实现更简洁、抗侧信道更好，被现代库优先；Profile B 与 NIST/FIPS 体系兼容、便于硬件加速与合规。最终取决于运营商 USIM 与 UDM 的密码栈支持情况，二者通过 scheme-id 区分、必须端到端一致。 ## 参考来源 1. [3GPP TS 33.501 — Security architecture and procedures for 5G system](https://www.3gpp.org/dynareport/33501.htm) — §6.12 用户标识隐私、附录 C.3 SUCI 的 ECIES 计算方法（Profile A/B） 2. [3GPP TS 23.003 — Numbering, addressing and identification](https://www.3gpp.org/dynareport/23003.htm) — §28.7 SUCI 编码格式与各字段定义 3. [3GPP TS 24.501 — Non-Access-Stratum (NAS) protocol](https://www.3gpp.org/dynareport/24501.htm) — §9.11.3.4 SUCI Mobile Identity IE、§5.4.2 Identity Request/Response 流程 4. [ECIES in 5G Core: SUPI to SUCI Conversion — Medium](https://medium.com/@aditya.koranga/ecies-in-5g-core-supi-to-suci-conversion-15c0fb8373e2) — UE 侧 SUCI 计算逐步流程与 MSIN 加密解读 5. [NIST CSWP 36 — Protecting Subscriber Identifiers with SUCI](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.36A.ipd.pdf) — 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 等场景全覆盖。