Conformitate CNSA 2.0 pentru organizații de apărare: foaie de parcurs pentru migrare

În septembrie 2022, Direcția de Securitate Cibernetică a NSA a publicat Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) — o directivă care cere ca toate Sistemele de Securitate Națională să treacă de la criptografia clasică cu chei publice la algoritmi post-cuantici conform unui calendar definit. Pentru organizațiile de apărare, aceasta nu este o problemă de cercetare sau un element de planificare viitoare: cerințele de achiziții incorporează deja criterii de pregătire CNSA 2.0, iar noile sisteme implementate începând din 2025 sunt așteptate să accepte algoritmii obligatorii de la prima zi.

Provocarea migrării este substanțială. Criptografia clasică cu chei publice — RSA, Criptografia pe Curbe Eliptice (ECC) și Diffie-Hellman — este integrată în toată infrastructura IT de apărare: endpoint-uri TLS, gateway-uri VPN, autorități de certificare PKI, sisteme de gestionare a cheilor, conducte de semnare firmware și arhive de date criptate. Înlocuirea acestor dependențe într-o organizație mare este un program de mai mulți ani care necesită secvențiere atentă, coordonare cu furnizorii și gestionarea riscurilor în perioada în care sistemele clasice și post-cuantice trebuie să interopereze.

Acest articol prezintă o foaie de parcurs practică pentru migrare: ce solicită CNSA 2.0, care algoritmi îi înlocuiesc pe alții, cum să secvențiați tranziția în cadrul unei organizații de apărare și ce să cereți furnizorilor care livrează sisteme compatibile cu CNSA 2.0.

Ce solicită CNSA 2.0 și de ce

Amenințarea criptografică care determină CNSA 2.0 este algoritmul lui Shor — un algoritm cuantic care, rulat pe un calculator cuantic suficient de mare, sparge problemele matematice care stau la baza RSA (factorizarea numerelor întregi), ECC (logaritmul discret pe curbe eliptice) și Diffie-Hellman (logaritmul discret). Un calculator cuantic capabil să ruleze algoritmul lui Shor împotriva RSA pe 2048 de biți sau ECC pe 256 de biți ar necesita milioane de qubiți logici care funcționează cu rate de eroare scăzute. Această capacitate nu există astăzi, dar estimările publice credibile plasează un „calculator cuantic relevant din punct de vedere criptografic" (CRQC) undeva în fereastra 2030–2035.

Amenințarea „harvest now, decrypt later" (HNDL) comprimă acest calendar în scopuri de apărare. Adversarii care colectează trafic criptat astăzi — comunicații strategice, rapoarte de informații, evaluări de capacități — îl pot stoca și decripta odată ce un CRQC devine disponibil. Confidențialitatea datelor criptate astăzi cu algoritmi clasici are astfel o dată de expirare efectivă corelată cu disponibilitatea CRQC. Pentru datele cu cerințe de confidențialitate măsurate în decenii, această expirare este deja o preocupare operațională prezentă.

CNSA 2.0 abordează acest lucru prin mandatarea unui set specific de algoritmi post-cuantici pentru NSS, cu un calendar de tranziție conceput pentru a asigura finalizarea migrării înainte de disponibilitatea CRQC. Mandatele cheie:

• ML-KEM (FIPS 203 / CRYSTALS-Kyber) — înlocuiește RSA și ECDH pentru toate stabilirile de chei. CNSA 2.0 mandatează ML-KEM-1024 (setul de parametri cu cea mai înaltă securitate) pentru aplicațiile NSS.
• ML-DSA (FIPS 204 / CRYSTALS-Dilithium) — înlocuiește RSA-PSS și ECDSA pentru semnăturile digitale în majoritatea aplicațiilor. Oferă semnare și verificare rapidă cu dimensiuni rezonabile ale cheilor și semnăturilor.
• SLH-DSA (FIPS 205 / SPHINCS+) — un algoritm alternativ de semnătură bazat pe funcții hash mai degrabă decât pe matematica rețelelor. Utilizat acolo unde este necesară diversificarea față de algoritmii bazați pe rețele, sau unde algoritmii bazați pe rețele nu sunt permiși. Semnăturile sunt semnificativ mai mari decât ML-DSA, dar securitatea se bazează pe proprietăți bine înțelese ale funcțiilor hash.
• LMS și XMSS — scheme de semnătură bazate pe hash cu stare, aprobate pentru cazuri de utilizare specifice, în special semnarea firmware-ului în medii cu resurse limitate. Necesită gestionarea atentă a stării pentru a evita reutilizarea cheilor.
• AES-256 și SHA-384 — păstrate din CNSA 1.0 pentru criptarea simetrică și hashing; acestea nu sunt amenințate de calculatoarele cuantice la scară practică.

Algoritmii deprecați care trebuie eliminați treptat în cadrul CNSA 2.0 includ: RSA (toate dimensiunile cheilor, toate aplicațiile), ECDH și ECDSA (toate curbele), Diffie-Hellman (clasic și pe curbe eliptice) și SHA-256 pentru aplicațiile NSS (unde SHA-384 este acum obligatoriu). AES-128 și AES-192 sunt de asemenea deprecate în favoarea AES-256 pentru NSS.

Algoritmii aprobați în detaliu

ML-KEM (Module-Lattice Key Encapsulation Mechanism) se bazează pe dificultatea problemei Module Learning With Errors (MLWE) — o problemă de rețele pe care niciun algoritm cuantic sau clasic cunoscut nu o rezolvă eficient. ML-KEM funcționează ca un mecanism de încapsulare a cheilor: expeditorul încapsulează un secret partajat sub cheia publică a destinatarului; destinatarul decapsulează pentru a recupera secretul partajat. Secretul partajat alimentează apoi o funcție de derivare a cheii simetrice. ML-KEM-1024 produce chei publice de 1.568 octeți, texte cifrate de 1.568 octeți și secrete partajate de 32 octeți — mai mari decât cheile RSA-2048 (256 octeți), dar acceptabile pentru cele mai multe contexte de protocol.

ML-DSA (Module-Lattice Digital Signature Algorithm) se bazează pe dificultatea problemelor Module Short Integer Solution (MSIS) și MLWE. ML-DSA-87 (cel mai înalt nivel de securitate, corespunzând securității AES-256) produce chei publice de 2.592 octeți și semnături de 4.627 octeți. Prin comparație, ECDSA P-256 produce semnături de 64 octeți. Dimensiunile mai mari ale semnăturilor necesită ajustări în protocoalele și sistemele de stocare care au presupus semnături compacte — lanțurile de certificate, imaginile firmware și legăturile cu limitări de lățime de bandă necesită planificare de capacitate.

SLH-DSA (Stateless Hash-Based Digital Signature Algorithm) nu are structură algebrică exploatabilă de către algoritmi clasici sau cuantici dincolo de atacurile generice asupra funcțiilor hash; securitatea sa se reduce în întregime la rezistența la coliziuni a funcției hash subiacente. Compromisul este performanța și dimensiunea: semnăturile SLH-DSA-SHA2-256s au 29.792 octeți la cel mai mic set de parametri, iar semnarea este cu ordine de mărime mai lentă decât ML-DSA. SLH-DSA este potrivit ca algoritm secundar de semnătură pentru a oferi diversitate de securitate, în special pentru semnarea firmware-ului și software-ului, unde dimensiunea semnăturii și frecvența semnării sunt gestionabile.

Cele patru faze de migrare

O migrare CNSA 2.0 bine structurată parcurge patru faze. Organizațiile pot fi în faze diferite simultan pentru diferite tipuri de sisteme — o organizație mare de apărare va avea de obicei migrarea PKI în Faza 2, în timp ce sistemele tactice la margine sunt încă în Faza 1.

Faza 1 — Inventar criptografic. Înainte de a planifica orice lucrare de migrare, organizația trebuie să știe ce are. Inventarul criptografic cuprinde: fiecare endpoint TLS și suitele sale de cifruri negociate; fiecare certificat în uz (utilizator, dispozitiv, serviciu, semnare cod) și algoritmul cheii și data de expirare ale acestuia; fiecare gateway VPN și configurația sa de schimb de chei IKEv2; fiecare sistem de gestionare a cheilor, HSM și token criptografic; fiecare conductă de semnare firmware și tipul cheii de semnare; și fiecare arhivă de date unde este necesară confidențialitatea pe termen lung și algoritmul cheii de criptare.

Instrumentele automate ajută — scanere TLS (SSLyze, testssl.sh), analiză SBOM pentru dependențele bibliotecilor criptografice și platforme de gestionare a certificatelor cu raportare a algoritmilor. Dar instrumentele automate omit implementările de protocoale personalizate, criptografia firmware încorporat și criptografia la nivel de aplicație din afara bibliotecilor standard. Revizuirea manuală a documentației de arhitectură și a codului sursă este necesară pentru completitudine.

Faza 2 — Prioritizare bazată pe risc. Nu toate dependențele criptografice prezintă un risc HNDL egal. Prioritizarea ar trebui să reflecte două dimensiuni: longevitatea și sensibilitatea datelor protejate, și fezabilitatea migrării pe termen scurt. Țintele cu prioritate ridicată sunt sistemele care protejează date clasificate cu durată lungă de viață, unde expunerea HNDL este cea mai mare: CA-urile rădăcină și emitente PKI (ale căror chei protejează ancora de încredere pentru întreaga organizație), infrastructura de gestionare a cheilor (HSM-uri care dețin chei master pentru arhivele criptate), legăturile de comunicații strategice și orice sistem care criptează date cu o cerință de confidențialitate care depășește cinci ani.

Cu prioritate mai scăzută — dar totuși necesare înainte de 2030 — sunt sistemele cu cicluri frecvente de reînnoire hardware (platforme tactice, dispozitive ale utilizatorilor finali) unde capacitatea PQC poate fi încorporată la următoarea reînnoire naturală, și sistemele interne care protejează date neclasificate, unde riscul cuantic este mai mic.

Faza 3 — Operare hibridă. În timpul migrării, sistemele vor interopera atât cu omologii CNSA 1.0 (clasici), cât și CNSA 2.0 (post-cuantici). Criptografia hibridă — combinând algoritmi clasici și post-cuantici în același schimb de protocol — oferă rezistență cuantică pe traficul curent fără a necesita ca toate endpoint-urile să accepte simultan algoritmi post-cuantici.

Într-o conexiune TLS 1.3 hibridă, clientul include atât un schimb de chei ECDHE cât și un schimb de chei ML-KEM în ClientHello; serverul răspunde cu ambele. Cheia de sesiune finală este derivată din ambele secrete partajate utilizând o funcție de derivare a cheii. Un adversar trebuie să spargă atât algoritmii clasici cât și cei post-cuantici pentru a compromite sesiunea. Această abordare „centură și bretele" este aprobată explicit de NSA pentru perioada de tranziție.

Faza 4 — Tranziție completă. Odată ce toate sistemele acceptă algoritmi post-cuantici și operarea hibridă s-a dovedit stabilă în producție, suitele de cifruri și tipurile de certificate exclusiv clasice sunt retrase. Eliminarea trebuie coordonată cu toate organizațiile care interoperează, furnizorii și națiunile partenere. Stabiliți monitorizarea pentru a detecta orice negociere reziduală de algoritmi clasici (care ar indica un sistem omis în inventar sau că un furnizor nu a livrat încă software compatibil cu CNSA 2.0), și urmăriți etapele de eliminare față de termenul limită din 2030.

Sisteme cu prioritate ridicată și secvențierea migrării

În cadrul backlog-ului de migrare prioritizat, anumite tipuri de sisteme apar în mod constant ca priorități ridicate în practic toate organizațiile de apărare și ar trebui secvențiate devreme, indiferent de specificul organizațional.

Infrastructura de gestionare a cheilor. HSM-urile și serviciile de gestionare a cheilor (KMS-urile) sunt dependențe pentru migrarea aproape oricărui alt sistem — cheile post-cuantice trebuie generate, stocate și gestionate undeva. Actualizarea firmware-ului HSM pentru a accepta operații ML-KEM și ML-DSA, și verificarea faptului că API-urile de gestionare a cheilor expun tipuri de chei post-cuantice aplicațiilor consumatoare, reprezintă lucrări din Faza 1–2 în orice program de migrare. Acesta este și locul unde implicarea furnizorilor este cea mai critică: furnizorii de HSM variază semnificativ în foile lor de parcurs PQC, iar unele generații de hardware nu pot fi actualizate pe loc.

CA-urile rădăcină și emitente PKI. Ierarhia de încredere PKI stă la baza autentificării bazate pe certificate în întreaga organizație. Stabilirea CA-urilor rădăcină post-cuantice — și distribuirea ancorelor lor de încredere tuturor părților care se bazează pe acestea (browsere, sisteme de operare, clienți TLS, validatori OCSP) — este o condiție prealabilă pentru emiterea de certificate post-cuantice oricărui sistem. Aceasta trebuie să se întâmple înainte ca certificatele post-cuantice să poată fi implementate în altă parte. Un model de emitere duală, unde același CA emite atât certificate clasice cât și post-cuantice pentru fiecare subiect, permite migrarea graduală a părților care se bazează pe sistem fără a întrerupe relațiile de încredere existente.

Gateway-uri VPN și platforme de comunicații criptate. Gateway-urile VPN care protejează perimetrele rețelelor clasificate sunt ținte principale HNDL. IKEv2, protocolul de schimb de chei utilizat în majoritatea soluțiilor VPN enterprise, trebuie actualizat pentru a negocia ML-KEM pentru stabilirea cheilor și ML-DSA pentru autentificare. Majoritatea furnizorilor de VPN enterprise (Cisco, Palo Alto, Juniper, Check Point) au elemente în foaia de parcurs PQC, dar disponibilitatea funcționalităților și conformitatea cu parametrii CNSA 2.0 variază semnificativ — aceasta este o întrebare critică de calificare a furnizorilor în achiziții.

Platforme de comunicații și mesagerie criptată. Sistemele utilizate pentru comunicații de comandă strategică, diseminarea informațiilor și coordonarea misiunilor critice sunt ținte cu prioritate ridicată deoarece sensibilitatea și longevitatea traficului sunt ridicate. Corvus.Quantum, platforma de streaming a Corvus Intelligence pentru apărare, este concepută pentru alinierea la CNSA 2.0 — incorporând ML-KEM pentru stabilirea cheilor și ML-DSA pentru semnarea mesajelor în arhitectura sa de streaming și mesagerie, sprijinind operarea hibridă în perioada de tranziție.

Conducte de semnare firmware. Sistemele de arme și platformele hardware militare utilizează semnături digitale pentru a verifica integritatea firmware-ului. Aceste semnături au o durată lungă de viață — cheia de semnare poate acoperi întreaga viață de producție a unei platforme, întinzându-se pe un deceniu sau mai mult — și sunt prin urmare direct expuse riscului HNDL. Noile platforme care intră în producție ar trebui să fie livrate cu semnare firmware ML-DSA sau SLH-DSA de la prima livrare. Platformele în serviciu necesită o campanie de re-semnare a imaginilor firmware acolo unde arhitectura de boot acceptă rotația cheilor; platformele unde cheile de semnare sunt fuzionate la fabricație necesită documentare explicită a riscurilor.

Cum să inventariați dependențele criptografice

Inventarul criptografic este în mod constant faza cea mai subestimată a programelor de migrare PQC. Organizațiile care încep migrarea presupunând că inventarul va dura săptămâni descoperă de obicei că necesită luni, deoarece criptografia este implementată în mai multe straturi de sistem și mai multe căi de cod decât are orice echipă singulară vizibilitate completă.

O strategie cuprinzătoare de inventariere combină patru abordări. Prima, descoperirea la nivel de rețea: analiza pasivă a traficului TLS și scanarea activă a tuturor endpoint-urilor accesibile utilizând instrumente care amprentează suitele de cifruri negociate și algoritmii cheilor certificatelor. Aceasta capturează servere web, endpoint-uri API, echilibratori de încărcare și comunicații service-mesh care utilizează TLS standard. A doua, enumerarea platformei de gestionare a certificatelor: interogarea ierarhiei CA a organizației și orice jurnale CT (Certificate Transparency) publice pentru certificate purtând numele organizației, extragând algoritmul cheii și data de expirare pentru fiecare. A treia, analiza SBOM: extragând Software Bill of Materials din aplicațiile implementate și scanând dependențele bibliotecilor criptografice (OpenSSL, BoringSSL, libgcrypt, NSS, furnizori de criptografie Java) și versiunile acestora. Versiunile bibliotecilor criptografice determină algoritmii disponibili și care sunt valorile implicite. A patra, revizuirea documentației de arhitectură: identificând implementările de protocoale personalizate, derivarea cheilor în proces, coloanele de baze de date criptate și criptografia la nivel de aplicație pe care scanarea rețelei nu o poate observa.

Rezultatul inventarului ar trebui să fie un registru structurat cu cel puțin: numele sistemului, tipul dependenței criptografice (TLS, certificat, KEM, semnătură, simetric), algoritmul și dimensiunea cheii, biblioteca sau implementarea, clasificarea datelor protejate și complexitatea estimată a migrării. Acest registru conduce prioritizarea din Faza 2 și oferă baza de referință pentru urmărirea progresului conformității.

Întrebări pentru furnizori în timpul achizițiilor

Organizațiile de apărare care achiziționează software și hardware comercial de pe raft trebuie să evalueze pregătirea CNSA 2.0 ca parte a achizițiilor. Următoarele întrebări disting furnizorii cu capacitate PQC autentică de cei cu promisiuni din foile de parcurs:

Specificul suportului pentru algoritmi. „Produsul dumneavoastră acceptă ML-KEM-1024, ML-DSA-87 și SLH-DSA-SHA2-256s, astfel cum sunt definite în FIPS 203, 204 și 205?" Furnizorii care răspund cu afirmații generice de „suport post-cuantic" fără desemnări FIPS specifice și niveluri de parametri sunt puțin probabil să îndeplinească cerințele specifice ale CNSA 2.0. Suportul algoritmilor la niveluri de parametri mai mici (ML-KEM-512, ML-DSA-44) nu satisface nivelurile de securitate mandatate de CNSA 2.0 pentru NSS.

Disponibilitatea suitelor de cifruri hibride. „Implementarea dumneavoastră TLS acceptă schimbul de chei hibrid ML-KEM + ECDHE într-un singur handshake?" Suportul hibrid permite organizației să înceapă să beneficieze de rezistența cuantică pe traficul existent fără a necesita ca toate părțile care interoperează să finalizeze simultan migrarea PQC.

Acomodarea dimensiunilor cheilor. „Cum gestionează sistemul dumneavoastră dimensiunile mai mari ale cheilor și semnăturilor algoritmilor post-cuantici?" Semnăturile ML-DSA-87 au aproximativ 4,6 KB față de cei 64 octeți ai ECDSA P-256. Sistemele cu buffere de certificate sau semnături de dimensiune fixă, scheme de baze de date cu lungimi fixe ale câmpurilor criptografice sau protocoale de rețea cu ipoteze stricte de MTU pot necesita modificări arhitecturale pentru a acomoda materialul cheilor PQC.

Proveniența bibliotecii criptografice. „Ce bibliotecă criptografică stă la baza implementării dumneavoastră PQC și care este cadența de actualizare a versiunilor?" Implementările post-cuantice în OpenSSL, BoringSSL și Bouncy Castle sunt încă în maturizare; cadența de actualizare a furnizorului determină cât de repede ajung patch-urile de securitate la produsele implementate.

Foaia de parcurs post-2030. „Care este planul dumneavoastră pentru operarea exclusiv PQC după 2030, când modul hibrid și algoritmii clasici sunt eliminați?" Furnizorii fără o foaie de parcurs concretă post-2030 reprezintă un risc de conformitate care va necesita tranziții gestionate în cel mai prost moment posibil — când termenul limită este iminent.

Procesul de planificare a migrării CNSA 2.0 în șase pași

Pașii următori distilează fazele de migrare de mai sus într-o secvență de planificare acționabilă pentru echipele IT și de securitate din apărare care inițiază un program de conformitate CNSA 2.0.

Pasul 1 — Efectuați un inventar criptografic. Implementați scanarea TLS, raportarea gestionării certificatelor, analiza SBOM și revizuirea documentației de arhitectură în toate sistemele. Produceți un registru structurat al fiecărei dependențe criptografice: tip, algoritm, dimensiunea cheii, bibliotecă, clasificarea datelor și complexitatea estimată a migrării. Așteptați-vă ca acest pas să dureze 2–6 luni pentru o organizație de apărare de dimensiuni medii spre mari. Nu avansați la planificare fără un inventar rezonabil de complet — planurile de migrare construite pe inventar parțial vor omite sistemele cu prioritate ridicată.

Pasul 2 — Evaluați riscul și prioritizați sistemele. Notați fiecare element de inventar pe două axe: riscul HNDL (sensibilitatea și longevitatea datelor protejate) și fezabilitatea migrării (capacitatea echipei, pregătirea furnizorilor, complexitatea arhitecturală). Produceți un backlog de migrare prioritizat cu efort estimat, dependențe între elemente și atribuirea unui proprietar. Elementele care protejează date clasificate cu durată lungă de viață și complexitate scăzută de migrare ar trebui să fie la vârf, indiferent de politica organizațională.

Pasul 3 — Actualizați mai întâi gestionarea cheilor și infrastructura PKI. Migrați HSM-urile la firmware compatibil cu CNSA 2.0. Emiteți certificate CA rădăcină post-cuantice. Stabiliți capacitatea de emitere duală. Distribuiți ancora de încredere actualizată către părțile care se bazează pe sistem. Această fază este o dependență pentru toate migrările ulterioare bazate pe certificate și ar trebui să fie alocată cu resurse și inițiată imediat după finalizarea inventarului.

Pasul 4 — Implementați suite de cifruri hibride pe căile de rețea cu prioritate ridicată. Activați suitele de cifruri hibride ML-KEM pe gateway-urile VPN, perimetrele rețelelor clasificate și platformele de comunicații. Acest pas oferă reducerea imediată a riscului HNDL pe traficul curent fără a necesita pregătire PQC completă pe toate endpoint-urile. Monitorizați ratele de negociere pentru a urmări adoptarea.

Pasul 5 — Migrați semnarea firmware-ului și lanțul de aprovizionare software. Tranziționați conductele de semnare firmware la chei ML-DSA sau SLH-DSA pentru toate platformele care intră în producție. Efectuați campanii de re-semnare pentru platformele în serviciu acolo unde este arhitectural fezabil. Actualizați conductele de semnare a codului CI/CD. Documentați platformele cu restricții ca datorie tehnică criptografică gestionată cu acceptare explicită a riscului.

Pasul 6 — Executați tranziția completă și eliminați algoritmii clasici. Odată ce toate sistemele cu prioritate ridicată acceptă algoritmi post-cuantici și operarea hibridă este stabilă, începeți retragerea suitelor de cifruri și tipurilor de certificate clasice conform unui calendar coordonat cu organizațiile care interoperează. Stabiliți un tablou de bord de conformitate. Vizați eliminarea completă a algoritmilor clasici până în 2030, în conformitate cu îndrumările NSA.

Lecturi suplimentare

Pentru o acoperire mai aprofundată a algoritmilor post-cuantici subiacenți și a implicațiilor lor pentru apărare, consultați Criptografie post-cuantică pentru apărare: ghid CNSA 2.0. Pentru infrastructura de gestionare a cheilor și a secretelor care susține migrarea PQC, consultați Gestionarea secretelor în conductele CI/CD de apărare: Vault, HSM și rotația cheilor. Pentru arhitectura zero-trust ca strat de securitate complementar, consultați Arhitectura zero-trust pentru rețelele militare: principii și implementare.