Update on Overleaf.

Chapters/Evaluation.tex

@@ -611,7 +611,7 @@ According to SGP.22:
 \begin{quote}
 ``The Server (the entity providing the function, e.g., \gls{smdpp}) SHALL be authenticated first by the Client (the entity requesting the function). Authentication SHALL include the verification of a Server Certificate chain ending at an \gls{esim} \gls{ca} RootCA Certificate (section 4.5.2).''~\cite{gsma_sgp22_2025}
 \end{quote}
-The server certificate \texttt{CERT.DPauth.ECDSA} must be verified against the \gls{gsma} root-of-trust, and the digital signature of the \texttt{AuthenticateServerRequest} must be valid.
+The server certificate $Cert_{Sa}$ must be verified against the \gls{gsma} root-of-trust $Cert_{CI}$, and the digital signature of the \texttt{AuthenticateServerRequest} must be valid.
 
 \subsubsection*{Observed Behavior}
 By combining a series of failed and mutated authentication requests, it was possible to trigger incorrect trust decisions by the \gls{euicc}:
@@ -619,14 +619,21 @@ By combining a series of failed and mutated authentication requests, it was poss
 \begin{enumerate}
     \item A first \texttt{AuthenticateServerRequest} containing a malformed or mutated certificate (e.g., bit-flipped data) is sent to the \gls{euicc}. As expected, this request fails.
     
-    \item A second \texttt{AuthenticateServerRequest} is sent, using a valid profile but with the certificate truncated (i.e., digital signature and extensions removed). Surprisingly, the \gls{euicc} accepts this message and continues with the profile installation process.
+    \item A second \texttt{AuthenticateServerRequest} is sent, using a valid profile but with the certificate $Cert_{Sa}$ truncated (i.e., digital signature and extensions removed). Surprisingly, the \gls{euicc} accepts this message and continues with the profile installation process.
 
-    \item \gls{asn1} decoding of the truncated certificate on the \gls{lpa} side fails due to missing signature fields, but the \gls{euicc} does not reject it, indicating that signature verification was skipped.
+    \item \gls{asn1} decoding of the truncated certificate $Cert_{Sa}$ on the \gls{lpa} side fails due to missing signature fields, but the \gls{euicc} does not reject it, indicating that signature verification was skipped.
 
-    \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.
+    \item Swapping the \texttt{SubjectPublicKeyInfo} in the truncated certificate $Cert_{Sa}$ with an attacker-controlled public key $SK_A$ 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 $\mathrm{Cert}_{Sa} \triangleleft \mathrm{Cert}_{CI}$ as shown in \cref{fig:authenticate_server_sd}.
 \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{figure}[h!]
+	\centering
+    \includesvg[width=\textwidth]{Graphics/authenticate_server_sd.svg}
+    \caption{Sequence diagram of the authenticate server process.\cite{ahmed_security_2024}}
+    \label{fig:authenticate_server_sd}
+\end{figure}
+
+A deeper analysis of mutated \gls{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.
@@ -636,7 +643,7 @@ A deeper analysis of mutated APDU payloads of the initial \texttt{AuthenticateSe
     \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.
+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 $\mathrm{Cert}_{Sa} \triangleleft \mathrm{Cert}_{CI}$ appears to be bypassed entirely, as the mutated certificate $Cert_{Sa}$ 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: