Update on Overleaf.

Acronyms.tex

@@ -164,3 +164,7 @@
 
 \newacronym{imsi}{IMSI}{International Mobile Subscriber Identity}
 
+
+\newacronym{stk}{STK}{SIM Application Toolkit}
+\newacronym{usat}{USAT}{USIM Application Toolkit}
+\newacronym{rlpa}{RLPA}{Remote Local Profile Assistant}

Bibliography.bib

@@ -19,8 +19,8 @@
 	file = {PDF:/Users/privat/Zotero/storage/5BBQVAT6/SGP.22 v2.6 RSP Technical Specification.pdf:application/pdf},
 }
 
-@misc{etsi_etsi_1997,
-	title = {{ETSI} {GSM} 11.14 {SIM} {Application} {Toolkit}},
+@misc{etsi_gsm_1997,
+	title = {{GSM} 11.14 {SIM} {Application} {Toolkit}},
 	url = {https://www.etsi.org/deliver/etsi_gts/11/1114/05.04.00_60/gsmts_1114v050400p.pdf},
 	urldate = {2025-03-03},
 	author = {{ETSI}},
@@ -29,8 +29,8 @@
 	file = {PDF:/Users/privat/Zotero/storage/6TLW4EZW/ETSI GSM 11.14 SIM Application Toolkit.pdf:application/pdf},
 }
 
-@misc{etsi_etsi_2020,
-	title = {{ETSI} {TS} 131 111 {USIM} {Application} {Toolkit}},
+@misc{etsi_ts_2020,
+	title = {{TS} 131 111 {USIM} {Application} {Toolkit}},
 	url = {https://www.etsi.org/deliver/etsi_ts/131100_131199/131111/16.01.00_60/ts_131111v160100p.pdf},
 	urldate = {2025-03-03},
 	author = {{ETSI}},
@@ -48,8 +48,8 @@
 	file = {PDF:/Users/privat/Zotero/storage/XWXLNA5W/S@T 01.50 v4.0.0 S@T Browser Behavior Guidlines.pdf:application/pdf},
 }
 
-@misc{etsi_etsi_2023,
-	title = {{ETSI} {TS} 102 221 {V4}.10.0 {UICC}-{Terminal} interface},
+@misc{etsi_ts_2023,
+	title = {{TS} 102 221 {V4}.10.0 {UICC}-{Terminal} interface},
 	url = {https://www.etsi.org/deliver/etsi_ts/102200_102299/102221/04.10.00_60/ts_102221v041000p.pdf},
 	urldate = {2025-02-03},
 	author = {{ETSI}},
@@ -90,8 +90,8 @@
 	file = {Snapshot:/Users/privat/Zotero/storage/6IIWBLRP/estk-me-next-generation-removable-consumer-esim.html:text/html},
 }
 
-@misc{etsi_etsi_2022,
-	title = {{ETSI} {TS} 102 221 {V17}.1.0},
+@misc{etsi_ts_2022-1,
+	title = {{TS} 102 221 {Terminal} {Interface}},
 	url = {https://www.etsi.org/deliver/etsi_ts/102200_102299/102221/17.01.00_60/ts_102221v170100p.pdf},
 	urldate = {2025-02-16},
 	author = {{ETSI}},
@@ -425,3 +425,102 @@ C compilers is available on the web.},
 	year = {2025},
 	note = {original-date: 2022-10-25T09:34:57Z},
 }
+
+@misc{ort_writing_2001,
+	title = {Writing a {Java} {Card} {Applet}},
+	url = {https://www.oracle.com/java/technologies/java-card/javacard-applet.html#whatjavac},
+	urldate = {2025-05-13},
+	author = {Ort, Ed},
+	month = jan,
+	year = {2001},
+	file = {Writing a Java Card Applet:/Users/privat/Zotero/storage/P7WHIQEX/javacard-applet.html:text/html},
+}
+
+@misc{etsi_etsi_2020,
+	title = {{ETSI} {TS} 131 101 {3GPP} integration},
+	url = {https://www.etsi.org/deliver/etsi_ts/131100_131199/131101/16.00.00_60/ts_131101v160000p.pdf},
+	urldate = {2025-05-13},
+	author = {{ETSI}},
+	month = jul,
+	year = {2020},
+	file = {PDF:/Users/privat/Zotero/storage/UMVTLP9K/ts_131101v160000p.pdf:application/pdf},
+}
+
+@misc{etsi_etsi_2021,
+	title = {{ETSI} {TS} 102 221 {Terminal} {Interface}},
+	url = {https://www.etsi.org/deliver/etsi_ts/102200_102299/102221/16.06.00_60/ts_102221v160600p.pdf},
+	urldate = {2025-05-13},
+	author = {{ETSI}},
+	month = oct,
+	year = {2021},
+	file = {PDF:/Users/privat/Zotero/storage/HCNXBALK/ts_102221v160600p.pdf:application/pdf},
+}
+
+@misc{isoiec_isoiec_2006,
+	title = {{ISO}/{IEC} 7816-3},
+	url = {https://www.freecalypso.org/pub/GSM/ISO7816/ISO_7816-3_2006.pdf},
+	urldate = {2025-05-13},
+	author = {{ISO/IEC}},
+	month = nov,
+	year = {2006},
+	file = {PDF:/Users/privat/Zotero/storage/58QIFPW4/ISOIEC - 2006 - ISOIEC 7816-3.pdf:application/pdf},
+}
+
+@misc{eftlab_list_nodate,
+	title = {List of {APDU} responses},
+	url = {https://www.eftlab.com/knowledge-base/complete-list-of-apdu-responses},
+	urldate = {2025-05-13},
+	journal = {EFTlab - Breakthrough Payment Technologies},
+	author = {{EFTlab}},
+	file = {EFTlab - Breakthrough Payment Technologies:/Users/privat/Zotero/storage/XD6VW8D6/complete-list-of-apdu-responses.html:text/html},
+}
+
+@misc{oss_nokalva_asn1_nodate,
+	title = {{ASN}.1 {Introduction}},
+	url = {https://www.oss.com/asn1/resources/asn1-made-simple/introduction.html},
+	urldate = {2025-05-13},
+	journal = {ASN.1 Made Simple - Introduction},
+	author = {{OSS Nokalva}},
+	file = {ASN.1 Made Simple - Introduction:/Users/privat/Zotero/storage/SYR7T4NW/introduction.html:text/html},
+}
+
+@misc{globalplatform_secure_2014,
+	title = {Secure {Element} {Access} {Control} v1.1},
+	language = {en},
+	author = {{GlobalPlatform}},
+	month = sep,
+	year = {2014},
+	file = {PDF:/Users/privat/Zotero/storage/S6DJUWNA/Secure Element Access Control v1.1.pdf:application/pdf},
+}
+
+@misc{globalplatform_secure_2024,
+	title = {Secure {Element} {Access} {Control} v1.2},
+	language = {en},
+	author = {{GlobalPlatform}},
+	month = dec,
+	year = {2024},
+	file = {PDF:/Users/privat/Zotero/storage/A2LX9CP2/Secure Element Access Control v1.2.pdf:application/pdf},
+}
+
+@misc{estkme_rlpa-server_2025,
+	title = {rlpa-server},
+	copyright = {AGPL-3.0},
+	url = {https://github.com/estkme-group/rlpa-server},
+	abstract = {Remote LPA Server},
+	urldate = {2025-05-18},
+	publisher = {eSTK.me Group},
+	author = {{estk.me}},
+	month = apr,
+	year = {2025},
+	note = {original-date: 2024-06-15T14:06:07Z},
+}
+
+@misc{etsi_ts_2014,
+	title = {{TS} 102 223 {Card} {Application} {Toolkit}},
+	url = {https://www.etsi.org/deliver/etsi_ts/102200_102299/102223/12.01.00_60/ts_102223v120100p.pdf},
+	urldate = {2025-05-18},
+	author = {{ETSI}},
+	month = sep,
+	year = {2024},
+	file = {PDF:/Users/privat/Zotero/storage/2AETCTSV/ts_102223v120100p.pdf:application/pdf},
+}

Chapters/Background.tex

@@ -43,7 +43,7 @@ The \gls{gsma} defines the higher-level functional architecture necessary to ope
 % - 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-102-221}. Two primary protocols are specified: \textbf{T=0} and \textbf{T=1}. 
+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.
 
@@ -62,7 +62,7 @@ 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-102-221}. 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 \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.
 
@@ -98,7 +98,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{eftlabs-apdu-status}.
+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}.
 
 
 
@@ -110,7 +110,7 @@ The status word (SW) in an \gls{rapdu} signifies whether a command was successfu
 % - 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-asn1}.
+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.
 
@@ -151,7 +151,7 @@ The \gls{gsma} provides \gls{asn1} definitions for all standardized \gls{rsp} fu
 % - 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{etsi102221}. 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.
+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).
 
@@ -159,7 +159,7 @@ Each file is uniquely identified by a \gls{fid}, while applications are identifi
 
 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 Section~\ref{sec:isd-r-aid}.
+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}
@@ -179,6 +179,7 @@ This architecture introduces a secure, remote provisioning mechanism and signifi
 
 
 \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
@@ -189,7 +190,13 @@ This architecture introduces a secure, remote provisioning mechanism and signifi
 % - 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
 
-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.
+\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.
 
@@ -201,16 +208,115 @@ The \gls{aram}, as specified by \gls{gp}, governs access control for application
 
 Together, these components establish the trust and management architecture necessary for secure and scalable remote SIM provisioning.
 
-\section{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
+% - 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
-% - latter one produces the esim chips for apple 
+% - 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.
+
 
-\paragraph{Local Profile Assistant}
 
-\paragraph{SM-DP+}

Chapters/Evaluation.tex

@@ -8,6 +8,7 @@
 \section{Design}
 
 \section{Findings}
+\label{sec:findings}
 
 \section{estk Firmware Update Application}
 \lipsum[5]

Chapters/Implementation.tex

@@ -6,15 +6,21 @@
 \glsresetall % Resets all acronyms to not used
 
 \section{Tracing}
+\label{sec:tracing}
 
 \section{LPA}
+\label{sec:lpa}
 
 \section{Fuzzing}
+\label{sec:fuzzing}
 
 \subsection{Data Fuzzing}
+\label{subsec:data_fuzzing}
 
 \subsection{APDU Fuzzing}
+\label{subsec:apdu_fuzzing}
 
 \section{CLI}
+\label{sec:cli}
 
 \lipsum[4]