arXiv CSopen access

Tick-Tock on the Open Fronthaul: Securing Synchronization in O-RAN

arXiv:2609.22525v1 [cs.CR] 18 Sep 2026

Tick-Tock on the Open Fronthaul: Securing Synchronization in O-RAN Yiwei Zhang

Enrico Pisanti

Imtiaz Karim

Purdue University West Lafayette, Indiana, USA [email protected]

Purdue University West Lafayette, Indiana, USA [email protected]

The University of Texas at Dallas Richardson, Texas, USA [email protected]

Subangkar Karmaker Shanto

Elisa Bertino

Purdue University West Lafayette, Indiana, USA [email protected]

Purdue University West Lafayette, Indiana, USA [email protected]

Abstract—The Precision Time Protocol (PTP) provides the time and phase synchronization required by disaggregated Open Radio Access Networks (O-RAN). Yet, in current open fronthaul deployments, PTP traffic lacks mandatory authentication and integrity protection, leaving synchronization vulnerable to spoofing, replay, and delay manipulation attacks that can degrade radio access performance. Existing protections are poorly suited to this setting: they either add excessive latency, do not support multicast dissemination efficiently, or fail to contain key exposure under partially trusted RUs. This paper analyzes the security risks of unprotected ORAN PTP and develops a threat model for open fronthaul deployments. We then introduce PRTESLA-C, a lightweight synchronization protection mechanism that combines perround delayed key disclosure with ASCON-based message authentication. PRTESLA-C uses an apply-then-verify-andcorrect paradigm: timing samples are applied immediately to preserve real-time control, verified after key disclosure, and removed from persistent synchronization state if authentication fails. This design maintains sub-microsecond synchronization accuracy, provides strong protection against spoofing and replay, and bounds the impact of delay manipulation with minimal computational and latency overhead.

1. Introduction The increasing demand for flexibility, scalability, and rapid innovation in 5G networks has accelerated the transition toward open and modular architectures. Open Radio Access Network (O-RAN) embraces this vision through a disaggregated design that separates hardware and software components, enabling programmability and multi-vendor interoperability [6, 7, 21, 37]. However, this architectural openness also enlarges the attack surface. In particular, the Open Fronthaul (O-FH) interface between the O-RAN Distributed Unit (O-DU) and Radio Unit (O-RU) introduces new and insufficiently explored security risks [10, 13, 23, 26, 35, 41].

Among the functions carried over the O-FH, time and frequency synchronization are especially critical [7, 27, 34]. Accurate synchronization between O-DU and O-RU underpins key 5G features such as Time Division Duplex (TDD), beamforming, and coordinated multipoint transmission (CoMP). This functionality is typically realized through the IEEE 1588v2 Precision Time Protocol (PTP) [40]. Yet, PTP was originally designed for controlled wired industrial environments, not for open, packet-switched, and potentially adversarial settings like O-RAN. When deployed over OFH, PTP inherits security assumptions that no longer hold. Despite its critical role, PTP lacks mandatory and robust mechanisms for message authenticity and integrity protection in current O-RAN deployments [16, 37]. Existing specifications [8, 22] often treat authentication as optional due to concerns about computational overhead and stringent real-time constraints. Consequently, synchronization traffic remains vulnerable to spoofing, replay, and delay manipulation attacks [9, 16], which can significantly degrade synchronization accuracy or even disrupt service availability. Securing PTP in O-RAN is particularly challenging for three reasons. First, O-FH synchronization often relies on broadcast or multicast dissemination, especially when groups of O-RUs must maintain tight phase alignment, making pairwise secure channels impractical. Second, synchronization messages are exchanged at high frequency and directly feed real-time control loops, leaving little tolerance for added latency or jitter. Third, O-RUs may be partially compromised and leak locally stored credentials. Long-lived symmetric keys therefore become future-forgery capabilities: group keys amplify compromise across all ORUs, while pairwise keys confine but do not eliminate the exposure. Conventional solutions such as IPsec, TLS, and MACsec [16, 30] provide strong protection for unicast traffic, but their reliance on pairwise keying, heavyweight cryptographic processing, and limited multicast support render them ill-suited for high-frequency PTP flows under adversarial O-FH conditions. These challenges call for a lightweight, scalable, and timing-aware authentication

mechanism tailored to O-RAN synchronization. In this paper, we address these challenges by developing a security framework that aligns authentication strategies with O-RAN deployment constraints and realistic threat models. Inspired by the delayed authentication paradigm of TESLA [36], we revisit the design space of synchronization protection along three dimensions: key disclosure granularity, synchronization computation semantics, and verification timing. This analysis reveals a fundamental tension between immediate authentication (which preserves security but disrupts timing determinism) and delayed verification (which preserves real-time behavior but risks transient exposure). Guided by this design space, we propose PRTESLAC (Per-Round TESLA with Correction), a scalable authentication scheme for securing PTP synchronization in ORAN. PRTESLA-C combines per-round delayed key disclosure with lightweight ASCON-based message authentication [17], and adopts an apply-then-verify-and-correct paradigm. Synchronization updates are applied immediately upon reception to maintain real-time responsiveness, verified once the corresponding key is disclosed, and corrected in a bounded manner if authentication fails. This approach preserves synchronization stability while preventing longterm impact from spoofed or manipulated messages. PRTESLA-C is built on three key principles. First, it eliminates long-lived shared group keys at O-RUs. By leveraging one-way key chains with delayed disclosure, PRTESLA-C prevents a compromised O-RU from forging future synchronization traffic, mitigating compromise amplification risks inherent in symmetric-key designs. Second, it naturally supports multicast dissemination, enabling scalable protection for groups of O-RUs that must remain tightly synchronized. Third, it decouples authentication from real-time control while ensuring bounded correction, thereby maintaining sub-microsecond synchronization precision without destabilizing the control loop. Through lightweight cryptographic operations and efficient implementation techniques, PRTESLA-C introduces minimal computational and bandwidth overhead. In summary, our contributions are as follows: •

•

•

We present a comprehensive threat model for PTP synchronization in O-RAN, identifying attack vectors arising from unprotected fronthaul synchronization and analyzing the limitations of existing protection mechanisms. We develop a principled security framework for synchronization authentication under real-time and multicast constraints, and design PRTESLA-C, a scalable and timing-aware protection mechanism. We implement a prototype of PRTESLA-C and evaluate it in a realistic O-RAN testbed, demonstrating strong integrity and authenticity guarantees while preserving high-precision synchronization performance under adversarial manipulation and packet loss.

By systematically closing a previously underexplored vulnerability in O-RAN synchronization, this work provides

O-DU

O-RU

Eth Switch

Eth Switch

O-RU

O-DU

Eth Switch

O-RU

Figure 1. Example O-RAN fronthaul topology and attack surface for PTP synchronization

a practical and principled foundation for securing nextgeneration open radio access networks.

2. Background In this section, we first outline the O-RAN architecture and the structure of the Open Fronthaul (O-FH), then describe the synchronization mechanisms used to maintain precise timing across O-RAN deployments, and finally discuss existing protection approaches and their limitations.

2.1. O-RAN Architecture and Open Fronthaul O-RAN adopts a disaggregated architecture that separates traditional base-station functionality into standardized components, enabling multi-vendor interoperability and flexible deployment [6, 37]. Among the functional splits defined by the O-RAN Alliance, Split 7-2x is widely adopted: upper-PHY and MAC functions reside at the O-RAN Distributed Unit (O-DU, abbreviated as DU hereafter), while lower-PHY processing is executed at the O-RAN Radio Unit (O-RU, abbreviated as RU hereafter), which interfaces with the radio front end. The DU and RU communicate over the Open Fronthaul (O-FH), a packet-based Ethernet interface organized into four logical planes: Control, User, Management, and Synchronization. The Synchronization Plane distributes timing and phase information essential for coordinated baseband and radio operation, forming the temporal foundation of fronthaul.

2.2. Synchronization in O-RAN Precise timing in O-RAN is typically achieved using the IEEE 1588v2 Precision Time Protocol (PTP) [40]. PTP follows a hierarchical master–slave model in which a master clock distributes reference time and slaves synchronize using timestamped message exchanges. From these timestamps, each slave estimates clock offset and path delay relative to the master and disciplines its local oscillator via a feedback controller (clock servo). Delay Request-Response mechanism. O-RAN deployments adopt the Delay Request–Response mechanism, in which two independent message pairs serve distinct roles:

Sync/Follow Up carry master-to-slave timing information for offset estimation, while Delay Req/Delay Resp measure the slave-specific path delay and may operate at a different rate. Path delay and clock offset are computed as Delay = (T2 −T1 )+(T4 −T3 ) and Offset = (T2 − T1 ) − Delay where 2 (T1 , T2 ) are the transmission and reception times of Sync (T1 conveyed via Follow Up in two-step mode), and (T3 , T4 ) are the transmission and reception times of Delay Req. Although PTP also specifies a Peer Delay mechanism for link-local measurements, O-RAN fronthaul synchronization primarily relies on this master–slave model, which we adopt throughout. Clock Servo Dynamics. Offset and delay estimates are filtered to mitigate timestamp noise and packet delay variation [1]. The filtered offset drives a closed-loop servo, typically based on a proportional–integral (PI) controller [2], which computes bounded frequency adjustments to gradually reduce phase error. When offsets exceed configured thresholds, discrete phase steps may be applied; otherwise, the servo operates in frequency-slew mode. Importantly, the control input should be bounded, ensuring stable phase evolution and preventing unbounded timing excursions. PTP Roles in O-RAN Deployments. As shown in Figure 1, a transport-network grandmaster provides the primary time reference; the DU acts as PTP master within the fronthaul segment; and RUs act as slaves. Intermediate switches may operate as Boundary or Transparent Clocks, forwarding or compensating PTP traffic depending on deployment configuration.

2.3. Protection Mechanisms in PTP Although PTP can achieve sub-microsecond synchronization accuracy under ideal conditions, its messages are typically transmitted in plaintext without mandatory integrity or authenticity protection. Originally designed for closed and trusted environments, PTP does not inherently defend against adversarial manipulation. Consequently, unauthenticated synchronization traffic is vulnerable to spoofing, replay, and delay manipulation attacks [18, 24, 32, 33]. Conventional Security Approaches. Several mechanisms aim to enhance PTP message protection. IEEE 1588 Annex K defines an optional AUTHENTICATION TLV with a sequence counter and a shared-key HMAC, but it relies on pre-shared keys, lacks standardized key management, and scales poorly to multicast deployments. Network-layer mechanisms such as TLS, IPsec, and MACsec [16, 30] provide mature authenticated channels, but they are primarily designed for pairwise protection. In high-rate fronthaul synchronization, pairwise channels introduce per-destination processing and serialization at the DU, while multicast support is limited or falls back to shared group keys. These mechanisms also retain a symmetric-key exposure model that is ill-suited to partially trusted RUs. Any long-lived symmetric key stored at an RU becomes a future-forgery capability once extracted from memory. A pairwise DU– RU key confines the damage to the compromised association

but still enables future authenticated forgeries until rekeying completes; a shared multicast key amplifies the same failure to the entire RU group. Thus, the limitation is not only overhead or multicast inefficiency, but also the lack of forward compromise containment for receiver-held symmetric secrets. Lightweight primitives such as ASCON [17] can reduce cryptographic cost, but do not by themselves address this key-exposure problem. TESLA: Lightweight Broadcast Authentication TESLA (Timed Efficient Stream Loss-Tolerant Authentication) [28, 36, 39] provides scalable broadcast authentication using delayed key disclosure. The sender constructs a one-way key chain (K0 , . . . , Kn ) with Ki = F (Ki+1 ), and authenticates messages in interval i using key Ki , which is disclosed after a fixed delay. Receivers buffer messages and verify them once the corresponding key is revealed. TESLA eliminates pairwise key establishment and avoids long-lived shared group secrets, providing scalability and forward security in multicast settings. However, verification latency is inherent to its design: messages must be buffered until key disclosure. In tightly coupled realtime systems such as O-RAN synchronization, this delayedverification model conflicts with immediate control-loop updates.

2.4. Challenges in O-RAN Applying existing protection mechanisms to O-RAN fronthaul synchronization is challenging due to the combination of multi-RU coordination, partial trust, and strict real-time determinism. Multi-RU synchronization under limited trust. A single DU typically synchronizes multiple RUs that must remain aligned within a common timing epoch. For features such as TDD and CoMP [3], even small inter-RU skew can cause cross-link interference or reduce coordination gains. Synchronization must therefore provide both high accuracy and deterministically bounded skew across RUs. Pairwise unicast authentication secures each DU–RU association independently, but it also introduces per-destination processing, queueing, and serialization at the DU, which can amplify arrival-time divergence under load. Multicast dissemination better preserves group simultaneity, but a shared symmetric group key creates compromise amplification: a single compromised RU can forge synchronization traffic for the entire group. Compromise containment. RUs are distributed edge devices deployed across heterogeneous and potentially partially trusted environments [19]; partial endpoint compromise must therefore be treated as a realistic threat. If a receiver stores long-lived symmetric secrets, memory disclosure grants future-forgery capability: group keys compromise all receivers, while pairwise keys compromise the affected DU–RU association until rekeying. Synchronization protection should therefore expose only verification material for expired rounds. Strict real-time determinism. Synchronization updates directly drive the clock servo at each RU and operate at

sub-microsecond granularity. Protection mechanisms that introduce buffering, additional processing, or delayed application risk perturbing the control loop and degrading timing stability. Broadcast authentication schemes such as TESLA provide scalability and avoid receiver-held signingcapable secrets, but conventional verify-then-apply TESLA imposes verification latency. Conversely, pairwise protections can authenticate immediately but increase serialization and processing overhead at the DU. Taken together, these constraints require a mechanism that simultaneously (i) supports scalable one-to-many authentication, (ii) contains RU compromise without relying on receiver-held future-forgery secrets, and (iii) preserves real-time determinism with bounded inter-RU skew. Among existing approaches, TESLA most naturally addresses (i) and (ii): its broadcast-compatible design avoids pairwise keying, and its one-way key chain ensures that receivers learn only expired verification keys rather than keys for future message authentication. However, conventional TESLA’s verify-then-apply semantics fundamentally conflict with (iii), motivating the design of PRTESLA-C.

3. Threat Model We define a threat model tailored to PTP synchronization in disaggregated O-RAN fronthaul deployments. Our assumptions are grounded in prior empirical analyses of PTP vulnerabilities and timing attacks [19, 38], as well as documented security challenges in O-RAN systems. We consider realistic adversaries operating in partially trusted fronthaul environments, where synchronization traffic is often unauthenticated due to deployment and performance constraints.

3.1. Adversary Capabilities

Endpoint compromise. The adversary may partially compromise an RU and read locally stored cryptographic material, including symmetric keys, key schedules, or authentication state. This capability captures practical attacks such as physical access, local privilege escalation, software vulnerabilities, or read-only exposure on edge-deployed RUs. We do not require the compromised RU to be fully Byzantine: transient key disclosure may be feasible without persistent control of the RU’s PTP stack, radio behavior, or outgoing traffic, which would require stronger and noisier capabilities. Nevertheless, memory disclosure alone is sufficient to break conventional symmetric authentication. If the RU stores a shared group key, the attacker can generate valid tags for the entire synchronization group; if it stores a pairwise DU– RU key, the attacker can generate valid tags within that association and impersonate authenticated synchronization messages involving that RU. Accordingly, our goal is to contain RU compromise by ensuring that receiver-side state contains only verification material for expired rounds, rather than long-lived secrets capable of authenticating future DUoriginated PTP messages. Cryptographic assumptions and scope. We assume a computationally bounded adversary that cannot break standard cryptographic primitives without obtaining secret keys. Constructions such as HMAC, ASCON, and secure PRFs are treated as secure. Unrevealed TESLA keys remain unpredictable unless an endpoint is compromised. We assume a minimally trusted initialization phase in which the DU provisions key-chain commitments and configuration parameters to each RU. We do not assume confidentiality of PTP traffic; our focus is on scalable, low-overhead guarantees of authenticity and integrity against spoofing and replay, as well as robustness against adversarial delay manipulation and packet dropping, whose impact is bounded within the authentication window.

3.2. Practicality and Scope We consider an adversary targeting the synchronization plane (S-plane) with the objective of degrading timing precision, inducing inter-RU skew, or destabilizing synchronization control loops. The adversary does not control all fronthaul planes but can interfere with PTP traffic traversing the switched fronthaul path. As illustrated in Figure 1, we model two categories of capabilities. Synchronization-path compromise (MITM). By compromising intermediate switches or inserting a malicious device along the fronthaul, the adversary can act as a man-in-themiddle on PTP traffic. In this position, the attacker can eavesdrop, inject, forge, drop, or replay PTP packets, and introduce asymmetric delay or controlled latency to selected messages to bias clock-offset and path-delay estimation. This capability is confined to the synchronization plane and does not imply sustained manipulation of high-rate I/Q payload streams or higher-layer control entities. We do not focus on unbounded selective end-to-end delay or complete synchronization blocking, which constitute availability disruptions and have been addressed by prior detection and resilience mechanisms [4, 19, 31].

O-RAN deployments often span heterogeneous or partially trusted infrastructures, where fronthaul segments may be exposed to network-level manipulation or endpoint compromise. Prior work demonstrates that replay or delay manipulation of PTP traffic can destabilize production-grade 5G systems within seconds by biasing timing loops and misaligning coordinated RUs [19]. Notably, these attacks operate solely on low-bandwidth synchronization traffic yet induce large-scale desynchronization. Other studies show that broader fronthaul access may enable manipulation of I/Q samples or control-plane signaling [42]; however, such attacks require substantially stronger capabilities and target different planes. Endpoint compromise further expands the attack surface. Physical or local network access to O-RAN RUs may expose configuration data and cryptographic material [25]. Mechanisms relying on shared group keys are particularly vulnerable to compromise amplification, allowing a single breached RU to affect all receivers. Motivated by these findings, our threat model captures both synchronization-path manipulation and partial endpoint

compromise under realistic deployment conditions. We do not assume fully trusted endpoints and explicitly account for compromise containment. Our goal is to close a documented integrity gap in the synchronization plane that alone can induce large-scale service disruption. This work complements, rather than replaces, protections for user and control planes.

DU (Master)

Generate Key Chains

4. Detailed Design Our goal is to provide strong integrity and authenticity guarantees for PTP synchronization while preserving ORAN’s stringent real-time constraints. The design is guided by three principles: (i) minimizing trust in intermediaries and endpoints; (ii) preserving deterministic multi-RU timing alignment; and (iii) avoiding heavyweight cryptography that perturbs synchronization precision, while ensuring graceful degradation under partial compromise. We build on TESLA because delayed disclosure removes future-forgery secrets from receivers while supporting multicast authentication. Conventional TESLA, however, buffers messages until key disclosure, which delays servo inputs and destabilizes PTP control. PRTESLA-C instead applies samples immediately, verifies them after disclosure, and removes invalid samples from persistent synchronization state through bounded recovery. We organize the design around three dimensions: keydisclosure granularity, synchronization computation, and authentication timing. These choices lead to Per-Round TESLA with Correction (PRTESLA-C), a delayedauthentication mechanism tailored to O-RAN PTP synchronization.

RU (Slave)

Switch

Announce || Initial Parameters || Initial keys (delay=2, K0X, X∈{S,D})

Round i=1

M1 || Seq M1' || Seq || RolloverMeta || K1S || MAC S (computed by K S) 1

3

Check Seq Verify K1S using K0S Store M1, M1' and MAC1S

Round i=2

Apply timing contribution from M1 and M1'

M2 || Seq M2' || Seq || RolloverMeta || K2S || MAC2S Check Seq

Verify K2S using K0S or K1S Store M2, M2' and MAC2S

Round i=3

Apply timing contribution from M2 and M2'

M3 || Seq M3' || Seq || RolloverMeta || K3S || MAC3S Check Seq

Verify K3S using K0S ... K2S Store M3, M3' and MAC2S Verify (M1 and M1') using K3S

No Correction Round 1 (M1 and M1')

verified successfully? Yes Apply timing contribution from M3 and M3'

4.1. Design Space We characterize the design space along three dimensions that capture the main trade-offs in securing PTP synchronization over O-RAN fronthaul. Dimension 1: Key-Disclosure Granularity. This dimension determines how authentication keys are assigned, rotated, and disclosed, and therefore how widely a compromise can propagate: (a) Shared keys are efficient but amplify RU compromise. (b) Per-interval keys reduce management cost but introduce boundary ambiguity under loss and reordering. (c) Per-round keys avoid interval-boundary ambiguity and bound failures to individual rounds; PRTESLA-C adopts this choice with separate Sync and Delay chains. Dimension 2: Synchronization Computation. This dimension determines how timing estimates are computed when multiple rounds elapse before key disclosure. Per-interval schemes may use (a) last-only samples, where only the last valid round is used, minimizing buffering but increasing sensitivity to loss, jitter, and interval-boundary artifacts; or (b) aggregated samples, where multiple rounds are combined, improving smoothing but adding buffering and recovery complexity. In PRTESLA-C, per-round authentication avoids authentication-induced interval aggregation: each completed PTP exchange contributes independently.

Figure 2. PRTESLA-C Workflow. The same workflow applies independently to the Sync domain (S) and Delay domain (D). MiS binds Sync/Follow Up fields, while MiD binds Delay Req/Delay Resp fields and the requesting RU identity.

Dimension 3: Authentication Application Timing. This dimension determines when a sample affects the local clock. In (a) verify-then-apply, the receiver waits for key disclosure and MAC verification before applying the sample, avoiding unauthenticated servo inputs but introducing stale control inputs. In (b) apply-then-verify, the receiver applies the sample immediately, verifies it after disclosure, and corrects persistent state on failure. This creates a short speculative window, analyzed in Section 4.3, but preserves PTP servo timing; PRTESLA-C adopts this model.

4.2. PRTESLA-C: Per-Round TESLA with Correction Guided by the design taxonomy in Section 4, we present PRTESLA-C (Per-Round TESLA with Correction), a per-round delayed-authentication protocol for securing PTP

(D)

synchronization in O-RAN. PRTESLA-C integrates (i) perround key disclosure aligned with the PTP four-message exchange, (ii) independent per-domain authentication of Sync and Delay contributions each round, and (iii) an applythen-verify-and-correct execution model that preserves realtime responsiveness while enabling retrospective integrity enforcement. We describe PRTESLA-C as a sequence of phases executed by the DU (PTP master) and each RU (PTP slave).

Delay domain. Let Mi denote the canonical payload constructed from the Delay Req and Delay Resp messages (D) of round i. To prevent cross-slave replay, Mi explicitly binds the requesting RU’s port identity PIDRU , ensuring that a Delay Resp authenticated for one slave cannot be accepted by another. After completing the exchange, the DU computes   (D) (D) (D) MACi = ASCON F ′ (Ki ), Mi

4.2.1. Phase 1: Setup and Bootstrapping. The DU initializes two independent one-way key chains, one per authentication domain: the Sync domain (DS ), covering Sync and Follow Up messages, and the Delay domain (DD ), covering (·) Delay Req and Delay Resp exchanges. Each chain {KN , (·) (·) KN −1 , . . . , K0 } is constructed via a cryptographic oneway function F with Ki = F (Ki+1 ), with domain separation enforced by distinct derivation contexts. The chain (S) (D) anchors K0 and K0 are provisioned to each RU over a minimally trusted bootstrap channel, together with the disclosure delay d and an initial round index i0 . A separate derivation function F ′ is used to derive per-round MAC keys as Ki′ = F ′ (Ki ), ensuring that the MAC key and the chain key are domain-separated and that knowledge of a MAC key does not compromise the key-chain structure.

and appends MACi ∥Ki−d ∥RolloverMetai to Delay Resp, leaving Delay Req unmodified. Symmetrically, (D) RolloverMetai carries the next-epoch commitment and switch point for the Delay domain independently, since the two domains may exhaust their respective key chains at different times when operating at different exchange rates. Fast path and authentication state. Upon receiving an augmented Follow Up or Delay Resp, the RU records the authentication material in the corresponding TESLA stream. Each stream maintains independent state comprising the domain, epoch, sequence identifier, canonical payload, MAC tag, and disclosed-key information; the sequence identifier associates the two messages of each authenticated pair, while the domain and epoch metadata ensure correct verification context. Crucially, delayed authentication does not stall the PTP pipeline. Samples that pass PTP matching and metadata checks are applied immediately: the RU derives offset and path-delay estimates from the received timestamps and updates the clock servo exactly as in standard PTP. The associated authentication and recovery context is recorded in a ledger entry Li ; for Delay samples, Li additionally retains the state needed to reconstruct verified delay history. Once the corresponding key is disclosed, the buffered materials in Li are verified independently per domain; failure triggers the recovery procedure described in Section 4.2.4. To support multi-RU deployments, all RUs process every Delay Resp to advance shared authentication state, but apply path-delay updates only from responses whose requestingPortIdentity matches their own port.

4.2.2. Phase 2: Round Execution and Immediate Application. In steady state, PRTESLA-C authenticates each round as two independent domain contributions: the Sync domain covering Sync/Follow Up, and the Delay domain covering Delay Req/Delay Resp. The two pairs serve distinct roles and may operate at different exchange rates: Sync/Follow Up carry master-to-slave timing information for offset estimation, while Delay Req/Delay Resp perform a slave-initiated round-trip for path-delay measurement. A unified bundle would couple their buffering and disclosure behavior, causing out-of-order or rate-mismatched arrivals to break bundle assembly. Separate domains prevent failures or replays in one direction from contaminating the other’s authentication state, and scope recovery accordingly: Sync failures reset servo state, while Delay failures rebuild the path-delay estimator. (S)

Sync domain. Let Mi denote the canonical payload constructed from the timing-sensitive fields of the Sync and Follow Up messages of round i (timestamps, correction fields, source port identity, and sequence identifier). After transmitting Follow Up, the DU computes   (S) (S) (S) MACi = ASCON F ′ (Ki ), Mi (S)

(S)

(S)

and appends MACi ∥Ki−d ∥RolloverMetai to Follow Up, leaving the high-rate Sync message unmodified to minimize overhead on the most latency-sensitive message (S) type. RolloverMetai carries the next-epoch chain commitment and switch point for the Sync domain, and is nonempty only when the current epoch is nearing exhaustion (Section 4.2.5).

(D)

(D)

(D)

4.2.3. Phase 3: Delayed Verification. When the RU re(·) ceives a disclosed key Ki−d piggybacked on a later round, it validates the key incrementally against the last accepted (·) disclosure Klast : (·)

(·)

F ∆ (Ki−d ) = Klast

where ∆ is the index gap between the two disclosures. This check is O(∆), reducing to a single F evaluation under normal operation (∆ = 1), and is performed independently per domain. If valid, the RU derives the MAC key ′(·) (·) Ki−d = F ′ (Ki−d ), recomputes the MAC over the buffered canonical payload, and compares it against the stored tag. Successful verification marks the domain contribution as authenticated; the Sync and Delay domains are verified and released independently.

Loss of a disclosed key or a bundle component causes the affected sample to time out at deadline W and be treated as a verification failure, triggering recovery (Section 4.2.4). Crucially, a missing disclosure does not invalidate subse(·) quent rounds: since the incremental check uses Klast rather than a fixed anchor, the receiver skips the gap and resumes verification from the next successfully received key. 4.2.4. Phase 4: Correction upon Verification Failure. If delayed verification fails in either domain, due to a MAC mismatch, invalid key disclosure, missing bundle components, or a verification timeout, PRTESLA-C applies a control-level recovery action to prevent unauthenticated material from continuing to bias the RU clock. The ledger entry Li retains the authentication context for the affected timing sample and, for Delay-domain samples, the state needed to reconstruct verified delay history. PRTESLAC does not roll back wall-clock time, as doing so would disrupt higher-layer operation; instead, recovery removes unauthenticated samples from persistent estimator and servo state, preventing their influence from accumulating beyond the disclosure window. Recovery is scoped to the affected domain. For Delaydomain failures, PRTESLA-C resets the path-delay estimation state and reconstructs it by replaying previously verified Delay samples in order, excluding the rejected sample while preserving authenticated history. For Sync-domain failures, PRTESLA-C resets the affected clock-servo and timestamp-processing state without replaying prior Sync samples, since replaying stale offsets into a closed-loop servo may reintroduce phase disturbances. Subsequent synchronization resumes from fresh samples, and any physical phase deviation induced during the speculative window is treated as transient and corrected by the servo over time. This coarse-grained, domain-scoped recovery removes the persistent influence of invalid material while keeping the time-critical PTP processing path non-blocking. 4.2.5. Phase 5: Key-Chain Rollover. PRTESLA-C organizes each domain’s key chain into fixed-length epochs, with rollover proceeding independently per domain, as the Sync and Delay chains may be exhausted at different times when operating at different exchange rates. Because key disclosure lags transmission by d rounds, the final d samples of an epoch are verified only after the epoch boundary. PRTESLA-C handles this via a carry-over disclosure mechanism: the first d TLVs of the new epoch piggyback the previous-epoch disclosed keys needed to verify those tail samples, closing the verification gap at the boundary. R rounds before exhaustion, the DU preannounces the next chain’s public commitment via RolloverMeta(·) (Section 4.2.2). The receiver caches this commitment and accepts next-epoch keys only after validating them against it, guarding against epoch-boundary forgery. The transmitter advances the epoch once the current chain is exhausted; the receiver follows upon successful validation. This design rotates key chains per domain without interrupting the PTP pipeline or altering d.

4.3. Timing Analysis Speculative window. Let fS and fD denote the exchange rates of the Sync and Delay domains. With disclosure delay d, authentication material in domain X ∈ {S, D} becomes verifiable after d domain samples, yielding a speculative window d + τX WX ≈ fX where τX captures bounded propagation, scheduling, and processing delay. At most d samples per domain remain speculative at any time. For system-level bounds, we take the worst case across domains, W = max(WS , WD ). Bounded transient deviation. Let x(t) denote the RU phase error, and let the clock servo enforce a bounded control input |u(t)| ≤ Smax . Any unauthenticated influence accumulated during the speculative window is bounded by |∆x| ≤ Smax W,

W = max(WS , WD )

Upon verification failure, PRTESLA-C applies the controllevel recovery of Section 4.2.4, ensuring that rejected samples cannot persistently bias synchronization state beyond this bound.

4.4. Security Analysis PRTESLA-C provides scalable one-to-many authentication for PTP synchronization, bounding the window during which unauthenticated material may influence clock state to W . Confidentiality is out of scope and can be layered independently, e.g., via link-layer protection. Authenticity and integrity. Each domain contribution is (·) authenticated under key Ki and verified upon delayed disclosure. Under standard assumptions on the MAC and one-way function, an adversary without the undisclosed key cannot forge a valid tag; tampering is therefore detected at verification time. On failure, PRTESLA-C applies domainscoped recovery: Sync failures reset servo and timestampprocessing state, while Delay failures rebuild the path-delay estimator from verified history. Forged or modified samples thus have at most bounded transient influence and cannot persistently bias synchronization state. Replay and reordering. Each authenticated bundle is scoped by domain, epoch, and sequence identifier, ensuring buffered material is verified in the correct context. Replayed or reordered bundles inconsistent with this scope are rejected before or upon delayed verification; any transient influence is bounded by W and removed by the recovery procedure. Carry-over disclosure at epoch boundaries preserves verification coverage for the final d tail samples, eliminating gaps during key-chain rollover. Delay manipulation. An on-path adversary may bias offset or path-delay estimation by injecting asymmetric or selective delay without modifying packet contents. Payload modifications are detected as integrity failures at verification time. Schedule-consistent delay on otherwise authentic packets is not eliminated by authentication alone: such packets may

transiently bias the servo or delay estimator within W , with phase deviation bounded by |∆x| ≤ Smax W (Section 4.3). Manipulations that prevent bundle completion or key disclosure before the verification deadline are treated as availability disruptions and trigger recovery. Against a persistent adversary that repeats this across consecutive windows, PRTESLA-C’s recovery procedure (Section 4.2.4) resets the affected servo or delay-estimator state at each verification boundary, preventing bias from accumulating across windows. The long-term effect is therefore a degraded, but bounded, accuracy within each window, not unbounded drift. This residual exposure is a fundamental limitation of delayed authentication shared by all TESLA-based schemes; stronger guarantees require orthogonal mechanisms such as delay-asymmetry consistency checks [4, 19, 31]. Packet loss and dropping. Packet loss reduces the rate of valid timing samples but does not introduce persistent authenticated bias. Missing bundle components or undisclosed keys cause the affected sample to time out and be treated as a verification failure; the deadline W ensures speculative state is resolved within a bounded interval, and the recovery procedure prevents incomplete samples from continuing to influence RU state. Forward security and compromise containment. PRTESLA-C provides compromise containment by ensuring that RUs do not hold long-lived secrets capable of authenticating future DU-originated synchronization messages. Each authentication domain uses a one-way key chain, and disclosing Ki−d does not allow an adversary to recover any undisclosed key Kj for j > i − d, assuming F is one-way. Therefore, keys learned by receivers are useful only for verifying expired rounds, not for generating valid tags for future rounds. Even if an adversary partially compromises an RU and extracts its local authentication state, future rounds remain unforgeable except within the bounded speculative window W . This differs fundamentally from conventional symmetric-key protection. With a shared group MAC key, every RU stores the same long-lived signing-capable secret; compromising a single RU therefore enables the adversary to forge synchronization traffic for the entire multicast group until the group is rekeyed. Pairwise symmetric MACs reduce this blast radius but do not eliminate the underlying exposure. If the adversary extracts the DU–RU key from a compromised RU, that key remains usable to generate valid authentication tags for future synchronization messages within the compromised association until rekeying completes. Thus, pairwise keying confines compromise to one DU–RU association, but still grants a persistent future-forgery capability for that association. In contrast, PRTESLA-C changes the receiver-side exposure model. RUs learn only delayed disclosure keys after the corresponding rounds have expired for transmission, and the one-way key chain prevents deriving future keys from disclosed ones. Consequently, RU memory disclosure exposes at most expired verification material and bounded

speculative state, rather than a persistent secret for future forgery. This per-round disclosure structure directly limits compromise amplification: a compromised RU cannot forge synchronization traffic beyond the current disclosure window W , and key-chain rollover further bounds the lifetime of any exposed state to the current epoch of the affected domain.

5. Implementation We implement PRTESLA-C by extending linuxptp with about 7K lines of C/C++ code. We augment the Sync, Follow Up, Delay Req, and Delay Resp state machines with custom Annex-K TLVs carrying authentication tags, disclosed keys, and rollover metadata. Security logic runs in user space, while timestamping and packet scheduling remain on the kernel fast path, preserving compatibility with hardware timestamping. Key-chain evolution, disclosure handling, and verification execute asynchronously to avoid perturbing deterministic timing. We instantiate F and F ′ with domain-separated ASCON-based primitives at 128bit security. Runtime parameters, including Tint and disclosure delay d, are configurable; our evaluation uses d = 2.

6. Evaluation 6.1. Experimental Setup We evaluate PRTESLA-C on an O-RAN-like fronthaul testbed interconnected by an Arista 7010T-48 top-of-rack switch (Figure 3). The baseline topology consists of an DU (PTP master), an RU (PTP slave), and an impairment node for controlled MITM attacks (replay, loss, and delay manipulation). Single-RU topology. The DU and RU run on dedicated Linux hosts with an Intel Core i7-3770 CPU, 16 GB RAM, and a Mellanox ConnectX-4 Lx EN NIC (MCX4121AACAT, 2×25 GbE), providing hardware PTP/PHC timestamping via SO_TIMESTAMPING. All nodes run Ubuntu 22.04 (kernel 6.8) with linuxptp v4.4 [1] over 25 GbE full-duplex links. This topology is used for all baseline comparisons and attack experiments. Multi-RU topology. To study one-to-many synchronization, we extend the setup to a single-master, two-slave topology within the same L2 broadcast domain. Two logical RUs are emulated via isolated Linux network namespaces on a shared host, connected to the master-facing network through bridged virtual interfaces to preserve multicast PTP dissemination. The DU retains hardware timestamping; the namespace-based RUs use software timestamping, approximating two independent RUs on the same switch. End-to-end compatibility. To confirm that PRTESLA-C does not interfere with higher-layer O-RAN components, we perform E2E functional validation using an srsRAN-based pipeline: a DU-side gNB (gnb-oran) and an RU emulator (ru_emulator) interconnected via a Linux veth pair, with PRTESLA-C enabled on the synchronization path.

RU1: NS-1, SW TS Arista 7010T Switch

O-DU

Multi O-RUs

RU2: NS-2, SW TS

HW TS

HW TS

ConnectX-4 Lx NIC

ConnectX-4 Lx NIC

Single O-RU

Figure 3. O-RAN PTP evaluation testbed: DU (master) and RU (slave) interconnected via a switch.

Validation succeeds if (i) the RU emulator initializes and binds to the fronthaul interface, (ii) the gNB completes OFH setup, and (iii) the system runs continuously without synchronization loss, RU–DU interface errors, or abnormal PTP behavior.

6.2. Baselines and Metrics We evaluate PRTESLA-C along four axes: timing accuracy, timing stability, runtime overhead, and resilience to active attacks. All experiments use identical hardware, background traffic, and synchronization parameters. Each experiment is repeated 5 times; we report means with variability where appropriate. Baselines. We compare against S0 (plain IEEE 1588, no authentication); S1 (Annex K-style shared-key authentication with AES-GCM (S1-1, as in MACsec [16]), HMACSHA256 (S1-2, native to linuxptp), and ASCON-MAC (S1-3)); S2 (TESLA-style delayed disclosure with ASCON under verify-then-apply semantics, at three keying granularities: per-interval last-round (S2-1), per-interval averaged (S2-2), and per-round (S2-3)); and PRTESLA-C (per-round disclosure with apply-then-verify-and-correct and ledgerbased correction). Because S2 variants require per-scheme instrumentation and timestamping assumptions incompatible with namespace-based emulation, the full baseline comparison is restricted to the single-RU topology. Multi-RU experiments compare S1-1 (MACsec-compatible) and S13 (standard ASCON-based) as representative shared-key baselines alongside PRTESLA-C. E2E experiments compare PRTESLA-C against S0 only, focusing on functional correctness and timing preservation under a realistic O-RAN stack. Metrics. We evaluate timing precision and control-loop behavior via three primary metrics: RMS clock offset, capturing synchronization accuracy (mean offset vanishes in steady state, making RMS the appropriate measure of residual deviation); RMS frequency correction, reflecting servo stability (large RMS indicates control-loop oscillation); and mean one-way delay, assessing path-delay estimation quality. Standard deviations are reported alongside each metric to quantify run-to-run variability. In the single-RU topology, we additionally measure CPU and memory usage, packetsize overhead, and microarchitectural indicators (IPC, stall cycles, context switches), and assess resilience under active attacks.

6.3. Single-RU Evaluation 6.3.1. Timing Performance: Accuracy and Stability. Figure 4 reports RMS clock offset, frequency correction, and one-way delay across all schemes. Shared-key schemes (S1x) match S0 closely across all metrics, as symmetric MAC verification completes off the critical path without delaying timestamp acquisition or servo updates. All S2-x variants exhibit catastrophic timing degradation, that is, RMS offsets and frequency corrections exceed S0 by six orders of magnitude. The root cause is structural: withholding servo updates until key disclosure forces the control loop to operate on stale timing, introducing an effective latency W ≈ d/r + τ that far exceeds the servo’s stability margin. Notably, S2-3 (per-round TESLA) offers no improvement over per-interval variants; under verify-thenapply semantics, finer disclosure granularity stalls the servo more frequently, amplifying jitter rather than reducing it. This underscores that the decisive factor is not disclosure granularity but whether servo updates are decoupled from the authentication path. PRTESLA-C achieves timing accuracy and stability indistinguishable from S0 and S1-x across all metrics. Synchronization updates are applied immediately at the native round cadence; authentication executes asynchronously without touching the control-loop path, and the per-round correction mechanism absorbs rejected rounds without disrupting servo operation. Together, these results confirm that apply-then-verify-and-correct successfully decouples authentication latency from synchronization responsiveness. 6.3.2. Overhead: Runtime, Bandwidth, and Microarchitectural Effects. Bandwidth overhead. Table 1 shows permessage TLV sizes across schemes. Shared-key schemes (S1-x) attach a MAC to every message uniformly, imposing overhead on the high-rate Sync, Delay Req path regardless of message frequency. PRTESLA-C, like S2, concentrates authentication metadata in lower-rate messages: Sync and Delay Req carry only a compact sequence tag, while MACs, disclosed keys, and rollover metadata are confined to Follow Up, Delay Resp, and Announce. This asymmetry is deliberate, that is, fronthaul bandwidth is most sensitive to overhead on the highest-frequency messages, and PRTESLA-C preserves that path with minimal augmentation. Runtime overhead. As shown in Table 2, all schemes consume well under 1% CPU on both DU and RU, confirming that authentication is computationally lightweight in practice. On the DU, differences across schemes are negligible, as the sender’s workload is dominated by key lookup and tag generation rather than verification. On the RU, PRTESLA-C incurs modest CPU usage comparable to shared-key schemes, which is a natural consequence of combining immediate application with asynchronous perround verification. Memory consumption on the RU follows verification window length: per-interval TESLA variants (S2-1, S2-2) require larger buffers to hold unverified rounds over longer windows, while PRTESLA-C and S2-3 (per-

rms: 35 std: 6

40

rms: 29 std: 5

rms: 27.6M† std: 7.0M

rms: 89.3M† std: 91.2M

rms: 35 std: 3

rms: 32 std: 4 rms: 28 std: 2

30 20 10

5000 rms: 20.3M† std: 4.0M

4000 3000

rms: 2737 std: 33

rms: 2755 std: 26

rms: 2709 std: 35

rms: 15.4M† std: 3.1M

rms: 11.8M† std: 5.0M

rms: 2731 std: 25

rms: 2685 std: 29

2000 1000

0

3000

One-way delay (ns)

rms: 31.7M† std: 21.1M

50

Freq. correction (ppb)

Master offset (ns)

60

2000

-1

S1

-2 S1

-3

-1

S1

-2

S2

-3

S2

S2

SL

mean: 1850 std: 3

1000 500 0

S0

C A-

mean: 1850 mean: 1878 mean: 1888 mean: 1872 std: 5 std: 6 std: 6 std: 8

1500

0 S0

mean: 0.1M† mean: 0.2M† mean: 101.2M† std: 70934 std: 92129 std: 157.1M

2500

TE PR

-1

S1

-2

S1

-3

S1

-1

-2

S2

S2

-3

S2

S0

-C LA

S TE PR

-1

-2

S1

S1

-3

S1

-1

-2

S2

S2

S2

-3

SL

C A-

TE PR

S1-1

0 0 0 0 0

S1-2

26 26 26 26 26

S1-3

42 42 42 42 42

26 26 26 26 26

S2

PRTESLA-C

78 10 46 10 46

78 10 46 10 46

TABLE 2. RUNTIME OVERHEAD AND MICROARCHITECTURAL EFFICIENCY ACROSS SCHEMES .

Runtime Overhead Scheme

S0 S1-1 S1-2 S1-3 S2-1 S2-2 S2-3

Microarch. Efficiency

CPUDU (%) ↓

CPURU (%) ↓

MemRU (KB) ↓

IPC ↑

Stall (%) ↓

Ctx-sw (K/s) ↓

0.43 0.40 0.55 0.50 0.45 0.45 0.50

0.33 0.70 0.75 0.50 0.50 0.55 0.54

3968 6400 6016 2688 6144 5632 4224

0.35 0.51 0.64 0.27 0.49 0.48 0.38

81.51 78.71 75.18 85.92 77.63 78.15 82.37

16.71 11.21 10.65 12.72 15.37 15.14 12.56

PRTESLA-C 0.45 0.73 4224 0.31 84.82 10.55 CPU: %usr + %sys. IPC: instructions per cycle. Stall: front-end stalled cycles. Ctx-sw: context switches/s; elevated in S2-1/S2-2 due to deferredverification buffering. Means over 5 runs. ↓ lower is better, ↑ higher is better. Cell color: best to worst within each column.

round) share a substantially smaller footprint, consistent with their bounded, short verification windows. Microarchitectural efficiency. S2-1 and S2-2 exhibit elevated context-switch rates relative to all other schemes, reflecting the scheduling pressure of long buffering windows that require periodic background wake-ups to resolve pending rounds. PRTESLA-C, by contrast, maintains contextswitch rates comparable to the unsecured baseline, as its short, fixed verification window resolves predictably within each round cadence, avoiding irregular wake-up patterns. 6.3.3. Security Validation under Active Attacks. We evaluate PRTESLA-C under controlled on-path attacks at varying attack rates p (the probability that the adversary perturbs a given synchronization round), shown in Figure 5. MITM tampering. The adversary modifies packet payloads

250 200 150 100 50 0

1950 1900 1850 1800 1750 1700

0

10 20 30 40 50 60

Attack rate (%)

100

Replay Attack Delay (ns)

Announce Sync Follow Up Delay Req Delay Resp

S0

300

Replay Attack RMS (ns)

Packet

MITM Attack RMS (ns)

TABLE 1. TLV SIZES ( BYTES ) FOR PTP MESSAGES ACROSS SCHEMES .

MITM Attack Delay (ns)

Figure 4. Timing accuracy across authentication schemes.

80 60 40 20 0

0

10 20 30 40 50 60

Attack rate (%)

1950 1900 1850 1800 1750 1700

0

10 20 30 40 50 60

Attack rate (%)

0

10 20 30 40 50 60

Attack rate (%)

Figure 5. Impact of MITM and Replay attacks on PRTESLA-C under varying attack rates. Shaded regions denote ± standard deviation.

before they reach the RU. Tampered rounds cannot carry valid authentication tags without the undisclosed key; they fail delayed verification and their speculative contributions are deterministically retracted via the correction mechanism. RMS offset grows steadily with attack rate as valid updates become sparse and the correction-to-update ratio rises, but one-way delay shows no systematic bias since rejected rounds are excluded from the path-delay estimator by construction. Replay attacks. Replayed bundles carry stale sequence identifiers and are rejected before application by the perdomain monotonicity check, precluding any direct influence on clock state. From the servo’s perspective, replay is indistinguishable from packet loss: it reduces valid update rate without introducing erroneous inputs. RMS offset remains lower than under MITM at comparable attack rates, though variance increases substantially at high rates as update intervals become irregular. One-way delay shows no systematic bias, though variance similarly grows at high attack rates. Across both attack types, PRTESLA-C prevents persistent synchronization drift at all tested rates. The contrasting degradation profiles, i.e., correction-induced instability under MITM versus loss-induced variance under replay, reflect the distinct interception points: post-application for integrity failures, pre-application for freshness violations.

6.4. Multi-RU Scalability We evaluate PRTESLA-C under a one-to-many topology in which a single DU simultaneously serves two RU slaves within the same L2 multicast domain. As detailed in Section 6.1, both slaves are emulated via network namespaces on a shared host and rely on software timestamping, which introduces higher baseline jitter than hardware PHC

10000

1000 800

rms: 653 std: 128

600

rms: 659 std: 98

rms: 318 std: 140

rms: 633 std: 91

rms: 261 std: 94

400

rms: 149 std: 64

200 0

One-way delay (ns)

Master offset (ns)

1200

8000

mean: 7309 std: 72 mean: 6788 std: 39

mean: 7143 std: 108 mean: 6707 std: 135

mean: 7318 std: 44 mean: 6837 std: 44

6000 4000 2000 0

Slave1

Slave2

S1-1

Slave1

Slave2

S1-3

Slave1

Slave2

PRTESLA-C

Slave1

Slave2

S1-1

Slave1

Slave2

S1-3

Slave1

Slave2

PRTESLA-C

Figure 6. Multi-RU synchronization results with two slaves in the same multicast domain.

timestamps and accounts for the elevated absolute offset values relative to the single-RU experiments. Figure 6 reports RMS clock offset and mean one-way delay for both slaves across S1-1 (MACsec-based), S13 (ASCON-based), and PRTESLA-C. Two observations stand out. First, the two slaves exhibit consistent numerical differences across all schemes, which is a result of asymmetric scheduling pressure and unequal resource contention between namespace instances on the shared host, rather than any scheme-specific behavior. Second, within each slave, timing accuracy under PRTESLA-C is closely comparable to the shared-key baselines: PRTESLA-C introduces no systematic offset bias or delay inflation when authenticating multiple slaves concurrently. This confirms that the perround authentication and asynchronous verification path do not add measurable latency to the synchronization control loop even under concurrent multi-slave operation. Correctness under concurrent operation is preserved through strict per-slave state isolation. Each RU maintains an independent authentication context—comprising its key-chain state, verification buffer, and round indices—and bundles are bound to individual slaves via PTP port identifiers (sourcePortIdentity and requestingPortIdentity), precluding cross-RU state interference. The Delay domain’s explicit slaveidentity binding (Section 4.2.2) further ensures that a Delay Resp authenticated for one slave cannot be accepted by another, even when both share the same multicast synchronization stream. Together, these results confirm that PRTESLA-C scales to concurrent multi-slave deployments without compromising authentication isolation or timing accuracy.

6.5. End-to-End System Evaluation We evaluate PRTESLA-C in an end-to-end O-RAN deployment based on srsRAN, covering RU–DU initialization, Open Fronthaul (OFH) establishment, UE attachment, and steady-state data transmission. With PRTESLA-C enabled on the synchronization path, the system initializes successfully: the RU emulator binds to the fronthaul interface, the DU-side gNB completes OFH setup, and the UE attaches and operates normally. No abnormal PTP state transitions, synchronization loss, or RU–DU interface errors are observed, indicating that PRTESLA-C integrates transparently with the O-RAN control and data planes. In steady state, PRTESLA-C preserves the timing behavior of the plain (S0) baseline. In the single-RU configura-

tion, RMS clock offset remains within the same sub-200 ns regime, with comparable frequency-control dynamics and one-way delay statistics. In a dual-RU configuration where two logical RUs synchronize concurrently with a single DU, PRTESLA-C maintains strict per-RU authentication state and stable operation. RMS offset remains in the same microsecond-level range as the baseline (1.5–1.8 µs for S0 and 1.5–2.0 µs for PRTESLA-C), while one-way delay remains comparable (4.4–4.8 µs vs. 4.6–5.5 µs). The higher absolute values stem from software timestamping and virtualization overhead in the RU emulator environment rather than the authentication mechanism. Beyond the initial keychain bootstrap, PRTESLA-C requires no additional configuration. Overall, these results demonstrate that PRTESLAC preserves interoperability and stable synchronization in both single- and multi-RU O-RAN deployments.

7. Related Works O-RAN architectures and security. Polese et al. [37] and Azariah et al. [11] provide comprehensive overviews of O-RAN architecture and emphasize the critical role of fronthaul synchronization for 5G performance. Empirical work demonstrates the fragility of this infrastructure: Xing et al. [42] show that MITM manipulation of fronthaul traffic triggers large-scale service degradation, while Groen et al. [19, 20] demonstrate that PTP spoofing and delay attacks severely disrupt O-RAN timing. Industry analyses identify the open fronthaul as a major attack surface and recommend transport-layer protections such as TLS, IPsec, or MACsec [13]. Prior work on O-RAN synchronizationplane security [12, 15, 16, 27] largely focuses on generic transport protection without accounting for the impact on tight timing loops. Our work directly targets the synchronization plane, co-designing lightweight authentication with PTP’s control loop under O-RAN’s strict timing constraints. PTP security threats and defenses. RFC 7384 [29] identifies PTP threats such as impersonation, replay, and delay attacks; practical studies further show that delay manipulation degrades synchronization in data-center [14] and 5G [5] settings. Existing defenses include elliptic-curve signatures [24], Annex K-style symmetric authentication [22, 28, 39], shared-key software authentication [38], architectural PTP changes [32], and PTPsec’s path-asymmetry analysis [18]. However, they typically assume stable pairwise keying, add per-packet overhead, or rely on deployment assumptions ill-suited to O-RAN fronthaul, where multicast distribution, endpoint compromise, and strict timing budgets must be addressed together. Our work provides lightweight, synchronization-aware authentication that preserves tight timing constraints while scaling to broadcast synchronization.

8. Conclusion We address the lack of practical authentication for ORAN fronthaul synchronization. PRTESLA-C combines perround delayed disclosure with apply-then-verify-and-correct

execution, allowing PTP samples to drive the servo immediately while removing invalid samples from persistent state after verification. Our linuxptp prototype preserves nearbaseline synchronization accuracy with low overhead and resists spoofing and replay while bounding the impact of manipulation within the disclosure window. These results show that scalable PTP authentication is feasible under ORAN fronthaul timing constraints.

References [1]

Linuxptp project. https://github.com/richardcochran/ linuxptp, 2026. [2] ptp4l linux man page. https://linux.die.net/man/8/ptp4l, 2026. [3] 3GPP. 3gpp tr 36.819 v11.2.0. Technical report, 2013. [4] Waleed Alghamd and Michael Schukat. A detection model against precision time protocol attacks. In 2020 3rd International Conference on Computer Applications & Information Security (ICCAIS), pages 1–3. IEEE, 2020. [5] Waleed Alghamdi and Michael Schukat. Precision time protocol attack strategies and their resistance to existing security extensions. Cybersecurity, 4(1):12, 2021. [6] O-RAN Alliance. O-ran xhaul transport requirements 1.0. Technical report, 2021. [7] O-RAN Alliance. O-ran control, user and synchronization plane specification 17.01. Technical report, 2025. [8] O-RAN Alliance. O-ran security requirements and controls specifications 11.0. Technical report, 2025. [9] O-RAN Alliance. O-ran security threat modeling and risk assessment. Technical report, 2025. [10] Tolga O Atalay, Sudip Maitra, Dragoslav Stojadinovic, Angelos Stavrou, and Haining Wang. Securing 5g openran with a scalable authorization framework for xapps. In IEEE INFOCOM 2023-IEEE Conference on Computer Communications, pages 1–10. IEEE, 2023. [11] Wilfrid Azariah, Fransiscus Asisi Bimo, Chih-Wei Lin, Ray-Guang Cheng, Navid Nikaein, and Rittwik Jana. A survey on open radio access networks: Challenges, research directions, and open source approaches. Sensors, 24(3):1038, 2024. [12] Joo Yeon Cho and Andrew Sergeev. Secure open fronthaul interface for 5g networks. In Proceedings of the 16th International Conference on Availability, Reliability and Security, pages 1–6, 2021. [13] Quad Critical and Emerging Technology Working Group. Open ran security report. 2023. [14] Casimer DeCusatis, Robert M Lynch, William Kluge, John Houston, Paul A Wojciak, and Steve Guendert. Impact of cyberattacks on precision time protocol. IEEE Transactions on Instrumentation and Measurement, 69(5):2172–2181, 2019. [15] Daniel Dik and Michael Stübert Berger. Transport security considerations for the open-ran fronthaul. In 2021 IEEE 4th 5G World Forum (5GWF), pages 253– 258. IEEE, 2021.

[16] Daniel Dik and Michael Stübert Berger. Open-ran fronthaul transport security architecture and implementation. IEEE Access, 11:46185–46203, 2023. [17] Christoph Dobraunig, Maria Eichlseder, Florian Mendel, and Martin Schläffer. Ascon v1. 2: Lightweight authenticated encryption and hashing. Journal of Cryptology, 34(3):33, 2021. [18] Andreas Finkenzeller, Oliver Butowski, Emanuel Regnath, Mohammad Hamad, and Sebastian Steinhorst. Ptpsec: Securing the precision time protocol against time delay attacks using cyclic path asymmetry analysis. In IEEE INFOCOM 2024-IEEE Conference on Computer Communications, pages 461–470. IEEE, 2024. [19] Joshua Groen, Simone Di Valerio, Imtiaz Karim, Davide Villa, Yiewi Zhang, Leonardo Bonati, Michele Polese, Salvatore D’Oro, Tommaso Melodia, Elisa Bertino, et al. Timesafe: Timing interruption monitoring and security assessment for fronthaul environments. arXiv preprint arXiv:2412.13049, 2024. [20] Joshua Groen, Salvatore D’Oro, Utku Demir, Leonardo Bonati, Davide Villa, Michele Polese, Tommaso Melodia, and Kaushik Chowdhury. Securing o-ran open interfaces. IEEE Transactions on Mobile Computing, 23(12):11265–11277, 2024. [21] Mohammad Asif Habibi, Bin Han, Meysam Nasimi, Nandish P Kuruvatti, Amina Fellan, and Hans D Schotten. Towards a fully virtualized, cloudified, and slicingaware ran for 6g mobile networks. In 6G Mobile Wireless Networks, pages 327–358. Springer, 2021. [22] Bernd Hirschler and Albert Treytl. Validation and verification of ieee 1588 annex k. In 2011 IEEE International Symposium on Precision Clock Synchronization for Measurement, Control and Communication, pages 44–49. IEEE, 2011. [23] Cheng-Feng Hung, You-Run Chen, Chi-Heng Tseng, and Shin-Ming Cheng. Security threats to xapps access control and e2 interface in o-ran. IEEE Open Journal of the Communications Society, 5:1197–1203, 2024. [24] Eyal Itkin and Avishai Wool. A security analysis and revised security extension for the precision time protocol. IEEE Transactions on Dependable and Secure Computing, 17(1):22–34, 2017. [25] Leon Janzen, Lucas Becker, Colin Wiesenäcker, and Matthias Hollick. Oh no, my {RAN}! breaking into an {O-RAN} 5g indoor base station. In 18th USENIX WOOT Conference on Offensive Technologies (WOOT 24), pages 101–115, 2024. [26] Felix Klement, Alessandro Brighente, Michele Polese, Mauro Conti, and Stefan Katzenbeisser. Securing the open ran infrastructure: Exploring vulnerabilities in kubernetes deployments. In 2024 IEEE 10th International Conference on Network Softwarization (NetSoft), pages 185–189. IEEE, 2024. [27] Assrar Maamary, Hyame Assem Alameddine, Mourad Debbabi, and Chadi Assi. Synchronization plane in oran: Overview, security and research directions. IEEE Communications Magazine, 63(2):88–94, 2024.

[28] Dragos Maftei, Radim Bartos, Bob Noseworthy, and Timothy Carlin. Implementing proposed ieee 1588 integrated security mechanism. In 2018 IEEE International Symposium on Precision Clock Synchronization for Measurement, Control, and Communication (ISPCS), pages 1–6. IEEE, 2018. [29] T Mizrahi. Rfc 7384: Security requirements of time protocols in packet switched networks, 2014. [30] Tal Mizrahi. Time synchronization security using ipsec and macsec. In 2011 IEEE International Symposium on Precision Clock Synchronization for Measurement, Control and Communication, pages 38–43. IEEE, 2011. [31] Bassam Moussa, Mourad Debbabi, and Chadi Assi. A detection and mitigation model for ptp delay attack in a smart grid substation. In 2015 IEEE International Conference on Smart Grid Communications (SmartGridComm), pages 497–502. IEEE, 2015. [32] Bassam Moussa, Mourad Debbabi, and Chadi Assi. A detection and mitigation model for ptp delay attack in an iec 61850 substation. IEEE Transactions on Smart Grid, 9(5):3954–3965, 2016. [33] Bassam Moussa, Chantale Robillard, Alf Zugenmaier, Marthe Kassouf, Mourad Debbabi, and Chadi Assi. Securing the precision time protocol (ptp) against fake timestamps. IEEE communications letters, 23(2):278– 281, 2018. [34] Esteban Municio, Gines Garcia-Aviles, Andres GarciaSaavedra, and Xavier Costa-Pérez. O-ran: Analysis of latency-critical interfaces and overview of time sensitive networking solutions. IEEE Communications Standards Magazine, 7(3):82–89, 2023. [35] Nokia. Open ran security. Technical report, 2022. [36] Adrian Perrig, J Doug Tygar, Adrian Perrig, and JD Tygar. Tesla broadcast authentication. Secure Broadcast Communication: In Wired and Wireless Networks, pages 29–53, 2003. [37] Michele Polese, Leonardo Bonati, Salvatore D’oro, Stefano Basagni, and Tommaso Melodia. Understanding o-ran: Architecture, interfaces, algorithms, security, and research challenges. IEEE Communications Surveys & Tutorials, 25(2):1376–1411, 2023. [38] Filip Rezabek, Max Helm, Tizian Leonhardt, and Georg Carle. Ptp security measures and their impact on synchronization accuracy. In 2022 18th International Conference on Network and Service Management (CNSM), pages 109–117. IEEE, 2022. [39] Ezzeldin Shereen, Florian Bitard, György Dán, Tolga Sel, and Steffen Fries. Next steps in security for time synchronization: Experiences from implementing ieee 1588 v2. 1. In 2019 IEEE International Symposium on Precision Clock Synchronization for Measurement, Control, and Communication (ISPCS), pages 1–6. IEEE, 2019. [40] IEC/IEEE International Standard. Precision clock synchronization protocol for networked measurement and control systems. Technical report, 2021. [41] Kashyap Thimmaraju, Altaf Shaik, Sunniva Flück,

Pere Joan Fullana Mora, Christian Werling, and JeanPierre Seifert. Security testing the o-ran near-real time ric & a1 interface. In Proceedings of the 17th ACM Conference on Security and Privacy in Wireless and Mobile Networks, pages 277–287, 2024. [42] Jiarong Xing, Sophia Yoo, Xenofon Foukas, Daehyeok Kim, and Michael K Reiter. On the criticality of integrity protection in 5g fronthaul networks. In 33rd USENIX Security Symposium (USENIX Security 24), pages 4463–4479, 2024.

Appendix 1. Protocol Details

Algorithm 1: PRTESLA-C Protocol Flow (Per-Round TESLA with Correction) Parameters: disclosure delay d (rounds); round interval Tint ; per-epoch chain length N ; preannounce margin R (rounds); verification deadline W (Section 4.3); optional slew bound Smax . Crypto: one-way function F ; MAC-key derivation F ′ ; per-round MAC ASCON(·). DU state: epoch id e, round counter i, current chain {Ki } with public anchor K0 ; next-epoch chain {Kj′ } and anchor K0′ when preannouncing. RU state: expected round id SeqExp; per-round buffer B[·] for (Sync, Follow Up, Delay Req, Delay Resp, MAC, RolloverMeta); ledger L[·]; last accepted disclosed key Klast and its index Ilast; cached next anchor NextCommit and switch round SwitchPoint (optional). 1: Bootstrap (minimally trusted). DU provisions each RU with (e, i0 , d, Tint , K0 ) and initializes i ← i0 . RU sets SeqExp ← i0 ,

Klast ← K0 , Ilast ← 0. 2: Per-round message exchange. For each round i, DU and RU execute standard PTP (Sync, Follow Up, Delay Req, Delay Resp).

RU buffers received Sync/Follow Up/Delay Req into B[i] using PTP identities to associate messages with the correct slave instance. 3: DU: compute tag and disclose key. Upon generating Delay Resp for round i, DU forms the authenticated bundle Mibundle and sets

SeqNumi ← i. Let RolloverMetai be empty unless preannouncement is active (Step 4). DU computes the per-round tag:   MACi ← ASCON F ′ (Ki ), Mibundle ∥ SeqNumi ∥ RolloverMetai . DU attaches (SeqNumi , MACi ) to Delay Resp, and discloses Ki−d (if i ≥ d) in the same message.

4: DU: epoch preannouncement (optional). If the remaining rounds in the current epoch are ≤ R and the next epoch is not yet

′ , . . . , K0′ } and sets NextCommit ← K0′ and SwitchPoint ← isw (a future announced, DU generates a fresh next chain {KN round index). For rounds during preannouncement, DU sets RolloverMetai ← (NextCommit, SwitchPoint); otherwise RolloverMetai ← ∅. 5: RU: admission checks and buffering (pre-apply). Upon receiving Delay Resp carrying (SeqNumi , MACi , Ki−d , RolloverMetai ), RU first enforces freshness by checking SeqNumi ≥ SeqExp and discarding stale responses (replay) before application. If accepted, RU stores the response and TLV fields into B[i] and updates SeqExp ← i + 1. If RolloverMetai ̸= ∅, RU caches (NextCommit, SwitchPoint). 6: RU: apply fast path (speculative). If B[i] contains a complete four-message round, RU immediately computes offset/delay and applies the servo update (optionally bounded by Smax ). RU records the minimal incremental state in ledger L[i] and sets a verification deadline deadline[i] ← now + W . 7: RU: key-chain validation and delayed verification. If i ≥ d, RU validates the disclosed key Ki−d against the current epoch anchor. Concretely, RU checks that Ki−d is consistent with the one-way chain and the last accepted disclosure (gap-tolerant), e.g., F ∆ (Ki−d ) = Klast for some expected ∆ derived from indices. On success, RU updates (Klast, Ilast) and verifies round (i − d) by recomputing   bundle MAC′i−d ← ASCON F ′ (Ki−d ), Mi−d ∥ SeqNumi−d ∥ RolloverMetai−d ,

and comparing it with the stored MACi−d . 8: RU: commit on success; correct on failure/timeout. Upon verifying round (i − d), RU resolves its speculative effects using the

per-round ledger L[i − d]: if verification succeeds, RU commits the round by marking it authenticated, discarding the buffered bundle B[i − d], and releasing the ledger entry L[i − d] (the already-applied update remains in effect). Otherwise (MAC mismatch, invalid disclosure, missing bundle components, or verification deadline W expired), RU rejects the round and performs a deterministic control-level correction without rolling back wall-clock time. Concretely, RU (i) cancels the offset/servo input applied for round (i − d) and reverts the corresponding controller-state increment recorded in L[i − d], and (ii) subtracts the recorded incremental update to the path-delay estimator to restore it to its pre-round value (without resetting filter history). RU then marks the round as rejected/unverifiable and frees B[i − d] and L[i − d]. 9: RU: epoch switch at SwitchPoint. If valid rollover metadata (NextCommit, SwitchPoint) has been cached, RU activates the new epoch when the local round index reaches SwitchPoint. Specifically, RU sets the current verification anchor for newly arriving rounds to NextCommit (the next-chain commitment K0′ ) and advances the epoch identifier, while continuing to verify any previously buffered rounds using the old epoch key chain. To support the delayed-authentication pipeline, RU retains the previous epoch verification state until all pending rounds whose authentication keys belong to the old chain (at most d rounds) have been verified or resolved. After these rounds are completed, the old epoch state can be safely discarded. If NextCommit is missing or fails validation, RU enters holdover and rejects new-epoch synchronization updates until a valid commitment is re-provisioned.