niklas/master_thesis
1
0
Fork 0
mirror of https://sharelatex.tu-darmstadt.de/git/681e0e7a3a9c7c9c6b8bb298 synced 2025-12-08 05:27:59 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update on Overleaf.

Browse Source
This commit is contained in:
nb72soza Bittner
2025-07-11 22:20:04 +00:00
committed by node
parent 4d04daa0dd
commit 8a9bed4aea
4 changed files with 48 additions and 36 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
Chapters/Evaluation.tex
View File

@@ -17,6 +17,7 @@
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}.
\todo{List Hardware specs}
\begin{table}[ht]
\centering
@@ -41,7 +42,7 @@ To conduct a thorough and representative evaluation, we selected a diverse set o
Among the tested cards, the \textbf{sysmoEUICC} is loaded with a \gls{gsma} test certificate, allowing it to interact with the official \gls{smdpp} test server infrastructure. This certificate is publicly available and enables the evaluation of remote profile management procedures in a realistic but controlled environment. The firmware implementation of the sysmoEUICC is assumed to be functionally equivalent to production-grade \glspl{esim}. However, this restricts use to use Profiles which are also signed by the \gls{gsma} test certificate.
In contrast, \textbf{estk.me} does not expose an \gls{isdr} for \gls{lpa}-based interaction, limiting the scope of evaluation for that platform. As such, only \gls{usat}-based interaction was possible, and no \gls{rsp}-related operations via the implemented testing framework could be performed.
In contrast, \textbf{estk.me} does not expose an \gls{isdr} for \gls{lpa}-based interaction, limiting the scope of evaluation for that platform. As such, only \gls{usat}-based interaction was possible, and no \gls{rsp}-related operations via the implemented testing framework could be performed. \todo{Check how estk.me implements rsp -> maybe rlpa etc}
The \textbf{9esim v2} card, in comparison, fully supports both \gls{isdr} access and \gls{usat} communication. Although \gls{usat} interfaces were excluded from evaluation for this particular card due to it not being supported by the testing framwork.
@@ -164,6 +165,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}
\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.
@@ -194,7 +196,7 @@ The update process proceeds as follows:
\begin{itemize}
\item Firmware is divided into blocks of size \texttt{0x80D} bytes.
\item Each block is sent in subchunks, using standard \glspl{apdu} (\texttt{CLA=0xAA}) with \texttt{INS=0x11}.
\item After transmission, the same chunk is re-sent with \texttt{INS=0x12}, no payload, and the expected response length (\texttt{Le}) matches the chunk size.
\item After transmission, the same chunk is re-sent with \texttt{INS=0x12}, no payload, and the expected response length (\texttt{Le}) matching the original chunk size. This verification step is performed to ensure that the chunk was transmitted and received correctly, \ie, the \gls{euicc} confirms that the length of the previously received payload matches the expected length. We assume that the \gls{euicc} performs an internal consistency check between the declared length and the actual received bytes to validate chunk integrity.
\end{itemize}
\item \textbf{Check Flash Status}: The \gls{apdu} \texttt{AA13000000} is used to verify correct flash writing.
\item \textbf{Finalize}: The \gls{apdu} \texttt{AA00000000} marks the end of the update process.
@@ -206,7 +208,7 @@ The update tool fails gracefully only under specific conditions. For malformed o
Using insights gained from disassembly in Ghidra, a Python-based reimplementation of the update mechanism was developed and available via the \gls{cli} as shown in \cref{sec:cli}. This allowed fine-grained control over the update process and enabled targeted mutation-based testing of firmware blocks.
The same mutation strategies as shown in \cref{subsubsec:mutation_engine}, such as bit flipping, byte shuffling, truncation, and others, were applied to the firmware blocks on a per-chunk basis during both initial transmission and block validation. Notably, mutated blocks were generally accepted until the \texttt{check\_flash\_status} step, where the \gls{euicc} would immediately terminate the connection. This behavior strongly suggests that the device internally verifies each block against a checksum or hash.
The same mutation strategies as shown in \cref{subsubsec:mutation_engine}, such as bit flipping, byte shuffling, truncation, and others, were applied to the firmware blocks on a per-chunk basis during both initial transmission and block validation. Notably, mutated blocks were generally accepted until the \texttt{check\_flash\_status} step, where the \gls{euicc} would immediately terminate the connection. This behavior strongly suggests that the device internally verifies each block against a checksum, hash or cryptographic signature.
@@ -234,11 +236,11 @@ The same mutation strategies as shown in \cref{subsubsec:mutation_engine}, such
\section{Tracing}
\label{sec:eval_tracing}
To investigate vendor-specific behaviors in \gls{rsp}, we employed SIMTrace2 to capture the \glspl{apdu} exchanged between the \gls{lpa} and the \gls{esim}. This enabled us to analyze the communication protocols used during profile management and \gls{euicc} interaction, especially focusing on the discovery and selection of the \gls{isdr}.
To investigate vendor-specific behaviors in \gls{rsp}, we employed SIMTrace2 to capture the \glspl{apdu} exchanged between the \gls{lpa} running on a phone and the \gls{esim}. This enabled us to analyze the communication protocols used during profile management and \gls{euicc} interaction, especially focusing on the discovery and selection of the \gls{isdr}.
During the analysis of the \texttt{eSIM.me} eSIM, we observed the use of a custom \gls{aid} during the SELECT command for \gls{isdr}. The following listing illustrates a sample trace captured while launching the \texttt{esim.me} Android application:
\begin{lstlisting}[style=logstyle, escapeinside={(*}{*)}, caption={Traced APDUs when launching the esim.me App}]
\begin{lstlisting}[style=logstyle, escapeinside={(*}{*)}, caption={Traced APDUs when launching the esim.me App. Captured commands are executed by the esim.me App.]
INFO Captured MANAGE CHANNEL Apdu(00 70 00 00 01 01 9000)
INFO Captured SELECT MF/ADF.ISD-R Apdu(01 A4 04 00 10 a0000005591010ffffffff8900000100 6f1f8410a0000005591010ffffffff8900000100a5049f6501ffe0058203020200 9000)
INFO Captured MANAGE CHANNEL Apdu(00 70 00 00 01 01 9000)
@@ -279,6 +281,8 @@ While tracing provides valuable insights into command sequencing and \gls{aid} s
\section{Data Fuzzing}
\label{sec:data_fuzzing_evaluation}
\todo{Introduce different setups to make it more obvious when conducting seperate experiments}
\begin{table}[h!]
\centering
@@ -322,9 +326,9 @@ While tracing provides valuable insights into command sequencing and \gls{aid} s
\end{tabular}
\end{table}
Data fuzzing, as described in \cref{subsec:data_fuzzing}, was conducted on all tested \gls{esim} cards with the exception of \texttt{estk.me}. Each test case was executed sequentially across all eligible \glspl{esim} to ensure consistency and reproducibility of results.
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 devices:
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:
\begin{itemize}
\item 9esim
\item 9esim v2