mirror of
https://sharelatex.tu-darmstadt.de/git/681e0e7a3a9c7c9c6b8bb298
synced 2025-12-07 21:27:59 +00:00
31 lines
3.0 KiB
TeX
31 lines
3.0 KiB
TeX
% !TeX root = ../Thesis.tex
|
||
|
||
%************************************************
|
||
\chapter{Conclusions}\label{ch:conclusions}
|
||
%************************************************
|
||
\glsresetall % Resets all acronyms to not used
|
||
|
||
% build a framework for esim security analysis
|
||
% LPA in python
|
||
|
||
% Found bug in esim on sim cards
|
||
|
||
% reverse engineered the estk.me update mechanism
|
||
|
||
|
||
This thesis presented a systematic security analysis of commercial eSIM-on-SIM card implementations through the application of differential testing. Given the opaque and proprietary nature of most \gls{euicc} firmware, black-box testing approaches remain one of the few viable options for assessing correctness and security in deployed systems. With the design and implementation of a custom framework, this work introduces a reproducible method for identifying behavioral inconsistencies across vendor-specific \gls{esim} implementations.
|
||
|
||
The developed framework integrates trace recording, scenario-driven testing, and property-based structured fuzzing, allowing the systematic mutation and replay of \gls{apdu} traces. The combination of syntactically valid \gls{asn1}-based input generation with deterministic mutation provides a strong fuzzing implementation. Through this approach, several notable implementation differences were identified, including a critical certificate validation bypass in one vendor’s \gls{euicc} side provisioning logic.
|
||
|
||
These findings highlight the importance of independent verification and validation of \gls{esim} implementations. The observed deviations from \gls{gsma} specifications suggest that even well-established standards do not guarantee uniform security guarantees across vendors. Differential testing, as demonstrated, offers a scalable and automation-friendly approach to detect such inconsistencies without requiring access to proprietary source code.
|
||
|
||
|
||
\section{Future Work}
|
||
\label{sec:future_work}
|
||
|
||
This work can be extended in several directions. 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 as soon as implementations become available. 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.
|
||
|
||
Additionally, adding support for proactive commands to the fuzzing engine would enable testing of \gls{euicc} cards that expose only \gls{usat}-based interfaces, such as those from estk.me and 9esim v2. This addition would broaden the scope of the framework, allowing it to address a wider range of commercial \gls{esim} implementations and significantly increase protocol coverage.
|
||
|
||
Finally, improvements to the fuzzing engine itself, such as incorporating a Hypothesis rule based state machine, would allow direct behavioral comparisons between custom \gls{smdpp} and \gls{euicc} implementations and proprietary systems.
|