Crypto-agility in firmware: designing devices that can change their cryptography

Every cryptographic algorithm eventually retires. MD5 did. SHA-1 did. RSA and elliptic-curve cryptography are now on a published deprecation path.

For a web application, retiring an algorithm is a migration project. For a device in the field, it can mean a recall.

Crypto-agility is the ability to change the cryptography a system uses without redesigning the system. It sounds like a library feature. In embedded products it’s an architecture decision, and it’s made very early.

Where agility usually breaks

In my experience, devices rarely fail to change their cryptography because of the algorithm itself. They fail because of an assumption made somewhere else.

• The bootloader verifies firmware with one fixed algorithm and one fixed public key, burned into read-only memory.
• The partition layout reserves exactly enough space for today’s signature, and not a byte more.
• The update protocol has a message format that can’t carry a larger signature or a second one.
• The device identity is a certificate issued by a chain that can’t be re-signed.
• The keys live in a secure element that only supports the algorithms of its generation.

Each of these choices was reasonable when it was made. Together, they turn a cryptographic upgrade into a hardware change.

Design principles

These are the principles I’d want any new connected product to follow. None of them requires choosing a post-quantum algorithm today.

1. Separate the root of trust from the algorithm. The immutable part of the boot chain should be as small as possible, and able to verify the next stage with more than one scheme, or to hand over to an updatable stage.

2. Leave room. Budget flash, RAM and message sizes for signatures and keys several times larger than today’s. Post-quantum signatures are kilobytes, not bytes.

3. Version everything that carries cryptography. Firmware images, manifests, certificates and protocol messages should declare which algorithms they use, so that old and new can coexist during a transition.

4. Plan for dual signatures. During a migration, an update may need to be signed with both the old and the new scheme, so that every device in the field can verify it. Design the manifest so that this is possible.

5. Make keys replaceable. Have a documented, tested procedure to rotate signing keys and roots of trust, including what happens to devices that are offline for months.

6. Know your dependencies. Agility is impossible if you don’t know which component, from which supplier, implements which cryptographic function. An SBOM helps; a map of cryptographic relationships helps more.

The organisational side

A device can be technically agile and still be stuck, because nobody knows who decides.

Changing a signing algorithm touches hardware, firmware, the update backend, manufacturing, certificate management, customer support and sometimes certification. Each team holds part of the information. If the dependencies between those parts aren’t visible, every migration starts with weeks of archaeology.

That is the problem we work on at Shorium: modelling the cryptographic dependencies inside connected products, so that teams can see what a change will affect before they make it. I explained the idea of the Trust Twin in Why I’m building Shorium.

A simple test

Here is a test I find useful. Ask your team:

“If we had to replace the algorithm we use to sign firmware on our oldest supported product, what would we change, who would do it, and how long would it take?”

If the answer is a plan, you have some agility. If the answer is a silence, you know where to start.

Regulation is moving in the same direction. The Cyber Resilience Act expects products to stay secure through their support period, and NIST plans to deprecate today’s public-key algorithms after 2030. Devices designed now will live through that change. They should be built for it.