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-09 15:18:48 +00:00
committed by node
parent 04a77ee191
commit ed6ef06177
4 changed files with 23 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
Bibliography.bib
View File

@@ -839,6 +839,7 @@ C compilers is available on the web.},
title = {Avatar: {A} {Framework} to {Support} {Dynamic} {Security} {Analysis} of {Embedded} {Systems}’ {Firmwares}},
isbn = {978-1-891562-35-8},
shorttitle = {Avatar},
publisher = {NDSS},
author = {Zaddach, Jonas and Bruno, Luca and Francillon, Aurélien and Balzarotti, Davide},
month = feb,
year = {2014},
@@ -859,10 +860,13 @@ C compilers is available on the web.},
}
@misc{security_explorations_esim_2025,
type = {Security {Explorations}},
title = {{eSIM} security},
shorttitle = {{eSIM} security},
url = {https://security-explorations.com/esim-security.html#info},
language = {en},
urldate = {2025-07-09},
journal = {eSIM security {\textbar} eSIM security},
author = {{Security Explorations}},
year = {2025},
file = {Security Explorations - eSIM security:/home/niklas/Zotero/storage/J4QR5WQA/esim-security.html:text/html},
@@ -875,6 +879,7 @@ C compilers is available on the web.},
language = {en},
number = {SE-2019-01-ORACLE},
urldate = {2025-07-09},
institution = {Security Explorations},
author = {{Security Explorations}},
year = {2019},
file = {PDF:/home/niklas/Zotero/storage/XBKC7FAX/SE-2019-01-ORACLE.pdf:application/pdf},

2
Chapters/Evaluation.tex
View File

@@ -637,7 +637,7 @@ A deeper analysis of mutated \gls{apdu} payloads of the initial \texttt{Authenti
\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 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.
\item In cross-server scenarios (different \gls{smdpp}), subsequent flips occur in fields such as \texttt{euiccPki\-ToBeUsed}, \texttt{server\-Certificate.\-serial\-Number}, \texttt{server\-Signature1}, and both the \texttt{euicc\-Challenge} and \texttt{server\-Challenge} components of \texttt{server\-Signed1}. This attempt will not be able to pass the bug.
\item In same-server scenarios (same \gls{smdpp}), a similar flip in the tag is observed. Upon correction, mutations manifest in \texttt{euiccCiPKIdToBeUsed}, \texttt{serverCertificate.issuer}, \texttt{serverCertificate.serialNumber}, \texttt{serverSignature1}, and again in \texttt{serverSigned1.serverChallenge}. This scenario will be able to pass the truncation bug an successfully install the profile.
\end{itemize}

6
Chapters/Implementation.tex
View File

@@ -391,7 +391,7 @@ We repeat this process for all functions defined in the scenario, producing a co
% if so return the mutation type of the child that still has not tried mutation types -> brings us on the subtree where a child has not tried mutations -> next time this function is called we return the new not tried mutation type
% if child does not have any not tried mutations: we return the NoneNode of that child i.e the mutation type of the child that was successfully executed and did not make any mutations. idea: continue down the good path to find untried mutations
The decision process for selecting the next mutation to apply is a key component of the fuzzing framework and is handled entirely by the \texttt{OperationRecorder}. Its responsibility is to ensure that all mutations are eventually applied to each function within a scenario while maintaining a consistent and deterministic traversal order across runs.
The decision process for selecting the next mutation to apply is a key component of the fuzzing framework and is handled entirely by the \texttt{Operation\-Recorder}. Its responsibility is to ensure that all mutations are eventually applied to each function within a scenario while maintaining a consistent and deterministic traversal order across runs.
\begin{figure}
\centering
@@ -437,7 +437,7 @@ After multiple cards are fuzzed with the same scenario, their corresponding muta
\begin{itemize}
\item Trees must have equivalent structure (same function call order and mutation types).
\item Nodes are flagged as different if their response status word differs or if the failure reason (e.g. \texttt{EuiccException}, \texttt{AssertionError}) is inconsistent.
\item Nodes are flagged as different if their response status word differs or if the failure reason (e.g. \texttt{Euicc\-Exception}, \texttt{Assertion\-Error}) is inconsistent.
\item Discrepancies due to failed mutations (missing child nodes) are also handled gracefully.
\end{itemize}
@@ -520,7 +520,7 @@ To address this limitation, we introduce a complementary \textit{data fuzzing} a
\paragraph{Fuzzing with Hypothesis}
Hypothesis is a property-based testing framework, which allows developers to define \textit{strategies} for input data. The framework then generates test cases based on these strategies and attempts to explore edge cases through randomized sampling and shrinking. Unlike traditional random fuzzing, Hypothesis ensures that generated inputs conform to the structural invariants defined by the strategy, thereby increasing the likelihood of discovering subtle logic errors in protocol handling.
Hypothesis integrates seamlessly with \texttt{pytest} and uses the \texttt{@given} decorator to specify input generation strategies. For example, given the \gls{asn1} structure defined in the SGP.22 specification for the \texttt{GetProfileInfo} function:
Hypothesis integrates seamlessly with \texttt{pytest} and uses the \texttt{@given} decorator to specify input generation strategies. For example, given the \gls{asn1} structure defined in the SGP.22 specification for the \texttt{Get\-Profile\-Info} function:
\begin{lstlisting}[caption={ASN.1 definition of the ProfileInfoListRequest}]
ProfileInfoListRequest ::= [45] SEQUENCE {

28
Chapters/RelatedWork.tex
View File

@@ -32,18 +32,6 @@ The ecosystem surrounding \gls{esim} and \gls{euicc} technology is supported by
% - 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 SGP.22 specification. The model is developed using \texttt{ProVerif}~\cite{blanchet_efficient_2001} 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 SIM Profile Transparency Protocol (SPTP), a protocol designed to enhance transparency and trust in the provisioning process.
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.
% osmocom euicc manual
% collection of technical information about euiccs -> collaborative effort
% collects information related to the SGP.22 specification
@@ -65,7 +53,19 @@ SPTP introduces two new entities: a private index service for managing \glspl{im
% as a result the GSMA address this issue in an updated TS.48 specification: prevent unauthorized actors from installing malicouse applets
% security explorations fear that this might not be enough: argues that this doesn't fix the core problem in the java card vm architecture
A valuable resource for empirical research into \gls{euicc} behavior is the Osmocom \gls{euicc} Manual, a collaborative and community-maintained repository of technical knowledge \cite{welte_euicc_2024}. It aggregates details related to the \gls{sgp22} specification and serves as an empirical database of observed behavior across commercial \glspl{euicc}. The manual includes data such as known card Asnwer-To-Request (ATRs), supported \gls{lpa} implementations, available test profiles, and proprietary command sequences. Although not exhaustive, this knowledge base has proven instrumental in identifying inconsistencies and behavioral quirks in vendor-specific \gls{euicc} implementations.
\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 SGP.22 specification. The model is developed using \texttt{ProVerif}~\cite{blanchet_efficient_2001} 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 SIM Profile Transparency Protocol (SPTP), a protocol designed to enhance transparency and trust in the provisioning process.
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.
A valuable resource for empirical research into \gls{euicc} behavior is the Osmocom \gls{euicc} Manual, a collaborative and community-maintained repository of technical knowledge \cite{welte_euicc_2024}. It aggregates details related to the SGP.22 specification and serves as an empirical database of observed behavior across commercial \glspl{euicc}. The manual includes data such as known card Asnwer-To-Request (ATRs), supported \gls{lpa} implementations, available test profiles, and proprietary command sequences. Although not exhaustive, this knowledge base has proven instrumental in identifying inconsistencies and behavioral quirks in vendor-specific \gls{euicc} implementations.
In terms of adversarial perspectives, \textcite{vervier_embedded_2023} explored the potential misuse of \glspl{esim} from a red team viewpoint, particularly investigating their feasibility as covert command-and-control (C2) channels. While he did not uncover a direct vulnerability that would facilitate reliable C2 communication, he proposed several attack vectors:
@@ -103,7 +103,7 @@ A more serious security assessment was presented by \textcite{security_explorati
\texttt{pySim}~\cite{welte_pysim_2024} is a Python-based toolset designed for interacting with \gls{sim} cards and their derivatives. It is developed and actively maintained by the Osmocom project, a community of engineers focused on open-source mobile communication tools. Osmocom is also responsible for related utilities such as \texttt{simtrace2}, a hardware and software solution for tracing \gls{sim} card communication, which is utilized in this thesis for trace collection.
The \texttt{pySim} suite comprises five primary scripts: \texttt{pySim-shell}, \texttt{\justify 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} 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.