Chapter 2: Arm platform security architecture
Abstract
The arm platform security architecture defines a software architecture and design methodology along with firmware resources and tools. These resources will enable you to design secure IoT devices that meet and exceed all the current regulatory requirements, laws, and major standards. Devices that conform to the PSA standard can also be certified by independent security labs to demonstrate that good security principles and industry best practice have been applied to your design. The Platform Security Architecture methodology consists of four stages: analyze, architect, implement, and certify. Here, we will take an initial look at each PSA stage while later chapters will cover them in more detail.
Keywords
Arm platform security architecture; Communications; Software attack; Tampering; Lifecycle attack; Architect; Security model
Introduction
The Arm Platform Security Architecture defines a software architecture and design methodology along with firmware resources and tools. These resources will enable you to design secure IoT devices that meet and exceed all the current regulatory requirements, laws, and major standards. Devices that conform to the PSA standard can also be certified by independent security labs to demonstrate that good security principles and industry best practice have been applied to your design. The Platform Security Architecture methodology consists of four stages: analyze, architect, implement, and certify (Fig. 2.1). Here, we will take an initial look at each PSA stage while later chapters will cover them in more detail.
Analyze
The Platform Security Architecture provides an analysis of key threats to IoT devices and how to mitigate them. The threats against our devices can be divided into four key areas: communications, software attack, lifecycle attack, and device tampering (Fig. 2.2).
Communications
In our IoT model, a remote device will need to communicate with a server using TCP/IP based protocols. With today's microcontrollers, which feature sophisticated communications peripherals and widely available cloud servers, this has become fairly easy to achieve. However, in order to deploy a large-scale IoT system, we have to consider the confidentiality, integrity, and authenticity of the data as it is transferred to and from each device. This requires a firm knowledge of modern cryptographic algorithms and protocols. Outside of communication protocols, the same cryptographic techniques are used to protect our firmware image and stored data. For clarity, you will not need to code the actual cryptographic algorithms, and indeed, you should not, as this is a job for specialists. You will need to understand their proper application and configuration in order to create a secure communication channel and a secure device.
Software attack
Unlike most other microcontroller-based devices, each IoT device will contain sensitive data such as encryption keys, which must be protected against software hacking attempts. Such hacking attacks have long been a concern of personal computers (PC) using feature-rich operating systems such as Linux and Windows. Today, it would be considered asking for trouble to use an internet-connected PC without a firewall or virus checker. The world of small microcontrollers has not needed to consider such problems until now. In order to understand these threats and take them seriously, we will look at some key software attack techniques and how to mitigate them using the PSA security model. We will also look at adopting secure coding practices to avoid creating software vulnerabilities.
Tampering
Depending on your IoT system's location and physical accessibility, it may be exposed to direct attack from an adversary. This can take many forms, such as attempting to connect a debugger to read the FLASH, glitching clocks and power supplies, and reading and decoding external nonvolatile storage.
Lifecycle attack
When creating an IoT system, we must consider the lifecycle of our IoT devices from their initial manufacture through to eventual decommissioning. It is quite possible that our devices will be manufactured by a third party and delivered directly to a retail chain without ever coming into our possession. Yet, our devices must be provisioned with confidential data and onboarded onto our network. During their lifetime, we must have a way to update the firmware within our devices securely. We will also need to allow technicians access to the device for repair. Here, we may need to provide different debug access levels so that device secrets are protected. At the end of their lifetime, devices must be decommissioned so that any sensitive data are erased or “put beyond use.” Any of these lifecycle stages are prone to an attack by an adversary, such as stealing confidential data, suborning a device, or cloning counterfeit devices.
Application-specific threat modeling
While the Platform Security Architecture (PSA) is based on an analysis of the major threats facing IoT devices, it is a generic security platform and as such does not innately provide mitigation for every threat. At the start of a new project, in addition to defining the software requirements for our device, we need to consider the potential security threats against it. Working out these risks is part of the process called “threat modeling.” We can discover, document, rate, and provide mitigations against all the security threats to our actual system through threat modelling. It is highly likely that this process will be new to most embedded designers, so we will have a look at several threat modeling methods and tools in Chapter 8.
Architect
While there are many technologies and network configurations that can be used to create an IoT system, in this book, we will concentrate on developing a scalable fleet of IoT devices that connect to a cloud server using the TCP/IP protocols over a WiFi interface. A common temptation is to design an initial proof of concept, which does not consider any security issues. These are seen as an overhead that can be addressed later if the full design goes ahead. Such a system will meet the projects functional requirements, but a poorly designed IoT device will have multiple points of insecurity, which will be difficult or near impossible to fix later in the project. This will result in lots of extra work trying to “design in” security. Then, as we try to scale up such a system, the number of issues that need to be addressed will seem to increase exponentially. By understanding and adopting the PSA, it will be possible to develop a fully secure system from the very start of the project without becoming bogged down in lots of extra “unproductive” work. This will allow us to rapidly move from prototype to production code.
Security model
At the heart of the PSA is the security model. This defines a set of security goals, firmware specifications, and interface API's that you must meet in order to have a compliant device that is resistant to a software attack. The main elements of the security model are as follows:
Secure boot and root of trust
In a “normal” microcontroller project, we are accustomed to thinking of our application code running from the reset vector. With an IoT device, we must establish confidence that the device has not been tampered with before we let it execute the application code. To establish this trust, we must have some secure boot code that is resident in an immutable ROM. The secure boot code executes on startup to validate the application code and establish a root of trust (RoT), which all future operations will be based on. Fortunately, most, if not all, Cortex-M33 microcontrollers have a secure boot process as part of their system ROM code. While each family of devices has a different secure boot implementation, they all achieve similar results. We will have a look at a secure boot implantation and its supporting hardware in Chapter 11.
Secure update with antirollback
The provision of a secure update mechanism for the device firmware is a strict requirement of the PSA security model. In addition, all updates must be verifiable to ensure no unauthorized software is able to run on our device. An adjunct to this is the provision of an antirollback mechanism to ensure that an adversary cannot downgrade the device software to an earlier version with known vulnerabilities.
Isolation of secure code
Once a device has successfully booted, the application code will contain security functions and sensitive data such as encryption keys. As we will see, an adversary can conduct a software attack that can extract data from a poorly designed device. To make our device resistant to such software attacks, the security model defines two software partitions that isolate the application code from the security functions and any sensitive data. For now, you can think of this as an internal firewall where the secure partition provides security services to the application code. We will see how this can be implemented at the hardware level in Chapter 10 and at the software level in Chapter 12.
Security service
The secure partition is used to host the security functions as a set of security services. Each security service must conform to an API defined by the PSA security model. The security model must provide a mandatory set of security services with the following functions: attestation, cryptographic, storage, audit logging, and lifecycle. The secure partition structure is extensible so that other user or third-party services may be added.
True Random Number Generator (TRNG): Strictly speaking, a True Random Number Generator (TRNG) is not a security service in itself. However, a source of random numbers is critical for many of the cryptographic functions we will use. We will look at a typical microcontroller TRNG and how to establish a high-quality entropy source in Chapter 4.
Attestation: The attestation service is used to create security tokens that can be exchanged with an attestation server. The attestation tokens are used to identify and authenticate a device by providing a set of claims about a device and its capabilities. This allows a server to decide whether or not a device can be enrolled onto a network and what services can be granted. Attestation tokens may be generated on the fly, allowing them to contain some process data. For example, a metering system could generate an attestation token that identifies a meter along with its current readings. Ideally, a microcontroller should provide an immutable unique ID that can form the basis of the device attestation ID.
Cryptography: At the heart of the device, security is the cryptographic security service. The cryptographic service provides algorithms for confidentiality, integrity, and authentication. The cryptographic service is used to protect data being sent over a communication channel, “data in flight,” and data in device storage, “data at rest.” Additionally, the cryptographic service is used to validate firmware images before starting execution or device updates. As cryptography is such an important aspect of device security, it will be introduced over two chapters, which you should read before going to the PSA implementation sections. While there is no getting away from the fact that each cryptographic algorithm is complicated, the good news is that Arm has published a free-to-use open-source library called mbedTLS. Consequently, we only need to understand the purpose and best practice use of each cryptographic algorithm.
Secure Storage: The secure storage service provides two storage volumes: protected storage and internal trusted storage. The protected storage volume provides a storage space that may be located in either external memory or the microcontroller's internal FLASH memory. Protected storage provides a managed storage volume for application and process data. An item is stored with a cryptographic hash to provide integrity. Additionally, the data may be encrypted to provide confidentiality. A nonce (number once) may also be added as an antireplay measure. As its name implies, the internal trusted storage is located in the microcontroller's internal FLASH. The internal trusted storage is used to hold high-value device secrets such as encryption keys and other device intimate data. Consequently, the internal trusted storage always provides confidentiality, integrity, and authentication, so that stored data are held in a secure state and is bound to a specific device.
Audit: The audit service provides a means for the secure partition software to write log messages to the protected storage. The audit messages are timestamped using the microcontroller real-time clock and stored in the protected storage volume with confidentiality and replay protection. The nonsecure software can read and delete records in the audit log but cannot add a record.
Lifecycle: While there is not a specific lifecycle service, the concept of managing the device through its lifetime is built into the security model. Each IoT device can exist in one of six distinct lifecycle stages: assembly and test, provisioning, secured, nonroot of trust debug (service debug), root of trust debug (full debug), and decommissioned. When a device is manufactured, it will go through an assembly and test process and be programmed with an initial firmware image. It must next be provisioned with its device ID and device-specific secrets. At this point, the device will be locked down by enabling the secure boot. Once provisioned, it can then be onboarded or enrolled onto the IoT network to become a secure operational device. During its operational lifetime, it may become faulty, so our lifecycle must be able to place the device into a repair state to allow a service technician to connect a diagnostic tool and view data mediated by the application software while the secure software and data remains hidden. In order to resolve software bugs, our repair state must also have an additional state that allows an authorized design engineer to connect a debug tool to view the execution of the whole system, which is the application code and the partitioned security services. Finally, at the end of its life, a device must be fully decommissioned with any privileged data erased from the device.
Firmware update
The firmware update client is designed to co-operate with the second-stage bootloader so that firmware updates to the system images can be managed from within the application code. This includes multipart download and storage of firmware images, starting the installation process and confirming a successful update.
Implement
The PSA specifications define a wide range of requirements, many of which are a development project in their own right. In order to make PSA easy to adopt, Arm provides a reference platform that consists of both existing open-source projects and Arm-provided software components. The PSA platform components are in Table 2.1.
| Resource | Type | Description |
|---|---|---|
| mbedTLS | Firmware | Reference cryptography library |
| Trusted Firmware for Cortex-M (TF-M) | Firmware | Reference secure partition and security services |
| CMSIS-Zone Utility | Utility | Configuration tool for TrustZone Security peripheral |
| MCU Boot | Firmware | An Arm fork of the MCU boot second-stage bootloader |
Secure boot and assistive security features
Part of the implementation phase is selecting a suitable microcontroller. This is no mean feat as there are well over 8000 Cortex-M based devices from over thirteen different vendors. However, the introduction of the Cortex-M33 and the PSA has shaped the development of microcontrollers intended for use as IoT devices. These devices now provide a range of hardware features that “assist” the development of secure IoT nodes. While each implementation is unique to a given manufacturer, we will examine a real-world microcontroller in Chapter 11. In this book, we will use the NXP LPC55S69. This is one of the first Cortex-M33 based devices to be released and was designed with many advanced security features that provide direct hardware support for the PSA security model.
Second stage bootloader
The PSA software resources provide a version of the open-source MCUboot bootloader, which acts as the mandated secure update client. The MCUboot firmware is a sophisticated second-stage bootloader capable of managing multiple update images and validating the existing installed firmware. A set of Python scripts and tools are also included to version, sign, and encrypt update images for downloading into the device. A modified version of MCUboot is included as part of the Trusted Firmware pack (see below). This version uses the CMSIS-FLASH drivers to access the microcontroller memory, making the bootloader much easier to port between devices.
Partition
An essential part of the PSA security model is the ability to separate the device firmware into a nonsecure partition for the application code and a secure partition for the critical security code. While this can be achieved on any Cortex-M device, the Cortex-M33 security extension, TrustZone, is able to do this at the hardware level. This has many benefits such as reliability, lower power consumption, and better performance than a pure software “microVisor” implementation. In addition to the TrustZone peripheral, the Cortex-M33 Memory Protection Unit can also be used to further enforce access rights between the two security partitions. This creates a more complex memory map that must be accurately reflected in both the compiler/linker and software configuration functions across several different firmware subprojects.
Trusted firmware
Once we have partitioned our device, the security services will run in the “secure world” partition to be accessed by the application code in the “nonsecure world” partition. Setting up these services is one of those “projects in its own right” and would consume months of design time if you had to do it from scratch. Fortunately, Arm also provides an open-source reference implementation of the secure partition software—Trusted Firmware (TF-M). This firmware is designed to manage and provide the default security services required as part of the PSA specification. The TF-M firmware provides a standard API to the application code from its core library. The Trusted Firmware must be customized for a specific microcontroller by modifying a set of platform functions. Ideally, the platform code will be available from the device manufacturer, but you may need to do this yourself and you will certainly need to verify the platform functions. We will look at how to install, configure, and use the TF-M in Chapter 12.
mbedTLS and mbedCrypto
In addition to the trusted firmware, Arm also provides an open-source cryptographic library called mbedTLS, which can be used with Armv7-M and Armv8-M processors. The mbedTLS library was originally developed as a commercial product by PolarSSL before it was acquired by Arm and is now available for commercial and noncommercial use under a permissive Apache software license. A second version of mbedTLS called mbedCrypto is also available. mbedCrypto is a version of mbedTLS that has been rewritten to run as a security service within the PSA secure partition. Typically, this means an Armv8-M processor. Both the mbedTLS and mbedCrypto libraries can be used to provide cryptographic primitives within our application software, as well as creating and managing a secure network channel using the Transport Layer Security (TLS) protocol. We will look at both the cryptographic functions and the TLS protocol in Chapter 5.
Software components
In addition to the cryptography libraries, the PSA support software includes several open-source software components that are used to format and transport data between the device and server (Table 2.2).
| Component | Data format | Description |
|---|---|---|
| Paho MQTT | Message Queued Telemetry Transport Protocol (MQTT) | An IoT communications protocol between device and server |
| cJSON | Java Script Object Notation (JSON) | A lightweight standard for storing and transporting data in ASCII format |
| QCBOR | Concise Binary Object Representation (CBOR) | A lightweight standard for storing and transporting data in binary format |
We will have a look at each of these components and their matching specifications in Chapter 6 and also use them to connect to a commercial cloud server in Chapter 7.
PSA certification
The PSA methodology's final stage is your favorite and mine: certification. Before the IoT became an emerging technology, the IT industry had already considered the security certification requirements for computer systems. Today, there is an established path called the “Common Criteria for Information Technology Security Evaluation,” which is used to certify computer IT devices. The common criteria is part of the ISO/IEC 15408 standard and provides a formal methodology that is used by nation-states to provide security certification that is valid for multiple countries.
The Common Criteria provides a set of well-defined protection profiles against which devices can be tested. Once you have your device certified to the common criteria, it reduces or removes the need to test your device in each different country. This sounds ideal, but the common criteria is not well suited for certifying many IoT devices. First, the common criteria documentation is very abstract and typically requires a specialist to understand and implement its requirements against your particular device. This means it is quite expensive and also very time-consuming. This is less of a problem if you are making a consumer product such as a mobile telephone or creating a device for smart card technology. These devices will be made in large numbers and will be in use for a long time, making an expensive certification process less of a barrier. For our IoT systems, this whole process is both a prohibitively complex and expensive process designed to certify devices against requirements than are not really relevant.
We need a different system where we can test a large range of IoT devices and certify them to an appropriate level of security capability. This is the role of the Platform Security Architecture certification process. The PSA certification process is derived from the PSA design and specification documents. This makes the certification process accessible and easy for developers to understand. The PSA certification website provides a full overview of the scheme, a download of the certification questionnaire, plus a database of certified devices and software components: https://www.psacertified.org/.
PSACertified has been set up as an independent scheme that uses a number of security labs, with final certification being given through an international body called Trust CB who already specialize in certifying IT security products. This process allows PSACertified certification to meet multiregional IoT security requirements with a level of security appropriate for each use case and is backed by an internationally recognized authority. At the time of writing, there are five security labs that provide global coverage (Table 2.3).
| Certification lab | URL |
|---|---|
| Brightsight | https://www.brightsight.com/ |
| CAICT | http://www.caict.ac.cn/english/ |
| Riscure | https://www.riscure.com/ |
| UL | https://ims.ul.com/ |
| Prove and run | https://www.provenrun.com/ |
The PSA certification process has three levels. Assurance Level 1 is a baseline security assurance that all Cortex-M based IoT devices and software components should adhere to. Level 2 is mainly focused on proving that hardware devices and software components fully conform to the Level 1 requirements through analysis by a third-party security laboratory, and Level 3 provides substantial assurance against both software and hardware attacks (Fig. 2.3).
PSACertified level 1
Ideally, all IoT products will be certified to a minimum of Level 1 and it is intended to be an easy to follow process relying on a high degree of self-certification. The Level 1 certification is a methodically developed assessment with four key inputs: the PSA threat models and security analysis, security best practice, top 10 security goals, and finally, government regulations and regional requirements. An analysis of all four inputs is used to create a level of certification that exceeds all current government regulations. At the time of writing, there are three major standards that IoT devices need to comply with. These are NISTIR 8259 in the United States, ETSI 303 645 in Europe, and SB-327 in California. These map to the PSACertified Level 1 standard as shown in Table 2.4.
| PSA certification requirements | Required by ETSI 303 645 | Required by NISTIR 8259v2 | Required by SB-327 |
|---|---|---|---|
| Authentication/password | Yes | Yes | Yes |
| Configuration | No | Yes | No |
| Cryptography | Yes | Yes | No |
| Hardening | Yes | Yes | No |
| Logging | No | Yes | No |
| Privacy | Yes | Yes | No |
| Secure storage | Yes | Yes | No |
| Update | Yes | Yes | No |
PSACertified Level 1 certification is also used to certify microcontrollers and third-party real-time operating systems. This allows a device developer to base a system on precertified components, thus reducing the overall certification effort.
PSACertified Level 1 certification is based on a questionnaire that can be downloaded from the PSACertified website. The Level 1 questionnaire has under 50 questions covering the microcontroller, software components, and the full device application. Once you have filled in the questionnaire, it can be submitted to an authorized security laboratory who will then vet the questionnaire and provide any feedback where your device may need improvement. Once the security laboratory is happy that your device meets all the Level 1 requirements, it will notify the governing body, Trust CB, who will issue you a certificate that allows you to claim PSACertified Level 1 certification.
PSACertified Level 2
PSACertified Level 2 is currently aimed at silicon vendors. It is an extensive laboratory-based evaluation of the devices' PSA root of trust (RoT) and secure boot code. Level 2 testing is predominantly a white box evaluation against the PSA RoT protection profile. The testing laboratory will conduct scalable software and remote attacks against the PSA RoT to actively prove its conformance to the security model requirements. When the device passes, a certificate will be issued by Trust CB and the device will be listed on the PSACertified website.
PSACertified Level 3
At the time of writing, the Level 3 certification is still in development. This final certification level will provide substantial protection from hardware and sophisticated software attacks.
Conclusion
While you may initially view PSA certification as an endpoint of your project, the PSACertified website is also a good starting point since it carries a listing of all certified microcontrollers and software components. This should be your first port of call for device selection at the start of a project. It is also possible to download the certification questionnaire, which can be added to your project requirements. Again to be absolutely clear, you must include security requirements in your project from the start to have a fighting chance of creating a reliable IoT device.