Update on Overleaf.

Chapters/Background.tex

@@ -34,7 +34,8 @@ The \gls{etsi} defines the \gls{sim} card as a smart card platform. This include
 
 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 \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}.
+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 as described in \cref{sec:rsp}, and the \gls{lpa} aswell as the \gls{smdpp} in \cref{par:euicc_components}, 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
@@ -248,7 +249,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}.
 
 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.
 
@@ -306,6 +307,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!]
     \centering
@@ -331,7 +333,7 @@ Interface when LPA is in the Device (LUId), are collectively simplified and refe
 \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 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.
+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
@@ -401,9 +403,40 @@ 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!]
+	\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{figure}
+
+\begin{table}[h!]
+    \centering
+    \caption{Notation for mutual authentication sequence diagram.\cite{ahmed_security_2024}}
+    \label{tab:notiation}
+    \begin{tabular}{l p{6.5cm} l}
+        \toprule
+        \textbf{Symbol} & \textbf{Description} & \textbf{GSMA} \\
+        \midrule
+        $U$                & \gls{euicc} identifier & EID \\
+        $S$                & Server domain name \\
+        \text{userId}      & User identity authenticated by \gls{mno} & \\
+        $\text{iccid}$     & Unique identifier of the SIM profile & ICCID \\
+        $I_{ac}$           & Matching identifier in activation code & \\
+        $\mathrm{SKI}_{CI}$ & SubjectKeyIdentifier of $\mathrm{Cert}_{CI}$ & \\
+        $N_U := R,\ N_S := R$ & Random numbers generated by \gls{euicc} and server & \\
+        $I_t := R$         & Random session identifier generated by server & \\
+        $\mathrm{Sign}(M;\ SK)$ & Signature of message $M$ with private key $SK$ & \\
+        \text{serverOID}& Server OID in $\mathrm{Cert}_{Sa}$ and $\mathrm{Cert}_{Sp}$ & \\
+        \text{subject of Cert} & Subject identifier to which certificate was issued & \\
+        $\mathrm{Cert}_a \triangleleft \mathrm{Cert}_b$ & Certificates, check that $\mathrm{Cert}_a$ is signed by the subject key of $\mathrm{Cert}_b$ & \\
+        \bottomrule
+    \end{tabular}
+\end{table}
+
 \paragraph{Mutual Authentication}
 
-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 and sends it, along with its \gls{ci} Root public key certificate, to the \gls{smdpp}. The \gls{smdpp} responds with a signed version of the challenge, its own certificate subject, a transaction identifier, and a server challenge. The \gls{euicc} verifies the signature and certificate chain, signs the activation code’s profile identifier (and other protocol elements), the transaction identifier, the server challenge, 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}