Update on Overleaf.

Chapters/Evaluation.tex

@@ -23,7 +23,7 @@ The primary objective of this evaluation is to apply differential testing to ana
 \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}.
+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 \gls{apdu}-level communication with the inserted \glspl{euicc}.
 
 \begin{table}[ht]
     \centering
@@ -131,8 +131,8 @@ 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.}
+The firmware image accompanying the update utility appears to be encrypted or obfuscated.
+\marginpar{Firmware entropy analysis suggests encryption or compression.} 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, which is running on our estk.me \gls{euicc}, was measured at approximately \texttt{7.998}, which is close to the theoretical maximum of \texttt{8.0} for purely random data.
 
 \begin{figure}[ht]
 \centering
@@ -173,7 +173,6 @@ 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{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.
@@ -192,8 +191,7 @@ 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.
+Firmware versions follow the format \texttt{TXXXVXX}, where major generation (\texttt{T000}--\texttt{T003}) and minor version are encoded.\marginpar{Firmware follows one-way TXXXVXX versioning with no downgrade support.} 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 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/}.
 
@@ -206,8 +204,8 @@ 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}.\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.
+            \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}) matching the original chunk size.\marginpar{Firmware is split into blocks, then subchunks for transmission and verification.} 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.
@@ -301,7 +299,7 @@ While tracing provides valuable insights into command sequencing and \gls{aid} s
 \label{sec:data_fuzzing_evaluation}
 
 \begin{table}[t]
-    \begin{adjustwidth}{-.5in}{-1.5in} 
+    \begin{adjustwidth}{-1.5in}{-.5in} 
     \centering
     \caption{Data fuzzing results for for all tested eSIM-on-SIM cards. }
     \label{tab:data_fuzzing_result}
@@ -333,7 +331,7 @@ We conducted data fuzzing, as described in \cref{subsec:data_fuzzing}, on all te
     \caption{Fuzzing setup}
     \label{img:fuzz_setup}
 \end{figure}
-
+\marginpar{Most cards responded to fuzzed inputs with correct or graceful error handling.}
 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
@@ -348,6 +346,7 @@ get_profiles(use_iccid=False, profile_class=None, tags=b'')
 \end{lstlisting}
 
 resulted in a \texttt{CardConnection\-Exception} raised by the \texttt{smartcard} Python library during \gls{apdu} transmission. 
+\marginpar{Failures resulted in CardConnectionException during APDU transmission indicating potential undefined state in libpcsc.}
 
 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.
 
@@ -419,9 +418,9 @@ The LED activity ceased only when the card reader was fully disconnected from th
 To evaluate the robustness of \gls{rsp} protocol handling and smart card behavior under malformed input, we applied mutation-based fuzzing at the \gls{apdu} level. The goal was to explore unintended code paths and observe crash conditions or unexpected responses.
 
 \subsection*{Optimizing for Coverage}
-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.
+Initial fuzzing experiments revealed that applying aggressive mutations across all \glspl{apdu} early in a transaction significantly hindered code path exploration.\marginpar{Greedy mutation strategy preserves successful state transitions to maximize coverage depth.} 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.
 
-\paragraph{Experimental Setup}
+\paragraph{Experimental Setup.}
 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} and the hardware setup as shown in \cref{img:fuzz_setup} For consumer-grade \glspl{esim}, the following profile was used:
 \begin{center}
 \texttt{LPA:1\$rsp.truphone.com\$QR-G-5C-1LS-1W1Z9P7}
@@ -434,7 +433,7 @@ For the \texttt{sysmoEUICC}, which uses the \gls{gsma} test certificate, the fol
 
 The execution time of fuzzed \gls{apdu} sequences varied depending on chip processing speed and the degree to which the mutated input triggered deeper protocol branches.
 
-\paragraph{Observed Errors}
+\paragraph{Observed Errors.}
 % The following classes of errors were consistently encountered during mutation campaigns:
 % 
 % \todo{Put errors into a table with example mutations and explain in text}
@@ -531,6 +530,7 @@ During the mutation-based differential testing campaing several distinct error t
 One of the most frequently encountered errors was \textbf{SCP03TSecurity\-Error}, which emerged during the execution of the \texttt{LoadBoundProfile\-Package} operation. Specifically, this error was triggered during the transmission of either \texttt{sequence\-Of86}, \texttt{sequence\-Of88}, or the initial \texttt{sequence\-Of87}, pointing to a failure in establishing the Secure Channel Protocol 03 session on the terminal side.
 
 Another recurring issue was the \textbf{ApduException}, which was caused by malformed \gls{asn1} structures. These were typically introduced by mutations that altered either the tag or the length fields within the encoded data, leading to parsing failures during transmission.
+\marginpar{Observed exceptions result from malformed ASN.1 structures, cryptographic validation failures, or protocol violations during secure channel setup.}
 
 The \textbf{InvalidCertificate} error was predominantly seen during the \texttt{AuthenticateServer} and \texttt{PrepareDownload} commands. In these cases, the \gls{euicc} explicitly rejected the provided server certificate, signaling a failure in certificate validation, possibly due to mutations in the certificate’s structure or encoding.
 
@@ -547,7 +547,7 @@ Finally, a critical issue on the decoding side was \textbf{DecodeTagError}, rais
 \begin{quote}
     \texttt{euiccSignature1: Expected OCTET STRING (tag '5f37'), but got '2474'. (At offset: 271)}
 \end{quote}
-
+\marginpar{ASN.1 decoder failed to interpret malformed tags or structure in EUICC response.}
 Such decoding failures indicate inconsistencies between the expected \gls{ber}-encoded tags and the actual mutated values, likely due to truncated structures or corrupted length fields. Notably, in some cases, the \gls{euicc} still accepted and responded to these malformed \gls{apdu}s, albeit with corrupted payloads.
 
 To aid in the analysis and comparison, Table~\ref{tab:error_overview} summarizes these errors alongside example original and mutated payloads.
@@ -693,23 +693,21 @@ To aid in the analysis and comparison, Table~\ref{tab:error_overview} summarizes
 To further understand the behavior of different \glspl{euicc} under mutation-based fuzzing, we post-processed all recorded \gls{apdu} traces.
 
 \subsubsection*{Mutation Examples}
-Successful mutations were observed on \texttt{eSIM.me}, \texttt{5ber}, \texttt{Xesim}
+Successful mutations were observed on \texttt{eSIM.me}, \texttt{5ber}, \texttt{Xesim}, \texttt{9esim}, and \texttt{9esim v2}.
 
-\paragraph{GET\_EUICC\_INFO\_1 Truncation}
+\paragraph{GET\_EUICC\_INFO\_1 Truncation.}
 A truncated \gls{apdu} with trailing padding bytes removed (e.g., \texttt{BF2000} $\rightarrow$ \texttt{BF20}) was still accepted and processed successfully by several \glspl{euicc}. This indicates that, for some non-critical operations, strict \gls{ber}/\gls{der} tag integrity is not enforced.
 
-\paragraph{FIRSTSEQUENCEOF87 Bitflip}
+\paragraph{FIRSTSEQUENCEOF87 Bitflip.}
 A single-bit mutation changed a byte from \texttt{0xA0} to \texttt{0xA1}. Despite the low-level alteration, the \gls{apdu} was accepted, suggesting a fallback to an alternate logical channel or slightly different interpretation of \gls{tlv} structure.
 
-\paragraph{AUTHENTICATE\_SERVER Truncation}
-In one case, the mutation engine truncated approximately 75\% of the \texttt{AuthenticateServer\-Request} \gls{apdu}, removing critical fields such as \texttt{ctxParams1}, the digital signature, and certificate extensions (including \texttt{2.5.29.14}, \texttt{2.5.29.17}, \texttt{2.5.29.35}). The \gls{apdu} failed \gls{asn1} decoding due to inconsistent length indicators. However, after manual correction, analysis revealed that the missing fields did not prevent the \gls{euicc} from accepting the request under specific conditions.
-
-\todo{Try to find some more fuzzing statistics i.e runs, mutations per second, explored paths}
+\paragraph{AUTHENTICATE\_SERVER Truncation.}
+In one case, the mutation engine truncated approximately 75\% of the \texttt{AuthenticateServer\-Request} \gls{apdu},\marginpar{AuthenticateServer truncation removed critical fields but was accepted under certain conditions.} removing critical fields such as \texttt{ctxParams1}, the digital signature, and certificate extensions (including \texttt{2.5.29.14}, \texttt{2.5.29.17}, \texttt{2.5.29.35}). The \gls{apdu} failed \gls{asn1} decoding due to inconsistent length indicators. However, after manual correction, analysis revealed that the missing fields did not prevent the \gls{euicc} from accepting the request under specific conditions.
 
 \subsection{Certificate Validation Bypass}
 \label{subsec:certificate_bypass}
 
-According to SGP.22~\cite{gsma_sgp22_2025}, secure channel establishment between the \gls{lpa} and the \gls{euicc} mandates server authentication. The client, the \gls{euicc}, must validate the server’s X.509 certificate chain, ensuring that it is rooted in the \gls{gsma} Root \gls{ca}. Furthermore, the digital signature of the \texttt{AuthenticateServerRequest} must be verified before continuing with profile download and installation:
+According to SGP.22~\cite{gsma_sgp22_2025}, secure channel establishment between the \gls{lpa} and the \gls{euicc} mandates server authentication. The client, the \gls{euicc}, must validate the server’s X.509 certificate chain, ensuring that it is rooted in the \gls{gsma} Root \gls{ca}.\marginpar{SGP.22 specification require successful Certificate chain verification.} Furthermore, the digital signature of the \texttt{AuthenticateServerRequest} must be verified before continuing with profile download and installation:
 
 \begin{quote}
 ``The Server (the entity providing the function, e.g., \gls{smdpp}) SHALL be authenticated first by the Client (the entity requesting the function). Authentication SHALL include the verification of a Server Certificate chain ending at an \gls{esim} \gls{ca} RootCA Certificate (section 4.5.2).''~\cite{gsma_sgp22_2025}
@@ -727,6 +725,7 @@ To assess real-world conformance with these expectations, the following research
 \label{sec:rq1-truncation}
 
 To determine whether certificate validation is properly enforced, a sequence of mutated \texttt{AuthenticateServerRequest} messages was issued. A first request $AS_1$ was crafted with a malformed certificate $Cert_{Sa}^{(1)}$, where a single bit was flipped in the \gls{asn1} tag field of the certificate’s `SEQUENCE`, changing \texttt{BF38} to \texttt{BE38}. This triggered a potential decoding failure on the \gls{euicc} to reject the request, as expected.
+\marginpar{Truncated certificate without signature is improperly accepted by the eUICC.}
 
 Subsequently, a second request $AS_2$ was sent containing a structurally correct, but truncated version of $Cert_{Sa}^{(2)}$, lacking the digital signature and extensions required for complete X.509 validation. Despite these omissions, the \gls{euicc} accepted the request and proceeded to complete the profile installation. From the perspective of the \gls{lpa}, \gls{asn1} parsing failed, yet the \gls{euicc} made a trust decision as if the certificate were valid.
 
@@ -736,7 +735,7 @@ This demonstrates a critical breakdown in the certificate validation process, in
 \label{sec:rq2-caching}
 
 To explore whether the \gls{euicc} caches data across authentication attempts, additional mutation experiments were performed. After a failed $AS_1$ with a corrupted certificate, a valid truncated certificate was accepted in $AS_2$, provided that both requests originated from the same \gls{smdpp}.
-
+\marginpar{Cross-server attack fails, showing state is scoped to SM-DP+ identity.}
 We performed a set of differential tests across two configurations:
 \begin{itemize}
     \item \textbf{Same-server scenario:} Using two activation codes issued by the same provider (e.g., \texttt{QR-G-5C-1LS-1W1Z9P7} and \texttt{QRF-SPEEDTEST}), the attack succeeded. 
@@ -764,7 +763,7 @@ Analysis of the \gls{apdu} payloads in failed $AS_1$ requests revealed consisten
         \item \texttt{serverCertificate.serialNumber}
         \item \texttt{serverSigned1.serverChallenge}
         \item \texttt{serverSignature1}
-    \end{itemize}
+    \end{itemize}\marginpar{Cross-server mutations fail even under identical truncation conditions.}
     \item In cross-server experiments, mutations in \texttt{server\-Challenge}, \texttt{server\-Signature1}, and other cryptographic fields caused the attack to fail, even when truncation was applied identically.
 \end{itemize}
 
@@ -774,7 +773,7 @@ These observations suggest that state retention is selective and scoped to prior
 \label{sec:rq3-signature}
 
 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.
-
+\marginpar{Signature check is bypassed by reusing cached state.}
 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.
 
 \subsection{Implications}
@@ -785,16 +784,16 @@ The observed behavior constitutes a severe violation of the security architectur
 \begin{enumerate}
     \item \textbf{Bypassed Certificate Validation:} The \gls{euicc} accepts truncated certificates lacking critical fields, including the digital signature and X.509 extensions.
     \item \textbf{Persistent State Caching:} Cryptographic or trust-related state is cached across sessions and power cycles, even in response to malformed input.
-    \item \textbf{Skipped Signature Verification:} The \gls{euicc} does not re-verify signatures if a previously failed request cached valid key material.
+    \item \textbf{Skipped Signature Verification:} The \gls{euicc} does not re-verify signatures if a previously failed request cached valid key material.\marginpar{eUICCs cache trust state and accept truncated certificates, enabling scoped signature verification bypasses.}
     \item \textbf{Server-Scoped Trust Decisions:} State reuse is scoped to the \gls{smdpp} identity, allowing targeted trust bypasses under controlled conditions.
 \end{enumerate}
 
 Together, these issues expose an attack surface where adversaries can craft a sequence of malformed requests to poison the internal state of the \gls{euicc}. Once in this compromised state, the \gls{euicc} may proceed with mutual authentication and secure channel establishment, even in the absence of a complete or verifiable certificate chain. This behavior violates the security expectations in Sections 4.5.1 and 4.5.2 of the SGP.22 specification~\cite{gsma_sgp22_2025}, which require end-entity certificate validation and strict signature verification for all authentication steps.
-
+\marginpar{Only Eastcompeace devices were affected; other vendors behaved correctly.}
 The certificate bypass was only observed on \glspl{euicc} manufactured by \textbf{Eastcompeace}. Devices from other vendors did not exhibit this behavior under the same test conditions, suggesting an implementation-specific vulnerability in Eastcompeace firmware or certificate handling logic.
 
 
-\subsection{Limitations and Future Work}
+\subsection{Limitations}
 \label{sec:limitations}
 
 While the truncation-based bypass demonstrates a significant weakness in the certificate validation logic, it is not yet clear whether this vulnerability enables complete provisioning from an attacker-controlled \gls{smdpp}. The current attacks rely on prior interaction with a legitimate \gls{smdpp} that successfully injects a partially valid certificate into the \gls{euicc}'s internal state.
@@ -804,18 +803,9 @@ An open research question remains:
 \begin{quote}
 \textit{Can an attacker-controlled \gls{smdpp} successfully provision a profile on a vulnerable \gls{euicc} by leveraging this truncation-based bypass, without ever presenting a valid certificate chain anchored in the \gls{gsma} Root \gls{ca}?}
 \end{quote}
-
+\marginpar{Unclear if provisioning can occur entirely from attacker-controlled SM-DP+ infrastructure.}
 In other words, can the bypass be generalized to completely circumvent the certificate trust model, enabling profile installation from an untrusted or rogue infrastructure? If confirmed, this would constitute a full break of the \gls{gsma} trust model and pose significant implications for mobile network operators and \gls{esim} vendors.
 
-Future work will involve:
-
-\begin{itemize}
-    \item Isolating which fields from $AS_1$ are retained in the cache and reused during $AS_2$ (e.g., public key, issuer name, signature fields, etc.).
-    \item Reproducing the attack with a fully synthetic and attacker-controlled certificate chain.
-    \item Verifying whether the attack can be conducted using arbitrary \gls{smdpp} endpoints and activation codes.
-    \item Investigating whether other stateful fields (e.g., \texttt{serverSigned1}, \texttt{serverChallenge}) are also reused or must be aligned.
-\end{itemize}
-
 
 % \paragraph{Expected Behavior.}
 % SGP.22 describes the expected server-client authentication behaviour as follows: