mirror of
https://sharelatex.tu-darmstadt.de/git/681e0e7a3a9c7c9c6b8bb298
synced 2025-12-07 05:08:01 +00:00
Update on Overleaf.
This commit is contained in:
nb72soza Bittner
107
Bibliography.bib
107
Bibliography.bib
@@ -568,24 +568,34 @@ C compilers is available on the web.},
|
||||
month = may,
|
||||
year = {2025},
|
||||
note = {original-date: 2015-06-16T18:25:06Z},
|
||||
keywords = {apdu, pcsc, pyscard, python, python3, smartcard, smartcard-library, travis-ci},
|
||||
keywords = {smartcard, apdu, pcsc, pyscard, python, python3, smartcard-library, travis-ci},
|
||||
}
|
||||
|
||||
@article{fioraldi_afl_nodate,
|
||||
title = {{AFL}++: {Combining} {Incremental} {Steps} of {Fuzzing} {Research}},
|
||||
abstract = {In this paper, we present AFL++, a community-driven opensource tool that incorporates state-of-the-art fuzzing research, to make the research comparable, reproducible, combinable and — most importantly – useable. It offers a variety of novel features, for example its Custom Mutator API, able to extend the fuzzing process at many stages. With it, mutators for specific targets can also be written by experienced security testers. We hope for AFL++ to become a new baseline tool not only for current, but also for future research, as it allows to test new techniques quickly, and evaluate not only the effectiveness of the single technique versus the state-of-theart, but also in combination with other techniques. The paper gives an evaluation of hand-picked fuzzing technologies —shining light on the fact that while each novel fuzzing method can increase performance in some targets — it decreases performance for other targets. This is an insight future fuzzing research should consider in their evaluations.},
|
||||
language = {en},
|
||||
author = {Fioraldi, Andrea and Maier, Dominik and Eißfeldt, Heiko and Heuse, Marc},
|
||||
file = {PDF:/Users/privat/Zotero/storage/QNMM4NBX/Fioraldi et al. - AFL++ Combining Incremental Steps of Fuzzing Research.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@misc{corcoran_pcsc-lite_2025,
|
||||
title = {pcsc-lite: {MUSCLE} {PC}/{SC}-{Lite} {API} {Documentation}},
|
||||
url = {https://pcsclite.apdu.fr/api/index.html},
|
||||
urldate = {2025-06-24},
|
||||
journal = {MUSCLE PC/SC-Lite API Documentation},
|
||||
author = {Corcoran, David and Rousseau, Ludovic},
|
||||
year = {2025},
|
||||
file = {pcsc-lite\: MUSCLE PC/SC-Lite API Documentation:/Users/privat/Zotero/storage/MIGD3JM4/index.html:text/html},
|
||||
}
|
||||
|
||||
@misc{nist_nvd_2025,
|
||||
title = {{NVD} - {CVE}-2025-0343},
|
||||
url = {https://nvd.nist.gov/vuln/detail/CVE-2025-0343},
|
||||
urldate = {2025-06-30},
|
||||
author = {{NIST}},
|
||||
year = {2025},
|
||||
file = {NVD - CVE-2025-0343:/home/niklas/Zotero/storage/D6K8HLIX/CVE-2025-0343.html:text/html},
|
||||
}
|
||||
|
||||
@misc{mitre_cve_2003,
|
||||
title = {{CVE} - {CVE}-2003-0818},
|
||||
url = {https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0818},
|
||||
urldate = {2025-06-30},
|
||||
author = {{MITRE}},
|
||||
year = {2003},
|
||||
file = {CVE - CVE-2003-0818:/home/niklas/Zotero/storage/8NTHT84Y/cvename.html:text/html},
|
||||
file = {NVD - CVE-2025-0343:/Users/privat/Zotero/storage/D6K8HLIX/CVE-2025-0343.html:text/html},
|
||||
}
|
||||
|
||||
@misc{nist_nvd_2024,
|
||||
@@ -594,5 +604,78 @@ C compilers is available on the web.},
|
||||
urldate = {2025-06-30},
|
||||
author = {{NIST}},
|
||||
year = {2024},
|
||||
file = {NVD - CVE-2024-6197:/home/niklas/Zotero/storage/PMM5K88C/CVE-2024-6197.html:text/html},
|
||||
file = {NVD - CVE-2024-6197:/Users/privat/Zotero/storage/PMM5K88C/CVE-2024-6197.html:text/html},
|
||||
}
|
||||
|
||||
@misc{mitre_cve_2003,
|
||||
title = {{CVE} - {CVE}-2003-0818},
|
||||
url = {https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0818},
|
||||
urldate = {2025-06-30},
|
||||
author = {{MITRE}},
|
||||
year = {2003},
|
||||
file = {CVE - CVE-2003-0818:/Users/privat/Zotero/storage/8NTHT84Y/cvename.html:text/html},
|
||||
}
|
||||
|
||||
@misc{gsma_sgp21_2023,
|
||||
title = {{SGP}.21 v3.1 {RSP} {Architecture}},
|
||||
url = {https://www.gsma.com/solutions-and-impact/technologies/esim/wp-content/uploads/2023/12/SGP.21-V3.1.pdf},
|
||||
urldate = {2025-06-22},
|
||||
author = {{GSMA}},
|
||||
year = {2023},
|
||||
file = {PDF:/Users/privat/Zotero/storage/KSQP8T2D/SGP.21-V3.1.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@misc{gsma_sgp21_2015,
|
||||
title = {{SGP}.21 v1.01 {RSP} {Architecture}},
|
||||
url = {https://www.gsma.com/newsroom/wp-content/uploads/SGP.21-v1.01.pdf},
|
||||
urldate = {2025-07-01},
|
||||
author = {{GSMA}},
|
||||
year = {2015},
|
||||
file = {PDF:/Users/privat/Zotero/storage/ZNI6GMH2/SGP.21-v1.01.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@misc{gsma_sgp01_2014,
|
||||
title = {{SGP}.01 v1.12 {eSIM} {RSP} {Architecture}},
|
||||
url = {https://www.gsma.com/newsroom/wp-content/uploads//SGP.01-v1.12.pdf},
|
||||
urldate = {2025-07-01},
|
||||
author = {{GSMA}},
|
||||
year = {2014},
|
||||
file = {PDF:/Users/privat/Zotero/storage/RWPD9BJM/SGP.01-v1.12.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@misc{vincent_samsungs_2016,
|
||||
title = {Samsung’s {Gear} {S2} has the first certified {eSIM} that lets you choose carriers},
|
||||
url = {https://www.theverge.com/2016/2/18/11044624/esim-wearable-smartwatch-samsung-gear-s2},
|
||||
abstract = {The Gear S2 Classic 3G will use a new industry-approved eSIM},
|
||||
language = {en-US},
|
||||
urldate = {2025-07-01},
|
||||
journal = {The Verge},
|
||||
author = {Vincent, James},
|
||||
month = feb,
|
||||
year = {2016},
|
||||
file = {Snapshot:/Users/privat/Zotero/storage/F4N2FLKA/esim-wearable-smartwatch-samsung-gear-s2.html:text/html},
|
||||
}
|
||||
|
||||
@misc{apple_apple_2018,
|
||||
title = {Apple introduces {iPhone} {XR}},
|
||||
url = {https://www.apple.com/newsroom/2018/09/apple-introduces-iphone-xr/},
|
||||
abstract = {Apple today announced iPhone XR, integrating breakthrough technologies from iPhone XS in an all-screen glass and aluminum design.},
|
||||
language = {en-US},
|
||||
urldate = {2025-07-01},
|
||||
journal = {Apple Newsroom},
|
||||
author = {{Apple}},
|
||||
year = {2018},
|
||||
file = {Snapshot:/Users/privat/Zotero/storage/NVCL4WBU/apple-introduces-iphone-xr.html:text/html},
|
||||
}
|
||||
|
||||
@misc{esimme_esimme_2025,
|
||||
title = {{eSIM}.me: {UPGRADE} to {eSIM} - {Apps} on {Google} {Play}},
|
||||
shorttitle = {{eSIM}.me},
|
||||
url = {https://play.google.com/store/apps/details?id=esim.me&hl=en_CA},
|
||||
abstract = {ADD eSIM Functionality to your "Existing" Smartphone},
|
||||
language = {en-CA},
|
||||
urldate = {2025-07-01},
|
||||
author = {{esim.me}},
|
||||
year = {2025},
|
||||
file = {Snapshot:/Users/privat/Zotero/storage/BI639BHE/details.html:text/html},
|
||||
}
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
% !TeX root = ../Thesis.tex
|
||||
|
||||
%************************************************
|
||||
\chapter{Background}\label{ch:design}
|
||||
\chapter{Background}\label{ch:background}
|
||||
%************************************************
|
||||
\glsresetall % Resets all acronyms to not used
|
||||
|
||||
@@ -35,6 +35,28 @@ The \gls{3gpp} focuses on how \gls{sim} cards integrate with mobile networks. Th
|
||||
|
||||
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}.
|
||||
|
||||
% 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
|
||||
|
||||
The main GSMA eSIM specifications can be categorized as follows:
|
||||
\begin{itemize}
|
||||
\item \textbf{Machine-to-Machine (M2M) Standards (SGP.01, SGP.02):}
|
||||
Industry-focused specifications primarily used in the automotive sector to enable functionalities such as eCall.
|
||||
|
||||
\item \textbf{Consumer Specifications (SGP.21, SGP.22):}
|
||||
Targeted at regular users and implemented in smartphones and other consumer devices for remote SIM provisioning with focus on ease of use.
|
||||
|
||||
\item \textbf{Internet of Things (IoT) Specifications (SGP.31, SGP.32):}
|
||||
Successors to the M2M eSIM standards, designed to support 5G and NB-IoT connectivity for sensors and various IoT devices.
|
||||
|
||||
\item \textbf{In-Factory Specifications (SGP.41, SGP.42):}
|
||||
A brand new specification with version 1.0 released in February 2025, intended for devices including cars and IoT hardware that require immediate network connectivity post-manufacturing, predominantly in the automotive and IoT industries.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\todo{Explain different GSMA standards i.e consumer, m2m, iot, factory}
|
||||
|
||||
|
||||
|
||||
@@ -14,4 +14,7 @@
|
||||
|
||||
% SIMs and eSIMs are an established standard
|
||||
|
||||
|
||||
% future work
|
||||
% support of proactive commands to test esim like estk.me and 9esim v2
|
||||
% support for IoT specific features like remote push provisioning featured in the iot spec SGP.31 aswell as SGP.21 v3.1
|
||||
%
|
||||
|
||||
@@ -5,14 +5,59 @@
|
||||
%************************************************
|
||||
\glsresetall % Resets all acronyms to not used
|
||||
|
||||
% potential exploitation options for the certificate reuse
|
||||
% profile installation sabotage / Supply chain attack
|
||||
% persistent trust manipulation / downgrade attack
|
||||
% goal of the thisis: assess security and behavioral consistency of commercial esim on sim cards using differential testing
|
||||
% implemented custom framework to support apdu level fuzzing, structured asn.1 fuzzing, and trace based comparison across multiple euicc implementations
|
||||
% testing was conduct on 8 different commerical esim on sim implementations from 3 different manufactures
|
||||
% diversity in esim on sim implementations: significant structural differences i.e estk.me vs 9esim v2 vs 5ber
|
||||
% some implementations omit isd-r application and rely soley on USAT interface -> limiting compatability with LPA based provisioning though offering a noval remote lpa implementation that relies on privatly hosted servers to offer the lpa implementation which are not GSMA accredited (cite rlpa)
|
||||
% implementations from 5ber, xesim, and esim.me use different isdr aids
|
||||
% discovery of divergent responses to identical RSP operations across cards
|
||||
% instances where malformed asn1 data triggered undefined or inconsistent behavior
|
||||
% certificate validation bypass and unexpected success of corrupted profile operations in some cards
|
||||
% some cards lacked accessible isdr interfaces and were only usable via proprietary USAT interfaces
|
||||
% some cards offer flashing endpoints for euicc firmware outside of the gp commands
|
||||
|
||||
% presence of undefined error states: indicate that some vendor implementations lack proper or non-resilient internal error handling and fallback to generic errors
|
||||
% some mutated apdus resulted in successful operations: insufficient input validation in the used asn1 libraries or logical fallacies in command parsing
|
||||
% reporducible differences in status words reveal that profile management logic is not standardized in practice, even when based on shared GSMA specifications
|
||||
% lack of accessible debugging interfaces or verbose logging makes it difficult to determine whether observed behavior is due to benign vendor variation or security-relevant flaws
|
||||
|
||||
% TODO: not sure if this should be used
|
||||
% simurai focused on malicious SIM behaviour and demonstrated attack surfaces via malicious cards: did not assess provisioning logic or structured fuzzing
|
||||
% ahmed er al used formal verification to analyze the rsp protocol: did not evaluate live implementations or vender heterogenetiy
|
||||
|
||||
% thesis complements both approaches by provising an empiracal, black-box analysis of live esim on sim cards -> extending the testing landscape
|
||||
% tools like simtester are limited to legacy sims and lack support for esim specific features i.e isd-r, isd-p, etc which this work specifically targets
|
||||
|
||||
% observed inconsistencys can have ciritical implications
|
||||
% certificate validation bypass
|
||||
% beeing able to bypass the certificate validation during the authenticate server process can be critical
|
||||
% trust chain subversion: skipping certificate validation no longer enforces the trust hierarchy rooted in the GSMAs CA -> attacker can insert certificates that appear valid but are not actually signed by the legitimate authority
|
||||
% requirement access to lpa to craft malicous AuthenticateServerRequest messages
|
||||
% profile injection attack
|
||||
% attacker can provision attacker controlled profile (profile needs to be signed by valid GSMA CA) -> can potentially route traffic through rogue infrastructure, potential identiy theft or surveillance (simuarai demonstrates this)
|
||||
% man in the middle provision manipulation
|
||||
% attacker positioned in between the LPA and the euicc via compromised LPA -> interception and manipulation of profile installation, delivery of rogue profiles, violation of the integrity of the profile provisioning pipeline
|
||||
% these attack vectors can lead to a persistent compromise of the euicc
|
||||
|
||||
|
||||
|
||||
% mitigations for certificate reuse bug
|
||||
% flush any cryptographic context on failed rsp session
|
||||
% stricter session isolation
|
||||
|
||||
% limitations of esim security research
|
||||
% hard to analyze -> mostly blackbox fuzzing and analyzation with minimal error responses
|
||||
%
|
||||
% limitations of esim security research in general
|
||||
% hard to analyze -> mostly blackbox fuzzing and analyzation with minimal error information (e.g generic status words, limited error messages due to standard error code provided by the gsma)
|
||||
% restricts root cause analysis and complicates fuzzing based security assessments
|
||||
|
||||
% other limitations
|
||||
% testing was restricted to the SGP.21/22 standard -> new iot standard wasnt evaluated due to lack of available iot cards and more complex infrastructure
|
||||
% mutation coverage is bounded -> not all protocol branches may have been triggered
|
||||
% smdpp were left out: smdpp also are propriatary infrastructure with only the osmo-smdpp being open source, smdpp handle profile provisioning and may also pose as a valuble attacker target
|
||||
% fuzzing was mostly limited to esim side of the rsp protocol: hitting production smdpp servers with fuzzing data might be seen as a dos attack
|
||||
|
||||
% future work
|
||||
% extend lpa functionality to support SGP.31 i.e iot esims as well as SGP.41 iot factory standard
|
||||
% add support for full loop rsp fuzzing i.e add own smdpp plus server with test certificate and test profiles -> full loop fuzzing of esim on sim implementations with test certificates i.e sysmoeuicc
|
||||
% improve fuzzing strategies: currently only basic byte level fuzzing
|
||||
% implement own software euicc and smdpp and add hypothesis rule based state machine support -> directly compare own implementation of smdpp server or euicc to actual behaviour with fuzzing input
|
||||
|
||||
@@ -45,68 +45,6 @@ In contrast, \textbf{estk.me} does not expose an \gls{isdr} for \gls{lpa}-based
|
||||
|
||||
The \textbf{9esim V2} card, in comparison, fully supports both \gls{isdr} access and \gls{usat} communication. Although \gls{usat} interfaces were excluded from evaluation for this particular card due to it not being supported by the testing framwork.
|
||||
|
||||
|
||||
% data fuzzing
|
||||
% data fuzzing was performed on all esim except the estk.me esim since this card does not offer an isd-r
|
||||
% each fuzzing test was performed on all esims one after one
|
||||
|
||||
% findings data fuzzing
|
||||
% data fuzzing succeeded for most cards
|
||||
% ProfileInfoList failed for 9esim, 9esim v2 and EIOTCLUB
|
||||
% Reported failure input was get_profiles(use_iccid=False, profile_class=None, tags=b'') with failure CardConnectionException from the smartcard library
|
||||
% noticable was that the transaction LED on the CardReader continued to blink (suggesting APDUs were still being sent) eventough no traffic was generated by our code
|
||||
% traffic LED continued to blink even when esim was removed
|
||||
% only stopped blinking when completly disconnected from PC
|
||||
% suggests possible bug in smartcard library
|
||||
|
||||
\section{Data Fuzzing}
|
||||
\label{sec:data_fuzzing_evaluation}
|
||||
|
||||
Data fuzzing, as described in \cref{sec:data_fuzzing}, was conducted on all tested \gls{esim} cards with the exception of \texttt{estk.me}. Each test case was executed sequentially across all eligible \glspl{esim} to ensure consistency and reproducibility of results.
|
||||
|
||||
The majority of the cards handled the fuzzed input data as expected, either processing the requests successfully or rejecting them gracefully with standard-compliant error responses. However, notable exceptions were observed during the execution of the \texttt{GetProfileInfo} test case, particularly for the following devices:
|
||||
\begin{itemize}
|
||||
\item 9esim
|
||||
\item 9esim V2
|
||||
\item EIOTCLUB
|
||||
\end{itemize}
|
||||
|
||||
In all three cases, the fuzzing input
|
||||
|
||||
\begin{lstlisting}[language=Python]
|
||||
get_profiles(use_iccid=False, profile_class=None, tags=b'')
|
||||
\end{lstlisting}
|
||||
|
||||
resulted in a \texttt{CardConnectionException} raised by the \texttt{smartcard} Python library during \gls{apdu} transmission.
|
||||
|
||||
During these failures, a consistent and unusual hardware behavior was observed. The transaction LED on the card reader continued to blink, suggesting ongoing \gls{apdu} activity, even though no further commands were being issued by the fuzzing logic. This blinking persisted even after the test process was terminated and, in some cases, even after the \gls{esim} card was physically removed from the reader.
|
||||
|
||||
The LED activity ceased only when the card reader was fully disconnected from the host machine. This behavior strongly indicates that the failure triggered an inconsistent or undefined state within the underlying \texttt{smartcard} library or \texttt{libpcsc}.
|
||||
|
||||
% Although this failure was not directly traceable to a specific eSIM firmware implementation (due to the exception occurring before a meaningful response could be recorded), its repeatability across multiple cards and hardware sessions suggests it warrants further investigation—potentially outside the scope of this work but relevant for tooling robustness in future studies.
|
||||
|
||||
|
||||
\begin{table}[h!]
|
||||
\centering
|
||||
\caption{Data fuzzing results for each function per \gls{esim}}
|
||||
\label{tab:data_fuzzing_result}
|
||||
\begin{tabular}{lcccccc}
|
||||
\toprule
|
||||
\textbf{Function} & \textbf{5ber} & \textbf{eSIM.me} & \textbf{9esim} & \textbf{9esim v2} & \textbf{EIOTCLUB} & \textbf{Xesim} \\
|
||||
\midrule
|
||||
SetDefaultDpAddress & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
EuiccMemoryReset & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
RetrieveNotificationsList & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
ListNotification & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
ProfileInfoList & \cmark & \cmark & \xmark & \xmark & \xmark & \cmark \\
|
||||
SetNickname & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
PrepareDownload & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
AuthenticateServer & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
BoundProfilePackage & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
% general findings
|
||||
|
||||
% estk.me fwupd
|
||||
@@ -179,8 +117,8 @@ The LED activity ceased only when the card reader was fully disconnected from th
|
||||
% high shannon entropy of (TODO: check shannon entrpoy of all firmware versions)
|
||||
% analysing the firmware files with ghidra also just showed just binary data without any structure
|
||||
|
||||
\section{General Findings}
|
||||
\label{sec:general_findings}
|
||||
\section{estk.me Firmware}
|
||||
\label{sec:estk_me_firmware}
|
||||
|
||||
Among all evaluated \glspl{esim}, \texttt{estk.me} stands out due to its publicly available firmware update utility, which is offered via their official website. This binary executable provides both the latest firmware images and the means to apply updates directly from a host machine, making it a unique case in comparison to other \gls{esim} vendors, none of whom publicly expose firmware updates or custom flashing endpoints.
|
||||
|
||||
@@ -202,7 +140,7 @@ The update mechanism exposes two primary functions via a custom \gls{aid} endpoi
|
||||
|
||||
The \gls{aid} used to access the update utility differs based on firmware generation. For example, the test card (generation T001) uses the \gls{aid} :
|
||||
\begin{quote}
|
||||
\texttt{A06573746B6D65FFFFFFFF6677757064}
|
||||
\texttt{A06573746B6D65FFFFFFFF6677757064} \\
|
||||
(hex-encoded: \texttt{'estkmeÿÿÿÿfwupd'})
|
||||
\end{quote}
|
||||
Firmware versions follow the format \texttt{TXXXVXX}, where major generation (\texttt{T000}--\texttt{T003}) and minor version are encoded. Firmware updates are incremental and strictly one-way, the tool automatically selects the next version based on the currently installed one, and downgrade paths are not supported.
|
||||
@@ -223,7 +161,7 @@ The update process proceeds as follows:
|
||||
\item \textbf{Finalize}: The \gls{apdu} \texttt{AA00000000} marks the end of the update process.
|
||||
\end{enumerate}
|
||||
|
||||
The update tool fails gracefully only under specific conditions. For malformed or incorrect \glspl{apdu}, the \gls{euicc} abruptly terminates the connection, leading to a \texttt{CardConnectionException} raised by the PC/SC stack. This maps to the \texttt{SCARD\_E\_NOT\_TRANSACTED (0x80100016)} error, which occurs when the host attempts to communicate over a closed or non-existent connection~\cite{pcsclite_errors}.
|
||||
The update tool fails gracefully only under specific conditions. For malformed or incorrect \glspl{apdu}, the \gls{euicc} abruptly terminates the connection, leading to a \texttt{CardConnectionException} raised by the PC/SC stack. This maps to the \texttt{SCARD\_E\_NOT\_TRANSACTED (0x80100016)} error, which occurs when the host attempts to communicate over a closed or non-existent connection~\cite{corcoran_pcsc-lite_2025}.
|
||||
|
||||
\subsubsection*{Reverse Engineering and Mutation Testing}
|
||||
|
||||
@@ -286,6 +224,67 @@ This variation in \gls{aid} usage may be driven by internal vendor policy, brand
|
||||
|
||||
While tracing provides valuable insights into command sequencing and \gls{aid} selection behaviors, its utility is restricted when it comes to exercising full profile management flows or cross-device compatibility testing without access to valid cryptographic credentials.
|
||||
|
||||
% data fuzzing
|
||||
% data fuzzing was performed on all esim except the estk.me esim since this card does not offer an isd-r
|
||||
% each fuzzing test was performed on all esims one after one
|
||||
|
||||
% findings data fuzzing
|
||||
% data fuzzing succeeded for most cards
|
||||
% ProfileInfoList failed for 9esim, 9esim v2 and EIOTCLUB
|
||||
% Reported failure input was get_profiles(use_iccid=False, profile_class=None, tags=b'') with failure CardConnectionException from the smartcard library
|
||||
% noticable was that the transaction LED on the CardReader continued to blink (suggesting APDUs were still being sent) eventough no traffic was generated by our code
|
||||
% traffic LED continued to blink even when esim was removed
|
||||
% only stopped blinking when completly disconnected from PC
|
||||
% suggests possible bug in smartcard library
|
||||
|
||||
\section{Data Fuzzing}
|
||||
\label{sec:data_fuzzing_evaluation}
|
||||
|
||||
Data fuzzing, as described in \cref{subsec:data_fuzzing}, was conducted on all tested \gls{esim} cards with the exception of \texttt{estk.me}. Each test case was executed sequentially across all eligible \glspl{esim} to ensure consistency and reproducibility of results.
|
||||
|
||||
The majority of the cards handled the fuzzed input data as expected, either processing the requests successfully or rejecting them gracefully with standard-compliant error responses. However, notable exceptions were observed during the execution of the \texttt{GetProfileInfo} test case, particularly for the following devices:
|
||||
\begin{itemize}
|
||||
\item 9esim
|
||||
\item 9esim V2
|
||||
\item EIOTCLUB
|
||||
\end{itemize}
|
||||
|
||||
In all three cases, the fuzzing input
|
||||
|
||||
\begin{lstlisting}[language=Python]
|
||||
get_profiles(use_iccid=False, profile_class=None, tags=b'')
|
||||
\end{lstlisting}
|
||||
|
||||
resulted in a \texttt{CardConnectionException} raised by the \texttt{smartcard} Python library during \gls{apdu} transmission.
|
||||
|
||||
During these failures, a consistent and unusual hardware behavior was observed. The transaction LED on the card reader continued to blink, suggesting ongoing \gls{apdu} activity, even though no further commands were being issued by the fuzzing logic. This blinking persisted even after the test process was terminated and, in some cases, even after the \gls{esim} card was physically removed from the reader.
|
||||
|
||||
The LED activity ceased only when the card reader was fully disconnected from the host machine. This behavior strongly indicates that the failure triggered an inconsistent or undefined state within the underlying \texttt{smartcard} library or \texttt{libpcsc}.
|
||||
|
||||
% Although this failure was not directly traceable to a specific eSIM firmware implementation (due to the exception occurring before a meaningful response could be recorded), its repeatability across multiple cards and hardware sessions suggests it warrants further investigation—potentially outside the scope of this work but relevant for tooling robustness in future studies.
|
||||
|
||||
|
||||
\begin{table}[h!]
|
||||
\centering
|
||||
\caption{Data fuzzing results for each function per \gls{esim}}
|
||||
\label{tab:data_fuzzing_result}
|
||||
\begin{tabular}{lcccccc}
|
||||
\toprule
|
||||
\textbf{Function} & \textbf{5ber} & \textbf{eSIM.me} & \textbf{9esim} & \textbf{9esim v2} & \textbf{EIOTCLUB} & \textbf{Xesim} \\
|
||||
\midrule
|
||||
SetDefaultDpAddress & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
EuiccMemoryReset & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
RetrieveNotificationsList & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
ListNotification & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
ProfileInfoList & \cmark & \cmark & \xmark & \xmark & \xmark & \cmark \\
|
||||
SetNickname & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
PrepareDownload & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
AuthenticateServer & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
BoundProfilePackage & \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
% apdu fuzzing
|
||||
|
||||
% optimizing for coverage
|
||||
|
||||
@@ -7,23 +7,33 @@
|
||||
|
||||
% todays society is connected
|
||||
% all devices i.e Smartphones, iot devices, vehicles are connected and often have an SIM -> connect to cellular networks
|
||||
% The first phones supporting esims released in 2016 with the iphone that supports esim being released in 2018
|
||||
% gsma released first version of the SGP.21 specification in 2015: outlines how profiles should be provisioned to consumer esims -> baseline to support esims in smartphones (cite SGP.21 v1.0)
|
||||
% earlier versions for esim support exists (spec v1 released in 2014 but focused on machine to machine communication in industrial context
|
||||
% The first phones supporting esims released in 2016 with the first iphone that supports esim being released in 2018
|
||||
% in recent years: esims became more and more popular in such applications
|
||||
% advantages: no need to switch out hardware when getting a new phone contract, easier to switch out the profile when going to a foreign country an getting a temporary phone contract (or something similar)
|
||||
% adoption of eSIM technology is increasing rapidly due to its flexibility, remote provisioning capability, and suitability for IoT and mobile devices
|
||||
% most newly released phone support esims -> new attack vector for adversaries
|
||||
% people with older hardware i.e no esim support by their phone are left out -> introduction of eSIM on SIM
|
||||
% eSIM chips in the form factor of normal SIMs -> can be inserted in normal SIM slots and behave like normal SIM cards but with extra features
|
||||
% esim.me marketed their esim on sim as "world’s first eSIM Card" with their launch in 2020
|
||||
% esim on sim enable old phones to use eSIM via sim slot or other applications
|
||||
|
||||
|
||||
In today's hyper-connected society, smartphones, \gls{iot} devices, and vehicles rely on cellular networks for a wide range of functionalities. These devices typically authenticate to mobile networks using \gls{sim} cards. To keep pace with growing connectivity needs and reduce reliance on physical \gls{sim} provisioning, the GSMA released the first version of the SGP.21 specification in 2015 \cite{gsma_sgp21_2015}. This specification defines how profiles should be securely provisioned onto \glspl{esim}, laying the foundation for \gls{esim} integration in consumer devices.
|
||||
|
||||
Although an earlier specification focusing on M2M (Machine-to-Machine) use cases was released in 2014~\cite{gsma_sgp01_2014}, it was mainly targeted at industrial deployments. Consumer adoption started in 2016 with the release of the first device supporting \gls{esim}~\cite{vincent_samsungs_2016} and gained further traction with Apple's inclusion of \gls{esim} functionality in the iPhone lineup in 2018~\cite{apple_apple_2018}. Since then, \gls{esim} technology has become increasingly prevalent due to its flexibility, remote provisioning capabilities, and suitability for compact or embedded hardware. It simplifies processes such as switching mobile carriers or activating local profiles when traveling.
|
||||
|
||||
As \gls{esim} support becomes standard in newly released phones, it also introduces a new attack surface. Notably, older devices without native \gls{esim} support are excluded from this technological shift. In response, several vendors have introduced eSIM-on-SIM chips embedded in a traditional \gls{esim} card form factor. These allow older phones to access \gls{esim} functionality via the existing \gls{sim} slot. For example, esim.me marketed their solution in 2020 as the “world’s first \gls{esim} card”~\cite{esimme_esimme_2025}, enabling legacy smartphones to benefit from modern \gls{esim} provisioning workflows.
|
||||
|
||||
\section{Motivation}
|
||||
% Motivation
|
||||
|
||||
% esim standard is developed by the GSMA, ETSI and 3GPP -> security was build into the design from the ground up
|
||||
% with the first release of SGP.21 in 2015 relatively new -> current version v3.1 released in 2025 -> still introducing new features
|
||||
% other researches have already looked at the specs in depth (cite papers here)
|
||||
% implementation of the esim firmware is still up to the manufacturs which develope their own versions -> possibility of vulnerabilities in their implementations
|
||||
|
||||
% lack of formal security evaluation
|
||||
|
||||
% security vulnerabilities can have a major impact -> persistence of exploits are high: malicouse profiles may persist accross reboots or even device resets; often low level and invisible -> particularly dangerous and hard to detect
|
||||
% sims have direct, priviledged, unfiltered access to the baseband
|
||||
|
||||
@@ -43,7 +53,18 @@
|
||||
% differential testing: compare multiple implementations against each other -> identify anomalies under identical/similar inputs
|
||||
% goal: uncover functional deviations and security issues in a black-box setting
|
||||
|
||||
Despite the \gls{esim} architecture being built with security in mind and standardized by the GSMA, ETSI, and 3GPP, implementations are left to individual manufacturers. While the specifications provide a common baseline, the actual firmware and OS implementations remain proprietary and closed-source. This means they are not open to public review and may include undocumented features, backdoors, or custom update mechanisms beyond the published standards.
|
||||
|
||||
These implementation-specific deviations pose significant security risks. \glspl{esim} operate at a privileged layer of the system architecture, with direct and largely unfiltered access to the device's baseband. Vulnerabilities within this stack can result in persistent malware, surviving reboots or even factory resets, and often remain invisible to users. Bugs in the implementation of profile provisioning, certificate validation, or update mechanisms can therefore have severe and long-lasting consequences.
|
||||
|
||||
Furthermore, given the relative novelty of the consumer \gls{esim} ecosystem, the first SGP.21 release only dating back to 2015 and the latest version (v3.1) being released in 2025, the technology is still evolving. Different vendors may interpret and implement the specifications in slightly different ways, leading to inconsistencies and potentially exploitable gaps.
|
||||
|
||||
Due to the lack of transparency in vendor implementations, black-box testing methodologies are especially valuable for uncovering such issues. Differential testing is a promising approach: it systematically compares how different implementations behave when subjected to identical or similar inputs. This makes it possible to detect deviations and identify bugs without needing source code or internal documentation.
|
||||
|
||||
This thesis aims to close the gap in independent, systematic analysis of commercial eSIM-on-SIM implementations. It proposes and demonstrates a differential testing framework that facilitates the black-box evaluation of these implementations in terms of correctness and security.
|
||||
|
||||
\section{Contribution}
|
||||
% Contribution
|
||||
|
||||
% implement framework for differential testing of esims (esims and esim on sim)
|
||||
% containing: fuzzing of structural input when communicating with the esim, fuzzing on transport level, tracing and replaying recordings from one esim to another; make it accessible via cli and as a library for scripting
|
||||
@@ -54,6 +75,29 @@
|
||||
% demonstrate the framworks ability in security research:
|
||||
% through apdu level differnetial testing, we discover and evaluate bug in the profile provisioning process of one manufacturer -> suggests potential security risk such as certificate validation bypass -> analyze and evaluate potential impact
|
||||
|
||||
\section{Outline}
|
||||
This thesis presents a novel framework for the differential testing of \gls{esim} and eSIM-on-SIM implementations. The framework includes a custom \gls{lpa}, an \gls{apdu} mutation engine, and structured fuzzing tools. It enables tracing, mutation, and replaying of provisioning flows, and is exposed both through a command-line interface and as a Python library for scripting and automation.
|
||||
|
||||
%
|
||||
By employing property-based testing and structural input mutation, the framework generates valid but edge-case-rich test cases to evaluate high-level commands. This allows it to uncover subtle logic bugs beyond low-level malformed input handling.
|
||||
|
||||
We use the framework to analyze several commercial eSIM-on-SIM implementations. Our analysis reveals significant implementation differences, including a critical vulnerability in one vendor's certificate handling logic. Specifically, we uncover a bug that suggests a certificate validation bypass during the profile provisioning process. We also reverse-engineer the firmware update functionality of the estk.me card.
|
||||
|
||||
\section{Outline}
|
||||
% Outline
|
||||
|
||||
% Thesis begins with background: provides necesssary background on SIMs, eSIMs, and the RSP architecture
|
||||
% also introduces relevant standardization from 3GPP, GSMA, and ETSI
|
||||
% Chapter 3 reviews related work: including acedemic research on sim card security, emulation frameworks, and software tools relevant to analyze esims
|
||||
% In chapter 4: details about the implementation of the testing framework -> tracing mutation, structured fuzzing, and design of the custom LPA
|
||||
% Chapter 5: evaluation of several commercial eSIM on SIM cards using the implemented framework, analyzing observed behaviour, and identifying incosistencies accross vendors
|
||||
% Chapter 6: discuss the implications of our findings and reflect on potential weaknesses in current esim on sim deployment models
|
||||
% in the last chapter: concludes thesis, outlines possible future work, including testing of IoT specific features, and supporting proactive commands
|
||||
|
||||
The thesis begins with an overview of \gls{sim} and \gls{esim} technologies in \cref{ch:background}, along with the \gls{rsp} architecture, to establish the necessary technical background. It also introduces the relevant standards developed by the GSMA, ETSI, and 3GPP.
|
||||
|
||||
In \cref{ch:relatedwork}, it surveys related work in the domain of \gls{sim} and \gls{esim} security, focusing on academic literature, emulation frameworks, and software tools used for analysis.
|
||||
|
||||
The implementation of the proposed differential testing framework is described in \cref{ch:implementation}, covering the tracing infrastructure, \gls{apdu} mutation engine, and structured input generation logic.
|
||||
|
||||
Following the implementation, we evaluate a selection of commercial eSIM-on-SIM cards using the developed framework in \cref{ch:evaluation}. We analyze inconsistencies in behavior across vendors and discuss potential deviations from the specifications.
|
||||
|
||||
Finally, we discuss the broader implications of our findings in \cref{ch:discussion}, reflect on current limitations in eSIM-on-SIM deployment models, and propose avenues for future research in \cref{ch:conclusions}, including expanding the framework to support proactive commands and IoT-specific provisioning flows.
|
||||
|
||||
Reference in New Issue
Block a user