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.
Conversation
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
Batch keys aren't unique largely for privacy reasons. Ideally, they would generate a internal key for the app when it requests attestation, and use that as an extra link in the signing chain for all the attestations by the app. The key would get cleared when app data is cleared.
1
1
Current implementation:
app's keystore key -> batch -> intermediate -> root
Improved approach for pairing:
app's keystore key -> internal key for the app -> batch -> intermediate -> root
1
1
Then, this extra internal key would be pinned as part of the pairing, and allows strongly verifying future attestations from the app. Even if an attacker compromises the batch key on another device, attestation with a Trust On First Use pairing system would still remain secure.
The new key type needed to make this possible in keymaster has been on our to-do list for a while. It narrowly missed being added in R. I expect it should land in S (but don't count on it until you see the feature in a dev preview).
1
2
Question for you Daniel: Would you actually need a key at the leaf of this chain? Many uses of attestation don't use the attested key, they just want platform status info that is known to be fresh. Having the "internal key for the app" sign the RootOfTrust info would do that.
1
Show replies