首页 › security › 5G SEPP N32跨域安全与PRINS加密保护拆解

5G SEPP N32跨域安全互通与PRINS加密保护信令拆解

一、引言:为什么5G漫游需要SEPP

在4G时代,Diameter漫游安全依赖IPsec和GRX/IPX传输层保护,但这种方式存在根本性缺陷——中间传输节点(IPX Provider)可以窥探甚至篡改全部信令内容。5GC全面转向Service-Based Interface(SBI)架构后,所有NF间通信基于HTTP/2 + JSON,这为应用层安全提供了全新可能。

SEPP(Security Edge Protection Proxy)正是3GPP SA3工作组为5G漫游安全设计的核心网元,定义于TS 33.501 Section 13.2和TS 29.573。它并非简单的TLS网关,而是一个应用层安全代理——在保持JSON信令可路由的前提下,对敏感字段进行端到端加密和完整性保护,即使信令经过多个IPX中间节点,也只有目的端SEPP能解密敏感内容。

graph TB
    subgraph VPLMN["Visited PLMN (VPLMN)"]
        V_AMF[AMF]
        V_SMF[SMF]
        vSEPP[vSEPP]
        V_AMF -->|SBI| vSEPP
        V_SMF -->|SBI| vSEPP
    end

    subgraph IPX["IPX Transit Network"]
        IPX1[IPX Provider 1]
        IPX2[IPX Provider 2]
        IPX1 -.->|TLS hop-by-hop| IPX2
    end

    subgraph HPLMN["Home PLMN (HPLMN)"]
        H_UDM[UDM]
        H_AUSF[AUSF]
        hSEPP[hSEPP]
        hSEPP -->|SBI| H_UDM
        hSEPP -->|SBI| H_AUSF
    end

    vSEPP <==>|N32-c<br/>Security Context<br/>Establishment| hSEPP
    vSEPP --> IPX1
    IPX2 --> hSEPP
    IPX1 -.->|N32-f<br/>Protected Messages| IPX2

    style vSEPP fill:#e74c3c,color:#fff
    style hSEPP fill:#2980b9,color:#fff
    style IPX1 fill:#95a5a6,color:#fff
    style IPX2 fill:#95a5a6,color:#fff

二、N32接口架构:控制面与转发面分离

N32接口分为两个逻辑子接口,各自承载不同功能:

子接口 功能 协议承载 定义章节
N32-c 安全上下文协商、密钥建立、能力交换 TLS + HTTP/2 TS 29.573 Section 5.2
N32-f 受保护信令消息的转发 TLS + HTTP/2 + PRINS TS 29.573 Section 5.3

设计意图:控制面与转发面分离使得N32-c安全上下文只需建立一次,后续大量N32-f消息可复用该上下文进行加解密。这避免了每条消息都重复握手,同时隔离了密钥管理逻辑与业务转发逻辑。

N32-c连接建立在两个SEPP之间,通常使用mTLS(Mutual TLS)进行双向认证。每对漫游伙伴之间维护一个或多个N32-c安全上下文,每个上下文包含:

三、N32-c握手建立安全上下文

N32-c握手流程定义在TS 29.573 Section 5.2.2和TS 33.501 Section 13.2.2中。整个握手分为TLS层认证和应用层参数交换两个阶段。

3.1 完整握手时序图

sequenceDiagram
    participant vSEPP as vSEPP (VPLMN)
    participant hSEPP as hSEPP (HPLMN)

    Note over vSEPP,hSEPP: Phase 1: TLS Mutual Authentication
    vSEPP->>hSEPP: TLS ClientHello (SNI: hSEPP FQDN)
    hSEPP->>vSEPP: TLS ServerHello + Certificate
    vSEPP->>hSEPP: TLS Certificate + CertificateVerify
    hSEPP->>vSEPP: TLS Finished
    Note over vSEPP,hSEPP: mTLS隧道建立完成

    Note over vSEPP,hSEPP: Phase 2: Application Layer - N32-c Parameter Exchange
    vSEPP->>hSEPP: ExchangeApplicationData REQUEST<br/>SecurityPolicyRequest<br/>{3gpp-Sbi-Sender-Plmn, supportedSecCapabilities,<br/>n32Policies, vSEPP FQDN}

    hSEPP->>vSEPP: ExchangeApplicationData RESPONSE<br/>SecurityPolicyResponse<br/>{selectedSecCapability,<br/>n32Policies, hSEPP FQDN,<br/>SecurityContext ID}

    Note over vSEPP,hSEPP: Phase 3: Key Derivation (Local)
    Note right of vSEPP: KDF(TLS-Exporter Secret,<br/>N32-Context-Info) →<br/>N32-Forwarding-Key
    Note right of hSEPP: KDF(TLS-Exporter Secret,<br/>N32-Context-Info) →<br/>N32-Forwarding-Key

    Note over vSEPP,hSEPP: 安全上下文建立完成,N32-f通道就绪

3.2 关键Information Element解析

SecurityPolicyRequest消息体

IE名称 类型 说明
3gpp-Sbi-Sender-Plmn PlmnId 发起方PLMN标识(MCC+MNC)
supportedSecCapabilities array 支持的安全能力列表
n32Policies N32PolicyList 加密策略和修改策略
vSEPP FQDN string 发起方SEPP的全限定域名
targetPlmn PlmnId 目标PLMN标识

SecurityPolicyResponse消息体

IE名称 类型 说明
selectedSecCapability string 选定的安全能力(如"PRINS")
n32Policies N32PolicyList 确认的加密和修改策略
securityContextId string 新建立的安全上下文ID
hSEPP FQDN string 响应方SEPP的全限定域名

3.3 密钥推演过程

N32-c握手完成后,双方使用TLS Exporter机制(RFC 5705)从TLS会话中导出共享密钥材料:

N32-Forwarding-Key = KDF(
    TLS-Exporter-Secret,
    "N32 Forwarding Key",
    N32-Context-Info,
    key_length
)

其中N32-Context-Info包含双方SEPP的FQDN、PLMN ID和安全上下文ID等绑定信息。然后从N32-Forwarding-Key进一步派生:

派生密钥 用途
N32-Encryption-Key JSON敏感字段加密(AES-256-GCM)
N32-Integrity-Key 整体消息完整性保护(HMAC-SHA-256)

四、PRINS协议:N32-f消息保护机制

PRINS(Protocol for N32 Interconnect Security)是3GPP在TS 33.501 Annex中定义的应用层安全协议。它的核心设计理念是选择性保护(Selective Protection)——只加密需要保护的敏感字段,保持消息结构可被中间节点路由。

4.1 N32-f消息保护流程

sequenceDiagram
    participant NF_A as VPLMN NF<br/>(e.g. AMF)
    participant vSEPP as vSEPP
    participant IPX as IPX Provider
    participant hSEPP as hSEPP
    participant NF_B as HPLMN NF<br/>(e.g. UDM)

    NF_A->>vSEPP: HTTP/2 Request<br/>原始JSON (含SUPI等敏感字段)

    Note over vSEPP: Step 1: 头部替换<br/>保存原始Target-apiRoot<br/>替换为hSEPP地址
    Note over vSEPP: Step 2: 选择性加密<br/>按Data-type加密策略<br/>将敏感字段移入_encryptedDataArray
    Note over vSEPP: Step 3: 完整性保护<br/>对整个修改后的消息体<br/>计算IntegrityProtection MAC

    vSEPP->>IPX: N32-f Protected Request<br/>{modified headers,<br/>_encryptedDataArray,<br/>integrityProtection}
    Note over IPX: IPX仅能读取非加密头<br/>用于路由转发<br/>无法读取敏感内容

    IPX->>hSEPP: N32-f Protected Request

    Note over hSEPP: Step 4: 完整性验证<br/>使用N32-Integrity-Key<br/>验证MAC
    Note over hSEPP: Step 5: 解密敏感字段<br/>使用N32-Encryption-Key<br/>解密_encryptedDataArray
    Note over hSEPP: Step 6: 头部还原<br/>恢复原始Target-apiRoot<br/>指向目的NF

    hSEPP->>NF_B: HTTP/2 Request<br/>还原后的完整JSON
    NF_B->>hSEPP: HTTP/2 Response
    hSEPP->>vSEPP: N32-f Protected Response
    vSEPP->>NF_A: HTTP/2 Response (unprotected)

4.2 JSON体保护结构详解

SEPP对JSON消息体的保护不是整体加密,而是字段级别的选择性保护。以下是原始消息与保护后消息的结构对比:

原始消息(vSEPP收到的来自AMF的请求):

{
  "supi": "imsi-460001234567890",
  "plmnId": {"mcc": "460", "mnc": "00"},
  "ueId": "imsi-460001234567890",
  "supportedFeatures": "ffffff",
  "accessType": "3GPP_ACCESS"
}

保护后的消息(vSEPP发出经过N32-f处理):

{
  "_encryptedDataArray": [
    "eyJhbGciOiJkaXIiLCJlbmMiOiJBMjU2R0NNIn0..base64IV.base64Ciphertext.base64Tag"
  ],
  "plmnId": {"mcc": "460", "mnc": "00"},
  "supportedFeatures": "ffffff",
  "accessType": "3GPP_ACCESS",
  "integrityProtection": {
    "securityContextId": "ctx-2026-001",
    "macValue": "base64EncodedMAC"
  }
}

4.3 _encryptedDataArray加密机制

_encryptedDataArray是PRINS协议的核心数据结构,定义在TS 33.501 Section 13.2.3。它的工作原理:

  1. 字段分类:根据N32-c协商的Data-type加密策略,将JSON字段分为敏感(需加密)和非敏感(保持明文)两类
  2. 敏感字段打包:将所有敏感字段及其原始路径信息打包成一个JSON对象
  3. JWE加密:使用JWE Compact Serialization对该JSON对象进行加密 - Key Management:使用N32-Encryption-Key作为对称密钥 - Content Encryption:使用AES-256-GCM(A256GCM)算法
  4. 嵌入消息:将JWE加密结果作为数组元素嵌入_encryptedDataArray
graph LR
    subgraph Original["原始JSON消息"]
        A1["supi: imsi-460..."]
        A2["plmnId: {mcc:460}"]
        A3["ueId: imsi-460..."]
        A4["accessType: 3GPP"]
    end

    subgraph Classification["字段分类"]
        B1["敏感字段"]:::sensitive
        B2["非敏感字段"]:::nonsensitive
    end

    subgraph Protected["保护后消息"]
        C1["_encryptedDataArray:<br/>JWE(supi+ueId)"]:::encrypted
        C2["plmnId: {mcc:460}"]
        C3["accessType: 3GPP"]
        C4["integrityProtection:<br/>MAC(whole body)"]:::mac
    end

    A1 --> B1
    A3 --> B1
    A2 --> B2
    A4 --> B2
    B1 --> C1
    B2 --> C2
    B2 --> C3
    B1 -.->|完整性覆盖全部| C4
    B2 -.->|完整性覆盖全部| C4

    classDef sensitive fill:#e74c3c,color:#fff
    classDef nonsensitive fill:#27ae60,color:#fff
    classDef encrypted fill:#8e44ad,color:#fff
    classDef mac fill:#f39c12,color:#fff

4.4 HTTP头部修改保护

除了JSON体,SEPP还需要修改HTTP头部以实现路由。这些修改同样需要保护,防止中间节点篡改。TS 29.573 Section 5.2.3.3定义了修改保护机制:

原始头部 SEPP修改 保护方式
3gpp-Sbi-Target-apiRoot(指向目标NF) 替换为目标SEPP地址 记录在modifications中,MAC覆盖
3gpp-Sbi-Target-Nf-Id 保留但在MAC中记录 完整性保护
3gpp-Sbi-Target-Plmn 可能被移除或保留 完整性保护
Authorization 可能被添加/修改 完整性保护

接收端SEPP在解密后,会验证头部修改是否与MAC中记录的一致。如果中间节点擅自篡改了路由头部,MAC校验将失败。

五、N32-f安全上下文状态管理

stateDiagram-v2
    [*] --> Init: SEPP启动
    Init --> TLS_Establishing: 发起/接收N32-c连接
    TLS_Establishing --> ParamNegotiating: mTLS认证成功
    TLS_Establishing --> Failed: TLS握手失败
    ParamNegotiating --> Active: 安全参数协商成功<br/>密钥派生完成
    ParamNegotiating --> Failed: 策略不兼容
    Active --> Active: N32-f消息收发<br/>(protect/unprotect)
    Active --> KeyRekeying: 密钥有效期将至
    KeyRekeying --> Active: 密钥更新成功
    KeyRekeying --> Terminating: 更新失败
    Active --> Terminating: 连接关闭/错误
    Failed --> [*]
    Terminating --> [*]

安全上下文参数表

参数 说明 典型值
Security Context ID 唯一标识一个N32安全上下文 UUID格式
N32-Encryption-Key JSON体加密密钥 256-bit
N32-Integrity-Key 消息完整性保护密钥 256-bit
加密算法 对称加密算法 A256GCM
密钥有效期 密钥使用时间限制 运营商策略定义
Data-type加密策略 字段级加密规则 按数据类型分类
修改策略 HTTP头修改保护规则 按SBI API分类

六、与4G Diameter漫游安全的对比

维度 4G Diameter漫游 5G SEPP N32漫游
传输层安全 IPsec (隧道模式) mTLS 1.3
应用层安全 无(依赖IPsec端到端) PRINS选择性加密
中间节点可见性 IPX可看到全部内容 IPX仅看到路由信息和非敏感字段
保护粒度 整个IP包 JSON字段级别
信任模型 信任IPX传输链路 零信任——仅信任端点SEPP
密钥管理 IKEv2协商 TLS Exporter + KDF
多IPX场景 每跳需重新建立IPsec SA 端到端保护贯穿多IPX
头部保护 不适用(IP头修改无保护) 头部修改纳入MAC完整性保护
算法灵活性 IPsec算法套件 JWE支持的任意算法

核心差异:4G的IPsec是"管道式"保护——要么全加密要么不保护。5G PRINS的"选择性保护"是革命性的进步,它使得IPX中间节点可以执行路由功能(读取非敏感头部),但完全无法获取用户隐私数据。

七、实战:抓包识别与故障排查

7.1 Wireshark抓包识别SEPP流量

在SEPP网元上抓包时,可通过以下特征识别N32-c和N32-f流量:

N32-c流量特征: - TLS握手:SNI中包含对端SEPP的FQDN - HTTP/2 POST路径:/n32c-handshake/v1/exchange-application-data - Content-Type:application/json

N32-f流量特征: - HTTP/2 POST路径:与具体SBI API相关(如/nudm-sdm/v1/{ueId}/...) - JSON体中包含_encryptedDataArray字段 - JSON体中包含integrityProtection字段 - 3gpp-Sbi-Target-apiRoot头部指向SEPP而非目标NF

7.2 常见故障点

故障现象 可能原因 排查思路
N32-c握手TLS失败 证书链不完整/过期/未信任 检查双方SEPP证书、中间CA、CRL/OCSP状态
安全参数协商失败 双方加密策略不兼容 对比双方n32Policies,确认有交集
N32-f消息解密失败 密钥不匹配/上下文过期 检查Security Context ID是否一致
MAC校验失败 中间节点修改了HTTP头或JSON体 对比发送端和接收端的消息差异
_encryptedDataArray解不开 加密算法或密钥版本不一致 检查KDF参数和N32-Encryption-Key
路由失败 头部修改后路由信息丢失 检查modifications记录和原始apiRoot
跨厂商互通失败 JSON字段映射差异 检查Data-type加密策略的字段分类
## 八、GSMA NG.113部署指导要点

GSMA NG.113(5GS Roaming Guidelines)对SEPP部署提出以下关键要求:

  1. PKI基础设施:运营商必须通过GSMA SAS-SM(Security Accreditation Scheme - Subscription Management)认证的CA获取SEPP证书
  2. 证书格式:采用X.509 v3证书,包含SEPP FQDN和PLMN ID扩展
  3. TLS版本:必须使用TLS 1.2及以上,推荐TLS 1.3
  4. 密码套件:优先使用ECDHE密钥交换的套件,确保前向安全
  5. N32-f流量策略:必须实现anti-spoofing检查,防止非法源地址注入

常见问题

Q1: SEPP和传统IPsec网关(如4G的Security Gateway)的本质区别是什么?

A: 本质区别在于安全层级和信任模型。4G IPsec网关在网络层(L3)建立隧道,所有Diameter消息在隧道内完全明文传输——任何中间IPX节点(如IPsec隧道终结点)都能看到完整信令内容。SEPP在应用层(L7)工作,采用PRINS选择性加密,只加密敏感字段,即使经过多个不可信IPX节点,敏感内容也受端到端保护。此外,SEPP还能对HTTP头部的修改进行完整性保护,防止路由劫持。

Q2: _encryptedDataArray和_encryptedMap有什么区别?

A: 根据TS 33.501 Section 13.2.3,_encryptedDataArray用于当多个独立JSON字段需要加密时,将它们分别加密后以数组形式存储;而_encryptedMap(在某些版本中使用)用于将键值对形式的敏感数据加密后保持映射关系。实际部署中主要使用_encryptedDataArray,因为它更灵活,支持对不同路径的字段独立加密。

Q3: 如果两个运营商的N32加密策略不兼容怎么办?

A: N32-c握手阶段会进行策略协商。如果SecurityPolicyRequest中的supportedSecCapabilities和n32Policies与接收方不兼容,hSEPP会返回错误响应。解决方案是在漫游协议(Roaming Agreement)中预先约定统一的策略,或参考GSMA NG.113中的默认策略集。实际部署中,运营商通常使用GSMA推荐的基线策略作为最小公约数。

Q4: SEPP能否保护gRPC接口的漫游信令?

A: Rel-17及之前版本,SEPP主要保护基于HTTP/2 JSON的SBI接口。Rel-18引入了对gRPC SBI的支持,SEPP通过相同的PRINS机制保护gRPC消息体中的敏感字段,但具体的序列化格式(Protobuf vs JSON)会影响_encryptedDataArray的实现细节。

Q5: 多IPX hubbing场景下SEPP如何工作?

A: 在hubbing漫游场景中,信令可能经过两个以上IPX Provider。SEPP的端到端PRINS保护在此场景下依然有效——每个IPX节点只能看到TLS加密的传输隧道和N32-f消息中的非敏感路由信息。_encryptedDataArray中的加密内容和integrityProtection中的MAC值始终是端到端保护的,中间IPX无法解密或篡改。这是PRINS相比4G IPsec最重要的架构优势。

参考来源

  1. 3GPP TS 33.501 V18.10.0 — Section 13.2: Application layer security on the N32 interface, Annex: PRINS encoding rules
  2. 3GPP TS 29.573 — Section 5: N32 Procedures (N32-c handshake and N32-f protect/unprotect)
  3. GSMA NG.113 5GS Roaming Guidelines — SEPP deployment, N32-f policing, PKI requirements
  4. P1 Security - SEPP Security in 5G Roaming — 威胁分析与最佳实践
  5. IEEE - Performance Evaluation of 5G Roaming Security Based on PRINS — PRINS协议性能评估

本文由「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学通信知识星球海报-扫码加入