Migrazione post-quantum cryptography (PQC): guida per le imprese alla transizione post-quantum

Migrazione post-quantum cryptography (PQC): guida per le imprese alla transizione post-quantum

Migrazione post-quantum cryptography (PQC): non si tratta più di un tema futuribile legato all’arrivo dei computer quantistici, ma di una trasformazione già necessaria per proteggere dati, comunicazioni e infrastrutture critiche. Con i primi standard NIST ormai definiti, il rischio “harvest now, decrypt later” già attivo e le roadmap europee orientate al 2030-2035, le organizzazioni sono chiamate ad avviare oggi un percorso strutturato basato su inventario crittografico, crypto-agility, sperimentazioni ibride e coinvolgimento della supply chain.

Migrazione post-quantum cryptography (PQC): perché iniziare ora

La crittografia che protegge oggi comunicazioni, firme e dati a riposo si regge su problemi matematici, come la fattorizzazione di grandi numeri, che un computer quantistico sufficientemente potente sarebbe in grado di risolvere. Quel computer non esiste ancora, ma il conto alla rovescia per la migrazione alla crittografia post-quantistica (PQC, Post-Quantum Cryptography) è già partito, per due ragioni concrete: gli standard sono pronti e una parte della minaccia è già attiva oggi. Questa guida spiega perché iniziare adesso e come impostare una migrazione ordinata, senza allarmismi ma senza rinvii.

La minaccia “harvest now, decrypt later”

L’errore più comune è ragionare come se il rischio scattasse solo il giorno in cui esisterà un computer quantistico crittograficamente rilevante. In realtà una categoria di avversari agisce già oggi con la logica harvest now, decrypt later: raccogliere e archiviare ora il traffico cifrato e i dati sensibili, per decifrarli in futuro quando la capacità quantistica sarà disponibile. Questo sposta la scadenza dal “quando arriverà il quantum” al “quanto a lungo devono restare riservati i miei dati”. Informazioni con un ciclo di vita lungo, come segreti industriali, dati sanitari, atti coperti da segreto e chiavi di lunga durata, sono esposte da subito. È il motivo per cui l’attesa passiva non è una strategia.

Gli standard ci sono già

Il principale ostacolo storico alla migrazione, l’assenza di algoritmi standardizzati, è caduto. Il 13 agosto 2024 il NIST (National Institute of Standards and Technology statunitense) ha pubblicato i primi tre standard PQC definitivi. Il FIPS 203 definisce ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, derivato da CRYSTALS-Kyber), il meccanismo di incapsulamento delle chiavi destinato a sostituire lo scambio di chiavi basato su RSA ed ECC. Il FIPS 204 definisce ML-DSA (Module-Lattice-Based Digital Signature Algorithm, da CRYSTALS-Dilithium), lo schema di firma digitale principale. Il FIPS 205 definisce SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, da SPHINCS+), una firma basata su funzioni hash pensata come alternativa di riserva nel caso emergessero debolezze nell’approccio a reticoli.

A questi si è aggiunto, l’11 marzo 2025, HQC (Hamming Quasi-Cyclic), selezionato dal NIST come secondo meccanismo di incapsulamento delle chiavi: si basa su codici correttori d’errore, una matematica diversa da quella a reticoli di ML-KEM, e funge da rete di sicurezza qualora il primo schema venisse compromesso. La bozza dello standard HQC è attesa entro il 2026 e la versione definitiva nel 2027. La logica della doppia famiglia, reticoli e codici, è deliberata: non concentrare tutta la fiducia su un’unica ipotesi matematica.

Resta atteso un ulteriore standard di firma, FN-DSA (derivato da FALCON), utile dove servono firme particolarmente compatte. La scelta tra gli schemi non è indifferente: ML-KEM e ML-DSA, basati su reticoli, offrono un buon equilibrio tra dimensioni e prestazioni e si prestano all’uso generale; SLH-DSA, basato su funzioni hash, è più conservativo e resistente nel lungo periodo ma produce firme più grandi e lente, adatte a casi come la firma del firmware; HQC, più oneroso in termini di banda, ha senso come riserva. Conoscere queste differenze evita di adottare uno schema inadatto al proprio contesto, che è uno degli errori più costosi in fase di migrazione.

Le scadenze: cosa dicono NIST ed ENISA

Avere gli standard non basta: le organizzazioni hanno bisogno di un orizzonte temporale. Il NIST lo ha fissato con chiarezza nella bozza di transizione (IR 8547): gli algoritmi a 112 bit di sicurezza, come RSA-2048 ed ECC P-256, sono destinati alla deprecazione entro il 2030 e al divieto entro il 2035. Il divieto del 2035, però, non riguarda solo i 112 bit: lo stesso documento prevede la messa al bando, dopo quel termine, anche degli algoritmi asimmetrici di forza superiore, come RSA-3072 ed ECC P-384. In altre parole, dal 2030 i parametri più deboli non andrebbero più usati per nuove implementazioni e dal 2035 l’intera crittografia a chiave pubblica oggi in uso non dovrebbe più essere impiegata nei sistemi conformi.

Sul versante europeo, la Roadmap sulla crittografia post-quantistica pubblicata a giugno 2025 dal NIS Cooperation Group (il gruppo di cooperazione previsto dalla direttiva NIS, con un Work Stream dedicato co-presieduto da Francia, Germania e Paesi Bassi), su raccomandazione della Commissione europea dell’aprile 2024 e con il supporto dell’ENISA (l’Agenzia dell’Unione europea per la cybersicurezza), articola la transizione su tre tappe: roadmap nazionali iniziali e prime attività di identificazione e consapevolezza entro fine 2026; copertura dei casi d’uso ad alto rischio, con PQC adottata come impostazione predefinita, entro il 2030; transizione completa, per quanto tecnicamente possibile, entro il 2035. Anche il National Cyber Security Centre britannico ha pubblicato traguardi analoghi scaglionati fino al 2035. Le date possono sembrare lontane, ma per infrastrutture complesse, hardware con cicli di vita lunghi e catene di fornitura articolate, dieci anni sono un orizzonte stretto.

Il primo passo: l’inventario crittografico

Non si migra ciò che non si conosce. La prima attività concreta, e quella che le organizzazioni rimandano più spesso, è l’inventario crittografico: mappare dove e come la crittografia è utilizzata nell’organizzazione. Quali protocolli, quali algoritmi, quali lunghezze di chiave, in quali applicazioni, su quali dispositivi, attraverso quali fornitori. In pratica la crittografia è ovunque e spesso invisibile: nei certificati TLS di siti web e API, nelle VPN, nella firma del codice e degli aggiornamenti software, nelle infrastrutture a chiave pubblica (PKI) interne, nei token di autenticazione, nei database cifrati e nei dispositivi embedded. Molte di queste dipendenze non sono documentate da nessuna parte, ed è proprio questo il valore dell’inventario: trasformare un patrimonio crittografico implicito in un elenco gestibile. Il risultato è una sorta di distinta crittografica, talvolta chiamata cryptography bill of materials (CBOM), che diventa la base di ogni decisione successiva. Sull’inventario si innesta la prioritizzazione: i sistemi che proteggono dati a lunga vita o che sono difficili da aggiornare vanno affrontati per primi, proprio per neutralizzare il rischio harvest now, decrypt later. Per chi vuole un quadro del contesto e delle implicazioni, resta utile il nostro approfondimento sulla crittografia post-quantistica.

Crypto-agility: progettare per il cambiamento

La lezione di fondo di questa transizione non riguarda un singolo algoritmo, ma la capacità di cambiarlo. La crypto-agility è la proprietà di un sistema di sostituire algoritmi e parametri crittografici senza doverne riprogettare l’architettura. Significa evitare implementazioni in cui l’algoritmo è cablato in profondità, astrarre le primitive crittografiche dietro interfacce ben definite, centralizzare la gestione delle chiavi e dei certificati. Le organizzazioni che hanno investito in crypto-agility non dovranno affrontare solo la migrazione a PQC, ma saranno attrezzate per ogni futura transizione, compresa la sostituzione di un eventuale algoritmo che si rivelasse debole. È un investimento architetturale, non un singolo progetto a termine.

La transizione ibrida

Durante il passaggio, l’approccio raccomandato da ENISA e da altri organismi tecnici europei è quello degli schemi ibridi, detti PQ/T (post-quantum e traditional): combinare un algoritmo post-quantistico con uno tradizionale, in modo che la protezione regga finché almeno uno dei due resta sicuro. La logica è prudenziale: gli algoritmi PQC sono nuovi e, sebbene sottoposti a anni di analisi, non hanno ancora il decennio di scrutinio pubblico dei loro predecessori; affiancarli a uno schema collaudato riduce il rischio di sorprese senza rinunciare alla protezione quantistica. In parallelo, per la crittografia simmetrica è in molti casi sufficiente adeguare le lunghezze delle chiavi, poiché è meno esposta rispetto alla crittografia asimmetrica. Vale la pena sottolineare che l’approccio ibrido non è teoria: lo scambio di chiavi ibrido post-quantistico è già attivo nel protocollo TLS adottato dai principali browser e da diversi fornitori cloud, segno che, almeno per i dati in transito, la transizione è già cominciata sul campo.

Dove la migrazione è più difficile

Non tutti gli ambienti si aggiornano con un semplice patch. I sistemi con cicli di vita lunghi e difficili da toccare pongono i problemi maggiori: dispositivi industriali e medicali, hardware embedded, smart card, certificati radice con validità decennale, infrastrutture critiche e sistemi satellitari. In questi contesti sostituire gli algoritmi può richiedere aggiornamenti firmware complessi o addirittura la sostituzione fisica dei dispositivi, con tempi che si misurano in anni. A ciò si aggiungono i vincoli di risorse: alcuni algoritmi PQC hanno chiavi e firme più grandi, un costo non trascurabile dove memoria e banda sono limitate. È in questi ambienti che la pianificazione anticipata fa la differenza tra una transizione governata e una corsa contro il tempo.

Una roadmap pratica per le imprese

Tradotto in passi operativi, un percorso sostenibile si articola così. Primo, costruire l’inventario crittografico e mantenerlo aggiornato. Secondo, classificare dati e sistemi per sensibilità e ciclo di vita, isolando i casi a maggiore esposizione harvest now, decrypt later. Terzo, valutare la crypto-agility dei sistemi esistenti e introdurla dove manca. Quarto, avviare progetti pilota sugli standard NIST, preferibilmente in modalità ibrida, partendo dai casi d’uso critici. Quinto, coinvolgere la catena di fornitura: chiedere ai fornitori i loro piani di migrazione PQC, perché la sicurezza di un sistema dipende anche dalle librerie e dai prodotti di terzi. Sesto, formare i team e allineare la roadmap interna alle scadenze normative del proprio settore. Una visione d’insieme del percorso è tracciata anche nella nostra analisi sulla sicurezza post-quantum.

La migrazione a PQC non è un adempimento da chiudere in una stagione, ma una trasformazione pluriennale che conviene governare oggi, mentre il tempo è ancora dalla parte di chi pianifica. Le organizzazioni che cominciano adesso dall’inventario e dalla crypto-agility affrontano un percorso graduale e controllabile; quelle che rinviano si troveranno a comprimere lo stesso lavoro in finestre sempre più strette, sotto la pressione di scadenze normative e di fornitori che chiederanno garanzie. Aspettare l’arrivo del computer quantistico per muoversi significherebbe scoprire, troppo tardi, che i dati da proteggere erano già stati raccolti.

Condividi sui Social Network:

Ultimi Articoli