anselmschueler
but by actual trust/physical limitations, e.g. a chip manufacturer that can be physically audited and risks alienation if they betray their trust promising to only add some keys to those chips that refuse certain operations
Our Auditor app is primarily based on pinning the keys it generates in the hardware keystore. The attest key it generates in the hardware keystore is what's used to sign the attestation metadata which is included in the public key certificate for the signing key it generates in the hardware keystore. It does not depend on chaining up to the root of trust beyond the weak verification it provides for the initial pairing to bootstrap the process.
Read https://grapheneos.org/install/web#verifying-installation which provides an explanation of verified boot as a starting point, since you seem to be missing that prerequisite knowledge. Look at the implementation in https://github.com/GrapheneOS/Auditor/blob/80/app/src/main/java/app/attestation/auditor/AttestationProtocol.java for more details on the attestation implementation.
If I’m right about this fundamental limitation
No, not really.
what is the root of trust in the GrapheneOS attestation process? And what other components also need to be trusted (where we can trust the correct software is running because we trust the layer beneath it, but must then additionally trust that that software has the correct behavior to trust its actions)?
The SoC boot ROM verifies the signature and anti-rollback version for the main firmware on the SoC. Fuses were blown in the factory to hard-wire the keys. Fuses are blown after updates to prevent firmware downgrades for firmware updates with security patches relevant to verified boot, etc. The secure element has a 2nd separate root of trust but also only accepts updates after the Owner user successfully authenticates as part of what's called insider attack resistance, which mainly exists to defend the Weaver feature used to throttle key encryption key derivation as part of the disk encryption implementation. More details on that at https://grapheneos.org/faq#encryption and it's not really related to this, but the insider attack resistance is relevant to the hardware keystore too. The attestation feature is provided as part of the hardware keystore and both are tied to verified boot on the main SoC too.