首页 › security › 5G SUCI隐私保护与ECIES双Profile加密信令拆解

5G SUCI隐私保护与ECIES双Profile公钥加密方案信令拆解

一、SUPI隐私威胁与SUCI的设计动机

1.1 从IMSI Catcher到SUPI保护

在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隐藏标识。

1.2 SUCI设计的核心安全属性

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格式结构详解

2.1 SUCI的组成字段

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) 见下文

2.2 Scheme Output内部结构

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中能够唯一标识用户的那部分。

2.3 Null Scheme(保护方案0)

TS 33.501还定义了Null Scheme(Protection Scheme ID = 0),此时Scheme Output直接就是未加密的MSIN明文。这种情况发生在: - USIM未配置归属网公钥 - 紧急呼叫场景 - 某些运营商尚未部署SUCI保护

Null Scheme下的SUCI本质上等价于4G的IMSI明文传输,不具备隐私保护能力。

三、ECIES双Profile加密方案深度解析

3.1 Profile A与Profile B对比

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标准化

3.2 Profile A加密流程(Curve25519 / X25519)

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

3.3 KDF密钥推衍函数详解

两种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密钥)

3.4 Profile B加密流程(secp256r1 / ECDH)

Profile B使用NIST P-256曲线和标准ECDH密钥协商。其流程与Profile A结构完全相同,差异在于:

  1. 临时密钥对生成:在secp256r1曲线上生成,公钥为64字节(未压缩格式 04 || x || y)
  2. 密钥协商:使用标准ECDH算法(非X25519)
  3. KDF中的FC值:使用0x6C而非0x6B

3.5 为什么设计两种Profile?

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使用哪种方案。

四、Registration流程中的SUCI信令全解析

4.1 初始注册中的SUCI使用

在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)

4.2 关键信令消息中的IE分析

NAS Registration Request中的SUCI IE

根据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(无加密保护)。

4.3 SIDF解密过程的严格验证

SIDF(Subscription Identifier De-concealing Function)位于UDM中(TS 33.501 Section 6.12.5),其解密过程有严格的安全检查:

  1. 公钥ID查找:根据SUCI中的Protection Scheme ID和Home Network Public Key ID,查找对应的私钥sk_HN
  2. 共享密钥计算:使用私钥和UE的临时公钥计算共享密钥
  3. MAC验证优先于解密:先验证MAC Tag的正确性(MAC-then-decrypt模式),防止padding oracle攻击
  4. 解密MSIN:MAC验证通过后才执行AES-128-CTR解密
  5. SUPI恢复:将解密的MSIN与SUCI中明文的MCC/MNC组合,恢复完整SUPI

如果MAC验证失败,SIDF必须拒绝解密并向AMF返回错误,这是为了防止篡改攻击。

五、SUCI使用的状态转换与安全策略

5.1 UE标识使用的状态机

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

5.2 SUCI的不可关联性分析

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:完全无隐私保护

六、实战:抓包识别与排错指南

6.1 Wireshark抓包识别SUCI流程

在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

6.2 常见故障场景与排错

场景1:USIM公钥与UDM私钥不匹配

现象: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

场景2:SUCI中的Routing Indicator配置错误

现象:AMF无法将SUCI路由到正确的UDM实例。

排查步骤: 1. 检查USIM中配置的Routing Indicator值 2. 确认AMF的路由表中该Routing Indicator对应的UDM地址 3. 注意Routing Indicator在SUCI中以BCD编码

场景3:Null Scheme降级

现象: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验证来关联用户(虽然计算量极大)。

参考来源

  1. 3GPP TS 33.501 V18.10.0 — Section 6.12 SUCI计算, Annex C ECIES保护方案, Annex A KDF定义
  2. 3GPP TS 23.003 V18.3.0 — Section 2.2A SUCI格式定义
  3. 3GPP TS 24.501 V18.7.0 — Section 9.11.3.4 SUCI IE编码
  4. NIST CSWP 36A - Protecting Subscriber Identifiers with SUCI — ECIES方案详细技术分析
  5. 5G6G Academy - SUPI vs SUCI — Profile A/B方案对比与实际部署经验

本文由「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 等场景全覆盖。

51学通信知识星球海报-扫码加入