Vergelijking van SLH-DSA, LMS en XMSS voor firmware- en codeondertekening

Als je software of firmware ondertekent, bereik je de post-kwantumtransitie eerder dan bijna iedereen, en word je gedwongen een keuze te maken die in de rest van het PQC-debat grotendeels wordt overgeslagen. De meeste aandacht gaat uit naar TLS en certificaten, die binnen enkele uren opnieuw kunnen worden uitgegeven als er iets moet worden gewijzigd. Het ondertekenen van firmware is het tegenovergestelde. De handtekening op een firmware-image moet tien of vijftien jaar lang verifieerbaar blijven, op apparaten die je misschien nooit meer fysiek aanraakt, en tegen een aanvaller die tegen die tijd mogelijk al over een kwantumcomputer beschikt.

Als die digitale handtekening gebaseerd is op RSA of ECDSA, kan een kwantumcomputer deze vervalsen. Vervalsde firmware is dan firmware die het apparaat vertrouwt en uitvoert. Wanneer de vertrouwensbasis in de hardware is vastgelegd, is er meestal geen patch die dit achteraf kan verhelpen. Daardoor zijn de apparaten die dit jaar worden verzonden het meest kwetsbaar en het moeilijkst te repareren zodra ze in gebruik zijn. Dit is het onderdeel van de post-kwantummigratie dat niet kan wachten, en het is de reden waarom het ondertekenen van firmware de vroegste deadline heeft in de gehele transitie.

De druk is reëel, maar de antwoorden staan ​​niet ter discussie. De kwantumveilige handtekeningalgoritmen voor deze taak, SLH-DSA , LMS en XMSS, zijn allemaal hash-gebaseerd, gestandaardiseerd en gebouwd op cryptografie die al decennialang wordt bestudeerd. De vraag voor ondertekeningsteams in 2026 is dus niet of er een oplossing bestaat, maar welke ze moeten gebruiken. En de eerlijke versie van die beslissing is complexer dan het op het eerste gezicht lijkt. Dit artikel bespreekt de verschillen tussen deze algoritmen, de afweging tussen stateful en stateless die centraal staat in de keuze, en de ene regelgevende richtlijn die de beslissing vaak voor u neemt.

Post-kwantum handtekeningalgoritmen voor codeondertekening, gedefinieerd: SLH-DSA (FIPS 205), LMS en XMSS (beide NIST SP 800-208) zijn hash-gebaseerde handtekeningschema's die gestandaardiseerd zijn voor het ondertekenen van artefacten die gedurende een decennium of langer verifieerbaar moeten blijven; de keuze tussen deze schema's hangt af van de vraag of uw ondertekeningsoperatie de cryptografische status veilig kan beheren, niet van de pure prestaties.

Key Takeaways

• LMS en XMSS zijn stateful: elke privésleutel kan slechts een vast aantal handtekeningen genereren, en het hergebruiken van een eenmalig component, bijvoorbeeld uit een herstelde back-up of parallelle ondertekening, kan een aanvaller in staat stellen handtekeningen te vervalsen. SLH-DSA is stateless en elimineert dit risico volledig, ten koste van grotere handtekeningen.
• FIPS 205 (SLH-DSA) is sinds augustus 2024 een definitieve NIST-standaard; NIST SP 800-208 (LMS, XMSS) is dat sinds oktober 2020. Wat verschilt, is de ondersteuning door HSM-firmware en de compatibiliteit met verificatoren voor elk specifiek algoritme, niet de standaard zelf.
• CNSA 2.0 keurt SLH-DSA niet goed voor nationale veiligheidssystemen. Als CNSA 2.0 op u van toepassing is, zijn uw opties LMS, XMSS of ML-DSA, en niet SLH-DSA.
• Voor het volledige, gedateerde overgangsschema en de migratiearchitectuur van CNSA 2.0, zie Het ontwerpen van de transitiestrategieën voor CNSA 2.0Dit artikel richt zich specifiek op de keuze tussen SLH-DSA, LMS en XMSS.
• Welk algoritme u ook kiest, controleer eerst of de firmware van uw HSM het ondersteunt (aan de hand van de naam) en of uw verificatietools dit kunnen controleren, voordat u een pilotproject start.

Waarom hash-gebaseerde handtekeningen, en waarom nu?

Code- en firmwareondertekening heeft een eigenschap die de meeste cryptografie niet heeft: de handtekening moet vrijwel alles wat eromheen gebeurt overleven. Je ondertekent een firmware-image één keer, en die handtekening moet mogelijk gedurende de hele levensduur van de hardware correct geverifieerd worden, lang nadat de ondertekeningsinfrastructuur is veranderd. Als het algoritme erachter in die periode niet meer werkt, kan een aanvaller een handtekening vervalsen en kwaadaardige firmware verspreiden die apparaten volledig vertrouwen. Voor een root of trust die in de hardware is ingebouwd, is er mogelijk geen manier om dit in het veld te herstellen.

Die lange horizon is precies de reden waarom kwantumresistentie hier van het grootste belang is. Het is ook de reden waarom hash-gebaseerde handtekeningen de voorkeur genieten. In tegenstelling tot RSA en ECDSA , die gebaseerd zijn op getaltheoretische problemen die een kwantumcomputer kan oplossen, zijn hash-gebaseerde handtekeningen uitsluitend gebaseerd op de veiligheid van een hashfunctie zoals SHA-256. Hashfuncties worden door kwantumcomputers niet wezenlijk bedreigd, afgezien van een beheersbare afname in sterkte die grotere uitvoerwaarden kunnen opvangen. Ze bestaan ​​al lang, ze zijn goed begrepen en ze waren al lang klaar voordat de op roosters gebaseerde schema's volwassen werden. Voor iets dat vijftien jaar lang veilig moet blijven, is die staat van dienst veel waard.

SLH-DSA, LMS en XMSS zijn alle drie hash-gebaseerd en delen dezelfde onderliggende structuur: veel eenmalige handtekeningen die via een Merkle-boom worden gecombineerd tot één publieke sleutel. De verschillen tussen hen zijn doorslaggevend voor de keuze.

De werkelijke tweedeling: staten of statenloze staten

Het belangrijkste verschil zit hem niet in de prestaties of de grootte van de handtekening. Het zit hem in de staat.

LMS en XMSS zijn stateful. Elke privésleutel kan slechts een vast aantal handtekeningen genereren, en de ondertekenaar moet nauwkeurig bijhouden welke handtekeningen zijn gebruikt. Die nauwkeurige registratie is cruciaal. Als de status ooit verkeerd wordt beheerd, als een eenmalig component twee keer wordt gebruikt omdat een sleutel is hersteld vanuit een back-up, gekopieerd naar een tweede server of parallel is uitgevoerd, kan een aanvaller die beide handtekeningen ziet, nieuwe handtekeningen vervalsen. De wiskundige onderbouwing die deze systemen veilig maakt, is volledig gebaseerd op het feit dat een eenmalig component nooit opnieuw wordt gebruikt. Gaat de status mis, dan is de beveiliging ongemerkt verdwenen.

SLH-DSA is stateless. Het is specifiek ontworpen om dit risico te elimineren. In plaats van gebruikte signatures bij te houden, maakt het willekeurige selecties en vertrouwt het op een verwaarloosbaar kleine kans op een botsing. Er is geen status die kan worden aangetast, geen teller die verloren kan gaan en geen risico van een herstelde back-up. Deze ene ontwerpkeuze heeft grote operationele gevolgen, en dat is het volgende punt om te overwegen.

Wat je opoffert en wint, elke keer weer.

Stateful signatures (LMS en XMSS) zijn efficiënt en compact in vergelijking met de stateless variant, en ze worden al lange tijd ingezet voor precies deze rol: het ondertekenen van firmware. De prijs hiervoor is operationele discipline. Omdat de ondertekenaar de status perfect moet behouden, is het ondertekenen gekoppeld aan één gecontroleerde instantie van de sleutel. Je kunt het ondertekenen niet zomaar parallel uitvoeren op meerdere machines, omdat je dan juist de status hergebruikt.

Voor een firmware-ondertekeningsproces waarbij het aantal handtekeningen bekend en beperkt is, is dit doorgaans een acceptabele beperking. Daarom zijn deze schema's zo geschikt voor firmware. Het is echter sterk aan te raden om de sleutel en het bijbehorende statusbeheer in hardware, een HSM, te bewaren, zodat de status niet per ongeluk kan worden gedupliceerd of teruggedraaid.

Van de twee stateful opties is LMS de eenvoudigere en snellere standaard. Het gebruikt minder klokcycli voor sleutelgeneratie, ondertekening en verificatie, en verbruikt minder geheugen. XMSS voegt een bitmaskerconstructie toe, die sommige teams prefereren vanwege de sterkere beveiligingsveronderstellingen, ten koste van meer hashing en een hoger geheugenverbruik. Voor de meeste ondertekeningsbewerkingen is het praktische verschil klein en is LMS een redelijk uitgangspunt, tenzij u specifiek de functionaliteit van XMSS wilt.

Stateless signatures (SLH-DSA) ruilen grootte in voor veiligheid. SLH-DSA -handtekeningen zijn groter, wat van belang kan zijn voor apparaten met beperkte bandbreedte of update-mechanismen met beperkte opslagruimte, en het ondertekenen is rekenkundig zwaarder. In ruil daarvoor krijg je volledige vrijheid van statusinformatie. Omdat er niets is dat kan worden gecorrumpeerd, kan SLH-DSA worden geparallelliseerd en uitgevoerd in een gedistribueerd ondertekeningssysteem zonder het hergebruikrisico dat LMS en XMSS beperkt. Voor een grootschalige of gedistribueerde ondertekeningsoperatie waarbij het coördineren van statusinformatie over machines kwetsbaar zou zijn, is die vrijheid de grotere handtekeningen waard.

SLH-DSA versus LMS versus XMSS: naast elkaar

Afmeting	LMS	XMSS	SLH-DSA
Standaard	NIST SP 800-208 (2020)	NIST SP 800-208 (2020)	FIPS 205 (augustus 2024)
Land	Statusgebonden; eenmalige sleutels, mogen nooit herhaald worden	Statusgebonden; eenmalige sleutels, mogen nooit herhaald worden	Staatloos; geen staat om te besturen
Relatieve snelheid	De snelste van de drie; minste cycli	Langzamer dan LMS vanwege de bitmaskerconstructie.	Langzaamste; meest veeleisende ondertekeningsberekening
Relatieve signatuurgrootte	Compact	Compact, iets groter dan de LMS.	Aanzienlijk groter dan LMS/XMSS
Parallelle/gedistribueerde ondertekening	Niet veilig zonder hardware-afgedwongen statuscoördinatie	Niet veilig zonder hardware-afgedwongen statuscoördinatie	Veilig; geen gedeelde status die kan worden gecorrumpeerd.
CNSA 2.0 goedgekeurd voor ondertekening door NSS	Ja; de door de NSA geprefereerde parameterreeks (SHA-256/192)	Ja	Nee; gebruik in plaats daarvan ML-DSA als een stateless optie vereist is voor NSS.
Beste pasvorm	Firmware-ondertekening met een beperkt volume en één gecontroleerde ondertekenaar.	Net als bij LMS, wanneer de beveiligingsmarge van de bitmaskerconstructie specifiek gewenst is.	Ondertekening op grote schaal of gedistribueerd, waarbij coördinatie tussen staten kwetsbaar zou zijn.

De doorslaggevende factor: CNSA 2.0

Hier loopt de duidelijke drievoudige vergelijking spaak, en dit is een detail dat in de meeste samenvattingen wordt verzwegen. Als uw contract betrekking heeft op nationale veiligheidssystemen, of als uw klanten aan hen verkopen, is de CNSA 2.0- suite van de NSA bepalend voor uw keuze, en CNSA 2.0 keurt SLH-DSA niet goed.

Voor het ondertekenen van software en firmware keurt CNSA 2.0 de stateful schema's LMS en XMSS goed, afkomstig uit NIST SP 800-208, waarbij LMS SHA-256/192 als voorkeursparameter gebruikt. SLH-DSA is een definitieve NIST-standaard onder FIPS 205 en is volkomen legitiem voor commerciële ondertekening, maar maakt geen deel uit van CNSA 2.0 en is niet goedgekeurd voor NSS. ML-DSA, de op roosters gebaseerde stateless handtekeningstandaard, is ook goedgekeurd onder CNSA 2.0 en is de verstandige optie wanneer uw ondertekeningsvolume de capaciteit van één enkele stateful sleutel overschrijdt, of wanneer u gedistribueerde ondertekening nodig hebt.

De keuze is dus duidelijk langs één lijn te verdelen. Als u onder de CNSA 2.0-regelgeving valt, is uw stateless-optie in feite ML-DSA, niet SLH-DSA, en bouwt u waarschijnlijk voort op LMS of XMSS met hardware-ondersteund statusbeheer. Als u contracten afsluit voor de commerciële markt, heeft u de volledige keuzevrijheid en is de afweging tussen stateful en stateless een echte technische keuze in plaats van een compliance-vereiste.

De tijdsdruk is hoe dan ook reëel. Het ondertekenen van firmware kent de vroegste deadline in de hele post-kwantumtransitie, omdat de vertrouwensbasis van firmware het moeilijkst te wijzigen is nadat deze is uitgebracht. Onder CNSA 2.0 is de verwachting dat men nu al begint met het invoeren van deze handtekeningen, waarbij de deadline voor het ondertekenen van software en firmware ruim vóór de bredere overgang in 2035 valt. Of CNSA 2.0 u nu bindt of niet, de onderliggende logica blijft: hoe langer uw handtekeningen geldig moeten blijven, hoe minder tijd u heeft om over te stappen.

Gedateerde routekaart voor software- en firmwareondertekening

Milestone	Datum
Status van FIPS 205 (SLH-DSA) en NIST SP 800-208 (LMS, XMSS)	Definitieve normen sinds respectievelijk augustus 2024 en oktober 2020.
Ondersteuning voor CNSA 2.0 en voorkeursdatum voor software-/firmwareondertekening	2025 (reeds voorbij)
CNSA 2.0 gebruikt uitsluitend datumgegevens voor het ondertekenen van software/firmware.	2030
Volledige NSS-overgang (conform NSM-10)	2035

Voor het complete, meerdelige CNSA 2.0-schema en de vijfstappenmigratiearchitectuur die eraan ten grondslag ligt, zie Architecting the CNSA 2.0 Transition Strategies.

Migratieafhankelijkheden

Het kiezen van een algoritme op papier is het makkelijke deel. Voordat het iets concreets kan ondertekenen:

1. Controleer of de firmware van uw HSM het specifieke algoritme dat u hebt gekozen, LMS, XMSS of SLH-DSA, ondersteunt; algemene marketingtermen zoals "post-quantum ready" zijn geen bevestiging.
2. Voor stateful schema's (LMS, XMSS) moet worden bevestigd dat de HSM zelf het statusbeheer afdwingt in plaats van te vertrouwen op een extern systeem dat dit correct bijhoudt.
3. Controleer of de bootloader, het updatemechanisme of de platformverificatie die de handtekening controleert, het gekozen algoritme daadwerkelijk herkent; een correct gegenereerde LMS-handtekening is nutteloos voor een verificatie die alleen ECDSA begrijpt.
4. Een pilotproject is pas zinvol als zowel de HSM-ondersteuning als de verificatieondersteuning bevestigd zijn.

Verificatiecompatibiliteit

Dit is de beperking die bij de meeste algoritmevergelijkingen over het hoofd wordt gezien. Ondertekenen met LMS, XMSS of SLH-DSA is tegenwoordig alleen nuttig als het apparaat of platform dat de handtekening controleert, deze begrijpt. Veel bestaande bootloaders en firmware-updatesystemen zijn gebouwd op basis van RSA- of ECDSA-verificatie en herkennen hash-gebaseerde post-kwantumhandtekeningen niet van nature. Voor nieuwe hardwareontwerpen is het raadzaam om vanaf het begin ondersteuning voor het gekozen algoritme in de boot-ROM of het beveiligde element in te bouwen. Voor een bestaande vloot zorgt een dubbele, parallelle ondertekening (klassiek naast het post-kwantumalgoritme) ervoor dat oudere apparaten blijven werken, terwijl nieuwere apparaten kwantumresistente verificatie krijgen. Dit is hetzelfde praktische patroon dat elders wordt gebruikt bij post-kwantumcodeondertekening.

Testen en terugdraaien

Voor stateful schema's in het bijzonder moet het testen verder gaan dan een normale pilot voor ondertekening: test bewust crash-herstel- en back-up-herstelscenario's tegen het statusbeheer van de HSM, aangezien een terugdraaiing van de status precies de faalmodus is die de LMS- en XMSS-beveiliging ondermijnt. Als uit een pilot blijkt dat de gekozen HSM of het ondertekeningsplatform geen crash-consistente status kan garanderen, is de veiligere terugdraaioptie om de ondertekeningsstroom over te schakelen naar SLH-DSA (geen status die kan worden aangetast) in plaats van door te gaan met een stateful schema zonder een geverifieerde garantie voor statusbeheer. Omdat dual signing de klassieke handtekening onafhankelijk geldig houdt, hoeft bij het terugdraaien van een algoritmekeuze geen rekening te worden gehouden met reeds verzonden artefacten, alleen met de manier waarop toekomstige artefacten worden ondertekend.

Hoe Encryption Consulting u kan helpen

De keuze tussen stateful en stateless ondertekening, en de veilige uitvoering ervan, is een combinatie van strategie en concrete implementatiedetails. Dat is waar wij ons mee bezighouden.

CodeSign Secure , onze oplossing voor het ondertekenen van code, is ontworpen om ondertekeningssleutels te beschermen en gecontroleerde ondertekeningsworkflows af te dwingen, precies wat deze kwantumveilige schema's vereisen. Het biedt u een gereguleerd ondertekeningsproces voor software, firmware en andere artefacten, met de beleidscontroles en sleutelbescherming die er het meest toe doen wanneer u overstapt op LMS, XMSS of een stateless algoritme. Voor stateful schema's, waar een enkele fout in de status het hele beveiligingsmodel kan ondermijnen, zorgt een gedisciplineerd, gecentraliseerd ondertekeningssysteem in plaats van ad-hoc scripts ervoor dat een eenmalige sleutel nooit opnieuw kan worden gebruikt.

Omdat stateful-schema's in feite hardwarematig sleutel- en statusbeheer vereisen, vormt HSM-as-a-Service de natuurlijke basis hiervoor. Het houdt uw ondertekeningssleutels geïsoleerd in een hardwarematige beveiligingsmodule, zodat de status waarop LMS en XMSS afhankelijk zijn niet zomaar gekopieerd, hersteld vanuit een back-up of parallel uitgevoerd kan worden. Dit zijn namelijk de faalscenario's die een stateful-handtekening vatbaar maken voor vervalsing.

De keuze voor het juiste algoritme voor uw apparaten, uw ondertekeningsvolume en uw complianceverplichtingen wordt mede bepaald door onze post-kwantum cryptografische adviesdiensten . Wij helpen u de afweging te maken tussen stateful en stateless cryptografie, rekening houdend met uw specifieke beperkingen, de CNSA 2.0-regelgeving (indien van toepassing) en een migratieplan op te stellen voor uw ondertekeningsinfrastructuur dat aansluit op de door u gestelde termijn.

Als u bezig bent met het uitwerken van kwantumveilige ondertekening voor uw producten, of als u nog twijfelt tussen LMS, XMSS en een stateless schema voordat u een definitieve keuze maakt, neem dan contact met ons op . Wij kunnen u helpen bij het maken van de juiste beslissing en het opzetten van de bijbehorende infrastructuur.

Conclusie

De overstap naar kwantumveilige code- en firmwareondertekening is een van de weinige onderdelen van de PQC-transitie waar de algoritmen al vastliggen en de deadline nadert. SLH-DSA, LMS en XMSS zijn alle drie betrouwbaar, hash-gebaseerd en kwantumresistent. De keuze tussen deze algoritmen hangt af van de vraag of je de status veilig kunt beheren en of er factoren zijn die je richting een stateless ontwerp duwen.

Voor de meeste teams zijn compliance en operationele aspecten doorslaggevend. Als CNSA 2.0 van toepassing is, is ML-DSA de meest geschikte optie voor stateless systemen, en zijn de hash-gebaseerde opties LMS en XMSS met hardware-ondersteunde state. Zo niet, dan is SLH-DSA een legitieme manier om de last van state management volledig te vermijden, ten koste van grotere handtekeningen. Beide methoden werken, maar alleen als de ondertekeningssleutels beveiligd zijn en het proces zo gedisciplineerd is dat een eenmalige sleutel nooit twee keer wordt gebruikt.

Firmware die u dit jaar ondertekent, kan nog steeds actief zijn en moet nog steeds geverifieerd worden, lang nadat kwantumcomputers hun intrede hebben gedaan. Daarom kan deze beslissing niet langer wachten en is het belangrijk om het in één keer goed te doen.

Veelgestelde Vragen / FAQ

Is SLH-DSA hetzelfde als ML-DSA?

Nee. SLH-DSA (FIPS 205) is een stateless hash-gebaseerd ondertekeningsschema. ML-DSA (FIPS 204) is een stateless lattice-gebaseerd ondertekeningsschema. Beide zijn stateless en beide zijn ondertekeningsalgoritmen, maar ze berusten op verschillende wiskundige aannames, en alleen ML-DSA is goedgekeurd onder CNSA 2.0 voor nationale veiligheidssystemen.

Kan ik SLH-DSA gebruiken voor het ondertekenen van firmware op een nationaal veiligheidssysteem?

Nee. CNSA 2.0 keurt SLH-DSA niet goed. Voor het ondertekenen van NSS-software en -firmware zijn de goedgekeurde opties LMS, XMSS of ML-DSA.

Wat gebeurt er als de status van een stateful sleutel beschadigd raakt of hergebruikt wordt?

Als een eenmalig onderdeel van een LMS- of XMSS-sleutel tweemaal wordt gebruikt, bijvoorbeeld na een back-upherstel of parallel ondertekenen, kan een aanvaller die beide handtekeningen ziet, nieuwe handtekeningen vervalsen. Daarom vereisen stateful-schema's hardwarematig afgedwongen statusbeheer, en niet alleen procesdiscipline.

Ondersteunen de huidige firmwareverificatieprogramma's LMS, XMSS of SLH-DSA?

Inconsistent. Veel bestaande bootloaders en update-mechanismen zijn gebouwd voor RSA- of ECDSA-verificatie. Controleer of uw specifieke verificator dit ondersteunt voordat u een wijziging doorvoert en overweeg dubbele, parallelle ondertekening om oudere apparaten tijdens de overgang te laten blijven werken.

Moet ik voor LMS of XMSS kiezen als beide beschikbaar zijn?

LMS is de eenvoudigere, snellere standaard en de door de NSA geprefereerde parameterinstelling. XMSS voegt een bitmaskerconstructie toe die sommige teams verkiezen vanwege de extra beveiliging, ten koste van meer hashing en geheugen. Begin voor de meeste ondertekeningsbewerkingen met LMS, tenzij u een specifieke reden hebt om de mogelijkheden van XMSS te willen benutten.