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-05-20 15:27:22 +00:00
committed by node
parent fee4ef6317
commit 6358400a27
7 changed files with 233 additions and 28 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
Chapters/Background.tex
View File

@@ -29,7 +29,7 @@ Java Card applets are applications written in a restricted subset of the Java pr
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 ETSI standard TS 131 221 specifies the logical structure of the file system and the behavior of elementary and dedicated files~\cite{etsi-ts-131-221}.
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 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}.
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 \gls{lte}, \gls{5g}, and legacy systems. These standards ensure interoperability between SIMs and network infrastructure across vendors and operators.
@@ -192,7 +192,7 @@ This architecture introduces a secure, remote provisioning mechanism and signifi
\begin{figure}[h!]
\includegraphics[width=\textwidth]{Graphics/euicc_architecture.png}
\caption{eUICC architecture~\cite{gsma_sgp22_2024}.}
\caption{\gls{euicc} architecture~\cite{gsma_sgp22_2024}.}
\label{img:euicc_architecture}
\end{figure}
@@ -227,11 +227,11 @@ Together, these components establish the trust and management architecture neces
% - estk.me also implemented rlpa (remote lpa or as they call it cloud enhance) -> allows the user to provision profiles via the stk / usat menu (cite cloud rlpa-server)
% other options to provision profiles require an lpa client on the ue / terminal
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 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 eSIMs in these sizes are produced by vendors such as Kigen, Estcompeace, and Giesecke+Devrient.
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{Application Toolkit}
The SIM/USIM Application Toolkit — 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 UICC/USIM environments. CAT unifies STK and USAT under a single umbrella for all UICC-based toolkits. These toolkits enable on-card applets to interact with the user equipment—displaying menus, sending SMS, downloading data, or even initiating 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 CAT menus without a separate LPA client~\cite{estkme_rlpa-server_2025}. Other provisioning methods typically require a dedicated LPA application on the device.
The \gls{stk}/\gls{usat} — 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.
@@ -279,9 +279,9 @@ The SIM/USIM Application Toolkit — collectively referred to as the \gls{cat} i
% - when success response: notification is deleted from euicc
% - profile provisioning is finished
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 GSMA in specification SGP.22~\cite{gsma_sgp22_2023, gsma_sgp22_2024, gsma_sgp22_2025}. The key components of the RSP ecosystem are the \gls{lpa}, the \gls{smdpp}, and, to a lesser extent in consumer deployments, the \gls{smds}.
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 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 eUICC manufacturer, MNO, or third party—that securely hosts eSIM profiles and makes them available for download. The \gls{smds} facilitates the "push" provisioning approach but is less common in consumer scenarios.
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}
@@ -291,32 +291,32 @@ The \gls{lpa} is a user-facing application on the UE that interacts with the \gl
\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.}
SGP.22 defines three RSP initiation methods:
\gls{sgp22} defines three \gls{rsp} initiation methods:
\begin{enumerate}
\item \textbf{Default Server}: The SM-DP+ address is pre-configured on the eUICC at manufacture time. The user triggers provisioning via the default server.
\item \textbf{Authentication Code}: The user is provided with an activation code (containing the SM-DP+ address and optional confirmation code) when purchasing service. The LPA contacts the SM-DP+ and, after mutual authentication, may require entry of the confirmation code.
\item \textbf{SM-DS Assisted}: The LPA polls the SM-DS for an event matching the EID of the eUICC. If a download event exists, the SM-DS supplies the SM-DP+ address to the LPA for profile download.
\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{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}
In this work, we focus on the Authentication Code method due to its prevalence in commercial eSIM deployments and the ready availability of test activation codes—critical for our differential-testing and fuzzing methodology (see Section~\ref{sec:fuzzing})
In this work, we focus on the Authentication Code method due to its prevalence in commercial \gls{esim} deployments and the ready availability of test activation codes—critical for our differential-testing and fuzzing methodology (see~\cref{sec:fuzzing})
\textcite{ahmed_security_2024} packages the \gls{rsp} into four major steps: mutual authentication, profile binding, profile download (including authenticated key exchange), and notification.
\paragraph{Mutual Authentication}
The RSP process begins with mutual authentication between the eUICC and SM-DP+ over a TLS tunnel established via the LPA. The eUICC generates a random challenge and sends it, along with its CI Root public key certificate, to the SM-DP+. The SM-DP+ responds with a signed version of the challenge, its own certificate subject, a transaction identifier, and a server challenge. The 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 SM-DP+. Based on the profile identifier, the SM-DP+ selects the appropriate profile for download.
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.
\paragraph{Profile Binding}
Upon successful authentication, the SM-DP+ checks for profile availability and then sends the signed transaction identifier plus the profile-binding key to the eUICC. The eUICC validates the signature against the GSMA CI Root and ensures the certificate is authorized.
Upon successful authentication, the \gls{smdpp} checks for profile availability and then sends the signed transaction identifier plus the profile-binding key to the \gls{euicc}. The \gls{euicc} validates the signature against the \gls{gsma} \gls{ci} Root and ensures the certificate is authorized.
\paragraph{Profile Download}
Next, the eUICC and SM-DP+ perform an \gls{ecka} to derive session keys. The SM-DP+ encrypts the profile using the session key and transmits it to the eUICC. The eUICC configures the new ISD-P, decrypts the profile, and installs it. The profile is then ready for use.
Next, the \gls{euicc} and \gls{smdpp} perform an \gls{ecka} to derive session keys. The \gls{smdpp} encrypts the profile using the session key and transmits it to the \gls{euicc}. The \gls{euicc} configures the new \gls{isdp}, decrypts the profile, and installs it. The profile is then ready for use.
\paragraph{Notification}
After installation, session keys are erased and the eUICC generates a signed installation notification containing a sequence number and server address. The LPA forwards this notification to the SM-DP+, and upon receiving a success response, the eUICC removes the notification, completing the provisioning cycle.
After installation, session keys are erased and the \gls{euicc} generates a signed installation notification containing a sequence number and server address. The \gls{lpa} forwards this notification to the \gls{smdpp}, and upon receiving a success response, the \gls{euicc} removes the notification, completing the provisioning cycle.