Forensics of the Wallet: Detecting Local Credential Theft in eIDAS 2.0 Digital Identity Implementations

The Shift to the Edge: eIDAS 2.0 and the Mobile Wallet Target

The year 2026 marks a watershed moment for digital identity. Across the European Union and collaborating global jurisdictions, the deployment of the eIDAS 2.0 framework has transitioned from theoretical architecture to daily reality. Millions of citizens now carry European Digital Identity (EUDI) Wallets on their mobile devices, using them to store highly sensitive verifiable credentials—ranging from national IDs and driver’s licenses to professional qualifications and financial accounts.

Historically, identity systems relied on centralized servers, making those servers the primary targets for attackers. The decentralized nature of eIDAS 2.0, however, shifts the gravity of trust and security directly to the user’s mobile device. Because these wallets must operate offline and handle cryptographic keys locally, the client-side wallet application is now the ultimate prize for modern adversaries. If an attacker compromises a user’s device, they can attempt to extract private keys, bypass biometric checks, or harvest Selective Disclosure JWTs (SD-JWTs). For digital forensic examiners and mobile security engineers, understanding how to investigate and defend against local credential theft in this new ecosystem is paramount.

Under the Hood: How eIDAS 2.0 Wallets Secure Credentials

To understand how to investigate a compromise, we must first understand the security baseline of a standard EUDI-compliant wallet. The architecture relies on three core pillars:

• Hardware-Backed Storage: Private keys associated with credentials must be generated and stored within the device’s hardware security module—either the Secure Enclave (iOS) or StrongBox/Trusted Execution Environment (Android).
• Selective Disclosure (SD-JWTs): Instead of sharing a full identity profile, wallets use SD-JWTs to share only requested information (e.g., proving a user is over 18 without revealing their exact birthdate). This is achieved through salted cryptographic hashes of individual attributes.
• Device Attestation: During provisioning, the wallet app must prove to the issuer that it is running on an uncompromised, genuine operating system using hardware-backed attestation (like Apple’s DeviceCheck or Google’s Play Integrity API).

While this architecture is robust, it is not infallible. Attackers rarely attempt to crack the hardware cryptography directly. Instead, they exploit the software layer surrounding the hardware—the wallet application itself, its memory space, and the operating system’s IPC (Inter-Process Communication) mechanisms.

The Anatomy of Local Credential Theft

How do attackers compromise an eIDAS-compliant wallet? In practice, we observe two main vectors of client-side compromise: dynamic binary instrumentation (runtime manipulation) and memory scraping during credential presentation.

1. Dynamic Instrumentation and Biometric Bypass

An attacker with physical access, a compromised device, or user-authorized root access (e.g., through a malicious profile or sideloaded profile) can use frameworks like Frida or custom LLDB scripts to hook into the wallet’s runtime environment.

When the wallet prompts the user for a biometric authentication (FaceID/TouchID or Android BiometricPrompt) to authorize a credential release, the attacker doesn’t need to spoof the fingerprint. Instead, they hook the callback methods in the app’s runtime space. By forcing the runtime to execute the success callback (e.g., returning onAuthenticationSucceeded in Android’s BiometricPrompt.AuthenticationCallback), they bypass user consent entirely. If the cryptographic key release is not strictly bound to the hardware biometric verification itself (via key-agreement constraints), the app can be tricked into signing assertions without user interaction.

2. Memory Scraping during Selective Disclosure Generation

To construct a selective disclosure presentation, the wallet application must pull the fully decrypted, master SD-JWT into the application’s active heap memory, parse the disclosures, salt the requested fields, and generate the presentation token.

During this brief window, the master credential exists in plaintext within the application’s user-space memory. An attacker utilizing a high-privilege daemon or exploiting a local privilege escalation (LPE) vulnerability can dump the target process memory to extract these temporary, unblinded JSON structures. Once harvested, the attacker can reconstruct the user’s full, unredacted identity profile.

Forensic Artifacts: Hunting for Wallet Exploitation

When a digital forensic analyst is tasked with determining whether an eIDAS 2.0 wallet has been compromised, they must look for specific artifacts across both Android and iOS environments. Below are the key indicators of compromise (IoCs) and forensic procedures for each platform.

Android Forensic Analysis

On Android, the EUDI wallet typically stores its non-cryptographic metadata, cached disclosures, and configuration inside its sandboxed data directory: /data/data/[wallet.package.name]/. Here is how to hunt for anomalies:

Crucial Check: Examine the shared_prefs and local SQLite databases (e.g., app_database.db). If the device has been rooted, or if a backup exploit was utilized, these files may show signs of external modification or unauthorized access timestamps.

To detect dynamic instrumentation and runtime hooking, analysts should inspect the system-level logcat output and look for signs of zygote injection. Run the following command via ADB to audit Keystore operations and search for unauthorized key usage attempts:

adb logcat -d | grep -iE "Keystore|Keymaster|KeyMint"

Look specifically for KM_ERROR_KEY_USER_NOT_AUTHENTICATED errors followed by an immediate, anomalous success state. This discrepancy strongly points to runtime class hooking where the application’s presentation layer was bypassed, but the underlying Keystore successfully released a non-biometrically bound key due to poor architectural design.

iOS Forensic Analysis

On iOS, the wallet’s private keys reside within the Keychain, isolated by Apple’s secure storage architecture. However, local attacks using jailbreaks or developer-mode exploits leave specific forensic footprints.

Analysts should extract a sysdiagnose or perform a logical backup to inspect the Unified Logging system. Filter the log entries using the log command-line utility for the LocalAuthentication framework or Keychain services:

log show --predicate 'senderImagePath contains "LocalAuthentication"' --info

Analyze the sequence of events. A normal transaction shows a clear chain: user interaction request -> secure enclave daemon processing -> biometric verification success. In contrast, an instrumentation-based bypass often exhibits “orphaned” application callbacks where the target wallet application registers a successful biometric validation event without any corresponding log activity from the biometrid or localauthd system daemons.

Additionally, check the application’s sandbox directory under /var/mobile/Containers/Data/Application/. Inspect the Library/Caches/ directory. If the developers poorly implemented SD-JWT parsing, you may find remnants of unencrypted master credentials written to temporary files or cached HTTP response directories.

Mitigation: Building Hardened Wallets

For developers building or integrating with eIDAS 2.0 ecosystems, relying solely on OS-level security is no longer sufficient. You must design the wallet defensively assuming the client OS is hostile.

1. Cryptographic Biometric Binding: Never rely on simple boolean return values from biometric APIs to authorize transactions. Instead, use keys that are cryptographically bound to the biometric state. On Android, this means calling setUserAuthenticationRequired(true) when generating keys in the KeyGenParameterSpec. On iOS, configure Keychain items with the kSecAccessControlUserPresence or kSecAccessControlBiometryAny flags. This ensures that the hardware itself refuses to decrypt or sign unless a physical biometric event actually occurs, rendering software-based callback bypasses useless.
2. Memory Scrubbing: Minimize the lifecycle of sensitive data in memory. Once an SD-JWT is parsed and the presentation token is generated, overwrite the raw memory buffers with zeroes (using secure zeroing techniques like memset_s in C/C++ or clearing byte arrays in managed languages) before reclaiming the memory.
3. Robust Device Attestation and RASP: Implement multi-layered Runtime Application Self-Protection (RASP). The wallet must actively detect debugging, reverse-engineering tools (such as Frida, Magisk, or Cydia Substrate), and emulator environments. Ensure that device attestation checks are validated on a secure, remote backend server, rather than locally inside the app.

Conclusion

The eIDAS 2.0 framework represents a monumental leap forward for user privacy and decentralized trust, but it changes the threat landscape permanently. As our digital identities become localized on mobile devices, security practitioners must pivot their focus toward client-side defense and forensic analysis of mobile runtimes. By understanding the artifacts of local credential theft and implementing cryptographic hardware-binding, we can ensure that our digital wallets remain secure vaults rather than open targets.