Scalable architecture for multi-user encrypted

SQL operations on cloud database services

Abstract:
The success of the cloud database paradigm is strictly related to strong guarantees in terms of
service availability ,scalability and security, but also of data confidentiality. Any cloud provider
assures the security and availability of its platform, while the implementation of scalable
solutions to guarantee confidentiality of the information stored in cloud databases is an open
problem left to the tenant. Existing solutions address some preliminary issues through SQL
operations on encrypted data. We propose the first complete architecture that combines data
encryption, key management, authentication and authorization solutions, and that addresses the
issues related to typical threat scenarios for cloud database services. Formal models describe the
proposed solutions for enforcing access control and for guaranteeing confidentiality of data and
metadata. Experimental evaluations based on standard benchmark sand real Internet scenarios
show that the proposed architecture satisfies also scalability and performance requirements.

Existing System:

Existing proposals offer partial and separate solutions to data confidentiality and isolation. For
example, architectures supporting SQL operations on encrypted data leave access control to the
cloud provider or enforce it through an intermediate trusted server . Other proposed
architectures solve the problem of access control without the intervention of the cloud provider,
but they do not allow execution of SQL operations on encrypted data.

Proposed System:

We propose the first architecture, called Multi-User relaTional Encrypted Data Base (MuteDB),
that guarantees data confidentiality by executing SQL operations on encrypted data and by
enforcing access control policies through selective encryption methods. By combining these two
approaches MuteDB is the only solution ensuring confidentiality of data stored in the cloud.

Advantages:

Our solution works even in dynamic scenarios, in which users and access control policies change
over time, without the need to renew and redistribute user credentials. The proposed architecture
is specifically designed for cloud database scenarios where multiple users can access the cloud
database through the Internet possibly from different geographical areas.

Architecture Diagram:
Algorithm:

1. RSA algorithm
2. Diffie- hellman Algorithm
3. Symmetric key cryptography

Algorithm description:1:

RSA derives its security from the difficulty of factoring large integers that are the product of
two large prime numbers. Multiplying these two numbers is easy, but determining the
original prime numbers from the total -- factoring -- is considered infeasible due to the time it
would take even using today’s super computers.

Mathametical formula:

Encryption :

c = ENCRYPT (m) = memod n .

m = DECRYPT (c) = cd mod n .

Algorithm description:2:
Diffie-Hellman key exchange, also called exponential key exchange, is a method
of digital encryption that uses numbers raised to specific powers to produce decryption keys
on the basis of components that are never directly transmitted, making the task of a would-
be code breaker mathematically overwhelming.

To implement Diffie-Hellman, the two end users Alice and Bob, while communicating over a
channel they know to be private, mutually agree on positive whole numbers p and q, such
that p is a prime number and q is a generator of p. The generator q is a number that, when
raised to positive whole-number powers less than p, never produces the same result for any
two such whole numbers. The value of p may be large but the value of q is usually small.

Mathametical formula:

(gx mod p)y mod p = gxy mod p

(gy mod p)x mod p = gyx mod p
Implementation Modules:

1. Plaintext database model

Plaintext database model:

 Plaintext most commonly meant message text in the language of the communicating parties.
Since computers became commonly available. the original definition implied that the message
could be read by a human being, the modern definition emphasizes that a person using a
computer could easily interpret the data. Any information which the communicating parties wish
to conceal from others can now be treated, and referred to, as plaintext. Thus, in a significant
sense, plaintext is the 'normal' representation of data before any action has been taken to conceal,
compress, or 'digest' it. It need not represent text, and even if it does, the text may not be "plain".
Plaintext is used as input to an encryption algorithm; the output is usually termed ciphertext
particularly when the algorithm is a cipher. Code text is less often used, and almost always only
when the algorithm involved is actually a code. In some systems, however, multiple layers
of encryption are used, in which case the output of one encryption algorithm becomes plaintext
input for the next. The proposed plaintext database model is a poset that extends the structure
poset S, with the resources R, a structure s<S associated with a resource r< R is a parent of the
resource r (s > r).

Access control :

Access control a is way of limiting access to a system or to physical or virtual resources. In

In access control systems, users must present credentials before they can be granted access. In
physical systems, these credentials may come in many forms, but credentials that can't be
transferred provide the most security. The management of admission to system and network
resources. It grants authenticated users access to specific resources based on access policies and
the permission level assigned to the user or user group. Access control often includes
authentication, which proves the identity of the user or client machine attempting to access the
files. the MuteDB models and schemes for combining encryption and key management to
support data confidentiality and isolation in cloud data bases. After the presentation of the
models related to access control in plaintext and encrypted databases, we describe how MuteDB
transforms an access control matrix for the plaintext model to a matrix suitable for the encrypted
database, and how it generates user credentials. Let R be the set of resources that represent plain
text tenant data, S the set of plaintext database structures, E the set of encrypted tenant data, U
the set of users, and K the set of encryption keys. We define A as the access control matrix
where, for each user u P U and for each structure s P S, there exists a binary authorization rule a
that defines whether an access to s by u is denied or allowed .

Encrypted database model:

Database encryption is the process of converting data, within a database, In plaintext format into
meaningless cipher text by the means of a suitable algorithm. Database decryption is converting
the meaningless cipher text into the original information using keys generated by the encryption
angorithms. Database encryption be provided at the file or column level. Encryption of a
database is costly and requires more storage space than the original data. The steps in encrypting
a database are: Determine the criticality of the need for encryption, Determine what data needs to
be encrypted, Determine which algorithms best suit the encryption standard, Determine how the
keys will be managed. Numerous algorithms are used for encryption. These algorithms generate
keys related to the encrypted data. These keys set a link between the encryption and decryption
procedures. The encrypted data can be decrypted only by using these keys.

Encrypted data are contained in encrypted tables stored in cloud database servers. For each
plaintext table, the MuteDB DBA client generates the corresponding encrypted table and a
unique encryption key. The name of the encrypted table is computed by encrypting the name of
the plaintext table through that key. The encryption algorithm used for encrypting the table
names is a standard AES algorithm in a deterministic mode (e.g., CBC with constant
initialization vector). In such a way, only the users that know the plaintext table name and the
corresponding encryption key are able to compute the name of the encrypted table. The
deterministic scheme is preferred because it allows a correspondence between plaintext and
encrypted tables and improves the efficiency of the query translation process.

Metadata management:
Database metadata include all information allowing a Mute DB client to translate plaintext SQL
operations into operations working on the encrypted database. We describe the original solutions
adopted by Mute DB to manage metadata. Existing proposals use trusted infrastructures to store
and distribute metadata information or require database users to maintain them locally . These
schemes simplify metadata management, but they limit scalability and availability of a cloud
database service. The Mute DB alternative is to store metadata in the cloud database together
with encrypted tenant data. This approach allows each client to access metadata directly and
concurrently through standard SQL operations, thus avoiding system bottlenecks and single point
of failures at the tenant side. Metadata contain sensitive information, hence it is necessary to
store them in an encrypted form. Unlike the proposals of the same authors in which all users are
provided with the same master encryption key , Mute DB proposes a new metadata management
strategy that enforces access control policies at the encryption level, by generating a different
encryption key for each user and by ensuring that each user is able to decrypt all and only
encrypted tenant data on which he/she has legitimate access.

MuteDB:

The Mute DB DBA client, that is the application for the creation and management of the
encrypted database. All tenant database users can issue SQL operations directly to the cloud
database even from geographically distributed locations by executing a Mute DB client on their
machines. The entire set of tenant data are stored in an encrypted form in the cloud database.
Thanks to the use of SQL-aware encryption strategies, the cloud database engine can execute
queries on encrypted data without accessing any decryption keys. Even metadata that are
necessary to manage encryption strategies are considered critical information, hence Mute DB
stores them encrypted in the cloud database: the DBA and the tenant users can efficiently
retrieve metadata through standard SQL queries. We refer to the encrypted forms of tenant data
and metadata as encrypted tenant data and encrypted metadata.
Scope
Rather than run multiple database servers/VMs on the same machine, which wastes space and
system resources, each node runs a single database server. Tenants can load databases onto
servers, and databases can be partitioned for load balancing. The partitioning strategy is
workload aware, and partitions are migrated as necessary when workloads change. Workload
monitoring includes tracking resource usage, predicting combined resource requirements, and
consolidating workloads to minimize the total number of machines required while not exceeding
machine capacities. To protect user privacy, the authors briefly discuss CryptDB, which
implements adjustable security by storing only encrypted data.
FEATURES:

In personal computing devices that rely on a cloud storage environment for data backup

Until the arrival of the Diffie-Hellman key exchange and RSA algorithms, governments and
their armies were the only real users of encryption. However, Symmetric key cryptography
,Diffie-Hellman and RSA led to the broad use of encryption in the file user to upload file.

Since public-key algorithms tend to be much slower than symmetric-key algorithms, modern
systems such as TLS and SSH use a combination of the two: one party receives the other's public
key, and encrypts a small piece of data (either a symmetric key or some data used to generate it).
The remainder of the conversation uses a (typically faster) symmetric-key algorithm for
encryption.
User upload file not directly store in cloud send cloud admin it allow that time only store in
cloud and download the data.

System Configuration:-

H/W System Configuration:-

Processor - Pentium –III

Speed - 1.1 Ghz

RAM - 256 MB(min)

Floppy Drive - 1.44 MB

Key Board - Standard Windows Keyboard

Mouse - Two or Three Button Mouse

Monitor - SVGA

S/W System Configuration:-

 Operating System :Windows95/98/2000/XP

 Front End : java, jdk1.6

 Database : My sqlserver 2005

 Database Connectivity : JDBC.

CONCLUSION

In this paper we propose MuteDB, a novel architecture for cloud database services that
guarantees for the first time data confidentiality through SQL-aware encryption algorithms and
data isolation through access control enforcement based on encryption and key derivation
techniques. These solutions allow MuteDB to address threat issues that are relevant for cloud
services including risks of information leakage due to collusions between cloud provider
employees and tenant users. The most important solutions are described through formal models,
while the feasibility, performance and scalability of the proposed architecture are demonstrated
through a large set of experiments carried out through a prototype deployed in a real Internet-
based environment where cloud database services are accessed concurrently by geographically
distributed clients. All results confirm that for realistic workloads, the MuteDB architecture
achieves performance and scalability comparable to those of unencrypted cloud database
services. Ongoing work is focused on integrating private information retrieval solutions in
MuteDB with the goal of preventing information leakage caused by access pattern analyses, and
novel architectural solutions for hybrid cloud environments.