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.
Conversation
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
Hardware-based attestations are verified on the device performing verification via the pinned attestation certificate chain. The app id and signing key are verified as part of verifying the hardware attestation information. App attested info is an Auditor-specific thing added on.
1
It includes the hardware attestation (certificate chain) and the app attested information in the message, and it signs the overall message with the hardware-backed key used for pairing. The main thing I want them to improve is adding a dynamic cert to the attestation cert chain.
1
The hardware-based attestation used by Auditor also has 2 mechanisms: the signature from the hardware-backed key used for the initial pairing (the fact that the signature can be made provides a lot of guarantees) and fresh key attestation verified using pinned attestation chain.
Reliance on pinned attestation certificate chain is primarily for the OS patch levels, since it's dynamic information not provided by simply knowing that the hardware-backed key can still be used for signing by the app. Same will apply to other dynamic information as it's added.
1
Ideally, the keystore would dynamically generate a certificate specific to the app for signing the public key certificates, and this would chain to the existing attestation certificate chain. This would avoid relying on a key provisioned on batches of devices which would be nice.