arXiv:1907.03136v1 [cs.NI] 6 Jul 2019 emessetu hrn ewe eodr sr ( users secondary between sharing spectrum seamless ad k iiesBodadRdoSrie(BS,wl be ( will system (CBRS), access spectrum Service dynamic Radio a Broadband by in managed operations Citizens and aka Access use. band, broadband wireless shared for hyaerqie ovct h pcrmuo h eunof return the upon spectrum but the users, vacate GAA through to over assigned required priority are the are users have at they PAL or and [3]. users auction PAL users as competitive GAA tier as second secondary tier the as third at considered either users, operate CBRS users, new while priority, est pcrmdmn,teFdrlCmuiain Commission up Communications opened recently Federal has the (FCC) demand, spectrum roiyacs ies PL sr,adgnrlauthorize general and users, users. (PAL) (GAA) access license access priority SAS olanaotsetu viaiiyi hi iiiy nt In vicinity. their in propose availability we spectrum paper, about learn to esnbeoeha,mkn ta da ouinfraddres for solution ideal an SU it making overhead, reasonable experimenta that and show simulation We analysis, through desig performance regulatory FCC’s with complying t address requirements. while to way issues innovative an privacy in technology blockchain with eg,lcto,iett,setu sg)with usage) spectrum identity, location, (e.g., SU benefits, its Despite users. incumbent ai evc,setu aaae,Bokhi,privacy. Blockchain, databases, spectrum Service, Radio bu BSsetu potnte ntervicinity. their in opportunities spectrum CBRS about DB sstb C,peetpiayrssto risks privacy present FCC, by set as ossec.As,lk nTVWS, communi- in to informatio like use required Also, frequency ensure consistency. are to themselves and amongst cate administrators different ( by databases spectrum geolocation nisCR eot[] 2,FCpecie h s fa access, of case (TVWS) use the space Like white the users. TV secondary prescribes of and FCC incumbent ( among [2], system sharing DoD [1], access sharing. other spectrum report spectrum centralized and CBRS opportunistic Navy its and US In previously dynamic the up for opens by This 3.5 members, used [1]. the MHz) spectrum, in 3700 (CBRS) protected - Service (3550 Radio band Broadband GHz creat Citizens the the promulgated of recently has and resources, spectrum T rsSS rswrh pcrmAcs System Access Spectrum Trustworthy A TrustSAS: Abstract eaayetescrt forfaeokadeaut its evaluate and framework our of security the analyze We ne Terms Index SAS ’piayise na operational an in issues privacy s’ r eurdt hr estv prtoa information operational sensitive share to required are s sn hi xc oainifraint eal olearn to able be to information location exact their using s iusisefr oad rmtn yai cesto access dynamic promoting con- towards effort (FCC) its Commission tinues Communications Federal He htsnrie tt-fteatcytgahctechniqu cryptographic state-of-the-art synergizes that uprstretpso sr:piayues( users primary users: of types three supports A ato t non fot ome h increased the meet to efforts ongoing its of part —As TrustSAS Setu cessse,Ctzn Broadband Citizens system, access —Spectrum TrustSAS PU .I I. a fe ihscrt urneswith guarantees security high offer can r o/rtte sr ihtehigh- the with users tier top/first are s NTRODUCTION o h . H BSBand CBRS GHz 3.5 the for oae Grissa Mohamed rswrh rmwr for framework trustworthy a , 150 DB ⋆ H nthe in MHz SAS rgnSaeUiest,grissam,hamdaoui@oregonstate. University, State Oregon SU SAS SAS SAS ) prtd(typically) operated s), ‡ sdsg requirements, design ’s edt ur the query to need s nvriyo ot lrd,[email protected] Florida, South of University SU environment. opie multiple comprises ogvr CBRS govern to ) ,mrl because merely s, SAS SAS 3 ⋆ . 5 tiaA Yavuz A. Attila , oenable to ) ob able be to H band GHz SU PU )and s) tion. hese sing this ion his s), es n d n o ntne n-rie oainifraincneasily can information location fine-grained purposes other instance, or political, For economic, for exploited be and with information operational ecletdb navrayo malicious a or adversary an parameters, by transmission collected be and usage, spectrum identities, include information, may This [2]. information availability spectrum eeyt h atthat fact the to merely viaiiy A sr cur pcrmacs i biddin via Key access A. spectrum query acquire to users need PAL availability; users GAA only since .PiayIse in Issues impactin Privacy technology. thereby B. promising issues, this privacy of serious adoption some the to rise gives designing policies. and rules regulatory with compliance ensure hpsau hne,etc. changes, status ship including [7], operations • ti higher the by used query ( being available—not to are need portions spectrum they that in PU cesadtmeig r iia oTW ytm,other systems, TVWS to • to specific and similar only are rule are requirements data for tampering, unauthorized against and accountable protect access users to and hold violation, of policy users, some for authenticate While to requirements operationa [5]. of design responsive networks set FCC’s dynamic, heterogeneous diverse a more and of a scenarios support allowing capable generally [4], and TVWS of those of parts illustration, remaining of the ease in for users, paper, this secondary as considered are n o nesrn oxsec among coexistence ensuring on not and • in mandatory is informat this usage While frequency up-to-date and accurate maintain VSsses hc ou rmrl nprotecting on from primarily different is focus This which [6]. [2], systems, coex- users TVWS interference-free CBRS ensure all to among users istence GAA and PAL among hne sg nomto taltm,s that so time, all at information usage channel SAS PU Coexistence Auditability utepiaycnenaie in arises concern privacy subtle A ssiuae yFC[1], FCC by stipulated As ti hnipratta hs eurmnsb e when met be requirements these that important then is It nomto ahrn n retention and gathering Information .GAues nteohrhn,oeaeopportunistically, operate hand, other the on users, GAA s. ‡ n ehrHamdaoui Bechir and , rPL sr.Ee huhbt A n A users GAA and PAL both though Even users. PAL) or nomdaottercretoeaigprmtr and parameters operating current their about informed SAS SAS SU Requirements : : h hleg,hwvr sta etn them meeting that is however, challenge, The . SAS SAS ’sniiedt,sc sterlocations, their as such data, sensitive s’ SAS srqie ocodnt h interactions the coordinate to required is utmiti ui oso l system all of logs audit maintain must edu SU DB SAS SAS r eurdt hr sensitive share to required are s DB rt prtos srmember- user operations, write SAS ⋆ ssteelg ovrf and verify to logs these uses ti nyotoa nTVWS. in optional only is it , nodrfrte oobtain to them for order in s DB SAS SAS SU scpblte ilexceed will capabilities ’s olanaotwhich about learn to s DB hc nld [2]: include which , uha h ability the as such , eest A user, GAA a to refers SAS SU olanspectrum learn to s SAS : s. hc pertains which , SU administrator utkeep must s SAS which PU base may ion. [8]. can g. er s, g l SU Multiple spectrum databases Bootstrapping Phase FCC reveal other personal information about s including their 2 Requests to join TrustSAS behavior, health condition, personal habits or beliefs [9]. DB1 DBk 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 Leaders peer with DBs via Leader anonymous authentication Such privacy risks may hinder the wide adoption of this Global Blockchain promising spectrum sharing technology. Calls are starting to arise within the wireless community to raise awareness about Anchor 0 SUs peering with other SUs 2 this issue as it is the case with Federated Wireless in their 2 via anonymous authentication Cluster Keying comments to FCC regarding its report and order [2]. Therefore, 1 SUs form clusters SU Generation it is necessary to design mechanisms that can protect s’ Local Blockchain 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. The system design parameter. The geographical area serviced by security analysis and performance evaluation are provided in TrustSAS is modeled as a grid of N ×N cells of equal sizes, Sections IV and V, and the paper is concluded in Section VI. and an SU ’s location is expressed through the grid’s cell index. II. SYSTEM AND FRAMEWORK OVERVIEW B. TrustSAS Initial Setup In this section, we present the system architecture and provide a high-level overview of TrustSAS. Fig. 1 can be The first phase needed for setting up TrustSAS is bootstrap- referred to throughout this section to facilitate the description. ping (see Fig. 1), during which FCC creates the system param- eters and keys, specific to TrustSAS, and shares them with A. Architectural Components DBs. Also, SU s first need to register and request SAS access As illustrated in Fig. 1, TrustSAS comprises three main privileges from FCC before they can join TrustSAS. Once architectural entities: FCC, multiple DBs, and multiple SU s. registered, FCC provides the joining SU with the anchor Without loss of generality, throughout the paper, we use FCC SU list, membership keys, and the procedure necessary for to refer to FCC itself, or to any trusted third-party entity the SU to authenticate with and join TrustSAS. Note that, that is appointed by FCC to act on its behalf. In TrustSAS, in TrustSAS, all messages communicated between the SU s FCC is responsible for enforcing compliance with regulatory and the DBs are established over secure channels, so as to requirements, providing system keying materials, handling the ensure that the spectrum queries are authenticated, private, and registration of SU s, and granting them permissions to join not tampered with. Secure channels will be established via traditional mechanisms, and such mechanisms are ignored in members, as well as about other information, such as aggregate this framework to keep the focus on the other security aspects. transmit power on each used channel, duration of channel use, This phase is detailed in Section III-A1. etc., as required by FCC. TrustSAS uses this information to The second setup phase consists of establishing the un- build knowledge of the spectral environment and to maintain derlying network infrastructure. Registered SU s that join an accurate availability information to comply with the in- TrustSAS will maintain communication with one an- formation gathering and retention requirement. As we discuss other via an overlay p2p network, and a newly joining in more details in Section III, TrustSAS ensures that cluster SU will rely on anchor SU s to discover and join the p2p leaders report an accurate and non-altered spectrum usage network.TrustSAS relies on an anonymous digital signature information that is easily verifiable. Other leaders and DBs technique, explained in Section III-A, to enable all these will distributively reach an agreement about the validity of this SU s to anonymously authenticate and verify each other’s information, which, if valid, will be updated to DBs’ records. legitimacy when peering with one another. This anonymous Detailed description of this is provided in Section III-D. authentication will also enable SU s to enjoy system services TrustSAS anonymously, yet in a verifiable way, to break the link between III. THE PROPOSED FRAMEWORK: their sensitive operational data and their true identities. TrustSAS relies on permissioned blockchains [13] to keep TrustSAS adopts a clustering approach, where joined SU s track of system and cluster activities. Blockchains are also group themselves into clusters and elect cluster leaders, with used as a platform to handle agreements between entities at the leaders being responsible for representing their SU s for in- both the cluster and system levels. This is achieved thanks to teracting with other system entities. Not only will this improve permissioned blockchains’ underlying Byzantine fault tolerant TrustSAS scalability, but also protect SU s’ privacy, as it will (BFT) consensus mechanism [13], which enables participants limit the interaction with DBs to only cluster leaders. Once to reach agreements on block updates even when Byzantine clusters are established, SU s within each cluster distributively nodes are present. Throughout the description of TrustSAS, and collaboratively generate their cluster-specific keys, which before an entity submits and adds a block to a blockchain, will be used later for blockchain related operations inside the we assume that the block is first signed by the entity and then cluster and for signing cluster-wise spectrum agreements. This validated via BFT by the validators of the blockchain. We now phase is detailed in Section III-A2. describe the different algorithmic components of TrustSAS. Once clusters are formed, the last setup phase is for the leaders to anonymously authenticate with DBs, and upon A. System Setup successful authentication, these DBs will join and be part The first component of TrustSAS, depicted in Alg. 1, of the established p2p network. This way, DBs will not be consists of setting up the system parameters and the required involved in the initial clustering of SU s, and therefore they keys at initialization, which is done in three phases. will not be able to infer the SU s’ location information. This 1) Bootstrapping Phase (Alg. 1, steps 2-10): TrustSAS en- phase is detailed in Section III-A3. sures that SU s activities are anonymous, yet verifiable, by leveraging Intel’s anonymous digital signature, known as en- TrustSAS C. Main Operations hanced privacy ID (EPID) [14]. EPID allows any SU to prove 1) Querying Spectrum Availability Information: Each clus- its membership legitimacy to other TrustSAS entities, without ter leader acts on behalf of its SU members and privately revealing its true identity, using zero-knowledge proof [15]. queries DBs for spectrum availability information. Even EPID also enables access revocation of misbehaving SU s though the true identities of all SU s, including leaders, are anonymously, by maintaining and using a revocation list hidden in TrustSAS, this is not sufficient to preserve their L based on SU s’ signatures. EPID typically runs four pro- operational privacy. In fact, since each record in DBs is asso- cedures. The first, EPID.SETUP, is run by the FCC as the ciated with a unique location, DBs may infer the location of first step of the Bootstrapping phase (step 2, Alg. 1) and the leaders from their queries and can still use this information outputs two system keys: Membership Verification Public Key for tracking purposes. To prevent this, TrustSAS protects the (Kpk) and Membership Issuing Secret Key (Ksk). The first leaders’ queries through the adoption of multi-server private key, Kpk, is shared among all entities of TrustSAS, and used information retrieval (PIR) protocol [12], which enables a user by SU s and DBs to anonymously verify the membership to retrieve a record from multiple databases while preventing legitimacy of another SU . The second key, Ksk, is kept the databases from learning any information about the record secret and used only by FCC to create a unique Membership or the user requesting it. After learning the spectrum avail- Private Key, sk SU , for each joining SU , a key that the ability information, members of each cluster will distributively SU uses to prove its membership legitimacy to the other reach an agreement on how the spectrum resources are to be system members anonymously. We iterate again that FCC will shared among them. Detailed description of this operation is be used throughout to refer to either FCC itself or any third- provided in Section III-C. party entity that is appointed by FCC to govern on its behalf. 2) Notifying about Spectrum Usage: Once a spectrum The second procedure, EPID.JOIN, is run interactively assignment agreement is reached, the cluster leader will notify between each joining SU and FCC, and takes as input Kpk and the DBs about the spectrum portions used by its cluster FCC’s public key KFCC , as illustrated in steps 4 and 9 of Alg. 1. It results in SU obtaining Kpk and sk SU . The third public key, Kpk, by checking that SU ’s signature is not in L. procedure, EPID.SIGN, allows an SU to anonymously prove TrustSAS also requires that some SU s be appointed its membership legitimacy and that it does not belong to the to serve as anchor nodes. These SU s need to run the revocation list (i.e., its signature over a challenge message, m, TWOWAYEPID subroutine (Alg. 1, step 1) among themselves does not belong to L). Note that EPID signatures produced to authenticate each other anonymously before they peer up by the same SU are linkable; this prevents any malicious and initiate the overlay p2p network. Later on, every joining SU from forging multiple signatures on behalf of other SU s. SU , that obtained its sk SU through EPID.JOIN, will also get To validate the EPID signature of joining SU , a verifier uses the list of anchor nodes, denoted by A throughout, from FCC. the fourth procedure, EPID.VERIFY, using the membership 2) Joining and Clustering Phase (Alg. 1, steps 11-16): Algorithm 1 TrustSAS setup Every joining SU uses the list A to discover and join the on- going p2p network. The joining SU then needs to authenticate 1: function WO AY T W EPID(A, B, Kpk , L) with its peers and verify their legitimacy via TWOWAYEPID User A sends a challenge mA to user B (Alg. 1, step 1). After enough SU s have joined TrustSAS, User B sends a challenge mB to user A these SU s will form clusters based on their locations; this Σ sk A:( A, PA) ←EPID.SIGN( A, Kpk,mB, L ) may require the SU s to expose their locations to other SU s, Σ B: vA ←EPID.VERIFY(Kpk,mB, A, PA, L ) but it should be no issue at this point since DBs are not part Σ sk B:( B , PB) ←EPID.SIGN( B, Kpk,mA, L ) of the p2p network yet. The members of each C(i) will also Σ A: vB ←EPID.VERIFY(Kpk,mA, B , PB, L ) maintain a cluster (local) blockchain, BC(i), to log and keep return vA ∧ vB track of key events taking place in the cluster. Bootstrapping phase TrustSAS requires SU s of each cluster to serve as wit- nesses with respect to any cluster-related statement that is 2: FCC: (Kpk, Ksk) ← EPID.SETUP(κ) ⊲ κ: security level shared by the leader with the system. This is to prevent the DB 3: FCC shares Kpk with s leader from maliciously reporting incorrect information that sk SU 4: ( SU , Kpk)←EPID.JOIN(Kpk ,KFCC ) ∀ ∈ A was not validated by members of the cluster. To ensure this, SU 5: for k ∈ A do TrustSAS adopts the robust (t,n)-threshold BLS (TBLS) SU 6: for l ∈A\{k} do signature scheme [16]. TBLS requires no more than (any) 7: TWOWAYEPID(k,l) (i) ti + 1 of the ni SU s in C to collaboratively create a 8: All SU s ∈ A peer up with each other cluster signature over a statement. For this, members of each SU sk (i) 9: Joining : ( SU , Kpk) ← EPID.JOIN(Kpk , KFCC ) C will have to run the REKEYING operation described in SU (i) 10: FCC shares A with joining Alg 2, among the ni SU s of C , to jointly generate the keys Peering and clustering phase required for performing such distributed (ti,ni)-TBLS sig- natures within C(i). This is achieved by running TBLS’s 11: SU joins and discovers the p2p network through A distributed key generation (DKG) [17] operation which will 12: SU runs TWOWAYEPID() with each peer result in each SU j in C(i) obtaining three keys: Cluster Public SU (i) (i) (i) 13: s of the overlay network form clusters {C }1≤i≤nC Key, y , which is shared among all SU s in C , Cluster User (i) (i) (i) (i) x(i) 14: SU s ∈C elect a leader SU , ∀ 1 ≤ i ≤ nC j L Secret Key, xj , and Cluster User Public Key, zj = g . 15: SU s ∈C(i) maintain a local blockchain BC(i) (i) (i) (i) (i) The Cluster User Secret Keys (x1 , ··· , xni ) are a (ti,ni)- 16: SU s ∈C run steps 2-6 of REKEYING(C ) (Alg. 2) (i) (i) threshold secret sharing of the private key x = logg y . Peering with DBs These shares are constructed using Shamir secret sharing [18] such that any subset of t + 1 SU s from C(i) can recover DB i 17: s form validators set V x(i) using Lagrange interpolation. Cluster User Public Keys 18: Global blockchain BC is created with validators ∈V represent SU s’ pseudonyms within C(i) and are also used to DB 19: s ∈V and FCC maintain full copy of BC identify SU s’ transactions in the local blockchain, BC(i). In 20: for i =1, ··· ,nC do addition to DKG, TBLS comprises four other operations: SU (i) DB 21: L authenticates with s using EPID (i) • SIGNSHAREGEN: It enables each SU j to compute the 22: SU peers up with DBs and becomes a validator L signature share (i) over a message to be signed by (i). SU (i) (i) σj m C 23: L submits y to BC (i) (i) • SIGNSHAREVERIF: It enables members of C to verify 24: SU (i) DB L requests a beacon β from a SU (i) (i) (i) j’s signature share σj against its public key zj . 25: DB sends an EPID challenge m to SU L • SIGNRECONSTRUCT: The leader of a cluster collects a set (i) 26: SU :(Σ EPID.SIGN(sk ) L L, PL)← L, Kpk, m, L of ti + 1 signature shares of a message m, Hi, verified 27: DB verifies (Σ with EPID.VERIFY() L, PL) using SIGNSHAREVERIF, from ti + 1 SU s. It combines DB (i) SU (i) 28: issues β to L and submits it to BC these shares using Lagrange interpolation, via the Lagrange SU (i) SU (i) (i) 29: L selects s ∈C into R coefficients that were calculated in DKG, and reconstructs (i) 30: Every Tβ, SU s ∈ R transmit βi for a duration d the complete cluster signature. • GROUPSIGNVERIF: Used to verify the cluster-generated signature against C(i)’s public key y(i). In TrustSAS, an operational cluster is required to transmit Note that TBLS does not require reconstructing x(i) during a beacon for a certain duration, every Tβ period, so that the SU the signing process. Even after repeated signing, no SU could cluster could be discovered by nearby joining s, as in [20]. learn any information about x(i) that would enable it to create Tβ is a system design parameter that could be adjusted based SU signatures without t other SU s [19]. We refer the reader on system dynamics and on how frequent s join the system. i SU (i) to [16] for more details about TBLS. A leader L needs to request this beacon from one of the DBs and can acquire it only if it successfully proves its legitimacy to DB through EPID as depicted in steps 24-28 Algorithm 2 Rekeying within (i) C of Alg.1. This is achieved by creating an EPID signature of 1: procedure REKEYING(C(i)) a challenge message m that DB has created for this purpose. (i) (i) (i) (i) (i) 2: {y , x1 , ··· , xni ,z1 , ··· ,zni } ←TBLS.DKG(I) If the EPID signature is successfully verified, DB issues a 3: for SU j ∈C(i) do SU (i) beacon to L and submits the beacon to BC so that it (i) (i) 4: (Σ j , Pj )← EPID.SIGN(sk j , Kpk,z , L ) TrustSAS SU j is accessible by all entities. L picks some (i) Σ (i) 5: ̺j ← TBLS.SIGNSHAREGEN(xj , j , Pj ) representatives from C to transmit the beacon every Tβ, for SU Σ (i) SU (i) a specific duration over a system control channel that is known 6: j sends tuple (̺j , j , Pj ,zj ) to L (i) (i) (i) a priori and is assumed to be reserved for this purpose. 7: SU submits {(̺ , Σ , P ,z )} (i) to BC L j j j j j∈C Note that SU s in C(i) only need to have a light copy of SU (i) (i) 8: L submits y to BC BC containing the latest state of the system including the current number of clusters and their corresponding beacons. DB To handle system-wise access revocations, TrustSAS re- Note also that a secure session is maintained between s (i) quires that each SU ’s Cluster User Public Key is associated and the leader of C as long as EPID revocation list is with its EPID signature over some statement that is known not updated. This is to avoid running the EPID verification SU (i) by all cluster members. To achieve this, each SU j signs its protocol for every block or transaction submitted by L . (i) SU Cluster User Public Key zj itself, which is known to all s B. Joining TrustSAS in the cluster, using EPID.SIGN with its EPID Membership As depicted in Alg. 3, when an SU desires to join sk Private Key, j (Alg 2, step 4). This serves to create a TrustSAS, it needs to tune to the control channel and scans SU cryptographic binding between ’s EPID signature and its it to detect any beacons transmitted by any nearby cluster. Cluster User Public Key. This binding will then have to be Failure to detect any beacons means that either no cluster is submitted as a transaction to be included in (i). This is done BC nearby or all nearby clusters are not accepting new SU s. In by making SU sign the binding from the previous step using SU (i) either case, will start a new cluster and will request a TBLS.SIGNSHAREGEN with its Cluster User Secret Key, xj beacon from one of the DBs and will itself start accepting SU (Alg 2, step 5). Then each will send the signatures, new members, as described in Alg. 1. SU (i) obtained in steps 4 and 5 of Alg 2, to the leader L , which When the new SU detects a beacon, it invokes the (i) will collect all these signatures and include them in BC . TWOWAYEPID procedure with the cluster leader to ensure SU Later, when an j is detected to be malicious, the leader that the SU is legitimate and can be allowed to join the cluster, SU (i) will add ’s Cluster User Public Key zj along with its and that the leader is also in a good standing. If the two- EPID signature to the revocation list L. way verification is successful, the new SU is admitted to the 3) Peering with DBs Phase (Alg. 1, steps 17-30): Each cluster and will immediately request BC(i) from the cluster cluster leader will anonymously authenticate with DBs using leader and peer with the SU s in the cluster. Newly admitted DB DB EPID. Once a leader is authenticated by the s, these s SU s will have to wait until the next Tepoch period to be able join the established p2p network. to participate in the cluster and enjoy spectrum resources. During this phase, a global blockchain BC is also created Note that the admission of a new SU to a cluster is also to keep track of the key system-wise events. Only DBs and subject to interference constraints. Members of the cluster cluster leaders can participate in the validation and addition of must ensure that the entry of this new SU does not lead blocks to BC. To submit a cluster-related block for inclusion in to an aggregate interference that is harmful to higher tier BC, the leaders will need to have a key that identifies them and users or to other SU s in the cluster to satisfy coexistence. their clusters but also could be used to verify the correctness This could be resolved by adjusting grants and transmission of the submitted block. This is exactly why each leader is parameters of the other SU s in the cluster, or simply denying required to submit its Cluster Public Key, y(i), to BC to be the entry of a new SU to the cluster in the extreme case. These shared with DBs and other leaders. On top of that, the leader scenarios could be enforced by the cluster leader and agreed (i) will also share a (ti,ni)-TBLS signature of y to show that upon through consensus among members of the cluster. the Cluster Public Key was actually generated in collaboration Clusters will also need to perform rekeying operation when with members of the cluster using TBLS.DKG. The validators new SU s are added to their clusters, and this takes place at will validate the TBLS signature through a round of BFT the end of each Tepoch period, where again Tepoch is a system consensus by verifying the signature against y(i). design parameter that could be adjusted. Clusters could also Algorithm 3 Join C(i) this requirement by providing τ EPID signatures created by 1: SU scans control channel for beacons in B different legitimate SU s over a challenge message m that 2: if a beacon β(i) of C(i) is found then DBs created for this purpose; this is depicted in steps 2-5 SU (i) SU (i) 3: requests to join C of Alg. 4. Note that EPID prevents L from forging these SU SU (i) signatures without being detected. Also, TrustSAS will not 4: v ←TWOWAYEPID( , L ) τ 5: if v == True then require these τ EPID signatures later unless a change in the (i) 6: SU is added to C(i) membership of C takes place. If this verification is suc- SU SU (i) (i) SU (i) DB 7: peers with s in C and 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. Otherwise, s will label L as malicious and 9: else add it to the revocation list, L. To ensure robustness against a SU (i) SU (i) leader’s failures, a timeout period could be considered beyond 10: forms new C and becomes a leader L (i) SU 11: SU requests β(i) as in Steps 24-30 of Alg. 1 which if the members do not receive spectrum availability L information from their leader, the leader would be labeled as choose to perform rekeying when malicious and/or faulty SU s malicious and added to the revocation list, L, and a new leader are detected. The rekeying steps are shown in Alg. 2. will be elected. The REKEYING procedure is then run among the cluster members, and the new leader will request a new C. Querying for Spectrum Availability beacon for the cluster as in steps 24-30 of Alg.1. We now focus on describing the different steps required 2) Spectrum querying: To enable private querying of DBs, to privately query DBs for spectrum availability in a specific TrustSAS adopts multi-server private information retrieval cluster. These steps are also summarized in Alg. 4. (PIR) protocol [21], termed BATCHPIR, which leverages the DB SAS Algorithm 4 Private Spectrum Query multiple s, inherently available by design, to enable (i) the cluster leaders to efficiently retrieve data records from 1: SU DB L expresses interest to query s DBs while preventing DBs from learning anything about the DB SU (i) 2: s send an EPID challenge m to L records being retrieved. It guarantees information-theoretic pri- SU (i) sk 3: L : EPID.SIGN( L, Kpk, m, L ) vacy, i.e. privacy against computationally unbounded servers, SU (i) SU 4: L requests other τ − 1 s to EPID.SIGN m to cluster leaders as long as the spectrum database content, SU (i) DB D, is replicated among ℓ ≥ 2 non-colluding DBs [12]. 5: L sends τ EPID signatures of m to s 6: DBs verify the τ signatures with EPID.VERIFY() The main idea consists of decomposing each leader’s query 7: if any signature is not valid then into several sub-queries each processed by a different DB to DB SU (i) prevent leaking any information about the queried record. 8: adds L to L; break SU (i) SU (i) BatchPIR also supports batching of the queries, i.e. retrieving 9: if s ∈C experience timeout from L then (i) (i)∗ multiple blocks simultaneously, which is a desirable feature for 10: SU s ∈C(i) \{SU } elect new leader SU L L TrustSAS. It takes as input the list of DBs, the maximum SU (i) SU (i) 11: s ∈C \{ L } run REKEYING() allowed number of colluding servers, the dimensions of D, SU (i)∗ (i) 12: L requests β as in steps 24-30 of Alg. 1 and the indices of records of interest. For this, we assume that SU (i)∗ SU (i) SU (i) 13: L adds L to L and becomes L leaders can learn the index of the records of interest through 14: go to Step 1 an inverted index mechanism agreed upon with DBs. (i) (i) 15: SU : Dq ← BATCHPIR(DBs, ℓ, t, r, s, q) SU SU L A cluster leader, L , collects queries from the s in SU (i) D (i) (i) 16: L submits q as block Bepoch to BC its cluster C , batches them together, and invokes BATCHPIR 17: SU (i) DB SU (i) s ∈C run BFT consensus to validate Bepoch with its peered s. L then submits the query response, SU (i) D (i) SU (i) 18: L triggers smart contracts to divide resources q, as a block Bepoch for inclusion in BC . s in C run (i) 19: SU s ∈C are assigned channels for current Tepoch BFT consensus to validate this Bepoch by simply verifying the digitally signed database records against the public key of In TrustSAS, the cluster leaders will be in charge of DBs. This is to prevent the leader from maliciously sharing querying DBs for spectrum availability on behalf of their altered availability information. SU members, and a leader will query DBs only when: (i) Each record in DBs contains a smart contract that defines Period allocated for using some channel(s) expires, (ii) quality its usage rules. Once Bepoch is validated by SU s and added to of currently assigned channels degrades, or (iii) currently used BC(i), the scripts of the included smart contracts will reside in PU (i) SU (i) channels need to be vacated (e.g., when requested by s). BC . L will issue a transaction to trigger the execution 1) Authentication and permission: In TrustSAS, in order of these smart contracts, which will take as input the list for a leader to query DBs, its cluster is required to have a of SU s in the cluster, their cell indices, and the spectrum minimum of τ SU s, where τ is a system parameter that could availability information. All this information is already stored be tuned depending on the desired robustness and security in BC(i) and is accessible by all SU s in C(i). Once triggered, levels within each cluster. Therefore, before querying the DBs, these smart contracts run independently and automatically in SU (i) (i) SU a cluster leader, L , needs to show that its cluster C meets a prescribed and deterministic fashion on every ’s copy of BC(i), in accordance with the data that was enclosed in the 2) Security Objectives: Given the above threat model, triggering transaction. The execution of these smart contracts TrustSAS aims to achieve the following security objectives: will result in the automatic assignment of spectrum resources • Priiiiivvvvvaaaaattttteeeee SSSSSpppppeeeeeccccctttttruuuuummmmm Avvvvvaaaaaiiiiilllllaaaaabbbbbiiiiillllliiiiitttttyyyyy QQQQQuuuuueeeeeryyyyyiiiiinnnnnggggg::::: SU s can query in a way that follows TrustSAS’s guidelines while ensuring DBs privately, without revealing their operational information. coexistence between SU s. This assignment will be valid for • Priiiiivvvvvaaaaattttteeeee SSSSSpppppeeeeeccccctttttruuuuummmmm UUUUUsssssaaaaagggggeeeee NNNNNoooootttttiiiiifffffiiiiicccccaaaaatttttiiiiiooooonnnnn::::: SU s can notify DBs the duration of the Tepoch period. about their channel usage and transmission parameters pri- D. Notifying about Spectrum Usage vately, without revealing their operational information. • Rooooobbbbbuuuuussssstttttnnnnneeeeessssssssss tttttooooo Faaaaaiiiiillllluuuuureeeeesssss::::: All security guarantees are main- Algorithm 5 Spectrum Usage Notification tained, even when a system entity fails or is compromised. (i) • Immmmmmmmmmuuuuutttttaaaaabbbbbllllleeeee Puuuuubbbbbllllliiiiiccccc Loooooggggg fffffooooor Auuuuudddddiiiiitttttaaaaabbbbbiiiiillllliiiiitttttyyyyy::::: A globally consis- 1: SU L constructs block Bi with usage information tent, tamper-resistant log is maintained, where each system SU (i) SU (i) 2: L sends Bi to s in C for validation and signing event, once produced and logged, cannot be altered or deleted. 3: IGN ECONSTRUCT (Bi, σBi )←TBLS.S R (Hi,L1, ··· ,Ln) • Annnnnooooonnnnnyyyyymmmmmiiiiitttttyyyyy aaaaannnnnddddd Meeeeemmmmmbbbbbeeeeerssssshhhhhiiiiippppp VVVVVeeeeeriiiiifffffiiiiiaaaaabbbbbiiiiillllliiiiitttttyyyyy::::: SU s’ authenticity SU (i) 4: L submits (Bi, σBi ) to BC can be verified before the SU s are granted system access, and (i) 5: V:val←TBLS.GROUPSIGNVERIF(Bi, σBi ,y ) w/ BFT SU s cannot be identified at any stage of protocol execution. 6: if val == True then • Looooocccccaaaaatttttiiiiiooooonnnnn Priiiiivvvvvaaaaacccccyyyyy Prooooottttteeeeeccccctttttiiiiiooooonnnnn ooooofffff SUsssss::::: SU s’ physical loca- 7: Bi is added to BC tion information is kept private at all times from all DBs. 8: DBs update their records 3) Security Results: All proofs of the security results stated 9: else in this section are omitted here due to space limitation, and DB SU (i) 10: s flag L as malicious can be provided if and when requested. (i) 11: SU is added to revocation list L in BC L Corollary 1. TrustSAS achieves unforgeability and robust- 12: DBs remove β(i) from list of valid beacons on BC ness of TBLS signatures against an adversary that can corrupt any f < n(i)/2 SU s within a cluster C(i) as long SU i Once spectrum resources are allocated among s, the as the Gap-Diffie-Hellman problem is intractable. leader SU (i) shares with the DBs the allocation information, L TrustSAS including the channels to be used by the members of C(i), the Corollary 2. ensures consistency and resistance to (i) locations where these channels will be used, and aggregated fork attacks for a permissioned blockchain BC running BFT (i) transmit power over those chosen channels. The leader can consensus in every C if ti ≥ 2fi +1, where ti is the number also collect the received signal strengths in the used and of signature shares required to construct a group signature for (i) adjacent frequencies, the received packet error rates, and other C , and fi satisfies ni ≥ 3fi +1 for BFT mechanisms [22]. standard interference metrics for all SU s in the cluster. The Corollary 3. TrustSAS guarantees unforgeability and ro- leader will propose a block Bi containing this information to bustness of TBLS signatures while ensuring consistency and the members of the cluster for validation. They will verify the resistance to fork attacks for BC(i) of C(i) against an adversary (i) correctness of this information and sign the block using TBLS. that can corrupt any fi
0 0 0 TABLE I 0 50 100 0 50 100 0 1000 2000 3000 i TBLS OVERHEAD WITHIN CLUSTER C( ) (a) DB PIR delay. (b) SU PIR delay. (c) GoSig BFT delay. Operation Analytic Cost Empirical Cost Fig. 2. Overhead of PIR and GoSig DKG Computation O(ni) · PM 1.05 s become quite expensive for both signers and verifiers if such DKG Communication O(ni) messages ∝ 1000 messages a list becomes large. One possible way to maintain a good SIGNSHAREGEN 1 Hash + 1 Expp 0.63 ms performance of TrustSAS is to impose a threshold on the SIGNSHAREVERIF 2ti · TPO 2.3 ms list size. In this case, when the list size exceeds the threshold, Signature size 64 bytes 64 bytes Private key size 32 bytes 32 bytes FCC can create a new group and perform a rekeying operation, SIGNRECONSTRUCT ti · (Mulpp + Expp) 461 ms with each SU needing to prove to FCC that it is a legitimate GROUPSIGNVERIF 2 · TPO 2.3 ms member and that its membership was not revoked. This would be more efficient than carrying a large revocation list indefi- Variables: P M: cost of an elliptic curve point multiplication. ni = 1000 SU s, ti = 1000 SU s. T P O is the cost of one tate pairing. Expp and Mulpp are the nitely and run expensive zero-knowledge proof operations on cost of a modular exponentiation and multiplication, respectively, over modulus p. it. The old list will still be accessible for auditing purposes as it would have been stored already in BC. 2) Threshold Signature (TBLS): Table I provides the an- 4) Private Information Retrieval (PIR): We use our Geni alytical and empirical cost of the different TBLS operations testbed to evaluate TrustSAS’s multi-server PIR, BatchPIR. executed by SU s in C(i). SU s repeatedly sign the consensus As the obtained results in Figs. 2a and 2b show, the support statement at each BFT round within the cluster. From an of query batching by BatchPIR, which allows multiple blocks SU ’s perspective, this is relatively fast, as it involves signing to be retrieved simultaneously, reduces the overhead at both a single message whose cost is dominated by a modular DBs’ and cluster leaders’ sides. We summarize the obtained exponentiation operation, as shown in Table I. The leader, SU (i) results and the analytic estimation of the overhead in Table III. L , will, however, incur most of the overhead, as it needs to verify all the signature shares coming from the ti signing TABLE III SU s of C(i), before multiplying them to construct C(i)’s MULTI-SERVER PIR OVERHEAD signature. These are the most expensive operations involved Operation Analytical Cost Empirical Cost in TBLS as they require a number of modular multiplications Leader SU ’s query q ·O(ℓ2r) · addF 4.86 s . 8 and exponentiations that is linear in ti as illustrated in Table I. DB q0 8 addF mulF rs . s processing · ( 3 + ) · 2 66 To estimate the running time of TBLS’s different operations, Communication q · (r + s) 25 MB we use dfinity’s implementation of TBLS [26]. Variables: ℓ = 7: number of DBs, q = 25: number of batched PIR queries. 3) Enhanced Privacy ID (EPID): We evaluate EPID.SIGN DB size is η = 560 MB, s: number of field F elements per row, addF and mulF and EPID.VERIFY analytically and empirically (using In- denote the cost of an F addition and an F multiplication. In a field F of characteristic tel’s publicly available SDK [27]) as depicted in Table II. 2, additions are equivalent to XOR and multiplications are equivalent to AND. EPID.SIGN and EPID.VERIFY both require a number of 5) BFT Consensus: Table V shows that the communication modular exponentiations that is linear in the size of the revo- overhead of BFT expressed in terms of number of messages cations sublists; these revocation sublists are defined in [14]. sent every consensus round is quasi-linear in the size of Even though these delays seem relatively high, they are still the cluster, ni, which translates into a total communication 2 reasonable, especially that these membership proof operations overhead of O(ni log ni). In this experiment, we also set the are independent, unfrequent, and do not occur simultaneously, throughput between the nodes to 10 Mbps and the propagation once the system setup completes. Note that this proof has delay among SU s to 20 ms and simulate the protocol to a linear cost in the size of the revocation list and could estimate the time it takes to reach a consensus over a block. TABLE IV END-TO-END DELAY OF TrustSAS ALGORITHMS
Algorithm Major Operations Total Cost i Alg. 2 Rekeying within C( ) DKG+ TBLS.SIGNSHAREGEN + EPID.SIGN + BFT(ni) 77.47 s i Alg. 3: Join C( ) TWOWAYEPID+ REKEYING 78.12 s Alg. 4: Private Spec. Query EPID.SIGN + τ EPID.VERIFY + BATCHPIR+ BFT(ni) 13.15 s Alg. 5: Spec. Usage Notifica. t(TBLS.SIGNSHAREGEN+TBLS.SIGNSHAREVERIF)+TBLS.SIGNRECONSTRUCT+BFT(ℓ+nc) 1.85 s
6 Parameters: ni = 1000, t = ni/2, nc = 50 ℓ = 7, τ = 10, bandwidth = 10Mbps, η = 560MB, r = 10 . BFT(x): one round of BFT among x parties. TABLE V BFT COMPLEXITY [2] ——, “Order on reconsideration and second report and order, number 16-55, gn docket no. 12-354. FCC,” May 2016. Operation Analytical Cost Empirical Cost [3] Y. Ye, D. Wu, Z. Shu, and Y. Qian, “Overview of lte spectrum sharing technologies,” IEEE Access, vol. 4, pp. 8105–8115, 2016. Communication per user O(ni log ni) ∝ 3000 messages [4] V. Chen, S. Das, L. Zhu, J. Malyar, and P. McCann, “Protocol to access 2 Consensus w/o failures O(ni log ni) 4.3 s white-space (paws) databases,” Tech. Rep., 2015. 2 Consensus w/ failures O(ni log ni) 6.32 s [5] M. A. Clark and K. Psounis, “Trading utility for privacy in shared spec- trum access systems,” IEEE/ACM Transactions on Networking (TON), SU Parameters: ni = 1000, bandwidth = 10Mbps, 1 signature verification per . vol. 26, no. 1, pp. 259–273, 2018. [6] P. Marshall, Three-tier Shared Spectrum, Shared Infrastructure, and a Our results, depicted in Fig. 2c, show that even for a cluster Path to 5G. Cambridge University Press, 2017. of size as large as 1000 SU s, a consensus is reachable in [7] W. I. Forum, “Cbrs communications security technical specification, less than 7 s even if up to 1/3 of the SU s are Byzantine. winnf-15-s-0065,” April 2017. [8] ——, “Cbrs threat model technical report, winnf-15-p-0089,” May 2016. The overhead of BFT depends heavily on the number of [9] M. Grissa, B. Hamdaoui, and A. A. Yavuza, “Location privacy in participants and the number of signature verifications required cognitive radio networks: A survey,” IEEE Communications Surveys & by each participant. Therefore, BFT will have a different Tutorials, vol. 19, no. 3, pp. 1726–1760, 2017. TrustSAS [10] B. Khalfi, B. Hamdaoui, and M. Guizani, “Airmap: Scalable spectrum cost for each of ’s algorithms. For instance in occupancy recovery using local low-rank matrix approximation,” in REKEYING, BFT will take as long as 76 s since each SU will Global Communications Conference (GLOBECOM), 2018 IEEE. need to verify the signatures of all other SU s in C(i) included [11] M. Grissa, B. Hamdaoui, and A. A. Yavuz, “Unleashing the power of multi-server pir for enabling private access to spectrum databases,” IEEE in the block submitted by the leader at step 7 of Alg. 2. Communications Magazine, vol. 56, pp. 171–177, December 2018. 6) End-to-end Delay: We provide in Table IV the end- [12] B. Chor, O. Goldreich, E. Kushilevitz, and M. Sudan, “Private informa- to-end delays caused by TrustSAS’s different algorithms, tion retrieval,” in Foundations of Computer Science, 1995. Proceedings., 36th Annual Symposium on. IEEE, 1995, pp. 41–50. ignoring Byzantine faultiness for simplicity. Observe that the [13] M. Vukoli´c, “Rethinking permissioned blockchains,” in Proceedings of REKEYING has the highest cost, which is invoked mainly when ACM Workshop on Blockchain, Cryptocurrencies and Contracts, 2017. a membership change occurs. One way to address this is by [14] E. Brickell and J. Li, “Enhanced privacy id: A direct anonymous attesta- SU tion scheme with enhanced revocation capabilities,” IEEE Transactions setting REKEYING frequency small, and have joining s on Dependable and Secure Computing, vol. 9, no. 3, pp. 345–360, 2012. wait a little longer before they join the system. Another way to [15] C. Rackoff and D. R. Simon, “Non-interactive zero-knowledge proof further reduce the cost in most of these algorithms is by using of knowledge and chosen ciphertext attack,” in Annual International Cryptology Conference. Springer, 1991, pp. 433–444. different quorums of users every BFT round. This will reduce [16] A. Boldyreva, “Threshold signatures, multisignatures and blind signa- the overhead but will also impact the security guarantees and tures based on the gap-diffie-hellman-group signature scheme,” in Int’l robustness against failures. Despite the relatively high cost of Workshop on Public Key Cryptography. Springer, 2003, pp. 31–46. [17] R. Gennaro, S. Jarecki, H. Krawczyk, and T. Rabin, “Secure distributed these algorithms, note that these operations are expected to be key generation for discrete-log based cryptosystems,” in Int’l Conf. on invoked only every few hours, as it is the case for TVWS, the Theory and App. of Crypto Tech. Springer, 1999, pp. 295–310. which requires SU s to query DBs every 24 hours. [18] A. Shamir, “How to share a secret,” Communications of the ACM, vol. 22, no. 11, pp. 612–613, 1979. VI. CONCLUSION [19] S. Goldfeder, J. Bonneau, R. Gennaro, and A. Narayanan, “Escrow pro- tocols for cryptocurrencies: How to buy physical goods using bitcoin,” We propose TrustSAS, a trustworthy framework for in Int’l Conf. on Financial Crypto and Data Security. Springer, 2017. SAS that preserves SU s’ operational privacy while adhering [20] T. Chen, H. Zhang, G. M. Maggio, and I. Chlamtac, “Cogmesh: A cluster-based cognitive radio network,” in 2007 2nd IEEE International to regulatory requirements mandated by FCC in the 3.5 GHz Symposium on New Frontiers in Dynamic Spectrum Access Networks. CBRS band. TrustSAS achieves this by synergizing state-of- [21] W. Lueks and I. Goldberg, “Sublinear scaling for multi-client private the-art cryptographic mechanisms with the blockchain tech- information retrieval,” in International Conference on Financial Cryp- tography and Data Security. Springer, 2015, pp. 168–186. nology. We show the privacy benefits of TrustSAS through [22] M. Castro, B. Liskov et al., “Practical byzantine fault tolerance,” in security analysis, simulation and experimentation. OSDI, vol. 99, 1999, pp. 173–186. [23] M. Integer and C. Rational Arithmetic, “C++ library (miracl),” ACKNOWLEDGMENT https://github.com/miracl/MIRACL, 2013, accessed: 2018-06-02. [24] “Global environment for network innovations,” https://www.geni.net/. This work was supported in part by the US National [25] “Percy++ library,” http://percy.sourceforge.net, accessed: 2018-06-14. Science Foundation under NSF awards CNS-1162296 and [26] “Threshold bls dfinity implementation,” CNS-1652389. https://github.com/dfinity/random-beacon, accessed: 2018-06-02. REFERENCES [27] “The intel(r) enhanced privacy id software development kit,” https://github.com/Intel-EPID-SDK, accessed: 2018-06-02. [1] FCC, “Report and order and second further notice of proposed rulemak- [28] https://www.keylength.com/, accessed: 2018-06-02. ing, number 15-47, gn docket no. 12-354. FCC,” April 2015.