Arm Platform Security Architecture Overview...2.2 Arm’s vision for a more secure IoT 9 3...

Copyright © 2017-2018 Arm Limited (or its affiliates). All rights reserved. 1

October 2018 White Paper

Arm Platform Security Architecture OverviewRevision 1.2

2Copyright © 2017-2018 Arm Limited (or its affiliates). All rights reserved.

Platform Security Architecture Overview

Copyright © 2018 Arm Limited or its affiliates. All rights reserved.

Release Information

Table 1 lists the changes that are made to this document.

Date Issue Change

October 2017 A First development release

October 2018 B Full updates to release

Table 1 Change History


Non-Confidential Proprietary Notice

This document is protected by copyright and other related rights and the practice or

implementation of the information contained in this document may be protected by one or

more patents or pending patent applications. No part of this document may be reproduced

in any form by any means without the express prior written permission of Arm. No license, express or implied, by estoppel or otherwise to any intellectual property rights is granted by this document unless specifically stated.

Your access to the information in this document is conditional upon your acceptance that

you will not use or permit others to use the information for the purposes of determining

whether implementations infringe any third-party patents.

THIS DOCUMENT IS PROVIDED “AS IS”. ARM PROVIDES NO REPRESENTATIONS

AND NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, INCLUDING, WITHOUT

LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY, SATISFACTORY

QUALITY, NON-INFRINGEMENT OR FITNESS FOR A PARTICULAR PURPOSE WITH

RESPECT TO THE DOCUMENT. For the avoidance of doubt, Arm makes no representation

with respect to, and has undertaken no analysis to identify or understand the scope and

content of, patents, copyrights, trade secrets, or other rights.

This document may include technical inaccuracies or typographical errors.

TO THE EXTENT NOT PROHIBITED BY LAW, IN NO EVENT WILL ARM BE LIABLE

FOR ANY DAMAGES, INCLUDING WITHOUT LIMITATION ANY DIRECT, INDIRECT,

SPECIAL, INCIDENTAL, PUNITIVE, OR CONSEQUENTIAL DAMAGES, HOWEVER

CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF ANY

USE OF THIS DOCUMENT, EVEN IF ARM HAS BEEN ADVISED OF THE POSSIBILITY

OF SUCH DAMAGES.

This document consists solely of commercial items. You shall be responsible for ensuring

that any use, duplication or disclosure of this document complies fully with any relevant

export laws and regulations to assure that this document or any portion thereof is not

exported, directly or indirectly, in violation of such export laws. Use of the word “partner”

in reference to Arm’s customers is not intended to create or refer to any partnership

relationship with any other company. Arm may make changes to this document at

any time and without notice.

If any of the provisions contained in these terms conflict with any of the provisions

of any click through or signed written agreement covering this document with Arm, then

the click through or signed written agreement prevails over and supersedes the conflicting

provisions of these terms. This document may be translated into other languages for

convenience, and you agree that if there is any conflict between the English version of

this document and any translation, the terms of the English version of the Agreement

shall prevail.


The Arm corporate logo and words marked with ® or ™ are registered trademarks

or trademarks of Arm Limited (or its subsidiaries) in the US and/or elsewhere. All rights

reserved. Other brands and names mentioned in this document may be the trademarks

of their respective owners. Please follow Arm’s trademark usage guidelines at

http://www.arm.com/company/policies/trademarks.

Copyright © 2017-2018 Arm Limited (or its affiliates). All rights reserved.

Arm Limited. Company 02557590 registered in England.

110 Fulbourn Road, Cambridge, England CB1 9NJ.

LES-PRE-20349

https://www.arm.com/company/policies/trademarks


Table of Contents

Release information 2

Non-Confidential Proprietary Notice 3

1 About This Document 6

1.1 References 6

1.2 Terms and Abbreviations 6

2 Introduction 8

2.1 Industry Challenges 8

2.2 Arm’s vision for a more secure IoT 9

3 Introducing the Arm Platform Security Architecture 10

3.1 Solving an industry issue 10

3.2 What is Platform Security Architecture? 10

3.3 Objectives 10

3.4 Three key phases 11

3.5 Phase 1: Analyze with Threat Models and 12

Security Analyses

3.6 Phase 2: Architect with Architecture Specifications 14

3.6.1 PSA Security Model 15

3.6.2 Factory Initialization 15

3.6.3 Trusted Base System Architecture (TBSA) 15

3.6.4 Trusted Boot and Firmware Update 16

3.6.5 Firmware Framework (PSA-FF) 16

3.6.6 Developer APIs 18

3.7 Phase 3: Implement with Trusted Firmware-M 19

reference implementation

3.8 Mbed OS 20

3.9 Ecosystem Enabling 21

4 Functional APIs and Security Evaluation 22

5 Arm’s Supporting IP 23

6 Conclusion 24


1 About This DocumentThis is an introduction to Arm’s Platform Security Architecture (PSA) specifications.

This paper provides an overview of the evolution of the security technology, with some

high-level details. For further information, refer to the various specifications from Arm,

referenced in this document.

1.1 References

This document refers to the following documents:

Term Meaning

Application firmware The main application firmware for the platform, typically comprising application tasks and

an RTOS. PSA provides no isolation services for this firmware, although the RTOS might

make use of available hardware support, to provide internal isolation of operation.

Application Root of Trust This is the security domain in which additional security services are implemented.

See PSA Security Model [PSA-SM] for details.

Application Root of Trust Service This is a Root of Trust Service within the Application Root of Trust domain.

Common Criteria Common Criteria (CC) is the set of internationally and nationally recognised technical

standards and configurations that allow for security evaluations of products and

technology. The individual set of Common Criteria technical standards or configurations,

developed for a specific product or technology, is qualified as a protection profile.

IDAU Implementation defined attribution unit. See [Armv8-M].

Reference Document Number Title

[TF-A] N/A Trusted Firmware-A

[TBSA-M] Arm DEN 0083A Trusted Base System Architecture for

Armv6-M, Armv7-M and Armv8-M

[TBBR] Arm DEN 0006B Trusted Board Boot Requirements

[Armv8-M] Arm DDI 0553A Armv8-M Architecture Reference

Manual, Arm Ltd

[GPROT] GP_REQ_025 v1.0.1 Root of Trust Definitions and

Requirements, GlobalPlatform

[PSA-FF] ARM DEN 0063A Firmware Framework

[PSA-SM] ARM DEN 0079 PSA Security Model

[PSA-FI] Yet to be available Factory Initialization

[PSA-TBFU] ARM DEN 0072A Trusted Boot and Firmware Update

1.2 Terms and Abbreviations

This document uses the following terms and abbreviations:

https://git.trustedfirmware.org/trusted-firmware-a.git/


IPC Inter-process communication. PSA provides an IPC mechanism to provide

a communication channel for requests between isolated partitions.

MPU Memory protection unit.

Non-Secure Processing Environment (NSPE) This is the security domain outside of the SPE, the Application domain, typically

containing the application firmware and hardware.

Partition The unit of execution from the perspective of the SPM. The smallest isolated unit

in the PSA model.

Protection Profiles (PP) A formal document that describes a combination of threats, security objectives,

assumptions, security functional requirements, security assurance requirements

and rationales.

PSA Platform Security Architecture.

PSA-FF PSA Firmware Framework.

PSA Immutable Root of Trust The hardware and code and data that cannot be modified following manufacturing.


PSA Root of Trust This defines the most trusted security domain within a PSA system. See PSA Security

Model [PSA-SM] for details.

PSA Root of Trust Service This is a Root of Trust Service within the PSA Root of Trust domain.

PSA Updateable Root of Trust The Root of Trust firmware that can be updated following manufacturing.


RoT Root of Trust. See [GPROT]. This is the minimal set of software, hardware and data that

has to be implicitly trusted in the platform – there is no software or hardware at a deeper

level that can verify that the Root of Trust is authentic and unmodified.

Root of Trust Service (RoT Service) A set of related security operations that are implemented in a Secure Partition.

The server endpoint of a PSA IPC channel. Multiple RoT Services can co-exist in a single

Secure Partition.

SAU Security attribution unit. See [Armv8-M].

Secure Partition A thread of execution with protected runtime state within the Secure Processing

Environment. Container for the implementation of one or more RoT Services. Multiple

Secure Partitions may be present in a platform.

SPE Secure Processing Environment. A platform’s processing environment for software that

provides confidentiality and integrity for its runtime state, from software and hardware,

outside of the SPE. Contains the Secure Partition Manager, the Secure Partitions and

the trusted hardware.

SPM The part of a PSA implementation that is responsible for isolating software in

partitions, managing the execution of software within partitions, and providing IPC

between partitions.


2 IntroductionThe transition to an Internet of Things (IoT) is well underway and has the potential to

transform both commercial and consumer experience. The success of the IoT is heavily

dependent upon the trust and security built into billions of connected devices. Businesses

rely on the data from edge computing, in order to make gainful decisions, whilst consumers

need assurance that their connected homes and digital lives are not compromised.

Security is not optional

The mass deployment of IoT devices, over the next few years, will create a connected

world that the population relies upon. This extraordinary growth of microcontroller-based

products will result in:

Billions of IoT and embedded connected devices, built from a range of Arm-

based solutions.

A wide variety of use cases and security robustness requirements.

Integration of system components from multiple hardware, software,

and firmware vendors.

Diverse implementations of each component.

Integration work that may not be reusable from one project to another.

The gold rush that is pushing this market, is driving a time- and cost-sensitive environment,

which requires new designs to be created much faster than ever before. In many instances,

security is an after-thought, a fix-later problem to reduce time-to-market. However, poorly-

designed connected devices are vulnerable to exploitation and may act as a portal to bring

down key parts of the internet infrastructure, potentially risking our safety. Consequently,

there is a need for device security that addresses these vulnerabilities and can be applied

at all cost points.

This white paper offers an overview of the Platform Security Architecture (PSA) –

a framework that provides hardware- and firmware-based security that is designed

into devices, from the ground up.

2.1 Industry Challenges

The challenges facing the industry are as follows:

1. Security can be expensive to implement throughout a device lifecycle.

2. Secure devices are difficult to manage at scale.

3. The industry lacks confidence in the data being passed to and from sensors and

actuators, and is therefore unable to realize the full economic benefits of the IoT.

4. Security specialists are expensive and in short supply, particularly for smaller businesses

and startups.

5. The security landscape is ever evolving, with new vulnerabilities emerging all the time.


2.2 Arm’s vision for a more secure IoT

With these challenges in mind, we released the Arm Security Manifesto, which outlines our

vision for security.

1. To shift the economics of security:

- Security should be affordable throughout the device lifecycle.

2. Making security practical at scale:

- IoT cloud operators need the facility to manage vast numbers of devices, securely

and efficiently, regardless of the different device types or silicon inside them.

3. Security across the entire value chain:

- A key benefit of the IoT lies in the data generated and exchanged, and the analysis

and subsequent information extracted from this data. Companies must be able to

determine the reliability of the data, to make the shared financial benefits of the

ecosystem a reality.

4. Security from the ground up:

- A consistent standard of security should be designed into the hardware and firmware

of all devices.

5. An industry-wide responsibility:

- Security is an industry-wide responsibility. The technology industry, as a whole, needs

to step up, collaborate, and adopt a common security best practice in order to address

current and future security threats. PSA calls on the ecosystem to take action and

raise standards of security, across the board.


3 Introducing the Arm Platform Security Architecture

3.1 Solving an industry issue

Taking current trends and security issues into consideration, Arm felt a need to drive

alignment across the industry with a common standard. The goal is to create increased

security across the ecosystem, through a shared approach to best practice. In doing this,

we shift the economics of security, reducing risk, security cost and the complexity of

implementing robust security measures. To achieve this, Arm announced the Platform

Security Architecture (PSA).

3.2 What is Platform Security Architecture?

The Platform Security Architecture (PSA) is a framework for securing a trillion connected

devices. It includes a holistic set of deliverables, including Threat Models and Security

Analyses documentation, hardware and firmware architecture specifications, and API test

kits. Together, with an open source reference implementation, it enables you to consistently

design in the right level of security to all connected devices. PSA draws and builds upon

best practice from across the industry. It is aimed at different entities throughout the supply

chain, from chip designers and device developers to cloud and network infrastructure

providers and software vendors. Together with our partners, Arm is leading the ecosystem

in its goal to protect the connected world. The Platform Security Architecture (PSA) has

been designed to demystify security designs and concepts.

3.3 Objectives

The following objectives outline the PSA framework to make billions of devices more secure:

Simplify the process of evaluating IoT devices against security standards.

Reduce cost and complexity of software development for ecosystem partners by

facilitating re-use, improving interoperability, and minimizing API fragmentation.

Reduce cost of security and complexity for SoC designers, through the Security

Model realization, by leveraging from the primitives offered by the PSA.

To achieve the above objectives, the following requirements should be met:

Establish a basis for certification/evaluation of an Arm-based SoC or device.

Define core security functionality.

Define a sandbox security model.

Define a framework for security functions implemented by third party software vendors.

Define the fundamental IoT secure hardware platform.

Provide a robust, open source reference implementation for IoT devices (similar to

Trusted Firmware-A for clamshell and mobile).


3.4 Three key phases

Applying PSA consists of three key phases:

1. Analyze: Threat Models and Security Analyses, derived from a range of typical IoT

use cases.

2. Architect: Architecture specifications for firmware and hardware.

3. Implement: An open source reference implementation of the firmware

architecture specifications.

At the root of PSA, threat models drive security requirements at every phase, as illustrated

in Figure 1. These specific threat models are CPU architecture-agnostic, whereas the other

two components exist to support conformant implementations.

The relationship between the three phases of PSA is shown in Figure 1.

Figure 1 PSA components

Security Model

Trusted Base System Architecture

Trusted Boot & Firmware

Update

Firmware Framework

Factory Initialization

Cloud service clients

Threat Models and Security Analyses

OS

Developer APIs

Firmware

Hardware platform

Derived requirements

Implementation

Inform

Assess

Specify

Platform Security Architecture


3.5 Phase 1: Analyze with Threat Models and Security Analyses

When designing a secure system, we need to carry out a risk analysis and create a threat

model, taking into consideration the key factors. These include:

Assets in need of protection.

All potential threats.

The scope and severity of these threats.

The different types of attacker and the methods they might use to exploit vulnerabilities.

From this research, security objectives can be determined and the security functional

requirements established to mitigate the threats. Currently, Arm has developed three

example threat models, available to download via the PSA resources page. These were

created through a close analysis of three common IoT use cases. Generally applicable

security principles can be derived from these analyses, and are then used to guide the

development of the architecture specification documents.

The threat models have been created using an English Language Protection Profile-style

approach, to establish a set of Security Functional Requirements (SFR) for the Target of

Evaluation (TOE). Each profile considers the functional description, the TOE, and the

necessary security requirements. The documentation is intended to make threat modelling

more accessible and more useable by engineers, regardless of whether they have prior

security knowledge or expertise.

The hardware and software security building blocks, as described in the PSA architecture

specifications, provide the primitives needed to meet the security requirements, also

highlighted in the available threat modelling documentation.

https://pages.arm.com/psa-resources.html


System description

Assets

Threats

Security objectives

Security requirements

Smart Metering

Metering data to be protected in integrity and confidentiality

Remote software attacks

Strong crypto

Hardware-based keystore

Figure 2Example of a security analysis for a smart meter

Threat models and Security Analysis

An example of a high-level analysis is illustrated in Figure 2.


3.6 Phase 2: Architect with Architecture Specifications

Following analysis of a device, security recommendations are generated based on

the value of the device assets and the list of potential attacks that threaten those assets.

Phase two focuses on creating a system architecture that is capable of delivering the

security requirements, and describes this architecture in the PSA specifications.

The PSA specifications consist of a suite of connected documents, as follows:

1. PSA Security Model – Foundational trust models and patterns.

2. Factory Initialization – Requirements for initial secure device programming

and configuration.

3. Trusted Base System Architecture [TBSA-M] – Hardware platform requirements.

4. Trusted Boot and Firmware Update [TBFU].

5. Firmware Framework [PSA-FF] – Firmware interface definition of a Secure Processing

Environment (SPE) for constrained IoT platforms, including PSA Root of Trust APIs.

6. Developer APIs – Interfaces to security services for application developers.

In this next section of the whitepaper, we will discuss the purpose of each document.

Security Model

Trusted Base System Architecture

Trusted Boot & Firmware

Update

Firmware Framework

Factory Initialization

Developer APIs

Derived requirements

Platform Security Architecture


3.6.1 PSA Security Model

The Security Model (SM) defines the overall security architecture for designing and

deploying trusted PSA-compliant devices within ecosystems. It is the top-level document

for the other PSA specifications and defines common language, high-level robustness rules,

and models for them.

The SM is based on the use case-driven recommendations of the Threat Models and

Security Analyses. Although the SM is intended to be use case-agnostic, initially the focus

is on a few selected IoT use cases.

The SM covers three main areas:

1. Root of Trust (RoT) and associated security services.

2. Root secrets – their storage, protection, and provisioning.

3. Device lifecycle and its implications on Roots of Trust.

3.6.2 Factory Initialization

The security and Root of Trust (RoT) models are only effective if root secrets and

device firmware are provisioned in the context of secure manufacturing processes.

The manufacturing process extends into device management for robust distribution

of device attributes and properties, firmware updates, and so on to service providers

and device owners.

This is an informative document that identifies and discusses the general need for

infrastructure and common frameworks to facilitate these processes, as well as their

dependencies on the RoT, established in the device security architecture. Deploying actual

factory provisioning and device management infrastructure is expected to be done by

industry stakeholders or using services, such as Arm Mbed Cloud.

3.6.3 Trusted Base System Architecture (TBSA)

Trusted Base System Architecture for Armv6-M, Armv7-M and Armv8-M (TBSA-M) is

a set of SoC hardware requirements. It applies to SoC designs for PSA that use Armv6-M,

Armv7-M and Armv8-M CPUs.

TBSA-M encapsulates best practice security principles when designing systems around Arm

Cortex-M processing elements (PEs). These principles support the design and integration of

the following features, rooted in hardware:

A Root of Trust.

A protected keystore.

Isolation between trusted and untrusted software components.

A secure firmware update mechanism.


A lifecycle management mechanism and secure debug.

A high entropy random number generator; this is essential for reliable cryptography.

Cryptographic acceleration – in order for real-time functionality to be maintained

alongside the correct security features.

A Firmware Framework (PSA-FF) implementation ideally runs on top of designs

implementing the TBSA-M specification, to enable a secure processing environment

that isolates security-critical functionality and data from application firmware. This can

increase confidence in the trustworthiness of a device, even in the presence of exploitable

software vulnerabilities.

3.6.4 Trusted Boot and Firmware Update

The trusted boot and firmware update requirements provide the system and

firmware technical requirements for ensuring MCU boot integrity. The specification

covers the following:

Authenticated boot process to establish the secure runtime services.

A secure firmware update agent.

Description of authentication and authorizing of firmware updates with cryptographic

certificates and device keys.

Recommendations and best practice are described, to help make

implementations robust.

3.6.5 Firmware Framework (PSA-FF)

Based on the requirements in the PSA Security Model, the Firmware Framework (PSA-

FF) defines a standard interface and framework, to isolate trusted functionality within

constrained IoT devices. The framework provides:

Architecture that describes isolated runtime environments (partitions) for trusted and

untrusted firmware.

A standard model for describing the functionality and resources in each partition.

A secure IPC interface to request services from other partitions.

A model that describes how the partitions can interact with one another, as well as the

hardware and the firmware framework implementation, itself.

This specification enables the development of secure firmware functionality that

can be reused on different devices that use any conforming implementation of the

Firmware Framework.


For further details on the firmware framework, refer to the PSA Firmware Framework

[PSA-FF] specification.

3.6.5.1 Isolation

The Platform Security Architecture Firmware Framework (PSA-FF) defines three permitted

levels of firmware runtime isolation. This permits reduced isolation in highly constrained

devices. Simultaneously, it increases security and robustness on platforms with sufficient

resources – while still providing the same firmware interfaces for developing security services.

PSA-FF divides execution, within the system, into two zones – the Non-Secure Processing

Environment (NSPE) and the Secure Processing Environment (SPE). The NSPE contains

the application firmware, OS kernel, and OS libraries, which typically control most I/O

peripherals. The SPE contains the security firmware and hardware resources, which are

isolated from NSPE firmware and non-secure hardware resources.

PSA-FF further divides the SPE into the Secure Partition Manager (SPM) and Secure Partitions.

Secure Partitions are the execution environment for security services.

The SPM implements the isolation logic to separate the partitions, which is enforced

by platform hardware, such as an MPU, Arm TrustZone or physically isolated processors.

The higher isolation levels introduce separation between the different components within

the SPE.

Figure 3Elements of the PSA Firmware Framework

The overview of this is illustrated in Figure 3.

OS kernal

OS libraries

Application FirmwareApplication RoT

Service PSA RoT ServiceApplication RoT

ServiceApplication RoT

Service PSA RoT Service

Secure IPC Secure interruptsSecure isolation

Application Application Root of Trust

Secure Processing Environment (SPE)

Isolation boundary

Non-Secure Processing Environment (NSPE)

Secure Partition Manager

Secure Partition Secure Partition Secure Partition

PSA Root of Trust


3.6.5.2 Secure IPC

The Firmware Framework defines a secure session-based IPC mechanism that allows firmware,

in two isolated partitions, to interact. Specifically, the IPC framework enables firmware in one

partition to request services from firmware in another partition, through a standard interface.

The API requires that the messages are copied by the framework between the partitions,

removing the vulnerability risks that come from directly sharing memory.

3.6.5.3 Root of Trust Services (RoT Services)

Security functionality is exposed by the PSA-FF as a collection of RoT Services. Each RoT

Service is a set of related security operations that are implemented in a Secure Partition.

Multiple RoT Services can be supported in each Secure Partition.

Different silicon partners can provide their own plug-in implementations of standard

RoT Services. The firmware framework abstracts away RoT Service implementation

through a pre-defined API and calling semantics. Silicon and other partners can also define

implementations of their own RoT Services, to provide platform specific services or higher

level security services.

3.6.5.4 PSA Root of Trust APIs

PSA-FF also defines a standard API for all trusted services that can directly use the

PSA-SM Root secrets, such as cryptographic operations and device identity attestation.

Together with the SPM, these services form the PSA Root of Trust within the larger SPE.

At isolation level 2 or 3, the PSA Root of Trust is isolated from all other Secure Partitions.

3.6.6 Developer APIs

PSA also defines some security service APIs for application developers. Although these

are not all required APIs for PSA, using a common interface accelerates adoption and

deployment of PSA-based systems. For example:

Cryptographic Operations

These services offer the ability to work with cryptographic keys without ever seeing them.

Application developers refer to keys by handles and can request operations, like signature

or encryption, to be performed with a given key, without ever exporting it out of the secure

environment. On devices that sport a hardware secure element, calls are passed through

an appropriate driver and performed directly on the secure element.

Application developers will be able to rely on Random Number Generators of cryptographic

quality, based on dedicated hardware when present, or based on a unique private seed for

the simplest devices.


Secure Time Services

Secure Time Services allow devices to know the current date and time with a reasonable

amount of confidence. This is useful e.g. when validating a remote certificate in a Transport

Layer Security (TLS) session, or making sure that a firmware signature is still valid before

installing it.

Secure Storage

In many cases, storing just a few bits securely is enough to maintain confidentiality over the

whole device. This service offers a key/pair storage service meant to store small amounts of

data in tamper-proof areas, with integrity checks and rollback protection.

Secure Attestation

Using this service, devices will be able to report on their own identity and health status

using signed messages. This service enables things like remote identity provisioning,

protection against device duplication, and counterfeiting.

3.7 Phase 3: Implement with Trusted Firmware-M reference implementation

Trusted Firmware-M (TF-M) is a reference implementation of the PSA specifications,

for IoT devices based on M-Profile platforms. The implementation for Arm Cortex-M

processors leverages Arm’s TrustZone technology. TF-M is an open source, open

governance project and is available at www.trustedfirmware.org, alongside the existing

Trusted Firmware-A project that targets Cortex-A-powered mobile and clamshell devices.

Other ecosystem partners may provide other implementations.

OSPSA

Developer APIs

Network

Apps

Middleware

Stor

age

Cry

pto

Attes

tatio

n

Audi

t Log

s

Prov

ision

Platf

orm

3rd

Part

y

Platform Drivers(Crypto, NONCE,

RNG, etc.)

TF-M Core (IPC, SPM, Interrupt Handling)



TBSA-M Hardware (SoC)

Secure Boot

SecureNon-Secure

Isolation Boundary

PSA RoT (Secure Privileged Domain)

PSA Spec/APIApplication RoTTF-M

Figure 4Trusted Firmware-M

https://developer.arm.com/docs/ddi0553/latest/armv8-m-architecture-reference-manual

https://static.docs.arm.com/100690/0100/armv8_m_architecture_trustzone_technology_100690_0100_00_en.pdf

https://www.trustedfirmware.org


TF-M publicly launched in March 2018 and is under active development. See Roadmap.

TF-M aims to provide:

A bootloader for authenticated boot, for both secure and non-secure images,

and secure upgrade of images.

Implementation of the PSA Firmware Framework specification, including the IPC

framework used for communication between different isolated secure partitions,

SPM to manage isolation between the partitions and Secure Interrupt Handling.

Set of Secure Services that can be used by secure and non-secure applications,

such as Secure Storage, Cryptography, Audit Logs, and Attestation.

Standardized PSA APIs to invoke Secure Services from non-secure applications.

Easy to use infrastructure to create additional Secure Services.

High configurability, ease of porting and integration.

OS support:

- RTX is being used for development work.

- Integration with Mbed OS, FreeRTOS and Zephyr support will be available soon.

Integration guide on how to integrate TF-M with other hardware platforms and

operating systems.

Cross-platform build system based on cmake and GNU tool chain.

GCC and ARMCLANG compiler support.

3.8 Mbed OS

Mbed OS is an open source operating system for MCU-based IoT devices, addressing all

Arm Cortex-M targets.

Mbed OS includes, extends, and adapts Trusted Firmware-M (TF-M) so that Mbed OS

users can enjoy the benefits of having secure firmware foundations that are ported to

a large number of hardware platforms. Security features provided by TF-M are used by

Mbed OS, according to the hardware capabilities of the local platform. For example, secure

partitions can be defined over dual-core boards, or through Armv8-M TrustZone. Where

TF-M provides generic methods and APIs, Mbed OS provides specific implementations,

wherever applicable.

Mbed OS offers support for:

Dual-core Armv6-M or Armv7-M architectures, where PSA separation is achieved by

running SPE and NSPE on separate MCUs.

Armv8-M (through TF-M), where PSA separation is achieved using TrustZone.

PSA Cryptographic APIs available to firmware application developers, with support

for some crypto hardware acceleration and external secure elements.

Secure Sockets (TLS) as part of high-level developer APIs.

https://developer.trustedfirmware.org/w/tf_m/planning/


Mbed OS comes with a rich set of drivers to support communication devices and protocols,

an integrated development environment, online and offline compiler tools, and support

for features like firmware updates over the air, to maintain deployed devices for extended

periods of time.

3.9 Ecosystem Enabling

The following include ecosystem enabling support tools that are now available:

FPGA Prototyping Board and the Arm Musca-A1 test chip board, to enable development.

Arm software development tools fully support PSA and Trusted Firmware for Cortex-M

(TF-M). CMSIS-ZONE helps to reduce the attack surface exposure by making it easy to

partition an application into secure and non-secure zones, utilizing TrustZone and/or an

on-chip memory protection unit (MPU). For code maintenance post-deployment, our

secure debug capabilities ensure that only verified sources access authorized areas for

debug, using debug over functional interface and certificate-based authentication.

https://developer.arm.com/products/system-design/development-boards/fpga-prototyping-boards/mps2

https://www.arm.com/products/development-tools/development-boards/musca-iot


4 Functional APIs and Security EvaluationArm provides APIs to enable software developers to have a consistent interface to

hardware-based security functions. They have been designed to be easy to use and have

sensible defaults. The API test kits will enable chip vendors and device makers to check their

software implementations are functioning, as expected. Three test kits are being developed:

1. PSA Developer APIs are the top-level APIs used by application developers and RTOS

vendors. These APIs have been designed to be used by software developers who

wish to use the hardware security features without necessarily being security experts

themselves. These APIs provide the top-level essential services of: crypto, secure

storage and attestation tokens.

2. PSA Firmware Framework APIs are designed for developers of secure functions (aka

Application Root of Trust Services or ARoT). Security experts wishing to add their own

security functionality can develop an ARoT service that can be used on different chips

using these standard APIs.

3. TBSA-M API test kit enables chip vendors to check the functionality of their chips

against the proposed hardware requirements checklist contained in the Trusted Base

System Architecture-M document.

Arm is also working with leading test labs on a security evaluation scheme for IoT chipsets

and devices. This work will lead to a multi-level evaluation scheme that can provide easy-

to-understand security levels for IoT devices. The first set of deliverables is a library of

IoT Threat Models and Security Analyses (TMSAs) that helps to inform the design of the

evaluation scheme along with the PSA Security Model (SM) goals.


5 Arm’s Supporting IPArm’s existing repertoire of security products and technologies enables silicon partners

to improve time to market of their products. Arm’s existing security products include:

A-Profile architectures, such as Armv8-A, incorporating Arm TrustZone.

Trusted Firmware-A (for A-Profile), a reference open source implementation,

which includes Trusted Boot and TEE-loading components.

Armv8-M architecture introduced TrustZone for the microcontroller market.

Arm TrustZone technology is a system-on-chip (SoC) and CPU system-wide approach

to security with hardware-enforced isolation to establish secure end points and

a device root of trust.

Arm CryptoCell, a collection of security modules that provide platform-level

security services.

Arm CryptoIsland, a family of highly integrated security subsystems, aimed at

providing on-die smartcard-level security.

Arm’s Physical Security Solutions: empowering designers to build in the necessary

physical protection at the heart of the device. The suite includes both processor IP

(Cortex-M35P and Arm SecurCore) equipped with tamper resistance, plus a range

of IP (CryptoCell-300P and CryptoIsland-300P) specifically created to mitigate side-

channel attacks.

The Pelion IoT Platform is a flexible, secure, and efficient foundation spanning

connectivity, device, and data management. It accelerates the time to value of

your IoT deployments by helping you easily connect trusted IoT devices on global

networks, invisibly administer them, and extract real-time data from them, to drive

competitive advantage.


6 ConclusionThe Platform Security Architecture (PSA) shifts the economics of security for

connected devices.

The PSA brings together industry best practice, to form an holistic set of architecture

documentation, security analyses and requirements, together with an open source

reference firmware implementation.

Arm’s ongoing investment will enable solutions, within the ecosystem, to continuously

evolve, improve and adapt. We will provide a range of hardware security solutions that

work with the PSA, to offer appropriate security robustness. For example, the PSA will

work with a wide range of Arm microcontrollers and system IP, such as Arm CryptoCell.

By reducing low level security fragmentation, Arm aims to enable a security ecosystem

that works for everyone – silicon partners, OEMs, platform owners, service providers,

consumers, and the wider developer community. We invite the Arm ecosystem to build

upon and expand our work on the PSA and Trusted Firmware-M.

Arm Platform Security Architecture Overview...2.2 Arm’s vision for a more secure IoT 9 3...

Documents

Transcript of Arm Platform Security Architecture Overview...2.2 Arm’s vision for a more secure IoT 9 3...