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.
Conversation
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.
1
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
There's a good chance it was me since I remember advocating for having a feature like that very early on. I had an eye on key attestation since it was announced, which was long before it became available, and I planned out how Auditor would work with pairing, etc. before then.
Agreed, there is a good chance it was you. There are enough other use cases -- and my memory is bad enough -- that I can't be certain. In any case, thanks!