Pith. sign in

REVIEW 4 major objections 5 minor 58 references

Closing the Visibility Gap: A Monitoring Framework for Verifiable Open RAN Operations

T0 review · 4 major / 5 minor · reviewed 2026-08-05 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read 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

desk verdict 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. read the letter →

arxiv 2509.03000 v1 pith:K2PNNGZ6 submitted 2025-09-03 cs.NI cs.CR

Hexuan Yu , Md Mohaimin Al Barat , Yang Xiao , Y. Thomas Hou , Wenjing Lou This is my paper · ORCID
classification cs.NIcs.CR
keywords OpenRANsecurityruntimeattestationTrustedPlatformModuleMerkletreezerotrustO-RUmonitoringNETCONF/YANGtenantpolicycompliance
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

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.

What carries the argument

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

What would settle it

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.

Watch

Extended reading notes

Core claim

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

Load-bearing premise

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.

Editorial extensions

If this is right

  • 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.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • 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.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

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.

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 (4)
  1. [Section I; Section III-B; Section IV-A; Section VI] 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
  2. [Section V-A; Table III] 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.
  3. [Section IV-B4; Algorithm 1] 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.
  4. [Section V-C; Figure 4(b)] 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.
minor comments (5)
  1. [Section V-B; Table III vs. Figure 4] 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.
  2. [Algorithm 1; Algorithm 2] 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.
  3. [Section IV-A2] 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.
  4. [Section IV-B] 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.
  5. [Figure 2] The caption and figure mention 'MSC/UMS' without defining the acronym. Please expand or remove it.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the framework's verification is a direct hash-commitment construction; the acknowledged security gap is a scope limitation, not a circular step.

full rationale

The paper's derivation chain is: collect evidence → hash into a Merkle tree → sign the root with a TPM-protected key → transmit to the PRH → verify by recomputing the Merkle root from the evidence and checking the signature. This is a direct application of hash-commitment semantics: the root is defined as the Merkle hash of the evidence, so root-equality is equivalent to evidence-equality by construction. That equivalence is the intended meaning of the construction, not a masked fit or redefinition of the claimed result. No parameters are fitted to data and then presented as predictions; the 200 ms figure is a measured latency of a prototype, not a predicted quantity derived from fitted inputs. The only self-citations (refs [33]-[42] in related work; ref [56] as an optional RTOS attestation mechanism) are not load-bearing: nothing in the central verification or threat-model argument reduces to an unverified claim from the authors' prior work. The evaluation is self-referential in that the prototype is measured against its own implementation, but that is standard prototype evaluation, not circular reasoning; lack of validation on real O-RU hardware is a scope limitation, not a logical circle. Two passages undercut the strongest claim and are worth flagging: Section VI admits that runtime tamper protection requires a TEE ('For deployments requiring stronger protection against runtime tampering, the TR can be hosted within a TEE...') and the 'Integrity Assurance vs. Runtime Coverage' paragraph concedes that attesting configurations and selected runtime elements 'cannot fully capture the complexity of live system execution.' These indicate that the Design Overview's assertion of tamper-resistance under a compromised host ('This ensures that monitoring and reporting remain tamper-resistant, even in the presence of a compromised host') is stronger than what the implementation demonstrates. That is a security-correctness gap—the evidence-collection path may be attacker-controlled—not circularity: the signed Merkle root is a signature over whatever evidence the TR assembles, and verification checks only that the root matches that evidence. The architecture is self-consistent as a tamper-evident reporting channel, but its end-to-end guarantee depends on the untested assumption that the TR and its inputs are not themselves subverted. No step in the paper's reasoning defines its conclusion into its premises.

Assumptions & free parameters 0 free parameters · 5 assumptions · 2 invented entities

The framework introduces two software components (TR and PRH) but no physical entities. The central assumptions are vendor cooperation in exposing O-RU internals, availability of hardware-rooted trust, and the runtime integrity of the TR itself, which is not met by the prototype.

assumptions (5)
  • domain assumption The O-RU controller exposes C-plane and S-plane runtime states to the Trusted Reporter via secure memory interfaces.
    Used in Section IV-A2 for C-plane monitoring; not validated against any real O-RU vendor implementation.
  • domain assumption A hardware root of trust (TPM or TEE) is available and provisioned on O-RUs as mandated by O-RAN and 3GPP.
    Cited in Section I (refs [4], [26], [27]); basis for the anchor trust of the framework.
  • domain assumption The Trusted Reporter remains unmodified and correctly collects evidence at runtime under a compromised host.
    Required by the threat model (Section III-B) and claimed in Section I; the prototype does not satisfy this without a TEE (Section VI).
  • domain assumption The simulator configuration from sim-o1-ofhmp-interfaces is representative of real O-RU production configuration.
    Evaluation in Section V-A uses this simulator; no real O-RU hardware test is performed.
  • domain assumption Tenants know or are given the expected static configuration values to re-verify hashes, and dynamic values are sent in plaintext.
    Verification logic in Section IV-B4 depends on this assumption.
invented entities (2)
  • Trusted Reporter (TR) independent evidence
    purpose: Co-located with the O-RU controller, collects evidence items, builds a Merkle tree, and signs the root with a TPM-backed key.
    Implemented as a standalone Python app in the prototype; security depends on TPM and ideally a TEE.
  • Proof Repository Hub (PRH) independent evidence
    purpose: Stores signed attestation reports from TRs and serves as a tenant-visible immutable audit trail for verification.
    Also implemented as a standalone Python app; its own TEE anchoring is assumed.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Closing the Visibility Gap: A Monitoring Framework for Verifiable Open RAN Operations." pith.science (2026). https://pith.science/paper/K2PNNGZ6

@misc{pith2026250903000,
  author       = {Pith},
  title        = {Pith review of: Closing the Visibility Gap: A Monitoring Framework for Verifiable Open RAN Operations},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/K2PNNGZ6}},
  note         = {Machine review of arXiv:2509.03000}
}
read the original abstract

Open Radio Access Network (Open RAN) is reshaping mobile network architecture by promoting openness, disaggregation, and cross-vendor interoperability. However, this architectural flexibility introduces new security challenges, especially in deployments where multiple mobile network operators (MNOs) jointly operate shared components. Existing Zero Trust Architectures (ZTA) in O-RAN, as defined by governmental and industry standards, implicitly assume that authenticated components will comply with operational policies. However, this assumption creates a critical blind spot: misconfigured or compromised components can silently violate policies, misuse resources, or corrupt downstream processes (e.g., ML-based RIC xApps). To address this critical gap, we propose a monitoring framework for low-trust O-RAN environments that proactively verifies configuration state and control behavior against tenant-defined policies. Our system provides scalable, verifiable oversight to enhance transparency and trust in O-RAN operations. We implement and evaluate the framework using standardized O-RAN configurations, with total processing latency of approximately 200 ms, demonstrating its efficiency and practicality for timely policy enforcement and compliance auditing in multi-MNO deployments.

Figures

Figures reproduced from arXiv: 2509.03000 by the authors.

Figure 2
Figure 2. A shared O-RAN deployment. *Orange components: our proposed modules TR and PRH. can launch man-in-the-middle (MITM) attacks and manipu￾late fronthaul traffic to cause silent RF misbehavior, such as manipulating beamforming parameters or injecting malformed IQ samples [14], [15]. Yang et al. [16] revealed widespread vulnerabilities due to insecure M-plane configurations in real￾world O-RAN deployments. Akon et al. [1… view at source ↗
Figure 3
Figure 3. A simple Merkle tree constructed over 4 evidence items. [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figure 4
Figure 4. Merkle Root Computation Time and Total Processing [PITH_FULL_IMAGE:figures/full_fig_p008_4.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

58 extracted references · 57 canonical work pages

  1. [1]

    Joint statement endorsing principles for 6g: Secure, open & resilient by design,

    NTIA.gov, “Joint statement endorsing principles for 6g: Secure, open & resilient by design,” 2024

    work page 2024

  2. [2]

    Risks, Threats, and Vulnerabilities in an Open RAN,

    VMware, “Risks, Threats, and Vulnerabilities in an Open RAN,” 2024

    work page 2024

  3. [3]

    Open RAN security examined,

    NEC Corporation, “Open RAN security examined,” 2022

    work page 2022

  4. [4]

    Zero trust architecture for secure o-ran,

    O. ALLIANCE, “Zero trust architecture for secure o-ran,” 2024

    work page 2024

  5. [5]

    Zero trust architecture,

    “Zero trust architecture,” Tech. Rep. NIST SP 800-207, 2020

    work page 2020

  6. [6]

    O-RAN security threat modeling and risk assessment,

    O-RAN Alliance, “O-RAN security threat modeling and risk assessment,” 2024

    work page 2024

  7. [7]

    O-ran wg11 shared o-ru security analysis,

    O.-R. ALLIANCE, “O-ran wg11 shared o-ru security analysis,” Tech. Rep. TR.0-R004-v06.00, 2025

    work page 2025

  8. [8]

    Open, programmable, and virtualized 5g networks: State-of-the-art and the road ahead,

    L. Bonati, M. Polese, S. D’Oro, S. Basagni, and T. Melodia, “Open, programmable, and virtualized 5g networks: State-of-the-art and the road ahead,” Computer Networks, vol. 182, p. 107516, 2020

    work page 2020

Show all 58 references
  1. [9]

    O-ran use cases and deployment scenarios whitepa- per,

    O-RAN Alliance, “O-ran use cases and deployment scenarios whitepa- per,” 2020

    2020

  2. [10]

    Test plans, results, and lessons learned about open ran integration during the NTIA 5G challenges,

    “Test plans, results, and lessons learned about open ran integration during the NTIA 5G challenges,” 2025

    2025

  3. [11]

    Advanced Dynamic Spectrum Sharing Demonstration in the National Spectrum Strategy,

    ntia.gov, “Advanced Dynamic Spectrum Sharing Demonstration in the National Spectrum Strategy,” 2024

    2024

  4. [12]

    Prosas: An o-ran approach to spectrum sharing between nr and lte,

    S. Gopal, D. Griffith, R. A. Rouil, and C. Liu, “Prosas: An o-ran approach to spectrum sharing between nr and lte,” in ICC 2024-IEEE International Conference on Communications , pp. 360–366, IEEE, 2024

    2024

  5. [13]

    An o-ran approach to spectrum sharing between commercial 5g and government satellite systems,

    R. Smith, C. Freeberg, T. Machacek, and V . Ramaswamy, “An o-ran approach to spectrum sharing between commercial 5g and government satellite systems,” in IEEE Military Communications Conference (MIL- COM), pp. 739–744, IEEE, 2021

    2021

  6. [14]

    On the criticality of integrity protection in 5g fronthaul networks,

    J. Xing, S. Yoo, X. Foukas, D. Kim, and M. K. Reiter, “On the criticality of integrity protection in 5g fronthaul networks,” in 33rd USENIX Security Symposium (USENIX Security 24) , pp. 4463–4479, 2024

    2024

  7. [15]

    End-to-end o-ran security architecture, threat surface, coverage, and the case of the open fronthaul,

    A. S. Abdalla and V . Marojevic, “End-to-end o-ran security architecture, threat surface, coverage, and the case of the open fronthaul,” IEEE Communications Standards Magazine , vol. 8, no. 1, pp. 36–43, 2024

    2024

  8. [16]

    {ORANalyst}: Systematic testing framework for open {RAN} imple- mentations,

    T. Yang, S. M. M. Rashid, A. Ranjbar, G. Tan, and S. R. Hussain, “{ORANalyst}: Systematic testing framework for open {RAN} imple- mentations,” in 33rd USENIX Security Symposium, pp. 1921–1938, 2024

    1921

  9. [17]

    From control to chaos: A comprehensive formal analysis of 5g’s access control,

    M. Akon, M. Toufikuzzaman, and S. R. Hussain, “From control to chaos: A comprehensive formal analysis of 5g’s access control,” in 2025 IEEE Symposium on Security and Privacy (SP) , pp. 1043–1062, 2025

    2025

  10. [18]

    Open ran security report,

    NTIA, “Open ran security report,” 2023

    2023

  11. [19]

    Signaling storm in o-ran: challenges and research opportunities,

    A. Tabiban, H. A. Alameddine, M. A. Salahuddin, and R. Boutaba, “Signaling storm in o-ran: challenges and research opportunities,” IEEE Communications Magazine, vol. 62, no. 6, pp. 58–64, 2023

    2023

  12. [20]

    Synchroniza- tion plane in o-ran: Overview, security and research directions,

    A. Maamary, H. A. Alameddine, M. Debbabi, and C. Assi, “Synchroniza- tion plane in o-ran: Overview, security and research directions,” IEEE Communications Magazine, 2024

    2024

  13. [21]

    Attacking o-ran interfaces: threat modeling, analysis and practical experimentation,

    P. Baguer, G. M. Yilma, E. Municio, G. Garcia-Aviles, A. Garcia- Saavedra, M. Liebsch, and X. Costa-Pérez, “Attacking o-ran interfaces: threat modeling, analysis and practical experimentation,” IEEE Open Journal of the Communications Society , 2024

    2024

  14. [22]

    Misconfig- uration in o-ran: Analysis of the impact of ai/ml,

    N. M. Yungaicela-Naula, V . Sharma, and S. Scott-Hayward, “Misconfig- uration in o-ran: Analysis of the impact of ai/ml,” Computer Networks , p. 110455, 2024

    2024

  15. [23]

    Intelligent control in 6g open ran: Security risk or opportunity?,

    S. Soltani, A. Amanloo, M. Shojafar, and R. Tafazolli, “Intelligent control in 6g open ran: Security risk or opportunity?,” IEEE Open Journal of the Communications Society, 2025

    2025

  16. [24]

    System-level analysis of adversarial attacks and defenses on intelligence in o-ran based cellular networks,

    A. Chiejina, B. Kim, K. Chowhdury, and V . K. Shah, “System-level analysis of adversarial attacks and defenses on intelligence in o-ran based cellular networks,” in Proceedings of the 17th ACM Conference on Security and Privacy in Wireless and Mobile Networks , 2024

    2024

  17. [25]

    Rogue cell: Adversarial attack and defense in untrusted o-ran setup exploiting the traffic steering xapp,

    E. Aizikovich, D. Mimran, E. Grolman, Y . Elovici, and A. Shabtai, “Rogue cell: Adversarial attack and defense in untrusted o-ran setup exploiting the traffic steering xapp,” arXiv preprint, 2025

    2025

  18. [26]

    O-RAN O-Cloud Architecture and Requirements Specification,

    “O-RAN O-Cloud Architecture and Requirements Specification,” Tech. Rep. O-RAN.WG6.O-Cloud-Architecture-v06.00, O-RAN Alliance

  19. [27]

    Security architecture and procedures for 5G System. (TS 33.501),

    3GPP, “Security architecture and procedures for 5G System. (TS 33.501),” 2024

    2024

  20. [28]

    ETSI TS 104 023 V12.0114.0, 2024

    O-RAN.WG4.MP.0-R003-v12.01, O-RAN Fronthaul Management Plane Specification v12.01. ETSI TS 104 023 V12.0114.0, 2024

    2024

  21. [29]

    Network Configuration Protocol (NETCONF)

    “Network Configuration Protocol (NETCONF).” RFC 6241

  22. [30]

    Y ANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)

    “Y ANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF).” RFC 6020

  23. [31]

    Common Public Radio Interface (eCPRI) Specification V1.0,

    eCPRI Specification Working Group, “Common Public Radio Interface (eCPRI) Specification V1.0,” 2017

    2017

  24. [32]

    IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems,

    “IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems,” 2020

    2020

  25. [33]

    {UCBlocker}: Unwanted call blocking using anonymous authentica- tion,

    C. Du, H. Yu, Y . Xiao, Y . T. Hou, A. D. Keromytis, and W. Lou, “{UCBlocker}: Unwanted call blocking using anonymous authentica- tion,” in 32nd USENIX Security Symposium (USENIX Security 23) , pp. 445–462, 2023

    2023

  26. [34]

    Aaka: An anti-tracking cellular authentication scheme leveraging anonymous credentials,

    H. Yu, C. Du, Y . Xiao, A. Keromytis, C. Wang, R. Gazda, Y . T. Hou, and W. Lou, “Aaka: An anti-tracking cellular authentication scheme leveraging anonymous credentials,” in Network and Distributed System Security Symposium (NDSS) , 2023

    2023

  27. [35]

    Mobile tracking in 5g and beyond networks: Problems, challenges, and new directions,

    C. Du, H. Yu, Y . Xiao, W. Lou, C. Wang, R. Gazda, and Y . T. Hou, “Mobile tracking in 5g and beyond networks: Problems, challenges, and new directions,” in 2022 IEEE 19th International Conference on Mobile Ad Hoc and Smart Systems (MASS) , pp. 426–434, IEEE, 2022

    2022

  28. [36]

    Bijack: Breaking bitcoin network with tcp vulnerabilities,

    S. Li, S. Shi, Y . Xiao, C. Zhang, Y . T. Hou, and W. Lou, “Bijack: Breaking bitcoin network with tcp vulnerabilities,” in European Symposium on Research in Computer Security , pp. 306–326, Springer, 2023

    2023

  29. [37]

    Mindfl: Mitigating the impact of imbalanced and noisy-labeled data in feder- ated learning with quality and fairness-aware client selection,

    C. Zhang, N. Wang, S. Shi, C. Du, W. Lou, and Y . T. Hou, “Mindfl: Mitigating the impact of imbalanced and noisy-labeled data in feder- ated learning with quality and fairness-aware client selection,” in MIL- COM 2023-2023 IEEE Military Communications Conference (MILCOM), pp. ...

    2023

  30. [38]

    Hermes: Boosting the performance of machine-learning-based intrusion detection system through geometric feature learning,

    C. Zhang, S. Shi, N. Wang, X. Xu, S. Li, L. Zheng, R. Marchany, M. Gardner, Y . T. Hou, and W. Lou, “Hermes: Boosting the performance of machine-learning-based intrusion detection system through geometric feature learning,” in Proceedings of the Twenty-fifth International Sym-...

    2024

  31. [39]

    Feco: Boosting intrusion detection capability in iot networks via contrastive learning,

    N. Wang, S. Shi, Y . Chen, W. Lou, and Y . T. Hou, “Feco: Boosting intrusion detection capability in iot networks via contrastive learning,” IEEE Transactions on Dependable and Secure Computing , 2025

    2025

  32. [40]

    State-of-the-art approaches to enhancing privacy preservation of machine learning datasets: A survey,

    C. Zhang and S. Li, “State-of-the-art approaches to enhancing privacy preservation of machine learning datasets: A survey,” arXiv preprint arXiv:2404.16847, 2024

    2024 arXiv

  33. [41]

    StarCast: A Secure and Spectrum-Efficient Group Communica- tion Scheme for LEO Satellite Networks,

    C. Zhang, H. Yu, S. Shi, S. Li, Y . Shi, E. Burger, Y . T. Hou, and W. Lou, “StarCast: A Secure and Spectrum-Efficient Group Communica- tion Scheme for LEO Satellite Networks,” IEEE International Symposium on Dynamic Spectrum Access Networks (DySPAN) , 2025

    2025

  34. [42]

    Enabling Trustworthy Federated Learning via Remote Attestation for Mitigating Byzantine Threats,

    C. Zhang, H. Jin, S. Shi, H. Yu, S. Johns, Y . T. Hou, and W. Lou, “Enabling Trustworthy Federated Learning via Remote Attestation for Mitigating Byzantine Threats,” in Proceedings of the IEEE Military Communications Conference (MILCOM) , IEEE, 2025

    2025

  35. [43]

    Machine learning-based early attack detection using open ran intelligent controller,

    B. M. Xavier, M. Dzaferagic, D. Collins, G. Comarela, M. Martinello, and M. Ruffini, “Machine learning-based early attack detection using open ran intelligent controller,” in ICC 2023 - IEEE International Conference on Communications, pp. 1856–1861, 2023

    2023

  36. [44]

    Det- ran: Data-driven cross-layer real-time attack detection in 5g open rans,

    A. Scalingi, S. D’Oro, F. Restuccia, T. Melodia, and D. Giustiniano, “Det- ran: Data-driven cross-layer real-time attack detection in 5g open rans,” in IEEE INFOCOM 2024-IEEE Conference on Computer Communications , pp. 41–50, IEEE, 2024

    2024

  37. [45]

    Spotlight: Accurate, explainable and efficient anomaly detection for open ran,

    C. Sun, U. Pawar, M. Khoja, X. Foukas, M. K. Marina, and B. Radunovic, “Spotlight: Accurate, explainable and efficient anomaly detection for open ran,” in Proceedings of the 30th Annual International Conference on Mobile Computing and Networking , pp. 923–937, 2024

    2024

  38. [46]

    5g- spector: An o-ran compliant layer-3 cellular attack detection service,

    H. Wen, P. Porras, V . Yegneswaran, A. Gehani, and Z. Lin, “5g- spector: An o-ran compliant layer-3 cellular attack detection service,” in Proceedings of the 31st Annual Network and Distributed System Security Symposium, NDSS, vol. 24, 2024

    2024

  39. [47]

    A fpga-based heterogeneous implemen- tation of ntruencrypt,

    H. Yu, C. Zhang, and H. Jiang, “A fpga-based heterogeneous implemen- tation of ntruencrypt,” in Advances in Parallel & Distributed Processing, and Applications: Proceedings from PDPTA’20, CSC’20, MSV’20, and GCC’20, pp. 461–475, Springer, 2021

    2021

  40. [48]

    High-performance and energy-efficient fpga-gpu-cpu heterogeneous system implementation,

    C. Zhang, H. Yu, Y . Zhou, and H. Jiang, “High-performance and energy-efficient fpga-gpu-cpu heterogeneous system implementation,” in Advances in Parallel & Distributed Processing, and Applications: Proceedings from PDPTA’20, CSC’20, MSV’20, and GCC’20 , pp. 477– 492, Springer, 2021

    2021

  41. [49]

    Gpu acceleration of ciphertext-policy attribute-based encryption,

    K. Fan, C. Zhang, R. Shan, H. Yu, and H. Jiang, “Gpu acceleration of ciphertext-policy attribute-based encryption,” in 2019 20th IEEE/ACIS International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing (SNPD) , pp. 94–1...

    2019

  42. [50]

    Taking 5g ran analytics and control to a new level,

    X. Foukas, B. Radunovic, M. Balkwill, and Z. Lai, “Taking 5g ran analytics and control to a new level,” in Proceedings of the 29th Annual International Conference on Mobile Computing and Networking , 2023

    2023

  43. [51]

    An openran security framework for scalable authentication, authorization, and discovery of xapps with isolated critical services,

    T. O. Atalay, S. Maitra, D. Stojadinovic, A. Stavrou, and H. Wang, “An openran security framework for scalable authentication, authorization, and discovery of xapps with isolated critical services,” IEEE Transactions on Dependable and Secure Computing , 2024

    2024

  44. [52]

    Ztran: Prototyp- ing zero trust security xapps for open radio access network deployments,

    A. S. Abdalla, J. Moore, N. Adhikari, and V . Marojevic, “Ztran: Prototyp- ing zero trust security xapps for open radio access network deployments,” IEEE Wireless Communications, vol. 31, no. 2, pp. 66–73, 2024

    2024

  45. [53]

    {Application-Level} service assurance with 5g {RAN} slicing,

    A. Balasingam, M. Kotaru, and P. Bahl, “ {Application-Level} service assurance with 5g {RAN} slicing,” in 21st USENIX Symposium on Networked Systems Design and Implementation , pp. 841–857, 2024

    2024

  46. [54]

    O-RAN WG11 Security Requirements Specification,

    O-RAN Alliance, “O-RAN WG11 Security Requirements Specification,” Tech. Rep. O-RAN.WG11.SEC.0-v10.00, 2022

    2022

  47. [55]

    Realswatt: Remote software-based attestation for embedded devices under realtime constraints,

    S. Surminski, C. Niesler, F. Brasser, L. Davi, and A.-R. Sadeghi, “Realswatt: Remote software-based attestation for embedded devices under realtime constraints,” in Proceedings of the 2021 ACM SIGSAC conference on computer and communications security , 2021

    2021

  48. [56]

    {ARI}: Attestation of real-time mission execution integrity,

    J. Wang, Y . Wang, A. Li, Y . Xiao, R. Zhang, W. Lou, Y . T. Hou, and N. Zhang, “ {ARI}: Attestation of real-time mission execution integrity,” in 32nd USENIX Security Symposium , pp. 2761–2778, 2023

    2023

  49. [57]

    Efficient data structures for tamper- evident logging.,

    S. A. Crosby and D. S. Wallach, “Efficient data structures for tamper- evident logging.,” in USENIX security symposium , pp. 317–334, 2009

    2009

  50. [58]

    A digital signature based on a conventional encryption function,

    R. C. Merkle, “A digital signature based on a conventional encryption function,” in Advances in Cryptology — CRYPTO ’87 , Lecture Notes in Computer Science, Springer, 1988

    1988

Pith tools

Reviewed August 5, 2026 · model on record in the stance chip above.