Sicurezza post-quantistica: ciò che viene intercettato oggi, qualcuno lo leggerà domani

Le solite notizie sui computer quantistici sono o allarmismo o rassicurazione. Nessuna delle due aiuta. Considerando la situazione con lucidità, è gestibile: una parte della crittografia attualmente in uso ha una data di scadenza, un’altra no, e la differenza si può spiegare in una frase. Tuttavia, le cose diventano pratiche — ed è lì che risiedono i problemi reali.

Il problema si chiama «Raccogli ora, decifra dopo»

Chi intercetta traffico dati cifrato oggi può archiviarlo. Non per leggerlo subito, ma per leggerlo quando gli strumenti per farlo esisteranno. Un computer quantistico sufficientemente grande rompe con l’algoritmo di Shor esattamente quei protocolli che oggi garantiscono lo scambio di chiavi: RSA, Diffie-Hellman e le curve ellittiche.

L’attacco avviene quindi nel futuro, ma la raccolta dei dati avviene ora. Per la valutazione del rischio, questo significa: non conta la data del primo computer quantistico, ma la domanda di quanto tempo i dati che transitano oggi sulla linea rimarranno degni di protezione. Un contratto di assicurazione sanitaria, un disegno tecnico o un mandato legale non saranno meno riservati tra dieci anni di quanto lo siano oggi.

La formulazione classica per questo è l’uguaglianza di Mosca: se il tempo per cui i vostri dati devono rimanere segreti, più il tempo che richiede la vostra transizione, è maggiore del tempo fino al primo computer quantistico capace — allora siete in ritardo. Non è necessario conoscere la data del computer quantistico per questo. Basta sapere che la propria transizione richiede anni.

Cosa è interessato — e cosa no

Qui vale la pena essere precisi, perché fa risparmiare lavoro.

Da queste tre righe deriva l’intera priorità: Lo scambio di chiavi è il cantiere, tutto il resto ha tempo.

La soluzione c’è — ed è ibrida

Gli algoritmi sono stati standardizzati da agosto 2024. Il NIST ha pubblicato FIPS 203 ML-KEM, un protocollo di scambio di chiavi basato su reticoli, che allo stato attuale resiste anche ai computer quantistici.

La cosa decisiva è come si impiega: ibrida. Il protocollo classico resta, il nuovo viene aggiunto sopra, e la chiave di sessione nasce da entrambi. Se uno dei due protocolli cede, l’altro continua a proteggere. Questo non è esitazione, ma prudenza motivata — i nuovi protocolli sono notevolmente più giovani e sono stati attaccati pubblicamente per un periodo molto più breve rispetto a RSA o X25519. Il BSI tedesco raccomanda per esattamente questo motivo l’uso esclusivamente ibrido. Con la conversione non ci si assume quindi un nuovo rischio, ma si aggiunge un secondo strato di protezione.

Nella pratica i protocolli si chiamano così — entrambi sono disponibili, entrambi sono collaudati:

Dove fallisce nella pratica

Se algoritmi e standard sono pronti — perché la conversione è comunque lavoro? Per cinque motivi, che non hanno nulla a che fare con la crittografia.

1. Nessuno sa dove ci sia crittografia. Il problema non è il web server, ma il backup che replica da qualche parte di notte, l’agente di monitoraggio, la connessione al database tra due data center, il dispositivo in produzione con l’interfaccia web del 2014. La parte più difficile di una migrazione PQ è un inventario completo — non la scelta dell’algoritmo.
2. La versione del software decide, non la volontà. ML-KEM esiste in OpenSSH solo dalla versione 9.9. Ubuntu 24.04 fornisce 9.6, Debian 13 invece OpenSSH 10. Chi scrive il nuovo algoritmo fisso nella configurazione fa cadere ogni server che non lo conosce: il servizio rifiuta l’avvio a causa di un nome sconosciuto nella configurazione. Per un server SSH, nel caso peggiore, è la perdita dell’accesso.
3. I sistemi vecchi non ce la faranno mai. In quasi ogni ambiente cresciuto organicamente c’è un sistema il cui software non riceverà mai una versione compatibile con PQ — perché l’applicazione su di esso non è migrabile, perché il produttore non esiste più o perché un processo di certificazione dipende da esso. Questi sistemi non spariscono scrivendo una policy. Hanno bisogno di una classificazione: cosa ci gira sopra, per quanto tempo ancora, e quale strato di protezione si trova davanti nel frattempo?
4. Imporre rompe cose che nessuno ha in mente. Chi disattiva i protocolli classici non blocca solo gli attaccanti, ma anche ogni client troppo vecchio — l’agente di backup, il runner CI, il monitoraggio. Queste connessioni raramente si notano subito. Si notano quando serve il backup.
5. La trappola più ingannevole: PQ è configurato, ma non viene mai usato. Client e server concordano la prima voce comune nella loro lista di algoritmi. Se il protocollo PQ è in terza posizione e un classico è prima, viene usato quello classico — ogni volta. La configurazione sembra corretta, un rapporto di verifica segnala «presente», e in realtà la voce è peso morto. Non conta la presenza, ma l’ordine.

Come lo risolviamo

La nostra infrastruttura funziona tramite baseline di hardening automatizzate: uno script imposta lo standard di sicurezza di un server, un secondo lo misura indipendentemente. Il principio guida dietro è più vecchio del tema quantistico:

Hardening senza verifica è speranza.

Abbiamo sperimentato una volta che un file di configurazione dall’aspetto esemplare non aveva alcun effetto, perché un altro file lo sovrascriveva. Da allora non verifichiamo mai se un’impostazione si trovi da qualche parte, ma sempre cosa fa effettivamente il servizio.

Su questa base, la nostra conversione è così:

La lista degli algoritmi viene costruita a runtime

Lo script chiede al server quali protocolli la sua versione SSH conosce, e prende la migliore combinazione disponibile — ML-KEM, se presente, altrimenti il protocollo ibrido più vecchio. Un server con Debian 13 riceve automaticamente ML-KEM, uno con Ubuntu 24.04 continua a funzionare invariato, e al prossimo upgrade della distribuzione la configurazione si aggiorna da sola. Uno script per tutti i sistemi, senza verifiche di versione che qualcuno dovrebbe mantenere. Se il servizio rifiuta comunque la nuova configurazione, viene automaticamente ripristinata — per una configurazione SSH, questa è la differenza tra un avviso e un’interruzione del server.

Si verifica l’ordine, non la presenza

L’esecuzione di verifica segnala un errore se un protocollo classico si trova prima del protocollo PQ — esattamente la trappola del punto 5.

Si verifica contro ciò che accade realmente

L’esecuzione di verifica stabilisce una connessione reale al servizio, che consente esclusivamente il protocollo PQ, e valuta su cosa le due parti sono d’accordo. Non «nessun messaggio di errore» — questo sarebbe inutile, perché anche un servizio in crash non segnala errori. Ma la conferma registrata che lo scambio è effettivamente avvenuto in modo post-quantistico.

Il taglio netto è un interruttore, non uno standard

Disattivare completamente i protocolli classici è possibile, ma è una decisione consapevole per sistema e non l’impostazione predefinita. L’ordine corretto è: prima ovunque ibrido, poi misurare, poi rilevare i vecchi client rimanenti — e solo dopo disattivare.

La leva più grande non è SSH

Il traffico SSH da noi corre esclusivamente in reti interne e tramite VPN. Chi vuole intercettarlo è già nella rete. Il traffico che può realmente essere raccolto su larga scala è il traffico HTTPS pubblico al bordo della rete. Lì la capacità PQ dipende dalla versione della libreria TLS — negli attuali image container comuni, il confine cade esattamente lì: una versione ce la fa, quella precedente no. La strada per arrivarci passa quindi attraverso un aggiornamento dell’image e una riga di configurazione, non attraverso un progetto.

Alcune cose sono già sicure, senza che te ne accorgi

Il nostro VPN di amministrazione utilizza WireGuard con scambio di chiavi classico — ma con una chiave pre-condivisa individuale per dispositivo. Questa chiave non passa mai sulla linea, e rende il tunnel resistente ai quantistici. Un dettaglio dal processo di configurazione, impostato originariamente per un altro motivo e oggi casualmente esattamente giusto. Si trovano punti del genere solo se si passa in rassegna sistematicamente l’inventario — il che ci riporta al punto 1.

Cosa raccomandiamo

Post-Quantum non è un progetto che si avvia e si conclude, ma una proprietà che si integra nello standard con cui i sistemi vengono impostati e verificati. Chi inizia oggi dovrebbe procedere in questo ordine:

1. Fare l’inventario. Quali connessioni trasportano dati che tra dieci anni saranno ancora degni di protezione? Questa è l’unica domanda che determina la priorità.
2. Bordi esterni prima. Tutto ciò che passa attraverso Internet aperto, soprattutto l’interno.
3. Convertire in ibrido, non sostituire. La protezione di oggi resta intatta.
4. Misurare l’effetto, non leggere la configurazione. L’ordine degli algoritmi decide se la conversione ha effettivamente un effetto.
5. Indicare i sistemi legacy. Ciò che non sarà mai compatibile con PQ appartiene a una lista con data di scadenza — e nel frattempo dietro strati di protezione aggiuntivi.
6. Imporre solo alla fine. E poi con una via di ritorno.

Lo sforzo per i primi quattro punti è gestibile se l’ambiente è gestito in modo automatizzato. Da noi sono state integrazioni a script esistenti, non nuova infrastruttura.

Consigliamo e accompagniamo le aziende in esattamente questa inventariazione e conversione — dall’inventario all’hardening dei sistemi fino alla verifica continua e automatizzata. Contattateci se desiderate sapere come stanno le vostre connessioni.