docs/security/threat-model.rst

Generic Threat Model
====================

Threat modeling is a process to identify security requirements, pinpoint security threats and potential vulnerabilities,
quantify threat and vulnerability criticality and prioritize remediation methods.

In the next sections you can find the output of this process the for a generic, use-case and service independent
assessment.

Target evaluation
-----------------

In this threat model, the target of evaluation is the S-EL0 SPs part of the PSA RoT hosting a "generalized" trusted
service.

This evaluation is based on the following assumptions:

    * The implementation is based on the |FF-A| standard.
    * Trusted boot is enabled. This means an attacker can’t boot arbitrary images that are not approved by platform
      providers.
    * Each trusted service is running in an S-EL0 secure partition. Access to memory and hardware is controlled by the
      SPM based on the FF-A manifest or FF-A framework messages.
    * Components running at higher privilege levels than S-EL0 are to be inherently trusted. (I.e. the SPM).

Data flow diagram
-----------------

The data flow diagram visualizes the connection between components and where the data flow crosses security boundaries.

.. image:: ./generic-data-flow.svg
   :target: Attachments_

.. table:: List of data flows

    +-----------+---------------------------------------------------------------------------------+----------+
    | Data flow | Description                                                                     | In scope |
    +-----------+---------------------------------------------------------------------------------+----------+
    | DF1       | Trusted Service interacts with NWd client directly.                             | Yes      |
    +-----------+---------------------------------------------------------------------------------+----------+
    | DF2       | Trusted Service interacts with NWd client through SPM.                          | Yes      |
    +-----------+---------------------------------------------------------------------------------+----------+
    | DF3       | Trusted Services interact through SPM.                                          | Yes      |
    +-----------+---------------------------------------------------------------------------------+----------+
    | DF4       | Trusted Service logs debug information.                                         | Yes      |
    +-----------+---------------------------------------------------------------------------------+----------+
    | DF5       | Trusted Services interact directly.                                             | Yes      |
    +-----------+---------------------------------------------------------------------------------+----------+
    | DF6, DF7  | Trusted Services interacts with shared hardware.                                | Yes      |
    +-----------+---------------------------------------------------------------------------------+----------+
    | DF8       | Trusted Service interacts with dedicated peripheral interface.                  | Yes      |
    +-----------+---------------------------------------------------------------------------------+----------+
    | DF9, DF10 | Trusted Service interacts with shared, external hardware.                       | Yes      |
    +-----------+---------------------------------------------------------------------------------+----------+
    | DF11      | Trusted Service interacts with dedicated, external hardware.                    | Yes      |
    +-----------+---------------------------------------------------------------------------------+----------+
    | DF12      | NWd interacts with more privileged software.                                    | No       |
    +-----------+---------------------------------------------------------------------------------+----------+
    | DF13      | FF-A manifest and other data is handed over to a Trussed Service                | No       |
    +-----------+---------------------------------------------------------------------------------+----------+

Trust boundaries
----------------

.. list-table:: List of trust boundaries

    * - Trust boundary
      - Description
    * - TB1
      - Trust boundary between TEE and normal world.
    * - TB2
      - Trust boundary between higher privilege level SW and Trusted Services.
    * - TB3, TB4
      - Trust boundary between trusted services.
    * - TB5
      - Trust boundary to physically accessible external hardware.

Assets
------

The above dataflow identifies the following generalized assets.

.. table::

    +----------------------+----------------------------------------------------------------------------------+
    | Asset                | Description                                                                      |
    +----------------------+----------------------------------------------------------------------------------+
    | ``availability``     | Availability of a trusted service to clients.                                    |
    +----------------------+----------------------------------------------------------------------------------+
    | ``code execution``   | Code or code flow of a trusted service.                                          |
    +----------------------+----------------------------------------------------------------------------------+
    | ``sensitive data``   | Data that an attacker must not tamper with. These include device identity key,   |
    |                      | Initial Attestation Key, Protected Storage Key, UEFI variables, tpm-event log,   |
    |                      | etc...                                                                           |
    +----------------------+----------------------------------------------------------------------------------+
    |``sensitive hardware``| Hardware that an attacker must not be tamper with. Examples are control interface|
    |                      | of storage medium, true random number generator, crypto accelerator.             |
    +----------------------+----------------------------------------------------------------------------------+

Attackers and threat agents
---------------------------

This section identifies the generalized stakeholders interacting with secure services.

.. list-table::
    :widths: 20,70,10

    * - Attacker/Threat agent
      - Description
      - In scope
    * - ``NSClient``
      - Client executing in the normal world.
      - Yes
    * - ``SClient``
      - Client running in SWd.
      - Yes
    * - ``HPComponent``
      - Components running at higher privilege level than the trusted service.
      - No
    * - ``AppDebug``
      - Physical attacker using debug signals to access resources.
      - Yes
    * - ``PhysAcc``
      - Physical attacker having access to the external device communication bus and to the external flash communication
        bus using common hardware.
      - Yes
    * - ``AdvPhysAcc``
      - Attackers who are able to use specialist hardware for attacks that require irreversible changes to the target
        system (e.g., "rewiring" a chip using a Focused IonBeam FIB workstation).
      - No



Threat Priority
---------------

Threat priority calculation is based on `Common Vulnerability Scoring System`_ (CVSS) Version 3.1. The threat priority
is represented by the `Severity Rating Scale`_ calculated from the CVSS score of each threat. The CVSS score is
calculated using the `Vulnerability Calculator`_.

For each threat the priority and a link to CVSS calculator capturing the calculator settings will be listed.

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``.

.. list-table::
    :widths: 15,80

    * - **ID**
      - 1
    * - Description
      - Information leak via debug logs.

        During development it is common practice to help understanding code execution by emitting
        debug logs.
    * - Data flow
      - DF4
    * - Asset(s)
      - ``Sensitive Data``
    * - Threat Agent/Attacker
      - ``AppDebug``
    * - Threat type
      - ``Information disclosure``
    * - Impact
      - Sensitive information may get to unauthorized people. Information can potentially help
        compromising the target or other systems.
    * - Scoring/CVSS
      - Medium, 4.6 `CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N <https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N>`_
    * - Mitigation
      - Log messages are put to "verbosity categories". Release builds limit printed log messages
        to "error" category.
    * - Mitigation in place
      - yes

.. list-table::
    :widths: 15,80

    * - **ID**
      - 2
    * - Description
      - An attacker can tamper with sensitive data and execute arbitrary code through hardware-assisted
        debug interface.
    * - Data flow
      - N/A.
    * - Asset(s)
      - ``Sensitive Data``, ``Code Execution``, ``Sensitive Hardware``
    * - Threat Agent/Attacker
      - ``AppDebug``
    * - Threat type
      - ``Information disclosure``, ``Tampering``
    * - Impact
      - Sensitive information may get to unauthorized people. Information can potentially help
        compromising the target or other systems.

        An attacker may modify sensitive data and alter device behavior and thus compromise the
        target or other systems.
    * - Scoring/CVSS
      - Medium, 6.8 `CVSS:3.1/AV:P/AC:H/PR:H/UI:R/S:C/C:H/I:H/A:H <https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:P/AC:H/PR:H/UI:R/S:C/C:H/I:H/A:H>`_
    * - Mitigation
      - Hardware platform specific means to disable or limit access to debug functionality.
    * - Mitigation in place
      - yes

.. list-table::
    :widths: 15,80

    * - **ID**
      - 3
    * - Description
      - An attacker can perform a denial-of-service attack by using a broken service call that
        causes the service to enter an unknown state.

        Secure and non-secure clients access a trusted service through FF-A calls. Malicious code
        can attempt to place the service into an inconsistent state by calling unimplemented
        calls or by passing invalid arguments.
    * - Data flow
      - DF1, DF2, DF3, DF5
    * - Asset(s)
      - ``Availability``
    * - Threat Agent/Attacker
      - ``NSclient``, ``SClient``
    * - Threat type
      - ``Denial of service``
    * - Impact
      - The service or the whole system may temporarily or permanently enter an unusable state.
    * - Scoring/CVSS
      - Medium, 6.8 `CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H <https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H>`_
    * - Mitigation
      - The service must validate all inputs before usage. Input validation shall be checked during
        code review and by testing.
    * - Mitigation in place
      - yes

.. list-table::
    :widths: 15,80

    * - **ID**
      - 4
    * - Description
      - Memory corruption due to memory overflows and lack of boundary checking when accessing
        resources.

        Allows an attacker to execute arbitrary code, modify memory content to change
        program flow.
    * - Data flow
      - DF1, DF2, DF3, DF5
    * - Asset(s)
      - ``Code execution``, ``Sensitive Data``, ``Denial of service``
    * - Threat Agent/Attacker
      - ``SClient``, ``NSClient``, ``HSComponent``
    * - Threat type
      - ``Tampering``, ``Information disclosure``, ``Elevation of privilege``, ``Denial of service``
    * - Impact
      - The service or the whole system may temporarily or permanently enter an unusable state.

        Malicious code might be executed in the context of the compromised service.
        Leakage of sensitive data.
    * - Scoring/CVSS
      - High, 8.4 `CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H <https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H>`_
    * - Mitigation
      - The service must validate boundaries and sanity check incoming data. Validation shall be
        checked during code reviews and by testing.
    * - Mitigation in place
      - yes

.. list-table::
    :widths: 15,80

    * - **ID**
      - 5
    * - Description
      - External devices connected to the system storing sensitive data. An attacker could eavesdrop external signals.
    * - Data flow
      - DF9, DF10, DF11
    * - Asset(s)
      - ``Sensitive Data``
    * - Threat agent/Attacker
      - ``PhysAcc``
    * - Threat type
      - ``Information disclosure``
    * - Impact
      - An attacker may get access to sensitive data, could tamper with sensitive data, or could attack the service
        using the external device by injecting malicious data, which could lead to malfunction or execution of malicious
        code.
    * - Scoring/CVSS
      - Medium, 5.9 `CVSS:3.1/AV:P/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:H <https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:P/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:H>`_
    * - Mitigation
      - When designing the use case, storage services must be assessed to understand which protection type they can
        implement (integrity, authenticity, confidentiality, rollback-protection). Sensitive data must be categorized
        and mapped to the storage service which can provide the needed protection.

        For example integrity can be safeguarded by using checksums. Authenticity by using digital signatures.
        Confidentiality by using encryption. Rollback protection by using nonce values.
    * - Mitigation in place
      - yes

.. list-table::
    :widths: 15,80

    * - **ID**
      - 6
    * - Description
      - State of external devices connected to the system might be modified by an attacker.

        This includes modifying signals, replacing the device, or modifying device content.
    * - Data flow
      - DF9, DF10, DF11
    * - Asset(s)
      - ``Sensitive Data``, ``Denial of service``, ``Code execution``
    * - Threat agent/Attacker
      - ``PhysAcc``
    * - Threat type
      - ``Tampering``, ``Denial of service``, ``Code execution``
    * - Impact
      - An attacker could tamper with sensitive data, or could attack the system by injecting malicious data, which
        could lead to malfunction, execution of malicious code, or using old state with known vulnerability.
    * - Scoring/CVSS
      - High, 7.3 `CVSS:3.1/AV:P/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H <https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:P/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H>`_
    * - Mitigation
      - When designing the use case, storage services must be assessed to understand which protection type they can
        implement (integrity, authenticity, confidentiality, rollback-protection). Sensitive data must be categorized
        and mapped to the storage service which can provide the needed protection.

        For example integrity can be safeguarded by using checksums. Authenticity by using digital signatures.
        Confidentiality by using encryption. Rollback protection by using hardware backed nonce values.
    * - Mitigation in place
      - yes


.. list-table::
    :widths: 15,80

    * - ID
      - 7
    * - Description
      - Invalid or conflicting access to shared hardware.

    * - Data flow
      - DF6, DF7, DF9, DF10
    * - Asset(s)
      - ``Sensitive Data``, ``Denial of service``, ``Code execution``
    * - Threat Agent/Attacker
      - ``SClient``, ``NSClient``, ``HPComponent``
    * - Threat type
      - ``Tampering``, ``Information disclosure``, ``Denial of service``, ``Code execution``
    * - Impact
      - A trusted service relying on shared hardware usage might get compromised or misbehaving if other stakeholders
        affect shared hardware in unexpected way.

    * - Scoring/CVSS
      - High, 7.0 `CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:H <https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:H>`_
    * - Mitigation
      - Access to peripherals must be limited to the smallest possible set of services. Ideally each peripheral should be
        dedicated to a single trusted service and sharing of peripherals should be avoided is possible. If sharing can
        not be avoided, a strict handover process shall be implemented to allow proper context switches, where hardware
        state can be controlled.
    * - Mitigation in place
      - yes

.. list-table::
    :widths: 15,80

    * - **ID**
      - 8
    * - Description
      - Unauthenticated access to hardware.

        A trusted service relying on hardware usage might get compromised or misbehaving if hardware state is
        maliciously altered.
    * - Data flow
      - DF6, DF7, DF9, DF10
    * - Asset(s)
      - ``Sensitive Data``, ``Denial of service``, ``Code execution``
    * - Threat Agent/Attacker
      - ``SClient``, ``NSClient``, ``HPComponent``
    * - Threat type
      - ``Tampering``, ``Information disclosure``, ``Denial of service``, ``Code execution``
    * - Impact
      - An attacker may get access to sensitive data of might make a trusted service or the system enter an unusable
        state by tampering with hardware peripherals.
    * - Scoring/CVSS
      - Medium, 6.4 `CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H <https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H>`_
    * - Mitigation
      - Access to peripherals must be limited to the smallest possible set of services. Ideally each peripheral should be
        dedicated to a single trusted service, and sharing of peripherals should be avoided is possible. If sharing can
        not be avoided, a strict handover process shall be implemented to allow proper context switches, where register
        values can be controlled.
    * - Mitigation in place
      - yes


.. list-table::
    :widths: 15,80

    * - **ID**
      - 9
    * - Description
      - Unauthenticated access to sensitive data.
    * - Data flow
      - DF1, DF2, DF3, DF5
    * - Asset(s)
      - ``Sensitive Data``, ``Denial of service``
    * - Threat Agent/Attacker
      - ``SClient``, ``NSClient``, ``HPComponent``
    * - Threat type
      - ``Tampering``, ``Information disclosure``, ``Denial of service``
    * - Impact
      - A trusted service may manage data of multiple clients. Different clients shall not be able to access each
        other's data unless in response to explicit request.
    * - Scoring/CVSS
      - Medium, 6.8 `CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N <https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N>`_
    * - Mitigation
      - Trusted services must implement access control based on identification data provided by higher privileged
        components (i.e. FF-A endpoint ID).
    * - Mitigation in place
      - yes


--------------

.. _Attachments:
.. Rubric:: Attachments

Source file of the `Data flow diagram`_. Please use the yEd_ for editing. :download:`./generic-data-flow.graphml`

--------------

.. _`Common Vulnerability Scoring System`: https://www.first.org/cvss/v3.1/specification-document
.. _`Vulnerability Calculator`: https://www.first.org/cvss/calculator/3.1
.. _`Severity Rating Scale`: https://www.first.org/cvss/v3.1/specification-document#Qualitative-Severity-Rating-Scale
.. _`STRIDE threat analysis technique`: https://docs.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats#stride-model
.. _yEd: https://www.yworks.com/products/yed

*Copyright (c) 2022, Arm Limited and Contributors. All rights reserved.*

SPDX-License-Identifier: BSD-3-Clause