Beskrivning

De snabba framstegen inom kvantberäkning är inte längre en teoretisk fråga, utan snarare ett överhängande hot mot klassisk kryptografi. Algoritmer som Shors, som kan faktorisera stora heltal och beräkna diskreta logaritmer exponentiellt snabbare än någon klassisk algoritm, hotar att förstöra algoritmer som RSA och ECC. Likaså leder användningen av Grovers algoritm till en försvagning av symmetrisk kryptering genom att effektivt halvera nyckelstyrkan, vilket hotar integriteten hos kryptografiska system som använder kortare nyckellängder. Konsekvenserna av dessa är betydande för grundläggande säkerhetsprotokoll som TLS, VPN, digitala signaturer och särskilt kodsignering.

Med detta i åtanke har den amerikanska nationella säkerhetsmyndigheten NSA (National Security Agency) introducerat och publicerat Commercial National Security Algorithm Suite 2.0 (CNSA 2.0). Denna kryptografiska ansträngning kräver användning av post-kvantkryptografi (PQC)-algoritmer för att säkra nationella säkerhetssystem (NSS) och sekretessbelagd kommunikation. CNSA 2.0 är inte bara en rekommendation, utan ett strategiskt skifte, backat upp av regeringens politik, som syftar till att stärka system mot både nuvarande och framtida kryptanalytiska kapacitet.

CNSA 2.0 namnger uttryckligen ML-KEM (för nyckelinkapsling) och ML-DSA (för digitala signaturer) efter behov, PQC-algoritmer, vilka båda valdes ut av NIST i dess PQC-standardiseringsprocess för sina starka säkerhets- och prestandaegenskaper. Dessa algoritmer är gitterbaserade och förlitar sig på matematiska problem som tros vara resistenta mot kvantattacker, till skillnad från RSA och ECC. I den här bloggen kommer vi att undersöka detaljerna i CNSA 2.0 och utforska dess algoritmiska grunder. Vi kommer också att visa hur Encryption Consultings kodsigneringslösning, CodeSign Secure, ger organisationer möjlighet att upprätthålla förtroende, integritet och efterlevnad i programvarudistribution när de övergår till postkvantum-eran.

Vad är CNSA 2.0?

CNSA 2.0, eller Commercial National Security Algorithm Suite 2.0, är den senaste sviten av kryptografiska algoritmer som föreskrivits av US National Security Agency (NSA) för att säkra nationella säkerhetssystem (NSS) i postkvantumeran. CNSA 2.0 släpptes i september 2022 och representerar ett betydande skifte i kryptografisk strategi, uttryckligen utformad för att förhindra risker från både klassiska och kvantummotståndare. Den ersätter de äldre CNSA 1.0- och Suite B-protokollen och anpassar nationella säkerhetskryptografiska standarder till moderna kvantummotståndskraftiga initiativ.

Till skillnad från NIST:s standardisering av Post-Quantum Cryptography (PQC), som syftar till att tillhandahålla algoritmer för allmän kommersiell användning, har NSA satt tydliga och brådskande förväntningar på övergången till PQC genom CNSA 2.0, särskilt i miljöer med hög tillförlitlighet som kodsignering. Sviten tvingar fram användningen av kvantresistenta algoritmer eftersom de erbjuder stark säkerhet även mot kvantberäkningskapacitet, och samtidigt fasar ut äldre algoritmer som RSA, DSA och finita-fälts DH. Oavsett om du leder produktsäkerhet, hanterar DevOps-pipelines, utformar kryptografiska system eller säkerställer regelefterlevnad, påverkar denna förändring dig.

Utforska vår djupgående blogg inlägg för att veta mer om CNSA 2.0 i detalj.

CNSA 2.0 kryptografiska algoritmer

För att hantera de dubbla utmaningarna med avancerade klassiska hot och framtida kvantmotståndare introducerar CNSA 2.0-sviten en uppsättning kryptografiska algoritmer enligt de olika användningsfallen inom nationella säkerhetssystem (NSS). Dessa algoritmer kategoriseras baserat på deras tillämpning, från programvaru- och firmwaresignering till allmän kryptografi med offentliga nycklar.

1. Algoritmer för signering av programvara och firmware

Ett av de viktigaste användningsområdena som omfattas av CNSA 2.0 är kodsignering. Kodsignering är processen att digitalt signera programvara, firmware eller uppdateringar för att bevisa att de är autentiska och inte har modifierats.

I takt med att PQC blir alltmer aktuellt utmärker sig hashbaserade signaturalgoritmer för sin mognad, sina säkerhetsgarantier och sitt NSA-godkännande under CNSA 2.0-sviten. Två primära algoritmer, Leighton-Micali Signature (LMS) och eXtended Merkle Signature Scheme (XMSS), utgör ryggraden i betrodd kodsignering för att skydda nationella säkerhetssystem (NSS) i en postkvantvärld.

Dessa algoritmer skiljer sig fundamentalt från traditionella RSA- och ECDSA-scheman. Medan de senare bygger på talteoretiska antaganden (t.ex. diskret logaritm- eller heltalsfaktoriseringsproblem), förlitar sig LMS och XMSS på säkerhetsegenskaperna hos kryptografiska hashfunktioner, såsom preimage-motstånd, kollisionsbeständighet och andra preimage-motstånd. Dessa egenskaper förblir motståndskraftiga mot kvantattacker även under Grovers algoritm, som endast erbjuder en kvadratisk hastighetsökning och därför ger den högsta säkerhetsnivån.

Både LMS och XMSS är tillståndskänsliga signaturscheman. Det innebär att varje signatur kräver unik intern tillståndsinformation som måste hanteras säkert och uppdateras atomiskt efter varje signaturoperation. Till skillnad från RSA eller ECDSA, där samma privata nyckel kan användas för att generera flera signaturer, är LMS/XMSS-nycklar knutna till ett fast antal giltiga signaturer. Detta beror på att återanvändning av ett nyckeltillstånd eller signering av två olika meddelanden med samma tillstånd kan äventyra säkerheten, vilket gör det möjligt för angripare att förfalska ytterligare signaturer.

I praktiken inför detta strikta krav på:

Skydd mot tillståndsbeständighet och återställning: Speciellt i inbyggda miljöer eller firmware-miljöer måste system förhindra återställning till ett tidigare signeringstillstånd (t.ex. på grund av strömavbrott eller systemkrascher).
Atomsigneringsoperationer: Detta avser detektering av eventuella avbrott under signering och möjligheten att återställa för att undvika återanvändning.
Granskningsloggning och spårning av nyckelanvändning: En signaturräknare måste underhållas och skyddas för att säkerställa integritet vid omstarter eller systemmigreringar.

LMS

LMS, ursprungligen utvecklat av Leighton och Micali, är optimerat för begränsade miljöer som bootloaders, smartkort och hårdvarusäkerhetsmoduler (HSM)Den använder en hierarkisk struktur av Merkle-träd där varje löv är associerat med en engångssignatur (OTS). Schemat stöder parameteruppsättningar som möjliggör avvägningar mellan prestanda, storlek och säkerhet.

Aspect	Detaljer
Signaturstorlek	1.2 KB – 3 KB
Prestanda	LMS är beräkningsmässigt snabbare än XMSS, vilket gör det attraktivt för signeringsoperationer i realtid på enheter med begränsad CPU eller minne.
Användningsfall	Idealisk för miljöer där säker och effektiv firmware-signering är avgörande (t.ex. IoT, BIOS/UEFI).

En av fördelarna med LMS är dess statslös verifierare modell. Detta innebär att verifieringsrutiner inte kräver att något tillstånd upprätthålls, vilket gör LMS-signaturer enkla att validera även i minimala miljöer som ROM-baserade bootloaders eller enheter med luftgap.

XMSS

XMSS, specificerat i RFC 8391, erbjuder fler funktioner jämfört med LMS och introducerar framåtriktad säkerhet med pseudoslumpmässig nyckelgenerering och valfri nyckelrandomisering. Det är lämpligt för användningsfall som kräver långsiktig kryptografisk säkerhet och mer sofistikerade nyckelhanteringsmekanismer.

Aspect	Detaljer
Signaturstorlek	Vanligtvis 2 KB till 5 KB, beroende på parameteruppsättningar och säkerhetsnivåer.
Säkerhetsfastighet	Ger framåtriktad säkerhet eftersom den använder ett binärt Merkle-träd med hashkedjor för att härleda engångsnycklar, vilket säkerställer att varje signatur förblir oförfalskbar även om något internt tillstånd läcker ut.
Användningsfall	Lämplig för miljöer med hög säkerhet som kräver starkt nyckelskydd.

XMSS beräkningskostnader är högre än LMS, vilket gör det mer lämpligt för system med högre säkerhet och starka bearbetningsmöjligheter, såsom servrar för firmwaresignering, säkra koddistributionstjänster eller PKI-infrastrukturer för företag som övergår till PQC.

Här är en snabb jämförelse för LMS och XMSS, två NIST SP 800-208 standardiserade, hashbaserade digitala signaturscheman utformade för säker firmware- och programvarusignering:

Algoritm	Funktion	Specifikation	Driftparametrar
Leighton-Micai Signature (LMS)	Asymmetrisk algoritm för digital signering av firmware och programvara	NIST SP 800-208	Alla parametrar är godkända för alla klassificeringsnivåer. SHA-256/192 rekommenderas.
eXtended Merkle Signature Scheme (XMSS)	Asymmetrisk algoritm för digital signering av firmware och programvara	NIST SP 800-208	Alla parametrar är godkända för alla klassificeringsnivåer.

2. Kvantresistenta algoritmer för offentlig nyckel

Med uppkomsten av kvantberäkningar anses traditionella publika nyckelsystem som RSA, DH, ECDSA och ECDH inte längre vara framtidssäkra. Som en del av CNSA 2.0-färdplanen har NSA definierat en uppsättning kvantresistenta publika nyckelalgoritmer för att vägleda framtida NSS-distributioner. Medan NIST:s slutgiltiga FIPS Standardisering för dessa algoritmer väntar, men NSA:s tidiga tillkännagivande gör det möjligt för utvecklare, leverantörer och NSS-operatörer att börja planera och bygga i enlighet därmed.

Eftersom algoritmer med offentlig nyckel är kärnan i kodsignering, digitala signaturer genererade med dessa algoritmer garanterar äktheten och integriteten hos programvara och firmware. Därför rekommenderar CNSA 2.0 specifikt ett omedelbart införande av hashbaserade signaturscheman, såsom Leighton-Micali Signature (LMS) och eXtended Merkle Signature Scheme (XMSS), för kodsignering. Dessa är redan standardiserade och godkända för användning i nationella säkerhetssystem (NSS).

Algoritm	Funktion	Specifikation	Driftparametrar
ML-KEM	Asymmetrisk algoritm för nyckeletablering	FIPS 203	Använd nivå V-parametrar för alla klassificeringsnivåer
ML-DSA	Asymmetrisk algoritm för digitala signaturer	FIPS 204	Använd nivå V-parametrar för alla klassificeringsnivåer

Anpassning av CNSA 2.0 i kodsigneringsmetoder

I takt med att kvantberäkningar utvecklas och blir mer praktiska står traditionella kryptografiska mekanismer, särskilt de som förlitar sig på RSA och ECC, inför existentiella risker på grund av sina sårbarheter. Kodsignering, en grundläggande del av säkerheten i programvaruleveranskedjan, är särskilt känslig för dessa förändringar. Det säkerställer att programvaru-, firmware- och konfigurationsuppdateringar kommer från en betrodd källa, inte manipuleras under transport och inte kan avvisas av signeraren.

Därför identifieras firmware-signering som det "högst prioriterade användningsfallet för signaturer" i post-kvantumövergången under CNSA 2.0. Brådskan härrör från det faktum att valideringsalgoritmen för firmware i många system är fast vid driftsättning, ofta belägen i oföränderlig hårdvara eller firmware på startnivå. De valda algoritmerna: LMS och XMSS, är redan standardiserade av NIST i specialpublikation 800-208, till skillnad från vissa andra post-kvantumsignaturer som fortfarande är under utvärdering, och NSA nämner uttryckligen behovet av omedelbar implementering av dessa post-kvantumsignaturscheman. Dessutom belyser CNSA 2.0 också vikten av NISTs nyligen godkända algoritmer, ML-KEM för nyckelutbyte och ML-DSA för signaturer, när de är helt standardiserade och stöds i hårdvara och programvara.

Navigera i CNSA 2.0-policy och algoritmisk efterlevnad för kodsignering

I takt med att NSA rekommenderar sin färdplan för övergången till kvantresistent kryptografi (QRC) genom CNSA 2.0, måste organisationer som bygger eller stöder nationella säkerhetssystem (NSS) nu anpassa sina kodsigneringsimplementeringar till en exakt uppsättning algoritmer och följa operativa begränsningar.

Även om CNSA 2.0 ger kryptografisk vägledning är det avgörande för kommersiella leverantörer att förstå hur man uppfyller policykrav, särskilt de som anges i CNSSP 15, NSM-10 och tillhörande CNSS/NIAP-dokumentation. Om din organisation utvecklar programvara eller firmware för NSS måste du därför inte bara använda rätt kryptografiska algoritmsvit (CNSA 2.0), utan också följa flera policyregler som utfärdats av olika säkerhetsmyndigheter.

Den kryptografiska ställning som krävs för en produkt, särskilt en som utför känslig kodsignering eller signaturvalidering, beror på dess klassificering och användningsfall.

För Typ 1-utrustning (vanligtvis används i sekretessbelagda eller taktiska system), styrs kryptografiska implementeringar av en trio av grundläggande dokument: CJCSN 6510.04, CNSSAM 01-07 och NSM-5 vägleder kryptografisk modernisering för taktiska och klassificerade system, och kräver uttryckligen kryptografiska algoritmer lämpliga för kodsigneringsoperationer som säkerställer säker firmware-autentisering och integritet.

Dessutom kräver dessa dokument tillsammans användning av CNSA 2.0-godkända kryptografiska verktyg och ger tydlig vägledning om när och hur de ska användas, särskilt i fall där firmware måste förbli säker och är svår att uppdatera när den väl är driftsatt.

På kommersiell sida, särskilt för leverantörer som strävar efter att betjäna NSS- eller NIAP-validerade (National Information Assurance Partnership)-miljöer, måste efterlevnaden vara i linje med de nämnda policydirektiven:

CNSSP 15: listar de godkända CNSA 2.0-algoritmerna som måste följas av kodsigneringsnycklar och -processer. Detta säkerställer att alla digitala signaturer på programvara som används i nationella säkerhetssystem (NSS) är tillräckligt starka för att motstå framtida kvantattacker.
CNSSP 11 och NSM-10: Dessa policyer kräver användning av kvantsäkra algoritmer som LMS och XMSS i era system och anger exakt när och var de ska användas (t.ex. för signering av firmware).
CNSSP 156: Denna policy definierar den officiella migreringsperioden (2025–2030) för att byta från gammal kryptografi (CNSA 1.0) till den säkrare CNSA 2.0-standarden, inklusive kryptografiska algoritmer som används specifikt för kodsignering, samtidigt som flexibilitet tillåts för system som är dyra eller svåra att uppgradera.

En viktig slutsats är att om ert system förväntas användas efter 2030 måste ni använda CNSA 2.0-godkända algoritmer från början. CNSA 1.0 är fortfarande acceptabelt för vissa äldre system, men endast där kortsiktig kryptografisk giltighet eller operativ genomförbarhet motiverar dess fortsatta användning.

Algoritmval för programvaru- kontra firmware-signering

NSA hanterar signering av programvara och firmware som separata användningsfall, vilka härrör från tre tekniska överväganden:

1. Standardmognad

Hashbaserade signaturalgoritmer, LMS och XMSS, standardiserades tidigare av NIST via SP 800-208 och har CAVP-validering tillgänglig, vilket gör dem till de nuvarande godkända alternativen för programvaru- och firmwaresignering under CNSA 2.0, medan andra kvantresistenta signaturer kanske inte är lika lättillgängliga för integration.

Dessa algoritmer är "tillståndskänsliga", vilket innebär att de kräver noggrann hantering av engångsnycklar. De är särskilt lämpliga för långsiktiga system som firmware i inbyggda eller begränsade enheter, där det kanske inte är praktiskt att uppdatera signaturprocessen senare. Eftersom LMS och XMSS redan är kommersiellt tillgängliga och validerade rekommenderar NSA att man använder dem nu snarare än att vänta på att nyare algoritmer blir tillgängliga.

ML-DSA, en statslös och gitterbaserad signaturalgoritm, är också godkänd enligt CNSA 2.0, men den är kanske inte lika lättillgänglig för integration. Även om den kan användas för alla signeringsanvändningsfall, inklusive programvara och firmware, förväntas den vara mer användbar i scenarier där ett stort antal signaturer behövs eller där signering sker i en distribuerad miljö. När ML-DSA väl har validerats blir den allmänt tillgänglig och kan vara det föredragna valet för många organisationer. All implementering av ML-DSA eller ML-KEM måste dock strikt följa FIPS 203 och 204 för att anses vara CNSA 2.0-kompatibel.

2. Brådskande karaktär

NSA har prioriterat firmwaresignering på grund av den djupt inbäddade naturen hos dess kryptografiska rötter, såsom rotcertifikat, publika nycklar eller säkra startnycklar, vilka ofta är hårdkodade i hårdvara och inte lätt kan uppdateras när de väl är driftsatta. Därför är det en brådskande och kritisk prioritet att säkra inbäddad firmware med kvantsäkra signaturer.

3. Prestandajustering

LMS/XMSS medför högre prestandakostnader (t.ex. större signaturstorlekar, långsammare drift), men firmware-signering är ovanlig och lokaliserad, vilket gör dem till idealiska val. Programvarumiljöer med hög genomströmning kan senare anta ML-DSA efter validering.

Därför godkänner NSA för närvarande endast LMS och XMSS för signering i NSS-miljöer. Flerträdsvarianter som HSS (Hierarchical Signature Scheme) och XMSSMT (XMSS Multi-Tree), som redan ingår i NIST SP 800-208, är ännu inte tillåtna för NSS, troligen på grund av komplexiteten i deras flerträdshantering.

Som en del av övergången till CNSA 2.0 förväntas leverantörer börja integrera signaturverifiering av LMS och XMSS i BIOS, UEFI och inbäddade bootloaders. Dessa hashbaserade signaturscheman erbjuder kvantbeständigt skydd och är för närvarande de enda PQC-algoritmerna som godkänts av NSA för användning i NSS.

Obs: Validerad ML-DSA kommer så småningom att bli den föredragna lösningen för miljöer med hög genomströmning och distribuerade signeringar på grund av dess tillståndslöshet, effektivitet och starka matematiska grund i strukturerade gitter.

NSA:s ståndpunkt är dock tydlig: övergången mellan LMS och XMSS måste börja nu, särskilt för användningsområden för firmware, med tanke på:

Den förväntade förseningen i ML-DSA-validering och verktygstillgänglighet,
De långa hårdvarulivscyklerna i kritiska NSS-system,
Alternativkostnaden för att vänta kan resultera i osäkra distributioner efter kvantumsförändringar som inte kan uppgraderas.

När ML-DSA har validerats kommer det att erbjuda operativa fördelar, inklusive:

Bättre skalbarhet över CI/CD-pipelines,
Förenklad nyckelhantering utan tillståndsspårning,
Minskad overhead för signaturstorlek jämfört med LMS/XMSS i vissa konfigurationer.

Mer om hashbaserade algoritmer

SHA-384 och SHA-512 i CNSA 2.0

CNSA 2.0 anger att SHA-2-valen (SHA-384 och SHA-512) är tillräckliga för säkerhet, och deras utbredda användning i den kommersiella världen säkerställer sömlös interoperabilitet mellan system. Den nämner SHA-384 som en godkänd hashfunktion för säkring, baserat på dess bevisade styrka och NSA:s interna analys, och SHA-512 har uttryckligen lagts till i CNSA 2.0 för scenarier där prestandaoptimeringar är avgörande. Detta beror på att dess 64-bitars ordstruktur är särskilt fördelaktig på fyra moderna 64-bitarsprocessorer, vilket ofta ger snabbare dataflöde med jämförbara säkerhetsgarantier.

Implementeringen av SHA-512 medför dock en viktig faktor, nämligen interoperabilitet. Vid integration av tredjepartssystem eller äldre system som använder SHA-384 som standard måste utvecklare säkerställa samordning mellan komponenter för att förhindra fel i signaturverifiering, HMAC-generering eller kompatibilitet med meddelandesammanfattningar.

Användning av andra hashfunktioner

Det finns särskilda villkor under vilka andra hashfunktioner är tillåtna:

Avkortade SHA-2-varianter (t.ex. SHA-256/192): När en kryptografisk algoritm (godkänd av NSA eller NIST) uttryckligen definierar användningen av sådana avkortade varianter i sin konstruktion. Till exempel i ett LMS är de tillåtna.
SHA-3-familjen (SHA3-384, SHA3-512): Även om de inte generellt är godkända för allmänt bruk av NSS, är dessa acceptabla i interna hårdvaruprocesser, såsom generering av slumptal eller nyckelhärledning inom chips.

Om till exempel en hårdvaruisolerad, säker exekveringsmiljö utför KDF-operationer (Key Derivation Function) internt med SHA3-512 utan att exponera hashen externt, faller detta inom acceptabla praxisgränser.

[eCBOM]

Viktiga överväganden vid integrering av LMS och XMSS i kodsigneringsarbetsflöden

I takt med att organisationer övergår till kvantsäker kodsignering med hjälp av hashbaserade signaturscheman som LMS (Leighton-Micali Signature) och XMSS (eXtended Merkle Signature Scheme), måste flera unika operativa utmaningar åtgärdas för att säkerställa säkerhet och arbetsflödeskontinuitet.

1. HSM-kompatibilitet

De flesta kommersiella HSM:er är optimerade för RSA eller ECDSA, vilka inte behöver hålla reda på något mellan signaturer. Men LMS och XMSS är olika, eftersom de kräver att signaturstatus (som räknare eller trädindex) bibehålls säkert i modulen. På grund av detta behöver många HSM:er firmwareuppdateringar eller speciella tillägg för att korrekt stödja dessa nya typer av signaturer. Därför framväxer stöd för LMS/XMSS och kräver ofta firmwareuppgraderingar eller specialiserade moduler. Utan detta kan nycklar hanteras utanför HSM:en, vilket gör dem mindre säkra.

2. Tillståndssynkronisering i distribuerade miljöer

I moderna DevOps och CI / CD-rörledningar, kodsignering är ofta distribuerad över flera noder eller servrar. LMS och XMSS tillståndskänsliga natur innebär att varje signatur förbrukar en unik del av den privata nyckelns signeringskapacitet, och återanvändning av tillståndsparametrar kan äventyra hela nyckeln. Detta kräver en noggrant samordnad strategi där signeringstillståndet konsekvent synkroniseras över alla signeringsnoder.

3. Säkra säkerhetskopior av tillstånd

Säkerhetskopiering av privata nycklar av LMS eller XMSS innebär mer komplexitet än traditionella nyckelsäkerhetskopior eftersom det aktuella signeringsläget (t.ex. signaturräknare eller Merkle-trädindex) måste bevaras korrekt och säkert. Säkerhetskopieringsprocessen måste vara manipulationssäker och motståndskraftig mot rollback- eller replay-attacker, eftersom återställning av ett föråldrat tillstånd kan leda till återanvändning av signaturer och äventyra säkerheten. Därför använder organisationer ofta anpassade verktyg eller säkra enklaver för att skydda denna känsliga tillståndsinformation och säkerställa att säkerhetskopior förblir konsekventa med pågående signeringsåtgärder.

HSM-integration för kvantsäker kodsignering

I takt med att organisationer börjar använda kvantresistenta digitala signaturer som LMS och XMSS, spelar hårdvarusäkerhetsmoduler (HSM) en avgörande roll för att upprätthålla säkerhet, efterlevnad och driftskontinuitet.

Till skillnad från traditionella kryptografiska algoritmer använder LMS och XMSS engångssignaturnycklar som härleds från en huvudnyckel (seed). Varje signatur måste använda en unik härledd nyckel, som spåras med hjälp av en säker räknare. HSM säkerställer att:

Ett begränsat antal signaturer genereras per nyckelpar
Regeln för engångsanvändning tillämpas via intern tillståndshantering
Härledda nycklar återanvänds inte eller exporteras felaktigt

Varje härledning av privata nyckelr är deterministisk och baserad på en räknare, vilket innebär att varje härledd privat nyckel endast kan producera en signatur. Detta unika krav ställer operativa krav på det kryptografiska systemet. HSM:er upprätthåller detta tillstånd internt och förhindrar obehöriga återställningar eller duplicering av signeringsmiljön, vilket annars skulle äventyra integriteten hos LMS/XMSS.

Hybridkryptografins roll

I takt med att cybersäkerhetsbranschen förbereder sig för postkvantum-eran har hybridkryptografiska lösningar, de som kombinerar klassiska algoritmer som RSA eller ECC med postkvantumkryptografiska (PQC) algoritmer, blivit en populär övergångsstrategi. Dessa lösningar syftar till att skydda data i både det nuvarande och framtida hotlandskapet.

Denna tvåskiktsmetod säkerställer att om en kraftfull kvantdator bryter mot en klassisk algoritm, så skyddar PQC-lagret fortfarande data. Om de nya PQC-algoritmerna å andra sidan uppvisar oväntade svagheter, fortsätter det klassiska lagret att erbjuda en viss skyddsnivå. Hybridkryptografi hjälper till att balansera risk och säkerhet medan PQC-standarder fortfarande testas och antas.

NSA kräver dock inte, genom sin CNSA 2.0-vägledning, hybridlösningar för nationella säkerhetssystem (NSS). Myndigheten har förtroende för styrkan hos de godkända PQC-algoritmerna och uppmuntrar en direkt övergång till dessa kvantsäkra standarder.

Med det sagt erkänner NSA att vissa branschstandarder tillfälligt kan kräva hybridimplementeringar, särskilt på grund av de större nyckel- och signaturstorlekarna hos PQC-algoritmer. Ändå varnar de för att hybridsystem kan medföra ökad komplexitet och kompatibilitetsproblem. Som ett resultat anses hybridkryptografi vara en tillfällig åtgärd, inte en långsiktig lösning.

Hur kan krypteringskonsulting hjälpa till?

Krypteringskonsulttjänster hjälper företag och myndigheter att implementera CNSA 2.0-anpassade signeringsinfrastrukturer med fullt stöd för PQC och hybridkrypto.

CodeSign Secure v3.02 stöder PQC direkt, vilket ger organisationer ett försprång i att anpassa sig till nästa era av kryptografi utan att offra användbarhet eller prestanda. Det är ett smart drag nu och ett nödvändigt sådant för framtiden.

Att gå över till CNSA 2.0 handlar inte bara om att välja rätt algoritm. Det handlar om att bygga en heltäckande kodsigneringsstrategi som skyddar nycklar, automatiserar arbetsflöden, upprätthåller policyer och säkerställer efterlevnad. Det är precis vad... CodeSign Secure byggdes för. 

Så här stöder CodeSign Secure CNSA 2.0: 

LMS- och XMSS-klar: Stöder redan de post-kvantumsigneringsscheman som krävs för signering av programvara och firmware.
HSM-backat nyckelskydd: Dina privata nycklar förblir skyddade inuti FIPS 140-2 nivå 3 HSM:er, vilket säkerställer ingen exponering.
Inbyggd tillståndsspårning: Hanterar automatiskt tillstånd för LMS och XMSS för att säkerställa att varje signatur är kompatibel.
DevOps-vänlig: Integreras direkt med Jenkins, GitHub Actions, Azure DevOps och mer.
Policydriven säkerhet: Använd RBAC, signeringar från flera godkännare (M of N) och anpassade säkerhetspolicyer för att kontrollera alla aspekter av din kodsignering.
Revisionsklar loggning: Få fullständig insyn i varje signeringsoperation för enkel rapportering och efterlevnad.

Oavsett om du signerar programvara för Windows, Linux, macOS, Docker, IoT-enheter eller molnplattformar, CodeSign Secure är redo att hjälpa dig att göra en säker och effektiv övergång. 

Slutsats

CNSA 2.0 är här, och det är mer än en rekommendation, det är en färdplan för att förbättra dina säkerhetsåtgärder. Om du arbetar med mjukvaruutveckling, infrastruktur eller efterlevnad är det dags att börja planera. 

Med CodeSign Secure får du de verktyg och den automatisering du behöver för att: 

Börja signera med CNSA 2.0-kompatibla algoritmer
Skydda dina nycklar och tillämpa strikta regler
Ligg steget före deadlines utan att sakta ner utvecklingen

Vill du se hur det fungerar?

Nå ut till oss kl info@encryptionconsulting.com för att boka en demo eller lära dig mer om hur CodeSign Secure kan hjälpa dig att hålla dig säker och efterleva reglerna.

Säkra framtiden för kodsignering med CNSA 2.0-efterlevnad och PQC