Comprehensive technical knowledge base covering 12 GSMA eSIM specifications. 84+ articles on Remote SIM Provisioning — SGP.02, SGP.22, SGP.32, SGP.41, SGP.29, SGP.23, SGP.25, SGP.26 and more.
🏠 eUICC.tech > SGP.22 v3.x Unified RSP > Profile Protection & BPP Security: How eSIM Profiles Stay Secret
💡 Why this matters: An eSIM profile contains your mobile network authentication keys: the cryptographic equivalent of your house keys. If an attacker could intercept a profile during download or extract it from an SM-DP+ server, they could clone your SIM and impersonate you on the network. The SGP.22 security architecture prevents this through a layered protection chain: the raw profile is first encrypted (Protected Profile Package), then cryptographically bound to a specific eUICC (Bound Profile Package), and finally delivered over an authenticated, confidentiality-protected channel. The BPP Security Protocol (BSP) : derived from GlobalPlatform’s SCP11a: is the cryptographic engine that makes this possible.
Key takeaways:
- Profiles pass through four stages: UPP → PPP → BPP → SBPP, each adding a layer of protection
- The BPP Security Protocol (BSP) provides encryption (AES-CBC-128 or SM4-CBC) and MAC authentication (AES-CMAC-128 or SM4-CMAC) for all profile data
- Key agreement uses Elliptic Curve Diffie-Hellman (ECKA) with one-time key pairs, providing Perfect Forward Secrecy
- The SM-DP+ can protect profiles in advance using random Profile Protection Keys (PPK), then bind them to a specific eUICC later: enabling scalable bulk profile generation
- Segmented BPP breaks the BPP into APDU-sized chunks (≤255 bytes each) so even memory-constrained eUICCs can receive large profiles
- The protocol cryptographically determines which algorithm set to use based on the SM-DP+ certificate’s signature algorithm: supporting NIST P-256, BrainpoolP256r1, FRP256V1, and SM2 curves
The profile’s journey from Operator specification to installed eUICC configuration passes through four distinct package formats (section 2.5.1):
Operator specification
│
▼
Unprotected Profile Package (UPP) ← Raw eUICC Profile Package TLVs
│
▼ [Profile Package Protection]
Protected Profile Package (PPP) ← Segmented + BSP-encrypted payload
│
▼ [Profile Package Binding]
Bound Profile Package (BPP) ← Prepended with key agreement + ISD-P config
│
▼ [LPA Segmentation]
Segmented Bound Profile Package (SBPP) ← STORE DATA APDU script for ES10b
Generated by the SM-DP+ from the Operator’s profile specification (section 2.5.2). The UPP consists of a sequence of Profile Element (PE) TLVs conforming to the eUICC Profile Package specification [5] : these are the raw file system, NAA keys, applets, and Security Domains that constitute the profile.
At this stage the profile is in clear text and must be protected before any transmission.
The SM-DP+ applies the BPP Security Protocol (BSP) to the UPP (section 2.5.3). The UPP is treated as a single opaque data block, split into segments of at most 1020 bytes each (including tag, length, and MAC fields). Each segment receives:
The practical payload per segment is 1007 bytes (1020 minus 1 byte tag, 3 bytes length, 8 bytes MAC, and up to 16 bytes for CBC padding with ISO/IEC 9797-1 method 2). Each data segment is tagged with '86'.
Key protection modes (section 2.5.3):
The SM-DP+ must support random key mode and should support session key mode. The eUICC must support both.
This is where the profile becomes cryptographically locked to a specific eUICC (section 2.5.4). The SM-DP+ prepends four blocks to the PPP:
InitialiseSecureChannel (clear text): Key agreement parameters: the SM-DP+ provides its one-time public key (otPK.DP.KA) and the eUICC uses it together with its own one-time key pair to derive session keys. Not encrypted, but integrity-protected by signatures.
ConfigureISDP (encrypted + MACed): Creates the ISD-P on the eUICC. Protected under session keys (S-ENC, S-MAC).
StoreMetadata (MACed only, not encrypted): Profile Metadata including Profile Policy Rules, Profile Class, service provider name, icons, and Enterprise Configuration. MACed under the session key so the eUICC can verify authenticity without needing to decrypt.
ReplaceSessionKeys (encrypted + MACed, optional): If PPKs were used for protection, this block delivers the PPKs encrypted under the session keys. The eUICC decrypts them and replaces S-ENC/S-MAC with PPK-ENC/PPK-MAC for the subsequent profile element blocks.
Profile Elements (tag '86'): The PPP segments follow: these are decrypted and MAC-verified by the eUICC.
The BPP ASN.1 structure:
BoundProfilePackage ::= SEQUENCE {
initialiseSecureChannelRequest InitialiseSecureChannelRequest,
firstSequenceOf87 SEQUENCE OF OCTET STRING, -- ConfigureISDP
sequenceOf88 SEQUENCE OF OCTET STRING, -- StoreMetadata
secondSequenceOf87 SEQUENCE OF OCTET STRING OPTIONAL, -- PPKs
sequenceOf86 SEQUENCE OF OCTET STRING -- Profile Elements
}
The LPA segments the BPP into APDU-sized chunks for transport over the ES10b interface (section 2.5.5). Each segment is at most 255 bytes: fitting within a single STORE DATA APDU command. Larger TLVs are split across multiple 255-byte blocks with a final shorter block. The block counter for STORE DATA resets at the beginning of each segment.
This segmentation is critical for memory-constrained eUICCs: the eUICC processes each APDU as it arrives and doesn’t need to buffer the entire BPP. At the end of the LoadProfileElements phase, the eUICC produces the signed Profile Installation Result.
The BSP is the cryptographic engine that protects profile data. Derived from GlobalPlatform’s SCP11a, it provides three key mechanisms:
Uses Elliptic Curve Key Agreement (ECKA) following the Anonymous Diffie-Hellman protocol from BSI TR-03111:
otPK.EUICC.KA (eUICC’s one-time public key) and otSK.DP.KA (its own one-time private key)otPK.DP.KA (SM-DP+’s one-time public key) and otSK.EUICC.KA (its own one-time private key)Both sides arrive at the same shared secret without ever transmitting it. The BSP itself does not provide authentication: that’s handled by the signature verification layers above it.
Important note: The spec calls these “one-time” rather than “ephemeral” keys because they may live longer than a single session (e.g., stored in non-volatile memory for retry scenarios). However, for Perfect Forward Secrecy purposes, they serve the same function: compromising long-term keys doesn’t reveal past session keys.
Session keys are derived from the shared secret using the X9.63 Key Derivation Function with SHA-256:
SharedInfo = KeyType(1 byte) || KeyLength(1 byte) || HostID-LV || EID-LV
KeyData = KDF(shared_secret, SharedInfo)
KeyData is then partitioned:
| KeyData bytes | Key |
|---|---|
| 1 to L | Initial MAC chaining value |
| L+1 to 2L | S-ENC (session encryption key) |
| 2L+1 to 3L | S-MAC (session MAC key) |
Where L = 16 bytes for AES-CBC-128/AES-CMAC-128 or SM4-CBC/SM4-CMAC.
The initial MAC chaining value is used for the first data block’s MAC computation. Subsequent blocks chain from the previous block’s full MAC result.
BSP defines two protection modes for individual command TLVs:
MAC and Encryption (C-ENCRYPTION + C-MAC):
'80', then '00' bytes to reach block boundary)| Compute C-MAC over: MAC chaining value | tag | final length | encrypted data |
| Output: tag | final length | encrypted data | C-MAC (8 MSB bytes) |
MAC Only (C-MAC only):
| Compute C-MAC over: MAC chaining value | tag | length | data |
| Output: tag | final length | data | C-MAC (8 MSB bytes) |
The block counter for ICV calculation increments for every segment: both encrypted and MAC-only: ensuring unique IVs for each block.
When the ReplaceSessionKeys function is executed, the session keys (S-ENC, S-MAC) are replaced with Profile Protection Keys (PPK-ENC, PPK-MAC). The initial MAC chaining value is also reset, and the data block counter for ICV returns to its initial state. This allows the BSP to seamlessly continue protecting data under the new keys.
The entire cryptographic suite for an RSP Session is determined by the SM-DP+ authentication certificate (CERT.DPauth.SIG). The signature algorithm in that certificate dictates:
| CERT.DPauth.SIG signature | Key agreement | Symmetric algorithms | Hashing |
|---|---|---|---|
| ECDSA, NIST P-256 | ECKA, NIST P-256, SHA-256 | AES-CBC-128, AES-CMAC-128 | SHA-256 |
| ECDSA, BrainpoolP256r1 | ECKA, BrainpoolP256r1, SHA-256 | AES-CBC-128, AES-CMAC-128 | SHA-256 |
| ECDSA, FRP256V1 | ECKA, FRP256V1, SHA-256 | AES-CBC-128, AES-CMAC-128 | SHA-256 |
| SM2 Signature | ECKA, SM2 Curve, SM3 | SM4-CBC, SM4-CMAC | SM3 |
An eUICC must have at least two sets of elliptic curve parameters preloaded to ensure cryptographic agility across different eSIM CAs.
The eUICC signs the final outcome of every profile installation (section 2.5.6). The result contains:
SuccessResult (with ISD-P AID and PPI response) or ErrorResult (with the failing BPP command ID, error reason, and optional PPI response)This signed result serves as cryptographic proof: the Operator can verify that a profile was (or wasn’t) installed on a specific eUICC, and on which ISD-P AID. Even if the eUICC loses power mid-installation, the result is stored in non-volatile memory.
Based on GSMA SGP.22 v3.1 (01 December 2023), Sections 2.5: Profile Protection and Delivery, and 2.6.4: BPP Security Protocol
| ← Previous: Profile Download & Installation in SGP.22 v3.x | Section Index | Next: Policy Management in SGP.22 v3.x: PPR, RAT, and the Policy Enforcer → |