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-06 10:44:03 +00:00
committed by node
parent b6be91e4d9
commit 9e6e16c2f6
5 changed files with 46 additions and 22 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
Chapters/Background.tex
View File

@@ -178,7 +178,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}, either to request or to store data, the command payload is typically structured using \gls{asn1} encoded in the \gls{ber}-\gls{tlv} format. \gls{asn1} is a formal language used to define data structures in a way that is independent of machine-specific encoding. It is a mature and widely adopted technology, particularly within the field of telecommunications, and is standardized by the ITU-T~\cite{oss_nokalva_asn1_nodate}. 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}, either to request or to store data, 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.
@@ -273,7 +273,7 @@ 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 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.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. 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.
@@ -302,7 +302,7 @@ Together, these components establish the trust and management architecture neces
% - 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{euicc} manufacturer—they 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. 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}
@@ -331,7 +331,7 @@ Interface when LPA is in the Device (LUId), are collectively simplified and refe
\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 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}. 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!]
@@ -413,22 +413,22 @@ In this work, we focus on the Authentication Code method due to its prevalence i
\centering
\caption{Notation for mutual authentication sequence diagram.\cite{ahmed_security_2024}}
\label{tab:notiation}
\begin{tabular}{l p{6.5cm} l}
\begin{tabular}{l p{8cm}}
\toprule
\textbf{Symbol} & \textbf{Description} & \textbf{GSMA} \\
\textbf{Symbol} & \textbf{Description} \\
\midrule
$U$ & \gls{euicc} identifier & EID \\
$U$ & \gls{eid} \\
$S$ & Server domain name \\
\text{userId} & User identity authenticated by \gls{mno} & \\
$\text{iccid}$ & Unique identifier of the SIM profile & 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$ & \\
$\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}