HardFault

Securing OTA Firmware Updates — Encryption, Signatures, and Real-World Protections

An OTA update mechanism without security is a huge attack surface.

In this episode, we dive deep into how modern BLE-based devices — from wearables to smart speakers — protect firmware updates using encryption and digital signatures. We’ll also look at real-world implementation patterns, and how you can build secure OTA systems using chips like STM32WB, nRF52, and ESP32.

Why Secure OTA Matters

Once deployed, your device is in the wild — exposed to potential attackers who may:

• Inject malicious firmware
• Reverse-engineer sensitive logic
• Modify the firmware to bypass licensing or restrictions

This is why most production-grade devices:

• Encrypt their firmware (to protect IP)
• Digitally sign the firmware (to verify authenticity)
• Secure the boot process (to prevent booting modified images)

Security Goals of OTA

Symmetric Encryption in OTA

Symmetric encryption (same key for encrypt/decrypt) is fast and light for low-power BLE SoCs.

Common Algorithm:

• AES-128 / AES-256 in CBC or CTR mode

How it’s used:

• Firmware is encrypted before OTA transfer.
• Device holds the secret key (stored in secure flash or OTP).
• Image is decrypted in real-time before writing to flash or before boot.

Example:

• Amazon Echo Buds use AES to encrypt OTA images sent over BLE.
• Custom STM32WB implementations often encrypt firmware using AES-CBC and store the key in read-protected flash.

uint8_t firmware_data_encrypted[128];
aes_decrypt_cbc(firmware_data_encrypted, aes_key, iv, decrypted_output);

Asymmetric Cryptography: Digital Signatures

To ensure only trusted firmware is installed, devices use digital signatures.

ECC vs RSA

• ECC (e.g., secp256r1): Smaller, faster, and better for constrained devices
• RSA-2048: More common in older systems, larger footprint

How it works:

1. Firmware hash is generated (SHA-256).
2. Hash is signed with private key (only known to manufacturer).
3. Device verifies the signature using public key (burned into bootloader or secure memory).

Code Concept:

bool verify_signature(uint8_t* data, uint32_t len, uint8_t* signature, ecc_public_key_t* key) {
    uint8_t hash[32];
    sha256(data, len, hash);
    return ecc_verify(hash, signature, key);
}

Example:

• Fitbit devices verify signatures during boot using ECC.
• Nordic nRF52 Secure DFU stores ECC public key in flash (often protected via UICR).
• STM32WB with SBSFU (Secure Boot + Secure Firmware Update) uses bootloader-stored public key to verify RSA/ECC-signed firmware.

Secure Boot

OTA update alone isn’t enough — your bootloader must validate the firmware at each boot.

Secure Boot ensures:

• Only verified firmware is executed
• Tampered firmware is rejected

Secure bootloaders:

• Check image hash and signature
• Enforce read/write protections
• Disable debugging interfaces post-deployment

Examples:

• STM32WB with SBSFU: Secure Bootloader with image verification and rollback protection
• ESP32 with Secure Boot v2: RSA-2048 signature check + flash encryption
• Nordic nRF52840: Secure boot via MCUboot or built-in DFU with signature verification

OTA Flow with Security (BLE Device)

Here’s a secure OTA flow in steps:

1. App downloads encrypted + signed firmware from cloud
2. Sends it over BLE in packets
3. Device:
   • Decrypts each chunk (AES)
   • Verifies hash at end (SHA256)
   • Verifies signature (ECC or RSA)
4. Boot flag is set if valid
5. On reboot, bootloader re-verifies and boots the new image

Best Practices

Real-World Security Profiles

Open-Source Libraries & Tools

• MCUBoot (https://github.com/mcu-tools/mcuboot)
  Secure bootloader with signature + rollback + encryption support
• TinyCrypt
  ECC, AES, and SHA implementations for resource-constrained MCUs
• STM32 SBSFU (X-CUBE-SBSFU)
  ST’s secure bootloader framework with RSA/ECC and image integrity
• ESP-IDF Secure Boot & Flash Encryption
  Espressif’s toolchain for securing ESP32-based firmware