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-05-31 18:53:41 +00:00
committed by node
parent 2b898d829a
commit 7103fb5cb7
4 changed files with 157 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
Chapters/Evaluation.tex
View File

@@ -5,10 +5,38 @@
%************************************************
\glsresetall % Resets all acronyms to not used
% evaluation goal: use differential testing to analyze the security of esim on sim cards
% evaluation was performed on multiple esim on sim: in total 8 esims (shown in table)
% including the sysmoEUICC: special card -> loaded with gsma test certificate -> can also be used for smdp server with gsma test certificate -> testing of systems
% test ceritificate is freely available
% firmware implementation should not differ from normal esims
% altough for tests including an smdp server we have to use profiles with the test certificate
% estk.me does not offer an isd-r for regular interaction with our lpa implmenetation -> tesing is limited
\begin{table}[ht]
\centering
\begin{tabular}{|l|l|l|l|l|l|l|c|}
\hline
\textbf{Name} & \textbf{Manufacturer} & \textbf{Firmware} & \textbf{SVN} & \textbf{Apps} \\
\hline
\hline
9esim v2 & Kigen & 36.18.5 & 2.3.0 & 12 \\
9esim & Kigen & 36.17.4 & 2.3.0 & 11 \\
sysmoEUICC & Kigen & 35.6.35 & 2.3.0 & 8 \\
EIOTClub & Kigen & 36.7.24 & 2.3.0 & 10 \\
esim.me & Eastcompeace & 4.2.0 & 2.2.0 & 0 \\
estk.me & G+D & 4.6.0 & 2.2.0 & 0 \\
5Ber & Eastcompeace & 4.2.0 & 2.2.2 & 0 \\
Xesim & Eastcompeace & 4.2.0 & 2.2.2 & 0 \\
\hline
\end{tabular}
\caption{Overview of Analyzed eSIM Cards}
\label{tab:esim-overview}
\end{table}
\section{Design}
\section{Findings}
\label{sec:findings}
\section{estk Firmware Update Application}
\lipsum[5]

124
Chapters/Implementation.tex
View File

@@ -564,8 +564,130 @@ According to the \gls{sgp22} specification, many functions may return a generic
By contrast, when an \texttt{UndefinedError} is returned, we treat this as a potential indicator of an unhandled internal error or inconsistent implementation behavior. These cases are flagged for further investigation. Additionally, exceptions occurring outside the \gls{euicc}, such as Python \texttt{AssertionError}s or test harness failures, are treated as bugs in the testing infrastructure and are logged separately.
\paragraph{Conclusion}
By combining property-based data generation with structural knowledge of \gls{asn1} types, we extend the fuzzing coverage of the \gls{euicc} interface beyond what is possible with \gls{apdu} mutation alone. This enables the discovery of semantic inconsistencies and unhandled corner cases in \gls{euicc} implementations, especially when compared across different vendors during differential testing as shown in \cref{subsec:differential_testing}).
By combining property-based data generation with structural knowledge of \gls{asn1} types, we extend the fuzzing coverage of the \gls{euicc} interface beyond what is possible with \gls{apdu} mutation alone. This enables the discovery of semantic inconsistencies and unhandled corner cases in \gls{euicc} implementations, especially when compared across different vendors during differential testing as shown in \cref{subsec:differential_testing}.
\section{CLI}
\label{sec:cli}
% implementation can be used as a library for scripting with the lpa
% easier to use for most users is a cli -> make the functionality available as a cli i.e tracing, lpa, and fuzzing
% faster to record new esims for the apdu fuzzing etc
% to implement argument parsing we use the standard library argparse together with argcomplete for console autocompletion and rich for prettier output printing
% structure
% cli is structure in 3 main functions tracing, lpa, and fuzzing
% tracer (as shown in tracing section) handles the tracing of apdus between the simtrac2 and lpa
% lpa makes all the euicc, notification and profile handling functions available via a cli
% fuzz is split up into data fuzzing and apdu fuzzing aswell as compare -> enables comparison of two or more recordings and prints them out as json (json represents tree structure and shows differences)
% data fuzzing basically wraps pytest and executes all tests for each test class
%
% structure is defined by the folders
% each subfolder represents a new kind of functionality i.e fuzz or lpa -> see figure that shows tree structure
% the __init__ folders implement a run() function in which the args are parsed and distributed to the corresponding handling functions -> distribution also calls run() function with the args of the corresponding handling function -> see listing
% parser definiction happens on the handler level and global arguments are difined in the __init__ file in which also the subparsers are attached to the parent parser
% extensibility
% easy to extend thanks to its modular sturcuture
% completly independet from library -> library does not depend on cli
While the implemented library provides a programmatic interface to the \gls{lpa} and \gls{euicc} operations, many users—especially testers and engineers—require a more accessible method for interacting with the system. For this reason, we provide a fully-featured \gls{cli} that exposes all major functionalities of the system, including \gls{apdu} tracing, \gls{lpa} operations, and fuzzing workflows.
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}
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 \gls{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 Figure~\ref{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{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.
\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}
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.