Arm launches first set of Threat Models for PSA: IoT Security should start with analysis

At Arm TechCon last October, we announced a major program to improve IoT security, which we’ve named Platform Security Architecture (PSA). PSA is a common framework aiming to provide a holistic approach to IoT security. It has been designed to be a common foundation, which is easy to follow, whether you’re an OEM or a developer. PSA has been designed to fit resource constrained, microcontroller-based, devices and platforms – enabling it to be used on billions of future systems and chips. PSA has been warmly welcomed by the industry, analysts and press, so we are very excited to announce that by the end of March we will be providing some of the first code and documents, freely available to all.

The 3 elements of PSA

Fig.1: The three stages of PSA

Why do we need PSA?

To paraphrase the security analyst, Brian Krebs, if you connect devices to the internet you can expect them to be hacked. If your product is successful or your company has brand value, then attackers will spend more time exploiting any vulnerabilities. By introducing layers of hardware-based security and good security practice at the design stage, it becomes more difficult and, thus, uneconomic for attackers to exploit devices. For this reason, Arm has introduced PSA – to allow security to be quickly and economically designed into IoT devices, at the development phase. 

Learning from the smartphone industry

If you have been following the mass market consumer smartphones market for some time, you will have seen how security robustness has been transformed. My first touchscreen smartphone will have been easy to exploit (typically by breaking its secure boot and loading new software) in just a few weeks. Today, it’s not so easy and we see smartphones being sent to research labs, to extract secret keys and decrypt information. Smartphones are the ultimate connected consumer gadget, so it is instructive to consider what we can learn from the mobile industry and what is different for IoT. 

The four main security pillars that we can reapply to IoT

Mobile security can be considered in four parts:

  1. Isolation - using hardware to isolate sensitive operations and data away from the main part of the system. For example, an Arm TrustZone based Trusted Execution Environment or Secure Processing Environment (SPE)
  2. Communications security – providing end-to-end encryption of data flowing between the device and cloud
  3. Lifecycle security that provide updates to patch vulnerabilities over its lifetime
  4. Physical protection against tamper attacks. Some IoT devices will need protection only from remote software attacks others will need to resist physical tamper attacks.

Deciding on the correct level will be considered as part of designing an appropriate threat model. These same four aspects can also be applied to IoT devices, but it is the differences between the two markets that makes PSA a necessary step.

Security threats and appropriate counter-measures

Fig.2: the types of attack affecting IoT devices and the counter-measures to consider

IoT security requirements need to be established

The mobile industry is mature, for example, they have well established threat models and security analyses (also known as Protection Profiles). A typical smartphone will use a Trusted Execution Environment (TEE) that has a published threat model from GlobalPlatform, it will also have a Secure Element for additional protection against side channel attacks, that has a well-known threat model (PP0084). By contrast, the use cases in the IoT space are incredibly varied, often translating into poorly understood threats to the system and consequently vague security requirements.

IoT developers are usually not security experts

A typical smartphone OEM will have a large security team that understands the trusted hardware and software in detail, responding quickly to new vulnerabilities by providing updates. In contrast, many IoT developers do not have the benefit of working with a security team. So, even if they know they need to consider security in the design, they will probably lack access to expertise. This is one of the many reasons why the industry needs to simplify security for IoT platforms.

IoT diversity will benefit from a common security architecture

Another variation between the two markets is the huge hardware and software diversity found in IoT products, when compared to mobile devices. IoT devices can be based on many different commercial or open source operating systems (RTOS), plus the hardware implementations differ from vendor to vendor and chip to chip. Within this IoT fragmentation, there are many approaches to chip level security, each offering varying levels of protection. This creates a confusing market for OEMs and service providers, who need to have devices that are able to resist attack's and have data that is trustworthy. Arm recognizes the need for IoT diversity as it will drive market growth and the success of our partners. However, for the IoT market to grow and function (for the benefit of everyone) we need devices that have some common security ground rules.  PSA is Arm’s offering to solve this industry-wide problem, simplifying IoT security and providing a scalable and economic common recipe that IoT OEMs, silicon partners and developers can follow.

How can the Threat Models and Security Analyses (TMSA) process help developers?

PSA has three key stages: analyse, architect and implement. The first stage suggests that developers and manufacturers start their security journey by creating their own Threat Models and Security Analysis (also known as an English language Protection Profile). This process will help them to establish a set of security requirements, based on the key threats for their device and what assets need protecting.

The security analysis stage highlights some critical issues to address and some important questions to ask, such as:

  • What is the attack surface?
  • What are the assets that need to be protected?
  • What type of attack do I want to protect against?
  • What are the threats that will need to be considered? 
  • What are the security requirements?
  • How does my product fulfil the security requirements?

Developing your own TMSA is the starting point for deciding how robust, and difficult to crack, your security needs to be. It enables you to ascertain the security requirements necessary to protect your IoT product. At the end of the TMSA process, you (and your team) should have determined the appropriate security requirements for your device and how you plan to implement them.  

Threat models examples

Fig.3: Threat Models

First set of TMSA examples are now freely available from Arm

To help get you started, Arm is providing some examples of IoT market-relevant TMSAs. Although, Arm has provided protection profiles previously, they have only applied to Arm-based technology. The new TMSAs apply to widely available devices, which are becoming increasingly popular in the IoT space (a smart water meter, a web camera and an asset tracking device). While these documents provide guidance on specific items, they can also be used as a reference for how to carry out your own security analysis on a different product.

We would like the industry to build on these examples and carry out similar security analysis for their next commercial IoT product. For the first three TMSAs we have assumed that the devices are being designed to prevent an attack from a malicious person with “basic attack potential”. The appendices inside Arm’s TMSAs show how Arm CryptoIsland and Arm TrustZone technology, can be used to fulfill many of the security requirements. If the product needs to resist a more advanced attacker with sophisticated resources, such as an expert attacker in a lab using side channel techniques, then additional threats and requirements would need to be considered.

Future developments for PSA

The journey for PSA doesn’t end with the release of the TMSA documentation, in fact there is much more to come. If you’d like to know more about what’s coming for PSA, I recommend checking out our recent press release, which covers the release of the first reference code (Trusted Firmware-M) at the end of March, plus our plans surrounding PSA compliance programs.

The purpose of PSA is to make security simpler by offering high quality reference code, standard APIs and documents for free. Arm is working on a broad range of PSA topics to help the industry improve the security of IoT devices, please join in the conversation and let us know how we can improve our PSA programme for you. To get started look out for Trusted Firmware-M on GitHub in the next few weeks and download the first Arm TMSAs here.

Learn more about PSA