Deciphering phone and embedded security - Part 3: Unsigned, signed, locked and encrypted bootloaders

Lot of manufacturers that offer signed bootloaders do allow bootloaders to be "unlocked" in a variety of ways (unofficially) as mentioned in previous section. Under "unlocked" state, signature checking is bypassed, providing ability to update the firmware and thus install custom ROMs.

Some manufacturers especially those that have been using signed bootloaders have their bootloader permanently locked, allowing little scope for the Android community to do a firmware update unless they find ways around that. However, although hackers have often found exploits to set phones free from signature checking, some phones to date have been locked to their standard software (for example Motorola Droid 2).

Furthermore, there may be different methods of protecting the firmware, as shown in Figure 2.

Figure 2: Main partitioning in ROM (part of Flash)

All of the areas shown (Boot, Recovery, and System) may be independently signed by the manufacturer. What this really means is no custom kernel (which lives in /boot), no custom recovery (which lives in /recovery) and no custom ROM (which lives in/system).

Different manufacturer may use different variants, for example for the cases where "recovery" and "system" are not protected by digital signature one could still flash a custom recovery and install a custom ROM without the bootloader creating a problem. For any phone that comes with a signed Bootloader, the "Boot" partition will always be protected with the digital signature, which really means that one could only use the stock kernel.

If all areas are protected with the a signed and locked bootloader, the only way to get access to modify firmware is if engineering bootloaders get leaked (which is also common). An engineering Bootloader will not enforce the signature of the various partitions: /boot /recovery /system, which will allow anyone to flash custom kernels, recoveries, and custom ROM. The other alternative is to fool the system into thinking it has an empty Bootloader (on external Flash connected) and thus bypass signature checking to be able to load external Bootloader (this is described in Part II). However this trick may not work for all phones.

More recently under the pressure of the Android community, some manufacturers (like HTC) have reversed the trend and released new phones with an "unlocked" Bootloader so technical geeks can take advantage of open OS and customize phones.

On the "Encrypted" Bootloader, I am not sure if there are really any phones with this feature, rather all they have is a Bootloader with encrypted signature. Even though this is an area for improvement on security architecture on Android phones, it will be driven by what structure manufactures would like to use to keep it open to keep the Android community happy (to be able to customize their phones) versus what could actually be done to be able to avoid a hack.

The next section will focus on an ideal security platform that inherits capabilities from the mobile world and can be incorporated in future embedded devices.

For more articles like this and others related to designing for the embedded Internet, visit Embedded Internet Designline and/or subscribe to the biweekly Embedded Internet newsletter (free registration).