-
Notifications
You must be signed in to change notification settings - Fork 10
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
docs(threat model): add Threat Model for RMM
Signed-off-by: Javier Almansa Sobrino <javier.almansasobrino@arm.com> Change-Id: I64b16d55b109c915a7820277ec14dbf290b32647
- Loading branch information
1 parent
6957652
commit 5bf96ce
Showing
8 changed files
with
1,032 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,11 @@ | ||
.. SPDX-License-Identifier: BSD-3-Clause | ||
.. SPDX-FileCopyrightText: Copyright TF-RMM Contributors. | ||
Security | ||
======== | ||
.. toctree:: | ||
:maxdepth: 1 | ||
:caption: Contents | ||
:numbered: | ||
|
||
threat_model/index |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,90 @@ | ||
.. SPDX-License-Identifier: BSD-3-Clause | ||
.. SPDX-FileCopyrightText: Copyright TF-RMM Contributors. | ||
Data Flow Diagram | ||
================= | ||
|
||
This section describes the Data Flow Diagram for RMM. | ||
|
||
******************** | ||
Target of Evaluation | ||
******************** | ||
|
||
In this threat model, the target of evaluation is the Realm Management Monitor | ||
(RMM) in a system context for an Arm A-Class CPU with Realm Management Extension, | ||
as shown on Figure 1. Everything else on Figure 1 is outside of the scope of the | ||
evaluation. | ||
|
||
RMM 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: | ||
|
||
- RMM image is run from either ROM, on-chip trusted SRAM or off-chip DRAM. | ||
Any memory shared with EL3 Firmware is located inside on-chip trusted SRAM. | ||
If RMM runs from off-chip DRAM, then RMM is vulnerable to DRAM attacks | ||
(such as rowhammer) and attacks which can probe and tamper off-chip memory. | ||
|
||
- No experimental features are enabled. We do not consider threats that may come | ||
from them. | ||
|
||
- RME hardware threats and threats covered by the RMM ABI will be covered in a | ||
dedicated Security Risk Analysis document (to be published in the future). | ||
Although there is some overlap with threats mitigated by RME hardware and RMM | ||
ABI, this threat model focuses on covering threats specific to the RMM | ||
implementation and associated data flows. | ||
|
||
***************** | ||
Data Flow Diagram | ||
***************** | ||
|
||
Figure 1 shows a high-level data flow diagram for RMM. The diagram | ||
shows a model of the different components of a RMM system and | ||
their interactions with other FW/SW components. A description of each | ||
diagram element is given in Table 1. In the diagram, the red broken lines | ||
indicate trust boundaries. Components outside of the broken lines | ||
are considered untrusted by RMM. Components inside the broken lines must be | ||
trusted by RMM, as they provide security foundations for its functionality. | ||
|
||
|DFD Diagram| | ||
|
||
.. table:: Table 1: RMM Data Flow Diagram Description | ||
|
||
+-----------------+--------------------------------------------------------+ | ||
| Diagram Element | Description | | ||
+=================+========================================================+ | ||
| DF1 | | At boot time, EL3 Firmware configures RMM through | | ||
| | parameters stored in registers x0 to x3. It also | | ||
| | | passes a Boot Manifest using secure shared memory. | | ||
+-----------------+--------------------------------------------------------+ | ||
| DF2 | | RMM 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 RMM. | | ||
+-----------------+--------------------------------------------------------+ | ||
| DF4 | | Interface for RMM-EL3 communication as per documented| | ||
| | in `RMM-EL3 Runtime Interface`_. RMM trusts EL3, | | ||
| | | which is part of a trusted subsystem. | | ||
+-----------------+--------------------------------------------------------+ | ||
| DF5 | | Realm software can interact with RMM to request | | ||
| | services through the RSI (Realm Service Interface). | | ||
| | | This also includes the PSCI interface. | | ||
+-----------------+--------------------------------------------------------+ | ||
| DF6 | | Regardless of the type of memory from where RMM is | | ||
| | executed, off-chip dynamic RAM (considered | | ||
| | | Non-Secure) may be used to store large data | | ||
| | structures. This memory might be subject to different| | ||
| | | attacks. | | ||
+-----------------+--------------------------------------------------------+ | ||
| DF7 | | NS Host interacts with RMM by issuing SMCs that are | | ||
| | then forwarded from EL3 Firmware to RMM. | | ||
+-----------------+--------------------------------------------------------+ | ||
| DF8 | | This path represents the interaction between RMM and | | ||
| | various hardware IPs such as MMU controller and GIC. | | ||
| | | At boot time, RMM configures/initializes the IPs and | | ||
| | interacts with them at runtime through interrupts | | ||
| | | and registers. | | ||
+-----------------+--------------------------------------------------------+ | ||
|
||
.. |DFD Diagram| image:: ./diagrams/rmm_dfd.drawio.png | ||
.. _RMM-EL3 Runtime Interface: https://trustedfirmware-a.readthedocs.io/en/latest/components/rmm-el3-comms-spec.html#rmm-el3-runtime-interface |
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,13 @@ | ||
.. SPDX-License-Identifier: BSD-3-Clause | ||
.. SPDX-FileCopyrightText: Copyright TF-RMM Contributors. | ||
Threat Model | ||
============ | ||
.. toctree:: | ||
:maxdepth: 1 | ||
:caption: Contents | ||
|
||
introduction | ||
dfd | ||
threat_analysis | ||
threat_assessment |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,14 @@ | ||
.. SPDX-License-Identifier: BSD-3-Clause | ||
.. SPDX-FileCopyrightText: Copyright TF-RMM Contributors. | ||
Introduction | ||
============ | ||
|
||
Threat modeling is an important part of Secure Development Lifecycle (SDL) | ||
that helps us identify potential threats and mitigations affecting a system. | ||
|
||
In the next sections, we present the Threat Model for RMM, giving first a | ||
description of the target of evaluation using a data flow diagram. | ||
Then we provide a list of threats that we have identified based on the | ||
data flow diagram and potential threat mitigations. | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,193 @@ | ||
.. SPDX-License-Identifier: BSD-3-Clause | ||
.. SPDX-FileCopyrightText: Copyright TF-RMM Contributors. | ||
Threat Analysis components | ||
========================== | ||
|
||
In this section we identify all the possible *actors* involved in the Threat | ||
Model. | ||
|
||
For each threat, we will identify the *asset* that is under threat, the | ||
*threat agent* and the *threat type*. Each threat will be given a *risk rating* | ||
that represents the impact and likelihood of that threat. | ||
|
||
Any threat which needs to be mitigated by the RME hardware as well as by EL3 Root | ||
code is out of the scope of this Threat Model. | ||
|
||
****** | ||
Assets | ||
****** | ||
|
||
We have identified the following assets for RMM: | ||
|
||
.. table:: Table 2: RMM Assets | ||
|
||
+--------------------+---------------------------------------------------+ | ||
| Asset | Description | | ||
+====================+===================================================+ | ||
| Sensitive Data | | These include sensitive RMM and Realm data that | | ||
| | an attacker must not be able to tamper with. | | ||
| | | Also, RMM should protect the confidentiality of | | ||
| | of such data. | | ||
+--------------------+---------------------------------------------------+ | ||
| Code Execution | | This represents the requirement that Realms | | ||
| | should only run code in R-EL1/EL0 that is | | ||
| | | allowed by the RMM ABI. The Realm code execution| | ||
| | cannot be hijacked by an attacker. | | ||
| | | This also represents the requirement that RMM | | ||
| | should protect itself from privilege escalation | | ||
| | | and code injection by an attacker into R-EL2. | | ||
| | The RMM execution cannot be hijacked by an | | ||
| | | attacker through the use of the RMM ABI. | | ||
+--------------------+---------------------------------------------------+ | ||
| Availability | | Availability of Realm world is out of scope for | | ||
| | this Threat Model. However, RMM should be | | ||
| | | designed in such a way that neither Realm nor | | ||
| | RMM should significantly affect the availability| | ||
| | | of NS Host and Secure World. | | ||
+--------------------+---------------------------------------------------+ | ||
|
||
************* | ||
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. | ||
|
||
.. table:: Table 3: Threat Agents | ||
|
||
+-------------------+-------------------------------------------------------+ | ||
| Threat Agent | Description | | ||
+===================+=======================================================+ | ||
| RealmCode | | Malicious or faulty code running in the Realm | | ||
| | world, including R-EL0 and R-EL1 levels. | | ||
+-------------------+-------------------------------------------------------+ | ||
| HostSoftware | | Malicious or faulty code running in the Secure or | | ||
| | Non-Secure world, EL0 and EL1 levels. | | ||
+-------------------+-------------------------------------------------------+ | ||
| AppDebug | | Physical adversary using debug build of RMM or | | ||
| | access to debug sources of the system. | | ||
+-------------------+-------------------------------------------------------+ | ||
|
||
There is also a number of Threat Agents which are not covered by this Threat | ||
Model. These are listed in the table below. | ||
|
||
.. table:: Table 4: Threat Agents not covered by this Threat Model | ||
|
||
+-------------------+-------------------------------------------------------+ | ||
| Threat Agent | Description | | ||
+===================+=======================================================+ | ||
| RootCode | | Malicious or faulty code running at Root Level | | ||
| | (e.g. EL3 Firmware). Since RootCode is part of TCB | | ||
| | | of the system, any fault in Root code is usually a | | ||
| | critical vulnerability and not easily mitigated by | | ||
| | | RMM. This Threat is considered out-of-scope of | | ||
| | analysis. | | ||
+-------------------+-------------------------------------------------------+ | ||
| PhysicalAccess | | Physical adversary having access to external device | | ||
| | communication bus and to external flash | | ||
| | | communication bus using common hardware. | | ||
| | | | ||
| | | An advanced physical atacker that has the capability| | ||
| | to tamper with hardware (e.g. "rewiring" a chip | | ||
| | | using a focused ion beam -FIB- workstation or | | ||
| | decapsulate the chip using chemicals). | | ||
+-------------------+-------------------------------------------------------+ | ||
|
||
************ | ||
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 occurring 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. | ||
|
||
.. table:: Table 4: Rating and score as applied to impact and likelihood | ||
|
||
+-----------------------+-------------------------+---------------------------+ | ||
| **Rating (Score)** | **Impact** | **Likelihood** | | ||
+=======================+=========================+===========================+ | ||
| Critical (5) | | Extreme impact to | | Threat is almost | | ||
| | entire organization | certain to be exploited.| | ||
| | if exploited. | | | ||
| | | | Knowledge of the threat | | ||
| | | and how to exploit it | | ||
| | | are in the public | | ||
| | | domain. | | ||
+-----------------------+-------------------------+---------------------------+ | ||
| High (4) | | Major impact to entire| | Threat is relatively | | ||
| | organization or single| easy to detect and | | ||
| | line of business if | exploit by an attacker | | ||
| | exploited | with little skill. | | ||
+-----------------------+-------------------------+---------------------------+ | ||
| Medium (3) | | Noticeable impact to | | A knowledgeable insider | | ||
| | line of business if | or expert attacker could| | ||
| | exploited. | exploit the threat | | ||
| | | | without much difficulty.| | ||
+-----------------------+-------------------------+---------------------------+ | ||
| Low (2) | | Minor damage if | | Exploiting the threat | | ||
| | exploited or could | would require | | ||
| | be used in conjunction| | considerable expertise | | ||
| | with other | and resources | | ||
| | | vulnerabilities to | | | ||
| | perform a more serious| | | ||
| | attack | | | ||
+-----------------------+-------------------------+---------------------------+ | ||
| Informational (1) | | Poor programming | | Threat is not likely | | ||
| | practice or poor | to be exploited on its | | ||
| | design decision that | own, but may be used to | | ||
| | may not represent an | | gain information for | | ||
| | | immediate risk on its | launching another | | ||
| | own, but may have | attack | | ||
| | security implications | | | ||
| | if multiplied and/or | | | ||
| | | combined with other | | | ||
| | threats. | | | ||
+-----------------------+-------------------------+---------------------------+ | ||
|
||
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. | ||
|
||
.. table:: Table 5: Overall risk levels and corresponding aggregate scores | ||
|
||
+---------------------+-----------------------------------+ | ||
| 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 RMM 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 only consider ``Server`` target environments. | ||
|
||
-------------- | ||
|
||
.. _STRIDE threat analysis technique: https://docs.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats#stride-model |
Oops, something went wrong.