Understanding PSA requires you to know these architectural specification documents

The Device Security Model (DSM) defines the overall security architecture for designing and deploying PSA-compliant trusted devices within an ecosystem. It is the top-level document for other PSA specifications, providing a common language, high-level robustness rules and models for them.

The DSM is based on the threat model and the use case recommendations made by the security analysis. Although the DSM is use case agnostic, it initially focuses on a few selected IoT use cases.

The DSM consists of three main areas:

1. Root of Trust and Related Security Services

2. Root Secrets and Their Storage, Protection, and Initialization

3. Device lifecycle and its impact on root of trust

The security and trust model is only effective if the root secrets and device firmware are initialized in the context of a secure production process. The production process extends to device management to distribute device attributes and firmware updates to service providers and device owners, etc.

This is an informative document that identifies and discusses the general need for infrastructure and common frameworks to facilitate these processes in device security architectures and their reliance on roots of trust. Configuring the actual factory provisioning and device management architecture should be the responsibility of industry stakeholders, or using something like Arm Mbed Cloud.

The Arm Trusted Base System Architecture for Armv8-M (TBSA-M) is a set of SoC hardware requirements. It applies to Armv8-M-based designs and helps develop more secure devices. The TBSA-M document can also serve as a reference for silicon chip manufacturers who plan to implement secure designs using the Armv7-M architecture.

TBSA-M includes best practice security principles for system design around the Armv8-M Processing Element (PE). These principles support the design and integration of the following hardware-rooted features:

• Root of Trust

• Protected keystore

• Isolation of trusted and untrusted software components

• Secure firmware update mechanism

• Lifecycle management and secure debugging

• A high entropy random number generator; essential for strong cryptography

• Cryptographic accelerators, which are used to maintain real-time functionality for appropriate security functions

The firmware framework (PSA-FF) implementation should ideally be done on top of a TBSA-M compliant design to enable a secure processing environment where safety-critical functionality and data are isolated from application firmware data. This increases the trustworthiness of the device even in the presence of software vulnerabilities that could be exploited.

Trusted Boot and Firmware Update specifies the system and firmware technical requirements that must be met to ensure the integrity of the MCU boot. The specification includes the following:

• Verified boot process to establish secure runtime services

• Secure firmware update agent

• Authentication and authorization instructions for firmware updates, including cryptographic certificates and device keys

• Recommendations and best practices to help achieve robustness

The scope of the specification is similar to the Trusted Motherboard Boot Requirements (TBBR) for A-Series client devices.

The Firmware Framework (FF) specifies standard interfaces and frameworks for isolating trusted functions in constrained IoT devices based on the requirements of the device security model. The framework provides:

• Describes an architecture for isolated execution environments (partitions) for trusted and untrusted firmware

• A standard model for describing the functions and resources of each partition

• A secure IPC interface for requesting services from other partitions

• A model that describes how partitions interact with each other, as well as the hardware and firmware framework implementation itself

The specification enables the development of secure firmware functionality that is reusable across different devices that conform to the firmware framework implementation.

PSA Firmware Framework Overview

The Platform Security Architecture Firmware Framework (PSA-FF) defines three permissive firmware runtime isolation levels. This allows for reduced isolation in highly constrained devices while increasing security and robustness on platforms with sufficient resources and providing a consistent firmware interface for security features.

PSA-FF divides execution within the system into two partitions - the non-secure processing environment (NSPE) and the secure processing environment (SPE). The NSPE contains application firmware, the operating system kernel and libraries, and typically controls most of the input/output peripherals. The SPE contains secure firmware and hardware resources, isolated from the NSPE firmware and non-secure hardware resources.

PSA-FF further divides the SPE into a secure partition manager (SPM) and secure partitions. The secure partition provides an execution environment for security functions. The SPM applies isolation logic to separate different partitions, which is executed by the platform hardware using master-side and/or slave-side filters. For example, the Security Attribute Unit (SAU) and Memory Protection Unit (MPU) can be used in the new Armv8-M platform. Other platforms may use other mechanisms to provide similar partition isolation.

The firmware framework defines a secure session-based IPC mechanism that allows firmware in isolated partitions to interact. Specifically, the IPC framework allows firmware in one partition to request services from firmware in another partition through a standard interface. The API requires that messages be replicated by the framework between partitions, thereby eliminating the vulnerability risks caused by direct shared memory.

PSA-FF displays the safety function as a series of safety functions. Each safety function is a series of related safety operations implemented in a safety partition. Each safety partition can support multiple safety functions.

Different chip partners can provide their own plug-in implementations for standard safety functions (SF). The firmware framework abstracts the SF implementation through predefined APIs and calling semantics. Chips and other partners can also define their own safety function implementations to provide platform-specific services or higher-level security services.

For more details about the firmware framework, see the PSA Firmware Framework-M [PSA-FF] specification.

Some security functions provide root-of-trust services (such as authentication) or enable root-of-trust (such as cryptographic operations); these security functions are called "trusted functions". The standard interface of trusted functions will be defined by PSA, for example:

• safety certificate

• Secure storage/data encapsulation

• Cryptographic Operations

• RNG and Safe Time Services

• Secure firmware updates