Downloads BC Cessful, Then L Proceeds with Querying S for Available 8: SU (I) Run REKEYING( (I)) in Next DB SU (I) S ∈C C Tepoch Channels
Total Page:16
File Type:pdf, Size:1020Kb
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 PU s. GAA users, on the other hand, operate opportunistically, spectrum demand, the Federal Communications Commission in that they need to query the DBs to learn about which 150 3.5 (FCC) has recently opened up MHz in the GHz band spectrum portions are available—not being used by higher tier for shared wireless broadband use. Access and operations in this PU band, aka Citizens Broadband Radio Service (CBRS), will be ( or PAL) users. Even though both PAL and GAA users managed by a dynamic spectrum access system (SAS) to enable are considered as secondary users, in the remaining parts of seamless spectrum sharing between secondary users (SU s) and this paper, for ease of illustration, SU refers to a GAA user, incumbent users. Despite its benefits, SAS ’s design requirements, since only GAA users need to query DBs to learn spectrum SU as set by FCC, present privacy risks to s, merely because availability; PAL users acquire spectrum access via bidding. SU s are required to share sensitive operational information (e.g., location, identity, spectrum usage) with SAS to be able A. Key SAS Requirements to learn about spectrum availability in their vicinity. In this As stipulated by FCC [1], SAS’s capabilities will exceed paper, we propose TrustSAS , a trustworthy framework for SAS that synergizes state-of-the-art cryptographic techniques those of TVWS [4], allowing a more dynamic, responsive with blockchain technology in an innovative way to address these and generally capable support of a diverse set of operational privacy issues while complying with FCC’s regulatory design scenarios and heterogeneous networks [5]. While some of requirements. FCC’s design requirements for SAS, such as the ability We analyze the security of our framework and evaluate its to authenticate users, hold users accountable for rule and performance through analysis, simulation and experimentation. We show that TrustSAS can offer high security guarantees with policy violation, and to protect against unauthorized database reasonable overhead, making it an ideal solution for addressing access and tampering, are similar to TVWS systems, other SU s’ privacy issues in an operational SAS environment. requirements are only specific to SAS, which include [2]: Index Terms—Spectrum access system, Citizens Broadband • Information gathering and retention: SU s must keep Radio Service, spectrum databases, Blockchain, privacy. SAS informed about their current operating parameters and I. INTRODUCTION channel usage information at all time, so that SAS can maintain accurate and up-to-date frequency usage information. He Federal Communications Commission (FCC) con- While this is mandatory in SAS, it is only optional in TVWS. tinues its effort towards promoting dynamic access to T • Coexistence: SAS is required to coordinate the interactions spectrum resources, and has recently promulgated the creation among PAL and GAA users to ensure interference-free coex- of the Citizens Broadband Radio Service (CBRS) in the 3.5 istence among all CBRS users [2], [6]. This is different from GHz band (3550 - 3700 MHz) [1]. This opens up previously TVWS systems, which focus primarily on protecting PU s, protected spectrum, used by the US Navy and other DoD and not on ensuring coexistence among SU s. members, for dynamic and opportunistic spectrum sharing. • Auditability: SAS must maintain audit logs of all system In its CBRS report [1], [2], FCC prescribes the use of a operations [7], including DB write operations, user member- centralized spectrum access system (SAS) to govern CBRS ship status changes, etc. SAS uses these logs to verify and arXiv:1907.03136v1 [cs.NI] 6 Jul 2019 sharing among incumbent and secondary users. Like the case ensure compliance with regulatory rules and policies. of TV white space (TVWS) access, SAS comprises multiple It is then important that these requirements be met when geolocation spectrum databases (DBs), operated (typically) designing SAS. The challenge, however, is that meeting them by different administrators and are required to communi- gives rise to some serious privacy issues, thereby impacting cate amongst themselves to ensure frequency use information the adoption of this promising technology. consistency. Also, like in TVWS, SU s need to query the SAS DBs using their exact location information to be able to learn B. Privacy Issues in about CBRS spectrum opportunities in their vicinity. A subtle privacy concern arises in SAS, which pertains SAS supports three types of users: primary users (PU s), merely to the fact that SU s are required to share sensitive priority access license (PAL) users, and general authorized operational information with DBs in order for them to obtain access (GAA) users. PU s are top/first tier users with the high- spectrum availability information [2]. This information, which est priority, while new CBRS users, considered as secondary may include SU s’ sensitive data, such as their locations, users, operate either at the second tier as PAL users or at the identities, spectrum usage, and transmission parameters, may third tier as GAA users [3]. PAL users are assigned through be collected by an adversary or a malicious SAS administrator competitive auction and have priority over GAA users, but and be exploited for economic, political, or other purposes [8]. they are required to vacate the spectrum upon the return of For instance, fine-grained location information can easily SU Multiple spectrum dataEases Bootstrapping Phase FCC reveal other personal information about s including their 2 ReTuests to Moin TrustSAS behavior, health condition, personal habits or beliefs [9]. DB1 DBN 1 System parameters It may not be acceptable for most users to expose such a 3 Permission granted 0 System setup sensitive information, especially in the presence of malicious Peering with DBs Phase entities that can exploit it for malicious purposes [9]–[11]. 0 /eaders peer with DBs via /eader anonymous authentication Such privacy risks may hinder the wide adoption of this GloEal BlocNchain promising spectrum sharing technology. Calls are starting to arise within the wireless community to raise awareness about Anchor 0 68s peering with other 68s 2 this issue as it is the case with Federated Wireless in their 2 via anonymous authentication Cluster .eying comments to FCC regarding its report and order [2]. Therefore, 1 68s form clusters SU Generation it is necessary to design mechanisms that can protect s’ /ocal BlocNchain Peering Clustering Phase sensitive information while at the same time abiding by FCC’s Fig. 1. TrustSAS Architecture and Initial Operations rules and policies prescribed for SAS. TrustSAS. TrustSAS leverages and relies on the existence C. Contributions and Paper Organization of multiple DBs for spectrum access, each typically run Most of SAS’ rules require SU s to share a great deal of by a different administrator. These DBs are assumed to be their sensitive information, which conflict with SU s’ privacy synchronized and to be sharing the same content, as mandated objectives. As a result, we are facing a dilemma: On one hand, by FCC. Also, TrustSAS supports multiple SU s, including all SAS entities need to comply with SAS’s requirements a set of pre-registered SU s to be deployed specifically for to have a stable, interference-free radio environment. On the playing the role of anchor nodes. These anchor SU s serve to other hand, it is important to offer privacy guarantees to establish a backbone peer-to-peer (p2p) network that can be SU s so as to promote this new spectrum sharing technology. discoverable and joinable by new SU s. This dilemma makes the task of designing SAS mechanisms The content of each DB can be viewed/modelled as an SAS that provide privacy guarantees while complying with ’s r × b matrix D of size η bits, where r is the number of requirements and rules very challenging. records in the database, each of size b bits. Each record in We strongly envision that the public’s (long-term) accep- D is a unique combination of a cell number, representing the tance of the SAS paradigm will greatly depend on the ro- location, a channel number, and other transmission parameters bustness and trustworthiness of SAS vis-a-vis of its ability (e.g., max transmit power, duration, etc). In TrustSAS, each to address these privacy concerns. Therefore, in this work, we record in D contains a smart contract that is to be created propose TrustSAS, a trustworthy SAS design framework that by DBs to define channel usage rules, such as the maximum aims to achieve these two conflicting goals. More specifically, number of SU s allowed to transmit simultaneously in a given TrustSAS combines and synergizes state-of-the art crypto- location, SU ’s maximum transmit power, etc. With these smart graphic techniques with blockchain technology in an inno- contracts, TrustSAS ensures fair sharing of the spectrum vative way to address these privacy issues while complying resources, and limits the interference among SU s, thus sat- with FCC’s regulatory design requirements. To the best of our isfying the coexistence requirement, stated in Section I-A. For knowledge, this work is the first to address such issues within simplicity, we assume that channel usage is permitted over a the context of SAS and CBRS. fixed duration independently from the channel, and that SU s We first provide in Section II a high-level overview of our need to query DBs for an updated channel availability infor- framework to help grasp the big picture. Then, in Section III, mation periodically every Tepoch, where Tepoch is a tunable we provide a detailed description of the framework.