Update on Overleaf.

Chapters/Background.tex

@@ -37,7 +37,7 @@ Interaction with the \gls{sim} is governed by an embedded operating system \cite
 Java Card applets are applications written in a restricted subset of the Java programming language, specifically tailored for execution on constrained devices.\marginpar{Applets run in a secure JCVM environment.} 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.\cite{ort_writing_2001}
 
 
-\paragraph{Standards}
+\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
@@ -123,7 +123,7 @@ The main \gls{gsma} \gls{esim} specifications can be categorized as follows:
 \cref{tab:euicc_m2m_consumer} and \cref{tab:euicc_iot_infactory} compare the \gls{gsma} specifications and highlight their differences.
 
 
-\paragraph{Transport Protocols}
+\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)
@@ -138,7 +138,7 @@ In contrast, T=1 is a half-duplex, asynchronous, block-oriented protocol. It int
 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}
+\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
@@ -188,7 +188,7 @@ The status word (SW) in an R-APDU signifies whether a command was successfully p
 
 
 
-\paragraph{Data Encoding}
+\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
@@ -196,7 +196,7 @@ The status word (SW) in an R-APDU signifies whether a command was successfully p
 % - 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}, the command payload is typically structured using \gls{asn1} encoding 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.\marginpar{UICC payloads are encoded using ASN.1 in BER-TLV format.} 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}. Eventhough its an established encoding standard, it is still prone to be the source of bugs and security vulnerabilities \cite{nist_nvd_2024, nist_nvd_2025, mitre_cve_2003}.\marginpar{Despite maturity, ASN.1 encoding is a frequent source of security vulnerabilities.}
+When interacting with a \gls{uicc}, the command payload is typically structured using \gls{asn1} encoding 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.\marginpar{UICC payloads are encoded using ASN.1 in BER-TLV format.} 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}. Eventhough its an established encoding standard, it is still prone to be the source of bugs and security vulnerabilities \cite{nist_nvd_2024, nist_nvd_2025, mitre_cve_2003}.
 
 \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.
 
@@ -223,7 +223,7 @@ The \gls{gsma} provides \gls{asn1} definitions for all standardized \gls{rsp} fu
 
 
 
-\paragraph{File Structure}
+\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 
@@ -245,7 +245,7 @@ Each file is uniquely identified by a File Identifier (FID), while applications
 
 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.
 
-\paragraph{Application Toolkit}
+\paragraph{Application Toolkit.}
 
 The \gls{stk}/\gls{usat}, which are collectively referred to as the \gls{cat} in \gls{etsi} TS 102 223~\cite{etsi_ts_2014}, provides a proactive command framework for on-card applications. \gls{cat} functionalities are typically made available to end-users through standardized applications, known as \gls{sim} Toolkit apps that preinstalled on many mobile devices. These applications expose a menu-driven interface as shown in \cref{img:cat_interface}, that allows direct interaction with the \gls{esim} functionality embedded in the card, without requiring any additional software or manufacturer-specific \glspl{lpa}.\marginpar{SIM Toolkit apps expose CAT menus for user-driven card operations without the need for an LPA.} However, the amount of functionality provided over such interfaces still depends on the manufacturer and the implementation.
 The original \gls{stk}, introduced in \gls{etsi} 11.14~\cite{etsi_gsm_1997}, targets GSM \glspl{sim}, while the \gls{usat}, defined in \gls{etsi} TS 131 111~\cite{etsi_ts_2020}, extends these capabilities for \gls{uicc}/\gls{usim} environments. \gls{cat} unifies \gls{stk} and \gls{usat} under a single umbrella for all \gls{uicc}-based toolkits. These toolkits enable on-card applets to interact with the user equipment, displaying menus, sending SMS, downloading data, or even initiating \gls{esim} profile operations such as renaming or activation. Projects like \texttt{estk.me} have further enhanced this interface with “cloud-enhanced” \gls{rlpa}, which allows users to initiate profile provisioning directly via \gls{cat} menus without a separate \gls{lpa} client~\cite{estkme_rlpa-server_2025}. Other provisioning methods typically require a dedicated \gls{lpa} application on the device and cannot be facilitated through the \gls{cat} interface.
@@ -275,7 +275,7 @@ These profiles reside on the underlying \gls{euicc} hardware and can be provisio
 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}
+\paragraph{eUICC Components.}
 \label{par:euicc_components}
 
 % - to manage and issue newe eSIM profiles the eUICC needs some relevant Applications
@@ -314,7 +314,7 @@ These applications are typically addressed via their \glspl{aid}, some of which
 
 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}.
 
-\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
@@ -336,7 +336,7 @@ However, the actual \glspl{aid} used are implementation-specific and may be cust
 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.\marginpar{eSIM-on-SIM implementations enable use in legacy devices are equivalent to soldered eSIM`s.} 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{eum} and 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}
+\paragraph{Local Profile Assistant.}
 \label{par:lpa}
 
 \begin{figure}[t]
@@ -453,7 +453,7 @@ In this work, we focus on the Authentication Code method due to its prevalence i
     \end{tabular}
 \end{table}
 
-\paragraph{Mutual Authentication}
+\paragraph{Mutual Authentication.}
 
 As \cref{fig:mutual_authentication} shows, the \gls{rsp} process begins with mutual authentication between the \gls{euicc} and \gls{smdpp} over a \gls{tls} tunnel established via the \gls{lpa}. The \gls{euicc} generates a random challenge $N_U$ and sends it, along with its \gls{ci} Root public key certificate $SKI_{CI}$, to the \gls{smdpp}.\marginpar{Mutual authentication is performed between eUICC and SM-DP+ through the LPA.} The \gls{smdpp} responds with a signed version of the challenge $N_U$, its own certificate subject $S$, a transaction identifier $I_t$, and a server challenge $N_S$. The \gls{euicc} verifies the signature and certificate chain, signs the activation code’s profile identifier $I_{ac}$ (and other protocol elements), the transaction identifier $I_t$, the server challenge $N_S$, and relevant addresses, then returns this to the \gls{smdpp}. Based on the profile identifier, the \gls{smdpp} selects the appropriate profile for download. 
 
@@ -475,7 +475,7 @@ During the installation, a specific sequence of packages is exchanged between th
     \item The actual profile elements are loaded using the \texttt{sequence\-Of86} package.
 \end{enumerate}
 
-\paragraph{Notification}
+\paragraph{Notification.}
 
 After installation, session keys are erased and the \gls{euicc} generates a signed installation notification containing a sequence number and server address.\marginpar{LPA processes the notification, completing the provisioning process.} 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.