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

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.

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 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.

@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.

@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?

@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).
@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.
@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).
@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.
@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.
@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.
@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.

@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