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