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?

    The following PSA resources are now available: Threat Models and Security Analyses documentation, architecture specifications, open source reference implementation firmware (Trusted Firmware-M), and first level PSA APIs and API Test kits. All available resources can be downloaded from pages.arm.com/psa-resources.

    Further specifications will continue to be created and made public throughout 2019.

Roadmap

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.