TrustSAS: A Trustworthy Spectrum Access System for the 3.5 GHz CBRS Band
Mohamed Grissa, Attila A. Yavuz, and Bechir Hamdaoui

TL;DR
TrustSAS is a novel framework combining cryptography and blockchain to enhance privacy and security in spectrum access systems for the 3.5 GHz CBRS band, ensuring regulatory compliance and operational efficiency.
Contribution
It introduces an innovative TrustSAS framework that addresses privacy concerns in spectrum sharing by integrating cryptographic techniques with blockchain technology.
Findings
TrustSAS provides high security guarantees.
The framework operates with reasonable performance overhead.
It effectively protects secondary users' privacy in spectrum sharing.
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âŚ
| Operation | Analytic Cost | Empirical Cost |
|---|---|---|
| DKGÂ Computation | ||
| DKGÂ Communication | messages | messages |
| SignShareGen | ||
| SignShareVerif | ||
| Signature size | bytes | bytes |
| Private key size | bytes | bytes |
| SignReconstruct | ||
| GroupSignVerif |
| Operation | Analytical Cost | Empirical Cost |
|---|---|---|
| Signature size | bytes | bytes |
| Private key size | bytes | bytes |
| Operation | Analytical Cost | Empirical Cost |
|---|---|---|
| Leader âs query | ||
| Â processing | ||
| Communication |
| Operation | Analytical Cost | Empirical Cost |
|---|---|---|
| Communication per user | messages | |
| Consensus w/o failures | ||
| Consensus w/ failures |
Peer Reviews
No public reviews on file for this paper yet. If you reviewed it on a platform where reviews are public (OpenReview, ICLR, NeurIPS, ICML), you can paste yours below so the community can read it here.
Videos
No videos yet. Explain this paper in a talk, walkthrough, or lecture? Add one.
TrustSAS: A Trustworthy Spectrum Access System for the 3.5 GHz CBRS Band
Mohamed Grissa*â, Attila A. YavuzâĄ, and Bechir Hamdaouiâ*
â Oregon State University, grissam,[email protected]
⥠University of South Florida, [email protected]
Abstract
As part of its ongoing efforts to meet the increased spectrum demand, the Federal Communications Commission (FCC) has recently opened up MHz in the 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 () to enable seamless spectrum sharing between secondary users (s) and incumbent users. Despite its benefits, âs design requirements, as set by FCC, present privacy risks to s, merely because s are required to share sensitive operational information (e.g., location, identity, spectrum usage) with  to be able to learn about spectrum availability in their vicinity. In this paper, we propose , a trustworthy framework for  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  can offer high security guarantees with reasonable overhead, making it an ideal solution for addressing sâ privacy issues in an operational  environment.
Index Terms:
Spectrum access system, Citizens Broadband Radio Service, spectrum databases, Blockchain, privacy.
I Introduction
The Federal Communications Commission (FCC) continues its effort towards promoting dynamic access to spectrum resources, and has recently promulgated the creation of the Citizens Broadband Radio Service (CBRS) in the 3.5 GHz band (3550 - 3700 MHz) [1]. This opens up previously protected spectrum, used by the US Navy and other DoD members, for dynamic and opportunistic spectrum sharing. In its CBRS report [1, 2], FCC prescribes the use of a centralized spectrum access system () to govern CBRS sharing among incumbent and secondary users. Like the case of TV white space (TVWS) access,  comprises multiple geolocation spectrum databases (s), operated (typically) by different administrators and are required to communicate amongst themselves to ensure frequency use information consistency. Also, like in TVWS, s need to query the s using their exact location information to be able to learn about CBRS spectrum opportunities in their vicinity.
 supports three types of users: primary users (s), priority access license (PAL) users, and general authorized access (GAA) users. s are top/first tier users with the highest priority, while new CBRS users, considered as secondary users, operate either at the second tier as PAL users or at the third tier as GAA users [3]. PAL users are assigned through competitive auction and have priority over GAA users, but they are required to vacate the spectrum upon the return of s. GAA users, on the other hand, operate opportunistically, in that they need to query the s to learn about which spectrum portions are availableânot being used by higher tier ( or PAL) users. Even though both PAL and GAA users are considered as secondary users, in the remaining parts of this paper, for ease of illustration,  refers to a GAA user, since only GAA users need to query s to learn spectrum availability; PAL users acquire spectrum access via bidding.
I-A Key Requirements
As stipulated by FCC [1], âs capabilities will exceed those of TVWS [4], allowing a more dynamic, responsive and generally capable support of a diverse set of operational scenarios and heterogeneous networks [5]. While some of FCCâs design requirements for , such as the ability to authenticate users, hold users accountable for rule and policy violation, and to protect against unauthorized database access and tampering, are similar to TVWS systems, other requirements are only specific to , which include [2]:
Information gathering and retention: s must keep  informed about their current operating parameters and channel usage information at all time, so that  can maintain accurate and up-to-date frequency usage information. While this is mandatory in , it is only optional in TVWS.
Coexistence:  is required to coordinate the interactions among PAL and GAA users to ensure interference-free coexistence among all CBRS users [2, 6]. This is different from TVWS systems, which focus primarily on protecting s, and not on ensuring coexistence among s.
Auditability:  must maintain audit logs of all system operations [7], including  write operations, user membership status changes, etc.  uses these logs to verify and ensure compliance with regulatory rules and policies.
It is then important that these requirements be met when designing . The challenge, however, is that meeting them gives rise to some serious privacy issues, thereby impacting the adoption of this promising technology.
I-B Privacy Issues in
A subtle privacy concern arises in , which pertains merely to the fact that s are required to share sensitive operational information with s in order for them to obtain spectrum availability information [2]. This information, which may include sâ sensitive data, such as their locations, identities, spectrum usage, and transmission parameters, may be collected by an adversary or a malicious  administrator and be exploited for economic, political, or other purposes [8]. For instance, fine-grained location information can easily reveal other personal information about s including their behavior, health condition, personal habits or beliefs [9].
It may not be acceptable for most users to expose such a sensitive information, especially in the presence of malicious entities that can exploit it for malicious purposes [9, 10, 11]. Such privacy risks may hinder the wide adoption of this promising spectrum sharing technology. Calls are starting to arise within the wireless community to raise awareness about this issue as it is the case with Federated Wireless in their comments to FCC regarding its report and order [2]. Therefore, it is necessary to design mechanisms that can protect sâ sensitive information while at the same time abiding by FCCâs rules and policies prescribed for .
I-C Contributions and Paper Organization
Most of â rules require s to share a great deal of their sensitive information, which conflict with sâ privacy objectives. As a result, we are facing a dilemma: On one hand, all  entities need to comply with âs requirements to have a stable, interference-free radio environment. On the other hand, it is important to offer privacy guarantees to s so as to promote this new spectrum sharing technology. This dilemma makes the task of designing  mechanisms that provide privacy guarantees while complying with âs requirements and rules very challenging.
We strongly envision that the publicâs (long-term) acceptance of the  paradigm will greatly depend on the robustness and trustworthiness of  vis-a-vis of its ability to address these privacy concerns. Therefore, in this work, we propose , a trustworthy  design framework that aims to achieve these two conflicting goals. More specifically,  combines and 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. To the best of our knowledge, this work is the first to address such issues within the context of  and CBRS.
We first provide in Section II a high-level overview of our framework to help grasp the big picture. Then, in Section III, we provide a detailed description of the framework. The security analysis and performance evaluation are provided in Sections IV and V, and the paper is concluded in Section VI.
II System and Framework Overview
In this section, we present the system architecture and provide a high-level overview of . Fig. 1 can be referred to throughout this section to facilitate the description.
II-A Architectural Components
As illustrated in Fig. 1,  comprises three main architectural entities: FCC, multiple s, and multiple s. Without loss of generality, throughout the paper, we use FCC to refer to FCC itself, or to any trusted third-party entity that is appointed by FCC to act on its behalf. In , FCC is responsible for enforcing compliance with regulatory requirements, providing system keying materials, handling the registration of s, and granting them permissions to join .  leverages and relies on the existence of multiple s for spectrum access, each typically run by a different administrator. These s are assumed to be synchronized and to be sharing the same content, as mandated by FCC. Also,  supports multiple s, including a set of pre-registered s to be deployed specifically for playing the role of anchor nodes. These anchor s serve to establish a backbone peer-to-peer (p2p) network that can be discoverable and joinable by new s.
The content of each  can be viewed/modelled as an matrix  of size  bits, where  is the number of records in the database, each of size  bits. Each record in  is a unique combination of a cell number, representing the location, a channel number, and other transmission parameters (e.g., max transmit power, duration, etc). In , each record in  contains a smart contract that is to be created by s to define channel usage rules, such as the maximum number of s allowed to transmit simultaneously in a given location, âs maximum transmit power, etc. With these smart contracts,  ensures fair sharing of the spectrum resources, and limits the interference among s, thus satisfying the coexistence requirement, stated in Section I-A. For simplicity, we assume that channel usage is permitted over a fixed duration independently from the channel, and that s need to query s for an updated channel availability information periodically every , where  is a tunable system design parameter. The geographical area serviced by  is modeled as a grid of cells of equal sizes, and an âs location is expressed through the gridâs cell index.
II-B *Â Initial Setup*
The first phase needed for setting up  is bootstrapping (see Fig. 1), during which FCC creates the system parameters and keys, specific to , and shares them with s. Also, s first need to register and request  access privileges from FCC before they can join . Once registered, FCC provides the joining  with the anchor  list, membership keys, and the procedure necessary for the  to authenticate with and join . Note that, in , all messages communicated between the s and the s are established over secure channels, so as to ensure that the spectrum queries are authenticated, private, and not tampered with. Secure channels will be established via traditional mechanisms, and such mechanisms are ignored in this framework to keep the focus on the other security aspects. This phase is detailed in Section III-A1.
The second setup phase consists of establishing the underlying network infrastructure. Registered s that join  will maintain communication with one another via an overlay p2p network, and a newly joining  will rely on anchor s to discover and join the p2p network. relies on an anonymous digital signature technique, explained in Section III-A, to enable all these s to anonymously authenticate and verify each otherâs legitimacy when peering with one another. This anonymous authentication will also enable s to enjoy system services anonymously, yet in a verifiable way, to break the link between their sensitive operational data and their true identities.
 adopts a clustering approach, where joined s group themselves into clusters and elect cluster leaders, with the leaders being responsible for representing their s for interacting with other system entities. Not only will this improve  scalability, but also protect sâ privacy, as it will limit the interaction with s to only cluster leaders. Once clusters are established, s within each cluster distributively and collaboratively generate their cluster-specific keys, which will be used later for blockchain related operations inside the cluster and for signing cluster-wise spectrum agreements. This phase is detailed in Section III-A2.
Once clusters are formed, the last setup phase is for the leaders to anonymously authenticate with s, and upon successful authentication, these s will join and be part of the established p2p network. This way, s will not be involved in the initial clustering of s, and therefore they will not be able to infer the sâ location information. This phase is detailed in Section III-A3.
II-C *Â Main Operations*
II-C1 Querying Spectrum Availability Information
Each cluster leader acts on behalf of its  members and privately queries s for spectrum availability information. Even though the true identities of all s, including leaders, are hidden in , this is not sufficient to preserve their operational privacy. In fact, since each record in s is associated with a unique location, s may infer the location of the leaders from their queries and can still use this information for tracking purposes. To prevent this,  protects the leadersâ queries through the adoption of multi-server private information retrieval () protocol [12], which enables a user to retrieve a record from multiple databases while preventing the databases from learning any information about the record or the user requesting it. After learning the spectrum availability information, members of each cluster will distributively reach an agreement on how the spectrum resources are to be shared among them. Detailed description of this operation is provided in Section III-C.
II-C2 Notifying about Spectrum Usage
Once a spectrum assignment agreement is reached, the cluster leader will notify the s about the spectrum portions used by its cluster members, as well as about other information, such as aggregate transmit power on each used channel, duration of channel use, etc., as required by FCC.  uses this information to build knowledge of the spectral environment and to maintain an accurate availability information to comply with the information gathering and retention requirement. As we discuss in more details in Section III,  ensures that cluster leaders report an accurate and non-altered spectrum usage information that is easily verifiable. Other leaders and s will distributively reach an agreement about the validity of this information, which, if valid, will be updated to sâ records. Detailed description of this is provided in Section III-D.
III The Proposed Framework:
 relies on permissioned blockchains [13] to keep track of system and cluster activities. Blockchains are also used as a platform to handle agreements between entities at both the cluster and system levels. This is achieved thanks to permissioned blockchainsâ underlying Byzantine fault tolerant (BFT) consensus mechanism [13], which enables participants to reach agreements on block updates even when Byzantine nodes are present. Throughout the description of , before an entity submits and adds a block to a blockchain, we assume that the block is first signed by the entity and then validated via BFT by the validators of the blockchain. We now describe the different algorithmic components of .
III-A System Setup
The first component of , depicted in Alg. 1, consists of setting up the system parameters and the required keys at initialization, which is done in three phases.
III-A1 Bootstrapping Phase (Alg. 1, steps 11-19)
 ensures that s activities are anonymous, yet verifiable, by leveraging Intelâs anonymous digital signature, known as enhanced privacy ID (EPID) [14]. EPID allows any  to prove its membership legitimacy to other  entities, without revealing its true identity, using zero-knowledge proof [15]. EPID also enables access revocation of misbehaving s anonymously, by maintaining and using a revocation list  based on sâ signatures. EPID typically runs four procedures. The first, , is run by the FCC as the first step of the Bootstrapping phase (step 2, Alg. 1) and outputs two system keys: Membership Verification Public Key () and Membership Issuing Secret Key (). The first key, , is shared among all entities of , and used by s and s to anonymously verify the membership legitimacy of another . The second key, , is kept secret and used only by FCC to create a unique Membership Private Key, , for each joining , a key that the  uses to prove its membership legitimacy to the other system members anonymously. We iterate again that FCC will be used throughout to refer to either FCC itself or any third-party entity that is appointed by FCC to govern on its behalf.
The second procedure, , is run interactively between each joining  and FCC, and takes as input  and FCCâs public key , as illustrated in steps 4 and 9 of Alg. 1. It results in  obtaining  and . The third procedure, , allows an  to anonymously prove its membership legitimacy and that it does not belong to the revocation list (i.e., its signature over a challenge message, , does not belong to ). Note that EPID signatures produced by the same  are linkable; this prevents any malicious  from forging multiple signatures on behalf of other s. To validate the EPID signature of joining , a verifier uses the fourth procedure, EPID.Verify, using the membership public key, , by checking that âs signature is not in .
 also requires that some s be appointed to serve as anchor nodes. These s need to run the TwoWayEPID subroutine (Alg. 1, step 2) among themselves to authenticate each other anonymously before they peer up and initiate the overlay p2p network. Later on, every joining , that obtained its through EPID.Join, will also get the list of anchor nodes, denoted by throughout, from FCC.
III-A2 Joining and Clustering Phase (Alg. 1, steps 21-26)
Every joining  uses the list to discover and join the ongoing p2p network. The joining  then needs to authenticate with its peers and verify their legitimacy via TwoWayEPID (Alg. 1, step 2). After enough s have joined , these s will form clusters based on their locations; this may require the s to expose their locations to other s, but it should be no issue at this point since s are not part of the p2p network yet. The members of each will also maintain a cluster (local) blockchain, , to log and keep track of key events taking place in the cluster.
 requires s of each cluster to serve as witnesses with respect to any cluster-related statement that is shared by the leader with the system. This is to prevent the leader from maliciously reporting incorrect information that was not validated by members of the cluster. To ensure this,  adopts the robust -threshold BLS (TBLS) signature scheme [16]. TBLS requires no more than (any) of the s in to collaboratively create a cluster signature over a statement. For this, members of each will have to run the Rekeying operation described in Alg 2, among the s of , to jointly generate the keys required for performing such distributed -TBLS signatures within . This is achieved by running TBLSâs distributed key generation (DKG) [17] operation which will result in each in obtaining three keys: Cluster Public Key, , which is shared among all s in , Cluster User Secret Key, , and Cluster User Public Key, . The Cluster User Secret Keys are a -threshold secret sharing of the private key . These shares are constructed using Shamir secret sharing [18] such that any subset of s from can recover using Lagrange interpolation. Cluster User Public Keys represent sâ pseudonyms within and are also used to identify sâ transactions in the local blockchain, . In addition to DKG, TBLS comprises four other operations:
- â˘
SignShareGen: It enables each  to compute the signature share over a message to be signed by .
- â˘
SignShareVerif: It enables members of to verify  âs signature share against its public key .
- â˘
SignReconstruct: The leader of a cluster collects a set of signature shares of a message , , verified using SignShareVerif, from s. It combines these shares using Lagrange interpolation, via the Lagrange coefficients that were calculated in DKG, and reconstructs the complete cluster signature.
- â˘
GroupSignVerif: Used to verify the cluster-generated signature against âs public key .
Note that TBLS does not require reconstructing during the signing process. Even after repeated signing, no  could learn any information about that would enable it to create signatures without other s [19]. We refer the reader to [16] for more details about TBLS.
To handle system-wise access revocations,  requires that each âs Cluster User Public Key is associated with its EPID signature over some statement that is known by all cluster members. To achieve this, each  signs its Cluster User Public Key itself, which is known to all s in the cluster, using EPID.Sign with its EPID Membership Private Key, (Alg 2, step 4). This serves to create a cryptographic binding between âs EPID signature and its Cluster User Public Key. This binding will then have to be submitted as a transaction to be included in . This is done by making  sign the binding from the previous step using TBLS.SignShareGen with its Cluster User Secret Key, (Alg 2, step 5). Then each  will send the signatures, obtained in steps 4 and 5 of Alg 2, to the leader , which will collect all these signatures and include them in . Later, when an  is detected to be malicious, the leader will add âs Cluster User Public Key along with its EPID signature to the revocation list .
III-A3 Peering with Phase (Alg. 1, steps 28-41)
Each cluster leader will anonymously authenticate with s using EPID. Once a leader is authenticated by the s, these s join the established p2p network.
During this phase, a global blockchain  is also created to keep track of the key system-wise events. Only s and cluster leaders can participate in the validation and addition of blocks to . To submit a cluster-related block for inclusion in , the leaders will need to have a key that identifies them and their clusters but also could be used to verify the correctness of the submitted block. This is exactly why each leader is required to submit its Cluster Public Key, , to  to be shared with s and other leaders. On top of that, the leader will also share a -TBLS signature of to show that the Cluster Public Key was actually generated in collaboration with members of the cluster using TBLS.DKG. The validators will validate the TBLS signature through a round of BFT consensus by verifying the signature against .
In , an operational cluster is required to transmit a beacon for a certain duration, every period, so that the cluster could be discovered by nearby joining s, as in [20]. is a system design parameter that could be adjusted based on system dynamics and on how frequent s join the system. A leader needs to request this beacon from one of the s and can acquire it only if it successfully proves its legitimacy to  through EPID as depicted in steps 24-28 of Alg.1. This is achieved by creating an EPID signature of a challenge message that  has created for this purpose. If the EPID signature is successfully verified,  issues a beacon to and submits the beacon to  so that it is accessible by all  entities. picks some representatives from to transmit the beacon every , for a specific duration over a system control channel that is known a priori and is assumed to be reserved for this purpose.
Note that s in only need to have a light copy of  containing the latest state of the system including the current number of clusters and their corresponding beacons. Note also that a secure session is maintained between s and the leader of as long as EPID revocation list is not updated. This is to avoid running the EPID verification protocol for every block or transaction submitted by .
III-B Joining
As depicted in Alg. 3, when an  desires to join , it needs to tune to the control channel and scans it to detect any beacons transmitted by any nearby cluster. Failure to detect any beacons means that either no cluster is nearby or all nearby clusters are not accepting new s. In either case,  will start a new cluster and will request a beacon from one of the s and will itself start accepting new members, as described in Alg. 1.
When the new  detects a beacon, it invokes the TwoWayEPID procedure with the cluster leader to ensure that the  is legitimate and can be allowed to join the cluster, and that the leader is also in a good standing. If the two-way verification is successful, the new  is admitted to the cluster and will immediately request from the cluster leader and peer with the s in the cluster. Newly admitted s will have to wait until the next period to be able to participate in the cluster and enjoy spectrum resources.
Note that the admission of a new  to a cluster is also subject to interference constraints. Members of the cluster must ensure that the entry of this new  does not lead to an aggregate interference that is harmful to higher tier users or to other s in the cluster to satisfy coexistence. This could be resolved by adjusting grants and transmission parameters of the other s in the cluster, or simply denying the entry of a new  to the cluster in the extreme case. These scenarios could be enforced by the cluster leader and agreed upon through consensus among members of the cluster.
Clusters will also need to perform rekeying operation when new s are added to their clusters, and this takes place at the end of each  period, where again  is a system design parameter that could be adjusted. Clusters could also choose to perform rekeying when malicious and/or faulty  s are detected. The rekeying steps are shown in Alg. 2.
III-C Querying for Spectrum Availability
We now focus on describing the different steps required to privately query s for spectrum availability in a specific cluster. These steps are also summarized in Alg. 4.
In , the cluster leaders will be in charge of querying s for spectrum availability on behalf of their  members, and a leader will query s only when: (i) Period allocated for using some channel(s) expires, (ii) quality of currently assigned channels degrades, or (iii) currently used channels need to be vacated (e.g., when requested by s).
III-C1 Authentication and permission
In , in order for a leader to query s, its cluster is required to have a minimum of 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 s, a cluster leader, , needs to show that its cluster meets this requirement by providing EPID signatures created by different legitimate s over a challenge message that s created for this purpose; this is depicted in steps 2-5 of Alg. 4. Note that EPID prevents from forging these signatures without being detected. Also,  will not require these EPID signatures later unless a change in the membership of takes place. If this verification is successful, then proceeds with querying s for available channels. Otherwise, s will label as malicious and add it to the revocation list, . To ensure robustness against a leaderâs failures, a timeout period could be considered beyond which if the  members do not receive spectrum availability information from their leader, the leader would be labeled as malicious and added to the revocation list, , and a new leader will be elected. The Rekeying procedure is then run among the cluster members, and the new leader will request a new beacon for the cluster as in steps 24-30 of Alg.1.
III-C2 Spectrum querying
To enable private querying of s,  adopts multi-server private information retrieval () protocol [21], termed BatchPIR, which leverages the multiple s, inherently available by  design, to enable the cluster leaders to efficiently retrieve data records from s while preventing s from learning anything about the records being retrieved. It guarantees information-theoretic privacy, i.e. privacy against computationally unbounded servers, to cluster leaders as long as the spectrum database content, , is replicated among non-colluding s [12]. The main idea consists of decomposing each leaderâs query into several sub-queries each processed by a different  to prevent leaking any information about the queried record. BatchPIR also supports batching of the queries, i.e. retrieving multiple blocks simultaneously, which is a desirable feature for . It takes as input the list of s, the maximum allowed number of colluding servers, the dimensions of , and the indices of records of interest. For this, we assume that leaders can learn the index of the records of interest through an inverted index mechanism agreed upon with s.
A cluster leader, , collects queries from the s in its cluster , batches them together, and invokes BatchPIR with its peered s. then submits the query response, , as a block for inclusion in . s in run BFT consensus to validate this by simply verifying the digitally signed database records against the public key of s. This is to prevent the leader from maliciously sharing altered availability information.
Each record in s contains a smart contract that defines its usage rules. Once is validated by s and added to , the scripts of the included smart contracts will reside in . will issue a transaction to trigger the execution of these smart contracts, which will take as input the list of s in the cluster, their cell indices, and the spectrum availability information. All this information is already stored in and is accessible by all s in . Once triggered, these smart contracts run independently and automatically in a prescribed and deterministic fashion on every âs copy of , in accordance with the data that was enclosed in the triggering transaction. The execution of these smart contracts will result in the automatic assignment of spectrum resources in a way that follows âs guidelines while ensuring coexistence between s. This assignment will be valid for the duration of the period.
III-D Notifying about Spectrum Usage
Once spectrum resources are allocated among s, the leader shares with the s the allocation information, including the channels to be used by the members of , the locations where these channels will be used, and aggregated transmit power over those chosen channels. The leader can also collect the received signal strengths in the used and adjacent frequencies, the received packet error rates, and other standard interference metrics for all s in the cluster. The leader will propose a block containing this information to the members of the cluster for validation. They will verify the correctness of this information and sign the block using TBLS. If the validators successfully verify that was agreed upon and signed by members of via BFT consensus combined with TBLS, then is added to  and s will include this information in their records. Otherwise, will be flagged as malicious and its EPID signature of will be added to . These steps are summarized in Alg. 5.
IV Security Analysis
IV-1 Threat Model
 assumes that s are honest-but-curious, in that they act âhonestlyâ and follow the protocol in terms of handling queries and sharing spectrum availability information, but they are also âcuriousâ about sâ information and try to infer it from the messages they receive from s.  also assumes that these s do not collude with each other, nor with the s. We refer to a  that faithfully follows the protocol as honest; otherwise, it is referred to as Byzantine.  assumes that these Byzantine s do not collude with s, and for each cluster , at least  of the s participate in the signature, and no more than s are Byzantine. These s serve as witnesses for the cluster to make sure that the leader does not communicate compromised information.
IV-2 Security Objectives
Given the above threat model, Â aims to achieve the following security objectives:
\SOUL@Private Spectrum Availability Querying: s can query s privately, without revealing their operational information.
\SOUL@Private Spectrum Usage Notification: s can notify s about their channel usage and transmission parameters privately, without revealing their operational information.
\SOUL@Robustness to Failures: All security guarantees are maintained, even when a system entity fails or is compromised.
\SOUL@Immutable Public Log for Auditability: A globally consistent, tamper-resistant log is maintained, where each system event, once produced and logged, cannot be altered or deleted.
\SOUL@Anonymity and Membership Verifiability: sâ authenticity can be verified before the s are granted system access, and s cannot be identified at any stage of protocol execution.
\SOUL@Location Privacy Protection of s: sâ physical location information is kept private at all times from all s.
IV-3 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**.**
*Â achieves unforgeability and robustness of TBLSÂ signatures against an adversary that can corrupt any s within a cluster as long as the Gap-Diffie-Hellman problem is intractable.*
Corollary 2**.**
* ensures consistency and resistance to fork attacks for a permissioned blockchain running BFT consensus in every if , where is the number of signature shares required to construct a group signature for , and satisfies for BFT mechanisms  [22].*
Corollary 3**.**
*Â guarantees unforgeability and robustness of TBLSÂ signatures while ensuring consistency and resistance to fork attacks for of against an adversary that can corrupt any .*
Corollary 4**.**
*Â guarantees s with information-theoretic, private spectrum availability querying from s.*
Corollary 5**.**
*Â guarantees anonymous membership verification through EPIDÂ as long as the Decisional Diffie-Hellman and the strong RSA assumptions hold and the underlying primitives they use are secure.*
Corollary 6**.**
*Â is robust against Byzantine failures of both s and s alike.*
Corollary 7**.**
*Â guarantees location privacy information protection to all s.*
V Performance Evaluation
We assess the effectiveness of  by evaluating the performance of its building blocks and algorithms. These evaluations are performed both analytically and empirically via either implementations or benchmarking of the underlying math and crypto operations using MIRACL library [23]. Experiments are carried out on a testbed that we built on Geni platform [24] using percy++ library [25]. The testbed consists of VMs deployed on different Geni sites, each playing the role of a , and a Lenovo Yoga 3 Pro laptop with 8 GB RAM running Ubuntu 16.10 with an Intel Core m Processor 5Y70 CPU 1.10 GHz to play the role of a cluster leader.
V-1 Distributed Key Generation (DKG)
Running DKG requires performing a number of elliptic curve point multiplications that is proportional to the number of s within the cluster. Using the benchmarking results that we derived with the MIRACL library [23], we provide in Table I an estimate of the average processing time experienced by each  when running DKG. In terms of communication overhead, DKG requires rounds of broadcasts, yielding messages per , or messages per cluster , when assuming no faulty s. Despite its relatively high cost, DKG presents no bottleneck to the system, as it is only executed at initialization or when group membership changes occur.
V-2 Threshold Signature (TBLS)
Table I provides the analytical and empirical cost of the different TBLS operations executed by s in . s repeatedly sign the consensus statement at each BFT round within the cluster. From an âs perspective, this is relatively fast, as it involves signing a single message whose cost is dominated by a modular exponentiation operation, as shown in Table I. The leader, , will, however, incur most of the overhead, as it needs to verify all the signature shares coming from the signing s of , before multiplying them to construct âs signature. These are the most expensive operations involved in TBLS as they require a number of modular multiplications and exponentiations that is linear in as illustrated in Table I. To estimate the running time of TBLSâs different operations, we use dfinityâs implementation of TBLS [26].
V-3 Enhanced Privacy ID (EPID)
We evaluate and analytically and empirically (using Intelâs publicly available SDK [27]) as depicted in Table II. and both require a number of modular exponentiations that is linear in the size of the revocations sublists; these revocation sublists are defined in [14].
Even though these delays seem relatively high, they are still reasonable, especially that these membership proof operations are independent, unfrequent, and do not occur simultaneously, once the system setup completes. Note that this proof has a linear cost in the size of the revocation list and could become quite expensive for both signers and verifiers if such a list becomes large. One possible way to maintain a good performance of  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  needing to prove to FCC that it is a legitimate member and that its membership was not revoked. This would be more efficient than carrying a large revocation list indefinitely and run expensive zero-knowledge proof operations on it. The old list will still be accessible for auditing purposes as it would have been stored already in .
V-4 Private Information Retrieval ()
We use our Geni testbed to evaluate â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 both sâ and cluster leadersâ sides. We summarize the obtained results and the analytic estimation of the overhead in Table III.
V-5 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, , which translates into a total communication overhead of . In this experiment, we also set the throughput between the nodes to and the propagation delay among s to and simulate the protocol to estimate the time it takes to reach a consensus over a block. Our results, depicted in Fig. 2c, show that even for a cluster of size as large as 1000 s, a consensus is reachable in less than even if up to of the s are Byzantine. The overhead of BFT depends heavily on the number of participants and the number of signature verifications required by each participant. Therefore, BFT will have a different cost for each of âs algorithms. For instance in Rekeying, BFT will take as long as since each  will need to verify the signatures of all other s in included in the block submitted by the leader at step 7 of Alg. 2.
V-6 End-to-end Delay
We provide in Table IV the end-to-end delays caused by âs different algorithms, ignoring Byzantine faultiness for simplicity. Observe that the Rekeying has the highest cost, which is invoked mainly when a membership change occurs. One way to address this is by setting Rekeying frequency small, and have joining s wait a little longer before they join the system. Another way to further reduce the cost in most of these algorithms is by using different quorums of users every BFT round. This will reduce the overhead but will also impact the security guarantees and robustness against failures. Despite the relatively high cost of these algorithms, note that these operations are expected to be invoked only every few hours, as it is the case for TVWS, which requires s to query s every 24 hours.
VI Conclusion
We propose , a trustworthy framework for  that preserves sâ operational privacy while adhering to regulatory requirements mandated by FCC in the 3.5 GHz CBRS band.  achieves this by synergizing state-of-the-art cryptographic mechanisms with the blockchain technology. We show the privacy benefits of  through security analysis, simulation and experimentation.
Acknowledgment
This work was supported in part by the US National Science Foundation under NSF awards CNS-1162296 and CNS-1652389.
The reference list from the paper itself. Each links out to its DOI / PubMed record.
- 1[1] FCC, âReport and order and second further notice of proposed rulemaking, number 15-47, gn docket no. 12-354. FCC,â April 2015.
- 2[2] ââ, âOrder on reconsideration and second report and order, number 16-55, gn docket no. 12-354. FCC,â May 2016.
- 3[3] Y. Ye, D. Wu, Z. Shu, and Y. Qian, âOverview of lte spectrum sharing technologies,â IEEE Access , vol. 4, pp. 8105â8115, 2016.
- 4[4] V. Chen, S. Das, L. Zhu, J. Malyar, and P. Mc Cann, âProtocol to access white-space (paws) databases,â Tech. Rep., 2015.
- 5[5] M. A. Clark and K. Psounis, âTrading utility for privacy in shared spectrum access systems,â IEEE/ACM Transactions on Networking (TON) , vol. 26, no. 1, pp. 259â273, 2018.
- 6[6] P. Marshall, Three-tier Shared Spectrum, Shared Infrastructure, and a Path to 5G . Cambridge University Press, 2017.
- 7[7] W. I. Forum, âCbrs communications security technical specification, winnf-15-s-0065,â April 2017.
- 8[8] ââ, âCbrs threat model technical report, winnf-15-p-0089,â May 2016.
