mirror of
https://sharelatex.tu-darmstadt.de/git/681e0e7a3a9c7c9c6b8bb298
synced 2025-12-08 05:27:59 +00:00
Update on Overleaf.
This commit is contained in:
nb72soza Bittner
212
Chapters/Background.tex
Normal file
212
Chapters/Background.tex
Normal file
@@ -0,0 +1,212 @@
|
||||
% !TeX root = ../Thesis.tex
|
||||
|
||||
%************************************************
|
||||
\chapter{Background}\label{ch:design}
|
||||
%************************************************
|
||||
\glsresetall % Resets all acronyms to not used
|
||||
|
||||
\section{Subscriber Identity Module}
|
||||
\label{sec:sim}
|
||||
|
||||
% - base is a smart card -> also used for bank cards, MIFARE cards, etc
|
||||
% - contains a CPU, ROM, RAM and can be connected via 8 PINS on the back side
|
||||
% - access is provided via the OS running on the card, offers file structure
|
||||
% - The os on the card can also run java card applets to provide additional functionality
|
||||
% - java card applets enable the use of the java language to be used on smart cards, use the Java Card Runtime Environment which runs inside the Java Card VM
|
||||
|
||||
The \gls{sim} card is a specialized type of smart card, a form factor also employed in applications such as banking (\eg, EMV cards) and access control (\eg, \gls{mifare} cards). As a smart card, a SIM contains essential computing components: a \gls{cpu}, \gls{rom}, and \gls{ram}, all of which are accessed through up to eight physical contacts (pins) on the card's surface~\cite{smartcard-standard}.
|
||||
|
||||
Interaction with the \gls{sim} is governed by an embedded operating system, which provides a standardized file system structure for data access and application management. In addition to storing subscriber data and cryptographic keys, the \gls{sim} operating system can execute Java Card applets to extend its functionality.
|
||||
|
||||
Java Card applets are applications written in a restricted subset of the Java programming language, specifically tailored for execution on constrained devices. They operate within the \gls{jcre}, which itself runs inside the \gls{jcvm}. This environment enables secure, platform-independent execution of custom logic directly on the \gls{sim} card, a capability that is heavily utilized in mobile network provisioning, secure authentication, and value-added services.
|
||||
|
||||
|
||||
\paragraph{Standards}
|
||||
% - how SIMs operate and function is defined by 3 parties: ETSI, 3GPP, and the GSMA
|
||||
% - ETSI: defines how the SIM works as a platform i.e UICC hardware, how APDU are structured and work, and the smart card file system (cite TS 131 221)
|
||||
% - 3GPP: defines how the SIMs are integrated into the mobile networks by defining the mobile broadband standards such as 5G and LTE
|
||||
% - GSMA: defines the funcitonal systems around the eSIM to make it usable in the real-world, i.e. in the context of eSIMs: RSP, LPA, SM-DP+, etc -> later (cite SGP.22)
|
||||
|
||||
The operation and functionality of \gls{sim} and \gls{esim} cards are defined and governed by three major standardization bodies: \gls{etsi}, \gls{3gpp}, and the \gls{gsma}. Each of these organizations contributes distinct specifications that together form the foundation of the \gls{sim} ecosystem.
|
||||
|
||||
The \gls{etsi} defines the \gls{sim} card as a smart card platform. This includes specifications for the physical \gls{uicc} hardware, the structure and semantics of \gls{apdu} commands, and the internal smart card file system. Notably, the ETSI standard TS 131 221 specifies the logical structure of the file system and the behavior of elementary and dedicated files~\cite{etsi-ts-131-221}.
|
||||
|
||||
The \gls{3gpp} focuses on how \gls{sim} cards integrate with mobile networks. This includes the specification of \gls{sim} functionalities required for network access in technologies such as \gls{lte}, \gls{5g}, and legacy systems. These standards ensure interoperability between SIMs and network infrastructure across vendors and operators.
|
||||
|
||||
The \gls{gsma} defines the higher-level functional architecture necessary to operationalize \gls{esim} technology in real-world deployments. This includes specifications such as the \gls{rsp} system, the \gls{lpa}, and the \gls{smdpp}, which together enable the remote provisioning, management, and activation of eSIM profiles. The GSMA's \gls{sgp22} specification is a cornerstone in this area, detailing the technical realization of the consumer remote \gls{sim} provisioning system~\cite{gsma_sgp22_2025}.
|
||||
|
||||
|
||||
|
||||
\paragraph{Transport Protocols}
|
||||
% - ETSI defines two protocols for communication: T=0 and T=1
|
||||
% - T=0: half-duplex asynchronos asynchronous character based transmission protocol
|
||||
% - T=1: half-duplex asynchronous block based transmission protocol, is in several ways more advanced than t=0: better error correction, APDU chaining, better in handling large APDUs etc, but also has more overhead due to block headers, control fields, way more complex in comparison to t=0 (cite TS 102 221)
|
||||
% - to the best of my knowledge t=1 is rarly used in consumer SIMs and eSIMs -> we will focus on t=0
|
||||
|
||||
Communication between the \gls{uicc} and the terminal is governed by transport protocols defined by the \gls{etsi} standard TS 102 221~\cite{etsi-ts-102-221}. Two primary protocols are specified: \textbf{T=0} and \textbf{T=1}.
|
||||
|
||||
T=0 is a half-duplex, asynchronous, character-based transmission protocol. It is relatively simple in design and is widely supported across devices due to its low overhead and ease of implementation. However, it lacks advanced features such as robust error correction and support for transmitting large \glspl{apdu} efficiently.
|
||||
|
||||
In contrast, T=1 is a half-duplex, asynchronous, block-oriented protocol. It introduces several enhancements over T=0, including improved error detection and correction mechanisms, APDU chaining for handling long messages, and more flexible flow control. These improvements come at the cost of increased complexity, as T=1 includes block headers, control fields, and more elaborate state handling. Due to this additional complexity and resource requirements, T=1 is, to the best of current knowledge, rarely employed in consumer-grade \gls{sim} or \gls{esim} cards.
|
||||
|
||||
Given this, the remainder of this work will focus on the T=0 protocol, which remains the dominant transport protocol in commercial \gls{uicc} deployments.
|
||||
|
||||
|
||||
\paragraph{Application/Transportation Protocol Data Unit}
|
||||
% - we differentiate between APDU (Application layer) and TPDUs (transport layer)
|
||||
% - when sending APDUS to the UICC wthe ETSI defines them as C-APDUs (command apdus) and the responses from the UICC as R-APDUs (response apdus)
|
||||
% - on the tansport layer those are C-TPDUs and R-TPDUs respectivly
|
||||
% - the apdus have the following structure (insert table for C-apdus and r-apdus)
|
||||
% - the status word (sw) in the r-apdu indictates a successfull execution or an error
|
||||
% - success are indicated by 9000
|
||||
% - sw with 61XX or 6CXX are used to control the exchange on the transport layer and indicate that the UICC has data to return where XX indicates the amount of bytes that are availble
|
||||
% - other responses indicate errors during the command processing or execution (cite eftlabs list of apdu responses)
|
||||
|
||||
In smart card communication, it is essential to distinguish between the application-layer protocol and the transport-layer protocol. At the application layer, the data units are referred to as \glspl{apdu}, while at the transport layer, they are termed \glspl{tpdu}. According to \gls{etsi} specifications, outgoing commands from the terminal to the \gls{uicc} are defined as \glspl{capdu}, and the responses from the UICC are defined as \glspl{rapdu}~\cite{etsi-ts-102-221}. On the transport layer, these correspond to \gls{ctpdu} and \gls{rtpdu}, respectively.
|
||||
|
||||
A C-APDU consists of mandatory header fields and optional data and length fields. An R-APDU typically includes the response data followed by a two-byte status word (\texttt{SW1} and \texttt{SW2}), which indicates the result of the command execution.
|
||||
|
||||
\begin{table}[h]
|
||||
\centering
|
||||
\caption{Structure of a \gls{capdu}}
|
||||
\begin{tabular}{|l|l|l|}
|
||||
\hline
|
||||
\textbf{Field name} & \textbf{Length} & \textbf{Description} \\
|
||||
\hline \hline
|
||||
$CLA$ & 1 & Instruction Class \\
|
||||
$INS$ & 1 & Instruction Code \ie "SELECT" \\
|
||||
$P1$ & 1 & Parameter 1 \\
|
||||
$P2$ & 1 & Parameter 2 \\
|
||||
$L_c$ & 0, 1 & Encodes length ($N_c$) of command data \\
|
||||
$Data$ & $N_c$ & Command data \\
|
||||
$L_e$ & 0, 1 & Encodes length ($N_e$) of expected response data \\
|
||||
\hline
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\begin{table}[h]
|
||||
\centering
|
||||
\caption{Structure of a \gls{rapdu}}
|
||||
\begin{tabular}{|l|l|l|}
|
||||
\hline
|
||||
\textbf{Field name} & \textbf{Length} & \textbf{Description} \\
|
||||
\hline \hline
|
||||
$Data$ & at most $N_e$ & Response Data \\
|
||||
$SW1$ & 1 & Status Word 1 \\
|
||||
$SW2$ & 1 & Status Word 1 \\
|
||||
\hline
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
The status word (SW) in an \gls{rapdu} signifies whether a command was successfully processed or if an error occurred. The value \texttt{9000} is used to indicate successful execution. Other status words serve specific purposes. For instance, \texttt{61XX} or \texttt{6CXX} indicate that additional data is available, where \texttt{XX} specifies the number of bytes remaining. These codes are particularly relevant for controlling \gls{apdu} exchanges at the transport layer. Other status word values denote different error conditions related to command structure, logical access violations, or execution faults~\cite{eftlabs-apdu-status}.
|
||||
|
||||
|
||||
|
||||
\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
|
||||
|
||||
\paragraph{Data Encoding}
|
||||
|
||||
When interacting with a \gls{uicc}, either to request or to store data, the command payload is typically structured using \gls{asn1} encoded in the \gls{ber}-\gls{tlv} format. \gls{asn1} is a formal language used to define data structures in a way that is independent of machine-specific encoding. It is a mature and widely adopted technology, particularly within the field of telecommunications, and is standardized by the ITU-T~\cite{oss-asn1}.
|
||||
|
||||
\gls{asn1} supports a variety of encoding rules. One of the most commonly used in the context of smart cards and mobile communications is the \gls{ber}. In \gls{ber}, all data is encoded as a sequence of \gls{tlv} elements. The \emph{Tag} identifies the type of data, the \emph{Length} specifies the number of bytes used for the value, and the \emph{Value} contains the actual data payload.
|
||||
|
||||
For example, consider the following simplified \texttt{STORE DATA} command that encodes an \texttt{EnableProfileRequest} as defined in the GSMA's \texttt{SGP.22} specification. The request uses the \gls{iccid} variant of the \texttt{profileIdentifier} field:
|
||||
|
||||
\begin{verbatim}
|
||||
BF31 10
|
||||
-- [49] SEQUENCE (EnableProfileRequest)
|
||||
5A 0A 89 10 20 30 40 50 60 70 80 90
|
||||
-- ICCID (tag 5A, 10 bytes)
|
||||
01 01 FF
|
||||
-- refreshFlag = TRUE (tag 01, length 1, value FF)
|
||||
\end{verbatim}
|
||||
|
||||
In this example:
|
||||
\begin{itemize}
|
||||
\item \texttt{BF31} is the context-specific tag for \texttt{EnableProfileRequest} (constructed, tag number 49).
|
||||
\item \texttt{5A} represents the \gls{iccid} field as defined in the \gls{gsma} \gls{asn1} specification.
|
||||
\item The ten-byte \gls{iccid} value shown here (\texttt{89 10 20 30 40 50 60 70 80 90}) is an example placeholder.
|
||||
\item The boolean \texttt{refreshFlag} is encoded using tag \texttt{01} and value \texttt{FF}, which represents \texttt{TRUE} in \gls{asn1}.
|
||||
\end{itemize}
|
||||
|
||||
The \gls{gsma} provides \gls{asn1} definitions for all standardized \gls{rsp} functions, including profile management procedures such as enabling or disabling profiles. These encoded messages are typically wrapped in a \texttt{STORE DATA} \gls{apdu} (instruction byte \texttt{E2}) and sent to the \gls{euicc} for execution.
|
||||
|
||||
|
||||
|
||||
\paragraph{File Structure}
|
||||
|
||||
% - the file structure on an UICC is organized as an forest of trees (cite TS 102 221
|
||||
% - Dedicated files (DF) allows for functional grouping of files
|
||||
% - Applicataion DF: special DF that contains all EFs and DFs of an application
|
||||
% - Elementary files (EF) are childs of DF, differntiate between transparent EF, lienar fixed EF, cyclic EF
|
||||
% - Files are identified with their unique File Identifier (FID), Applications with their unique Application Identifier (AID)
|
||||
% - path represents a concatenation of FIDs, starts with MF or DF, FID "7fff" represents current ADF
|
||||
% - Master File represents the root object from which all EF, DF and ADF orginate from
|
||||
% - to select an file or application: SELECT command with FID/AID, path or short FID
|
||||
% - selcting files is stateful i.e to select subsequent files, first select the parent file or application to access files in that application
|
||||
% - Proposed AIDs by the GSMA/GP for Applications: ISD-R ("A0000005591010FFFFFFFF8900000100"), ARA-M ("'A00000015141434C00'")
|
||||
% - actual AID is up to the manufcacturer, especially ISD-R AID is often changed as explained in section (ref section here)
|
||||
|
||||
The file system of a \gls{uicc} is organized as a hierarchical forest of trees, as specified in \cite{etsi102221}. At the top of the hierarchy resides the \gls{mf} (Master File), from which all other files—\glspl{df}, \glspl{ef}, and \glspl{adf}—originate.
|
||||
|
||||
\glspl{df} serve as containers that enable functional grouping of files. A special class of DF, called \glspl{adf}, encapsulates all files (EFs and optionally DFs) related to a specific application. Within these structures, \glspl{ef} act as leaf nodes and contain the actual data. There are three types of EFs: transparent EFs (byte-oriented, raw data), linear fixed EFs (record-based, fixed-length records), and cyclic EFs (circular buffers).
|
||||
|
||||
Each file is uniquely identified by a \gls{fid}, while applications are identified by their \gls{aid}. File paths are defined as a sequence of FIDs, typically starting from the MF or an ADF. The reserved FID \texttt{7FFF} refers to the currently selected ADF.
|
||||
|
||||
To access files, the \texttt{SELECT} command is used. This command supports various addressing modes: by FID, AID, complete path, or short FID. Importantly, file selection is stateful—meaning that parent files or applications must be selected before accessing child files.
|
||||
|
||||
Common AIDs proposed by the \gls{gsma} and \gls{gp} include the \gls{isdr} application (\texttt{A0000005591010FFFFFFFF8900000100}) and the \gls{aram} application (\texttt{A00000015141434C00}). However, the actual AIDs used are implementation-specific and may be customized by the manufacturer. The \gls{isdr} AID in particular is often modified, as discussed in Section~\ref{sec:isd-r-aid}.
|
||||
|
||||
\section{Embedded SIM}
|
||||
\label{sec:esim}
|
||||
|
||||
% - based on eUICC
|
||||
% - before: subscriber identity was bound to physical smart card (integrated during manufacturing) -> eSIM: decouples identiy from SIM -> virtualized and de-coupled from
|
||||
% - USIM, ISIM, other Applications, and associated file system data is now an eSIM profile, underlying chip is eUICC
|
||||
% - profiles can be issued remotly (sm-ds) or can be triggered by an user via the lpa (sm-dp+)
|
||||
|
||||
The concept of the \gls{esim} is based on the \gls{euicc}, which replaces the traditional removable SIM card form factor with a soldered chip that remains permanently embedded within the device.
|
||||
|
||||
Historically, the subscriber identity and related credentials were bound to a physical \gls{uicc} during the manufacturing process. This physical coupling meant that changing network operators or updating credentials required the replacement of the \gls{sim} card itself. The \gls{esim} paradigm disrupts this model by decoupling the subscription identity from the physical card. Instead, subscriber credentials, including applications such as \gls{usim}, \gls{isim}, and their associated file systems, are now encapsulated within a virtual entity referred to as an \textit{eSIM profile}.
|
||||
|
||||
These profiles reside on the underlying \gls{euicc} hardware and can be provisioned, activated, and managed remotely. Profile management is facilitated through standardized components defined by the \gls{gsma}—most notably the \gls{smdpp} and \gls{smds} servers. Profiles can either be delivered in a passive manner through the \gls{smdpp} when triggered by the end user, often via the \gls{lpa}, or actively pushed to the device through the \gls{smds}.
|
||||
|
||||
This architecture introduces a secure, remote provisioning mechanism and significantly enhances user flexibility, while simultaneously introducing new complexity in terms of protocol design, security guarantees, and implementation correctness.
|
||||
|
||||
|
||||
\paragraph{eUICC Components}
|
||||
|
||||
% - 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
|
||||
|
||||
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.
|
||||
|
||||
The \gls{ecasd} provides secure storage and cryptographic services. It maintains sensitive credentials such as the \gls{euicc} private key and certificate, the eUICC Identifier (\texttt{EID}), the \gls{euicc} Manufacturer (\gls{eum}) certificate, and the manufacturer key set used for credential updates. It is also responsible for generating digital signatures on data received from the \gls{isdr} and for verifying certificates during the authentication of the \gls{smdpp} or other remote entities.
|
||||
|
||||
The \gls{isdr} acts as the primary control authority on the \gls{euicc}. It manages the creation, activation, deactivation, and deletion of \glspl{isdp}. Only one of either \gls{isdr} or \gls{ecasd} can be present on a single \gls{euicc}, depending on the \gls{euicc}'s implementation mode.
|
||||
|
||||
Each \gls{isdp} hosts exactly one \gls{esim} profile and is responsible for profile download and installation. \glspl{isdp} may additionally host applets specific to the mobile network operator or service provider.
|
||||
|
||||
The \gls{aram}, as specified by \gls{gp}, governs access control for applications on the Secure Element. It aggregates access rules from multiple possible sources on the Secure Element and provides them in a standardized form. These rules are defined by the Secure Element issuer—typically the device manufacturer—and can restrict which device-side applications are permitted to communicate with the \gls{euicc} and its applets.
|
||||
|
||||
Together, these components establish the trust and management architecture necessary for secure and scalable remote SIM provisioning.
|
||||
|
||||
\section{eSIM on SIM}
|
||||
|
||||
\section{Remote SIM Provisioning}
|
||||
|
||||
\paragraph{Local Profile Assistant}
|
||||
|
||||
\paragraph{SM-DP+}
|
||||
Reference in New Issue
Block a user