Update on Overleaf.

Chapters/Evaluation.tex

@@ -282,7 +282,7 @@ We catalogued the \gls{isdr} \glspl{aid} observed during tracing across multiple
     \item \textbf{standard}: \texttt{a0000005591010ffffffff8900000100}
 \end{itemize}
 
-This variation in \gls{aid} usage may be driven by internal vendor policy, branding, or the need to segment access to multiple security domains or services. In the case of \texttt{eSIM.me}, the coexistence of both the standard and custom \glspl{aid} suggests a fallback mechanism for compatibility with generic \gls{lpa} implementations. \todo{Check which applications are allowed by the aram}
+This variation in \gls{aid} usage may be driven by internal vendor policy, branding, or the need to segment access to multiple security domains or services. In the case of \texttt{eSIM.me}, the coexistence of both the standard and custom \glspl{aid} suggests a fallback mechanism for compatibility with generic \gls{lpa} implementations. \todo{Check which applications are allowed by the ara-m}
 
 While tracing provides valuable insights into command sequencing and \gls{aid} selection behaviors, its utility is restricted when it comes to exercising full profile management flows or cross-device compatibility testing without access to valid cryptographic credentials.
 
@@ -517,6 +517,13 @@ The following classes of errors were consistently encountered during mutation ca
 % same result when switching out the whole certificate
 % suggests that more than just the certificate is beeing reused from the previouse session
 
+% looking closer into the first bitflip in the failed request when using different smdps
+% first flip is in the tag for the AuthenticateServerRequest (bf38 -> be38 where be38 is invalid) -> fixing this leads to the following other flips
+% flips are done in euiccPkiToBeUsed, serverCertificate.serialNumber, serverSignature1, serverSigned1.euiccChallenge, serverSigned1.serverChallenge
+% when looking at the bitflips from the failed request with the same smdp server
+% first flip again in the tag for the request, fixing this shows flips in euiccCiPKIdToBeUsed, serverCertificate.issuer, serverCertificate.serialNumber, serverSignature1, serverSigned1.serverChallenge
+
+
 \subsection{Analysis of Successful Mutations}
 \label{subsec:successful_mutations}
 
@@ -560,6 +567,18 @@ By combining a series of failed and mutated authentication requests, it was poss
     \item Swapping the \texttt{SubjectPublicKeyInfo} in the truncated certificate with an attacker-controlled public key still results in successful mutual authentication and secure channel establishment. This would imply that the \gls{euicc} did not use the attacker controlled public key, but instead reused the previously sent publlic key from the failed request, as otherwise the \gls{smdpp} would have not been able to verify the signature in the subsequent client authentication.
 \end{enumerate}
 
+A deeper analysis of mutated APDU payloads of the initial \texttt{AuthenticateServerRequest}, particularly in cases using different \gls{smdpp} servers, shows the following:
+
+\begin{itemize}
+    \item The first mutation typically occurs in the tag of the \texttt{AuthenticateServerRequest}, where the correct \texttt{bf38} tag is flipped to an invalid \texttt{be38}. Correcting this tag lets us decode the remaining data.
+    
+    \item In cross-server scenarios (different \gls{smdpp}), subsequent flips occur in fields such as \texttt{euiccPkiToBeUsed}, \texttt{serverCertificate.serialNumber}, \texttt{serverSignature1}, and both the \texttt{euiccChallenge} and \texttt{serverChallenge} components of \texttt{serverSigned1}. This attempt will not be able to pass the bug.
+    
+    \item In same-server scenarios (same \gls{smdpp}), a similar flip in the tag is observed. Upon correction, mutations manifest in \texttt{euiccCiPKIdToBeUsed}, \texttt{serverCertificate.issuer}, \texttt{serverCertificate.serialNumber}, \texttt{serverSignature1}, and again in \texttt{serverSigned1.serverChallenge}. This scenario will be able to pass the truncation bug an successfully install the profile.
+\end{itemize}
+
+These observations further validate the theory that the certificate from the initial failed \texttt{AuthenticateServerRequest} is cached and reused by the \gls{euicc}. In both the same-server and cross-server mutation scenarios, the public key remains unmodified, yet the behavior diverges based on the prior session’s state. Additionally, certificate validation appears to be bypassed entirely, as the mutated certificate contents never represent a structurally valid or correctly signed certificate at any point in the provisioning flow.
+
 \subsubsection*{State Persistence Across Sessions}
 Further experiments showed that this vulnerability persists across sessions and even power cycles: