Den amerikanska säkerhetsmyndigheten NSA (National Security Agency) har officiellt släppt Commercial National Security Algorithm Suite 2.0 (CNSA 2.0). Detta är inte bara ytterligare en policyuppdatering; det är en allvarlig förändring i hur vi skyddar programvara, firmware och system mot den kommande vågen av kvantberäkningshot.
Om du ansvarar för mjukvaruutveckling, IT-säkerhet eller efterlevnad inom en myndighets-, försvars- eller kommersiell miljö, borde CNSA 2.0 vara på din radar. Låt oss gå igenom vad det innebär, vad som förändras och hur du kan ligga steget före utan att bli överväldigad.
CNSA 2.0 och kodsignering, kort sagt: signering av mjukvara och firmware har den tidigaste deadline i hela CNSA 2.0-sviten, föredra LMS/XMSS eller ML-DSA (FIPS 204) senast 2025, obligatoriskt senast 2030, långt före deadline 2035 för resten av nationella säkerhetssystem, eftersom signeringsnycklar för firmware är den svåraste komponenten att uppdatera när en enhet väl har levererats.
Key Takeaways
- ML-KEM (FIPS 203) och ML-DSA (FIPS 204) är slutgiltiga NIST-standarder från och med augusti 2024, inte kandidater i väntan på godkännande; namnen Kyber och Dilithium hänvisar till samma algoritmer före standardisering.
- ML-KEM hanterar nyckelupprättandet; det spelar ingen roll i kodsignering. Signering av programvara och firmware använder LMS, XMSS eller ML-DSA.
- Den här sidan fokuserar på de specifika förberedelseåtgärderna för kodsignering. För den fullständiga och uppdaterade migreringsarkitekturen och hybridsigneringsmönster, se Utformning av CNSA 2.0-övergångsstrategierna och Hybridkryptografi för CNSA 2.0-övergången.
Varför är CNSA 2.0 så viktigt?
Kvantberäkningar utvecklas snabbt, och när de når en viss tröskel kan de knäcka allmänt använda krypteringsmetoder som RSA och ECC . Det är därför NSA har lagt ut en tydlig väg för att övergå till kvantresistenta algoritmer för nationella säkerhetssystem och deras stödjande tekniker.
CNSA 2.0 introducerar nya kryptografiska standarder utformade för att motstå både klassiska och kvantattacker. Målet? Hjälpa organisationer att påbörja övergången nu, så att de är redo i god tid före deadline.
Vad finns i CNSA 2.0?
Här är en snabb översikt över vad som ändras:
1. Signering av programvara och firmware
För första gången rekommenderar CNSA 2.0 specifika kvantsäkra algoritmer enbart för signering av programvaru- och firmwareuppdateringar. Dessa är redan standardiserade, så du kan börja använda dem idag:
| Algoritm | Vad den är till för | Specifikation | Detaljer |
|---|---|---|---|
| LMS (Leighton-Micali Signature) | Signering av programvara och firmware | NIST SP 800-208 | SHA-256/192 föredras |
| XMSS (Xtended Merkle Signature Scheme) | Signering av programvara och firmware | NIST SP 800-208 | Alla parametrar godkända |
Dessa algoritmer är tillståndskänsliga, vilket innebär att de kräver noggrann nyckelspårning, men de är utmärkta alternativ för att säkra långsiktiga programuppdateringar.
2. Kryptografi med symmetrisk nyckel
Inte många förändringar här. NSA har precis lagt till SHA-512 till listan över godkända, vilket ger lite mer flexibilitet:
| Algoritm | Användningsfall | Specifikation | Rekommendation |
|---|---|---|---|
| AES | Datakryptering | FIPS PUB 197 | Använd 256-bitarsnycklar |
| SHA | hashing | FIPS PUB 180-4 | Använd SHA-384 eller SHA-512 |
3. Kvantresistenta algoritmer för offentlig nyckel
Dessa är slutgiltiga, publicerade NIST-standarder, inte kandidater som är under utformning. Kyber och Dilithium var namnen före standardiseringen; från och med augusti 2024 slutgiltigade NIST dem som FIPS 203 respektive FIPS 204, och det är dessa namn som kommer att användas framöver:
| Algoritm | Användningsfall | Specifikation | Detaljer |
|---|---|---|---|
| ML-KEM (tidigare CRYSTALS-Kyber) | Nyckeletablering (ej signering) | FIPS 203 | Använd ML-KEM-1024 (parametrar för nivå V/kategori 5) |
| ML-DSA (tidigare CRYSTALS-Dilithium) | Digitala signaturer | FIPS 204 | Använd ML-DSA-87 (parametrar för nivå V/kategori 5) |
Det är värt att vara tydlig med skillnaden mellan dessa två: ML-KEM upprättar en gemensam hemlighet mellan två parter och spelar ingen roll i signeringen av någonting. ML-DSA är det som producerar en signatur. Signering av programvara och firmware använder specifikt LMS, XMSS eller ML-DSA, aldrig ML-KEM.
Om du planerar i förväg är ML-DSA (eller LMS/XMSS specifikt för signering) de algoritmer du bör bygga in i dina system.
Tidslinje för CNSA 2.0: När behöver du agera?
Den fullständiga övergången förväntas vara avslutad senast 2035, men det finns milstolpar längs vägen beroende på vad du hanterar:
-
Programvaru- och firmwaresignering
- Börja nu
- Använd CNSA 2.0 senast 2025
- Obligatorisk senast 2030
-
Webbläsare, molntjänster
- Börja stödja CNSA 2.0 senast 2025
- Obligatorisk senast 2033
-
Nätverksutrustning (VPN, routrar)
- Stöd senast 2026
- Obligatorisk senast 2030
-
Operativsystem
- Stöd senast 2027
- Obligatorisk senast 2033
-
Nischenheter och äldre system
- Uppdatera eller ersätt senast 2033
Ju tidigare du börjar testa, desto smidigare blir din utrullning.
Efterlevnad och verkställighet: Vad du kan förvänta dig
Om du arbetar med nationella säkerhetssystem måste du visa framsteg som en del av dina bedömningar av riskhanteringsramverket (RMF). NSA kommer inte längre att acceptera enbart "FIPS-validerad" krypto för dessa miljöer; du måste använda NSA-godkända algoritmer och konfigurationer.
Revisionerna kommer att omfatta:
- NIAP-valideringar mot skyddsprofiler
- Rapportering om signeringsalgoritmer och nyckelhantering
- Verifiering av tillståndsspårning för LMS/XMSS
Hur CodeSign Secure kan hjälpa till?
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-klarStöder redan de post-kvantumsigneringsscheman som krävs för signering av programvara och firmware.
- HSM-stödd nyckelskyddDina privata nycklar förblir skyddade inom FIPS 140-2 nivå 3 HSM, vilket säkerställer ingen exponering.
- Inbyggd tillståndsspårningHanterar automatiskt tillstånd för LMS och XMSS för att säkerställa att varje signatur är kompatibel.
- DevOps-vänligIntegreras direkt med Jenkins, GitHub Actions, Azure DevOps med flera.
- Policydriven säkerhetAnvä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 loggningFå 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, är CodeSign Secure redo att hjälpa dig att göra en säker och effektiv övergång.
Vanliga frågor om partihandel med mat och dryck
Är ML-KEM och ML-DSA fortfarande utkast till standarder?
Nej. NIST slutfördes i augusti 2024, som FIPS 203 (ML-KEM) och FIPS 204 (ML-DSA). De är publicerade, slutgiltiga standarder, inte kandidater som väntar på urval.
Kan jag använda ML-KEM för att signera firmware?
Nej. ML-KEM är en nyckelinkapslingsmekanism för nyckelutbyte, inte en signaturalgoritm. Signering av firmware och programvara under CNSA 2.0 använder LMS, XMSS eller ML-DSA.
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?
Kontakta oss på [email protected] 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.
