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-01 23:50:06 +00:00
committed by node
parent 928dcd72df
commit 05541d57ab
10 changed files with 690 additions and 539 deletions
Download Patch File Download Diff File Expand all files Collapse all files

129
Chapters/Background.tex
View File

@@ -14,11 +14,12 @@
% - The os on the card can also run java card applets to provide additional functionality
% - java card applets enable the use of the java language to be used on smart cards, use the Java Card Runtime Environment which runs inside the Java Card VM
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, \gls{mifare} cards). As a smart card, a SIM contains essential computing components: a \gls{cpu}, \gls{rom}, and \gls{ram}, all of which are accessed through up to eight physical contacts (pins) on the card's surface~\cite{smartcard-standard}.
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{smartcard-standard}.
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.
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 \gls{jcre}, which itself runs inside the \gls{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.
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.
\paragraph{Standards}
@@ -29,11 +30,11 @@ 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 151 011 specifies the logical structure of the file system and the behavior of elementary and dedicated files~\cite{etsi_ts_2005}.
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}.
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.
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 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}.
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}.
% 4 main specifications
% machine-2-machine standard (SGP.01, SGP.02): industry focused -> mainly used in the automotive industry to enable eCall functionality
@@ -41,24 +42,67 @@ The \gls{gsma} defines the higher-level functional architecture necessary to ope
% 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
The main GSMA eSIM specifications can be categorized as follows:
\begin{table}[ht]
\centering
\small
\begin{tabular}{|p{2.5cm}|p{4cm}|p{4cm}|}
\hline
\textbf{Attribute} & \textbf{M2M} & \textbf{Consumer} \\
\hline \hline
\gls{gsma} Specification & SGP.01 / \textbf{SGP.02} & SGP.21 / \textbf{SGP.22} \\
\hline
First Publication & 2013 & 2015/2016 \\
\hline
Use Case & \textbf{Devices with no user interface} (e.g., automotive, industrial) & \textbf{Devices with user interface} (e.g., smartphones, tablets) \\
\hline
Examples & Vehicles, smart meters, sensors & Smartphones, tablets, wearables \\
\hline
RSP Type & \textbf{Push} (centrally managed) & \textbf{Pull} (user-initiated) \\
\hline
\end{tabular}
\caption{Comparison of M2M and Consumer eUICC Types \cite{gd_rsp_nodate}}
\label{tab:euicc_m2m_consumer}
\end{table}
\begin{table}[ht]
\centering
\small
\begin{tabular}{|p{2.5cm}|p{4cm}|p{4cm}|}
\hline
\textbf{Attribute} & \textbf{IoT} & \textbf{In-Factory} \\
\hline \hline
\gls{gsma} Specification & SGP.31 / \textbf{SGP.32} & SGP.41 / \textbf{SGP.42} \\
\hline
First Publication & 2023/2024 & 2025 \\
\hline
Use Case & \textbf{UI/network-constrained IoT devices} & \textbf{Profile pre-loading during production} \\
\hline
Examples & Trackers, wearables, sensors, vehicles & Smartphones, wearables, meters \\
\hline
RSP Type & \textbf{Push} (server-driven) & \textbf{Push} (factory provisioned) \\
\hline
\end{tabular}
\caption{Comparison of IoT and In-Factory eUICC Types \cite{gd_rsp_nodate}}
\label{tab:euicc_iot_infactory}
\end{table}
The main \gls{gsma} \gls{esim} specifications can be categorized as follows:
\begin{itemize}
\item \textbf{Machine-to-Machine (M2M) Standards (SGP.01, SGP.02):}
\item \textbf{Machine-to-Machine (M2M) Standard:}
Industry-focused specifications primarily used in the automotive sector to enable functionalities such as eCall.
\item \textbf{Consumer Specifications (SGP.21, SGP.22):}
Targeted at regular users and implemented in smartphones and other consumer devices for remote SIM provisioning with focus on ease of use.
\item \textbf{Consumer Standard:}
Targeted at regular users and implemented in smartphones and other consumer devices for remote \gls{sim} provisioning with focus on ease of use.
\item \textbf{Internet of Things (IoT) Specifications (SGP.31, SGP.32):}
Successors to the M2M eSIM standards, designed to support 5G and NB-IoT connectivity for sensors and various IoT devices.
\item \textbf{\gls{iot} Standard:}
Successors to the M2M \gls{esim} standards, designed to support 5G and Narrowband-IoT (NB-IoT) connectivity for sensors and various IoT devices.
\item \textbf{In-Factory Standard:}
Released in February 2025 as version 1.0, the upcoming In-Factory Profile Provisioning (IFPP) standard targets devices, such as those in the automotive and IoT sectors, that require network connectivity immediately after or during production. It is specifically designed to enable profile installation during the manufacturing process. So far only the IFPP Architecture and Requirements Specifications SGP.41~\cite{gsma_sgp41_2025} have been released, with the IFPP Technical Specification SGP.42 still being actively developed.
\item \textbf{In-Factory Specifications (SGP.41, SGP.42):}
A brand new specification with version 1.0 released in February 2025, intended for devices including cars and IoT hardware that require immediate network connectivity post-manufacturing, predominantly in the automotive and IoT industries.
\end{itemize}
\todo{Explain different GSMA standards i.e consumer, m2m, iot, factory}
\cref{tab:euicc_m2m_consumer} and \cref{tab:euicc_iot_infactory} compare the \gls{gsma} specifications and highlight their differences.
\paragraph{Transport Protocols}
@@ -71,7 +115,7 @@ Communication between the \gls{uicc} and the terminal is governed by transport p
T=0 is a half-duplex, asynchronous, character-based transmission protocol. It is relatively simple in design and is widely supported across devices due to its low overhead and ease of implementation. However, it lacks advanced features such as robust error correction and support for transmitting large \glspl{apdu} efficiently.
In contrast, T=1 is a half-duplex, asynchronous, block-oriented protocol. It introduces several enhancements over T=0, including improved error detection and correction mechanisms, APDU chaining for handling long messages, and more flexible flow control. These improvements come at the cost of increased complexity, as T=1 includes block headers, control fields, and more elaborate state handling. Due to this additional complexity and resource requirements, T=1 is, to the best of current knowledge, rarely employed in consumer-grade \gls{sim} or \gls{esim} cards.
In contrast, T=1 is a half-duplex, asynchronous, block-oriented protocol. It introduces several enhancements over T=0, including improved error detection and correction mechanisms, \gls{apdu} chaining for handling long messages, and more flexible flow control. These improvements come at the cost of increased complexity, as T=1 includes block headers, control fields, and more elaborate state handling. Due to this additional complexity and resource requirements, T=1 is, to the best of current knowledge, rarely employed in consumer-grade \gls{sim} or \gls{esim} cards.
Given this, the remainder of this work will focus on the T=0 protocol, which remains the dominant transport protocol in commercial \gls{uicc} deployments.
@@ -86,14 +130,14 @@ Given this, the remainder of this work will focus on the T=0 protocol, which rem
% - sw with 61XX or 6CXX are used to control the exchange on the transport layer and indicate that the UICC has data to return where XX indicates the amount of bytes that are availble
% - other responses indicate errors during the command processing or execution (cite eftlabs list of apdu responses)
In smart card communication, it is essential to distinguish between the application-layer protocol and the transport-layer protocol. At the application layer, the data units are referred to as \glspl{apdu}, while at the transport layer, they are termed \glspl{tpdu}. According to \gls{etsi} specifications, outgoing commands from the terminal to the \gls{uicc} are defined as \glspl{capdu}, and the responses from the UICC are defined as \glspl{rapdu}~\cite{etsi_ts_2023}. On the transport layer, these correspond to \gls{ctpdu} and \gls{rtpdu}, respectively.
In smart card communication, it is essential to distinguish between the application-layer protocol and the transport-layer protocol. At the application layer, the data units are referred to as \glspl{apdu}, while at the transport layer, they are termed \glspl{tpdu}. According to \gls{etsi} specifications, outgoing commands from the terminal to the \gls{uicc} are defined as Command APDUs (C-APDU), and the responses from the UICC are defined as Response APDUs (R-APDU)~\cite{etsi_ts_2023}. On the transport layer, these correspond to Command APDUs and Response APDUs, respectively.
A C-APDU consists of mandatory header fields and optional data and length fields. An R-APDU typically includes the response data followed by a two-byte status word (\texttt{SW1} and \texttt{SW2}), which indicates the result of the command execution.
\begin{table}[h]
\centering
\caption{Structure of a \gls{capdu}}
\begin{tabular}{|l|l|l|}
\caption{Structure of a C-APDU}
\begin{tabular}{|l|l|p{6cm}|}
\hline
\textbf{Field name} & \textbf{Length (bytes)} & \textbf{Description} \\
\hline \hline
@@ -110,7 +154,7 @@ A C-APDU consists of mandatory header fields and optional data and length fields
\begin{table}[h]
\centering
\caption{Structure of a \gls{rapdu}}
\caption{Structure of a R-APDU}
\begin{tabular}{|l|l|l|}
\hline
\textbf{Field name} & \textbf{Length (bytes)} & \textbf{Description} \\
@@ -122,7 +166,7 @@ A C-APDU consists of mandatory header fields and optional data and length fields
\end{tabular}
\end{table}
The status word (SW) in an \gls{rapdu} signifies whether a command was successfully processed or if an error occurred. The value \texttt{9000} is used to indicate successful execution. Other status words serve specific purposes. For instance, \texttt{61XX} or \texttt{6CXX} indicate that additional data is available, where \texttt{XX} specifies the number of bytes remaining. These codes are particularly relevant for controlling \gls{apdu} exchanges at the transport layer. Other status word values denote different error conditions related to command structure, logical access violations, or execution faults~\cite{eftlab_list_nodate}.
The status word (SW) in an R-APDU signifies whether a command was successfully processed or if an error occurred. The value \texttt{9000} is used to indicate successful execution. Other status words serve specific purposes. For instance, \texttt{61XX} or \texttt{6CXX} indicate that additional data is available, where \texttt{XX} specifies the number of bytes remaining. These codes are particularly relevant for controlling \gls{apdu} exchanges at the transport layer. Other status word values denote different error conditions related to command structure, logical access violations, or execution faults~\cite{eftlab_list_nodate}.
@@ -138,7 +182,7 @@ When interacting with a \gls{uicc}, either to request or to store data, the comm
\gls{asn1} supports a variety of encoding rules. One of the most commonly used in the context of smart cards and mobile communications is the \gls{ber}. In \gls{ber}, all data is encoded as a sequence of \gls{tlv} elements. The \emph{Tag} identifies the type of data, the \emph{Length} specifies the number of bytes used for the value, and the \emph{Value} contains the actual data payload.
For example, consider the following simplified \texttt{STORE DATA} command that encodes an \texttt{EnableProfileRequest} as defined in the GSMA's \texttt{SGP.22} specification. The request uses the \gls{iccid} variant of the \texttt{profileIdentifier} field:
For example, consider the following simplified \texttt{STORE DATA} command that encodes an \texttt{EnableProfileRequest} as defined in the \glsposs{gsma} \texttt{SGP.22} specification. The request uses the \gls{iccid} variant of the \texttt{profileIdentifier} field:
\begin{verbatim}
BF31 10
@@ -168,29 +212,29 @@ The \gls{gsma} provides \gls{asn1} definitions for all standardized \gls{rsp} fu
% - Applicataion DF: special DF that contains all EFs and DFs of an application
% - Elementary files (EF) are childs of DF, differntiate between transparent EF, lienar fixed EF, cyclic EF
% - Files are identified with their unique File Identifier (FID), Applications with their unique Application Identifier (AID)
% - path represents a concatenation of FIDs, starts with MF or DF, FID "7fff" represents current ADF
% - Master File represents the root object from which all EF, DF and ADF orginate from
% - path represents a concatenation of FIDs, starts with MF or DF, FID "7fff" represents current \gls{adf}
% - Master File represents the root object from which all EF, DF and \gls{adf} orginate from
% - to select an file or application: SELECT command with FID/AID, path or short FID
% - selcting files is stateful i.e to select subsequent files, first select the parent file or application to access files in that application
% - 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}, 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 Master File (MF), from which Dedicated Files (DFs), Elementary Files (EFs), and \glspl{adf} originate.
\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).
DFs 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, EFs 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).
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}.
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 \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.
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 AIDs proposed by the \gls{gsma} and \gls{gp} include the \gls{isdr} application and the \gls{aram} application.
Common \glspl{aid} proposed by the \gls{gsma} and \gls{gp} include the \gls{isdr} application and the \gls{aram} application.
\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: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:eval_tracing}.
\section{Embedded SIM}
\label{sec:esim}
@@ -206,7 +250,7 @@ Historically, the subscriber identity and related credentials were bound to a ph
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 secure, remote provisioning mechanism and significantly enhances user flexibility, while simultaneously introducing new complexity in terms of protocol design, security guarantees, and implementation correctness.
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.
\paragraph{eUICC Components}
@@ -235,11 +279,11 @@ The \gls{isdr} acts as the primary control authority on the \gls{euicc}. It mana
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.
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, during the \gls{euicc} manufacturing process and can restrict which device-side applications are permitted to communicate with the \gls{euicc} and its applets.
Together, these components establish the trust and management architecture necessary for secure and scalable remote SIM provisioning.
\paragraph{eSIM on SIM}
\paragraph{eSIM-on-SIM}
% - most popular option of integrating esims is directly soldering them onto the cricuit board of a smartphone
% - since the soldered esim is near identical to the SIMs normally distributed as physical SIMs -> esims can also be distributed as physical esims -> enables non esim capable phones to use esims
@@ -258,7 +302,7 @@ 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 \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.
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 \gls{euicc} manufacturer—they can also be packaged as “physical \glspl{esim}” 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}
@@ -267,14 +311,17 @@ The \gls{lpa} is a user-facing application (i.e an App on a smartphone) on the \
\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}.}
\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}
\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.}
\footnotetext{The components referred to as the Local Profile Assistant when LPA is in the Device
(LPAd) in this thesis, namely the Local Discovery Service when LPA is in the Device
(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 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.
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. 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.
@@ -322,10 +369,10 @@ The \gls{stk}/\gls{usat}, which are collectively referred to as the \gls{cat} in
% - 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 \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}.
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 SGP.22~\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}.
\gls{sgp22} defines three \gls{rsp} initiation methods:
SGP.22 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 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.
@@ -352,5 +399,7 @@ Next, the \gls{euicc} and \gls{smdpp} perform an \gls{ecka} to derive session ke
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.
\todo{Add sequence diagram which shows the rsp process}