arXiv CSopen access

TESLA-for-5G: Broadcast Authentication for 5G Networks Using TESLA

TESLA-for-5G: Broadcast Authentication for 5G Networks Using TESLA Subin Song1 , Michael K. Reiter2 , and Taekyoung (Ted) Kwon1

arXiv:2606.26528v1 [cs.CR] 25 Jun 2026

1

Seoul National University, Seoul, South Korea {sbsong66,tkkwon}@snu.ac.kr 2 Duke University, Durham, NC, USA [email protected]

Abstract. 5G base stations broadcast unauthenticated system information (SI) that every user equipment (UE) reads during cell selection. This enables attackers to broadcast forged SI from a fake base station (FBS), deceiving UEs into camping on it. Prior approaches require UEs to authenticate System Information Block 1 (SIB1) using digital signatures. This necessitates computation-heavy verification for every SIB1 reception, imposing a significant burden on resource-constrained UEs. We propose TESLA-for-5G (TF5), a broadcast authentication protocol for 5G SIB1 that combines TESLA with GG09 Schnorr-like identity-based signatures (IBS). In the steady state, TF5 enables UEs to authenticate each SIB1 message using a symmetric MAC and delayed key disclosure, eliminating the need for per-message digital signatures. Initial trust is bootstrapped during cell entry using a lightweight GG09 IBS over the TESLA parameters, avoiding certificate distribution overhead. We formally verify TF5 in Tamarin under a Dolev–Yao adversary and demonstrate its favorable computation, communication, and storage costs through both an implementation on the OpenAirInterface 5G stack and trace-driven analysis. Keywords: network security · 5G mobile networks · broadcast authentication · TESLA · identity-based signatures

1

Introduction

In 5G networks, base stations (gNBs) periodically broadcast unauthenticated system information, including the Master Information Block (MIB) and System Information Block Type 1 (SIB1). Every user equipment (UE) must acquire these blocks before camping on a cell. By transmitting forged system information at a higher power, a fake base station (FBS) can deceive nearby UEs into camping on it. This enables attacks such as IMSI/SUCI catching, location tracking, protocol downgrades, and denial of service [29,44,14]. 3GPP has explored countermeasures in TR 33.809 [2], and prior research has proposed several other solutions [29,41,19]. However, these solutions require digital-signature verification for every SIB1 reception, imposing a significant computational burden on resource-constrained UEs.

2

S. Song et al.

To address this challenge, we present TESLA-for-5G (TF5), an efficient broadcast authentication scheme for 5G SIB1 messages. Our key observation is that most SIB1 acquisitions occur during RRC_IDLE returns to the same cell (see §6.4), allowing the UE to cache authentication state. TF5 adopts TESLA [38] to authenticate recurring SIB1 broadcasts using symmetric MACs, and bootstraps initial trust via a lightweight GG09 identity-based signature [24]. This approach requires signature verification only once per cell, eliminating certificate distribution and validation overhead. Our contributions are as follows: – We design TF5, an authentication protocol that combines TESLA with GG09 IBS for 5G SIB1 broadcasts. We formally verify its security properties using the Tamarin prover [33] under a Dolev–Yao adversary model. – We comprehensively evaluate TF5 against eight baseline schemes, demonstrating its efficiency in computation, communication, and storage. Furthermore, we implement TF5 within the OpenAirInterface 5G stack [35], achieving an end-to-end camp completion latency of ≈109 ms for returning UEs. – We conduct a trace-driven analysis using real-world UE mobility and RRC state transition traces collected from two distinct environments. Our results show that TF5, with environment-adaptive optimizations, achieves a 55– 65% reduction in daily UE verification costs compared to a signature-only baseline.

2

Background

2.1

5G Broadcast and Fake Base Station Attacks

A 5G network consists of User Equipment (UE), Next-Generation RAN (NGRAN) base stations (gNBs), and the 5G Core (5GC) [7]. Each gNB periodically broadcasts Master Information Block (MIB) and System Information Block Type 1 (SIB1) messages containing the essential parameters UEs require for network access [4]. Crucially, these broadcasts lack authentication: UEs cannot verify whether a received MIB or SIB1 originates from a legitimate gNB [29]. Consequently, an adversary can deploy a rogue gNB that broadcasts forged system information at a higher power, tricking nearby UEs into camping on a fake cell. While 5G provides mutual authentication via 5G-AKA, this activates only after cell selection, leaving the initial bootstrapping phase vulnerable [25,39]. Although 3GPP has explored countermeasures such as identity-based signatures in TR 33.809 [2], no broadcast authentication mechanism has been standardized to date [2,41]. 2.2

TESLA Broadcast Authentication Protocol

TESLA (Timed Efficient Stream Loss-tolerant Authentication) [38] is a broadcast authentication protocol that achieves per-message authentication through

TESLA-for-5G: Broadcast Authentication for 5G Networks Using TESLA

3

delayed key disclosure, only using symmetric primitives (MACs and one-way hash functions). We summarize the protocol based on RFC 4082 [38]. The sender generates a one-way key chain by repeatedly applying a one-way function F to a random seed KN : F

F

F

F

KN − → KN −1 − → ··· − → K1 − → K0 The protocol consumes these keys in reverse order (K1 , K2 , . . .). Due to the oneway nature of F , knowing Ki reveals all earlier keys while keeping subsequent keys secure. Thus, K0 acts as a cryptographic commitment to the entire chain. During initialization, receivers must obtain K0 , the interval duration Tint , key disclosure delay d, and start time T0 via an authenticated channel (e.g., a digital signature). Furthermore, TESLA requires loose time synchronization: each receiver must know an upper bound Dt on how far the sender’s clock is ahead of its own. Time is divided into intervals of duration Tint . During interval i, the sender computes MACs using a derived key Ki′ = F ′ (Ki ) and discloses Ki−d . Upon receiving a packet P = M ∥ i ∥ MAC(Ki′ , M ) ∥ Ki−d , the receiver performs a safe packet test to ensure Ki has not yet been disclosed (Appendix A), buffering safe packets and discarding unsafe ones. When Ki arrives (typically in interval i + d), the receiver verifies F i (Ki ) = K0 (where F i denotes the i-fold application of F ). If this chain check succeeds, the receiver validates the buffered MAC. 2.3

Identity-Based Signature

Shamir [40] introduced identity-based cryptography, in which a user’s public key is derived directly from an arbitrary identity string, eliminating the need for public-key certificates. In an identity-based signature (IBS) scheme, a trusted authority called the Private Key Generator (PKG) holds a master secret key (msk ) and issues identity-specific signing keys to users. A verifier can reconstruct the signer’s public key from its identity, so IBS eliminates the need to distribute and validate certificates—a property particularly attractive for broadcast authentication under tight message-size constraints. 3GPP TR 33.809 [2] includes IBS as a candidate authentication scheme for 5G broadcast messages. The standard security notion is existential unforgeability under adaptive chosenmessage and chosen-identity attack (EUF-IBS-CMA) [9,24].3 An adversary may adaptively query an extraction oracle for signing keys of chosen identities and a signing oracle for arbitrary identity–message pairs, and wins by forging a valid signature on a fresh identity–message pair for which it neither extracted the key nor obtained a signature. Many existing IBS constructions are pairing-based [28,8], incurring expensive bilinear-map evaluations; pairing-free alternatives avoid this cost. We adopt the GG09 scheme [24], which operates on standard elliptic curves under the discretelogarithm assumption, to be detailed below. 3

The exact name varies; we follow the terminology of [24].

4

S. Song et al.

GG09 IBS Scheme Galindo and Garcia [24] construct a pairing-free IBS from two concatenated Schnorr signatures. Let G be a cyclic group of prime order q with generator P , H1 , H2 : {0, 1}∗ → Zq be hash functions modeled as random oracles, and id be the signer’s identity. GG09 IBS consists of four algorithms: – Setup(): PKG chooses z ← − Zq and outputs MPK = zP , msk = z. – Extract(msk , id ): PKG chooses r ← − Zq , computes R = rP and y = r + z · H1 (R, id ) mod q, and outputs sk id = (y, R). – Sign(sk id , m): The signer chooses a ← − Zq , computes A = aP and s = a + y · H2 (id , A, m) mod q, and outputs σ = (A, s, R). – Verify(MPK , id , m, σ): The verifier parses σ = (A, s, R), computes c = H1 (R, id ) and e = H2 (id , A, m), and accepts iff sP = A + e(R + c · MPK ). Correctness follows from sP = (a + ye)P = A + e · yP = A + e(r + zc)P = A+e(R+c·MPK ). The original EUF-IBS-CMA security proof under the discretelogarithm assumption in the random-oracle model [24] was found to contain flaws in both reductions [13]; Chatterjee et al. provided a corrected proof that reestablishes security under the same assumption with a non-tight reduction [13]. The scheme itself remains unbroken, though a tight reduction remains open.

3

Threat Model and Security Goals

Adversary model. We consider a Dolev–Yao-style adversary consistent with the TESLA threat model [38] and prior FBS authentication work [29,41]. The adversary controls a localized wireless channel—eavesdropping, injecting, modifying, dropping, or delaying any over-the-air packet—and can deploy rogue gNBs that broadcast arbitrary system information at arbitrary signal strength. An individual gNB’s signing key may also be compromised, since a cell-site equipment is more exposed than the core-network infrastructure. The adversary is computationally bounded and cannot break standard cryptographic assumptions. We exclude core network compromise, relay attacks (see §7), side-channel attacks, and physical-layer attacks such as jamming or waveform manipulation. Assumptions. The core network’s PKG correctly issues identity-based signing keys only to authorized gNBs, bound to their cell IDs and validity periods. Each UE is pre-provisioned with the core’s master public key (MPK ) via a trusted channel (e.g., SIM provisioning). Wall-clock time at the UE and gNB must be synchronized to within a few seconds of real time (e.g., via GNSS or NTP) for signature replay detection. Legitimate gNBs are assumed not to manipulate their synchronization signal block (SSB) transmission timing to deceive UEs. Security goals. The primary goal of TESLA-for-5G is to enable UEs to reject SIB1 messages not originating from a legitimate gNB, thereby preventing camping on fake base stations. Specifically, TESLA-for-5G provides the following properties to a gNB whose signing key is not compromised: – Source authentication — the SIB1 originates from a legitimate gNB.

TESLA-for-5G: Broadcast Authentication for 5G Networks Using TESLA

5

– Message integrity — any tampering with SIB1 content is detected. – Replay protection — replayed SIB1 (from previous TESLA intervals) and stale SIB-TF5 bootstrap messages are rejected. For compromised gNBs, none of these properties hold, but compromise of one gNB does not affect the security of other gNBs. TESLA-for-5G does not provide non-repudiation or pre-authentication DoS protection; DoS preceding SIB1 authentication remains possible. Since UEs only receive broadcasts and transmit nothing in this phase, DoS is the only possible attack surface.

4

TESLA-for-5G Design

TF5 integrates TESLA [38] with the GG09 [24] IBS scheme. In this design, IBS is used to bootstrap TESLA root commitment and parameters, while TESLA authenticates each SIB1 broadcast through symmetric-key MACs. By deriving the gNB’s public key from its Cell ID and key validity period, IBS eliminates the need of certificates. The TF5 protocol involves three primary entities: the PKG, gNB, and UE. The PKG, a trusted core-network entity, holds the master-key pair (MPK , msk ) and issues IBS signing keys to authorized gNBs. At startup, each gNB generates a TESLA keychain and periodically broadcasts its parameters in a dedicated SIB-TF5 signed with its IBS signing key. Subsequent SIB1 broadcasts include a TESLA MAC tag and disclosed key material; the latter is used to derive the MAC key for the broadcast prior to the key disclosure delay d. Upon entering a cell, a UE verifies the IBS signature in the SIB-TF5 to obtain a trusted TESLA key commitment, hence authenticating each SIB1 via its TESLA MAC; any verification failure triggers cell rejection. While TF5 authenticates SIB1, it does not authenticate the MIB since the PBCH carrying the MIB has a fixed 32-bit payload [3] that cannot accommodate an authentication tag. An unauthenticated MIB only exposes the UE to minor denial-of-service risks. In contrast, more critical attacks—such as IMSI/SUCI catching [14], location tracking, downgrade, and power draining [34]—require the UE to camp on the cell. This approach aligns with prior work: Hussain et al. [29] authenticate only SIB1/SIB2; Singla et al. [41] authenticate only SIB1; and Dong et al. [19] defer MIB authentication to SIB1. b i−d represent In the following, let N denote the TESLA chain length and K an unverified disclosed key candidate, where i is the current TESLA interval index and d is the key disclosure delay. We define the iterated hash function as F n (x) = F (F n−1 (x)) with F 0 (x) = x, and let (MPK , msk ) be the PKG’s master key pair. Wsig denotes a UE-local signature freshness window, and the TESLA parameter set is denoted by ΠTESLA = (T0 , Tint , d, N, K0 ). Symbols for per-message fields are summarized in Table 1. 4.1

Protocol Description

TF5 operates in two phases. In the bootstrap phase, the UE verifies a GG09 IBS signature on a dedicated SIB-TF5 message to obtain a trusted TESLA key

6

S. Song et al.

Table 1: TF5 wire format. Size, Auth, and Sym. denote each field’s size, authentication coverage (by TESLA MAC for the SIB1 extension, by GG09 signature for SIB-TF5), and symbolic variable, respectively. (a) SIB1 extension.

(b) SIB-TF5 bootstrap message.

Field Size Auth*Sym. next ** sp flag 1B ✓ sp next Interval index 4B × i b i−d Disclosed key 16B × K Next-chain comm. 16B ✓ K0next TESLA MAC tag 16B — τ Total 53B

Field Size Auth Sym. Cell ID 5B ✓ cid boot Starting time (SFN, slot) 4B ✓ T0 Interval duration (ms) 2B ✓ Tint Key disclosure delay 1B ✓ d Chain length 4B ✓ N Chain commitment 16B ✓ K0 Signing key validity end 3B ✓ texp * The original SIB1 content is also GG09 signature 96B — σ covered by the TESLA MAC. Signing timestamp 3B ✓ tsign ** To be explained in §4.3. Total 134B

commitment and parameters. In the subsequent TESLA phase, each SIB1 is authenticated by a MAC whose key is disclosed in a later interval. A dedicated SIB-TF5 avoids the bandwidth cost of transmitting a full signature in every SIB1. Table 1 shows the wire formats for TF5 messages. Algorithm 1 summarizes the UE-side authentication procedures. We describe only TF5-specific elements here; the underlying TESLA operation is covered in §2.2. Accept(M ) delivers the verified message to the upper layer. Each gNB’s IBS identity is ID = cid boot ∥ texp , binding the Cell ID with the signing key’s expiration time; a short validity period (see §7) obviates UE-side revocation checking. TF5.Bootstrap verifies the key validity and freshness (lines 2–3) before accepting the message and initializing the TESLA trust anchor. TF5.VerifySIB1 caches the last verified key as trust anchor Kanchor to avoid full chain traversal, and stores the next-chain commitment K0next for seamless transitions (§4.3). SafePacketTest is detailed in Appendix A. 4.2

TESLA Timing and Parameters

TESLA requires each receiver to know an upper bound Dt on the sender’s clock advance relative to its own (see §2.2). TF5 uses the Synchronization Signal Block (SSB) transmitted by the gNB as its time-synchronization source. RFC 4082 requires authenticated time synchronization [38], yet the SSB is unauthenticated. TF5 addresses this by relying on the assumption that a legitimate gNB does not forge SSB timing (see §3): once the UE verifies the IBS signature on SIB-TF5— which does not depend on SSB timing—it can trust the previously received SSB timing. We set Dt = 1 ms, a conservative bound derived from the OFDM cyclic prefix timing constraint (Appendix A). The TESLA interval is set to Tint = 160 ms, matching the SIB1 broadcast periodicity. Start of each interval is aligned with the SIB1 transmission schedule;

TESLA-for-5G: Broadcast Authentication for 5G Networks Using TESLA

Algorithm 1 TF5 UE-side authentication procedures. TF5.Bootstrap(Pboot , tboot rx , MPK , Wsig ) Input: Pboot : received SIB-TF5 packet; tboot : reception time; MPK ; Wsig rx Output: ⊤ if bootstrap succeeds, ⊥ otherwise State: ΠTESLA , cid boot , Kanchor , ianchor , buf , K0next , sp next 1:

c boot , Π b TESLA , σ, tsign , texp ) ← Parse(Pboot ) (cid

2:

if tboot > texp then return ⊥ rx

3:

if tboot − tsign > Wsig then return ⊥ rx

4:

c boot ∥ texp ID ← cid

// key expired // replay protection

// construct IBS identity

5:

c boot ∥ Π b TESLA ∥ tsign ∥ texp Mboot ← cid

6:

if GG09.Verify(MPK , ID, Mboot , σ) = ⊥ then return ⊥

7:

b TESLA ) K0 ← ParseK0 (Π

8:

c boot ; Kanchor ← K0 ; ianchor ← 0 b TESLA ; cid boot ← cid ΠTESLA ← Π

9:

buf ← ∅; K0next ← ⊥; sp next ← 0

10 :

return ⊤

// signature invalid

TF5.VerifySIB1(PSIB1 , tSIB1 , Dt ) rx Input: PSIB1 : received SIB1 packet; tSIB1 : reception time; Dt rx Output: ⊤ if packet buffered, ⊥ otherwise 1: 2: 3: 4: 5: 6: 7:

State: ΠTESLA , cid boot , Kanchor , ianchor , buf , K0next , sp next cSIB1 , i, K b i−d , K b 0next , sp (M b next , τ ) ← Parse(PSIB1 ) c SIB1 ← ParseCellID(M cSIB1 ) // Parse Cell ID from original SIB content cid c if cid SIB1 ̸= cid boot then return ⊥ // Cell ID mismatch if SafePacketTest(tSIB1 , i, ΠTESLA , Dt ) = ⊥ then return ⊥ rx cSIB1 , i, K b 0next , sp e ← (M b next , τ ); buf ← buf ∪ {e}

// cf. App. A

if i − d ≤ ianchor then return ⊤ // disclosed key already seen; buffered only b i−d ) ̸= Kanchor then if F (i−d)−ianchor (K

9:

buf ← buf \ {e}; return ⊥ // key verification fail; discard e b i−d ; ianchor ← i − d // advance trust anchor Kanchor ← K

10 :

j next while ∃ ej = (MSIB1 , j, K0,j , sp next , τj ) ∈ buf with j ≤ ianchor do j

8:

// remove eligible entry

11 :

buf ← buf \ {ej }

12 :

Kj ← F

ianchor −j

13 :

j next if MAC(Kj′ , MSIB1 ∥ K0,j ∥ sp next ) = τj then j

14 : 15 : 16 :

(Kanchor ); Kj′ ← F ′ (Kj )

// recover Kj ; tolerates skips

j next Accept(MSIB1 ); K0next ← K0,j ; sp next ← sp next j

else discard ej return ⊤

// MAC verification failed

// accept buffered packet

7

8

S. Song et al.

thus, SIB1 arrives well before the next interval begins.4 We set the key disclosure delay d = 1 to minimize verification latency.5 4.3

Chain Renewal

TESLA uses a finite key chain of length N ; once exhausted, the gNB must switch to a new chain with a fresh root key. Without any renewal mechanism, each chain transition would make UEs receive a new SIB-TF5 and perform expensive IBS signature verification. TF5 addresses this by embedding a next-chain commitment K0next in every SIB1 extension (see Table 1). Because this field is covered by the current chain’s TESLA MAC, verifying a SIB1 message also validates the successor chain’s root key. A 1-bit sp next flag is included in a dedicated header byte. When sp next = 0 (common case), the next chain inherits all current parameters and starts immediately after the last interval, so the UE continues authenticating broadcasts seamlessly by setting K0 ← K0next without IBS verification. When sp next = 1 (rare), one or more parameters become different and the UE must re-bootstrap via a fresh SIB-TF5. If the UE has been in idle or disconnected mode for a long time and couldn’t obtain K0next , it may choose to set a local timer to wake up several intervals before chain exhaustion—ensuring it can receive and verify at least one SIB1. The cost of this wakeup is evaluated in Section 6.4.

5

Security Analysis

We formally verify TF5’s the security goals (§3) using the Tamarin Prover [33] under a Dolev–Yao adversary capable of compromising individual gNB signing keys. Our model builds upon the TESLA proof of Cremers et al. [16], extending it with GG09 IBS and chain renewal. The complete Tamarin model is available at [42]. Our TF5 Tamarin model employs the following abstractions. Since Tamarin cannot model real-time, we follow the established practice of prior work [32,16] and substitute wall-clock time with symbolic trace ordering. The signing key validity period, signature freshness, and safe-packet checks all adopt this approach. Cryptographic primitives (e.g., GG09 IBS and hash functions) are idealized and treated as black boxes, while chain renewal is modeled exclusively for the sameparameter path (sp_next=0). Table 2 maps the security goals (§3) and key auxiliary properties to their corresponding Tamarin lemmas. We additionally verify seven exists-trace lemmas (not listed in the table) to confirm that it admits the intended protocol SIB1 scheduling occasions are tied to SSB transmissions and the UE assumes TSSB = 20 ms during initial cell selection [5]; thus, SIB1 is repeated 8 times within each 160 ms interval. 5 RFC 4082 notes that d = 1 “does not work” for packets near interval boundaries [38]; this does not apply to TF5 because SIB1 has a fixed schedule and is aligned with the TESLA interval. 4

TESLA-for-5G: Broadcast Authentication for 5G Networks Using TESLA

9

Table 2: TF5’s security goals and auxiliary properties mapped to Tamarin lemmas. All lemmas are verified under a Dolev–Yao adversary who can compromise individual gNB signing keys; listed properties hold for any gNB whose signing key is not compromised. Security Goal Tamarin Lemma(s) SIB-TF5 source authen- bootstrap_authentic — verified SIB-TF5 was sent by a tication & integrity legitimate gNB with matching content SIB1 source authentica- authentic — verified SIB1 was sent by a legitimate gNB tion & integrity with matching content Bootstrap replay pro- bootstrap_freshness — bootstrap with a signature older tection than the freshness window Wsig is rejected SIB1 replay protection sib1_freshness — SIB1 received after its TESLA interval has elapsed is rejected Key secrecy knows_only_expired_chain_keys — adversary learns chain keys only after disclosure gNB key validity confor- stale_gnb_signing_key_rejected — gNB keys past their mance validity period are rejected Chain renewal authen- renewal_commitment_authenticity — renewed chain ticity commitment is authentic to the gNB

runs in each phase, such as bootstrapping, TESLA, and chain renewal. We also prove further auxiliary properties, including bootstrap parameter agreement and cross-cell compromise isolation; see [42] for details.

6

Evaluation

6.1

Computational Overhead

Evaluation setup. We compare TF5 against eight baselines, including certificatebased schemes (CertECDSA , CertEdDSA ), pairing-free IBS (GG09 [24], SchnorrHIBS [41], E2IBS [19]), and pairing-based schemes (Hes03 [28], BLMQ [8], and CertBLS 6 ). These baselines are selected considering 3GPP TR 33.809 [2], which proposes certificate-based and IBS schemes (e.g., ECCSI [26], SM9 [30], and BLS7 [12]) as 5G SI authentication candidates. We evaluate each scheme across three roles: Core (gNB key extraction/certificate issuance), gNB (signing), and UE (verification). Schnorr-HIBS [41] employs a 3-level hierarchy (PKG, AMF, gNB) for GG09 IBS in 5G; we adopt its 2-level variant (PKG, gNB) as the GG09 baseline. All Schnorr-based schemes (TF5, CertEdDSA , GG09, Schnorr-HIBS, E2IBS) are implemented on the Edwards25519 curve8 using libsodium [18]. Pairing-based We develop a scheme that uses BLS [12] for both certificate and SIB-TF5 signing and name it CertBLS . 7 BLS is not an IBS scheme but seems to have been misclassified; [19] also discuss this 8 Schnorr-HIBS and E2IBS originally use FourQ [15]; we reimplement both on Edwards25519 for fair comparison. 6

10

S. Song et al.

Table 3: Computational overhead (µs): Core/gNB-side operations (desktop) and UE-side verification (measured and predicted platforms). Sign-off = gNB signing offline (precomputation); Sign-on = gNB signing online. Standard deviations are <6% of the mean for measured operations ≥1 µs (12% for RPi MAC verification) and below 0.14 µs for <1 µs operations. Bold indicates the three lowest values in each column, with ties at the third rank all bolded. Core

gNB

UE Verification

†

TF5 bootstrap TF5 MAC‡ CertECDSA CertEdDSA CertBLS Hes03 BLMQ GG09 Schnorr-HIBS E2IBS

Extract Sign-off Sign-on Desktop RPi 4B Phone V2X IoT 10.81 10.35 0.33 41.95 453.93 278 1,212 17,873△ — 0.17 0.67 0.80 4.02 0.53 10.3 158△ 14.27 16.45 0.49 87.77 611.48 340 1,637 24,077△ 11.06 10.36 0.50 59.69 641.68 393 1,714 25,266△ 103.11 — 103.11 805.81 9,374.10 5,265∗29,877∗369,097△ 93.44 368.57 57.93 526.12 6,117.40 3,436∗19,498∗240,867△ 58.10 368.71 57.42 662.32 7,708.22 4,330∗24,568∗303,505△ 10.73 10.42 0.50 41.91 451.56 276 1,206 17,780△ 21.64 10.36 0.50 74.26 802.30 491 2,143 31,590△ 11.99 10.39 0.61 37.96 407.92 250 1,089 16,062△

Key extraction for IBS schemes; certificate generation for Cert schemes. Smartphone, V2X, IoT values without markers use eBACS [10] scaling (high confidence). ∗ Uses CoreMark /MHz [22] scaling (medium confidence). △ Uses CoreMark /MHz [22] scaling (low confidence; cross-ISA). †

schemes (Hes03, BLMQ, CertBLS ) use BLS12-381 via blst [43], while CertECDSA uses NIST P-256 through OpenSSL 3.0+ [37]. OpenSSL is also used for SHA-256 and HMAC. Benchmarks are compiled with -O2 -march=native and pinned to a single CPU core. We apply standard optimizations, including offline/online signing decomposition and precomputed MPK tables. Each operation is measured over 1,000 iterations after 10 warmup runs, reporting the average wall-clock time in microseconds. Our evaluation code will be released upon publication. We benchmark all entity roles on a desktop (Intel Core i5-14600KF, 5.3 GHz, 32 GB RAM) and use a Raspberry Pi (RPi) 4B (Cortex-A72 @ 1.8 GHz, 8 GB RAM) for UE-side evaluation to mirror power-constrained ARM processors. To estimate the performance across diverse UE classes, we scale the RPi 4B measurements to three additional platforms using public benchmarks from eBACS [10] and CoreMark [22]: Smartphone (Cortex-A76 @ 2.42 GHz), V2X (Cortex-A53 @ 1.0 GHz), and IoT (Cortex-M33 @ 64 MHz). The IoT platform uses a different ISA (32-bit ARMv8-M vs. 64-bit ARMv8-A) and likely underestimate actual latency; further details are in Appendix B. Results. Table 3 summarizes the benchmark results. Since TF5 and GG09 share the same signing algorithm and differ only in their payloads, their performance is nearly identical across all roles and platforms. Overall, pairing-based schemes

TESLA-for-5G: Broadcast Authentication for 5G Networks Using TESLA

11

Table 4: Air-interface communication overhead (bytes). per-cell = cacheable within the same cell; per-msg = varies per SIB1 broadcast. Cert schemes report raw-field encoding; X.509 sizes are discussed in the text. Scheme per-cell per-msg Total TF5 134 53 187 CertECDSA 100 67 167 CertEdDSA 99 67 166 CertBLS 147 51 198 Hes03, BLMQ 3 83 86 GG09, E2IBS 35 67 102 Schnorr-HIBS 77 67 144

are 1–2 orders of magnitude slower than non-pairing schemes. All non-pairing schemes achieve sub-microsecond online signing at the gNB via a single scalar multiplication, with TF5’s MAC calculation reaching a comparable 0.67 µs. For UE verification, E2IBS is the fastest, followed closely by GG09 and TF5’s bootstrap verification. While CertEdDSA verification outperforms CertECDSA on the desktop, the opposite result occurs on the RPi because OpenSSL’s optimized x86_64 assembly for P-256 is unavailable. The MAC verification cost is 0.80 µs on the desktop (52× faster than GG09), 4.02 µs on the RPi (112×), and 0.53 µs on the smartphone (521×). We measure the hash chain traversal cost for dC = 1 to 50,000 hops to the last verified trust anchor (9 data points; dC is the hop count) and fit OLS regressions. Both desktop and RPi 4B show near-perfect linearity (R2 ≈ 1) with slopes of 0.14 µs and 0.61 µs per hop (∆dC ), respectively; predicted slopes for smartphone, V2X, and IoT are 0.08, 1.58, and 24.2 µs/∆dC . Hashing in smartphones is performed notably fast due to ARMv8 Crypto Extensions, which are prevalent in modern mobile SoCs [31]. 6.2

Communication and Storage Overhead

Table 4 summarizes the air-interface overhead for each scheme, analytically derived from protocol specifications and cryptographic primitive sizes. Timestamp and key-validity fields are normalized to 3 B; gNB identities are excluded from IBS schemes as they are already present in standard SIB1. Since per-cell data (e.g., certificates or IBS parameters) can be cached at the UE, per-message overhead—data included in every SIB1 broadcast (e.g., signatures)—is the critical metric. TF5’s per-message overhead (53 B) is lower than all baselines except CertBLS (51 B), which is impractical due to its high verification cost (§6.1). Hes03 and BLMQ achieve the lowest total overhead (86 B) but the highest per-message cost (83 B). The 372 B maximum capacity of SIB1 [6] introduces a constraint: a typical SIB1 message occupies ∼100 B,9 leaving ∼272 B for authentication data. TF5’s 53 B extension fits within this budget, as do all 9

Measured from a plain OpenAirInterface (OAI) [35] implementation.

12

S. Song et al.

Table 5: Storage overhead per scheme. (b) TF5 runtime state (bytes).

(a) Key sizes (bytes). Scheme

MPK msk P Kgnb skgnb

TF5, Schnorr-HIBS, GG09, CertEdDSA

CertECDSA CertBLS Hes03, BLMQ E2IBS

32 32 33 96 96 32,768

32 32 32 32

32

32

33 96 — 32

32 32 48 32

Entity Item

gNB UE

Size TESLA params (ΠTESLA ) 11 TESLA key chain 16 · N TESLA params (ΠTESLA ) 11 cid boot (36 b), sp next (1 b) 5 Trust anchor key (Kanchor ) 16 Trust anchor idx. (ianchor ) 4 Pending SIB1 buffer (buf ) 392 Next-chain comm. (K0next ) 16

Table 6: End-to-end latency (SIB1 decoded → camp) on the OAI prototype (50 runs). Scenario Mean Stddev Median First-time UE 289.0 ms 54.7 ms 290.1 ms SIB1 decoded → IBS verified 117.9 ms 54.2 ms — IBS verified → camp 171.1 ms 4.4 ms — Returning UE 108.8 ms 59.3 ms 159.6 ms

raw-encoded baselines. However, DER-encoded X.509 certificates increase percell overhead to 317 B for ECDSA and 252 B for EdDSA,10 exceeding the SIB1 capacity and requiring a separate SIB. Table 5a summarizes the key sizes for each entity. Notably, E2IBS is an outlier, requiring a ∼32 KB MPK to be pre-provisioned on the SIM, which consumes a significant fraction of a commodity UICC’s 128–512 KB flash [1]. In contrast, TF5’s 32 B MPK is highly compatible with these constraints. Table 5b details the additional runtime state for TF5. The gNB’s TESLA key chain (16 × N B) is the dominant factor, requiring ≈32 KB when N = 2,000, while the UE state (corresponding to the state variables in Algorithm 1) totals 444 B. 6.3

Implementation and End-to-End Latency

We prototype TF5 on the OpenAirInterface (OAI) [35] 5G stack. GG09 IBS is implemented using Ed25519 via libsodium [18], while SHA-256 hash and HMAC operations utilize OpenSSL 3.0+ [37]. We measure wall-clock latency from SIB1 decoding to camp completion across 50 runs on a desktop platform. The system is deployed via Docker using OAI’s vrtsim [36] at a 1.0 timescale. We evaluate two scenarios: a first-time UE (TF5.Bootstrap + VerifySIB1) and a returning UE (TF5.VerifySIB1). The SIB-TF5 broadcast period is 160 ms. 10

Measured using OpenSSL 3.0+ [37]

TESLA-for-5G: Broadcast Authentication for 5G Networks Using TESLA

13

Table 6 reports the results. For a first-time UE, camp completion takes 289.0 ms, comprising TF5.Bootstrap (117.9 ms) and TF5.VerifySIB1 (171.1 ms). The latency for a returning UE is dominated by the wait for key disclosure while buffering SIB1; consequently, the total delay remains within one Tint (mean 108.8 ms). We discuss the acceptability of this latency in §7. The high standard deviations in both scenarios arise from asynchronous UE arrival. Because a firsttime UE may arrive at any point relative to the next SIB-TF5 broadcast, and a returning UE at any point within a TESLA disclosure interval, random wait times dominate the variance. 6.4

Trace-Driven Cost Analysis

Among SIB1 acquisition triggers [6], idle returns (RRC_CONNECTED → RRC_IDLE) and cell reselections are the most frequent. In both cases, the UE must reacquire SIB1 since it cannot reuse a cached copy [6]. While handovers deliver SI via the backhaul and thus require no broadcast read, we log them to track cell transitions. We develop an event-driven simulator that replays real-world traces to estimate the daily UE-side verification cost of TF5 relative to plain GG09 verification. Each trace was collected using a custom Android application that monitors modem-level RRC state transitions via the radio logcat buffer. By combining these transitions with TelephonyCallback-based service-state and cell-ID updates, the app records mobility and connectivity events that trigger SIB1 reacquisition. We analyzed two datasets: TD (Durham, NC, USA; car-dominated; ≈371 h; 590 reselections, 1,079 handovers, 1,763 idle returns) and TS (Seoul, South Korea; dense urban; ≈376.5 h; 2,008 reselections, 2,825 handovers, 6,481 idle returns). Overall, TS exhibits 3.3× more events than TD . The simulator evaluates verification costs based on event types. Under the GG09-only baseline, each SIB1 reception requires one signature verification (Csig ). For TF5, these costs vary by event: – Cell reselection: Csig +i·Chash +Cmac , where i is the current interval index within the chain. – Idle return: (i − ianchor ) · Chash + Cmac . – Chain transition: 0 if K0next is pre-acquired via chain renewal; otherwise, Csig . We apply the smartphone-predicted values from Section 6.1 to Csig , Chash , and Cmac for all cost calculations in this section. Chain length sensitivity Table 7a reports the average daily verification cost across varying N for the TF5 baseline (without chain renewal or state caching). While increasing N reduces re-bootstrapping frequency, it raises the per-event hash-chain traversal cost. N = 2,000 yields the highest cost reduction in both TD (34.0%) and TS (29.7%). Beyond N = 2,000, chain traversal dominates, making TF5 costlier. However, TS is more robust to large N than TD because its higher event density amortizes the traversal cost across more events.

14

S. Song et al.

Table 7: Trace-driven cost analysis results. GG09 baseline costs: TD = 42.1 ms/day, TS = 149.6 ms/day. Red. = cost reduction (%) of TF5 relative to GG09; negative values indicate TF5 is costlier. Bold marks the best reduction per column. (a) Chain length (N ) sensitivity. C.D. = chain duration in seconds (N × Tint ).

(b) Feature evaluation at N = 2,000.

TD TS TD TS # Features ms/day Red. ms/day Red. N C.D. ms/day Red. ms/day Red. A Baseline 27.7 34.0 105.2 29.7 24.2 42.4 88.4 40.9 500 80 30.8 26.9 116.2 22.3 B SC 23.1 45.0 77.9 48.0 1,000 160 28.1 33.1 106.9 28.6 C CR 50.9 −20.9 71.6 52.2 2,000 320 27.7 34.0 105.2 29.7 D CR+W 18.9 55.0 59.0 60.6 3,000 480 29.0 31.1 108.7 27.4 E CR+SC 45.8 −8.9 52.6 64.9 4,000 640 30.6 27.2 110.2 26.4 F CR+W+SC 10,000 1,600 42.1 −0.2 128.7 14.0

Feature evaluation Table 7b evaluates six configurations at N = 2,000 by progressively enabling TESLA state caching (SC), chain renewal (CR), and renewal wakeup (W). SC allows a UE re-entering a previously visited cell (e.g., a → b → a) to resume from its cached anchor Kanchor , effectively mitigating ping-pong reselections at cell edges. We detail chain renewal and wakeup in Section 4.3. Both SC and CR yield consistent, independent improvements: SC provides an 8–13 pp gain across all feature mixes (A→B, C→E, D→F), while CR adds 11–20 pp over the baseline and SC-only configurations (A→C, B→E). However, the wakeup mechanism (W) is highly environment-sensitive. Without W, a UE idling across multiple chain epochs pays only a single Csig upon return. With W, the UE must wake for each intermediate epoch, accumulating hash-traversal costs that can easily exceed a single Csig . Consequently, W causes a ≈65 pp regression in TD , but provides a marginal ≈4 pp benefit in TS due to its higher event density. The optimal configuration for TD is CR+SC (18.9 ms/day, 55.0% lower than GG09), while TS performs best with CR+W+SC (52.6 ms/day, 64.9% lower). Because renewal wakeup is a UE-local decision, devices can adaptively toggle it based on event density, maintaining near-optimal performance without gNB coordination.

7

Discussion

Acceptability of Verification Delay. TF5 adds two delay sources over plainsignature schemes: bootstrapping waits up to one SIB-TF5 period (160 ms in §6.3), and TESLA’s d = 1 disclosure defers SIB1 verification by Tint = 160 ms, giving a worst case of 0.32 s. This delay is largely invisible in practice because SIB1 acquisition is anticipatory, not on-demand: as shown in §6.4, the dominant triggers—idle returns and cell reselections—happen while the UE is in RRC_IDLE or RRC_INACTIVE, well before any subsequent data exchange. In RRC_CONNECTED,

TESLA-for-5G: Broadcast Authentication for 5G Networks Using TESLA

15

where latency matters most, the target cell’s system information arrives via the secure backhaul [6], bypassing broadcast SIB1; TF5 is not invoked there. Signing Key Validity Period. Each gNB’s signing key embeds a validity period in its identity (ID = cid ∥texp ). Short-lived keys obviate explicit revocation—a pattern from identity-based cryptography [11] adopted in prior 5G broadcast authentication work [41,19]. Key renewal cost is negligible: GG09.Extract takes ≈ 11 µs per key on a desktop core (Table 3), so a PKG serving 2×105 gNBs—the per-operator scale of every country except China11 —finishes all extractions in ≈ 2 s on a single core, and each renewal delivers only a 64-byte key per gNB (≈ 12 MB total). We therefore recommend a one-hour default, which effectively bounds the attack window of a compromised key while imposing negligible corenetwork overhead. Relay Attacks. TF5 does not defend against relay attacks, where an attackercontrolled UE forwards legitimate broadcasts from a genuine gNB to a victim UE through a rogue gNB [20]. The standard countermeasure for relay attacks in prior work is a time-bounded defense: the gNB embeds a signing timestamp and the UE rejects messages older than a window ∆t [29,19,20]. Dong et al. [20] evaluated this on an OAI testbed, separating legitimate (∼3 ms) from relayed (∼7 ms) messages at ∆t = 5 ms. However, these numbers come from a co-located lab setup and any real deployment would need to re-tune ∆t to its environment, such as cell radius and propagation.

8

Related Work

Digital Signature Approaches. Hussain et al. [29] identified the FBS bootstrapping problem and proposed certificate-based authentication, dismissing TESLA because bootstrapping still requires a signature and delayed key disclosure adds latency. Singla et al. [41] subsequently introduced Schnorr-HIBS, a hierarchical IBS system adopting GG09 [24]. Dong et al. [19] optimized this line with E2IBS (2× faster verification than Schnorr-HIBS). Dong et al. [20] evaluates a timebounded defense against relay attacks on signature-based solutions. 3GPP TR 33.809 [2] surveys both signature-based countermeasures (ECDSA/RSA certificates, ECCSI [26]/SM9 [30]/BLS [12], and delegated signing) and symmetric MAC approaches; it acknowledges TESLA but defers analysis, and no solution has yet been adopted [27]. Detection-Based Approaches. Orthogonal to cryptographic prevention, FBSDetector [34] classifies protocol traces with machine learning, PHOENIX [21] performs device-centric runtime verification, and Purification et al. [39] blacklist FBSes by monitoring NAS connection-setup duration and registration retransmissions. 11

Estimated by dividing each country’s total 5G base station count [23] by its number of major MNOs.

16

S. Song et al.

Algorithm 2 TESLA safe packet test. For notations, see Table 1. SafePacketTest(trx , i, ΠTESLA , Dt ) 1:

Output: ⊤ if safe, ⊥ if key may be disclosed t̄s ← trx + Dt

9

// upper bound on sender’s time on rx // upper bound on sender’s interval

2:

j̄ ← ⌊(t̄s − T0 ) / Tint ⌋

3:

if j̄ ≥ i + d then return ⊥

4:

return ⊤

// key Ki may be disclosed

Conclusion

We presented TESLA-for-5G, a broadcast authentication protocol for 5G SIB1 that combines GG09 IBS [24] with TESLA [38], replacing the costly per-SIB1 signature verification of prior schemes with cheap symmetric MAC checks. We verified its security with Tamarin; compared its computation, communication, and storage overhead against eight baseline schemes; and implemented it on OpenAirInterface, achieving ≈109 ms returning-UE verification. A trace-driven cost analysis on two real-world SIB1 reception traces further shows a 55–65% reduction in daily verification cost compared to a signature-only baseline. By demonstrating its cost-effectiveness on real-world event traces, TESLA-for-5G offers a viable candidate solution to the still-unresolved problem of secure 5G broadcast authentication.

A

TESLA Safe Packet Test and Dt Derivation

Algorithm 2 formalizes the safe packet test invoked by TF5.VerifySIB1 (Algorithm 1). Given an interval-i message arriving at trx , the receiver upper-bounds the sender’s current interval using Dt and discards the message if the sender may already have reached the disclosure interval for Ki . Accepting such a message would allow an adversary who learned the disclosed Ki to forge a valid MAC. TF5 sets Dt = 1 ms. We use the gNB’s Synchronization Signal Block (SSB) during UE’s cell search [5] as a time-synchronization source. OFDM demodulation requires that the receiver’s timing be aligned with the transmitter to within one cyclic prefix (CP); otherwise, the message cannot be decoded due to intersymbol interference. CP is longest at the 15 kHz subcarrier spacing, where it is approximately 4.7 µs; higher subcarrier spacings yield proportionally shorter CPs [17]. Any successfully decoded SIB1 therefore implies that the UE’s timing matches the gNB’s to within at most 4.7 µs. With a large safety margin, we conservatively set Dt = 1 ms.

TESLA-for-5G: Broadcast Authentication for 5G Networks Using TESLA

17

Table 8: Reference and target cores: CoreMark /MHz [22] and eBACS [10] cycle counts. SHA-256 on a 64-byte message; Ed25519 and ECDSA verify on a 59-byte message. Cortex-M33 is not in eBACS ; shown as —. Core CM/MHz SHA-256 Ed25519 vrfy ECDSA vrfy Cortex-A72 5.668 1,539 406,698 641,007 Cortex-A76 7.505 272 334,798 478,673 Cortex-A53 3.201 2,195 603,383 953,118 Cortex-M33 4.048 — — —

B

Benchmark Scaling Methodology

To predict UE verification overhead for the Smartphone, V2X, and IoT platforms in §6.1, we scale per-operation runtimes measured on the RPi 4B reference. Table 8 lists each core’s CoreMark /MHz score [22] and eBACS [10] cycle counts. Let Tref be a measured per-operation runtime; we estimate the target-platform runtime as fref Ttarget = Tref · R · , (1) ftarget where f is the clock frequency and the ratio R takes one of two forms. When both processors appear in eBACS , R = Ctarget /Cref , where C values are primitivespecific cycle counts reported by eBACS . Otherwise, R falls back to Sref /Starget , where S values are per-core CoreMark /MHz scores reported by CoreMark : this applies to BLS12-381 pairings—which are not measured in eBACS —and all IoT predictions due to the Cortex-M33’s absence from eBACS . Values predicted with eBACS carry high confidence; Smartphone and V2X pairing predictions carry medium confidence; all IoT predictions carry low confidence due to the cross-ISA discontinuity between ARMv8-A and ARMv8-M (see Table 3 for actual results).

References 1. SIM Card Market Size by Memory Capacity, https://www.abiresearch.com/ news-resources/chart-data/sim-card-market-outlook 2. 3GPP: Study on 5G security enhancements against false base stations (FBS). Technical Report (TR) 33.809 (Release 18), 3rd Generation Partnership Project (3GPP) (Sep 2023), http://www.3gpp.org/DynaReport/33809.htm 3. 3GPP: NR; Multiplexing and channel coding. Technical Specification (TS) 38.212 (Release 19), 3rd Generation Partnership Project (3GPP) (Dec 2025), http://www. 3gpp.org/DynaReport/38212.htm 4. 3GPP: NR; NR and NG-RAN overall description; stage-2. Technical Specification (TS) 38.300 (Release 19), 3rd Generation Partnership Project (3GPP) (Dec 2025), http://www.3gpp.org/DynaReport/38300.htm 5. 3GPP: NR; Physical layer procedures for control. Technical Specification (TS) 38.213 (Release 19), 3rd Generation Partnership Project (3GPP) (Dec 2025), http: //www.3gpp.org/DynaReport/38213.htm

18

S. Song et al.

6. 3GPP: NR; radio resource control (RRC); protocol specification. Technical Specification (TS) 38.331 (Release 19), 3rd Generation Partnership Project (3GPP) (Dec 2025), http://www.3gpp.org/DynaReport/38331.htm 7. 3GPP: System architecture for the 5G system (5GS). Technical Specification (TS) 23.501 (Release 20), 3rd Generation Partnership Project (3GPP) (Dec 2025), http: //www.3gpp.org/DynaReport/23501.htm 8. Barreto, P.S.L.M., Libert, B., McCullagh, N., Quisquater, J.J.: Efficient and provably-secure identity-based signatures and signcryption from bilinear maps. In: Proceedings of the 11th International Conference on Theory and Application of Cryptology and Information Security. pp. 515–532. ASIACRYPT’05, SpringerVerlag, Berlin, Heidelberg (Dec 2005). https://doi.org/10.1007/11593447_28 9. Bellare, M., Namprempre, C., Neven, G.: Security Proofs for Identity-Based Identification and Signature Schemes. In: Cachin, C., Camenisch, J.L. (eds.) Advances in Cryptology - EUROCRYPT 2004. pp. 268–286. Springer, Berlin, Heidelberg (2004). https://doi.org/10.1007/978-3-540-24676-3_17 10. Bernstein, D.J., Lange, T.: eBACS: ECRYPT Benchmarking of Cryptographic Systems, https://bench.cr.yp.to/ 11. Boneh, D., Franklin, M.: Identity-Based Encryption from the Weil Pairing. In: Kilian, J. (ed.) Advances in Cryptology — CRYPTO 2001. pp. 213–229. Springer, Berlin, Heidelberg (2001). https://doi.org/10.1007/3-540-44647-8_13 12. Boneh, D., Lynn, B., Shacham, H.: Short Signatures from the Weil Pairing. Journal of Cryptology 17(4), 297–319 (Sep 2004). https://doi.org/10.1007/ s00145-004-0314-9 13. Chatterjee, S., Kamath, C., Kumar, V.: Galindo-Garcia Identity-Based Signature Revisited. In: Kwon, T., Lee, M.K., Kwon, D. (eds.) Information Security and Cryptology – ICISC 2012. pp. 456–471. Springer, Berlin, Heidelberg (2013). https: //doi.org/10.1007/978-3-642-37682-5_32 14. Chlosta, M., Rupprecht, D., Pöpper, C., Holz, T.: 5G SUCI-catchers: Still catching them all? In: Proceedings of the 14th ACM Conference on Security and Privacy in Wireless and Mobile Networks. pp. 359–364. ACM, Abu Dhabi United Arab Emirates (Jun 2021). https://doi.org/10.1145/3448300.3467826 15. Costello, C., Longa, P.: FourQ: Four-dimensional decompositions on a Q-curve over the mersenne prime. In: Iwata, T., Cheon, J.H. (eds.) Advances in Cryptology – ASIACRYPT 2015. pp. 214–235. Springer Berlin Heidelberg, Berlin, Heidelberg (2015) 16. Cremers, C., Jacomme, C., Lukert, P.: Subterm-Based Proof Techniques for Improving the Automation and Scope of Security Protocol Analysis. In: 2023 IEEE 36th Computer Security Foundations Symposium (CSF). pp. 200–213 (Jul 2023). https://doi.org/10.1109/CSF57540.2023.00001 17. Dahlman, E., Parkvall, S., Sköld, J.: Chapter 7: Overall Transmission Structure. In: 5G NR: The next Generation Wireless Access Technology. Academic Press, London, United Kingdom ; San Diego, CA, United States, second edition edn. (2021) 18. Denis, F.: Libsodium (Mar 2026), https://github.com/jedisct1/libsodium 19. Dong, Y., Behnia, R., Yavuz, A.A., Hussain, S.R.: Securing 5G Bootstrapping: A Two-Layer IBS Authentication Protocol (Feb 2025). https://doi.org/10.48550/ arXiv.2502.04915 20. Dong, Y., Wan, T., Wu, T., Hussain, S.R.: Evaluating Time-Bounded Defense Against RRC Relay in 5G Broadcast Messages. In: 18th ACM Conference on Security and Privacy in Wireless and Mobile Networks. pp. 236–241. WiSec

TESLA-for-5G: Broadcast Authentication for 5G Networks Using TESLA

19

2025, Association for Computing Machinery, New York, NY, USA (Jun 2025). https://doi.org/10.1145/3734477.3734718 21. Echeverria, M., Ahmed, Z., Wang, B., Arif, M.F., Hussain, S.R., Chowdhury, O.: PHOENIX: Device-Centric Cellular Network Protocol Monitoring using Runtime Verification. In: Proceedings 2021 Network and Distributed System Security Symposium. Internet Society, Virtual (2021). https://doi.org/10.14722/ndss.2021. 24390 22. EEMBC: CoreMark®: An EEMBC Benchmark, https://www.eembc.org/ coremark/ 23. European Commission: 5G indicators: Infrastructure deployment | Shaping Europe’s digital future (Dec 2025), https://digital-strategy.ec.europa.eu/en/policies/ 5g-indicators-infrastructure-deployment 24. Galindo, D., Garcia, F.D.: A Schnorr-Like Lightweight Identity-Based Signature Scheme. In: Preneel, B. (ed.) Progress in Cryptology – AFRICACRYPT 2009. pp. 135–148. Springer, Berlin, Heidelberg (2009). https://doi.org/10.1007/ 978-3-642-02384-2_9 25. Gao, H., Zhang, Y., Wan, T., Zhang, J., Duan, H.: On Evaluating Delegated Digital Signing of Broadcasting Messages in 5G. In: 2021 IEEE Global Communications Conference (GLOBECOM). pp. 1–7 (Feb 2021). https://doi.org/10.1109/ GLOBECOM46510.2021.9685173 26. Groves, M.: Elliptic curve-based certificateless signatures for identity-based encryption (ECCSI). RFC 6507 (Feb 2012). https://doi.org/10.17487/RFC6507 27. Heijligenberg, T., Rupprecht, D., Kohls, K.: The attacks aren’t alright: Large-Scale Simulation of Fake Base Station Attacks and Detections. In: Proceedings of the 17th Cyber Security Experimentation and Test Workshop. pp. 54–64. CSET ’24, Association for Computing Machinery, New York, NY, USA (Aug 2024). https: //doi.org/10.1145/3675741.3675742 28. Hess, F.: Efficient Identity Based Signature Schemes Based on Pairings. In: Nyberg, K., Heys, H. (eds.) Selected Areas in Cryptography. pp. 310–324. Springer, Berlin, Heidelberg (2003). https://doi.org/10.1007/3-540-36492-7_20 29. Hussain, S.R., Echeverria, M., Singla, A., Chowdhury, O., Bertino, E.: Insecure connection bootstrapping in cellular networks: The root of all evil. In: Proceedings of the 12th Conference on Security and Privacy in Wireless and Mobile Networks. pp. 1–11. WiSec ’19, Association for Computing Machinery, New York, NY, USA (May 2019). https://doi.org/10.1145/3317549.3323402 30. ISO/IEC: IT Security techniques — Digital signatures with appendix — Part 3: Discrete logarithm based mechanisms. Tech. Rep. ISO/IEC 14888-3:2018, International Organization for Standardization (2018) 31. Kölbl, S.: Putting Wings on SPHINCS. In: Lange, T., Steinwandt, R. (eds.) PostQuantum Cryptography. pp. 205–226. Springer International Publishing, Cham (2018). https://doi.org/10.1007/978-3-319-79063-3_10 32. Meier, S.: Advancing Automated Security Protocol Verification. Ph.D. thesis, ETH Zurich (2013). https://doi.org/10.3929/ETHZ-A-009790675 33. Meier, S., Schmidt, B., Cremers, C., Basin, D.: The TAMARIN prover for the symbolic analysis of security protocols. In: Sharygina, N., Veith, H. (eds.) Computer Aided Verification. pp. 696–701. Springer Berlin Heidelberg, Berlin, Heidelberg (2013) 34. Mubasshir, K.S., Karim, I., Bertino, E.: Gotta detect’em all: Fake base station and multi-step attack detection in cellular networks. In: Proceedings of the 34th USENIX Security Symposium (2025)

20

S. Song et al.

35. OpenAirInterface: OpenAirInterface. OpenAirInterface (2026), https: //openairinterface.org/oai-code/ 36. OpenAirInterface: radio/vrtsim/vrtsim.c · oai / openairinterface5G · GitLab (Jan 2026), https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/develop/ radio/vrtsim/vrtsim.c 37. OpenSSL: Openssl/openssl. OpenSSL (Mar 2026), https://github.com/openssl/ openssl 38. Perrig, A., Canetti, R., Song, D., Tygar, D., Briscoe, B.: Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction. Request for Comments RFC 4082, Internet Engineering Task Force (Jun 2005). https://doi.org/10.17487/RFC4082 39. Purification, S., Wuthier, S., Kim, J., Kim, J., Chang, S.Y.: Fake Base Station Detection and Blacklisting. In: 2024 33rd International Conference on Computer Communications and Networks (ICCCN). pp. 1–9 (Jul 2024). https://doi.org/10. 1109/ICCCN61486.2024.10637542 40. Shamir, A.: Identity-Based Cryptosystems and Signature Schemes. In: Blakley, G.R., Chaum, D. (eds.) Advances in Cryptology. pp. 47–53. Springer, Berlin, Heidelberg (1985). https://doi.org/10.1007/3-540-39568-7_5 41. Singla, A., Behnia, R., Hussain, S.R., Yavuz, A., Bertino, E.: Look Before You Leap: Secure Connection Bootstrapping for 5G Networks to Defend Against Fake Base-Stations. In: Proceedings of the 2021 ACM Asia Conference on Computer and Communications Security. pp. 501–515. ASIA CCS ’21, Association for Computing Machinery, New York, NY, USA (Jun 2021). https://doi.org/10.1145/3433210. 3453082 42. Song, S.: Ssubinsong/tf5-tamarin-proof (Apr 2026), https://github.com/ ssubinsong/tf5-tamarin-proof 43. Supranational: Supranational/blst. Supranational (Mar 2026), https://github. com/supranational/blst 44. Tucker, T., Bennett, N., Kotuliak, M., Erni, S., Capkun, S., Butler, K., Traynor, P.: Detecting IMSI-Catchers by Characterizing Identity Exposing Messages in Cellular Traffic. In: Proceedings 2025 Network and Distributed System Security Symposium. Internet Society, San Diego, CA, USA (2025). https://doi.org/10.14722/ ndss.2025.241115