niklas/master_thesis
1
0
Fork 0
mirror of https://sharelatex.tu-darmstadt.de/git/681e0e7a3a9c7c9c6b8bb298 synced 2025-12-07 05:08:01 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update on Overleaf.

Browse Source
This commit is contained in:
nb72soza Bittner
2025-07-15 15:59:23 +00:00
committed by node
parent ab40f6e909
commit e702a2aa6f
11 changed files with 864 additions and 723 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
AdditionalPackages.tex
View File

@@ -83,6 +83,8 @@
% SVGs
\usepackage{svg}
\usepackage{float}
\usepackage{graphicx}
% lstlistings
\definecolor{eclipseStrings}{RGB}{42,0.0,255}
@@ -172,4 +174,4 @@
\fontdimen4\font=0.1em% interword shrink
\fontdimen7\font=0.1em% extra space
\hyphenchar\font=`\-% allowing hyphenation
}
}

26
Appendices/SomeProof.tex
View File

@@ -182,3 +182,29 @@ def run(args: argparse.Namespace) -> None:
Each subcommand module (e.g., \texttt{fuzz/data\_fuzz.py}) provides its own parser configuration and encapsulated logic, adhering to a clearly defined interface.
\section{APDU Status Word Codes}
\label{sec:sw_codes}
In the context of \gls{apdu} communication with \glspl{euicc}, each Response-APDU (R-APDU) from the card ends with a two-byte Status Word (SW), which indicates the outcome of the command execution. The SW is encoded as a 16-bit hexadecimal value and follows the ISO/IEC 7816-4 specification \cite{isoiec_isoiec_2006}.
Some SW codes contain fixed values, whereas others use placeholders (represented as \texttt{??} or \texttt{XX}) to indicate that specific bits may vary, often encoding additional information such as a retry count or the number of bytes remaining. \cref{tab:sw_codes} provides an overview of some of the most frequently observed status words.
\begin{table}[H]
\centering
\begin{tabular}{|c|p{10cm}|}
\hline
\textbf{SW Code} & \textbf{Meaning} \\
\hline
\texttt{9000} & Normal ending of the command. This indicates that the command was executed successfully and no further action is required. \\
\texttt{61XX} & Command executed successfully; \texttt{XX} bytes of data are available for retrieval using a subsequent \texttt{GET RESPONSE} command. \\
\texttt{91XX} & Command executed successfully; the card has sent a proactive command that the terminal must fetch. The \texttt{XX} indicates the length of the pending command. \\
\texttt{6A82} & File not found. This error typically occurs when the requested EF (Elementary File) or DF (Dedicated File) does not exist in the current context. \\
\texttt{6982} & Security status not satisfied. This usually implies that access conditions (e.g., PIN verification) were not met before executing the command. \\
\texttt{6D00} & Instruction code not supported or invalid. The \gls{euicc} does not recognize the INS byte of the command. \\
\texttt{6F00} & Technical problem with no precise diagnosis. Often a fallback or catch-all error code indicating an internal card error or undefined behavior. \\
\hline
\end{tabular}
\caption{Common \gls{apdu} Status Words}
\label{tab:sw_codes}
\end{table}

1315
Bibliography.bib
View File

File diff suppressed because it is too large Load Diff

76
Chapters/Background.tex
View File

@@ -5,7 +5,21 @@
%************************************************
\glsresetall % Resets all acronyms to not used
\todo{Overview of esim stack}
The \gls{esim} communication architecture consists of interrelated components distributed across the user device, the \gls{euicc}, and remote network-side infrastructure as shown in \cref{img:esim_overview}. At the heart of this system lies the \gls{lpa}, a software component running on the user device.\marginpar{eSIM architecture consists of device, eUICC, and remote infrastructure components.} The \gls{lpa} is responsible for initiating and managing the download, installation, and activation of \gls{esim} profiles. It communicates with the \gls{euicc} via a standardized \glspl{apdu}.
The \gls{euicc} is an embedded element within the device that hosts multiple functional domains. These include the \gls{isdr}, \gls{ecasd}, and \gls{aram}. Crucially, the \gls{euicc} also contains one or more profiles, each encapsulated within its own \gls{isdp}. A profile includes a file system hierarchy and applets necessary for mobile network operation.
On the network side, two entities play essential roles. The \gls{smdpp} prepares and securely delivers profile packages to the device, while the \gls{smds} acts as a directory service, enabling the device to discover available profiles.
This architecture enables secure, remote provisioning and lifecycle management of mobile subscriptions across a variety of device types, while ensuring strict isolation between profiles and robust authentication mechanisms throughout the process.\marginpar{Architecture ensures secure, remote subscription management for eSIM profiles.}
The following sections will provide a detailed analysis of each of these core components, including their roles, interfaces, and interactions in the \gls{esim} communication stack.
\begin{figure}[t]
\includesvg[width=\textwidth,inkscapelatex=false]{Graphics/esim_overview.svg}
\caption{High-level overview of the \gls{esim} communication stack.}
\label{img:esim_overview}
\end{figure}
\section{Subscriber Identity Module}
\label{sec:sim}
@@ -20,7 +34,7 @@ The \gls{sim} card is a specialized type of smart card, a form factor also emplo
Interaction with the \gls{sim} is governed by an embedded operating system \cite{etsi_ts_2022-1, globalplatform_gp_2018}, which provides a standardized file system structure for data access and application management. In addition to storing subscriber data and cryptographic keys, the \gls{sim} operating system can execute Java Card applets to extend its functionality.
Java Card applets are applications written in a restricted subset of the Java programming language, specifically tailored for execution on constrained devices. They operate within the Java Card Runtime Environment (JCRE), which itself runs inside the Java Card Virtual Machine (JCVM). This environment enables secure, platform-independent execution of custom logic directly on the \gls{sim} card, a capability that is heavily utilized in mobile network provisioning, secure authentication, and value-added services.\cite{ort_writing_2001}
Java Card applets are applications written in a restricted subset of the Java programming language, specifically tailored for execution on constrained devices.\marginpar{Applets run in a secure JCVM environment.} They operate within the Java Card Runtime Environment (JCRE), which itself runs inside the Java Card Virtual Machine (JCVM). This environment enables secure, platform-independent execution of custom logic directly on the \gls{sim} card, a capability that is heavily utilized in mobile network provisioning, secure authentication, and value-added services.\cite{ort_writing_2001}
\paragraph{Standards}
@@ -30,14 +44,14 @@ Java Card applets are applications written in a restricted subset of the Java pr
% - GSMA: defines the funcitonal systems around the eSIM to make it usable in the real-world, i.e. in the context of eSIMs: RSP, LPA, SM-DP+, etc -> later (cite SGP.22)
Identification cards such as \glspl{sim} and \glspl{esim} are fundamentally built upon the ISO/IEC 7816 standard \cite{iso_isoiec_2019}, which defines key aspects of smart cards with contacts. This includes specifications for the physical characteristics, contact positioning, electrical interface, transmission protocols, and command structure. These foundational definitions are essential for the development of both traditional \glspl{uicc} and embedded \glspl{euicc}, ensuring baseline interoperability and functionality across compliant hardware platforms.
\marginpar{SIM functionality is governed by ETSI, 3GPP, and GSMA standards.}
The operation and functionality of \gls{sim} and \gls{esim} cards are defined and governed by three major standardization bodies: \gls{etsi}, \gls{3gpp}, and the \gls{gsma}. Each of these organizations contributes distinct specifications that together form the foundation of the \gls{sim} ecosystem.
The \gls{etsi} defines the \gls{sim} card as a smart card platform. This includes specifications for the physical \gls{uicc} hardware, the structure and semantics of \gls{apdu} commands, and the internal smart card file system. Notably, the \gls{etsi} standard TS 151 011 specifies the logical structure of the file system and the behavior of elementary and dedicated files~\cite{etsi_ts_2005}.
The \gls{3gpp} focuses on how \gls{sim} cards integrate with mobile networks. This includes the specification of \gls{sim} functionalities required for network access in technologies such as LTE, 5G, and legacy systems. These standards ensure interoperability between \glspl{sim} and network infrastructure across vendors and operators.
The \gls{gsma} defines the higher-level functional architecture necessary to operationalize \gls{esim} technology in real-world deployments. This includes specifications such as the \gls{rsp} system as described in \cref{sec:rsp}, and the \gls{lpa} aswell as the \gls{smdpp} in \cref{par:euicc_components}, which together enable the remote provisioning, management, and activation of \gls{esim} profiles.
The \gls{gsma} defines the higher-level functional architecture necessary to operationalize \gls{esim} technology in real-world deployments.\marginpar{GSMA defines the eSIM architecture, including RSP, LPA, and SM-DP+.} This includes specifications such as the \gls{rsp} system as described in \cref{sec:rsp}, and the \gls{lpa} aswell as the \gls{smdpp} in \cref{par:euicc_components}, which together enable the remote provisioning, management, and activation of \gls{esim} profiles.
The \glsposs{gsma} SGP.22 specification is a cornerstone in this area, detailing the technical realization of the consumer remote \gls{sim} provisioning system~\cite{gsma_sgp22_2025}.
% 4 main specifications
@@ -118,7 +132,7 @@ The main \gls{gsma} \gls{esim} specifications can be categorized as follows:
Communication between the \gls{uicc} and the terminal is governed by transport protocols defined by the \gls{etsi} standard TS 102 221~\cite{etsi_ts_2023}. Two primary protocols are specified: \textbf{T=0} and \textbf{T=1}.
T=0 is a half-duplex, asynchronous, character-based transmission protocol. It is relatively simple in design and is widely supported across devices due to its low overhead and ease of implementation. However, it lacks advanced features such as robust error correction and support for transmitting large \glspl{apdu} efficiently.
\marginpar{UICC communication uses ETSI-defined T=0 and T=1 transport protocols.}
In contrast, T=1 is a half-duplex, asynchronous, block-oriented protocol. It introduces several enhancements over T=0, including improved error detection and correction mechanisms, \gls{apdu} chaining for handling long messages, and more flexible flow control. These improvements come at the cost of increased complexity, as T=1 includes block headers, control fields, and more elaborate state handling. Due to this additional complexity and resource requirements, T=1 is, to the best of current knowledge, rarely employed in consumer-grade \gls{sim} or \gls{esim} cards.
Given this, the remainder of this work will focus on the T=0 protocol, which remains the dominant transport protocol in commercial \gls{uicc} deployments.
@@ -134,7 +148,7 @@ Given this, the remainder of this work will focus on the T=0 protocol, which rem
% - sw with 61XX or 6CXX are used to control the exchange on the transport layer and indicate that the UICC has data to return where XX indicates the amount of bytes that are availble
% - other responses indicate errors during the command processing or execution (cite eftlabs list of apdu responses)
In smart card communication, it is essential to distinguish between the application-layer protocol and the transport-layer protocol. At the application layer, the data units are referred to as \glspl{apdu}, while at the transport layer, they are termed \glspl{tpdu}. According to \gls{etsi} specifications, outgoing commands from the terminal to the \gls{uicc} are defined as Command APDUs (C-APDU), and the responses from the UICC are defined as Response APDUs (R-APDU)~\cite{etsi_ts_2023}. On the transport layer, these correspond to Command APDUs and Response APDUs, respectively.
In smart card communication, it is essential to distinguish between the application-layer protocol and the transport-layer protocol. At the application layer, the data units are referred to as \glspl{apdu}, while at the transport layer, they are termed \glspl{tpdu}.\marginpar{APDUs/TPDUs are used for communication between UICC and terminal.} According to \gls{etsi} specifications, outgoing commands from the terminal to the \gls{uicc} are defined as Command APDUs (C-APDU), and the responses from the UICC are defined as Response APDUs (R-APDU)~\cite{etsi_ts_2023}. On the transport layer, these correspond to Command APDUs and Response APDUs, respectively.
A C-APDU consists of mandatory header fields and optional data and length fields. An R-APDU typically includes the response data followed by a two-byte status word (\texttt{SW1} and \texttt{SW2}), which indicates the result of the command execution.
@@ -170,7 +184,7 @@ A C-APDU consists of mandatory header fields and optional data and length fields
\end{tabular}
\end{table}
The status word (SW) in an R-APDU signifies whether a command was successfully processed or if an error occurred. The value \texttt{9000} is used to indicate successful execution. Other status words serve specific purposes. For instance, \texttt{61XX} or \texttt{6CXX} indicate that additional data is available, where \texttt{XX} specifies the number of bytes remaining. These codes are particularly relevant for controlling \gls{apdu} exchanges at the transport layer. Other status word values denote different error conditions related to command structure, logical access violations, or execution faults~\cite{eftlab_list_nodate}.
The status word (SW) in an R-APDU signifies whether a command was successfully processed or if an error occurred. The value \texttt{9000} is used to indicate successful execution. Other status words serve specific purposes. For instance, \texttt{61XX} or \texttt{6CXX} indicate that additional data is available, where \texttt{XX} specifies the number of bytes remaining.\marginpar{Status words indicate APDU command success or error conditions.} These codes are particularly relevant for controlling \gls{apdu} exchanges at the transport layer. Other status word values denote different error conditions related to command structure, logical access violations, or execution faults~\cite{eftlab_list_nodate}.
@@ -182,7 +196,7 @@ The status word (SW) in an R-APDU signifies whether a command was successfully p
% - it uses a TLV for the encoding of all its information -> tag indicates what kind of data follows, then length to tell the parser how much that to read for this tag, and then the actual data (provide example for BER-TLV ASN1 encoding of some short RSP message)
% - the GSMA provides ASN.1 definitions for all of its standardized functions
When interacting with a \gls{uicc}, the command payload is typically structured using \gls{asn1} encoding in the \gls{ber}-\gls{tlv} format. \gls{asn1} is a formal language used to define data structures in a way that is independent of machine-specific encoding. It is a mature and widely adopted technology, particularly within the field of telecommunications, and is standardized by the ITU-T~\cite{oss_nokalva_asn1_nodate}. Eventhough its an established encoding standard, it is still prone to be the source of bugs and security vulnerabilities \cite{nist_nvd_2024, nist_nvd_2025, mitre_cve_2003}.
When interacting with a \gls{uicc}, the command payload is typically structured using \gls{asn1} encoding in the \gls{ber}-\gls{tlv} format. \gls{asn1} is a formal language used to define data structures in a way that is independent of machine-specific encoding.\marginpar{UICC payloads are encoded using ASN.1 in BER-TLV format.} It is a mature and widely adopted technology, particularly within the field of telecommunications, and is standardized by the ITU-T~\cite{oss_nokalva_asn1_nodate}. Eventhough its an established encoding standard, it is still prone to be the source of bugs and security vulnerabilities \cite{nist_nvd_2024, nist_nvd_2025, mitre_cve_2003}.\marginpar{Despite maturity, ASN.1 encoding is a frequent source of security vulnerabilities.}
\gls{asn1} supports a variety of encoding rules. One of the most commonly used in the context of smart cards and mobile communications is the \gls{ber}. In \gls{ber}, all data is encoded as a sequence of \gls{tlv} elements. The \emph{Tag} identifies the type of data, the \emph{Length} specifies the number of bytes used for the value, and the \emph{Value} contains the actual data payload.
@@ -204,7 +218,7 @@ In this example:
\item The ten-byte \gls{iccid} value shown here (\texttt{89 10 20 30 40 50 60 70 80 90}) is an example placeholder.
\item The boolean \texttt{refreshFlag} is encoded using tag \texttt{01} and value \texttt{FF}, which represents \texttt{TRUE} in \gls{asn1}.
\end{itemize}
\marginpar{Encoded messages are sent using STORE DATA APDUs to the eUICC.}
The \gls{gsma} provides \gls{asn1} definitions for all standardized \gls{rsp} functions, including profile management procedures such as enabling or disabling profiles. These encoded messages are typically wrapped in a \texttt{STORE DATA} \gls{apdu} (instruction byte \texttt{E2}) and sent to the \gls{euicc} for execution.
@@ -225,7 +239,7 @@ The \gls{gsma} provides \gls{asn1} definitions for all standardized \gls{rsp} fu
The file system of a \gls{uicc} is organized as a hierarchical forest of trees, as specified in \cite{etsi_ts_2023}. At the top of the hierarchy resides the Master File (MF), from which Dedicated Files (DFs), Elementary Files (EFs), and \glspl{adf} originate.
DFs serve as containers that enable functional grouping of files. A special class of DF, called \glspl{adf}, encapsulates all files (EFs and optionally DFs) related to a specific application. Within these structures, EFs act as leaf nodes and contain the actual data. There are three types of EFs: transparent EFs (byte-oriented, raw data), linear fixed EFs (record-based, fixed-length records), and cyclic EFs (circular buffers).
DFs serve as containers that enable functional grouping of files. A special class of DF, called \glspl{adf}, encapsulates all files (EFs and optionally DFs) related to a specific application. Within these structures, EFs act as leaf nodes and contain the actual data.\marginpar{Files are addressed by FIDs and applications use AIDs for identification.} There are three types of EFs: transparent EFs (byte-oriented, raw data), linear fixed EFs (record-based, fixed-length records), and cyclic EFs (circular buffers).
Each file is uniquely identified by a File Identifier (FID), while applications are identified by their \gls{aid}. File paths are defined as a sequence of FIDs, typically starting from the MF or an \gls{adf}. The reserved FID \texttt{7FFF} refers to the currently selected \gls{adf}.
@@ -233,7 +247,7 @@ To access files, the \texttt{SELECT} command is used. This command supports vari
\paragraph{Application Toolkit}
The \gls{stk}/\gls{usat}, which are collectively referred to as the \gls{cat} in \gls{etsi} TS 102 223~\cite{etsi_ts_2014}, provides a proactive command framework for on-card applications. \gls{cat} functionalities are typically made available to end-users through standardized applications, known as \gls{sim} Toolkit apps that preinstalled on many mobile devices. These applications expose a menu-driven interface as shown in \cref{img:cat_interface}, that allows direct interaction with the \gls{esim} functionality embedded in the card, without requiring any additional software or manufacturer-specific \glspl{lpa}. However, the amount of functionality provided over such interfaces still depends on the manufacturer and the implementation.
The \gls{stk}/\gls{usat}, which are collectively referred to as the \gls{cat} in \gls{etsi} TS 102 223~\cite{etsi_ts_2014}, provides a proactive command framework for on-card applications. \gls{cat} functionalities are typically made available to end-users through standardized applications, known as \gls{sim} Toolkit apps that preinstalled on many mobile devices. These applications expose a menu-driven interface as shown in \cref{img:cat_interface}, that allows direct interaction with the \gls{esim} functionality embedded in the card, without requiring any additional software or manufacturer-specific \glspl{lpa}.\marginpar{SIM Toolkit apps expose CAT menus for user-driven card operations without the need for an LPA.} However, the amount of functionality provided over such interfaces still depends on the manufacturer and the implementation.
The original \gls{stk}, introduced in \gls{etsi} 11.14~\cite{etsi_gsm_1997}, targets GSM \glspl{sim}, while the \gls{usat}, defined in \gls{etsi} TS 131 111~\cite{etsi_ts_2020}, extends these capabilities for \gls{uicc}/\gls{usim} environments. \gls{cat} unifies \gls{stk} and \gls{usat} under a single umbrella for all \gls{uicc}-based toolkits. These toolkits enable on-card applets to interact with the user equipment, displaying menus, sending SMS, downloading data, or even initiating \gls{esim} profile operations such as renaming or activation. Projects like \texttt{estk.me} have further enhanced this interface with “cloud-enhanced” \gls{rlpa}, which allows users to initiate profile provisioning directly via \gls{cat} menus without a separate \gls{lpa} client~\cite{estkme_rlpa-server_2025}. Other provisioning methods typically require a dedicated \gls{lpa} application on the device and cannot be facilitated through the \gls{cat} interface.
\begin{figure}[t]
@@ -254,7 +268,7 @@ The original \gls{stk}, introduced in \gls{etsi} 11.14~\cite{etsi_gsm_1997}, tar
The concept of the \gls{esim} is based on the \gls{euicc}, which replaces the traditional removable SIM card form factor with a soldered chip that remains permanently embedded within the device.
Historically, the subscriber identity and related credentials were bound to a physical \gls{uicc} during the manufacturing process. This physical coupling meant that changing network operators or updating credentials required the replacement of the \gls{sim} card itself. The \gls{esim} paradigm disrupts this model by decoupling the subscription identity from the physical card. Instead, subscriber credentials, including applications such as \gls{usim}, \gls{isim}, and their associated file systems, are now encapsulated within a virtual entity referred to as an \textit{eSIM profile}.
Historically, the subscriber identity and related credentials were bound to a physical \gls{uicc} during the manufacturing process. This physical coupling meant that changing network operators or updating credentials required the replacement of the \gls{sim} card itself. The \gls{esim} paradigm disrupts this model by decoupling the subscription identity from the physical card.\marginpar{eSIM decouples identity from hardware via remotely managed virtualized profiles.} Instead, subscriber credentials, including applications such as \gls{usim}, \gls{isim}, and their associated file systems, are now encapsulated within a virtual entity referred to as an \textit{eSIM profile}.
These profiles reside on the underlying \gls{euicc} hardware and can be provisioned, activated, and managed remotely. Profile management is facilitated through standardized components defined by the \gls{gsma}, most notably the \gls{smdpp} and \gls{smds} servers. Profiles can either be delivered in a passive manner through the \gls{smdpp} when triggered by the end user, often via the \gls{lpa}, or actively pushed to the device through the \gls{smds} as shown in \cref{img:rsp_architecture}.
@@ -281,18 +295,18 @@ This architecture introduces a remote provisioning mechanism and significantly e
To manage, store, and control \gls{esim} profiles, the \gls{euicc} hosts several critical applications and system components. These include the \gls{isdr}, \gls{isdp}, \gls{ecasd}, optionally the embedded \gls{lpa}, \gls{aram}, and various \gls{lpa} service interfaces as shown in \cref{img:euicc_architecture}.
The \gls{ecasd} provides secure storage and cryptographic services. It maintains sensitive credentials such as the \gls{euicc} private key and certificate, the \gls{eid}, the \gls{eum} certificate, and the manufacturer key set used for credential updates. It is also responsible for generating digital signatures on data received from the \gls{isdr} and for verifying certificates during the authentication of the \gls{smdpp} or other remote entities.Typically, the stored certificates and cryptographic keys within the \gls{ecasd} are immutable and cannot be updated, and as a result, they are provisioned with a validity period of approximately 25 years \cite{welte_euicc_2024}.
The \gls{ecasd} provides secure storage and cryptographic services. It maintains sensitive credentials such as the \gls{euicc} private key and certificate, the \gls{eid}, the \gls{eum} certificate, and the manufacturer key set used for credential updates. \marginpar{ECASD securely stores keys, certificates, and handles crypto operations.} It is also responsible for generating digital signatures on data received from the \gls{isdr} and for verifying certificates during the authentication of the \gls{smdpp} or other remote entities.Typically, the stored certificates and cryptographic keys within the \gls{ecasd} are immutable and cannot be updated, and as a result, they are provisioned with a validity period of approximately 25 years \cite{welte_euicc_2024}.
The \gls{isdr} acts as the primary control authority on the \gls{euicc}. It manages the creation, activation, deactivation, and deletion of \glspl{isdp}. Only one of either \gls{isdr} or \gls{ecasd} can be present on a single \gls{euicc}, depending on the \gls{euicc}'s implementation mode.
The \gls{isdr} acts as the primary control authority on the \gls{euicc}. It manages the creation, activation, deactivation, and deletion of \glspl{isdp}.\marginpar{ISD-R controls profile lifecycle: creation, activation, deletion, and switching.} Only one of either \gls{isdr} or \gls{ecasd} can be present on a single \gls{euicc}, depending on the \glsposs{euicc} implementation mode.
Each \gls{isdp} hosts exactly one \gls{esim} profile and is responsible for profile download and installation. \glspl{isdp} may additionally host applets specific to the mobile network operator or service provider. An \gls{euicc} can have multiple \glspl{isdp} to have multiple profiles installed at the same time. Each \gls{isdp} must have it's own unique \glspl{aid}.
The \gls{aram}, as specified by \gls{gp} \cite{globalplatform_secure_2024}, governs access control for applications on the Secure Element. It aggregates access rules from multiple possible sources on the Secure Element and provides them in a standardized form. These rules are defined by the Secure Element issuer, typically the device manufacturer, during the \gls{euicc} manufacturing process and can restrict which device-side applications are permitted to communicate with the \gls{euicc} and its applets.
The \gls{aram}, as specified by \gls{gp} \cite{globalplatform_secure_2024}, governs access control for applications on the Secure Element.\marginpar{ARA-M enforces access rules for manufacturer defined LPA’s.} It aggregates access rules from multiple possible sources on the Secure Element and provides them in a standardized form. These rules are defined by the Secure Element issuer, typically the device manufacturer, during the \gls{euicc} manufacturing process and can restrict which device-side applications are permitted to communicate with the \gls{euicc} and its applets.
Together, these components establish the trust and management architecture necessary for secure and scalable remote SIM provisioning.
These applications are typically addressed via their \glspl{aid}, some of which are standardized by the \gls{gsma} and \gls{gp} to ensure interoperability across implementations, others are defined by the \gls{mno}. Standardized \glspl{aid} allow external entities, such as the \gls{lpa}, to reliably identify and interact with specific applications on the card.
\marginpar{AIDs may be vendor-specific and are often modified in practice.}
\begin{itemize}
\item \gls{isdr}: \texttt{A0000005591010FFFFFFFF8900000100}
\item \gls{aram}: \texttt{A00000015141434C00}
@@ -319,7 +333,7 @@ However, the actual \glspl{aid} used are implementation-specific and may be cust
% - estk.me also implemented rlpa (remote lpa or as they call it cloud enhance) -> allows the user to provision profiles via the stk / usat menu (cite cloud rlpa-server)
% other options to provision profiles require an lpa client on the ue / terminal
In many modern devices, the most common integration of an \gls{esim} is as a soldered chip on the printed circuit board of a smartphone. Because these embedded chips are functionally identical to traditional removable \gls{sim} cards—apart from the \gls{esim} operating system, which is supplied by the \gls{eum} and can also be packaged as “physical \glspl{esim}” in standard form-factors (2FF, 3FF, 4FF). This enables even non-eSIM–capable devices to use remotely provisioned profiles without hardware changes. To date, physical \glspl{esim} in these sizes are produced by vendors such as Kigen, Estcompeace, and Giesecke+Devrient.
In many modern devices, the most common integration of an \gls{esim} is as a soldered chip on the printed circuit board of a smartphone.\marginpar{eSIM-on-SIM implementations enable use in legacy devices are equivalent to soldered eSIM`s.} Because these embedded chips are functionally identical to traditional removable \gls{sim} cards, apart from the \gls{esim} operating system, which is supplied by the \gls{eum} and can also be packaged as “physical \glspl{esim}” in standard form-factors (2FF, 3FF, 4FF). This enables even non-eSIM–capable devices to use remotely provisioned profiles without hardware changes. To date, physical \glspl{esim} in these sizes are produced by vendors such as Kigen, Estcompeace, and Giesecke+Devrient.
\paragraph{Local Profile Assistant}
@@ -334,7 +348,7 @@ In many modern devices, the most common integration of an \gls{esim} is as a sol
\label{img:lpa_interfaces}
\end{figure}
The \gls{lpa} is a user-facing application (i.e an App on a smartphone) on the \gls{ue} that interacts with the \gls{euicc}, enabling users to initiate profile provisioning and perform lifecycle management operations such as enabling, disabling, or deleting profiles. \cref{img:lpa_interfaces} shows 3 different \gls{lpa} implementions that enable such functionality. The \gls{smdpp} is a server—operated by an \gls{euicc} manufacturer, \gls{mno}, or third party, that securely hosts \gls{esim} profiles and makes them available for download. The \gls{smds} facilitates the "push" provisioning approach, where the operator notifies the \gls{lpa} via the \gls{smds} that an profile is ready download. The \gls{lpa} then downloads and installs this profile from the \gls{smdpp} server onto the \gls{euicc} with the information provided by the \gls{smds}. This approach is less common in consumer scenarios.
The \gls{lpa} is a user-facing application (i.e an App on a smartphone) on the \gls{ue} that interacts with the \gls{euicc}, enabling users to initiate profile provisioning and perform lifecycle management operations such as enabling, disabling, or deleting profiles. \cref{img:lpa_interfaces} shows 3 different \gls{lpa} implementions that enable such functionality.\marginpar{The LPA is a user-facing app for managing eSIM profiles.} The \gls{smdpp} is a server—operated by an \gls{euicc} manufacturer, \gls{mno}, or third party, that securely hosts \gls{esim} profiles and makes them available for download. The \gls{smds} facilitates the "push" provisioning approach, where the operator notifies the \gls{lpa} via the \gls{smds} that an profile is ready download. The \gls{lpa} then downloads and installs this profile from the \gls{smdpp} server onto the \gls{euicc} with the information provided by the \gls{smds}. This approach is less common in consumer scenarios.
\begin{figure}[t]
\includegraphics[width=\textwidth]{Graphics/rsp_architecture.png}
@@ -392,22 +406,22 @@ Interface when LPA is in the Device (LUId), are collectively simplified and refe
% - when success response: notification is deleted from euicc
% - profile provisioning is finished
One of the most significant advantages of \glspl{esim} is the ability to download and install profiles remotely without physically swapping the card. This process, known as \gls{rsp}, is defined by the \gls{gsma} in specification SGP.22~\cite{gsma_sgp22_2023, gsma_sgp22_2024, gsma_sgp22_2025}. The key components of the \gls{rsp} ecosystem are the \gls{lpa}, the \gls{smdpp}, and, to a lesser extent in consumer deployments, the \gls{smds}.
One of the most significant advantages of \glspl{esim} is the ability to download and install profiles remotely without physically swapping the card. This process, known as \gls{rsp}, is defined by the \gls{gsma} in specification SGP.22~\cite{gsma_sgp22_2023, gsma_sgp22_2024, gsma_sgp22_2025}.\marginpar{RSP enables eSIM profile provisioning.} The key components of the \gls{rsp} ecosystem are the \gls{lpa}, the \gls{smdpp}, and, to a lesser extent in consumer deployments, the \gls{smds} as shown in \cref{img:rsp_architecture}.
SGP.22 defines three \gls{rsp} initiation methods:
\begin{enumerate}
\item \textbf{Default Server}: The \gls{smdpp} address is pre-configured on the \gls{euicc} at manufacture time and points to a operator controlled server. The user triggers provisioning via the default server if no other address is given by the profile.
\item \textbf{Default Server}: The \gls{smdpp} address is pre-configured on the \gls{euicc} at manufacture time and points to a operator controlled server. The user triggers provisioning via the default server if no other address is given by the profile. \marginpar{SGP.22 defines three RSP initiation methods: Default Server, Authentication Code, and SM-DS Assisted provisioning.}
\item \textbf{Authentication Code}: The user is provided with an activation code (containing the \gls{smdpp} address and optional confirmation code) when purchasing service. The \gls{lpa} contacts the \gls{smdpp} and, after mutual authentication, may require entry of the confirmation code.
\item \textbf{\gls{smds} Assisted}: The \gls{lpa} polls the \gls{smds} for an event matching the \gls{eid} of the \gls{euicc}. If a download event exists, the \gls{smds} supplies the \gls{smdpp} address to the \gls{lpa} for profile download.
\end{enumerate}
In this work, we focus on the Authentication Code method due to its prevalence in commercial \gls{esim} deployments and the ready availability of test activation codes—critical for our differential-testing and fuzzing methodology (see~\cref{sec:fuzzing})
In this work, we focus on the Authentication Code method due to its prevalence in commercial \gls{esim} deployments and the ready availability of test activation codes, critical for our differential-testing and fuzzing methodology (see~\cref{sec:fuzzing})
\textcite{ahmed_security_2024} packages the \gls{rsp} into four major steps: mutual authentication, profile binding, profile download (including authenticated key exchange), and notification.
\begin{figure}[t]
\begin{adjustwidth}{-1.5in}{-.5in}
\begin{adjustwidth}{-.5in}{-1.5in}
\centering
\includesvg[width=1.3\textwidth]{Graphics/mutual_authentication_sd.svg}
\caption{Sequence diagram of the mutual authentication.\cite{ahmed_security_2024}}
@@ -441,7 +455,7 @@ In this work, we focus on the Authentication Code method due to its prevalence i
\paragraph{Mutual Authentication}
As \cref{fig:mutual_authentication} shows, the \gls{rsp} process begins with mutual authentication between the \gls{euicc} and \gls{smdpp} over a \gls{tls} tunnel established via the \gls{lpa}. The \gls{euicc} generates a random challenge $N_U$ and sends it, along with its \gls{ci} Root public key certificate $SKI_{CI}$, to the \gls{smdpp}. The \gls{smdpp} responds with a signed version of the challenge $N_U$, its own certificate subject $S$, a transaction identifier $I_t$, and a server challenge $N_S$. The \gls{euicc} verifies the signature and certificate chain, signs the activation code’s profile identifier $I_{ac}$ (and other protocol elements), the transaction identifier $I_t$, the server challenge $N_S$, and relevant addresses, then returns this to the \gls{smdpp}. Based on the profile identifier, the \gls{smdpp} selects the appropriate profile for download.
As \cref{fig:mutual_authentication} shows, the \gls{rsp} process begins with mutual authentication between the \gls{euicc} and \gls{smdpp} over a \gls{tls} tunnel established via the \gls{lpa}. The \gls{euicc} generates a random challenge $N_U$ and sends it, along with its \gls{ci} Root public key certificate $SKI_{CI}$, to the \gls{smdpp}.\marginpar{Mutual authentication is performed between eUICC and SM-DP+ through the LPA.} The \gls{smdpp} responds with a signed version of the challenge $N_U$, its own certificate subject $S$, a transaction identifier $I_t$, and a server challenge $N_S$. The \gls{euicc} verifies the signature and certificate chain, signs the activation code’s profile identifier $I_{ac}$ (and other protocol elements), the transaction identifier $I_t$, the server challenge $N_S$, and relevant addresses, then returns this to the \gls{smdpp}. Based on the profile identifier, the \gls{smdpp} selects the appropriate profile for download.
\paragraph{Profile Binding}
@@ -451,11 +465,19 @@ Upon successful authentication, the \gls{smdpp} checks for profile availability
Next, the \gls{euicc} and \gls{smdpp} perform an \gls{ecka} to derive session keys. The \gls{smdpp} encrypts the profile using the session key and transmits it to the \gls{euicc}. The \gls{euicc} configures the new \gls{isdp}, decrypts the profile, and installs it. The profile is then ready for use.
\todo{Explain what sequenceOf87, sequenceOf88, etc is because we are using this later on}
During the installation, a specific sequence of packages is exchanged between the \gls{smdpp} and the \gls{euicc}:
\marginpar{eUICC installs the profile and prepares the ISD-P.}
\begin{enumerate}
\item A secure channel is initialized using the \texttt{initialiseSecure\-Channel} package.
\item The \gls{isdp} is configured via the \texttt{firstSequence\-Of87} package.
\item Profile metadata is stored in the \gls{isdp} using the \texttt{sequence\-Of88} package.
\item Dession keys are replaced by profile-specific Profile Protection Keys using the \texttt{second\-Sequence\-Of87} package.
\item The actual profile elements are loaded using the \texttt{sequence\-Of86} package.
\end{enumerate}
\paragraph{Notification}
After installation, session keys are erased and the \gls{euicc} generates a signed installation notification containing a sequence number and server address. The \gls{lpa} forwards this notification to the \gls{smdpp}, and upon receiving a success response, the \gls{euicc} removes the notification, completing the provisioning cycle.
After installation, session keys are erased and the \gls{euicc} generates a signed installation notification containing a sequence number and server address.\marginpar{LPA processes the notification, completing the provisioning process.} The \gls{lpa} forwards this notification to the \gls{smdpp}, and upon receiving a success response, the \gls{euicc} removes the notification, completing the provisioning cycle.
\section{Fuzzing}
@@ -481,7 +503,7 @@ After installation, session keys are erased and the \gls{euicc} generates a sign
% other option: use differential testing -> compare output of two programs that should behave the same when giving the same input
% we cant inject assertions -> opted for option 2 i.e differntial testing
Fuzzing is a well-established technique for uncovering software bugs and security vulnerabilities through the automated generation of test inputs. It has contributed to the discovery of thousands of critical security issues~\cite{arya_oss-fuzz_2025} across various domains. The fundamental principle behind fuzzing is to provide a target system with a large number of automatically generated inputs, ranging from completely random to well-structured, and monitor the system's behavior for anomalies such as crashes, unexpected outputs, or assertion failures.
Fuzzing is a well-established technique for uncovering software bugs and security vulnerabilities through the automated generation of test inputs. It has contributed to the discovery of thousands of critical security issues~\cite{arya_oss-fuzz_2025} across various domains.\marginpar{Fuzzing uncovers bugs by feeding systems large volumes of generated test inputs.} The fundamental principle behind fuzzing is to provide a target system with a large number of automatically generated inputs, ranging from completely random to well-structured, and monitor the system's behavior for anomalies such as crashes, unexpected outputs, or assertion failures.
Traditionally, fuzzers attempt to explore edge cases and increase code coverage, aiming to execute as many distinct code paths as possible. Depending on the level of insight into the internal structure of the system under test, fuzzers are commonly classified into three categories \cite{chen_systematic_2018}:
@@ -494,7 +516,7 @@ Traditionally, fuzzers attempt to explore edge cases and increase code coverage,
\end{itemize}
A critical aspect of effective fuzzing is the ability to differentiate between expected and unexpected behavior. In traditional fuzzing scenarios, this is often accomplished using sanitizers and runtime assertions, which cause the target program to fail explicitly when a bug is detected. However, such instrumentation is typically infeasible in closed-source or hardware-backed environments such as commercial \gls{esim} implementations~\cite{zaddach_avatar_2014}.
\marginpar{This work uses differential testing to detect inconsistencies across implementations.}
Given these constraints, this thesis adopts a \textit{differential testing} approach to fuzzing. Instead of relying on internal instrumentation or assertions, the framework can compare the responses of multiple independent implementations of the same specification to identical fuzzed inputs. Any divergence in the observed behavior may indicate a potential bug, inconsistency in interpretation of the specification, or a security-relevant anomaly.
This methodology is particularly well-suited for black-box systems like eSIM-on-SIM cards, where internal state and logic are inaccessible.

7
Chapters/Design.tex
View File

@@ -65,6 +65,7 @@ This section introduces the core design of our differential testing framework \s
\item Mutating protocol-level inputs to explore edge cases and verify robustness,
\item Comparing card responses under similar inputs to identify differences.
\end{itemize}
\marginpar{\sysname is the differential testing framwork for eSIM analysis}
To achieve these goals, we propose a modular three-layered architecture:
@@ -80,6 +81,7 @@ To achieve these goals, we propose a modular three-layered architecture:
The first design focuses on capturing and replaying real interaction sequences between an \gls{lpa} and a target \gls{euicc}. This allows deterministic replay of recorded \gls{apdu} sequences on different cards for side-by-side comparison.
\paragraph{Design Rationale.} Real-world traces provide insights into how \glspl{euicc} are used in practice, including undocumented behavior not covered by specifications. Replaying identical \gls{apdu} sequences across cards enables direct differential testing. To ensure realistic conditions, the setup is designed to remain as close as possible to the original communication path between \gls{lpa} and \gls{euicc}.
\marginpar{Design 1 replays real LPA–eUICC interactions for side-by-side card comparison.}
\paragraph{Key Components.}
\begin{itemize}
@@ -96,6 +98,7 @@ The first design focuses on capturing and replaying real interaction sequences b
The second design focuses on exploring the input space of the \gls{euicc} \gls{rsp} protocol stack by mutating valid \glspl{apdu}. The aim is to test robustness against malformed, unexpected, or edge-case inputs and to expose implementation-level inconsistencies.
\paragraph{Design Rationale.} While real traces offer insight into typical usage, they often fail to reveal vulnerabilities related to invalid inputs. \gls{apdu} fuzzing is essential for testing the correctness of error handling and boundary enforcement.
\marginpar{Design 2 mutates valid APDUs to test eUICC robustness and correctness by comparing recorded behavior.}
\paragraph{Key Components.}
\begin{itemize}
@@ -103,7 +106,7 @@ The second design focuses on exploring the input space of the \gls{euicc} \gls{r
\item \textbf{Mutation Engine:} Valid \glspl{apdu} are mutated using deterministic and randomized strategies, including bit-flipping, truncation, data zeroing, byte replacement, and block shuffling.
\item \textbf{Mutation Tree Representation:} The fuzzer constructs a hierarchical tree representing each function call, input mutation, and observed result, supporting exhaustive and resumable test runs.
\item \textbf{Exception-Aware Runner:} Each test is isolated, and card resets are used to restore a clean state, preventing a single failure from corrupting the session.
\item \textbf{Comparison Engine:} Results from multiple \glspl{euicc} are compared node-by-node. Deviations in status words, exceptions or data are reported and visualized to highlight divergent execution paths.
\item \textbf{Comparison:} Results from multiple \glspl{euicc} are compared node-by-node. Deviations in status words, exceptions or data are reported and visualized to highlight divergent execution paths.
\end{itemize}
\paragraph{Motivation.} \gls{apdu} fuzzing allows systematic probing of error-handling logic, \gls{asn1} decoding boundaries, and specification ambiguities. The use of deterministic strategies supports reproducibility and enables direct comparison across different cards.
@@ -114,6 +117,7 @@ The second design focuses on exploring the input space of the \gls{euicc} \gls{r
The third design targets application-level logic using structurally valid inputs. It leverages property-based testing to exercise schema-conformant payloads and detect semantic inconsistencies or robustness issues.
\paragraph{Design Rationale.} Data fuzzing explores the validity boundaries of specific protocol fields. Unlike raw \gls{apdu} mutation, it focuses on high-level, syntactically valid but semantically unusual inputs to stress the logic of the \gls{lpa}-\gls{euicc} interaction.
\marginpar{Design 3 targets semantic correctness using schema-conformant, high-level input fuzzing.}
\paragraph{Key Components.}
\begin{itemize}
@@ -155,6 +159,7 @@ Each of the three design strategies presented in this chapter targets a differen
\textbf{Tracing and Replay} focuses on the deterministic reproduction of real-world \gls{lpa}-\gls{euicc} sessions. By replaying fully valid \gls{apdu} sequences captured from live devices, this strategy ensures strict behavioral equivalence and reproducibility. However, it is limited in its ability to explore malformed or edge-case inputs.
\textbf{APDU-Level Fuzzing} extends this foundation by introducing structured mutations into valid \glspl{apdu}. It strikes a balance between input validity and exploratory depth, allowing the framework to probe robustness, error-handling routines, and implementation-specific divergences while still supporting comparative analysis across multiple \glspl{euicc}.
\marginpar{Each design targets a distinct dimension of eUICC differential testing and by combination yields a broad, modular fuzzing and testing framework.}
\textbf{Structured Data Fuzzing}, finally, operates at the semantic layer by generating well-formed but edge-case-rich inputs for application-level interfaces. This approach excels at uncovering logic flaws and inconsistencies in the parsing and interpretation of complex data structures, particularly those encoded in \gls{asn1}.

39
Chapters/Evaluation.tex
View File

@@ -14,14 +14,15 @@
% estk.me does not offer an isd-r for regular interaction with our lpa implmenetation -> tesing is limited
% 9esim v2 offers both -> only testing isd-r not USAT for RSP related communication
The primary objective of this evaluation is to apply differential testing to analyze the behavior and potential security implications of various commercial eSIM on SIM solutions. This methodology aims to uncover inconsistencies, implementation deviations, and potential vulnerabilities by observing how different cards react to the same input sequences under controlled conditions.
To conduct a thorough and representative evaluation, we selected a diverse set of eSIM-on-SIM cards from multiple vendors. In total, \textbf{eight} different cards were included in the analysis, as shown in Table~\ref{tab:esim-overview}. These cards vary in terms of manufacturer, supported features, and firmware versions. The tests were conducted using the tracing, mutation, and fuzzing infrastructure described in \cref{ch:implementation}.
% experiments were conduct on a host machine running arch linux (6.15.5-zen)
% 32 GB of RAM, and and Ryzen 7 5800x
% smart card reader is the HID OMNIKEY 3121 USB in combination with sysmocom smart card adapter v1
% smartcard middleware library: pcsclite 2.3.3-1
The primary objective of this evaluation is to apply differential testing to analyze the behavior and potential security implications of various commercial eSIM on SIM solutions. This methodology aims to uncover inconsistencies, implementation deviations, and potential vulnerabilities by observing how different cards react to the same input sequences under controlled conditions.
\marginpar{Eight commercial eSIM-on-SIM cards from different vendors were selected for analysis.}
To conduct a thorough and representative evaluation, we selected a diverse set of eSIM-on-SIM cards from multiple vendors. In total, \textbf{eight} different cards were included in the analysis, as shown in Table~\ref{tab:esim-overview}. These cards vary in terms of manufacturer, supported features, and firmware versions. The tests were conducted using the tracing, mutation, and fuzzing infrastructure described in \cref{ch:implementation}.
All experiments were conducted on a host machine running Arch Linux (kernel version \texttt{6.15.5-zen}), equipped with an AMD Ryzen 7 5800X CPU and 32\,GB of RAM. For smart card interfacing, we used the HID OMNIKEY 3121 USB smart card reader in combination with the sysmocom Smart Card Adapter v1. The middleware stack was based on \texttt{pcsclite} version \texttt{2.3.3-1}, providing the PC/SC interface for APDU-level communication with the inserted \glspl{euicc}.
\begin{table}[ht]
@@ -47,7 +48,7 @@ All experiments were conducted on a host machine running Arch Linux (kernel vers
Among the tested cards, the \textbf{sysmoEUICC} is loaded with a \gls{gsma} test certificate, allowing it to interact with the official \gls{smdpp} test server infrastructure. This certificate is publicly available and enables the evaluation of remote profile management procedures in a realistic but controlled environment. The firmware implementation of the sysmoEUICC is assumed to be functionally equivalent to production-grade \glspl{esim}. However, this restricts use to use Profiles which are also signed by the \gls{gsma} test certificate.
In contrast, \textbf{estk.me} does not expose an \gls{isdr} for \gls{lpa}-based interaction, limiting the scope of evaluation for that platform. As such, only \gls{usat}-based interaction was possible, and no \gls{rsp}-related operations via the implemented testing framework could be performed. \todo{Check how estk.me implements rsp -> maybe rlpa etc}
In contrast, \textbf{estk.me} allows users to manually enable \gls{isdr} mode, which theoretically permits access via an \gls{lpa}.
The \textbf{9esim v2} card, in comparison, fully supports both \gls{isdr} access and \gls{usat} communication. Although \gls{usat} interfaces were excluded from evaluation for this particular card due to it not being supported by the testing framwork.
@@ -131,6 +132,7 @@ Among all evaluated \glspl{esim}, \texttt{estk.me} stands out due to its publicl
\paragraph{Firmware Structure and Analysis.}
The firmware image accompanying the update utility appears to be encrypted or obfuscated. An entropy analysis conducted using the Shannon entropy metric indicates a consistently high entropy across all tested firmware files, suggesting the presence of encryption or compression. For instance, the entropy of the T001V06 firmware image was measured at approximately \texttt{7.998}, which is close to the theoretical maximum of \texttt{8.0} for purely random data.
\marginpar{Firmware entropy analysis suggests encryption or compression.}
\begin{figure}[ht]
\centering
@@ -190,9 +192,10 @@ The \gls{aid} used to access the update utility differs based on firmware genera
\texttt{A06573746B6D65FFFFFFFF6677757064} \\
(hex-encoded: \texttt{'estkmeÿÿÿÿfwupd'})
\end{quote}
\marginpar{Firmware follows one-way TXXXVXX versioning with no downgrade support.}
Firmware versions follow the format \texttt{TXXXVXX}, where major generation (\texttt{T000}--\texttt{T003}) and minor version are encoded. Firmware updates are incremental and strictly one-way, the tool automatically selects the next version based on the currently installed one, and downgrade paths are not supported.
Earlier releases of the firmware update utility included the corresponding C source code used to build the update binary. However, more recent versions of the utility are distributed only as precompiled binaries, without source code availability. Access to the original source-based versions is now limited and typically requires archival tools such as the Wayback Machine \footnote{https://web.archive.org/web/20250000000000*/https://www.estk.me/downloads/}.
Earlier releases of the firmware update utility included the corresponding C source code used to build the update binary. However, more recent versions of the utility are distributed only as precompiled binaries, without source code availability for newer versions. Access to the original source-based versions is now limited and requires archival tools such as the Wayback Machine \footnote{https://web.archive.org/web/20250000000000*/https://www.estk.me/downloads/}.
\paragraph{Firmware Flashing Procedure.}
@@ -203,7 +206,7 @@ The update process proceeds as follows:
\item \textbf{Send Firmware Blocks}:
\begin{itemize}
\item Firmware is divided into blocks of size \texttt{0x80D} bytes.
\item Each block is sent in subchunks, using standard \glspl{apdu} (\texttt{CLA=0xAA}) with \texttt{INS=0x11}.
\item Each block is sent in subchunks, using standard \glspl{apdu} (\texttt{CLA=0xAA}) with \texttt{INS=0x11}.\marginpar{Firmware is split into blocks, then subchunks for transmission and verification.}
\item After transmission, the same chunk is re-sent with \texttt{INS=0x12}, no payload, and the expected response length (\texttt{Le}) matching the original chunk size. This verification step is performed to ensure that the chunk was transmitted and received correctly, \ie, the \gls{euicc} confirms that the length of the previously received payload matches the expected length. We assume that the \gls{euicc} performs an internal consistency check between the declared length and the actual received bytes to validate chunk integrity.
\end{itemize}
\item \textbf{Check Flash Status}: The \gls{apdu} \texttt{AA13000000} is used to verify correct flash writing.
@@ -215,6 +218,7 @@ The update tool fails gracefully only under specific conditions. For malformed o
\paragraph{Reverse Engineering and Mutation Testing.}
Using insights gained from disassembly in Ghidra, a Python-based reimplementation of the update mechanism was developed and available via the \gls{cli} as shown in \cref{sec:cli}. This allowed fine-grained control over the update process and enabled targeted mutation-based testing of firmware blocks.
\marginpar{Mutated chunks often pass until flash check, indicating internal block verification logic.}
The same mutation strategies as shown in \cref{subsubsec:mutation_engine}, such as bit flipping, byte shuffling, truncation, and others, were applied to the firmware blocks on a per-chunk basis during both initial transmission and block validation. Notably, mutated blocks were generally accepted until the \texttt{check\_flash\_status} step, where the \gls{euicc} would immediately terminate the connection. This behavior strongly suggests that the device internally verifies each block against a checksum, hash or cryptographic signature.
@@ -251,7 +255,7 @@ The same mutation strategies as shown in \cref{subsubsec:mutation_engine}, such
\label{img:trace_setup}
\end{figure}
To investigate vendor-specific behaviors in \gls{rsp}, we employed SIMTrace2 to capture the \glspl{apdu} exchanged between the \gls{lpa} running on a phone and the \gls{esim}. This enabled us to analyze the communication protocols used during profile management and \gls{euicc} interaction, especially focusing on the discovery and selection of the \gls{isdr}.
To investigate vendor-specific behaviors in \gls{rsp}, we employed SIMTrace2\marginpar{SIMTrace2 captured vendor-specific APDU sequences during eSIM profile management.} to capture the \glspl{apdu} exchanged between the \gls{lpa} running on a phone and the \gls{esim}. This enabled us to analyze the communication protocols used during profile management and \gls{euicc} interaction, especially focusing on the discovery and selection of the \gls{isdr}.
During the analysis of the \texttt{eSIM.me} eSIM, we observed the use of a custom \gls{aid} during the SELECT command for \gls{isdr}. The following listing illustrates a sample trace captured while launching the \texttt{esim.me} Android application:
@@ -265,7 +269,7 @@ INFO Captured SELECT Apdu(01 A4 04 00 10 a0000005591010000000008900000300
The log highlights a noteworthy behavior: in line \ref{code:unkown_aid}, the SELECT command targets an unknown \gls{aid} \texttt{a0000005591010000000008900000300}, which results in status word \texttt{6A82} (File not found). This custom \gls{aid} is not documented in standard \gls{gsma} or \gls{gp} specifications and appears to be vendor-specific.
This behavior suggests that certain vendors, such as \texttt{esim.me}, implement proprietary \glspl{aid} in parallel to the standardized \gls{isdr} \gls{aid} (\texttt{A0000005591010FFFFFFFF8900000100}). This may serve as an obfuscation or access control measure, potentially restricting third-party \gls{lpa} implementations or enforcing usage of vendor-specific software. However, due to the mandatory access mediation performed by the \gls{aram}, the effectiveness of such mechanisms is ultimately constrained by access control policies defined on the card.
This behavior suggests that certain vendors, such as \texttt{esim.me}, implement proprietary \glspl{aid} in parallel to the standardized \gls{isdr} \gls{aid} (\texttt{A0000005591010FFFFFFFF8900000100}).\marginpar{Vendors may use custom AIDs for obfuscation or third-party access restriction.} This may serve as an obfuscation or access control measure, potentially restricting third-party \gls{lpa} implementations or enforcing usage of vendor-specific software. However, due to the mandatory access mediation performed by the \gls{aram}, the effectiveness of such mechanisms is ultimately constrained by access control policies defined on the card.
We catalogued the \gls{isdr} \glspl{aid} observed during tracing across multiple \gls{esim} vendors:
@@ -277,7 +281,7 @@ We catalogued the \gls{isdr} \glspl{aid} observed during tracing across multiple
\end{itemize}
This variation in \gls{aid} usage may be driven by internal vendor policy, branding, or the need to segment access to multiple security domains or services. In the case of \texttt{eSIM.me}, the coexistence of both the standard and custom \glspl{aid} suggests a fallback mechanism for compatibility with generic \gls{lpa} implementations.
\marginpar{Tracing helps analyze AID use but is limited without valid credentials.}
While tracing provides valuable insights into command sequencing and \gls{aid} selection behaviors, its utility is restricted when it comes to exercising full profile management flows or cross-device compatibility testing without access to valid cryptographic credentials.
% data fuzzing
@@ -343,7 +347,7 @@ In all three cases, the fuzzing input
get_profiles(use_iccid=False, profile_class=None, tags=b'')
\end{lstlisting}
resulted in a \texttt{CardConnectionException} raised by the \texttt{smartcard} Python library during \gls{apdu} transmission.
resulted in a \texttt{CardConnection\-Exception} raised by the \texttt{smartcard} Python library during \gls{apdu} transmission.
During these failures, a consistent and unusual hardware behavior was observed. The transaction LED on the card reader continued to blink, suggesting ongoing \gls{apdu} activity, even though no further commands were being issued by the fuzzing logic. This blinking persisted even after the test process was terminated and, in some cases, even after the \gls{esim} card was physically removed from the reader.
@@ -457,10 +461,10 @@ The execution time of fuzzed \gls{apdu} sequences varied depending on chip proce
%
% \end{itemize}
\begin{table}[ht]
\begin{adjustwidth}{-1in}{}
\begin{table}[H]
\begin{adjustwidth}{}{-1in}
\centering
\caption{Overview of Observed Error Types by Functions and Mutation Types}
\caption{Overview of Observed Error Types by Functions and all Mutation Types.}
\label{tab:error_overview}
\begin{tabular}{|p{4cm}|p{5cm}|p{4cm}|}
\hline
@@ -739,12 +743,13 @@ We performed a set of differential tests across two configurations:
\item \textbf{Cross-server scenario:} When changing the server to a different \gls{smdpp} (e.g., from \texttt{rsp.truphone.com} to \texttt{rsp-eu.redte\-mobile.com}), the identical $AS_2$ was rejected with an \texttt{UndefinedError}.
\end{itemize}
These results confirm that the \gls{euicc} caches authentication state scoped to the server identity as shown in \cref{img:auth-bypass-cache}. Notably, this state appears to persist even across full power cycles. When the \gls{esim} was physically removed from the card reader and reinserted, the same truncation attack still succeeded, indicating that state was retained in non-volatile storage.
These results confirm that the \gls{euicc} caches authentication state scoped to the server identity as shown in \cref{img:auth_bypass_cache}. Notably, this state appears to persist even across full power cycles. When the \gls{esim} was physically removed from the card reader and reinserted, the same truncation attack still succeeded, indicating that state was retained in non-volatile storage.
\begin{figure}[ht]
\begin{figure}[H]
\centering
\includesvg[width=\textwidth,inkscapelatex=false]{Graphics/vulnerability_sd.svg}
\label{img:auth_bypass_cache}
\caption{Impact of server identity on authentication state reuse. In same-server attacks, a malformed $AS_1$ followed by a truncated $AS_2$ leads to profile installation. In cross-server attacks, $AS_2$ is rejected, indicating scoped state persistence.}
\label{img:auth-bypass-cache}
\end{figure}
\paragraph{Example Mutation Patterns.}
@@ -768,7 +773,7 @@ These observations suggest that state retention is selective and scoped to prior
\subsection*{RQ3: Skipping Signature Verification via State Reuse}
\label{sec:rq3-signature}
Finally, to determine whether signature validation $\mathrm{Cert}_{Sa} \triangleleft \mathrm{Cert}_{CI}$ as shown in \cref{img:authenticate_server_sd} is skipped, we modified the truncated certificate in $AS_2$ by injecting an attacker-controlled public key $SK_A$ into the \texttt{SubjectPublicKeyInfo} field. Despite this manipulation, the \gls{euicc} still proceeded to mutual authentication and secure channel establishment.
Finally, to determine whether signature validation $\mathrm{Cert}_{Sa} \triangleleft \mathrm{Cert}_{CI}$ is skipped, we modified the truncated certificate in $AS_2$ by injecting an attacker-controlled public key $SK_A$ into the \texttt{SubjectPublicKeyInfo} field. Despite this manipulation, the \gls{euicc} still proceeded to mutual authentication and secure channel establishment.
The only plausible explanation is that the \gls{euicc} ignored the actual contents of the truncated $Cert_{Sa}^{(2)}$, and instead reused the public key received in the previously failed $AS_1$. Supporting this, attempts to reverse the sequence (sending the truncated $AS_2$ first) always failed, as did replaying the same attack against a different \gls{smdpp}. Thus, \textbf{RQ3} is also confirmed: digital signature verification can be bypassed through state reuse.

77
Chapters/Implementation.tex
View File

@@ -24,6 +24,7 @@
% - in the following sections i will go into details on how each implementation work
The primary goal of this thesis is to conduct a security analysis of commercial \gls{esim} implementations through differential testing. We adopt a systematic approach to compare the behavior of different \gls{euicc} implementations under identical inputs to uncover inconsistencies and potential vulnerabilities. Our focus lies particularly on components and behaviors that differentiate traditional \gls{sim} cards from \glspl{esim}, such as profile download and profile mangement capabilites.
\marginpar{Implementation focus is on behaviors unique to eSIMs, like profile download and management.}
To perform differential testing, we designed a structured fuzzing methodology that employs both valid and mutated \gls{apdu} sequences. By observing and comparing how multiple \glspl{euicc} respond to the same inputs, we aim to uncover deviations that may indicate security flaws or implementation weaknesses.
@@ -41,9 +42,10 @@ To perform differential testing, we designed a structured fuzzing methodology th
% - recording: represents a list of recorded \glspl{apdu}, handles source and target isd-r addresses, file saving and loding as well as checking if the file is replayable
% - replay: establishes connection to pcsc via pcsc link, loads recorded \glspl{apdu} and sends them over the link to the connected euicc, switches out source isd-r and target isd-r during replay, compares response status word to recorded status word on prints an error if there is a difference
We built the tracing component based on Design 1 in \cref{subsec:design_1} to capture and interpret \glspl{apdu} exchanged between an \gls{lpa} (or other source) and the \gls{euicc}, and to replay them by inserting the recorded \glspl{apdu} into the communication between the \gls{lpa} and the \gls{euicc}. This forms the foundation of the differential testing framework by allowing the same interaction sequence to be executed across multiple \glspl{euicc} for behavioral comparison.
We build the tracing component based on Design 1 in \cref{subsec:design_1} to capture and interpret \glspl{apdu} exchanged between an \gls{lpa} (or other source) and the \gls{euicc}, and to replay them by inserting the recorded \glspl{apdu} into the communication between the \gls{lpa} and the \gls{euicc}. This forms the foundation of the differential testing framework by allowing the same interaction sequence to be executed across multiple \glspl{euicc} for behavioral comparison.
Our tracing functionality comprises two main operations:
\marginpar{Inject recorded APDUs into a card reader session, adjusting IDs and checking responses.}
\begin{itemize}
\item \textbf{Tracing and recording:} Captures \glspl{apdu} traffic from a physical interface using \texttt{simtrace2}~\cite{osmocom_simtrace_nodate} and associates it with functional interpretations (e.g., profile enablement, deletion). The \glspl{apdu} are parsed and stored along with contextual information such as sender and receiver addresses.
@@ -65,8 +67,10 @@ The implementation consists of several key components as shown in \cref{img:clas
\item[\texttt{Card}] Represents a connected card in a PC/SC reader. It queries the card to determine its type (e.g., standard \gls{sim}, test \gls{euicc}, or commercial \gls{euicc}), and identifies installed applications such as \gls{isdr} or \gls{ecasd}. The class serves as the interface for sending \glspl{apdu} to the card through the \texttt{pcsc\_link}.
\item[\texttt{Tracer}] A dummy implementation of the \texttt{Card} interface used during passive tracing. It parses incoming \glspl{apdu} from the GSMTAP interface using \texttt{pysim} and attempts to classify them based on instruction type. This allows mapping observed \glspl{apdu} to functional operations.
\marginpar{Card, Tracer, and Recorder handle active interaction, passive capture, and session logging for eUICC testing.}
\item[\texttt{Recorder}] Coordinates tracing and recording. It spawns a separate tracer thread that listens for \glspl{apdu} from GSMTAP in a loop until a timeout occurs or a stop signal is issued. \glspl{apdu} are recorded alongside the designated target \gls{isdr} for later analysis.
\marginpar{Recording and Replayer store traced sessions and replay them to detect behavioral differences across eUICCs.}
\item[\texttt{recording}] An abstraction for a recorded session. It stores the list of \glspl{apdu}, associated source and target \texttt{\gls{isdr}} addresses, and metadata. It provides serialization functions for saving to and loading from disk, as well as validity checks to determine whether a recording is replayable.
@@ -148,7 +152,7 @@ This modular structure allows for easy integration into both automated test pipe
% before returning the data to the caller -> client checks for error on server and eventually raises the corresponding exception -> as explained in the exception handling part
% smdp+ client is mostly used by the isd-r
Due to the inability of the \texttt{tracer} implementation to accurately replay \gls{rsp} interactions, we developed a dedicated \gls{lpa} to initiate valid interactions with the \gls{euicc}. This custom \gls{lpa} provides us with full control over the generation and mutation of traffic, enabling structured and repeatable interaction patterns. We describe the mutation and fuzzing strategies enabled by this setup in detail in \cref{sec:fuzzing}. Our implementation specifically targets the SGP.22 v3.1 specification, which, at the time of writing, represented the most recent version available~\cite{gsma_sgp22_2025}.
Due to the inability of the \texttt{tracer} implementation to accurately replay \gls{rsp} interactions, we developed a dedicated \gls{lpa} to initiate valid interactions with the \gls{euicc}.\marginpar{Custom LPA enables precise and controlled RSP interactions with eUICCs.} This custom \gls{lpa} provides us with full control over the generation and mutation of traffic, enabling structured and repeatable interaction patterns. We describe the mutation and fuzzing strategies enabled by this setup in detail in \cref{sec:fuzzing}. Our implementation specifically targets the SGP.22 v3.1 specification, which, at the time of writing, represented the most recent version available~\cite{gsma_sgp22_2025}.
The \gls{lpa} is composed of multiple components:
@@ -156,15 +160,17 @@ The \gls{lpa} is composed of multiple components:
Represents the \gls{euicc} currently inserted into the PC/SC card reader. Upon initialization, it scans the card for supported applications, identifying the applicable \gls{adf} through probing. This is necessary as eSIM-on-SIM implementations often use proprietary \glspl{adf}, diverging from the \glspl{adf} specified in the SGP.22 standard as we will evaluate in \cref{sec:eval_tracing}. The card object keeps track of the selected application to reduce unnecessary reselection and traffic.
\paragraph{PC/SC Link.}
\marginpar{PC/SC Link maintains session and supports APDU mutation.}
This component is based on \texttt{pySim}'s \texttt{LinkBaseTpdu}. It establishes an exclusive connection to the PC/SC reader to maintain session state consistency, which is required due to the stateful nature of \gls{euicc} interactions. During initialization:
\begin{itemize}
\item The supported transmission protocol (T=0 or T=1) is detected.
\item A connection is established and validated.
\end{itemize}
It handles both \gls{apdu} and \gls{tpdu} transmission, automatically requesting additional data when status words such as \texttt{9FXX}, \texttt{61XX}, \texttt{62XX}, or \texttt{63XX} are encountered. When enabled, it invokes an optional mutation engine before sending \glspl{apdu} (see \cref{subsec:apdu_fuzzing}) and also records all traffic for later analysis.
It handles both \gls{apdu} and \gls{tpdu} transmission, automatically requesting additional data when status words such as \texttt{9FXX}, \texttt{61XX}, \texttt{62XX}, or \texttt{63XX} are encountered as further detailed in \cref{sec:sw_codes}. When enabled, it invokes an optional mutation engine before sending \glspl{apdu} (see \cref{subsec:apdu_fuzzing}) and also records all traffic for later analysis.
\paragraph{Application.}
Each \gls{euicc} application (\eg, \gls{isdr}, \gls{ecasd}) is implemented with application-specific logic and communicates with the card via the \texttt{pcsc\_link}. The application layer abstracts encoding/decoding and command sending. For instance, the \texttt{store\_data} command is handled internally using \texttt{asn1tools} for encoding and decoding.
\marginpar{Application represents eUICC applet, encode commands, and decodes responses.}
Known \glspl{adf} for \gls{isdr} observed during analysis:
\begin{itemize}
@@ -179,10 +185,10 @@ To decoded response data for further processing, we use \texttt{pydantic} data c
The \texttt{estk\_fwupd} application implements a proprietary firmware update interface, which we reverse-engineered (see \cref{sec:eval_tracing}). It supports reading the current firmware version, unlocking\footnote{This unlocking is distinct from \gls{gp}-defined unlocking, which allows the execution of generic \gls{gp} commands. See \gls{gp} Card Specification \cite{globalplatform_gp_2018}.} the \gls{euicc} for updates, and installing new binaries.
\paragraph{Exception Handling.}
The SGP.22 standard defines a variety of response codes and error conditions. We map these response codes to custom exception classes in the \gls{lpa} implementation to enable precise error handling. This is essential for both debugging and for the differential testing framework to reason about diverging behavior across implementations. A code listing of the exception handling mappings is provided in \cref{sec:exception-handling}.
The SGP.22 standard defines a variety of response codes and error conditions.\marginpar{Custom exceptions provide precise handling of SGP.22-defined response codes.} We map these response codes to custom exception classes in the \gls{lpa} implementation to enable precise error handling. This is essential for both debugging and for the differential testing framework to reason about diverging behavior across implementations. A code listing of the exception handling mappings is provided in \cref{sec:exception-handling}.
\paragraph{SM-DP+ Client.}
In addition to \gls{euicc} communication, the \gls{lpa} implementation must interact with the \gls{smdpp} server via the ES9+ interface. Our implementation uses \texttt{httpx} for HTTP interactions and adheres to the expected headers and structure as defined by SGP.22:
In addition to \gls{euicc} communication, the \gls{lpa} implementation must interact with the \gls{smdpp} server via the ES9+ interface as shown in \cref{img:rsp_architecture}. Our implementation uses \texttt{httpx} for HTTP interactions and adheres to the expected headers and structure as defined by SGP.22:
\begin{lstlisting}[language=json,caption={ES9+ Request Headers}]
{
"Content-Type": "application/json",
@@ -190,6 +196,7 @@ In addition to \gls{euicc} communication, the \gls{lpa} implementation must inte
"X-Admin-Protocol": "gsma/rsp/v3.1.0"
}
\end{lstlisting}
\marginpar{Deserialization of responses and structured error handling using SM-DP+ client.}
We encode payload values in Base64 format, as mandated by the specification. To process server responses, we deserialize the returned data using custom \texttt{pydantic} data classes that model the expected structure. In the event of an error response, our implementation raises the appropriate exception, following the error-handling logic outlined in the previous section.
@@ -198,6 +205,8 @@ The \gls{smdpp} client is primarily used by our \gls{isdr} application to execut
\section{Fuzzing}
\label{sec:fuzzing}
\todo{Section summary}
\subsection{APDU Fuzzing}
\label{subsec:apdu_fuzzing}
@@ -281,7 +290,7 @@ To uncover behavioral differences between \gls{euicc} implementations, we implem
\paragraph{Fuzzing Scenarios and Execution.}
We perform fuzzing through predefined \emph{scenarios}, which consist of ordered sequences of function calls targeting the \gls{euicc}. Each function within a scenario is executed via our custom \gls{lpa} implementation and serves as a potential mutation point. To ensure a consistent test environment, the scenario runner establishes a fresh PC/SC connection and resets the card into a clean state by invoking the \texttt{eUICCMemoryReset} operation. This includes processing all pending notifications and performing a full memory wipe prior to execution.
We perform fuzzing through predefined \emph{scenarios}, which consist of ordered sequences of function calls targeting the \gls{euicc}. Each function within a scenario is executed via our custom \gls{lpa} implementation and serves as a potential mutation point.\marginpar{Scenarios define structured test sequences where each function is a mutation target.} To ensure a consistent test environment, the scenario runner establishes a fresh PC/SC connection and resets the card into a clean state by invoking the \texttt{eUICCMemoryReset} operation. This includes processing all pending notifications and performing a full memory wipe prior to execution.
To systematically track the fuzzing process, we developed an \textbf{operation recorder} that tracks every function invocation, the applied mutations, and the corresponding responses. This data is structured as a hierarchical \emph{mutation tree}, where each node represents a function call with a specific mutation applied. Each level in the tree corresponds to a function in the scenario, while sibling nodes denote alternative mutations of the same function. \cref{img:class_basic} shows how the \textbf{operation recorder} intregrates into \sysname.
@@ -297,15 +306,15 @@ To systematically track the fuzzing process, we developed an \textbf{operation r
We designed the mutation engine to support both \textit{deterministic} and \textit{random} mutation modes. It implements the following strategies for data transformation:
\begin{itemize}
\item \textbf{Bit Flip:} In this strategy, individual bits within the payload are flipped to introduce low-level perturbations. The number of bits to flip is determined by the mutation rate $M$ in proportion to the length $L$ of the payload: $max(1, L \cdot M)$. In deterministic mode, the bit positions are computed using a fixed formula: the byte index $B_I$ is calculated as $(i \cdot 31) \mod L$ and the specific bit to flip within that byte is $(i \cdot 7) \mod 8$ with $i$ indicating the index of the current flip. This approach ensures consistent mutation offsets across runs, thereby facilitating reproducibility.
\item \textbf{Bit Flip:} In this strategy, individual bits within the payload are flipped to introduce low-level perturbations. The number of bits to flip is determined by the mutation rate $M$ in proportion to the length $L$ of the payload: $max(1, L \cdot M)$.\marginpar{Bit Flip alters bits at computed offsets.} In deterministic mode, the bit positions are computed using a fixed formula: the byte index $B_I$ is calculated as $(i \cdot 31) \mod L$ and the specific bit to flip within that byte is $(i \cdot 7) \mod 8$ with $i$ indicating the index of the current flip. This approach ensures consistent mutation offsets across runs, thereby facilitating reproducibility.
\item \textbf{Random Byte:} This mutation strategy replaces specific bytes with deterministic pseudo-random values. Similar to the bit flip strategy, the number of mutations is derived from the mutation rate $M$ and length $L$ of the payload. The byte index is computed using $(i \cdot 29) \mod L$, and the replacement value is calculated as $(i \cdot 13) \mod 256$ where is the index of the current mutation. Although the name suggests randomness, in deterministic mode these substitutions are reproducible due to the deterministic index-value derivation.
\item \textbf{Random Byte:} This mutation strategy replaces specific bytes with deterministic pseudo-random values. Similar to the bit flip strategy, the number of mutations is derived from the mutation rate $M$ and length $L$ of the payload.\marginpar{Random Byte replaces bytes using pseudo-random values.} The byte index is computed using $(i \cdot 29) \mod L$, and the replacement value is calculated as $(i \cdot 13) \mod 256$ where is the index of the current mutation. Although the name suggests randomness, in deterministic mode these substitutions are reproducible due to the deterministic index-value derivation.
\item \textbf{Zero Block:} A contiguous sequence of bytes is replaced with zeroes to simulate data loss or corruption. The mutation engine deterministically selects the starting index as $\lfloor \frac{L}{4} \rfloor \mod \max(1, L - 20)$ and replaces the next ten bytes (up to the end of the data). This method introduces a predictable null block, which is especially useful for observing system behavior under conditions of zeroed memory regions.
\item \textbf{Zero Block:} A contiguous sequence of bytes is replaced with zeroes to simulate data loss or corruption.\marginpar{Zero Block inserts a null region to simulate data loss.} The mutation engine deterministically selects the starting index as $\lfloor \frac{L}{4} \rfloor \mod \max(1, L - 20)$ and replaces the next ten bytes (up to the end of the data). This method introduces a predictable null block, which is especially useful for observing system behavior under conditions of zeroed memory regions.
\item \textbf{Shuffle Block:} To alter the structure of the payload while preserving local data, the input is first partitioned into fixed-size blocks (16 bytes each). These blocks are then reordered deterministically based on a checksum-like function, specifically by sorting according to the sum of bytes in each block modulo 256.
\item \textbf{Shuffle Block:} To alter the structure of the payload while preserving local data,\marginpar{Shuffle Block reorders 16-byte blocks.} the input is first partitioned into fixed-size blocks (16 bytes each). These blocks are then reordered deterministically based on a checksum-like function, specifically by sorting according to the sum of bytes in each block modulo 256.
\item \textbf{Truncation:} The mutation engine simulates incomplete transmissions or premature message termination by truncating the payload at a fixed ratio. Specifically, the payload is cut at 75\% of its original length. This type of mutation is particularly relevant in fuzzing protocols or parsers that may not handle end-of-stream conditions robustly.
\item \textbf{Truncation:} The mutation engine simulates incomplete transmissions or premature message termination by truncating the payload at a fixed ratio.\marginpar{Truncation cuts payload at 75\% length.} Specifically, the payload is cut at 75\% of its original length. This type of mutation is particularly relevant in fuzzing protocols or parsers that may not handle end-of-stream conditions robustly.
\end{itemize}
Deterministic mode ensures reproducibility by applying mutations at fixed, formula-derived offsets, whereas the random mode selects mutation targets probabilistically at runtime. Both modes behave similar to the deterministic and non-deterministic mutation modes used in AFLPlusPlus~\cite{fioraldi_afl_2020}.
@@ -316,18 +325,20 @@ Deterministic mode ensures reproducibility by applying mutations at fixed, formu
Figure \cref{fig:scenario_flow} illustrates the \gls{apdu} fuzzing workflow, which we structured into four main steps:
\begin{enumerate}
\item \textbf{Mutation selection:} The operation recorder decides the next mutation to apply based on a depth-first traversal of the mutation tree. If all mutations for the current function are exhausted, the runner searches for unexplored child nodes.
\item \textbf{Mutation selection:} The operation recorder decides the next mutation to apply based on a depth-first traversal of the mutation tree. If all mutations for the current function are exhausted, the runner searches for unexplored child nodes.\marginpar{APDU fuzzing mutates scenario functions, sends inputs to eUICCs, and records responses in a tree.}
\item \textbf{\gls{apdu} mutation:} We apply the selected mutation to the original \gls{apdu} using the mutation engine.
\item \textbf{\gls{apdu} transmission:} The mutated \gls{apdu} is sent to the \gls{euicc}. We record success or failure in the current mutation tree node.
\item \textbf{Recording:} We save the response or exception in the corresponding mutation tree node for further analysis.
\end{enumerate}
\begin{figure}
\centering
\input{Graphics/record_scenario_flow.tikz}
% \resizebox{\textwidth}{!}{\input{Graphics/record_scenario_flow.tikz}}
\caption{Flow for recording a scenario.}
\label{fig:scenario_flow}
\begin{adjustwidth}{-1.5in}{-.5in}
\centering
\input{Graphics/record_scenario_flow.tikz}
% \resizebox{\textwidth}{!}{\input{Graphics/record_scenario_flow.tikz}}
\caption{Flow for recording a scenario.}
\label{fig:scenario_flow}
\end{adjustwidth}
\end{figure}
We repeat this process for all functions defined in the scenario, producing a complete mutation tree (see \cref{fig:tree_structure}) that captures all inputs, outputs, and error states.
@@ -350,26 +361,28 @@ We repeat this process for all functions defined in the scenario, producing a co
% if so return the mutation type of the child that still has not tried mutation types -> brings us on the subtree where a child has not tried mutations -> next time this function is called we return the new not tried mutation type
% if child does not have any not tried mutations: we return the NoneNode of that child i.e the mutation type of the child that was successfully executed and did not make any mutations. idea: continue down the good path to find untried mutations
The decision process for selecting the next mutation to apply is a key component of the fuzzing framework and is handled entirely by the \texttt{Operation\-Recorder}. Its responsibility is to ensure that all mutations are eventually applied to each function within a scenario while maintaining a consistent and deterministic traversal order across runs.
The decision process for selecting the next mutation to apply is a key component of the fuzzing framework and is handled entirely by the \texttt{Operation\-Recorder}.\marginpar{OperationRecorder deterministically selects the next mutation using structured tree traversal.} Its responsibility is to ensure that all mutations are eventually applied to each function within a scenario while maintaining a consistent and deterministic traversal order across runs.
\begin{figure}
\centering
\input{Graphics/determine_next_mutation_flow.tikz}
\caption{Flow on how to determine the next mutation that should be used.}
\label{fig:next_mutation_flow}
\begin{adjustwidth}{-1.5in}{-.5in}
\centering
\input{Graphics/determine_next_mutation_flow.tikz}
\caption{Flow on how to determine the next mutation that should be used.}
\label{fig:next_mutation_flow}
\end{adjustwidth}
\end{figure}
Our algorithm, illustrated in \cref{fig:next_mutation_flow}, operates based on the current node in the mutation tree. Each node represents a function invocation, and its children represent the same invocation with different mutations. The logic proceeds as follows:
\begin{enumerate}
\item \textbf{Check for untried mutations at the current node:}
The recorder checks whether the current node has already created child nodes for every defined mutation type (e.g., bitflip, zero-block, truncate, etc.). If there are untried mutation types, it selects one of them, creates a new child node with that mutation, sets it as the new current node, and returns the selected mutation type.
The recorder checks whether the current node has already created\marginpar{Recorder recursively explores child nodes to find untested mutations.} child nodes for every defined mutation type (e.g., bitflip, zero-block, truncate, etc.). If there are untried mutation types, it selects one of them, creates a new child node with that mutation, sets it as the new current node, and returns the selected mutation type.
\item \textbf{Recursive traversal of child nodes:}
If all mutation types have already been tried at the current node (i.e., all child mutations are present), the recorder traverses the subtree rooted at each child node. For each child, it checks if there are any untried mutations deeper in the tree.
\item \textbf{Descent via valid (None) paths:}
If no untried mutations are found among the children, the recorder follows the \texttt{NoneNode} child—representing the unmutated, successful execution of the function. This path is presumed to lead to deeper parts of the tree where further mutations might be unexplored. In essence, this descent along the ``clean'' path enables the system to reach other branches that may still contain untested mutations.
If no untried mutations are found among the children, the recorder follows the \texttt{NoneNode} child—representing\marginpar{Fallback to unmutated path enables deeper traversal of untested branches.} the unmutated, successful execution of the function. This path is presumed to lead to deeper parts of the tree where further mutations might be unexplored. In essence, this descent along the ``clean'' path enables the system to reach other branches that may still contain untested mutations.
\item \textbf{Backtrack or complete:}
If the entire subtree from the current node has been fully explored (i.e., all mutations at all levels are exhausted), the recorder signals completion by returning a sentinel (e.g., \texttt{None}) to the scenario runner.
@@ -392,7 +405,7 @@ To preserve fuzzing results, the entire mutation tree is serialized and stored u
\paragraph{Differential Testing.}
After multiple cards are fuzzed with the same scenario, their corresponding mutation trees are compared to identify behavioral discrepancies. This is done via depth-first traversal of the trees:
After multiple cards are fuzzed with the same scenario,\marginpar{Differential testing compares mutation trees across cards to identify behavior mismatches.} their corresponding mutation trees are compared to identify behavioral discrepancies. This is done via depth-first traversal of the trees:
\begin{itemize}
\item Trees must have equivalent structure (same function call order and mutation types).
@@ -478,11 +491,11 @@ This differential testing method highlights edge-case inconsistencies across \gl
% this allows us to test failed input against other cards when running the fuzzing against them -> differential testing
While APDU-level fuzzing (see \cref{subsec:apdu_fuzzing}) is useful for evaluating command behavior across different \textit{euicc} implementations, it suffers from the drawback that random mutations, particularly at the bit or byte level, often invalidate the structured \gls{asn1} encoding. As a result, many \gls{apdu} mutations are immediately rejected as malformed, limiting the coverage and effectiveness of the test campaign.
\marginpar{Data fuzzing targets high-level LPA inputs to preserve structure while testing edge cases.}
To address this limitation, we introduce a complementary \textit{data fuzzing} approach based on Design 3 in \cref{subsec:design_3}, that operates at the semantic level by fuzzing the input arguments of high-level \gls{lpa} function calls. This enables us to maintain structural validity while still exercising a wide variety of edge cases in the data provided to the \gls{euicc}. Our implementation builds on property-based testing frameworks designed for Python, in particular the \texttt{hypothesis} library~\cite{maciver_hypothesis_2019}.
\paragraph{Fuzzing with Hypothesis.}
Hypothesis is a property-based testing framework, which allows developers to define \textit{strategies} for input data. The framework then generates test cases based on these strategies and attempts to explore edge cases through randomized sampling and shrinking. Unlike traditional random fuzzing, Hypothesis ensures that generated inputs conform to the structural invariants defined by the strategy, thereby increasing the likelihood of discovering subtle logic errors in protocol handling.
Hypothesis is a property-based testing framework, which allows developers to define \textit{strategies} for input data.\marginpar{Property-based testing with Hypothesis ensures input validity and semantic diversity.} The framework then generates test cases based on these strategies and attempts to explore edge cases through randomized sampling and shrinking. Unlike traditional random fuzzing, Hypothesis ensures that generated inputs conform to the structural invariants defined by the strategy, thereby increasing the likelihood of discovering subtle logic errors in protocol handling.
Hypothesis integrates seamlessly with \texttt{pytest} and uses the \texttt{@given} decorator to specify input generation strategies. For example, given the \gls{asn1} structure defined in the SGP.22 specification for the \texttt{Get\-Profile\-Info} function:
@@ -523,7 +536,7 @@ def test_get_profiles(self, use_iccid, profile_class, tags):
This approach preserves the semantics and structure of the expected \gls{asn1} types while still allowing a wide variety of edge cases to be exercised.
\paragraph{Implementation Scope.}
Due to reliance on external infrastructure for the \gls{rsp} process, such as the \gls{smdpp} server, our fuzzing campaign focuses exclusively on the \gls{euicc}-side of the \gls{rsp} protocol. Invalid structured fuzzing requests directed at the \gls{smdpp} would lead to excessive traffic and could be misinterpreted as \gls{dos} attempts. Therefore, we restrict our tests to those functions defined in the ES10a, ES10b, and ES10c interfaces of the SGP.22 specification, which form the communication layer between the \gls{lpa} and the \gls{euicc}, specifically focusing on functions that accept structured input arguments and directly interact with the \gls{euicc}.
Due to reliance on external infrastructure for the \gls{rsp} process, such as the \gls{smdpp} server, our fuzzing campaign focuses exclusively on the \gls{euicc}-side of the \gls{rsp} protocol. Invalid structured fuzzing requests directed at the \gls{smdpp} would lead to excessive traffic and could be misinterpreted as \gls{dos} attempts.\marginpar{Fuzzing is limited to eUICC-side functions to avoid DoS risks on SM-DP+.} Therefore, we restrict our tests to those functions defined in the ES10a, ES10b, and ES10c interfaces of the SGP.22 specification and also shown in \cref{img:rsp_architecture}, which form the communication layer between the \gls{lpa} and the \gls{euicc}, specifically focusing on functions that accept structured input arguments and directly interact with the \gls{euicc}.
Specifically, we implemented fuzzing tests for the following functions:
@@ -556,14 +569,13 @@ During the \texttt{setUpClass} phase, a PC/SC link is initialized, and the \gls{
\paragraph{Error Classification.}
According to the SGP.22 specification, many functions may return a generic \texttt{UndefinedError} in response to unexpected or malformed input. In our implementation, exceptions raised by the \gls{euicc} that map to well-defined error codes (i.e., subclasses of \texttt{EuiccException}) are not treated as test failures. These represent handled errors indicating that the input was invalid but the card responded appropriately.
\marginpar{Well-defined EuiccExceptions indicate valid error handling and are not treated as failures.}
\todo{Check Undefined Error}
By contrast, when an \texttt{UndefinedError} is returned, we treat this as a potential indicator of an unhandled internal error or inconsistent implementation behavior. These cases are flagged for further investigation. Additionally, exceptions occurring outside the \gls{euicc}, such as Python \texttt{AssertionError}s or test harness failures, are treated as bugs in the testing infrastructure and are logged separately.
\todo{Explain how we use differential testing in this context}
\paragraph{Conclusion.}
By combining property-based data generation with structural knowledge of \gls{asn1} types, we extend the fuzzing coverage of the \gls{euicc} interface beyond what is possible with \gls{apdu} mutation alone. This enables the discovery of semantic inconsistencies and unhandled corner cases in \gls{euicc} implementations, especially when compared across different vendors during differential testing as shown in \cref{sec:data_fuzzing_evaluation}.
\marginpar{Data fuzzing complements APDU mutation by testing semantic correctness of structured inputs.}
\textit{hypothesis} automatically records any failing test cases to local storage. For each failure, the corresponding input is saved and a unique hash is printed to allow reproducible identification of the triggering input. These previously failing test cases are automatically re-executed during future fuzzing runs prior to generating new test data. This mechanism enables us to efficiently validate whether the same input leads to diverging behavior across different \glspl{euicc}, thereby supporting systematic and automated differential testing.
@@ -593,6 +605,7 @@ By combining property-based data generation with structural knowledge of \gls{as
While the implemented library provides a programmatic interface to the \gls{lpa} and \gls{euicc} operations, many users, especially testers and engineers, require a more accessible method for interacting with the system. For this reason, we provide a fully-featured \gls{cli} that exposes all major functionalities of the system, including \gls{apdu} tracing, \gls{lpa} operations, and fuzzing workflows.
\marginpar{CLI offers user-friendly access to tracing, LPA operations, and fuzzing features.}
The \gls{cli} is built using Python’s standard \texttt{argparse} module for argument parsing, extended with \texttt{argcomplete} to enable shell auto-completion. For improved readability and formatting of terminal output, the \texttt{rich} library is used. This combination allows for an interactive, user-friendly \gls{cli} with both developer ergonomics and production readiness in mind.

10
Chapters/Introduction.tex
View File

@@ -20,10 +20,10 @@
% esim on sim enable old phones to use eSIM via sim slot or other applications
In today's hyper-connected society, smartphones, \gls{iot} devices, and vehicles rely on cellular networks for a wide range of functionalities. These devices typically authenticate to mobile networks using \gls{sim} cards. To keep pace with growing connectivity needs and reduce reliance on physical \gls{sim} provisioning, the GSMA released the first version of the SGP.01 specification in 2013 \cite{gsma_sgp01_2014}. This specification focuses on M2M (Machine-to-Machine) use cases and was mainly targeted at industrial deployments.
In today's hyper-connected society, smartphones, \gls{iot} devices, and vehicles rely on cellular networks for a wide range of functionalities. These devices typically authenticate to mobile networks using \gls{sim} cards. To keep pace with growing connectivity needs and reduce reliance on physical \gls{sim} provisioning, the \gls{gsma} released the first version of the SGP.01 specification in 2013 \cite{gsma_sgp01_2014}. This specification focuses on M2M (Machine-to-Machine) use cases and was mainly targeted at industrial deployments.\marginpar{eSIM technology is still relatively new.}
Later on the SGP.21 specification was released in 2015 \cite{gsma_sgp21_2015}, which defines how profiles should be securely provisioned onto \glspl{esim}, laying the foundation for \gls{esim} integration in consumer devices. Industry adoption started in 2016 with the release of the first device supporting \gls{esim}~\cite{vincent_samsungs_2016} and gained further traction with Apple's inclusion of \gls{esim} functionality in the iPhone lineup in 2018~\cite{apple_apple_2018}. Since then, \gls{esim} technology has become increasingly popular due to its flexibility, remote provisioning capabilities, and suitability for compact or embedded hardware. It simplifies processes such as switching mobile carriers or activating local profiles when traveling.
As \gls{esim} support becomes standard in newly released phones, it also introduces a new industry for esim profiles \cite{saily_get_2025, holafly_holafly_2025}. Notably, older devices without native \gls{esim} support are excluded from this technological shift. In response, several vendors have introduced eSIM-on-SIM chips embedded in a traditional \gls{esim} card form factor. These allow older phones to access \gls{esim} functionality via the existing \gls{sim} slot. For example, esim.me marketed their solution in 2020 as the “world’s first \gls{esim} card”~\cite{esimme_esimme_2025}, enabling legacy smartphones to benefit from modern \gls{esim} provisioning workflows.
As \gls{esim} support becomes standard in newly released phones, it also introduces a new industry for esim profiles \cite{saily_get_2025, holafly_holafly_2025}. Notably, older devices without native \gls{esim} support are excluded from this technological shift. In response, several vendors have introduced eSIM-on-SIM chips embedded in a traditional \gls{esim} card form factor.\marginpar{eSIM-on-SIM cards bring eSIM functionality to legacy devices.} These allow older phones to access \gls{esim} functionality via the existing \gls{sim} slot. For example, esim.me marketed their solution in 2020 as the “world’s first \gls{esim} card”~\cite{esimme_esimme_2025}, enabling legacy smartphones to benefit from modern \gls{esim} provisioning workflows.
\section{Motivation}
% Motivation
@@ -56,11 +56,11 @@ Despite the \gls{esim} architecture being built with security in mind and standa
However, while these tests offer a common baseline for conformance, the underlying firmware and operating system implementations of the \glspl{euicc} remain proprietary and closed-source. This means they are not open to public review and may include undocumented features, backdoors, or custom update mechanisms beyond the published standards.
These implementation-specific deviations can have a significant security risks. \glspl{sim} operate at a privileged layer of the system architecture, with direct access to the device's baseband. Vulnerabilities within this stack can result in persistent malware, surviving reboots or even factory resets, and often remain invisible to users. Bugs in the implementation of profile provisioning, certificate validation, or update mechanisms can therefore have severe and long-lasting impact.
These implementation-specific deviations can have a significant security risks. \glspl{sim} operate at a privileged layer of the system architecture, with direct access to the device's baseband.\marginpar{Inconsistent interpretations may introduce security or interoperability vulnerabilities.} Vulnerabilities within this stack can result in persistent malware, surviving reboots or even factory resets, and often remain invisible to users. Bugs in the implementation of profile provisioning, certificate validation, or update mechanisms can therefore have severe and long-lasting impact.
Furthermore, given the relative novelty of the consumer \gls{esim} ecosystem, the first SGP.21 release only dating back to 2015~\cite{gsma_sgp21_2015} and the latest version (v3.1) being released in 2025~\cite{gsma_sgp22_2025}, the technology is still evolving. Different vendors may interpret and implement the specifications in slightly different ways, leading to inconsistencies and potentially exploitable gaps.
Due to the lack of transparency in vendor implementations, black-box testing methodologies are especially valuable for uncovering such issues. Differential testing is a promising approach as it systematically compares how different implementations behave when subjected to identical or similar inputs \cite{mckeeman_differential_1998}. This makes it possible to detect deviations and identify bugs without needing source code or internal documentation.
Due to the lack of transparency in vendor implementations, black-box testing methodologies are especially valuable for uncovering such issues. Differential testing is a promising approach as it systematically compares how different implementations behave when subjected to identical or similar inputs \cite{mckeeman_differential_1998}.\marginpar{Differential testing detects behavioral differences between vendor implementations.} This makes it possible to detect deviations and identify bugs without needing source code or internal documentation.
This thesis aims to close the gap in independent, systematic analysis of commercial eSIM-on-SIM implementations. It proposes and demonstrates a differential testing framework that facilitates the black-box evaluation of these implementations in terms of correctness and security.
@@ -98,7 +98,7 @@ This thesis presents \sysname~\footnote{https://github.com/Trup3s/resimulate}, t
\item \textbf{Library and CLI-based usability:} The framework is exposed both as a command-line interface and as a Python library, enabling flexible integration into automated test setups and scripting environments.
\end{itemize}
We use the framework to analyze several commercial eSIM-on-SIM implementations. Our analysis reveals significant implementation differences, including a critical vulnerability in one vendor's certificate handling logic. Specifically, we uncover a bug that suggests a certificate validation bypass during the profile provisioning process. We also reverse-engineer the firmware update functionality of the estk.me card.
We use the framework to analyze several commercial eSIM-on-SIM implementations.\marginpar{We find a critical certificate validation bypass in one vendor's provisioning process.} Our analysis reveals significant implementation differences, including a critical vulnerability in one vendor's certificate handling logic. Specifically, we uncover a bug that suggests a certificate validation bypass during the profile provisioning process. We also reverse-engineer the firmware update functionality of the estk.me card.
\section{Outline}
% Outline

30
Chapters/RelatedWork.tex
View File

@@ -53,39 +53,52 @@ The ecosystem surrounding \gls{esim} and \gls{euicc} technology is supported by
% 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. 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_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}. 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.
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.
\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.
\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. 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{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.
\todo{Find more relevant papers i.e side-channel attacks, etc}
\section{Software and Hardware Implementations}
@@ -106,7 +119,7 @@ A more serious security assessment was presented by \textcite{security_explorati
\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.
@@ -128,6 +141,7 @@ While \texttt{pySim} provides useful standalone utilities, its usability as a ge
\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}.
@@ -148,6 +162,7 @@ Overall, \texttt{SIMtrace2} is a versatile tool both for passive analysis and ac
\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}.
@@ -161,6 +176,7 @@ However, \texttt{lpac} only supports SGP.22 version 2.2.2, whereas the most rece
% - 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.

1
Graphics/esim_overview.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 15 KiB

2
Graphics/vulnerability_sd.svg
View File

File diff suppressed because one or more lines are too long
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 14 KiB

After

Width:  |  Height:  |  Size: 14 KiB