PQC voor codeondertekening: bescherming van software en firmware met een lange levensduur

Kort antwoord: Codeondertekening brengt een duidelijk, langdurig risico met zich mee dat in de meeste PQC-planningen wordt onderschat: een ondertekend installatieprogramma, firmware-image of updatepakket blijft jaren of zelfs decennia na ondertekening in omloop. Een klassieke handtekening die vandaag wordt toegepast, is dus gedurende de hele levensduur van het artefact kwetsbaar, niet alleen tot de komst van een kwantumcomputer. Om dit risico te beperken, moet je vijf dingen goed op elkaar afstemmen: het juiste algoritme kiezen, elke handtekening voorzien van een tijdstempel zodat deze de vervaldatum van het certificaat overleeft, controleren of je HSM en tijdstempelautoriteit daadwerkelijk post-kwantumbewerkingen ondersteunen, ervoor zorgen dat het verificatiesysteem dat je handtekeningen gebruikt, deze kan controleren, en een pilot met parallelle ondertekening uitvoeren vóór de productiefase. Deze handleiding behandelt al deze vijf aspecten.

Onze PQC-architectuurhandleiding voor codeondertekening behandelt de selectie van algoritmen en de planning van gefaseerde migratie in detail. Deze handleiding richt zich op wat er gebeurt nadat een algoritme is gekozen: het behouden van de verifieerbaarheid van een handtekening zolang het artefact dat ermee wordt beschermd in gebruik blijft, tot en met het verlopen van certificaten, het voldoen aan TSA- en HSM-vereisten en een uiteindelijke algoritmeovergang.

Key Takeaways

• Software en firmware met een digitale handtekening blijven jaren of zelfs decennia in omloop. Het risico voor een klassieke digitale handtekening beslaat daarom de gehele levensduur van het artefact, niet alleen de tijd tot er een kwantumcomputer bestaat.
• Een RFC 3161-tijdstempel bewijst dat een handtekening op een specifiek tijdstip is aangemaakt. Dit maakt het mogelijk dat de verificatie blijft slagen, zelfs nadat het ondertekeningscertificaat zelf is verlopen.
• De meeste openbare tijdstempelautoriteiten bieden nog geen ondersteuning voor post-quantum ondertekening, en de meeste oudere FIPS 140-2 HSM's missen native ondersteuning voor het PQC-algoritme. Dit zijn twee afzonderlijke gereedheidstekorten die beide moeten worden aangepakt voordat een pilot als volledig post-quantum kan worden beschouwd.
• Firmware met een implementatiecyclus van meer dan tien jaar kent een specifiek probleem: de handtekening kan na de implementatie niet opnieuw worden ondertekend. De handtekening die tijdens de build is aangebracht, moet dus gedurende de gehele operationele levensduur van het apparaat verifieerbaar blijven.
• Een parallelle pilot voor digitale handtekeningen, waarbij zowel een klassieke als een post-kwantumhandtekening op hetzelfde object wordt toegepast, stelt een organisatie in staat om post-kwantumtools te valideren zonder de verificatie te onderbreken voor systemen die nog niet geschikt zijn voor post-kwantumtechnologie.

Het risico van een langdurige signatuur

De meeste discussies over kwantumrisico's gaan over het principe 'nu oogsten, later decoderen', waarbij een aanvaller vandaag versleuteld verkeer onderschept om het te decoderen zodra er een kwantumcomputer beschikbaar is. Codeondertekening brengt een verwant, maar ander risico met zich mee: een aanvaller die klassieke handtekeningen kan vervalsen, kan, zodra er een cryptografisch relevante kwantumcomputer is, achteraf kwaadaardige software produceren die niet te onderscheiden is van legitieme, historisch ondertekende software. Een ondertekend installatieprogramma, firmware-image of updatepakket dat jarenlang in omloop blijft, betekent dat de kwetsbaarheid niet begint op het moment dat een kwantumcomputer verschijnt, maar gedurende de gehele resterende levensduur van alle klassiek ondertekende software die op dat moment nog actief is. Daarom moet bij de planning van de migratie naar codeondertekening specifiek rekening worden gehouden met de levensduur van de software, en niet alleen met een algemene migratiedeadline.

Wat tijdstempels nu eigenlijk doen

Een codeondertekeningscertificaat heeft een geldigheidsperiode, doorgaans 460 dagen volgens de huidige CA/Browser Forum-vereisten. Zonder tijdstempel is de verificatie van een handtekening afhankelijk van een controle met een certificaat dat op het moment van verificatie nog binnen die geldigheidsperiode moet vallen. Dit levert problemen op zodra het certificaat verloopt, omdat de verificatie van software die jaren geleden is ondertekend anders zou mislukken.

Een RFC 3161-tijdstempelautoriteit lost dit op door een hash van de handtekening cryptografisch te koppelen aan een vertrouwd, onafhankelijk verifieerbaar tijdstip, met behulp van een eigen ondertekeningssleutel die in een HSM is opgeslagen. Een verificator die een handtekening met tijdstempel controleert na het verlopen van het certificaat, stelt een andere vraag: was het certificaat geldig op het moment dat de tijdstempel aantoont dat de handtekening is aangemaakt, in plaats van of het certificaat op dit moment geldig is. Daarom wordt het toevoegen van een tijdstempel aan elke codeondertekening in een productieomgeving als verplicht beschouwd, en niet als een optionele extra.

Tijdstempelautoriteit Post-kwantumgereedheid

Dit is de lacune die de meeste PQC-codeondertekeningsplannen over het hoofd zien. Een tijdstempeltoken is zelf een digitale handtekening, gegenereerd door de eigen sleutel van de TSA, en die sleutel moet post-kwantumcompatibel zijn om de tijdstempel zelf bestand te maken tegen toekomstige cryptanalyse. Op het moment van publicatie van deze handleiding is ondersteuning voor post-kwantumtijdstempels nog in ontwikkeling binnen het TSA-ecosysteem en nog niet breed beschikbaar. Dit betekent dat een organisatie die vandaag de dag ML-DSA-codeondertekening test, mogelijk merkt dat haar tijdstempels nog steeds worden uitgegeven door een klassieke RSA- of ECDSA-TSA-sleutel.

Die kloof is met name van belang voor artefacten met een lange levensduur. Een software-artefact dat is ondertekend met ML-DSA maar voorzien van een tijdstempel met een klassieke sleutel, erft een zwakke schakel: het tijdstempel dat bewijst wanneer de post-kwantumhandtekening is aangemaakt, is zelf kwetsbaar voor hetzelfde toekomstige cryptanalytische risico dat de post-kwantumhandtekening juist moest voorkomen. Controleer de specifieke post-kwantum roadmap en algoritmeondersteuning van uw TSA voordat u een pilotproject voor codeondertekening als volledig post-kwantum beschouwt, en voorzie kritieke artefacten met een lange levensduur van een nieuw tijdstempel zodra post-kwantumtijdstempeling beschikbaar is bij uw provider.

HSM-ondersteuning: De andere paraatheidskloof

De gereedheid voor tijdstempelautorisatie is slechts de helft van de infrastructuurvraag; de HSM die uw daadwerkelijke ondertekeningssleutels bevat, is de andere helft, en de vereisten van CA/Browser Forum schrijven voor dat privésleutels voor codeondertekening zich in FIPS-gevalideerde hardware bevinden, niet in software. De meeste oudere FIPS 140-2-gecertificeerde HSM's zijn gebouwd voordat NIST ML-DSA en SLH-DSA definitief vaststelde en bieden geen native ondersteuning voor beide. Organisaties die oudere HSM-firmware gebruiken, moeten ofwel upgraden naar FIPS 140-3-compatibele firmware met post-quantum-ondersteuning, ofwel een weloverwogen dual-stack-aanpak hanteren, waarbij klassieke ondertekening doorgaat op bestaande hardware terwijl post-quantum-ondertekening wordt uitgevoerd op bijgewerkte of nieuw aangeschafte HSM's gedurende de overgangsperiode.

Controleer uw specifieke HSM-model en firmwareversie aan de hand van de daadwerkelijk door de leverancier geleverde ondersteuning na de quantumtest (PQC), en niet aan de hand van een roadmap-aankondiging, voordat u een productiepipeline voor ondertekening implementeert. De FIPS 140-3-certificering voor PQC-compatibele HSM-firmware vordert gestaag bij de belangrijkste leveranciers, maar de geleverde ondersteuning verschilt per model en firmwareversie. Het verschil tussen "de leverancier heeft PQC-ondersteuning aangekondigd" en "onze specifieke hardware heeft gevalideerde PQC-firmware" is precies waar ondertekeningspipelines vastlopen.

Validatie op lange termijn: verder dan een enkel tijdstempel

Validatie op lange termijn (LTV) vergroot de verifieerbaarheid van handtekeningen door bewijs van de intrekkingsstatus, zoals een OCSP-reactie of een CRL, dat is verzameld op of rond het moment van ondertekening, samen met de tijdstempel in te bedden. Een betrouwbare tijdbron en het bewijs dat het ondertekeningscertificaat op dat moment niet was ingetrokken, zorgen ervoor dat een handtekening gedurende langere perioden verifieerbaar blijft, soms tot wel twintig jaar voor het ondertekenen van documenten, zonder dat de verificator contact hoeft op te nemen met een actieve intrekkingsdienst die mogelijk niet meer bestaat op het moment van verificatie.

Voor artefacten met bijzonder lange verificatievereisten kan een tweede tijdstempel worden toegevoegd voordat het betrouwbaarheidsanker van het eerste tijdstempel twijfelachtig wordt. Hierdoor wordt de aantoonbare tijdlijn van de handtekening effectief verder in de toekomst verankerd. Deze gelaagde aanpak, en niet een enkel tijdstempel alleen, is essentieel voor een werkelijk langdurige geldigheid van de handtekening.

Firmware: een opvallend, langdurig probleem

Firmware kent een variant van het probleem met de langdurige digitale handtekening, iets wat software-updates doorgaans niet hebben: eenmaal geïnstalleerd op een apparaat, kan de handtekening vaak niet opnieuw worden geplaatst of vervangen, met name bij embedded of industriële hardware met een levensduur van tientallen jaren. De handtekening die tijdens de build wordt toegepast, is de enige handtekening die het apparaat ooit zal hebben. Dit maakt de keuze van het ondertekeningsalgoritme, de tijdstempeling en de langetermijnvalidatiestrategie die eraan ten grondslag liggen, een beslissing met gevolgen voor de gehele operationele levensduur van het apparaat, niet alleen voor de initiële implementatieperiode.

Dit is ook de reden waarom hash-gebaseerde ondertekeningsschema's zoals LMS en XMSS, naast ML-DSA, specifiek interessant zijn voor het ondertekenen van firmware: hun beveiliging berust op de eigenschappen van de hashfunctie in plaats van op nieuwere roosterveronderstellingen, een conservatieve keuze die belangrijker is voor een artefact dat niet opnieuw kan worden ondertekend dan voor een artefact dat tijdens een normale updatecyclus opnieuw kan worden uitgegeven.

Verificatie-ecosystemen: het meerjarige synchronisatieprobleem

Een digitale handtekening is alleen nuttig als de systemen die deze controleren, deze ook daadwerkelijk kunnen valideren. Elk besturingssysteem, elke browser, elk beveiligingsprogramma en elk installatieplatform dat ondertekende documenten verifieert, moet post-kwantumalgoritmen herkennen voordat een handtekening correct kan worden gevalideerd. Dit is een echte, meerjarige uitdaging voor de synchronisatie van het ecosysteem, geen eenmalige update: een organisatie die vandaag de dag begint met ondertekenen met ML-DSA zal documenten produceren die de validatie niet doorstaan ​​op elk verificatiesysteem dat nog niet is bijgewerkt om dat algoritme te herkennen. Dit is precies het compatibiliteitsrisico dat een pilotproject voor parallel ondertekenen moet beheersen.

Breng uw daadwerkelijke verificatie-ecosysteem in kaart vóór de uitrol, niet alleen de ondertekeningskant: welke besturingssysteemversies, beveiligingshulpmiddelen en installatieprogramma's gebruiken uw klanten of interne gebruikers daadwerkelijk, en welke daarvan herkennen post-quantum handtekeningen al? Een technisch gereed ondertekeningsproces is niet hetzelfde als een implementatie die daadwerkelijk gevalideerd wordt voor uw echte gebruikers.

Een pilotproject voor parallelle ondertekening uitvoeren

De praktische manier om tools voor het ondertekenen van code na kwantumtechnologie te valideren zonder de verificatie in de productieomgeving in gevaar te brengen, is door zowel een klassieke als een post-kwantumhandtekening op hetzelfde artefact toe te passen. Dit resulteert in een losstaand patroon met dubbele handtekeningen in plaats van één enkele hybride handtekening. Systemen die de klassieke handtekening al valideren, blijven ongewijzigd werken; systemen die zijn bijgewerkt om de post-kwantumhandtekening te controleren, kunnen deze onafhankelijk verifiëren. Hierdoor kan een organisatie haar ML-DSA-ondertekeningsinfrastructuur, HSM-ondersteuning, tijdstempeling en CI/CD-integratie in productieomstandigheden testen, terwijl alle bestaande verificatiesystemen precies blijven werken zoals vóór de pilot.

Wat we daadwerkelijk zouden aanbevelen

Controleer of zowel uw tijdstempelautoriteit als uw HSM specifieke post-kwantumalgoritmen ondersteunen voordat u een ML-DSA-ondertekeningspilot als volledig kwantumresistent beschouwt; de handtekening, de tijdstempel en de hardware erachter moeten post-kwantum zijn om het artefact daadwerkelijk te beschermen. Voer nu parallelle klassieke en post-kwantumondertekening uit op productie-artefacten, in plaats van te wachten op een volledige overstap, om de tooling te valideren onder reële productieomstandigheden en zonder verificatierisico. Voor firmware en andere artefacten die na implementatie niet opnieuw kunnen worden ondertekend, moet u het ondertekeningsalgoritme en de tijdstempelstrategie beschouwen als een beslissing met gevolgen voor de gehele operationele levensduur van het apparaat, en dienovereenkomstig wegen. Breng uw verificatie-ecosysteem parallel aan uw ondertekeningsinfrastructuur in kaart, aangezien een technisch complete ondertekeningspipeline in productie nog steeds faalt als de systemen die de handtekeningen controleren niet zijn bijgewerkt.

Hoe encryptieconsultancy kan helpen

CodeSign Secure , het platform voor codeondertekening voor bedrijven van Encryption Consulting, is specifiek ontwikkeld voor het risico dat in deze handleiding wordt beschreven: het ondersteunt ML-DSA- en SLH-DSA-ondertekening met verwijderbare handtekeningen, bewaart sleutels in FIPS-gevalideerde HSM's en dwingt RFC 3161-tijdstempeling af als een beleidsgestuurde stap in elke ondertekeningsworkflow. De hierboven beschreven tekortkomingen op het gebied van tijdstempels en HSM-gereedheid worden dus op platformniveau aangepakt in plaats van overgelaten te worden aan individuele pipelineconfiguraties. Firmware- en IoT-ondertekening wordt ondersteund via LMS (NIST SP 800-208), het hash-gebaseerde schema dat in deze handleiding wordt genoemd voor artefacten die na implementatie niet opnieuw kunnen worden ondertekend.

Onze PQC Advisory Services integreren de TSA-gereedheidsevaluatie, de in kaart brengen van het verificatie-ecosysteem en de pilot voor parallelle ondertekening, zoals beschreven in deze handleiding, in een gestructureerd migratieplan, afgestemd op de bredere architectuurroadmap in onze bijbehorende handleiding.

De kracht van een handtekening hangt af van de zwakste schakel.

Het beschermen van een langdurig ondertekend document vereist meer dan alleen het kiezen van een post-kwantumalgoritme. De tijdstempel die bewijst wanneer het document is ondertekend, de HSM die de sleutel bevat waarmee het is ondertekend, en het verificatiesysteem dat het jaren later controleert, moeten allemaal tegelijkertijd post-kwantumklaar zijn. Een tekortkoming in een van deze onderdelen ondermijnt immers de bescherming die de algoritmekeuze had moeten bieden. Het expliciet bevestigen van de gereedheid van de TSA en de HSM, het toevoegen van bewijsmateriaal voor validatie op de lange termijn, het beschouwen van de beperking dat de firmware niet opnieuw kan worden ondertekend als een eersteklas ontwerpcriterium, en het in kaart brengen van het verificatiesysteem parallel aan de ondertekeningspipeline, bepalen in feite of een handtekening die vandaag wordt gezet, over twintig jaar nog steeds relevant is.

Veelgestelde Vragen / FAQ

Waarom is tijdstempeling belangrijker tijdens een post-kwantumovergang?

Tijdstempels bewijzen dat een handtekening op een specifiek tijdstip is gemaakt. Dit is precies het bewijs dat nodig is om aan te tonen dat een handtekening is gezet voordat een klassiek algoritme verouderd raakte, waardoor de handtekening beschermd is tegen claims van vervalsing achteraf, zodra kwantumcomputers dat algoritme kunnen kraken.

Zijn tijdstempelautoriteiten en HSM's vandaag de dag klaar voor het post-quantumtijdperk?

Ondersteuning is nog in ontwikkeling binnen beide ecosystemen en is nog niet breed beschikbaar. De meeste oudere FIPS 140-2 HSM's bieden geen native ondersteuning voor ML-DSA of SLH-DSA, en de meeste openbare TSA's hebben ook nog geen ondersteuning voor post-quantum signing geleverd. Controleer of uw specifieke leverancier daadwerkelijk ondersteuning biedt (niet alleen de aangekondigde ondersteuning) voordat u een pilot als volledig post-quantum beschouwt.

Waarom verschilt het ondertekenen van firmware van het ondertekenen van reguliere software voor PQC-doeleinden?

Firmware, met name op embedded en industriële hardware, kan vaak niet opnieuw worden ondertekend nadat deze is geïmplementeerd. De handtekening die tijdens de build is aangebracht, moet gedurende de gehele operationele levensduur van het apparaat, die tientallen jaren kan duren, verifieerbaar blijven. Dit maakt de initiële keuze voor het algoritme en de tijdstempels veel belangrijker dan bij software die regelmatig updates ontvangt.

Wat is een pilotproject voor parallelle ondertekening?

Het toepassen van zowel een klassieke als een post-kwantumhandtekening op hetzelfde object, als twee afzonderlijke, losgekoppelde handtekeningen. Bestaande verificatiesystemen blijven de klassieke handtekening ongewijzigd valideren, terwijl bijgewerkte verificatiesystemen de post-kwantumhandtekening onafhankelijk kunnen controleren. Hierdoor kan een organisatie de infrastructuur voor post-kwantumondertekening testen zonder enig risico voor de huidige verificatie.

Hoe lang blijft een correct getimede handtekening verifieerbaar?

Met langetermijnvalidatie die een tijdstempel combineert met ingebed bewijs van intrekkingsstatus, worden verificatieperioden tot wel twintig jaar genoemd voor toepassingen waarbij documenten digitaal worden ondertekend. Het opnieuw toevoegen van een tijdstempel voordat de betrouwbaarheid van het oorspronkelijke tijdstempel twijfelachtig wordt, kan die periode voor bijzonder lang bestaande documenten verder verlengen.