CNSA 2.0 -vaatimustenmukaisuus puolustusorganisaatioille: siirtymäsuunnitelma

Syyskuussa 2022 NSA:n kyberturvallisuusosasto julkaisi Commercial National Security Algorithm Suite 2.0:n (CNSA 2.0) – direktiivin, joka vaatii kaikkia kansallisen turvallisuuden järjestelmiä siirtymään klassisesta julkisen avaimen kryptografiasta post-kvanttialgoritmehin määritellyn aikataulun mukaisesti. Puolustusorganisaatioille tämä ei ole tutkimuskysymys tai tulevaisuuden suunnittelukohde: hankintavaatimukset sisältävät jo CNSA 2.0 -valmiuskriteerit, ja vuodesta 2025 alkaen käyttöönotetuissa uusissa järjestelmissä edellytetään mandatoitujen algoritmien tukea alusta alkaen.

Siirtymähaaste on merkittävä. Klassinen julkisen avaimen kryptografia – RSA, elliptinen käyrä-kryptografia (ECC) ja Diffie-Hellman – on upotettu koko puolustuksen IT-infrastruktuuriin: TLS-päätepisteisiin, VPN-yhdyskäytäviin, PKI-varmenteiden myöntäjiin, avaintenhallinnan järjestelmiin, laiteohjelmiston allekirjoitusputkilinjoihin ja salattuihin data-arkistoihin. Näiden riippuvuuksien korvaaminen suuressa organisaatiossa on monivuotinen ohjelma, joka edellyttää huolellista jaksotusta, toimittajien koordinointia ja riskienhallintaa sen jakson aikana, kun klassisten ja post-kvanttijärjestelmien on yhteistoimittava.

Tässä artikkelissa esitetään käytännön siirtymäsuunnitelma: mitä CNSA 2.0 vaatii, mitkä algoritmit korvaavat mitkä, kuinka jaksottaa siirtymä puolustusorganisaation läpi ja mitä vaatia CNSA 2.0 -kykyisiä järjestelmiä toimittavilta toimittajilta.

Mitä CNSA 2.0 vaatii ja miksi

CNSA 2.0:n taustalla oleva kryptografinen uhka on Shorin algoritmi – kvanttilaskenta-algoritmi, joka suurella kvanttitietokoneella ajettuna murtaa RSA:n (kokonaislukujen tekijäänjaon), ECC:n (elliptisen käyrän diskreetti logaritmi) ja Diffie-Hellmanin (diskreetti logaritmi) matemaattiset ongelmat. Shorin algoritmia 2048-bittistä RSA:ta tai 256-bittistä ECC:tä vastaan ajava kvanttitietokone vaatisi miljoonia loogisia kubitteja, jotka toimivat pienillä virhenopeuksilla. Tätä kykyä ei tänään ole olemassa, mutta uskottavat julkiset arviot sijoittavat "kryptografisesti relevantin kvanttitietokoneen" (CRQC) jonnekin vuosien 2030–2035 välille.

"Kerää nyt, pura myöhemmin" (HNDL) -uhka lyhentää tätä aikajanaa puolustuksen tarkoituksiin. Vastustajat, jotka keräävät salattua liikennettä tänään – strategiset viestit, tiedusteluraportit, kykyarvioinnit – voivat tallentaa ne ja purkaa salauksen, kun CRQC tulee saataville. Klassisilla algoritmeilla tänään salattujen tietojen salassapito on siis käytännössä eräpäivässä, joka korreloi CRQC:n saatavuuden kanssa. Tiedoille, joiden salassapitovaatimukset mitataan vuosikymmenissä, tuo eräpäivä on jo nykyinen operatiivinen huolenaihe.

CNSA 2.0 vastaa tähän mandatoimalla tietyn joukon post-kvanttialgoritmeja NSS-järjestelmille siirtymäaikataululla, joka on suunniteltu varmistamaan siirtymän valmistuminen ennen CRQC:n saatavuutta. Tärkeimmät vaatimukset:

• ML-KEM (FIPS 203 / CRYSTALS-Kyber) – korvaa RSA:n ja ECDH:n kaikessa avainten muodostamisessa. CNSA 2.0 mandatoi ML-KEM-1024:n (korkein turvallisuusparametrijoukko) NSS-sovelluksille.
• ML-DSA (FIPS 204 / CRYSTALS-Dilithium) – korvaa RSA-PSS:n ja ECDSA:n digitaalisiin allekirjoituksiin useimmissa sovelluksissa. Tarjoaa nopean allekirjoituksen ja vahvistuksen kohtuullisilla avain- ja allekirjoituskoilla.
• SLH-DSA (FIPS 205 / SPHINCS+) – vaihtoehtoinen allekirjoitusalgoritmi, joka perustuu tiivistefunktioihin eikä hilamatemaatiikkaan. Käytetään, kun vaaditaan monimuotoisuutta hilaperusteisista algoritmeista tai kun niitä ei sallita. Allekirjoitukset ovat huomattavasti suurempia kuin ML-DSA:ssa, mutta turvallisuus perustuu hyvin tunnettuihin tiivistefunktioiden ominaisuuksiin.
• LMS ja XMSS – tilalliset tiivisteperusteiset allekirjoitusskeemat, jotka on hyväksytty tietyille käyttötapauksille, erityisesti laiteohjelmiston allekirjoitukseen rajoitetuissa ympäristöissä. Vaativat huolellisen tilanhallintaa avainten uudelleenkäytön välttämiseksi.
• AES-256 ja SHA-384 – säilytetty CNSA 1.0:sta symmetriseen salaukseen ja hajautukseen; nämä eivät ole käytännön mittakaavassa kvantitietokoneiden uhkaamia.

Poistettavat algoritmit, jotka on vaiheistettava ulos CNSA 2.0:n myötä, ovat: RSA (kaikki avainten koot, kaikki sovellukset), ECDH ja ECDSA (kaikki käyrät), Diffie-Hellman (klassinen ja elliptinen käyrä) ja SHA-256 NSS-sovelluksille (joissa SHA-384 on nyt mandatoitu). AES-128 ja AES-192 on myös poistettu käytöstä AES-256:n hyväksi NSS:ssä.

Hyväksytyt algoritmit yksityiskohtaisesti

ML-KEM (Module-Lattice Key Encapsulation Mechanism) perustuu Module Learning With Errors (MLWE) -ongelman vaikeuteen – hilaongelmaan, jota mikään tunnettu kvantti- tai klassinen algoritmi ei ratkaise tehokkaasti. ML-KEM toimii avainten kapselointimekanismina: lähettäjä kapseloi jaetun salaisuuden vastaanottajan julkisella avaimella; vastaanottaja purkaa kapselin palauttaakseen jaetun salaisuuden. Jaettu salaisuus syöttää sitten symmetrisen avainjohdannaisfunktion. ML-KEM-1024 tuottaa 1 568 tavun julkiset avaimet, 1 568 tavun salatekstin ja 32 tavun jaetut salaisuudet – suurempia kuin RSA-2048-avaimet (256 tavua), mutta hyväksyttäviä useimmissa protokollakonteksteissa.

ML-DSA (Module-Lattice Digital Signature Algorithm) perustuu Module Short Integer Solution (MSIS) - ja MLWE-ongelmien vaikeuteen. ML-DSA-87 (korkein turvallisuustaso, vastaa AES-256-turvallisuutta) tuottaa 2 592 tavun julkiset avaimet ja 4 627 tavun allekirjoitukset. Vertailun vuoksi: ECDSA P-256 tuottaa 64-tavuisia allekirjoituksia. Suuremmat allekirjoituskoot edellyttävät mukautuksia protokollissa ja tallennusjärjestelmissä, jotka olettivat kompakteja allekirjoituksia – sertifikaattiketjut, laiteohjelmistokuvat ja kaistanleveydeltään rajoitetut yhteydet tarvitsevat kapasiteetin suunnittelua.

SLH-DSA (Stateless Hash-Based Digital Signature Algorithm) ei sisällä algebrallista rakennetta, jota joko klassiset tai kvanttialgoritmit voisivat hyödyntää muuten kuin geneerisissä tiivistefunktioiden hyökkäyksissä; sen turvallisuus perustuu kokonaan taustalla olevan tiivistefunktion törmäyskestävyyteen. Vastineena on suorituskyky ja koko: SLH-DSA-SHA2-256s-allekirjoitukset ovat 29 792 tavua pienimmällä parametrijoukolla, ja allekirjoittaminen on kertaluokkia hitaampaa kuin ML-DSA:ssa. SLH-DSA sopii toissijaiseksi allekirjoitusalgoritmiksi turvallisuuden monimuotoisuuden tarjoamiseksi, erityisesti laiteohjelmiston ja ohjelmiston allekirjoittamiseen, jossa allekirjoituskoko ja -taajuus ovat hallittavissa.

Neljä siirtymävaihetta

Hyvin rakennettu CNSA 2.0 -siirtymä etenee neljän vaiheen kautta. Organisaatiot voivat olla samanaikaisesti eri vaiheissa eri järjestelmätyypeissä – suuressa puolustusorganisaatiossa PKI-siirtymä on tyypillisesti Vaiheessa 2, kun taktiset reuna-alueen järjestelmät ovat vielä Vaiheessa 1.

Vaihe 1 – Kryptografinen inventaario. Ennen kuin siirtymätyötä voidaan suunnitella, organisaation on tiedettävä, mitä sillä on. Kryptografinen inventaario kattaa: jokaisen TLS-päätepisteen ja sen neuvoteltujen salauspakettien yhdistelmät; jokaisen käytössä olevan sertifikaatin (käyttäjä, laite, palvelu, koodiallekirjoitus) ja sen avaimen algoritmin sekä voimassaoloajan; jokaisen VPN-yhdyskäytävän ja sen IKEv2-avaintenvaihdon konfiguraation; jokaisen avaintenhallintajärjestelmän, HSM:n ja kryptografisen tokenin; jokaisen laiteohjelmiston allekirjoitusputkilinjan ja sen allekirjoitusavaimen tyypin; sekä jokaisen data-arkiston, jossa vaaditaan pitkäaikaista luottamuksellisuutta, ja sen salausavaimen algoritmin.

Automaattiset työkalut auttavat – TLS-skannerit (SSLyze, testssl.sh), SBOM-analyysi kryptografisille kirjastoriippuvuuksille sekä sertifikaattien hallintaalustat algoritmiraporten kanssa. Mutta automaattiset työkalut eivät havaitse mukautettuja protokollatoteutuksia, upotetun laiteohjelmiston kryptoa tai sovelluskerroksen kryptografiaa vakiokirjastojen ulkopuolella. Täydellisyyden varmistamiseksi tarvitaan arkkitehtuuridokumentaation ja lähdekoodin manuaalinen katsaus.

Vaihe 2 – Riskiperusteinen priorisointi. Kaikilla kryptografisilla riippuvuuksilla ei ole yhtä suuri HNDL-riski. Priorisoinnin tulisi heijastaa kahta ulottuvuutta: suojattujen tietojen pitkäikäisyys ja arkaluonteisuus sekä lähiajan siirtymän toteutettavuus. Korkean prioriteetin kohteita ovat järjestelmät, jotka suojaavat pitkäikäisiä salattuja tietoja, joissa HNDL-altistus on suurin: PKI-juuret ja myöntävät CA:t (joiden avaimet suojaavat koko organisaation luottamusankkuria), avaintenhallintainfrastruktuuri (HSM:t, jotka pitävät master-avaimia salattuihin arkistoihin), strategiset viestintäyhteydet sekä kaikki viisi vuotta ylittävällä salassapitovaatimuksella olevaa dataa salaavat järjestelmät.

Alemman prioriteetin – mutta silti ennen vuotta 2030 vaadittuja – ovat järjestelmät, joissa on tiheä laitteiston uusintatahti (taktiset alustat, loppukäyttäjälaitteet), joihin PQC-kyky voidaan sisällyttää seuraavalla luonnollisella uusinnalla, sekä sisäiset järjestelmät, jotka suojaavat luokittelematonta tietoa, jossa kvanttiriski on pienempi.

Vaihe 3 – Hybriditoiminta. Siirtymän aikana järjestelmät yhteistoimivat sekä CNSA 1.0 (klassinen) että CNSA 2.0 (post-kvantti) vastineiden kanssa. Hybridikryptografia – klassisten ja post-kvanttialgormien yhdistäminen samaan protokollanvaihtoon – tarjoaa kvanttikestävyyttä nykyisessä liikenteessä ilman, että kaikkien päätepisteiden on tuettava post-kvanttialgoritmeja samanaikaisesti.

Hybridissä TLS 1.3 -yhteydessä asiakas sisällyttää ClientHello-viestiin sekä ECDHE-avainjaon että ML-KEM-avainjaon; palvelin vastaa molemmilla. Lopullinen istuntoavain johdetaan molemmista jaetuista salaisuuksista avainjohdannaisfunktiolla. Hyökkääjän on murrettava sekä klassinen että post-kvantti-algoritmi vaarantaakseen istunnon. NSA hyväksyy nimenomaisesti tämän "henkselit ja vyö" -lähestymistavan siirtymäkaudella.

Vaihe 4 – Täydellinen siirtymä. Kun kaikki järjestelmät tukevat post-kvanttialgoritmeja ja hybriditoiminta on osoittautunut vakaaksi tuotannossa, klassiset salauspakettiyhdistelmät ja sertifikaattityypit poistetaan käytöstä. Poistaminen on koordinoitava kaikkien yhteistoimivien organisaatioiden, toimittajien ja kumppanimaiden kanssa. Luo seuranta havaitsemaan jäljellä oleva klassinen algoritmieneuvottelu (mikä viittaisi järjestelmään, joka puuttui inventaariosta tai jonka toimittaja ei ole vielä toimittanut CNSA 2.0 -kykyistä ohjelmistoa), ja seuraa poistamisvaiheita vuoden 2030 määräajan mukaisesti.

Korkean prioriteetin järjestelmät ja siirtymäjaksotus

Priorisoidussa siirtymätietolistassa tietyntyyppiset järjestelmät esiintyvät johdonmukaisesti korkean prioriteetin kohteina käytännössä kaikissa puolustusorganisaatioissa, ja ne tulisi jaksottaa varhaiseen vaiheeseen organisaation erityispiirteistä riippumatta.

Avaintenhallintainfrastruktuuri. HSM:t ja avaintenhallintapalvelut (KMS:t) ovat riippuvuuksia lähes jokaisen muun järjestelmän siirtymälle – post-kvantti-avaimet on luotava, tallennettava ja hallittava jonnekin. HSM:n laiteohjelmiston päivittäminen ML-KEM- ja ML-DSA-operaatioiden tukemiseksi sekä sen varmistaminen, että avaintenhallinta-API:t paljastavat post-kvantti-avaimentyypit kuluttaville sovelluksille, on Vaiheen 1–2 työtä jokaisessa siirtymäohjelmassa. Tässä myös toimittajasitoutuminen on kriittisintä: HSM-toimittajat eroavat merkittävästi PQC-tiekartoissaan, ja joitakin laitteistosukupolvia ei voi päivittää paikan päällä.

PKI-juuret ja myöntävät CA:t. PKI-luottamushierarkia tukee sertifikaattipohjaista todentamista koko organisaatiossa. Post-kvantti-juuriCA:iden perustaminen – ja niiden luottamusankkureiden jakelu kaikille luottaville osapuolille (selaimet, käyttöjärjestelmät, TLS-asiakkaat, OCSP-validaattorit) – on edellytys post-kvanttisertifikaattien myöntämiselle mille tahansa järjestelmälle. Tämän on tapahduttava ennen kuin post-kvanttisertifikaatit voidaan ottaa käyttöön muualla. Kaksoisjakelumallia, jossa sama CA myöntää kullekin kohteelle sekä klassisia että post-kvanttisertifikaatteja, voidaan käyttää asteittaiseen luottavien osapuolien siirtymiseen rikkomatta olemassa olevia luottamussuhteita.

VPN-yhdyskäytävät ja salatut viestintäalustat. Luokiteltujen verkkojen perimetreitä suojaavat VPN-yhdyskäytävät ovat ensisijaisia HNDL-kohteita. IKEv2, suurimmassa osassa yritys-VPN-ratkaisuja käytetty avaintenvaihtoprotokolla, on päivitettävä neuvottelemaan ML-KEM avainten muodostamiseen ja ML-DSA todentamiseen. Useimmilla yritys-VPN-toimittajilla (Cisco, Palo Alto, Juniper, Check Point) on PQC-tiekarttakohteita, mutta ominaisuuksien saatavuus ja CNSA 2.0 -parametrivaatimustenmukaisuus vaihtelevat merkittävästi – tämä on kriittinen toimittajan pätevyyskysymys hankinnassa.

Salatut viestintä- ja viestinalustat. Strategiseen johtamisviestintään, tiedustelutiedon jakeluun ja kriittiseen koordinointiin käytettävät järjestelmät ovat korkean prioriteetin kohteita, koska liikenteen arkaluonteisuus ja pitkäikäisyys on suuri. Corvus.Quantum, Corvus Intelligencen puolustuksen suoratoistoalusta, on suunniteltu CNSA 2.0 -yhdenmukaistamiseen – sisältäen ML-KEM:n avainten muodostamiseen ja ML-DSA:n viestien allekirjoittamiseen suoratoisto- ja viestiarkitehtuurissaan, tukien hybriditoimintaa siirtymäkaudella.

Laiteohjelmiston allekirjoitusputkilinjat. Asejärjestelmät ja sotilaalliset laitteistoalustat käyttävät digitaalisia allekirjoituksia laiteohjelmiston eheyden todentamiseen. Nämä allekirjoitukset ovat pitkäikäisiä – allekirjoitusavain saattaa kattaa koko alustan tuotantoelinkaaren, joka voi kestää vuosikymmenen tai enemmän – ja ne ovat siksi suoraan alttiina HNDL-riskille. Uusien, tuotantoon tulevien alustojen tulisi toimittaa ML-DSA- tai SLH-DSA-laiteohjelmiston allekirjoitus ensimmäisestä toimituksesta alkaen. Käytössä olevat alustat tarvitsevat uudelleenallekirjoituskampanjan laiteohjelmistokuville, joissa käynnistysarkkitehtuuri tukee avainten kierrätystä; alustoille, joissa allekirjoitusavaimet on sulatettu valmistuksessa, tarvitaan selkeä riskidokumentaatio.

Kryptografisten riippuvuuksien inventoiminen

Kryptografinen inventaario on johdonmukaisesti PQC-siirtymäohjelmien aliarvostetuimpi vaihe. Organisaatiot, jotka aloittavat siirtymän olettaen inventaarion kestävän viikkoja, löytävät tyypillisesti sen vaativan kuukausia, koska kryptografia on otettu käyttöön useammissa järjestelmäkerroksissa ja koodipoluissa kuin yhdellä tiimillä on täydellinen näkyvyys.

Kattava inventaariostrategia yhdistää neljä lähestymistapaa. Ensinnäkin, verkkokerroksen löytö: passiivinen TLS-liikenneanalyysi ja aktiivinen skannaus kaikista saavutettavista päätepisteistä käyttäen työkaluja, jotka sormenjälkivät neuvoteltuja salauspaketteja ja sertifikaattien avaimien algoritmeja. Tämä kattaa verkkopalvelimet, API-päätepisteet, kuormantasaajat ja palveluverkkojen viestinnän, jotka käyttävät vakio-TLS:ää. Toiseksi, sertifikaattien hallintaalustan luettelo: organisaation CA-hierarkian ja mahdollisten julkisten CT (Certificate Transparency) -lokien kyseleminen organisaation nimiä kantavien sertifikaattien osalta, kunkin avaimen algoritmin ja voimassaoloajan poimiminen. Kolmanneksi, SBOM-analyysi: ohjelmiston materiaaliluetteloiden poimiminen käyttöönotetuista sovelluksista ja skannaaminen kryptografisten kirjastoriippuvuuksien (OpenSSL, BoringSSL, libgcrypt, NSS, Java-salauspalveluntarjoajat) ja niiden versioiden osalta. Kryptografisten kirjastojen versiot määrittävät, mitkä algoritmit ovat käytettävissä ja mitkä ovat oletuksia. Neljänneksi, arkkitehtuuridokumentaation katsaus: mukautettujen protokollatoteutusten, prosessinsisäisen avainjohdannaisuuden, salattujen tietokantasarakkeiden ja sovelluskerroksen kryptografian tunnistaminen, jota verkkojen skannaus ei pysty havainnoimaan.

Inventaarion tuloksen tulee olla strukturoitu rekisteri, joka sisältää vähintään: järjestelmän nimi, kryptografisen riippuvuuden tyyppi (TLS, sertifikaatti, KEM, allekirjoitus, symmetrinen), algoritmi ja avainten koko, kirjasto tai toteutus, suojattujen tietojen luokittelu sekä arvioitu siirtymän monimutkaisuus. Tämä rekisteri ohjaa Vaiheen 2 priorisointia ja tarjoaa perusviivan vaatimustenmukaisuusedistymisen seurannalle.

Toimittajakysymykset hankinnan yhteydessä

Puolustusorganisaatioiden, jotka hankkivat kaupallisesti saatavilla olevaa ohjelmistoa ja laitteistoa, on arvioitava CNSA 2.0 -valmius osana hankintaa. Seuraavat kysymykset erottavat toimittajat, joilla on aito PQC-kyky, niistä, joilla on vain tiekarttolupauksia:

Algoritmin tuen erityiskohdat. "Tukeeko tuotteenne ML-KEM-1024:ää, ML-DSA-87:ää ja SLH-DSA-SHA2-256s:ää FIPS 203:n, 204:n ja 205:n mukaisesti?" Toimittajat, jotka vastaavat yleisillä "post-kvanttituki" -väitteillä ilman erityisiä FIPS-merkintöjä ja parametritasoja, eivät todennäköisesti täytä CNSA 2.0:n erityisvaatimuksia. Algoritmin tuki alemmilla parametritasoilla (ML-KEM-512, ML-DSA-44) ei täytä CNSA 2.0:n mandatoituja turvallisuustasoja NSS:lle.

Hybridisalauspakettien saatavuus. "Tukeeko TLS-toteutuksenne hybridistä ML-KEM + ECDHE -avaintenvaihtoa yhdessä kättelyssä?" Hybridituki mahdollistaa organisaation alkaa hyödyntää kvanttikestävyyttä olemassa olevassa liikenteessä ilman, että kaikkien yhteistoimivien osapuolien on suoritettava PQC-siirtymä samanaikaisesti.

Avainten koon sopeutuminen. "Kuinka järjestelmänne käsittelee post-kvanttialgoritm-ien suurempia avain- ja allekirjoituskokoja?" ML-DSA-87-allekirjoitukset ovat noin 4,6 kt verrattuna ECDSA P-256:n 64 tavuun. Järjestelmät, joissa on kiinteän kokoisia sertifikaatti- tai allekirjoituspuskureita, tietokantakaavoja kiinteillä kryptografisten kenttien pituuksilla tai verkkoprotokollat tiukoin MTU-olettamuksin, saattavat tarvita arkkitehtuurimuutoksia PQC-avainmateriaalin mahduttamiseksi.

Kryptografisen kirjaston alkuperä. "Mikä kryptografinen kirjasto on PQC-toteutuksenne taustalla ja mikä on version päivitystahti?" Post-kvanttitoteutukset OpenSSL:ssä, BoringSSL:ssä ja Bouncy Castlessa kypsyvät edelleen; toimittajan päivitystahti määrittää, kuinka nopeasti tietoturvapaikkaukset tavoittavat käyttöönotetut tuotteet.

Vuoden 2030 jälkeinen tiekartta. "Mikä on suunnitelmanne puhtaalle PQC-toiminnalle vuoden 2030 jälkeen, kun hybriditila ja klassiset algoritmit poistetaan?" Toimittajat, joilla ei ole konkreettista vuoden 2030 jälkeistä tiekarttaa, edustavat vaatimustenmukaisuusriskiä, joka vaatii hallittuja siirtymiä pahimmalla mahdollisella hetkellä – kun määräaika on lähellä.

Kuusivaiheinen CNSA 2.0 -siirtymän suunnitteluprosessi

Seuraavat vaiheet tiivistävät edellä mainitut siirtymävaiheet toimivaksi suunnittelujärjestykseksi puolustuksen IT- ja turvallisuustiimeille, jotka aloittavat CNSA 2.0 -vaatimustenmukaisuusohjelman.

Vaihe 1 – Suorita kryptografinen inventaario. Ota käyttöön TLS-skannaus, sertifikaattien hallinnan raportointi, SBOM-analyysi ja arkkitehtuuridokumentaation katsaus kaikkien järjestelmien osalta. Tuota strukturoitu rekisteri jokaisesta kryptografisesta riippuvuudesta: tyyppi, algoritmi, avainten koko, kirjasto, tietojen luokittelu ja arvioitu siirtymän monimutkaisuus. Odota tämän vaiheen kestävän 2–6 kuukautta keskikokoisesta suureen puolustusorganisaatioon. Älä siirry suunnitteluun ilman kohtuullisen täydellistä inventaariota – osittaiseen inventaarioon perustuvat siirtymäsuunnitelmat jättävät huomaamatta korkean prioriteetin järjestelmät.

Vaihe 2 – Arvioi riskit ja priorisoi järjestelmät. Pistytä jokainen inventaarikohde kahdella akselilla: HNDL-riski (suojattujen tietojen arkaluonteisuus ja pitkäikäisyys) ja siirtymän toteutettavuus (tiimin kyky, toimittajan valmius, arkkitehtuurinen monimutkaisuus). Tuota priorisoitu siirtymätietolista arvioidulla työmäärällä, kohteiden välisillä riippuvuuksilla ja omistajan määrityksellä. Pitkäikäisiä salattuja tietoja suojaavien kohteiden, joiden siirtymä on yksinkertaista, tulisi olla listan kärjessä organisaatioiden politiikasta riippumatta.

Vaihe 3 – Päivitä avaintenhallinta- ja PKI-infrastruktuuri ensin. Siirrä HSM:t CNSA 2.0 -kykyiseen laiteohjelmistoon. Myönnä post-kvantti-juuriCA-sertifikaatit. Luo kaksoisjakamiskyky. Jaa päivitetyt luottamusankkurit luottaville osapuolille. Tämä vaihe on riippuvuus kaikille myöhemmille sertifikaattipohjaisille siirtymille, ja se tulisi resursoida ja aloittaa välittömästi inventaarion valmistuttua.

Vaihe 4 – Ota käyttöön hybridisalauspaketteja korkean prioriteetin verkkoyhteyksissä. Ota käyttöön ML-KEM-hybridisalauspakettiyhdistelmät VPN-yhdyskäytävillä, luokiteltujen verkkojen perimetreillä ja viestintäalustoilla. Tämä vaihe tarjoaa välittömän HNDL-riskin vähentämisen nykyisessä liikenteessä ilman täydellistä PQC-valmiutta kaikissa päätepisteissä. Seuraa neuvottelutahteja käyttöönoton seuraamiseksi.

Vaihe 5 – Siirrä laiteohjelmiston allekirjoitus ja ohjelmistotoimitusketju. Siirry laiteohjelmiston allekirjoitusputkilinjoissa ML-DSA- tai SLH-DSA-avaimiin kaikille tuotantoon tuleville alustoille. Suorita uudelleenallekirjoituskampanjat käytössä oleville alustoille, joissa se on arkkitehtuurisesti mahdollista. Päivitä CI/CD-koodiallekirjoitusputkilinjat. Dokumentoi rajoitetut alustat hallittuna kryptografisena teknisenä velkana, jolla on selkeä riskin hyväksyminen.

Vaihe 6 – Toteuta täydellinen siirtymä ja poista klassiset algoritmit. Kun kaikki korkean prioriteetin järjestelmät tukevat post-kvanttialgoritmeja ja hybriditoiminta on vakaata, aloita klassisten salauspakettien ja sertifikaattityyppien poistaminen koordinoidun aikataulun mukaisesti yhteistoimivien organisaatioiden kanssa. Luo vaatimustenmukaisuuskojelauta. Tavoittele klassisten algoritmien täydellistä poistumista vuoteen 2030 mennessä NSA:n ohjeiden mukaisesti.

Aiheeseen liittyvää lukemista

Syvempää käsittelyä taustalla olevista post-kvanttialgoritmeista ja niiden puolustusvaikutuksista löydät sivulta Post-kvanttikryptografia puolustukselle: CNSA 2.0 -opas. Avaintenhallinnan ja salaisuuksien infrastruktuurista, joka tukee PQC-siirtymää, löydät lisätietoja sivulta Salaisuuksien hallinta puolustuksen CI/CD-putkilinjoissa: Vault, HSM ja avainten kierrätys. Zero-trust-arkkitehtuurista täydentävänä turvallisuuskerroksena löydät lisätietoja sivulta Zero-trust-arkkitehtuuri sotilasverkoille: periaatteet ja toteutus.