Runtime Security Subsystem

Introduction

The Runtime Security Subsystem processor (RSS) is tasked with being the secure root of trust for platforms it is included. The main tasks are securely loading firmware and provides secure services such as storing encryption keys safely and secure encryption/decryption without exposing the stored keys as part of CCA Hardware Enforced Security (CCA HES) (see CCA Security Model). In addition RSS provides attestation services and can store and return measurement data.

RSS firmware is a platform of the open source project Trusted Firmware-M (TF-M).

For further documentation see:: <workspace>/tf-m/docs/
and: <workspace>/tf-m/docs/platform/arm/rss/

Hardware Specification

RSS integrates Cortex-M55 processor core, two volatile memory banks, Memory Protection Controller (MPC), Non-Volatile ROM. In addition, RSS uses the following peripherals:

Address Translation Unit (ATU) - Maps part of RSS address space to address space of other subsystems.
Crypto Accelerator - A private accelerator to perform encryption and decryption operation without involvement of the processor.
Key Management Unit (KMU) - Stores keys securely in a way they can only be accessed by Crypto Accelerator ensuring keys are secure even from RSS.
One Time Programable memory (OTP) - Memory that allows data to only be written once.

Bootloader

The RSS Bootloader is split into 3 parts: BL1_1, BL1_2 and BL2 to provide a balance between security and ease of update.

BL1_1 is run from the ROM and has the main job of initializing the OTP, loading and running the provisioning bundles, and loading BL1_2 from the OTP into SRAM. It is kept relatively simple as it cannot be changed once the ROM is manufactured. For more details on provisioning see: RSS Provisioning.

BL1_2 is loaded from OTP to run from SRAM and has the main job of initializing the flash and loading BL2 from the flash into SRAM. This is easier to change as it is in OTP which can be changed at manufacturing without changing hardware like the ROM.

BL2 is loaded from flash to run from SRAM and has the main job of loading and verifying the firmware for all subsystems. BL2 will load the firmware for SCP, MCP, all LCPs, AP BL-1 and the RSS runtime firmware. The ATU is required to access the address space of the other processors. To access LCP, the SCP needs to have setup the CMN so this stage also initializes communication to coordinate with the other processors (see SCP - RSS Communication). This is also the point where the SCP ATU is setup (see SCP Address Translation Unit (ATU) Configuration).

BL2 is a configuration of MCUBoot which uses headers and trailers to validate the images. For more details see Image Loading Using MCUBoot.

Lifecycle

The chip lifecycle is split into 4 states.

Chip Manufacture (CM)
Device Manufacture (DM)
Secure Enabled (SE)
Return to Manufacture (RTM)

During CM and DM stages, secure data is loaded into the OTP and KMU from the provisioning bundles for use in the SE stage. SE is the main stage the chip is used in and the only stage that boots past BL1_1. RTM is only used for decommissioning the chip.

Secure Encryption

In RSS systems with a crypto accelerator and KMU secure keys for encryption are only stored in the KMU. This provides an extra level of security as once keys are stored and locked in the KMU they cannot be accessed by software. The only way to use keys in the KMU is through a secure channel between the KMU and crypto accelerator. This means even if the RSS runs compromised code the crypto keys will still be secure as they are never in memory or accessible to the processor during SE state.

Note: In the current implementation the KMU is not locked for debugging.

If a crypto accelerator software cryptography must be used which will require either the KMU is not locked or it is not used. If software cryptography is used the keys will also need to be in memory. This is considered less secure.