Mastodawn

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

Show thread

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.

Show thread

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.

Show thread

pixelschubsi 1d ago

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

Show thread

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.

Show thread

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

Show thread

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?

Show thread

pixelschubsi

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