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.
Android's hardware attestation API is problematic for a free and open market because it supports root-based attestation. However, it does at least support choosing arbitrary trusted roots and arbitrary trusted operating systems. It isn't locked to Google's roots or stock OSes they certify.
We made a proposal to Google for pinning-based attestation support for Android hardware attestation and they ended up implementing it. It can be used in combination with root-based attestation or without it. It doesn't have the anti-competitive properties and provides far more actual security value.
Root-based attestation trusts the whole hardware attestation ecosystem. Leaked keys from any device can be used to bypass it. Pinning-based attestation starts trust from first use and then provides a high level of security based on the security of the device's early boot chain and secure element.
Root-based attestation is mainly used to disallow an arbitary device, OS or modified app for control rather than security. Pinning-based attestation lacks those negatives and can be very secure. It can be bootstrapped by root-based attestation but it works without it and it's not the only approach.
@GrapheneOS do you have links to more information on pinning-based attestation? It is important to point app devs to it in order to avoid attestation by play integrity api.

@GrapheneOS

Is there an in-depth blogpost that lays how you define root-based vs pinning-based attestation?

I'm trying to understand the argumentation why root-based attestation is considered bad and why pinning-based attestation is better.
I've been going through the auditor app's about page and some of your comments in the source code, but I'm failing to understand the difference between root-based vs pinning-based attestation, so far.

From my PoV Auditor just uses the standard Android app attestation (in a neat way). Is there anything specific that libraries like Warden do differently architecturally, something that you consider being problematic?
Or do the approaches distinguish themselves, mostly by the threat model instead?

Tbf, I really just started looking more deeply into how attestation works on Android the other night, so please excuse my ignorance. I just can't seem to find a good resource that explains the differences between the approaches.

@GrapheneOS
I also want to be up-front about it and disclose that I do know people involved in the Warden library.
@hupf There's a clear difference between verification via chaining to a root of trust where a leaked key from any device can be used to bypass it and it can be used for anti-user control vs. generating a key in the secure element for signing attestations which is pinned. Auditor combines both together but is primarily based as pinning-based attestation. Your earlier posts show you don't have a good understanding of Android hardware attestation with or without the attest key feature for pinning.
@GrapheneOS
Yep that's true. I really didnt (and dont yet). Thanks for the learning opportunity. Im gonna try and change that
@GrapheneOS I use Graphene / Nitrokey phone. Is there a site I can go to to learn about this stuff - like, what is pinning, etc.? Thank you.

@GrapheneOS

What do you feel is the culture or climate for Google when it comes to allowing others to utilize Android?

Do you feel they are conflicted? It sounds like they are still working with you which is good, but that they are equal parts working against you. That's vague, but hopefully makes sense.

Do you think the culture is supportive of your work? That they are resisting the capture of Android as a purely extractive operating system?

@GrapheneOS I haven't seen you post about unified attestation for days. I was beginning to worry you'd changed your mind. How am I supposed to know your thoughts on unified attestation if you don't post about it daily?
@GrapheneOS The above is a joke, GrapheneOS is an awesome project.
@migam830 We'll stop posting about it after it's discontinued.