Platform Security Architecture FAQs
Answers to frequently asked questions about Platform Security Architecture.
ARM’s developer website includes documentation, tutorials, support resources and more.
Over the next few months we will be adding more developer resources and documentation for all the products and technologies that ARM provides.Close
Sorry, your browser is not supported. We recommend upgrading your browser. We have done our best to make all the documentation and resources available on old versions of Internet Explorer, but vector image support and the layout may not be optimal. Technical documentation is available as a PDF Download.
Answers to frequently asked questions about Platform Security Architecture.
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:
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).
As demand for more secure IoT systems grows, the whole ecosystem has to respond. Adopting a common framework is a good commercial decision.
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.
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.
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.
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.
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.
The PSA documentation and reference source code are free of charge.
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.
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.
The PSA specifications and source code are publicly available to download from pages.arm.com/psa-resources. Further specifications will continue to be created and made public throughout 2019.
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.
At the highest levels PSA is architecture-agnostic, however, we are addressing Arm Cortex-M initially, with Trusted Firmware-M.
PSA doesn't yet look at this kind of threat, but we would like to provide guidance on this in the future. PSA is an ongoing journey that will evolve and increase in scope.
In general, hardware-based security will offer stronger mitigations against scalable attacks and will be easier to validate. However, the advantages of software flexibility and its ability to implement complex functions more easily means that, in practice, both approaches should be used. PSA takes the approach of security by separation, where software functions are able to use hardware support to be isolated from each other and thus reduce the opportunities available to malware.
Yes, the system hardware requirements (TBSA-M) guide how power controls should be handled and what should allow access to them. For instance, should they be allowed access from the non-secure or secure side etc. Normally, we’d expect things like regulators to only be controlled from the secure side.
PSA does address some lightweight hardware attacks. For instance, looking at the signals going in and out of an SoC, but it does not address lab attacks.
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.
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.
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.
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.
Arm is currently defining a PSA Certification and Compliance program, working with the ecosystem. More details will be released on this, in due course.
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.
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.