Play Integrity API

spring-onion can you please elaborate a bit on security issues? There seem to be a hot mess of opinions around it and it is hard to pick some meaningful signal in all the noise

borgo I'm in the UK and as far as I'm aware Starling Bank supports GrapheneOS. Each time it's has been broken and reported, their devs have responded saying they have been made aware of the issues and pushing a fix for GrapheneOS soon - and the fix comes about and sanity is restored.

There's even a (or multiple?) thread in this forum about it and in the GitHub repo dedicated to which banking apps work on G-OS.

I think just for that itself, these people deserve to be applauded and I've got myself and many of my folks (I've installed G-OS for as many as I could convince in my family and also among friends/colleagues) as I could to use Starling, even if they for some reason don't want it to be their main banking app. I see it similar to donating for a FOSS project or crowdfunding exercise. On top of that Starling is actually damn good banking experience.

So we should have a pin-up of all these banks (along with the country/ies they operate in) and encourage folks to give them a try. That way they have more customer base, feel it important to continue supporting G-OS and have our loyalty. That might also have an effect on other banks falling in line when they see a precedent (otherwise the banking software industry works with pre-historic constraints and herd mentality).

andzhi4 It doesn't verify the signatures which prove apps genuinely came from the play store.

GrapheneOS can you imagine any reason for why the same app (same version) would sometimes fail to open due to play integrity check and other times it would work?

borgo very weird behaviour. for me it works sometimes, and sometimes it doesn't. however, I couldn't reproduce it yet. i just thought that the VPN could make some difference (e.g. an additional security check based on where you're opening the app from,...).

spring-onion spring-onion Thank you, I see how this could be a problem. I could not help, but checked how Aurora retrieves an app. They depend on their own gPlayApi lib, which in turn has all the URLs hardcoded (GooglePlayApi.kt)

companion object {
        const val URL_BASE = "https://android.clients.google.com"
        const val URL_FDFE = "$URL_BASE/fdfe"
        const val CATEGORIES_URL = "$URL_FDFE/categoriesList"
        ...

So I have to somehow poison users DNS lookup, add malicious root CA to their phone and serve an exploited but very similar to original apk that would persuade them to install, launch and give necessary privileges.

Aurora also has hardcoded Google Play cert in utils/CertUtils.kt, but it is used for some edge cases with microG

const val GOOGLE_PLAY_CERT =
        "MIIEQzCCAyugAwIBAgIJAMLgh0...

Anyway, if Aurora Store itself is not compromised, it does not look like something a script kiddy could pull through, to put it mildly. I think, at the point where an attacker can add their own CA to your system you already waist deep in trouble and Aurora is not even on the list :).
Please correct me if I'm missing something, I did just a very quick code lookup and might have missed important pieces

andzhi4

So I have to somehow poison users DNS lookup, add malicious root CA to their phone and serve an exploited but very similar to original apk that would persuade them to install, launch and give necessary privileges.

No, this is not how it works.

add their own CA to your system you already waist deep in trouble and Aurora is not even on the list

This is not how this works.

Please correct me if I'm missing something, I did just a very quick code lookup and might have missed important pieces

WebPKI does not provide strong assurance that you're obtaining valid APKs. Google's own servers also have layers of trust and APK signing is far more protected than the TLS entry point.

GrapheneOS Thanks, I agree proper chain of trust is much stronger than just TLS authenticating whatever host provides you the file. But this scenario assumes that Play itself might have been compromised and serves you malicious APKs on the API, correct? Then validating APK's signature after download would raise an alarm.
Also, Aurora using reversed engineered API probably does not help the situation.

skydel0 @borgo

I did not receive a feedback from Yuh yet. However, I wonder if I managed to get an idea on when it happens and when it doesn't. I just had the issue again, but I also managed to enter Yuh just a moment after.

I don't have it installed on my Owner profile, but in my "Fin-Profile" (that includes Google Play Services). It seems I only have the issue when I re-enter this "Fin-Profile" and Yuh has been open already before (normally on the same day). Closing Yuh and reopening it newly usually fixes the issue.

It seems the problem therefore only arises if:
I) the profile has been running in the background
II) Yuh has been running in the background and you're re-entering

This is why it might seem "random". So it could be that this integrity API is only checked by Yuh in case it has been active and you re-enter it, but not in the actual initial start up of the app.

Do you have a similar impression? Can you confirm? Anyone any thoughts?