Source-linked AI summary
Implementing and Evaluating Security in O-RAN: Interfaces, Intelligence, and Platforms
Joshua Groen, Salvatore DOro, Utku Demir, Leonardo Bonati, Michele Polese, Tommaso Melodia, Kaushik Chowdhury
TL;DR
Open, disaggregated O-RAN interfaces create security vulnerabilities, while existing work has not assessed protection costs. This paper classifies threats across interfaces, intelligence, and platforms and evaluates selected defenses, finding low encryption delay but CPU costs and fewer unexpected ML outputs with autoencoders.
Problem
Open, disaggregated O-RAN interfaces create vulnerabilities, and prior work identifies threats without assessing protection costs.
Source: §I · p. 1, A. New Vulnerabilities · p. 2Method
The paper classifies risks across open interfaces, AI-enabled decision-making, and cloud platforms, proposes mitigations, and reports baseline implementations for interfaces and intelligence.
Source: §VII · p. 7Results
IPsec encryption adds less than 50µs delay but requires more CPU as throughput increases, while autoencoders decrease unexpected scheduling and slicing outputs by 30% and 70%, respectively.
Source: §VII · p. 7Takeaways & Limitations
For cloud deployment, the paper recommends shared responsibility, customer separation, visibility and auditing, and security by design.
Source: §VII · p. 7
Abstract
from arXiv · showhide
The Open Radio Access Network (RAN) is a networking paradigm that builds on top of cloud-based, multi-vendor, open and intelligent architectures to shape the next generation of cellular networks for 5G and beyond. While this new paradigm comes with many advantages in terms of observatibility and reconfigurability of the network, it inevitably expands the threat surface of cellular systems and can potentially expose its components to several cyber attacks, thus making securing O-RAN networks a necessity. In this paper, we explore the security aspects of O-RAN systems by focusing on the specifications and architectures proposed by the O-RAN Alliance. We address the problem of securing O-RAN systems with a holistic perspective, including considerations on the open interfaces used to interconnect the different O-RAN components, on the overall platform, and on the intelligence used to monitor and control the network. For each focus area we identify threats, discuss relevant solutions to address these issues, and demonstrate experimentally how such solutions can effectively defend O-RAN systems against selected cyber attacks. This article is the first work in approaching the security aspect of O-RAN holistically and with experimental evidence obtained on a state-of-the-art programmable O-RAN platform, thus providing unique guideline for researchers in the field.
I. INTRODUCTION
O-RAN’s openness, virtualization, and AI/ML control expand its security exposure, while comprehensive security remains an open challenge. The article examines interfaces, intelligence, and cloud platforms, combining proposed protections with experimental evaluations.
I. INTRODUCTION
- O-RAN’s fine-grained data and control capabilities create exploitable vulnerabilities, but comprehensive security across the architecture remains an open challenge.Cloud-based virtualized functions and third-party AI/ML applications further expand the threat surface.Source: §I · p. 1
- The article identifies open interfaces, AI-native closed-loop control, and cloud-based platforms as three heightened-risk areas and proposes strategies to mitigate their risks.It also empirically evaluates the cost and effectiveness of several measures.Source: §I · p. 1
- The article reports encryption’s effects on E2-interface latency, throughput, and processing load, and evaluates autoencoders against attacks targeting AI applications.It also identifies three cloud-security principles for O-RAN deployments.Source: §I · pp. 1–2
- The paper progresses from O-RAN background to interface security, AI/ML threat mitigation, platform security, and directions for advancing O-RAN security.The interface discussion includes a baseline evaluation of securing interfaces.Source: §I · p. 2
II. O-RAN PRIMER
O-RAN disaggregates RAN functions across software-controlled components and connects them through open interfaces. Near-RT and non-RT RICs use applications operating on different time scales to monitor and control the network.
II. O-RAN PRIMER
- The 3GPP 7.2x split distributes RAN functions among the Central Unit, Distributed Unit, and Radio Unit, which handle different protocol-stack operations.The CU handles RRC, PDCP, and SDAP; the DU handles RLC, MAC, and PHY-high; the RU handles PHY-low and radio transmission.Source: §II · p. 2
- Open standardized interfaces connect the disaggregated components to one another and to the RICs, while APIs enable software control of component functions.Examples include F1 between CU and DU, Open Fronthaul between DU and RU, and E2 and O1 to the RICs.Source: §II · p. 2
- The near-RT RIC runs xApps on 10 ms–1 s time scales, while the non-RT RIC runs rApps above 1 s and exchanges KPIs and control actions with RAN nodes.The A1 interface connects the controllers; xApps receive KPIs through E2 and rApps through O1.Source: §II · p. 2
III. SECURING THE OPEN INTERFACES
Open interfaces create vulnerabilities to interception and injection, while security protections can carry performance and scalability costs. The paper tests adding IPsec to E2 to assess the security–performance trade-off.
A. New Vulnerabilities
- Open interfaces between disaggregated nodes create exposure to missing ciphering or authentication, enabling man-in-the-middle injection of false KPIs or malicious control actions.Threats include false KPI reports sent northbound to the near-RT RIC and malicious actions sent southbound to the gNB.Source: A. New Vulnerabilities · p. 2
- Although interface guidance generally calls for confidentiality, integrity, and authentication, little study has measured security’s impact in O-RAN deployments.Encryption may reduce throughput or require equipment, affecting scalability and CAPEX.Source: A. New Vulnerabilities · p. 2
B. Implementing IPsec on the E2 Interface
- The authors test encryption on E2, the most mature interface, using IPsec to measure the trade-off between security robustness and performance.The test follows the E2 interface description in.Source: B. Implementing IPsec on the E2… · p. 2
- The E2 standards call for IPsec, while other open interfaces use TLS 1.2, with TLS 1.3 recommended; the authors expect general performance trends to extend across protocols.They note that TLS 1.3 establishes a security association fastest, making direct extrapolation from IPsec less certain.Source: B. Implementing IPsec on the E2… · pp. 2–3
- The tested IPsec configuration provides confidentiality, integrity, replay protection, and authentication, adding at least 57 bytes per packet before any further padding.A 62-byte SACK gains 76 bytes, producing a 138-byte ciphertext SACK.Source: B. Implementing IPsec on the E2… · p. 3
C. Theoretical Analysis
Encryption does not affect every source of network delay equally. The analysis focuses on transmission and processing delays because encryption can increase packet size and adds processing work.
C. Theoretical Analysis
- Transmission delay is Dtrans = L/R, so encryption can increase it by increasing packet size L while link rate R remains fixed.The passage identifies packet size in bits and link transmission rate as the formula’s inputs.Source: C. Theoretical Analysis · p. 3
- Queuing and propagation delays are unaffected by encryption, whereas transmission and processing delays can be affected.The analysis therefore focuses on quantifying changes to the latter two delays.Source: C. Theoretical Analysis · p. 3
- For this analysis, processing delay includes encryption delay because the payload must pass to lower or higher OSI layers.The passage also describes processing delay as work at intermediate nodes to examine headers and direct packets.Source: C. Theoretical Analysis · p. 3
D. System Implementation Results
Encryption adds little processing delay to tested E2 traffic, but throughput depends strongly on the encryption implementation and available CPU capacity.
D. System Implementation Results
- Processing-delay difference between CT and PT is ≤50 µs for all tested packet sizes, and encryption has minimal impact on E2 traffic delay.AES256-CCM processing delay increases with packet length, while AES256-GCM has virtually no impact.Source: D. System Implementation Results · p. 3, Figure 2 · p. 3
- Encryption throughput is CPU-limited, with the tested AES256-CCM and SHA256 configuration reaching just under 600 Mbps.CPU utilization grows linearly with attempted transmission rate until saturation.Source: D. System Implementation Results · p. 3, Figure 3 · p. 4
- AES-GCM achieves 1370 Mbps across 64-, 128-, and 256-bit keys, versus 989 Mbps for ChaCha20-Poly1305 and 573 Mbps for AES-CCM at both tested key lengths.AES-CBC achieves 505 Mbps with 128-bit keys and 512 Mbps with 256-bit keys; the paper identifies implementation as the largest factor in maximum throughput.Source: D. System Implementation Results · p. 3, Figure 3 · p. 4
- The authors recommend 256-bit keys because they provide higher security with virtually no performance impact compared with 128-bit keys.The measured throughput showed virtually no difference by AES key size.Source: D. System Implementation Results · pp. 3–4
E. Key to Securing Open Interfaces
Securing open interfaces creates a compute-capacity trade-off, while O-RAN’s AI-driven control applications face vulnerabilities before and after deployment. The section describes practical resource choices alongside data-poisoning, backdoor, and adversarial-input risks.
E. Key to Securing Open Interfaces
- Encryption consumes CPU as open-interface traffic grows; options include more compute, dedicated encryption hardware, or carefully limiting traffic.In the tested system with 10 UEs, reducing E2 updates from every 250 ms to every 333 ms lowered average throughput from 3.5 Mbps to 2.6 Mbps and link utilization by 25%.Source: E. Key to Securing Open Interfaces · p. 4
IV. SECURING THE INTELLIGENCE
- O-RAN’s AI-driven applications face vulnerabilities that can expose rApps, xApps, RICs, and the network to security threats.These applications support functions including slicing, scheduling, traffic steering, mobility management, beamforming, and energy saving.Source: §IV · p. 4
A. Vulnerabilities of AI/ML O-RAN Applications
- Before deployment, data poisoning can bias training data and backdoors can trigger unfair or conflicting xApp/rApp decisions; after deployment, adversarial inputs can mislead inference and network control.Examples include false KPI reports, misclassification of traffic, bypassed anomaly detection, and incorrect handover or resource-allocation decisions.Source: A. Vulnerabilities of AI/ML O-RAN… · p. 4
B. Toward Reliable AI/ML O-RAN Applications
Reliable O-RAN AI applications can be protected through prevention, detection, and response strategies. The section identifies training-time defenses, runtime anomaly detection, and explainability-guided recovery.
Preventing Attacks
- Developers can reduce AI/ML vulnerability through robust-by-design training, including latent-space projection, adversarial or poisoned training data, and attention networks.Examples include autoencoders, contrastive and adversarial learning, contaminated best arm identification, and defensive distillation.Source: B. Toward Reliable AI/ML O-RAN… · pp. 4–5
Detecting Attacks
- Anomaly detection can flag inputs or application decisions that depart from expected distributions, statistical behavior, formats, or patterns.The section describes clustering- and distance-based methods, statistical techniques, and deep neural networks for detecting unexpected features.Source: B. Toward Reliable AI/ML O-RAN… · p. 5
Reacting to Attacks
- After a detected attack, explainable AI can help identify affected applications, triggering inputs, and unexpected outputs, informing model retraining to eliminate vulnerabilities.Source: B. Toward Reliable AI/ML O-RAN… · p. 5
C. Autoencoders for Threat Mitigation
An autoencoder (AE) preprocessing KPIs for a DRL agent reduces the effects of tested adversarial attacks on scheduling and slicing actions. The paper also situates this experiment within the larger threat surface created by virtualized O-RAN platforms.
C. Autoencoders for Threat Mitigation
- The experiment uses an xApp with a PPO-trained DRL agent jointly controlling slicing and scheduling, comparing direct KPI input with AE-based dimensionality reduction and outlier suppression.The black-box attack perturbs legitimate KPI measurements with normally distributed random noise.Source: C. Autoencoders for Threat Mitigation · p. 5
- With AE preprocessing, the attack’s action distance falls by approximately 2× for scheduling and more than 13× for slicing policies.The comparison reports normalized Euclidean distance between intended actions and actions taken after attack.Source: C. Autoencoders for Threat Mitigation · p. 5, Figure 5 · p. 6
- Across 200 independent runs, AE preprocessing yields fewer action deviations than direct KPI input, even at high noise variance; without an AE, deviations exceed 95%.Scheduling is the most affected action, deviating 70% of the time, compared with 30% for slicing.Source: C. Autoencoders for Threat Mitigation · p. 5, Figure 4 · p. 5
V. SECURING THE PLATFORMS
- Virtualized, cloud-based network functions improve agility and flexibility but enlarge O-RAN’s threat surface.Source: §V · p. 6
A. Cloud Security Risks
O-RAN cloud deployments inherit the trust and isolation risks of shared virtualized infrastructure while adding multi-vendor governance challenges. The paper recommends cloud-security practices tailored to O-RAN, including customer separation, auditing, and security by design.
A. Cloud Security Risks
- Trust in an application depends on trusting every layer beneath it, while shared hardware provides only logical isolation between software instances.Host operating systems can access VM memory and disks, and hypervisors mediate hardware security functions.Source: A. Cloud Security Risks · p. 6
B. O-RAN Specific Security Recommendations
- O-RAN’s multiple vendors complicate supply-chain, administration, and personnel security, while external gateways between every component are infeasible on CAPEX and OPEX grounds.Governance, visibility, and auditing could mitigate some of these challenges.Source: B. O-RAN Specific Security… · p. 6
- Customer separation requires both cloud providers to secure the hypervisor or host OS and developers to prevent functions such as xApps from leaking customer information.Source: B. O-RAN Specific Security… · p. 6
- Visibility and auditing should trace component actions and responsibilities; RIC logs of xApp and rApp control messages are one proposed mechanism.Source: B. O-RAN Specific Security… · p. 6
- Security by design should span every O-RAN layer, though performance constraints at lower layers such as the RU and DU create trade-offs.Starting with security objectives for each block lets researchers optimize solutions before deployment and an attack.Source: B. O-RAN Specific Security… · pp. 6–7
VI. ADVANCING THE SECURITY FRAMEWORK
The paper identifies Open Fronthaul security and Zero Trust Architecture as priorities for further O-RAN security work. It highlights low-latency plane-specific protection needs and proposes using O-RAN’s AI/ML capabilities for dynamic risk assessment and continuous trust evaluation.
VI. ADVANCING THE SECURITY FRAMEWORK
- Achieving completely secure O-RAN deployments requires further research, particularly on Open Fronthaul and Zero Trust Architecture.Source: §VI · p. 7
- Open Fronthaul security remains an open problem because its planes require low latency while needing different protections.The synchronization plane needs authentication and integrity, but not confidentiality; man-in-the-middle attacks on timing messages could degrade or disrupt service.Source: §VI · p. 7
- Zero Trust Architecture fits O-RAN’s multi-entity setting, with dynamic risk assessment and continuous trust evaluation identified as key elements.The paper suggests leveraging O-RAN’s AI/ML integration and developing xApps and rApps for real-time monitoring and risk assessment.Source: §VI · p. 7
VII. CONCLUSIONS
The paper offers a holistic O-RAN security guideline spanning open interfaces, intelligence, and cloud platforms, with baseline implementation results for selected protections. Its experiments report under 50µs added delay for E2 IPsec encryption and reduced unexpected scheduling and slicing outputs with an autoencoder.
VII. CONCLUSIONS
- The paper classifies O-RAN security targets as open interfaces, data-driven intelligence, and cloud platforms, and gives threats, mitigations, and baseline implementation results for interfaces and intelligence.Source: §VII · p. 7
- The E2-interface IPsec encryption added less than 50µs delay, while increasing throughput required higher CPU and CPU utilization was the key encryption cost in the tested environment.Source: §VII · p. 7
- An autoencoder before the DRL model reduced unexpected ML outputs by 30% for scheduling and 70% for slicing in the reported experiments.Source: §VII · p. 7
- For O-RAN cloud deployments, the paper recommends shared responsibility, with providers securing the service and users securing data, alongside customer separation, visibility and auditing, and security by design.A Cloud Workload Protection Platform is given as an example of realizing the shared-responsibility model.Source: §VII · p. 7