[Wallet Solution] Can a rooted/jailbreaked device get a WIA?

[peppelinux]

The integrity check only certifies that the app code has not been compromised.
The checks (sometimes not exhaustive) on rooted/jailbroken must then be done at the app code level.

can we define a generic approach to obtain app security certification within the specs?

To date, it seems to us that a way to achieve this requirement is to use StrongBox (i.e. a hardware chip installed on the device on which cryptographic operations are carried out).

Other solutions such as TEE are software-based and therefore it is possible to circumvent the system in some way. For iOS, however, there is no problem as the Secure Enclave has always been hardware based.

The real problem with strongbox is that only a very limited number of devices support it (we are talking about single-digit numbers) and they are all very high-end smartphones.

It seems to not be there alternative approach to StrongBox to obtain the security certification of the app (among other things dictated by eidas2). This is why many are opting for HSM.

[grausof]

For now I'm focusing only on Android since it is the only OS that is very fragmented and with different devices that support it.

We are assuming that to carry out an attack on the TEE of an Android device it is necessary to rewrite the kernel or more specifically to unlock the bootloader in order to access the boot partition, install modified bootloaders or rather non-OEM kernels to be able to conduct an attack .

With this type of attack the problem does not arise as unlocking the bootloader (an essential operation for conducting any software attack) implies a complete wipe of the device causing the irreversible loss of all data stored inside including credentials and private keys . RAM not yet overwritten by Android specifications must also be restored during a fastboot flashing unlock. Having said that, rewriting the kernel and installing a custom ROM also falls into the previous case.
Android refs.

Suppose instead of having "privileged" access perhaps via serial (JTAG) directly to the internal memory partition, I could obtain root privileges that allow me to write a malicious app or have access to portions of memory that allow me to carry out a MITM type attack. This type of attack, although very complicated, is also directly mitigated by the guidelines for the certification of Android devices as all devices started with Android 10 and later versions must use file-based encryption.
Android refs.

However, everything is mitigated by the use of the play integrity check within the Wallet Solution in addition to the verification of the bootloader whether unlocked or not and the verification of the operating system signature which allows the Wallet Provider to understand whether the Wallet Solution instance with which it is communicating is genuine or not by verifying a series of cryptographic evidence. Furthermore, the addition of a key attestation of the device allows you to cryptographically demonstrate the security level of the device and whether the keys stored within the device are secure or not by checking a SecurityLevel.
Android refs.

I leave attached the screenshot of a verification app that allows you to obtain a series of information regarding the keys stored on the device. Both for a device that uses strongbox and for one with an unlocked bootloader but without root permissions.

CC: @pp-ps

[grausof]

As suggested also here by @asharif1990 in addition to the integrity check, we will add a key attestation for devices that support it and application-level controls on rooted devices, unlocked bootloaders and non-OEM software. These measures will allow us to reach a substantial level for now. I therefore move the milestone to 0.6.0 and then we will address the LoA high level in the next milestone (for which it is necessary to open a new issue)
​

[peppelinux]

I think that PR #233 only resolves this partially, and additional security consideration must then be included in the current specifications