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

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

Tables

Table 1. TABLE I: TBLS  Overhead within cluster 𝒞 ( i ) \mathcal{C}{}^{(i)}

Operation	Analytic Cost	Empirical Cost
DKG Computation	$𝒪\left(n_i\right)\cdot PM$	$1.05s$
DKG Communication	$𝒪\left(n_i\right)$ messages	$\propto 1000$ messages
SignShareGen	$1Hash+1Expp$	$0.63ms$
SignShareVerif	$2t_i\cdot TPO$	$2.3ms$
Signature size	$64$ bytes	$64$ bytes
Private key size	$32$ bytes	$32$ bytes
SignReconstruct	$t_i\cdot \left(Mulpp+Expp\right)$	$461ms$
GroupSignVerif	$2\cdot TPO$	$2.3ms$

Table 2. TABLE II: EPID  complexity

Operation	Analytical Cost	Empirical Cost
$\text{EPID}.\text{Sign}$	$\left(6{\delta }_2+2{\delta }_3+c\right)\cdot Expp$	$135ms$
$\text{EPID}.\text{Verify}$	$\left({\delta }_1+6{\delta }_2+2{\delta }_3+c\right)\cdot Expp$	$120ms$
Signature size	$257$ bytes	$257$ bytes
Private key size	$129$ bytes	$129$ bytes

Table 3. TABLE III: Multi-server 𝑃𝐼𝑅 𝑃𝐼𝑅 \mathit{PIR}  Overhead

Operation	Analytical Cost	Empirical Cost
Leader $\mathrm{𝑆𝑈}$’s query	$q\cdot 𝒪\left({\ell }^{2}r\right)\cdot ad{d}_{𝔽}$	$4.86s$
$\mathrm{𝐷𝐵}$ processing	$q^{0.8}\cdot \left(\frac{8}{3}ad{d}_{𝔽}+mu{l}_{𝔽}\right)\cdot rs$	$2.66s$
Communication	$q\cdot \left(r+s\right)$	$25MB$

Table 4. TABLE IV: End-to-end Delay of 𝑇𝑟𝑢𝑠𝑡𝑆𝐴𝑆 𝑇𝑟𝑢𝑠𝑡𝑆𝐴𝑆 \mathit{TrustSAS}  Algorithms

Algorithm	Major Operations	Total Cost
Alg. 2 Rekeying within $𝒞{}^{\left(i\right)}$	DKG + $\text{TBLS}.\text{SignShareGen}$ + $\text{EPID}.\text{Sign}$ +  BFT($n_i$)	$77.47s$
Alg. 3: Join $𝒞{}^{\left(i\right)}$	TwoWayEPID + Rekeying	$78.12s$
Alg. 4: Private Spec. Query	$\text{EPID}.\text{Sign}$ + $\tau \text{EPID}.\text{Verify}$ + BatchPIR +  BFT($n_i$)	$13.15s$
Alg. 5: Spec. Usage Notifica.	$t(\text{TBLS}.\text{SignShareGen}$+$\text{TBLS}.\text{SignShareVerif})$+$\text{TBLS}.\text{SignReconstruct}$+$\text{BFT}(\ell$+$n_c$)	$1.85s$

Table 5. TABLE V: BFT complexity

Operation	Analytical Cost	Empirical Cost
Communication per user	$𝒪\left(n_i\log n_i\right)$	$\propto 3000$ messages
Consensus w/o failures	$𝒪\left(n_i^2\log n_i\right)$	$4.3s$
Consensus w/ failures	$𝒪\left(n_i^2\log n_i\right)$	$6.32s$

Full text

We analyze the security of our framework and evaluate its performance through analysis, simulation and experimentation. We show that $\mathit{TrustSAS}$ can offer high security guarantees with reasonable overhead, making it an ideal solution for addressing $\mathit{SU}$s’ privacy issues in an operational $\mathit{SAS}$ environment.

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 ($\mathit{SAS}$) to govern CBRS sharing among incumbent and secondary users. Like the case of TV white space (TVWS) access, $\mathit{SAS}$ comprises multiple geolocation spectrum databases ($\mathit{DB}$s), operated (typically) by different administrators and are required to communicate amongst themselves to ensure frequency use information consistency. Also, like in TVWS, $\mathit{SU}$s need to query the $\mathit{DB}$s using their exact location information to be able to learn about CBRS spectrum opportunities in their vicinity.

$\mathit{SAS}$ supports three types of users: primary users ($\mathit{PU}$s), priority access license (PAL) users, and general authorized access (GAA) users. $\mathit{PU}$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 $\mathit{PU}$s. GAA users, on the other hand, operate opportunistically, in that they need to query the $\mathit{DB}$s to learn about which spectrum portions are available—not being used by higher tier ($\mathit{PU}$ 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, $\mathit{SU}$ refers to a GAA user, since only GAA users need to query $\mathit{DB}$s to learn spectrum availability; PAL users acquire spectrum access via bidding.

I-A Key $\boldsymbol{\mathit{SAS}{}}$ Requirements

As stipulated by FCC [1], $\mathit{SAS}$’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 $\mathit{SAS}$, 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 $\mathit{SAS}$, which include [2]:

$\bullet$ Information gathering and retention: $\mathit{SU}$s must keep $\mathit{SAS}$ informed about their current operating parameters and channel usage information at all time, so that $\mathit{SAS}$ can maintain accurate and up-to-date frequency usage information. While this is mandatory in $\mathit{SAS}$, it is only optional in TVWS.

$\bullet$ Coexistence: $\mathit{SAS}$ 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 $\mathit{PU}$s, and not on ensuring coexistence among $\mathit{SU}$s.

$\bullet$ Auditability: $\mathit{SAS}$ must maintain audit logs of all system operations [7], including $\mathit{DB}$ write operations, user membership status changes, etc. $\mathit{SAS}$ uses these logs to verify and ensure compliance with regulatory rules and policies.

It is then important that these requirements be met when designing $\mathit{SAS}$. 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 $\boldsymbol{\mathit{SAS}{}}$

A subtle privacy concern arises in $\mathit{SAS}$, which pertains merely to the fact that $\mathit{SU}$s are required to share sensitive operational information with $\mathit{DB}$s in order for them to obtain spectrum availability information [2]. This information, which may include $\mathit{SU}$s’ sensitive data, such as their locations, identities, spectrum usage, and transmission parameters, may be collected by an adversary or a malicious $\mathit{SAS}$ administrator and be exploited for economic, political, or other purposes [8]. For instance, fine-grained location information can easily reveal other personal information about $\mathit{SU}$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 $\mathit{SU}$s’ sensitive information while at the same time abiding by FCC’s rules and policies prescribed for $\mathit{SAS}$.

I-C Contributions and Paper Organization

Most of $\mathit{SAS}$’ rules require $\mathit{SU}$s to share a great deal of their sensitive information, which conflict with $\mathit{SU}$s’ privacy objectives. As a result, we are facing a dilemma: On one hand, all $\mathit{SAS}$ entities need to comply with $\mathit{SAS}$’s requirements to have a stable, interference-free radio environment. On the other hand, it is important to offer privacy guarantees to $\mathit{SU}$s so as to promote this new spectrum sharing technology. This dilemma makes the task of designing $\mathit{SAS}$ mechanisms that provide privacy guarantees while complying with $\mathit{SAS}$’s requirements and rules very challenging.

We strongly envision that the public’s (long-term) acceptance of the $\mathit{SAS}$ paradigm will greatly depend on the robustness and trustworthiness of $\mathit{SAS}$ vis-a-vis of its ability to address these privacy concerns. Therefore, in this work, we propose $\mathit{TrustSAS}$, a trustworthy $\mathit{SAS}$ design framework that aims to achieve these two conflicting goals. More specifically, $\mathit{TrustSAS}$ 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 $\mathit{SAS}$ 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 $\mathit{TrustSAS}$. Fig. 1 can be referred to throughout this section to facilitate the description.

II-A Architectural Components

As illustrated in Fig. 1, $\mathit{TrustSAS}$ comprises three main architectural entities: FCC, multiple $\mathit{DB}$s, and multiple $\mathit{SU}$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 $\mathit{TrustSAS}$, FCC is responsible for enforcing compliance with regulatory requirements, providing system keying materials, handling the registration of $\mathit{SU}$s, and granting them permissions to join $\mathit{TrustSAS}$. $\mathit{TrustSAS}$ leverages and relies on the existence of multiple $\mathit{DB}$s for spectrum access, each typically run by a different administrator. These $\mathit{DB}$s are assumed to be synchronized and to be sharing the same content, as mandated by FCC. Also, $\mathit{TrustSAS}$ supports multiple $\mathit{SU}$s, including a set of pre-registered $\mathit{SU}$s to be deployed specifically for playing the role of anchor nodes. These anchor $\mathit{SU}$s serve to establish a backbone peer-to-peer (p2p) network that can be discoverable and joinable by new $\mathit{SU}$s.

The content of each $\mathit{DB}$ can be viewed/modelled as an $\mathit{r}{}\times\mathit{b}{}$ matrix $\boldsymbol{\mathcal{D}}$ of size $\eta{}$ bits, where $\mathit{r}$ is the number of records in the database, each of size $\mathit{b}$ bits. Each record in $\boldsymbol{\mathcal{D}}$ 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 $\mathit{TrustSAS}$, each record in $\boldsymbol{\mathcal{D}}$ contains a smart contract that is to be created by $\mathit{DB}$s to define channel usage rules, such as the maximum number of $\mathit{SU}$s allowed to transmit simultaneously in a given location, $\mathit{SU}$’s maximum transmit power, etc. With these smart contracts, $\mathit{TrustSAS}$ ensures fair sharing of the spectrum resources, and limits the interference among $\mathit{SU}$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 $\mathit{SU}$s need to query $\mathit{DB}$s for an updated channel availability information periodically every $\mathcal{T}_{epoch}{}$, where $\mathcal{T}_{epoch}{}$ is a tunable system design parameter. The geographical area serviced by $\mathit{TrustSAS}$ is modeled as a grid of $N\times N$ cells of equal sizes, and an $\mathit{SU}$’s location is expressed through the grid’s cell index.

II-B $\mathit{TrustSAS}$* Initial Setup*

The first phase needed for setting up $\mathit{TrustSAS}$ is bootstrapping (see Fig. 1), during which FCC creates the system parameters and keys, specific to $\mathit{TrustSAS}$, and shares them with $\mathit{DB}$s. Also, $\mathit{SU}$s first need to register and request $\mathit{SAS}$ access privileges from FCC before they can join $\mathit{TrustSAS}$. Once registered, FCC provides the joining $\mathit{SU}$ with the anchor $\mathit{SU}$ list, membership keys, and the procedure necessary for the $\mathit{SU}$ to authenticate with and join $\mathit{TrustSAS}$. Note that, in $\mathit{TrustSAS}$, all messages communicated between the $\mathit{SU}$s and the $\mathit{DB}$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 $\mathit{SU}$s that join $\mathit{TrustSAS}$ will maintain communication with one another via an overlay p2p network, and a newly joining $\mathit{SU}$ will rely on anchor $\mathit{SU}$s to discover and join the p2p network.$\mathit{TrustSAS}$ relies on an anonymous digital signature technique, explained in Section III-A, to enable all these $\mathit{SU}$s to anonymously authenticate and verify each other’s legitimacy when peering with one another. This anonymous authentication will also enable $\mathit{SU}$s to enjoy system services anonymously, yet in a verifiable way, to break the link between their sensitive operational data and their true identities.

$\mathit{TrustSAS}$ adopts a clustering approach, where joined $\mathit{SU}$s group themselves into clusters and elect cluster leaders, with the leaders being responsible for representing their $\mathit{SU}$s for interacting with other system entities. Not only will this improve $\mathit{TrustSAS}$ scalability, but also protect $\mathit{SU}$s’ privacy, as it will limit the interaction with $\mathit{DB}$s to only cluster leaders. Once clusters are established, $\mathit{SU}$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 $\mathit{DB}$s, and upon successful authentication, these $\mathit{DB}$s will join and be part of the established p2p network. This way, $\mathit{DB}$s will not be involved in the initial clustering of $\mathit{SU}$s, and therefore they will not be able to infer the $\mathit{SU}$s’ location information. This phase is detailed in Section III-A3.

II-C $\mathit{TrustSAS}$* Main Operations*

II-C1 Querying Spectrum Availability Information

Each cluster leader acts on behalf of its $\mathit{SU}$ members and privately queries $\mathit{DB}$s for spectrum availability information. Even though the true identities of all $\mathit{SU}$s, including leaders, are hidden in $\mathit{TrustSAS}$, this is not sufficient to preserve their operational privacy. In fact, since each record in $\mathit{DB}$s is associated with a unique location, $\mathit{DB}$s may infer the location of the leaders from their queries and can still use this information for tracking purposes. To prevent this, $\mathit{TrustSAS}$ protects the leaders’ queries through the adoption of multi-server private information retrieval ($\mathit{PIR}$) 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 $\mathit{DB}$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. $\mathit{TrustSAS}$ 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, $\mathit{TrustSAS}$ ensures that cluster leaders report an accurate and non-altered spectrum usage information that is easily verifiable. Other leaders and $\mathit{DB}$s will distributively reach an agreement about the validity of this information, which, if valid, will be updated to $\mathit{DB}$s’ records. Detailed description of this is provided in Section III-D.

III The Proposed Framework: $\mathit{TrustSAS}$

$\mathit{TrustSAS}$ 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 $\mathit{TrustSAS}$, 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 $\mathit{TrustSAS}$.

III-A System Setup

The first component of $\mathit{TrustSAS}$, 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)

$\mathit{TrustSAS}$ ensures that $\mathit{SU}$s activities are anonymous, yet verifiable, by leveraging Intel’s anonymous digital signature, known as enhanced privacy ID (EPID) [14]. EPID allows any $\mathit{SU}$ to prove its membership legitimacy to other $\mathit{TrustSAS}$ entities, without revealing its true identity, using zero-knowledge proof [15]. EPID also enables access revocation of misbehaving $\mathit{SU}$s anonymously, by maintaining and using a revocation list $\mathcal{L}$ based on $\mathit{SU}$s’ signatures. EPID typically runs four procedures. The first, $\textsc{EPID}{}.\textsc{Setup}$, 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 ($\mathcal{K}_{pk}$) and Membership Issuing Secret Key ($\mathcal{K}_{sk}$). The first key, $\mathcal{K}_{pk}$, is shared among all entities of $\mathit{TrustSAS}$, and used by $\mathit{SU}$s and $\mathit{DB}$s to anonymously verify the membership legitimacy of another $\mathit{SU}$. The second key, $\mathcal{K}_{sk}$, is kept secret and used only by FCC to create a unique Membership Private Key, $\mathit{sk}{}_{\mathit{SU}{}}$, for each joining $\mathit{SU}$, a key that the $\mathit{SU}$ 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, $\textsc{EPID}{}.\textsc{Join}$, is run interactively between each joining $\mathit{SU}$ and FCC, and takes as input $\mathcal{K}_{pk}$ and FCC’s public key $\mathcal{K}_{FCC}$, as illustrated in steps 4 and 9 of Alg. 1. It results in $\mathit{SU}$ obtaining $\mathcal{K}_{pk}$ and $\mathit{sk}{}_{\mathit{SU}}{}$. The third procedure, $\textsc{EPID}{}.\textsc{Sign}$, allows an $\mathit{SU}$ to anonymously prove its membership legitimacy and that it does not belong to the revocation list (i.e., its signature over a challenge message, $m$, does not belong to $\mathcal{L}$). Note that EPID signatures produced by the same $\mathit{SU}$ are linkable; this prevents any malicious $\mathit{SU}$ from forging multiple signatures on behalf of other $\mathit{SU}$s. To validate the EPID signature of joining $\mathit{SU}$, a verifier uses the fourth procedure, EPID.Verify, using the membership public key, $\mathcal{K}_{pk}$, by checking that $\mathit{SU}$’s signature is not in $\mathcal{L}$.

$\mathit{TrustSAS}$ also requires that some $\mathit{SU}$s be appointed to serve as anchor nodes. These $\mathit{SU}$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 $\mathit{SU}$, that obtained its $\mathit{sk}{}_{\mathit{SU}{}}$ through EPID.Join, will also get the list of anchor nodes, denoted by $\mathcal{A}$ throughout, from FCC.

III-A2 Joining and Clustering Phase (Alg. 1, steps 21-26)

Every joining $\mathit{SU}$ uses the list $\mathcal{A}$ to discover and join the ongoing p2p network. The joining $\mathit{SU}$ then needs to authenticate with its peers and verify their legitimacy via TwoWayEPID (Alg. 1, step 2). After enough $\mathit{SU}$s have joined $\mathit{TrustSAS}$, these $\mathit{SU}$s will form clusters based on their locations; this may require the $\mathit{SU}$s to expose their locations to other $\mathit{SU}$s, but it should be no issue at this point since $\mathit{DB}$s are not part of the p2p network yet. The members of each $\mathcal{C}{}^{(i)}$ will also maintain a cluster (local) blockchain, $\mathcal{BC}{}^{(i)}$, to log and keep track of key events taking place in the cluster.

$\mathit{TrustSAS}$ requires $\mathit{SU}$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, $\mathit{TrustSAS}$ adopts the robust $(t,n)$-threshold BLS (TBLS) signature scheme [16]. TBLS requires no more than (any) $t_{i}+1$ of the $n_{i}$ $\mathit{SU}$s in $\mathcal{C}{}^{(i)}$ to collaboratively create a cluster signature over a statement. For this, members of each $\mathcal{C}{}^{(i)}$ will have to run the Rekeying operation described in Alg 2, among the $n_{i}$ $\mathit{SU}$s of $\mathcal{C}{}^{(i)}$, to jointly generate the keys required for performing such distributed $(t_{i},n_{i})$-TBLS signatures within $\mathcal{C}{}^{(i)}$. This is achieved by running TBLS’s distributed key generation (DKG) [17] operation which will result in each $\mathit{SU}{}~{}j$ in $\mathcal{C}{}^{(i)}$ obtaining three keys: Cluster Public Key, $y^{(i)}$, which is shared among all $\mathit{SU}$s in $\mathcal{C}{}^{(i)}$, Cluster User Secret Key, $x^{(i)}_{j}$, and Cluster User Public Key, $z^{(i)}_{j}=g^{x^{(i)}_{j}}$. The Cluster User Secret Keys $(x^{(i)}_{1},\cdots,x^{(i)}_{n_{i}})$ are a $(t_{i},n_{i})$-threshold secret sharing of the private key $x^{(i)}=\log_{g}y^{(i)}$. These shares are constructed using Shamir secret sharing [18] such that any subset of $t_{i}+1$ $\mathit{SU}$s from $\mathcal{C}{}^{(i)}$ can recover $x^{(i)}$ using Lagrange interpolation. Cluster User Public Keys represent $\mathit{SU}$s’ pseudonyms within $\mathcal{C}{}^{(i)}$ and are also used to identify $\mathit{SU}$s’ transactions in the local blockchain, $\mathcal{BC}{}^{(i)}$. In addition to DKG, TBLS comprises four other operations:

• •

SignShareGen: It enables each $\mathit{SU}$ $j$ to compute the signature share $\sigma_{j}^{(i)}$ over a message $m$ to be signed by $\mathcal{C}{}^{(i)}$.

• •

SignShareVerif: It enables members of $\mathcal{C}{}^{(i)}$ to verify $\mathit{SU}$ $j$’s signature share $\sigma^{(i)}_{j}$ against its public key $z^{(i)}_{j}$.

• •

SignReconstruct: The leader of a cluster collects a set of $t_{i}+1$ signature shares of a message $m$, $\mathcal{H}_{i}$, verified using SignShareVerif, from $t_{i}+1$ $\mathit{SU}$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 $\mathcal{C}{}^{(i)}$’s public key $y^{(i)}$.

Note that TBLS does not require reconstructing $x^{(i)}$ during the signing process. Even after repeated signing, no $\mathit{SU}$ could learn any information about $x^{(i)}$ that would enable it to create signatures without $t_{i}$ other $\mathit{SU}$s [19]. We refer the reader to [16] for more details about TBLS.

To handle system-wise access revocations, $\mathit{TrustSAS}$ requires that each $\mathit{SU}$’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 $\mathit{SU}$ $j$ signs its Cluster User Public Key $z_{j}^{(i)}$ itself, which is known to all $\mathit{SU}$s in the cluster, using EPID.Sign with its EPID Membership Private Key, $\mathit{sk}{}_{j}$ (Alg 2, step 4). This serves to create a cryptographic binding between $\mathit{SU}$’s EPID signature and its Cluster User Public Key. This binding will then have to be submitted as a transaction to be included in $\mathcal{BC}{}^{(i)}$. This is done by making $\mathit{SU}$ sign the binding from the previous step using TBLS.SignShareGen with its Cluster User Secret Key, $x^{(i)}_{j}$ (Alg 2, step 5). Then each $\mathit{SU}$ will send the signatures, obtained in steps 4 and 5 of Alg 2, to the leader $\mathit{SU}{}^{(i)}_{L}$, which will collect all these signatures and include them in $\mathcal{BC}{}^{(i)}$. Later, when an $\mathit{SU}$ $j$ is detected to be malicious, the leader will add $\mathit{SU}$’s Cluster User Public Key $z^{(i)}_{j}$ along with its EPID signature to the revocation list $\mathcal{L}$.

III-A3 Peering with $\boldsymbol{\mathit{DB}{}s}$ Phase (Alg. 1, steps 28-41)

Each cluster leader will anonymously authenticate with $\mathit{DB}$s using EPID. Once a leader is authenticated by the $\mathit{DB}$s, these $\mathit{DB}$s join the established p2p network.

During this phase, a global blockchain $\mathcal{BC}{}$ is also created to keep track of the key system-wise events. Only $\mathit{DB}$s and cluster leaders can participate in the validation and addition of blocks to $\mathcal{BC}{}$. To submit a cluster-related block for inclusion in $\mathcal{BC}{}$, 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, $y^{(i)}$, to $\mathcal{BC}{}$ to be shared with $\mathit{DB}$s and other leaders. On top of that, the leader will also share a $(t_{i},n_{i})$-TBLS signature of $y^{(i)}$ 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 $y^{(i)}$.

In $\mathit{TrustSAS}$, an operational cluster is required to transmit a beacon for a certain duration, every $\mathcal{T}_{\mathcal{\beta}}{}$ period, so that the cluster could be discovered by nearby joining $\mathit{SU}$s, as in [20]. $\mathcal{T}_{\mathcal{\beta}}{}$ is a system design parameter that could be adjusted based on system dynamics and on how frequent $\mathit{SU}$s join the system. A leader $\mathit{SU}{}^{(i)}_{L}$ needs to request this beacon from one of the $\mathit{DB}$s and can acquire it only if it successfully proves its legitimacy to $\mathit{DB}$ through EPID as depicted in steps 24-28 of Alg.1. This is achieved by creating an EPID signature of a challenge message $m$ that $\mathit{DB}$ has created for this purpose. If the EPID signature is successfully verified, $\mathit{DB}$ issues a beacon to $\mathit{SU}{}^{(i)}_{L}$ and submits the beacon to $\mathcal{BC}{}$ so that it is accessible by all $\mathit{TrustSAS}$ entities. $\mathit{SU}{}_{L}^{(i)}$ picks some representatives from $\mathcal{C}{}^{(i)}$ to transmit the beacon every $\mathcal{T}_{\mathcal{\beta}}{}$, 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 $\mathit{SU}$s in $\mathcal{C}{}^{(i)}$ only need to have a light copy of $\mathcal{BC}{}$ 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 $\mathit{DB}$s and the leader of $\mathcal{C}{}^{(i)}$ 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 $\mathit{SU}{}^{(i)}_{L}$.

III-B Joining $\mathit{TrustSAS}$

As depicted in Alg. 3, when an $\mathit{SU}$ desires to join $\mathit{TrustSAS}$, 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 $\mathit{SU}$s. In either case, $\mathit{SU}$ will start a new cluster and will request a beacon from one of the $\mathit{DB}$s and will itself start accepting new members, as described in Alg. 1.

When the new $\mathit{SU}$ detects a beacon, it invokes the TwoWayEPID procedure with the cluster leader to ensure that the $\mathit{SU}$ 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 $\mathit{SU}$ is admitted to the cluster and will immediately request $\mathcal{BC}{}^{(i)}$ from the cluster leader and peer with the $\mathit{SU}$s in the cluster. Newly admitted $\mathit{SU}$s will have to wait until the next $\mathcal{T}_{epoch}{}$ period to be able to participate in the cluster and enjoy spectrum resources.

Note that the admission of a new $\mathit{SU}$ to a cluster is also subject to interference constraints. Members of the cluster must ensure that the entry of this new $\mathit{SU}$ does not lead to an aggregate interference that is harmful to higher tier users or to other $\mathit{SU}$s in the cluster to satisfy coexistence. This could be resolved by adjusting grants and transmission parameters of the other $\mathit{SU}$s in the cluster, or simply denying the entry of a new $\mathit{SU}$ 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 $\mathit{SU}$s are added to their clusters, and this takes place at the end of each $\mathcal{T}_{epoch}{}$ period, where again $\mathcal{T}_{epoch}{}$ is a system design parameter that could be adjusted. Clusters could also choose to perform rekeying when malicious and/or faulty $\mathit{SU}$ 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 $\mathit{DB}$s for spectrum availability in a specific cluster. These steps are also summarized in Alg. 4.

In $\mathit{TrustSAS}$, the cluster leaders will be in charge of querying $\mathit{DB}$s for spectrum availability on behalf of their $\mathit{SU}$ members, and a leader will query $\mathit{DB}$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 $\mathit{PU}$s).

III-C1 Authentication and permission

In $\mathit{TrustSAS}$, in order for a leader to query $\mathit{DB}$s, its cluster is required to have a minimum of $\tau$ $\mathit{SU}$s, where $\tau$ is a system parameter that could be tuned depending on the desired robustness and security levels within each cluster. Therefore, before querying the $\mathit{DB}$s, a cluster leader, $\mathit{SU}{}_{L}^{(i)}$, needs to show that its cluster $\mathcal{C}{}^{(i)}$ meets this requirement by providing $\tau$ EPID signatures created by different legitimate $\mathit{SU}$s over a challenge message $m$ that $\mathit{DB}$s created for this purpose; this is depicted in steps 2-5 of Alg. 4. Note that EPID prevents $\mathit{SU}{}_{L}^{(i)}$ from forging these $\tau$ signatures without being detected. Also, $\mathit{TrustSAS}$ will not require these $\tau$ EPID signatures later unless a change in the membership of $\mathcal{C}{}^{(i)}$ takes place. If this verification is successful, then $\mathit{SU}{}_{L}^{(i)}$ proceeds with querying $\mathit{DB}$s for available channels. Otherwise, $\mathit{DB}$s will label $\mathit{SU}{}_{L}^{(i)}$ as malicious and add it to the revocation list, $\mathcal{L}$. To ensure robustness against a leader’s failures, a timeout period could be considered beyond which if the $\mathit{SU}$ members do not receive spectrum availability information from their leader, the leader would be labeled as malicious and added to the revocation list, $\mathcal{L}$, 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 $\mathit{DB}$s, $\mathit{TrustSAS}$ adopts multi-server private information retrieval ($\mathit{PIR}$) protocol [21], termed BatchPIR, which leverages the multiple $\mathit{DB}$s, inherently available by $\mathit{SAS}$ design, to enable the cluster leaders to efficiently retrieve data records from $\mathit{DB}$s while preventing $\mathit{DB}$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, $\boldsymbol{\mathcal{D}}{}$, is replicated among $\ell\geq 2$ non-colluding $\mathit{DB}$s [12]. The main idea consists of decomposing each leader’s query into several sub-queries each processed by a different $\mathit{DB}$ 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 $\mathit{TrustSAS}$. It takes as input the list of $\mathit{DB}$s, the maximum allowed number of colluding servers, the dimensions of $\boldsymbol{\mathcal{D}}$, 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 $\mathit{DB}$s.

A cluster leader, $\mathit{SU}{}_{L}^{(i)}$, collects queries from the $\mathit{SU}$s in its cluster $\mathcal{C}{}^{(i)}$, batches them together, and invokes BatchPIR with its peered $\mathit{DB}$s. $\mathit{SU}{}_{L}^{(i)}$ then submits the query response, $\boldsymbol{\mathcal{D}}{}_{\boldsymbol{q}}$, as a block $\mathcal{B}{}_{epoch}$ for inclusion in $\mathcal{BC}{}^{(i)}$. $\mathit{SU}$s in $\mathcal{C}{}^{(i)}$ run BFT consensus to validate this $\mathcal{B}{}_{epoch}$ by simply verifying the digitally signed database records against the public key of $\mathit{DB}$s. This is to prevent the leader from maliciously sharing altered availability information.

Each record in $\mathit{DB}$s contains a smart contract that defines its usage rules. Once $\mathcal{B}{}_{epoch}$ is validated by $\mathit{SU}$s and added to $\mathcal{BC}{}^{(i)}$, the scripts of the included smart contracts will reside in $\mathcal{BC}{}^{(i)}$. $\mathit{SU}{}_{L}^{(i)}$ will issue a transaction to trigger the execution of these smart contracts, which will take as input the list of $\mathit{SU}$s in the cluster, their cell indices, and the spectrum availability information. All this information is already stored in $\mathcal{BC}{}^{(i)}$ and is accessible by all $\mathit{SU}$s in $\mathcal{C}{}^{(i)}$. Once triggered, these smart contracts run independently and automatically in a prescribed and deterministic fashion on every $\mathit{SU}$’s copy of $\mathcal{BC}{}^{(i)}$, 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 $\mathit{TrustSAS}$’s guidelines while ensuring coexistence between $\mathit{SU}$s. This assignment will be valid for the duration of the $\mathcal{T}_{epoch}{}$ period.

III-D Notifying about Spectrum Usage

Once spectrum resources are allocated among $\mathit{SU}$s, the leader $\mathit{SU}{}_{L}^{(i)}$ shares with the $\mathit{DB}$s the allocation information, including the channels to be used by the members of $\mathcal{C}{}^{(i)}$, 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 $\mathit{SU}$s in the cluster. The leader will propose a block $\mathcal{B}{}_{i}$ 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 $\mathcal{B}{}_{i}$ was agreed upon and signed by members of $\mathcal{C}{}^{(i)}$ via BFT consensus combined with TBLS, then $\mathcal{B}{}_{i}$ is added to $\mathcal{BC}{}$ and $\mathit{DB}$s will include this information in their records. Otherwise, $\mathit{SU}{}_{L}^{(i)}$ will be flagged as malicious and its EPID signature of $y^{(i)}$ will be added to $\mathcal{L}$. These steps are summarized in Alg. 5.

IV Security Analysis

IV-1 Threat Model

$\mathit{TrustSAS}$ assumes that $\mathit{DB}$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 $\mathit{SU}$s’ information and try to infer it from the messages they receive from $\mathit{SU}$s. $\mathit{TrustSAS}$ also assumes that these $\mathit{DB}$s do not collude with each other, nor with the $\mathit{SU}$s. We refer to a $\mathit{SU}$ that faithfully follows the protocol as honest; otherwise, it is referred to as Byzantine. $\mathit{TrustSAS}$ assumes that these Byzantine $\mathit{SU}$s do not collude with $\mathit{DB}$s, and for each cluster $\mathcal{C}{}^{(i)}$, at least $t_{i}$ of the $n_{i}$ $\mathit{SU}$s participate in the signature, and no more than $f_{i}=(n_{i}-t_{i})$ $\mathit{SU}$s are Byzantine. These $t_{i}$ $\mathit{SU}$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, $\mathit{TrustSAS}$ aims to achieve the following security objectives:

$\bullet$ \SOUL@Private Spectrum Availability Querying: $\mathit{SU}$s can query $\mathit{DB}$s privately, without revealing their operational information.

$\bullet$ \SOUL@Private Spectrum Usage Notification: $\mathit{SU}$s can notify $\mathit{DB}$s about their channel usage and transmission parameters privately, without revealing their operational information.

$\bullet$ \SOUL@Robustness to Failures: All security guarantees are maintained, even when a system entity fails or is compromised.

$\bullet$ \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.

$\bullet$ \SOUL@Anonymity and Membership Verifiability: $\mathit{SU}$s’ authenticity can be verified before the $\mathit{SU}$s are granted system access, and $\mathit{SU}$s cannot be identified at any stage of protocol execution.

$\bullet$ \SOUL@Location Privacy Protection of $\mathit{SU}$s: $\mathit{SU}$s’ physical location information is kept private at all times from all $\mathit{DB}$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**.**

$\mathit{TrustSAS}$* achieves unforgeability and robustness of TBLS signatures against an adversary that can corrupt any $f_{i}<n^{(i)}/2$ $\mathit{SU}$s within a cluster $\mathcal{C}{}^{(i)}$ as long as the Gap-Diffie-Hellman problem is intractable.*

Corollary 2**.**

$\mathit{TrustSAS}$* ensures consistency and resistance to fork attacks for a permissioned blockchain $\mathcal{BC}{}^{(i)}$ running BFT consensus in every $\mathcal{C}{}^{(i)}$ if $t_{i}\geq 2f_{i}+1$, where $t_{i}$ is the number of signature shares required to construct a group signature for $\mathcal{C}{}^{(i)}$, and $f_{i}$ satisfies $n_{i}\geq 3f_{i}+1$ for BFT mechanisms  [22].*

Corollary 3**.**

$\mathit{TrustSAS}$* guarantees unforgeability and robustness of TBLS signatures while ensuring consistency and resistance to fork attacks for $\mathcal{BC}{}^{(i)}$ of $\mathcal{C}{}^{(i)}$ against an adversary that can corrupt any $f_{i}<n^{(i)}/3$.*

Corollary 4**.**

$\mathit{TrustSAS}$* guarantees $\mathit{SU}$s with information-theoretic, private spectrum availability querying from $\mathit{DB}$s.*

Corollary 5**.**

$\mathit{TrustSAS}$* 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**.**

$\mathit{TrustSAS}$* is robust against Byzantine failures of both $\mathit{DB}$s and $\mathit{SU}$s alike.*

Corollary 7**.**

$\mathit{TrustSAS}$* guarantees location privacy information protection to all $\mathit{SU}$s.*

V Performance Evaluation

We assess the effectiveness of $\mathit{TrustSAS}$ 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 $7$ VMs deployed on different Geni sites, each playing the role of a $\mathit{DB}$, 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 $\mathit{SU}$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 $\mathit{SU}$ when running DKG. In terms of communication overhead, DKG requires $2$ rounds of broadcasts, yielding $\mathcal{O}(n_{i})$ messages per $\mathit{SU}$, or $\mathcal{O}(n_{i}^{2})$ messages per cluster $\mathcal{C}{}^{(i)}$, when assuming no faulty $\mathit{SU}$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 $\mathit{SU}$s in $\mathcal{C}{}^{(i)}$. $\mathit{SU}$s repeatedly sign the consensus statement at each BFT round within the cluster. From an $\mathit{SU}$’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, $\mathit{SU}{}_{L}^{(i)}$, will, however, incur most of the overhead, as it needs to verify all the signature shares coming from the $t{}_{i}$ signing $\mathit{SU}$s of $\mathcal{C}{}^{(i)}$, before multiplying them to construct $\mathcal{C}{}^{(i)}$’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 $t{}_{i}$ 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 $\textsc{EPID}{}.\textsc{Sign}$ and $\textsc{EPID}{}.\textsc{Verify}$ analytically and empirically (using Intel’s publicly available SDK [27]) as depicted in Table II. $\textsc{EPID}{}.\textsc{Sign}$ and $\textsc{EPID}{}.\textsc{Verify}$ 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 $\mathit{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 $\mathit{SU}$ 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 $\mathcal{BC}{}$.

V-4 Private Information Retrieval ($\mathit{PIR}$)

We use our Geni testbed to evaluate $\mathit{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 both $\mathit{DB}$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, $n_{i}$, which translates into a total communication overhead of $\mathcal{O}(n_{i}^{2}\log n_{i})$. In this experiment, we also set the throughput between the nodes to $10\;Mbps$ and the propagation delay among $\mathit{SU}$s to $20\;ms$ 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 $\mathit{SU}$s, a consensus is reachable in less than $7\;s$ even if up to $1/3$ of the $\mathit{SU}$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 $\mathit{TrustSAS}$’s algorithms. For instance in Rekeying, BFT will take as long as $76\>s$ since each $\mathit{SU}$ will need to verify the signatures of all other $\mathit{SU}$s in $\mathcal{C}{}^{(i)}$ 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 $\mathit{TrustSAS}$’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 $\mathit{SU}$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 $\mathit{SU}$s to query $\mathit{DB}$s every 24 hours.

VI Conclusion

We propose $\mathit{TrustSAS}$, a trustworthy framework for $\mathit{SAS}$ that preserves $\mathit{SU}$s’ operational privacy while adhering to regulatory requirements mandated by FCC in the 3.5 GHz CBRS band. $\mathit{TrustSAS}$ achieves this by synergizing state-of-the-art cryptographic mechanisms with the blockchain technology. We show the privacy benefits of $\mathit{TrustSAS}$ 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.