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 18:27:06 +00:00
committed by node
parent e702a2aa6f
commit 9f51f200c3
9 changed files with 75 additions and 77 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
Appendices/SomeProof.tex
View File

@@ -20,7 +20,7 @@
% listing2 shows implemention of a function exception class with a fill error_map and some example error exception
Robust exception handling is critical in the context of \gls{euicc} interactions, especially when performing differential testing. The SGP.22 specification defines a comprehensive set of error codes, many of which are reused across different functions. To allow both coarse-grained and fine-grained error handling, the exception hierarchy in our implementation is explicitly structured around two core ideas:
Robust exception handling is critical in the context of \gls{euicc} interactions, especially when performing differential testing. The SGP.22 specification defines a comprehensive set of error codes, many of which are reused across different functions.\marginpar{Exceptions are categorized by function context and specific error type.} To allow both coarse-grained and fine-grained error handling, the exception hierarchy in our implementation is explicitly structured around two core ideas:
\begin{itemize}
\item \textbf{Function-based exceptions} encapsulate the context in which the error occurred (e.g., Profile Management, \gls{isdr} interactions).
@@ -30,7 +30,7 @@ Robust exception handling is critical in the context of \gls{euicc} interactions
All exceptions inherit from a common \texttt{EuiccException} base class, ensuring they can be captured uniformly when needed.
\subsection*{Exception Hierarchy}
\marginpar{Hierarchy enables both broad and precise exception handling.}
The exception hierarchy is structured such that all specific error exceptions (e.g. \texttt{IccidNotFound}) inherit from a relevant function exception (e.g. \texttt{ProfileInteractionException}), which itself inherits from \texttt{EuiccException}. This enables both precise and broad exception matching, depending on the caller’s needs. For example:
\begin{center}
@@ -86,6 +86,7 @@ class IccidOrAidNotFound(EuiccException):
\subsection*{Benefits}
This exception model provides the following advantages:
\marginpar{Clean exception abstraction improves introspection during fuzzing and test execution.}
\begin{itemize}
\item \textbf{Modular extensibility:} New error types can be added per function with minimal changes.
\item \textbf{Granular diagnostics:} Developers can differentiate between general failure (\texttt{ProfileInteractionException}) and specific causes (\texttt{IccidNotFoundException}).
@@ -100,11 +101,11 @@ This exception system enables detailed introspection during fuzzing and testing
\label{sec:cli_structure}
The CLI is organized around three core commands:
\begin{itemize}
\item \textbf{tracing} — Interfaces with the \texttt{simtrace2} device and the \gls{lpa} to capture \gls{apdu} traffic in real time. This functionality is discussed in detail in \cref{sec:tracing}.
\item \textbf{tracing} — Interfaces with the \texttt{simtrace2} device and the \gls{lpa} to capture \gls{apdu} traffic in real time. This functionality is discussed in detail in \cref{sec:tracing}.\marginpar{CLI provides tracing, lpa, and fuzzing commands for core system interaction.}
\item \textbf{lpa} — Exposes \gls{euicc} communication features such as profile management, notification handling, and remote procedure execution via the \gls{cli}.
\item \textbf{fuzzing} — Wraps both \gls{apdu}-level and data-level fuzzing. Additionally, it provides a \texttt{compare} command to compare multiple trace recordings and highlight structural differences in JSON format.
\end{itemize}
\marginpar{Each CLI command resides in a dedicated subfolder.}
Each of these commands is implemented in its respective subfolder (e.g., \texttt{tracing/}, \texttt{lpa/}, \texttt{fuzz/}). The modular structure of the \gls{cli} is shown in \cref{fig:cli_structure}, which illustrates how the subcommands map to the file and folder hierarchy of the project.
\begin{figure}[h]
@@ -186,7 +187,7 @@ Each subcommand module (e.g., \texttt{fuzz/data\_fuzz.py}) provides its own pars
\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}.
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.\marginpar{Each R-APDU ends with a 16-bit Status Word indicating command execution outcome.} 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.
@@ -194,7 +195,7 @@ Some SW codes contain fixed values, whereas others use placeholders (represented
\centering
\begin{tabular}{|c|p{10cm}|}
\hline
\textbf{SW Code} & \textbf{Meaning} \\
\textbf{SW Code} & \textbf{Description} \\
\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. \\

24
Chapters/Background.tex
View File

@@ -37,7 +37,7 @@ Interaction with the \gls{sim} is governed by an embedded operating system \cite
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}
\paragraph{Standards.}
% - how SIMs operate and function is defined by 3 parties: ETSI, 3GPP, and the GSMA
% - ETSI: defines how the SIM works as a platform i.e UICC hardware, how APDU are structured and work, and the smart card file system (cite TS 131 221)
% - 3GPP: defines how the SIMs are integrated into the mobile networks by defining the mobile broadband standards such as 5G and LTE
@@ -123,7 +123,7 @@ The main \gls{gsma} \gls{esim} specifications can be categorized as follows:
\cref{tab:euicc_m2m_consumer} and \cref{tab:euicc_iot_infactory} compare the \gls{gsma} specifications and highlight their differences.
\paragraph{Transport Protocols}
\paragraph{Transport Protocols.}
% - ETSI defines two protocols for communication: T=0 and T=1
% - T=0: half-duplex asynchronos asynchronous character based transmission protocol
% - T=1: half-duplex asynchronous block based transmission protocol, is in several ways more advanced than t=0: better error correction, APDU chaining, better in handling large APDUs etc, but also has more overhead due to block headers, control fields, way more complex in comparison to t=0 (cite TS 102 221)
@@ -138,7 +138,7 @@ In contrast, T=1 is a half-duplex, asynchronous, block-oriented protocol. It int
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.
\paragraph{Application/Transportation Protocol Data Unit}
\paragraph{Application/Transportation Protocol Data Unit.}
% - we differentiate between APDU (Application layer) and TPDUs (transport layer)
% - when sending APDUS to the UICC wthe ETSI defines them as C-APDUs (command apdus) and the responses from the UICC as R-APDUs (response apdus)
% - on the tansport layer those are C-TPDUs and R-TPDUs respectivly
@@ -188,7 +188,7 @@ The status word (SW) in an R-APDU signifies whether a command was successfully p
\paragraph{Data Encoding}
\paragraph{Data Encoding.}
% - when requesting data or storing data on the UICC the command data uses ASN.1 with BER-TLV encoding
% - ASN.1 is a language that describes the sequence, the data and the encoding of the data that is used in a communication protocol (cite oss_nokalva)
% - it is a mature and widly spread technology especially in the telecommunications field
@@ -196,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.\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.}
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}.
\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.
@@ -223,7 +223,7 @@ The \gls{gsma} provides \gls{asn1} definitions for all standardized \gls{rsp} fu
\paragraph{File Structure}
\paragraph{File Structure.}
% - the file structure on an UICC is organized as an forest of trees (cite TS 102 221
% - Dedicated files (DF) allows for functional grouping of files
@@ -245,7 +245,7 @@ Each file is uniquely identified by a File Identifier (FID), while applications
To access files, the \texttt{SELECT} command is used. This command supports various addressing modes: by FID, \gls{aid}, complete path, or short FID. Importantly, file selection is stateful, meaning that parent files or applications must be selected before accessing child files.
\paragraph{Application Toolkit}
\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}.\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.
@@ -275,7 +275,7 @@ These profiles reside on the underlying \gls{euicc} hardware and can be provisio
This architecture introduces a remote provisioning mechanism and significantly enhances user flexibility, while simultaneously introducing new complexity in terms of protocol design and implementation correctness.
\paragraph{eUICC Components}
\paragraph{eUICC Components.}
\label{par:euicc_components}
% - to manage and issue newe eSIM profiles the eUICC needs some relevant Applications
@@ -314,7 +314,7 @@ These applications are typically addressed via their \glspl{aid}, some of which
However, the actual \glspl{aid} used are implementation-specific and may be customized by the manufacturer. The \gls{isdr} \gls{aid} in particular is often modified, as discussed in \cref{sec:eval_tracing}.
\paragraph{eSIM-on-SIM}
\paragraph{eSIM-on-SIM.}
% - most popular option of integrating esims is directly soldering them onto the cricuit board of a smartphone
% - since the soldered esim is near identical to the SIMs normally distributed as physical SIMs -> esims can also be distributed as physical esims -> enables non esim capable phones to use esims
@@ -336,7 +336,7 @@ However, the actual \glspl{aid} used are implementation-specific and may be cust
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}
\paragraph{Local Profile Assistant.}
\label{par:lpa}
\begin{figure}[t]
@@ -453,7 +453,7 @@ In this work, we focus on the Authentication Code method due to its prevalence i
\end{tabular}
\end{table}
\paragraph{Mutual Authentication}
\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}.\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.
@@ -475,7 +475,7 @@ During the installation, a specific sequence of packages is exchanged between th
\item The actual profile elements are loaded using the \texttt{sequence\-Of86} package.
\end{enumerate}
\paragraph{Notification}
\paragraph{Notification.}
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.

4
Chapters/Conclusions.tex
View File

@@ -13,8 +13,8 @@
% reverse engineered the estk.me update mechanism
This thesis presented a systematic security analysis of commercial eSIM-on-SIM card implementations through the application of differential testing. Given the opaque and proprietary nature of most \gls{euicc} firmware, black-box testing approaches remain one of the few viable options for assessing correctness and security in deployed systems. With the design and implementation of a custom framework, this work introduces a reproducible method for identifying behavioral inconsistencies across vendor-specific \gls{esim} implementations.
This thesis presented a systematic security analysis of commercial eSIM-on-SIM card implementations through the application of differential testing.\marginpar{Thesis introduces a differential testing framework to analyze commercial eSIM-on-SIM card implementations.} Given the opaque and proprietary nature of most \gls{euicc} firmware, black-box testing approaches remain one of the few viable options for assessing correctness and security in deployed systems. With the design and implementation of a custom framework, this work introduces a reproducible method for identifying behavioral inconsistencies across vendor-specific \gls{esim} implementations.
The developed framework integrates trace recording, scenario-driven testing, and property-based structured fuzzing, allowing the systematic mutation and replay of \gls{apdu} traces. The combination of syntactically valid \gls{asn1}-based input generation with deterministic mutation provides a strong fuzzing implementation. Through this approach, several notable implementation differences were identified, including a critical certificate validation bypass in one vendor’s \gls{euicc} side provisioning logic.
The developed framework integrates trace recording, scenario-driven testing, and property-based structured fuzzing, allowing the systematic mutation and replay of \gls{apdu} traces. The combination of syntactically valid \gls{asn1}-based input generation with deterministic mutation provides a strong fuzzing implementation.\marginpar{It reveals security flaws and highlights the need for independent implementation validation across vendor implementations.} Through this approach, several notable implementation differences were identified, including a critical certificate validation bypass in one vendor’s \gls{euicc} side provisioning logic.
These findings highlight the importance of independent verification and validation of \gls{esim} implementations. The observed deviations from \gls{gsma} specifications suggest that even well-established standards do not guarantee uniform security guarantees across vendors. Differential testing, as demonstrated, offers a scalable and automation-friendly approach to detect such inconsistencies without requiring access to proprietary source code.

2
Chapters/Design.tex
View File

@@ -65,7 +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}
\marginpar{reSIMulate is a differential testing framwork for eSIM analysis}
To achieve these goals, we propose a modular three-layered architecture:

21
Chapters/Discussion.tex
View File

@@ -61,19 +61,19 @@
% implement own software euicc and smdpp and add hypothesis rule based state machine support -> directly compare own implementation of smdpp server or euicc to actual behaviour with fuzzing input
The primary goal of this thesis was to assess the security posture and behavioral consistency of commercial eSIM-on-SIM products through differential testing. To this end, we developed a custom black-box testing framework capable of performing APDU-level fuzzing, structured \gls{asn1} mutation, and trace-based cross-device comparisons. Our evaluation was conducted on eight commercially available eSIM-on-SIM cards from three distinct vendors, revealing a diverse and fragmented implementation landscape.
\marginpar{Eight cards from three vendors revealed fragmented architectures and implementation inconsistencies.}
Our findings indicate substantial architectural differences across implementations. For instance, some \glspl{euicc}, such as the one from estk.me, omit the standard \gls{isdr} application altogether and instead expose functionality solely via the \gls{usat} interface. This approach also offers a privately hosted \gls{rlpa} server for provisioning \cite{estkme_rlpa-server_2025}, circumventing the \glsposs{gsma} standardized infrastructure and raising questions regarding compliance and security. Other implementations (\eg, 5ber, Xesim, eSIM.me) do include \gls{isdr} support, but use vendor-specific \glspl{aid}, deviating from the default identifiers specified in SGP.22. These differences complicate interoperability and testing, while also highlighting the absence of a uniform baseline across implementations.
A key contribution of our work is the observation of different behaviors in response to identical \gls{rsp} inputs. Mutated \gls{asn1} payloads triggered undefined behavior in several \glspl{euicc}, including silent failures, unexpected success responses, and inconsistent status words. In multiple instances, we observed malformed requests that bypassed expected validation routines, particularly during the certificate authentication phase. One notable case revealed a likely certificate validation bypass, where corrupted \texttt{AuthenticateServerRequest} messages were accepted despite invalid or tampered certificates. This suggests that parts of the certificate verification pipeline were either improperly implemented or incorrectly reused from prior sessions without sufficient integrity checks.
A key contribution of our work is the observation of different behaviors in response to identical \gls{rsp} inputs. Mutated \gls{asn1} payloads triggered undefined behavior in several \glspl{euicc}, including silent failures, unexpected success responses, and inconsistent status words.\marginpar{Bypassing certificate validation breaks GSMA trust model and opens door to rogue profile injection.} In multiple instances, we observed malformed requests that bypassed expected validation routines, particularly during the certificate authentication phase. One notable case revealed a likely certificate validation bypass, where corrupted \texttt{AuthenticateServerRequest} messages were accepted despite invalid or tampered certificates. This suggests that parts of the certificate verification pipeline were either improperly implemented or incorrectly reused from prior sessions without sufficient integrity checks.
The implications of such inconsistencies are significant. Bypassing certificate validation undermines the trust model of the \gls{gsma} \gls{rsp} architecture, as the certificate chain rooted in the \gls{gsma} \gls{ca} can no longer be reliably enforced. An attacker able to craft malicious authentication messages, potentially by compromising or distributing malicious \glspl{lpa}, could install rogue profiles onto the \gls{euicc}. While a valid \gls{gsma}-signed profile is still required, this opens the door for profile injection attacks, man-in-the-middle (MITM) provisioning manipulation, and potentially persistent compromise of the device. Previous research, such as that by \textcite{lisowski_simurai_2024}, has demonstrated the feasibility of malicious \gls{sim} cards. However, their work focused on runtime behavior and not on provisioning vulnerabilities. Our findings extend this threat model by targeting the provisioning pipeline itself.
The implications of such inconsistencies are significant. Bypassing certificate validation undermines the trust model of the \gls{gsma} \gls{rsp} architecture, as the certificate chain rooted in the \gls{gsma} \gls{ca} can no longer be reliably enforced. An attacker able to craft malicious authentication messages, potentially by compromising or distributing malicious \glspl{lpa}, could install rogue profiles onto the \gls{euicc}. While a valid \gls{gsma}-signed profile is still required, this opens the door for profile injection attacks, man-in-the-middle (MITM) provisioning manipulation, and potentially persistent compromise of the device.\marginpar{Previous research focused on runtime behavior, this work targets the provisioning pipeline.} Previous research, such as that by \textcite{lisowski_simurai_2024}, has demonstrated the feasibility of malicious \gls{sim} cards. However, their work focused on runtime behavior and not on provisioning vulnerabilities. Our findings extend this threat model by targeting the provisioning pipeline itself.
Several cards also revealed additional security concerns. One exposed endpoints for firmware updates that fall outside the \gls{gp} command set, suggesting the existence of non-standard, vendor-specific mechanisms for critical operations. The presence of undefined error states, typically in the form of generic status words (\eg, \texttt{6F00}) or generic Errors (\eg, \texttt{UndefinedError}), indicates insufficient internal error handling. In some cases, malformed inputs resulted in successful operations, pointing to either faulty \gls{asn1} decoding or logical flaws in the parsing routines.
\marginpar{Closed-source firmware limits root cause analysis and vendor-specific vulnerability attribution.}
Being able to reproduce these findings across multiple cards supports the claim that profile management logic is often implemented in a non-specification conforming way. Unfortunately, due to the \gls{euicc} firmware being a closed-source implementation, the lack of verbose error logging, and official debugging interfaces, root cause analysis remains difficult. This significantly reduces the ability to differentiate between vendor-specific variations and actual security vulnerabilities.
In terms of research landscape, this thesis complements prior work that either focused on malicious runtime \gls{sim} behavior \cite{lisowski_simurai_2024} or employed formal methods to analyze the \gls{rsp} protocol \cite{ahmed_security_2024}. Unlike those approaches, our methodology provides empirical, implementation-level insights through the differential testing of live, commercial-grade eSIM-on-SIM products. Compared to existing tools such as SimTester~\cite{security_research_labs_simtester_2025}, which are tailored to legacy \gls{sim} cards and lack support for eSIM-specific features (e.g., \gls{isdr}, \gls{isdp}), our framework directly targets the modern provisioning stack.
\marginpar{Limitations include lack of IoT card availability, partial protocol coverage, and SM-DP+ exclusion.}
While the results demonstrate the effectiveness of our framework, several limitations should be noted. First, our testing was confined to the SGP.21 and SGP.22 consumer specification. The newer \gls{iot}-centric specification, defined SGP.31 and SGP.32, were not evaluated due to a lack of publicly available \gls{iot}-targeted eSIM-on-SIM cards and the additional infrastructure they require. Second, although our fuzzing engine supports both structural and transport-level mutation, protocol coverage remains inherently bounded. Some branches in the protocol logic may not have been exercised. Additionally, our evaluation focused primarily on the \gls{euicc} side of the \gls{rsp} protocol. The \gls{smdpp} servers, which are integral to the provisioning process, were treated as opaque black boxes. Since most commercial \gls{smdpp} implementations are closed source and fuzzing them could be seen as a malicious \gls{dos} attack, they were mostly excluded from testing. The only publicly available implementation, osmo-smdpp, was not integrated due to scope limitations.
To mitigate the certificate reuse issue observed, we recommend stricter cryptographic context isolation, including flushing session state after failed provisioning attempts. This would reduce the risk of unintended reuse of sensitive materials across sessions.
@@ -82,10 +82,19 @@ To mitigate the certificate reuse issue observed, we recommend stricter cryptogr
\section{Future Work}
\label{sec:future_work}
This work can be extended in several directions. First, the \gls{lpa} implementation could be extended to support SGP.31/SGP.32 and SGP.41/SGP.42 specific functionality, enabling testing of \gls{iot}-specific provisioning flows and factory provisioning procedures as soon as implementations become available. Second, to achieve full-loop fuzzing, future versions of the framework could integrate a self-hosted \gls{smdpp} server equipped with test certificates and profiles. This would allow end-to-end testing of the complete \gls{rsp} lifecycle.
This work can be extended in several directions. First, the \gls{lpa} implementation could be extended to support SGP.31/SGP.32 and SGP.41/\-SGP.42 specific functionality, enabling testing of \gls{iot}-specific provisioning flows and factory provisioning procedures as soon as implementations become available.\marginpar{Self-hosted SM-DP+ would enable full end-to-end RSP fuzzing.} Second, to achieve full-loop fuzzing, future versions of the framework could integrate a self-hosted \gls{smdpp} server equipped with test certificates and profiles. This would allow end-to-end testing of the complete \gls{rsp} lifecycle.
Additionally, adding support for proactive commands to the fuzzing engine would enable testing of \gls{euicc} cards that expose only \gls{usat}-based interfaces, such as those from estk.me and 9esim v2. This addition would broaden the scope of the framework, allowing it to address a wider range of commercial \gls{esim} implementations and significantly increase protocol coverage.
Finally, improvements to the fuzzing engine itself, such as incorporating a Hypothesis rule based state machine, would allow direct behavioral comparisons between custom \gls{smdpp} and \gls{euicc} implementations and proprietary systems.
\marginpar{Further analysis is needed for certificate validation caching vulnerability.}
Beyond general improvements to the framework, further work is needed to fully understand and analyze the discovered vulnerability related to certificate validation caching during the \texttt{Authenticate\-Server\-Request}. This will involve:
\begin{itemize}
\item Isolating which fields from $AS_1$ are retained in the cache and reused during $AS_2$ (e.g., public key, issuer name, signature fields, etc.).
\item Reproducing the attack with a fully synthetic and attacker-controlled certificate chain.
\item Verifying whether the attack can be conducted using arbitrary \gls{smdpp} endpoints and activation codes.
\item Investigating whether other stateful fields (e.g., \texttt{serverSigned1}, \texttt{serverChallenge}) are also reused.
\end{itemize}

66
Chapters/Evaluation.tex
View File

@@ -23,7 +23,7 @@ The primary objective of this evaluation is to apply differential testing to ana
\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}.
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 \gls{apdu}-level communication with the inserted \glspl{euicc}.
\begin{table}[ht]
\centering
@@ -131,8 +131,8 @@ 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.}
The firmware image accompanying the update utility appears to be encrypted or obfuscated.
\marginpar{Firmware entropy analysis suggests encryption or compression.} 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, which is running on our estk.me \gls{euicc}, was measured at approximately \texttt{7.998}, which is close to the theoretical maximum of \texttt{8.0} for purely random data.
\begin{figure}[ht]
\centering
@@ -173,7 +173,6 @@ The firmware image accompanying the update utility appears to be encrypted or ob
\end{axis}
\end{tikzpicture}
\caption{Shannon entropy values across blocks for three different firmware versions.}
\todo{explain drop off at 200}
\end{figure}
A deeper static analysis using Ghidra~\cite{nsa_ghidra_2025} did not reveal any recognizable structure or file headers, further supporting the assumption of encryption. Similarly, tools like Binwalk~\cite{refirmlabs_binwalk_2025} did not detect known compression schemes, embedded file systems, or file signatures. Consequently, firmware payload analysis could not be meaningfully performed beyond block-level transmission.
@@ -192,8 +191,7 @@ 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.
Firmware versions follow the format \texttt{TXXXVXX}, where major generation (\texttt{T000}--\texttt{T003}) and minor version are encoded.\marginpar{Firmware follows one-way TXXXVXX versioning with no downgrade support.} 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 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/}.
@@ -206,8 +204,8 @@ 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}.\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.
\item Each block is sent in subchunks, using standard \glspl{apdu} (\texttt{CLA=0xAA}) with \texttt{INS=0x11}.
\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.\marginpar{Firmware is split into blocks, then subchunks for transmission and verification.} 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.
\item \textbf{Finalize}: The \gls{apdu} \texttt{AA00000000} marks the end of the update process.
@@ -301,7 +299,7 @@ While tracing provides valuable insights into command sequencing and \gls{aid} s
\label{sec:data_fuzzing_evaluation}
\begin{table}[t]
\begin{adjustwidth}{-.5in}{-1.5in}
\begin{adjustwidth}{-1.5in}{-.5in}
\centering
\caption{Data fuzzing results for for all tested eSIM-on-SIM cards. }
\label{tab:data_fuzzing_result}
@@ -333,7 +331,7 @@ We conducted data fuzzing, as described in \cref{subsec:data_fuzzing}, on all te
\caption{Fuzzing setup}
\label{img:fuzz_setup}
\end{figure}
\marginpar{Most cards responded to fuzzed inputs with correct or graceful error handling.}
The majority of the cards handled the fuzzed input data as expected, either processing the requests successfully or rejecting them gracefully with standard-compliant error responses. However, notable exceptions were observed during the execution of the \texttt{GetProfileInfo} test case as shown in \cref{tab:data_fuzzing_result}, particularly for the following cards:
\begin{itemize}
\item 9esim
@@ -348,6 +346,7 @@ get_profiles(use_iccid=False, profile_class=None, tags=b'')
\end{lstlisting}
resulted in a \texttt{CardConnection\-Exception} raised by the \texttt{smartcard} Python library during \gls{apdu} transmission.
\marginpar{Failures resulted in CardConnectionException during APDU transmission indicating potential undefined state in libpcsc.}
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.
@@ -419,9 +418,9 @@ The LED activity ceased only when the card reader was fully disconnected from th
To evaluate the robustness of \gls{rsp} protocol handling and smart card behavior under malformed input, we applied mutation-based fuzzing at the \gls{apdu} level. The goal was to explore unintended code paths and observe crash conditions or unexpected responses.
\subsection*{Optimizing for Coverage}
Initial fuzzing experiments revealed that applying aggressive mutations across all \glspl{apdu} early in a transaction significantly hindered code path exploration. In many cases, although a mutation in an early \gls{apdu} succeeded in provoking an altered behavior or state change, subsequent mutated \glspl{apdu} caused premature failures. As a mitigation strategy, we adopted a greedy mutation approach: once a mutation led to a successful state transition, the subsequent \glspl{apdu} in that session were executed unmutated to allow complete transaction processing and thereby maximize coverage.
Initial fuzzing experiments revealed that applying aggressive mutations across all \glspl{apdu} early in a transaction significantly hindered code path exploration.\marginpar{Greedy mutation strategy preserves successful state transitions to maximize coverage depth.} In many cases, although a mutation in an early \gls{apdu} succeeded in provoking an altered behavior or state change, subsequent mutated \glspl{apdu} caused premature failures. As a mitigation strategy, we adopted a greedy mutation approach: once a mutation led to a successful state transition, the subsequent \glspl{apdu} in that session were executed unmutated to allow complete transaction processing and thereby maximize coverage.
\paragraph{Experimental Setup}
\paragraph{Experimental Setup.}
All tests are conducted with test profiles that use the \gls{gsma} Live CI and are offered by various \glspl{mno}~\cite{welte_euicc_2024} and the hardware setup as shown in \cref{img:fuzz_setup} For consumer-grade \glspl{esim}, the following profile was used:
\begin{center}
\texttt{LPA:1\$rsp.truphone.com\$QR-G-5C-1LS-1W1Z9P7}
@@ -434,7 +433,7 @@ For the \texttt{sysmoEUICC}, which uses the \gls{gsma} test certificate, the fol
The execution time of fuzzed \gls{apdu} sequences varied depending on chip processing speed and the degree to which the mutated input triggered deeper protocol branches.
\paragraph{Observed Errors}
\paragraph{Observed Errors.}
% The following classes of errors were consistently encountered during mutation campaigns:
%
% \todo{Put errors into a table with example mutations and explain in text}
@@ -531,6 +530,7 @@ During the mutation-based differential testing campaing several distinct error t
One of the most frequently encountered errors was \textbf{SCP03TSecurity\-Error}, which emerged during the execution of the \texttt{LoadBoundProfile\-Package} operation. Specifically, this error was triggered during the transmission of either \texttt{sequence\-Of86}, \texttt{sequence\-Of88}, or the initial \texttt{sequence\-Of87}, pointing to a failure in establishing the Secure Channel Protocol 03 session on the terminal side.
Another recurring issue was the \textbf{ApduException}, which was caused by malformed \gls{asn1} structures. These were typically introduced by mutations that altered either the tag or the length fields within the encoded data, leading to parsing failures during transmission.
\marginpar{Observed exceptions result from malformed ASN.1 structures, cryptographic validation failures, or protocol violations during secure channel setup.}
The \textbf{InvalidCertificate} error was predominantly seen during the \texttt{AuthenticateServer} and \texttt{PrepareDownload} commands. In these cases, the \gls{euicc} explicitly rejected the provided server certificate, signaling a failure in certificate validation, possibly due to mutations in the certificate’s structure or encoding.
@@ -547,7 +547,7 @@ Finally, a critical issue on the decoding side was \textbf{DecodeTagError}, rais
\begin{quote}
\texttt{euiccSignature1: Expected OCTET STRING (tag '5f37'), but got '2474'. (At offset: 271)}
\end{quote}
\marginpar{ASN.1 decoder failed to interpret malformed tags or structure in EUICC response.}
Such decoding failures indicate inconsistencies between the expected \gls{ber}-encoded tags and the actual mutated values, likely due to truncated structures or corrupted length fields. Notably, in some cases, the \gls{euicc} still accepted and responded to these malformed \gls{apdu}s, albeit with corrupted payloads.
To aid in the analysis and comparison, Table~\ref{tab:error_overview} summarizes these errors alongside example original and mutated payloads.
@@ -693,23 +693,21 @@ To aid in the analysis and comparison, Table~\ref{tab:error_overview} summarizes
To further understand the behavior of different \glspl{euicc} under mutation-based fuzzing, we post-processed all recorded \gls{apdu} traces.
\subsubsection*{Mutation Examples}
Successful mutations were observed on \texttt{eSIM.me}, \texttt{5ber}, \texttt{Xesim}
Successful mutations were observed on \texttt{eSIM.me}, \texttt{5ber}, \texttt{Xesim}, \texttt{9esim}, and \texttt{9esim v2}.
\paragraph{GET\_EUICC\_INFO\_1 Truncation}
\paragraph{GET\_EUICC\_INFO\_1 Truncation.}
A truncated \gls{apdu} with trailing padding bytes removed (e.g., \texttt{BF2000} $\rightarrow$ \texttt{BF20}) was still accepted and processed successfully by several \glspl{euicc}. This indicates that, for some non-critical operations, strict \gls{ber}/\gls{der} tag integrity is not enforced.
\paragraph{FIRSTSEQUENCEOF87 Bitflip}
\paragraph{FIRSTSEQUENCEOF87 Bitflip.}
A single-bit mutation changed a byte from \texttt{0xA0} to \texttt{0xA1}. Despite the low-level alteration, the \gls{apdu} was accepted, suggesting a fallback to an alternate logical channel or slightly different interpretation of \gls{tlv} structure.
\paragraph{AUTHENTICATE\_SERVER Truncation}
In one case, the mutation engine truncated approximately 75\% of the \texttt{AuthenticateServer\-Request} \gls{apdu}, removing critical fields such as \texttt{ctxParams1}, the digital signature, and certificate extensions (including \texttt{2.5.29.14}, \texttt{2.5.29.17}, \texttt{2.5.29.35}). The \gls{apdu} failed \gls{asn1} decoding due to inconsistent length indicators. However, after manual correction, analysis revealed that the missing fields did not prevent the \gls{euicc} from accepting the request under specific conditions.
\todo{Try to find some more fuzzing statistics i.e runs, mutations per second, explored paths}
\paragraph{AUTHENTICATE\_SERVER Truncation.}
In one case, the mutation engine truncated approximately 75\% of the \texttt{AuthenticateServer\-Request} \gls{apdu},\marginpar{AuthenticateServer truncation removed critical fields but was accepted under certain conditions.} removing critical fields such as \texttt{ctxParams1}, the digital signature, and certificate extensions (including \texttt{2.5.29.14}, \texttt{2.5.29.17}, \texttt{2.5.29.35}). The \gls{apdu} failed \gls{asn1} decoding due to inconsistent length indicators. However, after manual correction, analysis revealed that the missing fields did not prevent the \gls{euicc} from accepting the request under specific conditions.
\subsection{Certificate Validation Bypass}
\label{subsec:certificate_bypass}
According to SGP.22~\cite{gsma_sgp22_2025}, secure channel establishment between the \gls{lpa} and the \gls{euicc} mandates server authentication. The client, the \gls{euicc}, must validate the server’s X.509 certificate chain, ensuring that it is rooted in the \gls{gsma} Root \gls{ca}. Furthermore, the digital signature of the \texttt{AuthenticateServerRequest} must be verified before continuing with profile download and installation:
According to SGP.22~\cite{gsma_sgp22_2025}, secure channel establishment between the \gls{lpa} and the \gls{euicc} mandates server authentication. The client, the \gls{euicc}, must validate the server’s X.509 certificate chain, ensuring that it is rooted in the \gls{gsma} Root \gls{ca}.\marginpar{SGP.22 specification require successful Certificate chain verification.} Furthermore, the digital signature of the \texttt{AuthenticateServerRequest} must be verified before continuing with profile download and installation:
\begin{quote}
``The Server (the entity providing the function, e.g., \gls{smdpp}) SHALL be authenticated first by the Client (the entity requesting the function). Authentication SHALL include the verification of a Server Certificate chain ending at an \gls{esim} \gls{ca} RootCA Certificate (section 4.5.2).''~\cite{gsma_sgp22_2025}
@@ -727,6 +725,7 @@ To assess real-world conformance with these expectations, the following research
\label{sec:rq1-truncation}
To determine whether certificate validation is properly enforced, a sequence of mutated \texttt{AuthenticateServerRequest} messages was issued. A first request $AS_1$ was crafted with a malformed certificate $Cert_{Sa}^{(1)}$, where a single bit was flipped in the \gls{asn1} tag field of the certificate’s `SEQUENCE`, changing \texttt{BF38} to \texttt{BE38}. This triggered a potential decoding failure on the \gls{euicc} to reject the request, as expected.
\marginpar{Truncated certificate without signature is improperly accepted by the eUICC.}
Subsequently, a second request $AS_2$ was sent containing a structurally correct, but truncated version of $Cert_{Sa}^{(2)}$, lacking the digital signature and extensions required for complete X.509 validation. Despite these omissions, the \gls{euicc} accepted the request and proceeded to complete the profile installation. From the perspective of the \gls{lpa}, \gls{asn1} parsing failed, yet the \gls{euicc} made a trust decision as if the certificate were valid.
@@ -736,7 +735,7 @@ This demonstrates a critical breakdown in the certificate validation process, in
\label{sec:rq2-caching}
To explore whether the \gls{euicc} caches data across authentication attempts, additional mutation experiments were performed. After a failed $AS_1$ with a corrupted certificate, a valid truncated certificate was accepted in $AS_2$, provided that both requests originated from the same \gls{smdpp}.
\marginpar{Cross-server attack fails, showing state is scoped to SM-DP+ identity.}
We performed a set of differential tests across two configurations:
\begin{itemize}
\item \textbf{Same-server scenario:} Using two activation codes issued by the same provider (e.g., \texttt{QR-G-5C-1LS-1W1Z9P7} and \texttt{QRF-SPEEDTEST}), the attack succeeded.
@@ -764,7 +763,7 @@ Analysis of the \gls{apdu} payloads in failed $AS_1$ requests revealed consisten
\item \texttt{serverCertificate.serialNumber}
\item \texttt{serverSigned1.serverChallenge}
\item \texttt{serverSignature1}
\end{itemize}
\end{itemize}\marginpar{Cross-server mutations fail even under identical truncation conditions.}
\item In cross-server experiments, mutations in \texttt{server\-Challenge}, \texttt{server\-Signature1}, and other cryptographic fields caused the attack to fail, even when truncation was applied identically.
\end{itemize}
@@ -774,7 +773,7 @@ These observations suggest that state retention is selective and scoped to prior
\label{sec:rq3-signature}
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.
\marginpar{Signature check is bypassed by reusing cached state.}
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.
\subsection{Implications}
@@ -785,16 +784,16 @@ The observed behavior constitutes a severe violation of the security architectur
\begin{enumerate}
\item \textbf{Bypassed Certificate Validation:} The \gls{euicc} accepts truncated certificates lacking critical fields, including the digital signature and X.509 extensions.
\item \textbf{Persistent State Caching:} Cryptographic or trust-related state is cached across sessions and power cycles, even in response to malformed input.
\item \textbf{Skipped Signature Verification:} The \gls{euicc} does not re-verify signatures if a previously failed request cached valid key material.
\item \textbf{Skipped Signature Verification:} The \gls{euicc} does not re-verify signatures if a previously failed request cached valid key material.\marginpar{eUICCs cache trust state and accept truncated certificates, enabling scoped signature verification bypasses.}
\item \textbf{Server-Scoped Trust Decisions:} State reuse is scoped to the \gls{smdpp} identity, allowing targeted trust bypasses under controlled conditions.
\end{enumerate}
Together, these issues expose an attack surface where adversaries can craft a sequence of malformed requests to poison the internal state of the \gls{euicc}. Once in this compromised state, the \gls{euicc} may proceed with mutual authentication and secure channel establishment, even in the absence of a complete or verifiable certificate chain. This behavior violates the security expectations in Sections 4.5.1 and 4.5.2 of the SGP.22 specification~\cite{gsma_sgp22_2025}, which require end-entity certificate validation and strict signature verification for all authentication steps.
\marginpar{Only Eastcompeace devices were affected; other vendors behaved correctly.}
The certificate bypass was only observed on \glspl{euicc} manufactured by \textbf{Eastcompeace}. Devices from other vendors did not exhibit this behavior under the same test conditions, suggesting an implementation-specific vulnerability in Eastcompeace firmware or certificate handling logic.
\subsection{Limitations and Future Work}
\subsection{Limitations}
\label{sec:limitations}
While the truncation-based bypass demonstrates a significant weakness in the certificate validation logic, it is not yet clear whether this vulnerability enables complete provisioning from an attacker-controlled \gls{smdpp}. The current attacks rely on prior interaction with a legitimate \gls{smdpp} that successfully injects a partially valid certificate into the \gls{euicc}'s internal state.
@@ -804,18 +803,9 @@ An open research question remains:
\begin{quote}
\textit{Can an attacker-controlled \gls{smdpp} successfully provision a profile on a vulnerable \gls{euicc} by leveraging this truncation-based bypass, without ever presenting a valid certificate chain anchored in the \gls{gsma} Root \gls{ca}?}
\end{quote}
\marginpar{Unclear if provisioning can occur entirely from attacker-controlled SM-DP+ infrastructure.}
In other words, can the bypass be generalized to completely circumvent the certificate trust model, enabling profile installation from an untrusted or rogue infrastructure? If confirmed, this would constitute a full break of the \gls{gsma} trust model and pose significant implications for mobile network operators and \gls{esim} vendors.
Future work will involve:
\begin{itemize}
\item Isolating which fields from $AS_1$ are retained in the cache and reused during $AS_2$ (e.g., public key, issuer name, signature fields, etc.).
\item Reproducing the attack with a fully synthetic and attacker-controlled certificate chain.
\item Verifying whether the attack can be conducted using arbitrary \gls{smdpp} endpoints and activation codes.
\item Investigating whether other stateful fields (e.g., \texttt{serverSigned1}, \texttt{serverChallenge}) are also reused or must be aligned.
\end{itemize}
% \paragraph{Expected Behavior.}
% SGP.22 describes the expected server-client authentication behaviour as follows:

12
Chapters/Implementation.tex
View File

@@ -205,7 +205,8 @@ The \gls{smdpp} client is primarily used by our \gls{isdr} application to execut
\section{Fuzzing}
\label{sec:fuzzing}
\todo{Section summary}
The following section introduces the implementation of two core fuzzing components: \gls{apdu}-level fuzzing and structured data fuzzing. These components enable the systematic exploration of protocol edge cases and semantic inconsistencies in \gls{euicc} behavior.
\subsection{APDU Fuzzing}
\label{subsec:apdu_fuzzing}
@@ -568,10 +569,9 @@ Specifically, we implemented fuzzing tests for the following functions:
During the \texttt{setUpClass} phase, a PC/SC link is initialized, and the \gls{euicc} is prepared (\eg, by installing a test profile) to ensure the preconditions for each function are met. After executing the class's test suite, the \texttt{eUICCMemoryReset} function is called with all reset options enabled to restore a clean state. All leftover notifications are processed to leave the card in a consistent state for subsequent tests.
\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.
According to the SGP.22 specification, many functions may return a generic \texttt{UndefinedError} in response to unexpected or malformed input. In our implementation, 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.
\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.
By contrast, exceptions raised by the \gls{euicc} that map to well-defined error codes (\ie, 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.
\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}.
@@ -607,9 +607,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.
The CLI structure is further detailed in \cref{sec:cli_structure}.
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. The CLI structure is further detailed in \cref{sec:cli_structure}.
\paragraph{Integration with Pytest.}
The data fuzzing component internally wraps \texttt{pytest}, leveraging the structure of Python test classes defined with the Hypothesis framework (cf. Section~\ref{subsec:data_fuzzing}). Each test class corresponds to a group of \gls{rsp} commands. By invoking the data fuzzing \gls{cli}, all available test classes are executed against the connected \gls{euicc}, with proper initialization and teardown logic handled automatically.

2
Chapters/Introduction.tex
View File

@@ -115,7 +115,7 @@ The thesis begins with an overview of \gls{sim} and \gls{esim} technologies in \
In \cref{ch:relatedwork}, it surveys related work in the domain of \gls{sim} and \gls{esim} security, focusing on academic literature, emulation frameworks, and software tools used for analysis.
The implementation of the proposed differential testing framework is described in \cref{ch:implementation}, covering the tracing infrastructure, \gls{apdu} mutation engine, and structured input generation logic.
The design is described in \cref{ch:design} and the implementation of the proposed differential testing framework is described in \cref{ch:implementation}, covering the tracing infrastructure, \gls{apdu} mutation engine, and structured input generation logic.
Following the implementation, we evaluate a selection of commercial eSIM-on-SIM cards using the developed framework in \cref{ch:evaluation}. We analyze inconsistencies in behavior across vendors and discuss potential deviations from the specifications.

8
Chapters/RelatedWork.tex
View File

@@ -102,7 +102,7 @@ A more serious security assessment was presented by \textcite{security_explorati
\section{Software and Hardware Implementations}
\paragraph{pySim}
\paragraph{pySim.}
% - python tool for interacting with SIM cards and their derivitives
% - developed and maintained by osmocom -> engineer and implement tools all around SIMs i.e simtrace2 which we are also using for the tracing
@@ -127,7 +127,7 @@ The \texttt{pySim-smdpp} script serves as a proof-of-concept implementation of t
While \texttt{pySim} provides useful standalone utilities, its usability as a general-purpose library is limited. The internal architecture is not optimized for external scripting, requiring substantial effort to perform even basic tasks programmatically. As such, \texttt{pySim} is best suited for interactive use via its provided command-line tools rather than as a cleanly structured library for automation or integration.
\paragraph{SIMtrace2}
\paragraph{SIMtrace2.}
% - system consisting of software, firmware and hardware
% - main purpose: used for tracing the communication between the SIM card and some user equipment i.e phone
@@ -149,7 +149,7 @@ Overall, \texttt{SIMtrace2} is a versatile tool both for passive analysis and ac
\paragraph{lpac}
\paragraph{lpac.}
% - lpa implementation of the SGP.22 v2.2.2 in c from the estkme group
% - full compatiability i.e. profile provisioning, profile interaction, and notification handling
@@ -166,7 +166,7 @@ Due to its C-language base, \texttt{lpac} is widely adopted across various platf
However, \texttt{lpac} only supports SGP.22 version 2.2.2, whereas the most recent version (3.1) introduces several enhancements, especially targeted at \gls{iot} \gls{esim} use cases, including additional return values and extended feature support \cite{gsma_sgp22_2025}. Furthermore, while the software is considered mature and widely usable, its extensibility remains limited. Key components such as \gls{asn1} decoding and encoding are implemented manually without leveraging standardized libraries like \texttt{asn1c}~\cite{walkin_asn1c_2025}.
\paragraph{SIMTester}
\paragraph{SIMTester.}
% SIMTester