Embedded SIMs (eSIMs), officially known as Kigen eUICC, are transforming connectivity by allowing users to switch operators without physically swapping cards. These chips store digital profiles and support secure over-the-air provisioning, a boon for smartphones, IoT devices, and connected vehicles.
Yet, Security Explorations, a cybersecurity lab within AG Security Research, recently revealed a correspondingly troubling breakthrough: they successfully executed a hacking eUICC card exploit. Their research exposes deep security flaws in hardware-protected SIM elements, forcing industry-wide reappraisal of digital SIM safety.
A Long Road to Discovery
Work began in July 2024, when Security Explorations dissected Kigen’s Java Card implementation and the chip’s secure enclave. Their process generated over 4,200 detailed internal notes, documenting vulnerabilities in how data is managed within the Java Card VM.
By March 2025, researchers had achieved a monumental breakthrough: the extraction of the eUICC’s private ECC key, a certificate-signing master credential. Documentation of this success was delivered to Kigen on March 17, with confirmation received by March 20.
They also developed a proof-of-concept (PoC) mimicking an OTA attack via the SMS-PP protocol. While it required knowledge of the internal keys, the PoC fundamentally shattered assumptions about tamper-resistant eSIM hardware.
Why Kigen eUICC Became a Target
Kigen’s embedded SIM solution is deployed globally, reportedly across two billion devices. Their Java Card VM, built on Infineon’s ARM SecurCore chip, earned EAL4+ certification under GSMA TS.48. Official statements highlighted this: Kigen claimed its eSIM OS was as secure as traditional SIM cards.
But Security Explorations proved otherwise. The hacking eUICC card exploit leveraged longstanding Java bytecode vulnerabilities, enabling:
- Extraction of the private ECC key linked to GSMA identity profiles.
- Retrieval of decrypted subscription profiles from major operators without encryption controls.
- Injection of malicious Java Card applets into existing profiles.
- Creation of cloned eSIMs capable of intercepting communications at scale.
In a notable test, two cloned phones received identical calls and messages, silently stealing communications with no user alerts.
Responsible Disclosure Timeline
Security Explorations followed a structured disclosure path:
- Mar 17, 2025: Delivered ECC key proof to Kigen.
- Mar 21: Technical advisory shared; Kigen acknowledged and began remediation.
- By Mar 31: A $30,000 reward was issued to researchers.
- Apr–Jun: Further technical guidance and lab data shared.
- Apr 7 & 10: GSMA and Oracle Java Card teams were privately notified.
- Jul 2: Full public disclosure after 90-day responsible window.
The Depth of the Threat
- Extracted eSIM Profiles in Plaintext: Once the ECC key was compromised, malicious actors could rip unencrypted eSIM profiles from operator servers, altering or cloning them with impunity.
- Complete Identity Theft: The cloned eSIMs flawlessly impersonate legitimate users, redirecting SMS, calls, and 2FA tokens without detection by users or operators.
- Hidden Backdoors: The exploit allows silencing operators through applet-level backdoors, undermining remote update controls.
- Large-Scale Impersonation: Attacks could be automated for massive eSIM theft if predictable profile identifiers are exploited.
- Dormant Legacy Flaws: The vulnerabilities stem from Java Card bytecode issues identified in 2019, dismissed at the time but proving cataclysmic when weaponized.
Kigen’s Response
Post-attack, Kigen deployed sweeping mitigations:
- ~180 bytecodes hardened with type-safety checks.
- TS.48 Test Profile rules tightened with GSMA cooperation.
- Patches applied across millions of eSIMs.
- Communications issued via GSMA’s CVD program.
Kigen reported a CVSS score of 6.7 (environmental) for the exploit, which, with network access factored in, increases to 9.1 (critical). They opted not to issue a public CVE, as reported by Security Explorations.
A Fragmented Industry Reaction
Despite GSMA’s July 9 Application Note that restricted test-profile provisioning via Remote Application Management (RAM) keys, such steps fail to tackle the root cause, weak validation in Java Card bytecode execution. GSMA still permits 44 SAS-SM provisioning sites and 74 SAS-UP identity issuers, leaving avenues for future exploits.
Security Explorations engaged GSMA on June 27, inquiring about certification limits, key custodianship, and liability in rogue provisioning contexts. GSMA’s subsequent policy note stopped short of mandating bytecode verification, leaving vendor-specific VM flaws unchecked.
Introducing the Toolkit
Researchers also released a command-line hacking toolkit featuring:
- castcheck, ptrgranularity, and objarrconfusion for VM integrity issues.
- locvaraccess, stkframeaccess, instfieldaccess for deeper memory and stack violations.
- Full support for profile extraction, modification, and OTA injection using compromised ECC keys.
Cloning, Multi-Profile Threats, and Industry-Wide Vulnerabilities
Security Explorations successfully cloned an eSIM on two smartphones, allowing a rogue device to silently intercept calls, texts, and Gmail 2FA codes, without alerting the original user.
This real-world test proved that a compromised Kigen eUICC can expose all installed profiles, especially in devices with multi-eSIM support. Though the project lacked full funding, the findings exposed deep flaws in the Java Card VM shared across vendors.
Even non-Kigen chips showed vulnerabilities, including weak type safety and poorly managed certificates. Despite Kigen’s custom VM build, it suffered similar issues due to missing bytecode checks. The success of this hacking eUICC card operation highlights the value of independent research and calls for urgent industry-wide reforms to ensure the integrity of ECC key handling and Java Card-based secure elements.
Conclusion
The hacking eUICC card exploit demonstrates that eSIMs, once considered secure due to hardware-level protections, are now vulnerable at their core, especially when Java Card VMs lack bytecode verification and memory safety. The exposure of a single ECC key can trigger global identity hijacks, undermining user privacy, SMS-based authentication, and network trust.
To counter this, the industry must treat compromise as inevitable and focus on containment through secure provisioning, rigorous OTA channel controls like SMS-PP, and continuous side-channel testing. Security can no longer rely on closed systems or vague assurances; it requires verified protections, not promises. Chipmakers, MNOs, and OEMs must align around transparent standards and thorough audits, or risk letting compromised Kigen eUICC and similar cards silently erode the foundation of digital identity worldwide.
