Update on Overleaf.

Chapters/Discussion.tex

@@ -40,8 +40,6 @@
 % 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
@@ -61,3 +59,27 @@
 % 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
+
+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 \acposs{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.
+
+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.
+
+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 \textref{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.
+
+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.
+
+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.
+
+While the results demonstrate the effectiveness of our framework, several limitations should be noted. First, our testing was confined to the SGP.21 and SGP.22 consumer specification. The newer \gls{iot}-centric specification, defined SGP.31 and SGP.32, were not evaluated due to a lack of publicly available \gls{iot}-targeted eSIM-on-SIM cards and the additional infrastructure they require. Second, although our fuzzing engine supports both structural and transport-level mutation, protocol coverage remains inherently bounded. Some branches in the protocol logic may not have been exercised. Additionally, our evaluation focused primarily on the \gls{euicc} side of the \gls{rsp} protocol. The \gls{smdpp} servers, which are integral to the provisioning process, were treated as opaque black boxes. Since most commercial \gls{smdpp} implementations are closed source and fuzzing them could be seen as a malicious \gls{dos} attack, they were mostly excluded from testing. The only publicly available implementation, osmo-smdpp, was not integrated due to scope limitations.
+
+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 and SGP.41 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.
+
+