Multi-Party Firmware Signing for Projects with Shared Release Authority
In many embedded products, firmware updates are authenticated using a single private key held by one developer or system. If that key is compromised or misused—whether through a tampered build environment, unauthorized HSM access, a stolen laptop, an internal mistake, or a rogue maintainer—the device fleet has no mechanism to enforce additional approval. A single key becomes a single point of failure for every device in the field.
This talk presents a practical quorum-based (M-of-N) signing scheme that distributes trust across multiple maintainers, systems, or roles. Instead of relying on one signature, the bootloader verifies multiple independent signatures before accepting an update. The design targets general-purpose microcontrollers and does not depend on any specialized hardware modules.
To demonstrate feasibility, a reference open-source bootloader implementation is presented, validated on an STM32F4 platform using ECDSA/SHA-256 algorithms and a microSD-based update flow, highlighting the constraints typical of embedded targets such as limited flash and RAM.
Although SUIT and TUF are widely adopted standards, certain environments, like constrained MCUs or devices updated through offline or removable media methods, can benefit from a more lightweight approach. This talk presents such a model built around simple, explicit checks and balances. It also covers several operational aspects, including:
- Basics of signing ceremonies and safe key rotation.
- Key hierarchies (e.g., vendor vs. maintainer keys).
- Rollback protection and boot time optimization.
- TOCTOU (Time-of-Check to Time-of-Use) considerations when validating manifests.
Attendees will gain a clear understanding of how quorum-based signing can be integrated into existing bootloaders and update designs, what constraints apply on embedded targets, and which operational practices help keep the firmware update process trustworthy over the device’s lifetime.
What this presentation is about and why it matters
What happens when one firmware signing key becomes too much of a single point of failure, and how can the device itself enforce shared release authority? Mike Tolkachev approaches that problem as a practical embedded security case study, grounded in bootloaders, update formats, and team workflows for distributed maintainers. He walks through quorum signing, key roles, update verification, and recovery behavior, with attention to what the device can actually trust at runtime. This will be useful if you design secure update paths, maintain a shared codebase, or need a release process that survives both technical and organizational failure.
Who will benefit the most from this presentation
- Firmware engineers who own bootloader or update logic and need stronger release controls
- Embedded security engineers working on authenticity, rollback resistance, or trust anchors
- Open source maintainers coordinating releases across multiple contributors
- Product or release engineers who need a process that still works when one signer is unavailable
- Teams shipping security-critical devices where update integrity must be enforced on-device
What you need to know
A basic familiarity with firmware update flows and signing will help. The talk also uses a few security and bootloader concepts:
- Bootloaders and firmware update images
- Digital signatures and public/private key pairs
- Rollback protection and version tracking
- CRC-based integrity checks
- Time-of-check to time-of-use concerns
Glossary (terms used in this talk)
- CRC (Cyclic Redundancy Check): An error-detection method that computes a check value from a block of data to detect accidental corruption.
- Quorum signing: A release model where multiple independent signatures are required before an update is accepted. The threshold can be set as an n-of-m policy, so no single key can authorize a release alone.
- Release authority: The power to approve and distribute firmware updates. In shared projects, this authority can be split across multiple people or roles instead of being concentrated in one maintainer or system.
- Dual image update: A firmware update strategy that keeps two copies of critical software, so one can remain available if the other is damaged or a write is interrupted. This reduces the chance of bricking a device during update handling.
- time-of-check-to-time-of-use (TOCTOU): A class of race-condition problems where a system checks a property of data at one time but later uses the data and the data may have changed in between, invalidating the earlier check.
- anti-rollback (rollback protection): A mechanism that prevents a device from accepting firmware versions older than the highest version it has previously trusted, preventing attackers from reverting a device to a vulnerable firmware even if that older firmware is still correctly signed.
- release ceremony: A structured release workflow where artifacts are frozen, built deterministically, independently signed by maintainers, and then assembled into a final bundle; designed to separate and enforce trust without sharing private keys.
Toolbox (mentioned in this talk)
- GitHub: A web-based platform for hosting Git repositories and collaborating on software development.
- Docker: A containerization platform used to package a development environment and make it repeatable across machines. It is commonly used to keep local development and CI environments aligned.
- Spectre bootloader: An open source bootloader used as the reference implementation discussed in the session. Bootloaders like this are responsible for validating and selecting firmware images before execution.
Final thoughts
Practical and security-focused, this talk gives you a design lens for thinking about firmware release authority as a device-enforced property, not just a team policy. The value is in the way it connects cryptographic verification, bootloader behavior, and release workflow into one coherent mental model. Firmware engineers, secure update designers, and open source maintainers will come away with a sharper vocabulary for shared trust. It is a talk about making releases harder to misuse, without making them harder to run.
This overview is AI-generated from the session transcript. Spot an issue? Let us know.
Thanks, good questions.
In the example implementation, the bootloader can enable write protection for its own sectors and the application firmware if configured to do so. When one of the bootloader copies needs to be replaced, this protection is temporarily removed as part of the update process.
That particular bootloader also manages read protection for the sector containing the application's secrets. But this is an application-defined feature and may not be needed in every case. The public keys embedded inside the bootloader itself are not secret, so there is no real need to protect them from being read.
Regarding two maintainer keys: the capabilities these maintainers have depend on the actual multi-signature scheme. If it is "1 of 2", then either maintainer can release new firmware. The same applies to a new bootloader if a flat key hierarchy is used. If it is "2 of 2", then both maintainers must sign the upgrade bundle for the bootloader to consider it valid.
To clarify, these keys are used specifically to sign firmware and bootloader releases. They do not directly control access to flash memory.
To clarify, these keys are used specifically to sign
firmware and bootloader releases. They do not directly control access to flash memory.
Exactly my point. So it requires that the enforcer, here the bootloader, can prevent malicious firmware from messing with the flash, like overwriting keys and/or a bootloader copy. Or the two maintainer keys just obsoleted the vendor keys.
This is a valid concern. In that specific example for the STM32F4 platform, there is no technical capability to enforce flash write protection in a way that can be controlled only by the bootloader. So yes, in this setup the risk of privilege escalation from application firmware exists.
In other words, if the application firmware is malicious and has enough privileges to reconfigure flash protection, then the bootloader cannot fully defend itself only by checking signatures before booting the firmware. This can be enforced better on platforms that provide some kind of TEE or other hardware-enforced separation or register locking, where only the trusted boot/update component can control specific flash regions.
In our setup, the assumption was that both the vendor- and maintainer-key owners are interested in keeping the whole solution secure. They are not expected to fight or compete against each other. The maintainer keys were meant to reduce release bottlenecks and bus factor, not to create an adversarial boundary against the vendor.
But the risk of a rogue maintainer still exists, and in this particular setup it is not fully avoidable by hardware. It can only be mitigated by the quorum scheme. For example, with "2 of 3" or "3 of 5", one malicious maintainer cannot release malicious firmware alone. The other members of the quorum are expected to review what is being released and prevent such action.
So I would say the protection this scheme gives is against single-key compromise and single-person release decisions, but it does not magically create a sandbox around the application code. For that, hardware support is needed indeed.
Is the bootloader protected by HW?
I wonder if two maintainer keys can release a firmware, what will stop that firmware from reading and writing the flash, including the bootloader and keys?