Detailed analysis of files associated with the PSA architecture specification

The PSA Architecture Specification consists of a series of interrelated files, listed below:

➤Device Security Model – the underlying trust model and model

信任 Trusted Device Initialization – Initial Security Device Programming and Configuration Requirements

可信 Trusted Infrastructure System Architecture [TBSA-M] – hardware platform requirements for v8-M

ä¿¡ä»» Trusted boot and firmware update

➤ PSA Firmware Framework M [PSA FF] – Firmware Interface Definition for Restricted IoT Platform Secure Processing Environment (SPE)

➤ PSA trusted function – definition of standard trusted device in SPE

Equipment security model

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 file for other PSA specifications, specifying common language, high-order robustness rules, and models.

The foundation of DSM is the recommendations of the threat model and security analysis for use cases. Although DSM has nothing to do with use cases, it initially focused on several selected IoT use cases.

DSM includes three main aspects:

1. Root of trust and related security services

2. Root secrets and their storage, protection and initialization

3. Equipment life cycle and its impact on the root of trust

Trusted device initialization

The security and trust model is only valid when the root secret and device firmware are initialized in the context of a secure production process. The production process extends to device management to assign device attributes and firmware updates to service providers and device owners.

This is an informative document that identifies and discusses the general requirements for infrastructure and common frameworks to facilitate these processes in the device security architecture and their dependence on the root of trust. Configuring the actual plant supply and equipment management architecture should be the responsibility of industry stakeholders or using equipment like Arm Mbed Cloud.

Trusted Infrastructure Architecture (TBSA)

Armv8-M's Arm Trusted Base System Architecture (TBSA-M) is a set of SoC hardware requirements. It is suitable for Armv8-M based designs and helps to develop safer devices. The TBSA-M file can also be used as a reference for silicon chip manufacturers planning to implement a secure design using the Armv7-M architecture.

The TBSA-M includes best practice safety principles applicable to system design around the Armv8-M Processing Unit (PE). These principles support the design and integration of the following hardware-based features:

Root of trust

Protected keystore

Isolation of trusted and untrusted software components

Secure firmware update mechanism

Lifecycle management mechanism and safe debugging

High entropy random number generator; it is essential for reliable passwords

Password Compilation Accelerator, which maintains real-time functionality for proper security functions

The firmware framework (PSA-FF) implementation is best implemented on top of the TBSA-M compatible design to enable secure processing environments where security critical functionality and data are isolated from application firmware data. This can increase the credibility of the device, even if there are software vulnerabilities that may be exploited.

Trusted boot and firmware update

Trusted boot and firmware updates specify the system and firmware technical requirements that must be met to ensure the integrity of the MCU boot. The specification includes the following:

Proven startup process to establish secure runtime services

Secure firmware update agent

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

Suggestions and best practice notes that help achieve robustness

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

Firmware Framework (PSA-FF)

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

Describe the architecture of the isolated operating environment (partition) for trusted and untrusted firmware

A standard model that describes the capabilities and resources of each partition

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.

This specification enables the development of secure firmware functionality that can be reused for different devices that conform to the implementation of the firmware framework.

Overview of the PSA firmware framework

>>>>

Secure partitioning and isolation

The Platform Security Architecture Firmware Framework (PSA-FF) defines three licensed firmware operational isolation levels. This allows for reduced isolation in highly restricted devices. At the same time, it increases security and robustness on platforms with sufficient resources and provides a consistent firmware interface for security functions.

PSA-FF divides the execution within the system into two partitions - the Non-Secure Processing Environment (NSPE) and the Secure Processing Environment (SPE). NSPE contains application firmware, operating system kernels, and libraries that typically control most of the input/output peripherals. The SPE contains secure firmware and hardware resources that are isolated from NSPE firmware and non-secure hardware resources.

PSA-FF further divides the SPE into a Secure Partition Manager (SPM) and a secure partition. Secure partitioning provides an execution environment for security functions. SPM uses isolation logic to separate different partitions, which are executed by the platform hardware using the primary side and/or the secondary side filters. For example, the Security Attribute Unit (SAU) and Storage Protection Unit (MPU) can be used in the new Armv8-M platform. Other platforms can use other mechanisms to provide similar partition isolation.

>>>>

Secure IPC

The firmware framework defines a secure session-based IPC mechanism that allows firmware in partitions that are isolated from each other to interact. Specifically, the IPC framework allows firmware within a partition to request service from firmware in another partition through a standard interface. The API requires that messages be replicated by a framework between partitions, thereby eliminating the risk of vulnerability from direct shared memory.

>>>>

security function

The PSA-FF displays the security features as a series of security features. Each security function is a series of related security operations implemented in a secure partition. Each secure partition can support multiple security features.

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

See the PSA Firmware Framework-M [PSA-FF] specification for more details on the firmware framework.

Trusted function

Some security features provide a trusted root service (such as authentication) or an enable root (such as an encryption operation); these security features are called "trusted features." The standard interface for trusted functions will be defined by the PSA, for example:

safety certificate

Secure storage / data encapsulation

Encryption operation

RNG and safe time service

Secure firmware update