Bringing Post-Quantum Cryptography to SWUpdate

Quantum computing is advancing and the classical cryptography securing today’s products will not remain safe forever. Devices built today may still be receiving updates when classical cryptography can no longer be trusted. The transition must therefore begin before the threat becomes real. Making OTA updates post-quantum ready is a critical first step.

I have been contributing practical post-quantum safety directly to the upstream SWUpdate and meta-swupdate projects.

To the best of my knowledge this makes SWUpdate the first open-source OTA framework with practical post-quantum support for update signing and TLS.

The work connects the algorithms provided by OpenSSL 3.5.x+ to the real OTA workflow:

Set the CMS digest required for ML-DSA signing.
Add multiple CMS signers to the Yocto build flow.
Require classical and post-quantum signatures on the device.
Control TLS key-establishment groups

The CMS siging changes are already upstream. The TLS group option settings is the latest part of the same effort.

Securing long lived devices for the quantum era

RSA and elliptic-curve are not yet broken but nobody can give an exact timeline for a cryptographically relevant quantum computer.

But waiting for classical cryptography to break would be far too late.

NIST notes that a major cryptographic migration can take 10 to 20 years. That is already as long as the lifetime of many embedded products.

There is also the “harvest now decrypt later” problem when an attacker can record encrypted TLS traffic today store it and try to decrypt it when better attacks become available.

The broad transition timeline looks like this:

2024: NIST finalized ML-KEM, ML-DSA, and SLH-DSA.
Now to 2030: products need testing, hybrid deployment, and migration plans.
After 2030: NIST’s draft plan proposes deprecating 112-bit classical public-key schemes.
After 2035: the same draft proposes disallowing quantum-vulnerable public-key signatures and key establishment in NIST standards.

These are migration targets not predictions for when a quantum computer will arrive. The point is simple is that the transition must begin while classical systems are still secure.

Why hybrid cryptography?

Post-quantum algorithms are still new and have not yet had the decades of real-world scrutiny behind today’s classical cryptography. A hybrid design therefore keeps trusted classical algorithms in place while adding post-quantum protection.

For SWUpdate, this means:

Signing an SWU artifact with both classical (RSA or ECDSA) and ML-DSA.
Establishing TLS keys with X25519MLKEM768 which combines classical X25519 key establishment with ML-KEM-768.

The two mechanisms protect different parts of the update process.

The CMS signatures authenticate sw-description whose hashes bind the update payloads to the signed manifest. Hybrid TLS protects the network session used to download or upload the SWU.

Signing an update

The build or signing host must provide OpenSSL 3.5 or newer, because ML-DSA support was added in that release. Check the available version and algorithms first:

openssl version
openssl list -signature-algorithms | grep ML-DSA

For a local test, create one ECDSA P-256 and one ML-DSA-65 signer:

# ECDSA private key and self-signed certificate
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 \
  -out update-ecdsa.key
openssl req -new -x509 -key update-ecdsa.key -sha256 -days 3650 \
  -subj "/CN=SWUpdate ECDSA signer" -out update-ecdsa.crt

# ML-DSA private key and self-signed certificate
openssl genpkey -algorithm ML-DSA-65 -out update-mldsa.key
openssl req -new -x509 -key update-mldsa.key -days 3650 \
  -subj "/CN=SWUpdate ML-DSA signer" -out update-mldsa.crt

These commands create unencrypted private keys for demonstration. Production keys should be generated and protected by a signing service or HSM and not stored directly on the build host.

The meta-swupdate signing flow now supports multiple CMS signers. Certificates and private keys are paired by their position in the configuration:

SWUPDATE_SIGNING = "CMS"
SWUPDATE_CMS_CERT = "/keys/update-ecdsa.crt /keys/update-mldsa.crt"
SWUPDATE_CMS_KEY  = "/keys/update-ecdsa.key /keys/update-mldsa.key"
SWUPDATE_CMS_MD   = "sha512"

OpenSSL produces a single CMS structure containing two independent signatures over the same sw-description. In this example one comes from ECDSA and the other from ML-DSA.

But there is a catch: an attacker could remove one CMS signer while leaving the other signature valid. A hybrid update could quietly become classical-only.

To prevent that downgrade I added Kconfig option: CONFIG_CMS_REQUIRE_HYBRID_PQC.

When enabled, SWUpdate requires at least one trusted classical signer and one trusted post-quantum signer. Remove either one and the update is rejected.

Hybrid signing is therefore enforced.

Making hybrid TLS mandatory

OpenSSL 3.5.x+ supports X25519MLKEM768, the standardized and recommended hybrid post-quantum key-agreement group for TLS 1.3. It combines classical X25519 with ML-KEM-768. However there is no guarantee it will be negotiated.

The new tls_group option makes that choice explicit:

tls_group = "X25519MLKEM768";

If the server does not support the hybrid group the handshake fails. SWUpdate cannot silently fall back to a classical-only connection.

During a gradual rollout, compatibility can still be kept by using for example:

tls_group = "X25519MLKEM768:secp256r1";

This allows older servers but it also allows classical fallback.

Extending hybrid TLS to the Web UI

The SWUpdate Web UI can use Mongoose as its embedded web-server backend. With a PQC-capable TLS backend modern Chromium-based browsers and Firefox can negotiate X25519MLKEM768 automatically.

Conclusion

The goal was to make post-quantum protection usable and enforceable: create hybrid CMS signatures require both signatures and be able to select the hybrid TLS group and fail instead of quietly downgrading.

This does not make the complete device quantum-safe. TLS certificates, secure boot and storage and other trust boundaries still need attention.

But it gives SWUpdate projects a practical migration path today. OpenSSL 3.5.x+ supplies the algorithms and SWUpdate can now turn them into a meaningful OTA security policy.

For devices expected to remain in the field through the next decade, that is a transition worth starting now.

References

Embetrix helps customers plan and implement that transition, from crypto-agility assessments and hybrid OTA signing to TLS migration and validation on real embedded hardware. If your products need a practical path to post-quantum security please get in touch.