pith. sign in

arxiv: 1907.03136 · v1 · pith:J6ZOUQW5new · submitted 2019-07-06 · 💻 cs.NI · cs.CR

TrustSAS: A Trustworthy Spectrum Access System for the 3.5 GHz CBRS Band

Mohamed Grissa , Attila A. Yavuz , Bechir Hamdaoui This is my paper

Pith reviewed 2026-05-25 01:40 UTC · model grok-4.3

classification 💻 cs.NI cs.CR
keywords spectrum access systemprivacy preservationblockchaincryptographyCBRSsecondary usersdynamic spectrum accessFCC regulations
0
0 comments X

The pith

TrustSAS uses cryptography and blockchain to protect secondary users' location and identity data in the CBRS spectrum system while meeting all FCC rules.

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

The paper presents TrustSAS as a framework that lets secondary users query spectrum availability in the 3.5 GHz band without exposing sensitive operational details to the central SAS. It does this by combining established cryptographic methods with blockchain records so that regulatory requirements for accuracy, auditability, and dynamic access remain intact. A reader would care because current SAS designs force users to reveal their positions and usage patterns, creating privacy exposure in an otherwise shared spectrum environment. The work shows through analysis and tests that the added protections incur only moderate extra computation and communication cost.

Core claim

TrustSAS is a trustworthy framework for the spectrum access system that synergizes state-of-the-art cryptographic techniques with blockchain technology to address privacy issues for secondary users while fully complying with FCC regulatory design requirements for the CBRS band.

What carries the argument

The TrustSAS framework that integrates cryptographic privacy mechanisms with blockchain to handle spectrum queries and operations without revealing secondary user data.

If this is right

  • Secondary users can obtain spectrum availability information without disclosing their location, identity, or usage patterns.
  • The system remains fully compliant with all FCC-mandated SAS functions including dynamic access and incumbent protection.
  • Security against privacy attacks holds while communication and computation overhead stay within practical limits for deployment.
  • Blockchain provides an auditable yet private record of spectrum transactions that regulators can verify.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same privacy-preserving query pattern could apply to other regulated shared-spectrum bands that require central coordination.
  • If the overhead measurements hold in larger networks, operators might adopt similar designs to reduce legal and user-acceptance barriers to spectrum sharing.
  • Regulators could treat the blockchain ledger as an independent verification layer for SAS compliance audits.

Load-bearing premise

Cryptographic methods and blockchain records can be combined to satisfy every FCC requirement for SAS functionality and accuracy without breaking the ability to deliver timely spectrum availability answers.

What would settle it

A test showing that TrustSAS either violates at least one explicit FCC SAS design rule or produces spectrum availability responses that are unusable for secondary users under realistic query loads.

Figures

Figures reproduced from arXiv: 1907.03136 by Attila A. Yavuz, Bechir Hamdaoui, Mohamed Grissa.

Figure 1
Figure 1. Figure 1: TrustSAS Architecture and Initial Operations [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Overhead of PIR and GoSig become quite expensive for both signers and verifiers if such a list becomes large. One possible way to maintain a good performance of TrustSAS is to impose a threshold on the list size. In this case, when the list size exceeds the threshold, FCC can create a new group and perform a rekeying operation, with each SU needing to prove to FCC that it is a legitimate member and that it… view at source ↗
read the original abstract

As part of its ongoing efforts to meet the increased spectrum demand, the Federal Communications Commission (FCC) has recently opened up 150 MHz in the 3.5 GHz band for shared wireless broadband use. Access and operations in this band, aka Citizens Broadband Radio Service (CBRS), will be managed by a dynamic spectrum access system (SAS) to enable seamless spectrum sharing between secondary users (SUs) and incumbent users. Despite its benefits, SAS's design requirements, as set by FCC, present privacy risks to SUs, merely because SUs are required to share sensitive operational information (e.g., location, identity, spectrum usage) with SAS to be able to learn about spectrum availability in their vicinity. In this paper, we propose TrustSAS , a trustworthy framework for SAS that synergizes state-of-the-art cryptographic techniques with blockchain technology in an innovative way to address these privacy issues while complying with FCC's regulatory design requirements. We analyze the security of our framework and evaluate its performance through analysis, simulation and experimentation. We show that TrustSAS can offer high security guarantees with reasonable overhead, making it an ideal solution for addressing SUs' privacy issues in an operational SAS environment.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 1 minor

Summary. The paper proposes TrustSAS, a framework that synergizes cryptographic techniques with blockchain technology to mitigate privacy risks to secondary users (location, identity, spectrum usage) in the FCC-mandated SAS for the 3.5 GHz CBRS band. It claims to satisfy all regulatory design requirements for incumbent protection, information exchange, and dynamic spectrum access while providing high security guarantees with reasonable overhead, supported by security analysis and performance evaluation via analysis, simulation, and experimentation.

Significance. If the hybrid construction demonstrably meets every FCC timing and authority constraint without compromising query functionality, the work would address a genuine tension between regulatory transparency mandates and SU privacy in operational spectrum sharing systems. The approach of layering privacy-preserving crypto atop blockchain for trust is novel in this domain, but its value hinges on concrete evidence that blockchain latency properties are compatible with SAS's centralized, low-latency model.

major comments (2)
  1. [Abstract and performance evaluation sections] Abstract and performance evaluation sections: the central claim that TrustSAS satisfies all FCC regulatory requirements (mandatory information exchange, incumbent protection, real-time availability queries) with only 'reasonable overhead' is unsupported. No timing measurements, latency bounds, or comparison against FCC response-time mandates are provided to address the risk that blockchain consensus and ledger operations introduce unacceptable delay or eventual consistency incompatible with SAS query functionality.
  2. [Security analysis section] Security analysis section: the assertion of 'high security guarantees' rests on the unverified premise that the crypto+blockchain design fully preserves SAS functionality and authority constraints. No concrete mapping or proof is given showing how blockchain components satisfy the specific FCC rules cited in the paper without altering the centralized query model.
minor comments (1)
  1. [Abstract] The abstract references 'analysis, simulation and experimentation' but does not specify the simulation parameters, experimental setup, or metrics used; adding these details would improve clarity even if the core evaluation is expanded.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive and detailed feedback. We address the two major comments point by point below, clarifying the existing evaluation and analysis while indicating where revisions will strengthen the manuscript.

read point-by-point responses

  1. Referee: [Abstract and performance evaluation sections] Abstract and performance evaluation sections: the central claim that TrustSAS satisfies all FCC regulatory requirements (mandatory information exchange, incumbent protection, real-time availability queries) with only 'reasonable overhead' is unsupported. No timing measurements, latency bounds, or comparison against FCC response-time mandates are provided to address the risk that blockchain consensus and ledger operations introduce unacceptable delay or eventual consistency incompatible with SAS query functionality.

    Authors: We agree that the performance evaluation would be strengthened by explicit latency measurements and direct comparisons to FCC response-time mandates. Our analysis, simulations, and experiments already quantify computational and communication overheads, which we characterize as reasonable relative to the operations performed. However, the submitted version does not include a dedicated mapping of measured latencies against specific FCC timing constraints for queries. We will revise the performance evaluation section to add available timing results from our experiments and provide explicit comparisons to the relevant FCC requirements. revision: yes

  2. Referee: [Security analysis section] Security analysis section: the assertion of 'high security guarantees' rests on the unverified premise that the crypto+blockchain design fully preserves SAS functionality and authority constraints. No concrete mapping or proof is given showing how blockchain components satisfy the specific FCC rules cited in the paper without altering the centralized query model.

    Authors: The security analysis examines how the cryptographic primitives and blockchain elements achieve the stated privacy goals while supporting the required information exchanges and incumbent protection. We acknowledge that an explicit component-by-component mapping to the cited FCC rules would make clearer that the centralized SAS authority model remains intact. We will revise the security analysis section to include a table or subsection that directly maps each design element to the relevant FCC requirements, confirming preservation of the query model. revision: yes

Circularity Check

0 steps flagged

No circularity: claims rest on novel construction and external evaluation

full rationale

The paper proposes TrustSAS as a new framework combining cryptographic primitives with blockchain to mitigate privacy risks in SAS while satisfying FCC regulatory constraints. No equations, fitted parameters, or derivations are present that could reduce by construction to their own inputs. Security and performance claims are supported by analysis, simulation, and experimentation rather than self-referential definitions or load-bearing self-citations. The derivation chain is therefore self-contained.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

Abstract-only review yields no explicit free parameters, axioms, or invented entities; the proposal relies on standard cryptographic primitives and blockchain properties assumed to be available from prior literature.

pith-pipeline@v0.9.0 · 5750 in / 971 out tokens · 17647 ms · 2026-05-25T01:40:44.665115+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

44 extracted references · 44 canonical work pages

  1. [1]

    Even though the true identities of all SU s, including leaders, are hidden in TrustSAS, this is not sufficient to preserve their operational privacy

    Querying Spectrum Availability Information: Each clus- ter leader acts on behalf of its SU members and privately queries DB s for spectrum availability information. Even though the true identities of all SU s, including leaders, are hidden in TrustSAS, this is not sufficient to preserve their operational privacy. In fact, since each record in DB s is asso-...

    work page

  2. [2]

    Notifying about Spectrum Usage: Once a spectrum assignment agreement is reached, the cluster leader will no tify the DB s about the spectrum portions used by its cluster members, as well as about other information, such as aggrega te transmit power on each used channel, duration of channel use , etc., as required by FCC. TrustSAS uses this information to ...

    work page

  3. [3]

    1, steps 2-10): TrustSAS en- sures that SU s activities are anonymous, yet verifiable, by leveraging Intel’s anonymous digital signature, known as e n- hanced privacy ID (EPID) [14]

    Bootstrapping Phase (Alg. 1, steps 2-10): TrustSAS en- sures that SU s activities are anonymous, yet verifiable, by leveraging Intel’s anonymous digital signature, known as e n- hanced privacy ID (EPID) [14]. EPID allows any SU to prove its membership legitimacy to other TrustSAS entities, without revealing its true identity, using zero-knowledge proof [1 ...

    work page

  4. [4]

    1, steps 11-16): Every joining SU uses the list A to discover and join the on- going p2p network

    Joining and Clustering Phase (Alg. 1, steps 11-16): Every joining SU uses the list A to discover and join the on- going p2p network. The joining SU then needs to authenticate with its peers and verify their legitimacy via T WOWAYEPID (Alg. 1, step 1). After enough SU s have joined TrustSAS, these SU s will form clusters based on their locations; this may ...

    work page

  5. [5]

    1, steps 17-30): Each cluster leader will anonymously authenticate with DB s using EPID

    Peering with DB s Phase (Alg. 1, steps 17-30): Each cluster leader will anonymously authenticate with DB s using EPID. Once a leader is authenticated by the DB s, these DB s join the established p2p network. During this phase, a global blockchain BC is also created to keep track of the key system-wise events. Only DB s and cluster leaders can participate ...

    work page

  6. [6]

    Authentication and permission: In TrustSAS, in order for a leader to query DB s, its cluster is required to have a minimum of τ SU s, where τ is a system parameter that could be tuned depending on the desired robustness and security levels within each cluster. Therefore, before querying the DBs, a cluster leader, SU (i) L , needs to show that its cluster ...

    work page

  7. [7]

    It guarantees information-theor etic pri- vacy, i.e

    Spectrum querying: To enable private querying of DB s, TrustSAS adopts multi-server private information retrieval (PIR) protocol [21], termed B ATCH PIR, which leverages the multiple DBs, inherently available by SAS design, to enable the cluster leaders to efficiently retrieve data records fro m DBs while preventing DBs from learning anything about the rec...

    work page

  8. [8]

    honestly

    Threat Model: TrustSAS assumes that DB s are honest- but-curious, in that they act “honestly” and follow the protocol in terms of handling queries and sharing spectrum availabil ity information, but they are also “curious” about SU s’ infor- mation and try to infer it from the messages they receive from SU s. TrustSAS also assumes that these DBs do not co...

    work page

  9. [9]

    Security Objectives: Given the above threat model, TrustSAS aims to achieve the following security objectives: • P ri i i iiv v v vva a a aat t t tte e e ee S S S SSp p p ppe e e eec c c cct t t ttru u u uum m m mm Av v v vva a a aai i i iil l l lla a a aab b b bbi i i iil l l lli i i iit t t tty y y yy Q Q Q QQu u u uue e e eery y y yyi i i iin n n nng g...

    work page

  10. [10]

    Corollary 1

    Security Results: All proofs of the security results stated in this section are omitted here due to space limitation, and can be provided if and when requested. Corollary 1. TrustSAS achieves unforgeability and robust- ness of TBLS signatures against an adversary that can corrupt any fi < n (i)/ 2 SU s within a cluster C(i) as long as the Gap-Diffie-Hellma...

    work page

  11. [11]

    Distributed Key Generation ( DKG ): Running DKG re- quires performing a number of elliptic curve point multipli - cations that is proportional to the number of SU s within the cluster. Using the benchmarking results that we derived wit h the MIRACL library [23], we provide in Table I an estimate of the average processing time experienced by each SU when r...

    work page

  12. [12]

    SU s repeatedly sign the consensus statement at each BFT round within the cluster

    Threshold Signature ( TBLS ): Table I provides the an- alytical and empirical cost of the different TBLS operation s executed by SU s in C(i). SU s repeatedly sign the consensus statement at each BFT round within the cluster. From an SU ’s perspective, this is relatively fast, as it involves sign ing a single message whose cost is dominated by a modular e...

    work page

  13. [13]

    Enhanced Privacy ID ( EPID ): We evaluate EPID .SIGN and EPID .VERIFY analytically and empirically (using In- tel’s publicly available SDK [27]) as depicted in Table II. EPID .SIGN and EPID .VERIFY both require a number of modular exponentiations that is linear in the size of the rev o- cations sublists; these revocation sublists are defined in [ 14]. Even...

    work page 2000

  14. [14]

    As the obtained results in Figs

    Private Information Retrieval ( PIR): We use our Geni testbed to evaluate TrustSAS’s multi-server PIR, BatchPIR. As the obtained results in Figs. 2a and 2b show, the support of query batching by BatchPIR, which allows multiple blocks to be retrieved simultaneously, reduces the overhead at bot h DBs’ and cluster leaders’ sides. We summarize the obtained re...

    work page

  15. [15]

    BFT Consensus: Table V shows that the communication overhead of BFT expressed in terms of number of messages sent every consensus round is quasi-linear in the size of the cluster, ni, which translates into a total communication overhead of O(n2 i log ni). In this experiment, we also set the throughput between the nodes to 10 M bps and the propagation dela...

    work page

  16. [16]

    Observe tha t the REKEYING has the highest cost, which is invoked mainly when a membership change occurs

    End-to-end Delay: We provide in Table IV the end- to-end delays caused by TrustSAS’s different algorithms, ignoring Byzantine faultiness for simplicity. Observe tha t the REKEYING has the highest cost, which is invoked mainly when a membership change occurs. One way to address this is by setting R EKEYING frequency small, and have joining SU s wait a litt...

    work page

  17. [17]

    Report and order and second further notice of propo sed rulemak- ing, number 15-47, gn docket no. 12-354. FCC,

    FCC, “Report and order and second further notice of propo sed rulemak- ing, number 15-47, gn docket no. 12-354. FCC,” April 2015

    work page 2015

  18. [18]

    Order on reconsideration and second report and orde r, number 16-55, gn docket no. 12-354. FCC,

    ——, “Order on reconsideration and second report and orde r, number 16-55, gn docket no. 12-354. FCC,” May 2016

    work page 2016

  19. [19]

    Overview of lte spectrum sharing technologies,

    Y . Y e, D. Wu, Z. Shu, and Y . Qian, “Overview of lte spectrum sharing technologies,” IEEE Access , vol. 4, pp. 8105–8115, 2016

    work page 2016

  20. [20]

    Protoco l to access white-space (paws) databases,

    V . Chen, S. Das, L. Zhu, J. Malyar, and P . McCann, “Protoco l to access white-space (paws) databases,” Tech. Rep., 2015

    work page 2015

  21. [21]

    Trading utility for privacy i n shared spec- trum access systems,

    M. A. Clark and K. Psounis, “Trading utility for privacy i n shared spec- trum access systems,” IEEE/ACM Transactions on Networking (TON) , vol. 26, no. 1, pp. 259–273, 2018

    work page 2018

  22. [22]

    Marshall, Three-tier Shared Spectrum, Shared Infrastructure, and a Path to 5G

    P . Marshall, Three-tier Shared Spectrum, Shared Infrastructure, and a Path to 5G . Cambridge University Press, 2017

    work page 2017

  23. [23]

    Cbrs communications security technical sp ecification, winnf-15-s-0065,

    W. I. Forum, “Cbrs communications security technical sp ecification, winnf-15-s-0065,” April 2017

    work page 2017

  24. [24]

    Cbrs threat model technical report, winnf-15-p-00 89,

    ——, “Cbrs threat model technical report, winnf-15-p-00 89,” May 2016

    work page 2016

  25. [25]

    Location priva cy in cognitive radio networks: A survey,

    M. Grissa, B. Hamdaoui, and A. A. Y avuza, “Location priva cy in cognitive radio networks: A survey,” IEEE Communications Surveys & Tutorials, vol. 19, no. 3, pp. 1726–1760, 2017

    work page 2017

  26. [26]

    Airmap: Scalabl e spectrum occupancy recovery using local low-rank matrix approximat ion,

    B. Khalfi, B. Hamdaoui, and M. Guizani, “Airmap: Scalabl e spectrum occupancy recovery using local low-rank matrix approximat ion,” in Global Communications Conference (GLOBECOM), 2018 IEEE

    work page 2018

  27. [27]

    Unleashing the power of multi-server pir for enabling private access to spectrum da tabases,

    M. Grissa, B. Hamdaoui, and A. A. Y avuz, “Unleashing the power of multi-server pir for enabling private access to spectrum da tabases,” IEEE Communications Magazine, vol. 56, pp. 171–177, December 2018

    work page 2018

  28. [28]

    Pr ivate informa- tion retrieval,

    B. Chor, O. Goldreich, E. Kushilevitz, and M. Sudan, “Pr ivate informa- tion retrieval,” in F oundations of Computer Science, 1995. Proceedings., 36th Annual Symposium on . IEEE, 1995, pp. 41–50

    work page 1995

  29. [29]

    Rethinking permissioned blockchains,

    M. Vukoli´ c, “Rethinking permissioned blockchains,” in Proceedings of ACM W orkshop on Blockchain, Cryptocurrencies and Contract s, 2017

    work page 2017

  30. [30]

    Enhanced privacy id: A direct ano nymous attesta- tion scheme with enhanced revocation capabilities,

    E. Brickell and J. Li, “Enhanced privacy id: A direct ano nymous attesta- tion scheme with enhanced revocation capabilities,” IEEE Transactions on Dependable and Secure Computing , vol. 9, no. 3, pp. 345–360, 2012

    work page 2012

  31. [31]

    Non-interactive zero-know ledge proof of knowledge and chosen ciphertext attack,

    C. Rackoff and D. R. Simon, “Non-interactive zero-know ledge proof of knowledge and chosen ciphertext attack,” in Annual International Cryptology Conference. Springer, 1991, pp. 433–444

    work page 1991

  32. [32]

    Threshold signatures, multisignature s and blind signa- tures based on the gap-diffie-hellman-group signature sche me,

    A. Boldyreva, “Threshold signatures, multisignature s and blind signa- tures based on the gap-diffie-hellman-group signature sche me,” in Int’l W orkshop on Public Key Cryptography . Springer, 2003, pp. 31–46

    work page 2003

  33. [33]

    Secu re distributed key generation for discrete-log based cryptosystems,

    R. Gennaro, S. Jarecki, H. Krawczyk, and T. Rabin, “Secu re distributed key generation for discrete-log based cryptosystems,” in Int’l Conf. on the Theory and App. of Crypto Tech. Springer, 1999, pp. 295–310

    work page 1999

  34. [34]

    How to share a secret,

    A. Shamir, “How to share a secret,” Communications of the ACM , vol. 22, no. 11, pp. 612–613, 1979

    work page 1979

  35. [35]

    Escrow pro- tocols for cryptocurrencies: How to buy physical goods usin g bitcoin,

    S. Goldfeder, J. Bonneau, R. Gennaro, and A. Narayanan, “Escrow pro- tocols for cryptocurrencies: How to buy physical goods usin g bitcoin,” in Int’l Conf. on Financial Crypto and Data Security . Springer, 2017

    work page 2017

  36. [36]

    Cogmes h: A cluster-based cognitive radio network,

    T. Chen, H. Zhang, G. M. Maggio, and I. Chlamtac, “Cogmes h: A cluster-based cognitive radio network,” in 2007 2nd IEEE International Symposium on New Frontiers in Dynamic Spectrum Access Netwo rks

    work page 2007

  37. [37]

    Sublinear scaling for multi- client private information retrieval,

    W. Lueks and I. Goldberg, “Sublinear scaling for multi- client private information retrieval,” in International Conference on Financial Cryp- tography and Data Security . Springer, 2015, pp. 168–186

    work page 2015

  38. [38]

    Practical byzantine fault tolerance,

    M. Castro, B. Liskov et al. , “Practical byzantine fault tolerance,” in OSDI, vol. 99, 1999, pp. 173–186

    work page 1999

  39. [39]

    C++ library (mi racl),

    M. Integer and C. Rational Arithmetic, “C++ library (mi racl),” https://github.com/miracl/MIRACL , 2013, accessed: 2018 -06-02

    work page 2013

  40. [40]

    Global environment for network innovations,

    “Global environment for network innovations,” https: //www.geni.net/

    work page

  41. [41]

    Percy++ library,

    “Percy++ library,” http://percy.sourceforge.net , a ccessed: 2018-06-14

    work page 2018

  42. [42]

    Threshold bls dfinity implementation,

    “Threshold bls dfinity implementation,” https://github.com/dfinity/random-beacon, accessed: 20 18-06-02

    work page

  43. [43]

    The intel(r) enhanced privacy id software developmen t kit,

    “The intel(r) enhanced privacy id software developmen t kit,” https://github.com/Intel-EPID-SDK, accessed: 2018-06- 02

    work page 2018

  44. [44]

    https://www.keylength.com/, accessed: 2018-06-02

    work page 2018