首页 › security › 5G SEPP N32端到端互联安全拆解

5G SEPP N32端到端互联安全拆解：从安全协商到逐字段加密的全链路分析

一、为什么5G漫游必须引入SEPP

4G/EPC时代，运营商间漫游信令基于Diameter协议，边界由Diameter Edge Agent（DEA）+ IPSec隧道保护，属于逐跳（hop-by-hop）安全模型。进入5GC后，控制面全面转向SBI（Service-Based Interface，HTTP/2 + JSON + OpenAPI），这带来一个根本性矛盾：

如果只用TLS，TLS会在IPX处逐跳终止，IPX即可明文看到全部JSON——这违背漫游数据不出本网的合规要求（GDPR、GSMA IR.88）。如果用IPsec隧道做端到端，IPX又无法读取路由头，路由彻底瘫痪。

SEPP（Security Edge Protection Proxy，安全边缘保护代理） 正是为此诞生（TS 33.501 Section 6.2）：它是每个运营商5GC通往外部网络的唯一信令出入口，采用应用层、字段级（per-IE）的端到端保护——路由头明文留给IPX，敏感字段用JOSE加密签名端到端护送到对端SEPP。这一设计是5G安全架构（TS 33.501）相对4G最具突破性的创新之一。

二、N32接口的双面结构：N32-c与N32-f

N32参考点连接拜访地vSEPP与归属地hSEPP，逻辑上一分为二：

flowchart TD
    subgraph VPLMN["拜访地 PLMN"]
        NF1["源 NF<br/例: vAMF"]
        VSEPP["vSEPP"]
        NF1 -.HTTP/2.- VSEPP
    end
    subgraph IPX["IPX 转接域"]
        IPX1["IPX Provider"]
    end
    subgraph HPLMN["归属地 PLMN"]
        HSEPP["hSEPP"]
        NF2["目标 NF<br/例: hUDM"]
        HSEPP -.HTTP/2.- NF2
    end
    VSEPP == "N32-c (控制面)<br/>TLS + 安全策略协商" ==> HSEPP
    VSEPP == "N32-f (转发面)<br/>TLS + JOSE(JWE/JWS)" ==> IPX1
    IPX1 == "路由头明文/载荷密文" ==> HSEPP
子接口 全称 传输安全 应用层保护 职责
N32-c N32-control 双向认证TLS（必选） 无（仅协商） 协商加密/签名策略、建立并维护N32-f安全上下文
N32-f N32-forwarding TLS（逐跳到IPX） JOSE：JWE加密+JWS签名 转发真实NF-NF SBI消息，实施字段级保护

设计意图：将"低频重、重量级"的协商与"高频、轻量级"的转发解耦。N32-c协商一次可服务海量N32-f转发，避免每条消息重复TLS握手与策略拉取。

三、N32-c安全协商全流程

N32-c基于n32c-handshake服务（TS 29.500），核心是交换双方的数据类型加密清单（Data Type Ciphering List）与数据类型签名清单（Data Type Signing List），取交集作为本次漫游链路的保护策略。

sequenceDiagram
    autonumber
    participant V as vSEPP (VPLMN)
    participant H as hSEPP (HPLMN)
    Note over V,H: 阶段0: DNS解析hSEPP FQDN + 证书预置
    V->>H: TCP/TLS握手 (双向mTLS, SNI=hSEPP FQDN)
    H-->>V: TLS Established
    V->>H: POST /n32c-handshake/v1/n32c-id<br/>SecNegotiateEstablish<br/>(plmnIdList, supportedFeatures,<br/> supportedDataTypeCiphering,<br/> supportedDataTypeSigning, seppFQDN)
    H->>H: 校验PLMN-ID合法性 (TS 33.517)<br/>取交集 = 选定保护清单
    H-->>V: 201 SecNegotiateEstablishResponse<br/>(selectedDataTypeCiphering,<br/> selectedDataTypeSigning,<br/> n32fContextId, selectedFeatures)
    Note over V,H: N32-f 安全上下文 ESTABLISHED
    loop 漫游生命周期内
        V->>H: PUT /n32c-handshake/v1/n32c-id (上下文保活/更新)
    end
    V->>H: DELETE n32c-id (上下文释放)
    Note over V,H: N32-f 安全上下文 RELEASED

N32-c协商关键IE说明

IE字段 含义 抓包识别要点
plmnIdList 本端允许对接的PLMN MCC-MNC列表 TS 33.517强制SEPP校验，不匹配即拒绝
supportedDataTypeCiphering 本端支持加密的IE类型集合 如 Supi、AuthenticationSubscription、Gpsi
supportedDataTypeSigning 本端支持完整性签名的IE类型 如路由头、整消息体
seppFQDN SEPP全限定域名 与TLS证书CN/SAN必须一致
n32fContextId 协商成功后分配的上下文ID 后续N32-f消息据此查找密钥材料
selectedFeatures 特性位图（如PRINS、版本协商） 决定是否启用扩展保护特性

四、N32-f字段级转发与JOSE保护

n32f-forward服务（TS 29.500）承载真实NF消息。以漫游注册中vAMF向hUDM请求签约数据（Nudm_SDM_Get）为例：

sequenceDiagram
    autonumber
    participant UE
    participant AMF as vAMF (VPLMN)
    participant VS as vSEPP
    participant IPX
    participant HS as hSEPP
    participant UDM as hUDM (HPLMN)
    UE->>AMF: Registration Request (漫游)
    AMF->>VS: HTTP/2 GET /nudm-sdm/v2/{suPI}/am-data<br/>(明文: SUPI=460..., RoutingInfo, ApiRoot)
    VS->>VS: 加密策略查找 CPL<br/>SUPI ∈ CipheringList → JWE<br/>路由头 ∈ SigningList → JWS
    VS->>IPX: POST /n32f-forward/v1/forwarding-path<br/>3gpp-Sbi-RoutingInfo(明文)<br/>3gpp-Sbi-Target-ApiRoot(明文)<br/>Body: { JWE(SUPI), JWS(签名) }
    Note over IPX: IPX仅看路由头可转发<br/>无法解密JWE载荷
    IPX->>HS: 转发同一消息
    HS->>HS: 验JWS完整性<br/>解JWE恢复SUPI<br/>PLMN-ID二次校验
    HS->>UDM: HTTP/2 GET (明文还原)
    UDM-->>HS: 200 OK (签约数据,含位置/签约)
    HS->>HS: 对响应敏感字段再次JWE/JWS
    HS->>IPX: POST /n32f-forward (响应, 受保护)
    IPX->>VS: 转发
    VS->>VS: 解密验签 → 还原
    VS-->>AMF: 200 OK (明文)

消息拆解：哪些字段加密、哪些签名、哪些明文

vSEPP收到NF请求后，执行加密策略查找（Ciphering Policy Lookup, CPL），把JSON消息体分解为三类区域：

flowchart TB
    MSG["原始 SBI HTTP/2 消息<br/>{SUPI, 路由头, 签约指针, GPSI, API名}"]
    MSG --> CLEAR["① 明文区 (留给IPX路由)<br/>3gpp-Sbi-RoutingInfo / FQDN<br/>3gpp-Sbi-Target-ApiRoot<br/>Request-URI / API name"]
    MSG --> JWE["② JWE加密区 (机密性)<br/>SUPI<br/>AuthenticationSubscription/Vector<br/>Gpsi, 位置信息, 签约QoS"]
    MSG --> JWS["③ JWS签名区 (完整性)<br/>路由头摘要<br/>整消息体指纹<br/>防止IPX篡改"]
    CLEAR --> IPX2["IPX可读"]
    JWE --> IPX2
    JWS --> IPX2
    IPX2 --> RESTORE["对端hSEPP验签+解密<br/>还原原始消息"]
保护类型 JOSE技术 保护的IE示例 设计目的
机密性 JWE（RFC 7516） SUPI、鉴权向量、GPSI、签约数据 即使IPX抓包也无法读取用户隐私
完整性/真实性 JWS（RFC 7515） 路由头、消息体、自定义头 防止中间IPX篡改或注入
不保护（明文） 无 FQDN、API名、Request-URI 满足IPX基于NRF的路由需求

JWE密文以eyJ（base64url编码的JSON头{"alg":...,"enc":...}）开头，是抓包识别SEPP保护载荷的最显著指纹。加密算法由JWA（RFC 7518）规定，5G SEPP常用 A128KW/A256KW（密钥包装）+ A128GCM/A256GCM（内容加密）。

五、两种N32安全Profile

TS 33.501定义了两种可对接的N32安全轮廓，运营商需协商一致：

stateDiagram-v2
    [*] --> 初始
    初始 --> 协商中: vSEPP发起N32-c
    协商中 --> ProfileA: 选定IPsec模式
    协商中 --> ProfileB: 选定JOSE模式
    ProfileA --> ESTABLISHED: IKEv2/IPsec隧道就绪
    ProfileB --> ESTABLISHED: N32-f上下文就绪
    ESTABLISHED --> 转发中: N32-f消息收发
    转发中 --> ESTABLISHED: 保活
    ESTABLISHED --> 过期: TTL超时
    ESTABLISHED --> 释放: 显式DELETE
    过期 --> [*]
    释放 --> [*]
维度 Profile A（IPsec模式） Profile B（JOSE应用层模式）
传输层 IKEv2/IPsec隧道（SEPP间） TLS（逐跳到IPX）
端到端保护 IPsec隧道模式（可选叠加JOSE） 强制JOSE（JWE+JWS）
IPX可见性 仅见加密IP包，无法路由细节 可见路由头，载荷密文
部署复杂度 高（需跨运营商IPsec对等） 低（主流商用首选）
适用场景 直连/专线大T互联 经IPX的多跳漫游（绝大多数场景）

实际现网以Profile B为主——它完美匹配IPX商业模式：转接商能路由、却读不到内容。

六、抓包识别与故障定位

6.1 抓包识别要点

  1. N32-c：TCP（通常443/8443）→ TLS → HTTP/2 POST /n32c-handshake/v1/...，Body为JSON安全能力清单。
  2. N32-f：TLS → HTTP/2 POST /n32f-forward/v1/forwarding-path，请求头含 3gpp-Sbi-RoutingInfo、3gpp-Sbi-Target-ApiRoot，Body中出现 eyJ 开头的JWE/JWS串。
  3. 用Wireshark过滤器：http2.headers.path contains "n32" 可快速过滤SEPP流量；JWE载荷需配合SEPP私有密钥才能解密（抓包侧通常无法还原明文，这是正常安全表现）。

6.2 常见故障点

故障现象 根因 排错思路
N32-c TLS握手失败 证书过期/未互信/SAN不含FQDN 检查mTLS双向证书链、FQDN与SAN匹配
协商后立即断开 plmnIdList不匹配（TS 33.517校验失败） 核对双方白名单MCC-MNC配置
N32-f返回5xx/解密失败 加密清单交集为空、密钥材料过期 对比selectedDataTypeCiphering，刷新N32-f上下文
漫游注册卡在取签约 vSEPP未对SUPI做JWE，被hSEPP拒 检查CPL策略表是否包含Supi
响应偶发篡改告警 JWS验签失败 排查IPX是否违规改写头、时钟漂移
## 七、常见问题

Q1: SEPP和4G的DEA/IPSec边界网关本质区别是什么？ A: DEA+IPSec是逐跳保护——IPX处TLS/IPSec终止后即可看到全部明文Diameter；SEPP是应用层端到端保护，IPX全程只能看到密文载荷+明文路由头，是真正的"可路由、不可读"。

Q2: 为什么不直接对整条SBI消息加密，而要逐字段（per-IE）保护？ A: 因为IPX需要明文路由头（FQDN、API名、Request-URI）做基于NRF的转发。整条加密会让IPX无法路由；逐字段加密让"该路由的明文路由、该保密的密文保密"，是IPX商业模式与端到端安全的精确平衡。

Q3: JWE和JWS在SEPP里是二选一还是同时用？ A: 同时用、互补。JWE解决机密性（SUPI等隐私不可读），JWS解决完整性（防IPX篡改路由头/消息体）。一个IE可只加密、可只签名，也可既加密又签名，由CPL策略表逐项决定。

Q4: N32-c协商的清单是静态预置还是动态协商？ A: 两者结合。基础能力清单（支持哪些IE类型加密）在N32-c动态协商取交集；但"哪些业务消息、哪些字段必须保护"的策略规则（CPL表）通常由运营商OAM静态配置，协商只确认双方能力是否覆盖。

Q5: 抓包看到N32-f消息但Body全是eyJ乱码，正常吗？ A: 正常。eyJ是base64url编码的JOSE头起始，证明载荷已被JWE/JWS保护。只有持有对应SEPP密钥材料的对端才能解密还原，外部抓包设备无法解读，这正是SEPP的安全目标。

参考来源

  1. 3GPP TS 33.501 — Security architecture and procedures for 5G system — Section 6.2.3（SEPP架构）、Section 13（N32安全要求）
  2. 3GPP TS 29.500 — Service Based Architecture, SEPP forwarding & N32 APIs — n32c-handshake、n32f-forward、JOSE保护框架
  3. 3GPP TS 33.517 V18.0.0 — SCAS for SEPP（安全保证规范） — PLMN-ID校验、N32接口测试用例
  4. 5G Roaming with SEPP — 3g4g.co.uk 技术博客 — N32-c/N32-f流程图与实战解读
  5. 5G Roaming Security — 3GPP SA3 官方专题 — 5G漫游安全架构总览
  6. RFC 7515 (JWS) / RFC 7516 (JWE) / RFC 7518 (JWA) — JOSE签名、加密、算法规范

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

📎 本分类最新文章