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
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
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.
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