https://bmi.usercontent.opencode.de/eudi-wallet/wallet-development-documentation-public/latest/architecture-concept/06-mobile-devices/02-mdvm/ [ ] [ ] Skip to content German National EUDI Wallet: Architecture Documentation Mobile Device Vulnerability Management Concept ( ) ( ) [ ] Initializing search wallet-development-documentation-public * Home * Architecture * Data Flows * MDVM * UI/UX * Guidelines German National EUDI Wallet: Architecture Documentation wallet-development-documentation-public * Home * [ ] Architecture Architecture + Scope + Decomposition + Data Register + Sequence Diagrams + Cryptography + Mobile Devices + User Interface and User Experience * [ ] Data Flows Data Flows + Wallet Activation + Wallet Registration + Issuance of Wallet Instance Attestation (WIA) + Wallet Revocation + Remote WSCA Operations + PID Issuance + PID Presentation + PID Deletion * [*] MDVM MDVM + [ ] Mobile Device Vulnerability Management Concept Mobile Device Vulnerability Management Concept Table of contents o Motivation o Collected Signals # Overview # Android KeyAttestation Signals # Android PlayIntegrity Verdict Signals # Android RASP # iOS DCDeviceCheck.AppAttest Attestation # iOS DCDeviceCheck.AppAttest Assertions # iOS RASP + Mobile Device Vulnerability Management Flows + Requirements for Mobile Devices * [ ] UI/UX UI/UX + UI/UX Documentation and Summary of current User Studies + User Flow Diagrams * [ ] Guidelines Guidelines + Establishing app integrity + eID Flow Table of contents * Motivation * Collected Signals + Overview + Android KeyAttestation Signals + Android PlayIntegrity Verdict Signals + Android RASP + iOS DCDeviceCheck.AppAttest Attestation + iOS DCDeviceCheck.AppAttest Assertions + iOS RASP 1. Home 2. MDVM Mobile Device Vulnerability Management ConceptP MotivationP The Wallet Unit provides for authentication means which can be bound to multiple identification means, such as the PID, via a public/ private key pair, see cryptography. When issuing the PID, the WB confirms to the PP (via OpenID4VCI Key Attestation) that the keys to which a PID is to be bound are controlled by an authentication means(../05-cryptography.md) that meets certain security requirements with regard to resistance against attackers with a certain attack potential (see ISO/IEC 18045). Furthermore, in the context of performing electronic identification at assurance level high, such as the PID, it is required that authentication of wallet users is done in accordance with, the requirements for the characteristics and design of electronic identification means at assurance level high, as set out in Implementing Regulation (EU) 2015/1502 (see CIR 2024/2979 Article 5 1. b/g). Therefore, the authentication means provides two important assurances: 1. The authentication means protects against duplication and tampering attacks to the key store by attackers with high attack potential. Thus, the PP can be sure that it's issued credentials that are bound to the keys of the authentication mean cannot be duplicated by an attacker with high attack potential and thus the identification means itself cannot be duplicated in their entirety (see CIR 2015/1502 Annex 2.2.1). 2. The authentication means protects against attacks on the user's authentication mechanism by attackers with high attack potential. Thus, the PP can be sure that it's issued credentials that are bound to the keys of the authentication mean cannot be misused by an attacker with high attack potential, e.g. for single presentations of a credential (see CIR 2015/1502 Annex 2.3.1). The first assurance can be achieved by creating and processing the relevant keys in an RWSCD implemented as an HSM that has been appropriately evaluated and certified. This assurance can therefore be achieved independently of the user device. The second assurance concerns the authentication mechanism of the user towards the relying party when presenting the credential. This includes two-factor authentication of the user towards the RWSCA. The security of the user authentication mechanism and the authentication factors depend on the security of the user device. The solution comprises a possession factor secured by the HKS of the mobile device and a knowledge factor entered via the mobile device. The security of the possession factor depends on the existence of exploitable vulnerabilities in the HKS of the mobile device that allow the key to be extracted or misused. The security of the knowledge factor, depends on the existence of exploitable vulnerabilities in the wallet instance and/or the operating system of the mobile device. A preceding vulnerability analysis and certification of the HKS or the OS with regard to resistance to a specific attack potential, which would significantly reduce the likelihood of the existence of relevant vulnerabilities, is not available for mobile devices in practice. Rather, it can be observed that relevant vulnerabilities have become known for mobile devices in the past. For this reason, the solution provides for monitoring identified vulnerabilities for the HKS and the operating system of user devices through a mobile device vulnerability management (MDVM) during operation to reduce the likelihood that existing relevant vulnerabilities can be exploited. This is achieved by ensuring that if vulnerabilities are known for a user device that could compromise the user's authentication mechanism towards the RWSCA with a attack potential of 'high' or lower, the use of keys secured by the RWSCA/ RWSCD is prevented. Thus, the confirmation of the WB to the PP remains valid. To achieve this goal, the MDVM provides for the following functions: Function Description Provides verified information regarding device integrity and authenticity, as well as wallet app Verify device/ integrity and authenticity for a specific user device app security /wallet instance. To achieve this, security functions posture from the platform of the user device are used, as well as platform independent solutions such as RASP (Runtime Application Self-Protection) solutions. Provides verified information regarding the device Identify device model, the operating system incl. version and patch class level and the HKS. This could be achieved with the verified information from platform attestations and RASP attestations. Verify Provides up-to-date information on relevant vulnerabilities vulnerabilities of the device operation system and for device HKS of a dedicated device class. classes Based on device/app security and vulnerability Decide on information, (1) prevent confirmation to the PP via device/app OpenID4VCI Key Attestation if devices/wallet usage instances are not sufficient secure, (2) prevent the use of RWSCD keys by user authentication with insufficiently secure devices/wallet instances. The components and roles for providing these functions are introduced in the decomposition chapter of the architecture. Collected SignalsP This chapter provides an overview of the collected signals and their mapping to relevant threats. It also describes additional uses of these signals for plausibility checks and for determining the device class used to query the MDVM databases. OverviewP Signal-Source Threats Synergies Notes rooting via unlocked bootloader, unknown system image (e.g. custom ROM), loss of Used as input root of trust (e.g. for DCVDB, manipulated boot needs LPADB to sequence), app increase KeyAttestation repackaging & tampering LPADB, RASP resilience & spoofing & against downgrading, app non-publicly cloning, device or HKS leaked emulation attacks, KeyAttestation Replay attacks, keys response reuse, device proxy used to spoof attestations app repackaging & tampering & spoofing, Replay attacks, response reuse, proxy attestations, app Bootloader downgrade attacks, state needs to side-loaded older be checked to vulnerable app trust versions, rooting via PlayIntegrity unlocked bootloader, verdicts, unknown system image Unsure how (e.g. custom ROM), loss trustworthy - of root of trust (e.g. unclear how manipulated boot the evaluation PlayIntegrity sequence) + Google KeyAttestation, in the google proprietary backend RASP backend works MDVM verdict to (also known to identify compromised be often devices, Credential targeted by theft tools, input open source automation/bots, rooting overlay attacks (e.g. community tapjacking), can be using leaked used to enforce KeyAttestation security update keys) policies (MEETS_STRONG_INTEGRITY requires a security patch in the last 12 months) Replay attacks, tampering with DeviceCheck certificate, device needs proxy used to spoof additional attestations, app security iOS DC Device repackaging & tampering RASP measures as it Check & spoofing, leaked does not debug builds, it's attest to the unclear from integrity of documentation what the device - additional threats RASP could be mitigated Leaked Platform rooting based on Attestation Key unlocking bootloader Database using publicly leaked KeyAttestation - (LPADB) attestation keys for obfuscation insecure user devices DCVDB is only Device Class due to publicly known as effective Vulnerability vulnerabilities e.g. KeyAttestation, as the Database rooting/local privilege RASP identification (DCVDB) escalation, TEE, of the correct bootloader/chain of device class trust exploits RASP provides a way to continuously and dynamically monitor the app and the user's device for integrity Runtime App Hooking/debugging & and Application Repackaging & authenticity Self-Protection tampering, UD rooting & - while the app (RASP) emulation is running. Additionally, it provides an alternative detection framework that operates independently of the platform mechanisms. Android KeyAttestation SignalsP Signal Enforcement Details Example Value Mitigated Additional Plausibility Threats Usage Check emulation ensure the attacks e.g. keys are used, must SecurityLevel Hardwareenforced identifies HKS TrustedEnvironment emulation of stored in always be type or StrongBox devices or a secure the same key stores key storage e.g. "SM-A146P" for used to used, must attestationIdModel Hardwareenforced identifies a Samsung Galaxy app cloning identify always be device model A14 5G device the same class identifies used to device model e.g. "a14xmeea" for identify used, must attestationIdProduct Hardwareenforced (alternative a Samsung Galaxy app cloning device always be source A14 5G class the same attribute) identifies used to device model e.g. "a14xm" for a identify used, must attestationIdDevice Hardwareenforced (alternative Samsung Galaxy A14 app cloning device always be source 5G class the same attribute) app cloning, used to used, can osVersion Hardwareenforced identifies OS e.g. "130000" for downgrade identify only version Android 13 attacks device increase, class not decrease identifies the e.g. "202508" for used to used, can osPatchLevel Hardwareenforced current security patch - identify only security patch level August 2025 device increase, level class not decrease rooting via unlocked bootloader, e.g. "true" if unknown identifies the device booted a system image RootOfTrust. Hardwareenforced current boot signed image that (e.g. custom - not used deviceLocked loader state was successfully ROM), loss verified by of root of Verified Boot trust (e.g. manipulated boot sequence) rooting via unlocked bootloader, unknown system image identifies the e.g. "Verified" for (e.g. custom RootOfTrust. Hardwareenforced device's fully verified root ROM), loss - not used verifiedBootState Verified Boot of trust of root of state trust (e.g. manipulated boot sequence), emulation attacks Replay attacks, response attestationChallenge Hardwareenforced server-provided max 128 bytes reuse, - not used challenge length device proxy used to spoof attestations identifies apps AttestationApplicationId. that are app AttestationPackageInfo. Softwareenforced allowed to use e.g. repackaging - not used package_name the secret key "org.sprind.wallet" & tampering material under & spoofing attestation app identifies the downgrade used, can AttestationApplicationId. apps attacks, only AttestationPackageInfo. Softwareenforced "versionCode" e.g. "1" side-loaded - increase, version from the build older not decrease properties vulnerable app versions set of SHA-256 app AttestationApplicationId. Softwareenforced digests of the SHA-256 digests in repackaging - not used signature_digests app's signing Base64 encoding & tampering certificates & spoofing Notes: * "attestationIdModel", "attestationIdProduct", and "attestationIdDevice" can all be used to identify the device model for determining the device class. All three are included because tests have shown that some devices do not provide all of these values. To increase the likelihood of identifying the model via key attestation, all three fields should be evaluated. * The key attestation signature and certificates (including the full certificate chain) must be validated in order to rely on the signals as described. Google's revocation list for key-attestation certificates should also be checked. However, the list is not updated frequently enough, and there are regularly leaked keys publicly available that can still be used to sign key attestations but have not yet been revoked by Google. * Android key attestation also includes additional information about the properties of the attested key, such as user-authentication requirements for key usage or the key's purpose (signing, encryption, etc.). These aspects are not documented in this list, as they do not mitigate a specific threat to the app or the device. Nonetheless, they are important and must be verified when evaluating the key attestation. Android PlayIntegrity Verdict SignalsP Signal Provider Details Example Value Mitigated Collect Plausibility Threats Experience Check Package name the request claims to app requestDetails. originate from; repackaging & requestPackageName OS Play Integrity e.g. "org.sprind.wallet" tampering & - not used verifies it spoofing matches the calling app + signing cert Random value generated by Replay requestDetails. Wallet your backend to base64 encoded 16-32 attacks, nonce Backend prevent replay; bytes response - not used returned reuse, proxy unchanged in attestations the verdict Replay requestDetails. Time when e.g. "1672531199000" attacks, timestamp Google Google produced (Unix ms) response - not used the verdict reuse, proxy attestations Whether the app app is recognized repackaging & appIntegrity. Google as original, e.g. "PLAY_RECOGNIZED" tampering & - not used appRecognitionVerdict unmodified, spoofing, validly side-loading installed (unintended?) The actual package Google app appIntegrity. Google sees executing e.g. "org.sprind.wallet" repackaging & - not used packageName the request tampering & (also from a spoofing KeyAttestation) SHA-256 digest of the app's app appIntegrity. Google signing SHA-256 digests in repackaging & - not used certificateSha256Digest certificate Base64 encoding tampering & (also from a spoofing KeyAttestation) identifies the app downgrade apps attacks, could be appIntegrity. "versionCode" side-loaded used, can versionCode Google from the build e.g. "1" older - only properties vulnerable increase, (also from a app versions not decrease KeyAttestation) rooting via unlocked bootloader, unknown system image (e.g. custom ROM), loss of root of trust (e.g. manipulated boot deviceIntegrity. Describes e.g. sequence) + deviceRecognitionVerdict Google device trust "MEETS_STRONG_INTEGRITY" Google yes not used level proprietary backend MDVM verdict to identify compromised devices (we do not know what they are actually doing in their backend) The devices's could be deviceIntegrity. Android SDK API e.g. "33" for Android app cloning, used, can deviceAttributes. Google level (OS 13, downgrade - only sdkVersion Version) attacks increase, not decrease integrity token Bot traffic, deviceIntegrity. requests on emulator recentDeviceActivity. Google this device in e.g. "LEVEL_1" to farms, proxy yes not used deviceActivityLevel the last hour "LEVEL_4" device to per app spoof verdicts Indicates if e.g. "LICENSED", sideloaded accountDetails. Google the app has "UNLICENSED", APKs without yes not used appLicensingVerdict been installed "UNEVALUATED" entitlement from PlayStore (unintended?) List of other apps detected that may capture, overlay, Credential control, or theft tools, environmentDetails. otherwise e.g. "KNOWN_CAPTURING", input appAccessRiskVerdict. Google interfere with "UNKNOWN_CONTROLLING" automation/ yes maybe appsDetected your app bots, overlay (screen attacks (e.g. recorders, tapjacking) overlay malware, automation tools, etc.) Using devices with known Indicates Play malware, environmentDetails. Google Protect's e.g. "NO_ISSUES" or disabled Play yes maybe playProtectVerdict assessment of "MEDIUM_RISK" Protect device/app risk (which is a possible user choice) Notes: * Since our minimum Android version will be Android 13, we will be checking for "MEETS_STRONG_INTEGRITY", and the table above is based on the capabilities of the hardware-backed Play Integrity verdict. * MEETS_STRONG_INTEGRITY also includes the requirement that the device has received a security patch within the last 12 months. * The PlayIntegrity verdict signature must be validated and the verdict needs to be decrypted (using keys provided via theGoogle Play Console) in order to rely on the signals as described. Android RASPP Since we have not yet decided on a RASP solution, the documented detection features should be considered a preliminary set of requirements for potential RASP solutions. Detection Details Mitigated Threats Feature Monitors for dynamic debugger attachment, library injection, Reverse engineering, App Hooking instrumentation frameworks (Frida, dynamic runtime /debugging Xposed, LSPosed, DobbyHook), and manipulation other forms of dynamic manipulation of runtime logic. Detects modifications to the app App bundle, re-signing with app repackaging & Repackaging unauthorized certificates, or tampering & spoofing injected frameworks before installation. Identifies binary patches, altered App code segments, unexpected file Disabled protections, tampering changes, and modifications to patched logic critical logic. Detects rooting indicators such as Privilege escalation, sandbox violations, privileged unrestricted hooking, UD rooting file access, injected toolchains, bypass of integrity and elevated OS capabilities. controls and sandbox isolation Detects execution in virtualized, UD automated, or non-real hardware Automation fraud, bot emulation environments through system attacks, spoofed behavior checks and hardware devices consistency verification. Notes: * RASP provides a way to continuously and dynamically monitor the app and the user's device for integrity and authenticity while the app is running. * Root detection by RASP is particularly important in the Android environment, as there are publicly known and well-documented methods that use leaked key-attestation keys to emulate a device with a locked bootloader, even when it is running a modified system image (e.g., a rooted system image). This root-detection mechanism works in combination with an independently maintained blocklist, separate from Google's revocation list, for publicly leaked key-attestation keys that have not been revoked by Google. It is intended in particular to serve as a barrier against the use of non-publicly leaked key-attestation keys. iOS DCDeviceCheck.AppAttest AttestationP Signal Provider Details Example Mitigated Plausibility Value Threats Check Replay attacks, tampering with certificate, it's unclear from documentation what Secure CBOR object that additional attestationObject Enclave + proves the App Binary CBOR threats could (x5c) Apple Attest key was structure be mitigated, not used attestation generated in a might also servers SecureEnclave identify app repackaging & tampering & spoofing, device emulation, tampered runtime, jailbroken (rooted) OS 32-byte opaque Key cloning used, Secure identifier for the Base64 or device checked credentialId Enclave App Attest key string proxy used to against generated in the spoof assertion Secure Enclave attestations Replay SHA-256 hash of attacks, Wallet your 32-byte response clientDataHash Backend server-provided digest reuse, device not used challenge proxy used to spoof attestations your app's App ID e.g. SHA-256 app RP ID OS + Secure prefix, a period ( TeamID + repackaging & not used Enclave and your "." + tampering & CFBundleIdentifier BundleID ) spoofing Indicates whether environment OS + Secure the key is from e.g. leaked debug (aaguid) Enclave "development" or "production" builds not used "production" environment It is unclear counts how many what the Secure times the key has implications initially counter Enclave been used to sign, "0" are if the stored to MUST be 0 for counter is populate DB attestations not equal to 0 Notes: * The attestation also includes a receipt that can be used to query a risk metric from Apple's servers. Apple's documentation describes this metric as follows: "The receipt represents the metric as a string that indicates the number of attested keys associated with a given device over the past 30 days. Look for this value to be a low number." This metric could help identify devices that are being used to generate attestations or assertions on behalf of other devices (proxy attestation threat). However, it has significant limitations: neither the metric nor the expected thresholds are clearly defined, and its use requires our backend to communicate with Apple's servers, which introduces additional privacy risks due to the potential for tracking on Apple's side. For additional information, see WardenSupreme's description of the feature. * iOS does not provide any hardware-backed information about the device model or the OS version/patch level. These values must be queried from the OS after ensuring that the device and operating system have not been tampered with. iOS DCDeviceCheck.AppAttest AssertionsP Signal Provider Details Example Mitigated Additional Plausibility Value Threats Usage Check Replay attacks, tampering with certificate, it's unclear from documentation CBOR object what containing additional Must validate Secure signature over Binary threats could signature with assertionObject Enclave challenge + state CBOR be mitigated, - attestation with the App structure might also public key Attest key identify app repackaging & tampering & spoofing, Device emulation, tampered runtime, jailbroken (rooted) OS Must match Identifier of the App cloning, known attested keyId (matches Secure App Attest key Base64 device proxy - keyId credentialId) Enclave used to sign the string used to spoof (credentialId assertion attestations from attestation) SHA-256 hash of Replay clientDataHash Wallet server-generated 32-byte attacks, - not used Backend challenge and digest response optional payload reuse e.g. OS + your app's App ID SHA-256( app RP ID Secure prefix, a period TeamID + repackaging & - not used Enclave and your "." + tampering & CFBundleIdentifier BundleID spoofing ) The counter is required to increase monotonically. Replay Big jumps attacks, could indicate Secure counts how many response app/device is counter Enclave times the key has "42" reuse, device - used to proxy been used to sign proxy used to attestations spoof for other app/ attestations devices, lower value then recorded point to a replay attack iOS RASPP Since we have not yet decided on a RASP solution, the documented detection features should be considered a preliminary set of requirements for potential RASP solutions. Detection Details Mitigated Threats Feature Monitors for dynamic debugger attachment, library injection, Reverse engineering, App Hooking instrumentation frameworks dynamic runtime /debugging (Frida, Substrate), and other manipulation forms of dynamic manipulation of runtime logic. Detects modifications to the app App bundle, re-signing with app repackaging & Repackaging unauthorized certificates, or tampering & spoofing injected frameworks before installation. Identifies binary patches, App altered code segments, unexpected Disabled protections, tampering file changes, and modifications patched logic to critical logic. Detects jailbreak indicators such Privilege escalation, UD rooting as sandbox violations, privileged unrestricted hooking, file access, injected toolchains, keychain access, bypass and elevated OS capabilities. of integrity controls. Detects execution in virtualized, UD automated, or non-real hardware Automation fraud, bot emulation environments through system attacks, spoofed behavior checks and hardware devices consistency verification. Notes: * Apple's platform security provides strong install-time protections: App Sandbox & Code Signing, App Store Review (prevent obviously malicious or re-signed apps from entering the store), System Integrity Protection (prevents unsigned code execution on non-jailbroken devices). Based on the documented functionality of these features they do not provide information about or protection against: Rooting (Jailbreak) or elevated privileges, runtime hooking or instrumentation. + "Your app uses the App Attest service to assert its authenticity. A compromised version of your app running on a genuine, unmodified Apple device can't create valid assertions." Apple documentation * RASP provides a way to continuously and dynamically monitor the app and the user's device for integrity and authenticity while the app is running. Back to top Previous PID Deletion Next Mobile Device Vulnerability Management Flows Copyright (c) BMI License: CC BY 4.0 Made with Material for MkDocs