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

Update on Overleaf.

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

10
Chapters/Introduction.tex
View File

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