[DISCUSSION] Play Integrity API

[pndwal]

Do we know why in ASUS ROG Phone 3 the keystore is broken? I'm interested on it and why exactly it can pass the STRONG hardware verification.

AFAIK keystore/keymaster/keymint isn't broken in ROG Phone 3... Seems it has working keymaster implementation but the droidguard attestation is flawed...

FWIW, since DroidGuard itself is implemented as a custom virtual machine running dynamically loaded proprietary Google bytecode (unique for each attestation request) and when DroidGuardService is triggered it also checks latest DroidGuard version has been loaded as well, I believe that the Bootloader Verification it sources for Hardware Attestation as KeyStore.getCertificateChain is really the issue, so it comes back to the OEM's implementation of AVB and bootloader... Duplicating this in other devices, it seems, would depend on finding a boot chain or low-level vulnerability.

Some of the signals that ROG Phone 3's boot chain may be sending in error are outlined in this Google doc:
https://developer.android.com/training/articles/security-key-attestation

I put something (w/ help from @shoey63) about Rog Phone 3 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

Regarding the common failure of OEM's to test that keymaster, driodguard, AVB chain of trust, etc, responses are accurate and implementations comply with Google requirements/specs, Google seems to be tightening up at least w/ respect to broken keymaster implementations:

...

Nb. Google have clearly been steadily increasing the number of prop values used to flag devices for hardware based evaluation type enforcement in their whitelist implementation for newer devices/OSs... Notably, the last addition exempts no API level 33+ LV devices!

This means that no stock (un-modded) 33+ devices will pass deviceIntegrity w/o HKA, so it seems that Google expect OnePlus and other OEM's to have fixed bad keymaster implementations in all devices launched w/ Android 13+...

If manufacturers mess this up again, their stock/locked devices can now never pass even deviceIntegrity verdict (unless Google revert the first_api_level flag that effectively whitelists all A13+ devices for HKA evaluation type enforcement), so these are effectively being forced to 'up their game' at this time...

Guess they may need to start revoking device certifications to force OEM's to take due care with bootloader / AVB implementations however...

PW

 

[LaiKash]

AFAIK keystore/keymaster/keymint isn't broken in ROG Phone 3... Seems it has working keymaster implementation but the droidguard attestation is flawed...

FWIW, since DroidGuard itself is implemented as a custom virtual machine running dynamically loaded proprietary Google bytecode (unique for each attestation request) and when DroidGuardService is triggered it also checks latest DroidGuard version has been loaded as well, I believe that the Bootloader Verification it sources for Hardware Attestation as KeyStore.getCertificateChain is really the issue, so it comes back to the OEM's implementation of AVB and bootloader... Duplicating this in other devices, it seems, would depend on finding a boot chain or low-level vulnerability.

Some of the signals that ROG Phone 3's boot chain may be sending in error are outlined in this Google doc:
https://developer.android.com/training/articles/security-key-attestation

I put something (w/ help from @shoey63) about Rog Phone 3 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

Regarding the common failure of OEM's to test that keymaster, driodguard, AVB chain of trust, etc, responses are accurate and implementations comply with Google requirements/specs, Google seems to be tightening up at least w/ respect to broken keymaster implementations:

Guess they may need to start revoking device certifications to force OEM's to take due care with bootloader / AVB implementations however...

PW

Could it be possible to emulate this same behaviour with an emulator so as to test it? Trying to replicate the strong integrity verification with a rooted emulator (with Play Store so that the Integrity API can be executed) could be a really good starting point for some tests

 

[pndwal]

Could it be possible to emulate this same behaviour with an emulator so as to test it? Trying to replicate the strong integrity verification with a rooted emulator (with Play Store so that the Integrity API can be executed) could be a really good starting point for some tests

Emulate the flawed boot-chain VerifiedBootState data in verifiable hardware-backed key pairs with the root certificate within thie chain of X.509 certificates signed with manufacturer's factory set attestation root key etc, etc?

Maybe... doubtful... ...But I'm certainly the wrong person to be asking... PW

 

[immortalwon]

Emulate the flawed boot-chain VerifiedBootState data in verifiable hardware-backed key pairs with the root certificate within thie chain of X.509 certificates signed with manufacturer's factory set attestation root key etc, etc?

Maybe... doubtful... ...But I'm certainly the wrong person to be asking... PW

Should I buy this used phone from someone asus rog 3 if I want to have strong device integrity with unlocked bootloader? Asking for a friend

 

[V0latyle]

Should I buy this used phone from someone asus rog 3 if I want to have strong device integrity with unlocked bootloader? Asking for a friend

There's not really any point to passing STRONG_INTEGRITY, as there are no apps that depend on it. Most apps that are not security sensitive depend only on DEVICE result (to ensure they're running on a compatible platform) while those that are use the BASIC result as well as a mild guarantee of platform integrity. Google knows that both of these can be defeated and are not a secure guarantee, which is why they implemented HARDWARE_BACKED attestation in SafetyNet (now Play Integrity STRONG) but as far as I know, very few if any apps actually use it. As @shoey63 has demonstrated, the only "easy" way to pass all 3 is factory state locked, as with any other device; while it is capable of passing STRONG while unlocked, it's taken some work to get there.

 

[immortalwon]

There's not really any point to passing STRONG_INTEGRITY, as there are no apps that depend on it. Most apps that are not security sensitive depend only on DEVICE result (to ensure they're running on a compatible platform) while those that are use the BASIC result as well as a mild guarantee of platform integrity. Google knows that both of these can be defeated and are not a secure guarantee, which is why they implemented HARDWARE_BACKED attestation in SafetyNet (now Play Integrity STRONG) but as far as I know, very few if any apps actually use it. As @shoey63 has demonstrated, the only "easy" way to pass all 3 is factory state locked, as with any other device; while it is capable of passing STRONG while unlocked, it's taken some work to get there.

Thanks for the explanation. Only reason I am concerned is because one day Google will require this high level of integrity and I would like to remain unlocked and bypass the security they implement

 

[V0latyle]

Thanks for the explanation. Only reason I am concerned is because one day Google will require this high level of integrity and I would like to remain unlocked and bypass the security they implement

Well...there's no guarantee they will. They had the ability to require HARDWARE_BACKED evaluationType in SafetyNet but they never did for any of their own apps, and as far as I know, neither did any app developers. There's no saying whether they will or won't. The one thing that "protects" us is the fact that all pre Android 8 platforms are not capable of hardware key attestation, therefore they will never pass STRONG Integrity.

So while it's entirely possible that they could, it's worth noting that they always could since Android 8 (or at least whenever SafetyNet supported hardware backed attestation), but they never did.

Therefore the question is really whether they would start doing something that they never did before despite having the ability to do so for quite some time. If they could but they didn't, why would they start?

 

[V0latyle]

Welp, I broke CTS profile on my device somehow and USNF 2.3.1 MOD 2.1 isn't fixing it. Time to try MHPC...

 

[Lughnasadh]

Welp, I broke CTS profile on my device somehow and USNF 2.3.1 MOD 2.1 isn't fixing it. Time to try MHPC...

Displax updated his mod to 2.3.1-MOD_3.0. Not sure if it will help.

Release v2.3.1-MOD_3.0 · Displax/safetynet-fix

Google SafetyNet attestation workarounds for Magisk - Release v2.3.1-MOD_3.0 · Displax/safetynet-fix

github.com

 

[KrazyKlutt]

Displax updated his mod to 2.3.1-MOD_3.0. Not sure if it will help.

Release v2.3.1-MOD_3.0 · Displax/safetynet-fix

Google SafetyNet attestation workarounds for Magisk - Release v2.3.1-MOD_3.0 · Displax/safetynet-fix

github.com

Didnt work for me

 

[Lughnasadh]

Didnt work for me

Yeah, seems to be working for some but not for others.

 

[phaino00]

Welp, I broke CTS profile on my device somehow and USNF 2.3.1 MOD 2.1 isn't fixing it. Time to try MHPC...

Were you able to get CTS Profile restored to passing state via MHPC?

 

[V0latyle]

Displax updated his mod to 2.3.1-MOD_3.0. Not sure if it will help.

Release v2.3.1-MOD_3.0 · Displax/safetynet-fix

Google SafetyNet attestation workarounds for Magisk - Release v2.3.1-MOD_3.0 · Displax/safetynet-fix

github.com

It did...I think. I'm not sure what broke it in the first place. I'm on the stock February release and 2.3.1 Mod 2.1 was working before...well, before I tried the 14 DP then went back to the February release.

Were you able to get CTS Profile restored to passing state via MHPC?

No. Pixel 5 on TQ1A, was passing BASIC but kept failing DEVICE. Tried changing fingerprint, no dice. Tried forcing basic attestation, didn't help. Not sure what fixed it but I'm back on the stock fingerprint now

 

[phaino00]

I started failing device after update to Feb tq1a stock image. Tried all variations of mods and nothing. I unrooted and locked bootloader a few days ago. I'll probably try the updated displax 's updated mod after unlocking bootloader today or tomorrow. Tough few days without root...lol

Update:. Unlocked the bootloader again and re-rooted stock tq1a Feb image. Installed Displax's SafetyNet mod (ver 3.0). Passing integrity checks again.

Thanks to all for the info.

 

[SchWeinSAuG]

I started failing device after update to Feb tq1a stock image. Tried all variations of mods and nothing. I unrooted and locked bootloader a few days ago. I'll probably try the updated displax 's updated mod after unlocking bootloader today or tomorrow. Tough few days without root...lol

Update:. Unlocked the bootloader again and re-rooted stock tq1a Feb image. Installed Displax's SafetyNet mod (ver 3.0). Passing integrity checks again.

Thanks to all for the info.

hey there

what your status in play protect certification in playstore ?
mine keeps beeing uncertified, even i pass both tests in YASNAC
you got MHPC module installed?

Also rooted Stock Tq1a. Displax Savenet mod 2.4.0 v1.2

 

[V0latyle]

hey there

what your status in play protect certification in playstore ?
mine keeps beeing uncertified, even i pass both tests in YASNAC
you got MHPC module installed?

Also rooted Stock Tq1a. Displax Savenet mod 2.4.0 v1.2

What device?

If Play Integrity reports MEETS_DEVICE_INTEGRITY, Play Store should report Cerified
MHPC should not be necessary on stock firmware.

 

[SchWeinSAuG]

What device?

If Play Integrity reports MEETS_DEVICE_INTEGRITY, Play Store should report Cerified
MHPC should not be necessary on stock firmware.

pixel 6a.

gonna try with mod v3 and without MHPC

 

[V0latyle]

pixel 6a.

gonna try with mod v3 and without MHPC

Make sure you reset props before you remove MHPC. You want to start from a "clean slate" so to speak with the OEM fingerprint.

 

[SchWeinSAuG]

Make sure you reset props before you remove MHPC. You want to start from a "clean slate" so to speak with the OEM fingerprint.

thx mate

 

[phaino00]

hey there

what your status in play protect certification in playstore ?
mine keeps beeing uncertified, even i pass both tests in YASNAC
you got MHPC module installed?

Also rooted Stock Tq1a. Displax Savenet mod 2.4.0 v1.2

Play store is certified. I only have displax's 2.4.v1.1 installed and gpay is working too.

As @V0latyle mentioned, play store should be certified if you pass device integrity.