<!-- title: 5G SEPP漫游N32安全机制拆解 -->
<!-- domain: security -->

# 5G SEPP 跨 PLMN 漫游安全机制深度拆解：N32-c 协商与 N32-f PRINS 保护全链解析

## 一、为什么需要 SEPP：从 4G 漫游安全的"裸奔"说起

在 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 在漫游架构中的位置与双平面模型

SEPP 部署在每个 PLMN 的网络边界，是所有跨运营商 SBI 信令的**唯一出入口**。两个 PLMN 的 SEPP 之间通过 **N32 参考点**互联。N32 被巧妙地拆分为两个逻辑平面：

```mermaid
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
```

- **N32-c（Control plane，控制面）**：用于两个 SEPP 之间的**安全能力协商（Security Capability Negotiation）**——完成双向认证、密码套件协商、密钥派生，建立可复用的 **N32-f 安全上下文**。类比 IPsec 中的 IKE。
- **N32-f（Forwarding plane，转发面）**：承载实际的跨 PLMN SBI 业务信令，对每条消息应用 **PRINS（PRotocol for N32 Interconnect Security）** 应用层保护。类比 IPsec 中的 ESP。

这种"先握手建隧道、再逐消息保护"的双平面分离，使协商开销被摊薄到大量后续业务消息上，兼顾了安全性与性能。

## 三、N32-c 安全能力协商流程（TS 29.573 §5.2.2）深度解析

当一个 vPLMN 的 NF 首次向 hPLMN 的 NF 发起请求，且两 SEPP 间尚无有效 N32-f 上下文时，vSEPP 触发 N32-c 协商。该流程定义于 **TS 29.573 §5.2.2 "Security Capability Negotiation Procedure"**。

```mermaid
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）解析：**

1. **PLMN-id / SEPP FQDN**：每个 SEPP 用全限定域名（FQDN）标识，并携带所属 PLMN ID。协商双方必须校验"证书中的 FQDN ↔ 声明的 PLMN-id"一致性，防止身份伪造。
2. **密码套件有序列表（Ordered cipher suite list）**：双方各自维护一个按运营商策略排序的支持列表，TS 29.573 规定响应方 SEPP 的支持套件必须是**有序列表**，最终按"发起方列表 ∩ 响应方列表，取双方共同最高优先级"选定。典型套件形如 `PRINS-128-...`，涵盖加密算法（如 AES）、完整性算法、密钥派生函数。
3. **N32-f 上下文**：协商成功后，双方各持有一份对称的上下文，包含 `Kenc`（加密密钥）、`Kint`（完整性密钥）、选定套件、生命周期（有效期）。该上下文被缓存，后续多条业务消息复用，直到过期或被撤销。

> **设计意图**：把"认证+密钥协商"与"数据保护"解耦，与 IPsec 的 IKE/ESP 分离思路一致。这样新增密码套件或更新密钥时，无需重传海量业务数据。

## 四、N32-f PRINS 保护：SEPP"修改函数"逐信元拆解

这是整个机制最精妙、也最常被误解的部分。PRINS 保护**不是对整条 HTTP 消息加密**，而是 SEPP 执行一个**修改函数（modification function）**，按"数据类型"对消息内的特定 IE 做精细化处理——这正是 IPX 节点为何仍能完成路由却看不到敏感内容的关键。

### 4.1 三类 IE 保护策略

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 | ✅ 可见 |

### 4.2 修改函数的变换流水线

```mermaid
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
```

**关键设计点：**

1. **数据类型驱动（Data-type based）而非字段名驱动**：SEPP 维护一张"数据类型 → 保护策略"表，即使不同 NF 服务里字段名不同，只要语义数据类型相同（如所有"用户永久标识"），保护策略一致。TS 33.501 规定了哪些数据类型必须机密性保护。
2. **JWS（JSON Web Signature，RFC 7515）提供完整性+防重放**：签名对象中包含时间戳与序列号，接收 SEPP 校验时间窗口，杜绝重放攻击。
3. **加密用 JWE（JSON Web Encryption）**：密文封装为带数据类型标识的对象，接收方据此正确解密。
4. **可逆性**：hSEPP 执行完全逆过程——先验签（必须先验签后解密，防止伪造密文导致后续处理异常），再解密，最后重建出与 vNF 原始请求**逐字节等价**的 SBI 消息递交给 hNF。hNF 完全无感，无需知道经过 SEPP。

## 五、完整漫游注册鉴权信令全链时序

下面以一个典型的漫游场景——**UE 在 vPLMN 注册，需向 hPLMN 的 UDM/AUSF 完成鉴权**——展示 N32-c 与 N32-f 如何协同工作（综合 TS 23.502 §4.2.2 注册流程与 TS 33.501 鉴权流程）：

```mermaid
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 截获报文，得到的也只是无法解析的密文与一条不可伪造的签名。

## 六、5G SEPP N32 vs 4G Diameter/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 转发。

## 参考来源

1. [3GPP TS 33.501 V18.10.0 — Security architecture and procedures for 5G system (R18)](https://www.3gpp.org/dynareport/33501.htm) — SEPP、N32 安全架构、需机密性保护数据类型定义
2. [3GPP TS 29.573 — 5G System; PLMN Interconnection; Stage 3](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3530) — §5 N32 Procedures、§5.2.2 Security Capability Negotiation、PRINS、密码套件协商
3. [3GPP TS 29.500 — Technical Realization of Service Based Architecture](https://www.3gpp.org/dynareport/29500.htm) — SBI 安全原则与 SEPP 消息保护机制
4. [3GPP — 5G Roaming Security (SA3)](https://www.3gpp.org/technologies/roaming-security-sa3) — SEPP 漫游安全架构官方说明
5. [The 3G4G Blog — 5G Roaming with SEPP (Security Edge Protection Proxy)](https://blog.3g4g.co.uk/2020/06/5g-roaming-with-sepp-security-edge.html) — SEPP 双平面模型与 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学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)