Integrering av postkvantkryptografi i kodsigneringsarbetsflöden

Kodsignering har länge varit en viktig del av mjukvaruförtroende, och säkerställer att applikationer som levereras till användare är autentiska och inte manipulerade av hotaktörer. Men grunden för detta förtroende börjar förändras. I takt med att kvantberäkning blir mer realistisk kommer kryptografiska algoritmer som används i dagens kodsigneringsprocesser, såsom RSA och ECC , sannolikt att bli föråldrade.

Även om legitima kvantdatorattacker kanske inte inträffar imorgon, är hotet närmare än någon förväntat sig. Specifikt för signerad programvara är den viktigaste risken inte dekryptering, utan förfalskning: en angripare som så småningom bryter den underliggande signaturalgoritmen dekrypterar eller ändrar inte programvara som signerats för flera år sedan, de använder den återställda privata nyckeln för att förfalska en ny signatur på en skadlig artefakt som verkar komma från samma betrodda utgivare. Denna "skörda nu, förfalska senare"-modell gör det avgörande att börja förbereda sig nu snarare än att vänta på att kvantdatorer ska bli tillräckligt mogna för att knäcka dessa kryptografiska algoritmer. Att integrera postkvantkryptografi (PQC) i kodsigneringsarbetsflöden är inte en enkel förändring. Det kräver att man omprövar befintliga processer, verktyg och infrastruktur för att stödja nya algoritmer, större signaturer och förändrade standarder.

Integrering av postkvantkodsignering, definierad: att lägga till en kvantresistent signaturalgoritm, ML-DSA, SLH-DSA eller LMS/XMSS, som en parallell, dubbel signatur tillsammans med din befintliga CI/CD-pipelines klassiska signeringssteg, utan att ersätta det helt, så att pipelinen fortsätter att fungera för verifierare som inte har uppdaterats samtidigt som den får kvantresistent skydd för de som har det.

Key Takeaways

• ML-KEM (FIPS 203) är en viktig inkapslingsmekanism, inte en signaturalgoritm; den spelar ingen roll i kodsignering. Kodsignering använder ML-DSA (FIPS 204), SLH-DSA (FIPS 205) eller det tillståndsfulla hashbaserade LMS/XMSS (NIST SP 800-208).
• FIPS 204 och 205 har varit slutgiltiga NIST-standarder sedan augusti 2024; det som fortfarande är ojämnt är pipeline-verktyg, HSM-firmware och verifieringsstöd i hela ekosystemet, inte själva algoritmstandarderna.
• ”Hybridsignering” i en CI/CD-pipeline betyder idag dubbla, parallella, oberoende signaturer, en klassisk och en postkvantum, inte ett enda kombinerat signaturformat, vilket fortfarande är ett oavslutat IETF-utkast.
• Den här sidan behandlar praktisk pipeline-integration. Mer specifikt för algoritmval, se Jämförelse av SLH-DSA, LMS och XMSSför den fullständiga och daterade migreringsarkitekturen för CNSA 2.0, se Utformning av CNSA 2.0-övergångsstrategierna.

Att förstå PQC-landskapet

PQC hänvisar till en ny uppsättning kryptografiska algoritmer som är utformade för att vara säkra även mot kvantdatorattacker. Traditionella metoder som RSA och ECC förlitar sig på matematiska problem som kvantdatorer så småningom skulle kunna lösa mycket snabbare, medan PQC bygger på problem som tros vara mycket svårare för dem att knäcka.

De flesta PQC-metoder faller inom ett par kategorier, som gitterbaserad, hashbaserad, kodbaserad och multivariat kryptografi. Av dessa får gitterbaserade algoritmer mest uppmärksamhet eftersom de erbjuder en bra balans mellan säkerhet och prestanda. Standardiseringsinsatser från grupper som NIST hjälper redan till att begränsa vilka algoritmer organisationer bör börja förbereda sig för.

NIST har släppt FIPS 203 , 204 och 205. Det är värt att vara exakt om vad var och en är till för, eftersom de löser olika problem och endast två av dem gäller för kodsignering: FIPS 203 standardiserar ML-KEM, en nyckelinkapslingsmekanism som används för att etablera delade hemligheter för kryptering (relevant för TLS och nyckelutbyte, inte för signering); FIPS 204 standardiserar ML-DSA , en signaturalgoritm; och FIPS 205 standardiserar SLH-DSA, också en signaturalgoritm. Kodsignering använder ML-DSA eller SLH-DSA (eller det tillståndsbaserade hashbaserade LMS/XMSS från NIST SP 800-208), aldrig ML-KEM. En del av behovet av att gå över till PQC är trycket från olika myndighetsmandat som driver organisationer att migrera till PQC förr snarare än senare. CISA och USA är två exempel på dem som driver på för PQC-migrering tidigare än andra.

Med det sagt är PQC inte en enkel ersättning för det vi använder idag. Dessa algoritmer har ofta större nycklar, större signaturer och olika prestandaeffekter. På grund av detta måste organisationer tänka igenom hur införandet av PQC kommer att påverka deras nuvarande system – särskilt inom områden som kodsignering , där hastighet och kompatibilitet verkligen spelar roll.

Där traditionella kodsigneringsarbetsflöden inte räcker

Traditionella kodsigneringsarbetsflöden byggdes inte med kvanthot i åtanke. De förlitar sig på klassisk kryptografi, såsom RSA och ECC, vilka är grunden för de flesta PKI-system idag. I takt med att kvantberäkningar utvecklas kan dessa algoritmer så småningom brytas, vilket försvagar förtroendet för digitalt signerad programvara.

En av de största problemen är hur länge signerad kod finns kvar. Programvara som signeras idag kan fortfarande användas om flera år, vilket gör utgivarens signeringsnyckel till ett långlivat mål. Det är här idén om att " skörda nu, förfalska senare " kommer in – när en angripare kan bryta signaturalgoritmen som skyddar den nyckeln kan de förfalska nya signaturer som verkar komma från samma betrodda utgivare, även om den redan signerade programvaran från flera år sedan inte i sig är ändrad eller dekrypterad.

En annan utmaning är bristen på kryptoflexibilitet. Det vill säga möjligheten att växla mellan kryptografiska algoritmer utan större förändringar i systemen. De flesta kodsigneringsverktyg, certifikatutfärdare och HSM:er är byggda kring äldre algoritmer, så det är inte alltid enkelt att införa PQC. Detta gör det svårare för organisationer att anpassa sig snabbt och ökar deras totala risk.

Utforma en PQC-klar kodsigneringsstrategi

Att bygga en PQC-klar kodsigneringsstrategi börjar med att vara flexibel. Istället för att förlita sig på en enda kryptografisk metod bör dina system kunna stödja flera algoritmer och växla mellan dem allt eftersom saker och ting utvecklas. Det är särskilt viktigt just nu, eftersom PQC-standarder fortfarande förändras och sannolikt kommer att fortsätta att göra det. Ett bra sätt att börja är med en hybridsigneringsmetod. Det innebär att man använder både traditionella algoritmer och PQC tillsammans i samma signatur. Det låter dig börja lägga till kvantresistent skydd samtidigt som du förblir kompatibel med befintliga system, så att du inte bryter något i processen.

Det är också viktigt att förstå vad du redan har på plats. Du bör veta var dina nycklar, certifikat och signeringsprocesser finns i din miljö. Utan den insynen är det svårt att planera en smidig övergång till PQC. Att ha något som en CBOM , eller kryptografisk materiallista, kan hjälpa dig att säkerställa att du har den insyn du behöver i dina olika system. Dina policyer måste också utvecklas. Det innebär att sätta tydliga regler för när och hur PQC används, hur hybridsignaturer hanteras och hur du följer reglerna. Att ha dessa riktlinjer på plats hjälper till att säkerställa att din strategi är medveten och i linje med dina övergripande säkerhetsmål.

Integrering av PQC i DevOps-pipelines

Att integrera PQC i din DevOps-pipeline börjar med att veta var kodsignering passar in idag. I de flesta fall sker det under bygg- eller releasefaserna, så alla ändringar måste fungera smidigt med din befintliga CI/CD-process. En av de största utmaningarna är verktygen – många nuvarande signeringsverktyg och API:er byggdes inte för PQC, så du kan behöva uppdaterade versioner eller nya verktyg som stöder hybrid- eller PQC-baserad signering.

Prestanda är en annan faktor att tänka på. PQC-signaturer är ofta större och kan ta längre tid att generera, vilket kan sakta ner delar av din pipeline eller påverka hur artefakter distribueras. På grund av detta kan det vara klokt att börja med att bara använda PQC för dina mest kritiska applikationer snarare än allt på en gång. Innan du rullar ut något helt är testning nyckeln. Du vill se till att din signerade kod fortfarande accepteras av de plattformar du bryr dig om, att den fungerar med befintliga system och att hybridsignaturer beter sig som du förväntar dig. Att ta sig tid att validera tidigt hjälper till att undvika större problem senare.

Migrationsberoenden

Innan PQC-signering berör en verklig pipeline, bekräfta att beroendekedjan faktiskt är i ordning:

1. HSM-firmware stöder den specifika algoritm du avser att använda, bekräftad per modell, inte förutsatt från en leverantörs färdplan.
2. Din certifikatutfärdare eller certifikatutfärdare kan utfärda en certifikatprofil för den algoritmen, om arbetsflödet alls kräver ett certifikat.
3. Ditt CI/CD-signeringsverktyg eller plugin kan faktiskt anropa den nya algoritmen; många befintliga signeringsverktyg och API:er byggdes aldrig för PQC och behöver en uppdatering, inte bara en HSM som stöder den.
4. Systemen som verifierar signaturen, operativsystemets förtroendelagringar, distributionsgrindar, pakethanterare känner igen algoritmen; om de inte gör det är dubbelsignering inte valfritt.

Verifieringskompatibilitet

Detta är den begränsning som de flesta integrationsplaner underskattar. En pipeline kan producera en korrekt ML-DSA-signatur idag, men den signaturen är bara användbar för en verifierare som känner igen den. Signaturverifiering på mainstream OS-nivå gör det till stor del inte ännu, vilket är anledningen till att dubbel, parallell signering, den klassiska signaturen tillsammans med den nya, är det praktiska mönstret snarare än en direkt ersättning. Bekräfta vilken kategori var och en av dina faktiska nedströmsverifierare faller in i innan du antar att ett pilotprojekt generaliserar till produktion.

HSM-beredskap

De flesta äldre HSM:er behöver en firmwareuppdatering, eller i vissa fall hårdvaruutbyte, för att stödja ML-DSA-, SLH-DSA- eller LMS/XMSS-nyckelgenerering och -signering. För varje HSM i din pipeline, bekräfta aktuell firmware-kapacitet direkt med leverantören, få ett specifikt måldatum om en uppdatering behövs och anta inte att leverantörsstöd för hela sviten omfattar just din modell.

Testning och återställning

Testa mot varje verifierare som artefakten faktiskt kommer att möta i produktion, inte bara den som används i utvecklingen, och mät storlekspåverkan av större PQC-signaturer på alla bandbredds- eller lagringsbegränsade distributionskanaler innan du binder dig till en tidslinje för utrullning. Eftersom dubbelsignering lägger till en andra, oberoende signatur snarare än att ersätta den första, är det låg risk för återställning under en pilotfas: om PQC-signaturen orsakar ett oväntat verifieringsfel förblir den klassiska signaturen giltig, och lösningen är att pausa tillägget av den andra signaturen för det pipeline-steget medan inkompatibiliteten diagnostiseras, inte att återkalla eller utfärda något på nytt.

Framtidssäkra din kodsigneringsinfrastruktur

Att framtidssäkra din kodsigneringsuppsättning handlar inte om att göra en stor förändring, det handlar om att vara beredd att anpassa sig över tid. PQC utvecklas fortfarande, och nya algoritmer och standarder kommer att fortsätta dyka upp. På grund av det är det viktigt att hålla sig informerad om branschuppdateringar, inklusive standardiseringsinsatser och leverantörssupport, så att du kan fatta smarta beslut om när du ska anta nya metoder eller överge äldre.

Flexibilitet i er infrastruktur är också viktigt. Era nyckelhanteringssystem och HSM: er bör kunna stödja flera algoritmer och anpassa sig när kraven förändras. Att välja verktyg som är utformade för att fungera bra med andra och som kan utvecklas kommer att göra denna övergång smidigare.

Istället för att försöka göra om allt på en gång är det mer praktiskt att använda en etappvis metod. Börja i liten skala, testa vad som fungerar och bygg vidare därifrån. Detta ger ditt team tid att lära sig och anpassa sig utan att ta onödiga risker. Att regelbundet granska och uppdatera din metod hjälper till att säkerställa att din kodsigneringsprocess förblir säker och tillförlitlig i takt med att kvanthot blir mer verkliga.

Hur krypteringskonsulting kan hjälpa

På Encryption Consulting specialiserar vi oss på PKI, kryptering och certifikat av alla typer, och vi stöder våra kunder. Vi kan hjälpa din organisation att designa, implementera och hantera din PKI, eller så kan du använda vårt CBOM-verktyg, CBOM Secure. CBOM Secure är en komplett lösning för alla dina behov av kryptoinventering. Vår plattform spårar nycklar, certifikat och protokoll som används i din organisation, så att du snabbt kan avgöra om dina kryptografiska tillgångar uppfyller de specifika regelverk och efterlevnadsstandarder du behöver. För att lära dig mer om de tjänster och produkter som Encryption Consulting erbjuder, besök vår webbplats på www.encryptionconsulting.com.

Checklista för integrationsberedskap

• Bekräftat vilken algoritm du behöver: ML-DSA för generell/högvolymsignering, SLH-DSA eller LMS/XMSS om ett långlivat förtroendeankare eller CNSA 2.0-efterlevnad specifikt kräver ett hashbaserat schema.
• Bekräftat stöd för HSM-firmware för exakt den algoritmen, per modell.
• Bekräftat att ditt CI/CD-signeringsverktyg kan anropa algoritmen, inte bara att HSM stöder den.
• Bekräftat vilka nedströmsverifierare som känner igen den nya signaturen och planerat dubbelsignering för de som inte gör det.
• Pilottestades i en kontrollerad pipeline-fas med lägre risk innan skalning till produktionslanseringar.

Vanliga frågor om partihandel med mat och dryck

Används ML-KEM vid kodsignering?

Nej. ML-KEM (FIPS 203) är en nyckelinkapslingsmekanism för att etablera delade hemligheter, relevant för TLS och nyckelutbyte. Kodsignering använder signaturalgoritmer: ML-DSA (FIPS 204), SLH-DSA (FIPS 205) eller LMS/XMSS (NIST SP 800-208).

Behöver jag byta ut min klassiska signatur omedelbart?

Nej. Dubbel, parallell signering, både en klassisk och en postkvantumsignatur på samma artefakt, är det praktiska integrationsmönstret medan verifierarstödet för postkvantumsignaturer fortfarande är ojämnt över ekosystemet.

Vilken är den vanligaste anledningen till att ett PQC-signeringspilotprojekt misslyckas?

Verifieringsinkompatibilitet upptäcks efter signering snarare än tidigare. Signeringssidan (HSM, CI/CD-verktyg) verifieras vanligtvis i förväg; verifieringssidan kontrolleras ofta inte förrän en signerad artefakt misslyckas någonstans i fältet.

Finns ett enda kombinerat "hybrid"-signaturformat tillgängligt idag?

Inte ännu som en slutgiltig standard. Den relevanta IETF-specifikationen för sammansatta signaturer är fortfarande ett internetutkast. Dubbla, oberoende signaturer är den för närvarande praktiska metoden med lägre risk.

Slutsats

Övergången till postkvantkryptografi är inte bara en teoretisk idé; det är något som kommer att hända, och det kommer att förändra hur vi ser på digitalt förtroende. För kodsignering, där förtroende är direkt kopplat till programvaruintegritet och leveranskedjesäkerhet, spelar detta stor roll. Om organisationer väntar för länge med att förbereda sig riskerar de att fastna med föråldrade system som är svåra att uppdatera när det verkligen gäller. Å andra sidan ger det tidigt att börja tidigt dig tid att planera ordentligt, prova saker som hybridsignering, få bättre grepp om dina kryptografiska tillgångar och bygga in flexibiliteten att anpassa sig allt eftersom standarder utvecklas.

Det finns ingen tydlig slutlinje för införandet av PQC. Det är en pågående process, inte ett engångsprojekt. Nyckeln är att vara flexibel och fortsätta förbättra sig över tid. Genom att börja nu och ha ett genomtänkt tillvägagångssätt kan organisationer se till att det förtroende de bygger upp idag fortfarande kommer att finnas kvar i framtiden.