Cryptographic Bill of Materials (CBOM) for an Open RAN-Based Telecom RAN

Introduction

Based on anonymized results of a project (and with permission), I will try to illustrate key parts of a comprehensive Cryptographic Bill of Materials (CBOM) for a telecom Radio Access Network (RAN) implementation based on the Open RAN architecture. I enumerate all cryptographic mechanisms across the control plane, user plane, management interfaces, and orchestration layers of the RAN. Both standardized algorithms (e.g. 3GPP-defined ciphers like SNOW 3G, AES, ZUC) and any vendor-specific/proprietary mechanisms are included, with an emphasis on an EU deployment scenario.

In the European context, strong encryption and security-by-design are mandated; for example, ENISA (the EU cybersecurity agency) recommends using non-null ciphers for all user and signaling data and state-of-the-art protocols with mutual authentication on RAN interfaces.

We break down the CBOM by major architectural components – Radio Unit (O-RU), Distributed Unit (O-DU), Central Unit (O-CU), RAN Intelligent Controller (RIC), and Service Management & Orchestration (SMO) – detailing cryptographic primitives used for key functions: authentication, encryption, key agreement/management, secure boot & supply chain integrity, and protocol-specific security.

EU-specific standards and regulations (such as 3GPP security specs, O-RAN Alliance security requirements, ENISA guidelines, and GDPR-compliant practices) are cited to contextualize the choices.

Open RAN Architecture Overview

Open RAN disaggregates the traditional RAN into open, interoperable components. Key components include the O-RU, O-DU, O-CU (often split into O-CU-Control Plane and O-CU-User Plane), and RIC, all managed by the Service Management and Orchestration (SMO) framework. These elements communicate via defined interfaces: the Open Fronthaul (O-RU ↔ O-DU), F1 (O-DU ↔ O-CU), E2 (near-RT RIC ↔ O-CU/O-DU), A1 (non-RT RIC in SMO ↔ near-RT RIC), O1 (SMO ↔ all O-RAN nodes for management), and O2 (SMO ↔ O-Cloud). Each interface and component brings specific security requirements. The CBOM below enumerates the cryptographic algorithms and protocols that secure:

• Authentication: How components verify identities (e.g. SIM-based subscriber authentication, mutual TLS between nodes, SSH for admin access).
• Encryption & Integrity: Protection of data in transit (air interface, fronthaul/midhaul/backhaul links, management traffic) and at rest, using ciphers like AES, SNOW 3G, ZUC, etc.
• Key Agreement & Management: Mechanisms for exchanging or deriving keys (Diffie-Hellman/ECDH handshakes, PKI certificate systems, 5G key derivation functions) and managing key lifecycles.
• Secure Boot & Supply Chain: Ensuring hardware/software integrity via cryptographic signatures on firmware, secure boot loaders, and software bill-of-materials verification.
• Protocol-Specific Crypto: The use of protocols like IPsec, TLS, HTTPS, SSH, and 5G-specific NAS/AS security, including algorithm profiles and modes of operation.

Throughout, we note algorithm parameters (key lengths, modes), known classical vulnerabilities, and anticipated quantum vulnerabilities. In line with EU guidelines, the chosen algorithms generally adhere to strong security margins (e.g. avoiding deprecated algorithms and preparing for post-quantum security). The subsections below detail each component’s CBOM entries.

Radio Unit (O-RU)

Role: The O-RU is the radio head at cell sites, handling the analog/digital RF processing and Low-PHY layer. It interfaces with the O-DU over the open fronthaul (usually an eCPRI-based protocol over ethernet/IP). Security in the RU focuses on protecting the fronthaul link, authenticating the RU to the network, and ensuring the RU’s software integrity, despite the RU’s limited computing scope (no user-plane encryption occurs here, as that is handled at higher layers).

• Device Authentication & Identity: The O-RU is typically authenticated in the network via a certificate-based mechanism. Each RU can be provisioned with a unique X.509 certificate (often an IEEE 802.1AR IDevID or operator-issued credential). During network attach, the RU may perform 802.1X EAP-TLS at the Ethernet layer to prove its identity to the O-DU, using its certificate for mutual TLS authentication. This ensures only authorized RUs can connect. The certificate algorithms are usually RSA-2048/3072 or ECDSA (256-bit prime curve) for digital signatures. Classical security of RSA/ECDSA is strong with sufficient key lengths, but they are quantum-vulnerable (Shor’s algorithm could break them if a large quantum computer emerges). Thus, EU operators often require robust PKI and plan for future quantum-safe credentials in the long term. The O-RAN Alliance Security specs mandate mutual authentication on the fronthaul M-plane (management plane), using PKI (public key infrastructure) certificates. According to ENISA, operators must establish a PKI infrastructure for secure device authentication and admin access in 5G, with as much automation as possible for certificate management.
• Fronthaul Link Encryption (C/U-Planes): The O-RU ↔ O-DU fronthaul carries user plane (I/Q samples or frequency-domain data), control plane (C-Plane configuration of the PHY), management (M-Plane), and synchronization (S-Plane) data, often over Ethernet/IP. Early Open RAN deployments did not always encrypt this link, but current best practice is to provide confidentiality and integrity protection on the fronthaul, given its critical data. Two main options are used:
  • IPsec (Layer 3 encryption): IPsec in tunnel mode (with ESP) can secure IP-based fronthaul traffic. Typically, IKEv2 with certificate-based mutual authentication is used to establish IPsec SAs (Security Associations) between the O-RU and O-DU. The cryptographic suite for IPsec in RAN uses modern ciphers like AES-128-GCM or AES-256-GCM (Galois/Counter Mode provides combined encryption and integrity). 3GPP requires that gNBs (which include DU/RU functionality) support IPsec with ESP and IKEv2 on such internal interfaces (F1, Xn, etc.), even if its use is left to operator decision. In EU deployments, using IPsec on fronthaul/midhaul is often considered mandatory for compliance with security policies (unless the link is entirely within a physically secure site). AES-128-GCM with a 128-bit key has no known practical attacks and is NIST-approved; however, to mitigate future quantum threats (Grover’s algorithm can effectively halve the key length security), AES-256 is recommended for long-term confidentiality. Perfect forward secrecy is provided via ephemeral Diffie-Hellman (often ECDH P-256 or X25519) during IKEv2, so even if long-term keys (certificates) are compromised, past session keys remain safe. Classical vulnerabilities are minimal (AES-GCM is robust if used with unique nonces; IKEv2 is secure when configured properly), but misconfiguration (e.g., reusing nonces or weak Diffie-Hellman groups) must be avoided.
  • MACsec (Layer 2 encryption): Because fronthaul can be an Ethernet-based eCPRI transport, IEEE 802.1AE MACsec is an attractive option to meet strict latency requirements. MACsec operates at the data-link layer, encrypting Ethernet frames with negligible overhead and hardware-offload support. In a MACsec-protected fronthaul, the RU and DU form a trusted group (a Connectivity Association); a secure 802.1X handshake yields a Connectivity Association Key (CAK) which in turn produces session keys (SAKs) for frame encryption. MACsec uses AES-GCM as well (commonly 128-bit keys, though 256-bit is available), providing confidentiality and frame integrity in one algorithm. Each frame carries an incrementing packet number to prevent replay attacks. This setup authenticates the O-RU and O-DU at the hardware port level and encrypts all C-Plane, U-Plane, M-Plane traffic on the fronthaul. Known vulnerabilities: MACsec is considered strong; its GCM mode inherits AES’s security (thus similarly quantum-vulnerable for the long term if 128-bit keys are used). The main challenge is ensuring timing/latency for synchronization traffic (PTP) is handled, which vendors have addressed by adjusting timestamping to work with encryption. The O-RAN Alliance Security spec now allows optional MACsec on fronthaul, and work is underway to mandate 802.1X support for link authentication, which is especially relevant in EU operator deployments focused on zero-trust principles.

Note: On the fronthaul user plane (U-Plane), there is an additional layer of protection from 5G’s inherent encryption at the PDCP layer in the O-CU. The O-RAN security analyses acknowledge that PDCP security (in the O-CU) protects the content of user-plane traffic between the UE and gNB, even if the RU-DU link were intercepted. However, this does not protect lower-layer control or sync messages, so fronthaul encryption (IPsec/MACsec) is still critical for full security (and to hide user traffic metadata like radio headers).

• Management & OAM Interfaces: An O-RU usually has a management interface (the O1 interface in O-RAN) for configuration, performance management, and software updates. This typically runs over IP and is secured with protocols like NETCONF over TLS or NETCONF over SSH. O-RAN Alliance’s Security Protocol specifications list SSH and TLS as approved protocols for management. In practice, many implementations use TLS 1.2/1.3 with mutual authentication for O1. For example, the SMO (or other manager) and O-RU exchange certificates and establish a TLS connection for NETCONF (or REST) API calls. TLS 1.3 is preferred (and mandated by O-RAN) due to its improved security and performance. The cryptographic primitives here include ECDHE key exchange (often X25519 or secp256r1), RSA or ECDSA for certificate signatures, and AES-128-GCM (or ChaCha20-Poly1305) for encryption, ensuring confidentiality and integrity of management commands. Classical vulnerabilities are mitigated by disallowing older TLS versions and weak ciphers; 3GPP and O-RAN profiles forbid TLS 1.1 and insecure suites. From a quantum perspective, TLS’s use of ECDHE and RSA/ECDSA is not quantum-safe, meaning a future quantum adversary could break the handshake and certificates. Although this is a long-term concern, the architecture is being designed to swap in quantum-resistant algorithms once standardized (e.g., post-quantum TLS handshakes). Additionally, direct admin access to RU (e.g. an engineer SSHing into the RU’s OS) is secured with SSH v2. That uses primitives like ECDH key exchange, Ed25519 or RSA-2048 host keys, and symmetric ciphers (AES or ChaCha20). O-RAN specs include SSH as a supported secure management protocol. Good practices in EU networks include enforcing strong SSH key policies and disabling password-auth if possible.

• Secure Boot & Firmware Integrity: RUs, often deployed in potentially accessible locations (cell towers), must ensure their software and firmware haven’t been tampered with. Secure Boot is implemented: the RU’s bootloader verifies digital signatures on the firmware image before execution. Commonly, RUs use an embedded hardware root-of-trust (e.g., a TPM or secure element) that stores a vendor’s public key. The firmware is signed by the vendor using RSA-2048/3072 or ECDSA-256/384; upon boot, the RU computes a signature check (RSA signature verify or ECDSA verify) on the code using the stored trusted key. If the signature (often SHA-256 hashed and then signed) is invalid, the device will refuse to run untrusted code. This mechanism uses standard cryptographic primitives (SHA-256 hashing, RSA/ECDSA verification). Classical vulnerabilities include any weakness in the hash or signature algorithm: SHA-256 and ECDSA-256 are currently strong, with no feasible collisions or signature forgeries known. RSA-2048 is also secure against classical attacks (assuming proper padding like PSS). The primary risk is private key compromise or supply-chain insertion of a signed malicious firmware (which robust operational security and code-signing policies must prevent). From a quantum standpoint, secure boot signatures based on RSA/ECC will eventually need upgrades – quantum computers could forge those signatures if algorithms remain the same in a decade or more. The O-RAN Alliance’s security requirements call for trustworthy supply chain measures including signed software updates and SBOM (Software Bill of Materials) transparency. In EU deployments, guidelines from bodies like GSMA NESAS and EU 5G Toolbox require that network equipment undergo secure development and that software binaries include integrity protections. Firmware update packages are typically encrypted or at least signed; cryptographically, this might involve not only signatures but also encryption for confidentiality (e.g., firmware encrypted under keys only known to the operator and device, mitigating an adversary learning the firmware internals). The SBOM concept means listing all cryptographic components and third-party libraries in the RU software – for instance, if OpenSSL is used in the RU for TLS, that would appear in the CBOM, with version info to track vulnerabilities.

• Cryptographic Algorithms Summary (O-RU): To summarize the O-RU’s CBOM entries, the RU leverages a variety of algorithms:
  • Symmetric Ciphers: AES-128/256 (for IPsec, TLS, MACsec), SNOW 3G or ZUC (not directly in RU, but worth noting for context, these run in O-CU for air interface encryption), and possibly ChaCha20 in TLS/SSH as an alternative cipher.
  • Asymmetric Crypto: RSA-2048/3072 and ECDSA/ECDH (256-bit curve like P-256, curve25519) for authentication and key exchanges.
  • Hashes / MAC: SHA-256 (cert signatures, HMAC in IKE, etc.), and AES-GCM provides built-in MAC (GMAC). Also, HMAC-SHA-256 might be used in certain key derivations or older TLS if 1.2 with HMAC.
  • All these are standard algorithms (NIST or ETSI approved) with well-understood security. There are no known classical vulnerabilities when they are used as specified (e.g., AES-GCM and SHA-256 are still unbroken). One must avoid deprecated options (no SHA-1, no RC4, etc., per modern profiles). Quantum vulnerabilities center on RSA/ECDH/ECDSA as noted – anticipated EU regulations and 3GPP Release 18+ work items are exploring quantum-resistant algorithms to replace those in the future.

Distributed Unit (O-DU)

Role: The O-DU handles the higher PHY layer, MAC and RLC functions of the RAN protocol stack. It is typically located at an edge site or aggregation point and connects upward to the O-CU over the F1 interface, while interfacing downward to multiple O-RUs over the open fronthaul. The O-DU may also interact with a near-Real-Time RIC via the E2 interface. Security considerations for the O-DU include midhaul link protection (F1), RIC interface protection (E2), management and OAM security, and its own secure boot and integrity. Note that user-plane encryption terminates at the O-CU (PDCP layer), not at the O-DU; hence the O-DU primarily forwards already-encrypted user traffic, but it still handles plaintext control messages between RU and itself, and between itself and CU.

• Authentication and Trust Relationships: The O-DU must mutually authenticate with its peer components:
  • To the O-RU: As mentioned, the RU and DU typically use link-layer or network-layer authentication (802.1X or IKEv2) to establish trust. From the O-DU side, this involves validating the O-RU’s certificate or credentials. The O-DU thus contains a trust store of the operator’s CA certificates (to verify RU certs) and its own private key and certificate to present to RUs. These credentials are usually provisioned by the operator’s PKI. The cryptography is the same as described for the O-RU: RSA/ECDSA for certs, and the handshake either in EAP-TLS or IKE uses ECDH. No special vulnerabilities beyond those already noted (the DU should be hardened to store its private keys securely, e.g., in a secure module or encrypted form, to prevent compromise).
  • To the O-CU: The F1 interface (between O-DU and O-CU) similarly requires mutual authentication if IPsec or TLS is used. In many deployments, the O-DU and O-CU may be within the same trust domain (e.g., both in operator-controlled data centers), but open interfaces mean they could be multi-vendor, so authentication is critical to prevent impersonation. IPsec with IKEv2 is commonly the method (as 3GPP mandates IPsec support on F1-C and F1-U). The O-DU will authenticate the O-CU’s certificate during IKEv2 and vice versa. Certificates here might be issued by the operator’s internal CA (distinct from those for RU, or possibly the same CA with different scopes). Alternatively, if the F1 runs over a private network, some operators might opt for lower-layer protection (e.g., if DUs and CUs are co-located, they might consider the link secure, but the trend is to use cryptographic auth regardless, aligning with zero-trust).
  • To the near-RT RIC: The E2 interface connects the O-DU (and O-CU) to the near-real-time RIC for control and optimization messages. O-RAN security specs call for mutual authentication on E2, likely via certificates and IPsec or TLS as well. In practice, this means the O-DU will have credentials to establish a secure session with the RIC (see RIC section for details). The authentication primitives are the same (X.509 certs, ECDH/RSA etc.). Classical security of these mutual auth protocols is maintained by using strong cipher suites and proper certificate validation.

• Midhaul Encryption & Integrity (F1 Interface): The F1 interface between O-DU and O-CU has two planes: F1-C (control plane, carrying signaling like RRC messages between DU and CU) and F1-U (user plane, carrying user data packets after PDCP). While user data on F1-U may already be ciphered at the PDCP layer, the F1-U packets still reveal network information (headers, PDCP PDUs) and could be manipulated if not protected. The F1-C carries unencrypted control messages (since RRC is terminated at the O-CU, the DU sees plain instructions for scheduling, etc.), which are highly sensitive. Therefore, securing F1 is vital. 3GPP TS 33.501 specifies that both F1-C and F1-U shall support IPsec ESP with IKEv2 (and even suggests DTLS as an option for certain cases). In an open deployment, the O-DU and O-CU establish an IPsec tunnel (or a pair of tunnels for C and U planes) at startup.
  • Algorithms: Typically, the IPsec SA for F1 will use similar algorithms as described earlier (AES-GCM-256 is a common choice in EU deployments for a high security margin). IKEv2 key exchange might use ECDH (Curve25519 or secp384r1, etc.) for PFS, and certificates (RSA or ECDSA) for authentication. Integrity, confidentiality, and replay protection are provided by AES-GCM’s integrated mechanism (and sequence numbers in ESP). If DTLS were used (datagram TLS over UDP, which could be an alternative for F1-C if using UDP transport), it would similarly rely on AES-GCM or ChaCha20-Poly1305 and requires mutual cert auth. However, IPsec is more common and has the benefit of potentially hiding traffic patterns (tunnel mode hides inner IP headers – useful if the operator wants to conceal internal topology).
  • Classical Vulnerabilities: As long as strong algorithms are used and keys are of adequate length (128-bit symmetric minimum, ideally 256-bit for long-term), F1 security is strong. Improper configuration (e.g. failing to enable encryption, or using static pre-shared keys instead of certificates) would be a vulnerability. EU guidance explicitly says to “use secure protocol on network for both user and control plane data on RAN interfaces” and not to rely on any null ciphering – this implies IPsec/TLS should be turned on for F1 in EU networks.
  • Quantum Considerations: Same as earlier – symmetric encryption is quantum-resistant to a large extent (with a reduction in effective security proportional to key length), whereas the RSA/ECDH parts of IKEv2 are not. Future updates may replace those with post-quantum key exchanges (there is active work in IETF on PQC for IKEv2).

• RIC Interface Security (E2): The O-DU connects to the near-RT RIC via the E2 interface, which carries near-real-time control information (e.g., radio resource management directives, policy enforcement, and telemetry). This interface could be a vector for attacks if not secured, as a malicious RIC could send bogus control commands, or an intruder could sniff sensitive data. The O-RAN Alliance recommends protecting E2 with similar techniques (IPsec or TLS) as other interfaces. A common approach is IPsec with certificates between the RIC and each O-DU/O-CU. Because E2 messages might use SCTP or another transport, IPsec at layer 3 is a convenient universal solution. In practice, the O-DU will establish an IPsec tunnel to the RIC’s endpoint, using the same cryptographic profile (IKEv2 with Diffie-Hellman, AES-GCM, etc.). Optional alternatives could be TLS if E2 is carried over TCP, but IPsec is generally favored for its transparency and performance. Known vulnerabilities would be similar: without encryption, an E2 link could be a man-in-the-middle target or subject to impersonation; with encryption and auth, these risks are mitigated. Ensuring RIC’s identity via cert prevents a rogue RIC from hijacking control. Performance is a factor (the RIC may be handling many DUs), so hardware crypto acceleration is typically used.

• OAM & Management (O1 interface): The O-DU, like the O-RU, has an O1 management interface for the SMO to configure and monitor it. This O1 interface is often implemented via NETCONF/YANG models in O-RAN. Security for O1 on the O-DU uses TLS 1.3 with client/server certificates (or NETCONF/SSH in some cases). The SMO (as a client) will authenticate the O-DU’s server certificate, and the O-DU may also verify the SMO’s certificate (mutual auth). The algorithms are the same as described earlier: ECDHE for key exchange, AES for encryption. The O-DU’s CBOM thus includes the cryptographic library or module supporting TLS (e.g., an OpenSSL or WolfSSL library built into the O-DU’s software, with FIPS-140 certification in many cases for compliance). All sensitive management transactions (configuration changes, retrieval of performance data, etc.) are encrypted. ENISA’s guidance for EU networks is to ensure usage of “current security protocols for TLS” and proper certificate management – which translates to using TLS 1.3 and avoiding any outdated cipher.

• Secure Boot & Software Integrity: Distributed Units are often software workloads running on generic compute (they can be containerized or VM-based, or on bare-metal). Secure boot at the hardware level (UEFI Secure Boot, Trusted Platform Module attestation, etc.) is typically employed on the servers hosting the O-DU (the O-Cloud infrastructure – see later section – provides trusted compute). The O-DU software images (VNFs or CNFs) are signed by the vendor or operator. Cryptographically, this involves code signing (often an RSA-2048 or ECDSA-256 signature on the image). The orchestration system or the O-Cloud will verify these signatures before instantiation. Additionally, runtime attestation might be used: the O-DU can perform a cryptographic attestation (TPM quotes of measurements) to prove to the SMO or to a security server that it is running the expected software (involves hash algorithms like SHA-256 and RSA/ECC signatures on attestation data). These measures align with EU supply-chain integrity requirements – e.g., German BSI’s recommendations for Open RAN include ensuring that all components run authentic, untampered software. As part of a CBOM, the O-DU’s vendor would list the cryptographic mechanisms for boot and update (e.g., “Secure Boot with RSA-3072 signature (SHA-256 hash, PSS padding)”, “Kernel module signing with ECDSA-256”, etc.). Classical security of these is high; they largely depend on the secrecy of private signing keys. If any algorithm is weak (say, if SHA-1 were used, which it should not be anymore), that would be a vulnerability – but modern implementations use SHA-256/384 and strong signatures. For quantum, as noted, RSA/ECDSA will need eventual replacement, but an interim mitigation is to use larger keys (RSA-3072+ or ECDSA-384) to increase the quantum attack workload and allow time for PQC migration.

In summary, the O-DU uses a very similar set of cryptographic primitives as the O-RU and additional ones for its interfaces: AES-GCM, HMAC-SHA-256 (in IPsec/IKE), ECDH (P-256/X25519), RSA/ECDSA certificates, etc., plus SNOW 3G/AES/ZUC indirectly as part of the overall RAN encryption (even if the O-DU doesn’t execute PDCP, it handles the encrypted traffic). The DU’s security heavily leans on IETF-defined protocols (IPsec, TLS, SSH), and 3GPP/O-RAN profiles requiring up-to-date algorithm choices. EU deployments typically enforce these and avoid any optional “no encryption” modes that earlier networks sometimes allowed.

Central Unit (O-CU)

Role: The O-CU is the higher-layer RAN node, split into Control Plane (O-CU-CP) and User Plane (O-CU-UP) in an Open RAN architecture. It runs the Packet Data Convergence Protocol (PDCP), Radio Resource Control (RRC) for control plane, and SDAP (Service Data Adaptation Protocol) for QoS mapping. The O-CU interfaces with the O-DU (over F1), with the 5G Core network (NG interfaces: N2 for control, N3 for user plane), and with the near-RT RIC (E2). It is typically deployed in more centralized locations (edge or regional data centers) and can be virtualized. The O-CU is where 3GPP-defined cryptographic mechanisms for over-the-air security reside – making it a critical component in the CBOM for user and control plane cryptography.

• 5G Subscriber Authentication (SIM-Based AKA): While the primary 5G Authentication & Key Agreement (AKA) procedure is between the UE (SIM/USIM) and the 5G Core (AUSF & ARPF), the O-CU plays a supporting role in establishing security. When a UE attaches, the O-CU (specifically the O-CU-CP) communicates with the AMF (core) to run AKA. Cryptographically, AKA uses symmetric key algorithms in the SIM and core:
  • MILENAGE algorithm: the de-facto standard AKA algorithm set based on AES-128. The USIM and home subscriber system share a 128-bit secret key (K). Using MILENAGE (AES with specific constant inputs), they compute an authentication response, session keys, etc. MILENAGE’s functions (f1, f2, f3, f4, f5) produce a MAC (for authentication), expected response (XRES), cipher key (CK) and integrity key (IK). No classical attacks are known on MILENAGE aside from side-channel attacks on SIM cards; it effectively inherits AES-128’s strength, so the main consideration is that AES-128 provides ~128-bit security (quantum Grover’s search could reduce this, but 128-bit is still considered secure for the near future).
  • TUAK algorithm: an alternative AKA algorithm based on the Keccak hash (which underlies SHA-3). TUAK was developed to diversify away from purely AES-based MILENAGE. It’s recommended by GSMA to have USIMs support both MILENAGE and TUAK for future-proofing. TUAK uses a 256-bit key and relies on the AES finalist Keccak, giving it a very high security margin (and some inherent resistance against quantum since it’s not an algebraic structure like AES – though large quantum computers could still brute force if keys are not sufficiently large).
  • The O-CU itself does not execute these algorithms, but it receives from the core the derived keys and information (e.g., it gets security policy from the AMF). Specifically, after AKA, the core derives K_AMF and then a K_gNB (via a key derivation function) which is delivered to the gNB (the combined DU/CU) over NGAP signaling. Key derivation uses cryptographic KDF functions specified by 3GPP – typically based on HMAC-SHA-256. For example, K_gNB = HKDF(K_SEAF, “kgNB”, etc.) as per TS 33.501. These KDFs are designed with no known collisions and ensure one-way derivation.
  • The CBOM entry here would list AES-128 (MILENAGE) and/or TUAK (Keccak-based) as cryptographic primitives for authentication, with context “SIM-based AKA algorithm in UE and core”. The O-CU’s involvement is to store or handle the resulting keys (like K_gNB) and ensure they are used correctly for encryption. There are no direct vulnerabilities in MILENAGE known, but older algorithms (e.g., COMP128 used in 2G) had weaknesses – those are not used in 5G. EU operators have largely standardized on MILENAGE and will be introducing TUAK or even a 256-bit MILENAGE variant in coming years for enhanced security. Also, to protect user identity, 5G introduced the Subscription Concealed Identifier (SUCI): the UE encrypts its IMSI using the home network’s public key (which could be an RSA or ECC public key) before sending to the network. The algorithm for SUCI encryption is often ECIES (Elliptic Curve Integrated Encryption Scheme) using EC public keys, as defined in 3GPP. This means the O-CU/AMF only sees an encrypted identifier and must forward it for de-concealment by the home network. The SUCI design was made flexible to allow very long public keys or even quantum-resistant schemes in the future. Currently, SUCI’s RSA/ECC encryption is quantum-susceptible (like any public-key encryption), but 3GPP explicitly allowed large key sizes to accommodate PQC in future.

• Air-Interface Encryption (User Plane): The O-CU-UP is responsible for user-plane encryption over the Uu interface (air link) between the gNB and the UE. After authentication and key setup, the UE and gNB share cipher keys and integrity keys. The PDCP layer in the O-CU applies encryption to all user data packets and RRC signaling (below NAS) using one of the standardized algorithms:
  • 128-NEA1: A 128-bit key cipher based on SNOW 3G. SNOW 3G is a stream cipher developed by ETSI/SAGE, used originally in 3G and LTE (as UEA2 algorithm). It generates keystream which is XORed with plaintext. NEA1 is largely for backward compatibility and as an optional algorithm – it’s efficient in hardware and has no known cryptanalytic breaks. However, it’s not as software-friendly and is slower compared to newer ciphers. Key length is 128 bits, and SNOW 3G has an internal state size of 384 bits. Classical security: no practical attacks; it was designed to replace earlier broken ciphers (A5, etc.). It remains secure, but its performance might not meet future needs. Quantum security: a 128-bit symmetric key is theoretically reduced to 64-bit strength by Grover’s algorithm, which is still non-trivial to break. Nonetheless, for critical infrastructure, EU agencies suggest moving to 256-bit keys in the long term.
  • 128-NEA2: A 128-bit key cipher based on AES-128 in Counter Mode (AES-CTR). NEA2 uses the AES block cipher to generate keystream blocks (CTR mode) for encryption. AES is widely trusted; NEA2 is often the default choice for many operators. It leverages AES hardware acceleration available in CPUs. Key length 128 bits (with a block size of 128, and a random IV per bearer). No known weaknesses in AES-CTR aside from requiring a unique IV per encryption to avoid two-time pad issues. AES’s classical robustness is excellent, and only side-channel attacks are a consideration (hence in implementations, constant-time operations are used). Quantum-wise, AES-128 is somewhat threatened (to an attacker with a quantum computer, brute force is 2¹²⁸ -> 2⁶⁴ steps, which is still extremely high; AES-256 would go to 2¹²⁸ which is essentially unbreakable in practice). There is active work on introducing 256-bit versions of these algorithms in 5G (referred to as NEA4/NIA4 in proposals) to align with evolving security needs.
  • 128-NEA3: A 128-bit key cipher based on the ZUC stream cipher. ZUC (named after Zu Chongzhi) is a stream cipher standardized by 3GPP for LTE and 5G, and mandated by Chinese regulators for use in China’s networks. It’s an LFSR-based cipher with a 128-bit key and 128-bit IV. NEA3 is typically optional elsewhere. Security of ZUC: it had some initial statistical weaknesses which were fixed in version 2; currently, no efficient attacks are known. It’s considered secure and slightly faster in software than SNOW 3G. ZUC’s integrity variant and cipher are also used in some 4G/5G implementations to have diversity. Classical and quantum considerations are similar to SNOW 3G (both are stream ciphers with 128-bit keys).
  • Null cipher (NEA0): It’s worth noting 3GPP defines NEA0 (no encryption) for testing. In real deployments (especially under EU law and GDPR), using NEA0 is not permitted for actual subscriber traffic. It exists for debug or emergency use only. The CBOM for a production system would highlight that NEA0 is disabled (ensuring compliance with “encrypt UE data by default” guidance).

The O-CU’s CBOM should list all implemented algorithms. Most gNBs support at least 128-NEA1, NEA2, NEA3 (to ensure interoperability and a backup cipher as per 3GPP policy of having multiple algorithms). In an EU deployment, AES-based (NEA2) is commonly chosen by the core network as the active cipher, with ZUC or SNOW as fallback. The algorithm negotiation happens during the Security Mode Command procedure: the UE sends supported algorithms and the network picks one (never null in normal operation). Known vulnerabilities: none on the ciphers themselves, but one must ensure the implementation is correct (e.g., the keystream should never repeat under the same key and count – PDCP count serves as IV to ensure that). Also, user-plane integrity protection is an optional feature in 5G (different from encryption) that some operators might enable for sensitive scenarios; if integrity is off, an attacker with the ability to inject packets between O-CU and O-DU might alter user-plane packets (though encryption makes it hard to craft valid ones). So integrity for user plane (see next bullet) can be a consideration.

• Air-Interface Integrity Protection (Control Plane, and optionally User Plane): In addition to encryption, 5G uses integrity algorithms (NIA1, NIA2, NIA3 corresponding to the above ciphers) to protect signaling, and optionally user data, from tampering. The O-CU-CP applies integrity protection to RRC messages; the UE and gNB each verify message MACs. The algorithms:
  • 128-NIA1: based on SNOW 3G integrity algorithm (UIA2 in 3G). It computes a 32-bit Message Authentication Code (MAC) using SNOW 3G in a particular mode.
  • 128-NIA2: based on AES-128 CMAC (Cipher-based MAC). AES-CMAC produces a 32-bit MAC. This is a strong integrity check (AES-CMAC is secure if keys are not reused across different contexts; 3GPP has defined usage to avoid that).
  • 128-NIA3: based on ZUC’s integrity mode. Also produces 32-bit tag.

All three integrity algorithms use a 128-bit integrity key (separate from the cipher key) and produce a truncated MAC (typically 32 bits for RRC, which is a balance between security and overhead). A 32-bit tag means a brute force injection has a 1 in 2³² chance of being accepted – which is about 1 in 4 billion. This is considered acceptable for control-plane protection given the limited time/attempts an attacker would have (and if anything fails integrity check, the connection is dropped or rekeyed). There are no known analytical attacks on these MAC algorithms; the main consideration is the tag length (32 bits may not be sufficient if we worry about an adversary injecting a high volume of messages – but 3GPP chose it to minimize overhead, and it’s similar to LTE’s design). Classical security of 32-bit CMAC/SNOW MAC is okay for short-term, but some argue for 64-bit tags in future. Indeed, 3GPP is looking to mandate at least 64-bit MACs for future releases as networks become more critical. Quantum-wise, breaking a 128-bit key in CMAC is similar to breaking AES (Grover reduces effort, but still huge), and forging a 32-bit tag by brute force remains 2³² attempts (quantum doesn’t help much there except Grover could at best square-root the MAC search, which is negligible given 32-bit space is tiny anyway – the bottle-neck is more the protocol will reset after few failures). The O-CU’s PDCP integrity protection for user plane data (if enabled) uses the same NIA algorithms on each data PDU. User-plane integrity is optional because it adds overhead and can impact throughput (every packet gets a MAC). Some EU operators might enable it for specific scenarios (e.g., critical IoT communications) despite the performance cost, whereas others rely on encryption alone for user data integrity (ciphertext modifications would garble data, though not detectable by the cipher itself without a MAC). If user-plane integrity is off, one risk is an active attacker in the backhaul could flip bits in a user’s encrypted traffic which, while not decryptable, could corrupt the communication (e.g., causing a TCP connection to reset if the corruption hits the right bits). This is a known trade-off. If enabled, it mitigates that by O-CU-UP verifying each packet’s tag.

Source/Standard: These cipher and integrity algorithms are standardized by 3GPP in TS 33.501 Annex and the 3GPP 35-series specs (where their technical specs are published). They also align with ETSI SAGE designs. The CBOM would cite the origin (e.g., “128-NEA2: AES-128-CTR as per 3GPP TS 35.221”). Ericsson notes that 5G Phase 1 uses the same algorithms as 4G with no known weaknesses, but to meet future needs (software-based RAN, longer keys, etc.), new algorithms like SNOW-V and AES-256/GMAC are being developed for Rel-17+.

• Backhaul Security (O-CU to 5GC – N2/N3): The O-CU-CP connects to the 5G Core’s AMF over the N2 interface (carrying NG-AP signaling), and the O-CU-UP connects to the Core’s UPF over N3 (carrying GTP-U user packets). These are often on the operator’s IP network. 3GPP security architecture doesn’t enforce encryption here by default if the transport network is trusted, but it mandates support for IPsec or equivalent to protect N2/N3. In an open environment or an outsourced transport network, IPsec tunnels are typically used between the O-CU and a Security Gateway (SEG) at the core network side. In EU deployments, protecting the backhaul is important for both security and privacy (to prevent interception or tampering with user traffic as it leaves the RAN). Thus:
  • N2 (control plane to AMF): IPsec ESP with IKEv2 and certificates is required on the gNB (O-CU). Often the AMF or an intermediate SEG will handle the other end. This ensures all NAS signaling (which is anyway encrypted at NAS layer end-to-end, but still) and other control info is confidential and authenticated at the network layer too. It also hides the gNB’s IP and structure (topology hiding).
  • N3 (user plane to UPF): IPsec support is also mandated on gNB for N3, but the actual use is optional if the environment is deemed physically secure (as per operator decision). Many operators in practice do enable IPsec on N3, or use other protections like carrier-grade transport encryption. The cryptographic algorithms are the same (commonly AES-GCM). The throughput demands on N3 (which can be very high) sometimes drive solutions like using dedicated hardware or network function offloading for the IPsec encryption to handle many Gbps. For GDPR compliance, since user data leaves the RAN towards core, having it encrypted (even though PDCP encrypted, once it reaches UPF it gets decrypted to route internally) is an added layer of defense.
  • Alternatively, some networks use MACsec at the Ethernet transport if the O-CU and core are in the same L2 domain. But typically N2/N3 traverse IP networks, making IPsec the appropriate tool. TLS is not used here because NG-AP uses SCTP; if needed, DTLS over SCTP could be considered, and indeed 3GPP mentions DTLS support for Xn or other interfaces as an alternative.
  • The CBOM for O-CU would list “IPsec with AES-256-GCM, IKEv2 with ECDH and X.509 (PKI)” as a mechanism for backhaul. Known vulnerabilities are minimal if configured right (one risk historically is if weak certificate validation or outdated crypto is used, but 3GPP profiles disallow that). Both IPsec and TLS profiles in 5G are up-to-date (e.g., 3GPP quickly mandated TLS1.3, and required strong ciphers in IKEv2).

• Near-RT RIC Interface (E2): The O-CU (like O-DU) connects to the near-Real-Time RIC over E2. The security for this was covered in O-DU section – both CU and DU are E2 nodes that need to secure communication with the RIC. So O-CU will similarly have IPsec/TLS for E2. There’s an additional twist: the O-CU-CP might handle E2 messages related to RRC policies, and O-CU-UP might handle those related to user plane (QoS adjustments etc.), so both parts need secure links to the RIC or via some proxy. The cryptography remains consistent (cert-based mutual auth, AES encryption).

• OAM (O1 to SMO): The O-CU’s management interface is protected like the others with TLS/SSH. Given the O-CU is often virtualized, its management might be a Kubernetes/OpenStack API as well (for lifecycle management by orchestrators) – those APIs are also secured via TLS and OAuth or similar authentication. EU’s recommendations emphasize proper key and certificate management in these layers, meaning the O-CU has to handle certificate rotations, use unique certificates per instance, etc. The CBOM should capture any specific libraries (e.g., if the O-CU uses an OpenSSL FIPS module for all its TLS/IPsec needs, that should be noted along with version, to track any known CVEs or compliance level).

• Secure Boot & Integrity (O-CU): Similar to O-DU, the O-CU software must be validated. If the O-CU is a VNF/CNF, the NFVI ensures the image is signed. Additionally, the O-CU container or VM might use measured boot and attestation to the management system. O-RAN’s security specs include requirements for the O-Cloud to support attestation of VNFs. From a cryptographic standpoint, this involves the use of hashes (SHA-256/384) to measure images and digital signatures (RSA/ECDSA) by an attestation service to certify that measurements match expected values. The O-CU vendors also provide SBOMs listing open-source crypto (for example, the O-CU might incorporate the NR security library that implements NEA/NIA algorithms – if that library is open-source, e.g., a reference implementation of ZUC, its details would be in the CBOM). Known vulnerabilities: if any cryptographic library in use had a bug (say an OpenSSL bug), the CBOM helps identify it. For instance, if the O-CU uses OpenSSL 1.1.1, that would be listed, and one could cross-reference OpenSSL’s known issues. EU cybersecurity rules (like the NIS Directive and 5G Toolbox) push for regular security testing and patching of such components.

In summary, the O-CU contains the richest set of cryptographic functions in the RAN. It hosts all 5G radio security algorithms (SNOW 3G, AES, ZUC for encryption/integrity), deals with multiple secure interfaces (F1, E2, Xn, N2/N3, O1), and uses extensive PKI. Table 1 below summarizes the 3GPP algorithms used on the air interface via the O-CU:

Table 1: Standardized 5G Air-Interface Algorithms (in O-CU for PDCP)

• Classical vulnerability example: if any of these algorithms were found to have a weakness (e.g., a cryptanalytic attack), 3GPP would introduce replacements. So far, algorithms standardized since 2000 like AES, SNOW 3G, ZUC, etc., “have remained secure, with no practical attacks”, while older ones (A5/1, etc.) have been phased out. The CBOM helps track if an algorithm is considered legacy; in an EU context, operators avoid using legacy options at all.
• Post-Quantum outlook: The O-CU will be a component that eventually needs quantum-resistant algorithms for its certificate-based communications. 3GPP is well-prepared to introduce PQC when ready. Already, parameters like SUCI allow larger keys, and future releases might add PQC algorithms for IKEv2/TLS profiles. For symmetric radio ciphers, moving to 256-bit keys (as planned with SNOW-V and potentially AES-256-based NEA4) is a straightforward hedge.

Near-Real-Time RIC (Near-RT RIC)

Role: The Near-RT RIC is a new Open RAN component that sits between the SMO/Non-RT-RIC and the gNB (O-DU/O-CU). It hosts control applications (“xApps”) that perform real-time (within 10 ms to 1 s) optimization of RAN behaviors. It communicates with E2 nodes (O-CU and O-DU) over the E2 interface and with the Non-RT RIC (in the SMO) over A1 interface. From a cryptographic standpoint, the near-RT RIC is similar to a controller or server in a client-server model with the O-DUs/O-CUs as clients. Security is critical because if a RIC is compromised, it could send malicious commands that degrade or hijack the RAN. Conversely, if an attacker impersonates a gNB to the RIC, it could feed false data.

• E2 Interface Protection: The E2 interface is typically built on ASN.1-based messages over SCTP or TCP. The O-RAN Alliance security guidelines recommend IPsec to secure E2. The near-RT RIC thus serves as an IPsec endpoint for multiple tunnels (one per O-DU/O-CU). Cryptographically, this mirrors the earlier IPsec descriptions: IKEv2 with mutual cert auth (the RIC likely has a pool of certificates or uses one with multiple tunnels), and ESP with AES-GCM (128 or 256-bit). The RIC’s CBOM includes the cryptographic algorithms for these tunnels. For scalability, the RIC might use high-performance crypto acceleration, given potentially dozens of gNB connections. If E2 runs within a closed network, some might consider not encrypting it, but doing so is risky; indeed, a security analysis noted that leaving E2 unencrypted poses high risk. Known vulnerabilities if unprotected: E2 messages could be manipulated (e.g., an attacker could spoof a “hand over this UE to my rogue cell” command if they intercepted E2). With IPsec, authenticity and confidentiality are ensured. The same quantum considerations (ECDH and RSA certs vulnerability) apply, so future RIC designs will need updates (maybe using PQC-based IKE or quantum-safe VPNs when available).
• A1 Interface Security: The A1 interface connects the Non-RT RIC (inside SMO) with the Near-RT RIC. It typically carries policy directives or high-level guidance (not real-time critical). A1 messages often use a RESTful API (HTTP/HTTPS with JSON). Thus, TLS 1.3 is the natural choice to secure A1. In practice, the near-RT RIC may host an HTTPS server for A1, and the SMO acts as client (or vice-versa for certain queries). The CBOM should list TLS 1.3, with likely cipher suites like TLS_AES_256_GCM_SHA384 or TLS_CHACHA20_POLY1305_SHA256, ECDHE key exchange, and X.509 certificates for both RIC and SMO. Mutual TLS is advisable so that each side authenticates the other (preventing an impostor SMO or a fake RIC). The algorithms involved (ECDSA certs, AES, ChaCha, etc.) have no known classical weaknesses when configured correctly. The main risk is misconfiguration (trusting the wrong CA, weak ciphers if someone enabled them, etc., which O-RAN specs try to prevent by profiling). The quantum weakness of TLS is, again, the reliance on ECDH and RSA/ECDSA. The RIC’s TLS library might support post-quantum ciphersuites in the future (several such experimental ciphersuites exist, combining classical and PQ key exchanges). For now, using curve25519 and 3072-bit RSA (or ECDSA-256) at least gives a decent security level.
• RIC Platform Security and xApps: The RIC, being a software platform that loads third-party xApps (which can be provided by various vendors to extend RAN functionality), introduces supply chain considerations. Each xApp should be digitally signed by its developer and verified by the RIC platform before deployment (to ensure authenticity and that it hasn’t been tampered). The signing could use code signing certificates (possibly an O-RAN code signing PKI). For example, an xApp package might carry an XML or JSON signature or a detached signature file (using X.509 and PKCS#7 or similar). The cryptography here might involve RSA-2048 signatures or ECDSA. The RIC CBOM would include what signature schemes it supports for xApps. If this process is not in place, a malicious or vulnerable xApp could be sideloaded. The O-RAN Alliance was studying security for Near-RT RIC and xApps, and it’s likely that recommendations such as code signing, permission isolation, and perhaps runtime attestation of xApps will be instituted. Classical vulns would be minimal if code signing uses modern algorithms. The bigger issue is operational (ensuring keys used to sign xApps are protected and the trust model is sound). In EU contexts, strong software integrity and isolation are expected for such multi-vendor platforms.
• Management Interface: The near-RT RIC itself is managed via O1 (by SMO). So like O-CU and O-DU, it will have NETCONF/RESTCONF interfaces protected by TLS or SSH. The same cryptographic patterns apply (certs, TLS 1.3). There might also be an O2 interface if the RIC is a VNF, for the orchestrator to manage its lifecycle on the cloud infrastructure – that would typically also rely on TLS and secure APIs.
• Secure Boot & Platform Integrity: The near-RT RIC likely runs on the O-Cloud as a VM or container. So its secure boot is covered by the underlying platform’s secure boot. The RIC application software itself could be verified via signatures and checksums in the container image (much like O-DU/O-CU). A CBOM would list cryptographic hashes of the RIC software components, any signing keys/certs used to verify them, etc. Additionally, if the RIC platform uses a database or message bus, encryption at rest or in transit for those internal components might be noted (e.g., if Kafka is used for messaging, TLS would secure it, adding to cryptographic inventory).

In essence, the near-RT RIC extends the cryptographic boundary of the RAN. It doesn’t introduce fundamentally new primitives beyond what’s used in O-CU/O-DU (mostly it leverages TLS/IPsec, X.509 PKI, code signing). But it highlights the importance of a robust PKI: multiple components (RU, DU, CU, RIC, SMO) all need certificates and a trust hierarchy. EU agencies like ENISA stress the need for automation in certificate lifecycle at this scale, because manual management would be error-prone. Thus, one entry in the CBOM could be a Certificate Authority component, e.g., “Operator Private CA – RSA-4096 root, issues device certs (RSA-2048 or ECC P-256) for O-RAN nodes, 20-year validity” – which itself uses cryptography (SHA-256, RSA signatures) and must be secured (maybe stored in HSM, etc.)

Service Management and Orchestration (SMO & Non-RT RIC)

Role: The SMO is the top-level framework in Open RAN for managing and orchestrating all RAN components. It includes the Non-Real-Time RIC functionality (for rApps and policy management) and handles FCAPS management (Fault, Configuration, Accounting, Performance, Security) via the O1 interface, as well as lifecycle management via O2. It may interface with external OSS/BSS systems. The SMO is essentially an IT/Cloud system that must communicate securely with potentially thousands of distributed RAN nodes. As such, it heavily uses standard cryptographic protocols to ensure confidentiality, integrity, and authentication across these communications. Being an orchestration entity, it’s also responsible for key management functions like distributing certificates or credentials to the RAN nodes.

• O1 Interface (SMO ↔ O-RAN nodes management): This is generally a NETCONF or REST-based management link to O-RUs, O-DUs, O-CUs, and near-RT RIC. As discussed for other nodes, the SMO will initiate TLS connections to each node for O1 (or accept connections). Thus, the SMO acts as a TLS client (for NETCONF over TLS) or server depending on design, but mutual authentication is the norm. The SMO holds a trust store of all node certificates (signed by the operator CA) and possibly its own certificate that nodes trust. Cryptographically, the SMO likely uses a robust TLS stack (supporting TLS 1.3, PFS ciphers, etc.). It must support many simultaneous secure sessions. The SMO’s CBOM includes algorithms like TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (just as an example of a cipher suite) and maybe TLS_CHACHA20 for performance on certain links. ENISA explicitly calls out the need to “ensure usage of current security protocols for TLS and appropriate key and certificate management”, which the SMO is chiefly responsible for. This means TLS 1.3, no TLS 1.0/1.1, and strong cipher suites only. The SMO might enforce policies like refusing any RAN node whose cert is not from the expected CA or is expired – essentially acting as a certificate authority itself in function. There are no unique vulnerabilities beyond typical TLS considerations (like trust chain validation, revocation checking via CRL/OCSP, etc., which should be part of the security policy). In an EU scenario, the SMO’s management connections ensure GDPR compliance by encrypting any personal or network operational data in transit on O1 (like subscriber data in trace logs, configuration of user identifiers, etc.), thus fulfilling the “appropriate technical measures” requirement of GDPR (encryption and access control are explicitly mentioned in GDPR Art.32).
• O2 Interface (SMO ↔ O-Cloud): O2 manages the infrastructure (O-Cloud) on which the O-RAN functions run (similar to NFV MANO in ETSI). This typically involves controlling VM/container deployment, resource allocation, etc. O2 is often implemented via secure REST APIs to the cloud/orchestrator (for example, the SMO might communicate with an OpenStack or Kubernetes API). These APIs are secured with TLS as well, and often with client certificates or tokens for auth. Cryptographically, it’s TLS (similar profile to O1). Additionally, the SMO might use protocols like SSH or Ansible with SSH to configure underlying hosts – those use the SSH cryptos (Ed25519 keys, AES, etc.). The CBOM here doesn’t introduce new primitives; it just means enumerating that “SMO uses HTTPS (TLS1.3) with the O-Cloud NFVI API” and the algorithms thereby used. If the O-Cloud is operated by a third party, there might be VPN tunnels (IPsec) between SMO and O-Cloud too, which again reuse prior algorithms.
• A1 Interface (SMO/Non-RT RIC ↔ Near-RT RIC): The Non-RT RIC, part of SMO, communicates policies/AI model outputs via A1. Security for A1 was described under RIC: mutual TLS with JSON/HTTP. From SMO side, it’s just the client or server counterpart. The SMO will host the Non-RT RIC’s services likely on a secure web server. All the cryptography is the same (X.509, TLS).
• PKI and Key Management: The SMO often encompasses the Security Management functions, including PKI services. In an Open RAN deployment, an operator may run a dedicated Certificate Authority (or use an existing telco PKI) to issue certificates to each RU, DU, CU, RIC, etc. The SMO (or a subcomponent thereof) could manage certificate enrollment via protocols like CMPv2, SCEP, or EST, which are used to securely distribute certificates and keys to devices. These protocols themselves use cryptography: for instance, CMPv2 messages can be signed and encrypted (CMS with AES, RSA, etc.), EST runs over HTTPS, etc. The CBOM should include entries for these mechanisms if used (e.g., “Certificate provisioning: CMPv2 using RSA-2048 signature, AES-128 encryption for messages”). DigiCert notes that automation of PKI (with protocols like EST and CMPv2) is crucial for scale. The SMO’s key management also covers:
  • Generating key material for certain network functions (if symmetric keys are distributed).
  • Storing master keys or seeds (which should be in an HSM ideally – that HSM itself using cryptography like master wrap keys, etc., though that may be too granular for CBOM).
  • Handling SSH key management for any CLI access – e.g., updating authorized keys on systems, which involves cryptographic hashes of fingerprints, etc.
• Secure Storage: The SMO likely manages a database of network information. If it stores sensitive data (like user identifiers, performance data that might include personal data), encryption at rest is employed. That could mean the SMO’s database uses AES-256 encryption (either at application level or disk level). EU’s GDPR encourages encryption of personal data at rest as well (to mitigate breaches). So a CBOM might note “PostgreSQL DB encryption: AES-256-XTS at disk layer” or “Vault storage for keys: AES-GCM with hardware support”.
• Software Integrity and Updates: The SMO, being a software platform possibly based on open-source components (ONAP/O-RAN SC SMO or similar), should have its own secure update mechanism. It likely receives updates or new apps (rApps) which are signed. For instance, rApps might be signed similarly to xApps. The SMO software itself likely runs on standard OS, so it relies on Linux package signing (e.g., RPM/DEB signing with RSA keys) as part of its supply chain security. These are indirect but relevant cryptographic items in an overall CBOM.
• Audit and Monitoring: One aspect of cryptographic material often overlooked is logging and audit. The SMO might have a central log of security events (e.g., login attempts, certificate expirations). If those logs are exported, they might use TLS or be signed to ensure integrity. For example, syslog over TLS (with mutual TLS) could be used to send logs to a SIEM. That adds entries (again TLS 1.2/1.3 algorithms). Also, any root of trust or secure module used by SMO would be part of CBOM: e.g., if the SMO uses a hardware security module (HSM) for CA keys, that HSM might use its own internal cryptographic algorithms (maybe proprietary implementations of AES, or support for ECC). We might note compliance like “HSM (FIPS 140-2 Level 3, uses RSA-2048, AES-256 for key wrapping, etc.)”.

In EU deployments, compliance with regulations such as GDPR and the EU 5G Toolbox is critical. The SMO is where compliance is enforced: by encrypting data in transit and at rest, and by ensuring secure configuration management. For example, GDPR requires data controllers to implement appropriate security – encryption is explicitly cited as an example. Our CBOM demonstrates that all interfaces carrying personal data (subscriber identities, keys, etc.) are encrypted (O1, A1, F1, N2/N3, etc.), fulfilling those requirements. Additionally, EU’s NIS Directive and national regulations require telcos to secure their networks; having a full inventory of cryptographic components (a CBOM) is aligned with those requirements for risk assessment and incident response.

O-Cloud and Virtualization Infrastructure

(Note: This section touches on the underlying cloud infrastructure, which is slightly beyond the RAN nodes themselves but is included for completeness as it is part of the Open RAN environment. If the focus is strictly on RAN functional elements, this can be omitted.)

The O-Cloud provides the virtualization or containerization platform for hosting O-DU, O-CU, near-RT RIC, and possibly parts of SMO. Its cryptographic mechanisms ensure the infrastructure is secure:

• Secure Infrastructure Communication: The O-Cloud consists of compute & storage nodes, and a cloud manager. Their internal communications (APIs, message buses) use TLS or SSH. For example, OpenStack control traffic is often on TLS, and Kubernetes API is on TLS with client certs for kubelets. These use standard cryptos (X.509, AES, etc.). If the O-Cloud spans multiple sites, IPsec tunnels might link them.
• Virtual Network Functions (VNF/CNF) Isolation: Technologies like VLAN or VXLAN encryption, or Software-Defined Networking security may be used. Some implementations might use MACsec within the data center to isolate tenant networks (VXLAN over MACsec). Again AES-GCM appears here as the cipher if used.
• Image Signing and Attestation: When VNFs (like the O-CU) are deployed, the O-Cloud verifies images via signatures (perhaps using OpenStack Glance image signatures, which use RSA/ECDSA). It may also perform attestation (Intel TXT/TPM-based) to ensure hosts are in a trusted state – which involves TPM quote signatures (RSA/ECC signature on PCR values). Those cryptographic assurances might be listed.
• Secure Storage: If the O-Cloud uses ceph or some storage for VM images, they might be encrypted (LUKS encryption using AES-XTS on disks, etc.).

All these contribute to a comprehensive security posture but are more “IT security” of the cloud. They are important in Open RAN because disaggregation means more reliance on cloud tech. The O-RAN Security Focus group indeed has a study on O-Cloud security, highlighting issues and presumably recommending secure isolation and trusted computing base.

From a CBOM perspective, one might list “TPM 2.0 (SHA-256 PCRs, ECC attestation keys) present in O-Cloud servers”, “OpenStack Barbican for secrets management (AES-256 encryption of secrets)” and so forth.

Conclusion

In conclusion, the Open RAN telecom architecture uses a broad array of cryptographic mechanisms to secure every plane of communication and aspect of operation. Table 2 below recaps the major cryptographic primitives by component and function:

Table 2: CBOM Highlights by Component and Function

Final Notes: This CBOM illustrates that an Open RAN deployment in the EU context employs strong, state-of-the-art cryptographic controls at every layer: from SIM-based symmetric encryption for subscriber auth, through robust air-interface ciphers (AES, SNOW 3G, ZUC), to extensive use of PKI, TLS 1.3, IPsec VPNs, and secure boot mechanisms. The design addresses known classical threats (eavesdropping, tampering, impersonation) with well-vetted algorithms that have no known practical vulnerabilities. It also anticipates emerging threats: for example, by allowing 256-bit keys and modular algorithms, the system is poised to evolve toward quantum-resistant cryptography in the future. The CBOM also aligns with EU regulatory expectations, like GDPR’s call for encryption of personal data and the EU 5G Toolbox’s emphasis on supply chain security and use of certified components. By referencing sources such as 3GPP specs, O-RAN Alliance security docs, and ENISA guidelines, we ensure the described cryptographic profile is grounded in internationally recognized standards and best practices. This comprehensive inventory can serve as a baseline for security audits, compliance checks, and future upgrades of the RAN’s security posture.