github
/
arm-trusted-firmware
mirror of https://github.com/ARM-software/arm-trusted-firmware.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
Browse Source

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

* changes:
  docs(threat-model): classify threats by mitigating entity
  docs(threat-model): club RME note with other assumptions
pull/2000/head
Sandrine Bailleux 1 year ago
committed by TrustedFirmware Code Review
parent
ce64c650e8 a1e121beba
commit
a4ee7b093c
1 changed files with 407 additions and 370 deletions
Whitespace
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Unified View
Diff Options
Show Stats Download Patch File Download Diff File
  1. 777
      docs/threat_model/threat_model.rst

777
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.
+------------------------+----------------------------------------------------+
| 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.** |
+------------------------+----------------------------------------------------+
+------------------------+-------------------------------------------------------+ As our :ref:`Target of Evaluation` is made of several, distinct firmware images,
| ID | 03 | 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 use Time-of-Check-Time-of-Use | are categorized based on the firmware image that should mitigate them.
| | (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. |
+------------------------+-------------------------------------------------------+
+------------------------+-------------------------------------------------------+ General Threats for All Firmware Images
| 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 |
@ -598,74 +389,31 @@ These are highlighted in the ``Mitigations implemented?`` box.
+------------------------+----------------------------------------------------+ +------------------------+----------------------------------------------------+
+------------------------+------------------------------------------------------+ +------------------------+------------------------------------------------------+
| ID | 07 | | ID | 08 |
+========================+======================================================+ +========================+======================================================+
| Threat | | **An attacker can perform a denial-of-service | | Threat | | **Memory corruption due to memory overflows and |
| | attack by using a broken SMC call that causes the | | | lack of boundary checking when accessing resources |
| | system to reboot or enter into unknown state.** | | | 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 | | | | Like in other software, TF-A has multiple points |
| | through SMC calls. Malicious code can attempt to | | | where memory corruption security errors can arise. |
| | place the TF-A runtime into an inconsistent state | | | |
| | by calling unimplemented SMC call or by passing | | | | Some of the errors include integer overflow, |
| | invalid arguments. | | | 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 | | Diagram Elements | DF4, DF5 |
+------------------------+------------------------------------------------------+ +------------------------+------------------------------------------------------+
| Affected TF-A | BL31 | | Affected TF-A | BL1, BL2, BL31 |
| Components | | | 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 Agent | NSCode, SecCode |
+------------------------+------------------------------------------------------+ +------------------------+------------------------------------------------------+
@ -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 |

Write Preview
Loading…
Cancel
Save