56 KiB
Generic Threat Model
Introduction
This document provides a generic threat model for TF-A firmware.
Note
This threat model doesn't consider Root and Realm worlds introduced by :ref:`Realm Management Extension (RME)`.
System Message: ERROR/3 (<stdin>, line 11); backlink
Unknown interpreted text role "ref".Target of Evaluation
In this threat model, the target of evaluation is the Trusted Firmware for A-class Processors (TF-A). This includes the boot ROM (BL1), the trusted boot firmware (BL2) and the runtime EL3 firmware (BL31) as shown on Figure 1. Everything else on Figure 1 is outside of the scope of the evaluation.
TF-A can be configured in various ways. In this threat model we consider only the most basic configuration. To that end we make the following assumptions:
- All TF-A images are run from either ROM or on-chip trusted SRAM. This means TF-A is not vulnerable to an attacker that can probe or tamper with off-chip memory.
- Trusted boot is enabled. This means an attacker can't boot arbitrary images that are not approved by platform providers.
- There is no Secure-EL2. We don't consider threats that may come with Secure-EL2 software.
Data Flow Diagram
Figure 1 shows a high-level data flow diagram for TF-A. The diagram shows a model of the different components of a TF-A-based system and their interactions with TF-A. A description of each diagram element is given on Table 1. On the diagram, the red broken lines indicate trust boundaries. Components outside of the broken lines are considered untrusted by TF-A.
System Message: ERROR/3 (<stdin>, line 46)
Unknown directive type "uml".
.. uml:: ../resources/diagrams/plantuml/tfa_dfd.puml :caption: Figure 1: TF-A Data Flow Diagram
Diagram Element | Description |
---|---|
DF1 | At boot time, images are loaded from non-volatile
memory and verified by TF-A boot firmware. These
images include TF-A BL2 and BL31 images, as well as
other secure and non-secure images.
|
DF2 | TF-A log system framework outputs debug messages
over a UART interface.
|
DF3 | Debug and trace IP on a platform can allow access
to registers and memory of TF-A.
|
DF4 | Secure world software (e.g. trusted OS) interact
with TF-A through SMC call interface and/or shared
memory.
|
DF5 | Non-secure world software (e.g. rich OS) interact
with TF-A through SMC call interface and/or shared
memory.
|
DF6 | This path represents the interaction between TF-A and
various hardware IPs such as TrustZone controller
and GIC. At boot time TF-A configures/initializes the
IPs and interacts with them at runtime through
interrupts and registers.
|
Threat Analysis
In this section we identify and provide assessment of potential threats to TF-A firmware. The threats are identified for each diagram element on the data flow diagram above.
For each threat, we identify the asset that is under threat, the threat agent and the threat type. Each threat is given a risk rating that represents the impact and likelihood of that threat. We also discuss potential mitigations.
Assets
We have identified the following assets for TF-A:
Asset | Description |
---|---|
Sensitive Data | These include sensitive data that an attacker
must not be able to tamper with (e.g. the Root
of Trust Public Key) or see (e.g. secure logs,
debugging information such as crash reports).
|
Code Execution | This represents the requirement that the
platform should run only TF-A code approved by
the platform provider.
|
Availability | This represents the requirement that TF-A
services should always be available for use.
|
Threat Agents
To understand the attack surface, it is important to identify potential attackers, i.e. attack entry points. The following threat agents are in scope of this threat model.
Threat Agent | Description |
---|---|
NSCode | Malicious or faulty code running in the Non-secure
world, including NS-EL0 NS-EL1 and NS-EL2 levels
|
SecCode | Malicious or faulty code running in the secure
world, including S-EL0 and S-EL1 levels
|
AppDebug | Physical attacker using debug signals to access
TF-A resources
|
PhysicalAccess | Physical attacker having access to external device
communication bus and to external flash
communication bus using common hardware
|
Note
In this threat model an advanced physical attacker that has the capability to tamper with a hardware (e.g. "rewiring" a chip using a focused ion beam (FIB) workstation or decapsulate the chip using chemicals) is considered out-of-scope.
Threat Types
In this threat model we categorize threats using the STRIDE threat analysis technique. In this technique a threat is categorized as one or more of these types: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service or Elevation of privilege.
Threat Risk Ratings
For each threat identified, a risk rating that ranges from informational to critical is given based on the likelihood of the threat occuring if a mitigation is not in place, and the impact of the threat (i.e. how severe the consequences could be). Table 4 explains each rating in terms of score, impact and likelihood.
Rating (Score) | Impact | Likelihood |
---|---|---|
Critical (5) | Extreme impact to
entire organization
if exploited.
|
Threat is almost
certain to be exploited.
Knowledge of the threat
and how to exploit it
are in the public
domain.
|
High (4) | Major impact to entire
organization or single
line of business if
exploited
|
Threat is relatively
easy to detect and
exploit by an attacker
with little skill.
|
Medium (3) | Noticeable impact to
line of business if
exploited.
|
A knowledgeable insider
or expert attacker could
exploit the threat
without much difficulty.
|
Low (2) | Minor damage if
exploited or could
be used in conjunction
with other
vulnerabilities to
perform a more serious
attack
|
Exploiting the threat
would require
considerable expertise
and resources
|
Informational (1) | Poor programming
practice or poor
design decision that
may not represent an
immediate risk on its
own, but may have
security implications
if multiplied and/or
combined with other
threats.
|
Threat is not likely
to be exploited on its
own, but may be used to
gain information for
launching another
attack
|
Aggregate risk scores are assigned to identified threats; specifically, the impact score multiplied by the likelihood score. For example, a threat with high likelihood and low impact would have an aggregate risk score of eight (8); that is, four (4) for high likelihood multiplied by two (2) for low impact. The aggregate risk score determines the finding's overall risk level, as shown in the following table.
Overall Risk Level | Aggregate Risk Score (Impact multiplied by Likelihood) |
---|---|
Critical | 20–25 |
High | 12–19 |
Medium | 6–11 |
Low | 2–5 |
Informational | 1 |
The likelihood and impact of a threat depends on the target environment in which TF-A is running. For example, attacks that require physical access are unlikely in server environments while they are more common in Internet of Things(IoT) environments. In this threat model we consider three target environments: Internet of Things(IoT), Mobile and Server.
Threat Assessment
The following threats were identified by applying STRIDE analysis on each diagram element of the data flow diagram.
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 Components | BL2, BL31 | ||
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 | TF-A implements the Trusted Board Boot (TBB)
feature which prevents malicious firmware from
running on the platform by authenticating all
firmware images. In addition to this, the TF-A
boot firmware performs extra checks on
unauthenticated data, such as FIP metadata, prior
to use.
|
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 Components | BL2, BL31 | ||
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 | TF-A supports anti-rollback protection using
non-volatile counters (NV counters) as required
by TBBR-Client specification. 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 or equal to 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 Components | BL1, BL2 | ||
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 | TF-A boot firmware copies image to on-chip
memory before authenticating an image.
|
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 Components | BL1, BL2 | ||
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 | 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 | ||
---|---|---|---|
Threat | Information leak via UART logs such as
crashes
During the development stages of software it is
common to include crash reports with detailed
information of the CPU state including current
values of the registers, privilege level and
stack dumps. This information is useful when
debugging problems before releasing the
production version, but it could be used by an
attacker to develop a working exploit if left
in the production version.
|
||
Diagram Elements | DF2 | ||
Affected TF-A Components | BL1, BL2, BL31 | ||
Assets | Sensitive Data | ||
Threat Agent | AppDebug | ||
Threat Type | Information Disclosure | ||
Application | Server | IoT | Mobile |
Impact | N/A | Low (2) | Low (2) |
Likelihood | N/A | High (4) | High (4) |
Total Risk Rating | N/A | Medium (8) | Medium (8) |
Mitigations | In TF-A, crash reporting is only enabled for
debug builds by default. Alternatively, the log
level can be tuned at build time (from verbose
to no output at all), independently of the
build type.
|
ID | 06 | ||
---|---|---|---|
Threat | An attacker can read sensitive data and
execute arbitrary code through the external
debug and trace interface
Arm processors include hardware-assisted debug
and trace features that can be controlled without
the need for software operating on the platform.
If left enabled without authentication, this
feature can be used by an attacker to inspect and
modify TF-A registers and memory allowing the
attacker to read sensitive data and execute
arbitrary code.
|
||
Diagram Elements | DF3 | ||
Affected TF-A Components | BL1, BL2, BL31 | ||
Assets | Code Execution, Sensitive Data | ||
Threat Agent | AppDebug | ||
Threat Type | Tampering, Information Disclosure, Elevation of privilege | ||
Application | Server | IoT | Mobile |
Impact | N/A | High (4) | High (4) |
Likelihood | N/A | Critical (5) | Critical (5) |
Total Risk Rating | N/A | Critical (20) | Critical (20) |
Mitigations | Configuration of debug and trace capabilities is
platform specific. Therefore, platforms must
disable the debug and trace capability for
production releases or enable proper debug
authentication as recommended by [DEN0034].
|
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 Components | BL31 | ||
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 | The generic TF-A code validates SMC function ids
and arguments before using them.
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, the Trusted Firmware has
multiple points where memory corruption security
errors can arise. Memory corruption is a dangerous
security issue since it could allow an attacker
to execute arbitrary code, modify some state
variable to change the normal flow of the program,
or leak sensitive information.
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 Components | BL1, BL2, BL31 | ||
Assets | Code Execution, Sensitive Data | ||
Threat Agent | NSCode, SecCode | ||
Threat Type | Tampering, Information Disclosure, Elevation of Privilege | ||
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 | 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.
Data received from normal world, such as addresses
and sizes identifying memory regions, are
sanitized before being used. These security checks
make sure that the normal world software does not
access memory beyond its limit.
By default asserts are only used to check for
programming errors in debug builds. Other types of
errors are handled through condition checks that
remain enabled in release builds. See
TF-A error handling policy. TF-A provides an
option to use asserts in release builds, however
we recommend using proper runtime checks instead
of relying on asserts in release builds.
|
ID | 09 | ||
---|---|---|---|
Threat | Improperly handled SMC calls can leak register
contents
When switching between secure and non-secure
states, register contents of Secure world or
register contents of other normal world clients
can be leaked.
|
||
Diagram Elements | DF5 | ||
Affected TF-A Components | BL31 | ||
Assets | Sensitive Data | ||
Threat Agent | NSCode | ||
Threat Type | Information Disclosure | ||
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 | TF-A saves and restores registers
by default when switching contexts. Build options
are also provided to save/restore additional
registers such as floating-point registers.
|
ID | 10 | ||
---|---|---|---|
Threat | SMC calls can leak sensitive information from
TF-A memory via microarchitectural side channels
Microarchitectural side-channel attacks such as
Spectre can be used to leak data across
security boundaries. An attacker might attempt to
use this kind of attack to leak sensitive
data from TF-A memory.
|
||
Diagram Elements | DF4, DF5 | ||
Affected TF-A Components | BL31 | ||
Assets | Sensitive Data | ||
Threat Agent | SecCode, NSCode | ||
Threat Type | Information Disclosure | ||
Application | Server | IoT | Mobile |
Impact | Medium (3) | Medium (3) | Medium (3) |
Likelihood | Medium (3) | Medium (3) | Medium (3) |
Total Risk Rating | Medium (9) | Medium (9) | Medium (9) |
Mitigations | TF-A implements software mitigations for Spectre
type attacks as recommended by Cache Speculation
Side-channels for the generic code. SiPs should
implement similar mitigations for code that is
deemed to be vulnerable to such attacks.
|
ID | 11 | ||
---|---|---|---|
Threat | Misconfiguration of the Memory Management Unit
(MMU) may allow a normal world software to
access sensitive data or execute arbitrary
code
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 Components | BL1, BL2, BL31 | ||
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 | In TF-A, configuration of the MMU is done
through a translation tables library. The
library provides APIs to define memory regions
and assign attributes including memory types and
access permissions. Memory configurations are
platform specific, therefore platforms need make
sure the correct attributes are assigned to
memory regions. When assigning access
permissions, principle of least privilege ought
to be enforced, i.e. we should not grant more
privileges than strictly needed, e.g. code
should be read-only executable, RO data should
be read-only XN, and so on.
|
ID | 12 | ||
---|---|---|---|
Threat | Incorrect configuration of Performance Monitor
Unit (PMU) counters can allow an attacker to
mount side-channel attacks using information
exposed by the counters
Non-secure software can configure PMU registers
to count events at any exception level and in
both Secure and Non-secure states. This allows
a Non-secure software (or a lower-level Secure
software) to potentially carry out
side-channel timing attacks against TF-A.
|
||
Diagram Elements | DF5, DF6 | ||
Affected TF-A Components | BL31 | ||
Assets | Sensitive Data | ||
Threat Agent | NSCode | ||
Threat Type | Information Disclosure | ||
Impact | Medium (3) | Medium (3) | Medium (3) |
Likelihood | Low (2) | Low (2) | Low (2) |
Total Risk Rating | Medium (6) | Medium (6) | Medium (6) |
Mitigations | TF-A follows mitigation strategies as described
in Secure Development Guidelines. General
events and cycle counting in the Secure world is
prohibited by default when applicable. 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
that external debug is disabled in production or
proper debug authentication is in place.
|
Copyright (c) 2021, Arm Limited. All rights reserved.