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.
Conversation
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.
1
1
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
In other cases, of course, it's useful to have an actual key at the leaf position, which you can then use to sign other info, etc.
1
The Auditor protocol is documented at github.com/GrapheneOS/Aud. It keeps the key generated in the initial pairing and uses that to sign each message to verify the pairing identity and other data. It doesn't really need a leaf key for the attestations it performs after the pairing.
1
1
It pins the certificate chain used to sign the persistent key and then enforces that future attestations have the same certificate chain. It discards the temporary keys created to generate the future attestations but it's actually convenient for it to work like the initial one.
Makes sense. So you would probably use a "platform attestation" (what I'm currently calling the notion) rather than a "key attestation" for those post-pairing attestations. You'd obviously need a key attestation for the key that signs those, though.
1
I should mention that there are actually a lot of use cases for an app-generated attestation key, not just Auditor. It addresses many problems in many contexts. I don't recall whether the initial idea came from you, . It might have!
1
Show replies