Firmware Signing

01 Why hash-based

The most conservative signature there is.

If a signature has to hold for decades, rest it on the fewest assumptions possible.

LMS and XMSS are stateful hash-based signatures. Their security rests only on the hash function: no lattices, no elliptic curves, no number theory. Grover's algorithm weakens hashes only modestly, and no quantum algorithm is known to break them outright. That is why CNSA 2.0 names LMS and XMSS (NIST SP 800-208, single-tree only) for software and firmware signing.

The scheme is a Merkle tree of one-time keys. Each leaf is a one-time signing key, and the root is the public key that devices trust. A signature is one leaf's one-time signature plus the authentication path up to the root. Verifying it is cheap: a few hundred hash calls. That suits a microcontroller.

The price is state. Each leaf may sign exactly once. Sign twice with the same leaf and an attacker can start forging. NIST SP 800-208 allows these schemes only if key generation and signing happen in a cryptographic module that keeps that state safe. Everything on this page is built around that constraint.

LMSLeighton–Micali, RFC 8554; single-tree for CNSA-bound profiles

XMSSThe second stateful family, RFC 8391; also approved in SP 800-208

02 One signature, end to end

Build, hash, sign one leaf, ship, verify, refuse.

LMS firmware signing01 / 06

01 · BUILD

A firmware image is built in Zone D.

The build runs on the air-gapped signer. The image carries its version, which the device will later compare against its anti-rollback counter.

02 · HASH

The image is reduced to a digest.

The signer signs a SHA-256 digest of the image, never the image itself. The same digest becomes the firmware commitment in the receipt.

03 · SIGN ONE LEAF

The next unused leaf signs, and the counter moves first.

The state counter q advances and is sealed before the signature is released. That leaf is now spent forever. The authentication path ties the signature to the public root registered in R+14.

Single writer: one signer, one state
A corrupted or rolled-back state must be refused

04 · ATTACH + MANIFEST

Signed image + manifest + registry epoch.

The signature (leaf index, one-time signature, authentication path) is attached, with a manifest naming the version and the registry epoch. It leaves Zone D on write-once USB, or as a QR code for small manifests.

05 · DEVICES VERIFY

Devices verify only.

The gateway relays the image and never re-signs it. Each device checks the signature against the registered root, the epoch, and that the version is not older than its counter. No device holds a signing key.

06 · ROLLBACK REFUSED

An older image is refused, even though its signature is valid.

An attacker who replays a genuine but vulnerable older release is stopped by the anti-rollback counter. The refusal is logged on the device and becomes evidence.

A one-time key used twice is no longer a signature.

03 Why state never lives on a device

State belongs in one place, sealed, with one writer.

The dangerous moments for stateful signatures are ordinary operations: a backup restored to an earlier counter, a virtual machine snapshot rolled back, a cloned signer, two build servers signing in parallel. Each can reuse a leaf without anyone noticing.

So the rules are absolute. Signer state is held only in the signer zone, sealed and single-writer, with a counter that only moves forward. Field devices, gateways and build pipelines never hold signer state. They only verify.

In production, the state belongs inside a hardware module that manages it itself. No major cloud key-management service offers LMS or XMSS today. Firmware signing is therefore designed to run in an HSM that holds state in-module, and R-Series' registry acts as the anchor for the state attestations the HSM issues.

Honesty line used in every demo. The bench signer (Tier 0.5: an air-gapped laptop with a USB HSM that wraps the state key) is "SP 800-208-style, not validated". The USB HSM is not an LMS signer itself. The validated path is a network or cloud HSM that holds LMS/XMSS state in-module (Tier 1).

04 The signing path

Six design decisions.

ONE KEY PER BATCH

Small blast radius

Each firmware batch gets its own LMS key. When the batch is done, the key is retired and archived. A problem with one key never touches another batch.

AIR-GAPPED SIGNER

No network, ever

A dedicated laptop with wireless hardware removed, kept locked away when not in use. Data crosses the gap only by write-once USB or QR code.

IMAGE + MANIFEST + EPOCH

Three things travel together

The signed image, a manifest (version, digest, batch) and the registry epoch. The device needs all three to accept an update.

VERIFY-ONLY DEVICES

No signing key on a device

Devices hold the public root and an anti-rollback counter, nothing more. Devices verify with a vetted third-party LMS verifier.

ANTI-ROLLBACK

Versions only move forward

A device refuses a bad signature, an older version and a wrong registry epoch. All three refusals are part of the gate, with device logs as evidence.

THROUGH THE ENGINE

The engine boundary applies to signing

The workflow runs through the engine's custody path, so there is one LMS capability. That capability serves PQC migration, code signing and OT firmware.

05 Receipts for every signing event

The signer's history, written as evidence.

Signing events become R-Series receipts, so ten years later anyone can check which key signed what, under which epoch.

06 Profiles

Enterprise default, and a CNSA option for defence.

Firmware is signed with hash-based signatures (LMS, XMSS) under NIST SP 800-208. A CNSA 2.0 profile is selectable for defence and national-security programmes, built on the NIST post-quantum standards (FIPS 203/204/205).

In development

07 Status

Where firmware signing stands.

In development. The signing workflow is designed; signing and device verification are proved on the bench before any customer device sees them.

In development

08 Questions

From firmware and product-security teams.

Why not use ML-DSA for firmware?

You can, and the CNSA profile allows ML-DSA-87. Hash-based signatures add a second, independent assumption that rests on hashes alone, and their verification is simple enough for small devices. R-Series treats lattice plus hash as an explicit design goal.

What happens when a tree runs out of leaves?

The batch key is retired and archived, and a new key is generated, registered in a new epoch and receipted. One key per batch keeps trees small and retirement routine.

Can the gateway sign firmware for devices that cannot verify?

No. The gateway relays firmware and never re-signs it. A device that cannot verify an update is handled as a legacy device and fenced behind the gateway.

Is your firmware signing SP 800-208 validated?

No. The bench signer is "SP 800-208-style, not validated". Validation comes only from a hardware module that holds state in-module, and from an independent assessment. Neither is claimed.

How does a device know the signing key is still trusted?

The manifest names a registry epoch. The device checks it against the epoch it trusts, and the R+14 registry records when each root was active and when it was retired.

Do you need the cloud to verify an update?

No. Devices verify locally, and the Zone C verifier checks signing receipts offline. Anchoring is used for civil demonstrations only.

Signed in an air gap. Checked on the plant floor.

Firmware signing is one of eight workstreams in the OT/IoT line.

The OT/IoT programme

In development — talk to us about a design partnership.

Want the details for your sector? Book a briefing — we share the full design and a live demo in a private session.

Sign firmware that must outlast the algorithm.