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
@@ -14,6 +14,10 @@
|
||||
% estk.me does not offer an isd-r for regular interaction with our lpa implmenetation -> tesing is limited
|
||||
% 9esim v2 offers both -> only testing isd-r not USAT for RSP related communication
|
||||
|
||||
The primary objective of this evaluation is to apply differential testing to analyze the behavior and potential security implications of various commercial eSIM on SIM solutions. This methodology aims to uncover inconsistencies, implementation deviations, and potential vulnerabilities by observing how different cards react to the same input sequences under controlled conditions.
|
||||
To conduct a thorough and representative evaluation, we selected a diverse set of eSIM-on-SIM cards from multiple vendors. In total, \textbf{eight} different cards were included in the analysis, as shown in Table~\ref{tab:esim-overview}. These cards vary in terms of manufacturer, supported features, and firmware versions. The tests were conducted using the tracing, mutation, and fuzzing infrastructure described in \cref{ch:implementation}.
|
||||
|
||||
|
||||
\begin{table}[ht]
|
||||
\centering
|
||||
\begin{tabular}{|l|l|l|l|l|l|l|c|}
|
||||
@@ -35,6 +39,13 @@
|
||||
\label{tab:esim-overview}
|
||||
\end{table}
|
||||
|
||||
Among the tested cards, the \textbf{sysmoEUICC} is loaded with a GSMA test certificate, allowing it to interact with the official \gls{smdpp} test server infrastructure. This certificate is publicly available and enables the evaluation of remote profile management procedures in a realistic but controlled environment. The firmware implementation of the sysmoEUICC is assumed to be functionally equivalent to production-grade \glspl{esim}. However, this restricts use to use Profiles which are also signed by the GSMA test certificate.
|
||||
|
||||
In contrast, \textbf{estk.me} does not expose an \gls{isdr} for \gls{lpa}-based interaction, limiting the scope of evaluation for that platform. As such, only \gls{usat}-based interaction was possible, and no \gls{rsp}-related operations via the implemented testing framework could be performed.
|
||||
|
||||
The \textbf{9esim V2} card, in comparison, fully supports both \gls{isdr} access and \gls{usat} communication. Although \gls{usat} interfaces were excluded from evaluation for this particular card due to it not being supported by the testing framwork.
|
||||
|
||||
|
||||
% data fuzzing
|
||||
% data fuzzing was performed on all esim except the estk.me esim since this card does not offer an isd-r
|
||||
% each fuzzing test was performed on all esims one after one
|
||||
@@ -48,9 +59,36 @@
|
||||
% only stopped blinking when completly disconnected from PC
|
||||
% suggests possible bug in smartcard library
|
||||
|
||||
\section{Data Fuzzing}
|
||||
\label{sec:data_fuzzing_evaluation}
|
||||
|
||||
Data fuzzing, as described in \cref{sec:data_fuzzing}, was conducted on all tested \gls{esim} cards with the exception of \texttt{estk.me}. Each test case was executed sequentially across all eligible \glspl{esim} to ensure consistency and reproducibility of results.
|
||||
|
||||
The majority of the cards handled the fuzzed input data as expected, either processing the requests successfully or rejecting them gracefully with standard-compliant error responses. However, notable exceptions were observed during the execution of the \texttt{GetProfileInfo} test case, particularly for the following devices:
|
||||
\begin{itemize}
|
||||
\item 9esim
|
||||
\item 9esim V2
|
||||
\item EIOTCLUB
|
||||
\end{itemize}
|
||||
|
||||
In all three cases, the fuzzing input
|
||||
|
||||
\begin{lstlisting}[language=Python]
|
||||
get_profiles(use_iccid=False, profile_class=None, tags=b'')
|
||||
\end{lstlisting}
|
||||
|
||||
resulted in a \texttt{CardConnectionException} raised by the \texttt{smartcard} Python library during \gls{apdu} transmission.
|
||||
|
||||
During these failures, a consistent and unusual hardware behavior was observed. The transaction LED on the card reader continued to blink, suggesting ongoing \gls{apdu} activity, even though no further commands were being issued by the fuzzing logic. This blinking persisted even after the test process was terminated and, in some cases, even after the \gls{esim} card was physically removed from the reader.
|
||||
|
||||
The LED activity ceased only when the card reader was fully disconnected from the host machine. This behavior strongly indicates that the failure triggered an inconsistent or undefined state within the underlying \texttt{smartcard} library or \texttt{libpcsc}.
|
||||
|
||||
% Although this failure was not directly traceable to a specific eSIM firmware implementation (due to the exception occurring before a meaningful response could be recorded), its repeatability across multiple cards and hardware sessions suggests it warrants further investigation—potentially outside the scope of this work but relevant for tooling robustness in future studies.
|
||||
|
||||
|
||||
\begin{table}[h!]
|
||||
\centering
|
||||
\caption{Data fuzzing results for each function per eSIM}
|
||||
\caption{Data fuzzing results for each function per \gls{esim}}
|
||||
\label{tab:data_fuzzing_result}
|
||||
\begin{tabular}{lcccccc}
|
||||
\toprule
|
||||
@@ -141,18 +179,70 @@
|
||||
% high shannon entropy of (TODO: check shannon entrpoy of all firmware versions)
|
||||
% analysing the firmware files with ghidra also just showed just binary data without any structure
|
||||
|
||||
\section{General Findings}
|
||||
\label{sec:general_findings}
|
||||
|
||||
Among all evaluated \glspl{esim}, \texttt{estk.me} stands out due to its publicly available firmware update utility, which is offered via their official website. This binary executable provides both the latest firmware images and the means to apply updates directly from a host machine, making it a unique case in comparison to other \gls{esim} vendors, none of whom publicly expose firmware updates or custom flashing endpoints.
|
||||
|
||||
\subsubsection*{Firmware Structure and Analysis}
|
||||
|
||||
The firmware image accompanying the update utility appears to be encrypted or obfuscated. An entropy analysis conducted using the Shannon entropy metric indicates a consistently high entropy across all tested firmware files, suggesting the presence of encryption or compression. For instance, the entropy of the T001V06 firmware image was measured at approximately \texttt{7.998}, which is close to the theoretical maximum of \texttt{8.0} for purely random data.
|
||||
|
||||
\todo{Entropy graph, shannon entropy for all firmwares}
|
||||
|
||||
A deeper static analysis using Ghidra did not reveal any recognizable structure or file headers, further supporting the assumption of encryption. Similarly, tools like Binwalk\footnote{https://github.com/ReFirmLabs/binwalk} did not detect known compression schemes, embedded file systems, or file signatures. Consequently, firmware payload analysis could not be meaningfully performed beyond block-level transmission.
|
||||
|
||||
\subsubsection*{Firmware Update Mechanism}
|
||||
|
||||
The update mechanism exposes two primary functions via a custom \gls{aid} endpoint:
|
||||
\begin{itemize}
|
||||
\item \texttt{get\_version}: retrieves the currently installed firmware version.
|
||||
\item \texttt{flash\_firmware}: performs the actual firmware flashing process.
|
||||
\end{itemize}
|
||||
|
||||
The \gls{aid} used to access the update utility differs based on firmware generation. For example, the test card (generation T001) uses the \gls{aid} :
|
||||
\begin{quote}
|
||||
\texttt{A06573746B6D65FFFFFFFF6677757064}
|
||||
(hex-encoded: \texttt{'estkmeÿÿÿÿfwupd'})
|
||||
\end{quote}
|
||||
Firmware versions follow the format \texttt{TXXXVXX}, where major generation (\texttt{T000}--\texttt{T003}) and minor version are encoded. Firmware updates are incremental and strictly one-way, the tool automatically selects the next version based on the currently installed one, and downgrade paths are not supported.
|
||||
|
||||
\subsubsection*{Firmware Flashing Procedure}
|
||||
|
||||
The update process proceeds as follows:
|
||||
\begin{enumerate}
|
||||
\item \textbf{Initialize}: Select the \gls{aid} and send the initialization \gls{apdu} \texttt{CLA=0x01, INS=0x55, P1=0x55, P2=0x55}.
|
||||
\item \textbf{Unlock}: Issue the unlock \gls{apdu} \texttt{AA21000000} to enable flashing.
|
||||
\item \textbf{Send Firmware Blocks}:
|
||||
\begin{itemize}
|
||||
\item Firmware is divided into blocks of size \texttt{0x80D} bytes.
|
||||
\item Each block is sent in subchunks, using standard \glspl{apdu} (\texttt{CLA=0xAA}) with \texttt{INS=0x11}.
|
||||
\item After transmission, the same chunk is re-sent with \texttt{INS=0x12}, no payload, and the expected response length (\texttt{Le}) matches the chunk size.
|
||||
\end{itemize}
|
||||
\item \textbf{Check Flash Status}: The \gls{apdu} \texttt{AA13000000} is used to verify correct flash writing.
|
||||
\item \textbf{Finalize}: The \gls{apdu} \texttt{AA00000000} marks the end of the update process.
|
||||
\end{enumerate}
|
||||
|
||||
The update tool fails gracefully only under specific conditions. For malformed or incorrect \glspl{apdu}, the \gls{euicc} abruptly terminates the connection, leading to a \texttt{CardConnectionException} raised by the PC/SC stack. This maps to the \texttt{SCARD\_E\_NOT\_TRANSACTED (0x80100016)} error, which occurs when the host attempts to communicate over a closed or non-existent connection~\cite{pcsclite_errors}.
|
||||
|
||||
\subsubsection*{Reverse Engineering and Mutation Testing}
|
||||
|
||||
Using insights gained from disassembly in Ghidra, a Python-based reimplementation of the update mechanism was developed and available via the \gls{cli} as shown in \cref{sec:cli}. This allowed fine-grained control over the update process and enabled targeted mutation-based testing of firmware blocks.
|
||||
|
||||
The same mutation strategies as shown in \cref{subsubsec:mutation_engine}, such as bit flipping, byte shuffling, truncation, and others, were applied to the firmware blocks on a per-chunk basis during both initial transmission and block validation. Notably, mutated blocks were generally accepted until the \texttt{check\_flash\_status} step, where the \gls{euicc} would immediately terminate the connection. This behavior strongly suggests that the device internally verifies each block against a checksum or hash.
|
||||
|
||||
|
||||
|
||||
% tracing
|
||||
% using simtrace 2 tracing and recording traffic showed that some esims use different aids for the isdr
|
||||
% -> insert sample trace
|
||||
\begin{lstlisting}[style=logstyle, caption={Traced APDUs when launching the esim.me App}]
|
||||
INFO Captured MANAGE CHANNEL Apdu(00 70 00 00 01 01 9000)
|
||||
INFO Captured SELECT MF/ADF.ISD-R Apdu(01 A4 04 00 10 a0000005591010ffffffff8900000100 6f1f8410a0000005591010ffffffff8900000100a5049f6501ffe0058203020200 9000)
|
||||
INFO Captured MANAGE CHANNEL Apdu(00 70 00 00 01 01 9000)
|
||||
WARNING SELECT UNKNOWN AID a0000005591010000000008900000300
|
||||
INFO Captured SELECT Apdu(01 A4 04 00 10 a0000005591010000000008900000300 6a82)
|
||||
\end{lstlisting}
|
||||
% \begin{lstlisting}[style=logstyle, caption={Traced APDUs when launching the esim.me App}]
|
||||
% INFO Captured MANAGE CHANNEL Apdu(00 70 00 00 01 01 9000)
|
||||
% INFO Captured SELECT MF/ADF.ISD-R Apdu(01 A4 04 00 10 a0000005591010ffffffff8900000100 6f1f8410a0000005591010ffffffff8900000100a5049f6501ffe0058203020200 9000)
|
||||
% INFO Captured MANAGE CHANNEL Apdu(00 70 00 00 01 01 9000)
|
||||
% WARNING SELECT UNKNOWN AID a0000005591010000000008900000300
|
||||
% INFO Captured SELECT Apdu(01 A4 04 00 10 a0000005591010000000008900000300 6a82)
|
||||
% \end{lstlisting}
|
||||
% line X shows that the selected aid could not be mapped to anything known
|
||||
% probably done by vendors to force people to use their own lpa implementations eventough this is also limited by the ara-m
|
||||
% we found the following isdr aids
|
||||
@@ -164,6 +254,37 @@ INFO Captured SELECT Apdu(01 A4 04 00 10 a0000005591010000000008900000300
|
||||
% replaying the traffic to other esims did not show any relevant or interisting behaviour
|
||||
% limited to small subset of esim functionality due to usage of nonces for specific tasks
|
||||
|
||||
\section{Tracing}
|
||||
\label{sec:tracing}
|
||||
|
||||
To investigate vendor-specific behaviors in \gls{rsp}, we employed SIMTrace2 to capture the \glspl{apdu} exchanged between the \gls{lpa} and the \gls{esim}. This enabled us to analyze the communication protocols used during profile management and \gls{euicc} interaction, especially focusing on the discovery and selection of the \gls{isdr}.
|
||||
|
||||
During the analysis of the \texttt{eSIM.me} eSIM, we observed the use of a custom \gls{aid} during the SELECT command for \gls{isdr}. The following listing illustrates a sample trace captured while launching the \texttt{esim.me} Android application:
|
||||
|
||||
\begin{lstlisting}[style=logstyle, escapeinside={(*}{*)}, caption={Traced APDUs when launching the esim.me App}]
|
||||
INFO Captured MANAGE CHANNEL Apdu(00 70 00 00 01 01 9000)
|
||||
INFO Captured SELECT MF/ADF.ISD-R Apdu(01 A4 04 00 10 a0000005591010ffffffff8900000100 6f1f8410a0000005591010ffffffff8900000100a5049f6501ffe0058203020200 9000)
|
||||
INFO Captured MANAGE CHANNEL Apdu(00 70 00 00 01 01 9000)
|
||||
WARNING SELECT UNKNOWN AID a0000005591010000000008900000300(*\label{code:unkown_aid}*)
|
||||
INFO Captured SELECT Apdu(01 A4 04 00 10 a0000005591010000000008900000300 6a82)
|
||||
\end{lstlisting}
|
||||
|
||||
The log highlights a noteworthy behavior: in line \ref{code:unkown_aid}, the SELECT command targets an unknown \gls{aid} \texttt{a0000005591010000000008900000300}, which results in status word \texttt{6A82} (File not found). This custom \gls{aid} is not documented in standard \gls{gsma} or \gls{gp} specifications and appears to be vendor-specific.
|
||||
|
||||
This behavior suggests that certain vendors, such as \texttt{esim.me}, implement proprietary \glspl{aid} in parallel to the standardized \gls{isdr} \gls{aid} (\texttt{A0000005591010FFFFFFFF8900000100}). This may serve as an obfuscation or access control measure, potentially restricting third-party \gls{lpa} implementations or enforcing usage of vendor-specific software. However, due to the mandatory access mediation performed by the \gls{aram}, the effectiveness of such mechanisms is ultimately constrained by access control policies defined on the card.
|
||||
|
||||
We catalogued the \gls{isdr} \glspl{aid} observed during tracing across multiple \gls{esim} vendors:
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{Xesim}: \texttt{A0000005591010FFFFFFFF8900000177}
|
||||
\item \textbf{5ber}: \texttt{A0000005591010FFFFFFFF8900050500}
|
||||
\item \textbf{eSIM.me}: \texttt{A0000005591010000000008900000300}
|
||||
\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}
|
||||
|
||||
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.
|
||||
|
||||
% apdu fuzzing
|
||||
|
||||
@@ -221,14 +342,56 @@ INFO Captured SELECT Apdu(01 A4 04 00 10 a0000005591010000000008900000300
|
||||
% adjusting the specific tags to make it decodable shows that there is now differenence to a successfully decoded AuthenticateServerResponse apdu apart from the euiccSignature1, serverChallenge and transactionId. All of which are supposed to be different
|
||||
% still interisting that the response data was malformed
|
||||
|
||||
|
||||
\section{APDU Fuzzing}
|
||||
\label{sec:apdu_fuzzing}
|
||||
|
||||
To evaluate the robustness of \gls{rsp} protocol handling and smart card behavior under malformed input, we applied mutation-based fuzzing at the \gls{apdu} level. The goal was to explore unintended code paths and observe crash conditions or unexpected responses.
|
||||
|
||||
\subsection*{Optimizing for Coverage}
|
||||
Initial fuzzing experiments revealed that applying aggressive mutations across all \glspl{apdu} early in a transaction significantly hindered code path exploration. In many cases, although a mutation in an early \gls{apdu} succeeded in provoking an altered behavior or state change, subsequent mutated \glspl{apdu} caused premature failures. As a mitigation strategy, we adopted a greedy mutation approach: once a mutation led to a successful state transition, the subsequent \glspl{apdu} in that session were executed unmutated to allow complete transaction processing and thereby maximize coverage.
|
||||
|
||||
\subsection*{Experimental Setup}
|
||||
All tests were conducted using a HID OMNIKEY 3121 USB smart card reader.\glspl{esim} were inserted into a Sysmocom 2FF-to-full-size adapter to ensure compatibility with the reader. For consumer-grade \glspl{esim}, the following profile was used:
|
||||
\begin{center}
|
||||
\texttt{LPA:1\$rsp.truphone.com\$QR-G-5C-1LS-1W1Z9P7}
|
||||
\end{center}
|
||||
|
||||
For the \texttt{sysmoEUICC}, which uses the \gls{gsma} test certificate, the following test profile was employed:
|
||||
\begin{center}
|
||||
\texttt{LPA:1\$smdpp.test.rsp.sysmocom.de\$TS48v5\_SAIP2.1B\_NoBERTLV}
|
||||
\end{center}
|
||||
|
||||
The execution time of fuzzed \gls{apdu} sequences varied depending on chip processing speed and the degree to which the mutated input triggered deeper protocol branches.
|
||||
|
||||
\subsection*{Observed Errors}
|
||||
The following classes of errors were consistently encountered during mutation campaigns:
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{SCP03TSecurityError}: Occurred during the \texttt{LoadBoundProfilePackage} step, particularly when transmitting \texttt{sequenceOf86}, \texttt{sequenceOf88}, or the initial \texttt{sequenceOf87}. This indicates failure during Secure Channel Protocol 03 (terminal-side variant) session establishment.
|
||||
|
||||
\item \textbf{ApduException}: Triggered by malformed \gls{asn1} structures, typically due to mutations altering length or tag fields.
|
||||
|
||||
\item \textbf{InvalidCertificate}: Observed during \texttt{AuthenticateServer} and \texttt{PrepareDownload}. The \gls{euicc} rejected the server certificate during validation.
|
||||
|
||||
\item \textbf{InvalidSignature}: Raised exclusively during \texttt{InitialiseSecureChannelRequest}, indicating that the \gls{euicc} failed to verify the signature required for secure channel establishment.
|
||||
|
||||
\item \textbf{UnsupportedRemoteOpType}: Also restricted to \texttt{InitialiseSecureChannelRequest}. Mutation operators such as \texttt{ZERO\_BLOCK} or \texttt{TRUNCATE} corrupted the operation type field, which is normally set to \texttt{installBoundProfilePackage (1)}.
|
||||
|
||||
\item \textbf{UnsupportedCurve}: Introduced via bit-level mutations affecting certificate parameters. The \gls{euicc} did not support the altered elliptic curve definition.
|
||||
|
||||
\item \textbf{UndefinedError}: A non-specific error raised by the \gls{euicc} during \texttt{AuthenticateServer} and \texttt{FirstSequenceOf87}, implying the input could not be classified under known error types.
|
||||
|
||||
\item \textbf{DecodeTagError}: Thrown by the Python-side \gls{asn1} decoder during parsing of malformed responses. A representative example:
|
||||
\begin{quote}
|
||||
\texttt{euiccSignature1: Expected OCTET STRING (tag '5f37'), but got '2474'. (At offset: 271)}
|
||||
\end{quote}
|
||||
This indicates an inconsistency between the \gls{ber}-encoded tag and its expected value, likely due to mutated length fields or premature truncation. Notably, this malformed \gls{apdu} was still accepted and responded to by the \gls{euicc}, albeit with corrupt data.
|
||||
|
||||
\end{itemize}
|
||||
|
||||
|
||||
% successful mutations
|
||||
|
||||
% get_euicc_info_1 truncation
|
||||
% truncation with the deterministic engine always cuts of the last 75% of the apdu
|
||||
% bf2000 -> bf20
|
||||
% nothing to be interisting
|
||||
|
||||
|
||||
% analyzing recorded apdu fuzzing
|
||||
% PATHS = glob.glob("recordings/*.resim")
|
||||
%
|
||||
@@ -354,12 +517,75 @@ INFO Captured SELECT Apdu(01 A4 04 00 10 a0000005591010000000008900000300
|
||||
% same result when switching out the whole certificate
|
||||
% suggests that more than just the certificate is beeing reused from the previouse session
|
||||
|
||||
% TODO: Find out which parts are reused aswell -> serverSigned1, serverSignature
|
||||
% TODO: serverSigned1 -> check if signature is verified
|
||||
\subsection{Analysis of Successful Mutations}
|
||||
\label{subsec:successful_mutations}
|
||||
|
||||
\section{Design}
|
||||
To further understand the behavior of different \glspl{euicc} under mutation-based fuzzing, we post-processed all recorded \gls{apdu} traces stored in the \texttt{recordings/*.resim} directory.
|
||||
|
||||
\section{Findings}
|
||||
\label{sec:findings}
|
||||
\todo{Be more clear about how many and which recordings were performed}
|
||||
|
||||
\subsubsection*{Mutation Examples}
|
||||
|
||||
\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.
|
||||
|
||||
\paragraph{FIRSTSEQUENCEOF87 Bitflip}
|
||||
A single-bit mutation changed a byte from \texttt{0xA0} to \texttt{0xA1}. Despite the low-level alteration, the \gls{apdu} was accepted, suggesting a fallback to an alternate logical channel or slightly different interpretation of \gls{tlv} structure.
|
||||
|
||||
\paragraph{AUTHENTICATE\_SERVER Truncation}
|
||||
In one case, the mutation engine truncated approximately 75\% of the \texttt{AuthenticateServerRequest} \gls{apdu}—removing critical fields such as \texttt{ctxParams1}, the digital signature, and certificate extensions (including \texttt{2.5.29.14}, \texttt{2.5.29.17}, \texttt{2.5.29.35}). The \gls{apdu} failed \gls{asn1} decoding due to inconsistent length indicators; however, after manual correction, analysis revealed that the missing fields did not prevent the \gls{euicc} from accepting the request under specific conditions.
|
||||
|
||||
\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{AuthenticateServerRequest} messages.
|
||||
|
||||
\subsubsection*{Expected Behavior}
|
||||
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.
|
||||
|
||||
\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}:
|
||||
|
||||
\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 \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 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}
|
||||
|
||||
\subsubsection*{State Persistence Across Sessions}
|
||||
Further experiments showed that this vulnerability persists across sessions and even power cycles:
|
||||
|
||||
\begin{itemize}
|
||||
\item A failed mutated authentication is followed by a successful truncated certificate installation—even after the \gls{euicc} is physically removed and reinserted into the card reader.
|
||||
|
||||
\item If different profiles from the same \gls{smdpp} are used (e.g., activation codes \texttt{QR-G-5C-1LS-1W1Z9P7} and \texttt{QRF-SPEEDTEST}), the bypass remains possible.
|
||||
|
||||
\item However, if different \gls{smdpp} servers are used (e.g., \texttt{rsp.truphone.com} vs \texttt{rsp-eu.redteamobile.com}), the attack fails, and the \gls{euicc} returns an \texttt{UndefinedError}. This is supports the idea that the euicc reuses the public key from the previously sent but failed \texttt{AuthenticateServerRequest}.
|
||||
\end{itemize}
|
||||
|
||||
To further probe the caching mechanism, additional tests were conducted in which the public key of the second \texttt{AuthenticateServerRequest} was substituted into the first request. Based on previous observations, it was hypothesized that this would allow a successful installation by aligning the reused state with the new request.
|
||||
|
||||
However, these attempts consistently resulted in an \texttt{UndefinedError} exception. The same error occurred even when replacing the entire certificate with the one used in the second request. This strongly suggests that the \gls{euicc} caches more than just the certificate object, potentially including intermediate cryptographic material or session-specific internal state derived from the original malformed request.
|
||||
|
||||
This reinforces the assumption that the \gls{euicc} maintains non-trivial persistent state across sessions, and that this state influences the acceptance of subsequent messages even when they originate from clean profiles or well-formed certificates.
|
||||
|
||||
\todo{Find out which parts are reused aswell -> serverSigned1, serverSignature}
|
||||
\todo{serverSigned1 -> check if signature is verified}
|
||||
|
||||
\subsubsection*{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{AuthenticateServerRequest} 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}
|
||||
|
||||
\section{estk Firmware Update Application}
|
||||
|
||||
@@ -327,6 +327,7 @@ Fuzzing is conducted through predefined \emph{scenarios}—sequences of function
|
||||
This process is guided by an \textbf{operation recorder} that tracks each function call, applied mutations, and resulting responses in a structured \emph{mutation tree}. Each tree node represents a specific function call executed with one type of mutation. A tree level corresponds to a function in the scenario; sibling nodes represent different mutations of that function.
|
||||
|
||||
\subsubsection*{Mutation Engine}
|
||||
\label{subsubsec:mutation_engine}
|
||||
|
||||
The mutation engine supports both \textit{deterministic} and \textit{random} mutation modes, and implements the following strategies:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user