CNSA 2.0-naleving voor defensieorganisaties: migratieroadmap

In september 2022 publiceerde de Cybersecurity Directorate van NSA de Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) — een richtlijn die vereist dat alle National Security Systems overstappen van klassieke publieke-sleutelcryptografie naar post-kwantumalgoritmen volgens een vastgesteld schema. Voor defensieorganisaties is dit geen onderzoeksvraag of een toekomstig planningsonderwerp: inkoopvereisten nemen al CNSA 2.0-gereedheidscriteriumcriteria op, en nieuwe systemen die vanaf 2025 worden ingezet, worden geacht de voorgeschreven algoritmen vanaf dag één te ondersteunen.

De migratieuitdaging is aanzienlijk. Klassieke publieke-sleutelcryptografie — RSA, Elliptic Curve Cryptography (ECC) en Diffie-Hellman — is verankerd in de hele defensie-IT-infrastructuur: TLS-eindpunten, VPN-gateways, PKI-certificaatautoriteiten, sleutelbeheersystemen, firmware-ondertekeningspijplijnen en versleutelde gegevensarchieven. Het vervangen van deze afhankelijkheden in een grote organisatie is een meerjarenprogramma dat zorgvuldige sequentiering, leverancierscoördinatie en risicobeheer vereist gedurende de periode dat klassieke en post-kwantumsystemen moeten samenwerken.

Dit artikel legt een praktische migratieroadmap uit: wat CNSA 2.0 vereist, welke algoritmen door welke worden vervangen, hoe de overgang over een defensieorganisatie te sequentiëren, en wat van leveranciers te eisen die CNSA 2.0-geschikte systemen leveren.

Wat CNSA 2.0 vereist en waarom

De cryptografische bedreiging die CNSA 2.0 aandrijft is het algoritme van Shor — een kwantumalgoritme dat, wanneer uitgevoerd op een voldoende grote kwantumcomputer, de wiskundige problemen doorbreekt die ten grondslag liggen aan RSA (factorizatie van gehele getallen), ECC (elliptische curve discrete logaritme) en Diffie-Hellman (discrete logaritme). Een kwantumcomputer die in staat is het algoritme van Shor uit te voeren tegen 2048-bit RSA of 256-bit ECC zou miljoenen logische qubits nodig hebben die met lage foutpercentages werken. Die capaciteit bestaat vandaag niet, maar geloofwaardige openbare schattingen plaatsen een "cryptografisch relevante kwantumcomputer" (CRQC) ergens in het venster van 2030–2035.

De "harvest now, decrypt later" (HNDL)-bedreiging verkort deze tijdlijn voor defensiedoeleinden. Tegenstanders die vandaag versleuteld verkeer verzamelen — strategische communicatie, inlichtingenrapportage, capaciteitsbeoordelingen — kunnen het opslaan en ontsleutelen zodra een CRQC beschikbaar wordt. De geheimhouding van gegevens die vandaag met klassieke algoritmen zijn versleuteld, heeft daarom een effectieve vervaldatum die gecorreleerd is met de beschikbaarheid van CRQC. Voor gegevens met geheimhoudingsvereisten gemeten in decennia is die vervaldatum al een huidig operationeel aandachtspunt.

CNSA 2.0 pakt dit aan door een specifieke reeks post-kwantumalgoritmen voor NSS voor te schrijven, met een overgangstijdlijn die is ontworpen om ervoor te zorgen dat de migratie voltooid is voordat CRQC beschikbaar wordt. De belangrijkste voorschriften:

• ML-KEM (FIPS 203 / CRYSTALS-Kyber) — vervangt RSA en ECDH voor alle sleutelvaststelling. CNSA 2.0 schrijft ML-KEM-1024 (de hoogste beveiligingsparameterset) voor NSS-toepassingen voor.
• ML-DSA (FIPS 204 / CRYSTALS-Dilithium) — vervangt RSA-PSS en ECDSA voor digitale handtekeningen in de meeste toepassingen. Biedt snelle ondertekening en verificatie met redelijke sleutel- en handtekeninggroottes.
• SLH-DSA (FIPS 205 / SPHINCS+) — een alternatief handtekeningalgoritme gebaseerd op hashfuncties in plaats van roosterwiskunde. Gebruikt waar diversiteit ten opzichte van roostergebaseerde algoritmen vereist is, of waar roostergebaseerde algoritmen niet zijn toegestaan. Handtekeningen zijn aanzienlijk groter dan ML-DSA, maar de beveiliging is gebaseerd op goed begrepen hashfunctie-eigenschappen.
• LMS en XMSS — stateful hash-gebaseerde handtekeningschema's goedgekeurd voor specifieke gebruikssituaties, met name firmware-ondertekening in beperkte omgevingen. Vereisen zorgvuldig statusbeheer om hergebruik van sleutels te voorkomen.
• AES-256 en SHA-384 — behouden van CNSA 1.0 voor symmetrische versleuteling en hashing; deze worden op praktische schaal niet bedreigd door kwantumcomputers.

Afgeschreven algoritmen die onder CNSA 2.0 moeten worden uitgefaseerd, zijn: RSA (alle sleutelgroottes, alle toepassingen), ECDH en ECDSA (alle curves), Diffie-Hellman (klassiek en elliptische curve), en SHA-256 voor NSS-toepassingen (waar SHA-384 nu verplicht is). AES-128 en AES-192 worden ook afgeschreven ten gunste van AES-256 voor NSS.

Goedgekeurde algoritmen in detail

ML-KEM (Module-Lattice Key Encapsulation Mechanism) is gebaseerd op de hardheid van het Module Learning With Errors (MLWE)-probleem — een roosterprobleem dat geen bekend kwantum- of klassiek algoritme efficiënt oplost. ML-KEM werkt als een sleutelinkapselingsmechanisme: de afzender kapselt een gedeeld geheim in onder de publieke sleutel van de ontvanger; de ontvanger decapsuleert om het gedeelde geheim te herstellen. Het gedeelde geheim leidt vervolgens een symmetrische sleutelafleidingsfunctie aan. ML-KEM-1024 produceert publieke sleutels van 1.568 bytes, cijferteksten van 1.568 bytes en gedeelde geheimen van 32 bytes — groter dan RSA-2048-sleutels (256 bytes), maar acceptabel voor de meeste protocolcontexten.

ML-DSA (Module-Lattice Digital Signature Algorithm) is gebaseerd op de hardheid van de Module Short Integer Solution (MSIS)- en MLWE-problemen. ML-DSA-87 (het hoogste beveiligingsniveau, overeenkomend met AES-256-beveiliging) produceert publieke sleutels van 2.592 bytes en handtekeningen van 4.627 bytes. Ter vergelijking: ECDSA P-256 produceert 64-byte handtekeningen. De grotere handtekeninggroottes vereisen aanpassing in protocollen en opslagsystemen die uitgingen van compacte handtekeningen — certificaatketens, firmware-images en bandbreedtebeperkte verbindingen hebben capaciteitsplanning nodig.

SLH-DSA (Stateless Hash-Based Digital Signature Algorithm) heeft geen algebraïsche structuur die door klassieke of kwantumalgoritmen kan worden benut buiten generieke hashfunctie-aanvallen; de beveiliging ervan reduceert volledig tot de botsingsresistentie van de onderliggende hashfunctie. De afweging is prestaties en grootte: SLH-DSA-SHA2-256s-handtekeningen zijn 29.792 bytes bij de laagste parameterset, en ondertekening is ordes van grootte langzamer dan ML-DSA. SLH-DSA is geschikt als secundair handtekeningalgoritme om beveiligingsdiversiteit te bieden, met name voor firmware- en software-ondertekening waarbij de handtekeninggrootte en ondertekeningsfrequentie beheersbaar zijn.

De vier migratiefasen

Een goed gestructureerde CNSA 2.0-migratie verloopt door vier fasen. Organisaties kunnen voor verschillende systeemtypen tegelijkertijd in verschillende fasen zijn — een grote defensieorganisatie zal doorgaans PKI-migratie in fase 2 hebben terwijl tactische randsystemen nog in fase 1 zijn.

Fase 1 — Cryptografische inventarisatie. Voordat migratiewerk kan worden gepland, moet de organisatie weten wat ze heeft. Cryptografische inventarisatie omvat: elk TLS-eindpunt en de onderhandelde cipher suites; elk in gebruik zijnd certificaat (gebruiker, apparaat, dienst, code-ondertekening) en het sleutelalgoritme en de vervaldatum; elke VPN-gateway en de IKEv2-sleuteluitwisselingsconfiguratie; elk sleutelbeheersysteem, HSM en cryptografisch token; elke firmware-ondertekeningspijplijn en het type ondertekeningssleutel; en elk gegevensarchief waar langdurige vertrouwelijkheid vereist is en het versleutelingssleutelalgoritme.

Geautomatiseerde hulpmiddelen helpen — TLS-scanners (SSLyze, testssl.sh), SBOM-analyse voor cryptografische bibliotheekafhankelijkheden en certificaatbeheerplatformen met algoritme-rapportage. Maar geautomatiseerde hulpmiddelen missen aangepaste protocol-implementaties, embedded firmware-crypto en applicatielaagcryptografie buiten standaardbibliotheken. Handmatige beoordeling van architectuurdocumentatie en broncode is vereist voor volledigheid.

Fase 2 — Risicogebaseerde prioritering. Niet alle cryptografische afhankelijkheden dragen een gelijk HNDL-risico. Prioritering moet twee dimensies weerspiegelen: de levensduur en gevoeligheid van beschermde gegevens, en de haalbaarheid van migratie op korte termijn. Hoogprioritaire doelwitten zijn systemen die langdurig gerubriceerde gegevens beschermen waarbij HNDL-blootstelling het hoogst is: PKI-root en uitgevende CA's (waarvan de sleutels de vertrouwensanker voor de hele organisatie beschermen), sleutelbeheerinfrastructuur (HSMs die mastersleutels voor versleutelde archieven bewaren), strategische communicatieverbindingen en elk systeem dat gegevens versleutelt met een geheimhoudingsvereiste van meer dan vijf jaar.

Lagere prioriteit — maar nog steeds vereist voor 2030 — zijn systemen met frequente hardware-vernieuwingscycli (tactische platformen, eindgebruikersapparaten) waarbij PQC-capaciteit kan worden opgenomen bij de volgende natuurlijke vernieuwing, en interne systemen die niet-gerubriceerde gegevens beschermen waarbij het kwantumrisico lager is.

Fase 3 — Hybride werking. Tijdens de migratie werken systemen samen met zowel CNSA 1.0 (klassieke) als CNSA 2.0 (post-kwantum) tegenhangers. Hybride cryptografie — het combineren van klassieke en post-kwantumalgoritmen in dezelfde protocoluitwisseling — biedt kwantumresistentie op huidig verkeer zonder dat alle eindpunten tegelijkertijd post-kwantumalgoritmen hoeven te ondersteunen.

In een hybride TLS 1.3-verbinding neemt de client zowel een ECDHE-sleutelaandeel als een ML-KEM-sleutelaandeel op in de ClientHello; de server reageert met beide. De definitieve sessiesleutel wordt afgeleid van beide gedeelde geheimen met behulp van een sleutelafleidingsfunctie. Een aanvaller moet zowel de klassieke als de post-kwantumalgoritmen doorbreken om de sessie te compromitteren. Deze "riem en bretels"-aanpak wordt door NSA expliciet onderschreven voor de overgangsperiode.

Fase 4 — Volledige overgang. Zodra alle systemen post-kwantumalgoritmen ondersteunen en hybride werking stabiel is gebleken in productie, worden klassieke-only cipher suites en certificaattypen buiten gebruik gesteld. Afschaffing moet worden gecoördineerd met alle samenwerkende organisaties, leveranciers en partnernaties. Stel monitoring in om eventuele resterende onderhandeling over klassieke algoritmen te detecteren (wat zou aangeven dat een systeem is gemist in de inventarisatie of dat een leverancier nog geen CNSA 2.0-geschikte software heeft geleverd), en volg afschaffingsmijlpalen tegen de deadline van 2030.

Hoogprioritaire systemen en migratiesequentiering

Binnen de geprioriteerde migratie-achterstand verschijnen bepaalde systeemtypen consequent als hoogprioriteit bij vrijwel alle defensieorganisaties en moeten ongeacht organisatiespecificaties vroeg worden gesequentieerd.

Sleutelbeheerinfrastructuur. HSMs en sleutelbeheerservices (KMSes) zijn afhankelijkheden voor de migratie van bijna elk ander systeem — post-kwantumsleutels moeten ergens worden gegenereerd, opgeslagen en beheerd. Het upgraden van HSM-firmware om ML-KEM- en ML-DSA-bewerkingen te ondersteunen, en verifiëren dat sleutelbeheer-API's post-kwantum-sleuteltypen beschikbaar stellen aan verbruikende applicaties, is fase 1-2 werk in elk migratieprogramma. Dit is ook waar leveranciersbetrokkenheid het meest kritiek is: HSM-leveranciers variëren aanzienlijk in hun PQC-roadmaps, en sommige hardwaregeneraties kunnen niet ter plaatse worden geüpgraded.

PKI-root en uitgevende CA's. De PKI-vertrouwenshiërarchie ondersteunt op certificaten gebaseerde authenticatie in de hele organisatie. Het opzetten van post-kwantum root CA's — en het distribueren van hun vertrouwensankers naar alle vertrouwende partijen (browsers, besturingssystemen, TLS-clients, OCSP-validators) — is een voorwaarde voor het uitgeven van post-kwantumcertificaten aan elk systeem. Dit moet gebeuren voordat post-kwantumcertificaten ergens anders kunnen worden ingezet. Een dubbel-uitgiftemodel, waarbij dezelfde CA zowel klassieke als post-kwantumcertificaten uitgeeft voor elk onderwerp, maakt geleidelijke migratie van vertrouwende partijen mogelijk zonder bestaande vertrouwensrelaties te verstoren.

VPN-gateways en versleutelde communicatieplatformen. VPN-gateways die gerubriceerde netwerkperimeters beschermen, zijn primaire HNDL-doelwitten. IKEv2, het sleuteluitwisselingsprotocol dat wordt gebruikt in de meeste zakelijke VPN-oplossingen, moet worden bijgewerkt om ML-KEM voor sleutelvaststelling en ML-DSA voor authenticatie te onderhandelen. De meeste zakelijke VPN-leveranciers (Cisco, Palo Alto, Juniper, Check Point) hebben PQC-roadmap-items, maar de beschikbaarheid van functies en CNSA 2.0-parameternaleving variëren aanzienlijk — dit is een kritieke leveranciersgekwalificeerde vraag bij inkoop.

Versleutelde communicatie- en berichtenplatformen. Systemen die worden gebruikt voor strategische commandocommunicatie, inlichtingenverspreiding en missiekritische coördinatie zijn hoogprioritaire doelwitten omdat de gevoeligheid en levensduur van het verkeer hoog zijn. Corvus.Quantum, het streamingplatform van Corvus Intelligence voor defensie, is ontworpen voor CNSA 2.0-afstemming — met ML-KEM voor sleutelvaststelling en ML-DSA voor berichtondertekening in zijn streaming- en berichtenarchitectuur, met ondersteuning voor hybride werking tijdens de overgangsperiode.

Firmware-ondertekeningspijplijnen. Wapensystemen en militaire hardwareplatformen gebruiken digitale handtekeningen om firmware-integriteit te verifiëren. Deze handtekeningen zijn langdurig — de ondertekeningssleutel kan de gehele productielooptijd van een platform beslaan, die zich uitstrekt over een decennium of meer — en zijn daardoor direct blootgesteld aan HNDL-risico. Nieuwe platformen die in productie gaan, moeten vanaf de eerste levering worden verzonden met ML-DSA- of SLH-DSA-firmware-ondertekening. In-service platformen vereisen een herondertekeningscampagne voor firmware-images waarbij de opstartarchitectuur sleutelrotatie ondersteunt; platformen waarbij ondertekeningssleutels bij de fabricage zijn vastgezet, vereisen expliciete risicودکوmumentatie.

Hoe cryptografische afhankelijkheden te inventariseren

Cryptografische inventarisatie is consequent de meest onderschatte fase van PQC-migratieprogramma's. Organisaties die beginnen met de aanname dat inventarisatie weken in beslag neemt, ontdekken doorgaans dat het maanden vereist, omdat cryptografie over meer systeemlagen en meer codepaden is ingezet dan een enkel team volledig zicht op heeft.

Een uitgebreide inventarisatiestrategie combineert vier benaderingen. Ten eerste, ontdekking op netwerklaag: passieve TLS-verkeersanalyse en actieve scanning van alle bereikbare eindpunten met behulp van tools die onderhandelde cipher suites en certificaatsleutelalgoritmen identificeren. Dit omvat webservers, API-eindpunten, load balancers en service-mesh-communicaties die standaard TLS gebruiken. Ten tweede, opsomming van certificaatbeheerplatformen: het bevragen van de CA-hiërarchie van de organisatie en eventuele publieke CT (Certificate Transparency)-logboeken voor certificaten met de namen van de organisatie, waarbij het sleutelalgoritme en de vervaldatum voor elk worden geëxtraheerd. Ten derde, SBOM-analyse: het extraheren van Software Bill of Materials uit geplaatste applicaties en scannen op cryptografische bibliotheekafhankelijkheden (OpenSSL, BoringSSL, libgcrypt, NSS, Java-cryptoproviders) en hun versies. Cryptografische bibliotheekversies bepalen welke algoritmen beschikbaar zijn en welke de standaarden zijn. Ten vierde, beoordeling van architectuurdocumentatie: het identificeren van aangepaste protocol-implementaties, in-process sleutelafleiding, versleutelde databasekolommen en applicatielaagcryptografie die netwerkscannen niet kan waarnemen.

De output van de inventarisatie moet een gestructureerd register zijn met minimaal: systeemnaam, type cryptografische afhankelijkheid (TLS, certificaat, KEM, handtekening, symmetrisch), algoritme en sleutelgrootte, bibliotheek of implementatie, gegevensclassificatie van beschermde gegevens en geschatte migratiecomplexiteit. Dit register stuurt fase 2-prioritering en biedt de basislijn voor het volgen van nalevingsvoortgang.

Leveranciersvragen bij inkoop

Defensieorganisaties die commercieel-kant-en-klare software en hardware inkopen, moeten CNSA 2.0-gereedheid evalueren als onderdeel van de inkoop. De volgende vragen onderscheiden leveranciers met echte PQC-capaciteit van die met roadmap-beloften:

Specificaties voor algoritme-ondersteuning. "Ondersteunt uw product ML-KEM-1024, ML-DSA-87 en SLH-DSA-SHA2-256s zoals gedefinieerd in FIPS 203, 204 en 205?" Leveranciers die reageren met generieke "post-kwantumondersteuning"-claims zonder specifieke FIPS-aanduidingen en parameterniveaus zullen waarschijnlijk niet voldoen aan de specifieke vereisten van CNSA 2.0. Algoritme-ondersteuning op lagere parameterniveaus (ML-KEM-512, ML-DSA-44) voldoet niet aan de voorgeschreven beveiligingsniveaus van CNSA 2.0 voor NSS.

Beschikbaarheid van hybride cipher suites. "Ondersteunt uw TLS-implementatie hybride ML-KEM + ECDHE-sleuteluitwisseling in een enkele handshake?" Hybride ondersteuning stelt de organisatie in staat te beginnen te profiteren van kwantumresistentie op bestaand verkeer zonder te vereisen dat alle samenwerkende partijen tegelijkertijd PQC-migratie voltooien.

Accommodatie van sleutelgrootte. "Hoe verwerkt uw systeem de grotere sleutel- en handtekeninggroottes van post-kwantumalgoritmen?" ML-DSA-87-handtekeningen zijn ongeveer 4,6 KB versus ECDSA P-256's 64 bytes. Systemen met vaste-grootte certificaat- of handtekeningbuffers, databaseschema's met vaste cryptografische veldlengtes of netwerkprotocollen met strikte MTU-aannames vereisen mogelijk architecturale wijzigingen om PQC-sleutelmateriaal te accommoderen.

Herkomst van cryptografische bibliotheek. "Welke cryptografische bibliotheek ligt ten grondslag aan uw PQC-implementatie, en wat is de versie-updatecadans?" Post-kwantumimplementaties in OpenSSL, BoringSSL en Bouncy Castle zijn nog in ontwikkeling; de updatecadans van de leverancier bepaalt hoe snel beveiligingspatches geplaatste producten bereiken.

Roadmap na 2030. "Wat is uw plan voor pure-PQC-werking na 2030 wanneer hybride modus en klassieke algoritmen worden afgeschreven?" Leveranciers zonder een concrete roadmap na 2030 vertegenwoordigen een nalevingsrisico dat beheerde overgangen zal vereisen op het slechtst mogelijke moment — wanneer de deadline nabij is.

Zesstappen CNSA 2.0-migratieplanningsproces

De volgende stappen destilleren de bovenstaande migratiefasen tot een uitvoerbare planningsreeks voor defensie-IT- en beveiligingsteams die een CNSA 2.0-nalevingsprogramma starten.

Stap 1 — Voer een cryptografische inventarisatie uit. Implementeer TLS-scanning, certificaatbeheerrapportage, SBOM-analyse en beoordeling van architectuurdocumentatie voor alle systemen. Produceer een gestructureerd register van elke cryptografische afhankelijkheid: type, algoritme, sleutelgrootte, bibliotheek, gegevensclassificatie en geschatte migratiecomplexiteit. Verwacht dat deze stap 2–6 maanden in beslag neemt voor een middelgrote tot grote defensieorganisatie. Ga niet verder met planning zonder een redelijk volledige inventarisatie — migratieplannen gebouwd op gedeeltelijke inventarisatie zullen hoogprioritaire systemen missen.

Stap 2 — Beoordeel risico's en geef prioriteit aan systemen. Beoordeel elk inventarisatie-item op twee assen: HNDL-risico (gevoeligheid en levensduur van beschermde gegevens) en migratiehaalbaar (teamcapaciteit, leveranciersgereedheid, architecturale complexiteit). Produceer een geprioriteerde migratie-achterstand met geschatte inspanning, afhankelijkheden tussen items en eigenaarstoewijzing. Items die langdurig gerubriceerde gegevens beschermen met lage migratiecomplexiteit moeten bovenaan staan, ongeacht organisatorische politiek.

Stap 3 — Upgrade eerst sleutelbeheer- en PKI-infrastructuur. Migreer HSMs naar CNSA 2.0-geschikte firmware. Geef post-kwantum root CA-certificaten uit. Stel dubbele-uitgiftecapaciteit in. Distribueer bijgewerkte vertrouwensankers naar vertrouwende partijen. Deze fase is een afhankelijkheid voor alle volgende op certificaten gebaseerde migraties en moet worden uitgerust en onmiddellijk na voltooiing van de inventarisatie worden gestart.

Stap 4 — Implementeer hybride cipher suites op hoogprioritaire netwerkpaden. Schakel ML-KEM hybride cipher suites in op VPN-gateways, gerubriceerde netwerkperimeters en communicatieplatformen. Deze stap biedt onmiddellijke HNDL-risicoreductie op huidig verkeer zonder volledige PQC-gereedheid voor alle eindpunten te vereisen. Monitor onderhandelingspercentages om adoptie bij te houden.

Stap 5 — Migreer firmware-ondertekening en softwaretoeleveringsketen. Zet firmware-ondertekeningspijplijnen over naar ML-DSA- of SLH-DSA-sleutels voor alle platformen die in productie gaan. Voer herondertekeningscampagnes uit voor in-service platformen waar architecturaal haalbaar. Update CI/CD-code-signing-pijplijnen. Documenteer beperkte platformen als beheerde cryptografische technische schuld met expliciete risicoaanvaarding.

Stap 6 — Voer volledige overgang uit en schaf klassieke algoritmen af. Zodra alle hoogprioritaire systemen post-kwantumalgoritmen ondersteunen en hybride werking stabiel is, begin dan met het buiten gebruik stellen van klassieke cipher suites en certificaattypen op een gecoördineerd schema met samenwerkende organisaties. Stel een nalevingsdashboard in. Streef naar volledige klassieke algoritme-afschaffing vóór 2030 in lijn met NSA-richtlijnen.

Gerelateerde lectuur

Voor diepgaandere informatie over de onderliggende post-kwantumalgoritmen en hun defensie-implicaties, zie Post-kwantumcryptografie voor defensie: CNSA 2.0-gids. Voor het sleutelbeheer en de geheimen-infrastructuur die ten grondslag liggen aan PQC-migratie, zie Geheimenbeheer in defensie-CI/CD-pijplijnen: Vault, HSM en sleutelrotatie. Voor zero-trust-architectuur als een complementaire beveiligingslaag, zie Zero-trust-architectuur voor militaire netwerken: principes en implementatie.