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

Update on Overleaf.

Browse Source
This commit is contained in:
nb72soza Bittner
2025-07-11 14:08:10 +00:00
committed by node
parent 23c94ec81e
commit 4d04daa0dd
4 changed files with 708 additions and 604 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
Chapters/Background.tex
View File

@@ -5,6 +5,8 @@
%************************************************
\glsresetall % Resets all acronyms to not used
\todo{Overview of esim stack}
\section{Subscriber Identity Module}
\label{sec:sim}
@@ -16,7 +18,7 @@
The \gls{sim} card is a specialized type of smart card, a form factor also employed in applications such as banking (\eg, EMV cards) and access control (\eg, MIFARE cards). As a smart card, a \gls{sim} contains essential computing components: a CPU, ROM, and RAM, all of which are accessed through up to eight physical contacts (pins) on the card's surface~\cite{etsi_ts_2003}.
Interaction with the \gls{sim} is governed by an embedded operating system, which provides a standardized file system structure for data access and application management. In addition to storing subscriber data and cryptographic keys, the \gls{sim} operating system can execute Java Card applets to extend its functionality.
Interaction with the \gls{sim} is governed by an embedded operating system \cite{etsi_ts_2022-1, globalplatform_gp_2018}, which provides a standardized file system structure for data access and application management. In addition to storing subscriber data and cryptographic keys, the \gls{sim} operating system can execute Java Card applets to extend its functionality.
Java Card applets are applications written in a restricted subset of the Java programming language, specifically tailored for execution on constrained devices. They operate within the Java Card Runtime Environment (JCRE), which itself runs inside the Java Card Virtual Machine (JCVM). This environment enables secure, platform-independent execution of custom logic directly on the \gls{sim} card, a capability that is heavily utilized in mobile network provisioning, secure authentication, and value-added services.\cite{ort_writing_2001}
@@ -27,6 +29,8 @@ Java Card applets are applications written in a restricted subset of the Java pr
% - 3GPP: defines how the SIMs are integrated into the mobile networks by defining the mobile broadband standards such as 5G and LTE
% - GSMA: defines the funcitonal systems around the eSIM to make it usable in the real-world, i.e. in the context of eSIMs: RSP, LPA, SM-DP+, etc -> later (cite SGP.22)
Identification cards such as \glspl{sim} and \glspl{esim} are fundamentally built upon the ISO/IEC 7816 standard \cite{iso_isoiec_2019}, which defines key aspects of smart cards with contacts. This includes specifications for the physical characteristics, contact positioning, electrical interface, transmission protocols, and command structure. These foundational definitions are essential for the development of both traditional \glspl{uicc} and embedded \glspl{euicc}, ensuring baseline interoperability and functionality across compliant hardware platforms.
The operation and functionality of \gls{sim} and \gls{esim} cards are defined and governed by three major standardization bodies: \gls{etsi}, \gls{3gpp}, and the \gls{gsma}. Each of these organizations contributes distinct specifications that together form the foundation of the \gls{sim} ecosystem.
The \gls{etsi} defines the \gls{sim} card as a smart card platform. This includes specifications for the physical \gls{uicc} hardware, the structure and semantics of \gls{apdu} commands, and the internal smart card file system. Notably, the \gls{etsi} standard TS 151 011 specifies the logical structure of the file system and the behavior of elementary and dedicated files~\cite{etsi_ts_2005}.
@@ -42,7 +46,7 @@ The \glsposs{gsma} SGP.22 specification is a cornerstone in this area, detailing
% SGP.32 iot (SGP.31, SGP.32): for iot devices -> successor to m2m esim, supports 5g and NB-IoT, for sensors etc
% SGP.42 in factory (SGP.41, SGP.42) for cars and devices that immediate network connectivity after manufactoring -> mainly automotoive and iot industry
\begin{table}[ht]
\begin{table}[t]
\centering
\small
\begin{tabular}{|p{2.5cm}|p{4cm}|p{4cm}|}
@@ -64,7 +68,7 @@ The \glsposs{gsma} SGP.22 specification is a cornerstone in this area, detailing
\label{tab:euicc_m2m_consumer}
\end{table}
\begin{table}[ht]
\begin{table}[t]
\centering
\small
\begin{tabular}{|p{2.5cm}|p{4cm}|p{4cm}|}
@@ -435,7 +439,7 @@ In this work, we focus on the Authentication Code method due to its prevalence i
\paragraph{Mutual Authentication}
As \cref{fig:mutual_authentication} shows, the \gls{rsp} process begins with mutual authentication between the \gls{euicc} and \gls{smdpp} over a \gls{tls} tunnel established via the \gls{lpa}. The \gls{euicc} generates a random challenge $N_U$ and sends it, along with its \gls{ci} Root public key certificate $SKI_{CI}$, to the \gls{smdpp}. The \gls{smdpp} responds with a signed version of the challenge $N_U$, its own certificate subject $S$, a transaction identifier $I_t$, and a server challenge $N_S$. The \gls{euicc} verifies the signature and certificate chain, signs the activation code’s profile identifier $I_{ac}$ (and other protocol elements), the transaction identifier $I_t$, the server challenge $N_S$, and relevant addresses, then returns this to the \gls{smdpp}. Based on the profile identifier, the \gls{smdpp} selects the appropriate profile for download.
As \cref{fig:mutual_authentication} shows, the \gls{rsp} process begins with mutual authentication between the \gls{euicc} and \gls{smdpp} over a \gls{tls} tunnel established via the \gls{lpa}. The \gls{euicc} generates a random challenge $N_U$ and sends it, along with its \gls{ci} Root public key certificate $SKI_{CI}$, to the \gls{smdpp}. The \gls{smdpp} responds with a signed version of the challenge $N_U$, its own certificate subject $S$, a transaction identifier $I_t$, and a server challenge $N_S$. The \gls{euicc} verifies the signature and certificate chain, signs the activation code’s profile identifier $I_{ac}$ (and other protocol elements), the transaction identifier $I_t$, the server challenge $N_S$, and relevant addresses, then returns this to the \gls{smdpp}. Based on the profile identifier, the \gls{smdpp} selects the appropriate profile for download.
\paragraph{Profile Binding}

35
Chapters/Introduction.tex
View File

@@ -20,11 +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.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.
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.
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.
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.
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.
\section{Motivation}
% Motivation
@@ -53,9 +52,11 @@ As \gls{esim} support becomes standard in newly released phones, it also introdu
% differential testing: compare multiple implementations against each other -> identify anomalies under identical/similar inputs
% goal: uncover functional deviations and security issues in a black-box setting
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.
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. To support this process and ensure interoperability, the GSMA has defined comprehensive sets of test specifications \cite{gsma_sgp23_2025, packer_sgp33-3_2025}, which enumerate numerous conformance and interoperability test cases for the different deployment models. These specifications are intended to guide manufacturers in validating their implementations against the standard behavior. Additionally, the \gls{gsma} provides standardized test profiles \cite{gsma_ts48_2025} as well as test certificates \cite{gsma_sgp26_2024}, which are specifically designed for device testing and are used in formal industry certification programs such as PTCRB~\cite{ptcrb_ptcrb_2025} and the execution of test cases.
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.
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.
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.
@@ -75,7 +76,27 @@ This thesis aims to close the gap in independent, systematic analysis of commerc
% demonstrate the framworks ability in security research:
% through apdu level differnetial testing, we discover and evaluate bug in the profile provisioning process of one manufacturer -> suggests potential security risk such as certificate validation bypass -> analyze and evaluate potential impact
To the best of our knowledge, this thesis introduces the first differential testing framework for \gls{esim} and, in particular, eSIM-on-SIM implementations that leverages fuzzing techniques.
% This thesis presents a novel framework for the differential testing of
% eSIM and eSIM-on-SIM implementations. The framework includes a
% custom Local Profile Assistant (LPA), an Application Protocol Data
% Unit (APDU) mutation engine, and structured fuzzing tools. It enables
% tracing, mutation, and replaying of provisioning flows, and is exposed
% both through a command-line interface and as a Python library for
% scripting and automation.
% By employing property-based testing and structural input mutation,
% the framework generates valid but edge-case-rich test cases to evaluate
% high-level commands. This allows it to uncover subtle logic bugs
% beyond low-level malformed input handling.
This thesis presents \sysname~\footnote{https://github.com/Trup3s/resimulate}, the first comprehensive differential testing framework targeting eSIM-on-SIM implementations. The key contributions are:
\begin{itemize}
\item \textbf{First \gls{esim} fuzzing framework:} A novel testing framework designed specifically for black-box analysis of \gls{esim} provisioning flows and implementation behavior.
\item \textbf{Custom \gls{lpa}:} A fully functional \gls{lpa} implementation that supports the full \gls{rsp} protocol aswell as profile and \gls{euicc} management commands.
\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.