mirror of
https://sharelatex.tu-darmstadt.de/git/681e0e7a3a9c7c9c6b8bb298
synced 2025-12-07 13:18:00 +00:00
Update on Overleaf.
This commit is contained in:
nb72soza Bittner
@@ -229,16 +229,20 @@ DFs serve as containers that enable functional grouping of files. A special clas
|
||||
|
||||
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 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.
|
||||
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 \glspl{aid} proposed by the \gls{gsma} and \gls{gp} include the \gls{isdr} application and the \gls{aram} application.
|
||||
\paragraph{Application Toolkit}
|
||||
|
||||
\begin{itemize}
|
||||
\item \gls{isdr} \texttt{A0000005591010FFFFFFFF8900000100}
|
||||
\item \gls{aram} \texttt{A00000015141434C00}
|
||||
\end{itemize}
|
||||
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. \gls{cat} functionalities are typically made available to end-users through standardized applications, known as \gls{sim} Toolkit apps that preinstalled on many mobile devices. These applications expose a menu-driven interface as shown in \cref{img:cat_interface}, that allows direct interaction with the \gls{esim} functionality embedded in the card, without requiring any additional software or manufacturer-specific \glspl{lpa}. However, the amount of functionality provided over such interfaces still depends on the manufacturer and the implementation.
|
||||
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 and cannot be facilitated through the \gls{cat} interface.
|
||||
|
||||
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}.
|
||||
\begin{figure}[t]
|
||||
\centering
|
||||
\includegraphics[width=.45\textwidth]{Graphics/cat_9esimv2_cardinfo.jpg}
|
||||
\includegraphics[width=.45\textwidth]{Graphics/cat_9esimv2_profile_info.jpg}
|
||||
\caption{\gls{cat} interfaces of the 9esim v2 card showing the card and profile info.}
|
||||
\label{img:cat_interface}
|
||||
\end{figure}
|
||||
|
||||
\section{Embedded SIM}
|
||||
\label{sec:esim}
|
||||
@@ -252,7 +256,7 @@ The concept of the \gls{esim} is based on the \gls{euicc}, which replaces the tr
|
||||
|
||||
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}.
|
||||
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} as shown in \cref{img:rsp_architecture}.
|
||||
|
||||
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.
|
||||
|
||||
@@ -269,7 +273,7 @@ This architecture introduces a remote provisioning mechanism and significantly e
|
||||
% - 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
|
||||
|
||||
\begin{figure}[h!]
|
||||
\begin{figure}[t]
|
||||
\includegraphics[width=\textwidth]{Graphics/euicc_architecture.png}
|
||||
\caption{\gls{euicc} architecture~\cite{gsma_sgp22_2024}.}
|
||||
\label{img:euicc_architecture}
|
||||
@@ -287,6 +291,15 @@ The \gls{aram}, as specified by \gls{gp} \cite{globalplatform_secure_2024}, gove
|
||||
|
||||
Together, these components establish the trust and management architecture necessary for secure and scalable remote SIM provisioning.
|
||||
|
||||
These applications are typically addressed via their \glspl{aid}, some of which are standardized by the \gls{gsma} and \gls{gp} to ensure interoperability across implementations, others are defined by the \gls{mno}. Standardized \glspl{aid} allow external entities, such as the \gls{lpa}, to reliably identify and interact with specific applications on the card.
|
||||
|
||||
\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:eval_tracing}.
|
||||
|
||||
\paragraph{eSIM-on-SIM}
|
||||
|
||||
% - most popular option of integrating esims is directly soldering them onto the cricuit board of a smartphone
|
||||
@@ -312,7 +325,7 @@ In many modern devices, the most common integration of an \gls{esim} is as a sol
|
||||
\paragraph{Local Profile Assistant}
|
||||
\label{par:lpa}
|
||||
|
||||
\begin{figure}[h!]
|
||||
\begin{figure}[t]
|
||||
\centering
|
||||
\includegraphics[width=.32\textwidth]{Graphics/lpa_easyeuicc.jpg}
|
||||
\includegraphics[width=.32\textwidth]{Graphics/lpa_9esim.jpg}
|
||||
@@ -323,7 +336,7 @@ In many modern devices, the most common integration of an \gls{esim} is as a sol
|
||||
|
||||
The \gls{lpa} is a user-facing application (i.e an App on a smartphone) on the \gls{ue} that interacts with the \gls{euicc}, enabling users to initiate profile provisioning and perform lifecycle management operations such as enabling, disabling, or deleting profiles. \cref{img:lpa_interfaces} shows 3 different \gls{lpa} implementions that enable such functionality. The \gls{smdpp} is a server—operated by an \gls{euicc} manufacturer, \gls{mno}, or third party, that securely hosts \gls{esim} profiles and makes them available for download. The \gls{smds} facilitates the "push" provisioning approach, where the operator notifies the \gls{lpa} via the \gls{smds} that an profile is ready download. The \gls{lpa} then downloads and installs this profile from the \gls{smdpp} server onto the \gls{euicc} with the information provided by the \gls{smds}. This approach is less common in consumer scenarios.
|
||||
|
||||
\begin{figure}[h!]
|
||||
\begin{figure}[t]
|
||||
\includegraphics[width=\textwidth]{Graphics/rsp_architecture.png}
|
||||
\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}
|
||||
@@ -333,19 +346,6 @@ The \gls{lpa} is a user-facing application (i.e an App on a smartphone) on the \
|
||||
(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 \gls{etsi} TS 102 223~\cite{etsi_ts_2014}, provides a proactive command framework for on-card applications. \gls{cat} functionalities are typically made available to end-users through standardized applications, known as \gls{sim} Toolkit apps that preinstalled on many mobile devices. These applications expose a menu-driven interface as shown in \cref{img:cat_interface}, that allows direct interaction with the \gls{esim} functionality embedded in the card, without requiring any additional software or manufacturer-specific \glspl{lpa}. However, the amount of functionality provided over such interfaces still depends on the manufacturer and the implementation.
|
||||
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 and cannot be facilitated through the \gls{cat} interface.
|
||||
|
||||
\begin{figure}[h!]
|
||||
\centering
|
||||
\includegraphics[width=.45\textwidth]{Graphics/cat_9esimv2_cardinfo.jpg}
|
||||
\includegraphics[width=.45\textwidth]{Graphics/cat_9esimv2_profile_info.jpg}
|
||||
\caption{\gls{cat} interfaces of the 9esim v2 card showing the card and profile info.}
|
||||
\label{img:cat_interface}
|
||||
\end{figure}
|
||||
|
||||
|
||||
|
||||
\section{Remote SIM Provisioning}
|
||||
@@ -406,14 +406,16 @@ In this work, we focus on the Authentication Code method due to its prevalence i
|
||||
|
||||
\textcite{ahmed_security_2024} packages the \gls{rsp} into four major steps: mutual authentication, profile binding, profile download (including authenticated key exchange), and notification.
|
||||
|
||||
\begin{figure}[h!]
|
||||
\begin{figure}[t]
|
||||
\begin{adjustwidth}{-1.5in}{-.5in}
|
||||
\centering
|
||||
\includesvg[width=1.3\textwidth]{Graphics/mutual_authentication_sd.svg}
|
||||
\caption{Sequence diagram of the mutual authentication.\cite{ahmed_security_2024}}
|
||||
\label{fig:mutual_authentication}
|
||||
\end{adjustwidth}
|
||||
\end{figure}
|
||||
|
||||
\begin{table}[h!]
|
||||
\begin{table}[t]
|
||||
\centering
|
||||
\caption{Notation for mutual authentication sequence diagram as introduced by \textcite{ahmed_security_2024}}
|
||||
\label{tab:notiation}
|
||||
|
||||
@@ -17,6 +17,7 @@
|
||||
The primary objective of this evaluation is to apply differential testing to analyze the behavior and potential security implications of various commercial eSIM on SIM solutions. This methodology aims to uncover inconsistencies, implementation deviations, and potential vulnerabilities by observing how different cards react to the same input sequences under controlled conditions.
|
||||
To conduct a thorough and representative evaluation, we selected a diverse set of eSIM-on-SIM cards from multiple vendors. In total, \textbf{eight} different cards were included in the analysis, as shown in Table~\ref{tab:esim-overview}. These cards vary in terms of manufacturer, supported features, and firmware versions. The tests were conducted using the tracing, mutation, and fuzzing infrastructure described in \cref{ch:implementation}.
|
||||
|
||||
\todo{List Hardware specs}
|
||||
|
||||
\begin{table}[ht]
|
||||
\centering
|
||||
@@ -41,7 +42,7 @@ To conduct a thorough and representative evaluation, we selected a diverse set o
|
||||
|
||||
Among the tested cards, the \textbf{sysmoEUICC} is loaded with a \gls{gsma} test certificate, allowing it to interact with the official \gls{smdpp} test server infrastructure. This certificate is publicly available and enables the evaluation of remote profile management procedures in a realistic but controlled environment. The firmware implementation of the sysmoEUICC is assumed to be functionally equivalent to production-grade \glspl{esim}. However, this restricts use to use Profiles which are also signed by the \gls{gsma} test certificate.
|
||||
|
||||
In contrast, \textbf{estk.me} does not expose an \gls{isdr} for \gls{lpa}-based interaction, limiting the scope of evaluation for that platform. As such, only \gls{usat}-based interaction was possible, and no \gls{rsp}-related operations via the implemented testing framework could be performed.
|
||||
In contrast, \textbf{estk.me} does not expose an \gls{isdr} for \gls{lpa}-based interaction, limiting the scope of evaluation for that platform. As such, only \gls{usat}-based interaction was possible, and no \gls{rsp}-related operations via the implemented testing framework could be performed. \todo{Check how estk.me implements rsp -> maybe rlpa etc}
|
||||
|
||||
The \textbf{9esim v2} card, in comparison, fully supports both \gls{isdr} access and \gls{usat} communication. Although \gls{usat} interfaces were excluded from evaluation for this particular card due to it not being supported by the testing framwork.
|
||||
|
||||
@@ -164,6 +165,7 @@ The firmware image accompanying the update utility appears to be encrypted or ob
|
||||
\end{axis}
|
||||
\end{tikzpicture}
|
||||
\caption{Shannon entropy values across blocks for three different firmware versions.}
|
||||
\todo{Start with block 0, explain drop off at 200}
|
||||
\end{figure}
|
||||
|
||||
A deeper static analysis using Ghidra~\cite{nsa_ghidra_2025} did not reveal any recognizable structure or file headers, further supporting the assumption of encryption. Similarly, tools like Binwalk~\cite{refirmlabs_binwalk_2025} did not detect known compression schemes, embedded file systems, or file signatures. Consequently, firmware payload analysis could not be meaningfully performed beyond block-level transmission.
|
||||
@@ -194,7 +196,7 @@ The update process proceeds as follows:
|
||||
\begin{itemize}
|
||||
\item Firmware is divided into blocks of size \texttt{0x80D} bytes.
|
||||
\item Each block is sent in subchunks, using standard \glspl{apdu} (\texttt{CLA=0xAA}) with \texttt{INS=0x11}.
|
||||
\item After transmission, the same chunk is re-sent with \texttt{INS=0x12}, no payload, and the expected response length (\texttt{Le}) matches the chunk size.
|
||||
\item After transmission, the same chunk is re-sent with \texttt{INS=0x12}, no payload, and the expected response length (\texttt{Le}) matching the original chunk size. This verification step is performed to ensure that the chunk was transmitted and received correctly, \ie, the \gls{euicc} confirms that the length of the previously received payload matches the expected length. We assume that the \gls{euicc} performs an internal consistency check between the declared length and the actual received bytes to validate chunk integrity.
|
||||
\end{itemize}
|
||||
\item \textbf{Check Flash Status}: The \gls{apdu} \texttt{AA13000000} is used to verify correct flash writing.
|
||||
\item \textbf{Finalize}: The \gls{apdu} \texttt{AA00000000} marks the end of the update process.
|
||||
@@ -206,7 +208,7 @@ The update tool fails gracefully only under specific conditions. For malformed o
|
||||
|
||||
Using insights gained from disassembly in Ghidra, a Python-based reimplementation of the update mechanism was developed and available via the \gls{cli} as shown in \cref{sec:cli}. This allowed fine-grained control over the update process and enabled targeted mutation-based testing of firmware blocks.
|
||||
|
||||
The same mutation strategies as shown in \cref{subsubsec:mutation_engine}, such as bit flipping, byte shuffling, truncation, and others, were applied to the firmware blocks on a per-chunk basis during both initial transmission and block validation. Notably, mutated blocks were generally accepted until the \texttt{check\_flash\_status} step, where the \gls{euicc} would immediately terminate the connection. This behavior strongly suggests that the device internally verifies each block against a checksum or hash.
|
||||
The same mutation strategies as shown in \cref{subsubsec:mutation_engine}, such as bit flipping, byte shuffling, truncation, and others, were applied to the firmware blocks on a per-chunk basis during both initial transmission and block validation. Notably, mutated blocks were generally accepted until the \texttt{check\_flash\_status} step, where the \gls{euicc} would immediately terminate the connection. This behavior strongly suggests that the device internally verifies each block against a checksum, hash or cryptographic signature.
|
||||
|
||||
|
||||
|
||||
@@ -234,11 +236,11 @@ The same mutation strategies as shown in \cref{subsubsec:mutation_engine}, such
|
||||
\section{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}.
|
||||
To investigate vendor-specific behaviors in \gls{rsp}, we employed SIMTrace2 to capture the \glspl{apdu} exchanged between the \gls{lpa} running on a phone 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}.
|
||||
|
||||
During the analysis of the \texttt{eSIM.me} eSIM, we observed the use of a custom \gls{aid} during the SELECT command for \gls{isdr}. The following listing illustrates a sample trace captured while launching the \texttt{esim.me} Android application:
|
||||
|
||||
\begin{lstlisting}[style=logstyle, escapeinside={(*}{*)}, caption={Traced APDUs when launching the esim.me App}]
|
||||
\begin{lstlisting}[style=logstyle, escapeinside={(*}{*)}, caption={Traced APDUs when launching the esim.me App. Captured commands are executed by the esim.me App.]
|
||||
INFO Captured MANAGE CHANNEL Apdu(00 70 00 00 01 01 9000)
|
||||
INFO Captured SELECT MF/ADF.ISD-R Apdu(01 A4 04 00 10 a0000005591010ffffffff8900000100 6f1f8410a0000005591010ffffffff8900000100a5049f6501ffe0058203020200 9000)
|
||||
INFO Captured MANAGE CHANNEL Apdu(00 70 00 00 01 01 9000)
|
||||
@@ -279,6 +281,8 @@ While tracing provides valuable insights into command sequencing and \gls{aid} s
|
||||
\section{Data Fuzzing}
|
||||
\label{sec:data_fuzzing_evaluation}
|
||||
|
||||
\todo{Introduce different setups to make it more obvious when conducting seperate experiments}
|
||||
|
||||
|
||||
\begin{table}[h!]
|
||||
\centering
|
||||
@@ -322,9 +326,9 @@ While tracing provides valuable insights into command sequencing and \gls{aid} s
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
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.
|
||||
We conducted data fuzzing, as described in \cref{subsec:data_fuzzing}, on all tested \gls{esim} cards with the exception of \texttt{estk.me}. Each test case is executed sequentially across all eligible \glspl{esim} to ensure consistency and reproducibility of results.
|
||||
|
||||
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:
|
||||
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 cards:
|
||||
\begin{itemize}
|
||||
\item 9esim
|
||||
\item 9esim v2
|
||||
|
||||
@@ -102,8 +102,11 @@ Our tracing functionality comprises two main operations:
|
||||
\includesvg[width=\textwidth]{Graphics/trace_setup.svg}
|
||||
\caption{Tracing lab setup}
|
||||
\label{img:trace_setup}
|
||||
\todo{Add \sysname onto pc image and reference this figure in text}
|
||||
\end{figure}
|
||||
|
||||
\todo{Overview of software components}
|
||||
|
||||
The implementation consists of several key components:
|
||||
|
||||
\begin{description}
|
||||
@@ -595,6 +598,8 @@ According to the SGP.22 specification, many functions may return a generic \text
|
||||
|
||||
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.
|
||||
|
||||
\todo{Explain how we use differential testing in this context}
|
||||
|
||||
\paragraph{Conclusion}
|
||||
By combining property-based data generation with structural knowledge of \gls{asn1} types, we extend the fuzzing coverage of the \gls{euicc} interface beyond what is possible with \gls{apdu} mutation alone. This enables the discovery of semantic inconsistencies and unhandled corner cases in \gls{euicc} implementations, especially when compared across different vendors during differential testing as shown in \cref{sec:data_fuzzing_evaluation}.
|
||||
|
||||
@@ -629,6 +634,7 @@ While the implemented library provides a programmatic interface to the \gls{lpa}
|
||||
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.
|
||||
|
||||
\subsection*{Structure}
|
||||
\todo{Put this section into the appendix}
|
||||
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}.
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
|
||||
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{Literature}
|
||||
\section{Academic and Industry Research}
|
||||
|
||||
% SIMURAI
|
||||
% - focuses on the possiblility of compromised / attacker controlled SIM cards
|
||||
@@ -85,7 +85,7 @@ A more serious security assessment was presented by \textcite{security_explorati
|
||||
|
||||
\textcite{security_explorations_esim_2025} responsibly disclosed the vulnerability to Kigen, GSMA, and Oracle. As a result, GSMA introduced additional restrictions in the updated TS.48 specification v7.0~\cite{gsma_ts48_2025}, aiming to prevent unauthorized applet installations. However, the researchers voiced concern that this measure only mitigated the symptoms rather than addressing the core vulnerability in the Java Card VM architecture.
|
||||
|
||||
\section{Software Implementations}
|
||||
\section{Software and Hardware Implementations}
|
||||
|
||||
\paragraph{pySim}
|
||||
|
||||
@@ -123,7 +123,7 @@ While \texttt{pySim} provides useful standalone utilities, its usability as a ge
|
||||
% - 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}.
|
||||
\texttt{SIMtrace2} is a hardware platform 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 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}.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user