I've been attempting to learn about Auditor, attestation and firmware/hardware root of trust.
Could attestation done Pixel to Pixel with Auditor re-establish root of trust in Pixel hardware and firmware in these scenarios?
1) I buy a used, supported Pixel, properly flash GOS, do a device-to-device attestation with Auditor.
1b) I buy a used, supported Pixel, already flashed with GOS, then do an attestation with Auditor from another Pixel.
2) my phone is taken at the airport by authorities for 2 hours, returned, I then use another Pixel to do a new attestation (not already established) with Auditor (without reflashing GOS).
2b) my phone is taken at the airport by authorities for 2 hours, returned, I use another Pixel previously used for attestation with Auditor with the device in question to do another attestation with Auditor (without reflashing GOS).
Does Auditor yield results in those scenarios that will restore hardware and firmware trust or not?
Thank you
@GrapheneOS
Also reviewed:
1)
"Hardware-based security verification and monitoring via our Auditor app and attestation service"
(https://grapheneos.org/features#anti-persistence)
2)
"Our Auditor app and attestation service provide strong hardware-based verification of the authenticity and integrity of the firmware/software on the device. A strong pairing-based approach is used which also verifies the device's identity based on the hardware-backed key generated for each pairing. Software-based checks are layered on top with trust securely chained from the hardware."
(https://grapheneos.org/features#auditor)
3)
"The Auditor app uses hardware security features on supported devices to validate the integrity of the operating system from another Android device. It will verify that the device is running the stock operating system with the bootloader locked and that no tampering with the operating system has occurred. It will also detect downgrades to a previous version.
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) or Hardware Security Module (HSM) including the verified boot state, operating system variant and operating system version. The verification is much more meaningful after the initial pairing as the app primarily relies on Trust On First Use via pinning. It also verifies the identity of the device after the initial verification. Trust is chained through the verified OS to the app to bootstrap software checks with results displayed in a separate section."
(https://github.com/GrapheneOS/Auditor/releases)