Update on Overleaf.

Chapters/Background.tex

@@ -281,7 +281,7 @@ The SIM/USIM Application Toolkit — collectively referred to as the \gls{cat} i
 
 One of the most significant advantages of \glspl{esim} is the ability to download and install profiles remotely without physically swapping the card. This process, known as \gls{rsp}, is defined by the GSMA in specification SGP.22~\cite{gsma_sgp22_2023, gsma_sgp22_2024, gsma_sgp22_2025}. The key components of the RSP ecosystem are the \gls{lpa}, the \gls{smdpp}, and, to a lesser extent in consumer deployments, the \gls{smds}.
 
-The \gls{lpa} is a user-facing application on the UE that interacts with the \gls{euicc}, enabling users to initiate profile provisioning and perform lifecycle management operations such as enabling, disabling, or deleting profiles. The \gls{smdpp} is a server—operated by an eUICC manufacturer, MNO, or third party—that securely hosts eSIM profiles and makes them available for download. The \gls{smds} facilitates the “push” provisioning approach but is less common in consumer scenarios.
+The \gls{lpa} is a user-facing application on the UE that interacts with the \gls{euicc}, enabling users to initiate profile provisioning and perform lifecycle management operations such as enabling, disabling, or deleting profiles. The \gls{smdpp} is a server—operated by an eUICC manufacturer, MNO, or third party—that securely hosts eSIM profiles and makes them available for download. The \gls{smds} facilitates the "push" provisioning approach but is less common in consumer scenarios.
 
 \begin{figure}[h!]
     \includegraphics[width=\textwidth]{Graphics/rsp_architecture.png}

Chapters/Implementation.tex

@@ -5,9 +5,33 @@
 %************************************************
 \glsresetall % Resets all acronyms to not used
 
+% - Goal of this thesis is security analysis using differential testing
+% - first idea (naive implementation): use simtrace2 to capture traffic between the LPA (ue) and euicc
+% - simtrace2 sends apdus to socket via udp packet -> read data from socket -> analyse apdu command for instruction type
+% - save recored traffic to file 
+% - insert other euicc into pcsc card reader -> replay each apdu to euicc
+% - check for differences in the responses
+% - problem: rsp uses signed nonces -> can't replay data
+% - next idea: implement lpa to perform actions via code -> not rely on manual interaction with esim manufacturer lpa app, manufacturer lpa introduce traffic that is not necessary for the intended action
+% - use the lpa to produce traffic for the euicc in the pcsc card reader, but mutate it before sending
+% - record the returned status codes and check if different euicc behaves the same (crashes at the same point or returns the same status word)
+% - on the slower side -> rsp is stateful and we rely on the sm-dp+ from the profile vendor
+% - small problem: we basically just fuzz the asn1 parser of the euicc sometimes
+% - alternative: fuzz valid input data
+% - oss-fuzz proposes python hypothesis as a framework for fuzzing via python
+% - python hypothesis: property based testing library -> we define input structure and hypothesis produces data that is valid for the given structure
+% - tests for edge cases
+% - in the following section i will go into details on how each implementation works
+
 \section{Tracing}
 \label{sec:tracing}
 
+% functions: 
+% - trace traffic from the simtrace2, map the traffic to function calls i.e. identify which function the call handles, record the traced traffic
+% - replay: replay the previously recorded traffic to euicc in pcsc reader, check 
+% parts:
+% - card: 
+
 \section{LPA}
 \label{sec:lpa}