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

Update on Overleaf.

Browse Source
This commit is contained in:
nb72soza Bittner
2025-07-11 22:20:04 +00:00
committed by node
parent 4d04daa0dd
commit 8a9bed4aea
4 changed files with 48 additions and 36 deletions
Download Patch File Download Diff File Expand all files Collapse all files

54
Chapters/Background.tex
View File

@@ -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}