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-07 00:56:57 +00:00
committed by node
parent 9e6e16c2f6
commit 8bf17984fc
9 changed files with 41 additions and 47 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
Chapters/Evaluation.tex
View File

@@ -35,15 +35,15 @@ To conduct a thorough and representative evaluation, we selected a diverse set o
Xesim & Eastcompeace & 4.2.0 & 2.2.2 & 0 \\
\hline
\end{tabular}
\caption{Overview of Analyzed eSIM Cards}
\caption{Overview of Analyzed eSIM Cards based on the information from \texttt{EuiccInfo2}.}
\label{tab:esim-overview}
\end{table}
Among the tested cards, the \textbf{sysmoEUICC} is loaded with a 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 GSMA test certificate.
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.
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.
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.
% general findings
@@ -587,9 +587,7 @@ The following classes of errors were consistently encountered during mutation ca
\subsection{Analysis of Successful Mutations}
\label{subsec:successful_mutations}
To further understand the behavior of different \glspl{euicc} under mutation-based fuzzing, we post-processed all recorded \gls{apdu} traces stored in the \texttt{recordings/*.resim} directory.
\todo{Be more clear about how many and which recordings were performed}
To further understand the behavior of different \glspl{euicc} under mutation-based fuzzing, we post-processed all recorded \gls{apdu} traces.
\subsubsection*{Mutation Examples}
@@ -637,7 +635,7 @@ By combining a series of failed and mutated authentication requests, it was poss
A deeper analysis of mutated \gls{apdu} payloads of the initial \texttt{AuthenticateServerRequest}, particularly in cases using different \gls{smdpp} servers, shows the following:
\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 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.
@@ -663,8 +661,8 @@ However, these attempts consistently resulted in an \texttt{UndefinedError} exce
This reinforces the assumption that the \gls{euicc} maintains non-trivial persistent state across sessions, and that this state influences the acceptance of subsequent messages even when they originate from clean profiles or well-formed certificates.
\todo{Find out which parts are reused aswell -> serverSigned1, serverSignature}
\todo{serverSigned1 -> check if signature is verified}
% \todo{Find out which parts are reused aswell -> serverSigned1, serverSignature}
% \todo{serverSigned1 -> check if signature is verified}
\subsubsection*{Implications}
The observed behavior violates \gls{gsma} security requirements, particularly in Sections 4.5.1 and 4.5.2 of SGP.22~\cite{gsma_sgp22_2025}, which mandate certificate chain validation and signature verification during server authentication. The following points summarize the core issues: