mirror of
https://sharelatex.tu-darmstadt.de/git/681e0e7a3a9c7c9c6b8bb298
synced 2025-12-07 13:18:00 +00:00
60 lines
4.3 KiB
TeX
60 lines
4.3 KiB
TeX
% !TeX root = ../Thesis.tex
|
||
|
||
%************************************************
|
||
\chapter{Introduction}\label{ch:introduction}
|
||
%************************************************
|
||
\glsresetall % Resets all acronyms to not used
|
||
|
||
% todays society is connected
|
||
% all devices i.e Smartphones, iot devices, vehicles are connected and often have an SIM -> connect to cellular networks
|
||
% The first phones supporting esims released in 2016 with the iphone that supports esim being released in 2018
|
||
% in recent years: esims became more and more popular in such applications
|
||
% advantages: no need to switch out hardware when getting a new phone contract, easier to switch out the profile when going to a foreign country an getting a temporary phone contract (or something similar)
|
||
% adoption of eSIM technology is increasing rapidly due to its flexibility, remote provisioning capability, and suitability for IoT and mobile devices
|
||
% most newly released phone support esims -> new attack vector for adversaries
|
||
% people with older hardware i.e no esim support by their phone are left out -> introduction of eSIM on SIM
|
||
% esim.me marketed their esim on sim as "world’s first eSIM Card" with their launch in 2020
|
||
% esim on sim enable old phones to use eSIM via sim slot or other applications
|
||
|
||
\section{Motivation}
|
||
|
||
% esim standard is developed by the GSMA, ETSI and 3GPP -> security was build into the design from the ground up
|
||
% other researches have already looked at the specs in depth (cite papers here)
|
||
% implementation of the esim firmware is still up to the manufacturs which develope their own versions -> possibility of vulnerabilities in their implementations
|
||
|
||
% lack of formal security evaluation
|
||
|
||
% security vulnerabilities can have a major impact -> persistence of exploits are high: malicouse profiles may persist accross reboots or even device resets; often low level and invisible -> particularly dangerous and hard to detect
|
||
% sims have direct, priviledged, unfiltered access to the baseband
|
||
|
||
% esim os are closed source and implemented by the manufactruers -> not subject to open review
|
||
% strengthens the importance of black-box testing methodologies to uncover implementation specific issues without requiring internal access
|
||
% also has potential for undocumented features and backdoors -> esim vendors might introduce update endpoints to update their esim firmware, or add extra functionality outside of the specs
|
||
|
||
% non standard implementations may introduce bugs or security flaws
|
||
% implementation bugs: like any other complex embedded system esim stack are susceptiuble to bugs
|
||
% particular dangeros due to the priviledged rele of the esim in device architecture
|
||
|
||
% esim specs may have been interpretated differently by the different vendors
|
||
|
||
% differential testing offers automated and scalable method to detect inconsistency in the different implementations -> comparing output of multiple esim on sim implementations against the same inputs
|
||
|
||
% this thesis addresses need for systematic security and correctness evaluation of esim on sim implementations -> differential testing
|
||
% differential testing: compare multiple implementations against each other -> identify anomalies under identical/similar inputs
|
||
% goal: uncover functional deviations and security issues in a black-box setting
|
||
|
||
\section{Contribution}
|
||
|
||
% implement framework for differential testing of esims (esims and esim on sim)
|
||
% containing: fuzzing of structural input when communicating with the esim, fuzzing on transport level, tracing and replaying recordings from one esim to another; make it accessible via cli and as a library for scripting
|
||
% this includes custom LPA implementation, APDU mutation engine, and structured fuzzing tools
|
||
% using property based testing: generate valid but edge-case-rich inputs targeting high-level esim commands -> detecting errors beyond byte-level malformations
|
||
% using the tracing functionality we discover first implementation differences in the implementation
|
||
% reverse engineer the update functionality of the estk.me esim
|
||
% demonstrate the framworks ability in security research:
|
||
% through apdu level differnetial testing, we discover and evaluate bug in the profile provisioning process of one manufacturer -> suggests potential security risk such as certificate validation bypass -> analyze and evaluate potential impact
|
||
|
||
\section{Outline}
|
||
|
||
%
|