Towards Quantum-Safe O-RAN -- Experimental Evaluation of ML-KEM-Based IPsec on the E2 Interface

Titolo: Verso O-RAN Quantum-Safe: Valutazione Sperimentale di IPsec basato su ML-KEM sull'Interfaccia E2

1. Il Problema e il Contesto

Le reti Open Radio Access Network (O-RAN) stanno espandendo la loro adozione, offrendo interoperabilità multi-vendor e intelligenza basata sull'IA. Tuttavia, la loro natura disaggregata e virtualizzata amplia la superficie di attacco, rendendo critiche le interfacce di controllo come l'interfaccia E2, che collega il nodo 5G (gNB) al Near-Real-Time RAN Intelligent Controller (Near-RT RIC).
Attualmente, l'interfaccia E2 è protetta da IPsec utilizzando crittografia classica (es. scambio di chiavi ECDH). Con l'avanzare del calcolo quantistico, gli algoritmi a chiave pubblica attuali (RSA, ECC) sono vulnerabili agli attacchi "store-now, decrypt-later" (cattura ora, decifra dopo).
Sebbene l'NIST abbia standardizzato nuovi algoritmi post-quantistici (PQC), come ML-KEM (precedentemente CRYSTALS-Kyber), manca ancora evidenza empirica su come l'integrazione di questi algoritmi nell'IPsec dell'interfaccia E2 impatti le prestazioni in tempo reale, cruciali per il controllo della rete radio. Gli operatori di rete necessitano di dati concreti per valutare il compromesso tra sicurezza quantistica e latenza.

2. Metodologia Sperimentale

Gli autori hanno sviluppato un banco di prova (testbed) open-source, riproducibile e allineato agli standard O-RAN per valutare l'impatto delle prestazioni.

• Architettura del Testbed:
  • RAN e Core: Utilizzo di srsRAN (per emulare gNB e UE), Open5GS (Core 5G) e FlexRIC (piattaforma Near-RT RIC con xApps).
  • Sicurezza: Implementazione di strongSwan (patchato con la libreria liboqs) per gestire il protocollo IPsec/IKEv2.
  • Topologia: L'interfaccia E2 è protetta da un tunnel IPsec tra l'host O-CU (gNB) e l'host Near-RT RIC.
• Scenari di Confronto:
  1. Baseline: Nessuna protezione IPsec.
  2. Classico: IPsec con scambio di chiavi ECDH (Curve25519).
  3. Post-Quantistico (PQC): IPsec con scambio di chiavi ML-KEM (parametri ML-KEM-512, 768 e 1024).
• Metriche Valutate:
  • Latenza di Setup del Tunnel: Tempo necessario per stabilire la Security Association (SA) di IPsec (dall'inizio di IKEv2 alla disponibilità del tunnel).
  • Stabilità degli xApp: Impatto sul comportamento delle applicazioni RIC (xApp) e sui loop di controllo durante l'avvio del tunnel.
  • Overhead di Runtime: Latenza aggiuntiva nel traffico dati una volta stabilito il tunnel.

3. Contributi Chiave

Il paper offre tre contributi principali:

1. Prima Valutazione Empirica: È la prima analisi sperimentale che valuta l'integrazione di ML-KEM nell'IPsec specifico per l'interfaccia E2 di O-RAN, utilizzando un testbed open-source e standardizzato.
2. Framework Riproducibile: Fornisce una documentazione dettagliata e un ambiente riproducibile per studiare la sicurezza delle interfacce O-RAN potenziata dalla PQC, facilitando futuri studi da parte della comunità di ricerca.
3. Evidenza Quantitativa: Dimostra che l'adozione di ML-KEM è fattibile senza compromettere i requisiti di tempo reale, fornendo dati concreti per le strategie di migrazione verso la sicurezza quantistica.

4. Risultati Sperimentali

I risultati, ottenuti da esecuzioni automatizzate e ripetute, mostrano quanto segue:

• Latenza di Setup (IKEv2):
  • L'integrazione di ML-KEM introduce un ritardo aggiuntivo principalmente nella fase di scambio delle chiavi (IKE Initiation).
  • Rispetto all'IPsec classico (ECDH), l'uso di ML-KEM-768 aggiunge circa 3 ms di latenza.
  • L'uso di ML-KEM-1024 aggiunge circa 4.7 ms di latenza.
  • Le fasi di autorizzazione (IKE Auth) e setup della Child SA rimangono simili tra le configurazioni classiche e PQC.
• Impatto sul Traffico Dati e xApp:
  • Una volta stabilito il tunnel, l'overhead di latenza sul traffico dati (payload) è trascurabile e simile a quello dell'IPsec classico (circa 165 µs aggiuntivi rispetto al traffico non cifrato, dovuti alla crittografia simmetrica AES-256-GCM, non al KEM).
  • Nessuna interruzione operativa: Le applicazioni xApp e i loop di controllo del Near-RT RIC sono rimasti stabili. Non sono stati osservati ritardi significativi nell'avvio del traffico di controllo o errori di timeout che potrebbero compromettere la gestione della rete radio.
• Confronto con la Latenza di Base:
  • L'IPsec classico aggiunge circa 165 µs di latenza rispetto al traffico non cifrato.
  • L'IPsec PQC mantiene questa latenza di runtime, spostando il costo computazionale quasi esclusivamente sulla fase iniziale di negoziazione del tunnel.

5. Significato e Conclusioni

Il paper conclude che l'integrazione di ML-KEM nell'IPsec per l'interfaccia E2 è praticamente fattibile su hardware server di classe corrente.

• Implicazioni per gli Operatori: Il piccolo overhead di latenza (3-5 ms) nella fase di setup è accettabile e non compromette i requisiti di tempo reale (10ms-1s) del Near-RT RIC. Questo suggerisce che la migrazione verso la crittografia post-quantistica può iniziare in modo graduale ("staged migration") senza rischiare la stabilità della rete.
• Lavori Futuri: Gli autori intendono estendere lo studio alle interfacce basate su TLS (A1, O1, O2) e esplorare l'uso del Federated Learning (FL) per ottimizzare la selezione degli algoritmi PQC e rilevare anomalie in modo collaborativo tra diversi vendor, senza condividere dati sensibili.

In sintesi, lo studio fornisce la prova empirica necessaria per rassicurare gli operatori di rete sul fatto che la sicurezza quantistica può essere implementata nelle reti O-RAN critiche mantenendo le prestazioni richieste per il controllo in tempo reale.