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.
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.
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
One of the main gaps in my understanding disappeared after realizing that the auditor app does not use a rotating Attestation key.
The whole protocol makes a lot more sense to me now.
Essentially, a potential attacker CANNOT just use any leaked attestation key AFTER initial setup. They would need the SAME key to forge an attestation statement.
I agree with your point but would appreciate a transparent and open way for other OSes and devices to be accepted on the #AttestationApp / #Auditor.
So that it becomes less of a #GrapheneOS-only tool.
I have used other Androids on a Pixel with locked bootloader but their hash was not in your database so there was zero information to see for me. Apparently, multiple users could try to authenticate an OS and then there would be a chance for you to add it.
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?
@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?
@pixelschubsi That would be a very reasonable approach but handing over control to Volla definitely isn't, especially considering they pull stuff like this:
GrapheneOS
S1m
opinonToo
hupf
Henning
🅱🅻🆄🅴🅱️
Xtreix