A Secure Threshold Secret Sharing Framework for ... - IEEE Xplore

2014 IEEE International Conference on Advanced Communication Control and Computing Technologies (ICACCCT)

A Secure Threshold Secret Sharing Framework for Database Outsourcing Ajeet Ram Pathak1 ,B. Padmavathi2 1,2

Department of Computer Engineering,G. H. Raisoni College of Engineering and Management,Pune 412207, India 1 [email protected], [email protected]

Abstract— Due to advancement in cloud computing technology and significant growth in database technology, Database as a Service (DBaaS) has become the breakaway technology of the recent era. It is the paramount solution for managing and administering the outsourced databases. Though the users are availed through the database services, the security of databases being outsourced is not guaranteed as the database service provider can be deceitful. Therefore, implementing the security in outsourced databases is a grand challenge. In this paper, we have proposed a secure framework for achieving the confidentiality, integrity in outsourced databases using the customized secret sharing approach and polynomial interpolation. The completeness and correctness dimensions are considered for achieving the integrity. To the best of our findings, our framework is the first which provides security solutions to alphanumeric data, string, special symbols and any kind of database including NoSQL databases which support hash index. The multiple indexing in our research allows the user to search and process the query efficiently based on multiple searchable attributes. Keywords - Confidentiality, Completeness, Correctness, DBaaS, Integrity, NoSQL database

I.

INTRODUCTION

The large amounts of data are generated in research industries, business firms, and educational institutes. Managing, processing and analyzing Big Data using inhouse traditional data management approach is tedious and inefficient from processing point of view. Therefore, Database as a Service provides the most promising solution for managing, administering and processing data. The data owner of the company outsources data at a third party service provider’s site. By deploying necessary software and hardware tools for data management, third party provider avails the readymade and on-demand service to clients on metered usage. Though the clients are availing the database services, security of the database is of utmost important. Our approach provides the confidentiality, integrity (completeness and correctness) as the security services. The confidentiality is one of the important aspects of privacy. Data confidentiality is referred to as making the data unintelligible to prevent it from unauthorized access. The integrity is said to be provided in terms of completeness and correctness. Completeness guarantees that results obtained by retrieving all records from database mentioned in ISBN No. 978-1-4799-3914-5/14/$31.00 ©2014 IEEE

predicate of query and no any record contained in predicate is omitted.The correctness assures that results obtained from the database servers are unaltered and tamperproof. The detailed discussion of approaches used for implementing the security in outsourced databases is given in our survey paper [1]. The inherent option to provide the confidentiality and privacy is encrypting the data and then outsourcing it [2-7]. But it causes the computation overhead of encryption and decryption on the system. Also querying the encrypted database is very complex. We have put forth a lightweight Secure Threshold Secret Sharing Framework providing the confidentiality and integrity. Our framework is lightweight in the sense that no encryption mechanism is applied and hence outperforms the approaches proposed in [2-7]. We have applied the polynomial based Shamir’s secret sharing approach [8] to distribute the secret data among n entities (Data Servers) to provide confidentiality. As the secret data is held by more than one secret sharing entity, our approach is resistant to single point vulnerability. Fake tuple insertion approach is adopted in [9, 10] for providing integrity assurance. But, due to this approach, the client suffers from storage overhead of fake tuples which is against the concept of outsourcing. Our approach excels the fake tuple insertion approach in such a way that when the client fires the query, the secret value is built only when the valid shares are returned by the valid Data Server. The shares are returned only if threshold value is satisfied. This assures completeness requirement. The secret value is built only when the tamperproof shares are obtained from the Data Servers; giving us the correctness assurance. In this way, integrity is achieved considering the completeness and correctness dimensions. Our system provides faster query execution by dividing the query into two parts as SELECT and WHERE. The proposed approach supports multiple indexing and outperforms indexing techniques put forth in [11-13]. It allows creating indexes on multiple searchable attributes of the database. Due to this, the wide variety of query search option is made available for the users. A secure framework is designed to provide the security to the Big Data, namely, NoSQL databases. Our approach has an inherent capacity to protect any kind of database which supports the hash indexing. Our framework gives the security to all the data types including alphanumeric data, special symbols and strings. It best suits for the latency sensitive applications in the industries where query processing time should be as less 1642

2014 IEEE International Conference on Advanced Communication Control and Computing Technologies (ICACCCT)

as possible. The query execution time in our framework is negligible as compared to approaches in [14-16]. The contents of paper are portrayed as follows: The section II deals with system model of the proposed approach. The description of implementation details, assumptions, proposed algorithms and query processing execution flow are elaborated in section III. The example and security analysis showing the effectiveness of the proposed approach are respectively mentioned in section IV and V. The experimental evaluation of system is done in section VI. The paper is concluded in section VII. II.

SYSTEM MODEL

The system architecture of the proposed system is depicted in figure 1. The system is divided into 2 parts as the trusted site and the untrusted site. The Index Server and Data owner are considered to be present at the trusted site while service provider and clients at the untrusted site. A (k, n) threshold secret sharing scheme [8] is used in our approach to distribute the data among the Data Servers. There are 2 main phases. The first phase is data distribution phase in which the secret data is distributed among n entities. The data owner stores the searchable attributes along with the Tuple IDs in the Index Server. The OrientDB - NoSQL database is deployed on Index Server. The searchable attributes are stored as it is without any encryption in the Index Server because the Index Server is present in the trusted environment at the data owner’s site. Untrusted Site

Trusted Site

DISTRUSTFUL SERVICE PROVIDER’S SITE

INTERPRETER Encoding

DATA SERVERS

THRESHOLD VERIFIER Counting Response INDEX SERVER (OrientDB) INTERPRETER Decoding

Data Owner

Client TRUSTFUL DATA OWNER ENVIRONMENT

DISTRUSTFUL CLIENT ENVIRONMENT Untrusted Site Client Request

Trusted Site

LEGENDS

Store Shares in DS Insert Data in IS Share Retriev al Request Encode Secret Shares Returned Shares Retrieve Secret Share Decode shares and get result

Figure 1. System Architecture

The attributes used for firing the query against the database are called as searchable attributes. To support all

the alphanumeric data, we have implemented an Interpreter to encode the data before applying polynomial function and decode the data after Lagrange’s Interpolation. The encoded secret values are placed into n number of Data Servers after polynomial encoding. The second phase is Query Evaluation phase in which client fires the query against the Index Server. After receiving this request from client, the query is divided into SELECT and WHERE parts. The Index Server analyses the query and sends the selected Tuple IDs satisfying the query to Data Servers for retrieving the corresponding shares. The Data Servers return the shares. The response of the Data Servers is calculated in terms of the obtained shares. If k Data Servers responds out of n; then from the retrieved shares, the secret value is calculated using the Lagrange’s Interpolation. This processing is done in Threshold Verifier of the system architecture. Then result obtained via Lagrange’s Interpolation is decoded and the secret value is retrieved using an Interpreter. The beauty of our approach is that even if the sniffer gets an access to the transmission link between trusted and untrusted site, he will not be able to trace out the secret values due to n-Tuple ID scheme (explained in further section) implemented in our system. III.

DETAILED DISCUSSION OF THE PROPOSED SECURE FRAMEWORK

This section deals with the detailed discussion of major components in the secure framework, assumptions, design of proposed algorithms and query processing flow. A. Major components in framework The functionalities of Index Server, Data Server, Threshold Verifier and the Interpreter are explained here. 1) Index Server The OrintDB database is deployed on the Index Server. To the best of our findings, most of the times Index Servers are maintained over the numerical value in encrypted format for providing the security. But in our approach, searchable attributes are stored in Index Server at trusted data owner’s site, so we have not applied any encryption technique to encrypt the values stored in the Index Server. OrientDB supports multiple indexing, so any data type like numerals, strings can be used as searchable attribute. OrientDB is a NoSQL Document Database and it handles the relationships using Graph DB. The disjoint tree is created over the searchable attributes in the Index Server and all the nodes are searchable by the hash index. The fast retrieval and storage of nodes in a persistent manner makes the system performance efficient. In case of OrientDB which is modeled as Graph DB, all the queries have equal time complexity for insert, update and delete operations. It outperforms the B+ tree approach. In B+ tree approach, SELECT query execution is fast but insert, delete and update operations are slow. The Index Server is implemented using n-Tuple ID scheme which works as follows; n being number of Data 1643

2014 IEEE International Conference on Advanced Communication Control and Computing Technologies (ICACCCT)

Servers. Initially, a unique Tuple ID is created for each record in database. Then for each of these Tuple IDs (TID), a set of n-sub identifiers as {tid1, tid2, tidn} are created. These sub-tuple IDs are stored in Index Server along with searchable attributes (SA). The sub-tuple IDs (tids) are also maintained over all n Data Servers for record. In this way, data Servers maintain sub-tuple IDs {tid1, tid2, ..,tidn} instead of single Tuple ID. Hence, each Data Server has different sub-tuple IDs for same record. So when sub-tuple IDs are transmitted from Index Server to Data Server, even if a sniffer gets an access to these tid, he can’t obtain actual values from tids. This scheme makes approach secure and faster since only data owner knows which Tuple IDs belong to which set of tids and also their location in respective Data Servers. 2) Data Server For maintaining the privacy and confidentiality of data, a customized (k, n) threshold secret sharing scheme is used [8]. A separate set of n-sub identifiers as {tid1, tid2,..,tidn} are maintained in each Data Server as discussed in previous section. In this, we have taken n=3, k=2. Here, data owner chooses n-ary vector X = {x1, x2,…, xn} and maintain it concealed from deceitful service provider and untrusted client. For distributing a secret value v, a polynomial P(x) is created by data owner given in equation (1) as
                The coefficients ak-1, ak-2,…, a1 in polynomial are random numbers. Data owner calculates the share of each Data Server as sharei = P(xi) where i ≤ n. If a client gets sharei from at least k Data Servers out of n i.e. if threshold is satisfied then only the secret value, vs is retrieved using Lagrange’s Interpolation in equation (2).    ! "  # ) (           "  # (  #$ , $

 ' #&

*

B. Assumptions •

• •

•

The service provider and client are distrustful while the data owner is considered as the trustful entity. Index Server is assumed to be fully secured as it is residing at the trustful data owner’s site. The transmission link between trusted and untrusted site is maintained secure. According to secret sharing scheme, we assumed n=3 and k=2 i.e. secret value is shared among 3 Data Servers. Secret value is calculated by Interpolation only if response comes from at least 2 entities. If the correct share is not obtained from the Data Servers then secret value vs will not be computed.

C. Algorithm Design We have designed two algorithms. The secret share distribution algorithm is used for distributing the secret values among Data Servers while secret share evaluation algorithm is used for calculating secret shares when the client fires the query. 1) Secret Share Distribution Algorithm The Secret Share Distribution algorithm as given in Algorithm 1 takes the secret value as an input and distributes it among n Data Servers which are the secret sharing entities. The threshold parameters are initialized first (Step 1 and Step 2). The index variable is assigned a value 1 (Step 3). For each record the unique Tuple ID is generated (Step 6). Then for each Data Server, the unique sub-tuple IDs are generated as {tidi1, tidi2,..tidin} (Step 7). The Tuple IDs of all the records, respective sub-tuple IDs (tids) and the searchable attributes SA are inserted into Index Server (Step 10). The Index Server is kept unencrypted at data Owner’s site. The data owner selects n-ary vector X and keeps it concealed from service provider (Step 12). Agorithm: Secret Share Distribution Algorithm Input: SA, sa, v, p, TID, tid, DS, IS, n, k SA – Searchable attributes, v – Original Secret value to be shared among t servers, p – Total number of records, DS – Data Server, IS – Index Server, TID – Set of Tuple IDs, tid –Sub-identifiers being used by each Data Servers, n – Number of Data Servers, k – Threshold value Output: Distributed Secret Shares on n Data Servers 1. n ← 3; // Initialize number of secret sharing entities 2. k ← 2; // Initialize threshold value in secret sharing 3. i ← 1; // Initialize index variable 4. for i ← 1 to p do 5. for j ← 1 to n 6. TIDi ← GenerateUniqueIdentifier(); 7. {tidi1,tidi2,..tidin}←GenarateSubIdentifier(TIDi); 8. end 9. end 10. IS ← Insert (TIDi , {tidi1, tidi2,..tidin}, SA) ; 11. for i ← 1 to n do 12. X ← SelectVector(xi); 13. end 14. X ← {x1, x2,…, xn}; // n-ary vector kept as secret 15. for each xi € X 16. P(xi) ← CreatePolynomial(); 17. sharei ← P(xi) with respect to 1 ≤ i ≤ n; 18. end 19. for i ← 1 to n do 20. DSi ← Insert(sharei,{tidi1, tidi2,..tidin}); 21. end Algorithm 1. Secret Share Distribution Algorithm

1644

2014 IEEE International Conference on Advanced Communication Control and Computing Technologies (ICACCCT)

Algorithm: Secret Share Evaluation Algorithm Input: Q, SA_R, m, TID, tid, DS, IS, n, k Q- Query containing the searchable attribute (predicate) SA_R – Retrieved Searchable Attributes present in query m – Total number of retrieved records obtained from query, TID – Set of Tuple IDs, tid – Sub-tuple ID being used by Data Servers, DS – Data Server, IS – Index Server, n – Number of Data Servers, k – Threshold value Output: Secret Share - vs 1. flag ← 0; // Initialize the response of Data Servers 2. n ← 3; k ← 2; // Initialize variables in secret sharing 3. i ← 1; // Initialize index variable 4. ValidQuery(Q); 5. if (ValidQuery() = = true) then 6. {tid, m} ← AnalyzeQuery(); 7. for i ← 1 to m 8. for j ← 1 to n 9. for each DS 10. if (tidij = = tid) then 11. sharej ← RetrieveShare(tidij); 12. flag ++; 13. end 14. else 15. flag ← flag; 16. end 17. end 18. end 19. end 20. if (flag ≥ k) then 21. vs ← CalculateSecretByInterpolation(); 22. return (vs); 23. end 24. else 25. NoShareSecret(); 26. end 27. end 28. else 29. InvalidQuery(); 30. end Algorithm 2. Secret Share Evaluation Algorithm

D. Query Processing The query processing overview is shown in figure 2. The client first fires the query against the database (Step 1). The query is then validated. The query is analyzed (Step 2.1). If query is invalid, then client is notified about it (Step 2.2). QUERY EXECUTION SCENARIO

Untrusted Service Provider

Untrusted Client

1. Fires the Query

Share1 tid1

Data Server 1

6. Secret Value Client

Share2 Data Server 2

tid2 4. DS’s Shares

Sharen Data Server n

Trusted Data Owner

tidn

2.2 Invalid Query Valid Query? No

5.2 Rejection of Shares

2) Secret Share Evaluation Algorithm The Algorithm 2 depicts the design of Secret Share Evaluation Algorithm.

It takes the query as an input and evaluates the secret value as vs. When the client fires the query against the database, the query is accepted by the Index Server. The query is validated first (Step 2). If the searchable attributes mentioned in the query are available in the Index Server, then only the query is said to be valid. If the query is not valid, then respective invalid query message is sent to the client (Step 29). The valid query is analyzed to get the respective sub-tuple IDs (tids) (Step 6). The retrieved subtuple IDs (tids) are matched with the sub-tuple IDs (tids) in the Data Servers (step 10), then shares are retrieved with respective to the corresponding tids from the Data Servers (Step 11). As the sub-tuple IDs gets matched, it is considered as response from Data Servers and so the flag is incremented (Step 12). Otherwise, flag value remains same in case of no response from Data Servers (Step 15). If the response from the Data Servers satisfies the threshold condition, the secret share is calculated by using Lagrange’s Interpolation (Step 21) and returned to the client (Step 22); else the secret is not revealed (Step 25).

Yes 2.1 Analyze Query Divide query into two parts

Threshold Verification of Shares?

WHERE

5.1 Acceptance of Shares

The polynomial is generated for each secret value using the equation (1) and selected n-ary vector X (Step 16). This generated polynomial in terms of secret value is called as the secret share. These polynomials are assigned to sharei for 1 ≤ i ≤ n (Step 17). These sharei along with the sub-tuple IDs (tids) are stored on n Data Servers (Step 20). In this way, the secret share is distributed among n Data Servers.

Index Server

Calculate Secret Share By Interpolation

SELECT

Decode result and retrieve Secret Value 3. sub-Tuple IDs (tids)

Figure 2. Query Execution Flow

1645

2014 IEEE International Conference on Advanced Communication Control and Computing Technologies (ICACCCT)

The valid query is divided into two parts namely, SELECT and WHERE. WHERE is used for retrieving the respective Tuple IDs (sub-tuple IDs) from Index Server. Through SELECT query, the request along with the subtuple IDs is sent to the Data Servers for retrieving the respective shares (Step 3). The Data Servers respond by returning the shares (Step 4). If the number of responses from the Data Servers satisfies the threshold then secret share is calculated by equation (2) (Step 5.1). After decoding, the secret value is returned to the client (Step 6). If the threshold is not satisfied, then secret share is not revealed (Step 5.2). IV.

EXAMPLE

The simple student relation is shown in table I with the searchable attributes age and stipend. Here, for example, we are considering the login name as the secret value. To store the Tuple IDs, set of sub-tuple IDs and searchable attributes in the Index Server, the n-Tuple ID scheme is used for Index Server as shown in table II. Here, we have used (k, n) threshold secret sharing scheme to distribute the data. As our approach supports all kinds of data types, the data is encoded first by ASCII (American Standard Code for Information Interchange) conversion. For the sake of simplicity, in this example, we have assumed the values obtained after encoding. A Polynomial Scheme is applied to distribute the secret. We have assumed n=3 and k=2. An nary vector X is chosen as X={x1=2, x2=1, x3=3} and the coefficients are selected as any random number. Suppose a client submits the following query consisting of multiple searchable attributes Age and Stipend. “SELECT Login Name from Student WHERE Age = 29 AND Stipend = 2000” Initially, the query is validated. The valid query is divided into two parts as WHERE and SELECT. WHERE gets executed in Index Server to get the sub-tuple IDs. TABLE I THE STUDENT RELATION TupleID 1 2 3 4 5

Set of Sub-TupleIDs for each Data Server {11, 12, 13} {14, 15, 16} {17, 18, 19} {20, 21, 22} {23, 24, 25}

Age

Stipend

23 29 28 21 29

1500 2000 1800 5000 1800

TABLE II Age 23 29 28 21 29

11 14 17 20 23

Stipend 1500 2000 1800 5000 1800

Secret Shares 108 204 306 402 518

Data Server 1 tids Secret Shares John44

Encoded Secret Shares 100.0

P(x)

4xi+100

12 15 18 21 24

Secret Shares 104 202 303 401 509

Mack11

200.0

2xi+200

Ram@12

300.0

3xi+300

Jake$15

400.0

xi+400

Data Server 2

Pitter11

500.0

9xi+500

tids 13 16 19 22 25

Secret Shares 112 206 309 403 527

Data Server 3 Figure 3. Distribution of Secret among 3 Data Servers

Index Server returns tids as {14, 15, 16} for query. The second part is executed as SELECT tids {14, 15, 16} from Data Servers 1, 2 and 3 respectively shown in figure 3. Then Data Servers return the encoded and encrypted value of shares for given tids as (204, 202, 206). Suppose we consider the returned shares from the Data Server 1 and Data Server 2 as 204 and 202 respectively. The secret value vs is obtained using the equation (2) as +,  204

0"1 0"2  202  200 2"1 1"2

Now, after decoding the obtained secret value vs using an interpreter, we get the actual value as “Mack11”. V.

N-TUPLE ID SCHEME FOR INDEX SERVERS

Login Name John44 Mack11 Ram@12 Jake$15 Pitter11

tids

SECURITY ANALYSIS

Confidentiality is achieved by distributing the secret data among the Data Servers using secret sharing scheme. The confidentiality at Index Server is achieved as it is maintained at the trusted data owner’s site. Integrity is achieved in terms of completeness and correctness. When the client has at least k shares retrieved from the k number of Data Servers, the threshold condition in secret sharing scheme is satisfied. The satisfaction of threshold condition implies the fulfillment of completeness requirement. In case of colluding Data Servers, even if the completeness is achieved; the further calculation of secret share will not be done if the shares returned by Data Servers are false. In this case, the secret would not be constructed from Interpolation formula even though the completeness is achieved.

1646

2014 IEEE International Conference on Advanced Communication Control and Computing Technologies (ICACCCT)

This implies that the user will get the actual secret value using Lagrange’s Interpolation only when the shares returned by Data Servers are correct. This assures the correctness. In this way, we can say that our approach not only provides collusion-resistance against distrustful Data Servers but also provides security requirements like confidentiality and integrity. As secret is held by more than entity, our approach is resistant to Single point vulnerability. Due to proposed n-Tuple ID scheme; even if the hacker gets an access to transmission link and get the sub-tuple IDs, he can’t detect which Tuple ID belongs to which Data Server. To make system more robust in terms of security, order of transmitted Tuple IDs can also be changed. VI.

EXPERIMENTAL EVALUATION

The system is developed in Java with Java Development Kit 1.7 [17]. The system is executed and evaluated on 64-bit Ubuntu machine with Intel i5 core processor. The Index Server is deployed using the OrientDB database of version 1.7 [18] for maintaining the references to the data. The NoSQL database – MongoDB of version 2.11.2 [19] is deployed on Data Servers.

The communication between client and Index Server is done through Hyper Text Transfer Protocol (HTTP) while the communication between service provider and client as well as service provider and admin is governed by Transmission Control Protocol (TCP). We have evaluated the system’s performance with an average Internet connection bandwidth for accessing the database deployed on cloud. We are measuring performance in term of query execution time. We have selected the four types of query for evaluation as an example The examples of query are 1) (EQUAL QUERY) Single Query Execution Single_= “SELECT Login Name from Student WHERE Age = 23” 2) (EQUAL OR QUERY) OR Query Execution OR_= “Login Name from Student WHERE Age = 28 OR Stipend = 2000” 3) (RANGE QUERY) Range Query Execution OR_>_< “SELECT Login Name from Student WHERE Age < 23 OR Stipend > 4000” 4) (SINGLE QUERY) Single_> “SELECT Login Name from Student WHERE Age > 28”

TABLE III COMPARISON BETWEEN DIFFERENT QUERY TYPES Label

Samples

Avg

Median

90% Line

Min

Max

Throughput

single_=

28

1533

1734

1827

882

3571

0.167601444

or_=

28

1517

1733

1927

247

3161

0.169168957

or_>_


27

1464

1726

1832

911

1903

0.171006213

TOTAL

110

1510

1734

1927

247

3571

0.657442548

Figure 4. Response Time Graph

1647

2014 IEEE International Conference on Advanced Communication Control and Computing Technologies (ICACCCT)

Figure 5. Aggregate Graph

Table III shows statistical comparison between execution time of each of the different queries when executed on our secure framework. The respective queries are executed for the number of samples times mentioned in the table III. The Average refers to average time of a set of results. The Median is the time in the middle of a set of results. 50% of the samples took no more than this time; the remainder took at least as long. 90% Line shows 90% of the samples took no more than this time. The remaining samples require at least as long as this (90th percentile). Min represents the shortest time for the samples with the same label. Max is given for the longest time of the samples with the same label. Throughput represents the ratio of number of samples and the response time of each sample. It is measured as the transactions completed per milliseconds in our framework. The response time for execution of query is plotted in figure 4 showing execution time in milliseconds versus HTTP Request. The aggregate graph for the execution of four different queries is shown in figure 5. 90% of query execution takes no more than 1.8 seconds of time for Equal Query, 1.9 seconds for both the OR Query and Range Query, and 1.8 for Single Query. The minimum time required for Equal, OR, range and single query for executing in our secure framework is 0.882, 0.247, 0.889, 0.911 seconds respectively. The system performance with respect to query execution time for each of these queries is on par with each other. By storing Index server in cache memory and using the Internet connection of high bandwidth, the I/O cost can be reduced and hence the system performance can be drastically improved. In this way, we have proposed a practical and secure approach for Database Outsourcing with improved performance based on Secure Threshold Secret Sharing Scheme using proposed n-Tuple ID scheme.

VII. CONCLUSION AND FUTURE SCOPE DBaaS is the breakaway technology of recent era. It is the most promising solution to alleviate the limitations of in-house database management method at a lesser cost. We put forth an efficient approach to implement security in outsourced databases. A customized secret sharing approach and interpolation are used to maintain the privacy and confidentiality of outsourced databases. As the encryption is not applied in our framework so our approach outperforms other encryption-based approaches by providing the fast execution, good scalability. The approach provides the security to any kind of database which support hash index. The future scope is providing the security in multiple data owner scenario and to provide access control policies in multi-user environment. The solutions alleviating the need of encryption can be discovered. REFERENCES [1] Ajeet Ram Pathak, B. Padmavathi, “Analysis of Security Techniques Applied in Database Outsourcing”, In Proc. of International Journal of Computer Science and Information Technologies, Vol. 5 (1) , 2014, pp. 665-670.

[2] H. Hacigumus, B. Iyer and S. Mehrotra, “Providing database as a service,” In Proc. of IEEE 18th ICDE, 2002, pp. 29-38.

[3] Zheng-Fei Wang, Ai-Guo Tang, “Implementation of Encrypted Data for Outsourced Database”, In Proc. of Second International Conference on Computational Intelligence and Natural Computing (CINC), IEEE, 2010, pp. 150-153.

[4] V. Ciriani, S. D. Vimercati, S. Foresti, and S. Jajodia, “Combining Fragmentation and Encryption to Protect Privacy in Data Storage,” In Proc. of TISSEC, vol. 13, pp. 1094-9224, 2010.

[5] R. Agrawal, J. Kiernan, R. Srikant, and Y. Xu. Order preserving encryption for numeric data. In Proc. of ACM SIGMOD international conference on Management of data, pp. 563–574, 2004.

1648

2014 IEEE International Conference on Advanced Communication Control and Computing Technologies (ICACCCT)

[6] A. Boldyreva, N. Chenette, Y. Lee, and A. O’Neill. Order-preserving symmetric encryption. In Proc. of the 28th Annual International Conference on Advances in Cryptology, EUROCRYPT ’09, pages 224–241, 2009.

[7] Dongxi Liu, Shenlu Wang, “Programmable Order-Preserving Secure Index for Encrypted Database Query” In Proc. of 2012 IEEE Fifth International Conference on Cloud Computing, pp. 502-509, 2012.

[8] A. Shamir. “How to share a secret” In Communications of the ACM, 1979, pp. 612–613.

[9] M. Xie, H. Wang, J. Yin, and X. Meng, “Integrity auditing of outsourced data,” VLDB 2007, pp. 782-793.

[10] P. Ghazizadeh, R. Mukkamala S. Olariu, “Data Integrity Evaluation in Cloud Database-as-a-Service”, In Proceedings of IEEE Ninth World Congress on Services, 2013, pp. 280-285.

[11] Chung-Min Chen, Andrzej Cichocki, Allen McIntosh, Euthimios Panagos, “Privacy-Protecting Index for Outsourced Databases”, In Proc. of ICDE Workshops, 2013, pp. 83-87.

[12] Li Feifei, Marios H, George K, “Dynamic Authenticated Index Structures for Outsourced Database” In Proc. of ACM SIGMOD’06. Chicago, Illinois, 2006, pp. 121-132.

[13] Viet Hung Nguyen, Tran Khanh Dang, Nguyen Thanh Son , Josef Küng, “Query Assurance Verification for Dynamic Outsourced XML Databases”, In Proc. of Second International Conference on Availability, Reliability and Security (ARES'07), 2007, pp. 689- 696.

[14] D. Agrawal, A. El Abbadi, F. Emekci, A. Metwally. g“Database management as a service: challenges and opportunities” In Proc. of IEEE International Conference on Data Engineering (ICDE’09). IEEE Computer Society, 2009, pp. 1709-1716.

[15] M. N. Mohammad Ali Hadavi, Rasool Jalili, “Secure Data Outsourcing Based on Threshold Secret Sharing: Towards a More Practical Solution,” In Proc. of PhD Workshop at VLDB 2010, Singapore, 2010, pp. 54-59.

[16] M. A. Hadavi, M. Noferesti, R. Jalili, E. Damiani “Database as a Service: Towards a Unified Solution for Security Requirements” In Proceedings of IEEE 36th International Conference on Computer Software and Applications Workshops, pp. 415-420, 2012.

[17] (Accessed on 10th September 2013) Java Development Kit 7. [Online]. Available:http://www.oracle.com/technetwork/java/javase/downloads /jdk7-downloads-1880260.html

[18] (Accessed on 25th October 2013) OrientDB 1.7-rc1 Community Edition. [Online]. Available: http

[19] (Accessed on 20th October 2013) MongoDB. [Online]. Available: www.mongodb.org/

1649