They can check RootOfTrust and VerifiedBootState in the metadata. And since proper implementation will do the attestation on a remote device, we cannot fake it on device (unless we exploit TEE of course)
Conversation
There are two kinds of hardware keystores, both of which provide key attestation support. The traditional implementation uses the TEE, but newer generation devices like the Pixel 3 and some newer Samsung devices provide a StrongBox keystore implemented via a secure element.
1
3
SafetyNet attestation isn't a particularly strong use of key attestation. It performs validation of a massive number of devices at scale, without any kind of pairing in advance. That means they depend on verifying devices via the root certificate, which isn't high assurance.
1
1
3
Bypassing it doesn't necessarily require exploiting the TEE or SE on the device being checked, since there's no pairing with that specific device. An attacker could perform an attestation, modify verified boot state, and sign it with a valid batch key extracted from any device.
1
5
To bypass this kind of unpaired verification, an attacker only need a batch key from *any* device, not necessarily the one on the device being checked. That's why they have a way to revoke leaked/compromised keys:
android.googleapis.com/attestation/st
Unclear if SafetyNet checks revocation.
3
5
So, an attacker only needs to exploit the TEE on one device to get a batch key for faking unpaired attestations on any device. They can choose a device without updated TEE firmware.
The Auditor app (attestation.app/about) uses pairing rather than just verifying via the root.
1
1
If they notice a batch key was extracted and is being used to sign fake attestations, they can respond with revocation. Can see they've already revoked keys at android.googleapis.com/attestation/st. This is good enough for things like anti-cheat or DRM, but real security checks need pairing.
1
3
Ideally, they would improve key attestation with better support for the pairing approach. Pairing is well suited to device manager workflows where there's already a propositioning step. At the moment, the cert for the app's key is directly signed with the provisioned batch key.
2
1
It allows securely checking the patch level, etc. of the device after the initial pairing, which has a lot of use cases. Checking solely based on a root provides very low assurance since an attacker can choose any device, avoid updating the firmware and eventually compromise it.