You are here

Why IoT Matters and What Edge-to-Cloud Security Means | Cypress Semiconductor

Why IoT Matters and What Edge-to-Cloud Security Means

In the first and second blog posts from this series, we discuss why security in IoT matters and what edge-to-cloud security means. This blog will describe how AWS and Infineon work together to provide an integrated edge-to-cloud security solution with the PSoC® 64 MCU, while continuing to address the topics and issues we discussed from the first two blogs.

As a quick recap, the PSoC 64 solution has a dual-core architecture that is partitioned into a Secure Processing Environment (SPE), running on the Arm® Cortex® M0+ core, and a Non-Secure Processing environment, running on the M4 core. 

A high-level software stack view of the PSoC 64 Standard Secure solution is shown in Figure 1,

Figure 1: Software stack view of PSoC64 Standard Secure AWS Solution

To understand how these different pieces work together, we will be exploring security as it applies throughout the product lifecycle i.e.,

Figure 2: Device lifecycles in a typical IoT Product

Provisioning

The PSoC 64 is a Secure MCU, and this architecture treats the application firmware separately from security assets. There are several security assets which must be present in the chip to boot up correctly, from public keys used for secure boot, to certificates used for TLS connectivity. Provisioning is a mechanism by which your product-specific identity and security assets get into the chip.

The diagram below shows a high-level flow of how you would typically provision a PSoC 64 chip and program your application:

Figure 3: Provisioning a PSoC64

Every PSoC 64 chip comes with a pre-established Root of Trust (RoT), which is bound to Infineon in the form of a public key. The first step is to transfer this pre-established RoT to your own RoT, put in your product-specific security keys and policies (along with a bootloader), and, finally, program your application. The underlying mechanisms are presented in greater detail in the Secure Boot SDK user guide.

After this step, the chip is primed to go and has all the required information to securely boot up and connect to AWS IoT Core.

Power ON/Secure Boot

When the chip is powered ON, the first stage, which begins execution, uses immutable boot-code present in the Root of Trust. This immutable code validates and launches the Secure Bootloader, which is a part of the open source MCUBoot library for the PSoC 6 platform. The Secure Bootloader in PSoC 64 has been extended with the capabilities to parse public keys and other security policies which are provisioned during the secure manufacturing process.

The Secure Bootloader serially does three steps:

  • Validates the signature of the Trusted Firmware-M code against the public key present in the Root of Trust
  • Validates the application firmware code using a public key (either the same public key in the previous step or a different one) based on your configuration
  • Hands off execution to the TF-M code

Then, the TF-M firmware sets security parameters, like memory protections and cryptographic services needed in further stages, and begins the CM4 core so the application can start executing. Failing signature validation in any of these steps puts the chip in an unusable state. This process cannot be interrupted by any code in the user space and guarantees that only trusted code can be executed.

Figure 4: Root-of-Trust based Secure Boot in a PSoC64 Standard Secure AWS solution

Wi-Fi Connectivity

Before being able to connect to the Cloud, the device must first connect to the local Wi-Fi® access point. In this case, the FreeRTOS stack is integrated with the Wi-Fi driver and talks to the 4343W radio to establish connectivity. Optionally, it can also use the Bluetooth®/BLE communication interface to provide the needed Wi-Fi credentials in order for Wi-Fi connectivity to be established. After a successful connection to the access point, the TLS 1.2 handshake is initiated.

Figure 5: Blocks used for WiFi Connectivity

AWS Onboarding and Secure Communication

Now, when you want to connect to AWS IoT Core, you first need to pass the device certificate and perform a TLS handshake with the cloud server. During the standard PSoC 64 device provisioning flow, this key-pair and certificate is present in the Root of Trust subsystem; however, only the device certificate can be accessed by the TF-M. The device’s private key cannot leave the secure environment nor be accessed from the non-secure environment.

The FreeRTOS layer makes a cryptographic request for the certificate and key handshake using the standard PCKS11 calls. The PSoC 64 solution includes a PKCS11 <-> PSA (Platform Security Architecture) API translation layer which enables the calls to be passed to the TF-M layer. The TF-M layer then either retrieves the certificate or performs cryptographic operations based on the Root of Trust key/certificate store.

After this handshake, an encrypted communication channel is setup using the TLS 1.2 standard.

Firmware Update

The Secure Bootloader is based on the open source MCUBoot library, conceptualizing two areas in an MCU system:

  • A boot slot (Slot #0), which holds the firmware that will be cryptographically validated and executed
  • An update slot (Slot #1), which holds the update firmware

When the AWS IoT Core pushes a firmware update to the chip, the PSoC 64 communication/stack layer places the updated image into an update slot area and resets the chip. Finally, the Secure Bootloader verifies the cryptographic signature to ensure that the update image is valid, and then it updates the image in the boot slot and launches it.

Figure 6: Secure Firmware Update Overview

Order the CY8CKIT-064S0S2-4343W development kit today if you want to learn more about the PSoC 64’s integrated edge-to-cloud security solution firsthand.

In the next blog, we will discuss how to deploy your PSoC 64 Standard Secure MCU from one to a million devices and how the interplay of Infineon, Amazon, and Arrow Secure programming services provide a scalable, secure approach when manufacturing and deploying IoT designs. We will also focus on the attestation function and how you can initiate a cloud-based call asking your device to send a unique, verifiable fingerprint of its firmware’s current state based on the hardware Root of Trust.

To learn more about our PSoC 64 Secure MCU, visit: https://www.cypress.com/psoc64

By Michael Schy, Solutions Architect for the Specialist IoT team at Amazon Web Services

ALL CONTENT AND MATERIALS ON THIS SITE ARE PROVIDED "AS IS". CYPRESS SEMICONDUCTOR AND ITS RESPECTIVE SUPPLIERS MAKE NO REPRESENTATIONS ABOUT THE SUITABILITY OF THESE MATERIALS FOR ANY PURPOSE AND DISCLAIM ALL WARRANTIES AND CONDITIONS WITH REGARD TO THESE MATERIALS, INCLUDING BUT NOT LIMITED TO, ALL IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT OF ANY THIRD PARTY INTELLECTUAL PROPERTY RIGHT. NO LICENSE, EITHER EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, IS GRANTED BY CYPRESS SEMICONDUCTOR. USE OF THE INFORMATION ON THIS SITE MAY REQUIRE A LICENSE FROM A THIRD PARTY, OR A LICENSE FROM CYPRESS SEMICONDUCTOR.

Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms and Conditions of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms and Conditions of this site. Cypress Semiconductor and its suppliers reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.