• General

  • Non-stock Android Verified Boot key

The final firmware boot stage before the OS is responsible for verifying it. For the stock OS, it uses a hard-wired public key. Installing GrapheneOS flashes the GrapheneOS verified boot public key to the secure element. Each boot, this key is loaded and used to verify the OS.

This is strange, since I've actually deleted the key (using steps here: https://grapheneos.org/install/web#replacing-grapheneos-with-the-stock-os) and the OS definitely still booted.

Is this a bug?

    fizzics
    I imagine thats because the key verifies the system. Its not actually needed to run the system I don't think. It is however needed to ensure the system isn't changed, since the key would have to match the key thats stored on the secure element when the device is booted. So deleting the key would mean the system still works, but you've removed the security of it.

        Dumdum I have noticed however that:

        https://grapheneos.org/install/web#verified-boot-key-hash

        The verified boot public key flashed to the secure element can only be changed when the device is unlocked.

        Can anyone clarify what it means by the public key being changed?

        If you are running GrapheneOS and you wish to switch to running a different OS, signed by a different signing key, you will wish to change the OS signing key that the secure element uses. I believe that can be done only when OEM unlocking is on and the bootloader is unlocked (unlocking the bootloader will wipe the user data partition).

          fizzics I've actually deleted the key (using steps here: https://grapheneos.org/install/web#replacing-grapheneos-with-the-stock-os) and the OS definitely still booted.

          Is this a bug?

          Perhaps? It depends on exactly what was observed. Can you indicate exactly the steps you took and what you observed? For example:

          1. Install GrapheneOS the regular way including verified boot key,
          2. Boot GrapheneOS, receive the "different operating system" yellow screen with correct signing-key hash,
          3. Delete GrapheneOS signing key but leave GrapheneOS installed,
          4. Reboot into GrapheneOS,
          5. Observe _______ on the bootloader screen.

          It would also be good to know which device the observations are from. I think some of the early devices didn't report the entire signing key hash, and it is possible that early versions contained other infelicities.

          Edit: note that the bootloader may behave differently depending on whether or not it is locked. I can imagine that it might not complain about a missing verified-boot signing key if it's unlocked. Meanwhile I am not exactly urging people to try locking the bootloader without a signing key installed -- that seems like a potentially uncomfortable situation to be in.

              Dumdum

              This makes a lot of sense.

              When I booted into the OS after removing the key, it mentioned only that the bootloader was unlocked (required to remove the key) but nothing else.

              Would there be some way in the OS to tell if the system is still verified with the secure boot key?

              I also wanted to ask, when flashing a new ROM or stock ROM over GrapheneOS--without removing the GrapheneOS verified boot public key, will that key remain the same and unused in those ROMs? And when flashing GrapheneOS again, I assume the old key left behind will be overwritten with a new key? It seems that the key is set under the variable name avb_custom_key, so I'm wondering about the interaction with other ROMs/stock if not removed.

              • de0u replied to this.

                  de0u

                  Steps I've Observed:

                  1. Install GrapheneOS the regular way including verified boot key.
                  2. Boot GrapheneOS, receive the "different operating system" yellow screen. The key is present at the point on this screen.
                  3. Delete GrapheneOS signing key but left GrapheneOS installed.
                  4. Reboot into GrapheneOS, bootloader is unlocked so I think it was orange more than yellow, don't remember if the hash of the key is shown.
                  5. Booted into the OS, but GrapheneOS warned me that my bootloader was unlocked and that security is compromised (normal since I didn't lock the bootloader after removing the key) but didn't mention anything about the secure boot key being removed or different.
                  6. Rest of the OS booted up normally and brought me to the onboarding screen.
                  • de0u replied to this.

                      fizzics It sounds as if there were multiple warnings that system security was not guaranteed, so personally I don't see a bug.

                        fizzics I also wanted to ask, when flashing a new ROM or stock ROM over GrapheneOS--without removing the GrapheneOS verified boot public key, will that key remain the same and unused in those ROMs? And when flashing GrapheneOS again, I assume the old key left behind will be overwritten with a new key? It seems that the key is set under the variable name avb_custom_key, so I'm wondering about the interaction with other ROMs/stock if not removed.

                        My belief is:

                        1. The bootloader always has Google's key and prefers it, so if it sees an OS signed by Google's key and the signature is good then it will ignore the custom key,
                        2. If the bootloader sees an OS signed by one key but the key that is present is not that key, it will complain (though I have not verified this),
                        3. The standard AOSP build process signs the OS with a random key,
                        4. Some distributions sign their OS images with their key.

                        So I think leaving the GrapheneOS key in place will not trouble an installation of Google's OS, but might be annoying for somebody who installs some other OS, if they don't overwrite the custom key appropriately (which arguably they should).

                            de0u

                            Ah ok, this makes a lot of sense now. Doing a bit more digging and it seems like the avb_custom_key variable is actually supported by AOSP (wasn't aware of this, I thought it was just an arbitrary name for a variable):

                            On the Pixel 2, Pixel 2 XL and later Pixel models, the boot loader supports a virtual partition with the name avb_custom_key. Flashing and erasing this partition only works in the UNLOCKED state.

                            Good to know that this is a special key that custom OSes must use if they want verified boot so this key is most definitely overwritten whenever a new flash occurs and only strictly when a ROM is flashed.

                            Also, it seems that these keys are not dynamically generated, but instead are pre-generated which makes sense.

                            Thanks for the help, I'm just learning as I go!

                            • de0u replied to this.

                                fizzics Doing a bit more digging and it seems like the avb_custom_key variable is actually supported by AOSP (wasn't aware of this, I thought it was just an arbitrary name for a variable).

                                Not at all. For the bootloader to use the custom OS signing key to verify OS signatures (while booting, but also while sideloading), the key must be installed in accordance with code in the bootloader that looks for the key (e.g., by name).

                                fizzics Also, it seems that these keys are not dynamically generated, but instead are pre-generated which makes sense.

                                Some distributors of Android (e.g., Google, GrapheneOS) use static keys that are carefully managed. I believe the standard AOSP build process includes a key which one should never use in production (source).

                                      de0u Not at all. For the bootloader to use the custom OS signing key to verify OS signatures (while booting, but also while sideloading), the key must be installed in accordance with code in the bootloader that looks for the key (e.g., by name).

                                      Just so I can understand better, the variable avb_custom_key is arbitrary and, in this case, is what GrapheneOS uses but not necessarily what other Custom ROMS use?

                                      • de0u replied to this.

                                          fizzics The OS signing key is put there for Google's Pixel bootloader code to use to check the integrity of the system image. The bootloader does specific things, not arbitrary things.

                                          Please feel free to experiment, but I expect you will find that the GrapheneOS installer installs the signing key in exactly the way that causes the bootloader to use it, and calling it something else will cause the bootloader to not sign off on the integrity of the system image.

                                          Note that the bootloader is part of the device, not part of GrapheneOS.

                                            fizzics Just so I can understand better, the variable avb_custom_key is arbitrary and, in this case, is what GrapheneOS uses but not necessarily what other Custom ROMS use?

                                            It is arbitrary in the sense that some Google firmware developer could have decided to call it something else, such as PlutoActuallyIsAPlanet. But after the name was chosen it is part of the defined behavior of the device, see: https://source.android.com/docs/security/features/verifiedboot/device-state#user-settable-root-of-trust