Conversation

So here we go, after years of fun messing around using Magisk, it seems that Google FINALLY decided to "fix" SafetyNet to something useful, and that is to use key attestation to verify device status (after 3 years since introduced to Android's platform!)

255

816

Replying to

very interesting. Do you have more details on which part of the "device status" are they checking with attestation? I'm curious about how TEE can retrieve info about the overall system in a "trusted" / non hackable way

Replying to

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)

Replying to

and

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.

Replying to

and

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.

Replying to

and

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.

Replying to

and

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.

1:22 PM · Mar 11, 2020Twitter Web App

Replying to

and

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.

attestation.app

Auditor overview

Overview of the Auditor Android app and associated service.

Replying to

and

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.

Show replies

Replying to

and

I know that in the case of Intel's SGX, the key was exposed with a hardware issue (Foreshadow), and they revoked the key after they released a microcode update fixing it. Maybe there is something similar in the mobile world I guess?

Replying to

and

If I understand this, only one batch (so should be <100k devices), had actual fault, and not just "oops i sent my keys to the wrong person", in the last three years? They really aren't revoking eagerly