docs(threat-model): classify threats by mitigating entity
The generic threat model used to list threats in no particular order.
Reorganize threats so that they are grouped by mitigating entity. For
example, threats mitigated by the boot firmware (i.e. BL1 and BL2) are
now clubbed together, ditto for those mitigated by the runtime EL3
firmware. Note that some generic threats apply to all firmware images
so these get grouped in their own section as well.
The motivations for this refactoring are the following:
- Clarify the scope of the threats.
In particular, as the boot firmware is typically transient, threats
applying to those images can only be exploited during a short
period of time before the runtime firmware starts.
A note has been added to this effect.
- Helping developers implement mitigations in the right place.
- Some vendors have their own solution for booting their device and
only leverage the runtime firmware from the TF-A project. Thus,
they are not interested in the threat model of TF-A's boot
firmware. Isolating the latter in a specific section helps them
focus on what is important for them.
To avoid unnecessary churn, the threats ids have been kept the same.
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Change-Id: Id8616fd0e4b37cd400b1ad3372beb3455234d4dc
diff --git a/docs/threat_model/threat_model.rst b/docs/threat_model/threat_model.rst
index 1d689f5..c50ed8e 100644
--- a/docs/threat_model/threat_model.rst
+++ b/docs/threat_model/threat_model.rst
@@ -7,6 +7,8 @@
This document provides a generic threat model for TF-A firmware.
+.. _Target of Evaluation:
+
********************
Target of Evaluation
********************
@@ -37,30 +39,6 @@
- No experimental features are enabled. We do not consider threats that may come
from them.
-.. note::
-
- In the current Measured Boot design, BL1, BL2, and BL31, as well as the
- secure world components, form the |SRTM|. Measurement data is currently
- considered an asset to be protected against attack, and this is achieved
- by storing them in the Secure Memory.
- Beyond the measurements stored inside the TCG-compliant Event Log buffer,
- there are no other assets to protect or threats to defend against that
- could compromise |TF-A| execution environment's security.
-
- There are general security assets and threats associated with remote/delegated
- attestation. However, these are outside the |TF-A| security boundary and
- should be dealt with by the appropriate agent in the platform/system.
- Since current Measured Boot design does not use local attestation, there would
- be no further assets to protect(like unsealed keys).
-
- A limitation of the current Measured Boot design is that it is dependent upon
- Secure Boot as implementation of Measured Boot does not extend measurements
- into a discrete |TPM|, where they would be securely stored and protected
- against tampering. This implies that if Secure-Boot is compromised, Measured
- Boot may also be compromised.
-
- Platforms must carefully evaluate the security of the default implementation
- since the |SRTM| includes all secure world components.
Data Flow Diagram
=================
@@ -284,201 +262,16 @@
Also, some mitigations require enabling specific features, which must be
explicitly turned on via a build flag.
-These are highlighted in the ``Mitigations implemented?`` box.
-
-+------------------------+----------------------------------------------------+
-| ID | 01 |
-+========================+====================================================+
-| Threat | | **An attacker can mangle firmware images to |
-| | execute arbitrary code** |
-| | |
-| | | Some TF-A images are loaded from external |
-| | storage. It is possible for an attacker to access|
-| | the external flash memory and change its contents|
-| | physically, through the Rich OS, or using the |
-| | updating mechanism to modify the non-volatile |
-| | images to execute arbitrary code. |
-+------------------------+----------------------------------------------------+
-| Diagram Elements | DF1, DF4, DF5 |
-+------------------------+----------------------------------------------------+
-| Affected TF-A | BL2, BL31 |
-| Components | |
-+------------------------+----------------------------------------------------+
-| Assets | Code Execution |
-+------------------------+----------------------------------------------------+
-| Threat Agent | PhysicalAccess, NSCode, SecCode |
-+------------------------+----------------------------------------------------+
-| Threat Type | Tampering, Elevation of Privilege |
-+------------------------+------------------+-----------------+---------------+
-| Application | Server | IoT | Mobile |
-+------------------------+------------------+-----------------+---------------+
-| Impact | Critical (5) | Critical (5) | Critical (5) |
-+------------------------+------------------+-----------------+---------------+
-| Likelihood | Critical (5) | Critical (5) | Critical (5) |
-+------------------------+------------------+-----------------+---------------+
-| Total Risk Rating | Critical (25) | Critical (25) | Critical (25) |
-+------------------------+------------------+-----------------+---------------+
-| Mitigations | | 1) Implement the `Trusted Board Boot (TBB)`_ |
-| | feature which prevents malicious firmware from |
-| | running on the platform by authenticating all |
-| | firmware images. |
-| | |
-| | | 2) Perform extra checks on unauthenticated data, |
-| | such as FIP metadata, prior to use. |
-+------------------------+----------------------------------------------------+
-| Mitigations | | 1) Yes, provided that the ``TRUSTED_BOARD_BOOT`` |
-| implemented? | build option is set to 1. |
-| | |
-| | | 2) Yes. |
-+------------------------+----------------------------------------------------+
-
-+------------------------+----------------------------------------------------+
-| ID | 02 |
-+========================+====================================================+
-| Threat | | **An attacker may attempt to boot outdated, |
-| | potentially vulnerable firmware image** |
-| | |
-| | | When updating firmware, an attacker may attempt |
-| | to rollback to an older version that has unfixed |
-| | vulnerabilities. |
-+------------------------+----------------------------------------------------+
-| Diagram Elements | DF1, DF4, DF5 |
-+------------------------+----------------------------------------------------+
-| Affected TF-A | BL2, BL31 |
-| Components | |
-+------------------------+----------------------------------------------------+
-| Assets | Code Execution |
-+------------------------+----------------------------------------------------+
-| Threat Agent | PhysicalAccess, NSCode, SecCode |
-+------------------------+----------------------------------------------------+
-| Threat Type | Tampering |
-+------------------------+------------------+-----------------+---------------+
-| Application | Server | IoT | Mobile |
-+------------------------+------------------+-----------------+---------------+
-| Impact | Critical (5) | Critical (5) | Critical (5) |
-+------------------------+------------------+-----------------+---------------+
-| Likelihood | Critical (5) | Critical (5) | Critical (5) |
-+------------------------+------------------+-----------------+---------------+
-| Total Risk Rating | Critical (25) | Critical (25) | Critical (25) |
-+------------------------+------------------+-----------------+---------------+
-| Mitigations | Implement anti-rollback protection using |
-| | non-volatile counters (NV counters) as required |
-| | by `TBBR-Client specification`_. |
-+------------------------+----------------------------------------------------+
-| Mitigations | | Yes / Platform specific. |
-| implemented? | |
-| | | After a firmware image is validated, the image |
-| | revision number taken from a certificate |
-| | extension field is compared with the |
-| | corresponding NV counter stored in hardware to |
-| | make sure the new counter value is larger than |
-| | the current counter value. |
-| | |
-| | | **Platforms must implement this protection using |
-| | platform specific hardware NV counters.** |
-+------------------------+----------------------------------------------------+
+When such conditions must be met, these are highlighted in the ``Mitigations
+implemented?`` box.
-+------------------------+-------------------------------------------------------+
-| ID | 03 |
-+========================+=======================================================+
-| Threat | | **An attacker can use Time-of-Check-Time-of-Use |
-| | (TOCTOU) attack to bypass image authentication |
-| | during the boot process** |
-| | |
-| | | Time-of-Check-Time-of-Use (TOCTOU) threats occur |
-| | when the security check is produced before the time |
-| | the resource is accessed. If an attacker is sitting |
-| | in the middle of the off-chip images, they could |
-| | change the binary containing executable code right |
-| | after the integrity and authentication check has |
-| | been performed. |
-+------------------------+-------------------------------------------------------+
-| Diagram Elements | DF1 |
-+------------------------+-------------------------------------------------------+
-| Affected TF-A | BL1, BL2 |
-| Components | |
-+------------------------+-------------------------------------------------------+
-| Assets | Code Execution, Sensitive Data |
-+------------------------+-------------------------------------------------------+
-| Threat Agent | PhysicalAccess |
-+------------------------+-------------------------------------------------------+
-| Threat Type | Elevation of Privilege |
-+------------------------+---------------------+-----------------+---------------+
-| Application | Server | IoT | Mobile |
-+------------------------+---------------------+-----------------+---------------+
-| Impact | N/A | Critical (5) | Critical (5) |
-+------------------------+---------------------+-----------------+---------------+
-| Likelihood | N/A | Medium (3) | Medium (3) |
-+------------------------+---------------------+-----------------+---------------+
-| Total Risk Rating | N/A | High (15) | High (15) |
-+------------------------+---------------------+-----------------+---------------+
-| Mitigations | Copy image to on-chip memory before authenticating |
-| | it. |
-+------------------------+-------------------------------------------------------+
-| Mitigations | | Platform specific. |
-| implemented? | |
-| | | The list of images to load and their location is |
-| | platform specific. Platforms are responsible for |
-| | arranging images to be loaded in on-chip memory. |
-+------------------------+-------------------------------------------------------+
+As our :ref:`Target of Evaluation` is made of several, distinct firmware images,
+some threats are confined in specific images, while others apply to each of
+them. To help developers implement mitigations in the right place, threats below
+are categorized based on the firmware image that should mitigate them.
-+------------------------+-------------------------------------------------------+
-| ID | 04 |
-+========================+=======================================================+
-| Threat | | **An attacker with physical access can execute |
-| | arbitrary image by bypassing the signature |
-| | verification stage using glitching techniques** |
-| | |
-| | | Glitching (Fault injection) attacks attempt to put |
-| | a hardware into a undefined state by manipulating an|
-| | environmental variable such as power supply. |
-| | |
-| | | TF-A relies on a chain of trust that starts with the|
-| | ROTPK, which is the key stored inside the chip and |
-| | the root of all validation processes. If an attacker|
-| | can break this chain of trust, they could execute |
-| | arbitrary code on the device. This could be |
-| | achieved with physical access to the device by |
-| | attacking the normal execution flow of the |
-| | process using glitching techniques that target |
-| | points where the image is validated against the |
-| | signature. |
-+------------------------+-------------------------------------------------------+
-| Diagram Elements | DF1 |
-+------------------------+-------------------------------------------------------+
-| Affected TF-A | BL1, BL2 |
-| Components | |
-+------------------------+-------------------------------------------------------+
-| Assets | Code Execution |
-+------------------------+-------------------------------------------------------+
-| Threat Agent | PhysicalAccess |
-+------------------------+-------------------------------------------------------+
-| Threat Type | Tampering, Elevation of Privilege |
-+------------------------+---------------------+-----------------+---------------+
-| Application | Server | IoT | Mobile |
-+------------------------+---------------------+-----------------+---------------+
-| Impact | N/A | Critical (5) | Critical (5) |
-+------------------------+---------------------+-----------------+---------------+
-| Likelihood | N/A | Medium (3) | Medium (3) |
-+------------------------+---------------------+-----------------+---------------+
-| Total Risk Rating | N/A | High (15) | High (15) |
-+------------------------+---------------------+-----------------+---------------+
-| Mitigations | Mechanisms to detect clock glitch and power |
-| | variations. |
-+------------------------+-------------------------------------------------------+
-| Mitigations | | No. |
-| implemented? | |
-| | | The most effective mitigation is adding glitching |
-| | detection and mitigation circuit at the hardware |
-| | level. |
-| | |
-| | | However, software techniques, such as adding |
-| | redundant checks when performing conditional |
-| | branches that are security sensitive, can be used |
-| | to harden TF-A against such attacks. |
-| | **At the moment TF-A doesn't implement such |
-| | mitigations.** |
-+------------------------+-------------------------------------------------------+
+General Threats for All Firmware Images
+---------------------------------------
+------------------------+---------------------------------------------------+
| ID | 05 |
@@ -596,77 +389,34 @@
+------------------------+----------------------------------------------------+
+------------------------+------------------------------------------------------+
-| ID | 07 |
+| ID | 08 |
+========================+======================================================+
-| Threat | | **An attacker can perform a denial-of-service |
-| | attack by using a broken SMC call that causes the |
-| | system to reboot or enter into unknown state.** |
+| Threat | | **Memory corruption due to memory overflows and |
+| | lack of boundary checking when accessing resources |
+| | could allow an attacker to execute arbitrary code, |
+| | modify some state variable to change the normal |
+| | flow of the program, or leak sensitive |
+| | information** |
| | |
-| | | Secure and non-secure clients access TF-A services |
-| | through SMC calls. Malicious code can attempt to |
-| | place the TF-A runtime into an inconsistent state |
-| | by calling unimplemented SMC call or by passing |
-| | invalid arguments. |
+| | | Like in other software, TF-A has multiple points |
+| | where memory corruption security errors can arise. |
+| | |
+| | | Some of the errors include integer overflow, |
+| | buffer overflow, incorrect array boundary checks, |
+| | and incorrect error management. |
+| | Improper use of asserts instead of proper input |
+| | validations might also result in these kinds of |
+| | errors in release builds. |
+------------------------+------------------------------------------------------+
| Diagram Elements | DF4, DF5 |
+------------------------+------------------------------------------------------+
-| Affected TF-A | BL31 |
+| Affected TF-A | BL1, BL2, BL31 |
| Components | |
+------------------------+------------------------------------------------------+
-| Assets | Availability |
+| Assets | Code Execution, Sensitive Data |
+------------------------+------------------------------------------------------+
| Threat Agent | NSCode, SecCode |
+------------------------+------------------------------------------------------+
-| Threat Type | Denial of Service |
-+------------------------+-------------------+----------------+-----------------+
-| Application | Server | IoT | Mobile |
-+------------------------+-------------------+----------------+-----------------+
-| Impact | Medium (3) | Medium (3) | Medium (3) |
-+------------------------+-------------------+----------------+-----------------+
-| Likelihood | High (4) | High (4) | High (4) |
-+------------------------+-------------------+----------------+-----------------+
-| Total Risk Rating | High (12) | High (12) | High (12) |
-+------------------------+-------------------+----------------+-----------------+
-| Mitigations | Validate SMC function ids and arguments before using |
-| | them. |
-+------------------------+------------------------------------------------------+
-| Mitigations | | Yes / Platform specific. |
-| implemented? | |
-| | | For standard services, all input is validated. |
-| | |
-| | | Platforms that implement SiP services must also |
-| | validate SMC call arguments. |
-+------------------------+------------------------------------------------------+
-
-+------------------------+------------------------------------------------------+
-| ID | 08 |
-+========================+======================================================+
-| Threat | | **Memory corruption due to memory overflows and |
-| | lack of boundary checking when accessing resources |
-| | could allow an attacker to execute arbitrary code, |
-| | modify some state variable to change the normal |
-| | flow of the program, or leak sensitive |
-| | information** |
-| | |
-| | | Like in other software, TF-A has multiple points |
-| | where memory corruption security errors can arise. |
-| | |
-| | | Some of the errors include integer overflow, |
-| | buffer overflow, incorrect array boundary checks, |
-| | and incorrect error management. |
-| | Improper use of asserts instead of proper input |
-| | validations might also result in these kinds of |
-| | errors in release builds. |
-+------------------------+------------------------------------------------------+
-| Diagram Elements | DF4, DF5 |
-+------------------------+------------------------------------------------------+
-| Affected TF-A | BL1, BL2, BL31 |
-| Components | |
-+------------------------+------------------------------------------------------+
-| Assets | Code Execution, Sensitive Data |
-+------------------------+------------------------------------------------------+
-| Threat Agent | NSCode, SecCode |
-+------------------------+------------------------------------------------------+
| Threat Type | Tampering, Information Disclosure, |
| | Elevation of Privilege |
+------------------------+-------------------+-----------------+----------------+
@@ -710,7 +460,381 @@
| | platforms. |
+------------------------+------------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 11 |
++========================+====================================================+
+| Threat | | **Misconfiguration of the Memory Management Unit |
+| | (MMU) may allow a normal world software to |
+| | access sensitive data, execute arbitrary |
+| | code or access otherwise restricted HW |
+| | interface** |
+| | |
+| | | A misconfiguration of the MMU could |
+| | lead to an open door for software running in the |
+| | normal world to access sensitive data or even |
+| | execute code if the proper security mechanisms |
+| | are not in place. |
++------------------------+----------------------------------------------------+
+| Diagram Elements | DF5, DF6 |
++------------------------+----------------------------------------------------+
+| Affected TF-A | BL1, BL2, BL31 |
+| Components | |
++------------------------+----------------------------------------------------+
+| Assets | Sensitive Data, Code execution |
++------------------------+----------------------------------------------------+
+| Threat Agent | NSCode |
++------------------------+----------------------------------------------------+
+| Threat Type | Information Disclosure, Elevation of Privilege |
++------------------------+-----------------+-----------------+----------------+
+| Application | Server | IoT | Mobile |
++------------------------+-----------------+-----------------+----------------+
+| Impact | Critical (5) | Critical (5) | Critical (5) |
++------------------------+-----------------+-----------------+----------------+
+| Likelihood | High (4) | High (4) | High (4) |
++------------------------+-----------------+-----------------+----------------+
+| Total Risk Rating | Critical (20) | Critical (20) | Critical (20) |
++------------------------+-----------------+-----------------+----------------+
+| Mitigations | When configuring access permissions, the |
+| | principle of least privilege ought to be |
+| | enforced. This means we should not grant more |
+| | privileges than strictly needed, e.g. code |
+| | should be read-only executable, read-only data |
+| | should be read-only execute-never, and so on. |
++------------------------+----------------------------------------------------+
+| Mitigations | | Platform specific. |
+| implemented? | |
+| | | MMU configuration is platform specific, |
+| | therefore platforms need to make sure that the |
+| | correct attributes are assigned to memory |
+| | regions. |
+| | |
+| | | TF-A provides a library which abstracts the |
+| | low-level details of MMU configuration. It |
+| | provides well-defined and tested APIs. |
+| | Platforms are encouraged to use it to limit the |
+| | risk of misconfiguration. |
++------------------------+----------------------------------------------------+
+
+
++------------------------+-----------------------------------------------------+
+| ID | 13 |
++========================+=====================================================+
+| Threat | | **Leaving sensitive information in the memory, |
+| | can allow an attacker to retrieve them.** |
+| | |
+| | | Accidentally leaving not-needed sensitive data in |
+| | internal buffers can leak them if an attacker |
+| | gains access to memory due to a vulnerability. |
++------------------------+-----------------------------------------------------+
+| Diagram Elements | DF4, DF5 |
++------------------------+-----------------------------------------------------+
+| Affected TF-A | BL1, BL2, BL31 |
+| Components | |
++------------------------+-----------------------------------------------------+
+| Assets | Sensitive Data |
++------------------------+-----------------------------------------------------+
+| Threat Agent | NSCode, SecCode |
++------------------------+-----------------------------------------------------+
+| Threat Type | Information Disclosure |
++------------------------+-------------------+----------------+----------------+
+| Application | Server | IoT | Mobile |
++------------------------+-------------------+----------------+----------------+
+| Impact | Critical (5) | Critical (5) | Critical (5) |
++------------------------+-------------------+----------------+----------------+
+| Likelihood | Medium (3) | Medium (3) | Medium (3) |
++------------------------+-------------------+----------------+----------------+
+| Total Risk Rating | High (15) | High (15) | High (15) |
++------------------------+-------------------+----------------+----------------+
+| Mitigations | Clear the sensitive data from internal buffers as |
+| | soon as they are not needed anymore. |
++------------------------+-----------------------------------------------------+
+| Mitigations | | Yes / Platform specific |
++------------------------+-----------------------------------------------------+
+
+
+Threats to be Mitigated by the Boot Firmware
+--------------------------------------------
+
+The boot firmware here refers to the boot ROM (BL1) and the trusted boot
+firmware (BL2). Typically it does not stay resident in memory and it is
+dismissed once execution has reached the runtime EL3 firmware (BL31). Thus, past
+that point in time, the threats below can no longer be exploited.
+
+Note, however, that this is not necessarily true on all platforms. Platform
+vendors should review these threats to make sure they cannot be exploited
+nonetheless once execution has reached the runtime EL3 firmware.
+
++------------------------+----------------------------------------------------+
+| ID | 01 |
++========================+====================================================+
+| Threat | | **An attacker can mangle firmware images to |
+| | execute arbitrary code** |
+| | |
+| | | Some TF-A images are loaded from external |
+| | storage. It is possible for an attacker to access|
+| | the external flash memory and change its contents|
+| | physically, through the Rich OS, or using the |
+| | updating mechanism to modify the non-volatile |
+| | images to execute arbitrary code. |
++------------------------+----------------------------------------------------+
+| Diagram Elements | DF1, DF4, DF5 |
++------------------------+----------------------------------------------------+
+| Affected TF-A | BL2, BL31 |
+| Components | |
++------------------------+----------------------------------------------------+
+| Assets | Code Execution |
++------------------------+----------------------------------------------------+
+| Threat Agent | PhysicalAccess, NSCode, SecCode |
++------------------------+----------------------------------------------------+
+| Threat Type | Tampering, Elevation of Privilege |
++------------------------+------------------+-----------------+---------------+
+| Application | Server | IoT | Mobile |
++------------------------+------------------+-----------------+---------------+
+| Impact | Critical (5) | Critical (5) | Critical (5) |
++------------------------+------------------+-----------------+---------------+
+| Likelihood | Critical (5) | Critical (5) | Critical (5) |
++------------------------+------------------+-----------------+---------------+
+| Total Risk Rating | Critical (25) | Critical (25) | Critical (25) |
++------------------------+------------------+-----------------+---------------+
+| Mitigations | | 1) Implement the `Trusted Board Boot (TBB)`_ |
+| | feature which prevents malicious firmware from |
+| | running on the platform by authenticating all |
+| | firmware images. |
+| | |
+| | | 2) Perform extra checks on unauthenticated data, |
+| | such as FIP metadata, prior to use. |
++------------------------+----------------------------------------------------+
+| Mitigations | | 1) Yes, provided that the ``TRUSTED_BOARD_BOOT`` |
+| implemented? | build option is set to 1. |
+| | |
+| | | 2) Yes. |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 02 |
++========================+====================================================+
+| Threat | | **An attacker may attempt to boot outdated, |
+| | potentially vulnerable firmware image** |
+| | |
+| | | When updating firmware, an attacker may attempt |
+| | to rollback to an older version that has unfixed |
+| | vulnerabilities. |
++------------------------+----------------------------------------------------+
+| Diagram Elements | DF1, DF4, DF5 |
++------------------------+----------------------------------------------------+
+| Affected TF-A | BL2, BL31 |
+| Components | |
++------------------------+----------------------------------------------------+
+| Assets | Code Execution |
++------------------------+----------------------------------------------------+
+| Threat Agent | PhysicalAccess, NSCode, SecCode |
++------------------------+----------------------------------------------------+
+| Threat Type | Tampering |
++------------------------+------------------+-----------------+---------------+
+| Application | Server | IoT | Mobile |
++------------------------+------------------+-----------------+---------------+
+| Impact | Critical (5) | Critical (5) | Critical (5) |
++------------------------+------------------+-----------------+---------------+
+| Likelihood | Critical (5) | Critical (5) | Critical (5) |
++------------------------+------------------+-----------------+---------------+
+| Total Risk Rating | Critical (25) | Critical (25) | Critical (25) |
++------------------------+------------------+-----------------+---------------+
+| Mitigations | Implement anti-rollback protection using |
+| | non-volatile counters (NV counters) as required |
+| | by `TBBR-Client specification`_. |
++------------------------+----------------------------------------------------+
+| Mitigations | | Yes / Platform specific. |
+| implemented? | |
+| | | After a firmware image is validated, the image |
+| | revision number taken from a certificate |
+| | extension field is compared with the |
+| | corresponding NV counter stored in hardware to |
+| | make sure the new counter value is larger than |
+| | the current counter value. |
+| | |
+| | | **Platforms must implement this protection using |
+| | platform specific hardware NV counters.** |
++------------------------+----------------------------------------------------+
+
+
++------------------------+-------------------------------------------------------+
+| ID | 03 |
++========================+=======================================================+
+| Threat | | **An attacker can use Time-of-Check-Time-of-Use |
+| | (TOCTOU) attack to bypass image authentication |
+| | during the boot process** |
+| | |
+| | | Time-of-Check-Time-of-Use (TOCTOU) threats occur |
+| | when the security check is produced before the time |
+| | the resource is accessed. If an attacker is sitting |
+| | in the middle of the off-chip images, they could |
+| | change the binary containing executable code right |
+| | after the integrity and authentication check has |
+| | been performed. |
++------------------------+-------------------------------------------------------+
+| Diagram Elements | DF1 |
++------------------------+-------------------------------------------------------+
+| Affected TF-A | BL1, BL2 |
+| Components | |
++------------------------+-------------------------------------------------------+
+| Assets | Code Execution, Sensitive Data |
++------------------------+-------------------------------------------------------+
+| Threat Agent | PhysicalAccess |
++------------------------+-------------------------------------------------------+
+| Threat Type | Elevation of Privilege |
++------------------------+---------------------+-----------------+---------------+
+| Application | Server | IoT | Mobile |
++------------------------+---------------------+-----------------+---------------+
+| Impact | N/A | Critical (5) | Critical (5) |
++------------------------+---------------------+-----------------+---------------+
+| Likelihood | N/A | Medium (3) | Medium (3) |
++------------------------+---------------------+-----------------+---------------+
+| Total Risk Rating | N/A | High (15) | High (15) |
++------------------------+---------------------+-----------------+---------------+
+| Mitigations | Copy image to on-chip memory before authenticating |
+| | it. |
++------------------------+-------------------------------------------------------+
+| Mitigations | | Platform specific. |
+| implemented? | |
+| | | The list of images to load and their location is |
+| | platform specific. Platforms are responsible for |
+| | arranging images to be loaded in on-chip memory. |
++------------------------+-------------------------------------------------------+
+
+
++------------------------+-------------------------------------------------------+
+| ID | 04 |
++========================+=======================================================+
+| Threat | | **An attacker with physical access can execute |
+| | arbitrary image by bypassing the signature |
+| | verification stage using glitching techniques** |
+| | |
+| | | Glitching (Fault injection) attacks attempt to put |
+| | a hardware into a undefined state by manipulating an|
+| | environmental variable such as power supply. |
+| | |
+| | | TF-A relies on a chain of trust that starts with the|
+| | ROTPK, which is the key stored inside the chip and |
+| | the root of all validation processes. If an attacker|
+| | can break this chain of trust, they could execute |
+| | arbitrary code on the device. This could be |
+| | achieved with physical access to the device by |
+| | attacking the normal execution flow of the |
+| | process using glitching techniques that target |
+| | points where the image is validated against the |
+| | signature. |
++------------------------+-------------------------------------------------------+
+| Diagram Elements | DF1 |
++------------------------+-------------------------------------------------------+
+| Affected TF-A | BL1, BL2 |
+| Components | |
++------------------------+-------------------------------------------------------+
+| Assets | Code Execution |
++------------------------+-------------------------------------------------------+
+| Threat Agent | PhysicalAccess |
++------------------------+-------------------------------------------------------+
+| Threat Type | Tampering, Elevation of Privilege |
++------------------------+---------------------+-----------------+---------------+
+| Application | Server | IoT | Mobile |
++------------------------+---------------------+-----------------+---------------+
+| Impact | N/A | Critical (5) | Critical (5) |
++------------------------+---------------------+-----------------+---------------+
+| Likelihood | N/A | Medium (3) | Medium (3) |
++------------------------+---------------------+-----------------+---------------+
+| Total Risk Rating | N/A | High (15) | High (15) |
++------------------------+---------------------+-----------------+---------------+
+| Mitigations | Mechanisms to detect clock glitch and power |
+| | variations. |
++------------------------+-------------------------------------------------------+
+| Mitigations | | No. |
+| implemented? | |
+| | | The most effective mitigation is adding glitching |
+| | detection and mitigation circuit at the hardware |
+| | level. |
+| | |
+| | | However, software techniques, such as adding |
+| | redundant checks when performing conditional |
+| | branches that are security sensitive, can be used |
+| | to harden TF-A against such attacks. |
+| | **At the moment TF-A doesn't implement such |
+| | mitigations.** |
++------------------------+-------------------------------------------------------+
+
+.. topic:: Measured Boot Threats (or lack of)
+
+ In the current Measured Boot design, BL1, BL2, and BL31, as well as the
+ secure world components, form the |SRTM|. Measurement data is currently
+ considered an asset to be protected against attack, and this is achieved
+ by storing them in the Secure Memory.
+ Beyond the measurements stored inside the TCG-compliant Event Log buffer,
+ there are no other assets to protect or threats to defend against that
+ could compromise |TF-A| execution environment's security.
+
+ There are general security assets and threats associated with remote/delegated
+ attestation. However, these are outside the |TF-A| security boundary and
+ should be dealt with by the appropriate agent in the platform/system.
+ Since current Measured Boot design does not use local attestation, there would
+ be no further assets to protect(like unsealed keys).
+
+ A limitation of the current Measured Boot design is that it is dependent upon
+ Secure Boot as implementation of Measured Boot does not extend measurements
+ into a discrete |TPM|, where they would be securely stored and protected
+ against tampering. This implies that if Secure-Boot is compromised, Measured
+ Boot may also be compromised.
+
+ Platforms must carefully evaluate the security of the default implementation
+ since the |SRTM| includes all secure world components.
+
+
+Threats to be Mitigated by the Runtime EL3 Firmware
+---------------------------------------------------
+
+------------------------+------------------------------------------------------+
+| ID | 07 |
++========================+======================================================+
+| Threat | | **An attacker can perform a denial-of-service |
+| | attack by using a broken SMC call that causes the |
+| | system to reboot or enter into unknown state.** |
+| | |
+| | | Secure and non-secure clients access TF-A services |
+| | through SMC calls. Malicious code can attempt to |
+| | place the TF-A runtime into an inconsistent state |
+| | by calling unimplemented SMC call or by passing |
+| | invalid arguments. |
++------------------------+------------------------------------------------------+
+| Diagram Elements | DF4, DF5 |
++------------------------+------------------------------------------------------+
+| Affected TF-A | BL31 |
+| Components | |
++------------------------+------------------------------------------------------+
+| Assets | Availability |
++------------------------+------------------------------------------------------+
+| Threat Agent | NSCode, SecCode |
++------------------------+------------------------------------------------------+
+| Threat Type | Denial of Service |
++------------------------+-------------------+----------------+-----------------+
+| Application | Server | IoT | Mobile |
++------------------------+-------------------+----------------+-----------------+
+| Impact | Medium (3) | Medium (3) | Medium (3) |
++------------------------+-------------------+----------------+-----------------+
+| Likelihood | High (4) | High (4) | High (4) |
++------------------------+-------------------+----------------+-----------------+
+| Total Risk Rating | High (12) | High (12) | High (12) |
++------------------------+-------------------+----------------+-----------------+
+| Mitigations | Validate SMC function ids and arguments before using |
+| | them. |
++------------------------+------------------------------------------------------+
+| Mitigations | | Yes / Platform specific. |
+| implemented? | |
+| | | For standard services, all input is validated. |
+| | |
+| | | Platforms that implement SiP services must also |
+| | validate SMC call arguments. |
++------------------------+------------------------------------------------------+
+
+
++------------------------+------------------------------------------------------+
| ID | 09 |
+========================+======================================================+
| Threat | | **Improperly handled SMC calls can leak register |
@@ -793,60 +917,6 @@
| | attacks. |
+------------------------+-----------------------------------------------------+
-+------------------------+----------------------------------------------------+
-| ID | 11 |
-+========================+====================================================+
-| Threat | | **Misconfiguration of the Memory Management Unit |
-| | (MMU) may allow a normal world software to |
-| | access sensitive data, execute arbitrary |
-| | code or access otherwise restricted HW |
-| | interface** |
-| | |
-| | | A misconfiguration of the MMU could |
-| | lead to an open door for software running in the |
-| | normal world to access sensitive data or even |
-| | execute code if the proper security mechanisms |
-| | are not in place. |
-+------------------------+----------------------------------------------------+
-| Diagram Elements | DF5, DF6 |
-+------------------------+----------------------------------------------------+
-| Affected TF-A | BL1, BL2, BL31 |
-| Components | |
-+------------------------+----------------------------------------------------+
-| Assets | Sensitive Data, Code execution |
-+------------------------+----------------------------------------------------+
-| Threat Agent | NSCode |
-+------------------------+----------------------------------------------------+
-| Threat Type | Information Disclosure, Elevation of Privilege |
-+------------------------+-----------------+-----------------+----------------+
-| Application | Server | IoT | Mobile |
-+------------------------+-----------------+-----------------+----------------+
-| Impact | Critical (5) | Critical (5) | Critical (5) |
-+------------------------+-----------------+-----------------+----------------+
-| Likelihood | High (4) | High (4) | High (4) |
-+------------------------+-----------------+-----------------+----------------+
-| Total Risk Rating | Critical (20) | Critical (20) | Critical (20) |
-+------------------------+-----------------+-----------------+----------------+
-| Mitigations | When configuring access permissions, the |
-| | principle of least privilege ought to be |
-| | enforced. This means we should not grant more |
-| | privileges than strictly needed, e.g. code |
-| | should be read-only executable, read-only data |
-| | should be read-only execute-never, and so on. |
-+------------------------+----------------------------------------------------+
-| Mitigations | | Platform specific. |
-| implemented? | |
-| | | MMU configuration is platform specific, |
-| | therefore platforms need to make sure that the |
-| | correct attributes are assigned to memory |
-| | regions. |
-| | |
-| | | TF-A provides a library which abstracts the |
-| | low-level details of MMU configuration. It |
-| | provides well-defined and tested APIs. |
-| | Platforms are encouraged to use it to limit the |
-| | risk of misconfiguration. |
-+------------------------+----------------------------------------------------+
+------------------------+-----------------------------------------------------+
| ID | 12 |
@@ -903,40 +973,9 @@
| | mitigated. |
+------------------------+-----------------------------------------------------+
-+------------------------+-----------------------------------------------------+
-| ID | 13 |
-+========================+=====================================================+
-| Threat | | **Leaving sensitive information in the memory, |
-| | can allow an attacker to retrieve them.** |
-| | |
-| | | Accidentally leaving not-needed sensitive data in |
-| | internal buffers can leak them if an attacker |
-| | gains access to memory due to a vulnerability. |
-+------------------------+-----------------------------------------------------+
-| Diagram Elements | DF4, DF5 |
-+------------------------+-----------------------------------------------------+
-| Affected TF-A | BL1, BL2, BL31 |
-| Components | |
-+------------------------+-----------------------------------------------------+
-| Assets | Sensitive Data |
-+------------------------+-----------------------------------------------------+
-| Threat Agent | NSCode, SecCode |
-+------------------------+-----------------------------------------------------+
-| Threat Type | Information Disclosure |
-+------------------------+-------------------+----------------+----------------+
-| Application | Server | IoT | Mobile |
-+------------------------+-------------------+----------------+----------------+
-| Impact | Critical (5) | Critical (5) | Critical (5) |
-+------------------------+-------------------+----------------+----------------+
-| Likelihood | Medium (3) | Medium (3) | Medium (3) |
-+------------------------+-------------------+----------------+----------------+
-| Total Risk Rating | High (15) | High (15) | High (15) |
-+------------------------+-------------------+----------------+----------------+
-| Mitigations | Clear the sensitive data from internal buffers as |
-| | soon as they are not needed anymore. |
-+------------------------+-----------------------------------------------------+
-| Mitigations | | Yes / Platform specific |
-+------------------------+-----------------------------------------------------+
+
+Threats to be Mitigated by an External Agent Outside of TF-A
+------------------------------------------------------------
+------------------------+-----------------------------------------------------+
| ID | 14 |