3. Terminology

This section describes important concepts and consistent terms.

3.1. Image

A firmware update consists of one or more images. An image can be:

• A complete image or a partial diff.

• Compressed.

• Encrypted. For example, using a pre-provisioned device key.

• Encoded.

• Code, data, or both.

• A single component or multiple components that are linked or packaged together.

An implementation may only support the properties that it needs.

An image is always associated with some signed metadata. The signed metadata describes:

• The intended device, which might be a specific instance or class.

• The intended device component. For example, the PSA RoT component.

• The digest of the image.

• Anti-rollback information.

• Any dependencies.

Additional metadata can be included to provide hints or explicit instructions on how to decrypt, decompress or install an image. It may also describe whether the component needs to be restarted.

3.2. Trust anchor

A device contains one or more trust anchors. A trust anchor is used to check if an image and its metadata are signed by a signing authority that the device trusts.

Each trust anchor is pre-provisioned on the device. A trust anchor can be implemented in many ways, but typically takes the form of a public key or certificate chain, depending on the complexity of the trust model.

The management and provisioning of trust anchors is not within the scope of this document.

An example of a trust anchor is the Root of Trust Public Key (ROTPK), which is defined in the Trusted Base System Architecture.

3.3. Installer

An installer is a part of the device that processes an image. An image can be in different states when it is on a device:

• When an image is not installed, the image is referred to as a candidate image.

• When an image is ready to run, it is installed, and the image is referred to as an installed image. The process of converting a candidate image to an installed image is as follows:

  1. An installer verifies that the image metadata is signed by an appropriate trust anchor.

  2. An installer verifies that all installation conditions and dependencies are satisfied.

  3. An installer takes the necessary steps to apply the update. A reboot might be needed during the installation.

• If an image requires a reboot to complete installation, then the image is set to a reboot needed state.

• When an image fails installation, it is referred to as a rejected image. If the severity of the failure is recoverable, the implementation may choose to turn the rejected image into a candidate image again. A rejected image might be marked as invalid and should be erased or overwritten.

• An implementation can optionally support a state where an image is tested for functional correctness before it is fully installed. This state is referred to as a pending install state. An implementation can also choose to support this state for selected types of image. This state must meet all the same security conditions as an installed image.

The architectural states and the permitted transitions are shown in the following diagram:

Implementation note:

For example, an installer might be a secure bootloader or runtime software. An installer can also be split across multiple components.

Some devices require protection against failure of a new image by retention of a known good image, normally the current image. This implies sufficient NVM to store two images. The simplest case is when both images might be stored on the device in eFlash, in which case the eFlash has to be dimensioned for two image slots, a primary slot and a secondary slot. The same principle can be applied for external flash. A system that uses two slots with a hardware banking mechanism might contain installed images in both slots.

3.4. Update client

A software component that downloads images. It may initiate the download (pull model) or wait until it recieves a notification to fetch (push model).

The Update client runs as part of the application firmware.

It may report device identity and installation state to a remote party using the PSA Attestation API [PSA-ATT], which returns an Entity Attestation Token (EAT). For example, the reported installation state can include the versions of installed images and error information of images that did not install successfully.

When it downloads an image, it transfers it to the installer using the interface described in this document.

3.5. Secure Processing Environment (SPE)

An isolated environment that hosts the PSA Root of Trust and Application Root of Trust. It is isolated from the Non-secure Processing Environment (NSPE).

The SPE protects the trust anchors.

The SPE is an installer and installs SPE images. In some constrained implementations, it may also install NSPE images.

The SPE also contains storage that is protected from the NSPE and from physical snooping.

The SPE also contains the secure bootloader needed for Trusted Boot, see PSA Trusted Boot and Firmware Update [PSA-TB].

The SPE has a means of recovery if a newly installed image fails after an update.

3.6. Staging area

A staging area is an area of memory used to verify an image. The staging area might be in NVM or RAM and thus not guaranteed to be non-volatile. The choice of memory depends on resource constraints and the nature of an update.

The staging area might also be protected by a Secure Processing Environment or resident on another processor.

The size of a staging area is pre-determined by the implementation. This avoids contention of system resources.

An implementation might have one staging area per type of image.

The Update client is responsible for deciding when to erase the staging area.

4. Trust model and scenarios

The following actor definitions are taken from the IETF SUIT architecture draft:

• Author: The author is the entity that creates the firmware image. There may be multiple authors in a system either when a device consists of multiple microcontrollers or when the the final firmware image consists of software components from multiple companies.

• Device Operator: The actor responsible for the day-to-day operation of a fleet of devices.

• Network Operator: The actor responsible for the operation of a network to which devices connect.

• Status Tracker: The status tracker offers device management functionality to retrieve information about the installed firmware on a device and other device characteristics (including free memory and hardware components), to obtain the state of the firmware update cycle the device is currently in, and to trigger the update process. The deployment of status trackers is flexible and they may be used in cloud-based servers, on-premise servers, embedded in edge computing device, etc.

The implementor of the interface described within this document always:

• verifies that the image metadata is signed by a trusted author before installation

• verifies that the image metadata complies with the platform’s security policy

• verifies the image itself using information from the metadata

• trusts authors for specific purposes only (e.g. the NSPE author cannot directly overwrite images in the SPE)

The Update client, the consumer of the interface, is only trusted for the following purposes:

• Downloading images from an approved image repository decided by the Device Operator.

• Selecting the images that the Status Tracker wants installed.

• Obeying the restrictions of the Network Operator.

Depending on the threat model, the following should also be considered:

• If an image is tested before it is permanently installed then a component in the system needs to approve or reject images if they detect a fault during testing. Typically, only a single component can vouch for system wide functional correctness. The update client might be trusted to make decisions during a test.

• Certain images might contain confidential code or data that must never be exposed to the NSPE. Therefore, some images might be encrypted with a key that is private to the SPE and when decryption occurs the data is stored in storage that is inaccessible from the NSPE.