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-15 15:59:23 +00:00
committed by node
parent ab40f6e909
commit e702a2aa6f
11 changed files with 864 additions and 723 deletions
Download Patch File Download Diff File Expand all files Collapse all files

39
Chapters/Evaluation.tex
View File

@@ -14,14 +14,15 @@
% estk.me does not offer an isd-r for regular interaction with our lpa implmenetation -> tesing is limited
% 9esim v2 offers both -> only testing isd-r not USAT for RSP related communication
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 (6.15.5-zen)
% 32 GB of RAM, and and Ryzen 7 5800x
% smart card reader is the HID OMNIKEY 3121 USB in combination with sysmocom smart card adapter v1
% smartcard middleware library: pcsclite 2.3.3-1
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.
\marginpar{Eight commercial eSIM-on-SIM cards from different vendors were selected for analysis.}
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}.
All experiments were conducted on a host machine running Arch Linux (kernel version \texttt{6.15.5-zen}), equipped with an AMD Ryzen 7 5800X CPU and 32\,GB of RAM. For smart card interfacing, we used the HID OMNIKEY 3121 USB smart card reader in combination with the sysmocom Smart Card Adapter v1. The middleware stack was based on \texttt{pcsclite} version \texttt{2.3.3-1}, providing the PC/SC interface for APDU-level communication with the inserted \glspl{euicc}.
\begin{table}[ht]
@@ -47,7 +48,7 @@ All experiments were conducted on a host machine running Arch Linux (kernel vers
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. \todo{Check how estk.me implements rsp -> maybe rlpa etc}
In contrast, \textbf{estk.me} allows users to manually enable \gls{isdr} mode, which theoretically permits access via an \gls{lpa}.
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.
@@ -131,6 +132,7 @@ Among all evaluated \glspl{esim}, \texttt{estk.me} stands out due to its publicl
\paragraph{Firmware Structure and Analysis.}
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.
\marginpar{Firmware entropy analysis suggests encryption or compression.}
\begin{figure}[ht]
\centering
@@ -190,9 +192,10 @@ The \gls{aid} used to access the update utility differs based on firmware genera
\texttt{A06573746B6D65FFFFFFFF6677757064} \\
(hex-encoded: \texttt{'estkmeÿÿÿÿfwupd'})
\end{quote}
\marginpar{Firmware follows one-way TXXXVXX versioning with no downgrade support.}
Firmware versions follow the format \texttt{TXXXVXX}, where major generation (\texttt{T000}--\texttt{T003}) and minor version are encoded. Firmware updates are incremental and strictly one-way, the tool automatically selects the next version based on the currently installed one, and downgrade paths are not supported.
Earlier releases of the firmware update utility included the corresponding C source code used to build the update binary. However, more recent versions of the utility are distributed only as precompiled binaries, without source code availability. Access to the original source-based versions is now limited and typically requires archival tools such as the Wayback Machine \footnote{https://web.archive.org/web/20250000000000*/https://www.estk.me/downloads/}.
Earlier releases of the firmware update utility included the corresponding C source code used to build the update binary. However, more recent versions of the utility are distributed only as precompiled binaries, without source code availability for newer versions. Access to the original source-based versions is now limited and requires archival tools such as the Wayback Machine \footnote{https://web.archive.org/web/20250000000000*/https://www.estk.me/downloads/}.
\paragraph{Firmware Flashing Procedure.}
@@ -203,7 +206,7 @@ The update process proceeds as follows:
\item \textbf{Send Firmware Blocks}:
\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 Each block is sent in subchunks, using standard \glspl{apdu} (\texttt{CLA=0xAA}) with \texttt{INS=0x11}.\marginpar{Firmware is split into blocks, then subchunks for transmission and verification.}
\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.
@@ -215,6 +218,7 @@ The update tool fails gracefully only under specific conditions. For malformed o
\paragraph{Reverse Engineering and Mutation Testing.}
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.
\marginpar{Mutated chunks often pass until flash check, indicating internal block verification logic.}
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.
@@ -251,7 +255,7 @@ The same mutation strategies as shown in \cref{subsubsec:mutation_engine}, such
\label{img:trace_setup}
\end{figure}
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}.
To investigate vendor-specific behaviors in \gls{rsp}, we employed SIMTrace2\marginpar{SIMTrace2 captured vendor-specific APDU sequences during eSIM profile management.} 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:
@@ -265,7 +269,7 @@ INFO Captured SELECT Apdu(01 A4 04 00 10 a0000005591010000000008900000300
The log highlights a noteworthy behavior: in line \ref{code:unkown_aid}, the SELECT command targets an unknown \gls{aid} \texttt{a0000005591010000000008900000300}, which results in status word \texttt{6A82} (File not found). This custom \gls{aid} is not documented in standard \gls{gsma} or \gls{gp} specifications and appears to be vendor-specific.
This behavior suggests that certain vendors, such as \texttt{esim.me}, implement proprietary \glspl{aid} in parallel to the standardized \gls{isdr} \gls{aid} (\texttt{A0000005591010FFFFFFFF8900000100}). This may serve as an obfuscation or access control measure, potentially restricting third-party \gls{lpa} implementations or enforcing usage of vendor-specific software. However, due to the mandatory access mediation performed by the \gls{aram}, the effectiveness of such mechanisms is ultimately constrained by access control policies defined on the card.
This behavior suggests that certain vendors, such as \texttt{esim.me}, implement proprietary \glspl{aid} in parallel to the standardized \gls{isdr} \gls{aid} (\texttt{A0000005591010FFFFFFFF8900000100}).\marginpar{Vendors may use custom AIDs for obfuscation or third-party access restriction.} This may serve as an obfuscation or access control measure, potentially restricting third-party \gls{lpa} implementations or enforcing usage of vendor-specific software. However, due to the mandatory access mediation performed by the \gls{aram}, the effectiveness of such mechanisms is ultimately constrained by access control policies defined on the card.
We catalogued the \gls{isdr} \glspl{aid} observed during tracing across multiple \gls{esim} vendors:
@@ -277,7 +281,7 @@ We catalogued the \gls{isdr} \glspl{aid} observed during tracing across multiple
\end{itemize}
This variation in \gls{aid} usage may be driven by internal vendor policy, branding, or the need to segment access to multiple security domains or services. In the case of \texttt{eSIM.me}, the coexistence of both the standard and custom \glspl{aid} suggests a fallback mechanism for compatibility with generic \gls{lpa} implementations.
\marginpar{Tracing helps analyze AID use but is limited without valid credentials.}
While tracing provides valuable insights into command sequencing and \gls{aid} selection behaviors, its utility is restricted when it comes to exercising full profile management flows or cross-device compatibility testing without access to valid cryptographic credentials.
% data fuzzing
@@ -343,7 +347,7 @@ In all three cases, the fuzzing input
get_profiles(use_iccid=False, profile_class=None, tags=b'')
\end{lstlisting}
resulted in a \texttt{CardConnectionException} raised by the \texttt{smartcard} Python library during \gls{apdu} transmission.
resulted in a \texttt{CardConnection\-Exception} raised by the \texttt{smartcard} Python library during \gls{apdu} transmission.
During these failures, a consistent and unusual hardware behavior was observed. The transaction LED on the card reader continued to blink, suggesting ongoing \gls{apdu} activity, even though no further commands were being issued by the fuzzing logic. This blinking persisted even after the test process was terminated and, in some cases, even after the \gls{esim} card was physically removed from the reader.
@@ -457,10 +461,10 @@ The execution time of fuzzed \gls{apdu} sequences varied depending on chip proce
%
% \end{itemize}
\begin{table}[ht]
\begin{adjustwidth}{-1in}{}
\begin{table}[H]
\begin{adjustwidth}{}{-1in}
\centering
\caption{Overview of Observed Error Types by Functions and Mutation Types}
\caption{Overview of Observed Error Types by Functions and all Mutation Types.}
\label{tab:error_overview}
\begin{tabular}{|p{4cm}|p{5cm}|p{4cm}|}
\hline
@@ -739,12 +743,13 @@ We performed a set of differential tests across two configurations:
\item \textbf{Cross-server scenario:} When changing the server to a different \gls{smdpp} (e.g., from \texttt{rsp.truphone.com} to \texttt{rsp-eu.redte\-mobile.com}), the identical $AS_2$ was rejected with an \texttt{UndefinedError}.
\end{itemize}
These results confirm that the \gls{euicc} caches authentication state scoped to the server identity as shown in \cref{img:auth-bypass-cache}. Notably, this state appears to persist even across full power cycles. When the \gls{esim} was physically removed from the card reader and reinserted, the same truncation attack still succeeded, indicating that state was retained in non-volatile storage.
These results confirm that the \gls{euicc} caches authentication state scoped to the server identity as shown in \cref{img:auth_bypass_cache}. Notably, this state appears to persist even across full power cycles. When the \gls{esim} was physically removed from the card reader and reinserted, the same truncation attack still succeeded, indicating that state was retained in non-volatile storage.
\begin{figure}[ht]
\begin{figure}[H]
\centering
\includesvg[width=\textwidth,inkscapelatex=false]{Graphics/vulnerability_sd.svg}
\label{img:auth_bypass_cache}
\caption{Impact of server identity on authentication state reuse. In same-server attacks, a malformed $AS_1$ followed by a truncated $AS_2$ leads to profile installation. In cross-server attacks, $AS_2$ is rejected, indicating scoped state persistence.}
\label{img:auth-bypass-cache}
\end{figure}
\paragraph{Example Mutation Patterns.}
@@ -768,7 +773,7 @@ These observations suggest that state retention is selective and scoped to prior
\subsection*{RQ3: Skipping Signature Verification via State Reuse}
\label{sec:rq3-signature}
Finally, to determine whether signature validation $\mathrm{Cert}_{Sa} \triangleleft \mathrm{Cert}_{CI}$ as shown in \cref{img:authenticate_server_sd} is skipped, we modified the truncated certificate in $AS_2$ by injecting an attacker-controlled public key $SK_A$ into the \texttt{SubjectPublicKeyInfo} field. Despite this manipulation, the \gls{euicc} still proceeded to mutual authentication and secure channel establishment.
Finally, to determine whether signature validation $\mathrm{Cert}_{Sa} \triangleleft \mathrm{Cert}_{CI}$ is skipped, we modified the truncated certificate in $AS_2$ by injecting an attacker-controlled public key $SK_A$ into the \texttt{SubjectPublicKeyInfo} field. Despite this manipulation, the \gls{euicc} still proceeded to mutual authentication and secure channel establishment.
The only plausible explanation is that the \gls{euicc} ignored the actual contents of the truncated $Cert_{Sa}^{(2)}$, and instead reused the public key received in the previously failed $AS_1$. Supporting this, attempts to reverse the sequence (sending the truncated $AS_2$ first) always failed, as did replaying the same attack against a different \gls{smdpp}. Thus, \textbf{RQ3} is also confirmed: digital signature verification can be bypassed through state reuse.