Update on Overleaf.

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

View File

@@ -22,7 +22,7 @@
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.
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 popular 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 “worlds first \gls{esim} card”~\cite{esimme_esimme_2025}, enabling legacy smartphones to benefit from modern \gls{esim} provisioning workflows.
@@ -55,11 +55,11 @@ As \gls{esim} support becomes standard in newly released phones, it also introdu
Despite the \gls{esim} architecture being built with security in mind and standardized by the \gls{gsma}, \gls{etsi}, and \gls{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.
These implementation-specific deviations can have a 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 impact.
Furthermore, given the relative novelty of the consumer \gls{esim} ecosystem, the first SGP.21 release only dating back to 2015~\cite{gsma_sgp21_2015} and the latest version (v3.1) being released in 2025~\cite{gsma_sgp22_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 \cite{mckeeman_differential_1998}. This makes it possible to detect deviations and identify bugs without needing source code or internal documentation.
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 as it systematically compares how different implementations behave when subjected to identical or similar inputs \cite{mckeeman_differential_1998}. 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.