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 14:08:10 +00:00
committed by node
parent 23c94ec81e
commit 4d04daa0dd
4 changed files with 708 additions and 604 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
Chapters/Background.tex
View File

@@ -5,6 +5,8 @@
%************************************************
\glsresetall % Resets all acronyms to not used
\todo{Overview of esim stack}
\section{Subscriber Identity Module}
\label{sec:sim}
@@ -16,7 +18,7 @@
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{etsi_ts_2003}.
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.
Interaction with the \gls{sim} is governed by an embedded operating system \cite{etsi_ts_2022-1, globalplatform_gp_2018}, 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 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.\cite{ort_writing_2001}
@@ -27,6 +29,8 @@ Java Card applets are applications written in a restricted subset of the Java pr
% - 3GPP: defines how the SIMs are integrated into the mobile networks by defining the mobile broadband standards such as 5G and LTE
% - GSMA: defines the funcitonal systems around the eSIM to make it usable in the real-world, i.e. in the context of eSIMs: RSP, LPA, SM-DP+, etc -> later (cite SGP.22)
Identification cards such as \glspl{sim} and \glspl{esim} are fundamentally built upon the ISO/IEC 7816 standard \cite{iso_isoiec_2019}, which defines key aspects of smart cards with contacts. This includes specifications for the physical characteristics, contact positioning, electrical interface, transmission protocols, and command structure. These foundational definitions are essential for the development of both traditional \glspl{uicc} and embedded \glspl{euicc}, ensuring baseline interoperability and functionality across compliant hardware platforms.
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 \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}.
@@ -42,7 +46,7 @@ The \glsposs{gsma} SGP.22 specification is a cornerstone in this area, detailing
% 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
\begin{table}[ht]
\begin{table}[t]
\centering
\small
\begin{tabular}{|p{2.5cm}|p{4cm}|p{4cm}|}
@@ -64,7 +68,7 @@ The \glsposs{gsma} SGP.22 specification is a cornerstone in this area, detailing
\label{tab:euicc_m2m_consumer}
\end{table}
\begin{table}[ht]
\begin{table}[t]
\centering
\small
\begin{tabular}{|p{2.5cm}|p{4cm}|p{4cm}|}
@@ -435,7 +439,7 @@ In this work, we focus on the Authentication Code method due to its prevalence i
\paragraph{Mutual Authentication}
As \cref{fig:mutual_authentication} shows, the \gls{rsp} process begins with mutual authentication between the \gls{euicc} and \gls{smdpp} over a \gls{tls} tunnel established via the \gls{lpa}. The \gls{euicc} generates a random challenge $N_U$ and sends it, along with its \gls{ci} Root public key certificate $SKI_{CI}$, to the \gls{smdpp}. The \gls{smdpp} responds with a signed version of the challenge $N_U$, its own certificate subject $S$, a transaction identifier $I_t$, and a server challenge $N_S$. The \gls{euicc} verifies the signature and certificate chain, signs the activation code’s profile identifier $I_{ac}$ (and other protocol elements), the transaction identifier $I_t$, the server challenge $N_S$, and relevant addresses, then returns this to the \gls{smdpp}. Based on the profile identifier, the \gls{smdpp} selects the appropriate profile for download.
As \cref{fig:mutual_authentication} shows, the \gls{rsp} process begins with mutual authentication between the \gls{euicc} and \gls{smdpp} over a \gls{tls} tunnel established via the \gls{lpa}. The \gls{euicc} generates a random challenge $N_U$ and sends it, along with its \gls{ci} Root public key certificate $SKI_{CI}$, to the \gls{smdpp}. The \gls{smdpp} responds with a signed version of the challenge $N_U$, its own certificate subject $S$, a transaction identifier $I_t$, and a server challenge $N_S$. The \gls{euicc} verifies the signature and certificate chain, signs the activation code’s profile identifier $I_{ac}$ (and other protocol elements), the transaction identifier $I_t$, the server challenge $N_S$, and relevant addresses, then returns this to the \gls{smdpp}. Based on the profile identifier, the \gls{smdpp} selects the appropriate profile for download.
\paragraph{Profile Binding}