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.
Conversation
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
Replying to
i might be misunderstanding — the hardware keystore doesn't know which application is making the request unless the system tells it. i'm wondering what the attack surface of application ID attestations is, i.e. which SELinux domains can forge the application ID
1
Replying to
Ah, I understand what you were asking now. It's primarily system_server, the core OS underlying that and the HALs for the keystore implementation. There's no way for a priv_app to fake something like that since they don't get special hardware access or anything like that.
The SELinux domain for priv_app doesn't add that much. One of the main things it provides is the ability to communicate with the underlying update system (update_engine or recovery). They also get to use privileged permissions, but only ones explicitly whitelisted for the app.