This was my response to questions on the purpose / use cases for Auditor and AttestationServer: gist.github.com/thestinger/ed1. I plan to extend attestation.app/about into a better overview along with covering more than just operating the app and service in attestation.app/tutorial.
Conversation
Auditor / AttestationServer don't aim to prevent a compromise, which is the focus of GrapheneOS itself. Rather, they aim to provide a rigorous approach to device monitoring aimed at a past or current compromise. The foundation is a pairing-based approach to hardware attestation.
1
I have a very clear threat model in mind for them, and while I clearly split the information into hardware verified and software verified (i.e. obtained by the app), the software verified information does have a threat model and cannot simply be faked with a modified app / OS.
1
The ability to chain trust to the app and reliability monitor the patch level of the OS are the foundation for the software-based checks. An attacker that has exploited the OS and currently has root can fake information obtained by the app, but not the core portion from hardware.
1
1
Since it doesn't allow them to fake the verified boot hash (for identifying a specific release) or patch level, they cannot hold back the updates with security bug fixes and broader security improvements without this being revealed. The app aims to uncover persistent compromise.
Replying to
The software-based checks are focused on persistence mechanisms bypassing the need to exploit the OS each boot. This part of the app is currently very limited due to the app sandbox. The plan is to offer the option of it being a device admin along with GrapheneOS integration.
1
Auditor / AttestationServer are definitely not magic security pixie dust. They won't make your device more resistant to compromise. They only aim to uncover a compromise. The capabilities will heavily depend on improvements to the hardware attestation support, verified boot, etc.