niklas/master_thesis
1
0
Fork 0
mirror of https://sharelatex.tu-darmstadt.de/git/681e0e7a3a9c7c9c6b8bb298 synced 2025-12-07 05:08:01 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update on Overleaf.

Browse Source
This commit is contained in:
nb72soza Bittner
2025-07-01 23:50:06 +00:00
committed by node
parent 928dcd72df
commit 05541d57ab
10 changed files with 690 additions and 539 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
Acronyms.tex
View File

@@ -126,7 +126,7 @@
\newacronym{usim}{USIM}{Universal Subscriber Identity Module}
\newacronym{w3c}{W3C}{World Wide Web Consortium}
\newacronym{sgp22}{SGP.22}{Remote SIM Provisioning Architecture for Consumer Devices (GSMA Specification)}
\newacronym{sgp22}{SGP.22}{Remote SIM Provisioning Techincal Specification (GSMA Specification)}
\newacronym{iot}{IoT}{Internet of Things}
\newacronym{udp}{UDP}{User Datagram Protocol}
\newacronym{t0}{T=0}{Character-oriented transmission protocol (ISO/IEC 7816-3)}
@@ -154,6 +154,7 @@
\newacronym[plural=R-TPDUs]{rtpdu}{R-TPDU}{Response TPDU}
\newacronym{ber}{BER}{Basic Encoding Rules}
\newacronym{der}{DER}{Distinguished Encoding Rules}
\newacronym{df}{DF}{Dedicated File}
\newacronym{ef}{EF}{Elementary File}

10
AdditionalPackages.tex
View File

@@ -149,3 +149,13 @@
% TODO
\usepackage{todonotes}
% Acronyms
\newcommand{\glsposs}[1]{%
\ifglsused{#1}{%
\glslink{#1}{\glsentryshort{#1}'s}%
}{%
\glslink{#1}{\glsentrylong{#1}'s (\glsentryshort{#1})}%
}%
\glsadd{#1}%
}

4
Appendices/SomeProof.tex
View File

@@ -20,7 +20,7 @@
% listing2 shows implemention of a function exception class with a fill error_map and some example error exception
Robust exception handling is critical in the context of \gls{euicc} interactions, especially when performing differential testing. The \gls{sgp22} specification defines a comprehensive set of error codes, many of which are reused across different functions. To allow both coarse-grained and fine-grained error handling, the exception hierarchy in our implementation is explicitly structured around two core ideas:
Robust exception handling is critical in the context of \gls{euicc} interactions, especially when performing differential testing. The SGP.22 specification defines a comprehensive set of error codes, many of which are reused across different functions. To allow both coarse-grained and fine-grained error handling, the exception hierarchy in our implementation is explicitly structured around two core ideas:
\begin{itemize}
\item \textbf{Function-based exceptions} encapsulate the context in which the error occurred (e.g., Profile Management, \gls{isdr} interactions).
@@ -89,7 +89,7 @@ This exception model provides the following advantages:
\begin{itemize}
\item \textbf{Modular extensibility:} New error types can be added per function with minimal changes.
\item \textbf{Granular diagnostics:} Developers can differentiate between general failure (\texttt{ProfileInteractionException}) and specific causes (\texttt{IccidNotFoundException}).
\item \textbf{Cleaner call sites:} Exceptions can be caught using either the general or specific class depending on context.
\item \textbf{Cleaner call sites:} Exceptions can be caught using either the general or specific class, depending on context.
\end{itemize}
This exception system enables detailed introspection during fuzzing and testing while maintaining a clean abstraction between components.

931
Bibliography.bib
View File

File diff suppressed because it is too large Load Diff

129
Chapters/Background.tex
View File

@@ -14,11 +14,12 @@
% - 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}.
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, MIFARE cards). As a smart card, a \gls{sim} contains essential computing components: a CPU, ROM, and 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.
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 Java Card Runtime
Environment (JCRE), which itself runs inside the Java Card Virtual Machine (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}
@@ -29,11 +30,11 @@ Java Card applets are applications written in a restricted subset of the Java pr
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 151 011 specifies the logical structure of the file system and the behavior of elementary and dedicated files~\cite{etsi_ts_2005}.
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 \gls{etsi} standard TS 151 011 specifies the logical structure of the file system and the behavior of elementary and dedicated files~\cite{etsi_ts_2005}.
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{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 LTE, 5G, and legacy systems. These standards ensure interoperability between \glspl{sim} 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}.
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 \gls{esim} profiles. The \glsposs{gsma} SGP.22 specification is a cornerstone in this area, detailing the technical realization of the consumer remote \gls{sim} provisioning system~\cite{gsma_sgp22_2025}.
% 4 main specifications
% machine-2-machine standard (SGP.01, SGP.02): industry focused -> mainly used in the automotive industry to enable eCall functionality
@@ -41,24 +42,67 @@ The \gls{gsma} defines the higher-level functional architecture necessary to ope
% SGP.32 iot (SGP.31, SGP.32): for iot devices -> successor to m2m esim, supports 5g and NB-IoT, for sensors etc
% SGP.42 in factory (SGP.41, SGP.42) for cars and devices that immediate network connectivity after manufactoring -> mainly automotoive and iot industry
The main GSMA eSIM specifications can be categorized as follows:
\begin{table}[ht]
\centering
\small
\begin{tabular}{|p{2.5cm}|p{4cm}|p{4cm}|}
\hline
\textbf{Attribute} & \textbf{M2M} & \textbf{Consumer} \\
\hline \hline
\gls{gsma} Specification & SGP.01 / \textbf{SGP.02} & SGP.21 / \textbf{SGP.22} \\
\hline
First Publication & 2013 & 2015/2016 \\
\hline
Use Case & \textbf{Devices with no user interface} (e.g., automotive, industrial) & \textbf{Devices with user interface} (e.g., smartphones, tablets) \\
\hline
Examples & Vehicles, smart meters, sensors & Smartphones, tablets, wearables \\
\hline
RSP Type & \textbf{Push} (centrally managed) & \textbf{Pull} (user-initiated) \\
\hline
\end{tabular}
\caption{Comparison of M2M and Consumer eUICC Types \cite{gd_rsp_nodate}}
\label{tab:euicc_m2m_consumer}
\end{table}
\begin{table}[ht]
\centering
\small
\begin{tabular}{|p{2.5cm}|p{4cm}|p{4cm}|}
\hline
\textbf{Attribute} & \textbf{IoT} & \textbf{In-Factory} \\
\hline \hline
\gls{gsma} Specification & SGP.31 / \textbf{SGP.32} & SGP.41 / \textbf{SGP.42} \\
\hline
First Publication & 2023/2024 & 2025 \\
\hline
Use Case & \textbf{UI/network-constrained IoT devices} & \textbf{Profile pre-loading during production} \\
\hline
Examples & Trackers, wearables, sensors, vehicles & Smartphones, wearables, meters \\
\hline
RSP Type & \textbf{Push} (server-driven) & \textbf{Push} (factory provisioned) \\
\hline
\end{tabular}
\caption{Comparison of IoT and In-Factory eUICC Types \cite{gd_rsp_nodate}}
\label{tab:euicc_iot_infactory}
\end{table}
The main \gls{gsma} \gls{esim} specifications can be categorized as follows:
\begin{itemize}
\item \textbf{Machine-to-Machine (M2M) Standards (SGP.01, SGP.02):}
\item \textbf{Machine-to-Machine (M2M) Standard:}
Industry-focused specifications primarily used in the automotive sector to enable functionalities such as eCall.
\item \textbf{Consumer Specifications (SGP.21, SGP.22):}
Targeted at regular users and implemented in smartphones and other consumer devices for remote SIM provisioning with focus on ease of use.
\item \textbf{Consumer Standard:}
Targeted at regular users and implemented in smartphones and other consumer devices for remote \gls{sim} provisioning with focus on ease of use.
\item \textbf{Internet of Things (IoT) Specifications (SGP.31, SGP.32):}
Successors to the M2M eSIM standards, designed to support 5G and NB-IoT connectivity for sensors and various IoT devices.
\item \textbf{\gls{iot} Standard:}
Successors to the M2M \gls{esim} standards, designed to support 5G and Narrowband-IoT (NB-IoT) connectivity for sensors and various IoT devices.
\item \textbf{In-Factory Standard:}
Released in February 2025 as version 1.0, the upcoming In-Factory Profile Provisioning (IFPP) standard targets devices, such as those in the automotive and IoT sectors, that require network connectivity immediately after or during production. It is specifically designed to enable profile installation during the manufacturing process. So far only the IFPP Architecture and Requirements Specifications SGP.41~\cite{gsma_sgp41_2025} have been released, with the IFPP Technical Specification SGP.42 still being actively developed.
\item \textbf{In-Factory Specifications (SGP.41, SGP.42):}
A brand new specification with version 1.0 released in February 2025, intended for devices including cars and IoT hardware that require immediate network connectivity post-manufacturing, predominantly in the automotive and IoT industries.
\end{itemize}
\todo{Explain different GSMA standards i.e consumer, m2m, iot, factory}
\cref{tab:euicc_m2m_consumer} and \cref{tab:euicc_iot_infactory} compare the \gls{gsma} specifications and highlight their differences.
\paragraph{Transport Protocols}
@@ -71,7 +115,7 @@ Communication between the \gls{uicc} and the terminal is governed by transport p
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.
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, \gls{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.
@@ -86,14 +130,14 @@ Given this, the remainder of this work will focus on the T=0 protocol, which rem
% - 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_2023}. On the transport layer, these correspond to \gls{ctpdu} and \gls{rtpdu}, respectively.
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 Command APDUs (C-APDU), and the responses from the UICC are defined as Response APDUs (R-APDU)~\cite{etsi_ts_2023}. On the transport layer, these correspond to Command APDUs and Response APDUs, 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|}
\caption{Structure of a C-APDU}
\begin{tabular}{|l|l|p{6cm}|}
\hline
\textbf{Field name} & \textbf{Length (bytes)} & \textbf{Description} \\
\hline \hline
@@ -110,7 +154,7 @@ A C-APDU consists of mandatory header fields and optional data and length fields
\begin{table}[h]
\centering
\caption{Structure of a \gls{rapdu}}
\caption{Structure of a R-APDU}
\begin{tabular}{|l|l|l|}
\hline
\textbf{Field name} & \textbf{Length (bytes)} & \textbf{Description} \\
@@ -122,7 +166,7 @@ A C-APDU consists of mandatory header fields and optional data and length fields
\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{eftlab_list_nodate}.
The status word (SW) in an R-APDU 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{eftlab_list_nodate}.
@@ -138,7 +182,7 @@ When interacting with a \gls{uicc}, either to request or to store data, the comm
\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:
For example, consider the following simplified \texttt{STORE DATA} command that encodes an \texttt{EnableProfileRequest} as defined in the \glsposs{gsma} \texttt{SGP.22} specification. The request uses the \gls{iccid} variant of the \texttt{profileIdentifier} field:
\begin{verbatim}
BF31 10
@@ -168,29 +212,29 @@ The \gls{gsma} provides \gls{asn1} definitions for all standardized \gls{rsp} fu
% - 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
% - path represents a concatenation of FIDs, starts with MF or DF, FID "7fff" represents current \gls{adf}
% - Master File represents the root object from which all EF, DF and \gls{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{etsi_ts_2023}. At the top of the hierarchy resides the \gls{mf}, from which \glspl{df}, \glspl{ef}, and \glspl{adf} originate.
The file system of a \gls{uicc} is organized as a hierarchical forest of trees, as specified in \cite{etsi_ts_2023}. At the top of the hierarchy resides the Master File (MF), from which Dedicated Files (DFs), Elementary Files (EFs), and \glspl{adf} originate.
\glspl{df} serve as containers that enable functional grouping of files. A special class of \gls{df}, called \glspl{adf}, encapsulates all files (\glspl{ef} and optionally \glspl{df}) related to a specific application. Within these structures, \glspl{ef} act as leaf nodes and contain the actual data. There are three types of \glspl{ef}: transparent \glspl{ef} (byte-oriented, raw data), linear fixed \glspl{ef} (record-based, fixed-length records), and cyclic \glspl{ef} (circular buffers).
DFs 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, EFs 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 \glspl{fid}, typically starting from the \gls{mf} or an \gls{adf}. The reserved \gls{fid} \texttt{7FFF} refers to the currently selected \gls{adf}.
Each file is uniquely identified by a File Identifier (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 \gls{adf}. The reserved FID \texttt{7FFF} refers to the currently selected \gls{adf}.
To access files, the \texttt{SELECT} command is used. This command supports various addressing modes: by \gls{fid}, \gls{aid}, complete path, or short \gls{fid}. Importantly, file selection is stateful—meaning that parent files or applications must be selected before accessing child files.
To access files, the \texttt{SELECT} command is used. This command supports various addressing modes: by FID, \gls{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 and the \gls{aram} application.
Common \glspl{aid} proposed by the \gls{gsma} and \gls{gp} include the \gls{isdr} application and the \gls{aram} application.
\begin{itemize}
\item \gls{isdr} \texttt{A0000005591010FFFFFFFF8900000100}
\item \gls{aram} \texttt{A00000015141434C00}
\end{itemize}
However, the actual \glspl{aid} used are implementation-specific and may be customized by the manufacturer. The \gls{isdr} \gls{aid} in particular is often modified, as discussed in \cref{sec:findings}.
However, the actual \glspl{aid} used are implementation-specific and may be customized by the manufacturer. The \gls{isdr} \gls{aid} in particular is often modified, as discussed in \cref{sec:eval_tracing}.
\section{Embedded SIM}
\label{sec:esim}
@@ -206,7 +250,7 @@ Historically, the subscriber identity and related credentials were bound to a ph
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.
This architecture introduces a remote provisioning mechanism and significantly enhances user flexibility, while simultaneously introducing new complexity in terms of protocol design and implementation correctness.
\paragraph{eUICC Components}
@@ -235,11 +279,11 @@ The \gls{isdr} acts as the primary control authority on the \gls{euicc}. It mana
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. An \gls{euicc} can have multiple \glspl{isdp} to have multiple profiles installed at the same time. Each \gls{isdp} must have it's own unique \glspl{aid}.
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.
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, during the \gls{euicc} manufacturing process 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.
\paragraph{eSIM on SIM}
\paragraph{eSIM-on-SIM}
% - most popular option of integrating esims is directly soldering them onto the cricuit board of a smartphone
% - since the soldered esim is near identical to the SIMs normally distributed as physical SIMs -> esims can also be distributed as physical esims -> enables non esim capable phones to use esims
@@ -258,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 eUICC manufacturer—they can also be packaged as “physical eSIMs” 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{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.
\paragraph{Local Profile Assistant}
@@ -267,14 +311,17 @@ The \gls{lpa} is a user-facing application (i.e an App on a smartphone) on the \
\begin{figure}[h!]
\includegraphics[width=\textwidth]{Graphics/rsp_architecture.png}
\caption{\gls{rsp} architecture~\cite{gsma_sgp22_2024} consisting of the \gls{lpa}~\footnotemark, \gls{euicc}, \gls{smds}, and \gls{smdpp}.}
\caption[\gls{rsp} architecture~\cite{gsma_sgp22_2024} consisting of the \gls{lpa}, \gls{euicc}, \gls{smds}, and \gls{smdpp}.]{\gls{rsp} architecture~\cite{gsma_sgp22_2024} consisting of the \gls{lpa}~\footnotemark, \gls{euicc}, \gls{smds}, and \gls{smdpp}.}
\label{img:rsp_architecture}
\end{figure}
\footnotetext{The components referred to as the \gls{lpad} in this thesis — namely the \gls{ldsd}, \gls{lpdd}, and \gls{luid} — are collectively simplified and referred to as \gls{lpa} for readability.}
\footnotetext{The components referred to as the Local Profile Assistant when LPA is in the Device
(LPAd) in this thesis, namely the Local Discovery Service when LPA is in the Device
(LDSd), Local Profile Download when LPA is in the Device (LPDd), and Local User
Interface when LPA is in the Device (LUId), are collectively simplified and referred to as \gls{lpa} for readability.}
\paragraph{Application Toolkit}
The \gls{stk}/\gls{usat}, which are collectively referred to as the \gls{cat} in ETSI TS 102 223~\cite{etsi_ts_2014}, provides a proactive command framework for on-card applications. The original \gls{stk}, introduced in ETSI 11.14~\cite{etsi_gsm_1997}, targets GSM SIMs, while the \gls{usat}, defined in 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.
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. 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.
@@ -322,10 +369,10 @@ The \gls{stk}/\gls{usat}, which are collectively referred to as the \gls{cat} in
% - when success response: notification is deleted from euicc
% - profile provisioning is finished
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 \gls{gsma} in specification \gls{sgp22}~\cite{gsma_sgp22_2023, gsma_sgp22_2024, gsma_sgp22_2025}. The key components of the \gls{rsp} ecosystem are the \gls{lpa}, the \gls{smdpp}, and, to a lesser extent in consumer deployments, the \gls{smds}.
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 \gls{gsma} in specification SGP.22~\cite{gsma_sgp22_2023, gsma_sgp22_2024, gsma_sgp22_2025}. The key components of the \gls{rsp} ecosystem are the \gls{lpa}, the \gls{smdpp}, and, to a lesser extent in consumer deployments, the \gls{smds}.
\gls{sgp22} defines three \gls{rsp} initiation methods:
SGP.22 defines three \gls{rsp} initiation methods:
\begin{enumerate}
\item \textbf{Default Server}: The \gls{smdpp} address is pre-configured on the \gls{euicc} at manufacture time and points to a operator controlled server. The user triggers provisioning via the default server if no other address is given by the profile.
\item \textbf{Authentication Code}: The user is provided with an activation code (containing the \gls{smdpp} address and optional confirmation code) when purchasing service. The \gls{lpa} contacts the \gls{smdpp} and, after mutual authentication, may require entry of the confirmation code.
@@ -352,5 +399,7 @@ Next, the \gls{euicc} and \gls{smdpp} perform an \gls{ecka} to derive session ke
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.
\todo{Add sequence diagram which shows the rsp process}

26
Chapters/Discussion.tex
View File

@@ -40,8 +40,6 @@
% attacker positioned in between the LPA and the euicc via compromised LPA -> interception and manipulation of profile installation, delivery of rogue profiles, violation of the integrity of the profile provisioning pipeline
% these attack vectors can lead to a persistent compromise of the euicc
% mitigations for certificate reuse bug
% flush any cryptographic context on failed rsp session
% stricter session isolation
@@ -61,3 +59,27 @@
% add support for full loop rsp fuzzing i.e add own smdpp plus server with test certificate and test profiles -> full loop fuzzing of esim on sim implementations with test certificates i.e sysmoeuicc
% improve fuzzing strategies: currently only basic byte level fuzzing
% implement own software euicc and smdpp and add hypothesis rule based state machine support -> directly compare own implementation of smdpp server or euicc to actual behaviour with fuzzing input
The primary goal of this thesis was to assess the security posture and behavioral consistency of commercial eSIM-on-SIM products through differential testing. To this end, we developed a custom black-box testing framework capable of performing APDU-level fuzzing, structured \gls{asn1} mutation, and trace-based cross-device comparisons. Our evaluation was conducted on eight commercially available eSIM-on-SIM cards from three distinct vendors, revealing a diverse and fragmented implementation landscape.
Our findings indicate substantial architectural differences across implementations. For instance, some cards, such as the one from estk.me, omit the standard \gls{isdr} application altogether and instead expose functionality solely via the \gls{usat} interface. This approach also offers a privately hosted \gls{rlpa} server for provisioning \cite{estkme_rlpa-server_2025}, circumventing the \acposs{gsma} standardized infrastructure and raising questions regarding compliance and security. In contrast, other implementations (e.g., 5ber, Xesim, eSIM.me) do include \gls{isdr} support, but use vendor-specific \glspl{aid}, deviating from the default identifiers specified in SGP.22. These differences complicate interoperability and testing, while also highlighting the absence of a uniform baseline across implementations.
A key contribution of our work is the observation of divergent behaviors in response to identical \gls{rsp} inputs. Mutated \gls{asn1} payloads triggered undefined behavior in several cards, including silent failures, unexpected success responses, and inconsistent status words. In multiple instances, we observed malformed requests that bypassed expected validation routines, particularly during the certificate authentication phase. One notable case revealed a likely certificate validation bypass, where corrupted `AuthenticateServerRequest` messages were accepted despite invalid or tampered certificates. This suggests that parts of the certificate verification pipeline were either improperly implemented or incorrectly reused from prior sessions without sufficient integrity checks.
The implications of such inconsistencies are significant. Bypassing certificate validation undermines the trust model of the \gls{gsma} \gls{rsp} architecture, as the certificate chain rooted in the \gls{gsma} \gls{ca} can no longer be reliably enforced. An attacker able to craft malicious authentication messages, potentially by compromising or emulating an \gls{lpa}, could install rogue profiles onto the \gls{euicc}. While a valid \gls{gsma}-signed profile is still required, this opens the door for profile injection attacks, man-in-the-middle (MITM) provisioning manipulation, and potentially persistent compromise of the device. Previous research, such as that by \textref{lisowski_simurai_2024}, has demonstrated the feasibility of malicious \gls{sim} cards. However, their work focused on runtime behavior and not on provisioning vulnerabilities. Our findings extend this threat model by targeting the provisioning pipeline itself.
Several cards also revealed additional security concerns. One exposed undocumented endpoints for firmware updates that fall outside the \gls{gp} command set, suggesting the existence of non-standard, vendor-specific mechanisms for critical operations. The presence of undefined error states, typically in the form of generic status words (\eg, \texttt{6F00}) or generic Errors (\eg, \texttt{UndefinedError}), indicates insufficient internal error handling. In some cases, malformed inputs resulted in successful operations, pointing to either faulty \gls{asn1} decoding or logical flaws in the parsing routines.
The reproducibility of these findings across multiple cards supports the claim that profile management logic is often implemented in a non-standardized manner, despite the underlying reliance on common specifications such as SGP.21 and SGP.22. Unfortunately, due to the closed-source nature of the \gls{euicc} firmware, the lack of verbose error logging, and the absence of official debugging interfaces, root cause analysis remains difficult. This significantly hampers the ability to distinguish between benign vendor-specific variations and genuine security vulnerabilities.
In terms of research landscape, this thesis complements prior work that either focused on malicious runtime \gls{sim} behavior \cite{lisowski_simurai_2024} or employed formal methods to analyze the \gls{rsp} protocol \cite{ahmed_security_2024}. Unlike those approaches, our methodology provides empirical, implementation-level insights through the differential testing of live, commercial-grade eSIM-on-SIM products. Compared to existing tools such as SimTester~\cite{security_research_labs_simtester_2025}, which are tailored to legacy \gls{sim} cards and lack support for eSIM-specific features (e.g., \gls{isdr}, \gls{isdp}), our framework directly targets the modern provisioning stack.
While the results demonstrate the effectiveness of our framework, several limitations should be noted. First, our testing was confined to the SGP.21 and SGP.22 consumer specification. The newer \gls{iot}-centric specification, defined SGP.31 and SGP.32, were not evaluated due to a lack of publicly available \gls{iot}-targeted eSIM-on-SIM cards and the additional infrastructure they require. Second, although our fuzzing engine supports both structural and transport-level mutation, protocol coverage remains inherently bounded. Some branches in the protocol logic may not have been exercised. Additionally, our evaluation focused primarily on the \gls{euicc} side of the \gls{rsp} protocol. The \gls{smdpp} servers, which are integral to the provisioning process, were treated as opaque black boxes. Since most commercial \gls{smdpp} implementations are closed source and fuzzing them could be seen as a malicious \gls{dos} attack, they were mostly excluded from testing. The only publicly available implementation, osmo-smdpp, was not integrated due to scope limitations.
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.
\paragraph{Future Work}
Several directions for future research emerge from this work. First, the \gls{lpa} implementation could be extended to support SGP.31 and SGP.41 specific functionality, enabling testing of \gls{iot}-specific provisioning flows and factory provisioning procedures. 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. Finally, improvements to the fuzzing engine, such as incorporating a hypothesis rule based state machine, which would directly compare the fuzzing behaviour of a custom \gls{smdpp} server and \gls{euicc} implementation against propriatary ones.

54
Chapters/Evaluation.tex
View File

@@ -193,7 +193,7 @@ The same mutation strategies as shown in \cref{subsubsec:mutation_engine}, such
% limited to small subset of esim functionality due to usage of nonces for specific tasks
\section{Tracing}
\label{sec:tracing}
\label{sec:eval_tracing}
To investigate vendor-specific behaviors in \gls{rsp}, we employed SIMTrace2 to capture the \glspl{apdu} exchanged between the \gls{lpa} and the \gls{esim}. This enabled us to analyze the communication protocols used during profile management and \gls{euicc} interaction, especially focusing on the discovery and selection of the \gls{isdr}.
@@ -242,10 +242,10 @@ While tracing provides valuable insights into command sequencing and \gls{aid} s
Data fuzzing, as described in \cref{subsec:data_fuzzing}, was conducted on all tested \gls{esim} cards with the exception of \texttt{estk.me}. Each test case was executed sequentially across all eligible \glspl{esim} to ensure consistency and reproducibility of results.
The majority of the cards handled the fuzzed input data as expected, either processing the requests successfully or rejecting them gracefully with standard-compliant error responses. However, notable exceptions were observed during the execution of the \texttt{GetProfileInfo} test case, particularly for the following devices:
The majority of the cards handled the fuzzed input data as expected, either processing the requests successfully or rejecting them gracefully with standard-compliant error responses. However, notable exceptions were observed during the execution of the \texttt{GetProfileInfo} test case as shown in \cref{tab:data_fuzzing_result_part1} and \cref{tab:data_fuzzing_result_part2}, particularly for the following devices:
\begin{itemize}
\item 9esim
\item 9esim V2
\item 9esim v2
\item EIOTCLUB
\end{itemize}
@@ -266,25 +266,47 @@ The LED activity ceased only when the card reader was fully disconnected from th
\begin{table}[h!]
\centering
\caption{Data fuzzing results for each function per \gls{esim}}
\label{tab:data_fuzzing_result}
\begin{tabular}{lcccccc}
\caption{Data fuzzing results for 5ber, eSIM.me, and EIOTCLUB}
\label{tab:data_fuzzing_result_part1}
\begin{tabular}{lccc}
\toprule
\textbf{Function} & \textbf{5ber} & \textbf{eSIM.me} & \textbf{9esim} & \textbf{9esim v2} & \textbf{EIOTCLUB} & \textbf{Xesim} \\
\textbf{Function} & \textbf{5ber} & \textbf{eSIM.me} & \textbf{EIOTCLUB} \\
\midrule
SetDefaultDpAddress & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
EuiccMemoryReset & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
RetrieveNotificationsList & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
ListNotification & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
ProfileInfoList & \cmark & \cmark & \xmark & \xmark & \xmark & \cmark \\
SetNickname & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
PrepareDownload & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
AuthenticateServer & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
BoundProfilePackage & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
SetDefaultDpAddress & \cmark & \cmark & \cmark \\
EuiccMemoryReset & \cmark & \cmark & \cmark \\
RetrieveNotificationsList & \cmark & \cmark & \cmark \\
ListNotification & \cmark & \cmark & \cmark \\
ProfileInfoList & \cmark & \cmark & \xmark \\
SetNickname & \cmark & \cmark & \cmark \\
PrepareDownload & \cmark & \cmark & \cmark \\
AuthenticateServer & \cmark & \cmark & \cmark \\
BoundProfilePackage & \cmark & \cmark & \cmark \\
\bottomrule
\end{tabular}
\end{table}
\begin{table}[h!]
\centering
\caption{Data fuzzing results for 9esim, 9esim v2, and Xesim}
\label{tab:data_fuzzing_result_part2}
\begin{tabular}{lccc}
\toprule
\textbf{Function} & \textbf{9esim} & \textbf{9esim v2} & \textbf{Xesim} \\
\midrule
SetDefaultDpAddress & \cmark & \cmark & \cmark \\
EuiccMemoryReset & \cmark & \cmark & \cmark \\
RetrieveNotificationsList & \cmark & \cmark & \cmark \\
ListNotification & \cmark & \cmark & \cmark \\
ProfileInfoList & \xmark & \xmark & \cmark \\
SetNickname & \cmark & \cmark & \cmark \\
PrepareDownload & \cmark & \cmark & \cmark \\
AuthenticateServer & \cmark & \cmark & \cmark \\
BoundProfilePackage & \cmark & \cmark & \cmark \\
\bottomrule
\end{tabular}
\end{table}
% apdu fuzzing
% optimizing for coverage

54
Chapters/Implementation.tex
View File

@@ -33,7 +33,7 @@ The proposed method was to:
\begin{enumerate}
\item Record the \gls{apdu} traffic between the \gls{lpa} and the \gls{euicc} during an \gls{rsp} session.
\item Store this traffic in a structured format.
\item Replace the original \gls{euicc} with another one inserted into a \gls{pcsc}-compatible card reader.
\item Replace the original \gls{euicc} with another one inserted into a PC/SC-compatible card reader.
\item Replay each recorded \gls{apdu} and monitor the response.
\end{enumerate}
@@ -48,7 +48,7 @@ The goal was to detect behavioral differences, such as differing \glspl{sw} or e
\item A custom \gls{lpa} allows for controlled mutation and injection of \gls{apdu} sequences.
\end{itemize}
The implemented \gls{lpa} performs a target operation (e.g., profile download or enablement) by issuing the appropriate command sequence to the \gls{euicc} in the \gls{pcsc} card reader. Before sending, \glspl{apdu} can be programmatically mutated to evaluate robustness of the implementation against malformed or unexpected inputs. The \gls{lpa} records returned status words and checks for behavioral consistency across different \glspl{euicc}.
The implemented \gls{lpa} performs a target operation (e.g., profile download or enablement) by issuing the appropriate command sequence to the \gls{euicc} in the PC/SC card reader. Before sending, \glspl{apdu} can be programmatically mutated to evaluate robustness of the implementation against malformed or unexpected inputs. The \gls{lpa} records returned status words and checks for behavioral consistency across different \glspl{euicc}.
While this approach allows for a more precise control, it has some drawbacks. \gls{rsp} is a stateful protocol, and provisioning actions rely on interaction with the profile vendor's \gls{smdpp} server. Consequently, execution speed is constrained by network latency and backend responsiveness as well as restoring the \gls{euicc} state after a reset.
@@ -89,7 +89,7 @@ The tracing functionality comprises two main operations:
\begin{itemize}
\item \textbf{Tracing and recording:} Captures \glspl{apdu} traffic from a physical interface using \texttt{simtrace2}~\cite{osmocom_simtrace_nodate} and associates it with functional interpretations (e.g., profile enablement, deletion). The \glspl{apdu} are parsed and stored along with contextual information such as sender and receiver addresses.
\item \textbf{Replaying:} Replays previously recorded \glspl{apdu} sequences to an \gls{euicc} in a \gls{pcsc} card reader. It replaces context-specific identifiers and checks for discrepancies in response behavior.
\item \textbf{Replaying:} Replays previously recorded \glspl{apdu} sequences to an \gls{euicc} in a PC/SC card reader. It replaces context-specific identifiers and checks for discrepancies in response behavior.
\end{itemize}
\begin{figure}[h!]
@@ -101,13 +101,13 @@ The tracing functionality comprises two main operations:
The implementation consists of several key components:
\begin{description}
\item[\texttt{PcscLink}] A thin wrapper over the Python \texttt{pyscard} library~\cite{rousseau_pyscard_2025}, which abstracts away low-level communication with \gls{pcsc}-compatible card readers. It handles session establishment, \glspl{apdu}/\gls{tpdu} transmission, and automatic processing of status words such as \texttt{61XX} (i.e., triggering \texttt{GET RESPONSE} when necessary).
\item[\texttt{PcscLink}] A thin wrapper over the Python \texttt{pyscard} library~\cite{rousseau_pyscard_2025}, which abstracts away low-level communication with PC/SC-compatible card readers. It handles session establishment, \glspl{apdu}/\gls{tpdu} transmission, and automatic processing of status words such as \texttt{61XX} (i.e., triggering \texttt{GET RESPONSE} when necessary).
\item[\texttt{Card}] Represents a connected card in a \gls{pcsc} reader. It queries the card to determine its type (e.g., standard \gls{sim}, test \gls{euicc}, or commercial \gls{euicc}), and identifies installed applications such as \texttt{\gls{isdr}} or \texttt{\gls{ecasd}}. The class serves as the interface for sending \glspl{apdu} to the card through the \texttt{pcsc\_link}.
\item[\texttt{Card}] Represents a connected card in a PC/SC reader. It queries the card to determine its type (e.g., standard \gls{sim}, test \gls{euicc}, or commercial \gls{euicc}), and identifies installed applications such as \texttt{\gls{isdr}} or \texttt{\gls{ecasd}}. The class serves as the interface for sending \glspl{apdu} to the card through the \texttt{pcsc\_link}.
\item[\texttt{Tracer}] A dummy implementation of the \texttt{Card} interface used during passive tracing. It parses incoming \glspl{apdu} from the \gls{gsmtap} interface using \texttt{pysim} and attempts to classify them based on instruction type. This allows mapping observed \glspl{apdu} to functional operations.
\item[\texttt{Tracer}] A dummy implementation of the \texttt{Card} interface used during passive tracing. It parses incoming \glspl{apdu} from the GSMTAP interface using \texttt{pysim} and attempts to classify them based on instruction type. This allows mapping observed \glspl{apdu} to functional operations.
\item[\texttt{Recorder}] Coordinates tracing and recording. It spawns a separate tracer thread that listens for \glspl{apdu} from \gls{gsmtap} in a loop until a timeout occurs or a stop signal is issued. \glspl{apdu} are recorded alongside the designated target \texttt{\gls{isdr}} for later analysis.
\item[\texttt{Recorder}] Coordinates tracing and recording. It spawns a separate tracer thread that listens for \glspl{apdu} from GSMTAP in a loop until a timeout occurs or a stop signal is issued. \glspl{apdu} are recorded alongside the designated target \texttt{\gls{isdr}} for later analysis.
\item[\texttt{recording}] An abstraction for a recorded session. It stores the list of \glspl{apdu}, associated source and target \texttt{\gls{isdr}} addresses, and metadata. It provides serialization functions for saving to and loading from disk, as well as validity checks to determine whether a recording is replayable.
@@ -189,15 +189,15 @@ This modular structure allows for easy integration into both automated test pipe
% before returning the data to the caller -> client checks for error on server and eventually raises the corresponding exception -> as explained in the exception handling part
% smdp+ client is mostly used by the isd-r
Due to the limitations of the \texttt{tracer} implementation in correctly replaying \gls{rsp} interactions, a dedicated \gls{lpa} implementation was developed to initiate valid interactions with the \gls{euicc}. This enables the controlled generation and mutation of valid traffic which we will further explain in \cref{sec:fuzzing}. Our implementation targets the \gls{sgp22} v3.1 specification, which was the latest version available at the time of writing.
Due to the limitations of the \texttt{tracer} implementation in correctly replaying \gls{rsp} interactions, a dedicated \gls{lpa} implementation was developed to initiate valid interactions with the \gls{euicc}. This enables the controlled generation and mutation of valid traffic which we will further explain in \cref{sec:fuzzing}. Our implementation targets the SGP.22 v3.1 specification, which was the latest version available at the time of writing \cite{gsma_sgp22_2025}.
The \gls{lpa} is composed of multiple components:
\paragraph{Card}
Represents the \gls{euicc} currently inserted into the \gls{pcsc} card reader. Upon initialization, it scans the card for supported applications, identifying the applicable \gls{adf} through probing. This is necessary as eSIM-on-SIM implementations often use proprietary \glspl{adf}, diverging from the \glspl{adf} specified in the \gls{sgp22} standard. The card object keeps track of the selected application to reduce unnecessary reselection and traffic.
Represents the \gls{euicc} currently inserted into the PC/SC card reader. Upon initialization, it scans the card for supported applications, identifying the applicable \gls{adf} through probing. This is necessary as eSIM-on-SIM implementations often use proprietary \glspl{adf}, diverging from the \glspl{adf} specified in the SGP.22 standard as we will evaluate in \cref{sec:eval_tracing}. The card object keeps track of the selected application to reduce unnecessary reselection and traffic.
\paragraph{PC/SC Link}
This component is based on \texttt{pySim}'s \texttt{LinkBaseTpdu}. It establishes an exclusive connection to the \gls{pcsc} reader to maintain session state consistency, which is required due to the stateful nature of \gls{euicc} interactions. During initialization:
This component is based on \texttt{pySim}'s \texttt{LinkBaseTpdu}. It establishes an exclusive connection to the PC/SC reader to maintain session state consistency, which is required due to the stateful nature of \gls{euicc} interactions. During initialization:
\begin{itemize}
\item The supported transmission protocol (T=0 or T=1) is detected.
\item A connection is established and validated.
@@ -213,17 +213,17 @@ Known \glspl{adf} for \gls{isdr} observed during analysis:
\item 5Ber.esim: \texttt{A0000005591010FFFFFFFF8900050500}
\item Xesim: \texttt{A0000005591010FFFFFFFF8900000177}
\item esim.me: \texttt{A0000005591010000000008900000300}
\end{itemize}as
\end{itemize}
The decoded response data is further processed using \texttt{pydantic} data classes. These enable structured parsing of values including Base64-encoded strings, bitfields, version types, and more. Custom encoders/decoders are used to simplify readability and downstream data processing. For bit fields, a mixin is used to allow checking for specific feature flags via simple accessors.
The decoded response data is further processed using \texttt{pydantic} data classes. \texttt{pydantic} is a python library that enable structured parsing of values including Base64-encoded strings, bitfields, version types, and more. Custom encoders/decoders are used to simplify readability and downstream data processing. For bit fields, a mixin is used to allow checking for specific feature flags via simple accessors.
The \texttt{estk\_fwupd} application implements a proprietary firmware update interface, which was reverse-engineered (see \cref{sec:findings}). It supports reading the current firmware version, unlocking\footnote{This unlocking is distinct from \gls{gp}-defined unlocking, which allows the execution of generic \gls{gp} commands. See \gls{gp} Card Specification.} the \gls{euicc} for updates, and installing new binaries.
\paragraph{Exception Handling}
The \gls{sgp22} standard defines a variety of response codes and error conditions. The \gls{lpa} library maps these response codes to custom exception classes for precise error handling. This is essential for both debugging and for the differential testing framework to reason about diverging behavior across implementations. A code listing of the exception handling mappings is provided in \cref{sec:exception-handling}.
The SGP.22 standard defines a variety of response codes and error conditions. The \gls{lpa} library maps these response codes to custom exception classes for precise error handling. This is essential for both debugging and for the differential testing framework to reason about diverging behavior across implementations. A code listing of the exception handling mappings is provided in \cref{sec:exception-handling}.
\paragraph{SM-DP+ Client}
In addition to \gls{euicc} communication, the \gls{lpa} must interact with the \gls{smdpp} server via the ES9+ interface. Our implementation uses \texttt{httpx} for HTTP interactions and adheres to the expected headers and structure as defined by \gls{sgp22}:
In addition to \gls{euicc} communication, the \gls{lpa} must interact with the \gls{smdpp} server via the ES9+ interface. Our implementation uses \texttt{httpx} for HTTP interactions and adheres to the expected headers and structure as defined by SGP.22:
\begin{lstlisting}[language=json,caption={ES9+ Request Headers}]
{
"Content-Type": "application/json",
@@ -322,15 +322,17 @@ To uncover behavioral differences between \gls{euicc} implementations, we implem
\subsubsection*{Fuzzing Scenarios and Execution}
Fuzzing is conducted through predefined \emph{scenarios}—sequences of function calls that operate on the \gls{euicc}. Each function in a scenario interacts with the \gls{euicc} through the \gls{lpa} and is subject to mutation. The scenario runner initiates a fresh \gls{pcsc} link, resets the card into a clean state (processing all notifications and performing a full memory reset), and executes each function with multiple mutations.
Fuzzing is conducted through predefined \emph{scenarios}—sequences of function calls that operate on the \gls{euicc}. Each function in a scenario interacts with the \gls{euicc} through the \gls{lpa} and is subject to mutation. The scenario runner initiates a fresh PC/SC link, resets the card into a clean state (processing all notifications and performing a full memory reset) using our \gls{lpa} implementation, and executes each function with multiple mutations.
This process is guided by an \textbf{operation recorder} that tracks each function call, applied mutations, and resulting responses in a structured \emph{mutation tree}. Each tree node represents a specific function call executed with one type of mutation. A tree level corresponds to a function in the scenario; sibling nodes represent different mutations of that function.
This process is guided by an \textbf{operation recorder} that tracks each function call, applied mutations, and resulting responses in a structured \emph{mutation tree}. Each tree node represents a specific function call executed with one type of mutation. A tree level corresponds to a function in the scenario and sibling nodes represent different mutations of that function.
\subsubsection*{Mutation Engine}
\label{subsubsec:mutation_engine}
The mutation engine supports both \textit{deterministic} and \textit{random} mutation modes, and implements the following strategies:
\todo{Go into more detail on how the muations are performed}
\begin{itemize}
\item \textbf{Bit flip:} Flips a fixed number of bits based on mutation rate and payload length.
\item \textbf{Random byte:} Swaps random byte positions.
@@ -339,7 +341,7 @@ The mutation engine supports both \textit{deterministic} and \textit{random} mut
\item \textbf{Truncate:} Removes the tail of the \gls{apdu}.
\end{itemize}
Deterministic mode ensures reproducibility by always mutating the same offset, while the random mode selects targets dynamically. This allows us to explore both fixed and variable fuzzing behavior. Both modes behave similar to the deterministic and non-deterministic mutation modes used in AFLPlusPlus.
Deterministic mode ensures reproducibility by always mutating the same offset, while the random mode selects targets dynamically. This allows us to explore both fixed and variable fuzzing behavior. Both modes behave similar to the deterministic and non-deterministic mutation modes used in AFLPlusPlus~\cite{fioraldi_afl_2020}.
\subsubsection*{Fuzzing Workflow}
@@ -347,7 +349,7 @@ The \gls{apdu} fuzzing workflow is illustrated in \cref{fig:scenario_flow} and p
\begin{enumerate}
\item \textbf{Mutation selection:} The operation recorder decides the next mutation to apply based on a depth-first traversal of the mutation tree. If all mutations for the current function are exhausted, the runner searches for unexplored child nodes.
\item \textbf{\gls{apdu} mutation:} The selected mutation is applied to the original APDU using the mutation engine.
\item \textbf{\gls{apdu} mutation:} The selected mutation is applied to the original \gls{apdu} using the mutation engine.
\item \textbf{\gls{apdu} transmission:} The mutated \gls{apdu} is sent to the card. Success or failure is recorded in the current node.
\item \textbf{Recording:} The response (or exception) is saved to the mutation tree node for further analysis.
\end{enumerate}
@@ -406,7 +408,7 @@ This strategy is both exhaustive and progress-aware. It ensures that:
\subsubsection*{Error Handling and Retry Logic}
Errors during execution are logged and associated with the current mutation node. If a function fails (e.g., due to protocol state loss or card reset), the runner resets the \gls{pcsc} link and the card, then resumes execution. This ensures that failures do not corrupt the mutation tree and allows exploration to continue.
Errors during execution are logged and associated with the current mutation node. If a function fails (e.g., due to protocol state loss or card reset), the runner resets the PC/SC link and the card, then resumes execution. This ensures that failures do not corrupt the mutation tree and allows exploration to continue.
\subsubsection*{Scenario Persistence and Reuse}
@@ -508,7 +510,7 @@ To address this limitation, we introduce a complementary \textit{data fuzzing} a
\paragraph{Fuzzing with Hypothesis}
Hypothesis is a property-based testing framework, which allows developers to define \textit{strategies} for input data. The framework then generates test cases based on these strategies and attempts to explore edge cases through randomized sampling and shrinking. Unlike traditional random fuzzing, Hypothesis ensures that generated inputs conform to the structural invariants defined by the strategy, thereby increasing the likelihood of discovering subtle logic errors in protocol handling.
Hypothesis integrates seamlessly with \texttt{pytest} and uses the \texttt{@given} decorator to specify input generation strategies. For example, given the \gls{asn1} structure defined in the \gls{sgp22} specification for the \texttt{GetProfileInfo} function:
Hypothesis integrates seamlessly with \texttt{pytest} and uses the \texttt{@given} decorator to specify input generation strategies. For example, given the \gls{asn1} structure defined in the SGP.22 specification for the \texttt{GetProfileInfo} function:
\begin{lstlisting}[caption={ASN.1 definition of the ProfileInfoListRequest}]
ProfileInfoListRequest ::= [45] SEQUENCE {
@@ -557,10 +559,10 @@ Specifically, we implemented fuzzing tests for the following functions:
\end{itemize}
\paragraph{Fuzzing Lifecycle}
Each fuzzing test class is executed under a shared fixture. During the \texttt{setUpClass} phase, a \gls{pcsc} link is initialized, and the \gls{euicc} is prepared (e.g., by installing a test profile) to ensure the preconditions for each function are met. After executing the class's test suite, the \texttt{eUICCMemoryReset} function is called with all reset options enabled to restore a clean state. All leftover notifications are processed to leave the card in a consistent state for subsequent tests.
Each fuzzing test class is executed under a shared fixture. During the \texttt{setUpClass} phase, a PC/SC link is initialized, and the \gls{euicc} is prepared (e.g., by installing a test profile) to ensure the preconditions for each function are met. After executing the class's test suite, the \texttt{eUICCMemoryReset} function is called with all reset options enabled to restore a clean state. All leftover notifications are processed to leave the card in a consistent state for subsequent tests.
\paragraph{Error Classification}
According to the \gls{sgp22} specification, many functions may return a generic \texttt{UndefinedError} in response to unexpected or malformed input. In our implementation, exceptions raised by the \gls{euicc} that map to well-defined error codes (i.e., subclasses of \texttt{EuiccException}) are not treated as test failures. These represent handled errors indicating that the input was invalid but the card responded appropriately.
According to the SGP.22 specification, many functions may return a generic \texttt{UndefinedError} in response to unexpected or malformed input. In our implementation, exceptions raised by the \gls{euicc} that map to well-defined error codes (i.e., subclasses of \texttt{EuiccException}) are not treated as test failures. These represent handled errors indicating that the input was invalid but the card responded appropriately.
By contrast, when an \texttt{UndefinedError} is returned, we treat this as a potential indicator of an unhandled internal error or inconsistent implementation behavior. These cases are flagged for further investigation. Additionally, exceptions occurring outside the \gls{euicc}, such as Python \texttt{AssertionError}s or test harness failures, are treated as bugs in the testing infrastructure and are logged separately.
@@ -593,7 +595,7 @@ By combining property-based data generation with structural knowledge of \gls{as
% completly independet from library -> library does not depend on cli
While the implemented library provides a programmatic interface to the \gls{lpa} and \gls{euicc} operations, many users—especially testers and engineers—require a more accessible method for interacting with the system. For this reason, we provide a fully-featured \gls{cli} that exposes all major functionalities of the system, including \gls{apdu} tracing, \gls{lpa} operations, and fuzzing workflows.
While the implemented library provides a programmatic interface to the \gls{lpa} and \gls{euicc} operations, many users, especially testers and engineers, require a more accessible method for interacting with the system. For this reason, we provide a fully-featured \gls{cli} that exposes all major functionalities of the system, including \gls{apdu} tracing, \gls{lpa} operations, and fuzzing workflows.
The \gls{cli} is built using Python’s standard \texttt{argparse} module for argument parsing, extended with \texttt{argcomplete} to enable shell auto-completion. For improved readability and formatting of terminal output, the \texttt{rich} library is used. This combination allows for an interactive, user-friendly \gls{cli} with both developer ergonomics and production readiness in mind.
@@ -602,10 +604,10 @@ The CLI is organized around three core commands:
\begin{itemize}
\item \textbf{tracing} — Interfaces with the \texttt{simtrace2} device and the \gls{lpa} to capture \gls{apdu} traffic in real time. This functionality is discussed in detail in \cref{sec:tracing}.
\item \textbf{lpa} — Exposes \gls{euicc} communication features such as profile management, notification handling, and remote procedure execution via the \gls{cli}.
\item \textbf{fuzzing} — Wraps both \gls{apdu}-level and data-level fuzzing. Additionally, it provides a \texttt{compare} command to compare multiple trace recordings and highlight structural differences in \gls{json} format.
\item \textbf{fuzzing} — Wraps both \gls{apdu}-level and data-level fuzzing. Additionally, it provides a \texttt{compare} command to compare multiple trace recordings and highlight structural differences in JSON format.
\end{itemize}
Each of these commands is implemented in its respective subfolder (e.g., \texttt{tracing/}, \texttt{lpa/}, \texttt{fuzz/}). The modular structure of the \gls{cli} is shown in Figure~\ref{fig:cli_structure}, which illustrates how the subcommands map to the file and folder hierarchy of the project.
Each of these commands is implemented in its respective subfolder (e.g., \texttt{tracing/}, \texttt{lpa/}, \texttt{fuzz/}). The modular structure of the \gls{cli} is shown in \cref{fig:cli_structure}, which illustrates how the subcommands map to the file and folder hierarchy of the project.
\begin{figure}[h]
\centering
@@ -653,7 +655,7 @@ Each of these commands is implemented in its respective subfolder (e.g., \texttt
]
]
\end{forest}
\caption{CLI folder structure and modular separation of functionality}
\caption{\gls{cli} folder structure and modular separation of functionality}
\label{fig:cli_structure}
\end{figure}

2
Chapters/Introduction.tex
View File

@@ -57,7 +57,7 @@ Despite the \gls{esim} architecture being built with security in mind and standa
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.
Furthermore, given the relative novelty of the consumer \gls{esim} ecosystem, the first SGP.21 release only dating back to 2015 and the latest version (v3.1) being released in 2025, the technology is still evolving. Different vendors may interpret and implement the specifications in slightly different ways, leading to inconsistencies and potentially exploitable gaps.
Furthermore, given the relative novelty of the consumer \gls{esim} ecosystem, the first SGP.21 release only dating back to 2015~\cite{gsma_sgp21_2015} and the latest version (v3.1) being released in 2025~\cite{gsma_sgp22_2025}, the technology is still evolving. Different vendors may interpret and implement the specifications in slightly different ways, leading to inconsistencies and potentially exploitable gaps.
Due to the lack of transparency in vendor implementations, black-box testing methodologies are especially valuable for uncovering such issues. Differential testing is a promising approach: it systematically compares how different implementations behave when subjected to identical or similar inputs. This makes it possible to detect deviations and identify bugs without needing source code or internal documentation.

16
Chapters/RelatedWork.tex
View File

@@ -36,13 +36,13 @@ The ecosystem surrounding \gls{esim} and \gls{euicc} technology is supported by
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~\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.
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 \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_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_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 \gls{sptp}, a protocol designed to enhance transparency and trust in the provisioning process.
\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.
\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.
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 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.
\section{Software Implementations}
@@ -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 \gls{sgp22} \gls{smdpp} server component. Notably, \texttt{pySim} does not implement the full \gls{sgp22} protocol stack on the client side (i.e., communication between the \gls{euicc} and the \gls{smdpp} server); its \gls{sgp22} 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 (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.
@@ -102,11 +102,11 @@ Overall, \texttt{SIMtrace2} is a versatile tool both for passive analysis and ac
% - 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.
\texttt{lpac} is a C-based implementation of the \gls{lpa} defined in the SGP.22, 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.
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.
\paragraph{SIMTester}
@@ -121,5 +121,5 @@ However, \texttt{lpac} only supports \gls{sgp22} version 2.2.2, whereas the most
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.
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 SGP.22 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.