Mitigating Supply Chain Risks in Embedded Firmware: A Guide to Secure Boot and Firmware Updates

Mitigating Supply Chain Risks in Embedded Firmware: A Guide to Secure Boot and Firmware Updates

Did you recently experience a device bricked due to a compromised firmware update? You're not alone. Modern embedded systems are increasingly reliant on complex supply chains, making them vulnerable to malicious actors seeking to inject compromised code. A compromised firmware update can render your device unusable, steal sensitive data, or even control physical functionality – a scenario avoided by robust secure boot and secure firmware update strategies. This article delves into mitigating these risks by implementing a layered approach to secure boot and firmware updates.

Core Concepts

Before diving into implementation, it’s crucial to understand the underlying principles. Let’s break down secure boot and secure firmware updates:

Secure Boot: Secure boot is the process of verifying the integrity of the firmware before it's executed. It prevents the execution of unauthorized or malicious code. It operates at the hardware/firmware level, ensuring that only trusted firmware can run on the device.

Secure Firmware Updates (SFU): SFU involves securely transferring and installing updated firmware onto the device, protecting it from malicious updates during the process. This protects against attackers modifying the firmware before deployment.

Key Components of a Secure Boot System:

• Bootloader: The first code executed when the device powers on. It’s responsible for verifying the integrity of the next stage of the boot process.
• Hardware Root of Trust (HRoT): Typically a dedicated hardware component (e.g., a secure element, Trusted Platform Module – TPM) that provides a secure foundation for the entire system. It’s responsible for generating and storing cryptographic keys.
• Cryptographic Keys: Used to sign and verify the integrity of the firmware image. These keys are protected by the HRoT.
• Firmware Image: The actual code that runs on the device.
• Verification Chain: A chain of checks performed by the bootloader to verify the integrity and authenticity of each component in the boot process.

Diagram:

graph TD
    A[Power On] --> B(HRoT);
    B --> C{Key Verification};
    C -- Valid --> D[Bootloader];
    C -- Invalid --> E[Device Failure];
    D --> F{Firmware Verification};
    F -- Valid --> G[Execution];
    F -- Invalid --> H[Device Failure];

Secure Firmware Update Process:

SFU typically involves these stages:

1. Image Signing: The firmware image is digitally signed using a private key stored in the HRoT. The signature ensures the integrity and authenticity of the image.
2. Image Storage: The signed firmware image is stored securely (e.g., on a secure flash memory).
3. Update Request: A trigger (e.g., a software update mechanism) initiates an SFU process.
4. Secure Transfer: The signed firmware image is securely transferred to the device (e.g., over a network or via a physical medium).
5. Image Verification: The device verifies the signature of the received image using its public key (also stored in the HRoT).
6. Image Installation: If the verification is successful, the firmware image is installed onto the device.

Implementation

Let's explore how to implement secure boot and SFU. This example focuses on using a hypothetical, but common, approach.

Hardware Requirements:

• A microcontroller or SoC with secure boot capabilities (often built into newer ARM Cortex-M series).
• A hardware root of trust (HRoT) – a dedicated secure element or TPM. This is not a common requirement for very low-cost devices but is critical for high-security applications.
• Secure flash memory for storing the firmware and signing keys.

Software Considerations:

• Bootloader: A customized bootloader that handles secure boot and SFU.
• Cryptographic Libraries: Libraries for cryptographic operations (e.g., RSA, ECC) to sign and verify firmware images.
• Key Management System (KMS): A system for securely storing and managing cryptographic keys.

Step-by-Step Walkthrough:

1. Hardware Setup: Ensure your microcontroller/SoC has secure boot features enabled. If using a TPM, configure it for key storage and cryptographic operations.
2. Bootloader Development: Develop a custom bootloader that performs the following tasks:
   • Key Loading: Loads the public key from the HRoT.
   • Signature Verification: Verifies the signature of the firmware image.
   • Firmware Installation: Installs the verified firmware image.
3. Firmware Signing: Use a cryptographic library to sign the firmware image with a private key stored in the HRoT.
4. Secure Image Storage: Store the signed firmware image securely in flash memory.
5. SFU Implementation: Implement the SFU process, including secure transfer, verification, and installation.

Gotchas:

• Key Rotation: Regularly rotate cryptographic keys to mitigate the impact of key compromise.
• Firmware Updates During Operation: Avoid updating firmware while the device is running critical operations, as this could lead to data corruption or device instability.
• Secure Storage: Ensure that cryptographic keys are stored securely and are protected from unauthorized access.

Code Examples

Here are two code snippets illustrating key aspects of secure boot and SFU. These are illustrative and may need adaptation for your specific hardware and software environment.

1. Firmware Signing (using OpenSSL):

#include <stdio.h>
#include <openssl/rsa.h>
#include <openssl/evp.h>
#include <openssl/err.h>

int main() {
    RSA *rsa;
    EVP_PKEY *pkey;
    FILE *fp;
    char *filename = "firmware.bin";
    char *private_key_filename = "private.pem";
    char *public_key_filename = "public.pem";

    // Load the private key
    pkey = PEM_read_bio_PrivateKey(stdin, NULL, RSA_PKCS1_KEYTYPE, NULL);
    if (!pkey) {
        fprintf(stderr, "Error loading private key: %s\n", ERR_error_string(ERR_get_error(), NULL));
        return 1;
    }
    rsa = RSA_import_key(RSA_PKCS1_KEYTYPE, pkey, 0, NULL);

    // Load the firmware image
    FILE *fp = fopen(filename, "rb");
    if (!fp) {
        fprintf(stderr, "Error opening firmware image: %s\n", filename);
        return 1;
    }
    unsigned char firmware_data[4096];
    size_t bytes_read = fread(firmware_data, 1, sizeof(firmware_data), fp);
    fclose(fp);

    // Sign the firmware data
    int status = RSA_sign(rsa, firmware_data, bytes_read, NULL, NULL);
    if (status != 1) {
        fprintf(stderr, "Error signing firmware: %s\n", ERR_error_string(ERR_get_error(), NULL));
        return 1;
    }

    // Write the signed data to a new file
    fp = fopen("signed_firmware.bin", "wb");
    if (!fp) {
        fprintf(stderr, "Error opening file for writing: %s\n", "signed_firmware.bin");
        return 1;
    }
    fwrite(firmware_data, 1, bytes_read, fp);
    fclose(fp);

    printf("Firmware signed and saved to signed_firmware.bin\n");
    return 0;
}

2. Secure Firmware Update (simplified):

c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

// Placeholder for secure transfer (e.g., over network)
void secure_transfer(const char *firmware_data, size_t size) {
    // In a real implementation, this would handle secure transfer of the firmware image
    printf("Securely transferring firmware data...\n");
}

int main() {
    const char *firmware_file = "signed_firmware.bin";
    size_t firmware_size = 4096;
    char *destination_file = "new_firmware.bin";

    // Read the firmware data
    FILE *fp = fopen(firmware_file, "rb");
    if (!fp) {
        fprintf(stderr, "Error opening firmware file: %s\n", firmware_file);
        return 1;
    }
    unsigned char firmware_data[firmware_size];
    size_t bytes_read = fread(firmware_