Approfondimento Tech

Crittografia post-quantum sicura

Come prepararsi alla crittografia post-quantum: standard NIST, rischi per RSA/ECC, crypto-agility e codice “quantum-safe”.

computer quantistici

14 Gennaio 2026

Indice dei contenuti

  • Perché i computer quantistici sono un punto di svolta (senza magia)
  • Lo stato degli standard: cosa ha fatto (e sta facendo) il NIST
  • Comprendere le famiglie post-quantum (e come si scelgono)
  • Minaccia reale vs. hype: dove siamo con l’hardware quantistico
  • Roadmap operativa “quantum-safe” per aziende (crypto-agility al centro)
  • Focus infrastrutture critiche: energia e trasporti
  • Normativa e conformità: Europa e Stati Uniti
  • Esempio pratico: generare chiavi e fare un KEM “quantum-safe” con liboqs-python
  • Come portare TLS nell’era post-quantum: ibrido e rollout controllato
  • Prestazioni, costi e “sorprese” ingegneristiche
  • Casi d’uso: come iniziare in 90 giorni
  • Agire ora con crypto-agility, governare il cambiamento
  • (Appendice) Snippet operativi extra

La promessa (e la minaccia) dell’era quantistica è ormai concreta: i computer quantistici stanno accelerando, e con essi cresce il rischio che algoritmi asimmetrici oggi ubiqui RSA ed ECC diventino decifrabili in tempi utili per un attaccante.

Questo articolo spiega, in chiave pratica e approfondita, perché la computazione quantistica scardina alcuni pilastri della cifratura, cosa stanno facendo gli enti di standardizzazione (con il NIST in testa), e come impostare da subito una roadmap “quantum-safe” fondata su crypto-agility, migrazione ibrida e inventario delle dipendenze crittografiche.

Troverai esempi concreti di codice con librerie post-quantum, spunti architetturali per infrastrutture critiche (energia, trasporti) e indicazioni normative europee e statunitensi aggiornate.

Perché i computer quantistici sono un punto di svolta (senza magia)

Nel calcolo classico, la sicurezza degli schemi a chiave pubblica poggia su problemi matematici ritenuti intrattabili: fattorizzazione di grandi interi (cuore di RSA) e logaritmo discreto su curve ellittiche (ECC). Un computer quantistico universale e sufficientemente grande, eseguendo l’algoritmo di Shor, riduce questi problemi da “impraticabili” a “risolvibili in tempo polinomiale”: significa che, una volta disponibili qubit logici in numero e qualità sufficienti, le chiavi pubbliche potrebbero essere usate per derivare le corrispondenti chiavi private, vanificando confidenzialità e autenticità delle comunicazioni basate su RSA/ECC.

Gli schemi simmetrici (AES, SHA-2/3) subiscono principalmente la “sola” radice quadrata di vantaggio quantistico (algoritmo di Grover), mitigabile con chiavi più lunghe (es. AES-256). Quindi: il bersaglio primario è l’asimmetrico.

Due parole chiave per il rischio reale:

  • “Harvest now, decrypt later”
    Oggi si intercettano dati cifrati a lungo termine (sanitario, finanziario, segreti industriali) confidando di decifrarli domani con capacità quantistiche sufficienti. Anche una minaccia a 5-10 anni impone azioni immediate per dati con valore che dura nel tempo.
  • Persistenza delle dipendenze
    La crittografia è ovunque (TLS, PKI, firmware signing, VPN, IoT, protocolli ICS/SCADA). Smontare e rimontare questo ecosistema richiede anni.

Lo stato degli standard: cosa ha fatto (e sta facendo) il NIST

Nel 2024 il NIST ha pubblicato i primi tre FIPS “quantum-resistant”:

  • FIPS 203 (ML-KEM, derivato da CRYSTALS-Kyber) per accordo/trasporto di chiavi;
  • FIPS 204 (ML-DSA, derivato da CRYSTALS-Dilithium) per firme digitali generali;
  • FIPS 205 (SLH-DSA, derivato da SPHINCS+) per firme hash-based stateless, alternative conservative.

Nel 2025 il NIST ha inoltre annunciato la selezione di HQC (Hamming Quasi-Cyclic) per standardizzazione aggiuntiva (famiglia code-based), ampliando le opzioni per i KEM. La pagina ufficiale del progetto PQC del NIST sintetizza stato e documentazione, inclusi report e draft.

Sul fronte policy, l’NSA con la suite CNSA 2.0 ha fissato tempistiche: transizione avviata subito per il software/firmware signing, adozione generalizzata di algoritmi post-quantum e obbligatorietà progressiva entro il prossimo decennio (sostanziale “mandato” completo attorno al 2031–2035, con fasi e scadenze per i sistemi di sicurezza nazionale USA).

In Europa, la Commissione ha pubblicato nel 2025 una Coordinated Implementation Roadmap per la transizione alla crittografia post-quantum, coordinando Stati membri, operatori essenziali e filiere critiche. ENISA ha prodotto report tecnici su famiglie di algoritmi e mitigazioni. Questi documenti sono fondamentali per allineare la migrazione con NIS2, supply chain e servizi essenziali.

Comprendere le famiglie post-quantum (e come si scelgono)

Gli algoritmi post-quantum non si basano su fattorizzazione o logaritmo discreto, ma su problemi ritenuti resistenti ad attacchi quantistici: reticoli (lattice-based, come Kyber/Dilithium), hash-based (SPHINCS+), code-based (HQC), multivariate (meno adottati oggi), isogeny-based (in gran parte ridimensionati dopo attacchi crittanalitici). Ogni famiglia ha trade-off fra dimensioni delle chiavi, velocità, grandezza dei ciphertext/firme e caratteristiche di sicurezza.

Una prassi ragionevole per ambienti enterprise:

  • Prediligere KEM lattice-based (es. ML-KEM/Kyber) per il key agreement in protocolli tipo TLS e firme ML-DSA/Dilithium per code signing e autenticazione server.
  • Usare SLH-DSA/SPHINCS+ in contesti dove la robustezza conservativa hash-based (stateless) è prioritaria e il costo in dimensioni della firma è accettabile.
  • Tenersi aggiornati sui profili di sicurezza di standard e implementazioni (versioni FIPS, parametri approvati, certificazioni).

Il sito del progetto Open Quantum Safe (OQS) riassume bene algoritmi e parametri supportati, utile per prototipi e test.

Minaccia reale vs. hype: dove siamo con l’hardware quantistico

IBM ha comunicato nel 2025 una roadmap verso sistemi fault-tolerant (es. progetto Quantum Starling entro il 2029), evidenziando l’accelerazione industriale verso qubit logici (non solo fisici) e correzione d’errore su larga scala. Anche se la piena capacità di eseguire attacchi pratici a RSA/ECC non è “domani mattina”, il trend industriale e gli investimenti giustificano piani di migrazione immediati (specie per dati a lungo valore).

Sul fronte best practice, IBM propone strumenti e servizi “Quantum Safe” per discovery, analisi e remediation delle dipendenze crittografiche (Explorer, Remediator, Guardium Quantum Safe), allineati a una roadmap di adozione quantum-safe end-to-end.

Anche autorità nazionali come il NCSC del Regno Unito raccomandano percorsi a tappe fino al 2035 per gli operatori di infrastrutture critiche (energia, trasporti), enfatizzando che ridurre la superficie di attacco oggi è l’unico modo per mitigare il rischio “harvest now, decrypt later”.

Roadmap operativa “quantum-safe” per aziende (crypto-agility al centro)

La trasformazione quantum-safe non è (solo) sostituire RSA con Kyber. È un programma: multi-anno, trasversale, con governance e metriche. Qui una traccia operativa pronta per essere adottata come piano di migrazione.

1) Inventario delle chiavi e delle dipendenze

Mappa dove e come usi la crittografia:

  • Canali
    TLS (interno/esterno), VPN, SSH, mTLS, IPsec, Wi-Fi Enterprise.
  • Oggetti
    Certificati X.509, token OIDC/SAML, firmware signing, secure boot, immagini container, archivi cifrati, HSM, KMS.
  • Software & protocolli
    Versioni di OpenSSL/BoringSSL/WolfSSL, librerie TLS nelle app, terminatori L7, proxy, broker MQTT, database con TDE, backup cifrati.
  • Asset ICS/OT/IoT
    Gateway, PLC, RTU, sensori, radio, Edge e 5G industriale.

Strumenti di discovery (scanner sorgenti/binary, analisi traffico, inventari PKI) aiutano a stimare l’impatto: quante chiavi? con quali algoritmi? con quali durate? (Gli strumenti IBM Quantum Safe Explorer/Remediator sono un riferimento commerciale per questa fase.)

2) Valutazione rischio “data-lifetime”

Classifica i flussi/dati in funzione dell’orizzonte di segretezza e integrità richiesto:

  • Dati a lungo valore (sanitario, IP, difesa, telco core, finanziario regolato) vanno protetti ora con schemi resistenti o ibridi.
  • Dati transienti possono tollerare una migrazione successiva, ma solo se crypto-agility è già predisposta.

3) Abbracciare la crypto-agility

La crypto-agility è la capacità del sistema di aggiornare algoritmi, parametri e chiavi senza rifacimenti architetturali. Praticamente:

  • Strati di configurazione separati dal codice;
  • API KEM/SIG astratte;
  • Supporto a policy per “preferenze algoritmiche” a runtime;
  • Pipeline CI/CD con test di regressione crittografica;
  • PKI che gestisce formati e OID post-quantum, profili CSR/CRT aggiornati, OCSP/CRL adeguati;
  • HSM/KMS compatibili con nuovi schemi (o “offload” software di transizione).

4) Criptografia ibrida come ponte

Nella fase di transizione, adotta handshake ibridi (es. X25519+ML-KEM/Kyber) e dual-sign (es. ECDSA+ML-DSAo RSA+SLH-DSA): se una componente venisse compromessa, l’altra mantiene la sicurezza. È l’approccio sostenuto in molte raccomandazioni industriali e di community tecniche (IETF/TLS, esperimenti in browser e stack TLS).

5) Priorità: firmware/software signing

Le linee CNSA 2.0 e il buon senso convergono: metti subito in priorità il code/firmware signing (supply-chain!). Pianifica il passaggio a ML-DSA (Dilithium) o SLH-DSA (SPHINCS+) per i componenti più sensibili e a lunga vita sul campo (PLC, dispositivi medicali, apparati di rete).

6) Aggiornabilità end-to-end

Progetta canali di update sicuri (firmware-over-the-air, gestione certificati) compatibili con dimensioni maggiori di chiavi/firme, latenza, memoria. Valuta impatto su MTU, frammentazione, handshake più “pesanti” e su acceleratori(HSM, NIC TLS offload).

7) Governance, metriche, audit

Definisci KPI: % di traffico coperto da KEM post-quantum/ibrido, % di binari firmati con ML-DSA/SLH-DSA, Mean Time to Crypto-Change (quanto impieghi a ruotare algoritmo/parametri), conformità a roadmap UE e requisiti di settore (pagamenti, sanità, energia). Documenta nel risk register.

Focus infrastrutture critiche: energia e trasporti

Nei sistemi OT la migrazione è più difficile: device legacy, finestre di manutenzione rare, requisiti real-time, apparecchiature distribuite (linee elettriche, sottostazioni, SCADA di linea ferroviaria, sistemi di segnalamento). Suggerimenti pratici:

  • Segmentazione e “crypto gateways”
    Se non puoi aggiornare il PLC, cifra e autentica a monte, in un gateway Edge che termina TLS 1.3 ibrido o tunnel “quantum-safe” verso il control center.
  • Firmware signing prima di tutto
    Garantisci che solo firmware firmato con schema post-quantum possa essere installato, anche se la comunicazione resta legacy per un periodo.
  • Telecontrollo
    Per collegamenti a bassa banda (RM/PMR, VSAT), pianifica formati di firma compatti (es. ML-DSA a parametri adeguati) e rotazione chiavi con pre-posizionamento.
  • Supply chain
    Impone requisiti quantum-safe nei capitolati, chiedendo prove di crypto-agility ai vendor (roadmap, laboratori, conformità FIPS).

Il NCSC UK suggerisce tappe per completare la migrazione al 2035: utile come riferimento temporale per operatori essenziali che devono pianificare con ampio anticipo.

Firmware signing

Normativa e conformità: Europa e Stati Uniti

  • Unione Europea
    La Coordinated Implementation Roadmap del 2025 definisce raccomandazioni operative per Stati membri e stakeholder, coerenti con NIS2. Preparati ad audit e richieste di piani di transizione.
  • Stati Uniti
    NIST ha finalizzato FIPS 203/204/205; l’NSA con CNSA 2.0 indica scadenze e preferenze architetturali. Aspettati riflessi sulle forniture globali (prodotti “FIPS-validated”, profili DoD/FedRAMP).
  • Linee ENISA
    Panoramiche tecniche e di adozione (famiglie, mitigazioni). Ottime per impostare policy interne e materiali di formazione.

Esempio pratico: generare chiavi e fare un KEM “quantum-safe” con liboqs-python

Per sperimentare rapidamente, la community Open Quantum Safe fornisce liboqs (C) e liboqs-python (“oqs” su PyPI). Con poche righe puoi provare ML-KEM (Kyber) per uno scambio di chiavi e ML-DSA (Dilithium) per la firma. (Perfetto per ambienti di sviluppo e PoC; in produzione segui gli FIPS e le linee del tuo ente di certificazione/HSM.)

Requisiti: Python 3.10+, pip install oqs (bindings liboqs)

KEM con ML-KEM (Kyber): incapsulamento/decapsulamento

# Demo educativa: KEM "quantum-safe" con ML-KEM (Kyber)

# Libreria: liboqs-python (package: oqs)

import oqs

# Lato server: genera keypair ML-KEM

kem_name = "ML-KEM-768"  # profilo intermedio FIPS 203

with oqs.KeyEncapsulation(kem_name) as server_kem:

    public_key = server_kem.generate_keypair()

    # Espone public_key al client via canale pubblico (es. handshake TLS ibrido)

    # Lato client: incapsula una shared secret verso la public_key del server

    with oqs.KeyEncapsulation(kem_name) as client_kem:

        ciphertext, shared_secret_client = client_kem.encap_secret(public_key)

    # Lato server: decapsula per ottenere la stessa shared secret

    shared_secret_server = server_kem.decap_secret(ciphertext)

assert shared_secret_client == shared_secret_server

print(f"Shared secret ({len(shared_secret_client)} bytes) stabilita in modo quantum-safe.")

Firma con ML-DSA (Dilithium): sign/verify

import oqs, hashlib

sig_name = "ML-DSA-65"  # profilo tipico FIPS 204 (equiv. Dilithium3)

message = b"Messaggio critico da firmare"

with oqs.Signature(sig_name) as signer:

    public_key = signer.generate_keypair()

    signature = signer.sign(message)

with oqs.Signature(sig_name) as verifier:

    ok = verifier.verify(message, signature, public_key)

print("Firma valida:", ok)

Questi snippet mostrano l’uso base di KEM e Signature “quantum-safe”, utili per prototipi TLS applicativo, scambio segreto per cifratura simmetrica (es. AES-256-GCM) e sostituzione graduale delle firme RSA/ECDSA in pipeline di code signing. Per esempi in C e integrazione OpenSSL 3 con provider OQS (inclusi TLS demo e X.509), vedi gli examples ufficiali.

Come portare TLS nell’era post-quantum: ibrido e rollout controllato

Un percorso realistico:

  • Mappa i terminatori TLS (ingress, API gateway, LB, proxy) e aggiorna lo stack a una versione che consenta ciphersuite e KEM moderni, preferibilmente con supporto a ibridi (es. X25519+ML-KEM).
  • Pilota su domini interni a basso rischio, poi su servizi interni critici (mTLS) e infine sui front-end pubblici, verificando latenza, CPU, compatibilità client (browser, SDK, agent legacy).
  • Rotazione certificati
    Inizia con dual-cert (ECDSA + ML-DSA) o delegated credentials dove disponibili, per non interrompere i client non aggiornati.
  • Osservabilità
    Colleziona metriche handshake (fallimenti, fallback), negoziazione KEM, distribuzione versioni client.
  • Policy
    Imposta “preferenze algoritmiche” lato server, lasciando uno zoccolo di compatibilità temporaneo ma con scadenze precise.

PKI e code signing: ciò che impatta davvero i team di sicurezza

  • Gerarchie CA
    Ti serviranno nuove CA e profili X.509 con estensioni/OID per algoritmi post-quantum. Verifica che i tuoi HSM possano generare/gestire chiavi ML-DSA/SLH-DSA (o pre-provisioning software con migrazione successiva su HSM).
  • CRL/OCSP
    Dimensioni firme e chiavi crescono; stress-testa latenza e dimensione delle risposte, adegua TTL e caching.
  • Time-stamping e supply chain
    Firme post-quantum per build artifact, container, pacchetti (SBOM firmati), driver, firmware. CNSA 2.0 spinge a farlo ora, perché i device resteranno sul campo per anni.

Prestazioni, costi e “sorprese” ingegneristiche

  • Dimensioni
    Ciphertext e firme più grandi impattano MTU, storage, bandwidth su link lenti (OT, satcom). Pianifica frammentazione e retrasmissioni.
  • CPU/latency
    I KEM lattice-based sono veloci ma con profili diversi da ECDH; misura su hardware reale (x86/ARM, edge).
  • Compatibilità
    Client legacy non capiscono gli OID post-quantum — usa rollout ibrido e fallback pianificato.
  • Toolchain
    Assicurati che librerie, compilatori, FIPS modules e acceleratori (SmartNIC, HSM) siano supportati/validati.

Casi d’uso: come iniziare in 90 giorni

Giorni 0–30

  • Nomina un Crypto Program Owner (CISO-sponsored).
  • Avvia discovery (sorgenti, binari, rete) e compila l’inventario crittografico.
  • Seleziona gli use case pilota: 1) code signing per un microservizio core; 2) mTLS tra due servizi interni con KEM ibrido; 3) firmware signing per un componente IoT/OT.

Giorni 31–60

  • Implementa dual-sign nel pipeline CI/CD (ECDSA + ML-DSA).
  • Esegui PoC mTLS con ML-KEM (lato server preferenze ibride).
  • Disegna la PKI “quantum-ready” (nuove CA, profili, CRL/OCSP).

Giorni 61–90

  • Estendi il pilot a un sottoinsieme prod a basso impatto.
  • Misura latenza/CPU, errori di handshake, compatibilità client.
  • Scrivi policy di crypto-agility e una roadmap per 12–24 mesi.

(Per realtà enterprise che non vogliono costruire tutto “in casa”, esistono tool e servizi IBM Quantum Safe per discovery e remediation end-to-end.)

Agire ora con crypto-agility, governare il cambiamento

Il passaggio a un mondo quantum-safe non è un aggiornamento “di routine”. Richiede governance, strumenti, nuova PKI, protocolli ibridi, inventario accurato e formazione. La buona notizia è che gli standard ci sono: FIPS 203/204/205 e gli indirizzi CNSA 2.0 danno un quadro tecnico; l’Europa si è dotata di una roadmap coordinata. Le aziende che iniziano oggi partendo da code signing, TLS ibrido e crypto-agility si mettono al riparo dal rischio “harvest now, decrypt later” e, soprattutto, costruiscono un’infrastruttura resiliente a minacce che diventeranno concrete nell’arco di vita dei loro dati e dispositivi.

In questo scenario, la parola d’ordine è preparazione: senza inventario delle chiavi, senza PKI aggiornata e senza capacità di cambiare algoritmo con rapidità, nessuna strategia potrà reggere all’urto dell’innovazione quantistica.

Domande frequenti

  1. Che differenza c’è tra “crittografia post-quantum” e “quantum-safe”?
    Sono spesso usati come sinonimi. Post-quantum indica algoritmi progettati per resistere ad attacchi di computer quantistici; quantum-safe enfatizza l’obiettivo di sicurezza complessiva (algoritmi + processi + migrazione).
  2. Devo abbandonare subito RSA ed ECC?
    No, ma devi pianificare. Inizia con ibridi (X25519+ML-KEM e ECDSA+ML-DSA) e con code/firmware signing. Imposta crypto-agility e scadenze chiare.
  3. Gli algoritmi simmetrici sono al sicuro?
    Sono meno esposti: aumenta le chiavi (es. AES-256) e usa SHA-256/384/512. Gli attacchi quantistici riducono la complessità “solo” di una radice quadrata.
  4. Quali standard seguire?
    Riferimento primario: FIPS 203/204/205 del NIST e successivi profili; CNSA 2.0 per tempistiche USA; roadmap UE e ENISA per indirizzi europei.
  5. Quali algoritmi scegliere oggi?
    Per il KEM: ML-KEM/Kyber; per firme: ML-DSA/Dilithium; in scenari conservativi o con particolari vincoli, SLH-DSA/SPHINCS+; tieni d’occhio HQC. La scelta definitiva dipende da prestazioni e vincoli del tuo ambiente. 
  6. Come si gestiscono le performance?
    Misura su hardware reale; ottimizza parametri, considera acceleratori e planning di MTU/frammentazione. Gli overhead sono spesso accettabili per servizi IT; in OT, usa gateway ed edge offload.
  7. Cosa significa “harvest now, decrypt later”?
    Gli attaccanti registrano oggi il traffico cifrato per decifrarlo in futuro quando avranno capacità quantistiche. Proteggi subito dati con lungo valore.
  8. Che impatto ha sulle infrastrutture critiche?
    Alto: device OT a lungo ciclo di vita, canali a bassa banda, supply chain estese. Priorità a firmware signing, gateway e migrazione ibrida. Le autorità (es. NCSC UK) indicano obiettivo 2035 per completare la transizione.
  9. Esistono librerie open-source per testare la migrazione?
    Sì: il progetto Open Quantum Safe (liboqs, oqs Python) e integrazioni con OpenSSL per demo TLS/X.509. Ottime per PoC e sperimentazioni.
  10. Qual è il ruolo di IBM?
    IBM fornisce una roadmap tecnologica per i computer quantistici e una suite IBM Quantum Safe (Explorer, Guardium QS, Remediator) per guidare discovery, analisi e remediation della crittografia aziendale.

(Appendice) Snippet operativi extra

Verifica rapida di compatibilità OpenSSL (provider OQS in laboratorio)

Nota: per ambienti di test, OQS mantiene un provider per OpenSSL 3 con algoritmi post-quantum di riferimento. Per i passaggi, consultare la documentazione ufficiale e gli examples.

# Ambiente di laboratorio, non per prod:

# 1) Compila/installa OQS-OpenSSL provider seguendo la doc ufficiale

# 2) Elenca algoritmi firma/KEM disponibili dal provider

openssl list -signature-algorithms -provider oqsprovider -provider default

openssl list -keyexchange-algorithms -provider oqsprovider -provider default

# 3) Genera una keypair ML-DSA e una CSR di test

openssl genpkey -algorithm ML-DSA-65 -provider oqsprovider -out server-ml-dsa.key

openssl req -new -key server-ml-dsa.key -out server-ml-dsa.csr -subj "/CN=example.com"

# 4) (Per demo) firma self-signed con ML-DSA

openssl req -x509 -key server-ml-dsa.key -in server-ml-dsa.csr \

  -provider oqsprovider -days 30 -out server-ml-dsa.crt

Schema di policy per crypto-agility (pseudocodice)

crypto_policy:

  version: 1

  default_kem: ML-KEM-768        # preferenza KEM post-quantum (FIPS 203)

  fallback_kex: X25519           # per ibrido e compatibilità

  default_sig: ML-DSA-65         # firma post-quantum (FIPS 204)

  dual_sign: true                # abilita firme ibride in rollout

  symmetric:

    cipher: AES-256-GCM          # robusto anche contro Grover

    hash: SHA-384

  rotation:

    cert_ttl_days: 180

    key_ttl_days: 90

  telemetry:

    tls_handshake_metrics: true

    kem_negotiation_breakdown: true

  enforcement:

    deadline_hybrid_all: "2026-12-31"

    deadline_pq_only_critical: "2028-12-31"
2
To top