master_thesis/Chapters/RelatedWork.tex

% !TeX root = ../Thesis.tex

%*****************************************
\chapter{Related Work}\label{ch:relatedwork}
%*****************************************
\glsresetall % Resets all acronyms to not used

The ecosystem surrounding \gls{esim} and \gls{euicc} technology is supported by a combination of practical implementations and academic research. As this thesis focuses on differential testing of consumer \gls{esim} cards, it is essential to examine both established software tools that enable interaction with such cards and the existing academic efforts that analyze their security, functionality, and protocol correctness.

\section{Academic and Industry Research}

% SIMURAI
% - focuses on the possiblility of compromised / attacker controlled SIM cards
% - implemented a SIM card emulation framework consisting of: swSIM -> open source SIM and swICC -> smart Card framework
% - Research goal: find out if malicious SIM cards are a credible attack vector
% - they demonstrate their framwork by emulating SIM cards to enable fuzzing against user equipment
% - propose 2 different attack scenarios: Rouge Carrier and interposer with physical access
% - they evalute each attack scenario and propose possible mitigations
% - used their implementation to discover multiple high value memory corruption vulnerabilities inside the 
% - exploit those vulns by implementing spyware (similar to SIMjacker) that is remotly patched onto the SIM and sends information to the attacker
% - show that hostile SIMs can be used to exploit vulnerabilites and urge that hostile SIMs should be considered as serious attack vectors

% Security Analysis of the Consumer Remote SIM Provisioning Protocol
% - implement a formal modal of RSP in ProVerfiy to remotly provision SIM profiles
% - found different failure modes, however most of them assume a rather strong attacker -> e.g. TLS private key compromise, etc
% - most practical one: no method to verify user intend -> attacker can order/request profile for victim euicc from sm-dp+ -> victim may be able to download attacker ordered profile

% Transparency of SIM profiles for the consumer remote SIM provisioning protocol
% - says that the entire security of the RSP relies on the PKI in which the GSMA signs domains of sm-dp+ server
% - argues that RSP could be compromised if only a single sm-dp+ server is breached -> attacker could clone profiles
% - propose SPTS (SIM profile transparency protocol) protocol that gives more transparency to the RSP profile provisioning process
% - introduces two new actors to the protol which serve as a private index for IMSIs and a transperncy ledger which protocols each action in the RSP protocol for transparency
% - using formal security analysis of their protocol with ProVerif and develope a prototype that uses the SPTS

% osmocom euicc manual
% collection of technical information about euiccs -> collaborative effort
% collects information related to the SGP.22 specification
% offers information about available LPA implementations, known euicc cards, ATRs of some cards, known test profiles, etc

% Markus vervier took perspektive of RED team: how to leverage the esim as a c2 channel
% did not find vulnerability to use as a c2 channel
% proposes phishig via the CAT -> use proactive commands to display input and messages
% proposes maliciouse applet as feasible attack vector -> writes custom applet to fuzz proactive commands on user equipment side
% custom applet prevents user from leaving the STK until the next factory reset -> not a real vulnerability since this is intended behaviour
% proposes c2 OOB channel via sms: PoC which would allow attackers to controle a windows pc via SMS OOB 

% security exploriations demonstrate that they are able to break the security of Kigen euiccs with GSMA consumer certificates installed
% relies on physical access to the card and knowledge of the keys required to install custom java applets
% they show that using a malicious applet using the SMS-PP
% they rely on a previous type confiusion vulnerability in java card vm architecture -> Kigen implemented a fix which did not prevent the vulnerability in its entirety
% they were able to exploit this vulnerability to compromise the euicc and extract the euicc certs private keys
% they notified Kigen, GSMA, and Oracle about their findings
% as a result the GSMA address this issue in an updated TS.48 specification: prevent unauthorized actors from installing malicouse applets 
% security explorations fear that this might not be enough: argues that this doesn't fix the core problem in the java card vm architecture

% welte gives an overview on esim technology
% goes into detail on the following topics
% What is an eSIM?
% The eUICC as physical "trusted chip" inside the phone
% The 3 flavors of eSIM: Consumer, M2M and IoT
% The eSIM cryptographic chain of trust
% The invovled network elements, their purpose, procedures (SM-DP+, SM-SR, LPA/IPA, ...)
% The new IoT RSP model
% welte contributed with software (cite osmocom, pysim) and conference talks (cite conference talks from harald welte) to the mobile communication community

\texttt{Simurai} is a research framework that investigates the potential threat of compromised or attacker-controlled \gls{sim} cards~\cite{lisowski_simurai_2024}. The authors introduce a \gls{sim} card emulation system comprising two core components: \texttt{swSIM}, an open-source \gls{sim} card emulator, and \texttt{swICC}, a smart card framework. Their primary goal is to evaluate whether malicious \gls{sim} cards represent a credible attack vector against user equipment.

To support this, they demonstrate how their framework enables fuzz testing by emulating arbitrary \gls{sim} card behaviors. The study proposes two concrete attack scenarios: (1) a rogue carrier scenario, in which a malicious network operator issues hostile \gls{sim} cards, and (2) a physical card interposer attack, where an attacker inserts a interposer between the legitimate \gls{sim} and the phone. For both scenarios, the researchers conduct evaluations and suggest potential mitigations.
\marginpar{Simurai uses swSIM and swICC to emulate and fuzz SIM behavior.}

Using their emulation framework, the authors discovered multiple high-impact memory corruption vulnerabilities in baseband implementations. These were exploited via spyware-like payloads reminiscent of the \textit{SIMjacker} attack~\cite{enea_simjacker_2019}, remotely installed onto the \gls{sim} card. This spyware exfiltrates information to the attacker without requiring user interaction. Their findings underscore the seriousness of hostile SIMs as an attack vector and argue that such threat models should be incorporated into mobile security considerations.

\textcite{ahmed_security_2024} present a formal model of the \gls{rsp} protocol based on the SGP.22 specification. The model is developed using \texttt{ProVerif}~\cite{blanchet_efficient_2001} to verify the security properties of remote profile provisioning.\marginpar{Formal validation of RSP shows potential profile download attack.} Although many of the identified failure modes require strong attacker capabilities, such as compromise of \gls{tls} private keys, the study highlights a particularly practical issue: the absence of a robust mechanism to verify user intent. An attacker could initiate a profile download to a victim's \gls{euicc} without user consent, provided they have access to the device or provisioning channel, resulting in unauthorized profile installation.

\textcite{ahmed_transparency_2021} critiques the centralized trust model underlying the \gls{rsp} ecosystem. The study emphasizes that the entire trust infrastructure hinges on the \gls{pki} used by the \gls{gsma} to certify \gls{smdpp} domains. A breach of any single \gls{smdpp} server could allow an attacker to issue cloned or rogue profiles of that operator to attacker controlled \glspl{euicc}. To address this, the authors propose the SIM Profile Transparency Protocol (SPTP), a protocol designed to enhance transparency and trust in the provisioning process.
\marginpar{Compromise of an SM-DP+ server enables rogue profile injection into eUICCs.}

SPTP introduces two new entities: a private index service for managing \glspl{imsi}, and a transparency ledger that logs profile provisioning actions. Formal security analysis of the SPTP protocol using \texttt{ProVerif}, alongside a functional prototype, demonstrates that such an approach can mitigate the identified risks without significant architectural changes to the existing infrastructure.

A valuable resource for empirical research into \gls{euicc} behavior is the Osmocom \gls{euicc} Manual, a collaborative and community-maintained repository of technical knowledge \cite{welte_euicc_2024}.\marginpar{Osmocom eUICC Manual aggregates information on commercial eUICC cards.} It aggregates details related to the SGP.22 specification and serves as an empirical database of observed behavior across commercial \glspl{euicc}. The manual includes data such as known card Asnwer-To-Request (ATRs), supported \gls{lpa} implementations, available test profiles, and proprietary command sequences. Although not exhaustive, this knowledge base has proven instrumental in identifying inconsistencies and behavioral quirks in vendor-specific \gls{euicc} implementations.

In terms of adversarial perspectives, \textcite{vervier_embedded_2023} explored the potential misuse of \glspl{esim} from a red team viewpoint, particularly investigating their feasibility as covert command-and-control (C2) channels. While he did not uncover a direct vulnerability that would facilitate reliable C2 communication, he proposed several attack vectors:

\begin{itemize}
    \item \textbf{Phishing via Proactive Commands:} Leveraging the \gls{cat}, \textcite{vervier_embedded_2023} demonstrated how malicious profiles could issue proactive commands that render UI elements on the device, potentially tricking users into inputting sensitive data.
    \item \textbf{Malicious Java Applet for User Lockout:} A custom applet was developed that exploited \gls{stk} behavior to prevent users from exiting a malicious menu without performing a factory reset. Although this is technically compliant with the specification, it exemplifies how legitimate features may be repurposed for adversarial use.\marginpar{Malicious CAT commands can phish sensitive input via deceptive UI elements.}
    \item \textbf{SMS-based C2 Communication:} \textcite{vervier_embedded_2023} proposed an out-of-band C2 mechanism using SMS-PP (Point-to-Point) messages. A proof-of-concept was presented where an attacker could control a Windows machine via SMS relayed through an infected \gls{esim} card. 
\end{itemize}

A more serious security assessment was presented by \textcite{security_explorations_esim_2025}, who performed a low-level compromise of commercial Kigen \glspl{euicc}, including those with valid GSMA Consumer Profile certificates. Their attack relied on:

\begin{itemize}
    \item\textbf{Physical Access and Key Knowledge:} Required access to the physical \gls{euicc} and privileged provisioning keys to sideload custom Java applets.\marginpar{Malicious applet exfiltrated ECC private keys via SMS-PP messages.}
    \item \textbf{Java Card VM Type Confusion Vulnerability:} They exploited a known type confusion vulnerability in the Java Card virtual machine architecture \cite{security_explorations_security_2019}. Although Kigen had implemented mitigations, Security Explorations demonstrated that these were insufficient, enabling them to install a malicious applet.
    \item \textbf{Private Key Extraction via SMS-PP:} Once compromised, the applet could misuse SMS-PP functionality to exfiltrate cryptographic material, including private Elliptic-curve cryptography (ECC) keys of the \gls{euicc} certificate chain.
\end{itemize}

\textcite{security_explorations_esim_2025} responsibly disclosed the vulnerability to Kigen, GSMA, and Oracle.\marginpar{Disclosure led GSMA to update TS.48 with stricter applet installation rules.} As a result, GSMA introduced additional restrictions in the updated TS.48 specification v7.0~\cite{gsma_ts48_2025}, aiming to prevent unauthorized applet installations. However, the researchers voiced concern that this measure only mitigated the symptoms rather than addressing the core vulnerability in the Java Card VM architecture.

\textcite{welte_demystifying_2023} provides a comprehensive overview of \gls{esim} technology, covering foundational concepts such as the role of the \gls{euicc} as a secure element, the differences between the Consumer, M2M, and \gls{iot} variants of the \gls{rsp} architecture, and the cryptographic trust model underlying \gls{esim} operations. His work also outlines the responsibilities and interactions of core components like \gls{smdpp}, \gls{smds}, and the \gls{lpa}. In addition, Welte has supported the mobile communication community with practical software as well as hardware~\cite{welte_pysim_2024, welte_wireshark_nodate, osmocom_simtrace_nodate} and has delivered several conference talks~\cite{welte_osmo_remsim_2018, welte_osmocom_2016, welte_open_2025} to advance open understanding of cellular infrastructure and \gls{esim} technology.


\section{Software and Hardware Implementations}

\paragraph{pySim}

% - python tool for interacting with SIM cards and their derivitives
% - developed and maintained by osmocom -> engineer and implement tools all around SIMs i.e simtrace2 which we are also using for the tracing
% - provides 5 scripts: shell, read, prog, trace, smdpp
% - shell: main part -> provides shell like interface to move around the cards file structure and also execute application specific commands 
% - similar to shell (legacy version of shell basically): supports a small subset of the commands
% - utility to read most used fields of an SIM card
% - trace: tracing utility and decoder for SIM card related protocols -> interacts with the simtrace2 to sniff packages between the user device and the card
% - smdpp: poc implementation of the SGP.22 smdp+ server 
% - pysim is a rather complex tool to work with outside of the provided scripts when it comes to scripting -> needs lots of code to archieve little functionality, does not provide a clean programming interface to be used as a library
% - does not implement the SGP.22 communication with the card itself only the server side code
% - tracing can only be used to record traces

\texttt{pySim}~\cite{welte_pysim_2024} is a Python-based toolset designed for interacting with \gls{sim} cards and their derivatives. It is developed and actively maintained by the Osmocom project, a community of engineers focused on open-source mobile communication tools. Osmocom is also responsible for related utilities such as \texttt{simtrace2}, a hardware and software solution for tracing \gls{sim} card communication, which is utilized in this thesis for trace collection.

The \texttt{pySim} suite comprises five primary scripts: \texttt{pySim\--shell}, \texttt{pySim\--read}, \texttt{pySim\--prog}, \texttt{pySim\--trace}, and \texttt{pySim-smdpp}. Among these, \texttt{pySim\--shell} is the core component, offering an interactive shell interface to navigate the \gls{sim} card file system and issue application-specific commands. It supersedes the legacy \texttt{pySim-read} script, which only supports a limited subset of shell commands and is primarily used to extract commonly accessed data fields from \gls{sim} cards.
\marginpar{pySim is a Python toolset for interacting with SIM and eSIM cards.}
The \texttt{pySim-trace} script provides a tracing utility and protocol decoder for \gls{sim} card-related communication. It integrates with \texttt{SIMtrace2} to intercept and decode communication between a user device and the \gls{sim} card. This functionality is limited to passive recording and does not support active injection or modification of messages.

The \texttt{pySim-smdpp} script serves as a proof-of-concept implementation of the SGP.22 \gls{smdpp} server component. Notably, \texttt{pySim} does not implement the full SGP.22 protocol stack on the client side (\ie, communication between the \gls{euicc} and the \gls{smdpp} server), although its SGP.22 functionality is restricted to the server role only.

While \texttt{pySim} provides useful standalone utilities, its usability as a general-purpose library is limited. The internal architecture is not optimized for external scripting, requiring substantial effort to perform even basic tasks programmatically. As such, \texttt{pySim} is best suited for interactive use via its provided command-line tools rather than as a cleanly structured library for automation or integration.


\paragraph{SIMtrace2}

% - system consisting of software, firmware and hardware
% - main purpose: used for tracing the communication between the SIM card and some user equipment i.e phone
% - multiple different firmware version for different funcionality: trace, emulate
% - trace allows for sniffing the communication, supports t=0 protocol and operates completly passiv
% - sends sniffed apdus as udp packages to a socket from which it can be read with tools like wireshark or pySim-trace
% - osmocom also offers wireshark disector, which makes it easier and better to read
% - emulation offers card emulation for SIM cards, most commonly used for when the SIM card isn't in the device but rather some remote location or a smart card reader
% - also used by Simurai for malicous card emulation

\texttt{SIMtrace2} is a hardware platform developed by the osmocom~\cite{osmocom_simtrace_nodate} project that combines hardware, firmware, and software components to enable the monitoring and emulation of communication between a \gls{sim} card and \gls{ue}, such as a mobile phone~\cite{osmocom_simtrace_nodate}.

The primary use case of \texttt{SIMtrace2} is passive tracing of the communication between a \gls{sim} card and its host device. For this purpose, it supports multiple firmware variants, the most relevant being the \texttt{trace} and \texttt{emulate} firmware. The \texttt{trace} firmware allows passive sniffing of \gls{apdu}-level communication, operating without interfering with the ongoing exchange. It supports the T0 protocol and transmits the captured data as \gls{udp} packets to a specified socket. These packets can be analyzed using tools such as \texttt{Wireshark}, for which Osmocom provides a dedicated dissector~\cite{welte_wireshark_nodate}, or through \texttt{pySim-trace}~\cite{welte_pysim_2024}.
\marginpar{SIMtrace2 enables monitoring and emulation of SIM communication.}

The \texttt{emulate} firmware, on the other hand, provides \gls{sim} card emulation capabilities. This mode is used to simulate a \gls{sim} card that is not physically present in the device, such as in scenarios involving remote \gls{sim} access or when using a smart card reader. Notably, this emulation capability has also been employed by projects such as \textit{Simurai} for malicious card emulation and fuzzing purposes~\cite{lisowski_simurai_2024}.

Overall, \texttt{SIMtrace2} is a versatile tool both for passive analysis and active emulation of \gls{sim} card communication, making it valuable for research, debugging, and security analysis in the domain of mobile telecommunication.



\paragraph{lpac}

% - lpa implementation of the SGP.22 v2.2.2 in c from the estkme group
% - full compatiability i.e. profile provisioning, profile interaction, and notification handling
% - handles communication with card and smdp+ sever
% - is used by many lpa implementations across platforms via wrappers, used by EasyEuicc, OpenEuicc, MiniLPA, and several others
% - provides a cli to interact with
% - only supports SGP.22 v2.2.2 -> newest version is v3.1 with several new additions for IoT eSIMs and also more information are returned in already existing functions
% - established software, usablity as library improved by wrappers, doesn't offer flexibility for extending functionality -> asn decoding/encoding happens manually, no library used

\texttt{lpac} is a C-based implementation of the \gls{lpa} defined in the SGP.22, version 2.2.2, developed by the \texttt{estk.me} group~\cite{estkme_lpac_2025}. It provides full support for the required \gls{lpa} functionality, including profile provisioning, profile interaction, and notification handling. The implementation manages both the communication with the \gls{euicc} and the \gls{smdpp} server, thereby serving as a complete \gls{lpa} stack.

Due to its C-language base, \texttt{lpac} is widely adopted across various platforms through language-specific wrappers. It forms the core of several \gls{lpa} implementations, including \texttt{EasyEuicc}, \texttt{OpenEuicc}, \texttt{MiniLPA}, and others~\cite{icedtangerine_easylpac_2025, petercxy_openeuicc_nodate, esimmoe_minilpa_nodate}. It also exposes a command-line interface, allowing users to interact with the \gls{lpa} directly for debugging or automation purposes.
\marginpar{lpac is a C-based implementation of the LPA and widely adopted via wrappers.}

However, \texttt{lpac} only supports SGP.22 version 2.2.2, whereas the most recent version (3.1) introduces several enhancements, especially targeted at \gls{iot} \gls{esim} use cases, including additional return values and extended feature support \cite{gsma_sgp22_2025}. Furthermore, while the software is considered mature and widely usable, its extensibility remains limited. Key components such as \gls{asn1} decoding and encoding are implemented manually without leveraging standardized libraries like \texttt{asn1c}~\cite{walkin_asn1c_2025}.

\paragraph{SIMTester}


% SIMTester
% - java application that provides different tools to check if a specified SIM card is vulnerable against known vulnerabilities
% - finds unprotected applications and uses cryptographic signatures and encryptions of plain text
% - has own fuzzer implementation: fuzzer checks a combination of applicaation identifiers and 
% - only checks for SIM specific vulnerabilities -> not against eSIM specific applications etc i.e profile switching and provisioning

\texttt{SIMTester} is a Java-based application designed to evaluate the security posture of \gls{sim} cards by testing for a variety of known vulnerabilities~\cite{security_research_labs_simtester_2025}. It provides a suite of analysis tools that inspect the card for unprotected applications and analyze the use of cryptographic signatures and encryption mechanisms applied to plaintext communication.
\marginpar{SIMTester analyzes SIM card security and cryptographic protection mechanisms to detect unauthorized file access or improper command handling.}

One of the core components of \texttt{SIMTester} is its integrated fuzzing module. This module systematically tests combinations of \gls{aid} and command structures to detect insecure or unexpected behavior in \gls{sim} applications. This approach enables the detection of vulnerabilities such as unauthorized access to file structures or insecure command handling.

However, the scope of \texttt{SIMTester} is explicitly limited to physical \gls{sim} cards. It does not support or test \gls{esim}-specific features or functionalities, such as profile provisioning, profile switching, or remote \gls{sim} management as defined in the SGP.22 specification. As such, while useful for legacy systems and certain classes of attacks, its applicability in the context of modern \gls{esim} testing is limited.