Perché le firme post-quantistiche superano i limiti dell’handshake TLS

Quando si affronta la transizione verso la crittografia post-quantistica, alcuni aspetti sono più semplici di altri. Portare lo scambio delle chiavi a un approccio resistente ai quanti ha richiesto del lavoro, ma siamo arrivati a una soluzione (un approccio ibrido, che combina curve ellittiche con ML-KEM) senza grandi difficoltà. Quando invece si parla di certificati e autenticazione, il lavoro richiesto è molto maggiore, e tutto dipende dalle differenze tra le dimensioni delle firme negli algoritmi che usiamo oggi (tradizionali) rispetto a quelli che vogliamo usare domani (post-quantistici).

Quando progettiamo qualcosa, ad esempio un protocollo crittografico, prendiamo in considerazione diversi fattori, valutiamo le possibilità e i loro vantaggi e svantaggi, quindi prendiamo decisioni che ci consentano di rispettare i vincoli imposti. La sicurezza di solito non è negoziabile (anche se spesso è su uno spettro), ma le prestazioni sono un fattore importante. Storicamente, ci piace la sicurezza, ma amiamo la crittografia veloce.

Alcune cose ti conquistano e così è stato con la crittografia ellittica. Sembrava lo strumento perfetto: sicuro e performante, con operazioni rapide e firme di dimensioni ridotte. Nel tempo, sempre più protocolli sono passati a questa famiglia di algoritmi crittografici, fino a diventare onnipresenti. Le esigenze si risolvevano facilmente aggiungendo un'altra firma, finché tutto si è fermato bruscamente a causa dei computer quantistici. (Se hai bisogno di un ripasso, la nostra Guida alla Crittografia Post-Quantistica è una lettura leggera e utile.)

La transizione post-quantistica della crittografia, imposta dalla minaccia di un computer quantistico rilevante dal punto di vista crittografico (CRQC), è un ottimo promemoria del fatto che nel mondo digitale non esiste una sicurezza intrinseca. È tutto un gioco di equilibri. Giochiamo con la matematica e troviamo proprietà interessanti, che poi combiniamo in modi utili. Quella che chiamiamo sicurezza è effimera perché lo stato dell’arte avanza costantemente. Forse avrai già sentito dire che gli attacchi migliorano solo.

I nostri computer classici non riescono a rompere la matematica di RSA ed ECDSA, ma, come si è scoperto, i computer quantistici sì. Per difenderci, giochiamo ad altri giochi con una matematica diversa. Concepiamo nuovi algoritmi. L’unico problema è che le proprietà di questi nuovi algoritmi sono diverse. In questo caso particolare, le prestazioni restano comparabili, ma le chiavi e le firme richiedono molto più spazio.

Nella tabella seguente, confrontiamo gli aspetti fondamentali di ML-DSA con quelli della crittografia tradizionale. Mostriamo i valori per gli algoritmi comuni e i livelli di sicurezza che normalmente vediamo nei certificati di leaf e negli intermedi, dove si utilizza una crittografia più forte. Ci concentriamo solo su ML-DSA perché al momento è la nostra principale scommessa. Se vuoi capire come sono gli altri algoritmi, visita il PQC Signature Zoo.

Come si può vedere, la variante entry level di ML-DSA utilizza firme che sono 10 volte più grandi di RSA e 34 volte più grandi di ECDSA. Questo aumento delle dimensioni della crittografia pubblica cambia in modo radicale le assunzioni fatte nei livelli successivi della crittografia, al punto che certi meccanismi potrebbero addirittura smettere di funzionare correttamente.

Una nota: se noti leggere discrepanze tra le dimensioni dichiarate di firme e chiavi pubbliche in diversi articoli su Internet, è probabilmente perché alcuni riportano le dimensioni dei primitivi grezzi e altri tengono conto di come i dati vengono confezionati per il trasporto in rete, come faccio qui.

Alla base, un certificato X.509 è un contenitore e mezzo di trasporto per una chiave pubblica, firmata con la chiave di un’autorità. Quando sono apparsi inizialmente i certificati, le chiavi disponibili erano solo quelle RSA. Ai soliti 2.048 bit, una chiave RSA occupa 272 byte e la sua firma 256. ECDSA, invece, richiede 65 byte per la chiave pubblica (senza compressione) e 72 per la firma. Con la metainformazione addizionale necessaria in ogni certificato, la dimensione tipica di un certificato di leaf può essere circa 1-2 KB.

Un solo certificato non basta per accedere in modo sicuro a un server. In pratica, ci si affida alle catene di certificati, che prevedono almeno 2 certificati trasportati sulla rete. (Una catena completa può essere di 3 certificati, considerando anche la root, ma quest’ultimo certificato non dovrebbe essere trasmesso.)

Questo ulteriore intermediario raddoppia i requisiti di dimensione. Gli intermediari e i root tendono ad usare una crittografia ancora più forte e quindi sono più pesanti.

Inoltre, i protocolli necessitano almeno di una firma per autenticare l’handshake crittografico in tempo reale. A questo punto, in un handshake TLS, parliamo di almeno 3 firme e 2 chiavi pubbliche.

Nei primi tempi di SSL, le CPU erano lente e la crittografia troppo impegnativa. Le operazioni crittografiche erano il collo di bottiglia principale. (Avevamo anche pagine web molto più piccole di oggi.) Oggi il collo di bottiglia è qualcosa che forse non conosci: la congestion window iniziale di TCP.

Senza andare troppo nei dettagli, la finestra di congestione iniziale è la quantità massima di dati che puoi inviare all’inizio di una connessione TCP senza dover attendere un round trip di rete aggiuntivo. La finestra era molto più piccola in passato, ma il limite moderno è di circa 14,5 KB. QUIC, il sostituto moderno di TCP (implementato sopra UDP), ha un limite di circa 4.500 byte, ma per un motivo diverso (la difesa anti-amplificazione, per mitigare gli attacchi DoS di amplificazione, semplici su UDP).

In pratica, se il server non riesce a far stare tutti i suoi certificati e la crittografia protocollo aggiuntiva in quei 14,5 KB, dovrà aspettare il via libera dal client proprio nel momento più delicato della conversazione, cioè all’inizio. Su una rete veloce, questa penalizzazione può pesare decine di millisecondi. Sulle reti mobili, possono essere centinaia.

Se il tuo protocollo usa UDP (come QUIC), pacchetti grandi possono richiedere frammentazione, che spesso viene bloccata dai middlebox. Su reti con significative perdite di pacchetti, le prestazioni calano ulteriormente.

I certificati X.509 classici, descritti prima, non sono quelli che usiamo comunemente oggi. Nelle reti private forse sì, ma nel Web PKI richiediamo una versione estesa di X.509 arricchita con informazioni di Certificate Transparency (CT). L’ecosistema CT offre garanzie di sicurezza estese registrando tutti i certificati pubblici in registri pubblici. La pubblicazione viene certificata, oggi, da almeno 2 operatori. Ogni operatore aggiunge una firma, incorporata nei certificati X.509 tramite l’estensione Signed Certificate Timestamp (SCT).

Con CT aggiunto, in un tipico handshake TLS arriviamo a 5 firme e 2 chiavi pubbliche.

Senza entrare nel dettaglio dei calcoli (che forse meriterebbero un post a sé), ecco i numeri approssimativi a cui sono arrivato per le catene tipiche in uso oggi:

• Catena certificati ECDSA: 586 byte
• Catena certificati RSA: 1.712 byte
• Catena certificati ML-DSA: 14.724, 18.640 o 18.565 byte

I numeri di ML-DSA richiedono una spiegazione. Otteniamo la dimensione minore (14.724) solo se usiamo ML-DSA-44 per tutta la catena, ma ciò va contro le best practice. Il secondo valore (18.640) lo otteniamo se gli intermediari e i root utilizzano crittografia più forte, in quanto le relative chiavi devono restare sicure più a lungo. Il terzo valore vale per l’utilizzo con CNSA 2.0 (il pacchetto Commercial National Security Algorithm della NSA), che accetta solo ML-DSA-87.

È evidente come, anche nel caso migliore, con una catena ML-DSA la crittografia pubblica da sola supera la finestra di congestione iniziale di 14 KB, e nessuno può esserne contento. Questo aumento potrebbe avere un impatto piccolo ma significativo nell’uso quotidiano. I dispositivi vincolati (come IoT) potrebbero avere difficoltà a implementare la crittografia post-quantistica.

Il calcolo si concentra sugli aspetti basilari, ma ci sono molte situazioni in cui l’handshake TLS può diventare ancora più grande. Ad esempio:

• A volte bisogna aggiungere un altro intermediario alla catena di certificati, per esempio quando si passa da una gerarchia a un’altra e si vuole garantire la compatibilità con archivi root più vecchi.
• La situazione peggiora leggermente se si decide di utilizzare l’autenticazione ibrida, mescolando crittografia tradizionale e post-quantistica nello stesso certificato. Si può volerlo fare quando non ci si fida appieno dei nuovi algoritmi post-quantistici e si preferisce un approccio "cintura e bretelle".
• Peggiora ancora un po’ se vuoi supportare il controllo delle revoche tramite OCSP, anche se questa funzione è ormai raramente usata su Internet pubblica.

Abbiamo visto che una transizione ingenua agli algoritmi post-quantistici significa dover pianificare un impatto potenzialmente significativo sulle prestazioni. Nel mio prossimo post, esaminerò le evidenze che potrebbero aiutarci a confermare queste paure.