Update on Overleaf.

Chapters/Discussion.tex

@@ -5,14 +5,59 @@
 %************************************************
 \glsresetall % Resets all acronyms to not used
 
-% potential exploitation options for the certificate reuse
-% profile installation sabotage / Supply chain attack
-% persistent trust manipulation / downgrade attack
+% 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
-% hard to analyze -> mostly blackbox fuzzing and analyzation with minimal error responses
-% 
+% 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