Attestation: Wrong Ways // What Not to do // What to Expect

axino

When I began GOS, I didn't understand I should use the auditor app, I thought verifying the boot key hash from the screen was enough.
Even though I reviewed the tutorial and info, I only understand some of it; there wasn't a "what to expect" or "not muck it up".

I hope everyone can help to compile a list of what not to do or how to avoid simple mistakes from misunderstanding.
I will ask some questions and hopefully there can be some answers. Feel free to also add in additional questions/scenarios.
If my phrasing is wrong, it is due to my lack of full comprehension.

1} I Verified the boot key hash, isn't that enough?
A: No. Auditor Attestation will periodically check (every 6h for remote with 32h possible delay in notification) if there was corruption or difference.

2} I have been using the GOS device for many months and just now setup remote attestation, did I do it too late? How can I correct this if I did?
A: ?

3} First time remote attestation and the result under "Detailed History" says "Successfully performed basic initial verification and pairing."
Is the first time just a baseline? Meaning if there was an "issue", it wouldn't be able to determine it yet?
A: ?

4} First time Using Local Attestation on Auditor Apps GOS. With two devices, chose auditee and auditor, both scanned their opposite's QR code. The auditor turned brown with text about basic initiation verification and pairing, the auditee remained on the QR code screen saying if not complete then to clear.
Is this expected? How can we tell if it was completed correctly? Will it look the same the second time around?
A: ?

5} Should attestation be setup before a restore, or after a restore and what differences are expected: When it's the same device? When it's a new model device? When it's a new device but same model?

6} Are there certain sections to pay attention to? What are some actions to take if red does appear?
A: ?

7} Why would I clear the auditor/ee pairings? Wouldn't this just reset the baseline after a potention issue? Is this the same if I disable remote attestation?
A: ?

8} Is there a way to determine hardware corruption vs malicious corruption? What are some things to investigate? Should I stop using the phone to lessen the risk?
A: ?

9} The Auditor results looked unusual. Besides making a paniced post on GOS Forums, should I notify the community in other ways in case others may be at risk?
A: ?

someone27281

axino my understanding is GrapheneOS's auditor app will use a hardware based key attestation to verify (using Titan M2) some properties of the device. Enabling remote attestation using attestation.app/ will let GrapheneOS server verify what your phone reports.

The main idea is even if your phone is tampered (the OS is no longer the real GrapheneOS), the attestation service can detect it and notify you out of band (an email) because it's the Titan M2 chip that verifies and signs the info, not the OS.

At first, when the initial pairing is done (local or remote), the server has no way of knowing if the signature is done by the real chip or faked by malicious OS. So it has to trust from first use. If your system was secure when you did the initial pairing, it is secure now. If not, then no.

If you clear the pairings or disable remote attestation, then the keys are deleted and new keys must be generated, like the initial set up. That means the server has no way of knowing whether that new key is not tampered at first time. Basically whenever you do the initial key generation, you trust your device up to that moment. After that, auditor can detect tampering.

Note that it is possible to completely fake the attestation IF the Titan chip is breached. That is the root of trust. That's why that chip is heavily isolated and hardened against all sorts of attacks. But breach may happen, who knows.

Watermelon

Please note: I am NOT part of the GrapheneOS project in any way, I'm not working with them in any way, and I don't represent their views in any way. I am just a user contributing my knowledge. For transparency sake, every time I've previously contributed my knowledge about the Auditor app/attestation on this forum, I got my posts deleted by moderators who believed that I'm spreading misinformation, which I believe is incorrect and unjustified. What I'm posting here is what I believe to be correct, but feel free to wait for others to weigh in. I think the Auditor app is great to have, it also allows existing GrapheneOS installations to verify other GrapheneOS installations without resorting to manually verifying the key from the website (which relies on the HTTPS/root CAs security model which is problematic) so it's important to have it preinstalled in GrapheneOS, and they recently extended the Auditor app to report some security-sensitive settings, which is cool. I still think the Auditor app could be described better to users to prevent people from falsely believing that the Auditor app can verify the volatile running copy of the OS in RAM. See below for details.

You say you verified the verified boot key fingerprint displayed at boot. That's great! My recommendation is simple: Set up the Auditor app, check that the security patch levels are up-to-date, and if you suspect anything malicious has occurred in privileged OS components, simply reboot and that's all. After installing GrapheneOS updates that include a new monthly security patch level, check the attestation result and ensure that it reports the updated patch level as well.

axino I thought verifying the boot key hash from the screen was enough.

It largely is. Once you install the correct GrapheneOS verified boot public key and lock the bootloader, there shouldn't be any way to change this key without triggering a full wipe, short of compromising the secure element.

Depending on your threat model, you might have preferred to set up the Auditor app as soon as possible. You can boot into Safe Mode which prevents the OS from loading third-party apps until the next reboot before any third-party app can start, and also automatically enables Airplane Mode, hopefully before any network communication is done (it should be enabled before network communication, but the devs have said in another thread that this may not be guaranteed due to the baseband firmware), which should prevent any external attacker or locally installed exploit from compromising the OS using an unfixed vulnerability after the verified boot process checks the OS during boot. But again, depending on your threat model, it might not satisfy you much, if you think an attacker has already compromised the verified boot process or can exploit the OS even though all third-party apps should be temporarily disabled, etc. This should only be necessary for the initial pairing, because after that the Auditor app will ensure that the attestation results are coming from the specific secure element in your specific device that it will now cryptographically recognize in all future attestations (the only way to bypass this would be to compromise the secure element, but then you couldn't trust neither the verified boot process nor any attestation results at all).

axino Auditor Attestation will periodically check (every 6h for remote with 32h possible delay in notification) if there was corruption or difference.

Remote attestation (with the Auditor app or any app performing remote attestation really) doesn't and cannot check the volatile running copy of the OS in RAM. The secure element can attest the properties it has like the verified boot key installed into it, and can attest things that are part of the verified boot process like the OS's security patch level, as part of the "hardware-verified" information. Once the OS is booted, the secure element can gather information collected by the OS into a separate extension bundled into the final attested response from the secure element, such as sensitive configuration like the USB-C port and OEM Unlocking setting from the OS, but the Auditor app rightfully separates it into a separate "OS-verified" section because this information is gathered from the running OS, so the secure element relies on the OS to tell it the truth and cannot itself attest it. This is useful to prevent malware that compromises or spoofs the display on the device, for example a website that mimics your device's display that you accidentally entered into full-screen mode and you don't notice is still in full-screen mode, from telling you fake information, because you know that the secure element gathered it directly from the OS that was already verified by the verified boot process, but it still has to trust the OS for it and if you suspect that the OS is compromised post-boot using an unfixed vulnerability in a privileged OS component, then this might not be useful to you.

The secure element cannot reverify the volatile running copy of the OS in RAM. The verified boot process verifies the stored copy of the OS before it's loaded to RAM and starts executing. This is because the verified boot process relies on a chain of trust where the integrity of every component is checked by the preceding component, tracing all the way back to the boot ROM that's burnt into the hardware of your device at factory. Because of this, once execution is transferred to the next component, it cannot be checked again short of rebooting the device to restart the verified boot process from the hardware root of trust.