T3AB: Transparent and Trustworthy Third-party Authority using Blockchain
TT AB: Transparent and Trustworthy Third-party Authority usingBlockchain
RUNHUA XU,
IBM Almaden Research Center state
California , United States
CHAO LI,
Beijing Jiaotong University, China
JAMES JOSHI,
University of Pittsburgh state
Pennsylvania , United States
Increasingly, information systems rely on computational, storage, and network resources deployed in third-party facilitiesor are supported by service providers. Such an approach further exacerbates cybersecurity concerns constantly raised bynumerous incidents of security and privacy attacks resulting in data leakage and identity theft, among others. These havein turn forced the creation of stricter security and privacy related regulations and have eroded the trust in cyberspace. Inparticular, security related services and infrastructures such as Certificate Authorities (CAs) that provide digital certificateservice and Third-Party Authorities (TPAs) that provide cryptographic key services, are critical components for establishingtrust in Internet enabled applications and services. To address such trust issues, various transparency frameworks andapproaches have been recently proposed in the literature. In this paper, we propose a
Transparent and Trustworthy TPA usingBlockchain ( π π΄π΅ ) to provide transparency and accountability to the trusted third-party entities, such as honest-but-curious third-party IaaS servers, and coordinators in various privacy-preserving machine learning (PPML) approaches. π π΄π΅ employsthe Ethereum blockchain as the underlying public ledger and also includes a novel smart contract to automate accountabilitywith an incentive mechanism that motivates participantsβ to participate in auditing, and punishes unintentional or maliciousbehaviors. We implement π π΄π΅ , and show through experimental evaluation in the Ethereum official test network, Rinkeby,that the framework is efficient. We also formally show the security guarantee provided by π π΄π΅ , and analyze the privacyguarantee and trustworthiness it provides.Additional Key Words and Phrases: Transparency, Trustworthiness, Third-party Authority, Blockchain, Ethereum, SmartContract, Functional Encryption Increasingly, information systems are being built on the third-party facilities or use external services, wherebasic computational, storage, network, resources are offered on a pay-as-you-go basis. This is beneficial to manyenterprises as it lowers costs and allows them to keep their focus on business missions. On the other hand,increasing cybersecurity incidents such as cybersecurity attacks including those leading to data leakage andidentity theft are amplifying usersβ concerns with regards to their sensitive personal data that is collected, stored,and processed on the third-party facilities. Furthermore, newer regulations such as Health Insurance Portabilityand Accountability Act (HIPPA), General Data Protection Regulation (GDPR), California Consumer PrivacyAct (CCPA), and New York SHIELD Act introduce stricter compliance requirements for enterprise informationsystems. Figure 1 illustrates the architecture of a typical privacy-preserving third-party service enabled system,as illustrated in a variety of existing work [1β4], where the personal data is protected by a cryptosystem, andthe encrypted data is collected and processed by a third-party IaaS server, while the public key and private keyservices are provided by the third-party authority (TPA). Usually, the third-party entities are assumed to be honest-but-curious , and a TPA is typically fully trusted .To address the trust and compliance issues on these service providers, especially, the security-related serviceproviders such as certificate authorities (CAs) and TPAs that provide certification service and key service inexisting public key infrastructures, various transparency approaches that provision openness and accountability
Authorsβ addresses: Runhua Xu, [email protected], IBM Almaden Research Center, San Jose, California, United States, 95120; Chao Li,[email protected], Beijing Key Laboratory of Security and Privacy in Intelligent Transportation, Beijing Jiaotong University, Beijing, China,100044; James Joshi, [email protected], School of Computing and Information, University of Pittsburgh, 135 North Bellefield Avenue, Pittsburgh,Pennsylvania, United States, 15260. a r X i v : . [ c s . CR ] F e b ig. 1. Illustration of a typical privacy-preserving third-party service. have been recently proposed [5β11] to increase usersβ trust or confidence in such services. For instance, the CAs,as the underlying public key infrastructure for SSL/TLS protocol, are responsible for issuing digital certificatesthat certify the ownership of a public key by the named principal of the certificate and allows others to rely uponsignatures made by the private key corresponding to the certified public key. To address various attacks [12β14]and mis-issuance problems [15β17] in the certificate issuing procedures, notions of certificate transparency [5, 7]and transparency overlay [10] have been proposed. Transparency overlay is actually a formalization of severalspecific certificate transparency frameworks.Similar to certificate transparency , the notion of authority transparency [18] has been proposed to address similarbut more complex issues related to a TPA; a TPA is a critical component of many emerging cryptosystems suchas attribute-based encryption (ABE) schemes [19β21] and functional encryption (FE) schemes [22β24]. Unlike theCAs that only need to issue a certificate that proves the identity-to-public-key binding, a TPA is responsible formore complex tasks such as setting public parameters and providing a private key service to authorized entitiesaccording to various credentials such as attribute identities and functionality-related materials. In particular,compared to certificate transparency , authority transparency can further capture multiple rounds of interactionsbetween a TPA and other entities.The initial authority transparency proposed in [18] presents a formal architecture to make TPAs transparentand trustworthy. However, there are limitations that hinder its deployment and application in several areas,for example, in emerging privacy-preserving machine learning (PPML) based applications proposed in [1β4].Specifically, these limitations include: (i) the definitions and protocols designed in authority transparency modelonly work on, and relies on, the attribute-based encryption schemes; and (ii) the implementation of authoritytransparency framework is based on a secure logging system. As a result, the existing authority transparency proposal does not directly support other emerging cryptosystems such as the functional encryption (FE) familythat has been used to build secure computation protocols in recently proposed PPML approaches [2β4]. Besides the identity-to-public-key-binding stealthy targeted attack and the private-key-service censorship attack as illustrated in[18], FE-based applications have additional privacy threats; for instance, there is a potential inference attack bymanipulating a malicious functionality-related vector, as illustrated in [2, 3]. Furthermore, the deployment of thedistributed secure logging system based authority transparency solution pose a challenge with regards to beingbroadly accepted by the Internet community because: (i) it requires several commercial companies or non-profitorganizations that have the computation and storage capabilities to deploy a publicly auditable secure loggingsystem such as that used in the certificate transparency community (e.g., a secure logging system deployed byGoogle or Mozilla); (ii) there is also a lack of a concrete mechanism for the entities to participate in a transparencyframework and monitor and audit unintentional or malicious behaviors.To address the aforementioned limitations, in this paper, inspired by the notion of authority transparency ,we propose an approach that provides Transparency and
Trustworthiness of a
Third-party Authority or enti-ties using Blockchain - in short, π π΄π΅ - for recently proposed or emerging crypto-based privacy-preserving pproaches. For simplicity, we use FE-based systems proposed in [2β4] as the underlying application to illustratethe π π΄π΅ approach. In particular, to achieve the transparency and trustworthiness goal, π π΄π΅ employs theEthereum blockchain as the underlying public ledger infrastructure, and also includes a novel and well designedEthereum smart contract to support automatic accountability with an additional incentive mechanism to motivateparticipants to participate in the auditing process and punish unintentional misbehaviors or malicious behaviors.We summarize our key contributions as follows: β’ We first revisit the notion of authority transparency model and propose our formal π π΄π΅ model with newdefinitions and protocols to address the entity trust issues considering the scenarios of FE-based systemswhere a TPA is commonly assumed to be fully trusted and the data user (third-party entities) is usuallyassumed to be honest-but-curious . β’ We design a novel smart contract to achieve automatic accountability based on our design of the π π΄π΅ model and employ the Ethereum blockchain as the underlying public ledger infrastructure. β’ We also design an incentive mechanism in the smart contract to (i) reward a TPA if it fulfills its obligation;(ii) punish any entity that violates its responsibility, and (iii) encourage other entities to help audit andinspect the potential malicious behaviors caused by the assumed fully trusted
TPA and assumed honest participants. β’ We finally analyze the security guarantee of π π΄π΅ and present the experimental evaluation on the smartcontract implemented in the Ethereum official test network - Rinkeby. The evaluation result shows that π π΄π΅ is efficient and provides security and privacy guarantees. Organization . The rest of the paper is organized as follows. In Section 2, we introduce relevant background,motivation, and preliminaries. We elaborate our π π΄π΅ framework in Section 3. We present the experimentalevaluation and security related analysis in Section 4. We review the related work in Section 5 and conclude thepaper in Section 6. Emerging modern cryptographic schemes, especially those that rely on a third-party authority (TPA) to provide keyservices, are being adopted in privacy-preserving applications, where data is encrypted and the data managementoperations such as querying, accessing control, and computation are over the encrypted data. A TPA is a criticalcomponent in these cryptosystems, and it is generally assumed to be fully trusted. Such an assumption is verycommon in cryptography research community. However, deploying such a trusted TPA component in a realscenario is still a challenge because there is a lack of (i) incentive mechanisms to encourage a participant (i.e.,a third-party entity) to play the role of the authority and (ii) a transparent mechanism to ensure that such aTPA works as expected when considering the attacks such as identity-to-public-key-binding stealthy targeted attack and private-key-service censorship attack as illustrated in [18]. Beyond authority transparency proposed in[18] that addresses the trust issues in a TPA caused by the aforementioned attacks, we address incentive issuesrelated to participantsβ engagement in a transparency framework via Ethereum blockchain techniques, and tackleadditional privacy leakage issue caused by assuming that an aggregator or coordinator is hones-but-curious infunctional encryption enabled applications [2, 3].Here, we briefly present some preliminaries, and background of related concepts such as functional encryptionand its related applications, authority transparency, blockchain, Ethereum, and smart contract.
Our proposed blockchain-based π π΄π΅ framework can support various TPA-based cryptosystems such as ABE-enabled applications as illustrated in [18] and the emerging FE-enabled applications. Here, we briefly introduce theFE cryptosystem and FE-based applications; we also differentiate between the ABE and FE structures/components. .1.1 Functional Encryption (FE). FE is a generalization of public-key encryption in which any party with anissued functional secret key allows us to compute a function of what a ciphertext is encrypting. We present thefollowing definition of FE based that presented in [22, 23].
Definition 2.1 (Functional Encryption Scheme [22]). A functional encryption (FE) scheme for functionality F is atuple E πΉπΈ = (Setup, KeyDerive, Encrypt, Decrypt) of four algorithms: β’ πππ‘π’π ( π ) outputs public and master secret keys (mpk, msk) for security parameter π ; β’ πΎππ¦π·ππππ£π ( ππ π, π ) outputs secret key π π π given inputs a master secret key ππ π and a key π β πΎ ; β’ πΈππππ¦ππ‘ ( πππ, π₯ ) outputs ciphertext ππ‘ given inputs a public key πππ and a message π₯ β π ; β’ π·ππππ¦ππ‘ ( πππ, ππ‘, π π π₯ ) outputs π§ β Ξ£ βͺ {β₯} .Note that the Setup and
KeyDerive algorithms are run by a TPA that is assumed to be fully trusted . A dataowner can adopt the
Encrypt algorithm to protect its data, while a data user with the functional decryption keyissued by its TPA can compute the function over the ciphertext to acquire the function result without learningthe original data.
The feature of computing over encrypted data makes functionalencryption a promising approach for employing secure multi-party protocols for privacy-preserving machinelearning (PPML) [2, 3]. While employing FE, a PPML also inherits the assumption of a trusted
TPA. Besides, PPMLtechniques typically assume that the aggregator or coordinator (that is, the decryption party when PPML uses aFE scheme) is honest-but-curious .Security guarantee provided by a FE scheme can ensure that the encrypted data cannot be compromised byan adversary [23]. However, there is still potential privacy leakage in PPML approaches that use FE schemes,as demonstrated in [2, 3]; here, an authorized honest-but-curious decryption party may exploit a manipulatedvector to request a functional decryption key to repeatedly execute the decryption algorithm over the encrypteddata and store the intermediate data to infer partial information in the encrypted data. For the specific inferenceattack, we refer the readers to [2, 3] for more details.
ABE is also a type of public-key encryption in which ciphertexts are dependentupon access policy over a set of attribute credentials (e.g., age, affiliation, etc.) and any party with proper attributecredentials can be issued a secret key to access the encrypted data. We present the following definition based onthe one from [25, 26].
Definition 2.2 (ABE Scheme [26]). A (ciphertext-policy) attribute-based encryption (ABE) scheme for access policy A is a tuple E π΄π΅πΈ = (Setup, KeyGeneration, Encrypt, Decrypt) of four algorithms: β’ πππ‘π’π ( π ) outputs public parameters and master secret keys (pk, msk) for security parameter π ; β’ πΎππ¦πΊππππππ‘πππ ( ππ, π ) outputs secret key π π π given inputs a master secret key ππ π and a set of attributes π ; β’ πΈππππ¦ππ‘ ( ππ, A , π ) outputs ciphertext ππ‘ given inputs public key ππ , message π , and access structure π΄ ; β’ π·ππππ¦ππ‘ ( πππ, ππ‘, π π π ) outputs π§ = π βͺ {β₯} .As in FE, the Setup and
KeyGeneration algorithms are run by a TPA that is assumed to be fully trusted . A dataowner uses the
Encrypt algorithm with a specified access policy to protect her data, while the data user withproper attribute credentials that satisfy the access policy can access (Decrypt) the encrypted data.The main difference between ABE and FE is the credentials that are used to generate or derive the private key.In ABE, the private key is generated based on a set of attributes of a data user, while the functional decryptionkey is derived from a function-related vector in FE for the functionality of inner-product scheme. Besides, theadoption of FE may introduce potential inference threats as illustrated in [3].
Remark . Unlike authority transparency [18] that builds on the ABE scheme, for simplicity, in this paper, weuse the recently proposed FE-based applications [2β4] as underlying examples to illustrate the key features of π΄π΅ . Specifically, π π΄π΅ focuses on providing transparency in cases related to above-discussed assumptions,namely, a trusted TPA and a honest-but-curious coordinator or aggregator, to increase usersβ trust in a system.In Section 3.4, we analyze the applicability of π π΄π΅ in other TPA-based cryptosystems. Authority transparency is defined as a publicly auditable set of a TPAβs activities [18]. The goal is to ensure that aTPA fulfills its auditing obligations ( O ) related to public parameter distribution ( O ππ ) and trustworthy key service( O ππ ), continuously and transparently. We formally define authority transparency as below; here, we adopt thenotation from [27]. Definition 2.3 (Authority Transparency [18]).
Let T , L and C denote a third-party authority, a log server, anda client, respectively, that use a set of interactive protocols. Let C .πππ‘ππ, C .ππ’πππ‘ππ and C .πππππ‘ππ representthe roles of the actor, auditor, and monitor that execute the application, auditing, and monitoring modules,respectively. We define authority transparency , AT T , L , CO , as a set of six interactive protocols: AT T , L , CO = ( Gen O , Log O ππ , Log O ππ , Check O , Inspect , Gossip ) , and each protocol is defined as follows: : ( π O ππ , π O ππ ) β Run ( π , Gen O , {T , C .πππ‘ππ } , ( π, π )) : ( π T , π ) β Run ( π , Log O ππ , {T , L } , ( π O ππ , π )) : ( π T ,π C , π ) β Run ( π , Log O ππ , {T , C .πππ‘ππ, L } , ( π, O ππ . S C , O ππ . S T )) : ( π,π C .ππ’πππ‘ππ ) β Run ( π , Check O , {L , C .ππ’πππ‘ππ } , ( π, π )) : ( π L , π ) β Run ( π , Inspect , {L , C .πππππ‘ππ } , ( π, π )) : ( evidence ) β Run ( π , Gossip , {C .ππ’πππ‘ππ, C .πππππ‘ππ } , ( π, π )) The order of parameters in the input tuple and the order of elements in the output are consistent withparticipating entities. For instance, in protocol ( π T , π ) β Run ( π , Log O ππ , {T , L} , ( π O ππ , π )) , there exists twoparticipants: T has the input O ππ while L has no input, as denoted by π .We briefly introduce each interactive protocol as follows:(1) Gen O is a protocol between T and C .πππ‘ππ that generates the audit obligations to be logged;(2) Log O ππ is a protocol between T and L that is used to record O ππ in the public log;(3) Log O ππ is a protocol involving T , L and C .πππ‘ππ that is used to record O ππ in the public log;(4) Check O is a protocol involving L , C .πππ‘ππ and C .ππ’πππ‘ππ that is used to check whether or not an auditobligation O ππ or O ππ is in the log;(5) Inspect is a protocol between L and C .πππππ‘ππ that is used to allow the monitor to inspect the contents ofthe log and find suspicious audit obligations {O π } ;(6) Gossip is a protocol between C .auditor and C .monitor that is used to compare different versions of a logand detect any inconsistencies caused by misbehavior of a participant or on behalf of the log server.Unlike the authority transparency approach proposed in [18] that is built on the distributed secure logging sys-tem, our proposed π π΄π΅ relies on the Ethereum blockchain. Thus, the above-mentioned protocols are not directlyapplicable in our blockchain-based π π΄π΅ framework. We will present our relevant definitions in Section 3.3. A blockchain is a growing list of records (a.k.a, blocks) that are linked via cryptographic techniques, where eachblock contains a cryptographic hash of the previous block, a timestamp, and the transaction data. In particular, ig. 2. Overview of the π π΄π΅ framework. Note that the dashed lines represent the procedures of the FE-based applications,while the solid lines denote the procedures of π π΄π΅ framework. the blockchain is a public distributed database of records, transactions, or digital events that have been executedand shared among various participants. In our proposed work we, employ a blockchain as the underlying publicledger infrastructure instead of the secure logging system adopted in [18].Ethereum is an open-source and public blockchain-based distributed computing platform supporting smartcontracts [28]. Usually, there are two types of accounts in Ethereum, namely External Owned Accounts (EOAs)controlled by private keys associated with users and Contract Accounts assigned to smart contracts. A smartcontract in Ethereum refers to a piece of code, for instance, a Solidity program code that usually consists ofmultiple functions, few parameters and perhaps some modifiers. To deploy a smart contract, an ordinary usercan compile the contract to generate the corresponding bytecodes and application binary interface (ABI), andthen send a contract creation transaction to the Ethereum network with the bytecodes and ABI. Upon receiving atransaction, the miners of the Ethereum network will include the bytecodes into the newly coming block beingadded. Each successfully deployed contract account can be viewed as a small decentralized computation andstorage unit that can execute specific functions defined in the contract and also store data allowed by the contract.As a result, the transactions, messages, as well as the inputs of the functions are all recorded by the Ethereumblockchain, and, hence, the outputs of the functions are deterministic because the distributed miners can ensurethat. Note that it is not free to either deploy a smart contract or to call a function of existing smart contracts inEthereum. A user needs to pay Gas that can be exchanged with Ether, the cryptocurrency used in Ethereum. π π΄π΅ FRAMEWORK3.1 Overview of π π΄π΅ To tackle trust issues caused by a TPA and curious entities in FE-based applications, here, we present our proposed π π΄π΅ framework that increases the transparency and trustworthiness of the entities using Ethereum blockchain. π π΄π΅ . Figure 2 illustrates the π π΄π΅ framework. Note that the dashed lines represent theprocedures of FE-based applications, while the solid lines denote the procedures of the π π΄π΅ framework. π π΄π΅ consists of the following entities: β’ TPA . The TPA is the same role as in the ordinary FE cryptosystem, but in π π΄π΅ it has additional responsibili-ties to fulfill, including: (a) submitting the public parameters obligations (in particular, identity-to-public-key https://github.com/ethereum/solidity https://github.com/ethereum/wiki/wiki/Whisper indings), (b) reporting its fulfillment of obligations in the key service process, and (c) verifying that thesubmitted/reported obligations are permanently recorded in the blockchain. β’ Actors . Actors include all users of an FE-based application, namely, the entities (e.g., participants ) thatemploy the encryption algorithm and the entities (e.g., coordinator ) that employ the decryption algorithm.Besides, the actors may also need to fulfill the obligations of key service because they are involved ininteraction with other actors and/or the TPA. β’ Monitors . Monitors are responsible for inspecting the contents of the recorded auditing obligations to findsuspicious obligations. In π π΄π΅ , the encryption entities or the additional independent entities play the roleof the monitors. β’ Administrator . An administrator is responsible for the deployment, maintenance, and administration ofthe smart contract. The smart contract mainly includes three modules: (a) the obligation record modulethat provides various interaction functions for the entities to carry out recording, auditing and inspectionrequirements related to the obligations, (b) the incentive mechanism that provides the payment and rewardfunctions to the participants, and (c) the inference prevention module (IPM) , previously deployed in a TPA asillustrated in [3]. Note that the Ethereum blockchain can ensure the trustworthiness of smart contracts; itcan also ensure that the recorded obligations are distributed, open, and tamper-proof. Furthermore, oncedeployed it does not need a centralized administration.
To elaborate our π π΄π΅ , we first present the notations, entities, and scenariosof applying our π π΄π΅ framework in an FE-based environment. Suppose that we have a group of data owners {C owner π } π β[ π ] that will share their private data π₯π₯π₯ = { π₯ π } π β[ π ] encrypted by an FE scheme where for simplicitywe assume that C owner π owns data π₯ π , a group of data users {C user π } π β[ π ] , where each data user has a vector π¦π¦π¦ π and needs to acquire the inner-product β¨ π₯π₯π₯,π¦π¦π¦ π β© over the ciphertext of π₯π₯π₯ , and a TPA A that provides public andprivate key services for these data owners and users. Furthermore, let {C owner π } π β[ π ] be the monitors. We use B to represent the Ethereum blockchain, and let B π π΄π΅ππΆ denotes our proposed smart contract deployed in theblockchain.
Existing FE-based applications are usually based on the assumption that a TPA is assumed to be fully trusted andthe coordinator (here, a.k.a., the decryption party) is assumed to be honest-but-curious . Hence, the threat modelsin such cases typically focus on an adversary who attempts to compromise the encrypted data and a curious entity that launches potential privacy attacks (e.g., infer the private information), while honestly following theprotocols/algorithms.In addition to addressing above threats, π π΄π΅ focuses on increasing entitiesβ trust on the TPAs and thecoordinators through transparency. In particular, π π΄π΅ removes the dependence of FE-based applications onthe assumptions of a trusted TPA and an honest coordinator. As illustrated by the identity-to-public-key-bindingstealthy targeted attack and the private-key-service censorship attack in [18], a TPA may not be trusted because ofits unintentional misbehaviors and/or malicious behaviors . Similarly, the coordinator may also behave dishonestly.We assume that such a dishonest adversary may pretend to behave honestly without being detected by otherentities. Adversaries may not follow the specifications in the protocols, and/or attempt to conceal their activities.In general, the dishonest adversary includes the TPA and actors, where a dishonest TPA may attempt to forgea key service proof-of-work without actually providing a valid key service; and, a dishonest actor may try toincorrectly blame other entities for misbehavior. Note that misbehavior may be related to non-malicious misuseby normal actors or the behavior of compromised actors controlled by an attacker.We note that the case of potential collusion between a dishonest
TPA and honest-but-curious actors is notconsidered in this paper. Rather than forbidding or preventing collusion through technical means, such collusion etween two stakeholders (i.e., TPA and actors) can be solved by resorting to game theory and incentivemechanism designed in the smart contracts, [29]. π π΄π΅ also involves the incentive mechanism from the aspectsof each entity, and hence it can prevent such collusion in a game theory manner. We will not discuss that in thereset of the paper, and readers can refer to [29] for more details.Furthermore, unlike the secure logging system based authority transparency framework in [18], where the logger is treated as a potential dishonest adversary, in π π΄π΅ , the Ethereum smart contract is adopted as the publicledger infrastructure that has been proved to be a trusted computation platform. π π΄π΅ Framework π π΄π΅ Model.
Unlike the authority transparency approach in [18] that builds on the secure logging systemfor ABE cryptosystem, π π΄π΅ uses the Ethereum blockchain, and to keep consistency, we adopt the similarconcepts/notions of the authority transparency but it considers different scenarios including FE-based applicationsand a blockchain-based public ledger infrastructure.Unlike ABE-based applications, in FE-based applications, there is no need to define complex attribute identitiesin the functional encryption scheme, and hence, we enhance the related concepts by considering the simplifiedidentities and smart contracts.Suppose that each entity π in π π΄π΅ is issued or self-generates an identity-based public and private key pair β¨ pk π , sk π β© . Note that the key service interaction occurs between entity C actor and authority A , where each entityhas already received its public and private key pair. For instance, let β¨ pk actor , sk actor β© and β¨ pk TPA , sk TPA β© representthe public/private key pairs of the actor and the TPA, respectively. Here, we first present the notion of publicparameter audit obligation and key service audit obligation , and then present the formal definition of π π΄π΅ . Definition 3.1 (Public Parameter Audit Obligation (PPAO)).
A PPAO O ππ of π is a map structure as follows: O πππ : = H ( π ππ ) : β¨ π ππ , pk π , Sig sk π ( π ππ , pk π )β© , where π ππ represents the descriptive identifier of π , H (Β·) is a hash function, pk π denotes the public key binding ofentity π , and Sig sk π is the signature using sk π . Definition 3.2 (Key Service Audit Obligation (KSAO)).
A KSAO O C actor , A ππ is a map structure consisting of a pairof key service snapshots O C actor , A ππ : = H (C actor ππ , A ππ , π ) : β¨S req , S resp β© , where each snapshot is a 4-tuple as follows: S req : = H (C actor ππ , A ππ , π ) : β¨ π, π , π‘ C actor , Sig sk actor ( π, π , π‘ C actor )β© , S resp : = H (C actor ππ , A ππ , π ) : β¨ π, π, π‘ A , Sig sk TPA ( π, π, π‘ A )β© , such that S req . H (C actor ππ , A ππ , π ) = S resp . H (C actor ππ , A ππ , π )S resp .π‘ A β S req .π‘ C actor > S req .π‘ A β S resp .π‘ C actor < πΏ π‘ where π is a nonce selected by the key service requester, π‘ is the timestamp of key service processed by eachentity, π denotes the request content such as function related vector, π represents the proof-of-work that TPAhas issued the key, πΏ π‘ is the threshold of timestamp difference indicating the expected time of processing of thekey service request by the TPA. emark . In particular, O ππ is an identity-to-public-key binding with the issuerβs signature, while O C actor , A ππ isthe proof-of-key-service . In the O C actor , A ππ , for simplicity, to provide the proof-of-work of issuing the functionaldecryption key sk π for the function related materials π , let Sig ππ be H ( sk π ) .Based on the notion of public parameter audit obligation and key service audit obligation , we present the formal π π΄π΅ model as follows: Definition 3.3 ( π π΄π΅ Model).
Let A , B and C denote a third-party authority, a blockchain, and an actor,respectively, which are parties involved in the interactive protocols. Let C .πππ‘ππ and C .πππππ‘ππ represent theroles of the actor and monitor that execute the functional and monitoring modules, respectively. We define π π΄π΅ model, M , as a set of five interactive protocols: M A , B , CO = ( Gen O , Log O ππ , Log O ππ , Inspect ) , and each protocol is defined as follows: ( π O ππ , π O ππ ) β Run ( π , Gen O , {A , C .πππ‘ππ })( π A , π ) β Run ( π , Log O ππ , {A , B} , ( π O ππ , π ))( π A , π C , π ) β Run ( π , Log O ππ , {A , C .πππ‘ππ, B} , (O ππ . S A , O ππ . S C , π ))( π B , π ) β Run ( π , Inspect , {B , C .πππππ‘ππ } , ( π, π )) Theorem 3.4 presents similar security guarantee as used in [18]. We present the details in Section 4.1.Theorem 3.4.
If the hash function is collision-resistant and the signature scheme is unforgeable, then π π΄π΅ modelcomprises a secure transparency framework.Remark . Note that the formal definition of our π π΄π΅ model is inherited from the authority transparency model[18] with needed changes considering the underlying Ethereum blockchain infrastructure. Specifically, in theauthority transparency model, the gossip protocol essentially ensures the consistency of distributed logs withoutbeing tampered by an adversary, while the check protocol guarantees that the submitted obligations are recordedby the logging system. As π π΄π΅ adopts the Ethereum blockchain as the underlying public ledger infrastructure,there is no need to run the gossip and check protocols because these logging-related functions are the featuresprovided by the Ethereum smart contract. B π π΄π΅ππΆ . The π π΄π΅ smart contract is a critical component in our framework. To support thegoal of π π΄π΅ framework, B π π΄π΅ππΆ includes various types of modules: administrative module , access control module , obligation module , inspection module , and incentive module . We discuss each module next. Administrative module allows the administrator role to deploy the smart contract into the Ethereum network.The module also includes functions such as opening and locking the enrollment, and allowing the participants todrop out.
Access control module . This module supports a basic role based access control (RBAC) mechanism that allowsthe account (a.k.a, the participating entities) have role-related permissions to call various functions. In B π π΄π΅ππΆ ,we define four types of roles: the
TPA , the actors of data owner , the actors of data user , the monitors and the administrator (i.e., the smart contract owner). The administrative entity that deploys the smart contract becomesthe smart contract owner . The ownership can be transferred to a new account if necessary. Besides, it is alsopossible to relinquish this administrative privilege, which is a common pattern after an initial stage when thereis a need for a decentralized administration. After the deployment, each entity needs to register to its role bycalling the corresponding function before it can use the ordinary features of the smart contract.
Obligation module . This module assists in recording the audit obligation into the public ledger. It also publishesits identity-to-public-key binding to the Ethereum blockchain, as illustrated above. Note that the identity of the ntity is the unique public address (i.e., 42 hex string characters without case-sensitivity) of the blockchainaccount, which is derived from the entityβs private key. With regards to the key service audit obligation procedure,the key service requestor (i.e., data owner) can call the corresponding function (that includes role verification)with a randomly generated request identifier, the key-related request parameters, and the corresponding signature.The function then automatically analyzes the request parameters via the inference prevention module (IPM) . Notethat the IPM, previously deployed inside the centralized trusted TPA in vanilla FE-based applications, is nowdeployed in the smart contracts in a decentralized trust setting in the π π΄π΅ . Upon receiving the key servicerequest with the request identifier, the TPA first checks the verification result of IPM. If the request passes theverification, the TPA will issue the functional decryption key and then publish a response snapshot to fulfill thekey service obligation. Inspection module . This module mainly inspects the completeness of a pair of the key service snapshots tocheck whether the TPA has fulfilled its key service obligation or not. Besides, it also allows checking for thepublished identity-to-public-key binding. Besides the inspection module that can prevent potential misbehaviors,we have introduced the RBAC mechanism to prevent partial misbehaviors and malicious behaviors as each entityonly will be allowed to call corresponding functions with limited privilege.
Incentive module . This module, as part of B π π΄π΅ππΆ , includes several functions to enforce the incentive mechanism,as depicted in Figure 4. The incentive mechanism is based on payment features of the Ethereum network, wherethe token can be exchanged for real currency. As illustrated in Figure 4, we design several functions as "publiclypayable", which indicates that the smart contract is able to receive the transaction value (e.g., the Ether) when thefunction is successfully called and executed.In general, π data consumers need to pay equally for the cost of calling the registration function for themselvesas well as for π data owners and the TPA. Each data user also needs to pay for the cost of calling the requestobligation record function and that of calling the response obligation record function by the TPA. Additionally,there exists a mechanism to punish the misbehaviors and malicious activities by a dishonest TPA and data users.To achieve that, the data users and the TPA first need to register and pay the cost by themselves. The data ownersmake a deposit equally for all the entitiesβ registration cost after the enrollment phase. Then, the data users andthe TPA can call the disposable reward function to withdraw the registration cost. Besides, we make the TPAand data owners make a guaranteed deposit after the registration phase. The monitors can register and pay thecost by themselves, and then calls the inspection function to check the suspicious behaviors. If monitors find themalicious behaviors, they will acquire the reward from a fine to the corresponding entity (i.e., the guaranteeddeposit of the entity). Without the guaranteed deposit, the corresponding entity is not allowed to operate in/jointhe system. We discuss the quantitative analysis of the cost of each entity in B π π΄π΅ππΆ in Section 4.2. π π΄π΅ Procedures.
As depicted in Figure 3, we illustrate the four phases of the π π΄π΅ framework with specificprocedures in a typical FE-based application scenario. Note that the dashed arrows represent the functionalprocedures of a typical FE-based application, while the solid arrows denote procedures specific to π π΄π΅ . In ourdesign, each entity in the FE-based application can also play the role of the auditor and monitor, and we also allowadditional monitors to help inspect the misbehaviors and malicious behaviors. Below, we present the specificprocedures of each phase in π π΄π΅ . Phase I: entity initialization : For each entity π with role π ππππ and identifier π ππ in the framework, it generates a publicand private key pair β¨ pk π , sk π β© . Then, entity π registers its role π ππππ to B π π΄π΅ππΆ , and publishes its id-to-public-keybinding β¨ π ππ , pk π β© with its signature Sig sk π ( π ππ , pk π ) to B π π΄π΅ππΆ . Phase II: FE initialization . The TPA A sets up the FE cryptosystem with the master public key and master privatekey pair β¨ mpk FE , msk FE β© . Using the master key, the TPA generates and sends the common public key pk FE πππ for ig. 3. Illustration of the four phases with specific procedures in π π΄π΅ in a FE-based application scenario. Note that thedashed arrows represent the functional procedures of a typical FE-based application, while the solid arrow lines denoteprocedures in π π΄π΅ . all entities (i.e., data owners and data users) in the FE-based application. Then, the TPA publishes the binding β¨A ππ , pk FE πππ β© with its signature Sig sk A (A ππ , pk FE πππ ) to B π π΄π΅ππΆ . Phase III: secure data publishing . For each data owner C owner π , it first selects a nonce π as the key service identifier.Then C owner π requests the entity-specific public key pk FE C owner π from the TPA with π . Meanwhile, C owner π also sends arequest key service snapshot S C owner π req to B π π΄π΅ππΆ as follows: S C owner π req = β¨ π, , π‘ C owner π , Sig sk C owner π ( π, , π‘ C owner π )β© . Then, the TPA generates pk FE C owner π for C owner π using its master keys, and also publishes a corresponding responsekey service snapshot S A πππ π to B π π΄π΅ππΆ to fulfill its key service audit obligation O C owner π , A ππ with mapping keyH (C owner π,ππ , A ππ , π ) as follows: S A resp = β¨ π, H ( pk FE C owner π ) , π‘ A , Sig sk A ( π, H ( pk FE C owner π ) , π‘ A )β© . Each data owner then uses pk FE π owner π to encrypt its data as follows: { Enc pk FE π owner π ( π₯ π )} π β[ π ] . Finally, the data ownerpublishes a receipt for the received pk FE π owner π . Phase IV: secure data computation . Suppose that a data user C user π who has a vector π¦π¦π¦ π = ( π¦ , ..., π¦ π ) π wouldapply inner-product functionality over the encrypted data { Enc ( π₯ ) , ..., Enc ( π₯ π )} . C user π also selects a key serviceidentifier π β² first, and then requests the functional decryption key sk FE π¦π¦π¦ π to the TPA with the vector π¦π¦π¦ π and π β² . Atthe same time, C user π also sends the request key service snapshot S C user π req to B π π΄π΅ππΆ as follows: S C user π req = β¨ π β² ,π¦π¦π¦ π , π‘ C user π , Sig sk C user π ( π β² ,π¦π¦π¦ π , π‘ C user π )β© . nlike the approaches proposed in [2, 3] that deploy the inference prevention module (IPM) within a TPA, wepropose to deploy IPM in a smart contract as the TPA is not fully trusted in π π΄π΅ . Thus, the TPA needs to query B π π΄π΅ππΆ to check the validity of π¦π¦π¦ π . If π¦π¦π¦ π is valid, the TPA generates sk FE π¦π¦π¦ π for C user π using its master keys, and thenpublishes a corresponding response key service snapshot S A resp to B π π΄π΅ππΆ to fulfill its key service audit obligation O C user π , A ππ with mapping key H (C user π , A , π β² ) as follows: S A resp = β¨ π β² , H ( sk FE π¦π¦π¦ π ) , π‘ A , Sig sk A ( π β² , H ( sk FE π¦π¦π¦ π ) , π‘ A )β© . Otherwise, the TPA refuses the key service and also publishes key service snapshot indicating that it has refusedthe key service, S A , refuseresp , with refusing symbol β₯ to B π π΄π΅ππΆ to fulfill its key service audit obligation as follows: S A , refuseresp = β¨ π β² , H (β₯ ,π¦π¦π¦ π ) , π‘ A , Sig sk A ( π β² , H ( sk FE π¦π¦π¦ π ) , π‘ A )β© . With the received sk FE π¦π¦π¦ , a data user can compute the inner-product of β¨ π₯π₯π₯,π¦π¦π¦ β© by decryting as follows: β¨ π₯π₯π₯,π¦π¦π¦ π β© = Dec sk FE π¦π¦π¦π ({ Enc pk FE C owner π ( π₯ π )} π β[ π ] ) . Finally, the data owner publishes a receipt for the received sk FE π¦π¦π¦ . Remark . To avoid redundant description, we do not present the roles of auditor and monitor in the above-mentioned procedures. In particular, as illustrated in Figure 3, the data users , data owners and the TPA also playthe role of auditor that checks whether the audit obligations are recorded into the blochchain permanently.In our design, the data owners also play the role of a monitor to check the suspicious obligations caused bymisbehaviors and malicious behaviors from the TPA and adversarial data users . For instance, as illustrated in[2, 3], an adversarial data user may infer the private vector π₯π₯π₯ by manipulating a vector to request the functionaldecryption key. The monitor can inspect O π user ,π TPA ππ to find the adversaryβs suspicious behaviors. Furthermore, ourdesign can also address the case of intentionally issuing an incorrect functional decryption key. For example,suppose the key request material (i.e., π₯π₯π₯ ) from the authorized user is correct after IPM checking, while the key isincorrect. In π π΄π΅ , the data user is also the monitor/auditor and can file a claim by manually calling the inspectfunction based on existing logged key service materials. T AB π π΄π΅ is applicable to other TPA-based cryptosystems as well. Specifically, we analyze the applicability of π π΄π΅ in the attribute-based encryption scheme that is the focus of authority transparency proposed in [18].Differences in key service audit obligations in FE and ABE schemes are as shown in Table 1. The main differencein the key service is the credential type, namely, the function-related vector and the attributes that are usuallyrepresented in a character string. These credentials are used to generate or derive the private key in the Setup and
KeyGeneration phases. As presented in Section 3.3, π π΄π΅ is a general framework and is not restricted tothe type of audit obligation that builds on different key service credentials. Specifically, the request content π and response proof-of-work π in Definition 3.2 are not limited to a function-related vector and correspondinghashed generated key as illustrated in Section 3.3.3. π π΄π΅ is applicable to ABE-based applications by replacingthe following audit obligations: S C user π req = β¨ π β² ,π¦π¦π¦ π , π‘ C user π , Sig sk C user π ( π β² ,π¦π¦π¦ π , π‘ C user π )β© , S A resp = β¨ π β² , H ( sk FE π¦π¦π¦ π ) , π‘ A , Sig sk A ( π β² , H ( sk FE π¦π¦π¦ π ) , π‘ A )β© , able 1. Different key service audit obligations in FE and ABE Types audit obligations in FE audit obligations in ABESetup-Output private key public parameterKeyGen-Input function-related vector attribute setKeyGen-Output functional decryption key attribute-related private key by the corresponding audit obligations: S C user π req = β¨ π β² , πππ π , π‘ C user π , Sig sk C user π ( π β² , πππ π , π‘ C user π )β© , S A resp = β¨ π β² , H ( sk ABE
πππ π ) , π‘ A , Sig sk A ( π β² , H ( sk FE πππ π ) , π‘ A )β© , where πππ π is the attribute set and H ( sk ABE
πππ π ) is the corresponding access control private key generated by the TPAusing the attribute set πππ π in the hash format. The security for the transparency framework is defined in terms of three properties[10, 18]: (i) log-consistency - a dishonest public ledger cannot remain undetected if it tries to present inconsistentversions of the recorded obligations; (ii) unforgeable-service - a dishonest TPA cannot forge a key service bysending valid key service snapshots, but not provide the key service to the actors; (iii) non-fabrication - a dishonestTPA or actors cannot blame the public ledger for misbehavior if it has behaved honestly, and dishonest actorscannot prove the TPA for misbehavior if it has behaved honestly.We note that log-consistency relies on the security properties of the Ethereum blockchain. The unforgeable-service and non-fabrication properties depend on the designed smart contract functions and the adopted signaturescheme. Here, we use the game simulation-based reduction methodology to prove Theorem 3.4.Proof. π π΄π΅ is built on three fundamental security components: the Ethereum blockchain as the public ledgerinfrastructure, the Secure Hash Algorithm 3 (SHA3) as the collision-resistance hash function, the Elliptic CurveDigital Signature Algorithm (ECDSA) to sign and validate the origin and integrity of messages. The security ofthree components has been proved in corresponding related work [28, 30, 31]. We only prove the above-mentionedthree security properties. Log-consistency . Unlike the existing transparency framework, [10, 18], that relies on the customized public ledger, π π΄π΅ uses the public blockchain that has already been proved to provide secure consistency feature [28], andhence we do not present it here to avoid redundancy. Unforgeable-service . In π π΄π΅ , there are two possible issues related to forgeable-service: β’ a dishonest TPA may publish S A resp to the blockchain, but does not send the key sk π to the actors; β’ the dishonest TPA may send an invalid key sk β² π to the actors, but publishes correct S A resp generated fromthe valid key sk π .For the first issue, the confirmation phase of key service audit obligation cannot be accomplished in our designedsmart contract, and then such adversarial behavior is easily detected by the monitors. For the second issue, supposethat the dishonest TPA has the non-negligible advantage π to break the unforgeable-service security guarantee,and hence it can forge the hashed key component H ππ»π΄ ( sk β² π ) for sk π with advantage Adv A H ππ»π΄ ( sk β² π )β sk π β₯ π . o achieve that, the dishonest TPA hence needs the ability to find potential collision H ππ»π΄ ( sk π ) = H ππ»π΄ ( sk β² π ) .According to the security promise of SHA3, it is impossible to find that collision with non-negligible advantage[30]. Thus, dishonest TPA does not have a non-negligible advantage to provide an unforgeable key servicewithout being detected. Non-fabrication . In π π΄π΅ , a possible fabrication case is that dishonest actors may attempt to blame the TPAby publishing S C actor πππ to the blockchain but does not actually send the key request to the TPA. Suppose that adishonest actor has the non-negligible advantage π to break the non-fabrication security promise. To launch thefabrication case, the dishonest actor needs to forge a fake S A resp so that it can accomplish the confirmation phase.Thus, the dishonest actor is able to forge a fake signature of the TPA with advantage Adv C actor sk A β₯ π . However, it isimpossible to break the ECDSA [31], as has been proved, namely, the unforgeability of the signature scheme.Thus, the actors do not have a non-negligible advantage to frame up the TPA. β‘ Unlike the authority transparency framework that focuses on ABE-based applicationswhere partial attribute identities are privacy-sensitive, π π΄π΅ framework also supports the FE-based applicationscenarios. There is no privacy concern regarding the identity in an FE-based application since FE-based com-putation focuses on the secure computation instead of identity based access control features. Furthermore, theidentity of each entity in π π΄π΅ is the public account address of the Ethereum network, which is a random 64character hex string generated from the private key of the entity. Thus, such account identities do not reveal anyprivate information, even public identity information in the FE-based applications. The purpose of the π π΄π΅ approach is to deal with the trust issues raised by potential dishonest entities by providing transparency. π π΄π΅ is able to prevent the attacks such as stealthy targeted attackand censorship attack as illustrated in [18]. Specifically, each dishonest entity needs to publish the key servicesnapshot to prove that it has fulfilled its obligation of public parameter distribution and private key service. Thedesigned smart contract can ensure that each entityβs submitted audit obligations can be automatically cross-validated based on our designed protocols before being honestly and permanently recorded into the blockchain.Our security analysis has shown that the misbehaviors or malicious behaviors of a TPA and the actors are easilydetected. Furthermore, the IPM is a critical component in FE-based applications [2, 3] that helps to mitigatethe inference threats. In π π΄π΅ , the IPM, which was deployed in a TPA in the scheme proposed in [3], is movedto the smart contract, is automatically executed in a publicly auditable environment, and hence increase thetransparency and trustworthiness of IPM. In this section, we present the implementation of the proposed π π΄π΅ framework and the experimental evaluation. The π π΄π΅ model does not rely on the specific FE-based applications, and hencefor generality, we only present the evaluation on a pure π π΄π΅ model with the simulated audit obligations wherethe key-related components are generated by the FE-based application in an off-line manner. Implemented Smart Contract : We implement the smart contracts in
Solidity programming language using a
Truffle framework - a development environment, testing framework and asset pipeline for blockchains usingthe Ethereum Virtual Machine (EVM). Figure 4 presents simplified π π΄π΅ smart contract interfaces. π π΄π΅ mainlyincludes four types of functions as follows: β’ Access Control Modifiers . The modifier can be used to change the behavior of functions in a declarative way.In our implementation, we use the modifier to automatically check the privilege of each account that isdefined in RBAC module prior to executing the function. We employ
Ownable and
AccessControl smart pragma solidity ^0.6.0; pragma experimental ABIEncoderV2; import "./Ownable.sol"; import "./AccessControl.sol"; contract T3AB is Ownable, AccessControl { // access control related modifiers bytes32 public constant AUTHORITY_ROLE = keccak256("AUTHORITY_ROLE"); bytes32 public constant ACTOR_DATA_OWNER_ROLE = keccak256("ACTOR_DATA_OWNER_ROLE"); bytes32 public constant ACTOR_DATA_USER_ROLE = keccak256("ACTOR_DATA_USER_ROLE"); bytes32 public constant MONITOR_ROLE = keccak256("MONITOR_ROLE"); modifier onlyAuthority() modifier onlyDataOwner() modifier onlyDataUser() modifier onlyActor() modifier onlyMonitor() modifier onlyDeposit() modifier onlyWithdrawRegisterCost() // administrative and incentive function enrollLock() public onlyOwner function enrollOpen() public onlyOwner function depositeGuarantee() public payable onlyDeposit function rewardRegisterCost() public onlyWithdrawRegisterCost function rewardDeploymentCost() public onlyOwner function _checkGuaranteeDeposit(address account) private returns(bool) function _inferencePreventionModule(uint[l] memory y) private returns(bool) function dropout() public // Registration function registerAuthority(bytes memory pk, sign memory sign) public payable function registerActorDataOwner(bytes memory pk, sign memory sign) public function registerActorDataUser(bytes memory pk, sign memory sign) public function registerMonitor(bytes memory pk, sign memory sign) public // Obligation function recordKSPKReq(bytes32 id, uint pkReqSymbol, uint reqTime, sign memory sign) public onlyDataOwner function recordKSPKResp(bytes32 id, bytes32 pkHash, uint respTime, sign memory sign) public onlyAuthority function recordKSSKReq(bytes32 id, uint[l] memory y, uint reqTime, sign memory sign) public payable onlyDataUser returns(bool) function recordKSSKResp(bytes32 id, bytes32 skHash, uint respTime, sign memory sign) public onlyAuthority function recordKSConfirm(address tpa, bytes32 id, bytes32 keyHash, uint confirmTime, sign memory signRecpt, sign memory sign) public onlyActor // Inspection function inspectObligationKS(bytes32 id) public onlyMonitor returns(bool) function inspectObligationPP(address addr, bytes memory pk, sign memory sign) public onlyMonitor returns(bool) } Fig. 4. The overview of π π΄π΅ smart contract interfaces. Note that the parameter βsignβ is our defined customized struct thatare not presented here. Such a feature is provide in ABIEncoderV2 . ontracts from OpenZeppelin as the basis for our access control mechanism. To be specific, we definevarious access control modifiers in which the basic RBAC functions are integrated to satisfy our accesscontrol requirement. Except for the registration related functions, other functions are restricted by thesemodifiers. β’ Administrative and Incentive Functions . We define several administrative functions such as βenrollLock()β , βenrollOpen()β , βdropout()β that allow the administrator to control the enrollment status. In π π΄π΅ , each entitycan register if and only if the enrollment is set as open by the administrator. After the enrollment is locked,the deposit operations are opened to the related entities. Besides, π π΄π΅ also inherits the administrativefunctions such as βtransferOwnership(newOwner)β , βrenounceOwnership()β that are not presented in Figure 4.These two functions allow transferring the ownership of the contract and leave the contract without owner,respectively. Furthermore, we also define several withdraw and deposit functions that help to establish abasis for the incentive and penalty mechanisms. β’ Registration Functions . The registration functions mainly focus on the initialization phases of π π΄π΅ (i.e.,Phases I and II, as illustrated in Section 3.3.3), where each entity is allowed to register a role, and publishits identity-to-public-key binding in the blockchain. β’ Obligation Functions . The obligation functions address the core features of the π π΄π΅ model. As illustratedin Section 3.3.3 Phases III and IV, we use a three-phase commitment approach to achieve the obligationfeatures. To be specific, βrecordKSPKReqβ, and βrecordKSSKReqβ allow the actors to publish the key servicerequest snapshots, while βrecordKSPKRespβ, and βrecordKSSKRespβ allow the TPA to record correspondingkey service response snapshots. Then, βrecordKSPKRespβ function allows us to confirm the receipt of thekey service. β’ Inspection Functions . The inspection functions address the monitoring task for the recorded audit obligationas discussed in Section 3.3.3. To be specific, βinspectObligationKSβ allows to automatically inspect thecompleteness of the key service obligations, while βinspectObligationPPβ permits the monitor to verify thepublished identity-to-public-key binding. Regarding the incentive design, if a dishonest behavior is detected,the corresponding entity will be fined a fixed number of ethers that will be provided as an incentive rewardto the monitor.
Experimental Setup : Our experiments have been performed on a Macbook Pro platform with 2.3GHz 8-CoreIntel Core i9 processors and 32GB DDR4 memory. Besides, we use the Ethereum official test network, Rinkeby, asthe experimental environment to deploy our smart contract. Furthermore, we write several
JavaScript test-casesusing the automated testing framework of
Truffle that is built on Mocha and provides a cleanroom environment.Specifically, for demonstration, we use five Ethereum accounts to simulate various entities in π π΄π΅ , namely,the role of the administrator , the TPA , the data owner , the data user and the monitor . With regards to variousscenarios, we write corresponding test-cases to evaluate the performance (i.e., the gas cost and the time cost forscenarios such as administrative, registration, obligation, etc).
We report the performance of π π΄π΅ for selected functions for various test scenariosin Table 2. In particular, the performance includes two aspects: the gas cost and the test time. Gas is spent inEthereum for deploying smart contracts or calling functions. As reported in Table 2, most functions cost very little.Specifically, except for the smart contract deployment, the cost of each function is at the level of 10 gas in general.Regarding the most called functions for obligation and inspection, to record an audit obligation for one keyservice, the functions related to three-phase commitment (i.e., recordKSSKReq , recordKSSKResp , recordKSConfirm )cost 3 . Γ gas, 8 . Γ gas, 4 . Γ gas, respectively. Besides, the cost of inspection for key service andpublic parameter audit obligations is 2 . Γ gas and 3 . Γ gas, respectively. https://openzeppelin.com/contracts/ https://mochajs.org/ able 2. The gas cost and test time of selected functions in various test case scenarios in the π π΄π΅ . Test Cases Functions Gas Cost Time DescriptionAdministrative deployment 4125603 183ms deploy the smart contractenrollOpen 44126 42ms open the enrollmentenrollLock 14531 46ms lock the enrollmentdropout 28293 178ms allow to drop out and withdraw the balanceIncentive depositGuarantee 28083 48ms deposit the guaranteerewardRegisterCost 52949 43ms reward registration cost for non-payable entityrewardDeploymentCost 51584 41ms reward deployment for the administratorRegisteration registerAuthority 38276 80ms register the role of third-party authorityregisterActorDataOwner 38335 71ms register the role of data ownerregisterActorDataUser 36555 70ms register the role of data userregisterMonitor 36521 72ms register the role of monitorObligation recordKSSKReq 43173 96ms publish the key service request snapshotrecordKSSKResp 84211 55ms publish the key service response snapshotrecordKSConfirm 43402 49ms confirm receipt of the key service obligationInspection inspectObligationKS 24511 41ms inspect the key service audit obligationinspectObligationPP 37482 46ms check the correct of the public parameter
Furthermore, we also measure the time it takes to test the selected functions. Except for the administrativefunctions, the calling time of rest of the functions is less than 100 ππ . Note that the time to test each function ismeasured in the Ethereum test network. The testing time is related to execution time instead of time taken toconfirm the transaction . Thus, the deployment time of the smart contract is only 183 ππ rather than the generaltime taken to confirm a transaction, namely, about 6 minutes. Functional Encryption based Applications . Emerging FE schemes [22, 23] have been shown to be a promisingcandidate for secure computation in privacy-preserving application scenarios where data is encrypted andoutsourced, and the computation is carried out over the encrypted data. Especially, recently proposed functionalencryption for the functionality of computing the inner-product such as in [23, 24] raises the possibility ofapplying functional encryption in complex applications such as the federated learning and deep neural networks,as demonstrated in [2, 3].We note that a homomorphic encryption-based secure computation approach does not need a third-partyauthority (TPA), while the FE-based secure computation method relies on a TPA to help generate the publicparameters and provide functional decryption keys related to each function. A TPA is a critical component and isusually assumed to be fully trusted in the FE-based application. Furthermore, the entities such as a coordinatorin federated learning are also assumed to be honest-but-curious . However, the trust issues caused by maliciousinsiders in the TPA infrastructure [10, 18] and the privacy inference issues caused by curious entities [2, 3] havenot been investigated adequately.
Transparency and Blockchain . The concept of transparency issues have received more and more attentiondue to malicious activities or misbehavior in various secure computing infrastructures and components. Forinstance, the certificate transparency proposed in [5, 7] aims to mitigate the certificate-based threats caused byfake or forged SSL certificates that are mistakenly or maliciously issued by insiders. Most recent and relatedwork such as
CONIKS [8] and transparency overlay [10] target the key transparency in end-to-end encryptedcommunications systems and provide a formal transparency model. The work closest to this proposed work is he authority transparency framework proposed in [18] that addresses the issues related to potentially dishonestTPAs in ABE-based applications using a secure logging based approach. Further, blockchain based techniqueshave also been introduced to help increase the transparency of existing certificate transparency framework,such as in [17, 32]. However, there is still a lack of a mechanism to address the authority transparency issues forFE-based applications without relying on the complex secure logging systems. Such a transparency approach isimportant to ensure the trustworthy deployment of FE-enabled systems. TIn this paper, we have proposed the π π΄π΅ framework to address transparency and trustworthiness of third-partyauthorities (TPAs) and honest-but-curious entities in FE or ABE-enabled applications, as well as other schemesthat have components similar TPAs and many entities that interact with them. π π΄π΅ employs the Ethereumblockchain as the underlying public ledger infrastructure and also incorporates a novel smart contract to supportaccountability with an additional incentive mechanism that motivates participants to engage in auditing andpunish misbehaviors or malicious behaviors in the environment. Our evaluation shows that π π΄π΅ is efficientin the simulated Ethereum, and achieves the security, privacy and trustworthiness goals. One future directionis to establish a more complete theoretical framework for transparency with security an privacy guaranteesthat incorporates FE and ABE type schemes as well as other cryptographic infrastructures that have differentarchitectural components. REFERENCES [1] Edouard Dufour Sans, Romain Gay, and David Pointcheval. Reading in the dark: Classifying encrypted digits with functional encryption.
IACR Cryptol. ePrint Arch. , 2018:206, 2018.[2] Runhua Xu, James BD Joshi, and Chao Li. Cryptonn: Training neural networks over encrypted data. In , pages 1199β1209. IEEE, 2019.[3] Runhua Xu, Nathalie Baracaldo, Yi Zhou, Ali Anwar, and Heiko Ludwig. Hybridalpha: An efficient approach for privacy-preservingfederated learning. In
Proceedings of the 12th ACM Workshop on Artificial Intelligence and Security , pages 13β23, 2019.[4] ThΓ©o Ryffel, David Pointcheval, Francis Bach, Edouard Dufour-Sans, and Romain Gay. Partially encrypted deep learning using functionalencryption. In
Advances in Neural Information Processing Systems , pages 4517β4528, 2019.[5] Ben Laurie, Adam Langley, and Emilia Kasper. Certificate transparency. Technical report, IETF, 2013.[6] Mark Dermot Ryan. Enhanced certificate transparency and end-to-end encrypted mail. In
NDSS . Internet Society, 2014.[7] Ben Laurie. Certificate transparency.
Queue , 12(8):10, 2014.[8] Marcela S Melara, Aaron Blankstein, Joseph Bonneau, Edward W Felten, and Michael J Freedman. Coniks: Bringing key transparency toend users. In
USENIX Security , pages 383β398, 2015.[9] Benjamin Dowling, Felix GΓΌnther, Udyani Herath, and Douglas Stebila. Secure logging schemes and certificate transparency. In
EuropeanSymposium on Research in Computer Security , pages 140β158. Springer, 2016.[10] Melissa Chase and Sarah Meiklejohn. Transparency overlays and applications. In
Proceedings of the 2016 ACM SIGSAC Conference onComputer and Communications Security , pages 168β179, 2016.[11] Saba Eskandarian, Eran Messeri, Joseph Bonneau, and Dan Boneh. Certificate transparency with privacy.
Proceedings on PrivacyEnhancing Technologies , 2017(4):329β344, 2017.[12] David Basin, Cas Cremers, Tiffany Hyun-Jin Kim, Adrian Perrig, Ralf Sasse, and Pawel Szalachowski. Design, analysis, and implementationof arpki: an attack-resilient public-key infrastructure.
IEEE Transactions on Dependable and Secure Computing , 15(3):393β408, 2016.[13] Jiangshan Yu, Mark Ryan, and Cas Cremers. Decim: Detecting endpoint compromise in messaging.
IEEE Transactions on InformationForensics and Security , 13(1):106β118, 2017.[14] Kevin Borgolte, Tobias Fiebig, Shuang Hao, Christopher Kruegel, and Giovanni Vigna. Cloud strife: mitigating the security risks ofdomain-validated certificates. In
NDSS . Internet Society, 2018.[15] Deepak Kumar, Zhengping Wang, Matthew Hyder, Joseph Dickinson, Gabrielle Beck, David Adrian, Joshua Mason, Zakir Durumeric,J Alex Halderman, and Michael Bailey. Tracking certificate misissuance in the wild. In , pages 785β798. IEEE, 2018.[16] Quirin Scheitle, Taejoong Chung, Jens Hiller, Oliver Gasser, Johannes Naab, Roland van Rijswijk-Deij, Oliver Hohlfeld, Ralph Holz, DaveChoffnes, Alan Mislove, et al. A first look at certification authority authorization (caa).
ACM SIGCOMM Computer CommunicationReview , 48(2):10β23, 2018.
17] Jing Chen, Shixiong Yao, Quan Yuan, Kun He, Shouling Ji, and Ruiying Du. Certchain: Public and efficient certificate audit based onblockchain for tls connections. In
IEEE INFOCOM 2018-IEEE Conference on Computer Communications , pages 2060β2068. IEEE, 2018.[18] Runhua Xu and James Joshi. Trustworthy and transparent third party authority.
ACM Transactions on Internet Technology (TOIT) , 2020.[19] Yannis Rouselakis and Brent Waters. Practical constructions and new proof methods for large universe attribute-based encryption. In
Proceedings of the ACM SIGSAC CCS , pages 463β474. ACM, 2013.[20] Nikita Gorasia, RR Srikanth, Nishant Doshi, and Jay Rupareliya. Improving security in multi authority attribute based encryption withfast decryption.
Procedia Computer Science , 79:632β639, 2016.[21] Shashank Agrawal and Melissa Chase. Fame: fast attribute-based message encryption. In
Proceedings of the 2017 ACM SIGSAC Conferenceon Computer and Communications Security , pages 665β682, 2017.[22] Dan Boneh, Amit Sahai, and Brent Waters. Functional encryption: Definitions and challenges. In
Theory of Cryptography Conference ,pages 253β273. Springer, 2011.[23] Michel Abdalla, Dario Catalano, Dario Fiore, Romain Gay, and Bogdan Ursu. Multi-input functional encryption for inner products:function-hiding realizations and constructions without pairings. In
Annual International Cryptology Conference , pages 597β627. Springer,2018.[24] Michel Abdalla, Florian Bourse, Angelo De Caro, and David Pointcheval. Simple functional encryption schemes for inner products. In
IACR International Workshop on Public Key Cryptography , pages 733β751. Springer, 2015.[25] Vipul Goyal, Omkant Pandey, Amit Sahai, and Brent Waters. Attribute-based encryption for fine-grained access control of encrypteddata. In
Proceedings of the 13th ACM conference on Computer and communications security , pages 89β98, 2006.[26] John Bethencourt, Amit Sahai, and Brent Waters. Ciphertext-policy attribute-based encryption. In , pages 321β334. IEEE, 2007.[27] Mihir Bellare and Sriram Keelveedhi. Interactive message-locked encryption and secure deduplication. In
IACR International Workshopon Public Key Cryptography , pages 516β538. Springer, 2015.[28] Gavin Wood et al. Ethereum: A secure decentralised generalised transaction ledger.
Ethereum project yellow paper , 151(2014):1β32, 2014.[29] Changyu Dong, Yilei Wang, Amjad Aldweesh, Patrick McCorry, and Aad van Moorsel. Betrayal, distrust, and rationality: Smartcounter-collusion contracts for verifiable cloud computing. In
Proceedings of the 2017 ACM SIGSAC Conference on Computer andCommunications Security , pages 211β227, 2017.[30] Morris J Dworkin. Sha-3 standard: Permutation-based hash and extendable-output functions. Technical report, 2015.[31] Don Johnson, Alfred Menezes, and Scott Vanstone. The elliptic curve digital signature algorithm (ecdsa).
International journal ofinformation security , 1(1):36β63, 2001.[32] Ze Wang, Jingqiang Lin, Quanwei Cai, Qiongxiao Wang, Daren Zha, and Jiwu Jing. Blockchain-based certificate transparency andrevocation transparency.
IEEE Transactions on Dependable and Secure Computing , 2020., 2020.