Comment by dist-epoch

> resets SecureBoot to the new configuration so it's accepted on reboot, triggers a PIN screen to re-seal user secrets, but it will now fail attestation since it's hashes will be non-recognized.

There are two types of compromise for the local device. The first is that they get root on the application processor (but not the secure processor), the second is that they get root on the secure processor.

If you have the first type of compromise then you don't need remote attestation because you can have the secure processor do any verification the remote server would have done and not release keys/signatures that allow you to sign into the service when the device isn't in the expected state. The secure processor won't accept a different device state for use of the existing key unless you compromise it.

If you have the second type of compromise then remote attestation can't save you because the attacker can forge attestations.

In neither case does it do you any good. The only thing it does in the first case is lock you out of using a device or OS you want to use because the service is demanding a signature from a specific OEM rather than one from the key you yourself generated and registered with the service and can keep in any kind of device you choose.

You can’t change secure boot settings from the OS, even with root. You need the signing keys or to be in BIOS (if it’s configured correctly), which shouldn’t be on the device.

Now if the right kernel exploit and a secure boot exploit are chained together then it’s possible. But at the point, you’re gonna be hosed no matter what you do.