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.
Replying to
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
Auditor has a challenging task with a difficult security model. The core functionality depends entirely on the hardware, firmware and OS security model / features. Other than expanding app attested information, it depends on improvements in hardware and OS releases to get better.
1
1