聚焦规范：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 侧密钥与路由指示存储。
在 4G/EPS 及之前，用户永久标识 IMSI（International Mobile Subscriber Identity）在以下两个场景会以明文通过空口发送：
这催生了著名的 IMSI Catcher（伪基站）攻击：攻击者只需伪装成基站、强制终端发起一次新的注册或 Identity 过程，就能在空口明文捕获 IMSI，进而完成用户定位、追踪、用户画像甚至定向中间人攻击。这是一类主动攻击（active attack），门槛低、危害大，且在 3G/4G 体制内长期无法根治——因为网络在认证之前必须先知道"我是谁"。
5G 系统给出的标准答案就是 SUPI / SUCI 双标识体系：
其核心思想一句话概括：在空口永远不传明文 SUPI，而是用基于公钥密码（ECIES）的方案把 SUPI 中可识别用户身份的部分（MSIN）加密后再传；只有归属网络（Home Network）的 UDM/SIDF 持有私钥，才能将其"解隐藏"还原为 SUPI。 这是从"明文身份 + 共享密钥认证"到"隐藏身份 + 非对称加密 + 后续认证"的范式跃迁。
本文将逐字节、逐信令拆解这一机制在 TS 33.501 附录 C 中的具体实现。
这是理解整个 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 里。这个看似"不彻底"的设计是深思熟虑的结果，后文设计意图部分会专门分析。
flowchart LR
subgraph SUPI["SUPI（永久标识，等价 IMSI）"]
M["MCC+MNC<br/>(归属网络)"]
S["MSIN<br/>(用户唯一号)"]
end
M -->|"明文保留"| SUCI1["SUCI.Home Network ID"]
S -->|"ECIES 加密"| SUCI2["SUCI.Scheme-Output<br/>(密文+临时公钥+MAC)"]
SUCI1 --> OUT["SUCI（空口传输）"]
SUCI2 --> OUT
style S fill:#ffd6d6
style SUCI2 fill:#ffe9b3
style OUT fill:#d6f5d6
在 NAS 层，SUCI 作为一个 Mobile Identity IE 携带，其 type 字段值为 SUCI。IE 的逻辑结构如下（IMSI-based SUPI 格式）：
flowchart TB
A["SUCI IE"] --> A1["SUPI Format（4 bit）<br/>0 = IMSI-based"]
A --> A2["Home Network Identifier<br/>MCC + MNC（明文）"]
A --> A3["Routing Indicator（明文，1~4 位）"]
A --> A4["Protection Scheme Identifier（4 bit）<br/>0=null / 1=Profile A / 2=Profile B"]
A --> A5["Home Network Public Key ID（8 bit）<br/>1~255，标识使用的归属公钥"]
A --> A6["Scheme-Output<br/>临时公钥E ‖ 密文C ‖ MAC tag"]
style A4 fill:#fff3b0
style A5 fill:#fff3b0
style A6 fill:#ffd6d6
为了便于人类可读与信令追踪，TS 23.003 还定义了一种 URI 风格的 SUCI 字符串表示：
suci-<supi-type>-<mcc>-<mnc>-<routing-indicator>-<scheme-id>-<hn-pubkey-id>-<scheme-output>
举两个具体例子：
suci-0-208-93-0-0-0-00000012340000001234）；suci-0-208-93-0-1-27-3a7f9c…（64 hex）各字段说明表：
| 字段 | 作用 | 关键取值与含义 |
|---|---|---|
| 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 |
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）的内容包括：
而对应的 HNpriv（归属网络私钥） 永远不出现在终端侧，只安全存储于归属网络 UDM 的 SIDF（Subscription Identifier De-concealing Function，用户标识解隐藏功能） 中。
下面逐步拆解终端如何把 SUPI 变成 SUCI。以 Profile A（Curve25519）为例：
flowchart TD
Start(["UE 持有 SUPI + HNpk(USIM预置)"]) --> E1["① 生成临时密钥对 (e, E)<br/>E = X25519(e, 9)"]
E1 --> E2["② ECDH 共享密钥<br/>Z = X25519(e, HNpk)"]
E2 --> E3["③ KDF 派生 (X9.63 + SHA-256)<br/>得 eK(16B) ‖ iV(16B) ‖ mK(32B)"]
E3 --> E4["④ AES-128-CTR 加密 MSIN<br/>C = AES-128-CTR(eK, iV, MSIN)"]
E4 --> E5["⑤ HMAC-SHA-256 计算 MAC<br/>tag = MAC(mK, C) 截断 64bit"]
E5 --> E6["⑥ 组装 Scheme-Output<br/>= E ‖ C ‖ tag"]
E6 --> E7["⑦ 拼装 SUCI<br/>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
关键密码学细节：
e 与临时公钥 E。这是 SUCI 每次取值都不同的根本原因，也是抗用户追踪（linkability）的核心机制。Z = X25519(e, HNpk)，由 ECDH 保证。由于对称性，网络侧用 X25519(HNpriv, E) 会得到同一个 Z。eK（16 字节）、计数器初值 iV（16 字节，供 CTR 模式用）、MAC 密钥 mK（32 字节）。eK 和 iV 以 AES-128-CTR（流密码模式）加密 MSIN 得密文 C。CTR 模式无需分组填充，长度基本保持。mK 对密文 C 计算 HMAC-SHA-256，并截断取高 64 bit 作为 tag。这一步确保 SUCI 在传输中若被篡改，SIDF 侧 MAC 校验会失败。E 必须明文带上，否则网络侧无法计算 Z。设计上必须把
E（临时公钥）以明文包含在 SUCI 里——这是非对称方案的"代价"，但E是随机的、且与用户身份无固定绑定，因此不会泄露隐私。
终端在以下两种情况会在 Registration Request 中携带 SUCI（而非 5G-GUTI）：
下面是首次注册 + Identity 流程的完整信令时序，把 SUCI 的产生、传输、解隐藏串成一条链：
sequenceDiagram
autonumber
participant UE as UE/USIM
participant gNB as (R)AN / gNB
participant AMF as AMF（拜访/归属）
participant SIDF as UDM/SIDF<br/>(持有 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<br/>(含 Registration Request)
Note over AMF: 解析 Mobile Identity IE = SUCI
alt 仅有 SUCI，需解析为 SUPI（获取鉴权向量）
AMF->>SIDF: Nudm_UEAU_Get(SUCI)<br/>或 Nudm_SDM_Info
Note over SIDF: ① 取 HNpriv<br/>② Z=X25519(HNpriv, E)<br/>③ KDF→eK/iV/mK<br/>④ 验 MAC tag<br/>⑤ 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' 主认证
几个必须强调的信令要点：
mK 校验 tag，通过后再用 eK/iV 解密。这是为了抵抗选择密文/篡改攻击。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。
TS 33.501 明确把 scheme-id=0 定义为"空方案"：scheme-output 直接是明文 MSIN。它存在的意义是互操作兜底，但在工程上带来了重要风险：
这也是为什么 NIST 等机构专门发布白皮书推动 SUCI 保护的"使能（enabling）"——核心就是督促运营商完成 HNpk 预置与密钥管理（KMS）建设。
如何在 pcap 里识别 SUCI 流程？
使用 Wireshark/TShark 的 5G NAS（5GMM）解析器：
Registration request 消息里看 Mobile identity IE，若 type=SUCI，则进一步展开；0 说明是 Null 方案（MSIN 明文，隐私暴露）；1/2 是 ECIES（scheme-output 为不透明十六进制）；Identity request（identity type=5GS mobile identity / SUCI）+ Identity response，说明 AMF 主动向 UE 索要了 SUCI；Nudm_UEAU_Get 请求体携带 SUCI、响应体携带 SUPI 与鉴权向量——这是 SIDF 解隐藏发生在 SBI 层的证据。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 区分、必须端到端一致。
本文由「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 等场景全覆盖。