Motivation

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:

The components and roles for providing these functions are introduced in the decomposition chapter of the architecture.

Collected Signals

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.

Overview

Android KeyAttestation Signals

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 Signals

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 RASP

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.

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 Attestation

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 Assertions

iOS RASP

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.

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.