Update on Overleaf.

This commit is contained in:
nb72soza Bittner
2025-07-01 23:50:06 +00:00
committed by node
parent 928dcd72df
commit 05541d57ab
10 changed files with 690 additions and 539 deletions

View File

@@ -57,7 +57,7 @@ Despite the \gls{esim} architecture being built with security in mind and standa
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.
Furthermore, given the relative novelty of the consumer \gls{esim} ecosystem, the first SGP.21 release only dating back to 2015 and the latest version (v3.1) being released in 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.
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. This makes it possible to detect deviations and identify bugs without needing source code or internal documentation.