Add Firmware Security to an IoT Design with a Single Chip

In an increasingly security aware IoT landscape, IoT developers face seemingly conflicting demands for rapid development and tighter security for all phases of the application lifecycle. While many emerging solutions come with mechanisms for encryption, IoT designs need to be able to address a wider range of security threats.

To allow them to do so, IoT applications need to build on a root-of-trust established with secure boot and firmware updates at the device level.

This article will show how, using a single security device from Microchip Technology, developers can rapidly implement a range of security mechanisms needed to ensure IoT application security.

The many threats to IoT security

As with any embedded system, IoT designs face a continual stream of threats. As hackers employ new attacks, developers hurry to close security holes. In deployed devices, the need to update IoT firmware adds to potential weaknesses in security. For example, even the use of a simple firmware validation check can leave the software exposed. In this situation, developers might hope that querying some external resource for validation might catch attempts to replace firmware with hacked code. Yet, even relatively novice hackers can replace firmware with code that ignores such validation checks.

Use of encryption alone to lock down firmware offers no sure remedy. Even encryption can fall to attacks such as chosen ciphertext attacks, where hackers determine the encryption key by studying the target system’s decryption process. These types of attacks can be difficult to mitigate, but the use of authentication with encryption is known as an effective defense.

In building resource-constrained IoT devices, however, developers who use conventional software-based security methods face added complexity and performance issues. The availability of Microchip Technology’s CEC1702 cryptographic embedded controller allows developers to address heightened security concerns with little additional effort during development, and with minimal impact on design performance.

Full-featured MCU

Designed to support the diverse nature of IoT security requirements, the CEC1702 combines an ARM^® Cortex^®-M4F processor with a full slate of peripherals, including a multi-channel analog-to-digital converter (ADC), UARTs, GPIOs, PWM outputs, LED interfaces, several counters/timers, and multiple I²C and SPI controllers (Figure 1).

Figure 1: The Microchip Technology CEC1702 cryptographic embedded controller combines a high-performance ARM Cortex-M4F core with general-purpose peripherals and specialized support for authentication and encryption. (Image source: Microchip Technology)

While the device can meet functional requirements for a typical IoT design, its distinguishing features lie in its security capabilities. The CEC1702 combines fundamental security features such as secure storage and data protection mechanisms with multiple integrated cryptographic engines. Along with a multi-purpose AES crypto engine, the device includes a crypto hash engine and public key engine that provides hardware support for multiple algorithms including RSA, elliptic-curve Diffie–Hellman (ECDH), and elliptic curve digital signature algorithm (ECDSA), among others. Because the hardware security engines can perform crypto algorithms orders of magnitude faster than software-based methods, developers can employ strong encryption and authentication without compromising application performance.

At the hardware design level, developers can use the CEC1702 as a standalone MCU in an IoT design, or add the device through its SPI connections to existing MCU based designs with little additional effort. For their IoT software design, developers can use the CEC1702’s encryption and authentication features to implement secure communications between the IoT device and the cloud.

Beyond serving more traditional needs for secure communications, the device’s security mechanisms offer critical support for broader lifecycle security requirements, including pre-boot firmware authentication and secure firmware update. With its ability to authenticate firmware, the CEC1702 provides the hardware foundation for creating the root of trust that lies at the heart of security in connected systems, including the IoT.

Secure boot

In a typical MCU-based IoT system, the CEC1702 would connect via SPI to the external Flash memory storing firmware, for both the host MCU and the CEC1702 (Figure 2). When the system powers up, the CEC1702 begins running, holding the host MCU in reset until it authenticates the security of the application code used to boot the host MCU.

Figure 2: Working through a shared SPI bus, the Microchip CEC1702 uses its integrated security mechanisms to ensure that the host application processor runs only validated firmware. (Image source: Microchip Technology)

The root-of-trust lies with the CEC1702’s sequential approach to firmware authentication needed for secure boot (Figure 3). When the CEC1702 powers up, it first runs boot firmware loaded in ROM at the factory. Because this ROM code cannot be changed, this first step in the boot process inherently builds on a trusted foundation. Although developers can choose to load the application firmware without authentication or encryption, use of these security mechanisms helps continue the chain of trust to the end of the boot process. Using these security mechanisms, the CEC1702 boot ROM code authenticates and decrypts application firmware designed to run on the CEC1702.

In the final step in this sequence, the CEC1702 authenticates and decrypts application firmware designed to run on the host MCU application processor. Because code is validated at each step, the final code image running on the host application processor is trusted, completing the root of trust.

Figure 3: The CEC1702 boot process applies validation checks to each step in the boot process to establish the root of trust needed for IoT security. (Image source: Microchip Technology)

During the secure boot process, the CEC1702 uses security data held in its integrated Efuse one-time programmable (OTP) memory to validate the firmware against information contained in the firmware envelope (Figure 4). For authentication, the device uses a public key held in Efuse to validate the firmware envelope’s ECDSA signature created during image generation (described below). Because that signature is created using a private key held by the customer, this stage of firmware validation ensures the legitimacy of the firmware source.

Figure 4: The image generation process wraps each firmware image with security information required to authenticate and decrypt the image. (Image source: Microchip Technology)

Although image encryption is optional, the combination of authentication and encryption adds extra security protection as noted earlier. When the developer does use encrypted firmware, the CEC1702 follows the authentication process with a decryption stage using ECDH key exchange to create the decryption key.

In this process, the CEC1702 uses a (different) private key contained in Efuse as part of the ECDH algorithm that generates the proper decryption key (Figure 5).

Figure 5: The CEC1702 handles the ECDH key exchange mechanism using a combination of data held in its embedded Efuse memory and data transmitted with the firmware image. (Image source: Microchip Technology)

Here, the device combines the NIST P-256 curve generator point (Gx,Gy in Figure 5) held in Efuse, the private key (s, in Figure 5) held in Efuse, and the public key (Rx and Ry terms in Figure 4) embedded in the firmware envelope to derive the key (Kx in Figure 5) used to finally decrypt the firmware image.

A distinct advantage of this approach is the ability of the underlying elliptic curve methods to provide very robust security with relatively short keys.

Rapid development

Despite the complexity of the CEC1702’s security mechanisms, Microchip has gone out of its way to make it relatively easy for developers to take full advantage of the chip’s firmware authentication and encryption capabilities. The company’s Efuse generator tool provides a simple interface for specifying ECDSA and ECDH keys and generating the Efuse data (Figure 6). After generation, developers can use any JTAG programmer to program the CEC1702 Efuse OTP memory.

Figure 6: The Microchip Efuse generator provides a simple interface for creating firmware images with associated security data used for authentication and decryption. (Image source: Microchip Technology)

For hardware development, Microchip Technology’s SecureIoT1702 (DM990012) demo board offers a simple platform to jumpstart hardware development. Along with pushbuttons, LEDs, and a small LCD, the board includes Microchip’s SST26VF016 16 Mbit flash device for storing firmware images. Along with headers for serial flash programming, JTAG debug, and others, the board includes MikroBUS headers for supporting a wide range of compatible hardware expansion boards.

Developers can attach a Microchip ATWINC1500 Wi-Fi clicker board to a MikroBUS expansion slot on the demo board to quickly connect the SecureIoT1702 board to the Microsoft Azure cloud (Figure 7).

Figure 7: Developers can quickly connect to the Microsoft Azure cloud using the Microchip SecureIoT1702 demo board, ATWINC1500 Wi-Fi expansion, and Microchip’s SecureIoT1702 software package. (Image source: Microsoft Azure)

The SecureIoT1702 demo board has gained recognition from Microsoft as an Azure certified IoT device with DICE (Device Identity Composition Engine) hardware support. Although beyond the scope of this article, DICE is an emerging standard for trusted devices that specifies a secure boot process using separate stages of validation for building a root of trust (see Figure 3).

Using Microchip’s SecureIoT1702_Azure_IoT_build software package, developers can quickly connect the SecureIoT1702 board to the Azure cloud through the Azure IoT Hub. As with other emerging IoT platform offerings, the Azure IoT Hub provides services such as authentication, device registration, and others required to connect IoT hardware devices to the Azure cloud. The software package combines the Azure IoT Device software development kit C language (SDK) with hardware drivers and the mbedTLS full TLS (Transport Layer Security) stack.

Sample software included in the package includes a pre-configured root certificate, X509 certificate, and a private key so developers can easily authenticate with the Azure cloud. As the sample software demonstrates, developers only need to make a few calls to load the security data and begin sending IoT data (Listing 1). Using this basic design pattern, developers can extend the board’s functionality and even begin exploring secure over-the-air update techniques using the CEC1702.

Copy
/* Setting Message call back, so we can receive Commands. */
if (IoTHubClient_LL_SetMessageCallback(iotHubClientHandle, ReceiveMessageCallback, &receiveContext) != IOTHUB_CLIENT_OK)
{
    (void)printf("ERROR: IoTHubClient_LL_SetMessageCallback..........FAILED!\r\n");
}
else
{
    (void)printf("IoTHubClient_LL_SetMessageCallback...successful.\r\n");
 
    /* Now that we are ready to receive commands, let's send some messages */
    size_t iterator = 0;
    do
    {
        if (iterator < MESSAGE_COUNT)
        {
            sprintf_s(msgText, sizeof(msgText), "{\"deviceId\": \"myFirstDevice\",\"windSpeed\": %.2f}", avgWindSpeed + (rand() % 4 + 2));
            if ((messages[iterator].messageHandle = IoTHubMessage_CreateFromByteArray((const unsigned char*)msgText, strlen(msgText))) == NULL)
            {
                (void)printf("ERROR: iotHubMessageHandle is NULL!\r\n");
            }
            else
            {
                MAP_HANDLE propMap;
 
                messages[iterator].messageTrackingId = iterator;
 
                propMap = IoTHubMessage_Properties(messages[iterator].messageHandle);
                (void)sprintf_s(propText, sizeof(propText), "PropMsg_%zu", iterator);
                if (Map_AddOrUpdate(propMap, "PropName", propText) != MAP_OK)
                {
                    (void)printf("ERROR: Map_AddOrUpdate Failed!\r\n");
                }
 
                if (IoTHubClient_LL_SendEventAsync(iotHubClientHandle, messages[iterator].messageHandle, SendConfirmationCallback, &messages[iterator]) != IOTHUB_CLIENT_OK)
                {
                    (void)printf("ERROR: IoTHubClient_LL_SendEventAsync..........FAILED!\r\n");
                }
                else
                {
                    (void)printf("IoTHubClient_LL_SendEventAsync accepted message [%zu] for transmission to IoT Hub.\r\n", iterator);
                }
 
            }
        }
        IoTHubClient_LL_DoWork(iotHubClientHandle);
        ThreadAPI_Sleep(1);
 
        iterator++;
    } while (g_continueRunning);

Listing 1: The Microchip Azure IoT software package includes all the software required to connect the SecureIoT1702 to the Azure cloud, including sample software demonstrating transactions with the Azure IoT Hub. (Code source: Microchip Technology)

Conclusion

As the IoT extends deeper into more applications, poorly secured IoT devices pose a significant threat to IoT networks and applications. To enhance security, IoT developers need to employ security methods able to establish a root of trust at the IoT system level. Developers face considerable challenges using conventional security methods without dramatically increasing design complexity and degrading overall performance.

Using the Microchip CEC1702 cryptographic embedded controller, however, developers can quickly create IoT applications built on a firm root-of-trust.