Handling Confidential Data on the Untrusted Cloud: An Agent-based Approach

Cloud computing allows shared computer and storage facilities to be used by a multitude of clients. While cloud management is centralized, the information resides in the cloud and information sharing can be implemented via off-the-shelf techniques for multiuser databases. Users, however, are very diffident for not having full control over their sensitive data. Untrusted database-as-a-server techniques are neither readily extendable to the cloud environment nor easily understandable by non-technical users. To solve this problem, we present an approach where agents share reserved data in a secure manner by the use of simple grant-and-revoke permissions on shared data.Comment: 7 pages, 9 figures, Cloud Computing 201

CryptDB: A Practical Encrypted Relational DBMS

CryptDB is a DBMS that provides provable and practical privacy in the face of a compromised database server or curious database administrators. CryptDB works by executing SQL queries over encrypted data. At its core are three novel ideas: an SQL-aware encryption strategy that maps SQL operations to encryption schemes, adjustable query-based encryption which allows CryptDB to adjust the encryption level of each data item based on user queries, and onion encryption to efficiently change data encryption levels. CryptDB only empowers the server to execute queries that the users requested, and achieves maximum privacy given the mix of queries issued by the users. The database server fully evaluates queries on encrypted data and sends the result back to the client for final decryption; client machines do not perform any query processing and client-side applications run unchanged. Our evaluation shows that CryptDB has modest overhead: on the TPC-C benchmark on Postgres, CryptDB reduces throughput by 27% compared to regular Postgres. Importantly, CryptDB does not change the innards of existing DBMSs: we realized the implementation of CryptDB using client-side query rewriting/encrypting, user-defined functions, and server-side tables for public key information. As such, CryptDB is portable; porting CryptDB to MySQL required changing 86 lines of code, mostly at the connectivity layer

iPrivacy: a Distributed Approach to Privacy on the Cloud

The increasing adoption of Cloud storage poses a number of privacy issues. Users wish to preserve full control over their sensitive data and cannot accept that it to be accessible by the remote storage provider. Previous research was made on techniques to protect data stored on untrusted servers; however we argue that the cloud architecture presents a number of open issues. To handle them, we present an approach where confidential data is stored in a highly distributed database, partly located on the cloud and partly on the clients. Data is shared in a secure manner using a simple grant-and-revoke permission of shared data and we have developed a system test implementation, using an in-memory RDBMS with row-level data encryption for fine-grained data access controlComment: 13 pages, International Journal on Advances in Security 2011 vol.4 no 3 & 4. arXiv admin note: substantial text overlap with arXiv:1012.0759, arXiv:1109.355

ANEW TECHNIQUE BY USING INVERTED TABLES AND 3D BOX FOR EFFICIENT QUERYING OVER AN ENCRYPTED DATABASE

The increase in the amount of data in encrypted databases has caused problems in data processing and retrieval time. In traditional query processing methods, there are many difficulties in execute query over an encrypted database because it is time- consuming. In this paper, proposes technique for querying encrypted databases records, allows authorized users to execute queries without decrypting all the records of the encrypted database. In this technique, inverted tables include the numbers of 3D box cover locations that were created to enhance and speed up the retrieval time of query and improve an approach of data embedding according to the random 3D box. The proposed method has been examined on the Iraqi voter encrypted Database. The retrieval time in (second, millisecond) has been computed for the traditional method of query processing and proposed technique that using inverted tables. The retrieval time of query executing of proposed techniques without retrieval of all the records of the encrypted database is 10.870 (seconds, millisecond) where the retrieval time of query executing of conventional method that’s retrieval of all the records of the encrypted database is 40.682 (seconds, millisecond)

Using secret sharing for searching in encrypted data

When outsourcing data to an untrusted database server, the data should be encrypted. When using thin clients or low-bandwidth networks it is best to perform most of the work at the server. We present a method, inspired by secure multi-party computation, to search efficiently in encrypted data. XML elements are translated to polynomials. A polynomial is split into two parts: a random polynomial for the client and the difference between the original polynomial and the client polynomial for the server. Since the client polynomials are generated by a random sequence generator only the seed has to be stored on the client. In a combined effort of both the server and the client a query can be evaluated without traversing the whole tree and without the server learning anything about the data or the query

SecureDBaaS Model for Accessing Encrypted Cloud Databases

Cloud computing has recently emerged being a compelling paradigm that pertains to managing and delivering services over the web. The particular prevalent problem connected with cloud is confidentiality, security, as well as reliability etc., in which how the cloud provider assures. To recognize this, a novel architecture is usually introduced that will integrates cloud database services and as well executing concurrent operations on encrypted information. Also a new homomorphic encryption algorithm will likely be incorporated to offer confidentiality as well as concurrent execution of various SQL operations. This will be the first option supporting quite a few stributed clienteles to access encrypted cloud databases. One of main thing is that it eliminates advanced proxies in between cloud user and provider. The performance on the architecture is usually lculated by means of theoretical and practical results which are subjected to TPC-C benchmark standard tools for a number of clients as well as network latencies

Performance study of a COTS Distributed DBMS adapted for multilevel security

Multilevel secure database management system (MLS/DBMS) products no longer enjoy direct commercial-off-the-shelf (COTS) support. Meanwhile, existing users of these MLS/DBMS products continue to rely on them to satisfy their multilevel security requirements. This calls for a new approach to developing MLS/DBMS systems, one that relies on adapting the features of existing COTS database products rather than depending on the traditional custom design products to provide continuing MLS support. We advocate fragmentation as a good basis for implementing multilevel security in the new approach because it is well supported in some current COTS database management systems. We implemented a prototype that utilises the inherent advantages of the distribution scheme in distributed databases for controlling access to single-level fragments; this is achieved by augmenting the distribution module of the host distributed DBMS with MLS code such that the clearance of the user making a request is always compared to the classification of the node containing the fragments referenced; requests to unauthorised nodes are simply dropped. The prototype we implemented was used to instrument a series of experiments to determine the relative performance of the tuple, attribute, and element level fragmentation schemes. Our experiments measured the impact on the front-end and the network when various properties of each scheme, such as the number of tuples, attributes, security levels, and the page size, were varied for a Selection and Join query. We were particularly interested in the relationship between performance degradation and changes in the quantity of these properties. The performance of each scheme was measured in terms of its response time. The response times for the element level fragmentation scheme increased as the numbers of tuples, attributes, security levels, and the page size were increased, more significantly so than when the number of tuples and attributes were increased. The response times for the attribute level fragmentation scheme was the fastest, suggesting that the performance of the attribute level scheme is superior to the tuple and element level fragmentation schemes. In the context of assurance, this research has also shown that the distribution of fragments based on security level is a more natural approach to implementing security in MLS/DBMS systems, because a multilevel database is analogous to a distributed database based on security level. Overall, our study finds that the attribute level fragmentation scheme demonstrates better performance than the tuple and element level schemes. The response times (and hence the performance) of the element level fragmentation scheme exhibited the worst performance degradation compared to the tuple and attribute level schemes