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.
The security model for app attestation information didn't require android:useEmbeddedDex but it was tied to uncovering compromise after an OS upgrade. It's definitely still not perfect and it's a much different level of security than the directly hardware attested information.
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
Show replies