How the eSIM Download Protocol Fails to Verify Identity

TLDR: Researchers at Aalto University used ProVerif to uncover critical flaws in the Consumer Remote SIM Provisioning (RSP) protocol. By exploiting the lack of a-priori knowledge of the SM-DP+ server and EID, an attacker can perform identity fraud and hijack SIM profiles. This research proves that relying solely on TLS for protocol security is insufficient when the underlying identity verification mechanisms are absent.

Mobile network operators have spent years pushing users toward eSIMs, promising convenience and a seamless digital experience. From a security perspective, however, this transition replaces a physical, tangible object with a complex, software-defined provisioning flow. When you scan a QR code to activate an eSIM, you are initiating a series of cryptographic handshakes between your device, the operator, and a provisioning server. If that handshake is flawed, the entire concept of a "secure" SIM profile evaporates.

The Illusion of Security in the RSP Protocol

The Consumer Remote SIM Provisioning (RSP) protocol is designed to be the backbone of eSIM activation. The core issue identified by the researchers is that the protocol assumes a level of trust that simply does not exist in the real world. Specifically, the activation code and default server download flows rely heavily on the assumption that the communication channel is secure, primarily through TLS.

When an attacker sits in the middle of the communication between the device and the SM-DP+ (Subscription Manager Data Preparation) server, they can manipulate the provisioning flow. The researchers modeled this using ProVerif, a tool for the formal verification of cryptographic protocols. Their findings show that when the design assumptions—specifically that all participants are honest—are violated, the protocol fails to maintain its security goals.

Why TLS Is Not Enough

Many developers treat TLS as a "magic bullet" for security. If the traffic is encrypted, they assume the data is safe. This research highlights why that mindset is dangerous. The RSP protocol uses TLS to protect the transport layer, but it fails to provide adequate authentication for the entities involved.

The vulnerability stems from two main issues:

1. Server OID Not Known: The device does not have a-priori knowledge of the SM-DP+ server's identity. If an attacker can compromise the TLS layer or redirect the traffic, the device has no way to verify that it is talking to the legitimate provisioning server.
2. EID Not Known: Similarly, the server often lacks a-priori knowledge of the device's EID (eUICC Identifier). This allows an attacker to present a victim's EID to the server, tricking it into provisioning a profile for a device the attacker does not actually own.

In a penetration test, this is a goldmine. If you can intercept the traffic, you are not just looking at cleartext; you are looking at an opportunity to inject your own provisioning instructions. By manipulating the SM-DP+ address or the EID, you can effectively force a device to download a malicious SIM profile.

Real-World Impact and Exploitation

For a bug bounty hunter or a red teamer, the implications are severe. This is essentially a modern, digital version of a SIM swap attack. In a traditional SIM swap, an attacker convinces a carrier to move a victim's number to a new physical card. Here, the attacker uses the protocol's own logic to achieve the same result without needing to talk to a human customer service representative.

The consequences are identical to those of a successful SIM swap:

• Account Takeover: Once the attacker has the SIM profile, they can intercept SMS-based two-factor authentication codes, effectively bypassing A07:2021-Identification and Authentication Failures.
• Metadata Leakage: The attacker gains access to call logs, roaming history, and potentially location data associated with the victim's mobile subscription.
• Data Interception: With home routing, an attacker can divert all mobile data traffic from the victim's device to their own infrastructure, enabling full-scale traffic analysis.

The Path Forward for Defenders

The researchers notified the GSMA of their findings. The response from the industry body confirms that while the protocol is secure between honest entities, it is highly vulnerable when endpoints are compromised. The GSMA points to the eSIM certification process as the primary mitigation.

However, for those of us in the trenches, this is a reminder that certification is not a substitute for secure design. If you are auditing mobile infrastructure or working with eUICC-enabled hardware, do not assume that the protocol handles identity verification for you. The lack of a-priori knowledge is a design flaw that cannot be patched with a simple software update; it requires a fundamental shift in how devices and servers authenticate each other during the provisioning phase.

If you are looking to dig deeper, the researchers have published their formal model on GitHub. It is a perfect starting point for anyone wanting to test their own assumptions about how these protocols behave under stress. Don't just look at the traffic; look at the logic that governs it. The most interesting bugs are often found in the assumptions that the protocol designers thought were too obvious to verify.