RFC 7516
JSON Web Encryption (JWE)
Standards Track May 2015
Abstract: JWE represents encrypted content using JSON-based data structures. It provides confidentiality for JWT claims or other payloads. JWE is used in 3GPP SEPP N32-f interface for encrypting sensitive IEs in forwarded SBI messages between PLMNs.
Canonical source: https://www.rfc-editor.org/rfc/rfc7516
| IETF Datatracker
1. Introduction
▶JWE provides confidentiality for JSON-based content. While JWS only signs (integrity), JWE encrypts the payload so only authorized recipients can read it.
In 5G, JWE is used on the N32-f (forwarding) interface between SEPPs. When roaming messages transit IPX providers, sensitive Information Elements (IEs) such as SUPI, authentication vectors, and subscriber data are encrypted using JWE to prevent IPX inspection.
2. JWE Structure
▶JWE separates key management (alg) from content encryption (enc). The Content Encryption Key (CEK) is generated randomly, used to encrypt the payload, then the CEK itself is encrypted/wrapped for each recipient.
JWE Compact Serialization (5 parts):
BASE64URL(Header)
.BASE64URL(Encrypted Key)
.BASE64URL(IV)
.BASE64URL(Ciphertext)
.BASE64URL(Authentication Tag)
Header: {"alg":"ECDH-ES+A256KW","enc":"A256GCM"}
Encrypted Key: Content Encryption Key wrapped with recipient's public key
IV: Initialization Vector for content encryption
Ciphertext: Encrypted payload
Auth Tag: AEAD authentication tag 3. Key Management Algorithms
▶| Algorithm | JWA Name | Description |
|---|---|---|
| ECDH-ES | ECDH-ES | Direct ECDH key agreement (single recipient) |
| ECDH-ES+A128KW | ECDH-ES+A128KW | ECDH + AES-128 key wrapping |
| ECDH-ES+A256KW | ECDH-ES+A256KW | ECDH + AES-256 key wrapping |
| RSA-OAEP-256 | RSA-OAEP-256 | RSA with OAEP padding + SHA-256 |
| A256KW | A256KW | AES-256 key wrapping (symmetric) |
4. N32-f Usage
▶The SEPP N32-f interface uses JWE to protect sensitive IEs in forwarded SBI messages:
- N32-c negotiation: SEPPs negotiate JWE algorithms and exchange public keys via N32-c (TLS-protected)
- Selective encryption: Only sensitive IEs are encrypted — non-sensitive parts remain as metadata for IPX routing
- Combined JWS+JWE: Messages can be both signed (JWS) and encrypted (JWE) — sign-then-encrypt
- Protected IEs: SUPI, GPSI, authentication vectors, session keys, subscriber profiles
N32 Split: N32-c handles SEPP-to-SEPP security negotiation (over TLS). N32-f carries the actual forwarded SBI messages with application-layer protection (JWS for integrity, JWE for confidentiality) through IPX providers.
5. Security Considerations
▶- JWE provides confidentiality but NOT integrity by default — combine with JWS for authenticated encryption
- Key management algorithm (alg) determines how the CEK is protected — ECDH-ES provides forward secrecy
- RSA-OAEP is preferred over RSAES-PKCS1-v1_5 (vulnerable to Bleichenbacher attacks)
- Compressed payloads inside JWE can lead to CRIME-style attacks — compression should be avoided