首页 › security › 5G SEPP N32跨域PRINS保护信令拆解

5G SEPP N32跨域PRINS保护与消息安全信令全链路拆解

1. 引言:为什么5G漫游需要全新的安全架构

4G时代的漫游安全依赖IPSec或TLS隧道在Diameter信令网(IPX)上建立传输层保护。但5G核心网全面转向SBI(Service Based Interface)架构后,NF间通信基于HTTP/2 + JSON,传统传输层隧道存在三大缺陷:中间IPX提供商可窥探全部信令内容、无法对单个IE字段实施差异化保护、缺少消息级重放攻击防护。

3GPP SA3工作组在TS 33.501 Section 13中定义了全新的SEPP(Security Edge Protection Proxy)架构,并在N32接口上引入PRINS(PRotocol for N32 INterconnect Security)应用层安全协议(TS 33.501 Section 13.2),实现跨PLMN信令的细粒度、策略驱动的消息级保护。本文将深入拆解N32-c握手协商、PRINS保护策略匹配、N32-f消息转发全链路信令,揭示每个关键IE的设计意图与博弈逻辑。

2. SEPP在网络架构中的定位

SEPP是部署在每个PLMN边缘的安全代理网关,是所有跨PLMN SBI信令的必经关卡。TS 33.501 Section 9.2明确定义了SEPP的安全职责:

graph LR
    subgraph VPLMN["Visited PLMN (vPLMN)"]
        AMF_v[AMF]
        SMF_v[SMF]
        NRF_v[NRF]
        SEPP_v[SEPP<br/>c-SEPP]
    end

    subgraph IPX["IPX Provider Network"]
        IPX_Proxy[IPX Proxy<br/>可选中间节点]
    end

    subgraph HPLMN["Home PLMN (hPLMN)"]
        SEPP_h[SEPP<br/>p-SEPP]
        AUSF_h[AUSF]
        UDM_h[UDM]
        NRF_h[NRF]
    end

    AMF_v -->|SBI| SEPP_v
    SMF_v -->|SBI| SEPP_v
    SEPP_v -->|N32-c + N32-f| IPX_Proxy
    IPX_Proxy -->|N32-c + N32-f| SEPP_h
    SEPP_h -->|SBI| AUSF_h
    SEPP_h -->|SBI| UDM_h

    style SEPP_v fill:#e74c3c,color:#fff
    style SEPP_h fill:#3498db,color:#fff
    style IPX_Proxy fill:#f39c12,color:#fff

关键博弈点:SEPP设计面临安全性vs可路由性的核心矛盾。IPX中间节点需要读取HTTP头部中的路由信息来转发消息,但又不能看到敏感的业务数据(如SUPI、认证向量)。PRINS通过分层保护策略解决这一矛盾——路由字段明文可读,业务数据加密不可见。

3. N32接口双层架构:N32-c与N32-f

TS 33.501 Section 13.1将N32接口分为两个逻辑子接口:

维度 N32-c(Control) N32-f(Forwarding)
定义章节 TS 33.501 Section 13.1.2 TS 33.501 Section 13.1.3
协议规范 TS 29.573 Section 5 TS 29.573 Section 6
功能 安全上下文建立与参数协商 承载实际NF间SBI消息
安全机制 TLS双向认证 + 参数交换 PRINS消息保护
触发时机 SEPP对之间首次通信前 每次NF间服务调用
持续时间 长期安全上下文 逐消息保护
保护对象 SEPP间协商数据 HTTP/2请求/响应的全部内容

3.1 N32-c安全能力协商信令流程

N32-c握手包含两个阶段:TLS隧道建立和安全参数协商。TS 29.573 Section 5.2定义了Nnrf_nfDiscovery触发SEPP发现和N32c-handshake服务操作。

sequenceDiagram
    participant cSEPP as c-SEPP (vPLMN)
    participant pSEPP as p-SEPP (hPLMN)

    Note over cSEPP,pSEPP: 阶段一:TLS隧道建立
    cSEPP->>pSEPP: TLS ClientHello<br/>[SNI: sepp.hplmn.example]
    pSEPP->>cSEPP: TLS ServerHello + Certificate
    cSEPP->>pSEPP: Certificate + CertificateVerify
    pSEPP->>cSEPP: TLS Finished
    Note over cSEPP,pSEPP: TLS 1.3 mutual auth完成<br/>双向证书验证

    Note over cSEPP,pSEPP: 阶段二:安全能力协商
    cSEPP->>pSEPP: POST /n32c-handshake/v1/exchange-capability<br/>{seppId, plmnId, supportedSecCapability,<br/>n32fContextId, senderIdentity}
    pSEPP->>cSEPP: 200 OK<br/>{selectedSecCapability, n32fContextId,<br/>senderIdentity, protectionPolicy}

    alt 协商失败
        pSEPP->>cSEPP: 403 Forbidden<br/>{cause: "Unsupported security capability"}
    end

    Note over cSEPP,pSEPP: N32-c安全上下文建立完成<br/>后续N32-f消息使用协商参数

3.1.1 N32-c ExchangeCapabilityRequest关键IE

IE名称 类型 说明
seppId FQDN 发起方SEPP的完全限定域名,如sepp.mnc460.mcc001.3gppnetwork.org
plmnId PlmnId 发起方PLMN标识(MCC+MNC)
supportedSecCapability array 支持的安全能力列表,含PRINS
n32fContextId string 本次协商关联的N32-f上下文标识
senderIdentity string 发送方身份标识,用于TLS证书绑定验证
vPLMNId PlmnId 可选,发起方PLMN-ID,用于多PLMN场景

设计意图:supportedSecCapability采用列表而非单一值,是为了前向兼容。Rel-15仅定义了PRINS,Rel-18增加了对TLS profile增强的支持,未来可扩展更多安全机制。

3.1.2 N32-c ExchangeCapabilityResponse关键IE

IE名称 类型 说明
selectedSecCapability string 选定的安全能力,必须为发起方列表中的某一项
n32fContextId string 确认的N32-f上下文标识
senderIdentity string 响应方身份标识
protectionPolicy object 核心字段——保护策略定义,指定每类数据的保护方式

关键博弈点:响应方的selectedSecCapability必须从发起方提供的列表中选择。如果两个SEPP没有交集的安全能力,握手将失败(HTTP 403),这意味着漫游协议签署前必须确认双方SEPP的兼容性。

4. PRINS保护策略(Protection Policy)深度解析

PRINS的保护粒度达到单个JSON字段级别,这是5G相比4G安全的革命性提升。TS 33.501 Section 13.2.1.4定义了五种保护类型:

graph TD
    A[Protection Policy<br/>保护策略] --> B[INTEGRITY_PROTECTION<br/>仅完整性保护]
    A --> C[INTEGRITY_AND_CIPHERING<br/>完整性+机密性保护]
    A --> D[CLEAR_TEXT<br/>明文传输]
    A --> E[MODIFICATION_REPLACEMENT<br/>替换修改]
    A --> F[MODIFICATION_DELETION<br/>删除修改]

    B --> B1[JWS签名<br/>IPX可读不可改]
    C --> C1[JWE加密+JWS签名<br/>IPX完全不可读]
    D --> D1[不保护<br/>路由等公共信息]
    E --> E1[cSEPP替换敏感值<br/>pSEPP恢复原值]
    F --> F1[cSEPP删除字段<br/>pSEPP不恢复]

    style B fill:#27ae60,color:#fff
    style C fill:#e74c3c,color:#fff
    style D fill:#95a5a6,color:#fff
    style E fill:#f39c12,color:#fff
    style F fill:#8e44ad,color:#fff

4.1 五种保护类型详解

类型一:INTEGRITY_PROTECTION(仅完整性)

类型二:INTEGRITY_AND_CIPHERING(完整性和机密性)

类型三:CLEAR_TEXT(明文)

类型四:MODIFICATION_REPLACEMENT(替换修改)

类型五:MODIFICATION_DELETION(删除修改)

4.2 保护策略协商博弈

保护策略并非单方面决定,而是在N32-c握手过程中双向协商的结果:

协商维度 规则 博弈点
策略来源 cSEPP和pSEPP各持本地策略 取两者交集(更严格者)
字段匹配 JSON Pointer定位(RFC 6901) 嵌套字段的匹配优先级
默认策略 未匹配字段默认CLEAR_TEXT 安全基线的设定风险
策略更新 仅可通过N32-c重新握手 策略变更导致短暂中断
中间IPX策略 cIPX可能有独立修改策略 三方策略一致性问题

实际部署中的典型配置:

消息类型 SUPI 认证向量 DNN 内部NF地址 消息ID
Nudm_UECM_Registration INTEGRITY - INTEGRITY REPLACEMENT CLEAR
Nausf_UEAuthentication INTEGRITY INTEGRITY_AND_CIPHERING - REPLACEMENT CLEAR
Nudm_SDM_Get INTEGRITY - INTEGRITY REPLACEMENT CLEAR
Nsmf_PDUSession_Create INTEGRITY - INTEGRITY_AND_CIPHERING REPLACEMENT CLEAR

5. N32-f消息保护与转发的完整信令流程

以下展示漫游注册场景中,vPLMN AMF通过c-SEPP → IPX → p-SEPP向hPLMN AUSF发起5G-AKA认证请求的完整PRINS保护信令链:

sequenceDiagram
    participant AMF as vPLMN AMF
    participant cSEPP as c-SEPP
    participant IPX as IPX Provider
    participant pSEPP as p-SEPP
    participant AUSF as hPLMN AUSF

    Note over AMF: UE发起注册<br/>需要hPLMN认证

    AMF->>cSEPP: POST /nausf-auth/v1/ue-authentications<br/>Body: {supi: SUCI, servingNetworkName: "5G:mnc460.mcc001"...}

    Note over cSEPP: 步骤1:策略匹配<br/>匹配Protection Policy<br/>- supi → INTEGRITY_PROTECTION<br/>- servingNetworkName → INTEGRITY_PROTECTION

    Note over cSEPP: 步骤2:JWS签名<br/>对integrity保护字段生成<br/>JWS Compact Serialization签名

    Note over cSEPP: 步骤3:拓扑隐藏<br/>内部NF地址替换<br/>amf.internal.vplmn → placeholder-001

    cSEPP->>IPX: POST /nausf-auth/v1/ue-authentications<br/>Header: Content-Type: application/json<br/>Body: {<br/>"protectedHeader": {...},<br/>"signature": "BASE64URL(SIG)",<br/>"payload": {<br/>  "supi": "SUCI_value",<br/>  "servingNetworkName": "5G:mnc460.mcc001"<br/>}<br/>}

    Note over IPX: IPX仅读取路由头<br/>无法修改被保护字段<br/>(JWS签名会校验失败)

    IPX->>pSEPP: 转发请求<br/>(消息内容不变)

    Note over pSEPP: 步骤4:JWS验证<br/>验证签名完整性<br/>确认消息未被篡改

    Note over pSEPP: 步骤5:拓扑恢复<br/>placeholder-001 →<br/>amf.internal.vplmn<br/>(使用replacementMap)

    pSEPP->>AUSF: POST /nausf-auth/v1/ue-authentications<br/>Body: {supi: SUCI,<br/>servingNetworkName: "5G:mnc460.mcc001"...}

    AUSF->>pSEPP: 201 Created<br/>Body: {authType: "5G-AKA",<br/>5gAuthData: {rand, autn, hxstarstar*},<br/>links: {...}}

    Note over pSEPP: 步骤6:出站策略匹配<br/>- 5gAuthData → INTEGRITY_AND_CIPHERING<br/>- rand → INTEGRITY_PROTECTION<br/>- hxstarstar* → INTEGRITY_AND_CIPHERING

    Note over pSEPP: 步骤7:JWE加密敏感字段<br/>对认证向量等施加JWE加密<br/>使用协商的加密密钥

    pSEPP->>IPX: 201 Created<br/>Body: {<br/>"encrypted": "BASE64URL(JWE)",<br/>"signature": "BASE64URL(SIG)",<br/>"clearFields": {authType: "5G-AKA"}<br/>}

    IPX->>cSEPP: 转发响应

    Note over cSEPP: 步骤8:JWE解密<br/>使用本地密钥解密<br/>恢复认证向量

    Note over cSEPP: 步骤9:JWS验证<br/>验证响应完整性

    cSEPP->>AMF: 201 Created<br/>Body: {authType: "5G-AKA",<br/>5gAuthData: {rand, autn, hxstarstar*}}

6. PRINS消息保护的JWS/JWE结构剖析

6.1 JWS Compact Serialization结构(完整性保护)

TS 33.501 Section 13.2.1.5规定,对需要完整性保护的消息,cSEPP生成JWS Compact Serialization:

BASE64URL(ProtectedHeader) . BASE64URL(Payload) . BASE64URL(Signature)

Protected Header示例:

{
  "alg": "ES256",
  "kid": "csepp-key-2026-001",
  "typ": "PRINS-JWS",
  "n32fCtxId": "ctx-v2plmn-hplmn-001",
  "iat": 1716422400,
  "jti": "msg-uuid-a1b2c3d4"
}
字段 说明 设计意图
alg 签名算法,通常ES256(ECDSA P-256) 3GPP推荐P-256曲线,平衡安全性和性能
kid 密钥标识 支持密钥轮换,无需中断服务
typ 类型标识PRINS-JWS 区分普通JWS,便于IPX识别
n32fCtxId N32-f上下文ID 绑定到N32-c协商的安全上下文
iat 签发时间戳 重放攻击防护核心字段
jti 消息唯一标识 防止同一消息被重复投递

6.2 JWE JSON Serialization结构(机密性保护)

对需要机密性保护的字段,SEPP生成JWE JSON Serialization:

{
  "protected": "BASE64URL({alg:A256KW, enc:A256GCM})",
  "encrypted_key": "BASE64URL(CEK_wrapped)",
  "iv": "BASE64URL(initialization_vector)",
  "ciphertext": "BASE64URL(encrypted_payload)",
  "tag": "BASE64URL(authentication_tag)",
  "unprotected": {
    "kid": "csepp-enc-key-2026-001",
    "n32fCtxId": "ctx-v2plmn-hplmn-001"
  }
}

密钥派生链:

graph TD
    TLS[TLS 1.3 Master Secret] -->|TLS-Exporter| MK[N32 Master Key<br/>TS 33.501 13.2.1.3]
    MK -->|KDF| IK[Integrity Key<br/>用于JWS签名/验证]
    MK -->|KDF| EK[Encryption Key<br/>用于JWE加密/解密]
    MK -->|KDF| SALT[Key Salt<br/>密钥更新种子]

    SALT -->|密钥轮换| MK2[Updated Master Key]

    style TLS fill:#2c3e50,color:#fff
    style MK fill:#e74c3c,color:#fff
    style IK fill:#27ae60,color:#fff
    style EK fill:#3498db,color:#fff

密钥派生博弈:TS 33.501 Section 13.2.1.3规定密钥材料从TLS 1.3的TLS-Exporter机制获取,而非独立协商。这种设计的优势是减少额外握手开销,但风险是TLS会话 renegotiation会影响PRINS密钥。3GPP通过N32-f上下文绑定n32fCtxId来隔离密钥生命周期。

6.3 PRINS保护消息的整体JSON结构

cSEPP发送的完整保护消息结构(TS 29.573 Section 6.1.3定义的SecuredRIMessage):

{
  "sender": "sepp.vplmn.example",
  "receiver": "sepp.hplmn.example",
  "n32fContextId": "ctx-v2plmn-hplmn-001",
  "messageBody": {
    "originalHttpMethod": "POST",
    "originalTargetApi": "/nausf-auth/v1/ue-authentications",
    "httpHeaders": {
      "content-type": "application/json"
    },
    "jsonData": {
      "supi": {
        "integritySignature": "eyJhbGciOiJFUzI1NiIs..."
      },
      "servingNetworkName": {
        "integritySignature": "eyJhbGciOiJFUzI1NiIs..."
      }
    },
    "replacementsMap": {
      "placeholder-001": "amf.internal.vplmn.mnc460.mcc001.3gppnetwork.org"
    }
  }
}

7. cIPX中间节点的策略处理

TS 33.501 Section 13.2.2引入了cIPX(commercial IPX)的概念,允许IPX提供商在消息转发链中执行有限的修改操作。这引入了三方博弈:

参与方 可执行操作 安全约束
cSEPP 施加全部保护策略 不能跳过任何mandatory保护
cIPX MODIFICATION_REPLACEMENT和MODIFICATION_DELETION 不能修改integrity-protected字段
pSEPP 恢复所有修改,验证完整性 必须按逆序恢复

cIPX修改策略的嵌套博弈:

  1. cSEPP对字段A施加INTEGRITY_PROTECTION
  2. cSEPP对字段B施加MODIFICATION_REPLACEMENT(替换为placeholder-001)
  3. 消息到达cIPX,cIPX对字段C施加MODIFICATION_DELETION
  4. pSEPP接收后,首先验证字段A的JWS签名(完整性检查)
  5. pSEPP恢复字段B(placeholder-001 → 原始值)
  6. pSEPP不恢复字段C(已被删除)

安全风险:如果cIPX恶意修改了INTEGRITY_PROTECTION保护的字段,pSEPP的JWS验证将失败,消息被丢弃。但cIPX如果篡改CLEAR_TEXT字段,则无法被检测——这是PRINS设计的已知边界,也是为什么路由关键字段应至少施加INTEGRITY_PROTECTION。

8. N32-f上下文生命周期与密钥管理

stateDiagram-v2
    [*] --> INIT: N32-c握手发起
    INIT --> NEGOTIATING: ExchangeCapabilityRequest发送
    NEGOTIATING --> ACTIVE: 协商成功<br/>密钥建立
    NEGOTIATING --> FAILED: 能力不匹配<br/>返回403
    FAILED --> [*]

    ACTIVE --> ACTIVE: 密钥轮换<br/>计数器或时间触发
    ACTIVE --> EXPIRED: 安全上下文超时
    ACTIVE --> TERMINATED: SEPP重启/策略变更
    EXPIRED --> INIT: 自动重协商
    TERMINATED --> INIT: 手动触发重新握手

    note right of ACTIVE
        正常N32-f消息传输
        每条消息携带n32fCtxId
        JWS签名计数器递增
    end note

密钥轮换触发条件(TS 33.501 Section 13.2.1.3):

触发条件 说明
消息计数器溢出 当JWS的jti序列号接近2^32时
时间过期 N32-f上下文生命周期到期(运营商配置,通常24-72小时)
策略变更 任一方SEPP更新保护策略
TLS重协商 底层TLS会话重建
管理员触发 O&M系统手动发起密钥更新

9. 抓包识别与故障排查

9.1 Wireshark抓包识别要点

识别特征 具体表现
N32-c握手 HTTP/2 POST到/n32c-handshake/v1/exchange-capability
PRINS消息 Content-Type为application/json,Body包含sender/receiver/n32fContextId
JWS保护字段 值为eyJhbGci...开头的Base64URL字符串
JWE保护字段 包含encrypted_key/ciphertext/tag子结构
拓扑隐藏 NF地址显示为placeholder-xxx格式

9.2 常见故障场景

故障现象 根因 排查方法
N32-c握手403 安全能力不匹配 检查双方supportedSecCapability是否包含交集
N32-f消息JWS验证失败 密钥不一致或轮换不同步 检查n32fCtxId是否一致,比较双方密钥版本
认证向量解密失败 JWE加密密钥不匹配 确认TLS-Exporter派生的Encryption Key一致
消息被IPX丢弃 保护策略冲突 检查cIPX的修改策略是否与SEPP策略兼容
拓扑恢复失败 replacementMap不同步 检查cSEPP的替换映射是否被正确同步到pSEPP
重放攻击误报 时钟不同步 检查iat时间戳,确保两端NTP同步
## 10. 与4G漫游安全的对比
维度 4G(Diameter/IPSec) 5G(SBI/PRINS)
保护层级 传输层(IPSec隧道) 应用层(PRINS消息级)
保护粒度 整条消息 单个JSON字段
中间节点可见性 全可见或全不可见 按策略分级可见
拓扑隐藏 无原生支持 MODIFICATION_REPLACEMENT
密钥管理 IKEv2协商 TLS-Exporter派生
策略灵活性 静态(隧道级别) 动态(字段级别协商)
算法协商 IKE SA提案 JWS/JWE标准算法

11. Rel-18/19增强方向

TS 33.501 Rel-18对SEPP/PRINS的关键增强:

常见问题

Q: PRINS的Mode A和Mode B有什么区别? A: 早期Rel-15草案中Mode A指cSEPP直接保护(hop-by-hop),Mode B指端到端保护。但正式发布的TS 33.501中统一为基于保护策略的单模式方案,取消了Mode A/B的区分。当前所有字段保护都基于Protection Policy中的5种类型。

Q: SEPP是否可以跳过某些字段的保护? A: 可以,使用CLEAR_TEXT保护类型。但TS 33.501 Annex A.4定义了minimum protection profile,某些字段(如SUPI、认证向量)是mandatory to protect的,不能设为CLEAR_TEXT。违背最低保护要求的配置将导致漫游安全审计不通过。

Q: cIPX能读取INTEGRITY_PROTECTION保护的消息内容吗? A: 能。INTEGRITY_PROTECTION仅提供JWS签名(防篡改),字段内容仍然以明文传输。cIPX可以看到但无法修改这些字段——任何修改都会被pSEPP的JWS验证检测到。如需对cIPX隐藏内容,应使用INTEGRITY_AND_CIPHERING。

Q: N32-c握手失败后如何恢复? A: N32-c握手失败后,cSEPP不会建立N32-f上下文,后续所有NF间通信将失败。恢复方式包括:(1) 修正安全能力配置后重新握手;(2) 通过O&M系统手动触发重连;(3) 配置fallback策略(部分厂商支持降级到TLS-only模式,但不推荐)。

Q: PRINS密钥和TLS密钥的关系是什么? A: PRINS的Master Key通过TLS 1.3的TLS-Exporter机制从TLS会话中派生,这意味着PRINS密钥依赖于TLS握手建立的安全通道。如果TLS会话被 renegotiation,PRINS密钥也需要更新。但PRINS密钥和TLS密钥是不同的密钥——TLS保护传输层,PRINS保护应用层消息内容,形成双层防护。

参考来源

  1. 3GPP TS 33.501 V18.10.0 — Section 13: Inter-PLMN security, Section 13.2: Application layer security on N32
  2. 3GPP TS 29.573 — Section 5: N32-c Procedures, Section 6: N32-f Procedures
  3. 3GPP Roaming Security (SA3) — 5G Roaming security architecture overview
  4. Mavenir: Securing 5G Signalling for Roaming — PRINS protocol design rationale
  5. IEEE CNS 2025: Performance Evaluation of 5G Roaming Security Based on PRINS — 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学通信知识星球海报-扫码加入