borgo Revolut app is working again for the time being until they start enforcing the Play Integrity API. Hopefully, enough pressure can be put on them before they do that to convince them to implement support for GrapheneOS via hardware attestation.
Play Integrity API
I was blocked to log in yersterday but now i can log in and I no longer get the Play Integrity API notification. Anyway, I will close the account. Not the first time, i have issues with their service.
User163826 Super weird behaviour. I tried to login by opening it from the home screen, same issue (couldn't log in). I opened the app through the Google Play Store (from where I installed it initially some weeks ago) and tried to login, and it worked. (That was the case now at 1405 CET, I tried both just behind each other). Now I can even login when I block the Play Integrity API. It's still the same app version (1.35.2).
When searching for an app on the Play Store, if Play Store says "Your device cannot run this app", is it related to the Integrity API? I have a Pixel 6.
- Edited
Aru Almost always yes. The aurora store could come in handy here if the app does no more checks (upon launch for example) or has a broken implementation in general. But mind the possible security implications of aurora, especially if we're talking of a sensitive app here.
It works for me too now, same app, same version, changed nothing...
Question about this. As I'm unclear about what stage of use of the API an app is at.
Alladin Connect (garage door interface) was stalling on login and I got a Play Integrity pop-up from GOS for the first time. After blocking the API it immediately logged in, so I don't think "banned" is right, it I'm unclear.
I'm preparing to write to the developers. Anything specific I should be telling them?
I suggest that maybe GrapheneOS could block this API by default, so that apps wouldn't be able to store its verdict and reuse it after manually starting to block it. Sure, it's also possible to switch off internet access/toggle off the Network permission, but some apps can only start with internet connectivity.
- Edited
Watermelon That's not how it's used in practice. Blocking it also doesn't generally achieve anything and is only provided for a very narrow set of services which are using it but not yet enforcing providing a result. The main purpose of the feature is identifying the apps using it, not blocking it.
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?
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
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.