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-06-23 20:19:09 +00:00
committed by node
parent 9305d82b15
commit 09b1b30a05
4 changed files with 65 additions and 57 deletions
Download Patch File Download Diff File Expand all files Collapse all files

40
Chapters/Background.tex
View File

@@ -35,6 +35,8 @@ The \gls{3gpp} focuses on how \gls{sim} cards integrate with mobile networks. Th
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}.
\todo{Explain different GSMA standards i.e consumer, m2m, iot, factory}
\paragraph{Transport Protocols}
@@ -93,7 +95,7 @@ A C-APDU consists of mandatory header fields and optional data and length fields
\hline \hline
$Data$ & at most $N_e$ & Response Data \\
$SW1$ & 1 & Status Word 1 \\
$SW2$ & 1 & Status Word 1 \\
$SW2$ & 1 & Status Word 2 \\
\hline
\end{tabular}
\end{table}
@@ -151,13 +153,13 @@ The \gls{gsma} provides \gls{asn1} definitions for all standardized \gls{rsp} fu
% - 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} (Master File), 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 \gls{mf}, from which \glspl{df}, \glspl{ef}, and \glspl{adf} originate.
\glspl{df} serve as containers that enable functional grouping of files. A special class of DF, called \glspl{adf}, encapsulates all files (EFs and optionally DFs) related to a specific application. Within these structures, \glspl{ef} act as leaf nodes and contain the actual data. There are three types of EFs: transparent EFs (byte-oriented, raw data), linear fixed EFs (record-based, fixed-length records), and cyclic EFs (circular buffers).
\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).
Each file is uniquely identified by a \gls{fid}, while applications are identified by their \gls{aid}. File paths are defined as a sequence of FIDs, typically starting from the MF or an ADF. The reserved FID \texttt{7FFF} refers to the currently selected ADF.
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}.
To access files, the \texttt{SELECT} command is used. This command supports various addressing modes: by FID, AID, complete path, or short FID. Importantly, file selection is stateful—meaning that parent files or applications must be selected before accessing child files.
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.
Common AIDs proposed by the \gls{gsma} and \gls{gp} include the \gls{isdr} application and the \gls{aram} application.
@@ -166,7 +168,7 @@ Common AIDs proposed by the \gls{gsma} and \gls{gp} include the \gls{isdr} appli
\item \gls{aram} \texttt{A00000015141434C00}
\end{itemize}
However, the actual AIDs used are implementation-specific and may be customized by the manufacturer. The \gls{isdr} AID in particular is often modified, as discussed in \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:findings}.
\section{Embedded SIM}
\label{sec:esim}
@@ -209,7 +211,7 @@ The \gls{ecasd} provides secure storage and cryptographic services. It maintains
The \gls{isdr} acts as the primary control authority on the \gls{euicc}. It manages the creation, activation, deactivation, and deletion of \glspl{isdp}. Only one of either \gls{isdr} or \gls{ecasd} can be present on a single \gls{euicc}, depending on the \gls{euicc}'s implementation mode.
Each \gls{isdp} hosts exactly one \gls{esim} profile and is responsible for profile download and installation. \glspl{isdp} may additionally host applets specific to the mobile network operator or service provider.
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.
@@ -236,11 +238,24 @@ Together, these components establish the trust and management architecture neces
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.
\paragraph{Local Profile Assistant}
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. 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!]
\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}.}
\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.}
\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.
\section{Remote SIM Provisioning}
\label{sec:rsp}
@@ -287,19 +302,10 @@ The \gls{stk}/\gls{usat}, which are collectively referred to as the \gls{cat} in
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}.
The \gls{lpa} is a user-facing application 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. 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 but is less common in consumer scenarios.
\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}.}
\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.}
\gls{sgp22} 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. The user triggers provisioning via the default server.
\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.
\item \textbf{\gls{smds} Assisted}: The \gls{lpa} polls the \gls{smds} for an event matching the \gls{eid} of the \gls{euicc}. If a download event exists, the \gls{smds} supplies the \gls{smdpp} address to the \gls{lpa} for profile download.
\end{enumerate}