D. Security Risk Assessment¶
This appendix provides a Security Risk Assessment (SRA) of the Firmware Update API. It describes the threats presented by various types of adversary against the security goals for an implementation of the firmware update process, and mitigating actions for those threats.
About this assessment describes the assessment methodology.
Feature definition defines the security problem.
Feature characterization provides additional security design details.
Threats describes the threats and the recommended mitigating actions.
Mitigation summary summarizes the mitigations, and where these are implemented.
D.1. About this assessment¶
D.1.1. Subject and scope¶
This SRA analyses the security of the Firmware Update API itself, not of any specific implementation of the API, or any specific application of the API.
The purpose of the SRA is to identify requirements on the design of the Firmware Update API. Those requirements can arise from threats that directly affect the caller and implementation of the API, but also from threats against the whole firmware update process. As a result, the assessment considers a broad set of threats to the entire firmware update process.
Secure firmware update has been the subject of a number of recent studies and working groups. These examine the challenges faced when implementing over-the-air updates to secure devices at scale, or present architectures for addressing those challenges. For example, see Report from the Internet of Things Software Update (IoTSU) Workshop 2016 [RFC8240], A Firmware Update Architecture for Internet of Things [RFC9019], and A Manifest Information Model for Firmware Updates in Internet of Things (IoT) Devices [RFC9124].
This SRA does not cover the Trusted client deployment architecture. Operation and trust boundaries describes the effects of the deployment model on the security analysis.
Note
This document is not a substitute for performing a security risk assessment of the overall firmware update process for a system that incorporates the Firmware Update API. However, this SRA can be used as a foundation for such an implementation-specific assessment.
D.1.2. Risk assessment methodology¶
Our risk ratings use an approach derived from NIST Special Publication 800-30 Revision 1: Guide for Conducting Risk Assessments [SP800-30]: for each Threat, we determine its Likelihood and the Impact. Each is evaluated on a 5-level scale, as defined in Table 8 and Table 9.
Level |
Definition |
|---|---|
Very Low |
Unlikely to ever occur in practice, or mathematically near impossible |
Low |
The event could occur, but only if the attacker employs significant resources; or it is mathematically unlikely |
Medium |
A motivated, and well-equipped adversary can make it happen within the lifetime of a product based on the feature (resp. of the feature itself) |
High |
Likely to happen within the lifetime of the product or feature |
Very High |
Will happen, and soon (for instance a zero-day) |
Level |
Definition |
Example Effects |
|---|---|---|
Very Low |
Causes virtually no damage |
Probably none |
Low |
The damage can easily be tolerated or absorbed |
There would be a CVE at most |
Medium |
The damage will have a noticeable effect, such as degrading some functionality, but won’t degrade completely the use of the considered functionality |
There would be a CVE at most |
High |
The damage will have a strong effect, such as causing a significant reduction in its functionality or in its security guarantees |
Security Analysts would discuss this at length, there would be papers, blog entries. Partners would complain |
Very High |
The damage will have critical consequences — it could kill the feature, by affecting several of its security guarantees |
It would be quite an event. Partners would complain strongly, and delay or cancel deployment of the feature |
For both Likelihood and Impact, when in doubt always choose the higher value. These two values are combined using Table 10 to determine the Overall Risk of a Threat.
Impact |
|||||
|---|---|---|---|---|---|
Likelihood |
Very Low |
Low |
Medium |
High |
Very High |
Very Low |
Very Low |
Very Low |
Very Low |
Low |
Low |
Low |
Very Low |
Very Low |
Low |
Low |
Medium |
Medium |
Very Low |
Low |
Medium |
Medium |
High |
High |
(Very) Low |
Low |
Medium |
High |
Very High |
Very High |
(Very) Low |
Medium |
High |
Very High |
Very High |
Threats are handled starting from the most severe ones. Mitigations will be devised for these Threats one by one (note that a Mitigation may mitigate more Threats, and one Threat may require the deployment of more than one Mitigation in order to be addressed). Likelihood and Impact will be reassessed assuming that the Mitigations are in place, resulting in a Mitigated Likelihood (this is the value that usually decreases), a Mitigated Impact (it is less common that this value will decrease), and finally a Mitigated Risk. The Analysis is completed when all the Mitigated Risks are at the chosen residual level or lower, which usually is Low or Very Low.
The Mitigating actions that can be taken are defined in the acronym CAST:
Control: Put in place steps to reduce the Likelihood and/or Impact of a Threat, thereby reducing the risk to an acceptable level.
Accept: The threat is considered to be of acceptable risk such that a mitigation is not necessary, or must be accepted because of other constraint or market needs.
Suppress: Remove the feature or process that gives rise to the threat.
Transfer: Identify a more capable or suitable party to address the risk and transfer the responsibility of providing a mitigation for the threat to them.
D.2. Feature definition¶
D.2.1. Introduction¶
Background¶
Using firmware updates to fix vulnerabilities in devices is important, but securing this update mechanism is equally important since security problems are exacerbated by the update mechanism. An update is essentially authorized remote code execution, so any security problems in the update process expose that remote code execution system. Failure to secure the firmware update process will help attackers take control of devices.
Firmware update provides the context in which the Firmware Update API is designed. Figure 16 is a reproduction of Figure 2 that illustrates where the Firmware Update API fits in the overall firmware update process.
Figure 16 A firmware update process¶
Purpose¶
The Firmware Update API separates the software responsible for delivering the new firmware in the device, from the software that is responsible for storing and installing it in the device memory. Figure 16 shows how the Firmware Update API separates an update client, which obtains the new firmware from the update server, from an update service, which stores the firmware in the device memory.
The API enables an update client to be written independently of the firmware storage design, and the update service to be written independently of the delivery mechanism.
Function¶
The Firmware Update API provides an interface by which an update client can query the state of firmware components that are managed by the service, prepare firmware updates for those components, and initiate the installation of the updates.
D.2.2. Lifecycle¶
Figure 17 shows the typical lifecycle of a device that provide firmware updates.
Figure 17 Device lifecycle of a system providing firmware updates¶
The software implementing the on-device firmware update functionality, and the credentials for authorizing the update process, are installed or provisioned to device prior to its operational phase.
The overall firmware update process is active during the operational phase. The Firmware Update API is used within the run-time software to prepare an update. The implementation of the API prepares the update at run-time, and installs the update at boot-time.
D.2.3. Operation and trust boundaries¶
The following operational dataflow diagrams include all of the main components in a firmware update process. Presenting the context in which the Firmware Update API operates aids understanding of the threats and security mitigations, and provides the rationale for some elements of the API design.
The firmware creator and update server components are representative: in a real implementation of the process these roles may be distributed amongst multiple systems and stakeholders.
The Firmware Update API is a C language API. Therefore, any implementation of the API must execute, at least partially, within the context of the calling application. When an implementation includes a trust boundary, the mechanism and protocol for communication across the boundary is implementation defined.
The Firmware Update API supports implementation in various deployment architectures, described in Deployment scenarios. The operation and dataflow of the firmware update process is similar across these deployments. However, the trust boundaries within the device are different.
Figure 18 shows the simplest deployment — trusted client — which has no trust boundaries within the device. The individual dataflows are described in Table 11. This deployment is described in Trusted client.
In the trusted client deployment, the attack surface lies outside of the Firmware Update API and its implementation, and mitigations for relevant threats to this deployment do not result in additional security requirements for the API. However, the threat model for the other deployments are very different, because they have a security boundary inside the implementation that protects the device’s Root of Trust. Deployment models describes the dataflows for the other deployment models.
As a consequence, this SRA does not provide an assessment of the mitigations required for the trusted client deployment architecture. See also Assumptions and constraints.
Figure 18 Operational dataflow diagram for firmware update in a trusted client deployment¶
Dataflow |
Description |
|---|---|
DF.A |
The firmware creator uploads a firmware update to the update server. |
DF.B |
Communication between the update server and a managed device that supports firmware update, to track firmware status and deliver updates. |
DF.C |
The Firmware Update API, used by the update client to query component state and prepare firmware updates for installation. |
DF.D |
Active firmware image state read by the update service. |
DF.E |
Update service i/o to the second image, to read the component state and prepare candidate images for update. |
DF.F |
Bootloader i/o to the active image, to install a firmware image, or to authenticate it. |
DF.G |
Bootloader i/o to the second image, to verify an update and install it. |
D.2.4. Deployment models¶
This SRA is relevant for the deployment architectures — described in Deployment scenarios — that include a Root of Trust within the device.
DM.UNTRUSTED_CLIENT deployment model¶
This deployment model corresponds to the deployment architecture shown in Untrusted client. Figure 19 shows the dataflow diagram for this deployment, and Table 11 describes the dataflows.
A detailed dataflow is provided in Feature characterization.
Figure 19 Operational dataflow diagram for firmware update in an untrusted client deployment¶
DM.UNTRUSTED_STAGING deployment model¶
This deployment model corresponds to the deployment architecture shown in Untrusted staging. Figure 20 shows the dataflow diagram for this deployment. The dataflow is described by Table 11, the same as for DM.UNTRUSTED_CLIENT.
A detailed dataflow is provided in Feature characterization.
Figure 20 Operational dataflow diagram for firmware update in an untrusted staging deployment¶
The second image in the firmware store is accessible to untrusted software. The Root of Trust protects the active image from modification by untrusted software. In this deployment model, there is no benefit from implementing the update service within the Root of Trust:
The update service only communicates with the bootloader via the data in the firmware store.
As the second image can be modified by untrusted components, the content and state of the second image is not trusted until the bootloader has verified the update.
In this deployment model, the update service can be implemented entirely as software library that runs within the update client execution context.
D.2.5. Assumptions and constraints¶
This SRA assumes that the system implements a Root of Trust, with, at least, the following capabilities:
The Root of Trust implements a Secure boot process that ensures that all firmware is authorized prior to execution when the device boots.
The active firmware image cannot be modified by the system after the bootloader has authenticated the firmware.
Although the Firmware Update API can be used to provide a firmware update service in a system that does not have a Root of Trust, or implement Secure boot, such a system is not considered within this SRA.
Attacks against the firmware supply chain are not considered as part of this assessment. It is assumed that firmware creators and the off-device update infrastructure are designed to protect the credentials and processes that are involved in signing firmware images and updates.
Within the scope of AM.1, the adversary is assumed to have the ability to execute software within the context of the caller of the Firmware Update API, or other untrusted components. The adversary is assumed to not have software execution capability within the Root of Trust.
For example, this might be achieved by an adversary that initially has remote access to the device (AM.0), who then exploits a vulnerability in the firmware to achieved local code execution (AM.1).
Reliable update is a design goal for the Firmware Update API. That is, the firmware update process is robust against failures that would result in an inoperable device. However, the API cannot prevent a denial of service of the overall firmware update process, and this is not in scope for this SRA.
This API is designed for implementation in small microprocessor systems, which generally use SRAM or PSRAM memory, rather than the DDR memories that are typical in larger systems. Attacks against DDR memory, such as Rowhammer, are out of scope for this assessment.
As a result of these assumptions:
Threats to the interfaces outside the device (DF.A and DF.B in Table 11) are equivalent in effect to threats against the interface between the update client and update service (DF.C). This security analysis focuses on the latter dataflows.
Threats to the interfaces within the Root of Trust are assumed to be mitigated by the Root of Trust implementation.
D.2.6. Stakeholders and assets¶
The following assets are considered in this assessment:
- Device firmware
The device manufacturers (SiP, OEM), and device operator are interested in the integrity and authenticity of the device software.
The firmware developers (SiP, OEM, ISV) might also be concerned about the confidentiality of the firmware. Disclosure of the firmware can reveal confidential IP, or reduce the cost of finding and exploiting a vulnerability in the device.
- Device firmware manifest
The device manufacturers (SiP, OEM), and device operator are interested in the integrity and authenticity of the firmware metadata within the firmware manifest.
- Reliability of device operation
The device operator is concerned about the availability of the device to execute the application firmware.
All stakeholders are concerned about the integrity of their reputation with regards to device security, and liability for security failures. A scalable security flaw related to firmware update, or an inability to use firmware update to address a security issue, can have a significant impact on the stakeholders.
D.2.7. Security goals¶
The following security goals are applicable for all systems which implement the Firmware Update API:
- SG.AUTHENTIC
An adversary is unable to install, or cause to be installed, a firmware image that is not valid and authorized for the device.
- SG.RELIABLE
An adversary is unable to use the firmware update process to render the device inoperable.
The following security goal is applicable for some systems which implement the API:
- SG.CONFIDENTIAL
An adversary is unable to disclose the content of a firmware image.
D.2.8. Adversarial model¶
Adversarial models are descriptions of capabilities that adversaries of systems implementing the Firmware Update API can have, grouped into classes. The adversaries are defined in this way to assist with threat modelling an abstract API, which can have different implementations, in systems with a wide range of security sensitivity.
- AM.0
The Adversary is only capable of accessing data that requires neither physical access to a system containing an implementation of the feature nor the ability to run software on it. This Adversary is intercepting or providing data or requests to the target system via a network or other remote connection.
For instance, the Adversary can:
Read any input and output to the target through external devices.
Provide, forge, replay or modify such inputs and outputs.
Perform timings on the observable operations being done by the target machine, either in normal operation or as a response to crafted inputs. For example, timing attacks on web servers.
- AM.1
The Adversary can additionally mount attacks from software running on a target device implementing the feature. This type of Adversary can run software on the target.
For instance, the Adversary can:
Attempt software exploitation by running software on the target.
Exploit access to any memory mapped configuration, monitoring, debug register.
Mount any side channel analysis that relying on software-exposed built-in hardware features to perform physical unit and time measurements.
Perform software-induced glitching of resources such as Rowhammer, RASpberry or crashing the CPU by running intensive tasks.
- AM.2
In addition to the above, the Adversary is capable of mounting hardware attacks and fault injection that does not require breaching the physical envelope of the chips. This type of Adversary has access to a system containing an implementation of the target feature.
For instance, the Adversary can:
Conduct side-channel analysis that requires measurement devices. For example, this can utilize leakage sources such as EM emissions, power consumption, photonics emission, or acoustic channels.
Plug malicious hardware into an unmodified system.
Gain access to the internals of the target system and interpose the SoC or memory for the purposes of reading, blocking, replaying, and injecting transactions.
Replace or add chips on the motherboard.
Make simple, reversible modifications, to perform glitching.
- AM.3
In addition to all the above, the Adversary is capable of performing invasive SoC attacks.
For instance, the Adversary can:
Decapsulate a chip, via laser or chemical etching, followed by microphotography to reverse engineer the chip.
Use a focussed ion beam microscope to perform gate level modification.
The adversarial models that are in scope for a firmware update process depend on the product requirements. To ensure that the Firmware Update API can be used in a wide range of systems, this assessment considers adversarial models AM.0, AM.1, and AM.2 to be in-scope.
D.3. Feature characterization¶
D.3.1. Detailed deployment dataflow¶
The following diagrams expand on the diagrams in Operation and trust boundaries to show the detailed operational dataflow during the firmware update process.
Figure 21 shows the detailed dataflow diagram for the DM.UNTRUSTED_CLIENT deployment, and Table 12 describes each dataflow.
Figure 21 Detailed dataflow diagram for DM.UNTRUSTED_CLIENT¶
The individual dataflows are described in Table 12.
Dataflow |
Description |
|---|---|
DF.1 |
The update service reads status information for the protected, active image, and the unprotected second image. |
DF.2 |
Firmware information in response to Firmware Update API query. |
DF.3 |
[Optional] Client reports device firmware status to online Status Tracker. |
DF.4 |
Firmware creator loads a firmware update containing new firmware images to the update server. Images are signed by firmware creator to authenticate their origin. See Assumptions and constraints. |
DF.5 |
[Optional] Update server issues notification to device about the firmware update. Alternatively, device periodically polls server to discover update. |
DF.6, DF.7 |
Device requests and downloads firmware update images from the update server. |
DF.8 |
Update client uses Firmware Update API to prepare the candidate firmware images for update. |
DF.9 |
Update service writes new firmware images into the firmware store’s staging area. |
DF.10 |
[Optional] Device reports to the update server that the update is ready. Alternatively, the device immediately installs the prepared update. |
DF.11 |
[Optional] Update server issues command to device to apply the update. |
DF.12 |
Update client uses Firmware Update API to request installation of the update. |
DF.13 |
Update service marks the candidate firmware images as ready for installation. |
DF.14 |
Bootloader inspects the second image, to determine if an update is ready for installation. |
DF.15, DF.16 |
Bootloader verifies the update, and installs it as the active image. [Optional] Bootloader retains the previous firmware image for rollback. |
DF.17 |
Bootloader authenticates the firmware image, and then executes it. |
Figure 22 shows the detailed dataflow diagram for the DM.UNTRUSTED_STAGING deployment. The dataflows are described by Table 12, the same as for DM.UNTRUSTED_CLIENT.
Figure 22 Detailed dataflow diagram for DM.UNTRUSTED_STAGING¶
The individual dataflows are described in Table 12.
D.3.2. Security features of the API¶
The following aspects of the Firmware Update API result from the mitigations identified by this assessment:
The behavior of memory buffer parameters is fully specified. See also Pointer conventions.
The API provides a full state model for the firmware update process. See State model. Common variations are also defined in Variation in system design parameters.
Firmware images are not automatically staged for installation after being written to the firmware store, to support atomic update of multiple images. See also Rationale.
A TRIAL state is provided to permit a new firmware image to be tested, and then reverted to the previous image in case of a fault. See also Rationale.
The different deployment models, and variability in the adversarial model in scope for a particular product, requires that the Firmware Update API provides the following features:
Flexibility in when a firmware update is verified: verification errors can be reported from multiple functions. See also Verifying an update.
Some mitigations are required in the format of the firmware image or the firmware manifest. The Firmware Update API does not specify a firmware update format — see Firmware image format — and enables the following aspects to be included in the firmware image or manifest, as required for the implementation:
Compatibility information that identifies the system and component the firmware image is intended for.
Description and verification of dependencies between firmware images.
Authentication of the firmware image and manifest.
Encryption of the firmware image and manifest.
D.4. Threats¶
Because Firmware Update API can be used in a wide range of deployment models and a wide range of threats, not all mitigating actions apply to all scenarios. As a result, various mitigations are optional to implement, depending on which threats exist in a particular domain of application, and which firmware update use cases are important for deployments.
Table 13 summarizes the threats.
Threat |
Description |
|---|---|
Tampering with the firmware image or manifest |
|
Install defective firmware |
|
Install old firmware |
|
Skip intermediate update |
|
Repeatedly install invalid firmware |
|
Call the API with illegal inputs |
|
Modify asset between authentication and use |
|
Trigger installation of incomplete update |
|
Install firmware for a different device |
|
Unauthorized disclosure of a firmware image or manifest |
|
Corrupt image by disrupting installer |
|
Corrupt image by disrupting writes |
|
Verification bypass via glitching |
|
Exploiting or spoofing the update server |
|
Spoofing the firmware creator |
|
Manipulation of network traffic outside the device |
D.4.1. T.TAMPER: Tampering with the firmware image or manifest¶
Description: An attacker modifies the firmware image or firmware manifest to cause a malfunction in the installer.
For example:
If a device misinterprets the format of the firmware image, it may cause a device to install a firmware image incorrectly. An incorrectly installed firmware image would likely cause the device to stop functioning.
If a device installs a firmware image to the wrong location on the device, then it is likely to break.
This can cause device malfunction, or enable elevation of privilege.
Adversarial Model
Security Goal
Unmitigated Impact
High
Unmitigated Likelihood
High
Unmitigated Risk
High
Mitigating Actions
Secure boot (see Assumptions and constraints) will prevent tampered firmware images from executing, but installation of such images can leave the device inoperable.
M.AUTHENTICATE. Transfer to firmware creator and implementation: authenticate the content of the firmware image manifest and firmware images to prevent unauthorized modification. Authentication must occur within a trusted component. For detached manifests this can be achieved by including a cryptographic hash of the firmware image in the manifest, and then signing the manifest with an authorized key. The Firmware Update API design must enable authentication of firmware images and manifests.
Residual Impact
High
Residual Likelihood
Very Low
Residual Risk
Low
D.4.2. T.NON_FUNCTIONAL: Install defective firmware¶
Description: An attacker sends a firmware update to a device that is known to not function correctly. If the firmware update function is non-operational following this update, the device also cannot be recovered without a physical repair.
Adversarial Model
Security Goal
Unmitigated Impact
High
Unmitigated Likelihood
Medium
Unmitigated Risk
Medium
Mitigating Actions
M.TRIAL. Control by API design: provide a firmware image state where a failure to run a new firmware image will cause a roll back to the previously installed firmware, instead of making the device inoperable, without bypassing M.SEQUENCE. Transfer to implementation and update client: use the provided TRIAL state in the firmware update process.
Residual Impact
High
Residual Likelihood
Very Low
Residual Risk
Low
D.4.3. T.ROLLBACK: Install old firmware¶
Description: An attacker sends an old, but otherwise valid, firmware update to a device. If there is a known vulnerability in the provided firmware image, this may allow an attacker to exploit the vulnerability and gain control of the device.
Adversarial Model
Security Goal
Unmitigated Impact
High
Unmitigated Likelihood
Medium
Unmitigated Risk
Medium
Mitigating Actions
M.SEQUENCE. Transfer to the firmware creator and implementation. Firmware images, or their manifests, must be monotonically sequenced for the device, or for each component within a device. The implementation will deny an attempt to install an update with a sequence number that is lower than the currently installed firmware. Verification of sequence numbers must occur within a trusted component.
This mitigation creates a fragility when an update is non-functional, and requires the implementation of M.TRIAL to maintain availability in case of a non-functional update. See also T.NON_FUNCTIONAL.
Residual Impact
High
Residual Likelihood
Very Low
Residual Risk
Low
D.4.4. T.SKIP_INTERMEDIATE: Skip intermediate update¶
Description: An attacker sends a valid firmware update to the device, that requires an intermediate update to be installed first.
Following update the device might operate incorrectly, or can be left completely inoperable.
Adversarial Model
Security Goal
Unmitigated Impact
High
Unmitigated Likelihood
Medium
Unmitigated Risk
Medium
Mitigating Actions
M.CHECK_DEPENDENCY. Transfer to the implementation: dependencies between firmware images are declared in the authenticated firmware image or manifest, and verified by the implementation. Dependency verification must occur within a trusted component. The Firmware Update API design must enable verification of firmware images.
Residual Impact
High
Residual Likelihood
Very Low
Residual Risk
Low
D.4.5. T.DEGRADE_DEVICE: Repeatedly install invalid firmware¶
An attacker repeatedly causes an attempted installation of invalid firmware, to make the installation process disrupt the application availability, exhaust the device power supply, or excessively degrade the firmware store non-volatile memory.
Adversarial Model
Security Goal
Deployment Model
Unmitigated Impact
High
High
Unmitigated Likelihood
Medium
Medium
Unmitigated Risk
Medium
Medium
Mitigating Actions
M.VERIFY_EARLY. Transfer to the update client and the implementation: verify firmware images as early as possible in the update process, to detect and reject an invalid update. This can reduce the storage of invalid image data in the firmware store, prevent unnecessary device reboots, and eliminate installation of firmware that will be rejected by a Secure boot process. The Firmware Update API design must permit verification to occur at all appropriate firmware update operations.
Warning
Although verification outside of the Root of Trust can reduce the likelihood of this threat, it is insufficient to mitigate attackers that can bypass such a check. See also T.TOCTOU.
Residual Impact
High
High
Residual Likelihood
Very Low
Low
Residual Risk
Low
Low
D.4.6. T.INTERFACE_ABUSE: Illegal inputs to the API¶
Description: An attacker can abuse the Firmware Update API. For example:
Passing out of range values to the interface to provoke unexpected behavior of the implementation.
Passing invalid input or output buffers to the interface, that would cause the implementation to access non-existent memory, or memory that is inaccessible to the caller.
Invoking the interface functions out of sequence to cause a malfunction of the implementation.
Using the interface to install attacker-defined firmware images and manifests is covered by T.TAMPER, T.NON_FUNCTIONAL, and T.INCOMPATIBLE.
Note that for DM.UNTRUSTED_STAGING, the attacker can bypass the API entirely as there is no security boundary between the update service and the update client.
Adversarial Model
Security Goal
Deployment Model
Unmitigated Impact
High
High
Unmitigated Likelihood
Medium
Low
Unmitigated Risk
Medium
Low
Mitigating Actions
M.STATE_MODEL. Control by API design: the valid operation sequence for the API is fully specified by the API, to prevent unexpected firmware update states. Responsibility for enforcing the state model is transferred to the implementation.
M.MEMORY_BUFFER. Control by API design: input buffers are fully consumed by the implementation before returning from a function. An implementation must not access the caller’s memory after a function has returned.
M.VALIDATE_PARAMETER. Transfer to the implementation: check all API parameters to lie within valid ranges, including memory access permissions.
Residual Impact
High
High
Residual Likelihood
Very Low
Very Low
Residual Risk
Low
Low
D.4.7. T.TOCTOU: Modify asset between authentication and use¶
Description: An attacker modifies a manifest, or a firmware image, after it is authenticated (time of check) but before it is used (time of use). The attacker can place any content whatsoever in the affected asset.
Adversarial Model
Security Goal
Deployment Model
Unmitigated Impact
High
High
Unmitigated Likelihood
Low
Medium
Unmitigated Risk
Low
Medium
Mitigating Actions
M.PROTECT_THEN_VERIFY. Transfer to the implementation: verification of firmware images and manifests must be done on a copy of the asset that is protected from tampering by untrusted components.
For a DM.UNTRUSTED_STAGING deployment, this requires that everything must be verified by the bootloader.
For a DM.UNTRUSTED_CLIENT deployment, the verification can be implemented within the update service, or the bootloader.
This SRA assumes that Secure boot is implemented, which is the final mitigation to detect unauthorized modification of firmware. See Assumptions and constraints.
See also T.DEGRADE_DEVICE.
Residual Impact
High
High
Residual Likelihood
Very Low
Very Low
Residual Risk
Low
Low
D.4.8. T.PARTIAL_UPDATE: Trigger installation of incomplete update¶
Description: An attacker triggers the installation of an update before all of the candidate firmware images have been prepared.
For example, where an update requires multiple images to be installed concurrently, the attacker might attempt to trigger the installation by forcing the device to restart. A partial installation might render the device inoperable.
Adversarial Model
Security Goal
Unmitigated Impact
High
Unmitigated Likelihood
Medium
Unmitigated Risk
Medium
Mitigating Actions
M.EXPLICIT_STAGING. Control by Firmware Update API design: candidate firmware images that have been prepared are not automatically staged for installation. An explicit API call is used to stage all candidate images.
M.CHECK_DEPENDENCY. Verify that all dependencies are satisfied before installation.
Residual Impact
High
Residual Likelihood
Very Low
Residual Risk
Low
D.4.9. T.INCOMPATIBLE: Mismatched firmware¶
Description: An attacker sends a valid firmware image, for the wrong type of device, signed by a key with firmware installation permission on both device types. This could have wide-ranging consequences. This could cause minor breakage, expose security vulnerabilities, or render devices inoperable.
Adversarial Model
Security Goal
Unmitigated Impact
High
Unmitigated Likelihood
Medium
Unmitigated Risk
Medium
Mitigating Actions
M.COMPATIBILITY. Transfer to the firmware creator and implementation: include authenticated device type information in the manifest, and verify it prior to installation. Verification must occur within a trusted component. The Firmware Update API design must enable authentication of firmware manifests, and validation of device type.
Residual Impact
High
Residual Likelihood
Very Low
Residual Risk
Low
D.4.10. T.DISCLOSURE: Disclosure of protected firmware¶
Description: An attacker wants to mount an attack on the device. To prepare the attack, the provided firmware image is reverse engineered and analyzed for vulnerabilities.
The firmware image might be obtained while in transit from the firmware creator to the device, or while stored in the update server, or on the device prior to installation.
Adversarial Model
Security Goal
Unmitigated Impact
Medium
Unmitigated Likelihood
High
Unmitigated Risk
Medium
Mitigating Actions
M.ENCRYPT. Transfer to the firmware creator and implementation: use encryption to protect the firmware image. The Firmware Update API design must enable the use of encrypted firmware images.
Note
There are challenges when implementing encryption of firmware in a manner that is secure at scale. For example, the problems and some solutions are described in Encrypted Payloads in SUIT Manifests [SUIT-ENC].
Protection of installed firmware images is outside the scope of the firmware update process.
Residual Impact
Medium
Residual Likelihood
Very Low
Residual Risk
Very Low
D.4.11. T.DISRUPT_INSTALL: Corrupt image by disrupting installer¶
Description: An attacker attempts to corrupt the firmware store by causing a device restart while an installation operation is in process. For example, causing a device restart while the bootloader is copying or swapping images, or cleaning the firmware store. After restart the corrupted firmware store can result in an inoperable device.
Note
For implementations where the bootloader does the installation, this threat only relevant for an attacker with physical access (AM.2).
Adversarial Model
Security Goal
Unmitigated Impact
High
Unmitigated Likelihood
Medium
Unmitigated Risk
Medium
Mitigating Actions
M.ROBUST_INSTALL. Transfer to the implementation: updates to the firmware store must be resilient to a power failure or reset interrupting the installation process. This requires that the installer can detect when an update process has been interrupted in this way, and then either recover and resume the installation, or revert to the previous firmware image.
Residual Impact
High
Residual Likelihood
Very Low
Residual Risk
Low
D.4.12. T.DISRUPT_DOWNLOAD: Corrupt image by disrupting writes¶
Description: In a component with a non-volatile WRITING state, an attacker attempts to corrupt the firmware image being staged by causing a device restart while firmware image data is being written. When the update process resumes following restart, an incomplete write might not be detected, or corrected.
Adversarial Model
Security Goal
Unmitigated Impact
High
Unmitigated Likelihood
Medium
Unmitigated Risk
Medium
Mitigating Actions
M.ROBUST_DOWNLOAD. Transfer to the update client and the implementation: implement a protocol for reliably synchronizing the partially written image status between the update client and implementation when the device restarts. This should include detecting situations that cannot be resumed due to incompletely written or corrupted data, and require the update to restart from the beginning.
Note
This threat is related to T.TAMPER. Authentication of the complete image via M.AUTHENTICATE will detect the corruption. However, a device will implement a non-volatile WRITING state when the transfer and storage of firmware update images is relatively expensive. For example, in systems with very low bandwidth, or small energy budgets.
Residual Impact
High
Residual Likelihood
Very Low
Residual Risk
Low
D.4.13. T.FAULT_INJECTION: Verification bypass via glitching¶
Description: An attacker attempts to bypass verification of a firmware update by injecting faults, enabling the installation of non-authentic, non-functional, incompatible, or known to be vulnerable firmware images.
Adversarial Model
Security Goal
Unmitigated Impact
Very High
Unmitigated Likelihood
Low
Unmitigated Risk
Medium
Mitigating Actions
M.FAULT_HARDENING. Transfer to the implementation: use fault-injection-hardening techniques in the design and implementation of the update service and bootloader.
Residual Impact
Very High
Residual Likelihood
Very Low
Residual Risk
Low
D.4.14. T.SERVER: Attack from exploited update server¶
Description: An attacker can impersonate, or exploit the update server to provide attacker-controlled commands and data to the update client.
For the deployment models that are in scope for this SRA, this threat is indistinguishable from T.TAMPER.
D.4.15. T.CREATOR: Attack from spoof firmware creator¶
Description: An attacker can impersonate the firmware creator to upload attacker-controlled firmware images.
For the deployment models that are in scope for this SRA, this threat is indistinguishable from T.TAMPER.
D.4.16. T.NETWORK: Manipulate network traffic¶
Description: An attacker intercepts all traffic to and from a device. The attacker can monitor or modify any data sent to or received from the device.
For the deployment models that are in scope for this SRA, this threat is indistinguishable from T.TAMPER.
D.5. Mitigation summary¶
This section provides a summary of the mitigations described in the threat analysis, organized by the entity responsible for providing the mitigation. Security features of the API lists the API impacts that result from the security assessment.
D.5.1. Architectural mitigations¶
Table 14 lists mitigations that must be included in the design of the Firmware Update API.
Table 15 lists mitigations that need to be included in the design of the firmware image and firmware manifest formats used by the selected firmware update process. An example of a firmware manifest format that provides these features is described in [RFC9124].
Mitigation |
Description |
Mitigated threats |
|---|---|---|
Candidate firmware images that have been prepared require an explicit API call to stage for installation. |
||
The implementation use of memory buffers in the API is fully specified. |
||
The valid operation sequence for the API is fully specified by the API. |
||
Provide a firmware image state where a failure to run a new firmware image will cause a roll back to the previously installed firmware. |
Mitigation |
Description |
Mitigated threats |
|---|---|---|
Authenticate the content of the firmware image manifest and firmware images to prevent unauthorized modification. For detached manifests this can be achieved by including a cryptographic hash of the firmware image in the manifest, and then signing the manifest with an authorized key. |
||
Dependencies between firmware images are declared in the firmware image or manifest. |
||
Include authenticated device type information in the manifest. |
||
Use encryption to protect the firmware image. |
||
Firmware images, or their manifests, must be monotonically sequenced for the device, or for each component within a device. |
D.5.2. Implementation-level mitigations¶
Table 16 lists the mitigations that are transferred to the implementation. These are also known as ‘remediations’.
Mitigation |
Description |
Mitigated threats |
|---|---|---|
Verify the authenticity of the firmware image manifest and firmware images against a trust anchor within the implementation, prior to installation. |
||
Dependencies between firmware images are verified by the implementation prior to installation. |
||
Verify firmware image compatibility prior to installation. |
||
Use cryptographic encryption to protect the firmware image. |
||
Use fault-injection-hardening techniques. |
||
Verification of firmware images and manifests must be done on a copy of the asset that is protected from tampering by untrusted components. |
||
Synchronize a partially written image status between the update client and implementation when the device restarts. |
||
Updates to the firmware store must be resilient to a power failure or reset interrupting the installation process. |
||
Deny an attempt to install an update with a sequence number that is lower than the currently installed firmware. |
||
Enforce the state model defined by the API. |
||
Use the provided TRIAL state in the firmware update process, to enable recovery of a failed update |
||
Check all API parameters to lie within valid ranges, including memory access permissions. |
||
Verify firmware images as early as possible in the update process, to detect and reject an invalid update. |
D.5.3. User-level mitigations¶
Table 17 lists mitigations that are transferred to the application or other external components. These are also known as ‘residual risks’.
Mitigation |
Description |
Mitigated threats |
|---|---|---|
Synchronize a partially written image status between the update client and implementation when the device restarts. |
||
Verify firmware images as early as possible in the update process, to detect and reject an invalid update. |
