[DISCUSSION] Play Integrity API

Search This thread

V0latyle

Forum Moderator
Staff member
X2

Well Hardware evaluationTypes are used if available by default even if just calling Device_Integrity. That's why @kdragon uses both fake keystone (causes exception which triggers fall back to basic attestation) and altered Model prop (mismatch this causes allows enforcement of a Hardware based verdict to be bypassed, is the forced basic attestation becomes acceptable)...

The statement "JSON ... details was the CTS Profile checked on TEE or not (= STRONG integrity for the be PI API)" is misleading; actually CTS Profile checked in TEE (ie. we see HARDWARE) = is used here to attest to DEVICE_INTEGRITY if it's available by default (ie. on A8+ devices); a CTS Profile match=true result using BASIC evaluation is still enough for this (or pre A8 devices couldn't give MEETS_DEVICE_INTEGRITY), but it would not be accepted if a STRONG_INTEGRITY verdict were called.

Don't confuse evaluationType with the choice of verdict type; Devs can choose any of three levels for verdict but cannot choose evaluationType used; Hardware will be used if it's available for that type unless userspace tricks are used to spoof device and cause fallbacks...

It's an API, (Application Programming Interface) requiring server-end support by Google; I gave you the dates / link a couple of times now for 'Migration deadline' & 'Full turndown' of S/N API at which point there will be no choice but to use PI API...

Sorry, are you referring to Play Integrity response labels?... These are all part of Play Integrity, of course!?

Main signals (responses) are defined as:

- Application integrity
- Account details
- Device integrity

For Device integrity, device_recognition_verdict is called.

By default, this can have one of the following labels:

MEETS_DEVICE_INTEGRITY
or
No labels (a blank value)

If you opt in to receive additional labels in the integrity verdict, device_recognition_verdict can have the following additional labels:

MEETS_BASIC_INTEGRITY
or
MEETS_STRONG_INTEGRITY
and for emulators only
MEETS_VIRTUAL_INTEGRITY

These 'fields' are all called via the Device Integrity API.

https://developer.android.com/google/play/integrity/verdict

😛 PW

PS. Just did this on 140 min flight from Broken Hill to Sydney... Just landed...
Sorry if I was confusing.

I'm still not quite clear on this...

What's the difference between evaluation type and verdict type?

You said developers can't choose the former but they can choose the latter; is this referring to the MEETS_x_INTEGRITY responses?
Are applications able to see these responses themselves, or does the API present some sort of "layer" between the application and the verdicts?
 

pndwal

Senior Member
Sorry if I was confusing.

I'm still not quite clear on this...

What's the difference between evaluation type and verdict type?

You said developers can't choose the former but they can choose the latter; is this referring to the MEETS_x_INTEGRITY responses?
Yup; the 3 (4 incl. emulators) MEETS_x_INTEGRITY response verdicts + blank for device_recognition_verdict call can be chosen; Client app will see either
MEETS_DEVICE_INTEGRITY
or
No labels (a blank value)
by default... All others are optional and require Play Store distribution of app...

EvaluationType is the old S/N field ideally set by the presence of hardware keystore for HKA, but currently capable devices can spoof incapable ones; That's the function of Universal SafetyNet Fix, and the same fallbacks / bypasses work for both S/N and PI APIs.

The only possible S/N API evaluationType responses are
BASIC
or
HARDWARE_BACKED

A (near) equivalent for evaluationType in new PI API is obtained by combining deviceRecognitionVerdict field verdicts, ie.
MEETS_xxx_INTEGRITY combinations...

https://developer.android.com/google/play/integrity/migrate

Are applications able to see these responses themselves, or does the API present some sort of "layer" between the application and the verdicts?
Please see Play Integrity API summary of workings and flowchart details interaction with / reliance on Google Play server as with app server here:
https://developer.android.com/google/play/integrity

🤪 PW
 
Last edited:

mrjuniork

Forum Moderator
Staff member
Aug 29, 2015
1,652
3,623
Vienna
OnePlus 6
@V0latyle
Mate, thx for the workload, really appreciate it 😁

@ipdev
Thx for pinging me, not a problem at all. And yes, it will be me taking care of this 😉
And thx as well for linking one of the initial discussion openers 👍

So hold your horses, I'm gonna get this done sometime today (which refers to Europe).
RL does hold me tight lately.

Cheers,
mrjuniork
 

zgfg

Senior Member
Oct 10, 2016
7,963
5,514
Thanks. I will then mark my posts to be moved here. But now on the road trip, hence when I find time
 

Oswald Boelcke

Senior Moderator / Moderator Committee
Staff member
I am not sure about the Google Pay Magisk Discussion Thread but, posts (including mine) related to Play Integrity in the Universal SafetyNet Fix 2.3.1 thread seem to start around Post # 1,796.

All the posts about Play Integrity (that are not related to the USNF module) would have to be moved and kept in order to this thread.
I am not sure how easy that would be to do, since a lot of the discussion included linked posts in the responses.

Maybe @mrjuniork has an idea of the best and easiest way to do it?

Cheers. :cowboy:

PS.
Sorry to ping you mrjuniork.
I might be wrong but, it looks like you will be the one who gets stuck moving the posts.
🙃
Please see above post by @shadowstep who moved quite a lot of posts to this thread minutes ago.
 
  • Like
Reactions: ipdev

vMAC

Senior Member
Oct 21, 2007
343
34
Yup; the 3 (4 incl. emulators) MEETS_x_INTEGRITY response verdicts + blank for device_recognition_verdict call can be chosen; Client app will see either
MEETS_DEVICE_INTEGRITY
or
No labels (a blank value)
by default... All others are optional and require Play Store distribution of app...

EvaluationType is the old S/N field ideally set by the presence of hardware keystore for HKA, but currently capable devices can spoof incapable ones; That's the function of Universal SafetyNet Fix, and the same fallbacks / bypasses work for both S/N and PI APIs.

The only possible S/N API evaluationType responses are
BASIC
or
HARDWARE_BACKED

A (near) equivalent for evaluationType in new PI API is obtained by combining deviceRecognitionVerdict field verdicts, ie.
MEETS_xxx_INTEGRITY combinations...

https://developer.android.com/google/play/integrity/migrate


Please see Play Integrity API summary of workings and flowchart details interaction with / reliance on Google Play server as with app server here:
https://developer.android.com/google/play/integrity

🤪 PW
Pardon my ignorance, but why can apps like XPrivacyLua not spoof a TEE status of hardware-backed just as it spoofs a hardware based IMEI or S/N?
 

zgfg

Senior Member
Oct 10, 2016
7,963
5,514
Pardon my ignorance, but why can apps like XPrivacyLua not spoof a TEE status of hardware-backed just as it spoofs a hardware based IMEI or S/N?
You are quoting the post with links to the Play Integrity documentation.
Please read and study the original doc, and you will understand the answer to your question

Sorry but if it would not be clear from the document itself, I doubt it would be clear from somebody's rewriting/reinterpretating the Google's doc

TEE has to do the 'calculation' (verification of CTS Profile, that includes if Bootloader is unlocked, etc) and sign its result by its private key.
That result goes to Google server and Google server verifies both the result and was it really signed by TEE

If you know how signing and authenticating works, you will understand that man-in-the-middle attack (somebody else submits the result instead of TEE or changes the content of TEE's signed result) is practically impossible (modern cryptography)

On the other side, Google eg offers up to 1.5 M $ if anyone breaks the TEE module itself on the new Titan processor

It's not a simple thing as spoofing a number like IMEI. You (Lua, whatever) don't ask TEE to read IMEI number, to sign its result (the number plus its signature) and you don't submit that result to an external server (out of your control) for verification

Now reading my answer above, I see (as stated at the beginning) that reading and studying the official documentation is by far more valuable than my attempt trying to explain the things
 
Last edited:
  • Like
Reactions: rodken and V0latyle

pndwal

Senior Member
Pardon my ignorance, but why can apps like XPrivacyLua not spoof a TEE status of hardware-backed just as it spoofs a hardware based IMEI or S/N?
This from the horse's mouth:

(Those who've kept up with comments from John Wu won't need to bother opening this unless, like mine, they possess a photographic memory that needs developing... And for those who haven't kept up, be aware that the information contained herein may require some assimilation...)


😬 PW
 
Last edited:
  • Like
Reactions: V0latyle

pndwal

Senior Member

Tech = Spy-Biz, HippoMan

FWIW, I'm answering this here (might be the best place...):
Its none of the banks business to stop their clients from using rooted devices. Theyre just adding another hindrance to smooth banking operations thereby possibly hampering their own business by wasting both their and their clients time. Thats Stupidity!
Well, seems that's a popular option here, but it's also a highly subjective one...
Bank Devs did you hear? Pls discuss this with your bosses. Its like going backwards instead of forward.
And you're going to need to do better than that... Even if banks themselves didn't persue these initiatives (ostensibly to protect their interests / bottom line) they're being driven by many other powerful entities...

The Open Mobile Terminal Platform (OMTP) first defined TEE in their "Advanced Trusted Environment:OMTP TR1" standard around 2007, and for some 15 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 customer 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...

So banks do their own security checks... Simply because Android Verified Boot doesn't work for them... I mean attestation to it in the usable deviceIntegrity 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 not being usefully implemented (ie. to allow detection of tampering with a runtime environment along with either a hardware based attestation to the device model or to a working implementation of keymaster for enforcing hardware evaluation type)... And it's not useful presently because the simple implementations of both SafetyNet evaluationType and Play Integrity strongIntegrity will necessarily fail all devices using Android 7 and below as well many OnePlus and other devices with broken keystore implementations if adopted (because attestation doesn't include the information in parentheses above) making this option largely impractical...

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)...

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...

I totally agree!

And as I've mentioned here before, every desktop computer is a rooted device, and of course we don't see the banks trying to hinder us from accessing their services from our computers.

And banks gladly issue us debit cards which we keep in our wallets that are just as easy to steal as mobile devices.

Rooted Android devices are just low-hanging fruit. And the amount of fraud that's prevented by trying to fight against Android root is minuscule, given the extremely small percentage of mobile device users who want to use rooted Android devices. I wouldn't be surprised if the amount of money that banks spend for anti-Android-modding software development exceeds the maximum amount of money that could be lost via the hacking of modded Android devices.
But as I've told you before, and as the above should make abundantly clear, TEE and other, especially hardware backed, means to detect tampered execution environments for an application developer's code are here to stay in mobile devices, and are arriving in PCs also... cos like banks, Google and iOS etc, Microsoft is doing the maths also...
In 2021, protections built into Windows, Azure, Microsoft 365, and Microsoft Defender for Office 365 have blocked more than 9.6 billion malware threats, more than 35.7 billion phishing and other malicious emails, and 25.6 billion attempts to hijack our enterprise customers by brute-forcing stolen passwords—that’s more than 800 password attacks per second...
https://www.microsoft.com/security/...for-windows-11-will-help-protect-hybrid-work/

Hardware and software makers hope TEEs provide a long-term solution for using sensitive data in a more secure manner on smartphones, PCs, cloud systems, and virtualized workloads...
https://www.hpe.com/us/en/insights/...with-trusted-execution-environments-2102.html

And Microsoft are already spruiking Windows 11 as a "Zero Trust" solution for PC advanced security needs...

Guards against sophisticated attacks​

Protects down to the firmware level with hardware security features that shield user credentials and other critical data.

Secured-core PCs and hardware-based security​

Secured-core PCs deliver the highest level of Windows 11 protection including advanced protection of firmware and dynamic root of trust measurement.

Windows 11 security innovations​

Microsoft optimizes Windows 11 for Zero Trust protection. Read the Windows 11 Security Guide for a quick overview.
https://www.microsoft.com/en-us/windows/business/windows-11-secured-core-computers

Anyway, as I see it, we are able to have a bit of fun beating the system, or really subverting mobile OS's security models only because these have been slow to implement proper / useful "zero trust" protections... The fun's sure to end sooner or later however cos we live in the real world!... And being real, you and I both know 'bank devs' will NEVER convince their bosses to abandon these advances either! (...ok, ok... advancement, regression, it's your call... or is it?... Who do we think we are???)...

Eh guys?

... The only way you'll get your wish is by cobbling together enough funds to buy the banks, Google, the SOC makers and the OEMs you love ... Then you'll have a fighting chance. 🙂...

Wish you luck... PW
 
Last edited:

HippoMan

Senior Member
May 5, 2009
1,947
782
Hippoland
[ ... etc. ... ]

https://www.microsoft.com/e only way you'll get your wish is by cobbling together enough funds to buy the banks, Google, the SOC makers and the OEMs you love ... Then you'll have a fighting chance. 🙂...

Wish you luck... PW

I can't speak for anyone else, but for me, my editorializing about what I perceive as banks' stupidity doesn't mean that I have any expectation about these banks changing their policies. In other venues, I also editorialize about other things (for example, certain societal trends) which also have little, if any chance of changing.

Anyway, it's of course important for security purposes to reduce the attack surface, but rooted/modded Android devices make up much less than one percent of the attack surface area that banks need to pay attention to. And even with the use of the security tools that Android offers, I still believe that the banks pay proportionally more for their anti-Android-modding software development (which in many cases goes beyond the mere use of Android's Safety Net and Play Integrity facilities) than the losses they would incur without having developed this additional software.

But like I said, I have no expectation of any banks making any changes to these policies.

There's no law against being stupid.
 

HippoMan

Senior Member
May 5, 2009
1,947
782
Hippoland
But like I said, I have no expectation of any banks making any changes to these policies.

I now will editorialize about a proposed solution to this issue which also has very little, if any chance of actually occuring in the real world ...

I propose what I will call a "double device": i.e., two complete Android devices inside of one case. They would be designed to use the same screen, buttons, and sensors as each other, with the choice of which device has access to the screen, buttons, sensors, etc. at any given time being controlled completely by hardware and determined by the setting of a hardware switch that the user could utilize.

They also could be made to share some storage.

One device could be loaded up with a pristine, non-rooted, non-modded, Google-approved OS, while the other one could be loaded up with whatever modded OS is desired.

The banking and other mod-proofed apps would be utilitized on the pristine device.

Of course, this device would be costly, and two SIM cards would probably be necessary, although perhaps there could be some sort of hardware-based solution for sharing a SIM ... but any such SIM sharing is not a necessary feature for my proposed device.

Anyway, I would definitely be willing to pay the cost of such a device, and at least a few other people might also be happy to buy such a thing.

But I know that it will be a cold day in hell before any such device actually appears in the real world.

However, I can dream ...
 
Last edited:

V0latyle

Forum Moderator
Staff member
I can't speak for anyone else, but for me, my editorializing about what I perceive as banks' stupidity doesn't mean that I have any expectation about these banks changing their policies. In other venues, I also editorialize about other things (for example, certain societal trends) which also have little, if any chance of changing.

Anyway, it's of course important for security purposes to reduce the attack surface, but rooted/modded Android devices make up much less than one percent of the attack surface area that banks need to pay attention to. And even with the use of the security tools that Android offers, I still believe that the banks pay proportionally more for their anti-Android-modding software development (which in many cases goes beyond the mere use of Android's Safety Net and Play Integrity facilities) than the losses they would incur without having developed this additional software.

But like I said, I have no expectation of any banks making any changes to these policies.

There's no law against being stupid.
I think you're making some pretty broad assumptions here. From a developer perspective, there's really no way to tell the difference between a device that has been intentionally compromised, such as devices rooted by users, and a device that is unintentionally compromised. So, they just check to see whether the device has been compromised at all. That's where APIs such as Play Integrity come in - they provide a way for the developer to ensure that the device security is intact. It's not out of any animosity towards developers, power users, or modders...they're trying to develop a software product suitable for the general public, while protecting the secure assets of said general public (as long as the assets in question is money, not privacy). You used the example of "every PC is a rooted device". Yes, but how many banks are developing Windows platform applications for consumer use? Few, if not none.

As @pndwal pointed out, you can rail against this as much as you want, but it's not going to change anything.

Further, this thread is specifically intended for discussion on the mechanism that is Play Integrity, not ideological rants, so please stay on topic.
 

HippoMan

Senior Member
May 5, 2009
1,947
782
Hippoland
I think you're making some pretty broad assumptions here. From a developer perspective, there's really no way to tell the difference between a device that has been intentionally compromised, such as devices rooted by users, and a device that is unintentionally compromised. So, they just check to see whether the device has been compromised at all. That's where APIs such as Play Integrity come in - they provide a way for the developer to ensure that the device security is intact. It's not out of any animosity towards developers, power users, or modders...they're trying to develop a software product suitable for the general public, while protecting the secure assets of said general public (as long as the assets in question is money, not privacy). You used the example of "every PC is a rooted device". Yes, but how many banks are developing Windows platform applications for consumer use? Few, if not none.

As @pndwal pointed out, you can rail against this as much as you want, but it's not going to change anything.

Further, this thread is specifically intended for discussion on the mechanism that is Play Integrity, not ideological rants, so please stay on topic.
Yes. Play Integrity (and SafetyNet in the past) are used for the purpose of identifying compromised devices, and the use of these Google-supplied features doesn't cost the banks very much, relatively speaking.

I'm talking about all the other efforts that many banks make which go beyond Play Integrity and Safety Net. Not all banks go this far, but those who do are spending (OK, I'm willing to say "wasting") programmer-hours and money going after a minuscule attack surface.

And I'm not the one who moved my comments about this topic into this thread. I'll now stop ranting about non-Play-Integrity issues here.
 

Tech = Spy-Biz

Account currently disabled
May 25, 2022
32
20
I now will editorialize about a proposed solution to this issue which also has very little, if any chance of actually occuring in the real world ...

I propose what I will call a "double device": i.e., two complete Android devices inside of one case. They would be designed to use the same screen, buttons, and sensors as each other, with the choice of which device has access to the screen, buttons, sensors, etc. at any given time being controlled completely by hardware and determined by the setting of a hardware switch that the user could utilize.

They also could be made to share some storage.

One device could be loaded up with a pristine, non-rooted, non-modded, Google-approved OS, while the other one could be loaded up with whatever modded OS is desired.

The banking and other mod-proofed apps would be utilitized on the pristine device.

Of course, this device would be costly, and two SIM cards would probably be necessary, although perhaps there could be some sort of hardware-based solution for sharing a SIM ... but any such SIM sharing is not a necessary feature for my proposed device.

Anyway, I would definitely be willing to pay the cost of such a device, and at least a few other people might also be happy to buy such a thing.

But I know that it will be a cold day in hell before any such device actually appears in the real world.

However, I can dream ...
There are so many ways they can secure any transaction, it was never about security, thats a hoax, whos gonna hack the daddy of all hacks ;)? Google just wants to push other agendas through apps that are important for android users and what better than banking apps? coz people want tosecure their transactions, security is the alibi google uses. It's not windows that anyone can hack, android based on super strong Linux, no way google feeling so threatened about security. It's for the Billion dollar Ad Revenues and Big Data Analytics forselling to Government Agencies, thats all, Homeland Security too.
 

V0latyle

Forum Moderator
Staff member
There are so many ways they can secure any transaction, it was never about security, thats a hoax, whos gonna hack the daddy of all hacks ;)? Google just wants to push other agendas through apps that are important for android users and what better than banking apps? coz people want tosecure their transactions, security is the alibi google uses. It's not windows that anyone can hack, android based on super strong Linux, no way google feeling so threatened about security. It's for the Billion dollar Ad Revenues and Big Data Analytics forselling to Government Agencies, thats all, Homeland Security too.
Again...this isn't the place to rant. The point of this thread is to discuss the Play Integrity API.
 
  • Like
Reactions: ipdev and mrjuniork

HippoMan

Senior Member
May 5, 2009
1,947
782
Hippoland
Again...this isn't the place to rant. The point of this thread is to discuss the Play Integrity API.
Feel free to carry on with our editorializing in the following thread:
https://forum.xda-developers.com/t/...ng-and-mod-hiding-cat-and-mouse-game.4425939/

... and more specifically:
https://forum.xda-developers.com/t/...ding-cat-and-mouse-game.4425939/post-87403123

... and also this:
https://forum.xda-developers.com/t/...ding-cat-and-mouse-game.4425939/post-87403193

I created that thread for the purpose of discussing issues such as these.
 
Last edited:

V0latyle

Forum Moderator
Staff member
Feel free to carry on with our editorializing in the following thread:
https://forum.xda-developers.com/t/...ng-and-mod-hiding-cat-and-mouse-game.4425939/

... and more specifically:
https://forum.xda-developers.com/t/...ding-cat-and-mouse-game.4425939/post-87403123

... and also this:
https://forum.xda-developers.com/t/...ding-cat-and-mouse-game.4425939/post-87403193

I created that thread for the purpose of discussing issues such as these.
Don't get me wrong, I share a lot of your frustrations...while I don't necessarily agree with a lot of your assumptions, this will eventually mean that rooters/modders like us will no longer be able to use secure applications that depend on Play Integrity, once support for legacy SafetyNet is removed. Pretty much the only thing on our side is the high degree of fragmentation in Android - there are still millions of devices out there running older builds of Android that do not support Play Integrity due to HKA and other mechanisms, but once developers decide to remove support for older platforms, that will be the end, because we cannot and will likely never be able to spoof STRONG_INTEGRITY.
 
  • Like
Reactions: rodken

Top Liked Posts

  • There are no posts matching your filters.
  • 3
    @pndwal
    Time for some tests.
    Starting with stock A12 with unlocked bootloader

    View attachment 5753341View attachment 5753343

    It seems ROG 3 TEE is more busted than I thought! No hiding mechanisms active yet still showing bootloader locked🤔


    Next, Rooted with Magisk, Zygisk only active + gms processes removed from denylist...


    View attachment 5753345View attachment 5753347
    Oh dear 😱 API checker is NOT happy!


    Now we'll do Zygisk and Shamiko active + gms processes in denylist...

    View attachment 5753349View attachment 5753351
    Ok, so not detecting root, Shamiko is doing its thing with the props but Latest A12 firmware for ROG 3 isn't certified. Well soon fix that...
    Nb. This covers tests 1and 2


    And lastly....

    View attachment 5753361View attachment 5753365View attachment 5753369
    Revert to an older certified fingerprint, and all good👍
    Since your Key Attestation constantly shows that BL is locked (btw, it doesn't utilize SN/PI API for its check), it means that your ROG 3 does 'not know' that Bootloader was unlocked

    Ie, the method Key Attestation uses to check if BL is unlocked, somehow returns locked BL (in all conditions), although the BL is unlocked

    Hence, I would conclude that TEE is 'not broken' on your phone but it probably also reads that BL is 'locked' like the Key Attestation does

    And that's the reason that you can pass Strong Integrity
    2
    @pndwal
    Time for some tests.
    Starting with stock A12 with unlocked bootloader

    Screenshot_20221106-115607790.jpgScreenshot_20221106-115703.jpg

    It seems ROG 3 TEE is more busted than I thought! No hiding mechanisms active yet still showing bootloader locked🤔


    Next, Rooted with Magisk, Zygisk only active + gms processes removed from denylist...


    Screenshot_20221106-122136567.jpgScreenshot_20221106-122052.jpg
    Oh dear 😱 API checker is NOT happy!


    Now we'll do Zygisk and Shamiko active + gms processes in denylist...

    Screenshot_20221106-123257333.jpgScreenshot_20221106-123632.jpg
    Ok, so not detecting root, Shamiko is doing its thing with the props but Latest A12 firmware for ROG 3 isn't certified. Well soon fix that...
    Nb. This covers tests 1and 2


    And lastly....

    Screenshot_20221106-124048.jpgScreenshot_20221106-124442751.jpgScreenshot_20221106-124506.jpg
    Revert to an older certified fingerprint, and all good👍
    2
    @shoey63 and/or anyone else familiar with the Asus ROG situation, can you explain how the keystore is broken and how this allows Play Integrity to return STRONG verdict?
    You may have missed the exchange here, but I recently analysed & made (educated) guesses w/ @shoey63's help. See here:
    https://forum.xda-developers.com/t/discussion-play-integrity-api.4479337/post-87684705
    and here:
    https://forum.xda-developers.com/t/discussion-play-integrity-api.4479337/post-87684959

    Basically It seems droidguard is erroneously sending basic attestation data flagged as hardware backed and this is the basic breakage in keymaster implementation...

    Further, gms is not smart enough to challenge this (it would be very unusual after all) but the PI API has the smarts to recognise that some included data is not hardware backed and thus requires (the initial fingerprint) mismatched prop trigger for PI hardware enforcement bypass before accepting the attestation data...

    👀 PW
    2
    Hi. I have a riddle that I can't solve. I have two devices: Pixel 6 Pro (raven) and Pixel 7 Pro (cheetah). Both with unlocked bootloader. On Pixel 6 Pro I installed the RiceDroid rom.


    It is very functional, does not really require root to give satisfaction from daily use. It runs banking applications, gpay (wallet) and has the accepted status of MEETS_DEVICE_INTEGRITY and MEETS_BASIC_INTEGRITY.

    Pixel 7 Pro, on the other hand, is quite a challenge. I installed Paranoid Android Topaz beta 1 on it

    Seems Ricedroid is based on lineage/crdroid... You'll see here that crdroid pulls SafetyNet Fix w/ Displax mod from here:
    https://github.com/kdrag0n/safetynet-fix/pull/207
    (Latest is this commit: c5ed4b1)

    I don't see Paranoid Android on that page although that doesn't mean that they don't integrate a fix...

    Personally I prefer to use clean ROMs (eg official LOS) that don't integrate spoofing and add these using Magisk as there are less issues with conflicting Magisk modules and when changes (eg Google server end) are made...
    Due to limited usability, I rooted and installed Displax mod 2.0 USNF. I couldn't get MEETS_DEVICE_INTEGRITY despite combos with other Magisk modules (Shamiko, Husky, old USNF etc.)
    Nb. Displax mod 2.0 USNF is enough for this; USNF settings will often interfere with that fix and your other solutions may be confusing you/the issue...

    It is possible there is also an underlying custom ROM issue (as mentioned above or other) that prevents success...
    So I went back to absolute stock via the online android flash tool. Strangely, on absolute stock, without root, Pixel 7 Pro still shows only MEETS_BASIC_INTEGRITY and no wallet or Netflix or anything "requiring" internal payments accually works. This is a really incomprehensible situation for me considering how the predecessor (Pixel 6 Pro) behaves. I kindly ask for advice and tips.
    Device is not 'absolute stock' if bootloader is unlocked... AVB is reporting that so you don't have deviceIntegrity! - you need the @Displax modded USNF to spoof this by forcing the fallback (based on an exception error mod causes) to basic attestation as well as several prop mismatches needed to bypass hardware evaluation type enforcement... With old Basic attestation (as used in pre A8 devices) you can spoof deviceIntegrity as AVB signals are not backed by HKA.

    I recommend that you check this thread, especially the first 8 posts:
    https://forum.xda-developers.com/t/unlock-bootloader-root-pixel-7-pro-cheetah-safetynet.4502805/
    as there are really not issues getting deviceIntegrity on stock ROM. 😃
    Welcome... 🙂 PW
    1
    Okay. So, it sounds like the mechanism used for verifying STRONG integrity also verifies BASIC and DEVICE integrity....in a sense
    If you mean signals collected, this is all done by droidguard, yes...
    - with any system modifications (custom software), root, and unlocked bootloader, the device will fail STRONG integrity and cannot guarantee the authenticity of BASIC and DEVICE integrity.
    Yup... Root etc may be hidden from attestation/droidguard process to pass basic integrity and CTS Profile, model and other props may be spoofed to pass deviceIntegrity... Of course if strongIntegrity is passing it would generally indicate that neither Basic attestation fallback nor HK enforcement bypass triggers have been used because HK attestation to bootloader etc would necessarily fail strongIntegrity...

    ... Except in the case of Asus ROG 3, in which it now seems there are at least 2 bugs in keymaster implementation; 1) It's using Basic attestation out of the box (ie. fake keystore registration to trigger exception --> Basic attestation fallback is not needed), 2) fingerprint prop mismatch based HK enforcement bypass erroneously allows strongIntegrity to pass...
    STRONG integrity is only available in a pristine environment - locked bootloader, OEM firmware, OEM root of trust, which ostensibly means that the device will also pass BASIC and DEVICE integrity.
    Yup...
    We've established that, assuming the same definitions as SafetyNet:
    MEETS_BASIC_INTEGRITY: The device running your app likely hasn't been tampered with (root and/or system modifications not detected).
    MEETS_DEVICE_INTEGRITY: The profile of the device running your app matches the profile of a device that has passed Android compatibility testing through CTS. Play Integrity does not allow the use of this label by itself.
    Well it must be used by itself for those apps not choosing to register with Google Play... I wrote this in last post!...
    MEETS_STRONG_INTEGRITY: The device is able to guarantee by means of hardware authentication, image verification, and other means that the Android security environment is sterile and uncompromised

    So:
    • A modified device CAN potentially pass BASIC and DEVICE integrity, because we can force the BASIC evaluationType.
    • A device that passes STRONG integrity will always pass BASIC and DEVICE integrity
    AFAICS, yup, yup and yup...
    @pndwal I think you had mentioned some devices with broken keystores that were still able to pass STRONG integrity on an unlocked bootloader? Do you have more information on these - i.e., firmware was completely stock, no root? Or was STRONG integrity still available even without BASIC or DEVICE?
    All I know was from @shoey63, and I think member addressed all this... 👍 PW
  • 7
    Some Insight on the New Cat and Mouse Game...

    Since many are asking:
    Is there a fix for this? ... Can't pass MEETS_STRONG_INTEGRITY.
    I'm posting this WOT. 🤪

    I predict some will like it, some won't... You've been warned! 😜

    FWIW, Play Integrity MEETS_STRONG_INTEGRITY is akin to SafetyNet Evaluation type HARDWARE with CTS Profile match...

    Banks could have used this before (w/ S/N API) but haven't as it would have excluded too many users/devices/customers... Nothing has actually changed with new PI API; MEETS_STRONG_INTEGRITY will exclude the same group, so it's doubtful they'll rush to require this verdict...

    Basically, the means to enforce Hardware key-backed Attestation has already been here w/ either of these attestations, but banks don't want to exclude all those w/Android 7 and below, or many w/ broken keymaster 3+ implementations in Android 8+ devices (CTS Profile match with HARDWARE Evaluation type / MEETS_STRONG_INTEGRITY won't pass with locked bootloader), eg most OnePlus devices (nb. Keymaster may have been fixed in OnePlus devices launched with Android 12+)...

    I'm guessing the banks may well leverage this at some point if the time arrives when they feel there is a sufficient critical mass of devices w/ working hardware-backed keymaster (ie w/ hardware keystore, A8+) to trade against the number of modded (bootloader unlocked) devices in use especially if they deem Google slow to close the fallback-to-basic-attestation loophole that has allowed modders to bypass hardware based attestation to CTS Profile match enforcement (by triggering fallback to BASIC Evaluation type as well as bypassing enforcement) and also to allow its counterpart, MEETS_DEVICE_INTEGRITY verdict. (Nb. This verdict should not properly be obtained on modded devices, and it requires the same attestations as S/N as well as the same tricks to trigger fallback to BASIC attestation and bypass enforcement) The incentive to use this foolproof means is also certainly being weighed constantly against the cost / need to use their own custom means of sophisticated 'root' detection...

    Google also, as other authorities have commented, appears to be waiting for some 'acceptable' percentile / critical mass of such devices in use to be reached also, before they swing the 'big hammer' that is Hardware-backed Key Attestation enforcement and that will definitely spell the endgame for modders' use of bank apps, and possibly for OnePlus users and others whose devices have broken keymaster*

    *Nb. There are exceptions, eg Asus ROG Phone 3, where broken keymaster actually results in PI MEETS_STRONG_INTEGRITY and S/N CTS Profile match with Evaluation type HARDWARE regardless of bootloader status instead of the converse...

    It seems likely to me that OnePlus and other devices with broken keymaster can be spared if Google do prevent on-device triggering of fallbacks to basic attestation use simply by using device info contained in the cryptographic attestation sent to Google servers instead of userspace model props etc now used, to bypass enforcement at the server end. If they do this it would be a concession as modded OnePlus etc may then still be able to pass CTS Profile match / DEVICE_INTEGRITY while other modern modded devices won't...

    This would, however, be a way to swing the hammer a bit sooner, and either way, as can be seen from the above, they may be forced to do this once banks do indicate a willingness to enforce
    MEETS_STRONG_INTEGRITY in order to stop a landslide that would prevent all stock locked Android 7 and lower devices using bank apps etc... Or maybe they'll just let the landslide go and force bank app users to upgrade devices...

    Hopefully this gives some insight regarding what pressures may finally force Google to properly deploy (ie. strictly enforce) Hardware-based Key Attestation on devices that support it...

    Personally, I think Google has exercised great restraint, possibly out of some regard for the modding community since I can't see any other compelling reason not to have properly enforced CTS Profile match with HARDWARE Evaluation type where supported or Hardware attested MEETS_DEVICE_INTEGRITY sooner, unless the matter of ensuring that the API properly sees hardware identifiers (ie. these cannot be spoofed, which I believe would again require cryptographic server-side attestation that the device doesn't indicate the presence of hardware keystore) for bypassing hardware attestation enforcement in devices launched with Android 7 and earlier is proving difficult (but I'm fairly sure this mechanism will be a simple matter for Google and probably already in place)... 😛

    It may well be that Google is benevolently holding off but is using/will use MEETS_STRONG_INTEGRITY uptake data as tha natural indicator of the banks propensity for reliable HKA... My bet is that if Google doesn't have immediate plans to move to srtict HKA enforcement for MEETS_DEVICE_INTEGRITY, then they will when the banks themselves move to use the even stricter MEETS_STRONG_INTEGRITY verdict...


    👀 🤠
    5
    Play Integrity API

    What is Play Integrity?
    Play Integrity has replaced SafetyNet for the most part, with a deadline of June 2024, when Google's SafetyNet servers will go offline. Apps that continue to exclusively depend on SafetyNet will no longer work once this happens. Most developers have already migrated to Play Integrity.

    Is Play Integrity the same as Play Protect?
    No. Play Integrity provides users with the ability to verify device compatibility and security, much like SafetyNet did. Play Protect is a part of the Play Store that ensures that your device is certified, and helps to protect against malware. In this context, "certified" refers to whether or not your device has passed Android compatibility testing. This is also used for part of the Play Integrity checks. More information here

    My device passes SafetyNet but I can't use Google Pay/other apps.
    Don't rely on SafetyNet as a good assessment of your device's compatibility and security. It is possible to pass SafetyNet, but fail Play Integrity.

    Rooted Pixel 5 on stock firmware: USNF 2.3.1 shows SafetyNet Pass using YASNAC, but device fails Play Integrity DEVICE_INTEGRITY check.

    How do I know if my device is passing Play Integrity checks?
    To check Play Integrity status, you can use this app:
    Github

    If you're a nerd and you want to check key attestation, use this:
    Github

    What do I do if my device is failing all 3 checks?
    You can use the Universal SafetyNet Fix Magisk module modded by @Displax to pass BASIC and DEVICE integrity. This should be sufficient for most apps including Google Pay. No other modules/modifications should be necessary. It is not possible to pass STRONG integrity on a modified device...unless it's"broken", like an ASUS ROG.



    Now, details on what Play Integrity is and how it works...


    SafetyNet has been discontinued in favor of the new Play Integrity, which uses stronger methods to verify the security of a device. This is why many users have been unable to use security sensitive apps, such as banking and DRM. There is a workaround for this, for now.

    But first, details on the new API.
    The three elements in Play Integrity are:
    • MEETS_DEVICE_INTEGRITY: Corresponds to SafetyNet ctsProfileMatch. The app is running on an Android device powered by Google Play services. The device passes system integrity checks and meets Android compatibility requirements. (Device profile matches that of a device that has passed Compatibility Test Suite) A device that fails this will appear as Uncertified in Play Store.
    • MEETS_BASIC_INTEGRITY: Corresponds to SafetyNet basicIntegrity. The app is running on a device that passes basic system integrity checks. The device may not meet Android compatibility requirements and may not be approved to run Google Play services. For example, the device may be running an unrecognized version of Android, may have an unlocked bootloader, or may not have been certified by the manufacturer. Most devices should pass this, even if they're rooted.
    • MEETS_STRONG_INTEGRITY: Corresponds to SafetyNet HARDWARE_BACKED attestation. The app is running on an Android device powered by Google Play services and has a strong guarantee of system integrity such as a hardware-backed proof of boot integrity. The device passes system integrity checks and meets Android compatibility requirements. An unlocked bootloader will ALWAYS fail this label because boot integrity cannot be verified.
    This table shows the relationship between SafetyNet and Play Integrity responses:
    1665499433643.png


    The most fundamental change is that Play Integrity, by default, uses hardware methods to verify BASIC and DEVICE integrity, which is why simply having an unlocked bootloader will cause the device to fail all 3 results. However, Play Integrity also uses hardware methods to verify device security state in addition to the aforementioned checks. This is STRONG integrity, which relies on hardware-backed key attestation as well as Verified Boot to verify that a device has not been tampered with and MEETS_STRONG_INTEGRITY. It is not possible to pass STRONG integrity on an unlocked and/or modified device. (Notable exception being devices with broken keystores such as ASUS ROG)

    It is worth noting that SafetyNet always provided the means for developers to force hardware backed evaluation types; none did, including Google.

    So this all sounds rather depressing. What do we do?
    Fortunately, we have the ability to force a legacy attestation method that prevents the use of hardware checks, meaning it is possible to partially pass. @Displax was able to do this with his fork of Universal SafetyNet Fix:
    (Response from Play Integrity Checker on my rooted Pixel 5 with Universal SafetyNet Fix MOD by Displax)
    1667488774837.png

    You can find that module here:

    Do not use MagiskHide Props Config or other fingerprint altering modules with this mod.


    As far as how this is going to affect us in the future, it's up to the app developers to decide what results they want. In most cases, all they care about is BASIC and DEVICE. But if they really want to ensure that they're running on a trusted platform, they can require STRONG attestation, which cannot be spoofed or bypassed. BASIC and DEVICE can, because they use the same mechanisms that SafetyNet did. The million dollar question is whether they ever will; if they do, this will mean everyone using older Android versions, specifically prior to 8.0, will be unable to pass Play Integrity, even on a bone stock locked device.


    For those interested in the timeline:
    1665497085076.png


    For more information, please read the discussion in this thread.
    5
    RL does hold me tight lately.
    ...which is why I already moved a few posts @V0latyle requested. Got your back! (y)
    5

    Tech = Spy-Biz, HippoMan

    FWIW, I'm answering this here (might be the best place...):
    Its none of the banks business to stop their clients from using rooted devices. Theyre just adding another hindrance to smooth banking operations thereby possibly hampering their own business by wasting both their and their clients time. Thats Stupidity!
    Well, seems that's a popular option here, but it's also a highly subjective one...
    Bank Devs did you hear? Pls discuss this with your bosses. Its like going backwards instead of forward.
    And you're going to need to do better than that... Even if banks themselves didn't persue these initiatives (ostensibly to protect their interests / bottom line) they're being driven by many other powerful entities...

    The Open Mobile Terminal Platform (OMTP) first defined TEE in their "Advanced Trusted Environment:OMTP TR1" standard around 2007, and for some 15 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 customer 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...

    So banks do their own security checks... Simply because Android Verified Boot doesn't work for them... I mean attestation to it in the usable deviceIntegrity 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 not being usefully implemented (ie. to allow detection of tampering with a runtime environment along with either a hardware based attestation to the device model or to a working implementation of keymaster for enforcing hardware evaluation type)... And it's not useful presently because the simple implementations of both SafetyNet evaluationType and Play Integrity strongIntegrity will necessarily fail all devices using Android 7 and below as well many OnePlus and other devices with broken keystore implementations if adopted (because attestation doesn't include the information in parentheses above) making this option largely impractical...

    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)...

    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...

    I totally agree!

    And as I've mentioned here before, every desktop computer is a rooted device, and of course we don't see the banks trying to hinder us from accessing their services from our computers.

    And banks gladly issue us debit cards which we keep in our wallets that are just as easy to steal as mobile devices.

    Rooted Android devices are just low-hanging fruit. And the amount of fraud that's prevented by trying to fight against Android root is minuscule, given the extremely small percentage of mobile device users who want to use rooted Android devices. I wouldn't be surprised if the amount of money that banks spend for anti-Android-modding software development exceeds the maximum amount of money that could be lost via the hacking of modded Android devices.
    But as I've told you before, and as the above should make abundantly clear, TEE and other, especially hardware backed, means to detect tampered execution environments for an application developer's code are here to stay in mobile devices, and are arriving in PCs also... cos like banks, Google and iOS etc, Microsoft is doing the maths also...
    In 2021, protections built into Windows, Azure, Microsoft 365, and Microsoft Defender for Office 365 have blocked more than 9.6 billion malware threats, more than 35.7 billion phishing and other malicious emails, and 25.6 billion attempts to hijack our enterprise customers by brute-forcing stolen passwords—that’s more than 800 password attacks per second...
    https://www.microsoft.com/security/...for-windows-11-will-help-protect-hybrid-work/

    Hardware and software makers hope TEEs provide a long-term solution for using sensitive data in a more secure manner on smartphones, PCs, cloud systems, and virtualized workloads...
    https://www.hpe.com/us/en/insights/...with-trusted-execution-environments-2102.html

    And Microsoft are already spruiking Windows 11 as a "Zero Trust" solution for PC advanced security needs...

    Guards against sophisticated attacks​

    Protects down to the firmware level with hardware security features that shield user credentials and other critical data.

    Secured-core PCs and hardware-based security​

    Secured-core PCs deliver the highest level of Windows 11 protection including advanced protection of firmware and dynamic root of trust measurement.

    Windows 11 security innovations​

    Microsoft optimizes Windows 11 for Zero Trust protection. Read the Windows 11 Security Guide for a quick overview.
    https://www.microsoft.com/en-us/windows/business/windows-11-secured-core-computers

    Anyway, as I see it, we are able to have a bit of fun beating the system, or really subverting mobile OS's security models only because these have been slow to implement proper / useful "zero trust" protections... The fun's sure to end sooner or later however cos we live in the real world!... And being real, you and I both know 'bank devs' will NEVER convince their bosses to abandon these advances either! (...ok, ok... advancement, regression, it's your call... or is it?... Who do we think we are???)...

    Eh guys?

    ... The only way you'll get your wish is by cobbling together enough funds to buy the banks, Google, the SOC makers and the OEMs you love ... Then you'll have a fighting chance. 🙂...

    Wish you luck... PW
    4
    I am not sure about the Google Pay Magisk Discussion Thread but, posts (including mine) related to Play Integrity in the Universal SafetyNet Fix 2.3.1 thread seem to start around Post # 1,796.

    All the posts about Play Integrity (that are not related to the USNF module) would have to be moved and kept in order to this thread.
    I am not sure how easy that would be to do, since a lot of the discussion included linked posts in the responses.

    Maybe @mrjuniork has an idea of the best and easiest way to do it?

    Cheers. :cowboy:

    PS.
    Sorry to ping you mrjuniork.
    I might be wrong but, it looks like you will be the one who gets stuck moving the posts.
    🙃