Update on Overleaf.

Bibliography.bib

@@ -570,3 +570,29 @@ C compilers is available on the web.},
 	note = {original-date: 2015-06-16T18:25:06Z},
 	keywords = {apdu, pcsc, pyscard, python, python3, smartcard, smartcard-library, travis-ci},
 }
+@misc{nist_nvd_2025,
+	title = {{NVD} - {CVE}-2025-0343},
+	url = {https://nvd.nist.gov/vuln/detail/CVE-2025-0343},
+	urldate = {2025-06-30},
+	author = {{NIST}},
+	year = {2025},
+	file = {NVD - CVE-2025-0343:/home/niklas/Zotero/storage/D6K8HLIX/CVE-2025-0343.html:text/html},
+}
+
+@misc{mitre_cve_2003,
+	title = {{CVE} - {CVE}-2003-0818},
+	url = {https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0818},
+	urldate = {2025-06-30},
+	author = {{MITRE}},
+	year = {2003},
+	file = {CVE - CVE-2003-0818:/home/niklas/Zotero/storage/8NTHT84Y/cvename.html:text/html},
+}
+
+@misc{nist_nvd_2024,
+	title = {{NVD} - {CVE}-2024-6197},
+	url = {https://nvd.nist.gov/vuln/detail/CVE-2024-6197},
+	urldate = {2025-06-30},
+	author = {{NIST}},
+	year = {2024},
+	file = {NVD - CVE-2024-6197:/home/niklas/Zotero/storage/PMM5K88C/CVE-2024-6197.html:text/html},
+}

Chapters/Background.tex

@@ -73,7 +73,7 @@ A C-APDU consists of mandatory header fields and optional data and length fields
     \caption{Structure of a \gls{capdu}}
     \begin{tabular}{|l|l|l|}
         \hline
-        \textbf{Field name} & \textbf{Length} & \textbf{Description} \\
+        \textbf{Field name} & \textbf{Length (bytes)} & \textbf{Description} \\
         \hline \hline
         $CLA$ & 1 & Instruction Class \\
         $INS$ & 1 & Instruction Code \ie "SELECT" \\
@@ -91,7 +91,7 @@ A C-APDU consists of mandatory header fields and optional data and length fields
     \caption{Structure of a \gls{rapdu}}
     \begin{tabular}{|l|l|l|}
         \hline
-        \textbf{Field name} & \textbf{Length} & \textbf{Description} \\
+        \textbf{Field name} & \textbf{Length (bytes)} & \textbf{Description} \\
         \hline \hline
         $Data$ & at most $N_e$ & Response Data \\
         $SW1$ & 1 & Status Word 1 \\
@@ -112,7 +112,7 @@ The status word (SW) in an \gls{rapdu} signifies whether a command was successfu
 % - 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}.
+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}
 
 \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.
 

Chapters/Conclusions.tex

@@ -12,8 +12,6 @@
 
 % reverse engineered the estk.me update mechanism
 
-% 
-
 % SIMs and eSIMs are an established standard
-% hard to analyze -> mostly blackbox fuzzing and analyzation with minimal error responses
-% 
+
+

Chapters/Discussion.tex

@@ -14,4 +14,5 @@
 % stricter session isolation
 
 % limitations of esim security research
+% hard to analyze -> mostly blackbox fuzzing and analyzation with minimal error responses
 % 

Chapters/Evaluation.tex

@@ -282,7 +282,7 @@ We catalogued the \gls{isdr} \glspl{aid} observed during tracing across multiple
     \item \textbf{standard}: \texttt{a0000005591010ffffffff8900000100}
 \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. \todo{Check which applications are allowed by the aram}
+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. \todo{Check which applications are allowed by the ara-m}
 
 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.
 
@@ -517,6 +517,13 @@ The following classes of errors were consistently encountered during mutation ca
 % same result when switching out the whole certificate
 % suggests that more than just the certificate is beeing reused from the previouse session
 
+% looking closer into the first bitflip in the failed request when using different smdps
+% first flip is in the tag for the AuthenticateServerRequest (bf38 -> be38 where be38 is invalid) -> fixing this leads to the following other flips
+% flips are done in euiccPkiToBeUsed, serverCertificate.serialNumber, serverSignature1, serverSigned1.euiccChallenge, serverSigned1.serverChallenge
+% when looking at the bitflips from the failed request with the same smdp server
+% first flip again in the tag for the request, fixing this shows flips in euiccCiPKIdToBeUsed, serverCertificate.issuer, serverCertificate.serialNumber, serverSignature1, serverSigned1.serverChallenge
+
+
 \subsection{Analysis of Successful Mutations}
 \label{subsec:successful_mutations}
 
@@ -560,6 +567,18 @@ By combining a series of failed and mutated authentication requests, it was poss
     \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.
 \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{itemize}
+    \item The first mutation typically occurs in the tag of the \texttt{AuthenticateServerRequest}, where the correct \texttt{bf38} tag is flipped to an invalid \texttt{be38}. Correcting this tag lets us decode the remaining data.
+    
+    \item In cross-server scenarios (different \gls{smdpp}), subsequent flips occur in fields such as \texttt{euiccPkiToBeUsed}, \texttt{serverCertificate.serialNumber}, \texttt{serverSignature1}, and both the \texttt{euiccChallenge} and \texttt{serverChallenge} components of \texttt{serverSigned1}. This attempt will not be able to pass the bug.
+    
+    \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.
+
 \subsubsection*{State Persistence Across Sessions}
 Further experiments showed that this vulnerability persists across sessions and even power cycles:
 

Chapters/Introduction.tex

@@ -27,20 +27,33 @@
 % security vulnerabilities can have a major impact -> persistence of exploits are high: malicouse profiles may persist accross reboots or even device resets; often low level and invisible -> particularly dangerous and hard to detect
 % sims have direct, priviledged, unfiltered access to the baseband
 
+% esim os are closed source and implemented by the manufactruers -> not subject to open review
+% strengthens the importance of black-box testing methodologies to uncover implementation specific issues without requiring internal access
+% also has potential for undocumented features and backdoors -> esim  vendors might introduce update endpoints to update their esim firmware, or add extra functionality outside of the specs
+
 % non standard implementations may introduce bugs or security flaws 
+% implementation bugs: like any other complex embedded system esim stack are susceptiuble to bugs
+% particular dangeros due to the priviledged rele of the esim in device architecture
 
 % esim specs may have been interpretated differently by the different vendors
 
 % differential testing offers automated and scalable method to detect inconsistency in the different implementations -> comparing output of multiple esim on sim implementations against the same inputs
 
+% this thesis addresses need for systematic security and correctness evaluation of esim on sim implementations -> differential testing
+% 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
+
 \section{Contribution}
 
 % implement framework for differential testing of esims (esims and esim on sim)
 % containing: fuzzing of structural input when communicating with the esim, fuzzing on transport level, tracing and replaying recordings from one esim to another; make it accessible via cli and as a library for scripting
+% this includes custom LPA implementation, APDU mutation engine, and structured fuzzing tools
+% using property based testing: generate valid but edge-case-rich inputs targeting high-level esim commands -> detecting errors beyond byte-level malformations
 % using the tracing functionality we discover first implementation differences in the implementation
 % reverse engineer the update functionality of the estk.me esim
 % demonstrate the framworks ability in security research:
-% discover and evaluate bug in the profile provisioning process of one manufacturer -> evaluate the impact
-
+% through apdu level differnetial testing, we discover and evaluate bug in the profile provisioning process of one manufacturer -> suggests potential security risk such as certificate validation bypass -> analyze and evaluate potential impact
 
 \section{Outline}
+
+%