Het ontwerpen van de transitiestrategieën voor CNSA 2.0

De Commercial National Security Algorithm Suite 2.0 ( CNSA 2.0 ) van de National Security Agency is de meest operationele routekaart die een overheid ooit heeft gepubliceerd voor het begeleiden van deze transitie. Waar National Security Memorandum 10 (NSM-10) de ambitieuze doelstelling stelt om nationale veiligheidssystemen tegen 2035 kwantumresistent te maken, vertaalt CNSA 2.0 die doelstelling naar concrete instructies: gebruik ML-KEM-1024 voor sleutelgeneratie, ML-DSA-87 voor digitale handtekeningen, ondersteun deze algoritmen in uw producten vóór specifieke data en stop met het gebruik van de oude algoritmen door anderen.

De deadlines liggen niet meer zo ver in de toekomst. De eerste deadline, die betrekking had op het ondertekenen van software en firmware, schreef voor dat organisaties tegen 2025 de voorkeur moesten geven aan CNSA 2.0-algoritmes, een mijlpaal die al is bereikt. Vanaf 1 januari 2027 moeten alle nieuwe aankopen voor nationale veiligheidssystemen CNSA 2.0-algoritmes ondersteunen.

Deze blog beschrijft de CNSA 2.0-algoritmesuite, het volledige transitietijdschema, de handhavingsmechanismen die deze deadlines bindend maken, en een praktische strategie in vijf fasen voor het ontwerpen van de migratie zonder uw bedrijfsvoering te verstoren.

Post-quantum code signing, gedefinieerd als: het ondertekenen van software en firmware met een algoritme dat bestand is tegen aanvallen door een quantumcomputer, momenteel ML-DSA (FIPS 204) of het stateful hash-gebaseerde LMS/XMSS (NIST SP 800-208), dat doorgaans naast een klassiek algoritme wordt uitgevoerd tijdens de overgang, zodat zowel huidige als nog niet geüpgrade verificatoren het artefact nog steeds kunnen valideren.

Key Takeaways

• ML-KEM (FIPS 203) en ML-DSA (FIPS 204) zijn niet uitwisselbaar: ML-KEM is een sleutelinkapselingsmechanisme voor het vaststellen van gedeelde geheimen, ML-DSA is een handtekeningalgoritme. Codeondertekening maakt gebruik van ML-DSA of LMS/XMSS, nooit van ML-KEM.
• FIPS 203, 204 en 205 zijn sinds augustus 2024 definitieve NIST-standaarden; NIST SP 800-208 (LMS/XMSS) is dat sinds 2020. Wat nog steeds inconsistent is, is de ondersteuning door het ecosysteem, de HSM-firmware, certificeringsinstanties en verificatietools voor digitale handtekeningen.
• Een enkel, gecombineerd "samengesteld" post-kwantum/klassiek handtekeningformaat voor X.509 is nog steeds een IETF Internet-Draft (draft-ietf-lamps-pq-composite-sigs, nog geen RFC in 2026); het huidige praktische hybride patroon voor codeondertekening bestaat uit dubbele, parallelle, losgekoppelde handtekeningen, niet uit een samengestelde handtekening.
• De compatibiliteit van de verificator, en niet de mogelijkheden van de ondertekenaar, is meestal het echte knelpunt: een artefact kan vandaag de dag wel met ML-DSA worden ondertekend, maar alleen worden geverifieerd door platforms die er ondersteuning voor hebben toegevoegd.
• Software- en firmwareondertekening valt onder de vroegste deadline van CNSA 2.0 (ondersteuning en voorkeur: 2025, reeds verstreken); zie het onderstaande overgangsschema met datums voor alle andere systeemcategorieën.

Wat CNSA 2.0 is en waarom het bestaat.

CNSA 2.0 is de richtlijn van de NSA voor cryptografische algoritmen ter bescherming van nationale veiligheidssystemen (NSS). Deze systemen omvatten geclassificeerde en niet-geclassificeerde systemen die nationale veiligheidsinformatie, militaire commandovoering en -controle, inlichtingen en aanverwante functies verwerken. De richtlijn werd voor het eerst aangekondigd op 7 september 2022 en bijgewerkt naar versie 2.1 in december 2024, nadat NIST in augustus 2024 de definitieve FIPS-standaarden voor het post-kwantumtijdperk had gepubliceerd.

Het bestaan ​​van CNSA 2.0 komt neer op één enkele, goed begrepen dreiging. De publieke-sleutelalgoritmen die tegenwoordig in bijna alle systemen worden gebruikt, RSA en elliptische-curve-cryptografie ( ECC ), zijn gebaseerd op wiskundige problemen die klassieke computers binnen een redelijke tijd niet kunnen oplossen. Een voldoende krachtige kwantumcomputer die het algoritme van Shor uitvoert, kan diezelfde problemen efficiënt oplossen, waardoor RSA- en ECC-handtekeningen en sleuteluitwisselingen onveilig worden.

Dit brengt twee verschillende risico's met zich mee. Het eerste is toekomstgericht: zodra er een cryptografisch relevante kwantumcomputer ( CRQC ) bestaat, is elk systeem dat nog steeds afhankelijk is van RSA of ECC direct kwetsbaar. Het tweede risico speelt zich nu af: tegenstanders onderscheppen en archiveren nu al versleutelde gegevens en ondertekende communicatie, met de bedoeling deze te decoderen of te vervalsen zodra een CRQC beschikbaar komt. Dit is de "Nu verzamelen, later decoderen"-dreiging, en het betekent dat gegevens met vertrouwelijkheidsvereisten die verder reiken dan de periode waarin een CRQC beschikbaar komt, nu al risico lopen, ongeacht hoe sterk de huidige encryptie ook lijkt.

CNSA 2.0 vervangt de eerdere CNSA 1.0- suite, die gebaseerd was op RSA, ECDH, ECDSA en AES. CNSA 2.0 behoudt de symmetrische en hash-primitieven die kwantumresistent blijven en vervangt de voor kwantumaanvallen kwetsbare publieke-sleutelalgoritmen door NIST-gestandaardiseerde post-kwantumalternatieven.

CNSA 2.0 Algoritmesuite

CNSA 2.0 specificeert exacte algoritmen en, cruciaal, exacte parameterreeksen voor elk gebruiksscenario. Een van de bepalende kenmerken van de suite is dat deze alleen de hoogste NIST- beveiligingsniveaus verplicht stelt. Lagere parameterreeksen, hoewel NIST deze heeft gestandaardiseerd en goedgekeurd voor algemeen gebruik, zijn niet toegestaan ​​voor nationale veiligheidssystemen.

Functie	CNSA 2.0-algoritme	Standaard	Notes
Sleutel Vestiging	ML-KEM-1024	FIPS203	Voorheen CRYSTALS-Kyber; alleen NIST-beveiligingsniveau 5. ML-KEM-512 en ML-KEM-768 zijn niet goedgekeurd voor NSS.
Digitale handtekeningen (algemeen)	ML-DSA-87	FIPS204	Voorheen CRYSTALS-Dilithium; alleen de hoogste parameter ingesteld. ML-DSA-44 en ML-DSA-65 zijn niet toegestaan ​​voor NSS. Gebruikt voor alle ondertekening, inclusief software en firmware.
Software- en firmware-ondertekening	LMS of XMSS	NIST SP 800-208	Statusgebaseerde hash-handtekeningen. De NSA beveelt LMS met SHA-256/192 aan. ML-DSA-87 is ook goedgekeurd voor dit gebruik.
Symmetrische encryptie	AES-256	FIPS197	Overgenomen van CNSA 1.0; kwantumresistent bij een sleutellengte van 256 bits.
Hashing	SHA-384 of SHA-512	FIPS 180-4	CNSA 2.0 heeft SHA-512 toegevoegd als goedgekeurde optie naast SHA-384.

Status van de normen: Wat is definitief en wat is nog in ontwikkeling?

Niet alles wat als "post-quantum" wordt bestempeld, bevindt zich in hetzelfde stadium van ontwikkeling, en het verwarren van een afgeronde algoritmestandaard met een ecosysteemfunctie die nog in ontwikkeling is, is een van de meest voorkomende planningsfouten. Het is nuttig om de algoritmestandaard zelf te scheiden van de omringende infrastructuur die zich daaraan moet aanpassen.

Item	Status	Sinds / Notities
FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA)	Definitieve NIST-normen	Gepubliceerd augustus 13, 2024
NIST SP 800-208 (LMS, XMSS)	Definitieve NIST-aanbeveling	Gepubliceerd oktober 2020
Samengestelde (enkelvoudige, gecombineerde) post-kwantum/klassieke signaturen voor X.509	IETF Internet-Draft, nog geen RFC	draft-ietf-lamps-pq-composite-sigs, actief herzien tot en met 2026; bouw geen productiesystemen uitgaande van een stabiel draadformaat.
HSM-firmwareondersteuning voor FIPS 203/204/205 en SP 800-208	Ongelijkmatig, leverancier- en modelspecifiek	Grote leveranciers leverden de eerste ondersteuning in de firmware-updates van 2025 tot 2026; controleer dit per model, ga er niet zomaar vanuit.
Ondersteuning voor openbare codeondertekenings-CA's voor ML-DSA/LMS-certificaatprofielen	Beperkt en nog in ontwikkeling	Neem contact op met uw certificeringsinstantie voordat u ervan uitgaat dat er momenteel een publiekelijk erkend PQC-codeondertekeningscertificaat beschikbaar is.
Verificatie van besturingssysteem- en platformsignaturen (bijv. Authenticode-achtige verificatie)	Erkent PQC-handtekeningen nog grotendeels niet.	Daarom is het ondertekenen met twee parallelle handtekeningen tegenwoordig de gangbare praktijk, en geen vervanging van de klassieke handtekening.

Overgangstijdlijn

CNSA 2.0 definieert twee mijlpalen voor elke systeemcategorie: een "ondersteunings- en voorkeursdatum", waarna systemen in staat moeten zijn om CNSA 2.0-algoritmen te gebruiken en deze standaard moeten toepassen, en een "exclusieve gebruiksdatum", waarna CNSA 1.0-algoritmen niet langer zijn toegestaan. Het schema is bewust gespreid, waarbij de categorieën die na implementatie het moeilijkst te updaten zijn, vooraan worden geplaatst.

Systeemcategorie	Ondersteunen en de voorkeur geven	Uitsluitend gebruik
Software- en firmware-ondertekening	2025 (geslaagd)	2030
Netwerkapparatuur (VPN's, routers)	2026	2030
Besturingssystemen	2027	2033
Webbrowsers, servers, cloudservices	2025 (geslaagd)	2033
Niche- en legacy-apparatuur	Bijwerken of vervangen vóór 2033	2033
Alle NSS (volledige transitie)	Lopend	2035 (volgens NSM-10)

Waarom het ondertekenen van software en firmware de vroegste deadline heeft

Het is geen toeval dat de ondertekening van software en firmware de vroegste deadline voor "ondersteuning en voorkeur" heeft in het gehele CNSA 2.0-schema. Daar is een specifieke architectonische reden voor: de vertrouwensbasis van de firmware is het moeilijkst bij te werken nadat een apparaat in gebruik is genomen.

Bij de fabricage van een apparaat worden de verificatiesleutels voor de firmware vaak in de hardware ingebed, soms zelfs in de chipset zelf, op een manier die later niet meer kan worden gewijzigd. Als die sleutels gebaseerd zijn op een kwantumkwetsbaar algoritme, blijft het apparaat gedurende zijn hele levensduur kwetsbaar. Voor apparaten met een levensduur van tientallen jaren, zoals militaire hardware, industriële controllers en embedded systemen, kan een vandaag gekozen ondertekeningssleutel nog steeds in gebruik zijn lang nadat een CRQC (Creative Reference Quality Control) niet meer nodig is.

Dit creëert een cumulatief risico dat specifiek is voor firmware. Een aanvaller die de ondertekeningssleutel kan achterhalen, hetzij uit gearchiveerd ondertekeningsverkeer, hetzij door het algoritme direct te kraken met een CRQC, zou kwaadaardige firmware kunnen ondertekenen die door elk apparaat als legitiem wordt geaccepteerd. Omdat firmware zich onder het besturingssysteem en onder alle beveiligingsmaatregelen op softwareniveau bevindt, is een vervalste firmware-ondertekening een van de gevaarlijkste aanvallen die mogelijk zijn.

Daarom heeft de NSA leveranciers al sinds het oorspronkelijke advies uit 2022 aangespoord om direct te beginnen met de implementatie van LMS en XMSS, ruim vóór de bredere overgang. Stateful hash-gebaseerde handtekeningen zoals LMS en XMSS zijn goed bekend, hanteren conservatieve beveiligingsveronderstellingen en zijn bestand tegen kwantumaanvallen. Ze zijn bijzonder geschikt voor gebruik in firmware, waar de ondertekeningsbewerking zelden voorkomt en gecontroleerd wordt uitgevoerd, wat de operationele complexiteit van het beheren van stateful sleutels vermindert.

Voor organisaties die producten ontwikkelen met firmware, betekent dit in de praktijk dat de infrastructuur voor digitale handtekeningen als eerste moet worden gemigreerd. Het apparaat dat u vandaag de dag levert met klassieke digitale handtekeningen, is het apparaat dat deze kwetsbaarheid ook in de jaren 2030 en daarna zal blijven vertonen. Voor de specifieke formaten die een platform voor digitale handtekeningen moet ondersteunen voor al die apparaten, zie We Counted Every Format CodeSign Secure Can Sign ; voor meer informatie over hoe de keuze van algoritmes samenhangt met de herkomst van de code, zie Strengthening Supply Chain Security with SLSA Level 3 and Code Signing.

Hybride en parallelle ondertekeningspatronen

De term 'hybride ondertekening' wordt vaak onnauwkeurig gebruikt, en het onderscheid tussen de twee daadwerkelijke betekenissen is belangrijk voor wat je tegenwoordig kunt implementeren.

Dubbele, parallelle, losgekoppelde handtekeningen vormen momenteel het praktische model: het artefact wordt tweemaal ondertekend, eenmaal met een klassiek algoritme (RSA of ECDSA) en eenmaal met een post-kwantumalgoritme (ML-DSA of LMS). Beide handtekeningen worden samen met het artefact verzonden als afzonderlijke, onafhankelijke handtekeningblokken. Een verificator die alleen het klassieke algoritme begrijpt, controleert die handtekening en negeert de handtekening die hij niet herkent; een verificator die is bijgewerkt om de post-kwantumhandtekening te begrijpen, kan beide controleren. Geen van beide handtekeningen is afhankelijk van de andere, en dat is precies de reden waarom dit model werkt in het huidige landschap van gemengde, gedeeltelijk geüpgrade verificatoren.

Samengestelde handtekeningen , een enkele cryptografische handtekening die een klassiek en een post-kwantumalgoritme wiskundig combineert tot één waarde, vormen een andere en nauwer geïntegreerde aanpak, en zijn nog geen definitieve standaard voor X.509-gebruik. De relevante specificatie, draft-ietf-lamps-pq-composite-sigs, is in 2026 nog steeds een IETF Internet-Draft en wordt nog steeds herzien; het is nog geen RFC. Het bouwen van productietools voor een onvoltooide wire-indeling brengt het risico met zich mee dat certificaten opnieuw moeten worden ondertekend of uitgegeven zodra de indeling stabiel is. Specifiek voor codeondertekening zijn dubbele parallelle handtekeningen momenteel de minst risicovolle keuze; samengestelde handtekeningen zijn het volgen waard, maar nog niet voldoende om er volledig op te vertrouwen.

Migratieafhankelijkheden

Een CNSA 2.0-ondertekeningsmigratie kent een echte volgorde van afhankelijkheden, en het starten in een andere volgorde is een veelvoorkomende manier om een ​​pilotproject te laten vastlopen op een probleem dat helemaal niet met ondertekening te maken had.

1. De firmware of hardware van de HSM moet eerst worden gecontroleerd en, indien nodig, worden bijgewerkt om te bevestigen of het beoogde algoritme (ML-DSA, LMS of XMSS) wordt ondersteund; u kunt geen sleutels genereren of gebruiken die de HSM niet ondersteunt.
2. Vervolgens komt de ondersteuning voor certificeringsinstanties en certificaatprofielen aan bod, als de toepassing überhaupt een certificaat vereist (voor het ondertekenen van LMS/XMSS-firmware worden vaak ingebedde publieke sleutels gebruikt). Controleer of uw certificeringsinstantie een certificaat kan uitgeven dat het algoritme codeert dat u wilt gebruiken, voordat u ervan uitgaat dat dit mogelijk is.
3. Ondersteuning voor de toolchain voor digitale handtekeningen en CI/CD-integratie is vereist. De pipeline moet het nieuwe algoritme kunnen aanroepen via uw platform voor digitale handtekeningen of de HSM API.
4. De verificatie en platformondersteuning worden als laatste gecontroleerd, maar moeten conceptueel eerst worden geëvalueerd: als de systemen die de handtekening controleren het nieuwe algoritme niet herkennen, is dubbele ondertekening geen optie, maar de enige manier om het artefact bruikbaar te houden.
5. Een proefimplementatie is pas zinvol als alle vier de factoren bevestigd zijn; zie de fasen van de transitiearchitectuur hieronder.

Verificatiecompatibiliteit

Dit is de beperking die in de meeste transitieplannen onderschat wordt. Een artefact kan vandaag de dag correct ondertekend worden met ML-DSA of LMS, maar die handtekening is alleen bruikbaar als iets aan de andere kant deze kan verifiëren. De gangbare verificatie op besturingssysteemniveau, zoals die van Authenticode, herkent op het moment van schrijven geen post-quantum handtekeningen; de klassieke handtekening op een dubbel ondertekend artefact is wat de meeste ingezette verificatoren in de nabije toekomst daadwerkelijk zullen controleren. Interne of aangepaste verificatietools die u beheert, kunnen worden bijgewerkt om de post-quantum handtekening expliciet te controleren. Daarom dient dubbele ondertekening vandaag de dag twee verschillende doelgroepen tegelijk: externe, ongewijzigde verificatoren krijgen de klassieke handtekening die ze al kennen, en interne of toekomstgerichte verificatiesystemen kunnen daarnaast de post-quantum handtekening valideren voor echte quantumresistente zekerheid. Bevestig, in plaats van aan te nemen, in welke categorie elk van uw daadwerkelijke verificatoren valt voordat u een pilot als representatief voor de productieomgeving beschouwt.

Transitiearchitectuur

Een CNSA 2.0-migratie is geen eenmalig project met een vast eindpunt. Het is een meerjarig programma dat betrekking heeft op cryptografische inventaris, infrastructuur, ondertekeningsprocessen en governance. De volgende strategie in vijf fasen biedt een gestructureerd traject dat organisaties kunnen aanpassen aan hun eigen omvang en tijdschema.

Fase 1: Cryptografische ontdekking en inventarisatie

Je kunt cryptografie niet migreren als je die niet hebt geïdentificeerd. De eerste en meest fundamentele fase is het opstellen van een complete inventaris van alle plaatsen binnen de organisatie waar klassieke cryptografie wordt gebruikt: elk certificaat, elke ondertekeningssleutel, elk TLS-eindpunt en elke ingebedde cryptografische afhankelijkheid in software en hardware.

CBOM Secure van Encryption Consulting helpt uw ​​organisatie bij het inventariseren van elk cryptografisch element, inclusief het gebruikte algoritme en de bijbehorende parameters, de implementatielocatie, de afhankelijkheden, de eigenaar en het vervangingspad. Cryptografische afhankelijkheden bevinden zich vaak op moeilijk te herkennen plaatsen: bibliotheken van derden, configuraties van hardwarebeveiligingsmodules, verouderde applicaties en producten van leveranciers waarvan de interne werking niet zichtbaar is.

Fase 2: Prioritering en risicobeoordeling

Met een complete inventarisatie is de volgende fase het prioriteren van de migratie op basis van risico en deadline. De CNSA 2.0-tijdlijn biedt de structuur voor de deadlines, maar organisaties moeten daar bovenop hun eigen risicobeoordeling uitvoeren.

De belangrijkste activa zijn die welke een vroege CNSA 2.0-deadline combineren met een langdurige blootstelling. Firmware-ondertekeningssleutels voor apparaten met een levensduur van tientallen jaren staan ​​bovenaan deze lijst: ze hebben de vroegste deadline en de langste blootstellingsperiode. Gegevens en handtekeningen die informatie beschermen met lange vertrouwelijkheids- of integriteitsvereisten komen daarna, vanwege de dreiging van 'Nu verzamelen, later decoderen'. Minder belangrijke activa zijn die met een korte levenscyclus en latere deadlines, waarbij wachten op meer geavanceerde tools weinig risico met zich meebrengt.

Fase 3: Infrastructuur en gereedheid van de benodigde tools

Fase 3 bereidt de infrastructuur voor die nodig is voor de CNSA 2.0-activiteiten. De centrale vraag voor de meeste organisaties is de gereedheid van de HSM . CNSA 2.0 vereist dat sleutels worden beschermd in gevalideerde hardware, en de meeste oudere HSM's hebben firmware-updates nodig om ML-KEM, ML-DSA, LMS en XMSS te ondersteunen.

Voor elke HSM in de omgeving moeten organisaties bij de leverancier navragen of de huidige firmware de generatie, opslag en ondertekening van CNSA 2.0-sleutels ondersteunt; of de firmware kan worden bijgewerkt om ondersteuning toe te voegen of dat hardwarevervanging nodig is; en wat de verwachte releasedatum is voor firmware die voldoet aan FIPS 203, 204 en 205. Grote leveranciers zoals Thales Luna, Entrust nShield en Utimaco hebben CNSA 2.0-ondersteuning uitgebracht in firmware-updates voor 2025 en 2026, maar de ondersteuning verschilt per model en moet worden geverifieerd in plaats van aangenomen.

In deze fase wordt ook gecontroleerd of ondertekeningstoolchains, CI/CD-pipelines , certificeringsinstanties en verificatiesystemen CNSA 2.0-handtekeningen kunnen genereren en valideren.

HSM-gereedheidschecklist

• Bevestig per model of de huidige firmware ML-DSA en/of LMS/XMSS-sleutelgeneratie en -ondertekening ondersteunt, en beperk u niet tot een algemene roadmap-verklaring van de leverancier.
• Er is vastgesteld of een firmware-update de benodigde ondersteuning biedt of dat hardwarevervanging vereist is, en er is een specifieke streefdatum van de leverancier verkregen.
• De prestaties van de HSM zijn geverifieerd met de nieuwe algoritmen; grotere sleutels en handtekeningen kunnen de doorvoer beïnvloeden op manieren die het waard zijn om te meten voordat een implementatietijdlijn wordt vastgesteld.
• Bevestigd is dat het beheer van de status crashbestendig is, met name voor LMS/XMSS, aangezien een verloren of teruggedraaide ondertekeningsstatus de sleutel volledig in gevaar kan brengen.
• Gecontroleerd of het ondertekeningsplatform of de CI/CD-plugin die voor de HSM draait daadwerkelijk is bijgewerkt om het nieuwe algoritme aan te roepen, en niet alleen of de HSM zelf het ondersteunt.

Fase 4: Hybride implementatie en pilot

De aanbevolen aanpak tijdens de transitie is een hybride implementatie in plaats van een onmiddellijke, volledige vervanging. Hybride ondertekening en hybride sleuteluitwisseling maken parallel gebruik van zowel een klassiek algoritme als een CNSA 2.0-algoritme, zodat systemen die post-kwantumverificatie aankunnen, kwantumresistente bescherming krijgen, terwijl legacy-systemen die nog niet zijn gemigreerd, blijven functioneren.

Fase 4 brengt dit in de praktijk door middel van pilotimplementaties. Begin met een gecontroleerde productlijn of systeem met een lager risico, implementeer hybride ondertekening of hybride sleuteluitwisseling en valideer of de artefacten en verbindingen correct werken binnen de volledige reeks verificatie-infrastructuren waarmee ze te maken krijgen. Dit is waar de randgevallen aan het licht komen: verificatietools die CNSA 2.0-handtekeningen nog niet begrijpen, prestatieproblemen door grotere sleutel- en handtekeninggroottes en integratieproblemen in de ondertekeningspipeline. Het oplossen hiervan in een pilot is veel goedkoper dan ze in productie te ontdekken.

Fase 5: Volledige migratie en ontmanteling van de oude systemen

In de laatste fase wordt de gevalideerde aanpak opgeschaald naar de volledige omgeving en wordt de klassieke cryptografie geleidelijk uitgefaseerd. Naarmate de verificatie-infrastructuur volwassener wordt en de ondersteuning voor CNSA 2.0 universeel wordt in alle systemen van de organisatie, kan het klassieke component van hybride implementaties worden uitgefaseerd volgens de deadlines voor "exclusief gebruik" in het CNSA 2.0-schema.

Deze fase omvat ook het buitenbedrijf stellen of vervangen van de specialistische en verouderde apparatuur die niet ter plaatse kan worden gemigreerd. CNSA 2.0 verwacht dit tegen 2033 te hebben aangepakt. Dit zijn vaak de meest arbeidsintensieve veranderingen en moeten ruim voor de deadline worden gepland.

Testen en validatie

Naast de pilot die in Fase 4 is beschreven, verdienen een aantal specifieke controles expliciete testdekking voordat een product met dubbele ondertekening op grote schaal wordt uitgebracht:

• Controleer het artefact met elke verificator die het daadwerkelijk in productie zal tegenkomen, niet alleen met degene die tijdens de ontwikkeling is gebruikt, aangezien het gedrag van een verificator bij een niet-herkende extra handtekening niet gegarandeerd identiek is op alle platformen.
• Meet de impact van grotere post-kwantumsleutels en -handtekeningen op de omvang van artefacten, de downloadtijd en elk distributiekanaal met beperkingen qua omvang (met name ingebouwde update-mechanismen).
• Controleer de compatibiliteit van de tijdstempel; een betrouwbare tijdstempel moet geldig en verifieerbaar blijven, ongeacht aan welk ondertekeningsalgoritme deze is gekoppeld.
• Test de doorvoer van ondertekeningstaken onder het nieuwe algoritme bij een hoog releasevolume, aangezien ML-DSA en LMS/XMSS andere prestatiekarakteristieken hebben dan RSA of ECDSA.

Rollback

Omdat dubbele, parallelle ondertekening een tweede, onafhankelijke handtekening toevoegt in plaats van de eerste te vervangen, is terugdraaien tijdens de pilot- en vroege uitrolfases relatief risicoarm: als de toegevoegde post-quantum handtekening ergens in het veld een onverwachte verificatiefout veroorzaakt, is de klassieke handtekening nog steeds aanwezig en geldig. De oplossing is dan om te stoppen met het toevoegen van de tweede handtekening voor die artefactstroom totdat de incompatibiliteit is opgelost, en niet om iets opnieuw uit te geven of in te trekken. De situatie is anders wanneer een omgeving de datum van "exclusief gebruik" bereikt en de klassieke handtekening daadwerkelijk is verwijderd; op dat moment betekent terugdraaien het tijdelijk opnieuw inschakelen van dubbele ondertekening terwijl de onderliggende verificatiekloof wordt gedicht. Dit is nog een reden om de klassieke handtekening niet volledig uit te faseren totdat de verificatiedekking is bevestigd bij elke gebruiker van het artefact, en niet wordt aangenomen.

Hoe encryptieconsultancy kan helpen

De transitie naar CNSA 2.0 omvat cryptografische ontdekking, infrastructuurgereedheid, ondertekeningsprocessen en langetermijnbeheer. Het productportfolio en de adviesdiensten van Encryption Consulting zijn ontworpen om organisaties in elke fase van dit traject te ondersteunen.

PQC Advisory Services : Onze post-kwantum cryptografische adviesdiensten bieden de strategische basis voor een CNSA 2.0-migratie. We helpen organisaties hun huidige cryptografische positie te beoordelen, een migratieplan op te stellen dat is afgestemd op de CNSA 2.0-tijdlijn, activa te prioriteren op basis van risico en deadline, en een crypto-agile architectuur te ontwerpen die zowel deze als toekomstige transities beheersbaar maakt.

CBOM Secure : Fase 1 van elke CNSA 2.0-migratie is ontdekking, en je kunt niet migreren wat je niet kunt zien. CBOM Secure voert continue cryptografische ontdekking uit in je gehele omgeving en bouwt zo een complete, actuele inventaris op van certificaten, sleutels en cryptografische afhankelijkheden waarop de migratie is gebaseerd. Het identificeert precies welke assets kwantumkwetsbare algoritmen gebruiken en onder de CNSA 2.0-transitie moeten worden gebracht, waardoor de fundamentele ontdekkingsfase verandert van een handmatige, foutgevoelige oefening in een geautomatiseerde, herhaalbare procedure.

CodeSign Secure : Omdat het ondertekenen van software en firmware de vroegste deadline van CNSA 2.0 heeft, moeten veel organisaties als eerste actie ondernemen op het gebied van de ondertekeningsinfrastructuur. CodeSign Secure ondersteunt de CNSA 2.0-ondertekeningsalgoritmen in productie: ML-DSA op de vereiste parameterniveaus en LMS voor firmwareondertekening, allemaal ondersteund door FIPS-gevalideerde HSM's van Thales, Entrust, Utimaco en Securosys. Het platform zorgt ook voor de sleutelbescherming, op rollen gebaseerde toegangscontrole en auditregistratie die NSS-ondertekeningsgovernance vereist.

Conclusie

CNSA 2.0 is de meest concrete en operationeel specifieke routekaart voor de migratie naar de periode na de kwantumcomputers die ooit door een overheid is gepubliceerd. Het document noemt exacte algoritmen, exacte parameterreeksen en exacte data, en ondersteunt deze data met handhavingsmechanismen die naleving tot een voorwaarde maken voor validatie, certificering en inkoop.

De organisaties die deze transitie succesvol zullen doorstaan, zijn degenen die het beschouwen als een gestructureerd, meerjarig programma: het in kaart brengen van hun cryptografische inventaris, het prioriteren op basis van risico en deadline, het voorbereiden van hun infrastructuur, het implementeren van hybride benaderingen tijdens de transitie en het bouwen aan crypto-flexibiliteit, zodat de volgende cryptografische verandering veel minder pijnlijk is dan deze. De infrastructuur voor digitale handtekeningen, met zijn vroege deadline en lange blootstellingsperiode, is een goede plek om te beginnen.

Bij Encryption Consulting zijn onze adviesdiensten en productportfolio, van CBOM Secure voor ontdekking tot CodeSign Secure voor CNSA 2.0-ondertekening, ontworpen om u te ondersteunen tijdens het hele traject, van de eerste inventarisatie tot de uiteindelijke ontmanteling. Als uw organisatie de gereedheid voor CNSA 2.0 beoordeelt, helpen we u graag bij het uitstippelen van het juiste traject.

Veelgestelde Vragen / FAQ

Is ML-KEM hetzelfde als ML-DSA?

Nee. ML-KEM (FIPS 203) is een sleutelinkapselingsmechanisme dat wordt gebruikt om een ​​gedeeld geheim voor encryptie vast te stellen; ML-DSA (FIPS 204) is een digitaal handtekeningalgoritme. Ze lossen verschillende problemen op en zijn niet uitwisselbaar. Codeondertekening maakt gebruik van ML-DSA of het stateful hash-gebaseerde LMS/XMSS, nooit van ML-KEM.

Wat is het verschil tussen hybride en samengestelde post-kwantumsignaturen?

Hybride, zoals dat tegenwoordig wordt toegepast, betekent twee onafhankelijke, parallelle handtekeningen, een klassieke en een post-kwantum, die aan hetzelfde artefact zijn gekoppeld. Samengesteld betekent een enkele handtekeningwaarde die beide algoritmen wiskundig combineert; de relevante IETF-specificatie voor samengestelde ML-DSA-handtekeningen is in 2026 nog steeds een internetconcept en geen definitieve RFC.

Kunnen de huidige systemen voor het verifiëren van digitale handtekeningen een ML-DSA- of LMS-handtekening controleren?

Het hangt volledig af van de specifieke verificator. De gangbare Authenticode-achtige verificatiemethoden op besturingssysteemniveau herkennen post-quantum handtekeningen grotendeels nog niet. Daarom is dubbele ondertekening, waarbij de klassieke handtekening naast de nieuwe wordt bewaard, een praktischere aanpak dan de klassieke handtekening volledig te vervangen.

Welke HSM's ondersteunen momenteel de CNSA 2.0-algoritmen?

Grote leveranciers zoals Thales Luna, Entrust nShield en Utimaco hebben CNSA 2.0-ondersteuning uitgebracht in firmwareversies van 2025 en 2026, maar de ondersteuning verschilt per model. Controleer de huidige firmwarecompatibiliteit rechtstreeks bij de leverancier voor uw specifieke HSM-model in plaats van aan te nemen dat het voor alle systemen in de suite beschikbaar is.

Wat gebeurt er als een document met dubbele ondertekening ergens in het proces niet geverifieerd kan worden?

Omdat de klassieke handtekening nog steeds aanwezig en onafhankelijk is, blijft het artefact doorgaans geldig voor verificatoren die alleen de klassieke handtekening controleren. De reactie is om het toevoegen van de post-kwantumhandtekening voor die artefactstroom te pauzeren totdat de specifieke incompatibiliteit is vastgesteld, en niet om iets in te trekken of opnieuw uit te geven.