|
|
|
|
|
by TSUTiger
691 days ago
|
|
Off twitter/x you miss the tweet quoted reply[1]: The article unfortunately leaves out most of the points we made in the thread. GrapheneOS supports hardware-based attestation and it's entirely possible for Google to allow it as part of the Play Integrity API. They choose to ban using GrapheneOS. [1]: https://nitter.privacydev.net/GrapheneOS/status/181841539179... |
|
But hardware-based attestation is fundamentally based on a whitelist of OS images. With AVB, the only job of hardware is to validate that the chain of trust starts with the certificate the user provides (or the factory default). That certificate, if controlled by a trusted party, attests that the resulting chain of trust implements the Android security model correctly. But all the Android API does is provide a verifiable attestation of what is running; it can't attest that Android hasn't been e.g. Magisk'd and then re-signed. (Please correct me if I'm wrong here!)
Google trusts themselves, of course, perhaps too much. But, they're unwilling to add others to the whitelist of things they trust. I think what you're asking for, is actually for the Play Integrity code to have some mechanism to become trusted/whitelisted (this would prevent other app devs from having to play whack-a-mole to allow other secure images). Phrasing it that way might be a good clarification.