Update on Overleaf.

Chapters/Background.tex

@@ -0,0 +1,212 @@
+% !TeX root = ../Thesis.tex
+
+%************************************************
+\chapter{Background}\label{ch:design}
+%************************************************
+\glsresetall % Resets all acronyms to not used
+
+\section{Subscriber Identity Module}
+\label{sec:sim}
+
+% - base is a smart card -> also used for bank cards, MIFARE cards, etc
+% - contains a CPU, ROM, RAM and can be connected via 8 PINS on the back side
+% - access is provided via the OS running on the card, offers file structure 
+% - The os on the card can also run java card applets to provide additional functionality
+% - java card applets enable the use of the java language to be used on smart cards, use the Java Card Runtime Environment which runs inside the Java Card VM
+
+The \gls{sim} card is a specialized type of smart card, a form factor also employed in applications such as banking (\eg, EMV cards) and access control (\eg, \gls{mifare} cards). As a smart card, a SIM contains essential computing components: a \gls{cpu}, \gls{rom}, and \gls{ram}, all of which are accessed through up to eight physical contacts (pins) on the card's surface~\cite{smartcard-standard}.
+
+Interaction with the \gls{sim} is governed by an embedded operating system, which provides a standardized file system structure for data access and application management. In addition to storing subscriber data and cryptographic keys, the \gls{sim} operating system can execute Java Card applets to extend its functionality.
+
+Java Card applets are applications written in a restricted subset of the Java programming language, specifically tailored for execution on constrained devices. They operate within the \gls{jcre}, which itself runs inside the \gls{jcvm}. This environment enables secure, platform-independent execution of custom logic directly on the \gls{sim} card, a capability that is heavily utilized in mobile network provisioning, secure authentication, and value-added services.
+
+
+\paragraph{Standards}
+% - how SIMs operate and function is defined by 3 parties: ETSI, 3GPP, and the GSMA
+% - ETSI: defines how the SIM works as a platform i.e UICC hardware, how APDU are structured and work, and the smart card file system (cite TS 131 221)
+% - 3GPP: defines how the SIMs are integrated into the mobile networks by defining the mobile broadband standards such as 5G and LTE
+% - GSMA: defines the funcitonal systems around the eSIM to make it usable in the real-world, i.e. in the context of eSIMs: RSP, LPA, SM-DP+, etc -> later (cite SGP.22)
+
+The operation and functionality of \gls{sim} and \gls{esim} cards are defined and governed by three major standardization bodies: \gls{etsi}, \gls{3gpp}, and the \gls{gsma}. Each of these organizations contributes distinct specifications that together form the foundation of the \gls{sim} ecosystem.
+
+The \gls{etsi} defines the \gls{sim} card as a smart card platform. This includes specifications for the physical \gls{uicc} hardware, the structure and semantics of \gls{apdu} commands, and the internal smart card file system. Notably, the ETSI standard TS 131 221 specifies the logical structure of the file system and the behavior of elementary and dedicated files~\cite{etsi-ts-131-221}.
+
+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 \gls{lte}, \gls{5g}, and legacy systems. These standards ensure interoperability between SIMs 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 eSIM profiles. The GSMA's \gls{sgp22} specification is a cornerstone in this area, detailing the technical realization of the consumer remote \gls{sim} provisioning system~\cite{gsma_sgp22_2025}.
+
+
+
+\paragraph{Transport Protocols}
+% - ETSI defines two protocols for communication: T=0 and T=1
+% - T=0: half-duplex asynchronos asynchronous character based transmission protocol
+% - T=1: half-duplex asynchronous block based transmission protocol, is in several ways more advanced than t=0: better error correction, APDU chaining, better in handling large APDUs etc, but also has more overhead due to block headers,  control fields, way more complex in comparison to t=0  (cite TS 102 221)
+% - to the best of my knowledge t=1 is rarly used in consumer SIMs and eSIMs -> we will focus on t=0
+
+Communication between the \gls{uicc} and the terminal is governed by transport protocols defined by the \gls{etsi} standard TS 102 221~\cite{etsi-ts-102-221}. Two primary protocols are specified: \textbf{T=0} and \textbf{T=1}. 
+
+T=0 is a half-duplex, asynchronous, character-based transmission protocol. It is relatively simple in design and is widely supported across devices due to its low overhead and ease of implementation. However, it lacks advanced features such as robust error correction and support for transmitting large \glspl{apdu} efficiently.
+
+In contrast, T=1 is a half-duplex, asynchronous, block-oriented protocol. It introduces several enhancements over T=0, including improved error detection and correction mechanisms, APDU chaining for handling long messages, and more flexible flow control. These improvements come at the cost of increased complexity, as T=1 includes block headers, control fields, and more elaborate state handling. Due to this additional complexity and resource requirements, T=1 is, to the best of current knowledge, rarely employed in consumer-grade \gls{sim} or \gls{esim} cards.
+
+Given this, the remainder of this work will focus on the T=0 protocol, which remains the dominant transport protocol in commercial \gls{uicc} deployments.
+
+
+\paragraph{Application/Transportation Protocol Data Unit}
+% - we differentiate between APDU (Application layer) and TPDUs (transport layer)
+% - when sending APDUS to the UICC wthe ETSI defines them as C-APDUs (command apdus) and the responses from the UICC as R-APDUs (response apdus)
+% - on the tansport layer those are C-TPDUs and R-TPDUs respectivly
+% - the apdus have the following structure (insert table for C-apdus and r-apdus)
+% - the status word (sw) in the r-apdu indictates a successfull execution or an error
+% - success are indicated by 9000
+% - sw with 61XX or 6CXX are used to control the exchange on the transport layer and indicate that the UICC has data to return where XX indicates the amount of bytes that are availble
+% - other responses indicate errors during the command processing or execution (cite eftlabs list of apdu responses)
+
+In smart card communication, it is essential to distinguish between the application-layer protocol and the transport-layer protocol. At the application layer, the data units are referred to as \glspl{apdu}, while at the transport layer, they are termed \glspl{tpdu}. According to \gls{etsi} specifications, outgoing commands from the terminal to the \gls{uicc} are defined as \glspl{capdu}, and the responses from the UICC are defined as \glspl{rapdu}~\cite{etsi-ts-102-221}. On the transport layer, these correspond to \gls{ctpdu} and \gls{rtpdu}, respectively.
+
+A C-APDU consists of mandatory header fields and optional data and length fields. An R-APDU typically includes the response data followed by a two-byte status word (\texttt{SW1} and \texttt{SW2}), which indicates the result of the command execution.
+
+\begin{table}[h]
+    \centering
+    \caption{Structure of a \gls{capdu}}
+    \begin{tabular}{|l|l|l|}
+        \hline
+        \textbf{Field name} & \textbf{Length} & \textbf{Description} \\
+        \hline \hline
+        $CLA$ & 1 & Instruction Class \\
+        $INS$ & 1 & Instruction Code \ie "SELECT" \\
+        $P1$ & 1 & Parameter 1 \\
+        $P2$ & 1 & Parameter 2 \\
+        $L_c$ & 0, 1 & Encodes length ($N_c$) of command data \\
+        $Data$ & $N_c$ & Command data \\
+        $L_e$ & 0, 1 & Encodes length ($N_e$) of expected response data \\
+        \hline
+    \end{tabular}
+\end{table}
+
+\begin{table}[h]
+    \centering
+    \caption{Structure of a \gls{rapdu}}
+    \begin{tabular}{|l|l|l|}
+        \hline
+        \textbf{Field name} & \textbf{Length} & \textbf{Description} \\
+        \hline \hline
+        $Data$ & at most $N_e$ & Response Data \\
+        $SW1$ & 1 & Status Word 1 \\
+        $SW2$ & 1 & Status Word 1 \\
+        \hline
+    \end{tabular}
+\end{table}
+
+The status word (SW) in an \gls{rapdu} signifies whether a command was successfully processed or if an error occurred. The value \texttt{9000} is used to indicate successful execution. Other status words serve specific purposes. For instance, \texttt{61XX} or \texttt{6CXX} indicate that additional data is available, where \texttt{XX} specifies the number of bytes remaining. These codes are particularly relevant for controlling \gls{apdu} exchanges at the transport layer. Other status word values denote different error conditions related to command structure, logical access violations, or execution faults~\cite{eftlabs-apdu-status}.
+
+
+
+\paragraph{Data Encoding}
+% - when requesting data or storing data on the UICC the command data uses ASN.1 with BER-TLV encoding
+% - ASN.1 is a language that describes the sequence, the data and the encoding of the data that is used in a communication protocol (cite oss_nokalva)
+% - it is a mature and widly spread technology especially in the telecommunications field
+% - asn1 supports multiple different encoding rules among which is also the BER encoding
+% - 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
+
+\paragraph{Data Encoding}
+
+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-asn1}.
+
+\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.
+
+For example, consider the following simplified \texttt{STORE DATA} command that encodes an \texttt{EnableProfileRequest} as defined in the GSMA's \texttt{SGP.22} specification. The request uses the \gls{iccid} variant of the \texttt{profileIdentifier} field:
+
+\begin{verbatim}
+    BF31 10  
+    -- [49] SEQUENCE (EnableProfileRequest)
+       5A 0A 89 10 20 30 40 50 60 70 80 90  
+       -- ICCID (tag 5A, 10 bytes)
+       01 01 FF  
+       -- refreshFlag = TRUE (tag 01, length 1, value FF)
+\end{verbatim}
+
+In this example:
+\begin{itemize}
+    \item \texttt{BF31} is the context-specific tag for \texttt{EnableProfileRequest} (constructed, tag number 49).
+    \item \texttt{5A} represents the \gls{iccid} field as defined in the \gls{gsma} \gls{asn1} specification.
+    \item The ten-byte \gls{iccid} value shown here (\texttt{89 10 20 30 40 50 60 70 80 90}) is an example placeholder.
+    \item The boolean \texttt{refreshFlag} is encoded using tag \texttt{01} and value \texttt{FF}, which represents \texttt{TRUE} in \gls{asn1}.
+\end{itemize}
+
+The \gls{gsma} provides \gls{asn1} definitions for all standardized \gls{rsp} functions, including profile management procedures such as enabling or disabling profiles. These encoded messages are typically wrapped in a \texttt{STORE DATA} \gls{apdu} (instruction byte \texttt{E2}) and sent to the \gls{euicc} for execution.
+
+
+
+\paragraph{File Structure}
+
+% - the file structure on an UICC is organized as an forest of trees (cite TS 102 221
+% - Dedicated files (DF) allows for functional grouping of files 
+% - Applicataion DF: special DF that contains all EFs and DFs of an application
+% - Elementary files (EF) are childs of DF, differntiate between transparent EF, lienar fixed EF, cyclic EF
+% - Files are identified with their unique File Identifier (FID), Applications with their unique Application Identifier (AID)
+% - path represents a concatenation of FIDs, starts with MF or DF, FID "7fff" represents current ADF
+% - Master File represents the root object from which all EF, DF and ADF orginate from
+% - to select an file or application: SELECT command with FID/AID, path or short FID
+% - selcting files is stateful i.e to select subsequent files, first select the parent file or application to access files in that application
+% - Proposed AIDs by the GSMA/GP for Applications: ISD-R ("A0000005591010FFFFFFFF8900000100"), ARA-M ("'A00000015141434C00'")
+% - actual AID is up to the manufcacturer, especially ISD-R AID is often changed as explained in section (ref section here)
+
+The file system of a \gls{uicc} is organized as a hierarchical forest of trees, as specified in \cite{etsi102221}. At the top of the hierarchy resides the \gls{mf} (Master File), from which all other files—\glspl{df}, \glspl{ef}, and \glspl{adf}—originate.
+
+\glspl{df} serve as containers that enable functional grouping of files. A special class of DF, called \glspl{adf}, encapsulates all files (EFs and optionally DFs) related to a specific application. Within these structures, \glspl{ef} act as leaf nodes and contain the actual data. There are three types of EFs: transparent EFs (byte-oriented, raw data), linear fixed EFs (record-based, fixed-length records), and cyclic EFs (circular buffers).
+
+Each file is uniquely identified by a \gls{fid}, while applications are identified by their \gls{aid}. File paths are defined as a sequence of FIDs, typically starting from the MF or an ADF. The reserved FID \texttt{7FFF} refers to the currently selected ADF.
+
+To access files, the \texttt{SELECT} command is used. This command supports various addressing modes: by FID, AID, complete path, or short FID. Importantly, file selection is stateful—meaning that parent files or applications must be selected before accessing child files.
+
+Common AIDs proposed by the \gls{gsma} and \gls{gp} include the \gls{isdr} application (\texttt{A0000005591010FFFFFFFF8900000100}) and the \gls{aram} application (\texttt{A00000015141434C00}). However, the actual AIDs used are implementation-specific and may be customized by the manufacturer. The \gls{isdr} AID in particular is often modified, as discussed in Section~\ref{sec:isd-r-aid}.
+
+\section{Embedded SIM}
+\label{sec:esim}
+
+% - based on eUICC
+% - before: subscriber identity was bound to physical smart card (integrated during manufacturing) -> eSIM: decouples identiy from SIM -> virtualized and de-coupled from 
+% - USIM, ISIM, other Applications, and associated file system data is now an eSIM profile, underlying chip is eUICC
+% - profiles can be issued remotly (sm-ds) or can be triggered by an user via the lpa (sm-dp+)
+
+The concept of the \gls{esim} is based on the \gls{euicc}, which replaces the traditional removable SIM card form factor with a soldered chip that remains permanently embedded within the device.
+
+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}.
+
+This architecture introduces a secure, remote provisioning mechanism and significantly enhances user flexibility, while simultaneously introducing new complexity in terms of protocol design, security guarantees, and implementation correctness.
+
+
+\paragraph{eUICC Components}
+
+% - to manage and issue newe eSIM profiles the eUICC needs some relevant Applications
+% - ISD-R, ISD-P, ECASD, (LPAe), ARA-M,  LPA Services
+% - ECASD: secure storage of credentials relevant for the eUICC, i.e. eUICC privat keys and certificat, eSIM CI, EUM Certificat, Manufacturer key set for key/certificat renewal
+% - ECASD: signatur creation on data provided by the ISD-R, verification of certificates i.e SM-DP+ server certs
+% - ISD-R: responsible for creation of new ISD-Ps as well as lifecycle management i.e enable, disable and deletion of ISD-Ps
+% - only one of ECASD and ISD-R can be present on one eUICC
+% - ISD-P hosts one unique profile, used for profile download and installation, the ISD-P itself can also host applets
+% - ARA-M: defined by GlobalPlatform, Access Rules that are defined by the Secure Element Issuer i.e Manufacturer are availble via the Access Rule Application Master, Access Rules can be stored in multiple locations on the Secure Element -> ARA-M sources them and provides them
+
+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.
+
+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.
+
+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.
+
+Each \gls{isdp} hosts exactly one \gls{esim} profile and is responsible for profile download and installation. \glspl{isdp} may additionally host applets specific to the mobile network operator or service provider.
+
+The \gls{aram}, as specified by \gls{gp}, governs access control for applications on the Secure Element. It aggregates access rules from multiple possible sources on the Secure Element and provides them in a standardized form. These rules are defined by the Secure Element issuer—typically the device manufacturer—and can restrict which device-side applications are permitted to communicate with the \gls{euicc} and its applets.
+
+Together, these components establish the trust and management architecture necessary for secure and scalable remote SIM provisioning.
+
+\section{eSIM on SIM}
+
+\section{Remote SIM Provisioning}
+
+\paragraph{Local Profile Assistant}
+
+\paragraph{SM-DP+}

Chapters/Conclusions.tex

@@ -0,0 +1,8 @@
+% !TeX root = ../Thesis.tex
+
+%************************************************
+\chapter{Conclusions}\label{ch:conclusions}
+%************************************************
+\glsresetall % Resets all acronyms to not used
+
+\lipsum[7]

Chapters/Discussion.tex

@@ -0,0 +1,8 @@
+% !TeX root = ../Thesis.tex
+
+%************************************************
+\chapter{Discussion}\label{ch:discussion} % $\mathbb{ZNR}$
+%************************************************
+\glsresetall % Resets all acronyms to not used
+
+\lipsum[6]

Chapters/Evaluation.tex

@@ -0,0 +1,13 @@
+% !TeX root = ../Thesis.tex
+
+%************************************************
+\chapter{Evaluation}\label{ch:evaluation}
+%************************************************
+\glsresetall % Resets all acronyms to not used
+
+\section{Design}
+
+\section{Findings}
+
+\section{estk Firmware Update Application}
+\lipsum[5]

Chapters/Implementation.tex

@@ -0,0 +1,20 @@
+% !TeX root = ../Thesis.tex
+
+%************************************************
+\chapter{Implementation}\label{ch:implementation}
+%************************************************
+\glsresetall % Resets all acronyms to not used
+
+\section{Tracing}
+
+\section{LPA}
+
+\section{Fuzzing}
+
+\subsection{Data Fuzzing}
+
+\subsection{APDU Fuzzing}
+
+\section{CLI}
+
+\lipsum[4]

Chapters/Introduction.tex

@@ -0,0 +1,14 @@
+% !TeX root = ../Thesis.tex
+
+%************************************************
+\chapter{Introduction}\label{ch:introduction}
+%************************************************
+\glsresetall % Resets all acronyms to not used
+
+\section{Motivation}
+
+\section{Contribution}
+
+\section{Outline}
+
+\lipsum[3]

Chapters/RelatedWork.tex

@@ -0,0 +1,126 @@
+% !TeX root = ../Thesis.tex
+
+%*****************************************
+\chapter{Related Work}\label{ch:relatedwork}
+%*****************************************
+\glsresetall % Resets all acronyms to not used
+
+The ecosystem surrounding \gls{esim} and \gls{euicc} technology is supported by a combination of practical implementations and academic research. As this thesis focuses on differential testing of consumer \gls{esim} cards, it is essential to examine both established software tools that enable interaction with such cards and the existing academic efforts that analyze their security, functionality, and protocol correctness.
+
+\section{Software Implementations}
+
+\paragraph{pySim}
+
+% - python tool for interacting with SIM cards and their derivitives
+% - developed and maintained by osmocom -> engineer and implement tools all around SIMs i.e simtrace2 which we are also using for the tracing
+% - provides 5 scripts: shell, read, prog, trace, smdpp
+% - shell: main part -> provides shell like interface to move around the cards file structure and also execute application specific commands 
+% - similar to shell (legacy version of shell basically): supports a small subset of the commands
+% - utility to read most used fields of an SIM card
+% - trace: tracing utility and decoder for SIM card related protocols -> interacts with the simtrace2 to sniff packages between the user device and the card
+% - smdpp: poc implementation of the SGP.22 smdp+ server 
+% - pysim is a rather complex tool to work with outside of the provided scripts when it comes to scripting -> needs lots of code to archieve little functionality, does not provide a clean programming interface to be used as a library
+% - does not implement the SGP.22 communication with the card itself only the server side code
+% - tracing can only be used to record traces
+
+\texttt{pySim}~\cite{welte_pysim_2024} is a Python-based toolset designed for interacting with \gls{sim} cards and their derivatives. It is developed and actively maintained by the Osmocom project, a community of engineers focused on open-source mobile communication tools. Osmocom is also responsible for related utilities such as \texttt{simtrace2}, a hardware and software solution for tracing \gls{sim} card communication, which is utilized in this thesis for trace collection.
+
+The \texttt{pySim} suite comprises five primary scripts: \texttt{pySim-shell}, \texttt{pySim-read}, \texttt{pySim-prog}, \texttt{pySim-trace}, and \texttt{pySim-smdpp}. Among these, \texttt{pySim-shell} is the core component, offering an interactive shell interface to navigate the \gls{sim} card file system and issue application-specific commands. It supersedes the legacy \texttt{pySim-read} script, which only supports a limited subset of shell commands and is primarily used to extract commonly accessed data fields from \gls{sim} cards.
+
+The \texttt{pySim-trace} script provides a tracing utility and protocol decoder for 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; it 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.
+
+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.
+
+
+\paragraph{SIMtrace2}
+
+% - system consisting of software, firmware and hardware
+% - main purpose: used for tracing the communication between the SIM card and some user equipment i.e phone
+% - multiple different firmware version for different funcionality: trace, emulate
+% - trace allows for sniffing the communication, supports t=0 protocol and operates completly passiv
+% - sends sniffed apdus as udp packages to a socket from which it can be read with tools like wireshark or pySim-trace
+% - osmocom also offers wireshark disector, which makes it easier and better to read
+% - emulation offers card emulation for SIM cards, most commonly used for when the SIM card isn't in the device but rather some remote location or a smart card reader
+% - also used by Simurai for malicous card emulation
+
+\texttt{SIMtrace2} is a system developed by the osmocom~\cite{osmocom_simtrace_nodate} project that combines hardware, firmware, and software components to enable the monitoring and emulation of communication between a \gls{sim} card and \gls{ue}, such as a mobile phone~\cite{osmocom_simtrace_nodate}.
+
+The primary use case of \texttt{SIMtrace2} is passive tracing of the communication between a \gls{sim} card and its host device. For this purpose, it supports multiple firmware variants, the most relevant being the \texttt{trace} and \texttt{emulate} firmware. The \texttt{trace} firmware allows passive sniffing of \gls{apdu}-level communication, operating without interfering with the ongoing exchange. It supports the \gls{t0} protocol and transmits the captured data as \gls{udp} packets to a specified socket. These packets can be analyzed using tools such as \texttt{Wireshark}—for which Osmocom provides a dedicated dissector~\cite{welte_wireshark_nodate}—or through \texttt{pySim-trace}~\cite{welte_pysim_2024}.
+
+The \texttt{emulate} firmware, on the other hand, provides \gls{sim} card emulation capabilities. This mode is used to simulate a \gls{sim} card that is not physically present in the device, such as in scenarios involving remote \gls{sim} access or when using a smart card reader. Notably, this emulation capability has also been employed by projects such as \textit{Simurai} for malicious card emulation and fuzzing purposes~\cite{lisowski_simurai_2024}.
+
+Overall, \texttt{SIMtrace2} is a versatile tool both for passive analysis and active emulation of \gls{sim} card communication, making it valuable for research, debugging, and security analysis in the domain of mobile telecommunication.
+
+
+
+\paragraph{lpac}
+
+% - lpa implementation of the SGP.22 v2.2.2 in c from the estkme group
+% - full compatiability i.e. profile provisioning, profile interaction, and notification handling
+% - handles communication with card and smdp+ sever
+% - is used by many lpa implementations across platforms via wrappers, used by EasyEuicc, OpenEuicc, MiniLPA, and several others
+% - provides a cli to interact with
+% - only supports SGP.22 v2.2.2 -> newest version is v3.1 with several new additions for IoT eSIMs and also more information are returned in already existing functions
+% - established software, usablity as library improved by wrappers, doesn't offer flexibility for extending functionality -> asn decoding/encoding happens manually, no library used
+
+\texttt{lpac} is a C-based implementation of the \gls{lpa} defined in the \gls{sgp22}, version 2.2.2, developed by the \texttt{estk.me} group~\cite{estkme_lpac_2025}. It provides full support for the required \gls{lpa} functionality, including profile provisioning, profile interaction, and notification handling. The implementation manages both the communication with the \gls{euicc} and the \gls{smdpp} server, thereby serving as a complete \gls{lpa} stack.
+
+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 \gls{sgp22} 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. 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.
+
+\paragraph{SIMTester}
+
+
+% SIMTester
+% - java application that provides different tools to check if a specified SIM card is vulnerable against known vulnerabilities
+% - finds unprotected applications and uses cryptographic signatures and encryptions of plain text
+% - has own fuzzer implementation: fuzzer checks a combination of applicaation identifiers and 
+% - only checks for SIM specific vulnerabilities -> not against eSIM specific applications etc i.e profile switching and provisioning
+
+\texttt{SIMTester} is a Java-based application designed to evaluate the security posture of \gls{sim} cards by testing for a variety of known vulnerabilities~\cite{security_research_labs_simtester_2025}. It provides a suite of analysis tools that inspect the card for unprotected applications and analyze the use of cryptographic signatures and encryption mechanisms applied to plaintext communication.
+
+One of the core components of \texttt{SIMTester} is its integrated fuzzing module. This module systematically tests combinations of \gls{aid} and command structures to detect insecure or unexpected behavior in \gls{sim} applications. This approach enables the detection of vulnerabilities such as unauthorized access to file structures or insecure command handling.
+
+However, the scope of \texttt{SIMTester} is explicitly limited to physical \gls{sim} cards. It does not support or test \gls{esim}-specific features or functionalities, such as profile provisioning, profile switching, or remote \gls{sim} management as defined in the \gls{sgp22} specification. As such, while useful for legacy systems and certain classes of attacks, its applicability in the context of modern \gls{esim} testing is limited.
+
+
+\section{Literature}
+
+% SIMURAI
+% - focuses on the possiblility of compromised / attacker controlled SIM cards
+% - implemented a SIM card emulation framework consisting of: swSIM -> open source SIM and swICC -> smart Card framework
+% - Research goal: find out if malicious SIM cards are a credible attack vector
+% - they demonstrate their framwork by emulating SIM cards to enable fuzzing against user equipment
+% - propose 2 different attack scenarios: Rouge Carrier and interposer with physical access
+% - they evalute each attack scenario and propose possible mitigations
+% - used their implementation to discover multiple high value memory corruption vulnerabilities inside the 
+% - exploit those vulns by implementing spyware (similar to SIMjacker) that is remotly patched onto the SIM and sends information to the attacker
+% - show that hostile SIMs can be used to exploit vulnerabilites and urge that hostile SIMs should be considered as serious attack vectors
+
+% Security Analysis of the Consumer Remote SIM Provisioning Protocol
+% - implement a formal modal of RSP in ProVerfiy to remotly provision SIM profiles
+% - found different failure modes, however most of them assume a rather strong attacker -> e.g. TLS private key compromise, etc
+% - most practical one: no method to verify user intend -> attacker can order/request profile for victim euicc from sm-dp+ -> victim may be able to download attacker ordered profile
+
+% Transparency of SIM profiles for the consumer remote SIM provisioning protocol
+% - says that the entire security of the RSP relies on the PKI in which the GSMA signs domains of sm-dp+ server
+% - argues that RSP could be compromised if only a single sm-dp+ server is breached -> attacker could clone profiles
+% - propose SPTS (SIM profile transparency protocol) protocol that gives more transparency to the RSP profile provisioning process
+% - introduces two new actors to the protol which serve as a private index for IMSIs and a transperncy ledger which protocols each action in the RSP protocol for transparency
+% - using formal security analysis of their protocol with ProVerif and develope a prototype that uses the SPTS
+
+\texttt{Simurai} is a research framework that investigates the potential threat of compromised or attacker-controlled \gls{sim} cards~\cite{lisowski_simurai_2024}. The authors introduce a \gls{sim} card emulation system comprising two core components: \texttt{swSIM}, an open-source \gls{sim} card emulator, and \texttt{swICC}, a smart card framework. Their primary goal is to evaluate whether malicious \gls{sim} cards represent a credible attack vector against user equipment.
+
+To support this, they demonstrate how their framework enables fuzz testing by emulating arbitrary \gls{sim} card behaviors. The study proposes two concrete attack scenarios: (1) a rogue carrier scenario, in which a malicious network operator issues hostile \gls{sim} cards, and (2) a physical card interposer attack, where an attacker inserts a interposer between the legitimate \gls{sim} and the phone. For both scenarios, the researchers conduct evaluations and suggest potential mitigations.
+
+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, 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 \gls{sgp22} 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_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. To address this, the authors propose the \gls{sptp}, a protocol designed to enhance transparency and trust in the provisioning process.
+
+\gls{sptp} introduces two new entities: a private index service for managing \glspl{imsi}, and a transparency ledger that logs profile provisioning actions. Formal security analysis of the \gls{sptp} protocol using \texttt{ProVerif}, alongside a functional prototype, demonstrates that such an approach can mitigate the identified risks without significant architectural changes to the existing infrastructure.
+