Open-Radio Access Network (O-RAN) is the next evolutionary step in mobile network architecture and operations and the Near-Real Time RAN Intelligent Controller (Near-RT RIC) plays a central role in the O-RAN architecture as it interfaces between the orchestration layer and next generation eNodeBs. In this paper we highlight the architectural weakness of a centralized controller in O-RAN by first drawing parallels with the Software-Defined Networking (SDN) controller. We then present a two part security evaluation of two open-source Near-RT RICs (μONOS and OSC), focused on the newly introduced A1 interface of the Near-RT RIC. In the first part of our evaluation, we evaluate the supply-chain risks of μONOS and OSC using off-the-shelf open-source dependency analysis and configuration file analysis tools. In the second part, we present our run-time security testing of the A1 API implemented by μONOS and OSC using our custom O-RAN A1 Interface Testing Tool (OAITT). Our supply-chain risk analysis shows that both the open-source Near-RT RICs we evaluated have multiple dependency risks and weak or insecure configurations. We identified 211 and 285 known dependency vulnerabilities in μONOS and OSC respectively of which 82 and 190 dependencies were rated as high CVSS respectively. The A1 interface contributed to a majority of the dependency risks in both Near-RT RICs. From a security misconfiguration perspective, we identified issues concerning access control, lack of encryption and poor secret management. Our run-time testing of OSC and μONOS revealed the following. First, both Near-RT RICs lack TLS for the A1 interface. Second, malicious Non-Real Time RAN Intelligent Controller (Non-RT RIC)s or rApps that reside in the Non-RT RIC could tamper with policies installed in the Near-RT RIC which can impact the availability of the O-RAN. Third, the A1 protocol could be exploited by Non-RT RICs for covert communication via the Near-RT RIC. Fourth, the A1 implementation by μONOS was vulnerable to degradation of service attacks (10-60s response time for GET requests) and a denial of service attack, the latter has been ethically reported and a fix is underway.

Trusted Platform Modules (TPMs) constitute an integral building block of modern security features. Moreover, as Windows 11 made a TPM 2.0 mandatory, they are subject to an ever-increasing academic challenge. While discrete TPMs (dTPMs) – as found in higher-end systems – have been susceptible to attacks on their exposed communication interface, more common firmware TPMs (fTPMs) are immune to this attack vector as they do not communicate with the CPU via an exposed bus.In this paper, we analyze a new class of attacks against fTPMs: Attacking their Trusted Execution Environment (TEE) can lead to a full TPM state compromise. We experimentally verify this attack by compromising the AMD Secure Processor (AMD-SP), which constitutes the TEE for AMD’s fTPMs. In contrast to previous dTPM sniffing attacks, this vulnerability exposes the complete internal TPM state of the fTPM. It allows us to extract any cryptographic material stored or sealed by the fTPM regardless of authentication mechanisms such as Platform Configuration Register (PCR) validation or passphrases with anti-hammering protection. First, we demonstrate the impact of our findings by – to the best of our knowledge – enabling the first attack against Full Disk Encryption (FDE) solutions backed by an fTPM. Furthermore, we lay out how any application relying solely on the security properties of the TPM – like Bitlocker’s TPM-only protector – can be defeated by an attacker with 2-3 hours of physical access to the target device. Lastly, we analyze the impact of our attack on FDE solutions protected by a TPM and PIN strategy. While a naive implementation also leaves the disk completely unprotected, we find that BitLocker’s FDE implementation withholds some protection depending on the complexity of the used PIN. Our results show that when an fTPM’s internal state is compromised, a TPM and PIN strategy for FDE is less secure than TPM-less protection with a reasonable passphrase.

Cloud computing is one of the most prominent technologies to host Internet services that unfortunately leads to an increased risk of data theft. Customers of cloud services have to trust the cloud providers, as they control the building blocks that form the cloud. This includes the hypervisor enabling the sharing of a single hardware platform among multiple tenants. Executing in a higher-privileged CPU mode, the hypervisor has direct access to the memory of virtual machines. While data at rest can be protected using well-known disk encryption methods, data residing in main memory is still threatened by a potentially malicious cloud provider. AMD Secure Encrypted Virtualization (SEV) claims a new level of protection in such cloud scenarios. AMD SEV encrypts the main memory of virtual machines with VM-specific keys, thereby denying the higher-privileged hypervisor access to a guest's memory. To enable the cloud customer to verify the correct deployment of his virtual machine, SEV additionally introduces a remote attestation protocol. This protocol is a crucial component of the SEV technology that can prove that SEV protection is in place and that the virtual machine was not subject to manipulation. This paper analyzes the firmware components that implement the SEV remote attestation protocol on the current AMD Epyc Naples CPU series. We demonstrate that it is possible to extract critical</> CPU-specific keys that are fundamental for the security of the remote attestation protocol. Building on the extracted keys, we propose attacks that allow a malicious cloud provider a complete circumvention of the SEV protection mechanisms. Although the underlying firmware issues were already fixed by AMD, we show that the current series of AMD Epyc CPUs, i.e., the Naples series, does not prevent the installation of previous firmware versions. We show that the severity of our proposed attacks is very high as no purely software-based mitigations are possible. This effectively renders the SEV technology on current AMD Epyc CPUs useless when confronted with an untrusted cloud provider. To overcome these issues, we also propose robust changes to the SEV design that allow future generations of the SEV technology to mitigate the proposed attacks.