Auditor and AttestationServer split the user-facing information from device verification into 2 sections: hardware attested and OS / app attested. The information from the hardware cannot be tampered by an attacker that has gained root / kernel access in the OS via exploitation.
Conversation
OS / app attested information builds upon verified boot authenticating the firmware, kernel / device tree and base userspace OS. The intention is an attacker can't tamper with this weaker subset of information without exploiting the OS and gaining root/kernel in the current boot.
1
2
Auditor version is directly from hardware attested information, as are the non-user-facing app id and signing key fingerprint fields. The rest of the OS/app attested information depends on trust being chained to the app and useEmbeddedDex eliminates semi-persistent trusted state.
1
1
2
The TEE/HSM obtains OS patch level(s) in early boot and attests to it directly, so an attacker successfully exploiting the OS each boot cannot hold back upgrades without Auditor / AttestationServer detecting it. This is part of the security model for chaining trust to the app.
2
1
Replying to
is the application attestation secure against an attacker with persistent privesc via a priv-app with the DEX residing on /data?
1
Replying to
A priv-app can't do anything that would compromise the security model. It depends on core components of the OS including system_server, which haven't been allowed to run code from /data for quite some time. Trust in persistent state has also been dropping with each OS release.
2
Replying to
which SELinux roles are required to obtain an attestation for an arbitrary application?
1
Replying to
Hardware-based attestation is tied to hardware-backed keys so you can only do it for your own app via your own hardware-backed keys. Another app could supply you with the certificate chains needed to perform attestation for it though. I might be misunderstanding what you mean.
2
Replying to
which SELinux roles do i need to forge attestations for any installed app? e.g. is citadel_device:chr_file sufficient or do i need keystore_data_file as well?
1
Replying to
I don't think either of those would help with that. If you control system_server and the HAL processes involved in obtaining attestations, you could substitute them with your own, but the security model for hardware-based attestations doesn't trust the OS not to tamper with them.
3