4.2.1.1 Executable Firmware Partition

During the firmware update process, designers should consider the impact of the update process on the existing firmware image, especially in the case of a partial or invalid image download.

Security Objectives:

Availability
Integrity
Authenticity

In some systems, it might be critical that a device maintain functionality in the case of a failed firmware update. In the simplest system that supports firmware update, there is only one firmware image area.

Figure 4-9. Firmware Update System - Single Firmware Image

In this case, the existing firmware image is lost when an update is started. It is impossible to verify/authenticate an incoming image until the entire new image is locally stored. This means that a system can be attacked by starting a firmware update and sending an invalid image or not sending an image at all which leaves the device in a non-operational state without another firmware update.

For some systems, this might be acceptable. Or it might be acceptable to have just a factory Reset, as described in Factory Reset (Immutable Recovery Image), that could be used as the point of recovery. These approaches, however, wouldn’t meet the requirements of the NIST SP 800-193 guidelines. Section 4.2.1.1 states: “The digital signature of a new or recovery firmware update image shall be verified … prior to the non-volatile storage completion of the update process.”

An approach to meet this requirement could be to create a dedicated download scratchpad used for the firmware update process. By having a download scratchpad, the prior version is protected in case of a failed update.

Figure 4-10. Firmware Update System - Download Scratchpad

By creating a download scratchpad, the firmware update system can download a new image into the scratchpad, which allows it to be verified and authenticated before allowing installation.

The Flash protection regions’ feature of the dsPIC33A can be used to increase the protection, and thus availability, of the existing firmware image during the firmware update process. By creating separate Flash protection regions for the existing executable firmware and the download scratchpad, one can use appropriate permissions to protect the existing image from modification during the firmware update process. The existing firmware image can be write-protected during the download of the new firmware image so accidental writes do not corrupt the current firmware image.

Figure 4-11. Firmware Update System - Separate Flash Region

By creating a separate Flash region for the executable image, the system can write-protect the executable image while the download scratchpad updates.

In Figure 4-11, the executable image disables writes and is locked until Reset during the firmware update process. This prevents the existing firmware image being written during the firmware download process. If the image download is incomplete, corrupted or invalid in any way, the boot code can load the existing firmware executable image. Since the executable image is locked until Reset during the download process to protect the image, after the new image is received, a Reset is required to install the new image to the executable memory range, if it passes all appropriate checks (e.g. integrity, authenticity, anti-rollback, etc.).

During the firmware update process, the availability, integrity and authentication of the executable code image is the same, as described in more detail in First Mutable Code in Flash.

Key Considerations:

A second memory area is required to cache an incoming firmware update to verify the integrity and authenticity of the code before committing/installing the update.
If the download scratchpad is in internal Flash, consider protecting the existing firmware image by disabling write protections to the existing image during the download to protect the integrity and authenticity of that image.