# 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能解密敏感内容。 ```mermaid 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
Security Context
Establishment| hSEPP vSEPP --> IPX1 IPX2 --> hSEPP IPX1 -.->|N32-f
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安全上下文，每个上下文包含： - **Security Context ID**：唯一标识一个安全上下文 - **N32-Forwarding-Key**：用于派生加密和完整性保护密钥 - **加密算法**：协商确定的加密算法（如A256GCM） - **数据类型加密策略**：哪些JSON字段需要加密 - **修改策略**：哪些HTTP头需要被保护 ## 三、N32-c握手建立安全上下文 N32-c握手流程定义在TS 29.573 Section 5.2.2和TS 33.501 Section 13.2.2中。整个握手分为TLS层认证和应用层参数交换两个阶段。 ### 3.1 完整握手时序图 ```mermaid 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
SecurityPolicyRequest
{3gpp-Sbi-Sender-Plmn, supportedSecCapabilities,
n32Policies, vSEPP FQDN} hSEPP->>vSEPP: ExchangeApplicationData RESPONSE
SecurityPolicyResponse
{selectedSecCapability,
n32Policies, hSEPP FQDN,
SecurityContext ID} Note over vSEPP,hSEPP: Phase 3: Key Derivation (Local) Note right of vSEPP: KDF(TLS-Exporter Secret,
N32-Context-Info) →
N32-Forwarding-Key Note right of hSEPP: KDF(TLS-Exporter Secret,
N32-Context-Info) →
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消息保护流程 ```mermaid sequenceDiagram participant NF_A as VPLMN NF
(e.g. AMF) participant vSEPP as vSEPP participant IPX as IPX Provider participant hSEPP as hSEPP participant NF_B as HPLMN NF
(e.g. UDM) NF_A->>vSEPP: HTTP/2 Request
原始JSON (含SUPI等敏感字段) Note over vSEPP: Step 1: 头部替换
保存原始Target-apiRoot
替换为hSEPP地址 Note over vSEPP: Step 2: 选择性加密
按Data-type加密策略
将敏感字段移入_encryptedDataArray Note over vSEPP: Step 3: 完整性保护
对整个修改后的消息体
计算IntegrityProtection MAC vSEPP->>IPX: N32-f Protected Request
{modified headers,
_encryptedDataArray,
integrityProtection} Note over IPX: IPX仅能读取非加密头
用于路由转发
无法读取敏感内容 IPX->>hSEPP: N32-f Protected Request Note over hSEPP: Step 4: 完整性验证
使用N32-Integrity-Key
验证MAC Note over hSEPP: Step 5: 解密敏感字段
使用N32-Encryption-Key
解密_encryptedDataArray Note over hSEPP: Step 6: 头部还原
恢复原始Target-apiRoot
指向目的NF hSEPP->>NF_B: HTTP/2 Request
还原后的完整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的请求）**： ```json { "supi": "imsi-460001234567890", "plmnId": {"mcc": "460", "mnc": "00"}, "ueId": "imsi-460001234567890", "supportedFeatures": "ffffff", "accessType": "3GPP_ACCESS" } ``` **保护后的消息（vSEPP发出经过N32-f处理）**： ```json { "_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` ```mermaid 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:
JWE(supi+ueId)"]:::encrypted C2["plmnId: {mcc:460}"] C3["accessType: 3GPP"] C4["integrityProtection:
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安全上下文状态管理 ```mermaid stateDiagram-v2 [*] --> Init: SEPP启动 Init --> TLS_Establishing: 发起/接收N32-c连接 TLS_Establishing --> ParamNegotiating: mTLS认证成功 TLS_Establishing --> Failed: TLS握手失败 ParamNegotiating --> Active: 安全参数协商成功
密钥派生完成 ParamNegotiating --> Failed: 策略不兼容 Active --> Active: N32-f消息收发
(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](https://www.etsi.org/deliver/etsi_ts/133500_133599/133501/18.10.00_60/ts_133501v181000p.pdf) — Section 13.2: Application layer security on the N32 interface, Annex: PRINS encoding rules 2. [3GPP TS 29.573](https://itecspec.com/3gpp/29.573/s/5) — Section 5: N32 Procedures (N32-c handshake and N32-f protect/unprotect) 3. [GSMA NG.113 5GS Roaming Guidelines](https://www.gsma.com/newsroom/wp-content/uploads//NG.113.v.11.0-14.pdf) — SEPP deployment, N32-f policing, PKI requirements 4. [P1 Security - SEPP Security in 5G Roaming](https://www.p1sec.com/blog/sepp-security-in-5g-roaming-how-the-security-edge-protection-proxy-protects-inter-operator-trust) — 威胁分析与最佳实践 5. [IEEE - Performance Evaluation of 5G Roaming Security Based on PRINS](https://ieeexplore.ieee.org/document/11195047) — 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 等场景全覆盖。