Mastodawn

GrapheneOS 3d ago

If apps are required to verify the hardware, operating system and their app for regulatory reasons they should use an approach supporting arbitrary roots of trust and operating systems. Android already has a standard hardware attestation system usable for this.

Android's documentation and sample libraries are biased towards Google by using them as the only valid root of trust and the API is biased towards stock operating systems but it's better than a centralized API.

https://infosec.exchange/@rene_mobile/116286110700616525

GrapheneOS 3d ago

Apps should only resort to this if they're forced to do it. Root-based attestation provides minimal security and is easy to bypass. It's inherently insecure due to trusting the weakest security systems. A leaked key from the TEE/SE on any device can be used to spoof attestations for any device.

Play Integrity permits a device with years of missing security patches. It isn't a legitimate security feature. It checks for a device in compliance with Google's Android business model, not security.

GrapheneOS 3d ago

Unified Attestation is another anti-competitive system putting companies selling products in control of which devices and operating systems are allowed to be used. As with the Play Integrity API, it's a phony security feature existing solely to get their products permitted while disallowing fair market competition.

@GrapheneOS Are you talking about https://uattest.net/? I had a glimpse at it, and they talk about multiple backends and federation of backends. As I understood it, everyone can create a backend and create tokens for devices/OS that they like, it's then subject for the app developers to accept those tokens, either directly or indirectly through federation. Which means it does allow for competitor OS to also be accepted for as long as the app developer or their selected backends support it.

Unified Attestation

Unified Attestation is a free, open-source alternative to Google Play Integrity with offline verification and simple app + server integration.

pixelschubsi 1d ago

@GrapheneOS Notably, if you worry about old and insecure devices (like those still accepted by Play Integrity) as an app developer your just need to make sure to use a backend that would not sign them off. Which may well be one that's not the hardware manufacturer. I see Unified Attestation more as a decentralized/federated version of Play Integrity that gives app developers control to decide which devices, operating system creators or third-party attestors they trust.

pixelschubsi 1d ago

@GrapheneOS As an app developer that needs to take care of this, I don't want to open the https://grapheneos.org/articles/attestation-compatibility-guide page and copy out the fingerprints for those various devices out and update my local copy of them whenever a new device is supported by GrapheneOS. I just want to have a way to say "I trust whatever GrapheneOS guys consider safe". In understand Unified Attestation could be that way (if GrapheneOS was to provide a backend for it).

GrapheneOS attestation compatibility guide

Guide on using remote attestation in a way that's compatible with GrapheneOS.

GrapheneOS

GrapheneOS 1d ago

@pixelschubsi That's a misrepresentation of the alternative to putting Volla, Murena and iodé in charge of which devices and operating systems are allowed to be used. It would be entirely possible to distribute signed lists of verified boot key fingerprints for use with a library using the Android hardware attestation API. It would also be possible to distribute alternative roots of trust. Why should there be another API layered on top of it controlled by these for-profit companies attacking us?

pixelschubsi 21h ago

@GrapheneOS Well, I guess those lists would need to be updated regularly, so there's need to do that automatically. And you might want to go further than just the fingerprint (e.g. compare security patch level against what it should be). Of course all of these could be provided in an openly standardized API and then the verification is done at the app server, but that increases complexity for the app developer.

pixelschubsi 21h ago

@GrapheneOS If things are openly standardized I wouldn't consider them controlled by the author anymore. In the end, what app developers verify is some JWT with a few standardized fields, signed by whoever they decide to trust. Even if the Unified Attestation authors were to intentionally act malicious, as long as GrapheneOS would be able to provide such JWT, it could be compatible with the system and allow app developers to easily accept GrapheneOS devices.

GrapheneOS 1d ago

@pixelschubsi The companies behind Unified Attestation are heavily misleading people about what they're doing and we've already provided a detailed response debunking it.

You should read https://grapheneos.social/@GrapheneOS/116239523775374959 and stop promoting this anti-competitive garbage from companies which are actively attacking the GrapheneOS project and our team.

Android already has a hardware attestation API open to permitting anything which is literally what they're using to make an anti-competitive system on top.

GrapheneOS 1d ago

@pixelschubsi Here's a thread documenting attacks made by Volla on GrapheneOS from a sockpuppet account which they've clearly shown belongs to one of them:

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

We know which employee at Volla this account belongs to based on their specific writing style and unique attacks. They were involved in Volla reaching out to us where it was clear they were unable and unwilling to meet our requirements so it didn't go anywhere. This account posted non-public info about that.

GrapheneOS 1d ago

@pixelschubsi Why do you think it makes sense for a company using sockpuppet accounts to promote themselves and attack GrapheneOS to be in charge of which devices and operating systems people are allowed to use?

The two other companies they've named as being involved in it have been attacking the GrapheneOS project with fabrications for years.

Why not simply use the standard Android hardware attestation API rather than an API layered on top of it which exists to put them in control of it?

pixelschubsi 21h ago

@GrapheneOS As I said, the standard hardware attestation API bears to much work on the app developer. That's the reason why everyone uses Play Integrity and not directly hardware attestation, even though doing so could provide much better security (as old and insecure devices can be kicked out). Some app developers would go as far as adding GrapheneOS next to Play Integrity, but that's a minority and that also doesn't improve security for them (because they still accept Play Integrity).

pixelschubsi 21h ago

@GrapheneOS The Unified Attestation system would make things easy for all developers and is not tied to a single trust root. You can use the system entirely without trusting Volla or any if the other companies currently involved. In fact, as I understand, Volla at most wants to be a trust root for their own devices.

pixelschubsi 21h ago

@GrapheneOS But for the system to work and be adopted as an alternative to Play Integrity and to be able to entirely replace it, one would need independent trust root(s) for the majority of secure devices (e.g. all the Samsung phones people actually have). As these trust roots would no longer be bound to GMS certification (which is what Play Integrity is essentially about), they could even have GrapheneOS in it (and there's no good reason why it wouldn't).

pixelschubsi 21h ago

@GrapheneOS What confuses me is that you're making a huge effort to argue against Unified Attestation when at the same time, you could build something that's compatible with it (don't need to use their source, just their openly specified API) and profit from someone else promoting an alternative to Play Integrity that is compatible with GrapheneOS through your independent backend. If this gets adopted by apps and you have a backend for it working, your users will be able to profit from it.

GrapheneOS 15h ago

@pixelschubsi It makes absolutely no sense to use an API which solely exists for them to gain centralized control over attestation. Android already has a far superior hardware attestation API. Unified Attestation is entirely built on top of the standard API. It serves no valid purpose, and contrary to the inaccurate information you're peddling does not require more complexity or manually choosing which keys to allow. Your claims are inaccurate and you're basing them on their false marketing.

GrapheneOS 15h ago

@pixelschubsi Apps adopting it would not work with GrapheneOS unless they went out of the way to allow it. That's a worse situation than them using the Android hardware attestation API and permitting GrapheneOS through it. Contrary to your inaccurate claims, that doesn't at all imply manually adding each of our verified boot keys. There's no reason there can't be a signed JSON file listing out our verified boot keys. There's no reason organizations can't make a larger signed JSON file with more.

pixelschubsi 13h ago

@GrapheneOS sure, but not even you provided such a signed JSON file listing all your keys. If you think that Unified Attestation is bad, please go ahead and solve the issues it tries to solve that you didn't solve yet. If you specify and establish an open standard format for a signed JSON file that lists keys, a standardized API to retrieve and update it, that would be great as a starting point, so that others can build libraries and server software to ease verification of devices.

GrapheneOS 12h ago

@pixelschubsi That would be a very reasonable approach but handing over control to Volla definitely isn't, especially considering they pull stuff like this:

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

@pixelschubsi @GrapheneOS UA is useless, is a illegal cartel, and is yet another way to create a centralized authority under the excuse of being open-source, and to top it all off, it has been set up and is supported by completely untrustworthy for-profit companies that users should never rely on. UA is unusable, and its existence is not acceptable.