Platform Security Architecture FAQs

Answers to frequently asked questions about Platform Security Architecture.

General

  • What is PSA?

    Platform Security Architecture (PSA) is an IoT security framework being developed by Arm for the Arm ecosystem and wider industry, enabling the vision of one trillion secure connected IoT devices. PSA is designed to make security a reality across the IoT ecosystem, to allow end-users to continue to build their IoT-based businesses relying on more secure endpoint devices.

    PSA enables simpler, more scalable and cost-effective security lifecycle management for IoT devices. It consists of three parts:

    • A set of Threat Models and Security Analyses (TMSAs), derived from a range of typical IoT use cases.
    • Architecture specifications for firmware (FW) and hardware (HW) for common security functions.
    • An open source reference firmware (Trusted Firmware-M) implementation.
  • What is new?

    Arm is providing a holistic set of security documents and an open source reference implementation. It aims to provide the security foundations for resource-constrained IoT devices. Until now, the industry has focused on larger, Linux-based platforms. Although PSA is architecture agnostic, its initial focus has been on microcontrollers that run a real-time operating system (RTOS).

  • Why is PSA important?

    As demand for more secure IoT systems grows, the whole ecosystem has to respond. Adopting a common framework is a good commercial decision.

  • What are the benefits of using PSA?
    • Cheaper and easier to design in security using off-the-shelf components, from analysis documents, through architecture specifications to an open source trusted firmware implementation.
    • A reduction in risk even with limited security knowledge.
    • Demonstrate to your customers that you are committed to building more secure devices.
  • Are PSA and Arm TrustZone complementary?

    Arm TrustZone is an excellent way of conforming to PSA. In fact, if you have an Armv8-M processor, it’s a great starting point, as it’s simple and already encompasses a lot of the security requirements. Think of Arm TrustZone as an implementation option, but if you don’t have the option to use Arm TrustZone (for example, if you’re running Armv7-M) there are other options, such as to run twin cores and use those cores to act like two sides of Arm TrustZone.

  • How does PSA fit with Mbed?

    Through the PSA program, Arm has analyzed a number of common IoT use cases and drawn clear definitions for what is being protected (assets), and whom the attackers might be (threat models), together with security design patterns that describe typical solutions to common IoT security issues. Applying those security solutions has an impact on the way devices are designed and built, how their firmware should be written and how to update it over-the-air, and how a device lifecycle is managed throughout the years to always maintain a sufficiently high trust level in devices and their data.

    Arm Mbed is a secure and scalable platform that includes security at its very core, carefully implementing the PSA principles. The set of default device-side PSA services is offered as part of the default Arm Mbed firmware, providing each device with a unique certificate-based identity, trusted boot, and secure over-the-air update services, when connected to Pelion Device Management, for device lifecycle management. 

    Mbed OS is open and available to anyone to freely adopt, with large numbers of contributors from the ecosystem. By contributing PSA and Mbed, we can enable a much stronger and more secure IoT ecosystem, which the entire market can benefit from, including Mbed and its many partners. 

    To find out more on Mbed Client, please visit the webpage

  • How does PSA fit in with other Arm security, such as CryptoCell and TrustZone?

    Arm's IP and products, such as CryptoCell and TrustZone, are part of a menu of security technologies. PSA provides a recipe to implement Arm’s technology, allowing security to be designed in at the appropriate level.

  • How does one define the 'right level' of security and will Arm provide any security profiles?

    To help define the right level of security for different applications, Arm is releasing an initial set of Threat Models and Security Analyses (TMSA) documents. This first set is based on three popular IoT devices - a smart water meter, a network-connected camera and an asset tracking device. We would like our TMSAs to be representative of good examples of effective threat models and security analyses, and we hope that the relevant industries will develop their own TMSAs.

  • Does PSA restrict me to using only Arm IP and Arm software?

    Many parts of PSA can be used with non-Arm IP. Arm believes that it is our industry’s responsibility to make the IoT more secure.

  • How much does it cost to access PSA guidance?

    The PSA documentation and reference source code are free of charge.

  • Are the PSA specifications available via NDA or are they open?

    Early access to alpha-level PSA documentation requires an NDA with Arm. To gain access, please contact your Arm account manager. Note, we intend all PSA documents to be made public without NDA when each one reaches beta quality. For more information, see the roadmap section below.

  • When will PSA be available?

    PSA is continually evolving. Partners can gain access to the first draft specifications now and it will be made public in Q1 2018. Further specifications will continue to be created and made public throughout 2018. The reference firmware implementation will be public in Q1 2018.

Roadmap

  • When will Arm publish the PSA specifications and source code? And how can one gain access to these specifications? 

    The PSA journey starts with security analyses. We are releasing a representative set of Threat Models and Security Analyses (TMSA) documents (beta versions) at Embedded World 2018. These security analyses look at three popular IoT devices, as mentioned above, and are freely available to download here.

    Following this, Trusted Firmware-M will be made available as an open source project from April 2018. This software will develop more features and evolve. It is being provided under a permissive licence and can be run on an Arm development board. In terms of development boards, there are a couple of options available, such as Arm Musca-A1 test chip board, the first PSA development platform. In addition to this, one can use the Arm MPS2 FPGA board, or simulate on a Fixed Virtual Platform (FVP).

    Later, we will provide non-confidential access to architecture specifications, such as the PSA Firmware Framework (PSA-FF) document that describes the basic software architecture, concepts and language around PSA. This document is at the heart of PSA and provides the next level of technical detail.

  • Is there any roadmap for when PSA will extend into the high-end (Linux/Android)?

    Not yet, as our focus is currently on M-Profile. PSA is fundamentally independent of architecture, but we have prioritised the M-Profile. We will later provide details for IoT devices based on the Arm Cortex-A cores.

  • Will PSA apply to the Armv8-A processors?

    At the highest levels PSA is architecture-agnostic, however, we are addressing Arm Cortex-M initially, with Trusted Firmware-M. 

Physical Security

Implementation

  • Are there existing metrics on overheads that will come with security integration versus non-secured implementation?

    Arm is contributing PSA to the community and ecosystem. In future, it will be included in products produced by the Arm ecosystem. We have absorbed the development cost because we want people to implement more secure chips and devices – the IoT will not succeed without this kind of joined-up and collaborative thinking.

  • Which CPU architecture will Trusted Firmware-M (TF-M) support? 

    TF-M is currently prioritizing the Armv8-M architecture, such as Arm Cortex-M33 and Cortex-M23 systems. Reference software to demonstrate PSA features for Armv7-M-based systems is being developed in MbedOS, and TF-M will adopt that functionality as appropriate for PSA-compliant hardware systems.

  • Are there levels of implementation for different price points?

    Yes – the PSA Firmware Framework (PSA-FF) defines three levels of isolation between Non-Secure Processing Environment (NSPE), Secure Processing Environment (SPE), and within the SPE, between Trusted Functions and Secure Functions. These levels allow trade-offs between isolation models and cost.

  • What is the smallest RAM/ROM footprint that will be able to support PSA?

    We don’t have specific values, yet. The open source implementation (Trusted Firmware-M) is designed to be highly modular, such that by disabling features, it can be reduced in size to fit to highly constrained devices, while still providing basic secure computing support.

    The Threat Models and Security Analyses (TMSA) documents drive the security requirements for a device. Any product requirements document needs to include security requirements, as driven by the TMSA outcomes, along with market requirements. There is a big price and feature range across the IoT, but if the Firmware Framework implementation does not fit on the smallest device, then one may need to change the product requirements, accordingly.

Compliance and certification

Inter-processing Communication (IPC) and Partitioning

  • Is communication between secure partitions also via IPC, or syscalls?

    Between secure partitions, it’s via the IPC mechanism. The IPC mechanism is there to ‘police’; it’s a high-integrity piece of code that needs to be reviewed many times and needs to be very small, with a lower tech surface. If you’re calling into the Secure Processing Environment (SPE), you will need to use IPC and then calling between secure partitions, you will need to use the IPC mechanism, as well.

  • What is the difference between a trusted partition and a secure partition?

    The trusted partition is part of the Trusted Computing Base (TCB). The TCB has the smallest possible attack surface. It would be delivered as part of one block with the secure partition manager. Secure partitions could be delivered by third parties. It enables you to take code from third parties and integrate on your device. Sometimes you trust the third party, sometimes not; fundamentally, this is the reason for the difference.