[Retr0id]

A hypothetical useful use of attestation is that a company promising to process personal data securely could actually prove it to end-users, by open-sourcing their server-side code and using reproducible builds combined with remote attestation, to prove to the client that the server-side is running unmodified within a secure enclave.

I struggle to think of a useful use for it on the end-user client side, though.

[jt2190]

Isn’t the client-side case something like “the banking app you’re entering your account password into is the binary the bank created and not a compromised binary that will drain your bank account”?

[Wicher]

This is kind of already the case on Android.

If you've installed RealActualBankApp (with the ID of real.actual.bank.app) once (from whatever source!) then there cannot be another app installed with that same id but signed with a different public key (oversimplified version of the story, there is a key rollover scheme).

You can however install an imposter app that's also called RealActualBankApp, with the same icon. It'll need to go by a different ID.

So then we're down to the same problem, or pseudo-problem, of identity confusion, as we have for banking website URLs. Where is the ID/URL shown, and does the user know that it should be mybank.com and not mybank-incorporated.com ?

[Retr0id]

Android Key Attestations are bound to the app that minted the key, so this does prevent a fully-functional clone from working if they use attestation during auth. But it doesn't prevent a fake app that only exists to phish credentials.

[summm]

No, this would just require a publicly verifyable signature of the software, and the user would just choose to have their operating system verify it. No remote attestation or other hand-over-your-controls necessary.