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
Replying to
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
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