在 4G/EPC 漫游架构中，跨运营商（inter-PLMN）的控制面信令通过 Diameter 路由代理（DRA）或 IPX 提供商以明文传输。这意味着任何一个中间 IPX 节点都可以完整解析、甚至篡改 IMSI、鉴权向量、位置信息等敏感字段。这就是臭名昭著的 SS7/Diameter 攻击（位置追踪、短信拦截、欺诈）的根因——攻击者只要攻破一个 IPX 提供商，即可横向危及整个漫游生态。
3GPP 在 R15 设计 5G SBA（服务化架构）时，直面这个"中间人不可信"的现实：所有 NF 间信令都走 HTTP/2 REST，传统边界网关（如 4G 的 SCEF/DRA）已经无法提供足够保护。为此，SA3 工作组引入了 SEPP（Security Edge Protection Proxy，安全边缘保护代理），定义于 TS 33.501《5G 系统安全架构与流程》，并在 TS 29.573《PLMN 互联 Stage 3》 中给出完整的 N32 接口流程定义。
SEPP 的核心设计哲学可以用一句话概括：传输层（TLS）解决不了的问题，交给应用层（PRINS）端到端解决。 即便信令穿越多个不可信的 IPX 提供商，敏感信息元（IE）在两个 SEPP 之间始终处于加密+完整性保护之下，IPX 只能看到路由必需的最小信息。
SEPP 部署在每个 PLMN 的网络边界，是所有跨运营商 SBI 信令的唯一出入口。两个 PLMN 的 SEPP 之间通过 N32 参考点互联。N32 被巧妙地拆分为两个逻辑平面：
flowchart TD
subgraph VPLMN["拜访网络 VPLMN"]
VNF["vNF<br/>如 vAMF"]
VSEPP["vSEPP"]
VNF -.SBI/TLS.-> VSEPP
end
subgraph IPX["IPX 提供商（不可信域）"]
IPX1["IPX 节点"]
end
subgraph HPLMN["归属网络 HPLMN"]
HSEPP["hSEPP"]
HNF["hNF<br/>如 UDM/AUSF"]
HSEPP -.SBI/TLS.-> HNF
end
VSEPP ==>|"N32-c 控制面<br/>能力协商(握手)"| HSEPP
VSEPP -->|"N32-f 转发面<br/>PRINS保护业务信令"| IPX1
IPX1 -->|"N32-f 转发面"| HSEPP
classDef plane fill:#e8f4f8,stroke:#2196F3,stroke-width:2px
classDef core fill:#fff3e0,stroke:#FF9800,stroke-width:2px
class VSEPP,HSEPP plane
class VNF,HNF core
这种"先握手建隧道、再逐消息保护"的双平面分离，使协商开销被摊薄到大量后续业务消息上，兼顾了安全性与性能。
当一个 vPLMN 的 NF 首次向 hPLMN 的 NF 发起请求，且两 SEPP 间尚无有效 N32-f 上下文时，vSEPP 触发 N32-c 协商。该流程定义于 TS 29.573 §5.2.2 "Security Capability Negotiation Procedure"。
sequenceDiagram
participant vSEPP as vSEPP（发起方）
participant hSEPP as hSEPP（响应方）
Note over vSEPP,hSEPP: 阶段1：TLS 传输层双向认证（基于证书/漫游协议）
vSEPP->>hSEPP: TLS ClientHello（含 vSEPP FQDN、证书）
hSEPP->>vSEPP: TLS ServerHello + 证书 + CertificateRequest
vSEPP->>hSEPP: 客户端证书 + 密钥交换（建立 TLS 通道）
Note over vSEPP,hSEPP: 阶段2：应用层安全能力协商（N32-c）
vSEPP->>hSEPP: NegotiateSecurityCapability Request<br/>{vPLMN-id, vSEPP FQDN,<br/>支持密码套件列表(有序),<br/>FQDN→PLMN 映射}
hSEPP->>hSEPP: 校验 vPLMN-id 与证书一致性<br/>选择共同最高优先级密码套件
hSEPP->>vSEPP: NegotiateSecurityCapability Response<br/>{hPLMN-id, 选定密码套件,<br/>hSEPP FQDN, 生命周期}
Note over vSEPP,hSEPP: 双方基于 TLS 密钥材料<br/>派生 N32-f 加密密钥 Kenc 与完整性密钥 Kint
rect rgb(232,245,233)
Note over vSEPP,hSEPP: N32-f 安全上下文建立完成<br/>(Kenc, Kint, 密码套件, 有效期)
end
关键信元（IE）解析：
PRINS-128-...，涵盖加密算法（如 AES）、完整性算法、密钥派生函数。Kenc（加密密钥）、Kint（完整性密钥）、选定套件、生命周期（有效期）。该上下文被缓存，后续多条业务消息复用，直到过期或被撤销。设计意图：把"认证+密钥协商"与"数据保护"解耦，与 IPsec 的 IKE/ESP 分离思路一致。这样新增密码套件或更新密钥时，无需重传海量业务数据。
这是整个机制最精妙、也最常被误解的部分。PRINS 保护不是对整条 HTTP 消息加密，而是 SEPP 执行一个修改函数（modification function），按"数据类型"对消息内的特定 IE 做精细化处理——这正是 IPX 节点为何仍能完成路由却看不到敏感内容的关键。
TS 33.501 与各 API 规范（TS 29.5xx 系列）为每条消息的每个 IE 定义了三级保护：
| 保护类别 | 处理方式 | 典型 IE 示例 | IPX 是否可见 |
|---|---|---|---|
| 机密性保护（Ciphered） | 用 Kenc 加密为密文，整体被 JWS 完整性覆盖 |
SUPI、鉴权向量（RAND/AUTN/XRES*）、Kseaf、用户订阅数据、GPSI | ❌ 不可见（仅见密文） |
| 仅完整性保护（Integrity only） | 明文，但纳入 JWS 签名，篡改即被检出 | 部分路由标识、会话 ID | ✅ 可见但不可篡改 |
| 无保护（None） | 明文透传，仅依赖传输层 TLS | 路由必需字段、API 路径、FQDN | ✅ 可见 |
flowchart TD
A["原始 SBI 消息<br/>(vNF→vSEPP, 明文 JSON)"] --> B["IE 分类与查表<br/>按 29.5xx 数据类型映射"]
B --> C{"IE 是否需加密?"}
C -->|"是"| D["用 Kenc 加密<br/>密文封装为特殊对象<br/>(含数据类型标识)"]
C -->|"否"| E["明文保留"]
D --> F["组装受保护 JSON 主体"]
E --> F
F --> G["JWS 签名<br/>(Kint + 时间戳/序列号<br/>提供完整性+防重放)"]
G --> H["经 N32-f 转发<br/>vSEPP → IPX → hSEPP"]
H --> I["hSEPP: 验签 JWS<br/>校验时间戳窗口"]
I --> J["hSEPP: 用 Kenc 解密<br/>还原原始 IE"]
J --> K["重建原始 SBI 消息<br/>转发至 hNF"]
style D fill:#ffe0b2,stroke:#E65100
style G fill:#c8e6c9,stroke:#1B5E20
style I fill:#bbdefb,stroke:#0D47A1
关键设计点：
下面以一个典型的漫游场景——UE 在 vPLMN 注册，需向 hPLMN 的 UDM/AUSF 完成鉴权——展示 N32-c 与 N32-f 如何协同工作（综合 TS 23.502 §4.2.2 注册流程与 TS 33.501 鉴权流程）：
sequenceDiagram
participant UE
participant RAN as (v)NG-RAN
participant vAMF
participant vSEPP
participant IPX as IPX
participant hSEPP
participant AUSF as hAUSF
participant UDM as hUDM
UE->>RAN: Registration Request (含 SUCI)
RAN->>vAMF: N2 消息透传
Note over vAMF: 解析出目标 hPLMN-id<br/>需向 hUDM/hAUSF 取鉴权向量
Note over vAMF,vSEPP: N32-c 上下文不存在 → 先协商（见第三节）
vAMF->>vSEPP: Nausf_UEAuthentication 请求(明文,PLMN-内TLS)
vSEPP->>hSEPP: N32-c 协商(如尚未建立)
vSEPP->>vSEPP: 修改函数:加密 SUPI/鉴权参数, JWS签名
vSEPP->>IPX: N32-f 受保护消息(密文IE+签名)
Note over IPX: 仅见路由字段,无法读取鉴权向量
IPX->>hSEPP: 透传
hSEPP->>hSEPP: 验签JWS → 解密IE → 重建请求
hSEPP->>AUSF: Nausf_UEAuthentication(明文,PLMN-内TLS)
AUSF->>UDM: Nudm_UEAuthentication(取鉴权向量)
UDM-->>AUSF: 5G-AKA 向量(RAND/AUTN/XRES*)
AUSF-->>hSEPP: 鉴权响应
hSEPP->>hSEPP: 修改函数:加密敏感响应IE, JWS签名
hSEPP->>IPX: N32-f 受保护响应
IPX->>vSEPP: 透传
vSEPP->>vSEPP: 验签 → 解密 → 重建
vSEPP-->>vAMF: 鉴权响应(明文)
vAMF->>UE: (后续) Authentication Request / Security Mode
注意全链中敏感字段（SUPI、RAND、AUTN、XRES*、Kseaf 等）在 N32 段全程加密，而 IPX 仅承担"按路由字段转发"的职责。即便恶意 IPX 截获报文，得到的也只是无法解析的密文与一条不可伪造的签名。
| 维度 | 4G/EPC（Diameter/IPX） | 5G（SEPP + N32/PRINS） |
|---|---|---|
| 传输介质 | Diameter/SCTP 经 DRA/IPX | HTTP/2 REST 经 SEPP/IPX |
| 中间节点可见性 | 全明文，IPX 可读所有 IE | IPX 仅见路由字段，敏感 IE 加密 |
| 完整性保护 | 无（依赖传输层，跨域断裂） | 端到端 JWS 签名，覆盖整条消息 |
| 防篡改 | IPX 可静默篡改（SS7/Diameter 攻击根源） | 任意篡改即验签失败 |
| 防重放 | 弱 | JWS 时间戳+序列号校验 |
| 粒度 | 全消息或无 | 逐 IE 数据类型精细化 |
| 信任边界 | 必须信任所有 IPX 节点 | 仅需信任两端 SEPP，IPX 零信任 |
抓包识别要点：
- 在 IPX 侧抓包，N32-f 流量是 HTTP/2 over TLS（443 或运营商协商端口）。即便 TLS 解密，应用层 JSON 中敏感字段已被替换为密文对象（典型结构含 "ciphered" 标识或 Base64URL 密文 + 数据类型标识）。
- 寻找 JWS 头部（JOSE Header）：可见 alg、kid 字段；载荷（payload）为受保护结构。
- 在 SEPP 内部接口（NF↔SEPP，PLMN 内）抓包则可见明文 SBI，是验证 SEPP 改造正确性的最佳观测点。
常见故障点与排错：
1. N32-c 协商失败：最常见。检查证书链是否互通、FQDN↔PLMN-id 映射是否正确、双方密码套件列表无交集（TS 29.573 要求取共同最高优先级，无交集则协商失败，业务信令无法跨域）。表现为 vNF 收到 SEPP 返回的 5xx，需查 SEPP 日志中的协商失败原因码。
2. 证书过期/吊销：导致 TLS 握手在 N32-c 第一阶段即失败，需关注证书生命周期管理。
3. JWS 验签失败：通常是密钥不同步（一侧上下文已刷新、另一侧未更新）或时间戳越窗（两 SEPP 时钟漂移过大）。排错时核对 Kint 一致性与 NTP 时钟同步。
4. IPX 节点 TLS 拦截：若 IPX 启用 TLS 中间盒（TLS-aware IPX）且配置错误，可能截断 N32-f 上下文。需确认 SEPP 间是否使用端到端 TLS 还是逐跳 TLS，并保证 PRINS 不受影响（PRINS 独立于 TLS，理论上即使 TLS 被 IPX 终止，PRINS 仍提供端到端保护）。
5. 性能瓶颈：大量短消息的 JWS 签名/验签开销。部分厂商（如 IPLOOK、爱立信）通过 N32-f 上下文复用、硬件加速与批量验签优化，据称可提升 N32-f 性能 40%。
Q1: N32-c 和 N32-f 到底有什么区别？ A: N32-c 是"控制面/握手面"，负责双向认证、密码套件协商、派生密钥并建立可复用的 N32-f 安全上下文，执行频率低（类似 IPsec IKE）；N32-f 是"转发面"，对每条实际业务消息应用 PRINS 加密+完整性保护，执行频率高（类似 IPsec ESP）。一次 N32-c 协商支撑后续成千上万条 N32-f 消息。
Q2: 既然有 TLS，为什么还要 PRINS 这个应用层安全？ A: TLS 是传输层逐跳的，而 N32 路径穿越多个不可信 IPX 提供商。如果仅靠 TLS，要么 IPX 不可见（端到端 TLS，但 IPX 无法做路由优化/计费），要么 IPX 终止 TLS（即可见全部明文，重蹈 4G 覆辙）。PRINS 在应用层做端到端的逐 IE 加密+签名，与 TLS 解耦，使 IPX 能看到路由字段完成转发、却始终无法读取或篡改敏感内容——这正是"零信任 IPX"的设计精髓。
Q3: 抓包能看到漫游信令的明文吗？ A: 取决于抓包位置。在 IPX 段或 SEPP 之间（N32-f），即使解密 TLS，看到的仍是密文 IE + JWS 签名，无法还原明文。只有在 PLMN 内部（NF↔SEPP，hSEPP↔hNF）才能看到 SEPP 重建后的明文 SBI。这是排错时常切换抓包点的原因。
Q4: 如果两个 SEPP 协商不出共同密码套件怎么办？ A: TS 29.573 要求取双方支持列表的交集最高优先级；若无交集，N32-c 协商失败，N32-f 上下文无法建立，所有跨 PLMN 业务信令被阻断。实务中需通过漫游协议预先对齐双方 PRINS 套件版本（尤其 R15↔R17/R18 设备对接时），或升级设备补齐套件。注意：3GPP 不鼓励"零保护降级"，默认拒绝明文回退。
Q5: 哪些 IE 会被 SEPP 加密？ A: 由 TS 33.501 规定的"需机密性保护的数据类型"决定，典型包括：SUPI、5G-AKA/EAP-AKA' 鉴权向量（RAND、AUTN、XRES、Kseaf/HRES）、用户订阅数据、GPSI、用户位置等。具体到每个 API 消息的逐字段策略，在各接口规范（如 TS 29.503 UDM、TS 29.509 AUSF）中给出映射表。路由必需字段（如 API 路径、目标 FQDN）保留明文以供 IPX 转发。
本文由「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 等场景全覆盖。