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.
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.
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
Show replies
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.
1
Show replies