[Android Software Development] pndwal:
Clearly. 😜

Yeah... The "Such as" made it ambiguous for me. 🤪

Agree... Seems it does after all! 🤭

Ie. SafetyNet is not passing (as far as banks are concerned) unless CTS Profile match = true also! 😜

Yup, = full CTS Profile match pass w/ HA... this is now apparent...

Nb. basicIntegrity is always required for (real) CTS Profile match pass.

Well I turned off USNF and no longer achieve PI Device Integrity in new PI API Checker for one thing. 😛 ...

But I need to test further which mechanisms are required when we shouldn't need to trigger fallback to basic evaluation... Or should we? 🤔 ...

Well, when a signed attestation is requested the response includes 'evaluationType' which will indicate BASIC was used just like devices that launched w/ Android 7 or less (lacking keymaster 3) do.

Yup, but no need to assume the other; it's pretty clear that PI doesn't require HA for MEETS_BASIC_INTEGRITY (which is of no interest to banks AFAIK in any case) or for MEETS_DEVICE_INTEGRITY for any device.

Yup... Good find; I'd missed this, and the fact that STRONG_INTEGRITY verdict requires HARDWARE_BACKED evaluation. 😬 👍

Seems to make sense to me; if only DEVICE_INTEGRITY is requested, the app is satisfied with the equivalent of SafetyNet full pass... SafetyNet Basic Integrity may be passing (= PI BASIC_INTEGRITY) and this verdict may be useful for some apps but it's not sufficient for bank app security etc generally...

er, no (doesn't require ctsProfileMatch)... That would be MEETS_DEVICE_INTEGRITY w/ either evaluationType...

Nb. the Empty labels state w/ ctsProfileMatch is a false state; XPosed module etc must be intercepting / faking signals... It's not from Google server end.

I see that's correct... Many thanks for the PI verdict mapping link! 😛...

This is probably why Google (it now) seems is not (😜) calling STRONG_INTEGRITY verdict yet... This would preclude use of GPay etc for users of:

1) Many late devices (many OnePlus and others) with broken keymaster implementations.

2) users of devices launched with Android 7 and earlier even if running late Android.

Also, I assume/hope that generally banks won't want to exclude these users / customers either ... Most of them should likely wait for 'reasonable' market saturation of devices with properly implemented HKA / keymaster... I guess they will use STRONG_INTEGRITY verdict

will eventually...

It should also be noted that this really changes nothing: banks could have excluded the same groups of customers (as well as modders using USNF) by using SafetyNet evaluationType result; I'm not aware of any that do this yet.

So Play Integrity API so far seems to be just a new way to package the same attestation as far as deviceIntegrity is concerned...

It does add entirely new unrelated security functions however, eg appIntegrity field including PLAY_RECOGNIZED, UNRECOGNIZED_VERSION and UNEVALUATED verdicts and accountDetails field including LICENSED, UNLICENSED and UNEVALUATED verdicts.

Nb. We still need Universal Fix for Play Integrity API's equivalent to SafetyNet pass (ie. MEETS_DEVICE_INTEGRITY) as (at least some of) the methods USNF module uses are needed to spoof DEVICE_INTEGRITY. (Try turning off USNF and running @1nikolas's integrity checker.) Also, we clearly need further spoofing for late (11+) Android versions...

I will have to fix errata in my USNF GitHub issue (soon) now... 🤷 🤪 PW