5G核心网全面服务化（Service Based Architecture, SBI），所有NF之间的交互都基于HTTP/2 + JSON。这一变革在网内带来了便利，但在跨PLMN漫游（inter-PLMN roaming）场景下却制造了一个前所未有的安全难题：4G时代漫游信令走的是Diameter协议，经由IPX（IP eXchange）网络的DRA/DSC节点中转，传统做法是网络域安全（NDS/IP）+ IPSec隧道做逐跳保护；而5G漫游信令是HTTP/2，需要穿越多个漫游中介（Roaming Intermediary, RI / IPX Provider）。
问题随之而来：
3GPP SA3工作组给出的答案是SEPP（Security Edge Protection Proxy），定义在TS 33.501第13章。SEPP是部署在PLMN边界的非透明安全代理，它不解决"是否加密"的问题，而是解决"对谁加密、加密到什么粒度、如何认证中间商修改"的问题。其核心机制就是本文要拆解的PRINS（PRotocol for N32 Interconnect Security）——这是5G相比4G在漫游安全上最根本的架构升级。
SEPP在拓扑上位于每个PLMN的边界，所有跨运营商的NF服务信令都必须经由本侧SEPP出网、对端SEPP入网。两个SEPP之间的逻辑接口统称为N32，被刻意拆成两条职责不同的逻辑链路：
| 接口 | 全称 | 承载内容 | 传输保护 |
|---|---|---|---|
| N32-c | N32-context | 安全能力协商、密钥与参数交换、保护策略下发 | 始终基于双向认证TLS（TS 33.501 13.1.2） |
| N32-f | N32-forwarding | 真正的NF服务信令（HTTP/2请求/响应，如AMF→UDM） | 由N32-c协商选定的模式保护：PRINS或TLS |
这个"控制面（N32-c）+转发面（N32-f）"分离的设计是理解整个机制的关键：先在N32-c上"谈判"好怎么保护，再在N32-f上"执行"保护。N32-c像两个PLMN之间的"安全外交官"，N32-f则是运送实际货物的"加密货柜通道"。
graph TD
subgraph VPLMN[拜访PLMN V-PLMN]
vNF[vNF 如AMF/SMF]
vSEPP[vSEPP]
vNF -->|N32 / HTTP-2 同网内| vSEPP
end
subgraph HPLMN[归属PLMN H-PLMN]
hSEPP[hSEPP]
hNF[hNF 如UDM/AUSF]
hSEPP -->|N32 / HTTP-2 同网内| hNF
end
vSEPP -->|N32-c: 能力/密钥/策略协商 TLS| RI1[IPX Provider 1]
vSEPP -->|N32-f: NF信令 PRINS/JWE| RI2[IPX Provider 2]
RI1 --> hSEPP
RI2 --> hSEPP
style vSEPP fill:#ffe,stroke:#a80,stroke-width:2px
style hSEPP fill:#ffe,stroke:#a80,stroke-width:2px
需要强调：N32-c承载的协商信息本身就是敏感的（含双方证书、保护策略），所以N32-c必须运行在双向认证TLS之上（TS 33.501 13.5明确："A mutually authenticated TLS connection as defined in clause 13.1 shall be used for protecting security capability negotiation over N32-c. The TLS connection shall provide integrity, confidentiality and replay protection."）。
N32-c上的工作分为两个阶段，分别对应TS 33.501的两条子流程：安全能力协商（clause 13.5）和密钥协商与参数交换（clause 13.2.2.2）。
发起TLS连接的SEPP向对端的exchange-capability资源（TS 29.573定义的n32c-handshake服务）发起POST，携带本端支持的N32-f保护机制列表，按优先级排序。对端比对自身支持列表，依据本地策略（如判断路径上是否有RI、本PLMN是否允许TLS模式）选定一种双方都支持的机制。
Table 13.5-1 N32-f保护机制
Mechanism 1: PRINS (clause 13.2)
Mechanism 2: TLS
Mechanism n: Reserved
注意三个工程细节：第一，若选PRINS则保持N32-c连接并按13.2执行；若选TLS则主动拆除N32-c连接，改为在N32-f上直接建立TLS隧道（13.1.2）；第二，协商顺序由"发起方列优先级、响应方做选择"，响应方握有最终决定权——这是为了让归属侧（通常是数据/密钥的持有者）能强制执行更高级别的安全策略；第三，仅当双方支持的机制交集为空时才终止TLS。
选定为PRINS模式后，双方进入真正的"安全上下文建立"，原文逐条定义了四步：
Security Parameter Exchange Request（含本端支持的cipher suite优先级列表 + 本端的N32-f Context ID）；响应方比对后回Security Parameter Exchange Response（含选定cipher suite + 响应方的N32-f Context ID）。sequenceDiagram
autonumber
participant V as vSEPP(发起方)
participant H as hSEPP(响应方)
Note over V,H: 前置: 双向认证TLS连接已建立(clause 13.1)
V->>H: POST exchange-capability<br/>[支持机制:PRINS,TLS 优先级排序]
H->>V: 200 OK [选定机制:PRINS]
Note over V,H: 阶段一 安全能力协商(clause 13.5)完成
V->>H: SecParamExchReq<br/>[cipher suite列表 + vSEPP的N32-f Context ID]
H->>V: SecParamExchResp<br/>[选定cipher + hSEPP的N32-f Context ID]
V->>H: SecParamExchReq<br/>[Data-type加密策略 + 修改策略]
H->>V: SecParamExchResp<br/>[响应侧保护策略套件]
Note over V,H: 步骤2 互存保护策略
V->>H: 交换RI安全信息列表[RI公钥/证书]
H->>V: 交换RI安全信息列表[RI公钥/证书]
Note over V,H: 步骤3 RI信息交换
Note over V,H: 步骤4 双方各自调用TLS exporter<br/>派生N32-f master key → N32-KDF
V->>H: N32-f连接就绪,开始转发NF信令(JWE/JWS保护)
| 消息/IE | 方向 | 关键字段 | 作用 |
|---|---|---|---|
exchange-capability Request |
发起方→响应方 | supportedFeatures、3gpp-Sbi-TargetApiRootSupported、seppInfo(SEPP ID, PLMN ID) | 能力发现、接口版本兼容性 |
exchange-capability Response |
响应方→发起方 | selectedN32fProtection=PRINS/TLS | 选定保护模式 |
Security Parameter Exchange Request |
双向 | cipherSuites、senderN32fContextId、data-typeEncryptionPolicy、modificationPolicy | 套件与策略协商 |
Security Parameter Exchange Response |
双向 | selectedCipherSuite、responderN32fContextId | 确认套件，分配上下文ID |
| RI信息列表 | 双向 | riPublicKey、riCertRef | 后续JWS验签依据 |
N32-f Context ID |
双向各自维护 | 全局唯一标识符 | 绑定密钥，防止重用 |
注意N32-f Context ID是整个PRINS密钥管理的"命门"：它既是双方在两个HTTP/2会话（一个发起方做client、一个响应方做client）之间区分密钥的锚点，又是防止密钥/IV重用的核心，下文密钥层级会详述。
这是PRINS最精妙的部分——它不是整条消息加密，而是对HTTP/2请求/响应做"外科手术式"的重构。vSEPP在转发前把JSON消息拆解、重组成一个嵌套的安全封装结构，hSEPP收到后还原。原文（13.2.4.2/13.2.4.3）定义了三大数据块：
dataToIntegrityProtect（仅完整性保护，明文）：包含clearTextEncapsulatedMessage和metadata。这些字段RI必须能读、能路由（如目标API root、NF类型、路由信息），但不允许被篡改——因此只做完整性（MAC），不做加密。这是PRINS能兼容IPX商业模型的关键。dataToIntegrityProtectAndCipher（完整性+加密）：真正的敏感字段（SUPI、认证向量、KAUSF、用户鉴权响应等）。用JWE（JSON Web Encryption, RFC 7516）逐字段加密，RI看到的是密文。modifiedDataToIntegrityProtect（RI修改区）：RI对消息做的合法修改（如注入计费头、号段翻译）。用JWS（JSON Web Signature, RFC 7515）签名，接收侧SEPP凭N32-c阶段交换的RI公钥验证——既能改，又改不了"未经授权的内容"。整个封装结构再计算一个顶层integrityMAC，覆盖所有上述数据块，确保整体不可篡改。
flowchart TB
Orig[原始HTTP/2请求/响应<br/>含SUPI、Auth向量、路由字段等JSON]
Orig --> Split{字段分类<br/>依据保护策略}
Split -->|RI需读取/路由的字段<br/>路由头、目标NF类型| DTIP[dataToIntegrityProtect<br/>clearTextEncapsulatedMessage+metadata]
Split -->|敏感字段<br/>SUPI、RAND/AUTN/XRES*、KAUSF| DTIPC[dataToIntegrityProtectAndCipher]
DTIPC --> JWE[**JWE加密**<br/>用parallel_request_key<br/>AES-GCM]
DTIP --> MAC1[完整性保护]
subgraph 经IPX传输
Envelope[安全封装消息<br/>明文路由区 + 密文敏感区]
RI[Roaming Intermediary<br/>读取明文路由 + 注入计费头]
RI --> MD[modifiedDataToIntegrityProtect<br/>**JWS签名**的RI修改]
end
MAC1 --> Envelope
JWE --> Envelope
MD --> Envelope
Envelope --> TopMAC[顶层integrityMAC覆盖全部]
TopMAC --> Recv[hSEPP: 验证MAC→解JWE→验JWS→还原原始消息]
style JWE fill:#fee,stroke:#c00
style MD fill:#eef,stroke:#00c
字段怎么分类，由三类策略控制：
Supi、AuthenticationInfo、Kausf）是否加密、用哪个key。它是"字段名→保护动作"的映射表。策略在N32-c阶段双向交换并存储。策略冲突（如一方要求某字段加密、另一方策略不允许）是现网最常见的一类故障（详见后文排错）。
PRINS选择JOSE（JSON Object Signing and Encryption）体系而非3GPP自有算法（如NEA/NIA），是有明确工程考量的：5G SBI本就是HTTP/2+JSON生态，JWE/JWS原生适配JSON字段级操作，且经过互联网工程界的广泛验证；而3GPP的NEA/NIA是面向NAS/RRC这样定长流式数据的。PRINS用AES-GCM（典型如A256GCM）做JWE加密，既提供保密性又提供认证加密（AEAD），一举两得。
PRINS的密钥体系完全建立在TLS之上，这是它"应用层安全"的本质——复用传输层TLS已经建立的信任，在应用层再派生一组专用密钥。原文给出的推导链非常精确：
第一步：导出主密钥（N32-f master key）
通过TLS exporter（RFC 5705，TLS 1.3中即tls_exporter）从已建立的N32-c TLS会话中导出64字节主密钥：
Label = "EXPORTER_3GPP_N32_MASTER" (IANA注册)
Context = "" (空字符串)
Length = 64 octets
第二步：N32-KDF派生会话密钥与IV salt
N32-KDF基于HKDF（RFC 5869），且只用HKDF-Expand（因为初始密钥已安全生成，无需再Extract）：
N32-KDF(label, L) = HKDF-Expand(N32-f master key,
"N32" || N32-Context-ID || label, L)
注意输入串里绑定了N32-Context-ID——这是防重用的关键。每次HKDF-Expand产出"一个会话密钥"或"一个IV salt"。共需派生两对（4个）密钥 + 对应IV salt，分别用于两个HTTP/2会话：
| 标签（label） | 用途 |
|---|---|
parallel_request_key / parallel_response_key |
发起方做HTTP client的会话（与N32-c同方向），用于请求/响应的JWE加密 |
reverse_request_key / reverse_response_key |
响应方做HTTP client的会话（与N32-c反方向），用于请求/响应的JWE加密 |
flowchart TD
TLS[N32-c双向认证TLS会话<br/>已建立]
TLS -->|TLS exporter<br/>Label=EXPORTER_3GPP_N32_MASTER<br/>Ctx=空, Len=64| MK[N32-f Master Key 64B]
MK --> |HKDF-Expand＜br/＞输入: 'N32'\ \ N32-Context-ID\ \ label| K1[parallel_request_key + IV salt]
MK -->|HKDF-Expand| K2[parallel_response_key + IV salt]
MK -->|HKDF-Expand| K3[reverse_request_key + IV salt]
MK -->|HKDF-Expand| K4[reverse_response_key + IV salt]
K1 -->|AES-GCM| JWE1[JWE加密: 发起方→响应方请求]
K2 -->|AES-GCM| JWE2[JWE加密: 响应方→发起方响应]
K3 -->|AES-GCM| JWE3[JWE加密: 反向会话请求]
K4 -->|AES-GCM| JWE4[JWE加密: 反向会话响应]
style MK fill:#ffd,stroke:#a80,stroke-width:2px
style TLS fill:#efe,stroke:#0a0
原文有一段意味深长的NOTE："In AES-GCM re-use of one IV may reveal the integrity key (Joux's Forbidden attack). The binding of session keys and IV salts to N32-f context IDs and labels is essential to protect against inadvertent use of the same key with a repeated IV."
AES-GCM的致命弱点是同一密钥下IV绝不能复用，否则会被Joux提出的"Forbidden Attack"恢复出认证密钥，进而可伪造任意密文。5G漫游信令量大、HTTP/2 stream可能耗尽后重建，密钥重用概率不低。3GPP的解法是把N32-f Context ID硬性绑定进KDF输入，并为每个方向、每个角色（request/response）分配独立标签——任何一次"master secret复用建立新会话"都必须生成新的、唯一的Context ID，从而保证派生出的所有密钥和IV都是全新的。这是把密码学最危险的雷区用工程约束彻底封死。
以最典型的Home-Routed漫游下的UE主认证为例：UE在VPLMN发起注册，VPLMN的AMF需要向HPLMN的AUSF/UDM请求认证向量。整个HTTP/2调用要穿越N32。
sequenceDiagram
autonumber
participant UE
participant AMF as vAMF(VPLMN)
participant vSEPP
participant IPX as IPX Provider(RI)
participant hSEPP
participant AUSF as hAUSF(HPLMN)
participant UDM as hUDM(HPLMN)
UE->>AMF: Registration Request(SUCI)
AMF->>vSEPP: HTTP/2 POST AUSF 产生认证<br/>含SUCI/SN-Name
Note over vSEPP: 重构消息<br/>SUCI→dataToIntegrityProtectAndCipher(JWE)<br/>SN-Name→dataToIntegrityProtect(明文+MAC)
vSEPP->>IPX: 转发: 明文路由区+密文敏感区+顶层MAC
Note over IPX: 可读路由字段<br/>可注入计费头(JWS签名)<br/>无法读SUCI
IPX->>hSEPP: 转发封装消息
Note over hSEPP: 验顶层MAC→用reverse/parallel key解JWE<br/>验RI的JWS→还原原始HTTP/2
hSEPP->>AUSF: HTTP/2 POST(明文,已到归属网内)
AUSF->>UDM: 拉取签约/鉴权数据
UDM-->>AUSF: 鉴权向量生成依据
AUSF-->>hSEPP: 200 OK(RAND/AUTN/XRES*, KAUSF)
Note over hSEPP: 这些敏感字段再走JWE加密回程
hSEPP->>IPX: 加密响应
IPX->>vSEPP: 转发
Note over vSEPP: 解密还原
vSEPP-->>AMF: 200 OK(明文认证向量)
AMF-->>UE: Authentication Request(RAND/AUTN)
这个实例清晰展示了PRINS的三大价值：SUPI/SUCI与认证向量对IPX全程不可见（JWE加密）、IPX仍能完成路由和计费（明文路由区+JWS签名修改）、归属侧能验证整条链路未被篡改（顶层MAC+RI的JWS）。
| 维度 | PRINS（Mechanism 1） | TLS（Mechanism 2） |
|---|---|---|
| 保护层级 | 应用层（HTTP消息体内字段级） | 传输层（整条连接） |
| 加密粒度 | 选择性：仅敏感字段JWE加密 | 全量：整个TLS载荷 |
| IPX可见性 | 可读路由/元数据字段、可JWS签名修改 | 完全不可见（黑盒隧道） |
| 中介修改认证 | JWS逐修改项签名，可追溯RI | 不支持（中介无法修改也无法认证） |
| 密钥来源 | TLS exporter→N32-KDF派生 | TLS会话密钥本身 |
| 适用场景 | 经IPX的多跳漫游（主流） | 点对点直连两PLMN、无RI路径 |
| N32-c连接 | 保持，持续承载 | 选定后拆除（13.1.2重建TLS over N32-f） |
| 性能开销 | 每消息字段级加解密，CPU较高 | TLS硬件卸载，单条流开销低 |
| 标准依据 | TS 33.501 clause 13.2 | TS 33.501 clause 13.1.2 |
实务中，绝大多数商用5G漫游采用PRINS，因为漫游的商业模式离不开IPX多跳。TLS模式更多用于两运营商直连（如两家大T之间有专线）或测试环境。
stateDiagram-v2
[*] --> IDLE
IDLE --> TLS_HANDSHAKE: 触发跨PLMN信令<br/>建立N32-c
TLS_HANDSHAKE --> CAP_NEG: 双向认证TLS完成
CAP_NEG --> KEY_EXCH: 选定PRINS(clause 13.5)
KEY_EXCH --> ACTIVE: 密钥+策略+RI信息交换完成<br/>N32-f Context建立
ACTIVE --> ACTIVE: 转发NF信令(JWE/JWS)
ACTIVE --> KEY_RENEG: 安全能力变更/密钥老化
KEY_RENEG --> ACTIVE: 重新派生密钥与Context ID
ACTIVE --> TEARDOWN: 选定TLS模式/无交集机制
CAP_NEG --> TEARDOWN: 机制无交集
TLS_HANDSHAKE --> IDLE: 认证失败/超时
TEARDOWN --> IDLE
3gpp-Sbi-Message-Id、3gpp-Sbi-Router-Scp等自定义头；N32-c流量是到/n32c-handshake/v1/exchange-capability、/n32c-handshake/v1/sec-param-exch等资源的POST。eyJ...（header）.（密文）.（IV）.（tag）的Base64URL拼接串，且{"protected":...,"encrypted_key":...,"ciphertext":...}的JOSE封装。若看到完整明文SUPI/认证向量，说明保护未生效（重大安全事件）。modifiedDataToIntegrityProtect段及其JWS签名，可定位到具体RI的修改操作。"N32"||N32-Context-ID||label是否对齐。Q1: PRINS和端到端TLS到底什么区别，为什么不直接全用TLS？ A: TLS保护整条连接，IPX中介完全看不到内容，无法路由/计费，会破坏漫游商业模式；PRINS在应用层做字段级保护，敏感字段JWE加密、路由字段明文+完整性、RI修改用JWS认证，兼顾了安全与中介可用性。
Q2: N32-c和N32-f是物理上两条线吗？ A: 不是。二者是逻辑接口，可复用同一IP/端口，但承载内容不同：N32-c承载协商信令（始终在TLS上），N32-f承载NF业务信令（按协商结果保护）。选定TLS模式后N32-c会被拆除，N32-f直接走TLS。
Q3: 为什么PRINS的密钥要绑定N32-f Context ID？ A: 防止AES-GCM的密钥/IV重用。GCM在同一密钥下复用IV会触发Joux's Forbidden Attack暴露认证密钥。把Context ID绑进KDF，每次master secret复用都生成新Context ID，保证派生密钥和IV唯一。
Q4: 漫游中UE的SUPI对IPX安全吗？
A: 安全。PRINS把SUPI/SUCI等身份与认证数据放入dataToIntegrityProtectAndCipher做JWE加密，IPX只能看到密文。若抓包发现明文SUPI，说明保护策略配置错误，属重大安全事件。
Q5: 4G漫游有SEPP吗？ A: 没有。SEPP是5G SBI架构的产物。4G漫游信令走Diameter，靠NDS/IP和IPSec逐跳保护；5G改用HTTP/2+JSON跨IPX，才催生了字段级保护的SEPP/PRINS，这是5G相对4G在漫游安全上最根本的架构升级。
本文由「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 等场景全覆盖。