Update on Overleaf.

Chapters/Background.tex

@@ -178,7 +178,7 @@ The status word (SW) in an R-APDU signifies whether a command was successfully p
 % - it uses a TLV for the encoding of all its information -> tag indicates what kind of data follows, then length to tell the parser how much that to read for this tag, and then the actual data (provide example for BER-TLV ASN1 encoding of some short RSP message)
 % - the GSMA provides ASN.1 definitions for all of its standardized functions
 
-When interacting with a \gls{uicc}, either to request or to store data, the command payload is typically structured using \gls{asn1} encoded in the \gls{ber}-\gls{tlv} format. \gls{asn1} is a formal language used to define data structures in a way that is independent of machine-specific encoding. It is a mature and widely adopted technology, particularly within the field of telecommunications, and is standardized by the ITU-T~\cite{oss_nokalva_asn1_nodate}. Eventhough its an established encoding standard, it is still prone to be the source of bugs and security vulnerabilities.\cite{nist_nvd_2024, nist_nvd_2025, mitre_cve_2003}
+When interacting with a \gls{uicc}, either to request or to store data, the command payload is typically structured using \gls{asn1} encoding in the \gls{ber}-\gls{tlv} format. \gls{asn1} is a formal language used to define data structures in a way that is independent of machine-specific encoding. It is a mature and widely adopted technology, particularly within the field of telecommunications, and is standardized by the ITU-T~\cite{oss_nokalva_asn1_nodate}. Eventhough its an established encoding standard, it is still prone to be the source of bugs and security vulnerabilities.\cite{nist_nvd_2024, nist_nvd_2025, mitre_cve_2003}
 
 \gls{asn1} supports a variety of encoding rules. One of the most commonly used in the context of smart cards and mobile communications is the \gls{ber}. In \gls{ber}, all data is encoded as a sequence of \gls{tlv} elements. The \emph{Tag} identifies the type of data, the \emph{Length} specifies the number of bytes used for the value, and the \emph{Value} contains the actual data payload.
 
@@ -273,7 +273,7 @@ This architecture introduces a remote provisioning mechanism and significantly e
 
 To manage, store, and control \gls{esim} profiles, the \gls{euicc} hosts several critical applications and system components. These include the \gls{isdr}, \gls{isdp}, \gls{ecasd}, optionally the embedded \gls{lpa}, \gls{aram}, and various \gls{lpa} service interfaces as shown in \cref{img:euicc_architecture}.
 
-The \gls{ecasd} provides secure storage and cryptographic services. It maintains sensitive credentials such as the \gls{euicc} private key and certificate, the eUICC Identifier (\texttt{EID}), the \gls{euicc} Manufacturer (\gls{eum}) certificate, and the manufacturer key set used for credential updates. It is also responsible for generating digital signatures on data received from the \gls{isdr} and for verifying certificates during the authentication of the \gls{smdpp} or other remote entities.Typically, the stored certificates and cryptographic keys within the \gls{ecasd} are immutable and cannot be updated, and as a result, they are provisioned with a validity period of approximately 25 years \cite{welte_euicc_2024}.
+The \gls{ecasd} provides secure storage and cryptographic services. It maintains sensitive credentials such as the \gls{euicc} private key and certificate, the \gls{eid}, the \gls{eum} certificate, and the manufacturer key set used for credential updates. It is also responsible for generating digital signatures on data received from the \gls{isdr} and for verifying certificates during the authentication of the \gls{smdpp} or other remote entities.Typically, the stored certificates and cryptographic keys within the \gls{ecasd} are immutable and cannot be updated, and as a result, they are provisioned with a validity period of approximately 25 years \cite{welte_euicc_2024}.
 
 The \gls{isdr} acts as the primary control authority on the \gls{euicc}. It manages the creation, activation, deactivation, and deletion of \glspl{isdp}. Only one of either \gls{isdr} or \gls{ecasd} can be present on a single \gls{euicc}, depending on the \gls{euicc}'s implementation mode.
 
@@ -302,7 +302,7 @@ Together, these components establish the trust and management architecture neces
 % - estk.me also implemented rlpa (remote lpa or as they call it cloud enhance) -> allows the user to provision profiles via the stk / usat menu (cite cloud rlpa-server)
 % other options to provision profiles require an lpa client on the ue / terminal
 
-In many modern devices, the most common integration of an \gls{esim} is as a soldered chip on the printed circuit board of a smartphone. Because these embedded chips are functionally identical to traditional removable \gls{sim} cards—apart from the \gls{esim} operating system, which is supplied by the \gls{euicc} manufacturer—they can also be packaged as “physical \glspl{esim}” in standard form-factors (2FF, 3FF, 4FF). This enables even non-eSIM–capable devices to use remotely provisioned profiles without hardware changes. To date, physical \glspl{esim} in these sizes are produced by vendors such as Kigen, Estcompeace, and Giesecke+Devrient.
+In many modern devices, the most common integration of an \gls{esim} is as a soldered chip on the printed circuit board of a smartphone. Because these embedded chips are functionally identical to traditional removable \gls{sim} cards—apart from the \gls{esim} operating system, which is supplied by the \gls{eum} and can also be packaged as “physical \glspl{esim}” in standard form-factors (2FF, 3FF, 4FF). This enables even non-eSIM–capable devices to use remotely provisioned profiles without hardware changes. To date, physical \glspl{esim} in these sizes are produced by vendors such as Kigen, Estcompeace, and Giesecke+Devrient.
 
 
 \paragraph{Local Profile Assistant}
@@ -331,7 +331,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 \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 \gls{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 and cannot be facilitated through the \gls{cat} interface.
 
 \begin{figure}[h!]
@@ -413,22 +413,22 @@ In this work, we focus on the Authentication Code method due to its prevalence i
     \centering
     \caption{Notation for mutual authentication sequence diagram.\cite{ahmed_security_2024}}
     \label{tab:notiation}
-    \begin{tabular}{l p{6.5cm} l}
+    \begin{tabular}{l p{8cm}}
         \toprule
-        \textbf{Symbol} & \textbf{Description} & \textbf{GSMA} \\
+        \textbf{Symbol} & \textbf{Description} \\
         \midrule
-        $U$                & \gls{euicc} identifier & EID \\
+        $U$                & \gls{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$ & \\
+        $\text{iccid}$     & Unique identifier of the \gls{sim} profile \ie \gls{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}

Chapters/Implementation.tex

@@ -559,7 +559,7 @@ 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 for the \gls{rsp} process, 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}.
+Due to reliance on external infrastructure for the \gls{rsp} process, such as the \gls{smdpp} server, our fuzzing campaign focuses exclusively on the \gls{euicc}-side of the \gls{rsp} protocol. Invalid structured 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:

Chapters/Introduction.tex

@@ -53,7 +53,7 @@ As \gls{esim} support becomes standard in newly released phones, it also introdu
 % differential testing: compare multiple implementations against each other -> identify anomalies under identical/similar inputs
 % goal: uncover functional deviations and security issues in a black-box setting
 
-Despite the \gls{esim} architecture being built with security in mind and standardized by the GSMA, ETSI, and 3GPP, implementations are left to individual manufacturers. While the specifications provide a common baseline, the actual firmware and OS implementations remain proprietary and closed-source. This means they are not open to public review and may include undocumented features, backdoors, or custom update mechanisms beyond the published standards.
+Despite the \gls{esim} architecture being built with security in mind and standardized by the \gls{gsma}, \gls{etsi}, and \gls{3gpp}, implementations are left to individual manufacturers. While the specifications provide a common baseline, the actual firmware and OS implementations remain proprietary and closed-source. This means they are not open to public review and may include undocumented features, backdoors, or custom update mechanisms beyond the published standards.
 
 These implementation-specific deviations pose significant security risks. \glspl{esim} operate at a privileged layer of the system architecture, with direct and largely unfiltered access to the device's baseband. Vulnerabilities within this stack can result in persistent malware, surviving reboots or even factory resets, and often remain invisible to users. Bugs in the implementation of profile provisioning, certificate validation, or update mechanisms can therefore have severe and long-lasting consequences.
 
@@ -92,7 +92,7 @@ We use the framework to analyze several commercial eSIM-on-SIM implementations.
 % Chapter 6: discuss the implications of our findings and reflect on potential weaknesses in current esim on sim deployment models
 % in the last chapter: concludes thesis, outlines possible future work, including testing of IoT specific features, and supporting proactive commands
 
-The thesis begins with an overview of \gls{sim} and \gls{esim} technologies in \cref{ch:background}, along with the \gls{rsp} architecture, to establish the necessary technical background. It also introduces the relevant standards developed by the GSMA, ETSI, and 3GPP.
+The thesis begins with an overview of \gls{sim} and \gls{esim} technologies in \cref{ch:background}, along with the \gls{rsp} architecture, to establish the necessary technical background. It also introduces the relevant standards developed by the \gls{gsma}, \gls{etsi}, and \gls{3gpp}.
 
 In \cref{ch:relatedwork}, it surveys related work in the domain of \gls{sim} and \gls{esim} security, focusing on academic literature, emulation frameworks, and software tools used for analysis.
 

Chapters/RelatedWork.tex

@@ -38,7 +38,7 @@ To support this, they demonstrate how their framework enables fuzz testing by em
 
 Using their emulation framework, the authors discovered multiple high-impact memory corruption vulnerabilities in baseband implementations. These were exploited via spyware-like payloads reminiscent of the \textit{SIMjacker} attack~\cite{enea_simjacker_2019}, remotely installed onto the \gls{sim} card. This spyware exfiltrates information to the attacker without requiring user interaction. Their findings underscore the seriousness of hostile SIMs as an attack vector and argue that such threat models should be incorporated into mobile security considerations.
 
-\textcite{ahmed_security_2024} present a formal model of the \gls{rsp} protocol based on the SGP.22 specification. The model is developed using \texttt{ProVerif} to verify the security properties of remote profile provisioning. Although many of the identified failure modes require strong attacker capabilities—such as compromise of \gls{tls} private keys—the study highlights a particularly practical issue: the absence of a robust mechanism to verify user intent. An attacker could initiate a profile download to a victim's \gls{euicc} without user consent, provided they have access to the device or provisioning channel, resulting in unauthorized profile installation.
+\textcite{ahmed_security_2024} present a formal model of the \gls{rsp} protocol based on the SGP.22 specification. The model is developed using \texttt{ProVerif}~\cite{blanchet_efficient_2001} to verify the security properties of remote profile provisioning. Although many of the identified failure modes require strong attacker capabilities—such as compromise of \gls{tls} private keys—the study highlights a particularly practical issue: the absence of a robust mechanism to verify user intent. An attacker could initiate a profile download to a victim's \gls{euicc} without user consent, provided they have access to the device or provisioning channel, resulting in unauthorized profile installation.
 
 \textcite{ahmed_transparency_2021} critiques the centralized trust model underlying the \gls{rsp} ecosystem. The study emphasizes that the entire trust infrastructure hinges on the \gls{pki} used by the \gls{gsma} to certify \gls{smdpp} domains. A breach of any single \gls{smdpp} server could allow an attacker to issue cloned or rogue profiles of that operator to attacker controlled \glspl{euicc}. To address this, the authors propose the SIM Profile Transparency Protocol (SPTP), a protocol designed to enhance transparency and trust in the provisioning process.
 
@@ -66,7 +66,7 @@ The \texttt{pySim} suite comprises five primary scripts: \texttt{pySim-shell}, \
 
 The \texttt{pySim-trace} script provides a tracing utility and protocol decoder for \gls{sim} card-related communication. It integrates with \texttt{SIMtrace2} to intercept and decode communication between a user device and the \gls{sim} card. This functionality is limited to passive recording and does not support active injection or modification of messages.
 
-The \texttt{pySim-smdpp} script serves as a proof-of-concept implementation of the SGP.22 \gls{smdpp} server component. Notably, \texttt{pySim} does not implement the full SGP.22 protocol stack on the client side (i.e., communication between the \gls{euicc} and the \gls{smdpp} server); its SGP.22 functionality is restricted to the server role only.
+The \texttt{pySim-smdpp} script serves as a proof-of-concept implementation of the SGP.22 \gls{smdpp} server component. Notably, \texttt{pySim} does not implement the full SGP.22 protocol stack on the client side (\ie, communication between the \gls{euicc} and the \gls{smdpp} server), although its SGP.22 functionality is restricted to the server role only.
 
 While \texttt{pySim} provides useful standalone utilities, its usability as a general-purpose library is limited. The internal architecture is not optimized for external scripting, requiring substantial effort to perform even basic tasks programmatically. As such, \texttt{pySim} is best suited for interactive use via its provided command-line tools rather than as a cleanly structured library for automation or integration.
 
@@ -106,7 +106,7 @@ Overall, \texttt{SIMtrace2} is a versatile tool both for passive analysis and ac
 
 Due to its C-language base, \texttt{lpac} is widely adopted across various platforms through language-specific wrappers. It forms the core of several \gls{lpa} implementations, including \texttt{EasyEuicc}, \texttt{OpenEuicc}, \texttt{MiniLPA}, and others~\cite{icedtangerine_easylpac_2025, petercxy_openeuicc_nodate, esimmoe_minilpa_nodate}. It also exposes a command-line interface, allowing users to interact with the \gls{lpa} directly for debugging or automation purposes.
 
-However, \texttt{lpac} only supports SGP.22 version 2.2.2, whereas the most recent version (3.1) introduces several enhancements, especially targeted at \gls{iot} \gls{esim} use cases, including additional return values and extended feature support \cite{gsma_sgp22_2025}. Furthermore, while the software is considered mature and widely usable, its extensibility remains limited. Key components such as \gls{asn1} decoding and encoding are implemented manually without leveraging standardized libraries.
+However, \texttt{lpac} only supports SGP.22 version 2.2.2, whereas the most recent version (3.1) introduces several enhancements, especially targeted at \gls{iot} \gls{esim} use cases, including additional return values and extended feature support \cite{gsma_sgp22_2025}. Furthermore, while the software is considered mature and widely usable, its extensibility remains limited. Key components such as \gls{asn1} decoding and encoding are implemented manually without leveraging standardized libraries like \texttt{asn1c}~\cite{walkin_asn1c_2025}.
 
 \paragraph{SIMTester}