Secure Boot and Firmware Updates in Embedded Systems

Why Secure Boot and Secure Updates Matter

Embedded devices are increasingly connected to the internet, making them targets for attacks. Without secure boot and secure firmware updates, an attacker could:

• Replace your firmware with malicious code
• Modify firmware to disable safety features
• Inject backdoors that persist across reboots
• Brick devices by pushing corrupt updates

Secure boot ensures that only authentic, unmodified firmware runs on your device. Secure firmware updates ensure that only authorized updates from trusted sources are installed.

Secure Boot

What is Secure Boot?

Secure boot is a process where the device verifies the integrity and authenticity of its firmware every time it starts up. If the firmware has been tampered with, the device refuses to boot.

How Secure Boot Works

The basic principle relies on cryptographic signatures:

Build Time (at your development machine):
  1. Compile firmware → firmware.bin
  2. Hash the firmware → SHA-256 hash
  3. Sign the hash with your PRIVATE key → signature
  4. Combine: firmware.bin + signature → signed_firmware.bin

Boot Time (on the device):
  1. Bootloader reads firmware from flash
  2. Bootloader calculates SHA-256 hash of the firmware
  3. Bootloader verifies signature using PUBLIC key (stored in device)
  4. If signature is valid → boot the firmware
  5. If signature is INVALID → refuse to boot (stay in bootloader)

  Power On
     |
  [ROM Bootloader]  (immutable, burned into chip)
     |
     v
  Verify Stage 1 bootloader signature
     |
     +--- FAIL → Stop (device does not boot)
     |
     +--- PASS
            |
            v
     [Stage 1 Bootloader]
            |
            v
     Verify application firmware signature
            |
            +--- FAIL → Stay in bootloader (wait for valid update)
            |
            +--- PASS → Boot application firmware

This is called a chain of trust. Each stage verifies the next before handing over control.

Secure Boot on ESP32

The ESP32 has built-in secure boot support:

# Enable secure boot in ESP-IDF menuconfig
idf.py menuconfig
# → Security features → Enable hardware Secure Boot in bootloader

# Generate signing key (keep this secret!)
espsecure.py generate_signing_key secure_boot_signing_key.pem

# Build with secure boot enabled
idf.py build

# Flash (this burns the key hash into eFuse - IRREVERSIBLE)
idf.py flash

Once enabled on ESP32:

• The signing key hash is burned into one-time-programmable eFuses
• Every boot verifies the bootloader and application signatures
• Unsigned or incorrectly signed firmware will not run
• This cannot be disabled once enabled (by design)

Secure Boot on STM32

STM32 microcontrollers (especially STM32L4, STM32H7, STM32U5) support secure boot through:

• SBSFU (Secure Boot and Secure Firmware Update) – ST’s reference implementation
• TrustZone (on Cortex-M33/M55) – hardware isolation between secure and non-secure code
• Read-out protection (RDP) – prevents reading flash via debug interface

Secure Firmware Updates (OTA)

Why OTA Updates?

Over-the-Air (OTA) updates let you fix bugs, patch security vulnerabilities, and add features to deployed devices without physical access. But OTA also introduces risk: if an attacker can push a malicious update, they control the device.

Secure OTA Architecture

  Developer                    Cloud Server              Device
     |                             |                       |
  1. Build firmware                |                       |
  2. Sign with private key         |                       |
  3. Upload signed firmware ------>|                       |
     |                             |                       |
     |                          4. Device checks for update|
     |                             ||
     |                             |                       |
     |                             |  6. Verify signature   |
     |                             |  7. Verify version     |
     |                             |  8. Write to flash     |
     |                             |  9. Verify written data|
     |                             | 10. Reboot into new FW |

Key Security Measures for OTA

1. Sign every firmware image

# Sign firmware with your private key
openssl dgst -sha256 -sign private_key.pem -out firmware.sig firmware.bin

# On the device, verify with the public key before installing

2. Use HTTPS/TLS for transportAlways download firmware over an encrypted connection to prevent man-in-the-middle attacks that could swap the firmware in transit.3. Version checkingThe device should only accept firmware with a version number higher than the current one. This prevents rollback attacks where an attacker forces the device to install an older, vulnerable version.

if (new_version <= current_version) {
    reject_update("Rollback not allowed");
    return;
}

4. A/B partition schemeStore two firmware images on the device. Update the inactive partition, verify it, then switch:

Flash Layout:
  [Bootloader] [Partition A (active)] [Partition B (inactive)] [Config]

Update Process:
  1. Download new firmware to Partition B
  2. Verify signature and integrity of Partition B
  3. Mark Partition B as "pending verification"
  4. Reboot into Partition B
  5. If Partition B works → mark as active
  6. If Partition B fails → bootloader reverts to Partition A

This ensures the device always has a known-good firmware to fall back to.5. Integrity verification after writingAfter writing firmware to flash, read it back and verify the hash matches. Flash write errors can corrupt the image silently.

Flash Encryption

Even with secure boot, an attacker with physical access could read the flash chip and reverse-engineer your firmware. Flash encryption encrypts the contents of the flash memory so that even if someone reads the raw flash, they see only encrypted data.The ESP32 supports flash encryption:

# Enable in menuconfig
# → Security features → Enable flash encryption on boot

# The encryption key is stored in eFuses (not readable by software)
# Flash contents are encrypted/decrypted transparently by hardware

Practical Security Checklist

1. Enable secure boot on production devices
2. Sign all firmware with a private key stored securely (not in your repository)
3. Use HTTPS for all OTA downloads
4. Implement version checking to prevent rollback attacks
5. Use A/B partitions for safe updates with fallback
6. Enable flash encryption if physical access is a threat
7. Disable debug interfaces (JTAG/SWD) on production devices
8. Protect your signing key as if it were a master password (use HSM for production)
9. Log update attempts to detect attack patterns
10. Test the update failure path to ensure devices always recover

Summary

Secure boot and secure firmware updates form the foundation of embedded device security. Secure boot ensures only authentic firmware runs on the device using cryptographic signatures and a chain of trust. Secure OTA updates ensure that field-deployed devices can be safely patched without risk of malicious firmware injection. Together with flash encryption and anti-rollback protection, these techniques protect your devices from the most common firmware-level attacks. Every connected embedded product shipping today should implement these measures.