Calendario CNSA 2.0: algoritmi e scadenze spiegati

CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) è l'insieme di algoritmi post-quantum che la NSA richiede per i National Security Systems (NSS) statunitensi e per i prodotti commerciali impiegati al loro interno. La suite comprende ML-KEM-1024 per lo scambio di chiavi, ML-DSA-87 per le firme di uso generale, LMS e XMSS per la firma di software e firmware, AES-256 per la cifratura simmetrica e SHA-384 o SHA-512 per l'hashing. L'uso esclusivo è richiesto entro la fine del 2030 per la firma di software e firmware e per gli apparati di rete tradizionali, ed entro la fine del 2033 per browser e server web, servizi cloud, sistemi operativi e apparati di nicchia.

A chi si applica CNSA 2.0

CNSA 2.0 non è una regola generale sulla crittografia negli Stati Uniti e non è uno standard internazionale. Disciplina i National Security Systems: i sistemi che trattano informazioni classificate o che sono critici per le funzioni militari e di intelligence. Riguarda tre gruppi di soggetti. In primo luogo, le organizzazioni che possiedono e gestiscono tali sistemi. In secondo luogo, gli integratori che li realizzano. In terzo luogo, ed è il gruppo che più spesso viene colto di sorpresa, i fornitori commerciali i cui prodotti vengono acquistati per questi sistemi.

Le agenzie federali civili seguono un percorso diverso. I loro obblighi derivano dall'Executive Order 14412 (22 giugno 2026) e dal memorandum OMB M-26-15 (24 giugno 2026), sintetizzati nella nostra pagina sul post-quantum federale statunitense: inventario crittografico automatizzato, piani di migrazione delle agenzie da presentare entro il 22 ottobre 2026, TLS 1.3 obbligatorio entro il 2 gennaio 2030, sistemi ad alto valore con scambio di chiavi post-quantum entro la fine del 2030 e con firme post-quantum entro la fine del 2031, migrazione completa entro il 2035 ai sensi di NSM-10. I due percorsi vanno nella stessa direzione, ma date e ambito differiscono. Fate riferimento a quello che si applica al contratto che avete davanti. Le tappe datate di CNSA 2.0 sono raccolte nella nostra pagina di riferimento su CNSA 2.0.

Questo articolo ha carattere informativo e non costituisce consulenza legale. Le clausole di approvvigionamento di un contratto specifico prevalgono sempre su una sintesi generale.

La suite di algoritmi

CNSA 2.0 non si limita a dire post-quantum. Indica i set di parametri, e indica i più elevati.

Tre punti meritano attenzione. ML-KEM è la forma standardizzata di CRYSTALS-Kyber, pubblicata dal NIST come FIPS 203 il 13 agosto 2024 insieme a FIPS 204 (ML-DSA) e FIPS 205 (SLH-DSA). I gruppi Kyber pre-standard come X25519Kyber768Draft00 sono obsoleti e non soddisfano alcun requisito. Inoltre, CNSA 2.0 richiede i set di parametri più alti, ML-KEM-1024 e ML-DSA-87, non l'ML-KEM-768 che i browser negoziano oggi per impostazione predefinita. Un prodotto che supporta solo X25519MLKEM768 è post-quantum, ma non è conforme a CNSA 2.0. Infine, la suite rimanda a LMS e XMSS, definiti in SP 800-208, per la firma di software e firmware. Si tratta di schemi con stato: la chiave di firma non deve mai riutilizzare un indice di chiave monouso, quindi l'infrastruttura di firma deve garantire la persistenza dello stato. SLH-DSA (FIPS 205) è senza stato e non compare nella suite descritta sopra.

AES-256 e la famiglia SHA-2 fanno parte della suite perché non sono compromessi dall'algoritmo di Shor. L'algoritmo di Grover è il motivo per cui AES-256 è preferito ad AES-128 per la protezione a lungo termine, e il motivo per cui le dimensioni degli hash partono da 384 bit.

Le scadenze, categoria per categoria

CNSA 2.0 fissa date per l'uso esclusivo, un requisito più severo del semplice supporto. Uso esclusivo significa che gli algoritmi CNSA 2.0 sono gli unici impiegati per quella funzione: RSA, ECDSA ed ECDH sono eliminati, non semplicemente declassati di priorità. Il supporto deve quindi arrivare con largo anticipo rispetto alla scadenza, perché entro quella data l'intero parco deve essere completamente convertito.

Queste date provengono dalle FAQ CNSA 2.0 versione 2.1 (dicembre 2024) e dall'avviso CNSA 2.0 Algorithms del 30 maggio 2025. L'ordine è voluto. La firma viene per prima perché una radice di firma ha una vita lunga: un firmware firmato oggi con una chiave ECDSA potrebbe essere ancora verificato da dispositivi sul campo tra dieci anni, e la riemissione di un trust anchor su un parco installato è lenta. Gli apparati di rete vengono per primi perché terminano i tunnel cifrati di lunga durata, il bersaglio più appetibile per gli attacchi harvest now, decrypt later: il traffico registrato è protetto solo dallo scambio di chiavi che ha generato le sue chiavi di sessione, quindi ciò che viene catturato oggi può diventare testo in chiaro domani. Browser, server, piattaforme cloud e sistemi operativi hanno tempo fino al 2033 perché la catena di dipendenze sottostante (librerie, moduli di sicurezza hardware, autorità di certificazione, stack di protocollo) è più profonda.

Perché interessa ai fornitori al di fuori degli Stati Uniti

Tre motivi, nessuno dei quali teorico.

• Le clausole di approvvigionamento si propagano. I requisiti CNSA 2.0 vengono inseriti nei contratti e nelle richieste di offerta. Un fornitore di componenti situato due o tre livelli più in basso in una filiera della difesa li eredita tramite il proprio cliente, non tramite il proprio regolatore.
• I set di parametri elevati sono una decisione di prodotto, non un'opzione di configurazione. ML-KEM-1024 e ML-DSA-87 modificano le dimensioni di chiavi e firme, degli handshake, delle immagini firmware e i requisiti dei moduli di sicurezza hardware. Una roadmap che si ferma a ML-KEM-768 richiederà un secondo passaggio.
• I requisiti europei non sono identici. L'ANSSI rende obbligatoria l'ibridazione nel proprio ambito regolamentato (qualificazione dei prodotti, procedure legate alla difesa, operatori di importanza vitale) e precisa che le sue altre raccomandazioni post-quantum non sono ancora obblighi normativi. BSI TR-02102-1 (versione 2026-01) è una linea guida tecnica che raccomanda lo scambio di chiavi post-quantum ibrido e ritiene accettabile lo scambio di chiavi classico usato da solo soltanto fino alla fine del 2031, o fino alla fine del 2030 per esigenze di protezione molto elevate. Un prodotto venduto su entrambi i mercati deve poter negoziare un gruppo ibrido e un set di parametri CNSA 2.0, il che è un argomento a favore della crypto-agility nel codice anziché di un'unica scelta cablata.

Se desiderate vedere tutte le scadenze ufficiali a confronto, la nostra panoramica sulle scadenze della migrazione post-quantum mette a confronto CNSA 2.0 con la roadmap UE, le date dell'NCSC britannico e il percorso federale statunitense.

Cosa verificare in questo trimestre

Iniziate in sola lettura, in ambiente di staging, e mantenete un fallback classico finché la scadenza che vi riguarda non è vicina.

Verificate quali gruppi il vostro stack TLS è effettivamente in grado di offrire. I gruppi ML-KEM richiedono OpenSSL 3.5 o successivo:

openssl version
openssl list -tls-groups

Cercate MLKEM1024 e SecP384r1MLKEM1024 oltre al diffusissimo X25519MLKEM768. I codepoint IANA sono pubblicati nel registro dei parametri TLS, e il meccanismo ibrido è specificato in RFC 10024 (agosto 2026).

Quindi verificate cosa negozia un server, un gruppo alla volta, su un host di staging:

openssl s_client -connect staging.example.com:443 -groups MLKEM1024 </dev/null 2>&1 | grep -i -E "negotiated|group"
openssl s_client -connect staging.example.com:443 -groups X25519MLKEM768 </dev/null 2>&1 | grep -i -E "negotiated|group"

Per la parte di firma, generate una coppia di chiavi ML-DSA-87 di prova e misurate l'effetto delle firme più grandi sulle dimensioni dei vostri artefatti, sul canale di aggiornamento e sui percorsi di codice di verifica:

openssl genpkey -algorithm ML-DSA-87 -out mldsa87-test.key

Tenete la chiave di prova fuori da qualsiasi trust store di produzione. Il lavoro più impegnativo è organizzativo: inventariare ogni radice di firma e la relativa scadenza, individuare i moduli di sicurezza hardware che devono supportare ML-DSA-87 o la firma basata su hash con stato, e pianificare la gestione dello stato richiesta da LMS e XMSS. La nostra guida su come migrare la firma del codice a ML-DSA illustra la sequenza delle operazioni, compresa la doppia firma durante la transizione.

Passo successivo: misurate ciò che esponete oggi

Le scadenze CNSA 2.0 riguardano ciò che i vostri prodotti e servizi negoziano effettivamente, non ciò che promette la vostra roadmap. Iniziate dal livello visibile dall'esterno: analizzate il vostro dominio con PQC Status per vedere quali gruppi di scambio di chiavi, versioni TLS e algoritmi di certificato offrono oggi i vostri endpoint. Usate il risultato come prima riga di un elenco delle lacune: endpoint privi di qualsiasi gruppo ML-KEM, endpoint che offrono solo ML-KEM-768 laddove un contratto CNSA 2.0 richiederà ML-KEM-1024, e catene di certificati ancora firmate con RSA o ECDSA. Una scansione descrive una configurazione TLS visibile dall'esterno. Non è una certificazione né un'attestazione di conformità, quindi affiancatela al vostro inventario interno di chiavi di firma, immagini firmware e librerie embedded.