[Magisk] pndwal:
Exactly... that's what vv/Rikka's key attestation POC is designed to demonstrate except that it does the validation of certificates within the Android framework, not on a server so can be bypassed (as your app demonstrates 👍)...

What seems strange to me is that few if any banks seem to have implemented this model (with server-based validation of course), but continue to mess about with custom means of detecting compromised runtime environments ('root' etc) when this method is documented in detail by Google, doesn't rely on Play Integrity/DroidGuard VM etc (who's strongIntegrity verdict would necessarily disqualify even B/L locked pre-keymaster 3 devices if implemented) and can simply gain strong attestation to the true boot-state of any device as well as being fool-proof... 🤪

Just not sure why you say 'in 2025' when banks could easily be doing this now (and I suspect we'll soon discover some that do)... 🤔

I don't know much about TPM, but seems all consumer electronics is in fact going down this path with PC/soc manufacturers adopting a similar model with TPM/UEFI...

Well, seems TPM device is required for Win11+ although secure boot can still be disabled, ie. machine must be TPM/UEFI compliant AFAIK...

I don't know what plans Microsoft have to enforce secure boot in future, but seems they may be getting prepared by requiring the hardware already...

Similarly, before Android 6.0, Android already had a simple, hardware-backed crypto services API, provided by versions 0.2 and 0.3 of the Keymaster Hardware Abstraction Layer (HAL)... In Android 7.0, Keymaster 2 added support for key attestation and version binding... In Android 8.0, Keymaster 3 transitioned from the old-style C-structure Hardware Abstraction Layer (HAL) to the C++ HAL interface generated from a definition in the new Hardware Interface Definition Language (HIDL).

The Keymaster 3 hardware implementation was finally determined to be 'strong' enough for strong attestation to 'device integrity', but It still took some time before Google implemented their evaluationType verdict in SafetyNet API so Devs/apps would have a Google provisioned mechanism to leverage such attestations. No one was in a hurry to do so, thankfully for us...

The point @swer45 made that "Microsoft are forcing users to implement a TPM device in all computers" to run Win11+ for example, seems correct to me, and further that "it will be the same history" in that sooner or later secure boot is bound to be enforced. 🙃

TPM means Secure Boot can be verified with 'strong' attestation; doesn't mean compatibility certification can't pass AFAIK...

Simply providing an accessible hardware backed chain of trust (beginning at bootloader level) is how Google have chosen to implement such attestation, but this is also available without S/N or PI APIs and independent from DroidGuard VM engine too...

I don't know if Microsoft will likewise continue allow verified Secure Boot to be bypassed to boot systems but provide Google-style attestations to apps going forward, or if they will simply prohibit use of machines without verified boot like IOS, but that's not the point... Point is that Windows now requires a TPM device AFAICS...

But again, that's just Google's API implementation, patently favouring us modders by weaving severe disadvantages for banks into the strongIntegrity / HARDWARE_BACKED evaluationType provisioning. 😜...

And banks can already simply validate certificates for chain of trust independantly of Google APIs to decode Secure Boot status (as mentioned above and by @swer45) on a per-device basis if they want to (read: they have the means for strong attestation to unlocked bootloader or custom key use already, and with none of the disadvantages of the Google APIs!)...

Frankly, what puzzles me is why they appear to be so slow to do this... 🙃 😬 PW