A long overdue feature for Auditor in Android 10:
github.com/GrapheneOS/Aud
Documentation:
developer.android.com/topic/security
Auditor uses the hardware-based attestation feature to chain trust to the app through the OS based on it providing the application id and signing key fingerprint.
Conversation
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.
1
1
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.
If you perform attestation and use it to chain trust to the app, it becomes useful to obtain and send information from the OS though, which is what Auditor is doing. It signs it with the hardware backed key and sends it along with the hardware-based attestation for that key.
1
So, you could perform an attestation chaining trust to your own app and then check the application id and signing key of another app which could be considered performing attestation for it. This is essentially what Auditor is doing for accessibility services / device managers.
1
Show replies
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
Show replies