在4G EPS中,UE的永久标识IMSI以明文形式通过空口传输,这一设计缺陷被广泛利用——伪基站(IMSI Catcher / Stingray)只需被动监听Radio Interface,即可捕获用户的IMSI,进而实施用户追踪、行为分析甚至定向攻击。3GPP SA3工作组在5G系统安全架构设计之初,就将"空口用户永久标识保护"列为核心安全目标之一。
3GPP TS 33.501 Section 5.9明确提出:SUPI(Subscriber Permanent Identifier)不得以明文形式通过空口传输(紧急呼叫等特殊场景除外)。取而代之的是SUCI(Subscription Concealed Identifier)——一个基于公钥加密的SUPI隐藏标识。
SUCI方案在TS 33.501 Section 6.12中定义,其设计目标是实现以下安全属性:
| 安全属性 | 实现机制 | 规范依据 |
|---|---|---|
| 机密性 | ECIES公钥加密,仅归属网SIDF可解密 | TS 33.501 §6.12.2/6.12.3 |
| 不可关联性 | 每次Registration生成新的临时密钥对 | TS 33.501 §6.12.1 |
| 完整性 | HMAC-SHA-256 MAC标签防篡改 | TS 33.501 Annex C.6 |
| 前向安全性 | 临时密钥对 + 静态公钥的ECDH | TS 33.501 §6.12.2 |
| 抗重放 | 临时公钥每次不同,无法复用 | TS 33.501 §6.12.1 |
graph TB
subgraph "4G EPS - IMSI暴露"
UE4[UE] -->|IMSI 明文| ENB4[eNodeB]
ENB4 -->|IMSI 明文| MME4[MME]
ATK[伪基站/IMSI Catcher] -.->|被动监听IMSI| UE4
end
subgraph "5GS - SUCI保护"
UE5[UE/USIM] -->|SUCI 加密| GNB5[gNB]
GNB5 -->|SUCI 加密| AMF5[AMF]
AMF5 -->|SUCI 加密| SIDF5[UDM/SIDF]
SIDF5 -->|解密获得SUPI| SIDF5
ATK5[攻击者] -.->|仅见密文| UE5
end
style ATK fill:#ff6b6b,color:#fff
style ATK5 fill:#51cf66,color:#fff
SUCI的格式定义在TS 23.003 Section 2.2A和TS 24.501 Section 9.11.3.4中。以IMSI类型的SUPI为例,完整的SUCI结构如下:
SUCI = <SUPI Type> <MCC> <MNC> <Routing Indicator> <Protection Scheme ID> <Home Network Public Key ID> <Scheme Output>
| 字段 | 长度 | 说明 | 取值示例 |
|---|---|---|---|
| SUPI Type | 4 bits | 标识类型:0=IMSI, 1=NAI | 0 (IMSI) |
| MCC | 12 bits | 移动国家码 | 460 (中国) |
| MNC | 8-12 bits | 移动网络码 | 00 (中国移动) |
| Routing Indicator | 1-4 digits | 路由指示,用于SUCI在归属网路由 | 0001 |
| Protection Scheme ID | 4 bits | 保护方案:0=Null, 1=Profile A, 2=Profile B | 1 (Profile A) |
| Home Network PK ID | 8 bits | 归属网公钥标识符 | 01 |
| Scheme Output | 变长 | 加密方案输出(含临时公钥+密文+MAC) | 见下文 |
Scheme Output是SUCI中最关键的部分,其内部结构根据使用的Protection Scheme不同而不同:
ECIES Profile A(Curve25519)的Scheme Output:
| 字段 | 长度 | 说明 |
|---|---|---|
| Ephemeral Public Key | 32 bytes (Curve25519) | UE生成的临时公钥 |
| Encrypted MSIN | ~40 bits变长 | AES-128-CTR加密的MSIN |
| MAC Tag | 16 bytes | HMAC-SHA-256截断后的MAC标签 |
ECIES Profile B(secp256r1)的Scheme Output:
| 字段 | 长度 | 说明 |
|---|---|---|
| Ephemeral Public Key | 64 bytes (secp256r1未压缩) | UE生成的临时公钥 |
| Encrypted MSIN | ~40 bits变长 | AES-128-CTR加密的MSIN |
| MAC Tag | 16 bytes | HMAC-SHA-256截断后的MAC标签 |
关键设计要点:MCC、MNC和Routing Indicator以明文形式包含在SUCI中,这是因为拜访网络(Visited Network)的AMF需要用这些信息将Registration消息路由到正确的归属网UDM/SIDF。真正被加密保护的是MSIN(Mobile Subscription Identification Number)——即SUPI中能够唯一标识用户的那部分。
TS 33.501还定义了Null Scheme(Protection Scheme ID = 0),此时Scheme Output直接就是未加密的MSIN明文。这种情况发生在: - USIM未配置归属网公钥 - 紧急呼叫场景 - 某些运营商尚未部署SUCI保护
Null Scheme下的SUCI本质上等价于4G的IMSI明文传输,不具备隐私保护能力。
3GPP在TS 33.501 Annex C中定义了两种ECIES保护方案,其核心区别在于使用的椭圆曲线和密钥协商算法:
| 参数 | Profile A (Scheme ID=1) | Profile B (Scheme ID=2) |
|---|---|---|
| 椭圆曲线 | Curve25519 (Montgomery) | secp256r1 (NIST P-256) |
| 密钥协商 | X25519 | ECDH |
| 临时公钥长度 | 32 bytes | 64 bytes (未压缩) |
| KDF | HKDF-SHA-256 | HKDF-SHA-256 |
| 加密算法 | AES-128-CTR | AES-128-CTR |
| MAC算法 | HMAC-SHA-256 (16B) | HMAC-SHA-256 (16B) |
| 参考章节 | TS 33.501 §6.12.2, Annex C.3.4 | TS 33.501 §6.12.3, Annex C.2 |
| 优势 | 密钥短、计算快、侧信道抗性强 | 兼容性好、NIST标准化 |
Profile A基于Daniel J. Bernstein设计的Curve25519,使用Montgomery ladder算法实现X25519密钥协商。完整加密流程分为四个阶段:
flowchart TB
subgraph "Phase 1: 密钥协商"
A1["USIM读取归属网静态公钥 PK_HN<br/>(预置在USIM中)"]
A2["UE生成临时密钥对 (sk_E, pk_E)<br/>Curve25519"]
A3["计算共享密钥<br/>EK = X25519(sk_E, PK_HN)"]
A1 --> A2 --> A3
end
subgraph "Phase 2: 密钥推衍"
B1["输入: EK (共享密钥)"]
B2["KDF: HKDF-SHA-256<br/>FC = 0x6B (SUCI Profile A)"]
B3["输出: Enc Key (16B) + MAC Key (32B)"]
B1 --> B2 --> B3
end
subgraph "Phase 3: 加密MSIN"
C1["明文: MSIN (SUPI的用户标识部分)"]
C2["AES-128-CTR 加密<br/>Key = Enc Key"]
C3["密文: Encrypted MSIN"]
C1 --> C2 --> C3
end
subgraph "Phase 4: 完整性保护"
D1["输入: pk_E || Encrypted MSIN"]
D2["HMAC-SHA-256<br/>Key = MAC Key"]
D3["MAC Tag (截断至16 bytes)"]
D1 --> D2 --> D3
end
A3 --> B1
B3 --> C2
B3 --> D2
subgraph "最终输出: Scheme Output"
E["pk_E (32B) || Encrypted MSIN || MAC Tag (16B)"]
end
C3 --> E
D3 --> E
两种Profile使用相同的KDF框架,定义在TS 33.501 Annex A.2中。KDF基于HKDF-SHA-256:
KDF输入参数:
FC = 0x6B (Profile A) / 0x6C (Profile B)
P0 = EK (共享密钥, 32 bytes)
L0 = length(P0)
P1 = || (空, 无附加参数)
L1 = 0
KDF输出:
Key = SHA-256(EK || FC || L0 || P0 || L1 || P1)
从输出中截取:
- Enc Key = Key[0:16] (16 bytes, AES-128密钥)
- MAC Key = Key[16:48] (32 bytes, HMAC密钥)
Profile B使用NIST P-256曲线和标准ECDH密钥协商。其流程与Profile A结构完全相同,差异在于:
3GPP设计双Profile的考量是一个有趣的安全与标准化博弈:
| 考量因素 | Profile A (Curve25519) | Profile B (P-256) |
|---|---|---|
| 安全界信任度 | 高(避开NIST潜在后门嫌疑) | 高(NIST FIPS合规) |
| 政府合规要求 | 部分国家不认可 | 满足多数国家合规 |
| 实现复杂度 | 低(Montgomery ladder简单) | 中(需要完整的EC运算库) |
| 侧信道抗性 | 天然抗侧信道(常数时间算法) | 需额外防护措施 |
| 密钥尺寸 | 32 bytes(更紧凑) | 64 bytes(未压缩) |
| 互操作性 | 需要较新的USIM/ME支持 | 兼容性好 |
运营商可根据自身合规要求和设备生态选择部署哪种Profile。大多数部署同时支持两种Profile,USIM中预置的Protection Scheme ID决定了UE使用哪种方案。
在5G初始注册流程中(TS 23.502 Section 4.2.2.2),SUCI的使用贯穿整个注册过程。以下信令时序图展示了完整的SUCI加密与解密流程:
sequenceDiagram
participant UE as UE/USIM
participant gNB as gNB
participant AMF as AMF<br/>(Visited Network)
participant AUSF as AUSF
participant UDM as UDM/SIDF
participant ARPF as ARPF
Note over UE: 1. 构造SUCI
UE->>UE: a) 读取USIM中的归属网公钥 PK_HN<br/>和Protection Scheme ID
UE->>UE: b) 生成临时密钥对 (sk_E, pk_E)
UE->>UE: c) ECDH/X25519协商共享密钥 EK
UE->>UE: d) KDF推衍 Enc Key + MAC Key
UE->>UE: e) AES-128-CTR加密MSIN
UE->>UE: f) HMAC-SHA-256计算MAC Tag
UE->>UE: g) 组装SUCI = SUPI Type + MCC/MNC<br/>+ Routing Indicator + Scheme ID<br/>+ PK ID + Scheme Output
rect rgb(230, 245, 255)
Note over UE,gNB: 2. Registration Request (NAS)
UE->>gNB: RRC: RRCSetupRequest<br/>含5G-S-TMSI或random value
UE->>gNB: RRC: ULInformationTransfer<br/>携带NAS Registration Request
Note over UE,gNB: NAS消息中 <mobile identity> = SUCI<br/>(非明文SUPI!)
end
gNB->>AMF: N2: Initial UE Message<br/>含Registration Request (SUCI)
Note over AMF: 3. AMF路由决策
AMF->>AMF: 解析SUCI中的MCC/MNC<br/>+ Routing Indicator<br/>确定归属网UDM地址
AMF->>AUSF: Nausf_UEAuthentication<br/>Authenticate Request<br/>(含SUCI, SN-Name)
AUSF->>UDM: Nudm_UEAuthentication<br/>Get Request (SUCI, SN-Name)
rect rgb(255, 240, 230)
Note over UDM,ARPF: 4. SIDF解密SUCI (TS 33.501 §6.12.5)
UDM->>UDM: a) 根据Scheme ID和PK ID<br/>查找对应的私钥 sk_HN
UDM->>UDM: b) 从Scheme Output提取<br/>临时公钥 pk_E
UDM->>UDM: c) ECDH/X25519(sk_HN, pk_E)<br/>计算共享密钥 EK'
UDM->>UDM: d) KDF推衍 Enc Key' + MAC Key'
UDM->>UDM: e) 验证MAC Tag<br/>(HMAC-SHA-256)
UDM->>UDM: f) MAC验证通过后<br/>AES-128-CTR解密MSIN
UDM->>UDM: g) 恢复完整SUPI
end
UDM->>ARPF: 用SUPI查找用户订阅数据<br/>获取K/OPc等认证凭据
ARPF->>UDM: 生成5G-AKA认证向量<br/>(RAND, AUTN, XRES*, KAUSF)
UDM->>AUSF: Nudm_UEAuthentication<br/>Get Response (SUPI, AV)
Note over UDM,AUSF: 此时SIDF已完成SUCI→SUPI解密<br/>后续流程使用SUPI而非SUCI
AUSF->>AMF: Nausf_UEAuthentication<br/>Authenticate Response<br/>(RAND, AUTN, HXRES*)
AMF->>UE: DL NAS: Authentication Request<br/>(RAND, AUTN)
UE->>UE: USIM验证AUTN<br/>计算RES*
UE->>AMF: UL NAS: Authentication Response<br/>(RES*)
AMF->>AUSF: Nausf_UEAuthentication<br/>Authenticate Complete (RES*)
AUSF->>AUSF: 验证 RES* == XRES*
AUSF->>AMF: 认证成功 + KSEAF
AMF->>UE: DL NAS: Security Mode Command<br/>建立NAS安全上下文
UE->>AMF: UL NAS: Security Mode Complete
Note over AMF,UE: 后续所有NAS消息均受加密和完整性保护<br/>UE获得5G-GUTI替代SUCI用于后续注册
AMF->>UE: DL NAS: Registration Accept<br/>(含5G-GUTI)
根据TS 24.501 Section 9.11.3.4,Registration Request中的<mobile identity> IE编码如下:
| 字节偏移 | 字段 | 值(示例) | 说明 |
|---|---|---|---|
| Byte 1 | IEI | 0x77 | Mobile Identity IE标识 |
| Byte 2-3 | Length | 变长 | IE总长度 |
| Byte 4 bits 7-4 | SUPI Type | 0b0000 | IMSI类型 |
| Byte 4 bits 3 | Odd/Even | 0b0 | 偶数位 |
| Byte 4 bits 2-1 | Type of Identity | 0b01 | SUCI标识 |
| Byte 5-7 | MCC+MNC | 64F000 | MCC=460, MNC=00 (BCD编码) |
| Byte 8 | Routing Indicator | 0x01 | 路由指示器 |
| Byte 9 bits 7-4 | Protection Scheme ID | 0x01 | Profile A |
| Byte 9 bits 3-0 | Home Network PK ID | 0x01 | 公钥ID=1 |
| Byte 10+ | Scheme Output | 变长 | pk_E |
抓包要点:在Wireshark中,NAS Registration Request消息的Mobile Identity字段,当
Type of Identity = 0b01(SUCI)时,解析器会展开显示SUCI的各子字段。如果看到Protection Scheme ID = 0,说明使用Null Scheme(无加密保护)。
SIDF(Subscription Identifier De-concealing Function)位于UDM中(TS 33.501 Section 6.12.5),其解密过程有严格的安全检查:
sk_HN如果MAC验证失败,SIDF必须拒绝解密并向AMF返回错误,这是为了防止篡改攻击。
stateDiagram-v2
[*] --> InitialRegistration: UE开机/失联
state "标识选择决策" as Decision {
InitialRegistration --> HasValidGUTI: 检查5G-GUTI
HasValidGUTI --> UseGUTI: 5G-GUTI有效
HasValidGUTI --> CheckSUCI: 5G-GUTI无效/过期
CheckSUCI --> UseSUCI: USIM有公钥
CheckSUCI --> UseNullSUCI: USIM无公钥
UseSUCI --> RegistrationWithECIES: ECIES加密
UseNullSUCI --> RegistrationWithNull: Null Scheme
UseGUTI --> RegistrationWithGUTI: 明文GUTI
}
RegistrationWithECIES --> AuthSuccess: 5G-AKA认证成功
RegistrationWithNull --> AuthSuccess
RegistrationWithGUTI --> AuthSuccess
RegistrationWithGUTI --> GUTIFailed: AMF找不到GUTI
GUTIFailed --> UseSUCI: Identity Request→SUCI响应
AuthSuccess --> AssignedGUTI: 获得新5G-GUTI
AssignedGUTI --> SubsequentRegistration: 后续注册
SubsequentRegistration --> HasValidGUTI
SUCI方案的一个关键安全目标是不可关联性(Unlinkability)——攻击者无法将不同时间点的SUCI关联到同一个用户。这通过以下机制保证:
| 关联维度 | 攻击场景 | SUCI防护 |
|---|---|---|
| 跨次关联 | UE两次Registration的SUCI相同? | 每次生成新的临时密钥对,SUCI必然不同 |
| 时间关联 | 固定时间间隔出现相同SUCI? | 临时密钥的随机性打破时间规律 |
| 位置关联 | 不同基站收到相同SUCI? | Ephemeral key不同,即使同一MSIN也产生不同密文 |
| 流量关联 | 某SUCI的数据流特征关联? | SUCI仅在初始注册使用,后续用GUTI |
但需注意以下关联性泄露风险: - MCC/MNC明文泄露:攻击者可知道UE的归属运营商 - Routing Indicator明文泄露:可缩小用户范围到特定路由域 - SUPI Type明文泄露:可知道标识类型(IMSI/NAI) - Null Scheme:完全无隐私保护
在5G SA核心网抓包中,识别SUCI相关的关键消息:
| 消息 | 协议层 | 关键过滤条件 | 关注字段 |
|---|---|---|---|
| Registration Request | NAS 5GS | nas_5gs.reg.message_type == 0x41 |
Mobile Identity IE |
| Identity Request | NAS 5GS | nas_5gs.reg.message_type == 0x5C |
Identity Type |
| Identity Response | NAS 5GS | nas_5gs.reg.message_type == 0x5D |
Mobile Identity (SUCI) |
| Nudm_UEAuth_Get | HTTP/2 | http2.headers.path contains "ue-authentications" |
SUCI in body |
| Registration Accept | NAS 5GS | nas_5gs.reg.message_type == 0x42 |
5G-GUTI |
Wireshark过滤示例:
# 查看所有携带SUCI的NAS Registration消息
nas_5gs.reg.message_type == 0x41 && nas_5gs.mobile_identity.type_of_identity == 1
# 查看使用Null Scheme的注册(安全风险)
nas_5gs.reg.protection_scheme_id == 0
现象:UE发送携带ECIES加密SUCI的Registration Request,但UDM/SIDF返回MAC验证失败。
排查步骤: 1. 检查USIM中预置的Home Network Public Key ID 2. 检查UDM/SIDF中对应ID的私钥是否匹配 3. 确认Protection Scheme ID一致(Profile A vs Profile B) 4. 验证公钥格式(Profile A: 32B Curve25519, Profile B: 64B secp256r1)
典型错误日志:
UDM/SIDF: SUCI deconcealment failed - MAC verification failure
Protection Scheme: Profile A (Curve25519)
Home Network PK ID: 0x03
Error: No matching private key found for PK ID 0x03
现象:AMF无法将SUCI路由到正确的UDM实例。
排查步骤: 1. 检查USIM中配置的Routing Indicator值 2. 确认AMF的路由表中该Routing Indicator对应的UDM地址 3. 注意Routing Indicator在SUCI中以BCD编码
现象:UE使用Null Scheme发送Registration,空口可见明文MSIN。
排查步骤:
1. 检查USIM是否预置了归属网公钥(EF_SUCI文件)
2. 检查USIM中的Protection Scheme ID是否为0(Null)
3. 确认运营商是否已部署SUCI保护
4. 使用AT+CSIM命令读取USIM中的公钥信息
Q1: SUCI与4G中的GUTI有什么本质区别? A: GUTI是网络分配的临时标识,用于后续注册时的标识替换,但首次注册仍需发送明文IMSI。SUCI则解决了首次注册时的永久标识保护问题——即使用户首次附着网络,SUPI也不会以明文暴露。SUCI基于公钥加密(UE主动保护),GUTI基于网络分配(网络侧保护),两者互补构成完整的隐私保护体系。
Q2: Profile A和Profile B能否在同一网络中混用? A: 可以。USIM中预置的Protection Scheme ID决定UE使用哪种Profile。运营商可以为不同批次USIM配置不同Profile。UDM/SIDF必须同时支持两种Profile,根据SUCI中的Scheme ID字段选择对应的解密算法。但同一张USIM在一次Registration中只能使用一种Profile。
Q3: SUCI加密只保护MSIN,不保护MCC/MNC,这是否构成隐私泄露? A: 这是有意的设计权衡。MCC/MNC标识运营商而非用户,泄露运营商信息不会直接威胁单个用户的隐私。拜访网络的AMF需要MCC/MNC和Routing Indicator来路由Registration消息到归属网。如果加密这些字段,将无法完成路由。实际攻击中,知道"某UE属于某运营商"的价值远低于知道"某UE的具体标识"。
Q4: UE每次注册都生成新的临时密钥对,这对性能有何影响? A: Curve25519的密钥生成仅需约100微秒,对UE的注册时延影响可忽略。Profile B的secp256r1密钥生成稍慢但仍在毫秒级。真正的性能瓶颈在UDM/SIDF侧——当大量UE同时注册时,SIDF需要为每个SUCI执行ECDH计算。运营商通常通过SIDF实例化和硬件加速(HSM)来应对。
Q5: 如果攻击者获得了归属网的私钥,能否解密所有历史SUCI? A: 不能完全解密。每个SUCI使用不同的临时密钥对(ephemeral key pair),即使攻击者获得私钥,也需要同时拥有UE当时生成的临时私钥才能计算共享密钥。而临时私钥在生成SUCI后即被销毁(UE不会存储)。这提供了类似前向安全性的保护——但严格来说,如果攻击者记录了所有SUCI,获得私钥后可以尝试离线暴力破解MAC Key验证来关联用户(虽然计算量极大)。
本文由「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 等场景全覆盖。
