mirror of
https://sharelatex.tu-darmstadt.de/git/681e0e7a3a9c7c9c6b8bb298
synced 2025-12-07 13:18:00 +00:00
Update on Overleaf.
This commit is contained in:
nb72soza Bittner
@@ -686,9 +686,10 @@ To aid in the analysis and comparison, Table~\ref{tab:error_overview} summarizes
|
||||
\subsection{Analysis of Successful Mutations}
|
||||
\label{subsec:successful_mutations}
|
||||
|
||||
To further understand the behavior of different \glspl{euicc} \todo{Which euiccs?} under mutation-based fuzzing, we post-processed all recorded \gls{apdu} traces.
|
||||
To further understand the behavior of different \glspl{euicc} under mutation-based fuzzing, we post-processed all recorded \gls{apdu} traces.
|
||||
|
||||
\subsubsection*{Mutation Examples}
|
||||
Successful mutations were observed on \texttt{eSIM.me}, \texttt{5ber}, \texttt{Xesim}
|
||||
|
||||
\paragraph{GET\_EUICC\_INFO\_1 Truncation}
|
||||
A truncated \gls{apdu} with trailing padding bytes removed (e.g., \texttt{BF2000} $\rightarrow$ \texttt{BF20}) was still accepted and processed successfully by several \glspl{euicc}. This indicates that, for some non-critical operations, strict \gls{ber}/\gls{der} tag integrity is not enforced.
|
||||
@@ -704,74 +705,111 @@ In one case, the mutation engine truncated approximately 75\% of the \texttt{Aut
|
||||
\subsection{Certificate Validation Bypass}
|
||||
\label{subsec:certificate_bypass}
|
||||
|
||||
% Further experimentation revealed a state machine vulnerability in the \gls{rsp} implementation of \glspl{euicc} manufactured by Eastcompeace. This vulnerability allows partial bypass of the \gls{gsma} certificate chain validation under specific mutated sequences of \texttt{AuthenticateServer\-Request} messages.
|
||||
|
||||
According to the \gls{gsma} specification SGP.22~\cite{gsma_sgp22_2025}, the server authentication process is expected to follow a strict mutual authentication model:
|
||||
According to SGP.22~\cite{gsma_sgp22_2025}, secure channel establishment between the \gls{lpa} and the \gls{euicc} mandates server authentication. The client, the \gls{euicc}, must validate the server’s X.509 certificate chain, ensuring that it is rooted in the \gls{gsma} Root \gls{ca}. Furthermore, the digital signature of the \texttt{AuthenticateServerRequest} must be verified before continuing with profile download and installation:
|
||||
|
||||
\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).''
|
||||
``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}
|
||||
|
||||
This implies that the server certificate $Cert_{Sa}$ must be validated against the trusted GSMA root-of-trust $Cert_{CI}$, and the digital signature contained in the \texttt{AuthenticateServerRequest} must be successfully verified.
|
||||
|
||||
|
||||
To evaluate the robustness of this authentication flow, we formulate the following research questions:
|
||||
To assess real-world conformance with these expectations, the following research questions were formulated:
|
||||
|
||||
\begin{description}
|
||||
\item[RQ1:] Can certificate chain validation be bypassed during \texttt{AuthenticateServerRequest} handling?
|
||||
\item[RQ2:] Does the \gls{euicc} cache internal state across failed authentication attempts, and does this influence subsequent request handling?
|
||||
\item[RQ3:] Is it possible to skip digital signature verification by exploiting session state reuse?
|
||||
\item[RQ1:] Can the mandatory certificate chain validation be bypassed via malformed or truncated requests?
|
||||
\item[RQ2:] Does the \gls{euicc} cache trust-related state across failed authentication attempts or power cycles, and does this influence future authentication flows?
|
||||
\item[RQ3:] Is it possible to skip or bypass digital signature verification by crafting truncated payloads that exploit residual state?
|
||||
\end{description}
|
||||
|
||||
\subsection{RQ1: Certificate Truncation and Validation Bypass}
|
||||
\subsection*{RQ1: Certificate Truncation and Validation Bypass}
|
||||
\label{sec:rq1-truncation}
|
||||
|
||||
Initial tests involved sending a malformed authentication request $AS_1$ containing a syntactically invalid server certificate. As expected, the \gls{euicc} rejected this message.
|
||||
To determine whether certificate validation is properly enforced, a sequence of mutated \texttt{AuthenticateServerRequest} messages was issued. A first request $AS_1$ was crafted with a malformed certificate $Cert_{Sa}^{(1)}$, where a single bit was flipped in the \gls{asn1} tag field of the certificate’s `SEQUENCE`, changing \texttt{BF38} to \texttt{BE38}. This triggered a potential decoding failure on the \gls{euicc} to reject the request, as expected.
|
||||
|
||||
However, a second request $AS_2$, sent immediately afterward, contained a valid certificate structure but with truncated content, specifically the digital signature and X.509 extensions were removed. Surprisingly, the \gls{euicc} accepted this truncated certificate and proceeded with profile installation. Notably, the LPA’s ASN.1 decoder rejected the certificate, suggesting that the signature field was indeed malformed or missing. This implies that the \gls{euicc} skipped validation of both the certificate chain and the certificate's signature.
|
||||
Subsequently, a second request $AS_2$ was sent containing a structurally correct, but truncated version of $Cert_{Sa}^{(2)}$, lacking the digital signature and extensions required for complete X.509 validation. Despite these omissions, the \gls{euicc} accepted the request and proceeded to complete the profile installation. From the perspective of the \gls{lpa}, \gls{asn1} parsing failed, yet the \gls{euicc} made a trust decision as if the certificate were valid.
|
||||
|
||||
Thus, we conclude that certificate truncation can bypass mandatory verification mechanisms, answering \textbf{RQ1} in the affirmative.
|
||||
This demonstrates a critical breakdown in the certificate validation process, indicating that the server certificate was either not validated at all, or that validation relied on state carried over from $AS_1$. Therefore, \textbf{RQ1} can be affirmatively answered: certificate chain validation can be bypassed under controlled truncation conditions.
|
||||
|
||||
\subsection{RQ2: Session Caching and Cross-Request State Leakage}
|
||||
\subsection*{RQ2: Session Caching and State Persistence}
|
||||
\label{sec:rq2-caching}
|
||||
|
||||
To understand the acceptance of truncated messages, further experiments evaluated whether the \gls{euicc} reuses internal state from failed authentication attempts. In a typical experiment, a valid but malformed certificate $Cert_{Sa}$ was first sent in $AS_1$, followed by a truncated certificate in $AS_2$. If both requests were made to the same \gls{smdpp}, $AS_2$ succeeded, even though it did not include a verifiable public key or signature.
|
||||
To explore whether the \gls{euicc} caches data across authentication attempts, additional mutation experiments were performed. After a failed $AS_1$ with a corrupted certificate, a valid truncated certificate was accepted in $AS_2$, provided that both requests originated from the same \gls{smdpp}.
|
||||
|
||||
In contrast, changing the \gls{smdpp} between requests (e.g., from \texttt{rsp.truphone.com} to \texttt{rsp-eu.redteamobile.com}) caused the same second request to fail, returning an \texttt{UndefinedError}. This behavior strongly suggests that the \gls{euicc} caches per-server authentication state, most likely including the server’s public key or related cryptographic material.
|
||||
We performed a set of differential tests across two configurations:
|
||||
\begin{itemize}
|
||||
\item \textbf{Same-server scenario:} Using two activation codes issued by the same provider (e.g., \texttt{QR-G-5C-1LS-1W1Z9P7} and \texttt{QRF-SPEEDTEST}), the attack succeeded.
|
||||
\item \textbf{Cross-server scenario:} When changing the server to a different \gls{smdpp} (e.g., from \texttt{rsp.truphone.com} to \texttt{rsp-eu.redte\-mobile.com}), the identical $AS_2$ was rejected with an \texttt{UndefinedError}.
|
||||
\end{itemize}
|
||||
|
||||
Moreover, this cached state persisted even after power-cycling the device or removing and reinserting the eSIM, suggesting that the cache is stored in non-volatile memory within the \gls{euicc}.
|
||||
These results confirm that the \gls{euicc} caches authentication state scoped to the server identity as shown in \cref{img:auth-bypass-cache}. Notably, this state appears to persist even across full power cycles. When the \gls{esim} was physically removed from the card reader and reinserted, the same truncation attack still succeeded, indicating that state was retained in non-volatile storage.
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\includegraphics[width=0.8\linewidth]{figures/auth-bypass-cache.pdf}
|
||||
\caption{Behavioral difference between same-server and cross-server request sequences. Truncation bypass succeeds only when $AS_1$ and $AS_2$ are sent to the same \gls{smdpp}, implying server-specific session caching in the \gls{euicc}.}
|
||||
\label{fig:auth-bypass-cache}
|
||||
\includesvg[width=\textwidth,inkscapelatex=false]{Graphics/vulnerability_sd.svg}
|
||||
\caption{Impact of server identity on authentication state reuse. In same-server attacks, a malformed $AS_1$ followed by a truncated $AS_2$ leads to profile installation. In cross-server attacks, $AS_2$ is rejected, indicating scoped state persistence.}
|
||||
\label{img:auth-bypass-cache}
|
||||
\end{figure}
|
||||
|
||||
Figure~\ref{fig:auth-bypass-cache} summarizes the behavioral divergence between same-server and cross-server requests, highlighting the role of cached state in the vulnerability.
|
||||
\paragraph{Example Mutation Patterns.}
|
||||
Analysis of the \gls{apdu} payloads in failed $AS_1$ requests revealed consistent mutation patterns depending on the server origin:
|
||||
|
||||
\subsection{RQ3: Signature Skipping via Truncation}
|
||||
\begin{itemize}
|
||||
\item In same-server attacks, tag-level mutations were observed: e.g., flipping the tag of the \gls{asn1}-encoded \texttt{serverCertificate} from \texttt{BF38} to \texttt{BE38}.
|
||||
\item Additional mutated fields included:
|
||||
\begin{itemize}
|
||||
\item \texttt{euiccCiPKIdToBeUsed}
|
||||
\item \texttt{serverCertificate.issuer}
|
||||
\item \texttt{serverCertificate.serialNumber}
|
||||
\item \texttt{serverSigned1.serverChallenge}
|
||||
\item \texttt{serverSignature1}
|
||||
\end{itemize}
|
||||
\item In cross-server experiments, mutations in \texttt{server\-Challenge}, \texttt{server\-Signature1}, and other cryptographic fields caused the attack to fail, even when truncation was applied identically.
|
||||
\end{itemize}
|
||||
|
||||
These observations suggest that state retention is selective and scoped to prior interaction history with a specific \gls{smdpp}. Thus, \textbf{RQ2} is answered positively: trust state is cached across sessions and affects future request evaluation.
|
||||
|
||||
\subsection*{RQ3: Skipping Signature Verification via State Reuse}
|
||||
\label{sec:rq3-signature}
|
||||
|
||||
The third research question concerns the validity of the signature in the truncated certificate. In further tests, we replaced the \texttt{SubjectPublicKeyInfo} field in $AS_2$ with an attacker-controlled public key $SK_A$. Despite this modification, the \gls{euicc} continued to establish a secure channel—provided that $AS_1$ had been sent previously with a valid certificate.
|
||||
Finally, to determine whether signature validation $\mathrm{Cert}_{Sa} \triangleleft \mathrm{Cert}_{CI}$ as shown in \cref{img:authenticate_server_sd} is skipped, we modified the truncated certificate in $AS_2$ by injecting an attacker-controlled public key $SK_A$ into the \texttt{SubjectPublicKeyInfo} field. Despite this manipulation, the \gls{euicc} still proceeded to mutual authentication and secure channel establishment.
|
||||
|
||||
This suggests that the \gls{euicc} did not verify the signature in $AS_2$ at all, and instead reused the public key from the initial, failed request. Importantly, if $AS_1$ was omitted or came from a different \gls{smdpp}, the truncated $AS_2$ was correctly rejected. This supports the hypothesis that signature validation is skipped when previous authentication state is available.
|
||||
The only plausible explanation is that the \gls{euicc} ignored the actual contents of the truncated $Cert_{Sa}^{(2)}$, and instead reused the public key received in the previously failed $AS_1$. Supporting this, attempts to reverse the sequence (sending the truncated $AS_2$ first) always failed, as did replaying the same attack against a different \gls{smdpp}. Thus, \textbf{RQ3} is also confirmed: digital signature verification can be bypassed through state reuse.
|
||||
|
||||
\subsection{Security Implications}
|
||||
\subsection{Implications}
|
||||
\label{sec:implications}
|
||||
|
||||
The combination of certificate truncation, session caching, and signature skipping presents a serious violation of GSMA’s SGP.22 requirements. Server authentication can be bypassed under realistic conditions, enabling an attacker to impersonate a legitimate \gls{smdpp} server if they can trigger specific request sequences.
|
||||
|
||||
Specifically, the \gls{euicc} fails to:
|
||||
The observed behavior constitutes a severe violation of the security architecture defined in \gls{gsma} SGP.22. Specifically, the following breakdowns were observed:
|
||||
|
||||
\begin{enumerate}
|
||||
\item Enforce mandatory certificate chain validation against the GSMA Root CA.
|
||||
\item Validate the digital signature of the \texttt{AuthenticateServerRequest} after initial failure.
|
||||
\item Clear cryptographic session state after request rejection or power cycles.
|
||||
\item \textbf{Bypassed Certificate Validation:} The \gls{euicc} accepts truncated certificates lacking critical fields, including the digital signature and X.509 extensions.
|
||||
\item \textbf{Persistent State Caching:} Cryptographic or trust-related state is cached across sessions and power cycles, even in response to malformed input.
|
||||
\item \textbf{Skipped Signature Verification:} The \gls{euicc} does not re-verify signatures if a previously failed request cached valid key material.
|
||||
\item \textbf{Server-Scoped Trust Decisions:} State reuse is scoped to the \gls{smdpp} identity, allowing targeted trust bypasses under controlled conditions.
|
||||
\end{enumerate}
|
||||
|
||||
These behaviors not only violate Sections 4.5.1 and 4.5.2 of the GSMA SGP.22 specification, but also open a practical attack surface for persistent authentication bypass. Further analysis should investigate whether other fields, such as \texttt{serverSigned1} and \texttt{serverSignature1}, are also affected by state reuse.
|
||||
Together, these issues expose an attack surface where adversaries can craft a sequence of malformed requests to poison the internal state of the \gls{euicc}. Once in this compromised state, the \gls{euicc} may proceed with mutual authentication and secure channel establishment, even in the absence of a complete or verifiable certificate chain. This behavior violates the security expectations in Sections 4.5.1 and 4.5.2 of the SGP.22 specification~\cite{gsma_sgp22_2025}, which require end-entity certificate validation and strict signature verification for all authentication steps.
|
||||
|
||||
The certificate bypass was only observed on \glspl{euicc} manufactured by \textbf{Eastcompeace}. Devices from other vendors did not exhibit this behavior under the same test conditions, suggesting an implementation-specific vulnerability in Eastcompeace firmware or certificate handling logic.
|
||||
|
||||
|
||||
\subsection{Limitations and Future Work}
|
||||
\label{sec:limitations}
|
||||
|
||||
While the truncation-based bypass demonstrates a significant weakness in the certificate validation logic, it is not yet clear whether this vulnerability enables complete provisioning from an attacker-controlled \gls{smdpp}. The current attacks rely on prior interaction with a legitimate \gls{smdpp} that successfully injects a partially valid certificate into the \gls{euicc}'s internal state.
|
||||
|
||||
An open research question remains:
|
||||
|
||||
\begin{quote}
|
||||
\textit{Can an attacker-controlled \gls{smdpp} successfully provision a profile on a vulnerable \gls{euicc} by leveraging this truncation-based bypass, without ever presenting a valid certificate chain anchored in the \gls{gsma} Root \gls{ca}?}
|
||||
\end{quote}
|
||||
|
||||
In other words, can the bypass be generalized to completely circumvent the certificate trust model, enabling profile installation from an untrusted or rogue infrastructure? If confirmed, this would constitute a full break of the \gls{gsma} trust model and pose significant implications for mobile network operators and \gls{esim} vendors.
|
||||
|
||||
Future work will involve:
|
||||
|
||||
\begin{itemize}
|
||||
\item Isolating which fields from $AS_1$ are retained in the cache and reused during $AS_2$ (e.g., public key, issuer name, signature fields, etc.).
|
||||
\item Reproducing the attack with a fully synthetic and attacker-controlled certificate chain.
|
||||
\item Verifying whether the attack can be conducted using arbitrary \gls{smdpp} endpoints and activation codes.
|
||||
\item Investigating whether other stateful fields (e.g., \texttt{serverSigned1}, \texttt{serverChallenge}) are also reused or must be aligned.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
% \paragraph{Expected Behavior.}
|
||||
@@ -834,12 +872,12 @@ These behaviors not only violate Sections 4.5.1 and 4.5.2 of the GSMA SGP.22 spe
|
||||
% \todo{Find out which parts are reused aswell -> serverSigned1, serverSignature}
|
||||
% \todo{serverSigned1 -> check if signature is verified}
|
||||
|
||||
\paragraph{Implications.}
|
||||
The observed behavior violates \gls{gsma} security requirements, particularly in Sections 4.5.1 and 4.5.2 of SGP.22~\cite{gsma_sgp22_2025}, which mandate certificate chain validation and signature verification during server authentication. The following points summarize the core issues:
|
||||
|
||||
\begin{itemize}
|
||||
\item The \gls{euicc} reuses elements (possibly the previously received certificate or derived session keys) from failed \texttt{AuthenticateServer\-Request} sessions.
|
||||
\item Certificate truncation alone does not prevent the \gls{euicc} from proceeding with secure channel establishment.
|
||||
\item The signature over the \texttt{tbsCertificate} is not validated after session caching has occurred.
|
||||
\end{itemize}
|
||||
% \paragraph{Implications.}
|
||||
% The observed behavior violates \gls{gsma} security requirements, particularly in Sections 4.5.1 and 4.5.2 of SGP.22~\cite{gsma_sgp22_2025}, which mandate certificate chain validation and signature verification during server authentication. The following points summarize the core issues:
|
||||
%
|
||||
% \begin{itemize}
|
||||
% \item The \gls{euicc} reuses elements (possibly the previously received certificate or derived session keys) from failed \texttt{AuthenticateServer\-Request} sessions.
|
||||
% \item Certificate truncation alone does not prevent the \gls{euicc} from proceeding with secure channel establishment.
|
||||
% \item The signature over the \texttt{tbsCertificate} is not validated after session caching has occurred.
|
||||
% \end{itemize}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user