The recent deployment of connected devices, as part of the evolution of the Internet of Things (IoT), has led to a major increase in the number of IoT-based cyber-attacks. These attacks have highlighted the very real need for better security measures to be implemented, throughout the value chain of connected devices, covering high-level infrastructure, such as energy supply and connected vehicles to low-cost devices, such as webcams and smart lighting. Breaches in security present a host of issues for those operating in the IoT. Leaks in confidential information, theft of personal data, a loss of control of connected systems and the shutting down of critical infrastructure, all represent major areas at risk.
The growth of IoT-based services is founded on a diversity in the nature and type of device being connected to the internet, whether sensors, actuators or gateways. Not all of these devices, however, are high value, high specification appliances, with the vast majority likely to be small and built to a budget. Despite this, as recent high-profile attacks have demonstrated, even the cheapest of devices needs to be secure as they can act as portals into much larger systems. Overall, as the number of connected assets in the Internet of Things increases, the attack surface is expanding and so is the need for more robust, scalable defence systems.
Figure 1. Threat Categories
The Platform Security Architecture is an holistic set of threat models, security analyses, hardware and firmware architecture specifications. The PSA provides a framework, based on industry best practice, that allows security to be consistently designed in, at both a hardware and firmware level. It offers common ground rules and a more economical approach to building more secure devices. Additionally, Arm is delivering an open source reference implementation of PSA firmware for Armv8-M based devices. The components of PSA can be framed in three general design stages: Analyse, Architect and Implement.
The value of the Arm ecosystem is to provide diversity and choice to end-customers and this benefit extends to the IoT and its broad range of technologies and providers. Arm recognises this potential, alongside the risks that threaten the devices, systems and infrastructures operating within the IoT. PSA provides the common framework for the ecosystem, from chip designers and device developers, to cloud and network infrastructure providers and software vendors.
Arm is creating a cost-effective, scalable, easy-to-implement security framework that provides a basis for the industry to build more secure devices. Security can no longer be optional, and as an industry we have a shared responsibility to protect our connected world.
For more in-depth information, we have written a white paper Platform Security Architecture Overview covering:
To find out more on the PSA
Download PSA White Paper
Thanks for your advice!
1. Any unmodified RTOS will work in the normal world
2. No changes are required in the RTOS to support TF-M. All requests from the normal world are treated under a single context. If there are multiple, mutually distrusting tasks in the non-secure world, then the RTOS can take advantage of a TF-M APIs to manage multiple client contexts. More information can be found here https://developer.trustedfirmware.org/w/tf_m/design/ns_client_management/
3. It depends on what your definition of a complete OS is. TF-M is highly modular and can be configured as an event-driven library or can support multiple scheduled threads. The choice depends on application needs.
4. Mbed is an open source organisation that has multiple projects and are one of the first to use PSA. MbedOS uses TF-M services if they are available. TF-M uses MbedTLS to provide the PSA Crypto API.
Thank you Carl very much. Yes, I have got the paper.
Hi Matt, just to clear up this thread, our systems indicate the email was delivered to you (mine was caught in a filter). I've provided the direct download link via pm as well.
Great to see Trusted Firmware-M reference implementation.
I have some questions before I read the source code in Trusted Firmware-M reference implementation..
1. whether I can use another RTOS such as RTX/ThreadX in normal world while the Trusted Firmware-M reference implementation running in secure world or not?
2. And if yes, what changes should the third RTOS do to incorporate with Trusted Firmware-M reference implementation?
3. Is there a complete os running in secure world in the Trusted Firmware-M reference implementation?
4. what is the role of the mbed in the Trusted Firmware-M reference implementation.?