scispace - formally typeset
Search or ask a question
Journal ArticleDOI

Performance and cost evaluation of an adaptive encryption architecture for cloud databases

02 Apr 2014-Vol. 2, Iss: 2, pp 143-155
TL;DR: This work proposes a novel architecture for adaptive encryption of public cloud databases that offers an interesting alternative to the tradeoff between the required data confidentiality level and the flexibility of the cloud database structures at design time.
Abstract: The cloud database as a service is a novel paradigm that can support several Internet-based applications, but its adoption requires the solution of information confidentiality problems We propose a novel architecture for adaptive encryption of public cloud databases that offers an interesting alternative to the trade-off between the required data confidentiality level and the flexibility of the cloud database structures at design time We demonstrate the feasibility and performance of the proposed solution through a software prototype Moreover, we propose an original cost model that is oriented to the evaluation of cloud database services in plain and encrypted instances and that takes into account the variability of cloud prices and tenant workload during a medium-term period

Summary (5 min read)

1 INTRODUCTION

  • THE cloud computing paradigm is successfully converg-ing as the fifth utility [1], but this positive trend is partially limited by concerns about information confidentiality [2] and unclear costs over a medium-long term [3], [4].
  • It poses novel issues in terms of applicability to a cloud context, and doubts about storage and network costs.
  • The authors investigate each of these issues and they reach three original conclusions in terms of prototype implementation, performance evaluation, and cost evaluation.
  • This model also considers the variability of cloud prices and of the database workload during the evaluation period, and allows a tenant to observe how adaptive encryption influences the costs related to storage and network usage of a database service.

3 ARCHITECTURE DESIGN

  • The proposed system supports adaptive encryption for public cloud database services, where distributed and concurrent clients can issue direct SQL operations.
  • Fig. 1 shows a scheme of the proposed architecture where each client executes an encryption engine that manages encryption operations.
  • To improve performance, the plain metadata are cached locally by the client.
  • After obtaining the metadata, the encryption engine is able to issue encrypted SQL statements to the cloud database, and then to decrypt the results.

3.1 Adaptive Encryption Schemes

  • The authors consider SQL-aware encryption algorithms that guarantee data confidentiality and allow the cloud database engine to execute SQL operations over encrypted data.
  • It supports the sum operator between integer values.
  • This issue can be addressed through adaptive encryption schemes that support at runtime SQL operations while preserving the highest possible data confidentiality level on the encrypted data.
  • The most external layer of an onion is called actual layer, which corresponds to its strongest encryption algorithm.
  • Each onion represents a column in the encrypted database structure.

3.2 Metadata Structure

  • Metadata include all information that allows a legitimate client knowing the master key to execute SQL operations over an encrypted database.
  • They are organized and stored at table-level granularity to reduce communication overhead for retrieval, and to improve management of concurrent SQL operations [22].
  • Moreover, for each column of the original plain table they also include a set of column metadata containing the name and the data type of the corresponding plain column (e.g., integer, varchar, datetime).
  • Each set of onion metadata is associated with as many sets of layer metadata as the number of layers required by the onion type.
  • Each set of layer metadata includes an encryption key and a label identifying the corresponding encryption algorithm.

3.3.1 Database Creation

  • In the setup phase, the database administrator generates a master key, and uses it to initialize the architecture metadata.
  • The master key is then distributed to legitimate clients.
  • Table creation requires the insertion of a new row in the metadata table.
  • For each table creation, the administrator adds a column by specifying the column name, data type and confidentiality parameters.
  • These last data are the most important for this paper because they include the set of onions associated with the column, the starting layer denoting the actual layer at creation time, and the field confidentiality of each onion.

3.3.2 Execution of SQL Operations

  • When a user/application wants to execute an operation on the cloud database, the client encryption engine analyzes the SQL command structure and identifies which tables, columns and SQL operators are involved.
  • The client issues a request for the table metadata for each involved table, and decrypts the metadata with the master key.
  • Then, the client determines whether the SQL operators are supported by the actual layers of the onions associated with the involved columns.
  • The client issues this new statement called encrypted SQL operation to the cloud database which transparently executes it over encrypted data.
  • The encrypted results are decrypted using information contained in the metadata.

3.3.3 Adaptive Layer Removal

  • The adaptive layer removal is the process that dynamically removes the external layer of an onion in order to adaptively support SQL operations issued by legitimate clients.
  • Let us describe the details of the adaptive layer removal mechanism by referring to the following example.
  • If the actual layer of Onion-Ord associated with id is set to Rand, then the client dynamically invokes a stored procedure on the cloud database that removes at runtime the Rand layer of Onion-Ord of the column id, thus leaving the Ope layer exposed.
  • The client can now encrypt the SELECT query that contains the operation id < 10 and issue the encrypted query to the encrypted database, that executes it on the Ope layer of Onion-Ord.
  • The cloud database can execute the adaptive layer removal if and only if a legitimate client invokes the stored procedure and gives to it the decryption key of the most external encryption layer.

4 COST ESTIMATION OF CLOUD DATABASE SERVICES

  • This porting is a strategic decision that must evaluate confidentiality issues and related costs over a medium-long term.
  • For these reasons, the authors propose a model that includes the overhead of encryption schemes and the variability of database workload and cloud prices.
  • The proposed model is general enough to be applied to the most popular cloud database services, such as Amazon Relational Database Service [23], EnterpriseDB [24], Windows Azure SQL Database [25], and Rackspace Cloud Database [26].

4.1 Cost Model

  • Time identifies the time interval T for which the tenant requires the service.
  • Pricing refers to the prices of the cloud provider for subscription and resource usage; they typically tend to diminish during T [27].
  • Usage denotes the total amount of resources used by the tenant; it typically increases during T .
  • The authors model takes into account billing prices for all the resources considered by the main providers [28], [29], [30], [31], [32]: uptime price fphb g, storage price fpsbg and network price fpnb g.
  • It is defined as the set of uptime usage fhbg, storage usage fsbg and network usage fnbg.

4.2 Cloud Pricing Models

  • Popular cloud database providers adopt two different billing functions, that the authors call linear L and tiered T .
  • If the resource usage is lower than the first threshold (xb x̂1), then the billing function is defined as: T xb; p x b ¼ xb p̂xb;1: (5) Otherwise, the authors denote as ~xz the highest threshold that is lower than the usage xb.
  • Then the billing function can be defined as: T xb; p x b ¼ ðxb ~xzÞ p̂xb;zþ1 þ Xz 1 j¼0 ðx̂jþ1 x̂jÞ p̂xb;jþ1: (6) The uptime and the storage billing functions of AmazonRDS [23] are linear, while the network usage is a tiered billing function.
  • On the other hand, the uptime billing functions of AzureSQL [25] is linear, while the storage and network billing functions are tiered.

4.3 Usage Estimation

  • While the uptime (hb) is easily measurable, it is more difficult to estimate the usage of storage (sb) and network (nb) because they depend on the database structure, the workload and the use of encryption.
  • The authors now propose a methodology for the estimation of storage and network usage.
  • Hence the authors propose that the tenant evaluates it experimentally for a specific software configuration.
  • If the tenant does not use adaptive strategies (that is, each column is encrypted through only one SQL-aware encryption algorithm) he can estimate the storage size se and the network consumption ne of the encrypted database by replacing vpa with v e a in Equations (7) and (8).
  • To model storage and network overheads for adaptively encrypted databases, the authors define u as the ordered set of encryption algorithms that represents an onion.

5 PERFORMANCE EVALUATION

  • This section aims to verify whether the overheads of adaptive encryption represent an acceptable compromise between performance and data confidentiality for the tenants of cloud database services.
  • The TPC-C standard benchmark is used as the workload model for the database services.
  • Most SQL operations have similar costs, but in the ADAPT configuration (Fig. 8) some operations require much higher encryption times with respect to ENC (Fig. 7).
  • Hence, every insertion of a value into an integer column requires an Ope encryption, and this causes a significant increase of the overall encryption overhead.
  • As a consequence, performance of adaptive encryption for many realistic workloads fall between the ENC and ADAPT scenarios presented in this section.

6 COST EVALUATION

  • ENC and ADAPT configurations (see Section 5) in real cloud database services.the authors.
  • The authors initially validate the usage estimation methodology presented in Section 4.3.
  • The authors then analyze how costs vary for different cloud providers and resource usages.
  • The authors finally evaluate tenant’s costs over a medium-term period equal to three years by considering realistic resource usage increments and cloud price reductions.

6.1 Validation of the Usage Estimation

  • To validate the usage estimation model, the authors perform several experiments based on the TPC-C benchmark.
  • Estimated storage of PLAIN, ENC and ADAPT are calculated by using the analytical model presented in Section 4.3.
  • For each estimated value, the authors report the estimation error with respect to the measured database size.
  • The authors then validate the network usage estimation model.
  • The authors deploy PLAIN, ENC and ADAPT TPC-C compliant databases, each having 10 warehouses.

6.2 Analysis of Cloud Database Costs

  • The authors analyze cloud database costs with respect to different cloud provider offers and different storage and network usages.
  • The authors initially estimate the monthly costs of a cloud database service in the PLAIN, ENC and ADAPT configurations with respect to a plaintext storage usage of 100 GB and a plaintext network usage of 100 GB.
  • For each instance, the authors estimate the monthly cost C of the PLAIN, ENC and ADAPT configurations, expressed in USD [$], and the influence of storage cost S and of network cost N on the billing cost C (i.e., S=C and N =C) that are expressed as percentages.
  • It is interesting to observe that the cost differences between plain and encrypted cloud databases tend to remain constant for different instances of the same cloud provider, because their unit prices ps and pn do not vary.
  • The results of this table show that in Amazon RDS C% is always lower than 60 and 90 percent in the ENC and configurations respectively, whereas in SQL Azure it is always lower than 30% (ENC) and 50% .

6.3 Cost Evaluation over a Medium-Term Period

  • The authors now consider an application of the proposed cost model in a realistic scenario in which a tenant wants to estimate the costs of moving his e-commerce database to the cloud for the upcoming three years.
  • An analysis of the break even points is presented in Table 6, in which the authors report the annual and triennial costs with respect to the PLAIN, ENC and ADAPT configurations and different monthly workload increases: 2%; 4% and 9%.
  • The authors observe that the break even points of the two encrypted configurations correspond to monthly workload increases that are lower than the break even point of the plaintext configuration.
  • This occurs because, even if the three configurations are subject to the same workload, the actual resource usages of ENC and ADAPT are higher due to encryption and adaptivity overheads.

7 CONCLUSIONS

  • There are two main tenant concerns that may prevent the adoption of the cloud as the fifth utility: data confidentiality and costs.
  • These applications have not yet received adequate attention by the academic literature, but they are of utmost importance if the authors consider that almost all important services are based on one or multiple databases.
  • The authors investigate the feasibility and performance of the proposed architecture through a large set of experiments based on a software prototype subject to the TPC-C standard benchmark.
  • Moreover, the authors propose a model and a methodology that allow a tenant to estimate the costs of plain and encrypted cloud database services even in the case of workload and cloud price variations in a medium-term horizon.
  • Future research could evaluate the proposed or alternative architectures for multi-user key distribution schemes and under different threat model hypotheses.

Did you find this useful? Give us your feedback

Content maybe subject to copyright    Report

Performance and Cost Evaluation of an Adaptive
Encryption Architecture for Cloud Databases
Luca Ferretti, Fabio Pierazzi, Michele Colajanni, and Mirco Marchetti
Abstract—The cloud database as a service is a novel paradigm that can support several Internet-based applications, but its adoption
requires the solution of information confidentiality problems. We propose a novel architecture for adaptive encryption of public cloud
databases that offers an interesting alternative to the tradeoff between the required data confidentiality level and the flexibility of the
cloud database structures at design time. We demonstrate the feasibility and performance of the proposed solution through a software
prototype. Moreover, we propose an original cost model that is oriented to the evaluation of cloud database services in plain and
encrypted instances and that takes into account the variability of cloud prices and tenant workloads during a medium-term period.
Index Terms—Cloud database, confidentiality, encryption, adaptivity, cost model
Ç
1INTRODUCTION
T
HE cloud computing paradigm is successfully converg-
ing as the fifth utility [1], but this positive trend is par-
tially limited by concerns about information confidentiality
[2] and unclear costs over a medium-long term [3], [4].
We are interested in the database as a service para-
digm (DBaaS) [5] that poses several research challenges
in terms of security and cost evaluation from a tenant’s
point of view. Most results concerning encryption for
cloud-based services [6], [7] are inapplicable to the data-
base paradigm. Other encryption schemes that allow the
execution of SQL operations over encrypted data either
have perf ormance limits [8] or require the choice of which
encryption scheme must be adopted for each database
column and SQL operation [9]. These latter proposals are
fine when the set of queries can be statically determined
at design time, while we are interested in other common
scenarios where the wo rkload may change after the data-
base design. In this paper, we propose a novel architec-
ture for adaptive encryption of public cloud databases
that offers a proxy-free alternative to the system
described in [10 ]. The p ropo sed architectur e guarantees
in an adaptive way the best level of data confidentiality
for any database workload, even when the set of SQL
queries dynamically changes. The adaptive encryption
scheme, which was initially proposed for applications not
referring to the cloud, encrypts e ach plain column to mul-
tiple encrypted columns, and each value is encapsulated
in different layers of encryption, so t hat the outer layers
guarantee higher confid entiality but support fewer com-
putation capabilities with respect to the inner layers. The
outer layers are dynamically adapted at runtime when
new S QL operations are added to the workload.
Although this adaptive encryption architecture is attrac-
tive because it does not require to define at design time
which database operations are allowed on each column, it
poses novel issues in terms of applicability to a cloud con-
text, and doubts about storage and network costs. We inves-
tigate each of these issues and we reach three original
conclusions in terms of prototype implementation, perfor-
mance evaluation, and cost evaluation.
We initially design the first proxy-free architecture for
adaptive encryption of cloud databases that does not limit
the availability, elasticity and scalability of a plain cloud
database because multiple clients can issue concurrent oper-
ations without passing through some centralized compo-
nent as in alternative architectures [10]. Then, we evaluate
the performance of encrypted database services by assum-
ing the standard TPC-C benchmark as the workload and by
considering different network latencies. Thanks to this
testbed, we show that most performance overheads of
adaptively encrypted cloud databases are masked by net-
work latencies that are typical of a geographically distrib-
uted cloud scenario.
Finally, we propose the first analytical cost estimation
model for evaluating cloud database costs in plaintext and
encrypted configurations from a tenant’s point of view over
a medium-term period. This model also considers the vari-
ability of cloud prices and of the database workload during
the evaluation period, and allows a tenant to observe how
adaptive encryption influences the costs related to storage
and network usage of a database service. By applying the
model to several cloud provider offers and related prices,
the tenant can choose the best compromise between the
data confidentiality level and consequent costs in his period
of interest.
This paper is structured as following. Section 2 exam-
ines related solutions for data confidentiali ty and cost
estimation in cloud database services, and compares them
against our proposal. Section 3 describes the proposed
adaptive encryption architecture for cloud database
The authors are with the Department of Engineering “Enzo Ferrari”, Uni-
versity of Modena and Reggio Emilia, Modena, Italy. E-mail: {luca.ferretti,
fabio.pierazzi, michele.colajanni, mirco.marchetti}@unimore.it.
Manuscript received 15 Sept. 2013; revised 7 Mar. 2014; accepted 18 Mar.
2014. Date of publication 1 Apr. 2014; date of current version 30 July 2014.
Recommended for acceptance by I. Bojanova, R.C.H. Hua, O. Rana, and
M. Parashar.
For information on obtaining reprints of this article, please send e-mail to:
reprints@ieee.org, and reference the Digital Object Identifier below.
Digital Object Identifier no. 10.1109/TCC.2014.2314644
IEEE TRANSACTIONS ON CLOUD COMPUTING, VOL. 2, NO. 2, APRIL-JUNE 2014 143
2168-7161 ß 2014 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.
See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

services. Section 4 proposes the anal ytical cost model for
the estimation of database service costs in a medium term
where it is likely that workloads and cloud pric es change.
Section 5 presents experimental evaluations for different
network scenarios, workload models and number of cli-
ents. Section 6 reports the results of the cost model
applied to real c loud database providers over a three
years horizon that is a typical view for tenant’s invest-
ments. Section 7 outlines main conclusions and possible
directions for further research.
2RELATED WORK
Improving the confidentiality of information stored in cloud
databases represents an important contribution to the adop-
tion of the cloud as the fifth utility because it addresses
most user concerns. Our proposal is characterized by two
main contributions to the state of the art: architecture and
cost model.
Although data encryption seems the most intuitive solu-
tion for confidentiality, its application to cloud database
services is not trivial, because the cloud database must be
able to execute SQL operations directly over encrypted data
without accessing any decryption key. Na
ıve solutions
encrypt the whole database through some standard encryp-
tion algorithms that do not allow to execute any SQL opera-
tion directly on the cloud. As a consequence, the tenant has
two alternatives: download the entire database, decrypt it,
execute the query and, if the operation modifies the data-
base, encrypt and upload the new data; decrypt temporarily
the cloud database, execute the query, and re-encrypt it.
The former solution is affected by huge communication and
computation overheads, and consequent costs that would
make cloud database services quite inconvenient; the latter
solution does not guarantee data confidentiality because the
cloud provider obtains decryption keys.
The right alternative is to execute SQL operations directly
on the cloud database, without giving decryption keys to
the provider. An initial solution presented in [5] is based on
data aggregation techniques [8], that associate plaintext
metadata to sets of encrypted data. However, plaintext
metadata may leak sensitive information and data aggrega-
tion introduces unnecessary network overheads.
The use of fully homomorphic encryption [11] would guar-
antee the execution of any operation over encrypted data,
but existing implementations areaffectedbyhugecompu-
tational costs to the extent that the execution of SQL opera-
tions over a cloud database would become impractical.
Other encryption algorithms characterized by acceptable
computational complexity support a subset of SQL opera-
tors [12 ], [13], [14]. For example, an encryption algorithm
may suppo rt the o rder comparison comm and [12], but not
a search operator [14]. The drawback related to these feasi-
ble enc ryption algorithms is t hat in a medium-l ong term
horizon, the database administrator cannot know at design
time whic h database operations will be required over each
database column. This issue is i n part addressed in [10] by
proposing an adaptive encryption architecture that is
founded on an intermediate and trusted proxy. This t en-
ant’s component, which mediates all the interactions
between the clien ts and a possibly untrusted DBMS server,
is fine for a loc ally distributed archite cture but it cannot b e
applied to a cloud context. Indeed, any centralized compo-
nent at the tenant side reduces the scalability and avail-
ability that are among the most important features of
cloud services. A soluti on to t his problem was presented
in [9]: t he proposed architect ure allows multiple clients to
issue concurrent SQL operations to an encrypted database
without any intermediate trusted server, but it assumes
that the set of SQL operations does not change after the
database design. A first idea to integrate adaptive encryp-
tion schemes with a proxy-free architecture was proposed
by the same authors in [15]. This paper develops the initial
design through a prototype imp lementation, novel experi-
mental results and an original cost model.
Indeed, besides data confidentiality, unclear costs are a
main concern for cloud tenants. To this purpose, we propose
an analytical cost model and a usage estimation methodol-
ogy that allow a tenant to estimate the costs deriving from
cloud database services characterized by plain, encrypted
and adaptively encrypted databases over a medium-term
horizon during which it is likely that both the database
workload and the cloud prices change. This model is
another original contribution of this paper because previous
research focuses on the costs of cloud computing from a
provider’s perspective [16], [17]. For example, the authors in
[16] outline the problems related to the cost estimation of a
cloud data center, such as servers, power consumption, and
infrastructures, but they do not propose an analytical cost
estimation model. CloudSim [18] can help a provider to esti-
mate performance and resource consumptions of one or
multiple cloud data center alternatives.
This paper has a focus on database services and takes an
opposite direction by evaluating the cloud service costs
from a tenant’s point of view. This approach is quite origi-
nal because related papers evaluate the pros and cons of
porting scientific applications to a cloud platform, such as
[4] focusing on specific astronomy software and a specific
cloud provider (Amazon), and [3] presenting a composable
cost estimation model for some classes of scientific applica-
tions. Besides the focus on a different context (scientific ver-
sus database applications), the proposed model can be
applied to any cloud database service provider, and it takes
into account that over a medium-term period the database
workload and the cloud prices may vary.
3ARCHITECTURE DESIGN
The proposed system supports adaptive encryption for pub-
lic cloud database services, where distributed and concur-
rent clients can issue direct SQL operations. By avoiding an
architecture based on intermediate servers [10] between the
clients and the cloud database, the proposed solution guar-
antees the same level of scalability and availability of the
cloud service. Fig. 1 shows a scheme of the proposed archi-
tecture where each client executes an encryption engine that
manages encryption operations. This software module is
accessed by external user applications through the encrypted
database interface. The proposed architecture manages five
types of information:
plain data represent the tenant information;
encrypted data are the encrypted version of the plain
data, and are stored in the cloud database;
144 IEEE TRANSACTIONS ON CLOUD COMPUTING, VOL. 2, NO. 2, APRIL-JUNE 2014

plain metadata represent the additional information
that is necessary to execute SQL operations on
encrypted data;
encrypted metadata are the encrypted version of the
plain metadata, and are stored in the cloud database;
master key is the encryption key of the encrypted
metadata, and is known by legitimate clients.
All data and metadata stored in the cloud database are
encrypted. Any application running on a legitimate client
can transparently issue SQL operations (e.g., SELECT,
INSERT, UPDATE and DELETE) to the encrypted cloud
database through the encrypted database interface. Data
transferred between the user application and the encryption
engine are not encrypted, whereas information is always
encrypted before sending it to the cloud database. When an
application issues a new SQL operation, the encrypted data-
base interface contacts the encryption engine that retrieves
the encrypted metadata and decrypts them with the master
key. To improve performance, the plain metadata are
cached locally by the client. After obtaining the metadata,
the encryption engine is able to issue encrypted SQL state-
ments to the cloud database, and then to decrypt the results.
The results are returned to the user application through the
encrypted database interface.
As in related literature, the proposed architecture guar-
antees data confidentiality in a security model in which: the
network is untrusted; tenant users are trusted, that is, they
do not reveal information about plain data, plain metadata,
and the master key; the cloud provider administrators are
defined semi-honest or honest-but-curious [19], that is, they
do not modify tenant’s data and results of SQL operations,
but they may access tenant’s information stored in the cloud
database. The remaining part of this section describes the
adaptive encryption schemes (Section 3.1), the encrypted
metadata stored in the cloud database (Section 3.2), and the
main operations for the management of the encrypted cloud
database (Section 3.3).
3.1 Adaptive Encryption Schemes
We consider SQL-aware encryption algorithms that guaran-
tee data confidentiality and allow the cloud database engine
to execute SQL operations over encrypted data. As each
algorithm supports a specific subset of SQL operators, we
refer to the following encryption schemes.
Random (Rand): it is the most secure encryption
because it does not reveal any information about the
original plain value (IND-CPA) [20], [21]. It does not
support any SQL operator, and it is used only for
data retrieval.
Deterministic (Det): it deterministically encrypts data,
so that equality of plaintext data is preserved. It sup-
ports the equality operator.
Order Preserving Encryption (Ope) [12]: it preserves in
the encrypted values the numerical order of the orig-
inal unencrypted data. It supports the comparison
SQL operators (i.e., ¼;<;;>;).
Homomorphic Sum (Sum) [13]: it is homomorphic
with respect to the sum operation, so that the multi-
plication of encrypted integers is equal to the sum of
plaintext integers. It supports the sum operator
between integer values.
Search: it supports equality check on full strings (i.e.,
the LIKE operator).
Plain: it does not encrypt data, but it is useful to sup-
port all SQL operators on non confidential data.
If each column of the database was encrypted with only
one algorithm, then the database administrator would have
to decide at design time which operations must be sup-
ported on each database column. However, this solution is
impractical for scenarios in which the database workload
changes over time. As an example, if we consider a database
supporting a web application for which features or security
updates are released, data encryption prevents the applica-
tion of any update that introduces new SQL operations that
were not considered at database design time. Similarly,
encryption prevents the execution of data analytics on the
encrypted database and of user-defined queries that do not
belong to a fixed workload (e.g., because the database is
queried directly by tenant employees). This issue can be
addressed through adaptive encryption schemes that sup-
port at runtime SQL operations while preserving the highest
possible data confidentiality level on the encrypted data. To
this purpose, the encryption algorithms are organized into
structures called onions , where each onion is composed by
an ordered set of encryption algorithms, called (encryption)
layers [10]. Outer layers guarantee higher level of data confi-
dentiality and support fewer operations on encrypted data.
Hence, each onion supports a specific set of operations. We
design the following onions:
Onion-Eq: it supports the equality operator, and inte-
grates Plain, Det and Rand layers.
Onion-Ord: it supports the comparison operators
(i.e., ¼;<;;>;), and integrates Plain, Ope and
Rand layer s.
Onion-Sum: it supports the sum operator, and inte-
grates Plain, Sum and Rand layers.
Onion-Search: it supports the string equality operator
(LIKE), and integrates the Plain, Search and Rand
layers.
Onion-Single-Layer: this is a special type of onion that
supports only one encryption layer.
Each plaintext column is converted into one or more
encrypted columns, each one corresponding to an onion.
Each plaintext value is encrypted through all the layers of
Fig. 1. Encrypted cloud database architecture.
FERRETTI ET AL.: PERFORMANCE AND COST EVALUATION OF AN ADAPTIVE ENCRYPTION ARCHITECTURE FOR CLOUD DATABASES 145

its onions. For example, the plaintext values associated with
Onion-Eq are encrypted with Det, then the Det value is
encrypted with Rand. The most external layer of an onion is
called actual layer, which corresponds to its strongest
encryption algorithm. The cloud database can only see the
actual layer of the onions, and has no access to inner layers
nor to plaintext data. The first time that a new SQL opera-
tion is requested on a column, the outer layer of the appro-
priate onion is dynamically removed at runtime through
the adaptive layer removal mechanism that exposes a layer
supporting the requested operations. This layer becomes
the new actual layer of the onion in the encrypted database.
The layer removal mechanism is designed to ensure that the
cloud provider can never access plaintext data. A detailed
description is in Section 3.3.
Fig. 2 shows an example of the onions and layers struc-
tures by considering two plaintext columns having data
types int and varchar. The integer column is encrypted with
Onion-Eq, Onion-Ord, and Onion-Sum, and the string col-
umn is encrypted with Onion-Eq and Onion-Search. Each
onion represents a column in the encrypted database struc-
ture. The actual layers of all the onions are set to Rand, that
guarantees the best data confidentiality level but it does not
allow computations on encrypted data. When an equality
check is requested on the integer column the adaptive layer
removal mechanism removes the Rand layer of Onion-Eq,
thus leaving Det as its new actual layer.
3.2 Metadata Structure
Metadata include all information that allows a legitimate cli-
ent knowing the master key to execute SQL operations over
an encrypted database. They are organized and stored at
table-level granularity to reduce communication overhead
for retrieval, and to improve management of concurrent
SQL operations [22]. We define all metadata information
associated with a table as table metadata. Let us describe the
structure of a table metadata by referring to Fig. 3.
Table metadata include the correspondence between the
plain table name and the encrypted table name because each
encrypted table name is randomly generated. Moreover, for
each column of the original plain table they also include a
set of column metadata containing the name and the data
type of the corresponding plain column (e.g., integer, var-
char, datetime). Each set of column metadata is associated
with as many sets of onion metadata as the number of onions
associated with the column. Onion metadata describe all
the encryption information about an onion and its layers,
hence they are organized in a data structure that contains
the following attributes:
the encrypted name is the name of the encrypted col-
umn (i.e., the onion) in the encrypted cloud database;
the actual encryption layer is the name of the most
external layer of the encrypted data (e.g., Rand)
stored in the column;
the field confidentiality denotes which set of keys
must be used to encrypt a column data, because
only columns that share the same encryption keys
can be joined; we identify three types of field confi-
dentiality parameters: self denotes a private set of
keys for the column, multi-column identifies the
sharing of the same set of keys among two columns,
database imposes the same set of keys on all columns
of the same data type.
the onion parameter identifies the type of onion that
is used to encrypt data (e.g., Onion-Eq).
Each set of onion metadata is associated with as many
sets of layer metadata as the number of layers required by the
onion type. Each set of layer metadata includes an encryp-
tion key and a label identifying the corresponding encryp-
tion algorithm. The set of encryption keys for each onion is
generated according to the field confidentiality parameter
imposed on each encrypted column.
3.3 Encrypted Database Management
We now describe the three main operations involved in the
encrypted database management: database creation, execu-
tion of SQL operations, and adaptive layer removal.
3.3.1 Database Creation
In the setup phase, the database administrator generates a
master key, and uses it to initialize the architecture metadata.
The master key is then distributed to legitimate clients.
Table creation requires the insertion of a new row in the
metadata table. For each table creation, the administrator
adds a column by specifying the column name, data type and
confidentiality parameters. These last data are the most impor-
tant for this paper because they include the set of onions asso-
ciated with the column, the starting layer denoting the actual
layer at creation time, and the field confidentiality of each
onion. If the administrator does not specify the confidential-
ity parameters of a column, they are automatically chosen
by the encryption engine with respect to some tenant’s pol-
icy. Typically, the default policy assumes that each column
is associated with all the compatible onions, and the starting
Fig. 2. Example of onion structures.
Fig. 3. Metadata structure.
146 IEEE TRANSACTIONS ON CLOUD COMPUTING, VOL. 2, NO. 2, APRIL-JUNE 2014

layer of each onion is set to the strongest encryption algo-
rithm. For example, integer columns are encrypted by
default with Onion-Eq, Onion-Ord and Onion-Sum using
Rand as the actual encryption layer (see Fig. 2).
3.3.2 Execution of SQL Operations
When a user/application wants to execute an operation on
the cloud database, the client encryption engine analyzes
the SQL command structure and identifies whic h tables,
columns and SQL operators are involved. The cli ent issues
a request for the ta ble metadata for each invo lved table,
and decrypts the metadata with the master key. Then, the
client determines whether the SQL operators are sup-
ported by the actual layers of the onions associated with
the involved columns. If required, the client issues a
request for layer r emoval in order to support the SQL
operators at runtime. By using the information stored in
the table metadata, the client is able to encrypt the parame-
ters of the SQL operations: t ables and columns names, and
constant values. The client issues this new statement called
encrypted SQL operation to the cloud database which trans-
parently executes it over encrypted data. The encrypted
results a re decrypted using information contained in the
metadata.
3.3.3 Adaptive Layer Removal
The adaptive layer removal is the process that dynamically
removes the external layer of an onion in order to adap-
tively support SQL operations issued by legitimate clients.
Letusdescribethedetailsoftheadaptivelayerremoval
mechanism by referring to the following example. We
consider a table T with columns id of type int and name
of type string, and a tenant client preparing to issue the
following statement to the e ncrypted cloud database:
SELECT
FROM T WHERE id < 10.Theclientencryption
engine analyzes the SQL statement, and identifies that the
operation id < 10 hastobeexecutedontheencrypted
database. Then, the client reads the metadata and checks
whether there is the Onion-Ord attribute associated with
the column id because this is the only onion supporting
the operator < . If the ac tual layer of Onio n-Ord associ-
ated with id is set to R and, then the client dynamically
invokes a stored procedure on the cloud database that
removes at r untime the Rand layer of Onion-Ord of the
column id, thus leaving the Ope layer exposed. The client
can now encrypt the SELECT query that contains the oper-
ation id < 10 and issue the encrypted query to the
encrypted database, that executes it on the Ope layer of
Onion-Ord. Any n ew SQL operation involving an order
comparison on the column id does not require to invoke
again the layer removal procedure because the actual
layer of Onion-Ord is Ope.
The cloud database can execute the adaptive layer
removal if and only if a legitimate client invokes the stored
procedure and gives to it the decryption key of the most
external encryption layer. As each layer has a different
encryption key, the data remain encrypted and the cloud
provider cannot access plaintext data. For security reasons,
we also assume that the adaptive layer removal mechanism
does never expose the Plain layer of an onion.
4COST ESTIMATION OF CLOUD DATABASE
SERVICES
We consider a tenant that is interested in estimating the cost
of porting his database to a cloud platform. This porting is a
strategic decision that must evaluate confidentiality issues
and related costs over a medium-long term. For these rea-
sons, we propose a model that includes the overhead of
encryption schemes and the variability of database work-
load and cloud prices. The proposed model is general
enough to be applied to the most popular cloud database
services, such as Amazon Relational Database Service [23],
EnterpriseDB [24], Windows Azure SQL Database [25], and
Rackspace Cloud Database [26].
4.1 Cost Model
The cost of a cloud database service can be estimated as a
function of three main parameters:
Cost ¼ fðTime; Pricing; UsageÞ; (1)
where:
Time identifies the time interval T for which the ten-
ant requires the service.
Pricing refers to the prices of the cloud provider for
subscription and resource usage; they typically tend
to diminish during T [27].
Usage denotes the total amount of resources used by
the tenant; it typically increases during T .
In order to detail the Pricing attribute, it is important to
specify that cloud providers adopt two subscription poli-
cies: the on-demand policy allows a tenant to pay-per-use
and to withdraw his subscription anytime; the reservation
policy requires the tenant to commit in advance for a reser-
vation period. Hence, we distinguish between billing costs
that depend on resource usage and reservation costs denoting
additional fees for commitment in exchange for lower pay-
per-use prices [28]. Billing costs are billed periodically to
the tenant every billing period T
B
. Moreover, if the tenant
adopts the reservation policy, the cloud provider requires
the payment of the reservation cost at the beginning of each
reservation period T
R
. An example of the relationship among
T (three years), T
R
(one year) and T
B
(one month) is repre-
sented in Fig. 4.
Pricing is the set of reservation prices and billing prices. Res-
ervation prices fR
r
g refer to reservation periods, where
r ¼½1; ...;N
R
and N
R
¼
T
=
T
R
is the number of reservation
periods. Billing prices refer to billing periods b ¼½1; ...;
N
B
, where N
B
¼
T
=
T
B
. Our model takes into account bill-
ing prices for all the resources considered by the main pro-
viders [28], [29], [30], [31], [32]: uptime price fp
h
b
g, storage
price fp
s
b
g and network price fp
n
b
g.
Fig. 4. Example of relationship among estimation (T ), reservation (T
R
)
and billing (T
B
) periods.
FERRETTI ET AL.: PERFORMANCE AND COST EVALUATION OF AN ADAPTIVE ENCRYPTION ARCHITECTURE FOR CLOUD DATABASES 147

Citations
More filters
Journal ArticleDOI
TL;DR: This article presents a multicloud storage architecture called WA-MRC-RRNS that combines the weighted access scheme, threshold secret sharing, and redundant residue number system with multiple failure detection/recovery mechanisms and homomorphic ciphers and proposes a multiobjective optimization mechanism to adjust redundancy, encryption–decryption speed, and data loss probability.
Abstract: Internet-of-Things (IoT) environment has a dynamic nature with high risks of confidentiality, integrity, and availability violations. The loss of information, denial of access, information leakage, collusion, technical failures, and data security breaches are difficult to predict and anticipate in advance. These types of nonstationarity are one of the main issues in the design of the reliable IoT infrastructure capable of mitigating their consequences. It is not sufficient to propose solutions for a given scenario, but mechanisms to adapt the current solution to changes in the environment. In this article, we present a multicloud storage architecture called WA-MRC-RRNS that combines the weighted access scheme, threshold secret sharing, and redundant residue number system with multiple failure detection/recovery mechanisms and homomorphic ciphers. We provide a theoretical analysis of the probability of information loss, data redundancy, speed of encoding/decoding, and show how to dynamically configure parameters to cope with different objective preferences, workloads, and cloud properties. We propose a multiobjective optimization mechanism to adjust redundancy, encryption–decryption speed, and data loss probability. Comprehensive experimental analysis with real data shows that our approach provides a secure way to mitigate the uncertainty of the use of untrusted and not reliable IoT infrastructure.

34 citations


Additional excerpts

  • ...on costs [10], [11]....

    [...]

Journal ArticleDOI
TL;DR: Evaluation results show that BDTD can be shared securely multiple times per second through the framework, which demonstrates the feasibility of the framework in supporting timely sharing of BDTD.

25 citations

Journal ArticleDOI
TL;DR: An original solution based on encrypted Bloom filters that addresses the latter problem by allowing a cloud service user to detect unauthorized modifications to his outsourced data and an original analytical model that can be used to minimize storage and network overhead depending on the database structure and workload is proposed.

21 citations


Cites background from "Performance and cost evaluation of ..."

  • ...Existing verification solutions are affected by prohibitive computational, storage and bandwidth overhead that have an impact on costs because additional network and storage usage increases cloud service expenses [22]....

    [...]

Journal ArticleDOI
TL;DR: Numerical results demonstrate RCRM outperforms the others in dropping probability, SLA violation, violation penalty and net profit, and the dropping probability of analysis is very close to that of simulation and justifies the correctness of the proposed Markov chain model.

12 citations


Cites background from "Performance and cost evaluation of ..."

  • ...However, more the number of the deployed cloud DCs, higher the cloud cost [25,26]....

    [...]

Journal Article
TL;DR: In this paper, a new technique that provides data confidentiality and concurrent access of encrypted cloud database with resolving the bottleneck problem is presented, which can solve the problem of data confidentiality in cloud.
Abstract: We are moving to future where some or even most of our data will exist in cloud, because cloud provides stored data to be accessed at anywhere through networks. Since data in cloud will be placed anywhere, because of the critical nature of the applications, it is important that clouds be secure. The major security challenge with clouds is that the owner of the data may not have control of where the data is placed; it will create other problems also like data confidentiality and bottleneck. This paper presents a new technique that provides data confidentiality and concurrent access of encrypted cloud database with resolving the bottleneck problem .

10 citations

References
More filters
Book ChapterDOI
02 May 1999
TL;DR: A new trapdoor mechanism is proposed and three encryption schemes are derived : a trapdoor permutation and two homomorphic probabilistic encryption schemes computationally comparable to RSA, which are provably secure under appropriate assumptions in the standard model.
Abstract: This paper investigates a novel computational problem, namely the Composite Residuosity Class Problem, and its applications to public-key cryptography. We propose a new trapdoor mechanism and derive from this technique three encryption schemes : a trapdoor permutation and two homomorphic probabilistic encryption schemes computationally comparable to RSA. Our cryptosystems, based on usual modular arithmetics, are provably secure under appropriate assumptions in the standard model.

7,008 citations

Journal ArticleDOI
TL;DR: This paper defines Cloud computing and provides the architecture for creating Clouds with market-oriented resource allocation by leveraging technologies such as Virtual Machines (VMs), and provides insights on market-based resource management strategies that encompass both customer-driven service management and computational risk management to sustain Service Level Agreement (SLA) oriented resource allocation.

5,850 citations

Proceedings ArticleDOI
Craig Gentry1
31 May 2009
TL;DR: This work proposes a fully homomorphic encryption scheme that allows one to evaluate circuits over encrypted data without being able to decrypt, and describes a public key encryption scheme using ideal lattices that is almost bootstrappable.
Abstract: We propose a fully homomorphic encryption scheme -- i.e., a scheme that allows one to evaluate circuits over encrypted data without being able to decrypt. Our solution comes in three steps. First, we provide a general result -- that, to construct an encryption scheme that permits evaluation of arbitrary circuits, it suffices to construct an encryption scheme that can evaluate (slightly augmented versions of) its own decryption circuit; we call a scheme that can evaluate its (augmented) decryption circuit bootstrappable.Next, we describe a public key encryption scheme using ideal lattices that is almost bootstrappable.Lattice-based cryptosystems typically have decryption algorithms with low circuit complexity, often dominated by an inner product computation that is in NC1. Also, ideal lattices provide both additive and multiplicative homomorphisms (modulo a public-key ideal in a polynomial ring that is represented as a lattice), as needed to evaluate general circuits.Unfortunately, our initial scheme is not quite bootstrappable -- i.e., the depth that the scheme can correctly evaluate can be logarithmic in the lattice dimension, just like the depth of the decryption circuit, but the latter is greater than the former. In the final step, we show how to modify the scheme to reduce the depth of the decryption circuit, and thereby obtain a bootstrappable encryption scheme, without reducing the depth that the scheme can evaluate. Abstractly, we accomplish this by enabling the encrypter to start the decryption process, leaving less work for the decrypter, much like the server leaves less work for the decrypter in a server-aided cryptosystem.

5,770 citations


Additional excerpts

  • ...Index Terms—Cloud database, confidentiality, encryption, adaptivity, cost model Ç...

    [...]

Journal ArticleDOI
TL;DR: The result of this case study proves that the federated Cloud computing model significantly improves the application QoS requirements under fluctuating resource and service demand patterns.
Abstract: Cloud computing is a recent advancement wherein IT infrastructure and applications are provided as ‘services’ to end-users under a usage-based payment model. It can leverage virtualized services even on the fly based on requirements (workload patterns and QoS) varying with time. The application services hosted under Cloud computing model have complex provisioning, composition, configuration, and deployment requirements. Evaluating the performance of Cloud provisioning policies, application workload models, and resources performance models in a repeatable manner under varying system and user configurations and requirements is difficult to achieve. To overcome this challenge, we propose CloudSim: an extensible simulation toolkit that enables modeling and simulation of Cloud computing systems and application provisioning environments. The CloudSim toolkit supports both system and behavior modeling of Cloud system components such as data centers, virtual machines (VMs) and resource provisioning policies. It implements generic application provisioning techniques that can be extended with ease and limited effort. Currently, it supports modeling and simulation of Cloud computing environments consisting of both single and inter-networked clouds (federation of clouds). Moreover, it exposes custom interfaces for implementing policies and provisioning techniques for allocation of VMs under inter-networked Cloud computing scenarios. Several researchers from organizations, such as HP Labs in U.S.A., are using CloudSim in their investigation on Cloud resource provisioning and energy-efficient management of data center resources. The usefulness of CloudSim is demonstrated by a case study involving dynamic provisioning of application services in the hybrid federated clouds environment. The result of this case study proves that the federated Cloud computing model significantly improves the application QoS requirements under fluctuating resource and service demand patterns. Copyright © 2010 John Wiley & Sons, Ltd.

4,570 citations


Additional excerpts

  • ...Index Terms—Cloud database, confidentiality, encryption, adaptivity, cost model Ç...

    [...]

Book
14 Feb 2002
TL;DR: The underlying mathematics and the wide trail strategy as the basic design idea are explained in detail and the basics of differential and linear cryptanalysis are reworked.
Abstract: 1. The Advanced Encryption Standard Process.- 2. Preliminaries.- 3. Specification of Rijndael.- 4. Implementation Aspects.- 5. Design Philosophy.- 6. The Data Encryption Standard.- 7. Correlation Matrices.- 8. Difference Propagation.- 9. The Wide Trail Strategy.- 10. Cryptanalysis.- 11. Related Block Ciphers.- Appendices.- A. Propagation Analysis in Galois Fields.- A.1.1 Difference Propagation.- A.l.2 Correlation.- A. 1.4 Functions that are Linear over GF(2).- A.2.1 Difference Propagation.- A.2.2 Correlation.- A.2.4 Functions that are Linear over GF(2).- A.3.3 Dual Bases.- A.4.2 Relationship Between Trace Patterns and Selection Patterns.- A.4.4 Illustration.- A.5 Rijndael-GF.- B. Trail Clustering.- B.1 Transformations with Maximum Branch Number.- B.2 Bounds for Two Rounds.- B.2.1 Difference Propagation.- B.2.2 Correlation.- B.3 Bounds for Four Rounds.- B.4 Two Case Studies.- B.4.1 Differential Trails.- B.4.2 Linear Trails.- C. Substitution Tables.- C.1 SRD.- C.2 Other Tables.- C.2.1 xtime.- C.2.2 Round Constants.- D. Test Vectors.- D.1 KeyExpansion.- D.2 Rijndael(128,128).- D.3 Other Block Lengths and Key Lengths.- E. Reference Code.

3,444 citations


"Performance and cost evaluation of ..." refers background in this paper

  • ...Although data encryption seems the most intuitive solution for confidentiality, its application to cloud database services is not trivial, because the cloud database must be able to execute SQL operations directly over encrypted data without accessing any decryption key....

    [...]

Frequently Asked Questions (2)
Q1. What are the contributions mentioned in the paper "Performance and cost evaluation of an adaptive encryption architecture for cloud databases" ?

The authors propose a novel architecture for adaptive encryption of public cloud databases that offers an interesting alternative to the tradeoff between the required data confidentiality level and the flexibility of the cloud database structures at design time. The authors demonstrate the feasibility and performance of the proposed solution through a software prototype. Moreover, the authors propose an original cost model that is oriented to the evaluation of cloud database services in plain and encrypted instances and that takes into account the variability of cloud prices and tenant workloads during a medium-term period. 

Future research could evaluate the proposed or alternative architectures for multi-user key distribution schemes and under different threat model hypotheses.