https://arstechnica.com/gadgets/2024/07/loss-of-popular-2fa-tool-puts-security-minded-grapheneos-in-a-paradox/

The article unfortunately leaves out most of the points we made in the thread.

GrapheneOS supports hardware-based attestation and it’s entirely possible for Google to allow it as part of the Play Integrity API. They choose to ban using GrapheneOS.

Play Integrity API has no minimum security patch level and nearly all these apps use weak software-based checks that are easily bypassed by attackers. The hardware-based checks rely on trusting every key distributed to every certified Android device, which are often leaked.

Hardware-based attestation can be used for security purposes such as verifying device integrity with a pinning-based approach without the weakness of being vulnerable to leaked keys from the whole Android ecosystem since specific per-app keys in the secure element can be pinned.

Play Integrity API is claimed to be based on devices complying with the Compatibility Test Suite and Compatibility Definition Document. We have irrefutable proof that the majority of certified Android devices do not comply with the CTS/CDD. Play Integrity API is based on lies.

Essentially every non-Pixel device has important CTS failures not caused by CTS bugs. OEMs are cheating to obtain certification. Google claims GrapheneOS can’t be permitted because we don’t have a certification where they freely allow cheating and don’t ban non-compliant devices.

Since Play Integrity doesn’t even have a minimum security patch level, it permits a device with multiple years of missing patches. Hardware attestation was required on all devices launched with Android 8 or later, but they don’t enforce it to permit non-compliant devices.

The reality is that the Play Integrity API permits devices from companies partnered with Google with privileged Google Play integration when they’re running the stock OS. It’s easy to bypass, but they’ll make changes to block it being done at scale long term such as if we did it.

It does not matter if these devices have years of missing security patches. It doesn’t matter if the companies skipped or improperly implemented mandatory security features despite that being required by CDD compliance. Failing even very important CTS tests doesn’t matter either.

Google can either permit GrapheneOS in the Play Integrity API in the near future via the approach documented at https://grapheneos.org/articles/attestation-compatibility-guide or we’ll be taking legal action against them and their partners. We’ve started the process of talking to regulators and they’re interested.

We’re not going to give Google veto power over what we’re allowed to do in GrapheneOS. We comply with CTS and CDD except when it limits our ability to provide our users with privacy and security. Google wants to be in charge of which privacy/security features can be added. Nope.

Google’s behavior in the mobile space is highly anti-competitive. Google should be forbidden from including Google Mobile Services with privileged access unavailable to regular apps and services. GrapheneOS sandboxed Google Play proves that hardly anything even needs to change.

Google should also be forbidden from participating in blocking using alternate hardware/firmware/software. They’ve abused their market position to reinforce their monopolies. They’ve used security as an excuse despite what they’re doing having no relevance to it and REDUCING it.

Google is forbidding people from using a growing number of apps and services on an objectively far more private and secure OS that’s holding up much better against multiple commercial exploit developers:

https://grapheneos.social/@GrapheneOS/112826067364945164

They’re holding back security, not protecting it.

We’ve put a lot of effort into collaborating with Google to improve privacy and security for all Android users. Their business team has repeatedly vetoed even considering giving us partner access. They rolled back us being granted security partner access by the security team.

As with how they handle giving out partner access, the Play Integrity API serves the interests of Google’s business model. They have no valid excuse for not allowing GrapheneOS to pass device and strong integrity. If app developers want to ban it, they can still do it themselves.

After our security partner access was revoked, we stopped most of our work on improving Android security. We continued reporting vulnerabilities upstream. However, we’re going to stop reporting most vulnerabilities until GrapheneOS is no longer blocked by the Play Integrity API.

This year, we reported multiple serious vulnerabilities to Android used by widely used commercial exploit tools:

https://source.android.com/docs/security/overview/acknowledgements

If Google wants more of that in the future, they can use hardware attestation to permit GrapheneOS for their device/strong integrity checks.

Authy’s response about their usage of the Play Integrity API shows their service is highly insecure and depends on having client side validation. Play Integrity is thoroughly insecure and easily bypassed, so it’s unfortunate that according to Authy their security depends on it.

If Authy insists on using it, they should use the standard Android hardware attestation API to permit using GrapheneOS too. It’s easy to do:

https://grapheneos.org/articles/attestation-compatibility-guide

Banning 250k+ people with the most secure smartphones from using your app is anti-security, not pro-security.

It’s very unfortunate when new apps adopt the Play Integrity API and stop working. Authy isn’t a very good choice for 2FA but many people use it and it’s a problem for us for a widely used app to be incompatible. A single widely used app losing compatibility is a big deal to us.