Novità della crittografia post-quantistica in RHEL 10.1

A maggio 2025, Red Hat Enterprise Linux 10 (RHEL) è stato distribuito con le prime tappe verso la crittografia post-quantistica (PQC) per proteggersi dagli attacchi dei computer quantistici, che renderanno possibili attacchi agli algoritmi di crittografia classici esistenti, come RSA e le curve ellittiche. Non è ancora nota l'esistenza di computer quantistici crittograficamente rilevanti (CRQC), ma ciò non significa che il rischio sia nullo. Ad esempio, gli attacchi "harvest now, decrypt later" non necessitano di un computer quantistico ora, ma è sufficiente che uno di essi sia disponibile prima che i dati crittografati archiviati perdano il loro valore e, a seconda dei dati trasferiti, potrebbero passare decenni prima che ciò accada.

Per prepararsi a un futuro quantistico, RHEL 10.1 migliora le difese contro gli attacchi "harvest now, decrypt later" e introduce firme post-quantistiche per i suoi pacchetti.

La sezione successiva illustra le modifiche apportate a PQC in Transport Layer Security (TLS), mentre quella che segue spiega una modifica ai criteri di crittografia predefiniti di RHEL. Sapevi che RHEL è la prima grande distribuzione Linux a firmare i propri pacchetti con chiavi ibride post-quantistiche?

La terza sezione illustra i dettagli di queste modifiche, prima di concludere con i passaggi successivi consigliati per gli utenti e i fornitori di software di terze parti.

Crittografia post-quantistica in TLS

TLS può utilizzare la crittografia post-quantistica in due modi: lo scambio di chiavi protegge dagli attacchi "harvest now, decrypt later", mentre le firme impediscono gli attacchi machine-in-the-middle che utilizzano i computer quantistici. Con il rilascio di RHEL 10.1, le applicazioni che utilizzano OpenSSL, GnuTLS, NSS o il linguaggio di programmazione Go hanno il supporto per lo scambio di chiavi post-quantistico abilitato per impostazione predefinita.

Le librerie di crittografia OpenSSL, GnuTLS e NSS supportano inoltre firme e certificati TLS con Module-Lattice-Based Digital Signature Algorithm (ML-DSA), un algoritmo PQC standardizzato dal NIST. Al momento, nessuna autorità di certificazione (CA) pubblica offre la crittografia post-quantistica, ma le CA private o i certificati autofirmati possono essere creati con ML-DSA.

In RHEL 10.0, questa funzionalità è disponibile in anteprima tecnica a causa della rapida evoluzione degli standard e delle implementazioni. Oggi la situazione sta cambiando: la crittografia post-quantistica con Module-Lattice-Based Key Encapsulation Mechanism (ML-KEM) e ML-DSA in TLS è generalmente disponibile e completamente supportata in Go, OpenSSL, GnuTLS e NSS.

In vista di RHEL 10.1, gli sviluppatori Red Hat hanno eseguito un test a livello di prodotto per lo scambio di chiavi PQC e per i certificati PQC. Questo ha permesso di individuare diversi problemi, che i responsabili della manutenzione dei pacchetti hanno risolto nei progetti open source upstream e downstream in RHEL. Ti consigliamo di iniziare subito a testare lo scambio di chiavi PQC ibrido nelle tue distribuzioni TLS e di pianificare l'adozione di due server di certificati TLS classici/PQC (vedi “Creating a post-quantum TLS certificate”).

Policy PQC by DEFAULT

Le impostazioni di crittografia su RHEL vengono gestite tramite policy crittografiche a livello di sistema, con DEFAULT come policy standard. In RHEL 10.1, questa policy è stata modificata per abilitare e preferire la crittografia post-quantistica per impostazione predefinita. Ciò significa che le connessioni TLS e SSH da e verso RHEL 10.1 o versioni successive utilizzeranno automaticamente lo scambio di chiavi post-quantistico, ove disponibile. Questi due protocolli sono ampiamente utilizzati e probabilmente rappresentano gran parte dei trasferimenti di dati crittografati, aumentando notevolmente il livello di sicurezza.

Le applicazioni su RHEL 9.7 basate su OpenSSL o NSS possono utilizzare anche PQC in TLS, se il modulo dei criteri di crittografia a livello di sistema “PQ” è abilitato, utilizzando sudo update-crypto-policies --set DEFAULT:PQ.

Per verificare la policy utilizzata dal tuo sistema, esegui update-crypto-policies --show.

Aggiornamenti dei pacchetti con firme post-quantistiche

Infine, gli sviluppatori Red Hat hanno lavorato per introdurre protezioni contro gli attacchi basati su computer quantistici per i nostri percorsi di distribuzione del software. Questo è importante perché gli aggiornamenti dei pacchetti attraverso questi percorsi saranno il modo in cui Red Hat fornirà miglioramenti futuri nella transizione post-quantistica.

Red Hat Enterprise Linux 10 utilizza l'implementazione Sequoia-PGP di OpenPGP per verificare le firme dei pacchetti. Una specifica per l'utilizzo di PQC in OpenPGP è nella fase finale e Red Hat ha contribuito al finanziamento della sua implementazione in Sequoia-PGP, che ora è disponibile come pre-release. Alcuni ambienti operativi dovranno rispondere a requisiti normativi per la firma del software PQC in tempi brevi. Per questo motivo, dopo test approfonditi, questa implementazione è già stata inclusa in RHEL 10.1.

Nell'ambito dello stesso progetto, gli strumenti sq-cryptoki e sq hanno ottenuto il supporto per l'accesso alle chiavi post-quantistiche tramite PKCS#11. Ciò consente l'integrazione con i moduli di sicurezza hardware. Red Hat ha modernizzato la sua infrastruttura di firma, ha creato una chiave di firma post-quantum che utilizza un ibrido di ML-DSA-87 ed Ed448 e ha iniziato a firmare i suoi pacchetti RPM con questa chiave. RHEL è la prima e, al momento, l'unica distribuzione Linux principale a raggiungere questo traguardo.

Il primo pacchetto firmato post-quantum è stato ipmitool-1.8.19-10.el10_1 in RHBA-2025:23156:

# dnf download ipmitool
ipmitool-1.8.19-10.el10_1.aarch64.rpm                                                                                                                                                                           
# rpm -Kv ipmitool-1.8.19-10.el10_1.aarch64.rpm | head -3
ipmitool-1.8.19-10.el10_1.aarch64.rpm:
    Header V6 ML-DSA-87+Ed448/SHA512 Signature, key ID 05707a62: OK
    Header V4 RSA/SHA256 Signature, key ID fd431d51: OK

Inoltre, questo pacchetto è ancora firmato dalla nostra chiave RSA. I sistemi che comprendono il formato dell'intestazione RPM 6 e le firme OpenPGP v6 verificheranno sia le firme RSA che le firme PQC. I sistemi meno recenti convalidano solo la firma RSA classica.

Conclusione

Red Hat ha compiuto passi importanti nella transizione post-quantum per preparare i propri clienti ai rischi futuri e ai requisiti normativi. TLS con scambio di chiavi ML-KEM ibrido non è più in anteprima tecnica e può mitigare gli attacchi "harvest now, decrypt later". Il supporto per i certificati e le firme ML-DSA nelle librerie di crittografia principali di RHEL, OpenSSL, GnuTLS e NSS è ora generalmente disponibile.

In linea con i recenti inviti del settore (ad esempio, lo European Cyber Resilience Act) verso una sicurezza per impostazione predefinita, la configurazione standard è stata modificata per abilitare e preferire algoritmi post-quantistici in TLS e SSH. Seguiranno altri protocolli in futuro. Incoraggiamo tutti i nostri utenti a implementare lo scambio di chiavi PQC e a testare le configurazioni dei certificati TLS dual classic/PQC con i propri server TLS. Scopri anche come preparare la tua organizzazione al futuro quantistico.

Infine, RHEL è la prima distribuzione principale ad aggiungere firme ibride post-quantistiche ai propri pacchetti. Per i nostri partner, il mio collega Jakub Jelen ha documentato come firmare i pacchetti RPM con chiavi post-quantistiche. L'integrazione con Hardware Security Modules tramite PKCS#11 3.2 è oggi possibile per la firma degli RPM: i nostri team di supporto e ingegneria possono aiutarti.

Go attualmente supporta solo ML-KEM a partire dalla versione 1.24. Il supporto per ML-DSA è previsto in una delle versioni future.