niklas/master_thesis
1
0
Fork 0
mirror of https://sharelatex.tu-darmstadt.de/git/681e0e7a3a9c7c9c6b8bb298 synced 2026-02-04 11:07:43 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update on Overleaf.

Browse Source
This commit is contained in:
nb72soza Bittner
2025-07-01 23:50:06 +00:00
committed by node
parent 928dcd72df
commit 05541d57ab
10 changed files with 690 additions and 539 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
Chapters/RelatedWork.tex
View File

@@ -36,13 +36,13 @@ The ecosystem surrounding \gls{esim} and \gls{euicc} technology is supported by
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.
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_security_2024} present a formal model of the \gls{rsp} protocol based on the SGP.22 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.
\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 SIM Profile Transparency Protocol (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.
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 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}
@@ -66,7 +66,7 @@ The \texttt{pySim} suite comprises five primary scripts: \texttt{pySim-shell}, \
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.
The \texttt{pySim-smdpp} script serves as a proof-of-concept implementation of the SGP.22 \gls{smdpp} server component. Notably, \texttt{pySim} does not implement the full SGP.22 protocol stack on the client side (i.e., communication between the \gls{euicc} and the \gls{smdpp} server); its SGP.22 functionality is restricted to the server role only.
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.
@@ -102,11 +102,11 @@ Overall, \texttt{SIMtrace2} is a versatile tool both for passive analysis and ac
% - only supports SGP.22 v2.2.2 -> newest version is v3.1 with several new additions for IoT eSIMs and also more information are returned in already existing functions
% - established software, usablity as library improved by wrappers, doesn't offer flexibility for extending functionality -> asn decoding/encoding happens manually, no library used
\texttt{lpac} is a C-based implementation of the \gls{lpa} defined in the \gls{sgp22}, version 2.2.2, developed by the \texttt{estk.me} group~\cite{estkme_lpac_2025}. It provides full support for the required \gls{lpa} functionality, including profile provisioning, profile interaction, and notification handling. The implementation manages both the communication with the \gls{euicc} and the \gls{smdpp} server, thereby serving as a complete \gls{lpa} stack.
\texttt{lpac} is a C-based implementation of the \gls{lpa} defined in the SGP.22, version 2.2.2, developed by the \texttt{estk.me} group~\cite{estkme_lpac_2025}. It provides full support for the required \gls{lpa} functionality, including profile provisioning, profile interaction, and notification handling. The implementation manages both the communication with the \gls{euicc} and the \gls{smdpp} server, thereby serving as a complete \gls{lpa} stack.
Due to its C-language base, \texttt{lpac} is widely adopted across various platforms through language-specific wrappers. It forms the core of several \gls{lpa} implementations, including \texttt{EasyEuicc}, \texttt{OpenEuicc}, \texttt{MiniLPA}, and others~\cite{icedtangerine_easylpac_2025, petercxy_openeuicc_nodate, esimmoe_minilpa_nodate}. It also exposes a command-line interface, allowing users to interact with the \gls{lpa} directly for debugging or automation purposes.
However, \texttt{lpac} only supports \gls{sgp22} 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. 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.
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.
\paragraph{SIMTester}
@@ -121,5 +121,5 @@ However, \texttt{lpac} only supports \gls{sgp22} version 2.2.2, whereas the most
One of the core components of \texttt{SIMTester} is its integrated fuzzing module. This module systematically tests combinations of \gls{aid} and command structures to detect insecure or unexpected behavior in \gls{sim} applications. This approach enables the detection of vulnerabilities such as unauthorized access to file structures or insecure command handling.
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.
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 SGP.22 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.