andrius
/
arm-trusted-firmware
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

docs(threat-model): emphasize whether mitigations are implemented 

For each threat, we now separate:
 - how to mitigate against it;
 - whether TF-A currently implements these mitigations.

A new "Mitigations implemented?" box is added to each threat to
provide the implementation status. For threats that are partially
mitigated from platform code, the original text is improved to make
these expectations clearer. The hope is that platform integrators will
have an easier time identifying what they need to carefully implement
in order to follow the security recommendations from the threat model.

Change-Id: I8473d75946daf6c91a0e15e61758c183603e195b
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
This commit is contained in:
Sandrine Bailleux 2022-05-13 12:39:56 +02:00
parent 453abc80b2
commit 7e32cdb21e
1 changed files with 164 additions and 78 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

242
docs/threat_model/threat_model.rst
View File

@ -254,6 +254,18 @@ Threat Assessment
The following threats were identified by applying STRIDE analysis on The following threats were identified by applying STRIDE analysis on
each diagram element of the data flow diagram. each diagram element of the data flow diagram.
For each threat, we strive to indicate whether the mitigations are currently
implemented or not. However, the answer to this question is not always straight
forward. Some mitigations are partially implemented in the generic code but also
rely on the platform code to implement some bits of it. This threat model aims
to be platform-independent and it is important to keep in mind that such threats
only get mitigated if the platform code properly fulfills its responsibilities.
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 | | ID | 01 |
+========================+====================================================+ +========================+====================================================+
@ -286,13 +298,18 @@ each diagram element of the data flow diagram.
+------------------------+------------------+-----------------+---------------+ +------------------------+------------------+-----------------+---------------+
| Total Risk Rating | Critical (25) | Critical (25) | Critical (25) | | Total Risk Rating | Critical (25) | Critical (25) | Critical (25) |
+------------------------+------------------+-----------------+---------------+ +------------------------+------------------+-----------------+---------------+
| Mitigations | | TF-A implements the `Trusted Board Boot (TBB)`_ | | Mitigations | | 1) Implement the `Trusted Board Boot (TBB)`_ |
| | feature which prevents malicious firmware from | | | feature which prevents malicious firmware from |
| | running on the platform by authenticating all | | | running on the platform by authenticating all |
| | firmware images. In addition to this, the TF-A | | | firmware images. |
| | boot firmware performs extra checks on | | | |
| | unauthenticated data, such as FIP metadata, prior| | | | 2) Perform extra checks on unauthenticated data, |
| | to use. | | | 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. |
+------------------------+----------------------------------------------------+ +------------------------+----------------------------------------------------+
+------------------------+----------------------------------------------------+ +------------------------+----------------------------------------------------+
@ -324,22 +341,27 @@ each diagram element of the data flow diagram.
+------------------------+------------------+-----------------+---------------+ +------------------------+------------------+-----------------+---------------+
| Total Risk Rating | Critical (25) | Critical (25) | Critical (25) | | Total Risk Rating | Critical (25) | Critical (25) | Critical (25) |
+------------------------+------------------+-----------------+---------------+ +------------------------+------------------+-----------------+---------------+
| Mitigations | | TF-A supports anti-rollback protection using | | Mitigations | Implement anti-rollback protection using |
| | non-volatile counters (NV counters) as required | | | non-volatile counters (NV counters) as required |
| | by `TBBR-Client specification`_. After a firmware| | | by `TBBR-Client specification`_. |
| | image is validated, the image revision number | +------------------------+----------------------------------------------------+
| | taken from a certificate extension field is | | Mitigations | | Yes / Platform specific. |
| | compared with the corresponding NV counter stored| | implemented? | |
| | in hardware to make sure the new counter value is| | | | After a firmware image is validated, the image |
| | larger or equal to the current counter value. | | | revision number taken from a certificate |
| | Platforms must implement this protection using | | | extension field is compared with the |
| | platform specific hardware NV counters. | | | 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 | | ID | 03 |
+========================+=======================================================+ +========================+=======================================================+
| Threat | | **An attacker can use Time-of-Check-Time-of-Use | | Threat | | **An attacker can use Time-of-Check-Time-of-Use |
| | (TOCTOU) attack to bypass image authentication | | | (TOCTOU) attack to bypass image authentication |
| | during the boot process** | | | during the boot process** |
| | | | | |
@ -370,8 +392,14 @@ each diagram element of the data flow diagram.
+------------------------+---------------------+-----------------+---------------+ +------------------------+---------------------+-----------------+---------------+
| Total Risk Rating | N/A | High (15) | High (15) | | Total Risk Rating | N/A | High (15) | High (15) |
+------------------------+---------------------+-----------------+---------------+ +------------------------+---------------------+-----------------+---------------+
| Mitigations | | TF-A boot firmware copies image to on-chip | | Mitigations | Copy image to on-chip memory before authenticating |
| | memory before authenticating an image. | | | 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. |
+------------------------+-------------------------------------------------------+ +------------------------+-------------------------------------------------------+
+------------------------+-------------------------------------------------------+ +------------------------+-------------------------------------------------------+
@ -415,12 +443,19 @@ each diagram element of the data flow diagram.
+------------------------+---------------------+-----------------+---------------+ +------------------------+---------------------+-----------------+---------------+
| Total Risk Rating | N/A | High (15) | High (15) | | Total Risk Rating | N/A | High (15) | High (15) |
+------------------------+---------------------+-----------------+---------------+ +------------------------+---------------------+-----------------+---------------+
| Mitigations | | The most effective mitigation is adding glitching | | 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 | | | detection and mitigation circuit at the hardware |
| | level. However, software techniques, | | | level. |
| | such as adding redundant checks when performing | | | |
| | conditional branches that are security sensitive, | | | | However, software techniques, such as adding |
| | can be used to harden TF-A against such attacks. | | | 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 | | | **At the moment TF-A doesn't implement such |
| | mitigations.** | | | mitigations.** |
+------------------------+-------------------------------------------------------+ +------------------------+-------------------------------------------------------+
@ -460,11 +495,25 @@ each diagram element of the data flow diagram.
+------------------------+------------------+----------------+---------------+ +------------------------+------------------+----------------+---------------+
| Total Risk Rating | N/A | Medium (8) | Medium (8) | | Total Risk Rating | N/A | Medium (8) | Medium (8) |
+------------------------+------------------+----------------+---------------+ +------------------------+------------------+----------------+---------------+
| Mitigations | | In TF-A, crash reporting is only enabled for | | Mitigations | Remove crash reports in production releases. |
| | debug builds by default. Alternatively, the log | +------------------------+---------------------------------------------------+
| | level can be tuned at build time (from verbose | | Mitigations | | Yes / Platform Specific. |
| | to no output at all), independently of the | | implemented? | Requires the right build options to be used. |
| | build type. | | | |
| | | Crash reporting is only enabled for debug |
| | builds by default, see ``CRASH_REPORTING`` |
| | build option. |
| | |
| | | The log level can be tuned at build time, from |
| | very verbose to no output at all. See |
| | ``LOG_LEVEL`` build option. By default, release |
| | builds are a lot less verbose than debug ones |
| | but still produce some output. |
| | |
| | | Messages produced by the platform code should |
| | use the appropriate level of verbosity so as |
| | not to leak sensitive information in production |
| | builds. |
+------------------------+---------------------------------------------------+ +------------------------+---------------------------------------------------+
+------------------------+----------------------------------------------------+ +------------------------+----------------------------------------------------+
@ -503,11 +552,14 @@ each diagram element of the data flow diagram.
+------------------------+------------------+---------------+-----------------+ +------------------------+------------------+---------------+-----------------+
| Total Risk Rating | N/A | Critical (20) | Critical (20) | | Total Risk Rating | N/A | Critical (20) | Critical (20) |
+------------------------+------------------+---------------+-----------------+ +------------------------+------------------+---------------+-----------------+
| Mitigations | | Configuration of debug and trace capabilities is | | Mitigations | Disable the debug and trace capability for |
| | platform specific. Therefore, platforms must | | | production releases or enable proper debug |
| | disable the debug and trace capability for | | | authentication as recommended by [`DEN0034`_]. |
| | production releases or enable proper debug | +------------------------+----------------------------------------------------+
| | authentication as recommended by [`DEN0034`_]. | | Mitigations | | Platform specific. |
| implemented? | |
| | | Configuration of debug and trace capabilities is |
| | entirely platform specific. |
+------------------------+----------------------------------------------------+ +------------------------+----------------------------------------------------+
+------------------------+------------------------------------------------------+ +------------------------+------------------------------------------------------+
@ -542,9 +594,14 @@ each diagram element of the data flow diagram.
+------------------------+-------------------+----------------+-----------------+ +------------------------+-------------------+----------------+-----------------+
| Total Risk Rating | High (12) | High (12) | High (12) | | Total Risk Rating | High (12) | High (12) | High (12) |
+------------------------+-------------------+----------------+-----------------+ +------------------------+-------------------+----------------+-----------------+
| Mitigations | | The generic TF-A code validates SMC function ids | | Mitigations | Validate SMC function ids and arguments before using |
| | and arguments before using them. | | | them. |
| | Platforms that implement SiP services must also | +------------------------+------------------------------------------------------+
| Mitigations | | Yes / Platform specific. |
| implemented? | |
| | | For standard services, all input is validated. |
| | |
| | | Platforms that implement SiP services must also |
| | validate SMC call arguments. | | | validate SMC call arguments. |
+------------------------+------------------------------------------------------+ +------------------------+------------------------------------------------------+
@ -588,17 +645,12 @@ each diagram element of the data flow diagram.
+------------------------+-------------------+-----------------+----------------+ +------------------------+-------------------+-----------------+----------------+
| Total Risk Rating | High (15) | High (15) | High (15) | | Total Risk Rating | High (15) | High (15) | High (15) |
+------------------------+-------------------+-----------------+----------------+ +------------------------+-------------------+-----------------+----------------+
| Mitigations | | TF-A uses a combination of manual code reviews and | | Mitigations | | 1) Use proper input validation. |
| | automated program analysis and testing to detect |
| | and fix memory corruption bugs. All TF-A code |
| | including platform code go through manual code |
| | reviews. Additionally, static code analysis is |
| | performed using Coverity Scan on all TF-A code. |
| | The code is also tested with |
| | `Trusted Firmware-A Tests`_ on Juno and FVP |
| | platforms. |
| | | | | |
| | | Data received from normal world, such as addresses | | | | 2) Code reviews, testing. |
+------------------------+------------------------------------------------------+
| Mitigations | | 1) Yes. |
| implemented? | Data received from normal world, such as addresses |
| | and sizes identifying memory regions, are | | | and sizes identifying memory regions, are |
| | sanitized before being used. These security checks | | | sanitized before being used. These security checks |
| | make sure that the normal world software does not | | | make sure that the normal world software does not |
@ -612,6 +664,17 @@ each diagram element of the data flow diagram.
| | option to use *asserts* in release builds, however | | | option to use *asserts* in release builds, however |
| | we recommend using proper runtime checks instead | | | we recommend using proper runtime checks instead |
| | of relying on asserts in release builds. | | | of relying on asserts in release builds. |
| | |
| | | 2) Yes. |
| | TF-A uses a combination of manual code reviews |
| | and automated program analysis and testing to |
| | detect and fix memory corruption bugs. All TF-A |
| | code including platform code go through manual |
| | code reviews. Additionally, static code analysis |
| | is performed using Coverity Scan on all TF-A code. |
| | The code is also tested with |
| | `Trusted Firmware-A Tests`_ on Juno and FVP |
| | platforms. |
+------------------------+------------------------------------------------------+ +------------------------+------------------------------------------------------+
+------------------------+------------------------------------------------------+ +------------------------+------------------------------------------------------+
@ -643,10 +706,14 @@ each diagram element of the data flow diagram.
+------------------------+-------------------+----------------+-----------------+ +------------------------+-------------------+----------------+-----------------+
| Total Risk Rating | High (12) | High (12) | High (12) | | Total Risk Rating | High (12) | High (12) | High (12) |
+------------------------+-------------------+----------------+-----------------+ +------------------------+-------------------+----------------+-----------------+
| Mitigations | | TF-A saves and restores registers | | Mitigations | Save and restore registers when switching contexts. |
| | by default when switching contexts. Build options | +------------------------+------------------------------------------------------+
| | are also provided to save/restore additional | | Mitigations | | Yes. |
| | registers such as floating-point registers. | | implemented? | |
| | | This is the default behaviour in TF-A. |
| | Build options are also provided to save/restore |
| | additional registers such as floating-point |
| | registers. These should be enabled if required. |
+------------------------+------------------------------------------------------+ +------------------------+------------------------------------------------------+
+------------------------+-----------------------------------------------------+ +------------------------+-----------------------------------------------------+
@ -680,11 +747,17 @@ each diagram element of the data flow diagram.
+------------------------+-------------------+----------------+----------------+ +------------------------+-------------------+----------------+----------------+
| Total Risk Rating | Medium (9) | Medium (9) | Medium (9) | | Total Risk Rating | Medium (9) | Medium (9) | Medium (9) |
+------------------------+-------------------+----------------+----------------+ +------------------------+-------------------+----------------+----------------+
| Mitigations | | TF-A implements software mitigations for Spectre | | Mitigations | Enable appropriate side-channel protections. |
+------------------------+-----------------------------------------------------+
| Mitigations | | Yes / Platform specific. |
| implemented? | |
| | | TF-A implements software mitigations for Spectre |
| | type attacks as recommended by `Cache Speculation | | | type attacks as recommended by `Cache Speculation |
| | Side-channels`_ for the generic code. SiPs should | | | Side-channels`_ for the generic code. |
| | implement similar mitigations for code that is | | | |
| | deemed to be vulnerable to such attacks. | | | | SiPs should implement similar mitigations for |
| | code that is deemed to be vulnerable to such |
| | attacks. |
+------------------------+-----------------------------------------------------+ +------------------------+-----------------------------------------------------+
+------------------------+----------------------------------------------------+ +------------------------+----------------------------------------------------+
@ -720,19 +793,25 @@ each diagram element of the data flow diagram.
+------------------------+-----------------+-----------------+----------------+ +------------------------+-----------------+-----------------+----------------+
| Total Risk Rating | Critical (20) | Critical (20) | Critical (20) | | Total Risk Rating | Critical (20) | Critical (20) | Critical (20) |
+------------------------+-----------------+-----------------+----------------+ +------------------------+-----------------+-----------------+----------------+
| Mitigations | | In TF-A, configuration of the MMU is done | | Mitigations | When configuring access permissions, the |
| | through a translation tables library. The | | | principle of least privilege ought to be |
| | library provides APIs to define memory regions | | | enforced. This means we should not grant more |
| | and assign attributes including memory types and | | | privileges than strictly needed, e.g. code |
| | access permissions. Memory configurations are | | | should be read-only executable, read-only data |
| | platform specific, therefore platforms need make | | | should be read-only execute-never, and so on. |
| | sure the correct attributes are assigned to | +------------------------+----------------------------------------------------+
| | memory regions. When assigning access | | Mitigations | | Platform specific. |
| | permissions, principle of least privilege ought | | implemented? | |
| | to be enforced, i.e. we should not grant more | | | | MMU configuration is platform specific, |
| | privileges than strictly needed, e.g. code | | | therefore platforms need to make sure that the |
| | should be read-only executable, RO data should | | | correct attributes are assigned to memory |
| | be read-only XN, and so on. | | | 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. |
+------------------------+----------------------------------------------------+ +------------------------+----------------------------------------------------+
+------------------------+-----------------------------------------------------+ +------------------------+-----------------------------------------------------+
@ -747,7 +826,7 @@ each diagram element of the data flow diagram.
| | to count events at any exception level and in | | | to count events at any exception level and in |
| | both Secure and Non-secure states. This allows | | | both Secure and Non-secure states. This allows |
| | a Non-secure software (or a lower-level Secure | | | a Non-secure software (or a lower-level Secure |
| | software) to potentially carry out | | | software) to potentially carry out |
| | side-channel timing attacks against TF-A. | | | side-channel timing attacks against TF-A. |
+------------------------+-----------------------------------------------------+ +------------------------+-----------------------------------------------------+
| Diagram Elements | DF5, DF6 | | Diagram Elements | DF5, DF6 |
@ -767,18 +846,25 @@ each diagram element of the data flow diagram.
+------------------------+-------------------+----------------+----------------+ +------------------------+-------------------+----------------+----------------+
| Total Risk Rating | Medium (6) | Medium (6) | Medium (6) | | Total Risk Rating | Medium (6) | Medium (6) | Medium (6) |
+------------------------+-------------------+----------------+----------------+ +------------------------+-------------------+----------------+----------------+
| Mitigations | | TF-A follows mitigation strategies as described | | Mitigations | Follow mitigation strategies as described in |
| | in `Secure Development Guidelines`_. General | | | `Secure Development Guidelines`_. |
| | events and cycle counting in the Secure world is | +------------------------+-----------------------------------------------------+
| | prohibited by default when applicable. However, | | Mitigations | | Yes / platform specific. |
| | on some implementations (e.g. PMUv3) Secure world | | implemented? | |
| | event counting depends on external debug interface| | | | General events and cycle counting in the Secure |
| | signals, i.e. Secure world event counting is | | | world is prohibited by default when applicable. |
| | enabled if external debug is enabled. | | | |
| | Configuration of debug signals is platform | | | | However, on some implementations (e.g. PMUv3) |
| | Secure world event counting depends on external |
| | debug interface signals, i.e. Secure world event |
| | counting is enabled if external debug is enabled. |
| | |
| | | Configuration of debug signals is platform |
| | specific, therefore platforms need to make sure | | | specific, therefore platforms need to make sure |
| | that external debug is disabled in production or | | | that external debug is disabled in production or |
| | proper debug authentication is in place. | | | proper debug authentication is in place. This |
| | should be the case if threat #06 is properly |
| | mitigated. |
+------------------------+-----------------------------------------------------+ +------------------------+-----------------------------------------------------+
-------------- --------------