BSI TR-02102-1 e crittografia post-quantistica: le raccomandazioni 2026

BSI TR-02102-1 è la linea guida tecnica sui meccanismi crittografici pubblicata dall'Ufficio federale tedesco per la sicurezza informatica (BSI, Bundesamt für Sicherheit in der Informationstechnik). La versione 2026-01, datata 23 gennaio 2026, raccomanda l'accordo di chiavi post-quantistico ibrido, considera l'accordo di chiavi classico usato da solo raccomandato soltanto fino alla fine del 2031 (fine del 2030 dove le esigenze di protezione sono molto elevate) e fissa chiavi RSA di almeno 3000 bit. Si tratta di una linea guida tecnica, non di una legge, e questo articolo mostra come tradurre questi tre punti in una configurazione TLS verificabile.

Che cos'è la TR-02102-1, e che cosa non è

La TR-02102-1 elenca i meccanismi crittografici che il BSI ritiene idonei, ciascuno con lunghezze di chiave e un orizzonte temporale associati. È una guida. Di per sé non crea alcun obbligo per un'azienda privata. Diventa vincolante solo quando qualcos'altro la rende tale: un contratto con un cliente tedesco, una norma di settore, un requisito di un appalto pubblico o una policy crittografica interna che la richiama. Quest'ultima frase è la nostra lettura di come il documento viene usato nella pratica, non una citazione della linea guida.

Ne derivano due conseguenze per i team che servono clienti tedeschi. In primo luogo, citate sempre la versione. Ogni dato di questo articolo proviene dalla versione 2026-01, e dovreste riprenderli dalla versione in vigore al momento dell'audit. In secondo luogo, un questionario fornitori che chiede se siete conformi alla TR-02102-1 chiede in realtà se la configurazione effettivamente in esercizio corrisponde ai meccanismi raccomandati e ai relativi orizzonti. Le scadenze sono riassunte nella nostra pagina di riferimento sulla BSI TR-02102-1, e la linea guida stessa è pubblicata dal BSI in formato PDF: BSI TR-02102-1.

La posizione della versione 2026-01 sull'accordo di chiavi

La linea guida raccomanda l'accordo di chiavi post-quantistico ibrido. Ibrido significa combinare un accordo di chiavi classico, come il Diffie-Hellman su curve ellittiche (ECDH), con un meccanismo di incapsulamento delle chiavi (KEM) post-quantistico, in modo che la chiave di sessione resti sicura se almeno uno dei due componenti regge. In TLS 1.3 il componente post-quantistico oggi in produzione è ML-KEM (Module-Lattice-based Key Encapsulation Mechanism), standardizzato dal NIST come FIPS 203 il 13 agosto 2024.

Contano due date. L'accordo di chiavi classico usato da solo è raccomandato soltanto fino alla fine del 2031. Dove le esigenze di protezione sono molto elevate, la data diventa la fine del 2030. Si tratta di raccomandazioni con un orizzonte, non di una data di spegnimento imposta da un regolatore.

L'accordo di chiavi viene prima per una ragione tecnica, non normativa. Il traffico TLS registrato è protetto soltanto dallo scambio di chiavi che ha prodotto le sue chiavi di sessione. Un attaccante che oggi archivia il testo cifrato può decifrarlo in seguito, se lo scambio di chiavi diventa violabile: è lo schema noto come harvest now, decrypt later (HNDL). Firme e certificati non hanno questa proprietà: una firma verificata oggi non può essere falsificata retroattivamente. Per questo l'orizzonte dell'accordo di chiavi arriva prima di qualsiasi migrazione delle firme.

RSA di almeno 3000 bit, e ciò che non garantisce

La versione 2026-01 fissa una lunghezza minima delle chiavi RSA di 3000 bit. Nella pratica, autorità di certificazione, moduli di sicurezza hardware e librerie TLS lavorano con chiavi RSA a 3072 bit, che soddisfano la soglia e sono ampiamente supportate. Verificare la lunghezza della chiave di un certificato in esercizio richiede un solo comando.

openssl x509 -in server.crt -noout -text | grep -i public-key

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out server.key
openssl req -new -key server.key -out server.csr

Occorre essere precisi su ciò che si ottiene. Una chiave RSA più lunga aumenta il livello di sicurezza classico. Non rende la chiave resistente ai computer quantistici: RSA, ECDSA, EdDSA, ECDH, Diffie-Hellman su campi finiti e DSA sono tutti violati dall'algoritmo di Shor su un computer quantistico sufficientemente grande, qualunque sia la dimensione della chiave. La soglia di 3000 bit e la raccomandazione sull'accordo di chiavi ibrido rispondono a due problemi diversi, e soddisfare l'una non soddisfa l'altra.

Per confronto, NIST IR 8547 propone di deprecare gli algoritmi vulnerabili ai computer quantistici al livello di sicurezza di 112 bit, che include RSA-2048, dopo il 2030, e di vietare tutti gli algoritmi a chiave pubblica vulnerabili ai computer quantistici dopo il 2035. Quel documento è una bozza pubblica iniziale pubblicata il 12 novembre 2024 ed è ancora una bozza: NIST IR 8547 (ipd). Un minimo tedesco di 3000 bit e una deprecazione statunitense, ancora in bozza, delle chiavi a 2048 bit vanno nella stessa direzione, a partire da due testi diversi con due status diversi.

Tradurre la raccomandazione in una configurazione TLS

La linea guida raccomanda un meccanismo, l'accordo di chiavi ibrido. La scelta del gruppo TLS 1.3 concreto è una decisione implementativa, e quanto segue è la nostra corrispondenza pratica, non una citazione. I gruppi ibridi registrati presso IANA sono X25519MLKEM768 (codepoint 0x11EC, 4588), SecP256r1MLKEM768 (0x11EB, 4587) e SecP384r1MLKEM1024 (0x11ED, 4589), elencati nel registro IANA dei parametri TLS. Il loro uso in TLS 1.3 è descritto nella RFC 10024 (agosto 2026). Le versioni attuali di Chrome, Edge e Firefox offrono già X25519MLKEM768 per impostazione predefinita, quindi abilitarlo lato server cambia immediatamente ciò che i browser reali negoziano.

Passo 1: verificare che la libreria supporti i gruppi

Per i gruppi TLS ML-KEM in OpenSSL è necessario OpenSSL 3.5 o successivo. Verificatelo prima di modificare qualsiasi configurazione del server.

openssl version
openssl list -tls-groups | grep -i mlkem

Passo 2: offrire per primo il gruppo ibrido, mantenere un fallback classico

L'ordine conta: il gruppo ibrido va per primo, i gruppi classici restano dopo, così che i client meno recenti possano ancora connettersi. Non rimuovete mai il fallback classico nella stessa modifica.

# nginx, built against OpenSSL 3.5 or later
ssl_protocols TLSv1.3 TLSv1.2;
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;

# Apache httpd with mod_ssl, OpenSSL 3.5 or later
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLOpenSSLConfCmd Groups X25519MLKEM768:X25519:prime256v1

I nomi delle direttive e il relativo supporto variano tra distribuzioni e tra build della stessa versione del server, quindi verificate sul vostro pacchetto invece di darlo per scontato. Le procedure complete per nginx, Apache, HAProxy e Caddy si trovano nella nostra guida per abilitare ML-KEM sui principali server web. Testate in staging prima della produzione.

Passo 3: verificare ciò che viene effettivamente negoziato

openssl s_client -connect example.de:443 -tls1_3 -groups X25519MLKEM768 </dev/null | grep -i negotiated

Un handshake riuscito stampa il gruppo negoziato. Ripetete lo stesso test senza il gruppo ibrido per confermare che i client classici si connettono ancora.

Come si confronta l'orizzonte tedesco con le altre tempistiche

Le date tedesche non esistono isolatamente. Se servite clienti in più paesi, è l'orizzonte applicabile più vicino a guidare il piano.

Le evidenze che un cliente o un auditor tedesco chiederà

NIS2, Direttiva (UE) 2022/2555, articolo 21(2)(h), richiede politiche e procedure relative all'uso della crittografia e, se del caso, della cifratura. Per le entità finanziarie, le norme tecniche di regolamentazione DORA, Regolamento delegato (UE) 2024/1774 della Commissione, articolo 6, richiedono una politica in materia di cifratura e controlli crittografici che comprenda disposizioni per l'aggiornamento o la modifica della tecnologia crittografica in base agli sviluppi della crittoanalisi. Nessuno dei due testi menziona algoritmi post-quantistici.

La nostra interpretazione, chiaramente indicata come tale: citare la TR-02102-1 e la sua versione all'interno di quella politica, con i meccanismi che accettate e l'orizzonte che applicate, è un modo pratico per mostrare che la politica è ancorata a un riferimento riconosciuto e prevede un criterio di revisione. Mantenete gli artefatti semplici e datati: la politica stessa, un inventario degli endpoint TLS con i gruppi negoziati e le dimensioni delle chiavi dei certificati, e un risultato di scansione per ciascun endpoint. La nostra pagina su NIS2 articolo 21(2)(h) illustra ciò che la direttiva richiede. Questo articolo ha carattere informativo e non costituisce consulenza legale.

Passo successivo: verificate cosa negoziano oggi i vostri server

Prima di scrivere qualsiasi piano, misurate lo stato attuale. Scansionate il vostro dominio con PQC Status per vedere quali versioni TLS, gruppi di accordo di chiavi e algoritmi dei certificati il vostro server offre effettivamente, compreso se viene negoziato un gruppo ML-KEM ibrido. Una scansione descrive soltanto la configurazione TLS visibile dall'esterno: non è una certificazione né un'attestazione di conformità. Usate il risultato come prima riga del vostro inventario, poi abilitate il gruppo ibrido in staging, mantenete il fallback classico e registrate la situazione prima e dopo per ciascun endpoint.