Merkle Tree Certificates: la terza iterazione della Web PKI

Negli ultimi tre mesi ho esplorato la crittografia post-quantistica, il suo impatto su Internet e il modo in cui sta ridefinendo lo stato della crittografia e della sicurezza di rete. In questo post, il settimo e ultimo della serie, analizzo come l’autenticazione sul Web venga riprogettata attraverso i Merkle Tree Certificates (MTC).

All’inizio esisteva solo la Internet PKI, che copriva tutta l’autenticazione pubblica tra software client e server di ogni tipo. Nel caso non lo sapessi, PKI sta per Public Key Infrastructure (infrastruttura a chiave pubblica). Nonostante la parola “public” nel nome, le PKI non devono per forza essere pubbliche o aperte a tutti, ma la Internet PKI lo è.

La storia di come è nata la Internet PKI è affascinante, ma in sostanza si riduce a un ingegnere dei primi tempi di Netscape, Kipp Hickman, che impiegò tre mesi per mettere a punto tutto. Tra l’altro, in quel periodo lavorò alla prima versione di Secure Sockets Layer (SSL) e alla Internet PKI (basandosi su X.509, che esisteva già). A quanto pare, quest’ultima parte (l’autenticazione) fu in gran parte un ripensamento. Con il lavoro di Kipp, Netscape inaugurò l’era della comunicazione sicura, e il mondo la seguì.

Questo primo sistema funzionò per circa un decennio, ma alla fine le crepe divennero troppo grandi per essere ignorate. Il CA/Browser Forum, un gruppo di settore composto da CA e browser, nacque nel 2005 e nel 2007 pubblicò il suo primo documento per iniziare a formalizzare l’emissione dei certificati. Quel lavoro prosegue ancora oggi.

Parallelamente, i produttori di browser, con Google in prima linea, iniziarono a esercitare un controllo crescente su ciò che è considerato sicuro. I browser cominciarono a utilizzare i certificati in modo leggermente diverso, dando vita alla Web PKI. All’inizio le differenze erano minime. Una nuova tecnologia chiamata Certificate Transparency (CT) divenne obbligatoria nel 2018 e cambiò radicalmente la Web PKI. Questa aggiunta segnò la seconda iterazione della Web PKI, quella che usiamo oggi. La recente eliminazione dell’autenticazione client è stata l’ultima modifica che ha consolidato le differenze.

Tra poco entrerò nei dettagli, ma la decisione di riprogettare la Web PKI si riduce a tre problemi principali:

1. L’attuale ecosistema CT è già fragile così com’è
2. La prevista riduzione della durata dei certificati con ogni probabilità lo manderà in crisi
3. Le firme post-quantistiche, più grandi, gli daranno il colpo di grazia

In poche parole, la migrazione post-quantistica è l’occasione che ci permette di giustificare il lavoro necessario per far funzionare tutto in modo molto più fluido. Ci sarà molto lavoro nuovo, ma non butteremo via tutto ciò che abbiamo imparato finora.

Il ruolo della Certificate Transparency (CT) è garantire piena visibilità sull’emissione di certificati a livello mondiale. Ciò avviene registrando i certificati nei log CT, protetti tramite crittografia. Di conseguenza, i log CT sono diventati una parte critica dell’autenticazione sul Web.

Poiché tutti i principali browser e molti sistemi operativi ora richiedono CT, i certificati non possono essere emessi se non vengono registrati. Questo significa che servono log CT ad alta disponibilità, in grado di reggere i picchi di emissione mondiali, e anche qualcosa in più. Finora non ci sono stati grandi disservizi, ma se segui le mailing list giuste saprai che le difficoltà non sono mancate. Gli addetti ai lavori sono preoccupati.

Le decisioni già prese peggioreranno la situazione. Entro il 2029 la durata massima consentita dei certificati scenderà a soli 47 giorni, rispetto all’anno attuale, limite peraltro piuttosto recente. Passeremo quindi da un’emissione annuale a una mensile, con un aumento di 12 volte.

È anche possibile che vengano introdotte ulteriori riduzioni della durata. La prima policy di Apple sull’autenticazione post-quantistica, ad esempio, consente solo 7 giorni. Non è chiaro se il limite valga solo per la fase di prova o se l’intenzione sia di adottarlo definitivamente. Se rimarrà, si tratterà di un ulteriore aumento di 4 volte rispetto all’emissione mensile, finora la più breve. In tutto, circa 50 volte il carico attuale sull’ecosistema CT in termini di numero di emissioni.

L’aumento del numero di certificati è solo una parte del problema. Come forse ricorderai dal mio post precedente, le firme e gli algoritmi a chiave pubblica post-quantistici sono molto più grandi, il che da solo potrebbe portare a un aumento di 10-20 volte della dimensione dei certificati (e dei log CT). Moltiplica le due cose e capirai perché c’è preoccupazione.

La terza iterazione, sotto forma di Merkle Tree Certificates (MTC), è pensata come soluzione.

La differenza più importante degli MTC è che uniscono X.509 e CT. Nell’assetto attuale, CT è un componente aggiuntivo. Registrare i certificati in CT è un passaggio separato. Le organizzazioni che emettono i certificati sono diverse da quelle che li registrano in CT. Si tratta di una debolezza strutturale che porta a un disallineamento degli incentivi.

Con gli MTC, ogni CA gestisce un’istanza di un log CT (di nuova generazione) e vi scrive i propri certificati. La frase che sentirai spesso è che le CA “emetteranno tramite registrazione”. Dove prima c’erano due passaggi, ora ce n’è uno solo. Con questo cambiamento, ogni CA deve anche partecipare all’ecosistema CT; non c’è altra strada.

Poiché gli MTC vengono emessi tramite registrazione, i precertificati, attualmente richiesti in CT, non servono più. D’ora in poi verrà registrato un solo oggetto. Questo cambiamento riduce la complessità operativa e può ridurre fino alla metà la dimensione dei log CT. (Le CA più grandi oggi inviano a CT sia i precertificati sia i certificati.)

Un aspetto importante di CT è che l’emissione dei certificati viene attestata (witnessing) e replicata da terze parti. Non ci fidiamo che una singola organizzazione faccia la cosa giusta. In CT v1 i certificati vengono registrati singolarmente. Un log CT contiene una varietà di certificati emessi da CA diverse. Inoltre, chiunque può inviare un certificato da registrare nel log.

Con gli MTC, attestazione e replica avvengono a livello di log. Le CA emettono i certificati registrandoli nei propri log. Questi vengono firmati, quindi attestati e replicati in blocchi. Un log mirror è identico al log originale. Questo comporta notevoli vantaggi:

• Le operazioni in blocco sono più snelle ed efficienti.
• Le terze parti non possono più inviare certificati arbitrari, il che riduce la duplicazione del lavoro (certificati registrati inutilmente) ed evita di sovraccaricare i log CT.
• I monitor non devono più controllare tutti i log CT del mondo per ottenere tutti i certificati; basta monitorarne un’istanza, o addirittura bilanciare il carico tra più istanze dello stesso log.

Poiché tutti gli emittenti di MTC sono anche operatori di log MTC, è probabile che si accordino con altre CA con volumi di emissione simili per replicare reciprocamente i rispettivi certificati.

Agli albori di CT, ogni log aveva una sola istanza, e per un po’ ha funzionato bene. I primi log erano annuali perché, una volta scaduti tutti i certificati di un log, non era più necessario conservarli. Col tempo, però, i log annuali sono diventati troppo grandi e si sono aggiunti shard più piccoli (ad es. intervalli di 6 mesi).

La creazione e la gestione degli shard dei log CT comportano un carico operativo continuo e significativo. Gli operatori devono dedicare molto tempo a creare e gestire gli shard, per poi eliminarli. I nuovi shard devono poi essere monitorati e convalidati in collaborazione con i principali utilizzatori (i produttori di browser). Infine, le relative informazioni devono essere distribuite agli utenti finali.

Gli MTC supportano la potatura (pruning) dei log. Grazie al modo in cui i log sono costruiti internamente (e a come è progettata la convalida crittografica), è possibile rimuovere del tutto le parti scadute. Sarà un cambiamento molto gradito per chi deve assicurarsi che l’ecosistema funzioni, e funzioni bene.

Nell’attuale progettazione di CT, ogni voce contiene la chiave pubblica associata e la firma della CA. Oggi sono piccole, ma con la PQC le loro dimensioni esploderanno. Con gli MTC, le chiavi pubbliche vengono omesse e sostituite da una combinazione di identificatore dell’algoritmo e hash. Anche le firme delle CA sono escluse (perché i log MTC vengono firmati in blocchi).

Questo cambiamento riduce in modo significativo la dimensione dei log CT, soprattutto considerando che d’ora in poi non ci saranno più precertificati e che non sarà possibile registrare certificati arbitrari.

Abbiamo visto che gli MTC renderanno molto più semplice gestire gli aspetti di trasparenza dell’autenticazione sul Web. La maggior parte delle analisi, tuttavia, si concentra sulla riduzione delle dimensioni degli handshake TLS. Per capire il problema, ti consiglio di leggere il mio post precedente sulle dimensioni delle firme post-quantistiche e sul loro impatto sulle prestazioni di rete. Potrebbe interessarti anche questo post di approfondimento, dedicato ai dati a supporto delle affermazioni sulle prestazioni.

I Merkle Tree Certificates esistono in due forme. La prima si chiama standalone ed è più o meno equivalente, nella forma, ai certificati che conosciamo oggi (X.509 + CT).

Nei certificati standalone, le firme sono sostituite da una prova di inclusione (inclusion proof), una struttura basata su hash che svolge una funzione simile. Il punto cruciale è che, sebbene le prove di inclusione siano più grandi delle firme RSA ed EC attuali (circa 384 byte), sono molto più piccole delle firme post-quantistiche. Di conseguenza, i singoli MTC standalone sono molto più leggeri.

C’è un’altra novità. Gli MTC vengono emessi direttamente da CA attendibili, quindi nell’handshake TLS non servono più certificati intermedi, il che riduce ulteriormente le dimensioni.

I certificati standalone sono concettualmente semplici, ma non bastano a riportare le dimensioni degli handshake TLS post-quantistici ai livelli attuali. Se vogliamo fare di meglio, dobbiamo fare di più e accettare una complessità molto maggiore. Questo avviene tramite la seconda forma che gli MTC possono assumere, i cosiddetti Landmark-Relative Certificates.

I certificati standalone sono più piccoli, ma devono comunque contenere firme, che nel mondo post-quantistico sono molto grandi. I Landmark-Relative Certificates (LRC) sono molto più piccoli perché il loro unico meccanismo di autenticazione è una prova di inclusione; non contengono firme. La prova di inclusione degli LRC non è la stessa dei certificati standalone ed è quindi leggermente più grande, ma non di molto (circa 736 byte, all’incirca il doppio).

C’è però un inconveniente. Per funzionare, gli LRC hanno bisogno di prove di inclusione emesse rispetto a landmark, cioè gruppi (sottoalberi) di certificati emessi. Per autenticare queste prove di inclusione, gli user agent devono disporre in anticipo di informazioni sui landmark corrispondenti, il che significa che devono recuperare continuamente qualcosa da qualche parte per ogni CA di cui si fidano. Ahi.

Se sei un utente finale, nulla di tutto questo ti riguarderà. Supportare gli LRC comporta molta complessità aggiuntiva, ma sarà gestita e “pagata” dagli sviluppatori di user agent e dagli operatori dei server. Per questi ultimi, la speranza è che la maggior parte venga gestita dal software di automazione, tramite ACME.

I Landmark-Relative Certificates sono un’ottimizzazione. Quando tutto va bene, gli handshake TLS saranno brevi e veloci. Altrimenti, gli user agent ripiegheranno sui certificati standalone, più lenti, ma senza che nulla si rompa.

Sul fronte positivo, secondo Cloudflare gli LRC offrono prestazioni migliori del 9% rispetto alle catene di certificati classiche che usiamo oggi. Il vantaggio sarebbe molto più ampio rispetto ai certificati standalone, e decisamente maggiore rispetto a ipotetiche catene di certificati X.509 + ML-DSA che non vogliamo usare sull’Internet pubblico.

Detto questo, nelle reti private, che sono ambienti controllati e spesso dispongono di una connettività molto più veloce, le differenze di prestazioni potrebbero essere meno marcate. Una semplice evoluzione di X.509 con l’aggiunta di ML-DSA potrebbe funzionare benissimo.

Dopo tutto questo, proviamo a capire di quanti certificati potremmo avere bisogno per ottenere le massime prestazioni. Oggi la configurazione più solida prevede due certificati: uno EC, più veloce, e uno RSA, ampiamente supportato.

Per neutralizzare la minaccia dei computer quantistici crittograficamente rilevanti, dovremo passare all’autenticazione post-quantistica tramite gli MTC. Come minimo, questo significa supportare i certificati standalone. Ce ne serviranno quindi almeno tre, per supportare sia gli user agent moderni sia quelli più arretrati.

Purtroppo, con un solo certificato standalone, le prestazioni dell’handshake TLS saranno inferiori a quelle attuali. Forse va bene così, ma se vogliamo rimediare dobbiamo supportare anche i Landmark-Relative Certificates. E ce ne serviranno due, non uno solo.

Avremo quindi bisogno di almeno cinque certificati per servizio.

Ci sono un paio di motivi per cui esistono certificati standalone e Landmark-Relative Certificates. I certificati standalone possono essere creati subito, al momento dell’emissione. Gli LRC, invece, vengono prodotti in blocchi, quindi non sono disponibili immediatamente. Dovrai attendere un certo periodo (ad es. 1 ora) prima di poterne ottenere uno corrispondente al tuo certificato standalone.

E non è tutto. Come abbiamo visto, affinché un LRC possa essere autenticato, gli user agent devono prima recuperare informazioni dalla CA. (Indirettamente, tramite un servizio di aggiornamento dello user agent.) Gli user agent non controlleranno continuamente la presenza di nuovi landmark, ma li recupereranno solo periodicamente. Inoltre, potrebbero restare offline per un certo periodo. Di conseguenza, in genere gli user agent non avranno i landmark più recenti.

Riassumendo: 1) serve un certificato standalone per tutti, 2) un Landmark-Relative Certificate meno recente per la maggior parte degli user agent e 3) un certificato landmark più recente che, man mano che gli user agent si aggiornano, diventerà il tuo certificato principale.

Prova a immaginare di fare tutto questo a mano. Non c’è da stupirsi che serva ACME… l’automazione è l’unico modo per far funzionare il tutto. E anche così, diagnosticare i problemi di autenticazione e di prestazioni diventerà più difficile. Un monitoraggio continuo, per individuare i problemi in anticipo, diventerà necessario per una gamma molto più ampia di organizzazioni.