Secure BLE DFU: Signed Firmware Updates Over-the-Air

<\/script>\n
'; }, get iframeSnippet() { const domain = '{ SITE_DOMAIN }'; const type = '{ embed_type }'; const slug = '{ embed_slug }'; return ''; }, get activeSnippet() { return this.method === 'script' ? this.scriptSnippet : this.iframeSnippet; }, copySnippet() { navigator.clipboard.writeText(this.activeSnippet).then(() => { this.copied = true; setTimeout(() => { this.copied = false; }, 2000); }); } }" @keydown.escape.window="open = false" @click.outside="open = false">

Embed This Widget

Theme


      
    

Widget powered by . Free, no account required.

Implementing cryptographically signed OTA updates

| 4 min read

Secure BLE DFU: Signed Firmware Updates Over-the-Air

Over-the-Air (OTA) firmware updates are a mandatory capability for any production BLE product. Without OTA updates, deployed devices cannot receive security patches or feature improvements. Without cryptographic signing, OTA updates become an attack vector — an adversary can push malicious firmware to any device within BLE range.

Threat Model

Threat Impact Mitigation
Unsigned firmware accepted Full device compromise ECDSA/Ed25519 signature verification
Downgrade attack Reinstall patched vulnerability Anti-rollback counter in secure storage
MITM during OTA session Firmware injection LESC encrypted BLE connection mandatory
Key extraction from device Sign arbitrary firmware Store private key in secure element (never in flash)
Replay attack Re-apply old firmware image Firmware version > stored version required

Signature Schemes

Algorithm Key Size Signature Size Verification Time (M4) Security Level
ECDSA P-256 32 bytes (public) 64 bytes ~200 ms 128-bit
Ed25519 32 bytes (public) 64 bytes ~15 ms 128-bit
RSA-2048 256 bytes (public) 256 bytes ~800 ms 112-bit
ECDSA P-192 (deprecated) 24 bytes (public) 48 bytes ~150 ms 80-bit (inadequate)

Ed25519 is the recommended choice for embedded targets: faster verification than ECDSA P-256, smaller key/signature sizes, and immune to side-channel attacks from non-constant-time implementations. Nordic's nRF Secure Bootloader and MCUboot both support Ed25519 natively.

Secure Bootloader Architecture

Boot sequence:
  1. CPU reset vector → Secure Bootloader (in protected flash region)
  2. Bootloader verifies Application image:
     a. Read image header (magic, version, size, hash algorithm)
     b. Compute SHA-256 of image body
     c. Verify Ed25519 signature over SHA-256 hash
        using hardcoded public key in bootloader
  3. If valid AND version >= anti-rollback minimum:
     → Jump to application reset vector
  4. If invalid OR version < minimum:
     → Enter recovery mode (advertise DFU service)
     → Accept new firmware via BLE [GATT](/glossary/gatt/) DFU service
     → Verify new image before overwriting

The public key is burned into the bootloader at compile time — never stored in writable flash. Key rotation requires a new bootloader image, itself signed by the previous key (chain of trust).

Anti-Rollback Counter

Anti-rollback prevents an attacker from downgrading firmware to a vulnerable version:

// MCUboot security counter
// In image header:
//   BOOT_IMAGE_HEADER_FLAGS_SEC_CNT — indicates counter present
//   IMAGE_TLV_SEC_CNT — security counter value

// Bootloader logic (MCUboot):
uint32_t min_version = flash_read_security_counter(); // From TrustZone / OTP
if (image_security_counter < min_version) {
    /* Reject — downgrade attempt */
    boot_go_bad();
}
// On successful boot with new counter:
flash_update_security_counter(image_security_counter);
// Counter only ever increments — OTP fuses or eFuse ideal

Nordic's NSIB (Network Secure Immutable Bootloader) uses OTP (one-time programmable) registers to store the minimum counter, making rollback physically impossible after the register is written.

Key Management

Production line setup:
  1. HSM generates Ed25519 keypair
  2. Public key embedded in bootloader binary (hex file)
  3. Bootloader flashed to device (signed itself by HSM root key)
  4. Private key remains in HSM — NEVER on developer workstations

Firmware signing CI/CD:
  1. Build firmware → binary image
  2. CI sends image to signing service (HSM API)
  3. Signing service returns image + signature
  4. DFU package = image + signature + metadata
  5. Package uploaded to CDN / mobile app bundle

Using nRF SDK's imgtool (part of MCUboot): imgtool sign --key ed25519.pem --version 1.2.0 --security-counter 5 app.bin app_signed.bin

BLE DFU Service

The Nordic DFU ATT">gatt-service/" class="glossary-term-link" data-term="GATT service" data-definition="Collection of related BLE characteristics." data-category="GATT & ATT">GATT service (UUID FE59) is the de facto standard, also used by MCUboot with the SMP protocol over BLE. The SMP (Simple Management Protocol) GATT service (UUID 8D53DC1D-1DB7-4CD3-868B-8A527460AA84) provides image upload, hash verification, and reset commands.

OTA sessions must use an encrypted connection — reject DFU requests on unencrypted links. See BLE Vulnerabilities for known DFU attack vectors.

Frequently Asked Questions

Yes, our guides range from beginner introductions to advanced topics. Each guide indicates its difficulty level and prerequisites so you can find the right starting point.