Privacy-Preserving Searchable Encryption ...

Privacy-Preserving Searchable Encryption Framework for Permissioned Blockchain Networks Shahzaib Tahir∗ , Muttukrishnan Rajarajan† ∗† Department

of Electrical and Electronic Engineering School of Mathematics, Computer Science and Engineering City, University of London, United Kingdom ∗ Department of Information Security, College of Signals, National University of Sciences and Technology Islamabad, Pakistan Email: ∗ [email protected], ∗ [email protected], † [email protected] Abstract—Enabling keyword search directly over the data stored on the blockchain is a desirable technique that can help in the effective utilization of the data while preserving the privacy. Searchable Encryption (SE) is a well-known technique that allows search queries over the encrypted Cloud data, however, existing solutions are based on the assumption of the Cloud Server being “trusted-but-curious” or “honest-but-curious”. This leads to a compelling case to use permissioned blockchain technology to ensure greater levels of security when the Cloud Server is malicious. The amalgamation of SE and permissioned blockchain empowers a client to place complete trust on the Cloud Server and the services it has to offer. This paper presents a novel privacy-preserving framework to facilitate keyword search over encrypted data stored on the blockchain network. The framework for the first time studies SE over a permissioned blockchain network i.e., Hyperledger-Fabric. The SE scheme is privacypreserving as it is based on probabilistic trapdoors. As a result the framework guarantees prominent security and privacy gains. Index Terms—Hyperledger-Fabric, Probabilistic Trapdoors, Inverted Index, Indistinguishability, Smart Contract.

I. I NTRODUCTION Searchable Encryption (SE) is a cryptographic approach that allows to perform keyword search over the encrypted data outsourced to the Cloud. Most of the SE schemes presented till date assume that the Cloud Server is trusted-but-curious or honest-but-curious [1]–[3]. Hence the schemes fail when the server is malicious. This leads to a compelling case to use blockchain with SE that provides trust, immutability, transparency and provenance. Blockchain was for the first time proposed in [4] and applied to digital currency. Other areas of application of blockchain are thoroughly being explored, and almost daily, announcements are made on its applicability to everyday life. To name a few, up until now, blockchain is explored in the financial services by bringing trust, simplicity and efficiency to the financial transactions [5]. Blockchain in healthcare provides secure and efficient availability of the data across the peers [6]. Similarly, it could have a profound impact on digital voting [7], driverless cars [8] and the Internet of Things (IoT) [9]. Although blockchain has vast areas of application, but by-default it lacks in providing confidentiality and privacy

preservation. There are mainly two types of blockchain networks i.e., permissioned and permissionless. The permissioned blockchain network utilizes a set of access policies to allow the peers to access the network and the data stored within it. On the contrary, a permissionless blockchain allows access to all the peers regardless of their access rights. As evident, none of the network configurations allow to maintain confidentiality and privacy-preservation of the data stored on the blockchain. Encrypting the data prior to storing it onto the blockchain achieves confidentiality while making the keyword search over the blockchain difficult. Therefore, a SE scheme is required that is privacy preserving. Privacy-preservation in SE is a property that is accomplished with the help of probabilistic trapdoors. A trapdoor is a search token generated by an authorized person to delegate search to the Cloud Server. Probabilistic trapdoors help to generate a different search token for the same keyword searched again. As a result the search pattern remains hidden and the malicious Cloud Server or an adversary cannot launch distinguishability or passive attacks. A. Our Contributions This research makes the following contributions to the field of blockchain and SE: • A privacy-preserving SE framework is proposed that facilitates search over encrypted data stored on the permissioned and distributed ledger i.e., Hyperledger-Fabric. • To the best of our knowledge, this is for the first time a SE scheme based on probabilistic trapdoors is studied with respect to Hyperledger-Fabric. The proposed framework uses probabilistic trapdoors to resist distinguishability attacks and ensures higher-levels of security and privacy. B. Organization The system model along with the required design goals is discussed in the Section II. The related work is presented in the Section III. An overview of the architecture is presented in the the Section IV. The proposed Permissioned Blockchainbased Searchable Encryption (PBSE) framework is presented in Section V followed by the Security analysis in Section VI. Conclusions are drawn in Section VII.

II. S YSTEM M ODEL This section sheds light on the importance of SE and the blockchain technology with the help of a scenario. A. Problem Formulation Bob outsources sensitive and confidential data/documents D = {D1 , D2 , · · · , Dn } to the Cloud Server (CS) to ensure instant availability. Since the documents contain sensitive data, they are encrypted prior to being outsourced to the CS. Bob does not fully trust the CS and wants a mechanism that helps to maintain transparency, provenance and immutability over the encrypted documents. Precisely, Bob wants to record any update or modification to the encrypted documents outsourced to the CS as he is aware that encryption by default provides confidentiality but does not prevent data modification (meaningful/meaningless). Bob makes use of the permissioned blockchain technology that is a distributed ledger and restricts unauthorized access while providing integrity and transparency. Each encrypted document is recorded onto the blockchain after going through a consensus mechanism and after being endorsed and authenticated. Bob also realizes that searching for keywords over encrypted data on the blockchain network is not possible. Therefore, before encrypting the documents and prior to outsourcing them to the CS, Bob identifies a set of keywords W = {W1 , W2 , · · · , Wm } in D and generates a secure inverted index table I. The inverted index table I is sent to the CS to embed into the smart contract. Whenever bob wants to search for a keyword, he generates a trapdoor and sends it to the CS and further to the smart contract. The smart contract performs the search on behalf of Bob. Before sharing the search results, the consensus function is triggered that endorses, validates and applies ordering to the oncoming request so that they are also recorded on the blockchain. In this way not only are the results sent back to Bob, but also the trapdoor related information is stored onto the ledger. Using this search result, Bob is successfully able to identify the required data blocks and download them. B. Design Goals The proposed framework offers the following advantages beyond the SE and blockchain technologies in isolation: • Security allows to maintain confidentiality, integrity and availability of the data stored on the blockchain network. • Privacy-preservation allows to search and access specific data blocks while hiding the search pattern. • Transparency & Provenance attains accountability by maintaining information related to the existence of the data and its origin. • Immutability makes the data temper-proof by eliminating the possibility of modification. • Disintermediation removes the need for a trusted centralized authority for the data management. • Self-sovereignty refers to a user-centric approach, where the client has control over the data outsourced to the CS. • Permissioned access restricts access to untrusted peers while giving escalated access rights to the trusted peers.

The accomplishment of the aforestated goals lead to the client’s confidence onto the CS, resulting in the candid outsourcing of private and confidential documents onto the Cloud. Definition (Permissioned Blockchain-based Searchable Encryption Scheme (PBSE)): The proposed PBSE comprises of eight polynomial time algorithms Π = (KeyGen, SigGen, Build Index, Adopt, Build Trap, Put, Search Outcome, Dec): (K, ks , (kpr , kpu )) ← KeyGen(1λ ): is a probabilistic key generation algorithm that requires a security parameter λ as the input and returns a master key K. The asymmetric key pair (kpr , kpu ) and session key ks are derived from the master key K. The client runs this algorithm. Sig ← SigGen(kpu ): is a deterministic signature generation algorithm that requires the client’s public key kpu as the input and with the help of the membership service provider generates a signature. This is run by the client and the peers that want to be part of the network. (I, EncK (D)) ← Build Index(K, D): is a deterministic algorithm run by the client. It takes the master key K and collection of documents D as the input and returns a secure index I and encrypted documents EncK (D). Embed ← Adopt(Sig, I): is a deterministic algorithm triggered by the client. It takes the signature (Sig), index table I as input and embeds it to the smart contract (SC). Tw ← Build Trap(K, ks , w): is a probabilistic algorithm run by client. It takes the master key K, session key ks , keyword w as the input to output a trapdoor Tw . Append ← Put(EncK (D)/Tw ): is a deterministic algorithm that puts/records a transaction onto the blockchain. The encrypted documents (EncK (D)) or trapdoor (Tw ) is append to the blockchain through a consensus mechanism. X ← Search Outcome(ks , SC, I, Tw ): is a deterministic algorithm run by the Cloud Server with the help of the smart contract (SC). The algorithm triggers the search algorithm within the SC that takes the index table I and the trapdoor (Tw ) as the input and returns X, a set of encrypted document identifiers encrypted EncK (id(D)). Di ← Dec(K, X): is a deterministic algorithm executed by the client. The algorithm requires the client’s master key K and encrypted set of document identifiers EncK (id(Di )) to decrypt and recover the document id’s to retrieve corresponding blockchain data segments. III. R ELATED W ORK Extensive research has been carried out on privacypreserving SE Schemes [2], [10], [11]. However, limited research has been done on blockchain-based SE. Cai et al. in [12], have proposed a decentralized architecture that uses blockchain and SE. Their proposed architecture supports dynamic updates of the documents on a global ledger (permissionless blockchain) and hence they try to counter the fraudulent behavior of the clients. Although the proposed architecture allows to maintain confidentiality of the documents, it is not according to the definitions [2] of a privacy-preserving SE framework. The scheme is not based on probabilistic trapdoors due to which the search pattern is revealed and leads to

the contradiction of the principles of a privacy-preserving SE scheme. Furthermore, since the architecture is based on permissionless blockchain, any peer can be malicious and there is no mechanism to restrict access to the network. Do and Ng in [13] present a blockchain-based secure data storage system. The architecture uses permissioned blockchain for the secure data storage. The authors explore the concept of proof-of-readability [14] over permissioned blockchain. They modify the SE scheme proposed in [15] to adapt to their problem setting. The scheme provides data hiding and token hiding. Although, the authors have added privacy preservation to some extent, still they are not able to preserve the privacy of the trapdoors as the same trapdoor is generated for the same keywords searched again. Hence, the proposed system does not resist distinguishability attacks. Li et al. in [16] introduce SE over the data stored on the blockchain. Their threat model considers the server to be malicious, where the server does not return correct search results to the client. The authors extend the concept of bitcoin and apply SE to it. Therefore, they make use of a permissionless blockchain to maintain confidentiality of the encrypted documents but they are not able to restrict access to the blockchain network. To prove the security of their proposed architecture, they extend the definitions proposed in [10] and map them according to their construction. However, their construction is not secure under the security definitions [2] presenting stronger notions of security and privacy guarantees. IV. F RAMEWORK C ONCEPTUALIZATION As discussed earlier, the proposed framework explores the merger of SE and blockchain technology. The proposed framework mainly comprises of three operations; i.e., a) system setup, b) data insertion and c) keyword searching. A brief explanation of these phases are given below: A. System Setup Hyperledger is a permissioned blockchain technology that comes with a variety of frameworks to implement blockchain, such as, Iroha, Indy, Sawtooth, Quilt, Burrow and Fabric. We refer readers to [17] that explains the difference between these protocols. The proposed framework uses hyperledger-fabric [18] protocol for developing the blockchain application. The details about the system setup phase are as follows: 1) Membership Service Providers (MSP): For the effective management of the user IDs and to authenticate the peers that want to join the network, hyperledger-fabric relies on the MSP component. The MSP is based on a Certificate Authority (CA), that generates, verifies and revokes certificates related to an identity. Fabric allows to use default interface i.e., FabricCA API or an external CA. The fabric-CA API generates a signature for the peers by calling a Signing Algorithm. This signing algorithm requires the credentials of the peers and outputs an endorsement in return. All the future access to the blockchain network relies on the generated signature. If a peer needs to be verified by the MSP, a Signature Verification Algorithm is triggered. This requires the user’s ID, signature

and the endorsement. In return the output is “accept” if the signature is valid or “reject” otherwise. If the signature is valid, the peer is granted access to the network. 2) Chaincode: Chaincode also called a “smart contract” is a programmable code that is instantiated across all the peers on the network. The chaincode provides an interface/medium to the client application to interact with the peers. The chaincode is a collection of different functions that can be invoked by a client through the application. The invoke method is called by a client application to perform three types of transactions such as record, query and change. Record is invoked when a client wants to record a new transaction. This transaction will be encrypted by the client prior to being part of the blockchain. Query is invoked when a client wants to search for a keyword over the encrypted transactions already part of the blockchain. Hence this function enables keyword search over the encrypted data and the SE scheme is programmed under this function. A change is invoked when a client records a change in custody of an item or change in the form of an encrypted transaction. 3) Consensus Function: Consensus is a common agreement within the peers that allows to append a transaction on the existing ledger. The client application proposes a transaction. The endorsing peers simulate the proposed transaction with the help of the smart contract, without updating the ledger. The endorsing peers also record the current state of the ledger and the transition that may take place once the transaction is append to the ledger. This state transition is represented as Read and Written data called RW Sets that are signed and shared with the client application. Hence, the endorsement is a signed response to the results of the simulated transaction. Endorsement is governed by a policy such as 50% of the endorsing peers must endorse the transaction. The consensus function also uses an ordering service that takes the endorsed transaction and the RW sets from the client application to the ordering service. The ordering service orders the transaction into a block and broadcasts the information to all the peers part of the network. Figure 1 pictorially represents the setup phase of the proposed architecture. B. Data Insertion Upon completion of the initial setup of the client application and associated blockchain network, encrypted documents can be added onto the ledger. Since search over the blockchain is desirable, the proposed framework is based on the SE scheme presented in [2]. The client prior to encrypting the documents and outsourcing them to the CS has to generate a secure inverted index table I. The index table I is a mapping that shows the presence or absence of a keyword from a document. This is the only information that can be deduced from I while the keywords cannot be identified. Upon the successful generation of the index table I, the client encrypts the documents D using his master key K. The index table along with the encrypted document D is sent to the CS. In order to append the encrypted document to the ledger, the client has to be verified by the MSP. The client sends his signature to the MSP for validation and granted access.

V. P ROPOSED P ERMISSIONED B LOCKCHAIN - BASED S EARCHABLE E NCRYPTION (PBSE) F RAMEWORK This section presents the phases involved in the PBSE framework. Table I highlights the notations and abbreviations. TABLE I N OTATIONS AND A BBREVIATIONS SC –Represents the smart contract. M SP –Represents the Membership Service Provider. Sig –Symbolizes the signature of a client. CA –Denotes the Certificate Authority. ID –Denotes the unique identifiers. K –Represents a master key. ks –Denotes the session key. (kpr , kpu ) –Represents the public and private key pair. EncK –A probabilistic encryption algorithm that uses the master key. DecK –Denotes the decryption algorithm corresponding to EncK . H(·) –Represents a keyed one-way hash function. |W|–Denotes total number of identified distinct keywords. |D|–Denotes the size of a particular document, obtained by counting the words appeared in the document D. M ask() –Denotes the masked occurrence values.

A. System Setup

Fig. 1. The System Architecture

The chaincode allows to delegate operations to the peers. The client updates the search module within the chaincode with the latest index table I. In order to append the document to the blockchain, the client proposes this document as a transaction. The proposed transaction is sent to the peers that trigger the consensus function (the steps that will be followed during the consensus process are already discussed in the previous section). Upon the successful consensus, the proposed transaction is termed as a “validated transaction” and the ledger is updated with the encrypted document. In this way a client application is able to append encrypted documents/data onto the permissioned distributed ledger/blockchain. C. Keyword Searching Keyword searching requires the client to generate a probabilistic trapdoor. As only an authorized person is able to generate a meaningful trapdoor, hence, the trapdoor generation requires the client’s master key. The client also provides the keyword he intends to search for. The probabilistic trapdoor resists distinguishability attacks, as a new trapdoor is generated for the same keyword searched again. The generated trapdoor is sent to the CS to search on the client’s behalf. The client application invokes the CS with the query command. The smart contract using the trapdoor, identifies the encrypted document identifiers EncK (id(Di )) that contain the keyword. The client is notified about the search results and the Get operation is triggered. The trapdoor is append to the ledger via the consensus function and the required encrypted documents are directly retrieved from the blockchain network. The client using his master key is able to decrypt the documents.

1) KeyGen Algorithm: Given the security parameter λ, the KeyGen algorithm generates the master key K, asymmetric key pairs (kpr , kpu ) and the session key ks where, K, ks , (kpr , kpu ) ∈ {0, 1}λ . The ks is shared with the CS. Algorithm 1: KeyGen a) Input: A security parameter λ. b) KeyGen: Generate random keys K, ks , (kpr , kpu ) ← {0, 1}λ . c) Output: Master key K, asymmetric key pair (kpr , kpu ), session key ks .

2) SigGen Algorithm: Given the public key kpu , the algorithm with the help of the MSP and CA generates a unique signature corresponding to the client. Algorithm 2: SigGen a) Input: The public key kpu . b) SigGen: • Send the public key kpu to the MSP. • The CA computes the signature corresponding to the client. c) Output: Signature (Sig).

B. Data Insertion 1) Build Index Algorithm: The index table I is generated by the client according to the algorithm proposed in [2]. The algorithm makes use of a cryptographic Hash function H : {0, 1}λ × W → {0, 1}L ; where L is the length of the output. The keyed Hash function H uses the client’s master key K to generate hash of a keyword. This algorithm is also based on the property of modular inverse that helps to map the probabilistic trapdoor (discussed in the algorithms 6, 7). The index table by default reveals the frequency of occurrence of an encrypted keyword within a document leading to statistical

analysis attack. To avoid this, the proposed algorithm masks the values to mitigate the risk of an attack and only reveals the presence/absence of an encrypted keyword in a document.

use of the keyed hash function similar to the one used in Build Index algorithm. The trapdoor Tw is transmitted to the smart contract to search on the client’s behalf. Algorithm 6: Build Trap

Algorithm 3: Build Index a) Input: A set of documents D, dictionary of keywords W and the master key K. b) Initialization: • Initialize dynamic 2D Array A, prime number P of size λ+1bits. c) Build Index I: • for 1 ≤ t ≤ |W|: – let a ← HK (Wt ) mod P – Compute a−1 and store it in A[1][t]; – Compute EncK (id(Dn )), store it in A[t][1]; • for 1 ≤ u ≤ |D|: – if Wt ∈ Du ; set A[u][t] = A[u][t] + 1; – EncK (Du ) • M ask() : – for 1 ≤ m ≤ |W|: ◦ for 1 ≤ n ≤ D: Choose R in Zp A[n + 1][m + 1] = A[n + 1][m + 1] ∗ R d) Output: Index table I and encrypted set of documents.

2) Adopt Algorithm: Given the inverted index table I, Signature (Sig), the algorithm embeds the updated inverted index table I obtained from the Build Index algorithm within the Query function of the SC. Algorithm 4: Adopt a) Input: The signature (Sig), inverted index table I. b) Adopt: • The client is authenticated using Sig. • The Query function of the SC is updated with the I c) Output: The latest inverted index table I is embed within the SC.

3) Put Algorithm: Given the encrypted set of documents D, this algorithm appends documents to the ledger. This requires the client to firstly authenticate with the MSP. For this purpose, the consensus function is triggered. Upon the validation of a transaction from the validation peers it is added to the ledger. This is required for storing encrypted documents and maintaining a history of trapdoors and search results. Algorithm 5: Put a) Input: The signature (Sig), encrypted documents EncK (D). b) Adopt: • The client is authenticated by the MSP through CA using Sig. • The client proposes a transaction (EK (D) or Tw ). • The endorsing peers validate and endorse the transaction. • The ordering service orders the transaction into blocks. • The transaction specific information is broadcast to the peers. c) Output: The latest transaction is validated and append to the blockchain network.

C. Keyword Searching 1) Build Trap Algorithm: In order to search for a keyword over the encrypted documents stored on the blockchain, the client generates a probabilistic trapdoor. The trapdoor is made probabilistic with the help of a probabilistic symmetric encryption algorithm such as AES-CBC. This algorithm also makes

a) Input: The master key (K), the session key (ks ), keyword (w), Hash function H(·). b) Trapdoor Generation: • let b ← EncK (w) mod P . • let a ← HK (w) mod P • let c ← a ∗ b mod P • let d ← Hks (b). • Tw ← (d, c). c) Output: Transmit Tw to SC.

2) Search Outcome Algorithm: This algorithm is embedded within the smart contract. This algorithm is used to transmit a probabilistic trapdoor and search on behalf of the client. The CS does computations and identifies the entries for which d == Hks (c ∗ a−1 modP ). On the successful identification of the column, the SC returns the document identifiers to the client that give address to the required blocks on the network. Since the search is also recorded as a transaction, the Put algorithm is triggered again. Algorithm 7: Search Outcome a) Input: A trapdoor (Tw ) transmitted by the client, a session key (ks ), Hash functions H(·) and the index table I. b) Initialization: • A dynamic Array X. c) Searching: • for 1 ≤ l ≤ sizeof I: – if (d == Hks (c ∗ a−1 modP )) : – X[ ] ← EncK (id(Di )) d) Output: Encrypted document identifiers EncK (id(Di )).

3) Dec Algorithm: The client decrypts the encrypted document identifiers to uncover the blocks containing the required documents. The client can now retrieve the required documents directly from the blockchain network. Algorithm 8: Dec a) Input: Master key (K) and a set X of encrypted document IDs. b) Decryption: • for 1 ≤ o ≤ size of X: –DecK (X[o]); c) Output: Document identifiers id(Di )

VI. S ECURITY A NALYSIS This section presents the security analysis of the proposed PBSE Framework in accordance with the probabilistic trapdoor-based SE definitions proposed in [2]: Definition 1: (Keyword-Trapdoor Indistingushability for PBSE- Informal Version) A PBSE scheme is privacypreserving in the sense of Keyword-Trapdoor Indistinguishability if the underlying SE scheme provides Keyword-Trapdoor Indistinguishability. Precisely for two adaptively chosen keywords, the trapdoor is generated for any one of the keywords,

no PPT adversary can distinguish the trapdoor of one keyword from the other with non-negligible probability over 1/2. Proof Sketch: It is assumed that the adversary is given access to the dictionary of keywords. The adversary adaptively chooses a keyword i.e., the selection of the keyword depends upon the outcome of the previous search. Hence, the adversary is allowed to select the same keyword again. The adversary is given access to the trapdoor generated against the queried keyword and allowed to form a history of all the past queries and corresponding trapdoors. Now the adversary adaptively selects two distinct keywords, and a trapdoor is generated at random for any one of the two selected keywords. This trapdoor is shared with the adversary. The adversary is successful if it correctly guesses the keyword corresponding to the trapdoor. Intuitively, if the adversary distinguishes between the keywords, it leads to privacy breach. Definition 2: (Trapdoor-Index Indistingushability for PBSEInformal Version) A PBSE scheme is privacy-preserving in the sense of Trapdoor-Index Indistinguishability if the underlying SE scheme provides Trapdoor-Index Indistinguishability. Precisely for two adaptively chosen keywords, the generated trapdoors, no PPT adversary should be able to distinguish the index table entries associated to one trapdoor from the other with non-negligible probability greater than 1/2. Proof Sketch: It is assumed that the adversary is given access to the trapdoors and the corresponding index table entries. The adversary adaptively chooses a keyword such that can select the same keyword again. The adversary is given access to the trapdoor generated against the queried keyword along with the index table entry. The adversary forms a history of all the past queries, corresponding trapdoors and index table entries. Now the adversary adaptively selects two distinct keywords and a trapdoor is generated at random for one of the two selected keywords. This trapdoor is shared with the adversary. The adversary is successful if able to correctly guess the index table entry corresponding to this trapdoor. Intuitively, if the adversary is able to distinguish between the keywords, this could lead to a privacy breach resulting in sophisticated attacks revealing stored data. Theorem 1: The proposed PBSE is a Privacy-Preserving Blockchain-based Searchable Encryption Scheme. Proof Sketch: This proof directly follows the security definition 1 and 2. It is observed the proposed PBSE scheme is based on trusted atomic primitives such as encryption and hashing. To prove the scheme is Keyword-Trapdoor and Trapdoor-Index indistinguishable requires the trapdoors to be probabilistic. Only then the adversary is not able to distinguish between a trapdoor with probability greater than 1/2. This holds true when the adversary is maintaining a history of the past searches. The proposed PBSE scheme is based on the probabilistic trapdoors and the searching is governed by the CS through the chaincode/smart contract. The probabilistic trapdoors not only preserve the search pattern and resists distinguishability attacks but also prevents from passive attacks.

VII. C ONCLUSIONS AND F UTURE W ORK This paper proposes a novel permissioned blockchainbased Searchable Encryption framework built on an immutable distributed ledger i.e., hyperledger fabric. Hyperledger-fabric provides permissioned membership, scalability, higher level of trust and modular architecture. To enhance the security of the data outsourced to the Cloud, the data is encrypted and then stored on the blockchain. To search on the encrypted data, the proposed framework makes use of a privacy-preserving Searchable Encryption scheme based on probabilistic trapdoors that hides the search pattern. The security analysis yields that the proposed framework ensures higher levels of security and privacy guarantees. R EFERENCES [1] B. Wang, M. Li, and H. Wang, “Geometric range search on encrypted spatial data,” IEEE Transactions on Information Forensics and Security, vol. 11, no. 4, pp. 704–719, 2016. [2] S. Tahir, S. Ruj, Y. Rahulamathavan, M. Rajarajan, and C. Glackin, “A new secure and lightweight searchable encryption scheme over encrypted cloud data,” IEEE Transactions on Emerging Topics in Computing, vol. 99, no. 99, 2017. [3] C. Wang, N. Cao, J. Li, K. Ren, and W. Lou, “Secure ranked keyword search over encrypted cloud data,” in Distributed Computing Systems (ICDCS), 2010 IEEE 30th International Conference on. IEEE, 2010, pp. 253–262. [4] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system, http://bitcoin.org/bitcoin.pdf,” 2008. [5] J. Bonneau, A. Miller, J. Clark, A. Narayanan, J. A. Kroll, and E. W. Felten, “Sok: Research perspectives and challenges for bitcoin and cryptocurrencies,” in IEEE Symposium on Security and Privacy. IEEE, 2015, pp. 104–121. [6] M. Mettler, “Blockchain technology in healthcare: The revolution starts here,” in IEEE 18th International Conference on e-Health Networking, Applications and Services (Healthcom), 2016. IEEE, 2016, pp. 1–3. [7] P. Noizat, “Blockchain electronic vote,” Handbook of Digital Currency: Bitcoin, Innovation, Financial Instruments, and Big Data, p. 453, 2015. [8] G. Chavez-Dreyfuss, “Toyota, tech firms explore blockchain for driverless cars,” https://uk.reuters.com/article/us-toyota-selfdrivingblockchain/toyota-tech-firms-explore-blockchain-for-driverless-carsidUKKBN18I2G4, 2017, [Online; accessed 23-November-2017]. [9] K. Christidis and M. Devetsikiotis, “Blockchains and smart contracts for the internet of things,” IEEE Access, vol. 4, pp. 2292–2303, 2016. [10] R. Curtmola, J. Garay, S. Kamara, and R. Ostrovsky, “Searchable symmetric encryption: improved definitions and efficient constructions,” Journal of Computer Security, vol. 19, no. 5, pp. 895–934, 2011. [11] B. Wang, W. Song, W. Lou, and Y. T. Hou, “Inverted index based multikeyword public-key searchable encryption with strong privacy guarantee,” in IEEE Conference on Computer Communications (INFOCOM). IEEE, 2015, pp. 2092–2100. [12] C. Cai, Y. Xingliang, and C. Wang, “Towards trustworthy and private keyword search in encrypted decentralized storage,” in IEEE International Conference on Communications (ICC). IEEE, 2017, pp. 1–7. [13] H. G. Do and W. K. Ng, “Blockchain-based system for secure data storage with private keyword search,” in IEEE 13th World Congress on Services. IEEE, 2017, pp. 90–93. [14] H. Shacham and B. Waters, “Compact proofs of retrievability.” in Asiacrypt, vol. 5350. Springer, 2008, pp. 90–107. [15] R. A. Popa and N. Zeldovich, “Multi-key searchable encryption.” IACR Cryptology ePrint Archive, vol. 2013, p. 508, 2013. [16] H. Lia, H. Tiana, and F. Zhanga, “Block chain based searchable symmetric encryption, https://eprint.iacr.org/2017/447.pdf,” 2017. [17] TheLinuxFoundation, “Business Blockchain Frameworks Hosted with Hyperledger,” https://hyperledger.org/, 2017, [Online; accessed 28November-2017]. [18] Hyperledger, “hyperledger-fabric docs Documentation,” https://media.readthedocs.org/pdf/hyperledger-fabric/latest/hyperledgerfabric.pdf, 2017, [Online; accessed 28-November-2017].