在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-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握手流程定义在TS 29.573 Section 5.2.2和TS 33.501 Section 13.2.2中。整个握手分为TLS层认证和应用层参数交换两个阶段。
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通道就绪
| IE名称 | 类型 | 说明 |
|---|---|---|
3gpp-Sbi-Sender-Plmn |
PlmnId | 发起方PLMN标识(MCC+MNC) |
supportedSecCapabilities |
array | 支持的安全能力列表 |
n32Policies |
N32PolicyList | 加密策略和修改策略 |
vSEPP FQDN |
string | 发起方SEPP的全限定域名 |
targetPlmn |
PlmnId | 目标PLMN标识 |
| IE名称 | 类型 | 说明 |
|---|---|---|
selectedSecCapability |
string | 选定的安全能力(如"PRINS") |
n32Policies |
N32PolicyList | 确认的加密和修改策略 |
securityContextId |
string | 新建立的安全上下文ID |
hSEPP FQDN |
string | 响应方SEPP的全限定域名 |
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(Protocol for N32 Interconnect Security)是3GPP在TS 33.501 Annex中定义的应用层安全协议。它的核心设计理念是选择性保护(Selective Protection)——只加密需要保护的敏感字段,保持消息结构可被中间节点路由。
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)
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"
}
}
_encryptedDataArray加密机制_encryptedDataArray是PRINS协议的核心数据结构,定义在TS 33.501 Section 13.2.3。它的工作原理:
_encryptedDataArraygraph 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
除了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校验将失败。
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漫游 | 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中间节点可以执行路由功能(读取非敏感头部),但完全无法获取用户隐私数据。
在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
| 故障现象 | 可能原因 | 排查思路 |
|---|---|---|
| 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部署提出以下关键要求:
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最重要的架构优势。
本文由「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 等场景全覆盖。
