Distributed, Concurrent, and Independent Access to Encrypted Cloud Databases
Total Page:16
File Type:pdf, Size:1020Kb
IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS, VOL. 25, NO. 2, FEBRUARY 2014 437 Distributed, Concurrent, and Independent Access to Encrypted Cloud Databases Luca Ferretti, Michele Colajanni, and Mirco Marchetti Abstract—Placing critical data in the hands of a cloud provider should come with the guarantee of security and availability for data at rest, in motion, and in use. Several alternatives exist for storage services, while data confidentiality solutions for the database as a service paradigm are still immature. We propose a novel architecture that integrates cloud database services with data confidentiality and the possibility of executing concurrent operations on encrypted data. This is the first solution supporting geographically distributed clients to connect directly to an encrypted cloud database, and to execute concurrent and independent operations including those modifying the database structure. The proposed architecture has the further advantage of eliminating intermediate proxies that limit the elasticity, availability, and scalability properties that are intrinsic in cloud-based solutions. The efficacy of the proposed architecture is evaluated through theoretical analyses and extensive experimental results based on a prototype implementation subject to the TPC-C standard benchmark for different numbers of clients and network latencies. Index Terms—Cloud, security, confidentiality, SecureDBaaS, database Ç 1INTRODUCTION N a cloud context, where critical information is placed in SecureDBaaS that supports the execution of concurrent Iinfrastructures of untrusted third parties, ensuring data and independent operations to the remote encrypted confidentiality is of paramount importance [1], [2]. This database from many geographically distributed clients as requirement imposes clear data management choices: in any unencrypted DBaaS setup. To achieve these goals, original plain data must be accessible only by trusted SecureDBaaS integrates existing cryptographic schemes, parties that do not include cloud providers, intermediaries, isolation mechanisms, and novel strategies for management and Internet; in any untrusted context, data must be of encrypted metadata on the untrusted cloud database. This encrypted. Satisfying these goals has different levels of paper contains a theoretical discussion about solutions for complexity depending on the type of cloud service. There data consistency issues due to concurrent and independent are several solutions ensuring confidentiality for the storage client accesses to encrypted data. In this context, we cannot as a service paradigm (e.g., [3], [4], [5]), while guaranteeing apply fully homomorphic encryption schemes [7] because of confidentiality in the database as a service (DBaaS) paradigm their excessive computational complexity. [6] is still an open research area. In this context, we propose The SecureDBaaS architecture is tailored to cloud SecureDBaaS as the first solution that allows cloud tenants platforms and does not introduce any intermediary proxy to take full advantage of DBaaS qualities, such as or broker server between the client and the cloud availability, reliability, and elastic scalability, without provider. Eliminating any trusted intermediate server exposing unencrypted data to the cloud provider. allows SecureDBaaS to achieve the same availability, The architecture design was motivated by a threefold reliability, and elasticity levels of a cloud DBaaS. Other goal: to allow multiple, independent, and geographically proposals (e.g., [8], [9], [10], [11]) based on intermediate distributed clients to execute concurrent operations on server(s) were considered impracticable for a cloud-based encrypted data, including SQL statements that modify the solution because any proxy represents a single point of database structure; to preserve data confidentiality and failure and a system bottleneck that limits the main consistency at the client and cloud level; to eliminate any benefits (e.g., scalability, availability, and elasticity) of a intermediate server between the cloud client and the cloud database service deployed on a cloud platform. Unlike provider. The possibility of combining availability, elasti- SecureDBaaS, architectures relying on a trusted intermedi- city, and scalability of a typical cloud DBaaS with data ate proxy do not support the most typical cloud scenario confidentiality is demonstrated through a prototype of where geographically dispersed clients can concurrently issue read/write operations and data structure modifica- tions to a cloud database. The authors are with the University of Modena and Reggio Emilia, via A large set of experiments based on real cloud platforms Vignolese 905/b, Modena 41125, Italy. E-mail: {luca.ferretti, michele. colajanni, mirco.marchetti}@unimore.it. demonstrate that SecureDBaaS is immediately applicable to any DBMS because it requires no modification to the cloud Manuscript received 16 Sept. 2012; revised 14 Apr. 2013; accepted 23 May 2013; published online 30 May 2013. database services. Other studies where the proposed Recommended for acceptance by X. Li, P. McDaniel, R. Poovendran, and architecture is subject to the TPC-C standard benchmark G. Wang. for different numbers of clients and network latencies For information on obtaining reprints of this article, please send e-mail to: [email protected], and reference IEEECS Log Number TPDS-2012-09-0921. show that the performance of concurrent read and write Digital Object Identifier no. 10.1109/TPDS.2013.154. operations not modifying the SecureDBaaS database 1045-9219/14/$31.00 ß 2014 IEEE Published by the IEEE Computer Society 438 IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS, VOL. 25, NO. 2, FEBRUARY 2014 structure is comparable to that of unencrypted cloud In such a way, they prevent one cloud provider to read its database. Workloads including modifications to the data- portion of data, but information can be reconstructed by base structure are also supported by SecureDBaaS, but at colluding cloud providers. A step forward is proposed in the price of overheads that seem acceptable to achieve the [15], that makes it possible to execute range queries on data desired level of data confidentiality. The motivation of and to be robust against collusive providers. SecureDBaaS these results is that network latencies, which are typical differs from these solutions as it does not require the use of of cloud scenarios, tend to mask the performance costs of multiple cloud providers, and makes use of SQL-aware data encryption on response time. The overall conclusions encryption algorithms to support the execution of most of this paper are important because for the first time they common SQL operations on encrypted data. demonstrate the applicability of encryption to cloud SecureDBaaS relates more closely to works using en- database services in terms of feasibility and performance. cryption to protect data managed by untrusted databases. The remaining part of this paper is structured as follows: In such a case, a main issue to address is that cryptographic Section 2 compares our proposal to existing solutions techniques cannot be naı¨vely applied to standard DBaaS related to confidentiality in cloud database services. because DBMS can only execute SQL operations over Sections 3 and 4 describe the overall architecture and how plaintext data. it supports its main operations, respectively. Section 5 Some DBMS engines offer the possibility of encrypting reports some experimental evaluation achieved through the data at the filesystem level through the so-called Transpar- implemented prototype. Section 6 outlines the main results. ent Data Encryption feature [16], [17]. This feature makes it Space limitation requires us to postpone the assumed possible to build a trusted DBMS over untrusted storage. security model in Appendix A, which can be found on However, the DBMS is trusted and decrypts data before the Computer Society Digital Library at http://doi. their use. Hence, this approach is not applicable to the ieeecomputersociety.org/10.1109/TPDS.2013.154, to de- DBaaS context considered by SecureDBaas, because we scribe our solutions to concurrency and data consistency assume that the cloud provider is untrusted. problems in Appendix B, available in the online supple- Other solutions, such as [18], allow the execution of mental material, to detail the prototype architecture in operations over encrypted data. These approaches preserve Appendix C, available in the online supplemental material. data confidentiality in scenarios where the DBMS is not trusted; however, they require a modified DBMS engine and are not compatible with DBMS software (both 2RELATED WORK commercial and open source) used by cloud providers. SecureDBaaS provides several original features that differ- On the other hand, SecureDBaaS is compatible with entiate it from previous work in the field of security for standard DBMS engines, and allows tenants to build secure remote database services. cloud databases by leveraging cloud DBaaS services already available. For this reason, SecureDBaaS is more related to . It guarantees data confidentiality by allowing a [9] and [8] that preserve data confidentiality in untrusted cloud database server to execute concurrent SQL DBMSs through encryption techniques, allow the execution operations (not only read/write, but also modifica- of SQL operations over encrypted data, and are compatible tions to the database structure) over encrypted data. with common DBMS