If I'm not mistaken, Safetynet's security relies on all the ecosystem's TEE safety, not just Pixels. Once one is broken, everyone using Magisk (or whatever) can jump on this private key+fp. And from my lengthy experience, Android doesn't spend time towards its ecosystem's safety.
Conversation
1
2
Of course, but will Google actually revoke them?
Say you have a security flaw in Qualcomm's bootloader, will Google revoke every single Qualcomm device?
When (not if.) that happen, will they close their money-maker Google Pay to 100M+ customers?
2
2
12
Yes, we will revoke them. If the keys are leaked, we'll revoke them. If the firmware has an unrecoverable flaw, we'll revoke them. If the firmware has a flaw that can be fixed via OTA, we'll analyze the situation to decide if that is adequate.
7
6
28
fredericb.info/2020/06/exynos claims they have access to Galaxy S8's Secure World, which launched with Nougat, so I guess it has key attestation? Has it been revoked yet?
1
2
AFAIK, there's no evidence of a practical method to extract the private attestation key, or subvert attestation. It seems likely that those things could be done, but I don't think they have been done.
1
1
Keep in mind that the goal of attestation is to provide a commercially-useful signal of integrity, not an absolute guarantee -- which would be impossible.
2
2
I should probably write a blog post about attestation key revocation, explaining the goals and, therefore, the conditions under which revocation makes sense. Publication of a private key is a no-brainer, as is evidence of large-scale abuse.
3
3
FWIW, we're working on a new approach (first CLs should appear on AOSP next week) which shifts to a TCG DICE-like mechanism for authenticating devices so we can remotely provision attestation keys. It will take some years to fully roll out.
2
3
10
Revocation lists for attestation keys will be a thing of the past; instead we'll remotely provision short-lived (e.g. 30 days) attestation keys. If a device model has a serious known vulnerability, we'll just refuse to provision to it.
3
4
Hopefully the update mechanism doesn't depend on Play Services, since right now the keystore attestation feature fully works without it and doesn't require making a new implementation of a service for keeping it working.
As an existing example that's related to the keystore, U2F / FIDO2 is implemented in Play Services rather than AOSP even though it's not a Google service. I would have expected it to be an app in AOSP with a Google variant updated via the Play Store. These attestation key...
1
... updates sound like they would be done via a Google service making it natural for it to end up in Play Services, so what I'm hearing is that hardware-based attestation might stop being fully available via AOSP which would be unfortunate. Hopefully not what will happen though.