# 5G SUCI 身份隐私保护机制深度拆解：ECIES 加密、SIDF 去隐藏与 Null-Scheme 风险 ## 一、为什么 5G 必须引入 SUCI：从 IMSI 明文之痛说起 在 3G/4G 时代，用户永久标识 IMSI 在初始附着（Attach）过程中**以明文形式直接空口传输**。当 UE 没有有效的 GUTI（临时标识）时——例如首次开机、长期关机后重新接入、或被伪基站强制要求上报身份——网络会通过 `Identity Request` 消息索取 IMSI，UE 便在空中接口明文回传。这一设计缺陷催生了臭名昭著的 **IMSI Catcher（伪基站）攻击**：攻击者只需一台廉价软件无线电设备，主动广播一个比真实基站信号更强的伪基站，就能迫使所有附近 UE 上报 IMSI，进而实现对特定用户的身份识别、位置追踪与活动画像。这类攻击在 pre-5G 网络中"长期存在且严重"（arXiv:2105.10440）。 3GPP 在 Release 15 设计 5G 安全架构时，将**用户身份隐私**列为最高优先级目标之一（TS 33.501 §6.12）。其核心方案是：**永久标识 SUPI 永远不以明文形式出现在空口**，取而代之的是通过密码学手段包装出的**可隐藏标识 SUCI（Subscription Concealed Identifier）**。只有用户归属网络（Home Network）持有对应私钥的 SIDF（Subscriber Identifier De-concealing Function）才能解开 SUCI 还原出 SUPI，拜访网络、服务网络乃至任何空口窃听者都无法获取真实身份。 需要特别强调的是：SUCI **必须自带加密保护**。原因在于它出现在 UE 与网络建立**任何安全上下文之前**——即 `Registration Request` 这条 NAS 第一条消息中，此时 NAS 加密/完整性保护尚未启动。这与 PEI（IMEISV）的处理截然不同：PEI 通常在 NAS 安全模式控制（SMC）建立之后才发送，已被 NAS 密码学保护。因此 SUCI 不能依赖 NAS 层安全，必须用 ECIES 实现"自保护"。 ## 二、SUCI 的标识体系与 IE 结构 SUPI（Subscription Permanent Identifier）是 5G 中订阅的全局唯一永久标识，其基于 IMSI 的格式为： ``` SUPI = MCC | MNC | MSIN 例: MCC|MNC = '274012', MSIN = '001002086' ``` 其中 **MCC（移动国家码）+ MNC（移动网络码）标识归属网络 PLMN，MSIN（移动用户标识号）才是真正需要被加密保护的、对每个用户唯一的身份部分**。SUCI 的设计精髓在于：MCC/MNC 这部分归属网络标识在空口以明文传输（否则 AMF 无法知道把鉴权请求路由给哪个归属网络），而 MSIN 部分被 ECIES 加密。这样攻击者只能知道"某归属网络的某用户在活动"，但无法识别"是谁"。 SUCI 在 NAS 层承载于 **5GS Mobile Identity IE** 中（TS 24.501 §9.11.3.4），其字段结构如下表： ### 表1：SUCI（IMSI 类型）IE 字段说明（TS 24.501 §9.11.3.4） | 字段 | 长度 | 取值/含义 | 是否明文 | |------|------|-----------|----------| | Type of identity | 4 bit | `0001` = SUCI（`0010`=5G-GUTI，`0011`=IMEI） | 明文 | | SUPI format | 3 bit | `0` = IMSI 类型，`1` = Network Specific Identifier | 明文 | | Spare | 1 bit | 备用，置 0 | 明文 | | MCC + MNC | BCD | 归属网络 PLMN（MNC 不足 3 位用 `F` 补齐） | **明文** | | Routing Indicator | 最多 4 位 BCD | USIM 中 EF_Routing_Indicator 预置，路由到归属网内特定 SIDF/UDM 实例 | 明文 | | Protection Scheme Identifier | 4 bit | `0`=Null-scheme，`1`=Profile A，`2`=Profile B | 明文 | | Home Network Public Key ID | 8 bit | 标识归属网络公钥（0–255），便于密钥轮换 | 明文 | | Scheme Output | 变长 | ECIES 输出（临时公钥 e ‖ MAC ‖ 密文 C）；Null 时为明文 MSIN | **加密** | 值得注意的是 **Routing Indicator（路由指示符）** 的设计意图：当归属网络部署多个 UDM/SIDF 实例时，每个实例可能持有不同的归属网络私钥。非零的 Routing Indicator 让 NRF 能将鉴权请求路由到持有对应私钥的那个 SIDF 实例；若为 `0` 则按默认规则选择任意一个 SIDF。这同时实现了**负载分担**与**密钥分发隔离**。 ## 三、ECIES 保护机制核心拆解（TS 33.501 Annex C.3） SUCI 的加密采用 **ECIES（Elliptic Curve Integrated Encryption Scheme，椭圆曲线集成加密方案）**，完整流程在 TS 33.501 Annex C.3 中定义。其核心思想是：UE 利用预置在 USIM 中的**归属网络公钥 PK_HN**，结合每次新生成的**临时密钥对（d, e）**，通过 ECDH 协商出一个只有归属网络能算出的共享秘密，再据此派生加密密钥与 MAC 密钥。 ### 3.1 UE 侧加密流程（Annex C.3.2） ```mermaid flowchart TD A["输入: MSIN(取自SUPI) + 归属网络公钥 PK_HN"] --> B["生成临时椭圆曲线密钥对: 私钥 d, 公钥 e"] B --> C["ECDH 共享秘密: X = ECDH(d, PK_HN)"] C --> D["KDF: ANSI-X9.63 / SHA-256
SharedInfo = e ‖ PK_HN"] D --> E["派生 48 字节密钥材料
Key(前16字节) ‖ MacKey(后32字节)"] E --> F["对称加密: C = AES-128-Encrypt(Key, MSIN)"] F --> G["完整性: MAC = HMAC-SHA-256(MacKey, e ‖ C)"] G --> H["Scheme Output = e ‖ MAC ‖ C"] H --> I["SUCI = PLMN ‖ RI ‖ SchemeID ‖ PKI ‖ e ‖ MAC ‖ C"] ``` 其密码学要点在于： 1. **临时密钥对保证前向新鲜性**：UE 每次（重新）计算 SUCI 都生成全新的临时私钥 `d`，因此**同一个 SUPI 每次产生的 SUCI 都不同**。这使得被动攻击者无法通过比对 SUCI 来关联同一用户的多次接入，从源头消除了"标识稳定性"带来的追踪风险。 2. **ECDH 实现非对称保密**：共享秘密 `X = ECDH(d, PK_HN)`，只有持有对应私钥 `SK_HN` 的归属网络能算出同一个 `X`（因为 `ECDH(d, PK_HN) == ECDH(SK_HN, e)`）。空口窃听者即使捕获了 `e`，没有 `SK_HN` 也无法解出 `X`。 3. **KDF 派生对称密钥**：用 ANSI-X9.63 KDF（哈希函数 SHA-256）从 `X` 派生 48 字节密钥材料——前 16 字节作 AES-128 对称加密密钥，后 32 字节作 HMAC-SHA-256 完整性密钥。 4. **AES-128 加密 MSIN**：MSIN 经 BCD 编码后（10 位 MSIN 仅占 5 字节），填充为单个 16 字节分组，用 AES-128 加密（单块）。**典型的 MSIN 恰好一个 AES 块**，这也是规范选择简单分组模式可行的前提。 5. **HMAC 提供完整性与认证**：MAC 标签覆盖临时公钥 `e` 与密文 `C`，防止篡改。归属网络验证 MAC 失败即丢弃，防止注入伪造 SUCI。 ### 3.2 归属网络侧解密流程（Annex C.3.3，SIDF） 归属网络侧解密在 **SIDF（Subscriber Identifier De-concealing Function）** 中完成，SIDF 逻辑上位于 AUSF/UDM 内（TS 33.501 规定 SIDF 部署于归属网络，可与 UDM 合设或分离部署）： 1. 从 SUCI 提取 Home Network Public Key ID，据此选用对应的**归属网络私钥 `SK_HN`**； 2. 重算共享秘密 `X = ECDH(SK_HN, e)`（与 UE 侧 `ECDH(d, PK_HN)` 椭圆曲线运算等价）； 3. 用相同的 KDF 与 SharedInfo 派生出同样的 `Key` 与 `MacKey`； 4. **先验证 MAC**：`HMAC-SHA-256(MacKey, e ‖ C) == 收到的 MAC`，不匹配则拒绝； 5. **再解密**：`MSIN = AES-128-Decrypt(Key, C)`； 6. 拼接 `SUPI = MCC ‖ MNC ‖ MSIN`，返回给鉴权流程使用。 "先验 MAC 后解密"的顺序是密码学工程的最佳实践（Encrypt-then-MAC），可防止选择密文攻击。 ### 3.3 Profile A 与 Profile B 的真实差异 3GPP 定义了两套 ECIES Profile，**两者的差异仅在椭圆曲线本身**，KDF/HMAC/AES 算法完全相同。这里必须澄清一个流传甚广的错误说法：**Profile A 使用 Curve25519，Profile B 使用 secp256r1（NIST P-256）**——许多二手资料将其张冠李戴。以下证据链可证明这一点： - **free5GC** 官方配置（测试数据源自 TS 33501-f60 Annex C.4）： ```yaml SuciProfile: - ProtectionScheme: 1 # Profile A → Curve25519 PrivateKey: c53c22208b61860b06c62e5406a7b330c2b577aa5558981510d128247d38bd1d PublicKey: 5a8d38864820197c3394b92613b20b91633cbd897119273bf8e4a6f4eec0a650 # 32字节 - ProtectionScheme: 2 # Profile B → secp256r1 PrivateKey: F1AB1074477EBCC7F554EA1C5FC368B1616730155E0041AC447D6301975FECDA PublicKey: 0472DA7197... # 65字节非压缩点(04前缀) ``` - **Open5GS** 生成密钥的命令注释明确标注：`scheme: 1` 用 `openssl genpkey -algorithm X25519`，`scheme: 2` 用 `openssl ecparam -name prime256v1`。 ### 表2：三种保护方案对比 | 维度 | Null-Scheme (0) | Profile A (1) | Profile B (2) | |------|-----------------|---------------|---------------| | 椭圆曲线 | 无 | **Curve25519** (X25519) | **secp256r1 / NIST P-256** | | 临时公钥 e 长度 | — | 32 字节 | 33 字节(压缩)/65 字节(非压缩) | | 对称加密 | 无 | AES-128 | AES-128 | | MAC | 无 | HMAC-SHA-256 | HMAC-SHA-256 | | KDF | 无 | ANSI-X9.63 / SHA-256 | ANSI-X9.63 / SHA-256 | | 隐私保护 | **无（SUPI 明文）** | 完整保护 | 完整保护 | | 适用场景 | 未预置公钥的过渡期 | 推荐（实现简洁、抗侧信道） | 传统 NIST 曲线互操作 | Profile A 的 Curve25519 因实现简洁、天然抗时序侧信道攻击，被多数新建网络优先采用；Profile B 的 NIST P-256 则为已有 NIST 曲线生态的运营商提供互操作兜底。两者均满足安全要求，运营商可自行选择并预置到 USIM。 ## 四、Registration 信令全链时序 SUCI 的"诞生—传输—去隐藏"完整生命周期发生在初始注册流程中（TS 23.502 §4.2.2.2）： ```mermaid sequenceDiagram participant UE participant AMF participant UDM as UDM/SIDF participant ARPF UE->>UE: ① 从USIM读取SUPI、PK_HN、Routing Indicator UE->>UE: ② 生成临时密钥对(d,e)
ECDH→KDF→AES加密MSIN→SUCI UE->>AMF: ③ Registration Request
(Mobile Identity = SUCI) Note over AMF: AMF此时只知归属PLMN
不知SUPI AMF->>UDM: ④ Nudm_UEAuthentication_Get Request
(SUCI, SNN) UDM->>UDM: ⑤ SIDF: 用SK_HN重算ECDH→验证MAC→解密→SUPI ARPF-->>UDM: ⑥ 取订阅数据 & 生成鉴权向量AV UDM->>AMF: ⑦ Response(AV: RAND, AUTN, XRES*, KAUSF) AMF->>UE: ⑧ Authentication Request(RAND, AUTN) UE->>AMF: ⑨ Authentication Response(RES*) Note over UE,AMF: ⑩ 5G AKA 双向鉴权成功 AMF->>UE: ⑪ Security Mode Command(NAS SMC) Note over UE,AMF: NAS加密/完整性上下文建立 AMF->>UE: ⑫ Registration Accept(分配5G-GUTI) Note over UE: 此后用GUTI,不再用SUCI ``` 关键设计意图解析： - **步骤③** AMF 收到 SUCI 后，**AMF 本身并不知道 SUPI**。它只能从 SUCI 中提取明文的 MCC/MNC，据此通过 NRF 选路到归属网络的 UDM。这正是 SUCI 的隐私边界——即便服务网络被攻陷，攻击者也无法从 AMF 侧直接拿到 SUPI（需进一步攻破 UDM）。 - **步骤④⑤** 是 SIDF 发挥作用的关键节点。当 AMF 调用 UDM 的 `Nudm_UEAuthentication_Get` 服务（TS 29.503）时，UDM 内部的 SIDF 执行去隐藏。free5GC 官方文档明确记载："Upon reception of the Nudm_UEAuthentication_Get Request, the UDM shall de-conceal SUCI to gain SUPI"。只有到这一步，SUPI 才在网络侧"显形"。 - **步骤⑫** 鉴权与 NAS SMC 成功后，AMF 为 UE 分配临时标识 **5G-GUTI**。此后 UE 的所有信令都使用 GUTI 而非 SUCI，避免频繁解密开销，同时也提供持续的隐私保护（GUTI 可定期更新）。**SUCI 只在"无可用 GUTI"时使用**。 ```mermaid stateDiagram-v2 [*] --> InitialReg: 首次开机/无有效GUTI InitialReg --> SUCI使用: 用ECIES保护SUPI发送 SUCI使用 --> AuthDone: 5G AKA鉴权完成 AuthDone --> GUTI分配: AMF下发新5G-GUTI GUTI分配 --> 正常通信: 后续信令用GUTI 正常通信 --> SUCI使用: GUTI失效/被拒/Identity Request触发 正常通信 --> [*]: Deregistration去注册 ``` ## 五、Null-Scheme：5G 隐私保护的最大软肋 TS 33.501 同时定义了 **Null-Scheme（保护方案标识 = 0）**：当 USIM 未预置归属网络公钥时，UE 回退到不加密，**Scheme Output 直接是明文 MSIN**。这等于把 4G IMSI 明文暴露的问题原样保留。 Null-Scheme 存在的原因是**过渡兼容性**：运营商从 4G 升级到 5G 初期，旧 USIM 可能没有写入 5G 公钥（依赖 USIM 中 `DF.5GS`、`EF_SUCI_Calc_Info` 文件，且需启用 USIM Service 124，TS 31.102）。但代价是这些用户在 5G 网络中**完全没有身份隐私**。 ### SUCI-Catcher 攻击面 尽管 ECIES 设计严密，学术界已证明 5G 仍存在主动身份识别攻击（arXiv:2105.10440《Nori》、ACM WiSec 2021《5G SUCI-catchers: Still catching them all?》）： 1. **Null-Scheme 用户**：可直接读取明文 MSIN，等价于 IMSI Catcher。 2. **主动身份请求攻击**：伪基站广播强信号，UE 尝试用 5G-GUTI 注册；伪基站（作为伪 AMF）拒绝该 GUTI 并发起 `Identity Request`，迫使 UE 改用 SUCI。虽 SUCI 内容被 ECIES 加密，但**归属网络标识（MCC/MNC）始终明文**，攻击者可据此做粗粒度用户画像。 3. **SUCI 探测攻击**（ResearchGate《5G SUCI Probing in the Wild》）：利用 Null-Scheme 用户或网络返回的错误码差异，对目标做存在性探测。 4. **协议层稳定性**：尽管 SUCI 本身因临时密钥而变化，但同一 UE 反复接入的时间/位置模式、明文 PLMN/Routing Indicator 仍可作为侧信道关联依据。 防护建议：运营商应**强制预置公钥并禁用 Null-Scheme**（公钥轮换通过 Home Network Public Key ID 管理，支持平滑换钥）；同时在网络侧对异常高频的 Identity Request 进行检测。 ## 六、抓包识别与故障排查 ### 抓包识别（NGAP/5G NAS） 在 Wireshark 中，打开含初始注册的 pcap，过滤 `nas_5gs.reg.message_type == 65`（Registration Request）或 `nas-5gs.message_type == 0x41`，在 **5GS Mobile Identity** IE 中： - 若 `Type of identity = 1`（SUCI），展开可见 `SUPI format`、明文 `MCC/MNC`、`Routing Indicator`、`Protection Scheme ID`、`Home Network Public Key ID`、`Scheme Output`。 - **快速判断是否启用了隐私保护**：看 `Protection Scheme ID` 字段。`0` = Null-Scheme（明文 MSIN，存在风险）；`1`/`2` = 已启用 ECIES。Wireshark 对 Null-Scheme 会直接解码出 `MSIN` 数字。 - 对 Profile A/B 的 SUCI，Wireshark 只能显示 `Scheme Output` 的十六进制（临时公钥 + MAC + 密文），**无法解出 MSIN**——这正是设计目的。要验证正确性，需用归属网络私钥离线解密（可借助 free5GC/Open5GS 的 `suci` 工具或 wolfSSL 自写脚本）。 ### 常见故障点 | 现象 | 根因 | 排查思路 | |------|------|----------| | UE 发出 SUCI 后鉴权请求无响应 | UDM 侧 PKI 与 USIM 公钥不匹配（密钥轮换不同步） | 核对 AMF 转发的 `Home Network Public Key ID`，确认 UDM 持有对应私钥 | | UDM 解密失败/MAC 校验失败 | 归属网络私钥与 USIM 预置公钥非配对；或 Profile 选错（A/B 曲线混淆） | 用 TS 33.501 Annex C.4 测试向量做单元测试；检查 `scheme` 与曲线是否对应 | | UE 总是发 Null-Scheme | USIM 未预置公钥（`EF_SUCI_Calc_Info` 缺失）、Service 124 未启用、或 ME 侧配置 `protectionScheme:0` | 检查 USIM 文件树与 ME 配置（UERANSIM：`protectionScheme`/`homeNetworkPublicKey`/`homeNetworkPublicKeyId`/`routingIndicator`）| | 漫游场景 SIDF 选路失败 | Routing Indicator 为 0 或 NRF 未正确注册 SIDF 实例 | 检查 NRF 中 UDM/SIDF 实例的 key ID 注册与路由策略 | ## 七、常见问题 **Q1: SUCI 和 5G-GUTI 有什么区别？** A: 二者都是临时性标识，但用途与生命周期不同。SUCI 是**注册前**对永久标识 SUPI 的密码学包装，仅在无 GUTI 时使用一次，由 UE 用 ECIES 自加密；5G-GUTI 是**鉴权成功后**由 AMF 分配的临时标识，用于后续所有信令，由网络侧周期性更新。GUTI 不携带任何永久身份信息，且可随时更换，隐私性更强但依赖已建立的安全上下文。 **Q2: 既然 SUCI 已加密，为什么攻击者还能识别用户？** A: ECIES 加密的是 MSIN，但**归属网络标识（MCC/MNC）始终明文**，且 Null-Scheme 用户的 MSIN 完全暴露。此外，主动攻击者可拒绝 UE 的 GUTI、强制其改发 SUCI，或利用协议层时间/位置模式做侧信道关联。SUCI 防的是**被动窃听下的永久标识暴露**，无法完全抵御主动伪基站。 **Q3: Profile A 和 Profile B 该选哪个？** A: 两者安全性等价，KDF/AES/HMAC 完全相同，仅椭圆曲线不同。**Profile A（Curve25519）实现更简洁、天然抗时序侧信道，推荐新建网络采用**；**Profile B（NIST P-256）适合已有 NIST 曲线生态、需满足特定合规认证（如 FIPS）的运营商**。可二者同时预置（不同 PKI），逐步迁移。 **Q4: 归属网络公钥如何轮换而不中断服务？** A: 通过 **Home Network Public Key ID（0–255）** 实现。新旧公钥/私钥以不同 ID 并存于 USIM 与 UDM；UE 用新 PKI 计算 SUCI，UDM 按 PKI 选对应私钥解密。旧公钥可保留一个过渡期后退役，实现无感轮换。 **Q5: SIDF 必须和 UDM 合设吗？** A: 不必须。TS 33.501 规定 SIDF 是归属网络内的一个**功能**，可与 UDM 合设（多数实现如此，如 free5GC/Open5GS），也可作为独立 NF 部署以隔离密钥操作。无论哪种，**私钥 SK_HN 必须妥善保管在归属网络**——这是整个 SUCI 安全模型的信任根，一旦泄露，所有用该公钥的用户的身份隐私将全部瓦解。 ## 参考来源 1. [3GPP TS 33.501 — Security architecture and procedures for the 5G System](https://www.etsi.org/deliver/etsi_ts/133500_133599/133501/18.10.00_60/ts_133501v181000p.pdf) — §6.12 SUCI/SIDF 要求，Annex C.3 ECIES 保护方案 2. [A Note for 5G SUCI Profile A/B Scheme — s5uishida (GitHub)](https://github.com/s5uishida/note_5g_suci_profile_ab) — Profile A=Curve25519 / Profile B=secp256r1 的 OpenSSL 配置实证与测试密钥 3. [SUCI Computation on UE — Discrete Works](https://discreteworks.com/transform/2022/05/08/suci-computation-on-ue.html) — UE 侧 ECIES 计算流程与 wolfSSL 实现细节（TS 33.501 §C.3） 4. [ECIES for 5G — Thales Luna HSM 文档](https://thalesdocs.com/gphsm/luna/7/docs/network/Content/sdk/using/ecies_for_5G.htm) — Profile A/B 曲线参数与 HSM 侧解密实现 5. [Nori: Concealing the Concealed Identifier in 5G (arXiv:2105.10440)](https://arxiv.org/abs/2105.10440) — IMSI/SUCI Catcher 隐私漏洞分析与防护建议 6. [5G SUCI-Catchers: Still catching them all? (ACM WiSec 2021)](https://dl.acm.org/doi/abs/10.1145/3448300.3467826) — 5G 主动身份识别攻击的残留风险研究 --- > 本文由「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 等场景全覆盖。