Medical grade bootloader for ARM microcontrollers (UPDATE)
It has already been more than six months since we published our first blog post on the subject of bootloaders. A lot has happened since then. We were able to give a guest talk at the Embedded Computing Conference (ECC) in Winterthur and present the concepts, along with our approaches to finding solutions. In a packed lecture theatre, it became apparent that the topic of bootloaders is still posing major challenges for the industry, or rather, developers.
You can watch the entire talk on YouTube >
Alongside presenting our medical grade bootloader solution to the ECC, substantial work has also been carried out to improve its range of functions. For example, the switch from ARM Keil to GCC and CMake was successfully implemented. A generator can now be used to create RPC commands, which massively reduces the effort involved in implementing new commands. In what is likely to be the most interesting change, however, there is now the option of encrypting update files and cryptographically verifying firmware before booting up.
The CSA bootloader fulfils the following requirements (new requirements in bold):
- Medical device ready
- Installation of firmware during production
- Updating the firmware and bootloader in the field (in-application programming)
- Resistance to errors and prevention of devices being rendered unusable, or at least ensuring the recoverability of the device in the event of failed updates (e.g. during a power failure)
- Resistance to attacks
- Limiting the damage of a successful attack (e.g. reading keys from the microcontroller)
- Integrity and authenticity checks on the firmware during startup
- Protecting the device against the installation of unauthorised firmware
- Protection against the installation of firmware onto unauthorised devices
- Protection against modification of the firmware or the firmware update
- Protection against reverse engineering of the firmware or the firmware update
- Production keys – ensuring that devices or components that have “fallen off the back of a lorry” on the way from the electronics manufacturer to the assembling company, for example, cannot be used
- Automated building and testing of the bootloader or application firmware
Optional (if desired):
- Downgrade prevention: preventing the installation of older firmware versions
- Device-specific firmware: firmware is linked to the hardware of a device (e.g. via the unique identifier of the microcontroller)
The newly integrated requirements are specified in more detail below.
Asymmetrical cryptography
By using asymmetric cryptography to encrypt and decrypt firmware as well as to generate and verify digital signatures, keys extracted from one device by an attacker cannot be used directly for further attacks on other devices or the entire system. A key that is stored in the device’s memory to verify a signature, for example, cannot be used to generate valid signatures.
Update Files
In the current version, the update files are encrypted. The metadata required for asymmetrical encryption is stored in the header of the firmware update files (FUF) or in the bootloader update file (BUF) and signed cryptographically. The signature serves to detect malicious or unwanted changes to the header. Using the metadata, the actual firmware/bootloader update, which is divided into individual blocks, is encrypted block by block. This makes it possible to share the BUF/FUF file with external individuals without the need for them to obtain access to the actual binary file.
Abbildung 1: Firmware update file structure
The FUF/BUF files described above can be transferred to the target device with the help of the RPC tool. This involves firstly uploading the FUF/BUF header in order to initialise the update and associated decryption. Each block is then sent to the target device one after the other and decrypted there using the header metadata. Due to the limited working memory size, the individual blocks are written directly to their corresponding location in the flash memory.
Abbildung 2: Bootloader update file structure
Firmware Verifikation
A further security element is the verification of firmware using cryptographic signatures. For each booting process, the signature is calculated via the header fields (excluding the versions and signature field), the keystore and the actual firmware. The calculated signature must match the signature stored in the header in order for the booting process to continue.
Abbildung 3: Firmware verification
Switch from ARM Keil to GCC and CMake
CMake/Ninja and GCC are now used to ensure the bootloader can be compiled using the embedded toolchain and integrated into our CSA building blocks framework. Bootloader images and updates can now be automatically created in the pipeline on a build server. The use of CMake also allows other compilers to be supported, providing an added benefit.
RPC code generator
The newly developed code generator ensures that the (communication) code on the microcontroller and host sides is synchronous. A further advantage is the easier extensibility of the bootloader and, above all, the extensibility of application-specific firmware to accommodate other RPC commands. The current version of the code generator supports C on the microcontroller side and C++ and Python on the host side. The generator can also be used to support automatic (integration) tests by generating specific test commands.
Outlook
We are using the bootloader for our internal projects. New processors from the STM32 family are being supported in the process. Thanks to its built-in encryption feature, the bootloader is now ready to be integrated into your (medtech) projects!