PQC för kodsignering: Skydda långlivad programvara och firmware

Snabbt svar: Kodsignering medför en tydlig långvarig risk som de flesta PQC-planerare underskattar: ett signerat installationsprogram, en firmware-avbildning eller ett uppdateringspaket finns kvar i omlopp i åratal eller årtionden efter signering, så en klassisk signatur som tillämpas idag exponeras under artefaktens hela livslängd, inte bara förrän en kvantdator anländer. Att skydda sig mot den risken innebär att man får ihop fem saker: att välja rätt algoritm, tidsstämpla varje signatur så att den överlever certifikatets utgångsdatum, bekräfta att din HSM och tidsstämpelauktoritet faktiskt stöder post-kvantumoperationer, se till att verifieringsekosystemet som konsumerar dina signaturer kan kontrollera dem och köra ett parallellt signeringspilotprojekt innan någon produktionsövergång. Den här guiden täcker alla fem.

Vår guide till PQC-kodsigneringsarkitektur täcker algoritmval och planering av fasmigrering på djupet. Den här guiden fokuserar på vad som händer efter att en algoritm har valts: att hålla en signatur verifierbar så länge artefakten den skyddar används, genom certifikatets utgångsdatum, luckor i TSA- och HSM-beredskap och en eventuell algoritmövergång.

Key Takeaways

• Signerad programvara och firmware finns kvar i omlopp i åratal eller årtionden, så riskfönstret för en klassisk signatur är artefaktens hela livslängd, inte bara tiden tills en kvantdator finns.
• En RFC 3161-tidsstämpel bevisar att en signatur skapades vid en specifik tidpunkt, vilket gör att verifieringen kan fortsätta att lyckas även efter att själva signeringscertifikatet har löpt ut.
• De flesta offentliga tidsstämpelutfärdare har ännu inte levererat stöd för post-quantum-signering, och de flesta äldre FIPS 140-2 HSM:er saknar inbyggt stöd för PQC-algoritmer, två separata beredskapsluckor som båda behöver kontrolleras innan en pilot räknas som helt post-quantum.
• Firmware med driftsättningscykler på över ett decennium står inför ett tydligt problem: den kan inte signeras på nytt efter driftsättning, så signaturen som tillämpas vid byggtillfället måste förbli verifierbar under enhetens hela livslängd.
• Ett pilotprojekt för parallell signering, som tillämpar både en klassisk och en post-kvantumsignatur på samma artefakt, låter en organisation validera post-kvantumverktyg utan att bryta verifieringen för system som ännu inte är post-kvantumkapabla.

Den långlivade signaturrisken

De flesta diskussioner om kvantrisker kretsar kring "skörda-nu-avkryptera-senare", en angripare som idag fångar krypterad trafik för att dekryptera när en kvantdator väl existerar. Kodsignering medför en relaterad men distinkt risk: en angripare som kan förfalska klassiska signaturer när en kryptografiskt relevant kvantdator väl anländer kan retroaktivt producera skadliga artefakter som verkar omöjliga att skilja från legitim, historiskt signerad programvara. Ett signerat installationsprogram, en firmware-avbildning eller ett uppdateringspaket som finns i omlopp i flera år innebär att exponeringsfönstret inte är det ögonblick då en kvantdator dyker upp, utan hela den återstående livslängden för varje klassiskt signerad artefakt som fortfarande är aktiv vid den tidpunkten. Det är därför planering av migrering av kodsignering måste ta hänsyn till artefakternas livslängd specifikt, inte bara en generell migreringsdeadline.

Vad tidsstämpling faktiskt gör

Ett kodsigneringscertifikat har ett giltighetsfönster, vanligtvis 460 dagar enligt nuvarande krav från CA/Browser Forum. Utan en tidsstämpel är verifieringen av en signatur beroende av att den kontrolleras mot ett certifikat som fortfarande måste vara inom det giltighetsfönstret vid verifieringstillfället, vilket blir ett problem i det ögonblick certifikatet löper ut, eftersom verifiering av programvara som signerats för flera år sedan annars skulle misslyckas.

En RFC 3161-tidsstämpelutfärdare löser detta genom att kryptografiskt binda en hash av signaturen till en betrodd, oberoende verifierbar tidpunkt, med hjälp av sin egen signeringsnyckel som finns i en HSM. En verifierare som kontrollerar en tidsstämplad signatur efter att certifikatet har löpt ut ställer en annan fråga: var certifikatet giltigt vid den tidpunkt då tidsstämpeln bevisar att signaturen skapades, snarare än om certifikatet är giltigt just nu. Det är därför tidsstämpling av varje produktionskodsigneringsoperation behandlas som obligatorisk praxis, inte ett valfritt tillägg.

Tidsstämpelauktoritet Post-Quantum Readiness

Det här är den lucka som de flesta PQC-kodsigneringsplaner förbiser. En tidsstämpeltoken är i sig en digital signatur, producerad av TSA:s egen nyckel, och den nyckeln måste vara postkvantumkapabel för att tidsstämpeln i sig ska motstå framtida kryptanalys. I och med publiceringen av denna guide är stöd för postkvantumtidsstämpling fortfarande på väg att växa fram i hela TSA-ekosystemet snarare än att vara allmänt tillgängligt, vilket innebär att en organisation som piloterar ML-DSA-kodsignering idag kan upptäcka att dess tidsstämplar fortfarande utfärdas av en klassisk RSA- eller ECDSA TSA-nyckel.

Den luckan är särskilt viktig för långlivade artefakter. En programvaruartefakt som signerats med ML-DSA men tidsstämplat med en klassisk nyckel ärver en svag länk: tidsstämpeln som bevisar när post-kvantumsignaturen skapades är i sig sårbar för samma framtida kryptanalytiska risk som post-kvantumsignaturen var avsedd att undvika. Bekräfta din TSA:s specifika post-kvantumfärdplan och algoritmstöd innan du behandlar en kodsigneringspilot som helt post-kvantum end-to-end, och omtidsstämpla kritiska långlivade artefakter när post-kvantumtidsstämpling blir tillgänglig från din leverantör.

HSM-stöd: Det andra beredskapsgapet

Beredskap för tidsstämpelauktoritet är bara halva infrastrukturfrågan; HSM:n som innehar dina faktiska signeringsnycklar är den andra halvan, och CA/Browser Forum-kraven kräver att privata nycklar för kodsignering finns i FIPS-validerad hårdvara, inte programvara. De flesta äldre FIPS 140-2-certifierade HSM:er byggdes innan NIST slutförde ML-DSA och SLH-DSA och saknar inbyggt stöd för någon av dem. Organisationer som kör äldre HSM-firmware måste antingen uppgradera till FIPS 140-3-kompatibel firmware med post-quantum-stöd eller köra en avsiktlig dual-stack-metod, där klassisk signering fortsätter på befintlig hårdvara medan post-quantum-signering körs på uppdaterade eller nyligen anskaffade HSM:er, under övergångsfönstret.

Verifiera din specifika HSM-modell och firmwareversion mot leverantörens faktiska levererade post-quantum-support, inte ett tillkännagivande om en färdplan, innan du kopplar en signeringspipeline för produktion till den. FIPS 140-3-certifiering för PQC-kompatibel HSM-firmware har utvecklats hos större leverantörer, men levererat support varierar beroende på modell och firmwareversion, och gapet mellan "leverantören tillkännagav PQC-stöd" och "vår specifika distribuerade hårdvara har validerat PQC-firmware" är precis där signeringspipelines stannar av.

Långsiktig validering: Bortom en enda tidsstämpel

Långtidsvalidering (LTV) utökar verifierbarheten av signaturer ytterligare genom att bädda in bevis för återkallningsstatus, såsom ett OCSP-svar eller CRL, som samlats in vid eller nära signeringstillfället, tillsammans med tidsstämpeln. Tillsammans gör en pålitlig tidskälla och bevis på att signeringscertifikatet inte återkallades vid den tidpunkten att en signatur förblir verifierbar under längre perioder, ibland upp till tjugo år för användningsfall för dokumentsignering, utan att verifieraren behöver kontakta en aktiv återkallningstjänst som kanske inte längre finns när verifieringen sker.

För artefakter med särskilt långa verifieringskrav kan en andra tidsstämpel tillämpas innan det förstas eget förtroendeankare blir tvivelaktigt, vilket effektivt förankrar signaturens bevisbara tidslinje längre in i framtiden. Denna skiktade metod, inte enbart en tidsstämpel, är vad en genuint långvarig signaturgiltighet är beroende av.

Firmware: Ett tydligt långvarigt signaturproblem

Firmware innehåller en version av det långvariga signaturproblemet som programuppdateringar vanligtvis inte har: när den väl är distribuerad till en enhet kan den ofta inte omsigneras eller ersättas, särskilt på inbyggd eller industriell hårdvara med flera decenniers livslängd. Signaturen som tillämpas vid byggtidpunkten är den enda signaturen som artefakten någonsin kommer att ha, vilket gör valet av signeringsalgoritm, tidsstämpling och långsiktig valideringsstrategi bakom den, till ett beslut med konsekvenser som sträcker sig till enhetens hela driftstid, inte bara dess initiala driftsättningsfönster.

Det är också därför hashbaserade signaturscheman som LMS och XMSS, tillsammans med ML-DSA, ser ett specifikt intresse för firmware-signering: deras säkerhet vilar på hashfunktionsegenskaper snarare än nyare gitterantaganden, ett konservativt val som är viktigare för en artefakt som inte kan signeras om än för en som kan utfärdas på nytt vid en normal uppdateringscykel.

Verifieringsekosystem: Problemet med flerårig synkronisering

En signatur är bara användbar om systemen som kontrollerar den faktiskt kan validera den, och varje operativsystem, webbläsare, säkerhetsverktyg och installationsplattform som verifierar signerade artefakter måste känna igen postkvantalgoritmer innan de kan validera en korrekt. Detta är en verkligt flerårig utmaning för ekosystemsynkronisering, inte en engångsuppdatering: en organisation som börjar signera med ML-DSA idag kommer att producera artefakter som inte klarar valideringen på alla verifieringssystem som ännu inte har uppdaterats för att känna igen den algoritmen, vilket är just den kompatibilitetsrisk som ett parallellsigneringspilotprojekt är utformat för att hantera.

Kartlägg ditt faktiska verifieringsekosystem före utrullning, inte bara signeringssidan: vilka operativsystemversioner, säkerhetsverktyg och installationsprogram som dina kunder eller interna användare faktiskt kör, och vilka av dessa känner redan igen post-kvantumsignaturer. En signeringspipeline som är tekniskt redo är inte detsamma som en implementering som faktiskt kommer att validera för din verkliga användarbas.

Köra ett pilotprojekt för parallell signering

Det praktiska sättet att validera verktyg för postkvantkodsignering utan att riskera produktionsverifiering är att tillämpa både en klassisk och en postkvantsignatur på samma artefakt, ett fristående dubbelsignaturmönster snarare än en enda hybridsignatur. System som redan validerar den klassiska signaturen fortsätter att fungera oförändrade; system som uppdateras för att kontrollera postkvantsignaturen kan verifiera den oberoende. Detta låter en organisation utöva sin ML-DSA-signeringsinfrastruktur, HSM-stöd, tidsstämpling och CI/CD-integration i produktionsförhållanden medan varje befintlig verifierare fortsätter att fungera exakt som den gjorde innan pilotprojektet startade.

Vad vi egentligen skulle rekommendera

Bekräfta både din tidsstämpelauktoritets och din HSMs specifika stöd för post-kvantumalgoritmer innan du behandlar någon ML-DSA-signeringspilot som helt kvantresistent från början till slut; signaturen, tidsstämpeln och hårdvaran bakom båda måste vara post-kvantum för att artefakten faktiskt ska skyddas. Kör parallell klassisk och post-kvantumsignering på produktionsartefakter nu, istället för att vänta på en fullständig överkoppling, för att validera verktygen med verkliga produktionsförhållanden och noll verifieringsrisk. För firmware och andra artefakter som inte kan signeras på nytt efter distribution, behandla signeringsalgoritmen och tidsstämpelstrategin som ett beslut med konsekvenser som varar enhetens hela livslängd och vikta det beslutet därefter. Kartlägg ditt verifieringsekosystem parallellt med din signeringsinfrastruktur, eftersom en tekniskt komplett signeringspipeline fortfarande misslyckas i produktion om systemen som kontrollerar dessa signaturer inte har kommit ikapp.

Hur krypteringskonsulting kan hjälpa

CodeSign Secure , Encryption Consultings plattform för kodsignering av företag, är byggd specifikt för den risk som beskrivs i den här guiden: den stöder ML-DSA- och SLH-DSA-signering med avtagbara signaturer, lagrar nycklar inuti FIPS-validerade HSM:er och tillämpar RFC 3161-tidsstämpling som ett policystyrt steg i varje signeringsarbetsflöde, så tidsstämpel- och HSM-beredskapsluckorna som tas upp ovan åtgärdas på plattformsnivå snarare än att lämnas till individuell pipelinekonfiguration. Firmware- och IoT-signering stöds via LMS (NIST SP 800-208), det hashbaserade schema som den här guiden flaggar för artefakter som inte kan signeras om efter distribution.

Våra PQC-rådgivningstjänster bygger upp TSA-beredskapsutvärderingen, verifieringsekosystemets kartläggning och pilotprojektet för parallell signering som behandlas i den här guiden till en strukturerad migreringsplan, sekvenserad mot den bredare arkitekturfärdplanen i vår medföljande guide.

Signaturen är bara så stark som dess svagaste länk

Att skydda en långlivad signerad artefakt kräver mer än att välja en postkvantalgoritm. Tidsstämpeln som bevisar när den signerades, HSM:n som innehar nyckeln som signerade den, och verifieringsekosystemet som kontrollerar den år senare, måste alla vara postkvantklara, eftersom en lucka i någon av dem undergräver det skydd som algoritmvalet var avsett att ge. Att bekräfta TSA- och HSM-beredskap explicit, lägga till bevis för långsiktig validering, behandla firmwares begränsning att den inte kan signeras om som en förstklassig designinput, och kartlägga verifieringsekosystemet tillsammans med signeringspipelinen är det som faktiskt avgör om en signatur som tillämpas idag fortfarande betyder något om tjugo år.

Vanliga frågor om partihandel med mat och dryck

Varför spelar tidsstämpling större roll under en post-kvantövergång?

Tidsstämpling bevisar att en signatur skapades vid en specifik tidpunkt, vilket är exakt de bevis som behövs för att bevisa att en signatur gjordes innan en klassisk algoritm föråldrades, vilket skyddar den mot retroaktiva förfalskningsanspråk när kvantdatorer kan bryta den algoritmen.

Är tidsstämpelauktoriteter och HSM:er redo för post-quantum idag?

Stöd framträder fortfarande i båda ekosystemen snarare än att vara allmänt tillgängligt. De flesta äldre FIPS 140-2 HSM:er saknar inbyggt ML-DSA- eller SLH-DSA-stöd, och de flesta offentliga TSA:er har inte heller levererat post-quantum signing. Bekräfta din specifika leverantörs levererade, inte tillkännagivna, stöd innan du behandlar en pilot som helt post-quantum.

Varför skiljer sig firmware-signering från vanlig programvarusignering för PQC-ändamål?

Firmware, särskilt på inbyggd och industriell hårdvara, kan ofta inte omsigneras när den väl är driftsatt. Signaturen som tillämpas vid byggtillfället måste förbli verifierbar under enhetens hela livslängd, som kan sträcka sig över årtionden, vilket gör att den initiala algoritmen och tidsstämplingsbeslutet är mycket mer inriktat än för programvara som får regelbundna uppdateringar.

Vad är ett parallellt signeringspilotprojekt?

Tillämpa både en klassisk och en post-kvantumsignatur på samma artefakt som två separata, fristående signaturer. Befintliga verifierare fortsätter att validera den klassiska signaturen oförändrad medan uppdaterade verifierare kan kontrollera post-kvantumsignaturen oberoende, vilket låter en organisation testa post-kvantumsigneringsinfrastrukturen utan risk för aktuell verifiering.

Hur länge kan en korrekt tidsstämplad signatur förbli verifierbar?

Med långsiktig validering som kombinerar en tidsstämpel och inbäddade bevis för återkallelsestatus, citeras verifieringsperioder på upp till tjugo år för användningsfall av dokumentsignering. Omtidsstämpling innan den ursprungliga tidsstämpelns förtroendeankare blir tvivelaktigt kan förlänga detta ytterligare för särskilt långlivade artefakter.