master_thesis/Chapters/Discussion.tex

% !TeX root = ../Thesis.tex

%************************************************
\chapter{Discussion}\label{ch:discussion} % $\mathbb{ZNR}$
%************************************************
\glsresetall % Resets all acronyms to not used

% 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 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

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 \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 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 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 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.

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.

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.