Esim Javacard Security

eSIM / JavaCard Security Research

A skill for security researchers analyzing eSIM vulnerabilities, Java Card VM exploitation, and smart card security assessment.

When to Use This Skill

Use this skill when:

• Investigating eUICC (Embedded UICC) security vulnerabilities
• Analyzing Java Card Virtual Machine type-safety issues
• Testing Remote SIM Provisioning (RSP) security
• Researching smart card penetration testing methodologies
• Understanding GSMA TS.48 profile vulnerabilities
• Assessing eSIM cloning and hijacking risks
• Reviewing Java Card bytecode verification bypasses

Core Concepts

Attack Surface

1. Remote Application Management (RAM)

   • eSIM profiles embed Java Card applets
   • Provisioning via APDUs tunneled through SMS-PP or HTTPS
   • Compromised RAM keys enable remote INSTALL/LOAD of malicious applets

2. Java Card Bytecode Execution

   • Applets execute inside the VM
   • Missing runtime checks enable memory corruption
   • Type confusion primitives lead to arbitrary read/write

The Type-Confusion Primitive

The getfield/putfield instructions should only operate on object references. Vulnerable implementations skip validation, allowing:

1. Create byte-array: byte[] buf = new byte[0x100];
2. Cast to object: Object o = (Object)buf; (illegal but unverified)
3. Use putfield to overwrite 16-bit values in adjacent objects
4. Use getfield to read arbitrary memory via hijacked pointers

This provides arbitrary read/write in the eUICC address space.

Exploitation Workflow (Educational)

Step 1: Firmware Enumeration

Query undocumented GET DATA item DF1F to identify vulnerable firmware:

APDU: 80 CA DF 1F 00
Response: "ECu10.13" indicates vulnerable Kigen firmware

Step 2: Malicious Applet Installation

Abuse publicly-known keys from TS.48 Generic Test Profile (v≤6):

// LOAD command (block n)
80 E6 02 00 <data>

// INSTALL command
80 E6 0C 00 <data>

Step 3: Trigger Type Confusion

When the applet is selected, it performs write-what-where to hijack pointer tables and leak memory through APDU responses.

Step 4: Key Extraction

Private EC key is copied to applet RAM and returned in chunks via normal APDU responses.

Step 5: eUICC Impersonation

Stolen key pair + certificates enable authentication to any RSP server as a legitimate card.

Vulnerability Assessment Checklist

Pre-Engagement

• Confirm authorization for testing
• Document target eUICC model and firmware version
• Verify legal compliance with GSMA regulations

Technical Checks

• Query GET DATA DF1F for firmware string
• Inspect loaded profiles for TS.48 test profiles (v≤6)
• Check if RAM keys are publicly known
• Attempt basic cast primitive (objarrconfusion)
• Test for Security Domain private key exposure

Risk Indicators

Mitigations

Vendor-Level

1. On-card bytecode verification

   • Enforce full control-flow & data-flow type tracking
   • Not just stack-top validation

2. Hide array header

   • Place length field outside overlapping object fields
   • Prevents type confusion via field offset collision

3. Harden RAM keys policy

   • Never ship profiles with public keys
   • Disable INSTALL in test profiles
   • TS.48 v7 removes RAM keysets

Operator-Level

4. RSP server heuristics

   • Rate-limit profile downloads per EID
   • Monitor geographic anomalies
   • Validate certificate freshness

5. Profile lifecycle management

   • Keep devices off legacy test profiles
   • Apply OTA updates blocking applet loading with TS.48 v≤6
   • Remove test profiles from factory images

Automated Testing

Basic Security Check (bsc)

The bsc command reveals Java Card VM vulnerability status:

scard> bsc
castcheck        [arbitrary int/obj casts]
ptrgranularity   [pointer granularity/tr table presence]
locvaraccess     [local variable access]
stkframeaccess   [stack frame access]
instfieldaccess  [instance field access]
objarrconfusion  [object/array size field confusion]

Test Modules

• introspector – Full VM and memory explorer (~1.7 MB Java)
• security-test – Generic verification bypass applet (~150 KB)
• exploit – Kigen eUICC compromise module (~72 KB)

Cloning/Hijacking Impact

Installing the same profile on multiple devices routes traffic to whichever device most recently registered. This enables:

• Voice/SMS hijacking
• 2FA SMS interception
• Profile cloning to secondary eUICCs
• Java Card application patching (e.g., STK spyware insertion)
• Operator secret extraction

References

• Security Explorations – eSIM security
• GSMA TS.48 Generic Test Profile v7.0
• GSMA AN-2025-07 Preventing misuse of an eUICC Profile
• Java Card VM Specification 3.1

Important Notes

• This skill is for authorized security research only
• Always obtain proper authorization before testing
• GSMA regulations and local laws apply
• Vulnerabilities described are publicly disclosed and patched in updated firmware
• Focus on defensive measures and mitigation strategies