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-07 00:56:57 +00:00
committed by node
parent 9e6e16c2f6
commit 8bf17984fc
9 changed files with 41 additions and 47 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
Appendices/SomeProof.tex
View File

@@ -94,4 +94,4 @@ This exception model provides the following advantages:
This exception system enables detailed introspection during fuzzing and testing while maintaining a clean abstraction between components.
\todo{add section about inital testing of nonce randomness}
% \todo{add section about inital testing of nonce randomness}

10
Chapters/Background.tex
View File

@@ -60,7 +60,7 @@ The \glsposs{gsma} SGP.22 specification is a cornerstone in this area, detailing
RSP Type & \textbf{Push} (centrally managed) & \textbf{Pull} (user-initiated) \\
\hline
\end{tabular}
\caption{Comparison of M2M and Consumer eUICC Types \cite{gd_rsp_nodate}}
\caption{Comparison of M2M and Consumer \gls{euicc} Types \cite{gd_rsp_nodate}}
\label{tab:euicc_m2m_consumer}
\end{table}
@@ -82,7 +82,7 @@ The \glsposs{gsma} SGP.22 specification is a cornerstone in this area, detailing
RSP Type & \textbf{Push} (server-driven) & \textbf{Push} (factory provisioned) \\
\hline
\end{tabular}
\caption{Comparison of IoT and In-Factory eUICC Types \cite{gd_rsp_nodate}}
\caption{Comparison of \gls{iot} and In-Factory \gls{euicc} Types \cite{gd_rsp_nodate}}
\label{tab:euicc_iot_infactory}
\end{table}
@@ -95,7 +95,7 @@ The main \gls{gsma} \gls{esim} specifications can be categorized as follows:
Targeted at regular users and implemented in smartphones and other consumer devices for remote \gls{sim} provisioning with focus on ease of use.
\item \textbf{\gls{iot} Standard:}
Successors to the M2M \gls{esim} standards, designed to support 5G and Narrowband-IoT (NB-IoT) connectivity for sensors and various IoT devices.
Successors to the M2M \gls{esim} standards, designed to support 5G and Narrowband-IoT (NB-IoT) connectivity for sensors and various \gls{iot} devices.
\item \textbf{In-Factory Standard:}
Released in February 2025 as version 1.0, the upcoming In-Factory Profile Provisioning (IFPP) standard targets devices, such as those in the automotive and IoT sectors, that require network connectivity immediately after or during production. It is specifically designed to enable profile installation during the manufacturing process. So far only the IFPP Architecture and Requirements Specifications SGP.41~\cite{gsma_sgp41_2025} have been released, with the IFPP Technical Specification SGP.42 still being actively developed.
@@ -178,7 +178,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}, either to request or to store data, 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. 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.
@@ -313,7 +313,7 @@ In many modern devices, the most common integration of an \gls{esim} is as a sol
\includegraphics[width=.32\textwidth]{Graphics/lpa_easyeuicc.jpg}
\includegraphics[width=.32\textwidth]{Graphics/lpa_9esim.jpg}
\includegraphics[width=.32\textwidth]{Graphics/lpa_5ber.jpg}
\caption{\gls{lpa} interface of the open-source EasyEUICC App~\cite{petercxy_openeuicc_nodate}, 9esim v2 (rebranded version of the open-source NekokoLPA~\cite{iebb_nekokolpa_nodate}, and 5ber.}
\caption{\gls{lpa} interface of the open-source EasyEUICC App~\cite{petercxy_openeuicc_nodate}, 9esim v2 (rebranded version of the open-source NekokoLPA~\cite{iebb_nekokolpa_nodate}, and proprietary 5ber App.}
\label{img:lpa_interfaces}
\end{figure}

16
Chapters/Conclusions.tex
View File

@@ -13,8 +13,18 @@
% 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. By designing and implementing a custom framework, this work established a reproducible methodology 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. 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 discrepancies 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. 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 underscore the importance of independent verification and validation of \gls{esim} implementations, particularly in consumer devices, where assumptions of trust in embedded components are prevalent. 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.
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.
\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.
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.

14
Chapters/Discussion.tex
View File

@@ -62,15 +62,15 @@
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.
Our findings indicate substantial architectural differences across implementations. For instance, some cards, 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. In contrast, other implementations (e.g., 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.
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 divergent behaviors in response to identical \gls{rsp} inputs. Mutated \gls{asn1} payloads triggered undefined behavior in several cards, 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 `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. 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 emulating an \gls{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. 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 undocumented 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.
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.
The reproducibility of these findings across multiple cards supports the claim that profile management logic is often implemented in a non-standardized manner, despite the underlying reliance on common specifications such as SGP.21 and SGP.22. Unfortunately, due to the closed-source nature of the \gls{euicc} firmware, the lack of verbose error logging, and the absence of official debugging interfaces, root cause analysis remains difficult. This significantly hampers the ability to distinguish between benign vendor-specific variations and genuine security vulnerabilities.
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.
@@ -78,8 +78,4 @@ While the results demonstrate the effectiveness of our framework, several limita
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.
\paragraph{Future Work}
Several directions for future research emerge from this work. 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. 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. Finally, improvements to the fuzzing engine, such as incorporating a hypothesis rule based state machine, which would directly compare the fuzzing behaviour of a custom \gls{smdpp} server and \gls{euicc} implementation against propriatary ones.

16
Chapters/Evaluation.tex
View File

@@ -35,15 +35,15 @@ To conduct a thorough and representative evaluation, we selected a diverse set o
Xesim & Eastcompeace & 4.2.0 & 2.2.2 & 0 \\
\hline
\end{tabular}
\caption{Overview of Analyzed eSIM Cards}
\caption{Overview of Analyzed eSIM Cards based on the information from \texttt{EuiccInfo2}.}
\label{tab:esim-overview}
\end{table}
Among the tested cards, the \textbf{sysmoEUICC} is loaded with a 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 GSMA test certificate.
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.
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.
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.
% general findings
@@ -587,9 +587,7 @@ The following classes of errors were consistently encountered during mutation ca
\subsection{Analysis of Successful Mutations}
\label{subsec:successful_mutations}
To further understand the behavior of different \glspl{euicc} under mutation-based fuzzing, we post-processed all recorded \gls{apdu} traces stored in the \texttt{recordings/*.resim} directory.
\todo{Be more clear about how many and which recordings were performed}
To further understand the behavior of different \glspl{euicc} under mutation-based fuzzing, we post-processed all recorded \gls{apdu} traces.
\subsubsection*{Mutation Examples}
@@ -637,7 +635,7 @@ By combining a series of failed and mutated authentication requests, it was poss
A deeper analysis of mutated \gls{apdu} payloads of the initial \texttt{AuthenticateServerRequest}, particularly in cases using different \gls{smdpp} servers, shows the following:
\begin{itemize}
\item The first mutation typically occurs in the tag of the \texttt{AuthenticateServerRequest}, where the correct \texttt{bf38} tag is flipped to an invalid \texttt{be38}. Correcting this tag lets us decode the remaining data.
\item The first mutation typically occurs in the tag of the \texttt{AuthenticateServerRequest}, where the correct \texttt{BF38} tag is flipped to an invalid \texttt{BE38}. Correcting this tag lets us decode the remaining data.
\item In cross-server scenarios (different \gls{smdpp}), subsequent flips occur in fields such as \texttt{euiccPkiToBeUsed}, \texttt{serverCertificate.serialNumber}, \texttt{serverSignature1}, and both the \texttt{euiccChallenge} and \texttt{serverChallenge} components of \texttt{serverSigned1}. This attempt will not be able to pass the bug.
@@ -663,8 +661,8 @@ However, these attempts consistently resulted in an \texttt{UndefinedError} exce
This reinforces the assumption that the \gls{euicc} maintains non-trivial persistent state across sessions, and that this state influences the acceptance of subsequent messages even when they originate from clean profiles or well-formed certificates.
\todo{Find out which parts are reused aswell -> serverSigned1, serverSignature}
\todo{serverSigned1 -> check if signature is verified}
% \todo{Find out which parts are reused aswell -> serverSigned1, serverSignature}
% \todo{serverSigned1 -> check if signature is verified}
\subsubsection*{Implications}
The observed behavior violates \gls{gsma} security requirements, particularly in Sections 4.5.1 and 4.5.2 of SGP.22~\cite{gsma_sgp22_2025}, which mandate certificate chain validation and signature verification during server authentication. The following points summarize the core issues:

2
Chapters/Implementation.tex
View File

@@ -60,7 +60,7 @@ While our approach allows for a more precise control, it has some drawbacks. \gl
\paragraph{Fuzzing Strategy}
When applying mutations to \gls{apdu} messages, we encountered a common issue: random mutations frequently produce invalid \gls{asn1} structures. This narrows the testing focus to the \gls{asn1} decoder, which represents only a small portion of the total \gls{euicc} logic. Despite this limitation, fuzzing at the decoding layer can still yield valuable results, as parsing flaws in \gls{asn1}-based decoders have historically led to critical vulnerabilities~\cite{mitre_cve_2003, nist_nvd_2024, nist_nvd_2025}.
When applying mutations to \gls{apdu} messages, we encountered a common issue: random mutations frequently produce invalid \gls{asn1} structures. This narrows the testing focus to the \gls{asn1} decoder, which represents only a small part of the total \gls{euicc} logic. Still, fuzzing at the decoding layer can still yield valuable results, as parsing flaws in \gls{asn1}-based decoders have historically led to critical vulnerabilities~\cite{mitre_cve_2003, nist_nvd_2024, nist_nvd_2025}.
To improve the depth and scope of our fuzzing efforts, we adapted our implementation to generate and mutate structurally valid input instead. By preserving the syntactic and semantic correctness of \gls{asn1} structures, we enabled the fuzzer to exercise deeper layers of application logic. This allowed us to test state transitions, logical constraints, and error handling mechanisms that would otherwise remain untriggered by malformed data.

6
Chapters/Introduction.tex
View File

@@ -22,7 +22,7 @@
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.21 specification in 2015 \cite{gsma_sgp21_2015}. This specification defines how profiles should be securely provisioned onto \glspl{esim}, laying the foundation for \gls{esim} integration in consumer devices.
Although an earlier specification focusing on M2M (Machine-to-Machine) use cases was released in 2014~\cite{gsma_sgp01_2014}, it was mainly targeted at industrial deployments. Consumer 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 prevalent 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.
Although an earlier specification focusing on M2M (Machine-to-Machine) use cases was released in 2014~\cite{gsma_sgp01_2014}, it was mainly targeted at industrial deployments. Consumer 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 attack surface. 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.
@@ -55,11 +55,11 @@ As \gls{esim} support becomes standard in newly released phones, it also introdu
Despite the \gls{esim} architecture being built with security in mind and standardized by the \gls{gsma}, \gls{etsi}, and \gls{3gpp}, implementations are left to individual manufacturers. While the specifications provide a common baseline, the actual firmware and OS implementations 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 pose significant security risks. \glspl{esim} operate at a privileged layer of the system architecture, with direct and largely unfiltered 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 consequences.
These implementation-specific deviations can have a significant security risks. \glspl{esim} operate at a privileged layer of the system architecture, with direct and largely unfiltered 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.
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: 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}. 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.

15
FrontBackmatter/Abstract.tex
View File

@@ -9,22 +9,17 @@
\let\cleardoublepage\relax
\chapterExtra{Abstract}
Short summary of the contents in English\dots a great guide by
Kent Beck how to write good abstracts can be found here:
\begin{center}
\url{https://plg.uwaterloo.ca/~migod/research/beckOOPSLA.html}
\end{center}
eSIM-on-SIM cards bring eSIM functionality to legacy devices by embedding eSIM logic in physical SIM form factors. Despite standardized specifications by GSMA, 3GPP, and ETSI, their proprietary implementations are often opaque and inconsistent, introducing potential security risks. This thesis presents a differential testing framework to evaluate the correctness and security of commercial eSIM-on-SIM cards without requiring internal access or source code.
Steve Easterbrook also has a good article on the same topic:
\begin{center}
\url{https://www.easterbrook.ca/steve/2010/01/how-to-write-a-scientific-abstract-in-six-easy-steps/}
\end{center}
The framework includes a custom Local Profile Assistant, Application Protocol Data Unit mutation engine, and structured fuzzing components based on the SGP.22 specification. By analyzing multiple commercial eSIM-on-SIM cards, we uncover critical implementation differences, including a certificate validation bypass. Additionally, we reverse-engineer the firmware update binary of one vendor’s eSIM-on-SIM card, revealing its internal update protocol and control mechanisms. These results highlight the need for independent security analysis of eSIM implementations and demonstrate the utility of differential testing for evaluating closed, security-critical systems.
\vfill
\begin{otherlanguage}{ngerman}
\chapter*{Zusammenfassung}
Kurze Zusammenfassung des Inhaltes in deutscher Sprache\dots
eSIM-on-SIM-Karten erweitern ältere Geräte um eSIM-Funktionalität, indem sie eSIM-Logik in physische SIM-Kartenformate integrieren. Trotz standardisierter Spezifikationen durch GSMA, 3GPP und ETSI bleiben deren proprietäre Implementierungen oft intransparent und inkonsistent, was potenzielle Sicherheitsrisiken mit sich bringt. Diese Arbeit stellt ein Differential-Testing-Framework vor, das die Korrektheit und Sicherheit kommerzieller eSIM-on-SIM-Karten ohne Zugriff auf Quellcode oder interne Dokumentation bewertet und analysiert.
Das Framework umfasst einen eigens entwickelten Local Profile Assistant, eine Mutations-Generator für Application Protocol Data Units, sowie implementierung zum strukturellen Fuzzing basierend auf der SGP.22 Spezifikation. Durch die Analyse mehrerer kommerzieller eSIM-on-SIM-Karten werden kritische Implementierungsunterschiede aufgedeckt, darunter ein Umgehen der Zertifikatsvalidierung. Darüber hinaus wurde der Firmware-Update-Mechanismus einer eSIM-on-SIM-Karte mittels Reverse Engineering analysiert, wodurch das zugrunde liegende Update-Protokoll und die internen Steuermechanismen rekonstruiert werden konnten. Die Ergebnisse unterstreichen die Notwendigkeit unabhängiger Sicherheitsanalysen von eSIM-Implementierungen und zeigen die Effektivität von Differential Testing bei der Untersuchung geschlossener, sicherheitskritischer Systeme auf.
\end{otherlanguage}
\endgroup

7
FrontBackmatter/Acknowledgments.tex
View File

@@ -16,11 +16,6 @@ I would like to express my deepest gratitude to my parents and my family for sup
\bigskip
Special thanks for giving helpful advice while writing this thesis goes to Prof. Matthias Hollick and Adrian Loch.
\bigskip
Furthermore, I especially thank Sandrine Adéla\"ide and Adrian Loch for proofreading my thesis.
Special thanks for giving helpful advice while writing this thesis goes to Alexander Matern and Marius Muench.
}
\endgroup