Ed25519 signed firmware: why it matters on the factory floor

When Stuxnet surfaced in 2010, industry learned that compromised firmware in a single PLC could physically destroy centrifuges inside a nuclear facility. Six years later, Industroyer cut electrical service in Kyiv for about an hour by manipulating industrial protocols from payloads loaded onto substation equipment. In 2022, Industroyer2 was discovered before causing similar damage. The uncomfortable pattern is the same: the attacker does not need to be on the floor — they only need to get a tampered firmware loaded onto a trusted device.

Digitally signed firmware removes a meaningful share of that attack surface. This post explains what a digital signature is, why Ed25519 has become the practical standard for industrial microcontrollers in 2026, which attacks it prevents, and what to ask your next PLC, HMI or meter vendor before signing the purchase order.

What a digital signature is

The most useful analogy is a notary's stamp. When a document leaves the registry with seal and recognized signature, the receiver can verify without calling the notary that the document was indeed stamped by that specific registry, and that no one altered anything afterwards. The stamp proves authorship; the paper's integrity proves the content is intact.

A digital signature does the same with mathematics instead of ink. The signer holds a key pair: a private key that never leaves their possession, and a public key that can be distributed freely. The private key produces, over a block of bytes (in our case, a firmware image), a short sequence — the signature — that can only have been generated by the holder of that private key. The public key allows any third party to verify the signature without ever seeing the private key.

The field device, when accepting an update, computes a cryptographic hash over the received bytes, uses the public key burned into the bootloader to verify the signature against that hash, and only proceeds if it matches. Any single-bit change in the payload, or any forged signature attempted without the private key, makes verification fail.

This is the opposite of the still-common practice in legacy equipment, where "verification" is just a CRC-32 — designed to detect random transmission errors, not to resist an adversary. CRC is easy to satisfy with adversarial bytes, which is why it does not substitute for a signature.

Why Ed25519, not RSA

RSA dominated digital signatures for three decades, but on modest microcontrollers it pays a steep cost. An RSA-2048 verification on a 64 MHz Cortex-M0+ without hardware acceleration typically takes 30 to 60 milliseconds and requires a large library and careful modular arithmetic to avoid leaking the key through side-channel attacks. The public key is 256 bytes; the signature, another 256.

Ed25519 was published in 2011 by Daniel J. Bernstein and colleagues and standardized in RFC 8032 in 2017. It is a scheme based on an Edwards elliptic curve — a mathematically distinct family from the traditional NIST curves — designed specifically to avoid several practical implementation pitfalls. On a Cortex-M0+, Ed25519 verification in modern libraries (BearSSL, libsodium, monocypher) runs around 1.5 milliseconds. The public key is 32 bytes; the signature, 64 bytes. In a bootloader that must fit in 16 or 32 KB of flash, 1.5 ms versus 30 ms is the difference between an instantaneous boot and a sluggish one.

Security attributes matter too. Ed25519 offers a level equivalent to RSA-3072 — not RSA-2048 — per current NIST and French ANSSI guidance. The scheme is deterministic by construction: the signature is a function of the private key and the message only, with no dependency on a random number generator at signing time. That property eliminates the entire class of attacks that destroyed the PlayStation 3 signing key in 2010, when Sony reused the same random number in two ECDSA signatures. Ed25519 also resists several side-channel attacks by design, thanks to constant-time arithmetic in its reference implementations.

For embedded firmware in 2026, Ed25519 is faster, smaller, equally or more secure, and exposes less implementation surface.

The attacks this defense prevents

Four families of attack stop working when firmware is signed properly.

Malicious replacement. An attacker intercepts the update channel and injects a modified firmware with a backdoor or exfiltration logic. Without a signature, the device accepts whatever arrives as long as CRC matches; with a signature, the bogus image is rejected before flash is written.

Downgrade attack. The attacker captures an older, legitimately signed version with a known public vulnerability (a published CVE) and forces installation onto a device that has already been patched. The signature is valid; the defense requires a persistent anti-rollback counter, discussed below in the layer the AEM-60DC8 implements.

Replay attack. The attacker captures a legitimate update for one product and tries to deliver it to another product or family, hoping the bootloader will accept it because the signature is recognized. The defense is domain separation: the message the Ed25519 scheme actually signs is not the raw image — it is the image prefixed by a unique product-and-family identifier, e.g. LRI:AEM-60DC8:fw:v1 before the hash. A signature valid for that domain will not verify on a device expecting LRI:AEM-90AC:fw:v1.

Build pipeline compromise. The 2020 SolarWinds attack showed that sophisticated adversaries attack the factory that produces the product: they compromise the build server and insert malicious code before the signing step, so the resulting binary is signed by the legitimate key. The defense requires the private key never to touch the automated build server — it lives in hardware (YubiKey FIPS, HSM, smart card), and each signature requires physical presence (PIN, touch) of an accountable engineer. That is the signing ceremony, described below.

How a chain of trust is built

The term chain of trust describes the hierarchy of keys that lets you operate a fleet for years without exposing the most valuable key.

At the top sits a root master key, ideally offline, kept in an HSM or a YubiKey FIPS stored in a safe. That key is used rarely — only to authorize new release signing keys.

One level below sit the release signing keys, with periodic rotation (annually, for example). Each release key has an identifier and a pre-allocated slot in the bootloader. When a key is rotated, the next release switches to the new key; older releases remain verifiable through the previous keys still held in the remaining slots.

The bootloader contains in immutable flash a list of authorized public keys — typically four independent slots. The benefits:

• Non-disruptive rotation. A key got compromised? The next release flows through the next slot. The fleet still in the field keeps booting because its firmware was signed by a key still active in another slot.
• Multi-vendor. Separate slots can let vendor and integrator sign distinct releases under separate domains.
• Defense in depth. A single key compromise does not immediately compromise the fleet: the attacker would still need to defeat the anti-rollback, the domain prefix and the rest of the validation stack.

Domain separation provides cryptographic isolation between products, versions and contexts. It is cheap to implement and eliminates whole classes of cross-version attacks.

Signing ceremony

In a responsible factory, the typical release flow has four to six steps. A simplified example:

1. Reproducible build. The build server (CI) compiles from a Git commit signed with GPG, producing a binary whose hash is documented.
2. Peer review. Another engineer checks the changes and the resulting hash. In teams operating under IEC 62443-4-1, this step is auditable evidence of the secure development process.
3. Transfer to the key operator. The binary is transferred over an authenticated channel to the notebook of the engineer accountable for signing — not to a robot.
4. Hardware signing. The engineer plugs in the YubiKey, runs the signing tool, enters PIN and touches the sensor. The private key never appears in computer memory.
5. Packaging and seal. The binary, the signature, the anti-rollback level and the domain are packaged into the release envelope; the artifact is archived and its hash recorded in a release log.
6. Controlled deployment. The release is made available to an internal pilot before broad rollout. The distribution channel itself can be insecure — the bootloader will verify.

This is the concrete separation between whoever writes code and whoever authorizes it to run in the field. In regulated environments, it is also an audit trail.

How the AEM-60DC8 implements this

The AEM-60DC8 firmware v1.03 — LRI's industrial DC monitoring platform — adopts Ed25519 (RFC 8032) as the cryptographic layer of its update channel. The relevant choices for auditors and integrators:

• Master key off the build computer. The release private key lives in a YubiKey FIPS; each signature requires PIN and physical touch.
• Four public-key slots in the bootloader. Rotation without bricking the fleet; old keys removed in future releases according to policy.
• Own domain prefix at the start of the signed message.
• Nine-layer boot validation. Before handing control to the application firmware, the bootloader runs magic word, header version, header CRC-32, hardware ID, declared length, payload CRC-32, vector table plausibility, end seal and finally the Ed25519 verification. A failure at any layer returns the device to update mode, never to a compromised operational state.
• Persistent anti-rollback in MCU TAMP registers (STM32 backup domain) with a user-replaceable CR2032 lithium battery.
• Anti-brick by construction. The bootloader lives in a flash region the Modbus update channel never writes. An interrupted update leaves the device waiting for a retry over the same Modbus RTU bus.

The project takes IEC 62443-4-2 SL2 as its cybersecurity reference, in progress. Formal certification is under way; this post does not claim completed certification, and LRI Engineering will publish the formal status when issued by the certification body.

Checklist to ask your PLC/HMI vendor

Before signing the purchase order for your next PLC, supervisor or gateway, take these eight questions:

1. Is the firmware digitally signed? Which algorithm and key size? Acceptable: Ed25519, RSA-3072+, ECDSA-P256+. Unacceptable: "CRC" or "checksum".
2. Does the private signing key live in hardware (HSM/YubiKey) or on the build server? Hardware is the correct default.
3. Is there a persistent anti-rollback counter, and how does it survive power loss? Battery, dedicated NVRAM or protected flash are acceptable; "depends on RTC time" is not.
4. How many public-key slots does the bootloader support? What is the rotation policy? A single fixed slot is a known weakness.
5. Does the signed message include a domain prefix (product/family/major version)? Defense against cross-product replay.
6. Does the device expose, on its display or Modbus registers, the hash or version of the running image? Operational audit depends on it.
7. If validation fails during an update, does the device remain reachable for a retry, or does it brick? Anti-brick is a key differentiator at remote sites.
8. Is there secure-development documentation aligned with IEC 62443-4-1? A solid answer names internal procedures, not slogans.

Serious vendors answer these in an email; the ones who deflect or forward you to "our partner" signal that maturity has not yet reached their firmware.

Next steps

The full technical depth of the five-layer model, with tables and concrete examples, is documented in WP01 — Modbus RTU under Secure by Design, available under /en/whitepapers/. The formal specification of Ed25519 is in RFC 8032, recommended reading for those who sign and those who audit.

For roadmap discussion, integration or homologation, LRI Engineering can be reached through the contact channels published on the product site.

FAQ

1. Can I use Ed25519 on microcontrollers without hardware crypto acceleration? Yes. Portable C implementations (BearSSL, monocypher, libsodium) run Ed25519 verification at around 1.5 ms on a Cortex-M0+ at 64 MHz, with no coprocessor. Typical flash cost is 4 to 8 KB.

2. What happens if the only signing key is compromised on a product with no multiple slots? The entire fleet becomes vulnerable to adversarial firmware injection until a bootloader update is delivered over another channel — often requiring a physical recall. Multiple slots in the bootloader turn that incident into routine rotation.

3. Why does CRC-32 not replace a digital signature? CRC was designed to detect random transmission errors. An adversary can craft bytes that match a target CRC in fractions of a second. CRC remains useful for channel integrity but does not authenticate origin.

4. Is anti-rollback really necessary if the firmware is signed? Yes. Without an anti-rollback counter, an attacker can force installation of an older, legitimately signed version that contains a known public vulnerability — and signature verification accepts it because the old version was indeed signed by a valid key at the time.

5. Is the AEM-60DC8 already certified under IEC 62443-4-2 SL2? The project takes IEC 62443-4-2 SL2 as its certification goal. The process is in progress. LRI Engineering will publish the formal status when issued by the certification body. This post does not claim completed certification.

---