1

I'm trying to figure out how exactly works the Android Verified Boot process and its usage with custom ROMs. The documentation I found on it is unclear (or outdated) as there seems to be several ways to do it.

What I understood (please correct me if I'm wrong) is listed below.

Before flashing :

  1. The bootloasder is initially locked, and has to be unlocked through the fastboot command (and a physical confirmation from the end user).
  2. The user data are totally wiped in order to prevent unauthorized access through rooting process (e.g. if a device is theft and the thief tries to access private data).
  3. The custom ROM public key is stored in the user-settable root of trust (alongside with the manufacturer's one) when the OS is flashed.

Boot process (after flashing) :

  1. The systems is powered on (physical button)
  2. The device embedded BIOS reads the public keys stored in the root of trust (manufacturer and user-settable) and verifies that the kernel image has not been tampered.
  3. If the public key used to check kernel tampering is the user-stable one, then a 10 seconds warning is displayed in order to warn the end-user that the pub. key used to perform these checks is not the manufacturer's one.
  4. Once the kernel integrity is confirmed, the initial ram image is loaded and the init process is called.
  5. The dm-verity kernel module ensures that the boot process is not tampered through cryptographically signature checks, using a public key.

As I write these lines, several steps are still unclear to me :

  • Why are warnings displayed during boot if integrity checks pass ? I mean, even if the user-settable root of trust is used (instead of the manufacturer's one), integrity checks are still OK, don't they ?
  • Is the UNLOCKED state needed in order to set the user-settable root of trust, or is it needed to bypass Android Verified Boot ?
  • How is handled the "tamper evident" feature for the user-settable root of trust ? I mean : the user-settable root of trust should only be set by the end user (and not the manufacturer) but how can we be sure that It did not set one anyway ? Moreover, if the system is rooted, how can we be sure that the "new" OS has not reset the tamper evident flag ? Are one-time programmable memory used ?
  • What public key is used by the dm-verity kernel module in order to perform integrity checks ?

Thanks in advance !

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.