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

1. Problématique et Contexte

L'architecture O-RAN (Open Radio Access Network) introduit une décomposition des fonctions du réseau d'accion radio (RAN) et une virtualisation accrue, ce qui élargit la surface d'attaque. L'interface E2, qui relie le nœud 5G (gNB) au Contrôleur Intelligent RAN (Near-RT RIC), est critique car elle transporte des données de contrôle et de télémétrie en temps quasi réel (contraintes de latence de 10 ms à 1 s).

Bien que l'O-RAN exige l'utilisation d'IPsec pour sécuriser cette interface, les algorithmes de cryptographie asymétrique actuels (comme ECDH ou RSA) sont vulnérables aux futurs ordinateurs quantiques via l'algorithme de Shor. Cela expose les réseaux à la menace « stocker maintenant, déchiffrer plus tard » (store-now, decrypt-later).

Le problème central est l'absence de données empiriques sur l'impact des algorithmes de cryptographie post-quantique (PQC), spécifiquement le mécanisme d'encapsulation de clés basé sur les réseaux ML-KEM (anciennement Kyber, standardisé par le NIST), sur la performance de l'interface E2. Les opérateurs ont besoin de savoir si l'intégration du PQC dans IPsec compromet les contraintes de latence strictes du contrôle RAN.

2. Méthodologie et Testbed

Les auteurs ont conçu et déployé un banc d'essai open-source, reproductible et aligné sur les standards pour évaluer l'impact du PQC.

• Architecture du Testbed :

  • RAN et Cœur de réseau : Utilisation de srsRAN (pour l'émulation gNB/DU/CU), Open5GS (cœur 5G) et srsUE (équipement utilisateur).
  • Contrôle Intelligent : Utilisation de FlexRIC pour émuler le Near-RT RIC et exécuter des applications (xApps) générant du trafic de signalisation réaliste.
  • Sécurité : Implémentation d'IPsec via strongSwan (version 6.0.1) compilé avec la bibliothèque liboqs pour supporter les algorithmes PQC.
  • Topologie : Les composants sont distribués sur plusieurs machines virtuelles (VM) pour simuler des sauts réseau réalistes entre le gNB et le RIC.

• Scénarios d'Expérimentation :
  Trois configurations ont été comparées :

  1. Base : Aucune IPsec (référence de latence brute).
  2. Classique : IPsec avec échange de clés ECDH (Courbe 25519).
  3. Post-Quantique : IPsec avec échange de clés ML-KEM (paramètres 768 et 1024).

• Métriques Mesurées :

  • Latence de configuration du tunnel (SA Setup) : Temps écoulé entre l'initiation IKEv2 et l'établissement de la sécurité (IKE_SA et Child_SA).
  • Impact sur les xApps : Stabilité des boucles de contrôle du RIC et temps de démarrage des applications de contrôle.
  • Latence de données : Surcharge introduite par le chiffrement symétrique (AES-256-GCM) une fois le tunnel établi.

3. Contributions Clés

1. Première évaluation empirique : Il s'agit de la première étude mesurant l'impact de ML-KEM sur l'interface E2 d'O-RAN dans un environnement reproductible utilisant des composants open-source standards.
2. Cadre reproductible : La publication fournit une infrastructure complète (srsRAN, Open5GS, FlexRIC, strongSwan+liboqs) permettant à la communauté de reproduire et d'étendre les tests de sécurité PQC dans les réseaux radio.
3. Preuve de faisabilité opérationnelle : L'étude démontre quantitativement que la migration vers le PQC sur l'interface E2 est réalisable sans perturber les boucles de contrôle critiques du Near-RT RIC.

4. Résultats et Analyse

Les résultats, obtenus via des exécutions automatisées et répétées, montrent les points suivants :

• Surcharge de Latence de Tunnel (IKE Setup) :

  • L'intégration de ML-KEM ajoute un délai d'environ 3 à 5 ms par rapport à l'IPsec classique (ECDH) lors de la phase d'établissement du tunnel (IKE Initiation).
  • Détail : L'initiation IKE avec ECDH prend environ 1,3 ms, tandis que ML-KEM-768 prend ~4,3 ms et ML-KEM-1024 ~6,0 ms. La différence est principalement due au coût computationnel des opérations sur les réseaux (lattice-based).
  • Les phases d'authentification (IKE Auth) et de création des Child SA restent comparables entre les deux méthodes.

• Impact sur le Trafic de Données (Runtime) :

  • Une fois le tunnel établi, la latence ajoutée par le chiffrement symétrique (AES-256) est d'environ 165 µs par rapport à un trafic non chiffré.
  • Il n'y a aucune différence significative de performance entre l'IPsec classique et l'IPsec PQC une fois le tunnel établi, car la phase de chiffrement symétrique est identique.

• Stabilité des xApps :

  • Les applications de contrôle (xApps) du Near-RT RIC et leurs boucles de rétroaction fonctionnent de manière stable.
  • Le délai entre le lancement d'une commande xApp et l'émission du premier paquet n'est pas affecté par le type de KEM utilisé, car le tunnel IPsec est opérationnel avant le début du trafic de contrôle.

5. Signification et Conclusion

Cette étude conclut que l'intégration de ML-KEM dans IPsec pour sécuriser l'interface E2 d'O-RAN est pratiquement faisable sur du matériel serveur standard.

• Impact sur le déploiement : L'ajout de 3 à 5 ms à la phase d'établissement de session est négligeable par rapport aux contraintes de temps réel du RAN (qui opèrent sur des échelles de 10 ms à 1 s). Cela valide la stratégie de migration progressive vers la sécurité post-quantique sans compromettre la qualité de service (QoS).
• Recommandations : Les opérateurs peuvent envisager des déploiements hybrides ou purement PQC pour l'interface E2, en sachant que le coût principal se situe uniquement lors de la réinitialisation des tunnels (handshake), et non pendant le trafic continu.
• Travaux futurs : Les auteurs prévoient d'étendre ces évaluations aux interfaces basées sur TLS (A1, O1, O2) et d'explorer l'utilisation de l'apprentissage fédéré (Federated Learning) pour optimiser les paramètres de sécurité PQC de manière collaborative entre différents fournisseurs.

En résumé, ce papier fournit la preuve empirique nécessaire pour rassurer les opérateurs sur la viabilité de la migration vers des réseaux 5G/6G résistants aux attaques quantiques.