Implementation of searchable symmetric encryption for privacy-preserving keyword search on cloud storage

Abstract

Ensuring the cloud data security is a major concern for corporate cloud subscribers and in some cases for the private cloud users. Confidentiality of the stored data can be managed by encrypting the data at the client side before outsourcing it to the remote cloud storage server. However, once the data is encrypted, it will limit server's capability for keyword search since the data is encrypted and server simply cannot make a plaintext keyword search on encrypted data. But again we need the keyword search functionality for efficient retrieval of data. To maintain user's data confidentiality, the keyword search functionality should be able to perform over encrypted cloud data and additionally it should not leak any information about the searched keyword or the retrieved document. This is known as privacy preserving keyword search. This paper aims to study privacy preserving keyword search over encrypted cloud data. Also, we present our implementation of a privacy preserving data storage and retrieval system in cloud computing. For our implementation, we have chosen one of the symmetric key primitives due to its efficiency in mobile environments. The implemented scheme enables a user to store data securely in the cloud by encrypting it before outsourcing and also provides user capability to search over the encrypted data without revealing any information about the data or the query.

Salam et al. Hum. Cent. Comput. Inf. Sci. (2015) 5:19 DOI 10.1186/s1367301500399

http://crossmark.crossref.org/dialog/?doi=10.1186/s13673-015-0039-9&domain=pdf

Web End = http://crossmark.crossref.org/dialog/?doi=10.1186/s13673-015-0039-9&domain=pdf

Web End = http://crossmark.crossref.org/dialog/?doi=10.1186/s13673-015-0039-9&domain=pdf

Web End = http://crossmark.crossref.org/dialog/?doi=10.1186/s13673-015-0039-9&domain=pdf

Web End = http://crossmark.crossref.org/dialog/?doi=10.1186/s13673-015-0039-9&domain=pdf

Web End = http://crossmark.crossref.org/dialog/?doi=10.1186/s13673-015-0039-9&domain=pdf

Web End = http://crossmark.crossref.org/dialog/?doi=10.1186/s13673-015-0039-9&domain=pdf

Web End = http://crossmark.crossref.org/dialog/?doi=10.1186/s13673-015-0039-9&domain=pdf

Web End = Md Iftekhar Salam1, WeiChuen Yau2*, JiJian Chin2, SweeHuay Heng3, HuoChong Ling4, Raphael CW Phan2, Geong Sen Poh5, SyhYuan Tan3 and WunShe Yap6

*Correspondence: [email protected]

2 Faculty of Engineering, Multimedia University, Cyberjaya, Selangor, Malaysia Full list of author information is available at the end of the article

RESEARCH

Open Access

Implementation ofsearchablesymmetric encryption forprivacypreserving keyword search oncloud storage

Abstract

Ensuring the cloud data security is a major concern for corporate cloud subscribers and in some cases for the private cloud users. Condentiality of the stored data can be managed by encrypting the data at the client side before outsourcing it to the remote cloud storage server. However, once the data is encrypted, it will limit servers capabil ity for keyword search since the data is encrypted and server simply cannot make a plaintext keyword search on encrypted data. But again we need the keyword search functionality for efficient retrieval of data. To maintain users data condentiality, the keyword search functionality should be able to perform over encrypted cloud data and additionally it should not leak any information about the searched keyword or the retrieved document. This is known as privacy preserving keyword search. This paper aims to study privacy preserving keyword search over encrypted cloud data. Also, we present our implementation of a privacy preserving data storage and retrieval system in cloud computing. For our implementation, we have chosen one of the symmetric key primitives due to its efficiency in mobile environments. The implemented scheme enables a user to store data securely in the cloud by encrypting it before outsourcing and also provides user capability to search over the encrypted data without revealing any information about the data or the query.

Keywords: Searchable encryption, Data condentiality, Cloud storage, Keyword search

Background

With the rapid development of cloud computing and mobile networking technologies, users tend to access their stored data from the remote cloud storage with mobile devices. The main advantage of cloud storage is its ubiquitous user accessibility and also its virtually unlimited data storage capabilities. Despite such benets provided by the cloud, the major challenge that remains is the concern over the condentiality and privacy of data while adopting the cloud storage services [1]. For instance, unencrypted user data stored at the remote cloud server can be vulnerable to external attacks initiated by unauthorized outsiders and internal attacks initiated by the untrustworthy cloud service providers (CSPs) [2]. There are several reports that conrm data breaches related to cloud servers, due to malicious attack, theft or internal errors [3]. This raises concern for many users/

2015 Salam et al. This article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/

Web End =http:// http://creativecommons.org/licenses/by/4.0/

Web End =creativecommons.org/licenses/by/4.0/ ), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.

Salam et al. Hum. Cent. Comput. Inf. Sci. (2015) 5:19

organizations as the outsourced data might contain very sensitive personal organization/ information.

Several researches have addressed the issue of ensuring condentiality and privacy of cloud data without compromising the user functionality. Here, condentiality refers to the secrecy of the stored data so that only the client can read the contents of the stored data. To solve the problem of condentiality, data encryption schemes can come in handy to provide the users with some control over the secrecy of their stored data. This has been adopted by many recent researches which allow users to encrypt their data before outsourcing to the cloud [49]. However, standard encryption schemes will dampen users searching ability over the stored data, since after encryption a user simply cannot use a plaintext keyword to perform a search anymore and therefore cannot retrieve the contents in an efficient way.

The keyword search functionality enables the user to search for a certain keyword on the remote cloud data. Consider a cloud application that consists of a cloud service provider (CSP), and users who store their data on the cloud storage. The users can use a traditional encryption scheme to ensure the condentiality of the contents. The nave approach for retrieving encrypted contents related to a certain keyword would require the user to download all the stored data, and then decrypt and perform the search on the local machine. However, this solution is infeasible from a practical point of view, as the user needs to download all the contents rather than the contents containing the searched keyword. For example, consider a scenario where the cloud storage contains 1 GB of users data, but only 1MB of data is related to the searched keyword. Using the nave solution, it is required to retrieve all the 1GB data, which is inefficient. Alternatively, the user can store a plaintext keyword index in the cloud server and use it while retrieving the data. However, this approach will allow the CSPs to know about the keyword which is not desirable either. Therefore, to ease the data retrieval from a secure cloud, we need a scheme which enables user capability to search over encrypted contents.

To provide a secure and efficient retrieval of data, one needs to ensure that the user can perform a search over the encrypted data without revealing the contents and the searched keyword to the server. The cryptographic primitive that provides this feature is widely known as searchable encryption (SE). This research aims to study the searchable encryption schemes in detail and implements a solution that enables privacy preserving data storage and retrieval system in cloud computing (aka PrivCloud). For our implementation, we have chosen an existing searchable symmetric key encryption algorithm. To enable the privacy preserving keyword search, this scheme will generate an encrypted keyword index which will be outsourced to the cloud server along with the encrypted data set. The encrypted keyword index lists out the encrypted keyword and pointer to the corresponding document containing that keyword. To search a keyword, client can simply encrypt the keyword to generate the search token and send it to the remote cloud server. The server can retrieve pointer to the corresponding document by matching the search token with the encrypted keyword index table. For our proposed solution, we have chosen to index all the words from the document instead of a specic keyword set. This will allow the client to search for any word in the document rather than any specic keyword. Also, indexing all the words of the document make sure that the user does not need to maintain a keyword index table at the client side since it can

Page 2 of 16

Salam et al. Hum. Cent. Comput. Inf. Sci. (2015) 5:19

search for any words. However, indexing all the words will come with the trade-o of a slightly larger index size. One of the limitations of the proposed solution is that it does not support the addition of new les since the index update is static.

Background onsearchable encryption

This section provides a detailed background on the searchable encryption scheme. In particular, we discuss about the architecture, security requirements and design approaches for searchable encryption scheme.

Searchable encryption: architecture

Searchable encryption (SE) enables the users to generate a search token from the searched keyword in such way that given a token, the cloud server can retrieve the encrypted contents containing the searched keyword. Basically, the search token represents an encrypted query over the encrypted data and can be generated only by users with the appropriate secret key. Figure1 shows the basic architecture and working principle of a searchable encryption scheme. The architecture comprises mainly four entities: data owner, data user, cloud service provider and key generator. A brief description of the entities and their operations are given below.

A. Data owner: The data owner is the entity which generates and encrypts the data and uploads them to the cloud server. It can be either an organization or an individual. To use the service, the data owner uses its application which consists of a data processor

Page 3 of 16

Data Server Service Manager

Encrypted Data Encrypted Query

Cloud Service Provider

Test

Data Owner Data User

Key Management

Key Generator

Figure1 Architecture of a searchable encryption scheme. The gure shows the general architecture and components of a searchable encryption scheme. It describes the workow of the searchable encryption scheme.

Data Retrieval

Key Management

Salam et al. Hum. Cent. Comput. Inf. Sci. (2015) 5:19

for uploading new contents to the cloud. It encrypts the data and metadata with a cryptographic scheme[1] that enables searching capability.B. Data user: This entity is also a subscriber to the cloud storage which sends encrypted queries to the cloud service provider to search for a specic encrypted data. There may be more than one data user in the system and in some scenario, the data owner and the data user might be the same entity.

C. Cloud service provider: This entity provides the data storage and retrieval service to the subscribers. The cloud service provider consists of cloud data server and cloud service manager. The rst entity is used to store the outsourced encrypted data whereas the latter one is used for data management in the cloud. Upon receiving the encrypted search queries from the data user, the cloud service provider tests on the encrypted queries and encrypted metadata in the cloud storage. The encrypted data that satises the search criteria is retrieved and sent back to the data owner upon completion of the test. The cloud service provider should not learn any information from the operation.

D. Key generator: This entity is considered to be a trusted third party which is responsible for the generation and management of the encryption/ decryption keys. User specic keys are generated and distributed during the setup of the system.

Searchable encryption: security requirements

In general, the following requirements should be satised when constructing a searchable encryption scheme.

Retrieved data: Server should not be able to distinguish between documents and determine search contents.

Search query: Server should not learn anything about the keyword being searched for. Given a token, the server can retrieve nothing other than pointers to the encrypted content that contains the keyword.

Query generation: Server should not be able to generate a coded query. The query can be generated by only those users with the relevant secret key.

Search query outcome: Server should not learn anything about the contents of the search outcome.

Access patterns: Server should not learn about the sequences and frequency of documents accessed by the user.

Query patterns: Server should not learn whether two tokens were intended for the same query.

Searchable encryption: design approaches

Searchable encryption scheme can be built using either a non-keyword based approach or an index/keyword based approach. In the non-keyword based approach, the scheme scans the entire document word by word to nd out the word W of interest. This provides the functionality to search any words in the document. However, it takes a long search time for a large number of document set. On the other hand, index/keyword based solution builds up an index [10], for each word W of interest and lists out the

Page 4 of 16

Salam et al. Hum. Cent. Comput. Inf. Sci. (2015) 5:19

corresponding documents that contain W. This provides a faster search operation when the document set is large. However, storing and updating the index can be an overhead.

From the viewpoint of cryptographic algorithm selection, the SE scheme can mainly be modeled using either asymmetric/public key or symmetric/secret key setting. In the following, we briey discuss the dierence between these two settings.

A. Asymmetric searchable encryption (ASE): In this setting, a user encrypts the data using asymmetric/public key encryption schemes (e.g. RSA) before outsourcing it to the cloud server. This setting is appropriate for a scenario where the user searching over the data is dierent from the user who generates it. For example, multiple users can use the public key of a certain user to encrypt and upload the data, however; only the owner with the corresponding private key can generate the search token and therefore can perform a search over the encrypted data. The main advantage of ASE is its functionality whereas the drawback is inefficiency. ASE schemes can be used in a larger number of settings since the reader and writer can be dierent for this case. On the other hand, all known ASE schemes require the evaluation of pairings on elliptic curves which is a relatively slow and costly operation compared to the hash functions or block ciphers [1]. Several researches have been conducted in developing SE scheme using public key cryptography [1116].

B. Symmetric searchable encryption (SSE): In this setting, a user encrypts the data using symmetric/private key encryption schemes (e.g. AES) before outsourcing it to the cloud server. This setting is appropriate when the user that searches over the data is also the one who generates it. The main advantage of this setting is the efficiency, but it lacks of functionality as it can only be used for a single user scenario. Moreover, most of the SSE schemes leaks the access patterns. The encryption is efficient because most SSE schemes are based on symmetric primitives like block-ciphers and pseudo-random functions and requires very less computational overhead. The SSE scheme was rst proposed by Song etal. [17] which provides techniques for remote searching over encrypted data using symmetric key primitives. Later, security notions of SSE schemes were revisited and stronger security denitions were provided by Goh [10], Chang etal. [18] and Curtmola etal. [19].

Related work

In this section, we present a brief summary of related works dealing with the searchable encryption schemes. Searchable encryption scheme can be designed based on either public key or symmetric key algorithm. The rst searchable encryption scheme based on public key algorithm was proposed by Boneh etal. [11]. This is known as the PEKS scheme which uses the public key of a user to encrypt and store the data in the server, and allows an authorized user with the private key to search and decrypt the corresponding content. This is a keyword based scheme ensuring faster search functionality; however, limiting the search capability. Also, the scheme is computationally expensive and it reveals the user access pattern. An extension of the PEKS scheme was proposed by Liu etal. [14]. This also uses the public key primitive to support the keyword searching on encrypted data. This scheme allows the cloud service provider to participate in the partial decipherment and claims to have reduced computational overhead on the client

Page 5 of 16

Salam et al. Hum. Cent. Comput. Inf. Sci. (2015) 5:19

due to this partial decipherment. Another variant of the PEKS scheme called iPEKS was proposed by Tseng etal. [15]. This scheme aims to accelerate the search time by looking into the previously searched keywords. For this, the cloud service provider caches the previously searched keywords to avoid the search on all the stored ciphertexts. However, this comes with the tradeo of large storage overhead. The rst searchable encryption scheme based on symmetric key primitive was proposed by Song etal. [17]. This provides a non-keyword based solution. However, this scheme can search for only xed length words and also the search time is linear in document size, since the it needs to scan the whole document to complete the search. The scheme is too slow when searching for a large number of documents. Goh [10] addresses some of the issues of the above scheme by introducing the concept of a secure index. This scheme generates a search index which can be used to locate the encrypted content. Later, the security notions of searchable symmetric encryption were revisited and stronger security denitions were provided by Curtmola etal. [19]. This is a very simple scheme based on keyword indexing approach.

Proposed solution

This research aims to design and develop a privacy preserving data storage and retrieval system in cloud computing. The scopes involve the use of searchable encryption algorithms to search for specic keywords within an encrypted content, i.e., without requiring the user to download the database and decrypt its contents before searching can be performed. The proposed solution delegates searching on encrypted data to CSP but with privacy preserved. For the searchable encryption algorithm, we have chosen to implement the adaptively secure Searchable Symmetric encryption (referred as SSE-2 scheme in the original paper) scheme proposed by Curtmola etal. [19]. For the rest of the paper, we will use the term SSE-2 scheme or adaptively secure SSE scheme to refer to the proposed method by Curtmola etal. The SSE-2 scheme provides a simple but efficient method to enable searching over encrypted data while preserving the data privacy. The reason behind selecting a private/symmetric key primitive for our implementation mainly lies in the fact that it results in signicantly lesser computational overhead when compared to its public/ asymmetric key counterpart and therefore will be more suitable for mobile devices.

Adaptively secure searchable symmetric encryption

In this section, we describe the adaptively secure SSE algorithm proposed by Curtmola etal. [19]. As the name suggests, the scheme is based on the symmetric key encryption setting and therefore mostly suitable for a single reader/single writer scenario. It uses the index based approach [10], where user has to pre-process the contents to generate a keyword index to provide for the search capability. Figure2 shows the construction of the adaptively secure searchable symmetric encryption scheme.

As shown in Figure2, a user U encrypts a set of data D = {D1, D2, , Dn} and creates an encrypted index le I which contains a set of m encrypted keywords extracted from the data set D. In order to conduct a search over the encrypted data, user U outsources the index I and the encrypted data set D to the cloud server. During a search, U creates an encrypted query and sends it to the server. Cloud server takes this encrypted query as input and then uses the encrypted index located at the server to retrieve pointers to the

Page 6 of 16

Salam et al. Hum. Cent. Comput. Inf. Sci. (2015) 5:19

Page 7 of 16

Data Outsourcing

Cloud Server

Encrypted Data

Encrypted Index

Encrypted Query

Data Retrieval

Search over Encrypted Data

User/ Client

Figure2 Working principle of adaptively secure SSE scheme to search over encrypted data. The gure shows the workow of the searchable symmetric encryption scheme. This scheme generates and stores an encrypted index at the cloud server to enable search over encrypted data.

document(s) containing the searched keyword. Once the search result is obtained, the

encrypted document(s) containing the searched keyword is returned to the client.

The scheme mainly consists of six functional entities: key generation, document preprocessing, encryption, search token generation, search and decryption. Functions of each entity/ block are described as follows:

A. Key generation: It generates the keys for encryption and decryption using a symmetric key primitive. Two keys K1 and K2 are generated for encryption of index contents and documents respectively. Both keys are generated and stored securely at the user device. Note that this is a symmetric key primitive and therefore same key is used for both encryption or decryption purposes.

B. Document re-processing: This block provides the necessary function to pre-process a set of documents and initialize the encryption procedure. Before encrypting the set of documents, the user needs to pre-process the document set to pull out the keyword and build an index. Let D denes a set of document to be encrypted and uploaded in the cloud server. The user has to list out all the keywords from each document in D and build an index table listing the documents and the corresponding keywords. The scheme will also assign a content ID for each of the documents in the set. For example, consider a set of 5 documents D = {D1, D2, D3, D4, D5} to be uploaded in the cloud. At the pre-processing step, the user will pre-process these set of documents to build an index table as shown in Table1. Here, wi (i = 1, 2, 3, , m)

Salam et al. Hum. Cent. Comput. Inf. Sci. (2015) 5:19

Table 1 Document index creation

Content/ document Content ID Keyword

D1 1 w1, w5

D2 2 w1, w3, w8 D3 3 w2, w9, w5

D4 4 w6, w7, w9 D5 5 w1, w4, w10

represents the keyword and m is the total number (m = 10 for this example) of keywords. The content IDs are assigned sequentially starting from 1. In the next step, it will create an inverted index table which lists out the respective content IDs for each keyword wi. For the above example, the inverted index is shown in Table2. C. Encryption: This block provides the functionality to encrypt the index and document set. The encryption is performed using the encryption keys generated at the key generation step. Basically, it consists of index encryption and document encryptions and performs as described below: Index encryption This encrypts the keyword set generated at the pre-processing step and creates an encrypted index/lookup table. The keyword encryption is computed as ENCK1(wi||ni), where ENCK1 represents encryption with key K1, wi is the keyword i and ni is the corresponding document ID containing keyword wi. For each of the encrypted keywords, the encrypted index table lists out the corresponding document ID. For our example document set, the encrypted index table is shown in Table3. Document encryption: This encrypts each document from the document set D with key K2, and stores it in the database. The document encryption is computed as ENCK2(Di) which represents encryption of document Di with key

K2. For the above example, the encrypted document lists are shown in Table4. D. Search token generation: This block is used when a user wants to search for a document containing a certain keyword. It provides the user/client with the functionality of generating a search token/ trapdoor which can be used at the server to perform a search over encrypted documents. To carry out the search operation, the user will input the search keyword and then compute the search token. The search token for a keyword wq is computed as follows: Search Token, t = (t1, t2, , tn) = ENCK1[notdef]wq||1, ENCK1[notdef]wq||2, , ENCK1[notdef]wq||n, where n is

Table 2 Inverted index

Keyword Content ID

w1 1, 2, 5 w2 3

w3 2

w4 5

w5 1, 3 w6 4

w7 4

w8 2

w9 3, 4 w10 5

Page 8 of 16

Salam et al. Hum. Cent. Comput. Inf. Sci. (2015) 5:19

Table 3 Encrypted index

Encrypted keyword Content ID

ENCK1(w1||1) 1

ENCK1(w1||2) 2

ENCK1(w1||5) 5

ENCK1(w2||3) 3

ENCK1(w3||2) 2

ENCK1(w4||5) 5

ENCK1(w5||1) 1

ENCK1(w5||3) 3

ENCK1(w6||4) 4

ENCK1(w7||4) 4

ENCK1(w8||2) 2

ENCK1(w9||3) 3

ENCK1(w9||4) 4

ENCK1(w10||5) 5

Table 4 Encrypted document list

Content ID Encrypted Document

1 ENCK2(D1)

2 ENCK2(D2)

3 ENCK2(D3)

4 ENCK2(D4)

5 ENCK2(D5)

the total number of documents in the document set D. For our example of 5 document sets, the search token for keyword wq will be t = (t1, t2, t3, t4, t5). Once computed, the search token is sent to the server to nd out the corresponding document containing the searched keyword.E. Search: The search function takes the search token and the encrypted index table as input and outputs the document list containing the searched keyword. For a search token t = (t1, t2, , tn) it will compare with the encrypted index if any of the values in t matches with the encrypted keyword. It outputs the corresponding document IDs which match the search token and then send back the respective documents to the client.

F. Decryption: The client decrypts back the document once it has obtained the encrypted document set containing the searched keyword. The document decryption is computed as DECK2(Di) which represents decryption of document Di with key K2.

Implementation ofPrivCloud system

This section provides the detailed description for our implementation of the adaptively secure SSE scheme, aka PrivCloud. This implementation considers a single writer/ single

Page 9 of 16

Salam et al. Hum. Cent. Comput. Inf. Sci. (2015) 5:19

reader scenario where the user that searches over the data is also the one who generates it. First of all, we provide the basic framework for our implementation.

Framework ofthe PrivCloud system

The PrivCloud system implements the SSE-2 scheme [19] which consists of the following modules: encryption, search and decryption. These modules are integrated with a Key Generator block which provides the encryption/ decryption keys.

A. Encryption: This module provides the document and index encryption functionality. Figure3 shows the framework for the implementation of theSSE-2 Encryption module. First, the key generator is initiated to generate keys. Since symmetric key generation does not require much computational power, we assume that the key generator is located at the user device. This resolves the key distribution issue. The key generation is a one-time process to generate and store the keys. After the key generation, a user inputs a set of document for the encryption and index creation. When user inputs the document set, the Encryption module uses the Keyword Extractor block to pull out the keyword and builds an index of all the words in the document. After keyword extraction, input documents and the document index are fetched to the Encryption block. The Encryption block uses the keys generated by the key generator to create the encrypted document set and encrypted document index. Concurrently, theEncryption block also creates a lename mapping object/ lename index which contains the mapping of document IDs to the corresponding original lenames and extensions. This is stored in plaintext at the user device. Finally, the encrypted les are uploaded to the server.

B. Search: The search module provides the functionality of searching a keyword over the encrypted data stored at the cloud server. Figure 4 shows the framework for the implementation of the SSE-2 search module. When user inputs the searched

Page 10 of 16

KEY

GENERATOR

Generate and store keys

Keyword Extractor

Convert into .txt file and pull out the keywords for Index creation

Input Doc

Doc 1 Doc 2

Doc n

.

Encrypted Doc 1

Encrypted Doc 2

.

USER

Encryption

Encrypted Doc n

CLOUD SERVER

Keys for Document and

Index Encryption

Encrypted Index

Return and Store the Filename Mapping Object at the User

Figure3 Encryption module. The gure shows the working principle of dierent blocks in the encryption module of the PrivCloud system. The encryption module provides the document and index encryption functionality.

Salam et al. Hum. Cent. Comput. Inf. Sci. (2015) 5:19

Page 11 of 16

Search

Searched Token(s)

Return Document ID(s) Containing Searched Keyword

Searched Keyword(s)

USER

Search Token Generation

Searched Token(s)

CLOUD SERVER

Index/ Keyword Encryption Key

Search Module

Return Corresponding Encrypted Document(s) and Document ID(s) Containing Searched Result

Figure4 Search module. The gure shows the working principle of dierent blocks in the search module of the PrivCloud system. This module enables a cloud user to generate an encrypted query to the server. The cloud server can use this encrypted query to search over the encrypted data without knowing the contents of the data or the query.

keyword(s), Search Token Generation computes a search token(s)/ trapdoor(s) using the keyword/index encryption key. This generated search token is then sent to the cloud server to perform the search operation. Upon receiving the search token, the cloud server nd out pointer(s) to the appropriate encrypted documents by comparing the search token with the encrypted index values. Following this, the cloud server retrieves the encrypted document(s) containing the searched keyword(s) and sends it back to the client along with the corresponding document ID(s).C. Decryption: The Decryption module that is located at the users device provides the decryption functionality for a given set of encrypted documents. Figure 5 shows the basic construction for the SSE-2 Decryption module. The Decryption module requires Encrypted Document, corresponding Document ID, Document Decryption Key and Filename Mapping Object as input. First, theDecryption module uses the lename mapping object and the document ID to retrieve the original lename and extension of the encrypted document. Then it decrypts the document using the document decryption key and stores it to the user device.

Return Decrypted Document

Input Encrypted Document

Document ID

USER

Document Decryption Key

Decryption

Filename Mapping Object

Figure5 Decryption module. The gure shows the working principle of dierent blocks in the decryption module of the PrivCloud system. This module provides the decryption functionality.

Salam et al. Hum. Cent. Comput. Inf. Sci. (2015) 5:19

Implementation details

The scheme is implemented and tested under the following environment: Java 1.7.0_51 , Windows 8.1 64-bit operating system. Based on the framework, we divide our implementation into four main class structures: Key Generation, Encryption, Search and Decryption.

A. Key generation class: We use the standard javax.crypto library to generate the AES keys. Two 128-bit AES keys (i.e., keyword encryption key, K1 and document encryption key, K2) are generated and stored. The key generation class has 3 methods:

generate () : This method generates two 128-bit AES keys. store () : This method converts the generated keys (encoded) into strings, writes into a Key object and then stores it to a location at the user device.

read () : This provides the functionality to read the keys from user. The method read () takes the Key object as input and reads the key values. Following this, it will convert the key string to an array of bytes and then construct the corresponding secret key from the given byte of array.

B. Encryption class: The encryption is performed at user device before outsourcing the data to the cloud server. This creates the database containing the encrypted document set and encrypted index. Before performing encryption one needs to pre-process the data to retrieve the keyword and create an index. The SSE-2 scheme extracts only a set of distinct keywords to create an index. However, in our implementation we create an index of the whole document rather than a nite number of distinct keyword set. This gives a user the exibility to search for any words in the document rather than a selected keyword and also user does not need to keep the keyword index stored at its own device. We consider the initializing/pre-processing of documents within the Encryption block. The pre-processing step includes:

Document ID allocation: For each document, it assigns a unique document ID. The document ID will be assigned starting from 0 and will increase sequentially. Keyword extraction: The keyword extraction process searches for consecutive sequences of non-blank and non-punctuation characters. It can easily be tweaked to search for consecutive sequences of ASCII characters. This provides adequate results for binary les containing uncompressed English text. To read out the characters from an input document, we need to convert it to a text le rst and for this le conversion we have used the Apache Tika. The keyword extractor is implemented by pulling characters from stream, checking if they are acceptable, and accumulating consecutive acceptable characters into a keyword. An additional functionality is also provided where one can limit the number of total keywords by selecting a minimum length of characters in a keyword. For example, if we select the minimum keyword length to be 4 characters, then the keyword extraction algorithm will pull out only those keywords which have 4 or more ASCII characters.

Page 12 of 16

Salam et al. Hum. Cent. Comput. Inf. Sci. (2015) 5:19

After pre-processing process the encryption module outputs the encrypted les. We use AES/CBC/PKCS5 for the document and index encryption. Encryption class consists of mainly two methods: encrypt () and witeDocIDFileNameMapping ().

encrypt () : This function takes as input all the les from user given path and encrypt all the les and also creates an encrypted index. For each input le the function retrieves the keywords rst and for each keyword it computes the 128-bit AES encryption of the keyword and document ID. Then, it creates an index entry in the encrypted index table to list out the encrypted keyword and the corresponding document ID. It uses put[notdef]key, value specied in Java TreeMap interface to associate the specied value (document ID) with the specied key (encrypted keyword). Finally, it saves the encrypted index in the database. The input documents are ready for encryption once the indexing is nished. For theencryption of adocument, this method rst creates a new document in the database and writes the encrypted stream in this. For each encrypted document, the corresponding document ID is used as the new lename of the encrypted document.

writeDocIDFileNameMapping () : This method is used to create and store a le-name mapping object /lename index which stores the ID of an encrypted document and the corresponding lename. It uses hash table to map the keys (document ID) into values (lename). This object is stored at client and utilized during decryption for the mapping of document ID to retrieve original lename and extension of the document.

Figure6 shows the detail owchart of the encryption procedure.C. Search class: The search operation is initiated at the user device and performed in the cloud server. The operation consists of two methods: searchToken () and search ().

searchToken () : This takes the keyword and document ID as input and computes the search token at the client device. The keyword encryption key is used to compute the encrypted value of the user given keyword and returns the generated search token. The search token is then sent to the server.

search () : This takes place at the server when it receives a search request from the user. This method takes the search token and the user database as input to nd out the document IDs containing the search result. It uses get() dened in the Java TreeMap class, which returns the value to which the specied key is mapped, or null if this map contains no mapping for the key. Finally, server retrieves the corresponding document and sends back to the client for decryption.

D. Decryption class: This initiates the decrypt () method when the client receives the encrypted document from the server. decrypt () : This method decrypts back the data in its plaintext form by using the user decryption key stored at the client device. Once the user has input the encrypted document, the program reads the corresponding document ID from the lename of the encrypted document. Then, it uses the lename index stored at the user device and gets the original lename and extension for an encrypted document by using its ID. Then, it reads the input stream from the encrypted

Page 13 of 16

Salam et al. Hum. Cent. Comput. Inf. Sci. (2015) 5:19

Page 14 of 16

START

Run Encryption

Input Documents

Allocate Content ID for each Input

Index Encryption Document Encryption

Input = Text file?

Convert Input Document into Text File

YES

Create a Filename Mapping Object (Maps Content ID with the original

Filename and extension)

NO

Read Document Encryption Key

Read Data Stream from each Input

Document

Extract Keywords

Store at the User Device

Read Keyword Encryption Key

Compute Encrypted Output Stream for each Input Document

Compute Encrypted Index Bytes for each

Keyword

Create a New File (New Filename = content ID of the input) for each Input

Document

Create Encrypted Index Entry (Maps Encrypted Keyword and Content

ID)

Write Encrypted Output Stream in Corresponding File Created in the

Database

Save Index Values to File and store in

Database

Upload to Server

END

Figure6 Flowchart for the document and index encryption process. The gure shows the owchart of the encryption module for the PrivCloud system. It provides detail workow of the module to compute the encrypted document and encrypted index.

document and decrypts back the plaintext content using the corresponding decryption key. Lastly, this method generates a new document with the retrieved original lename and extension and then writes the decrypted plaintext stream into this le and stores it in the user device.

Conclusion

This article provides the details of our implementation of Curtmolas SSE scheme for the PrivCloud System. For our implementation, we have chosen the AES/ CBC mode for the encryption/decryption purpose. Our implementation indexes the whole document

Salam et al. Hum. Cent. Comput. Inf. Sci. (2015) 5:19

rather than a set of keyword from each document as proposed in the SSE-2 scheme, which provides the user capability to search any keyword from the document with the trade-o of a slightly larger index size. Also, the client does not need to maintain a keyword index on its side. However, the index update process is static in our implementation, which does not allow the addition of new les or updating les. On the other hand, our encryption module requires slightly longer time since this also includes the conversion of documents into text le for the keyword extraction process. A faster encryption process can be obtained if the keyword extraction module can work without the document conversion process.

Authors contributions

This work was carried out as a part of the TM R&D project: Privacy Preserving Data Storage and Retrieval System in Cloud Computing. All the authors were part of this project and contributed to this manuscript. All authors read and approved the nal manuscript.

Author details

1 Information Security Institute, Queensland University of Technology, Brisbane, Australia. 2 Faculty of Engineering, Multi media University, Cyberjaya, Selangor, Malaysia. 3 Faculty of Information Science and Technology, Multimedia University, Melaka, Malaysia. 4 Faculty of Engineering and Science, Curtin University, Miri, Sarawak, Malaysia. 5 University Malaysiaof Computer Science & Engineering, Putrajaya, Malaysia. 6 Lee Kong Chian Faculty of Engineering and Science, Universiti Tunku Abdul Rahman, Sungai Long, Selangor, Malaysia.

Acknowledgements

This research was supported by TM R&D Fund (RDTC/130827).

Compliance with ethical guidelines

Competing interests

The authors declare that they have no competing interests.

Received: 4 December 2014 Accepted: 5 July 2015

References

1. Kamara S, Lauter K (2010) Cryptographic cloud storage. In: Sion R, Curtmola R, Dietrich S, Kiayias A, Miret JM, Sako K, Seb F (eds) Financial Cryptography and Data Security, LNCS 6054. Springer, Berlin, Heidelberg, pp 1361492. Hacigms. H, Iyer B, Li C, Mehrotra S (2002) Executing sql over encrypted data in the databaseserviceprovider model. In: Proceedings of SIGMOD, ACM, pp 216227

3. Subashini S, Kavitha V (2011) A survey on security issues in service delivery models of cloud computing. J Netw Comput Appl 34:111

4. Kubiatowicz J, Bindel D, Chen Y, Czerwinski S, Eaton P, Geels D et al (2000) Oceanstore: an architecture for global scale persistent storage. In: Architectural support for programming languages and operating systems, ACM, pp 190201

5. Muthitacharoen A, Morris R, Gil TM, Chen B (2002) Ivy: a read/write peertopeer lesystem. In: Proceedings of the 5th symposium on Operating System Design and Implementation, vol. 36, pp 3144

6. Adya A, Bolosky WJ, Castro M, Cermak G, Chaiken R, Doucer JR et al (2002) Farsite: federated, available, and reliable storage for an incompletely trusted environment. In: Proceedings of the 5th Symposium on Operating systems design and implementation, vol. 36, pp 114

7. Benaloh J, Chase M, Horvitz E, Lauter K (2009) Patient controlled encryption: ensuring privacy of electronic medical records. In: Proceedings of the 2009 ACM workshop on Cloud computing security, ACM, pp 103114

8. Li M, Lou W, Ren K (2010) Data security and privacy in wireless body area networks. IEEE Wireless Communications Magazine, vol. 17, IEEE, pp 5158

9. Li M, Yu S, Ren K, Lou W (2010) Securing personal health records in cloud computing: patientcentric and ne grained data access control in multiowner settings. In: Jajodia S, Zhou J (eds) Security and Privacy in Communica tion Networks, LNCS 50. Springer, Berlin Heidelberg, pp 89106

10. Goh EJ (2003) Secure indexes. In: Cryptology ePrint Archive: Report 2003/21611. Boneh D, Crescenzo GD, Ostrovsky R, Persiano G (2004) Publickey encryption with keyword search. In: Cachin C, Camenisch JL (eds) Advances in Cryptology EUROCRYPT, LNCS 3027. Springer, Berlin Heidelberg, pp 506522

12. Boneh D, Waters B (2007) Conjunctive, subset, and range queries on encrypted data. In: Salil Vadhan P (ed) Theory of cryptography, LNCS 4392, Springer, Berlin Heidelberg, pp 535554

13. Liu Q, Wang G, Wu J (2009) An efficient privacy preserving keyword search scheme in cloud computing. In: Interna tional Conference on Computational Science and Engineering (CSE), Vol. 2, pp 715720

Page 15 of 16

Salam et al. Hum. Cent. Comput. Inf. Sci. (2015) 5:19

14. Liu Q, Wang G, Wu J (2012) Secure and privacy preserving keyword searching for cloud storage services. J Netw Comput Appl (JNCA) 35(3):927933

15. Tseng FK, Chen RJ, Lin BS (2013) iPEKS: Fast and secure cloud data retrieval from the publickey encryption with keyword search. International Conference on Trust. Security and Privacy in Computing and Communications, IEEE, pp 452458

16. Lee SH, Lee IY (2013) A secure index management scheme for providing data sharing in cloud storage. J Inform Process Syst 9(2):287300

17. Song DX, Wagner D, Perrig A (2000) Practical techniques for searches on encrypted data. In: Proceedings of the IEEE Symposium on Security and Privacy, IEEE, pp 4455

18. Chang YC, Mitzenmacher M (2005) Privacy preserving keyword searches on remote encrypted data. In: Ioannidis J, Keromytis A, Yung M (eds) Applied Cryptography and Network Security, LNCS 3531. Springer, Berlin Heidelberg, pp 442455

19. Curtmola R, Garay J, Kamara S, Ostrovsky R (2006) Searchable symmetric encryption: improved denitions and effi cient constructions. In: Proceedings of the 13th ACM conference on Computer and communications security, ACM, pp 7988

Page 16 of 16