About verifying the image

mikefjell

So according to the way I tried to verify the downloaded image, it was not "untampered" or corrupted, can anyone confirm if I did it the wrong way?

C:\Program Files (x86)\GnuPG\bin>gpg --verify C:\Users\Admin\Downloads\avbroot-3.12.0-x86_64-pc-windows-msvc\bluejay-install-2025012700.zip.sig C:\Users\Admin\Downloads\avbroot-3.12.0-x86_64-pc-windows-msvc\bluejay-install-2025012700.zip
gpg: no valid OpenPGP data found.
gpg: the signature could not be verified.
Please remember that the signature file (.sig or .asc)
should be the first file given on the command line.

If I verified the zip file wrong, please tell me how to do it properly

Also, this is the contents - maybe im overly paranoid but is it right with the modified date on all files set to that? (1899 or something)
https://prnt.sc/1gy40FYgm4jn

ryrona

mikefjell gpg: no valid OpenPGP data found.
gpg: the signature could not be verified.

The signature is not in GPG format, so you cannot use GPG to verify it. Please follow the advise in the installation guide to verify the image:

https://grapheneos.org/install/cli#obtaining-factory-images

You need to use "ssh-keygen" tool to verify the signatures. I don't know why they have chosen to do it this way, everyone else always sign with GPG.

mikefjell Also, this is the contents - maybe im overly paranoid but is it right with the modified date on all files set to that? (1899 or something)

I cannot open your screenshot, but the timestamps on the files doesn't matter, they aren't used for anything.

SgtSurehand

ryrona I have always relied on the boot hash to tell me my installation is genuine. Is it possible that the hash on the "device is loading a different operating system" is correct yet OS is compromised?

Carlos-Anso

ryrona I don't know why they have chosen to do it this way, everyone else always sign with GPG

A decision was made to move away from GPG due to various issues. Using something more modern, clean and better maintained makes much more sense.

ryrona

SgtSurehand I have always relied on the boot hash to tell me my installation is genuine. Is it possible that the hash on the "device is loading a different operating system" is correct yet OS is compromised?

There shouldn't be. The hash is the hash of the verified boot key, so it will only be able to load validly signed data. But verifying the signature over the zip-file is still good to do. The installation zip file contains many separate firmware components that are separately signed for verified boot, so you could possibly end up flashing a validly signed GrapheneOS that is the latest version as shown when booted, yet, some firmware components are valid and legitimate but really old versions with known vulnerabilities. The signature over the zip file would catch that, but depending on how the verified boot is implemented, it is not guaranteed that one will catch it. And it is possible of course that not all data blocks are there, and what you flash is incomplete. Everything that is loaded is valid, but it may fail to load some things.

So, the boot hash should be enough to verify to be sure there are no malicious code, but it might not guarantee that the system was flashed fully and as the intended unit. Someone who know exactly how the verified boot is implemented may answer more accurately.

The OS will be a unit though, since it uses dm-verity over the whole image. An attacker cannot manipulate that to mix and match between versions.

GrapheneOS

Carlos-Anso We had already moved away from GPG to signify years ago but we replaced signify with SSH due to it being more broadly available including both macOS and Windows having it included in the base OS. GPG has poor security and doesn't even support directly verifying a file with a public key and signature anyway but rather you have to use a key with a keyring.

GrapheneOS

ryrona The firmware images have anti-rollback protection at a low-level. We recommend updating the stock OS on the device before flashing GrapheneOS so if people follow that best practice they have the firmware patched and rollback to insecure older versions with verified boot vulnerabilities blocked before they flash GrapheneOS.

The OS is fully verified by verified boot. The vbmeta image is signed with downgrade protection and has hashes of the core OS images and hash tree roots (dm-verity) for high level images. We don't use chained vbmetas for out-of-band updates to images but that's supported and the stock OS uses it. It just means having a public key for a chained vbmeta in the main vbmeta and downgrade protection is done for them separately with the secure element having slots for each. Persistent state for the OS has to be wiped and formatted as a whole to be usable since the baseline encryption takes into account the OS verified boot public key along with being specific to a device due to the TEE hardware bound key for key derivation and other hardware integration. It's not feasible to make persistent state to flash which would be used by the OS. Locking also wipes the persistent state.

ryrona

GrapheneOS Persistent state for the OS has to be wiped and formatted as a whole to be usable since the baseline encryption takes into account the OS verified boot public key along with being specific to a device due to the TEE hardware bound key for key derivation and other hardware integration. It's not feasible to make persistent state to flash which would be used by the OS. Locking also wipes the persistent state.

But, is this really true? Wasn't there recently a case where the stock OS added some anti-tampering measure that required you to login to your Google account during the setup wizard after a factory reset, and this affected GrapheneOS in some sense, despite the user having gone through the whole process of unlocking bootloader, flashing GrapheneOS and then locking bootloader again. I remember GrapheneOS fixed the issue by clearing that persistent data the stock OS added, clearing it early during the setup wizard.

That would suggest to me there is at least some persistent state that does in fact not get deleted.

I have also wondered a lot if persistent state for all hardware components, such as for the baseband, really gets cleared by this procedure or a factory reset.

Both of these things are out of scope for this thread though.

GrapheneOS

ryrona

But, is this really true? Wasn't there recently a case where the stock OS added some anti-tampering measure that required you to login to your Google account during the setup wizard after a factory reset, and this affected GrapheneOS in some sense, despite the user having gone through the whole process of unlocking bootloader, flashing GrapheneOS and then locking bootloader again. I remember GrapheneOS fixed the issue by clearing that persistent data the stock OS added, clearing it early during the setup wizard.

Yes, it is true. The whole persistent state partition is wiped. There's a factory reset protection data block on the secure element which survives a regular wipe of the secure element for implementing factory reset protection.

That would suggest to me there is at least some persistent state that does in fact not get deleted.

It's not part of the OS state on the SSD.

I have also wondered a lot if persistent state for all hardware components, such as for the baseband, really gets cleared by this procedure or a factory reset.

It clears the hardware keystores, secure element (other than the frp data block) and SSD OS state partition which is mainly guaranteed through doing the previous 2 things. Non-OS persistent state whether on the SSD and elsewhere is minimal and most components don't have any.

GrapheneOS

@ryrona Worth noting that in addition to wiping the hardware keystores and overall secure element, the encryption metadata is wiped from the SSD with a special SSD supported command for wiping it. The OS avoids writing it or modifying the encrypted disk encryption keys stored there other than wiping it this way. It's an extra redundant mechanism so we don't focus on it. We use all 3 wipe mechanisms for our duress PIN/password feature too as part of our wipe-without-reboot implementation. They implemented wipe-without-reboot upstream based on our proposal for it in January 2024 but they only use the single method of wiping the hardware keystores which doesn't wipe Weaver, etc. so it's not the best way of doing it. They only use wipe-without-reboot in combination with booting into recovery to finish wiping / formatting though while our duress PIN/password uses all 3 methods and shuts down so there's a data corruption error at boot, then it falls back to asking the user to wipe/format since it can't decrypt anything and there isn't even encryption metadata there to try.

GrapheneOS

The original question was answered and more general discussions of verified boot and attestation can happen in new threads if there are still questions.