niklas/master_thesis
1
0
Fork 0
mirror of https://sharelatex.tu-darmstadt.de/git/681e0e7a3a9c7c9c6b8bb298 synced 2026-02-04 11:07:43 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update on Overleaf.

Browse Source
This commit is contained in:
nb72soza Bittner
2025-07-07 00:56:57 +00:00
committed by node
parent 9e6e16c2f6
commit 8bf17984fc
9 changed files with 41 additions and 47 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
Chapters/Discussion.tex
View File

@@ -62,15 +62,15 @@
The primary goal of this thesis was to assess the security posture and behavioral consistency of commercial eSIM-on-SIM products through differential testing. To this end, we developed a custom black-box testing framework capable of performing APDU-level fuzzing, structured \gls{asn1} mutation, and trace-based cross-device comparisons. Our evaluation was conducted on eight commercially available eSIM-on-SIM cards from three distinct vendors, revealing a diverse and fragmented implementation landscape.
Our findings indicate substantial architectural differences across implementations. For instance, some cards, such as the one from estk.me, omit the standard \gls{isdr} application altogether and instead expose functionality solely via the \gls{usat} interface. This approach also offers a privately hosted \gls{rlpa} server for provisioning \cite{estkme_rlpa-server_2025}, circumventing the \glsposs{gsma} standardized infrastructure and raising questions regarding compliance and security. In contrast, other implementations (e.g., 5ber, Xesim, eSIM.me) do include \gls{isdr} support, but use vendor-specific \glspl{aid}, deviating from the default identifiers specified in SGP.22. These differences complicate interoperability and testing, while also highlighting the absence of a uniform baseline across implementations.
Our findings indicate substantial architectural differences across implementations. For instance, some \glspl{euicc}, such as the one from estk.me, omit the standard \gls{isdr} application altogether and instead expose functionality solely via the \gls{usat} interface. This approach also offers a privately hosted \gls{rlpa} server for provisioning \cite{estkme_rlpa-server_2025}, circumventing the \glsposs{gsma} standardized infrastructure and raising questions regarding compliance and security. Other implementations (\eg, 5ber, Xesim, eSIM.me) do include \gls{isdr} support, but use vendor-specific \glspl{aid}, deviating from the default identifiers specified in SGP.22. These differences complicate interoperability and testing, while also highlighting the absence of a uniform baseline across implementations.
A key contribution of our work is the observation of divergent behaviors in response to identical \gls{rsp} inputs. Mutated \gls{asn1} payloads triggered undefined behavior in several cards, including silent failures, unexpected success responses, and inconsistent status words. In multiple instances, we observed malformed requests that bypassed expected validation routines, particularly during the certificate authentication phase. One notable case revealed a likely certificate validation bypass, where corrupted `AuthenticateServerRequest` messages were accepted despite invalid or tampered certificates. This suggests that parts of the certificate verification pipeline were either improperly implemented or incorrectly reused from prior sessions without sufficient integrity checks.
A key contribution of our work is the observation of different behaviors in response to identical \gls{rsp} inputs. Mutated \gls{asn1} payloads triggered undefined behavior in several \glspl{euicc}, including silent failures, unexpected success responses, and inconsistent status words. In multiple instances, we observed malformed requests that bypassed expected validation routines, particularly during the certificate authentication phase. One notable case revealed a likely certificate validation bypass, where corrupted \texttt{AuthenticateServerRequest} messages were accepted despite invalid or tampered certificates. This suggests that parts of the certificate verification pipeline were either improperly implemented or incorrectly reused from prior sessions without sufficient integrity checks.
The implications of such inconsistencies are significant. Bypassing certificate validation undermines the trust model of the \gls{gsma} \gls{rsp} architecture, as the certificate chain rooted in the \gls{gsma} \gls{ca} can no longer be reliably enforced. An attacker able to craft malicious authentication messages, potentially by compromising or emulating an \gls{lpa}, could install rogue profiles onto the \gls{euicc}. While a valid \gls{gsma}-signed profile is still required, this opens the door for profile injection attacks, man-in-the-middle (MITM) provisioning manipulation, and potentially persistent compromise of the device. Previous research, such as that by \textcite{lisowski_simurai_2024}, has demonstrated the feasibility of malicious \gls{sim} cards. However, their work focused on runtime behavior and not on provisioning vulnerabilities. Our findings extend this threat model by targeting the provisioning pipeline itself.
The implications of such inconsistencies are significant. Bypassing certificate validation undermines the trust model of the \gls{gsma} \gls{rsp} architecture, as the certificate chain rooted in the \gls{gsma} \gls{ca} can no longer be reliably enforced. An attacker able to craft malicious authentication messages, potentially by compromising or distributing malicious \glspl{lpa}, could install rogue profiles onto the \gls{euicc}. While a valid \gls{gsma}-signed profile is still required, this opens the door for profile injection attacks, man-in-the-middle (MITM) provisioning manipulation, and potentially persistent compromise of the device. Previous research, such as that by \textcite{lisowski_simurai_2024}, has demonstrated the feasibility of malicious \gls{sim} cards. However, their work focused on runtime behavior and not on provisioning vulnerabilities. Our findings extend this threat model by targeting the provisioning pipeline itself.
Several cards also revealed additional security concerns. One exposed undocumented endpoints for firmware updates that fall outside the \gls{gp} command set, suggesting the existence of non-standard, vendor-specific mechanisms for critical operations. The presence of undefined error states, typically in the form of generic status words (\eg, \texttt{6F00}) or generic Errors (\eg, \texttt{UndefinedError}), indicates insufficient internal error handling. In some cases, malformed inputs resulted in successful operations, pointing to either faulty \gls{asn1} decoding or logical flaws in the parsing routines.
Several cards also revealed additional security concerns. One exposed endpoints for firmware updates that fall outside the \gls{gp} command set, suggesting the existence of non-standard, vendor-specific mechanisms for critical operations. The presence of undefined error states, typically in the form of generic status words (\eg, \texttt{6F00}) or generic Errors (\eg, \texttt{UndefinedError}), indicates insufficient internal error handling. In some cases, malformed inputs resulted in successful operations, pointing to either faulty \gls{asn1} decoding or logical flaws in the parsing routines.
The reproducibility of these findings across multiple cards supports the claim that profile management logic is often implemented in a non-standardized manner, despite the underlying reliance on common specifications such as SGP.21 and SGP.22. Unfortunately, due to the closed-source nature of the \gls{euicc} firmware, the lack of verbose error logging, and the absence of official debugging interfaces, root cause analysis remains difficult. This significantly hampers the ability to distinguish between benign vendor-specific variations and genuine security vulnerabilities.
Being able to reproduce these findings across multiple cards supports the claim that profile management logic is often implemented in a non-specification conforming way. Unfortunately, due to the \gls{euicc} firmware being a closed-source implementation, the lack of verbose error logging, and official debugging interfaces, root cause analysis remains difficult. This significantly reduces the ability to differentiate between vendor-specific variations and actual security vulnerabilities.
In terms of research landscape, this thesis complements prior work that either focused on malicious runtime \gls{sim} behavior \cite{lisowski_simurai_2024} or employed formal methods to analyze the \gls{rsp} protocol \cite{ahmed_security_2024}. Unlike those approaches, our methodology provides empirical, implementation-level insights through the differential testing of live, commercial-grade eSIM-on-SIM products. Compared to existing tools such as SimTester~\cite{security_research_labs_simtester_2025}, which are tailored to legacy \gls{sim} cards and lack support for eSIM-specific features (e.g., \gls{isdr}, \gls{isdp}), our framework directly targets the modern provisioning stack.
@@ -78,8 +78,4 @@ While the results demonstrate the effectiveness of our framework, several limita
To mitigate the certificate reuse issue observed, we recommend stricter cryptographic context isolation, including flushing session state after failed provisioning attempts. This would reduce the risk of unintended reuse of sensitive materials across sessions.
\paragraph{Future Work}
Several directions for future research emerge from this work. First, the \gls{lpa} implementation could be extended to support SGP.31/SGP.32 and SGP.41/SGP.42 specific functionality, enabling testing of \gls{iot}-specific provisioning flows and factory provisioning procedures. Second, to achieve full-loop fuzzing, future versions of the framework could integrate a self-hosted \gls{smdpp} server equipped with test certificates and profiles. This would allow end-to-end testing of the complete \gls{rsp} lifecycle. Finally, improvements to the fuzzing engine, such as incorporating a hypothesis rule based state machine, which would directly compare the fuzzing behaviour of a custom \gls{smdpp} server and \gls{euicc} implementation against propriatary ones.