Initial release of my Auditor app as an independent project: github.com/AndroidHardeni. It's also available on the Play Store as a free app: play.google.com/store/apps/det.
It provides hardware-based integrity and identity verification for a gradually expanding set of supported devices.
Conversation
Replying to
"It cannot be bypassed by modifying or tampering with the operating system (OS) because it receives signed device information from the device's Trusted Execution Environment (TEE) including the verified boot state, operating system variant and operating system version."
2
1
Replying to
I can read. However, tools like Magisk (github.com/topjohnwu/Magi) can spoof build properties - which seem to be at least part of your attestation - and other system state, what makes the trusted environment APIs invulnerable to scenarios like that? Genuinely curious.
2
These techniques seem to be sufficient to get around Google's own device attestations, after all.
1
Replying to
My Auditor app implements hardware-based attestation, not software-based attestation like SafetyNet where an attacker controlling the kernel / OS can simply spoof the expected values. SafetyNet doesn't fail based on key attestation results and doesn't do any kind of pairing.
1
If you want a better understanding of how it works, read the technical documentation in the sources: github.com/AndroidHardeni.
Rootkits at the kernel / OS level cannot fake signatures from the hardware-backed keystore. An attacker has to compromise the hardware keystore for that.
Replying to
I see - You say '[it]...cannot be bypassed without exploiting either the TEE or bootloader' - how would a compromised bootloader be able to work around this?
1
Replying to
Exploiting the bootloader as it verifies the OS and then passing a fake result for the verification process to the TEE. The hardware-backed keystore would still be verifying the identity of the device but it would be attesting to a fake value from the compromised bootloader.
1
Show replies
Compromising the late stage bootloader during the verified boot process would also work since a fake verification result can be passed to the TEE. Either way, an exploit of the firmware is required. It's possible to fake UNPAIRED attestations with a leaked key but this app pairs.