Secure Bootloader - When, Why, How...Started by 5 years ago●4 replies●latest reply 2 months ago●7389 views
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.
- 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.
In the context of embedded systems, a secure bootloader refers to a bootloader that is designed to prevent unauthorized access, modification or execution of the boot process and the firmware it loads.
The difference between a secure bootloader and a non-secure bootloader lies in the level of protection provided against malicious attacks and unauthorized access. A secure bootloader provides mechanisms for verifying the authenticity and integrity of the firmware it loads, as well as protection against tampering and unauthorized execution.
A bootloader needs to be secure when the system it runs on contains sensitive or critical information, or when it is connected to a network or the Internet. In these cases, the bootloader needs to provide protection against malicious attacks that can compromise the security of the system, or cause the system to malfunction.
There are several options and best practices for securing a bootloader, including:
- Cryptographic signatures: The bootloader can verify the authenticity and integrity of the firmware by checking its cryptographic signature, which is generated using a secure key.
- Hash-based integrity checking: The bootloader can calculate a hash of the firmware, and compare it to a stored value to ensure that the firmware has not been tampered with.
- Secure key storage: The secure key used for cryptographic signatures and hash-based integrity checking needs to be securely stored, and protected against tampering.
- Encryption: The firmware can be encrypted, so that it cannot be read or executed without the correct encryption key.
- Memory protection: The bootloader can use memory protection mechanisms, such as memory mapping and privilege levels, to protect itself and the firmware from unauthorized access.
- Secure boot sequence: The boot process can be designed to be secure, with strict control over the sequence of events and the data that is processed.
- Secure boot environment: The boot environment, including the bootloader, the firmware and the hardware, needs to be secured against tampering, and protected against physical attacks.
In conclusion, securing a bootloader is important in order to protect the system against malicious attacks and unauthorized access. The best practices for securing a bootloader include using cryptographic signatures, hash-based integrity checking, secure key storage, encryption, memory protection, secure boot sequence and secure boot environment.