Mr. Integral
Embedded notes/Building Reliable Systems/Firmware Updates and Security

UNIT 15 · BUILDING RELIABLE SYSTEMS

Firmware Updates and Security

Ship new firmware without bricking the device or trusting strangers.

6 lessons24 guided experiments55 min full read

A device in the field will need new firmware: a bug fix, a new feature, a security patch. Updating it means replacing the program that is running, possibly over an unreliable link, possibly with the power failing halfway, and possibly with someone else trying to slip in firmware of their own. This unit is about doing that safely.

Start with lesson 1 →
∫ MR-INTEGRAL · 15 UNITS · 90 LESSONS016 lessonsPinssignals and circuits036 lessonsCPU coreand memory026 lessonsRegisters096 lessonsInterruptcontroller136 lessonsSchedulertasks and deadlines046 lessonsFlash imagebuilt by the toolchain156 lessonsSecure bootupdates and keys056 lessonsBoot ROMand reset066 lessonsDebug portprobe, trace146 lessonsPowersleep, brown-out126 lessonsDMA076 lessonsGPIOpins in and out086 lessonsClocksand timers106 lessonsUART · SPI · I²Cserial links116 lessonsADC · DACanalog
∫ MR-INTEGRAL · 15 UNITS01Pins · signals and circuits036 lessonsCPU coreand memory026 lessonsRegistersC close to the metal096 lessonsInterruptcontroller136 lessonsSchedulertasks and deadlines046 lessonsFlash imagebuilt by the toolchain156 lessonsSecure bootupdates and keys056 lessonsBoot ROMand reset066 lessonsDebug portprobe, trace146 lessonsPowersleep, brown-out126 lessonsDMA076 lessonsGPIOpins in and out086 lessonsClocksand timers106 lessonsUART · SPI · I²Cserial links116 lessonsADC · DACanalog

The unit in six ideas

  1. 1A bootloader that runs at every reset and is never replaced during an update makes field updates possible; the application moves to a slot of its own.
  2. 2A CRC catches random corruption well, but it is public and linear: anyone who changes an image can fix its CRC.
  3. 3Download into the secondary slot first; the running image is untouched until the bootloader installs the new one.
  4. 4Secure boot is a chain: each stage verifies the next, and the chain rests on an immutable first stage and root-of-trust public key.
  5. 5Assume anything stored in a device can be extracted; count how many devices one extraction exposes.
  6. 6MCUboot compares major, minor and revision in order; the build number counts only with MCUBOOT_VERSION_CMP_USE_BUILD_NUMBER.

Lessons

  1. LESSON 01 · 4 EXPERIMENTS · 10 MIN

    Application Images and Bootloaders

    What has to be on the device from the day it ships so that new firmware can be installed, and so that a failed installation can still be recovered?

  2. LESSON 02 · 4 EXPERIMENTS · 9 MIN

    Image Integrity and Authenticity

    Which checks answer which question, and what must stay secret for the answer to hold?

  3. LESSON 03 · 4 EXPERIMENTS · 9 MIN

    Safe Updates, Rollback, and Recovery

    And if the new image boots but crashes a second later, does it stay crashed forever?

  4. LESSON 04 · 4 EXPERIMENTS · 9 MIN

    Secure Boot and the Root of Trust

    Where does the chain of “who checks whom” have to end for any of it to mean something?

  5. LESSON 05 · 4 EXPERIMENTS · 9 MIN

    Protecting Keys, Debug Ports, and Device Identity

    So where do the keys actually live, who can read them, and what does an attacker gain by buying one of your devices, opening it and extracting everything inside?

  6. LESSON 06 · 4 EXPERIMENTS · 9 MIN

    Versioning, Diagnostics, and Field Maintenance

    And when you ship the next release, how do you find out it is failing before it reaches everyone?