A couple of weeks ago, we discussed the basics of bootloaders in the thread titled 'What is a Bootloader and When do You Need One' (thanks for the great posts!).  The occasional need to make the bootloader 'secure' came up a few times in the discussion and I thought that would make for a great new #FAQ thread where readers could learn more about this topic.  Some ideas (only ideas!) on how you could contribute to this new discussion:

• What does it mean when a bootloader is 'secure' (differences between non-secure and secure)
• When (practical examples maybe?) and why does a bootloader needs to be secure
• How to secure a bootloader - best practices, options (paid vs free)

Basically, anything that you believe you could share on the subject and that could be of some use to a fellow engineer down the line.

My high level ideas about it :)

• What is a secure bootloader? 
  • the bootloader itself can reflash(reprogramm) the firmware/software running on an embedded device or system, when the transferred content is encrypted we talk about secure bootloaders.
• When do i need a secure bootloader?
  • Basically when you want to prohibit unauthorized reprogramming/reconfiguring of your system, otherwise anybody could load anything on it, especially vulnerable are the IoT devices and systems with update Over the Air.
  • In other words: if you support OverTheAir update and you product is not some hobby tinkering around, please, ALWAYS use a secure bootloader.
  • If the device can be reprogrammed only by a cable connection, and it is enclosed in a larger system, the security might not be crucial, it really depends on the requirements.
• How to secure a bootloader ?
  • My personal advice - start with an open source bootloader and look for a commercial one only if you need a security certified bootloader.
  • In case you want to wonder into the world of secure bootloader development, consider the below points, if any of the topics sounds "alien", definitely re-consider the open source versions :)
    
    • Add an decryption/encryption layer to the bootloader itself
    • Add an encryption/decryption layer to your backend, or tools which are generating the to-be-dowloaded content
      • Note: use a strong symmetric encryption. like AES128 (or higher), this is still fast enough and state of the art secure
      • Think about key management, key rolling, in case you would want to update your symmetric key
      • In case of key management, it is strongly advised to have a mutual authentication phase, preceding the key rolling and the actual download.

Hope it helps.

Laszlo

Secure boot loader:
- allows updating firmware on a board by authenticated authority (if the source of the code cannot be confirmed it will be effectively ignored so that hackers can't upload bogus code).
- allow code distribution in a form that doesn't allow reverse engineering (encrypted in order to protect the code's intellectual rights) - this if often the main concern of manufacturers using encrypted boot loaders; they don't want others to simply copy their HW, load their code and thus fake their products.
- An integral part of secure boot loaders, which doesn't seem to always be mentioned, is to also protect the chip that it is running on from being debugged and loaded code from being read out (for reverse-engineering or duplication). This is important since otherwise the secure boot loader (which may contain some form of keys) could quite easily be read out to break the encryption or to modify it to allow un-secure loading to become possible. Also it is important to protect the application that is loaded (same reasons). Most single-chip devices (internal Flash) have the possibility to disable JTag (and such) and processors which boot from external memory (eg. SPI Flash) that are intended for secure operation may also allow the boot loader code itself to be stored in an encrypted from in the external Flash.

I have worked on several bootloaders where the GUI and bootloader share a private key. The GUI needed to send a GET_SEED command which received a "random" number from the loader and the GUI would apply the private key and return an UNLOCK value that needed to match the value computed by the bootloader before it could execute many loader commands. I first saw this in a CAN CCP bootloader and think it's the minimum that should be implemented for loader security.

I have implemented loaders for TI 28x processors that have an interesting Code Security Module(CSM) The CSM has a 128-bit passkey that can be used to lock down the flash, one time programable, RAM, and JTAG access. If you don't program the passkey you can do all the normal operations but once you program the key it is locked down until unlocked. This greatly increases the security of the loader. You can use the CSM passkey as the private key for the UNLOCK comparison and make it much more difficult to hack. Unfortunately this requires security and passkeys be maintained in the GUI and tracked to the devices. If the passkey is lost the device is essentially bricked. I worked with one company that was reluctant to use the passkey and left the key erased because they didn't have the discipline to secure the passkeys throughout the organization.