DLT-EVA: Hardening O-RAN Auditing and Digital Evidence Preservation Through Blockchain

DLT-EVA: Hardening O-RAN Auditing and Digital Evidence Preservation Through Blockchain Konstantinos Ntouros∗, Eleftherios Poulitsis†, Sotirios Brotsis‡, Konstantinos P. Grammatikakis§, and Nicholas Kolokotronis¶ Department of Informatics and Telecommunications, University of the Peloponnese, 22131 Tripolis, Greece Email: ∗[email protected], †[email protected], ‡[email protected], §[email protected], ¶[email protected] Abstract—The open radio access network (O-RAN) includes innovative building blocks, like the near-real time RAN intelligent controller and extensible applications, among others, that provide effective management of the communications infrastructure and services. The integration of potentially untrusted thirdparty applications raises significant security concerns, while the transition to softwarized networks driven by network function virtualization extends O-RAN attack surface and increases the threats to consider. Although security event logging contributes to adversarial behavior detection in O-RAN, an elaborate log management architecture for the secure preservation of important security event information is still at its early stages. In this paper, we propose a blockchain-enabled framework, referred to as DLTEVA, for trusted digital evidence preservation and auditing in ORAN that employs advanced remote attestation techniques and secure distributed log management. It is shown how the proposed framework is capable of defending against sophisticated cyberattacks on remote attestation systems, therefore ensuring the secure operation of critical O-RAN applications and services. Index Terms—O-RAN security; Blockchain; Log management; Remote attestation; Cyber-attacks. I. INTRODUCTION The open radio access network (O-RAN) is considered as a cutting-edge paradigm designed for wireless communications systems to overcome the limitations of current RAN technologies and enable different mobile network operators to launch their customized services [1], [2]. However, the advancements brought by O-RAN come with new forms of threats and cyberattacks due to the network’s openness and softwarization [3]. Remote attestation can greatly contribute towards securing the operation of disaggregated O-RAN functions and components at the edge and/or the cloud by verifying their integrity [4]; it complements trust-based access control policies, allowing only verified nodes to be onboarded to the operational environment of O-RAN. Remote attestation detects unauthorized modifications to critical components that may considerably increase the attack surface and allow adversaries’ lateral movement in the network [5]. However, if not properly secured, cyber-attacks can target and compromise the attestation process itself giving The authors K. Ntouros and E. Poulitsis have equally contributed. This work is partially funded by the European Union. Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or Smart Networks and Services Joint Undertaking. Neither the European Union nor the granting authority can be held responsible for them. The XTRUST-6G project (GA no. 101192749) is supported by the 6GSNS and its members. rise to numerous other attacks against O-RAN that severely violate the security policies [6]. As O-RAN presents a large attack surface, security logging should be a core part of any security solution. Securityrelated events stemming from the application and network layers about failed authentication or data access attempts are indicative examples of the information that needs to be logged for facilitating the detection of adversarial behavior in ORAN, [7]. Current work is focused on the design of centralized log management systems for O-RAN [8], [9], which become a target of great value for adversaries; if they get compromised, any information that may constitute digital forensic evidence could be modified or even erased by the attacker with ease. Therefore, distributed technologies like blockchain offer a secure and immutable solution for safeguarding security logs spanning the entire O-RAN infrastructure. To address these issues, an innovative blockchain-enabled framework is introduced in this paper, referred to as DLT-EVA, that provides remote attestation and auditing for enhancing the resilience and security of O-RAN and the future 6G networks. The rest of the paper is organized as follows. Section II presents the background and related works on O-RAN, remote attestation, and blockchain technology, where the attack surface of O-RAN is presented in Section III. Section IV presents the proposed solution, which includes a high-level architecture and details about the tools and data flows. Experimental results on an attack targeting the attestation process are presented in Section V, while conclusions and future work are given in Section VI. II. BACKGROUND AND RELATED WORK This section presents an overview of the background and related work concerning the O-RAN architecture, blockchain technology, and remote attestation. A. O-RAN architecture The O-RAN architecture [10] extends the 3GPP-based RAN specification and provides a logical representation of its elements as virtualized network functions (VNF) implementing a set of formalized interfaces, deployed on an O-RAN compatible cloud computing environment. The deployed components are divided in two major areas, namely the radio side and the management side. The radio side hosts VNFs for the real-time (RT) or near-RT operation (i.e. sub 10 millisecond control loops) of the RAN on the open cloud (O-Cloud), including (see Fig. 1): •The O-RAN radio unit (O-RU) handling the low physical layer (PHY) radio communications, connected via Open Fronthaul (Open FH) to O-DU or the SMO, leading to a hierarchical and hybrid deployment respectively. •The O-RAN distributed unit (O-DU), hosting the higher PHY protocols including the radio link control (RLC) and the media access control (MAC) protocols. •The O-RAN central unit control/user planes (O-CU-CP/ O-CU-UP), which hosts the radio resource control, packet data convergence protocol, along with the service data adaptation protocol. •The O-RAN near-RT RAN intelligent controller (NearRT RIC) and its extensible applications (xApps), which provide RAN analytics and control the E2 nodes (O-DU, O-CU) via the policies set by the Non-RT RIC through the A1 interface. In the case of failure, the E2 nodes are expected to continue functioning, albeit in a non-optimal manner [10]. The O-Cloud defines the deployment environment for the radio side VNFs, the container runtime, and auxiliary components/functions for container monitoring and orchestration. It exposes two interfaces to the SMO: (a) the O2 interface for infrastructure, performance, and configuration management; and (b) the O1 interface to control the radio side VNFs. In addition, it provides application programming interfaces (API) for hardware acceleration and critical workload notifications. The management side hosts the service management and orchestration (SMO) framework responsible for RAN domain management. Internally, it hosts the Non-RT RIC and the RAN applications (rApps) enforcing policies and providing services, such as ML model management, to the near-RT RIC (A1). It also provides services to the radio side VNFs (O1), the O-RU (Open FH), and the O-Cloud platform (O2). The SMO services include the federated O-Cloud orchestration and management (FOCOM), the network functions orchestration (NFO), secure package onboarding, RAN analytics, as well as, the topology exposure and inventory management (TE&IV). B. Blockchain technology Blockchain has received great attention in various scientific areas, as it inherently offers security, privacy, decentralization, and auditability. It is perceived as a sovereign RoT to exchange information among entities by establishing a distributed series of records and a sequential order of blocks. The blockchain essentially provides a decentralized and immutable service for preserving data from mutually distrustful parties [11]. Blockchain networks can be divided into different settings, according to the access control policies of the network nodes. In permissionless, any node can be part of the network, while in permissioned, which are subdivided into private and public, the blockchain nodes’ identities are verified and they can be held liable for any malicious action [11]. O-CLOUD O1 VNF/CNF virtualization layer E2 A1O2 near-RT RIC . . . xAppxApp messaging infrastructure O-CU O-DU SMO framework non-RT RIC . . . rApprApp NFO security FOCOM other functions rApp mgmt. R1 service mgmt. messaging infrastructure Open FH M-Plane Open FH M-Plane CUS-Plane #1 O-RU #4 #5 #3 #2 Fig. 1: High-level O-RAN architecture and potential threats. Several frameworks have been proposed to enhance the security of O-RAN. TrustORAN was introduced in [12], where the authentication and verification of xApps is conducted by O-RAN players via smart contracts, for preventing unauthorized access. Blockchain technology and federated learning were used in [13] for enhanced trust, accountability, and coordination among O-RAN components. However, the existing literature on O-RAN auditing is still limited, and the solutions are still being shaped along with the development of O-RAN specifications. C. Remote attestation Remote Attestation (RA) is a valuable security service for establishing a static or dynamic root-of-trust (RoT) and serves as the basis for other security-related operations, like firmware and software updating [14]. In RA, the verifier, which is a trusted entity, attempts to assess the state of an attested node that is referred to as prover. The verifier’s primary aim is to determine, via a challenge-response protocol, whether the prover’s state complies with the security policies. When the verifier challenges the prover with an attestation request, then an attestation response (i.e. a measurement) is generated about the prover’s state, which is compared against predefined and clean state measurements by the verifier [15]. In this context, three main approaches exist [16]: •Hardware-based, in which tamper-resistant hardware is employed, such as the software guard extensions (SGX), trusted platform module (TPM), and physical unclonable functions (PUF); •Software-based, which do not require hardware security components but instead rely on common methods, such as empty memory space-filling and response-time to realize attestation; and •Hybrid approaches, which leverage the advantages from both worlds and are commonly used for devices that are not equipped with delicate hardware components. Towards securing O-RAN, Kuure [17] used remote attestation for enabling trust in a cloud-native multi-vendor environment. This research area remains relatively unexplored, without any blockchain-enabled framework being proposed for enhancing O-RAN security and trust using remote attestation. Nevertheless, RA schemes can become the target of many attacks, including side-channel attacks and man-in-the-middle (MiTM) attacks, which aim at interrupting the communications between the RA entities [18]; even without altering the messages exchanged between the RA entities during the attestation processes, an adversary can launch a replay attack in an attempt to maintain trust [19]. The denial of service (DoS) attacks, which aim at flooding the verifier or the prover with excessive number of attestation requests, are also quite common [20]. Remote code execution (RCE) attacks have a considerable impact on the RA process, as they may lead to important RA configuration files being tampered with, e.g. concerning the directories to be excluded during the attestation process by the verifier [21]. Due to the high impact that these attacks achieve on O-RAN, their prevention should be of utmost importance [4]. III. O-RAN ATTACK SURFACE Representative attack vectors involving the core O-RAN components, extracted from [22], have been chosen to evaluate the effectiveness of the proposed framework. These vectors are illustrated in Fig. 1 and may be exploited from the location of the cloud operator, RAN operator, or an insider [9]. Starting from the O-RU, an attacker with access to Open FH can launch a DoS attack against the O-Cloud or the SMO. With unauthorized access to the Near-RT RIC an attacker can move laterally to the Non-RT RIC or to the E2 nodes. Control over RAN functions can lead to service degradation or information exposure for a subscriber/area/system, or data alteration on the A1, E2 interfaces. An attacker with access to the A1 interface may exploit vulnerable xApps/rApps; such vulnerabilities may be due to unsafe coding practices, untrusted or unmaintained sources, or from unused code/protocols. Having compromised the update package integrity (on the SMO prior to onboarding or the O-Cloud during instantiation) an attacker may trigger a downgrade attack to an older vulnerable version of a package or insert a backdoor to an open source O-RAN component. The underlying virtualization platform and the containers/ VMs of O-Cloud are also vulnerable. An attacker may exploit an overly-privileged container/VM and target the virtualization platform to bypass the O-Cloud defenses, reach the base hardware, and control other co-hosted containers/VMs. The latter exposes the O-Cloud to DoS attacks, information leakage, or backdoor installation. Access to the O2 interface also exposes other critical internal network services. Finally, from the SMO, an attacker could launch a DoS against the NFO/FOCOM to disrupt the administration of the O-RAN or against the SMO’s external and internal interfaces. Lateral movement towards OCloud could be facilitated by vulnerability exploitation, after which the attacker is able to mount a DoS against the O-Cloud infrastructure. O-RAN infrastructure DLT-EVA cloud Remote attestation service registration service protected database CLI REST APIs verification service agents sing/verify O-CLOUD VNF/CNF RoT DLT agent near-RT RIC xApp RA agents xApp xApp mgmt. virtualization layer O-CU O-DU SMO framework security DLT agent non-RT RIC rApp RA agents rApp rApp mgmt. O1 O2 Fig. 2: Securing O-RAN with remote attestation service and proof-of-integrity. IV. THE PROPOSED FRAMEWORK FOR O-RAN This section presents the proposed framework that includes remote attestation, log management, and auditing services as the core functions for O-RAN security. The attestation process enables zero trust by ensuring continuous verification of the infrastructure and the onboarding of trusted O-RAN components. On the other hand, log management and auditing service offers resilience against cyber-attacks, root cause analysis, and vendors’ accountability when malicious activities are detected. A. The attestation service The remote attestation services are responsible for validating the integrity of the O-RAN components, the RICs managed by the SMO, and the cloud resources. Therefore, the integrity of the O-RAN infrastructure is achieved by collecting attestation measurements from each system. The process is facilitated by a TPM that is used for the computation of the attestation responses (measurements). The TPM uses encryption, hashing and signing, key derivation functions (KDF) for secure key generation, and other cryptographic operations to ensure integrity [23]. In O-RAN’s infrastructure, attestation measurements are used for reliably verifying the security posture of O-RAN components that are provided by third-party vendors. The RA agent’s configuration, which includes cryptographic keys, certificates, IPs, ports, IDs, etc., is stored in a protected database by the registration service. As illustrated in Fig. 2, remote attestation services are used both at the SMO and the O-Cloud. The attestation process at the SMO aims to validate the integrity of critical O-RAN management functions, the network’s configurations, and the security policies. An RA agent is deployed at each rApp of the non-RT RIC to be attested; the attestation responses received periodically are compared against the functions’ clean state (when deployed at the SMO) and in case of mismatch, mitigation actions are orchestrated by the SMO in accordance with the security policies of O-RAN. On the other hand, the attestation process at the O-Cloud verifies that the underlying cloud resources, container images, virtual machines, and workloads have not been tampered with. The RA agents at the O-Cloud, which may rely on Kubernetes or OpenStack for managing the cloud resources and the workloads, establish a dynamic RoT for VNFs and other virtualized applications of O-RAN. Since different O-RAN deployment scenarios are possible [24], this impacts the deployment options for the RA agents, i.e. whether they are deployed at the regional or edge cloud of the mobile network operator (MNO). This mainly concerns the RA agents for attesting the O-Cloud and the xApps of the near-RT RIC; in contrast, the RA agents residing at the SMO framework are typically located at the MNO’s core network data centers or centralized cloud-based infrastructure (private or public cloud). The other components of the attestation service, namely the registration and verification services (depicted under the DLT-EVA cloud system), may be hosted by either the MNO or be provided as an external third-party system that enriches the SMO functionality [10]; in the former case, the attestation services are in the same trust domain with the rest of the O-RAN infrastructure, while they fall under different trust domains in the latter case, making the attestation process more complicated. In order to thwart advanced cyber-attacks against O-RAN, e.g. aiming at modifying virtual hosts’ boot process, DLT-EVA builds upon the ability of blockchain to act as a softwarized RoT and ensure the integrity of the information stored. Such information includes the attestation results and the attestation evidence about the virtualized functions that are critical for the resilient operation of O-RAN; the RA agents’ configuration and identity-based information are also safeguarded via the use of blockchain. By relying on TPM and blockchain, a hardwarerooted cryptographic trust chain for VNF/CNF is established, which is a prerequisite for secure onboarding onto the integrity protected O-RAN environment. B. O-RAN auditing service and log management To verify O-RAN systems’ robustness and traceability, a reliable mechanism is required to collect, preserve, and audit security logs. The disaggregation of O-RAN infrastructure, the virtualization of core network functions, and the utilization of open-source software components from third-party vendors, call for an extensive log management and auditing architecture, as illustrated in Fig. 3. The secure preservation of audit trails and logs is imperative for an effective incident response and the early detection of stealthy attacks against O-RAN [7]. The audit logs preserve information about security events generated by critical services of the O-RAN infrastructure (such as the O-RAN infrastructure log data log data O-CLOUD VNF/CNF logging VNF DLT agent near-RT RIC xApp logs xApp xApp mgmt. virtualization layer O-CU O-DU SMO framework logging agent DLT agent non-RT RIC rApp logs rApp rApp mgmt. O1 O2 DLT-EVA cloud auditing service UI REST APIs distributed log storage log monitoring and analytics Fig. 3: Securing O-RAN with tamper-proof auditing and log management. SMO-O-Cloud O2 services, O-Cloud software management service, and O-Cloud monitoring service) and various O-RAN components at the SMO and O-Cloud; see Section III. Such security logs are an important information source for analyzing security incidents against O-RAN. The types of logs that need to be preserved include [9]: •Application logs containing events that are generated by microservices, like the A1 mediator, the E2 manager, and the RIC message router (RMR). The O-RAN components can leverage the monitoring, orchestration, and logging capabilities of Kubernetes platform to simplify log aggregation from various log agents and increase visibility across the O-RAN infrastructure. •Security logs containing events from security services at the SMO, like extended detection and response (XDR) systems, rApp behavioral monitoring applications, and remote attestation services; they also incorporate security events from VNFs or xApps at the near-RT RIC, and OCU/O-DU, along with more typical security controls, like firewalls, authentication services, etc. •Infrastructure logs that include events generated by the O-Cloud (Kubernetes) and associated utilities for the automation/orchestration of containers, and security posture management; examples include KubeArmor, Kube-bench, Kube-hunter, Falco, and Helm, amongst others. Logs are often the target of stealthy attacks attempting to hide adversaries’ traces [25]. The integrity of such logs, which may include evidentiary material, must be ensured to retain O-RAN security posture. Current work in the literature focuses on the O-CLOUD virtualization layer platform/OS logs VNF/CNF DMS DMS DMS IMS logging VNF . . . DLT agent logger aggregator logger O-CU O-DU . . . RA agents Security xApp logs xAppxApp messaging infrastructure near-RT RIC A1O1 O2 SMO framework non-RT RIC . . . rApprApp NFO DLT agent FOCOM logging agent RA agents rApp logs messaging infrastructure log data agents sing/verify agents sing/verify log data DLT-EVA cloud Remote attestation service registration service protected database CLI REST APIs verification service auditing service UI REST APIs file system Fig. 4: A comprehensive architectural diagram of the proposed DLT-EVA framework for securing O-RAN infrastructure. design of centralized log management systems for O-RAN [8], [9], which however do not provide the required high-security assurance. The proposed framework utilizes a distributed log management infrastructure relying on blockchain technology to allow the secure preservation of audit logs and maintenance of a digital-chain-of-custody (DCOC). A log aggregator exists at both the SMO and the O-Cloud for collecting logs from the various log agents and filter the relevant security events. The collected logs are subsequently shipped to the auditing service so as to be securely stored, accessed, and visualized. Properly designed access control mechanism at the auditing service is in place for ensuring that logs can be accessed by authorized users only. The logs are collected by many different O-RAN components, and therefore their normalization at the auditing service (or even earlier) to a common format is required. The event attributes that should be provided at each log entry may include [7]: the time of the event generation; information about the O-RAN component that generated the log entry; and more details about the remote host that triggered the security event generation. C. Architectural overview and data flows The proposed framework is presented in more detail in Fig. 4; it relies on a variety of open-source software tools to realize the attestation and auditing services for O-RAN; these include: • Keylime 7.12.1 as the remote attestation tool; • Fluent Bit 3.2.0 as the log shipping tool; • Hyperledger Fabric 2.5.0 as the blockchain platform; • IPFS Kubo 0.23.0 as the distributed file system (this is a private version of IPFS for enhanced security); and • Hyperledger Firefly 1.3.2 as the core control trust plane for workflow coordination, log or attestation data routing, access control management, and the blockchain application governance. Furthermore, cAdvisor 0.52.1, Prometheus 3.2.1, Grafana 11.6.0, as well as, Node-exporter 1.3.1, are used to monitor the testbed’s containers performance. Keylime relies on the TPM 2.0 specification and consists of four main components: the agent, the registrar, the verifier, and the tenant. To be more precise, the agent is responsible for sending the measurements from the attester’s TPM to the verifier who decides on the attester’s integrity. This process is periodically repeated in accordance with the security policy. The registrar maintains agents’ data in a protected database, including identity, authentication data, and the cryptographic TPM keys used to sign the shared quotes. [26]. The tenant is responsible for adding and deleting agents and to immediately react to integrity deviations [27]; the tenant further provides the integrity verification criteria to the verifier, which are taken in account during the attestation scheduling process. Evidence from the attestation process could provide insights to forensic analysis regarding integrity violations, and is hence also stored on the distributed file-system for increased security; it is built on top of IPFS , which is a core component of the proposed security framework for O-RAN. The data stored on IPFS also include logs and alerts with a high value to the auditing process. These are shipped to IPFS and the blockchain from the O-RAN logging agents by using Fluent Bit ; they are delivered via Hyperledger Firefly , which acts as the middleware API gateway and orchestrator. Once data are stored on IPFS , the returned hash along with the corresponding metadata are likewise sent to the blockchain platform via Hyperledger Firefly . The blockchain is built on-top of Hyperledger Fabric that is a permissioned and Attacker Tenant Agent Verifier Establish connection via CVE-2025-32433 a lt [Excludelist file does not exist] [Excludelist file exists] Create new excludelist file Add directory to excludelist Read excludelist file Excluded directories Deploy malware to excluded directory Request attestation Send TPM quote Malware exists in an excluded directory Compare against expected values Accept attestation Malware is undetected Fig. 5: Attacking the remote attestation process. private platform [28]. Although it is not illustrated in Fig. 4, the alerts generated across the O-RAN infrastructure are also aggregated by a security information and event management (SIEM) platform for real-time analysis and mitigation. These alerts include runtime information about rApps/xApps, along with process names, command-line arguments, syscall names (e.g. rApps attempting to established an unauthorized TCP connection by using the tcp_connect() syscall), user IDs, and IP addresses, amongst others. V. ATTACKING AND DEFENDING THE RA PROCESS Remote attestation is a critical part of the proposed framework, and can therefore become the target of cyber-attacks; if compromised, this may render untrusted the whole O-RAN infrastructure. An attack is presented next against the remote attestation service, in which the newly discovered vulnerability CVE-2025-32433 is exploited [29]. This CVE concerns a vulnerability in the Erlang/OTP library and its SSH protocol implementation that allows adversaries to perform a remote code execution (RCE) attack. Such attacks can be detrimental to the RA service, since they can lead to unauthorized access and modification of the tenant’s exclude_list file, where directories that are excluded from the attestation process are maintained. Therefore, an attacker can add malicious software to the RA agents’ excluded directories, aiming at launching various other attacks to tamper with the attestation responses or disrupting the attestation service via DoS attacks. Typical operating system’s directories that could be excluded from the attestation process include /proc,/tmp, and /var/log as their contents are continuously changing, and therefore false positives due to attestation deviations need to be avoided. This approach is quite common and is also supported by Keylime implementation. As presented in Fig. 5, the attack starts with an attempt to establish an SSH connection with the tenant’s host using an exploit implementing the vulnerability CVE-2025-32433. After having established a connection, a malicious code is executed to get remote access to the tenant’s exclude_list, leading to two variants of the attack. In the first variant, the list of excluded directories does not exist and thus the attacker needs to create a new exclude_list file at the tenant before the malicious software is added to the agent’s targeted excluded directory. In the second variant, the list of excluded directories already exists at the tenant, and the attacker only needs read access to the exclude_list file in order to decide the agent’s directory in which the malicious software will be added [21]. In both cases, when the attestation process is initiated and the TPM quote is requested from the compromised agent, its attestation response is generated excluding the directory where the malicious software resides, which goes undetected. (a) Execution of the CVE-2025-32433 exploit. (b) Tampered exclude_list file. Fig. 6: Execution details of the attack on the remote attestation system. Fig. 6 illustrates steps of the attack that exploits the above mentioned vulnerability. In Fig. 6a, the attacker executes the proof of concept (PoC) script to establish a connection with the victim’s SSH server, whereas Fig. 6b presents the result of the attack, where the exclude_list file has been successfully modified and a target directory has been added to the list. As such attacks are simple examples of exploiting RA hosts, it is suggested that for the secure operation of remote attestation services, the integrity of the critical configuration files of the attestation process itself is also safeguarded. In the DLT-EVA framework, this is achieved by adding an extra security layer and storing such RA files on the IPFS distributed file system while using Hyperledger Fabric for integrity verification. However, this proactive security approach only prevents the first variant of the attack, where the adversary creates/modifies the contents of the exclude_list file; the second variant is more stealthy and cannot be detected via integrity verification approaches. Instead, other security controls, such as firewalls, intrusion detection systems, etc., need to be in place in order to prevent the RA hosts’ exploitation in the first phase of the cyber-attack. VI. CONCLUSIONS This paper introduced a blockchain-enabled framework for increased security in O-RAN infrastructures; it is comprised of two primary services, namely remote attestation and auditing, which aim at supporting a zero-trust approach in disaggregated multi-stakeholder deployments. The remote attestation ensures that the infrastructure is continuously verified with only trusted components participating in its operation, whereas the auditing service offers resilience against cyber-attacks, accountability, and ability for root cause analysis for cyber-security incidents in O-RAN. Future work focuses on validating the proposed framework in realistic O-RAN testbeds and the precise design and implementation of the agents (or extension of the existing ones), so as to fully meet the security requirements of future O-RAN infrastructures. REFERENCES [1] Z. A. E. Houda, H. Moudoud, and B. Brik, “Federated deep reinforcement learning for efficient jamming attack mitigation in O-RAN,” IEEE Transactions on Vehicular Technology, vol. 73, no. 7, pp. 9334–9343, 2024. [2] M. Polese, L. Bonati, S. D’Oro et al., “Understanding O-RAN: Architecture, interfaces, algorithms, security, and research challenges,” IEEE Communications Surveys & Tutorials, vol. 25, no. 2, pp. 1376–1411, 2023. [3] C.-F. Hung, Y.-R. Chen, C.-H. Tseng et al., “Security threats to xApps access control and E2 interface in O-RAN,” IEEE Open Journal of the Communications Society, vol. 5, pp. 1197–1203, 2024. [4] P. Kuure, “Security and trust in open RAN,” Master’s Thesis, Department of Information Technology, Cybersecurity, South-Eastern Finland University of Applied Sciences, 2024. [5] P. Porambage, M. Christopoulou, B. Han et al., “Security, privacy, and trust for open radio access networks in 6G,” IEEE Open Journal of the Communications Society, vol. 6, pp. 332–361, 2025. [6] M. Ammar, B. Crispo, and G. Tsudik, “SIMPLE: A remote attestation approach for resource-constrained IoT devices,” in 2020 ACM/IEEE 11th International Conference on Cyber-Physical Systems (ICCPS), 2020, pp. 247–258. [7] O-RAN Working Group 11, “Study on security log management,” ORAN Alliance, Tech. Rep. v5.00.03, Feb. 2025. [8] T.-H. Wang, Y.-C. Chen, S.-J. Huang et al., “Design of a network management system for 5G open RAN,” in 2021 22nd Asia-Pacific Network Operations and Management Symposium (APNOMS), 2021, pp. 138–141. [9] H. Wittemeier, T. Karl, A. J. Dieterich et al., “Digital forensics and incident response (DFIR) in O-RAN implementations,” in Mobilkommunikation; 28. ITG-Fachtagung, 2024, pp. 25–30. [10] O-RAN Working Group 1, “O-RAN architecture description,” O-RAN Alliance, Tech. Rep. v13.00, Feb. 2025. [11] S. Brotsis, K. P. Grammatikakis, D. Kavallieros et al., “Blockchain meets internet of things (IoT) forensics: A unified framework for IoT ecosystems,” Internet of Things, vol. 24, p. 100968, 2023. [12] Z. A. El Houda, H. Moudoud, and L. Khoukhi, “Blockchain meets o-ran: A decentralized zero-trust framework for secure and resilient o-ran in 6g and beyond,” in IEEE INFOCOM 2024 - IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), 2024, pp. 1–6. [13] F. Javed, J. Mangues-Bafalluy, E. Zeydan et al., “Trustworthy reputation for federated learning in o-ran using blockchain and smart contracts,” IEEE Open Journal of the Communications Society, vol. 6, pp. 1343– 1362, 2025. [14] E. Dushku, M. M. Rabbani, J. Vliegen et al., “PROVE: Provable remote attestation for public verifiability,” Journal of Information Security and Applications, vol. 75, p. 103448, 2023. [15] B. Kuang, A. Fu, W. Susilo et al., “A survey of remote attestation in Internet of things: Attacks, countermeasures, and prospects,” Computers & Security, vol. 112, p. 102498, 2022. [16] Z. Sha, C. Shepherd, A. Rafi et al., “Control-flow attestation: Concepts, solutions, and open challenges,” Computers & Security, vol. 150, p. 104254, 2025. [17] P. Kuure, “Security and trust in open ran,” Master’s thesis, Xamk University of Applied Sciences, Kouvola, Finland, 2024, available online at: https://www.theseus.fi/bitstream/handle/10024/857344/Kuure Pekka.pdf. [18] W. A. Johnson, S. Ghafoor, and S. Prowell, “A taxonomy and review of remote attestation schemes in embedded systems,” IEEE Access, vol. 9, pp. 142 390–142 410, 2021. [19] H. Tan, G. Tsudik, and S. Jha, “MTRA: Multi-tier randomized remote attestation in IoT networks,” Computers & Security, vol. 81, pp. 78–93, 2019. [20] C. Kil, E. C. Sezer, A. M. Azab et al., “Remote attestation to dynamic system properties: Towards providing complete system integrity evidence,” in 2009 IEEE/IFIP International Conference on Dependable Systems & Networks, 2009, pp. 115–124. [21] D. G. Berbecaru and S. Sisinni, “Counteracting software integrity attacks on IoT devices with remote attestation: a prototype,” in 2022 26th International Conference on System Theory, Control and Computing (ICSTCC), 2022, pp. 380–385. [22] O-RAN Working Group 11, “O-RAN security threat modeling and risk assessment,” O-RAN Alliance, Tech. Rep. v5.00, Feb. 2025. [23] S. P. Rao, G. Limonta, and J. Lindqvist, “Usability and security of trusted platform module (TPM) library APIs,” in Eighteenth Symposium on Usable Privacy and Security (SOUPS 2022). USENIX Association, Aug. 2022, pp. 213–232. [24] O-RAN Working Group 6, “Cloud architecture and deployment scenarios for O-RAN virtualized RAN,” O-RAN Alliance, Tech. Rep. v08.01, Feb. 2025. [25] L. Cazorla, C. Alcaraz, and J. Lopez, “Cyber stealth attacks in critical information infrastructures,” IEEE Systems Journal, vol. 12, no. 2, pp. 1778–1792, 2018. [26] A. Mosayyebzadeh, A. Mohan, S. Tikale et al., “Supporting security sensitive tenants in a bare-metal cloud,” in 2019 USENIX Annual Technical Conference (USENIX ATC 19). USENIX Association, Jul. 2019, pp. 587–602. [27] N. Schear, P. T. Cable, T. M. Moyer et al., “Bootstrapping and maintaining trust in the cloud,” in Proceedings of the 32nd Annual Conference on Computer Security Applications. Association for Computing Machinery, 2016, p. 65–77. [28] S. Brotsis, N. Kolokotronis, K. Limniotis et al., “On the security and privacy of Hyperledger Fabric: Challenges and open issues,” in 2020 IEEE World Congress on Services (SERVICES), 2020, pp. 197–204. [29] CVE-2025-32433, “Erlang/OTP SSH vulnerable to pre-authentication RCE,” The MITRE Corporation, Apr. 2025.