Scambio di chiavi post-quantistico, dieci anni dopo

Questo articolo è il secondo di una serie dedicata alle decisioni tecniche legate alla crittografia post-quantistica. La serie è iniziata la settimana scorsa con l'articolo sulle dimensioni delle firme post-quantistiche. Non è necessario aver letto il primo articolo per apprezzare questo.

Questa settimana l'IETF ha pubblicato ufficialmente l'ultimo RFC necessario a standardizzare del tutto lo scambio di chiavi post-quantistico in TLS, quindi è il momento giusto per guardare più da vicino lo scambio di chiavi in questa nuova puntata.

Questo aspetto della migrazione è al tempo stesso più semplice e più complicato. In breve, la minaccia allo scambio di chiavi è immediata e c'è forte urgenza di affrontarla. La sfida tecnica è più semplice e il design si è definito con poche polemiche. Questa è la parte semplice. Sul versante più complicato, la NSA ha scelto una strada in contrasto con la comunità tecnica, creando all'IETF una frattura che continua. Continua a leggere per saperne di più.

I protocolli crittografici sono fatti di molte parti, ma in generale devono gestire tre aspetti chiave: autenticazione, scambio di chiavi e cifratura. Gli algoritmi che girano su computer quantistici non minacciano allo stesso modo tutti e tre. Contro l'autenticazione, per esempio, la minaccia si concretizza solo nel momento in cui serve autenticare. In TLS l'autenticazione è effimera, quindi non siamo in pericolo immediato. Non lo saremo finché i computer quantistici non diventeranno una realtà pratica.

I computer quantistici non avranno un grande impatto sulla cifratura, ma lo scambio di chiavi è già sotto attacco oggi, molto prima che esista un computer quantistico [rilevante dal punto di vista crittografico] funzionante. Un avversario capace può infatti raccogliere traffico cifrato oggi, conservarlo e decifrarlo più avanti, quando otterrà accesso a un computer quantistico. Questa minaccia è nota come "harvest now, decrypt later", o HNDL.

Vista questa asimmetria, non sorprende che il lavoro sia partito dalla ricerca di un nuovo approccio allo scambio di chiavi. Google ha annunciato il suo primo esperimento quasi esattamente 10 anni fa. Era più o meno il periodo in cui il NIST iniziava a pianificare il suo concorso sulla crittografia post-quantistica.

Oggi tutti i browser moderni supportano uno scambio di chiavi ibrido che combina la crittografia tradizionale (basata su curve ellittiche) con ML-KEM, l'algoritmo scelto per primo dal NIST a questo scopo. Le varianti in uso sono tre: X25519MLKEM768, SecP256r1MLKEM768 e SecP384r1MLKEM1024. La costruzione è la stessa in tutti e tre i casi, con differenze principali nei parametri della curva ellittica e nei livelli di sicurezza.

Sul piano tecnico, questo nuovo scambio di chiavi si compone dei seguenti livelli:

• Diffie-Hellman su curva ellittica (ECDH), parte della specifica TLS 1.3 fin dall'inizio
• ML-KEM, standardizzato dal NIST nel 2024 (ma annunciato vincitore nel 2022)
• RFC 9954: Hybrid Exchange in TLS 1.3
• RFC 10024: Post-Quantum Traditional Hybrid Key Agreement Mechanisms for TLS 1.3

Perché tutti questi pezzi? All'inizio c'era solo ECDH. Poi abbiamo dovuto inventare ML-KEM per affrontare la minaccia dei computer quantistici. Poiché ML-KEM è piuttosto nuovo e meno consolidato, e poiché la crittografia a curve ellittiche è compatta e veloce, si è deciso che un approccio ibrido avrebbe offerto la sicurezza migliore. Purtroppo TLS non prevedeva uno scambio di chiavi ibrido, quindi è stato necessario progettare la RFC 9954. Infine è arrivata la RFC 10024 a tenere insieme il tutto.

Nota anche che entrambe le RFC dicono esplicitamente "for TLS 1.3". L'IETF sta facendo del suo meglio per dirci che questi lavori non si applicano ai protocolli precedenti. TLS 1.2 è in feature freeze (RFC 9851) e si stanno scrivendo nuovi documenti per deprecare ciò che è deprecabile (RFC 10015).

Secondo Cloudflare, che ha una dashboard sul traffico post-quantistico che osserva, circa il 71% del traffico umano che arriva alla sua CDN usa uno scambio di chiavi ibrido ed è quindi protetto dalle minacce dei computer quantistici.

Questo è il dato in prima pagina, ma scorrendo si scopre che solo l'11% circa dei server di origine ha la stessa protezione. Dopo 10 anni di lavoro, lato server siamo lontani da un supporto diffuso dello scambio di chiavi resistente al quantistico. Il primo numero (71%) suona bene, ma l'avversario capace che ti preoccupa attaccherà dove sei debole, non dove sei forte.

Si potrebbe pensare che lo scambio di chiavi sia stato risolto in fretta, ma è così solo visto da lontano. Come detto, Google ha iniziato molto tempo fa. Quel primo esperimento, partito a luglio 2016, si è chiuso a novembre dello stesso anno. È stata dimostrata la fattibilità dell'approccio.

Il secondo esperimento è iniziato alla fine del 2019, come collaborazione tra Cloudflare e Google. Usava lo stesso approccio ibrido con altri due algoritmi, NTRU-HRSS e SIKE. Tre anni dopo, SIKE è stato violato. E questo ha rafforzato l'idea degli ibridi.

Dopo la scelta di ML-KEM da parte del NIST, l'attenzione si è spostata sul suo uso in costruzioni ibride. È entrato nelle librerie e i produttori di browser lo hanno supportato. Cloudflare lo ha attivato a ottobre 2022, con gli algoritmi provvisori X25519Kyber512Draft00 e X25519Kyber768Draft00. Sono serviti altri due anni perché ML-KEM fosse standardizzato, e poi tutti sono passati a X25519MLKEM768 e affini.

Nella puntata precedente ho dedicato l'intero articolo al forte aumento delle dimensioni delle firme post-quantistiche. Nella pratica, il passaggio allo scambio di chiavi ibrido ha già aumentato la dimensione dell'handshake TLS, di circa 1.100 byte per direzione.

Nel 2024 Google ha riportato un aumento mediano del 4% della latenza dell'handshake dovuto a questo cambiamento. AWS ha segnalato un lieve aumento del tempo di handshake in un ambiente controllato, per via del maggiore carico di calcolo. La conclusione principale è che l'aumento di latenza dipende dalla necessità di trasferire più dati per completare l'handshake TLS, e parliamo di circa 1 kB. L'aumento dovuto alle firme aggiungerà più di dieci volte tanto.

La migrazione degli algoritmi di scambio di chiavi sembra una storia di successo, ma c'è un piccolo intoppo: la National Security Agency statunitense (l'onnipotente NSA) non ama la crittografia ibrida.

A settembre 2022 la NSA ha lanciato la Commercial National Algorithm Suite 2.0 (nuovo nome; prima si chiamava NSA Suite B). Di per sé è stata un'ottima mossa, perché ha fissato presto una tabella di marcia e chiarito quali algoritmi usare. Purtroppo i suoi requisiti sullo scambio di chiavi vanno contro il resto del mondo.

Nella comunità tecnica la maggior parte delle persone [è una mia impressione, non una misura scientifica] preferisce l'approccio ibrido per la sicurezza in più che offre. La sensazione è che serva più tempo per accettare i nuovi algoritmi post-quantistici e testarne ulteriormente la solidità. I crittografi sono per natura molto prudenti. A conferma, questa settimana sono usciti due articoli di ricerca interessanti, uno che potrebbe intaccare la sicurezza dei problemi su reticoli e l'altro su Classic McEliece. Nulla è ancora rotto, ma ci piace ricordare che gli attacchi migliorano soltanto.

La divisione è più visibile nel gruppo di lavoro TLS dell'IETF, come confermerà chiunque segua la mailing list. Il punto è questo: l'IETF dovrebbe pubblicare un RFC informativo che documenta lo scambio di chiavi con ML-KEM puro? Da un lato c'è chi dice che, per via dei requisiti della NSA, quell'algoritmo verrà usato e serve una specifica comune. Dall'altro c'è chi sostiene che l'approccio ibrido è già stato adottato con successo, quindi perché dare legittimità a un approccio meno sicuro?

Per chiarezza, la direzione attuale non è solo marcare questo lavoro come informativo (quindi non uno standard), ma anche indicarlo come non raccomandato. Nemmeno questo è bastato a evitare discussioni infinite sulla lista. Il documento (draft-ietf-tls-mlkem-09) è attualmente in Last Call. È anche già implementato in alcuni browser, con priorità inferiore agli ibridi ma disponibile per i server che preferiscono l'approccio ML-KEM puro.