Prove & Run’s Secure Firmware Update (SFU) Solution is a set of software components designed to perform secure firmware updates for connected embedded devices. It is pre-integrated with a number of SoCs and boards and is available directly from Prove & Run.
The need for FOTA Systems
Providing firmware updates to devices in the field is now a requirement in most markets. Firmware Over-The-Air (FOTA) management systems:
- Improve the value of existing devices by enhancing their functionality and performance: Tesla motors routinely update the firmware of existing cars to add new features for the benefit of the users.
- Eliminate costly recalls or physical replacements because of functional or security bugs: in 2015, following a well-publicized hack, Jeep had to recall 1.4M cars, a massive expense.
- Reduce testing and support costs by keeping all of your devices at the same version, so there is no need to build-in support to allow newer versions of your software stack to interact with older versions.
But allowing OTA firmware updates is a massive security risk, as any issues with the process enables an attacker to take over the whole device with potentially dire consequences:
- Bricking or otherwise disabling the device
- Leaking confidential and/or private data back to the attacker
- Unlocking restricted features or performing unauthorized modifications
Most importantly, even devices that carry little value can present an important security risk if they can be used as stepping-stones toward larger attacks.
However, building a secure firmware update process is hard as it requires expertise with:
- Hardware and software security architectures
- Extensive security validation and certification processes as any slight error is a potential weakness
The Secure Firmware Update Solution
Prove & Run’s Secure Firmware Update (SFU) Solution offers a pre-integrated solution to these concerns, focused on one crucial goal: Making sure that the firmware of you device stays authentic and cannot be downgraded by an attacker. The SFU Solution:
- Comes pre-integrated with specific SoCs and boards,
- Requires almost no modifications to the OS of a device,
- Is easily adaptable to the requirements and architecture of each device,
- Can be used to secure third party FOTA or firmware management solutions,
- Includes a top quality Secure Boot implementation based on available hardware security features to offer a consistent and high quality root of trust,
- Is cheaper than building your own: Requirements for the core part are similar across markets so there is little value in building a specific firmware update mechanism for each new device,
- Is backed by Prove & Run’s years of expertise in the area of security architectures for embedded devices,
- Can be used and programmed to perform integrity checks during execution,
- Can be used to securely perform post-attack remote actions (platform inspection, corrective actions, etc).
Architecture of the SFU Solution
The SFU Solution is composed of two software bricks: the SFU Client and the SFU Agent.
|SFU Client||SFU Agent|
|Functional Role:||Download the firmware update image and forward it to the SFU Agent||Apply the firmware update image to the board|
|Security Role:||None||Check the authenticity of the firmware update image using stored public keys and prevent version downgrading|
|Executes:||As an application of the Rich OS||On its own in a secure processing area managed by TrustZone®, protected by a Secure Boot anchored using available hardware features|
|Provided as:||A reference implementation with C source code for ease of adaptation to specific functional requirements||A binary pre-integrated with specific SoCs and boards|
Many firmware update solutions are insecure because they rely on agents running in the same address space as the Rich OS (Android, Linux, etc), where they are vulnerable to the huge numbers of local and remote attacks that affect Rich OSs, which makes it impossible to trust the authenticity and confidentiality of the firmware update package.
The SFU Solution is secure because:
- Within a device, the security of the firmware update process does not rely on the Rich OS nor on the SFU Client but only on the SFU Agent.
- The SFU Agent executes in a secure area, protected from attacks coming from the inside (applications running on the Rich OS) or the outside (network connections and peripherals) thanks to TrustZone.
- The kernel of the SFU Agent is formally proven for higher security.
- The authenticity of the SFU Agent is protected by a Secure Boot mechanism anchored in the hardware security features of the board.
- The SFU Agent’s implementation benefits from Prove & Run’s years of expertise developing security applications for embedded applications.
Deploying the SFU Solution
Performing a firmware update with the SFU Solution
- Prepare the updated firmware image as usual
- Create the Secured Firmware Update Image (SFUI) by signing the firmware image
- The user or a firmware management system activates the SFU Client executing as an application of the Rich OS.
- The SFU Client retrieves the SFUI from a remote repository and provides it to the SFU Agent.
- The SFU Agent validates the authenticity of the SFUI so only authentic updates are applied.
- The SFU Agent compares the version of the firmware packaged in the SFUI with the version currently installed on the device and ensures that no downgrade is possible.
- The SFU Agent applies the firmware image packaged in the SFUI to the device.
- The firmware update is complete.
Integrating the SFU Solution with a device
The SFU Solution is available as pre-integrated Packages targeted at specific boards. In order to deploy the solution, one needs to:
- Obtain the pre-integrated SFU Package for your board from Prove & Run,
- Provide a HTTP server to hold the SFUI and configure the SFU Client accordingly,
- Configure the Secure Boot process using Prove & Run’s documentation.
Optionally, the SFU Client reference implementation can be modified so as to comply with a different firmware update delivery mechanism:
- From a local repository (SD card, USB Flash Drive, etc),
- From a remote repository (TFTP, FTP, HTTP, etc), potentially using a delta algorithm to reduce the bandwidth requirement,
- From a third party FOTA system.
The SFU Solution requires an an ARM® Cortex®-A microprocessor and a board with enough available RAM to store one copy of the updated firmware image along with the Rich OS, its applications and the SFU Agent. To obtain a list of compatible boards please contact Prove & Run at .
Content of a SFU Package
- Source code and binary of the reference implementation of the SFU Client
- Binary code of the SFU Agent
- Scripts to create the SFUI
- Deployment documentation