API Usage/deployment use cases

[athoelke]

The [v0.7 specification] makes some assertions and assumptions about the security model for the systems in which it is used. In particular, it requires that the Update Service (or Bootloader) verifies the firmware image/firmware update: checking the validity of the firmware for the device, ensuring dependencies are satisfied, and authenticating the firmware with a trust anchor stored within the device Root of Trust.

This deployment scenario corresponds to figure 1 or figure 2 below, where there is a trust boundary between the Update Client and the firmware installer.

Figure 1: The Root of Trust protects the Update Service, Firmware Store and Bootloader

Figure 1 corresponds to a system in which the runtime Update Service is protected from the Update Client by a Root of Trust.

Figure 2: The Root of Trust protects the active image and Bootloader

Figure 2 corresponds to a system where the Update Service runs within the same security domain as the Update Client, but a boot-time Root of Trust protects the bootloader and active image from being accessed or manipulated by the rest of the system. A new image for installation is transferred to the Bootloader via the second image.

In Figure 1, either the Update Service, or the bootloader can carry out the image verification. In Figure 2, the Bootloader has to carry out all of the image verification, as it does not trust the other entities to have done this.

Other deployment use cases

As discussed in #13, there is another security model for the system in which the PSA Firmware Update API might be useful. In the design depicted in Figure 3, there is no security boundary between the installation and the Update Client, and the Update Client carries out all of the required update verification.

Figure 3: The Update Client is trusted to implement the firmware update verification policies

In this system, the PSA Firmware Update API is only being used as a Platform Abstraction Layer, but not as an interface to a secure update service.

Question

Should we extend the scope of the PSA Firmware Update API to this use case? - where there is no requirement for the Update Service or Bootloader to implement any verification or authentication checks.

The benefits of permitting such use are that this reduces the fragmentation for Update Client and Update Service software, by making the API usable on more systems. This could make is easier to port an IoT Application to a hardware platform that provides better security for firmware updates, if the same API can be used.

However, this change would mean that an implementation that is compliant with the API is not necessarily an implementation of "secure update". The security of Firmware Update on a system using this API becomes a 'quality of implementation' issue, which should be assessed separately from compliance to the API specification.

[athoelke]

Proposal

Extend the permitted deployment use cases to include the FWU API being used purely as a PAL, where there is no security boundary between the Update Client and the installer (depicted in Figure 3 above).

Clarify the requirements on the API relating to verification of the image.

[bulislaw]

I'm not sure we can stop people doing it anyway. Maybe not forbidding rather than explicitly allowing is the right way forward? It would stop or precent the argument "It's fine - the spec says so". Another question is our reference implementation and any form of certification (if that's something we want to do) which should strictly do/require checks.

There's also backward compatibility with v7 to think about. Although there's some level of separation possible using user/privileged model in practice it may not be used or it may not provide adequate protection.

[athoelke]

Thanks for the feedback. I would tie the relaxation of the requirement to verify the image when installing with the deployment scenario. I.e. for implementations that include a trust boundary between the Client and the Installer, the Installer MUST verify the image before applying the update, and MUST authenticate the image according the system's firmware execution policy.

The reference implementation in TF-M does have the Service running within the Root of Trust, and so it will be required to implement the verification checks.