Course contentsShow
← Embedded Systems & Computer Architecture
Lesson 478 of 9366. Embedded Software Construction and ToolchainsFree lesson

Integrating Digital Signatures for Secure Updates

Learners will implement cryptographic signature verification to ensure only authorized firmware images are accepted by the bootloader during updates.

In this lesson, you will learn how to verify digital signatures on a firmware image to ensure that only authenticated code can be executed by your bootloader.

Beyond Simple Checksums

While CRCs and checksums are excellent for detecting accidental data corruption during a firmware update, they offer zero protection against malicious actors. A checksum can be easily recalculated if an attacker modifies the binary. Digital signatures solve this by using asymmetric cryptography: the developer signs the firmware with a private key, and the device verifies the signature using a corresponding public key embedded in its read-only memory.

The Verification Workflow

Before jumping to the new firmware, your bootloader must perform a cryptographic check. This typically involves two inputs: the firmware binary and its associated signature header.

  1. Hashing: The bootloader calculates a cryptographic hash (like SHA-256) of the firmware image in flash.
  2. Signature Decoding: The bootloader uses the stored public key to decrypt the digital signature attached to the image, retrieving the "original" hash generated by your build server.
  3. Comparison: If the calculated hash matches the decrypted hash, the image is authentic and authorized to run.

Implementation Concept

In a practical embedded environment, you might use a lightweight library (like mbedTLS or tinycrypt) to perform these operations. Your bootloader’s validation logic will look something like this:

// Verify the image before allowing the jump to application
if (verify_signature(firmware_base_addr, firmware_size, public_key) == SUCCESS) {
    jump_to_app(APP_START_ADDRESS);
} else {
    // Keep the old, safe image or enter recovery mode
    boot_recovery_image();
}

The public key must be placed in a write-protected area of your flash memory (or an OTP—One-Time Programmable—register) during manufacturing. If an attacker tries to swap the public key to match their own malicious firmware, the physical protection on that memory region will prevent the overwrite, effectively locking the device to your authorized updates.

Key Takeaway: Digital signatures transition your firmware security from "error detection" to "origin authentication," ensuring the device only executes code authorized by your private signing key.