Securing embedded systems using the PSoC 64
The number of products being connected to the Internet continues to grow at an exponential rate. The problem facing many product teams is that embedded software developers don’t have sufficient security experience. Lack of experience can lead to overlooked security requirements, security gaps, and poor implementation. The result is connected systems that are poorly protected and are low-hanging fruit for theft of intellectual property, along with device and user data. Rolf Horn, Applications Engineer at Digi-Key Electronics further explores.
This article originally appeared in the Nov'22 magazine issue of Electronic Specifier Design – see ES's Magazine Archives for more featured publications.
Designers of microcontroller-based systems have several solutions available to them that can be used to simplify security implementations and provide them with the tools to do so successfully. For example, single-core microcontrollers can use Arm’s TrustZone, which is part of the Armv8-M architecture (and beyond). There are also solutions with multicore microcontrollers. This article shows how developers can use multicore processors to secure their embedded solutions. Specifically, it examines the Cypress PSoC 64 secure microcontroller and the tools it provides to implement a secure solution.
Embedded security fundamentals
One of the core fundamentals of designing a secure product is to leverage hardware-based isolation. This isolation can come in many forms, such as an isolated execution environment, or isolated memory based on a memory protection unit (MPU). At the highest level, a microcontroller needs to be able to separate its execution environment into a secure processing environment (SPE) and a non-secure processing environment (NSPE).
An SPE is an isolated execution environment that keeps its memory, components, and application code separate from the NSPE. The SPE can be thought of as a security processor. The SPE runs secure code and operations such as a secure operating system and/or a root-of-trust (RoT). The SPE will also execute trusted services such as cryptography, secure storage, attestation, and secure logging. A limited number of trusted applications related to secure operations will run in the SPE.
The NSPE, for its part, can be thought of as the feature-rich execution environment that runs everything, except for secure operations. In fact, The number of products being connected to the Internet continues to grow at an exponential rate. The problem facing many product teams is that embedded software developers don’t have sufficient security experience. Lack of experience can lead to overlooked security requirements, security gaps, and poor implementation. The result is connected systems that are poorly protected and are low-hanging fruit for theft of intellectual property, along with device and user data. Rolf Horn, Applications Engineer at Digi-Key Electronics further explores. Securing embedded systems using the PSoC 64 DESIGN 35 ELECTRONICSPECIFIER.COM the NSPE is really the familiar programming model that most embedded developers are used to; it has an RTOS and most of the application’s components.
Hardware-based isolation is one of the core tenants, or best practices, provided by Arm Platform Security Architecture (PSA) to build secure systems. The different layers of isolation that we’ve just discussed can be seen implemented in Figure 1, with the PSoC 64 being the example. In this example, the SPE and NSPE (1) produce hardware isolation by having the run-time environments on separate processors. In addition to run-time separation, the RoT and Trusted Services are further isolated (2). Finally, each trusted application in the SPE is also isolated using tools like trusted partitions and MPUs (3).
The PSoC 64 is a dual-core microcontroller where the NSPE is executed on an Arm Cortex-M4 processor, and the SPE is executed on an Arm Cortex-M0+ processor. The Arm Cortex-M0+ runs all the security functions and can communicate with the Cortex-M4 through an inter-processor communication (IPC) bus. The architecture limits access to the SPE, which is hardware isolated.
To get started using the PSoC 64, developers will want to check out the PSoC 64 Secure Boot Pioneer Kit.
The PSoC 64 Secure Boot Pioneer Kit
The PSoC 64 Secure Boot Pioneer Kit (Figure 2) has everything that developers need to get started with securing their applications. First, it has a PSoC 64 module that has the PSoC 64 microcontroller, external memory, and all the support circuitry (shown in red). The external memory can be used to store application code or used to store new firmware images for secure firmware-over-the-air (FOTA) updates.
Next, it has a Wi-Fi module that allows developers to connect the board to a network. The Wi-Fi module is especially useful for IoT applications where the board will connect to cloud services like AWS or Azure. The development board supports Amazon FreeRTOS, which we will discuss in the next section.
Finally, the Pioneer Kit supports a wide range of expansion capabilities such as pin headers, Arduino headers, and a range of sensors. Developers can leverage the on-board touch slider and touch buttons, push buttons, potentiometer, and much more. The board is also set up to make customisation quite easy for nearly any application.
The PSoC 64 secure software suite
Designing a secure embedded application can be time-consuming and challenging. Developers should be looking for solutions that help decrease costs and time-to-market while ensuring that their application is secure. To assist in this, the PSoC 64 provides a wide range of software that allows developers to quickly build a secure application.
For example, the CySecureTools provides developers with a toolset for creating keys and certificates, as well as tools for signing user applications and provisioning Cypress microcontrollers. The tool allows developers to transfer the Cypress RoT and then inject their own security assets. Information about how to set up and use CySecureTools can be found in the github repository README file.
A tool that IoT developers will find useful is support for AWS using FreeRTOS. The github repository contains useful examples for using FreeRTOS and AWS with the PSoC 64. The first example that developers would be interested in is the ‘Hello World’ application that transmits MQTT messages from the PSoC 64 to the AWS cloud. This example allows the developer to walk through the provisioning process, key generation, and deployment phases. At the end of the example, developers have a secure embedded device connected to AWS. Details about how to get started can be found in the Getting Started with CY8CKIT-064S0S204343 kit guide.
Secure applications with Trusted Firmware-M (TF-M)
The PSoC 64 provides developers with an out-of-the-box security framework that can be easily customised for an application. Developers may find it useful to understand what is going on behind the scenes from a software perspective. Specifically, the PSoC 64 firmware leverages an open-source baseline security framework known as Trusted Firmware-M, or TF-M.
TF-M is a reference implementation of the Arm PSA IoT Security Framework. It provides developers with useful security tools such as device attestation, firmware verification, cryptographic services, device secret management, and secure partitioning, just to name a few. Cypress leveraged TF-M to build its security framework so that developers can then use it in their applications.
Developers can modify their security framework by adding their own code, adding security profiles, and much more. However, it is important to keep in mind that the more the SPE software is modified, the greater the chance that a vulnerability will be added. Developers need to carefully weigh the risks associated with changes, additions, or subtractions to the baseline firmware.
Tips and tricks for securing embedded applications
Developers looking to secure their embedded applications for the first time have much to consider. Here are several ‘tips and tricks’ that can simplify and speed up development:
- Perform a threat model and security analysis (TMSA) early in the development cycle
- Use a development board to test out the device RoT, Secure Bootloader, device provisioning process, and firmware updates
- Don’t implement security alone! Leverage existing open source and secure firmware stacks to minimise rework
- Be sure to think through the device’s life cycle, including how it is to be securely decommissioned
- Explore tools like the CySecureTools; such tools come with example security templates, software, and examples
- When cloning the FreeRTOS github repository, clone the latest tagged version. Cloning the active mainline often results in finding tool incompatibility and bugs that are still in-progress
- Start a project by walking through the Getting Started with the Cypress CY8CKIT-064S0S2-4343W kit. It provides all the necessary information to get a baseline application running that can then be modified for specific product purposes
Developers that follow these ‘tips and tricks’ will find that they save quite a bit of time and grief.
Security doesn’t have to be hard. Embedded developers should be focusing on their product’s differentiators, their secret sauce. In most cases, that’s not security. This article explored how the PSoC 64 can help developers quickly secure their applications by providing not just a hardware-based isolation environment, but by providing a framework of software tools. Together, the hardware and software solutions provide developers with an accelerated security development cycle.