[Magisk] pndwal:
Come on...

The industry in general has (very slowly) been setting up for strengthened device integrity attestations...

The Open Mobile Terminal Platform (OMTP) first defined TEE in their "Advanced Trusted Environment:OMTP TR1" standard around 2007, and for some 16 years Hardware implementations for a hardware isolation mechanism with a secure operating system running on top of this along with an associated "hardware root of trust" have been progressively adopted and implemented not just in/by mobile devices / ARM SOCs (TrustZone, first iterations in 2008, but not much further development/excited customers till 1012, and more), but also by Apple (Secure Enclave is a hardware feature found in most versions of iPhone, iPad, Mac, Apple TV, Apple Watch and HomePod), AMD (Platform Security Processor, PSP, 2013, and more), IBM (IBM Secure Service Container, 2017, and more), Intel (Trusted Execution Technology / Management Engine, 2008 and more), RISC-V SOCs (MultiZone™ Security Trusted Execution Environment, 2018, and more)...

The aim of tee on SOC is to to reduce the attack surface... Typical applications include DRM functionality for controlling the use of media (ie. media security) and preventing any unapproved use of a device (ie. device/data security)...

And it's not just banks who are interested in this; Service providers, mobile network operators (MNO), operating system developers, application developers, device manufacturers, platform providers and silicon vendors are the main stakeholders contributing to the standardization efforts around the TEE in SOC and implementation...

Banks are simply impatient as, at least in Android, secure TEE implementation for device security is un-developed, flawed, lagging, arguably broken even... unlike in iOS (iOS Secure Enclave) ... And that's a problem, not just for Google...

In reality, Google have arguably be way too S L O W and hardly aggressive enough! They've slowly improved Verified boot, AVB (V2+), TEE OS (incl. their own TrustyTEE), Droidguard VM, SafetyNet, etc... Eventually (in March 2020, after SafetyNet API had been a thing for 3, years already) and after several iterations of Keymaster for key based attestation, Google introduced the evaluationType labels (HARDWARE_BACKED, BASIC) in the SafetyNet API with Android 8 / Keymaster 3 launched devices...

At that point, John Wu said "Let's face it. Fun is over guys"!...

www.twitter.com/topjohnwu/status/1237656705850212352

Well we're still on top!... He imagined Google was going to 'fully deploy" and "properly implement" this thing and that further efforts to bypass enforcement were basically futile... A Tsunami had been unleashed!

However Google have not really changed anything much, even after introducing a new API which really only added Application integrity and Account details response fields to existing Device integrity and therefore got rebranded as Play Integrity...

Google's wave has been extremely slow in reality and we're still riding it... And John's now working for 'em (a 'Googler') too!

... So banks do their own security checks... Simply because Android Verified Boot doesn't work for them (even yet!)... I mean attestation to it in the usable DEVICE_INTEGRITY verdict can't be trusted... I mean it's hardly 'verified', is it?... It's 'chain of trust' can't be trusted because components can be spoofed so Verified Boot can't be trusted, and all because of TEE based attestation not being usefully implemented (ie. to allow detection of tampering a runtime environment along with either a hardware based attestation to the device model, keymaster version (always available in the key pairs) or to some other attestation to a working implementation of keymaster for enforcing hardware evaluation type properly, unlike the spoof-able prop based enforcement Google delivered)... And it's not useful presently because the simple implementations of both SafetyNet hardware-backed evaluationType and Play Integrity strongIntegrity enforcement will necessarily fail all devices using Android 7 and below as well many OnePlus and other devices with broken keystore/keymaster implementations if adopted (because attestation doesn't include the information in parentheses above which would allow banks to use Google's strong device integrity verdicts now without the collateral damage) making this option largely impractical...

I say 'Thanks Google for designing the thing this way!... You didn't need too, but we appreciate your putting the banks between a rock and a hard place!".

... Don't expect that banks won't adopt PI strongIntegrity verdict use sooner or later however... they're only waiting for a certain critical mass of compliant devices (which only they will determine)... or for a better solution (read: more useful hardware based attestation to a trusted, non-tampered runtime environment)... Or to wake up to the fact that it already exists. 😬

Moreover, the efforts banks are making in persuing their own detection of tampered runtime environments as an interim measure only highlights their own interest/ stake in TEE in SOC implementation of keystore/keymaster attestation for device security and standardization...

It's NOT Google pushing this thing... They may be forced to play catch-up however... 😬

And it's Google who've allowed us to bypass DEVICE_INTEGRITY enforcement on devices that really have no business doing so (it's designed to use hardware-backed key based attestation wherever it's available; only difference with STRONG_INTEGRITY is that basic-only attestation is prohibited for all devices) by their very implementation... Again, they didn't have to... At all... 😋

Google won't... They've no intention or interest... They've supplied the mechanism to placate banks and designed it with such penalties that they can't adopt it for now... It's been a white elephant for banks (for years) although Google won't admit it... They'll just continue to 'harden' this thing a bit for appearances sake and wait for banks to flip the switch themselves... Whenever the critical mass I mentioned above is reached...

I think it came from XiaomiEU Dev(s) first(?), @chiteroman noted it and applied it first to his USNF fork, then @Displax build both some PIF builds and his USNF 2.4.0 mod 2.0 with Pixel 2 spoofing to fake STRONG_INTEGRITY...

Google have never slept on this... Shawn Wilden said they would revoke keys or fix the API where vulnerabilities or exploits were discovered... They did it with ROG Phone 3 and many more, and the fake STRONG_INTEGRITY (which I've commented seems to be to cover over their own bad Keymaster or AVB trustchain implementation in early Pixel 2s) pass was no different, except for being very embarrassing when it was revealed how much they'd evidently slanted the playing field!... Of course they had to fix it... 😉

🤠 PW