I couldn't understand why there were so many attempts to submit attestation samples with my Auditor app (attestation.app/about) on devices with broken hardware-backed keystores. It turns out that people are breaking it and then using my app to diagnose.
github.com/GrapheneOS/Aud
Conversation
For the TEE-based keystore, the attestation keys provisioned for the device in the factory are encrypted with the hardware-bound TEE key and stored encrypted in the persist partition. Some users are wiping / replacing the persist partition on unlockable devices and losing them.
1
1
Some examples on XDA: forum.xda-developers.com/showpost.php?p, forum.xda-developers.com/xperia-xz1-com.
It's an interesting way for the app to be promoted. In these threads, people are mostly using a modified variant aimed at debugging with the security model removed. Some are still using the original though.
1
2
StrongBox keystore on the Pixel 3 has separate attestation keys, and I think they're burned into the Titan M security chip rather than encrypted with a hardware-bound and stored elsewhere, so this kind of issue can't happen. Similar to how StrongBox uses internal key storage.
Replying to
TEE-based keystore approach doesn't have any practical limitation on the number of stored keys, since it delegates storage of the hardware encrypted keys to the OS. That's why good TEE keystore implementations need to provide rollback resistance for keys.
2