mirror of
https://sharelatex.tu-darmstadt.de/git/681e0e7a3a9c7c9c6b8bb298
synced 2025-12-07 05:08:01 +00:00
454 lines
39 KiB
TeX
454 lines
39 KiB
TeX
% !TeX root = ../Thesis.tex
|
||
|
||
%************************************************
|
||
\chapter{Background}\label{ch:background}
|
||
%************************************************
|
||
\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, MIFARE cards). As a smart card, a \gls{sim} contains essential computing components: a CPU, ROM, and RAM, all of which are accessed through up to eight physical contacts (pins) on the card's surface~\cite{etsi_ts_2003}.
|
||
|
||
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 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}
|
||
% - 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 \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 \glsposs{gsma} SGP.22 specification is a cornerstone in this area, detailing the technical realization of the consumer remote \gls{sim} provisioning system~\cite{gsma_sgp22_2025}.
|
||
|
||
% 4 main specifications
|
||
% machine-2-machine standard (SGP.01, SGP.02): industry focused -> mainly used in the automotive industry to enable eCall functionality
|
||
% SGP.22 consumer (SGP.21, SGP.22): for regular users -> used in smartphones and other consumer devices
|
||
% SGP.32 iot (SGP.31, SGP.32): for iot devices -> successor to m2m esim, supports 5g and NB-IoT, for sensors etc
|
||
% SGP.42 in factory (SGP.41, SGP.42) for cars and devices that immediate network connectivity after manufactoring -> mainly automotoive and iot industry
|
||
|
||
\begin{table}[ht]
|
||
\centering
|
||
\small
|
||
\begin{tabular}{|p{2.5cm}|p{4cm}|p{4cm}|}
|
||
\hline
|
||
\textbf{Attribute} & \textbf{M2M} & \textbf{Consumer} \\
|
||
\hline \hline
|
||
\gls{gsma} Specification & SGP.01 / \textbf{SGP.02} & SGP.21 / \textbf{SGP.22} \\
|
||
\hline
|
||
First Publication & 2013 & 2015/2016 \\
|
||
\hline
|
||
Use Case & \textbf{Devices with no user interface} (e.g., automotive, industrial) & \textbf{Devices with user interface} (e.g., smartphones, tablets) \\
|
||
\hline
|
||
Examples & Vehicles, smart meters, sensors & Smartphones, tablets, wearables \\
|
||
\hline
|
||
RSP Type & \textbf{Push} (centrally managed) & \textbf{Pull} (user-initiated) \\
|
||
\hline
|
||
\end{tabular}
|
||
\caption{Comparison of M2M and Consumer \gls{euicc} Types \cite{gd_rsp_nodate}}
|
||
\label{tab:euicc_m2m_consumer}
|
||
\end{table}
|
||
|
||
\begin{table}[ht]
|
||
\centering
|
||
\small
|
||
\begin{tabular}{|p{2.5cm}|p{4cm}|p{4cm}|}
|
||
\hline
|
||
\textbf{Attribute} & \textbf{IoT} & \textbf{In-Factory} \\
|
||
\hline \hline
|
||
\gls{gsma} Specification & SGP.31 / \textbf{SGP.32} & SGP.41 / \textbf{SGP.42} \\
|
||
\hline
|
||
First Publication & 2023/2024 & 2025 \\
|
||
\hline
|
||
Use Case & \textbf{UI/network-constrained IoT devices} & \textbf{Profile pre-loading during production} \\
|
||
\hline
|
||
Examples & Trackers, wearables, sensors, vehicles & Smartphones, wearables, meters \\
|
||
\hline
|
||
RSP Type & \textbf{Push} (server-driven) & \textbf{Push} (factory provisioned) \\
|
||
\hline
|
||
\end{tabular}
|
||
\caption{Comparison of \gls{iot} and In-Factory \gls{euicc} Types \cite{gd_rsp_nodate}}
|
||
\label{tab:euicc_iot_infactory}
|
||
\end{table}
|
||
|
||
The main \gls{gsma} \gls{esim} specifications can be categorized as follows:
|
||
\begin{itemize}
|
||
\item \textbf{Machine-to-Machine (M2M) Standard:}
|
||
Industry-focused specifications primarily used in the automotive sector to enable functionalities such as eCall.
|
||
|
||
\item \textbf{Consumer Standard:}
|
||
Targeted at regular users and implemented in smartphones and other consumer devices for remote \gls{sim} provisioning with focus on ease of use.
|
||
|
||
\item \textbf{\gls{iot} Standard:}
|
||
Successors to the M2M \gls{esim} standards, designed to support 5G and Narrowband-IoT (NB-IoT) connectivity for sensors and various \gls{iot} devices.
|
||
|
||
\item \textbf{In-Factory Standard:}
|
||
Released in February 2025 as version 1.0, the upcoming In-Factory Profile Provisioning (IFPP) standard targets devices, such as those in the automotive and IoT sectors, that require network connectivity immediately after or during production. It is specifically designed to enable profile installation during the manufacturing process. So far only the IFPP Architecture and Requirements Specifications SGP.41~\cite{gsma_sgp41_2025} have been released, with the IFPP Technical Specification SGP.42 still being actively developed.
|
||
|
||
\end{itemize}
|
||
|
||
\cref{tab:euicc_m2m_consumer} and \cref{tab:euicc_iot_infactory} compare the \gls{gsma} specifications and highlight their differences.
|
||
|
||
|
||
\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, \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.
|
||
|
||
|
||
\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 Command APDUs (C-APDU), and the responses from the UICC are defined as Response APDUs (R-APDU)~\cite{etsi_ts_2023}. On the transport layer, these correspond to Command APDUs and Response APDUs, respectively.
|
||
|
||
A C-APDU consists of mandatory header fields and optional data and length fields. An R-APDU typically includes the response data followed by a two-byte status word (\texttt{SW1} and \texttt{SW2}), which indicates the result of the command execution.
|
||
|
||
\begin{table}[h]
|
||
\centering
|
||
\caption{Structure of a C-APDU}
|
||
\begin{tabular}{|l|l|p{6cm}|}
|
||
\hline
|
||
\textbf{Field name} & \textbf{Length (bytes)} & \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 R-APDU}
|
||
\begin{tabular}{|l|l|l|}
|
||
\hline
|
||
\textbf{Field name} & \textbf{Length (bytes)} & \textbf{Description} \\
|
||
\hline \hline
|
||
$Data$ & at most $N_e$ & Response Data \\
|
||
$SW1$ & 1 & Status Word 1 \\
|
||
$SW2$ & 1 & Status Word 2 \\
|
||
\hline
|
||
\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}.
|
||
|
||
|
||
|
||
\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}, 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}.
|
||
|
||
\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 \glsposs{gsma} \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 \gls{adf}
|
||
% - Master File represents the root object from which all EF, DF and \gls{adf} orginate from
|
||
% - to select an file or application: SELECT command with FID/AID, path or short FID
|
||
% - selcting files is stateful i.e to select subsequent files, first select the parent file or application to access files in that application
|
||
% - Proposed AIDs by the GSMA/GP for Applications: ISD-R ("A0000005591010FFFFFFFF8900000100"), ARA-M ("'A00000015141434C00'")
|
||
% - actual AID is up to the manufcacturer, especially ISD-R AID is often changed as explained in section (ref section here)
|
||
|
||
The file system of a \gls{uicc} is organized as a hierarchical forest of trees, as specified in \cite{etsi_ts_2023}. At the top of the hierarchy resides the 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).
|
||
|
||
Each file is uniquely identified by a File Identifier (FID), while applications are identified by their \gls{aid}. File paths are defined as a sequence of FIDs, typically starting from the MF or an \gls{adf}. The reserved FID \texttt{7FFF} refers to the currently selected \gls{adf}.
|
||
|
||
To access files, the \texttt{SELECT} command is used. This command supports various addressing modes: by FID, \gls{aid}, complete path, or short FID. Importantly, file selection is stateful—meaning that parent files or applications must be selected before accessing child files.
|
||
|
||
Common \glspl{aid} proposed by the \gls{gsma} and \gls{gp} include the \gls{isdr} application and the \gls{aram} application.
|
||
|
||
\begin{itemize}
|
||
\item \gls{isdr} \texttt{A0000005591010FFFFFFFF8900000100}
|
||
\item \gls{aram} \texttt{A00000015141434C00}
|
||
\end{itemize}
|
||
|
||
However, the actual \glspl{aid} used are implementation-specific and may be customized by the manufacturer. The \gls{isdr} \gls{aid} in particular is often modified, as discussed in \cref{sec:eval_tracing}.
|
||
|
||
\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 remote provisioning mechanism and significantly enhances user flexibility, while simultaneously introducing new complexity in terms of protocol design 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{\gls{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 \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{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. 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.
|
||
|
||
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 \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}
|
||
\label{par:lpa}
|
||
|
||
\begin{figure}[h!]
|
||
\centering
|
||
\includegraphics[width=.32\textwidth]{Graphics/lpa_easyeuicc.jpg}
|
||
\includegraphics[width=.32\textwidth]{Graphics/lpa_9esim.jpg}
|
||
\includegraphics[width=.32\textwidth]{Graphics/lpa_5ber.jpg}
|
||
\caption{\gls{lpa} interface of the open-source EasyEUICC App~\cite{petercxy_openeuicc_nodate}, 9esim v2 (rebranded version of the open-source NekokoLPA~\cite{iebb_nekokolpa_nodate}, and proprietary 5ber App.}
|
||
\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.
|
||
|
||
\begin{figure}[h!]
|
||
\includegraphics[width=\textwidth]{Graphics/rsp_architecture.png}
|
||
\caption[\gls{rsp} architecture~\cite{gsma_sgp22_2024} consisting of the \gls{lpa}, \gls{euicc}, \gls{smds}, and \gls{smdpp}.]{\gls{rsp} architecture~\cite{gsma_sgp22_2024} consisting of the \gls{lpa}~\footnotemark, \gls{euicc}, \gls{smds}, and \gls{smdpp}.}
|
||
\label{img:rsp_architecture}
|
||
\end{figure}
|
||
\footnotetext{The components referred to as the Local Profile Assistant when LPA is in the Device
|
||
(LPAd) in this thesis, namely the Local Discovery Service when LPA is in the Device
|
||
(LDSd), Local Profile Download when LPA is in the Device (LPDd), and Local User
|
||
Interface when LPA is in the Device (LUId), are collectively simplified and referred to as \gls{lpa} for readability.}
|
||
|
||
\paragraph{Application Toolkit}
|
||
|
||
The \gls{stk}/\gls{usat}, which are collectively referred to as the \gls{cat} in \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 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}[h!]
|
||
\centering
|
||
\includegraphics[width=.45\textwidth]{Graphics/cat_9esimv2_cardinfo.jpg}
|
||
\includegraphics[width=.45\textwidth]{Graphics/cat_9esimv2_profile_info.jpg}
|
||
\caption{\gls{cat} interfaces of the 9esim v2 card showing the card and profile info.}
|
||
\label{img:cat_interface}
|
||
\end{figure}
|
||
|
||
|
||
|
||
\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 \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}.
|
||
|
||
|
||
SGP.22 defines three \gls{rsp} initiation methods:
|
||
\begin{enumerate}
|
||
\item \textbf{Default Server}: The \gls{smdpp} address is pre-configured on the \gls{euicc} at manufacture time and points to a operator controlled server. The user triggers provisioning via the default server if no other address is given by the profile.
|
||
\item \textbf{Authentication Code}: The user is provided with an activation code (containing the \gls{smdpp} address and optional confirmation code) when purchasing service. The \gls{lpa} contacts the \gls{smdpp} and, after mutual authentication, may require entry of the confirmation code.
|
||
\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})
|
||
|
||
\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}[h!]
|
||
\centering
|
||
\includesvg[width=1.3\textwidth]{Graphics/mutual_authentication_sd.svg}
|
||
\caption{Sequence diagram of the mutual authentication.\cite{ahmed_security_2024}}
|
||
\label{fig:mutual_authentication}
|
||
\end{figure}
|
||
|
||
\begin{table}[h!]
|
||
\centering
|
||
\caption{Notation for mutual authentication sequence diagram.\cite{ahmed_security_2024}}
|
||
\label{tab:notiation}
|
||
\begin{tabular}{l p{8cm}}
|
||
\toprule
|
||
\textbf{Symbol} & \textbf{Description} \\
|
||
\midrule
|
||
$U$ & \gls{eid} \\
|
||
$S$ & Server domain name \\
|
||
\text{userId} & User identity authenticated by \gls{mno} & \\
|
||
$\text{iccid}$ & Unique identifier of the \gls{sim} profile \ie \gls{iccid}\\
|
||
$I_{ac}$ & Matching identifier in activation code \\
|
||
$\mathrm{SKI}_{CI}$ & SubjectKeyIdentifier of $\mathrm{Cert}_{CI}$ \\
|
||
$N_U := R,\ N_S := R$ & Random numbers generated by \gls{euicc} and server \\
|
||
$I_t := R$ & Random session identifier generated by server \\
|
||
$\mathrm{Sign}(M;\ SK)$ & Signature of message $M$ with private key $SK$ \\
|
||
\text{serverOID}& Server OID in $\mathrm{Cert}_{Sa}$ and $\mathrm{Cert}_{Sp}$ \\
|
||
\text{subject of Cert} & Subject identifier to which certificate was issued \\
|
||
$\mathrm{Cert}_a \triangleleft \mathrm{Cert}_b$ & Certificates, check that $\mathrm{Cert}_a$ is signed by the subject key of $\mathrm{Cert}_b$ \\
|
||
\bottomrule
|
||
\end{tabular}
|
||
\end{table}
|
||
|
||
\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.
|
||
|
||
\paragraph{Profile Binding}
|
||
|
||
Upon successful authentication, the \gls{smdpp} checks for profile availability and then sends the signed transaction identifier plus the profile-binding key to the \gls{euicc}. The \gls{euicc} validates the signature against the \gls{gsma} \gls{ci} Root and ensures the certificate is authorized.
|
||
|
||
\paragraph{Profile Download}
|
||
|
||
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.
|
||
|
||
\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.
|
||
|
||
|
||
|