Djam/arm-trusted-firmware
1
0
Fork 0
mirror of https://github.com/ARM-software/arm-trusted-firmware.git synced 2025-04-24 13:55:56 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Merge changes from topic "sb/split-boot-runtime-threats" into integration

Browse source 
* changes:
  docs(threat-model): classify threats by mitigating entity
  docs(threat-model): club RME note with other assumptions
This commit is contained in:
Sandrine Bailleux 2023-09-06 09:30:40 +02:00 • committed by TrustedFirmware Code Review
commit a4ee7b093c
1 changed files with 389 additions and 352 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

741
docs/threat_model/threat_model.rst
View file

@ -7,10 +7,7 @@ Introduction
This document provides a generic threat model for TF-A firmware. This document provides a generic threat model for TF-A firmware.
.. note:: .. _Target of Evaluation:
This threat model doesn't consider Root and Realm worlds introduced by
:ref:`Realm Management Extension (RME)`.
******************** ********************
Target of Evaluation Target of Evaluation
@ -36,33 +33,12 @@ assumptions:
- There is no Secure-EL2. We don't consider threats that may come with - There is no Secure-EL2. We don't consider threats that may come with
Secure-EL2 software. Secure-EL2 software.
- There are no Root and Realm worlds. These are introduced by :ref:`Realm
Management Extension (RME)`.
- No experimental features are enabled. We do not consider threats that may come - No experimental features are enabled. We do not consider threats that may come
from them. 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 Data Flow Diagram
================= =================
@ -286,201 +262,16 @@ only get mitigated if the platform code properly fulfills its responsibilities.
Also, some mitigations require enabling specific features, which must be Also, some mitigations require enabling specific features, which must be
explicitly turned on via a build flag. explicitly turned on via a build flag.
These are highlighted in the ``Mitigations implemented?`` box. When such conditions must be met, these are highlighted in the ``Mitigations
implemented?`` box.
+------------------------+----------------------------------------------------+ As our :ref:`Target of Evaluation` is made of several, distinct firmware images,
| ID | 01 | 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
| Threat | | **An attacker can mangle firmware images to | are categorized based on the firmware image that should mitigate them.
| | 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. |
+------------------------+----------------------------------------------------+
+------------------------+----------------------------------------------------+ General Threats for All Firmware Images
| 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.** |
+------------------------+-------------------------------------------------------+
+------------------------+---------------------------------------------------+ +------------------------+---------------------------------------------------+
| ID | 05 | | ID | 05 |
@ -597,49 +388,6 @@ These are highlighted in the ``Mitigations implemented?`` box.
| | entirely platform specific. | | | entirely platform specific. |
+------------------------+----------------------------------------------------+ +------------------------+----------------------------------------------------+
+------------------------+------------------------------------------------------+
| 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 | 08 | | ID | 08 |
+========================+======================================================+ +========================+======================================================+
@ -712,6 +460,380 @@ These are highlighted in the ``Mitigations implemented?`` box.
| | platforms. | | | 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 | | ID | 09 |
+========================+======================================================+ +========================+======================================================+
@ -795,60 +917,6 @@ These are highlighted in the ``Mitigations implemented?`` box.
| | attacks. | | | 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 | | ID | 12 |
@ -905,40 +973,9 @@ These are highlighted in the ``Mitigations implemented?`` box.
| | mitigated. | | | mitigated. |
+------------------------+-----------------------------------------------------+ +------------------------+-----------------------------------------------------+
+------------------------+-----------------------------------------------------+
| ID | 13 | Threats to be Mitigated by an External Agent Outside of TF-A
+========================+=====================================================+ ------------------------------------------------------------
| 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 |
+------------------------+-----------------------------------------------------+
+------------------------+-----------------------------------------------------+ +------------------------+-----------------------------------------------------+
| ID | 14 | | ID | 14 |