As a consequence of the strong rise of smart and internet connected devices, there is an increased demand for embedded system security. As a result, more and more customers ask Feaser about the security options that are available, when the OpenBLT bootloader is incorporated into their microcontroller based product.
Security is needed in an embedded system to prevent unwanted third parties from tampering with the system and from stealing your intellectual property (IP). From the context of a bootloader, security options are meant to prevent unwanted third parties from
- Making firmware updates on your product.
- Capturing your firmware data while it is communicated to your product during a firmware update.
- Reading out your firmware data after it was programmed onto your product.
The OpenBLT bootloader already has several security options build-in that can be easily enabled. Together with readily available add-on modules and a few extra configuration steps, your system can be fully secured. This article describes the different levels of security available in a system with the OpenBLT bootloader.
Level 0 (default)
The seed/key security feature is enabled. Before performing memory read/erase/program operations via the bootloader, the firmware update PC tool needs to first unlock privileges. It does that by requesting a multi-byte seed from the bootloader on the microcontroller. The PC tool computes a key based on this seed and sends the key back to the bootloader. The bootloader verifies the key and if correct, it unlocks the needed privileges.
To enable the seed/key security feature, set the following configuration macro to 1 in “blt_conf.h”:
#define BOOT_XCP_SEED_KEY_ENABLE (1)
You have full control over how the seed is generated and you can implement your own key computation algorithm. On the PC, the key computation algorithm is embedded into a shared library (DLL). Refer to the security section of the user manual for more details.
If the key computation algorithm from level 1 is cracked, then it is possible for someone to download your firmware via the communication protocol of the bootloader. Once they have your firmware, they could reverse engineer it.
By setting the following configuration macro to 0 in “blt_conf.h”, all memory read operations via the bootloader’s communication protocol are disabled and always return zero values.
#define BOOT_XCP_UPLOAD_ENABLE (0)
Note that this particular feature is not yet available in the current OpenBLT release (version 1.6.0). It is already present in the SVN trunk and will be included in version 1.7.0, which is planned for release in January 2019.
The measures in level 1 and 2 are a good start, but if it is possible for someone to connect a debugger interface to the microcontroller on your system, then they could just download your firmware with the debugger. Alternatively, they could overwrite your bootloader with the default OpenBLT bootloader and have full access again.
For full security the recommended practice is to disable debugger access on your system. This functionality is not part of the bootloader, but you can easily implement this yourself. On STM32 microcontrollers for example, you can use the STM32CubeProgrammer tool to easily change the option bytes to configure a “level 1” read out protection:
The measures in level 1 to 3 are sufficient to secure the bootloader and your system, such that your firmware cannot be readout and updated by unwanted parties. This is fine in case you perform the firmware updates for your customers. But what if this is to be done by a field technician or the customer themselves? In this case you have to provide them with your firmware file. If your firmware file falls in the wrong hands, your firmware can be reverse engineered. Another method that could be used to access your firmware data is when someone snoops the communication data exchange during a firmware update.
To prevent these scenarios, Feaser offers the Firmware Encryption add-on module. Each time you build your software with your compiler toolchain, a provided command-line program is called to encrypt the program data in your firmware file. When communicating the firmware data to the bootloader, the data is still encrypted. It is only decrypted right before it is programmed into flash memory. This way you can freely distribute your firmware file and don’t have to worry about someone capturing a trace of the communication data during a firmware update.
The measures in level 1 to 4 make sure that no one from the outside can change flash memory contents. There is still a small chance that “someone” on the inside changes the contents. Think about a flash memory hardware failure or just the fact that all flash memories have a time limit on how long it can retain data.
For this situation, Feaser offers the Improved Checksum add-on module. Each time you build your software with your compiler toolchain, a provided command-line program is called to patch a checksum information table at a fixed address into the firmware file. After each reset event, the bootloader calculates and verifies the checksum over the entire range of your firmware data. Your firmware is only started by the bootloader if the checksum verification was successful, thereby preventing potentially damaging side effects from starting an incorrect or incomplete software program.
This article described in detail how you can fully secure an embedded system that makes use of the OpenBLT bootloader for firmware updates. Feel free to contact Feaser for more bootloader security related question or if you are interested in having Feaser perform a bootloader integration on your system, which enables and configures all these security features for you.