5G SUCI 加密保护机制（ECIES）全链拆解：从 SUPI 到 SIDF 解密

一、为什么 5G 必须发明 SUCI：IMSI Catcher 的终结

在 4G/LTE 时代，用户首次接入网络时，永久身份 IMSI 会以明文形式通过空口传输。这一设计缺陷催生了 IMSI Catcher（伪基站）这一最经典、最廉价的移动通信攻击手段：攻击者只需伪装成基站广播一个陌生的 PLMN，并主动发起 Identity Request，UE 就会老老实实地把自己的 IMSI 明文回传——此后跟踪、定位、用户画像、重放攻击均可展开。Stingray、IMSI-catcher 类设备在 4G 网络中几乎没有门槛。

5G 系统在 3GPP TS 33.501（Security Architecture and Procedures）中给出了根本性的修复方案：永久标识符 SUPI（Subscription Permanent Identifier）永不以明文在空口出现。UE 在初始注册时，先用部署在 USIM 上的归属网络公钥（Home Network Public Key, HNpk）对 SUPI 的可路由部分之外的 MSIN 进行非对称加密，生成用户隐藏标识符 SUCI（Subscription Concealed Identifier），再把 SUCI 作为 Registration Request 消息中的 5GS registration type 携带的 mobile identity 发送出去。空口上监听者能看到的只有加密后的密文，无法回溯到具体的 SUPI。

这一机制的密码学核心是 ECIES（Elliptic Curve Integrated Encryption Scheme，椭圆曲线集成加密方案），定义在 TS 33.501 Annex C。本文将逐比特、逐信令消息地拆解 SUCI 的生成、传输、在 SIDF（Subscription Identifier De-concealing Function）中解密还原 SUPI 的完整链路，并给出抓包识别方法和排错实战。

本文聚焦 TS 33.501 Annex C.3（ECIES Protection Scheme）与 TS 23.502 Section 4.2.2.2（Registration）中的身份标识使用，不泛泛讨论安全架构。

二、核心标识符与角色：SUPI、SUCI、GUTI、SIDF

在拆解信令前，必须厘清 5G 身份标识体系中的几组关键概念，它们构成了隐私保护的"轮换梯队"。

SUPI 的结构（IMSI 类型）：MCC + MNC + MSIN。其中 MCC（移动国家码）、MNC（移动网络码）是公开的路由信息，必须明文以便网络路由；而 MSIN（移动用户标识号）才是真正标识"具体哪个人"的隐私核心。SUCI 的设计正是：保留 MCC/MNC/Routing Indicator 明文以供路由，仅加密 MSIN。

SIDF（Subscription Identifier De-concealing Function）是 5G 核心网中唯一持有归属网络私钥 HNpriv 的逻辑功能。它在 TS 33.501 中被规定为 UDM（Unified Data Management）的一个组成部分（deployment 上可分离部署以隔离私钥）。当 AMF 收到一个无法用 5G-GUTI 解析的 SUCI 时，会调用 UDM 的 Nudm_UEAuthentication_Get 服务，SIDF 用 HNpriv 完成 ECIES 的逆运算，恢复出 SUPI，再据此执行鉴权向量获取。

三、USIM 侧的预置：HNpk、Protection Scheme ID 与 Routing Indicator

ECIES 能否工作的前提，是 USIM 上已经预置了归属网络的公钥体系。根据 TS 31.102（USIM 应用特性），USIM 文件系统 ADF(USIM)/USIM/ 下必须包含以下与 SUCI 相关的字段（EF 文件）：

设计意图：Home Network Public Key ID 这个字段至关重要。它允许运营商在不换卡的前提下滚动更新公钥（key rotation）。一旦某把公钥被怀疑泄露或需要按周期更换，运营商只需在网络侧部署新公钥并赋予新的 Key ID，新发的 SUCI 会携带新 Key ID，SIDF 据此选择对应的私钥解密。旧公钥可在过渡期内继续服务存量用户。这是一种典型的"密钥版本管理"思想。

为什么把公钥放进 USIM 而非 ME（手机）？因为 ME 是不可信的——可以被刷机、root、替换。将 HNpk 绑定在 USIM（一个独立的、防篡改的安全芯片环境）上，可以保证即使用户更换手机，SUCI 加密能力依然随卡走，且运营商对密钥分发有完全控制权。

四、SUCI 生成全链：ECIES 逐比特运算

这是本文最核心的部分。我们以 ECIES Profile A（NIST P-256 曲线） 为例，逐字节拆解 USIM/ME 如何把 MSIN 变成 SUCI 的 scheme-output。算法定义在 TS 33.501 Annex C.3.2。

4.1 SUCI 的总体结构

SUCI = <suci-type> || <Home Network Identifier (MCC-MNC)> || <Routing Indicator>
       || <Protection Scheme ID> || <Home Network Public Key ID>
       || <Scheme Output>

其中： - suci-type：标识 SUPI 类型（0=IMSI-based，1=Network-specific） - Home Network Identifier：MCC + MNC，明文，用于路由 - Routing Indicator：明文，1-4 位，用于跨运营商网络时引导到正确的 UDM/归属网络 - Protection Scheme ID：保护方案标识（0/1/2） - Home Network Public Key ID：公钥 ID（0-255） - Scheme Output：全部密文部分，含临时公钥 + 密文 + MAC

明文部分（MCC/MNC/Routing Indicator）和密文部分（Scheme Output）的分界，正是隐私保护的关键边界：监听者能知道"这是哪个运营商的卡"，但无法知道是哪张卡。

4.2 ECIES Profile A 计算流程

flowchart TD
    A[USIM 取出 MSIN + HNpk + Key ID + Scheme ID] --> B[UE 生成临时私钥 d 随机数]
    B --> C[计算临时公钥 R = d · G<br/>G 为 P-256 基点]
    C --> D[ECDH 共享点 S = d · HNpk<br/>S = x, y]
    D --> E[KDF Oakley-IPP<br/>输入: x坐标 &#124;&#124; 临时公钥R<br/>Key: 16字节全0]
    E --> F[派生 eK 加密密钥 16B<br/>派生 iK 完整性密钥 16B]
    F --> G[AES-128-CTR 加密 MSIN<br/>IV = 全0, 输出 ciphertext]
    G --> H[HMAC-SHA-256 iK, ciphertext<br/>取前8字节 = MAC-tag]
    C --> I[Scheme Output = R &#124;&#124; ciphertext &#124;&#124; MAC]
    H --> I
    I --> J[拼接明文路由信息<br/>生成完整 SUCI]
    J --> K[放入 Registration Request<br/>mobile identity 字段]

第一步：生成临时密钥对。UE 为每次 SUCI 生成生成一个全新的随机临时私钥 d（256 bit），计算临时公钥 R = d · G（G 是 P-256 的基点）。临时公钥 R 在 Profile A 下是 65 字节（未压缩点格式：0x04 || x(32B) || y(32B)）。每次注册都换新的临时密钥对，这是 ECIES 提供前向保密语义的关键——即使 HNpriv 将来被泄露，已捕获的 SUCI 密文也无法被追溯解密（因为临时私钥 d 用完即弃，从不存储或传输）。

第二步：ECDH 共享密钥派生。UE 计算 ECDH 共享点 S = d · HNpk（用 UE 的临时私钥 d 与运营商公钥 HNpk 做标量乘法），得到点 S = (x, y)。这是一个椭圆曲线离散对数困难问题——攻击者即使同时捕获了临时公钥 R 和 HNpk，也无法反推出 d 或 S。

第三步：KDF（密钥派生函数）。TS 33.501 定义了一个基于 HMAC-SHA-256 的 KDF（Annex C.3.2）：

key  = 0x00000000000000000000000000000000   (16 字节全 0)
msg  = (x-coordinate of S, 32B) || (ephemeral public key R, 65B for Profile A)
out  = HMAC-SHA-256(key, msg)              (32 字节)
eK   = out[0:16]                           (加密密钥)
iK   = out[16:32]                          (完整性密钥)

注意 KDF 的输入同时包含了共享密钥的 x 坐标和临时公钥 R——后者把"这次会话的临时密钥"绑定进了派生过程，防止重放与混淆。

第四步：加密 MSIN。用 eK 对 MSIN 做 AES-128 in CTR mode（计数器模式），IV 固定为全 0。CTR 模式是流密码性质，密文长度等于明文长度。Profile A 与 Profile B 加密算法相同（都用 AES-128-CTR）。

第五步：完整性 MAC。用 iK 对密文做 HMAC-SHA-256，并取前 8 字节（64 bit）作为 MAC-tag。这 64 位 MAC 在空口带宽约束下提供了足够的完整性保护，能检测密文被篡改、替换。最终：

Scheme Output = ephemeral public key R (65B) || ciphertext (len(MSIN)) || MAC-tag (8B)

4.3 Profile A vs Profile B 对比

设计意图：保留两套曲线是 3GPP 标准的典型"保险"策略。NIST P-256 是美国 NIST 标准化曲线，生态成熟、硬件加速普及；Curve25519 由 Daniel J. Bernstein 设计，被认为在实现安全性（抗时序侧信道）和效率上更优，被 IETF/TLS 广泛采纳。运营商可按部署偏好选择，USIM 中通过 Protection Scheme ID 标识使用了哪一套。

4.4 Null Scheme（空方案）

Protection Scheme ID = 0 表示 Null Scheme——SUPI/MSIN 以明文形式直接放入 scheme-output，不做任何加密。这等同于 4G 的 IMSI 明文传输，彻底丧失隐私保护。

为什么标准要保留它？作为兜底方案：当 USIM 未预置 HNpk、或 HNpk 不可用、或测试/应急场景时，保证基本流程可通。但在生产网络中，开启 Null Scheme 等于把 5G 的隐私优势退化为 4G，运营商应严格监控并避免。

五、空口信令链路：SUCI 如何进入 Registration Request

SUCI 生成后，通过 NAS 层进入空口。完整的初始注册信令链路见 TS 23.502 Section 4.2.2.2（Registration procedure）。

sequenceDiagram
    autonumber
    participant UE
    participant gNB
    participant AMF
    participant UDM as UDM/SIDF
    participant AUSF as AUSF
    participant ARPF as ARPF

    Note over UE: 本地无有效 5G-GUTI<br/>或 GUTI 在 AMF 解析失败
    UE->>UE: USIM 用 HNpk 对 MSIN<br/>做 ECIES 生成 SUCI
    UE->>gNB: RRC SetupRequest
    gNB->>UE: RRC Setup
    UE->>gNB: RRC SetupComplete<br/>(携带 NAS Registration Request)
    Note over UE,gNB: NAS msg: Registration Request<br/>mobile identity = SUCI
    gNB->>AMF: NGAP Initial UE Message<br/>(含 Registration Request, SUCI)
    AMF->>UDM: Nudm_UEAuthentication_Get<br/>(SUCI, SNN)
    Note over UDM: SIDF 用 HNpriv 做 ECIES 逆运算<br/>恢复 SUPI 明文
    UDM->>ARPF: 取得 SUPI, 生成鉴权向量<br/>RAND/AUTN/XRES*
    ARPF-->>UDM: 鉴权向量
    UDM-->>AMF: 返回 SUPI + 5G AV (RAND/AUTN/XRES*/KAUSF)
    AMF->>AUSF: Nausf_UEAuthentication_Authenticate
    AUSF->>UE: NAS Authentication Request<br/>(RAND, AUTN, ngKSI)
    Note over UE: USIM 验证 AUTN<br/>计算 RES*
    UE-->>AUSF: NAS Authentication Response (RES*)
    AUSF->>AUSF: 验证 RES* == XRES*
    AUSF-->>AMF: 鉴权成功
    AMF->>UE: NAS Security Mode Command<br/>(激活 NAS 安全, 加密算法)
    Note over UE,AMF: 此后 NAS 信令加密+完整性保护
    AMF->>UE: Registration Accept<br/>(分配新 5G-GUTI)
    Note over UE,AMF: 后续用 5G-GUTI 标识,<br/>避免重复使用 SUCI

关键 Information Element 解析

消息①：NAS Registration Request（TS 24.501 §8.2.7）

这是 SUCI 进入网络的核心载体。关键 IE：

Mobile identity 这个 IE 内部又分多个子字段来编码 SUCI（TS 24.501 §9.11.3.4）： - type of identity：010 = SUCI - SUCI 内含：SUPI type + MCC/MNC + Routing Indicator + Protection scheme ID + Home network public key ID + Scheme output

设计意图：注意第 2 步——Security header type = 0，意味着 Registration Request 是明文 NAS。这是必然的"鸡生蛋"困境：要加密 NAS 就要先建立密钥，而建立密钥（鉴权）又要先知道 SUPI，知道 SUPI 又要先传 SUCI。所以 SUCI 这条消息必须在 NAS 安全激活之前发送，它只能依赖 ECIES 自身的密码学保护，而非 NAS 层加密。这就是为什么 SUCI 不能用简单的对称加密——空口上 UE 和网络之间此时还没有任何共享密钥。

消息④：Nudm_UEAuthentication_Get（SBI 服务，TS 29.503）

AMF 向 UDM 发起的 SBI HTTP 请求，请求体中携带 SUCI。UDM 内的 SIDF 触发解密。SBI 接口走的是 HTTPS（TLS），所以 SUCI 在核心网内部传输是受 TLS 保护的，但 ECIES 是额外的一层端到端保护——只有归属网络的 SIDF 能解密，途经的任何 AMF（哪怕是漫游地的 V-AMF）都无法获知 SUPI。

六、SIDF 侧解密还原 SUPI：ECIES 逆运算

SIDF 持有归属网络私钥 HNpriv，对应于 USIM 中 HNpk 的那一对密钥。解密是 ECIES 正向运算的镜像（TS 33.501 Annex C.3.2）：

flowchart TD
    A[SIDF 收到 SUCI] --> B[解析出 Protection Scheme ID<br/>和 Home Network Public Key ID]
    B --> C[据 Key ID 选取对应的 HNpriv]
    C --> D[取出 Scheme Output 中的<br/>临时公钥 R, ciphertext, MAC-tag]
    D --> E[ECDH 共享点 S' = HNpriv · R<br/>S' = x', y']
    E --> F[同样的 KDF<br/>输入: x' &#124;&#124; R]
    F --> G[派生 eK, iK]
    G --> H[HMAC-SHA-256 iK, ciphertext<br/>取前8字节, 校验 == MAC-tag]
    H --> I{MAC 校验通过?}
    I -->|否| J[拒绝, SUCI 被篡改/伪造]
    I -->|是| K[AES-128-CTR 解密 eK, ciphertext<br/>恢复 MSIN 明文]
    K --> L[拼接 MCC/MNC + MSIN<br/>还原完整 SUPI]
    L --> M[返回 SUPI 给鉴权流程]

关键密码学保证：

1. ECDH 对称性：UE 算 S = d · HNpk，SIDF 算 S' = HNpriv · R = HNpriv · (d · G) = d · (HNpriv · G) = d · HNpk = S。两者得到完全相同的共享点（椭圆曲线标量乘法的结合律），这是 ECIES 双方能独立派生出相同密钥的数学基础，整个过程从不交换私钥。

2. MAC 先验校验：解密前先验 MAC-tag，保证只有持有正确 HNpriv 的 SIDF 才能通过校验，且能检测任何传输/篡改。这是"先认证后解密"（encrypt-then-MAC）的正确顺序，避免对篡改密文做无意义解密，也防御选择密文攻击。

3. Key ID 路由：SIDF 根据 Home Network Public Key ID 从私钥库中选取对应的 HNpriv，支撑公钥滚动更新。

SIDF 解密出 SUPI 后，将 SUPI 传给 ARPF（Authentication Repository and Processing Function）生成鉴权向量，5G-AKA'/EAP-AKA' 鉴权流程随之展开。注意：SUCI 只在首次注册（或 GUTI 失效）时使用一次，鉴权成功并分配 5G-GUTI 后，后续所有信令都用临时的 5G-GUTI 标识 UE，SUCI 被尽量少用。

七、SUCI 使用频率限制：防主动去匿名化

TS 33.501 §6.12.2 规定了一个重要的防攻击机制：UE 必须限制生成新 SUCI 的频率。攻击者的一种去匿名化手段是反复触发 UE 发送 SUCI（例如反复让 UE 重选到恶意基站），结合时间/位置关联来缩小候选范围。

为此，UE 实现中维护一个"上次生成 SUCI 的时间戳"，只有当距离上次使用 SUCI 超过运营商配置的最小间隔（provisioning 给定），或当前无有效 5G-GUTI时，才允许重新生成 SUCI。配合 5G-GUTI 的轮换，正常情况下 SUCI 在网络中长期只出现有限次数，极大压缩了关联攻击的窗口。

八、抓包识别与排错实战

8.1 抓包如何识别 SUCI 流程

在 5G 核心网抓包（NGAP/NAS over N2、SBI over N8）中：

• N2 接口（NGAP）：Initial UE Message 中携带的 NAS Registration Request，查看 Mobile identity IE，type of identity = 010（SUCI）。可读出明文的 MCC/MNC/Routing Indicator/Protection Scheme ID/Key ID，以及密文的 Scheme Output。
• N8 接口（SBI）：POST /ue-authentications/{suci}/security-information，URL 中直接以 SUCI 作为路径参数，HTTP body 为 {suci: "...", servingNetworkName: "..."}。
• tshark 过滤：nas_5gs.mm.mobile_identity.type == 2（SUCI 类型）；SBI 过滤 http.request.uri contains "ue-authentications"。

8.2 常见故障点

Q1：SUCI 和 5G-GUTI 有什么区别？什么时候用哪个？ A：SUCI 是永久身份 SUPI 的加密形态，只在首次注册、或 UE/AMF 没有可用 5G-GUTI 时使用一次，目的是让网络在安全上下文建立前识别"你是谁"。5G-GUTI 是临时身份，由 AMF 在鉴权成功后分配，此后所有信令都用 5G-GUTI 标识，避免反复使用 SUCI。一句话：SUCI 解决"首次如何安全地报上永久身份"，5G-GUTI 解决"如何长期不暴露永久身份"。

Q2：为什么 SUCI 加密用非对称 ECIES，而不是对称加密？ A：因为 Registration Request 发送时，UE 和网络之间还没有任何共享密钥（密钥要等鉴权后才有）。对称加密要求双方先共享密钥，陷入"先有鸡还是先有蛋"。非对称加密让 UE 用网络的公钥加密、网络用私钥解密，无需预先共享秘密，正好契合"首次接触、零信任前置"的场景。

Q3：ECIES 用了临时密钥对，这带来什么安全收益？ A：临时密钥对提供前向保密（forward secrecy）语义。临时私钥 d 用完即弃、从不存储或传输。即使将来 HNpriv 被泄露，攻击者也无法解密历史上抓取的 SUCI 密文——因为他们无法恢复每次会话的 d。同时，每次 SUCI 用不同的临时公钥，密文每次都不同，阻断了基于密文重复的关联。

Q4：Profile A 和 Profile B 怎么选？ A：技术上两者都能满足安全要求。Profile A（P-256）生态成熟、硬件加速广泛、与 NIST 标准化体系一致，适合追求兼容与合规审计的部署。Profile B（Curve25519）临时公钥更短（省空口带宽）、原生抗时序侧信道、实现安全性更优，适合追求实现安全与效率的部署。选择取决于运营商的密钥策略与设备支持情况，USIM 中通过 Protection Scheme ID 标明。

Q5：如果 USIM 没有 HNpk，会发生什么？ A：UE 将退回 Null Scheme（Protection Scheme ID=0），SUPI/MSIN 以明文放入 SUCI 的 scheme-output，等同 4G 的 IMSI 明文传输，丧失隐私保护。这是兜底行为，生产网络应确保所有在网 USIM 都预置了 HNpk 并配置正确的 Scheme ID，避免退化为明文。

参考来源

1. 3GPP TS 33.501 — Security Architecture and Procedures for 5G System — Annex C.3 ECIES Protection Scheme、§6.12 Subscription Identifier Privacy
2. 3GPP TS 23.502 — Procedures for the 5G System — Section 4.2.2.2 Registration Procedure
3. 3GPP TS 23.501 — System Architecture for the 5G System — §5.9 Identifier handling、SIDF/UDM 功能
4. NIST White Paper — Protecting Subscriber Identifiers with Subscription Concealed Identifier (SUCI) Protection — SUCI 启用机制与隐私分析
5. ShareTechNote / Techplayon — 5G SUPI and SUCI NAS Signalling — NAS 消息中 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 等场景全覆盖。