Security Analysis of the Consumer Remote SIM Provisioning Protocol

[ArpitxGit]

Observation from this great paper

RSP security is critical because, The Profile includes the credentials with which the mobile device will authenticate to the mobile network

a) Define eSIM as "process"? , downloading SIM Profiles into a secure element in a mobile device,

Security of the process,

i) Depends unnecessarily on it being encapsulated in a TLS tunnel,
ii) Lack of pre-established identifiers means that a compromised download server anywhere in the world or a compromised secure element can be used for attacks against RSP between honest participants.
iii) Lack of reliable methods for verifying user intent can lead to serious security failures.

[ArpitxGit]

SIM(Subscriber Identity Module) is the sE(secure element) in a mobile phone or device that contains the identifiers and cryptographic credentials with which the UE(user equipment) authenticates the mobile subscriber to the MNO(Mobile Network Operator).

Trust relations in RSP(Remote SIM Provisioning), both the SM-DP+ server and eUICC trust a common GSMA CI(certificate issuer).
The adversary has no access to any trusted participants (CI, SM-DP+ server, EUM, eUICC and MNOs). It can not obtain a certificate for an arbitrary eUICC identifier and key.

The RSP specification mainly considers a network adversary, that is, an attacker who can intercept and alter network communication between the RSP participants.

[ArpitxGit]

In contrast,
The consumer RSP Protocol requires end users to trigger management operations such as ,
Remote Provisioning, enabling, disabling and deletion of SIM profiles on the mobile device.

[ArpitxGit]

Unwanted exposure or tampering of the SIM Profile or the credentials whithin it could lead to identity theft, billing fraud, eavesdropping and various privacy violations against the mobile subscriber.

The SIM Profile contains security-critical information such as the IMSI(International mobile subscriber identity) and subscriber key Ki, which is shared between the UE(User Equipment) and the MNO.
The UE uses these credentials from the SIM profile in the (AKA)authentication and key agreement procedure to enable the subscriber's access to the mobile network.

Thus, the secure delivery of the SIM profile to the mobile device is of the utmost importance.

[ArpitxGit]

SIM vs eSIM

Traditionally, a SIM profile is provisioned to UICC(Universal Integrated Circuit Card) in the smart-card factory. Once, provisioned UICC is inserted in the UE for each mobile network subscription.
Now, the eSIM is [e]mbedded UICC + digital [SIM], where the SIM is now structured into "domains" that separate the operator profile from the security and application "domains".

"This new specification gives consumers the freedom to remotely connect devices, such as wearables, to a mobile network of their choice and continues to evolve the process of connecting new and innovative devices," Alex Sinclair, Chief Technology Officer, GSMA.

Besides, the right of independent service providers to transmit commands of loading profiles to SIM-cards in the device has been amended and the possibility to store arrays of profiles in independent certified data centres (Subscriptions manager) has appeared.

[ArpitxGit]

Security Analysis and Revelations

Insights into the protocol design and also reveals several weakness that could lead to security failures in realistic scenarios.
Formal verification under the presence of a network attacker
Analysis on protocol under partial compromise scenarios where one of the system components is not completely trustworthy.

Active Participants

1. MNO provides mobile network access to users.
2. UE connects to the mobile network.
3. LPA(Local Profile Assistant) is a software application that runs on the UE.
4. User owns the UE and has a subscription that runs on the UE.
5. eUICC , embedded secure hardware module inside the UE. Stores eSIM Profile
6. SM-DP+ server is subscription manager, creates, manage and deliver eSIM profile to respective eUICC. New Entity

[ArpitxGit]

Certificates

Multiple certificates within the protocol with different certificate policy identifiers.
Verified by the TLS layer in the client and not by the RSP protocol implementation.
GSMA CI directly issues all the server, equipment manufacturer certificates, The eUICC certificate is issued by the manufacturer.
Based on X.509 certificate chain.

1. TLS server certificate for the domain name in the server address,
2. Certificate used to authenticate the server to the eUICC.
3. Certificate that authorizes the server to issue SIM profiles.

Steps

User Intent

When a profile has been ordered and the download initiated, with a common handshake and download phase.
The MNO registers the user identity and the users's eUICC identifier and orders a profile for the specific eUICC identifier to the default server and notifier respective LPA user after profile preparation.

Profile Preparation

SM-DP+ server prepares a new SIM profile for the eUICC.
The LPA retrieves the default SM-DP+ address from the eUICC and now ready to move to the common handshake.

TLS Tunnel

The protocol takes place inside a TLS tunnel from the LPA to the SM-DP+ server for authentication but the TLS client is not authenticated.

• Communication between the MNO and the SM-DP+ server is protected with mutually authenticated TLS, The MNO is the TLS client and the SM-DP+ server is the TLS server. Trust established earlier so that both sides know the other's certified name.

❗ The method and strength of the user authentication depend on the local regulations and business decision.

Mutual Authentication

The base case, the endpoints do not have prior knowledge of each other's identities.

• The eUICC indicates its preferred CI root key which determines the elliptic curve that will that will be used for all certificates, signatures and ECDH key exchange throughout the protocol.
• The server accept any valid eUICC certificate chain that originates from the root key and the eUICC accepts any valid server the same way.
• Nonces to ensure the freshness of the auth.
• Before server pass any message to the eUICC, the LPA verifies the server identifier by matching the server name to which it created the TLS tunnel.

Provides level of channel binding between the TLS tunnel and inner authentication.

Profile Binding

• Server checks that it has a profile available for download to the eUICC.
• If it does, it signs the session identifier with the profile binding key ,
• Sends the signature together with the profile-binding certificate to the eUICC.
• eUICC verifies signature and certificate, also checks that the two server certs(different purpose) contain the same server OID(unique identifier).

Assures the eUICC that the previously authenticated server is an authorized server.

Authenticated Key Exchange

based on elliptic-curve key agreement (ECKA) , The eUICC and server generate ephemeral ECDHE key components respectively.

• The eUICC and server exchange the public components and then compute the shared secret.
• From this shared secret, they generate session keys with the key derivation function(KDF), other inputs are Server OID(unique identifier) and eUICC identifier(also unique).
• The key exchange is authenticated by the signatures and certificates.

Profile Download

Overlaps with the last authenticated key exchange.

• Server performs authentication encryption of the profile, first encrypts with key and the appends a MAC(message authentication code) computed with another key.
• Server sends the encrypted profile and the MAC to the LPA.
• Also shares MNO identifier protected with a separate MAC, to identify the respective MNO.

LPA displays the respective MNO identifier to the user, who should check that it refers to the intended operator.
After user approves the operator, the LPA forwards the information to the eUICC.
Consequently, the eUICC computes session keys, checks MACs, and decrypts the received profile.
The eUICC can now take the profile into use.

[ArpitxGit]

Assets that Require Protection

Focus is on the confidentiality and integrity of the SIM profile.
The profile is initially knows only to the SM-DP+ and MNO.
After eUICC downloads the profile, it is assumed that the server forgets that data and the eUICC stores it securely.

The Profile Contents are not modelled explicitly, contains other data, such as the subscriber and MNO identifiers,,
which require integrity protection.

Refer to this document for Profile Package Technical Specification.

[ArpitxGit]

Given the use of TLS tunnels for network communication and out-of-band authentication between the user and the MNO, we do not expect major security failures against the base-case network adversary.
Nevertheless, it is necessary to verify that the TLS tunnels and the protocols executed inside these tunnels combine to provide the desired security properties.
More importantly, we extend the network adversary in the following scenarios by modelling the compromise of selected endpoints and channels:

1. base-case: All participants are honest. The network between the LPA and SM-DP+ server is untrusted.
2. server: The adversary has all the private keys of the SM-DP+ server.
3. eUICC: The adversary has the private key SKU of the honest user’s eUICC.
4. LPA: The adversary is the user who controls the LPA, or compromised LPA software misleads the user.
5. 2nd server: The intended SM-DP+ server is honest, but there exists another compromised server.
6. 2nd eUICC: The adversary has compromised the private key of the eUICC in its own device.
7. 2nd MNO: The intended MNO is honest, but there exists another compromised MNO.
8. order as user: The adversary impersonates the honest user when ordering a profile.
9. order for eUICC: The adversary requests a profile for the honest user’s eUICC.
10. AC leak: The adversary learns the activation code associated with an ordered profile.
11. AC spoof: The adversary tricks the LPA or user to use the wrong activation code.

[ArpitxGit]

Abstractions made in the model

Cryptographic primitives including signature, key agreement, and encryption algorithms are modelled as simple rewriting rules without considering their cryptographic implementation.
Some of the message fields are abstracted away: omitted eUICC capabilities, cryptographic algorithm suites, message lengths, profile contents, and error codes.
The activation code never expires.
The eUICC certificate is issued directly by the CI (and not by the EUM), to we avoid modelling the two-certificate chain.

Verification Results

1. Failure of the SM-DP+ Server Authentication

Scenario : Server's private keys are compromised.
In the attack, the adversary plays the role of the server towards the eUICC, and the victim server does not need to be involved at all.

• This violates all the client-side correspondence properties.
• The profile secrecy goal also fails because the client accepts a fake profile created by the adversary.
• Moreover, when the victim server participates in the protocol, the attacker can cause inconsistent states between the server and eUICC by tampering with the signed messages from the server.

an adversary that has compromised an SM-DP+ server anywhere in the world can issue fake SIM profiles to any subscriber of any MNO — even if they have no business relation with the compromised server.

Root cause, The client typically lacks a-priori knowledge of the server OID. This allows the adversary to sign message with any GSMA-issued server certificate.

• The RSP protocol has the option of delivering the server OID to the client together with the activation code so that the LPA can check it after receiving message.
• Unfortunately, there is currently no similar option for the default-server approach, where the eUICC stores only the server domain name.

2. Failure of Client Authentication and Profile Secrecy

Technical failures having serious consequences later in the protocol.
Scenario : eUICC’s private key is compromised

• The eUICC authentication relies on the certificate and signature in message.
• The adversary in has the private key, and it can sign a spoofed message.
• In the activation-code approach, the adversary needs a valid activation code for the spoofed message; it can obtain one by ordering a profile for itself.

Failure of the client authentication in the key exchange, which in turn breaks the secrecy of the session key and secrecy of the profile.
In other words,
the Diffie-Hellman session key is compromised and, therefore, the SIM profile leaks to the adversary.

3. Failure Due to Identity Fraud and Leaked Activation Code

Scenario: Adversary spoofs the user identity or gains access to a legitimate activation code.

In the attack, the adversary either impersonates a legitimate user when requesting a SIM profile from the MNO or obtains the victim’s activation code through leaks or software compromise.

• The adversary can then download the victim’s profile into an adversary-owned eUICC.
• This results in the adversary gaining full access to the victim's mobile network services.

This attack leads to:

• A complete failure of the high-level client authentication goal (Auth B′), as the profile is issued and used contrary to the user’s actual intent.
• Profile secrecy is also compromised since the adversary obtains and installs a valid SIM profile linked to the victim’s account.

In practice, this enables SIM swapping, where:

• The adversary can impersonate the victim by receiving calls and messages intended for the victim.
• Services that rely on the phone number for authentication (such as banking or messaging apps) become vulnerable to unauthorized access.

Root cause, there is insufficient verification of user identity during profile ordering and poor handling of activation codes.

• In offline or phone-based orders, MNO staff may prioritize customer onboarding over security verification.

• In online or LPA-based orders, the authentication methods vary and often depend on national regulations or the MNO’s policies.

• Additionally, activation codes are treated inconsistently across the supply chain, and any leak effectively compromises the associated user identity and SIM profile.

Recommendation:
MNOs must apply strict identity verification before profile issuance.

• In the default-server approach, verification must precede the order to the SM-DP+ server.
• In the activation-code approach, verification must happen before handing out the activation code.

The RSP specification mandates secrecy of activation codes but does not explicitly enforce identity verification policies — leaving a critical gap in practical deployment.

4. Failure Due to Unauthorized Order for an eUICC

Scenario: Adversary orders a profile for someone else’s eUICC identifier.

In the attack, the adversary provides their own legitimate user identity to the MNO, but falsely claims a victim’s eUICC identifier.

• The adversary can now order a profile for a device they do not own.
• The victim may unknowingly download and install the adversary's profile, especially in the default-server approach.

This leads to:

• A failure of the client authentication goal (Auth B′) and also the full protocol authentication goal (Auth K).
• The victim ends up with a SIM profile tied to the adversary’s mobile subscription.

The consequences are serious:

• The adversary may gain control over the victim’s mobile connectivity, including the ability to intercept calls or texts.
• In extended versions of the attack, the adversary can use a different MNO (on the same SM-DP+ server) to deliver a malicious or monetized profile.
• This breaks fundamental network security properties like call confidentiality and billing integrity.

Root cause, the MNO does not verify that the user requesting the profile actually owns the eUICC identifier.

• The attack is feasible when the adversary knows the victim’s eUICC ID and does not need to prove possession.
• The real-world separation between device holder and mobile subscriber further complicates proper authorization.

Similar attacks exist in the activation-code approach:

• The adversary can inject a malicious activation code into the victim’s device (e.g., via social engineering or compromised LPA).
• If the victim installs it, they receive a profile linked to the adversary’s subscription.

Mitigations:

• Users should avoid using activation codes or LPA software from untrusted sources.
• Dual authorization (both the device holder and account owner) would help, but is currently unsupported in the RSP standard.

While the RSP already supports metadata like MNO icon and name, it lacks guidance on:

• How this information is displayed.
• What the user should compare.
• How to ensure the icons/names are trustworthy.

5. Failure Due to Misbinding Without TLS

Scenario: TLS is not used, allowing misbinding attacks during authentication.

In the attack, the eUICC performs mutual authentication with what it believes to be the authorized SM-DP+ server.
However, the adversary leverages a compromised server to confuse the identity mapping — known as a misbinding attack.

• The eUICC believes it is in a session with one server, while that server believes it is communicating with a different eUICC or another server entirely.
• This leads to a violation of the correspondence properties Auth B (client authentication) and, in some cases, Auth D.

This is not a classic man-in-the-middle or impersonation:

• Instead, the attacker causes two honest entities to mismatchedly authenticate each other, with the adversary linking them.

While secrets are not leaked in this misbinding, the practical result is:

• Confusion in the session state between legitimate participants.
• Potential service errors or user support issues due to mismatched expectations between client and server.

Root cause, the protocol lacks binding checks for identity consistency across messages:

• The eUICC does not confirm the server’s OID in early protocol messages.
• The server does not verify the eUICC identifier across authentication and profile-binding phases.

There is also a reverse misbinding vulnerability:

• The adversary intercepts a message from a legitimate eUICC, swaps its certificate with one from a compromised eUICC, and sends it to the server.
• The server responds using the identity from the swapped certificate, creating a state mismatch — violating Auth C.

This second type of misbinding is mitigated somewhat:

• The mismatch is usually detected during the key exchange (when the eUICC signs later messages), but it still represents a protocol design flaw.

Recommendations:

• Amend the RSP specification so that signed messages in initial authentication include the server OID, and recipients validate it.
• Require that the server checks that its domain name matches the expected value in the authentication process.
• Ensure the eUICC identifier from authentication is included in the signed profile-binding step, and that the eUICC verifies this identifier on receipt.

These measures would make misbinding attacks much harder and reinforce the linkage between user intent and authenticated session state — critical for preserving integrity in profile delivery.

6. TLS Tunnel Dependency

Scenario: Network adversary (scenario 1) or compromised TLS; impact on activation-code approach and profile security.

Key Issues:

• Default-server approach: Does not rely on TLS for security.
• Activation-code approach: Critically depends on TLS to protect the activation code.
  • Without TLS, the activation code can be:
    • Stolen → profile is downloaded to the wrong eUICC.
    • Replaced → client authentication is bypassed (e.g., scenario 3).

Root Causes:

1. The server doesn’t initially know the eUICC identity (𝑈).
2. The activation code is used as a secret for client authentication.
3. TLS protects that code — but if TLS is missing or compromised, attackers can misuse it.

Broader Concern:

• TLS compromise = protocol failure (seen in scenarios 2, 3, 4, 5).
• TLS isn’t just a privacy layer — it's doing core security work, which is brittle.

Recommendation:

• Redesign RSP to eliminate critical dependence on TLS.
  • Implement recommendation R1, R2, R3, R7, R9 to make the protocol robust without TLS.
  • Example changes:
    • Use signed messages with OIDs (R7).
    • Use certificate-based eUICC authentication instead of code secrecy (R3).
    • Include eUICC ID checks during profile binding (R9).

TLS should remain only as a privacy layer (e.g., to hide identifiers from network observers).
Even without TLS, privacy loss ≠ authentication failure, if other recommendations are implemented.

[ArpitxGit]

Main vulnerabilities

1. Dependence on TLS.
2. No a-priori knowledge of identifiers.
3. Misbinding vulnerability.
4. Difficulty of verifying user intent.