Once your STM32 devices are in the field, every firmware update becomes a security decision: who is allowed to run code on this hardware, and what happens if an update is interrupted or malicious? A secure bootloader architecture adds signatures, anti-replay and clear recovery paths on top of your existing update flow.
What this article focuses on
- Designing a secure boot path for STM32 (not a specific library or vendor tool).
- Using signatures and key management to ensure only trusted firmware runs.
- Preventing replay of old images and defining clean recovery paths.
We assume you already have a basic bootloader or update mechanism. If you are still defining your overall firmware structure and timing, you may want to read this together with your firmware architecture and real-time optimisation plans.
Step 1 – Start with a concrete threat model
“Secure bootloader” can mean anything from “basic sanity checks” to “full-blown hardened system”. To avoid over-engineering in the wrong places, write down what you are actually defending against.
- Accidental corruption: power loss during update, flash wear, noise on interfaces.
- Unintentional misuse: wrong firmware loaded for the hardware variant.
- Attacks: cloned hardware, modified firmware, attempts to bypass safety limits.
- IP protection: preventing easy extraction or reuse of your firmware.
For each category, decide whether your priority is integrity (no unauthorised code), availability (device always recovers) or confidentiality (protecting IP) – or a mix.
Step 2 – Establish a root of trust on STM32
A root of trust is the part of the system you decide to trust unconditionally. On STM32, this is typically:
- A hardware ROM bootloader or immutable boot path, plus
- A small, carefully reviewed first-stage bootloader in flash.
At minimum, this first stage should:
- Live in a well-protected flash region (write-protected once final).
- Contain the public keys or trust anchors for signature verification.
- Perform all checks required before handing control to any application image.
Keep this root-of-trust code as small and boring as possible. Complexity belongs in updatable areas, not here.
Step 3 – Design your signature and key management scheme
Signatures guarantee that only firmware produced by you (or explicitly authorised parties) will run on the device.
- Private keys live on your build and release infrastructure, never on the device.
- Public keys (or their hashes) are stored in the STM32 as trust anchors.
- Every firmware image carries a header with version, length and signature over the relevant data.
Decide on:
- The algorithm (e.g. ECC vs RSA) and expected lifetime of the keys.
- How you will roll keys if a private key is ever compromised.
- Whether different product families or customers will use different signing keys.
Many teams document this alongside their overall firmware and system design as part of engineering & firmware consulting.
Step 4 – Add anti-replay rules: when are “old but valid” images allowed?
Signatures alone do not stop an attacker from installing an old, vulnerable version that is still correctly signed. Anti-replay protections address exactly this.
- Give every image a monotonic version or build number.
- Store a minimum allowed version or a monotonic counter in protected flash.
- Reject any update image that is both signed and below the allowed version threshold.
You may still want a way to perform controlled rollbacks (for example after a bad release), but then:
- Use a different mechanism (service tool, special signed “rollback authorisation”).
- Log and track such events clearly in your backend and service process.
Step 5 – Define a secure update and verification flow
The bootloader’s job is not to handle every detail of your transport (UART, USB, BLE, app), but to define a small set of states any update must go through. A common pattern:
- Download the new image to a dedicated region (often a second slot).
- Verify integrity (CRC) and signature before marking it as “candidate”.
- Optionally perform offline compatibility checks (hardware ID, config version).
- Mark the image as “pending boot” and perform an atomic state change in metadata.
- On next reset, bootloader decides which image to start based on those flags.
If you already have a dual-slot and rollback design, secure boot logic hooks directly into it: only signed and non-replayed images ever reach “pending” or “confirmed” state.
Step 6 – Plan clear recovery paths
Secure boot is not only about saying “no”. It also needs to answer: “what happens if something goes wrong?”. Typical recovery paths include:
- A fallback image in a second slot that is always bootable.
- A safe mode with limited functionality but robust update capability.
- A controlled manufacturing / re-provisioning mode for devices that are truly broken.
For STM32-based drive systems, recovery concepts must align with safety and protection logic in the motor control stack and the rest of the product – not just with the bootloader in isolation. That is why we usually treat it together with drive systems and protection & fault handling.
Step 7 – Treat secure boot as a testable feature, not a slide in a deck
Once the architecture is in place, you want evidence that it works under real-world conditions. At minimum, test:
- Unsigned or incorrectly signed images are rejected and never executed.
- Old but still correctly signed images are rejected when below your minimum version.
- Power loss at critical points (during download, metadata update, first boot) leads to a safe state.
- Recovery paths behave as specified – with clear logs or indicators.
For larger programmes, it is worth capturing these as explicit test cases in your system-level validation, alongside FOC tuning, protection tests and mechanical robustness.
Threats and where you handle them
| Threat | Mitigation | Implemented in |
|---|---|---|
| Modified firmware image | Digital signatures and integrity checks before boot | Bootloader + release process |
| Replay of old, vulnerable firmware | Version checks, minimum allowed version, monotonic counters | Bootloader + backend policy |
| Power loss during update | Dual-slot or staged update, atomic metadata transitions | Bootloader architecture |
| Accidental wrong firmware for hardware variant | Hardware ID / compatibility fields in image header | Bootloader + build system |
| Complete brick of device | Fallback image, safe mode, manufacturing recovery path | Bootloader + production process |
FAQ: Secure bootloaders on STM32
Is secure boot only relevant for connected / IoT devices?
No. Even “offline” devices like tools, drives or lab equipment are often updated in the field via USB, service tools or mobile apps. Once firmware can be updated, someone can try to load their own code – secure boot defines where you draw the line.
Do signatures always require big, expensive MCUs?
Cryptography has a cost, but modern STM32 devices are usually capable of running signature checks if the architecture and timing are planned accordingly. The key is to keep the bootloader focused and avoid unnecessary complexity in the critical path.
How does this interact with FOC and real-time motor control?
Secure boot runs before any FOC or control code, so it does not change your control loop timing directly. But it strongly influences how you structure your firmware images, configuration and update flow around the motor control. We usually design them together in STM32 drive projects – see drive systems and STM32 motor control consulting.
What about debug access and factory programming?
Secure boot must be consistent with how you program and debug devices in production and service. Typically this means locking or restricting debug interfaces after provisioning and having a clear, documented process for re-enabling them in controlled environments. The details depend on your production setup and are usually part of broader product development services.
Next steps if you are planning a secure bootloader
If you are in the concept or early implementation phase of a secure bootloader for STM32, it helps to align architecture, cryptography choices and test strategy early – before they harden into difficult constraints.
Typical starting points for collaboration include:
- A short architecture review of your planned boot flow, image format and key management.
- Designing dual-slot / rollback and secure boot together as one coherent concept.
- Defining concrete test cases for failure and attack scenarios.
You can reach us via the contact page or through the overview on engineering & firmware consulting.
0 comments