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-12 22:54:06 +00:00
committed by node
parent bf7e86572e
commit f9130f1aee
4 changed files with 119 additions and 128 deletions
Download Patch File Download Diff File Expand all files Collapse all files

87
Appendices/SomeProof.tex
View File

@@ -95,3 +95,90 @@ This exception model provides the following advantages:
This exception system enables detailed introspection during fuzzing and testing while maintaining a clean abstraction between components.
% \todo{add section about inital testing of nonce randomness}
\section{CLI Structure}
\label{sec:cli_structure}
The CLI is organized around three core commands:
\begin{itemize}
\item \textbf{tracing} — Interfaces with the \texttt{simtrace2} device and the \gls{lpa} to capture \gls{apdu} traffic in real time. This functionality is discussed in detail in \cref{sec:tracing}.
\item \textbf{lpa} — Exposes \gls{euicc} communication features such as profile management, notification handling, and remote procedure execution via the \gls{cli}.
\item \textbf{fuzzing} — Wraps both \gls{apdu}-level and data-level fuzzing. Additionally, it provides a \texttt{compare} command to compare multiple trace recordings and highlight structural differences in JSON format.
\end{itemize}
Each of these commands is implemented in its respective subfolder (e.g., \texttt{tracing/}, \texttt{lpa/}, \texttt{fuzz/}). The modular structure of the \gls{cli} is shown in \cref{fig:cli_structure}, which illustrates how the subcommands map to the file and folder hierarchy of the project.
\begin{figure}[h]
\centering
\begin{forest}
for tree={
font=\ttfamily,
grow'=0,
child anchor=west,
parent anchor=south,
anchor=west,
calign=first,
inner sep=1pt,
l=1.5em,
s sep=3pt,
edge path={
\noexpand\path [draw, \forestoption{edge}]
(!u.south west) +(3.5pt,0) |- node[fill,inner sep=1.25pt] {} (.child anchor)\forestoption{edge label};
},
before typesetting nodes={
if n=1
{insert before={[,phantom]}}
{}
},
fit=band,
before computing xy={l=15pt},
}
[cli
[\_\_init\_\_.py]
[fuzzer
[\_\_init\_\_.py]
[apdu\_fuzzer.py]
[compare.py]
[data\_fuzzer.py]
]
[trace
[\_\_init\_\_.py]
[record.py]
[replay.py]
]
[lpa
[\_\_init\_\_.py]
[euicc.py]
[notification.py]
[profile.py]
]
]
\end{forest}
\caption{\gls{cli} folder structure and modular separation of functionality}
\label{fig:cli_structure}
\end{figure}
\paragraph{Dispatch and Argument Parsing}
Each submodule implements a \texttt{run()} function that parses the subcommand’s specific arguments and dispatches execution to the appropriate internal handler. At the top level, the root \texttt{\_\_init\_\_.py} file defines the global parser, registers the subcommands via subparsers, and handles any global options. This design pattern is shown in \cref{lst:cli_parser}.
\begin{lstlisting}[caption={Top-level CLI dispatch pattern}, label={lst:cli_parser}]
def add_subparser(parent_parser: argparse._SubParsersAction) -> None:
trace_parser: argparse.ArgumentParser = parent_parser.add_parser(
"trace",
help="Trace-level operations (record, replay)",
formatter_class=RichHelpFormatter,
)
trace_subparsers = trace_parser.add_subparsers(dest="trace_command", required=True)
record.add_subparser(trace_subparsers)
replay.add_subparser(trace_subparsers)
def run(args: argparse.Namespace) -> None:
if args.trace_command == "record":
record.run(args)
elif args.trace_command == "replay":
replay.run(args)
\end{lstlisting}
Each subcommand module (e.g., \texttt{fuzz/data\_fuzz.py}) provides its own parser configuration and encapsulated logic, adhering to a clearly defined interface.

69
Chapters/Evaluation.tex
View File

@@ -17,6 +17,12 @@
The primary objective of this evaluation is to apply differential testing to analyze the behavior and potential security implications of various commercial eSIM on SIM solutions. This methodology aims to uncover inconsistencies, implementation deviations, and potential vulnerabilities by observing how different cards react to the same input sequences under controlled conditions.
To conduct a thorough and representative evaluation, we selected a diverse set of eSIM-on-SIM cards from multiple vendors. In total, \textbf{eight} different cards were included in the analysis, as shown in Table~\ref{tab:esim-overview}. These cards vary in terms of manufacturer, supported features, and firmware versions. The tests were conducted using the tracing, mutation, and fuzzing infrastructure described in \cref{ch:implementation}.
% experiments were conduct on a host machine running arch linux
% 32 GB of RAM, and and Ryzen 7 (find out actual version)
% smart card reader is the HID OMNIKEY 3121 USB
All experiments were performed on a host machine running Arch Linux, equipped with 32\,GB of RAM and an AMD Ryzen 7 5800X processor. For physical communication with the \gls{esim} cards, an HID OMNIKEY 3121 USB smart card reader was used.
\todo{List Hardware specs}
\begin{table}[ht]
@@ -127,7 +133,7 @@ Among all evaluated \glspl{esim}, \texttt{estk.me} stands out due to its publicl
The firmware image accompanying the update utility appears to be encrypted or obfuscated. An entropy analysis conducted using the Shannon entropy metric indicates a consistently high entropy across all tested firmware files, suggesting the presence of encryption or compression. For instance, the entropy of the T001V06 firmware image was measured at approximately \texttt{7.998}, which is close to the theoretical maximum of \texttt{8.0} for purely random data.
\begin{figure}[htbp]
\begin{figure}[ht]
\centering
\begin{tikzpicture}
\begin{axis}[
@@ -142,6 +148,7 @@ The firmware image accompanying the update utility appears to be encrypted or ob
xmin=0,
ymin=0,
grid,
axis lines=left
]
\addplot[
@@ -165,7 +172,7 @@ The firmware image accompanying the update utility appears to be encrypted or ob
\end{axis}
\end{tikzpicture}
\caption{Shannon entropy values across blocks for three different firmware versions.}
\todo{Start with block 0, explain drop off at 200}
\todo{explain drop off at 200}
\end{figure}
A deeper static analysis using Ghidra~\cite{nsa_ghidra_2025} did not reveal any recognizable structure or file headers, further supporting the assumption of encryption. Similarly, tools like Binwalk~\cite{refirmlabs_binwalk_2025} did not detect known compression schemes, embedded file systems, or file signatures. Consequently, firmware payload analysis could not be meaningfully performed beyond block-level transmission.
@@ -284,52 +291,33 @@ While tracing provides valuable insights into command sequencing and \gls{aid} s
\todo{Introduce different setups to make it more obvious when conducting seperate experiments}
\begin{table}[h]
\begin{table}[t]
\begin{adjustwidth}{-.5in}{-1.5in}
\centering
\caption{Data fuzzing results for 5ber, eSIM.me, and EIOTCLUB}
\label{tab:data_fuzzing_result_part1}
\begin{tabular}{lccc}
\caption{Data fuzzing results for for all tested eSIM-on-SIM cards. }
\label{tab:data_fuzzing_result}
\begin{tabular}{lcccccc}
\toprule
\textbf{Function} & \textbf{5ber} & \textbf{eSIM.me} & \textbf{EIOTCLUB} \\
\textbf{Function} & \textbf{5ber} & \textbf{eSIM.me} & \textbf{EIOTCLUB} & \textbf{9esim} & \textbf{9esim v2} & \textbf{Xesim} \\
\midrule
SetDefaultDpAddress & \cmark & \cmark & \cmark \\
EuiccMemoryReset & \cmark & \cmark & \cmark \\
RetrieveNotificationsList & \cmark & \cmark & \cmark \\
ListNotification & \cmark & \cmark & \cmark \\
ProfileInfoList & \cmark & \cmark & \xmark \\
SetNickname & \cmark & \cmark & \cmark \\
PrepareDownload & \cmark & \cmark & \cmark \\
AuthenticateServer & \cmark & \cmark & \cmark \\
BoundProfilePackage & \cmark & \cmark & \cmark \\
SetDefaultDpAddress & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
EuiccMemoryReset & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
RetrieveNotificationsList & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
ListNotification & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
ProfileInfoList & \cmark & \cmark & \xmark & \xmark & \xmark & \cmark \\
SetNickname & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
PrepareDownload & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
AuthenticateServer & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
BoundProfilePackage & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
\bottomrule
\end{tabular}
\end{table}
\begin{table}[h]
\centering
\caption{Data fuzzing results for 9esim, 9esim v2, and Xesim}
\label{tab:data_fuzzing_result_part2}
\begin{tabular}{lccc}
\toprule
\textbf{Function} & \textbf{9esim} & \textbf{9esim v2} & \textbf{Xesim} \\
\midrule
SetDefaultDpAddress & \cmark & \cmark & \cmark \\
EuiccMemoryReset & \cmark & \cmark & \cmark \\
RetrieveNotificationsList & \cmark & \cmark & \cmark \\
ListNotification & \cmark & \cmark & \cmark \\
ProfileInfoList & \xmark & \xmark & \cmark \\
SetNickname & \cmark & \cmark & \cmark \\
PrepareDownload & \cmark & \cmark & \cmark \\
AuthenticateServer & \cmark & \cmark & \cmark \\
BoundProfilePackage & \cmark & \cmark & \cmark \\
\bottomrule
\end{tabular}
\todo{Merge tables and explain check mark and cross}
\caption*{\cmark \hspace{.2cm} indicates that fuzzing did not find any bug \\ \xmark \hspace{.2cm} indicates an error during the fuzzing operation}
\end{adjustwidth}
\end{table}
We conducted data fuzzing, as described in \cref{subsec:data_fuzzing}, on all tested \gls{esim} cards with the exception of \texttt{estk.me}. Each test case is executed sequentially across all eligible \glspl{esim} to ensure consistency and reproducibility of results.
The majority of the cards handled the fuzzed input data as expected, either processing the requests successfully or rejecting them gracefully with standard-compliant error responses. However, notable exceptions were observed during the execution of the \texttt{GetProfileInfo} test case as shown in \cref{tab:data_fuzzing_result_part1} and \cref{tab:data_fuzzing_result_part2}, particularly for the following cards:
The majority of the cards handled the fuzzed input data as expected, either processing the requests successfully or rejecting them gracefully with standard-compliant error responses. However, notable exceptions were observed during the execution of the \texttt{GetProfileInfo} test case as shown in \cref{tab:data_fuzzing_result}, particularly for the following cards:
\begin{itemize}
\item 9esim
\item 9esim v2
@@ -417,8 +405,7 @@ To evaluate the robustness of \gls{rsp} protocol handling and smart card behavio
Initial fuzzing experiments revealed that applying aggressive mutations across all \glspl{apdu} early in a transaction significantly hindered code path exploration. In many cases, although a mutation in an early \gls{apdu} succeeded in provoking an altered behavior or state change, subsequent mutated \glspl{apdu} caused premature failures. As a mitigation strategy, we adopted a greedy mutation approach: once a mutation led to a successful state transition, the subsequent \glspl{apdu} in that session were executed unmutated to allow complete transaction processing and thereby maximize coverage.
\subsection*{Experimental Setup}
All tests were conducted using a HID OMNIKEY 3121 USB smart card reader.\glspl{esim} were inserted into a Sysmocom 2FF-to-full-size adapter to ensure compatibility with the reader. For consumer-grade \glspl{esim}, the following profile was used:
\todo{Reference where the profiles are comming from}
All tests are conducted with test profiles that use the \gls{gsma} Live CI and are offered by various \glspl{mno} \cite{welte_euicc_2024}. For consumer-grade \glspl{esim}, the following profile was used:
\begin{center}
\texttt{LPA:1\$rsp.truphone.com\$QR-G-5C-1LS-1W1Z9P7}
\end{center}

89
Chapters/Implementation.tex
View File

@@ -633,95 +633,10 @@ While the implemented library provides a programmatic interface to the \gls{lpa}
The \gls{cli} is built using Python’s standard \texttt{argparse} module for argument parsing, extended with \texttt{argcomplete} to enable shell auto-completion. For improved readability and formatting of terminal output, the \texttt{rich} library is used. This combination allows for an interactive, user-friendly \gls{cli} with both developer ergonomics and production readiness in mind.
\subsection*{Structure}
\todo{Put this section into the appendix}
The CLI is organized around three core commands:
\begin{itemize}
\item \textbf{tracing} — Interfaces with the \texttt{simtrace2} device and the \gls{lpa} to capture \gls{apdu} traffic in real time. This functionality is discussed in detail in \cref{sec:tracing}.
\item \textbf{lpa} — Exposes \gls{euicc} communication features such as profile management, notification handling, and remote procedure execution via the \gls{cli}.
\item \textbf{fuzzing} — Wraps both \gls{apdu}-level and data-level fuzzing. Additionally, it provides a \texttt{compare} command to compare multiple trace recordings and highlight structural differences in JSON format.
\end{itemize}
Each of these commands is implemented in its respective subfolder (e.g., \texttt{tracing/}, \texttt{lpa/}, \texttt{fuzz/}). The modular structure of the \gls{cli} is shown in \cref{fig:cli_structure}, which illustrates how the subcommands map to the file and folder hierarchy of the project.
\begin{figure}[h]
\centering
\begin{forest}
for tree={
font=\ttfamily,
grow'=0,
child anchor=west,
parent anchor=south,
anchor=west,
calign=first,
inner sep=1pt,
l=1.5em,
s sep=3pt,
edge path={
\noexpand\path [draw, \forestoption{edge}]
(!u.south west) +(3.5pt,0) |- node[fill,inner sep=1.25pt] {} (.child anchor)\forestoption{edge label};
},
before typesetting nodes={
if n=1
{insert before={[,phantom]}}
{}
},
fit=band,
before computing xy={l=15pt},
}
[cli
[\_\_init\_\_.py]
[fuzzer
[\_\_init\_\_.py]
[apdu\_fuzzer.py]
[compare.py]
[data\_fuzzer.py]
]
[trace
[\_\_init\_\_.py]
[record.py]
[replay.py]
]
[lpa
[\_\_init\_\_.py]
[euicc.py]
[notification.py]
[profile.py]
]
]
\end{forest}
\caption{\gls{cli} folder structure and modular separation of functionality}
\label{fig:cli_structure}
\end{figure}
\paragraph{Dispatch and Argument Parsing}
Each submodule implements a \texttt{run()} function that parses the subcommand’s specific arguments and dispatches execution to the appropriate internal handler. At the top level, the root \texttt{\_\_init\_\_.py} file defines the global parser, registers the subcommands via subparsers, and handles any global options. This design pattern is shown in \cref{lst:cli_parser}.
\begin{lstlisting}[caption={Top-level CLI dispatch pattern}, label={lst:cli_parser}]
def add_subparser(parent_parser: argparse._SubParsersAction) -> None:
trace_parser: argparse.ArgumentParser = parent_parser.add_parser(
"trace",
help="Trace-level operations (record, replay)",
formatter_class=RichHelpFormatter,
)
trace_subparsers = trace_parser.add_subparsers(dest="trace_command", required=True)
record.add_subparser(trace_subparsers)
replay.add_subparser(trace_subparsers)
def run(args: argparse.Namespace) -> None:
if args.trace_command == "record":
record.run(args)
elif args.trace_command == "replay":
replay.run(args)
\end{lstlisting}
Each subcommand module (e.g., \texttt{fuzz/data\_fuzz.py}) provides its own parser configuration and encapsulated logic, adhering to a clearly defined interface.
The CLI structure is further detailed in \cref{sec:cli_structure}.
\paragraph{Integration with Pytest}
The data fuzzing component internally wraps \texttt{pytest}, leveraging the structure of Python test classes defined with the Hypothesis framework (cf. Section~\ref{subsec:data_fuzzing}). Each test class corresponds to a group of \gls{rsp} commands. By invoking the data fuzzing \gls{cli}, all available test classes are executed against the connected \gls{euicc}, with proper initialization and teardown logic handled automatically.
\subsection*{Extensibility}
\paragraph{Extensibility}
The \gls{cli} is designed with extensibility as a primary concern. Adding new commands requires minimal effort: developers only need to create a new subfolder, define a \texttt{run()} function, and register the new command in the main \gls{cli} dispatcher. Moreover, the \gls{cli} is completely decoupled from the core library logic, ensuring that library users are not forced to depend on the \gls{cli} subsystem and vice versa.

2
Chapters/RelatedWork.tex
View File

@@ -85,6 +85,8 @@ A more serious security assessment was presented by \textcite{security_explorati
\textcite{security_explorations_esim_2025} responsibly disclosed the vulnerability to Kigen, GSMA, and Oracle. As a result, GSMA introduced additional restrictions in the updated TS.48 specification v7.0~\cite{gsma_ts48_2025}, aiming to prevent unauthorized applet installations. However, the researchers voiced concern that this measure only mitigated the symptoms rather than addressing the core vulnerability in the Java Card VM architecture.
\todo{Find more relevant papers i.e side-channel attacks, etc}
\section{Software and Hardware Implementations}
\paragraph{pySim}