Harvest now, decrypt later: perché i prodotti di lunga durata devono pianificare il post-quantum oggi

La domanda che sento più spesso sulla crittografia post-quantistica è: «Quando i computer quantistici romperanno davvero RSA?».

È una domanda ragionevole. È anche il punto di partenza sbagliato.

Per molte organizzazioni il rischio non comincia il giorno in cui esiste un computer quantistico abbastanza potente. Comincia il giorno in cui qualcuno registra dati che avranno ancora valore quando quel computer arriverà.

Cosa significa «harvest now, decrypt later»

L’idea è semplice. Un attaccante intercetta e conserva oggi traffico cifrato. Non può ancora leggerlo. Non gli serve. Archiviare costa poco, e può aspettare.

Quando sarà disponibile un computer quantistico crittograficamente rilevante, gli scambi di chiavi protetti dagli algoritmi a chiave pubblica di oggi, come RSA e la crittografia a curve ellittiche, potrebbero essere violati. L’algoritmo di Shor ha mostrato nel 1994 che in linea di principio è possibile. I dati registrati anni prima diventano leggibili.

Che succeda tra dieci anni o tra venti è incerto. Conta un confronto molto più semplice.

I tre numeri che decidono il rischio

C’è un modo noto di inquadrare la questione, spesso attribuito a Michele Mosca. Si confrontano tre durate:

• per quanto tempo i dati devono restare riservati (x);
• quanto ci vorrà per migrare i sistemi a una crittografia resistente ai quantistici (y);
• quanto manca a un computer quantistico capace di rompere la crittografia a chiave pubblica di oggi (z).

Se x + y è maggiore di z, hai un problema, e ce l’hai oggi.

La parte utile di questa formula è che non serve conoscere z con precisione. Basta essere onesti su x e y. E per la mia esperienza, y è il numero che si sottovaluta di più.

Perché i prodotti connessi sono diversi

Per un servizio web la migrazione è difficile ma circoscritta. Controlli i server, puoi installare nuove librerie, puoi ruotare i certificati.

I prodotti connessi sono diversi.

• Restano sul campo dieci, quindici, a volte vent’anni.
• La loro crittografia è spesso legata a hardware, bootloader ed elementi sicuri scelti anni prima.
• La loro catena di aggiornamento può coinvolgere più fornitori.
• Alcuni non si possono aggiornare affatto.

Così, per un dispositivo progettato oggi, x e y si sovrappongono a z quasi per definizione. Il prodotto che stai specificando ora sarà molto probabilmente ancora acceso quando la transizione sarà in pieno svolgimento.

Non è solo una questione di riservatezza

«Harvest now, decrypt later» riguarda la riservatezza. Per i prodotti connessi c’è un secondo rischio che trovo ancora più importante: l’autenticità.

Gli aggiornamenti firmware sono firmati. I dispositivi dimostrano la propria identità con certificati. Se gli schemi di firma alla base di questi meccanismi diventano violabili, un attaccante non ha bisogno di leggere i tuoi dati. Può fingersi te: firmare un firmware malevolo, o clonare un dispositivo fidato.

Questo rischio non inizia quando i dati vengono raccolti. Inizia quando l’attacco diventa praticabile. Ma la radice di fiducia che dovrà resistere si decide molto prima, quando si progettano l’hardware e la catena di avvio.

Le scadenze ci sono già

Non serve scommettere sull’hardware quantistico per avere delle scadenze.

• Il NIST ha pubblicato i primi standard post-quantistici, FIPS 203, 204 e 205, ad agosto 2024.
• Il NIST ha indicato il piano per deprecare gli algoritmi a chiave pubblica vulnerabili ai quantistici dopo il 2030 e vietarli dopo il 2035.
• La roadmap coordinata dell’Unione europea chiede di avviare la transizione entro la fine del 2026, proteggere i casi d’uso ad alto rischio entro il 2030 e migrare quanti più sistemi possibile entro il 2035.

Autorità di regolazione e grandi clienti seguiranno queste date, qualunque cosa succeda nei laboratori quantistici.

Cosa fare adesso

Non devi sostituire ogni algoritmo quest’anno. Devi smettere di ingrandire il problema.

1. Classifica i dati per durata. Cosa deve restare riservato per più di dieci anni? Quel traffico merita attenzione per primo.
2. Trova dove si usa la crittografia a chiave pubblica. Scambio di chiavi, firme, identità dei dispositivi, firma degli aggiornamenti. Non puoi pianificare una migrazione che non vedi.
3. Non lanciare prodotti nuovi che non possono cambiare. Assicurati che i nuovi progetti abbiano memoria, margine di prestazioni e percorso di aggiornamento per adottare nuovi algoritmi. Lo chiamo crypto-agility.
4. Stima y con onestà. Chiedi ai tuoi team quanto ci vorrebbe per cambiare lo schema di firma del prodotto più vecchio che supportate ancora. La risposta di solito è più lunga di quanto la roadmap preveda.

Il computer quantistico non è il punto di partenza. Il punto di partenza sono i dati, e i prodotti, che stai creando oggi.