From bf7e86572ec8291fba93f782bf271907c9f17978 Mon Sep 17 00:00:00 2001 From: nb72soza Bittner Date: Fri, 11 Jul 2025 23:22:38 +0000 Subject: [PATCH] Update on Overleaf. --- Appendices/SomeProof.tex | 2 +- Chapters/Background.tex | 2 ++ Chapters/Conclusions.tex | 10 ---------- Chapters/Discussion.tex | 10 ++++++++++ Chapters/Evaluation.tex | 17 +++++++++++------ Chapters/Introduction.tex | 2 +- PersonalInfo.tex | 2 +- 7 files changed, 26 insertions(+), 19 deletions(-) diff --git a/Appendices/SomeProof.tex b/Appendices/SomeProof.tex index 32de7cc..42098e7 100644 --- a/Appendices/SomeProof.tex +++ b/Appendices/SomeProof.tex @@ -6,7 +6,7 @@ % -- TemplateKnob % If problems with the headers: get headings in appendix etc. right %\markboth{\spacedlowsmallcaps{Appendix}}{\spacedlowsmallcaps{Appendix}} -\chapter{Some Proof}\label{ch:SomeProof} +\chapter{Appendix}\label{ch:SomeProof} \glsresetall % Resets all acronyms to not used \section{Exception Handling} diff --git a/Chapters/Background.tex b/Chapters/Background.tex index bc44a5b..7e1bb5f 100644 --- a/Chapters/Background.tex +++ b/Chapters/Background.tex @@ -451,6 +451,8 @@ Upon successful authentication, the \gls{smdpp} checks for profile availability Next, the \gls{euicc} and \gls{smdpp} perform an \gls{ecka} to derive session keys. The \gls{smdpp} encrypts the profile using the session key and transmits it to the \gls{euicc}. The \gls{euicc} configures the new \gls{isdp}, decrypts the profile, and installs it. The profile is then ready for use. +\todo{Explain what sequenceOf87, sequenceOf88, etc is because we are using this later on} + \paragraph{Notification} After installation, session keys are erased and the \gls{euicc} generates a signed installation notification containing a sequence number and server address. The \gls{lpa} forwards this notification to the \gls{smdpp}, and upon receiving a success response, the \gls{euicc} removes the notification, completing the provisioning cycle. diff --git a/Chapters/Conclusions.tex b/Chapters/Conclusions.tex index 98ee3b9..b26fbfa 100644 --- a/Chapters/Conclusions.tex +++ b/Chapters/Conclusions.tex @@ -18,13 +18,3 @@ This thesis presented a systematic security analysis of commercial eSIM-on-SIM c The developed framework integrates trace recording, scenario-driven testing, and property-based structured fuzzing, allowing the systematic mutation and replay of \gls{apdu} traces. The combination of syntactically valid \gls{asn1}-based input generation with deterministic mutation provides a strong fuzzing implementation. Through this approach, several notable implementation differences were identified, including a critical certificate validation bypass in one vendor’s \gls{euicc} side provisioning logic. These findings highlight the importance of independent verification and validation of \gls{esim} implementations. The observed deviations from \gls{gsma} specifications suggest that even well-established standards do not guarantee uniform security guarantees across vendors. Differential testing, as demonstrated, offers a scalable and automation-friendly approach to detect such inconsistencies without requiring access to proprietary source code. - - -\section{Future Work} -\label{sec:future_work} - -This work can be extended in several directions. 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 as soon as implementations become available. 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. - -Additionally, adding support for proactive commands to the fuzzing engine would enable testing of \gls{euicc} cards that expose only \gls{usat}-based interfaces, such as those from estk.me and 9esim v2. This addition would broaden the scope of the framework, allowing it to address a wider range of commercial \gls{esim} implementations and significantly increase protocol coverage. - -Finally, improvements to the fuzzing engine itself, such as incorporating a Hypothesis rule based state machine, would allow direct behavioral comparisons between custom \gls{smdpp} and \gls{euicc} implementations and proprietary systems. diff --git a/Chapters/Discussion.tex b/Chapters/Discussion.tex index 26ddbbc..d560079 100644 --- a/Chapters/Discussion.tex +++ b/Chapters/Discussion.tex @@ -79,3 +79,13 @@ While the results demonstrate the effectiveness of our framework, several limita To mitigate the certificate reuse issue observed, we recommend stricter cryptographic context isolation, including flushing session state after failed provisioning attempts. This would reduce the risk of unintended reuse of sensitive materials across sessions. +\section{Future Work} +\label{sec:future_work} + +This work can be extended in several directions. 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 as soon as implementations become available. 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. + +Additionally, adding support for proactive commands to the fuzzing engine would enable testing of \gls{euicc} cards that expose only \gls{usat}-based interfaces, such as those from estk.me and 9esim v2. This addition would broaden the scope of the framework, allowing it to address a wider range of commercial \gls{esim} implementations and significantly increase protocol coverage. + +Finally, improvements to the fuzzing engine itself, such as incorporating a Hypothesis rule based state machine, would allow direct behavioral comparisons between custom \gls{smdpp} and \gls{euicc} implementations and proprietary systems. + + diff --git a/Chapters/Evaluation.tex b/Chapters/Evaluation.tex index b113bb1..284bd13 100644 --- a/Chapters/Evaluation.tex +++ b/Chapters/Evaluation.tex @@ -240,7 +240,7 @@ To investigate vendor-specific behaviors in \gls{rsp}, we employed SIMTrace2 to During the analysis of the \texttt{eSIM.me} eSIM, we observed the use of a custom \gls{aid} during the SELECT command for \gls{isdr}. The following listing illustrates a sample trace captured while launching the \texttt{esim.me} Android application: -\begin{lstlisting}[style=logstyle, escapeinside={(*}{*)}, caption={Traced APDUs when launching the esim.me App. Captured commands are executed by the esim.me App.] +\begin{lstlisting}[style=logstyle, escapeinside={(*}{*)}, caption={Traced APDUs when launching the esim.me App. Captured commands are executed by the esim.me App.}] INFO Captured MANAGE CHANNEL Apdu(00 70 00 00 01 01 9000) INFO Captured SELECT MF/ADF.ISD-R Apdu(01 A4 04 00 10 a0000005591010ffffffff8900000100 6f1f8410a0000005591010ffffffff8900000100a5049f6501ffe0058203020200 9000) INFO Captured MANAGE CHANNEL Apdu(00 70 00 00 01 01 9000) @@ -284,7 +284,7 @@ While tracing provides valuable insights into command sequencing and \gls{aid} s \todo{Introduce different setups to make it more obvious when conducting seperate experiments} -\begin{table}[h!] +\begin{table}[h] \centering \caption{Data fuzzing results for 5ber, eSIM.me, and EIOTCLUB} \label{tab:data_fuzzing_result_part1} @@ -305,7 +305,7 @@ While tracing provides valuable insights into command sequencing and \gls{aid} s \end{tabular} \end{table} -\begin{table}[h!] +\begin{table}[h] \centering \caption{Data fuzzing results for 9esim, 9esim v2, and Xesim} \label{tab:data_fuzzing_result_part2} @@ -324,6 +324,7 @@ While tracing provides valuable insights into command sequencing and \gls{aid} s BoundProfilePackage & \cmark & \cmark & \cmark \\ \bottomrule \end{tabular} + \todo{Merge tables and explain check mark and cross} \end{table} We conducted data fuzzing, as described in \cref{subsec:data_fuzzing}, on all tested \gls{esim} cards with the exception of \texttt{estk.me}. Each test case is executed sequentially across all eligible \glspl{esim} to ensure consistency and reproducibility of results. @@ -417,6 +418,7 @@ Initial fuzzing experiments revealed that applying aggressive mutations across a \subsection*{Experimental Setup} All tests were conducted using a HID OMNIKEY 3121 USB smart card reader.\glspl{esim} were inserted into a Sysmocom 2FF-to-full-size adapter to ensure compatibility with the reader. For consumer-grade \glspl{esim}, the following profile was used: +\todo{Reference where the profiles are comming from} \begin{center} \texttt{LPA:1\$rsp.truphone.com\$QR-G-5C-1LS-1W1Z9P7} \end{center} @@ -431,6 +433,7 @@ The execution time of fuzzed \gls{apdu} sequences varied depending on chip proce \subsection*{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} \begin{itemize} \item \textbf{SCP03TSecurityError}: Occurred during the \texttt{\justify LoadBoundProfilePackage} step, particularly when transmitting \texttt{sequenceOf86}, \texttt{sequenceOf88}, or the initial \texttt{sequenceOf87}. This indicates failure during Secure Channel Protocol 03 (terminal-side variant) session establishment. @@ -591,7 +594,7 @@ The following classes of errors were consistently encountered during mutation ca \subsection{Analysis of Successful Mutations} \label{subsec:successful_mutations} -To further understand the behavior of different \glspl{euicc} under mutation-based fuzzing, we post-processed all recorded \gls{apdu} traces. +To further understand the behavior of different \glspl{euicc} \todo{Which euiccs?} under mutation-based fuzzing, we post-processed all recorded \gls{apdu} traces. \subsubsection*{Mutation Examples} @@ -604,6 +607,8 @@ A single-bit mutation changed a byte from \texttt{0xA0} to \texttt{0xA1}. Despit \paragraph{AUTHENTICATE\_SERVER Truncation} In one case, the mutation engine truncated approximately 75\% of the \texttt{AuthenticateServerRequest} \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} + \subsection{Certificate Validation Bypass} \label{subsec:certificate_bypass} @@ -639,7 +644,7 @@ By combining a series of failed and mutated authentication requests, it was poss 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. + \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 provides a valid \gls{asn1} structure and makes the remaining data decodable. \item In cross-server scenarios (different \gls{smdpp}), subsequent flips occur in fields such as \texttt{euiccPki\-ToBeUsed}, \texttt{server\-Certificate.\-serial\-Number}, \texttt{server\-Signature1}, and both the \texttt{euicc\-Challenge} and \texttt{server\-Challenge} components of \texttt{server\-Signed1}. This attempt will not be able to pass the bug. @@ -656,7 +661,7 @@ Further experiments showed that this vulnerability persists across sessions and \item If different profiles from the same \gls{smdpp} are used (e.g., activation codes \texttt{QR-G-5C-1LS-1W1Z9P7} and \texttt{QRF-SPEEDTEST}), the bypass remains possible. - \item However, if different \gls{smdpp} servers are used (e.g., \texttt{rsp.truphone.com} vs \texttt{rsp-eu.redteamobile.com}), the attack fails, and the \gls{euicc} returns an \texttt{UndefinedError}. This is supports the idea that the euicc reuses the public key from the previously sent but failed \texttt{AuthenticateServerRequest}. + \item However, if different \gls{smdpp} servers are used (e.g., \texttt{rsp.truphone.com} vs \texttt{rsp-eu.redteamobile.com}), the attack fails, and the \gls{euicc} returns an \texttt{UndefinedError}. This supports the idea that the \gls{euicc} reuses the public key from the previously sent but failed \texttt{AuthenticateServerRequest}. \end{itemize} To further probe the caching mechanism, additional tests were conducted in which the public key of the second \texttt{AuthenticateServerRequest} was substituted into the first request. Based on previous observations, it was hypothesized that this would allow a successful installation by aligning the reused state with the new request. diff --git a/Chapters/Introduction.tex b/Chapters/Introduction.tex index 9a1e1fc..e3ca22d 100644 --- a/Chapters/Introduction.tex +++ b/Chapters/Introduction.tex @@ -119,4 +119,4 @@ The implementation of the proposed differential testing framework is described i Following the implementation, we evaluate a selection of commercial eSIM-on-SIM cards using the developed framework in \cref{ch:evaluation}. We analyze inconsistencies in behavior across vendors and discuss potential deviations from the specifications. -Finally, we discuss the broader implications of our findings in \cref{ch:discussion}, reflect on current limitations in eSIM-on-SIM deployment models, and propose avenues for future research in \cref{ch:conclusions}, including expanding the framework to support proactive commands and IoT-specific provisioning flows. +Finally, we discuss the broader implications of our findings and propose avenues for future research including expanding the framework to support proactive commands and IoT-specific provisioning flows in \cref{ch:discussion}. Finally we reflect on current limitations in eSIM-on-SIM deployment models and conclude in \cref{ch:conclusions}. diff --git a/PersonalInfo.tex b/PersonalInfo.tex index 2f7be30..27bc511 100644 --- a/PersonalInfo.tex +++ b/PersonalInfo.tex @@ -16,7 +16,7 @@ % Custom variables -\newcommand{\sysname}{reSIMulate} +\newcommand{\sysname}{\texttt{reSIMulate}} % -----------------------------------------------------------------------