Spoof CTS Profile checks in Play Integrity API checks to pass with MEETS_DEVICE_INTEGRITY #1986
Comments
|
Spoof? Isn't that contrary to GOS goals? |
|
In what way? If there's a non-invasive, sandbox-friendly, minimal, and safe way to improve app compatibility by passing this why would we not want to do it? It could possibly make apps like Google Pay work. What "goals" is it conflicting with? |
|
The only reason not to do this would be because then people would be relying on these apps working and will be disappointed when it is no longer possible to spoof this in the future. That said, there's no timeline for when that time will come, so having this in the meantime would be great for a lot of people! |
It would have to be on an opt-in basis alongside an explanation that it is ultimately not a bulletproof mitigation, and that apps may suddenly break. |
|
I would agree with that, a lot of banking / payment apps use CTS checks now :( On a more personal note, this is the only problem that really keeps me on iDevices now |
|
EDIT: sent them the request to implement hardware attestation according to: https://grapheneos.org/articles/attestation-compatibility-guide |
|
To avoid being just another "+1", "this is really important to me", "please do this", I'll put my money where my mouth is. I'm willing to donate $500 to GrapheneOS once this is implemented, available on stable, and google wallet works. This expires 6 months after this is posted. (I would very likely be willing after that but just want to constrain my promises) HMU if you want to discuss details, talk to me on discord or gmail with the same username |
While I don't speak for the GrapheneOS team directly, GrapheneOS generally doesn't accept bounties as what is delivered can differ from what people expect, and that can cause friction. GrapheneOS accepts donations, but they do not come with "strings attached". I would assume that this goes doubly for this specific feature because even if this is added, it is added with the explicit understanding that it can stop working at any time. The moment an app decides to use strong hardware-based attestation instead of weak, spoofable software attestation, any such feature or workaround will immediately stop working without a clear way to ever make it work again. As such, one can imagine a scenario in which this feature is developed, and stops working shortly after that. You've now "paid" for a feature that doesn't work, and the team has no recourse. It is much simpler for the team work on what makes sense to work on at the time and for people to support that work, rather than being sidetracked with bounties (in my opinion). With all of that said, though, your offer is still generous, and I'm glad to see people willing to fund GrapheneOS feature development, even if this specific way of doing so is one which I think doesn't make a lot of sense. |
|
I realize that google could change their proprietary code the day after this feature is finished and make it useless, I am willing to take that risk. That said, I can understand people may not want to take the particular deal, that's fine. I hope I've at least brought more attention to the issue. |
The Uber Driver work app currently doesn't work on GrapheneOS because it relies on Google Play. I presume this is an Attestation issue and another reason GOS should get this working. I rely on Free Software as an Independent Contractor; all the hefty fees and proprietary data on a bloated "stock" Android OS is a security nightmare. |
As workaround you can use the PWA, which works flawlessly |
|
Spoofing Google certification without now requires spoofing a legacy device model that's either quite old or shipped with a broken hardware attestation implementation. Google appears to be actively banning the build fingerprints being used for spoofing at scale. GrapheneOS has far too many users for us to avoid this being detected and acted upon. It's not looking good for this. |
|
Could it be possible to extract the passing check/fingerprint from the pre-grapheneos flashed stock pixel and use that once grapheneos is installed? |
|
You can't pass the Play Integrity device integrity check with the stock Pixel OS fingerprint, etc. You need to pretend to be an insecure old device without hardware attestation or hardware attestation is required. There's no spoofing for the strong mode and the device mode is gradually moving towards closing the loophole of old devices without hardware attestation. Faking hardware attestation requires vulnerabilities, although those can be used to leak keys to reuse but they'll get blacklisted. |
|
Ah okay that sucks, thanks for explaining. Missing tap to pay is the only issue I have with GrapheneOS atm.. |
The way to work around it is to use a smartwatch that you pair to GrapheneOS. Can use Google Pay via the watch. |
|
It is quite upsetting what Uber Inc. is doing. As an Independent Driver and Business, it is our responsibility to secure and protect our hardware and software from any outside threats. By disabling GrapheneOS from their Maybe we need a lawyer to fight for small independent business's? It is absurd how Uber Inc is over stepping their boundaries and forcefully nesting their 3rd party services inside small business infrastructure. |
|
If Uber reads this, a minimal solution would be to add GrapheneOS to their They may do so here: https://grapheneos.org/articles/attestation-compatibility-guide |
|
They permit a device certified by Google running firmware/software which hasn't been patched for 5 years. It has nothing to do with security. It has to do with control. They don't want you to be able to use a modified variant of the app or a modified OS which changes how the app works. They could permit GrapheneOS via https://grapheneos.org/articles/attestation-compatibility-guide without losing any of the anti-tampering they're trying to use. They want to control their drivers and stop them modifying the app so they do this, which they could still do on GrapheneOS. There are 2 options: 1) they stop trying to exert control this way, 2) they use hardware-based attestation to support GrapheneOS per our guide with no loss of control over their drivers. |
|
Correction
The drivers are independent business's that do their own tax work. |
They're controlling what people can do with their personal devices which shows they're employees. Uber committing fraud to avoid employment laws and taxes is their problem. This is simply evidence of that. |
If that were true, then they would need to purchase our phones, vehicles and provide the necessary insurance and benefits. Their entire business model would collapse.. No thank you; I am responsible for my own Freedom. Please add GrapheneOS to your |
Doesn't sound like it if they get to decide which operating system you can use on your personal phone. |
|
I'm not seeing when this issue was closed, but evidently it's closed now, so I guess that means devs are no longer considering it? That's a shame. Even if the useful lifespan of spoofed CTS were limited, it would likely solve the problem of RCS messaging's instability on GrapheneOS: https://discuss.grapheneos.org/d/1353-using-rcs-with-google-messages-on-grapheneos/227. Especially since Apple is adopting RCS, and I believe it's becoming the default messaging protocol on all new Android phones, it seems like it would really align with Graphene's mission to adopt a widespread, extremely secure, open-source, E2EE messaging protocol. (While I don't know what's happening behind the scenes with the core dev team, I'm actually surprised RCS compatibility hasn't been a bigger goal so far.) And while there's clearly something at a system level that's interfering with Google Message's RCS provisioning, implementing CTS spoofing would be a much-welcomed stopgap to make RCS work until a more permanent solution is discovered. |
|
Something interesting to consider, that would solve all these problems might be the DMA from the EU. https://discuss.grapheneos.org/d/11424-could-eus-dma-facilitate-verification-of-alternative-os-like-grapheneos |
|
@e-t-l What is there to consider? Spoofing the strong mode is not possible. Spoofing the weak mode requires pretending to be an insecure, old device and will be cut off via their spoofing detection mechanisms when they see it happening at scale. What do you expect us to do? It's not feasible to do what you want. RCS works fine on GrapheneOS. It's not our fault if Google's RCS service has anti-spam partially based on only allowing a Google certified OS. Again, what do you expect us to do? What makes you think RCS is a well designed or secure protocol? It isn't a good protocol. It has a ton of unnecessary complexity and attack surface. Regardless, it works fine.
A temporary working lasting a few weeks until they block it due to wide scale easily detected spoofing where modern devices running an OS not certified by Google are clearly pretending to be old, insecure ones running a stock OS certified by Google. |
|
So what's the long-term solution here? It seems that the Uber Driver app, ChatGPT, Starbucks, American Airlines, Marriott, and a growing number of apps are using Play Integrity API and MEETS_DEVICE_INTEGRITY is the culprit? Are we going to be in a situation in 6-12 months time where that list of apps has grown even more? |
The long-term solution is those apps not using Play Integrity API, or whitelisting GrapheneOS via hardware attestation, for which we provide a guide for app developers: https://grapheneos.org/articles/attestation-compatibility-guide Alternatively, it could be ruled illegal, and apps could stop doing it based on that. Beyond that, there's nothing we can do. |
Yeah this is my concern. So far the apps that use Play Integrity API are not breaking my daily usage, I can live without them, but it might get to a point where more app developers use it, rendering my GrapheneOS device impractical for daily usage. |
|
People who care about alternative OSes should be pressuring these companies into dropping these meaningless checks. I understand that you're turning to us for a solution, but we're the wrong party to turn to, in this case. We aren't the ones imposing arbitrary restrictions. |
No I totally agree. I'm gathering information here so I understand this correctly. I didn't want to step on to my soap box if I were missing something, which it turns out I'm not. I'll do my part to highlight this and yes.... I agree with the meaningless checks part! |
|
There's one thing that's important to note here. None of these apps are blacklisting GrapheneOS. They're blacklisting everything that's not a Google-certified OS. This is important as it wouldn't make any sense to try to convince anyone if they'd already made the decision to specifically blacklist GrapheneOS. We're just essentially being ruled out along with every other non-certified OS based on these checks, not because we're lacking something these apps expect. |
|
In addition to us pressuring the companies, one can keep a topic label on
the forums to keep track of which have problems with a secure, non-Google,
OS, and periodically contact the European Comission/Federal
Government/EFF/FSFE in order to raise awareness.
It is my naive opinion this constitutes a constriction of the existence of
a single market, which seems to be highly valued by certain government
bodies as a necessity to achieve better market competition.
… Message ID: ***@***.***
com>
|
Totally agree, competition is absolutely hindered when some apps decide to restrict access to their service based on a false idea of security - even those that have no real purpose to "block" an "insecure" OS. |
|
Users contact us about it instead of bothering app developers and convincing them to implement https://grapheneos.org/articles/attestation-compatibility-guide. If you want apps to do that, you're going to need to make a concerted effort to bring it on their radar by having many people persistently contact their support, engineers, etc. on a daily basis until it becomes noisy enough for them to consider it. |
Where is their contact information or phone numbers; maybe I should go knock on their front door and ask them to speak with an engineer? 😄 They @uber Inc. make it so you have to know the developer and have the technical know how to even understand the issue..most of their support channels barely even know how to make use of a computer and we must jump through infinite hoops to even maybe be heard by an actual dev or engineer. I agree with @Segment0895
|
Expecting companies to allocate expensive developer time on an OS-specific implementation when an API that covers all stock android phones exists is a bit unrealistic, don't you think? |
|
@aly-k This API covers all stock Android devices that are remotely secure. Hardware attestation API is mandatory for devices launched with Android 8 or later. Only Android 12 or later have security support, and there's hardly any device launched before Android 8 that's still receiving actual security support since it would imply having updated to Android 12 or later. |
|
This is the standard Android API for this purpose instead of using a much less useful and secure Google Play API going through a Google service. This is hardly an OS specific implementation. Read the article. |
|
Apologies i am not a developer. From what i understand, Apps that use the play integrity API currently leave all the work of hardware attestation to google and they just check the returned pass/fail value. |
No, either way they need to verify a result on their server, whether it's a hardware attestation or a Play Integrity API service result. Verifying the stock OS with hardware attestation is not much different. Verifying alternate operating systems simply requires having a list of permitted key fingerprints for yellow boot state. The main work has been done for them via Google's key attestation library. |
|
Hmm, can't we use pKVM and virtualize some lightweight android to provide CTS checks for us? Or even to provide entire wallet experience? Like separate user profile for banking. |
Maybe. But that's probably a lot of dev hours, getting an unfair feature working, without knowing if corporate overlords would get annoyed with GOS and block GOS wrappers or something. Don't poke the bear. Honestly, I think this is better handled with a forum topic instead of commenting. I'd suggest closing the issue and blocking further posts. |
|
Yeah. I think that as well. But maybe link the forum post here. |
|
I suggest this topic to be moved to the forums Spoof CTS Profile checks in Play Integrity API checks. |
|
They can trivially block any spoofing we do because they submit GPU fingerprints, etc. and don't use them for direct enforcement but rather only to monitor spoofing and choose when to block it when it's being done at scale. They block it with primitive checks instead of the more advanced techniques like GPU fingerprinting right now, but they could start directly enforcing the more advanced techniques. It's not realistic to do anything about this in a production OS which needs to keep working properly. We could dedicate substantial development resources to spoofing it as part of sandboxed Google Play (which is more involved than spoofing it for privileged Google Play because a lot of what it tries to do fails permission checks, etc.) but then they can quickly block it and likely will. We have over 200k users in total, and if around half of them use sandboxed Google Play then that's going to trigger around 100k devices submitting spoofed basic integrity attestations which still fail strong integrity. Play Store does this itself to filter apps marked as requiring Play Integrity to avoid users giving bad ratings. |
|
Well point of pKVM wasn't really spoofing. It would be perfectly ok if we just get VM abstracted as separate user profile. That should look as any other android, be upgradable as one... etc. |
and others
This has to be non-invasive and minimal.
The text was updated successfully, but these errors were encountered: