1Threat Model for RSS - AP interface
2***********************************
3
4************
5Introduction
6************
7This document is an extension for the general TF-A threat-model. It considers
8those platforms where a Runtime Security Subsystem (RSS) is included in the SoC
9next to the Application Processor (AP).
10
11********************
12Target of Evaluation
13********************
14The scope of this threat model only includes the interface between the RSS and
15AP. Otherwise, the TF-A :ref:`Generic Threat Model` document is applicable for
16the AP core. The threat model for the RSS firmware will be provided by the RSS
17firmware project in the future.
18
19
20Data Flow Diagram
21=================
22This diagram is different only from the general TF-A data flow diagram in that
23it includes the RSS and highlights the interface between the AP and the RSS
24cores. The interface description only focuses on the AP-RSS interface the rest
25is the same as in the general TF-A threat-model document.
26
27.. uml:: ../resources/diagrams/plantuml/tfa_rss_dfd.puml
28  :caption: Figure 1: TF-A Data Flow Diagram including RSS
29
30.. table:: Table 1: TF-A - RSS data flow diagram
31
32  +-----------------+--------------------------------------------------------+
33  | Diagram Element | Description                                            |
34  +=================+========================================================+
35  |       DF7       | | Boot images interact with RSS over a communication   |
36  |                 |   channel to record boot measurements and get image    |
37  |                 |   verification keys. At runtime, BL31 obtains the      |
38  |                 |   realm world attestation signing key from RSS.        |
39  +-----------------+--------------------------------------------------------+
40
41Threat Assessment
42=================
43For this section, please reference the Threat Assessment under the general TF-A
44threat-model document, :ref:`Generic Threat Model`. All the threats listed there
45are applicable for the AP core, here only the differences are highlighted.
46
47    - ID 11: The access to the communication interface between AP and RSS is
48      allowed only for firmware running at EL3. Accidentally exposing this
49      interface to NSCode can allow malicious code to interact with RSS and
50      gain access to sensitive data.
51    - ID 13: Relevant in the context of the realm attestation key, which can be
52      retrieved by BL31 through DF7. The RSS communication protocol layer
53      mitigates against this by clearing its internal buffer when reply is
54      received. The caller of the API must do the same if data is not needed
55      anymore.
56
57--------------
58
59*Copyright (c) 2022, Arm Limited. All rights reserved.*