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-06-23 20:19:09 +00:00
committed by node
parent 9305d82b15
commit 09b1b30a05
4 changed files with 65 additions and 57 deletions
Download Patch File Download Diff File Expand all files Collapse all files

40
Chapters/Background.tex
View File

@@ -35,6 +35,8 @@ The \gls{3gpp} focuses on how \gls{sim} cards integrate with mobile networks. Th
The \gls{gsma} defines the higher-level functional architecture necessary to operationalize \gls{esim} technology in real-world deployments. This includes specifications such as the \gls{rsp} system, the \gls{lpa}, and the \gls{smdpp}, which together enable the remote provisioning, management, and activation of eSIM profiles. The GSMA's \gls{sgp22} specification is a cornerstone in this area, detailing the technical realization of the consumer remote \gls{sim} provisioning system~\cite{gsma_sgp22_2025}.
\todo{Explain different GSMA standards i.e consumer, m2m, iot, factory}
\paragraph{Transport Protocols}
@@ -93,7 +95,7 @@ A C-APDU consists of mandatory header fields and optional data and length fields
\hline \hline
$Data$ & at most $N_e$ & Response Data \\
$SW1$ & 1 & Status Word 1 \\
$SW2$ & 1 & Status Word 1 \\
$SW2$ & 1 & Status Word 2 \\
\hline
\end{tabular}
\end{table}
@@ -151,13 +153,13 @@ The \gls{gsma} provides \gls{asn1} definitions for all standardized \gls{rsp} fu
% - Proposed AIDs by the GSMA/GP for Applications: ISD-R ("A0000005591010FFFFFFFF8900000100"), ARA-M ("'A00000015141434C00'")
% - actual AID is up to the manufcacturer, especially ISD-R AID is often changed as explained in section (ref section here)
The file system of a \gls{uicc} is organized as a hierarchical forest of trees, as specified in \cite{etsi_ts_2023}. At the top of the hierarchy resides the \gls{mf} (Master File), from which \glspl{df}, \glspl{ef}, and \glspl{adf} originate.
The file system of a \gls{uicc} is organized as a hierarchical forest of trees, as specified in \cite{etsi_ts_2023}. At the top of the hierarchy resides the \gls{mf}, from which \glspl{df}, \glspl{ef}, and \glspl{adf} originate.
\glspl{df} serve as containers that enable functional grouping of files. A special class of DF, called \glspl{adf}, encapsulates all files (EFs and optionally DFs) related to a specific application. Within these structures, \glspl{ef} act as leaf nodes and contain the actual data. There are three types of EFs: transparent EFs (byte-oriented, raw data), linear fixed EFs (record-based, fixed-length records), and cyclic EFs (circular buffers).
\glspl{df} serve as containers that enable functional grouping of files. A special class of \gls{df}, called \glspl{adf}, encapsulates all files (\glspl{ef} and optionally \glspl{df}) related to a specific application. Within these structures, \glspl{ef} act as leaf nodes and contain the actual data. There are three types of \glspl{ef}: transparent \glspl{ef} (byte-oriented, raw data), linear fixed \glspl{ef} (record-based, fixed-length records), and cyclic \glspl{ef} (circular buffers).
Each file is uniquely identified by a \gls{fid}, while applications are identified by their \gls{aid}. File paths are defined as a sequence of FIDs, typically starting from the MF or an ADF. The reserved FID \texttt{7FFF} refers to the currently selected ADF.
Each file is uniquely identified by a \gls{fid}, while applications are identified by their \gls{aid}. File paths are defined as a sequence of \glspl{fid}, typically starting from the \gls{mf} or an \gls{adf}. The reserved \gls{fid} \texttt{7FFF} refers to the currently selected \gls{adf}.
To access files, the \texttt{SELECT} command is used. This command supports various addressing modes: by FID, AID, complete path, or short FID. Importantly, file selection is stateful—meaning that parent files or applications must be selected before accessing child files.
To access files, the \texttt{SELECT} command is used. This command supports various addressing modes: by \gls{fid}, \gls{aid}, complete path, or short \gls{fid}. Importantly, file selection is stateful—meaning that parent files or applications must be selected before accessing child files.
Common AIDs proposed by the \gls{gsma} and \gls{gp} include the \gls{isdr} application and the \gls{aram} application.
@@ -166,7 +168,7 @@ Common AIDs proposed by the \gls{gsma} and \gls{gp} include the \gls{isdr} appli
\item \gls{aram} \texttt{A00000015141434C00}
\end{itemize}
However, the actual AIDs used are implementation-specific and may be customized by the manufacturer. The \gls{isdr} AID in particular is often modified, as discussed in \cref{sec:findings}.
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:findings}.
\section{Embedded SIM}
\label{sec:esim}
@@ -209,7 +211,7 @@ The \gls{ecasd} provides secure storage and cryptographic services. It maintains
The \gls{isdr} acts as the primary control authority on the \gls{euicc}. It manages the creation, activation, deactivation, and deletion of \glspl{isdp}. Only one of either \gls{isdr} or \gls{ecasd} can be present on a single \gls{euicc}, depending on the \gls{euicc}'s implementation mode.
Each \gls{isdp} hosts exactly one \gls{esim} profile and is responsible for profile download and installation. \glspl{isdp} may additionally host applets specific to the mobile network operator or service provider.
Each \gls{isdp} hosts exactly one \gls{esim} profile and is responsible for profile download and installation. \glspl{isdp} may additionally host applets specific to the mobile network operator or service provider. An \gls{euicc} can have multiple \glspl{isdp} to have multiple profiles installed at the same time. Each \gls{isdp} must have it's own unique \glspl{aid}.
The \gls{aram}, as specified by \gls{gp}, governs access control for applications on the Secure Element. It aggregates access rules from multiple possible sources on the Secure Element and provides them in a standardized form. These rules are defined by the Secure Element issuer—typically the device manufacturer—and can restrict which device-side applications are permitted to communicate with the \gls{euicc} and its applets.
@@ -236,11 +238,24 @@ Together, these components establish the trust and management architecture neces
In many modern devices, the most common integration of an \gls{esim} is as a soldered chip on the printed circuit board of a smartphone. Because these embedded chips are functionally identical to traditional removable \gls{sim} cards—apart from the \gls{esim} operating system, which is supplied by the eUICC manufacturer—they can also be packaged as “physical eSIMs” 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}
The \gls{lpa} is a user-facing application (i.e an App on a smartphone) on the \gls{ue} that interacts with the \gls{euicc}, enabling users to initiate profile provisioning and perform lifecycle management operations such as enabling, disabling, or deleting profiles. The \gls{smdpp} is a server—operated by an \gls{euicc} manufacturer, \gls{mno}, or third party, that securely hosts \gls{esim} profiles and makes them available for download. The \gls{smds} facilitates the "push" provisioning approach, where the operator notifies the \gls{lpa} via the \gls{smds} that an profile is ready download. The \gls{lpa} then downloads and installs this profile from the \gls{smdpp} server onto the \gls{euicc} with the information provided by the \gls{smds}. This approach is less common in consumer scenarios.
\begin{figure}[h!]
\includegraphics[width=\textwidth]{Graphics/rsp_architecture.png}
\caption{\gls{rsp} architecture~\cite{gsma_sgp22_2024} consisting of the \gls{lpa}~\footnotemark, \gls{euicc}, \gls{smds}, and \gls{smdpp}.}
\label{img:rsp_architecture}
\end{figure}
\footnotetext{The components referred to as the \gls{lpad} in this thesis — namely the \gls{ldsd}, \gls{lpdd}, and \gls{luid} — are collectively simplified and referred to as \gls{lpa} for readability.}
\paragraph{Application Toolkit}
The \gls{stk}/\gls{usat}, which are collectively referred to as the \gls{cat} in ETSI TS 102 223~\cite{etsi_ts_2014}, provides a proactive command framework for on-card applications. The original \gls{stk}, introduced in ETSI 11.14~\cite{etsi_gsm_1997}, targets GSM SIMs, while the \gls{usat}, defined in 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.
\section{Remote SIM Provisioning}
\label{sec:rsp}
@@ -287,19 +302,10 @@ The \gls{stk}/\gls{usat}, which are collectively referred to as the \gls{cat} in
One of the most significant advantages of \glspl{esim} is the ability to download and install profiles remotely without physically swapping the card. This process, known as \gls{rsp}, is defined by the \gls{gsma} in specification \gls{sgp22}~\cite{gsma_sgp22_2023, gsma_sgp22_2024, gsma_sgp22_2025}. The key components of the \gls{rsp} ecosystem are the \gls{lpa}, the \gls{smdpp}, and, to a lesser extent in consumer deployments, the \gls{smds}.
The \gls{lpa} is a user-facing application on the \gls{ue} that interacts with the \gls{euicc}, enabling users to initiate profile provisioning and perform lifecycle management operations such as enabling, disabling, or deleting profiles. The \gls{smdpp} is a server—operated by an \gls{euicc} manufacturer, \gls{mno}, or third party—that securely hosts \gls{esim} profiles and makes them available for download. The \gls{smds} facilitates the "push" provisioning approach but is less common in consumer scenarios.
\begin{figure}[h!]
\includegraphics[width=\textwidth]{Graphics/rsp_architecture.png}
\caption{\gls{rsp} architecture~\cite{gsma_sgp22_2024} consisting of the \gls{lpa}~\footnotemark, \gls{euicc}, \gls{smds}, and \gls{smdpp}.}
\label{img:rsp_architecture}
\end{figure}
\footnotetext{The components referred to as the \gls{lpad} in this thesis — namely the \gls{ldsd}, \gls{lpdd}, and \gls{luid} — are collectively simplified and referred to as \gls{lpa} for readability.}
\gls{sgp22} defines three \gls{rsp} initiation methods:
\begin{enumerate}
\item \textbf{Default Server}: The \gls{smdpp} address is pre-configured on the \gls{euicc} at manufacture time. The user triggers provisioning via the default server.
\item \textbf{Default Server}: The \gls{smdpp} address is pre-configured on the \gls{euicc} at manufacture time and points to a operator controlled server. The user triggers provisioning via the default server if no other address is given by the profile.
\item \textbf{Authentication Code}: The user is provided with an activation code (containing the \gls{smdpp} address and optional confirmation code) when purchasing service. The \gls{lpa} contacts the \gls{smdpp} and, after mutual authentication, may require entry of the confirmation code.
\item \textbf{\gls{smds} Assisted}: The \gls{lpa} polls the \gls{smds} for an event matching the \gls{eid} of the \gls{euicc}. If a download event exists, the \gls{smds} supplies the \gls{smdpp} address to the \gls{lpa} for profile download.
\end{enumerate}

77
Chapters/RelatedWork.tex
View File

@@ -7,6 +7,43 @@
The ecosystem surrounding \gls{esim} and \gls{euicc} technology is supported by a combination of practical implementations and academic research. As this thesis focuses on differential testing of consumer \gls{esim} cards, it is essential to examine both established software tools that enable interaction with such cards and the existing academic efforts that analyze their security, functionality, and protocol correctness.
\section{Literature}
% SIMURAI
% - focuses on the possiblility of compromised / attacker controlled SIM cards
% - implemented a SIM card emulation framework consisting of: swSIM -> open source SIM and swICC -> smart Card framework
% - Research goal: find out if malicious SIM cards are a credible attack vector
% - they demonstrate their framwork by emulating SIM cards to enable fuzzing against user equipment
% - propose 2 different attack scenarios: Rouge Carrier and interposer with physical access
% - they evalute each attack scenario and propose possible mitigations
% - used their implementation to discover multiple high value memory corruption vulnerabilities inside the
% - exploit those vulns by implementing spyware (similar to SIMjacker) that is remotly patched onto the SIM and sends information to the attacker
% - show that hostile SIMs can be used to exploit vulnerabilites and urge that hostile SIMs should be considered as serious attack vectors
% Security Analysis of the Consumer Remote SIM Provisioning Protocol
% - implement a formal modal of RSP in ProVerfiy to remotly provision SIM profiles
% - found different failure modes, however most of them assume a rather strong attacker -> e.g. TLS private key compromise, etc
% - most practical one: no method to verify user intend -> attacker can order/request profile for victim euicc from sm-dp+ -> victim may be able to download attacker ordered profile
% Transparency of SIM profiles for the consumer remote SIM provisioning protocol
% - says that the entire security of the RSP relies on the PKI in which the GSMA signs domains of sm-dp+ server
% - argues that RSP could be compromised if only a single sm-dp+ server is breached -> attacker could clone profiles
% - propose SPTS (SIM profile transparency protocol) protocol that gives more transparency to the RSP profile provisioning process
% - introduces two new actors to the protol which serve as a private index for IMSIs and a transperncy ledger which protocols each action in the RSP protocol for transparency
% - using formal security analysis of their protocol with ProVerif and develope a prototype that uses the SPTS
\texttt{Simurai} is a research framework that investigates the potential threat of compromised or attacker-controlled \gls{sim} cards~\cite{lisowski_simurai_2024}. The authors introduce a \gls{sim} card emulation system comprising two core components: \texttt{swSIM}, an open-source \gls{sim} card emulator, and \texttt{swICC}, a smart card framework. Their primary goal is to evaluate whether malicious \gls{sim} cards represent a credible attack vector against user equipment.
To support this, they demonstrate how their framework enables fuzz testing by emulating arbitrary \gls{sim} card behaviors. The study proposes two concrete attack scenarios: (1) a rogue carrier scenario, in which a malicious network operator issues hostile \gls{sim} cards, and (2) a physical card interposer attack, where an attacker inserts a interposer between the legitimate \gls{sim} and the phone. For both scenarios, the researchers conduct evaluations and suggest potential mitigations.
Using their emulation framework, the authors discovered multiple high-impact memory corruption vulnerabilities in baseband implementations. These were exploited via spyware-like payloads reminiscent of the \textit{SIMjacker}attack~\cite{enea_simjacker_2019}, remotely installed onto the \gls{sim} card. This spyware exfiltrates information to the attacker without requiring user interaction. Their findings underscore the seriousness of hostile SIMs as an attack vector and argue that such threat models should be incorporated into mobile security considerations.
\textcite{ahmed_security_2024} present a formal model of the \gls{rsp} protocol based on the \gls{sgp22} specification. The model is developed using \texttt{ProVerif} to verify the security properties of remote profile provisioning. Although many of the identified failure modes require strong attacker capabilities—such as compromise of \gls{tls} private keys—the study highlights a particularly practical issue: the absence of a robust mechanism to verify user intent. An attacker could initiate a profile download to a victim's \gls{euicc} without user consent, provided they have access to the device or provisioning channel, resulting in unauthorized profile installation.
\textcite{ahmed_transparency_2021} critiques the centralized trust model underlying the \gls{rsp} ecosystem. The study emphasizes that the entire trust infrastructure hinges on the \gls{pki} used by the \gls{gsma} to certify \gls{smdpp} domains. A breach of any single \gls{smdpp} server could allow an attacker to issue cloned or rogue profiles of that operator to attacker controlled \glspl{euicc}. To address this, the authors propose the \gls{sptp}, a protocol designed to enhance transparency and trust in the provisioning process.
\gls{sptp} introduces two new entities: a private index service for managing \glspl{imsi}, and a transparency ledger that logs profile provisioning actions. Formal security analysis of the \gls{sptp} protocol using \texttt{ProVerif}, alongside a functional prototype, demonstrates that such an approach can mitigate the identified risks without significant architectural changes to the existing infrastructure.
\section{Software Implementations}
\paragraph{pySim}
@@ -27,7 +64,7 @@ The ecosystem surrounding \gls{esim} and \gls{euicc} technology is supported by
The \texttt{pySim} suite comprises five primary scripts: \texttt{pySim-shell}, \texttt{pySim-read}, \texttt{pySim-prog}, \texttt{pySim-trace}, and \texttt{pySim-smdpp}. Among these, \texttt{pySim-shell} is the core component, offering an interactive shell interface to navigate the \gls{sim} card file system and issue application-specific commands. It supersedes the legacy \texttt{pySim-read} script, which only supports a limited subset of shell commands and is primarily used to extract commonly accessed data fields from \gls{sim} cards.
The \texttt{pySim-trace} script provides a tracing utility and protocol decoder for \gls{sim} card-related communication. It integrates with \texttt{simtrace2} to intercept and decode communication between a user device and the \gls{sim} card. This functionality is limited to passive recording and does not support active injection or modification of messages.
The \texttt{pySim-trace} script provides a tracing utility and protocol decoder for \gls{sim} card-related communication. It integrates with \texttt{SIMtrace2} to intercept and decode communication between a user device and the \gls{sim} card. This functionality is limited to passive recording and does not support active injection or modification of messages.
The \texttt{pySim-smdpp} script serves as a proof-of-concept implementation of the \gls{sgp22} \gls{smdpp} server component. Notably, \texttt{pySim} does not implement the full \gls{sgp22} protocol stack on the client side (i.e., communication between the \gls{euicc} and the \gls{smdpp} server); its \gls{sgp22} functionality is restricted to the server role only.
@@ -86,41 +123,3 @@ One of the core components of \texttt{SIMTester} is its integrated fuzzing modul
However, the scope of \texttt{SIMTester} is explicitly limited to physical \gls{sim} cards. It does not support or test \gls{esim}-specific features or functionalities, such as profile provisioning, profile switching, or remote \gls{sim} management as defined in the \gls{sgp22} specification. As such, while useful for legacy systems and certain classes of attacks, its applicability in the context of modern \gls{esim} testing is limited.
\section{Literature}
% SIMURAI
% - focuses on the possiblility of compromised / attacker controlled SIM cards
% - implemented a SIM card emulation framework consisting of: swSIM -> open source SIM and swICC -> smart Card framework
% - Research goal: find out if malicious SIM cards are a credible attack vector
% - they demonstrate their framwork by emulating SIM cards to enable fuzzing against user equipment
% - propose 2 different attack scenarios: Rouge Carrier and interposer with physical access
% - they evalute each attack scenario and propose possible mitigations
% - used their implementation to discover multiple high value memory corruption vulnerabilities inside the
% - exploit those vulns by implementing spyware (similar to SIMjacker) that is remotly patched onto the SIM and sends information to the attacker
% - show that hostile SIMs can be used to exploit vulnerabilites and urge that hostile SIMs should be considered as serious attack vectors
% Security Analysis of the Consumer Remote SIM Provisioning Protocol
% - implement a formal modal of RSP in ProVerfiy to remotly provision SIM profiles
% - found different failure modes, however most of them assume a rather strong attacker -> e.g. TLS private key compromise, etc
% - most practical one: no method to verify user intend -> attacker can order/request profile for victim euicc from sm-dp+ -> victim may be able to download attacker ordered profile
% Transparency of SIM profiles for the consumer remote SIM provisioning protocol
% - says that the entire security of the RSP relies on the PKI in which the GSMA signs domains of sm-dp+ server
% - argues that RSP could be compromised if only a single sm-dp+ server is breached -> attacker could clone profiles
% - propose SPTS (SIM profile transparency protocol) protocol that gives more transparency to the RSP profile provisioning process
% - introduces two new actors to the protol which serve as a private index for IMSIs and a transperncy ledger which protocols each action in the RSP protocol for transparency
% - using formal security analysis of their protocol with ProVerif and develope a prototype that uses the SPTS
\texttt{Simurai} is a research framework that investigates the potential threat of compromised or attacker-controlled \gls{sim} cards~\cite{lisowski_simurai_2024}. The authors introduce a \gls{sim} card emulation system comprising two core components: \texttt{swSIM}, an open-source \gls{sim} card emulator, and \texttt{swICC}, a smart card framework. Their primary goal is to evaluate whether malicious \gls{sim} cards represent a credible attack vector against user equipment.
To support this, they demonstrate how their framework enables fuzz testing by emulating arbitrary \gls{sim} card behaviors. The study proposes two concrete attack scenarios: (1) a rogue carrier scenario, in which a malicious network operator issues hostile \gls{sim} cards, and (2) a physical card interposer attack, where an attacker inserts a interposer between the legitimate \gls{sim} and the phone. For both scenarios, the researchers conduct evaluations and suggest potential mitigations.
Using their emulation framework, the authors discovered multiple high-impact memory corruption vulnerabilities in baseband implementations. These were exploited via spyware-like payloads reminiscent of the \textit{SIMjacker} attack, remotely installed onto the \gls{sim} card. This spyware exfiltrates information to the attacker without requiring user interaction. Their findings underscore the seriousness of hostile SIMs as an attack vector and argue that such threat models should be incorporated into mobile security considerations.
\textcite{ahmed_security_2024} present a formal model of the \gls{rsp} protocol based on the \gls{sgp22} specification. The model is developed using \texttt{ProVerif} to verify the security properties of remote profile provisioning. Although many of the identified failure modes require strong attacker capabilities—such as compromise of \gls{tls} private keys—the study highlights a particularly practical issue: the absence of a robust mechanism to verify user intent. An attacker could initiate a profile download to a victim's \gls{euicc} without user consent, provided they have access to the device or provisioning channel, resulting in unauthorized profile installation.
\textcite{ahmed_transparency_2021} critiques the centralized trust model underlying the \gls{rsp} ecosystem. The study emphasizes that the entire trust infrastructure hinges on the \gls{pki} used by the \gls{gsma} to certify \gls{smdpp} domains. A breach of any single \gls{smdpp} server could allow an attacker to issue cloned or rogue profiles. To address this, the authors propose the \gls{sptp}, a protocol designed to enhance transparency and trust in the provisioning process.
\gls{sptp} introduces two new entities: a private index service for managing \glspl{imsi}, and a transparency ledger that logs profile provisioning actions. Formal security analysis of the \gls{sptp} protocol using \texttt{ProVerif}, alongside a functional prototype, demonstrates that such an approach can mitigate the identified risks without significant architectural changes to the existing infrastructure.