Medical grade bootloader for ARM microcontrollers
The process of installing firmware updates in the field is challenging for many products, especially medical devices. Our CSA bootloader saves a lot of development time during embedded projects, creating added value in terms of performing secure (remote) updates in the field.
The CSA bootloader implements the functionality needed for installing, updating and protecting firmware against modification and reverse engineering. Combined with specially designed hardware, this minimises the risk to patients from age-related, environmental and malicious modification of a medical device's firmware. The bootloader is primarily used in systems consisting of a host computer (PC) and one or more microcontrollers. The bootloader and the respective application firmware implement a proprietary RPC interface; this enables them to be controlled by application software on the host computer.
The CSA bootloader meets the following requirements (see the next section for technical details):
- 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 out keys from the microcontroller)
Optional:
- 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)
Under development:
- Integrity and authenticity checks on the firmware during start up
- 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
For more details, see the "Asymmetric cryptography" section.
The bootloader is equipped with ARM Compiler Version 5. Launched as part of the CSA Boostcamp 2022, the transition to GCC is currently in the planning phase. In addition, the Boostcamp also laid the foundation for automatic code generation for RPC commands using clean JSON files.
CSA offers a ready-to-use, licensable bootloader solution, as well as customer-specific adaptation and development as a service. The bootloader has been developed, documented and verified in accordance with IEC 62304.
For applications involving integration into a customer product, the integration plans and protocols can be supplied, which enable the customer or CSA to adapt them to the respective product. We would be happy to show you the bootloader's full range of functions. If you are interested, please contact our sales team, who will arrange for you to meet with an expert.
You can find further interesting details on implementation, hardware requirements and information on establishing communication below.
Figure 1 Overview of STM32L4 regions in flash memory
The STM32F4 and STM32L4 families (Cortex-M4, ARMv7e-M) are currently supported by STMicroelectronics. Support can easily be extended to other microcontroller families from the same manufacturer as needed.
Hardware requirements
On-chip flash memory: four independent regions are required in the flash memory. It is imperative that the regions are able to be deleted and written independently of each other and that they also offer sufficient space for the bootloader components and application firmware. This means at least:
Region 1: 4kB (pre-bootloader)
Region 2: 100kB (primary bootloader) or 16-32kB for versions with adapted cryptography
Region 3: 100kB (secondary bootloader) or 16-32kB for versions with adapted cryptography
Region 4: Provided by application firmware
On-chip SRAM: 32kB RAM and above (depending on functional scope)
In the current implementation, both bootloaders and the firmware have a checksum for verification purposes. For the option with asymmetric cryptography, the checksum is replaced by a cryptographic signature.
Bootloader update
In addition to the application firmware, the bootloader can also be updated securely in the field. To ensure that the device remains usable or recoverable even in the event of a failed update, there are two copies of the bootloader on the target system. A bootloader can only ever overwrite the other copy, which guarantees a fallback should an error occur.
Asymmetric cryptography (under development)
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.
Figure 2 Typical application with daisy chain topology
Communication
The functions of the bootloader can be accessed via a proprietary RPC protocol (Remote Procedure Call). The same protocol can also be used in the application firmware, allowing optimal integration of the bootloader and application. C, C++ and Python software libraries are available if required. RPC commands/responses and events are exchanged as individual packets via the underlying data link protocol. The RPC packets are divided into frames. The maximum frame size depends on the RAM/DMA capacity of the controllers used. Each data link endpoint has its own address, which is composed of the address of the receiver itself and the corresponding port. The data link protocol can therefore be used across most available electronic interfaces.
The following topologies can be used:
- Point-to-point: one host (master) and one microcontroller (slave): master > slave 1
- Daisy chain: one host (master) and several microcontrollers connected in a series (slaves): master > slave 1 > slave 2 >
- Star – one host (master) with several physical point-to-point connections
- Network – one host (master) with several logical point-to-point connections, e.g. via an existing TCP/IP network, an I2C or SPI bus with several addressable slaves.
Restrictions
As the bootloader is usually stored in the normal program memory (like the application firmware itself), we recommend using hardware measures to protect it against malicious modification (e.g. via JTAG). Most microcontrollers contain a variety of options for doing this by default.