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的设计意图与博弈逻辑。
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通过分层保护策略解决这一矛盾——路由字段明文可读,业务数据加密不可见。
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请求/响应的全部内容 |
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消息使用协商参数
| 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增强的支持,未来可扩展更多安全机制。
| IE名称 | 类型 | 说明 |
|---|---|---|
selectedSecCapability |
string | 选定的安全能力,必须为发起方列表中的某一项 |
n32fContextId |
string | 确认的N32-f上下文标识 |
senderIdentity |
string | 响应方身份标识 |
protectionPolicy |
object | 核心字段——保护策略定义,指定每类数据的保护方式 |
关键博弈点:响应方的selectedSecCapability必须从发起方提供的列表中选择。如果两个SEPP没有交集的安全能力,握手将失败(HTTP 403),这意味着漫游协议签署前必须确认双方SEPP的兼容性。
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
supi(在SUCI场景下已加密)、dnn、snssai等需要中间节点可见但不可改的路由信息authenticationVector、kSeAF、kAusf等敏感密钥材料,以及gpsis等用户隐私数据3gpp-Sbi-Target-apiRoot)、nfId等公共信息replacementMap,映射占位符→原始值保护策略并非单方面决定,而是在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 |
以下展示漫游注册场景中,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*}}
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 |
消息唯一标识 | 防止同一消息被重复投递 |
对需要机密性保护的字段,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来隔离密钥生命周期。
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"
}
}
}
TS 33.501 Section 13.2.2引入了cIPX(commercial IPX)的概念,允许IPX提供商在消息转发链中执行有限的修改操作。这引入了三方博弈:
| 参与方 | 可执行操作 | 安全约束 |
|---|---|---|
| cSEPP | 施加全部保护策略 | 不能跳过任何mandatory保护 |
| cIPX | MODIFICATION_REPLACEMENT和MODIFICATION_DELETION |
不能修改integrity-protected字段 |
| pSEPP | 恢复所有修改,验证完整性 | 必须按逆序恢复 |
cIPX修改策略的嵌套博弈:
安全风险:如果cIPX恶意修改了INTEGRITY_PROTECTION保护的字段,pSEPP的JWS验证将失败,消息被丢弃。但cIPX如果篡改CLEAR_TEXT字段,则无法被检测——这是PRINS设计的已知边界,也是为什么路由关键字段应至少施加INTEGRITY_PROTECTION。
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系统手动发起密钥更新 |
| 识别特征 | 具体表现 |
|---|---|
| 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格式 |
| 故障现象 | 根因 | 排查方法 |
|---|---|---|
| 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标准算法 |
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保护应用层消息内容,形成双层防护。
本文由「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 等场景全覆盖。
