Update on Overleaf.

AdditionalPackages.tex

@@ -44,10 +44,11 @@
 }
 
 
-% TikZ/PGFPlots
+% TikZ/PGFPlots/Diagrams
 \usepackage{tikz}
 \usepackage{pgfplots}
 \pgfplotsset{compat=newest}
+\usepackage{pgf-umlsd}
 \usetikzlibrary{
   chains,
   positioning,

Chapters/Background.tex

@@ -34,7 +34,8 @@ The \gls{etsi} defines the \gls{sim} card as a smart card platform. This include
 
 The \gls{3gpp} focuses on how \gls{sim} cards integrate with mobile networks. This includes the specification of \gls{sim} functionalities required for network access in technologies such as LTE, 5G, and legacy systems. These standards ensure interoperability between \glspl{sim} and network infrastructure across vendors and operators.
 
-The \gls{gsma} defines the higher-level functional architecture necessary to operationalize \gls{esim} technology in real-world deployments. This includes specifications such as the \gls{rsp} system, the \gls{lpa}, and the \gls{smdpp}, which together enable the remote provisioning, management, and activation of \gls{esim} profiles. The \glsposs{gsma} SGP.22 specification is a cornerstone in this area, detailing the technical realization of the consumer remote \gls{sim} provisioning system~\cite{gsma_sgp22_2025}.
+The \gls{gsma} defines the higher-level functional architecture necessary to operationalize \gls{esim} technology in real-world deployments. This includes specifications such as the \gls{rsp} system as described in \cref{sec:rsp}, and the \gls{lpa} aswell as the \gls{smdpp} in \cref{par:euicc_components}, which together enable the remote provisioning, management, and activation of \gls{esim} profiles.
+The \glsposs{gsma} SGP.22 specification is a cornerstone in this area, detailing the technical realization of the consumer remote \gls{sim} provisioning system~\cite{gsma_sgp22_2025}.
 
 % 4 main specifications
 % machine-2-machine standard (SGP.01, SGP.02): industry focused -> mainly used in the automotive industry to enable eCall functionality
@@ -248,7 +249,7 @@ The concept of the \gls{esim} is based on the \gls{euicc}, which replaces the tr
 
 Historically, the subscriber identity and related credentials were bound to a physical \gls{uicc} during the manufacturing process. This physical coupling meant that changing network operators or updating credentials required the replacement of the \gls{sim} card itself. The \gls{esim} paradigm disrupts this model by decoupling the subscription identity from the physical card. Instead, subscriber credentials, including applications such as \gls{usim}, \gls{isim}, and their associated file systems, are now encapsulated within a virtual entity referred to as an \textit{eSIM profile}.
 
-These profiles reside on the underlying \gls{euicc} hardware and can be provisioned, activated, and managed remotely. Profile management is facilitated through standardized components defined by the \gls{gsma}—most notably the \gls{smdpp} and \gls{smds} servers. Profiles can either be delivered in a passive manner through the \gls{smdpp} when triggered by the end user, often via the \gls{lpa}, or actively pushed to the device through the \gls{smds}.
+These profiles reside on the underlying \gls{euicc} hardware and can be provisioned, activated, and managed remotely. Profile management is facilitated through standardized components defined by the \gls{gsma}, most notably the \gls{smdpp} and \gls{smds} servers. Profiles can either be delivered in a passive manner through the \gls{smdpp} when triggered by the end user, often via the \gls{lpa}, or actively pushed to the device through the \gls{smds}.
 
 This architecture introduces a remote provisioning mechanism and significantly enhances user flexibility, while simultaneously introducing new complexity in terms of protocol design and implementation correctness.
 
@@ -306,6 +307,7 @@ In many modern devices, the most common integration of an \gls{esim} is as a sol
 
 
 \paragraph{Local Profile Assistant}
+\label{par:lpa}
 
 \begin{figure}[h!]
     \centering
@@ -331,7 +333,7 @@ Interface when LPA is in the Device (LUId), are collectively simplified and refe
 \paragraph{Application Toolkit}
 
 The \gls{stk}/\gls{usat}, which are collectively referred to as the \gls{cat} in \gls{etsi} TS 102 223~\cite{etsi_ts_2014}, provides a proactive command framework for on-card applications. \gls{cat} functionalities are typically made available to end-users through standardized applications, known as SIM Toolkit apps that preinstalled on many mobile devices. These applications expose a menu-driven interface as shown in \cref{img:cat_interface}, that allows direct interaction with the \gls{esim} functionality embedded in the card, without requiring any additional software or manufacturer-specific \glspl{lpa}. However, the amount of functionality provided over such interfaces still depends on the manufacturer and the implementation.
-The original \gls{stk}, introduced in \gls{etsi} 11.14~\cite{etsi_gsm_1997}, targets GSM \glspl{sim}, while the \gls{usat}, defined in \gls{etsi} TS 131 111~\cite{etsi_ts_2020}, extends these capabilities for \gls{uicc}/\gls{usim} environments. \gls{cat} unifies \gls{stk} and \gls{usat} under a single umbrella for all \gls{uicc}-based toolkits. These toolkits enable on-card applets to interact with the user equipment—displaying menus, sending SMS, downloading data, or even initiating \gls{esim} profile operations such as renaming or activation. Projects like \texttt{estk.me} have further enhanced this interface with “cloud-enhanced” \gls{rlpa}, which allows users to initiate profile provisioning directly via \gls{cat} menus without a separate \gls{lpa} client~\cite{estkme_rlpa-server_2025}. Other provisioning methods typically require a dedicated \gls{lpa} application on the device.
+The original \gls{stk}, introduced in \gls{etsi} 11.14~\cite{etsi_gsm_1997}, targets GSM \glspl{sim}, while the \gls{usat}, defined in \gls{etsi} TS 131 111~\cite{etsi_ts_2020}, extends these capabilities for \gls{uicc}/\gls{usim} environments. \gls{cat} unifies \gls{stk} and \gls{usat} under a single umbrella for all \gls{uicc}-based toolkits. These toolkits enable on-card applets to interact with the user equipment, displaying menus, sending SMS, downloading data, or even initiating \gls{esim} profile operations such as renaming or activation. Projects like \texttt{estk.me} have further enhanced this interface with “cloud-enhanced” \gls{rlpa}, which allows users to initiate profile provisioning directly via \gls{cat} menus without a separate \gls{lpa} client~\cite{estkme_rlpa-server_2025}. Other provisioning methods typically require a dedicated \gls{lpa} application on the device and cannot be facilitated through the \gls{cat} interface.
 
 \begin{figure}[h!]
     \centering
@@ -401,9 +403,40 @@ In this work, we focus on the Authentication Code method due to its prevalence i
 
 \textcite{ahmed_security_2024} packages the \gls{rsp} into four major steps: mutual authentication, profile binding, profile download (including authenticated key exchange), and notification.
 
+\begin{figure}[h!]
+	\centering
+    \includesvg[width=1.3\textwidth]{Graphics/mutual_authentication_sd.svg}
+    \caption{Sequence diagram of the mutual authentication.\cite{ahmed_security_2024}}
+    \label{fig:mutual_authentication}
+\end{figure}
+
+\begin{table}[h!]
+    \centering
+    \caption{Notation for mutual authentication sequence diagram.\cite{ahmed_security_2024}}
+    \label{tab:notiation}
+    \begin{tabular}{l p{6.5cm} l}
+        \toprule
+        \textbf{Symbol} & \textbf{Description} & \textbf{GSMA} \\
+        \midrule
+        $U$                & \gls{euicc} identifier & EID \\
+        $S$                & Server domain name \\
+        \text{userId}      & User identity authenticated by \gls{mno} & \\
+        $\text{iccid}$     & Unique identifier of the SIM profile & ICCID \\
+        $I_{ac}$           & Matching identifier in activation code & \\
+        $\mathrm{SKI}_{CI}$ & SubjectKeyIdentifier of $\mathrm{Cert}_{CI}$ & \\
+        $N_U := R,\ N_S := R$ & Random numbers generated by \gls{euicc} and server & \\
+        $I_t := R$         & Random session identifier generated by server & \\
+        $\mathrm{Sign}(M;\ SK)$ & Signature of message $M$ with private key $SK$ & \\
+        \text{serverOID}& Server OID in $\mathrm{Cert}_{Sa}$ and $\mathrm{Cert}_{Sp}$ & \\
+        \text{subject of Cert} & Subject identifier to which certificate was issued & \\
+        $\mathrm{Cert}_a \triangleleft \mathrm{Cert}_b$ & Certificates, check that $\mathrm{Cert}_a$ is signed by the subject key of $\mathrm{Cert}_b$ & \\
+        \bottomrule
+    \end{tabular}
+\end{table}
+
 \paragraph{Mutual Authentication}
 
-The \gls{rsp} process begins with mutual authentication between the \gls{euicc} and \gls{smdpp} over a \gls{tls} tunnel established via the \gls{lpa}. The \gls{euicc} generates a random challenge and sends it, along with its \gls{ci} Root public key certificate, to the \gls{smdpp}. The \gls{smdpp} responds with a signed version of the challenge, its own certificate subject, a transaction identifier, and a server challenge. The \gls{euicc} verifies the signature and certificate chain, signs the activation code’s profile identifier (and other protocol elements), the transaction identifier, the server challenge, and relevant addresses, then returns this to the \gls{smdpp}. Based on the profile identifier, the \gls{smdpp} selects the appropriate profile for download.
+As \cref{fig:mutual_authentication} shows, the \gls{rsp} process begins with mutual authentication between the \gls{euicc} and \gls{smdpp} over a \gls{tls} tunnel established via the \gls{lpa}. The \gls{euicc} generates a random challenge $N_U$ and sends it, along with its \gls{ci} Root public key certificate $SKI_{CI}$, to the \gls{smdpp}. The \gls{smdpp} responds with a signed version of the challenge $N_U$, its own certificate subject $S$, a transaction identifier $I_t$, and a server challenge $N_S$. The \gls{euicc} verifies the signature and certificate chain, signs the activation code’s profile identifier $I_{ac}$ (and other protocol elements), the transaction identifier $I_t$, the server challenge $N_S$, and relevant addresses, then returns this to the \gls{smdpp}. Based on the profile identifier, the \gls{smdpp} selects the appropriate profile for download.
 
 \paragraph{Profile Binding}
 

Chapters/Discussion.tex

@@ -62,11 +62,11 @@
 
 The primary goal of this thesis was to assess the security posture and behavioral consistency of commercial eSIM-on-SIM products through differential testing. To this end, we developed a custom black-box testing framework capable of performing APDU-level fuzzing, structured \gls{asn1} mutation, and trace-based cross-device comparisons. Our evaluation was conducted on eight commercially available eSIM-on-SIM cards from three distinct vendors, revealing a diverse and fragmented implementation landscape.
 
-Our findings indicate substantial architectural differences across implementations. For instance, some cards, such as the one from estk.me, omit the standard \gls{isdr} application altogether and instead expose functionality solely via the \gls{usat} interface. This approach also offers a privately hosted \gls{rlpa} server for provisioning \cite{estkme_rlpa-server_2025}, circumventing the \acposs{gsma} standardized infrastructure and raising questions regarding compliance and security. In contrast, other implementations (e.g., 5ber, Xesim, eSIM.me) do include \gls{isdr} support, but use vendor-specific \glspl{aid}, deviating from the default identifiers specified in SGP.22. These differences complicate interoperability and testing, while also highlighting the absence of a uniform baseline across implementations.
+Our findings indicate substantial architectural differences across implementations. For instance, some cards, such as the one from estk.me, omit the standard \gls{isdr} application altogether and instead expose functionality solely via the \gls{usat} interface. This approach also offers a privately hosted \gls{rlpa} server for provisioning \cite{estkme_rlpa-server_2025}, circumventing the \glsposs{gsma} standardized infrastructure and raising questions regarding compliance and security. In contrast, other implementations (e.g., 5ber, Xesim, eSIM.me) do include \gls{isdr} support, but use vendor-specific \glspl{aid}, deviating from the default identifiers specified in SGP.22. These differences complicate interoperability and testing, while also highlighting the absence of a uniform baseline across implementations.
 
 A key contribution of our work is the observation of divergent behaviors in response to identical \gls{rsp} inputs. Mutated \gls{asn1} payloads triggered undefined behavior in several cards, including silent failures, unexpected success responses, and inconsistent status words. In multiple instances, we observed malformed requests that bypassed expected validation routines, particularly during the certificate authentication phase. One notable case revealed a likely certificate validation bypass, where corrupted `AuthenticateServerRequest` messages were accepted despite invalid or tampered certificates. This suggests that parts of the certificate verification pipeline were either improperly implemented or incorrectly reused from prior sessions without sufficient integrity checks.
 
-The implications of such inconsistencies are significant. Bypassing certificate validation undermines the trust model of the \gls{gsma} \gls{rsp} architecture, as the certificate chain rooted in the \gls{gsma} \gls{ca} can no longer be reliably enforced. An attacker able to craft malicious authentication messages, potentially by compromising or emulating an \gls{lpa}, could install rogue profiles onto the \gls{euicc}. While a valid \gls{gsma}-signed profile is still required, this opens the door for profile injection attacks, man-in-the-middle (MITM) provisioning manipulation, and potentially persistent compromise of the device. Previous research, such as that by \textref{lisowski_simurai_2024}, has demonstrated the feasibility of malicious \gls{sim} cards. However, their work focused on runtime behavior and not on provisioning vulnerabilities. Our findings extend this threat model by targeting the provisioning pipeline itself.
+The implications of such inconsistencies are significant. Bypassing certificate validation undermines the trust model of the \gls{gsma} \gls{rsp} architecture, as the certificate chain rooted in the \gls{gsma} \gls{ca} can no longer be reliably enforced. An attacker able to craft malicious authentication messages, potentially by compromising or emulating an \gls{lpa}, could install rogue profiles onto the \gls{euicc}. While a valid \gls{gsma}-signed profile is still required, this opens the door for profile injection attacks, man-in-the-middle (MITM) provisioning manipulation, and potentially persistent compromise of the device. Previous research, such as that by \textcite{lisowski_simurai_2024}, has demonstrated the feasibility of malicious \gls{sim} cards. However, their work focused on runtime behavior and not on provisioning vulnerabilities. Our findings extend this threat model by targeting the provisioning pipeline itself.
 
 Several cards also revealed additional security concerns. One exposed undocumented endpoints for firmware updates that fall outside the \gls{gp} command set, suggesting the existence of non-standard, vendor-specific mechanisms for critical operations. The presence of undefined error states, typically in the form of generic status words (\eg, \texttt{6F00}) or generic Errors (\eg, \texttt{UndefinedError}), indicates insufficient internal error handling. In some cases, malformed inputs resulted in successful operations, pointing to either faulty \gls{asn1} decoding or logical flaws in the parsing routines.
 
@@ -80,6 +80,6 @@ To mitigate the certificate reuse issue observed, we recommend stricter cryptogr
 
 \paragraph{Future Work}
 
-Several directions for future research emerge from this work. First, the \gls{lpa} implementation could be extended to support SGP.31 and SGP.41 specific functionality, enabling testing of \gls{iot}-specific provisioning flows and factory provisioning procedures. Second, to achieve full-loop fuzzing, future versions of the framework could integrate a self-hosted \gls{smdpp} server equipped with test certificates and profiles. This would allow end-to-end testing of the complete \gls{rsp} lifecycle. Finally, improvements to the fuzzing engine, such as incorporating a hypothesis rule based state machine, which would directly compare the fuzzing behaviour of a custom \gls{smdpp} server and \gls{euicc} implementation against propriatary ones.
+Several directions for future research emerge from this work. First, the \gls{lpa} implementation could be extended to support SGP.31/SGP.32 and SGP.41/SGP.42 specific functionality, enabling testing of \gls{iot}-specific provisioning flows and factory provisioning procedures. Second, to achieve full-loop fuzzing, future versions of the framework could integrate a self-hosted \gls{smdpp} server equipped with test certificates and profiles. This would allow end-to-end testing of the complete \gls{rsp} lifecycle. Finally, improvements to the fuzzing engine, such as incorporating a hypothesis rule based state machine, which would directly compare the fuzzing behaviour of a custom \gls{smdpp} server and \gls{euicc} implementation against propriatary ones.
 
 

Chapters/Evaluation.tex

@@ -611,7 +611,7 @@ According to SGP.22:
 \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}
 \end{quote}
-The server certificate \texttt{CERT.DPauth.ECDSA} must be verified against the \gls{gsma} root-of-trust, and the digital signature of the \texttt{AuthenticateServerRequest} must be valid.
+The server certificate $Cert_{Sa}$ must be verified against the \gls{gsma} root-of-trust $Cert_{CI}$, and the digital signature of the \texttt{AuthenticateServerRequest} must be valid.
 
 \subsubsection*{Observed Behavior}
 By combining a series of failed and mutated authentication requests, it was possible to trigger incorrect trust decisions by the \gls{euicc}:
@@ -619,14 +619,21 @@ By combining a series of failed and mutated authentication requests, it was poss
 \begin{enumerate}
     \item A first \texttt{AuthenticateServerRequest} containing a malformed or mutated certificate (e.g., bit-flipped data) is sent to the \gls{euicc}. As expected, this request fails.
     
-    \item A second \texttt{AuthenticateServerRequest} is sent, using a valid profile but with the certificate truncated (i.e., digital signature and extensions removed). Surprisingly, the \gls{euicc} accepts this message and continues with the profile installation process.
+    \item A second \texttt{AuthenticateServerRequest} is sent, using a valid profile but with the certificate $Cert_{Sa}$ truncated (i.e., digital signature and extensions removed). Surprisingly, the \gls{euicc} accepts this message and continues with the profile installation process.
 
-    \item \gls{asn1} decoding of the truncated certificate on the \gls{lpa} side fails due to missing signature fields, but the \gls{euicc} does not reject it, indicating that signature verification was skipped.
+    \item \gls{asn1} decoding of the truncated certificate $Cert_{Sa}$ on the \gls{lpa} side fails due to missing signature fields, but the \gls{euicc} does not reject it, indicating that signature verification was skipped.
 
-    \item Swapping the \texttt{SubjectPublicKeyInfo} in the truncated certificate with an attacker-controlled public key still results in successful mutual authentication and secure channel establishment. This would imply that the \gls{euicc} did not use the attacker controlled public key, but instead reused the previously sent publlic key from the failed request, as otherwise the \gls{smdpp} would have not been able to verify the signature in the subsequent client authentication.
+    \item Swapping the \texttt{SubjectPublicKeyInfo} in the truncated certificate $Cert_{Sa}$ with an attacker-controlled public key $SK_A$ still results in successful mutual authentication and secure channel establishment. This would imply that the \gls{euicc} did not use the attacker controlled public key, but instead reused the previously sent publlic key from the failed request, as otherwise the \gls{smdpp} would have not been able to verify the signature in the subsequent client authentication $\mathrm{Cert}_{Sa} \triangleleft \mathrm{Cert}_{CI}$ as shown in \cref{fig:authenticate_server_sd}.
 \end{enumerate}
 
-A deeper analysis of mutated APDU payloads of the initial \texttt{AuthenticateServerRequest}, particularly in cases using different \gls{smdpp} servers, shows the following:
+\begin{figure}[h!]
+	\centering
+    \includesvg[width=\textwidth]{Graphics/authenticate_server_sd.svg}
+    \caption{Sequence diagram of the authenticate server process.\cite{ahmed_security_2024}}
+    \label{fig:authenticate_server_sd}
+\end{figure}
+
+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.
@@ -636,7 +643,7 @@ A deeper analysis of mutated APDU payloads of the initial \texttt{AuthenticateSe
     \item In same-server scenarios (same \gls{smdpp}), a similar flip in the tag is observed. Upon correction, mutations manifest in \texttt{euiccCiPKIdToBeUsed}, \texttt{serverCertificate.issuer}, \texttt{serverCertificate.serialNumber}, \texttt{serverSignature1}, and again in \texttt{serverSigned1.serverChallenge}. This scenario will be able to pass the truncation bug an successfully install the profile.
 \end{itemize}
 
-These observations further validate the theory that the certificate from the initial failed \texttt{AuthenticateServerRequest} is cached and reused by the \gls{euicc}. In both the same-server and cross-server mutation scenarios, the public key remains unmodified, yet the behavior diverges based on the prior session’s state. Additionally, certificate validation appears to be bypassed entirely, as the mutated certificate contents never represent a structurally valid or correctly signed certificate at any point in the provisioning flow.
+These observations further validate the theory that the certificate from the initial failed \texttt{AuthenticateServerRequest} is cached and reused by the \gls{euicc}. In both the same-server and cross-server mutation scenarios, the public key remains unmodified, yet the behavior diverges based on the prior session’s state. Additionally, certificate validation $\mathrm{Cert}_{Sa} \triangleleft \mathrm{Cert}_{CI}$ appears to be bypassed entirely, as the mutated certificate $Cert_{Sa}$ contents never represent a structurally valid or correctly signed certificate at any point in the provisioning flow.
 
 \subsubsection*{State Persistence Across Sessions}
 Further experiments showed that this vulnerability persists across sessions and even power cycles:

Chapters/Implementation.tex

@@ -93,7 +93,7 @@ In the following sections, the technical details of each implementation componen
 % - recording: represents a list of recorded \glspl{apdu}, handles source and target isd-r addresses, file saving and loding as well as checking if the file is replayable
 % - replay: establishes connection to pcsc via pcsc link, loads recorded \glspl{apdu} and sends them over the link to the connected euicc, switches out source isd-r and target isd-r during replay, compares response status word to recorded status word on prints an error if there is a difference
 
-We built the tracing component to capture, interpret, and replay \glspl{apdu} communication between an \gls{lpa} (or other source) and the \gls{euicc}. This forms the foundation of the differential testing framework by allowing the same interaction sequence to be executed across multiple \glspl{euicc} for behavioral comparison.
+We built the tracing component to capture and interpret \glspl{apdu} exchanged between an \gls{lpa} (or other source) and the \gls{euicc}, and to replay them by inserting the recorded \glspl{apdu} into the communication between the \gls{lpa} and the \gls{euicc}. This forms the foundation of the differential testing framework by allowing the same interaction sequence to be executed across multiple \glspl{euicc} for behavioral comparison.
 
 The tracing functionality comprises two main operations:
 
@@ -367,6 +367,13 @@ Figure \cref{fig:scenario_flow} illustrates the \gls{apdu} fuzzing workflow, whi
   \item \textbf{Recording:} We save the response or exception in the corresponding mutation tree node for further analysis.
 \end{enumerate}
 
+\begin{figure}
+	\centering
+    \input{Graphics/record_scenario_flow.tikz}
+    \caption{Flow for recording a scenario.}
+    \label{fig:scenario_flow}
+\end{figure}
+
 We repeat this process for all functions defined in the scenario, producing a complete mutation tree (see \cref{fig:tree_structure}) that captures all inputs, outputs, and error states.
 
 \begin{figure}
@@ -439,13 +446,6 @@ After multiple cards are fuzzed with the same scenario, their corresponding muta
 
 This differential testing method highlights edge-case inconsistencies across \gls{euicc} vendors and enables systematic validation of the \gls{rsp} protocol compliance.
 
-\begin{figure}
-	\centering
-    \input{Graphics/record_scenario_flow.tikz}
-    \caption{Flow for recording a scenario.}
-    \label{fig:scenario_flow}
-\end{figure}
-
 
 \subsection{Data Fuzzing}
 \label{subsec:data_fuzzing}
@@ -516,7 +516,7 @@ This differential testing method highlights edge-case inconsistencies across \gl
 % on the other hand an undefined error is still handled be the euicc but could not be properly handled -> could mean that there is a potential bug in the implementation and we need to do some further investigation into to this particular function call
 % -> euicc exceptions are ignored unless they are an UndefinedError
 
-While APDU-level fuzzing (see \cref{subsec:apdu_fuzzing}) is useful for evaluating command behavior across different \textit{euicc} implementations, it suffers from the drawback that random mutations—particularly at the bit or byte level—often invalidate the structured ASN.1 encoding. As a result, many \gls{apdu} mutations are immediately rejected as malformed, limiting the coverage and effectiveness of the test campaign.
+While APDU-level fuzzing (see \cref{subsec:apdu_fuzzing}) is useful for evaluating command behavior across different \textit{euicc} implementations, it suffers from the drawback that random mutations—particularly at the bit or byte level—often invalidate the structured \gls{asn1} encoding. As a result, many \gls{apdu} mutations are immediately rejected as malformed, limiting the coverage and effectiveness of the test campaign.
 
 To address this limitation, we introduce a complementary \textit{data fuzzing} approach that operates at the semantic level by fuzzing the input arguments of high-level \gls{lpa} function calls. This enables us to maintain structural validity while still exercising a wide variety of edge cases in the data provided to the \gls{euicc}. Our implementation builds on property-based testing frameworks designed for Python, in particular the \texttt{hypothesis} library~\cite{maciver_hypothesis_2019}.
 
@@ -562,7 +562,8 @@ def test_get_profiles(self, use_iccid, profile_class, tags):
 This approach preserves the semantics and structure of the expected \gls{asn1} types while still allowing a wide variety of edge cases to be exercised.
 
 \paragraph{Implementation Scope}
-Due to reliance on external infrastructure, such as the \gls{smdpp} server, our fuzzing campaign focuses exclusively on the \gls{euicc}-side of the \gls{rsp} protocol. Fuzzing requests directed at the \gls{smdpp} would lead to excessive traffic and could be misinterpreted as \gls{dos} attempts. Therefore, our tests are restricted to those functions in the ES10a, ES10b, and ES10c SGP.22 interfaces which accept structured input arguments and interact directly with the \gls{euicc}.
+Due to reliance on external infrastructure, such as the \gls{smdpp} server, our fuzzing campaign focuses exclusively on the \gls{euicc}-side of the \gls{rsp} protocol. Fuzzing requests directed at the \gls{smdpp} would lead to excessive traffic and could be misinterpreted as \gls{dos} attempts. Therefore, we restrict our tests to those functions defined in the ES10a, ES10b, and ES10c interfaces of the SGP.22 specification, which form the communication layer between the \gls{lpa} and the \gls{euicc}, specifically focusing on functions that accept structured input arguments and directly interact with the \gls{euicc}.
+
 
 Specifically, we implemented fuzzing tests for the following functions:
 \begin{itemize}

Graphics/determine_next_mutation_flow.tikz

@@ -26,7 +26,7 @@
 \path[line] (n2) -- node[left] {Yes} (D);
 \path[line] (n2) -- node[above] {No} (n3);
 \path[line] (n3) -- node[right] {Yes} (n4);
-\path[line] (n3) -- (n5);
+\path[line] (n3) -- node[right] {No}(n5);
 \path[line] (n5) -- node[above] {Yes} (n6);
 
 \end{tikzpicture}