% !TeX root = ../Thesis.tex

%************************************************
\chapter{Background}\label{ch:design}
%************************************************
\glsresetall % Resets all acronyms to not used

\section{Subscriber Identity Module}
\label{sec:sim}

% - base is a smart card -> also used for bank cards, MIFARE cards, etc
% - contains a CPU, ROM, RAM and can be connected via 8 PINS on the back side
% - access is provided via the OS running on the card, offers file structure 
% - 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}.

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.


\paragraph{Standards}
% - how SIMs operate and function is defined by 3 parties: ETSI, 3GPP, and the GSMA
% - ETSI: defines how the SIM works as a platform i.e UICC hardware, how APDU are structured and work, and the smart card file system (cite TS 131 221)
% - 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)

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{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{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}.



\paragraph{Transport Protocols}
% - ETSI defines two protocols for communication: T=0 and T=1
% - T=0: half-duplex asynchronos asynchronous character based transmission protocol
% - T=1: half-duplex asynchronous block based transmission protocol, is in several ways more advanced than t=0: better error correction, APDU chaining, better in handling large APDUs etc, but also has more overhead due to block headers,  control fields, way more complex in comparison to t=0  (cite TS 102 221)
% - to the best of my knowledge t=1 is rarly used in consumer SIMs and eSIMs -> we will focus on t=0

Communication between the \gls{uicc} and the terminal is governed by transport protocols defined by the \gls{etsi} standard TS 102 221~\cite{etsi_ts_2023}. Two primary protocols are specified: \textbf{T=0} and \textbf{T=1}. 

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.

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.


\paragraph{Application/Transportation Protocol Data Unit}
% - we differentiate between APDU (Application layer) and TPDUs (transport layer)
% - when sending APDUS to the UICC wthe ETSI defines them as C-APDUs (command apdus) and the responses from the UICC as R-APDUs (response apdus)
% - on the tansport layer those are C-TPDUs and R-TPDUs respectivly
% - the apdus have the following structure (insert table for C-apdus and r-apdus)
% - the status word (sw) in the r-apdu indictates a successfull execution or an error
% - success are indicated by 9000
% - 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.

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|}
        \hline
        \textbf{Field name} & \textbf{Length} & \textbf{Description} \\
        \hline \hline
        $CLA$ & 1 & Instruction Class \\
        $INS$ & 1 & Instruction Code \ie "SELECT" \\
        $P1$ & 1 & Parameter 1 \\
        $P2$ & 1 & Parameter 2 \\
        $L_c$ & 0, 1 & Encodes length ($N_c$) of command data \\
        $Data$ & $N_c$ & Command data \\
        $L_e$ & 0, 1 & Encodes length ($N_e$) of expected response data \\
        \hline
    \end{tabular}
\end{table}

\begin{table}[h]
    \centering
    \caption{Structure of a \gls{rapdu}}
    \begin{tabular}{|l|l|l|}
        \hline
        \textbf{Field name} & \textbf{Length} & \textbf{Description} \\
        \hline \hline
        $Data$ & at most $N_e$ & Response Data \\
        $SW1$ & 1 & Status Word 1 \\
        $SW2$ & 1 & Status Word 1 \\
        \hline
    \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}.



\paragraph{Data Encoding}
% - when requesting data or storing data on the UICC the command data uses ASN.1 with BER-TLV encoding
% - ASN.1 is a language that describes the sequence, the data and the encoding of the data that is used in a communication protocol (cite oss_nokalva)
% - it is a mature and widly spread technology especially in the telecommunications field
% - asn1 supports multiple different encoding rules among which is also the BER encoding
% - it uses a TLV for the encoding of all its information -> tag indicates what kind of data follows, then length to tell the parser how much that to read for this tag, and then the actual data (provide example for BER-TLV ASN1 encoding of some short RSP message)
% - the GSMA provides ASN.1 definitions for all of its standardized functions

When interacting with a \gls{uicc}, either to request or to store data, the command payload is typically structured using \gls{asn1} encoded in the \gls{ber}-\gls{tlv} format. \gls{asn1} is a formal language used to define data structures in a way that is independent of machine-specific encoding. It is a mature and widely adopted technology, particularly within the field of telecommunications, and is standardized by the ITU-T~\cite{oss_nokalva_asn1_nodate}.

\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:

\begin{verbatim}
    BF31 10  
    -- [49] SEQUENCE (EnableProfileRequest)
       5A 0A 89 10 20 30 40 50 60 70 80 90  
       -- ICCID (tag 5A, 10 bytes)
       01 01 FF  
       -- refreshFlag = TRUE (tag 01, length 1, value FF)
\end{verbatim}

In this example:
\begin{itemize}
    \item \texttt{BF31} is the context-specific tag for \texttt{EnableProfileRequest} (constructed, tag number 49).
    \item \texttt{5A} represents the \gls{iccid} field as defined in the \gls{gsma} \gls{asn1} specification.
    \item The ten-byte \gls{iccid} value shown here (\texttt{89 10 20 30 40 50 60 70 80 90}) is an example placeholder.
    \item The boolean \texttt{refreshFlag} is encoded using tag \texttt{01} and value \texttt{FF}, which represents \texttt{TRUE} in \gls{asn1}.
\end{itemize}

The \gls{gsma} provides \gls{asn1} definitions for all standardized \gls{rsp} functions, including profile management procedures such as enabling or disabling profiles. These encoded messages are typically wrapped in a \texttt{STORE DATA} \gls{apdu} (instruction byte \texttt{E2}) and sent to the \gls{euicc} for execution.



\paragraph{File Structure}

% - the file structure on an UICC is organized as an forest of trees (cite TS 102 221
% - Dedicated files (DF) allows for functional grouping of files 
% - 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
% - 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} (Master File), from which all other files—\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).

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.

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.

Common AIDs proposed by the \gls{gsma} and \gls{gp} include the \gls{isdr} application~(\texttt{A0000005591010FFFFFFFF8900000100}) and the \gls{aram} application~(\texttt{A00000015141434C00}). 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}.

\section{Embedded SIM}
\label{sec:esim}

% - based on eUICC
% - before: subscriber identity was bound to physical smart card (integrated during manufacturing) -> eSIM: decouples identiy from SIM -> virtualized and de-coupled from 
% - USIM, ISIM, other Applications, and associated file system data is now an eSIM profile, underlying chip is eUICC
% - profiles can be issued remotly (sm-ds) or can be triggered by an user via the lpa (sm-dp+)

The concept of the \gls{esim} is based on the \gls{euicc}, which replaces the traditional removable SIM card form factor with a soldered chip that remains permanently embedded within the device.

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}.

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.


\paragraph{eUICC Components}
\label{par:euicc_components}

% - to manage and issue newe eSIM profiles the eUICC needs some relevant Applications
% - ISD-R, ISD-P, ECASD, (LPAe), ARA-M,  LPA Services
% - ECASD: secure storage of credentials relevant for the eUICC, i.e. eUICC privat keys and certificat, eSIM CI, EUM Certificat, Manufacturer key set for key/certificat renewal
% - ECASD: signatur creation on data provided by the ISD-R, verification of certificates i.e SM-DP+ server certs
% - ISD-R: responsible for creation of new ISD-Ps as well as lifecycle management i.e enable, disable and deletion of ISD-Ps
% - only one of ECASD and ISD-R can be present on one eUICC
% - ISD-P hosts one unique profile, used for profile download and installation, the ISD-P itself can also host applets
% - ARA-M: defined by GlobalPlatform, Access Rules that are defined by the Secure Element Issuer i.e Manufacturer are availble via the Access Rule Application Master, Access Rules can be stored in multiple locations on the Secure Element -> ARA-M sources them and provides them

\begin{figure}[h!]
    \includegraphics[width=\textwidth]{Graphics/euicc_architecture.png}
    \caption{eUICC architecture~\cite{gsma_sgp22_2024}.}
    \label{img:euicc_architecture}
\end{figure}

To manage, store, and control \gls{esim} profiles, the \gls{euicc} hosts several critical applications and system components. These include the \gls{isdr}, \gls{isdp}, \gls{ecasd}, optionally the embedded \gls{lpa}, \gls{aram}, and various \gls{lpa} service interfaces as shown in \cref{img:euicc_architecture}.

The \gls{ecasd} provides secure storage and cryptographic services. It maintains sensitive credentials such as the \gls{euicc} private key and certificate, the eUICC Identifier (\texttt{EID}), the \gls{euicc} Manufacturer (\gls{eum}) certificate, and the manufacturer key set used for credential updates. It is also responsible for generating digital signatures on data received from the \gls{isdr} and for verifying certificates during the authentication of the \gls{smdpp} or other remote entities.

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.

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.

Together, these components establish the trust and management architecture necessary for secure and scalable remote SIM provisioning.

\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
% - Come in formfactors 2FF, 3FF, and 4FF to the best of our knowledge
% - most of the esims on sims we could find are manufactured by kigen, estcompeace, Giesecke+Devrient
% - most important feature of esim is remote sim provisioning (cite section rsp)

% STK / USAT (CAT
% - sim application toolkit (STK) introduced in the ETSI 11.14 for 2G SIM cards
% - defines set of commands and mechanisms that allow applications on the sim to interact with the UE or terminal i.e profile download, proactiv SIM (display messages, send messages, etc), data download, menue selection, etc (cite ETSI 11.14)
% - usim application toolkit (USAT) defined in ETSI TS 131 111 for 3G SIM cards
% - extends stk to support features which require higher level services like, multimedia messaging, bearer independed protocol (cite TS 131 111)
% - card application toolkit (CAT) defined in ETSI TS 102 223 is the umbrella term for the stk or usat
% - stk limited to gsm and usat on usim on uicc -> cat is uicc in general
% - stk/usat can be used to interact with the SIM/eSIM and perform application specific commands such as profile renaming, etc
% - 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.

\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.



\section{Remote SIM Provisioning}
\label{sec:rsp}

% - one the biggest features of esims is the ability to download profiles to the SIM without switching out the physical SIM
% - happens via the rsp process defined in sgp.22
% - the key components are the lpa and sm-dp+ as well as sm-ds (not that much used in the consumer market)
% - local profile assistant: user facing application which enables users to interact with the euicc and peform actions such as profile provisioning, as well as profile lifecycle interactions (enable, disable, delete)
% - sm-dp+: server operated by euicc manufacturer, mno, or someone else -> hosts profiles and makes them available for download 
% - sgp22 defines three approaches for the rsp: default server (sm-dp+ address is stored as the default address in the euicc during the manufacturing -> profile is created for euicc and user can trigger provisioning via default server), authentication code (authentication code with smdp address and optional confirmation code is given to the user when buying a mobile subscription, lpa contacts smdp address and inities download, confirmation code might be required after the mutual authentication), smds assisted (less common, lpa checks sm-ds server for event with eid of euicc, if profile download event is availble contact smdp+ address which is provided by the smds to download profile)
% - we focus on the authentication via authentication code due to its popularity (find validation that this is indeed the most popular option) and the availbiltiy of test profiles activation codes which is important for the fuzzing approach which is explained later (cite fuzzing section)
% - \textcite{ahmed_security_2024} packages the rsp into 4 major steps
% 1. mututal authentication: euicc and smdp perform mutual authentication via pki
% 2. profile binding: profile is bound to the euicc
% 3. profile download: euicc and smdp create secure channel over lpa, configure the isd-p on the euicc, and profile installation on the euicc
% 4. notification: profile installation notification is created, and processed to indicate a successful installation

% Mutual Authentication
% - euicc and smdpp perform mutual authentication over tls tunnel between lpa and smdpp
% - lpa initiates profile download and forwards messages between euicc and smdpp
% - euicc generates challenge and sends it together with CI root key to smdpp
% - smdpp returns signed euicc challenge, Cert Subject, transaction id and server challenge
% - euicc validates signature, signs profile identifier from activation code (and several other components), transaction id, server challenge, server address and other parts -> sends back to smdpp
% - based on identifier, smdpp selects profile for euicc

% - Note: Certs need to orginate from GSMA CI root which is validated by both the smdpp and euicc

% Profile binding
% - smdpp checks if profile is available for download
% - if available smdpp sends signed transaction id together with the profile binding key to the euicc
% - euicc validates signature and cert and checks that cert comes from authorized GSMA server

% Profile download
% - euicc and smdpp perform authenticated key exchange based on ECKA
% - smdpp encrypts profile with previously exchange session key and sends it to the euicc
% - euicc configures isdp, decrypts profile and installs it
% - profile is now ready to use

% Notification
% - profile download is finished and session keys are deleted
% - euicc creates signed notification including a sequence number and server address
% - lpa can initiate the processing of the notification -> send signed notification to smdpp
% - 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}.

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.

\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.}


SGP.22 defines three 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.
\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})

\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.

\paragraph{Profile Binding}

Upon successful authentication, the SM-DP+ checks 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.

\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.

\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.



