Approfondimento sul supporto della crittografia post-quantistica nel piano di controllo di Red Hat OpenShift 4.20

L'era dell'informatica quantistica si avvicina e, con la sua immensa potenza di elaborazione, rappresenta una minaccia significativa per le basi crittografiche del nostro mondo digitale. In questo articolo analizzeremo il supporto emergente per la crittografia post-quantistica (PQC) in Red Hat OpenShift 4.20, concentrandoci sul miglioramento dei componenti principali del piano di controllo di Kubernetes: apiserver, kubelet, scheduler e controller-manager. Non ci soffermeremo su etcd, che utilizza una versione precedente di Go.

La minaccia quantistica

I moderni sistemi crittografici a chiave pubblica, come RSA e la crittografia ellittica (ECC), costituiscono la base della comunicazione online potenziata dalla sicurezza. Tuttavia, questi sistemi sono vulnerabili agli attacchi dei computer quantistici su larga scala, il che può risolvere i problemi matematici alla base di questi algoritmi con una velocità allarmante. Questa vulnerabilità ha dato origine ad attacchi in cui soggetti malintenzionati registrano il traffico crittografato oggi per decrittografarlo in futuro, una volta che avranno accesso a un potente computer quantistico. Lo stesso problema si applica ai dati inattivi, se il soggetto riesce a crearne una copia per decrittografarla in un secondo momento.

Per contrastare questa minaccia, è emerso il campo della PQC, sviluppando nuovi algoritmi di crittografia resistenti agli attacchi dei computer classici e quantistici.

PQC in Kubernetes e OpenShift

Red Hat OpenShift è una distribuzione certificata Cloud Native Computing Foundation (CNCF) di Kubernetes e Kubernetes è scritto nel linguaggio di programmazione Go. Pertanto, il percorso verso il supporto PQC in OpenShift inizia con Go.

La versione Go 1.24 ha segnato un importante traguardo introducendo il supporto per il meccanismo di scambio di chiavi ibride X25519MLKEM768. X25519MLKEM768 è uno scambio di chiavi ibrido che combina il classico X25519 (curva ellittica di Diffie-Hellman) con ML-KEM-768 (l'algoritmo post-quantistico). Il segreto finale condiviso deriva dalla combinazione di entrambi i meccanismi. Pure ML-KEM fa affidamento unicamente sulla crittografia basata su reticolo per la resistenza quantistica. X25519MLKEM768 offre contemporaneamente la resistenza quantistica di ML-KEM e la sicurezza tipica di X25519.

Al momento, l'approccio ibrido è decisamente più robusto. ML-KEM è stato standardizzato solo nell'agosto 2024, il che significa che è considerato “giovane” in termini crittografici. Se qualcuno rilevasse un attacco classico inaspettato contro i presupposti del reticolo di ML-KEM (non tramite la crittoanalisi quantistica, ma con la normale crittoanalisi), i deployment ML-KEM puri verrebbero violati. Con l'approccio ibrido, X25519 mantiene la situazione sotto controllo.

Il segreto condiviso risultante per una sessione Transport Layer Security (TLS) fornisce il livello di sicurezza previsto, a condizione che almeno uno degli algoritmi dei componenti rimanga intatto. In questo modo è possibile introdurre la PQC nell'ecosistema in modo affidabile e compatibile con le versioni future.

Applicazione di PQC al piano di controllo di OpenShift

Il supporto per PQC in OpenShift 4.20 non riguarda la configurazione di flag PQC specifici su ciascun componente Kubernetes. Riguarda invece l’efficace comunicazione TLS tra questi componenti, resa possibile dalla versione alla base di Go e dalle relative librerie di crittografia.

Ecco come il supporto PQC migliora la sicurezza della comunicazione tra i componenti principali di OpenShift (di seguito parleremo anche dello stato etcd):

• Server API: essendo l'hub centrale del piano di controllo Kubernetes, tutte le comunicazioni da e verso il server API sono un punto critico per la sicurezza. Con TLS abilitato per ML-KEM, la comunicazione con il piano di controllo è protetta dagli attacchi che registrano il traffico crittografato attuale con l’intenzione di decrittografarlo in futuro.
• Kubelet: il kubelet, in esecuzione su ciascun nodo, comunica con il server API per fornire aggiornamenti sullo stato del nodo e ricevere le specifiche del pod. Questa comunicazione ora prevede uno scambio di chiavi PQC ibrido per una maggiore sicurezza, contribuendo a verificare l'integrità e la riservatezza del collegamento.
• Scheduler e controller-manager: lo scheduler e il controller-manager interagiscono continuamente con il server API per prendere decisioni sulla pianificazione e gestire lo stato del cluster. Queste interazioni sono protette anche dal protocollo TLS abilitato per ML-KEM per rafforzare la sicurezza della logica e delle operazioni che consentono l’esecuzione delle applicazioni.

Il punto di vista di Red Hat

Sebbene molte normative di settore non richiedano la PQC fino al 2035, stiamo lavorando attivamente alla transizione alla PQC. Nel recente articolo intitolato “Preparing your organization for the quantum future”, abbiamo sottolineato l'importanza di iniziare subito il percorso verso la PQC. Inoltre, il lavoro svolto per integrare PQC in Red Hat Enterprise Linux (RHEL) è un valido indicatore della direzione da seguire con OpenShift. L'inclusione delle funzionalità PQC in OpenShift 4.20 è un passo avanti significativo.

Le versioni Go

Una questione fondamentale per gli amministratori riguarda la potenziale mancata corrispondenza delle versioni Go tra i diversi componenti di un cluster. Ad esempio, se un client kubectl creato con una versione Go compatibile con ML-KEM comunica con un server API precedente, l'handshake TLS potrebbe eseguire il downgrade automatico a un algoritmo crittografico classico. Ciò comporterebbe la perdita della protezione PQC senza alcun avviso esplicito. È quindi essenziale verificare che tutti i componenti dell'ambiente OpenShift eseguano versioni compatibili in grado di supportare PQC.

Che dire di etcd?

Mentre i componenti principali del piano di controllo beneficiano del TLS abilitato per ML-KEM, per etcd funziona diversamente, poiché è radicato nel suo ruolo ed ha una filosofia di sviluppo distinta. In quanto fonte di attendibilità definitiva per l'intero cluster, le priorità assolute di etcd sono la stabilità, l'integrità dei dati e le prestazioni. Il progetto etcd mantiene intenzionalmente una pianificazione del controllo delle versioni Go più conservativa rispetto a Kubernetes. Mentre il progetto Kubernetes adotta spesso l'ultima versione Go per utilizzare rapidamente le nuove funzionalità e migliorare le prestazioni, il team di etcd dà la priorità alla stabilità mantenendo le versioni Go precedenti e più testate per le sue versioni stabili. Questo ritardo intenzionale aiuta la community a valutare a fondo eventuali problemi in un nuovo runtime Go prima che venga introdotto in un componente critico come etcd.

La mancanza di un supporto immediato per la PQC non è una svista, ma una diretta conseguenza di questo approccio incentrato sulla stabilità. Prima che gli algoritmi PQC, introdotti in Go 1.24, possano essere ufficialmente supportati in etcd, la versione Go deve essere adottata nelle branch release stabili di etcd, che attualmente continuano ad utilizzare Go 1.23. Questo processo prevede una convalida approfondita per confermare che non ci siano ripercussioni negative sul protocollo di consenso Raft, sulla latenza di I/O o sulle operazioni di ripristino. Seguici per scoprire il supporto quantum-safe di etcd nelle prossime versioni.

La strada da percorrere

L'integrazione di PQC in OpenShift 4.20 testimonia l'approccio proattivo che Red Hat sta adottando per sviluppare un futuro quantum ready per il cloud native computing. Sebbene la PQC per firme digitali e certificati sia ancora nelle fasi iniziali, l'implementazione dello scambio di chiavi ibrido in TLS è un primo passo fondamentale.