1. Introduction

Firmware update support is an essential property of a PSA device. However, the mechanism to update firmware on a device differs significantly across embedded platforms. This is further complicated by different implementations of a Secure Processing Environment (SPE), which have their own set of firmware that is separate from application firmware.

Some vendors also support a range of different Update clients that may come from third parties, such as ISVs, OEMs or CSPs, in order to support different markets. Likewise, CSPs must integrate their Update clients to work with different device vendor SDKs. The sum of these aspects create a significant integration and maintenance challenge, where there are N device SDKs that needs to integrate with M Update clients.

This document describes a standard interface for updating firmware. By providing a consistent interface for firmware update, update clients and cloud connectors can be written in a more platform independent manner. The scope of the interface is primarily SPE firmware, but can be extended by implementers to cover non-SPE firmware.

The document includes:

2. Design goals

This section describes the main goals of the interface and the rationale.

2.1. Suitable for constrained devices

The interface is suitable for a range of embedded devices: from very simple microcontrollers with one or two flat images, to richer devices that have images for multiple subsystems and separated applications.

Consequentially, the interface is scalable and modular:

  • Scalable: devices only need to implement the functionality that they will use.

  • Modular: larger devices can implement more aspects of the same interface, rather than different interfaces.

A device is assumed to have enough storage for downloading updates over-the-air (OTA). The device is also assumed to have a backup or recovery capability in the event of a failed update. An implementation without such a capability may still choose to implement this interface.

This document does not cover manual reprogramming of a device using a debug interface, such as JTAG or SWD. For more information, see PSA Debug Access Control [PSA-DBG].

In general, these constrained devices are expected to run either bare metal programs or a real-time OS. A device that is not constrained should implement the Embedded Base Boot Requirements [EBBR] specification, which prescribes the UEFI Capsule Update interface. The EBBR specification defines requirements for embedded systems to enable inter-operability between SoCs, hardware platforms, firmware implementations, and operating system distributions. The aim is to establish consistent boot ABIs and behaviour so that supporting new hardware platforms does not require custom engineering work.

2.2. PSA Root of Trust update

The PSA Security Model (SM) requires all of the Mutable PSA Root of Trust firmware to be updateable. This may include bootloaders, SPM, Trusted OS, and runtime services. In some implementations, the PSA RoT may be built using a trusted subsystem with its own isolated and updateable firmware.

The PSA SM requirements for firmware update are also reflected in certifications like NIST IR 8259, ETSI EN 303 645 and PSA Certified. The PSA Certified Protection Profiles describes the following objectives, where the Target of Evaluation (TOE) refers to the PSA RoT:

  • The TOE verifies the integrity and authenticity of the TOE update prior to performing the update.

  • The TOE also rejects attempts of firmware downgrade.

  • This security function mitigates T.UPDATE_ABUSE by preventing installation of firmware from unknown sources or installation of obsolete firmware.

T.UPDATE_ABUSE is defined as:

“An attacker exploits a flaw in the firmware update mechanisms of the TOE, for instance by sending malformed parameters, by altering an authentic firmware update, by installing an old version of the firmware or by bypassing security checks, and installs a flawed version of the PSA updateable root of trust.”

2.3. Application Root of Trust update

In addition to the PSA Root of Trust firmware, unprivileged applications that run in the SPE require updates. The applications may be bundled as a single image or they may be separate images. This is an OEM and supply chain decision.

In some instances, the authority who signs this firmware might be different from the PSA Root of Trust vendor.

2.4. Flexiblility for different trust models

Supply chains dictate a particular trust model for a product. A device may have to support firmware updates from multiple, mutually distrustful firmware vendors.

Some regulations may also require certain implementations to use Certificate Authorities and PKI.

Furthermore, the firmware signer might not be the operator of a device. An operator of a device may have their own security policy that is complimentary to the firmware author’s policy.

The interface must be flexible enough to support a trust model needed by a particular products requirements, without imposing unnecessary requirements 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 LWM2M, and propietary protocols from cloud service providers. These protocols serve the specific needs of their respective markets.

Some of the protocols have metadata that is separate from the images themselves. This is taken into account.

The interface must be independent of the protocol used to recieve an update.

2.6. Transport independence

Embedded devices may recieve firmware updates OTA over different transport media depending on the industry and the application. This may include, but not limited, to Wi-Fi, LTE, LoRa, and commercial low-power wide-area networks (LPWAN).

Some devices might not be directly connected to a network but may recieve updates through a physical interface from an adjacent device, such as UART or a CAN bus.

Firmware installation can take a long time for small devices with very low bandwidth. The device may reboot several times while downloading an update.

The interface must be independent of the transport used to receieve an update.

2.7. Hardware flexibility

The interface is designed to be reasonably efficient to implement on different SoC architectures, while providing a consistent interface for Update clients or cloud connectors to target.

For example, the design should be compatible with the following types of system:

  • Armv8-M based SoCs that use TrustZone, or equivalent security IP, to protect the SPE.

  • SoCs using multiple CPUs, providing an isolated CPU and flash for the SPE and another for the NSPE.

  • Armv7-M, Armv7-R and Armv8-R based SoCs, that use an MPU to protect the SPE.

  • Armv7-A or Armv8-A based SoCs, using TrustZone to protect the SPE.

In addition to the SoC components, board level features provided by OEMs are also considered. This includes peripherals, personalization, and various storage options.

In some system designs, the application firmware may not be able to update itself without interacting with the SPE.

To enable compile-time and design-time optimization, the interface places no requirement on binary compatibility. The interface is therefore described as an Application Programming Interface (API) instead of a binary interface.

2.8. Composite devices

Some platforms have specific subsystems that are isolated from the main application or OS. These subystems have their own firmware that need updating depending on their criticality. For example, this may include radios, secure elements, secure enclaves, or other kinds of microcontroller.

An implementation should be able to support update of these using the interface if this is desired.

2.9. Room for different implementations

The interface is architectural and does not define a single implementation. For example, some implementations can:

  • offer a more robust solution while others optimise for device cost.

  • optimise for bandwidth efficiency while others optimise for simplicity

  • provide fine grained update of personalization data while others perform monoloithic updates of all code and data

  • provide enhanced security for stricter markets.

An implementation chooses what features to support. The interface may also be ported to systems without an SPE for compatibility benefits.