AP - RSS Attestation Service

Introduction

This document gives an overview of handling of all the secure service requests that originates from TF-A running on AP and lands in TF-M SPM running on RSS. Arm CCA platforms has certain security requirements. One of the requirement is to provide with a platform attestation token whenever any user code executing in Realm demands for it. This attestation token is used by the Realm user to verify the trustworthiness and credibility of the platform. In simpler terms this attestation token is like a compiled signed document that has all the details about the hardware lifecycle state, SHA hash of all the trusted binaries which are loaded on the hardware and other claims about the legitimacy of the platform. To learn more about this please refer to Arm CCA.

On RME enabled RD platforms TF-RMM, TF-A and TF-M are involved in creation and transportation of the attestation token to Realm user. This document only focuses on providing a surface level understanding of the complicated boot time communication between TF-RMM, TF-A and TF-M for exchange of attestation token related data. The actual process of key and token generation in TF-M and transportation of the same from RMM to real user is out of the scope of this document.

Overview

There are two communication interfaces used to obtain realm private key and attestation token:

Interface between TF-A running on AP and TF-M SPM running on RSS.

Interface between TF-A and TF-RMM both running on AP.

TF-M has a boot time and runtime phase. TF-M runtime phase has all the secured services running as a separate thread in a multithread model. All the request always begins from AP side and RSS responds to those request by handling it through relevant secure services. TF-A also has boot time and runtime stages. In current situation all TF-RMM requests are catered by EL3 runtime TF-A stage which in certain conditions forwards the request to RSS for it to handle.

The overall attestation token is a composition of sub-tokens, where each sub-token is generated by different entitiy in the system. And each of the sub-tokens are cryptographically bound to each other. On RME enabled RD platforms from TF-M, to TF-A to all the way till TF-RMM, there are two sub-tokens. One of the token is called Initial Attestation Token (IAT) which is provided by RSS that includes measurements of all the updatable images running on AP, RSS, MSCP and LCP, hardware lifecyle state and other claims. The other sub-token is generated by TF-RMM which falls out of the scope of this document. Together they are called realm attestation token. Here measurements are nothing but SHA hash calculation of trusted loaded binary images which is encapsulated along with other metadata info to form a measurment. To learn more about attestation token and measurments, please refer to Arm CCA Security Model.

Each sub-token is needed to be signed by a private key. The IAT is the first token which is signed by a key provisioned in RSS Key Management Unit (KMU). TF-RMM requests for a different private key called as realm private key which is derived by RSS and provided back to TF-RMM. To learn more about the cryptographic binding of two sub-tokens and the maintained hierarchy, please refer to Delegated Attestation Service Integration Guide.

TF-M and TF-A Interface

AP and RSS communicates over a secure gateway which is implemented in hardware called as Message handling Unit (MHU). On RME enabled RD platforms we have four MHU units connecting AP and RSS. Each unit’s accessibility is restrictive to the security state in which the processing element (PE) is executing. These security states align to the four states mentioned in ARMv9 RME which are Non-secure, Secure, Realm and Root. Since TF-A BL31 is the root monitor in RME enabled RD platforms, while AP is executing TF-A code, it is always at Root EL3 mode. Similarly for the secure transmission and reception of data to and from RSS, Root MHU is used. This pathway is used to implement TF-M and TF-A software interface.

There are three specific services related to attestation that TF-M provides:

Record and extend measurements

Derive and provide a delegated attestation key

Provide the delegated attestation token

TF-A loads in stages. Staring with TF-A BL1 stage which is loaded by TF-M MCUboot. TF-M calculates and stores the measurement of TF-A BL1 image once it is loaded into AP SRAM. When AP boots it starts with TF-A BL1 which authenticates and loads TF-A BL2 image into AP SRAM and similarly when BL2 starts it authenticates and loads TF-A BL31 into AP SRAM. At each stage whenever there is a authenticated loading of any image, measurment of that image is also recorded. And this recorded measurement is provided to RSS through TF-M & TF-A MHU interface. This is called extending of measurment to RSS. This is a necessary step for TF-M to store all the measurements which is later used to derive delegated attestion key and compute delegated attestation token. The recording of the measurements are not just limited to TF-A BL images but also include FW configs which are Device tree blobs (DTB).

When BL31 comes up, there are no more images to load but it serves as a intermediary between TF-RMM requests and TF-M services. The request for delegated attestation key and token originally comes from TF-RMM. More about this process is explained in next section.

All the service request that arrives at TF-M from TF-A are initially picked up by a particular sevice named as ns_agent_mailbox. Repsonsibility of this service is to fetch message from MHU and pass it to relevant partitions like measured_boot & delegated_attestation. And once respective partitions have produced a response, it is gathered again by ns_aganet_mailbox and sent over MHU to TF-A. More detail on this can be read from SPE - NSPE communication.

TF-A and TF-RMM Interface

TF-A BL31 is the runtime stage which interfaces to TF-RMM. There are two parts in this interface: the boot interface and the runtime interface. To learn more about this interface refer to RMM-EL3 Communication Interface document. There are many runtime services which are requested by RMM over this interface to TF-A BL31. Two important services among these that needs special attention are RMM_ATTEST_GET_REALM_KEY and RMM_ATTEST_GET_PLAT_TOKEN.

As the name suggests, with RMM_ATTEST_GET_REALM_KEY TF-RMM request for a realm private key from TF-A BL31 and then TF-A BL31 request for delegated attestation key from TF-M SPM runtime. In response TF-M SPM runtime invokes delegated_attestation service which dervies the key and returns back the key to TF-A BL31 which is finally returned back to TF-RMM as a realm private key. During the derivation of private key, it uses CRYPTO service and measured_boot service to fetch all stored recorded measurments in RSS as these measurments are fed as input to the key derivation process.

As a next step TF-RMM requests for the IAT sub-token from TF-A BL31 using the service RMM_ATTEST_GET_PLAT_TOKEN. TF-A BL31 again forwards this as a deleagated attestation token request to TF-M SPM. And TF-M SPM invokes same service i.e. delegated_attestation. Internally it fetches the IAT from the initial_attestation service. This particular service has the duty to compile all the recorded measurments, hardware lifecycle state and other claims into a token and sign it. Once the IAT is produced, it is provided back to TF-A BL31 as a repsonse to request which is retuned back to TF-RMM.

Overall Flow

A simplified flow diagram is shown below.

The complete sequence of measured boot and generation of platform attestation token is divided into these steps:

At the beginning TF-M BL2 (MCUBoot) loads the TF-A BL1 into AP SRAM and stores its measurments internally. At this moment there is no involvement from AP as it hasn’t booted yet, so there is no requirment to use TF-M(RSS) and TF-A(AP) interface.

SCP bring AP out of reset to start executing the TF-A BL1. TF-A BL1 goes ahead and initializes other componenets and in the end authenticates and loads TF-A BL2 into AP SRAM and right after that it records the measurment of TF-A BL2 and extends it to RSS over TF-M & TF-A interface.

TF-A BL1 hands off the control to TF-A BL2. Which carries out many other operations before authenticating and loading BL31. And just like before it extends the recorded measurment of TF-A BL31 using same TF-M & TF-A interface.

Once TF-A BL2 is done with its functions, the control is passed to TF-A BL31 which sets up the RMM-EL3 interface to service requests arriving from TF-RMM and then invokes TF-RMM to perform its initialization.

During early init of TF-RMM, it requests for realm private key on TF-A & TF-RMM interface. Which is translated as a request for delegated attestation key by TF-A BL31 before being forwarded to TF-M on TF-M & TF-A interface. TF-M responds back with the key which is forwarded to TF-RMM by TF-A BL31.

On similar terms TF-RMM requests for final platform attestation token which is translated as a request for delegated attestation token by TF-A BL31 and forwarded to TF-M. TF-M uses internal secure services to produce a attestation token which is fetched by TF-A BL31 returned back to TF-RMM.

This completes the process of obtaining of the platform attestation token at boot time. Later during realm runtime, whenever a request for token arrives at TF-RMM from Realm user, it adds additional sub-token on top of platform attestation token to create a combined attestation token.