Quando parlo di sicurezza con chi gestisce i sistemi di un’organizzazione, c’è una domanda che torna spesso senza una risposta precisa: quante chiavi, quanti certificati e quali algoritmi sono in uso, e dove si trovano? Raramente è una questione di competenze. Più spesso nessuno ha mai avuto il mandato, o un motivo concreto, per contarli. I sistemi sono cresciuti nel tempo, un progetto dopo l’altro, e ognuno ha portato con sé le proprie scelte crittografiche.
Prima di discutere quali algoritmi post-quantistici adottare, quindi, c’è un lavoro meno spettacolare da fare: capire dove vengono usati quelli attuali. Senza questa informazione, qualsiasi piano di migrazione parte da una visione incompleta.
Il problema non è il computer quantistico
Il tema viene quasi sempre raccontato come una questione di data: quando esisterà un computer quantistico in grado di rompere gli algoritmi a chiave pubblica che usiamo oggi, come RSA e quelli basati su curve ellittiche? Nessuno lo sa con certezza, e una domanda posta così porta di solito all’allarme o al rinvio.
Le linee guida dell’Agenzia per la Cybersicurezza Nazionale indicano un criterio più utile: pianificare in base a quanto a lungo devono restare protetti i dati di oggi, non in base alla data in cui comparirà la macchina. Il traffico cifrato può essere intercettato e archiviato adesso, per essere decifrato quando sarà possibile: è la strategia nota come harvest now, decrypt later. Nel mio lavoro in ambito sanitario il criterio pesa più che altrove: un referto trasmesso oggi in pochi millisecondi può dover restare riservato per decenni.
Il rischio riguarda soprattutto la crittografia a chiave pubblica, usata per scambiare le chiavi e per firmare. Gli algoritmi simmetrici come AES, con chiavi di lunghezza adeguata, restano validi.
Il quadro di riferimento è ormai definito. Nell’agosto 2024 il NIST ha pubblicato i primi tre standard post-quantistici: FIPS 203 (ML-KEM) per lo stabilimento delle chiavi, FIPS 204 (ML-DSA) e FIPS 205 (SLH-DSA) per la firma digitale. A fine ottobre 2026 ha pubblicato la versione definitiva dell’IR 8547, che descrive il percorso di transizione dagli algoritmi a chiave pubblica vulnerabili. Le tappe principali sono il 2030 e il 2035, con scadenze diverse a seconda dell’impiego e del livello di sicurezza. In Europa, la roadmap coordinata pubblicata nel 2025 chiede di avviare i piani nazionali entro la fine del 2026, di migrare i casi ad alto rischio e le infrastrutture critiche entro il 2030 e di completare la transizione, per il maggior numero possibile di sistemi, entro il 2035.
Per sistemi che restano in esercizio per anni sono tempi stretti. E non si può pianificare ciò che non si è censito.
La crittografia nascosta nel software e nei processi
Quando un’organizzazione avvia la ricognizione delle proprie dipendenze crittografiche, di solito parte dai certificati TLS. È la scelta più naturale: sono il punto più visibile, ed esistono strumenti maturi per censirli. Raccolti i dati dall’infrastruttura, però, ci si accorge che una parte importante delle dipendenze non è lì. Sta nel codice applicativo, nelle librerie incluse in un gestionale, nei connettori verso sistemi esterni, nei dispositivi che dialogano con il software centrale.
E a volte sta nei processi che ruotano attorno alla tecnologia. Capita che chiavi e credenziali, ben protette all’origine, attraversino poi qualche passaggio manuale prima di arrivare all’applicazione che le usa: un invio via email, una cartella condivisa, una copia su un server di appoggio. Sono soluzioni nate per rispondere a un’esigenza reale, spesso con tempi stretti, che col tempo entrano nel funzionamento quotidiano. Nessuno le considera crittografia, eppure sono proprio i punti da ritrovare e rivedere uno per uno quando cambieranno algoritmi, chiavi o formati.
A quel punto la domanda cambia.
Oltre a sapere quali algoritmi sono in uso, bisogna capire chi può modificarli, quali componenti ne dipendono e che cosa smetterebbe di funzionare dopo una sostituzione.
È una forma di debito tecnico che raramente compare nei backlog: il debito crittografico. Le librerie continuano a funzionare, i certificati vengono rinnovati, le connessioni restano attive. Quello che spesso nessuno ha avuto occasione di verificare è quanto sarebbe complesso sostituire le funzioni crittografiche su cui tutto questo si regge.
Serve anche un po’ di ordine nei termini. Un certificato contiene una chiave pubblica, RSA o a curva ellittica, e la firma dell’autorità che lo ha emesso, che può usare un algoritmo diverso. Una connessione TLS usa poi meccanismi distinti per lo scambio delle chiavi, che protegge la riservatezza ed è il primo esposto all’harvest now, decrypt later, e per l’autenticazione, che protegge l’autenticità e riguarda già oggi chiavi e dispositivi destinati a restare in uso a lungo. Un inventario che mescola questi livelli non aiuta a pianificare una migrazione.
Il costo di una dipendenza sconosciuta
Quando l’urgenza diventa reale, chi non ha un inventario deve fare tre cose insieme: scoprire dove sono le dipendenze, capire quali sono critiche e migrare. Con i tempi di chi è già in ritardo.
Le conseguenze di una migrazione fatta in emergenza sono prima di tutto tecniche. Le priorità vengono decise a istinto invece che in base al rischio. Componenti legacy che non supportano i nuovi algoritmi emergono a lavoro già avviato. Alcune librerie non si possono aggiornare senza modificare le interfacce che espongono. Compatibilità date per scontate si rivelano mai messe alla prova. E sistemi nati in momenti diversi devono continuare a dialogare mentre gli algoritmi cambiano.
C’è anche un aspetto che si tende a sottovalutare: chiavi e firme post-quantistiche sono molto più grandi di quelle attuali. Una firma ECDSA occupa qualche decina di byte, una firma ML-DSA qualche kilobyte. Campi a dimensione fissa, protocolli con limiti stretti e dispositivi con poca memoria possono non reggere il cambio, e conviene saperlo prima.
Poi c’è l’effetto organizzativo: senza inventario diventa difficile anche dimostrare la conformità. Si può avere un piano ragionevole e nessuna evidenza da mostrare.
Progettare software che possa cambiare
Il primo passo, secondo me, è costruire un inventario crittografico. Più che un elenco di algoritmi, serve una mappa che per ogni funzione crittografica dica:
- a cosa serve: cifratura, scambio delle chiavi, firma, autenticazione;
- quale algoritmo usa e con quali parametri;
- quali certificati e quali chiavi coinvolge;
- in quali librerie e componenti è implementata, e in quale versione;
- quali sistemi e servizi ne dipendono;
- chi ne è il responsabile tecnico e quale fornitore la gestisce, se c’è;
- qual è il suo ciclo di vita e quanto è davvero sostituibile.
Non deve essere perfetto dal primo giorno. Deve esistere, restare aggiornato e permettere di ordinare i sistemi per criticità e per vita utile dei dati. Esistono anche formati standard per descriverlo, come il Cryptography Bill of Materials (CBOM) di CycloneDX, utili quando le informazioni devono passare tra più fornitori.
Come ci si muove nella pratica dipende dal contesto. Su molti progetti lavoriamo direttamente sul codice e interveniamo sulle librerie crittografiche: le integriamo, le aggiorniamo, le sostituiamo quando serve. In ecosistemi come quello sanitario, invece, sullo stesso sistema informativo lavorano spesso molti fornitori, ciascuno con i propri prodotti. Lì il nostro contributo è soprattutto architetturale: più che intervenire sulla singola libreria, aiutiamo l’organizzazione a definire i perimetri, mappare servizi e integrazioni e costruire un’architettura in cui le dipendenze siano chiare e governabili.
In sanità, e più in generale nella pubblica amministrazione, la difficoltà maggiore spesso non è tecnologica. Molti soggetti coinvolti, progetti che durano anni e il naturale ricambio delle persone fanno sì che le informazioni si distribuiscano tra documenti, sistemi e competenze diverse. È il modo in cui evolvono i progetti lunghi e complessi. A questo si aggiungono vincoli propri del settore: dispositivi che restano in servizio per molti anni, integrazioni con altri enti che non si possono cambiare da un giorno all’altro, documenti firmati che devono restare verificabili nel tempo. Per questo un inventario condiviso vale più della memoria di chiunque.
Non tutte le dipendenze hanno la stessa urgenza. La firma di un documento che deve restare valido per decenni pone un problema diverso dall’autenticazione di un servizio interno che viene rinnovato ogni anno. L’inventario serve proprio a questo: decidere da dove iniziare, quali dipendenze affrontare per prime e quali sistemi richiedono una riprogettazione.
Il secondo passo riguarda il modo in cui il software viene progettato. Poter sostituire un algoritmo dipende dall’architettura: se le scelte crittografiche sono sparse tra librerie, configurazioni e codice applicativo, cambiarle richiede interventi su molti componenti e una nuova verifica di come interagiscono.
La crypto-agility si costruisce prima che serva.
Vuol dire isolare le funzioni crittografiche dietro interfacce ben definite, evitare algoritmi scritti direttamente nel codice, automatizzare la gestione di chiavi e certificati eliminando i passaggi manuali, e prevedere nei nuovi sviluppi che più algoritmi possano convivere durante la transizione. È anche il modo più semplice per evitare che un’applicazione nuova nasca già con dipendenze difficili da sostituire.
In alcuni casi questa convivenza passa da schemi ibridi, che combinano un meccanismo classico e uno post-quantistico, così che la protezione regga finché almeno uno dei due resta sicuro. Non è uno scenario lontano: diversi browser usano già per impostazione predefinita uno scambio di chiavi ibrido che affianca una curva ellittica a ML-KEM. Affiancare due algoritmi, però, non basta: servono combinazioni standardizzate e verificate, una gestione adeguata delle chiavi e la compatibilità tra tutti i sistemi coinvolti. La roadmap europea raccomanda questo approccio dove appropriato.
Se domani mattina fosse necessario sostituire un algoritmo crittografico in uno dei vostri sistemi critici, per una nuova norma o per una vulnerabilità scoperta all’improvviso, sapreste da dove cominciare?
