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-15 15:59:23 +00:00
committed by node
parent ab40f6e909
commit e702a2aa6f
11 changed files with 864 additions and 723 deletions
Download Patch File Download Diff File Expand all files Collapse all files

76
Chapters/Background.tex
View File

@@ -5,7 +5,21 @@
%************************************************
\glsresetall % Resets all acronyms to not used
\todo{Overview of esim stack}
The \gls{esim} communication architecture consists of interrelated components distributed across the user device, the \gls{euicc}, and remote network-side infrastructure as shown in \cref{img:esim_overview}. At the heart of this system lies the \gls{lpa}, a software component running on the user device.\marginpar{eSIM architecture consists of device, eUICC, and remote infrastructure components.} The \gls{lpa} is responsible for initiating and managing the download, installation, and activation of \gls{esim} profiles. It communicates with the \gls{euicc} via a standardized \glspl{apdu}.
The \gls{euicc} is an embedded element within the device that hosts multiple functional domains. These include the \gls{isdr}, \gls{ecasd}, and \gls{aram}. Crucially, the \gls{euicc} also contains one or more profiles, each encapsulated within its own \gls{isdp}. A profile includes a file system hierarchy and applets necessary for mobile network operation.
On the network side, two entities play essential roles. The \gls{smdpp} prepares and securely delivers profile packages to the device, while the \gls{smds} acts as a directory service, enabling the device to discover available profiles.
This architecture enables secure, remote provisioning and lifecycle management of mobile subscriptions across a variety of device types, while ensuring strict isolation between profiles and robust authentication mechanisms throughout the process.\marginpar{Architecture ensures secure, remote subscription management for eSIM profiles.}
The following sections will provide a detailed analysis of each of these core components, including their roles, interfaces, and interactions in the \gls{esim} communication stack.
\begin{figure}[t]
\includesvg[width=\textwidth,inkscapelatex=false]{Graphics/esim_overview.svg}
\caption{High-level overview of the \gls{esim} communication stack.}
\label{img:esim_overview}
\end{figure}
\section{Subscriber Identity Module}
\label{sec:sim}
@@ -20,7 +34,7 @@ The \gls{sim} card is a specialized type of smart card, a form factor also emplo
Interaction with the \gls{sim} is governed by an embedded operating system \cite{etsi_ts_2022-1, globalplatform_gp_2018}, 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 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}
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}
@@ -30,14 +44,14 @@ Java Card applets are applications written in a restricted subset of the Java pr
% - 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)
Identification cards such as \glspl{sim} and \glspl{esim} are fundamentally built upon the ISO/IEC 7816 standard \cite{iso_isoiec_2019}, which defines key aspects of smart cards with contacts. This includes specifications for the physical characteristics, contact positioning, electrical interface, transmission protocols, and command structure. These foundational definitions are essential for the development of both traditional \glspl{uicc} and embedded \glspl{euicc}, ensuring baseline interoperability and functionality across compliant hardware platforms.
\marginpar{SIM functionality is governed by ETSI, 3GPP, and GSMA standards.}
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 \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 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 as described in \cref{sec:rsp}, and the \gls{lpa} aswell as the \gls{smdpp} in \cref{par:euicc_components}, which together enable the remote provisioning, management, and activation of \gls{esim} profiles.
The \gls{gsma} defines the higher-level functional architecture necessary to operationalize \gls{esim} technology in real-world deployments.\marginpar{GSMA defines the eSIM architecture, including RSP, LPA, and SM-DP+.} This includes specifications such as the \gls{rsp} system as described in \cref{sec:rsp}, and the \gls{lpa} aswell as the \gls{smdpp} in \cref{par:euicc_components}, 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
@@ -118,7 +132,7 @@ The main \gls{gsma} \gls{esim} specifications can be categorized as follows:
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.
\marginpar{UICC communication uses ETSI-defined T=0 and T=1 transport protocols.}
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.
@@ -134,7 +148,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 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.
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}.\marginpar{APDUs/TPDUs are used for communication between UICC and terminal.} 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.
@@ -170,7 +184,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 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}.
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.\marginpar{Status words indicate APDU command success or error conditions.} 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}.
@@ -182,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. 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}.
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.}
\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.
@@ -204,7 +218,7 @@ In this example:
\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}
\marginpar{Encoded messages are sent using STORE DATA APDUs to the eUICC.}
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.
@@ -225,7 +239,7 @@ The \gls{gsma} provides \gls{asn1} definitions for all standardized \gls{rsp} fu
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.
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).
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.\marginpar{Files are addressed by FIDs and applications use AIDs for identification.} 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 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}.
@@ -233,7 +247,7 @@ To access files, the \texttt{SELECT} command is used. This command supports vari
\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}. However, the amount of functionality provided over such interfaces still depends on the manufacturer and the implementation.
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.
\begin{figure}[t]
@@ -254,7 +268,7 @@ The original \gls{stk}, introduced in \gls{etsi} 11.14~\cite{etsi_gsm_1997}, tar
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}.
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.\marginpar{eSIM decouples identity from hardware via remotely managed virtualized profiles.} 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} as shown in \cref{img:rsp_architecture}.
@@ -281,18 +295,18 @@ This architecture introduces a remote provisioning mechanism and significantly e
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 \gls{eid}, the \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.Typically, the stored certificates and cryptographic keys within the \gls{ecasd} are immutable and cannot be updated, and as a result, they are provisioned with a validity period of approximately 25 years \cite{welte_euicc_2024}.
The \gls{ecasd} provides secure storage and cryptographic services. It maintains sensitive credentials such as the \gls{euicc} private key and certificate, the \gls{eid}, the \gls{eum} certificate, and the manufacturer key set used for credential updates. \marginpar{ECASD securely stores keys, certificates, and handles crypto operations.} 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.Typically, the stored certificates and cryptographic keys within the \gls{ecasd} are immutable and cannot be updated, and as a result, they are provisioned with a validity period of approximately 25 years \cite{welte_euicc_2024}.
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.
The \gls{isdr} acts as the primary control authority on the \gls{euicc}. It manages the creation, activation, deactivation, and deletion of \glspl{isdp}.\marginpar{ISD-R controls profile lifecycle: creation, activation, deletion, and switching.} Only one of either \gls{isdr} or \gls{ecasd} can be present on a single \gls{euicc}, depending on the \glsposs{euicc} 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. 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} \cite{globalplatform_secure_2024}, 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.
The \gls{aram}, as specified by \gls{gp} \cite{globalplatform_secure_2024}, governs access control for applications on the Secure Element.\marginpar{ARA-M enforces access rules for manufacturer defined LPA’s.} 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.
These applications are typically addressed via their \glspl{aid}, some of which are standardized by the \gls{gsma} and \gls{gp} to ensure interoperability across implementations, others are defined by the \gls{mno}. Standardized \glspl{aid} allow external entities, such as the \gls{lpa}, to reliably identify and interact with specific applications on the card.
\marginpar{AIDs may be vendor-specific and are often modified in practice.}
\begin{itemize}
\item \gls{isdr}: \texttt{A0000005591010FFFFFFFF8900000100}
\item \gls{aram}: \texttt{A00000015141434C00}
@@ -319,7 +333,7 @@ However, the actual \glspl{aid} used are implementation-specific and may be cust
% - 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 \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.
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}
@@ -334,7 +348,7 @@ In many modern devices, the most common integration of an \gls{esim} is as a sol
\label{img:lpa_interfaces}
\end{figure}
The \gls{lpa} is a user-facing application (i.e an App on a smartphone) on the \gls{ue} that interacts with the \gls{euicc}, enabling users to initiate profile provisioning and perform lifecycle management operations such as enabling, disabling, or deleting profiles. \cref{img:lpa_interfaces} shows 3 different \gls{lpa} implementions that enable such functionality. The \gls{smdpp} is a server—operated by an \gls{euicc} manufacturer, \gls{mno}, or third party, that securely hosts \gls{esim} profiles and makes them available for download. The \gls{smds} facilitates the "push" provisioning approach, where the operator notifies the \gls{lpa} via the \gls{smds} that an profile is ready download. The \gls{lpa} then downloads and installs this profile from the \gls{smdpp} server onto the \gls{euicc} with the information provided by the \gls{smds}. This approach is less common in consumer scenarios.
The \gls{lpa} is a user-facing application (i.e an App on a smartphone) on the \gls{ue} that interacts with the \gls{euicc}, enabling users to initiate profile provisioning and perform lifecycle management operations such as enabling, disabling, or deleting profiles. \cref{img:lpa_interfaces} shows 3 different \gls{lpa} implementions that enable such functionality.\marginpar{The LPA is a user-facing app for managing eSIM profiles.} The \gls{smdpp} is a server—operated by an \gls{euicc} manufacturer, \gls{mno}, or third party, that securely hosts \gls{esim} profiles and makes them available for download. The \gls{smds} facilitates the "push" provisioning approach, where the operator notifies the \gls{lpa} via the \gls{smds} that an profile is ready download. The \gls{lpa} then downloads and installs this profile from the \gls{smdpp} server onto the \gls{euicc} with the information provided by the \gls{smds}. This approach is less common in consumer scenarios.
\begin{figure}[t]
\includegraphics[width=\textwidth]{Graphics/rsp_architecture.png}
@@ -392,22 +406,22 @@ Interface when LPA is in the Device (LUId), are collectively simplified and refe
% - 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 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}.
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}.\marginpar{RSP enables eSIM profile provisioning.} 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} as shown in \cref{img:rsp_architecture}.
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{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. \marginpar{SGP.22 defines three RSP initiation methods: Default Server, Authentication Code, and SM-DS Assisted provisioning.}
\item \textbf{Authentication Code}: The user is provided with an activation code (containing the \gls{smdpp} address and optional confirmation code) when purchasing service. The \gls{lpa} contacts the \gls{smdpp} and, after mutual authentication, may require entry of the confirmation code.
\item \textbf{\gls{smds} Assisted}: The \gls{lpa} polls the \gls{smds} for an event matching the \gls{eid} of the \gls{euicc}. If a download event exists, the \gls{smds} supplies the \gls{smdpp} address to the \gls{lpa} for profile download.
\end{enumerate}
In this work, we focus on the Authentication Code method due to its prevalence in commercial \gls{esim} deployments and the ready availability of test activation codes—critical for our differential-testing and fuzzing methodology (see~\cref{sec:fuzzing})
In this work, we focus on the Authentication Code method due to its prevalence in commercial \gls{esim} deployments and the ready availability of test activation codes, critical for our differential-testing and fuzzing methodology (see~\cref{sec:fuzzing})
\textcite{ahmed_security_2024} packages the \gls{rsp} into four major steps: mutual authentication, profile binding, profile download (including authenticated key exchange), and notification.
\begin{figure}[t]
\begin{adjustwidth}{-1.5in}{-.5in}
\begin{adjustwidth}{-.5in}{-1.5in}
\centering
\includesvg[width=1.3\textwidth]{Graphics/mutual_authentication_sd.svg}
\caption{Sequence diagram of the mutual authentication.\cite{ahmed_security_2024}}
@@ -441,7 +455,7 @@ In this work, we focus on the Authentication Code method due to its prevalence i
\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}. 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.
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.
\paragraph{Profile Binding}
@@ -451,11 +465,19 @@ Upon successful authentication, the \gls{smdpp} checks for profile availability
Next, the \gls{euicc} and \gls{smdpp} perform an \gls{ecka} to derive session keys. The \gls{smdpp} encrypts the profile using the session key and transmits it to the \gls{euicc}. The \gls{euicc} configures the new \gls{isdp}, decrypts the profile, and installs it. The profile is then ready for use.
\todo{Explain what sequenceOf87, sequenceOf88, etc is because we are using this later on}
During the installation, a specific sequence of packages is exchanged between the \gls{smdpp} and the \gls{euicc}:
\marginpar{eUICC installs the profile and prepares the ISD-P.}
\begin{enumerate}
\item A secure channel is initialized using the \texttt{initialiseSecure\-Channel} package.
\item The \gls{isdp} is configured via the \texttt{firstSequence\-Of87} package.
\item Profile metadata is stored in the \gls{isdp} using the \texttt{sequence\-Of88} package.
\item Dession keys are replaced by profile-specific Profile Protection Keys using the \texttt{second\-Sequence\-Of87} package.
\item The actual profile elements are loaded using the \texttt{sequence\-Of86} package.
\end{enumerate}
\paragraph{Notification}
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.
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.
\section{Fuzzing}
@@ -481,7 +503,7 @@ After installation, session keys are erased and the \gls{euicc} generates a sign
% other option: use differential testing -> compare output of two programs that should behave the same when giving the same input
% we cant inject assertions -> opted for option 2 i.e differntial testing
Fuzzing is a well-established technique for uncovering software bugs and security vulnerabilities through the automated generation of test inputs. It has contributed to the discovery of thousands of critical security issues~\cite{arya_oss-fuzz_2025} across various domains. The fundamental principle behind fuzzing is to provide a target system with a large number of automatically generated inputs, ranging from completely random to well-structured, and monitor the system's behavior for anomalies such as crashes, unexpected outputs, or assertion failures.
Fuzzing is a well-established technique for uncovering software bugs and security vulnerabilities through the automated generation of test inputs. It has contributed to the discovery of thousands of critical security issues~\cite{arya_oss-fuzz_2025} across various domains.\marginpar{Fuzzing uncovers bugs by feeding systems large volumes of generated test inputs.} The fundamental principle behind fuzzing is to provide a target system with a large number of automatically generated inputs, ranging from completely random to well-structured, and monitor the system's behavior for anomalies such as crashes, unexpected outputs, or assertion failures.
Traditionally, fuzzers attempt to explore edge cases and increase code coverage, aiming to execute as many distinct code paths as possible. Depending on the level of insight into the internal structure of the system under test, fuzzers are commonly classified into three categories \cite{chen_systematic_2018}:
@@ -494,7 +516,7 @@ Traditionally, fuzzers attempt to explore edge cases and increase code coverage,
\end{itemize}
A critical aspect of effective fuzzing is the ability to differentiate between expected and unexpected behavior. In traditional fuzzing scenarios, this is often accomplished using sanitizers and runtime assertions, which cause the target program to fail explicitly when a bug is detected. However, such instrumentation is typically infeasible in closed-source or hardware-backed environments such as commercial \gls{esim} implementations~\cite{zaddach_avatar_2014}.
\marginpar{This work uses differential testing to detect inconsistencies across implementations.}
Given these constraints, this thesis adopts a \textit{differential testing} approach to fuzzing. Instead of relying on internal instrumentation or assertions, the framework can compare the responses of multiple independent implementations of the same specification to identical fuzzed inputs. Any divergence in the observed behavior may indicate a potential bug, inconsistency in interpretation of the specification, or a security-relevant anomaly.
This methodology is particularly well-suited for black-box systems like eSIM-on-SIM cards, where internal state and logic are inaccessible.