# 5G SUCI 保护方案与 SIDF 去隐藏机制全链拆解 > 聚焦 3GPP TS 33.501 Annex C 与 Clause 6.12，从 UE 侧 ECIES 公钥加密到 UDM/SIDF 私钥解密的完整密码学与信令链路。 ## 一、为什么需要 SUCI：从 IMSI Catcher 到永久标识符隐藏 在 2G/3G/4G 时代，用户永久标识符（IMSI）在初始附着时以**明文**方式通过空口广播。攻击者只需一台伪基站（IMSI Catcher），就可以主动触发 Attach Request，被动监听并采集 IMSI，进而构建大规模用户位置与身份画像库。这一隐私缺陷的根源在于：**永久标识符必须在网络识别用户之前先被发送，而明文发送本身即构成泄露面**。 3GPP 在设计 5G 时，将"标识符隐私"（Identity Confidentiality）作为 R15 安全架构的一等公民写入 TS 33.501。其核心思路是：**在 UE 侧用归属网络（Home Network）的公钥对 SUPI（Subscription Permanent Identifier）进行非对称加密，生成临时的、每次可变的 SUCI（Subscription Concealed Identifier）；只有持有对应私钥的归属网络才能还原 SUPI**。这样，即使伪基站截获 SUCI，也无法将其与某次会话之外的任何历史记录关联——因为 SUCI 每次都不同（临时密钥每次随机生成）。 这一机制本质上是把"明文 IMSI"这一隐私攻击入口关闭，代价是引入了基于 ECIES（Elliptic Curve Integrated Encryption Scheme）的公钥加密体系和一个专用的去隐藏网元功能 SIDF。本文将完整拆解这条链路：从 SUCI 的字节结构、三种保护方案、UE 侧 ECIES 加密流程，到注册信令中 AMF 与 UDM/SIDF 的交互，再到抓包识别与故障排查。 ## 二、SUCI 的结构与字段拆解 SUCI 不是简单的"加密后的字符串"，而是一个有明确字段编排的结构化标识符，定义于 TS 23.003 Clause 2.10。其结构如下图所示： ```mermaid flowchart LR SUCI[SUCI] --> T["SUPI Type
(IMSI / Network Specific)"] SUCI --> HN["Home Network ID
MCC + MNC（明文）"] SUCI --> RI["Routing Indicator
（明文，路由用）"] SUCI --> PS["Protection Scheme Id
0=Null / 1=ProfA / 2=ProfB"] SUCI --> PKI["HN Public Key Id
（0~255）"] SUCI --> SO["Scheme Output
（加密载荷）"] SO --> SO1["Ephemeral Public Key R"] SO --> SO2["Encrypted MSIN C*"] SO --> SO3["MAC Tag"] ``` 各字段的含义与作用如下表（TS 23.003 Clause 2.10、TS 33.501 Clause 5.9）： | 字段 | 长度/取值 | 明文/密文 | 作用 | |------|-----------|-----------|------| | SUPI Type | 4 bit | 明文 | 指示 SUPI 类型：`0`=IMSI（最常见），`1`=Network Specific Identifier | | Home Network ID | MCC(3位)+MNC(2~3位) | **明文** | 归属网络标识，用于路由到归属网络 | | Routing Indicator | 1~4位十进制 | **明文** | 指示路由到归属网络的哪个 SIDF 实例，便于部署多 SIDF 分流 | | Protection Scheme Id | 4 bit | 明文 | `0`=Null-scheme，`1`=ECIES Profile A，`2`=ECIES Profile B | | HN Public Key Id | 8 bit (0~255) | 明文 | 标识使用哪一对归属网络公私钥（支持密钥轮换） | | Scheme Output | 变长 | **密文** | 加密后的内容，结构由具体 Protection Scheme 决定 | **设计要点**：注意 Home Network ID（MCC+MNC）与 Routing Indicator 是**明文**的——因为它们必须被中间网元（如 AMF、拜访网络）用于把信令路由到正确的归属网络 SIDF，不可能加密。真正被保护的是 **Scheme Output** 中的 SUPI 有效载荷（对于 IMSI 类型，即 MSIN 部分）。攻击者即使知道"这是归属到运营商 X 的某用户"，也无法得知该用户是谁——这正是 SUCI 提供的隐私粒度。 需要特别强调：对于 IMSI 类型的 SUPI，被加密的只是 **MSIN**（移动用户识别号），而 MCC+MNC 保留在明文头部。这是出于路由效率的折中——MCC+MNC 本身只暴露"哪个运营商的用户"，在隐私模型中被视为可接受的泄露。 ## 三、三种保护方案：Null-scheme、Profile A、Profile B TS 33.501 Annex C 定义了三种保护方案。UE 选择哪一种，取决于 USIM 卡中 EF_SUCI_Calc_Info 文件（TS 31.102）是否预置了归属网络公钥。 ### 3.1 Null-scheme（空方案，Annex C.1） 当 USIM **没有预置**归属网络公钥时，UE 必须使用 Null-scheme。其本质是"不加密"：Scheme Output 直接就是明文 MSIN（对 IMSI 类型）。此时 SUCI 提供的隐私保护**等同于 4G**——即不提供永久标识符隐藏。Null-scheme 的存在是为了保证后向兼容性，让旧式 USIM 也能接入 5G 网络。 Null-scheme 下，Scheme Output 仅包含 MSIN 的十进制表示，没有 Ephemeral Public Key 和 MAC Tag。 ### 3.2 ECIES Profile A 与 Profile B 当 USIM 预置了公钥时，UE 使用 ECIES 方案。两个 Profile 的差异在于底层椭圆曲线与部分密码学参数： | 维度 | **ECIES Profile A** | **ECIES Profile B** | |------|---------------------|---------------------| | 规范出处 | TS 33.501 Annex C.2 | TS 33.501 Annex C.3 | | 椭圆曲线 | Curve25519（X25519） | secp256r1（NIST P-256） | | 曲线阶位数 | 255 bit | 256 bit | | 公钥编码 | 32 字节（u-coordinate） | 33 字节压缩 / 65 字节未压缩 | | ECDH 共享秘密推导 | X25519 标量乘 | secp256r1 标量乘 | | KDF | HKDF-SHA256 | HKDF-SHA256 | | 对称加密 | AES-128 in CTR mode | AES-128 in CTR mode | | MAC 构造 | Annex C.2.4 定义 | Annex C.3.4 定义（HMAC-SHA-256） | | Scheme Output 组成 | R ‖ C* ‖ MAC | R ‖ C* ‖ MAC | **为什么要有两个 Profile？** 这是一个典型的标准政治学产物： - **Profile B（secp256r1）** 是 NIST 曲线，美国及部分北美运营商倾向于使用，因其硬件加速器、HSM、安全芯片生态成熟； - **Profile A（Curve25519）** 由 Daniel J. Bernstein 设计，被欧洲学术界与隐私倡导者认为在实现简洁性、抗侧信道攻击方面更优，且不受 NIST 后门争议影响。 3GPP 不愿在两者之间做单选，于是把选择权交给运营商：归属网络决定预置哪种公钥，UE 据此使用对应 Profile。这也意味着，**UE 必须同时支持 Profile A 和 Profile B 的解算逻辑**，由 USIM 中的 Protection Scheme Id 字段动态决定。 ## 四、UE 侧 SUCI 生成：ECIES 加密流程全链 UE（确切地说是 USIM，参见 TS 31.102 的 SUCI calculation profile）在发起初始注册前，对 SUPI 执行 ECIES 加密。完整流程如下： ```mermaid flowchart TD IN["输入: MSIN（明文）
+ 归属网络公钥 PK"] --> GEN["① 生成临时私钥 d（随机数）
计算临时公钥 R = d * G"] GEN --> ECDH["② ECDH 共享秘密推导
SS = f(d, PK)"] ECDH --> KDF["③ KDF 派生对称密钥
K = HKDF-SHA256(SS)
K_e = K[0:16], K_mac = K[16:32]"] KDF --> ENC["④ 加密: C* = AES-128-CTR(K_e, MSIN)
计数器从 0 开始"] ENC --> MAC["⑤ 计算 MAC Tag
tag = MAC(K_mac, C*)"] MAC --> OUT["⑥ 拼装 Scheme Output
= R ‖ C* ‖ tag
并组装完整 SUCI"] ``` 逐步解析每个步骤中的关键 Information Element： **① 临时密钥对生成**：UE 每次计算 SUCI 都生成一个**全新**的临时私钥 `d`（一次性随机数）和对应的临时公钥 `R = d * G`。这是 SUCI"每次可变"的根本来源——即使加密同一个 SUPI，由于 `d` 不同，`R`、共享秘密、密文、MAC 全部不同。这保证了**前向隐私**和**不可关联性**（un-linkability）。 **② ECDH 共享秘密**：UE 用临时私钥 `d` 与归属网络公钥 `PK` 做椭圆曲线 Diffie-Hellman，得到共享秘密 `SS = d · PK = d · (s · G) = s · R`，其中 `s` 是归属网络的私钥。注意 UE 不知道 `s`，但 ECDH 协议保证 UE 算出的 `SS` 与 SIDF 用 `s` 和 `R` 算出的 `SS` 完全一致。 **③ KDF 密钥派生**：用 HKDF-SHA256 从共享秘密 `SS` 派生出两个对称密钥：加密密钥 `K_e`（16 字节）和 MAC 密钥 `K_mac`（16 字节）。HKDF 的 info 参数固定为 `"SUCI shared secret"`（Annex C.2.2），盐值取归属网络公钥的编码。 **④ 对称加密**：用 `K_e` 对 MSIN 做 AES-128-CTR 加密。CTR 模式将 MSIN 视为字节流，初始计数器（counter block）固定为全 0。CTR 模式的选择是因为它无需填充（padding-free），对变长 MSIN 友好。 **⑤ MAC 计算**：用 `K_mac` 对密文 `C*` 计算认证标签 `tag`。这一步提供**完整性保护**——防止攻击者篡改密文导致 SIDF 解出错误的 MSIN。 **⑥ Scheme Output 拼装**：`Scheme Output = R ‖ C* ‖ tag`，即临时公钥、密文、MAC 标签三段拼接，再封装进 SUCI 的完整结构（含明文头部）。最终 SUCI 通过 NAS Registration Request 发送。 **设计意图**：整个 ECIES 是一个标准的"密钥封装 + 数据封装"混合加密（KEM/DEM）结构。ECDH 完成密钥协商（KEM），AES-CTR + MAC 完成数据保护（DEM）。之所以不用纯 RSA 直接加密，是因为椭圆曲线在同等安全强度下密钥更短（256 bit vs 3072 bit）、计算更快，更适合 UE/USIM 这种资源受限环境。 ## 五、注册信令时序：从 SUCI 到 SUPI 还原 SUCI 的生命发生在初始注册流程中（TS 23.502 Clause 4.2.2）。关键信令交互如下： ```mermaid sequenceDiagram participant UE participant AMF participant UDM as UDM / SIDF participant UDR as UDR UE->>AMF: ① Registration Request
(携带 SUCI in 5GS Mobile Identity) Note over UE,AMF: 空口传输 SUCI
攻击者只能看到 SUCI AMF->>UDM: ② Nudm_UEAU_GenerateAuthData
(SUCI, Serving Network Name) Note over UDM: ③ SIDF 去隐藏
ECDH: SS = s · R
派生 K_e/K_mac, 验 MAC, 解密 UDM->>UDR: ④ Nudr_Query(SUPI)
按还原的 SUPI 查订阅数据 UDR-->>UDM: 返回 K, OPC, 算法列表 Note over UDM: ⑤ 用 SUPI 与永久密钥 K
生成认证向量 AV UDM-->>AMF: ⑥ 返回 Authentication Vector
(RAND, AUTN, XRES*) AMF->>UE: ⑦ Authentication Request
(RAND, AUTN, ngKSI) Note over UE: ⑧ UE 验证 AUTN
（5G AKA / EAP-AKA'） UE-->>AMF: Authentication Response(RES*) ``` 逐条消息解析关键 IE： **消息① Registration Request**：UE 在 `5GS Mobile Identity` 信息元素中携带 SUCI。该 IE 的 Type of Identity 字段指示这是 SUCI（而非 5G-GUTI 或 IMEI）。当 UE 没有 5G-GUTI（首次注册或 GUTI 失效）时，必须用 SUCI。注意：如果 UE 有有效的 5G-GUTI，会优先用 GUTI（因为 GUTI 本身已是临时标识，无需 SUCI）——SUCI 主要在 GUTI 不可用的场景出现。 **消息② Nudm_UEAU_GenerateAuthData**：AMF 收到 SUCI 后，调用 UDM 的认证服务（TS 29.503），将 SUCI 透传给 UDM。AMF **不解析、不解密** SUCI——它没有私钥，也没有这个能力。AMF 只是搬运工。这里还携带 Serving Network Name（服务网络名），用于后续 5G AKA 的密钥派生。 **③ SIDF 去隐藏**：UDM 内的 SIDF 子功能（TS 33.501 Clause 6.12）执行 ECIES 解密： ```mermaid flowchart TD A["输入: SUCI 的 Scheme Output
R, C*, tag + 归属网络私钥 s"] --> B["① ECDH 共享秘密
SS = s · R"] B --> C["② KDF 派生
K_e, K_mac（与UE侧完全相同）"] C --> D["③ 验证 MAC: tag' ?= MAC(K_mac, C*)"] D -->|验证失败| X["拒绝, 返回错误"] D -->|验证成功| E["④ 解密: MSIN = AES-128-CTR⁻¹(K_e, C*)"] E --> F["⑤ 重组 SUPI
= MCC + MNC(明文头) + MSIN"] F --> G["输出: 明文 SUPI 供后续认证使用"] ``` **④⑤ 查询与生成认证向量**：还原 SUPI 后，UDM 用 SUPI 作为主键向 UDR 查询订阅数据（永久密钥 K、OPC、认证算法列表），然后用 5G AKA 或 EAP-AKA' 流程生成认证向量 AV（含 RAND、AUTN、XRES*）。**这一步的前提就是 SIDF 先把 SUPI 还原出来**——没有 SUPI，UDM 根本不知道查哪个用户。 **⑥⑦⑧**：认证向量返回 AMF，AMF 下发 Authentication Request，UE 验证网络身份后返回 RES*，完成 5G AKA 主认证（这部分见作者前序《5G AKA 主认证双确认机制全链拆解》）。值得强调：**SUCI 去隐藏发生在主认证之前**，是认证能够启动的前置条件。 ## 六、SIDF 的部署与安全定位 SIDF（Subscription Identifier De-concealing Function）在架构上是 UDM 的一个功能，但 TS 33.501 Clause 6.12 对其安全定位有严格规定： - **私钥唯一存放点**：归属网络的私钥 `s` **只能**存放在 SIDF（及承载它的硬件安全模块 HSM 中）。任何其他网元（AMF、SMF、AUSF）都不得持有私钥，从而将私钥泄露面收敛到最小。 - **集中化去隐藏**：所有 SUCI 去隐藏请求都汇聚到 SIDF 这一个点，便于集中审计、监控异常去隐藏频率（例如某 IP 短时间内大量去隐藏不同 SUCI 可能是攻击征兆）。 - **Routing Indicator 分流**：当单 SIDF 处理能力不足时，归属网络可部署多个 SIDF 实例，通过 SUCI 中的 Routing Indicator（明文字段）将请求路由到不同实例，所有实例共享同一私钥或分片持有。 - **HSM 强制**：运营商部署中，私钥通常存放在 FIPS 140-2 Level 3 及以上的 HSM（如 Thales Luna HSM），私钥永不离开 HSM 边界，所有 ECDH 运算在 HSM 内部完成。 **为什么不把去隐藏做成分布式？** 因为私钥分发即等于泄露面扩大。集中式 SIDF 是"安全 vs 性能"权衡中明确选择安全的典型案例——宁可牺牲一点可扩展性，也要确保永久标识符的解密能力集中可控。 ## 七、设计意图深度分析：为什么是这套机制 理解 SUCI/SIDF 的设计，需要回到三个核心矛盾： **矛盾一：永久标识符必须先于认证发送。** 网络在认证用户之前，必须先知道"用户是谁"才能查到对应的认证密钥。这意味着标识符的发送是无条件、无会话的。明文发送是 4G 的缺陷；SUCI 用公钥加密把这个"必须先发送"的泄露面加密掉。 **矛盾二：每次加密结果必须不同（不可关联性）。** 如果两次加密同一 SUPI 得到相同 SUCI，攻击者就能跨会话关联同一用户。ECIES 的临时密钥 `d` 每次随机，确保 SUCI 每次不同，从密码学上保证不可关联性。这是相比"固定对称密钥加密"方案的关键优势。 **矛盾三：去隐藏能力必须可控。** 私钥若分散存放，任一节点被攻破即全盘泄露。SIDF 集中化 + HSM 隔离，把去隐藏能力变成网络中受保护程度最高的"皇冠上的明珠"。 **一个常被忽略的设计**：SUCI 只保护永久标识符，**不保护后续信令**。注册成功后，AMF 会分配 5G-GUTI，后续信令用 GUTI 临时标识。SUCI 与 GUTI 形成"双保险"——SUCI 保护首次出现的永久标识符，GUTI 保护后续所有交互。两者职责不同，互补而非替代。 ## 八、抓包识别与故障排查 ### 8.1 抓包如何识别 SUCI 流程 在 Wireshark/TShark 抓取 NGAP + NAS 信令时，识别 SUCI 的要点： - **NAS Registration Request** 中 `5GS Mobile Identity` IE：若 `Type of identity` = `SUCI`（值 4），则该字段为 SUCI。 - `SUPI format` 子字段指示是 IMSI 类型还是 Network Specific 类型。 - `Protection scheme identifier` 显示是 Null（0）、Profile A（1）还是 Profile B（2）。 - `Home network public key identifier` 显示使用的公钥 ID。 若在空口抓包看到 `5GS Mobile Identity` 的 `Type of identity` 显示为 `IMSI` 或 SUCI scheme = Null-scheme 且 MSIN 明文可见，说明该用户**未启用 SUCI 保护**（USIM 未预置公钥），这是隐私降级场景。 ### 8.2 常见故障点 | 故障现象 | 可能原因 | 排查思路 | |----------|----------|----------| | AMF 转发 SUCI 后 UDM 返回失败 | SIDF 私钥与 USIM 公钥不匹配（公钥 ID 错配） | 核对 USIM EF_SUCI_Calc_Info 的公钥 ID 与 UDM/SIDF 持有私钥的 ID 是否一致 | | SUCI 去隐藏成功但 SUPI 错误 | KDF 的 info 参数实现不一致（厂商差异） | 抓包对比 UE 侧与 SIDF 侧的 HKDF info 字符串是否为 `"SUCI shared secret"` | | MAC 验证失败导致去隐藏被拒 | Curve25519 vs secp256r1 协商不一致 | 检查 Protection Scheme Id，确保 UE 与 SIDF 支持同一 Profile | | 频繁 SUCI 解密失败 | 网络未预置公钥，UE 回退 Null-scheme | 确认 USIM 是否写入公钥；检查是否运营商未启用 SUCI 服务 | ## 九、常见问题 **Q1: SUCI 和 5G-GUTI 有什么区别？为什么需要两个？** A: SUCI 是加密后的**永久**标识符（含 SUPI 的加密载荷），用于首次注册或 GUTI 失效时；5G-GUTI 是 AMF 分配的**临时**标识符，用于后续所有信令。SUCI 由 UE 用公钥加密生成，GUTI 由 AMF 明文分配。两者互补：SUCI 解决"永久标识符首次发送"的隐私问题，GUTI 解决"日常交互"的隐私问题。一旦拿到 GUTI，UE 就不再发送 SUCI，减少 SUCI 出现频率。 **Q2: Null-scheme 下 SUCI 还提供隐私保护吗？** A: 不提供。Null-scheme 的 Scheme Output 就是明文 MSIN，隐私等级等同于 4G 的明文 IMSI。3GPP 保留 Null-scheme 纯粹是为兼容未预置公钥的旧 USIM 卡，是过渡性方案。运营商启用 SUCI 服务的标志就是向 USIM 预置公钥并指定 Profile A 或 B。 **Q3: 攻击者拿到大量 SUCI 能否暴力破解 SUPI？** A: 在密码学上不可行。SUCI 基于 ECIES，其安全性依赖 ECDH 的离散对数难题（Curve25519/secp256r1）和 AES-128/HMAC 的对称安全性。攻击者没有私钥 `s`，无法从 SUCI 还原 MSIN。唯一可行的攻击是**针对私钥持有方（SIDF/HSM）的攻击**或**侧信道攻击**，这正是 SIDF 集中化 + HSM 隔离要防御的。 **Q4: 归属网络公钥可以更新吗？更新后旧 SUCI 怎么办？** A: 可以更新，通过 Public Key Id（0~255）区分不同代的公钥。USIM 通过 EF_SUCI_Calc_Info 可预置多个公钥及 ID，UE 计算时携带所用 ID，SIDF 据此选对应私钥解密。这样在密钥轮换期间，新旧 SUCI 都能被正确去隐藏，实现无中断的密钥更新。 **Q5: 为什么 SUCI 头部（MCC+MNC）不加密？** A: 因为 MCC+MNC 必须用于路由——拜访网络的 AMF 需要依据明文 Home Network ID 把信令路由到正确的归属网络 UDM。若加密头部，路由就无法进行。隐私模型认为"暴露是哪个运营商的用户"是可接受的，真正敏感的"是哪个具体用户（MSIN）"才需要加密。 ## 参考来源 1. [3GPP TS 33.501 — Security architecture and procedures for the 5G system](https://www.3gpp.org/dynareport/33501.htm) — Annex C.1/C.2/C.3（保护方案）、Clause 5.9.2（SUCI 计算）、Clause 6.12（SIDF 去隐藏） 2. [3GPP TS 23.003 — Numbering, addressing and identification](https://www.3gpp.org/dynareport/23003.htm) — Clause 2.10 SUCI 格式定义 3. [NIST CSWP 36 — Protecting Subscriber Identifiers with SUCI](https://csrc.nist.gov/pubs/cswp/36/a/protecting-subscriber-identifiers-with-suci-applyi/final) — NIST 关于 SUCI 部署的白皮书 4. [3GPP TS 31.102 — Characteristics of the USIM application](https://www.3gpp.org/dynareport/31102.htm) — EF_SUCI_Calc_Info 文件（公钥预置） 5. [Thales — 5G Subscriber Privacy and Authentication HSM Protection](https://cpl.thalesgroup.com/) — SIDF 私钥的 HSM 存储与运算隔离实践 --- > 本文由「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 等场景全覆盖。