Come migrare alla crittografia post-quantistica: ML-KEM, ML-DSA e approccio ibrido

Quando il team capisce che il rischio quantistico è reale, il pendolo spesso oscilla da “non è un mio problema” direttamente a “cambiamo tutto adesso”. Entrambi gli estremi si intromettono. La migrazione alla crittografia post-quantistica è un progetto di ingegneria con sequenza, priorità e attenzione, non un pulsante.

Con gli standard NIST finalizzati, c’è un posto dove migrare. ML-KEM si occupa della creazione delle chiavi, ML-DSA si occupa della firma digitale e SLH-DSA funge da firma di backup con basi matematiche diverse. Sapere dove andare è metà dell'opera. L'altra metà lo sta facendo senza rompere ciò che funziona.

Questo testo è la tabella di marcia pragmatica: da dove iniziare, come ordinare, di cosa occuparsi durante l'implementazione e perché la transizione attraversa una fase ibrida.

Inizia con l'inventario, non con l'algoritmo

La domanda “quale algoritmo adotto” è allettante e prematura. Prima ne arriva un altro: "dove utilizzo la crittografia oggi". La maggior parte delle organizzazioni risponde con il silenzio, e questo silenzio è il rischio più grande del progetto.

Non puoi migrare ciò che non puoi vedere. Prima di toccare qualsiasi libreria, è necessario un inventario crittografico: dove sono chiavi e certificati, quali librerie e versioni utilizzano le applicazioni, quali protocolli sono alla base delle loro connessioni e quali fornitori e integrazioni entrano in questa catena.

Questa indagine definisce la reale dimensione del problema e svela le dipendenze nascoste, quelle che nessuno ha documentato ma che bloccano la produzione se manomesse incautamente. Dell'inventario mi occupo approfonditamente in un articolo specifico della serie, perché è il fondamento di tutto ciò che verrà dopo.

Senza inventario, qualsiasi piano di migrazione è una supposizione. Con l'inventario, sai cosa hai, cosa è fondamentale e cosa può aspettare.

Stabilisci la priorità in base alla validità e all'esposizione dei dati

Migrare tutto in una volta è costoso, rischioso e non necessario. Il sequenziamento intelligente segue il rischio e il rischio si concentra su due assi.

Il primo asse è la validità della riservatezza. I dati che devono rimanere segreti per molti anni sono maggiormente minacciati dal "raccolto ora, decrittografato in seguito", l'acquisizione di dati crittografati oggi per essere decrittografati con il calcolo quantistico in futuro. Quanto più lunga è la validità del segreto, tanto prima avrà bisogno di protezione post-quantistica.

Il secondo asse è l’esposizione. I flussi che attraversano le reti catturabili, le integrazioni esterne e tutto ciò che negozia chiavi su internet si spostano in coda, perché è lì che avviene l’harvesting. I sistemi interni, isolati e di basso valore possono aspettare.

Esiste anche una differenza di urgenza tra i due usi della crittografia. Lo stabilimento chiave, il territorio di ML-KEM, è una priorità assoluta a causa del raccolto immediato: i dati acquisiti oggi possono essere letti in seguito. Le firme digitali, territorio della ML-DSA, hanno un’urgenza diversa, perché una firma contraffatta richiede la macchina quantistica esistente al momento della frode, non prima. Ciò non lo rende ignorabile, soprattutto per cose di lunga durata come i certificati root e la firma del firmware, ma aiuta a organizzare lo sforzo.

ML-KEM e ML-DSA: a cosa servono ciascuno

Vale la pena fissare i ruoli per non confondersi durante la pianificazione.

ML-KEM, FIPS 203, è un meccanismo di incapsulamento chiave. In pratica è ciò che stabilisce la chiave segreta condivisa che protegge una connessione. È il sostituto diretto dello scambio di chiavi che attualmente dipende da RSA ed ECC, ed è quindi il primo obiettivo della migrazione nei flussi sensibili.

ML-DSA, FIPS 204, è la firma digitale. Garantisce autenticità e integrità: che un aggiornamento software provenga da chi dice di essere, che un certificato sia legittimo, che un documento non sia stato alterato. Riguarda la migrazione PKI, la firma del codice e i processi di verifica.

Anche SLH-DSA, FIPS 205, firma, ma si basa sull'hashing, con premesse diverse. È più conservatore e tende a generare abbonamenti più grandi. È preziosa come riserva strategica in cui l’estrema longevità e la diversità dei fondamentali ne compensano il costo.

Tieni presente che questi algoritmi non vivono liberamente. Arrivano alla tua attività da librerie, librerie di protocolli, fornitori di servizi cloud e sistemi operativi. Gran parte della migrazione consisterà nell'aggiornare e configurare queste dipendenze man mano che incorporano gli standard, anziché implementare manualmente la crittografia.

L'approccio ibrido durante la transizione

Passare bruscamente dagli algoritmi classici a quelli post-quantistici è rischioso e l’industria è convergente su una risposta più sobria: la modalità ibrida.

In uno scambio di chiavi ibrido, si combina l’algoritmo classico come ECC con quello post-quantistico come ML-KEM, derivando la chiave di sessione dai due. La connessione è sicura solo se lo sono entrambi. Ciò fornisce un’importante garanzia durante la transizione: ottieni protezione contro la minaccia quantistica senza rinunciare alla maturità dell’algoritmo classico.

La logica è quella della prudenza. Gli algoritmi post-quantistici sono robusti sulla carta, ma hanno un chilometraggio operativo molto inferiore rispetto a RSA ed ECC. Se nella componente post-quantistica si manifesta una debolezza implementativa o un problema inaspettato, la componente classica mantiene ancora il livello. E se la minaccia quantistica si materializza, la componente classica cade, ma quella post-quantistica mantiene la protezione.

Il costo dell’ibrido è reale: chiavi e handshake più grandi, maggiore elaborazione, ottimizzazione del protocollo. Ma è il percorso che stanno intraprendendo i fornitori più seri e adottarlo ti mette in sintonia con l’ecosistema piuttosto che contro di esso.

Cura realizzativa che separa il serio dal frettoloso

Un algoritmo approvato non è sinonimo di implementazione sicura. È qui che i progetti ben intenzionati vengono danneggiati.

Non implementare da solo la crittografia post-quantistica. Utilizzare librerie mature, controllate e mantenute attivamente. I parametri di questi algoritmi sono sensibili e i dettagli di implementazione, come la perdita del canale laterale, trasformano un algoritmo potente in una protezione contro le perdite. Questo è lavoro di esperti e revisione del codice, non improvvisazione.

Pianificare le nuove dimensioni. Le chiavi, le firme e i messaggi di handshake post-quantici sono più grandi di quelli classici. Ciò influisce sulla dimensione dei pacchetti, sui limiti del protocollo, sui certificati, sull'archiviazione e sulle prestazioni. I sistemi che hanno assunto dimensioni ridotte nella progettazione possono rompersi in modi subdoli. Testare sotto carico e in condizioni di rete reali.

Prenditi cura delle prestazioni e della compatibilità. La negoziazione dell'algoritmo tra client e server nelle diverse fasi della migrazione richiede pianificazione, altrimenti si interrompono le connessioni legittime. E garantire la capacità di rollback: se un aggiornamento post-quantistico causa un problema nella produzione, è necessario un modo sicuro per tornare indietro, il che ci porta al tema della cripto-agilità.

Soprattutto, progettare per cambiare ancora. La crittografia post-quantistica si evolverà, i parametri verranno adeguati e non vorrai ripetere un progetto lungo anni ad ogni modifica. Coloro che isolano la crittografia dietro livelli ben definiti modificano gli algoritmi con poche modifiche. Chiunque diffonda cifre nel codice ne soffrirà.