ESP32 Hardware Security Mechanisms: Secure Boot and Firmware Encryption

The ESP32 series chips (such as ESP32-C6, ESP32-S2, etc.) ensure the full link security of devices from boot to operation through **Secure Boot** and **Flash Encryption** hardware security mechanisms. Below are the core mechanisms and implementation details:

1. Secure Boot

1. Core Functions

• Prevention of Unauthorized Firmware Execution by verifying the integrity of the firmware through digital signatures, ensuring that only trusted code runs.
• Layered Verification starts from the ROM Bootloader, verifying the signatures of the Bootloader, partition table, and application layer by layer.

2. Technical Implementation

• Signature Algorithms support RSA-2048/3072 and ECDSA (for example, ESP32-C6 supports RSA-3072 and ECC-P256).
• Key Storage The private key is generated and securely stored by the developer, while the public key is burned into the chip’s eFuse or secure storage area.

3. Secure Boot Process

1. ROM Bootloader Startup:

• Initial code is loaded from read-only memory (ROM), verifying the digital signature of the Bootloader.
• If verification fails, the device cannot boot.

Bootloader Verifies Partition Table and Application:

• Uses the public key to verify the signatures of the partition table and application.
• If verification passes, the application is loaded and executed; otherwise, the boot fails.

4. Configuration and Tools

• Generate Signing Key

# Generate RSA-3072 private key
espsecure.py generate_signing_key --version 2 --scheme rsa3072 secure_boot_signing_key.pem

• Sign Firmware

# Sign Bootloader
espsecure.py sign_data --keyfile secure_boot_signing_key.pem --output bootloader_signed.bin bootloader.bin

• Enable Secure Boot
• Enable the <span>Secure Boot</span> option in <span>menuconfig</span> and specify the signing key path.

5. Security Advantages

• Tamper Resistance Any unsigned or tampered firmware cannot run.
• Anti-Debugging The JTAG debugging interface can be disabled (locked via eFuse).

2. Flash Encryption

1. Core Functions

• Protect Stored Data Encrypts code and sensitive data (such as NVS storage) in Flash to prevent physical attacks (such as reading Flash chips).
• Dynamic Decryption Automatically decrypts data during device operation without requiring manual handling by the developer.

2. Technical Implementation

• Encryption Algorithms AES-128/256-XTS (hardware accelerated), supports encryption of the entire Flash or specific areas.
• Key Management
• Device Unique Key The key generated during chip production is stored in eFuse.
• User-Defined Key Can be generated and burned into eFuse using tools.

3. Encryption Process

1. Generate Encryption Key:

   # Generate Flash encryption key
   espsecure.py generate_flash_encryption_key flash_encryption_key.bin
   

2. Burn Key to eFuse:

   espefuse.py --port PORT burn_key 0x50 flash_encryption_key.bin
   

3. Enable Encryption Mode:

• Enable <span>Flash Encryption</span> in <span>menuconfig</span>, selecting the encryption mode (e.g., “Release” mode).

First Boot Encryption:

• On the first boot, the device automatically encrypts the firmware and data in Flash.
• On subsequent boots, data is automatically decrypted for operation.

4. Security Advantages

• Protection Against Physical Attacks Even if accessed via JTAG or direct Flash reading, plaintext data cannot be obtained.
• Dynamic Protection The encryption process is hardware accelerated, ensuring no performance impact.

3. Comprehensive Application Scenarios

Scenario	Secure Boot	Firmware Encryption
Industrial IoT Devices	Ensures firmware has not been tampered with	Protects sensitive configurations and communication keys
Smart Home Devices	Prevents malicious firmware replacement	Encrypts user privacy data (e.g., Wi-Fi passwords)
Medical Devices	Meets compliance requirements (e.g., FDA certification)	Protects patient data and device control logic

4. Configuration Considerations

1. Key Management:

• The private key must be kept strictly confidential, and it is recommended to use a hardware security module (HSM) for generation.
• eFuse burning is irreversible, and testing should be done in advance.

Debugging During Development:

• During testing, Secure Boot and encryption can be temporarily disabled (via <span>UART ROM download mode</span>), but must be enabled before mass production.

OTA Update Security:

• Combine TLS/SSL and HMAC to verify OTA firmware, ensuring the update process is secure.

5. Code Examples

Secure Boot Verification Example (ESP32-S2)

#include "esp_secure_boot.h"

void app_main() {
    esp_secure_boot_signature_t signature;
    esp_secure_boot_key_t public_key;

    // Read and verify firmware signature
    if (esp_secure_boot_read_signature(&signature) == ESP_OK &&
        esp_secure_boot_read_public_key(&public_key) == ESP_OK) {
        if (esp_secure_boot_verify_signature(&public_key, &signature)) {
            printf("Firmware signature verification successful!\n");
        } else {
            printf("Firmware signature is invalid, boot failed!\n");
        }
    }
}

Flash Encryption Enable Configuration (ESP-IDF)

# Generate encryption key
espsecure.py generate_flash_encryption_key key.bin

# Burn key to eFuse
espefuse.py burn_key 0x50 key.bin

# Enable encryption mode (in menuconfig)
idf.py menuconfig
# Path: Security features -> Enable flash encryption on boot

6. Conclusion

The Secure Boot and Flash Encryption mechanisms of the ESP32 build a multi-layer defense system for IoT devices through hardware isolation, encryption acceleration, and key protection. Developers can quickly implement high-security solutions using the APIs and toolchain of the ESP-IDF framework while meeting international security standards such as PSA Certified.

ESP32 Development Board Three Days to Master Microcontrollers Arduino Development Board

STM32 Development Board