2. Design goals¶
This section describes the main goals and use cases for the Firmware Update API.
2.1. Suitable for constrained devices¶
The interface is suitable for a range of embedded devices: from those with resource-limited microcontrollers with one or two simple firmware images, to richer devices that have firmware images for multiple subsystems and separated applications.
For example, the following resource constraints can affect the Firmware Update API:
Resource |
Impact on interface requirements |
|---|---|
Volatile memory capacity |
Firmware images must be transferred to the device in blocks small enough to fit in device RAM. |
Non-volatile memory capacity |
Firmware updates must be small enough to be stored in memory prior to installation. |
Delivery bandwidth |
Firmware download can take an extended period of time. The device might restart during this process. |
Energy and power |
Downloading and installing updates must be reliable to avoid wasting energy on failed or repeated update attempts. |
Performance of cryptographic primitives |
The use of cryptographic protection for firmware updates must match the security requirements for the device. |
For devices with sufficient resources, it is recommended to follow the Embedded Base Boot Requirements (EBBR) Specification [EBBR] specification, which prescribes the Unified Extensible Firmware Interface (UEFI) Specification [UEFI] capsule update interface.
2.2. Updating the Platform Root of Trust¶
The Firmware Update API is suitable for updating the device’s Platform Root of Trust (PRoT) firmware.
The Platform Security Model [PSM] requires all of the Updatable Platform Root of Trust firmware to be updatable. This can include bootloaders, Secure Partition Manager, Trusted OS, and runtime services. In some implementations, the PRoT can include a trusted subsystem with its own isolated and updatable firmware.
The [PSM] requirements for firmware update are also reflected in publications such as Foundational Cybersecurity Activities for IoT Device Manufacturers [IR8259] and Cyber Security for Consumer Internet of Things: Baseline Requirements [EN303645], and in certification schemes such as PSA Certified™ Level 2 Lightweight Protection Profile [PSA-CERT]. [PSA-CERT] provides the following definition of the F.FIRMWARE_UPDATE security function, where the Target of Evaluation (TOE) refers to the PRoT:
The TOE verifies the integrity and authenticity of the TOE update prior to performing the update.
The TOE also rejects attempts of firmware downgrade.
2.3. Updating the Application Root of Trust¶
In addition to the PRoT firmware, other services that run in the Secure processing environment (SPE), but outside of the PRoT, can require update via the Firmware Update API. These services may be combined with the updatable PRoT in a single firmware image, or provided in a separate firmware image.
2.4. Flexibility for different trust models¶
There are a number of factors that impact the trust model that is used to authorize device updates and firmware execution. For example:
A device can require firmware updates from multiple, mutually distrustful, firmware vendors.
Regulation can require implementations to use specified Certificate Authorities and PKI.
The entity that signs a firmware image can be distinct from the device owner or operator. An operator of a device can have a security policy that requires additional authorization to the firmware author’s policy.
The Firmware Update API must be flexible enough to support the trust model required for particular products, without imposing unnecessary overheads on constrained devices.
2.5. Protocol independence¶
Different protocols are used to communicate with a device depending on the industry and application context. This includes open protocols, such as Lightweight M2M [LWM2M], and proprietary protocols from cloud service providers. These protocols serve the specific needs of their respective markets.
Some of the protocols have manifest data that is separate from the firmware image.
The Firmware Update API must be independent of the protocol used by the update client to receive an update.
2.6. Transport independence¶
Embedded devices can receive over-the-air (OTA) firmware updates over different transport technologies, depending on the industry and the application. For example, this includes Wi-Fi, LTE, LoRa, and commercial low-power wide-area networks.
Some devices might not be directly connected to a network but may receive updates through a physical interface from an adjacent device, such as UART, CAN bus, or USB.
The Firmware Update API must be independent of the transport used by the update client to receive an update.
Note
The Firmware Update API does not cover reprogramming of a device using a debug interface, for example, JTAG or SWD.
2.7. Firmware format independence¶
Many device manufacturers and cloud service providers have established formats for firmware images and manifests, tailored to the specific needs of their systems and markets.
The Firmware Update API must be independent of the format and encoding of firmware images and manifests, to enable adoption of the interface by systems with existing formats.
Note
New standards for firmware update within IoT are being developed, such as A Firmware Update Architecture for Internet of Things [RFC9019].
This version of the Firmware Update API is suitable for some of the use cases that are defined by A Manifest Information Model for Firmware Updates in Internet of Things (IoT) Devices [RFC9124] and A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest [SUIT-MFST]. For example, where the payloads are integrated in the manifest envelope, or there is just one external payload to the envelope.
Support for the more complex use cases from [RFC9124], with multiple external payloads, is not considered in version 1.0 of the Firmware Update API, but might be in scope for future versions of the interface.
2.8. Flexibility for different hardware designs¶
The Firmware Update API is designed to be reasonably efficient to implement on different system-on-chip (SoC) architectures, while providing a consistent interface for update clients to target.
For example, the Firmware Update API should be effective in the following types of system:
SoCs that use bus filters, or equivalent security IP, to protect the SPE.
SoCs that use multiple CPUs, providing an isolated CPU and memories for the SPE and another for the NSPE.
Simple SoCs that use an MPU or equivalent to protect the SPE.
Systems that have unified on-chip non-volatile memory used for firmware storage.
Systems that have isolated on-chip non-volatile memory used for firmware storage.
Systems that have a mixture of on-chip and external non-volatile memory used for firmware storage.
2.9. Suitable for composite devices¶
Some platforms have independent subsystems that are isolated from the main microprocessor. These subsystems can have their own firmware, which can also require updates. For example, radios, secure elements, secure enclaves, or other kinds of microcontroller.
The Firmware Update API must support an implementation updates these types of subsystem.
2.10. Robust and reliable update¶
Devices that are remotely deployed, or are deployed in large numbers, must use an update process that does not have routine failure modes that result in devices that cannot be remotely recovered.
The Firmware Update API must support an update process that reduces the risk of in-field update failure, without compromising the requirements for secure boot.
Note
A device can also have an additional recovery capability, for example, a separate recovery firmware image that the bootloader can execute if the installed firmware cannot be verified.
The Firmware Update API might be useful for implementation of recovery firmware, but the requirements of recovery firmware are not considered in the interface design.
2.11. Flexibility in implementation design¶
The Firmware Update API is architectural and does not define a single implementation. An implementation can make trade-offs to target specific device needs. For example:
An implementation can provide a more robust solution, while others optimize for device cost.
An implementation can optimize for bandwidth efficiency, while others optimize for simplicity
An implementation can provide fine-grained update of personalization data, while others perform monolithic updates of all code and data.
An implementation can provide enhanced security for stricter markets, such as those which require encrypted firmware images, while others only use the Firmware Update API to provide a common interface across all products.
The Firmware Update API permits the omission of optional features that are not used by the implementation.
