Auditor: Hardware-based attestation/intrusion detection app for Android devices
The Auditor app uses hardware-based security features to validate the identity of a device, along with the authenticity and integrity of the operating system. It ensures the device is running a verified operating system with a locked bootloader and that no tampering has occurred. Auditor will also detect a downgrade to a previous operating system, patch, or app version. Auditor extends the hardware-based operating system verification by chaining verification to the app, performing software-based sanity checks, and gathering additional information about the device state and configuration beyond what hardware attestation directly provides.
The foundation of the Auditor app is generating a persistent key in the hardware-backed keystore for verifying the identity of the device and providing assurance that the operating system hasn’t been tampered with or downgraded via verified boot. It performs a pairing process between the device performing verification (Auditor) and the device being verified (Auditee) to implement a Trust On First Use (TOFU) model. The device performing verification can either be another Android device running the app in the Auditor mode or the https://attestation.app/ service for automated verification on a regular schedule with support for email alerts. See the tutorial for usage instructions. The protocol used for both local and remote attestation is documented in the source code.
Verified boot validates the integrity and authenticity of firmware and the entire operating system (both the kernel and userspace) from an immutable hardware root of trust. The results are passed along to the hardware-backed keystore and used to protect the keys.
The key attestation feature provided by the hardware-backed keystore provides direct support for attesting to device properties and bootstrapping the Trust On First Use model of the Auditor app with a basic initial verification chained up to a known root certificate. The latest version of key attestation provides a signed result with the verified boot state, verified boot key, a hash of all data protected by verified boot and the version of the operating system partitions among other properties. It also has support for chaining trust to the application performing the attestation checks, which is used by the Auditor app for bootstrapping checks at the software layer.
Devices shipping with Android 9 or later may ship a StrongBox Keymaster implementation, allowing the Auditor app to keep the keys used by the attestation protocol in the dedicated Hardware Security Module (HSM) (such as the Titan M in Pixel devices) rather than using the Trusted Execution Environment (TEE) on the main processor. This can provide substantial attack surface reduction.
Security enhancements offered by future generations of hardware and future Android releases will be closely tracked by these projects. The core workflow and feature set is already implemented but the foundation will be regularly improved along with major improvements to the user interface and documentation. The app and service are designed to be forwards and backwards compatible via a versioned protocol to permit substantial changes down the road.
Install & Use
Copyright (c) 2019 Daniel Micay
