Play Integrity API and Future of GrapheneOS

PacoBell

Fsck, Niantic is placing their Ingress Prime game behind GPI STRONG_INTEGRITY starting 5/27. I'm thinking this decision is the writing on the wall for all the rest of their properties, including the rather popular Pokémon Go franchise. I've already sent their support contact a plea to support the hardware attestation API and allowlist GOS' verified boot keys. I really don't want to have to relegate my current phone to "burner" status and revert to the stock image just to be able to enjoy these games.

https://niantic.helpshift.com/hc/en/3-ingress/faq/4495-ingress-is-not-supported-on-this-device-configuration-error-android-only/

Ammako

PacoBell yeahhh this is why I waited until I upgraded before playing any of this stuff. I can actually just keep the previous phone as a dedicated machine on stock OS to ensure compatibility, while the new daily driver remains separate.

adamc1999

My Arculus wallet is throwing an integrity check error after an update from April 8 2024

Is this the issue being discussed re: integrity api?
What can be done?

matchboxbananasynergy

adamc1999 If the app is using Play integrity API, they need to either add support for whitelisting GrapheneOS (for which we provide a guide), or stop using these checks.

[deleted]

To add my two cents, GrapheneOS has a great future without using Google Play Services. No one is forced to use them and in fact not using them gives one much higher level of privacy than if you did. Not talking here about security, that comes with the OS and its setup in both cases.

Tryptamine

[deleted] Is it really a higher level of privacy?

What if you turn off your all data collection preferences in your Google account, or never sign in?

Some may not trust this to be honored, but if it wasn't, then Google would be called out on it once people still were seeing personalized ads after turning off Web and App Activity and using Google apps and search. They haven't been, out of millions of users...

I've confirmed that turning on the toggle "Reroute location requests to the OS" prevents your device giving location to Location History, completely! Its an opt in thing in GrapheneOS.

One can do many things to make use of Google (Sandboxed) Play privacy respecting, yet I keep seeing assumptions and speculation like this, and I've tested as thoroughly as I can to try and disprove these speculative remarks. Nothing I have ever seen points to Google not respecting its privacy controls, and why should they be special and untrusted when other companies are trusted?

Sandboxed Google Play is an excellent feature! I dont think we should be discouraging others from using it! Especially when there are no hard facts presented for why, only one's feelings on the matter and one's speculation.

[deleted]

Tryptamine I mention the overall picture not the granularity off whichever toggle. You are welcome to believe in whatever it is that you believe in and use whatever it is that you use to make you happy and satisfied. I will not get nerdy here like you.

mmmm

Tryptamine I've confirmed that turning on the toggle "Reroute location requests to the OS" prevents your device giving location to Location History, completely! Its an opt in thing in GrapheneOS.

What's this then? Where is it and do you have a bit more info as to what it does or what it's for?

Tryptamine

[deleted]
Then please dont spread your speculation around without some evidence. Its irresponsible and could easily make things more difficult for new users who dont share the same level if paranoia.

For example, the new users who dive head first into believing that they need to use separate profiles for everything just because others do so and portray that as the only secure solution in relation for apps that run with Google Play. The main advice given to these people is to not bother at first!

Your comments as an experienced user can have them ignoring a powerful feature in GrapheneOS. That may be right for you, but not for others. Believe what you want, but here is a place of facts, not beliefs.

[deleted]

Just to add to my previous comment, I should have said great future with or without Google Play Services and I was in no way hinting against its use.

Tryptamine

[deleted] can't edit my last comment, just saw this.

Yeah, that's a lot better! Thank you.

[deleted]

Tryptamine Okay. I just have to reiterate like you said for those newcomers, that with its use you are basically bringing another trust party into play and in fact not very privacy respecting despite all the available toggles (and let's not start pulling out all those online articles mentioning user data misuse, which predominantly happen on stock devices) and Google Play Store opens a door to a whole world of potentially harmful apps (and that is not to say that all FOSS apps are harmless). You just have to do your research and learn how to restrict the environment and conditions those apps operate in to achieve desired functionality if possible without giving up too much privacy and convenience. It is and evolving battle and using Google Play Services on GrapheneOS will undoubtedly create app compatibilty problems in the future.

matchboxbananasynergy

[deleted] It is and evolving battle and using Google Play Services on GrapheneOS will undoubtedly create app compatibilty problems in the future.

Not at all clear what you mean here, and the conversation seems to drifting away from what the thread's topic is about.

I'd appreciate if you could please stick to what the thread is about instead of trying to push your opinions on different topics on all threads. This goes for everyone, not just @[deleted].

[deleted]

matchboxbananasynergy sorry, if you think I am mumbling here, you are welcome to delete all my posts in this thread. I have a pretty good idea what I mean.

Tryptamine

matchboxbananasynergy got it. Apologize if that's what it seems like I'm doing... My intention was to stick to facts here rather than speculative reasoning, but I can see how my posts could be misconstrued. Feel free to delete as you see fit!

Bringing it back to the initial topic;

Yeah, I really hope that more apps don't use stronger Play Integrity checking, but so far that is few and far between... Hope it stays that way, or...

Would be incredible if hardware based attestation were to have a surge in popularity! However I really wonder why that hasn't been the case... It seems to me that would provide a much stronger form of attestation than using play integrity, but I've never heard a story to date that an app has switched to it. I'd love to be wrong on this point!

Carlos-Anso

mmmm
That is the default setting. It makes all apps which request location from Google Play instead have the request routed to the OS location provider. Google Play does not need location permission.

mmmm

Carlos-Anso thanks for the info!

evol

dln949 i imagine its proprietary, but i wonder if there could be a foss project that tries to emulate it. donw know much about that possibility heheh.

crowbahr

Hey - Staff Android developer at a large, publicly traded company here.

We're seeing increasing rates of cyber security issues related to compromised devices which is why we've adopted the Play Protection API as part of a multi-pronged effort to reduce AI based impersonation attacks on our platform.

The reason why we really need attestation is to ensure that the device isn't compromised and that the app is similarly unmodified.

From reading the documentation I'm not seeing how we could prove app integrity with the existing hardware signing certificates proposed by GrapheneOS as a solution.

I'm interested in other options, or docs on what I've missed here.

I'm considering installing Graphene on a spare device just to see what happens with the integrity checks but it'd be nice if someone could weigh in on exactly what would fail in the Play check. Is it just the deviceIntegrity field while the appIntegrity field would still pass? Would nothing happen at all? What kind of access risks would show up in the environmentDetails, if any?

Obviously it's hard to get bandwidth allocated to supporting niche distros, especially with as lean as most teams run these days. That said: if I can sneak in some tweaks and support Graphene within one weekend...

chinook

crowbahr hey, thanks for expressing the interest.

Before someone gets the gory details, I'm curious how does your organisation reconcile Google-certified phones not getting updates since several years and considering vulnerable Android 12 or 13 (eg: Pixel 4) systems as safe/trusted (because certified by Google) - knowing many of these vulnerabilities could be used to temporarily root the device and hide this fact

At the same time GOS handset that passes hw attestation is not rooted and not modified. Basically pure, safer AOSP without privileged Google services :)

Last time I checked (few months ago), my ancient Xperia Z5 could still runs most of the apps, including two of my four banking apps.

I'm really just wondering what your position is, because it likely has been discussed in your team.

exactly what would fail in the Play check

Play Integrity API checker (gr.nikolasspyr.integritycheck) says my handset passes MEETS_BASIC_INTEGRITY but fails MEETS_DEVICE_INTEGRITY and MEETS_STRONG_INTEGRITY.

    "appIntegrity": {
        "appRecognitionVerdict": "PLAY_RECOGNIZED",
[...]
    "deviceIntegrity": {
        "deviceRecognitionVerdict": [
            "MEETS_BASIC_INTEGRITY"
        ],
        "recentDeviceActivity": {
            "deviceActivityLevel": "UNEVALUATED"
        },
        "deviceAttributes": {
            "sdkVersion": 36
        }
    },
    "accountDetails": {
        "appLicensingVerdict": "LICENSED"
    },
  "environmentDetails": {
        "playProtectVerdict": "NO_ISSUES",
        "appAccessRiskVerdict": {
            "appsDetected": [
                "KNOWN_INSTALLED",
                "UNKNOWN_INSTALLED"
            ]
        }

Thanks! (And thanks a lot for the interest, it may help other devs as well)

Watermelon

(I am NOT part of the GrapheneOS project.)

crowbahr which is why we've adopted the Play Protection API

crowbahr From reading the documentation I'm not seeing how we could prove app integrity with the existing hardware signing certificates proposed by GrapheneOS as a solution.

This implies that Play Integrity does something you need that the base API for attestation doesn't do. What is it that you find lacking in it? Note that attestation isn't just about the fingerprints. They point to the source code of their Auditor app. Quote:

Our MIT / Apache 2 licensed Auditor app can be used as a reference implementation for verifying hardware-based attestations.

crowbahr I'm interested in other options, or docs on what I've missed here.

If you have a Pixel, you can try the Auditor app on it in auditee mode. It's one of the core features in GrapheneOS and preinstalled in it, but also recognizes the stock OS of Pixels, and available on Google Play Store. The Auditor app uses hardware-based attestation completely independently from Play Integrity. You can see as a user what kind of info it's capable of reporting and checking. As far as I know, everything that the Auditor app checks can also be checked by any other app equally well (note that the GrapheneOS team added GrapheneOS-specific reporting of stuff like the auto-reboot timer and USB-C port setting, and I believe they can also be checked by any other app, but it's possible that not).

lbschenkel

crowbahr I'm not seeing how we could prove app integrity with the existing hardware signing certificates proposed by GrapheneOS as a solution.

I would need to look again, but last time I checked the Android attestation API, the app signature was part of the signed data so you also verify the app integrity as part of the attestation.

Since you are going to whitelist official GOS keys in this approach, this is implicitly trusting that GOS is trusted to do the signature checks before running your app and will not lie about the signature.

So it should give the same assurances in the end: unmodified device, unmodified OS, unmodified app.

GrapheneOS

crowbahr

We're seeing increasing rates of cyber security issues related to compromised devices which is why we've adopted the Play Protection API as part of a multi-pronged effort to reduce AI based impersonation attacks on our platform.

Play Integrity API does not provide any serious protection against this and forbids users from using more secure devices.

From reading the documentation I'm not seeing how we could prove app integrity with the existing hardware signing certificates proposed by GrapheneOS as a solution.

It provides cryptographic verification of the app through the package name, version code and signing key verification which is passed to the secure element by the verified OS for inclusion in the signed attestation. Why do you think you can't verify app integrity with it? Have you looked at the hardware key attestation API? The entire purpose of the Play Integrity API strong integrity level is using the hardware key attestation API to verify the OS and app in a much more secure way than software checks.

I'm considering installing Graphene on a spare device just to see what happens with the integrity checks but it'd be nice if someone could weigh in on exactly what would fail in the Play check. Is it just the deviceIntegrity field while the appIntegrity field would still pass? Would nothing happen at all? What kind of access risks would show up in the environmentDetails, if any?

You should use the hardware attestation API and verify your app's package name, version code and signing key fingerprints. You shouldn't use the Play Integrity API for this.

Obviously it's hard to get bandwidth allocated to supporting niche distros, especially with as lean as most teams run these days. That said: if I can sneak in some tweaks and support Graphene within one weekend...

Your company is going out of the way to forbid using GrapheneOS with a security feature which doesn't provide what it claims but rather exists to enforce Google's business model. It was an explicit choice to go out of the way to forbid using much more secure devices while still permitting devices with no security patches for many years.

crowbahr

chinook

While I'm limited in the amount of details I can share I can say that we're requiring MEETS_STRONG_INTEGRITY for our sensitive actions. I appreciate the API checker output for your GOS device - that's good to see. Having a PLAY_RECOGNIZED verdict along with the build number and sha256 of the build are all part of the required checks. It looks like you'd only be failed for the MEETS_STRONG_INTEGRITY check - which is what I'd expect.

For the MEETS_STRONG_INTEGRITY portion obviously there are issues on Android SDK <= 32 where the Strong verdict is returned purely based on hardware boot integrity with no recent security patch requirements. We're monitoring how this goes to see if we still have issues with camera spoofing on those devices, in which case we'll lock all SDK <= 32 out of the sensitive actions in app.

Again I'm trying not to dox myself here but we're a luxury product and we deal with PII so we have to take customer data very, very seriously. The security review on these kind of changes might take over a month on its own. So it's a not inconsiderable headache to support this when the Google Play API covers 99.999% of our customers, most of whom are nowhere near tech savvy enough to install a custom rom, and Security signs off on that for free since it's as simple as having the device perform the check then sending the token off to Google on our backend and getting a verdict. No chains to look into, it uses the existing GCM project etc etc.

THAT SAID - It sounds like I could add the attestation key certificate chain into the attestation step up and just have the server check that in the case that the device fails STRONG_INTEGRITY, allowing only the GrapheneOS boot key fingerprints. Where do you post revocation status btw? Is it in the Google maintained list?

« Previous Page Next Page »