# 5G SUCI身份隐藏与ECIES加密机制解读 ## 一、从一个4G时代的“遗留伤口”说起 在LTE网络中，IMSI（国际移动用户识别码）是用户在核心网侧的永久身份。协议设计了TMSI/GUTI机制来避免IMSI在空口明文传输，但这个方案有一个先天缺陷：**临时身份由网络分配、网络掌握映射关系，一旦临时身份失效（如MME重启、GUTI校验失败、寻呼响应失败），网络就会通过Identity Request要求UE回传真实IMSI**——而此时NAS安全尚未激活，IMSI以明文方式在空口传输。IMSICatcher（IMSI捕获器）正是利用这一点：主动发起Identity Request，周边所有UE被迫交出IMSI，从而实现低成本的用户追踪。这一问题在历年的学术测量研究中被反复证实。 5G系统在SA3主导的TS 33.501《Security architecture and procedures for 5G System》（Rel-15立项，当前Rel-19版本19.2.0，2025年3月SA#107冻结）中，对这一缺陷给出了釜底抽薪式的答案：**不再依赖“网络承诺不问真实身份”，而是让用户身份本身自带加密属性**。SUPI（Subscription Permanent Identifier）永久不出现在空口，空口传输的永远是SUCI（Subscription Concealed Identifier，隐匿用户标识）。SUCI的加密部分由UE或USIM在本地用归属网络公钥完成，只有归属网络持有对应私钥（存于UDM/ARPF侧）才能解出真实用户。网络端到端的解密链路，涉及AMF→AUSF→UDM→UDR一整套SBA服务调用。本文基于TS 23.003、TS 33.501、TS 24.501、TS 29.509等规范，逐步拆解这套机制。 ## 二、SUPI与SUCI的结构：从15位数字到加密串 ### 2.1 SUPI：形式上仍是IMSI SUPI是5G中用户在归属网络的唯一标识（TS 23.003《Numbering, addressing and identification》定义，该规范CT4维护，Rel-19版本19.7.0于2026年6月CT#112冻结）。对于3GPP接入，SUPI在绝大多数现网中就是IMSI（15位数字，MCC+MNC+MSIN）；对非3GPP接入可以采用NAI（Network Access Identifier，RFC 4282格式），固定接入场景还有GCI/GLI形式。关键点在于：**SUPI只在归属网络内部和UDM/UDR数据库中使用，永远不出现在空口信令中**。 ### 2.2 SUCI的六段式结构 SUCI按TS 23.003 §2.2B定义，是一个由数字组成的复合标识。在核心网SBA接口的URI中，它以形如`suci-0-901-70-0000-0-0-0000000003`的字符串出现（这是开源社区常见测试PLMN 901-70的真实格式示例）。逐段解析： ```mermaid flowchart LR A["SUCI
suci-0-901-70-0000-0-1-xxxx"] --> B["SUPI类型
1位数字
0=IMSI 1=NAI 2=GCI 3=GLI"] A --> C["归属网络标识
MCC(901)+MNC(70)
5~6位"] A --> D["路由指示
Routing Indicator
1~4位, 缺省0000"] A --> E["保护方案
Protection Scheme
0=null 1=Profile A 2=Profile B"] A --> F["归属网公钥标识
HNPK-ID
文本1位数字"] A --> G["方案输出
Scheme Output
MSIN密文或明文"] ``` 各字段说明如下表（NAS二进制编码见TS 24.501 §9.11.3.4，文本表示见TS 23.003 §2.2B）： | 字段 | 位数（文本/NAS） | 取值与含义 | 设计意图 | |---|---|---|---| | SUPI类型 | 1位数字 / 3比特 | 0=IMSI，1=NAI，2=GCI，3=GLI | 支持多种接入类型的统一封装 | | 归属网络标识 | 5~6位数字 | IMSI型即MCC+MNC（如901-70） | **不加密**——AMF需要它寻路归属网络 | | 路由指示 | 1~4位数字 | 缺省0000；可用于MVNO等场景路由到不同UDM | **不加密**——同上，属于路由信息而非用户隐私 | | 保护方案ID | 1位数字 / 4比特 | 0=null-scheme，1=ECIES Profile A，2=ECIES Profile B | 告知UDM用哪种算法/参数解密 | | 归属网公钥标识 | 1位数字 / 1个八位组（0~255） | 指明UE用了归属网络的哪把公钥 | 支持公钥轮换/多密钥共存 | | 方案输出 | 可变 | null-scheme时为MSIN明文；ECIES时为“临时公钥+密文+MAC” | 加密主体，每次注册都不同 | 注意两个细节：其一，MCC/MNC和路由指示**故意不加密**——它们是投递SUCI所必需的路由信息，不含用户个体隐私；其二，null-scheme时MSIN直接明文出现，这是协议为兼容低成本IoT场景保留的“裸奔”选项，后文将讨论其风险。 ## 三、ECIES隐藏机制：MSIN是如何被加密的 ### 3.1 为什么是ECIES而不是普通公钥加密 TS 33.501 Annex C为MSIN的加密定义了ECIES（Elliptic Curve Integrated Encryption Scheme，椭圆曲线集成加密方案）。相比RSA式的传统公钥加密，ECIES用**ECDH临时密钥协商+对称加密**完成：UE每次生成一对临时密钥，用归属网络静态公钥与自己的临时私钥算出共享密钥，派生出对称密钥加密MSIN。这带来两个关键性质： 1. **前向语义的随机性**：每次注册的临时密钥对都不同，同一个SUPI每次生成的SUCI完全不同，攻击者无法通过SUCI关联同一用户在不同时间/地点的活动轨迹； 2. **无证书轻量化**：不需要PKI证书体系，只要SIM中预置归属网络公钥即可，适配SIM卡有限的存储与算力。 3GPP定义了三个保护方案Profile（null-scheme，及TS 33.501 Annex C.3.4中的Profile A与Profile B）： | 对比项 | null-scheme（ID=0） | Profile A（ID=1） | Profile B（ID=2） | |---|---|---|---| | 隐藏效果 | 无，MSIN明文 | 完全隐藏 | 完全隐藏 | | 椭圆曲线 | — | Curve25519（X25519） | prime256v1（NIST P-256） | | 临时公钥长度 | — | 32字节 | 65字节（非压缩点） | | 密钥派生KDF | — | ANSI X9.63 KDF + SHA-256 | ANSI X9.63 KDF + SHA-256 | | 对称加密 | — | AES-256-GCM（认证加密） | AES-256-CBC | | MAC | — | GCM Tag（16字节） | HMAC-SHA-256（截断） | | 典型生态 | 早期网络/遗留SIM | IoT/eUICC生态、主流新SIM | 与传统SIM密码栈兼容性更好 | ### 3.2 SUCI生成的完整推演（UE侧） UE侧生成SUCI的输入与步骤如下： ```mermaid flowchart TB S["USIM: EF SUCI_Calc_Info
(TS 31.102, ADF_USIM下)"] --> S1["保护方案ID / HNPK-ID
路由指示 / 归属网公钥"] S1 --> K1["步骤1: 生成临时密钥对
(eph_sk, ephemeral_pub_key)"] K1 --> K2["步骤2: ECDH共享密钥
= X25519(eph_sk, HN_pub_key)
或P-256 ECDH"] MSIN["MSIN明文
(BCD编码, 约5字节)"] --> K3 K2 --> K3["步骤3: ANSI X9.63 KDF + SHA-256
派生CEK与IV/MAC密钥"] K3 --> K4["步骤4: 加密
Profile A: AES-256-GCM
Profile B: AES-256-CBC + HMAC-SHA-256"] K4 --> O["Scheme Output =
临时公钥 + 密文 + MAC"] O --> F["拼接: SUPI类型+HN ID+路由指示
+方案ID+HNPK-ID+Scheme Output
= SUCI"] ``` 这里有一个工程上容易被忽略的分叉：**SUCI可以由USIM生成，也可以由ME（终端基带）生成**。若由SIM生成，ME通过ETSI TS 102 221的GET IDENTITY命令向USIM的ADF索取现成的SUCI，SIM内部完成ECC运算——安全边界最好但速度慢；若由ME生成，ME先读出EF SUCI_Calc_Info中的公钥等参数，再在基带芯片里用临时密钥对计算——速度快，安全边界稍弱。现网两种实现都存在，这也是不同手机品牌行为差异的来源之一。 ### 3.3 UDM侧解密 UDM收到SUCI后，按方案ID+HNPK-ID选择本地私钥，执行逆过程：用私钥与SUCI中的临时公钥做ECDH → 同一KDF派生CEK → 解密还原MSIN → 拼出SUPI。解密发生在UDM/ARPF侧，**服务网络（VPLMN）全程拿不到MSIN**——漫游场景下，拜访网络的AMF只透传SUCI，这是相比4G的另一个本质改进（4G漫游下IMSI在VPLMN内部大量流转）。 ## 四、完整信令流程：从IDENTITY REQUEST到Kseaf下发 SUCI的用武之地是**注册流程中NAS安全激活之前**的身份交互环节，以及随后贯穿AMF/AUSF/UDM/UDR的认证数据获取链路。下图为TS 23.502 §4.2.2.2注册流程中与身份/认证相关的完整时序（省略与本文无关的信令）： ```mermaid sequenceDiagram participant UE as UE participant gNB as gNB/RAN participant AMF as AMF participant AUSF as AUSF participant UDM as UDM participant UDR as UDR UE->>gNB: Registration Request
(无有效5G-GUTI, clear NAS) gNB->>AMF: N2 INITIAL UE MESSAGE AMF->>UE: IDENTITY REQUEST (type=SUCI) Note over UE: 读SUCI_Calc_Info / 或SIM计算
生成临时密钥, ECIES加密MSIN UE->>AMF: IDENTITY RESPONSE
(Mobile Identity = SUCI) AMF->>AUSF: POST /nausf-auth/v1/ue-authentications
{supiOrSuci: "suci-0-...", servingNetworkName} AUSF->>UDM: POST /nudm-ueau/v1/{suci}/
security-information/generate-auth-data UDM->>UDM: ECIES解密MSIN → 还原SUPI UDM->>UDR: GET /nudr-dr/v1/subscription-data/
{supi}/authentication-data/authentication-subscription UDR-->>UDM: K/OPc/SQN/算法(5G_AKA或EAP-AKA') UDM-->>AUSF: rand, autn, xres*, Kausf AUSF-->>AMF: 201 Created
(rand, hxres*, autn + 确认资源链接) AMF->>UE: AUTHENTICATION REQUEST (rand, autn) Note over UE: 校验MAC/SQN, 算res* UE->>AMF: AUTHENTICATION RESPONSE (res*) AMF->>AUSF: PUT .../5g-aka-confirmation (res*) Note over AUSF: 比对res*与xres* AUSF-->>AMF: 200 OK (SUPI, Kseaf) AMF->>UE: SECURITY MODE COMMAND
(此后NAS信令全程加密+完整性保护) ``` 逐段拆解关键Information Element与设计要点： **（1）IDENTITY REQUEST / RESPONSE（TS 24.501 §5.3.2）**。AMF在收到无法识别5G-GUTI的Registration Request后发送IDENTITY REQUEST（5GMM消息类型0x5C），其中Identity type IE取值SUCI（5GS中只定义了SUCI一种身份类型，UE无法用IMSI应答——协议层面堵死了明文通道）。UE用IDENTITY RESPONSE（消息类型0x5D）回送Mobile Identity IE，内部就是上述SUCI结构。该消息对由T3570定时器保护，超时重传，多次失败则注册流程终止。注意此时NAS层**尚未**激活安全模式，所以SUCI必须是自保护的——这就是它存在的根本理由。 **（2）AMF→AUSF的Nausf-auth调用（TS 29.509）**。AMF向AUSF发起HTTP POST `/nausf-auth/v1/ue-authentications`，请求体携带`supiOrSuci`（即`suci-0-...`字符串）与`servingNetworkName`（SNN，形如`5G:mnc070.mcc901.3gppnetwork.org`）。SNN参与后续密钥派生，用于防范“假基站身份欺骗”，这是5G-AKA相对4G-AKA的重要增强。 **（3）AUSF→UDM的Nudm-UEAU调用（TS 29.503）**。AUSF向UDM请求生成认证向量，URI形如`/nudm-ueau/v1/suci-0-901-70-0000-0-0-0000000003/security-information/generate-auth-data`——**SUCI直接作为资源标识出现在URL中**。UDM在此刻完成ECIES解密（这是全网唯一持有私钥的环节），随后查UDR获取该用户的鉴权五元组输入（K、OPc、SQN、authenticationMethod）。authenticationMethod字段决定走5G-AKA还是EAP-AKA'。 **（4）向量下发与res\*/xres\*分体校验**。UDM返回`rand`、`autn`、`xres*`、`Kausf`（avType=5G_HE_AKA）。AUSF只保留xres*的哈希（hxres*）下发给AMF，AMF把rand/autn发给UE，UE校验通过后回res*，AMF转发给AUSF，由AUSF比对res*与xres*。这种“锚点分离”设计防止AMF被攻破后直接获得可复用的认证向量。确认成功后AUSF向AMF返回**SUPI与Kseaf**——注意：在认证确认之前，AMF甚至不知道用户的SUPI，这是SUCI机制在架构上的精髓。 **（5）密钥链路**。Kseaf→Kamf→NAS密钥（KnaS-int/KnaS-enc）逐级派生（TS 33.501 §6.2），SECURITY MODE COMMAND完成后，后续所有NAS信令受完整性保护与加密，身份隐私的“裸奔窗口”正式关闭。 ## 五、设计意图与已知弱点：这个方案不是完美的 **为什么不让网络承诺“永远不发IMSI”就行？** 4G的教训表明，临时身份方案的安全强度等于“网络实现不出错”的概率，而协议必须假设网络会被攻破或实现有缺陷。5G把隐私属性内嵌进凭证本身，UE在**被要求暴露身份之前**就已经无法暴露——即使面对恶意Identity Request，UE回传的也只是一次性的SUCI。 **已知的弱点与争议**（这部分对研究人员尤其重要）： 1. **null-scheme仍然合法**。保护方案0不做任何隐藏。现网中老USIM不含EF SUCI_Calc_Info、ME无法获得归属网公钥时，只能退化为null-scheme。曾有针对商用5G网络的学术测量报告指出，早期部分北美运营商网络使用了null-scheme（即SUCI等价于明文IMSI），此类现象被归因于SIM升级滞后——属于实现层面的遗留风险，具体运营商名单未经官方证实。 2. **只防被动窃听者，不完全防主动攻击**。SUCI保护的是“UE说什么”，而ETH Zurich研究团队的5G AKA形式化分析（Basin等，ACM CCS 2018，arXiv:1806.10360）指出，认证失败/重同步路径上仍存在身份相关的可利用行为（如通过构造失败诱导特定响应），攻击者可借此缩小用户身份范围。该分析直接推动了SA3后续CR的修补。 3. **归属网公钥的信任模型**。公钥烧录在SIM里，由发卡环节保证真实性；公钥轮换（新增HNPK-ID）需要SIM重写或ME预置，运营商演进不灵活——这是运营层面被诟病最多的一点。 ## 六、实战连接：抓包识别与故障排查 **抓包识别**。空口侧用Wireshark解密抓取NAS（需先拿到KnaS之前的消息）：过滤`nas-5gs`协议，找Security header type = plain NAS、Message type = 0x5C/0x5D的消息对；IDENTITY RESPONSE的Mobile Identity IE会显示protection scheme、HNPK-ID、ephemeral public key等字段——**若protection scheme显示为null scheme（0），立即标记为隐私风险项**。核心网侧抓SBA流量（N2/N8等接口的HTTP/2），在Nausf-auth的POST请求JSON中直接可见`suci-0-`开头的完整字符串，可逐段核对路由指示与方案ID。 **常见故障点与排错思路**： - **注册被拒cause #3（Illegal UE）或#23（5GS services not authorized）**：典型原因是UDM侧ECIES解密失败。检查HNPK-ID是否与UDM配置的私钥编号匹配（发卡密钥与核心网配置不一致是最常见事故），以及路由指示是否被UDM正确识别。 - **UE反复收到IDENTITY REQUEST**：说明Registration Request中的5G-GUTI一直无效且IDENTITY RESPONSE异常，排查T3570超时、SUCI编码错误（NAS IE长度/字段顺序错会导致AMF丢弃响应）。 - **Profile A/B互通问题**：SIM支持Profile B（P-256）而UDM只配了Profile A私钥时，解密必败。发卡前应做E2E联调：用同一批SIM样卡在测试UDM上跑通解密再批量发卡。 - **老SIM卡（无SUCI_Calc_Info）入网**：ME无公钥可用，只能null-scheme或由网络侧处理。正确姿势是换卡；临时方案是接受风险并加强空口监测。 ## 常见问题 **Q: SUCI与4G的GUTI/TMSI有什么本质区别？** A: GUTI是网络分配的临时身份，映射表存在网络侧，映射关系丢失时网络会要求UE回传明文IMSI——保护是“机会性”的。SUCI是用户侧用密码学生成的自保护身份，网络侧不掌握明文映射（只有归属网私钥能解），不存在“回退明文”的协议通道。实际流程中两者配合：首次注册用SUCI，之后AMF分配5G-GUTI用于日常移动性管理。 **Q: 同一个用户每次注册SUCI都一样吗？** A: 不一样。ECIES方案输出包含每次随机生成的临时公钥与密文，同一SUPI每次生成的SUCI都不同，这切断了“通过标识关联用户轨迹”的攻击路径。只有null-scheme的SUCI才保持不变（就是明文MSIN）。 **Q: 为什么MCC/MNC和路由指示不加密？** A: 因为AMF在拿到SUCI时还不知道用户是谁，必须依靠这些字段把认证请求路由到正确的归属UDM。它们标识的是“号段/发卡群体”而非个人，泄露风险可接受。这也是一种务实的取舍：全字段加密会让寻路本身变得不可能。 **Q: Profile A和Profile B该如何选择？互通吗？** A: 两者安全性等价（ECIES+ECDH），差异在密码栈生态：Profile A基于Curve25519+AES-GCM，实现简洁、性能好，IoT/eUICC生态偏好；Profile B基于NIST P-256+AES-CBC/HMAC，与传统SIM密码模块兼容性好。网络侧UDM可同时配置两套私钥，UE按SIM中EF SUCI_Calc_Info指示选择，所以**互通的关键在发卡环节**——SIM里的方案ID与核心网配置的私钥必须一致。 **Q: 5G还有IMSI Catcher式的追踪风险吗？** A: 被动窃听IMSI的攻击在启用ECIES的网络上基本失效。但主动攻击者仍可通过伪基站诱导UE接入并利用认证失败路径的侧信道（ETH 2018年形式化分析所揭示）获取部分身份信息；若目标网络/目标用户SIM处于null-scheme状态，则明文追踪完全可行。防护完整性取决于“全网ECIES覆盖率”，这正是监管与运营商审计的重点。 ## 参考来源 1. [3GPP TS 33.501 (Rel-19 V19.2.0, SA#107)](https://www.3gpp.org/dynareport/33501.htm) — 5G安全架构规范主页；Annex C定义ECIES Profile A/B的曲线、KDF与加解密参数，§6.2定义Kseaf→Kamf密钥层级 2. [3GPP TS 23.003 (Rel-19 V19.7.0, CT#112)](https://www.3gpp.org/dynareport/23003.htm) — Numbering, addressing and identification；§2.2B定义SUPI/SUCI六段式结构与数字化编码 3. [5G Subscriber Identifiers – SUCI & SUPI (Nick vs Networking)](https://nickvsnetworking.com/5g-subscriber-identifiers-suci-supi/) — SUCI结构与ECIES方案的工程化解读，含SIM/ME生成路径与Routing Indicator的MVNO路由示例 4. [Authentication in 5GC – Nausf-auth (Nick vs Networking)](https://nickvsnetworking.com/authentication-in-5gc-nausf-auth/) — Nausf-auth/Nudm-UEAU真实HTTP报文示例（含suci-0-901-70-...完整URI与rand/hxres*/xres*/Kausf字段） 5. [A Formal Analysis of 5G Authentication (Basin et al., ACM CCS 2018)](https://arxiv.org/abs/1806.10360) — 5G AKA形式化验证，揭示认证失败路径上的身份泄露弱点，推动SA3修补 --- > 本文由「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 等场景全覆盖。