In October 2024, the National Institute of Standards and Technology (NIST) published an initial public draft of Special Publication 800 – 131A, with the title “Transitioning the Use of Cryptographic Algorithms and Key Lengths”.
It details how the NIST expects the requirements for use of cryptography to protect non-classified information to evolve.
There are several key points, such as abandoning ECB and SHA-1, but the main one this post will investigate is digital signatures.
Transitioning to 128-bit strength
The NIST expects that the 112-bit strength that is considered sufficient today for most applications will not be anymore by the end of 2030.
What this means, is that algorithms, functions and modes that provide this security strength should no longer be used beyond that point to protect new information. They can still be used to e.g. verify a digital signature, or decrypt information, but not to sign or encrypt data.
By the first of January 2031, NIST will expect entities impacted by the Federal Information Processing Standard (FIPS) to have transitioned to at least 128 bits of security. One of the algorithms that will be impacted by this is RSA, and specifically, RSA 2048. As can be seen in Column 4 of Table 2 in NIST SP 800-57 (part 1), RSA with a 2048-bit modulus provides a security strength of 112 bits. In 6 years, that will no longer be enough.
What path forward?
The first idea coming to mind as to what to do next would be to move to RSA 3072 bits, as the next line in the table does indicate that a 3072-bit modulus will provide a security strength of 128 bits, enough to satisfy the FIPS standard in 2031. In many cases, this is the most straightforward option, as it is most likely a simple matter of software configuration.
One could argue, that with increasing key sizes, elliptic curve-based asymmetric cryptography becomes more appealing, as the computational performance aspect becomes increasingly in its favor, so it might be time to switch to ECDSA.
Both of those options would be in compliance with the next FIPS standard, but neither is the NIST’s prefered choice.
Post-quantum cryptography
In reading section 1.2.3, which details the NIST’s recommended strategy to move away from 112-bit security strength, it is clear that while moving to 128-bit strength was the original plan, the NIST is now recommending a one-step migration to quantum-resistant digital signature schemes.
As this will mean adopting new digital signature standards, which are very new and for which implementations are not yet widely accepted, the NIST is not making this mandatory, but it is recommending it.
This is part of the Post-Quantum Cryptography project which recently (in August 2024) published three new FIPS standards:
- FIPS 203 describes ML-KEM, the Module-Lattice-based Key Encapsulation Mechanism based on CRYSTALS (CRYptographic Suite for Algebraic LatticeS) – Kyber
- FIPS 204 describes ML-DSA, the Module-Lattice-based Digital Signature Scheme based on CRYSTALS – Dilithium
- FIPS 205 describes SLH-DSA, the StateLess Hash-Based Digital Signature Scheme based on SPHINCS+
The latter two are the quantum-resistant digital signature schemes the NIST is recommending. A second round is currently in progress to select more signature schemes.
Immediate impact
The provisions of the standard regarding digital signatures do not come into effect until January 1st, 2031. Even then, compliance with that standard will only be automatically mandatory for a specific set of systems that are the object of legislation mandating it.
However, this is a good indication of where the field of cryptography is headed, and 2031 is not that far away. Although most cryptographic software can be updated between now and then, and configured to use either longer moduli, or different algorithms, there is one specific area where this standard is immediately relevant, especially in the embedded world: implementations of Secure Boot.
Indeed, secure boot is based on the verification of a digital signature on the various components of the boot chain. The initial verification is necessarily done by an immutable piece of software since replacing that software with a malicious implementation would compromise the entire chain. It will therefore not be possible to update that software to fit the NIST’s recommandations on existing devices.
On embedded systems, that is the vendor’s ROMcode, which verifies the signature of the bootloader. One can cite e.g. the software supporting NXP’s HAB (High Assurance Boot). NXP’s HABv4 does support RSA 3072 and RSA 4096 and should therefore not be concerned by these new recommendations, but a secure boot implementation that would only match the current standard, RSA 2048 would prevent its users from signing new updates after 2031 if they want to remain FIPS-compliant.
Partial impact mitigation
Importantly, what will be deprecated after 2030 is the generation of new RSA signatures using under 128 bits of security strength.
Verification of such signatures will be allowed for legacy use. The ROMcode verifying the signature of the bootloader (generated before January 1st, 2031) would therefore be allowed, but not signing a new bootloader update.
This means, that makers/users of devices with a ROMcode that does not implement RSA 3072 or stronger could mitigate this issue by making sure that their bootloader does support an algorithm fitting this criterion, by shipping a bootloader update signed using the soon-to-be deprecated security strength before January 2031.
The operating system, which is the software more likely to need regular updates, can then be updated as normal, as the bootloader will be doing the OS’s signature verification, and supports non-deprecated security strengths.
Conclusion
The path of implementing the new quantum-resistant cryptographic standards, though the most future-proof, will probably be challenging at first in the embedded world.
This is particularly true in the context of secure boot, especially until hardware acceleration for them is more ubiquitous.
Impact can be mitigated from a completely update-locked system to a system whose OS can be updated but not its bootloader, by making sure of the proper security strength support at the bootloader level before 2031.