[DISCUSSION] Play Integrity API

Search This thread

V0latyle

Forum Moderator
Staff member
As the new Play Integrity API has become a major topic of late, I thought it best to create a thread specifically for that conversation.

SafetyNet has been discontinued in favor of the new Play Integrity scheme, which relies on hardware-backed key attestation (as well as Google's Play Integrity servers) to verify that a device MEETS_STRONG_INTEGRITY. Previously, we have been able to use methods such as device signature spoofing to pass SafetyNet by restricting the EvaluationType to basic. However, an unlocked bootloader (and custom binaries such as a patched boot image) prevent a device from being capable of the HARDWARE_BACKED EvaluationType, due to the disabling of certain features like the Trusted Execution Environment, which is used for HKA. Since the Play Integrity API depends on HKA for MEETS_STRONG_INTEGRITY this essentially means that Play Integrity cannot be spoofed; this would require breaking TEE, which currently has a $1.5M bounty.

In other words...it's not possible, and it likely will never be.

For now, those of us who want to remain rooted can use Magisk modules such as Universal SafetyNet Fix mod by @Displax which forces a "legacy" profile that depends only on BASIC and DEVICE integrity. Many newer banking apps such as GPay and Wallet are able to use both, so if you're having difficulty getting these to work on a rooted system, try the above mod.

However: Since progress never stops, there will come a time when Google, as well as other app developers, will end legacy support in their apps and force dependence on Play Integrity. This means that everyone who is rooted, everyone using versions of Android prior to 8.0, and everyone whose OEM implemented a broken keystore will fail Play Integrity and no longer be able to use those apps.

For more information, please read the discussion in this thread.
 
Last edited:

pndwal

Senior Member
But new devices have originally been released with A11 (or A12).
Hence, it's not possible to spoof A10 on those devices just by 'downgrading' the Android version

Then we come to the 'suggestions' to spoof fingerprints from a 'close device' (where A10 or earlier stock ROM was available) - but that just opens a Pandora box with who knows what kind of problems, because the same fingerprints are also used by system apps and services to drive various components:
- go to MHPC thread and find people who experimented with the same and lost fingerprint or the whole touch
- on another phone it could be camera or who knows what
- not to mention that spoofed CTS fingerprints may screw OTA and therefore brick the system
Yup... But this is what the @Displax mod solution is doing however, but targeting GMS... Also his USNF PR...

Also interesting:
This kills two rabbits:
• fix old SN CTS profile check on some weird Custom ROMs
• bypass Integrity (MEETS_DEVICE_INTEGRITY) for now.
https://github.com/kdrag0n/safetynet-fix/pull/207#issue-1317290126

@kdragon is taking interest... He's concerned about fingerprint mismatch issues too:
Have you noticed any features acting up with the old fingerprint?

Ideally, I think this should be scoped to Play Integrity code by identifying methods it calls near the beginning and end of integrity checks, and adding hooks to set and restore the fingerprint. I feel like setting a fingerprint that doesn't match the system in so many ways is bound to cause an issue somewhere.

So @Displax says it's "for now" / and is "just quick example (and core resolve) with temp fix for impatient people))... But need more testing with various devices." He agreed:
We need separate target hook for this (if feasible) - will be more polite solution...

Target process (one of?) "com.android.vending/com.google.android.finsky.integrityservice.IntegrityService"
https://github.com/kdrag0n/safetynet-fix/pull/207#issuecomment-1195951660

👀 PW
 

zgfg

Senior Member
Oct 10, 2016
7,804
5,216
Yup... But this is what the @Displax mod solution is doing however, but targeting GMS...
Yeah, that's the point - he uses Zygisk to limit CTS prints only to GMS - therefore if you use getprop you won't see the CTS prints being changed (like if you would use MHCP for changing the prints)

See that USNF is Zygisk type module, MHCP is not - hence MHCP cannot filter the props changes only to particular app/process

Therefore, other apps (like camera, Samsung store, etc) are not troubled - they still see the proper props values
 
  • Like
Reactions: rodken and 73sydney

pndwal

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


👀 🤠
 

V0latyle

Forum Moderator
Staff member
Since many are asking:

I've posted some information about Play Integrity MEETS_STRONG_INTEGRITY being akin to SafetyNet Evaluation type HARDWARE with CTS Profile match, but since it became a WOT, I put it here:
https://forum.xda-developers.com/t/magisk-general-support-discussion.3432382/post-87274009

😜 PW
I've been meaning to ask....Since Google is replacing SafetyNet with Play Integrity, is it safe to assume that there will come a day when app developers (particularly Google) remove SafetyNet support from their apps, at which point those of us with root will be unable to force "legacy" attestation as with the modified USNF? Of course this will mean that all versions of Android prior to the implementation of HA/TEE will be excluded as well, but it's not uncommon for developers to stop supporting older platforms.
 

V0latyle

Forum Moderator
Staff member
Some Insight on the New Cat and Mouse Game...

Since many are asking:

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


👀 🤠
Would you consider possibly boiling this down to a fairly simpler explanation that we can sticky? It's likely this will be the topic of quite repetitive questions going forward.

I tried to explain it somewhat simply here, please let me know how far I missed the mark
 
  • Like
Reactions: 73sydney

pndwal

Senior Member
I've been meaning to ask....Since Google is replacing SafetyNet with Play Integrity, is it safe to assume that there will come a day when app developers (particularly Google) remove SafetyNet support from their apps,
I put info about this originally here:
https://forum.xda-developers.com/t/magisk-module-universal-safetynet-fix-2-3-1.4217823/post-87188299

Google is urging Devs to do just that; S/N API was already depreciated in June with 'full turndown' slated for June 2024... banks are urged to move to PI asap, and at least before the June 2023 migration deadline. If they do, their older versions will continue to function with S/N API till June 2024. If they don't, these will cease to gat needed attestations from June 2023.
at which point those of us with root will be unable to force "legacy" attestation as with the modified USNF?
No, the new API includes all of the same device state checks and app processees use either one or the other, (although GPay seemed to use one for the app info and the other for card setup... but I'm betting it's only due to progressive changes...) so S/N turnoff won't matter...

You'll notice that if CTS Profile match fails for example, Device Integrity will fail also... The new API is a little stricter, especially for A11+ devices but @Displax's new USNF covers new enforcement bypass needed for these devices... The old bypasses are also still needed... And an official Pull Request is pending. (My Android 10 device doesn't need any change from official USNF)
Of course this will mean that all versions of Android prior to the implementation of HA/TEE will be excluded as well, but it's not uncommon for developers to stop supporting older platforms.
This is the point of what I just posted; if Google swings the enforce HKA if supported for MEETS_DEVICE_INTEGRITY hammer first, banks likely won't move to MEETS_STRONG_INTEGRITY sparing pre A8 stock devices... If they don't, eventually banks will implement MEETS_STRONG_INTEGRITY which will exclude customers using pre A8 devices... Either way it's game over for modders at that point... At least that's what my deduction says! 😛

See official dates, info, links from here:
https://developer.android.com/training/safetynet/deprecation-timeline

👀 PW
 

zgfg

Senior Member
Oct 10, 2016
7,804
5,216
I've been meaning to ask....Since Google is replacing SafetyNet with Play Integrity, is it safe to assume that there will come a day when app developers (particularly Google) remove SafetyNet support from their apps, at which point those of us with root will be unable to force "legacy" attestation as with the modified USNF? Of course this will mean that all versions of Android prior to the implementation of HA/TEE will be excluded as well, but it's not uncommon for developers to stop supporting older platforms.
That's something we can only speculate about.
Frankly, Google did not need Play Integrity - they could have simply forced CTS Profile checking through TEE (same thing as STRONG now) - but they didn't (yet)

Per specification, Google is not the final Judge. It only provides info how your device passes the Play Integrity API levels

If you are developer of a banking app, it is up to you would you allow DEVICE integrity, or would you require STRONG. Not even your banking app but better the banking server should make the final judgement (upon being passed the PI API test results)

Again, frankly, bankers could have already been checking do you pass CTS Profile with HARDWARE_BACKED or only BASIC, and allow only the first ones (they can also read that info with the old SafetyNet)

Btw, bankers (developers) can employ a more complex logic. Based on your phone model to require STRONG (new phones) or allow DEVICE (for older phones) - but it requires more work on their side
 
Last edited:

pndwal

Senior Member
Wow.. another thread 😬... Perhaps we could condense this in @Didgeridoohan's GPay thread?

Anyway, since you asked me to critique:
The reason for this is that Google is sunsetting the SafetyNet and Play Protect certifications
I hadn't heard about Play Protect depreciation (it's still there currently, and Play Store is already using Play Integrity API!), but SafetyNet is already deprecated...
in favor of the new Play Integrity API, which uses 3 fields:

MEETS_DEVICE_INTEGRITY
  • The app is running on an Android device powered by Google Play services. The device passes system integrity checks and meets Android compatibility requirements. This is replacing SafetyNet's ctsProfile. This is what USNF fixes.
MEETS_BASIC_INTEGRITY
  • 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. This is replacing SafetyNet's basicIntegrity, and means that Play Services has not detected root.
MEETS_STRONG_INTEGRITY
  • 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.
    This is replacing SafetyNet's Hardware Attestation, and uses the Android system's Trusted Execution Environment to guarantee process security. This will not pass with an unlocked bootloader, and cannot be spoofed as it specifically relies on hardware security; unlocking the bootloader "breaks" TEE.

The workaround for this is the modded USNF module by @Displax which forces the system to use the old SafetyNet API instead of Play Integrity.
Um, no...

It simply allows PI MEETS_DEVICE_INTEGRITY verdict in Android 11+ (generally), by creating a fingerprint prop SDK-level (and possibly other) mismatch that triggers bypassing of Hardware keystore attestation enforcement... The original USNF fallback trigger (fake keystone registration) and enforcement bypass (altered Model prop) are also needed for MEETS_DEVICE_INTEGRITY verdict, and these alone are enough for many devices (pre-Android 11 generally).
I imagine at some point in the future when SafetyNet is completely retired, app developers (especially large ones like Google) will eventually remove support for SafetyNet in their apps, which will mean that anyone whose device does not pass Play Integrity will not be able to use the app. This will include everyone running versions of Android older than 8.0, when TEE was implemented.
Hardware keystore and hardware TEE have been around at least since Android 6, but keymaster could not reliably verify the key pairs were in hardware... This was strengthened in Android 7 Keymaster 2 attesting to hardware backed keys, but only Android 8's Keymaster 3, with ID attestation allowing the device to provide proof of hardware identifiers, such as serial number or IMEI, was considered an attestation strong enough for HKA in android..

The other points are treated in my post above. 😛 PW
 
  • Like
Reactions: 73sydney

zgfg

Senior Member
Oct 10, 2016
7,804
5,216
Would you consider possibly boiling this down to a fairly simpler explanation that we can sticky? It's likely this will be the topic of quite repetitive questions going forward.

I tried to explain it somewhat simply here, please let me know how far I missed the mark
You may also see this answer (we are all talking the same things, maybe with slightly different words):
https://forum.xda-developers.com/t/...agisk-discussion-thread.3906703/post-87274309
 
  • Like
Reactions: 73sydney

V0latyle

Forum Moderator
Staff member
I admit it's a little hard to wrap my brain around this.

My understanding of the Play Integrity API was originally that in order to meet Play Integrity as a whole, devices would have to meet the BASIC, DEVICE, and STRONG integrity. I didn't know the apps looked at those qualities directly - I thought Play Integrity checked these, and if any of them was false, Play Integrity would report that integrity is compromised.

I promise I'm not being obtuse...

So the way it REALLY works is that the API is a method by which the apps can check these properties; it doesn't rely on a Google specific process (because AOSP)
Which means I still don't quite understand...how does the modded USNF allow apps such as GPay and Wallet to ignore the MEETS_STRONG_INTEGRITY?

It's clear to me that almost any device should return MEETS_BASIC_INTEGRITY, and that we have to use workarounds such as USNF to be able to return MEETS_DEVICE_INTEGRITY, and that we will never be able to return MEETS_STRONG_INTEGRITY because of HKA vs unlocked bootloaders.
 
  • Like
Reactions: 73sydney

zgfg

Senior Member
Oct 10, 2016
7,804
5,216
I admit it's a little hard to wrap my brain around this.

My understanding of the Play Integrity API was originally that in order to meet Play Integrity as a whole, devices would have to meet the BASIC, DEVICE, and STRONG integrity. I didn't know the apps looked at those qualities directly - I thought Play Integrity checked these, and if any of them was false, Play Integrity would report that integrity is compromised.

I promise I'm not being obtuse...

So the way it REALLY works is that the API is a method by which the apps can check these properties; it doesn't rely on a Google specific process (because AOSP)
Which means I still don't quite understand...how does the modded USNF allow apps such as GPay and Wallet to ignore the MEETS_STRONG_INTEGRITY?

It's clear to me that almost any device should return MEETS_BASIC_INTEGRITY, and that we have to use workarounds such as USNF to be able to return MEETS_DEVICE_INTEGRITY, and that we will never be able to return MEETS_STRONG_INTEGRITY because of HKA vs unlocked bootloaders.
Here (again) link to Google's doc:

Pay attention to verdict - but better spend 15 minutes to read the whole

And in YASNAC, you can also read the JSON with eg details was the CTS Profile checked on TEE or not (= STRONG integrity for the be PI API)
 
  • Like
Reactions: 73sydney

pndwal

Senior Member
Frankly, Google did not need Play Integrity - they could have simply forced CTS Profile checking through TEE (same thing as STRONG now) - but they didn't (yet)...
FWIW, the real reason for the change was to provide an inclusive Integrity solution that
helps protect your apps and games from potentially risky and fraudulent interactions, allowing you to respond with appropriate actions to reduce attacks and abuse such as fraud, cheating, and unauthorized access.
by combining existing SafetyNet attestation in Device Integrity fields with the new Application integrity and Account details fields in a single API.

🤠 PW
 
  • Like
Reactions: 73sydney

pndwal

Senior Member
I admit it's a little hard to wrap my brain around this.

My understanding of the Play Integrity API was originally that in order to meet Play Integrity as a whole, devices would have to meet the BASIC, DEVICE, and STRONG integrity. I didn't know the apps looked at those qualities directly - I thought Play Integrity checked these, and if any of them was false, Play Integrity would report that integrity is compromised.

I promise I'm not being obtuse...

So the way it REALLY works is that the API is a method by which the apps can check these properties; it doesn't rely on a Google specific process (because AOSP)
Which means I still don't quite understand...how does the modded USNF allow apps such as GPay and Wallet to ignore the MEETS_STRONG_INTEGRITY?

It's clear to me that almost any device should return MEETS_BASIC_INTEGRITY, and that we have to use workarounds such as USNF to be able to return MEETS_DEVICE_INTEGRITY, and that we will never be able to return MEETS_STRONG_INTEGRITY because of HKA vs unlocked bootloaders.
Apps can use MEETS_DEVICE_INTEGRITY by default, using any distribution channel. Registration with Google Play allows use of MEETS_BASIC_INTEGRITY and MEETS_STRONG_INTEGRITY in addition...

Flow chart:
IMG_20220813_014920.jpg

😛 PW
 
  • Like
Reactions: 73sydney

V0latyle

Forum Moderator
Staff member
Here (again) link to Google's doc:

Pay attention to verdict - but better spend 15 minutes to read the whole

And in YASNAC, you can also read the JSON with eg details was the CTS Profile checked on TEE or not (= STRONG integrity for the be PI API)
I have read this and keep going back but I'm no developer and my general understanding of Android is less than elementary

Apps can use MEETS_DEVICE_INTEGRITY by default, using any distribution channel. Registration with Google Play allows use of MEETS_BASIC_INTEGRITY and MEETS_STRONG_INTEGRITY in addition...
This is where it's still confusing to me. Because according to that statement, it sounds like developers can choose what guarantee of security they want...but
This makes it sound like Play Integrity is not so much a framework as it is a service, meaning at some point app developers will have no choice?

Or am I right on both accounts, but app developers can either call the Play Integrity API, or they can call the device security fields alone?
 
  • Like
Reactions: 73sydney

V0latyle

Forum Moderator
Staff member
@ipdev @pndwal @zgfg @TraderJack I know it's a lot of work, but could you please move your posts on Play Integrity into this thread as described above? The idea is to have one thread to discuss this topic, as well as a place to point other users to should they have questions. If someone would like to volunteer their post, I can copy/paste into the OP so we have an up front explanation of what Play Integrity is, how it works, and what it means for rooted/modded users.
 

zgfg

Senior Member
Oct 10, 2016
7,804
5,216
@ipdev @pndwal @zgfg @TraderJack I know it's a lot of work, but could you please move your posts on Play Integrity into this thread as described above? The idea is to have one thread to discuss this topic, as well as a place to point other users to should they have questions. If someone would like to volunteer their post, I can copy/paste into the OP so we have an up front explanation of what Play Integrity is, how it works, and what it means for rooted/modded users.
Is it possible to move the posts without copy-pasting them?

I mean it is if I mark it is Report and ask you to move - but then it's more work for you. Hence some other way?
 

V0latyle

Forum Moderator
Staff member
Is it possible to move the posts without copy-pasting them?

I mean it is if I mark it is Report and ask you to move - but then it's more work for you. Hence some other way?
No, only moderators can move posts (and we have forum specific moderators so it wouldn't be me lol)

Else, you can copy/paste and request the old post be deleted
 

pndwal

Senior Member
I have read this and keep going back but I'm no developer and my general understanding of Android is less than elementary
X2
This is where it's still confusing to me. Because according to that statement, it sounds like developers can choose what guarantee of security they want...
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 causes enforcement of a Hardware based verdict to be bypassed, ie. 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)" may be misleading; really, MEETS_STRONG_INTEGRITY only indicates a passing STRONG_INTEGRITY verdict using hardware TEE; of course, unlocked devices will fail to return MEETS_STRONG_INTEGRITY and there will be no indication whether hardware TEE was used or not in PI, unlike old S/N attestation... Conversely, CTS Profile will be checked in TEE (ie. we see S/N HARDWARE evaluationType) to attest to DEVICE_INTEGRITY if it's available by default (ie. on A8+ devices), but if it fails there is no indication from PI API that hardware TEE was used, and no indication if hardware was used if it succeeds either unless STRONG_INTEGRITY succeeds also...

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

This makes it sound like Play Integrity is not so much a framework as it is a service, meaning at some point app developers will have no choice?
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...
Or am I right on both accounts, but app developers can either call the Play Integrity API, or they can call the device security fields alone?
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 Device integrity, 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...
 
Last edited:

ipdev

Recognized Contributor
Feb 14, 2016
1,920
1
3,526
Google Nexus 10
Nexus 7 (2013)
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.
🙃
 

Top Liked Posts

  • There are no posts matching your filters.
  • 4

    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
    2
    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.
    1
    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.
    1
    Hopefully, there could be some truth in what was discussed here.
    You can go here for my response to that:
    https://forum.xda-developers.com/t/...ding-cat-and-mouse-game.4425939/post-87403751
  • 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
    RL does hold me tight lately.
    ...which is why I already moved a few posts @V0latyle requested. Got your back! (y)
    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.
    🙃
    4
    @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
    4

    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