banner
BGIcon

The Question

Secure boot on a microcontroller depends on a signature check that starts in boot ROM and fuses, which can never be updated. Today that check is almost always ECDSA. A large quantum computer would let an attacker forge that signature and get malicious firmware accepted. Post-quantum signatures fix the forgery problem but are far larger: an ML-DSA-44 signature is 2,420 bytes where ECDSA P-256 is 64. This research asks what that change does to secure boot on small Cortex-M parts, and whether devices that are already deployed have any real migration path.

The question grew out of my MITRE eCTF 2026 work, where I led Northeastern's team building bare-metal HSM firmware on a Cortex-M0+ with keys and signatures sized for classical crypto.

Planned Stack

  • - Nordic nRF development kits
  • - nRF Connect SDK boot chain (NSIB + MCUboot)
  • - ML-DSA (FIPS 204)
  • - LMS (SP 800-208)
  • - SLH-DSA (FIPS 205)
  • - C / Zephyr RTOS
BG
Icon

  • Status

    In Progress

  • Year

    2026

  • Advisor

    Prof. Rolando Herrero

  • Role

    Graduate Researcher

Approach

Real boot chains, not just isolated benchmarks: the plan is to work on Nordic nRF boards and the nRF Connect SDK boot chain, which already splits secure boot into an immutable first stage and an upgradable MCUboot stage. That split is exactly where the migration question lives.

Three signature families: ML-DSA is general-purpose and stateless but has kilobyte keys and signatures. LMS and SLH-DSA are hash-based, with small public keys and verification that is mostly SHA-256; LMS adds the burden of signer state, since a one-time key must never be reused.

What gets measured: verification time, RAM and stack during boot, flash for the verifier, and the size of signed images and keys. RAM is a likely limit, because the image, signature, key and verify code may all need to fit on-chip before anything else is available.

BG
Icon

  • Scope

    One semester

  • Target

    Cortex-M class MCUs

Open Questions

If the boot ROM only knows ECDSA, can a mutable bootloader that adds post-quantum verification still be worth having, or does a classical root make it a false sense of security?

For parts designed today, what should a boot ROM include (for example, a hash of the public key in fuses rather than the full key) so it does not face the same problem in ten years?

The work builds on Merlin, my nRF5340 benchmark firmware for ML-KEM and ML-DSA, so the measurement setup and PSA tooling carry over.

Back to Portfolio Entries