{"id":"4c7f5163-4e60-44f7-8400-d31ca5a98d70","arxiv_id":"2509.03000","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A TPM-backed Trusted Reporter in the O-RU and a Proof Repository Hub in the SMO produce Merkle-tree-based, tenant-verifiable evidence of runtime configuration and control state at about 200ms per cycle.","lead":"This paper describes a monitoring framework for shared Open RAN networks that uses trusted hardware to attest radio unit configuration and control behavior. It targets roughly 200ms per monitoring cycle and aims to give mobile operators verifiable evidence that shared infrastructure is following their policies.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Signed reports attest only what the TR is told: a compromised host can feed sanitized configuration while enforcing malicious state, so the claimed tamper-resistance under host compromise is unsubstantiated even with a TEE.","rationale":"The reader's weakest assumption correctly identifies that the TPM-only prototype cannot protect the TR's runtime execution and evidence path. My concern sharpens this: even moving the TR into a TEE does not solve the problem, because the TR's inputs—the configuration files and 'secure memory interfaces'—are provided by the same untrusted host. The attestation root only vouches for the data the TR was given; there is no designated verifier channel from the actual O-RU enforcement point to the TR. This is not a mere implementation gap but a design gap in the paper's central security claim. However, the paper has real strengths: the Merkle-tree reporting and proof-based verification are sound, the latency evaluation is plausible, and the framework could be repurposed as a compliance-monitoring tool under a weaker threat model where the TR is physically or logically isolated. Therefore the appropriate verdict is CONDITIONAL, requiring a demonstrated trusted path from O-RU state to the TR, not just TEE integration. I partially agree with the reader because they mentioned the evidence collection path but treated TEE as the fix, whereas TEE alone is insufficient.","tokens_in":15371,"tokens_out":5566,"duration_ms":66616,"concrete_test":"Run an adversarial experiment on a real O-RU controller with the TR in an SGX enclave and a root-compromised host. Have the attacker (1) change the actual enforced MACsec state and beamforming parameters, and (2) feed the enclave the original startup-config.xml/running-config.xml plus fabricated runtime fields. Check whether the enclave's signed Merkle root matches the tenant's expected values. If it matches, the framework reports compliance while the O-RU is non-compliant, directly falsifying the compromised-host guarantee.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The central claim (Section I, Design Overview) is that monitoring and reporting remain tamper-resistant even with a compromised host. The prototype (Section V) uses only a software TPM, which protects the attestation key but not the TR's execution or inputs; Section VI concedes that runtime tamper protection needs a TEE. But the deeper problem is that even a TEE does not protect the evidence collection path. The TR obtains O-RU state by reading NETCONF datastores (Section IV-A1) and 'secure memory interfaces' from the O-RU controller (Section IV-A2). If the host or O-RU software is compromised, it can supply the TR with a sanitized <running> datastore or fabricated beam/band IDs while actually enforcing malicious settings. The Merkle root is signed over whatever evidence the TR assembles; verification (Section IV-B4) only checks that the root matches expected values, so a report over sanitized data validates. The threat model (Section III-B) explicitly refuses to trust the host OS, but the design provides no mechanism binding the attested evidence to the actual enforced state. Thus the signed report is a signature over attacker-chosen data in exactly the scenario the paper claims to resist. The Merkle-tree construction and incremental update algorithms (Algorithms 3–4) are correct but orthogonal to this gap.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes a monitoring framework for Open RAN deployments in which tenants do not fully trust the infrastructure operator. A Trusted Reporter (TR) co-located with the O-RU controller collects configuration and selected control-plane/synchronization evidence from the M-, C-, and S-planes, hashes this evidence into a Merkle tree, and signs the root with a TPM-protected attestation key. The signed report is stored in a Proof Repository Hub (PRH) at the SMO layer, where tenants verify the signature and Merkle commitment and, if needed, trigger remediation. The authors implement a prototype using the O-RAN Software Community's sim-o1-ofhmp-interfaces simulator, Netopeer2, and a software TPM (swtpm), and report roughly 200 ms total processing latency per monitoring cycle, scaling to about 300 ms with 100 evidence items. The central claim is that this design provides tamper-resistant monitoring and reporting even when the host is compromised.","tokens_in":15682,"tokens_out":5633,"duration_ms":69101,"significance":"The problem addressed is timely and relevant: current O-RAN ZTA efforts largely stop at authentication/authorization, while tenants in shared deployments have no verifiable visibility into O-RU configuration and control behavior. The paper's core building blocks—Merkle-tree evidence aggregation, incremental updates, and signed root reporting—are simple and appropriate for the stated monitoring goal, and the prototype is concrete and reproducible. If the security claims are properly scoped, the latency numbers are useful for judging deployability at Non-RT RIC timescales. However, the paper's headline guarantee ('tamper-resistant even in the presence of a compromised host') is not supported by the design as presented: the evidence collection path is in untrusted software, the evaluation uses only a software TPM emulator, and the verifier does not check the reported platform measurement. These issues are load-bearing rather than cosmetic, so the manuscript needs major revision before the central claim can be accepted.","major_comments":[{"comment":"The threat model in §III-B explicitly refuses to trust the host OS or hypervisor, and Section I claims that 'monitoring and reporting remain tamper-resistant, even in the presence of a compromised host.' In the implemented design, however, the TR is a standalone Python process running in the host OS, and only the attestation key is protected by a TPM. Section VI concedes that runtime tamper protection requires a TEE. More fundamentally, even with a TEE, the evidence collection path described in §IV-A1–A2 reads NETCONF datastores and 'secure memory interfaces' through the O-RU software stack. A compromised host can supply sanitized <running> datastores, fabricated Beam IDs, or false synchronization indicators; the TPM/TEE signs the Merkle root over whatever evidence the TR assembles. Verification in §IV-B4 only checks the signature and Merkle reconstruction, not the authenticity of the in","section":"Section I; Section III-B; Section IV-A; Section VI"},{"comment":"The evaluation uses swtpm, a software TPM emulator, not a hardware TPM or TEE. Table III's 139.2 ms report-generation cost and 59.6 ms verification cost therefore characterize an emulator, not the 'hardware-rooted' attestation the design promises. Hardware TPM I/O latencies and RSA signing performance can differ substantially from swtpm, so the claimed approximately 200 ms total latency may not transfer to O-RU hardware. More importantly, the security claim cannot be validated with an emulated root of trust. Either the evaluation should be repeated with a real TPM/TEE, or the hardware-rooted terminology should be dropped.","section":"Section V-A; Table III"},{"comment":"Algorithm 1 includes platform_id in the signed report, but the verification procedure in §IV-B4 never checks platform_id against a known-good PCR or MRENCLAVE value. Without an authenticated comparison of platform_id to an expected measurement, the report does not give tenants evidence that the correct TR binary or monitoring code was actually loaded and executed. The paper claims in §III-B that platform measurements provide assurance of integrity, but the described verification flow omits this step, leaving a gap between the integrity claim and the implemented verifier.","section":"Section IV-B4; Algorithm 1"},{"comment":"The scalability result in Figure 4(b) shows total processing time rising from about 200 ms at 50 evidence items to about 300 ms at 100 items. The text attributes this trend to 'signing latency during report generation at the TR,' but TPM-backed signing of a single Merkle root is a fixed-cost operation independent of the number of leaves. This is inconsistent with Table III, where total time is the sum of a 1.3 ms Merkle computation, 139.2 ms signing, and 59.6 ms verification. If the experiment instead generates one report per evidence item, that is a different protocol from the single-root description. The authors should clarify the measurement methodology and re-assess the scalability claim.","section":"Section V-C; Figure 4(b)"}],"minor_comments":[{"comment":"Table III reports a fixed 50-file configuration, while Figure 4 varies evidence items from 1 to 100. State clearly whether the Table III row corresponds to 50 items and why the total in Table III is exactly the sum of the three components while Figure 4(b) reaches 300 ms.","section":"Section V-B; Table III vs. Figure 4"},{"comment":"Algorithm 1 generates a nonce, but Algorithm 2's trigger logic does not show how the nonce is maintained across periodic and event-driven reports. Specify the nonce lifecycle to make the replay-protection argument concrete.","section":"Algorithm 1; Algorithm 2"},{"comment":"The term 'secure memory interfaces provisioned by the O-RU software' is vague. Please specify the concrete O-RU API, memory region, or vendor interface that provides Beam IDs and sync indicators to the TR; this is also relevant to the input-authenticity concern in the major comments.","section":"Section IV-A2"},{"comment":"The sentence 'This method guarantees that configuration changes are both authorized and tamper-evident' uses 'authorized' without a definition. The protocol detects deviations from expected hashes; it does not itself determine whether a change was authorized by the tenant or SMO. Please rephrase or define the authorization model.","section":"Section IV-B"},{"comment":"The caption and figure mention 'MSC/UMS' without defining the acronym. Please expand or remove it.","section":"Figure 2"}],"recommendation":"major_revision","confidential_remarks":"The decisive issue is the evidence-collection path: even a TEE would not make the signed root meaningful if the untrusted host controls the data that the TR hashes. I would ask the authors to either narrow the threat model to 'trusted evidence collection by a protected TR' or add an explicit mechanism that binds the attested evidence to the actual enforced state of the O-RU. Also, the security evaluation with swtpm cannot support a hardware-root-of-trust claim; a real TPM/TEE evaluation (or a clear statement that security is argued by design rather than demonstrated) is needed. The paper has a useful monitoring architecture and a working prototype; with honest scoping it could become a solid contribution."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"This paper applies TPM-backed Merkle-tree attestation to O-RU configuration and control-state monitoring, and that is a legitimate new application of known primitives. The problem is real: in multi-tenant O-RAN, tenants have no way to verify that a shared O-RU is actually enforcing their slice policies. The Trusted Reporter / Proof Repository Hub split is coherent, and the decision to monitor M/C/S-plane state via NETCONF/YANG is well motivated. The Merkle tree construction and incremental updates are standard and correct. The prototype, though run on a simulator with a software TPM, produces plausible latency numbers around 200 ms. I also see no circularity or fitting problem: the verification logic is a straightforward recomputation of the root and comparison with the signed value.\n\nThe soft spot is the security claim. The introduction and design overview say monitoring and reporting remain tamper-resistant even when the host is compromised. That is not achieved. The TR obtains its evidence from NETCONF datastores and from \"secure memory interfaces\" that are controlled by the same O-RU software stack the threat model refuses to trust. If that stack is compromised, it can feed the TR sanitized configuration and fabricated beam or band IDs while enforcing something else. The signed Merkle root is a signature over whatever evidence the TR was given. Section VI acknowledges that a TEE is needed for runtime tamper protection, but a TEE only protects the TR's code, not the input path. Without a hardware-rooted channel from the actual RF state to the attestation logic, the claimed guarantee under host compromise is unsubstantiated. The evaluation also has no error bars, no baselines, and no real O-RU hardware; the software TPM dominates the 200 ms figure, and a hardware TPM could behave differently. Those are normal prototype limitations, but they do not support the strength of the stated claim.\n\nWhat the paper does well is scope out the problem and provide a first cut at a solution. The related work is appropriate and the self-limitations in Section VI are honestly stated. I would send this to peer review, because the problem matters and a serious referee could push the authors to either weaken the threat model or show how the evidence-collection path can be hardened. But I would not accept it as is. The authors should reframe the contribution as tamper-evident configuration reporting under a more modest threat model, and ideally evaluate with a hardware TPM and a real O-RU control interface. For readers working on O-RAN security or attestation-based monitoring, this is worth a look; for my own work, I would not cite it in its current form.","headline":"Sensible monitoring design with a working prototype, but the central claim of tamper-resistance under host compromise is not supported by the design or the evaluation.","tokens_in":16159,"tokens_out":2706,"would_cite":false,"duration_ms":31816,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper claims that a TPM-anchored Trusted Reporter signing Merkle roots of O-RU configuration and control-plane state can give Open RAN tenants verifiable, tamper-evident oversight of radio behavior in shared deployments, at about 200 ms","keywords":["Open RAN security","runtime attestation","Trusted Platform Module","Merkle tree","zero trust","O-RU monitoring","NETCONF/YANG","tenant policy compliance"],"falsifier":"Compromise the host OS of the prototype after boot, modify the running Trusted Reporter to hash an attacker-chosen configuration file instead of the real one, and have it sign the result; if the tenant's verification accepts the report as genuine, the claim of tamper resistance under a compromised host is refuted.","tokens_in":15297,"feed_emoji":"📡","tokens_out":8996,"duration_ms":92047,"temperature":0.7,"pith_summary":"Open RAN's zero-trust security model stops at the boundary: once a component authenticates, it is assumed to keep behaving, so a misconfigured or compromised radio unit can silently violate tenant policy. This paper argues that shared and vendor-managed deployments need a way to verify what the radio is actually doing, not just who was allowed to talk to it. The proposed framework puts a hardware-anchored Trusted Reporter inside the O-RU controller, hashes configuration and control-plane state into a Merkle tree, and signs the root with a TPM-protected key. A tenant-visible Proof Repository Hub at the SMO stores the signed reports, letting tenants check for unauthorized changes and trigger remediation. A prototype using standard O-RAN NETCONF/YANG models measures roughly 200 ms per attestation cycle, which the authors say fits non-real-time RIC timescales and makes the approach practical.","feed_headline":"TPM-signed Merkle roots make O-RAN radios auditable in ~200 ms","feed_subtitle":"A hardware-anchored reporter signs Merkle roots of O-RU state, so shared tenants can audit without trusting the host.","key_machinery":"The Trusted Reporter (TR) is the central component: a hardware-anchored monitor that lives inside the O-RU controller and produces tamper-evident attestation reports. Its signing key is held by a TPM (or TEE), and it hashes a defined set of evidence items from the M-, C-, and S-planes into a Merkle tree. The Merkle tree is the load-bearing data structure: it compresses arbitrarily many evidence items into a single 256-bit root, allows incremental updates by recomputing only affected leaf-to-root paths, and supports Merkle proofs so a tenant can verify one field (e.g., macsec-enabled=true) without receiving all configuration data. The Proof Repository Hub (PRH), deployed as an rApp at the SMO","core_discovery":"Central claim: O-RAN operations can be made tenant-verifiable without trusting the host OS, hypervisor, or vendor software stack. A Trusted Reporter inside the O-RU controller, anchored by a TPM attestation key, hashes evidence items—NETCONF datastore subtrees, MACsec/IPsec and PTP settings, KPM telemetry config, firmware version, its own binary hash, and selected runtime fields—into a Merkle tree and signs the root with timestamp, nonce, and platform measurement. Tenants reconstruct the tree, verify the signature, and can inspect single fields via Merkle proofs. With about 50 standardized O-RAN config files, the prototype totals roughly 200 ms per attestation cycle, shifting trust from stat","pith_inferences":["Inference: the same Merkle-root reporting pattern could be applied to other RAN components (O-DU, O-CU, xApps) with their own evidence sets; the paper motivates this but only implements and evaluates it for the O-RU.","Inference: if the Trusted Reporter were hosted in a real TEE rather than the prototype's software TPM, the runtime-isolation gap identified in Section VI would shrink; a natural test is measuring the latency penalty of SGX or TrustZone on an actual O-RU-class device.","Inference: the current checks compare hashes to expected values, so policies are equality constraints; a future extension could let the PRH evaluate richer tenant-defined conditions (ranges, thresholds, cross-field invariants) over the attested evidence.","Inference: the ~200 ms cycle time means the framework is aimed at non-real-time RIC timescales; real-time C-plane enforcement would need a different, much lighter mechanism, which the paper does not claim."],"forward_implications":["Tenants in shared or neutral-host deployments can detect silent configuration drift and unauthorized control changes at the O-RU without needing administrative access to the device.","A signed Merkle root per monitoring cycle yields a compact, non-repudiable audit trail that supports post-incident forensics and compliance reporting across multi-operator environments.","Incremental Merkle updates keep overhead low as the number of attested evidence items grows; the paper measures under 2.5 ms for root computation at 100 items.","Field-level verification lets tenants check a single policy-critical item, such as fronthaul encryption status, without transferring the whole configuration set.","Detected violations can be acted on through the SMO, e.g., revoking trust in the O-RU or rerouting traffic, closing the loop between attestation and operational control."],"supporting_citations":[{"why":"Defines the O-RAN zero-trust architecture whose post-authentication compliance gap the paper targets.","marker":"[4]"},{"why":"Analyzes shared O-RU security and motivates tenant visibility at the cell edge.","marker":"[7]"},{"why":"Shows unprotected fronthaul allows silent RF manipulation, motivating runtime configuration attestation.","marker":"[14]"},{"why":"Mandates trusted hardware (TPM/TEE) in O-RAN O-Cloud, grounding the hardware root of trust.","marker":"[26]"},{"why":"Specifies the M-plane NETCONF/YANG models the Trusted Reporter hashes as evidence.","marker":"[28]"},{"why":"Supplies the tamper-evident Merkle logging structure the attestation reports are built on.","marker":"[57]"},{"why":"Introduces Merkle-tree proofs used for field-level tenant verification.","marker":"[58]"}],"fun_headline_variants":["O-RAN gets a TPM trust anchor for 200-ms tenant audits","Merkle-root attestation audits O-RAN in ~200 ms","Hardware-anchored O-RAN monitoring: prove config without trust","TPM-signed Merkle proofs verify O-RAN states fast","Low-trust O-RAN? This framework verifies in 200 ms"],"cache_read_input_tokens":2688,"weakest_assumption_plain":"The Trusted Reporter's own code and its view of the configuration must stay correct and unaltered after boot; if a compromised host can change what the reporter reads or executes, the signed Merkle root only certifies the attacker's chosen state.","fun_headline_variants_meta":{"raw":{"variants":["O-RAN gets a TPM trust anchor for 200-ms tenant audits","Merkle-root attestation audits O-RAN in ~200 ms","Hardware-anchored O-RAN monitoring: prove config without trust","TPM-signed Merkle proofs verify O-RAN states fast","Low-trust O-RAN? This framework verifies in 200 ms"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000664,"raw_usage":{"total_tokens":2870,"prompt_tokens":748,"completion_tokens":2122,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":492,"completion_tokens_details":{"reasoning_tokens":2024}},"tokens_in":492,"tokens_out":2122,"duration_ms":17115,"temperature":1.0,"reasoning_tokens":2024,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-05T11:12:46.177132+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Compromise the host OS of the prototype after boot, modify the running Trusted Reporter to hash an attacker-chosen configuration file instead of the real one, and have it sign the result; if the tenant's verification accepts the report as genuine, the claim of tamper resistance under a compromised host is refuted.","supporting_citations":[{"cited_title":"Zero trust architecture for secure o-ran,","cited_arxiv_id":null,"evidence_quote":"Defines the O-RAN zero-trust architecture whose post-authentication compliance gap the paper targets."},{"cited_title":"O-ran wg11 shared o-ru security analysis,","cited_arxiv_id":null,"evidence_quote":"Analyzes shared O-RU security and motivates tenant visibility at the cell edge."},{"cited_title":"On the criticality of integrity protection in 5g fronthaul networks,","cited_arxiv_id":null,"evidence_quote":"Shows unprotected fronthaul allows silent RF manipulation, motivating runtime configuration attestation."},{"cited_title":"O-RAN O-Cloud Architecture and Requirements Specification,","cited_arxiv_id":null,"evidence_quote":"Mandates trusted hardware (TPM/TEE) in O-RAN O-Cloud, grounding the hardware root of trust."},{"cited_title":"ETSI TS 104 023 V12.0114.0, 2024","cited_arxiv_id":null,"evidence_quote":"Specifies the M-plane NETCONF/YANG models the Trusted Reporter hashes as evidence."},{"cited_title":"Efficient data structures for tamper- evident logging.,","cited_arxiv_id":null,"evidence_quote":"Supplies the tamper-evident Merkle logging structure the attestation reports are built on."},{"cited_title":"A digital signature based on a conventional encryption function,","cited_arxiv_id":null,"evidence_quote":"Introduces Merkle-tree proofs used for field-level tenant verification."}],"review_version":1}