Programvaruleveranskedjan bygger på förtroende, och varje signerad binärfil är beroende av ett grundläggande antagande, att de kryptografiska algoritmer som skyddar dessa signaturer, särskilt RSA och ECDSA, inte kan brytas av någon angripare med tillgängliga beräkningsresurser. Men det antagandet är inte längre säkert på obestämd tid.
Framväxten av kryptografiskt relevanta kvantdatorer (CRQC) introducerar en systemrisk för alla digitala signatursystem som är i produktion idag. NIST slutförde sina första postkvantkryptografiska standarder i augusti 2024 och uppmanade uttryckligen systemadministratörer att omedelbart påbörja integrationen. Tillsynsmyndigheter och teknikledare rör sig i takt, från NSA:s CNSA 2.0-mandat som kräver ML-DSA-implementering för nationella säkerhetssystem, till Googles och Cloudflares mål om fullständigt PQC-implementering i hela deras infrastruktur senast 2029.
Frågan är inte längre om organisationer behöver övergå till postkvantalgoritmer för kodsignering. Det är om de kommer att slutföra övergången innan en CRQC (Code Quantity Qualification Certification) gör förseningen avgörande.
Vi kommer att bryta ner PQC-algoritmlandskapet, de specifika implementeringsutmaningarna för kodsignering, arkitekturstrategierna och den stegvisa migreringsfärdplanen som ger programvaruleveranskedjans team en tydlig väg framåt, utan driftsavbrott. För tidsstämpling, HSM-beredskap och långsiktig verifieringsmekanik som avgör om en signatur som tillämpas idag fortfarande validerar om tjugo år, se vår PQC för kodsignering: Skydda långlivad programvara och firmware.
PQC-kodsigneringsstrategi, definierad: en prioriterad, fasad plan för att flytta en programvaruleveranskedjas signeringsinfrastruktur till kvantresistenta algoritmer, ML-DSA, SLH-DSA eller FN-DSA, vald efter arbetsbelastning snarare än som standard, distribuerad tillsammans med klassiska signaturer under övergången och sekvenserad så att root-of-trust-ändringar sker före beroende system snarare än efter.
Key Takeaways
- FIPS 204 (ML-DSA) och FIPS 205 (SLH-DSA) har varit slutgiltiga NIST-standarder sedan augusti 2024. FN-DSA (FIPS 206) är fortfarande ett initialt offentligt utkast, som förväntas slutföras i slutet av 2026 eller början av 2027, och är ännu inte en släppt standard.
- Algoritmvalet är arbetsbelastningsspecifikt: ML-DSA för CI/CD-signering med hög volym, där den generellt sett presterar konkurrenskraftigt med eller snabbare än RSA i publicerade riktmärken, SLH-DSA för långlivade förtroendeankare där dess konservativa, långsammare profil är acceptabel, FN-DSA (när den är slutgiltig) för begränsade IoT/inbäddade enheter.
- Hybridsignering (klassisk plus PQC, tillämpat parallellt) är det praktiska mönstret idag eftersom verifierarstödet för PQC-signaturer fortfarande är ojämnt över ekosystemet; detta är samma dubbla signaturmetod som beskrivs för CI/CD specifikt i vår SLSA Level 3-arkitekturdel.
- Denna sida är prioriterings- och arkitekturstrategilagret för den allmänna programvaruförsörjningskedjan. För det CNSA 2.0-specifika övergångsschemat och femfasmigreringen, se Utformning av CNSA 2.0-övergångsstrategierna; för att välja specifikt mellan hashbaserade signaturscheman, se Jämförelse av SLH-DSA, LMS och XMSS.
- Du kan inte migrera det du inte kan inventera; 34 % av företagen anger brist på centraliserad kryptografisk insyn som ett primärt hinder för PQC-beredskap.
Varför PQC-kodsignering inte kan vänta
När de flesta organisationer tänker på kvanthotet ser de det som ett framtida problem. Men för mjukvaruleveranskedjor minskar algoritmiska förbättringar kraven på qubits för att knäcka RSA-2048. År 2019 uppskattades det att det skulle krävas cirka 20 miljoner qubits för att knäcka RSA-2048, men år 2025 har nyare arkitekturer som använder Quantum Low-Density Parity-Check (QLDPC)-kod minskat den uppskattningen till cirka 100 000 qubits, vilket är en 20-faldig minskning enbart driven av algoritmisk innovation, inte hårdvara, på under sex år.
Till skillnad från krypterad kommunikation, där "skörda nu, dekryptera senare" gäller för konfidentialitet, medför signerad programvara en annan risk: " Lita på nu, förfalska senare ". Ett signerat installationsprogram, en firmware-avbildning, ett programuppdateringspaket: dessa artefakter finns kvar i omlopp i åratal eller årtionden. Om en CRQC anländer och klassiska signaturalgoritmer bryts, kan en angripare retroaktivt förfalska signaturer på skadliga artefakter som verkar oskiljbara från legitim historiskt signerad programvara. Riskfönstret är inte när en CRQC anländer, utan det är hela livslängden för varje klassiskt signerad artefakt som fortfarande kommer att vara i produktion vid den tidpunkten.
Citi Institutes rapport från januari 2026 , Quantum Threat: The Trillion-Dollar Security Race Is On, uppskattar att sannolikheten för att en kvantdator ska bryta mot RSA-2048 år 2034 är 19 till 34 %. Cirka 20 miljarder aktiva IoT-enheter världen över är för närvarande exponerade för kvanthotet under sin livslängd. För mjukvaruteam som hanterar produkter med flera års livslängd är övergången till PQC-kodsignering inte längre en fördel att vara tidig i utvecklingen. Det är en riskreducering i leveranskedjan som måste påbörjas nu.
NIST PQC-algoritmer för kodsignering
NIST slutförde sina tre första postkvantkryptografiska standarder den 13 augusti 2024, vilka trädde i kraft omedelbart för federal användning i USA och fungerar som globalt riktmärke för industrins införande. För digitala signaturer, som utgör grunden för kodsignering, finns tre algoritmer tillgängliga eller närmar sig slutförandet.
Att välja rätt algoritm är ett kritiskt arkitekturbeslut som påverkar allt från CI/CD-pipelinens prestanda till root-of-trust-livslängd. Så här jämför sig NIST-signaturalgoritmerna för kodsigneringsapplikationer:
| Algoritm | Standard | Kärnprincip | Signaturstorlek | genomströmning | Bäst lämpad för |
|---|---|---|---|---|---|
| ML-DSA (KRISTALLER-Dilitium) | FIPS 204 (Slutförd) | Strukturerat gitter (Modul-LWE) | 2–3 kB | Generellt sett konkurrenskraftiga med eller snabbare än klassiska system i publicerade riktmärken | Allmän paketsignering, DevOps, CI/CD-leveranskedja |
| SLH-DSA (SPHINCS+) | FIPS 205 (Slutförd) | Statslös hashbaserad (SHA-2/SHAKE) | 8–50 kB | Betydligt lägre; betydande omkostnader | Långsiktig arkivering, affärskritiska förtroendeankare |
| FN-DSA (FALCON) | FIPS 206 (Initialt offentligt utkast; förväntas slutgiltigt i slutet av 2026 eller början av 2027) | Kompakt gitter (NTRU-baserat) | 0.6–1.2 kB | Snabb (optimerad för begränsade enheter) | IoT-firmware, inbyggda system, resursbegränsad hårdvara |
Implementeringsutmaningar
PQC-kodsigneringsalgoritmerna är standardiserade och säkerhetsbevisen är solida. Det är en operativ och infrastrukturell utmaning. Men det finns några saker som kräver tydlig planering:
Uppblåsning av signatur och nyckelstorlek
Den mest omedelbart synliga förändringen vid övergången från klassiska till PQC-algoritmer är den betydande ökningen av nyckel- och signaturstorlekar.
| Komponent | RSA-3072 (Klassisk) | ML-DSA-65 (PQC) |
|---|---|---|
| Public Key | ~384 byte | ~1,952 byte |
| privat nyckel | ~384 byte | ~4,032 byte |
| namnteckning | ~384 byte | ~3,309 byte |
Med en rå 64-byte P-256 ECDSA-signatur som jämförelsepunkt är en ML-DSA-65-signatur (3 309 byte) ungefär 52 gånger större. Det förhållandet gäller specifikt för den råa 64-byte-representationen; verklighetskodade (DER) ECDSA-signaturer är vanligtvis något större än 64 byte, så denna jämförelse bör läsas som ett exempel på ökningens omfattning snarare än en universell multiplikator mot ECDSA-signaturer i allmänhet. För signeringspipelines med hög volym som bearbetar tusentals artefakter per dag påverkar denna storleksökning lagringskrav, nätverksöverföringstider för signerade artefakter och kapaciteten hos alla system som hanterar, validerar eller cachar signaturer.
Dessa effekter är hanterbara med korrekt arkitekturplanering. Klientsidig hashing säkerställer att endast hashfiler snarare än fullständiga artefaktbinärfiler passerar signeringsinfrastrukturen, och hårdvaruacceleration i moderna Hardware Security Modules (HSM) minskar beräkningskostnaden.
Äldre HSM-gap
Organisationer bör verifiera sin specifika HSM-modells PQC-färdplan och planera uppgraderingar av firmware därefter. De flesta äldre FIPS 140-2-certifierade HSM:er saknar inbyggt stöd för NIST PQC-standarder. Organisationer som kör äldre HSM-firmware måste antingen uppgradera till FIPS 140-3-kompatibel firmware med PQC-stöd eller hantera en "dual-stack"-metod under övergångsperioden där klassisk signering fortsätter på befintliga HSM:er medan PQC-signering körs på uppdaterad eller ny hårdvara.
FIPS 140-3-certifieringen för HSM-firmware med PQC-stöd fortskrider, och Entrust , Thales , Securosys och Utimaco har alla levererat eller tillkännagivit PQC-kompatibla firmwareuppdateringar.
Prestandaskillnader
De tre NIST PQC-signaturalgoritmerna har betydande olika prestandaegenskaper, även om de exakta siffrorna varierar avsevärt beroende på parameteruppsättning, RSA-nyckelstorlek som används som jämförelsebaslinje, om du mäter signering eller verifiering, det specifika programvarubiblioteket och CPU-arkitekturen, HSM-implementering, hårdvaruacceleration och om meddelandeförhashning används. Behandla alla specifika dataflödesprocent, inklusive de allmänna karakteriseringarna nedan, som illustrativa snarare än portabla mellan miljöer; jämför mot ditt eget bibliotek, din egen hårdvara och parameteruppsättning innan du förlitar dig på ett nummer.
- ML-DSA presterar generellt sett konkurrenskraftigt med, och i många publicerade riktmärken snabbare än, klassisk RSA för signeringsoperationer, tack vare dess effektiva gitterbaserade design.
- SLH-DSA är betydligt långsammare än klassisk RSA i de flesta konfigurationer, ofta med en till två storleksordningar, vilket gör den dåligt lämpad som primär signeringsalgoritm i pipelines med hög volym.
Denna prestandaskillnad är avgörande för algoritmval. Att välja SLH-DSA för en CI/CD-pipeline som signerar hundratals artefakter per byggcykel riskerar att skapa en flaskhals i dataflödet som omintetgör syftet med en automatiserad pipeline. ML-DSA är generellt sett det bättre valet för prestandakänsliga signeringskontexter; SLH-DSA är generellt reserverat för användningsfall med långlivade förtroendeankare där dess konservativa säkerhetsprofil motiverar prestandakostnaden.
Valideringsflaskhals
Varje operativsystem, webbläsare, säkerhetsverktyg och programvaruinstallationsplattform som validerar signaturer på signerade artefakter måste uppdateras för att känna igen och validera PQC-signaturer. Detta är en flerårig utmaning för ekosystemsynkronisering. En organisation som börjar signera med ML-DSA idag kommer att producera artefakter vars PQC-signaturer inte kan verifieras av system som ännu inte har uppdaterats. Det är just därför hybridsignering, som tillämpar både en klassisk och en PQC-signatur på varje artefakt, är rätt arkitektur för övergångsperioden.
Enligt en undersökning rapporterar 48 % av företagen att de för närvarande är oförberedda på kvanthot , medan 34 % anger brist på centraliserad insyn i sina kryptografiska tillgångar som ett primärt hinder för PQC-beredskap . Man kan inte migrera det man inte kan inventera.
Det grundläggande steget för alla PQC-migreringsprogram är en komplett kryptografisk identifieringsövning som identifierar varje certifikat, varje nyckel och varje signeringsoperation i hela bygg-, signerings- och distributionspipelinen. Encryption Consulting erbjuder CBOM Secure för att hjälpa dig att upprätthålla en inventering för alla kryptografiska objekt i din miljö. Utan denna inventering bygger PQC-migreringsplaner på ofullständig information.
Hybridsignering: Dubbla signaturer, inte ett sammansatt format
Det är värt att vara exakt om vad "hybrid" betyder här, eftersom det används löst. Den praktiska metoden idag är dubbla, parallella signaturer: artefakten bär en klassisk signatur och en PQC-signatur som två oberoende signaturblock. En verifierare som inte har uppdaterats kontrollerar den klassiska signaturen och ignorerar den den inte känner igen; en uppdaterad verifierare kan kontrollera båda. Ett enda kombinerat "sammansatt" signaturformat för X.509-certifikat är fortfarande ett IETF Internet-Draft, inte en slutgiltig standard, från och med 2026, så det är för tidigt att bygga produktionsverktyg mot det. Dubbelsignering är det lägre riskalternativet för närvarande.
Migreringsberoenden: Byggordningen
Prioriteringsramverket nedan visar vad som är viktigast; det är den tekniska ordning som dessa saker faktiskt måste ske i.
- Bekräfta att HSM-firmware stöder den specifika algoritmen (ML-DSA, SLH-DSA eller senare FN-DSA) som du avser att använda; detta måste verifieras per modell, inte antas från en leverantörs allmänna PQC-färdplan.
- Uppgradera rot- och mellanliggande CA-infrastruktur, eftersom det är förtroendeankaret för allt som signeras nedströms och måste flyttas före beroende system.
- Integrera PQC-signering i CI/CD-pipelinen som ett ytterligare, parallellt signeringssteg, inte en ersättning, så att klassisk signering fortsätter utan avbrott.
- Bekräfta vilka nedströmsverifierare (OS-förtroendelager, pakethanterare, interna distributionsgrindar) som kan kontrollera den nya signaturen och behandla alla som inte kan det som fortfarande beroende av den klassiska signaturen.
- Pilotera en kontrollerad produktlinje med lägre risk innan skalning, och dra endast tillbaka den klassiska signaturen när verifierartäckningen i dina faktiska distributionskanaler är bekräftad, inte antagen.
Testning
Innan du skalar upp bortom ett pilotprojekt, testa mot varje verifierare som artefakten faktiskt kommer att möta i produktion, inte bara den som används i utvecklingen, eftersom hanteringen av okända signaturer inte garanteras vara konsekvent över plattformar. Mät storlekens inverkan av PQC-signaturer på artefaktstorlek och överföringstid för alla bandbreddsbegränsade distributionskanaler, och belastningstesta signeringsgenomströmningen under den verkliga algoritmen och volymen, särskilt om SLH-DSA är med i mixen, med tanke på dess betydligt lägre genomströmning i förhållande till ML-DSA.
rollback
Eftersom dubbelsignering lägger till en andra, oberoende signatur snarare än att ersätta den första, är det låg risk att återställa under en pilotfas: om PQC-signaturen orsakar ett oväntat verifieringsfel någonstans i fältet, förblir den klassiska signaturen giltig, och lösningen är att pausa tillägget av den andra signaturen för den artefaktströmmen medan inkompatibiliteten diagnostiseras. Situationen som kräver verklig försiktighet är att helt dra tillbaka den klassiska signaturen; gör det bara efter att verifierartäckningen har bekräftats, eftersom att återkalla beslutet i efterhand innebär att återaktivera dubbelsignering snarare än en enkel konfigurationsändring.
Daterad färdplan
| Milestone | Datum |
|---|---|
| FIPS 204 (ML-DSA) och FIPS 205 (SLH-DSA) slutförda | August 13, 2024 |
| FIPS 206 (FN-DSA) förväntat slutförande | Sent 2026 eller början av 2027 (fortfarande utkast) |
| CNSA 2.0 support-and-prefer-datum för programvaru-/firmwaresignering | 2025 (redan passerat) |
| CNSA 2.0 exklusivt användningsdatum för signering av programvara/firmware | 2030 |
| Google och Cloudflare siktar på fullständig PQC-implementering i hela sin infrastruktur | 2029 |
| Fullständig NSS-övergång (enligt NSM-10) | 2035 |
Strategisk prioritering
Organisationer som försöker hantera alla aspekter av PQC-övergången samtidigt kommer att ha svårt att följa och prioritera uppgifterna. Ramverket nedan, som är hämtat direkt från riskprofilen för leveranskedjan, kategoriserar åtgärder efter brådska och vikt.
Implementera nu: Viktigt och brådskande
- Uppgradera rot och mellannivå certifikatmyndigheter (CA:er) till PQC-kompatibla algoritmer, eftersom CA-infrastrukturen är förtroendeankaret för allt nedströms och måste flyttas först.
- Lösa Skörda nu, dekryptera senare (HNDL) risker för värdefulla signerade artefakter genom att omsignera långlivad programvara med hybridsignaturer innan hotfönstret öppnas.
- Hantera prestanda- och latenskonsekvenser av större PQC-nycklar och -signaturer innan de påverkar produktionsflödet.
- Validerar hybridsigneringsarkitektur för bakåtkompatibilitet mot er faktiska distributions- och verifieringsinfrastruktur före eventuell produktionslansering.
Strategisk planering: Viktigt men mindre brådskande
- Utveckla och testa hybridsignaturscheman över representativa användningsfall i ert specifika programvaruekosystem.
- Val av PQC-algoritmer för varje produktlinje och användningsfall för signering baserat på prestandakrav, enhetsbegränsningar och behov av signaturers långa livslängd.
- Utforma kryptoagil arkitektur så att signeringsinfrastrukturen kan byta algoritmer och rotera nycklar utan att behöva en fullständig pipeline-ombyggnad varje gång.
- Kartläggning av kompatibilitet mellan tredjepartsleverantörskedjor för att förstå vilka nedströmspartners, distributionsplattformar och verifieringsverktyg som är redo att använda PQC-signerad programvara.
Taktiska uppgifter: Brådskande men operativt fokuserade
- Hantera ökningarna av certifikatvolymen som följer med nyckelrotation under migreringen.
- Svara på krav på efterlevnadsrapportering för regulatoriska förfrågningar.
- Integrering av PQC-signering i CI/CD-pipelines tillsammans med äldre verktyg under övergången.
Övervakning: Mindre brådskande och mindre viktigt nu
- Analys av PQC-algoritmens stabilitet över tid efter driftsättning.
- PQC-migrering för icke-kritiska äldre system.
- Spåra framtida utvecklingar för leverantörer av kvantattacker.
Hur Encryption Consultings CodeSign Secure hjälper
CodeSign Secure är Encryption Consultings plattform för hantering av kodsignering för företag, och den är specifikt utformad för att stödja migrering av PQC-kodsignering i varje fas av ovanstående färdplan.
Stöd för PQC-algoritm
CodeSign Secure v3.02 stöder signering i produktionsklass med alla primära NIST PQC-algoritmer som en avtagbar signatur för signerings- och verifieringsprocesser:
- ML-DSA (FIPS 204) på alla tre säkerhetsnivåer (ML-DSA-44, ML-DSA-65 och ML-DSA-87) för generella paket- och leveranskedjepipelines
- SLH-DSA (FIPS 205) för långsiktig arkivsignering och verksamhetskritiska förtroendeankarapplikationer
- LMS (NIST SP 800-208) för firmware och IoT-signeringsapplikationer där hashbaserad, tillståndsbaserad kvantresistens föredras
HSM-baserad nyckelhantering för PQC-nycklar
CodeSign Secure lagrar alla privata signeringsnycklar, både klassiska och PQC, inuti FIPS 140-2 Level 3-certifierade hårdvarusäkerhetsmoduler . Plattformen integreras med Entrust nCipher, Thales Luna, Securosys, Utimaco, samt moln-HSM:er från AWS och Azure, som alla har levererat eller aviserat stöd för ML-DSA och SLH-DSA i sin PQC-kompatibla firmware.
CI/CD Pipeline Integration
CodeSign Secure integreras direkt med Azure DevOps, Jenkins, GitLab CI, TeamCity och andra större pipeline-plattformar, och stöder både API-baserade och kommandoradsanrop. PQC -signeringsåtgärder kan konfigureras som kontrollerade, policystyrda steg i releasepipelines, vilket inte skiljer sig från befintliga klassiska signeringsarbetsflöden ur utvecklarens perspektiv.
Detaljerad åtkomstkontroll och granskningsloggning
Rollbaserad åtkomstkontroll i CodeSign Secure styr vem som kan begära PQC-signeringsåtgärder, vilka artefakter som kan signeras med vilken algoritm och vilket certifikat, och vilka godkännandesteg som krävs. Varje signeringshändelse, inklusive den algoritm som används, certifikatet, artefakt-hashen, tidsstämpeln och den godkännande identiteten, loggas oföränderligt.
Skanning av programvarusårbarheter
CodeSign Secure inkluderar skanning av programvarusårbarheter före signering och hashverifiering före/efter signering som en del av signeringsarbetsflödet. Innan en PQC-signatur tillämpas kan plattformen validera att artefakten som signeras har klarat definierade säkerhetsgranskningskriterier, vilket säkerställer att den kvantresistenta signaturen tillämpas på en säker artefakt och inte bara en kryptografiskt skyddad.
Vanliga frågor om partihandel med mat och dryck
Vilken PQC-signaturalgoritm ska jag använda för CI/CD-kodsignering?
ML-DSA (FIPS 204). I de flesta publicerade riktmärken presterar den konkurrenskraftigt med eller snabbare än klassisk RSA, vilket gör den lämplig för pipelines med hög volym, även om den exakta dataflödet beror på ditt specifika bibliotek, hårdvara och parameteruppsättning. SLH-DSAs dataflöde är betydligt lägre, ofta med en storleksordning eller mer, vilket gör den dåligt lämpad för rutinmässig signering under byggtid; den är bättre reserverad för långlivade förtroendeankare.
Är FN-DSA redo att användas idag?
Inte än. FN-DSA (FIPS 206) är fortfarande ett initialt offentligt utkast från och med 2026, och förväntas slutföras i slutet av 2026 eller början av 2027. Planera för det, men bygg inte produktionsberoenden på det innan det är en släppt standard.
Behöver jag ersätta klassiska signaturer omedelbart?
Nej, och det borde du inte. Dubbel, parallell signering, både en klassisk och en PQC-signatur på samma artefakt, är den praktiska metoden medan verifierarstödet för PQC-signaturer i hela ekosystemet fortfarande är ojämnt.
Vilka är de enskilt största blockerande organisationerna som underskattar?
Verifieringskompabilitet. En artefakt kan signeras korrekt med ML-DSA idag, men den signaturen är bara användbar för system som har uppdaterats för att känna igen den; detta är ett flerårigt problem med ekosystemsynkronisering, inte ett signeringsproblem.
Var ska jag börja om jag inte har inventerat min signeringsinfrastruktur än?
Med kryptografisk identifiering: en komplett inventering av varje certifikat, nyckel och signeringsåtgärd i bygg-, signerings- och distributionspipelinen. Migreringsplaner som skapats utan denna inventering arbetar utifrån ofullständig information.
Slutsats
Postkvantövergången för kodsignering är inte en engångsföreteelse. Det är en flerårig arkitektonisk utveckling som kräver medveten planering, fasad utförande och infrastruktur som kan hantera både klassiska och kvantresistenta signeringsoperationer samtidigt under övergångsperioden.
Regulatoriska mandat, inklusive NIST:s deadlines 2030 och 2035, CNSA 2.0:s ML-DSA-implementeringskrav och den brittiska NCSC:s migreringsmilstolpar, sätter konkreta förväntningar som organisationer inom både offentlig och privat sektor redan arbetar för att uppfylla. Och hotet "Trust Now, Forge Later" innebär att varje klassiskt signerad artefakt med en lång distributionslivslängd ackumulerar risker idag som kommer att materialiseras när en CRQC anländer.
På Encryption Consulting byggde vi CodeSign Secure för att göra PQC-övergången praktiskt genomförbar idag, med stöd för ML-DSA och SLH-DSA med avtagbara signaturer och de infrastrukturkontroller som efterlevnads- och styrningsprogram kräver.
