Sécurité Open RAN en Europe : pourquoi les tests souverains sont indispensables

NOC d’un opérateur européen, 2 heures du matin. Une rafale anormale de messages RRC Reconfiguration apparaît sur le tableau de bord de supervision d’un site O-RAN fraîchement déployé. Le xApp du fournisseur B déclenche des handovers inattendus sur l’unité radio du fournisseur A. Le fournisseur A incrimine le RIC. Le fournisseur B incrimine la configuration radio. L’intégrateur pointe le timing du fronthaul. Personne ne porte la responsabilité du problème.

Ce n’est pas un scénario fictif. C’est la réalité opérationnelle de l’Open RAN multi-vendeurs. Et lorsque la sécurité est en jeu, la question devient : qui valide le système assemblé ?

La promesse Open RAN et ses contreparties en matière de sécurité

L’architecture O-RAN Alliance désagrège le RAN traditionnel en composants modulaires et interopérables : O-CU (Centralized Unit), O-DU (Distributed Unit), O-RU (Radio Unit) et le RIC (RAN Intelligent Controller) avec son écosystème de xApps et rApps. L’objectif est la diversité des équipementiers, la réduction des coûts et l’innovation par les interfaces ouvertes.

La contrepartie est structurelle : la désagrégation multiplie les interfaces, et chaque interface constitue une surface d’attaque potentielle. Un RAN monolithique d’un seul équipementier possède des interfaces internes propriétaires et opaques. Un déploiement O-RAN expose des interfaces standardisées et documentées entre composants de fournisseurs différents. Les interfaces ouvertes facilitent l’intégration. Elles facilitent aussi le sondage.

La norme 3GPP TS 33.501 définit l’architecture de sécurité 5G, incluant l’authentification, la gestion des clés et la protection d’intégrité du plan utilisateur. Le groupe de travail O-RAN WG11 (Security Work Group) a publié des spécifications pour sécuriser les interfaces O-RAN : l’interface E2 entre le RIC et l’O-DU/O-CU, l’interface A1 entre le Non-RT RIC et le Near-RT RIC, et l’interface de gestion O1.

Mais les spécifications ne sont pas des implémentations. Et les implémentations testées en isolation ne sont pas des systèmes testés en conditions réelles.

Les nœuds orange représentent les interfaces où l’intégration multi-vendeurs introduit le risque le plus élevé. Chacune est une frontière où le code du fournisseur A rencontre celui du fournisseur B, avec des hypothèses de sécurité qui ne sont pas nécessairement alignées.

La réponse réglementaire européenne : Toolbox 5G et NIS2

L’Europe n’a pas ignoré le risque. Le cadre réglementaire pour la sécurité 5G et Open RAN s’est construit progressivement depuis 2019, avec deux instruments majeurs désormais en vigueur.

La Toolbox 5G de l’UE, adoptée en janvier 2020 et mise à jour en 2023, définit des mesures stratégiques pour les États membres. Elle aborde explicitement le profil de risque des fournisseurs, recommandant des restrictions sur les équipementiers à haut risque pour les fonctions de cœur de réseau et les composants RAN sensibles. La Toolbox ne bannit aucun fournisseur nommément, mais le cadre est conçu pour permettre des décisions nationales sur les restrictions de fournisseurs.

La directive NIS2 (Directive 2022/2555), effective depuis octobre 2024, classe les télécommunications comme secteur essentiel. Les opérateurs sont désormais soumis à des mesures obligatoires de gestion des risques, des obligations de notification d’incidents (notification sous 24 heures pour les incidents significatifs) et des exigences de sécurité de la chaîne d’approvisionnement. L’article 21 exige spécifiquement « la sécurité dans l’acquisition, le développement et la maintenance des réseaux et systèmes d’information, y compris le traitement et la divulgation des vulnérabilités ».

Pour les déploiements Open RAN, NIS2 signifie que les opérateurs ne peuvent plus se fier uniquement aux certifications des équipementiers. Ils doivent démontrer qu’ils ont validé la sécurité de leur système multi-vendeurs assemblé.

La direction est claire : les régulateurs européens passent de l’évaluation du risque au niveau du fournisseur à la validation sécuritaire au niveau du système. Pour les opérateurs déployant de l’Open RAN, cela implique une vérification indépendante de la chaîne multi-vendeurs assemblée, pas seulement la confiance dans les certifications individuelles.

Là où la sécurité Open RAN se fragilise sur le terrain

Les spécifications de sécurité définissent ce qui devrait se produire. Les tests terrain révèlent ce qui se produit réellement. L’écart entre les deux est l’espace où vivent les vulnérabilités.

Exposition du fronthaul

Le lien fronthaul entre l’O-DU et l’O-RU transporte du trafic eCPRI (enhanced Common Public Radio Interface). Le groupe O-RAN WG4 spécifie le plan fronthaul. Dans certains déploiements, le trafic eCPRI traverse le fronthaul sans chiffrement, en particulier lorsque les équipementiers privilégient la latence à la confidentialité. Un attaquant disposant d’un accès physique ou logique au segment fronthaul peut intercepter des échantillons IQ, injecter des trames radio malformées ou perturber la synchronisation temporelle.

RIC et frontières de confiance des xApps

Le Near-RT RIC exécute des xApps qui prennent des décisions en temps réel sur le comportement du RAN : orientation du trafic, optimisation des handovers, équilibrage de charge. Ces xApps sont souvent du code tiers exécuté avec un accès privilégié aux messages de l’interface E2. Un xApp compromis ou insuffisamment validé peut déclencher des handovers de masse, dégrader le service pour des abonnés spécifiques, ou exfiltrer des données de signalisation via l’interface E2.

O-RAN WG11 définit des exigences de sécurité pour l’intégration des xApps, mais leur application varie selon les implémentations du RIC. C’est sur le terrain que le comportement des xApps s’observe dans des conditions RF réelles, sous charge de trafic réelle et avec des interactions multi-vendeurs réelles.

Lacunes d’intégration multi-vendeurs

Chaque équipementier certifie son composant dans son propre environnement de laboratoire. L’O-RAN Alliance organise des plugfests et des événements de tests d’interopérabilité. Mais personne ne teste systématiquement la chaîne complète assemblée en conditions de production. Cela laisse des lacunes d’intégration qui n’apparaissent que lorsque le système est sollicité par des variables réelles : schémas d’interférences, tempêtes de handovers aux limites de cellules, dérive temporelle sous charge thermique, et interactions inattendues entre xApps.

Les deux approches sont complémentaires, mais les tests terrain détectent la catégorie de problèmes la plus critique pour la sécurité opérationnelle : ceux qui n’émergent que lorsque le système complet fonctionne en conditions non contrôlées.

Tests souverains : pourquoi les opérateurs doivent maîtriser leur validation

Le test souverain repose sur un principe : un opérateur doit pouvoir valider de manière indépendante la sécurité et les performances de son réseau, sans dépendre des résultats de validation fournis par ses équipementiers.

Ce n’est pas une posture philosophique. C’est une nécessité opérationnelle et réglementaire.

Lorsqu’un opérateur se fie exclusivement aux résultats de test fournis par ses fournisseurs, il fait confiance sans vérifier. Chaque équipementier teste son propre composant et rapporte les résultats. Mais aucun fournisseur n’a intérêt à signaler les problèmes qui naissent de l’interaction entre son composant et celui d’un concurrent. L’opérateur se retrouve avec une collection de rapports de tests conformes et un système qui peut encore présenter des vulnérabilités non détectées aux frontières d’intégration.

Les tests terrain indépendants changent cette dynamique. En capturant la signalisation L3 (messages RRC et NAS tels que définis dans les normes 3GPP TS 38.331 et TS 24.501), les KPIs RF et les métriques de qualité vocale sur des sites O-RAN en production, les opérateurs construisent leur propre base de preuves. Les outils de mesure terrain sur smartphone permettent une validation multi-sites rapide sans la logistique de déploiement de scanners dédiés.

L’analyse protocolaire L3 des messages RRC Reconfiguration révèle si les paramètres de configuration cellulaire sont cohérents aux frontières entre équipementiers. Les événements de mesure, les configurations de reporting et les seuils de handover qui diffèrent de manière inattendue entre les cellules du fournisseur A et du fournisseur B sont visibles dans la signalisation décodée, pas dans les tableaux de bord des équipementiers.

Pour les tests 5G NR spécifiquement, la capacité à décoder la signalisation spécifique NR (indices de faisceaux SSB, MeasConfig pour NR, RRC Reconfiguration avec paramètres NR) est essentielle pour valider que la couche 5G d’un déploiement Open RAN se comporte conformément aux spécifications en conditions RF réelles.

L’architecture NG-RAN (3GPP TS 38.401) définit les interfaces et le partage fonctionnel. Les tests terrain valident que l’implémentation effective correspond à l’intention architecturale.

Que vérifier lors de la validation d’un site Open RAN

Une approche de validation structurée pour la sécurité Open RAN requiert cinq phases, chacune produisant des preuves mesurables.

Cinq points concrets à vérifier sur chaque site Open RAN

1. Cohérence des paramètres SIB entre équipementiers. Décoder les System Information Blocks des cellules desservies par différents fournisseurs. Les paramètres tels que cellBarred, intraFreqReselection et sIntraSearchP doivent être cohérents au sein d’une même zone de couverture. Les écarts indiquent un désalignement de configuration pouvant provoquer des resélections inattendues ou un déni de service.

2. RRC Reconfiguration aux frontières inter-vendeurs. Capturer les messages RRC Reconfiguration lors des handovers entre cellules de fournisseurs différents. Vérifier que les paramètres measConfig, measObjectNR et reportConfig sont cohérents. Des configurations de mesure incohérentes provoquent du ping-pong de handover, ce qui constitue à la fois un problème de performance et de sécurité (les rattachements forcés peuvent exposer l’identité de l’abonné).

3. Intégrité de la séquence d’authentification NAS. Lors de l’attachement initial et de la mobilité inter-vendeurs, vérifier que les séquences d’authentification et de commande du mode de sécurité se terminent correctement. Des séquences d’authentification incomplètes ou répétées aux frontières entre fournisseurs peuvent indiquer des bugs d’interopérabilité ou, dans des scénarios adverses, des attaques par rétrogradation.

4. Timing fronthaul eCPRI sous charge. Bien que la mesure directe de l’eCPRI nécessite des sondes spécialisées, les effets de la dérive temporelle du fronthaul sont observables au niveau L3 : retransmissions HARQ accrues, SINR dégradé malgré un RSRP adéquat, et effondrement du débit sous charge. Ces symptômes, corrélés à des combinaisons spécifiques d’équipementiers, pointent vers des problèmes de fronthaul.

5. Schémas de signalisation induits par les xApps. Si le RIC déploie des xApps d’optimisation, surveiller les schémas de signalisation inhabituels : RRC Reconfigurations successives rapides, configurations de measurement gap inattendues, ou commandes de handover contradictoires avec les conditions RF. Ces schémas peuvent indiquer un dysfonctionnement des xApps, qu’il soit dû à des bugs ou à du code compromis.

Conclusion

L’Open RAN tient sa promesse de diversité des équipementiers et de flexibilité architecturale. Mais la désagrégation n’est pas gratuite. Chaque interface ouverte est une frontière de confiance, et chaque point d’intégration multi-vendeurs est un mode de défaillance potentiel qu’aucun fournisseur isolé n’identifiera ni ne signalera.

La Toolbox 5G de l’UE et la directive NIS2 ont établi le cadre réglementaire. Les opérateurs déployant de l’Open RAN en Europe sont désormais tenus de démontrer que leurs systèmes assemblés sont sécurisés, et non pas simplement que chaque composant a passé la certification de son fournisseur.

La capacité de test souveraine est le mécanisme qui rend cela possible. La validation indépendante et terrain de la signalisation L3, des performances RF et de la qualité vocale aux frontières entre équipementiers produit les preuves que ni les rapports des fournisseurs, ni les certifications en laboratoire ne peuvent fournir.

Alors que l’application de NIS2 commence et que les déploiements Open RAN s’étendent à travers l’Europe, quels opérateurs prendront la tête de la validation indépendante, et lesquels ne découvriront leurs lacunes d’intégration que lorsqu’elles seront exploitées ?