Open RAN telecom network security begins in the microprocessors that control telecom network equipment. Configure and use these processors with secure booting and build trust.

Disaggregated open radio access networks (Open RANs) offer numerous advantages to telecom operators compared to legacy, closed RANs. Open RAN relies on standardized interfaces, protocols, and interoperable hardware from multiple vendors. Designing and deploying radios and other equipment for Open RAN does, however, bring security challenges starting with the hardware.

While you may think of security as purely a software issue, security begins with the microprocessors that control the key functional blocks of the radio unit (RU), distributed unit (DU), centralized unit (CU), and RAN intelligent controller (RIC). Securely storing boot data in a microprocessor and using cryptoprocessors can bring security into the hardware that runs Open RAN equipment.

Figure 1 shows an Open RAN network architecture as defined by the O-RAN Alliance.

Mobile network operators (MNOs) looking to benefit from the lower equipment costs, improved network performance, and greater flexibility that result from moving away from closed, proprietary systems will largely drive growth in the Open RAN market. At the same time, there is significant political will to drive the ORAN evolution – most notably with the announcement that the CHIPS and Science Act of 2022 has allocated $1.5 billion of funding to the development of Open RAN systems.

Open RAN security challenges
Creating disaggregated networks around products from multiple suppliers could make Open RANs more vulnerable to cyberattacks than closed-system baseband units (BBUs). This risk has been specifically highlighted in Open Radio Access Network Security Considerations, which assesses the security considerations associated with implementing an Open RAN as architected and specified by the O-RAN Alliance.

This paper looks at security across a variety of technical aspects of Open RAN, ranging from multi-vendor management and radios and base station equipment to artificial intelligence and general network considerations.

The paper states:
“The deployment of Open RAN introduces new security considerations for mobile network operators (MNO). By nature, an open ecosystem that involves a disaggregated multi-vendor environment requires specific focus on changes to the threat surface area at the interfaces between technologies integrated via the architecture. In addition to addressing security considerations related to integrating components from multiple vendors, service providers will continue to deal with other considerations related to use of open-source applications and new 5G network functions and interfaces whose standards are still under development. Additionally, MNOs will need to address security considerations related, but not unique to Open RAN, such as cloud infrastructure, virtualization, containerization, and Distributed Denial of Service attacks.”

One of the challenges with technologies from multiple vendors is where the responsibility for security should fall. With traditional, proprietary RANs (BBUs), implementation issues tend to fall on a single supplier. With Open RAN, network operators may have to spend more time identifying which suppliers need to address security. Many operators will create Open RAN networks based on the core of existing LTE networks, which themselves can be susceptible to passive, eavesdropping attacks and active “man-in-the-middle” attacks. Furthermore, the attack surface is only going to increase as the number of connected devices grows. With increased security management overhead, network operators risk that the costs of mitigation begin eroding the cost savings touted as one of the fundamental benefits of ORAN.

Opportunities for virtualization move RANs towards cloud-based implementations, meaning network operators should be able to mitigate some of the security threats by leveraging security features already integrated into established cloud computing architectures. Many networks may not, however, be virtualized or have limited virtualization. Cost benefits (both initial and ongoing) are often the most significant factor in implementing virtualized networks.

Addressing Open RAN security
Regardless of whether networks implement virtualized security, many requirements call for for physical security at the hardware level. Delivering this security while maintaining the benefits of Open RAN encourages network architects to seek out off-the-shelf, semiconductor and hardware platform technologies designed to deliver cyber protection. These include embedded processors with integrated security features and certified “Trusted Platform Modules” built on industry-recognized specifications.

Here are guidelines to help OEMs and component suppliers implement stronger security in critical infrastructure systems. Guidelines such as those included in NIST Special Publication 800-193, which provide recommendations for supporting resiliency of platform firmware and data against potentially destructive attacks.

The NIST guidelines refer to the hardware and firmware components needed to boot and operate a system with respect to attacks that could render a system temporarily or permanently inoperable, leading to disruptions for users.
The three core principles of the guidelines are:

• Protect: Ensure code and critical data are protected from changes, whether malicious or inadvertent
• Detect: Identify when code and critical data have been corrupted
• Recover: Provide a means to restore code and critical data to a known good state

These requirements lead to a number of criteria for any secure system that forms part of the ORAN network:

• Secure boot: The use of hardware-enforced root of trust to ensure the integrity of the software at start up
• Authentication: The provision of unique and verifiable identity
• Secure communications: The transmission of authenticated and encrypted data
• Secure programming and debugging: Tight control over access to the system’s physical interfaces. This includes the removal of interface ports used during product development but not needed in production units
• Asset protection: Tight control over passwords, encryption keys and security certificates
• Lifecycle management: As cyberthreats evolve, so do cybersecurity measures
• Assurance: Demonstrating that all devices on the system are cyber robust and have been subjected to penetration (pen) testing, for example.

Semiconductor manufacturers have developed a variety of technologies with integrated features and capabilities to simplify developing equipment that meets these criteria.

Take, for example, secure embedded controllers originally designed for computing and network storage applications but are equally well-suited to providing security in the open systems around which equipment manufacturers and system architects will build ORANs. These embedded controllers feature a secure boot (root of trust) capability that combines immutable code in the Boot ROM along with public/private key cryptography. All application code must be authenticated using the public key before execution, while an elliptic curve cryptography (ECC) digital-signature algorithm can authenticate the code and validate that it is not corrupt.

When it comes to the NIST recovery requirements, you should provide redundancy by storing multiple images of the controller’s application code in external memory. This way if, at boot time, the first image is corrupted then the boot process can take place using another image. Once the application code has been loaded, the controller’s crypto hardware can extend the protection, detection, and recovery requirements to BIOS, management engine (ME), and other code and information stored in memory. Should corrupt system code be detected, then the application code can use backup or “golden” images to restore the system.

Figure 2 shows one implementation of a NIST-compliant embedded controller based on a master attached flash (MAF) memory configuration using a single SPI Flash chip. Alternative configuration options include MAF with two SPI chips, shared flash memory with a single SPI chip and shared MAF with two SPI chips.

Secure system booting is an important first line of defense. In some cases, application-specific demands may mean that Open RAN equipment designers are faced with basing their hardware on microprocessors that do not offer this integrated capability. Thus, they do not validate code prior to execution. In such cases, it will be necessary to add secure boot capability to the equipment design. One way to achieve this is to choose an off-the-shelf secure boot reference design built around the latest FPGA technology.

As Figure 3 shows, these devices, which use a trusted source and a comprehensive authentication process, can sit alongside target processors and, in the case of the system shown, include differential power analysis (DPA) resistant anti-tamper measures.

Standalone security cryptoprocessors
Another development of note for Open RAN equipment manufacturers is the emergence of dedicated and standalone security “cryptoprocessor” ICs that adhere to the Federal Information Processing (FIPS) standards developed by the NIST Computer Security Resource Center (CSRC) and support Trusted Computing Group (TCG) specifications.

FIPS standards apply to federal agencies that use cryptographic-based security systems to protect sensitive information in computing and telecom equipment, making them a good basis on which to build ORAN security at the hardware level. FIPS-compliant chips, which provide a method for storing keys in protected hardware and manage those keys to achieve multi-layer security, effectively acting as hardware crypto accelerators. They offload complex security operations from the host processor and protect keys in hardware. Because these chips are already used in embedded systems, they are proven, widely available, and cost-effective.

Figure 4 shows a block diagram of a cryptoprocessor IC that combines a microcontroller, protected non-volatile memory, and strong, hardware-based public key (RSA) security technology on a single chip. The device implements the TCG specification for trusted platform modules (TPMs), features a FIPS-certified pseudo-random number generator for key generation, and offers secure boot, intellectual property protection, authentication, and secure communications. It also includes active shielding and a variety of tamper-detection and response capabilities.

Conclusion
Implementing Open RANs demands a focus on changes to the threat surface area at the interfaces between the technologies integrated into the architecture. In addition, because many network operators create Open RAN networks based on the core of existing LTE networks, they can also be susceptible to passive, and active attacks. As a result, network architects must consider the safety and security of every possible connection.

Open RAN architectures will largely be built around cost-effective, commercially available, off-the-shelf application-specific technologies that speed implementation and reduce cost. When it comes to security, processors that help hardware designers mitigate security issues to implement robust, protected next-generation ORAN infrastructures will be vitally important.

These semiconductors should address the requirements of relevant bodies and standards including NIST, CISA, FIPs and the TCG by provide functionality ranging from secure boot and hardware root of trust to cryptography key generation and authentication, tamper detection and solutions for system recovery. In a growing number of cases, such security can be embedded in controllers and TPMs, and where it is not available can be added using proven, off-the-shelf reference designs.